iptables port connection limit rule
I'm trying to secure my ssh port with iptables. So far I successfully limit one ip to connect once a minute:
iptables -A INPUT -p tcp --dport 22 -i eth1 -m state --state NEW -m recent --set iptables -A INPUT -p tcp --dport 22 -i eth1 -m state --state NEW -m recent --update --seconds 60 --hitcount 2 -j DROP How would I add a rule that limits the total number of connections to 10, on port 22? |
Quote:
BTW, what you posted isn't limiting to 1/minute, it's limiting to 2/minute: Code:
[!] --hitcount hits |
To clarify, I want two rules:
1) A connection to port 22 can only be made once every 60 seconds per IP. Edit* 2) There can only be 10 new connections to port 22 every 5 minutes, regardless of IP. The original two iptables lines I listed enforce rule 1), look here for reference: http://www.debian-administration.org/articles/187. I'm trying to build rule 2). I don't want rule 2) to be based on IP, I just want to allow 10 connections from any number of IPs at once to port 22. Thanks for the suggestion but it's actually another way of building rule 1). |
Quote:
Quote:
|
I looked around and people were saying the --limit and --limit-burst would limit concurrent connections, no matter the IP. I only have two comps so I haven't tested it out on multiple machines yet- it works against one.
iptables -A INPUT -p tcp --dport 22 -i eth1 -m state --state NEW -m recent --set iptables -A INPUT -p tcp --dport 22 -i eth1 -m state --state NEW -m recent --update --seconds 60 --hitcount 2 -j DROP iptables -A INPUT -p tcp --dport 22 -i eth1 -m limit --limit 1/minute --limit-burst 10 -j ACCEPT I would rather have the --limit rule first, but I haven't found a way for it to say, "continue to the next rule if true, drop if false". Then if someone does a DDOS attack with a big botnet the packets will get dropped before going through two rules. Ideally: iptables -A INPUT -p tcp --dport 22 -i eth1 -m limit --limit 1/minute --limit-burst 10 -j "continue to the next rule if true, drop if false" iptables -A INPUT -p tcp --dport 22 -i eth1 -m state --state NEW -m recent --set iptables -A INPUT -p tcp --dport 22 -i eth1 -m state --state NEW -m recent --update --seconds 60 --hitcount 2 -j DROP iptables -A INPUT -p tcp --dport 22 -i eth1 -m state --state NEW -j ACCEPT |
Quote:
Quote:
Using the example you posted as a base, it might look something like this: Code:
iptables -N SSH_PROTECT |
Yes perfect thats exactly what I needed, thanks.
|
Quote:
Code:
iptables -N SSH_PROTECT Code:
iptables -N SSH_PROTECT |
I'm assuming when you say filter improper syns in your DROP rule, you could also say allow proper syns with an ACCEPT rule (--syn instead of ! --syn).
iptables -A INPUT -p tcp --dport 22 -i eth1 --syn -m state --state NEW -m limit --limit 20/minute --limit-burst 10 -j SSH_PROTECT I already configured the firewall with syn cookies, this link was useful: http://www.tty1.net/blog/2007-02-06-...rewall_en.html. I just hope sockstress isn't leaked... |
Yeah, you could do it that way too. The way I posted is just personal preference.
Glad to hear you're issuing SYN cookies already. |
Now that I think a bit more about your configuration, the cookies only stop the caveman from exploiting your recent match rules in order to DoS attack you. With the way the rules are currently laid-out, the caveman would still be able to exploit your limit match rule and have you under DoS in the blink of an eye (and he wouldn't need to spoof any IPs to do it).
|
Yeah that's right, cause syn attacks can be issued on any port and that rule is limited to port 22. I now added input and forward rules for it.
iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP iptables -A FORWARD -p tcp ! --syn -m state --state NEW -j DROP |
Quote:
|
Theoretically speaking, this DoS vulnerability can be eliminated by inversing the order in which the checks are being applied in the above rules. In other words, you instead use recent first to check that the IP isn't sending more SYNs than you allow per individual IP, and if that check is passed, then limit is used to check that the ceiling you've set for IPs in total hasn't been broken. If both checks are passed (in that order) then the packet gets sent to ACCEPT. This way if the bad guy tries to trigger the limit rule to put you under DoS, he won't even be able to get that far, as he'll get smacked down by the recent rule.
|
Ok, the packets would trigger the limit rule because they wouldn't get blocked by the IP block rule, which is in the SSH_PROTECT chain.
Your idea of reording the rules makes sense to me. I think I'd rather keep those two ! --syn DROP rules at the beginning of the input and forward tables though. That way it will apply to all subsequent rules and I won't have to worry about --syn being in the wrong place in a rule. |
All times are GMT -5. The time now is 05:02 AM. |