LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices


Reply
  Search this Thread
Old 10-05-2008, 04:29 PM   #1
Shwick
Member
 
Registered: Jun 2008
Posts: 111

Rep: Reputation: 15
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?
 
Old 10-05-2008, 07:48 PM   #2
win32sux
LQ Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 380Reputation: 380Reputation: 380Reputation: 380
Quote:
Originally Posted by Shwick View Post
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?
I know you could use the connlimit match to restrict the number of concurrent connections, but I think it can only be made to work on a per subnet basis (not in total). I'm not sure about that, though, so maybe you should still look into it and see. If you have a really modern version of OpenSSH (I don't), the MaxSessions parameter might satisfy your needs AFAICT.

BTW, what you posted isn't limiting to 1/minute, it's limiting to 2/minute:
Code:
       [!] --hitcount hits
              This  option must be used in conjunction with one of --rcheck or
              --update. When used, this will narrow the match to  only  happen
              when  the  address  is in the list and packets had been received
              greater than or equal to the given value.  This  option  may  be
              used  along  with  --seconds  to  create  an even narrower match
              requiring a certain number of hits within a specific time frame.

Last edited by win32sux; 10-05-2008 at 07:51 PM.
 
Old 10-06-2008, 08:25 PM   #3
Shwick
Member
 
Registered: Jun 2008
Posts: 111

Original Poster
Rep: Reputation: 15
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).

Last edited by Shwick; 10-06-2008 at 08:53 PM.
 
Old 10-06-2008, 09:13 PM   #4
win32sux
LQ Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 380Reputation: 380Reputation: 380Reputation: 380
Quote:
Originally Posted by Shwick View Post
The original two iptables lines I listed enforce rule 1), look here for reference: http://www.debian-administration.org/articles/187.
I haven't read the article you've linked, but I did some TCP SYN scan tests with nmap and they confirm that you're absolutely right. My bad.

Quote:
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).
Actually, I understand that part. That's why I mentioned that even though I know connlimit would let you do this per subnet, I wasn't sure if it had the option to do it "in total" (or for all subnets/IPs). I honestly wouldn't be surprised if it did have a way to say "any IP" - but I don't know if it does. I look forward to seeing how you end up achieving this with iptables, though, because I'd like to learn how to do it too. Good luck.

Last edited by win32sux; 10-06-2008 at 09:15 PM.
 
Old 10-06-2008, 11:46 PM   #5
Shwick
Member
 
Registered: Jun 2008
Posts: 111

Original Poster
Rep: Reputation: 15
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
 
Old 10-07-2008, 04:38 PM   #6
win32sux
LQ Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 380Reputation: 380Reputation: 380Reputation: 380
Quote:
Originally Posted by Shwick View Post
I looked around and people were saying the --limit and --limit-burst would limit concurrent connections, no matter the IP
Well, they can stop the connections from being started within the timeframe, yes.

Quote:
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".
You could put the recent rules in a separate chain, and have the limit rule jump to it when TRUE.

Using the example you posted as a base, it might look something like this:
Code:
iptables -N SSH_PROTECT

iptables -A INPUT -p tcp --dport 22 -i eth1 -m state --state NEW \
-m limit --limit 1/minute --limit-burst 10 -j SSH_PROTECT

iptables -A SSH_PROTECT -m recent --set

iptables -A SSH_PROTECT -m recent --update --seconds 60 --hitcount 2 -j DROP

iptables -A SSH_PROTECT -j ACCEPT
Notice that you don't need any protocol, interface, port, or state matches in the SSH_PROTECT rules, as they would be redundant. Also, packets which don't match the limit rule wouldn't get sent to SSH_PROTECT, so they would be dealt with either by some matching rule further down the INPUT chain, or by whatever the INPUT chain's policy is set to (if there were no other matching rules).

Last edited by win32sux; 10-07-2008 at 04:59 PM.
 
Old 10-07-2008, 09:30 PM   #7
Shwick
Member
 
Registered: Jun 2008
Posts: 111

Original Poster
Rep: Reputation: 15
Yes perfect thats exactly what I needed, thanks.
 
Old 10-09-2008, 05:03 PM   #8
win32sux
LQ Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 380Reputation: 380Reputation: 380Reputation: 380
Quote:
Originally Posted by Shwick View Post
Yes perfect thats exactly what I needed, thanks.
You're very welcome. BTW, remember to enable TCP SYN cookies when doing stuff like this otherwise even a caveman could have you under denial-of-service attack if they know the IP you (or any other client) will be connecting from. And when you do so, make sure you filter any TCP packets in state NEW which aren't proper SYNs, like:
Code:
iptables -N SSH_PROTECT

iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

iptables -A INPUT -p tcp --dport 22 -i eth1 -m state --state NEW \
-m limit --limit 1/minute --limit-burst 10 -j SSH_PROTECT

iptables -A SSH_PROTECT -m recent --set

iptables -A SSH_PROTECT -m recent --update --seconds 60 --hitcount 2 -j DROP

iptables -A SSH_PROTECT -j ACCEPT
Or if you only want it to apply to this SSH stuff then:
Code:
iptables -N SSH_PROTECT

iptables -A INPUT -p tcp --dport 22 -i eth1 ! --syn -m state --state NEW -j DROP

iptables -A INPUT -p tcp --dport 22 -i eth1 -m state --state NEW \
-m limit --limit 1/minute --limit-burst 10 -j SSH_PROTECT

iptables -A SSH_PROTECT -m recent --set

iptables -A SSH_PROTECT -m recent --update --seconds 60 --hitcount 2 -j DROP

iptables -A SSH_PROTECT -j ACCEPT

Last edited by win32sux; 10-09-2008 at 05:10 PM.
 
Old 10-09-2008, 06:37 PM   #9
Shwick
Member
 
Registered: Jun 2008
Posts: 111

Original Poster
Rep: Reputation: 15
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...
 
Old 10-09-2008, 06:45 PM   #10
win32sux
LQ Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 380Reputation: 380Reputation: 380Reputation: 380
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.
 
Old 10-09-2008, 07:07 PM   #11
win32sux
LQ Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 380Reputation: 380Reputation: 380Reputation: 380
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).

Last edited by win32sux; 10-09-2008 at 07:17 PM.
 
Old 10-09-2008, 07:36 PM   #12
Shwick
Member
 
Registered: Jun 2008
Posts: 111

Original Poster
Rep: Reputation: 15
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
 
Old 10-09-2008, 07:43 PM   #13
win32sux
LQ Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 380Reputation: 380Reputation: 380Reputation: 380
Quote:
Originally Posted by Shwick View Post
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.
No, that's not the reason. This isn't about a SYN flood. It's about exploiting your limit rule to get you under DoS. You see, the SYN cookies prevent the bad guy from sending SYN packets with spoofed source IPs (your IP or your other clients') to activate the recent match and lock you out of your box. But the cookies have zero effect for the limit rule, as those matches will be triggered regardless. So the bad guy simply sends SYN packets to you at a rate higher than the limit, and neither you or any of your clients will be able to connect.

Last edited by win32sux; 10-09-2008 at 07:48 PM.
 
Old 10-09-2008, 08:05 PM   #14
win32sux
LQ Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 380Reputation: 380Reputation: 380Reputation: 380
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.
 
Old 10-09-2008, 08:09 PM   #15
Shwick
Member
 
Registered: Jun 2008
Posts: 111

Original Poster
Rep: Reputation: 15
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
iptables nat port forwarding rule set crowhurst01 Linux - Networking 2 02-13-2012 03:39 AM
iptables: rule with RETURN target just after a rule with ACCEPT target Nerox Linux - Networking 6 09-04-2011 03:33 PM
iptables port 80 rule Q doronunu Linux - Security 3 06-04-2006 06:55 PM
Limit incoming smtp connection by ip using iptables lynksinc Linux - Security 4 11-03-2005 12:27 PM
proftpd (Router port change and limit login rule) icehenge Slackware 2 03-07-2005 03:23 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Security

All times are GMT -5. The time now is 02:27 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration