peter h wrote:

On Tuesday 03 March 2009 19.48, Dr. Alexander K. Seewald wrote:

...

We've built and run a prototype passive botnet tracking system in Austria for the last year. A journal paper is pending and should be ...

slot there - half an hour should suffice.

...

Best, Alex

Technical analysis is at best a forensic tool, possibly useful when a spammer has been stand to trial

What we need is legislation and spamhunting, where spamming is made illegal, no excuses allowed, badly managed computers that is taken over by spammers should be a crime, and where efforts of the law community is switched from the which-hunting of perr-to-peer networks to hunting spam and the assosiated criminality. ISP that does not prevvent spam and that does not act upon abuse-reports should be made accountable.

Sorry, bot-analysing is interesting, but it does not (much) prevent the disease.

Oh, you are so right ... And the following makes me really crazy: - preventing spambotted PCs from sending spam is SOOO easy Im talking about the following now for years and nearly nobody is listening to me, but the concept is working here with us perfectly. We identify any of our dial-in customers in minutes easily using only well-known open-source tools and block them out. I outline it again: - guess you are a dial-in provider - guess you provide mailservices for your customers - guess you already have a an antispam solution for your customers And now think about the following: - is it likely, that a spambotted PC, that dials in via one of your dial-in IPs, sends spam to the email address of this particular customer, his family and friends and colleges or simply any other customer of yours ? YES, its not only "likely", its prooven, spambots scan outlook address books, and if the provider is only big enough (it works here for only 10000 mailboxes) ... ... SPAMBOTS USING YOUR DIAL-IN IPs DO SEND SPAM TO YOUR OWN MAILSERVERS !!! And thats the point: - we are using spamassassin to identify spam for our email customers, sa has a plugins for putting the IP of the real sender or the AS-number into the header and surely the logfile - sa can also use a feature called ALL_TRUSTED, it was introduced to give mail some plus points, if they originate from identified customers, that already provided some login information (POPAuth, SMTP-Authentication aso) - so, if there is an email coming in, that - has a high spam score (currently is enough to set this to 20, what is huge for sa) and - the spam originated from our own dial-in-AS or -IP ... then we know immediately, that one of our customer either is sending spam on effort, is spambotted or has whatever problem. It even detects spambotted PCs, that are dialing in via a different provider, but are OUR mailcustomers (through ALL_TRUSTED) and identified here to send mail and use our mailservers. And do you now, what we do then ? the script that watches the sa logfile and alarmed, simply tells our radius server to disconnect the customer with the detected IP and changes the password ! Brutal ? no, its wise ... And what happens then ? the customer phones up usally 5 minutes later, we can explain and check the situation, he is cleaning his computer and there is one spambotted PC less in the world. This is so easy to implement and works perfectly, we only had a few cases so far, because we have mostly business customers with good infrastructure, we never had a false alarm, it stops crazy spam outbreaks and the best is: - this method is much easier then scanning outgoing email from your customers, what you only can achieve by transparently scanning port 25 or by blocking the port and having all the mail coming through a outgoing mailserver (I guess, thats what AOL is doing) and I think, thats a bit hard for your customers and very cost-intensiv) - furthermore, it will be really hard for the spambots to get arround this, because they would need to know wich email address belongs to what provider, surely they could check the MX records of every domain, check if there are similarities with the dialin IP to prevent sending to the same provider, but I guess this will be really hard for them ... And this will remove any spambotted PC forever. So, why not forcing any RIPE-member to detect spam on their own incoming mailservers coming from their own dial-in IPs ? RIPE could simply say: implement this, or you are not getting any more IPs, or we cancel your contract right away :o) RIPE should force TurkTelecom (ttnet.tr) to implement this as a reference and test implementation, this is one country represented by one ISP and they currently cause 8% of the spam we receive here. Better would be: TurkTelecom should volunteer for this and create a reference documentation and implementation based on open-source so any provider could easily adopt from there ... Anybody from TurkTelecom on the list ? Come one, you owe us a lot ... BTW: we call this method "SPAMTrusted" and there are more details about the implementation online in German under http://dnsbl.de/antispam.shtml Kind regards, Frank

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

Hi guys, Sorry, but I don't understand what kind of discussion is going on. What do I have to do with it and why am I getting all these mails? Please exclude me from the mailing list! Thanks! Best regards, Helmut _______________________________________ -------Originalmeddelande------- Från: Florian Weimer Datum: 2009-03-04 12:11:06 Till: frank@powerweb.de Cc: anti-abuse-wg@ripe.net Ämne: Re: [anti-abuse-wg] how to detect spambots - SPAMTrusted * Frank Gadegast:

And the following makes me really crazy: - preventing spambotted PCs from sending spam is SOOO easy

The detection problem has been solved years ago, agreed. There are multiple, working solutions.

YES, its not only "likely", its prooven, spambots scan outlook address books, and if the provider is only big enough (it works here for only 10000 mailboxes) ... ... SPAMBOTS USING YOUR DIAL-IN IPs DO SEND SPAM TO YOUR OWN MAILSERVERS !!!

And even if that doesn't happen for you due to some strange scenario, there are tons of free, external data feeds to which you can subscribe which provide you with high-quality data about compromised customer PCs.

the customer phones up usally 5 minutes later, we can explain and check the situation, he is cleaning his computer and there is one spambotted PC less in the world.

Cleaning up the PC costs between 100 and 200 EUR. Someone needs to absorb those costs. Detection is solved, but response is still an open problem. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99

--On 4 March 2009 16:11:34 +0100 Florian Weimer <fweimer@bfk.de> wrote:

* Helmut:

...

Sorry, but I don't understand what kind of discussion is going on. What do I have to do with it and why am I getting all these mails? Please exclude me from the mailing list!

Does anybody know how to view mail headers using IncrediMail?

Helmut, you could try sending an unsubscribe message to <anti-abuse-wg-request@ripe.net> (just put "unsubscribe" in the subject line). But this won't work if you're subscribed with an address different from the one you're currently using.

Given that there are few, if any, email clients that display List-* headers by default, why would administrators of an anti-abuse list think use of those headers alone is in any way helpful to someone in Helmut's situation. Can't we have just a little list footer with an unsubscribe link in it? -- Ian Eiloart IT Services, University of Sussex x3148

On Wednesday 04 March 2009 11.56, Florian Weimer wrote:

* Frank Gadegast:

...

And the following makes me really crazy: - preventing spambotted PCs from sending spam is SOOO easy

The detection problem has been solved years ago, agreed. There are multiple, working solutions.

...

YES, its not only "likely", its prooven, spambots scan outlook address books, and if the provider is only big enough (it works here for only 10000 mailboxes) ... ... SPAMBOTS USING YOUR DIAL-IN IPs DO SEND SPAM TO YOUR OWN MAILSERVERS !!!

And even if that doesn't happen for you due to some strange scenario, there are tons of free, external data feeds to which you can subscribe which provide you with high-quality data about compromised customer PCs.

...

the customer phones up usally 5 minutes later, we can explain and check the situation, he is cleaning his computer and there is one spambotted PC less in the world.

Cleaning up the PC costs between 100 and 200 EUR. Someone needs to absorb those costs. The "owner" has to absorb this cost. That's the price they pay to get infected in the first place. Tha main thing is to isolate it from Internet and prevent further damage.

Detection is solved, but response is still an open problem. Why ? The connection will go blank. Any person at the other end has to do some fault-finding and will end up with the solution. Any spambot will not. Problem solved.

-- Peter Håkanson There's never money to do it right, but always money to do it again ... and again ... and again ... and again. ( Det är billigare att göra rätt. Det är dyrt att laga fel. )

This simple wheel reinvented many times; need only to apply current knowledge. If someone will work with me we can submit the described RFC as is or improved as needed <http://www.camblab.com/misc/univ_std.txt> based on <http://www.camblab.com/nugget/spam_03.pdf> Jeffrey Race

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@powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== Public PGP Key available for frank@powerweb.de

On Wed, Mar 04, 2009 at 10:20:06AM +0100, Florian Weimer wrote:

* Alexander K. Seewald:

...

The gist: Based on a darknet (i.e. unused IP addresses), we analyze incoming packets and classify them into (currently eight) different spambot types based on learned idiosyncrasies of packet and protocol, and reference data (currently by Marshall).

Why do you expect bots to touch dark address space?

Or put differently, I think any approach based on darkspace monitoring signficantly restricts the types of bots you can detect.

Not if you use "dark" corners of your own PA space, eg unused /28s in your DSL space, or hosting space. -- Jan-Pieter Cornet <johnpc@xs4all.nl> !! Disclamer: The addressee of this email is not the intended recipient. !! !! This is only a test of the echelon and data retention systems. Please !! !! archive this message indefinitely to allow verification of the logs. !!

There seems to be an underlying assumption that all bots gather information through scanning (possibly neighboring) addresses, but this is simply not true. No, we have collected about twelve months traffic from four /26 subnets and were able to recognize about half of the spambots from single packet data alone using a machine learnin system trained on

On Wed, Mar 04, 2009 at 11:12:35AM +0100, Florian Weimer wrote: packet features (excluding obvious correlations such as TCP source port). We suspect this is due to non-random ICMP payloads, TCP option ordering and UDP payloads. There is no compelling reason for this data to be there, we were as surprised as you seem to be. Best, Alex -- Dr. Alexander K. Seewald Seewald Solutions www.seewald.at Tel. +43(664)1106886 Fax. +43(1)2533033/2764