When a security advisory lands, the first question is almost always the same: has anything unusual already happened on our server? Whether you can answer depends on a decision made long before the advisory arrived, namely what the server was logging and for how long. This is a follow-up to our five-question runbook for any file transfer server, which asks “Can you see what’s happening?” Here is how to make the answer yes with FileZilla Server and FileZilla Pro Enterprise Server.
One caveat up front: logs can’t prove that nothing happened, and they can’t tell you whether a vulnerability exists. What they can do is help you notice activity that doesn’t match how your server is normally used, which is often the earliest visible sign of a problem.
Set up logging before you need it
FileZilla Server keeps a log of its actions, and you choose how much detail it records with the logging level, from 0 (logging disabled) to 5 (verbose). Verbose logging is mainly useful when you’re working through an issue with support. For day-to-day use, decide on a level in advance and check that the events you care about actually show up at that level. You can send the log to the standard error channel or to a file, and a file is the practical choice for anything you’ll want to look back at. The logging level guide covers the settings. Three details are worth getting right:
- Rotation. You can rotate log files daily or when they reach a maximum size. By default the maximum number of log files is 1, so raise it if you want history to look back through.
- Permissions. Log files are intentionally restrictive, because they may contain sensitive information: only the account the service runs under and Administrators can read them. Keep it that way when you copy or archive them.
- Retention. Decide how long you keep logs and where copies live, before an advisory forces the question.
Know what normal looks like
Anomalies only stand out against a baseline. Pick a quiet period and note the basics: which accounts connect, from which addresses, at what times, and roughly how much data moves. The active sessions list at the bottom of the administration interface helps here. You can see who is connected right now, open More info for the details of a session, and use the context menu to kill a session or ban its IP address.
Five signals worth checking
1. Bursts of failed logins
Look for many failures from one address across many usernames, or one username attacked from many addresses. Background noise is routine on any internet-facing server, so what matters is a change in volume, or a run of failures followed by a success. Autoban can ban an address after a preset number of failed logins. One detail to confirm: if the ban duration is left at 0, no ban is applied.
2. Successful logins at odd hours or from unfamiliar addresses
An account that only ever connects from a partner’s network during business hours shouldn’t suddenly sign in at 3 a.m. from somewhere else. When an account has a predictable source, IP-based filters let you allow or disallow connections by address or range, including at user and group level.
3. Activity that doesn’t match the account
An account that normally uploads one small file a night, and starts listing many directories or downloading large volumes, deserves a closer look even if the login itself looked legitimate. This is where the baseline you noted earlier pays off.
4. Attempts to reach the administration interface
The administration interface shouldn’t be reachable from the open internet. Connection attempts from addresses outside your management network are worth investigating, and so is any unexplained change to where the interface listens. You can configure which addresses and ports it uses.
5. Gaps in the log
A stretch with no entries when you’d expect traffic, or a logging level that has quietly changed to 0, is a finding in itself. It may be benign, such as a full disk or a misconfigured rotation, but you want to know before someone asks you what happened during that window.
If something looks wrong
Preserve first, then contain. Copy the current log files somewhere safe, keeping their access restricted, before rotation replaces them. Then kill the suspicious sessions and ban the addresses from the active sessions list, tighten your IP filters, and rotate credentials for any affected accounts. Export your server configuration so you have a record of the settings as they were at that moment.
These controls work per server instance. If you run several servers, you review each one’s logs separately, so it’s worth agreeing in advance who does that and how often.
Where FileZilla Pro fits in
Logging, file rotation, Autoban and IP filtering belong to the core that both the free FileZilla Server and FZPES share. FZPES adds SFTP alongside FTP and FTPS, Active Directory/LDAP integration, 2FA and priority support, for teams that need them.
Running a file transfer server for your team?
FileZilla Pro Enterprise Server adds SFTP alongside FTP and FTPS, plus Active Directory integration and role-based access, with no limit on the number of users.