Kelihos Botnet Comes Back To Life 97
angry tapir writes "A botnet that was crippled by Microsoft and Kaspersky Lab last September is spamming once again and experts have no recourse to stop it. The Kelihos botnet only infected 45,000 or so computers but managed to send out nearly 4 billion spam messages a day, promoting, among other things, pornography, illegal pharmaceuticals and stock scams. But it was temporarily corralled last September after researchers used various technical means to get the 45,000 or so infected computers to communicate with a "sinkhole," or a computer they controlled."
Expected (Score:5, Informative)
Researchers knew that it would only be a matter of time before its controller used the botnet's complex infrastructure of proxy servers and communication nodes to regain control.
The linked story says they fully expected this, and that the method they used (sink-holing) was never expected to be a permanent solution. One has only to hope that stating they have no "recourse" is merely baffle-gab to embolden the controllers. It might also mean "lets make believe we haven't compromised some of the bots and planted a few or our own".
They also suggest that the suspected Russian controller couldn't be extradited, but conveniently neglect to mention that Kaspersky Lab is a Russian company that could influence internal Russian enforcement actions.
Kaspersky Lab Expert Maria Garnaeva Posts in her Blog some of the difference between the new and old control mechanisms: http://www.securelist.com/en/blog/655/Kelihos_Hlux_botnet_returns_with_new_techniques [securelist.com]
She also mentions it is not as bleak as the original article, because:
It is still possible to neutralize the botnet with sinkholing but using slightly different techniques as was used before, and it is still possible to push an update tool on infected machines to neutralize the botnet. In this case the botmasters need to infect machines again to build another botnet.
Re:aren't there some structural ways to curtail th (Score:5, Informative)
Why not require real mail servers to comply with DNS to have an MX record for the domain or IP,
Because there is no rule that says any destination must have an MX record associated with it. RFC 5321 lists how to determine the host a server connects to, and "no MX" is an allowed case.
and to then have SMTP servers for a given network or internet service provider throttle the number of e-mail per unit of time and to limit the number of recipients to human real-world numbers?
What is a "human real-world number"? How do you deal with mailing lists that have hundreds of recipients? One email to the list results in hundreds of emails all at the same time.
That would prevent a non-MX mail server from being able to send mail since other mail servers would reject it based on DNS,
I'm sorry, but I don't think you understand the purpose of an MX record. The MX record isn't for the SENDING server, it is so the sending server can find a defined host to which email FOR a domain is sent. In fact, if an MUA uses SMTP to send mail, then it is highly unlikely that the sending host (the user's computer) will be the address pointed to by the MX record for any domain.
Yes, it would require some more programming in the SMTP daemon, but it shouldn't jack with the protocol.
As long as you don't consider "not being able to send email at all" a problem, no, your idea won't "jack with the protocol".
The more correct means of dealing with the problem is two-fold. SPF (sender permitted|policy framework) is how a recipient server looks up the authorized hosts that might be sending it email from a domain. Greylisting is how a server typically dispatches botnet senders, since the botnet is usually not going to try resending an email after getting a 500-level error.
Re:aren't there some structural ways to curtail th (Score:5, Informative)
Jeez where do I start? You must not be that familiar with email or how it is actually run today.
First off, email is an archaic platform that gets a bunch of glue and duct tape every so often.
Why not require real mail servers to comply with DNS to have an MX record for the domain or IP, and to then have SMTP servers for a given network or internet service provider throttle the number of e-mail per unit of time and to limit the number of recipients to human real-world numbers?
You can already do this with most mail servers. You have two problems here:
1) Requirement.
2) ISP involvement.
You cannot legally compel any person operating a mail server to do anything as part of configuration. The only legal liability I am aware of is sending SPAM itself, and even then the claim that you are merely a victim usually works.
ISPs don't want to be involved on a general basis. On business connections they don't do a damn thing, because businesses would go ape shit. I would. On residential connections some have at some points in time restricted port 25 destination traffic and the TOS usually prevent operating services off the IP address anyways. That being said, it has been awhile since I have actually seen a US based ISP actually block port 25 traffic anymore.
What is done on a day-to-day basis now:
1) Inspection of the IP address communicating with the mail server. Policy based lists, which are contributed to by the ISPs, tell us if it is a residential connection (Dynamic IP address ranges). There are also other lists that allow us to see if that specific IP address is flagged for SPAM. Look at Spamhaus or Cisco's Senderbase products. If the IP address is on a list it the session can be terminated immediately or the SPAM score increased sufficiently.
2) Headers. Who is it being sent to? Who is it being sent from? You have to ignore who the email is claiming to be from in most cases since that is easily forged. Every part of the email address can be forged except the remote IP address. Sent to addresses can be on white list to get it into the Inbox regardless of SPAM heuristics. Part of what you seemed to be alluding to is the EHLO statement. You check the reverse DNS for the remote IP address and see if it matches, or even exists in the first place. You're right that most real mail servers run by professionals, and not on home networks, will have a proper reverse DNS. Shutting down the connection solely based on that is questionable though.
3) URI inspection. Parse out all the links in the email and compare them against lists of known malware host sites. Fairly effective, and I personally don't allow the email to even reach the junk mail folder when one is found. New URIs pop up very fast so this is only effective for older campaigns.
4) Certifications, DKIM, SPF. These are methods outside of the mail server communication that involve 3rd parties, certificates, and DNS records that can validate a mail server as authentic and provide policies on how to treat remote IP addresses.
5) Anti-virus and Anti-malware. Inspection of attachments.
6) Heuristics. Evaluating all of the above plus content inspection to arrive at an overall SPAM score. If it exceeds the threshold throw it in the junk mail folder.
Now that is just off the top of my head for the mail servers I run. You also alluded to gray listing which is temporarily denying an email and asking that it be resent later. This is controversial because a lot of people are waiting for an email ASAP and can't wait 15 minutes. Throttling is also not very useful because on an IP address basis the SPAM load is distributed.
There are already quite a number of tools to reduce SPAM. The biggest problem I face is backlash from executives. Requiring proper reverse DNS left out half the vendors we were communicating with right off the bat. I have had to tone down the security a number of times because the remote part has no clue what they are