Is the spam SMTP meant to be originating from the McColo ranges or is it being used to control other machines elsewhere? If they're originating the SPAM then is it sufficient for a transit provider to provide service but block tcp 25/465 etc and make then pass outbound email to something capable of cleaning it? Or are they doing more than just SMTP? Alternatively it seems a strategic advantage for a large amount of spam to originate from a single location with a small range of IP addresses. We could all just block tcp 25/465 at our borders for their ranges and/or just to our mail clusters. Although the last might leave customer mail servers vunerable, but at least no one could accuse us of filtering them (sore point in Oz at the moment!). MMC -- Matthew Moyle-Croft - Internode/Agile - Networks

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, Nov 15, 2008 at 8:30 PM, Matthew Moyle-Croft <mmc@internode.com.au> wrote:

Is the spam SMTP meant to be originating from the McColo ranges or is it being used to control other machines elsewhere?

The latter. Also a host of other badness, not just spam: http://hostexploit.com/index.php?option=com_content&view=article&id=12&Item id=15 - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFJH6N8q1pz9mNUZTMRAsnXAKClI4BUu8/qAQZ0tebwp0sPhFDWfQCfZV0/ LtUUpvA9GQVHIqs5whc5aQQ= =FG+e -----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/

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, Nov 15, 2008 at 8:46 PM, Jasper Bryant-Greene <jasper@unleash.co.nz> wrote:

Overall spam levels don't seem to have re-attained their previous lofty heights yet:

http://www.spamcop.net/spamgraph.shtml?spamweek http://www.spamcop.net/spamgraph.shtml?spamstats

Not yet, no -- I suspect they have priorities at the moment. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFJH6gsq1pz9mNUZTMRAmDSAKDkozgJWasjUxGoU6znRtFrnP2j8gCgjaWa NCfHK92EsP9DPdnGn0hFozc= =TeXa -----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/

Matthew Moyle-Croft wrote:

Is the spam SMTP meant to be originating from the McColo ranges or is it being used to control other machines elsewhere?

On the spam front, it's mostly command and control connections inbound from infected machines to McColo-based controllers. Hence, unless you can "watch" an infected machine in your own netblock, you don't know that it is being controlled from McColo. A transit provider could port block the inbound traffic, if they knew the ports, but that would presume that the BOTs don't try to get around that. And we do know that some BOTs can get around that. Secondly, from the transit provider's perspective, an outright depeer is probably easier to defend than selective (and probably having to be "secret") firewalling. If they're connected again, at least some of the Botnets don't seem to be back in full operation yet. Ozdok/Mega-D and Rustock doesn't seem to have started recovery (well over 95% down). Srizbi showed some brief renewed activity 12-24 hours ago (perhaps 10% of its former glory), but seemingly nothing since.

Alternatively it seems a strategic advantage for a large amount of spam to originate from a single location with a small range of IP addresses. We could all just block tcp 25/465 at our borders for their ranges and/or just to our mail clusters. Although the last might leave customer mail servers vunerable, but at least no one could accuse us of filtering them (sore point in Oz at the moment!).

The difficulty is that local blocking is only useful to block C&C communications from infected machine in _your_ netblock. It doesn't at all stop inbound port 25 connections from infected machines elsewhere. In some limited cases, you might see a benefit to blocking DNS queries from their netblocks. Some "spam-by-compromised-machine" mechanisms have the C&C doing the MX lookups for the victims. Mostly because the "compromised machine" is merely a proxy, and _can't_ do the MXes. I doubt these BOTnet C&Cs do. More efficient to have the BOTs themselves doing it.

If we all dropped routes from 26780 at the edge, I wonder how long it would be before their prefixes popped up somewhere else. Justin Paul Ferguson wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Sat, Nov 15, 2008 at 7:22 PM, Paul Ferguson <fergdawgster@gmail.com> wrote:

...

If they are, then I sure wish that someone would explain reconnecting McColo:

http://www.cidr-report.org/cgi-bin/as-report?as=as26780

With all of the evidence of criminal activity there, I would like to assume that this is just a case of ignorance.

- - ferg

Apparently, the badness is still located in the same SJ Data Center:

%traceroute 208.66.194.22

Tracing route to 208.66.194.22 over a maximum of 30 hops

1 2 ms 5 ms 1 ms 208.66.194.22

[snip]

6 14 ms 14 ms 13 ms xe-11-1-0.edge1.sanjose1.level3.net [4.79.43.133 ] 7 14 ms 16 ms 16 ms vlan69.csw1.sanjose1.level3.net [4.68.18.62] 8 21 ms 36 ms 37 ms ae-63-63.ebr3.sanjose1.level3.net [4.69.134.225]

9 24 ms 21 ms 33 ms ae-2.ebr3.losangeles1.level3.net [4.69.132.10] 10 36 ms 21 ms 31 ms ae-73-73.csw2.losangeles1.level3.net [4.69.137.3 8] 11 * 22 ms 27 ms ae-23-79.car3.losangeles1.level3.net [4.68.20.69 ] 12 27 ms 26 ms 41 ms telia-level3-ge.losangeles1.level3.net [4.68.110 .222] 13 35 ms 39 ms 35 ms sjo-bb1-link.telia.net [213.248.80.18] 14 35 ms 36 ms 36 ms giglinx-ic-122068-sjo-bb1.c.telia.net [213.248.8 4.210] 15 35 ms 35 ms 35 ms vl-701.rt02.sjc.mccolo.com [208.66.192.26] 16 * * * Request timed out. 17 * ^C

FYI,

- - ferg

-----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017)

wj8DBQFJH501q1pz9mNUZTMRAm/xAKCV0zAnL3hQkgrT+i/UANCXGziz5gCfYJLd MXnaUIk8IXy1VBjXD+UDrXw= =+RoU -----END PGP SIGNATURE-----

Paul Ferguson schrieb:

Thanks to some good folks in Telia, McColo has been de-peered (again):

26780 MCCOLO - McColo Corporation

Adjacency: 1 Upstream: 1 Downstream: 0 Upstream Adjacent AS list AS1299 TELIANET TeliaNet Global Network

NOT Announced

This AS is not currently used to announce prefixes in the global routing table, nor is it used as a visible transit AS.

Prefixes added and withdrawn by this origin AS in the past 7 days.

- 208.66.192.0/22 Withdrawn - 208.72.168.0/21 Withdrawn - 208.72.173.0/24 Withdrawn

I was wondering why I still saw routes from McColo AS26780, and I noticed that we picked up the routes via the Any2 LAX routeserver. They still seem to be connected to Any2 LAX, even though they are no longer listed. I applied now filters and set the community 19996:26780 to avoid the annoucement of our routes towards them. Maybe someone at CRG West could pull their plug, too. -- Fredy Künzler Init Seven AG, AS13030