Stateful firewalls make absolutely no sense in front of servers, given that by definition, every packet coming into the server is unsolicited (some protocols like ftp work a bit differently in that there're multiple bidirectional/omnidirectional communications sessions, but the key is that the initial connection is always unsolicited).
I'm interested by this assertion; surely Stateful Inspection is meant to facilitate the blocking of out-of-sequence packets, ones which aren't part of valid + recognised existing sessions - whilst of course allowing valid SYN session-starters, etc?
So thus, there may still be some value in catching 'injected' packets which don't actually belong in a session... ?
Putting firewalls in front of servers is a Really Bad Idea - besides the fact that the stateful inspection premise doesn't apply (see above), rendering the stateful firewall superfluous, even the biggest, baddest firewalls out there can be easily taken down via state-table exhaustion; an attacker can craft enough programmatically-generated, well-formed traffic which conforms to the firewall policies to 'crowd out' legitimate traffic, thus DoSing the server. Addtionally, the firewall can be made to collapse far quicker than the server itself would collapse, as the overhead on the state-tracking is less than what the server itself could handle on its own.
Some might argue that DoS is preferred to the other degrees of risk that many webservers hold... (trying not to point the finger in any one specific direction.)
Mark.
