In a recent article, I chronicled what I believe to be a new and looming threat to virtually all business and individual users of the Internet: the Mini-DDoS (mDDoS).
These are distributed denial of service attacks small enough to fly below the security radars of ISPs and law enforcement agencies, but potent enough to shut down cable or DSL modems connections. As evidenced by my inability to do anything about an attack on my connection (which I use to get my job done, but is shared with other family members for personal use), the perpetrators can wreak havoc without fear of reprisals.
Cable and DSL modem connections account for a growing contribution to the U.S. economy. Just think of the telecommuters and small- to medium-size businesses that host through such connections and the number of e-commerce transactions that pass through them. To the extent that national security relies on the vitality of the economy, I consider the mDDoS a significant threat to our national security.
I received a tonne of replies to that column with all sorts of interesting suggestions on how to stop an mDDoS targeted specifically at my home office connection. The most common suggestion was to unplug my router and plug it back in again. The thinking behind this is that if my Linksys router is obtaining its IP address from my Internet service provider (ISP) each time it restarts, then restarting it will force my ISP to issue the router a new address, and the mDDoS (which was relying on the old IP address) would lose its way.
Unfortunately, this is not a solution for a variety of reasons. First, although my ISP does issue dynamic IP addresses, the one it issues me never changes anyway. Despite all my attempts to release the old address and obtain a new one, my router always ends up with the same IP address. Additionally, even if this technique did work, it would simply put an end to the attack in progress. It wouldn't prevent it from happening again. Sooner or later, the perpetrators may get the new IP address. I have no interest in running to my basement every time I think I am experiencing an mDDoS.
Many readers asked if a personal firewall would have helped. The answer in my situation, where several PCs use a Linksys firewall/router to share a single connection to the Internet, is no. I already have personal firewalls running on the PCs. Within my home's local area network, the PCs have no trouble talking to one another. The connection that was overwhelmed by mDDoS was the one on my Linksys router that was connected to the cable modem. In other words, the traffic from the mDDoS never even reached the PCs on my network.
Several ISPs wrote in to say that they were aware of the problem and want to do something about it, but that I'd be surprised at how difficult it is for them to address the problem. The main problem has to do with the scalability of the carrier class anti-DDoS solutions. These solutions apparently employ the right techniques for ISPs and telecommunications carriers, but they have a difficult time keeping up with all the traffic that some of the larger ISPs see.
The best advice I got came from Greg Scott, founder and CTO at InfraSupport Corporation. One of Scott's specialties is custom-building firewalls, using Linux. Scott suggested that I run a simple vulnerability test on my router to see if it was configured to help an mDDoS attack, rather than take countermeasures to diffuse it. Scott suspected that the attackers' technique was relying on the router to tell them that a port was there, alive and waiting for its next instruction. In network lingo, this is referred to as an acknowledgement or an "ACK". In addition to alerting attackers to a port's presence, ACKs also take more of the router's processing power.
The port I'm speaking of is not the same as one of the ports on your router that you plug Ethernet cables into. The protocol that the Internet relies on (not surprisingly known as Internet Protocol or IP) uses the concept of "ports" to separate network traffic by the applications that create that traffic. For example, if you use your browser to access a Web server, most of the network traffic created by your browser is assigned to port 80 (the default port for HTTP, the primary protocol that makes the Web work). On the receiving end, when that traffic reaches the physical server, that server uses the port information to determine which application running on that server should service the request from your system. If it's port 80, then it passes the traffic to the Web serving software (such as Apache or Microsoft's Internet Information Server). If it's port 25 (the default port for SMTP, the protocol for Internet e-mail), it passes the traffic to the e-mail server (such as Lotus Notes or Microsoft Exchange). In many cases, especially in larger companies where physical servers are assigned one instead of multiple purposes (one for the Web, one for FTP, one for e-mail), a router uses the port information to decide which physical system to forward the traffic to.
In my case, I learned from my router's logs that the mDDoS attack was targeting port 113. All traffic from the two systems attacking my router was targeting that port. Scott suspected that port 113 on my router was actually giving the attackers the feedback (in the way of ACKs) they were looking for in order to continue with the attack.
To see if port 113 on my router was ACKing or not, Scott suggested I run Gibson Research's ShieldsUp service. ShieldsUp is a free service that anyone with a Web browser can access and that scans your network connection for common vulnerabilities. Among the vulnerabilities it looks for are ports that are ACKing when they shouldn't be. When ShieldsUp scans your ports, it comes back and tells you whether they're open, closed, or stealth. Open means just that. The port is open for business.
Since I'm running a Web server, and I had my Linksys router set to forward all port 80-based traffic to that Web server, port 80 showed up in ShieldsUp as being open. Open ports can be a problem because they not only ACK, they also provide an open connection to a system that could be inside your firewall "listening" on that port the way many Web servers listen for traffic on port 80. If you have open ports the way I have, then you know why they're open and you should be taking whatever precautions are necessary to seal up any known exploits for the software you're running. Most people are not doing such port forwarding, however, and therefore should find that none of their ports are open. If you need to keep any ports open, you may need a more sophisticated firewall (the sort that Scott will build for you) to make decisions about whether requests from a certain source are legitimate or not.
If ShieldsUp comes back and tells you that a port is closed, that's not quite as bad as a port being open, but it's still bad. There may be no systems on your network waiting to service requests that show up at that port. But the port will still be ACKing to attacking systems. With the exception of port 80, the only other port that was ACKing (and that ShieldsUp reported as closed) was port 113 -- the same port that the mDDoS perpetrators used in their attack.
ShieldsUp reported that the rest of the ports were stealth. In other words, if an attacker was scanning for an open port on my IP address, none of the other ports would have responded, which in turn (as long as my ports 80 and 113 were also stealth) would make it look as though the IP address didn't even exist to would-be attackers.
So, once equipped with this information, what's next?
I was disappointed to learn that in addition to port 113 on the Linksys BEFSX41 router being closed by default (and thereby being set to assist in an mDDoS rather than hide from it), ports 1002 and 1055 were equally vulnerable.
In discussing the issue with another ZDNet editor, I learned that, by comparison, his NetGear ProSafe Firewall FR114B appeared to ShieldsUp as being 100 percent stealth. None of the ports on his NetGear box were open or closed. I was jealous.
InfraSupport's Scott suggested that there was probably a way to convert the closed ports into stealth ones. Indeed, there was. Using the router's management utility, you can find the ports in question, and forward them to a non-existent IP address on your network. This suggestion came from the Gibson Research Web site. After I tried it and ran ShieldsUp again, the ports in question had indeed been switched from "closed" to "stealth".
Did it work? Was I able to fend off the next mDDoS attack? At this point, I don't know. The BEFSX41 has a neat feature that will alert the e-mail address of your choice when it thinks it's being subject to a DDoS attack. So far, I haven't played with it. Since I've experienced no downtime since the last attack, I'm assuming my connection hasn't been victimised again.
Also, while these counter measures may indeed fend off amateur attacks, they may not successfully defend against something more sophisticated. Scott suspects that because port 113 was vulnerable and overwhelmed, the "little" router simply wasn't equipped to deal with the flood of traffic that targeted it. Other attacks such as ones that would relentlessly flood the last mile with UDP packets (a type of protocol that runs over IP) do not rely on ACKs and therefore might succeed.
Given the increasing sophistication of DDoS attacks, the relative ease with which they can be pulled off, and the damage they can cause, I expect it's only a matter of time before we see cable modem router/firewalls take on some of the security features and bandwidth capabilities that are typically associated with enterprise-class equipment.