Host-Based Firewalls

A developer's laptop at the video game studio has a firewall of its own, which checks every connection in or out of that one laptop. Here is the rule list the IT lead set on it. Every device on a network has an IP address, a number others use to reach it. Every address in the office begins 10.40, written 10.40.0.0/16, where /16 means only the first two numbers are fixed. Each rule names a port, the number that tells the laptop which program a connection is for, and a protocol, TCP or UDP, the two common ways programs send data.

A coworker at 10.40.3.17, in the office, tries to reach the laptop on port 7777, but the coworker's game build is an old one that connects over TCP. Which rule applies to that request?

Rule 1 looks like the match, since the address and the port both fit it. But rule 1 is for UDP, and a rule matches only when every part of it fits. Rule 2 names TCP but a different port number, and rule 3 is for what leaves the laptop. That leaves rule 4, which matches any incoming connection, so the request is dropped, and the coworker needs the current build.

Rule 3 looks odd at first, blocking a kind of outgoing traffic that nothing on the laptop uses. The IT lead added it because of a worm from August 2003. On August 11, a worm later called Blaster began spreading through Windows XP and Windows 2000 computers. It sent a specially built request to a Windows service that listened on TCP port 135, through a flaw Microsoft had patched in July, and took over the computer. Then it made the new victim download a copy of the worm program, msblast.exe, from the computer that had attacked it, using TFTP, a bare-bones file transfer method on UDP port 69. Each victim then started attacking others. The attack often crashed that Windows service, so computers it hit kept restarting, infected or not. Starting August 16, the worm was set to flood windowsupdate.com, an address that forwarded to Microsoft's update site; Microsoft took that address off the internet beforehand, and the flood hit nothing.

Match each of Blaster's two steps to the rule that would have stopped it.

Rule 4 stops the first step: the attack arrives as an incoming connection to port 135, which no rule allows. Rule 3 stops the second: a victim that was somehow broken into still couldn't fetch the worm over TFTP. Either one breaks the chain, and the two together mean a single mistake in the rule list doesn't let it through. The last rule is looser than the advice on outbound rules below: whatever leaves the laptop that the rules above don't name gets through. That is the usual default, because naming everything a device needs to send is hard, so rule 3 stops only the one kind of traffic the IT lead knew to stop.

Blaster got into many companies that had firewalls at their internet connections. Laptops infected on home networks or public hot spots were carried back to the office and plugged in, inside the boundary firewall, where nothing stood between them and the other computers. Microsoft had shipped a firewall inside Windows XP, but it was off unless the user turned it on. In August 2004, Microsoft's Service Pack 2 for Windows XP turned it on by default, refusing incoming connections that hadn't been allowed. Jeffrey Lee Parson, a Minnesota teenager, was sentenced in January 2005 to 18 months in prison for releasing a variant of the worm. Whoever wrote the original was never caught.

The worm program carried two lines that were never shown on screen. Researchers found them when they unpacked the file and read it:

I just want to say LOVE YOU SAN!!
billy gates why do you make this possible ? Stop making money and fix your software!!

At the office, the laptop sits behind the studio's network firewall as well as its own. At the café it sits on a network the studio knows nothing about, beside strangers' devices, and the boundary firewall is miles away. There, rules 1 through 5 are the only network-level protection the studio controls.