How to Detect and Prevent “Low and Slow” Brute Force Attacks

Low and slow brute force attacks against FTP servers, SSH servers and WebDAV servers are already happening, so it’s important to learn how to detect and mitigate this increasing threat.

“Rapid Fire” vs. “Low and Slow”

We’ve all seen script kiddies fire up an SSH session and try 500 root passwords against a server in less than a minute.  That kind of “rapid fire” attack is really noisy.  That makes it easy to detect – and easy for both IP lockouts (a.k.a. antihammering) and user lockouts to shut down (usually in 10 tries or less).

The opposite case involves more sophisticated hackers – the ones who know that almost everyone relies on their built-in lockouts, and who can fly under the radar with “low and slow” scans.  These scans may try one username or multiple usernames, but they’re stretched out over hours, days, weeks or even months, with attempts staggered minutes or hours apart to avoid tripping your alerts and lockouts.

Defending Against “Low and Slow” Attacks

To defend against low and slow attacks you need to stretch the amount of time it would reasonably take to break in beyond the amount of time a hacker might reasonably spend trying to break in.

To accomplish this goal, there are four basic security policies you should implement immediately.

1) IP and User Lock-Outs.  Ensure your FTP server or SFTP server will automatically deny all access to remote clients and end users who hammer your system with bad attempts.  This will force the bad guys to use a “low and slow” approach rather than a “rapid fire” approach – and buy you valuable time to detect and prevent the attack.  An appropriate lockout trigger might be five bad attempts in one hour.

2) IP White and Black Lists.  Do you really need to provide full access to all clients in Russia and China?  Didn’t think so.  So why is your FTP server or SFTP server open to the whole Internet?   Decide today on a white list or black list default IP policy to restrict access to your server from the regions where you actually exchange files.

3) No Common Usernames.  Do not permit use “root” or “administrator” (duh) or even dictionary usernames like “oracle”, “test”, “ftp” or “marketing.”  Most evil scanners target these usernames disproportionally, because if you’re dumb enough to use a common username, you might be dumb enough to use a weak password, right?

4) Strong Passwords.  You already know this drill or you wouldn’t be reading this article.

Detecting “Low and Slow” Attacks

OK, if step one was to force the bad guys to use slow and ineffective tactics, step two is to find even “low and slow” attacks and shut them down automatically.  (Yes, this can be done.)

The first thing to do is to start logging all your failed authentication attempts to a database.  Save four pieces of information in every record: timestamp, source IP, username, and the password (or hash of the password) attempted.

Once you have some records built up, you can start querying the data.  Some recommended queries include:

  • Number of attempts by source IP, where number of attempts is larger than 10 or so:
    • Gives you a rough idea of how many scanners are after you.
    • However, also counts misconfigured FTP scripts and automation.   (Look for internal or other known IPs and chase them down manually!)
  • Number of attempts by username, where number of attempts is larger than 10 or so:
    • Gives you a rough idea of which usernames are being targeted
    • However, may also include misconfigured FTP scripts

As you can see, just filtering on busy usernames or IP addresses could collect legitimate users.  To exclude them we need to apply a behavior that is unique to brute force scanners: trying different combinations of usernames and passwords until they find one that works.

Lampe’s “Low and Slow” Lock-Out Algorithm

The following algorithm will detect most “low and slow” brute force scanners from data containing timestamps, source IPs, usernames and passwords.  Feel free to pair this algorithm with an automated lock-out process to shut the door on sophisticated evildoers.

If more than [badcredcombos] within [timeframe], lock the associated source IP.  


  • Each [badcredcombos] represents one unique set of username/password credentials.   (We ignore multiple invocations of the same credentials.)
  • [timeframe] is a relatively long sliding scale, such as “day”, “week” or even “month”

(Highly distributed attacks – e.g., four attempts from each attacking subnet – will evade this rule, but if your bad guys have to resort to that level of distribution you’ve probably already won.) 

Example One (Locking Out the Bad Guys)

Rule: If more than 5 badcredcombos in 1 week, lock out source IP.

A “low and slow” scanner hits us with”aaa/111″ on Monday, “aaa/112” on Tuesday, “aaa/113” on Wednesday, “bbb/111” on Thursday, “bbb/112” on Friday and “bbb/113” on Saturday.   That’s 6 badcredcombos in 1 week, so we lock out the source IP.

Example Two (Ignoring Legitimate Users)

Rule: If more than 4 badcredcombos in 2 days, lock out source IP.

A remote end user is fumbling around with his automated FTP client.  He hits us 25 times with “aaa/111” on Monday, 3 times with “aaa/112” also on Monday, and then switches to 57 “bbb/333” attempts on Tuesday.   That’s 3 (unique) badcredcombos in 2 days, so we do NOT lock out the source IP.


Download a free FTP/FTPS/SFTP brute force scanner and test for yourself.

About Jonathan Lampe

Andy White and I started File Transfer Consulting in 2011 to solve secure file transfer and managed file transfer issues through strategic analysis, training, integration and custom development. Our unique approach allows us to address complicated issues like no one else.

Before FTC I created and then led the development of Ipswitch's MOVEit managed file transfer software for ten exciting years, including three as VP for R&D and Product Management at Ipswitch (WS_FTP, MessageWay and hosted services). I also served for VP for Product Management for RhinoSoft (Serv-U), where I guided the development of managed file capabilities and marketing that led to its eventual sale to SolarWinds.

Come meet me on Google+ or LinkedIn today!