codered/nimda blocking

[Patrick McManus]

[Peter R. Wood: Tue, Nov 06, 2001 at 10:27:03AM -0500]
> 
> So we contacted our ISP (Genuity) and asked them if they could set this up
> on our routers. They refused, saying that they didn't think the routers
> were the right place to handle this problem, and suggested we set up a
> firewall. (Why would Cisco give their routers this capability, then?)

to answer your question (why would cisco..?): nabr for CR plays a
security role by protecting vulnerable servers from attack, but it has
horrible efficiency properties.. since you have a performance problem,
not a security problem, its not the right fix for you.

genuity is quite right: L3 fixes for L7 problems are indeed in the
wrong place. Routers are designed to move a phenomenal number of
packets from one interface to another - doing stateful inspection of
those packets (and worse, relating them to a larger flow) is typically
a significant burden on the router.

plus, it doesn't work well anyhow. In order to recognize a CR/nimda
request the TCP session needs to be already established, because an
HTTP client can't send its request until the TCP handshake is
complete.. In your case (with a non-vulnerable webserver) this
handshake is half the total work its going to do anyhow even if it
sees the worm. when the router sees the worm request it just applies a
filter to the rest of that TCP session - so the actual request never
makes it to the web server. However, the webserver still has an open
TCP session and is waiting to hear a request.. that session will need
to time out - a very long process. that ties up both kernel resources
and very likely your application's resources too.. nabr results in
connection tables full of connected but idle sockets. That can be a
bigger load problem than just serving the worm requests.

the cisco solution also doesn't work when the request is in more than
one packet (low mtu.. often dialup clients do this) or isn't in the
first data packet (due to persistent connections or just a more clever
client)..

what you really need is something HTTP aware that buffers
requests. the cheapest answer is probably squid in 'accelerator' mode
- though that doesn't scale up particularly well. How much traffic are
you doing?

-P