Intrusion Detection 1 What is Intrusion Detection We are referering to the act of detecting an unauthorized intrusion by a computer on a Network. Attemp to compromise or otherwise do harm, to other Network devices. Intrusion Detection System (IDS) is the high-tech equivalent of a burglar alarm ( to monitor access point, hostile activities, and known intruders). IDS as a specialized tool that knows how to read and interpret the contents of log files from router, Fire-Walls, servers and other Network devices. 2 1
What IDS does for a Network IDS can issue alarms or alerts, take various kinds of automatic action ranging. Shutting down Internet links or specific servers to launching back traces. Make other active attempts to identify attackers and actively Collect evidence of their nefarious activities. IDS is designed and used to detect and then to deflect or deter (if possible) such attacks or unauthorized use of: Systems Networks Firewalls IDSs can be software based or can combine hardware and software (in the form of preinstalled and preconfigured stand-alone IDS devices) IDS software runs on the same devices or servers where firewalls, proxies, or other boundary services operate. IDS system can detect and deal with insider attacks as well as external attacks. 3 TO distinguish IDS by the kinds of activities, Traffic, transaction or systems they monitor. IDS can be divided into: Network-based Host-based Distributed Network-based: IDSs that monitor network backbones and look for attack signatures. Host-based: IDs whereas those that operate on hosts defend and monitor the operating and file systems for signs of intrusion Ditributed: Group of IDSs functioning as remote sensors and reporting to a central management station are known as Distributed 4 IDS (DIDS). 2
Network IDS It monitors the entire network segment. The NIDS must operate in promiscuous Mode to monitor network traffic not destined for its own MAC address. Operation in promiscuous mode is Necessary to protect your network. In figure using three NIDS NIDS placed on strategic network segements and can monitor network traffic for all device on the segment. This configuration represents a standard Perimeter security network topology : The screened subnets the public servers are protected by NIDSs. When a public server is compromised on a screened subnet, the server can become a launching platform for additional exploits. Care full monitoring is necessary to prevent further damage. The internal host systems are protected by an additional NIDS to mitigate exposure to internal compromise. The use of multiple NIDS within a network is an example of a defense-in-depth security architecture. 5 HIDS differ from NIDS in two ways: Host-based IDS HIDS protects only the host systemon which it resides. NIC operates in nonpromiscuous(np) mode. NP mode can be an advantage in some cases. Not all NICs are capable of Promiscuous. CPU intensive for a slow host machine. No need to interrogate multiple rules to a specific need (e.g no need to interrogate multiple rules designed to detect DNS exploits on a host that is not running. In figure HIDS on mail server is customized to protect it from mail server exploits. While web server rules are tailorded for web server exploits. During installation individual host can be configured with a common set of rules. New rules can be loaded periodically to account for new vulnerabilities. 6 3
Distributed IDS DIDS functions in a Manager/probe architecture. NIDS detection sensors are remotely located and report to a centralized management station. That can be stored in a central database, new attack signatures can be downloaded to the sensors on an as-needed basis. The rules for each sensor can be tailored to meet its individual needs. Alerts can be forwarded to a messaging system located on the management station and used to notify the IDS administrator. In figure DIDS system comprised of 4 sensors and a centralized management station. Sensor NIDS 1 and 2 are operating in stealth promiscuous mode and are protecting the public servers. Sensor NIDS 3and 4 are protecting the host systems in the trusted computing base. The network transaction between sensor and manager can be on VPN ( highly recommended). 7 Using SNORT to Catch Intrusions Snort is an open source network intrusion detection system. Snort are capable of performing real-time traffic analysis and packet logging on IP networks. Snort can perform protocol analysis content searching /matching and can be used to detect a variety of attacks and probes such as: Buffer overflows Stealth port scans CGI attacks OS fingerprinting attempts. Three main modes (for Snort config): Sniffer Packet logger Network intrusion detection 8 4
Using SNORT to catch... Sniffer mode simply reads the packets off the network and display them in a continuous stream on the console. Packet logger mode logs the packet to the disk Network intrusion detection mode is the most complex and configurable, allowing snort to analyze network traffic for matches against a user-defined rule set and to perform one of several actions, based on what it sees. 9 Snort Architecture 1. It take all the packets from the network backbone. 2. Then it sends them through a chute to determine if they are packet from network backbone and how they should roll (the preprocessor) 3. It sorts the packets from the backbone according to the packet type (this is detection engine). 4. It is administrators task to decide what to do with the packets usually you roll them and store them (logging and database storage). The preprocessor the detection engine and the alert components of snort are all plug-ins. 1 2 3 4 Network Backbone Sniffer Preprocessor Detection Engine Alerts / logging Packets Logg files / database Rulesets 10 5
Snort Packet Sniffing Functionality IP traffic consists of many different types of network traffic (TCP; UPD; ICMP,...). Sniffer analyze the various network protocols to interpret the packet in to something human-readable. Packet sniffers have various uses: Network analysis and troubleshooting Performance analysis and benchmarking Eavesdropping for clear-text passwords and other interesting tidbits of data. Encryption your network traffic can prevent people from being able to sniff your packets into something readable. AS a sniffer snort can save the packets to be processed and viewed later as packet logger Network Backbone Sniffer Promiscuous Interface (eth 1) Visible Interface (eth 0) SSH HTTPS SQL SNMP Packets 11 Snort s Preprocessor The packet sorter has obtained all the packets it can and is ready to send the packets through the chute. Before the rolling the packets (the detection engine) the packet sorter needs to determine if they are packets from the network backbone). This is done through the preprocessor. The preprocessor takes the raw packets and checks them against certain plug-ins (like RPC plug-in and a port scanner plug-in). These plug-ins check for a certain type of behavior from the packet. The packet is determined to have a particular type of behavior it is sent to the detection engine. Preprocessor Detection Engine Packet HTTP Encoding Plug-in Port Scanning Plug-in 12 6
Snort Detection Engine The detection engine takes the data that comes from the preprocessor and its plug-ins and that data is checked through a set of rules. If the rules match the data in the packet then they are sent to the alert processor. The signature-based IDS function is accomplished by using various rule sets. The rule sets are grouped by category : Trojan horses, buffer overflows, access to various applications. The rules consist of two parts: The rule header is basically the action to take (log or alert) type of network packet (TCP, UDP,...) source and destination ip addresses and ports. The rule option is the content in the packet that should make the packet match the rule. The detection engine and its rules are the largest portion to learn and understand with the snort. Snort has a particular syntax that it uses with its rules. Rule syntax can involve the type of protocol the content the length the header and other various elements including garbage characters for defining buffer overflow rules. 13 Alerting /Logging Component After the Snort data goes through the detection engine it need to go out some where. If the data matches a rule in the detection engine then an alert is triggered. Alerts can be sent to a log file, through a network connection, through UNIX sockets or Windows Popup (SMB) or SNMP trap. The alert can also be stored in an SQL database such a My SQL and postgres. There are all sorts additional tools you can use with Snort. Include various plug-ins for Perl, PHP and Web Server to display the logs through a Web interface. Logs are stored in either text files (by default in (var/log/snort) or in a database such a MySQL and postgres. 14 7
Using Snort on your Network Passive monitoring is simple the ability to listen to network traffic and log it. Active monitoring involves the ability to either: Monitor traffic and then send alerts concerning the traffic that is discovered. Actually intercept and block this traffic. Snort is primarily used for active auditing. Intrusion detection applications also do signature-based and anomaly-based detection. Signature-based detection means that you predefine what an attack looks like, and then configure your network monitoring software to look for that signature. Anomaly-based detection requires the IDS to actually listen to the network and gather evidence about normal traffic. Then if any traffic occurs that seems different the IDS will respond by for example sending out an alert to the network administrator. 15 Using Snort on your... Snort can let you know that someone is sending an IMAP packet that contain the signature of an IMAP login overflow. You can either monitor the output or you can be notified by e-mail ( depending on set up of the snort). Now you can yank the Ethernet cable from the wall and look at the corps and find some tools used to break into the system and what they plan on doing on your machine. The rule for detecting this attack is: Alert tcp $EXTERNAL_NET any $HOME_NET 143 (msg: IMAP login buffer \ overflow attempt :;flow:established, to_server; content: LOGIN ; \ content: { ; distance: 0: nocase; \ byte_test:5,>,256,0,string,dec,relative;reference : bugtraq,6298; \ classtype:misc-attack; sid:1993;rev:1;) Rule check for any packet originating from the external network to any system on the internal network to port 143. The msg variable defines what is sent to the Snort alert. The rest of the information of the packet is content based. There are definition on the type of attack (misc-attack) the SID number (1993) and the bugtraq (www.securityfocus.com) reference on the attack 6298 (which you can find at www.securityfocus.com/bid/6298 ). 16 8
Usign Snort as packet sniffer and Logger The command-line interface for packet sniffing: #snort d e v Note that the v option is required. If you run snort on a command line without any options it look for the configuration file (.snortrc)in your home directory. -v put snort in packet sniffing mode (TCP header only). -d Include all network layer headers (TCP, UDP, and ICMP). -e Include the data link layer headers. You cannot use options d and e together without also using the v option. You can run snort with the -dev option to give us the most information: # Snort dev Log directory = /var/log/snort Initializing Network Interface eth0 --== Initialization complete ==--- 01/22-20:28:16.732371 0:45A:F2:F7:84 -> 1:0:5E:7F:FF:FD type :0x800 len :0x5B 131.215.183.30:57535 -> 239.255.253.156:427 UDP TTL:254 TOS :0x0 ID :26121 IPLen: 20 DgmLen : 77 Len : 57 02 01 00 00 31 20 00 00 00 00 00 73 70 000 02 65 6E... 1... Sp... En... 17 To use the packet logging features the command format is: #snort dev l {logging-directory} h {home-subnet-slash-notation } If you want to log the data into the directory /var/adm/snort/logs with the subnet 10.1.14.0/24 you would use the following: #snort dev l /var/adm/snort/logs h 10.1.14.0/24 There is also option to look at the data through TCPDump and Ethereal: #snort vd r {logfile} [tcp udp icmp] If you want to ignore all traffic to one IP address: #snort vd r <file> not host 10.1.14.25 If you want to ignore all traffic from the 10.1.14 network to destination port 80: #snort vd r <file> src net 10.1.14 and dst port 80 If you want to ignore all traffic coming from host 10.1.14.20 on port 22: # snort vd r <file> not host 10.1.14.20 and src port 22 To make Snort an IDS ( as NIDS), just add one thing to the packet logging function: the configuration file: # snort dev l /var/adm/snort/logs h 10.1.14.0/24 c /root/mysnort.conf Your rules are in the configuration file and they are what trigger the alerts. 18 9
Understanding Rule Parsing and Detection Engines We now have the packets from the network. we've decoded them and placed them into our data structures and have organized, filtered, and decoded the packet streams. The next part of the journey is the detection engine. The rules engine can be translated into two components: Rules builder/translator Detection engine based on the built rules Rule Builder: Snort rules are text based and usually stored in a directory or subdirectory from the Snort binary. The rules files are categorized into different groups; for example, the file ftp.rules contains a selection of FTP attacks and exploits. snort.conf: #################################################################### # Step #4: Customize your rule set # $RULE_PATH/bad-traffic.rules $RULE_PATH/exploit.rules $RULE_PATH/scan.rules $RULE_PATH/finger.rules $RULE_PATH/ftp.rules $RULE_PATH/telnet.rules $RULE_PATH/rpc.rules 19 Rule Format The following rule detects an old FTP exploit on a Linux machine. This rule is stored in the ftp.rules file. Snort rules are in text format all on one line, and can be broken into two sections: The rule header alert tcp $EXTERNAL_NET any -> $HOME_NET21 The rule options (msg:"ftp EXPLOIT wu-ftpd 2.6.0 site exec format string overflow Linux"; flow:to_server, established; content: " 31c031db31c9b046cd8031c031db " ; reference:bugtraq,1387; reference:cve,can-2000-0573; reference arachnids,2 87; classtype:attempted-admin; sid:344; rev4;) 20 10
Rule Header The following is a detailed description of the syntax used in the rule header: Alert: This will be the output format used. This output format will match to the top parts of the linked list tree header (ListHead). Other options for this position in the rule log,pass, dynamic, and activate. TCP This part of the syntax is the protocol being used; in this case, TCP. This will match to the top part of the linked list. Other options for this position in the rule UDP, IP, and ICMP. $EXTERNAL_NET This part of the syntax is the source IP address (by default set to any). any This is the source port set to any source port. -> This arrow indicates direction of the conversation; in this case, $EXTERNAL_NET on any port going to $HOME_NET on port 21. $HOME_NET When defining rules in Snort, $ Variables are used. A variable is defined once at the start of the snort.conf file and is used throughout the rules. The $HOME_NET variable would be defined as our network (in our example, 10.1.1.0/24), and the $EXTERNAL_NET variable would be set to any, which can be translated to "any network." On initialization, the Snort rules parser will substitute the $HOME_NET variable with the value set in the snort.conf. If you change your network address, rather than having to change all the rules, just change the $HOME_NET variable. 21 This is the destination port of the attack. In our rule header we can see that we are looking for any potential attacks on port 21. Port 21 is the port typically used for FTP action. 21 Rule Options The following is a detailed description of the syntax used in the rule option: msg "FTP EXPLOIT wu-ftpd 2.6.0 site exec format string overflow Linux." This is the message displayed by the alert. flow:to_server,established Snort contains keywords that link to detection plug-ins in the options part of a rule. The flow option is the third dimensionof the linked list, and is a pointer to the clientserver detection plugins (see the source code sp_clientserver.c).the clientserver plug-ins link to the stream4 preprocessor to check if the packet is part of an estab-lished session. content " 31c031db 31c9b046 cd80 31c031db " If the packet is matched against the Rule Tree node, then the session is an established one. Snort will take the following content and try to match it against the packet using the Boyer-Moore search algorithm Reference This keyword allows you to references to third-party attack identification information; for example, URLs to Bugtraq, McAfee, and the manufacturer or identification codes from vendors. Classtype: misc-attack Attacks are given a classification to allow users to quickly understand and prioritize each attack. Each classification has a default priority, which allows the user to prioritize what events he looks at via a simple number: 1 for High, 2 for Medium, and 3 for Low. Sid344 This is the Snort rule unique identifier. All of the rules in Snort have a unique identification number. Information on the rule canbe checked at www.snort.org/snort-db.the SID is also used by reporting programs to easily identify rules. Rev:4 This section of the options refers to the version number for the rule. When Snort rules are submitted by the open-source community, the rules go through a revision process. Over time, this process allows the rules to be fine-tuned and to avoid false-positives. 22 11
Summary 23 Thanks! I will appreciate direct feedback at: rahim.rahmani@miun.se 24 12