(2) Restrict access to the SSHD port, using iptables, to a group of approved IP addresses.
Regards,
20 thoughts on - Iptables Question
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.
RH-Firewall-1-INPUT is being invoked prior to your DROP rules, and is ACCEPTing all packets.
How did you added these rules?
using manual command line tools or automatically by fail2ban?
Eliezer
Are you series??
There are applications that fail2ban offers them things which others just can’t..
If you can email me the ip for your servers and also the root password and allow me in your INPUT all over the place I will leave you a message in the server.(hope you understand jokes)
All The Bests, Eliezer
[previous article hasn’t appeared on gmane yet]
Indeed, fail2ban and their ilk (e.g. my new favorite, sshguard) modify iptables rules in response to excessive failed login attempts. A
”proper firewall” with just static iptables rules can’t do that. And with so many pwn3d hosts out there being used to bounce attacks off of, it is foolish to rely on static rules alone to fend off these attacks.
Much better of course are static firewall rules that blocks off all but a few whitelisted hosts. But that is much less flexible for users.
–keith
All of the suggestions are graciously accepted, however, I was actually asking what I was doing wrong with iptables, and why, with the rules I put in place, someone was still able to connect to my machine.
I understand there might be better ways, but if I don’t understand what I did wrong last time, how am I going to figure out how to deny all, then allow selected, ehrn I can’t seem to allow all and deny selected.
There must be a misunderstanding on my part about how iptables are supposed to work.
-chuck
As John R Pierce mentioned one of your first rule in the chain is
“RH-Firewall-1-INPUT all — anywhere anywhere”, this simply mean everything with “DROP” after it will be ignored. iptables will work its way down the chain, therefore you have to options
1. remove that line or
2. move it at the bottom of the chain.
I am clearly missing some emails, because I didn’t see a reply from John R
Pierce. My apologies. I appreciate you restating this. I’ll try to go make sense of iptables, given the insight,
thanks,
-chuck
OK, I went to the list archive and found the email in question. Also, one after it that asked how I added these rules.
I ran a script after fail2ban was started. It looks like this:
#!/bin/sh iptables -A INPUT -s 116.10.191.0/24 -j DROP
iptables -A INPUT -s 183.136.220.0/24 -j DROP
iptables -A INPUT -s 183.136.221.0/24 -j DROP
iptables -A INPUT -s 183.136.222.0/24 -j DROP
iptables -A INPUT -s 183.136.223.0/24 -j DROP
iptables -A INPUT -s 122.224.11.0/24 -j DROP
iptables -A INPUT -s 219.138.0.0/16 -j DROP
so, how do I get them in front of the RH-Firewall-1-INPUT, or do I add them to that chain?
-chuck
use -I (insert) rather than -A (append).
OR
specify chain RH-Firewall-1-INPUT rather than INPUT
OR, better
use system-config-firewall rather than running your own iptables commands. this manages the rules used by the RH firewall scripts invoked by the iptables service which is run at boot time.
also, if you do manually add iptables rules, you can use `service iptables save` to remember these changes, instead of running them from your own scripts. these changes get saved to /etc/sysconfig/iptables
Keep in mind that there are three default chains, INPUT, OUTPUT and FORWARD
that are used to initiate the packet path through IPTABLES and that they are mutually exclusive. INPUT deals ONLY with packets that arrive from off of AND
are destined for the host running IPTABLES. OUTPUT deals only with packets that originate from the host running IPTABLES regardless of where they are destined. And FORWARD deals only with packets that arrive from and are destined off of the host running IPTABLES. A packet starts in only one of these based solely on its origin/destination pairing and it does not cross over automatically into either of the others. For example, if a forwarded packet is detected then the INPUT and OUTPUT chains are not used at all.
I have seen chain misconfiguration where IPTABLES rules evidently assume that a packet is to pass from the INPUT chain or the OUTPUT chain to the FORWARD
chain automatically. In some cases it seems that the rules writer has implicitly assumed that INPUT -> FORWARD -> OUTPUT is the default routing of all packet paths. This is not the case and it does not happen unless the other chain is specifically called from within the originating chain.
My practice is to place general rules that I wish to apply to all packets, regardless of source or destination, into a chain called GENERAL and simply call that chain as the last instruction in each of the default chains. Actually I put very little else in the default chains and route from the GENERAL chain to other chains dedicated to specific rule sets, like for port knocking (FWKNOP_ALLOW); or for assured access (ALWAYS_ALLOW); or for blacklists: ALWAYS_DENY and FAIL2BAN_DENY for example.
I used the RH-Firewall-1-INPUT chain, and -I, defaulting to position 1, and all is working as I had anticipated.
It is working as expected, killing all of those rolling ip attempts. I was loathe to use system-config-firewall, because I wasn’t sure it wouldn’t drop something I needed, or forgot to include, and it would have wiped out the existong ruleset. I’ll experiment with that when I am physically in front of the server, instead of remote from it. I would have had no quick remedy if I messed it up.
Thanks you for the clear concise explanation.
-chuck
thats why all my servers have remote consoles :)
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.
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
So increase the fail2ban time from the default (5 minutes, as I recall)
to 1 hour, or 1 day.
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.”
Would someone please explain to me the difference in effect between the following two IPTABLES conditions and the significance thereof in concurrent connection limiting?
–tcp-flags SYN,ACK,FIN,RST SYN -j REJECT \
–connlimit-above 3 –connlimit-mask 32
–state NEW -j REJECT \
–connlimit-above 3 –connlimit-mask 32
James B. Byrne writes:
Your first example will review only TCP packets and ensure out of SYN,ACK,FIN, and RST the only flag set is SYN (it doesn’t care about the URG
flag).
The –state NEW example on the other hand matches ANY new packet. This will capture protocols including OSPF, UDP, etc.. An easy way to see what it captures is to set the target to LOG:
[13982781.141620] IN= OUT=homework0 SRC2.168.254.2 DST”4.0.0.5 LEN
20 thoughts on - Iptables Question
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.
RH-Firewall-1-INPUT is being invoked prior to your DROP rules, and is ACCEPTing all packets.
How did you added these rules?
using manual command line tools or automatically by fail2ban?
Eliezer
Are you series??
There are applications that fail2ban offers them things which others just can’t..
If you can email me the ip for your servers and also the root password and allow me in your INPUT all over the place I will leave you a message in the server.(hope you understand jokes)
All The Bests, Eliezer
[previous article hasn’t appeared on gmane yet]
Indeed, fail2ban and their ilk (e.g. my new favorite, sshguard) modify iptables rules in response to excessive failed login attempts. A
”proper firewall” with just static iptables rules can’t do that. And with so many pwn3d hosts out there being used to bounce attacks off of, it is foolish to rely on static rules alone to fend off these attacks.
Much better of course are static firewall rules that blocks off all but a few whitelisted hosts. But that is much less flexible for users.
–keith
All of the suggestions are graciously accepted, however, I was actually asking what I was doing wrong with iptables, and why, with the rules I put in place, someone was still able to connect to my machine.
I understand there might be better ways, but if I don’t understand what I did wrong last time, how am I going to figure out how to deny all, then allow selected, ehrn I can’t seem to allow all and deny selected.
There must be a misunderstanding on my part about how iptables are supposed to work.
-chuck
As John R Pierce mentioned one of your first rule in the chain is
“RH-Firewall-1-INPUT all — anywhere anywhere”, this simply mean everything with “DROP” after it will be ignored. iptables will work its way down the chain, therefore you have to options
1. remove that line or
2. move it at the bottom of the chain.
I am clearly missing some emails, because I didn’t see a reply from John R
Pierce. My apologies. I appreciate you restating this. I’ll try to go make sense of iptables, given the insight,
thanks,
-chuck
OK, I went to the list archive and found the email in question. Also, one after it that asked how I added these rules.
I ran a script after fail2ban was started. It looks like this:
#!/bin/sh iptables -A INPUT -s 116.10.191.0/24 -j DROP
iptables -A INPUT -s 183.136.220.0/24 -j DROP
iptables -A INPUT -s 183.136.221.0/24 -j DROP
iptables -A INPUT -s 183.136.222.0/24 -j DROP
iptables -A INPUT -s 183.136.223.0/24 -j DROP
iptables -A INPUT -s 122.224.11.0/24 -j DROP
iptables -A INPUT -s 219.138.0.0/16 -j DROP
so, how do I get them in front of the RH-Firewall-1-INPUT, or do I add them to that chain?
-chuck
use -I (insert) rather than -A (append).
OR
specify chain RH-Firewall-1-INPUT rather than INPUT
OR, better
use system-config-firewall rather than running your own iptables commands. this manages the rules used by the RH firewall scripts invoked by the iptables service which is run at boot time.
also, if you do manually add iptables rules, you can use `service iptables save` to remember these changes, instead of running them from your own scripts. these changes get saved to /etc/sysconfig/iptables
Keep in mind that there are three default chains, INPUT, OUTPUT and FORWARD
that are used to initiate the packet path through IPTABLES and that they are mutually exclusive. INPUT deals ONLY with packets that arrive from off of AND
are destined for the host running IPTABLES. OUTPUT deals only with packets that originate from the host running IPTABLES regardless of where they are destined. And FORWARD deals only with packets that arrive from and are destined off of the host running IPTABLES. A packet starts in only one of these based solely on its origin/destination pairing and it does not cross over automatically into either of the others. For example, if a forwarded packet is detected then the INPUT and OUTPUT chains are not used at all.
I have seen chain misconfiguration where IPTABLES rules evidently assume that a packet is to pass from the INPUT chain or the OUTPUT chain to the FORWARD
chain automatically. In some cases it seems that the rules writer has implicitly assumed that INPUT -> FORWARD -> OUTPUT is the default routing of all packet paths. This is not the case and it does not happen unless the other chain is specifically called from within the originating chain.
My practice is to place general rules that I wish to apply to all packets, regardless of source or destination, into a chain called GENERAL and simply call that chain as the last instruction in each of the default chains. Actually I put very little else in the default chains and route from the GENERAL chain to other chains dedicated to specific rule sets, like for port knocking (FWKNOP_ALLOW); or for assured access (ALWAYS_ALLOW); or for blacklists: ALWAYS_DENY and FAIL2BAN_DENY for example.
Hi,
Here is a reasonable diagram that show the packet flow. http://xkr47.outerspace.dyndns.org/netfilter/packet_flow/packet_flow10.png
I used the RH-Firewall-1-INPUT chain, and -I, defaulting to position 1, and all is working as I had anticipated.
It is working as expected, killing all of those rolling ip attempts. I was loathe to use system-config-firewall, because I wasn’t sure it wouldn’t drop something I needed, or forgot to include, and it would have wiped out the existong ruleset. I’ll experiment with that when I am physically in front of the server, instead of remote from it. I would have had no quick remedy if I messed it up.
Thanks you for the clear concise explanation.
-chuck
thats why all my servers have remote consoles :)
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
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
So increase the fail2ban time from the default (5 minutes, as I recall)
to 1 hour, or 1 day.
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.”
+1
CentOS mailing list CentOS@CentOS.org http://lists.CentOS.org/mailman/listinfo/CentOS
Would someone please explain to me the difference in effect between the following two IPTABLES conditions and the significance thereof in concurrent connection limiting?
–tcp-flags SYN,ACK,FIN,RST SYN -j REJECT \
–connlimit-above 3 –connlimit-mask 32
–state NEW -j REJECT \
–connlimit-above 3 –connlimit-mask 32
James B. Byrne writes:
Your first example will review only TCP packets and ensure out of SYN,ACK,FIN, and RST the only flag set is SYN (it doesn’t care about the URG
flag).
The –state NEW example on the other hand matches ANY new packet. This will capture protocols including OSPF, UDP, etc.. An easy way to see what it captures is to set the target to LOG:
[13982781.141620] IN= OUT=homework0 SRC2.168.254.2 DST”4.0.0.5 LEN