- NANOG - lists.nanog.org

RE: [funsec] McColo: Major Source of Online Scams andSpams KnockedOffline (fwd)
by Skywing 13 Nov '08

13 Nov '08

I don't think you want to do that. It has been done in Germany, and there's been, for example, a chilling effect on legitimate security research that just makes *everyone* worse off. Precisely in that case because, as you noted, dual use tools exist - and as you made note as an unpleasant possibility in your message, they got caught up in the middle of this sort of legislation. Trying to regulate distribution of something on the Internet is both futile and dangerous, in general, IMO. It is certainly not going to make a dent on what malicious people do (they're probably breaking the law already or out of jurisdiction anyway). The only real side effect of such action that I can see is much pain and angst by legitimate people trying to do their job and wondering if they are going to risk having their lives ruined by running afoul of ill-conceived legislature trying to ban distribution of "tools". This is not the correct path, I think. Whatever the correct path is is likely to be a much more complex target, but many attempts at legislating the Internet often come out as so broad that you could find a way to use them against any ordinary sysadmin. I thik that given past attempts, it is unlikly that there will be legislature that is both effective at criminalizing McColo and avoids the sort of environment where basic general Internet use is risky from a legal perspective. (And we're perhaps a tad too close to that now. One does not wish to consider what'd happen if one got link-bombed with a shady site hosting "illegal" content that showers you in a badness pop-up deluge, and then got pulled over for a full computer search by the border patrol. Does trying to explain the concept of that situation before a jury as a defense for having a porn pic sitting around in your browser cache sound appealing?) Now, I'm not trying to say that the correct laws cannot be made. But you had better be damn sure they're the right laws before they get passed. Many of the issues here are subtle and significant, ones that traditionally Internet-facing laws hve glossed over to th public detriment. Explaining such things to legislators is hard enough; you don't want to be stuck trying to fend off wrong charges from an overzealous prosecutor on subtle and highly technical grounds if you find yourself. Because the danger from making the *wrong* laws is so great here, we really need to be very careful what we're calling for. - S -----Original Message----- From: John Bambenek <bambenek(a)gmail.com> Sent: Thursday, November 13, 2008 06:31 To: Charles Wyble <charles(a)thewybles.com> Cc: NANOG list <nanog(a)nanog.org> Subject: Re: [funsec] McColo: Major Source of Online Scams andSpams KnockedOffline (fwd) Something to keep in mind. I don't believe it was McColo that was the end provider of "badware" per se (and I could be proven wrong), they simply played the enabling role by hosting it and looked the other way. Now don't get me wrong, they ought to be kicked offline for externalizing their costs on the rest of us, but what criminal charges could be filed here? I'm not a lawyer but the person actually committing the crime and a person who willing provides tools to someone committing a crime are in completely different boats. We could criminalize hosting malicious tools, but then what of nessus, nmap, wireshark and the host of security tools that are effectively "dual use"? Child porn being an obvious exception of course, but the point remains. Negligence is bad and perhaps there are criminal remedies that can be brought to bear (I'm not a lawyer, I don't play one on the intarwebs) but I would imagine they would be minor in comparison. That said, of course this information should be turned over to law enforcement. It often is. j Charles Wyble wrote: > >> On to the question about how network operators can help LE: *Collect >> the data that proves a company such as Intercage/McColo is harboring >> cybercriminals* and get with your local FBI/Secret Service field >> office (or your state's Attorney General's office) (or both) and >> submit a complaint at IC3's website (www.ic3.gov) because we have an >> excellent team of analysts that track information like that. Package >> up the evidence you have and send it out. > > > Excellent point. Something like the fine folks at > http://hostexploit.com/ are doing. > > I also believe SANS has some excellent courses on forensics, and > things like chain of custody etc. Not sure how much that applies to > these sort of scenarios but it can't hurt to package/handle the > evidence in as compliant a manner as possible. > > >

1 0

Verizon/UU.net/Alternet Routing issue
by Peter Beckman 13 Nov '08

13 Nov '08

At about 4:24pm EDT, I lost connectivity from Verizon to destinations in New York, Seattle and others. Came back up (4:46pm) while composing this email. Anyone else notice? Major problem or minor routing issue? Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. localrouter 67.6% 395 0.6 1.6 0.5 18.8 2.3 2. 10.1.41.15 0.0% 395 5.7 5.1 1.8 306.0 17.4 3. P4-2.LCR-02.WASHDC.verizon-g 0.0% 395 7.4 2.7 1.2 19.0 2.5 4. 130.81.29.218 0.0% 395 6.0 3.8 1.8 40.9 4.2 5. 152.63.39.177 0.0% 395 8.6 6.8 3.9 71.3 4.4 152.63.36.213 6. 152.63.69.113 71.6% 395 120.7 44.0 31.2 186.7 30.3 7. POS7-0-0.GW4.IND6.ALTER.NET 30.7% 395 1179. 133.3 121.3 1179. 79.5 8. 152.63.67.250 93.9% 395 121.5 125.4 121.0 186.2 13.0 9. POS6-0-0.GW4.IND6.ALTER.NET 53.0% 395 318.9 217.7 206.8 722.0 43.3 10. 152.63.67.250 96.2% 395 211.1 211.1 209.0 215.7 1.8 11. POS6-0-0.GW4.IND6.ALTER.NET 67.0% 395 422.1 305.9 294.9 692.1 37.5 12. 152.63.67.250 97.5% 394 295.1 298.0 295.1 303.6 2.5 13. POS6-0-0.GW4.IND6.ALTER.NET 73.5% 394 523.9 391.5 382.1 523.9 17.7 14. 152.63.67.250 98.7% 392 388.5 386.6 381.9 389.5 3.1 15. POS6-0-0.GW4.IND6.ALTER.NET 82.6% 392 632.9 481.2 468.6 632.9 22.2 16. 152.63.67.250 99.2% 388 472.7 472.2 470.2 473.6 1.8 17. POS6-0-0.GW4.IND6.ALTER.NET 85.8% 388 737.0 573.3 559.4 737.0 27.8 18. 152.63.67.250 99.2% 387 560.5 562.0 560.5 565.1 2.7 19. POS6-0-0.GW4.IND6.ALTER.NET 89.6% 387 839.0 664.8 644.9 839.0 38.6 20. 152.63.67.250 99.2% 387 649.3 649.6 649.3 649.9 0.3 21. POS6-0-0.GW4.IND6.ALTER.NET 94.8% 383 946.4 763.8 734.6 946.4 48.5 22. 152.63.67.250 99.7% 376 735.5 735.5 735.5 735.5 0.0 23. POS6-0-0.GW4.IND6.ALTER.NET 92.5% 376 895.4 842.2 819.1 909.0 26.8 24. ??? 25. POS6-0-0.GW4.IND6.ALTER.NET 96.7% 365 1153. 955.9 908.9 1153. 78.7 26. ??? 27. POS6-0-0.GW4.IND6.ALTER.NET 96.6% 328 1261. 1057. 998.8 1261. 86.8 28. 152.63.67.250 99.6% 245 999.3 999.3 999.3 999.3 0.0 29. POS6-0-0.GW4.IND6.ALTER.NET 98.8% 245 1189. 1123. 1086. 1189. 57.5 30. ??? Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman(a)angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------

9 9

RE: Verizon/UU.net/Alternet Routing issue
by David Hubbard 13 Nov '08

13 Nov '08

From: Eric Tykwinski [mailto:eric-list@truenet.com] > > Anyone else still seeing routing issues from Verizon's network still? > We are getting intermittent routing to/from our IP space. > > Sincerely, > > Eric Tykwinski We're in Tampa and seeing issues with customers of ours in the northeast on Verizon; they can't get to us at all, traces from them make it about three hops and die. We have connectivity to uunet and Level 3 in addition to some others. I took down the uunet to see if that was it with no change, haven't taken down any of the others yet. David

1 0

mail traffic
by Revolver Onslaught 13 Nov '08

13 Nov '08

Hi everybody, I'm working for an ISP who manages several countries. On 11/13, we noticed that our incoming traffic was divided by 2 (SMTP hits). All the countries we manage were affected by. Did you enconuter the same problem ? Regards, RO

4 3

110/8 and 111/8 allocated to APNIC
by Leo Vegoda 13 Nov '08

13 Nov '08

Hi, The IANA IPv4 registry has been updated to reflect the allocation of two /8 IPv4 blocks to APNIC in November 2008: 110/8 and 111/8. You can find the IANA IPv4 registry at: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt Please update your filters as appropriate. Regards, Leo Vegoda Number Resources Manager, IANA

1 0

On the subject of multihoming
by Charles Wyble 12 Nov '08

12 Nov '08

I'm working on a small experiment which utilizes multiple outbound links (in the experiments case multiple consumer 3G connections [to 2 Sprint/2 Verizon/1 AT&T], Time Warner Cable Modem and an SBC Global DSL connection. What is the best way to do outbound traffic engineering? I would like to be able to determine the best path possible and send traffic out the appropriate link. Could this be done with a copy of the BGP tables? Obviously as they are consumer connections, I wouldn't get a BGP feed so would need to download a copy, which has the risk of stale data. Perhaps some sort of multihop BGP setup? I have done some research and found a lot of references to small site multihoming without BGP for link redundancy but not for traffic engineering. Thanks. Charles

7 8

Re: Potential Prefix Hijack
by Mohit Lad 12 Nov '08

12 Nov '08

The local scope of the event is also the reason that PHAS did not catch the hijack. Nevertheless, its good to have different services for hijack detection running independently, especially if they are getting different feeds. Even a hijack that is local in scope is worth alerting about; if not anything, at least to ensure it stays local :) -Mohit On Nov 12, 2008, at 4:52 AM, Eduardo Ascenço Reis wrote: Dear Fellows, I would like to add some information to this thread from AS27664 perspective. Both AS27664 (CTBC Multimídia) and AS22548 (Nic.br) share two common points: 1. They are IP transit customers from AS16735 (CTBC Telecom). 2. They feed with full BGP routing table the RIS/RIPE project located at PTTMetro-SP, Brazil (rrc15). I checked all BGP updates of 2008111[01] from Route Views Archive Project [1] and looked for prefixes originated by AS16735. I compared those with the prefixes officially allocated by Registro.br to AS16735 [2] and did not find any case o prefixes from different AS. This analyses confirms that yesterday AS16735 issue of IP prefixes Hijacking was not globally propagated. It seems that only some AS16735's Internet customers (like AS27664 and AS22548) were affect by this problem. Regards, -- Eduardo Ascenço Reis [1] http://archive.routeviews.org/ [2] https://registro.br/cgi-bin/whois/

1 0

Potential Prefix Hijack
by Mark Tinka 12 Nov '08

12 Nov '08

Hi all. Anyone know how we can contact AS16735 and their upstream AS27664. We think they are hijacking a number of our prefixes (AS24218- and AS17992-originated). Thanks BGPmon: e.g., ==================== Possible Prefix Hijack (Code: 11) 1 number of peer(s) detected this updates for your prefix 61.11.208.0/20: Update details: 2008-11-11 02:24 (UTC) 61.11.208.0/20 Announced by: AS16735 (Companhia de Telecomunicacoes do Brasil Central) Transit AS: 27664 (CTBC Multim�dia) ASpath: 27664 16735 ===================== RIPE's RIS BGPlay confirms the same, for about the last hour. E-mails to them won't get there (of course), so our NOC are contacting them via Gmail/Yahoo. All help appreciated. Cheers, Mark.

14 14

Cable re-management
by Tuc at T-B-O-H.NET 12 Nov '08

12 Nov '08

Hi, I wondered if any of the NANO's (Specifically NYCNANO's) have ever brought in another company, or offered as a service to the general world cable re-management. I know Hugh O'Kane is a big place that does it, but I'm looking for said services in NYC. I have client datatel closets that REALLY need color coding, cables cut to length, A-B labeling, etc. For an added bonus, they would potentially be able to build out an entire FLOOR of a building from scratch. Private replies please, will summarize to any who ask. Thanks, Tuc/TBOH

1 0

Re: Potential Prefix Hijack
by Nuno Vieira - nfsi telecom 11 Nov '08

11 Nov '08

Howdy, We were hijacked aswell, by 27664 16735 Our affected prefixes were: 94.46.0.0/16 194.88.142.0/23 194.11.23.0/24 82.102.0.0/18 195.246.238.0/23 194.107.127.0/24 81.92.192.0/19 193.227.238.0/23 We are trying to contact them in order to get some feedback, and some good explanation for this. In the meanwhile, there are lots of evidence spread around (thanks to RIS RIPE, Routeviews, BGPmon and others) http://www.ris.ripe.net/dashboard/27664 http://www.ris.ripe.net/dashboard/16735 In the meanwhile we are sending notices to the Upstreams of those ASN's, in order for them to apply proper filtering to their downstream customers to avoid situations like this. On the List i was able to found: AS8167 - TELESC AS6762 - SEABONE AS12956 - TELEFONICA AS3549 - GLOBAL CROSSING AS17379 - Interlig I welcome others to do the same, in order to avoid replicas for this situation. Regards, --- Nuno Vieira nfsi telecom, lda. nuno.vieira(a)nfsi.pt Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ ----- "Network Fortius" <netfortius(a)gmail.com> wrote: > Same problems here, for AS26028 > Stefan > > On Mon, Nov 10, 2008 at 8:54 PM, Mark Tinka > <mtinka(a)globaltransit.net>wrote: > > > Hi all. > > > > Anyone know how we can contact AS16735 and their upstream > > AS27664. We think they are hijacking a number of our > > prefixes (AS24218- and AS17992-originated). Thanks BGPmon: > > > > e.g., > > > > ==================== > > Possible Prefix Hijack (Code: 11) > > 1 number of peer(s) detected this updates for your prefix > > 61.11.208.0/20: > > Update details: 2008-11-11 02:24 (UTC) > > 61.11.208.0/20 > > Announced by: AS16735 (Companhia de Telecomunicacoes do > > Brasil Central) > > Transit AS: 27664 (CTBC Multimídia) > > ASpath: 27664 16735 > > ===================== > > > > RIPE's RIS BGPlay confirms the same, for about the last > > hour. > > > > E-mails to them won't get there (of course), so our NOC are > > contacting them via Gmail/Yahoo. > > > > All help appreciated. > > > > Cheers, > > > > Mark. > >

4 6