Botnets are responsible for sending 87.9 per cent of all junk mail messages, according to the latest monthly stats from email security outfit MessageLabs. A newer botnet, Maazben, first seen in late May, increase junk mail output to account for 1.4 per cent of all spam messages in September, compared to 0.5 per cent of spam in …
Botnets, why cant antivirus find the software on all theses PC's?
I dont get it, are all these PC's in botnets running out of date antivirus software (or even none at all?).
Botnet software infested pc's are spewing out emails, so a simple block on port 25 and having to use the ISP's port/server with software on that server that will stop obvious spam would make a massive difference.
No doubt then the botnet will use a completely different port to connect to a compromised email server somewhere but nonetheless it would lower the total amount.
Paris, because she uses different ports
Once they're aboard the PC, most botnet programs employ tricks such as rootkit tactics to make themselves unscannable and unremovable. Furthermore, the programs themselves tend to constantly alter themselves, making a signature search akin to finding a really tiny aluminum needle in a very big haystack.
That's why the general rule when one is infected has become, "When in doubt, reinstall the OS." And some lowlifes are trying very hard to make malware that resist even a reinstall.
ISP's should block port 25 by default and only open it for machines with a valid MX record. This is a logical first step and should have been done a long time ago.
Doesn't SMTP only need to send TO port 25, not necessarily FROM it? Blocking a user's port 25 is useless, then, as the bots would send their traffic FROM other ports. As for blocking all traffic with a port 25 destination (other than the ISP's designated SMTP server), that won't work either since rogue SMTP servers don't have to abide by the standard of using port 25 as the target. ANY server can use ANY port since there is no enforceable means to block otherwise--nothing there but rules.
I may be about to have a senior moment here, but presumably these machines that are sending mail are sending *to* port 25 on a machine that *has* a proper MX record (since spam is sent to conventional email addresses like email@example.com). Apart from the contents, this is surely indistinguishable from the process involved in sending legitimate email from the compromised machine. Similarly, botnet control can be done over http, with the compromised machine polling a range of controllers rather than listening for instructions.
I can't see why a botnet member would need to be listening on any port. Blocking outgoing traffic *to* ports 25 and 80 will upset the average punter (who only uses the machine for email and web). OTOH, deep packet inspection of the aforementioned traffic will leave all the non-average punters (who read El Reg) absolutely incandescent.
So what are the ISPs supposed to do?
Network sniffing too easy
It is simply too easy to sniff the network traffic and see what is happening. There is no excuse, especially on a corporate level, to have a botnet infestation on the network. A small Perl script can quantify ALL traffic, and create a nice report. I know, I wrote one. I could see at a glance what was coming in and going out. No problems.
@ Charles 9 and Ken Hagan
Yes, traffic can be sent FROM any port, but must be sent TO port 25. Some ISPs (to their credit) block outbound connections TO port 25 so that their customers cannot send mail - unfortunately some of them don't have the ability to lift that block for customers that do legitimately send mail directly. Normally the ISP will provide an outbound relay for it's customers to use, so it isn't a big problem for most customers - and the outbound relay can impose checks to detect unusual traffic patterns.
Many mail servers intended for relaying of mail will accept connections to the "submission" port (587). Since these connections *should* require authentication, then it's no good spammers trying to use them, but they allow users to send even when behind a firewall that blocks access to port 25.