ISPs cutting off infected users
I was reading Richi Jennings blog and his recent post about whether or not ISPs should cut off infected users from the Internet, that is, if they detect that the user’s machine is infected, do not allow that machine to browse the Internet and instead either disallow the user from sending out any internet traffic or redirecting them to an instructional page indicating to them that they are infected and should take actions to fix the problem.
In my view, ISPs taking action on botted machines is very similar to the problem that we as an outbound mail relay had when we were taking action on customers that were/are sending outbound spam. In our case, we had to detect that a customer was sending outbound spam and take action on it once we discovered they were doing abusive behavior. We are at the disadvantage that we do not own the email ecosystem of the mail that is passing through us, that is, it is a customer organization that is creating the mail and relaying it through us. Therefore, we can’t just fix the user’s computer once we detect that there is a problem, we have to tell the organization’s admin that they have a problem on their network and hope that they fix it. By contrast, an ISP does own the pipes that connect to the Internet from the user’s computer and they can (in theory) take direct action on the user’s computer. That is to say, there is no middle man between the ISP and the user that connects to them. If that user connects and is still botted, they can point to their terms of service (in theory).
However, ISPs are at a disadvantage compared to us. When we detect outbound spam, we are analyzing spam complaints from 3rd party feedback loops and examining logs for bursty behavior. When these complaints come back, we can take a look at the spam see the mail in clear text. In other words, it’s easy for a human to see if the behavior is malicious or not. In the case of an ISP, how do you tell whether or not a particular machine is being abusive?
An ISP such as Comcast is in a particularly tight spot. Something such as deep packet inspection would be useful to see what types of Internet traffic is flowing over their networks. By doing this, they can tell if someone is launching a DDOS attack, doing black SEO, sending malware, or other types of malicious actions. Of course, the minute someone like Comcast or Verizon even thinks about doing deep packet inspection, Net Neutrality advocates get all up in arms and claim that they are using security as a smokescreen precursor to traffic shaping. Not only that, while deep packet inspection sounds really cool, it’s actually quite expensive to do for an ISP like Comcast or Verizon when they have millions of bits of information flowing over their lines every second. Getting this information in real time and then taking action is very resource intensive.
The logical way to do it is similar to the way we check for outbound spam, and one of the ways malware/botnet researchers infiltrate a botnet. In the case of spam, we run all mail through a spam filter and keep track of outbound spam statistics. For a botnet researcher, they infect a machine with a particular piece of malware and then they check to see where the bots call home to, that is, what URL the bots look for updates, or if it is doing P2P, or if if is connecting to an IRC channel. For an ISP, if they know which domains a botnet calls home to, then in theory they could tell which IP address is connecting to which botnet URLs. Whenever someone sends a request, either http, ftp, or some other DNS protocol, that attempts to resolve the botnet C&C’s domain, then it is a logical assumption that the machine behind the IP address is part of a botnet. Australia started doing this earlier this year, and Comcast redirects its botted users’ web browsing session to a security portal where they educate the customer that they’ve been pwned and what steps they can take for remediation.
The advantages of this approach are the following:
They are letting users know that they are infected. Without informing them, most users would never otherwise know and might not take corrective action or alter their browsing habits (running A/V, running up-to-date software, etc).
They are providing them with instructions on how to fix their problem (ie, remove the malware infection). This corrects the problem so that it is one less bot on the web.
The soft block approach where Comcast directs their users to an information page lessens the intrusiveness of the action that Comcast is taking. In other words, if there is a false positive they can still browse the web and not be cut off from a service they are paying for.
The drawbacks of this approach:
A user can ignore the message by navigating away from the web page. If the onus is on the user, then they have the option of doing nothing and the problem continues. They can either do this deliberately because they don’t care, or don’t understand the instructions provided. If they don’t understand the instructions, then this can generate support calls which increases the cost overhead of the ISP.
This solution checks for domain resolution to an abusive URL and maps it back to an IP address. If the IP address is shared (like most home users are), then everyone on that shared IP gets the redirection to the web page. This means that clean users will get the message “Your machine is pwned“ but isn’t, it can create a “WTF?” experience.
Unfortunately, there is no way around this. If an IP address is how you track abusive resolution to domains, then there will be collateral damage in the shared IP space.
Obviously, it would be nice to use a finer layer of granularity but that option is not available without deep packet inspection where you can possibly map finer levels of identification. However, that has serious privacy considerations, that is, privacy watchdogs are not very understanding about this sort of thing. For example, Microsoft collects lots of statistics from its Malicious Software Removal Tool, and Microsoft Security Essentials A/V software, but they don’t collect Personally Identifiable Information (PII) such as IP addresses. They especially don’t collect machine IDs, and this is all due to privacy. While it’s great for keeping privacy private, it’s an obstacle for security because you cannot zero in specific problematic machines.
Thus, without the ability to narrowly target a specific user’s machine rather than their IP address, some users will get phantom messages.
Kudos to Comcast for taking affirmative action on machines that are part of a botnet. If they can experiment with it and determine that the cost/benefit ratio is favorable, then hopefully this can be a model that other ISPs will follow – both in the United States and in the rest of the world.