[anti-abuse-wg] how to detect spambots - SPAMTrusted

Jan Pieter Cornet wrote:

Hi,

> On Wed, Mar 04, 2009 at 09:21:32AM +0100, Frank Gadegast wrote:
>> And the following makes me really crazy:
>> - preventing spambotted PCs from sending spam is SOOO easy
>>
> [...]
>> ... SPAMBOTS USING YOUR DIAL-IN IPs DO SEND SPAM TO YOUR OWN MAILSERVERS !!!
> 
> This fails in two ways. First, not all spambots send spam to your own

I must correct you, the system is working perfectly here.
We identified a couple of users using our own dial-in IPs
and fixed them forever after we implemented the SPAMTrusted system.
New customers nearly never a problem, because they get
informed all right directly after they sign.

This had the nice effect that most customers are now aware
of how to protect themselve of beeing abused.
And the system detected a lot of email customers coming
from other dial-in Providers and helped them too.

> servers, as some specifically target eg hotmail.com or hinet.net. Also

Also true, but its a minority.

Th only case where this does not work is, when a dial-in customer
does not provide email services at all.

It works on any others.
An example: the biggest ISP in Germany is T-Online, we are working
closely together with them and have a lot of feedback.
We identify customers that dial-in via T-Online, but authenticate
here, because they have mail- and webservices with us and use
our mailserver to send mail out.
And it happend quite often already, that the spambot also
did send spam out to any of our other mailserver (we have
about 3000 other domains with about 200 different mailservers).
We detect this, and send lists to T-Online and they take
really care, after it was running for 2 years now, we do
only receive very little spam from T-Online IPs ...

> be aware that a lot of spam is specifically targeted not to be detected

One detected spam with a high score is enough.
Dont forget that spammers work together and shared the spambot networks.
Only one detectable spam is enough.
And our SA-setup detects about 98% of all spam correct without any
false positives.
Thats more than enough.

> by standard scanners, so especially when a spamrun just starts, it will
> take at least an hour, even for signature based systems, to see it. (Of

Why that ?
SA scans in realtime any incoming mail.
Any scan takes a maximum of 3 seconds, even on slow servers.
And our alarm script sends us a warning mail just in this moment.
Its as quick as hell ;o)

T-Online only receives a daily report, ok, they cannot block
the user right away, but they can identify him using there
radius-logs automatically and they take appropriate actions.

> course, monitoring abuse@ will eventually let you catch those)
> 
> Second, there are also legitimate reasons people send spammish-looking
> mail to your own mailservers. For example, if someone runs their own

That true (maybe not for us, because we are small, but true for bigger
providers), but thats we you can set the threshold for SA very high.
Its still detecting the right one.
And: if any provider does not like it, to blocked them out
right away, they still can identify the user, check the alarm
manually and decide what to do.

T-Online told us, that they have far less todo, since they automated
the reports.

> mailserver on their DSL line, they point an MX record for some domain to
> themselves, and then forwards mail for that domain to one (or a few) of
> your mailboxes, using none or only minimal spamfiltering. The result is
> spam coming from that node, but all of it is "legit", in the sense that
> it is supposed to flow that way.

That is not a usual setup, but true
if they even forward mail through their on internal mailserver
to the external mailserver of their provider (often used,
when customers do not want to open their mailserver for webmail,
CC there mails to the provider, so that their workers can
use webmail there).

But, scripts can send warnings alarms only or even whitelist some IPs.
Most providers also have different netblocks for customers
with fixed IPs (dont forget, that you need a a fixed IP
and a descend reverse mapping to work a real mailserver,


This changes nothing at the fact, that the system works perfectly
for most spambotted PCs.

And remember: any detected spambot also reduces the problem
for virus, hacked servers (most attacks here are coming from
dial-in IPs) and passwort scanners aso ...

Lets reduce the spambotted PCs in the RIPE region for lets say
only 50% and everybody lives much more peaceful.
And: if RIPE does somthing like that, it is likely that
other registries create something like this too, so we
could start a real world-wide detection.

> Another reason would be a badly configured mail server that backscatters
> on a DSL line, that happens to touch your incoming servers. Not strictly
> spam (yet still unwanted), but it's probably too harsh to completely
> disconnect the customer.

Any ISP can decide what to do exactly.
Important is, that the provider detects a lot of them, and that works.
And it works so good, compare the resources and knowledge that you
need to implement it.
We only had to write one script, configure SA the right way and
the system was running only one day, after I had the idea.

We realized for our customers, that it works.
Their is no backscatter here for dialin customers with an own email 
server, or its whitelisted.

> I'm not saying you shouldn't monitor your own spamscanner for your own
> IPs, just that it isn't as black and white a picture as you make us

Yes, anybody should do this.

So why not creating a recommendation from RIPE ?
Most providers are not aware, that they can easily detect most
of spambotted PCs dialing into their own network.
And that the main problem, they are not aware, do not take
care and nobody is forcing them to deal with the problem.

I thought, its the idea of this group to give recommendations ?

> believe it is. For example, combining this data with abuse reports will
> provide very valuable, and that could even be automated.

YES, YES, YES !

> What we do is simply volume counting, combined with a whitelist of
> known-good massmailers. Also make sure you count bounces and rejected
> addresses, and flag anyone that goes over a few % bad addresses. And

We are expirienced with this, our blacklist http://www.dnsbl.de
works this way.
We even throw a lot of reports away, because we cannot be sure
(automatically) if they are bounces or any other doubtfull spam.
Or it will be too complicated to programm an automatic decision.
But there are still enough reports coming out of the system.

> there will soon be network filters (user customizable, default on) that
> prevent access to other mailservers than our own.

Also a great idea.
I also find it very hard to block port 25 completely and its
great to block them and give the customer an interface
to whitelist some, if they have mailservice with another provider.



Kind regards, Frank
Mit freundlichen Gruessen,
--
PHADE Software - PowerWeb                       http://www.powerweb.de
Inh. Dipl.-Inform. Frank Gadegast             mailto:frank at powerweb.de
Schinkelstrasse 17                                fon: +49 33200 52920
14558 Nuthetal OT Rehbruecke, Germany             fax: +49 33200 52921
======================================================================
Public PGP Key available for frank at powerweb.de