October 1997 - Test - lists.nanog.org

Filters
by Michael Dillon 09 Oct '97

09 Oct '97

>Do you have a ready pointer to a document describing Sean's filters? I suppose this should be a public answer so here goes... http://www.nanog.org/filter.html Take a moment to check out the nanog.org pages every once in a while because they do add new stuff from time to time. ******************************************************** Michael Dillon voice: +1-650-482-2840 Senior Systems Architect fax: +1-650-482-2844 PRIORI NETWORKS, INC. http://www.priori.net "The People You Know. The People You Trust." ********************************************************

1 0

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

09 Oct '97

Let me try again, since it seems I wasn't clear enough. There's been a lot of delightful talk about whether/how to retrieve the calling phone on a given port. But none about how to determine with confidence which port the nasty packets come from. Without source address assurance, any user on any port of any dialin box can source packets with any IP address(es) desired. So you don't know which port to go get ANI/CLID for. What is also not explained is how to produce multi-megabit streams from dialup. MP? Multiple independent calls? Ping to broadcast with faked source address? Or was the attack not from dialup at all? In other words, I don't know why this attack generated a debate about ANI/CLID. Barney Wolff > Date: Wed, 8 Oct 1997 10:33:16 -0500 (CDT) > From: Joe Shaw <jshaw(a)insync.net> > To: Barney Wolff <barney(a)databus.com> > Cc: nanog(a)merit.edu > Subject: Re: Denial of service attacks apparently from UUNET Netblocks > Content-Length: 1151 > > On Tue, 7 Oct 1997, Barney Wolff wrote: > > > 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> > > What he means is that he can provide the number of the person who dialed > into his equipment. That information can be given to you on your PRI, and > reported in both radius accounting and syslog. > > Joe Shaw - jshaw(a)insync.net > NetAdmin - Insync Internet Services > >

5 7

Re: UUNet Routing SNAFU
by Matt Ranney 08 Oct '97

08 Oct '97

"Dorian R. Kim" <dorian(a)blackrose.org> writes: [...] > 62/8, 63/8 and 64/8 are being assigned now. > > So you just relax the filters according to what's being assigned. So is there any good way of hearing about these new assignments as they are made so we could adjust our filters before people complain? -- Matt Ranney - mjr(a)ranney.com Let's not let the students run the High School.

6 6

Is 701 becoming 7007?
by cameo 08 Oct '97

08 Oct '97

Sometimes, in times like these, one has a hard time telling the difference. Another "router bug?" Bahaha.

1 0

Re: OSPF Vs EIGRP
by Shaun S. Amini 08 Oct '97

08 Oct '97

Majority of Networks are running OSPF and a few larger ones like UUNET are running ISIS. For the most part, you will never need run ISIS. My recommendation would be to implement OSPF, it has a lot more knobs for tuning. If you are careful, you can even run OSPF and EIGRP together during the migration period and migrate one site at a time without any down time. At 04:50 PM 10/8/97 -0500, you wrote: >Dave do you know of any Global Corporations that are using EIGRP ? >IF so, what do they do when a major merger takes place and the corporation aquires a large amount of non Cisco routers throughout their newely aquired global network ? I have also been trying to locate a case study of the percentage of global IP networks currently using OSPF Vs EIGRP and any recent trends towards one or the other ? > With Regards, Shaun S. Amini samini(a)diginetusa.net www.diginetusa.net

1 0

OSPF Vs EIGRP
by Patrick O'Keefe 08 Oct '97

08 Oct '97

Dave do you know of any Global Corporations that are using EIGRP ? IF so, what do they do when a major merger takes place and the corporation aquires a large amount of non Cisco routers throughout their newely aquired global network ? I have also been trying to locate a case study of the percentage of global IP networks currently using OSPF Vs EIGRP and any recent trends towards one or the other ?

2 1

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