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.