Re: Proverbial appliance vs software based firewall

["Patrick M. Hausen" <hausen () punkt de>]

Hi Mike!

> However, we're talking about firewalls here, not toasters.
> Firewall vendors SHOULD be competent enough to do that -- how the 
> heck are they otherwise supposed to be able to know where the 
> problem areas are?

I really doubt most of the vendors of all those Linux/BSD based
appliances for a couple of hundred dollars out there know much
more than how to implement NAT and set up a squid proxy.

And these are the most common "firewall" systems in the market.
Of course I know the difference between a box like this and
a real firewall system.

> > Doesn't it feel good to know, that _they_ got tcp_input() right
> > and you don't need to worry about partial ACKs or some such,
> > when writing your application level proxy?
>
> This point was less than well thought-through.
>
> 1. If you're writing an ALG, you don't ever have to worry about
>    partial ACKs. Your interpretation is the correct one, since this
>    is exactly what you'll be telling the other end.
>
> And, as a sidenote:
> 2. SPF firewalls on top of linux are no less secure against partial ACKs.
>    The fact that TCP/IP stack in Linux doesn't generate partial ACKs 
>    has nothing to do with the operation of an SPF.  As a matter of 
>    fact, one could quite convincingly argue that Linux stacks are 
>    doing the wrong thing by refusing to re-send partial datagrams:
>    it doesn't take into account resource shortages at the receiving end.

Well, but it's the appliance producer's choice if he goes the
conservative route - design wise - and uses a good IP stack
with proxies on top of it. Or tries to reimplement the protocols
in an SPF state machine. And there are no "tried and true" free SPF state
machines to look at. Or are there (maybe I missed something)?
There are good free IP stacks, though.

That was the entire point. In all SPF implementations I've seen so
far the packets don't pass the OS's TCP implementation. So the
reassembly - if done at all - is done outside the OS. Whose
TCP/IP implementation has a fair chance of being much more mature
then the reimplemented "intelligence" inside the SPF engine.

So why use SPF at all? There's an entire IP stack in the OS to
do most of what SPF does today. And the kernel modifications necessary
for transparent proxying were a brilliant new idea when Marcus (?)
came up with them - but are well understood and looking rather
trivial/obvious today. Well, most brilliant ideas look obvious
_afterwards_ ;-)


Patrick M. Hausen
Technical Director
-- 
punkt.de GmbH         Internet - Dienstleistungen - Beratung
Scheffelstr. 17 a     Tel. 0721 9109 -0 Fax: -100
76135 Karlsruhe       http://punkt.de
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards