- Test - lists.nanog.org

Re: UUNet Routing SNAFU
by Selina F. Priestley 08 Oct '97

08 Oct '97

> In message <v03110710b06160330f78(a)[209.104.193.33]>, Michael Dillon writes: > > > > Isn't this the kind of problems that the Doran filters are supposed to prevent? > > Proper PRDB based filters would have stemmed this too. Why isn't everyone > using them these days? > > -- > Harald Maybe you're thinking RADB, which is based on the distributed Internet Routing Registry, defined by the RIPE folks. Yes, if people define their routes, ASs, and routing preferences in the RADB (or a personal database which they create for their own ISP and make public), then other ISPs can use that information to generate prefix-based configs. The RADB is the database used in the US by providers who do not wish to maintain their own database. CAnet, MCI, and ANS have their own databases. The RIPE database is in use overseas. The PRDB is a years defunct database used by the NSFnet project to configure their routers. Selina P.S. Here's the blurb returned by 'whois -h whois.ra.net' when bogus info is requested: For an overview of the RADB and more information about creating and submitting Route objects, see: http://www.ra.net/RADB.tools.docs/.docs.html ftp://ftp.ra.net/routing.arbiter/radb/OVERVIEW ftp://ftp.ra.net/routing.arbiter/radb/doc/how_to_register ftp://ftp.ra.net/routing.arbiter/radb/doc/updating_maintainers You can obtain the full database files via anonymous ftp: ftp.ra.net:/routing.arbiter/radb/dbase URL: ftp://ftp.ra.net/routing.arbiter/radb/dbase/radb.db.gz

2 1

Re: UUNet Routing SNAFU
by Sean M. Doran 08 Oct '97

08 Oct '97

"Alec H. Peterson" <ahp(a)hilander.com> writes: > It might be a good idea for providers to put up web pages on their > policy for accepting external announcements, for reference purposes. At the same time you should augment your current filtering policies with a list of prices for punching holes through them. Sean.

1 0

multihome w/o BGP4
by Richard Welty 08 Oct '97

08 Oct '97

i recall that some months back, there was discussion of some software which would permit support of multihomed customers without BGP4. cann anyone give me a pointer to some information? thanks, richard welty -- Richard Welty welty(a)inet-solutions.net http://www.inet-solutions.net/~welty/ 888-311-INET

2 1

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