More on Sasser, IPSec Firewalls, and SMB
I've had a couple of internal and external questions on the last post; rather than keep on flogging the earlier article, here's some more background information on how this all works. I've been known to be wrong before, so please yell if you spot any mistakes or overgeneralizations.
Don't Be Scared Of IPSec!
It's not as complex as it first appears. Really. Use the policy file to have a look at it - using it for blocking is just like configuring any other firewall, only with more layers, tabs and dialogs!
Sasser
Sasser (A through D) attacks hosts by connecting to TCP port 445. There are other ports used for payload transfer, but 445 is the one that causes the reboot, and that it's actually trying to exploit at the moment. All variants currently run an FTPD on 5554.
File Sharing Basics
Windows uses the SMB (Server Message Block) protocol for file sharing - when you connect a network drive, chances are you're using SMB to do it. Files that comprise the bulk of Group Policy settings are pulled to the client using SMB; logon scripts are run using SMB. RPC can also be used over SMB.
Windows 9X and Windows NT support only NetBIOS for file sharing, and this is performed using the NetBIOS Suite, the business end of which is TCP port 139. I'll call these “Legacy“ clients and servers for this discussion.
Windows 2000 and beyond (so Windows XP and Windows Server 2003 at this point) support the use of what's called “Direct Hosted SMB over TCP/IP”, which is the mechanism that uses TCP port 445. It essentially avoids a NetBIOS layer when doing file sharing.
To support both methods, Windows 2000+ clients try to connect to file shares on both on port 139 and 445 simultaneously, and start working with whichever connection responds first, sending a TCP reset to the slower port (if it responds at all).
If you disable NetBIOS over TCP/IP, then you're left with the direct hosted SMB stuff, so this effectively rules out using 139.
Typically, non-Legacy servers with File and Printer Sharing enabled operate with ports 445 and 139 incoming enabled, for compatibility with Legacy clients.
A Word On the NetBT Service
The NetBT service is NOT NetBIOS over TCP/IP alone. Don't disable this service to try to disable NetBIOS over TCP/IP. If you're going to disable it, use the radio button in Advanced TCP/IP properties, on a per-adapter basis. This service does more than just NetBIOS over TCP/IP, so please don't touch, it'll break other things as well.
IPSec as a Firewall
Using the IPSec driver to drop packets makes a very cheap (it's in every copy of Windows 2000 Pro and above) and straightforward port-based firewall out of every desktop. In situations like Sasser, this means that blocking exploit ports becomes relatively straightforward (and once you've done it once, you'll want to do it again).
You can block any protocol, port, single IP, range or subnet, incoming or outgoing. It's not application-aware (so it's not as flexible as the ICF or upcoming Windows Firewall - that is, it's not a stateful firewall), but to block exploits and the odd worm, it's as effective as it needs to be, in most instances.
That IPSec Policy
The IPSec Policy I put together (click that link to download it) prevents incoming connections on 445 (plus payload ports), and I've recommended it only be used for clients. In most cases, it can be used on servers too, but be aware of the risk if you've disabled NetBIOS over SMB on the server.
If you block 445 incoming on the clients, there's low to no risk; the clients will simply drop a connection attempt made to port 445 on themselves. You may still be able to do file sharing if NetBIOS is enabled on the clients; if not, RPC may still work for remote management anyway (port 135, then a referral to an ephemeral port).
The key point is that by not blocking outbound 445, the client can still connect to File Shares using port 445. If NetBIOS over TCP/IP is enabled on the client and the server, it has two options for doing this, but if not, it's not going to be able to connect any more. Sure, it can also try to infect other clients, but if every client is blocking port 445, that's a lot less to worry about while you get SUS in place to patch the little blighters.
The risk of blocking outbound 445 is that if NetBIOS (port 139) is disabled on the client or its target server (say, a DC), then the client will not be able to pull down logon scripts, Group Policies, and other important bits and pieces - and if you can't download Group Policy, you can't use Group Policy to turn it off. And that's why I'm hesitant to recommend blocking outbound connection attempts on the client, and inbound 445 on servers... it's eliminating a possible leg to stand on (but can be applied safely if tested, just don't go applying it to the whole domain).
Which Port?
Here's a quick summary of what I understand the ports to be used for by Sasser, and the effect of blocking each:
Block 445 Incoming: computer will not be rebooted by exploit attempts (because they're dropped) (Sasser A to D)
Block 445 Outgoing: exploited computer will not be able to connect to other computers to exploit them *but* may also break Group Policy and connection to file shares (see discussion above).
Block 5554 Incoming: exploited computer cannot have files copied from it.
Block 5554 Outgoing: same effect.
Block 9996 (A-C) and 9995 (D) Incoming/Outgoing: exploited computer won't initiate the transfer (not really sure if this is the case).