[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
|
|