December 2008 - Test - lists.nanog.org

Re: Christmas spam from RESERVED IANA adressblock ?
by Zaid Ali 24 Dec '08

24 Dec '08

If you want to file a spam complaint I suggest you do a whois for 76.74.250.247. This is the external facing mail server that sent you the email. Most applications these days are built in layers so a web layer forwards the email to an email server, if the application is not designed to suppress the HELO from the web layer then you will see internal email routing information. As for the network side most networks filter out BOGONS so you would not get RFC1918 into your network. Zaid -----Original Message----- From: macbroadcast [mailto:marc@let.de] Sent: Wednesday, December 24, 2008 6:48 AM To: NANOG list Subject: Christmas spam from RESERVED IANA adressblock ? hello ladys and getlepersons just out of curiosity i looked a bit closer into this spammail header, because this company is really annoying and abusing a lot of internet citizens. Anfang der weitergeleiteten E-Mail: > Von: mailling(a)ualadys.com > Datum: 24. Dezember 2008 12:30:18 MEZ > An: marc(a)let.de > Betreff: E-Mail For You @ ualadys.com > Return-Path: <www-data(a)web1.iispp.com> > Received: from mx2.mail.vrmd.de ([10.0.1.21]) by vm42.mail.vrmd.de > (Cyrus v2.2.12-Invoca-RPM-2.2.12-9.RHEL4) with LMTPA; Wed, 24 Dec > 2008 12:30:25 +0100 > Received: from mx2.iispp.com ([76.74.250.247]) by mx2.mail.vrmd.de > with esmtp (Exim 4.69) (envelope-from <www-data(a)web1.iispp.com>) id > 1LFRwW-00011o-DY for marc(a)let.de; Wed, 24 Dec 2008 12:30:25 +0100 > Received: from web1.iispp.com (w1 [172.16.21.244]) by mx2.iispp.com > (Postfix) with ESMTP id B71CF3504DB for <marc(a)let.de>; Wed, 24 Dec > 2008 11:30:18 +0000 (UTC) > Received: by web1.iispp.com (Postfix, from userid 33) id A5C7917A405C; > Wed, 24 Dec 2008 06:30:18 -0500 (EST) "Whois" wurde gestartet . OrgName: Internet Assigned Numbers Authority OrgID: IANA Address: 4676 Admiralty Way, Suite 330 City: Marina del Rey StateProv: CA PostalCode: 90292-6695 Country: US NetRange: 172.16.0.0 - 172.31.255.255 CIDR: 172.16.0.0/12 NetName: IANA-BBLK-RESERVED NetHandle: NET-172-16-0-0-1 Parent: NET-172-0-0-0-0 NetType: IANA Special Use NameServer: BLACKHOLE-1.IANA.ORG NameServer: BLACKHOLE-2.IANA.ORG Comment: This block is reserved for special purposes. Comment: Please see RFC 1918 for additional information. Comment: http://www.arin.net/reference/rfc/rfc1918.txt RegDate: 1994-03-15 Updated: 2007-11-27 OrgAbuseHandle: IANA-IP-ARIN OrgAbuseName: Internet Corporation for Assigned Names and Number OrgAbusePhone: +1-310-301-5820 OrgAbuseEmail: abuse(a)iana.org OrgTechHandle: IANA-IP-ARIN OrgTechName: Internet Corporation for Assigned Names and Number OrgTechPhone: +1-310-301-5820 OrgTechEmail: abuse(a)iana.org # ARIN WHOIS database, last updated 2008-12-23 19:10 # Enter ? for additional hints on searching ARIN's WHOIS database. so how is this possible ? merry christmas anyway Marc > X-Sieve: CMU Sieve 2.2 > Envelope-To: marc(a)let.de > Delivery-Date: Wed, 24 Dec 2008 12:30:25 +0100 > X-Id-From: 1000 > X-Id-To: 238141 > X-Mail-Id: 203714382 > Mime-Version: 1.0 > Content-Type: text/html > Message-Id: <20081224113018.A5C7917A405C(a)web1.iispp.com> > X-Spam-Suspicion: No > X-Purgate: Clean X-purgate-ID: > 150741::081224123024-0FFB86C0-283E8BDE/0-0/0-1 X-purgate-Ad: For more > information about eXpurgate please visit http://www.expurgate.net/ > > > > > marc, You have new mail > This is to notify you that you have received an E-Mail from > > View Photos > DetailsIrina O #1000 > Subject: Destiny has linked us... > > Date: 24 December 2008 > > To read the message go here: > > PLEASE, DO NOT REPLY TO THIS E-MAIL - FOLLOW THE LINK > > http://www.ualadys.com/view_mail.rpx?hash=a71d2600f032ece232a391296f5f > 071e&mid=203714382&uid=238141 > > Thank you, > ualadys.com Support Team > > Favorites ualadys.com > > 24x7 Call center > > United States > +1 (315) 849-5814 > > United Kigdom > +44 (315) 849-5814 > > Skype support : ualadys > > > > For any question in english > about this site please call: > +1 (212) 226-8900 > Mon-Fri 9:00-16:00 (EST)

1 0

Re: [outages] Yahoo! mail having problems?
by Jeff Shultz 23 Dec '08

23 Dec '08

Apparently they are - 219 of the 304 in the queue are for Yahoo - some over 1280 minutes. Or, as my boss put it when I mentioned that Yahoo was having e-mail issues: "What's new?" Chris Lauretano wrote: > Yep, experiencing the same here. The only e-mails stuck in the queue are outbound to Yahoo and the number is staggering. > > --C. Lauretano > > > On 12/23/08 3:34 PM, "iName.com" <frnkblk(a)iname.com> wrote: > > Our e-mail gateways are backing up with yahoo.com bound e-mail. I'm only > getting timeouts connecting to Yahoo's e-mail servers. I've tried these: > a.mx.mail.yahoo.com[67.195.168.31] > c.mx.mail.yahoo.com[216.39.53.3] > d.mx.mail.yahoo.com[66.196.82.7] > f.mx.mail.yahoo.com[68.142.202.247] > from the same subnet as the e-mail gateways. > > Anyone else having the same? > > Frank > > _______________________________________________ > outages mailing list > outages(a)outages.org > https://puck.nether.net/mailman/listinfo/outages > > _______________________________________________ > outages mailing list > outages(a)outages.org > https://puck.nether.net/mailman/listinfo/outages > -- Jeff Shultz

1 0

Unallocated prefix 100.10.10.0/24 in the DFZ via Cogent
by sthaug＠nethelp.no 23 Dec '08

23 Dec '08

Calling Cogent, Avantel (AS 6503) and Axtel (AS 14000): Axtel is announcing 100.10.10.0/24, which is within the 100.0.0.0/8 block, which is unallocated according to http://www.iana.org/assignments/ipv4-address-space/ I am seeing this from two of my transit providers, the common AS path is: 174 6503 6503 6503 6503 6503 14000 Prefix filtering is a good thing, please do it! Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

4 3

[outage] archive.routeviews.org under maintenance
by John Kemp 23 Dec '08

23 Dec '08

We are experiencing some unanticipated hardware issues with the machine archive.routeviews.org. This machine serves as the front-end to our primary data archive. It also hosts http://www.routeviews.org/ and is answering for route-views6.routeviews.org. We are currently working to deploy a replacement for this piece of hardware. NOTE: this outage will not affect the other routeviews collectors, or the data archive. Your patience during this time is appreciated. -- John Kemp RouteViews Engineer kemp(a)network-services.uoregon.edu 541-346-1714

1 0

RE: What is the most standard subnet length on internet
by Skywing 22 Dec '08

22 Dec '08

I am sure that there are foolish people doing foolish things somewhere on the Internet. But perhaps Joe had knowledge of a specific example && possibly "reasoning" from said example as to why they were using a broken configuration as that? – S -----Original Message----- From: Nathan Ward <nanog(a)daork.net> Sent: Monday, December 22, 2008 19:45 To: nanog list <nanog(a)nanog.org> Subject: Re: What is the most standard subnet length on internet On 23/12/2008, at 2:39 PM, Joe Provo wrote: > On Tue, Dec 23, 2008 at 02:34:39PM +1300, Nathan Ward wrote: > [snip] >> Let me rephrase; Are there people who are filtering /24s received >> from >> eBGP peers who do not have a default route? > > of course. Curiously, it was really meant as a rhetorical question where the answer was "no". Why are people doing this? Are they lacking clue, or, is there some reasonable purpose? -- Nathan Ward

1 0

Re: Re: What is the most standard subnet length on internet
by ChiYoung Joung 22 Dec '08

22 Dec '08

I would like to ask question more specifically. I know most of tier1 providers accept their customer prefixes smaller than /24. it means smaller than /24 routes always routable in that Tier1 provider. What about between Tier1 and another Tier1 ? Do they exchange their full customer's routes without any limitation of prefixes length ? or do they refer to some DB information like Regional Internet Registry and apply another filter on neighbor configuration with another Tier1 ? Chiyoung ============================================= Chi-Young Joung SAMSUNG NETWORKS Inc. Email: lionair(a)samsung.com Tel +82 70 7015 0623, Mobile +82 17 520 9193 Fax +82 70 7016 0031 ============================================= ------- Original Message ------- Sender : Nathan Ward<nanog(a)daork.net> Date : 2008-12-23 10:44 (GMT+09:00) Title : Re: What is the most standard subnet length on internet On 23/12/2008, at 2:39 PM, Joe Provo wrote: > On Tue, Dec 23, 2008 at 02:34:39PM +1300, Nathan Ward wrote: > [snip] >> Let me rephrase; Are there people who are filtering /24s received >> from >> eBGP peers who do not have a default route? > > of course. Curiously, it was really meant as a rhetorical question where the answer was "no". Why are people doing this? Are they lacking clue, or, is there some reasonable purpose? -- Nathan Ward

1 0

[USN-698-1] Nagios vulnerability (fwd)
by Gadi Evron 22 Dec '08

22 Dec '08

---------- Forwarded message ---------- Date: Mon, 22 Dec 2008 09:35:54 -0500 From: Marc Deslauriers <marc.deslauriers(a)canonical.com> To: ubuntu-security-announce(a)lists.ubuntu.com Cc: bugtraq(a)securityfocus.com, full-disclosure(a)lists.grok.org.uk Subject: [USN-698-1] Nagios vulnerability =========================================================== Ubuntu Security Notice USN-698-1 December 22, 2008 nagios vulnerability CVE-2008-5027 =========================================================== A security issue affects the following Ubuntu releases: Ubuntu 6.06 LTS This advisory also applies to the corresponding versions of Kubuntu, Edubuntu, and Xubuntu. The problem can be corrected by upgrading your system to the following package versions: Ubuntu 6.06 LTS: nagios-common 2:1.3-cvs.20050402-8ubuntu8 After a standard system upgrade you need to restart Nagios to effect the necessary changes. Details follow: It was discovered that Nagios did not properly parse commands submitted using the web interface. An authenticated user could use a custom form or a browser addon to bypass security restrictions and submit unauthorized commands. Updated packages for Ubuntu 6.06 LTS: Source archives: http://security.ubuntu.com/ubuntu/pool/main/n/nagios/nagios_1.3-cvs.2005040… Size/MD5: 70914 96d8036bdb33aadd3141715039c91b24 http://security.ubuntu.com/ubuntu/pool/main/n/nagios/nagios_1.3-cvs.2005040… Size/MD5: 959 0393336015bf452f5dfeb74d75245311 http://security.ubuntu.com/ubuntu/pool/main/n/nagios/nagios_1.3-cvs.2005040… Size/MD5: 1621251 0f92b7b8e705411b7881d3650cbb5d56 Architecture independent packages: http://security.ubuntu.com/ubuntu/pool/main/n/nagios/nagios-common_1.3-cvs.… Size/MD5: 1218132 d18e298ee16f4c6c6b7c5969c46044e6 amd64 architecture (Athlon64, Opteron, EM64T Xeon): http://security.ubuntu.com/ubuntu/pool/main/n/nagios/nagios-mysql_1.3-cvs.2… Size/MD5: 1030206 085483fdefd0d7bc43e55dbc5be2bcd6 http://security.ubuntu.com/ubuntu/pool/main/n/nagios/nagios-pgsql_1.3-cvs.2… Size/MD5: 1041656 09fc7bb2ff11062603680d09e290909b http://security.ubuntu.com/ubuntu/pool/main/n/nagios/nagios-text_1.3-cvs.20… Size/MD5: 1025618 61619d13effd9a4970486abf5933c756 i386 architecture (x86 compatible Intel/AMD): http://security.ubuntu.com/ubuntu/pool/main/n/nagios/nagios-mysql_1.3-cvs.2… Size/MD5: 877846 544afaebec24e7e94d2ce1da3a89346c http://security.ubuntu.com/ubuntu/pool/main/n/nagios/nagios-pgsql_1.3-cvs.2… Size/MD5: 886544 411d3ca5a204aa41a4a42ef6e5f56453 http://security.ubuntu.com/ubuntu/pool/main/n/nagios/nagios-text_1.3-cvs.20… Size/MD5: 872936 aa31f6d1fb8a081a206eae3d6bfb3dd6 powerpc architecture (Apple Macintosh G3/G4/G5): http://security.ubuntu.com/ubuntu/pool/main/n/nagios/nagios-mysql_1.3-cvs.2… Size/MD5: 1015630 540a27062c7f8612b7f460b2bcfd93b9 http://security.ubuntu.com/ubuntu/pool/main/n/nagios/nagios-pgsql_1.3-cvs.2… Size/MD5: 1024374 47e0480006df0b20a83f67b56da7a9f8 http://security.ubuntu.com/ubuntu/pool/main/n/nagios/nagios-text_1.3-cvs.20… Size/MD5: 993324 03a67a7675075050a672a4c515e8e0c3 sparc architecture (Sun SPARC/UltraSPARC): http://security.ubuntu.com/ubuntu/pool/main/n/nagios/nagios-mysql_1.3-cvs.2… Size/MD5: 918810 7340348f043dd884c88bd016ee30e41d http://security.ubuntu.com/ubuntu/pool/main/n/nagios/nagios-pgsql_1.3-cvs.2… Size/MD5: 926172 e9ccf388b828a17e868807aa39cb5b51 http://security.ubuntu.com/ubuntu/pool/main/n/nagios/nagios-text_1.3-cvs.20… Size/MD5: 917374 c88dec0d93f590f8a93ebbc701696f68

1 0

Re: ICANN/Dotster emergency contacts? (hopefully not too OT)
by Edward B. DREGER 22 Dec '08

22 Dec '08

Thanks, all. I have several responses, and finally got through. Again, sorry for the OT noise. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc(a)brics.com -*- jfconmaapaq(a)intc.net -*- sam(a)everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.

1 0

ICANN/Dotster emergency contacts? (hopefully not too OT)
by Edward B. DREGER 22 Dec '08

22 Dec '08

Greetings, Does anyone have any "emergency" contacts at ICANN? Dotster? I have a couple domains that were erroneously expired this year instead of next. (I have the CC statement and ref # in front of me, to be certain that I'm not hallucinating.) Automated web form failed to send (to different domain) account info, and hold time is getting annoying. I've already filed the ICANN complaint, but that doesn't restore service. I'd buy an extra year and worry about the dispute later, but see note about automated web form. Please CC me @brotsman.com, and I can't currently receive email via the address by which I'm subscribed. And off-list, please. I don't want to drag things even farther OT than I already have. Thanks, and sorry for the panicked OT noise, Eddy (please remember to s/noc.everquick.net/brotsman.com/) -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc(a)brics.com -*- jfconmaapaq(a)intc.net -*- sam(a)everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.

1 0

Managing CE eBGP details & common/accepted CE-facing BGP practices
by Justin Shore 22 Dec '08

22 Dec '08

Does anyone have any preferred ways to manage their customer-facing BGP details? I'm thinking about the customer's ASN (SP assigned private ASN or RIR assigned ASN), permitted prefixes, etc? While I'm sure this could be easily stored in a spreadsheet I'm not sure if there is any merit to storing some of these details outside of the configuration on the PE (assuming of course that the PE's config is regularly archived). Now if the PE's BGP config was auto-generated via a script then it would make sense for all the details to be stored off in a DB in the NOC. Beyond that is there a good reason to do archive it in a textual format off of the PE and if there is a sound reason to do it, is therea good or preferred way to do accomplish this? We're moving beyond our typical residential and very small SMB service to larger customers over the next few months. These areas have larger, more advanced customers and I'm sure we'll run into multi-homed environments and customer who will expect BGP peering options. I would like to be prepared with sound practices before we get our first customer that wants to get a default route via BGP, wants full tables, or has their own ASN and is bringing their own PI space with them. Some of this of course implies multiple processes to confirm that the ASN belongs to the customer in question, that the PI space belongs to the customer in question, notifying our upstreams to accept the customer's PI space, etc. It's hammering out the scalable and best practice config details that I'm concerned with at the moment. When assigning private ASNs to customers, are there any gotchas to be aware of? Is it possible to use the same private ASN for more than one customer on the same PE? What are common and accepted CE-facing BGP practices? MD5 AUTH, GTSM, max prefix limits? Which is preferred, route-maps or prefix-lists for controlling advertised and/or received routes? Do any SPs utilize AS-Path ACLs to check that prefixes from an customer's ASN are claimed to originate from there? Are there any SPs out there offering BFD support for BGP or CE-facing peering sessions? Should we have the customer announce their PA space to us or do we advertise it for them (redist a static)? Do SPs restrict access to tcp/179 on the CE from the Internet in the CE-facing ACL? Do SPs block access to the PE-CE subnet from the outside world like what was described in the Router Security Strategies book (pages 189-193)? What about dropping incoming traffic to everything but the CE IP? While I don't predict our CE-facing BGP load to be terribly significant at this point, I would like to establish sound practices now rather than down the road once we're neck deep in temporarily production workarounds. Is there any consensus on what's best practice for CE-facing BGP? I imagine most SP engineer's BGP practices could be better equated to a religious holy war on par with Chevy vs Ford or Mac vs PC. I would be interested in hearing what they are though and learning from the group's expertise. Thanks Justin

7 10