- Test - lists.nanog.org

Denial of service attacks apparently from UUNET Netblocks
by Karl Denninger 08 Oct '97

08 Oct '97

Ladies and Gentlemen, This evening, at 11:45 PM CDT, a serious and severe denial of service attack was launched against MCSNet. This was a very well-coordinated effort which crippled us for over an hour. The individuals involved sourced traffic from 207.76.*.* towards *unicast* addresses within our network and to bogus addresses also in the same netblocks. The machines implicated individually as sources, so far, all appear to be MAX TNTs within UUNET's core. Examples are 207.76.40.175 and 207.76.57.161/164. Each of the source addresses hit several machines with essentially-identical packet and byte counts over a sustained period. The attack came from several different core blocks in 207.76, and was received on *both* of our primary DS-3 feeds, burying the core network segments inside our Chicago offices and rendering the network essentially unusable. We have taken measures to both capture repeat attempts and filter selected source locations in an attempt to prevent a reoccurance. We *did* get a good trace on the tail end of the attack; it clearly delineated the source of the data. Due to the highly-concentrated nature of this attack, its unicast destinations, the fact that we refuse source-routed traffic and further refuse directed broadcasts, I am at this point assuming that the source addresses which we saw are genuine. This might indicate that either someone inside UUNET was responsible, or that someone has penetrated UUNET's internal security and compromised the source devices. As TNTs are typically connected to very-high-speed egress pathways, they would be quite capable of sourcing the data flows we saw this evening. Again, this was *NOT* a smurf attack; it neither fit the profile nor would it have had the pattern of source and destination addresses which we captured. We are treating this as a criminal matter and referring it to the federal authorities in the morning. At this point our network status is nominal. Other operators may wish to be on the lookout for similar types of attacks, and extreme packet rates which are sourced from these address blocks. We have taken preventive measures against a repeat performance; this may inconvenience some legitimate users, but frankly, until we can figure out what's going on and UUNET decides to get on the phone with us relating to this incident we're going to act conservatively to preserve our operational status. Again, we're not casting aspersions on UUNET directly in this matter, other than the documented fact that the source addresses of the packets were all within the above listed netblock. However, it is worthy of note that of the various carriers we contacted during this incident, NONE were able to be reached with someone who knew what they were doing for over an *HOUR*. Folks, this is unacceptable. Our customers were in touch with me inside of 10 minutes into this thing, and I find it incredible that none of the other national providers involved think this kind of incident is important enough to have people on-call and available during off-hours to cover this. If someone of these people HAD been available, we might have caught the perpetrator(s) in the act. -- -- Karl Denninger (karl(a)MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | NEW! K56Flex modem support is now available Voice: [+1 312 803-MCS1 x219]| 56kbps DIGITAL ISDN DOV on analog lines! Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal

22 39

Re: Denial of service attacks apparently from UUNET Netblocks
by Barney Wolff 08 Oct '97

08 Oct '97

> Date: Tue, 7 Oct 1997 12:04:27 -0400 (EDT) > From: Alex Przekupowski <oop(a)idt.net> > > On the MAX's that I have set up, I log that info to syslog (Local 7), and > can pull it up at will. If you need a hand, just let me know. By > combining the syslog output, and the RADIUS accounting logs, we can > definately prove at least the home address of the attacker. How are you providing source address assurance, on either a MAX or a TNT? My understanding, which may well be flawed, is that the only way is with a filter. I have heard claims, which may also be flawed, that filters have a severe performance impact on MAX and TNT. Without source address assurance, how do you know that the packets are actually coming from the user who was assigned that address at that time? Barney Wolff <barney(a)databus.com>

2 1

Re: 73K prefixes?
by John A. Tamplin 08 Oct '97

08 Oct '97

Well, at least we know our routers can handle an additional 30k prefixes out of this :). John Tamplin Traveller Information Services jat(a)Traveller.COM 2104 West Ferry Way 205/883-4233x7007 Huntsville, AL 35801

2 1

Re: Denial of service attacks apparently from UUNET Netblocks
by Sean Donelan 08 Oct '97

08 Oct '97

>Security teams at ISPs should also obtain contact information for >their local and federal law enforcement offices. Such contacts >should be tested regularly, (eg; monthly) to ensure they are >accurate. You can also ask Law Enforcement to provide you with >a briefing on the types of computer investigations they are >working on and seeing, which may help you plan your method of attack or >compensation, or help you justify your continued existance with your >upper management. Since most of the top government computer & network security people are in Baltimore, MD this week, you might try again next week :-) Anyone want to have a BOF at the NSA/NIST conference for ISP security personnel? Once again, federal law enforcement made a public plea for companies and individuals to report attacks. Although they also said they may not be able to do anything due to lack of resources, they made the point they can't justify adding resources if no one reports crimes. Unfortunately law enforcement computer crime jurisdiction is still a hodge-podge of overlapping agencies. In the end you may be better off hiring a retired federal law enforcement person for your security department. Even if they know nothing about computers, they can talk the talk to get action out of the various law enforcement agencies. Robert Steele calls it "hacking the buearacracy." >Also, MCI has released a Denial Of Service "tracking" program >called DoStracker that helps to automate detection and tracing of >these types of attacks through large backbone networks. Nice program, thank you. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

4 3

Re: UUnet routes from hell..
by brett watson 08 Oct '97

08 Oct '97

> > Uhm, yeah. It seems they decided that they wanted 128.0.0.0/9 or so, and > decided that the easiest way to get it is announce it all as /24's. Spiffy. > > At least it was fixed relatively quickly. the question remains, was this a bug in some version of their code? or could someone have actually mis-configured something this drastically? -brett

1 0

Re: Denial of service attacks apparently from UUNET Netblocks
by Sean Donelan 08 Oct '97

08 Oct '97

>I realize this is probably something one learns in Telco 101, which I >haven't taken, but if CNID == Caller ID, wouldn't ANI be *more* useful? It depends on what you want. A real call trace is more involved. But if all you are interested in is the billing information, then ANI usually works. If all you are interested in is the directory number then CLID works. In general, it is bad news for ISP geeks to play telephone guru, and bad news for telephone geeks to play ISP guru. >Or does CNID report the number regardless of Caller-ID blocking on PRI >lines/etc? No. Assuming the telco programs the switch correctly, blocked CLID won't be passed on subscriber lines. Mistakes happen, but don't count on it. >(I'm assuming that CNID == standard Caller-ID as it appears on POTS, and >that ANI == the special service that 800-lines get that *always* reports >the number, regardless of blocking..if I'm wrong, I'll accept the LART.) The alternative is to become a CLEC, and buy something like a FGB circuit with ANI or full-fledge SS7 trunks with per-minute usage fees, aka settlements. If you only want to pay standard POTS rates for your dialup lines, you only get standard POTS service. I think the telco's blew it when they tried to impose per minute fees on ISPs. Rather than thinking up nifty new services ISPs might want on the lines, and create a demand for improved lines, the telcos tried ramming through tariff changes for more money for the same service and ended up losing even more. The current dialup/packet-switched interface is such a kludge anyway. We've got to work on getting real packet-switched data service to the home for a number of reasons, not the least to get rid of this interference layer between the circuit switched identifier and the packet switched identifier. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Sample dampening entry
by Bob Collie 08 Oct '97

08 Oct '97

Does anyone have a sample dampening config that the would be willing to share? What are the generally-accepted dampening penalties per prefix? I'm planning to implement it on my routers, and just wanted to get a poll of what everyone was using. -Bob -- Bob Collie, VP/CTO, Telalink Corporation mailto:bob.collie@telalink.net

1 0

73K prefixes?
by Jonathan Heiliger 08 Oct '97

08 Oct '97

anyone else seeing this? BGP table version is 7270729, main routing table version 7270729 73487 network entries (235540/419163 paths) using 21848380 bytes of memory 15689 BGP path attribute entries using 2281792 bytes of memory 10269 BGP route-map cache entries using 164304 bytes of memory 19134 BGP filter-list cache entries using 306144 bytes of memory -jh-

8 8

Re: BGP?
by Sanjay Dani 08 Oct '97

08 Oct '97

> Is this the new BGP DoS attack? Or did the Internet routing table > just double in two hours from new ARIN policies ;) >UUnet reports an "oops" and it should be fixed by 9:15 EST. wheeeee... Maybe their network engineer prematurely started to announce specifics within 3561 and 1957 in addition to a few other acquisitions Bernie will announce in the morning tomorrow :-) > BGP table version is 12415019, main routing table version 12415019 > 78724 network entries (129728/289118 paths) using 18517816 bytes of memory Sanjay. --------------------------------------------------------------- Web Professionals, Inc. Direct: +1 408-863-4850 20111 Stevens Creek Blvd, Suite 145 Biz/NOC: +1 408-863-4848 Cupertino CA 95014 USA http://web.professionals.com --------------------------------------------------------------- -=- Your Outsourcing Partner in Website and Server Hosting -=-

1 0

UUnet routes from hell..
by Harold Willison 08 Oct '97

08 Oct '97

Here is what AGIS is seeing.. BGP table version is 35293027, main routing table version 35293027 76174 network entries (103312/230110 paths) using 15856492 bytes of memory 11155 BGP path attribute entries using 1438184 bytes of memory 3682 BGP route-map cache entries using 58912 bytes of memory 9872 BGP filter-list cache entries using 157952 bytes of memory Dampening enabled. 18898 history paths, 1516 dampened paths Is it just me or did you all notice the influx of 30,000+ routes with a 701 as, This is what Digex is seeing... BGP table version is 20811375, main routing table version 20811375 79158 network entries (173777/371074 paths) using 20851336 bytes of memory 24653 BGP path attribute entries using 3466820 bytes of memory 7506 BGP route-map cache entries using 120096 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory Dampening enabled. 8747 history paths, 7465 dampened paths UUnet reports an "oops" and it should be fixed by 9:15 EST. wheeeee... *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* | Harold Willison AGIS Network Engineering | * News Admin. 313-730-5151 * | news(a)agis.net 24 hours a day, 7 days a week | * harold(a)agis.net noc(a)agis.net * | <bold><italic> <underline>http://www.agis.net</underline></italic></bold> |<bold><italic> </italic></bold>\*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*/

2 1