Windows Server 2008 R2 Firewall Security
Best practices for enabling a firewall in a production environment
Today’s security model is all about layers. If your network suffers a breach, security layers can at least limit the scope of the attack or slow down the hacker. In my experience, Windows Server 2008 R2 and Windows Server 2008 are the first versions of Windows Server in which you can successfully keep your firewall enabled and still have the server work in a production environment. The Microsoft Management Console (MMC) Firewall with Advanced Security snap-in is key to this capability.
Firewall Profiles
There are three different Windows Firewall profiles that can be configured with a Server 2008 R2 firewall. Only one of these profiles can be active at a time.
1. Domain profile—This profile is active when the server is connected to an Active Directory (AD) domain via an internal network. This is the profile that’s typically active, because most servers are members of an AD domain.
2. Private profile—This profile is active when the server is a member of a workgroup. Microsoft recommends more restrictive firewall settings for this profile than for the domain profile.
3. Public profile—This profile is active when the server is connected to an AD domain via a public network. Microsoft recommends the most restrictive settings for this profile.
When you start the Firewall with Advanced Security snap-in, you can view which firewall profile is active. Although Microsoft recommends that you can have different security settings based on the firewall profile, I typically configure the firewall as if a perimeter firewall doesn’t exist. With this approach, if any ports are accidentally opened on perimeter firewalls, Server 2008’s Windows Firewall will block the traffic. Just as with previous versions of Windows Firewall, all inbound connections are blocked and all outbound connections from the server are allowed by default in Server 2008 R2 (as long as there’s no existing Deny rule).
With these settings, my organization’s firewall configuration leans toward a public profile environment. When we create a rule, we make it active for all three profiles. By using a firewall configuration that’s consistent across all three domain profiles, we don’t have to worry about exposing any unwanted ports in case the Windows Firewall profile changes.
IPsec and Domain Isolation
You can implement domain isolation by using Windows Firewall’s IPsec feature. Domain isolation prevents the communication of a non-domain computer from connecting to a computer that’s a domain member. When communication is established between two domain members, you can configure the firewall to encrypt all traffic between the two computers with IPsec. This configuration can be useful in an environment in which you have guests on the same network but you want to prevent them from accessing computers that are part of a domain. It can be used as an alternative or in addition to Virtual LANs (VLANs). For more information about domain isolation with IPsec tunnels, see the Microsoft TechNet article “Domain Isolation with Microsoft Windows Explained.”
Leave the Firewall Enabled
I suggest leaving the firewall enabled when Server 2008 R2 is first installed. Most applications are now smart enough to automatically open the necessary port on the firewall when they’re installed, which eliminates the need to manually open inbound ports on the server. One of the main reasons to have the firewall up during installation is that it protects the OS before you have the chance to apply the latest updates.
The firewall is well-integrated with Server Manager’s roles and features. When a role or feature is added on the server, the firewall automatically opens the necessary inbound ports. SQL Server uses the default port of TCP 1433. Therefore, you must manually create an inbound rule that allows TCP port 1433 on the firewall for SQL Server. (Alternatively, you can change the default.)
Creating Inbound Rules
If you leave the firewall enabled, you’ll probably need to manually create an inbound firewall rule at some point. Fortunately, there are quite a few rules that are created but disabled by default for many popular Windows applications.
Before creating a rule, check to see whether a rule was already created that will allow the desired inbound traffic to pass. If you find an existing rule, you can simply enable the rule and possibly change the default scope. If you don’t find an existing rule, you can always create one from scratch.
Select Administrative Tools from the Start menu, then select Windows Firewall with Advanced Security to start the Firewall with Advanced Securitysnap-in. For illustration purposes, I’ll explain how to create a rule to allow inbound SQL Server traffic on TCP port 1433 from a Microsoft Office SharePoint Server front-end server.
Right-click Inbound Rules and select New Rule. As Figure 1 shows, you can select Program, Port, Predefined, or Custom for the rule type. I typically select Custom, because this option prompts you to enter a scope for the rule. Click Next to continue.
Figure 1: Creating a new inbound rule type
In the next dialog box, which Figure 2 shows, you can specify a program or services that the rule will match. In my example, I selected All programs so that traffic will be controlled by the port number.
Figure 2: Specifying a program for a new inbound rule
As Figure 3 shows, I then selected TCP for the protocol type, and I selected Specific Ports from the Local port drop-down menu and specified port 1433, which is the default port for SQL Server. Because remote ports are dynamic, I selected All Ports.
Figure 3: Specifying a protocol and ports for a new inbound rule
In the Scope dialog box, which Figure 4 shows, I specified the local IP address of 192.168.1.11 and the remote IP address of 192.168.1.10, which is the IP address of my organization’s SharePoint front-end server. I strongly recommend specifying a scope with every rule, in case the server is accidentally exposed to unwanted subnets.
Figure 4: Specifying local and remote IP addresses in a new inbound rule’s scope
In the Action dialog box, which Figure 5 shows, I selected Allow the connection because I want to allow inbound traffic to pass for SQL Server.
Figure 5: Specifying the action to take when a connection matches the condition
in a new inbound rule
Alternatively, you can allow traffic to pass only if it’s encrypted and secured with IPsec, or you can block the connection. Next, you need to specify the profile(s) for which the rule will apply. As Figure 6 shows, I selected all the profiles (which is a best practice).
Figure 6: Specifying profiles for which a new inbound rule will apply
Finally, use a descriptive name for the rule, specifying the allowed service, scope, and ports, as Figure 7 shows. Using a descriptive name makes it easier to identify what a rule does. Click Finish to create the new inbound rule.
Figure 7: Naming a new inbound rule
Creating Outbound Rules
By default, all inbound traffic is blocked and all outbound traffic is allowed on all three firewall profiles (i.e., domain, public, and private). If you use the default settings, you don’t need to open any outbound ports. Alternatively, you can block outbound traffic—but then you must open up the necessary outbound ports.
Creating outbound rules is similar to creating inbound rules, except the traffic flow is reversed. You can use the Firewall with Advanced Security snap-in to block outbound traffic on specific ports if the server becomes infected with a virus and attempts to attack other computers on specific ports.
Managing Firewall Configuration
In addition to the Firewall with Advanced Security snap-in, you can use Netsh commands to create firewall rules. For more information about using Netsh to configure Windows Firewall, see the article “How to use the ‘netsh advfirewall firewall’ context instead of the ‘netsh firewall’ context to control Windows Firewall behavior in Windows Server 2008 and in Windows Vista.”
You can also use Group Policy to control the configuration of the firewall. One of the easiest ways to push out a firewall rule with Group Policy is to use theFirewall with Advanced Security snap-in to create the rule, export it, and import it into the Group Policy Management Editor. Then you can use Group Policy to push out the rule to the appropriate computers. For more information about how to use Group Policy to control the Windows Firewall, see the article “Best Practice: How to manage Windows Firewall settings using Group Policy.”
Troubleshooting
If you’re having difficulty connecting to a server that has Windows Firewall enabled, you can enable logging to determine if specific ports are being blocked. By default, firewall logging isn’t enabled. To enable firewall logging, right-click Windows Firewall with Advanced Security and select Properties. Click the Active Profile tab (Domain, Private, or Public) under the Logging section, and click Customize.
By default, the firewall log is located in C:\Windows\system32\LogFiles\Firewall\pfirewall.log. When troubleshooting connectivity problems, I typically log only the dropped packets, as Figure 8 shows; otherwise, the logs can fill up with a lot of successful connection information. Open the log with Notepad to determine if any packets are getting dropped by the firewall.
Figure 8: Enabling firewall logging for the domain profile
Another troubleshooting tip is to temporarily disable the firewall to see if doing so solves the connectivity problem. If you can establish a connection with the firewall disabled, open a command prompt and issue the command Netstat -AN to view the connection details. As long as the application is connecting with TCP, you can look at the local and foreign IP addresses with anEstablished state to determine the application’s port(s). This can be especially helpful when you’re not sure which port(s) a particular application uses to establish a connection.
The Windows Sysinternals tool TCPView is like Netstat on steroids. This tool provides detailed TCP connection information and can be helpful when troubleshooting connectivity issues.
Happy Firewalling
Server 2008 R2 and Server 2008 are the first versions of Windows Server that make it possible to keep the firewall enabled in a production environment. The trick is to leave the firewall enabled during installation of any programs on the server. This practice lets you test the server’s connectivity before it goes into production. Use the Log dropped packets option to determine if any packets are getting dropped by the firewall. If you decide that you want to enable the firewall on the server after it’s been in production for a while, I suggest that you establish a lab environment first to determine which ports are necessary to open on the firewall. Happy firewalling!
Note
Important
VM.Blog. 