As a Windows server administrator it is particularly important to secure your servers by any and all means at your disposal. We all know that Microsoft products are especially vulnerable to malware, due in part to their overwhelming prevalence in desktop computing. Hopefully most administrators are not going to be browsing the Web on their Windows file server, so chances are that malware is not going to get a hold of a server via user action on the desktop. The attack is going to come from the network, and the built-in Windows firewall can help.
Beginning with Windows Server 2003 SP1, the built-in firewall comes pre-installed. It is free, easy to setup, and can be configured using group policy. Lowering your attack surface by locking down remote desktop (RDP) is a prime example and a good place to start. Restricting the RDP port (3389) so that it is only available to subnets or IPs used by administrators takes only seconds.
To begin using the Windows firewall, open the control panel and double-click on the Windows Firewall icon. If you’re prompted with a message asking to start the necessary service, click yes. From this interface you can enable/disable the firewall as well as add exceptions. The Windows firewall allows the administrator to unlock individual ports or executables. When an executable is unlocked it will be able to listen on any port that it opens. When adding a new exception, be sure to click on the “Change scope…” button to set the appropriate trusted IP space. For any command line fanatics out there you can also use netsh:
netsh -c firewall
The most difficult piece of enabling the firewall on a server is figuring out what needs to be unlocked. The Windows firewall comes with some built-in exceptions that can be enabled, but if you go much beyond file services you will have to determine which ports or executables need to be unlocked. The easiest way to do this is by using the netstat command. Run the following from a command prompt:
netstat -a -b -n
This will return a list of all ports that are active or listening on your system. The -a switch ensures that all of the listening ports are displayed and -b shows the executables that opened each port. This can be very useful when trying to track down which executable(s) needs to be unlocked for a particular application. By default netstat will hide the actual port number from you if it “knows” what it is. The -n switch forces netstat to show the actual port number.
Group Policy Management
One of the key advantages of the Windows firewall is its ability to be configured through group policy. For large environments this feature is essential to administrator sanity.
Before doing any sort of group policy configuration you will want to make sure the Group Policy Management console is installed on your workstation. If you don’t see Group Policy Management in Control Panel -> Administrative Tools then you can download it here (search for “group policy management”).
Using the Group Policy Management interface, browse to the Active Directory organizational unit (OU) containing your servers. Right click on the OU and create or link an existing GPO. Open the GPO and navigate to the following folder:
Computer Configuration/Administrative Templates/Network/Network Connections/Windows Firewall
From here there are two sub-folders, Domain Profile and Standard Profile. It is extremely important to make sure that your firewall policy settings match in both of these folders. Under most circumstances the Domain Profile will be used, but if someone logs onto the server with a local user account then the server will switch to its Standard Profile settings. If the Standard Profile settings are not configured then the firewall will essentially turn itself off!
Browse through the list of available settings and configure the GPO for your server environment. There are a few things to keep in mind. First, once you choose a setting through group policy you will not be able to change the same setting on an individual server. For example, by unlocking RDP for a specific subnet via group policy you will not be able to add additional trusted subnets on a server-by-server basis. Second, don’t create a separate GPO for each server; try to group them together as much as possible. Creating a base firewall GPO that has exceptions for backup, anti-virus, etc. is optimal. Add server specific exceptions on the server itself, this way when you change anti-virus vendors (and someday you will) only one GPO has to be modified.
Adding exceptions for executables through group policy can be tricky. Use the “Windows Firewall: Define program exceptions” setting to unlock specific executables. Here are a few examples:
%programfiles%SymantecLiveUpdateLuComServer.EXE:192.168.1.1/24:enabled:GPO Policy for LuComServer.exe
%programfiles%Symantec AntiVirusRtvscan.exe:192.168.1.1/24:enabled:GPO Policy for Rtvscan.exe
%systemdrive%A286B00A-C3DE-414F-A96A-2BD238948D88MsMgmtAuxiliary.exe: 192.168.1.100:Enabled:MOM 2005 MsMgmtAuxiliary
The top two exceptions will allow Symantec Anti-Virus to communicate with its parent server, and the bottom exception allows the Microsoft Operations Manager (MOM) agent to function correctly. In fact, it even allows the MOM agent to be installed remotely. It is a good idea to store your list of program exceptions in a separate text file of some sort. This will save you a few keystrokes later on because they cannot be extracted from the GPO.
The built-in Windows firewall is a quick, easy, and cheap way to protect your servers and reduce your attack surface. Add in the ability to control settings via group policy and it’s really a no-brainer. With a few clicks you will be on your way to a more secure server environment.