Using IPSec Policies as a Firewall to Block SASSER Infection

  • Article

Short version: Use an IPSec policy to configure a miniature firewall on each client (Windows 2000 and above) to stop SASSER reboots and buy time to deploy the patch.

 

Long version: The Sasser worm hits hosts on port 445 to infect them and crashes LSASS, which makes the box restart - which can be annoying if you're trying to patch it at the time, to say the least, and can break it at worst.

 

If you have an AD infrastructure, you can quickly and easily use it to deploy an IPSec policy to the client machines that blocks port 445, as well as 5554 (the FTP server created by the worm) and 9996 (the remote command shell). Blocking any given port will stop the worm from being able to propagate, but if 445 is unblocked, you'll still get rebooting clients until the MS04-011 patch is applied as the clients repeatedly whack each others' LSasses. So, for workstations, blocking 445 seems like a reasonable path to take; you can still connect to file shares and RPC over the other SMB mechanism on 139, if NetBIOS over IP isn't disabled.

 

I rolled an IPSec policy for client application only earlier (click that link to download it). Please don't apply it to File Servers or Domain Controllers, just get them patched first. I'd rather not take the risk that other ports are blocked; these machines need to be as available as you can keep them. So, worst-case, patch them manually.

 

Why A Policy?

To buy you non-reboot, non-propagation time to apply the patch MS04-011. Once the patch is on, use a removal tool to eradicate the infection, then you're done.

 

To Assign The Policy

To assign the IPSec policy, find the OU that has your workstations in it, then edit the computer Group Policy Object for that OU. If you don't have an OU with your workstations in it (eg, not Servers, just client computers), now might be a good time to make one.

In a Group Policy object that applies to the OU, you want to go Computer Configuration -> Security Settings -> IP Security Policies on Active Directory.

 

You can only have a single IPSec policy assigned at a time, but the policy can comprise a whole bucketload of filter actions. If you import the policy above, it adds the filter actions to the pool, so you can add them to an existing IPSec policy if you like (if you've an existing assigned IPSec policy, I'll assume you know what you're doing when adding filters to it). Domain policies always override local policies if they're defined.

 

If you're looking at the default set of three policies when you start, you'll notice a SASSER policy added there now. If you've not used IPSec before, this is the one you want to Assign. If you look at the properties, you'll see two filter actions, which are block actions - I created one for the two payload ports, and one for inbound SMB 445. The payload ports are inbound and outbound blocking, but the SMB is only inbound, so you can still connect to file shares and (unfortunately) attack other hosts (if the other hosts are using the same policy, no harm done).

 

Once you've got the policy configured the way you want it, just Assign it, and all the computers in the OU will pick it up at their next policy refresh interval (up to 90 minutes by default).

 

Caveats:

  • If In Doubt, Don't Apply This Policy.
  • Patch Your Servers First. Don't Apply This Policy To Them.
  • This blocks the current infection and transfer method of the worm, but is not a substitute for patching. You Need To Patch. This may stop the constant rebooting though...
  • If you block port 139 as well, you will NOT be able to remotely manage the machine using RPC, nor will you be able to copy files to/from it. Terminal Server or Remote Desktop should still work, but you do NOT want to block 139 and 445 on DCs or File Servers. If in doubt, don't apply it.
  • If you have a problem, unassign the policy and reboot the client
  • Usefulness depends on having the IPSec Policy Agent enabled on PCs the policy is applied to. Group policy can be used to tweak this as well, in the Security settings for Services.

The policy blocks inbound 445, and in/out 5554/tcp and 9996/tcp, so it prevents infection, payload transfer and remote control, in that order. It does not prevent outbound connections on 445 - this means that clients can still retrieve Group Policy and connect to file shares, but also means that an infected client can try to hit other infected clients. This isn't as much of a problem if they're all either patched or using this policy.

 

Removal

To remove the policy, just Un-assign it in the Group Policy Object (or Local Security Policy if you're using it on standalone machines) and either reboot the clients, or wait for a policy refresh, or run

  • GPUPDATE /FORCE  for Windows XP+ machines, or
  • SECEDIT /REFRESHPOLICY MACHINE_POLICY /ENFORCE  for Windows 2000.

[Update] How This Compares To Other Solutions

This policy provides port blocking at every client that the policy is applied to. So, there are no infrastructural changes required to support it: if you have AD, you can roll out an IPSec policy, and turn the same policy off using AD when you're patched up.

Blocking the port at the router/switches is also a possibility, though blocking at the router means that an infected computer's local subnet is still able to keep itself busy - but keep in mind that you then need to identify servers you don't want blocked by IP address rather than using AD Users and Computers or similar directory-based management tools, where you probably have the servers grouped in a nice convenient OU to begin with.

Blocking at the edge is hazardous; if an infected client gets plugged into the network somehow (or VPNs in, etc, etc), then unless you're using IPSec or 802.1X to authenticate connections, or are patched, your network's edge protection will not help.

 

FAQ

IPsec seems complex. Don't I need a Public Key Infrastructure/shared key/whatever to use it?

NO!

This solution is actually not using IPSec, just using the IPSec driver to drop unwanted packets. We're not implementing IPSec itself, we're just configuring what could be thought of as a miniature firewall on every client. (as an aside, if XPSP2 were out and widely deployed, we'd have another option for doing this using a different set of policies).

 

Why not apply it to servers?

My cautious nature. Generally, SMB file sharing and RPC-dependent mechanisms can use SMB over 445, or NetBIOS-based SMB. If you've disabled NetBIOS over IP at the client OR the target server, I think that means that using this policy will stop SMB connectivity, which is required for Group Policy among other things. By all means experiment with the policy on local machines where you can turn it off, but deploying to servers via AD is probably The Wrong Choice.

 

Why does blocking 445 stop the reboots?

Because the LSASS vulnerability being exploited causes a reboot. Local infection is not known to cause a reboot, but being hit on port 445 by SASSER will.

 

And a follow-up post explaining a bit more about SMB, Sasser and IPSec Firewalling...

 

 

This is why I like the idea of the firewall being on by default in Windows XP SP2.

 

Hope it helps someone.