codered/nimda blocking

Patrick McManus mcmanus at appliedtheory.com
Tue Nov 6 12:44:26 EST 2001


[Derek D. Martin: Tue, Nov 06, 2001 at 11:44:46AM -0500]
>Interesting...  A firewall is nothing more than a router that filters
>traffic. 

that's simply not true. The architecture of an ISP router is nothing
like that of a firewall. It's apples and oranges.

your firewall can't forward at line rate between 6 channelized DS3
cards (and that's a puny 'edge router').. and that router can't apply
5000 long ACLs complete with logging and stateful connection tracking
on every flow. 

They are different beasts with different requirements that took
different implementation paths.

If peter would like to run NBAR on his CPE router (and perhaps manage
it himself) I can't beleive genuity would care - though its still a
bad answer to the problem.

> 
> I'm inclined to think that the folks at genuity are just being stupid
> and/or lazy.

Those are pretty pejorative words when you both don't know all the facts
and are clearly not an expert in the area. NBAR is one potential tool,
but it has a lot of problems. Perhaps the ops geeks at genuity who
work with this stuff everyday might be given the benefit of the doubt
before being called stupid and lazy? 

http://www.mcabee.org/lists/nanog/msg06185.html

NABR is really good for protecting vulnerable servers. Its especially
good for protecting embedded servers that can't be patched
easily. (e.g. a number of print servers and dsl modems crashed when
recving code red requests - they weren't infected per se, but they did
crash.) But it isn't an efficiency tool in any way shape or form. As a
matter of fact, it causes efficiency problems.

HTTP filtering is an application level issue. The only long term
answer is to solve it with an application level implementation. Squid
could work - or numerous other commercial packages if squid isn't up
to the bandwidth need. An application layer switch (alteon/nortel, or
arrowpoint/cisco) would also be well suited to the task - but expensive.

-P





More information about the Discuss mailing list