[unisog] IPTables as high banwidth firewall

Stephen Gill gillsr at cymru.com
Thu Aug 4 15:44:34 GMT 2005


Here are a few older thoughts on the subject of state table exhaustion:

http://www.cymru.com/gillsr/documents/maximizing-firewall-availability.pdf
http://www.cymru.com/gillsr/documents/maximizing-firewall-availability.htm

Since then, folks such as Netscreen have made considerable improvements in
the area as have several other vendors.

Cheers,
Steve, Team Cymru.

> From: Robert Kerr <r.kerr at cranfield.ac.uk>
> Reply-To: "UNIversity Security Operations Group <unisog at lists.sans.org>"
> <unisog at lists.sans.org>
> Date: Thu, 04 Aug 2005 09:49:44 +0100
> To: <unisog at lists.sans.org>
> Subject: Re: [unisog] IPTables as high banwidth firewall
> 
> On Wed, 2005-08-03 at 16:08 -0400, Lloyd B. Park wrote:
>> There are two issues we ran into with iptables.
>> 1.  Connection tracking in IPtables can kill your performance if you are
>>      in the middle of a worm break out.  P2P software can also trigger
>>      the problem.  All the scanning going on creates many connections.
>>      Each connection needs a hash table entry and creating them and
>>      destroying them takes time.  If your rule set is small, the solution
>>      may be to turn off connection tracking.
> 
> This isn't really so much an iptables problem as a problem with stateful
> firewalls in general. I've seen it happen plenty of times with
> commercial firewalls too - if your state table gets full then you'll
> start losing new and existing connections. As Johan mentioned the state
> table size is tunable, as are the state table timeouts - with careful
> adjustments you can reduce the risk quite a lot.
> 
> The best way to defeat this problem though is to be careful with your
> ruleset. Entries only get into the conntrack table if you accept the
> connections in the first place. If you pay a little attention to what
> you accept oubound instead of having a default outbound allow you can
> really cut the amount of junk getting into your conntrack tables in the
> first place:
> 
>  * Worms often use spoofed source addresses when flooding packets, so
>    make sure you have a rule to catch and drop outbound packets with a
>    source address not in your network
>  * Common worm ports (135/445) aren't really something that needs to be
>    allowed out to the internet anyway - so for perimeter firewalls they
>    can usually be dropped straight off. For internal firewalls things
>    aren't quite so simple of course
>  * Legitimate hosts don't produce thousands of connections per second,
>    so consider a rule that rate limits outgoing connections per host
>    (the hashlimit match is good for this)
> 
> Disabling connection tracking of course will work too, but I'm hesitant
> to recommend doing it unless you really need to. There's a patch in the
> netfilter patch-o-matic that will let you disable conntrack on a per
> src/dst basis which might be preferable to disabling it entirely - never
> used it though. All depends what role the firewall is playing really I
> guess.
> 
> -- 
>  Robert Kerr
> 
> _______________________________________________
> unisog mailing list
> unisog at lists.sans.org
> http://www.dshield.org/mailman/listinfo/unisog
> 




More information about the unisog mailing list