Today, however, such solutions are no longer enough. Firewalls cannot detect unintentional backdoors around the firewall, especially if you're not using a proxy firewall. Articles [Ref 2] and statistics suggest that more than 50% of all recorded breaches today originate from someone legitimately behind the firewall. Therefore, people started deploying intrusion detection (ID) systems as an additional part of a network's security architecture.
This article will provide a basic overview of today's ID systems. It
doesn't aim to be complete but gives a good starting point for further
information. I will talk about different architecture approaches for ID
systems, host and network based, to improve overall security for your
business. A general security framework using Snort as the basic Open Source
IDS tool will be presented together with some suggestions on how to generate
audit trails, anomaly event generation, and central logging over syslog(-ng).
You might ask yourself whether your network really needs such systems. Well, this depends on a lot of aspects; judge for yourself:
Since this article focuses on the Open Source IDS tool Snort [Ref 5], you might find another benefit for including an ID system into your network -- it's free, and it really works!
I'd like to shortly introduce some commonly used terms and show some
basic concepts. A thorough understanding of TCP/IP and networking in general
is a must. You should be able to read and understand a tcpdump
output. You don't need to know how the packet travels through the kernel
unless you start enhancing ID systems by yourself.
System | Example | URL -------+--------------+--------------------------------------------------- IDS | IDS182 | http://www.whitehats.com/IDS/182 -------+--------------+--------------------------------------------------- CVE | CVE-2000-0138| http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2000-0138 -------+--------------+--------------------------------------------------- Bugtraq| BugtraqID 1 | http://www.securitfocus.com/vdb/bottom.html?vid=1 -------+--------------+--------------------------------------------------- McAfee | Mcafee 10225 | http://vil.nai.com/vil/dispVirus.asp?virus_k=10225 -------+--------------+---------------------------------------------------
I will describe two different groups of intrusion detection systems, host- based and network-based. Host-based ID systems define the security on the system itself. These components can be of different nature and are available for all modern operating systems. For Unix derivates, you can find all kind of system surveillance tools starting with Tripwire and maybe ending with trusted security approaches. I'd like to mention a few tools available for the GNU/Linux system that I find quite interesting. Besides Tripwire for user space security, there are tools like kstat [Ref 10] or carbonite [Ref 14] for kernel space surveillance. Extensions like lomac [Ref 7], RSBAC [Ref 8], or selinux [Ref 9] can provide very advanced host-based ID security solutions for GNU/Linux.
On the other hand, we have the network-based intrusion detection systems. The basic purpose of a network-based IDS is to sniff all traffic on a network and to compare the network packets with certain patterns. If a pattern matches, an alarm is raised. There are a wide range of different network-based ID systems. A network-based IDS is a tool or a set of tools to inspect network traffic and generate alarms in case of bad traffic. It is not a packetfilter and should not be confused as such. One example of such an intrusion detection tool is Snort, a lightweight intrusion detection tool available for a variety of OS flavors. It's the only advanced Open Source intrusion detection tool comparable to commercial solutions such as NFR, Dragon, or ISS RealSecure.
Snort is a very nice ID tool that is actively being developed by Martin
Roesch and others based on the libpcap library. Roesch himself
calls Snort a lightweight ID tool that means "... cross-platform compatability,
small system footprint, and easy configurability ..." The latter is debatable,
as by the time of this writing, the official version 1.7 was out and had
some config file parsing problems. However, I've been working
with the CVS version, too, and the upcoming version 1.8 has undergone
major changes in the parsing machine and introduced new features that
are partly described in section 2.1.
To provide a complete reference on Snort is not possible within the scope of this article. (For more information, see Kristy Westphal's article on Snort in the September 2000 issue of Sys Admin magazine.) You can find all necessary documentation at: www.snort.org [Ref 5]. I will, however, use the syntax and the config files from the 1.8 version.
The following sketch should give you an overview of the basic workings of the Snort IDS. I will introduce the various layers while explaining the example throughout the next section.
Figure 1: Basic Snort IDS
------------------------------------------------
\ /
\ Packet Sniffing: we get all the packets /
1. \ of the physical segment connected /
\ /
--------------------------------------
\ /
\ Preprocessor: prepares packets /
2. \ for faster processing /
\ /
------------------------------
\ /
\ Pattern Matching: / +-------------+
3. \ Attack Detection / | |
\ / | allowed |
---------------------- | traffic |
\ / | |
\ Policy Enforce- / +-------------+
4. \ /
\ ment (PE) /
\ /
.........................------------..........................
\ /
\ denied / +-------------+
5. \ / | |
\ / | denied |
\ / | traffic |
\/ | |
+-------------+
(End Figure 1)
In this section, I will set up a step-by-step example using Snort as an IDS tool. Let's assume the following very simple network topology:
Figure 2: Basic Internet Topology
+-----------+
| Internet |
+-----+-----+
|
+-----+-----+
| router |
+-----+-----+
| [front zone]
X-----+----------------------------+-----------X
| [Admin] |
| X-+------------------+-X v
[fw-if0] | | | |
+-----------+-----+-----+ +--+---+------+
| | | (2) (0) |
| packetfilter/firewall | +--->--+(1) IDS |
| | | | |
+-----------+-----+-----+ | +-------------+
| | |
+-----------+ | X--+--------+---+--X
| | | [DMZ] |
| +-----------+ | |
| | | | |
+--| +-----------+ | +-----+-----+
| | | | | |
+--| your node | | | server |
| | | | |
+-----+-----+ | +-----------+
| |
| | [Intranet]
X-------------+-------+----------------------------------------X
(End Figure 2)
Note that I only put one IDS system with two interfaces for every network that is not attached to the intranet. People often circumvent the firewall by putting an IDS between the intranet and Internet, which means the IDS has a physical connection to the front zone and a physical one to the intranet. This is very dangerous, because you potentially expose the intranet although you have a packet filter. IDS specialists will tell you to put an IDS for every subnet you have. You might put two or three subnets together if you know that there is hardly ever traffic or if you're setting up an IDS in a private zone behind the firewall. Despite having firewall components, you must make the IDS secure. A firewall cannot protect the IDS. There is more than one method to achieve this:
ifconfig eth0 up
is enough).
Note that this example is used for simplicity and only shows how to generate rules and identify pitfalls. It shouldn't necessarily be done this way.
As you might have guessed, the default config files from the Snort package are not optimized for your network for obvious reasons. Therefore, you need to adjust them. We developed a scheme for configuring Snort that allowed us to cope with big networks and reduce the number of false positives and false negatives by introducing small configuration tricks. With this configuration, we could finally verify our firewall and packet filter configurations.
We start by defining a so-called port matrix of your firewall configuration, which will help to configure the IDS accordingly. Such a port matrix could look as shown in Figure 3:
Figure 3: Port Matrix
Universe : 0.0.0.0/0 : IDS-if = eth0
intranet : 172.24.0.0/16 : IDS-if = not connected
dmz-net : 192.168.1.0/24 : IDS-if = eth1
admin-net : 192.168.2.0/29 : IDS-if = eth2 (only administration)
front-zone: 194.245.91.0/24 : IDS-if = eth0
fw-if0 : 194.245.91.1/32 : IDS-if = eth0
Default policy: DENY!
| To | (A) | (B) | (C) |
| From | universe | dmz-net | fw-if0 |
+------------+----------+----------+----------+
(a) | universe | | 80/tcp | |
+------------+----------+----------+----------+
(b) | dmz-net | 53/udp | 22/tcp | |
+------------+----------+----------+----------+
(c) | fw-if0 | 80/tcp | 22/tcp | |
| | 53/udp | | |
| | 22/tcp | | |
+------------+----------+----------+----------+
eth0: [Aa-Ca] and [Aa-Ac] -> /etc/ids/eth0/policyrules/pass.rules
eth0: [Ac-Cc] and [Ca-Cc] -> /etc/ids/eth0/policyrules/pass.rules
eth1: [Ab-Cb] and [Ba-Bc] -> /etc/ids/eth1/policyrules/pass.rules
eth2: This is the administration net, we don't sniff there.
Read: Accept ``tcp intranet 1024:65535 -> 0.0.0.0/0 80''. Actually
we would need to say: accept ``tcp fw-if0 1024:65535 -> 0.0.0.0/0 80''.
This is because the intranet connections got masqueraded and get the IP
of the external interface of the firewall. Another example would be: accept
``tcp Universe 1024:65535 -> dmz-net 80''.
(End Figure 3)
I know that people would not be happy with such a configuration, but it serves its purpose; I tried to simplify things for the purpose of illustration.
As depicted in Figure 2, we have one ID system that records traces of network traffic. I will explain the implications and problems with such a setup further down. Let's move on to the configuration. I made a little script (Listing 1) that should provide a good preparation for you. Of course, you're free to choose your own setup.
(Download tarball of listings. listing0106j.tar.gz)
................................................................................
Listing 1
#! /bin/bash
IDS_CONFIG=/etc/ids
IDS_LOG=/var/log/ids
# prepare the directories for the 2 different networks and create the
policy
# rules files and the logfile directories
for NIC in eth0 eth1; do
mkdir -p $IDS_CONFIG/$NIC/policyrules
mkdir -p $IDS_LOG/$NIC
> $IDS_CONFIG/$NIC/ids.conf
for LOCALRULES in drop.rules pass.rules; do
> $IDS_CONFIG/$NIC/policyrules/$LOCALRULES
done
echo "deny ip any any -> any any (msg: "malicious traffic";)"
>\
$IDS_CONFIG/$NIC/policyrules/deny.rules
done
mkdir -p $IDS_CONFIG/idrules
(End Listing 1)
................................................................................
The only thing you have to do by hand is to copy the rules you take either
from the Snort source tar-ball or from Snort.org
[Ref 5] directly to the /etc/ids/idrules
directory.
Now we need the specific net-related ids.conf engine files.
Listing 2 is the example file for eth0,
which is /etc/ids/eth0/ids.conf. Repeat it for the other
interface of this example and put it in its appropriate place. Basically,
it is a:
sed -e 's/eth0/eth1/g' /etc/ids/eth0/ids.conf > /etc/ids/eth1/ids.conf
................................................................................
Listing 2
1 #
2 # ids.conf
3 #
4
5 # base config
6 config ghetto_msg: url
7 config umask: 0177
8 config alert_with_interface_name:
9 config utc:
10 config show_year:
11
12
13 # new rule types
14 ruletype drop
15 {
16 type pass
17 }
18
19 ruletype deny
20 {
21 type log
22 output log_tcpdump: deny
23 output alert_syslog: LOG_LOCAL7 LOG_INFO
24 }
25
26 ruletype info
27 {
28 type log
29 output log_tcpdump: info
30 }
31
32 config order: drop activation dynamic alert pass info deny
33
34 # variables
35 var Universe 0.0.0.0/0
36 var DMZ 192.168.1.0/24
37 var FRONT 194.245.91.0/24
38 var INTRANET 172.23.0.0/16
39 var FWIF0 194.245.91.1
40
41 # needed for alert rules
42 var EXTERNAL_NET [$Universe]
43 var HOME_NET [$FRONT,$DMZ]
44 var SMTP [$FWIF0]
45 var DNS_SERVER $HOME_NET
46 var HTTP_SERVERS $HOME_NET
47 var SQL_SERVERS $HOME_NET
48 var DNS_SERVERS $HOME_NET
49
50 # preprocessor
51 preprocessor defrag
52 preprocessor http_decode: 80 81 3128 8080 -unicode
53 preprocessor portscan: $FRONT 4 3 portscan.log
54 preprocessor portscan-ignorehosts: $FRONT
55
56 # output plugins
57 output alert_syslog: LOG_LOCAL7 LOG_INFO
58 output log_tcpdump: alert
59
60 include /etc/ids/idrules/classification.config
61
62 # local rules
63 # change interfaces for multiple network cards
64 include /etc/ids/eth0/policyrules/drop.rules
65 include /etc/ids/eth0/policyrules/pass.rules
66 include /etc/ids/eth0/policyrules/deny.rules
67
68 # IDS rules
69 include /etc/ids/idrules/exploit.rules
70 include /etc/ids/idrules/scan.rules
71 include /etc/ids/idrules/finger.rules
72 include /etc/ids/idrules/ftp.rules
73 include /etc/ids/idrules/telnet.rules
74 include /etc/ids/idrules/smtp.rules
75 include /etc/ids/idrules/rpc.rules
76 include /etc/ids/idrules/rservices.rules
77 include /etc/ids/idrules/backdoor.rules
78 include /etc/ids/idrules/dos.rules
79 include /etc/ids/idrules/ddos.rules
80 include /etc/ids/idrules/dns.rules
81 include /etc/ids/idrules/netbios.rules
82 include /etc/ids/idrules/web-cgi.rules
83 include /etc/ids/idrules/web-coldfusion.rules
84 include /etc/ids/idrules/web-frontpage.rules
85 include /etc/ids/idrules/web-misc.rules
86 include /etc/ids/idrules/web-iis.rules
87 include /etc/ids/idrules/icmp.rules
88 include /etc/ids/idrules/misc.rules
(End Listing 2)
................................................................................
Let me explain some things here. The config directives (lines 6-10) are
used to put in some option you would need to set on invocation of the
Snort tool from command line. For example, config show_year
replaces the -y option of Snort.
The next section in our ids.conf is the ruletypes
section (lines 14-30). In this section, you can define new ruletypes and
new characteristics of the new ruletypes. For example, you could define
a type "mytype" that not only logs in tcpdump format to a
file but also sends the alarms to the syslog. The Snort ruletype
definition section is a bit tricky, and you will need to read the manual
to understand it. We added some new ruletypes to improve accuracy and
the ability to reduce false alarms by defining a logical chain of rule
types that get processed sequentially. Note, however, that within one
ruletype the order is not given. Thus, if you have a rulefile that has
three alert rules defined, you don't know in which order Snort will process
them. The config order can be seen as a possibility to set the granularity
of the five different layers depicted in Figure
1.
Recall that we defined the order (line 32):
config order: drop activation dynamic alert pass info deny
The drop rule is mainly for taking away the false positives that would
be generated in the alert rule. As you will see further down, we have
the pass rule for the firewall policy enforcement rule. Suppose you have
icmp echo_requests from a HP-UX box and you accept those
requests to pass through your firewall. We have it in our port matrix,
and we added it to the pass rule. For some reason, one of the alert rules
matches, and Snort thinks this is some kind of attack. Snort then would
slowly fill up your logs with stuff you already know. Worse, these are
false positives, because you wanted those packets to travel through the
firewall. Therefore, you would put this policy rule to the drop rule,
where it gets silently discarded by Snort. Another use for the drop rule
would be for traffic we don't want to inspect because we trust it. However,
you have to know that you open a potential risk of an attacker masquerading
behind this drop rule by using forged packets that the IDS drops. Therefore,
the drop.rules is normally empty. The next two ruletypes
are new in Snort, and we currently don't honor them. The basic idea is
to dynamically activate rules according to some pattern matching.
Next is the alert rule, which is layer 3 of Figure
1. The alert rule is for the attack signatures defined in /etc/ids/idrules.
An example from /etc/ids/idrules/web-cgi.rules:
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80 (msg:"WEB-CGI w3-msql
solaris x86 access"; flags: A+; uricontent: "/bin/shA-cA/usr/openwin";
nocase; reference:cve,CVE-1999-0276; reference:arachnids,211;classtype:attempted-recon;)
Here Snort does pattern matching and generates alerts in case of a match.
These alerts are written to the syslog and to a tcpdump
format file.
What follows is an important ruletype, the pass rule. This is layer 4 of Figure 1. There we implement the port matrix shown above in Figure 3. We call this pass rule policy enforcement (PE). The policies are the firewall rules implemented according to the port matrix. If we see entries in the logfile after the pass rule, either there was an attack, a false positive, or our firewall is misconfigured. We can check the logfiles before the firewall and after the firewall. If they differ, we might check the firewall configuration again.
The next ruletype is info, which is a log type ruletype with redefined
output plugin (lines 26-30). We want to have tcpdump output,
so we can read the packets later with tcpdump. It is mainly
needed for traffic that is not allowed by the policy that we see regularly.
An example could be a mis-configured Windows NT box sending out bootpc
requests. This is not really an attack, but disturbs the output file of
the deny rule, which should explicitly only log malicious traffic that
has not yet matched any of the above rules. Again, we introduced this
new ruletype info because we could reduce false interpretations resulting
from logged traffic that was not allowed, but seen on a regular basis,
and which we, at the time, couldn't change or omit.
The deny rule is to log all packets that haven't yet matched a rule and that also don't belong to the allowed traffic of the firewall. It's depicted as layer 5 in Figure 1. This is a very important rule to minimize the false positives. It allows us to check whether the traffic behind the firewall is what we expected it to be. If it is not, it will get logged by the deny rule, which reads:
deny ip any any -> any any
(The ip PROTO is new in Snort 1.8. Prior to this version,
you could only specify tcp, udp, and icmp;
thus, packets originating from a IPSEC tunnel wouldn't get logged.)
The goal is to keep the resulting deny logfile as small as possible. Every entry in this file must be inspected and prosecuted. The packets should never reach there, or you have a problem -- either misconfiguration or a real attack.
Consider the preprocessor configuration, which is actually layer 2 according
to Figure 1. A preprocessor is a filter
that, like the name says, does some preprocessing to the packets. For
example, you have a packet defragmentation preprocessor that does nothing
other than defragment the packets in the memory until all packets are
assembled. Only after this does Snort forward the packets for further
rule inspection. The standard snort.conf that comes with
the package has a very good documentation of what each preprocessor does.
The only confusing part might be:
preprocessor portscan-ignorehosts: $FRONT
preprocessor portscan: $FRONT 4 3 portscan.log
This means if the preprocessor detects UDP or TCP_SYN packets going to
four different ports in less then three seconds, it will generate an event.
This event is an entry into the portscan.log file. We are
using the $FRONT again for the portscan-ignorehosts,
because we want to keep the false positives low.
The next two lines (57-58) are so-called output plugins. We defined the
alerts to be written to the syslog(-ng) to provide
the ability of using an IDS decentralized loghost. This also allows us
to embed important events into a monitoring system for fast alarming.
The central logging can be crucial in case of a breach.
The last thing we need to set up for the example is the PE configuration,
which is different for every interface. We do it in separate files to
get a better overview in the resulting Snort output files, such as the
tcpdump output.
/etc/ids/eth0/policyrules/pass.rules
pass tcp $Universe 1024: <> $DMZ 80
pass tcp $FWIF0 1024: <> $Universe 80
pass tcp $FWIF0 1024: <> $Universe 22
pass udp $FWIF0 1024: <> $Universe 53
/etc/ids/eth1/policyrules/pass.rules
pass tcp $Universe 1024: <> $DMZ 80
pass tcp $DMZ 1024: <> $DMZ 22
pass udp $DMZ 1024: <> $Universe 53
There are problems introduced with such a configuration. First, the packets
coming from the INTRANET are masqueraded and will not have an IP from
the INTRANET range but an IP of the outgoing firewall interface or one
of its aliases. Therefore, having an INTRANET<>Universe rule wouldn't
make sense, because packets would never match. I just wanted to make a
simple example to get the feeling and the concept behind it. The second
problem is obvious for people dealing on a daily basis with packet filtering
or intrusion detection. The <> means bidirectional,
but there are no TCP flags set. This means for rule 1 for the network
attached to eth0:
pass tcp $Universe 1024: -> $DMZ 80 (TCP state flags: ALL) and!!
pass tcp $DMZ 80 -> $Universe (TCP state flags: ALL)
But you don't want this. And, if you want to reduce false negatives, you must make three rules instead of one. The previous example could be written more restrictively (out of consideration for the PE on the firewall, especially if you have connection tracking enabled):
pass tcp $Universe 1024: -> $DMZ 80
pass tcp $DMZ 80 -> $Universe (flags: SA)
pass tcp $DMZ 80 -> $Universe (flags: FURPA)
This is a slight improvement compared to the one-liner with the bidirectional pass rule. We don't pass connection attempts from DMZ with correct three-way handshaking initialization to the Universe. There are better examples, of course.
The last thing you might set up is the syslogd. We've chosen
syslog-ng because you have more possibilities, such as logging
over tcp and keeping the originating system name in the logfile.
A possible configuration on the IDS is shown in Listing 3.
................................................................................
Listing 3
#
# syslog-ng configuration file for the IDS
#
options { keep_hostname(on); long_hostnames(off); sync(0); };
source s_src { unix-stream("/dev/log"); internal(); };
source s_net { udp(ip(127.0.0.1) port(514)); };
source s_krn { file("/proc/kmsg"); };
destination d_auth { file("/var/log/authlog"); };
destination d_kern { file("/var/log/kernlog"); };
destination d_mesg { file("/var/log/messages"); };
destination d_cron { file("/var/log/cronlog"); };
destination d_ids { file("/var/log/idslog"); };
destination d_loghost { tcp("loghost" port(1514)); };
filter f_auth { facility(auth, authpriv); };
filter f_kernel { facility(kern); };
filter f_cron { facility(cron); };
filter f_mesg { facility(daemon, mail, security); };
filter f_ids { facility(local7); };
log { source(s_src); filter(f_auth); destination(d_auth);
};
log { source(s_krn); filter(f_kernel); destination(d_kern);
};
log { source(s_src); filter(f_cron); destination(d_cron);
};
log { source(s_src);source(s_net); filter(f_ids); destination(d_ids);
};
log { source(s_src);source(s_net); filter(f_ids); destination(d_loghost);
};
log { source(s_src);source(s_net); filter(f_mesg); destination(d_mesg);
};
End Listing 3
................................................................................
On the other side we have the loghost that gets and stores all important
alerts from the various ID systems (Listing 4).
................................................................................
#
# syslog-ng configuration file for the central loghost
#
options { keep_hostname(on); long_hostnames(off); sync(0); };
source s_src { unix-stream("/dev/log"); internal(); };
source s_net { udp(ip(0.0.0.0) port(514)); };
source s_ids { tcp( ip(0.0.0.0) port(1514)); };
source s_krn { file("/proc/kmsg"); };
destination d_auth { file("/var/log/authlog"); };
destination d_kern { file("/var/log/kernlog"); };
destination d_mesg { file("/var/log/messages"); };
destination d_cron { file("/var/log/cronlog"); };
destination d_ids { file("/var/log/idslog"); };
filter f_auth { facility(auth, authpriv); };
filter f_kernel { facility(kern); };
filter f_cron { facility(cron); };
filter f_mesg { facility(daemon, mail, security); };
filter f_ids { facility(local7); };
log { source(s_src); filter(f_auth); destination(d_auth); };
log { source(s_krn); filter(f_kernel); destination(d_kern); };
log { source(s_src); filter(f_cron); destination(d_cron); };
log { source(s_ids); filter(f_ids); destination(d_ids); };
log { source(s_src);source(s_net); filter(f_mesg); destination(d_mesg); };
End Listing 4
................................................................................
This is it basically with the configuration for our test. We can start now the two Snort sessions as daemons in the background:
snort -D -i eth0 -c /etc/ids/eth0/ids.conf -l /var/log/ids/eth0
snort -D -i eth1 -c /etc/ids/eth1/ids.conf -l /var/log/ids/eth1
To test your setup, you could make a scan with nmap or connect
to a Web server and do a GET request to raise an alert (this
is listed in the idrules directory):
echo -e "/bin/shA-cA/usr/openwin\n\n" | netcat your_web server 80
If the preprocessor http_decode is enabled (see line
52 in Listing 2), the second connection attempt will raise
an alarm:
echo -e "%2fbin%2fsh%41-c%41/usr%2fopenwin\n\n" | netcat your_web server 80
Snort output:
May 2 15:22:48 Melian Snort: WEB-CGI w3-msql solaris x86 access - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-1999-0276 - http://www.whitehats.com/info/211 [Classification: Attempted Information Leak Priority: 3]: 172.23.2.48:1134 -> 172.23.2.47:80
You might need to change the alert URL http://www.whitehats.com/info/211
to http://www.whitehats.com/info/IDS211. Your mileage may
vary.
Unfortunately, the best case of no log entries and no alarms never occurs. Your logfiles will be full of scan attempts, false alarms, and other unwanted traffic. ID systems do have some potential problems you should be aware of apart from the usual percentage of human mistakes and their resulting misconfiguration.
GET /bin/shA-cA/usr/openwin HTTP/1.0the attacker composes the following unicode stream:
GET %2fbin%2fsh%41-c%41/usr%2fopenwin HTTP/1.0
The IDS system would correctly match the first one, but would normally
fail on the second one. The end system, howeve,r will accept both.
Important for the attacker, however, is that the second case will not
get logged by the IDS system and will likely not generate an alert,
whereas the first GET certainly does (all provided this would be an
exploit URL). Again, you can read more about IDS problems in Ptacek
and Newsham's excellent paper [Ref 1].
Personally, I have been working with Snort for a long time, and I'm pleased
by the fast development circle this project has. The developers seem to
take the problems addressed by Ptacek and Newsham very seriously. Today,
it's vital to have an ID system, because more and more hosts are connecting
to the Internet and more malicious traffic occurs. Another aspect of having
an IDS is that you have yet another method of verifying your firewall
configuration. Getting familiar with an IDS is a long process of constant
reading and learning. If you're thinking about using an ID system for
your network, you might as well consider having an expert evaluating the
logfiles. Because the best logfiles can't help if you don't understand
them. Learn how to read tcpdump; read the rich documentation
available on the Net; keep yourself updated. People tend not to use Open
Source software for mission critical tasks, but Snort is very advanced
and has the advantage that you can modify it and add new stuff. Snort
has provided more than good service; it became an invaluable tool in our
firewall product suite. Together with a good monitoring tool, you can
increase the overall security and availability of your network.
Roberto Nibali is a senior developer for terreActive AG in Switzerland. terreActive provides solutions for high secure networks and managed security services. Roberto is involved in various Open Source projects and can be reached at: roberto@terreactive.com.