The Microsoft Web Outage: What Went Wrong?

Unless you’ve been stranded on a desert island, you’ve no doubt heard about the run of bad luck Microsoft had a few weeks ago. In one week’s time, Microsoft had three major Web failures. The first of these failures was related to a router configuration error. However, the two other failures were the result of a security breach. In this article, I’ll explain what flaws the hackers exploited to bring Microsoft to their knees. As I do, I’ll also explain what Microsoft could have done differently to prevent this terrible situation.

Denial of Service

After the Web failure occurred, Microsoft’s security analysts determined that the Web outages were the result of a denial of service attack. As you probably know, a denial of service (DoS) attack is a procedure that’s designed to flood a Web server with more requests than it can handle. Many times, the perpetrator of a DoS attack will take control of many different computers all over the Web and set those computers to constantly access the server that’s being attacked. In this way, the hacker can flood the Web server with so many requests that it will be nearly impossible for a legitimate Web surfer to access the site. Depending on the nature of the attack and the software running on the machine that’s being attacked, it’s sometimes possible to flood the server to the point that it drops offline.

The DoS attacks against Microsoft were unique, however, because they weren’t targeted toward a Web server. Instead, these attacks were aimed at a router. Apparently, the hacker had learned of two critical design flaws in Microsoft’s network that made it vulnerable to attack.

Design Flaws

The first of the design flaws was that the router represented a single point of failure. The router that the hacker attacked stood between Microsoft’s internal network and its Internet connection. Therefore, by clogging the router, the attack made it nearly impossible for anyone to access Microsoft through the Web. If Microsoft had a secondary Internet connection that was linked to a different router, this problem could have been avoided. Even if a hacker managed to shut down a router, the second router would keep traffic moving between the Web and the internal network.

However, the router was only half the problem. As you probably know, routers not only connect networks to the Internet, but they are also used to divide networks into segments. Although Microsoft had divided its network into segments, all of the company’s DNS servers were located on a single segment. Unfortunately, this segment was shut down by attacking the router.

So what does this have to do with blocking access to Microsoft’s Web sites? Keep in mind that when you enter “www.microsoft.com” in your Web browser, the browser has no idea where to go. Because the browser can’t work directly with domain names, it must consult a DNS server for the IP address associated with the domain name. Only after the Web browser knows the Web site’s IP address can it actually go to the site.

Solving the Puzzle

Now that you’ve seen all the pieces of the puzzle, let’s look at the situation as a whole:

1. The hacker decides to launch a DoS attack against Microsoft’s primary router.
2. A legitimate user tries to access the Microsoft Web site. When the user enters the URL of any Microsoft site into his browser, the browser looks to a DNS server for the location of the Web site. (Keep in mind that the TCP/IP configuration information on a PC includes addresses for a couple of DNS servers, which usually are supplied by the user’s Internet service provider.)
3. The browser checks the DNS server for the IP address corresponding to the Web site. If the DNS server knows the address, then the address is sent to the browser and the browser tries to access the Web site–but it can’t, because the router is under attack.
4. On the other hand, if the ISP’s DNS doesn’t know the IP address of the Web site, it consults other DNS servers along the line until a DNS server does know the address. Many times, this process may mean accessing one of Microsoft’s DNS servers directly. However, the ISP’s DNS can’t access the Microsoft DNS, because the router is under attack and every one of Microsoft’s DNS servers are behind that router.

As you can see, although you can’t prevent a DoS attack, a problem like this one could have been avoided. All that Microsoft had to do was distribute its DNS servers around the network and provide some redundant Internet connections through different routers. Does your network architecture protect you from the same fate? //

Brien M. Posey is an MCSE who works as a freelance writer. His past experience includes working as the director of information systems for a national chain of health care facilities and as a network engineer for the Department of Defense. Because of the extremely high volume of e-mail that Brien receives, it’s impossible for him to respond to every message, although he does read them all.