Well the recent resurfacing of the LAND attack [secunia.com] has proven a good enough incentive to revisit security on the server.

Every system administrator knows that security is an ongoing fight. You build the box, you go configure and secure (principle of least attack surface applies) and then you review and re-implement security over the life of the machine.

In this case, Windows XP SP2 and Windows 2003, both with all patches, can be susceptible to an attack where rogue data packets to the computer can cause the computer to lock up, or run at 100% CPU usage for unusually large amounts of time. One packet can cause 30 seconds of 100% CPU, so it's possible for a single person with a dialup account to take a server offline.

NOT HAPPY MICROSOFT!

This attack originally appeared in 1997 and was believed extinct. Somehow, somewhere, in the change from service pack 1 to service pack 2 on XP, and from Windows 2000 to Windows 2003 on the server, the fault was re-introduced.

Now, even Microsoft developers are human. The problem we have here is that the testing of past attacks against current code seems to have lapsed in some fashion.

So what did we do today?

• The first mitigating factor for the revised LAND attack is to (re)-harden the TCP/IP stack. Microsoft provide some handy hints [microsoft.com] for Windows 2003 here. Similar settings [microsoft.com] exist for Windows 2000.
• Settings in use on our server include:
  • DisableIPSourceRouting (REG_DWORD): 1
  • EnableAddrMaskReply (REG_DWORD): 0
  • EnableDeadGWDetect (REG_DWORD): 0
  • EnableICMPRedirect (REG_DWORD): 0
  • EnableICMPRedirects (REG_DWORD): 0
  • KeepAliveTime (REG_DWORD): 0x00015f90
  • SynAttackProtect (REG_DWORD): 1
  • TcpMaxConnectResponseRetransmissions (REG_DWORD): 2
  • TcpMaxDataRetransmissions (REG_DWORD): 3
  • TcpMaxHalfOpen (REG_DWORD): 500
  • TcpMaxHalfOpenRetried (REG_DWORD): 400
  • TcpMaxPortsExhausted (REG_DWORD): 5
  • TcpTimedWaitDelay (REG_DWORD): 120
• Disabled NetBIOS on external interfaces ... again. This one is interesting - something or someone has apparently reenabled NetBIOS. Not sure who, but it won't make it through the rest of the network anyway.
• Configured a new IPSec policy to allow only the right protocols (well, ports really, this is not SPI or a layer 7 firewall - yay ISA, that's the next purchase!) from the outside world, or everything if you're internal.

So what's the end result?

We've achieved a few things. Firstly, the server now does not respond to packets sent to known listening ports unless the IPSec policy allows it. So for example RDP is permitted internally only. HTTP is permitted to the outside world (otherwise you wouldn't be reading this!)

Secondly, the server should theoretically be able to handle the next script kiddie who sends a SYN attack our way. I'm not angling to have it tested, but theoretically at least the settings are optimal and hopefully such an attack shouldn't give the server conniptions.