Red Hat Enterprise Linux 3: Security Guide
PrevChapter 9. Intrusion DetectionNext

9.3. Network-based IDS

Network-based intrusion detection systems operate differently from host-based IDSes. The design philosophy of a network-based IDS is to scan network packets at the router or host-level, auditing packet information, and logging any suspicious packets into a special log file with extended information. Based on these suspicious packets, a network-based IDS can scan its own database of known network attack signatures and assign a severity level for each packet. If severity levels are high enough, a warning email or pager call is placed to security team members so they can further investigate the nature of the anomaly.

Network-based IDSes have become popular as the Internet grows in size and traffic. IDSes that can scan the voluminous amounts of network activity and successfully tag suspect transmissions are well-received within the security industry. Due to the inherent insecurity of the TCP/IP protocols, it has become imperative to develop scanners, sniffers, and other network auditing and detection tools to prevent security breaches due to such malicious network activity as:

Most network-based IDSes require that the host system network device be set to promiscuous mode, which allows the device to capture every packet passed on the network. Promiscuous mode can be set through the ifconfig command, such as the following:

ifconfig eth0 promisc

Running ifconfig with no options reveals that eth0 is now in promiscuous (PROMISC) mode.

eth0      Link encap:Ethernet  HWaddr 00:00:D0:0D:00:01  
          inet addr:192.168.1.50  Bcast:192.168.1.255  Mask:255.255.252.0
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:6222015 errors:0 dropped:0 overruns:138 frame:0
          TX packets:5370458 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:2505498554 (2389.4 Mb)  TX bytes:1521375170 (1450.8 Mb)
          Interrupt:9 Base address:0xec80 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:21621 errors:0 dropped:0 overruns:0 frame:0
          TX packets:21621 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:1070918 (1.0 Mb)  TX bytes:1070918 (1.0 Mb)

Using a tool such as tcpdump (included with Red Hat Enterprise Linux), we can see the large amounts of traffic flowing throughout a network:

tcpdump: listening on eth0
02:05:53.702142 pinky.example.com.ha-cluster > \
 heavenly.example.com.860:  udp 92 (DF)
02:05:53.702294 heavenly.example.com.860 > \
 pinky.example.com.ha-cluster:  udp 32 (DF)
02:05:53.702360 pinky.example.com.55828 > dns1.example.com.domain: \
 PTR? 192.35.168.192.in-addr.arpa. (45) (DF)
02:05:53.702706 ns1.example.com.domain > pinky.example.com.55828: \
 6077 NXDomain* 0/1/0 (103) (DF)
02:05:53.886395 shadowman.example.com.netbios-ns > \
 172.16.59.255.netbios-ns: NBT UDP PACKET(137): QUERY; BROADCAST
02:05:54.103355 802.1d config c000.00:05:74:8c:a1:2b.8043 root \
 0001.00:d0:01:23:a5:2b pathcost 3004 age 1 max 20 hello 2 fdelay 15 
02:05:54.636436 konsole.example.com.netbios-ns > 172.16.59.255.netbios-ns:\
 NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
02:05:56.323715 pinky.example.com.1013 > heavenly.example.com.860:\
 udp 56 (DF)
02:05:56.323882 heavenly.example.com.860 > pinky.example.com.1013:\
 udp 28 (DF)

Notice that packets that were not intended for our machine (pinky.example.com) are still being scanned and logged by tcpdump.

9.3.1. Snort

While tcpdump is a useful auditing tool, it is not considered a true IDS because it does not analyze and flag packets for anomalies. Instead, tcpdump prints all packet information to the screen or to a log file without any analysis. A proper IDS analyzes the packets, tags potentially malicious packet transmissions, and stores them in a formatted log.

Snort is an IDS designed to be comprehensive and accurate in successfully logging malicious network activity and notifying administrators when potential breaches occur. Snort uses the standard libcap library and tcpdump as a packet logging backend.

The most prized feature of Snort, in addition to its functionality, is its flexible attack signature subsystem. Snort has a constantly updated database of attacks that can be added to and updated via the Internet. Users can create signatures based on new network attacks and submit them to the Snort signature mailing lists (located at http://www.snort.org/lists.html) so that all Snort users can benefit. This community ethic of sharing has developed Snort into one of the most up-to-date and robust network-based IDSes available.

NoteNote
 

Snort is not included with Red Hat Enterprise Linux and is not supported. It has been included in this document as a reference to users who may be interested in evaluating it.

For more information about using Snort, refer to the official website at http://www.snort.org/.

PrevHomeNext
Host-based IDSUpIncident Response