Skip to main content

Monitoring vsftpd

vsftpd is recognised by its process and monitored from its own transfer log: logins, failed logins, uploads and downloads become per-second rates, port 21 gets a liveness check, and a brute-force rule arms itself the moment the first rate arrives. Nothing is configured on your side.

How vsftpd is recognised​

The signed definition matches a host running a process named vsftpd. Once matched, every 60 seconds the agent dials 127.0.0.1:21, runs vsftpd -v for the version, and reads the configuration at /etc/vsftpd.conf (Debian family) or /etc/vsftpd/vsftpd.conf (RHEL family) for the vsftpd_log_file or xferlog_file setting. That file is tailed; when the configuration names none, the agent falls back to /var/log/vsftpd.log and then /var/log/xferlog, whichever exists. A missing log is not an error: the check stays ok and the tailer starts the moment the file appears.

What is collected​

Logins and transfers. Four counters over the new log lines: OK LOGIN, FAIL LOGIN, OK UPLOAD and OK DOWNLOAD, each turned into a per-second rate. Only new lines are read; the log stays where it is.

Liveness. A connection to port 21 has to be accepted. A port that is held but never accepts is reported as "the port is bound but the service is not accepting connections".

Facts shown on the host page: version and the log file path.

SignalMetric
Logins per secondsvc.vsftpd.login_rate
Failed logins per secondsvc.vsftpd.login_fail_rate
Uploads per secondsvc.vsftpd.upload_rate
Downloads per secondsvc.vsftpd.download_rate

Names, tags and units are in the metrics reference.

Logs. vsftpd's journal entries ship at notice level and above, and so does the transfer log itself: its lines carry no severity, so each is filed at notice and ships by default. See Logs.

Alerts out of the box​

RuleFires whenSeverityShips
FTP brute-force in progress0.2 or more failed logins per second, sustained for two minuteswarningauto

Twelve failures a minute, held for two minutes, is not a user who forgot a password. auto means the rule arms itself the moment svc.vsftpd.login_fail_rate starts flowing for your workspace, so a host without FTP never carries it and one with FTP gets it without a click. The incident closes once failures fall under 0.05 per second. Pure-FTPd has the same rule with the same numbers. Thresholds and hysteresis are in the rules catalog.

When a path is not where vsftpd says it is​

The log path comes from the configuration file. To point the agent elsewhere:

sudo wakora --set vsftpd.log-file=/var/log/ftp-custom/vsftpd.log

Keys are listed in Agent configuration.

Limitations​

  • The counters key off vsftpd's own log format (OK LOGIN, FAIL LOGIN, OK UPLOAD, OK DOWNLOAD). A log written in the wu-ftpd xferlog format (xferlog_std_format=YES) has none of these markers, so the rates stay at zero.
  • Only port 21 is probed; the passive data port range and implicit FTPS on 990 are not checked.
  • The configuration is read from the two stock paths. A daemon started with a config file elsewhere still gets the fallback log paths, but not the one that file names.
  • Failed logins are a rate without a per-source breakdown; the shipped log lines carry the client addresses.
  • Session counts and bytes transferred are not collected.