On Tue, 5 Jan 2010, Dobbins, Roland wrote:
In the most basic terms, a stateful firewall performs bidirectional
classification of communications between nodes, and makes a pass/fail
determination on each packet based on a) whether or not a bidirectional
communications session is already open between the nodes and b) any
policy rules configured on the firewall as to what ports/protocols
should be allowed between said nodes.
Stateful firewalls make good sense in front of machines which are
primarily clients; the stateful inspection part keeps unsolicited
packets away from the clients.
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).
Putting firewalls in front of servers is a Really Bad Idea - besides the
Hi Roland. I disagree strongly with this position.
fact that the stateful inspection premise doesn't apply (see above),
The problem is that your premise is wrong. Stateful firewalls (hereafter
just called firewalls) offer several advantages. This list is not
necessarily exhaustive.
(1) Security in depth. In an ideal world every packet arriving at a
server would be for a port that is intended to be open and listening.
Unfortunately ports can be opened unintentionally on servers in several
ways: sysadmin error, package management systems pulling in an extra
package which starts a service, etc. By having a firewall in front of the
server we gain security in depth against errors like this.
(2) Centralised management of access controls. Many services should only
be open to a certain set of source addresses. While this could be managed
on each server we may find that some applications don't support this well,
and management of access controls is then spread across any number of
management interfaces. Using a firewall for network access control reduces
the management overhead and chances of error. Even if network access
control is managed on the server, doing it on the firewall offers
additional security in depth.
(3) Outbound access controls. In many cases we want to stop certain types
of outbound traffic. This may contain an intrusion and prevent attacks
against other hosts owned by the organisation or other organisations.
Trying to do outbound access control on the server won't help as if the
server is compromised the attacker can likely get around it.
(4) Rate limiting. The ability to rate limit incoming and outgoing data
can prevent certain sorts of DoSes.
(5) Signature based blocking. Modern firewalls can be tied to intrusion
prevention systems which will 'raise the shields' in the face of
certain attacks. Many exploits require repeated probing and this provides
a way to stop the attack before it is successful.
rendering the stateful firewall superfluous, even the biggest, baddest
firewalls out there can be easily taken down via state-table exhaustion;
Do you have any evidence to support this assertion? You've just asserted
that all firewalls have a specific vulnerability. It isn't even possible
to know the complete set of architectures (hardware & software) used for
firewalls so I don't see how you can assert they all have this
vulnerability.
In any case, my experience tells me that a DDoS will be successful due to
exhaustion of available network capacity before it exhausts the state
table on the firewall.
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.
Again, I don't believe such a global claim can be made given the wide
variety of architectures used for firewalls.
Cheers,
Rob
--
I tried to change the world but they had a no-return policy
http://www.practicalsysadmin.com
