Configuration of a local Windows firewall and what and how it can protect against.
Many companies have no or an insufficiently configured local firewall activated on their Windows clients and servers. Windows administrators usually understand why a local client firewall should be implemented; nevertheless, the Windows firewall is often treated like a book with seven seals.
Things don’t look any better in the server landscape. Since servers are located in a data center (or in the basement) and are thus considered protected, those responsible often have not given it any further thought.
In doing so, the Windows firewall can help noticeably in establishing a “first line of defense” or function as a “defense in depth” in the corporate LAN. A local firewall can help protect against many different types of attacks: Information gathering, the spreading of malware, lateral-movement attacks in the LAN, finding and hijacking a notebook on the WLAN of your favorite coffee shop, exploiting new security holes, and more.
The following chapters will explain how easy it is to configure and roll out a local Windows firewall and what it protects against and how. The basic functions will be discussed; however, this article will not cover connection security rules and IPsec.
Table of contents
Note: If Intune is used instead of GPO to manage the clients, you will find a practical guide based on this article that explains how to easily create the same Windows Firewall baseline under Intune. The article is available in German only.
GPO, Copy & Paste, Default Rules
The title already describes what is necessary to get a working Windows Firewall configured and active.
The firewall settings are rolled out across the board via Group Policy Object (GPO). It is recommended to group the targeted systems together. This is because it is basically a watering can principle – individual cases are difficult or at least more costly to cover. For each group, for example, Office clients, a GPO is created, which only contains the firewall configuration for this group. This has several advantages. Using a GPO only for the Windows firewall increases flexibility in case of problems or unique setups. The firewall can be easily disabled via GPO without affecting any other settings. In addition, different device types and users require different firewall settings.
Furthermore, when troubleshooting, the firewall of a specific group can be disabled while other devices remain protected. A test group also makes sense when new rules need to be tested. The GPOs are linked to the corresponding organizational units (OU) and further set up (with filters etc.). In the rest of this example, the article will focus on Windows clients. Servers will be discussed separately.
Figure 1 – GPMC Editor
I The familiar Windows Firewall user interface in the GPO can be displayed under Computer Configuration -> Windows Settings -> Security Settings -> Windows Defender Firewall with Advanced Security. On the right of the display window, the settings dialog is opened by clicking on “Windows Defender Firewall Properties”.
Oneconsult recommends making the following settings for the three profiles:
| Settings | Value |
| Firewall state | On |
| Inbound connections | Block |
| Outbound connections | Allow |
Settings that affect the behavior of the firewall:
| Settings | Value |
| Display a notification | As desired |
| Unicast response | No |
| Apply local firewall rules | No |
| Apply local connection security rules | (not part of this article) |
Settings that affect logging:
| Setting | Value |
| Name | Default path with individual name per profile. For example: %systemroot%\system32\logfiles\firewall\domain-firewall.log |
| Size limit | 32’768 |
| Log dropped packets | Yes |
| Log successful connections | Not configured (or as desired) |
What is still missing are the classic firewall rules that allow or specifically block communication. In the configuration shown here, the outbound rules only play a minor role since outgoing connections are allowed per se. This table can remain empty if nothing specific needs to be blocked.
Insert Rules
To be able to import the most important rules into the new GPO in a simple way, access to a reference device should first be ensured. The Windows Firewall with Advanced Security can be opened via RDP or MMC, and the incoming rules are displayed. These can now be copied and pasted into the view in the GPO. Only the rules with “Core Networking” at the beginning of the name are copied to create a base profile. All other rules are ignored for now. The core rules ensure that basic functions like DHCP or necessary ICMP protocols work. In principle, the GPO could now be rolled out and used – at least for clients.
However, for easier management of devices, especially deployed software, or for other purposes, more rules should either be copied or created. For example, you could enable Remote Desktop for support or open certain ports like RPC for more straightforward configuration. The following principle applies: less is more. Additional rules should be countable on one hand. Furthermore, the rules should only allow what is necessary. They can be restricted by specifying specific profiles, limiting the source IP or source network, or restricting communication to a particular program. If the rules are too lax, the purpose of the firewall is defeated. In general, clients should not be able to reach each other on the network. Exceptions should be approved carefully.
Impact
Of course, being strict about Windows Firewall can lead to unwanted side effects. The most obvious is that by limiting it to very few rules, something will stop working correctly because it will be blocked. Most of the time, however, it’s surprising how few firewall exceptions a client needs to perform the same functions as it did before. If something is still blocked, the following procedure will help: A few power users should be provided with the GPO. If a program is blocked, the power user can notify the Administrator, who can then unblock the program with an additional rule in the GPO.
Somewhat less obviously problematic are programs that configure and use the local firewall. These include, for example, antivirus solutions that also allow firewall management. Often, these do not have their own firewall integrated but control the local Windows firewall. However, in the instructions above, the firewall was configured to ignore local settings and only consider the configuration done via GPO. This is actually a security feature, as local admins or programs can create or change rules during installation. If security software is used and the firewall is configured with it, the configuration via GPO should possibly be omitted.
Server
The server environment can become more complex depending on the situation. If only a few servers are in use, a separate GPO could be created for each server to meet the different requirements. The procedure is the same as for the clients. In addition, the ports for those services offered by the server must be considered in detail. To achieve micro-segmentation in SME environments, Oneconsult has, in the past, defined rules for each server that prohibits incoming connections from the same LAN. Only the domain controller was allowed to authenticate on specific ports.
In larger environments, there are often several servers of the same type, allowing groups with a common firewall GPO. Physical servers must also be taken into account insofar as they are not only used for virtualization and are already well shielded from the rest. If, for example, iSCSI comes into play, access to it must be guaranteed. Since outgoing traffic is generally allowed, no major problems should arise. Nevertheless, it is worth mentioning in this context, especially when working with deny rules.
For the administration of the servers, standard rules for the corresponding ports and protocols should be added to the base profile. For example, for RDP, PowerShell Remoting or Ping. Many MMC snap-ins also need their own ports. All the standard ports for the protocols mentioned are already available and can be copied from the console of an existing system.
A selection is shown in the following screenshot:
When new servers and services are installed, the local firewall can be started during the setup and test phase, and the necessary rules can be copied from there. In part, the rules for installed services are designed to be very lax, which is why it sometimes makes sense to create a new, more specific rule than to copy the existing one. The new GPO should then be applied, and the server should only be put into production after the test.
The best starting point for working with the Windows local firewall is if network segmentation is already in place. This allows GPOs and rules to be kept clear and straightforward. The rest of the work is done on firewalls that act as middlemen between networks. Documentation of the setup is also recommended so that the design and concept are still understandable in a few years.
Protection
The most significant protection offered by a firewall comes from the closed ports that would otherwise be accessible. An attacker who can reach all the other devices from one client is in a much better position to spread further into the network than one who cannot discover any other client in the network apart from the infected one. The ports used to administer the devices, or for code execution are particularly important.
Micro Segmentation
One advantage offered by the local firewall is micro-segmentation. This article assumes that the network is already segmented in principle. As described above, after segmentation, the clients of the same type are still connected to the same LAN but cannot reach each other, thanks to the local firewall.
This principle works the same way for server networks. In a server LAN, servers can be separated from each other as long as they do not need access to other servers for their function. The logon servers are known, and so are any database servers. Therefore, a GPO for the corresponding servers can be created, allowing incoming traffic only from targets that need access. One should concentrate on the corresponding LAN. Accesses from other networks are usually routed through a NAT and run through a firewall in-between segments. This firewall should control access between network segments. For example, when properly configured, users from other networks should have access to the file server but not to its RDP port, as this is filtered at the intermediate firewall (network segmentation). In the LAN, servers should only reach other servers if they have dependencies, and a corresponding rule has been set up in the local firewall (micro-segmentation).
Protection of Mobile Windows Clients
Mobile devices such as notebooks benefit greatly from a functional Windows firewall. On the road in foreign networks (such as Starbucks), a device is exposed to other devices on the same network. A VPN might encrypt traffic from the client to the enterprise or even the Internet. However, it does not prevent the device’s accessibility and visibility on the LAN. With an appropriate firewall configuration, both the visibility and the attack surface can be reduced.
Protection Against Internal Attacks
Windows firewall can also play a protective role against attacks from within. For the reasons already mentioned, it also keeps internal attackers from quickly spreading and reaching high-value targets.
Also to be evaluated internally is the weakening of the firewall through the installation of software. During installation (which is performed as an administrator), additional rules are often installed, which the software “needs”. In most cases, these rules are superfluous, and the program can be executed without restrictions, despite ignored local firewall rules. This behavior is achieved by invalidating locally configured rules via GPO. After this, even local admins cannot set their own rules.
Conclusion
The Windows firewall is basic and easy to understand and configure. It focuses on the LAN environment, can isolate devices, and thus enables micro-segmentation. For clients, in particular, it offers favorable protection in third-party and their own networks. Rules can be copied and pasted from a reference device into the GPOs. The core rules alone are sufficient for a basic profile.
If you have special requirements, you can define your own rules, which are easy to create via the user interface. The mantra “Least Privileges” is essential: As few privileges as possible, as many as necessary.
