Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer
Hello John Doe, I welcome any further comments you have. We have to get past people such as yourself, and your blasphemous and false statements. This is the same issue with the recent media and self-proclaimed "Security Researchers". Fly-by-night mind you. To help you out in your claims: Yes, we did house a client whom had quite a run with their client's from various locations, such as Russia. That Client is no longer hosted on our network. I myself spent all of monday afternoon, night, and tuesday morning shutting off EVERY machine they had leased in our Billing System. I'm currently working to scan further and see if there's anything I may have missed. Yes, Russia is very well known for Virus and Malware writer's. Yes, we have had issues with malware distribution from our network. This was directly and near singularly related to the former client of ours. We did have another client, Hostfresh, whom had their share of malware issues. Both have been completely and effectively removed. The server's leased to both of them have been canceled, and their machines have been shutoff. Let me know if there's anything else you'd like me to state to the public. We're on a rocky road right now. But it IS starting to smooth out. Thank you for your time. Have a great day. --- Russell Mitchell InterCage, Inc. - Original Message From: Mark Foo <[EMAIL PROTECTED]> To: Bruce Williams <[EMAIL PROTECTED]> Cc: Christopher Morrow <[EMAIL PROTECTED]>; nanog@nanog.org; Joe Greco <[EMAIL PROTECTED]> Sent: Tuesday, September 23, 2008 11:08:21 PM Subject: Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer NANOG: Look, the people posting here who are trashing Intercage are pure security analysts -- they know and understand the evil that is Intercage. STOP TRYING TO ASSIST INTERCAGE -- you are effectively aiding and abetting the enemy. Intercage/Atrivo hosts the malware c&c botnets that DDoS your systems and networks. Intercage/Atrivo hosts the spyware that compromises your users' passwords. Intercage/Atrivo hosts the adware that slows your customers' machines. Don't take my word for it, DO YOUR OWN RESEARCH: http://www.google.com/search?hl=en&q=intercage+malware You don't get called the ***American RBN*** for hosting a couple bad machines. They have and will continue to host much of the malware pumped out of America. THEY ARE NOT YOUR COMRADES.. These people represent the most HIGHLY ORGANZIED CRIME you will ever come across. Most people were afraid to speak out against them until this recent ground swell. This is the MALWARE CARTEL. GET THE PICTURE? Many links have been posted here that prove this already -- instead of asking what customers they cut off, let them show WHAT CUSTOMERS ARE LEGIT-- because there are NONE. > >> I would suggest a different Step 1. Instead of killing power, simply > >> isolate the affected machine. This might be as simple as putting up a > >> firewall rule or two, if it is simply sending outgoing SMTP spam, or > > it's probably easiest (depending on the network gear of course) to > > just put the lan port into an isolated VLAN. It's not the 100% > > solution (some badness rm's itself once it loses connectivity to the > > internets) but it'd make things simpler for the client/LEA when they > > need to figure out what happened. > > > > -chris > > > > > >
Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer
Wow, this topic has really gotten old. On Tue, Sep 23, 2008 at 11:31 PM, Paul Ferguson <[EMAIL PROTECTED]>wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Tue, Sep 23, 2008 at 11:28 PM, Russell Mitchell <[EMAIL PROTECTED]> > wrote: > > > > Sorry I didn't make this clear enough in the previous responses. > > > > The prefixes that are registered to Inhoster belong to Esthost. > > I'm not sure how or why you think those prefixes belong to us. > > > > These prefixes belong DIRECTLY to us: > > - 69.50.160.0/19 Withdrawn > > - 216.255.176.0/20Withdrawn > > > > These prefixes belong DIRECTLY to nLayer, and were LEASED to us: > > - 69.22.162.0/23 Withdrawn > > - 69.22.168.0/21 Withdrawn > > - 69.22.184.0/22 Withdrawn > > - 69.31.64.0/20 Withdrawn > > > > The prefixes LEASED to us BY nLayer are being reclaimed at the end of > > this month 09/30/08, as the lease contract is set to cease at that time. > > > > Hopefully, that is clear enough for you. > > > > Thank you for your time. Have a great day. > > --- > > Russell Mitchell > > > > InterCage, Inc. > > > > Clear as mud, thanks. > > - - ferg > > -BEGIN PGP SIGNATURE- > Version: PGP Desktop 9.6.3 (Build 3017) > > wj8DBQFI2d6uq1pz9mNUZTMRAmkcAJ4toRsggJ325VfjkqK8QJKWQG4UegCg84x+ > KwcuyxtFp7/x3/vScFTkP3I= > =/vFy > -END PGP SIGNATURE- > > > -- > "Fergie", a.k.a. Paul Ferguson > Engineering Architecture for the Internet > fergdawgster(at)gmail.com > ferg's tech blog: http://fergdawg.blogspot.com/ > >
Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Sep 23, 2008 at 11:28 PM, Russell Mitchell <[EMAIL PROTECTED]> wrote: > Sorry I didn't make this clear enough in the previous responses. > > The prefixes that are registered to Inhoster belong to Esthost. > I'm not sure how or why you think those prefixes belong to us. > > These prefixes belong DIRECTLY to us: > - 69.50.160.0/19 Withdrawn > - 216.255.176.0/20Withdrawn > > These prefixes belong DIRECTLY to nLayer, and were LEASED to us: > - 69.22.162.0/23 Withdrawn > - 69.22.168.0/21 Withdrawn > - 69.22.184.0/22 Withdrawn > - 69.31.64.0/20 Withdrawn > > The prefixes LEASED to us BY nLayer are being reclaimed at the end of > this month 09/30/08, as the lease contract is set to cease at that time. > > Hopefully, that is clear enough for you. > > Thank you for your time. Have a great day. > --- > Russell Mitchell > > InterCage, Inc. > Clear as mud, thanks. - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI2d6uq1pz9mNUZTMRAmkcAJ4toRsggJ325VfjkqK8QJKWQG4UegCg84x+ KwcuyxtFp7/x3/vScFTkP3I= =/vFy -END PGP SIGNATURE- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/
Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer
Hello Paul, Sorry I didn't make this clear enough in the previous responses. The prefixes that are registered to Inhoster belong to Esthost. I'm not sure how or why you think those prefixes belong to us. These prefixes belong DIRECTLY to us: - 69.50.160.0/19 Withdrawn - 216.255.176.0/20 Withdrawn These prefixes belong DIRECTLY to nLayer, and were LEASED to us: - 69.22.162.0/23 Withdrawn - 69.22.168.0/21 Withdrawn - 69.22.184.0/22 Withdrawn - 69.31.64.0/20 Withdrawn The prefixes LEASED to us BY nLayer are being reclaimed at the end of this month 09/30/08, as the lease contract is set to cease at that time. Hopefully, that is clear enough for you. Thank you for your time. Have a great day. --- Russell Mitchell InterCage, Inc. - Original Message From: Paul Ferguson <[EMAIL PROTECTED]> To: Russell Mitchell <[EMAIL PROTECTED]> Cc: nanog@nanog.org Sent: Tuesday, September 23, 2008 11:11:39 PM Subject: Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Sep 23, 2008 at 10:52 PM, Paul Ferguson <[EMAIL PROTECTED]> wrote: > On Tue, Sep 23, 2008 at 10:13 PM, Russell Mitchell <[EMAIL PROTECTED]> > wrote: > >> I believe the blocks your referring to are their 85.255 Blocks? >> Registered to "InHoster". I believe those prefixes are an entity of >> their's, though I don't know for sure. Perhaps ask them? >> > > Thanks, thats right -- Inhoster. Operating out of Odessa and blacklisted > virtually everywhere. > Sorry, my last post on this issue. As you may (or may not) know, Inhoster's domain(s) were suspended due to criminal activity: http://whois.domaintools.com/inhoster.com The prefixes you mention, were deliberately being originated by AS27595 up until the recent kerfluffle and disconnect on Saturday night: Prefixes added and withdrawn by this origin AS in the past 7 days. - 64.28.176.0/20 Withdrawn - 67.210.0.0/21 Withdrawn - 67.210.8.0/22 Withdrawn - 67.210.14.0/23 Withdrawn - 69.22.162.0/23 Withdrawn - 69.22.168.0/21 Withdrawn - 69.22.184.0/22 Withdrawn - 69.31.64.0/20 Withdrawn - 69.50.160.0/19 Withdrawn - 85.255.113.0/24 Withdrawn - 85.255.114.0/23 Withdrawn - 85.255.116.0/22 Withdrawn - 85.255.120.0/23 Withdrawn - 85.255.122.0/24 Withdrawn - 216.255.176.0/20 Withdrawn - 216.255.176.0/22 Withdrawn - 216.255.180.0/22 Withdrawn - 216.255.184.0/22 Withdrawn - 216.255.188.0/22 Withdrawn And they magically reappeared in Cernel (AS36445) almost immediately: Prefix AS Path 64.28.187.0/24 12654 3257 36445 67.210.12.0/23 12654 3257 36445 85.255.112.0/20 12654 3257 36445 93.188.161.0/24 12654 3257 36445 93.188.166.0/24 12654 3257 36445 This was not an accident. So what you are saying is that these prefixes have always belonged to Inhoster? Thanks, - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI2doTq1pz9mNUZTMRAupwAKDxEF9kyS/UoTb/Hl2FwEGM1tsj2gCfYF16 qyG0vUAmfxfdQg/vqHFCxbw= =T+0o -END PGP SIGNATURE- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/
Re: Atrivo/Intercage
On Sep 23, 2008, at 8:12 PM, Joe Greco wrote: Which is not acceptable. You answer your abuse complaints, you shut down your spammers. Period, end of subject. That's a bit '90's. I'll settle for s/answer/handle/, because I don't think that most sites are willing to actually discuss abuse issues with random folks submitting complaints, and so that leaves you with either sending a form letter of some sort, or not saying anything. I went out of my way to get it written into our customer contract that we can discuss abuse issues with the affected parties. And I am simply an employee, neither an executive nor an owner, so this took a bit of doing. But it has given me great pleasure the few times that we made a mistake with a customer, and I got to tell the affected parties that the abuser is now homeless ;-) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Sep 23, 2008 at 10:52 PM, Paul Ferguson <[EMAIL PROTECTED]> wrote: > On Tue, Sep 23, 2008 at 10:13 PM, Russell Mitchell <[EMAIL PROTECTED]> > wrote: > >> I believe the blocks your referring to are their 85.255 Blocks? >> Registered to "InHoster". I believe those prefixes are an entity of >> their's, though I don't know for sure. Perhaps ask them? >> > > Thanks, thats right -- Inhoster. Operating out of Odessa and blacklisted > virtually everywhere. > Sorry, my last post on this issue. As you may (or may not) know, Inhoster's domain(s) were suspended due to criminal activity: http://whois.domaintools.com/inhoster.com The prefixes you mention, were deliberately being originated by AS27595 up until the recent kerfluffle and disconnect on Saturday night: Prefixes added and withdrawn by this origin AS in the past 7 days. - 64.28.176.0/20 Withdrawn - 67.210.0.0/21 Withdrawn - 67.210.8.0/22 Withdrawn - 67.210.14.0/23 Withdrawn - 69.22.162.0/23 Withdrawn - 69.22.168.0/21 Withdrawn - 69.22.184.0/22 Withdrawn - 69.31.64.0/20 Withdrawn - 69.50.160.0/19 Withdrawn - 85.255.113.0/24 Withdrawn - 85.255.114.0/23 Withdrawn - 85.255.116.0/22 Withdrawn - 85.255.120.0/23 Withdrawn - 85.255.122.0/24 Withdrawn - 216.255.176.0/20Withdrawn - 216.255.176.0/22Withdrawn - 216.255.180.0/22Withdrawn - 216.255.184.0/22Withdrawn - 216.255.188.0/22Withdrawn And they magically reappeared in Cernel (AS36445) almost immediately: Prefix AS Path 64.28.187.0/24 12654 3257 36445 67.210.12.0/23 12654 3257 36445 85.255.112.0/20 12654 3257 36445 93.188.161.0/24 12654 3257 36445 93.188.166.0/24 12654 3257 36445 This was not an accident. So what you are saying is that these prefixes have always belonged to Inhoster? Thanks, - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI2doTq1pz9mNUZTMRAupwAKDxEF9kyS/UoTb/Hl2FwEGM1tsj2gCfYF16 qyG0vUAmfxfdQg/vqHFCxbw= =T+0o -END PGP SIGNATURE- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/
Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer
NANOG: Look, the people posting here who are trashing Intercage are pure security analysts -- they know and understand the evil that is Intercage. STOP TRYING TO ASSIST INTERCAGE -- you are effectively aiding and abetting the enemy. Intercage/Atrivo hosts the malware c&c botnets that DDoS your systems and networks. Intercage/Atrivo hosts the spyware that compromises your users' passwords. Intercage/Atrivo hosts the adware that slows your customers' machines. Don't take my word for it, DO YOUR OWN RESEARCH: http://www.google.com/search?hl=en&q=intercage+malware You don't get called the ***American RBN*** for hosting a couple bad machines. They have and will continue to host much of the malware pumped out of America. THEY ARE NOT YOUR COMRADES. These people represent the most HIGHLY ORGANZIED CRIME you will ever come across. Most people were afraid to speak out against them until this recent ground swell. This is the MALWARE CARTEL. GET THE PICTURE? Many links have been posted here that prove this already -- instead of asking what customers they cut off, let them show WHAT CUSTOMERS ARE LEGIT-- because there are NONE. > >> I would suggest a different Step 1. Instead of killing power, simply > >> isolate the affected machine. This might be as simple as putting up a > >> firewall rule or two, if it is simply sending outgoing SMTP spam, or > > it's probably easiest (depending on the network gear of course) to > > just put the lan port into an isolated VLAN. It's not the 100% > > solution (some badness rm's itself once it loses connectivity to the > > internets) but it'd make things simpler for the client/LEA when they > > need to figure out what happened. > > > > -chris > > > > > >
Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Sep 23, 2008 at 10:13 PM, Russell Mitchell <[EMAIL PROTECTED]> wrote: > I believe the blocks your referring to are their 85.255 Blocks? > Registered to "InHoster". I believe those prefixes are an entity of > their's, though I don't know for sure. Perhaps ask them? > Thanks, thats right -- Inhoster. Operating out of Odessa and blacklisted virtually everywhere. Cheers, - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI2dV3q1pz9mNUZTMRAvOwAKCQtLCPC+ZC3M1SVErh8kYGJ3Zp5ACaA/sE eHXtt63emWJNy/0NnVAuI6o= =xUzo -END PGP SIGNATURE- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/
Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer
Hello Joe, If we can't power down the machine, due to evidence loss. We can't nullroute the IP, as stated, some malware will delete itself or alter itself when Net Access is lost. Now we can filter a single port, in the case of spam, phishing, etc? I'll look further into the JunOS. I'm not too familiar with the rules on the Juniper, so I'll take a look further, and see how to achieve this on a single IP rather then the network. Thank you for your time. Have a great day. --- Russell Mitchell InterCage, Inc. - Original Message From: Joe Greco <[EMAIL PROTECTED]> To: Russell Mitchell <[EMAIL PROTECTED]> Cc: nanog@nanog.org Sent: Tuesday, September 23, 2008 8:20:18 PM Subject: Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer > Hello All,=0A=A0=0AIt seems you all missed the memo.=0AAs of about 11PM PST= > Last night 09/22/08, Esthost has been ENTIRELY Shutdown. They no longer ha= > ve ANY Machine on my network.=0A=A0=0AI'm currently starting to monitor som= > e of the public media, such as google, DroneBL, as well as several Anti-Mal= > ware community websites for abuse.=0A=A0=0ABeing that Esthost is now entire= > ly GONE, we should not have any further issues.=0AIn the case that somethin= > g=A0does arise, such as an exploited host, we're currently developing a gam= > e plan for=A0response to=A0the issues.=0ATo make the best effort towards co= > mbatting=A0abuse on our network, here's what I have planned so far for ANY = > Type of abuse:=0AStep 1,=A0Suspend Power to the affected machine.=0AStep 2,= > Call/Email the client whom the affected machine is leased to.=0AStep 3, Al= > low the client=A0the option to=A0investigate the machine further (Nullroute= > access via KVM)=0AStep=A04, Verify the=A0reported content, domain, user, o= > r exploit=A0is patched/eliminated from the machine.=0AStep 5,=A0Remove the = > Nullroute. Allow the machine to return to the network.=0A=A0=0AAny comments= > ? =0A=A0=0AThis is=A0the result of a zero tolerance policy regarding abuse.= > If it's clear that the server owner is the cause of the abusive material e= > tc, the client will then be immediately cancelled. No questions.=A0=0A=0A= > =0AIt seems that this approach will be the best supported by the anti-abuse= > communities, so please let me know your input.=0A=0AThank you for your tim= > e. Have a great day.=0A=A0---=0ARussell Mitchell=0A=0AInterCage, Inc.=0A=0A= > =0A=0A- Original Message =0AFrom: Paul Wall <[EMAIL PROTECTED]>= > =0ATo: Mark Foo <[EMAIL PROTECTED]>=0ACc: [EMAIL PROTECTED]: Tues= > day, September 23, 2008 5:46:58 PM=0ASubject: Re: YAY! Re: Atrivo/Intercage= > : NO Upstream depeer=0A=0AHold the rejoicing, Atrivo is back, this time on = > UnitedLayer.=0A=0AI'd contact them, only they seem to change CTOs every mon= > th or two,=0Adoes anybody know who's currently in charge?=0A=0AThank you, a= > nd Drive Slow,=0APaul Wall=0A=0A=0A Speaking of missing memos... mailing lists are not highly compatible with HTML or some clients that like to encode list mail. The above is what your mail looked like to some people. I would suggest a different Step 1. Instead of killing power, simply isolate the affected machine. This might be as simple as putting up a firewall rule or two, if it is simply sending outgoing SMTP spam, or for more complex issues, downing the port facing the machine in question. Killing the power may destroy useful forensic clues about what happened to the system, and may damage the system. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer
Hello Paul, Those are their IP Blocks. We were simply routing them, as they were our client. They've owned these blocks for quite a while. They seem to have moved that after a day of being down. I haven't been monitoring their blocks, and made the decision Sunday Night that they were no longer going to be allowed on our network. I believe the blocks your referring to are their 85.255 Blocks? Registered to "InHoster". I believe those prefixes are an entity of their's, though I don't know for sure. Perhaps ask them? Cernel is their own ASN. It's not associated with our company. Thank you for your time. Have a great day. --- Russell Mitchell InterCage, Inc. - Original Message From: Paul Ferguson <[EMAIL PROTECTED]> To: Russell Mitchell <[EMAIL PROTECTED]> Cc: nanog@nanog.org Sent: Tuesday, September 23, 2008 9:22:03 PM Subject: Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Russ, While I think that is great and everything, can you explain why Cernel is now originating prefixes which were originally originated by Atrivo/Intercage? I'd be curious as to your explanation. Thanks, - - ferg On Tue, Sep 23, 2008 at 9:05 PM, Russell Mitchell <[EMAIL PROTECTED]> wrote: > Apologies, Yahoo was set to "Rich Text" :( > > - > > Hello All, > > It seems you all missed the memo.As of about 11PM PST > Last night 09/22/08, Esthost has been ENTIRELY Shutdown. > They no longer have ANY Machine on my network. > > I'm currently starting to monitor some of the public media, such as > google, DroneBL, as well as several Anti-Malware community websites for > abuse. Being that Esthost is now entirely GONE, we should not have any > further issues. In the case that something does arise, such as an > exploited host, we're currently developing a game plan for response to > the issues. > > To make the best effort towards combatting abuse on our network, here's > what I have planned so far for ANY Type of abuse: Step 1, Suspend Power > to the affected machine. > Step 2, Call/Email the client whom the affected machine is leased to. > Step 3, Allow the client the option to investigate the machine further > (Nullroute access via KVM)= Step 4, Verify the reported content, domain, > user, or exploit is patched/eliminated from the machine. Step 5, Remove > the Nullroute. Allow the machine to return to the network. > > Any comments? This is the result of a zero tolerance policy regarding > abuse. > > If it's clear that the server owner is the cause of the abusive material > etc, the client will then be immediately cancelled. No questions. It > seems that this approach will be the best supported by the anti-abuse > communities, so please let me know your input. > > Thank you for your time. Have a great day. > > --- > Russell Mitchell > InterCage, Inc. > > > > > > -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI2cBUq1pz9mNUZTMRAtbAAJwKk/H/9Pz4YelIgnYvtuCCDhmuswCfcrfV PTUD/SyPo8+zHpACucRPqk4= =+rwg -END PGP SIGNATURE- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/
Re: Yahoo Email
In article <[EMAIL PROTECTED]> you write: >> Hello All,=0A=A0=0AIt seems you all missed the memo.=0AAs of about 11PM PST= >> Last night 09/22/08, Esthost has been ENTIRELY Shutdown. They no longer ha= >> ve ANY Machine on my network.=0A=A0=0AI'm currently starting to monitor som= >> e of the public media, such as google, DroneBL, as well as several Anti-Mal= >> ware community websites for abuse.=0A=A0=0ABeing that Esthost is now entire= [snipped] >Speaking of missing memos... mailing lists are not highly compatible >with HTML or some clients that like to encode list mail. The above is >what your mail looked like to some people. Most email from Yahoo is like this. Yahoo doesn't know how to do quoted-printable properly. It displays ok if you speak mime but not if you don't. The intent of quoted-printable is to display ASCII nicely if you don't have a mime compliant reader. Mark RFC 2045. The Quoted-Printable encoding is intended to represent data that largely consists of octets that correspond to printable characters in the US-ASCII character set. It encodes the data in such a way that the resulting octets are unlikely to be modified by mail transport. If the data being encoded are mostly US-ASCII text, the encoded form of the data remains largely recognizable by humans. A body which is entirely US-ASCII may also be encoded in Quoted-Printable to ensure the integrity of the data should the message pass through a character-translating, and/or line-wrapping gateway. also (4) (Line Breaks) A line break in a text body, represented as a CRLF sequence in the text canonical form, must be represented by a (RFC 822) line break, which is also a CRLF sequence, in the Quoted-Printable encoding. Since the canonical representation of media types other than text do not generally include the representation of line breaks as CRLF sequences, no hard line breaks (i.e. line breaks that are intended to be meaningful and to be displayed to the user) can occur in the quoted-printable encoding of such types. Sequences like "=0D", "=0A", "=0A=0D" and "=0D=0A" will routinely appear in non-text data represented in quoted- printable, of course.
Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It may be true that Estdomains has moved a couple of the external-facing a hosting hosts into the a Netherlands hosting provider in conjunction with this whole situation -- folks are watching very carefully. estdomains.com A 94.102.49.3 storefront.estdomains.com A 94.102.49.5 www.estdomains.com A 94.102.49.4 www.estsecure.com A 94.102.49.5 AS | IP | AS Name 29073 | 94.102.49.3 | ECATEL-AS AS29073, Ecatel Network % Information related to '94.102.48.0 - 94.102.63.255' inetnum: 94.102.48.0 - 94.102.63.255 netname: NL-ECATEL-20080829 descr: Ecatel LTD country: NL org: ORG-EL38-RIPE admin-c: RvE16-RIPE tech-c: RvE16-RIPE status: ALLOCATED PA mnt-by: RIPE-NCC-HM-MNT mnt-lower: ECATEL-MNT mnt-routes: ECATEL-MNT source: RIPE # Filtered organisation: ORG-EL38-RIPE org-name: Ecatel LTD org-type: LIR address: Ecatel LTD Reinier van Eeden P.O.Box 19533 2521 CA The Hague NETHERLANDS phone: +31702204015 fax-no: +31702204015 e-mail: [EMAIL PROTECTED] admin-c: RvE16-RIPE mnt-ref: ECATEL-MNT mnt-ref: RIPE-NCC-HM-MNT mnt-by: RIPE-NCC-HM-MNT source: RIPE # Filtered DNSLogger: estdomains.com A 94.102.49.3 estdomains.com A 216.255.176.238 estdomains.com NS ans1.esthost.com estdomains.com NS ans2.esthost.com estdomains.com NS temp1.estdomains.com estdomains.com NS ns1.estdomains.com estdomains.com NS temp2.estdomains.com estdomains.com NS ns2.estdomains.com http://www.bfk.de/bfk_dnslogger.html Thanks, - - ferg On Tue, Sep 23, 2008 at 9:05 PM, Russell Mitchell <[EMAIL PROTECTED]> wrote: > Apologies, Yahoo was set to "Rich Text" :( > > - > > Hello All, > > It seems you all missed the memo.As of about 11PM PST > Last night 09/22/08, Esthost has been ENTIRELY Shutdown. > They no longer have ANY Machine on my network. > -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI2cVCq1pz9mNUZTMRAtC1AJ9UK326w0H3C8lpB1cxz6EJC6KbqwCgjlwA 3WvkkgfWuVapwt1OKbys4dk= =B4vI -END PGP SIGNATURE- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/
Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Russ, While I think that is great and everything, can you explain why Cernel is now originating prefixes which were originally originated by Atrivo/Intercage? I'd be curious as to your explanation. Thanks, - - ferg On Tue, Sep 23, 2008 at 9:05 PM, Russell Mitchell <[EMAIL PROTECTED]> wrote: > Apologies, Yahoo was set to "Rich Text" :( > > - > > Hello All, > > It seems you all missed the memo.As of about 11PM PST > Last night 09/22/08, Esthost has been ENTIRELY Shutdown. > They no longer have ANY Machine on my network. > > I'm currently starting to monitor some of the public media, such as > google, DroneBL, as well as several Anti-Malware community websites for > abuse. Being that Esthost is now entirely GONE, we should not have any > further issues. In the case that something does arise, such as an > exploited host, we're currently developing a game plan for response to > the issues. > > To make the best effort towards combatting abuse on our network, here's > what I have planned so far for ANY Type of abuse: Step 1, Suspend Power > to the affected machine. > Step 2, Call/Email the client whom the affected machine is leased to. > Step 3, Allow the client the option to investigate the machine further > (Nullroute access via KVM)= Step 4, Verify the reported content, domain, > user, or exploit is patched/eliminated from the machine. Step 5, Remove > the Nullroute. Allow the machine to return to the network. > > Any comments? This is the result of a zero tolerance policy regarding > abuse. > > If it's clear that the server owner is the cause of the abusive material > etc, the client will then be immediately cancelled. No questions. It > seems that this approach will be the best supported by the anti-abuse > communities, so please let me know your input. > > Thank you for your time. Have a great day. > > --- > Russell Mitchell > InterCage, Inc. > > > > > > -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI2cBUq1pz9mNUZTMRAtbAAJwKk/H/9Pz4YelIgnYvtuCCDhmuswCfcrfV PTUD/SyPo8+zHpACucRPqk4= =+rwg -END PGP SIGNATURE- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/
Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer
Apologies, Yahoo was set to "Rich Text" :( - Hello All, It seems you all missed the memo.As of about 11PM PST Last night 09/22/08, Esthost has been ENTIRELY Shutdown. They no longer have ANY Machine on my network. I'm currently starting to monitor some of the public media, such as google, DroneBL, as well as several Anti-Malware community websites for abuse. Being that Esthost is now entirely GONE, we should not have any further issues. In the case that something does arise, such as an exploited host, we're currently developing a game plan for response to the issues. To make the best effort towards combatting abuse on our network, here's what I have planned so far for ANY Type of abuse: Step 1, Suspend Power to the affected machine. Step 2, Call/Email the client whom the affected machine is leased to. Step 3, Allow the client the option to investigate the machine further (Nullroute access via KVM)= Step 4, Verify the reported content, domain, user, or exploit is patched/eliminated from the machine. Step 5, Remove the Nullroute. Allow the machine to return to the network. Any comments? This is the result of a zero tolerance policy regarding abuse. If it's clear that the server owner is the cause of the abusive material etc, the client will then be immediately cancelled. No questions. It seems that this approach will be the best supported by the anti-abuse communities, so please let me know your input. Thank you for your time. Have a great day. --- Russell Mitchell InterCage, Inc.
Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer
using bolt cutters on cables has a certain satisfaction... On Tue, Sep 23, 2008 at 8:23 PM, Christopher Morrow <[EMAIL PROTECTED]> wrote: > On Tue, Sep 23, 2008 at 11:20 PM, Joe Greco <[EMAIL PROTECTED]> wrote: > >> I would suggest a different Step 1. Instead of killing power, simply >> isolate the affected machine. This might be as simple as putting up a >> firewall rule or two, if it is simply sending outgoing SMTP spam, or > > it's probably easiest (depending on the network gear of course) to > just put the lan port into an isolated VLAN. It's not the 100% > solution (some badness rm's itself once it loses connectivity to the > internets) but it'd make things simpler for the client/LEA when they > need to figure out what happened. > > -chris > >
RE: hat tip to .gov hostmasters
Pretty soon we'll have a blacklist of DNS servers that don't support DNSSEC for .gov. =) Frank -Original Message- From: Chris Owen [mailto:[EMAIL PROTECTED] Sent: Monday, September 22, 2008 10:02 AM To: NANOG list Subject: Re: hat tip to .gov hostmasters -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 22, 2008, at 9:59 AM, Simon Vallet wrote: > On Mon, 22 Sep 2008 10:52:42 -0400 > "Jason Frisvold" <[EMAIL PROTECTED]> wrote: > >> I'm not much up on DNSSEC, but don't you need to be using a resolver >> that recognizes DNSSEC in order for this to be useful? > > You do -- and last time I checked few native resolvers actually did : > glibc doesn't, and I'd be surprised if the Windows resolver does Chicken, meet egg. I think the point of the original post is that one end or the other has to start things. At least we have one US zone doing something on the server end of things. Chris Chris Owen ~ Garden City (620) 275-1900 ~ Lottery (noun): President ~ Wichita (316) 858-3000 ~A stupidity tax Hubris Communications Inc www.hubris.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Public Key: http://home.hubris.net/owenc/pgpkey.txt Comment: Public Key ID: 0xB513D9DD iEYEARECAAYFAkjXs30ACgkQElUlCLUT2d0SfwCbB8FQ4izN061GoQQMl3fkq+NT ga0AoJnwGG8PfBs5PaziRB6m0NQBuZwc =68dm -END PGP SIGNATURE-
Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer
On Tue, Sep 23, 2008 at 11:20 PM, Joe Greco <[EMAIL PROTECTED]> wrote: > I would suggest a different Step 1. Instead of killing power, simply > isolate the affected machine. This might be as simple as putting up a > firewall rule or two, if it is simply sending outgoing SMTP spam, or it's probably easiest (depending on the network gear of course) to just put the lan port into an isolated VLAN. It's not the 100% solution (some badness rm's itself once it loses connectivity to the internets) but it'd make things simpler for the client/LEA when they need to figure out what happened. -chris
Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer
please to not email in html format... yikes! Russ, could you re-mail whatever content you just sent, in plain text? On Tue, Sep 23, 2008 at 11:07 PM, Russell Mitchell <[EMAIL PROTECTED]> wrote: > MIME-Version: 1.0 > Content-Type: multipart/alternative; boundary="0-593512929-125655=:9145" > > --0-593512929-125655=:9145 > Content-Type: text/plain; charset=iso-8859-1 > Content-Transfer-Encoding: quoted-printable > > Hello All,=0A=A0=0AIt seems you all missed the memo.=0AAs of about 11PM PST= > Last night 09/22/08, Esthost has been ENTIRELY Shutdown. They no longer ha= > ve ANY Machine on my network.=0A=A0=0AI'm currently starting to monitor som= > e of the public media, such as google, DroneBL, as well as several Anti-Mal= > ware community websites for abuse.=0A=A0=0ABeing that Esthost is now entire= > ly GONE, we should not have any further issues.=0AIn the case that somethin= > g=A0does arise, such as an exploited host, we're currently developing a gam= > e plan for=A0response to=A0the issues.=0ATo make the best effort towards co= > mbatting=A0abuse on our network, here's what I have planned so far for ANY = > Type of abuse:=0AStep 1,=A0Suspend Power to the affected machine.=0AStep 2,= > Call/Email the client whom the affected machine is leased to.=0AStep 3, Al= > low the client=A0the option to=A0investigate the machine further (Nullroute= > access via KVM)=0AStep=A04, Verify the=A0reported content, domain, user, o= > r exploit=A0is patched/eliminated from the machine.=0AStep 5,=A0Remove the = > Nullroute. Allow the machine to return to the network.=0A=A0=0AAny comments= > ? =0A=A0=0AThis is=A0the result of a zero tolerance policy regarding abuse.= > If it's clear that the server owner is the cause of the abusive material e= > tc, the client will then be immediately cancelled. No questions.=A0=0A=0A= > =0AIt seems that this approach will be the best supported by the anti-abuse= > communities, so please let me know your input.=0A=0AThank you for your tim= > e. Have a great day.=0A=A0---=0ARussell Mitchell=0A=0AInterCage, Inc.=0A=0A= > =0A=0A- Original Message =0AFrom: Paul Wall <[EMAIL PROTECTED]>= > =0ATo: Mark Foo <[EMAIL PROTECTED]>=0ACc: [EMAIL PROTECTED]: Tues= > day, September 23, 2008 5:46:58 PM=0ASubject: Re: YAY! Re: Atrivo/Intercage= > : NO Upstream depeer=0A=0AHold the rejoicing, Atrivo is back, this time on = > UnitedLayer.=0A=0AI'd contact them, only they seem to change CTOs every mon= > th or two,=0Adoes anybody know who's currently in charge?=0A=0AThank you, a= > nd Drive Slow,=0APaul Wall=0A=0A=0A > --0-593512929-125655=:9145 > Content-Type: text/html; charset=us-ascii > > Hello All, > > It seems you all missed the memo.As of about 11PM PST Last night > 09/22/08, Esthost has been ENTIRELY Shutdown. They no longer have ANY Machine > on my network. > > I'm currently starting to monitor some of the public media, such as > google, DroneBL, as well as several Anti-Malware community websites for > abuse. > > Being that Esthost is now entirely GONE, we should not have any further > issues. > In the case that something does arise, such as an exploited host, we're > currently developing a game plan for response to the issues. > To make the best effort towards combatting abuse on our network, here's > what I have planned so far for ANY Type of abuse: > Step 1, Suspend Power to the affected machine. > Step 2, Call/Email the client whom the affected machine is leased to. > Step 3, Allow the client the option to investigate the machine further > (Nullroute access via KVM) > Step 4, Verify the reported content, domain, user, or exploit is > patched/eliminated from the machine. > Step 5, Remove the Nullroute. Allow the machine to return to the > network. > > Any comments? > > This is the result of a zero tolerance policy regarding abuse. If it's > clear that the server owner is the cause of the abusive material etc, the > client will then be immediately cancelled. No questions. > > > > It seems that this approach will be the best supported by the anti-abuse > communities, so please let me know your input. > > Thank you for your time. Have a great day. ---Russell > Mitchell > InterCage, Inc. > > - > Original Message From: Paul Wall <[EMAIL PROTECTED]>To: Mark Foo > <[EMAIL PROTECTED]>Cc: nanog@nanog.orgSent: Tuesday, September 23, > 2008 5:46:58 PMSubject: Re: YAY! Re: Atrivo/Intercage: NO Upstream > depeerHold the rejoicing, Atrivo is back, this time on > UnitedLayer.I'd contact them, only they seem to change CTOs every > month or two,does anybody know who's currently in charge?Thank > you, and Drive Slow,Paul Wall > > > --0-593512929-125655=:9145-- > > >
Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer
> Hello All,=0A=A0=0AIt seems you all missed the memo.=0AAs of about 11PM PST= > Last night 09/22/08, Esthost has been ENTIRELY Shutdown. They no longer ha= > ve ANY Machine on my network.=0A=A0=0AI'm currently starting to monitor som= > e of the public media, such as google, DroneBL, as well as several Anti-Mal= > ware community websites for abuse.=0A=A0=0ABeing that Esthost is now entire= > ly GONE, we should not have any further issues.=0AIn the case that somethin= > g=A0does arise, such as an exploited host, we're currently developing a gam= > e plan for=A0response to=A0the issues.=0ATo make the best effort towards co= > mbatting=A0abuse on our network, here's what I have planned so far for ANY = > Type of abuse:=0AStep 1,=A0Suspend Power to the affected machine.=0AStep 2,= > Call/Email the client whom the affected machine is leased to.=0AStep 3, Al= > low the client=A0the option to=A0investigate the machine further (Nullroute= > access via KVM)=0AStep=A04, Verify the=A0reported content, domain, user, o= > r exploit=A0is patched/eliminated from the machine.=0AStep 5,=A0Remove the = > Nullroute. Allow the machine to return to the network.=0A=A0=0AAny comments= > ? =0A=A0=0AThis is=A0the result of a zero tolerance policy regarding abuse.= > If it's clear that the server owner is the cause of the abusive material e= > tc, the client will then be immediately cancelled. No questions.=A0=0A=0A= > =0AIt seems that this approach will be the best supported by the anti-abuse= > communities, so please let me know your input.=0A=0AThank you for your tim= > e. Have a great day.=0A=A0---=0ARussell Mitchell=0A=0AInterCage, Inc.=0A=0A= > =0A=0A- Original Message =0AFrom: Paul Wall <[EMAIL PROTECTED]>= > =0ATo: Mark Foo <[EMAIL PROTECTED]>=0ACc: [EMAIL PROTECTED]: Tues= > day, September 23, 2008 5:46:58 PM=0ASubject: Re: YAY! Re: Atrivo/Intercage= > : NO Upstream depeer=0A=0AHold the rejoicing, Atrivo is back, this time on = > UnitedLayer.=0A=0AI'd contact them, only they seem to change CTOs every mon= > th or two,=0Adoes anybody know who's currently in charge?=0A=0AThank you, a= > nd Drive Slow,=0APaul Wall=0A=0A=0A Speaking of missing memos... mailing lists are not highly compatible with HTML or some clients that like to encode list mail. The above is what your mail looked like to some people. I would suggest a different Step 1. Instead of killing power, simply isolate the affected machine. This might be as simple as putting up a firewall rule or two, if it is simply sending outgoing SMTP spam, or for more complex issues, downing the port facing the machine in question. Killing the power may destroy useful forensic clues about what happened to the system, and may damage the system. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: Atrivo/Intercage
> On Sep 22, 2008, at 1:33 PM, Tom Sparks (Applied Operations) wrote: > > I also don't believe Intercage was complicit in any > > net-crime; Thats not to say it didn't exist, but more along the lines > > of they got lost in the noise of running a business. > > Which is not acceptable. You answer your abuse complaints, you shut > down your spammers. Period, end of subject. That's a bit '90's. I'll settle for s/answer/handle/, because I don't think that most sites are willing to actually discuss abuse issues with random folks submitting complaints, and so that leaves you with either sending a form letter of some sort, or not saying anything. Further, many places seem to send form letters but not do anything. I am not sure that there is much (or any) value-add in sending a response, unless further information is needed. >From my point of view, the best response is when the problem simply goes away. A personal reply (rather than a form letter) is also generally a really good sign that someone cares enough to show that they're doing something, but again that seems to be the exception rather than the norm. The Afterburner experience, however, should be an excellent example for the difference that simply *showing* you care and are doing something makes. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer
MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-593512929-125655=:9145" --0-593512929-125655=:9145 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hello All,=0A=A0=0AIt seems you all missed the memo.=0AAs of about 11PM PST= Last night 09/22/08, Esthost has been ENTIRELY Shutdown. They no longer ha= ve ANY Machine on my network.=0A=A0=0AI'm currently starting to monitor som= e of the public media, such as google, DroneBL, as well as several Anti-Mal= ware community websites for abuse.=0A=A0=0ABeing that Esthost is now entire= ly GONE, we should not have any further issues.=0AIn the case that somethin= g=A0does arise, such as an exploited host, we're currently developing a gam= e plan for=A0response to=A0the issues.=0ATo make the best effort towards co= mbatting=A0abuse on our network, here's what I have planned so far for ANY = Type of abuse:=0AStep 1,=A0Suspend Power to the affected machine.=0AStep 2,= Call/Email the client whom the affected machine is leased to.=0AStep 3, Al= low the client=A0the option to=A0investigate the machine further (Nullroute= access via KVM)=0AStep=A04, Verify the=A0reported content, domain, user, o= r exploit=A0is patched/eliminated from the machine.=0AStep 5,=A0Remove the = Nullroute. Allow the machine to return to the network.=0A=A0=0AAny comments= ? =0A=A0=0AThis is=A0the result of a zero tolerance policy regarding abuse.= If it's clear that the server owner is the cause of the abusive material e= tc, the client will then be immediately cancelled. No questions.=A0=0A=0A= =0AIt seems that this approach will be the best supported by the anti-abuse= communities, so please let me know your input.=0A=0AThank you for your tim= e. Have a great day.=0A=A0---=0ARussell Mitchell=0A=0AInterCage, Inc.=0A=0A= =0A=0A- Original Message =0AFrom: Paul Wall <[EMAIL PROTECTED]>= =0ATo: Mark Foo <[EMAIL PROTECTED]>=0ACc: [EMAIL PROTECTED]: Tues= day, September 23, 2008 5:46:58 PM=0ASubject: Re: YAY! Re: Atrivo/Intercage= : NO Upstream depeer=0A=0AHold the rejoicing, Atrivo is back, this time on = UnitedLayer.=0A=0AI'd contact them, only they seem to change CTOs every mon= th or two,=0Adoes anybody know who's currently in charge?=0A=0AThank you, a= nd Drive Slow,=0APaul Wall=0A=0A=0A --0-593512929-125655=:9145 Content-Type: text/html; charset=us-ascii Hello All, It seems you all missed the memo.As of about 11PM PST Last night 09/22/08, Esthost has been ENTIRELY Shutdown. They no longer have ANY Machine on my network. I'm currently starting to monitor some of the public media, such as google, DroneBL, as well as several Anti-Malware community websites for abuse. Being that Esthost is now entirely GONE, we should not have any further issues. In the case that something does arise, such as an exploited host, we're currently developing a game plan for response to the issues. To make the best effort towards combatting abuse on our network, here's what I have planned so far for ANY Type of abuse: Step 1, Suspend Power to the affected machine. Step 2, Call/Email the client whom the affected machine is leased to. Step 3, Allow the client the option to investigate the machine further (Nullroute access via KVM) Step 4, Verify the reported content, domain, user, or exploit is patched/eliminated from the machine. Step 5, Remove the Nullroute. Allow the machine to return to the network. Any comments? This is the result of a zero tolerance policy regarding abuse. If it's clear that the server owner is the cause of the abusive material etc, the client will then be immediately cancelled. No questions. It seems that this approach will be the best supported by the anti-abuse communities, so please let me know your input. Thank you for your time. Have a great day. ---Russell Mitchell InterCage, Inc. - Original Message From: Paul Wall <[EMAIL PROTECTED]>To: Mark Foo <[EMAIL PROTECTED]>Cc: nanog@nanog.orgSent: Tuesday, September 23, 2008 5:46:58 PMSubject: Re: YAY! Re: Atrivo/Intercage: NO Upstream depeerHold the rejoicing, Atrivo is back, this time on UnitedLayer.I'd contact them, only they seem to change CTOs every month or two,does anybody know who's currently in charge?Thank you, and Drive Slow,Paul Wall --0-593512929-125655=:9145--
Re: Atrivo/Intercage
On Sep 22, 2008, at 1:33 PM, Tom Sparks (Applied Operations) wrote: I also don't believe Intercage was complicit in any net-crime; Thats not to say it didn't exist, but more along the lines of they got lost in the noise of running a business. Which is not acceptable. You answer your abuse complaints, you shut down your spammers. Period, end of subject. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Well, their management team is listed here: http://www.unitedlayer.com/team.html - - ferg On Tue, Sep 23, 2008 at 5:46 PM, Paul Wall <[EMAIL PROTECTED]> wrote: > Hold the rejoicing, Atrivo is back, this time on UnitedLayer. > > I'd contact them, only they seem to change CTOs every month or two, > does anybody know who's currently in charge? > > Thank you, and Drive Slow, > Paul Wall > > -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI2Y/zq1pz9mNUZTMRAnfWAKClED9vjhHusr2Y6+HJ4Bc9fHAosACeOhfK 8coixrmTH5I3Hlh2phmut5w= =gzBi -END PGP SIGNATURE- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/
Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer
Hold the rejoicing, Atrivo is back, this time on UnitedLayer. I'd contact them, only they seem to change CTOs every month or two, does anybody know who's currently in charge? Thank you, and Drive Slow, Paul Wall
RE: Seattle Peering
If you are in S&D/PAIX's facility, you have two options for connecting to the SIX: - direct to the SIX core via the fiber-meet-me-room, thus no VLAN. You won't get access to the PAIX-SEA fabric with this method, but if what you really want is the SIX, this is the way to go. - direct to the PAIX-SEA switch, in which case you'll need to instruct S&D to enable your port to also have access to the SIX fabric. Your router will have two VLAN interfaces on the port, one for PAIX-SEA and one for the SIX. Feel free to direct further questions to [EMAIL PROTECTED] if you like. Chris On Tue, 23 Sep 2008, Paul Stewart wrote: > Thanks very much... we have a price from S&D for the x-connect. If we > connect on the PAIX side (most likely) do we need multiple VLAN's? I > had planned on a single VLAN on the port for there - just need to > understand ;) > > Thanks, > > Paul > > > -Original Message- > From: Chris Caputo [mailto:[EMAIL PROTECTED] > Sent: September 23, 2008 6:13 PM > To: Paul Stewart; Michael K. Smith > Cc: NANOG list > Subject: Re: Seattle Peering > > On Thu, 18 Sep 2008, Michael K. Smith wrote: > > Hello Paul: > > > > On 9/18/08 8:01 AM, "Paul Stewart" <[EMAIL PROTECTED]> wrote: > > > Hi folks... > > > > > > We're working on some plans to peer in the Seattle area. Choices so > > > far considered are SIX and PAIX Seattle pretty much > > > > > > I was of the impression that if you get a port on one of these > > > exchanges, you can connect to the other one as well? Just looking > > > for clarification from folks who are connected out there..;) Any > > > charges to go between the exchanges or it just included? > > > > Speaking from the SIX side, there is no charge to connect to the > > fabric if you supply the optics, and there is a one-time fiber cross > > connect charge of $200.00 US. The SIX and PAIX are directly connected > > and you can peer across the fabric. The SIX page is > > http://www.seattleix.net for more info or you can email me directly. > > And keep in mind that while the SIX and PAIX-SEA are directly connected, > > the exchanges are on different VLANs from the perspective of a PAIX-SEA > connection. > > If you connect on the SIX side, you can only reach the SIX fabric. No > MRC. > > If you connect on the PAIX-SEA side, you can reach both the SIX fabric > and the PAIX-SEA fabric via a single router port. For MRC talk to an > S&D rep. > > Chris
RE: Seattle Peering
Thanks very much... we have a price from S&D for the x-connect. If we connect on the PAIX side (most likely) do we need multiple VLAN's? I had planned on a single VLAN on the port for there - just need to understand ;) Thanks, Paul -Original Message- From: Chris Caputo [mailto:[EMAIL PROTECTED] Sent: September 23, 2008 6:13 PM To: Paul Stewart; Michael K. Smith Cc: NANOG list Subject: Re: Seattle Peering On Thu, 18 Sep 2008, Michael K. Smith wrote: > Hello Paul: > > On 9/18/08 8:01 AM, "Paul Stewart" <[EMAIL PROTECTED]> wrote: > > Hi folks... > > > > We're working on some plans to peer in the Seattle area. Choices so far > > considered are SIX and PAIX Seattle pretty much > > > > I was of the impression that if you get a port on one of these > > exchanges, you can connect to the other one as well? Just looking for > > clarification from folks who are connected out there..;) Any charges to > > go between the exchanges or it just included? > > Speaking from the SIX side, there is no charge to connect to the fabric if > you supply the optics, and there is a one-time fiber cross connect charge of > $200.00 US. The SIX and PAIX are directly connected and you can peer across > the fabric. The SIX page is http://www.seattleix.net for more info or you > can email me directly. And keep in mind that while the SIX and PAIX-SEA are directly connected, the exchanges are on different VLANs from the perspective of a PAIX-SEA connection. If you connect on the SIX side, you can only reach the SIX fabric. No MRC. If you connect on the PAIX-SEA side, you can reach both the SIX fabric and the PAIX-SEA fabric via a single router port. For MRC talk to an S&D rep. Chris "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."
Re: Seattle Peering
On Thu, 18 Sep 2008, Michael K. Smith wrote: > Hello Paul: > > On 9/18/08 8:01 AM, "Paul Stewart" <[EMAIL PROTECTED]> wrote: > > Hi folks... > > > > We're working on some plans to peer in the Seattle area. Choices so far > > considered are SIX and PAIX Seattle pretty much > > > > I was of the impression that if you get a port on one of these > > exchanges, you can connect to the other one as well? Just looking for > > clarification from folks who are connected out there..;) Any charges to > > go between the exchanges or it just included? > > Speaking from the SIX side, there is no charge to connect to the fabric if > you supply the optics, and there is a one-time fiber cross connect charge of > $200.00 US. The SIX and PAIX are directly connected and you can peer across > the fabric. The SIX page is http://www.seattleix.net for more info or you > can email me directly. And keep in mind that while the SIX and PAIX-SEA are directly connected, the exchanges are on different VLANs from the perspective of a PAIX-SEA connection. If you connect on the SIX side, you can only reach the SIX fabric. No MRC. If you connect on the PAIX-SEA side, you can reach both the SIX fabric and the PAIX-SEA fabric via a single router port. For MRC talk to an S&D rep. Chris
Re: prefix hijack by ASN 8997
On Mon, Sep 22, 2008 at 22:13, Jim Popovitch <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 22, 2008 at 21:06, Scott Weeks <[EMAIL PROTECTED]> wrote:
>>
>> I am hoping to confirm a short-duration prefix hijack of 72.234.0.0/15 (and
>> another of our
>> prefixes) by ASN 8997 ("OJSC North-West Telecom" in Russia) in using ASN 3267
>> (Russian Federal University Network) to advertise our space to ASN 3277
>> (Regional
>> University and Scientific Network (RUSNet) of North-Western and
>> Saint-Petersburg
>> Area of Russia).
>
> Yep, saw this for 69.61.0.0/17 GlobalCompass (my upstream) this AM:
>
> SEQUENCE_NUMBER: 1222091638
> TYPE: last-hop
> BGP-UPDATE-TIME: 1222075864
> PHAS-DETECT-TIME: 1222091637
> PHAS-NOTIFY-TIME: 1222091637
> PREFIX: 69.61.0.0/17
> SET: 3561,3267,3356,3491
> GAINED: 3267 <- Russian Federal University Network
> LOST:
>
> SEQUENCE_NUMBER: 1222091638
> TYPE: origin
> BGP-UPDATE-TIME: 1222075864
> PHAS-DETECT-TIME: 1222091637
> PHAS-NOTIFY-TIME: 1222091637
> PREFIX: 69.61.0.0/17
> SET: 8997,22653
> GAINED: 8997 <- OJSC North-West Telecom, St.-Petersburg, Russia
> LOST:
>
> SEQUENCE_NUMBER: 1222096125
> TYPE: origin
> BGP-UPDATE-TIME: 1222076569
> PHAS-DETECT-TIME: 1222092415
> PHAS-NOTIFY-TIME: 1222096124
> PREFIX: 69.61.0.0/17
> SET: 22653 <- GlobalCrossing
Small typo on my part above... 22653 is GlobalCompass, not
GlobalCrossing as I mistakenly typed above.
-Jim P.
Re: eigrp and managed ethernet
On Tuesday 23 September 2008 13:46:02 Joseph Doran wrote: > EIGRP timers over WAN media default to 60 seconds. Neighborship will not > expire for up to 180 seconds. To verify your EIGRP neighborship do a "show > ip eigrp neighbor" > > > Message: 6 > Date: Tue, 23 Sep 2008 09:25:34 -0700 (PDT) > From: Philip Lavine <[EMAIL PROTECTED]> > Subject: Re: eigrp and managed ethernet > To: nanog <[EMAIL PROTECTED]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=us-ascii > > What is really bizarre is that I am down for minutes not seconds and the > timers never fire. If I don't manually passive the connection eigrp will > for some reason think there is a neighbor even though I am unable to source > ping across the WAN. With regard to EIGRP, link type is dictated by the medium and speed. In this case, Ethernet will be considered a high-speed, broadcast link regardless of its use for LAN or WAN, so the hello/dead intervals should, by default, be 5/15 seconds.
Re: prefix hijack by ASN 8997
Scott Weeks wrote: -- [EMAIL PROTECTED] wrote: -- From: Marshall Eubanks <[EMAIL PROTECTED]> So, do you think this was lots of little tests / hijacks / mistakes ? Or did it just not propagate very far ? - According to Andree Toonk (and someone confirmed privately) ASN 8997 leaked a full table to ASN 3267 (who didn't filter!). The only upstream of ASN 3267 I saw in bgplay was ASN 174 (Cogent) who seems to have filtered, but I can't confirm. So I guess that the impact would've only been to the peers downstream of ASN 3267. scott - Andree Toonk <[EMAIL PROTECTED]> Not a false positive, It actually was detected by the RIS box in Moscow (rrc13). Strange that it's not visible in RIS search website, but it's definitely in the raw data files. Looking at that raw data from both routeviews and Ripe, it looks like they (AS8997) 'leaked' a full table, i.e. : -- I did some analysis of updates on routeviews. The only routeviews peer I saw leaking the routes was AS3277 (out of 42 peers). There were roughly 117,000 prefixes with origin AS8997 with the path going through AS3267 to AS3277. The initial announcements were seen at 09:29:32 UTC and updates with the correct path were seen starting at about 09:36:42 UTC (last ones seen at 09:43:42). -Larry
Re: eigrp and managed ethernet
EIGRP timers over WAN media default to 60 seconds. Neighborship will not expire for up to 180 seconds. To verify your EIGRP neighborship do a "show ip eigrp neighbor" Message: 6 Date: Tue, 23 Sep 2008 09:25:34 -0700 (PDT) From: Philip Lavine <[EMAIL PROTECTED]> Subject: Re: eigrp and managed ethernet To: nanog <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=us-ascii What is really bizarre is that I am down for minutes not seconds and the timers never fire. If I don't manually passive the connection eigrp will for some reason think there is a neighbor even though I am unable to source ping across the WAN.
Re: Atrivo/Intercage
http://www.giantitp.com/comics/oots0595.html I think that sums up this thread. On Tue, 23 Sep 2008, Joe Greco wrote: On Sep 22, 2008, at 4:33 PM, Tom Sparks (Applied Operations) wrote: Intercage is not a big shop, there are very few people involved in running it I have no dog in this fight, but I would comment on the "small shop" issue as it relates to handling abuse complaints. I own a small colo/hosting shop too. We don't have many employees. If we had to deal with so many abuse complaints that things were "getting lost in the noise", I'd have to seriously examine my AUP and associated enforcement policies, add staff to handle abuse issues, or both. Being small isn't an excuse. In fact, a small shop that runs a clean network should be far better at handling abuse issues than the larger players could ever hope to be. I would have to agree with this latter bit. We count incidents per YEAR. On a hand. Mostly because we haven't made a habit of accepting random clients, I guess, but were it a problem, it would be made not to be. Being proactive is a big part of this. For example, when ARIN began to allow abuse contacts for IP space, we fairly quickly registered a POC for it. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: eigrp and managed ethernet
You may want to check out BFD for EIGRP, http://www.cisco.com/en/US/technologies/tk648/tk365/tk207/technologies_white_paper0900aecd80243fe7_ps6599_Products_White_Paper.html Regards, Kevin On Tue, Sep 23, 2008 at 11:25 AM, Philip Lavine <[EMAIL PROTECTED]> wrote: > What is really bizarre is that I am down for minutes not seconds and the > timers never fire. If I don't manually passive the connection eigrp will for > some reason think there is a neighbor even though I am unable to source ping > across the WAN. > > > > - Original Message > From: Matthew Huff <[EMAIL PROTECTED]> > To: Philip Lavine <[EMAIL PROTECTED]>; nanog <[EMAIL PROTECTED]> > Sent: Tuesday, September 23, 2008 8:59:14 AM > Subject: RE: eigrp and managed ethernet > > Correct. Eigrp neighbor connectivity has a short-cut when L2 connectivity > goes down, otherwise it will use the eigrp neighbor hold-down timer. You can > decrease that timer: > > interface fa0/0 > ip hello-interval eigrp p x > ip hold-time eigrp p y > > where p is your eigrp as-number, and x is how often you want the hello (in > seconds) and y is the max hold-down timer. Generally y is = x * 3 > > http://www.cisco.com/en/US/docs/ios/12_2/iproute/command/reference/1rfeigrp.html > > > > Matthew Huff | One Manhattanville Rd > OTA Management LLC | Purchase, NY 10577 > www.ox.com| Phone: 914-460-4039 > aim: matthewbhuff | Fax: 914-460-4139 > > -Original Message- > From: Philip Lavine [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 23, 2008 11:43 AM > To: nanog > Subject: eigrp and managed ethernet > > For some reason when I lose layer 3 connectivity between two managed Ethernet > sites EIGRP does not bounce.Is this because the physical interface does not > bounce? > > > > >
Re: eigrp and managed ethernet
Be sure to differentiate between unicast and multicast reachability. Try 'ping 224.0.0.10'. Stephen Kratzer On Tuesday 23 September 2008 12:25:34 Philip Lavine wrote: > What is really bizarre is that I am down for minutes not seconds and the > timers never fire. If I don't manually passive the connection eigrp will > for some reason think there is a neighbor even though I am unable to source > ping across the WAN. > > > > - Original Message > From: Matthew Huff <[EMAIL PROTECTED]> > To: Philip Lavine <[EMAIL PROTECTED]>; nanog <[EMAIL PROTECTED]> > Sent: Tuesday, September 23, 2008 8:59:14 AM > Subject: RE: eigrp and managed ethernet > > Correct. Eigrp neighbor connectivity has a short-cut when L2 connectivity > goes down, otherwise it will use the eigrp neighbor hold-down timer. You > can decrease that timer: > > interface fa0/0 > ip hello-interval eigrp p x > ip hold-time eigrp p y > > where p is your eigrp as-number, and x is how often you want the hello (in > seconds) and y is the max hold-down timer. Generally y is = x * 3 > > http://www.cisco.com/en/US/docs/ios/12_2/iproute/command/reference/1rfeigrp >.html > > > > Matthew Huff | One Manhattanville Rd > OTA Management LLC | Purchase, NY 10577 > www.ox.com| Phone: 914-460-4039 > aim: matthewbhuff | Fax: 914-460-4139 > > -Original Message- > From: Philip Lavine [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 23, 2008 11:43 AM > To: nanog > Subject: eigrp and managed ethernet > > For some reason when I lose layer 3 connectivity between two managed > Ethernet sites EIGRP does not bounce.Is this because the physical interface > does not bounce?
RE: eigrp and managed ethernet
The issue may be that only one direction of traffic is being impacted. So maybe your A end is receiving all the hellos, while the Z end is not. Therefore A still has Z as a neighbor, but Z doesn't have A as a neighbor. Brian Knoll -Original Message- From: Philip Lavine [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 23, 2008 11:26 AM To: nanog Subject: Re: eigrp and managed ethernet What is really bizarre is that I am down for minutes not seconds and the timers never fire. If I don't manually passive the connection eigrp will for some reason think there is a neighbor even though I am unable to source ping across the WAN. - Original Message From: Matthew Huff <[EMAIL PROTECTED]> To: Philip Lavine <[EMAIL PROTECTED]>; nanog <[EMAIL PROTECTED]> Sent: Tuesday, September 23, 2008 8:59:14 AM Subject: RE: eigrp and managed ethernet Correct. Eigrp neighbor connectivity has a short-cut when L2 connectivity goes down, otherwise it will use the eigrp neighbor hold-down timer. You can decrease that timer: interface fa0/0 ip hello-interval eigrp p x ip hold-time eigrp p y where p is your eigrp as-number, and x is how often you want the hello (in seconds) and y is the max hold-down timer. Generally y is = x * 3 http://www.cisco.com/en/US/docs/ios/12_2/iproute/command/reference/1rfeigrp.html Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 www.ox.com| Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 -Original Message- From: Philip Lavine [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 23, 2008 11:43 AM To: nanog Subject: eigrp and managed ethernet For some reason when I lose layer 3 connectivity between two managed Ethernet sites EIGRP does not bounce.Is this because the physical interface does not bounce?
Re: eigrp and managed ethernet
Are you 100% positive that the link is really not passing any traffic? Have you looked at interface stats to verify that there are no incoming packets? I'd suggest running some EIGRP debug commands during the outage to verify if you are really not getting any packets.. Philip Lavine <[EMAIL PROTECTED]> 09/23/2008 09:25 AM To nanog <[EMAIL PROTECTED]> cc Subject Re: eigrp and managed ethernet What is really bizarre is that I am down for minutes not seconds and the timers never fire. If I don't manually passive the connection eigrp will for some reason think there is a neighbor even though I am unable to source ping across the WAN. - Original Message From: Matthew Huff <[EMAIL PROTECTED]> To: Philip Lavine <[EMAIL PROTECTED]>; nanog <[EMAIL PROTECTED]> Sent: Tuesday, September 23, 2008 8:59:14 AM Subject: RE: eigrp and managed ethernet Correct. Eigrp neighbor connectivity has a short-cut when L2 connectivity goes down, otherwise it will use the eigrp neighbor hold-down timer. You can decrease that timer: interface fa0/0 ip hello-interval eigrp p x ip hold-time eigrp p y where p is your eigrp as-number, and x is how often you want the hello (in seconds) and y is the max hold-down timer. Generally y is = x * 3 http://www.cisco.com/en/US/docs/ios/12_2/iproute/command/reference/1rfeigrp.html Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 www.ox.com| Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 -Original Message- From: Philip Lavine [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 23, 2008 11:43 AM To: nanog Subject: eigrp and managed ethernet For some reason when I lose layer 3 connectivity between two managed Ethernet sites EIGRP does not bounce.Is this because the physical interface does not bounce?
Re: eigrp and managed ethernet
What is really bizarre is that I am down for minutes not seconds and the timers never fire. If I don't manually passive the connection eigrp will for some reason think there is a neighbor even though I am unable to source ping across the WAN. - Original Message From: Matthew Huff <[EMAIL PROTECTED]> To: Philip Lavine <[EMAIL PROTECTED]>; nanog <[EMAIL PROTECTED]> Sent: Tuesday, September 23, 2008 8:59:14 AM Subject: RE: eigrp and managed ethernet Correct. Eigrp neighbor connectivity has a short-cut when L2 connectivity goes down, otherwise it will use the eigrp neighbor hold-down timer. You can decrease that timer: interface fa0/0 ip hello-interval eigrp p x ip hold-time eigrp p y where p is your eigrp as-number, and x is how often you want the hello (in seconds) and y is the max hold-down timer. Generally y is = x * 3 http://www.cisco.com/en/US/docs/ios/12_2/iproute/command/reference/1rfeigrp.html Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 www.ox.com| Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 -Original Message- From: Philip Lavine [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 23, 2008 11:43 AM To: nanog Subject: eigrp and managed ethernet For some reason when I lose layer 3 connectivity between two managed Ethernet sites EIGRP does not bounce.Is this because the physical interface does not bounce?
Re: eigrp and managed ethernet
On Tuesday 23 September 2008 11:43:06 Philip Lavine wrote: > For some reason when I lose layer 3 connectivity between two managed > Ethernet sites EIGRP does not bounce.Is this because the physical interface > does not bounce? Because EIGRP hellos are sent via IP multicast, layer 3 connectivity is required to establish and maintain adjacencies. However, layer 3 failures aren't detected for, at most, 15 seconds by default on an Ethernet link. Stephen Kratzer Network Engineer CTI Networks, Inc.
RE: eigrp and managed ethernet
Yeah. If the link-layer failure is hidden from your routing protocol, then the routing protocol has to rely on its timer setting. When your EIGRP's hold-time expires, peering would bounce. Luan -Original Message- From: Philip Lavine [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 23, 2008 11:43 AM To: nanog Subject: eigrp and managed Ethernet For some reason when I lose layer 3 connectivity between two managed Ethernet sites EIGRP does not bounce.Is this because the physical interface does not bounce?
Re: prefix hijack by ASN 8997
Note that my bgp was through Cogent - my guess is they did filter. Marshall On Sep 23, 2008, at 11:54 AM, Scott Weeks wrote: -- [EMAIL PROTECTED] wrote: -- From: Marshall Eubanks <[EMAIL PROTECTED]> So, do you think this was lots of little tests / hijacks / mistakes ? Or did it just not propagate very far ? - According to Andree Toonk (and someone confirmed privately) ASN 8997 leaked a full table to ASN 3267 (who didn't filter!). The only upstream of ASN 3267 I saw in bgplay was ASN 174 (Cogent) who seems to have filtered, but I can't confirm. So I guess that the impact would've only been to the peers downstream of ASN 3267. scott - Andree Toonk <[EMAIL PROTECTED]> Not a false positive, It actually was detected by the RIS box in Moscow (rrc13). Strange that it's not visible in RIS search website, but it's definitely in the raw data files. Looking at that raw data from both routeviews and Ripe, it looks like they (AS8997) 'leaked' a full table, i.e. : --
RE: eigrp and managed ethernet
Correct. Eigrp neighbor connectivity has a short-cut when L2 connectivity goes down, otherwise it will use the eigrp neighbor hold-down timer. You can decrease that timer: interface fa0/0 ip hello-interval eigrp p x ip hold-time eigrp p y where p is your eigrp as-number, and x is how often you want the hello (in seconds) and y is the max hold-down timer. Generally y is = x * 3 http://www.cisco.com/en/US/docs/ios/12_2/iproute/command/reference/1rfeigrp.html Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 www.ox.com| Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 -Original Message- From: Philip Lavine [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 23, 2008 11:43 AM To: nanog Subject: eigrp and managed ethernet For some reason when I lose layer 3 connectivity between two managed Ethernet sites EIGRP does not bounce.Is this because the physical interface does not bounce?
Re: prefix hijack by ASN 8997
-- [EMAIL PROTECTED] wrote: -- From: Marshall Eubanks <[EMAIL PROTECTED]> So, do you think this was lots of little tests / hijacks / mistakes ? Or did it just not propagate very far ? - According to Andree Toonk (and someone confirmed privately) ASN 8997 leaked a full table to ASN 3267 (who didn't filter!). The only upstream of ASN 3267 I saw in bgplay was ASN 174 (Cogent) who seems to have filtered, but I can't confirm. So I guess that the impact would've only been to the peers downstream of ASN 3267. scott - Andree Toonk <[EMAIL PROTECTED]> Not a false positive, It actually was detected by the RIS box in Moscow (rrc13). Strange that it's not visible in RIS search website, but it's definitely in the raw data files. Looking at that raw data from both routeviews and Ripe, it looks like they (AS8997) 'leaked' a full table, i.e. : --
eigrp and managed ethernet
For some reason when I lose layer 3 connectivity between two managed Ethernet sites EIGRP does not bounce.Is this because the physical interface does not bounce?
Re: prefix hijack by ASN 8997
On Sep 23, 2008, at 8:15 AM, Scott Weeks wrote:
--- [EMAIL PROTECTED] wrote:
From: Marshall Eubanks <[EMAIL PROTECTED]>
: You didn't specify the time zone you are in,
: so I looked at +- 1 day around it. If the
: hijack lasted 6 hours, we should have seen it.
My apologies, I just used the time zone the tool
(bgplay.routeviews.org/bgplay) was using when I said:
22/9/2008 9:00:00 and 22/9/2008 15:00:00
I'm sure it was in GMT. Seeing the many responses, we now know
something happened and it was only about 15 minutes in duration.
These two times are separated by 6 hours exactly (0500 and 1100 EDT).
There is a positive report at 1330 Moscow time or 0930 UTC or 0530 EDT.
There is a positive report "a few minutes" before 0122 UTC - say 0115
There is a positive report at 1222091563 which I cannot interpret.
(1222 UTC ?)
We have my negative reports at 0607 EDT and 1207 EDT, etc., or 1007
UTC and 1607 UTC, etc.
So (all times UTC)
0407 no
0900 yes
0930 yes
1007 no
1500 yes
1607 no
2207 no
0115 yes
0407 no
So, do you think this was lots of little tests / hijacks / mistakes ?
Or did it just not propagate very far ?
Marshall
bgplay shows the problem with the above data and I was just
wondering if I was understanding the impact correctly:
If the above two are correct, would it be
correct to say only the downstream customers
of ASN 3267 were affected?
I was not following the rules properly: never attribute to malice
that which can be explained by human error. I thought there might
be some testing-of-the-water in preparation for future 'events' and
I guess I was starting to be trigger happy after all the talk about
the new BGP attack.
scott
--- [EMAIL PROTECTED] wrote:
From: Marshall Eubanks <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: <[EMAIL PROTECTED]>
Subject: Re: prefix hijack by ASN 8997
Date: Tue, 23 Sep 2008 07:51:36 -0400
On Sep 22, 2008, at 9:06 PM, Scott Weeks wrote:
I am hoping to confirm a short-duration prefix hijack of
72.234.0.0/15 (and another of our prefixes) by ASN 8997 ("OJSC North-
West Telecom" in Russia) in using ASN 3267 (Russian Federal
University Network) to advertise our space to ASN 3277 (Regional
University and Scientific Network (RUSNet) of North-Western and
Saint-Petersburg Area of Russia).
Is that what I'm seeing when I go to "bgplay.routeviews.org/bgplay",
put in prefix 72.234.0.0/15 and select the dates:
22/9/2008 9:00:00 and 22/9/2008 15:00:00
If so, am I understanding it correctly if I say ASN 3267 saw a
shorter path from ASN 8997, so refused the proper announcement from
ASN 36149 (me) it normally hears from ASN 174 (Cogent).
I cannot confirm that from the monitoring program at AS 16517 :
[EMAIL PROTECTED] mcast]$ grep 72.234.0.0 bgp.full.Sep_2*2008
bgp.full.Sep_21_00:07:00_EDT_2008:*> 72.234.0.0/15
38.101.161.1163990 0 174 209 36149 ?
bgp.full.Sep_21_06:07:00_EDT_2008:*> 72.234.0.0/15
38.101.161.1163990 0 174 209 36149 ?
bgp.full.Sep_21_12:07:00_EDT_2008:*> 72.234.0.0/15
38.101.161.1163990 0 174 209 36149 ?
bgp.full.Sep_21_18:07:00_EDT_2008:*> 72.234.0.0/15
38.101.161.1163990 0 174 209 36149 ?
bgp.full.Sep_22_00:07:00_EDT_2008:*> 72.234.0.0/15
38.101.161.1163990 0 174 209 36149 ?
bgp.full.Sep_22_06:07:00_EDT_2008:*> 72.234.0.0/15
38.101.161.1163990 0 174 209 36149 ?
bgp.full.Sep_22_12:07:00_EDT_2008:*> 72.234.0.0/15
38.101.161.1163990 0 174 209 36149 ?
bgp.full.Sep_22_18:07:00_EDT_2008:*> 72.234.0.0/15
38.101.161.1163990 0 174 209 36149 ?
bgp.full.Sep_23_00:07:00_EDT_2008:*> 72.234.0.0/15
38.101.161.1163990 0 174 209 36149 ?
bgp.full.Sep_23_06:07:00_EDT_2008:*> 72.234.0.0/15
38.101.161.1163990 0 174 209 36149 ?
You didn't specify the time zone you are in, so I looked at +- 1 day
around it. If the hijack lasted 6 hours, we
should have seen it.
Regards
Marshall
If the above two are correct, would it be correct to say only the
downstream customers of ASN 3267 were affected?
scott
Re: Atrivo/Intercage
> On Sep 22, 2008, at 4:33 PM, Tom Sparks (Applied Operations) wrote: > > Intercage is not a big shop, there are very few people involved in > > running it > > I have no dog in this fight, but I would comment on the "small shop" > issue as it relates to handling abuse complaints. > > I own a small colo/hosting shop too. We don't have many employees. > If we had to deal with so many abuse complaints that things were > "getting lost in the noise", I'd have to seriously examine my AUP and > associated enforcement policies, add staff to handle abuse issues, or > both. Being small isn't an excuse. In fact, a small shop that runs a > clean network should be far better at handling abuse issues than the > larger players could ever hope to be. I would have to agree with this latter bit. We count incidents per YEAR. On a hand. Mostly because we haven't made a habit of accepting random clients, I guess, but were it a problem, it would be made not to be. Being proactive is a big part of this. For example, when ARIN began to allow abuse contacts for IP space, we fairly quickly registered a POC for it. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: InterCage, Inc. (NOT Atrivo)
[EMAIL PROTECTED] wrote: On Mon, 22 Sep 2008 17:00:35 CDT, Justin Shore said: There may not be a law preventing you from asking him for proof of legitimate customers, but there is a law preventing him from answering you. Google for CPNI and "red flag". Hmm... I'm not sure how "Yes, XYZ is a customer of mine" qualifies as a "red flag" question for identity theft. I'm also not sure how "XYZ is a customer" qualifies as CPNI, which (according to the first few pages of Google hits) comprises things like calling/billing records. Nope. Doesn't seem like "xyz is a customer" qualifies there... Hmm... "xyz is a customer" doesn't seem to run afoul of that either. Feel free to enlighten me about what I missed here? Given the unfortunate vagueness of the FCC on their directive, consultants have interpreted CPNI differently and have given their customers (SP and CS organizations) wildly varying instructions. However every interpretation that I've been privy to extends far beyond call records like many people believe CPNI is limited to. Our CPNI consultants instructed us to not even reveal that Company X is a customer (which is laughable given the size of the communities we serve, but I digress). They did however tell us that we can trust all phone numbers listed on an account both for instant information providing and for callbacks. Cox's interpretation is that only the primary number listed on the account is valid for callbacks and that the PIN is required regardless (something our consultants told us was only required if the caller couldn't be reached on a valid callback number). Everybody has different instructions to work with. To answer the question the list is asking, the SP isn't simply stating that Company X is a customer of SP ABC. They are stating that Company X is a customer and that they believe Company X is a valid, not malicious customer in good standing. While that's not a call record that implies certain things about Company X's relationship with the SP. They essentially stating that they haven't received spam or other abuse complaints regarding the customer. They're implying that they are a customer in good standing. That could even be construed to imply that their account is in good standing. That's more than just saying that Company X is a customer of SP ABC. Our consultants advised us against saying anything of the sort. Think of it like HIPAA for SPs. It's splitting hairs but that's the unfortunate situation that CPNI has put all of us in. Instead of a common sense response we get to deal with the knee-jerk response from the FCC thanks chiefly to the Patty Dunn scandal. Justin
comparison of hijack alert systems [was]: prefix hijack by ASN 8997
On Mon, 22 Sep 2008, Scott Weeks wrote: > > I am hoping to confirm a short-duration prefix hijack --- [EMAIL PROTECTED] wrote: From: Hank Nussbacher <[EMAIL PROTECTED]> I too spotted this via PHAS for a large number of prefixes, but have not received alerts from IAR, Watchmy.Net nor does RIPE RIS show this hijack: http://www.ris.ripe.net/perl-risapp/risearch.html I would have expected with so many RRC boxes that RIPE RIS would have caught it. I had thought it was a false positive from PHAS but now that you and others have seen it - I guess it is for real. It'd be very interesting to compare said systems using this event. I have not subscribed to MyASN or watchmy.net yet, so I can't do that. I do note, however, that PHAS took 4 hours and 20 minutes to email me, which is within the specs noted on their site. scott
RE: prefix hijack by ASN 8997
Agree on #2 as well. You can bet they're also reading Nanog right now
to see who and how it was detected. Oh, well, on with the fight.
Chuck
-Original Message-
From: Christian Koch [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 23, 2008 12:58 AM
To: Justin Shore; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: prefix hijack by ASN 8997
At first glance this morning not seeing any data between the gain and
lost alerts from phas and inability to find a route in any of the many
collectors and route servers out there I had thought it was a possibly
a fat finger mistake by 8997 or a false positive.
After locating the data in bgplay/rviews, and noticing how many more
people this occured to I'm leaning towards 2 possible scenarios:
1 - bgp misconfigurations leading to leaks
(Depends on the overall scale of how many other prefixes were
possibly announced)
2 - 8997 began announcing prefixes as an experiment to "test the
waters" for potential real hijacks in future...
'geography' hints towards #2
Or both theories could be way off :)
I'd be interested to know if Renesys collected any data that might
give some better insight to this...
Christian
On 9/23/08, Justin Shore <[EMAIL PROTECTED]> wrote:
> Looking up some of my prefixes in PHAS and BGPPlay, I too see my
> prefixes being advertised by 8997 for a short time. It looks like it
> happened around 1222091563 according to PHAS.
>
> Was this a mistake or something else?
>
> Justin
>
>
> Christian Koch wrote:
>> I received a phas notification about this today as well...
>>
>> I couldn't find any relevant data confirming the announcement of one
>> of my /19 blocks, until a few minutes ago when i checked the route
>> views bgplay (ripe bgplay turns up nothing) and can now see 8997
>> announcing and quickly withdrawing my prefix
>>
>>
>>
>>
>> On Mon, Sep 22, 2008 at 9:06 PM, Scott Weeks <[EMAIL PROTECTED]>
>> wrote:
>>>
>>>
>>> I am hoping to confirm a short-duration prefix hijack of
72.234.0.0/15
>>> (and another of our prefixes) by ASN 8997 ("OJSC North-West Telecom"
in
>>> Russia) in using ASN 3267 (Russian Federal University Network) to
>>> advertise our space to ASN 3277 (Regional University and Scientific
>>> Network (RUSNet) of North-Western and Saint-Petersburg Area of
Russia).
>>>
>>> Is that what I'm seeing when I go to "bgplay.routeviews.org/bgplay",
put
>>> in prefix 72.234.0.0/15 and select the dates:
>>>
>>> 22/9/2008 9:00:00 and 22/9/2008 15:00:00
>>>
>>> If so, am I understanding it correctly if I say ASN 3267 saw a
shorter
>>> path from ASN 8997, so refused the proper announcement from ASN
36149
>>> (me) it normally hears from ASN 174 (Cogent).
>>>
>>> If the above two are correct, would it be correct to say only the
>>> downstream customers of ASN 3267 were affected?
>>>
>>> scott
>>>
>>>
>>
>
--
Sent from my mobile device
Re: prefix hijack by ASN 8997
--- [EMAIL PROTECTED] wrote:
From: Marshall Eubanks <[EMAIL PROTECTED]>
: You didn't specify the time zone you are in,
: so I looked at +- 1 day around it. If the
: hijack lasted 6 hours, we should have seen it.
My apologies, I just used the time zone the tool (bgplay.routeviews.org/bgplay)
was using when I said:
22/9/2008 9:00:00 and 22/9/2008 15:00:00
I'm sure it was in GMT. Seeing the many responses, we now know something
happened and it was only about 15 minutes in duration. bgplay shows the
problem with the above data and I was just wondering if I was understanding the
impact correctly:
> If the above two are correct, would it be
> correct to say only the downstream customers
> of ASN 3267 were affected?
I was not following the rules properly: never attribute to malice that which
can be explained by human error. I thought there might be some
testing-of-the-water in preparation for future 'events' and I guess I was
starting to be trigger happy after all the talk about the new BGP attack.
scott
--- [EMAIL PROTECTED] wrote:
From: Marshall Eubanks <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: <[EMAIL PROTECTED]>
Subject: Re: prefix hijack by ASN 8997
Date: Tue, 23 Sep 2008 07:51:36 -0400
On Sep 22, 2008, at 9:06 PM, Scott Weeks wrote:
>
>
>
> I am hoping to confirm a short-duration prefix hijack of
> 72.234.0.0/15 (and another of our prefixes) by ASN 8997 ("OJSC North-
> West Telecom" in Russia) in using ASN 3267 (Russian Federal
> University Network) to advertise our space to ASN 3277 (Regional
> University and Scientific Network (RUSNet) of North-Western and
> Saint-Petersburg Area of Russia).
>
> Is that what I'm seeing when I go to "bgplay.routeviews.org/bgplay",
> put in prefix 72.234.0.0/15 and select the dates:
>
> 22/9/2008 9:00:00 and 22/9/2008 15:00:00
>
> If so, am I understanding it correctly if I say ASN 3267 saw a
> shorter path from ASN 8997, so refused the proper announcement from
> ASN 36149 (me) it normally hears from ASN 174 (Cogent).
I cannot confirm that from the monitoring program at AS 16517 :
[EMAIL PROTECTED] mcast]$ grep 72.234.0.0 bgp.full.Sep_2*2008
bgp.full.Sep_21_00:07:00_EDT_2008:*> 72.234.0.0/15
38.101.161.1163990 0 174 209 36149 ?
bgp.full.Sep_21_06:07:00_EDT_2008:*> 72.234.0.0/15
38.101.161.1163990 0 174 209 36149 ?
bgp.full.Sep_21_12:07:00_EDT_2008:*> 72.234.0.0/15
38.101.161.1163990 0 174 209 36149 ?
bgp.full.Sep_21_18:07:00_EDT_2008:*> 72.234.0.0/15
38.101.161.1163990 0 174 209 36149 ?
bgp.full.Sep_22_00:07:00_EDT_2008:*> 72.234.0.0/15
38.101.161.1163990 0 174 209 36149 ?
bgp.full.Sep_22_06:07:00_EDT_2008:*> 72.234.0.0/15
38.101.161.1163990 0 174 209 36149 ?
bgp.full.Sep_22_12:07:00_EDT_2008:*> 72.234.0.0/15
38.101.161.1163990 0 174 209 36149 ?
bgp.full.Sep_22_18:07:00_EDT_2008:*> 72.234.0.0/15
38.101.161.1163990 0 174 209 36149 ?
bgp.full.Sep_23_00:07:00_EDT_2008:*> 72.234.0.0/15
38.101.161.1163990 0 174 209 36149 ?
bgp.full.Sep_23_06:07:00_EDT_2008:*> 72.234.0.0/15
38.101.161.1163990 0 174 209 36149 ?
You didn't specify the time zone you are in, so I looked at +- 1 day
around it. If the hijack lasted 6 hours, we
should have seen it.
Regards
Marshall
>
>
> If the above two are correct, would it be correct to say only the
> downstream customers of ASN 3267 were affected?
>
> scott
>
Re: prefix hijack by ASN 8997
On Sep 22, 2008, at 9:06 PM, Scott Weeks wrote:
I am hoping to confirm a short-duration prefix hijack of
72.234.0.0/15 (and another of our prefixes) by ASN 8997 ("OJSC North-
West Telecom" in Russia) in using ASN 3267 (Russian Federal
University Network) to advertise our space to ASN 3277 (Regional
University and Scientific Network (RUSNet) of North-Western and
Saint-Petersburg Area of Russia).
Is that what I'm seeing when I go to "bgplay.routeviews.org/bgplay",
put in prefix 72.234.0.0/15 and select the dates:
22/9/2008 9:00:00 and 22/9/2008 15:00:00
If so, am I understanding it correctly if I say ASN 3267 saw a
shorter path from ASN 8997, so refused the proper announcement from
ASN 36149 (me) it normally hears from ASN 174 (Cogent).
I cannot confirm that from the monitoring program at AS 16517 :
[EMAIL PROTECTED] mcast]$ grep 72.234.0.0 bgp.full.Sep_2*2008
bgp.full.Sep_21_00:07:00_EDT_2008:*> 72.234.0.0/15
38.101.161.1163990 0 174 209 36149 ?
bgp.full.Sep_21_06:07:00_EDT_2008:*> 72.234.0.0/15
38.101.161.1163990 0 174 209 36149 ?
bgp.full.Sep_21_12:07:00_EDT_2008:*> 72.234.0.0/15
38.101.161.1163990 0 174 209 36149 ?
bgp.full.Sep_21_18:07:00_EDT_2008:*> 72.234.0.0/15
38.101.161.1163990 0 174 209 36149 ?
bgp.full.Sep_22_00:07:00_EDT_2008:*> 72.234.0.0/15
38.101.161.1163990 0 174 209 36149 ?
bgp.full.Sep_22_06:07:00_EDT_2008:*> 72.234.0.0/15
38.101.161.1163990 0 174 209 36149 ?
bgp.full.Sep_22_12:07:00_EDT_2008:*> 72.234.0.0/15
38.101.161.1163990 0 174 209 36149 ?
bgp.full.Sep_22_18:07:00_EDT_2008:*> 72.234.0.0/15
38.101.161.1163990 0 174 209 36149 ?
bgp.full.Sep_23_00:07:00_EDT_2008:*> 72.234.0.0/15
38.101.161.1163990 0 174 209 36149 ?
bgp.full.Sep_23_06:07:00_EDT_2008:*> 72.234.0.0/15
38.101.161.1163990 0 174 209 36149 ?
You didn't specify the time zone you are in, so I looked at +- 1 day
around it. If the hijack lasted 6 hours, we
should have seen it.
Regards
Marshall
If the above two are correct, would it be correct to say only the
downstream customers of ASN 3267 were affected?
scott
Re: prefix hijack by ASN 8997
Hi http://www.msk-ix.ru/network/traffic.html it was 12:00 moscow local time. sorry, 13:xx TIME: 09/22/08 09:30:05 TYPE: BGP4MP/MESSAGE/Update FROM: 193.232.244.36 AS2895 TO: 193.232.244.114 AS12654 ORIGIN: IGP ASPATH: 2895 3267 8997 NEXT_HOP: 193.232.244.36 ANNOUNCE GMT+4 Kind regards, ingo flaschberger
Re: prefix hijack by ASN 8997
Hi, http://www.msk-ix.ru/network/traffic.html it was 12:00 moscow local time. Kind regards, ingo flaschberger
Re: prefix hijack by ASN 8997
Hi Hank, .-- My secret spy satellite informs me that at Tue, 23 Sep 2008, Hank Nussbacher wrote: >> Looking at that raw data from both routeviews and Ripe, it looks like they >> (AS8997) 'leaked' a full table, i.e. : >> * 217.208 unique prefixes detected by the RIS server in Moscow (ASpath: 2895 >> 3267 8997) >> * 250495 seen by routeviews (ASpath: 2895 3267 8997). >> (results of quick query: where AS-path contained '3267 8997' update type = >> advertisement). >> >> ASpath: 2895 3267 8997 > > Is that the only ASpath that leaked it? There are others - did they > filter properly and only that path failed to filter? Again: * 217.208 unique prefixes detected by the RIS server in Moscow (ASpath: 2895 3267 8997 & ASpath 2895 5431 3267 8997) * 250495 seen by routeviews (ASpath: 3277 3267 8997). Looks like those are the only ones, but this is just a quick egrep, awk, and sort on the rawdata so I might have missed something (It's getting late here, so no guarantees ;)) Cheers, Andree
