On Tue, Jan 5, 2010 at 2:16 PM, Brian Johnson <bjohnson@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