the solution to synflood on netfilter

the solution to synflood on netfilter

[郑传波]

Check Point has two implementations on preventing synflood.  

One is to intercepts the syn packets between the client and the server. The firewall
sends a syn/ack packet to the client on behalf of the server when it receives a syn
packet. If the firewall received the Ack from the client,it will start another 3-way
handshake with the server. If not, the connection will be timeout on the firewall, 
without influncing on the server.

The other way is the firewall forward all the syn packets to the server. After get the
syn/ack from the server, the firewall sends a ack to the server on behalf of the client,
so that the connection on the server is removed from the half-opened queue immediately.
The if the ack from the client is received, the connection on the firewall is validated.
If not, the connection is timeout. And firewall sends a rst to the server.
	
I think it is possible to implement some methods similar to that on Checkpoint
in netfilter. Then synflood could be prevented with a netfilter firewall.

Any idea on that? thanks.
	
regards,
Jack Zheng
zhengcb@netpower.com.cn

Re: the solution to synflood on netfilter

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 4436 bytes --]

On Thu, Dec 25, 2003 at 06:11:38PM +0800, ?????? wrote:
> 
> One is to intercepts the syn packets between the client and the
> server. The firewall sends a syn/ack packet to the client on behalf of
> the server when it receives a syn packet. If the firewall received the
> Ack from the client,it will start another 3-way handshake with the
> server. If not, the connection will be timeout on the firewall, 
> without influncing on the server.

I think this is definitely not something that should be implemented in a
router/packet filter.  This behaviour simulates the 'server' end is
located on the packet filter.  Thus it should be done in an
application-layer [transparent] proxy.

In fact, a couple of people (including Marc Boucher and Lennert
Buytenhek) have proposed an extension to the linux socket API in order
to make such implementation possible as a transparent proxy.  
http://www.netfilter.org/documentation/events/netfilter-ws-2001-summary.txt&e=7418

> The other way is the firewall forward all the syn packets to the
> server. After get the syn/ack from the server, the firewall sends a
> ack to the server on behalf of the client, so that the connection on
> the server is removed from the half-opened queue immediately.  The if
> the ack from the client is received, the connection on the firewall is
> validated.  If not, the connection is timeout. And firewall sends a
> rst to the server.

So then, instead of having all connections in the half-open queue, you
will end up having them as real (stale) connections.  I doubt this will
decrease the load on the to-be-protected server in any way.

> I think it is possible to implement some methods similar to that on Checkpoint
> in netfilter. 

Of course it is possible to implement both of them with netfilter.
However, I think from past discussions it is quite clear that the core
team would never support such a 'solution' going into the mainstream
kernel.  This is, to speak in words of David Miller, a 'quality of
implementation' issue.

I think there is a clear line we really don't want to cross.  Such
awkward breakage of end-to-end and protocol transparency is just not
what we think should be deployed on the internet. 

Yes, we have nasty things like sequence-number-offset's on the fly, and
packet resizing within a TCP stream.  But that's only in the NAT code.
Nowhere in connection tracking or iptables you can find a behaviour like
that.

I think somebody who 'just' wants to use a packet filter should not have
his firewall produce such protocol breakage.

> Then synflood could be prevented with a netfilter firewall.

I think there is only a very little number of real-world cases where you
can 'prevent' such a flood.  In 99% of all cases I've seen, the firewall
or the uplink bandwidth is the bottleneck.  So the only case where you
could do something about syn flood is, if:

1) your attacker is not able to fill your uplink bandwidth with packets
2) your packet filter is able to deal with more pps than the protected
server

Especially case number 2 is not always true.  People tend to use old 
used desktop or server machines as packet filter.   This will work for
normal usage traffic, but not if the pps rate is increasing (as it is
the case with any small-packet flood).

If your packet filter is able to deal with the full upplink wire speed of small
64-byte-packets, then I would recommend using something like the
dstlimit match.

Not to forget:  Most people actually artificially introduce a DoS
vulnerability by implementing static syn-rate limiting.  They limit the
number of syn packets per timeframe to a rate lower than their protected
server would be able to deal with... and thus artificially lower the
connection rate.  As soon as they run into the limiter, they would start
throwing away 'real' connection requests as well as the flood, thus
preventing legitimate users of their service.

I'm curious for your reply :)

> regards,
> Jack Zheng
> zhengcb@netpower.com.cn
-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: the solution to synflood on netfilter

[Henrik Nordstrom]

On Fri, 26 Dec 2003, Harald Welte wrote:

> I think there is a clear line we really don't want to cross.  Such
> awkward breakage of end-to-end and protocol transparency is just not
> what we think should be deployed on the internet. 

Not to mention what mess such behavior easily could make to modern
standards-track TCP extensions such as TCP Window scaling, PAWS, ECN etc.

Regards
Henrik

Re: the solution to synflood on netfilter

[Emmanuel Guiton]

Hi!

Sorry to intervene so late on that subject, I was in holiday.
There is a now quite old paper (1997) that fits exactly with the ideas 
that were expressed and I think you should have a look at it:
C.L. Schuba, I.V. Krsul, M.G. Kuhn, E.H. Spafford, A. Sundaram, and D. 
Zamboni, "Analysis of a denial of service attack on TCP," in /Proc. IEEE 
Symposium on Security and Privacy 1997/, May 4-7, 1997, pp. 208-223.
As far as I know, it was one of the first paper published on the subject 
and there are a few proposed solutions with their issues. It includes 
the two solutions mentioned at first in the previous mails.
About the establishing "illegitimate connections" case, well it worth 
doing when considering that the processing power/memory needed to take 
care of the illegitimate connections has more capacity than the backlog 
queue can accept half-open connections.

Bye,

         Emmanuel

Re: the solution to synflood on netfilter

[Henrik Nordstrom]

On Thu, 8 Jan 2004, Emmanuel Guiton wrote:

> About the establishing "illegitimate connections" case, well it worth 
> doing when considering that the processing power/memory needed to take 
> care of the illegitimate connections has more capacity than the backlog 
> queue can accept half-open connections.

For TCP it is very hard to beat the SYN-cookies approach when it comes to
that specific issue. Moves the whole burden to the client while sacrifying
very little of TCP.

But this is only one of many issues to address, and for most if not all 
the firewall will have a harder time to maintain the required information 
than the server itself.

Note: The use of SYN-cookies is far more effective than netfilter
conntrack for SYN flood protection. The two can not even be compared in a
meaningful manner.

Note 2: Only the origin server can make correct use of SYN-cookies. 
Similar approaches done at the firewall level will have far more 
significant impact on TCP operations.

Regards
Henrik