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
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
The latter.
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
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
-jasper
Thanks for that Paul,
It's a pity - the slightly hazy Sunday afternoon brain was hoping, for once, for an easy fix!
MMC
Paul Ferguson wrote:
Not yet, no -- I suspect they have priorities at the moment.
- - ferg
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.
Chris Lewis wrote:
Matthew Moyle-Croft wrote:
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.
Yeah - got it. It's Sunday afternoon here ... I got all hopeful it might be easy.
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.
Actually, it's a pity the compromised machines don't do DNS - then you'd be able to do some interesting things with resolvers and looking for MX lookup abnormalities.
MMC
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:
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
- - ferg
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 NetworkNOT 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.