Windows Server 2019 – Windows Defender Firewall – no laughing matter

How to Activate Windows Server 2019

Let’s play a word association game. I will say something, and you say the first word that comes to mind.

Network security.

Did you say firewall? I think I would have. When we think of securing our devices at the network level, we think of perimeters. Those perimeters are defined and protected by firewalls, mostly at a hardware level, with specialized networking devices made to handle that particular task in our networks. Today, we are here to talk about another layer of firewalling that you can and should be utilizing in your environments. Yes, we are talking about the Windows Firewall. Stop laughing, it’s rude!

It is easy to poke fun at the Windows Firewall based on its history. In the days of Windows XP and Server 2003, it was pretty useless, and caused way more headaches than it solved. In fact, these feelings were so common that I still today find many companies who completely disable the Windows Firewall on all of their domain-joined systems as a matter of default policy. If you ask them, there is usually no specific reason they are doing this—it’s always been this way or it’s in our written security policy are standard replies. This is a problem, because the Windows Defender Firewall with Advanced Security (WFAS) that exists in the Windows OSes of today is much more robust and advanced than ever before, and can absolutely be used to enhance your security architecture. I would go as far as to say that it is entirely silly to disable WFAS on a current OS, unless you have a very good, very specific reason to do so.

Three Windows Firewall administrative consoles

First, it is important to know that there are three different consoles from which you can configure Windows Firewall settings. Two of these consoles are redundant of each other, and the third is much more capable than the others. Let’s take a quick look at each one.

Windows Defender Firewall (Control Panel)

When trying to launch any application or setting in Windows Server 2019, it is usually most efficient to simply click on the Start button, and then type a word relating to the task you are trying to accomplish. In my case, I clicked on Start and typed the word firewall. The best match option that was provided first in my search results was Windows Defender Firewall, so I went ahead and clicked on that.

Interestingly, this link opens the Windows Firewall configuration console from inside Control Panel, the old-school way of doing system settings. This console is still online and fully capable of manipulating basic firewalling functions, such as enabling or disabling the Windows Firewall, but since this tool resides inside Control Panel, we have to assume that this is actually not the tool which Microsoft intends for us to utilize. Remember, all new configuration capabilities have been migrated to the Windows Settings screens, rather than the old Control Panel:

Firewall & network protection (Windows Security Settings)

While the Control Panel-based tools were always the proper place to make these changes in past versions of the OS, we already know that there are many Windows Defender options stored inside Windows Settings. Could it be the case that there are also Windows Defender Firewall configuration settings stored inside the Windows Security section of Settings?

Yes, there definitely are. Open up Windows Settings and click on Update & Security, then on Windows Security. You’ve been here before—this is the screen that gives a quick summary of the Windows Defender components. Sure enough, there is one here called Firewall & network protection. Click on that button, and you will be taken into a new configuration platform for the Windows Firewall functions that did not exist in earlier versions of Windows Server:

Clicking on any of the links provided here will open additional configuration options. For example, if you wanted to quickly enable or disable particular firewall profiles (we will learn about those shortly), you could click on the profile you want to configure, such as the Domain network profile, and from there easily turn off the firewall for this networking profile. Many companies disable the Domain network profile on their machines, so that the firewall is not protecting traffic that happens inside a corporate LAN network.

While disabling the firewall is generally a bad idea, sometimes it is required to fit your business model:

The firewall configuration screen available inside Windows Settings is a good place to make simple, overhead decisions about the Windows Defender Firewall, but this interface is limited in capabilities. For any real utilization of firewall functionality or configuration….

Windows Defender Firewall with Advanced Security (WFAS)

If you are anything like me, you won’t be satisfied with this information and will want to see what is going on under the hood, and so you will want a little more information than the basic Windows Firewall tools alone can give you. You can either click on one of the Advanced settings links shown in previous screenshots, or simply open Command Prompt or a Start | Run prompt and type wf.msc. Either of these functions will launch the full WFAS administration console:

Here you can see much more in-depth information about the activity and rules that are in play with the Windows Firewall, and make more acute adjustments in your allowances and blocks. There is also a Monitoring section where you can view actively engaged rules, including Connection Security Rules. This is an important section because it highlights the fact that WFAS does much more than block network traffic. It is not only a firewall, it is also a connectivity platform. If you plan to utilize IPsec for encryption of network traffic, whether it be native IPsec inside your network or through the remote access technology DirectAccess, you will see rules populated in this section that are the definitions of those IPsec tunnels. Windows Firewall is actually responsible for making those encrypted connections and tunnels happen. This is way more advanced than the Windows Firewall of yesteryear.

Three different firewall profiles

When any NIC on a computer or server is connected to a network, the Windows Firewall will assign that connection one of the three different profiles. You have probably interfaced with this decision-making process before without even realizing it. When you connect your laptop to the Wi-Fi at your local coffee shop, did Windows ask you whether you were connecting to a home, work, or public network? This is your Windows Firewall asking you which profile you would like to assign to the new network connection. The reason that you can assign NICs and network connections to different firewall profiles is that you can assign different access rules and criteria for what is or is not allowed over those different profiles. Effectively, it is asking you how much do you trust this network? For example, when your laptop is connected to the corporate network you can probably be a little bit more lax than when that same laptop is connected at a hotel across the country. By assigning more intense firewall rules to the profile that is active when you are in the hotel, you build bigger walls for attackers to face when you are out working on that public internet. Let’s take a look at the three different types of profiles that are available, with a quick description of each:

  • Domain Profile: This is the only one that you cannot choose to assign. The Domain Profile is only active when you are on a domain-joined computer that is currently connected to a network where a domain controller for your domain is accessible. So, for any corporate machine inside the corporate network, you can expect that the Domain Profile would be active.
  • Private Profile: When connecting to a new network and you are prompted to choose where you are connected, if you choose either Home or Work, that connection will be assigned the Private Profile.
  • Public Profile: When prompted, if you choose Public, then of course you are assigned the public firewall profile. Also, if you are not prompted for some reason, or if you do not choose an option at all and simply close the window that is asking you what to assign to your new connection, this Public Profile will be the default profile that is given to any connections that do not have a different profile already assigned. In the more recent versions of Windows (particularly in Win10), you don’t usually get the prompt asking what kind of a network it is; instead you get a prompt asking whether or not you want to allow your computer to communicate with other devices on the new network. Effectively, this is still the same prompt, and the decision you make at that prompt will assign your connection to either the public or private firewall profile.

Each network connection gets assigned its own profile definition, you could certainly have more than one firewall profile active at the same time on the same system. For example, my RA1 server is connected to both the corporate network as well as the public internet. Inside WFAS, you can see that both the Domain Profile and Public Profile are active:

Alternatively, if you open up Network and Sharing Center on this server, we can also see the profiles listed here, and you can easily tell which NIC is using which profile:

Building a new inbound firewall rule

Now we know that the real meat and potatoes of the Windows Firewall is inside the WFAS console, so let’s use WFAS to build ourselves a new rule. On this RA1 server, I have enabled RDP access so that I can more easily manage this server from my desk. However, by turning on RDP I have now allowed RDP access from all of the networks on this server. That means I can RDP into RA1 from inside the network, but I can also RDP into RA1 from the internet, since this is a remote access server and happens to be connected straight to the internet. This is a big problem, because now any yahoo on the internet could potentially find my server, find the RDP login prompt, and try to brute force their way into RA1.

To alleviate this problem, I want to squash RDP only on my external NIC. I want it to remain active on the inside so that I can continue to access the server from my desk, but is there an easy way inside WFAS to create a firewall rule that blocks RDP access only from the outside? Yes, there certainly is.

Open up wf.msc in order to launch the Windows Defender Firewall with Advanced Security, and navigate to the Inbound Rules section and you will see all of the existing inbound firewall rules that exist on this server (there are many rules listed here even if you have never visited this console before, these rules are installed with the OS). Right-click on Inbound Rules, and choose New Rule…. This launches a wizard from which we will create our new firewall rule. The first screen is where we identify what kind of a rule we want to create. You can create a rule that modifies traffic for a particular program, or you can look through a list of Predefined protocols. However, I like knowing exactly what my rule is doing because of the way that I defined it, not because of a pre-existing protocol definition, and I know that RDP runs over TCP port 3389. So, I am going to choose port on this screen, and after I click on Next, I will define 3389 as the specific port that I want to modify:

Our third step is to decide whether we want to allow or block this particular port. There is a third option listed about only allowing the connection if it is authenticated by IPsec, which is a powerful option, but necessitates having IPsec established in our network already. Because of that requirement, this option doesn’t apply to most people. For our example, we already have RDP working, but we want to block it on one of the NICs, so I am going to choose Block the connection:

We don’t want to block RDP for all of the NICs, though, so this next screen is very important. Here we need to reference back to our knowledge about those firewall profiles we talked about. Remember that internal NICs connected to our domain network will have the Domain Profile assigned to them. But any NICs that are not connected to an internal network where a domain controller resides will have either Public or Private profiles active. That is the knowledge we need to employ on this screen. If we want to disable RDP only on the external NIC, we need this rule to be active for only the Private Profile and Public Profile. In fact, in looking back at the screenshots we already took, we can see that the external NIC is assigned the Public Profile specifically, and so we could check only the Public checkbox here and RDP would then be blocked on the external NIC. But in case we add more NICs to this server in the future over which we want to make sure RDP access is not possible, we will leave both Public and Private checked, to ensure better security for the future. Make sure that you uncheck the Domain profile! Otherwise you will block RDP access completely, and if you are currently using RDP in order to connect to this server, you will kick yourself out of it and be unable to reconnect:

And now we simply create a name for our new rule, and we are done! Our ability to RDP into this server from the internet has immediately been disabled, and we can rest much easier tonight.

Creating a rule to allow pings (ICMP)

Very often I find myself needing to create either an allow or a block rule for ICMP. In other words, I often find myself needing to adjust the firewall on servers in order to enable or disable their ability to reply to ping requests. You probably noticed with newer server OSes that it is pretty normal for the firewall to automatically block pings (ICMP) out of the box. This is a problem for environments where ping is the standard method for testing whether an IP address is consumed or available. You may be laughing, but, trust me, there are still plenty of IT administrators out there that don’t keep track of which IP addresses they have used inside their networks, and when faced with the need to set up a new server and decide what IP address to give it, they simply start pinging IP addresses in their network until they find one that times out! I have seen this so many times. While this is obviously not a good way to manage IP addresses, it happens. Unfortunately, this method encounters big problems, because most new Windows installations are designed to block ICMP responses out of the box, which means that you may ping an IP address and receive a timeout, but there could actually be a server running on that IP address.

So, getting back to the point. You may have a need to enable ICMP on your new server, so that it responds when someone tries to ping it. When we need to create a new rule that allows pings to happen, we set up a rule just like we did for RDP, but there is one big catch. On that very first Rule Type screen when creating the new rule where you have to identify what kind of rule you are creating, there are no options or predefinitions for ICMP. I find this strange because this is a very common type of rule to put into place, but alas choosing ICMP from the drop-down list would just be too easy. Instead, what you need to do is create a new inbound rule just like we did for RDP, but at the very first screen for Rule Type, make sure you select the option that says Custom.

Next, leave the option selected to define this rule for All programs. Click next again, and now you have a drop-down box called Protocol type. This is the menu where you can choose for your new rule to manipulate ICMP traffic. As you can see in the following screenshot, you can choose ICMPv4 or ICMPv6, depending on what your network traffic looks like. My test lab is IPv4-only, so I am going to choose ICMPv4:

For the rest of the ICMP rule creation, follow the same procedures outlined when we created the RDP rule, choosing to either allow or block this traffic, and for which firewall profiles. Once finished, your new ICMPv4 rule is immediately enacted, and if you have configured an Allow rule, your new server will now successfully respond to ping requests:

If ever you need to modify a rule or dig into more advanced properties of a firewall rule, back at the Inbound Rules screen you can right-click on any individual firewall rule and head into Properties. Inside these tabs, you have the opportunity to modify any criteria about the rule. For example, you could accommodate additional ports, you could modify which firewall profiles it applies to, or you could even restrict which specific IP addresses this rule applies to by use of the Scope tab.

This enables you to apply your firewall rule only to traffic coming or going from a specific portion of your network, or a certain subset of machines. For example, here I have modified my Scope tab to reflect that I only want this firewall rule to apply to traffic that is coming in from the 192.168.0.0/16 subnet:

Managing WFAS with Group Policy

Managing firewall rules on your servers and clients can be a huge step toward a more secure environment for your company. The best part? This technology is enterprise class, and free to use since it’s already built into the OSes that you use. The only cost you have associated with firewalling at this level is the time it takes to put all of these rules into place, which would be an administrative nightmare if you had to implement your entire list of allows and blocks on every machine individually.

Thank goodness for Group Policy Object (GPO). As with most settings and functions inside the Microsoft Windows platform, setting up a firewall policy that applies to everyone is a breeze for your domain-joined machines. You can even break it up into multiple sets of policies, creating one GPO that applies firewall rules to your clients, and a separate GPO that applies firewall rules to your servers, however you see fit. The point is that you can group many machines together into categories, create a GPO ruleset for each category, and automatically apply it to every machine by making use of the GPO’s powerful distribution capabilities.

You are already familiar with creating GPOs, so go ahead and make one now that will contain some firewall settings for us to play with. Link and filter the GPO accordingly so that only the machines you want to have the settings will actually get them. Perhaps a good place to start is a testing OU, so that you can make sure all the rules you are about to place inside the GPO work well together and with all of your other existing policies, before rolling the new policy out to your production workforce.

Once your new GPO is created, right-click on it from inside the Group Policy Management Console and click on Edit…:

Now that we are looking at the insides of this new GPO, we just need to figure out where the correct location is in order for us to create some new firewall rules. When you are looking inside the rules on the local machine itself, everything is listed under a Windows Defender Firewall with Advanced Security heading, and that is located at Computer Configuration | Policies | Windows Settings | Security Settings | Windows Defender Firewall with Advanced Security | Windows Defender Firewall with Advanced Security:

As you can see, this is also the place to go when you want to make sure that particular firewall profiles, or the Windows Firewall as a whole, are specifically turned on or off. So, this is the same place that you would go if you wanted to disable the Windows Firewall for everyone. By clicking on the Windows Defender Firewall properties, link shown earlier, you can determine the status of each firewall profile individually:

Once you are finished setting your profiles according to your needs, click on OK, and you find yourself back at the WFAS part of the GPO. Just like inside the local WFAS console, you have categories for Inbound Rules and Outbound Rules. Simply right-click on Inbound Rules and click on New Rule… in order to get started with building a rule right into this GPO. Walk through the same wizard that you are already familiar with from creating a rule in the local WFAS console, and when you are finished, your new inbound firewall rule is shown inside the GPO.

This firewall rule is already making its way around Active Directory, and installing itself onto those computers and servers that you defined in the policy’s links and filtering criteria:

Comments are closed.