Reading and printing or writing terms of snort network

align="right"> align="right"> align="right"> align="right"> Implementation Details Writing rules and understanding alerts for Snort, a network intrusion detection system Applies to the practice: "Identify data that characterize systems and aid in dectecting signs of suspicious behavior" Applicable Technologies: Solaris 2.x; UNIX operating system and derivatives Snortis a lightweight network intrusion detection system created by Martin Roesch (see http://www.snort.org).Snortis based on the libpcappacket capture library, commonly used in may TCP/IP traffic sniffers and analyzers. According to theSnortweb site, the program "can perform protocol analysis, content searching/matching, and can be used to detect a variety of attacks and probes, such as buffer overflow, stealth port scans, CGI attacks, SMB probes, OS fingerprinting attempts, and much more" Snorthas a real-time alerting capability, with alerts being sent tosyslog, a separate "alert" file, or as a WinPopup message via Samba's smbclient. This implementation covers the basic steps to obtain and install theSnortintrusion detection system on your computer. We examine how to writeSnortrules and describe how you can validate generated alerts. This document does not cover basic or advanced use of theSnortsystem, customization of the installation, configuration of the logging and alerting system, or answer such questions as where to deploySnortin your network environment. For details on these subjects, ports to other operating systems, plug-ins for reporting, and pre-built rule sets, consult theSnortweb site. Effort EstimatesTime to retrieve the necessary archive files from the distribution site will vary depending on connection speed. The expected time is a minute or less with a high speed connection. Building and installing Snort usually takes a minute or two, depending on machine performance. System PrerequisitesSnort can be built and installed on many UNIX systems. The following list is taken from the Snort web site: Snort is known to compile and run on: Sparc: SunOS 4.1.x, Solaris, Linux, and OpenBSD x86: Linux, OpenBSD, FreeBSD, NetBSD, and Solaris M68k/PPC: Linux, OpenBSD, NetBSD, Mac OS X Server Snort should also compile on: AIX, IRIX, HPUX, Tru64 Software Prerequisites To build and runSnort, you need internet access to retrieve the software and the following software tools: *.An MD5 cryptographic checksum program (refer to Using MD5 to verify the integrity of file contents). *.GZIP to uncompress the downloaded files ( ftp://ftp.gnu.org/gnu/gzip/). *.A C compiler; either the Sun C Computer or the free GNU C Compiler ( ftp://ftp.gnu.org /gnu/gcc/). *.libpcap library installed, see the implementation Installing libpcap to support network packet capturing tools on systems running Solaris 2.X. Downloading and Verifying Download the following files into the same directory and verify their checksums with an MD5 checksum program. File to Download MD5 Checksum http://www.snort.org/Files/snort- 1.6.3.tar.gz Source distribution for UNIX 5d628b08c0bf42af3affc9fcfca7ea69 http://www.snort.org/Files/snort- 1.6.3-sol-2.6-sparc-local Pre-compiled distribution for Solaris 2.6 ca491ade76253700860a6e2ac9259874 If the computed cryptographic checksum of the download files does not correspond to the information given above, verify that: *.your downloaded filenames match those listed *.your checksum program computes MD5 message digests Building The pre-compiled Solaris 2.6 distribution may be installed using thepkgaddprogram. If you are unfamiliar withpkgadd, or distrust supplied packages and wish to examine the source code, we recommend installing the program using the following procedure. Unpack theSnortsource distribution. The compressed file can be uncompressed using the GNUgunziputility and unpacked using the systemtarcommand: # gunzip -c snort-1.6.3.tar.gz| tar xvf - This creates a directory namedsnort-1.6.3. Change to this subdirectory because all remaining operations are performed there. You should review the INSTALL file to ensure that there are no other prerequisites before compiling the program. Additionally, configure-time switches are listed in this file, which allow such configurations as ‘flexible-response’ and SMB alerting. Now, configure and make the program with # /bin/sh ./configure # /usr/ccs/bin/make Testing Before Installation Test theSnortsystem. To test the correct operation ofSnort, executeSnortwith the following options from the install location, as follows: # ./snort –c ./snort-lib –v –i hmex You should receive output to the terminal similar to that produced by tcpdump(i.e., date and time stamp, unresolved source IP, source port, unresolved destination IP, destination port, and other protocol specific information). Installation Now install the program and manual pages with the following command. You should check the file ownerships and file protections once they have been copied to ensure that they cannot be modified or executed by unprivileged accounts, and that they reflect the security policy of your organization. # /usr/ccs/bin/make install Create a Directory for Snort Log Files Create a separate directory where theSnortlog and alert files will be stored. Note that this directory will contain connection information that may expose potential intrusions and attempted attacks of your network. We recommend that you restrict access to this directory as shown below. We further recommend that you store this directory within the/vardirectory because/varusually contains other log information: # /bin/mkdir /var/adm/snort # /bin/chmod 700 /var/adm/snort Testing After Installation Test theSnortsystem. TestSnortby following procedures similar to those under the "Testing Before Installation" section. To get help on command line options toSnort, issue the following from the command line: # ./snort -? Writing Rules SnortRules Snortallows you to write rules describing *.well-known and common vulnerability exploitation attempts *.violations of your security policy *.conditions under which you think a network packet(s) might be anomalous Through the use of an easy-to-understand and lightweight rule-description language,Snortrules can be both flexible and robust; written both for protocol analysis and content searching and matching. Two basic guiding principles must be kept in mind when writingSnortrules: *.Rules must be completely contained on a single line. *.Rules are divided into two logical sections, therule headerand therule options. The rule header contains the rule's action, protocol, source and destination IP addresses and CIDR (Classless Inter-Domain Routing) block, and the source and destination ports information. The rule option section contains alert messages. It also contains information about which parts of the packet you should inspect to determine if you should take the rule action. An example rule: alert tcp any any -> 192.168.1.0/24 111 (content:"|00 01 86 a5|"; msg: "mountd access";) [Example 1 - SampleSnortRule] This rule describes an alert that is generated when Snort matches a network packet with all of the following attributes: *.TCP packet *.Sourced from any IP address on any port *.Destined for any IP address on the 192.168.1.0 network (24 describes the CIDR block and netmask used) on port 111. The text up to the first parentheses is therule header: "alert tcp any any -> 192.168.1.0/24 111" The section enclosed in parenthesis is therule options: "(content:"|00 01 86 a5|"; msg: "mountd access";)" The word(s) before the colons in therule optionssection are calledoption keywords. These keywords may appear once, as with ‘content’ in Example 1 above, or multiple times, as shown in Example 2 below: alert tcp any any -> any 21 (content:"site exec"; content:"%"; msg:"site exec buffer overflow attempt";) [Example 2 - SampleSnortRule] The above rule illustrates an FTP vulnerability. The keyword "content" appears twice because the two strings that "content" describes are not concatenated but appear at different locations within the packet(s). For this rule to be violated, the content of a packet(s) must contain both character strings, "site exec" and "%". Therule optionssection is not specifically required by any rule; it is used for the sake of making tighter definitions of packets to collect or to issue an alert. Elements of an individual rule are treated as forming a logical AND statement. The complete collection of rules in aSnortrules library file (i.e., snort-lib) are treated as forming a larger logical OR statement. Basics in WritingSnortRules Rule Actions: Therule headercontains the information that defines the "who, where, and what" of a packet, as well as what to do when a packet occurs with all the attributes indicated in the rule. The first field in a rule is the rule action. The rule action tellsSnortwhat to do when it finds a packet that matches the rule criteria. There are three available actions inSnort- alert, log, and pass. alert- generates an alert using the selected alert method, and then log the packet log- logs the packet pass- drops (ignore) the packet Protocols: The next field in a rule is the protocol. There are three IP protocols thatSnortcurrently analyzes for suspicious behavior, TCP, UDP, and ICMP. In the future there may be more, such as ARP, IGRP, GRE, OSPF, RIP, and IPX. IP Addresses: The next portion of the rule header deals with the IP address and port information. The keyword "any" may be used to define any address.Snortdoes not have a mechanism to provide host name lookup for the IP address fields in the rules file. The addresses are formed by a straight numeric IP address and a CIDR block. The CIDR block indicates the netmask that should be applied to the rule's address and any incoming packets that are tested against the rule. A CIDR block mask of /24 indicates a Class C network, /16 a Class B network, and /32 a specific machine address. For example, the address/CIDR combination 192.168.1.0/24 would signify the block of addresses from 192.168.1.1 to 192.168.1.255. Any rule that used this designation for, say, the destination address would match on any address in that range. The CIDR designations give us an easy way to designate large address spaces with just a few characters. In Example 1 (above), the source IP address was set to match for any computer communicating, and the destination address was set to match on the 192.168.1.0 Class C network. A negation operator can be applied to IP addresses. This operator tellsSnortto match any IP address except the one indicated by the listed IP address. The negation operator is indicated with a "!". For example, an easy modification to the initial example is to make it alert on any traffic that originates outside of the local network with the negation operator as shown in Example 3. alert tcp ! 192.168.1.0/24 any -> 192.168.1.0/24 111 (content: "|00 01 86 a5|"; msg: "external mountd access";) [Example 3 - Example IP Address Negation Rule] This rule's IP addresses indicate "any TCP packet with a source IP address not originating from the internal network and a destination address on the internal network". Port Numbers: Port numbers may be specified in a number of ways, including "any" ports, static port definitions, ranges, and by negation. "Any" ports is a wildcard value, meaning literally any port. Static ports are indicated by a single port number, such as 111 for portmapper, 23 for telnet, or 80 for http. Port ranges are indicated with the range operator ":". The range operator may be applied in a number of ways, such as in Example 4. log udp any any -> 192.168.1.0/24 1:1024 Log UDP traffic coming from any port and destination ports ranging from 1 to 1024. log tcp any any -> 192.168.1.0/24 :6000 Log TCP traffic from any port going to ports less than or equal to 6000. log tcp any :1024 -> 192.168.1.0/24 500: Log TCP traffic from privileged ports less than or equal to 1024 going to ports greater than or equal to 500. [Example 4 - Port Range Examples] The negation operator, "!", may be applied against any of the other rule types (except "any", which would translate to none). For example, if for some reason you wanted to log everything except the X Windows ports, you could do something like the rule in Figure 5. log tcp any any -> 192.168.1.0/24 !6000:6010 [Example 5 - Example of Port Negation] Direction Operator: The direction operator "->" indicates the orientation, or "direction", of the traffic that the rule applies to. The IP address and port numbers on the left side of the direction operator designate traffic coming from the source host, and the address and port information on the right side of the operator designate destination host. There is also a bi-directional operator, which is indicated with a "<>" symbol. This tellsSnortto consider the address/port pairs in either the source or destination orientation. This is handy for recording and analyzing both sides of a conversation, such as telnet or POP3 sessions. An example of the bi-directional operator being used to record both sides of a telnet session is shown in Example 6. log ! 192.168.1.0/24 any <> 192.168.1.0/24 23 [Example 6 -Snortrules using the Bi-directional Operator] In Example 6, any traffic on any port originating from outside the internal network (192.168.1.x) with a destination of the internal network on the telnet port (23) is logged. Reciprocally, any telnet traffic originating from the internal network with a destination outside the internal network to any port is logged. Therefore, both sides of a telnet connection are logged. Snort Alerting SnortAlerts and How We Trust Them Alerting, part of the Alerting and Logging subsystem, is activated at run-time through the use of command-line options. In this section, we do not discuss these options, as they are detailed in documentation on the Snortweb site. Instead, we describe how you, the system administrator, can verify that aSnort-generated alert is valid. To fully trust an intrusion detection system alert, you must be able to examine three complementary data points: a rule representing behavior you know or suspect of being anomalous, an alerting message warning you of a rule violation or of particular behavior, and a network packet (or series of packets) causing the rule violation. In lieu of having all three components, you must be able to relate the network packet to at least one of the following: 1.the alerting message (of the proposed intrusion or intrusion attempt) 2.the rule violated (of the proposed intrusion or intrusion attempt) If neither of these relationships occur, you are precluded from characterizing the security event as a positive or negative. The network packet(s) is a critical point-of-examination, and without the actual, tangible packet(s) we cannot investigate whether a rule is violated or an alerting message displays a positive occurrence of violation to our security policy. Therefore, becauseSnortallows you to configure various levels of alerting and logging, we recommend thatSnortbe set up to log the offending packets causing the rule violation and to record the alerts, in separate files. SnortAlerts and Logs WhenSnortinspects a network packet and detects a match between a rule (describing a violation) and the network packet,Snortsends an alerting message to the user-defined facility and/or logs the packets causing the rule violation. The alerts "may either be sent to syslog, logged to an alert text file in two different formats, or sent as WinPopup messages using the Samba smbclient program. The syslog alerts are sent as security/authorization messages that are easily monitored with tools such as swatch[SWT93]. WinPopup alerts allow event notifications to be sent to a user-specified list of Microsoft Windows consoles running the WinPopup software. There are two options for sending the alerts to a plain text file; full and fast alerting. Full alerting writes the alert message and the packet header information through the transport layer protocol. The fast alert option writes a condensed subset of the header information to the alert file, allowing greater performance under load than full mode. There is a fifth option to completely disable alerting, which is useful when alerting is unnecessary or inappropriate, such as when network penetrations tests are being performed." Similarly, logging can be set up to "log packets in their decoded, human-readable format to an IP-based directory structure, or in tcpdumpbinary format to a single log file. The decoded format logging allows fast analysis of data collected by the system. The tcpdump format is much faster to record to the disk and should be used in instances where high performance is required. Logging can also be turned off completely, leaving alerts enabled for even greater performance improvements." To put this into perspective, let’s examine the logging and alerting areas of a system. For this discussion, the system sends alerts to thesyslogfacility and the offending network packet(s) to an IP-based directory structure. All alerts are logged viasyslogto a file called "alerts" in the file /var/adm/snort/alerts. Any alerting message found in this file will have corresponding offending network packets logged in the same directory as the alert file but under the IP address of the source packet. Using the rule in Figure 1, from above: alert tcp any any -> 192.168.1.0/24 111 (content:"|00 01 86 a5|"; msg: "mountd access";) WhenSnortinspects and matches the above rule to an offending network packet(s), an alerting message is sent tosyslogstating that a "mountd access" violation has occurred. This message is recorded in the file/var/adm/snort/alertsand the actual network packet(s) causing the alert is recorded in a file based on the source IP address of the offending packet(s), (i.e./var/adm/snort/a.b.c.d). Some problems may occur when filtering log entries into an IP-named file. For one, multiple alerts may involve one IP address. Under this condition, the offending packets violating each unique rule are sent to the same IP-named file; and mapping the specific alert to the offending packet(s) then demands a search and locate approach that could be time consuming. SnortIntegration with Other Administrative/Security Tools Snort's output can be used in concert with the output of other security tools to do the following: 1.corroborate a security event that happened by returning the process and user information of the event 2.identify discrepancies when processes that are reported by programs such asntopandtcpdump. Tripwire Configuration The following is thetripwireconfiguration for theSnortprogram once installed. Only a few files, theSnortexecutable,Snort(8) man page, and the snort alert file, require monitoring bytripwire. In addition, files necessary to implement the software (i.e.,libpcap) and the/var/log/snort/directory should be monitored. The following files should not change, as any changes are unexpected: @@define BINARY E+pinugsamc1-023456789 /usr/local/bin/snort @@BINARY /usr/local/man/man8/snort.8 @@BINARY /var/log/snort/alerts @@BINARY Acknowledgements The author would like to thank the developers ofSnortand the author(s) of theSnortweb site. Many of the examples and some documentation were reproduced in part and can be directly attributed to the developer's information as posted on the Snort web site ( http://www.snort.org/). The section entitled "Basics in Writing Snort Rules" was taken in part from the web document " Writing Snort Rules: How to write Snort rules and keep your sanity" by Martin Roesch.