RE: short Botnet list and Cashing in on DoS
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Paul Vixie Sent: Thursday, October 07, 2004 12:29 PM To: nanog@merit.edu Subject: Re: short Botnet list and Cashing in on DoS
..., a-la spamhaus. Bothaus anyone?
The problem with that is the list rapidly updates and must be maintained with some level of frequency and there's a level of trust involved in it as well.
i consider www.cymru.com to be an excellent beginning toward that goalset.
Going after the bots is lesser effort. The controllers are a priority.
wide scale BCP38 conformity is the only way any of this will ever happen.
You mean the bots? The controllers are behind the bots. Also, in John's presentation..: http://www.nanog.org/mtg-0410/pdf/kristoff.pdf [..]we additionally request that they resolve the RR to 127.0.0.3 before they lock out and reload the zone. We picked 127/8 as the standard. RFC 1918 wasn't suitable for obvious reasons. -M
On Wed, 20 Oct 2004 15:14:29 -0400 "Hannigan, Martin" <hannigan@verisign.com> wrote:
[..]we additionally request that they resolve the RR to 127.0.0.3 before they lock out and reload the zone.
We picked 127/8 as the standard. RFC 1918 wasn't suitable for obvious reasons.
[ I know you know this Martin, but for some list subscribers... ] As I briefly mentioned in the presentation, 127/8 addresses can be problematic also. 127.0.0.3 is better than 127.0.0.1, but there are some cases where a self-inflicted reflection attack can occur. Take for example what happened to some organizations when Blaster struck. Some organizations changed their local recursive DNS servers so that they were authorative for the windowsupdate record and then pointed it to 127.0.0.1. When the Blaster clock struck midnight (so to speak), the attack against that name did not reach Microsoft, but it did tend to result in odd-looking TCP RST packets on the local network. When the worm attacked the resolved name, it attacked 127.0.0.1, which would normally sound fine, but the worm did so using spoofed source addresses. Most infected hosts not having a process on the attacked port (TCP port 80), would issue a TCP reset to the spoofed source. Arguably a dumb thing for a system to do, but regardless it would happily send responses onto the wire to the spoofed address using a source address of 127.0.0.1. A number of admins then began wondering why they were seeing all these RSTs from a loopback address on their net. Hopefully anti-spoofing knobs were enabled and they didn't get far, but even on some local segments that might have caused a noticeable load problem. Interestly some systems will respond to certain types of packets to any local address. So even using something besides 127.0.0.1 may result in this odd reflection behavior. My guess is that it isn't that big a deal since it should be localized as far as anti-spoofing knobs are enabled. I kind of like the idea of using 240/4 for closing names especially since many network operators I suspect are more likely to notice (and hopefully do the host mitigation) when hosts send to bogons rather than when hosts are doing DNS queries that result in bogon answers (even if hosts are querying excessively for them). I may be wrong, but I tend to think 240/4 is in less likely to be in use than any of the other reserved or special use space. In another somewhat related session about DNS issues, when it was suggested that a well known address be used to close with, someone at the mic suggested that using well known addresses for this purpose may not be good practice. I think they were referring in part to Dave Plonka's draft about embedding globally routable addresses in hardware, which I don't think applies in this case, but maybe I missed something. Their argument may be worthwhile to consider for other reasons. John
participants (2)
-
Hannigan, Martin
-
John Kristoff