I don't need no stinking firewall!
mysidia at gmail.com
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..
More information about the NANOG