Log-Driven Auto-Banning for Transfer Services

Throttling inside the transfer application is a fine first line, but it has two gaps. Not every transfer server implements per-source banning itself, and even when one does, the guessing traffic still reaches the service to be counted and refused, one attempt at a time. There is a cleaner move for the loud, obvious attackers: watch the authentication log, notice a source that is clearly guessing, and tell the firewall to drop that source entirely for a while — so its next thousand attempts never even reach the server.

This is the watch-logs-then-ban pattern. The best-known tool in the category, fail2ban, gave the approach its popular name, but the idea is older and larger than any single program and applies to any server that writes an authentication log. This article teaches the pattern itself so you can apply it with whatever tooling your platform offers: how the loop works, how to write rules against transfer-service logs, why partner whitelisting is non-negotiable, how to choose ban durations, and how to handle the false positives that will happen.

It is part of our Brute-Force Defense series, and it is the automated enforcement layer behind the per-source thinking in lockout and throttling design — the mechanism that acts on the loud dictionary noise from the anatomy of credential attacks while you sleep.

The Loop in Four Parts

Every implementation of this pattern, whatever it is called, is the same feedback loop with four moving parts. Understand the loop and you can reason about any tool that implements it.

• A log to watch. The source of truth is the authentication log — the record of who tried to log in, from where, and whether they succeeded.
• A matcher. A rule that recognizes a genuine failure line and, crucially, extracts the source address from it. This is the part you tune to your server's log format.
• A threshold and window. The decision: how many matching failures from one source, within how long, count as an attack — for example, eight failures in ten minutes.
• An action with a timer. When the threshold trips, the source is banned at the firewall for a set duration, then automatically unbanned when the timer expires.

The diagram below traces that loop, including the two things that keep it safe: a partner whitelist feeding the matcher so known-good sources are never counted, and an unban timer so bans expire on their own.

The loop runs continuously. Most of the time the matcher sees ordinary traffic and does nothing. When a dictionary run or a scanner starts hammering, that one source crosses the threshold within minutes, gets dropped at the firewall, and disappears from the server's world entirely until its ban expires. The server never sees the bulk of the attack, which is the whole point.

Writing Rules for Transfer-Service Logs

The tool matters less than the rule you feed it, and transfer logs have a wrinkle that generic SSH examples gloss over: a transfer server often speaks several protocols — FTP, FTPS, SFTP, HTTPS — each of which may format its log lines a little differently. Your matcher has to recognize a real authentication failure in each of them and pull out the source address reliably. Match too loosely and you will ban on benign events like a normal disconnect; match too tightly and you will miss the attack on the one protocol you forgot.

The ruleset below is written as neutral pseudo-config to show the shape rather than any one product's syntax. Copy the structure, not the exact keywords, into whatever your platform uses:

WATCH-THEN-BAN RULESET  (illustrative pseudo-config)

# 1. WHERE TO WATCH
watch:
  source  = transfer-server activity log (ALL protocols)
  a line of interest looks like:
    AUTH FAIL  user=... src=<ip>  proto=...  reason=...

# 2. WHAT COUNTS AS AN OFFENSE
rule auth-fail:
  match      = "AUTH FAIL" AND capture src=<ip>
  threshold  = 8 failures
  window     = 10 minutes
  action     = ban <ip>

# 3. HOW LONG  (progressive - escalate repeat offenders)
ban-time:
  first offense   = 15 minutes
  second          = 4 hours
  third and up    = 24 hours        # the "recidive" tier
  permanent       = MANUAL only, confirmed-malicious

# 4. NEVER BAN THESE  (partner whitelist / ignore list)
ignore:
  203.0.113.64/28     # Acme Logistics prod egress
  198.51.100.0/28     # Bravo Inc SFTP gateway
  10.0.0.0/8          # internal networks
  <monitoring probe address>

# 5. SAFETY RAILS
on-ban:
  record the triggering lines + src + chosen ban-time
  ALERT if a banned range overlaps a known partner
  expose a fast:  unban <ip>   for reversing mistakes

Two rules of thumb make the matcher trustworthy. First, ban on authentication failures, not on connection events — a closed connection, a passive-data hiccup, or a protocol negotiation is not an attack, and matching on those produces bans that baffle everyone. Second, confirm you are capturing the true client address. If your transfer server sits behind a load balancer or reverse proxy, the log may show the proxy's address on every line, and a naive rule would either ban the proxy (taking everyone down) or never ban anyone. Make sure the real source is what your matcher reads — a concern that overlaps with the edge architecture in our hardening series.

Partner Whitelisting Is Not Optional

Section 4 of that ruleset is the one you cannot skip. Auto-banning acts at the firewall, which is a blunter and more disruptive instrument than a soft account lock — a banned source is gone entirely, across every service, often silently. If a legitimate partner ever trips the rule, they do not get a friendly retry prompt; they get a dropped connection and a confusing outage.

And partners trip these rules more often than you would think. The classic case is the stale-credential loop: a partner's scheduled job retries a dead password every fifteen minutes, patiently generating failures around the clock. Per the threshold above, that job bans its own partner within an hour or two — converting a fixable configuration error into a firewall-level outage that is much harder to diagnose, because now the partner cannot even reach the login to see the "bad password" message. Whitelisting the partner's known source addresses means their failures are counted as "someone to call," not "someone to ban."

This is exactly where auto-banning and IP allowlisting click together. Your known partners' addresses go on the ignore list here, while the auto-ban does its aggressive work on the open, anonymous traffic that allowlisting could not cover. The two controls partition the world cleanly: approved sources are never banned, and unapproved noise is banned fast.

Choosing Ban Durations

The instinct to ban attackers forever is understandable and usually wrong. The right shape is short first, escalating on repeat.

A first offense should earn a short ban — fifteen minutes is plenty to break a dictionary run's rhythm and send the attacker's automation off to easier targets. The reason to keep it short is the same reason to keep account locks short: it limits the blast radius of a false positive. If your rule accidentally caught an innocent source, a fifteen-minute ban self-heals before it becomes a real problem, whereas a mistaken permanent ban is a support ticket waiting weeks to happen.

A source that comes back and offends again has told you something — it is not a scanner passing through, it is persistent — so escalate: hours for a second offense, a day for the third and beyond. This "repeat offender" tier (fail2ban calls it recidive, and the concept outlives the name) reserves the heavier bans for the sources that keep earning them.

Permanent bans deserve real caution, for a reason that surprises people: addresses are recycled. Today's attacking address may, months from now, be reassigned to a home user, a mobile carrier's shared pool, or a cloud tenant who is a perfectly legitimate future partner. A growing list of permanent bans quietly accumulates addresses that are no longer hostile, and eventually one of them belongs to someone you need. Keep permanent bans rare, manual, reviewed, and reserved for sources with a confirmed malicious history and no plausible legitimate future.

Handling the Inevitable False Positive

No matter how careful the rules, auto-banning will eventually catch someone innocent. Planning for that is the difference between a control your team trusts and one they rip out after the first bad Monday. False positives come from a few recognizable places:

• Shared and carrier-grade NAT addresses. Many real users can sit behind one address — a whole office, or thousands of mobile customers behind a carrier's shared pool. Banning that one address is collateral damage against everyone behind it.
• A partner's own misconfiguration. The stale-credential loop, a client set to retry too aggressively, or a job accidentally pointed at the wrong account can all look like an attack from a friendly source.
• Monitoring and health checks. An uptime probe or a security scanner you run yourself can trip the rule if you forget to exclude it.

The defenses against false positives are mostly things you build in advance: a well-maintained whitelist, deliberately short first-offense bans so mistakes self-heal, an alert when a ban overlaps a known partner range, and — the one people forget — a fast, documented manual unban. When a partner calls to say they are locked out, you should be able to clear their ban in seconds and know exactly where to do it, not go hunting through firewall state under pressure. Recording the triggering log lines with every ban makes the review honest: you can see precisely why a source was banned and decide in a moment whether it was right.

A short false-positive runbook belongs alongside the partner-lockout runbook from the authentication series: confirm the caller out of band, look up the ban and its triggering lines, unban if it was a mistake, whitelist the source if it will legitimately recur, and note what happened so the rules improve. A handful of these entries teaches you more about your thresholds than any default ever could.

Where to Run It, and Feeding It Good Logs

The pattern can run right on the transfer host, banning at the local firewall, which is simple and self-contained. On a larger estate it often runs at a central log-collection point that watches many servers at once and pushes bans to a network firewall — the same place your logs are already being aggregated. Either way, the loop is only as good as the log it reads, and that log has to include the source address and a clear success-or-failure outcome for every attempt, across every protocol.

A Windows transfer server such as Sysax Multi Server writes those per-attempt authentication events to its activity log for FTP, FTPS, SFTP, and HTTPS, which is precisely the input a watch-then-ban tool consumes to decide whom to drop. Getting that log off the box and somewhere durable and searchable — so an attacker who lands cannot erase the evidence, and so your matcher has a reliable feed — is the pipeline work covered in transfer logging and audit.

One more detail decides how much collateral a ban causes: granularity. Ban the smallest unit that stops the attack — usually a single address — rather than the whole surrounding range, because a range ban risks catching innocent neighbors. This matters especially with IPv6, where a single user is often assigned a large block of addresses and a naive per-address ban is easily sidestepped by hopping within that block. The pragmatic answer is to ban a modest prefix for IPv6 sources and single addresses for IPv4, and to keep even those bans short so the recycled-address problem stays small.

Test Before You Enforce

Enabling aggressive banning blind is a fine way to cause a self-inflicted outage, so treat rollout the way you would any risky change. Run the rules first in a dry-run or log-only mode that records what would be banned without actually dropping anyone, and watch the results across a full business cycle — a week or a month, long enough for your scheduled partner jobs to run. Every would-be ban that lands on a partner, a shared office address, or your own monitoring is a whitelist entry you get to add before it hurts. Only when the dry run is quiet — banning nothing but obvious noise — do you switch to enforce. Done this way, the day you turn on real banning is uneventful, because you have already seen everything the rules will do.

One Layer Among Several

Auto-banning is powerful but narrow: it excels at the loud, high-volume, single-source attacks — the dictionary sweeps and noisy scanners — and it is deliberately blind to the quiet ones. A low-and-slow spray that makes one attempt per source stays under any sane threshold, by design. That is not a flaw in auto-banning; it is why the other layers exist. Allowlisting removes whole populations of attackers, throttling handles the medium noise, key-only authentication ends password guessing outright, and monitoring catches the slow, distributed campaigns that no single-source rule can see. Auto-banning takes the loud majority off your plate so your attention is free for the quiet minority that actually needs a human.

Wrapping Up

The watch-logs-then-ban pattern is a simple loop — read the auth log, recognize a source that is clearly guessing, drop it at the firewall, and unban it on a timer — and it is one of the highest-value controls you can add to an internet-facing transfer server. Write rules that match real authentication failures across every protocol and capture the true client address. Whitelist your partners and internal networks without exception, because a firewall ban is a heavy, silent instrument. Keep first-offense bans short and escalate only for repeat offenders, and hold permanent bans in reserve because addresses get recycled. Above all, plan for the false positive: short bans, good whitelists, an overlap alert, and a fast manual unban turn an inevitable mistake into a non-event.

From here, pair this with IP allowlisting so approved partners populate the ignore list, revisit lockout and throttling design for the in-application controls that sit alongside it, and build the detection for the attacks banning cannot see in watching credential attacks in your logs.

Frequently Asked Questions