SNORT:

1. SNORT: Plugins, Preprocessors, Output Modules And Third Party Enhancement

2. Plugins • Preprocessors • Output Modules • Third Party Enhancement

3. Introduction Preprocessors and output modules are two important parts of Snort architecture. Preprocessors- process received data packets before rules are applied to them. Output modules - control output generated from Snort’s detection mechanism.

4. The flow of a packet through Snort is shown in Figure where a packet is captured and then passed through preprocessors first. After that, the packet goes to the Snort detection engine where Snort rules are applied on the packet. As a result of application of Snort rules, if an alert or log message is generated, output processors or plug-ins operate on that output. The output of configured output modules is then used by the security administrators.

6. Snort allows you to select which preprocessors and output modules should be enabled. From a user standpoint, this is done through the Snort configuration file snort.conf. • Preprocessors and Output modules are also called plug-ins. • “input plug-in”, “input module” and “preprocessor” mean the same thing. Similarly, “output plug-in” and “output module” mean the same thing.

7. 1.Preprocessors When a packet is received by Snort, it may not be ready for processing by the main Snort detection engine and application of Snort rules. For example, a packet may be fragmented. Before you can search a string within the packet or determine its exact size, you need to defragment it by assembling all fragments of the data packet. The job of a preprocessor is to make a packet suitable for the detection engine to apply different rules to it. During the installation process, We can compile support of different preprocessors into Snort. Configuration parameters for different preprocessors (also called input plug-ins and input modules) are present in the snort.conf file. Using the file, you can enable or disable different preprocessors.

8. All preprocessors are enabled in the Snort configuration file using the preprocessor keyword. The general format of enabling a preprocessor is as follows: preprocessor <name of preprocessor>[: parameters] • The name of the preprocessor follows the preprocessor keyword. For example, thefollowing line in snort.conf file enables frag2 preprocessor: preprocessor frag2 • You can write your own preprocessors. Using README.PLUGINS in the doc directory of Snort source code.

9. 1.1.HTTP Decode The Hyper Text Transfer Protocol (HTTP) allows intrusion detection systems to use hexadecimal characters in URI to defeat known attacks. For example, this can be done by inserting something like %3A%2F%2F in the URI to replace :// characters. The HTTP decode preprocessor normalizes the HTTP requests so that they can be processed properly by the detection engine. You can use a list of ports used by HTTP servers or proxy servers as an argument to the preprocessor. The following line in the configuration file will apply HTTP decode for packets coming to ports 80, 8080, 443. preprocessor http_decode: 80 8080 443

10. 1.2.Port Scanning Port scanning is a process of finding out which ports are open on a particular host or all hosts on a network. The first step in any intruder activity is usually to find out what services are running on a network. The following is the general format of the preprocessor used in the snort.conf file. preprocessor portscan: <address> <ports> <time period> <file> • The address range of IP addresses to monitor is a single IP address or a network address. The range is specified using the CIDR block. • The number of ports accessed within a certain time period can be specified. For example, a number 5 means that if five ports are scanned within the time period specified, an alert is generated. • The time period is the number of seconds that defines the time period used for threshold. • The path of the file name where the activity should be logged.

11. 1.3- The frag2 Module This preprocessor does IP packet defragmentation. The frag2 preprocessor uses a splay tree algorithm, which is a self-organizing data structure. preprocessor frag2 The following command configures the preprocessor with 2MB memory and a timeout period of 30 seconds. preprocessor frag2: 2097152, 30

12. 1.4- The stream4 Module Stream4 is a replacement for the Stream module used in older versions of Snort. It provides two basic functions: 1. TCP stream reassembly 2. Stateful inspection You must configure two preprocessors in the snort.conf file for Stream4 to work properly. These modules are “stream4” and “stream4_reassemble.” Both of these take a number of arguments. If you don’t specify an argument, a default value is used instead. The general format of stream4 preprocessor is as follows: preprocessor stream4: [noinspect], [keepstats], \ [timeout <seconds>], [memcap <bytes>], [detect_scan], \ [detect_state]

13. 1.5-The spade Module Statistical Packet Anomaly Detection Engine (SPADE) is used to detect general packet anomalies in IP packets and a number of preprocessor keywords are associated with it. SPADE keeps a record of history data and uses threshold values to report anomalies. preprocessor spade: { <optionname>=<value> } Example- preprocessor spade:logfile=/var/log/spade/spade.log statefile=/var/log/spade/state.rcv cpfreq=25000 dest=alert adjdest=none 1.6ARP Spoofing Address Resolution Protocol (ARP) is used to find a MAC address when an IP address is known.

14. The arpspoof preprocessor detects anomalies in ARP packets. Specifically it does the following: • For all ARP requests, if source MAC address and sender’s MAC address are different, an alert is generated. If the source MAC address in the packet does not match the MAC address associated with source IP address, then an alert is generated. • For ARP replies, source MAC address is compared to sender’s MAC address. Similarly, destination MAC address is compared to receiver’s MAC address. An alert is generated if these entries mismatch. Example: preprocessor arpspoof_detect_host: 192.168.1.13 \ 34:45:fd:3e:a2:01

15. 2- Output Modules • Output modules are used to control the output from Snort detection engine. • By default, the output from alerts and logs go into files in the /var/log/snort directory. Using output modules, you can process output and send output messages a number of other destinations. • Commonly used output modules are: DATABASE, SNMP, SMB, SYSLOG etc. • The SNMP module can be used to send Snort alerts in the form of traps to a management server. • The SMB alerts module can send alerts to Microsoft Windows machines in the form of pop-up SMB alert windows.

16. • The syslog module logs messages to the syslog utility. Using this module you can log messages to a centralized logging server. • We can also use XML or CSV modules to save data in XML or comma separated files. The CSV files can then be imported into databases or spreadsheet software for further processing or analysis. Output modules are loaded at runtime by specifying the output keyword in the config file: output <name>: <options> output alert_syslog: log_auth log_alert

17. 2.1- alert_syslog This module sends alerts to the syslog facility. This module also allows the user to specify the logging facility and priority within the Snort config file, giving users greater flexibility in logging alerts. Available Keywords 1. Facilities • log_auth • log_authpriv • log_daemon • log_local0 • log_local1 • log_local2 • log_local3 • log_local4 • log_local5 • log_user

18. 2-Priorities • log_emerg • log_alert • log_crit • log_err • log_warning • log_notice • log_info • log_debug 3- Options • log_cons • log_ndelay • log_perror • log_pid

19. Format • alert_syslog: \ <facility> <priority> <options> Note:   As WIN32 does not run syslog servers locally by default, a hostname and port can be passed as options. The default host is 127.0.0.1. The default port is 514. output alert_syslog: \ [host=<hostname[:<port>],] \ <facility> <priority> <options> -Example • output alert_syslog: host=10.1.1.1:514, <facility> <priority> <options> Note:   As WIN32 does not run syslog servers locally by default, a hostname and port can be passed as options. The default host is 127.0.0.1. The default port is 514.

20. 2.2- alert_fast • This will print Snort alerts in a quick one-line format to a specified output file. It is a faster alerting method than full alerts because it doesn't need to print all of the packet headers to the output file and because it logs to only 1 file. Format • output alert_fast: [<filename> ["packet"] [<limit>]] <limit> ::= <number>[('G'|'M'|K')] Example • output alert_fast: alert.fast

21. 2.3 -alert_full • This will print Snort alert messages with full packet headers. The alerts will be written in the default logging directory (/var/log/snort) or in the logging directory specified at the command line. • Inside the logging directory, a directory will be created per IP. These files will be decoded packet dumps of the packets that triggered the alerts. The creation of these files slows Snort down considerably. This output method is discouraged for all but the lightest traffic situations.

22. -Format • output alert_full: [<filename> [<limit>]] <limit> ::= <number>[('G'|'M'|K')] • filename: the name of the log file. The default name is <logdir>/alert. You may specify "stdout" for terminal output. The name may include an absolute or relative path. • limit: an optional limit on file size which defaults to 128 MB. The minimum is 1 KB. See for more information. Example • output alert_full: alert.full

23. 2.4 -alert_unixsock • Sets up a UNIX domain socket and sends alert reports to it. External programs/processes can listen in on this socket and receive Snort alert and packet data in real time. This is currently an experimental interface. Format • alert_unixsock Example • output alert_unixsock 2.5 -log_tcpdump • The log_tcpdump module logs packets to a tcpdump-formatted file. This is useful for performing post-process analysis on collected traffic with the vast number of tools that are available for examining tcpdump-formatted files.

24. Format • output log_tcpdump: [<filename> [<limit>]] <limit> ::= <number>[('G'|'M'|K')] • filename: the name of the log file. The default name is <logdir>/snort.log. The name may include an absolute or relative path. A UNIX timestamp is appended to the filename. • limit: an optional limit on file size which defaults to 128 MB. When a sequence of packets is to be logged, the aggregate size is used to test the rollover condition. See for more information. Example • output log_tcpdump: snort.log

25. 2.6- database • This module from Jed Pickel sends Snort data to a variety of SQL databases. The arguments to this plugin are the name of the database to be logged to and a parameter list. Parameters are specified with the format parameter = argument. Format - database: <log | alert>, <database type>, <parameter list> The following parameters are available: • host - Host to connect to. If a non-zero-length string is specified, TCP/IP communication is used. Without a host name, it will connect using a local UNIX domain socket. • port - Port number to connect to at the server host, or socket filename extension for UNIX-domain connections. • dbname - Database name

26. 2.7-csv The csv output plugin allows alert data to be written in a format easily importable to a database. The output fields and their order may be customized. • Format output alert_csv: [<filename> [<format> [<limit>]]] <format> ::= "default"|<list> <list> ::= <field>(,<field>)* <field> ::= "dst"|"src"|"ttl" ... <limit> ::= <number>[('G'|'M'|K')] filename: the name of the log file. The default name is <logdir>/alert.csv. You may specify "stdout" for terminal output. The name may include an absolute or relative path. format: The list of formatting options which are suitable for current database. limit: an optional limit on file size which defaults to 128 MB. The minimum is 1 KB.

27. 2.8 -unified • The unified output plugin is designed to be the fastest possible method of logging Snort events. The unified output plugin logs events in binary format, allowing another programs to handle complex logging mechanisms that would otherwise diminish the performance of Snort. • The name unified is a misnomer, as the unified output plugin creates two different files, an alert file, and a log file. The alert file contains the high-level details of an event (eg: IPs, protocol, port, message id). The log file contains the detailed packet information. Both file types are written in a binary format described in spo_unified.h. • Format output alert_unified: <base file name> [, <limit <file size limit in MB>] output log_unified: <base file name> [, <limit <file size limit in MB>] • Example output alert_unified: snort.alert, limit 128 output log_unified: snort.log, limit 128

28. 2.9- log null Sometimes it is useful to be able to create rules that will alert to certain types of traffic but will not cause packet log entries. In Snort 1.8.2, the log_nullplugin was introduced. Format output log_null Example output log_null # like using snort -n ruletype info { type alert output alert_fast: info.alert output log_null }

29. Using ACID, SnortSnarf and Demarc with Snort Analysis Console for Intrusion Databases (ACID) is a tool used to analyze and present Snort data using a web interface. It is written in PHP. It works with Snort and databases like MySQL. What is ACID? • ACID consists of many Pretty Home Page (PHP) scripts and configuration files that work together to collect and analyze information from a database and present it through a web interface. • A user will use a web browser to interact with ACID. You have to have a web server, database server, PHP and some other tools installed on your system to make it work.

30. ACID offers many features: 1. Searching can be done on a large number of criteria like source and destination addresses, time, ports and so on. 2. Packet viewing is used to view different parts of packet. You can view different header parts as well as the payload. 3. Alerts can be managed by creating alert classes, exporting and deleting and sending them to an e-mail address. 4. Graphical representation includes charts based upon time, protocol, IP addresses, port numbers and classifications.

31. 5. Snapshots can be taken of the alerts database. As an example, you can view alerts for the last 24 hours, unique alerts, frequent alerts and so on. 6. You can go to different whois databases on the Internet to find out who owns a particular IP address that is attacking your network. You can then contact the responsible person to stop it. The whois database contains information about owners of domain names and IP addresses.

34. SnortSnarf • SnortSam is a tool used to make Snort work with most commonly used firewalls. It is used to create a Firewall/IDS combined solution. • SnortSnarf is a Perl program to take files of alerts from the Snort to produce HTML reports • Output intended for diagnostic inspection • Silicon Defense also supplies sensors with commercial support The tool consists of two parts: 1. A Snort output plug-in that is installed on the Snort sensor. 2. An agent that is installed on a machine close to Firewall or Firewall itself. Snort communicates to the agent using the output plug-in in a secure way.

36. Demarc • www.demarc.com • NIDS management console, integrating Snort with the convenience and power of a centralized interface for all network sensors • Monitor all servers / hosts to make sure network services such as a mail or web servers remain accessible at all times • Monitor system logs for anomalous log entries that may indicate intruders or system malfunctions