use of -m limit for Syn Flood protection

use of -m limit for Syn Flood protection

[Brent Clark]

Hey all

In my continuous quest to understand TCP and netfilter / iptables more, I have started experimenting with rate limiting and different TCP Flags.

On my Lan I have mail server and obviously ident requests are perform etc, so I currently im trying this

# we allow 4 TCP connects per second, no more
$IPT -N syn-flood
$IPT -A syn-flood -m limit --limit 1/s --limit-burst 4 -j LOG --log-level info --log-prefix '#### Syn Flood ####'
$IPT -A syn-flood -m limit --limit 1/s --limit-burst 4 -j RETURN
$IPT -A syn-flood -j DROP

$IPT -t filter -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A FORWARD -p tcp --syn -j syn-flood

so now I get this

Oct 14 14:51:46 gate kernel: #### Syn Flood ####IN=eth1 OUT=eth0 SRC=192.168.111.11 DST=218.15.249.32 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=23007 DF PROTO=TCP SPT=40108 DPT=113 WINDOW=5840 RES=0x00 SYN 
URGP=0
Oct 14 14:51:49 gate kernel: #### Syn Flood ####IN=eth1 OUT=eth0 SRC=192.168.111.11 DST=218.15.249.32 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=23008 DF PROTO=TCP SPT=40108 DPT=113 WINDOW=5840 RES=0x00 SYN 
URGP=0
Oct 14 14:51:55 gate kernel: #### Syn Flood ####IN=eth1 OUT=eth0 SRC=192.168.111.11 DST=218.15.249.32 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=23009 DF PROTO=TCP SPT=40108 DPT=113 WINDOW=5840 RES=0x00 SYN 
URGP=0
Oct 14 14:52:07 gate kernel: #### Syn Flood ####IN=eth1 OUT=eth0 SRC=192.168.111.11 DST=218.15.249.32 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=23010 DF PROTO=TCP SPT=40108 DPT=113 WINDOW=5840 RES=0x00 SYN 
URGP=0

So my question is, have I maybe been to aggressive on the limit.

I use the -j syn-flood for both FORWARD and INPUT

Re: use of -m limit for Syn Flood protection

[Jiann-Ming Su]

On 10/14/06, Brent Clark <bclark@eccotours.co.za> wrote:
>
> # we allow 4 TCP connects per second, no more
> $IPT -N syn-flood
> $IPT -A syn-flood -m limit --limit 1/s --limit-burst 4 -j LOG --log-level info --log-prefix '#### Syn Flood ####'
> $IPT -A syn-flood -m limit --limit 1/s --limit-burst 4 -j RETURN
> $IPT -A syn-flood -j DROP
>
>
> So my question is, have I maybe been to aggressive on the limit.
>

If you're trying to limit the SYNs to 4/sec, then the --limit should
be "--limit 4/s" along with the --limit-burst 4.  Though, 4 SYNs per
second is hardly a syn flood.  Also, you may want to specify the
destination port of the syn flood to give more grainular control.
-- 
Jiann-Ming Su
"I have to decide between two equally frightening options.
 If I wanted to do that, I'd vote." --Duckman
"The system's broke, Hank.  The election baby has peed in
the bath water.  You got to throw 'em both out."  --Dale Gribble

Re: use of -m limit for Syn Flood protection

[Brent Clark]

Jiann-Ming Su wrote:
> If you're trying to limit the SYNs to 4/sec, then the --limit should
> be "--limit 4/s" along with the --limit-burst 4.  Though, 4 SYNs per
> second is hardly a syn flood.  Also, you may want to specify the
> destination port of the syn flood to give more grainular control.

Hi Jiann

Thank you for your reply.

May I ask what you would consider a more realistic limit /value.

I currently have ports 25, 80 and 443 open. I would like to strive to get a respectable value that would cater for these ports.

Kind Regards
Brent Clark

Re: use of -m limit for Syn Flood protection

[Jiann-Ming Su]

On 10/14/06, Brent Clark <bclark@eccotours.co.za> wrote:
>
> Thank you for your reply.
>
> May I ask what you would consider a more realistic limit /value.
>
> I currently have ports 25, 80 and 443 open. I would like to strive to get a respectable value that would cater for these ports.
>
>

Here's what we've used for the wild, wild west that is a residential
hall network for a university:

-A FORWARD -i eth2 -p tcp -m tcp --tcp-flags SYN SYN -j FWD_SYN
-A FWD_SYN -p tcp -m tcp --tcp-flags FIN FIN -m limit --limit 10/min
-j ULOG --ulog-prefix "iptables S
YN/FIN attack"
-A FWD_SYN -p tcp -m tcp --tcp-flags FIN FIN -j DROP
-A FWD_SYN -p tcp -m tcp --dport 80 -m limit --limit 200/sec
--limit-burst 400 -j ACCEPT
-A FWD_SYN -p tcp -m tcp --dport 135 -m limit --limit 50/sec
--limit-burst 50 -j ACCEPT
-A FWD_SYN -p tcp -m tcp --dport 139 -m limit --limit 50/sec
--limit-burst 50 -j ACCEPT
-A FWD_SYN -p tcp -m tcp --dport 443 -m limit --limit 50/sec
--limit-burst 50 -j ACCEPT
-A FWD_SYN -p tcp -m tcp --dport 445 -m limit --limit 50/sec
--limit-burst 50 -j ACCEPT
-A FWD_SYN -p tcp -m tcp --dport 80 -m limit --limit 1/sec -j ULOG
--ulog-prefix "iptables syn limit (http): "
-A FWD_SYN -p tcp -m multiport --dports 135,139,443,445 -m limit
--limit 10/min -j ULOG --ulog-prefix "iptables syn limit (MS): "
-A FWD_SYN -p tcp -m tcp -m multiport --dports 80,135,139,443,445 -j DROP
-A FWD_SYN -p tcp -m tcp -m limit --limit 100/sec --limit-burst 200 -j ACCEPT
-A FWD_SYN -p tcp -m tcp -m limit --limit 10/min -j ULOG --ulog-prefix
"iptables syn limit: "
-A FWD_SYN -j DROP


-- 
Jiann-Ming Su
"I have to decide between two equally frightening options.
 If I wanted to do that, I'd vote." --Duckman
"The system's broke, Hank.  The election baby has peed in
the bath water.  You got to throw 'em both out."  --Dale Gribble

Re: use of -m limit for Syn Flood protection

[Pascal Hambourg]

Hello,

Brent Clark a écrit :
> 
> # we allow 4 TCP connects per second, no more
> $IPT -N syn-flood
> $IPT -A syn-flood -m limit --limit 1/s --limit-burst 4 -j LOG 
> --log-level info --log-prefix '#### Syn Flood ####'
> $IPT -A syn-flood -m limit --limit 1/s --limit-burst 4 -j RETURN
> $IPT -A syn-flood -j DROP

This accepts only 1 packet per second after an initial 4-packet burst, 
and it logs *accepted* packets, not dropped ones. I am not sure this is 
what you want.

You probably want something like this instead, assuming there is an 
ACCEPT rule later that matches these packets in the calling chain :

$IPT -N syn-flood
$IPT -A syn-flood -m limit --limit 4/s --limit-burst 4 -j RETURN
$IPT -A syn-flood -j LOG --log-level info \
   --log-prefix '#### Syn Flood ####'
$IPT -A syn-flood -j DROP

You may also want to set a rate limit in the LOG rule not to prevent SYN 
flood but to prevent log flood. ;-)