50 ISPs Harbor Half of All Infected Machines

Orome1 writes "As the classic method of combating botnets by taking down command and control centers has proven pretty much ineffective in the long run, there has been lots of talk lately about new stratagems that could bring about the desired result. A group of researchers from the Delft University of Technology and Michigan State University have recently released an analysis of the role that ISPs could play in botnet mitigation — an analysis that led to interesting conclusions. The often believed assumption that the presence of a high speed broadband connection is linked to the widespread presence of botnet infection in a country has been proven false."

Re:Duh.

[Albanach]

Do either of them filter outbound smtp?

It still amazes me that residential broadband connections don't filter this as standard. I guess while it's technically easy, it's all about cost, and it's cheaper to leave a customer running an infected machine than have them call your helldesk.

Re:Duh.

[mikael_j]

Unfortunately I've worked for several ISPs that had the bad habit of enforcing the following:

• Blocked outgoing connections on port 25 for all hosts except their own SMTP relay.
• Required valid logins on the SMTP relay in order to send emails.
• Draconian size limits on emails passing through the SMTP relay.
• Low upper limit on number of emails per day through the relay.
• Antivirus software that ripped all sorts of benign data from emails for no reason.

Let's just say there were plenty of issues with users who couldn't figure out how to set things up on their own, not to mention users who found out the hard way that large attachments caused their emails to bounce (somewhere in the 10-15 MiB range IIRC).

Personally I'd love if there was at least an option for completely unfiltered access (perhaps even proper reverse lookup to deal with the idiots who think reverse lookup is a good way to deal with spam (hint: it's not, way too many legit companies have multiple hostnames on their mail servers or use a third party's mail relay for this to work well, it just gimps email)). Now. I'm not saying this should be for everyone, filter by default but give users an option to turn the filter off completely but display an overly clear "don't do this unless you're absolutely certain you know what you're doing" message that includes a warning about how the ISP will shut them down in a nanosecond if they get any legit spam reports. That way those who really want/need unfiltered access can have it while the rest of the users can enjoy the walled garden.

Wrong way of looking at the problem

[Rosco P. Coltrane]

The real shocking truth here is that one single OS harbors the vast majority of botnets and viruses. That OS should be the real target, not ISPs or poor users or something. Sheesh...

Sandbox

[Mr. Munshun]

A friend of mine who was tasked with looking after a university network years ago had a setup that worked well. When the user first connected, they were put in a sandbox, and thus not allowed outside access. They would be greeted with a web page stating that their computer was being scanned for ports well known for viruses and/or spyware. Once the scan was completed, which took about 60 seconds IIRC, they were allowed access to the Internet. Perhaps there is a way that ISP's could do the same sort of thing?

Botnet sans broadband? Seen it already...

[damn_registrars]

My site at home has been under a distributed hack attempt (a long list of IPs all trying to ssh in as root*) for days now. On the first day the attempts were quite frequent; approaching 1 per minute. Now on day 4 the attempts are trickling it as infrequently as one every 20 minutes. A system on a reasonably fast connection could on its own surpass the 1/minute barrier when running a dictionary password attempt through ssh if it wanted to; hence this looks like it could well be systems on slow connections. Add in that some IPs disappear for a while and then come back - as if the PC is logging off and then on again - and it certainly does look like a low-speed botnet.

* Naturally, my ssh denies all root attempts. Even if they got the password right they wouldn't know it, because the rejection would be the same. Other botnets have tried whitepages-style attacks using long lists of common user names and not matched any allowed users on my system as well.

** Yes I know I could just change my ssh port and much of this would go away. But I find it amusing and I have bandwidth to burn.

very flawed logic

[frovingslosh]

One big problem with this logic is that it is based on IP addresses analyzed from captured spam. The problem with that is some major ISPs (including AT&T) are blocking access to out-of-network e-mail servers, and doing other things to make it difficult for even their legitimate customers to send legitimate e-mail. So this method of knowing where the botnets are would completely miss major botnets if they are unable to get spam out efficiently.

You may say "Why does that matter as long as the spam is stopped?", but it matters a lot. The machines are still infected and could be used for other things, from denial of service attacks to hosting and spreading kiddy porn to just watching for private data to go by (like banking information and credit card numbers) and report them directly back to the control system. Making major judgments about botnets based only on IP addresses seen in spam is short sighted and foolish. And it also assumes that all botnets are honest enough to not forge IP addresses. Any smart botnet could easily forge the IP address the spam is coming from, to make it that much harder to find. If a clever bot just changed the fourth or even third and fourth part of the IP address and replaced it with a random number, the botnet would look much larger than it really is and make it much harder to track back to the infected machine, but would not be easy to detect by comparing the supposed source IP and the SMTP server from outside the network.

Re:Wrong way of looking at the problem

[Rosco P. Coltrane]

Fix the OS, and botnets will pop up on a different OS

That is indeed the common wisdom. However, somehow I'm not convinced that's entirely true: Linux and MacOS machines have been around for a long time, and even if the represent a small (albeit growing) segment of the market, they're there and you'd think many pieces of malware would have cropped up on these platforms already. Yet it just hasn't happened: there are some, but nowhere near what you'd expect if the latter OSes were as insecure as Windows.

The other wisdom is that Windows is insecure because Windows users don't know jack squat and can't take care of their own security. That too I think isn't true: there are a lot of Windows users who can and do take precautions, and setup accounts with limited rights and whatnot. It goes a long way to curb malware infestations, yet those Windows boxes still get infected. At any rate, if indeed Windows is insecure because it has to stay simple, it means that in 25 years Microsoft still hasn't figured out a way to cater to noobs without compromising security, which is pathetic.

There's a reason why running an antivirus and a firewall is an absolute necessity only on Windows...

Re:Duh.

[mikael_j]

Why would you want to send mail from a residential IP?

Because it should be possible.

The vast majority of big mail servers will simply block your messages.

I've found it's more like a minority, and I've even encountered a few that block large swaths of IPs that they have tagged as "residential/dynamic" but will let incoming emails through if there's a proper matching SPF record.

What's the point of email if you don't have reliable delivery?

It's only unreliable because some admins are lazy. And boy, it sure is fun when an IP that's been a static business IP for years suddenly gets blacklisted as "dynamic residential"...

If you want to access your own mail server running elsewhere, it should be trivial for it to allow inbound connections requiring smtp auth on a port other than 25.

It's still just a workaround that doesn't need to be done if the ISP handles its network properly instead of just randomly blocking ports for shits and giggles. And most only block outgoing port 25 so it's pretty easy to set up your MTA to send via their relay and run the MTA locally anyway, but this still retains the problem of the ISP filtering and messing with outgoing email (as well as the potential loss of outside access if their SMTP relay decides to go down, and I've seen enough ancient Solaris machines handling customer email to have a strong distrust of ISP SMTP relays, it shouldn't be "normal" for it to go down at least 1-2 times per week if you have tens of thousands of customers).

Simple (but not easy) solution

[wowbagger]

There is a simple solution to the problem. Unfortunately, being simple does not mean it is easy.

1) ISPs by default implement some basic filtering:
1a) do not allow access to port 25, save to their own servers
1b) do not allow inbound nor outbound access to certain "LAN only" type services (e.g. NFS, SMB/CIFS, etc.)
2) NOTA BENE: ISPs SHALL allow users to elect to bypass these filters, but:
2a) This shall require action on the part of the account owner.
2b) Upon doing so, the account owner SHALL be responsible for their actions
2b.i) The ISP SHALL provide a contact mechanism (e.g. WHOIS record for that IP) that notifies both the ISP and the account holder of abuses.
2b.ii) The ISP SHALL act on complaints if the user does not.
2c) The action to disable blocking SHALL be done in a way that prevents a bot from doing it (e.g. require a phone call to the ISP, or a Turing test, etc.)
3) ISPs SHALL look for "infected" behaviors, like port scans, BEFORE the traffic leaves their network (remember people, the term "firewall" comes from building codes, where a building is supposed to have MANY levels of firewall. ISPs should be no different).
3a) such behaviors SHALL be investigated, and potential infectees quarantined and the owners contacted.
4) ISPs SHALL be required to address complaints
4a) The SHALL be required to have an automated means to report such abuses. No, Web pages don't count.
4b) ISPs that fail to address complaints SHALL be listed in such a way that other entities can block them (e.g. DNS-RBLs).

For too long ISPs have been able to externalize the costs of infected machines. Obviously, any cost a business can externalize will be externalized, and thus the business won't handle it. The solution is to force the costs of infected machines to be internalized to the ISPs. They will, of course, bitch mightily about this - again, no business will allow a previously externalized cost to be internalized without a fight.