North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: Bogon list or Dshield.org type list

  • From: jnull
  • Date: Mon Jul 29 14:14:48 2002

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

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
[email protected]
Sent: Monday, July 29, 2002 5:37 AM
To: [email protected]
Subject: RE: Bogon list or Dshield.org type list



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



---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.377 / Virus Database: 211 - Release Date: 7/15/2002
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.377 / Virus Database: 211 - Release Date: 7/15/2002