BCP38 making it work, solving problems
Suresh Ramasubramanian
suresh at outblaze.com
Wed Oct 13 12:07:32 UTC 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 ...
http://lists.planet-lab.org/pipermail/announce/2004-April/000012.html
> [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
> purpose.
>
> Larry
>
> ------------------------------
>
> 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
> large-scale behavior.
>
> 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.
>
More information about the NANOG
mailing list