2.8.2. Windows Firewall – Part 2
By Val Bakh
In last month’s blog post about Windows Firewall (WF), we introduced network firewalls and host-based firewalls and explained the general principles of their operation. We also became acquainted with WF, its most important general settings, and two types of rules. Now we’ll discuss both types of WF rules and examine their main settings. We will also consider an example scenario that illustrates how the two types of rules work together.
First we’ll discuss the settings that you can configure in connection rules. Let’s open an inbound rule. You can create a custom rule without changing any of its default settings, or you can open one of the existing preconfigured rules. On the General tab, you can enable or disable the rule. An enabled rule comes into effect right away, and a disabled rule is just sitting there doing nothing, waiting to be enabled later when it is needed. An inbound rule targets specified types of inbound traffic and applies a specified action to it. Typically, an inbound rule’s action would be Allow the connection. Other possible actions are Block the connection and Allow the connection if it is secure. The latter works in conjunction with connection security rules.
On the Protocols and Ports tab, you can specify the protocols and ports to which the rule applies. For example, a Web server listens on TCP port 80 for HTTP requests. To enable clients to access the site hosted on this server, you should create an inbound rule to allow TCP traffic to the local port 80 from any remote port. Usually, this rule will be created automatically when Internet Information Services (IIS) or another Web server application is installed. Sometimes you might need to allow traffic associated with a specific application or service, and you might not know exactly which ports or protocols it uses. So, instead of specifying ports and protocols, you can specify the application’s or service’s name on the Programs and Services tab. On the Scope tab, you can specify the IP addresses or DNS names of the sending computers whose traffic the rule will target.
On the Advanced tab, you can specify the profiles (Domain, Private, or Public) and interface types (LAN, remote access, or wireless) to which the rule will apply. There is also an obscure option named Edge traversal, which is, unfortunately, rather poorly documented. At first glance, it might appear that this option simply controls whether traffic that arrives from outside the computer’s LAN should be allowed or blocked; but that function is provided by the rule’s scope. The Edge traversal option exists only in inbound rules and is set to Block edge traversal by default. However, this setting does not cause any inbound traffic to be blocked just because the traffic passed through a firewall or network address translator (NAT) on its way to the local host. Instead, this option applies to only specific types of traffic that use encapsulation in order to successfully traverse a firewall or NAT. One example of a situation where the Edge traversal option matters is DirectAccess. If a DirectAccess client is located on a remote private network behind a NAT, the client uses a technology named Teredo to communicate with its corporate network over the Internet. Teredo encapsulates IPv6 inside IPv4 in such a way that it can pass through NATs. This DirectAccess client should be configured to allow unsolicited inbound traffic from management servers on the corporate network. The corresponding inbound rules should allow edge traversal.
An inbound rule can specify authorized users or computers. If it does, an incoming network packet matches a rule only if the packet has originated from an authorized user or computer. For the packet’s originator to be identified, the packet must arrive through an authenticated connection. Consequently, the rule’s action must be set to Allow the connection if it is secure and at least one suitable connection security rule must exist. Connection security rules cause specified types of network traffic to be authenticated by using specified methods. Additionally, by using Netsh or PowerShell (PS), you can also configure custom IPSec settings, such as security methods for key exchange, also known as Main Mode, or for data integrity and encryption, also known as Quick Mode.
Let’s consider an example that illustrates how connection rules work together with connection security rules. Suppose you have a server that runs a modern version of Windows, such as Windows Server 2012 or Windows Server 2008 R2, and hosts some applications or services. Regular users should be able to access only those applications and services, and you should have unrestricted access to the server. Let’s call this server Srv1.
First of all, you should ensure that WF is enabled on Srv1; by default, it is. If you neglected to verify that WF is indeed on and if it somehow happened to be off, none of the rules that you configured in it would work.
Next, you should configure inbound rules that target the appropriate protocols, ports, applications, or services. Set the rules’ action to Allow the connection because these rules are for regular users and do not require authentication. Well, authentication probably will be required, but only at the application or service level. Those applications and services must have been designed in such a way that different users can be assigned different levels of authority, but that is a completely different story and will transpire after client requests make it through WF.
Now create an inbound rule for yourself and call it Rule4U. You need unrestricted access; therefore, configure the rule to target all ports and protocols and all applications and services. If the rule is just for you, add your user account to the list of authorized users on the Users tab (in Windows Server 2008 R2) or on the Remote Users tab (in Windows Server 2012). If unrestricted access should be allowed only from your administrative workstation, add your computer’s account to the list of authorized computers on the Computers tab (in Windows Server 2008 R2) or on the Remote Computers tab (in Windows Server 2012). If appropriate, do both so that unrestricted access is allowed only to you and only from your workstation. Note that by now the rule’s action should have already been set to Allow the connection if it is secure. Otherwise, you would not be able to select the option that allows you to specify authorized users or computers. Next to this rule action setting on the General tab, there is a button named Customize. Click it, and take a look at the available options. Here you can specify the level of security required by this rule. In our example scenario, authentication alone will suffice. In other situations, you might decide to configure the rule to also require data integrity and, possibly, encryption. There is also an option that, if enabled, would cause this rule to override other rules that block connections allowed by this rule. Normally, block rules (that is, rules with the Block the connection action) win any conflicts with allow rules (that is, rules with the Allow the connection action). The Override block rules option can cause your rule to win conflicts with block rules. You do not need this option in our example scenario, because you are not going to create any block rules.
For Rule4U to work, you should create a suitable connection security rule. The connection security rule should target all IP addresses, ports, and protocols and should specify appropriate authentication settings: whether to request or require authentication on inbound connections, whether to request or require authentication on outbound connections, or whether to allow unauthenticated connections. Depending on the specific requirements, you can configure the rule to use only computer-level authentication, only user-level authentication, or both. The authentication can be performed by using Kerberos V5, NTLM v2, a certificate, or a preshared key (only for computers). Let’s say you configure the rule to require inbound and outbound authentication for both computers and users.
Let’s see how it will all work. On your workstation, create a connection security rule that requests or requires computer and user authentication for inbound and outbound connections. The rule should target all ports and protocols for Srv1’s IP address or DNS name. The two connection security rules—on Srv1 and on your workstation—should have at least one common method for computer authentication and at least one common method for user authentication. When you attempt to connect to Srv1 from your workstation, authentication will succeed and your connection request will then be analyzed against the existing inbound rules. The Rule4U inbound rule will check your computer’s identity against the list of authorized computers, will check your identity against the list of authorized users, and will allow the connection. When you attempt to communicate with other computers, those communications will occur normally because the connection security rule that you have created on your workstation targets only communications to or from Srv1.
If anyone attempts to access Srv1 from another computer and if there is no matching connection security rule on that computer, authentication will fail and Rule4U will not allow unauthenticated access. If there is a suitable connection security rule on the client computer, authentication will succeed, but Rule4U will not allow access from an unauthorized computer or by an unauthorized user. In either case, the connection request will then be checked against other inbound rules, the ones that you have created for regular users and that do not require connections to be secure. The connection request will be allowed only if it matches at least one of those inbound rules.
This example is intended for illustration purposes only and does not discuss some important aspects relevant to operating in an Active Directory Domain Services (AD DS) environment. The WF rules that you have created on Srv1 might prevent it from properly communicating with domain controllers, DNS servers, or perhaps some other servers. To ensure that Srv1 can properly participate in AD DS, you might need to create additional inbound rules and possibly connection security rules.
To summarize what we’ve covered in this blog post, we examined the settings available in connection rules and discussed their purposes. Then we described an example scenario and created the necessary connection and connection security rules that work together to implement the requisite functionality.
Are you studying for a Microsoft certification exam? Try our Microsoft practice exams and Microsoft practice lab demos!