RE: Bogon list or Dshield.org type list

Mailman List Mirror (Read Only)
1

Having recently read David Moore's paper on backscatter analysis,
http://www.caida.org/outreach/papers/2001/BackScatter/
this data is interesting because most of these filters seem to be blocking
an amount of traffic proportional to their size.

Extended IP access list 120 (Compiled)
   permit tcp any any established (243252113 matches)
   deny ip 0.0.0.0 1.255.255.255 any (825328 matches)

                    ^^^ ^^^^^^
The netmask is twice as large and it blocks twice the traffic as the
following three blocks.

   deny ip 2.0.0.0 0.255.255.255 any (413487 matches)
   deny ip 5.0.0.0 0.255.255.255 any (410496 matches)
   deny ip 7.0.0.0 0.255.255.255 any (413621 matches)
   deny ip 10.0.0.0 0.255.255.255 any (1524547 matches)

RFC 1918 space is different from the rest.

<some deleted to save space>

   deny ip 72.0.0.0 7.255.255.255 any (3300703 matches)

                     ^^^ ^^^^^^^
Eight times as big blocks eight times as much traffic

<some deleted to save space>

   deny ip 224.0.0.0 31.255.255.255 any (13165320 matches)

And the relationship holds even up here in the multicast range.

However, since you are seeing this on your ingress filters, this can't be
backscatter. It must be incoming attack traffic and since the traffic is
evenly distributed over the entire IPv4 address space, you can calculate
how much attack traffic is still getting through by adding up the amount
of IPv4 address space that you aren't filtering. If you would look at the
destination IP addresses from some of the netblocks in the above list,
then you could identify which of your machines (or your customer machines)
are being attacked.

This now provides enough information to identify attack traffic close to
its source. If you would publish the destination addresses and time
periods of the attacks then other people could look in their netflow data
for traffic from bogon addresses to your destination. A central repository
like dshield.org for this data would be interesting.

Other than for idle curiosity, I think this is interesting because there
is the real possibility of being able to identify an attacker and victim
soon enough after an attack begins that the victim could issue legal
warnings to the attacker and possibly follow up in the courts. I would
think that after a few well-publicised cases, the owners of compromised
machines used to initiate DDOS attacks will begin to secure their machines
the way they should have in the first place.

-- Michael Dillon

2

[...]

other people could look in their netflow data
for traffic from bogon addresses to your destination.

  Do other people need such a list to discover invalid source addresses
emerging from their networks?

[...] the owners of compromised
machines used to initiate DDOS attacks will begin to secure their machines
the way they should have in the first place.

  Given. The issue of securing networks has been covered here -- I'd've
figured it would have been worked into this issue as a given, for all
that it makes tracking attacks in the above scenario a tad more
challenging.

Peter E. Fry

3

It was an interesting paper--particularly the care they took in
analyzing their assumptions and the affect they may have on the outcome.
(Thank you).

I feel I should further qualify the numbers submitted, which may further
validate Moore's conclusions. The majority of these packets,
particularly in ARIN unassigned, where generated in a couple isolated
DoS attacks; they do not gradually increment: (aside from 1918--probably
due to misconfigurations and ignorance)
    deny ip 0.0.0.0 1.255.255.255 any (825674 matches)
    deny ip 2.0.0.0 0.255.255.255 any (413488 matches)
    deny ip 5.0.0.0 0.255.255.255 any (410506 matches)
    deny ip 7.0.0.0 0.255.255.255 any (413650 matches)
    deny ip 10.0.0.0 0.255.255.255 any (1553407 matches)

So this would leave me to believe that Moore is generally correct in his
equation:
  nm
E(X)=----
  32
     2
,and that DoS attacks are usually generated derived from the same family
of code (i.e. TFN and that ilk) that completely randomizes the source.
Although I did see Cisco's uRPF paper as a source and brought up edge
filtering as a possible variance, it did not particularly mention a
decreased portion of addresses in the "unassigned" ranges--where
networks such as mine would be filtering these source through ACLs or
uRPF loose-strict where supported, and thus no BackScatter sent. This
leads me to believe that not a significant number of those identified
had such filtering in place.

As far as tracking DoS, I've read some good papers on the subject and it
always boils down to tracking MAC addresses and going interface by
interface to the source, demanding inter-ISP cooperation, and finally
legal assistance. This has been tried during a few severe instances with
poor results. Bots/Zombies are traded openly on IRC and there is no
accountability for personal security. ISPs won't shut someone down
because they've been "hacked", merely send them a warning Email or
call--a process that takes days in my experience. DoS mitigation through
traffic analysis and filtering is where I'm allocating my energy; I've
demo'd a couple vendor solutions, but with less than pleasing results
for the price. I figure the DMCA or something else will get them on
their other illegal activities before I ISPs could persuade the Feds to
slap their wrist for packet floods.

jnull
PGP: 0x54B1A25C
So little time, so many packets

4

Worse -- there is an increasing number of ASNs spewing traffic onto the
internet with NOBODY AT THE WHEEL. We got attacked by some hosts in
UniNet S.A. de C.V. (NETBLK-UNINET-NETBLK-12) UNINET-NETBLK-12
                                                 148.221.0.0 - 148.221.255.255
there is not a single working contact for that netblock. I have been going
in circles with their upstream, AS7911, for two goddamn months trying to
find a working contact for those netblocks. Turns out that AS7911 is
unable to find any contact information for their own customer, and now
they are not returning emails or phone calls at all anymore...

So AS7911 is asleep at the wheel, and AS8151 is a script kiddie network on
autopilot... Be warned. You may want to blackhole AS8151...

-Dan