Welcome to WebmasterWorld Guest from 126.96.36.199
Forum Moderators: phranque
The purpose of this botnet appears to be spamming but whether it's email spamming or web spamming was unclear from the articles.
Researches have unearthed what they say is the biggest botnet ever. It comprises over 400,000 infected machines, more than twice the size of Storm, which was previously believed to be the largest zombie network.
What's new and different is this botnet uses HTTP as it's primary protocol instead of IRC!
In addition, compromised nodes speak to a control server using HTTP traffic instead of the more traditional approach of using IRC channels. IRC channel traffic is more obviously suspicious.
The really scary part is that the anti-virus products are behind in detecting this:
So far, only about 20 percent of PCs running anti-virus products are detecting the malware.
What makes the anti-virus vendors being behind in detecting Kraken more astonishing, in my opinion, is this malware has been known in malware research circles for at least a month!
APRIL 9, 2008 ¦ 4:00 PM - Damballa on Monday released details on Kraken, which it says is an all-new botnet that's twice the size of Storm, with 400,000 bots, including machines in 50 of the Fortune 500 companies.
This obviously raises quite a few concerns for webmasters as the sheer scope of this network could obviously be used to create quite a problem for any web server with just the volume of requests that could be generated per second.
TippingPoint's DVLABS published a list of about 15K known infected IPs responding to the botnet and the range of many of these IPs are in areas of frequent discussion in the Spider forum already so that wasn't much of a surprise.
[edited by: incrediBILL at 1:33 am (utc) on May 1, 2008]
This does not require the ISP to detect anything, merely to look at logs and verify the report.
3rd parties could also report, or maintain passive lists of, target bot herder addresses. ISPs could then scan network traffic for these addresses, potentially both blocking them and identifying infected PCs. False positives would be relatively rare.
I upload an email to smtp.myisp.com that is addressed to firstname.lastname@example.org and bcc'd to email@example.com
Problem: thisco.com has crashed - damnation what's going to happen now? Surely, the mail will sit intact, fully assembled on smtp.myisp.com (more or less) until it can be delivered to firstname.lastname@example.org
Why on earth would any server that has to hold on to the email until it has been delivered store it as some sort of ephemeral packet stream instead of as a single, fully assembled piece of data?
Can you answer this question without resort to technical mumbo-jumbo?
If I use smtp.mydomain.com to send mail, I agree that the ISP would see nothing but data packets and it would be unreasonable to expect the ISP to perform any sort of filtering - but that is simply not what happens where the average user is concerned.
Oh yes, consider this, in the UK, ISPs are required, by law, to save all emails for two years (I think). Organisations such as the police, fire service and even local authorities can demand access to those emails. If ISPs never actually assemble emails, how on earth do they manage to save them?
If ISPs never actually assemble emails, how on earth do they manage to save them?
E-mail address is mostly an extra service of an ISP to their clients. Only in that case they store the emails on their servers, but if the e-mail server is located somewhere else ISP's are not able to save the packets "in transit".
E-mail address is mostly an extra service of an ISP to their clients.Agreed, but it is a commonly-provided service non-the-less (but I am talking SMTP not "email addresses").
If the ISP does not provide the SMTP service (either because it's not included in the package or because another SMTP service is selected by the user) then it need take no action when an email is sent.
Having said that, given that most email is uploaded using port 25, it would be a straightforward matter for ISPs to monitor emails sent via other servers (but I have never proposed that).
My ISP is ntlworld.com (now VirginMedia). My personal emails are sent using smtp.ntlworld.com - the idea that they cannot scan emails that I send before they are dispatched to recipients is just plain laughable, utterly absurd, complete nonsense. Yes, it would require a small amount of effort, but the problem is little more than trivial.
My personal emails are sent using smtp.ntlworld.com - the idea that they cannot scan emails that I send before they are dispatched to recipients is just plain laughable, utterly absurd, complete nonsense.
Botnets mostly consist of computers belonging to people with little computer knowledge.
But what if you mail client connects to non-standard port on another smtp server and pop/imap elsewhere running again on an arbitrary port?That's not even a straw you're clutching onto.
We're talking about computers with default internet settings resulting from running an installation CD following instructions.
Of course, botnets could try to send spam via other SMTP servers, and that might be something that needs to be looked at, but botnet spam is normally sent via the ISP's SMTP server using the local credentials of that particular computer's user. If the spammers had access to other open SMTP servers (that haven't been blacklisted) they wouldn't need botnets to send spam would they?!
In addition, compromised nodes speak to a control server using HTTP traffic instead of the more traditional approach of using IRC channels. IRC channel traffic is more obviously suspicious. Data sent between compromised machines and control servers is encrypted and features randomly generated headers in a bid to further disguise dodgy communications, PC Tools explains.
In order to evade host intrusion prevention systems, such as firewalls, the new variant of Kraken 'talks' to its control centres via HTTP (the 'language' that web browsers use to talk to websites), using pseudo-random dynamic DNS names, with a variable length from seven to 12 characters, followed with one of the domain suffixes: dyndns.org, yi.org, mooo.com, dynserv.com, com, cc or net. The commands and data that the bot exchanges with the control centres is encrypted and also uses randomly generated 'bogus' headers to stay hidden under the firewall radar.
Using this approach the Kraken bot calculates the likely coordinates of its control server, without knowing where it is.
I am not sure what they're doing but they don't need ISP's mail server at all.
Actually, that's the part they DO need is someone else's SMTP server.
But what if you mail client connects to non-standard port on another smtp server and pop/imap elsewhere running again on an arbitrary port?
Some ISPs that I've been on that have locked out 3rd party SMTP access also block the SMTP packets so it doesn't matter what port you use, you simply cannot connect.
That's why we don't see the ISPs that block 3rd party SMTP servers involved in this type of botnet activity because those machines can't send email spam. However, they can do other things such as post blog/forum/wiki spam, harvest email addresses from websites, and attempt to hack websites.
Spam isn't their only objective :)