Linux Netfilter discussions
 help / color / mirror / Atom feed
* Hot to design syn-flood protection based on ip ?
@ 2009-08-27 12:36 J. Bakshi
  2009-09-01  6:28 ` J. Bakshi
  0 siblings, 1 reply; 6+ messages in thread
From: J. Bakshi @ 2009-08-27 12:36 UTC (permalink / raw)
  To: netfilter

Hello list,

I have finally  come to know the bad effect of syn-flood protection.

``````````````````````
iptables -N syn-flood
iptables -A INPUT -i $IFACE -p tcp --syn -j syn-flood
iptables -A syn-flood -m limit --limit 1/s --limit-burst 4 -j RETURN
iptables -A syn-flood -j DROP
```````````````````````````

The codes above drops the packets blindly if a single host initiate a
syn-flood and as a result other hosts can't get the ports.  Is there a
way to modify the rules so it drop the packets from the host which is
sending the syn-flood packets ?

eagerly waiting for a response.
Thanks

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Hot to design syn-flood protection based on ip ?
  2009-08-27 12:36 Hot to design syn-flood protection based on ip ? J. Bakshi
@ 2009-09-01  6:28 ` J. Bakshi
  2009-09-01  6:58   ` Marek Kierdelewicz
  0 siblings, 1 reply; 6+ messages in thread
From: J. Bakshi @ 2009-09-01  6:28 UTC (permalink / raw)
  To: netfilter

J. Bakshi wrote:

Any clue ?


> Hello list,
>
> I have finally  come to know the bad effect of syn-flood protection.
>
> ``````````````````````
> iptables -N syn-flood
> iptables -A INPUT -i $IFACE -p tcp --syn -j syn-flood
> iptables -A syn-flood -m limit --limit 1/s --limit-burst 4 -j RETURN
> iptables -A syn-flood -j DROP
> ```````````````````````````
>
> The codes above drops the packets blindly if a single host initiate a
> syn-flood and as a result other hosts can't get the ports.  Is there a
> way to modify the rules so it drop the packets from the host which is
> sending the syn-flood packets ?
>
> eagerly waiting for a response.
> Thanks
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>   


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Hot to design syn-flood protection based on ip ?
  2009-09-01  6:28 ` J. Bakshi
@ 2009-09-01  6:58   ` Marek Kierdelewicz
  2009-09-01  7:38     ` J. Bakshi
  0 siblings, 1 reply; 6+ messages in thread
From: Marek Kierdelewicz @ 2009-09-01  6:58 UTC (permalink / raw)
  To: J. Bakshi; +Cc: netfilter

Hello,

>Any clue ?

You're on the right track. Just use "hashlimit" module instead of
"limit".Use option "--hashlimit-mode srcip". All necessary info is in
iptables manpage.

Best regards,
Marek

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Hot to design syn-flood protection based on ip ?
  2009-09-01  6:58   ` Marek Kierdelewicz
@ 2009-09-01  7:38     ` J. Bakshi
  2009-09-01  8:12       ` Marek Kierdelewicz
  0 siblings, 1 reply; 6+ messages in thread
From: J. Bakshi @ 2009-09-01  7:38 UTC (permalink / raw)
  To: Marek Kierdelewicz; +Cc: netfilter

Marek Kierdelewicz wrote:
> Hello,
>
>   
>> Any clue ?
>>     
>
> You're on the right track. Just use "hashlimit" module instead of
> "limit".Use option "--hashlimit-mode srcip". All necessary info is in
> iptables manpage.
>   

Thanks a lot, what about this ruleset ?

iptables -A INPUT -p tcp --syn  -m hashlimit \
 --hashlimit 1/sec --hashlimit-burst 4 --hashlimit-htable-expire 300000 \
--hashlimit-mode srcip --hashlimit-name testlimit -j ACCEPT
 
iptables -A INPUT -j DROP

The concept here the blocked ip doing the syn-flood will be blacklisted
for 5 min and will be checked again after that interval.


> Best regards,
> Marek
>
>   


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Hot to design syn-flood protection based on ip ?
  2009-09-01  7:38     ` J. Bakshi
@ 2009-09-01  8:12       ` Marek Kierdelewicz
  2009-09-01  8:50         ` J. Bakshi
  0 siblings, 1 reply; 6+ messages in thread
From: Marek Kierdelewicz @ 2009-09-01  8:12 UTC (permalink / raw)
  To: J. Bakshi; +Cc: netfilter

Hello,

>Thanks a lot, what about this ruleset ?
>iptables -A INPUT -p tcp --syn  -m hashlimit \
> --hashlimit 1/sec --hashlimit-burst 4 --hashlimit-htable-expire 300000
>\ --hashlimit-mode srcip --hashlimit-name testlimit -j ACCEPT
>iptables -A INPUT -j DROP
>The concept here the blocked ip doing the syn-flood will be blacklisted
>for 5 min and will be checked again after that interval.

I think it won't work as a blacklist just drop syns that are above
1/sec. Option htable-expire is not for blacklisting but for setting
timeframe in which hashlimit is operating (eg. it won't work well if you
set htable-expire to 300s and have hashlimit set to 20/hour). To obtain
desired effect you can use recent module (great work by Stephen Frost
by the way):

iptables -A INPUT -m recent --name blacklist --rcheck --seconds 300 \
-j DROP
iptables -A INPUT -p tcp --syn  -m hashlimit \
 --hashlimit 1/sec --hashlimit-burst 4 --hashlimit-htable-expire 300000\
 --hashlimit-mode srcip --hashlimit-name testlimit -j ACCEPT
iptables -A INPUT -m recent --name blacklist --set -j DROP

You can find more information about recent here:
- http://snowman.net/projects/ipt_recent/
- and in manpage;

Best regards,
Marek

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Hot to design syn-flood protection based on ip ?
  2009-09-01  8:12       ` Marek Kierdelewicz
@ 2009-09-01  8:50         ` J. Bakshi
  0 siblings, 0 replies; 6+ messages in thread
From: J. Bakshi @ 2009-09-01  8:50 UTC (permalink / raw)
  To: Marek Kierdelewicz; +Cc: netfilter

Marek Kierdelewicz wrote:
> Hello,
>
>   
>> Thanks a lot, what about this ruleset ?
>> iptables -A INPUT -p tcp --syn  -m hashlimit \
>> --hashlimit 1/sec --hashlimit-burst 4 --hashlimit-htable-expire 300000
>> \ --hashlimit-mode srcip --hashlimit-name testlimit -j ACCEPT
>> iptables -A INPUT -j DROP
>> The concept here the blocked ip doing the syn-flood will be blacklisted
>> for 5 min and will be checked again after that interval.
>>     
>
> I think it won't work as a blacklist just drop syns that are above
> 1/sec. Option htable-expire is not for blacklisting but for setting
> timeframe in which hashlimit is operating (eg. it won't work well if you
> set htable-expire to 300s and have hashlimit set to 20/hour). To obtain
> desired effect you can use recent module (great work by Stephen Frost
> by the way):
>
> iptables -A INPUT -m recent --name blacklist --rcheck --seconds 300 \
> -j DROP
> iptables -A INPUT -p tcp --syn  -m hashlimit \
>  --hashlimit 1/sec --hashlimit-burst 4 --hashlimit-htable-expire 300000\
>  --hashlimit-mode srcip --hashlimit-name testlimit -j ACCEPT
> iptables -A INPUT -m recent --name blacklist --set -j DROP
>
> You can find more information about recent here:
> - http://snowman.net/projects/ipt_recent/
> - and in manpage;
>
> Best regards,
> Marek
>   

Dear Marek,

millions and millions of thanks to you. You have provided the solution
which I was searching since looong.  a syn-flood protection along with
IP-blacklist ( psad style arrangement) is something which I love to have
in my servers.   I think I can modify my DROP rules where ever required
to pass it through blacklist as

````````````````````
iptables -A INPUT -m recent --name blacklist --set -j DROP
 ``````````````````````

and place

`````````````
iptables -A INPUT -m recent --name blacklist --rcheck --seconds 300 -j DROP

```````````````

at the beginning of my firewall rule set.

A great learning for me.
Marek once again thanks a lot.


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2009-09-01  8:50 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-08-27 12:36 Hot to design syn-flood protection based on ip ? J. Bakshi
2009-09-01  6:28 ` J. Bakshi
2009-09-01  6:58   ` Marek Kierdelewicz
2009-09-01  7:38     ` J. Bakshi
2009-09-01  8:12       ` Marek Kierdelewicz
2009-09-01  8:50         ` J. Bakshi

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox