|
ru.internet.security
- RU.INTERNET.SECURITY ---------------------------------------------------------
From : Marхnais 2:5020/2173.2 18 Nov 2005 17:10:36
To : All
Subject : Desktop Firewalls and Intrusion Detection
--------------------------------------------------------------------------------
textsection 9 of 12 of file WUESTE.TXT
textbegin.section
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.
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:36 |
|
|
