I'm running fail2ban to attempt to block malicious brute-force password dictionary attacks against ssh. They seem to be rolling through a block of ip addresses as the source to defeat this kind of screening, so I've set some ip addresses to be blocked in iptables. Here is the output of iptables -L (edited):
Chain INPUT (policy ACCEPT) target prot opt source destination fail2ban-VSFTPD tcp -- anywhere anywhere tcp dpt:ftp fail2ban-SSH tcp -- anywhere anywhere tcp dpt:ssh RH-Firewall-1-INPUT all -- anywhere anywhere DROP all -- 116.10.191.0/24 anywhere DROP all -- 183.136.220.0/24 anywhere DROP all -- 183.136.221.0/24 anywhere DROP all -- 183.136.222.0/24 anywhere DROP all -- 183.136.223.0/24 anywhere DROP all -- 122.224.11.0/24 anywhere DROP all -- 219.138.0.0/16 anywhere
Chain FORWARD (policy ACCEPT) target prot opt source destination RH-Firewall-1-INPUT all -- anywhere anywhere REJECT all -- anywhere anywhere reject-with icmp-ho st-prohibited
Chain OUTPUT (policy ACCEPT) target prot opt source destination
Chain RH-Firewall-1-INPUT (2 references) target prot opt source destination ACCEPT all -- anywhere anywhere ACCEPT icmp -- anywhere anywhere icmp any ACCEPT esp -- anywhere anywhere . . .
Yet in my logwatch emails, I see this, long after the iptables rules are in place to drop some ip ranges:
--------------------- pam_unix Begin ------------------------
sshd: Authentication Failures: root (116.10.191.166): 1 Time(s) root (116.10.191.167): 1 Time(s) root (116.10.191.170): 1 Time(s) root (116.10.191.173): 1 Time(s) root (116.10.191.179): 1 Time(s) root (116.10.191.182): 1 Time(s) root (116.10.191.186): 1 Time(s) root (116.10.191.199): 1 Time(s) root (116.10.191.203): 1 Time(s) root (116.10.191.211): 1 Time(s) root (116.10.191.219): 1 Time(s) root (116.10.191.223): 1 Time(s) root (116.10.191.226): 1 Time(s) root (116.10.191.228): 1 Time(s) root (116.10.191.237): 1 Time(s) <snip>
--------------------- SSHD Begin ------------------------
Failed logins from:
116.10.191.165: 4 times 116.10.191.181: 3 times 116.10.191.201: 4 times 116.10.191.207: 4 times 116.10.191.218: 4 times 116.10.191.231: 4 times 116.10.191.234: 3 times 116.10.191.235: 4 times 116.10.191.239: 4 times
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.
Why is this ip range still able to attempt connections? Have I done something wrong with my address ranges, or added them in the wrong place?
thanks, -chuck
On Mon, 2014-06-16 at 16:58 -0500, Chuck Campbell wrote:
I'm running fail2ban to attempt to block malicious brute-force password dictionary attacks against ssh.
You could:-
(1) Change the SSHD port to something obscure.
(2) Restrict access to the SSHD port, using iptables, to a group of approved IP addresses.
Regards,
On Mon, 16 Jun 2014 16:58:18 -0500 Chuck Campbell wrote:
Why is this ip range still able to attempt connections? Have I done something wrong with my address ranges, or added them in the wrong place?
Have you considered taking the opposite approach and allowing only the IP addresses that you want to allow and blocking everything else? That would be a lot easier to keep track of and manage.
I personally don't allow password logins on any of the ssh connections that I look after.
On 6/16/2014 2:58 PM, Chuck Campbell wrote:
Chain INPUT (policy ACCEPT) target prot opt source destination fail2ban-VSFTPD tcp -- anywhere anywhere tcp dpt:ftp fail2ban-SSH tcp -- anywhere anywhere tcp dpt:ssh RH-Firewall-1-INPUT all -- anywhere anywhere DROP all -- 116.10.191.0/24 anywhere DROP all -- 183.136.220.0/24 anywhere DROP all -- 183.136.221.0/24 anywhere DROP all -- 183.136.222.0/24 anywhere DROP all -- 183.136.223.0/24 anywhere DROP all -- 122.224.11.0/24 anywhere DROP all -- 219.138.0.0/16 anywhere
...
Chain RH-Firewall-1-INPUT (2 references) target prot opt source destination ACCEPT all -- anywhere anywhere ACCEPT icmp -- anywhere anywhere icmp any ACCEPT esp -- anywhere anywhere . . .
Yet in my logwatch emails, I see this, long after the iptables rules are in place to drop some ip ranges:
RH-Firewall-1-INPUT is being invoked prior to your DROP rules, and is ACCEPTing all packets.
On 06/17/2014 01:11 AM, John R Pierce wrote:
On 6/16/2014 2:58 PM, Chuck Campbell wrote:
Chain INPUT (policy ACCEPT) target prot opt source destination fail2ban-VSFTPD tcp -- anywhere anywhere tcp dpt:ftp fail2ban-SSH tcp -- anywhere anywhere tcp dpt:ssh RH-Firewall-1-INPUT all -- anywhere anywhere DROP all -- 116.10.191.0/24 anywhere DROP all -- 183.136.220.0/24 anywhere DROP all -- 183.136.221.0/24 anywhere DROP all -- 183.136.222.0/24 anywhere DROP all -- 183.136.223.0/24 anywhere DROP all -- 122.224.11.0/24 anywhere DROP all -- 219.138.0.0/16 anywhere
How did you added these rules? using manual command line tools or automatically by fail2ban?
Eliezer
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
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@centos.org 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
On 6/17/2014 19:35, Chuck Campbell wrote:
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.
So increase the fail2ban time from the default (5 minutes, as I recall) to 1 hour, or 1 day.
Besides, just because the odds are against you, sometimes luck is all it takes.
That sort of thinking is why governments have started to levy taxes on people who are bad at math. (i.e. lotteries)
Some risks simply aren't worth worrying about.
Go play with the haystack calculator I linked from my previous email. If 8 random printable ASCII characters doesn't make you sleep well at night, make it nine. Now the attack space is about 2 orders of magnitude larger. If the risk with 8 was "sometime in my career, which cannot stand a single breach," the risk with 9 becomes "sometime after I have shuffled off this mortal coil."
-
Always Learning -
Chuck Campbell -
Eliezer Croitoru -
Frank Cox -
John R Pierce -
Warren Young