Laptops are very popular as home computers these days as they take up little space and can be easily moved from room to room. Many home users enable file sharing in order to, for example, play digital content on their multimedia systems and televisions.

Many of these users take their laptops with them to public places, such as cafes, and connect to the Internet using a wireless Wi-Fi network. It is reasonable to expect that when you request a firewall and select the network as public, the computer should be protected from intrusions from other participants in the open network.

Business users who use a laptop as their only work computer may find themselves in the same situation, with their machines most often configured to be controlled via Microsoft Remote Desktop.

The purpose of this test is to determine how the most popular third-party firewalls—standalone and as part of Internet Security suites—actually provide basic inbound access control for laptop users who switch between home/work and public networks.

Please note that the scope of the test is obviously very limited, and therefore a good result in this test does not mean that the product provides complete network security.

Testing was carried out in January 2014 by order of the CHIP Online magazine (Germany). The firewall versions used were available as of January 13, 2014.

Firewall testing procedure

The test PC is connected to the Internet via wireless local network(WLAN) using a network connection that is defined as Private in the Windows Network and Sharing Center (WNSC).

The test version of each product available as of January 13, 2014 is installed with default settings and the test computer is rebooted. If the product itself prompts the user to define the current network type as Private/Trusted, this option will be selected. If the product has an update function, then it is performed. Verifies that the product is registered with the Center Windows support as a system firewall, and the product itself showed that it was working as expected. Use a second PC to test connectivity on an existing private network in the following way:

• Ping hostname -4
• Ping hostname -6
• Ping IPv4 address
• Ping IPv6 address
• File share hostname
• File share IPv4 address
• Remote Desktop (RDP) hostname
• Remote Desktop (RDP) IPv4 address
• Remote Desktop (RDP) IPv6 address

All of these forms of remote access are verified to work to ensure full functionality of the test PC on the private network and maximum control over it. After this, the computer and the router to which it was connected are turned off, and the PC starts again. It then connects to another WLAN, which is defined as Public in WNSC, using the Windows Firewall dialog box.

If the firewall shows its request to determine the network type, it is set to “Public” or “Untrusted”. No further changes are made to the product setup.

This procedure models the typical behavior of a laptop user moving from home/office to a public network in a coffee shop, airport, or hotel. After the computer is connected to the new public wireless network, the same tests are performed as for connecting to a private network. This time, all connection attempts are expected to fail as the computer must be protected from any external detection and access on a public network.

Test methodology

Testing was carried out on an experimental PC running licensed Windows XP with SP1 installed (testing was carried out under idealized conditions - “operating system + Firewall” to exclude the influence of other programs on the purity of the experiment). The APS utility was used as an indicator of successful access to services. The following external influences were used:

• scanner XSpider 6.5 and 7.0
• Retina Network Security Scanner 4.9
• several scanners of my design.

In addition, the CommView 4.1 sniffer was used (as a means of monitoring network traffic and as a utility for generating and sending packets with various irregularities in the structure). The so-called flooders of common types, utilities for simulating Trojan programs.

On the test PC, IE 6, Outlook Express 6, TheBat 1.60, MSN Messanger 6.1 were used as means of accessing the network and the Internet. In addition to them, the test involved simulators of Trojan programs and real Trojan / Backdoor programs from my collection (in particular Backdoor.Antilam, Backdoor.AutoSpy, Backdoor.Death, Backdoor.SubSeven, Backdoor.Netbus, Backdoor.BO2K), network / email viruses ( I-Worm.Badtrans, I-Worm.NetSky, I-Worm.Sircam, I-Worm.Mydoom, I-Worm.MSBlast), Trojan Downloader downloaders (in particular TrojanDownloader.IstBar) and SpyWare components. The main task of the tests was to try to look at the Firewall through the eyes of the user, to note its strengths and weaknesses from my point of view.

Kerio Technologies WinRoute Pro v4.2.5

Installation and uninstallation:
It goes without problems.
Installation with default settings, no rules - only NAT is valid. Working on the network - no problems, scan results - APS does not show an alarm state, the scanner believes that all ports are closed. Winroute itself does not issue alarms and does not visually identify the fact of scanning.

Outpost Firewall Pro 2.1 Build 303.4009 (314)

Installation and uninstallation:
Installation under XP proceeds without problems; upon startup, the training mode is activated.

ZoneLabs ZoneAlarm Pro with Web Filtering 4.5.594.000 - Personal Firewall

Installation and uninstallation:
During the installation, XP crashed while trying to start after installation. After rebooting everything worked fine.

AtGuard 3.22>

Installation and uninstallation:
Installation and uninstallation does not cause any special problems

Advantages:

1. Small in size Firewall, has interesting solution from an interface point of view - it is designed as a panel placed at the top of the screen

Disadvantages and features:

1. In training mode it is vulnerable - from the moment the request to create a rule is issued until it is created, it passes packets in both directions
2. The interface is a little glitchy when redrawing windows

Overall rating:
Simple Firewall, but quite functional

Kerio Personal Firewall 4

Installation and uninstallation:
The installation proceeds without problems, the removal is “clean” - no problems were noticed after uninstallation.

Norton Internet Security 2004 (NIS)

Installation and uninstallation: Installation does not cause problems, but of all those analyzed, the installer is the most cumbersome.

Internet Connection Firewall, ICF - built-in Windows firewall XP

Installation and uninstallation: No installation required, it is a standard XP tool. Enabling is done in the network adapter settings. By default, ICF operates in maximum security mode and (this is the result of my observation) the principle of its operation is as follows: application requests are released externally, and only packets that come in response to my requests are received externally (the request-response correspondence is clearly maintained in the form of a dynamic table). Thus, when scanning ports on a computer with ICF enabled, there is not a single open port (this is logical - port scanner packets will not be missed, since no one requested them). The situation is similar with various kinds of “nukes” based on sending non-standard packets

Internet Connection Firewall, ICF - built-in firewall for Windows XP SP2

Installation and uninstallation: No installation required, it is a standard XP tool (included in SP2 for XP). Enabling is done in the network adapter settings. It should be noted that when installing SP2 or when installing XP with integrated SP2, in addition to Firewall, a security center appears in the system, which can show ICF settings

Sygate Personal Firewall Pro 5.5 build 2525

Installation and uninstallation:

ISS BlackIce 3.6.cci

Installation and uninstallation: Installing and uninstalling the program occurs without problems, but during installation an error occurs in the ikernel library. The same error occurred during uninstallation. The occurrence of this error does not affect the process of installing and uninstalling the program. The installer did not require a system reboot, which is unusual for Firewall

Visnetic Firewall 2.2

Installation and uninstallation: Installing the program and uninstalling it occurs without problems. After installation, a reboot is required.

Look n stop personal firewall 2.05

Installation and uninstallation: Installing the program and uninstalling it occurs without problems. After installation, a reboot is required. It installs its own driver to work.

Kaspersky AntiHacker 1.5

Installation and uninstallation: Installing the program and uninstalling it occurs without problems. After installation, a reboot is required.

Tiny Personal Firewall Pro 6.0

Installation and uninstallation:
Installing the program and uninstalling it occurs without problems. After installation, a reboot is required.

McAfee Personal Firewall Plus 6.0 Build 6014

Installation and uninstallation:
Installing the program and uninstalling it occurs without problems. After installation, a reboot is required.

R-Firewall 1.0 Build 43

Installation and uninstallation:
Installing the program and uninstalling it occurs without problems. The size of the distribution is small (3.8 MB), you can customize the composition of the product. The work is quite stable, no obvious crashes or freezes were noticed on the reference PC

General conclusions and conclusion

So, let's summarize the test results. In fact, the tests confirmed my theoretical ideas about the state of the problem:

1. Firewall needs to be configured. All tested Firewalls worked well, but only after configuration (training, creating settings manually - it doesn’t matter). Using an unconfigured Firewall can cause more harm than good (it will allow dangerous packets through and, conversely, will interfere with useful programs);
2. After setting up Firewall and IDS you need to test- This is also a fairly obvious conclusion, but nevertheless it is important. I took the first step towards creating a tester - this is the APS utility. There are two more left - a Trojan program simulator (i.e. a utility that will perform safe attempts for the user to “break” the Firewall from the inside (naturally, the attacks will be described by the database and will be carried out at the user’s command under his control), which will allow you to observe the reaction Firewall and IDS) and a utility for express port scanning and conducting basic attacks (essentially APS is exactly the opposite - they can have a common port base). I am already developing these utilities - their presence in the user’s arsenal will allow for some kind of “instrumental control”.
3. Personal Firewall is vulnerable to malware running from the context of useful programs. Conclusion - at least away with the different “left” panels and other BHOs ​​from the browser and email!! Before installing any plugin, panel, extension utility, etc. you need to think ten times about their necessity, because... they are not separate processes operating system and work from the context of the parent program. The Trojan program is easily detected by a personal Firewall - it “sees” that a certain process (say, bo2k.exe) is trying to start listening on port xxxxx or communicating with a certain host - a request for permission is issued, the user begins to figure out what kind of “bo2k.exe” it is " and Backdoor is caught. But if the Trojan program worked from the context of the browser, then almost certainly no one would pay attention to the browser’s access to the Internet. Such Trojan programs exist, the closest example is TrojanDownloader.IstBar - it is installed exactly as an IE panel (naturally it is not in processes, nor is it in the autorun list);
4. Many personal Firewalls are visible as operating system processes and can be stopped by a virus. Conclusion - the work of the Firewall needs to be monitored and its sudden termination may serve as a signal that a virus has penetrated the PC;
5. Some Firewalls (for example Kerio) allow remote control- the remote control function must be either disabled or password protected.

This second article describes how to resolve problems with the packet filter. Instead of presenting a ready-made table in the form of “problem” - “solution”, methods of a systematic approach are given for solving the problems that have arisen.

This second article (in a series of three) describes how to resolve packet filter problems. Instead of presenting a ready-made table in the form of “problem” - “solution”, methods of a systematic approach are given for solving the problems that have arisen.

Introduction

A packet filter implements a filtering policy by bypassing a set of rules and, accordingly, blocks or passes packets. The chapter explains how to verify that the filtering policy is being implemented correctly, and how to find errors if it is not.

In general, in this chapter's course we will compare the task of writing a set of filtering rules with programming. If you do not have programming skills, then this comparison will seem rather complicated to you. But writing rules in itself does not require the presence academic degree in "computer science" or programming experience, right?

The answer is no, you probably don't need that. The language used to configure the packet filter is made similar to human languages. For example:

block all

pass out all keep state

pass in proto tcp to any port www keep state

In fact, you don’t need to have a programmer nearby to understand what this set does or even, using intuition, to write a similar filtering policy. There is even a high chance that a set of filtering rules created in this likeness will perform the actions that its author had in mind.

Unfortunately, computers only do what you ask them to do, not what you want them to do. Worse yet, they will not be able to distinguish the desired from the actual, if there is such a difference. This means that if the computer does not do what you want correctly, even if you think you have described the instructions clearly, it is in your hands to find the differences and change the instructions. And since this is common problem in programming, we can look at how programmers deal with this. This is where it turns out that the skills and methods used to test and debug programs and filtering rules are very similar. And yet here you do not need knowledge of any programming language in order to understand the implications for testing and debugging.

Good filtering policy.

A filtering policy is an informal specification of what we want from a firewall. On the contrary, a set of rules, an implementation of a specification, is a set of standard instructions, a program executed by a machine. Accordingly, to write a program, you must determine what it should do.

So the first step in firewall configuration is to informally specify what you want to achieve. Which connections should be blocked or allowed through?

An example would be:

There are three networks that must be separated from each other by a firewall. Any connections from one network to another go through a firewall. The firewall has 3 interfaces, each of which is connected to the corresponding network:

$ext_if - to the external network.

$dmz_if - DMZ with servers.

$lan_if - LAN with workstations.

Hosts on the LAN should be free to connect to any hosts in the DMZ or external network.

Servers in the DMZ must be able to communicate freely with hosts on the external network. External network hosts can only connect to the following servers in the DMZ:

Web server 10.1.1.1 port 80

Mail server 10.2.2.2 port 25

All other connections should be prohibited (for example, from machines on the external network to machines on the LAN).

This policy is expressed informally so that anyone reading it can understand it. It should be so specific that the reader can easily formulate answers to a question like ‘Should a connection from host X to host Y be allowed incoming (or outgoing) on ​​interface Z?’. If you're wondering if your policy doesn't meet this requirement, it's because it's not well defined.

“Vague” policies like “allow only everything that is vital” or “block attacks” need to be clarified, or you will not be able to apply or verify them. As in software development, poorly formalized tasks rarely lead to justified or correct implementations. (“Why don’t you go start writing code, while I figure out what the customer needs”).

A set of rules that implements a policy

The set of rules is written as a text file containing sentences in a formal language. Just as the source code is processed and translated into machine code instructions by the compiler, the "source text" of the ruleset is processed by pfctl and the result is interpreted by pf in the kernel.

When source code breaks the rules formal language, the analyzer reports a syntax error and refuses to further process the file. This error is a compile-time error and can usually be fixed quickly. When pfctl can't parse your ruleset file, it prints a line that contains an error and a more or less informative message about what it couldn't parse. Until the entire file is processed without a single error, pfctl will not change the previous set of rules in the kernel. And since the file contains one or more syntax errors, there will be no "program" that pf can execute.

The second type of error is called “run-time errors” because it occurs when a syntactically correctly written program is successfully translated and executed. In general, in programming languages, this can happen when a program divides by zero, attempts to access invalid areas of memory, or runs out of memory. But since the rule sets only vaguely resemble the functionality of programming languages, most of these errors cannot occur during the application of the rules, for example, the rules cannot cause the so-called. “system crash”, as normal programs do. However, a set of rules can cause similar errors, in the form of blocking or, conversely, passing packets that do not comply with the policy. This is sometimes called a logical error, an error that does not throw an exception or stop, but simply produces incorrect results.

So, before we can start checking whether the firewall correctly implements our security policy, we must first successfully load the ruleset.

Analyzer errors

Analyzer errors occur when trying to load a list of rules using pfctl, for example:

# pfctl -f/etc/pf.conf

/ etc/pf.conf:3:syntaxerror

This message indicates that there is a syntax error on line 3 of /etc/pf.conf and pfctl cannot load the rules. The set in the kernel has not changed, it remains the same as before trying to load a new one.

There are many types of errors produced by pfctl. To get started with pfctl, you just need to read them carefully. Perhaps not all parts of the message will reveal their meaning to you right away, but you need to read them all, because... This will make it easier to understand what went wrong later. If a message contains a part of the form “filename:number:text”, it refers to the line with the corresponding number in the specified file.

The next step is to look at the output line using a text editor (in vi you can go to line 3 by typing 3G in beep mode), or like this:

# cat -n /etc/pf.conf

1 int_if = "fxp 0"

2 blocks all

3 pass out on $int_if inet all kep state

pass out inet on $int_if all kep state

The problem could be a simple typo, as in this case (“kep” instead of “keep”). After fixing, try reloading the file:

# pfctl -f/etc/pf.conf

/ etc/pf.conf:3:syntaxerror

# head -n 3 /etc/pf.conf | tail -n 1

pass out inet on $int_if all keep state

Now all the keywords are correct, but upon closer inspection we notice that the placement of the keyword “inet” before “on $int_if” is incorrect. This illustrates that the same line can contain more than one error. Pfctl prints the first error it finds and stops executing. If the same line number was issued upon restart, it means there are still errors in it, or the previous ones were not corrected correctly.

Improperly placed keywords are also a common mistake. This can be revealed by comparing the rule with the reference BNF syntax at the end of the man pf.conf(5) help file, which contains:

pf-rule= action [ ("in" | "out") ]

["log" | "log-all" ] [ "quick" ]

[ "on" ifspec ] [ route ] [ af ] [ protospec ]

hosts [filteropt-list]

ifspec = ([ "!" ] interface-name) | "(" interface-list ")"

af = "inet" | "inet6"

What does it mean that keyword“inet” must follow “on $int_if”

Let's fix it and try again:

# pfctl -f/etc/pf.conf

/ etc/pf.conf:3:syntaxerror

# head -n 3 /etc/pf.conf | tail -n 1

pass out on $int_if inet all keep state

There are no obvious errors left now. But we don’t see all the accompanying details! The line depends on the macro definition $inf_if. What could be wrongly defined?

# pfctl -vf /etc/pf.conf

int_if = "fxp 0"

block drop all

/etc/pf.conf:3: syntax error

After correcting the typo “fxp 0” to “fxp0”, try again:

# pfctl -f/etc/pf.conf

The absence of messages indicates that the file was successfully downloaded.

In some cases, pfctl may produce error messages that are more specific than just "syntax error":

# pfctl -f /etc/pf.conf

/etc/pf.conf:3: port only applies to tcp/udp

/etc/pf.conf:3: skipping rule due to errors

/etc/pf.conf:3: rule expands to no valid combination

# head -n 3 /etc/pf.conf | tail -n 1

pass out on $int_if to port ssh keep state

The first line of the error message is the most informative compared to the rest. In this case, the problem is that the rule, when specifying the port, does not specify the protocol - tcp or udp.

In rare cases, pfctl may become confused by the presence of unprintable characters or unnecessary spaces in a file, such errors are not easily detected without special processing of the file:

# pfctl -f /etc/pf.conf

/etc/pf.conf:2: whitespace after \

/etc/pf.conf:2: syntax error

# cat -ent /etc/pf.conf

1 block all$

2 pass out on gem0 from any to any \ $

3 ^ Ikeepstate$

The problem here is the space character, after the backslash but before the end of the second line, indicated by the “$” sign in the output of cat -e.

Once the ruleset has been successfully loaded, it would be nice to look at the result:

$ cat /etc/pf.conf

block all

# pass from any to any \

pass from 10.1.2.3 to any

$ pfctl -f /etc/pf.conf

$ pfctl -sr

blockdropall

A "backslash" at the end of a comment line actually means that the comment line will continue below.

Expanding lists enclosed in curly braces () can produce a result that may surprise you, and at the same time show the set of rules processed by the analyzer:

$ cat /etc/pf.conf

pass from ( !10.1.2.3, !10.2.3.4 ) to any

$ pfctl -nvf /etc/pf.conf

pass internet from ! 10.1.2.3 to any

pass internet from ! 10.2.3.4toany

The catch here is that the expression "( !10.1.2.3, !10.2.3.4 )" will not mean "all addresses except 10.1.2.3 and 10.2.3.4", the expanded expression itself means to match any possible address.

You should reload your ruleset after making permanent changes to ensure that pfctl can load it when the machine is rebooted. On OpenBSD, the rc startup script in /etc/rc first loads a small default set of rules that blocks all traffic except what is needed during the boot phase (such as dhcp or ntp). If the script is unable to load the real set of rules from /etc/pf.conf due to syntax errors introduced before the machine was rebooted without checking, then the default set will remain active. Fortunately, this set allows incoming ssh connections, so the problem can be solved remotely.

Testing

Since we have an extremely precisely defined policy and a set of rules that should implement it, then the term testing will mean in our case the compliance of the resulting set with the given policy.

There are only two ways for rules to work incorrectly: blocking connections that should be allowed, and vice versa, allowing connections that should be blocked.

Testing in general implies a systematic approach to the orderly creation of various types of connections. It's impossible to check everything possible combinations source/receiver and corresponding ports on the interfaces, because a firewall could theoretically encounter a huge number of such combinations. Ensuring the initial correctness of a set of rules can only be ensured for very simple cases. In practice, the best solution is to create a list of test connections based on the security policy, such that every policy item is affected. So, for our example policy, the list of tests will be as follows:

Connection from LAN to DMZ (must be skipped)

from LAN to external network (must be skipped)

from DMZ to LAN (must be blocked)

from DMZ to external network (must be skipped)

from external network to DMZ to 10.1.1.1 on port 80 (must be skipped)

from external network to DMZ to 10.1.1.1 on port 25 (should be blocked)

from the external network to the DMZ to 10.2.2.2 on port 80 (should be blocked)

from external network to DMZ to 10.2.2.2 on port 25 (must be skipped)

from external network to LAN (must be blocked)

The expected result must be defined in this list before testing begins.

This may sound strange, but the purpose of each test is to find errors in the implementation of a set of firewall rules, and not simply state their absence. And the ultimate goal of the process is to build a set of rules without errors, so if you think there might be errors, you're better off finding them than missing them. And if you take on the role of a tester, you should adhere to a destructive style of thinking and try to bypass the firewall restrictions. And only the fact that the restrictions cannot be broken will be a reasoned confirmation that the set of rules does not contain errors.

TCP and UDP connections can be checked using nc. nc can be used as both a client and a server (using the -l option). And for ICMP requests and responses, the best client to check is ping.

To check whether a connection is blocked, you can use any means that will try to create connections to the server.

Using ports collection tools like nmap, you can easily scan multiple ports, even across multiple hosts. If the results don't look quite clear, take a look at the man page. For example, for a TCP port, the scanner returns the value 'unfiltered' when nmap receives an RST from pf. Also, pf installed on the same machine as the scanner can influence the correct operation of nmap.

More sophisticated scanning tools may include tools to create fragmented or incorrect IP packets.

To verify that the filter is passing connections specified in the policy, the best method is to check using those applications that will subsequently be used by clients. Thus, checking the passage of http connections from different web server client machines, as well as from different browsers, and sampling different content will be better than simply confirming the establishment of a TCP session to nc, which works as a server part. Various factors, such as the host operating system, can also cause errors - problems with TCP window scaling or TCP SACK responses between certain operating systems.

When the next test point is passed, its results may not always be the same. The connection may be interrupted during the connection establishment process if the firewall returns RST. The connection establishment may simply fail due to a timeout. The connection may be fully established and work, but after a while it may freeze or break. The connection may hold, but throughput or latency may be different than expected, higher or lower (in case you use AltQ to limit bandwidth).

As expected results, in addition to skipping/blocking the connection, you can also note whether packets are logged, how they are translated, routed, and whether the necessary counters are increased, if necessary. If these aspects are important to you, then they also need to be included in the testing methodology.

Your policy may include requirements related to performance, response to overloads, and fault tolerance. And they may require separate tests. If you're setting up a fault-tolerant system using CARP, you'll probably want to know what happens under various types of failures.

When you observe a result different from what you expected, take a step-by-step note of your steps during the test, what you expected, why you expected it, the result you got, and how the result differed from your expectations. Repeat the test to see if the situation is the same or different from time to time. Try changing the input parameters of the test (source/destination address or ports).

From the moment you have a reproducible problem, you need to start debugging to figure out why things aren't working the way you expected and how to "fix" things. With this setup, you must change the ruleset and repeat all tests, including those that did not throw errors, because by changing the rules you could inadvertently affect the operation of valid parts of the ruleset.

The same principle applies to other changes made to the set. Such formal procedure checks will help make the process less prone to introducing errors. Small changes may not require repeating the entire procedure, but the sum of several small changes may affect overall result set processing. You can use a version control system such as cvs to work with your configuration file because... this will help in investigating the changes that led to the error. If you know that a bug didn't happen a week ago, but it does now, looking at all the changes you've made over the last week will help you notice the problem, or at least roll back to the point where it didn't exist.

Non-trivial rule sets can be thought of as programs; they are rarely perfect in their first version, and it takes time to be confident that they are free of errors. However, unlike regular programs, which are never considered error-free by most programmers, rule sets are still simple enough to be close to this definition.

Debugging

The term debugging usually refers to finding and eliminating programming errors in computer programs. Or, in the context of firewall rulesets, the term would refer to the process of finding the reason why the set does not return the desired result. There are few types of errors that can appear in the rules, however, the methods for finding them are similar to programming.

Before you start looking for the cause of the problem, you must clearly understand the nature of the problem. If you notice the error yourself during testing, it's very simple. But if another person reports a bug to you, creating a clear goal from an imprecise bug report can be challenging. The best place to start is by reproducing the error yourself.

Network problems may not always be caused by a packet filter. Before you focus your attention on debugging the pf configuration, you need to make sure that the problem is caused by the packet filter. This is easy to do and will also save time searching for the problem elsewhere. Simply turn off pf with pfctl -d and check if the problem occurs again. If so, enable pf with pfctl -e and see what happens. This method will not work in some cases, for example, if pf does not do network address translation (NAT) correctly, then turning off pf obviously will not get rid of the error. But in cases where this is possible, try to make sure that it is the packet filter that is at fault.

Accordingly, if the problem is in the packet filter, the first thing you need to do is make sure that pf really works and the required set of rules is successfully loaded:

# pfctl -si | grep Status

Status: Enabled for 4 days 13:47:32Debug: Urgent

# pfctl -sr

pass quick on lo0 all

pass quick on enc0 all

Debugging by protocols

The next debugging step is to pinpoint the problem to specific network connections. If you have the message: “Instant messaging in application X is not working,” you need to find out what network connections are being used. The conclusion might be something like “host A cannot establish a connection to host B on port C.” Sometimes this task is the most difficult, but if you have information about the necessary connections and you know that the firewall will not allow them, you only need to change the rules to solve this problem.

There are several ways to find out what protocols or connections an application is using. Tcpdump can display packets arriving or leaving both a real network interface and virtual ones such as pflog and pfsync. You can define a filter expression to specify which packets to display and eliminate extraneous network noise. Try to establish a network connection in the desired application and look at the packets being sent. For example:

# tcpdump -nvvvpi fxp0 tcp and not port ssh and not port smtp

23:55:59.072513 10.1.2.3.65123 > 10.2.3.4.6667: S

4093655771:4093655771(0) win 5840

1039287798 0,nop,wscale 0> (DF)

This is a TCP SYN packet, the first packet of a TCP handshake.

The sender is 10.1.2.3 port 65123 (looks like a random unprivileged port) and the recipient is 10.2.3.4 port 6667. A detailed explanation of the tcpdump output format can be found in the utility's manual pages. Tcpdump is the most important tool for debugging pf related problems and it is very important to become familiar with it.

Another method is to use pf's logging feature. Assuming you use the 'log' option in all rules with 'block', then all packets blocked by pf will be reflected in the log. It is possible to remove the 'log' option from rules that deal with known protocols, e.g. Only those packets that go to unknown ports will be recorded in the log. Try using the application that can't connect and look at pflog:

# ifconfig pflog0 up

# tcpdump -netti pflog0

Nov 26 00:02:26.723219 rule 41/0(match): block in on cue0:

195.234.187.87.34482 > 62.65.145.30.6667: S 3537828346:3537828346(0) win

16384 (DF)

If you are using pflog, a daemon that constantly listens to pflog0 and stores the received information in /var/log/pflog, you can see the saved information like this:

# tcpdump -nettr/var/log/pflog

When outputting saved pf packets, you can use additional filtering expressions, for example, look at packets that were blocked at the input on the wi0 interface:

# tcpdump -netttr /var/log/pflog inbound and action block and on wi0

Some protocols, such as FTP, are not so easy to trace because they do not use fixed port numbers or use multiple coexisting connections. It may not be possible to get them through the firewall without opening a wide range of ports. For individual protocols, there are solutions similar to ftp-proxy.

Debugging rules

If your ruleset is blocking a particular protocol because you haven't opened the correct port, it bigger problem design stage rather than a bug in the rules. But what if you see that a connection for which you have a rule allowing it is blocked?

For example, your set contains the rule

block in return-rst on $ext_if proto tcp from any to $ext_if port ssh

But when you try to connect to TCP port 22, the connection is accepted! It looks like the firewall is ignoring your rule. Just like putting together a puzzle, there is a simple logical and usually trivial explanation for these things the first few times you encounter them.

First, you should check all those steps mentioned earlier. For example, let's assume that the firewall is running and contains the rule given above. It's unlikely that our previous concerns are true, but it's easy to check:

# pfctl -si | grep Status

Status: Enabled for 4 days 14:03:13Debug: Urgent

# pfctl -gsr | grep "port=ssh"

@14 block return-rst in on kue0 inet proto tcp from any to 62.65.145.30 port = ssh

The next thing we have is: TCP connections are accepted on port 22 on kue0. You might think that this is already obvious, but it would be worth checking. Run tcpdump:

# tcpdump -nvvvi kue0 tcp and port 22 and dst 62.65.145.30

Now retry the SSH connection. You should see packets from your connection in the tcpdump output. You may not see them, and this could be because the connection is not actually going through kue0, but is going through a different interface, which explains why the rule is not triggered. Or you may be connecting to a different address. In short, if you don’t see ssh packets, then pf won’t see them either, and it may not be able to block them using the rule given in our problem.

But if you see packets using tcpdump, pf will “see” them too and will filter them. The next assumption is that the blocking rule must not only be present in the set (which we have already established), but must be the last matching rule for the desired packets. If this is not the final rule, then obviously the decision to hold packets is not made according to this.

In what cases might a rule not be the last matching rule? There are three possible reasons:

A) the rule does not work, since viewing the rules does not reach what we need.

The previously present rule is also triggered and causes execution to terminate with the 'quick' option;

B) the rule is processed, but the rule does not work due to a mismatch of individual criteria.

C) the rule is processed, the rule is triggered, but processing continues and subsequent rules are also triggered for the packet.

To reject these three cases, you can, looking at the loaded set of rules, mentally imagine processing a hypothetical TCP packet arriving on the kue0 interface and port 22. Select the block to be debugged. Start crawling with the first rule. Does it match? If yes, mark it. Does it have a 'quick' option? If so, then we stop going around. If not, continue with the next rule. Repeat the check until a match is found with the 'quick' option or the end of the ruleset is reached. Which rule matched last? If it's not rule number 14, you've found the explanation for the problem.

Bypassing the rules manually may seem like fun, however, if you have enough experience, it can be done quite quickly and to a large extent reliability. If the set is large enough, you can temporarily reduce it. Keep a copy of the actual list of rules and delete those entries that you don't think will affect the result. Download this set and test again. If the connection is now blocked, then the rules that seemed unrelated to the packets you were looking for are responsible for cases A or B. Add rules one by one, repeating the test until you find the one you need. If the connection is still passed after removing rules that do not affect it, repeat the mental traversal of the reduced set.

Another method is to use pf's logging ability to identify cases A or C. Add 'log' to all rules with 'pass quick' before the 14th rule. Add 'log' to all rules with 'pass' after the 14th rule. Run tcpdump for the pflog0 interface and establish an ssh connection. You will see which rules besides the 14th are triggered last on your packets. If there is nothing in the log, then case B occurs.

Tracking connections through a firewall

When a connection passes through a firewall, packets arrive on one interface and are transmitted out through the second. Responses come to the second interface and go to the first. Connections can thus fail in each of these four cases.

First, you must figure out which of the four cases is the problem. If you try to establish a connection, you should see a TCP SYN packet on the first interface using tcpdump. You should also see the same TCP SYN packet output from the second interface. If you don’t see it, then we conclude that pf is blocking an incoming packet on the first interface, or an outgoing packet on the second.

If the SYN send is not blocked, you should see SYN+ACK coming to the second interface and leaving the first. If not, pf blocks SYN+ACK on some interface.

Add the 'log' option to rules that should allow SYN and SYN+ACK on both interfaces, as well as to rules that should block them. Retry the connection and check pflog. It should clarify in what case the blocking occurs and by what rule.

Debugging connection states

The most common reason for pf packets to be blocked is that there is a redundant blocking rule in the set. The corresponding last match rule can be found by adding the 'log' option to all potentially impacting rules and listening to the pflog interface.

In a smaller number of cases, it happens that pf silently drops packets based on non-rules, and here adding 'log' to all rules will not cause the dropped packets to end up in pflog. Often a packet is almost, but not completely, matched by a state entry.

Remember that for each packet it processes, the packet filter scans the state table. If a matching entry is found, the packet is immediately allowed through without causing the ruleset to be processed for itself.

A state table entry contains information specific to a single connection.

Each entry has a unique key. This key consists of several values ​​that limit the lifetime of the connection to constant throughout. Here they are:

• Address type (Ipv4 or Ipv6)
• Source address
• Receiver address
• Protocol (TCP UDP)
• Source port
• Receiver port

This key is used for all packets belonging to the same connection, and packets from different connections will always have different keys.

When a state table entry is created using the 'keep state' option from a rule, the connection entry is stored using the connection key. An important limitation for the state table is that all keys must be unique. Those. there cannot be two records with the same keys.

It may not be immediately obvious that the same two hosts cannot establish multiple coexisting connections using the same addresses, protocols and ports, but this is a fundamental property of both TCP and UDP. In fact, TCP/IP stacks can only associate individual packets with their sockets by performing selections based on addresses and ports.

Even if the connection is closed, the same pair of addresses and ports cannot be re-used immediately. The network equipment may later deliver retransmitted packets, and if the recipient's TCP/IP stack mistakes them for packets from a newly created connection, this will interfere with or even break the new connection. For this reason, both hosts must wait a certain amount of time, called 2MSL ("twice the maximum segment lifetime"), before being able to use the same addresses and ports again for a new connection.

You can observe this property by manually establishing multiple connections to the same host. For example, having a web server running on 10.1.1.1 and port 80, and connecting twice with 10.2.2.2. using nc:

$ nc -v 10.1.1.1 80 & nc -v 10.1.1.1 80

Connection to 10.1.1.1 80 port succeeded!

While connections are open, you can use netstat on the client or server to display information about these connections:

$ netstat -n | grep 10.1.1.1.80

tcp 0 0 10.2.2.6.28054 10.1.1.1.80 ESTABLISHED

tcp 0 0 10.2.2.6.43204 10.1.1.1.80 ESTABLISHED

As you can see, the client has selected two different (random) source ports, so this does not violate the key uniqueness requirement.

You can tell nc to use a specific source port with the -p option:

$ nc -v -p 31234 10.1.1.1 80 & nc -v -p 31234 10.1.1.1 80

Connection to 10.1.1.1 80 port succeeded!

nc: bind failed: Address already in use

The client's TCP/IP stack prevented key uniqueness from being compromised. Some rare and buggy implementations of TCP/IP stacks did not follow this rule, and therefore, as we will soon see, pf will block their connections if the uniqueness of the keys is violated.

Let's go back to where pf queries the state table as the packet begins to be filtered. The request consists of two steps. The first query is made to find an entry in the table entry with a key corresponding to the protocol, addresses, and port of the packet. The search will be carried out for packets going in any direction. Let's assume that the following package created an entry in the state table:

incomingTCPfrom 10.2.2.2:28054to 10.1.1.1:80

A table query will find the following entries in the state table:

incoming TCP from 10.2.2.2:28054 to 10.1.1.1:80

outgoing TCP from 10.1.1.1:80 to 10.2.2.2:28054

An entry in the table includes information about the direction (incoming or outgoing) of the first packet that created the entry. For example, the following entries will not produce a match:

outgoingTCPfrom 10.2.2.2:28054to 10.1.1.1:80

incomingTCPfrom 10.1.1.1:80to 10.2.2.2:28054

The reason for these restrictions is not obvious, but is quite simple. Imagine that you have just one interface with address 10.1.1.1, where the web server is listening on port 80. When client 10.2.2.2 connects using a randomly selected outgoing port 28054, the first connection packet arrives on your interface and all your outgoing responses should will go from 10.1.1.1:80 to 10.2.2.2:28054. You will not allow outgoing packets from 10.2.2.2:28054 to 10.1.1.1:80, since such packets are meaningless.

If your firewall is configured for two interfaces, then by watching the packets passing through it, you will see that every packet arriving on the first interface goes out and through the second. If you create a state record in which the initial packet arrives on the first interface, then that record will prevent the same packet from leaving the second interface because it is misdirected.

When an attempt to find a packet among the entries in the state table fails, the list of filter rules is traversed. You must specifically allow the packet to pass out through the second interface with a separate rule. You probably use 'keep state' in this rule so that the second entry in the state table covers the entire connection and on the second interface.

You may be wondering how it is possible to create a second record in a table if we just explained that records must have unique keys. The explanation here is that the record also contains information about the direction of the connection, and the combination of this with the rest of the data must be unique.

Now we will also be able to explain the difference between a free connection and an interface bound connection. By default, pf creates entries that are not bound to any interface. Therefore, if you allow connections on one interface, packets related to the connection and matching the table entry (including information about the direction of the packet!) pass through any interface. In simple installations with static routing, these are more theoretical calculations. In principle, you should not see packets from the same connection arriving on multiple interfaces and response packets leaving on multiple interfaces as well. However, with dynamic routing this is possible. You can bind state records to a specific interface using the global setting 'set state-policy if-bound' or the per-rule option 'keep state (if-bound)'. This way you will be sure that packets will only be matched by records from the interface that created these records.

If tunnel interfaces are used, then the same connection passes through the firewall several times. For example, the first packet of a connection may first pass through interface A, then through B, then C and finally leave us through interface D. Typically the packets will be encapsulated on interfaces A and D and decapsulated on B and C, so pf sees packets of different protocols and you can create 4 different entries in the state table. Without encapsulation, the packet will be unchanged on all four interfaces and you will not be able to use some features, such as address translation or TCP sequence number modulation, because this will lead to conflicting keys appearing in the state table. Until you have a complete installation that includes interfaces with tunneling and debugged errors like "pf: src_tree insert failed", you will not be able to consider your installation sufficiently successful. Let's return to the state table query that is made for each packet before checking the rules. The query must return a single record with a matching key, or return nothing. If the query returns nothing, the list of rules is traversed.

If an entry is found, the second step for TCP packets before they are considered to belong to a specific connection and are filtered is to check the sequence number.

There are a large number of TCP attacks in which the attacker tries to control the connection between two hosts. In most cases, the attacker is not in the path of the routes between the hosts, and therefore cannot eavesdrop on legitimate packets sent by the hosts. However, he can send packets to any of the hosts, simulating the packets of his interlocutor, by spoofing (“spoofing”) - faking the sender's address. The attacker's goal may be to prevent connections between hosts from being created, or to terminate already established connections (to cause a denial of service), or to create malicious downloads on connections.

For a successful attack, the attacker must correctly “guess” several connection parameters, such as the source and destination address/port. And for widespread protocols, this may not be as difficult as it may seem. If the attacker knows the host addresses and one of the ports (since we are talking about a common service), he will only need to “guess” one port. Even if the client uses a truly random source port (which is not always true), the attacker only needs to traverse 65536 ports in a short period of time. (In most cases, even (65536-1024) ports, i.e. only unprivileged ports - translator's note))

But what is truly difficult for an attacker to guess is the correct sequence number (and its confirmation). If both hosts choose the initial sequence number randomly (or you use sequence number modulation for hosts that have a weak ISN (Initial Sequence Number) generator), then the attacker will not be able to find the appropriate value at the right time in the connection.

During the existence of a valid TCP connection, the sequence numbers (and acknowledgments) for individual packets change according to certain rules.

For example, if the host sends some data segment and its recipient acknowledges receipt, there should be no reason why the sender should send the segment data again. But, in fact, an attempt to overwrite parts of information already received by the host is not a violation of the TCP protocol, although it may be a type of attack.

pf uses rules to determine the smallest range for legitimate sequence numbers. In general, pf can only accurately determine the identity of 30,000 of the 4294967296 possible sequence numbers at any given time in a connection. Only if the sequence number and acknowledgment are included in this window, pf will be convinced that the packet is legitimate and will let it through.

If a suitable entry is found during a query to the state table, next step The sequence numbers of packets stored in the table are checked to see if they are within the range of possible values. If the comparison fails, pf will generate a "BAD state" message and discard the packet without evaluating the ruleset. There are two reasons why a comparison with the rules may not occur: it will almost certainly be an error to miss the packet, because if calculating the set will result in the rule hitting an option "keep state" and pf will not be able to make a decision and create a new record because this will lead to conflicting keys in the table.

In order to see and log "BAD state" messages, you need to enable debugging mode using the command:

$ pfctl -xm

Debug messages are sent to the console by default, and syslogd also writes them to /var/log/messages. Look for messages starting with "pf":

pf:BADstate:TCP 192.168.1.10:20 192.168.1.10:20 192.168.1.200:64828

[ lo=1185380879high=1185380879win=33304modulator=0wscale=1]

4:4 A seq=1185380879 ack=1046638749 len=1448 ackskew=0 pkts=940:631

dir=out,fwd

pf: State failure on: 1 |

These messages always come in pairs. The first message shows the state table entry at the time the packet was blocked and the sequence number of the packet that caused the error. The second entry displays the conditions that were violated.

At the end of the first message, you will see whether a status record was created for an incoming (dir=in) or outgoing (dir=out) packet, and whether the blocked packet was traveling in the same direction (dir=,fwd) or the opposite direction (dir=,rev) ) direction.

The entry in the table contains three addresses: pairs of ports, two of which are always equal to each other, if the connection has not undergone nat, rdr or bnat conversion. For outgoing connections, the source of the packet is displayed on the left and the destination of the packet on the right. If the outgoing connection involves source address translation, the pair in the middle shows the source after translation. For incoming connections, the source is on the right side of the output and the destination address is in the middle. If the incoming connection is subject to destination address translation, the ip/port pair on the left shows the destination after translation has been performed. This format matches the output of pfctl -ss, except that pfctl shows the direction of the packet using arrows.

In the output you can see the current host sequence numbers in square brackets. So the value “4:4” means that the connection is fully established (smaller values ​​are more likely at the connection establishment stage, larger values ​​are more likely at the time the connection is closed)."A" means that the blocked packet had the ACK flag set (as in tcpdump's flag output), followed by the values ​​of the sequence numbers (seq=) and (ack=) in the blocked packets and the packet payload length - data length (len =). askskew is part of the internal representation of data in the table, used only for values ​​​​not equal to zero.

The entry "pkts=930:631" means that it matched 940 packets traveling in the same direction as the packet that caused the entry to be created, and 631 packets in the opposite direction. These counters will be especially useful in troubleshooting the connection setup phase if one of them equal to zero, this will contradict your expectation that packets going in both directions match a given entry.

The following message will contain a list of one or more numbers. Each number represents the test on which the error occurred:

1. The packet window size exceeds the receiver's maximum size (seq + len > high)
2. the packet contains already transmitted data (seq< lo - win)
3. ackskew is less than the minimum value
4. ackskew is greater than the maximum value
5. same as in (1), but with a difference (seq + len > high + win)
6. same as in (2), but (seq< lo - maximum win)

Fortunately, "BAD state" messages do not apply to real day-to-day traffic, and checking the pf sequence number avoids most anomalies. If you see these messages appearing sporadically and don't notice a large number of hanging connections, you can simply ignore them. There are many TCP/IP implementations running on the Internet, and some of them can sometimes generate erroneous packets.

However, this class of problems can be easily diagnosed by the appearance of "BAD state" messages that appear only in such cases.

Creating State RecordsTCP by initialSYN to the package.

Ideally, state records should be created when the first SYN packet occurs.

You can force the use of this rule using the principle:

“Use “flags S/SA” options in all “pass proto tcp keep state” rules”

Only the initial SYN packets (and only these) have the SYN flag set and the ACK collected. When the "keep state" option is applied only to initial SYN packets, only those packets will create entries in the state table. Thus, any existing entry in the state table will be derived from the initial SYN packet.

The reason for creating records for only the initial packets is a TCP protocol extension called “window scaling” defined in RFC1323. The TCP header field, used to announce the size of received windows, is too small for today's high-speed communications links. Modern TCP/IP implementations prefer to use large values window size than can fit in the existing box. Window size scaling means that all window sizes known from the receiving host must be multiplied by a specific value specified by the recipient, rather than taken by themselves. For this scheme to work, both hosts must support the extension and indicate to each other their ability to implement it during the connection establishment (“handshake”) phase using TCP options. These options are only present in the initial SYN and SYN+ACK packets. Only if each of these packets contains an option will the mutual agreement be successful and the window size of all subsequent packets will be multiplied by a factor.

If pf were “not aware” of the window scaling being used, it would take the supplied value without a factor, and calculate window sizes for acceptable sequence number values ​​would be incorrect. Typically, hosts provide small window sizes at the start of a connection and increase them as the connection progresses. Unaware of the existence of factors changing the window size, pf will at some point begin to block packets, because it will believe that one of the hosts is trying to bypass the maximum window size provided by the “interlocutor”. The effects of this may be more or less noticeable. Sometimes, hosts will respond to packet loss by moving to the so-called. “loss recovery mode” and will advertise a smaller window size. After pf retransmits packets that were dropped the first time, the window sizes will further increase, to the point where pf will start blocking them again. The external manifestation may be temporary connection freezes and low performance. It is also possible that connections will completely freeze or reset due to a timeout.

But pf knows about the possibility of scaling windows and supports this possibility. However, the prerequisite for creating state table entries on the first SYN packets is that pf can associate the first two packets of the connection with the table entry. And since full matching of window size coefficients occurs only in these first two packets, there is no reliable method to determine these coefficients after the connection is negotiated.

In the past, window size scaling was not widely used, but this is rapidly changing. It's only recently that Linux has enabled this option by default. If you are having difficulty with hanging connections, especially with certain host combinations, and are seeing "BAD state" messages related to these connections, check that you are actually creating state table entries on the first packets of the connection.

You can determine whether pf is using the scaling option for the connection from the output of pfctl:

$ pfctl -vss

kue0 tcp 10.1.2.3:10604 -> 10.2.3.4:80 ESTABLISHED:ESTABLISHED

wscale 0wscale 1

If there is a "wscale x" entry printed on the second line (even if x is zero), pf will read that it knows that the connection is using scaling.

Another simple method for identifying problems associated with scaling is to temporarily disable scaling support and replay the situation. On OpenBSD, the use of scaling can be controlled by the sysctl option:

$ sysctlnet.inet.tcp.rfc1323

net.inet.tcp.rfc1323=1

$ sysctl -wsysctlnet.inet.tcp.rfc1323=0

net.inet.tcp.rfc1323: 1 -> 0

Similar problems appear when you create entries in the state table for packets other than the initial SYN and use the "mulate state" option or broadcast. In both cases, the broadcast occurs at the beginning of the connection. If the first packet is not translated, tranching subsequent ones usually discourages the receiving end and causes sent replies to be blocked by pf with a "BAD state" message.

The section is updated daily. Always the latest versions of the best free programs for everyday use in the Required programs section. There is almost everything you need for everyday work. Start gradually abandoning pirated versions in favor of more convenient and functional free analogues. If you still do not use our chat, we highly recommend that you get acquainted with it. There you will find many new friends. In addition, this is the fastest and most effective way to contact project administrators. The Antivirus Updates section continues to work - always up-to-date free updates for Dr Web and NOD. Didn't have time to read something? The full contents of the ticker can be found at this link.

Free firewall Comodo. Testing, conclusions

Comodo Firewall in action

After installation and configuration, Comodo hid in the tray and began pestering me with its questions. On the first day I played around with all the firewall and proactive protection modes and eventually silenced it. No brakes were found in our system after its appearance. In general, working with the firewall from Comodo was quite easy and convenient. The interface of the main window is very simple and informative:

But I had to get used to navigating through the firewall and proactive protection settings - it’s not always possible to quickly find the right item. I think this will go away with time.

A few days after installing Comodo Firewall, I decided to test it a little.

Test No. 1. Online testing

When you click on the "Test" button, the program tries to establish a connection with the site server.

Since Comodo Firewall does not yet know this utility, the first time it tried to access the Internet, there was an immediate reaction from proactive protection and the firewall:

In both cases, I clicked block and received confirmation that the test was successful:

Then I renamed the file FireWallTest.exe V opera.exe and replaced the standard Opera file with it. Thus, I tried to trick Comodo Firewall, which already knows this browser well and constantly and automatically releases it to the Internet. Comodo reacted to the launch of the “fake” Opera from Total as follows:

Having received my permission for a one-time launch, the firewall warned me that Opera was trying to access the Internet:

It turns out that any application for which there are already rules, if the executable file is replaced without my knowledge, will not be able to access the Internet. Everything seems to be fine, but here’s the thing: the color of the top part of the warning window depends on the severity of the situation. If Comodo evaluates an event as critical, the color will be red, if the event is less dangerous, it will be yellow. In my case, Comodo considered the simulated situation not particularly dangerous and turned on the “yellow” light. Moreover, instead of the wording “executable file opera.exe not recognized" I would prefer to see that "there was a change in file parameters opera.exe" This is how harvesters from Kaspersky and Eset, for example, warn in such situations. Moreover, the user sees an alarm window using the color red, which immediately forces them to pay attention to the situation. And a warning from Comodo can simply be ignored by the user due to insufficient emphasis on the event occurring.

Replacing the Opera file was only part of my insidious plan. The next victim was Internet Explorer 6, which is integrated into the operating system, and, therefore, iexplore.exe can be considered a full-fledged system file. Imagine my surprise when, under the complete silence of Comodo, I saw a window about test failure:

Apparently, an extra rule had been created, I decided and went into the firewall and proactive protection policies. After rummaging around there for about 15 minutes, I made the only right decision - to reinstall Comodo. No sooner said than done. Leaving the default operating modes, I repeated the experiment with substitution iexplore.exe. When launched from Total, proactive protection worked, as in the case of Opera:

Here you have to do a little lyrical digression. The fact is that when an IE executable file is replaced, the system restores the original one within 4-8 seconds iexplore.exe. In this regard, the results of my test depended on whether the spoofed file managed to reach the Internet or not.

In the case when I manage to complete all the manipulations before restoring explore.exe, the following happens. Having received my permission for a one-time launch explore.exe, Total launches the FireWallTest utility, press “Test”, Defens+ proactive protection issues a warning:

If we allow it (as an experiment), the firewall works:

We manage to click “Block” - the test is passed, the utility does not get through to the Internet. But if iexplore.exe restored before you pressed the block button - nothing depends on your choice - the utility automatically gains Internet access at the moment the original file is restored.

The same applies to the work of proactive protection: if you did not have time to command blocking before recovery explore.exe- the utility automatically gains access to the Internet.

Having played enough with the fake IE, I remembered the very first failure of the test, when Comodo remained silent and released the “wrong” file on the Internet. After reinstalling Comodo, I put Defense+ and the firewall into training mode and launched IE. After that, I returned the default modes and repeated the test. Comodo silently failed it again...

Test No. 3. Duel

Impressed by the results of the previous test, I looked for additional opportunities to test Comodo and finally found the AWFT utility.

This program emulates the behavior of Trojans and contains a series of six tests demonstrating various techniques unauthorized access to the network, bypassing firewall protection. Among these tests there are both old ways of deceiving firewalls and more modern techniques. For each successfully passed test, the firewall is awarded a certain number of points. If the test is not passed, points will be awarded to the AWFT. The maximum number of points is ten.

The utility is shareware, limited to 10 launches. At the top of the program window there are buttons that launch the corresponding tests; at the bottom is the site where AWFT will break through, and the result of the duel between the firewall and the utility. The Reset Points button is used to reset the accumulated points.

Just in case, I decided to change the site address to my own.

Testing took place with Comodo Firewall and Defense+ turned on, Opera running and Avira monitor turned off.

The first test used the technique of loading a hidden copy of the browser and patching the memory before launching it.

When I clicked the test button, a window popped up with an error:

After closing this window, Comodo responded to the test with a request window; when you clicked the “Block” button, AWFT, after thinking a little, gave the first point to the firewall.

According to the developers of the utility, test No. 2 is an old and well-known trick. Comodo responds again with a request window and again scores a point.

Test #3 also uses an old trick. Comodo simply silently blocks it, apparently, the trick is really well known.

Test No. 4 is similar to the first test with launching a hidden copy of the browser and patching the memory before launching it. The firewall did not give any warnings, but after a short pause it earned another point.

During the fifth and sixth tests, you need to switch to the browser and surf a little (I just refreshed the page loaded in the browser).

In test No. 5, the utility performs a heuristic search for authorized software installed on a computer (or network) that has access to the Internet via port 80, then launches a copy of the authorized program and, just before launch, patches the memory occupied by this program (i.e., AWFT launches itself in the memory of the allowed program). Comodo silently completed the test and received a whopping 3 points for it.

Test No. 6 is similar to the previous fifth test. The same technique is used with a heuristic search for installed software that has the right to exit through port 80. Only the hacking method has now been changed - a user request is used. At the same time, AWFT is trying to attach a hidden left toolbar to the browser. When I opened Opera, the following window popped up:

The moment I confirmed this user request, Comodo issued its request, the utility was blocked again, and the firewall received 3 points in its credit.

The result of the duel is 10:0 in favor of Comodo. Repeating the tests with Internet Explorer open, I got the same results.

Conclusion

Despite some bad aftertaste in my heart, remaining after testing the firewall, I still recommend Comodo Internet Security for home use, but only as a firewall. And don’t listen to those smart guys who advise turning off proactive protection, under no circumstances! Only with the use of Defense+ does this firewall truly ensure the security of your computer. But what you really shouldn't use is Comodo's antivirus. Not only does it skip quite a bit, but you will have problems updating it - its databases are very cumbersome. In addition, it significantly affects the performance of the system. Comodo Firewall and Avira Antivir Personal worked just fine for me.

I did not find any brakes or glitches in the system while the firewall was running. I’ll keep my thoughts on the results of my testing to myself for now; I’d like to hear your comments.

While writing the final part of this article, I came across the results of recent firewall testing by the Matousec laboratory. Comodo Internet Security was the only firewall with a 100% score (see firewall forum). Well, I made my choice... And you?

advantages (obvious):
free distribution,
availability of its own program database;
availability of proactive protection (Defense+);
ease of installation and initial setup;
very informative and convenient window with a summary;

pros (doubtful):
the presence of several operating modes;

cons (obvious):
annoying installation mode;
substitution of an executable file is not identified by proactive protection as a critical event;

cons (doubtful):
frankly unsuccessful antivirus.

Comparative testing of 21 popular firewalls for the quality of protection against attacks coming from inside the system. The test tested protection using 64 specially developed test utilities that checked protection of processes from termination, protection from standard internal attacks, protection from non-standard leaks, and protection from non-standard techniques for penetrating kernel mode.

Along with antivirus, a firewall is one of the main components of computer security. However, unlike antiviruses, objective tests of firewall performance are rarely carried out. We tried to close this gap by conducting a test of firewalls for protection against internal attacks in 2011 and 2012 and a test of personal IDS/IPS for protection against attacks on vulnerable applications. This year, we decided to expand the list of methods used and repeat the firewall test for protection against internal attacks to see how the results of popular products according to this criterion have changed over time.

What is this test aimed at or what functions does the firewall perform? According to the definition of the Internet standard [RFC3511] (2003), a firewall is a system that implements the functions of filtering network packets in accordance with specified rules in order to differentiate traffic between network segments. However, with the growing complexity of malware and hacker attacks, the original firewall tasks have been supplemented with new functional modules. It is virtually impossible to imagine a full-fledged firewall without a HIPS module (monitoring system events, monitoring system integrity, etc.).

The main task of a modern firewall is to block unauthorized network communications (hereinafter referred to as attacks), divided into internal and external. These include:

External attacks on a firewall-protected system:

• initiated by hackers;
• initiated by malicious code.

• initiated by untrusted applications (malicious code);
• initiated by applications whose network activity is explicitly prohibited by the rules.

In addition, products that could be classified as pure personal firewalls in the classic formulation of 2003 have virtually disappeared from the market. They have been replaced by comprehensive protection products personal computers, which necessarily include a firewall component.

A firewall test for protection against external attacks involves examining the quality of protection against attacks coming from within the system. The test was carried out in the following areas:

1. Checking protection of processes from termination.
2. Protection against standard internal attacks.
3. Testing protection against non-standard leaks.
4. Testing protection against non-standard techniques for penetrating kernel mode.

Compared to the previous test, the number of attacks used has increased significantly - from 40 to 64. The operating system that the tested products must protect has also changed. In the previous test it was Windows XP, and in this test it was Windows 7 x32. A similar test is also planned for the end of the year for the Windows 7 x64 operating system.

Introduction

The testing involved 21 popular comprehensive protection programs (Internet Security class; if there is no such product in the line, then a purely firewall was selected) from various manufacturers Product versions that are current as of the start date of testing (May 2013) and run on the Windows platform 7 x32 :

1. Avast! Internet Security (8.0.1488).
2. AVG Internet Security (2013.0.3272).
3. Avira Internet Security (13.0.0.3499).
4. Bitdefender Internet Security (16.29.0.1830).
5. Comodo Internet Security (6.1.276867.2813).
6. Dr.Web Security Space (8.0).
7. Eset Smart Security (6.0.316.0).
8. F-Secure Internet Security (1.77 build 243).
9. G DATA Internet Security (1.0.13113.239).
10. Jetico Personal Firewall (2.0).
11. Kaspersky Internet Security (13.0.1.4190(g).
12. McAfee Internet Security (11.6.507).
13. Kingsoft Internet Security (2009.05.07.70).
14. Microsoft Security Essentials (4.2.223.0) + Windows Firewall.
15. Norton Internet Security (20.3.0.36).
16. Online Armor Premium Firewall (6.0.0.1736).
17. Outpost Security Suite Pro (8.0 (4164.639.1856).
18. Panda Internet Security (01/18/01).
19. PC Tools Internet Security (9.1.0.2900).
20. Trend Micro Titanium Internet Security (6.0.1215).
21. TrustPort Internet Security (2013 (13.0.9.5102).

Before starting the test, the testing environment was prepared. To do this, the Windows 7 Enterprise SP1 x86 operating system with all updates available at that time, as well as additional software required for the test, was installed on a clean computer.

Testing was carried out on two types of settings: standard recommended by the manufacturer (default settings) and maximum. In the first case, the default settings recommended by the manufacturers were used and all actions recommended by the program were performed.

In the second case, in addition, all settings that were disabled in the “default” mode, but could still affect the outcome of the test, were turned on and/or brought to their maximum position (the most stringent settings). In other words, setting the maximum settings means transferring all settings available from the graphical user interface of all modules related to detecting malicious file or network activity to the most strict option.

The firewall test was carried out using to the following groups internal attacks, divided into difficulty levels for clarity:

1. Basic difficulty level (56 attack options):

1. checking the protection of processes from termination (41 attack options);
2. protection against standard internal attacks (15 attack options).

2. Increased difficulty level (8 attack options):

1. testing protection against non-standard leaks (3 attack options);
2. testing protection against non-standard techniques for penetrating kernel mode (5 attack options).

A detailed description of all attack methods used in the test can be found in the testing methodology.

Checking firewalls for protection against internal attacks

Let us remind you that according to the award scheme used, 1 point (+) was awarded if the attack was blocked automatically and the protective functionality of the program under test was not broken. 0.5 points (or +/-) - if the attack is blocked only under special circumstances (for example, when the user correctly selects required action at the request of the program under test). And finally, if the attack was successful in whole or in part and disabled the protection functionality, then no points were awarded. The maximum possible number of points scored in this test was 64.

Table 1-2 and Figure 1-2 show the results of testing firewalls separately on standard and maximum settings. For clarity, the results for each firewall are divided into two groups: protection against attacks basic level complexity and protection against attacks of an increased level of complexity.

Table 1: Firewall test results for standardArt settings

Tested product							Total points (max. 64)	Total %
	Points	%	% from the sum	Points	%	% from the sum
Comodo	53	95%	82,8%	6	75%	9,4%	59	92%
Online Armor	50	89%	78,1%	7,5	94%	11,7%	57,5	90%
Norton	45	80%	70,3%	6	75%	9,4%	51	80%
Jetico	46	82%	71,9%	4,5	56%	7,0%	50,5	79%
Outpost	45	80%	70,3%	2,5	31%	3,9%	47,5	74%
Trend Micro	42	75%	65,6%	3	38%	4,7%	45	70%
Kaspersky	42	75%	65,6%	2,5	31%	3,9%	44,5	70%
Dr.Web	42,5	76%	66,4%	2	25%	3,1%	44,5	70%
TrustPort	43	77%	67,2%	0,5	6%	0,8%	43,5	68%
G DATA	42	75%	65,6%	1	13%	1,6%	43	67%
Avast	41	73%	64,1%	1	13%	1,6%	42	66%
Eset	41	73%	64,1%	1	13%	1,6%	42	66%
Bitdefender	41	73%	64,1%	1	13%	1,6%	42	66%
AVG	41	73%	64,1%	0	0%	0,0%	41	64%
McAfee	41	73%	64,1%	0	0%	0,0%	41	64%
PC Tools	41	73%	64,1%	0	0%	0,0%	41	64%
Avira	40	71%	62,5%	0	0%	0,0%	40	63%
Microsoft	40	71%	62,5%	0	0%	0,0%	40	63%
F-Secure	31,5	56%	49,2%	1	13%	1,6%	32,5	51%
Panda	30	54%	46,9%	0	0%	0,0%	30	47%
Kingsoft	27	48%	42,2%	1	13%	1,6%	28	44%

Figure 1: Firewall test results on standard settings

Protection against internal attacks at the settings recommended by the manufacturer leaves much to be desired. Only three firewalls were able to overcome the 80% threshold on standard settings - Comodo, Online Armor and Norton. The products Jetico (79%) and Outpost (74%) are quite close to them. The results of other firewalls were significantly worse.

Compared to the results of the last test, all leaders confirmed their high results; there were only small movements within the leading group, for example, Outpost and Jetico swapped positions. The only surprise was the Norton product, which in the previous test showed a result of 45% and was at the bottom of the table, and in this test with 80% it took third position.

The results obtained are due to the fact that many manufacturers set the standard settings in such a way as to reduce the number of messages to which the user must respond. This is confirmed by the test results - at standard settings, firewalls asked questions to users only in 5.4% of attacks, and at maximum settings - in 9.2% of attacks. However, this affects the quality of the protection, which will remain silent in a situation where the malicious program imitates/performs completely legitimate actions in the system.

You should also pay attention to two patterns. Firstly, the percentage of prevention of complex types of attacks in general is noticeably worse than attacks of a basic level of complexity. More than half of these attacks were rejected by only four products - Comodo, Online Armor, Norton and Jetico. Four more products were included in the border group, rejecting from 25% to 38% of such attacks: Outpost, Trend Micro, Kaspersky and Dr.Web. All other products rejected no more than one complex attack. Secondly, the performance of repelling basic attacks has improved. If in the previous test 11 (50%) products rejected less than 50% of attacks, then in this test there were only 3 (14%) such products.

Table 2: Firewall test results at maximum settings

Tested product	Basic difficulty attacks (max. 56 points)			Attacks of a higher level of difficulty (max. 8 points)			Total points(max. 64)	Total %
	Points	%	% from the sum	Points	%	% from the sum
Comodo	56	100%	87,5%	8	100%	12,5%	64	100%
Bitdefender	56	100%	87,5%	8	100%	12,5%	64	100%
Online Armor	53	95%	82,8%	8	100%	12,5%	61	95%
Kaspersky	53	95%	82,8%	7	88%	10,9%	60	94%
Norton	50,5	90%	78,9%	8	100%	12,5%	58,5	91%
PC Tools	49,5	88%	77,3%	5,5	69%	8,6%	55	86%
Outpost	49	88%	76,6%	5,5	69%	8,6%	54,5	85%
Eset	49	88%	76,6%	5,5	69%	8,6%	54,5	85%
Dr.Web	46,5	83%	72,7%	5	63%	7,8%	51,5	80%
Jetico	46	82%	71,9%	4,5	56%	7,0%	50,5	79%
Trend Micro	43	77%	67,2%	3	38%	4,7%	46	72%
TrustPort	43	77%	67,2%	2,5	31%	3,9%	45,5	71%
G DATA	42	75%	65,6%	3	38%	4,7%	45	70%
Avira	41,5	74%	64,8%	2	25%	3,1%	43,5	68%
Avast	41	73%	64,1%	1,5	19%	2,3%	42,5	66%
AVG	41	73%	64,1%	0	0%	0,0%	41	64%
McAfee	41	73%	64,1%	0	0%	0,0%	41	64%
Microsoft	40	71%	62,5%	0	0%	0,0%	40	63%
F-Secure	31,5	56%	49,2%	1	13%	1,6%	32,5	51%
Panda	30	54%	46,9%	0	0%	0,0%	30	47%
Kingsoft	27	48%	42,2%	1	13%	1,6%	28	44%

Figure 2: Firewall test results at maximum settings

When the maximum settings were enabled, the quality of protection against internal attacks in many tested firewalls improved significantly. This is especially noticeable among strong middle peasants. All the leaders of the previous test also showed high results in this test. Among the changes, it is worth noting the Bitdefender product, which, along with Comodo, showed 100% results, and the Norton product, which moved to the leading group.

The results of a number of products on standard and maximum settings were the same. This is due to the fact that these products do not have settings that could affect the results of our test.

Comparison of protection quality at standard and maximum settings

Due to the logic of this test, we will not sum or average the results of the same product with different settings. On the contrary, we want to compare them and show significant differences in the quality of protection of the tested products depending on the settings used.

For clarity, we present the final results of the firewall test with standard and maximum settings in Table 3 and Figure 3.

Table 3: Summary results of the firewall test on standard and maximum settings

Product	Standard settings	Maximum settings
Comodo	92%	100%
Online Armor	90%	95%
Norton	80%	91%
Jetico	79%	79%
Outpost	74%	85%
Trend Micro	70%	72%
Kaspersky	70%	94%
Dr.Web	70%	80%
TrustPort	68%	71%
G DATA	67%	70%
Avast	66%	66%
Eset	66%	85%
Bitdefender	66%	100%
AVG	64%	64%
McAfee	64%	64%
PC Tools	64%	86%
Avira	63%	68%
Microsoft	63%	63%
F-Secure	51%	51%
Panda	47%	47%
Kingsoft	44%	44%

Figure 3: Summary results of the firewall test on standard and maximum settings

Figure 3 very clearly demonstrates the difference in test results depending on the selected settings.

Firstly, only two products – Comodo and Online Armor – show protection indicators close to the maximum, both at standard and at maximum settings.

Secondly, when changing the standard settings proposed by the manufacturer, some products show a significantly better level of protection. This is most clearly visible in products such as Bitdefender, Kaspersky, Eset, F-Secure and PC Tools.

Thirdly, as noted above, some of the tested products do not have settings at all that could in any way affect the test results. Therefore, their results for all types of settings in this test are the same. This group includes Jetico, Avast, AVG, McAffe, F-Secure, Panda, Kingsoft and Microsoft.

The final score does not take into account situations where the attack was repelled, but there were problems with the user interface of the products. In most cases, the problems consisted of the interface crashing for a short time (from 2 to 10 seconds) or until the next boot of the operating system. Although products continued to provide protection for user interface issues, the presence of such issues is subjectively perceived as negative and may influence product selection preferences. The number of problems with the user interface is presented in Table 3 and Figure 3. Errors arising from level 1 attacks were assessed, the total number of which was 41.

Table 4: Number of user interface problems on standard and maximum settings

Tested product	Standard settings		Maximum settings
	Number of mistakes	%	Number of mistakes	%
McAfee	34	83%	34	83%
Microsoft	33	80%	33	80%
Kingsoft	20	49%	20	49%
F-Secure	19	46%	19	46%
Panda	17	41%	17	41%
Jetico	16	39%	16	39%
PC Tools	13	32%	13	32%
Trend Micro	12	29%	12	29%
AVG	10	24%	9	22%
TrustPort	9	22%	9	22%
G DATA	9	22%	9	22%
Bitdefender	8	20%	8	20%
Norton	6	15%	6	15%
Avast	5	12%	5	12%
Outpost	5	12%	5	12%
Eset	5	12%	4	10%
Comodo	5	12%	0	0%
Avira	2	5%	2	5%
Dr.Web	2	5%	2	5%
Kaspersky	1	2%	1	2%
Online Armor	1	2%	1	2%

Figure 4: Number of UI problems on standard and maximum settings

The results show that McAfee and Microsoft products experienced user interface issues in the majority of attacks (more than 80%). This can be called an unacceptable level, because... Almost any successfully repelled attack will lead to problems. Quite poor results, ranging from 30% to 50%, are shown by products from Kingsoft, F-Secure, Panda, Jetico and PC Tools. When using them, every 2-3 attacks will lead to problems with the interface. A number of other products show results from 10% to 30%, which can be called satisfactory. Good results showed products Avira, Dr.Web, Kaspersky and Online Armor, problems for which occurred in the range from 2% to 5% of attacks. The only product that never had any problems with the user interface was Comodo at maximum settings, which can be admitted excellent result. However, with standard settings, the Comodo result deteriorates (12%), which suggests that using this product requires some knowledge of how to configure it.

Final test results and awards

Just like in the previous test, we did not average the results of the same product with different settings, but considered them independently of each other. Thus, each of the tested products can receive two awards, one for each type of setting.

In accordance with the award scheme, the best firewalls receive awards indicating the settings used, see Table 4.

Table 5: Final results of the firewall test on standard and maximum settings

Product being tested	Option settings	Attack Prevention [%]		Total [%]	Reward
		Base difficulty level	Increased difficulty level
Comodo	Max	100%	100%	100%	Platinum Firewall Outbound Protection Award
Bitdefender	Max	100%	100%	100%
Online Armor	Max	95%	100%	95%	Gold Firewall Outbound Protection Award
Kaspersky	Max	95%	88%	94%
Comodo	Standard	95%	75%	92%
Norton	Max	90%	100%	91%
Online Armor	Standard	89%	94%	90%
PC Tools	Max	88%	69%	86%
Outpost	Max	88%	69%	85%
Eset	Max	88%	69%	85%
Norton	Standard	80%	75%	80%
Dr.Web	Max	83%	63%	80%
Jetico	Max	82%	56%	79%	Silver Firewall Outbound Protection Award
Jetico	Standard	82%	56%	79%
Outpost	Standard	80%	31%	74%
Trend Micro	Max	77%	38%	72%
TrustPort	Max	77%	31%	71%
Trend Micro	Standard	75%	38%	70%
Kaspersky	Standard	75%	31%	70%
Dr.Web	Standard	76%	25%	70%
G DATA	Max	75%	38%	70%
TrustPort	Standard	77%	6%	68%	Bronze Firewall Outbound Protection Award
Avira	Max	74%	25%	68%
G DATA	Standard	75%	13%	67%
Avast	Max	73%	19%	66%
Avast	Standard	73%	13%	66%
Eset	Standard	73%	13%	66%
Bitdefender	Standard	73%	13%	66%
AVG	Max	73%	0%	64%
AVG	Standard	73%	0%	64%
McAfee	Max	73%	0%	64%
McAfee	Standard	73%	0%	64%
PC Tools	Standard	73%	0%	64%
Microsoft	Max	71%	0%	63%
Microsoft	Standard	71%	0%	63%
Avira	Standard	71%	0%	63%
F-Secure	Max	56%	13%	51%	No reward
F-Secure	Standard	56%	13%	51%
Panda	Max	54%	0%	47%
Panda	Standard	54%	0%	47%
Kingsoft	Max	48%	13%	44%
Kingsoft	Standard	48%	13%	44%

The best results in the test were shown by Comodo and Bitdefender firewalls, which scored 100% on maximum settings. These two products win an award PlatinumFirewallOutboundProtectionAward.

Very high results in the test (over 80%) were also shown by Online Armor, Kaspersky, Comodo, Norton, PC Tools, Outpost, Eset and Dr.Web firewalls, which received awards GoldFirewallOutboundProtectionAward. It is important to note that Comodo received this award on standard settings, Online Armor and Norton on standard and maximum settings, and all others only on maximum settings.

Next on the list is a group of seven firewalls whose results fall in the 60% to 70% range. These are Outpost, Kaspersky and Dr.Web with standard settings; TrustPort and G DATA at maximum settings, as well as Jetico and Trend Micro at both standard and maximum settings. They all get a reward

Enough large group Products falling in the range of 60% to 70% receive an award. It should be noted that Eset and Bitdefender products at standard settings were able to repel a significantly larger number of attacks at maximum settings.

You can view the detailed test results and ensure that the final calculations are correct by downloading the test results in Microsoft Excel format.

Shabanov Ilya, managing partner of the site:

“I was very pleased with the fact that many manufacturers have significantly improved proactive protection against internal attacks and self-defense in their products. We even had to revise the award scheme to raise the bar of requirements. A score of less than 51% was now considered a complete failure.

I was pleasantly surprised that Bitdefender repelled all 100% of attacks in paranoid mode, Eset and Dr.Web with results at maximum settings of 85% to 80%, respectively, as well as the newcomer to our tests, TrustPort. IN " gold group According to the results of this test, the products included firewalls Comodo, Norton and Online Armor, which scored more than 80% on standard and maximum settings. Consistently high results in tests involving proactive protection were demonstrated by Kaspersky, Outpost, and PC Tools.

However, in the case of a number of tested products, the logic by which the standard settings are set is unclear. As a result, the level of protection for most users who are accustomed to using protection with standard settings turns out to be significantly lower. This primarily applies to products from Bitdefender, Kaspersky, Eset and PC Tools.”

Mikhail Kartavenko, head of the testing laboratory website:

“Considering this test as a continuation of the previous similar test, we can identify several main trends and problems in the operation of firewalls.

Firstly, on average, most products showed better results than 1.5 years ago, but they did this mainly by repelling the simplest level 1 attacks. More complex attacks are tough on only a limited range of products.

Secondly, even if the protection of processes from termination (1st attack level) worked, the user interface of many products crashes. This puts the user in an awkward position in which he does not understand whether the protection is working or not.

Thirdly, there is a fairly large gap in the performance of firewalls on standard and maximum settings. As a result, an acceptable level of protection can often only be obtained by experienced users who know and can properly configure firewalls.

Thus, the test identified the pain points of modern firewalls, the solution of which can improve their protection.”