All of lore.kernel.org
 help / color / mirror / Atom feed
* iptables can protect syn-flooding?
@ 2002-11-06  5:01 SB CH
  2002-11-06 15:06 ` Jon Anderson
  0 siblings, 1 reply; 3+ messages in thread
From: SB CH @ 2002-11-06  5:01 UTC (permalink / raw)
  To: netfilter

Hello all.


I saw that we can protect syn-flooding using iptables like this.

$IPTABLES -N syn-flood
$IPTABLES -A INPUT -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

But I think that anyone can't protect syn-flooding attack completely using 
this rule, just some legal client can't connect the server because the rate 
limit rule in busy system.

I guess that any firewall can't protect syn-flooding except tcp intercept 
method.right?
(but tcp intercept requires so much memory)

any idea?


Thanks in advance.


_________________________________________________________________
증권 정보 가장 빠르고 편하게 보실 수 있습니다. MSN 증권/투자  
http://www.msn.co.kr/stock/ 



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

* Re: iptables can protect syn-flooding?
  2002-11-06  5:01 iptables can protect syn-flooding? SB CH
@ 2002-11-06 15:06 ` Jon Anderson
  2002-11-06 17:17   ` Antony Stone
  0 siblings, 1 reply; 3+ messages in thread
From: Jon Anderson @ 2002-11-06 15:06 UTC (permalink / raw)
  To: SB CH; +Cc: Netfilter Mailing List

Can't guarantee that I'm right about the following, or that it's even
relevant, but based on my experience, the following might help...

SB CH (chulmin2@hotmail.com) wrote:
> I saw that we can protect syn-flooding using iptables like this.
>
> $IPTABLES -N syn-flood
> $IPTABLES -A INPUT -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

Of course one could achieve the same thing by using only two rules:

iptables -A INPUT -p tcp --syn -m limit --limit 1/s --limit-burst 4 -j
ACCEPT
iptables -A INPUT -p tcp --syn -j DROP

But that's just so I can simplify things below...

> But I think that anyone can't protect syn-flooding attack completely using
> this rule, just some legal client can't connect the server because the
rate
> limit rule in busy system.

Ran into the same thing trying to intercept (syn) port scans - makes it real
easy to DoS a machine when the above "flood protection" rules are in effect,
thus making it useless (and even worse than nothing), especially when you
have an HTTP server that will get a few concurrent connections from the same
host (each sending a SYN packet) requesting images, or html pages in an html
frameset. That said, I found a few solutions, none are really perfect, but
are better than the above:

1) Accept served ports, then apply the syn flood protection.

iptables -A INPUT -p tcp --syn --dport 25 -j ACCEPT        <-- A Mail server
iptables -A INPUT -p tcp --syn --dport 80 -j ACCEPT        <-- Or a web
server, for example.
iptables -A INPUT -p tcp --syn -m limit --limit 1/s --limit-burst 4 -j
ACCEPT
iptables -A INPUT -p tcp --syn -j DROP

Add ports as necessary. This of course doesn't work if an attacker is SYN
flooding a particular port you're serving.

2) IPLimit extension (May not be available if you're using an old
distro...?)

iptables -A INPUT -p tcp --syn -m iplimit --iplimit-above 5 -j REJECT

That would allow 5 SYN packets from any given host, then reject any others.
This doesn't work if you're getting flooded by many fake hosts. This is
where your ISP could enable TCP Intercept on their router for you.

3) If by SYN flood, you're trying to block a SYN scan, you could use the PSD
extension, but that's not in the latest stable kernel - only in
patch-o-matic. Works really well though (cheers to the guy who wrote it!).

> I guess that any firewall can't protect syn-flooding except tcp intercept
> method.right?
> (but tcp intercept requires so much memory)

Maybe I'm not clear on what tcp intercept is, but I don't think it's
relevant in your case. Seems you're trying to prevent SYN flooding on the
INPUT chain...It would be relevant if it were a router, and were using the
FORWARD chain. I don't even know of a TCP Intercept implementation for
linux - only for routers (e.g. cisco).

Hope that helps,

jon anderson




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

* Re: iptables can protect syn-flooding?
  2002-11-06 15:06 ` Jon Anderson
@ 2002-11-06 17:17   ` Antony Stone
  0 siblings, 0 replies; 3+ messages in thread
From: Antony Stone @ 2002-11-06 17:17 UTC (permalink / raw)
  To: Netfilter Mailing List

On Wednesday 06 November 2002 3:06 pm, Jon Anderson wrote:

> Can't guarantee that I'm right about the following, or that it's even
> relevant, but based on my experience, the following might help...
>
> SB CH (chulmin2@hotmail.com) wrote:
> > I saw that we can protect syn-flooding using iptables like this.
> >
> > $IPTABLES -N syn-flood
> > $IPTABLES -A INPUT -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
>
> Of course one could achieve the same thing by using only two rules:
>
> iptables -A INPUT -p tcp --syn -m limit --limit 1/s --limit-burst 4 -j
> ACCEPT
> iptables -A INPUT -p tcp --syn -j DROP

Not really - the shorter version forces all SYN packets below the limit to be 
ACCEPTed, whereas the longer version allows for later rules in the INPUT 
chain to decide whether they ought to be accepted or not, based on the usual 
things like source/destination address/port etc.

Antony.

-- 

Abandon hope, all ye who enter here.
You'll feel much better about things once you do.


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

end of thread, other threads:[~2002-11-06 17:17 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-11-06  5:01 iptables can protect syn-flooding? SB CH
2002-11-06 15:06 ` Jon Anderson
2002-11-06 17:17   ` Antony Stone

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.