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