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 traffic and successfully tag suspect traffic 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:

IP Spoofing
Denial-of-service attacks
arp cache poisoning
DNS name corruption
Man-in-the-middle attacks

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

ifconfig eth0 promisc

Running ifconfig with no options reveals that eth0 is now in promiscuous 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 Linux), we can see the large amounts of traffic flowing throughout a network:

# tcpdump
tcpdump: listening on eth0
02:05:53.702142 pinky.exampledomain.com.ha-cluster > \
 heavenly.exampledomain.com.860:  udp 92 (DF)
02:05:53.702294 heavenly.exampledomain.com.860 > \
 pinky.exampledomain.com.ha-cluster:  udp 32 (DF)
02:05:53.702360 pinky.exampledomain.com.55828 > dns1.exampledomain.com.domain: \
 PTR? 254.35.168.192.in-addr.arpa. (45) (DF)
02:05:53.702706 ns1.rdu.redhat.com.domain > pinky.exampledomain.com.55828: \
 6077 NXDomain* 0/1/0 (103) (DF)
02:05:53.886395 shadowman.exampledomain.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.exampledomain.com.netbios-ns > 172.16.59.255.netbios-ns:\
 NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
02:05:56.323715 pinky.exampledomain.com.1013 > heavenly.exampledomain.com.860:\
 udp 56 (DF)
02:05:56.323882 heavenly.exampledomain.com.860 > pinky.exampledomain.com.1013:\
 udp 28 (DF)

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

`snort`

While tcpdump is a useful auditing tool, it is not considered a true IDS because it does not analyze packets for anomalies; it only dumps them to the output screen or to a log file. A proper IDS will analyze the packets and then tag and log suspicious activity.

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 is not in its functionality, but in 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 will benefit. This community ethic of sharing has grown Snort into one of the most up-to-date and robust network-based IDSes available.

	Note
	Snort is not included with Red Hat 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.