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
michael.dillon@radianz.com wrote: [...]
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
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: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of michael.dillon@radianz.com Sent: Monday, July 29, 2002 5:37 AM To: nanog@merit.edu 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
On Mon, 29 Jul 2002, jnull wrote:
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.
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 -- [-] Omae no subete no kichi wa ore no mono da. [-]
participants (4)
-
Dan Hollis -
jnull -
michael.dillon＠radianz.com -
Peter E. Fry