[ILUG] Firewalls... linux -v- BSD

[paul at clubi.ie]

On Tue, 29 Aug 2006, Paul Mc Auley wrote:

> Not all IP traffic is TCP.

The relevance of non-TCP IP traffic on stateful TCP filtering is hard 
to see.

But yes, you want as little state as possible. For UDP, "stateful" 
filtering often boils down to a timeout on the (src:port,dst:port) - 
which is a pretty poor (and weak) form of filtering.

> The other classic edge case is FTP, and no matter how much you 
> might want it otherwise, there are cases where FTP is a 
> requirement.

Uhuh..

$ ftp ftp.heanet.ie
Connected to ftp.heanet.ie.
<snip heanet banner>
220 ftp.heanet.ie FTP server ready.
Name (ftp.heanet.ie:paul): anonymous
331 Guest login ok, type your name as password.
Password:
230 Guest login ok, access restrictions apply.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>

That's behind a stateless TCP firewall. No state needed..

Ironically, given the point you thought you were making, TCP stateful 
firewalls /can't/ do this - they need yet *more* state (acquired by 
packet inspection of FTP protocol data no less, ick).

> balancing one, I'd be wary of the overhead from trying to keep the 
> management for any non-trivial number of states synched up as I'd 
> see that getting out of hand in a big hurry.

Yes, indeed. Now google for 'pfsync'.

> The correct answer is to match your solution to your problem. Just 
> because a certain solution doesn't match your needs, has caused you 
> trouble in the past or stolen your sweets doesn't automatically 
> make it the wrong answer for all cases.

Stateful filtering can't but fail to cause problems. It's the nature 
of it. Let's rattle off some of the obvious ones:

- ECN

    ok, this isn't a fault of stateful filtering, but it's symptomatic
    of the same school of thought amongst firewall 'designers' of
    putting way way too much "knowledge" into middle-boxes. Crap that
    just shouldn't be there. "Knowledge" which eventually breaks.

- TCP Wscale

   There are firewalls today which try to validate that packets are
   within window. This fails miserably if a firewall is restarted
   (One of the BSD firewalls, Open or Free). Unfixable.

- It will never, ever, ever, work with asymmetric paths. This
   includes hosts with links to multiple networks for redundancy
   purposes (a not at all uncommon scenario). Unfixable.

   And yes, my employer regularly get support queries from customers
   who have strange networking problems because of this.

The more your firewall tries to replicate state of transport and 
user-level protocols, the more and more there is to go wrong, either 
by:

- bugs
- the future catching up and invalidating its knowledge

> FFS, "NAT is evil?" Do you want everyone to switch to public IPs, right
> here, right now?

Yep.

> Sure it causes problems for a range of cases, but that
> doesn't stop it being usable for home and office networking.

It's better than nothing, but lots of stuff is broken by NAT, which 
is what makes it evil, yes.

regards,
-- 
Paul Jakma	paul at clubi.ie	paul at jakma.org	Key ID: 64A2FF6A
Fortune:
Most people feel that everyone is entitled to their opinion.