Re: I don't need no stinking firewall!

[Joe Greco <jgreco () ns sol net>]

> On Fri, Jan 8, 2010 at 10:48 AM, Joe Greco <jgreco () ns sol net> wrote:
> > Putting a stateful firewall in front of that would be dumb; the server
> > is completely capable of coping with the superfluous SYN's in a much
> > more competent manner than the firewall.
>
> The trouble with blanket statements about "all stateful firewalls" and
> "all servers" is there are lots of different firewall and server
> platforms.

Yes, yes there are, but only an idiot buys a Ford Pinto to haul pallets
of freight.  When you get serious about hauling lots of freight, you buy
something appropriate, and there are suddenly a lot fewer combinations.

> Stateful firewalls can implement SYN cookies, and at least
> a couple do.   Firewalls do not need to build a state entry for
> partial TCP sessions,  there are a few different  things that can be
> done,  such as  the firewall answering on behalf of the server (using
> SYN cookies) and negotiating connection with the server after the
> final ACK.

And how much of that is done in silicon?  Because if it's not in silicon,
then it's being done by a CPU, and if it's being done by a CPU, why not
just let the server do it?  Commodity server hardware is cheap compared
to specialized silicon offerings...

> As a result, spoofed TCP packets don't consume state.  Multiple IPs
> they can _receive_  traffic to required, next?
>
> Spoofed UDP is a much bigger problem, because there is no connection
> establishment.  And  it's probably not sane to put certain
> public-facing  UDP  services such as  large public DNS  service IPs
> (e.g.   8.8.8.8) behind most forms of stateful filter.
>
> But that's not the average case, by any means,  most servers are not
> DNS servers.
> Servers consume state just like firewalls do....
>
> E.g. A  public  FTP server  that opens a process for each connection,
> goes down in a connection flood, when kernel process slots are used
> up,  long before the firewall.

Again, Ford Pinto...  you can always design a system that will fail. 
That's like shooting fish in a barrel.  If you're worried about kernel 
process slots, you *choose* an appropriate service.  Like a threaded 
ftp server.

> Servers running a robust  OS  completely and correctly configured to
> perfectly protect themsleves  (resource limits, etc),  no Windows
> OSes, with unwanted open ports, is a wholly unwarranted assumption
> for real-world server environments.

And so is a high-performance non-crashable stateful firewall that's so
talented that it can keep a poorly configured server operational under
all circumstances.  Wheee.

> In the best cases it does hold up  (to a great extent).
> In other cases, it's an operational fantasy;  it would be nice if that
> could be relied upon....

Some of us are still failing to understand why it is that it's better to
buy an extremely expensive stateful firewall device which is likely to 
collapse under load because the salesman lied; it seems like it'd be 
easier to go and scale capacity with some cheap stateless firewalls to 
do packet filtering in silicon, backended by some additional servers 
and some good admins who have a clue about what they're doing.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.