Subject: RE: [Ieprep] FW: The Spread of the Sapphire/Slammer SQL Worm

From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[email-masked]>
Date: Sun, 2 Feb 2003 15:36:38 -0600

> > An artcile from CNN said the SQL worm started from the 
> > Pac Rim, mainly from Hongkong and South Korea. And it spread  
> > to the Europe and the US. 

The article looks like another slashdot post. Is their any proof 
to the statement? Did people do any backscatter or trace back analysis 
to validate the claim? 

> > I wonder it caused any  considerable stress for the Internet 
> > backbone.
> Yes, it did.  That's what an emergency looks like from our 
> point of view.

One more point. The problem during disaster situations is not just
hot spots but also security breaches. A lot of NASA websites has been 
defaced by hackers in line with the shuttle Columbia incident[1].

So, one of the important work for ieprep is to provide pointers 
to mitigate such breaches, other than helping the priority traffic 
to find its way to the destination.
 
> It caused very large problems, but was basically contained within four
> hours, everywhere that mattered, due in large part to the excellent
> communications which now obtain between ISP NOCs.

Obviously, the credit goes to the operators. But, due you think that
a good inter-communication and effective filtering is enough to STOP
the worm activity in future? 
From the caida/LBNL/UCB report:
"Since high-speed worms are no longer simply a theoretical threat, worm 
defenses need to be automatic; there is no conceivable way for system 
                    ^^^^^^^^^
administrators to respond to threats of this speed. Human-mediated filtering 
provides no benefit for actually limiting the number of infected machines. 
While the filtering may mitigate the overhead of the worm's continuing scan 
traffic, a more sophisticated worm might have stopped scanning once the entire 
susceptible population was infected, leaving itself dormant on over 75,000 
machines to do harm at some future point."

How do you make the defense automatic? 

1/ Can we maintain a worm bank to analyze various signature of 
   the worms? ( as proposed by vern et all "How to own the Internet 
   in Your Spare Time")

2/ The worms lead to lot of DDOS attacks. Can we concentrate on techniques 
   like trace back, pushback? How about deploying RED-PD. If we deploy 
   RED-PD, how to identify/characterize the high-BW flow or DDoS traffic? 

3/ the good old filtering techniques enough? or we have to make it
   more distributed and use some overlay option like Secure Overlay 
   Services[2].

4/ or use a combination of the above three.

> 
> However, the worm wasn't a particularly virulent one, and 
> four hours could be much improved upon.
Given the Microsoft buffer overflow vulnerability, hackers should 
have come up with more destructive pay load. I think they have not 
studied "how to own the internet in your spare time" to make it 
more virulent :)

[1] http://www.cctec.com/maillists/nanog/current/msg03153.html
[2] http://nms.lcs.mit.edu/papers/mayday-usits2003/paper.html
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Sean Donelan <[email-masked]>
Date: Sun, 2 Feb 2003 22:12:30 -0500 (EST)

This is a personal statement, and in no way reflects the opinions of
anyone else.

> to the statement? Did people do any backscatter or trace back analysis

Not that I've seen, but maybe the National Communications System folks
have some data they would like to share with industry.

When looking at data from this incident you need to be careful to consider
that some of the measurement collection systems using MS/SQL were
affected, although the systems they were measuring weren't.  So there are
reports of entire backbones being down, but in fact the backbone was
operating more or less normally. What really happened was the system
collecting statistics about the backbone used MS/SQL to store the data was
infected, or the measurement beacon was in a data center with another
MS/SQL infected system which congested the local network affecting all
measurements of the backbone.

Not to discount the severity of this incident.  But on further analysis,
I've found most of the reports about 5 root servers being infected, or
major Internet backbones collapsing were wrong.

Nevertheless, to stablize the networks at the source or destination,
many ISPs did block *ALL* UDP 1434 packets in the middle of the network.
Government-run networks seemed to have as many infected systems as
everyone else.  Allowing authorized government users to "exempt"
themselves from network management controls would have probably been
unwise in this case.

Did .MIL exempt some infected machines from management controls allowing
them to transmit the infection with high priority packets?

> defaced by hackers in line with the shuttle Columbia incident[1].

The Trippin Smurfs have defaced over 1400 Unix systems (they have a
fondness for Linux, Solaris, etc) over the last 16 months.  They don't
need to rely on security people being "distracted" by a crisis in order to
break into systems.

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 3 Feb 2003 08:02:08 -0500

> them to transmit the infection with high priority packets?

Sean,

	By JCS directive, there is no deployed QoS in any DISA/DIA-operated IP
network.  That is, there is no deployed QoS in NIPRnet, SIPRnet, or the 
more
highly classified US-military IP networks.  Some of the service-unique 
IP networks,
for example USN IP networks which are not operated by or subject to 
DISA,
have had QoS deployed, but I'm not certain of the current deployment 
state
of QoS in those nets these days.

	So no "management controls" (of the sort that exist in GETS-like PSTN 
systems)
actually exist in the DISA-operated IP networks.  Of course they have 
the usual
set of tools available (e.g. router ACLs) should they wish to deploy 
them.

	I'm not currently informed about details of any counter-measures that
might or might not have been deployed to deal with the worm on NIPRnet.

	At least in theory, SIPRnet and the more highly classified networks
do not interconnect at the IP-layer with the global IP network, but 
instead
are  deliberately isolated for security reasons.

Ran
[email-masked]

---

From: Rex Buddenberg <[email-masked]>
Date: 03 Feb 2003 09:11:10 -0800

A bit more ...  and mostly speculative.

The Navy has wrapped IP cocoons around legacy satcom circuits and
terminated them at routers -- the program is called ADNS.  The shore
side of these circuits terminates at the Fleet NOCs which are part of
the NCTAMS (Naval Computer & Telecom Area Master Stations, I think --
there are a handful worldwide).  ADNS has a box (called the CRIU --
CAP-to-Router-Interface-Unit) that has 16 buffers.  The router infers
priorities from IP addresses and port numbers and enqueues to each
buffer accordingly; then they are drained in priority order to the
comms.  So there is a homegrown QoS control.

The fleet NOCs have extensive firewall setup with bastion hosts,
intrusion detection sensors and screening routers.  The screening policy
is tight -- everything is blocked except  a. b. c..  Given what I know
to be blocked, I'd be surprised if SQL packets are passed.  So my guess
is that the afloat networks as well as the plumbing that reaches to them
were pretty well isolated.  

More data.  The Navy runs segregated LANs on its ships.  To feed them
from ashore, they tunnel (using Motorola NES boxes) through the ADNS
structure.  So, as Ran said, as long as the SIPRNET segregation practice
matches the theory, the classified networks should not be affected by
this one.