How Host-Based Firewalls Work: Architecture, Rules, and Alerts

As a security tool, firewalls have proved their effectiveness in protecting networks from malicious actors. Properly configured firewalls can significantly reduce the risk of getting infected with malware or leaking sensitive data.

This article describes how modern firewalls analyze network traffic. Host-based firewalls are a must-have security solution. We provide a close look at the host-based firewall architecture and explain the principles behind host-based firewalls with real-life examples.

How modern firewalls analyze network traffic

Host-based firewalls are installed on host computers with the purpose of controlling network traffic that goes through them. Modern host-based firewalls perform multiple levels of traffic analysis, which include packet analysis at various layers of the open systems interconnection (OSI) model. Basic filtering is performed at the Network and Transport layers. A firewall checks the MAC and IP addresses and packet source and destination ports to determine if a packet is allowed to pass. More advanced checks are made to analyze packet sequences using variations of the stateful filters approach. A stateful filter holds a series of packets to determine if the whole session is malicious and validate if a packet belongs to any real connection. Finally, Application layer packet analysis is done to validate the packet’s payload.

Nowadays, firewalls are usually integrated with antivirus software, so there’s even more logic involved in packet analysis to defend the host against trojans, rootkits, and other types of viruses.

Firewall architecture for Windows

There are multiple ways to monitor network traffic in Windows. However, the generic firewall architecture for the Windows operating system consists of the following components:

1. Driver
2. Service
3. UI application

1. Firewall driver

The traditional way to monitor a network was to implement a Network Driver Interface Specification (NDIS) driver, which registers a protocol stub. The new network protocol is registered in the system so that the operating system relays all network traffic through the protocol handler functions in the driver.

The modern way to monitor a network is to register the Windows Filtering Platform sublayer in the driver. This is how the driver embeds into the Windows Firewall architecture to provide additional filtering.

A firewall might also want to detect if there’s some other protocol registered over its own, so it’s necessary to monitor protocol registration too.

When traffic is passing through the driver, the firewall decides whether to let it through. If an anomaly is detected, the firewall should notify the user. But if the firewall just provides raw information about some specific outgoing packet coming to some port then it provides no meaning to the user because there’s no context.

The context that the user cares about is the process that sent this packet, the module which initiates the process, and the file path of the module. So a modern firewall needs to monitor operating system events from the start until the end of processes, loading and unloading modules, and be able to link this information to data at the moment the packet is filtered in the driver. Thus, the firewall driver also has to register notification handlers for system events.

Firewall rules

The next thing that a firewall must have is rules. Firewall rules specify which traffic from which processes must be blocked and which must not be blocked. Firewall rules can be created by users to tell the software to make one of the following decisions for both inbound and outbound traffic that match the rule:

• Allow the connection
• Allow only those connections that are secured through Internet Protocol security (IPsec)
• Block the connection

For instance, a firewall can have rules allowing all traffic from a trusted network or allowing HTTP or SSH connections from any IP address or blocking all incoming TCP and UDP traffic.

This set of rules can be quite large depending on the needs of computers, users, programs, and services. Thus, rules are usually provided to the driver by a component of the firewall that’s implemented as a Windows service.

2. Firewall service

A Windows service also controls the filter driver that can temporarily disable filtering or update the rules in the runtime. Sometimes, traffic blocking and filtering logic is placed into the service instead of within the driver. In this case, the driver serves as an event provider and the service decides whether to block traffic and then passes this decision to the driver. Using this approach, it becomes much easier to test business logic since the business logic is running in user mode.

If there are too many requests from the driver to the service to make a decision, however, the service can become a bottleneck to the whole operating system. This can happen because the user mode process that makes decisions doesn’t have dedicated CPU quants. So the firewall service may be preempted and the driver might not get a decision in time to release the traffic it’s keeping on hold. This may slow down traffic and potentially put the system into a deadlock.

3. Firewall UI application

Finally, the firewall requires a user interface to display alerts and let users edit rules. The need for a separate application to display notifications appears because of the firewall’s ability to filter traffic even if the UI is closed, which is achieved with the service process. Also, it’s harder to terminate a Windows service process than a regular Windows application, which is precisely what a UI is.

Below, we consider several firewalls architecture examples in order to understand how these architectures can protect against malware.

Real-life examples of firewall architectures

For our analysis of firewall architectures, we chose two applications: ZoneAlarm Free Firewall 2018 and Comodo Free Firewall. Both of these firewalls have all the components of the typical Windows firewall architecture discussed above.

ZoneAlarm Free Firewall 2018

ZoneAlarm Free Firewall 2018 is a personal firewall solution for all Windows platforms. This firewall can hide open ports, identify suspicious traffic, and disable malicious programs. In order to understand how it works, let’s look closer at its main architectural components.

Using the Wincheck tool, which analyzes changes made to Windows Kernel components, we find the following lines:

Export addr C:\Windows\system32\drivers\NDIS.SYS.NdisCloseAdapter patched by \SystemRoot\System32\drivers\vsdatant.sys !
Export addr C:\Windows\system32\drivers\NDIS.SYS.NdisDeregisterProtocol patched by \SystemRoot\System32\drivers\vsdatant.sys !
Export addr C:\Windows\system32\drivers\NDIS.SYS.NdisOpenAdapter patched by \SystemRoot\System32\drivers\vsdatant.sys !
Export addr C:\Windows\system32\drivers\NDIS.SYS.NdisRegisterProtocol patched by \SystemRoot\System32\drivers\vsdatant.sys !

Process notifiers:

[9] 8EB383BC SystemRootSystem32driversvsdatant.sys

Thread notifiers:

[1] 8EAE9B06 SystemRootSystem32driversvsdatant.sys

Image notifiers:

[1] 8EAE973C SystemRootSystem32driversvsdatant.sys

Registry notifiers:

[2] 8EB38A3E SystemRootSystem32driversvsdatant.sys

And by examining the import table of vsdatant.sys via DumpBin, we find that it uses NDIS APIs like NdisRegisterProtocol, NdisAllocatePacket, and NdisCopyFromPacketToPacket.

So ZoneAlarm uses the vsdatant.sys driver, which uses the NDIS traffic filtering approach and sets hooks and handlers in the system.

Using the Process Explorer by Mark Russinovich, we can find and examine the ZoneAlarm service:

We find references to the vsdatant driver within these strings:

And it has a connection handle to the device created by the vsdatant driver:

Next is the UI process, which communicates with the vsmon service. It’s quite obvious that zatray.exe is a UI process since it has an icon in the tray. Among the handles that vsmon keeps open is a handle to a Section object named ZLCommDB, and searching for other handles via the process explorer reveals this:

Since both the zatray and vsmon processes hold this handle, most likely it’s used for inter-process communication.

Comodo Free Firewall

Comodo Free Firewall is another free host-based firewall developed for Microsoft Windows platforms. This security solution blocks unauthorized connections, allows users to specify programs with permitted access to the internet, and hides ports.

An operating system inspection via the Wincheck tool shows that unlike ZoneAlarm, Comodo uses several drivers, three of which are involved in Firewall activities: cmdguard.sys, cmdhlp.sys, and inspect.sys.

Cmdguard.sys is obviously used to monitor operating system events.

Process notifiers:

[7] 8E1B016A SystemRootsystem32DRIVERScmdguard.sys

Thread notifiers:

[1] 8E1C8742 SystemRootsystem32DRIVERScmdguard.sys

Image notifiers:

[1] 8E1C8306 SystemRootsystem32DRIVERScmdguard.sys

Registry notifiers:

[1] 8E1B1C6E SystemRootsystem32DRIVERScmdguard.sys

An analysis of cmdhlp.sys imports shows that this is the driver which registers within the Windows Filtering Platform:

Analysis of inspect.sys imports shows that this is the driver that’s used to monitor traffic through NDIS:

The Windows service process for Comodo Firewall is CmdAgent:

The service doesn’t hold a connection to the drivers all the time, but there are references to the drivers in its image:

Comodo’s UI process is cis.exe, which communicates with the service via a CisSharedMemBuff Section object:

Conclusion

A host-based firewall is an essential security tool that can protect your system against various viruses. Having a clear understanding of how the components of firewall architecture work will help you better configure your firewall to protect from malware. Apriorit has a team of qualified specialists with deep expertise in network management. We would be glad to assist you in developing your own firewall solution.