North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: BCP38 making it work, solving problems
- From: Suresh Ramasubramanian
- Date: Wed Oct 13 08:13:07 2004
Randy Bush wrote:
For the week starting Sept 12, our dark space telescope "saw" 1675
spoofed DDOS attacks.
any idea why someone(s) is ddosing dark space? seems a bit silly.
Something like this I rather fancy ...
[Planetlab-announce] network telescope Larry Peterson llp at
CS.Princeton.EDU Thu Apr 15 16:31:24 EDT 2004
* Previous message: [Planetlab-announce] Cambridge meeting * Messages
sorted by: [ date ] [ thread ] [ subject ] [ author ]
I have a request to make of PlanetLab sites... There is an effort
underway to collect information about worms, ddos backscatter, and
other suspect activity on the Internet. Our ability to do this sort
of analysis would be greatly enhanced by having access to IP address
blocks spread across the Internet, for example, at as many PlanetLab
sites as possible. My specific request is for sites to contribute
blocks of, say, 16 otherwise unused addresses to PlanetLab. I have
attached a note from Vern Paxson outlining the idea, a so called
"network telescope". Please let me know if your site would be willing
to contribute (assign) some number of addresses to PlanetLab for this
A basic challenge for analyzing Internet-scale malicious phenomena
such as worms and automated scanning is acquiring sufficiently broad
visibility into their workings. Monitoring at a single location may
for example miss the early stages of a worm's spread or, more
generally, lack the diverse perspectives necessary for capturing
A powerful tool for acquiring such broader visibility is a "network
telescope". Network telescopes monitor traffic sent to communication
dead-ends such as unallocated portions of the IP address space or
ports on endhosts for which no server is listening. Since there is
no legitimate reason for a host to send packets to those
destinations, such traffic provides strong evidence of malicious
activity - including DDoS backscatter, port scanning, and probe
activity from worms.
Our goal is to build a large-scale telescope with significantly more
sampling breadth and diversity than current telescopes. This
telescope will be structured as two layers. Its front-end sensors
will be spread across a large number of address blocks and monitoring
points to achieve sampling diversity. We'll use both unallocated
address blocks (which attackers can learn about fairly easily) but
also unused subblocks within allocated blocks. This latter "dark
address space" is much more difficult for an attacker to learn about
and also enables highly diverse distribution of the sensors.
It's this latter that we're hoping can be done in conjunction with PL
nodes. In particular, the way we picture it working is that the PL
nodes will have multiple addresses assigned to them. A monitor
running on the host then tunnels traffic it receives on the extra
addresses over to the analysis point. It could also tunnel traffic
sent to its "normal" address but for which there's no listener.
One crucial issue with building a large telescope is *filtering*.
For a very large telescope, the volume of data collected can be
enormous. However, for many forms of analysis we can often filter out
a great deal of the traffic. For example, for worm detection we can
drop traffic seen by the sensor rather than forwarding it if the
traffic does not correspond to worm activity of possible interest
(e.g., it's instead DoS backscatter, or activity from known worms).
Because PL nodes can do computation before they forward traffic over
the tunnel (unlike, for example, telescope sensors based on using
routers), they make ideal platforms for developing such filtering.