Intrusion Detection refers to the collection of techniques and methods used to identify suspicious activities directed at network and host systems. There are typically two major categories of Intrusion Detection Systems (IDS): signature-based IDS and anomaly-based IDS.
Intrusion Detection System or IDS is a software, hardware, or combination of both that detects intrusions. Snort is an open-source IDS available to the public. The effectiveness of IDS depends on the complexity and sophistication of its components. A standalone IDS combines hardware and software, and many companies offer integrated solutions. Network IDS or NIDS captures data traveling over network media and compares it to a database of known signatures. Depending on the match, IDS generates an alert or logs the activity to files or databases. Snort is primarily used as a NIDS. Host IDS or HIDS runs as an agent on an individual host and analyzes system and application logs to detect intrusions. Some HIDS operate in a passive state, only notifying when an event occurs, while others are active, monitoring network communications directed at the host and generating alerts in real-time.
IDS Policy
Before installing an IDS on your network, you need a policy that can detect intruders and respond appropriately. A policy must provide a set of rules and how they should be applied.
Honeypots
A honeypot is a system designed to attract hackers by exposing known vulnerabilities. When hackers find a honeypot, they often spend time on it, during which their activities and techniques can be recorded and analyzed.
Snort Rules
Once Snort is installed and configured, the next step is to think about rules. Snort rules define how to look for potential malicious traffic on the network. Without these IDS rules, Snort is merely another sniffer. Writing Snort rules is relatively simple, allowing users to customize them, while Snort.org and other resources provide official and community-shared rules.
Snort is a cross-platform, lightweight network intrusion detection tool. Classified as network-based misuse detection, Snort derives characteristics for each type of intrusion and writes them into rules, forming a ruleset. Captured packets are matched against this ruleset; matches indicate potential intrusions.
Features of Snort include:
Cross-platform support for various operating systems like Linux, OpenBSD, NetBSD, Solaris, HP-UX, AIX, IRIX, MacOS, and Windows.
A lightweight system, easy to install and configure, integrating quickly into overall network security solutions.
Real-time traffic analysis and IP packet recording capabilities, generating timely alerts for network attacks.
Protocol analysis and content matching for TCP, UDP, and ICMP, with future support for more protocols like ARP, GRE, OSPF, RIP, IPX, and others.
Flexible logging formats, supporting binary, ASCII, and XML formats, along with database logging for systems like MySQL, Microsoft SQL Server, Oracle, etc.
TCP stream plugin to reassemble TCP packets, countering stateless attacks.
SPADE plugin for detecting abnormal packets through statistical anomaly detection.
Extensive system protection capabilities, including interaction with firewalls through plugins like IP Tables and IPFilter, and issuing commands to disconnect malicious connections.
Rapid responsiveness to new threats with expansion through plugins and a simple rule description language, commonly compatible with commercial IDS.
Snortâs extensibility includes various plugins like database log output, broken packet detection, port scan detection, HTTP URL parsing, XML page generation, and more.
Firewalls can be likened to office gatekeepers verifying identities, whereas IDS acts like an online alarm system, identifying intruders and indicating their actions. Considered the second line of defense after firewalls.
Experiment Goals
Understand the working principles of Snort IDS
Utilize Snort in its three modes of operation
Skillfully create Snort rules
Experiment Principles
Snort IDS Overview: A powerful network intrusion detection system with real-time traffic analysis, capable of protocol analysis and packet content matching.
Snort IDS Architecture: Consists of four main modules â packet sniffer, pre-processor, detection engine, and alert/log module. Packets are sniffed, pre-processed, analyzed by the detection engine, and alerts/logs are generated based on defined rules.
Three Modes of Snort Operation: Sniffer mode reads packets and displays them continuously, Packet Logger mode records packets to the disk, and NIDS mode analyzes network traffic against user-defined rules and responds accordingly.
Snort Rules: Based on a simple, extensible language, rules are categorized by functionality and include actions such as pass, log, alert, dynamic, and activate. Rules consist of headers (actions, protocols, and informational data) and bodies (further analysis criteria).
Example Snort Rule:
The rule above generates an alert for TCP traffic not originating from 192.168.0.1/24, with any source port, directed to the specified destination.
The second âanyâ indicates that the destination IP address is any IP address.
21 indicates that the destination port is 21.
content:âUSERâ indicates that the matched string is âUSERâ.
msg: âFTPLoginâ indicates that the alert message is âFTPLoginâ.
The above rule can also be written as follows:
The direction operator -> indicates the flow direction of the data packet. The packet on the left consists of the source address and source port, destination address, and destination port. In addition, there is a bidirectional operator <> which makes Snort record/analyze data transmission between two IP addresses/ports for this rule, such as Telnet or POP3 sessions. The following rule demonstrates recording bidirectional data transmissions for a Telnet session:
The activate/dynamic rule pair extends Snort functionality. By using activate/dynamic rule pairs, you can activate one rule with another. When a specific rule is triggered, if you want Snort to continue recording packets that meet certain conditions, activate/dynamic rule pairs are convenient. Besides the required option activates, the activate rule is very similar to the alert rule (alert). Dynamic rules (dynamic) are also similar to the log rules (log), but they need an option: activated_by. Dynamic rules also require another option: count. When an activate rule is triggered, it activates the dynamic rule indicated by the number following the activate/activated_by option, recording count number of packets.
Below is an example of an activate/dynamic rule pair:
When communication is detected on port 23 (default for Telnet), the activate rule is triggered and activates the dynamic rule, which then records 20 subsequent packets according to the configuration.
In the example above, the âactivatesâ value for the activate rule is 111, and the âactivated_byâ value for the dynamic rule is 111. This associates the two rules together rather than them having identical rule headers.
2) Preprocessors Overview
Preprocessors run before the detection engine is called, and after the packet has been decoded. Through this mechanism, Snort can modify or analyze packets in an out-of-band way.
Preprocessors can be loaded and configured using the preprocessor keyword. Commonly used preprocessors include:
(1) HTTP Decode Preprocessor
The HTTP decoding preprocessor module is used to handle HTTP URLs, converting them into clear ASCII strings.
(2) Port Scanner (portscan)
The port scanner records the full process of a port scan initiated by a single source IP address.
(3) Stream Processor
The stream processor provides Snort with the ability to reassemble TCP packets. On configured ports, the stream processor can reassemble tiny fragments of TCP packets into complete TCP packets, allowing Snort to check for suspicious behavior.
(4) Frag2 Preprocessor
The frag2 preprocessor provides Snort with the ability to reassemble IP fragments. The frag2 preprocessor can reassemble fragmented packets to identify fragmentation attacks. It works by reconstructing all fragments into a complete packet containing full information, which is then passed to the detection engine.
5. Snort Application
Snort runs in command-line mode with the format: snortâ[options]. Options are argument parameters; filters are the filters.
1) Main Options for Snort
-A sets the alert mode to full, fast, or none. In full mode, Snort writes detailed alerts to the alert file in the traditional format. In fast mode, Snort writes only the alert time, content, IP address, and port number to the file. In none mode, the alert function is disabled.
-a displays ARP packets.
-b logs packets in tcpdump format, storing all packets in binary format in the snort.log file, enhancing Snortâs performance as it avoids converting logs to text files. With the -b option, Snort can operate in networks up to 100Mbps without issues.
-c uses the configuration file . The file content primarily controls which packets to log, alert, or ignore.
-C captures only ASCII characters in packets.
-d captures application layer packets.
-D runs Snort in daemon mode.
-e displays and records data link layer information.
-F reads BPF filter information from the file.
-h sets (C-class IP address) as the internal network. Using this switch causes external traffic to point rightwards and internal traffic to point leftwards. Though not critical, it makes the packet information format easier to read.
-i uses the network interface file.
-l logs packet information to directory. This sets a hierarchical directory structure for logs, storing captured packets in their respective directories based on their receiving IP addresses.
-n exits after processing packets.
-N disables logging, keeping the alert function active.
-p disables promiscuous sniffing mode. This option is useful during severe network congestion.
-r reads the file generated by tcpdump, reading and processing the file with Snort.
-s logs alert information to the system log, which may appear in the /var/log/messages directory.
-v displays packet information in detail mode on the terminal. This mode is slower and may lead to packet loss in an IDS environment.
-V displays the version number and exits.
2) Filters
Snort uses standard BPF format filters.
Snort applies the BPF mechanism, allowing for writing and executing BPF rule files on the probe. The BPF mechanism enables quick packet analysis rules based on source, destination, and other header information. By using sniffing and BPF, you can capture only the required traffic, reducing the data to process.
The BPF mechanism is easily understood and can be used to analyze TCP, UDP, IP, and ICMP protocols. The rule syntax resembles natural language, using âandâ and âorâ as rule operators and ânotâ for negation. Parentheses can group data for collective processing by the engine.
For example: ICMP capture: icmp.
Telnet request packet capture: tcp and dst port 23.
Record all traffic from the 192.168.0.0/24 network to the 202.98.0.0/24 network: ip and âsrc net 192.168.0 â and âdst net 202.98.0 â.
ăExperiment Stepsă
This exercise has hosts A, B in one group, C, D in another, and E, F in the third group.
First, use âSnapshot Xâ to restore the Linux system environment.
I. Snort Packet Sniffing
1. Start Snort
Enter the experiment platform, click the âConsoleâ button on the toolbar, go to the IDS working directory, and run Snort to monitor the eth0 network interface with the following requirements:
(1) Capture only icmp echo request packets sent by the group host.
(2) Display data link layer and application layer information in detail mode on the terminal.
(3) Log the captured information, with the log directory as /var/log/snort.
Snort command: snort -i eth0 -dev icmp and src group host IP -l /var/log/snort
Execute the above command on your machine, have the group host ping your machine and fill in Table 8.1 based on the captured Snort information.
Table 8.1
Data Frame Source MAC
Group Host MAC
Data Frame Destination MAC
Local Host MAC
IP Upper Layer Protocol Type
ICMP
Data Packet Source IP
Group Host IP
Data Packet Destination IP
Local Host IP
Total Length of Data Packet
0x62
IP Header Length
20
ICMP Header Length
8
ICMP Payload Length
56
ICMP Type/Code
8/0
2. Check Snort log records.
ăNoteă The last directory level in the default Snort log record is named after the source IP of the triggering packet. Snort can be stopped using the Ctrl+C key combination.
II. Snort Packet Logging
(1) Monitor the eth0 network interface, capturing only Telnet request packets from the group host, and store the captured packets in binary format in the log file /var/log/snort/snort.log.
Snort command: snort -i eth0 -b tcp and src group host IP and dst port 23
(2) Execute the above command on the local machine, have the group host Telnet remotely log into the local machine.
(3) Stop Snort capture (Ctrl+C), read the snort.log file, and view the packet content.
(1) Create a new Snort rule set file new.rules in the Snort rule set directory ids/rules, to alert on request packets to port 80/tcp of the local machine from external hosts, with a custom alert message.
To start Snort with the command snort -c snort.conf, initiate Snort in intrusion detection mode, enabling same-group hosts to access the current hostâs web service.
Refer to the alert log at /var/log/snort/alert to complete Table 8.3:
Table 8.3:
Alert Name
XXX
Source IP of Data Packet
Same-group host IP
Destination IP of Data Packet
Local IP
Source Port of Data Packet
Random
Destination Port of Data Packet
80
4. String Matching:
Explanation: After an FTP service receives an FTP request from a client (target port 21/tcp), the response packet will inform the client about the FTP software and version being used. Fedora core 5 uses the vsFTPd 2.0.4 FTP server software. In other words, when data transmitted over the network contains the string âvsFTPdâ, it is likely that an FTP user is logging into a Linux FTP server. The intrusion detection system can match network packets containing âvsFTPdâ, and record the subsequent packets since they may contain the username and password used for the login if the FTP session is conducted in plaintext.
1. In Snort rules set directory /opt/ExpNIS/NetAD-Lib/Tools/ids/rules, create a Snort rules file named new2.rules to alert on communications involving vsFTPd and capture the FTP client login username and password immediately after the FTP server announces its identity.
2. Use activate/dynamic rules for implementation:
activate snort rule:
snort rule: activate tcp any 21 -> any any (activates: 81; content: "vsFTPd"; msg: "FTP User Login";)
3. Edit the snort.conf configuration file to include the new2.rules rule set file.
4. Start Snort in intrusion detection mode to monitor the network. Note that FTP username and password data are application layer data (ISO seven-layer model), and Snort does not display or record application layer data by default. Therefore, specify Snort to capture and record application layer data during startup.
Start Snort with the command: snort -d -c snort.conf.
Same-group hosts log into FTP remotely, and the login process is shown in Figure 8.3:
Figure 8.3: FTP Login
Check the alert log (log file directory named after the remote FTP login host IP) to extract the username and password used during the FTP client login.
5. Port Scan Attack Detection:
1. Modify the snort.conf configuration file to start the port scan preprocessor, and initiate Snort in intrusion detection mode to detect port scanning activities from external sources.
2. Same-group hosts use Nmap (/opt/ExpNIS/NetAD-Lib/Tools/portscan/namp) to perform TCP port scanning on the current host. After the port scan is completed, check the portscan.log alert log and answer the following questions.
Note: If no logs are present in portscan.log after the first port scan, do not exit Snort and have the same-group host perform a second port scan.
Portscan.log log format description:
Date Time Source IP: Source Port -> Target Host IP: Scanned Port SYN ******S*
By default, Nmap performs a TCP port scan on the target host in a (ordered/unordered) sequence: unordered.
6. IP Fragmentation Reassembly Detection:
Explanation: In IP protocol data transmission, data packets are fragmented when the size of the IP packet exceeds the Maximum Transmission Unit (MTU). This process is called fragmentation. For instance, in an Ethernet environment, the maximum IP packet size (MTU) is 1500 bytes. If the packet size exceeds 1500 bytes, it needs to be fragmented for transmission.
Hence, IP fragmentation is common in network environments. However, maliciously crafted fragments can lead to Denial of Service (DoS) attacks, providing a method to bypass routers, firewalls, or network intrusion detection systems (NIDS). IDS perform detection based on packet characteristics, but an attacker can use fragmentation tools to split a packet into multiple fragments, which each do not match the signature individually. Snortâs frag2 preprocessor can reassemble fragmented packets to identify such attacks.
Detection of IP fragments is not rule-based, so Snort still requires a preprocessor to reassemble IP fragments. Activating the preprocessorfrag2 in the snort.conf configuration file can enable this functionality. Example configuration:
preprocessorfrag2:timeout60,memcap4194304
The timeout option specifies the reassembly timeout duration. If no fragment is received within this period, reassembly of the packet is stopped.
The memcap option restricts the memory available for fragmentation reassembly. If frag2 exhausts this memory, it will evict inactive fragments from the fragment table.
Operational Overview: Using hosts A and B as examples to explain the procedure. Host B uses fragroute to construct and split data into fragments, sending them via the eth0 interface. Host A modifies the Snort configuration file snort.conf to start the fragmentation reassembly preprocessor, writes alert rules for specific load data from host B, and starts Snort in intrusion detection mode to detect external IP fragmentation attacks.
1. Host B constructs and sends IP fragmented packets.
Use fragroute to fragment network interface packets into specified sizes. Method:
1. Change the current working directory to /opt/ExpNIS/NetAD-Lib/Tools/fragroute/, edit the fragroute configuration file (default directory /opt/ExpNIS/NetAD-Lib/Tools/fragroute/fragroute.conf), and modify the "ip_frag" item to set the fragment packet IP payload size.
Note: The size specified in ip_frag must be a multiple of 8, with a default of 24.
2. Execute the command: ./fragroute -f fragroute.conf Host A's IP, to start fragroute. Click the console button, open a new terminal, and ping Host A, fragroute will fragment the ICMP echo request packets and send them out.
Note: If fragroute shows "fragroute: no route to Host A's IP: No such process", ping the target host A first, then continue to start fragroute.
2. Host A monitor and detect.
1. Host A starts Snort in network sniffing mode to monitor and analyze the fragment packet payload conditions. Default configuration is as shown in Figure 8.4:
Figure 8.4
Note: Different fragment sizes specified in ip_frag may change the underlined part of the data.
From the analysis, we see that the ping request packet is sent out in fragments. The data string "15161718191A" is split into two separate packets, then reassembled by the third layer (network layer) of TCP/IP at the receiving end, combining "15161718191A" into a single packet.
2. Add Snort detection rules to detect and alert for packets in the network containing "15161718191A" data strings (based on actual data values, this is an example from Figure 22-1-2).
Snort rule
3. Modify the Snort configuration file snort.conf to start the fragmentation reassembly preprocessor and include the new rule set file.
Preprocessor description
4. Start Snort in intrusion detection mode to begin monitoring.
5. Same-group hosts continue to ping the current host, successfully fragmenting the ICMP echo request packets.
6. The current host checks the Snort alert log. If a "Fragment Test" alert message is present, Snort has successfully reassembled the fragmented packets.
**Experiment Review:**
This experiment helped me understand the powerful capabilities of an intrusion detection system (IDS). It offers real-time traffic analysis, IP network packet logging, protocol analysis, and content searching/matching, detecting various attack types, and providing real-time alerts. I also learned about Snortâs three basic functionalities: sniffer, packet logger, and intrusion detection system, and became familiar with its basic usage, such as specific commands, rules writing, and further understanding its rule-based configuration.
