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 cellular pager 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: 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 passed on the network. Promiscuous mode can be set through the ifconfig command, such as the following: Running ifconfig with no options reveals that eth0 is now in promiscuous ( PROMISC ) mode. Using a tool such as tcpdump (included with Red Hat Enterprise Linux), we can see the large amounts of traffic flowing throughout a network: 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. Note 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/ .

Commands:
ifconfig eth0 promisc
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)
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)