- Test - lists.nanog.org

UDP Port 2002 DDOS?
by Scott Call 17 Sep '02

17 Sep '02

I apologize if this is an obvious question, but I've search bugtraq and other sources... I've had two customers complain today about massive amounts of incoming UDP traffic on port 2002. They appear to be some kind of DDOS or spoofed attack since the origin IPs on each packet are different. Is anyone else seeing something similar? Thanks -S -- Scott Call Router Geek, ATGi, home of $6.95 Prime Rib "Copyright Law is not a tool of repression granted to an unaccountable corporation by a corrupt congress at the expense of an ignorant public." -WW

1 0

RE: Testing BGP with real UPDATEs
by Vandy Hamidi 17 Sep '02

17 Sep '02

If you are testing the receipt of routes and inbound filtering, I just block all outbound advertisements and connect to an ISP or one of my border routers. That way you can test your filters and inbound access-lists and manipulate the BGP tables before putting the router into production. Hope that helps some, -=Vandy=- -----Original Message----- From: Sathya Perla [mailto:sperla@netplane.com] Sent: Tuesday, September 17, 2002 4:12 AM To: 'nanog(a)merit.edu' Subject: Testing BGP with real UPDATEs Hi, How is a BGP implementation tested with real Internet routing data (BGP UPDATEs)? Are there any experimental/test networks that can be connected to for testing a BGP implementation? Thanks, -Sathya

1 0

Re: How do you stop outgoing spam?
by Brad Knowles 17 Sep '02

17 Sep '02

At 1:51 PM -0400 2002/09/17, Greg A. Woods wrote: > No, Dave's second sentence is not true, thus his conclusion is bogus. Dave was talking about "normal" TCP connections, and I was following the same model. If you're talking about hi-jacking the TCP connection, then you are correct. > If you're talking about commercially available product, perhaps.... > > However this kind of thing is trivial with basic IPsec gateways and > simple filtering ala IP Filter, etc. How many ISPs use IPsec gateways and simple filtering with tools like IP filter? How scalable is this sort of thing? Could AOL do it with dozens or hundreds of OC-48 and OC-96 links? How long would it take to fix all the ISPs in the world that might potentially do transparent proxying of port 25? And where is the intelligence to selectively forward only those connections that are themselves encrypted and authenticated? -- Brad Knowles, <brad.knowles(a)skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)

1 0

Re: How do you stop outgoing spam?
by Brad Knowles 17 Sep '02

17 Sep '02

At 10:26 AM -0700 2002/09/15, Dave Crocker wrote: > 2. The issue with email is authentication, not privacy. > Authentication can be achieved can be achieved easily over port > 25, without encryption. Hence, blocking port 25 blocks > legitimately validated email, as well as possible spam. True enough. However, there are no intelligent transparent proxies that I know of which will allow authenticated and/or link-encrypted port 25 connections through to the indicated site, and shunt the non-authenticated/non-encrypted sessions to the side. Since this information is only available at the IP level, this is not something you can fix inside the SMTP MTA -- the critical information is destroyed before then. I imagine if you could get cisco (and other vendors) to fix their transparent proxy server software to be more intelligent, that would fix the problem. -- Brad Knowles, <brad.knowles(a)skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)

2 2

Re: Eugene Call for Presentations
by Susan Harris 17 Sep '02

17 Sep '02

Thanks Henk! We'll be back in touch in later in September, once all the NANOG26 submissions have been received and reviewed. Susan Harris, Ph.D. Merit Network/Univ. of Mich. On Mon, 16 Sep 2002, Henk Uijterwaal (RIPE-NCC) wrote: > Hi Susan, > > > Hi - just a reminder that abstracts are due this Monday, Sept. 16. > > > CALL FOR PRESENTATIONS > > I'd like to propose the following presentation: > > > New services from the RIPE NCC > ------------------------------ > > During the last 5 years, the RIPE NCC has been working on 2 new services > for the entire ISP community: TTM or Test Traffic Measurements, and the > RIS or Routing Information Service. These projects were presented at the > Spring 1999 NANOG meeting but a large number of new features have been > added during the last 3 years. > > TTM: The TTM now consists of a network of +/- 70 machines, measuring > delay and loss between sites all over the world. Since 1999, 2 new > measurements have been added: > > - IP Delay Variations a.k.a. Jitter > - Bandwidth measurements, providing an estimate of both the > total available bandwidth between sites as well as the > unused bandwidth. > > We also would like to take this opportunity to present the new > CDMA based version of the measurement device. CDMA is a 3rd > generation mobile telephony standard that, as a side effect, > produces a timing signal. This timing signal can be used to measure > the performance of both IPv4 and IPv6 networks down to the 10 > microsecond level, anywhere when one can use a mobile phone without > the need for an expensive and hard to install GPS system. > > RIS: The RIS is now collecting BGP information from 9 sites world-wide, > with collectors in North American, Europe and Asia, with some 200 > ISP's participating by providing a BGP feed. New applications (since > the project was presented at the Spring 1999 NANOG) of the data > include: > > - Daily lists of hot-spots with the most active prefixes > - Analysis of flaps in the routing table. > - Detection of AS's and prefixes announced by ISP's but not properly > registered in the whois data-base and/or not assigned to them. > - Multi homing effects. > > This talk gives a short overview of the various services and how they can > be used in daily ISP operations, using the shutdown of a major European > backbone provider that recently went bankrupt as an example. > > Henk > > > ps. While I hope that more people will start using these services after > this talk, this is definitely not a sales talk. > > > Comment: I can do this talk in either one of 2 ways (or both): a short > plenary presentation (20 mins or so), showing the highlights and URL's, > inviting people to try these at home, or a longer version (2 hours or so) > showing people the details. The latter would be more suitable for a > tutorial or BOF. Just let me know what you prefer. > > > > > ------------------------------------------------------------------------------ > Henk Uijterwaal Email: henk.uijterwaal(a)ripe.net > RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk > Singel 258 Phone: +31.20.5354414 > 1016 AB Amsterdam Fax: +31.20.5354445 > The Netherlands Mobile: +31.6.55861746 > ------------------------------------------------------------------------------ > > That problem that we weren't having yesterday, is it better? (Big ISP NOC) > > NOTE: My email address (and a hole in our mailing list software) is being > abused by a spammer. We are working on fixing this hole and tracking > the spammer down. If you receive mail from "henk(a)ripe.net" that is > obviously spam, please send me a copy of the mail including ALL headers. > I'm sorry for any inconvenience caused by this. > >

1 0

Re: Vulnerbilities of Interconnection
by sgorman1＠gmu.edu 17 Sep '02

17 Sep '02

"Again, it seems more likely and more technically effective to attack internally than physically. Focus again here on the cost/benefit analysis from both the provider and disrupter perspective and you will see what I mean." Is there a general consensus that cyber/internal attacks are more effective/dangerous than physical attacks. Anecdotally it seems the largest Internet downages have been from physical cuts or failures. 2001 Baltimore train tunnel vs. code red worm (see keynote report) 1999 Mclean fiber cut - cement truck AT&T cascading switch failure Utah fiber cut (date??) Not sure where the MAI mess up at MAE east falls Utah fiber cut (date??) Then again this is the biased perspetive of the facet I'm researching Secondly it seems that problems arise from physical cuts not because of a lack of redundant paths but a bottlneck in peering and transit - resulting in ripple effects seen with the Baltimore incident. ----- Original Message ----- From: "William B. Norton" <wbn(a)equinix.com> Date: Thursday, September 5, 2002 3:04 pm Subject: Re: Vulnerbilities of Interconnection > > At 02:45 PM 9/5/2002 -0400, alex(a)yuriev.com wrote: > >This obviously would be a thesis of Equinix and other collo space > providers,>since this is exactly the service that they provide. It > won't, hower, be a > >thesis of any major network that either already has a lot of > infrastructure>in place or has to be a network that is supposed to > survive a physical > >attack. > > Actually, the underlying assumption of this paper is that major > networks > already have a large global backbone that need to interconnect in > n-regions. The choice between Direct Circuits and Colo-based cross > connects > is discussed and documented with costs and tradeoffs. Surviving a > major > attack was not the focus of the paper...but... > > When I did this research I asked ISPs how many Exchange Points > they felt > were needed in a region. Many said one was sufficient, that they > were > resilient across multiple exchange points and transit > relationships, and > preferred to engineer their own diversity separate from regional > exchanges. > A bunch said that two was the right number, each with different > operating > procedures, geographic locations, providers of fiber, etc. , as > different > as possible. Folks seemed unanimous about there not being more > than two > IXes in a region, that to do so would splinter the peering population. > > Bill Woodcock was the exception to this last claim, positing > (paraphrasing) > that peering is an local routing optimization and that many > inexpensive > (relatively insecured) IXes are acceptable. The loss of any one > simply > removes the local routing optimization and that transit is always > an > alternative for that traffic. > > > > > > A couple physical security considerations came out of that > research:> > 1) Consider that man holes are not always secured, > providing access to > > > metro fiber runs, while there is generally greater security within > > > colocation environments > > > >This is all great, except that the same metro fiber runs are used > to get > >carriers into the super-secure facility, and, since neither those who > >originate information, nor those who ultimately consume the > information are > >located completely within facility, you still have the same > problem. If we > >add to it that the diverse fibers tend to aggregate in the > basement of the > >building that houses the facility, multiple carriers use the same > manholes>for their diverse fiber and so on. > > Fine - we both agree that no transport provider is entirely > protected from > physical tampering if its fiber travels through insecure > passageways. Note > that some transport capacity into an IX doesn't necessarily travel > along > the same path as the metro providers, particularly those IXes > located > outside a metro region. There are also a multitude of paths, > proportional > to the # of providers still around in the metro area, that provide > alternative paths into the IX. Within an IX therefore is a > concentration of > alternative providers, and these alternative providers can be > used as > needed in the event of a path cut. > > > > > 2) It is faster to repair physical disruptions at fewer > points, leveraging > > > cutovers to alternative providers present in the collocation > IX model, as > > > opposed to the Direct Circuit model where provisioning additional > > > capacities to many end points may take days or months. > > > >This again is great in theory, unless you are talking about > someone who > >is planning on taking out the IX not accidently, but > deliberately. To > >illustrate this, one just needs to recall the infamous fiber cut > in McLean > >in 1999 when a backhoe not just cut Worldcom and Level(3) > circuits, but > >somehow let a cement truck to pour cement into Verizon's manhole > that was > >used by Level(3) and Worldcom. > > Terrorists in cement trucks? > > Again, it seems more likely and more technically effective to > attack > internally than physically. Focus again here on the cost/benefit > analysis > from both the provider and disrupter perspective and you will see > what I mean. > > > >Alex > > >

25 43

Testing BGP with real UPDATEs
by Sathya Perla 17 Sep '02

17 Sep '02

Hi, How is a BGP implementation tested with real Internet routing data (BGP UPDATEs)? Are there any experimental/test networks that can be connected to for testing a BGP implementation? Thanks, -Sathya

1 0

Inter-ISP security procedures?
by Rajesh Talpade 17 Sep '02

17 Sep '02

Hi! Could someone please point me to BCP documents or products that permit an ISP to better interact with its peers/upstreams in case of DoS and worm attacks that cross ISP network boundaries? The approach I have seen so far involves a judicious combination of abuse@isp emails and frantic phone calls to NOC contacts. Thanks! Rajesh.

7 14

NSP Security List
by Barry Raveendran Greene 17 Sep '02

17 Sep '02

Hello Everyone, Thanks to Jared's sponsorship, we are creating a nsp-* mailing list for the NSP Security Operations community. We will use the nsp-security for NSP security coordination and consultation. We expect most of the consultation to be on procedures, polices, tools, mitigation techniques, and other proactive activities. We will also try to use the list as an incident response alias - tracking and mitigating attacks in progress. Membership to the alias will be restricted to those actively mitigating of NSP Security incidents. Therefore, it will be limited to operators, vendors, researchers, and FIRST team and other people in the NSP operations community working to stop attacks. That means no press and (hopefully) none of the "bad guys." We will use a simple trust/peering relationship used on some of the other aliases. This model is not as "secure" as an encrypted conversation, but better than a wide-open public dialog. We will establish the trust by asking members of the list to vouch for new subscriber requests. If the list administrators know the person, then they can vouch for them. Yes, we have had similar "security" lists in the past. With nsp-security we will connection the E-mail dialog with face-to-face meetings in the operations conferences. The first "meeting" is the ISP Security BOF at the next NANOG. Like NANOG's Peering BOF, the ISP Security BOF is a facilitation tool ... bring together people living with the daily pain of ISP Security incidents. So the hope is the combination of face-to-face and private E-mail list will help use take forward steps. So apply for subscription, send a note to: nsp-security-request(a)puck.nether.net with the word "subscribe" in the subject or body of the message. Alternatively, you can use the web page at: http://puck.nether.net/mailman/listinfo/nsp-security Barry PS - Looking for a couple more volunteers to help as administrators. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Barry Raveendran Greene | || || | Senior Consultant | || || | CTO Corporate Consulting | |||| |||| | | ..:||||||:..:||||||:.. | e-mail: bgreene(a)cisco.com | C i s c o S y s t e m s | Phone: +1 408 525-8089 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Recent NANOG postings
by hrs＠hushmail.com 16 Sep '02

16 Sep '02

I am very pleased to see the recent decrease in off-topic postings. I was having great difficulty blocking mail. Husan R. Sarris, Ph.D. (Pig-headed Dictator) Nerit Metwork Get your free encrypted email at https://www.hushmail.com

7 7