My client has a server that is being subjected to brute-force login attempts from a botnet. Due to the vagaries of the server and the client's client, we can't easily block the attempts through a firewall, port change, or login account name change.

The decision has been made to leave it open to attack, but find a method of keeping the password secure. Management and some of the other consultants have determined that the best thing to do is to install password rotation software to rotate the password every ten minutes and provide the new password to users that need to log in.

The brute force attempts are occurring twice every second.

I need to demonstrate that implementing a strong password with 12-15 characters is an easier and free solution. I know how to prove this with math, but I'd just be writing something like "there are x many possible permutations of our password, and the attacker can only try n attempts per day, thus we'd expect them to go x/2n days on average before they guess our password." Is there a more standard "proof" of this?

11 Answers 11


Using fail2ban with the iptables is a great way.

Here is the math for you:

Mixed upper and lower case alphabet and common symbols, 8 characters long, gives you 2.9 quadrillion conbinations and with 10,000 attempts a second will take 9,488 years. Thats the maximum of course - expect your password to be cracked in 4000 years. 1000 years if you're not feeling lucky.

As you can see you shouldn't have any issues if you do a 15 character password like:

  • How would fail2ban help against a botnet?
    – innaM
    May 29, 2009 at 20:34
  • 2
    the only issue you'll have is that nobody can remember their passwords.. Jul 21, 2009 at 8:53
  • That is a really interesting link, but I have noticed (at the bottom of the page) that their attack times are based around Pentium 100s! Perhaps a little out of date now, but still a good read.
    – Coops
    Jul 21, 2009 at 11:44

In addition to fail2ban,

If you're running any modern UNIX, you can generally change the bad password entry sleep time to up to 5 seconds, slowing the attack speed by 2000%. [Solaris 10 has it in /etc/default/login, search for SLEEPTIME] Which using the same tolerances would mean you could rotate the password every 3hrs 20 minutes.

Also, password tries before lockout would be a viable option, but I suspect it is not for you because you have multiple users sharing one account and do not want it locked out all the time.

Requiring a 12-15 character password helps, but if you are continually being attacked another solution is probably better. I don't know what your company's budget tolerance on this is, but RSA key cards for everyone who needs to log into that account would solve it as well. Two factor authentication pushes the probability out into quantum computing time.

The brute force approach going on long enough for you to post on this board is pretty surprising. Generally speaking it's pretty lowbrow and at best is a log filler while a real attack is going on.


How about an appeal to authority? You could reference the DoD Security Technical Implementation Guidelines (iase.disa.mil/stigs/stig) and say "If it's good enough for the Defense Department, it's good enough for us"


Something to consider: if you have a password that doesn't change, and the brute force attacks are testing a universe of passwords that includes yours, the brute force attack is guaranteed to hit eventually and you will remain vulnerable after that.

The "chance" that a random pick will hit your password can be calculated, as you've suggested, but that may not tell the whole story.

If you look at the brute force attempts, for example, and see that the longest password they try is 10 characters, picking anything at 12 will ensure you will never get hit.

Be very careful when trying to apply statistics to a particular case; they only predict the overall behavior with a large number of samples.

That aside, if the mathematics don't (or can't) convince someone, try to find something that has about the same chance of occurring but is familiar, like perhaps lotteries or car accidents or struck by lightning. If you can say "the chance of someone hitting this password is about the same as winning the lottery six weeks running" it may give them a better feel.

  • 3
    Why not pick a password the attacker has already tried? Just kidding.
    – innaM
    May 29, 2009 at 20:35

One thing that hasn't been considered is what username the botnet is using to Bruteforce. In all the instances I've seen the brute forces have been for variations of admin and root, and in one rare case usernames scraped from the corp website.

I'd also change the interactive login restrictions so that your root account is either disabled (preferred) or restricted to your local subnet or similar address range.


Twice per second is not bad. We used to see thousands of attempts per minute, before implementing fail2ban, which will lock a particular IP out of the network for a set amount of time after so many failed attempts (all configurable).

This has worked great for us.


Actually, you can selective scan against brute force ssh attacks using iptables, if this works for you.

These two strings:

iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -m recent --set --name sshscans 
iptables -A INPUT -m recent --rcheck --seconds 60 --hitcount 5 --name sshscans --rsource -j DROP 

will block access to anyone who tries to connect to SSH more than 5 times in a 60 second interval. You can change the "--hitcount" number if you want a bigger number than 5 per second to be allowed.


I agree that changing the password every 10 minutes seems a bit excessive. At this point the problem becomes how do you securely transmit the new password and keep the systems in sync with one another.

This article has some interesting statistics about cracking speeds:




It's surprising how many people don't understand exponential curves, but everybody knows the difference between 10, 100, and 1000, so that might be a good place to start making comparisons.

Another tactic might be to actually show people how long it takes to brute-force a 6 character password. If you have any programming knowledge, you can put together a quick tool that does this.


You could also show them how easily available rainbow tables are:


  • Only useful if they get the password hashes though, and with proper salting, the threat can be lessened.
    – skitzot33
    Jun 2, 2009 at 12:48

This may be a bit offtopic, but I'm using denyhosts and it's greatly reduced brute force attempts on my Linux boxes.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.