On 6/17/2014 6:39 PM, Warren Young wrote:
> 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
>
I concur with all you've said, and I haven't done the load stats, but it appears
to me that a hundred of these crackers hitting my machine at these rates is
likely to deny my legit users some resources. That is still a concern, but I've
already seen that 20 banned ip ranges out of china has dropped the incidence
from about 100 to 3.
That's worth the effort to gain a better understanding of iptables in managing
my servers anyway. I've noticed (unquantified) a bit better login response and
interactive response without the resource drain, unless I'm just imagining it...
Besides, just because the odds are against you, sometimes luck is all it takes.
I'm looking into the shared keys approach, so I can do away with passwords.
thanks,
-chuck
--
ACCEL Services, Inc.| Specialists in Gravity, Magnetics | (713)993-0671 ph.
| and Integrated Interpretation | (713)993-0608 fax
448 W. 19th St. #325| Since 1992 | (713)306-5794 cell
Houston, TX, 77008 | Chuck Campbell | campbell@xxxxxxxxxxxx
| President & Senior Geoscientist |
"Integration means more than having all the maps at the same scale!"
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
