|
ru.internet.security
- RU.INTERNET.SECURITY ---------------------------------------------------------
From : Marõnais 2:5020/2173.2 18 Nov 2005 17:10:11
To : All
Subject : Desktop Firewalls and Intrusion Detection
--------------------------------------------------------------------------------
textsection 4 of 12 of file WUESTE.TXT
textbegin.section
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.
textend.section
* Origin: 2:5020/1317.8, /2024.2, /2173.2, /2613.5, /5413.3 (2:5020/2173.2)
Āåšķóņüń˙ ź ńļčńźó ņåģ, ńīšņčšīāąķķūõ ļī: āīēšąńņąķčå äąņū óģåķüųåķčå äąņū ņåģą ąāņīš
| Ņåģą: |
Ąāņīš: |
Äąņą: |
|
Desktop Firewalls and Intrusion Detection |
Marõnais |
18 Nov 2005 17:10:11 |
|
|
