Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question
add comment

11 Answers

up vote 12 down vote accepted

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:

dJ&3${bs2ujc"qX
share|improve this answer
    
How would fail2ban help against a botnet? –  innaM May 29 '09 at 20:34
2  
the only issue you'll have is that nobody can remember their passwords.. –  Jeff Atwood Jul 21 '09 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 '09 at 11:44
add comment

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.

share|improve this answer
add comment

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"

share|improve this answer
add comment

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.

share|improve this answer
3  
Why not pick a password the attacker has already tried? Just kidding. –  innaM May 29 '09 at 20:35
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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:

http://www.lockdown.co.uk/?pg=combi

http://en.wikipedia.org/wiki/Password_cracking

share|improve this answer
add comment

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.

share|improve this answer
add comment

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

http://project-rainbowcrack.com/table.htm

share|improve this answer
    
Only useful if they get the password hashes though, and with proper salting, the threat can be lessened. –  skitzot33 Jun 2 '09 at 12:48
add comment

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

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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