ietf-asrg
[Top] [All Lists]

[Asrg] Spam is a security problem

2003-03-15 05:23:41
Most spam, that is. There's the small amount of direct spam and the huge amount of abuse spam.

That spam is a security problem has been long recognized: the efforts years ago to get all open relays secured were security-based anti-spam measures. They didn't work, spammers still seek and find open relays. Now they also do the same with open proxies.

May I suggest that the problem in this approach is the single-minded way in which a solution is attempted? That single-minded way is to secure systems. That works for those systems but it does not solve the overall problem: spammers can so easily find open relays that having almost every system secure does not effectively impact spam or spammers.

If simply securing doesn't work there seem to me to be at least two options: give up on trying to combat this kind of abuse or take measures to end this kind of abuse.

Effectively, the decision has been to give up. That's the wrong decision, of course. It is necessary to take measures to end this kind of abuse.

Let's start with a basic fact: it is incredibly easy to detect the abuse spammers commit when they seek open relays. Most operators of email systems can look in their logs and see entries that show a relay attempt was rejected. Spammers do relay tests every day, the tests that hit secured mail servers get logged.

You should realize that spammers do not just test mail servers. If you think about it the concept of "just test mail servers" is bogus - how could someone identify only the mail servers? Instead, spammers test IPs or ranges of IPs. Those with secure mail servers may have unassigned IP numbers and a spare, older system available. That is all you need to detect relay test messages.

Here's a recent relay test message:


Received: from 213.5.34.135 by X.X.X; Sat, 15 Mar 03 00:46 CST
Message-Id: <sorry-munged(_at_)outlaw(_dot_)com>
Date: Sat, 15 Mar 2003 08:55:05 -1000
From: gimohh(_at_)aol(_dot_)com
Subject: Hopefully this works...
To: <Undisclosed Recipients>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

05004905104605304605105204604905105305811211211205105204504905105304510311904805
20460971161041011101150460970990991011151150460970991100461031140580490550540500

With the undisclosed recipients:

admin(_at_)sincasino(_dot_)com
admin(_at_)videospoker(_dot_)com

I know automatically that this is the work of a spammer. Looking at the registrations sincasino.com and videospoker.com quickly conform that likelihood.

The question is: how do I use this information to end the spam-sending abuse?

As a single user/operator I'm somewhat constrained. I can track down the spammer's location and try to get the account terminated. For some tests I can try to get the target ISP (for instance, yahoo.com.UK for another recent test) to act in some way to thwart the spammer. I'd prefer those ISPs to simply divert messages addressed to spammer dropboxes to a non-working address but I think most simply terminate the account. This causes the spammer only the difficulty of setting up another dropbox address - hardly likely to stop anything. Recently I trapped tests from a Cox IP and to a Cox email address. Cox was smart enough to realize what I told them and terminated the account, then terminated the next account I reported.

Even this slow, one-at-a-time effort has results.

Another option is to go further - to deliver the relay test and screw the spammer a different way. Back in mid-February I delivered a test to jela(_at_)borovo(_dot_)net(_dot_) After that I received a mini-deluge of relay spam, about 200 99-recipient messages/day, ending yesterday. None of that spam got delivered. This morning there's a fresh test from jela(_at_)borovo(_dot_)net in the queue - I have no plans to deliver that one (and already its a little late to do so: I'd think spammers would be suspicious of late arrivals. I realize I'm giving the average spammer too much credit, and this guy must be below average: he puts "meet Russian women" subjects on his MMF spam.)

Others do this same thing. An operator elsewhere in the world, using his massive 120 MHz Pentium with 64 Mb, stopped spam to 281 million recipients in his first year of operation. All he does is deliver relay tests and stop spam (which he does archive to CDR.) He makes no complaints to ISPs or anyone. In Germany there's a site with somewhat more power and bandwidth available - they've stopped spam to well over 220 million recipients so far this year.

At home I do this same thing on my Windows system. Note this well. Windows typically does not run an MTA, port 25 is not in use. It is possible to run a program designed to interfere with the spammers and that program is available: http://jackpot.uk.net/

After years of effort to secure all open relays there are still enough open relays that spammers actively seek them. securing them all isn't a viable option, didn't work, can't work. I favor a different approach that does work and can work: dilute the pool of true open relays with so many false ones that the spammers can't find the true ones. That's absolutely simple. While this is being ramped up the operators of fake relays who know how can take the information they glean from their false relays and use it to persuade ISPs to take action against the spammers.

There are operational considerations I haven't discussed. Many critics assert that all the spammers need do is include a dedicated test address every so often in the addresses they spam and use non-delivery to that address as evidence of a false open relay. Sure, they can. Right now they don't - there's so few false open relays that many spammers don't recognize the possibility. With Jackpot it has to be trivially easy for a spammer to identify a probable Jackpot-IP and treat it just like a secure IP.

The basic idea is sound, and some very effective fake open relays are simply standard MTAs, reconfigured. Those aren't going to be easily identified. More to the point is that this entire means of combatting spammers and this entire opportunity to do so are both almost completely ignored. The idea has further extension. An ISP with a customer who is sending out large numbers of relay tests should be easily able to identify that customer strictly by the pattern of his outgoing traffic. A large ISP cannot monitor the entire stream of its packets but surely it can monitor substreams. It could monitor all the traffic form each /24, for instance. this isn't full-time monitoring, just sampling. You don't catch every spammer who does relay tests that way but you catch many, and that's the point.

Similarly, an ISP that is the target for such tests can identify the source of such tests by monitoring incoming traffic. Once the source IP is known a complaint can be sent to the ISP of the source, for action. Telesp.br could do this to good effect, as an example.

Everything I've written concerns open relays. Exactly the same approach can be taken against open proxy abuse (which is really where telesp.br needs to concentrate effort.)

Currently the practice is to wait until the spam hits the destination ISP (or the recipient) before action. All the difficulty with filters stems from this delay. If spam is attacked at the relay/proxy level no filter is needed: the spammer does the filtering for you: he sends only spam by the abuse pathways.

What I advocate isn't hard. For several years I ran a combined server/fake open relay. At the relay level it is not hard to separate spam from valid email - the spam is relay mail that doesn't originate at a valid source for you to relay.) It's far simpler to run a fake open relay (or fake open proxy) with no legitimate email function. You know that it has no email function, the spammer doesn't. To him it can look exactly like a system run by a clueless operator who doesn't know enough to secure his relay. That is exactly how you want it to look, of course. The better you fake the clueless operator the better you make the fake indistinguishable from the true open relay.

I won't give a long description but this fake open relay, run by Michael Tokarev in Moscow, successfully deceived one of the most blatant of the spammers, Alan Ralsky:

http://www.corpit.ru/cgi-bin/h0n5yp0t

The fake relay is now stopped (as you can tell from the dates), only the web page remains. In operation this was quite easy to use: send the URL to the ISP implicated by the IPs that were spam sources. The ISP could use this information to terminate the spammers throwaway account and then do a refresh. When the spammers next throwaway IP appeared, terminate that. Ralsky got thrown off 3 ISPs in one weekend that way. That was a 100 MHz 486 DX4.

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg



<Prev in Thread] Current Thread [Next in Thread>