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 Source port number SrcPort Destination IP address DestIP IP address [4 octets] Destination host name DestName Destination port number DestPort 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 Level of trust in this event Trust [0Ä9] Signature name Signature Entire original message Msg 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: Inbound TCP connection -> Direction + Protocol Local address,service is (10.10.50.1,446) -> DestIPaddr + DestPort Remote address,service is (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 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 11/27/2002 15:55:10 11/27/2002 15:55:13 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 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 11/27/2002 15:55:11 11/27/2002 15:55:11 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.