On Windows 7 (or Vista) I use
- Features of Modern Security Suites – Part 3
- Features of Modern Security Suites – Part 2
- Features of Modern Security Suites – Part 1
- KHOBE – 8.0 earthquake for Windows desktop security software
- Plague in (security) software drivers
- Introduction to Firewall Leak-testing
- Comparison of top five personal firewalls
- More about personal firewalls
- Design of ideal personal firewall
Design of ideal personal firewall
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'.
- Common concept
- Verification of own components
- Inbound and outbound protection
- Process protection
- File and component protection
- Driver protection
- Service protection
- Registry protection
- Protection of other system resources
- Parent process control
- Control of automatically started programs
- Sniffing protection
- Protection of system resources
- No ring3 hooks
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.