[CentOS] iptables question

[Warren Young]

On 6/16/2014 15:58, Chuck Campbell wrote:
> If they keep going through this ip block, they will still get 255 attempts at
> the root password and 1020 attempts at other login/password combinations before
> they are blocked by fail2ban.

I'm glad you got your firewall problem sorted out, but I can't let this 
comment slide.

If removing a thousand possibilities from the pool of available 
credentials puts your servers at significant risk, your passwords are 
too weak.

Let's say you're using 12-character alphanumeric passwords, mixed case, 
no symbols, 3/4 alphabetic.  That gives a search space of 3.28 x 10^21 
possible passwords.[1]  Knocking off 1,000 passwords on each pass means 
you need 3.28 x 10^18 passes to explore all options.  Since there are 
only 3.7 x 10^9 public IPv4 addresses, total,[2] that means if every 
single public machine (or NAT) on the Internet were gathered into a 
massive zombie net, the chance of them cracking one of your passwords is 
1 in a billion.  My state lottery offers better odds.

And we haven't even added symbols yet.

"But," I hear you say, "fail2ban doesn't ban an IP forever."  True. 
What it does is greatly stretch out the time between hammer blows, above 
that of ssh's own attack mitigation timers.

Let's say you set the ban expiration time to 5 minutes.  Let's also say 
you really annoyed someone, so they rent time on a 1 million machine 
zombie net, just to try and break into your server.  Let's also say they 
focus their entire attack on a single account, rather than guess user 
names as well as passwords, as is common for SSH crackbots.

The zombie net factor drops the 10^18 pass count magnitude above to the 
order of 10^12.  10^12 * 5 minutes is about 10 million years.

If you start using pre-shared keys and configure sshd to accept keys 
only,[3] you turn lottery odds into astronomical odds.  The twelve 
character passwords above have about 71 bits of entropy, if you pick 
them randomly.  A generated SSH key is as close to random as you're 
likely to get, and it will have a *minimum* of 1,024 bits of entropy. 
Every bit of entropy doubles the required attack time, so you turn 10^9 
into 10^ridiculous.  (Well known exponent in number theory, that.)

What if we're willing to settle for human time scales, rather than 
astronomical ones?  Using the information above, I have come to the 
realization that if I can hold off the crackbot hordes for just another 
100 years, I can stop caring about the risks, on account of the fact 
that I expect someone else will be taking care of my remaining CentOS 3 
servers by then, and they will change the passwords shortly after 
handover.  It turns out that 8 random lowercase letters is sufficient to 
buy me those 100 years.  I can then go play Tetris in my centenarian 
dotage without a care for the security of my old Linux boxen.

So, unless your passwords are weaker than 8 lowercase random letters, 
you're literally wasting time manually banning IPs.  Let fail2ban do its 
job, while you go off and do something a dumb computer can't.

I've used fail2ban myself, but only to cut down on log noise, not 
because it adds any real security.  In the end, I've found that moving 
ssh to a nonstandard port is just as effective at reducing log noise.




[1] https://www.grc.com/haystack.htm
[2] http://goo.gl/7LtFvE
[3] http://goo.gl/02oksG