[unisog] [REN-ISAC] Storm Worm DDoS Threat to the EDU Sector

Pearson, Douglas D dodpears at indiana.edu
Thu Aug 9 14:44:51 GMT 2007

Regarding: Storm Worm DDoS Threat to the EDU Sector
August 09,2007


Scanning certain Storm Worm[1]-infected machines with a security
vulnerability scanner can result in a DDoS[2] against the scanning
machine. This behavior is encountered with Storm-infected machines
operating as "distribution nodes" in the botnet hierarchy.

During the past month we've observed and notified involved
parties regarding numerous such Storm-related DDoS attacks. The
attacks have been ICMP, can last more than a day, involve a large
number of sources scattered globally, and can yield very
significant attack traffic.

With the impending return of students for fall classes, the
DDoS-the-scanner-when-scanned behavior represents a significant
risk for the EDU sector.


(1) If possible, move security vulnerability scanners to RFC1918
(private) address space - make the scanner IP address unroutable
from attacker networks. Make sure the scanner IP doesn't get NATed
to a public source address when reaching out to scanned hosts. If
the scanner must be seen by external networks, such as for vendor
updates, consider dual network interfaces - a public management
interface and a private scanning interface.

(2) Although opinions differ regarding the practice of blocking
ports at network borders, we note that -at least for now- dropping
inbound TCP/80 to residential networks will forestall the elevation
of Storm-infected residential machines to distribution node status,
and therefore attack trigger sensitivity. This should NOT be
interpreted as a recommendation by REN-ISAC to block residential
inbound TCP/80 - each site must evaluate that locally.


(1) Respond quickly to notifications of infected hosts on your
network. Infected machines can become distribution nodes, which
may become attack triggers.

(2) Monitor inbound network utilization. Identify suspicious
increases, and take action to determine causes.

(3) Have an emergency plan in place for contacting your Internet
service provider -by phone- for assistance when being DDoS'd. Many
commercial ISPs accept null route advertisements tagged with a BGP
community value. Contact your ISP IN ADVANCE to know what your
opportunities and procedures are for DDoS mitigation.

(4) Similarly, if you're connected to the Internet2 Network, have
an emergency plan to leverage Internet2 null route mitigation. See:

(5) Have a plan to contact the REN-ISAC 24x7 Watch Desk
(ren-isac at ren-isac.net, +1(317)278-6630) for assistance and to
share your experience if attacked. REN-ISAC is monitoring and
analyzing attacks within the sector. Sharing your experience
is critical to the evolution of security in the EDU sector.


(1) Don't block all ICMP at your network border. That breaks
certain network things like path MTU discovery and network problem
diagnostics, and it doesn't protect the DDoS chokepoint between
your network and your ISP. For ICMP rate limiting and filtering
recommendations see the Team Cymru ICMP Packet Filtering guide:

(2) Don't count on firewalls to protect you during a DDoS.
Similar to #1, the chokepoint between you and your network
provider is still vulnerable.

If you have questions or concerns, please contact us.

On behalf of the REN-ISAC staff and Technical Advisory Group,

Doug Pearson
Technical Director, REN-ISAC
24x7 Watch Desk +1(317)278-6630

REN-ISAC membership: http://www.ren-isac.net/membership.html


[1] Storm Worm aka Peacomm, Zhelatin, references:

[2] Distributed Denial of Service Attacks


More information about the unisog mailing list