Desktop Firewalls and Intrusion Detection
(abridged edition by Marinais, 03.11.2005)
Candid W\"uest
Swiss Federal Institute of Technology Zurich,
Computer Engineering and Networks Laboratory
Diploma Thesis DA�2003.22 Winter Term 2002/2003
Tutors:
Diego Zamboni (IBM R\"uschlikon Res. Lab),
Marc Rennhard
Supervisor:
Prof. Dr. Bernhard Plattner 28.02.2002�08.02.2002
Abstract
The use of desktop firewalls has become more and more popular these days.
The goal of this thesis is to analyze the use of desktop firewalls in detail,
to get a better understanding of their capabilities, strengths and weaknesses.
Because they are installed on end-user machines together with other applica-
tions, the question arises whether they can add security or whether they open
new security holes in the controlled machine. An interesting idea is to analy-
ze the cooperation of multiple instances of desktop firewalls with intrusion
detection systems (IDSs). Therefore, rules for detecting attacks with the log
files gathered will be established and a generic desktop firewall log file
format will be introduced that enables to correlate the corresponding events
from the different log files.
Chapter 1
Introduction
1.1 Motivation
It has become common to have an Internet connection at an every location.
Often it is running during day and night. Even at home many people have a PC
that is connected to the Internet 24 hours a day. During these long time peri-
ods the machines are exposed to the threats of the Internet. The longer a ma-
chine is connected, the more likely it is to be affected by a malicious acti-
vity. New technologies like wireless networks increase even more the risk of
getting attacked, as they introduce new possibilities of it. With all the re-
cent events of computer viruses and worms spreading through the Internet and
causing damage, users slowly but surely realize that there is a danger in the
Internet and that they need a protection against it [7].
In small companies the level of security is often not that high, and even
in big enterprises with good security policies it is not unusual that the em-
ployees take their laptops from their office back home and connect them to
their local Internet connections. At this moment all the data, which were pro-
tected through the enterprise security measures before, are exposed to a pos-
sible attacker. After a successful breaking into this machine it can, when
brought back into the corporation's network, infect other machines in the int-
ranet. Therefore, people have started using desktop firewalls to protect them-
selves against attackers. Having an anti-virus product installed is nothing
unusual today, but having a desktop firewall running is still not so common.
In contrast to the traditional model, where firewalls are recommended to
be installed on a dedicated and well-controlled machine, desktop firewalls are
installed on end-user machines together with a wide variety of tools and app-
lications. Therefore, the question arises whether they provide additional se-
curity or whether they are also vulnerable to new attacks and decrease the
overall security. To provide more security the log files of the desktop fire-
walls should be analyzed and considered when monitoring a network for attacks.
There has been no effort yet in the direction of correlating the logged events
of desktop firewalls, and also good detailed tests on the capabilities of des-
ktop firewalls are rare [1]. The available test results are normally consumer-
oriented and do not go into much detail [4].
This thesis is not intended to be another comparison study of desktop
firewalls regarding their ease of use or how nice they look. Rather, it should
as the first phase provide information about the concept of desktop firewalls
in general and whether using them to protect user machines makes sense from a
security point of view. In the second phase the thesis provides mechanisms to
correlate the generated events, making it possible to integrate the desktop
firewalls into a security framework. Until now the logged data are nearly al-
ways discarded and not further used in any way. Only if there occurred a prob-
lem that needs further investigation, these log files might be analyzed. Thin-
king of all the possibly valuable logged information, that is unused, is
enough motivation to take a closer look at the further use of this informa-
tion.
1.2 Related work
By the time of writing this thesis I was not aware of any work that is
directly related to the idea of this topic. Most of the works on correlating
log files target only network firewalls and not desktop firewalls themselves
[12]. We can find some log file analyzers that are able to process desktop fi-
rewall log files. A good example for this is "Symantec's Deep Sight" tool, al-
so used at "Security Focus", which is able to look through some desktop fire-
walls log files, for example, "Zonelabs Zonealarm" [2]. "DShield" is another
tool that lets users submit their log files for a collective examination [6].
Normally they are limited to a few widely-used desktop firewalls and do not
support many different versions of them. Another problem with these tools is
that the users will often not get a detailed analysis of the attacks on their
home network. The information is just added to a pool and analyzed over all
the events of all the submitters.
If we already have a security infrastructure, then we probably want to be
able to further process the events with all their relevant information on our
own. Submitting data to others might also not be compliant with the security
policies. Tools like "DShield" cover more or less just the idea of sending the
log files to a third party, which will then generate statistics, such as the
ports scanned most frequently, but they will not provide a detailed report of
the attacks that have been run against the machines. In addition, we are not
able to integrate the results easily into the correlation engine for the deci-
sion process.
There are few short articles about the topic of this thesis pointing out
the idea of using desktop firewalls as cheap sensors in an intrusion detection
network. One of them is by Marcus J. Ranum [1], but it does not go into de-
tails on how it would be implemented and what could be gained out of using
desktop firewalls as intrusion detection sensors. It only mentions that it
would probably make sense to do so.
On the other side, there have been plenty of examinations of desktop fi-
rewalls, and nearly every PC user magazine has published a review of a desktop
firewall examination. The problem with those articles is that they are mainly
dedicated to help an end-user to choose a product that is easy to manage. This
means the focus seldom lies on the core technology and the real capabilities
of the desktop firewalls but rather on how nice the graphical user interface
(GUI) looks or how fast the support hotline is. This kind of test is valuable
for a consumer, but still missing are tests that analyze the concept of "be-
hind the curtain". One of the more technical examinations of desktop firewalls
can be found at Boran's website [3]. Some websites have done generic tests of
desktop firewalls with so called "leak test tools" to see if it is possible to
send out an information from a protected system. Many of them are very succes-
sful and claim that desktop firewalls are unsafe and useless. Unfortunately,
some of them used attacks from which a desktop firewall was never meant to
protect and, thus, failed. Therefore, some of the applied techniques have been
taken into account in the examination part of this thesis. The causes of fail-
ing to protect from certain attacks are investigated later in Chapter 5. The
mentioned websites can be found at PC flank [5] or in the article [4].
1.3 Desktop firewalls
1.3.1 Desktop firewall technology
For quite a long time people in the IT security field have been using
network firewalls to secure their networks. A network firewall can be a hard-
ware device or a software program running on a dedicated machine. In either
case it must have at least two network interfaces: one for the network it is
intended to protect and one for the network it is exposed to. A network fire-
wall sits at the junction point or gateway between the two networks, usually a
private network and a public network such as the Internet. The earliest compu-
ter firewalls were simple routers. All a traffic that is passing the network
firewall is inspected, and, if it fulfills the defined criteria, it will be
allowed or otherwise blocked [17]. But for a normal computer user at home a
network firewall is usually too complex or too expensive. This is often the
reason, why the common home users would not use a network firewall even if
they wanted to protect themselves. This has led to the idea of desktop fire-
walls.
Desktop firewalls, sometimes also referred to as "personal firewalls" or
"distributed firewalls", target end users and do not try to replace network
firewalls. They intend to be easy to set up and maintain. Most desktop fire-
walls are preconfigured so that the user is not bothered with difficult rule
programming, and, if later an unknown event occurs, a wizard will help in cre-
ating the necessary rules.
As the name implies, desktop firewalls are host-based applications and
run on the user's machine. Therefore, they are only able to see a traffic that
is directed to the monitored machine.
A desktop firewall is usually a stateless packet filter. "Stateless"
means the filter does not track the state of a connection, it decides for each
packet on an individual basis to either permit it or to block it [17]. On the
other side, stateful filters do accept packets only if they are possible in
the actual connection state. Therefore, a stateless packet filter is an appli-
cation that can accept packets, examine their headers independently and then
decide whether to forward them, depending on whether they meet the rules defi-
ned by the user. They work on the level of IP packets. Disadvantage of state-
less inspection is that packets which would not be possible in a certain state
of communication still may pass the desktop firewall.
Desktop firewalls typically do not implement packet content filter. This
means they do not inspect the payload of the packet to see if it consists of a
malicious content. Only the headers of the packets are inspected by desktop
firewalls.
1.3.2 Reasons for desktop firewalls
The main purpose of a desktop firewall is to monitor and eventually block
an incoming and outgoing network traffic on a machine according to the wishes
of the user. This is normally done by applying some filter rules to the pac-
kets. So far, the behavior does not differ much from a standard network fire-
wall, except that network firewalls filter a traffic dedicated to multiple ma-
chines and desktop firewalls check only the packets targeting a one local ma-
chine.
Desktop firewalls can, additionally, check the name of the application
that opens the connection. This enables them to filter certain applications in
the rules. This means that filtering rules not only may contain IP addresses
but also may refer to trusted or untrusted application names, offering a finer
tuning of the rules.
The purposes of a desktop firewall can be classified in two categories.
First, it should protect from attacks that come from outside and are targeting
the monitored machine. This includes attacks such as port scans, misuse of
open daemons, like network shares, and DoS attacks. The second category is the
attacks or threats originating from the inside of the system, such as a trojan
horse server that tries to connect home or an adware tool that wants to send
some personal information back to its vendor. This should be blocked or at
least monitored and alerted by the desktop firewall.
There are a lot of reasons why we should use a desktop firewall solution,
even if we are considering it for a machine that is located behind a full-fea-
tured network firewall.
The first reason is employing a second line of defense to prevent attacks
and to secure the system. Given the fact that desktop firewalls have a diffe-
rent configuration and also different vulnerabilities than network-based fire-
walls, an attacker would have to breach two security systems. Searching for
two different exploits that work together decreases the chance of a successful
attack. Furthermore, those external firewalls which normally are placed on the
network border will not help if the attacker is coming from the inside of the
network. According to several surveys, most attacks come from the local net-
work [13]. Even if we fully trust our co-workers, we can never be sure that
their machines have not been broken into and are used against us.
Another benefit of a personal firewall is that it makes use of the local
context. Furthermore, it has access to data such as the name of the applica-
tion that opens a connection and not only to the IP address of the machine.
Taking this additional information into account it is possible to make deci-
sions on subtle distinctions. For example, assume that some adware has managed
to install itself on the machine and is trying to send some personal data back
to a marketing company by HTTP transmission. The majority of external firewall
products are configured to permit this traffic, as it looks like a legitimate
HTTP traffic. On the other hand, a properly configured desktop firewall would
at least alert us before sending the packets and tell us the name of the of-
fending application. However, not only with minor threats, like adware, a des-
ktop firewall is useful, in fact also with computer worms they help. As recent
cases show, computer worms spread so fast that most users will not have a
chance to update their anti-virus signatures to catch them. For example, the
computer worm "SQL.Slammer" (also known as "Hellkern" or "Sapphire") doubled
the number of the infected machines every 9 s in the first minutes of its out-
break [8]. After 11 min it was spread all over the Internet. Desktop firewalls
do a fairly good job in preventing those computer worms from spreading in the
network, as they block outgoing connections to the network for unknown appli-
cations. So, if the worm would try to send itself out from an infected machi-
ne, it would be blocked by the desktop firewall and would be prevented from
infecting other machines. Although in this scenario the infection of the first
machine was not prevented, the danger is still stemmed.
Many home users think they are safe at home. They often argue: "Why
should someone be interested in my data, it is nothing valuable and if I loose
some of the data, I don't really care". Even when agreeing with these points,
it still makes sense to install a desktop firewall. Especially home users with
a permanent Internet connection, such as DSL users, are more and more the tar-
get of attackers. They are not after secret data, but they can use those sys-
tems as stepping stones to obfuscate their true origin while attacking other
systems. For example, these systems could be used as sources for DoS flood at-
tacks.
Most of the above mentioned scenarios could also be detected using an in-
trusion detection system (IDS). The difference is that an IDS is normally used
for detecting attacks and not for preventing or protecting against them. An
IDS can tell if a trojan horse is trying to call home from the machine, but it
may not block a traffic, as it is not intended to do so. This means that IDSs
are not a replacement for desktop firewalls. Still most desktop firewall ven-
dors have started to include features to report known attacks that have been
detected, similar to intrusion detection systems. So they present the user
with an additional information about the recorded events. Another added fea-
ture is content filtering, which enables the desktop firewall to control the
information that is stored in cookies, block advertisement pop-ups or control
the execution of an active content like ActiveX in webpages on an individual
basis for the user.
Finally, as this report will show, another reason for using desktop fire-
walls is to use them as an additional information source that could help in
getting a better view of the overall security state. The log files provide an
information that can be used in the process of correlating alarms and respond-
ing to attacks.
1.4 Approach
The approach followed in this thesis is to first think of possible attack
scenarios on different levels targeting the desktop firewalls. For these rea-
sons a small test network is set up, with all the desktop firewall products to
be tested running in parallel on identically configured machines. By running
the chosen attacks set we can verify if the desktop firewalls are able to pro-
tect against those specific attacks. This experiment gives an overview of the
capabilities of desktop firewalls. The generated log files are collected for
further inquiries.
Analyzing the logged events leads to a generic event log format for desk-
top firewalls. Three Perl scripts are developed in this thesis, which trans-
late the log files into the generic event log format. In order to find corre-
lation rules for these alarms, the generated log files are analyzed. To verify
the made conclusions, a real world experiment is made with multiple desktop
firewalls running in a network.
Chapter 2
Specification of desktop firewalls
In this chapter the products chosen for testing are introduced and their
features are explained.
2.1 Selected products
Most Unix systems or Linux derivatives have already full featured fire-
walls included, that have little in common with desktop firewalls on Windows
systems. Therefore, I decided to choose only Windows-based desktop firewalls
for my test series. Non-Windows desktop firewall would probably distort the
result of the tests, because they are implemented like normal network fire-
walls and lack some of the special features that are common among the other
desktop firewalls. As the purpose of this thesis is to reflect a real user si-
tuation, products from the whole range of the market segment are chosen. The
selected desktop firewalls are the following:
Name: Zonealarm
Version: 3.1.395
Vendor: Zonelabs
Website: http://www.zonelabs.com
Type: freeware
Supported OS: Win98/ME/NT/2K/XP
Name: Symantec Desktop Firewall
Version: 2.01
Vendor: Symantec
Website: http://www.symantec.com
Type: commercial
Supported OS: Win95/98/ME/NT/2K/XP
Name: Sygate Personal Firewall
Version: 5.0.1150
Vendor: Sygate
Website: http://soho.sygate.com
Type: free for personal use
Supported OS: Win95/98/ME/NT/2K/XP
They where chosen because they represent a good overview of what can be
found on the market, regarding the small office and home user market. If any-
where in this thesis one of the names above appears without further indication
of the version, then the specific versions listed above, are assumed.
2.2 Features of desktop firewalls
In this section some of the interesting features of the desktop firewalls
chosen will be explained. The focus will be set on the logging and rule op-
tions, as they play the main rule in this thesis, but also other helpful fea-
tures will be mentioned. This list is not meant to be complete, as some fea-
tures like "live update" are not explained here.
2.2.1 "Zonealarm"
"Zonelabs's" desktop firewall provides two different zones of trust, the
"Internet zone" and the "trusted zone". For each zone the user can add IP ad-
dresses or networks. Both the zones may have different security settings. The
provided security can be one of three levels, either high, medium or low. In
the program control settings for each application we can define the rights in
the Internet zone and the rights in the trusted zone. Further, we can specify
if the application should be able to act as a server, making it possible for
it to wait for incoming connections. The possible options are: "allow",
"block" or "ask".
A feature that is not related to the main firewall but still interesting
is "mailsafe". It is a basic protection from Visual Basic script viruses in
e-mails. The idea is to move a script to a safe location and make sure, that
it does not execute automatically. This is achieved by monitoring the e-mail
traffic.
As an additional feature, a panic button is implemented, that switches
the desktop firewall into the "block all" mode when pressed. This can be use-
ful if the user notices some abnormal behavior of the system.
There is no possibility to add advanced custom rules which use filtering
options based on port numbers. This means each application will have the
rights to use all ports, when allowed to communicate with the network.
2.2.2 "Symantec desktop firewall"
The "Symantec Desktop Firewall" has two main categories: security and
privacy.
In "security" the user has an option to select one of the three predefi-
ned levels: high, medium or low. These three levels are settings for the in-
ternal options. They are split in three topics: desktop firewall, Java applets
and ActiveX. For each of these groups we can once more choose one of the three
protection levels. For desktop firewall this means: high � block everything
until the user allows it; medium � block known malicious applications; none �
allow any traffic. The other two groups can be set to either block, prompt
each time or allow the traffic.
Additionally, there are two more options. One for enabling alerts which
will be displayed in the task bar icon and one for silently blocking unused
ports. The latter means that a traffic which is directed to an unused port and
not matched by any filtering rule will be blocked, as if there was a rule to
do so.
The second category is privacy. A slider allows the user to set one of
three predefined levels of security: high, medium or minimal. These are bound
to the internal settings for cookie blocking (block, prompt or allow) and for
confidential information blocking (block, prompt or allow). A "confidential"
information can be any information that we enter in a custom field, for examp-
le, the last 4 digits of the credit card number. If enabled, the desktop fire-
wall attempts to make sure that this information does not leave the machine.
"Symantec Desktop Firewall" has, further, an ability to block an IGMP
traffic and also to block fragmented IP packets. Both the ones are often used
in DoS or Nuke attacks, which try to crash the system with intentionally craf-
ted packets.
"Symantec Desktop Firewall" offers a possibility to enable an automatic
firewall rule creation wizard. This wizard tool has an internal database of
known applications and corresponding default rules. If the desktop firewall
notices a new application that wants to access the network, the automatic fi-
rewall rule creating wizard will look up the name in the database and check if
it is a known application. When it is a known application, it will create the
corresponding rules automatically, without asking us. This can lead to prob-
lems if we want to have non-standard rules for standard applications like
browsers.
In the advanced option section we are able to set some more privacy rules
on a per-domain name basis. This allows blocking user-agent strings, cookies,
referrer and e-mail names from being submitted to websites.
Connections can be filtered by setting up rules in the rule editor. These
rules can match incoming or outgoing packets and filter them according to cri-
teria like: protocol, application name, port numbers or the IP addresses used.
The action on a filtered packet can be to allow it, block it or ignore
it. Ignoring means that the packet will be logged but not blocked.
For special events an alarm flag can be raised, which will be displayed
in the system tray icon.
2.2.3 "Sygate Personal Firewall"
"Sygate Personal Firewall" offers three different modes of operating le-
vels: "block all", "allow all" and normal.
Block All means that all transmissions incoming and outgoing are
prevented.
Allow All means that any traffic will be allowed from and to the
protected machine. Still it will write a log event if a
rule was matched.
Normal means that custom defined filtering rules will be applied.
There is an application table that remembers all the rights that we have
given the applications on a per-application basis. It has the following
fields:
FileName: the name of the application;
Version: the version (build number) of the application;
Access: the access status that was applied to this application
(either Block, Ask or Allow);
Path: the location of the application.
For all applications it is also possible to create an advanced rule. Tho-
se rules can filter a traffic of the applications with additional fields like
IP addresses or port numbers. Each application can be granted the right to
send or receive a traffic during screensaver mode or during specified time pe-
riods.
Further, it is possible to define advanced rules for connections. Each
rule can be set to filter packets according to the protocol, the IP addresses,
the MAC addresses or the port numbers they use. All rules can be bound to mul-
tiple applications. The action on a filtered packet can be to allow it or to
block it. A rule can be set to apply only during a specified time period or
during screensaver mode.
Instead of logging to a file, the firewall can inform about unusual
events by sending an e-mail. This can be done immediately when the alarm oc-
curs or regularly on a time interval basis.
"Sygate Personal Firewall" provides a driver-level protection. This fea-
ture blocks protocol stacks from accessing the network unless the user allows
it. If some application installs its own protocol stack and tries to bypass
the personal firewall, it will be detected.
The feature called "DLL authentication" provides a method to determine
which DLLs are associated with an application and mark them in an internal
table. All DLLs not marked will be blocked from accessing the network.
2.3 Logging capabilities
2.3.1 "Zonealarm"
"Zonealarm" provides a possibility of logging into a plain text file in a
straightforward format. It is not in real time, because it goes through an
internal buffer before getting flushed, but it is nearly real time because the
delay is less than a second. Each event is reported on a separated line con-
taining the fields separated by commas. Below is shown the format and a sample
fragment of a "Zonealarm" log file.
�������������������������������������������������������������������������Ŀ
�field name � example � content format �
�������������������������������������������������������������������������Ĵ
�Type �FWIN �FWIN|FWOUT|FWLOOP|LOCK|PE|ACCESS|FWROUTE|MS�
�Date �2002/11/26 �YYYY/MM/DD �
�Time �11:38:02 +1 GMT �HH:MM:SS +n GMT �
�Source �192.168.0.66:3244�IP address:Port �
�Destination�192.168.0.10:80 �IP address:Port �
�Transport �TCP(flags:s) �TCP(flags:x)|UDP|ICMP|IGMP|N/A �
���������������������������������������������������������������������������
FWIN,2002/11/26,13:21:22 +1:00 GMT,10.10.50.42:63348,10.10.50.2:17978,TCP (fl�
ags:S)
FWIN,2002/11/26,14:07:22 +1:00 GMT,192.168.0.9:0,10.10.50.2:0,ICMP (type:8/su�
btype:0)
FWIN,2002/11/26,14:22:00 +1:00 GMT,10.10.50.4:0,10.10.50.2:0,IGMP
FWIN,2002/11/25,13:41:36 +1:00 GMT,192.168.0.9:0,10.10.50.2:0,IGMP (type:2/su�
btype:31)
FWIN,2002/11/26,15:31:46 +1:00 GMT,192.168.0.9:7617,10.10.50.2:42,UDP
ACCESS,2002/11/28,14:05:58 +1:00 GMT,,N/A,N/A
ACCESS,2002/11/28,14:05:58 +1:00 GMT,flood.exe was temporarily blocked from c�
onnecting to the Internet (10.10.50.3).,N/A,N/A
PE,2002/11/28,14:09:06 +1:00 GMT,flood.exe,10.10.50.3:0,N/A
PE,2002/11/28,10:10:46 +1:00 GMT,Internet Explorer,192.168.0.9:80,N/A
FWOUT,2002/11/28,14:09:08 +1:00 GMT,10.10.50.2:96,10.10.50.3:66,TCP (flags:S)
FWOUT,2002/11/28,14:09:36 +1:00 GMT,10.10.50.2:0,10.10.50.3:0,IGMP
FWOUT,2002/11/25,14:37:40 +1:00 GMT,10.10.50.2:53,10.10.50.2:53,UDP
FWROUTE,2002/11/28,14:09:58 +1:00 GMT,0.0.0.0:96,10.10.50.3:66,UDP
FWROUTE,2002/11/28,14:11:28 +1:00 GMT,0.0.0.0:0,10.10.50.3:0,ICMP (type:8/sub�
type:0)
2.3.2 "Symantec Desktop Firewall"
"Symantec Desktop Firewall" logs six different things in separate log fi-
les, which will be explained later. The internal representation is encoded in
hexadecimal and uses a proprietary format. Unfortunately, "Symantec" does not
provide any explanation about the format of these files. There exists a func-
tion to export the log files to plain text, but there is some information dis-
carded from the original log file, like the subtype of the protocol. The fol-
lowing sample extracts are all taken from the exported log files and, there-
fore, are in plain text. The six different log files are explained in the next
subchapters.
Content blocking log
Stored in the file iamtdi.log. This file records the information about
blocked ActiveX or Java applets. The user has an option to enable this filter-
ing in three different levels: low, medium and high. This feature is not di-
rectly relevant for the experiments of this thesis, because the events do not
contain an information about intrusion attempts. Therefore, this log file was
not further inspected.
Connections log
Stored in the file iamtcp.log. This file records all incoming and outgo-
ing connections including ports, time stamp and number of bytes sent. Especi-
ally the last information could be interesting, for example, for checking if
an attack was successful or not. This logging is not influenced by the filter
rules. Below is shown an example of "Symantec Desktop Firewall's" connection
log.
1/28/2003 18:00:48 Connection: 192.168.0.33: http from 192.168.0.2: 1802, 537�
bytes sent, 1380 bytes received, 3:35.268 elapsed time
1/28/2003 18:00:12 Connection: 192.168.0.66: http from 192.168.0.2: radius, 3�
162 bytes sent, 8352 bytes received, 21.451 elapsed time
1/28/2003 17:59:54 Connection: 192.168.0.66: http from 192.168.0.63: radacct,�
503 bytes sent, 221 bytes received, 0.650 elapsed time
Firewall log
Stored in the file iamfw.log. This is the main log file. It records all
incoming and outgoing connections as specified with the filter rules. Each
event is reported on multiple lines. As observed, the number of lines can vary
from three to six. As the table below shows, the event records do not follow
any strict formatting rules. This fact makes it a bit elaborate to parse the
events into the generic event log format which is introduced in Chapter 6.
11/25/2002 14:39:05 Rule "Default Outbound ICMP" permitted (10.10.50.4,systat�
). Details:
Outbound ICMP request
Local address is (10.10.50.1)
Remote address is (10.10.50.4)
Message type is "Time Exceeded for a Datagram"
Process name is "N/A"
11/26/2002 14:14:30 Blocked inbound IGMP packet. Details:
Remote address (10.10.50.4)
Local address (10.10.50.1)
11/27/2002 16:39:53 Rule "block all" blocked (10.10.50.1,441). Details:
Inbound TCP connection
Local address,service is (10.10.50.1,441)
Remote address,service is (10.10.50.4,44614)
Process name is "N/A"
1/27/2003 14:08:45 Rule "Eudora HTTP" blocked (192.168.0.7,http). Details:
Outbound TCP connection
Local address,service is (0.0.0.0,2683)
Remote address,service is (192.168.0.7,http)
Process name is "C:\Program Files\Qualcomm\Eudora\Eudora.exe"
11/26/2002 15:24:28 Rule "block all" blocked (10.10.50.1,nameserver). Details:
Inbound UDP packet
Local address,service is (10.10.50.1,nameserver)
Remote address,service is (192.168.0.2,15897)
Process name is "N/A"
Privacy log
Stored in the file iampriv.log. This file records privacy-related events,
for example, sending cookies or the browser user-agent identifier. Because
these data are not directly related to intrusion attacks, this log file will
not be further analyzed.
System log
Stored in the file iamsys.log. This file records operational messages,
such as starting and stopping a service. In the scope of the experiments of
this thesis these alarms where not analyzed as they have no direct impact. In
future work it would make sense to include this log file for completeness. In
some scenarios it could be of interest to have this information. For example,
when an attack has successfully shut down the desktop firewall even if the at-
tacker should not be able to do so.
Web-history log
Stored in the file iamwebh.log. Similar to a web-browser history file,
this log file records all the visited URLs with time and date. Unless we want
to keep track of people who visit blocked webpages, this file will not be of
interest for the further experiments and, therefore, is not analyzed.
2.3.3 "Sygate Personal Firewall"
"Sygate Personal Firewall" logs events into four different log files:
system log, security log, traffic log and packet log. The log files itself are
encoded in hexadecimal, but there is a function to export them into plain text
messages from the log view console.
Additionally, there is a debug log file named debug.log in the same cata-
log, which contains an information like when the GUI was started or which dri-
ver where loaded with the firewall. As the name implies, it is just for debug-
ging reason and was not used in the experiments of this thesis.
All of these log files can be displayed in two different modes: "local
view" or "source view". The only difference is that they call two fields "re-
mote host" & "local IP" in the first mode and "destination host" & "source IP"
in the other mode. Actually, I could not figure out why this feature was imp-
lemented, since the information stays the same. It is just that these two
fields are swapped. A normal end user might get irritated and confused by this
option. To simplify matters I have made the tests always using the "source
view" mode.
System log
Stored in the file syslog.log. This file records all operational changes,
such as the starting and stopping of services, detection of network applica-
tions, software configuration modifications and software execution errors. The
system log is especially useful for troubleshooting but is not used for corre-
lation aspect. For the scope of this thesis this aspect was not included. In
future work it would make sense to include this log file for completeness. In
some scenarios it could make sense to have this kind of information, like when
the service started and stopped. Below is an example "Sygate Personal Fire-
wall" system log file.
*************** Windows Version info ***************
Operating System: Windows 2000 (5.0.2195 Service Pack 2)
*************** Network info ***************
No.0 "Local Area Connection" 00-04-ac-44-ab-ba "Intel 8255x-based PCI Ethernet
Adapter (10/100)" 10.10.50.3
96 01/22/2003 16:00:38 Information 12070202 Start Sygate Personal Firewall...
97 01/22/2003 16:00:38 Information 12070202 Sygate Personal Firewall has been�
started.
98 01/22/2003 16:00:38 Information 12070305 Security level has been changed t�
o Normal
99 01/22/2003 16:00:54 Information 12070305 New Option Settings is applied
100 01/22/2003 16:01:14 Information 12070305 New Advance rule has been applied
101 01/22/2003 16:01:20 Information 12070204 Stopping Sygate Personal Firewal�
l....
102 01/22/2003 16:01:24 Information 12070204 Sygate Personal Firewall is stop�
ped
103 01/22/2003 17:02:08 Information 12070201 Sygate Personal Firewall 5.0.1150
Security log
Stored in the file seclog.log. This file records potentially threatening
activities directed toward the machine, for example, port scanning or DoS at-
tacks. The security log is like a simple IDS console that lists events that
have been generated from the traffic log. Below is shown the format and a sam-
ple fragment of a "Sygate Personal Firewall" security log file.
����������������������������������������������������������������������������Ŀ
� field name � description �
����������������������������������������������������������������������������Ĵ
�Event number �events consecutively numbered �
�Time �date and time when the event was logged �
�Information �message of the alarm �
�Severity �severity of the alarm (Critical, Major, Minor or�
� �Information) �
�Direction �direction from the context of the User �
�Protocol �type of protocol (TCP, UDP or ICMP) �
�Destination �IP address of the machine being attacked �
�Source �IP address of the machine the traffic was coming�
� �from �
�Destination port or ICMP�destination port number or the type of the ICMP�
� �traffic that was sent �
�Source port or ICMP �source port number or the type of the ICMP traffic�
� �that was sent �
�Count �number of events of this type that where logged �
�Application �name of the application that was involved �
�Begin time �time that the attack attempt began �
�End time �time that the attack attempt ended �
������������������������������������������������������������������������������
113 11/28/2002 10:04:56 Executable File Change Denied Major Outgoing TCP 10.1�
0.50.4 0.0.0.0 C:\Program Files\Internet Explorer\IEXPLORE.EXE 1 11/28/2002�
10:04:52 11/28/2002 10:04:52
114 11/28/2002 10:05:19 Executable File Change Accepted Information Outgoing �
TCP 10.10.50.4 0.0.0.0 C:\Program Files\Internet Explorer\IEXPLORE.EXE 1 11�
/28/2002 10:05:15 11/28/2002 10:05:15
56 11/26/2002 14:02:59 Denial of Service Major Incoming ICMP 192.168.0.8 10.1�
0.50.3 1 11/26/2002 14:02:52 11/26/2002 14:02:52
58 11/26/2002 14:45:34 Denial of Service Major Incoming Unknown 10.10.50.4 10�
.10.50.3 7 11/26/2002 14:45:32 11/26/2002 14:45:34
105 11/27/2002 15:55:24 Port Scan Minor Incoming TCP 10.10.50.4 10.10.50.3 6 �
11/27/2002 15:55:18 11/27/2002 15:55:19
Traffic log
Stored in the file tralog.log. This file records every packet information
of a traffic that enters or leaves a port on the monitored machine. Below is
shown the format and a sample fragment of a "Sygate Personal Firewall" traffic
log file. The first time field (time) is the time of when the alarm was gene-
rated, the second time field (begin time) is when the reported attack has
started and the third time field (end time) is when the attack ended. This
means that the time marks behave always like: begin time =< end time =< time.
��������������������������������������������������������������������������Ŀ
� field name � description �
��������������������������������������������������������������������������Ĵ
�Event number�events consecutively numbered �
�Time �date and time when the event was logged �
�Action �action taken by the firewall (Blocked or Allowed) �
�Protocol �type of protocol used in the attempt (TCP, UDP, ICMP or Unk- �
� �nown) �
�Direction �direction from the context of the user (Incoming or Outgoing)�
�Source �IP address of the machine the traffic was sent from �
�Destination �IP address of the machine attacked �
�Application �name of the application that was involved �
�Count �number of events of this type that where logged �
�Begin time �time that the attack attempt began �
�End time �time that the attack attempt ended �
����������������������������������������������������������������������������
56 11/25/2002 14:22:54 Blocked UDP Incoming 127.0.0.1 53 10.10.50.3 53 2 11/2�
5/2002 14:22:32 11/25/2002 14:22:50 Block_all
57 11/25/2002 14:22:54 Allowed UDP Incoming 10.10.50.4 138 10.10.50.255 138 C�
:\WINNT\System32\ntoskrnl.exe 1 11/25/2002 14:22:52 11/25/2002 14:22:52 GUI�
%GUICONFIG#SRULE@NBENABLEYOU#ALLOW-UDP
30545 11/26/2002 14:01:10 Blocked ICMP Incoming 192.168.0.9 0 10.10.50.3 8 1 �
11/26/2002 14:00:51 11/26/2002 14:00:51 Block_all
1460410 11/28/2002 14:08:22 0.0.0.0 0 0.0.0.0 0 Outgoing Blocked C:\sygate_DF�
W\exploits\flood\flood.exe
Packet log
Stored in the file rawlog.log. This file captures every packet of data
that enters or leaves the computer. It can be thought of as a network sniffer
that is not in promiscuous mode. This logging option is turned off by default,
because it may consume a lot of disk space.
Unfortunately, the exported packet log does not contain the raw packets
but instead just the information that is already provided in the traffic log,
like source and destination IP address, for example. To extract the packet
content, we would have to write our own parser for their format which is not
publicly available. Once having the packet information from the raw log file,
we would have to create matching rules for all possible attack events. This is
just the raw packet information, without any pattern matching rules applied.
To check if these packets are malicious, different filtering rules must be ap-
plied to the packet content. This is exactly the job that an IDS already can
do. Reinventing the wheel does not make sense and would have exceeded the sco-
pe of this thesis. Therefore, this log file, even though it is one of the best
sources for information, was not further analyzed in this thesis, because in
the exported format it provides the same information as the traffic log file.
Below is shown the format and a sample fragment of a "Sygate Personal Fi-
rewall" packet log file. As mentioned, these messages do not include the full
packet, because the full packet is only recorded in the internal representa-
tion in the rawlog.log file.
���������������������������������������������������������������������������Ŀ
� field name � description �
���������������������������������������������������������������������������Ĵ
�Event number �events consecutively numbered �
�Time �date and time when the event was logged �
�Source �IP address of the machine the traffic was sent from �
�Source port �source port number �
�Destination �IP address of the machine attacked �
�Destination port�destination port number �
�Direction �direction from the context of the user (Incoming or Outgo-�
� �ing) �
�Action �action taken by the desktop firewall (Blocked or Allowed) �
�Application �name of the application that was involved �
�����������������������������������������������������������������������������
1019023 01/22/2003 15:41:01 10.10.50.4 80 10.10.50.3 1038 Outgoing Allowed C:�
\WINNT\system32\telnet.exe
1019034 01/22/2003 15:44:00 10.10.50.4 80 10.10.50.3 1040 Incoming Allowed C:�
\Program Files\Internet Explorer\IEXPLORE.EXE
1019035 01/22/2003 15:44:07 10.10.50.2 138 10.10.50.255 138 Incoming Blocked �
C:\WINNT\System32\ntoskrnl.exe
Chapter 3
Test environment
This chapter explains the setup of the testbed used for running the at-
tacks against the desktop firewalls to be tested and introduces the assump-
tions made and the goals of the experiments.
3.1 Goals of testing
In the Internet we can find some websites that provide firewall tests
specific for personal firewalls [3]. All the found tests simply do a port scan
of an IP address and report the ports open. This will only show misconfigura-
tion problems, but as the presumption in this thesis is that the desktop fire-
walls are well configured to their best possible level, we do not have to care
about these problems.
Having open ports is not dangerous per se, as long as the service is
meant to be accessible from the Internet. In the default installation all per-
sonal firewalls will block the incoming traffic and ask the user for each app-
lication if it should be allowed or not. So, I have my doubts that these test-
ing sites really help in checking the security of desktop firewalls. Somehow,
they make the end users think that they have a secure system, probably leaving
other open holes undiscovered.
Therefore, the idea of this thesis was to focus on design faults and ho-
les in the concept of desktop firewalls, which could not be fixed by reconfi-
guring the desktop firewall. Some of the problems might be patched by the
vendor in later versions, some might never get fixed, because they address
difficulties that the desktop firewalls have not been intended to solve. But
once analyzed and discovered, those loopholes can be avoided or secured with
other mechanisms. So, the focus was really set to find attacks that cover the
whole range of possible scenarios, which will be discussed in Chapter 4.
A second goal of the testing process is, of course, to generate log fi-
les, which later can be used to generate the correlation schema. For this pur-
pose the desktop firewalls have been configured to log all the important in-
formation. With the help of a small batch script the generated log files have
been moved to separate catalogs for each attack, to make a later analysis ea-
sier.
3.2 Assumptions
The emphasis of this thesis is the concept of desktop firewalls, therefo-
re, issues related to weaknesses of operating systems or attacks that are only
possible because of a flawed configuration of the firewall itself are not co-
vered.
Therefore, it is assumed that the underlying operating system has been
fully patched with all the necessary updates and is running stable. The desk-
top firewalls are assumed to run with a reasonable rule set that results in
the maximum of security that could possibly be achieved. For this the default
configuration of each desktop firewall is adapted, according to its possibili-
ties. All the outgoing traffic is blocked except for the "Internet Explorer",
which is granted access permissions for destination TCP port 80, 8080 and 443.
These represent the standard webserver port, an additional webserver port and
the SSL connection port. Incoming communications are only accepted for a Tel-
net server on TCP port 21. This setup was chosen to represent real world con-
ditions and not just block any traffic by default, because simply blocking any
traffic is not a reasonable option. The logging process is set up to the pos-
sible maximum of details, so that no information is lost in this step.
3.3 Testbed
For testing purposes four machines are set up in a small network. All of
them are "IBM PL300" desktop machines with "Pentium II" 350 MHz processors and
128 Mb of RAM. Three machines are identically installed with "Windows 2000"
and "Service Pack 2". On each system, one of the desktop firewalls to be test-
ed is installed. The fourth machine is used as the attack machine and has a
dual boot system for "Windows 2000" with "Service Pack 2" and "RedHat Linux
8.0". All the machines are connected to an isolated 100 Mbit network through a
"Netgear Hub". On all Windows systems an administrator account and a restric-
ted user is created.
Chapter 4
Attacks
In this chapter the attack scenarios used will be explained in detail
showing the impact that they can have.
4.1 Description of attacks used
Since the idea of this thesis was to check the strengths and weaknesses
of the desktop firewalls and not of the operating system, the focus of the
attacks targets the firewall itself.
The attacks set includes many ideas which require modifications on the
local machine to work. For justifying this we can think of a virus or a trojan
horse that was executed on the target system and can now make the desired mo-
difications. As normal antivirus tools mostly do their detection based on sig-
natures, it is obvious that a new malware application will not be detected.
This fact brings us to the conclusion that expecting some malware running un-
noticed on our machine is not such a devious idea. Therefore, assuming that
local modifications have taken place for some attacks is not so absurd.
Tools for all the used attacks that I have not programmed myself can be
found for free in the Internet. I did not include them in this thesis paper as
it is against the Swiss federal law to provide a source code or a detailed
help about working exploits. I decided not to include the descriptions of the
tools, because this work is not about the attack tools themselves. Rather, it
is about showing that it would be possible and illustrating the problems. A
technical reader will be able to perform the same tests by using similar tools
or program his own ones for this purpose.
The figure below shows the used attack tree from where the different sce-
narios were derived.
�ATTACK���>�Local����>�Attack trusted application����>�Misuse trusted�����ķ
� ��� � ��� � ��� �application ��
������ͼ�� ������ͼ�� ��������������������������ͼ�� ��������������������ͼ�
��������� ��������� ����������������������������� ����������������������
� � ��>�Memory injection���ķ
� � � � ��
� � ��>��������������������ͼ�
� � �� ����������������������
� � ��>�Modifying rule set�ķ
� � �� � ��
� � ��>��������������������ͼ�
� � �� ����������������������
� �>�Attack desktop firewall����ij�>�Push the YES buttonķ
� � ���� � ��
� ��������������������������ͼ��� ��������������������ͼ�
� ������������������������������ ����������������������
� ��>�Tunneling����������ķ
� � � ��
� � ��������������������ͼ�
� � ����������������������
�>�Remote���>�Attack desktop firewall�������>�Spoofed traffic����ķ
� ��� � ���� � ��
������ͼ�� ��������������������������ͼ��� ��������������������ͼ�
��������� ������������������������������ ����������������������
� ��>�Sniffing�����������ķ
� �� � ��
� �� ��������������������ͼ�
� �� ����������������������
� ��>�Avoiding visibilityķ
� �� � ��
� �� ��������������������ͼ�
� �� ����������������������
� ��>�Resources exhaustion�
� �� � ��
� �� ��������������������ͼ�
� �� ����������������������
� ��>�Process killing����ķ
� �� � ��
� �� ��������������������ͼ�
� �� ����������������������
� ��>�Mutex blocking�����ķ
� �� � ��
� �� ��������������������ͼ�
� �� ����������������������
� ��>�Flood��������������ķ
� �� � ��
� ��>��������������������ͼ�
� �� ����������������������
� ��>�Modifying log file�ķ
� � � ��
� � ��������������������ͼ�
� � ����������������������
� ��>�Alarm flooding�����ķ
� � ��
� ��������������������ͼ�
� ����������������������
�>�Information gathering���������>�Port scan����������ķ
� �� � ��
��������������������������ͼ� ��������������������ͼ�
���������������������������� ����������������������
�Misuse trusted���������>�Steal application rights���>�Pass certain filter�
�application ��� � ��� � ��
��������������������ͼ�� ������������������������ͼ�� �������������������ͼ�
����������������������� ��������������������������� ���������������������
�Memory injection������� �
� �� �
��������������������ͼ� �
���������������������� �
�Modifying rule set�����>�Add custom rule����������Ĵ
� ��� � ���
��������������������ͼ�� ������������������������ͼ��
����������������������� ���������������������������
�Push the YES button���� �
� �� �
��������������������ͼ� �
���������������������� �
�Tunneling������������Ŀ �
� ��� �
��������������������ͼ�� �
����������������������� �
�Spoofed traffic��������>�Trusted source's rights����
� ��� � ��
��������������������ͼ�� ������������������������ͼ�
����������������������� ��������������������������
�Sniffing�������������Ĵ
� ���
��������������������ͼ��
�����������������������
�Avoiding visibility����>�Bypass filter engine�������>�Bypass filtering��ķ
� �� � ��� � ��
��������������������ͼ� ������������������������ͼ�� �������������������ͼ�
���������������������� ��������������������������� ���������������������
�Resources exhaustion�Ŀ �
� ��� �
��������������������ͼ�� �
����������������������� �
�Process killing��������>�Disable desktop firewall���
� ��� � ��
��������������������ͼ�� ������������������������ͼ�
����������������������� ��������������������������
�Mutex blocking�������Ĵ
� ���
��������������������ͼ��
�����������������������
�Flood������������������ �Information loss�����������>�Information leak��ķ
� �� � �� � ��
��������������������ͼ��>������������������������ͼ� �������������������ͼ�
����������������������� �������������������������� ���������������������
�Modifying log file���Ĵ
� ���
��������������������ͼ��
�����������������������
�Alarm flooding�������Ĵ
� ���
��������������������ͼ��
�����������������������
�Port scan��������������
� ��
��������������������ͼ�
����������������������
We describe now the different groups of attacks which will be used to
test the desktop firewalls. This should explain the ideas of the attacks and
also the impact that they could have.
4.1.1 Process killing
Description: Locally try to stop the running desktop firewall process.
Required access: Local.
Idea: Stop the desktop firewall process.
Impact: Disabling the desktop firewall.
Leads to: Bypass the incoming and outgoing filter.
Variations: Send termination message as the administrator or as a normal
user.
4.1.2 Memory injection 1
Description: Inject a process into the memory space of the desktop fire-
wall.
Required access: Local.
Idea: Pretend to be a part of the firewall process.
Impact: Use access rights of the firewall.
Leads to: Bypass the incoming and outgoing filter.
Variations: Have a DLL loaded into this memory space, then allocate the
memory for a function called by the firewall's working memo-
ry.
4.1.3 Information gathering
Description: Do a port scan to gather information about the protected sys-
tem.
Required access: Remote.
Idea: Gain as much information as possible about the system for
further attacks.
Impact: Information leak.
Leads to: Possible specific succeeding attack.
Variations: Use special stealth scan techniques, like XMAS scan.
4.1.4 Memory injection 2
Description: Inject a process into the memory space of a trusted applica-
tion.
Required access: Local.
Idea: Pretend to be a part of the trusted application.
Impact: Filter of the trusted application will be applied to the
traffic.
Leads to: Bypass the incoming and outgoing filter.
Variations: Have a DLL loaded into this memory space, then allocate the
memory for a function called in the application's working me-
mory.
4.1.5 "More info" button
Description: Try to catch the information that is sent out when a user
clicks on the "more info" button and is redirected to the
vendor's page.
Required access: Remote.
Idea: Some desktop firewalls send the version number and IP addres-
ses to the website for getting an additional information.
Impact: Information leak.
Leads to: Possible specific succeeding attack.
4.1.6 Incoming flood
Description: Send a huge amount of a traffic to the desktop firewall.
Required access: Remote.
Idea: Use all resources to temporary or permanently disable the
desktop firewall.
Impact: Disabling the desktop firewall.
Leads to: Bypass the incoming and outgoing filter.
Variations: Use different protocols like TCP, UDP, ICMP or IGMP for
flooding. Use specially crafted packets like SYN or FYN pac-
kets. Vary the load of the traffic. Use spoofed random source
addresses. Use the same target and source address for the
packets.
4.1.7 Outgoing flood
Description: Send a huge amount of a traffic from the machine the desktop
firewall is running on.
Required access: Local.
Idea: Use all resources to temporary or permanently disable the
desktop firewall.
Impact: Disabling the desktop firewall.
Leads to: Bypass the incoming and outgoing filter.
Variations: Use different protocols like TCP, UDP, ICMP or IGMP for
flooding. Use specially crafted packets like SYN or FYN pac-
kets. Vary the load of the traffic. Use random target IP add-
resses and random spoofed source IP addresses. Use the same
target and source address for the packets.
4.1.8 Spoofed packets
Description: Send special packets with 127.0.0.1 as the source IP address.
Required access: Remote.
Idea: Pretend a traffic to come from a trusted loopback device.
Impact: Filter of the trusted source will be applied to the traffic.
Leads to: Bypass the incoming filter.
Variations: Use different protocols like TCP, UDP, ICMP or IGMP. Use spe-
cially crafted packets like SYN or FYN packets.
4.1.9 Replacing a binary
Description: Replace a trusted application with a malicious tool which has
the same name and path.
Required access: Local.
Idea: Impersonate the trusted application.
Impact: Filter of the trusted application will be applied to the
traffic.
Leads to: Bypass the incoming and outgoing filter.
Variations: Replace the hash value of the trusted application which is
stored by the desktop firewall for detection of misuse.
4.1.10 Sniffing
Description: Use a packet sniffer to receive a traffic before it gets dis-
carded by the desktop firewall.
Required access: Local.
Idea: Receive a traffic before it gets blocked later.
Impact: No incoming filter will be applied to the traffic.
Leads to: Bypass the incoming filter.
Variations: Use a different kind of network sniffer.
4.1.11 Mutex blocking
Description: Block the mutex of the desktop firewall.
Required access: Local.
Idea: Prevent the desktop firewall from loading.
Impact: Disabling the desktop firewall.
Leads to: Bypass the incoming and outgoing filter.
4.1.12 Tunneling
Description: Use allowed protocols for communication by hiding a real
traffic in new packets.
Required access: Local.
Idea: Repack the traffic in a different protocol, and use the cor-
responding ports to send and receive the traffic.
Impact: Filter of the trusted application will be applied to the
traffic.
Leads to: Bypass the incoming and outgoing filter.
Variations: Use different protocols, for example, HTTP, SMTP or ICMP to
hide packets.
4.1.13 Different IP stack
Description: Use a different IP stack to send and receive the packets.
Required access: Local.
Idea: The desktop firewall does not see the traffic.
Impact: No filtering will be applied to the traffic.
Leads to: Bypass the incoming and outgoing filter.
Variations: Install a new network driver. Install a layered service pro-
vider to send the traffic.
4.1.14 Avoiding visibility
Description: Make the process invisible for the desktop firewall.
Required access: Local.
Idea: Use a kernel patch to hide the applications from API calls.
Impact: No filtering will be applied to the traffic.
Leads to: Bypass the outgoing filter.
Variations: Use different root-kits for Windows systems.
4.1.15 Resource exhaustion
Description: Consume all the available resources on the protected machine.
Required access: Local.
Idea: Consume all the available resources to probably crash the
desktop firewall or at least temporary disable it.
Impact: Disabling the desktop firewall.
Leads to: Bypass the incoming and outgoing filter.
Variations: Try different resources like CPU time or memory.
4.1.16 Modifying log file
Description: Modify the log file of the desktop firewall.
Required access: Local.
Idea: Remove the traces after a successful attack.
Impact: Fake log files events.
Leads to: Misinformation.
Variations: Add alarms of attack that have not taken place. Delete the
complete log file.
4.1.17 Modifying rule set
Description: Modify the rule set of the desktop firewall.
Required access: Local.
Idea: Edit the rule set so that any traffic is allowed.
Impact: Add a custom rule.
Leads to: Bypass the incoming and outgoing filter.
Variations: Add new specific rules or edit the existing rules.
4.1.18 Push the "yes" button
Description: Write an application that automatically pushes the "yes" but-
ton of the rule creation wizard when a new rule should be
created.
Required access: Local.
Idea: Automatically create a rule for the malicious application.
Impact: Add a custom rule.
Leads to: Bypass the incoming and outgoing filter.
Variations: Use the wizard to create an allow-all rule.
4.1.19 Alarm flood
Description: Try to overflood the desktop firewall with alarm events.
Required access: Remote.
Idea: Too many alarms might overwrite the older alarms in the log
file.
Impact: Information loss.
Leads to: An unnoticed attack.
Variations: Use different log file sizes.
4.1.20 Misuse a trusted application
Description: Remotely control a trusted application having it communicat-
ing to the network. Use COM objects to open a browser window
that is hidden. Let it access a special webpage to exchange
information.
Required access: Local.
Idea: Pretend to be the trusted application.
Impact: Filter of the trusted application will be applied to the
traffic.
Leads to: Bypass the outgoing filter.
Chapter 5
Results
This chapter presents the results found while testing the desktop fire-
walls and explains the occurred design problems of them.
5.1 Results of attacks
5.1.1 Process killing
Description of attack:
As a restricted user try to terminate the running desktop firewall pro-
cess. When successful, this will disable the firewall and stop its services
and, thus, offer full access to the Internet. If not successful, try the same
with the administrator rights.
Tool used:
"Process Xplorer" from "Sysinternals" [11].
"Zonealarm":
Selecting the process Zonealarm.exe and sending a termination message
will end the firewall processes including the "TrueVector" service VSmon.exe
which does the filtering. Although during the experiment sometimes the "True-
Vector" did not terminate correctly. Therefore, it seems better to first stop
the VSmon.exe and then stop Zonealarm.exe separately. Zonealarm will notice
that TrueVector service is no longer running and will ask the user if it
should be restarted, but, if we kill Zonealarm too, this does not matter.
When the firewall was in "block all" mode, also known as "panic mode",
then after killing the process no further network connection is possible. It
seems that in this case a low level driver is injected into the network stack
to prevent any communications. By terminating the process the protection in
the network driver will not be removed as it is not the process itself which
blocks the traffic. It should be investigated what exactly gets installed by
the process, to be able to see if it can be removed by an attacker.
"Symantec Desktop Firewall":
Logged in as a restricted user it is possible to kill the process IAMAPP.
EXE. Unfortunately, this will only terminate the system tray icon. Examining
the startup shows that the first process starts another tool called NISSERV.
EXE. This process is responsible for the traffic filtering. Therefore, killing
it is what we want. During the experiment it was not possible to kill it as a
restricted user, but it went to a state where it did not respond and did not
perform filtering anymore. With an administrator rights terminating the fire-
wall process was not a problem.
If this is not an option, then the idea would be to remove the registry
key at:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run : IAMAPP
disabling the autostart of the firewall. Next time the system restarts, the
firewall will not be loaded.
"Sygate Personal Firewall":
Even when being logged on as an administrator, it is not possible to ter-
minate the SCM.EXE process of the firewall directly. It includes several
threads that constantly check for termination messages and try to block them
or restart the service. This is a clever idea.
Thus, it is not possible to terminate the process directly, but indirect-
ly it is possible. If we list all open handles of the firewall process, we can
see a one that is named "\Default" and is of type "Desktop". If we close this
handle, then soon a "Dr. Watson" message will appear and tell that the process
SMC.EXE has generated errors and will stop now. Even when we do not click on
the "OK" button of this message, after 15 s (on an idle system) the process
will terminate and leave the system unprotected. There is an option to set a
password for starting and stopping the firewall service, but this feature will
not prevent from the above explained attack as the password prompt will not
appear.
General conclusion
For all the three tested products it is possible to terminate the fire-
wall process. This can be implemented by a computer virus or a trojan horse,
giving it full access to the Internet after the shutdown of the firewall. Of
course, it is not easy to design a process that cannot be stopped by a malici-
ous application executed by a user since one of the requirements of a desktop
firewall is that the user is able to disable it when needed. This leads to a
problem that an attacker could theoretically use the desktop firewall configu-
ration utility and remove all unwanted functions, ending up with an applica-
tion that shuts down the firewall process. Therefore, I am not aware of a re-
liable method of ensuring that the desktop firewall process is not stoppable,
unless we remove the right of the normal user to start and stop the firewall.
Counter measure
"Sygate Personal Firewall" is on the right way but should improve its
service some more, so that it will be impossible, at least for a normal rest-
ricted user, to shut down the firewall.
5.1.2 Memory injection
Description of attack:
Load a malicious program into the memory space of a trusted application
by allocating memory space for a function in its working memory space and
starting a thread there.
Tool used:
"BackStealth"
Unfortunately, this version of "BackStealth" was not compatible with the
firewall versions of our test candidates, since it was designed for older ver-
sions of them. As the time line for this thesis was short, it did not allow to
code a custom memory injection for the three firewalls. This means the test
with this tool could not be performed.
According to the information available, I assume that it would be possib-
le to successfully inject a code into a trusted application. Generic code ex-
amples for this exist in different programming languages on the Internet. For
example, on "MADshi's" website source code for injecting own functions into
applications can be found [15]. Researches showed that some trojan horses like
"Assasin" already use similar techniques to bypass desktop firewalls.
5.1.3 SYN flood 1, total random
Description of attack:
Flood the target machine with TCP packets, which have the SYN flag set.
The packets are crafted with random source IP addresses, random source ports
and random destination ports.
Tool used:
"HGOD_flood.exe"
"Zonealarm":
Reports each packet as a different event. No special event message is ge-
nerated. No DoS behavior occurs.
"Symantec Desktop Firewall":
Reports each packet as a different event. No special event message is ge-
nerated. No DoS behavior occurs.
"Sygate Personal Firewall":
Reports each packet as a different event. No special event message is ge-
nerated. The CPU utilization goes up to 100% during the attack.
General conclusion
This kind of attack cannot be reduced to a one single event message, as
the events are different. Each packet has a different source IP address and
cannot be distinguished from the nonrelated traffic. Anyhow, no DoS behavior
should occur.
Counter measure
Make sure that no DoS behavior occurs by observing memory and CPU usage.
Maybe, also block packets on a lower layer. SYN floods should be detected and
reported with an alarm event.
5.1.4 SYN flood 2, random ports
Description of attack:
Flood the target machine with TCP packets, which have the SYN flag set.
The packets are crafted with static source IP address, random source ports and
random destination ports.
Tool used:
"HGOD_flood.exe"
"Zonealarm":
Reports each packet as a different event. No special event message is ge-
nerated. No DoS behavior occurs.
"Symantec Desktop Firewall":
Reports each packet as a different event. No special event message is ge-
nerated. No DoS behavior occurs.
"Sygate Personal Firewall":
Reports each packet as a different event. In the system log a port scan
is reported several times from the same IP address. No DoS behavior occurs.
General conclusion
This attack should get reported as a port scan or as a DoS attack. There
is no good argument for a one or the other alarm, as it could be both of them.
Therefore, reporting it as a port scan is not wrong, as for the desktop fire-
wall it looks like a port scan.
Counter measure
There is no real need to do anything against this kind of attack, as the
traffic gets blocked at the desktop firewall. No response will be sent back to
the attacker.
5.1.5 SYN flood 3, static
Description of attack:
Flood the target machine with TCP packets, which have the SYN flag set.
The packets are crafted with static source IP address, static source port and
static destination port.
Tool used:
"HGOD_flood.exe"
"Zonealarm":
Reports all packets in a one event message with an increasing counter.
The summarized count was very small, so it must have dropped some packets. No
special event message is generated. No DoS behavior occurs.
"Symantec Desktop Firewall":
Reports each packet as a different event. The summarized count was very
small, so it must have dropped some packets. No special event message is gene-
rated. No DoS behavior occurs.
"Sygate Personal Firewall":
Reports all packets in a one event message with an increasing counter.
After an irregular amount of time a new event message will be written, as long
as the attack is going on. No special event message is generated. No DoS beha-
vior occurs. Some packets seem to be dropped during the attack.
General conclusion
This attack should be reported as a DoS attack. Of course, it could be a
port scan, as mentioned in Section 5.1.4, but after monitoring few identical
packets always coming from the same source port and targeting the same desti-
nation port, a port scan can be excluded. This behavior would not make sense
for a port scan, however, it is regular for a DoS attack.
Counter measure
There is no real need to do anything against this kind of attack, as the
traffic gets blocked at the desktop firewall. No response will be sent back to
the attacker. However, the attack should get reported with a special event
message of DoS attack.
5.1.6 SYN flood 4, heavy
Description of attack:
Flood the target machine with TCP packets which have the SYN flag set.
The packets are crafted with random source IP addresses, random source ports
and random destination ports. About 300 Kb/s of network load was generated,
which is a lot for the test network.
Tool used:
"HGOD_flood.exe"
"Zonealarm":
After a short time CPU utilization goes up to 100% and stays there until
the end of the attack. Switching the "Block All" button on will not protect
the system from this DoS attack.
"Symantec Desktop Firewall":
After a short time CPU utilization goes up to 100% and stays there until
the end of the attack.
"Sygate Personal Firewall":
After a short time CPU utilization goes up to 100% and stays there until
the end of the attack. Switching the "Block All" button on will not protect
the system from the DoS attack. The firewall needs more then 60 s to recover
from the attack. During the experiment the firewall still used up to 100% of
CPU time for 80 s after an attack of 15 s. After an attack of 30 seconds the
firewall needed 100 s to recover.
General conclusion
For all the three firewalls it was possible to make a remote DoS attack.
This makes it possible to temporary block a protected target machine.
Counter measure
A DoS attack should not be possible. Dropping the packets should be done
as early as possible in the stack. It is a difficult issue to deal with, sin-
ce, at some point of network load, there will be no possibility for the recei-
ving network card to work properly anymore on all the packets. This behavior
would also occur if it there is no firewall running on the machine. Still the
firewall should prevent from such attacks.
5.1.7 ICMP flood
Description of attack:
Flood the target machine with ICMP packets, type echo request, with spoo-
fed source IP addresses.
Tool used:
"HGOD_flood.exe"
"Zonealarm":
Reports each packet as a different event. No special event message is ge-
nerated.
"Symantec Desktop Firewall":
Reports each packet as a different event. No special event message is ge-
nerated.
"Sygate Personal Firewall":
Reports each packet as a different event. Reports a DoS attack on ICMP
protocol in the system log. Regardless of the spoofed source addresses, the
firewall reports only a few source IP addresses.
General conclusion
This kind of attack cannot be reduced to a one single event message, as
the events are different. Each packet has a different source IP address and
cannot be distinguished from the nonrelated traffic.
Counter measure
None needed.
5.1.8 IGMP flood 1
Description of attack:
Flood the target machine with IGMP packets. The packet size was set to
1480 bytes, which means no fragments. No spoofed source IP address was used.
Tool used:
"HGOD_flood.exe"
"Zonealarm":
Reports all packets in a one event message with an increasing counter. No
DoS behavior occurs.
"Symantec Desktop Firewall":
Reports each packet as a different event. No DoS behavior occurs. The fi-
rewall has an option to block an IGMP traffic, but I was not able to see any
difference with this option enabled. Maybe, this feature only blocks the badly
crafted packets used for a "kiss of death" attack [20] and not any IGMP traf-
fic in general.
"Sygate Personal Firewall":
The firewall does not support IGMP protocol. Therefore, no packets are
seen and no events are generated. During the attack 100% of CPU time is used.
After the attack was stopped, it recovered back to normal. If the raw packet
log is enabled, then the packets will be logged there, but no events in the
traffic log are generated.
General conclusion
All desktop firewalls should be able to see and log an IGMP traffic. No
DoS behavior should occur.
Counter measure
Implement IGMP filter into the desktop firewall.
5.1.9 IGMP flood 2
Description of attack:
Flood the target machine with ICMP packets. The packet size was first set
to 1481 bytes and then to 65 000 bytes to have multiple fragmented packets. No
spoofed source IP address was used.
Tool used:
"HGOD_flood.exe"
"Zonealarm":
Reports all packets in a one event message with an increasing counter. No
DoS behavior occurs.
"Symantec Desktop Firewall":
Reports each packet as a different event. No DoS behavior occurs.
"Sygate Personal Firewall":
After a short time the CPU load goes up to 100%. It generates an event in
the system log for a DoS attack with an unknown protocol. If we have a look at
the raw packet log, we notice that a half of the packets are blocked and a
half of them are permitted. Because a payload of 1481 bytes generates two
fragmented packets.
When the packet size is set to 65 000 bytes, which will generate 44 frag-
mented packets, then 43 out of 44 packets are unblocked, as they do not have
the offset bit set to 0 and the more fragments bit is set to 0. The system log
will report a DoS attack. It seems that only fragmented packets get reported
to the DoS attack detection engine.
When pushing the "Block All" button during the attack, the CPU load rare-
ly goes back to less then 80%, most often it remains at 100%. Pressing this
button before the attack starts will limit the CPU usage of the firewall to
50% and keep it at this level during the attack. This is, of course, not what
normally will happen, because we do not know in advance when an attack will be
launched.
General conclusion
The same conclusions as for the first IGMP flood attack in Section 5.1.8.
5.1.10 UDP flood
Description of attack:
Flood the target machine with UDP packets with random source IP addresses
and random source ports using a packet size of 1000 bytes.
Tool used:
"HGOD_flood.exe"
"Zonealarm":
Reports each packet as a different event. No DoS behavior occurs.
"Symantec Desktop Firewall":
Reports each packet as a different event. No DoS behavior occurs.
"Sygate Personal Firewall":
Reports all packets in a one event message with an increasing counter. No
DoS alarm is created, although the CPU utilization was 100% during the attack.
General conclusion
No DoS behavior should occur.
Counter measure
Change the implementation of the filtering engine so that no DoS behavior
occurs.
5.1.11 Modifying rule set
Description of attack:
Locate where the desktop firewall stores the rule set. Modify it to add
custom rules which will not be detected as suspicious, thus, giving a malici-
ous application the privileges that it needs to communicate to the Internet.
"Zonealarm":
Stores the rules for the applications in a file called IAMDB.RDB, which
on a "Windows 2000" system can be found at C:\WINNT\internetlogs\. The file is
machine independent. This means that we can replace this file and its copy,
the file BACKUP.RDB, with a modified version from another machine. While the
firewall is running, it has this file opened in a non-shared mode. As discuss-
ed in Section 5.1.1, it is possible to terminate the firewall process and,
thus, end the lock on the rule file, making it possible even for a restricted
user to replace the rule set.
"Symantec Desktop Firewall":
Stores all the rules in plain text in the registry. The corresponding re-
gistry key is:
\HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\IAM\FirewallObjects\IPFilterRules\Rule1
Here we can find all the rule related details, like the direction or protocol.
It is simple for an attacker to insert a rule at the top of the ordering that
will allow any traffic through the firewall.
"Sygate Personal Firewall":
Stores the rule set in a file called STDDEF.DAT in its default installa-
tion catalog. The file is machine independent. This means that we can replace
this file with a modified version from another machine. While the firewall is
running, it has this file opened in a non-shared mode. As discussed in Section
5.1.1, it is possible to terminate the firewall process and, thus, end the
lock on the rule file, making it possible even for a restricted user to repla-
ce the rule set.
General conclusion
The rule file is the brain of a desktop firewall. If we are able to modi-
fy these entries, then the use of the whole firewall is at danger. In the ex-
periments it was possible to add custom rules for all the three tested fire-
walls. This method can be implemented by a trojan horse to add an allow-all
rule, thus, being able to communicate with the Internet without restrictions.
Counter measure
The rule set can be encrypted and protected with a message authentication
code (MAC), but all the data, especially the key that is needed to decrypt it,
would have to be stored locally on the same machine. Otherwise, the firewall
would not be able to read the rules after a reboot of the machine. However,
assuming that the secret key is stored locally makes it possible for another
application to read it and further more use it to decrypt the rule data.
If it is opened by the firewall in a non-shared mode by blocking the abi-
lity of another process to access this file, the question arises if it is sto-
red somewhere in memory where it could be manipulated?
Even if this is not the case, it is possible to terminate the current fi-
rewall process and, thus, also stop the exclusive access mode of the rule fi-
le, leaving it unprotected, as we have seen in Section 5.1.1.
Another possibility is that the first time, when the user installs the
desktop firewall, it asks for a password. With this password the rule set will
be signed using an asymmetric encryption schema. Each time the firewall
starts, it can use the public key to check the signature of the rule file to
verify if the file has been altered. If the user wants to modify some rule, he
supplies his private key, and the rule file gets updated. This could work if
there was not a problem that a malicious user could simply replace the rule
set and provide the corresponding public key for it, so that the verification
method would accept it. The problem in this setup is that we cannot relay on
any data as they have to be stored locally and, therefore, can be altered by
an attacker. The public key is not authentic as it can be replaced. Moving the
verification process to another machine is not practical.
The rule files could be installed with administrator rights, having a
small service running which accepts only calls from the user interface for mo-
difying requests. In this way it would be possible to protect the rule file
from direct altering, as a normal user has not the rights to modify this file.
But the problem is that a normal user wants to be able to change his rule
configuration. Having a possibility for a normal user to change the rules al-
ways makes it possible for a malicious application to use the same methods.
For example, we can think of a modified version of the user interface that
automatically installs an allow-all rule when started. For skeptics, think of
the following scenario. A malicious application makes a screenshot of the ac-
tual user desktop. Then it displays this picture as an image on the top of the
everything and disables the keyboard. For a normal user this will look like
his machine has frozen. Behind this image the tool emulates mouse clicks and
key strokes to the desktop firewall. This way the tool can create an allow-all
rule like the normal user would have done it. In the end the screenshot pic-
ture will be removed and the user did not notice that a new rule was
installed.
"Sygate Personal Firewall" is using another good approach. It writes the
rules from memory back to the file when shut down. This eliminates the problem
of file manipulations during normal use. Unfortunately, this method is only
safe when it is not possible to manipulate the rules in memory and when it is
not possible to shut down the firewall process illegitimately. The latter has
been proven to be possible in Section 5.1.1.
Unfortunately, I cannot provide a stable working solution for this prob-
lem. In my opinion, it has to be solved using an administrator process that
handles the rule file.
5.1.12 Replacing the binary
Description of attack:
Replace a trusted application with a malicious one that pretends to be
the trusted application. For the test "C:\Program Files\Internet Explorer\IEX�
PLORE.EXE" is replaced by the telnet.exe application, by renaming and overwri-
ting it. After this an outgoing connection to TCP port 80 is initiated.
"Zonealarm":
It does notice the change of the binary and asks if it should update its
rule base. "Zonealarm" stores the rules for the applications in a file called
IAMDB.RDB, which on a "Windows 2000" system can be found at C:\WINNT\internet�
logs\. The file is machine independent. This means that we can replace this
file and its copy, the file BACKUP.RDB, with a modified version from another
machine. While the firewall is running, it has this file opened in a non-sha-
red mode. As discussed in Section 5.1.1, it is possible to terminate the fire-
wall process and, thus, end the lock on the rule file, making it possible even
for a restricted user to replace the rule set.
"Symantec Desktop Firewall":
It does notice the change of the binary and tells that there exist some
rules for "telnet" but that the file has changed its path since the last time
and the firewall needs to create a new rule. It recommends using the automated
rule creating wizard, which looks at the filename and then grants even more
access to the modified "telnet" then we wanted. For example, FTP, Gopher and
SSL ports were allowed. The recommendation wizard should be disabled as it
would lead an inexperienced user to choose a wrong thing. It is a valuable
feature for a normal configuration but can be easily misused for a malicious
purpose.
All the signatures of the applications are saved in the registry in plain
text and without any further integrity checks. Therefore, we can easily over-
write the signature hash of the "Internet Explorer" with the new hash for a
malicious application. The hash is stored in a registry key located at:
HKLM\Software\symantec\IAM\FirewallObjects\Applications\Internet Explorer\App�
licationSignature1 Reg_Binary
This hash is machine independent. We do not have to know how it is generated,
as we can simply generate a one on another machine and overwrite the original
one with the new one.
"Sygate Personal Firewall":
The replacement of the binary is reported by the firewall as an event and
a message is displayed asking the user, if the changes are expected. In the
application list it did change the name from "Internet Explorer" to "telnet",
but the network connections are still blocked for the renamed "telnet".
The question arises where "Sygate Personal Firewall" does store the hash-
es of the applications. Nothing was found in the registry. So, I assumed that
they are stored in a file. With the help of file access monitor tools I was
able to trace the write commands back to the file called stdState.dat, which
is located in the home catalog of the firewall installation. The program sto-
res the rules for each application in this file. The file is encrypted, so
that we cannot change it. However, during the experiment it was possible to
replace this file with an stdState.dat file from another machine. If the rep-
lacement is done while the firewall is running, then nothing happens, as at
shutdown the program writes back the rules that it had been loaded into memo-
ry. But if the firewall was not running, then it will accept the new file at
the next startup and present all the rules which we have configured on the re-
mote machine. This makes it possible to replace the application rule file.
General conclusion
The rule file and hash values are the brain of a desktop firewall. If we
are able to modify these entries, then the use of the whole firewall is at
danger. In the experiments it was possible to replace the application finger-
prints for all the three tested firewalls. This method can be implemented by a
trojan horse to add itself to the trusted applications, thus, being able to
communicate with the Internet without restrictions.
Counter measure
For counter measurements see the attack about modifying the rule set in
Section 5.1.11.
5.1.13 Port scan 1
Description of attack:
Perform a port scan on the target machine with "Nmap" program to find out
which ports are open. This is often the first thing an attacker does to find
out more about the target. "Nmap" was used with the options -sT -p 440-450 -v
-P0 -T Aggressive. This is a TCP connect scan which is the basic variant of a
port scan using full TCP handshakes. It is not very stealth but still widely
used. Tested all TCP ports from 440 to 450 with no delay between each scan.
This port range was chosen with no special intenion.
Tool used:
"Nmap"
"Zonealarm":
Reports each packet as a different event. "Nmap" reports all ports as
filtered.
"Symantec Desktop Firewall":
Reports each packet as a different event. "Nmap" reports all ports as
filtered.
"Sygate Personal Firewall":
Each packet gets logged. The system log reports 3 port scan events with a
count of 6, 4 and 10. "Nmap" reports all ports as filtered.
General conclusion
All the three firewalls do not react in a fully stealth way, but they all
react in the same way. No port was reported as open or blocked.
Counter measure
There is no need for a counter measure, as no information leaked out.
5.1.14 Port scan 2
Description of attack:
Perform a port scan on the target machine with "Nmap" program to find out
which ports are open. "Nmap" was used with the options -sT -p 440-444 -v -P0
-T sneaky. This is the same TCP connection scan as used in the port scan 1,
but this time with a large delay of 15 s between each the single scans. Slow-
ing down the scan can bypass some detection engines, as they watch for a spe-
cific number of connections in a fixed time interval.
Tool used:
"Nmap"
"Zonealarm":
Reports each packet as a different event. "Nmap" reports all ports as
filtered.
"Symantec Desktop Firewall":
Reports each packet as a different event. "Nmap" reports all ports as
filtered.
"Sygate Personal Firewall":
Reports each packet as a different event. "Nmap" reports all ports as
filtered. The system log reports 2 port scan events, each with a count of 1.
General conclusion
All ports are reported filtered. The attacker did not gain an information
out of this attack.
Counter measure
There is no need for a counter measure, as no information leaked out.
5.1.15 Port scan 3
Description of attack:
Perform a port scan on the target machine with "Nmap" program to find out
which ports are open. "Nmap" was used with the options -sS -p 440-444 -v -P0
-T sneaky. This time only SYN packets are sent out. This technique is often
referred to as "half-open" scan, because we do not complete the full three way
TCP handshake. After getting a response from the target system, we immediately
close the connection request by sending an RST packet.
Tool used:
"Nmap"
"Zonealarm":
Reports each packet as a different event. "Nmap" reports all ports as
filtered.
"Symantec Desktop Firewall":
Reports each packet as a different event. "Nmap" reports all ports as
filtered.
"Sygate Personal Firewall":
Reports each packet as a different event. "Nmap" reports all ports as
filtered. The system log reports 4 port scan events.
General conclusion
All ports are reported filtered. The attacker did not gain an information
out of this attack.
Counter measure
There is no need for a counter measure, as no information leaked out.
5.1.16 Port scan 4
Description of attack:
Perform a port scan on the target machine with "Nmap" program to find out
which ports are open. "Nmap" was used with the options -sX -p 440- 444 -v -P0
-T normal. In this scan an XMAS-scan is used. This means a special packet with
the FIN, URG and PUSH flags set is sent. As the SYN flag is not set, this pac-
ket will bypass stateless filters. Depending on the answer, we can guess if
the port was open or not. This method does not work every time as it is OS de-
pendent.
Tool used:
"Nmap"
"Zonealarm":
No event messages are generated. "Nmap" reports all ports open, which is
wrong.
"Symantec Desktop Firewall":
No event messages are generated. "Nmap" reports all ports closed.
"Sygate Personal Firewall":
No events are generated in the traffic or system log. The raw packet log
does report the packets. "Nmap" reports all ports open, which is wrong.
General conclusion
This behavior makes it possible to guess which desktop firewall is used
at the target machine. This information could later be used to launch an exp-
loit that targets a specific version of desktop firewalls.
Counter measure
This problem could only be solved by implementing a stateful packet ins-
pection firewall.
5.1.17 Mutex blocking
Description of attack:
Some of desktop firewalls use a mutex to check if there is already an in-
stance of itself loaded. Mutex is a program object that allows multiple prog-
ram threads to share the same resource, such as file access, but not simulta-
neously. When a program is started, a mutex is created with a unique name
identifier. After this point any thread that needs the resource must lock the
mutex from other threads while it is using the resource. The mutex is set to
unlock when the data are no longer needed or the routine is finished.
By stopping the desktop firewall process and blocking its mutex with a
malicious program, it is possible to prevent the firewall from loading and so
from protecting the network.
Tool used:
"ZoneMutex" from "Diamond Computer Systems Labs"
"Zonealarm":
The tool kills the running firewall process. Then it will set a mutex
with the name "Zone Alarm Mutex" preventing the real "Zonealarm" from reload-
ing. As long as this tool blocks the mutex, the machine will be unprotected. A
malicious application could even implement the system tray icon to pretend
that the original firewall is working normally.
"Symantec Desktop Firewall" and "Sygate Personal Firewall":
Unfortunately, there was no ready made attack for these firewalls avail-
able. As the time line for this thesis was short, it did not allow to code a
custom mutex blocking for these firewalls. Therefore, this test could not be
done for "Symantec Desktop Firewall" and "Sygate Personal Firewall".
General conclusion
This problem is related to the process killing issue. Because, if the fi-
rewall is already running, we have to kill the process before we can block the
mutex. Still it is very serious that a single call to the mutex API can block
the firewall from loading.
Counter measure
Prevent another process from imitating the firewall mutex. This can pro-
bably be achieved by using cryptographic algorithms to protect the mutex.
Still it is not trivial. We can think of the idea that a malicious attacker
takes the original firewall application and extracts the creation the part of
the mutex from this application. With this it would be possible to create a
blocking mutex, regardless of what is used to protect it.
5.1.18 DLL injection
Description of attack:
Make a DLL that will be automatically loaded with a trusted application.
Then it can use the rights of the trusted applications to start connections to
the network. For this test a tool was used which creates a DLL that is loaded
with "Internet Explorer".
Tool used:
"FireHole"
"Zonealarm":
Reports nothing unusual. The packets were granted the same rights as the
trusted parent application.
"Symantec Desktop Firewall":
Reports nothing unusual. The packets were granted the same rights as the
trusted parent application.
"Sygate Personal Firewall":
Reports a changed DLL and asks if it should be blocked or permitted. This
is done by comparing the DLL to an internal list with names and fingerprints.
As discussed in Section 5.1.12, it would be possible to replace this internal
list, so that the new DLL can be loaded without an alarm.
General conclusion
This idea is similar to the idea of injecting a thread into the process
memory of a trusted application.
Counter measure
A desktop firewall should also check all the loaded DLLs of an applica-
tion and keep track of them. "Sygate Personal Firewall" does this already. Of
course, this goes back to the problem of where and how to store the signatures
that are checked against the DLLs, as mentioned in Section 5.1.12.
5.1.19 URL encoding
Description of attack:
Use the given web-browser to send a hidden string encoded in a URL. For
example, opening the URL:
http://www.attackerssite.com\input.php?passwd=secret&IP=192.168.0.7
The browser window used to send this information might be set to be invisible
or to be out of the user's desktop screen, so that it is not suspicious.
Tools like "TooLeaky" use this method.
General conclusion
This method will always work as long as a webtraffic is allowed. If we
allow a normal webtraffic to pass the firewall, then this method cannot be
blocked. It is impossible to distinguish between a malicious and a harmless
webtraffic. As all simple mail forms use the same methods of HTTP posts for
communication as well. This really leads to a problem as no users will give up
the possibility to browse the Internet just for security reasons.
Counter measure
Blocking the web-browser is not practicable and, therefore, not an op-
tion. Even if the firewall does stateful packet inspection, this method would
still be undetected as the traffic is a legal HTTP traffic.
One thing that would help is if we block requests from other applications
to open a URL in the default browser. But this is a one of the features the
user probably is not willing to give up. Using a webproxy would not eliminate
the problem.
The final conclusion is that there is no practicable solution to prevent
this attack.
5.1.20 LSP
Description of attack:
Install a layered service provider (LSP) [16] that will listen for all
the incoming traffic. If the LSP gets installed under the desktop firewall in
the protocol chain, it might be possible to read packets before they are re-
jected in the chain by the firewall. When implemented to filter out the pac-
kets of the attacker these special packet would never reach the firewall. This
would make a two way communication possible without the firewall even knowing
what was going on.
Tool used:
"AWP LSP"
"Zonealarm":
LSP can be installed with no problem. Packets that are blocked with it do
not show up in the LSP.
"Symantec Desktop Firewall":
LSP can be installed with no problem. Packets that are blocked with it do
not show up in the LSP.
"Sygate Personal Firewall":
LSP can be installed with no problem. Packets that are blocked with it do
not show up in the LSP.
General conclusion
The LSP was not installed deep enough in the chain, especially not under
the firewall driver, or they used other methods to get the network card
events. The firewall was still acting normally and discarding all the packets
before the LSP was able to view them. Therefore, this attack was not success-
ful.
Counter measure
None needed, but make sure that it is not possible to install an LSP be-
low the desktop firewall driver.
5.1.21 Outgoing flood
Description of attack:
Try emulating a malicious application, which attacks another target from
the protected machine. Therefore, a flooding tool is used to attack another
machine. The protocol is varied with TCP packets with the SYN flag set, an
IGMP traffic and UDP packets.
Tool used:
"HGOD_flood.exe"
"Zonealarm":
Detects the tool and asks to block or allow its traffic.
"Symantec Desktop Firewall":
No event is created, no packet is seen.
"Sygate Personal Firewall":
Detects the tool and asks to block or allow its traffic. All the packets
can be found in the raw packets log.
General conclusion
This would be the usual scenario that gets created if a DoS attack would
be started from this machine. For example, when a worm tries to spread [8].
Counter measure
Outgoing floods should be noticed and blocked if unwanted or not authori-
zed. Therefore, a stateful inspection filter is needed, as flood tools may
send special packets.
5.1.22 Using 100% CPU and memory
Description of attack:
With the help of a JavaScript code it is easy to generate 100% CPU load
and memory usage. The idea behind this is that it might be possible that some
of the events will not get logged by the firewall because of resource prob-
lems. If the firewall was not well programmed, it could also be possible that
the process will crash.
"Zonealarm":
The firewall did not crash and reported normally. No events are skipped
during the tests.
"Symantec Desktop Firewall":
The firewall did not crash and reported normally. No events are skipped
during the tests.
"Sygate Personal Firewall":
The firewall did not crash and reported normally. No events are skipped
during the tests.
General conclusion
Intensely using resources of the target system seems not to affect the
desktop firewall. Of course, it renders the system itself unusable.
Counter measure
None needed.
5.1.23 Special packet check
Description of attack:
Send specially crafted packets to the target system to see what kind of
packet can be detected. Focus will be held on all variations of flags that can
be set in a TCP packet. If it is possible to send packets that are not logged,
it could be possible to set up a communication channel with a trojan horse
using these packets.
Tool used:
"PacketCrafter"
"Zonealarm":
type of packet flags set detected
IP � no
TCP � yes
TCP URG yes
TCP ACK yes
TCP PSH yes
TCP RST yes
TCP SYN yes
TCP FIN yes
TCP all except PSH yes
UDP � yes
The table shows the results of the special packet test for "Zonealarm".
When the source and destination IP addresses are set to the local address
(127.0.0.1), then the packet will be handled as outgoing.
"Symantec Desktop Firewall":
type of packet flags set detected
IP � no
TCP � no
TCP URG no
TCP ACK no
TCP PSH no
TCP RST no
TCP SYN yes
TCP FIN no
TCP all except PSH yes
UDP � yes
The table shows the results of the special packet test for "Symantec Des-
ktop Firewall". Only packets that have the SYN flag set will be detected. When
the source and destination IP addresses are set to the local address (127.0.0.
1), then the packet will be handled as incoming.
"Sygate Personal Firewall":
type of packet flags set detected
IP � no
TCP � yes
TCP URG yes
TCP ACK yes
TCP PSH yes
TCP RST yes
TCP SYN yes
TCP FIN yes
TCP SYN & ACK no
UDP � yes
The table shows the results of the special packet test for "Sygate Perso-
nal Firewall". All packets get logged in the raw packet log. When the source
and destination IP addresses are set to the local address (127.0.0.1), then
the packet will be handled as incoming.
General conclusion
A malicious tool like a trojan horse could use special packets to commu-
nicate through the desktop firewall, as none of them detects all sorts of pac-
kets.
Counter measure
Desktop firewalls should contain a stateful packet inspection filter
which is able to detect all these packets and check if they belong to a valid
connection.
5.1.24 Modifying log file
Description of attack:
Try to modify the log file of the desktop firewall. With this idea an at-
tacker could delete all possible traces of its successful break in. Even pla-
cing a wrong information to blame other people could be possible. This could
lead to problems when the data in the log file are held as true data.
"Zonealarm":
Stores the log in a plain text file which can be easily altered or even
deleted while the process is running. The application console itself has a
buffer on its own, that will remain filled even if the program is restarted.
This means altering the log file will not be reflected in the console. Still
all inserted events will propagate to the centralized security console if one
is used.
"Symantec Desktop Firewall":
While the firewall is running, the log file cannot be deleted. But there
is a registry flag at:
HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\IAM\Logs\Firewall
When switching this off, the logging process will be disabled.
Of course, when the firewall is not running, then the log files can be
altered. At the next reload all new events will also appear in the console
view.
"Sygate Personal Firewall":
While the firewall is running, the log file cannot be deleted. Of course,
when the firewall is not running, then the log files can be altered. At the
next reload all new events will also appear in the console view.
General conclusion
By terminating the desktop firewall process it is possible to modify the
contents of its log file or delete the whole log file.
Counter measure
Protect the log file from altering during running the process.
There is no practical way to protect the log file from modifications when
the process is shut down. Encrypting the file is not an option as it should be
possible to extract the data by third party tools, so that they could send the
events to a centralized correlation engine. Even more important is the argu-
ment that the key for a decryption will be stored locally too and can be ext-
racted from the firewall. As the firewall is not running, there is also no way
of protecting this key from malicious tools.
5.1.25 Push the "yes" button
Description of attack:
Make a small application that rests in the memory and monitors the names
of the appearing windows. It waits until it detects a window from the desktop
firewall wizard which asks the user if he wants to block or allow a certain
traffic. At this moment the application emulates pressing the "yes" button,
for example, by sending the keystrokes for the shortcut. If this is done fast
enough, the user will not notice it. This method enables us to create rules
for new applications that allow them to communicate with the Internet.
General conclusion
This is a simple local attack that does not attack the firewall itself.
Rather, it makes use of a feature that all desktop firewalls have implemented
and enabled by default. Therefore, this attack works on all versions of desk-
top firewalls.
Counter measure
This new added rule could be seen in the rule set, but a common rule set
has more then a hundred rules, making it not easy to find a newly added one. A
normal user will seldom look at his rule set, at least not as long as all his
applications still work. Disabling the wizard is not an option, because it is
the most helpful feature for a new user. With it the user does not have to
find out himself what communication a new installed application needs. Thus,
there is no protection from this attack.
5.1.26 Avoiding visibility
Description of attack:
There exist several root-kits for Windows. With such tools it is possible
to hide running applications from the system. This is done by patching kernel
functions or catching API calls in the system.
General conclusion
The used root-kits were able to successfully hide the process from the
task manager and from the "Explorer". But they are not able to prevent the
desktop firewalls from seeing and blocking the traffic. I think that it will
be not easy to manipulate the network driver to filter out a certain traffic
before the firewall does see it.
On the other hand, supplying a new network stack could solve this prob-
lem. This would then be the same idea as discussed in Section 5.1.20.
Counter measure
None needed.
5.1.27 Tunneling
Description of attack:
"Tunneling" is an expression for repacking packets in other protocols.
The idea is to use an allowed protocol such as HTTP and fill those packets
with the original traffic. For this method often protocols like HTTP, SMTP or
ICMP are used.
General conclusion
This method works fine with network firewalls, as they cannot see the
difference between the tunneled packets and the original ones.
This method will not work with desktop firewalls as they will see the
different application names and then ask to block them. For a desktop firewall
it makes a difference which application is sending the traffic.
Counter measure
None needed.
5.1.28 Trojan horse port
Description of attack:
Emulate a trojan horse server program that tries to make a listening ser-
ver for incoming connections.
General conclusion
Incoming connections to trojan horse servers are filtered as a normal in-
coming traffic and are mapped with the rule name to the name of the trojan
horse which is normally using this port. Trojan horses can be configured to
run at any port, therefore, it makes no sense to map these ports to trojan
horses names. From the security point of view, this scenario is not a problem
for desktop firewalls, as they will detect a trojan horse server when it tries
to access to the Internet. Then the firewall will ask to block the applica-
tion, preventing the trojan horse from accepting connections.
Counter measure
None needed.
5.2 Conclusions
Desktop firewalls do a fairly job in protecting against incoming attacks.
They cannot prevent a major DoS attack, but this is normal. Still the experi-
ments have shown that they could improve the prevention of DoS attacks to a
better level.
One thing that should be kept in mind is that it is dangerous to imple-
ment automatic response systems into desktop firewalls. React on alarms that
have been raised by the firewall is OK as long as we do not trust the source
of the attack. Most of the attacks used during the experiment can be run with
fake source addresses, making it impossible and probably fatal to block them.
Setting the system into a stealth mode and, thus, not responding to any
unwanted packets, is a nice feature, but not required. Open ports on the local
system will always be reported as open in a port scan, and these are the only
ones that the attacker is interested in. Of course, services that should not
be accessible from the network should be blocked, but this is a matter of con-
figuration.
On the other hand, desktop firewalls are vulnerable to different attacks
coming from the system they are installed on. This problem cannot be solved.
We cannot prevent actions which a normal user is able to perform too. For ex-
ample, as long as a user is able to start and stop a service of the firewall
on its own, a malicious application executed by the user will have the same
possibilities. The same applies to the rule set. As long as a user is able to
modify the rule set, it will be possible for a malicious application to modify
it too. This can be solved by running the firewall with administrator rights,
like most anti-virus scanners already do. However, this takes away the comfort
for the user to add new rules "on the fly". This is really the main problem of
desktop firewalls: they run on a system where they can be attacked from the
inside. Therefore, it is not possible to make anything that a malicious user
with administrator rights cannot change.
Desktop firewalls should implement a stateful packet inspection filter,
otherwise a possibility for a hidden communication channel using special pac-
kets is given. This would also eliminate some outgoing DoS attacks which are
not yet detected because of this problem. Of course, desktop firewalls should
also monitor all the used protocols, especially IGMP.
Chapter 6
Correlation & Cooperation
In this chapter the generic event log format is defined and some examples
for cooperation of desktop firewalls are given. Then the correlation of log
events is discussed and illustrated with a real world experiment.
6.1 Generic event log format
If we want to compare and correlate events from desktop firewalls with
ones from other desktop firewalls or other security related tools, it is in-
evitable to map the different log file formats into a one generic format. This
format should contain all the necessary information. Having a consistent for-
mat will make it easier to write matching rules for alarms. Unfortunately,
there does not exist something like a generic log format that is already ac-
cepted and used by every vendor. Therefore, we have to provide tools which
convert the original event format into the new generic log format. As a part
of this thesis I developed three Perl scripts that can be used to translate
the log files of the three tested desktop firewalls into the generic log event
format.
6.1.1 Definitions
The information which all desktop firewalls have in common should be inc-
luded in the generic event log format. In addition, fields that are not pre-
sent in the log files but still needed should be added by the parser script,
for example, a trust field. After analyzing the log files and comparing them
with IDS and network firewalls log files we came up with a generic event log
format, containing the fields shown in the table below and described next.
description field name value
IP address of the sensor SensorIP IP address [4 octets]
Type of the sensor Type [ZOA3|SDF2|SPF5]
Time when the event occurred Time Unix timestamp
Source IP address SrcIP IP address [4 octets]
Source host name SrcName <string>
Source port number SrcPort <integer>
Destination IP address DestIP IP address [4 octets]
Destination host name DestName <string>
Destination port number DestPort <integer>
Action that was performed Action [blocked|allowed|ignored|info|N/A]
Direction Direction [incoming|outgoing|N/A]
Protocol which was used Protocol [TCP|UDP|ICMP|IGMP|N/A]
Flags or type of the packet Flag [SYN|FIN|ECHO_REPLY|...]
Application which was involved Application <string>
Level of trust in this event Trust [0�9]
Signature name Signature <string>
Entire original message Msg <string>
o SensorIP: (mandatory)
The address of the machine that the desktop firewall is running on. This
information could also be calculated by looking at the source address, the
destination address and the direction, but this method would fail in some ca-
ses. For example, when the packet was sent to a broadcast address. In addi-
tion, this is an information that is frequently needed, and it makes sense to
have it as a self-contained field. This field is filled with the parser script.
o Type: (mandatory)
The type and version of the desktop firewall that was used. This can be
used to filter out events from a specific vendor. For example, if it is known
that those signatures do not match a certain attack very well. Or this infor-
mation could be used to write a correlation rule which takes advantage of the
peculiarities of a specific firewall. The products used in this thesis have
been labeled "ZOA3" for "Zonealarm 3", "SDF2" for "Symantec Desktop Firewall
2" and "SPF5" for "Sygate Personal Firewall 5". This field is filled with the
parser script.
o Time: (mandatory)
Simply a common Unix timestamp. Make sure that all monitored machines are
in the same timezone.
o SrcIP: (optional)
The address where the traffic came from. It might be empty if the host
name was given instead.
o SrcName: (optional)
The host name where the traffic came from. It does not always make sense
to convert this name into an address, as the corresponding address might have
changed before the conversion took place or the local DNS resolution might
have been altered.
o SrcPort: (optional)
The port number where the traffic came from.
o DestIP: (optional)
The address where the traffic was sent to.
o DestName: (optional)
The host name where the traffic was sent to. It does not always make sen-
se to convert this name into an address, as the corresponding address might
have changed before the conversion took place or the local DNS resolution
might have been altered.
o DestPort: (optional)
The port number where the traffic was sent to.
o Action: (mandatory)
May contain one of the five different strings:
"blocked" � which means that the traffic was blocked and discarded
by the desktop firewall. This information can be useful
to verify whether the attack was successful or not.
"allowed" � which means that the traffic was not blocked and did
pass the desktop firewall. This information can be use-
ful to verify whether the attack was successful or not.
"ignored" � which means that the traffic was logged but not blocked.
"info" � which means that this event is just an information
event, like "new rule added for telnet.exe". When this
parameter is set, then the information of the event can
be found in the "msg" field.
"N/A" � which means none of the above matched or that there was
an error while parsing this event line in the original
log file.
o Direction: (optional)
The direction: incoming or outgoing. This information could also be cal-
culated by looking at the source and destination addresses, but they could be
spoofed. Some of the desktop firewalls, for example, "Zonealarm", seem to do
it like this and fail when we send a packet that has the source and destina-
tion addresses set to the address of the firewall. It will then mark this pac-
ket as an outgoing traffic, because the source address is the local one. In
addition, this is an information that is frequently needed, and it makes sense
to have it as a self-contained field.
o Protocol: (optional)
The protocol of the packet that was monitored, for example, TCP or UDP.
It is optional, as not all events assume it. For example, informational messa-
ges do not include a protocol specification.
o Flag: (optional)
Some additional information of the used protocol, if available. This can
be "SYN" if, for example, the SYN flag was set in the packet.
o Application: (optional)
The name of the application that was sending or receiving the packets on
the monitored system.
o Trust: (mandatory)
Was introduced additionally and cannot be found in the desktop firewall
log files themselves. Its value is a number between 0 and 9 expressing the
level of trust that we have in this alarm message. A value of 0 means that we
do not trust this alarm and think it is incorrect, while 9 means that we trust
this alarm and think it is true. This parameter should help to eliminate false
positives by rating events and, maybe, ignoring an alarm which has a low trus-
tiness during the correlation. By default a trust level of 5 is assigned to
all the parsed messages. In this thesis the only rule used to modify it is al-
arms rating. As a result of it, outbound connections from the protected machi-
ne will have an alarm with the default level +1, and inbound ones will have it
with the default level �1. The reason for this is that we have more control
over the local events and can provide more information on them. Remote events
can be easily faked to make us believe whatever the attacker wants us to be-
lieve. For example, a port scan can come from a spoofed source IP address such
that it looks like it is coming from someone else. Modifying local events is
much harder.
o Signature: (optional)
The name of the signature that was matched for this alarm. Keep in mind
that the user could have rights to change the rules and, therefore, also to
rename it to something that does not correspond with the real event. But, when
controlled, this information can be useful in filtering the events later.
o Msg: (mandatory)
The whole event message as it appeared in the original log file. This
field was added specially for the information messages. If an event has set
the action to information, then we can find here the specific message string.
As there are too many different information messages, it would not make sense
to add new fields for each of them. Also it can be used as a fall back if some
information got lost in the parsing script.
Some of the fields might stay empty after parsing different event logs,
because not all of the information might be present in the original event mes-
sage. The event numbers are removed, as they might not be consistent and are
not of interest. The correlation center or central console can, and most pro-
bably will, add their own numbering to the events.
6.1.2 Exporting
The following are the actual export mappings into the defined generic
format for the specific desktop firewalls.
"Zonealarm" log file mapping
A typical event in a "Zonealarm" log looks like this:
FWIN,2002/11/25,14:35:52 +1:00 GMT,10.10.10.7:53,10.10.50.2:53,TCP (flags:S)
"Zonealarm" log translation table
FWIN, -> Direction
2002/11/25, 14:35:52 +1:00 GMT, -> Time
10.10.10.7:53, -> SrcIPaddr + SrcPort
10.10.50.2:53, -> DestIPaddr + DestPort
TCP (flags:S) -> Protocol + Flag
complete string -> Msg
depending on rule Trust
set by script SensorIP
set by script Type
set by script Action
"Symantec Desktop Firewall" log file mapping
A typical event in a "Symantec Desktop Firewall" log looks like this:
11/27/2002 15:50:48 Rule "Implicit block rule" blocked (10.10.50.1,446).
Details: Inbound TCP connection
Local address,service is (10.10.50.1,446)
Remote address,service is (10.10.50.4,1684)
Process name is "N/A"
"Symantec Desktop Firewall" log translation table
12/27/2002 15:50:48 -> Time
Rule "Implicit block rule" -> Signature
blocked -> Action
(10.10.50.1,446). Details: <ignored>
Inbound TCP connection -> Direction + Protocol
Local address,service is <ignored>
(10.10.50.1,446) -> DestIPaddr + DestPort
Remote address,service is <ignored>
(10.10.50.4,1684) -> SrcIPaddr + SrcPort
Process name is "N/A" -> Application
complete string -> Msg
depending on rule Trust
set by script SensorIP
set by script Type
Unfortunately, the port numbers of known services are automatically map-
ped to their names. This means that, for example, port number 80 will be rep-
laced with the string "http" in the log file. This fact is quite annoying, be-
cause it makes it harder to compare the logs. A switch to disable this option
could not be found. For further analysis this has to be remapped to the origi-
nal port number.
Another installed feature is resolving the IP addresses into the host na-
mes, which also cannot be turned off in the configuration.
Initialization informations, like the ones shown below, will be mapped
into information messages with the Action parameter set to "info":
1/23/2003 9:19:14 Inbound IGMP packets are being blocked
1/23/2003 9:19:14 Inbound IP fragments are being blocked
1/23/2003 9:19:14 NDIS filtering is enabled
1/23/2003 9:19:14 Interactive learning mode is enabled
1/23/2003 9:19:14 Firewall configuration updated: 149 rules
"Sygate Personal Firewall" traffic log file mapping
A typical event in a "Sygate Personal Firewall" traffic log looks like
this:
32104 11/27/2002 15:55:24 Blocked TCP Incoming 10.10.50.4 1897 10.10.50.3 446�
1 11/27/2002 15:55:11 11/27/2002 15:55:11 Block_all_unknown
"Sygate Personal Firewall" traffic log translation table
103 <ignored>
11/27/2002 15:55:14 -> Time
Port Scan Minor -> Action
Incoming -> Direction
TCP -> Protocol
10.10.50.4 -> SrcIPaddr
10.10.50.3 -> DestIPaddr
10 <ignored>
11/27/2002 15:55:10 <ignored>
11/27/2002 15:55:13 <ignored>
complete string Msg
depending on rule Trust
set by script SensorIP
set by script Type
"Sygate Personal Firewall" system log file mapping
Events in the system log file are on a higher level. They are already
correlated and look like the events of an internal IDS. This makes them diffe-
rent than the log files that we have already mapped. Still this information is
of great value for us, as it compresses events into a one alarm.
A typical event in a "Sygate Personal Firewall" system log looks like
this:
103 11/27/2002 15:55:14 Port Scan Minor Incoming TCP 10.10.50.4 10.10.50.3 10�
11/27/2002 15:55:10 11/27/2002 15:55:13
"Sygate Personal Firewall" system log translation table
32104 <ignored>
11/27/2002 15:55:24 -> Time
Blocked TCP Incoming Action + Protocol + Direction
10.10.50.4 -> SrcIPaddr
1897 -> SrcPort
10.10.50.3 -> DestIPaddr
446 -> DestPort
1 <ignored>
11/27/2002 15:55:11 <ignored>
11/27/2002 15:55:11 <ignored>
Block all unknown Signature
complete string Msg
depending on rule Trust
set by script SensorIP
set by script Type
6.2 Collaboration
6.2.1 Multiple instances of the same desktop firewall
Having multiple instances of the same type of a desktop firewall install-
ed on different machines might be a common case in a company. This is also the
same setup that was tested in a real world experiment in Section 6.4.
These setups are simpler to maintain, because we only have a one type and
can create a specific rule set using all the provided features. The advantage
of this setup against a single installed desktop firewall is that we have an
access to the same information on different machines. With this we can see if
a detected attack was only targeting a single machine or a whole subnet. This
makes it possible for us to detect attacks that have made only a few events on
the each machine but a lot in total over all the machines.
The disadvantage is that, if the chosen desktop firewall has a vulnerabi-
lity, all the machines in the network are affected in the same way. An attack-
er could render the complete network unusable by exploiting such a vulnerabi-
lity.
6.2.2 Different desktop firewalls
Having different types of desktop firewalls installed in a subnet can
have an advantage over the scenario of a monoculture discussed in Section 6.2.
1. The advantage is that most likely not all the instances are affected by the
same vulnerabilities. This makes it harder for an attacker to take over the
complete subnet.
The disadvantage is that it is more costly to maintain different rule
sets for the different types of desktop firewalls. For this reason it would
make sense to create a generic firewall rule format, as we will discuss in
Chapter 8.
The detection of attacks which target multiple hosts is, of course, also
possible with this setup.
6.2.3 Desktop and network firewalls
In a setup where we have desktop firewalls and network firewalls running
in the same subnet we do not gain much additional information out of it. But
still we can check with the desktop firewall if the network firewall rules do
filter out what they should. For example, we set the network firewall to block
any Telnet traffic from the Internet into the intranet. When the desktop fire-
wall then reports an incoming Telnet traffic from IP addresses outside the in-
tranet, we know that something is going wrong. Either the network firewall has
an unwanted hole, or some internal machine is faking the traffic. So we can
further investigate the suspicious event.
6.2.4 Desktop firewalls and intrusion detection systems
This setup is probably one of the best that we can have. A network-based
intrusion detection system (NIDS) will identify the attacks by searching for
patterns in the traffic. This makes it possible to exactly identify the type
of the attack. Having then the information from the desktop firewall log files
available for correlation, enables us to confirm suspicious events. For examp-
le, if an IDS sensor reports a Nimda computer worm, that has tried to access
one of the monitored machines, then the desktop firewall of the involved ma-
chine should also report an event on the given port. If one of these two mes-
sages is missing, some special investigation should be made. It could be that
an attacker is injecting alarm events into the IDS to overload it. This way
the desktop firewall would not report anything. Or it could be that an attack-
er has compromised the IDS sensor machine and is blocking the messages.
6.3 Correlation
6.3.1 Internet worms
The most frequently seen Internet threats nowadays are probably computer
worms [13]. Often they come in by e-mail messages and, once activated, try to
spread themselves using different methods, such as sending themselves to other
victims by e-mail messages, looking for open network shares or for vulnerable
machines.
A desktop firewall could help in this case very much, as it would prevent
the worm from spreading in the network by blocking its network access. Fur-
thermore, it would log the name of the application as which the worm is runn-
ing. At the console a rule could be set up so that specific application names
get reported. This would work if the used application name of the worm is
known and does not vary much. But even with an unknown name it can work. When
a suspicious application is continually trying to access the Internet, the
desktop firewall will prevent it and generate an event each time. A simple ru-
le could catch those events and raise an alarm when a threshold is reached. As
long as the user does not grant access rights to this application, it would
work.
Nevertheless, an infection of a machine protected by a desktop firewall
cannot be prevented if a malware comes in by some legitimate ways, such as be-
ing received as an attachment by e-mail. In this case only an anti-virus scan-
ner could help in an early detection.
6.3.2 Port scans
A port scan on its own is nothing dangerous and not uncommon nowadays.
Still it is often the first step of an attack and should be monitored.
With a desktop firewall we are able to monitor our machine for port
scans. If we have multiple machines with installed desktop firewalls, then we
are also able to keep track of IP scans. These are simply port scans that are
repeated for multiple IP addresses in a sequence. If only a few destination
ports are checked, it is often difficult to say if it was a worm or a port
scan, but a port scan will often scan more then five ports, which a worm does
seldom.
Port scans can easily be detected, as we can monitor all the requests
from the remote machine to the target. We just need to analyze those events.
Not all the events will be of the state blocked, as some of the scanned ports
might have been in use and, therefore, were open. This means we have to ins-
pect the events regardless of the state. For this purpose we have to enable
logging also for accepted packets, and this could lead to much data in the log
file.
The source IP address of a port scan will always be the same if an attac-
ker is interested in the result. Well, at least this is what people usually
think. But since the introduction of blind scans like Idlscan, it is possible
to have a remote machine scanned without sending any packets directly to it
[9]. Combining these techniques with several different relay hosts makes it
possible to have a target system scanned from different IP addresses, not in-
volving the real source IP address in any of the logged messages. Actually, in
this case it is impossible for us to identify the real attacker.
In some situations it can even be that we reveal a much more information
to the attacker than we normally would. For example, a desktop firewall which
allows the user to specify a trusted IP address and let a traffic from it pass
unblocked, can be tricked into revealing information about the running servi-
ces. If the attacker knows that the machine is a trusted machine, it can mis-
use this machine for performing a stealth Idlscan against the firewall. Since
this is a trusted host the firewall will not block the packets. This could
lead to the real status of the ports leaking out. This opens a possibility of
a distributed port scan from multiple sources, such that different sources are
used to check for open ports on one target machine. Even web-based services
like "Hexillion" could be used for that [10].
A sophisticated port scanner will not search the port range in a linear
way. This, together with the fact that not all attackers being interested in
the same ports, indicates that it makes no sense to watch for a linear series
of ports as a signature for port scans.
These thoughts lead to the following criteria.
Indications for a port scan are that within a short period of time
(first threshold) an amount of different ports (second threshold)
get contacted. The thresholds have to be adapted to the environment
that the system is exposed to.
Regarding the problems discussed above, it does not make sense to say
that all port scan events will come from the same source, as they obviously do
not have to. Still, for reasons of completeness, all available data should be
sent to the engine that analyzes the event. It might be that the attacker did
forget to hide his real IP address.
As we never will be able to tell if we have the real source IP address of
an attacker, we should be careful with automated blocking features. If an at-
tacker knows that the system will block each attack for one hour from access-
ing the target machine, it is possible for him to use this against the protec-
ted system. For example, the attacker can fake a port scan so that it looks
like it is coming from the DNS server of the victim. The desktop firewall will
then automatically block the DNS for one hour and, thus, block the protected
machine from using the DNS server.
6.3.3 DoS attacks
A DoS (denial of service) attack normally tries to flood a target machine
with lots of bogus packets, so that it will stop responding to a legitimate
wanted traffic. As the attacker is not interested in any response from the
target, this is considered a one way attack: no feedback will be sent to the
attacker. This fact explains why often spoofed packets are used during DoS at-
tacks.
It is very difficult to distinguish between a port scan and a DoS attack
against TCP services, like a random SYN flood attack, because they simply re-
sult in the same messages. A SYN flood might result in more packets, but, if
someone is scanning all the TCP ports, this can also generate a lot of traf-
fic. Therefore, we are not able to define exactly what the cause is, but we
detect that we are attacked.
6.4 Real world experiment
To have a real world test environment I did the following experiment. I
searched for some Windows users within "IBM Zurich Research Lab" that would be
willing to participate in my test. I asked them to have the "Symantec Desktop
Firewall" running during a whole week and send me back the generated log files
and their rule sets. The activated rules are important too, as the people are
all able to generate new rules or deactivate default rules. This could lead to
the problem that events will not get logged on certain machines because the
rule set was modified not to do so. The purpose of the whole experiment was to
see if the correlation ideas introduced in Chapter 6 would really make sense
and could work in a real world scenario.
After a week I was presented with the gathered logs and rule configura-
tion files of 12 people situated in the same subnet within "IBM". After par-
sing the log files into the generic event format with the Perl scripts develo-
ped in this thesis, I ended up having around 6 000 alarms. For simpler proces-
sing, I loaded the data into an "Excel" table. Now I was able to perform the
tasks that normally a security console would do based on the defined rules. I
analyzed the data by hand to see if the methods worked or if they needed adap-
tation.
By searching for events with the same source IP address and the same des-
tination port I started looking for suspicious alarms, filtering all the out-
going connections so that I would only see incoming events with those crite-
ria. In addition, I set a time window that filters events that have occurred
within a 1 min. The so found groups of events contained a lot of very suspici-
ous events, such as the ones shown in table below (The IP addresses have been
anonymized and unnecessary fields have been removed for better readability.).
Time SrcIP SrcPort DestIP DestPort
16:53:11 10.10.10.66 2703 10.10.10.134 80
16:53:14 10.10.10.66 2703 10.10.10.134 80
16:53:16 10.10.10.66 2728 10.10.10.159 80
16:53:16 10.10.10.66 2728 10.10.10.159 80
16:53:16 10.10.10.66 2771 10.10.10.222 80
16:53:19 10.10.10.66 2771 10.10.10.222 80
The table shows that the machine with IP address 10.10.10.66 scanned se-
veral machines in the network on TCP port 80. If we calculate the differences
between the different source ports and the corresponding destination IP add-
resses, then we realize that they match. This can be verified in the following
calculation:
2728 � 2703 = 25 = 159 � 134
2771 � 2728 = 43 = 222 � 159
This fact indicates that the attacker probably did a scan in sequential
order of the IP address range at least from 10.10.10.134 to 10.10.10.222,
scanning the IP address 10.10.10.135 with source port 2704, IP address 10.10.
10.136 with source port 2705 and so on. The problem is that with having access
only to the desktop firewall log files shown in the table above, it is not
possible to tell if it was a port scan or a computer worm that searched for
vulnerable webservers. I guess that it was an ordinary port scan, as most new
computer worms search in random order rather than in sequential order for new
targets. But we cannot be sure.
The second search pattern that I used was looking for events with the
same destination IP address and the same destination port. Once again sorting
them by time and looking at a small time window. An extract of the alarms
found can be seen in the table below.
Time SrcIP SrcPort DestIP DestPort
10:12:11 10.10.10.66 1511 10.10.10.134 80
10:12:14 10.10.10.66 1511 10.10.10.134 80
14:53:42 10.10.10.88 1254 10.10.10.134 80
14:53:45 10.10.10.88 1254 10.10.10.134 80
17:23:31 10.10.10.22 1397 10.10.10.134 80
17:23:34 10.10.10.22 1397 10.10.10.134 80
In the whole aggregated data I found about 40 times of a conspicuous set
of events that contained 2 alarms in a time offset of 3 s using a source port
number in the range of 1100 up to 1600. They all targeted the same destination
port which is the webserver TCP port 80. Similar series could be found for the
other destination IP addresses, each time following the same pattern.
This leads to the assumption that these events could be generated by a
computer worm randomly checking IP addresses for running webservers. Unfortu-
nately, as mentioned before, I had no sniffer log of the analyzed time period,
so I was not able to check whether it was a computer worm or not. For coming
up with an exact result I would need other sources of information, where the
full packet is logged. But still we can identify those addresses as suspicious
and even malicious. So we could take further steps to check those machines.
I also observed similar patterns with the grouping of 3 events instead of
2, those are probably related to different computer worms.
There was no misconfiguration in the network that could be observed in
the analyzed log files. By having a look at the rule sets I found out that
most of the users did have the same default rules still enabled. In addition,
there were certain rules applied for specific applications, that where obvi-
ously used on those machines. This information could also be used to detect
the use of a software disallowed on those machines.
6.5 Conclusion
Log files of desktop firewalls are useful to correlate attack events.
To be of even more value they should be extended in different directions.
The logging feature should be modified in a way which allows easy further ana-
lysis on a centralized correlation engine. This could be achieved by sending
the events as syslog messages or by writing them to a file in an easily pars-
able format. Another point is an implementation of stateful packet inspection
filtering. With this feature it would be possible to add more useful informa-
tion to the event message, for example, the request string if it was a connec-
tion attempt to a webserver. Furthermore, it would enable us to set up more
precise rules which also look at the payload of the packet.
As long as the above mentioned points are not solved, a desktop firewall
collaborating with an intrusion detection system seems to be the desired se-
tup, in my opinion. This combines the power of good attack identification from
an intrusion detection system with the ability of protecting from unknown at-
tacks of a desktop firewall. If then the generated event messages are analyzed
in a central place and correlated, most attacks can be detected and prevented.
Chapter 7
Conclusions
Nowadays, when many people have a permanent Internet connection and more
and more people are trying to act as attackers and harm others, a danger from
the Internet grows. Of course, security measures of the defender evolve too,
and new products are introduced to protect systems. Desktop firewalls are a
one kind of the new product that fills a gap in the chain of protection tools.
While mainly targeting end users, they also have an application in companies
on desktop machines of the employees.
This thesis consists of two parts. The first part shows that there is a
huge variety of attacks that target desktop firewalls, both from local or re-
mote sources. Desktop firewalls do a fairly job in protecting against incoming
attacks from remote machines, such as DoS attacks. However, some of the local
attacks cannot be prevented with the current definition of desktop firewall.
As long as a user is able to modify the rule set while running a desktop fire-
wall, it will always be possible for a malicious application executed by the
user to perform the same modifications as the user. This could be solved by
running the desktop firewall process with administrator rights, like most an-
ti-virus scanners already do. However, this would remove the power of that a
desktop firewall is configurable by the user on the fly. This is the main
problem of desktop firewalls: they run on a system where they can be attacked
from the inside. Therefore, it is not possible to make anything that a malici-
ous user with administrator rights cannot change. This applies to the log fi-
les, rule sets, startup behavior. On the other hand, some of the attacks can
and should be prevented by desktop firewalls, such as DoS attacks with unmoni-
tored protocols like IGMP. Therefore, stateful packet inspection filter should
be implemented in desktop firewalls.
The second part of the thesis reveals that it is helpful to use desktop
firewalls as an additional information source. In general, we can think of
desktop firewalls as of a cheap way of getting additional host-based sensor
log files from distributed systems. Many companies have already desktop fire-
walls installed but do not use the generated log files. With the help of the
tools developed in this thesis it is possible to export those log files to a
generic event format, which is introduced in this thesis, so that they can be
then integrated into an existing security framework. By using a common log fi-
le adapter it is possible to send the events to a correlation engine, for ex-
ample, to the "IBM Tivoli Risk Manager" console for further analysis. At this
centralized point the rules for correlation with other desktop firewall logs
or with IDSs can be added, so that no information gets lost. The provided in-
formation can really support the decision of an IDS. By correlating the log
events it is possible to increase the level of certainty to eliminate false
positives and prioritize true positives. It has to be mentioned that the data
of desktop firewall logs alone do not provide enough information for an exact
identification of the attacks. For example, when we get attacked on the TCP
port 80, we know that there was an attack, but we cannot tell for sure if it
was a computer worm, a port scan or just a user that by accident typed our IP
address in his browser. For clearing this situation we have to correlate the
events with packet logs or with IDS logs, making it possible to analyze the
payload of the packets. However, this feature can be integrated in future ver-
sions of desktop firewalls.
This usefulness is also visible in the real world experiment, where mul-
tiple identical installations of desktop firewalls in a network were tested
during a one week. On the basis of the generated log files we were able to
identify and classify different attacks during this time period. This includes
computer worms, which tried to spread in this network, adware, trying to send
an information back to its vendor, and attackers, scanning ports of the net-
work for possible weaknesses.
Chapter 8
Future Work
This work could be extended in different directions.
A one potential immediate step is to look at the correlation engine, whe-
re the generated events come together, and check how this new information so-
urce influences the quality of the detection and whether it decreases the num-
ber of false positives. Analyzing the information of desktop firewalls logs,
such as the starting time of the firewall, not processed in this thesis, could
be of interest as well, maybe, more for general system health checking or as a
method of checking if the system was rebooted or modified in an unauthorized
fashion. At least, it is data that are rarely used and freely available and
can give an information about the monitored system.
Another idea is to check if the problems mentioned in the conclusions
were solved in upcoming versions, such as better protection from incoming DoS
attacks or prevention from changes in the local rule set and log files.
In addition, it could be of interest to create a concept of an ideal des-
ktop firewall and, maybe, even implement it. As we see a huge demand for good,
reliable, stable but also easy to use desktop firewalls. This ideal desktop
firewall should solve the problems with the issue that it can be attacked from
the system it is running on. In addition, it should address features like out-
going spoofing protection, rule set altering prevention and DoS-attacks pro-
tection. An unanswered question is also if it is possible to detect which ver-
sion of a desktop firewall is installed on a target machine and which rules
are enabled. This information could lead to more sophisticated attacks exp-
loiting specific vulnerabilities of the desktop firewall following the first
attack.
Another topic is to check if it is possible to write firewall rules in a
generic format and then translate them into the specific format of different
firewalls and install them into their rule set. The idea behind this is to
have a one single rule file and apply it to all different kinds of firewalls
installed in the environment.
Bibliography
1. M.Ranum. Using Desktop Firewalls as Basic IDSes. � http://www.infosecurit�
ymag.com/2002/oct/cooltools.shtml, 2002.
2. Log File Analyzer Project on Security Focus. � http://analyzer.securityfo�
cus.com, 2003.
3. S.Boran. An Analysis of Mini-Firewalls for Windows Users. � http://www.bo�
ran.com/security/sp/pf/pf_main20001023.html, 2003.
4. G.Bahadur. Article of Attacks Against Personal Firewalls. � http://www.in�
fosecuritymag.com/articles/july01/cover.shtml, 2001.
5. Leak Test Against Desktop Firewalls. � http://www.pcflank.com/art21.htm,
2002.
6. DShield, Distributed Intrusion Detection System Project. � http://www.dsh�
ield.org, 2003.
7. General Informations About Computer Viruses. � http://www.virusbtn.com,
2003.
8. D.Moore, V.Paxson, S.Savage et al. The Spreading of the Sapphire/Slammer
Worm. � http://www.caida.org/outreach/papers/2003/sapphire/sapphire.html,
2003.
9. Fyodor. Information About idlScans with Nmap. � http://www.nmap.org/nmap/
idlescan.html, 2002.
10. Hexillion's Online Information Gathering Tool. � http://www.hexillion.com,
2003.
11. ProcessXplorer, a Process Explorer from Sysinternals. � http://www.sysint�
ernals.com, 2002.
12. T.Bird. This is a Collection of Links Related to Log File Anayzer. � http:
//www.counterpane.com/log-analysis.html, 2002.
13. Analysis and Surveys About Computer Security. � http://www.cert.org/analy�
sis/, 2002.
14. R.Graham. Explains Alarms Seen in Firewall Logs. � http://packetstormsecu�
rity.org/papers/firewall/firewall-seen.htm, 2000.
15. M.Rauen. Website with Low Level System Programming Source Code. � http://
www.madshi.net, 2002.
16. W.Hua, J.Ohlund, B.Butterklee. Microsoft's Introduction to Layered Service
Provider. � http://www.microsoft.com/msj/0599/layeredservice/layeredservi�
ce.htm, 1999.
17. D.Brent Chapman, Elizabeth D.Zwicky. Building Internet Firewalls. �
O'Reilly & Associates, 1995.
18. DiamondCS. How to Shutdown Zonalarm from a Batch File. � http://www.diamo�
ndcs.com.au/alerts/zonedown.txt, 2000.
19. L.Bowyer. Article of Tunneling with HTTP Protocol and Stegano Messages in
Pictures. � http://www.networkpenetration.com/protocol_steg.html, 2002.
20. IGMP Fragmentation Bug. � http://www.iss.net/security_center/static/2341.
php: Internet Security Systems, 1999.