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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
