March 2003 - Test - lists.nanog.org

RE: spamcop.net?
by blitz 04 Mar '03

04 Mar '03

As of this writing, theyre back up, albeit slowly....thanks everyone who looked into this. Marc macronet.net At 19:54 3/3/03 -0700, you wrote: >I cant get to them either and others cant as well. > >Multiple Image Corporation - www.multipleimage.com >Hosting plans starting at only $4.95 per month > >-----Original Message----- >From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of >blitz >Sent: Monday, March 03, 2003 7:41 PM >To: nanog(a)merit.edu >Subject: spamcop.net? > > >Anyone having trouble getting to/ know of any issues with spamcop.net >today? > >They seemed to have dropped off the radar from me... > >No pings >No traceroute > >but they still show registered at 216.127.43.89 > >Tnx > >Marc >macronet.net

1 0

spamcop.net?
by blitz 03 Mar '03

03 Mar '03

Anyone having trouble getting to/ know of any issues with spamcop.net today? They seemed to have dropped off the radar from me... No pings No traceroute but they still show registered at 216.127.43.89 Tnx Marc macronet.net

3 2

Re: BGP to doom us all
by Avi Freedman 03 Mar '03

03 Mar '03

In article <10322.05320.15507(a)avi.netaxs.com> The Great Sean wrote: : I'll be stupid, and ask some questions I've always wondered about. : Why should routes learned by eBGP have a higher priority than iBGP? Love to know myself. Took me a few years to figure out why the strange iBGP redistribution rules (because barring something like confeds or RRs, there's no loop detection method in iBGP w/o it...) : Why should BGP implementations flap all good routes when they see a single : bad route packet? Sorry if this isn't adding enough signal, but Amen! However, there's some disagreement historically about this. I am in the camp who thinks the danger is higher from being able to trigger massive #s of session drops cyclically, but some argue that it's worse to continue talking to someone who may be spewing badness that you only see as syntax error, but some packets may have OK syntax and bad contents. This may be doomed to the neverending debate category, but I feel fairly strongly that I'd at least like a knob that makes NOTIFY not kill sessions (but you'd probably need to twist it it at both ends of the session). : Why don't SWIP forms include Origin-AS? Ahem. Origin-AS(s) - plural. Agreed - mildly. Of course, SWIP isn't updated when delegation info changes, so origin AS(s) would get just as stale as contact info. Avi

4 3

RE: Who uses RADB? [was BGP to doom us all]
by Jim Deleskie 03 Mar '03

03 Mar '03

I know when we separated Concert from iMCI we where using the filters on them, and they IMO would have been a peer, but then again Concert sould have been a special case either way. -Jim -----Original Message----- From: Danny McPherson [mailto:danny@tcb.net] Sent: Monday, March 03, 2003 11:59 AM To: nanog(a)merit.edu Subject: Re: Who uses RADB? [was BGP to doom us all] Yes, at iMCI (we) had our own registry, MCI-RR, but we only used it (in addition to data from the other IRRs) to generate customer prefix filters, not peers. Cable & Wireless still uses the RR, now know as CW-RR. -danny > As I remember and I could be wrong, its been a few years now, when I worked > for iMCI we did and we moved over to C&W we still did.

1 0

Fw: ISS Security Brief: Remote Sendmail Header Processing Vulnerability
by Matt Fearnow 03 Mar '03

03 Mar '03

Not that this is concerned with any network equipment or network operations per say, but I'm sure that alot of you do run sendmail. -----BEGIN PGP SIGNED MESSAGE----- Internet Security Systems Security Brief March 3, 2002 Remote Sendmail Header Processing Vulnerability Synopsis: ISS X-Force has discovered a buffer overflow vulnerability in the Sendmail Mail Transfer Agent (MTA). Sendmail is the most common MTA and has been documented to handle between 50% and 75% of all Internet email traffic. Impact: Attackers may remotely exploit this vulnerability to gain "root" or superuser control of any vulnerable Sendmail server. Sendmail and all other email servers are typically exposed to the Internet in order to send and receive Internet email. Vulnerable Sendmail servers will not be protected by legacy security devices such as firewalls and/or packet filters. This vulnerability is especially dangerous because the exploit can be delivered within an email message and the attacker doesn't need any specific knowledge of the target to launch a successful attack. Affected Versions: Sendmail versions from 5.79 to 8.12.7 are vulnerable Note: The affected versions of Sendmail commercial, Sendmail open source running on all platforms are known to be vulnerable. For the complete ISS X-Force Security Advisory, please visit: http://www.iss.net/issEn/delivery/xforce/alertdetail.jsp?oid=21950 ______ About Internet Security Systems (ISS) Founded in 1994, Internet Security Systems (ISS) (Nasdaq: ISSX) is a pioneer and world leader in software and services that protect critical online resources from an ever-changing spectrum of threats and misuse. Internet Security Systems is headquartered in Atlanta, GA, with additional operations throughout the Americas, Asia, Australia, Europe and the Middle East. Copyright (c) 2003 Internet Security Systems, Inc. All rights reserved worldwide. Permission is hereby granted for the electronic redistribution of this document. It is not to be edited or altered in any way without the express written consent of the Internet Security Systems X-Force. If you wish to reprint the whole or any part of this document in any other medium excluding electronic media, please email xforce(a)iss.net for permission. Disclaimer: The information within this paper may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties, implied or otherwise, with regard to this information or its use. Any use of this information is at the user's risk. In no event shall the author/distributor (Internet Security Systems X-Force) be held liable for any damages whatsoever arising out of or in connection with the use or spread of this information. X-Force PGP Key available on MIT's PGP key server and PGP.com's key server, as well as at http://www.iss.net/security_center/sensitive.php Please send suggestions, updates, and comments to: X-Force xforce(a)iss.net of Internet Security Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBPmOIRDRfJiV99eG9AQGOoAQAsW+F+O6i+tsKs6MCyUcBhZ1J83VgGcRU /qSQD68RlVBBD7+MDmjdr+eewu3a2wOAeBxFKRne3F/xijoqx6BV70iR5hwcZ1ZE RqyoluWYvkBOPnPvkoufTjuQvEWwTgZsf98JnjGbn/kIHPD2CUnz86CTEVSvJvlT wacUckcEhiA= =HFwX -----END PGP SIGNATURE-----

1 0

Re: RIPE Down or DOSed ?
by Douglas A. Dever 03 Mar '03

03 Mar '03

On 2/28/03 at 16:51 EST, Kai Schlichting wrote: >On 2/27/2003 at 9:58 PM, jlewis(a)lewis.org wrote: >> ... >> NetRange: 69.6.0.0 - 69.6.63.255 >> CIDR: 69.6.0.0/18 >> NetName: WHOLE-2 >> NetHandle: NET-69-6-0-0-1 >> Parent: NET-69-0-0-0-0 >> NetType: Direct Allocation >> NameServer: NS1.WHOLESALEBANDWIDTH.COM >> NameServer: NS2.WHOLESALEBANDWIDTH.COM >> ... >> Where are the swips? The rest of that record makes no mention of an >> rwhois server. Doing a bunch of whois requests for IPs in that block, I >> found only one swip (for a /21). I realize the ARIN regs don't seem to >> require that reassignment info be made available to the public (just to >> ARIN), but using your innocent customers (if there are any) as a shield to >> hide your spammer customers is just wrong. Should I block 69.6.4.0/24 >> from sending email into my systems? 69.6.0.0/18? > >Correct answer: the /18, and then some. > >Oh, how you wished you hadn't posted this to the list (and Cc:'d >wholesalebandwidth.com on it), but chosen reply-to-poster :) > >Random example from this block appearing in my rejects: >http://www.openrbl.org/lookup?i=69.6.4.153 or: "I see red!" > >Extended answer directly from my auto-complaint override map: > > 'as:26956' => 'as:17054,isp:cogent', # netfreeinc.com/wholesalebandwidth.com - rogue AS > 'as:11938' => 'abuse@yipes.com,isp:verio', # wholesalebandwidth.com - rogue AS > 'as:17054' => 'abuse@e-xpedient.com,isp:genuity,abuse@yipes.com,isp:gblx', # e-xpedient.com - rogue AS? > >Anything announced out of 26956 and 11938 goes straight to the sendmail >access file here, and given the various pointers from OTHER rogues back >to 17054, e-xpedient.com routes will be there RSN, too. We're not announcing 69.6.0.0/18 out of AS17054 nor is Wholesale Bandwidth a customer. We're announcing AS26956 for NetFree, and at this point I've seen less than a dozen spam complaints out of it over the last two months, and before that not a single one. If you want to route our mail to the bit bucket because of an /18 we're not announcing, that's your preogative. My abuse team is concentrating on removing customers we're actually seeing complaints on. (If you have any complaints, send them to abuse(a)e-xpedient.com. They get read, more often than not by me. :-) ) -- Douglas A. Dever doug(a)e-xpedient.com Director, Customer Operations E-xpedient

1 0

Re: BGP to doom us all
by Michael.Dillon＠radianz.com 03 Mar '03

03 Mar '03

> Too many features layered on a single tool. Haq the tool > and the dependencies will cripple your service offering. LDAP is not a tool, it is a protocol that can be used by many tools to communicate in the same way that many servers (BIND, NSD, DJBDNS, MS-DNS, QuickDNS) can use the DNS protocol to communicate with countless clients (Netscape, sendmail, ...). That's why I originally said the following > > I believe that LDAP can be the core of this toolset. If you build a tool that queries the ARIN LDAP server then you can mirror ARIN on your own LDAP server and the tool doesn't have to change. Or you can have a caching LDAP client/server that works and the tool doesn't have to change. If you offer your mirror of ARIN's data (or your caching LDAP server) to your customers for configuring their firewalls, then the firewall manufacturers will almost certainly add support for LDAP-based filter config to their product. That's because LDAP is a widely implemented and deployed industry standard protocol. Once firewalls are configuring dynamically based on either a trusted ISP's mirror of ARIN or a trusted firewall vendor's mirror of ARIN, then these bogon issues will go away. That's because we will have the knobs to turn on and off address space dynamically. Spammers won't be able to use unregistered addresses because everybody will be indirectly trusting ARIN's database. And they won't be able to use the unused parts of registered blocks because ISP's will publish their usage in their own LDAP servers that will be part of the ARIN trust hierarchy. Once this begins to provide benefit in North America, the rest of the world will soon follow. --Michael Dillon

4 7

Re: anti-spam vs network abuse
by Michael Lamoureux 03 Mar '03

03 Mar '03

"andy" == Andy Dills <andy(a)xecu.net> writes: andy> On Fri, 28 Feb 2003, Charlie Clemmer wrote: >> At 03:52 PM 2/28/2003 -0500, Andy Dills wrote: >> >Why is probing networks wrong? >> >> Depends on why you're doing the probing. andy> If so, why outlaw the act of probing? Why not outlaw "probing andy> for the purposes of..."? What's the offset into the probe packets to the "intent of the this probe" field? And would you trust it if there were one anyway? >> If you're randomly walk up to my house and check to see if the door >> is unlocked, you better be ready for a reaction. Same thing with >> unsolicited probes, in my opinion. Can I randomly walk up to your >> car to see if it's unlocked without getting a reaction out of you? andy> This is different. Metaphors applying networking concepts to andy> real world scenarios are tenuous at best. andy> In this case, your door being unlocked cannot cause me andy> harm. However, an "unlocked proxy" can. Heh, so I guess you could make it his gun and the safety. Does that change your answer? ;-) andy> Legit probes are an attempt to mitigate network abuse, not andy> increase it. If there was a sanctioned body who was trusted to andy> scan for such things, maybe this wouldn't be an issue. But andy> there's not, so it's a vigilante effort. What's a legit probe? One where the owner gave you permission in advance to run the scan? I can't think of another definition of that phrase. andy> You don't have to. This is why I never understood why people andy> care so much about probing. If you do a good job with your andy> network, probing will have zero affect on you. All the person andy> probing can do (regardless of their intent) is say "Gee, I guess andy> there aren't any vulnerabilities with this network." This is a completely naive statement. There are 0 networks that I'm willing to believe have 0 vulnerabilities on them. There may be 0 that you know about, but that doesn't mean there aren't more vulnerabilities which aren't public knowledge lurking in sendmail or bind or ssh or ssl or apache or any number of other services you have running. IMHO, Michael

5 4

OT: Need the name of a good Qwest account rep.
by joe mcguckin 03 Mar '03

03 Mar '03

I need to order some Qwest circuits. Is there an ISP account group? Can someone recommend a good account manager to work with? Thanks, Joe

1 0

Re: BGP to doom us all
by Michael.Dillon＠radianz.com 03 Mar '03

03 Mar '03

> For example, take a naive approach: your router crashes. It comes back > up. It receives 130,000 prefixes that it needs to validate. For each > prefix, your router must do an LDAP query. Then take a smarter approach: your router crashes. It comes back up and your network management system (NMS) pushes a special after-the-crash BGP filter set to it. It receives 130,000 prefixes, most of which pass through the filter just fine. The NMS collects the rejects, queries them against an LDAP server asynchronously and builds a better BGP filter set which gets pushed out to the router once the CPU settles down. Yes, this means that some routes take longer to converge at this particular router but that's not a problem because your resilient network architecture has continued to deliver 100% of packets offered in spite of this router crash. And if the router is crashing often then you have bigger problems to solve. I am not suggesting that router vendors should implement any sort of LDAP capability because it will be stuck in the same morass of ancient slow CPUs, not enough absurdly expensive RAM, years-long test and certification process because it runs on the router, and botched feature set because it has to fit in the vendors wide range of router architectures and they will only implement the features that many customers are clamoring for. The alternative is to use modern fast CPUs running on standard systems with lots of cheap RAM to handle these tasks that are peripheral to the job of packet-forwarding. Then use the standard interfaces already on the router (i.e. telnet from a protected server or SNMP) to communicate with this NMS device Your details may vary but this basic architecture works and it allows the NMS to track more closely with commercial off-the-shelf (COTS) hardware and software. Too many people are biased against this approach because of the days when the IBM RS-6000 based routers were replaced with purpose-built boxes from Cisco and Wellfleet (now Nortel). --Michael Dillon

1 0