stateful firewall implementation in FreeBSD

[Ian Smith]

On Fri, 27 Jan 2012, Nikolay Denev wrote:
 > On Jan 27, 2012, at 4:41 AM, Kevin Oberman wrote:
 > 
 > > On Thu, Jan 26, 2012 at 11:41 AM, Chuck Swiger <cswiger at mac.com> wrote:
 > >> Hi--
 > >> 
 > >> On Jan 26, 2012, at 9:24 AM, satish amara wrote:
 > >>> I have question regarding the size of the state table kept in FreeBSD for
 > >>> stateful packet inspection. Say we have a valid senario where we have
 > >>> stateful firewall rule for HTTP and we get lot of incoming new HTTP session
 > >>> and state table is filled full. In that case I guess FreeBSD would reject
 > >>> new sessions.  Just want to know what is the latest on this. How does
 > >>> FreeBSD would handle if the state table is full and we get valid new HTTP
 > >>> connection. What are options in terms of configuration or new feature in
 > >>> BSD would address this issue.
 > >> 
 > >> A securely designed firewall will drop connections when the state table is full.
 > >> 
 > >> You can increase the size of the state table by following the IPF FAQ:
 > >> 
 > >>  http://www.phildev.net/ipf/IPFques.html#ques25
 > >> 
 > >> ...but in point of fact, keeping state for high-volume traffic is generally
 > >> a losing game, and you are better off (IMHO) setting up stateless bidirectional
 > >> rules which permit such high volume traffic.
 > >> 
 > >> HTTP isn't generally too much of a problem, though-- something like a popular
 > >> stratum-1 or 2 public NTP timeserver will easily blow out a stateful firewall
 > >> if you try to keep state for NTP's UDP traffic.
 > > 
 > > To put it very clearly, a stateful firewall "protecting" a server is
 > > an open invitation to DOS. It is trivial to generate enough UDP
 > > traffic to overflow any limit on connections in a stateful firewall.
 > > Various tricks have been tried but the reality is that none has really
 > > succeeded. Some do help, but nowhere near enough to solve the problem.
 > > 
 > > Stateful firewalls are for clients and systems that  don't provide
 > > publicly accessible services. Servers require stateless filters along
 > > with IDS/IPS for effective protection.
 > > 
 > > And I do expect to get people saying that you HAVE to have a stateful
 > > firewall is a basic requirement for a device on the Internet. I can
 > > only say htat I know of many well known servers that do not have them
 > > and few that do. There is a reason for that. At my old employer we
 > > were under government security oversight and I can remember the
 > > auditors back a few years ago who had a fit when told that no firewall
 > > was employed, just an IDS/IPS with RTBH. The problem is that their red
 > > team of attackers never could successfully attack which really annoyed
 > > them to the point that they tryed toi order  that the IDS be disabled
 > > for their attack attempts. (We refused, siting terms of the testing
 > > agreement.)
 > > 
 > > Today, auditors still are a bit surprised that they don't use a
 > > firewall, but are no longer upset by it as they are seeing it more
 > > often.
 > > -- 
 > > R. Kevin Oberman, Network Engineer
 > > E-mail: kob6558 at gmail.com
 > > 
 > 
 > In my experience (and I've had a few DDoS attacks), the state table 
 > was never an issue (unless left at default settings), the machine 
 > would either die from interrupt/cpu overload, or the pipe will be 
 > filled. For example the pf(4) firewall can be tuned to have millions 
 > of state entries, then you can configure thresholds which reached 
 > will make the existing state entries expire sooner, leaving room for 
 > new ones.
 > 
 > P.S.: Stateful firewalls are required by the PCI DSS (requirement 1.3.6)

Some of us will recall when just about anything .gov (or at least .mil) 
-related had to be written in ADA.  One is left to ponder the relative 
wisdom of that old and this newer requirement :)

cheers, Ian