The Real Answer To Worm Propagation

Thomas Ptacek | August 25th, 2005 | Filed Under: Uncategorized

Bejtlich comments about this eWeek worm synopsis, and cites this SANS newsletter advocating for IPS and “security switches”:

Because [these] worms spread over 139/tcp or 445/tcp, [these] ports that cannot be firewalled without breaking some functionality in Windows environment. That means that even a single infected laptop brought inside an enterprise will infect all the other machines. Multiple intrusion prevention systems, as ubiquitous as switches, need to become as integral to networks.”

This is a very popular misperception.

It’s true that you can’t filter 139/TCP (NetBIOS SMB) and 445/TCP (Direct SMB) wholesale on an enterprise network.

It’s true, in the same sense as it’s true that you can’t filter port 80 everywhere on an enterprise network: everyone uses it.

Thing is, everyone doesn’t use it to everyone else. To put it theoretically: the graph of 445/TCP usage is sparse.

On the other hand, the graph of 445/TCP connection attempts made by a worm is dense. It has to be: worms scan randomly. They have to: if they don’t, infected hosts compete with each other and repeatedly scan the same hosts.

So, on the one hand, you can say that the solution to the worm propagation problem is to embed logic in every forwarding path on the network that will sweep traffic for worm signatures (if you’re going to do that, here’s a great place to start thinking about how).

On the other hand, instead of committing yourself to the strategy of making the IP network aware and coupled to every application you use forever and until secure programming is a solved problem, you could instead exploit the difference between the sparse graph of real usage and the dense graph of actual usage: lock down SMB to legitimate pairs of hosts.

Locking the network down this way is a hard problem to be sure, but it’s not harder than making the whole network application-aware, which I think is a stupid goal and contradicts the single most important architectural goal of IP networking.

Things you can do to facilitate “connectivity-based lockdown”:

• Divide your network into enclaves or zones by geography or org-chart and worry only about the connectivity between those zones.

• Learn how the network is used normally and use the information to write and maintain ACLs (my old employer did this, partially at my insistence, so note my bias).

• Pursue policies that simplify the connectivity graph on your network, for instance by centralizing storage.

Two things I like about this approach:

• It applies generally to applications we understand well and applications which haven’t been examined closely, and doesn’t depend on vulnerability research to be successful.

• It applies incrementally: the finer-grained your lockdown policies become, the more tightly contained outbreaks will become. For many organizations I’ve worked with, containment of a worm even to a single building on a campus would be a win. On the other hand, an all-or-nothing retrofit of instantly-dated app-layer devices is feasable almost nowhere.