I don't need no stinking firewall!

Wed Jan 6 01:56:05 UTC 2010

On Tue, Jan 5, 2010 at 2:16 PM, Brian Johnson <bjohnson at drtel.com> wrote:
> I have my own idea of what a firewall is and what it does. I also

A firewall is a term for a class of device (or software program).  Ask
different people  and you should get different answers, depending on
who you ask.
Windows firewall...  bpf..  ipfw..  iptables...  broadband router..
It's not one specific thing,  but the description of a role......

The essential characteristic of a firewall is: "a control point",  and
usually a "central control point" at that.
A computer network virtual equivalent of  real-world "sally ports"
and  the  access control vestibules you will find at airports, with
metal detectors, security guards, etc.

You probably won't find security booths at each row of seats on
airplanes themselves   -- but that's the equivalent of a "host
firewall"   (a much less useful more expensive control point to
maintain,  if you have many servers,  all  subject  to attack  through
the shared network,  you definitely want  some checkpoints and common
firewalls,  in addition to host firewalls)

A  control point is a place that provides the core security functions:
* Identification/Classification -- determining the nature of traffic
crossing the control point  into or out from the protected area
* Access Control -- implementing a policy against  such classified
traffic, to determine  who/what/when bits  may cross into or out from
the protected area, or between different protected areas
* Auditing --  logging,  making a record of what happened, when, in
what direction, evidence collection

It is just as much about preventing your compromised server from
making improper outbound connections,  such as  'port 25'  connections
to send spam  (for a server that is not a mail server),   or   'port
22' connections to  your other servers  in different subnets   (e.g.
attempts to  use a successfully compromised server's trusted IP to
leapfrog  to other servers in different LAN subnets)

Some firewalls do not perform auditing functions,  or  log to
/dev/null,  anyways:  this is just a log retention time of 0 seconds.
  If the firewall  does not produce logs,   then how can you validate
the firewall  blocks the right  things and allows other things?

Access control policy might be pre-defined  by the manufacturer, or
set by an administrator.  It  might not deny anything,  unless asked;
it's still a firewall.

The ability to quickly set a block with flexible parameters  is one of
the most significant benefits of having firewalls in place.

The depth of "Identification"  may vary,  depending on the type of
check point;  searching the packet's  luggage thoroughly  (DPI)
versus  just passing it through the metal detector  ( protocol type  /
port number  based filters).

> understand what statefull packet inspection is and what it does. Given
> this information, and not prejudging any responses, exactly what is a
> firewall for and when is statefull inspection useful?

Stateful inspection is useful for discarding  traffic  that is  not
meaningful in the context of a valid connection.

In the absence of a stateful firewall, the destination host has to
receive the traffic, and make a decision  (hopefully) to drop it.

If  the host has an exploitable condition in its TCP/IP
implementation,  a stateful firewall may be able to assist,  by
refusing packets that are invalid,  or do not make any sense in the
context of any already established connection.

So the host never sees them,  it  never  kernel panics, or  blue
screens, due to the  exploit attempt  (which would have happened
without the firewall).

Some stateful firewalls may re-assemble certain fragments,  offer
protections against teardrop attacks, common SYN floods, simple
floods, and the like.

So a  Firewall  can be a good backup safety net  against  the
exploitation of unpatched vulnerabilities.

In addition, by restricting management access, a central firewall
protects against password guessing attacks,  or even,  an outsider who
(somehow)  stole the server password.

You might say your system admins are perfect, and always apply all
vendor patches, with no mistakes ever,  always keep all ports closed
except the absolutely required ones,  so  none of your servers should
ever be vulnerable to 15-year-old TCP stack, application issues,  or
remote exploit of software you didn't know was installed.

But reminder:  without a safety net,  only  one mistake is required,
for an attacker to  (eventually)  become a successful intruder.

As for patching.. this is only useful, if the vendor knows about the
vulnerability, admits the problem, and makes a patch available,
before your adversary can take advantage of it.

New  (as of yet unknown)  vulnerabilities  may exist  in hosts,  and
thorough validation by the firewall device  looking for any  funny
business can be beneficial,
in almost all situations.

As long as you  size, configure your firewalls appropriately,  and
protect against problems  like   state table exhaustion.     Size
does not equal  just  bits per second of traffic,   but  worst-case
peak packets per second  cleartext+encrypted,   worst-case peak
connections per second, etc.

Probably if you have 100  mail or web servers,  you  do not want just
2 or 3 firewalls  handling all that all by themselves,  depending on
how much traffic they get,   and  the  need/price of downtime..

--
-J