[c-nsp] cisco-nsp Digest, Vol 83, Issue 39

[Kevin Graham]

> However, good firewalls are doing a lot more than that.

> 
> You may remember last year's "the Internet is falling and only Dan Kaminsky can 
> explain it" flap around DNS.  Well, a lot of the discussion around this 
> bug/problem/issue ignored the truth that a good firewall prevented the attack 
> directly

As I read it, the discussion here was a public/authoritative name server. The
only thing those servers would have seen from the attack is backscatter.

> by knowing enough 'deep packet smarts' around the DNS protocol that 
> the attack scenario was effectively blocked (hey, that's why we have a session 
> table in the first place!).

Which product's 'deep packet smarts' catch a duplicate transaction ID? For that
matter, does anyone know of a breakdown of _actual_ protocol analysis applied
by different products? The few I've poked at fail to catch many deviations of
well-formed and common protocols.

Egress traffic -- firewall to death (especially if you can offload heavy lifting
to a full ALG), but inbound is much more effectively addressed by application / 
server administration with a tight ingress and egress ACL.

> But if you do it right, there is value to be provided by a firewall.

> Similarly, a well-configured firewall would have per-IP rate limits in it,
> which would have been a second line of defense.

...and now we're back to Arbor, which get this w/o being in the forwarding
path. That said, there are lots of places where I'd love to be able to apply
QoS policies on a per-address (rather than per-flow or per-acl) basis both
for security and performance motivations.