[unisog] IPTables as high banwidth firewall

Robert Kerr r.kerr at cranfield.ac.uk
Thu Aug 4 08:49:44 GMT 2005


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



More information about the unisog mailing list