Throttling Viruses: Restricting propagation to defeat malicious mobile code Author: Matthew M. Williamson, HP Labs Bristol Published at the 18th Annual Computer Security Applications Conference (ACSAC), 2002 Presenter: Walter Mundt

Slowing Down Worms Limit outgoing connections to unique machines Normal traffic tends to made repeat connections to a small set of servers Worm traffic connects to many different servers Benign filter design exploits this difference to slow worm traffic selectively.

Why Bother? Why only slow worm traffic? Primary threat of worms is their speed Human response is too slow Automated responses can cause damage due to false positives Need a “benign” automated response that does not interfere with normal traffic.

How to tell the difference? HTTP Traffic Worm Traffic

What Not to Do Drop connections classified as “worm traffic” Slow down normal traffic unnecessarily Fail to slow down worm traffic

How? Set a limit on the rate of outgoing connections to “new” machines to r “New” machines are those not connected to recently A buffer of 4-5 remote hosts is sufficient Queue connections that are too fast Constantly de-queue and send connection attempts, at a rate of r

Algorithm Flow On connection attempt Delay queue loop

Behavior for normal traffic Normal traffic has bursts of new connections followed by repeated connections to the same hosts New connections get queued briefly, but delay is minimal Reconnections are allowed as normal

Behavior for worm traffic Worm traffic connections attempts are much faster than allowed rate A few connections go through, but most will be stuck in delay queue When the queue fills, the user can be notified and take action against the offending process

Contribution of the paper This paper provides an effective way to slow down worm traffic from an infected machine. The effects of false positive results are minimal. If widely implemented, could effectively limit worm spread rate enough to allow human intervention. Implementation would be fairly simple on most platforms

Weaknesses in Paper Tests few types of “normal” traffic Too much focus on HTTP Would need to be implemented very widely to significantly effect worm spread Does not stop worm spread, ineffective against slow-spread or “stealth” worms No future work discussed

Possible Improvements Experiment with more types of data Discuss future work Consider limitations, possible issues Test an implementation on an actual network environment Combine with other methods of identifying worm traffic and limiting worm effectiveness.