(site map)


On Windows 7 (or Vista) I use

  unlimited administrator's account (57.97%)

  limited administrator's account (16.4%)

  common user's account (13.65%)

  nothing (I do not use Win 7/Vista) (14.23%)




Design of ideal personal firewall

Published: 2006/07/01

The following article describes the design of the ideal Windows personal firewall from programmers point of view. First of all the ideal personal firewall is secure. So, this article is about secure design leaving other features like easy of use in the background. At first we say something about the common concept of personal firewalls and then we show important rules for the security design of personal firewall that should be respected during the development of Windows personal firewalls. During our analyses we examine whether those below mentioned rules, that are important for the security, are respected by tested products. In the following article we often use a term 'firewall' but we always mean 'Windows personal firewall'.


Back to contents

Common concept

This paragraph describes common concept of Windows personal firewalls. It is not necessary to implement the firewall in a similar way to have it secure. Common personal firewall is implemented as three or four separate components.

Kernel driver

The first part is kernel driver. Its has two main functions and that is why it is sometimes implemented in two components rather than in one. The first function is a packet filter. Usually on the NDIS, TDI or both levels this driver checks every packet that comes in from the network or goes out to the network. This is also known as inbound and outbound connection protection. As mentioned in the More about personal firewalls article there exist some personal firewalls that do not implement neither inbound nor outbound connection protection. However, these products also have kernel drivers because of their second function. The second function is called sandbox. The most common methods of the sandbox implementation are SSDT hooks and SSDT GDI hooks. The driver of the firewall replaces some system functions with its own code that verifies the rights of calling application and either denies the action or passes the execution to original code. These methods allows the firewall to control all the possible dangerous activity of applications such as attempts to open files, processes, registry keys, modify firewall settings, automatically respond to its queries etc.

System service

There are special user mode processes called system services. These processes have special functions and behaviour in the system. They run under privileged system user rather than under common user account. This fact allows services to run independently of user and they run also when no user is logged in. The role of service in the personal firewall is to secure the communication between main components. The service receives messages from the GUI and from the kernel driver and forwards this messages to each other. For example if the firewall is in the learning mode, the driver code in hooked SSDT function may be unable to decide whether to allow or deny the action because there is no corresponding rule for the action in the database. In such case it wants the user to decide. This requires to send a message to GUI to show the dialog and to receive the answer from it. This communication is usually implemented through the service component. The service of the firewall is sometimes used to ensure that the GUI is always available for the user.

Graphical user interface

The graphical user interface (GUI) is the user part of the firewall. It often implements a trayicon from which the administration of the firewall is available. Another important function of the GUI is to ask user for the decision of actions when the firewall is in the learning mode.

Back to contents


This is rule no. 1 for all security products, not only for personal firewalls. No matter the perfection of other features, if the firewall is not able to secure itself it is useless. If a malicious activity is able to switch off, disable or destroy the personal firewall it is equivalent not to have any personal firewall at all. All parts of the firewall have to be protected including its processes, files, registry entries, drivers, services and other system resources and objects.

Back to contents

Verification of own components

The verification of own components is very close to the above mentioned Self-protection. Firewalls are usually complex programs and they are often implemented in more than one module or component. In such case there are a few main modules that are executed by the operating system. During the startup or in the middle of run these modules loads other modules of the firewall. We say that the modules are loaded dynamically. It is necessary to check the integrity of all dynamically loaded modules. This implies that the integrity checker must be implemented in one of the main modules.

Back to contents

Inbound and outbound protection

The description of inbound and outbound protection is given in the More about personal firewalls article in the Good and bad products paragraph. We have already mentioned that there exist firewalls that do not implement this kind of protection. However, the majority of personal firewalls do implement it.

Back to contents

Process protection

Every privileged process must be protected against several dangerous actions. Firstly, no malicious application can terminate the process. Secondly, it must not be possible to modify its code or data. Thirdly, it must not be possible to execute any code in a context of any privileged process. This point also includes DLL injection.

Back to contents

File and component protection

The protection of files is very close to Process protection. If a malicious code is able to replace files of privileged applications it is equivalent to modify their code flow when they run. There are two ways how to implement the protection of files. The first way (active protection) is to prevent write and delete access to files that belong to privileged applications. Because this can be hard to implement many firewall coders choose the second way - to check the integrity of modules (component protection). In this case the firewall allows malicious code to damage or replace files of privileged applications. If such application is about to run its modules are verified and the execution is stopped or reported to the user. The file protection is also needed for all system files.

Back to contents

Driver protection

Windows operating systems trust its drivers. This mean that every code that is run by the driver is trusted and thus it is allowed to execute even protected processor's instruction and has potential access to all system resources. This is why it is necessary to implement a part of security software like personal firewall as a system driver. However, it is also why it is necessary to control loading of new drivers and to protect existing drivers. Malicious programs must not be able to install drivers or modify already loaded drivers.

Back to contents

Service protection

Since a part of the firewall is usually implemented as a system service the protection of system services is also necessary. But it is not only the firewall component that has to be protected. To install a new service is easy way for malware how to persist in the system because system services can be set to run every system start. What is more, a malicious service can be dangerous also because it runs even if no user is logged on. Creation, deletion and control of system services must be protected actions.

Back to contents

Registry protection

Windows registry contains a lot of important system information. Settings of system components can be changed using the registry. An incorrect modification of some registry objects can easily cause system to become unstable or unable to boot. There are many registry keys and values that should be protected against modifications of malicious applications.

Back to contents

Protection of other system resources

There are also different system resources and objects in Windows operating systems. Some of them can be dangerous if they are controlled by malware. One of these objects is a well known section '\Device\PhysicalMemory' which can be used to gain the complete control of the system if it is not protected. The firewall must protect those objects that can be misused by malware.

Back to contents

Parent process control

We already know that it is necessary to protect privileged processes. Probably the easiest way how to implement process protection is to control opening of processes and threads. However, if the process protection is implement in this way it is also important to implement Parent process control. Every process in the system has to be created by some other process - its parent. The parent is always given two handles when new it creates child process. These are handle to the process object and handle to its main thread. The given process handle is opened with a full access and thus the parent process can control its child completely. This is why the firewall must restrict the execution of privileged processes. Moreover, the parent process control should be implemented even if the firewall security design does not protect processes via control of opening of processes and threads. Some privileged processes can be misused to execute privilege action if they are run with specific command line arguments. Many firewalls do not distinguish between the execution of privileged and unprivileged processes. They restrict the process creation in general such that only those applications that were selected before are able to create child processes.

Back to contents

Control of automatically started programs

The firewall should protect those places in the operating system that can be used by malware to persist in the system after the reboot. If we allow users to run new unknown applications then there is no chance to protect the system against executing malicious application. And users often download and install or run new applications. The firewall is able to restrict actions of malicious applications such that they are not able to damage the system. However, if the malware application persists in the system it can damage it later when a new security bug is discovered. This is why the firewall should control those applications that are run automatically e.g. after every system start or user logon.

Back to contents

Sniffing protection

Spyware like keyloggers or packet sniffers are dangerous applications because they are made to steal the most sensitive data users can have - their passwords. But not only passwords are targets of these applications. Personal information, personal correspondence or business documents are also sensitive information that must be protected. The firewall has to protect sensitive data not only when they are complete in form of files but also when they are made or being transferred. Keyloggers can receive every key stroke user makes and thus assemble the whole information letter by letter. Packet sniffers are waiting for the messages to be transferred using some network interface and they make copies of sent messages. There are many ways how to implement spyware programs to collect sensitive data and all of them have to be protected by the firewall.

Back to contents

Protection of system resources

Every system has limited resources. Windows workstations are able to deal with a few thousands of objects. This number is sufficient for every work of common users. However, if a malicious program creates thousands of threads the system become unusable and such an action cause Denial of service (DoS). The firewall should limit unprivileged applications to cause DoS. There should be a limit set for number of threads, open files, used memory and other system resources used by unprivileged applications.

Back to contents

No ring3 hooks

The ring3 (or usermode) hooking is a technique that can be use to implement a personal firewall or its parts. However, ring3 hooks can be used only for special features and never for security critical features. A protection implemented by ring3 hooks can be easily bypassed by malicious applications. Ring3 hooks must not be used to restrict behaviour of unknown applications. They can be used very rarely to modify or control the behaviour of privileged applications that are guaranteed not to bypass ring3 hooks. Back to contents