Kerry Milestone wrote:
>Other than that, I guess the theories for firewalling are the same whether it be 100Mb or 10Gb - the device just needs to handle it.

Um, no.

If you're letting 10Gb/sec through, there's no way you're doing any
layer-7 analysis. If all you're doing is mostly below layer-7 then
there's not much need for a "firewall" - you're really just using your
firewall to implement something that's hardly more useful than a
router ACL. I'm emphatically not saying router ACLs are bad - far
from it - but you need to understand that most of the interesting
action in security, nowadays, is taking place at layer-7.*

For situations where "wire speed" is necessary, wire is the only
technology that'll cut it. So, what you need to do is identify which
services offer layer-7 security controls that you're comfortable
with, and which can be addressed at layer-4, or whatever other

One useful conceptual framework is the "security stack"** - basically
think of your security problems in detail in terms of where you're
going to apply your controls: at what layer of the stack:

7) Policy
6) Practices
5) Applications
4) Proxies
3) IP Filtering and router ACLs
2) IP Stack Termination
1) Physical and VLAN/MAC filtering

Arguably, there should be a layer 8 entitled "making it someone
else's problem" (i.e.: risk arbitrage or indemnification)

Anyway, let's suppose your problem is that you need to do "wire
speed firewalling" of a web server. You can look at your applications
mix and decide that you'll address security for everything except
DNS and HTTP/SSL at security stack layer-3. Then you'll deal with
HTTP/SSL at security stack layer-5 by locking down the server,
chrooting it, and running on SElinux with restricted privs on your
http/ssl daemon. And, perhaps you'll deal with DNS at security
stack layer-6 by having someone responsible for keeping their
ear to the ground for new DNS vulns and being prepared to
react rapidly. That's just an example - I wouldn't recommend
addressing DNS at security stack layer-6, but you get the idea.
The point is to think about what services are going to bypass
straight into your network (and why) and which are going to
force-terminate at an application. Basically, it's just a doctrine
of security design -- and "design" is what gets left out of
security critical systems all too often. In fact "put a firewall in"
is a security 'design' with vastly less attention to detail than
a well-reasoned pieces/parts implementation where you've
looked at each protocol and decided where in the computer
security stack to deal with it. Last, but not least, you can
layer defenses at multiple layers in the security stack (aka: "defense
in depth") This approach is not a panacea; it's simply an
organizing principle I've found useful when trying to explain
"letting HTTP straight in through your firewall to Microsoft
IIS is suicide" to executives.

Bandwidth is not a property of security. It's a side-effect.

(* and above)
(** this brilliant idea is not mine. I've forgotten whose it was, or I'd

firewall-wizards mailing list