> 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. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
