31 May 2009

Snort, IDS, IPS, NSM, hacking and...beyond

Excerpts of

Snort 2.0 Intrusion Detection ISBN: 1-931836-74-4
Snort 2.1 Intrusion Detection, Second Edition ISBN: 1-931836-04-3
Snort™ For Dummies® ISBN: 0-7645-6835-3
Snort Cookbook ISBN: 0-596-00791-4
Hack the Stack: Using Snort and Ethereal to Master the 8 Layers of an Insecure Netork ISBN: 1-59749-109-8
Nessus, Snort, & Ethereal Power Tools: Customizing Open Source Security Applications ISBN: 1-59749-020-2
Other resources....

IDS(Basics)

IDS keywords

False positives and false negatives
False positives are alerts generated by an IDS because it thinks it has detected a valid attack against a monitored system, but the attack really isn’t valid. False positives are problems because they create alert noise that can hide a real attack, and then can send you on wild goose chases for attacks that never really happened. A false positive occurs when an IDS generates an alert on either:

Network traffic that looks like an attack to the IDS, but isn’t an attack.
A real attack that attack doesn’t apply to the system being monitored.

A false negative is a real attack that was missed by the IDS, and therefore not alerted on. An IDS might miss an attack because

the attack is not one it recognizes, because the IDS is overwhelmed/not exist a sign yet, or
because the attacker has successfully used a method of evading the IDS.

The implications of this are obvious: An attack missed by your IDS is an attack you’re not aware of. Too bad!

What Is an IDS, and Why Have One?
When we speak of intrusion detection, we are referring to the act of detecting an unauthorized intrusion by a computer on a network. This unauthorized access, or intrusion, is an attempt to compromise, or otherwise do harm, to other network devices.

An Intrusion Detection System (IDS) is the high-tech equivalent of a burglar alarm —a burglar alarm configured to monitor access points, hostile activities, and known intruders.

The simplest way to define an IDS might be to describe it as a specialized tool that knows how to read and interpret the contents of log files from routers, firewalls, servers, and other network devices.

Furthermore, an IDS often stores a database of known attack signatures and can compare patterns of activity, traffic, or behavior it sees in the logs it is monitoring against those signatures to recognize when a close match between a signature and current or recent behavior occurs.
At that point, the IDS can issue alarms or alerts, take various kinds of automatic action ranging from shutting down Internet links or specific servers to launching backtraces, and make other active attempts to identify attackers and actively collect evidence of their nefarious activities.

By analogy, an IDS does for a network what an antivirus software package does for files that enter a system: it inspects the contents of network traffic to look for and deflect possible attacks, just as an antivirus software package inspects the contents of incoming files, e-mail attachments, active Web content, and so forth to look for virus signatures (patterns that match known malware) or for possible malicious actions (patterns of behavior that are at least suspicious, if not downright unacceptable).

An IDS is designed and used to detect and then to deflect or deter (if possible) such attacks or unauthorized use of systems, networks, and related resources. Like firewalls, IDSs can be software based or can combine hardware and software (in the form of preinstalled and preconfigured stand-alone IDS devices). Often, IDS software runs on the same devices or servers where firewalls, proxies, or other boundary services operate; an IDS not running on the same device or server where the firewall or other services are installed will monitor those devices closely and carefully. Although such devices tend to operate at network peripheries, IDS systems can detect and deal with insider attacks as well as external attacks.

IDS systems vary according to a number of criteria. By explaining those criteria, we can explain what kinds of IDSs you are likely to encounter and how they do their jobs.
First and foremost, it is possible to distinguish IDSs by the kinds of:

activities
traffic
transactions
systems they monitor.

IDSs are classified by their functionality and are loosely grouped into the following
three main categories:

Network-based, IDSs that monitor network backbones and look for attack signatures are called network-based IDSs (NIDS)
Host-based, those that operate on hosts defend and monitor the operating and file systems for signs of intrusion and are called host-based IDSs (HIDS)
Distributed. Groups of IDSs functioning as remote sensors and reporting to a central management station are known as Distributed IDS (DIDS).

In practice, most commercial environments use some combination of network, and host, and/or application-based IDS systems to observe what is happening on the network while also monitoring key hosts and applications more closely.

IDSs can also be distinguished by their differing approaches to event analysis.

Some IDSs primarily use a technique called signature detection. This resembles the way many antivirus programs use virus signatures to recognize and block infected files, programs, or active Web content from entering a computer system, except that it uses a database of traffic or activity patterns related to known attacks, called attack signatures. Indeed, signature detection is the most widely used approach in commercial IDS technology today. So An IDS that uses signature detection matches the network traffic it sees against a list of attack signatures. These signatures are typically important bits and pieces of the attack that the IDS should look for in incoming network packets and flag as “bad” traffic. The downside of signature detection (like in antivirus products) is that it only knows to look for attacks that it has signatures for, and therefore can miss newly (so called 0day attacks ) developed attacks. A properly tuned signature detection IDS might be low on false positives, but can be high on false negatives. Snort uses signature detection.
Another approach is called anomaly detection. An IDS that uses anomaly detection works in a different manner. It learns what “normal” traffic for your network looks like,and will then alert you when it sees something that looks “abnormal.”It uses rules or predefined concepts about “normal” and “abnormal” system activity (called heuristics) to distinguish anomalies from normal system behavior and to monitor, report on, or block anomalies as they occur. Some anomaly detection IDSs implement user profiles. These profiles are baselines of normal activity and can be constructed using statistical sampling, rulebase approach or neural networks. Unfortunately, anything new or different might have the chance of being labeled abnormal, so a properly tuned anomaly detection IDS might be low on false negatives, but higher on false positives.

Literally hundreds of vendors offer various forms of commercial IDS implementations as well as an advanced method for interpreting IDS output.

Most effective solutions combine network- and host-based IDS implementations. Likewise, the majority of implementations are primarily signature based, with only limited anomaly-based detection capabilities present in certain specific products or solutions.
Finally, most modern IDSs include some limited automatic response capabilities, but these usually concentrate on automated traffic filtering, blocking, or disconnects as a last resort. Although some systems claim to be able to launch counterstrikes against attacks, best practices indicate that automated identification and backtrace facilities are the most useful aspects that such facilities provide and are therefore those most likely to be used.

Some IDS solutions use signature detection, some use anomaly detection, and some stay in the middle and use both (Hybrid IDS's) like Prelude.

So an IDS is an application that detects attacks against your computer or network, and lets you know when the attacks occur. A quick rundown of some of the benefits of running an IDS:

Detecting attacks. Attack detection is what an IDS is there for. An IDS can tell you if a worm is attacking your network, or if a computer system has been compromised.
Enforcing policies. An IDS can monitor an internal network for behavior that violates your organization’s network security or acceptable use policies. For instance, if users are chatting on XMPP Instant Messenger, when IM use is prohibited.
Providing an audit trail. An IDS can provide an after-the-attack audit trail for seeing how far an attacker got, and where it came from.
Other protection resources justification. An IDS can provide information on how well your firewall is working and exactly how many people are “out to get you.”This is useful when managers want justification for the firewall upgrade, extra staff for the security team, or your pay-raise ;-).

All of the preceding benefits are good reasons to install an IDS as part of your security strategy.

Network-based IDS (NIDS)
A network-based IDS (NIDS) like Snort (Snort is also a NIPS) analyzes packets coming across a network connection (More accurately, it monitors an entire network segment) for data that look like its part of an attack. NIDS perform the following tasks:

NIDS analyze network traffic for attacks, using signature or anomaly detection (or both). Its Network Interface Card (NIC) runs in promiscuous mode (Normally, a computer network interface card (NIC) operates in nonpromiscuous mode---In this mode of operation, only packets destined for the NICs specific Media Access Control (MAC) address are forwarded up the TCP/IP stack for analysis----.The NIDS must operate in promiscuous mode to monitor network traffic not destined for its own MAC address. In promiscuous mode, the NIDS can eavesdrop on all communications on the network segment. Operation in promiscuous mode is necessary to protect your entire network. However, in view of emerging privacy regulations, monitoring network communications is a responsibility that must be considered carefully).
Generates alerts to notify you of an attack in real-time.
Generates logs to drill down deeper into an attack, typically after the attack has occurred.

In Figure, we see a network using three NIDS. The NIDS units have been placed on strategic network segments and can monitor network traffic for all devices on the segment.

This configuration represents a standard perimeter security network topology where the screened subnets housing the public servers (DMZs) are protected by NIDSs. When a public server is compromised on a screened subnet, the server can become a launching platform for additional exploits.

Careful 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.

Layering defensive techniques on top of one another is known as defense in depth. This technique seeks to delay and deter attackers by buying time and delaying the ultimate succession of the attack. It is designed so that if one security control fails, it is unlikely that the same attack will penetrate the next layer.

So NIDS can often be distributed to different parts of your network infrastructure, yet can send alerts to one central console. Snort is a fine example of a NIDS.

Host-based IDS (HIDS)
While a NIDS looks at all the traffic on a network (segment) to detect intrusions, a host-based IDS (HIDS) like OSSEC only monitors for intrusions on the system it’s running on. HIDS differ from NIDS in two ways.

HIDS protects only the host system on which it resides, and
its network card operates in nonpromiscuous mode. Nonpromiscuous mode of operation can be an advantage in some cases, because not all NICs are capable of promiscuous mode. In addition, promiscuous mode can be CPU intensive for a slow host machine.

HIDS perform one or more of the following tasks:

HIDS look at incoming network traffic for attacks, using signature or anomaly detection. Typically, the NIC on a system running a HIDS is not in promiscuous mode.
HIDS examine system logs for unusual events, such as multiple invalid login attempts.
HIDS check the integrity of files on the system. This has nothing to do with the files’ content but rather whether or not a file has been modified (if files have been created or deleted. This is useful for detecting when backdoor or Trojan programs have been installed on your system).

Another advantage of HIDS is the ability to tailor the ruleset to a specific need.

For example, there is no need to interrogate multiple rules designed to detect Domain Name Services (DNS) exploits on a host that is not running.

Consequently, the reduction in the number of pertinent rules enhances performance
and reduces processor overhead.

Figure here depicts a network using HIDS on specific servers and host computers. As previously mentioned, the ruleset for the HIDS on the mail server is customized to protect it from mail server exploits, while the Web server rules are tailored for Web exploits. During installation, individual host machines can be configured with a common set of rules. New rules can be loaded periodically to account for new vulnerabilities.

Using HIDS is another way to defend your network, and contributes to a defense-in-depth posture by adding yet another layer of security. If someone gets past your firewall and sneaks by your NIDS, there’s a chance your HIDS can still catch him.

Distributed IDS (DIDS)
The standard DIDS functions in a Manager/Probe architecture. NIDS detection
sensors are remotely located and report to a centralized management station. Attack logs are periodically or continously uploaded to the management station and 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 here, we see a DIDS system comprised of four sensors and a centralized
management station.

Sensors NIDS 1 and NIDS 2 are operating in stealth promiscuous mode and are protecting the public servers.
Sensors NIDS 3 and NIDS 4 are protecting the host systems in the trusted computing base.

The network transactions between sensor and manager can be on a private network, as depicted, or the network traffic can use the existing infrastructure. When using the existing network for management data, the additional security afforded by encryption, or VPN technology, is highly recommended.

In a DIDS, complexity abounds. The scope and functionality varies greatly from manufacturer to manufacturer, and the definition blurs accordingly. In a DIDS, the individual sensors can be NIDS, HIDS, or a combination of both. The sensor can function in promiscuous mode or nonpromiscuous mode. However, in all cases, the DIDS’ single defining feature requires that the distributed sensors report to a centralized management station.

ISO/OSI Model overview

The Application Layer
Recognized as the official top layer of the OSI model, this layer serves as the window for application services. Layer 7 is not the actual application, but rather the channel through which applications communicate.

The Presentation Layer
The main purpose of the presentation layer is to deliver and present data to the application layer. This data must be formatted so that the application layer can understand and interpret it. The presentation layer is responsible for items such as:

Encryption and decryption of messages
Compression and expansion of messages, format translation
Handling protocol conversion

The Session Layer
Its purpose is to allow two applications on different computers to establish and coordinate a session. It is also responsible for managing the session while information and data are being moved. When a data transfer is complete, the session
layer tears down the session. Session-layer protocols include:

The Transport Layer
Whereas the application, presentation, and session layers are primarily concerned with data, the transport layer is focused on segments. Transport layer responsibilities include

end-to-end error recovery and
flow control.

Depending on the application protocol being used, the transport layer can send data either quickly or reliably. The two primary protocols found on this layer include:

TCP A connection-oriented protocol; provides reliable communication using handshaking, acknowledgments, error detection, and session teardown
UDP A connectionless protocol; offers speed and low overhead as its primary advantage

The Network Layer
Layer 3 is known as the network layer, which is tied to software and deals with packets. The network layer offers best effort at delivery and seeks to find the best route from the source to the target network. Network-layer components include:

The Data Link Layer
Layer 2 is known as the data link layer and is focused on traffic within a single local area network (LAN). The data link layer formats and organizes the data before sending it to the physical layer. Because it is a physical scheme, hard-coded Mandatory Access Control (MAC) addresses are typically used. The data link layer organizes the data into frames. When a frame reaches the target device, the data link layer strips off the data frame and passes the data packet up to the network layer. Data-link-layer components include:

Bridges
Switches
Network Interface Card (NIC)
MAC addresses

The Physical Layer
Bit-level communication takes place at layer 1. Bits have no defined meaning on the wire; however, the physical layer defines how long each bit lasts and how it is transmitted and received. Physical layer components include copper cabling, fiber cabling, wireless system components, and Ethernet hubs. The physical layer (for us here) has been extended to include:

Perimeter security
Device Security
Identification and authentication

Common Stack Attacks

The Application Layer
Most of the applications listed in this section are totally insecure because they were written for a different time. At the beginning of the networked world, most systems were mainframes that were locked in government and business buildings. There were no Category 5 cables interconnecting every office in the building, and no open wireless access points were being broadcast from the apartment next door. Suppressing passwords and other critical information on the monitor was considered robust enough to protect information and data. Here’s a short list of some of the insecure applications and high-level protocols:

FTP FTP is a TCP service that operates on ports 20 and 21 and is used to move files from one computer to another. Port 20 is used for the data stream, and transfers the data between the client and the server. Port 21 is the control stream, and is used to pass commands between the client and the FTP server. Attacks on FTP target misconfigured directory permissions and compromised or sniffed cleartext passwords. FTP is one of the most commonly hacked services.

Telnet Telnet is a TCP shell service that operates on port 23. Telnet enables a client at one site to establish a session with a host at another site. The program passes the information typed at the client’s keyboard to the host computer system. While Telnet can be configured to allow anonymous connections, it should also be configured to require usernames and passwords. Unfortunately, even then,Telnet sends them in cleartext. When a user is logged in, he or she can perform any allowed task.

Simple Mail Transfer Protocol (SMTP) This application is a TCP service that operates on port 25, and is designed to exchange electronic mail between networked systems. Messages sent through SMTP have two parts: an address header and the message text. All types of computers can exchange messages with SMTP. Spoofing and spamming are two of the vulnerabilities associated with SMTP.

Domain Name Service (DNS) This application operates on port 53, and performs address translation. DNS converts fully qualified domain names (FQDNs) into a numeric IP address and converts IP addresses into FQDNs. DNS uses UDP for DNS queries and TCP for zone transfers. DNS is subject to poisoning and if misconfigured, can be solicited to perform a full zone transfer.

Trivial File Transfer Protocol (TFTP) TFTP operates on port 69, and is a connectionless version of FTP that uses UDP to reduce overhead and reliability. It does so without TCP session management or authentication, which can pose a big security risk. It is used to transfer router configuration files and to configure cable modems. People hacking those cable modems are known as uncappers.

Hypertext Transfer Protocol (HTTP) HTTP is a TCP service that operates on port 80. HTTP helped make the Web the popular service that it is today. The HTTP connection model is known as a stateless connection. HTTP uses a request- response protocol where a client sends a request and a server sends a response. Attacks that exploit HTTP can target the server, browser, or scripts that run on the browser. Nimda is an example of the code that targeted a Web server.

Simple Network Management Protocol (SNMP) SNMP is a UDP service that operates on ports 161 and 162, and was designed to be an efficient and inexpensive way to monitor networks. The SNMP protocol allows agents to gather information (e.g., network statistics) and report back to their management stations. Some of the security problems that plague SNMP are caused by the fact that community strings are passed as cleartext and the default community strings (public/private) are well known. SNMP version 3 is the most current and offers encryption for more robust security

The Session Layer
There is a weakness in the security controls at the presentation and session layers. Let’s look at the Windows NT LanMan (NTLM) authentication system. Originally developed for Windows systems and then revised for Windows NT post service pack 2 systems, this security control proved to be an example of weak encryption (i.e., many passwords encrypted with this system could be cracked in less than 1 second because of the way Microsoft stored the hashed passwords).

An NTLM password is uppercase, padded to 14 characters, and divided into seven character parts. The two hashed results are concatenated and stored as a LAN Manager (LM) hash, which is stored in the SAM. The session layer is also vulnerable to attacks such as session hijacking.

Network Basic Input/Output System (NetBIOS) is another service located in this area of the stack. NetBIOS was developed for IBM and adopted by Microsoft, and has become and industry standard. It allows applications on different systems to communicate through the LAN. On LANs, hosts using NetBIOS systems identify themselves using a 15-character unique name. Since NetBIOS is non-routable, Microsoft adapted it to run over Transmission Control Protocol/Internet Protocol (TCP/IP). NetBIOS is used in conjunction with SMB, which allows for the remote access of shared directories and files. This key feature of Windows makes file and print sharing and the Network Neighborhood possible. It also introduced other potential vulnerabilities into the stack by giving attackers the ability to enumerate systems and gather user names and accounts, and share information. Almost every script kiddie and junior league hacker has exploited the net use command.

The Transport Layer
The transport layer is rife with vulnerabilities, because it is the home of UDP and TCP.
Because UDP is connectionless, it’s open for attackers to use for a host of denial of service (DoS) attacks. It’s also easy to spoof and requires no confirmation. TCP is another used and abused protocol. Port scanning and TCP make the hacker trade possible. Before a hacker can launch an attack, he or she must know what is running and what to target. TCP makes this possible. From illegal flag settings, NULL, and XMAS, to more common synchronous (SYN) and reset (RST) scans, TCP helps attackers identify services and operating systems.

The Network Layer
At the network level are services such as IP and ICMP. IPv4 has no security services built in, which is why Secure Internet Protocol (IPSec) (a component of IPv6) was developed. Without IPSec, IP can be targeted for many types of attacks (e.g., DOS), abused through source routing, and tricked into zombie scanning “IPID Scan.”

While ICMP was developed for diagnostics and to help with logical errors, it is also the target of misuse. ICMP can be used to launch Smurf DoS attacks or can be subverted to become a covert channel with programs such as Loki.

The Data Link Layer
The dangers are real at the data link layer. Conversion from logical to physical addressing must be done between the network and data link layers. Address Resolution Protocol (ARP) resolves logical to physical addresses. While critical for communication, it is also used by attackers to bypass switches and monitor traffic, which is known as ARP poisoning. Even without ARP poisoning, passive sniffing can be a powerful tool if the attacker positions him/herself in the right place on the network.

The Physical Layer
An attacker gaining access to the telecommunications closet, an open port in the conference room, or an unused office, could be the foothold needed to breach the network or, even worse, gain physical access to a server or piece of equipment. It’s a generally accepted fact that if someone gains physical access to an item, they can control it. The Cisco site provides a page that explains how to reset the password and gain entry into a Cisco device.

WARNING
Logical controls are of little value if no physical controls are put in place (i.e., the best logical controls are of little value if an attacker can walk in and reboot a server or gain physical access of the SAM and its passwords

A wide range of protective mechanisms are shown at the various layers. The reason why so
many countermeasures were developed can be traced to the early development of TCP/IP,
which was originally developed as a flexible, fault tolerant network; security was not the driving concern.The network was designed to these specifications to withstand a nuclear strike that might destroy key routing nodes. The designers of this original network never envisioned the Internet used today; therefore, many TCP/IP protocols and applications are insecure. Security controls like IPSec are add-ons to the original protocol suite.

Mapping OSI to TCP/IP

The TCP/IP protocol suite (which makes up all Internet traffic) only loosely fits into the OSI Model. OSI has 7 levels while TCP/IP has 4 layers. TCP/IP is a combination of suites of different protocols at different layers of the OSI model

Layer 1 (Physical): Layer 1 is your physical network connection. For instance, your Ethernet network interface card (NIC).
Layer 2 (Data Link): Layer 2 is the binary data that rides over the physical connection. For example, the 802.2 Ethernet protocols operate at this layer. Ethernet Media Access Control (MAC) addresses and ARP are also at this layer.
Layer 3 (Network): Layer 3 provides the addressable routing of packets. The Internet Protocol (IP) and ICMP operates at this layer, so IP addresses are known as Layer 3 addresses.
Layer 4 (Transport): Layer 4 provides end-to-end networking communications. While Layer 3 tells data where it needs to go, Layer 4 tells it how to establish a connection. The Transmission Control Protocol (TCP) and Universal Datagram Protocol (UDP) perform this function in TCP/IP. Layer 4 communications over TCP/IP is done through numbered “ports” over which network applications and network services run. Web servers, for example, typically run over TCP port number 80.
Layer 7 (Application): Layer 7 provides for the end-to-end communication between applications. An example of this is the Hyper-Text Transport Protocol (HTTP), used by Web servers and Web browsers to communicate between each other, and e-mail SMTP-based protocol.

The layers we refer to most here are Layer 3 (Network), Layer 4 (Transport), and Layer 7 (Application).

Where fits the firewall then? Doesn’t My Firewall Serve as an IDS?
No! Having said that and said it emphatically, we shall try to stop the deluge of scorn from firewall administrators who might take exception to the statement. Admittedly, a firewall can be configured to

detect certain types of intrusions, such as an attempt to access the Trojan backdoor SubSeven’s port 27374.
In addition, it could be configured to generate an alert for any attempt to penetrate your network. In the strictest sense this would be an IDS function.

However, it is asking enough of the technology to simply determine what should and shouldn’t be allowed into or out of your network without expecting it to analyze the internal contents of every packet. Even a proxy firewall is not designed to examine the contents of all packets; the function would be enormously CPU intensive. Nevertheless, a firewall should be an integral part of your defense-in-depth, with its main function being a gatekeeper. A firewall is a basic requirement for a network connected to the Internet these days; without a firewall, you’re not even doing the minimum to protect your network and computers. A firewall is your network’s bouncer, only allowing certain people in or out. A firewall protects computer resources that you don’t want outsiders to reach (for example, your file servers), while allowing access to resources you do want outsiders to reach (your Web server, for example).

You need both a firewall and an IDS. Again a firewall is not a replacement for an IDS, it’s just a layer of the total security onion.

Although some firewalls have intrusion detection capabilities, they are typically able to detect fewer attacks than a full-fledged IDS

What Is an Intrusion?
At the scene of a crime, one of the first tasks of the forensic evidence technician is the gathering of fingerprints. These fingerprints can be used to determine the identity of the criminal.

Just as in criminal forensics, network forensics technicians gather fingerprints at the scene of a computer crime. The fingerprints are extracted from the victim computer’s log and are known as signatures or footprints.

Almost all exploits have a unique signature. Let’s look at the signatures of our three 2001's threats: Directory Traversal, CodeRed, and Nimda.

Directory Traversal footprint The Directory Traversal exploit or dot “../” could be used against IIS 4.0 and 5.0 if extended Unicode characters were used to represent the “/” and “\”. For example, if a hacker entered the string below into his browser, the contents of a directory on the victim’s computer would be displayed on the hacker’s system. The important part of this example is the uniqueness of the pattern /..%c1.The pattern can be used as a digital fingerprint or signature/footprint in an IDS.

http://Victim.com/scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir

CodeRed footprint For the CodeRed exploit, the system footprint was provided by Advisory CA-2001-19 and stated that the CodeRed worm activity can be identified on a machine by the presence of the entry in the Web server log files (see below).The footprint is extremely important from an intrusion detection point of view. It represents the information necessary to detect the intrusion before it can do damage to your network.

/default.ida?NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN%u9090%u6858%ucbd
3%u7801%u9090%u6805%ucbd3% u7801 etc.

Nimda footprint The numerous footprints described in the CERT Advisory CA-2001-26 read like a dictionary of exploits. Here are displayed a few of the exploits delivered in its payload. When one is building an intrusion detection rule, Nimda’s system footprints offer many signatures from which to choose. Furthermore, because the zombie machines or hacker scripts cycle through the complete list, any entry could be used to detect the intrusion. The most obvious one to use (from a security administrator’s point of view) is GET /scripts/root.exe. GET root.exe in an HTML request is very suspicious, especially on a Windows machine.

GET /scripts/root.exe?/c+dir
GET /c/winnt/system32/cmd.exe?/c+dir
GET /d/ winnt/system32/cmd.exe?/c+dir
GET /scripts/..%5c../..%5c../winnt/system32/cmd.exe?/c+dir
GET /_mem_bin/..%5c….%5c../winnt/system32/cmd.exe?/c+dir
GET /_vti_bin/..%5c….%5c../winnt/system32/cmd.exe?/c+dir

Why Are Intrusion Detection Systems Important?
In the world of network security, the ability to know when an intruder is engaged in reconnaissance, or other malicious activity, can mean the difference between being compromised and not being compromised. In addition, in some environments, what you don’t know can directly affect employment—yours.

IDSs such as Snort can detect ICMP and other types of network reconnaissance scans that might indicate an impending attack. In addition, the IDS can alert the admin of a successful compromise, which allows him the opportunity to implement mitigating actions before further damage is caused.

IDSs provide the security administrator with a window into the inner workings of the network, analogous to an X-ray or a blood test in the medical field. The ability to analyze the internal network traffic and to determine the existence of network viruses and worms is not altogether different from techniques used by the medical profession. The similarity of network viruses and worms to their biological counterparts has resulted in their medical monikers. IDSs provide the microscope necessary to detect these invaders. Without the aid of intrusion detection, a security administrator is vulnerable to exploits and will become aware of the presence of exploits only after a system crashes or a database is corrupted.

Why Are Attackers Interested in Me?
Zombie attacks are real and cost corporations and consumers billions. Zombies are computerized soldiers under the control of nefarious hackers, and in the process of performing distributed denial-of-service (DDoS) attacks, they blindly carry out the will of their masters.

In February 2000, a major DDoS attack blocked access to eBay, Amazon.com, AOL-TimeWarner, CNN, Dell Computers, Excite,Yahoo!, and other e-commerce giants. The damage done by this DDoS ranged from slowdown to complete system outages. The U.S. Attorney General instructed the FBI to launch a criminal investigation. This historical attack was perpetrated by a large group of compromised computers operating in concert. The lesson to be learned from this event is that no network is too small to be left unprotected. If a hacker can use your computer, he will. The main purpose of the CodeRed exploit was to perform a DDoS on the White House Web site. It failed, due only to the author’s oversight in using a hard-coded IP address instead of DNSs. The exploit compromised over a million computers, ranging from corporate networks to home users. In light of the war on terrorism and taking into account government-sponsored hacking, the use of an IDS such as Snort can prove crucial in the protection of the world’s network infrastructure.

Snort has many rules that can alert the system administrator to the presence of zombies.

Where Does an IDS Fit with the Rest of My Security Plan?
IDSs are a great addition to a network’s defense-in-depth architecture. They can
be used to identify vulnerabilities and weaknesses in your perimeter protection
devices; for example, firewalls and routers.

The firewall rules and router access lists(ACLs) can be verified regularly for functionality.
In the event these devices are reconfigured, the IDS can provide auditing for change management control.
IDS logs can be used to enforce security policy and are a great source of forensic evidence.
Inline IDSs can halt active attacks on your network while alerting administrators to their presence.
Properly placed IDSs can alert you to the presence of internal attacks. Industry analysis of percentages varies. However, the consensus is that the majority of attacks occur from within.
An IDS can detect failed administrator login attempts and recognize password-guessing programs. Configured with the proper ruleset, it can monitor critical application access and immediately notify the system administrator of possible breaches in security.

Where Else Should I Be Looking for Intrusions?
When computers that have been otherwise stable and functioning properly begin to perform erratically and periodically hang or show the Blue Screen of Death, a watchful security administrator should consider the possibility of a buffer overflow attack.

Buffer overflow attacks represent a large percentage of today’s computer exploits. Failure of programmers to check input code has led to some of the most destructive and costly vulnerabilities to date. Exploits that are designed to overflow buffers are usually operating system and application software specific. Without going into detail, the input to the application software is manipulated in such a manner as to cause a system error or “smash the stack” as it is referred to by some security professionals.

At this point in the exploit, malicious code is inserted into the computer’s process stack and the hacker gains control of the system. In some cases, for the exploit to be successful, the payload, or malicious code, must access OS functions located at specific memory addresses. If the application is running on an OS other than that for which the exploit was designed, the results of overflowing the buffer will be simply a system crash and not a compromise; the system will appear to be unstable with frequent resets. Interestingly, in this situation the definition of the exploit changes from a system compromise to a DoS attack.

IDSs can alert you to buffer overflow attacks. Snort has a large arsenal of rules designed to detect these attacks; the following are just a few:

Red Hat lprd overflow
Linux samba overflow
IMAP login overflow
Linux mountd overflow

We discuss these rules, along with many more, in detail later.

Backdoors and Trojans
Backdoors and Trojans come in many flavors. However, they all have one thing in common— they are remote control programs. Some are malicious code designed to “zombiefy” your computer, drafting it into a hacker’s army for further exploits. Others are designed to eavesdrop on your keystrokes and send your most private data to their authors. Programs such as Netbus, SubSeven, and BO2k are designed to perform these tasks with minimal training on the part of the hacker.

Remote control programs can have legitimate purposes, such as remote system administration. PCAnywhere, Citrix, and VNC are examples of commercial and free remote control programs. However, it should be pointed out that commercial products, in the hands of hackers, could just as easily be used for compromise. The legitimate use of these tools should be monitored, especially in sensitive environments.

Snort has many rules to aide the security administrator in detecting unauthorized use of these programs.

What Else Can Be Done by IDSs?
The name Intrusion Detection System conjures up a vision of a device that sits on the perimeter of your network alerting you to the presence of intruders. While this is a valid application, it is by no means the only one. IDS can also play an important role in a defense-in-depth architecture by protecting internal assets, in addition to acting as a perimeter defense. Many internal functions of your network can be monitored for security and compliance. In this section, we look at various internal IDS applications and reveal how Snort can be used to protect your most valuable resources.

Monitoring Database Access
When pondering the selection of a candidate for the “Crown Jewels” of a company, there is no better choice than the company’s database. Many times, an organization’s most valuable assets are stored in that database. Consider the importance of data to a pharmaceutical research company or to a high-tech software developer. Think the unthinkable—the theft of the U.S. military’s launch codes for the nation’s Intercontinental Ballistic Missile System. The importance of data confidentially,
integrity, and availability in such situations cannot be stressed strongly enough.

Admittedly, database servers are usually located deep within a network and are only accessible by internal resources. However, if one considers the FBI’s statistics for internal compromise, this location is not as safe as one might assume. A NIDS, when properly configured on the same segment with your database server, can go a long way in preventing internal compromise.

Snort includes a comprehensive ruleset designed to protect from database exploits. The following are a few examples:

ORACLE drop table attempt
ORACLE EXECUTE_SYSTEM attempt
MYSQL root login attempt
MYSQL show databases attempt

Monitoring DNS Functions
“What’s in a name server? ”The answer is,“Your network’s configuration.

The entries in your domain name server might include internal network component names, IP addresses, and other private information about your network.

The only information a hacker requires to map your network can be gleaned from a DNS zone transfer. The first step in a DNS reconnaissance probe is to determine the version of your DNS server. Snort detects this intrusion by invoking the rule “DNS
Name Version Attempt.”The second step in the exploit will be detected by the Snort rule “DNS Zone Transfer Attempt.”

IDSs placed at key locations within your network can guard against DNS exploits. Snort offers many rules to protect your namespace.

E-Mail Server Protection
When taking into account e-mail protection, we often resort to e-mail virus-scanning software to mitigate exposure. These programs have matured over the years and have become a formidable defense against attacks stemming from e-mail. Snort has many rules that can detect e-mail viruses such as the QAZ worm, NAVIDAD worm, and the newest versions of the ExploreZip.

In response to a brand new threat or a revision of an existing virus, Snort rules can be modified immediately. Viruses are often in the wild for a considerable amount of time before virus-scanning companies respond with updates; this delay can prove to be a costly one. In addition, one should develop a comprehensive approach to e-mail security by considering the possibility of an attack on the server itself. Snort has the ability to detect viral e-mail content while simultaneously protecting the e-mail server from attack. It is this added functionality that makes Snort stand out.

Snort can be configured to detect and block e-mail bombers, as well as other exploits that might disable your e-mail services.

Using an IDS to Monitor My Company Policy
In today’s litigious society, given the enormous legal interest in subjects such as
downstream litigation and intellectual property rights, it would be prudent to consider monitoring for compliance with your company’s security policy. Major motion picture companies have employed law firms specializing in Internet theft of intellectual property. Recently, many companies were sued because their employees illegally downloaded the motion picture X. Some of the employees involved were not aware that their computers were taking part in a crime. Nevertheless, the fines for damages were stiff—up to $100,000 in some cases. Many file-sharing programs, such as KaZaA and Gnutella, Emule are often used to share content that is federally prohibited. Computers are networked with computers in other countries that have differing laws. In the United States, the possession of child pornography is a federal offense. One is liable under the law simply for possessing it and can be held accountable whether one deliberately downloaded the content or not.

SUMMARY
IDSs can serve many purposes in a defense-in-depth architecture.

In addition to identifying attacks and suspicious activity, you can use IDS data to identify security vulnerabilities and weaknesses.
IDSs can enforce security policy. For example, if your security policy prohibits the use of file-sharing applications such as KaZaA, Gnutella, or messaging services such as Internet Relay Chat (IRC) or Instant Messenger, you could configure your IDS to detect and report this breach of policy.
IDSs are an invaluable source of evidence. Logs from an IDS can become an important part of computer forensics and incident-handling efforts. Detection systems are used to detect insider attacks by monitoring outbound traffic from Trojans or tunneling and can be used as incident management tools to track an attack.
A NIDS can be used to record and correlate malicious network activities. The NIDS is stealthy and can be implemented to passively monitor or to react to an intrusion.

The HIDS plays a vital role in a defense-in-depth posture; it represents the last bastion of hope in an attack. If the attacker has bypassed all of the perimeter defenses, the HIDS might be the only thing preventing total compromise. The HIDS resides on the host machine and is responsible for packet inspection to and from that host only. It can monitor encrypted traffic at the host level, and is useful for correlating attacks that are detected by different network sensors. Used in this manner it can determine whether the attack was successful. The logs from an HIDS are a vital resource in reconstructing an attack or determining the severity of an incident.

Why Snort(“the Pig”)?

Snort is a NIDS that uses signature detection; it sniffs and examines network data packets for content that matches known attacks (and uses rules to check for errant packets in your network. A rule is a set of requirements that would trigger an alert.

For example, one snort rule to check for peer-to-peer file sharing services checks for the GET string not connecting to a service running on port 80. If a packet matches that rule, that packet creates an alert.

Once an alert is triggered, the alert can go a multitude of places, such as a log file, a database, or to an SNMP trap.).

Snort is not the only NIDS option available. Security is a hot topic, and there are many big-name manufacturers with IDS products on the market these days (ISS RealSecure and Cisco IDS are two examples). There are also a number of free, open-source IDS projects (e.g. Snort and the Prelude IDS for Linux and BSD operating systems). With all of these options, why pick Snort to monitor your network for intrusions?

Snort is an open source network intrusion detection system 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, SMB probes, OS fingerprinting attempts, and much more.

Snort is rapidly becoming the tool of choice for intrusion detection. There are three main modes in which Snort can be configured:

sniffer: Sniffer mode simply reads the packets off the network and displays them in a continuous stream on the console.
packet logger: Packet logger mode logs the packets to the disk.
network intrusion detection: Network intrusion detection mode is the most complex and configurable, allowing Snort to analyze network traffic for matches against a user-defined ruleset and to perform one of several actions, based on what it sees.
In addition to all of the basic Snort Features, you can set up Snort to send real-time alerts. This provides you with the ability to receive alerts in real time, rather than having to continuously monitor your Snort system.

Snort is like a vacuum that takes particular items (in this case, packets) and allows you to do different things. You can either

watch the items as they get sucked up (packet sniffer),
put the items into a container (packet logger), or
it can sort them and let you know when a particular item has gone through your NIDS.

In other words

Snort is configurable. All of Snort’s inner workings, configuration files, and rules are laid bare to you, so you can tune Snort to your specific network architecture. Not only that, but you can create your own rules for new attacks.
Snort is free. Snort is released under the GNU GPL, which means you can use it for free, no matter if you’re a company or just a curious hobbyist.
Snort is widely used. There are tens of thousands of downloads of Snort each month from the Snort Web site.
Snort runs on multiple platforms. Snort not only runs on all the major Unix and Unix-ish operating systems (including Linux), but also runs on Microsoft Windows.
Snort is constantly updated. Maintenance releases for Snort come out as needed, typically once every few months. The Snort rules are regularly updated with new attack signatures and can be downloaded from Snort Web site.

Snort might be considered a lightweight NIDS. A “lightweight” IDS is one that has a small footprint and can run on various operating systems. Additionally, Snort provides functionality only before found in commercial-grade network IDSs such as Network Flight Recorder (NFR) and ISS RealSecure.

When it comes to network intrusion detection systems, nothing gives you more bang for your buck than Snort.

Examples
Let’s take a brief look at Snort’s ability to detect the trilogy of intrusions we discuss before.

Directory Traversal Detection Using Snort

In IDS mode, Snort can be configured to send alerts when a network packet matches the rule stored in its configuration file. As our first example, an alert has been generated by Snort for a Directory Traversal exploit.

The first line displays the message “WEB-IIS cmd.exe access”.
The source and destination IP addresses are displayed in line fou
The last line of the alert provides a source of information concerning this exploit.

Figure right shows the accompanying log entry for this intrusion.

The first line displays the message “WEB-IIS cmd.exe access”
The second line displays the date, time, type, and length of the packet
The third line displays the source and destination IP addresses.
For this example, the box on the end of the sixth line contains the signature data that generated this alert. We recognize from previous discussion the Directory Traversal footprint Get /scripts/..%c1%c1../winnt/system32/cmd.exe?/c+dir.

CodeRed Detection Using Snort

In Figure here we see the Snort alert for CodeRed.

The first line displays the message“WEB-IIS ISAPI .ida attempt”
Line 2 classifies this attack as a Priority of 1.
The last line of the alert provides a source of information concerning this exploit.

Figure in right show the accompanying log entry for this intrusion.

The first line includes the message “WEB-IIS .ida attempt”. The signature for the CodeRed exploit can be seen in the box at the end of line six. The display is truncated and includes only a few of the necessary 254 N” characters. The “N” characters have no particular significance except to overflow the buffer. The CodeRed II exploit used the same overflow mechanism with two hundred fifty four “X” characters.

Nimda Detection Using Snort

Figure here shows the Snort alert for the Nimda worm. The alert contains the
pertinent information for this exploit, including source and destination IP addresses as well as a reference to the CERT Advisory CA-2001-26.

The Nimda worm produced a virtual cornucopia of signatures, each intended to perform a specific exploit. The Snort log display of Figure here shows only one, the “scripts/root.exe” signature. The file used for this signature was left behind by the CodeRed II worm and is the result of copying the Windows CMD.exe as root.exe. Snort has detected Nimda’s attempt to access this backdoor and has generated both an alert and a log entry.

Snort’s advantages far exceed its pitfalls.

Snort’s Story

Snort was originally intended to be a packet sniffer. In November 1998, Marty Roesch wrote a Linux-only packet sniffer called APE. Despite the great features of APE, Marty also wanted a sniffer that also does the following:

Works on multiple OSs
Uses a hexdump payload dump (TCPDump later had this functionality)
Displays all the different network packets the same way (TCPDump did not have this)

Marty ‘s goal was to write a better sniffer for his own use. He also wrote Snort as a libcap application, which gives Snort portability from a network filtering and sniffing standpoint. At the time, only TCPDump was also compiled with libcap, so this gave the system administrator another sniffer with which to work.

Snort became available at Packet Storm on 22 December 1998. At that time, Snort was only about 1600 lines of code and had a total of two files. This was about a month after Snort’s initial inception, and was only used for packet sniffing at this point. Marty’s first uses of Snort included monitoring his cable modem connection and for debugging network applications he coded.

The name Snort came from the fact that the application is a “sniffer and
more.” In addition, Martin said that he has too many programs called
a.out, and all the popular names for sniffers called TCP-something were
already taken.

Snort’s first signature-based analysis (also known as rules-based within the Snort community) became a feature in late January 1999. This was Snort’s initial foray down the path of intrusion detection, and Snort could be used as a lightweight IDS at the time. By the time Snort version 1.5 came out in December 1999, Martin had decided on the Snort architecture that is currently being used until version 2.0. After version 1.5 was released, Snort was able to use all the different plug-ins that are available today. However, Snort took a backseat to another IDS Marty was working on for a commercial IDS startup. That startup took a sharp nose dive and Marty found himself unemployed. Because of Snort’s increasing popularity, Marty thought that
it was time to work on Snort and make it easier to configure and get it working in an enterprise environment.

While working on Snort, Marty discovered that between coding and support, Snort was
becoming a full-time job. In addition, Marty knew that if he could make Snort work for the enterprise, people would invest money in Snort and support for it. Marty started Sourcefire from this idea. Sourcefire hired most of the core team who developed Snort. However, Snort is still open source and will always be open source. The latest main version(since 2003) of Snort is 2.x.x, which is a rework of the architecture and at 2003 contains approximately 75,000 lines of code. Although Sourcefire writes and supports Snort in a commercial release, there will be a GNU release of Snort available. Even though Snort 2.0 is a complete rewrite and an improvement over the current Snort implementation, Snort has gone though a more in-depth evolution. Snort did not start out with preprocessing ability, nor did it start out with plug-ins. Over time, Snort grew to have improved network flow, plug-ins for databases such as MySQL and Postgres, and preprocessor plug-ins that check RPC calls and port scanning before the packets are sent to the rules to check for alerts.

Warning---Snort keeps everyone on the latest version by supporting the latest rules only on the latest revision. E.g if the latest revision is 2.0.0, so the rules only work with those versions.

Speaking of rules, as time progressed, so did the number of rules. The size of the latest rules you download is increasing with the number of exploits available.
As a result, the rules became organized by type as they are now. The rule types
include

P2P,
backdoor,
distributed denial of service (DDoS) attacks,
Web attacks,
viruses,
... and many others.

These rules are mapped to a number that is recognized as a type of attack or exploit known as a Sensor ID (SID). For example, the SID for the SSH banner attack is 1838.

Because of Snort’s increasing popularity, other IDS vendors are adopting a Snort rule format. TCPDump adopted the hex encoding for packets, and community support is ever increasing.There are at least two mailing lists for Snort:

A discussion of Snort’s usage and application
Dedicated entirely to the Snort rules

Snort’s Components

In the process of designing Snort, the developers focused their energies on taking an existing tool and greatly expanding its abilities to make it something new (that's a common practice in OpenSource world); the existing tool was tcpdump, the ubiquitous packet capturer found on many Unix systems. Marty Roesch, Snort’s creator, took tcpdump’s ability to grab packets, and added the ability to analyze those packets against a set of attack signatures. Snort is an elegantly designed little beast, made up of several components that each perform a specific task. The figure below breaks Snort down.

Whenever a network packet hits an Ethernet wire that Snort is sniffing, it takes the following path:

Packet capture library. Illustrated as “Libpcap library” in Figure, the packet capture library is a separate piece of software that tosses Snort network packets from the network card. There are unprocessed Data-Link Layer (Layer 2 of the OSI model) packets, such as Ethernet frames. On Linux and Unix systems, Snort uses "libpcap". On Windows systems, Snort uses "WinPcap".
Packet decoder. The packet decoder takes the Layer 2 data sent over from the packet capture library and takes it apart. First it decodes the Data Link frame (such as Ethernet, TokenRing, or 802.11), then the IP protocol, then the TCP or UDP packet. When finished decoding, Snort has all the protocols information in all the right places for further processing.
Preprocessor. Snort’s preprocessor has several plug-ins that can be turned on or off. Preprocessing operates on the decoded packets, performing a variety of transformations making the data easier for Snort to digest. Preprocessors can alert on, classify, or drop a packet before sending it on to the more CPU-intensive detection engine.
Detection engine. The detection engine is the heart of Snort. It takes information from the packet decoder and preprocessors and operates on it at the transport and application layers (Layers 4 and 5 of the OSI model), comparing what’s in the packet to information in its rules-based detection plug-in. These rules contain signatures for attacks.
Output. When a preprocessor or rule is triggered, an alert is generated and logged (optionally along with the offending packet). Snort supports a variety of output plug-ins, including its own text-based and binary-based logging formats, a number of databases, and syslog.

The preprocessor, the detection engine, and the alert components of Snort are all plug-ins. Plug-ins are programs that are written to conform to Snort’s plug-in API. These programs used to be part of the core Snort code, but were separated out to make modifications to the core source code more reliable and easier to accomplish.

At the network layer (OSI model Layer 3) and above, Snort can only decode packets that are part of the TCP/IP protocol suite. This means it cannot decode packets or detect attacks that are carried out over other network protocols, such as Novell’s IPX/SPX or AppleTalk. For the most part, though, this is no big deal, as many network operating systems have already migrated to TCP/IP. And don’t worry about someone attacking you with IPX from the Internet — because they can’t!

Packet Sniffer
A packet sniffer is a device (either hardware or software) used to tap into networks. It works in a similar fashion that a telephone wiretap does, but it is used for data networks instead of voice networks.

A network sniffer allows an application or a hardware device to eavesdrop on data network traffic. In the case of the Internet, this usually consists of IP traffic, but it can be other traffic such as IPX and AppleTalk network protocols.

Because IP traffic consists of many different types of network traffic, including TCP, UDP, ICMP, routing protocols and IPSec, many sniffers analyze the various network protocols to interpret the packets into 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

Encrypting your network traffic can prevent people from being able to sniff your packets into something readable. Like any network tool, packet sniffers can be used for good and evil. As Marty said, he named the application because it does more than sniffing—it snorts. The sniffer needs to be set up to obtain as many packets as possible. As a sniffer, Snort can save the packets to be processed and viewed later as a packet logger. Figure below illustrates Snort’s packet sniffing ability.

Preprocessor

At this point, our coin sorter has obtained all the coins it can (packets from the network), and is ready to send the packets through the chute. Before rolling the coins (the detection engine), the coin sorter needs to determine if they are coins. This is done through the preprocessor. The preprocessor takes the raw packets and checks them against certain plug-ins (like an RPC plug-in and a port scanner plug-in). These plug-ins check for a certain type of behavior from the packet. Once the packet is determined to have a particular type of “behavior,” it is then sent to the detection engine. From Figure, you can see how the preprocessor uses its plug-ins to check a packet. This is such a great feature for an IDS because other plug-ins can be enabled and disabled as they are needed at the preprocessor level. For example, you can say you don’t care about RPC traffic coming into your network for whatever reason. You can disable this plug-in and use the others.

Detection Engine
The detection engine is the meat of the IDS in Snort. 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. Earlier, we described Snort as a signature-based IDS. The signature-based IDS function is accomplished by using various rulesets. The rulesets are grouped by category (Trojan horses, buffer overflows, access to various applications), and are updated regularly. The rules themselves consist of two parts:

The rule header: is basically the action to take (log or alert), type of network packet (TCP, UDP, ICMP, and so forth), 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 (and steepest learning curve) to learn and understand with 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 butter overflow rules.

Once you get it working and learn how to write Snort rules, you can finetune and customize Snort’s IDS functionality. You can define rules that are particular to your environment and customize however you want. The detection engine is the part of the coin sorter that actually rolls the coins based on the type. The most common American coins are the quarter, dime, nickel, and penny. However, you might get a coin that doesn’t match, like the Kennedy half-dollar, and discard it. This is illustrated in Figure

Alerting/Logging Component

After the Snort data goes through the detection engine, it needs to go out somewhere.
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 traps. The alerts can also be stored in an SQL database such as MySQL and Postgres.

Additionally, there are all sorts of additional tools you can use with Snort here. These include various plug-ins for Perl, PHP, and Web servers 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 as MySQL and Postgres. Like the detection engine and the preprocessor, the alert component uses plug-ins to send the alerts to databases and through networking protocols such as SNMP traps and WinPopup messages. See Figure for an illustration of how this works.
Additionally, with syslog tools such as Swatch, Snort alerts messages can be sent via e-mail to notify a system administrator in real time so no one has to monitor the Snort output all day and night.

Inner Workings (intermediate level)

Taking as an example a user on the desktop machine pc-1 (IP address: 10.1.1.1), the user opens his Web browser and types http://10.1.1.220, which starts a connection to the Linux server. Within the TCP/IP stack of pc-1, the request travels down the five layers of the TCP/IP model, encapsulating along the way. When the request reaches Layer 3 (network layer), the desktop machine requires a mechanism to discover the hardware address of the Linux machine’s network card (this is called the Media Access Control, or MAC, address). It does so using the Address Resolution Protocol (ARP).The desktop machine sends out an ARP request for the machine with the IP address 10.1.1.220, and the Linux machine will answer with its MAC address.

A MAC address is in the format 00:10:A4:A2:09:88, and is a unique
address burned into every network card. We can see the MAC address of
our network card by running the command ifconfig -a in Linux, and
ipconfig /all on Windows 2000.

Once the pc-1 machine has the MAC address of the Linux server (00:10:A4:A2:09:88), it will encapsulate the traffic into an Ethernet frame (Layer 2) and send the packet to the Linux machine. When the Linux server receives the packet, it will decode the packet through the different layers of the TCP/IP model. The Linux server will re-encapsulate its response back down the layers of the TCP/IP model, and the packets will travel back to the desktop machine. While the desktop machine pc-1 is communicating with the Linux server, the traffic is seen by all of the network cards connected to the hub. Each network card then examines the destination MAC address of the Ethernet frame (00:10:A4:A2:09:88), sees if it matches against its MAC address, and ignores it if it doesn’t.

Promiscuous Mode
The default behavior of a network card is to ignore traffic that is not destined for its particular MAC address. We need to change this behavior so that it doesn’t check the destination MAC address. By placing the network card in promiscuous mode, we have a mechanism for seeing all of the traffic as it’s placed on the hub. Referring back to our previous example, the Snort server has a network card in promiscuous mode. When the packet from the desktop machine pc-1 to the Linux server (or for that matter, any packet on the network) is seen by our machine running Snort, the network card will make that packet available at the data link layer. Snort then needs a mechanism to get packets from the network card at the data link layer and into its packet decoder. Snort does this using the libpcap library.

libpcap Library
The libpcap library was written as part of a larger program called TCPDump. The libpcap library allowed developers to write code to receive link-layer packets (Layer 2 in the OSI model) on different flavors of UNIX operating systems without having to worry about the idiosyncrasy of different operating systems’ network cards and drivers. Essentially, the libpcap library grabs packets directly from the network cards, which allowed developers to write programs to decode, display, or log the packets. The TCPDump program did just that. A cross-platform sniffer, originally written by Van Jacobson, Craig Leres, and Steven McCanne at Lawrence Berkeley Labs to analyze TCP performance problems, TCPDump allowed you to capture packets and then decode and display them. One day, frustrated with the limitations and output formats of TCPDump, Marty Roesch wrote Snort as a replacement to TCPDump. The original version of Snort did not have preprocessors or fancy plug-ins; it was simply a better TCPDump. Pieces of TCPDump have been borrowed by Snort.

How Does Snort Link into libpcap?
Looking inside the snort.c source code, when Snort starts up it checks a number of settings and configurations. It calls the libpcap library, which, among other things, checks the interface and puts it into promiscuous mode.

When Snort calls the libpcap functions and initializes the interfaces, it enters what is called the primary execution loop, or pcap_loop. In this endless loop, the pcap function waits until it has received packets from the network card device driver, and then calls the ProcessPacket() function. The ProcessPacket() function links into Data-Link layer decode routine decode.c.

So, why use libpcap? libpcap is a cross-platform library that works on all major UNIX systems and Windows, so there’s no need to reinvent the wheel for decoding and packet capture. Writing your own sniffer is straightforward, and information on libpcap and writing libpcap code can be found here. Snort is only one of many programs that use the libpcap library and components of TCPDump; a full list is here. One of our personal favorites (besides Snort, of course) is Ethereal (now Wireshark).

Wireshark is an excellent GUI-based open-source packet sniffer with a massive decode plug-in set that can decode over 335 different network protocols. It also reads pcap formatted log files, so looking through large outputs from Snort or TCPDump is easy.

The original TCPDump and libpcap versions were UNIX only. However, a research and development group in Italy have put together a Windows version of libpcap called winpcap. Like the UNIX libpcap, winpcap is used by a number of Windows-based sniffer programs, including Snort and Ethereal. The libpcap libraries are a separate entity to Snort.

Decoding Packets

Now that the packets have arrived from the network card and have been passed to the Snort decode engine by the libpcap library, Snort needs to decode the raw Data-Link layer packets (Layer 2 of the OSI model). Snort can recognize different protocols, including Ethernet, 802.11,Token Ring, and other higher layer protocols such as IP,TCP, and UDP. During the decode process, Snort links the raw data to structures for later analysis by the preprocessors and detection engine.
Referring back to the network example in Figure, the desktop machine pc-1 connects to the Linux server via a Web browser, and the following actions occur.

When Snort starts up, the network card is placed into promiscuous mode by the libpcap library.
As the packet travels on the hub, from pc-1 to the Linux server, the network card gets the packet and copies it to the network driver. The libpcap library enabled by Snort is in an endless loop watching for packets.
When it receives the packets from the network card driver, it then runs the ProcessPacket() function (in the decode.c source code).
The ProcessPacket function calls the DecodeEthPkt function, which decodes the Ethernet frame.
From within the DecodeEthPkt function, the DecodeIP function decodes the IP protocol.
Finally, the DecodeTCPPkt function is called, which decodes the TCP packet. So, we have decoded the TCP packet and linked it to the appropriate data structures, and are now ready for detection.

NOTE---Snort supports a number of protocols, but some are simply recognized
and nothing is done to them. An example of this is IPX. Snort recognizes
IPX, but does not decode it above Layer 2—Snort only uses it for statistics.

Storage of Packets
As we move through the Snort functions, you might be asking,“Where does Snort store the actual packets?” The answer is in pointers and data structures held in memory. If you look at the code in decode.h, you will see data structures that define all of the protocols used by Snort; for example,TCP, IP, and Ethernet. Snort overlays these structures onto the raw packets using pointers that represent the protocol. For example, the pointer to the raw data that comes from libpcap as an Ethernet frame is the _EthrHdr header. In the case of higher-level protocols such as TCP, it will overlay further data structures onto them. The following example shows the Ethernet and the TCP header structures.

/*

* Ethernet header

*/

typedef struct _EtherHdr

{

u_int8_t ether_dst[6];

u_int8_t ether_src[6];

u_int16_t ether_type;

}

typedef struct _TCPHdr

{

u_int16_t th_sport; /* source port */

u_int16_t th_dport; /* destination port */

u_int32_t th_seq; /* sequence number */

u_int32_t th_ack; /* acknowledgement number */

u_int8_t th_offx2; /* offset and reserved */

u_int8_t th_flags; /* flags */

u_int16_t th_win; /* window */

u_int16_t th_sum; /* checksum */

u_int16_t th_urp; /* urgent pointer */

}

The core of all of these structures is _Packet. From within _Packet, all of the

Snort data structures are created and built as shown in the following _Packet

structure:

typedef struct _Packet

{

struct pcap_pkthdr *pkth; /* BPF data */

u_int8_t *pkt; /* base pointer to the raw packet data */

EtherHdr *eh; /* standard TCP/IP/Ethernet/ARP headers */

VlanTagHdr *vh;

WifiHdr *wifih; /* wireless LAN header */

EtherARP *ah;

IPHdr *iph, *orig_iph; /* and orig. headers for ICMP_*_UNREACH family */

u_int32_t ip_options_len;

u_int8_t *ip_options_data;

TCPHdr *tcph, *orig_tcph;

u_int32_t tcp_options_len;

u_int8_t *tcp_options_data;

UDPHdr *udph, *orig_udph;…

Processing Packets 101
Now that we have obtained some data packets and decoded them into the different
protocols, what is the next step in processing? There are three phases to this next step:

Preprocessors
Detect engines and plug-ins
Output plug-ins

Preprocessors
Before the packets are sent to the detection engine, they are first sent to the preprocessors. The preprocessor concept originated in Snort v1.5. The main idea behind the introduction of preprocessors was to provide a framework to allow for

alerting,
dropping,
and modification of the packets

before they reached Snort’s main detection engine.

Referring back to Figure, the desktop machine pc-2 decides to connect to the Windows 2000 Web server. The user opens the browser and enters the following:
http://10.1.1.251/%73%63%72%69%70%74%73/%68%61%63%6B%6D%65.%65%78%65

The HTTP protocol specifies that binary characters can be passed within the
Universal Resource Identifier (URI) by using %xx notation, where xx is the hex value of the character.

When the URI arrives at the Web server, it converts it to http://10.1.1.251/scripts/hackme.exe. Within Snort, the pattern matcher is looking for a pattern of /scripts/hackme.exe, but we have effectively mangled the URI so it does not trigger an alert.

The _decode Family of Preprocessors
One task of the preprocessor is to normalize packets before sending them to the detection engine. In the case of our HTTP request, the http_decode preprocessor
changes the URI before it reaches the detection engine. We can still write signatures
as we normally do; the preprocessor normalizes them into a standard format.

An excellent white paper on the IDS evasion of Web attacks can be found at www.wiretrip.net/rfp/pages/whitepapers/whiskerids.html. The author, Rain Forest Puppy, was one of the key developers of the http_decode preprocessor

The telnet_decode, ftp_decode, and rpc_decode preprocessors follow the same lines
as http_decode. However, instead of normalizing URIs, these preprocessors normalize
Telnet, FTP, and RPC traffic before it is sent to the detection engine.

The frag2(now frag3) Preprocessor
Let’s take this concept one step further. What if we fragmented the packets?
Fragmentation is a necessary function of the TCP/IP suite, as different routers on the Internet (or internally) have different sized network links. Fragmentation dissects the packets into smaller pieces so that they can fit the smaller links as they travel the network. However, as helpful as fragmentation is, fragmenting packets can also be an extremely effective way of bypassing pattern-based IDSs. One of the most famous tools for doing this is fragrouter.

The existence of fragmented packets is normal on a network, especially if it’s connected to the Internet. However, a large number of fragmented packets on a network would be classified as suspicious. You can block fragmented packets on most modern firewalls or routers, but in doing so, you might block access to systems for certain users who are traveling over a number of router hops or small links. It’s definitely a trade-off between security and usability that needs careful review.

The fragrouter program takes network traffic and fragments it into small pieces before putting it onto the network, thus effectively evading pattern matching systems. The pattern-based IDSs would only see portions of the packets as they travel across the network. At the far side, the TCP/IP stack on the Web server would reassemble the packets and interpret the results. One downside of fragmentation is that it can be used as an effective denial-of-service (DoS) attack. If your fragmented packets are exceptionally small, the Web server is using valuable system resources to reassemble them, thus clogging up the bandwidth available to your network. An IDS also has to reassemble the fragmented packets, which also requires a significant amount of memory and resources. Thus, if traffic volume is high enough and many fragmented packets are on the network, the IDS might be too busy reassembling fragmented packets to notice an attack on the Web server. Moreover, if the IDS is under load just watching normal traffic, it might miss a single packet that would make the signature invalid.

This brings us to the frag2 preprocessor. Using the frag2 preprocessor, fragmented packets are reassembled before they get to the detection engine, so signatures can be applied to the full sessions, not just the individual small packets. The frag2 preprocessor will also write alerts when fragmentation thresholds are reached. Finally, what if we could trigger thousands of false-positives, thereby overloading the IDS, and as in a fragmentation attack make the IDS blind due to lack of resources? The stick program was released with this in mind. stick takes all of the signatures files in Snort and generates packets that trigger alerts on the IDS. In our previous HTTP example, stick would generate a packet that contained the “/scripts/hackme.exe” string on the HTTP port and then place it on the network. The IDS would see the traffic containing the pattern and alert.

The stream4 (now stream5) Preprocessor
The stream4 preprocessor was designed to make Snort stateful. At over 2000 lines of code, and able to handle up to 64,0000 connections, stream4 is one of the largest components of Snort. By making Snort stateful, it can avoid the problems created by stick and provide better signature-matching capabilities. In addition, as a by product, the stateful properties allow Snort to detect operating system fingerprinting techniques and scans using out of state packets, typically used by the NMAP program.

When a TCP connection (Layer 3 of the TCP/IP) from a client to a server is made, a number of events take place.

An initial conversation is carried out; this is known as the three-way handshake.
Once the connection is set-up, data is transferred.
When the data has been transferred, the conversation ends.

Using the stream4 preprocessor, during these conversations Snort builds internal tables to represent these sessions and tears them down after each session ends. By making Snort capable of keeping its own state table, it becomes aware of a full session, not just individual SYN,ACK, and FIN flags to a particular server. This is important when we try to apply signatures, as in the example of a user opening a connection to a Web server. In this case, Snort monitors the conversation between the client (the user’s browser) and the server (Web server), and will build internal tables for each session. When the detection engine matches a packet, it checks to see if it is part of an established session, rather than blindly matching packets against signatures (which the stick program exploited). Snort is now capable of only alerting on matched signatures to established sessions.

Another advantage of Snort being stateful is that out-of-sequence scanning techniques can also be detected (for example, a stealth FIN scan, a popular scanning method using Nmap). According to the TCP protocol, FIN packets are only seen during the closing sequence of a connection (see Figure). If a FIN packet is sent to a closed TCP port, the server should send back an RST packet to the other side. The stream4 preprocessor will alert on the event of a FIN packet sent for a session that was never established.

In the following output from the stream4 preprocessor, the final line shows the SF (SYN FIN) flag set on the packet.

[**] [111:13:1] (spp_stream4) STEALTH ACTIVITY (SYN FIN scan) detection[**]
07/09-19:49:16.000000 10.1.1.236:1034 -> 10.1.1.220:6000
TCP TTL:255 TOS:0x0 ID:31377 IpLen:20 DgmLen:40
******SF Seq: 0xFFFFFFFF Ack: 0x0 Win: 0x1000 TcpLen: 20

The portscan Family of Preprocessors
An important part of an IDS is the ability to detect portscans. Portscans are a regular
occurrence on any network connected to the Internet, and are used by potential intruders to identify servers and the ports that are open. Once the attacker discovers which ports are open, he attempts to exploit the services provided on those ports. Referring above to Figure, a typical TCP portscan works

by sending a initial SYN to a server.
The server replies with a SYN/ACK if the port is open, and a SYN/RST if the port is not listening.

By sending SYNs to multiple ports and watching for the return SYN-ACK, we can map which ports are open on a server. Snort detects portscans through the use of preprocessors. The 2.0.0 version of Snort, has two portscan preprocessors available. There are some differences in the way in which each preprocessor works:

portscan preprocessor : The portscan preprocessor is watching for a single machine (client) connecting to multiple ports on a single server over a period of time. It also detects UDP portscans the same way and Stealth scans (see the section Stealth Portscanning)
portscan2 preprocessor :The portscan2 preprocessor is effectively the bigger brother of portscan. It has the same functionality as the original portscan preprocessor, but is now a complete rewrite of code. At its core it uses the conversation plug-in, similar to stream4, which tracks connection states. Therefore, portscan2 can determine if a SYN-ACK (see Figure) is part of a legitimate current connection or an actual scan. portscan2 also has a new output format that provides more information on the portscan, and supports separate thresholds for ports and machines hit in a given time. Going forward, the portscan2 preprocessor will be the standard portscan detector for Snort.

The limitation in portscan detectors is, of course, the concept of “slow scans.” If you scan a machine over the course of a week—say, one port per hour—it won’t trigger the portscan detectors, as they would have to store details on every connection made throughout the day. On a busy or large network, it’s a daunting task.

So, which preprocessor should you run? The portscan preprocessor is a simple and stable portscan detector. The portscan2 preprocessor is new, but does have some additional tuning options, thresholds, and better stealth scan detection. If your Snort server has the system resources in terms of memory and CPU processing power, run both over a period of time to see which gives the best results. In addition, you might run a few portscans yourself and see the results (with permission from your system administrator, of course).

The default configuration of both portscan preprocessors will always throw up false positives; the usual suspects are DNS servers and Web proxy servers. The portscan preprocessors can be configured to ignore traffic from certain hosts, and in the case of portscan2, certain ports to and from a server.

Stealth Portscanning

Nowadays, the “bad guys” are trying to be stealthy in their port scanning attempts. Within the TCP header are flags that denote the state of the packet. These
flags can be URG, ACK, PSH, RST, SYN, and FIN, and represent different states of the session (see Figure of stealth FIN scan). By mixing up the TCP flags, the attacker is hoping to elicit a response from the server to allow him to map open services. More importantly, however, the attacker is trying to avoid detection by portscan detection programs. A number of scans rely on setting different TCP flags; for example:

Full XMAS scan Sets the TCP flags to FIN, URG, PSH. The target server should send back an RST on all closed ports.
TCP FIN scan Sets the TCP flag to be FIN. As with the XMAS scan, the target should send back an RST.
NULL scan Sets the TCP flag to have no options. Again, the targetshould send back an RST.

TCP Flag Options

Introduction

Some TCP segments carry data while others are simple acknowledgements for previously received data. The popular 3-way handshake utilises the SYNs and ACKs available in the TCP to help complete the connection before data is transferred.

Our conclusion is that each TCP segment has a purpose, and this is determined with the help of the TCP flag options, allowing the sender or receiver to specify which flags should be used so the segment is handled correctly by the other end.

Let's take a look at the TCP flags field to begin our analysis:

You can see the 2 flags that are used during the 3-way handshake (SYN, ACK) and data transfers.

As with all flags, a value of '1' means that a particular flag is 'set' or, if you like, is 'on'. In this example, only the "SYN" flag is set, indicating that this is the first segment of a new TCP connection.

In addition to this, each flag is one bit long, and since there are 6 flags, this makes the Flags section 6 bits in total.

You would have to agree that the most popular flags are the "SYN", "ACK" and "FIN", used to establish connections, acknowledge successful segment transfers and, lastly, terminate connections. While the rest of the flags are not as well known, their role and purpose makes them, in some cases, equally important.

We will begin our analysis by examining all six flags, starting from the top, that is, the Urgent Pointer:

1st Flag - Urgent Pointer

The first flag is the Urgent Pointer flag, as shown in the previous screen shot. This flag is used to identify incoming data as 'urgent'. Such incoming segments do not have to wait until the previous segments are consumed by the receiving end but are sent directly and processed immediately.

An Urgent Pointer could be used during a stream of data transfer where a host is sending data to an application running on a remote machine. If a problem appears, the host machine needs to abort the data transfer and stop the data processing on the other end. Under normal circumstances, the abort signal will be sent and queued at the remote machine until all previously sent data is processed, however, in this case, we need the abort signal to be processed immediately.

By setting the abort signal's segment Urgent Pointer flag to '1', the remote machine will not wait till all queued data is processed and then execute the abort. Instead, it will give that specific segment priority, processing it immediately and stopping all further data processing. If you're finding it hard to understand, consider this real-life example:

At your local post office, hundreds of trucks are unloading bags of letters from all over the world. Because the amount of trucks entering the post office building are abundant, they line up one behind the other, waiting for their turn to unload their bags. As a result, the queue ends up being quite long. However, a truck with a big red flag suddenly joins the queue and the security officer, whose job it is to make sure no truck skips the queue, sees the red flag and knows it's carrying very important letters that need to get to their destination urgently. By following the normal procedures, the security officer signals to the truck to skip the queue and go all the way up to the front, giving it priority over the other the trucks. In this example, the trucks represent the segments that arrive at their destination and are queued in the buffer waiting to be processed, while the truck with the red flag is the segment with the Urgent Pointer flag set.

A further point to note is the existence of the Urgent Pointer field. This field is covered in section 5, but we can briefly mention that when the Urgent Pointer flag is set to '1' (that's the one we are analysing here), then the Urgent Pointer field specifies the position in the segment where urgent data ends.

2nd Flag - ACKnowledgement

The ACKnowledgement flag is used to acknowledge the successful receipt of packets.

If you run a packet sniffer while transferring data using the TCP, you will notice that, in most cases, for every packet you send or receive, an ACKnowledgement follows. So if you received a packet from a remote host, then your workstation will most probably send one back with the ACK field set to "1".

In some cases where the sender requires one ACKnowledgement for every 3 packets sent, the receiving end will send the ACK expected once (the 3rd sequential packet is received). This is also called Windowing and is covered extensively in the pages that follow.

3rd Flag - PUSH

The Push flag, like the Urgent flag, exists to ensure that the data is given the priority (that it deserves) and is processed at the sending or receiving end. This particular flag is used quite frequently at the beginning and end of a data transfer, affecting the way the data is handled at both ends.

When developers create new applications, they must make sure they follow specific guidelines given by the RFC's to ensure that their applications work properly and manage the flow of data in and out of the application layer of the OSI model flawlessly. When used, the Push bit makes sure the data segment is handled correctly and given the appropriate priority at both ends of a virtual connection.

When a host sends its data, it is temporarily queued in the TCP buffer, a special area in the memory, until the segment has reached a certain size and is then sent to the receiver. This design guarantees that the data transfer is as efficient as possible, without waisting time and bandwidth by creating multiple segments, but combining them into one or more larger ones.

When the segment arrives at the receiving end, it is placed in the TCP incoming buffer before it is passed onto the application layer. The data queued in the incoming buffer will remain there until the other segments arrive and, once this is complete, the data is passed to the application layer that's waiting for it.

While this procedure works well in most cases, there are a lot of instances where this 'queueing' of data is undesirable because any delay during queuing can cause problems to the waiting application. A simple example would be a TCP stream, e.g real player, where data must be sent and processed (by the receiver) immediately to ensure a smooth stream without any cut offs.

A final point to mention here is that the Push flag is usually set on the last segment of a file to prevent buffer deadlocks. It is also seen when used to send HTTP or other types of requests through a proxy - ensuring the request is handled appropriately and effectively.

4th Flag - Reset (RST) Flag

The reset flag is used when a segment arrives that is not intended for the current connection. In other words, if you were to send a packet to a host in order to establish a connection, and there was no such service waiting to answer at the remote host, then the host would automatically reject your request and then send you a reply with the RST flag set. This indicates that the remote host has reset the connection.

While this might prove very simple and logical, the truth is that in most cases this 'feature' is used by most hackers in order to scan hosts for 'open' ports. All modern port scanners are able to detect 'open' or 'listening' ports thanks to the 'reset' function.

The method used to detect these ports is very simple: When attempting to scan a remote host, a valid TCP segment is constructed with the SYN flag set (1) and sent to the target host. If there is no service listening for incoming connections on the specific port, then the remote host will reply with ACK and RST flag set (1). If, on the other hand, there is a service listening on the port, the remote host will construct a TCP segment with the ACK flag set (1). This is, of course, part of the standard 3-way handshake we have covered.

Once the host scanning for open ports receives this segment, it will complete the 3-way handshake and then terminate it using the FIN (see below) flag, and mark the specific port as "active".

5th Flag - SYNchronisation Flag

The fifth flag contained in the TCP Flag options is perhaps the most well know flag used in TCP communications. As you might be aware, the SYN flag is initialy sent when establishing the classical 3-way handshake between two hosts:

In the above diagram, Host A needs to download data from Host B using TCP as its transport protocol. The protocol requires the 3-way handshake to take place so a virtual connection can be established by both ends in order to exchange data.

During the 3-way handshake we are able to count a total of 2 SYN flags transmitted, one by each host. As files are exchanged and new connections created, we will see more SYN flags being sent and received.

6th Flag - FIN Flag

The final flag available is the FIN flag, standing for the word FINished. This flag is used to tear down the virtual connections created using the previous flag (SYN), so because of this reason, the FIN flag always appears when the last packets are exchanged between a connection.

It is important to note that when a host sends a FIN flag to close a connection, it may continue to receive data until the remote host has also closed the connection, although this occurs only under certain circumstances. Once the connection is teared down by both sides, the buffers set aside on each end for the connection are released.

A normal teardown procedure is depicted below:

The above diagram represents an existing connection betwen Host A and B, where the two hosts are exchanging data. Once the data transfer is complete, Host A sends a packet with the FIN, ACK flags set (STEP 1).

With this packet, Host A is ACKnowledging the previous stream while at the same time initiating the TCP close procedure to kill this connection. At this point, Host A's application will stop receiving any data and will close the connection from this side.

In response to Host A's request to close the connection, Host B will send an ACKnowledgement (STEP 2) back, and also notify its application that the connection is no longer available. Once this is complete, the host (B) will send its own FIN, ACK flags (STEP 3) to close their part of the connection.

If you're wondering why this procedure is required, then you may need to recall that TCP is a Full Duplex connection, meaning that there are two directions of data flow. In our example this is the connection flow from Host A to Host B and vice versa. In addition, it requires both hosts to close the connection from their side, hence the reason behind the fact that both hosts must send a FIN flag and the other host must ACKnowledge it.

Lastly, at Step 4, Host A willl acknowledge the request Host B sent at STEP 3 and the closedown procedure for both sides is now complete!

Summary

Perhaps the most important information given on this page that is beneficial to remember is the TCP handshake procedure and the fact that TCP is a Full Duplex connection (for more details see here).

portscan Output
The portscan and portscan2 preprocessors both send alerts using the standard Snort output alerting mechanism (see the section Output and Logs later). However, they do have their own in-built logging system that’s separate from the main Snort output plug-ins. The logging system is configured in snort.conf under the relevant portscan or portscan2 preprocessor section. The following alerts are generated from portscan and portscan2, and would be sent to the Snort output facility:

[**] [100:1:1] spp_portscan: PORTSCAN DETECTED to port 1 from 192.168.1.53
(STEALTH)
[**] [117:1:1] (spp_portscan2) Portscan detected from 192.168.1.53: 6
targets 14 ports in 11 seconds

The following are sample contents of portscan.log and scan.log:

Portscan.log Sample data is from a Full XMAS scan.

Oct 6 20:35:47 192.168.1.53:52645 -> 192.168.1.1:40936 XMAS
**U*P**F

Scan.log A full XMAS scan, but contains more data than portscan.log does.

10/06-20:35:47.000000 TCP src: 192.168.1.53 dst: 192.168.1.1
sport: 52645 dport: 40936 tgts: 3 ports: 59 flags: **U*P**F
event_id: 1298

Because the portscan preprocessors only send alerts to Snort, if you are
configuring Snort to “Log to Database,” none of the events will be
written. No logs will be written either, as the preprocessors will be using their own log format.

Other Preprocessors

A number of other preprocessors ship with Snort version 2.0.0. Some of these are in the experimental stage of development.Table below lists the preprocessors that are available and a brief description of their functionality.

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

Rules 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. On startup, Snort reads all of the rules files, and creates a three-dimensional (3D) linked list. Snort then uses this list to match packets against for detecting. The importing and reading of these files is done by the ParseRulesFile() function in the parser.c source code referenced from the main snort.c source code. The building of the linked list is initiated from the main snort.c source code.

On startup, Snort reads the snort.conf configuration file, and at the section “Step 4—Customize your rule set,” links to each of the specified rules files. Contained in each of the rules files are the Snort rules that are parsed and the linked list created. Step 4 of snort.conf:

####################################################################
# Step #4: Customize your rule set
#
.
include $RULE_PATH/bad-traffic.rules
include $RULE_PATH/exploit.rules
include $RULE_PATH/scan.rules
include $RULE_PATH/finger.rules
include $RULE_PATH/ftp.rules
include $RULE_PATH/telnet.rules
include $RULE_PATH/rpc.rules
...

Rule Format
Before talking about how the linked list is created, let’s look at a simple sample Snort FTP rule. 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_NET 21

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,287;
classtype:attempted-admin; sid:344; rev4;)

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 include 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 include 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.

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 dimension of 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 established 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 (see the section How a Packet Is Matched )
Reference This keyword allows you to include 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 can be checked here . 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 (Updating the Snort rule descriptions is a community effort. A number of signatures do not have descriptions, so if you have some spare time, pick a signature and write a description), the rules go through a revision process. Over time, this process allows the rules to be fine-tuned and to avoid false-positives.

What Is a 3D Linked List?

While we are processing the rules files, we need a way to store them for matching against the incoming packets. Snort uses a 3D linked list (see Figure). In software development terms, a linked list is an algorithm for storing a list of items; in our case, the Snort rules and their options. Snort stores rules and their options in the linked list and then searches the list for a rule header match. Then, within the header match, it searches for a pattern match or a match using a detection plug-in.

Components of the Snort Rule Tree
There are five separate chains of rules. These chains are the list headings at the top of Figure.

Activation Alert and then turn on another dynamic rule.
Dynamic Log the traffic when called by the above activation rule.
Alert Generate an alert and then log the packet.
Pass Ignore this packet.
Log Log the traffic (don’t alert).

For each of the five chains of rules, there are separate linked lists, broken down by protocol. This level of the tree is referred to as the Rule Tree Nodes (RTN). The four protocols supported by the Rule Tree are:

TCP TCP protocol; for example, SMTP, HTTP, FTP
UDP UDP protocol; for example, DNS lookups
ICMP ICMP protocol; for example, ping, traceroute
IP IP protocol; for example, IPSec, IGMP

Within each of the protocol linked lists are the Rule options, which are referred to as the Option Tree Nodes (OTN). An example of these options would be:

Content Content checked by the Boyer-Moore pattern matching algorithm
Flow Link to detection plug-in

On initialization, Snort reads the rule files and populates the linked lists.
Figure above shows a populated OptionTreeNode for the TCP RuleTreeNode off the Alert chain.

How a Packet Is Matched
Once we have built our linked lists, we need a method to navigate the list to look for a match to the packets. The following Snort HTTP rule is present in the middle-right portion of the following output.

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS
(msg:"WEB_IIS..\.. acess";flow:to_server,established; content:
"|2e2e5c2e2e|"; reference: bugtraq,2218; reference:cve, CAN-199-0299;
classtype:web-application-attack; sid:974; rev:6;)

When the packet arrives at the detection engine, Snort will navigate through the rule headers in the following order: Activation--> Dynamic--> Alert--> Pass--> Log. Within each of the rule headers, the RTNs and the OTNs will be checked. In our example, the action is alert; therefore, the first two nodes Activation and Dynamic have been checked but no matches returned. Snort then moves to the Alert chain.The search method is dependent on the protocol of the packet (in our example,TCP), so we start on the TCP node list. Traveling along the RTNs from left to right, it tries to match the packet by the following parameters:

Source IP address
Destination IP address
Source port
Destination port

When Snort finds a match, the algorithm moves down the columns looking for a match inside each of the OTNs. There might be a number of HTTP rules, so Snort checks the options of each. When we get to our HTTP exploit, Snort will do the following:

Within our particular option node are two items:

A pointer to a detection plug-in, which is the third dimension of the linked list, the first two being the RTN and OTNs. The flow plug-in checks to see if the packet matches an established session.
A pattern we want to search for using the Boyer-Moore Fast String Searching Algorithm.

NOTE---There are more than 35 individual options you can have in the Options part of a rule (OTN). As long as the rule doesn’t exceed 8k, you could use them all, but we are keeping our example simple.

One of the most efficient string pattern-matching algorithms is the Boyer- Moore Fast String Searching Algorithm. This searching algorithm is extremely efficient at matching patterns in a string. When a rule contains a content: option, the algorithm is used to search the contents. The contents can be in a number of formats, binary or text, or a mixture of the two; in our HTTP-based example, it’s in binary “|2e2e5c2e2e|”.

Now that we have found a match, we exit the tree structure and return to the Alert tree head. We alert via the output format (see the section Output and Logs) specified and then exit. Snort uses a fast exit strategy; once it matches a packet, it doesn’t check it against any other rules.

Snort version 2.0 gives users the ability to choose from three completely different pattern-matching algorithms depending on their use of Snort:
Aho-Corasick
Wu-Manber and
Boyer-Moore search algorithms.
Further information can be found in the “High Performance Multi-Rule Inspection Engine” white paper.

Pass Rules
Sometimes you want to ignore traffic from a particular server. There are two options for this:

Use BPF filter language on Snort startup (see later section “Using Snort as a quick sniffer”)
Use a Pass Rule (pass rules can be set up to ignore particular traffic)

If we want to ignore the traffic from a particular server for a particular signature, we can use the Pass rule; see the changes we made to the previous HTTP exploit rule. The pass rule will ignore any traffic that matches the following signature:

pass tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS
(flow:to_server,established; content "|2e2e5c2e2e|";)

To enable the Pass rule, you have to change the mechanism Snort uses to process rules (Activation, Dynamic, Alert, Pass, Log). This is done with the –o command-line switch, which changes it to (Pass, Activation, Dynamic, Alert, Log). Be careful when using this switch, because it is possible to set up a Pass rule that will pass all traffic and alert on nothing.

Log Rules
The log option is for logging of all packets that match a rule. The log option does not alert; it just logs to the defined output format (see the section Output and Logs). The log option doesn’t work when enabled with Snort in binary mode.

log tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS
(flow:to_server,established; content"|2e2e5c2e2e|";)

Dynamic and Activation rules
The dynamic and activation rules allow you to alert on a packet, similar to the alert option, but then log a number of packets after it. In our next example, we are alerting to the output facility when the packet matches, and then we are linking to the dynamic rule, which logs the next 128 packets coming from $EXTERNAL_NET on any port going to the $HTTP_SERVERS on the $HTTP_PORTS.



activate tcp $EXTERNAL_NET any-> $HTTP_SERVERS $HTTP_PORTS (msg:"WEBIIS..\..
access"flow:to_server,established: activates: 1;
content"|2e2e5c2e2f|"; reference:bugtraq,2218;reference:cve,CAN-199-0229;
classtype:web-application-attack; sid:974;rev6;)
dynamic tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_SEVERS $HTTP_PORTS
(activated_by: 1; count 128;)

The activate and dynamic options are being phased out by a new tagging option available as the tag keyword.

Detection Plug-Ins
Snort has a plug-in architecture for the detection engine; the version 2.0.0 of Snort has 22 built-in detection plug-ins. The files are contained in the detection-plug-ins subdirectory from the main SRC directory. The detection plug-in architecture allows other developers to write plug-ins that link into the Snort rules. An example of a third-party detection plug-in is the snortsam program(or fwsnort on Ubuntu repos). This program provides a link between detecting an exploit (our FTP exploit) and the ability to reconfigure your firewall to block the source IP address. If we take our original FTP rule and modify it for snortsam, the rule would look like the following:

alert tcp $EXTERNAL_NET any -> $HOME_NET 21
(msg:"FTP EXPLOIT wu-ftpd 2.6.0 site exec format string overflow Linus";
flow:to_server,established; content: "|31c031db31c9b046cd80 31c031db|";
reference:bugtraq,1387; reference:cve,CAN-2000-0573;
reference:arachnids,287; classtype:attempted-admin; sid:344; rev:4; fwsam:
src, 1 hour;)

The extra option is fwsam: src, 1 hour;, which translates into “block the source IP address of the attack for 1 hour.”

Snort also has the capability to tear down TCP connections and send “ICMP destination unreachable” for UDP connections using the REACT keyword.

Snort 2.0 Rule Design
A number of white papers on the design features of Snort 2.0 are available here.
Of particular interest are the following papers:

Snort 2.0—“Detection Revisited”
Snort 2.0—“Multi-Rule Inspection Engine”
Snort 2.0—“Rule Optimizer”
Snort 2.0—“Protocol Flow Analyzer”

Output and Logs
Now that we have, sniffed, decoded, and detected events, we need a mechanism to write or display them in a meaningful fashion. This is where the output plugins become necessary. The output plug-ins differ from the other components of Snort, as there is no single entry point into the output plug-ins. Different components use the output plug-ins at different stages.

The packet decode engine will use the output plug-ins; for example,output to TCPDump format or ASCII decode format.

The preprocessor will use the output plug-ins to alert on events, but some have their own output format; for example, the portscan2 preprocessor.

The detection engine will use the output plug-ins to alert and log. Output modules are similar to the Snort preprocessors in that they allow Snort to be more flexible about how it presents its alerts and logs.

The output stage will be moving to a separate process (see the section Barnyard and Unified Output later). The main reason for this is that while monitoring high-speed networks, you don’t want to have to wait for an output plug-in to write its alerts to a database.

The logging engine code mostly resides in the log.c file. Output plug-ins are defined in the output-plugins directory; the plug-ins start with the extension spo_. Deciding on the strategies for output is dependent on how you want to use Snort. There are multiple options you can use, including:

Snort as a quick sniffer Using Snort as a quick sniffer to troubleshoot network issues.
Intrusion detection mode Enabling Snort for intrusion detection.
Snort for honeypot capture and analysis Using Snort’s capability for packet capture and intrusion detection.
Logging to databases Logging of alerts to an Enterprise
Alerting using SNMP Integrating Snort into your network monitoring station (NMS) using the Simple Network Management Protocol (SNMP).
Barnyard and unified output Separate program to process alerts and logs, created by Snort in unified mode output.

Snort can also do combinations of the preceding options; for example, writing to a database and alerting using SNMP to your NMS. You can also defined custom outputs for individual rules; for example, on a particular HTTP exploit alert to the NMS, all others log to a database. Multiple output plug-ins can be defined; each is run in turn on alerting.

Snort as a Quick Sniffer
If you run Snort with the command snort -v, Snort will start up and then print out the IP/TCP/UDP/ICMP headers of the packets it’s sniffed to the screen. Referring back to our sample network (see Figure), if we are connected to pc-2 and want to Telnet onto our Linux server, Snort would see the following:

[root@linuxtest snort]# snort -v
Initializing Output Plugins!
Log directory = /var/log/snort
Initializing Network Interface eth0
--== Initializing Snort ==--
Decoding Ethernet on interface eth0
--== Initialization Complete ==--

06/04-23:34:49.280177 10.1.1.236:1056 -> 10.1.1.220:23
TCP TTL:64 TOS:0x10 ID:59230 IpLen:20 DgmLen:60 DF
******S* Seq: 0x46382934 Ack: 0x0 Win: 0x16D0 TcpLen: 40
TCP Options (5) => MSS: 1460 SackOK TS: 927387242 0 NOP WS: 0
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

The first thing to notice is that Snort outputs to a standard format for each packet. In the preceding output, we can see our pc-2 desktop client (10.1.1.236) on source port (1056) connecting to the Linux server (10.1.1.220) on port 23 (Telnet). Snort shows the IP and TCP protocol information, including the first SYN (***S).

Output Format
The –v switch shows basic IP/TCP/UDP/ICMP headers. If we want to see more information, we can use two other switches:

The -d switch will show the application data in HEX and ASCII (Layer 7 of the OSI model).
The -e switch will show the Data Link layer headers (Layer 2 of the OSI model).

06/04-23:39:05.288734 0:50:DA:42:B:9E -> 0:1:3:48:78:BA type:0x800 len:0x87
10.1.1.220:23 -> 10.1.1.236:1059 TCP TTL:64 TOS:0x10 ID:15596 IpLen:20
DgmLen:121 DF
***AP*** Seq: 0xB06E41D6 Ack: 0x56DB2709 Win: 0x16A0 TcpLen: 32
TCP Options (3) => NOP NOP TS: 115899727 927412845
FF FB 01 52 65 64 20 48 61 74 20 4C 69 6E 75 78 ...Red Hat Linux
20 72 65 6C 65 61 73 65 20 37 2E 33 20 28 56 61 release 7.3 (Va
6C 68 61 6C 6C 61 29 0D 0A 4B 65 72 6E 65 6C 20 lhalla)..Kernel
32 2E 34 2E 31 38 2D 33 20 6F 6E 20 61 6E 20 69 2.4.18-3 on an i
36 38 36 0D 0A 686..
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

In the preceding output, the first line is the MAC address (Layer 2) of the client (0:50:DA:42:B:9E), and the last line is the ASCII decode of the Telnet. The rows in between are the IP and TCP protocol information. As you can see, we are logging on to a Red Hat Linux machine.

Berkeley Packet Filter Commands
If you are connected to a busy network, it won’t be long before your computer screen quickly fills up with decoded network traffic from Snort. When TCPDump was originally designed, the developers had a similar issue, so they filtered traffic using a command language called the Berkeley Packet Filter (BPF) commands. The BPF commands allow you specify protocols, hosts, and ports; basically, any field that can be decoded can be searched on or filtered by. With the BPF commands we can set up Snort to log to the screen but only for certain servers. For example, in our ex. Figure , if we only want to see traffic to and from the Linux machine on the Telnet port 23, we would apply the following BPF logic on Snort startup:

[root@linuxtest snort]# snort -vde host 10.1.1.220 and port 23

This will run Snort, display to the screen, and decode the Layer 7 and Layer 2
traffic, but only for the host 10.1.1.220 and only on the port 23 (Telnet). Further
information on the BPF language can be found here.

Log to Disk(ASCII)
What if you want to log the traffic to disk for review later? If this is the case, you would use the following command:

[root@linuxtest snort]# snort -de -l /var/snort_logs

This chews more CPU cycles than binary logging, but the results are a lot easier for us humans to interpret. Note the missing –v option. This means that Snort will not log to the screen. The previous command puts Snort into sniffer mode, it creates files in the /var/snort_logs directory for each of the clients initiating connections (our pc-2 [10.1.1.236]), and then creates a file for each unique session. Contained in each file is the decoded traffic in ASCII representation format. Therefore, in the 10.1.1.236 subdirectory is a file called TCP:1059-23 (this refers to TCP the protocol, 1059 the source port, and 23 the destination port). Inside the file are the decoded packets similar to the nformation we saw in the Output Format section.

[root@linuxtest 10.1.1.236]# ls -la
drwx------ 2 root root 4096 Jun 4 23:58 .
drwxr-xr-x 7 root root 4096 Jun 4 23:58 ..
-rw------- 1 root root 27848 Jun 4 23:58 TCP:1059-23

Log In to a pcap (tcpdump binary) Format
The previous configuration creates text-based files with the decode traffic inside. Using the following command:

[root@linuxtest snort]# snort -l /var/snort_logs -b

all traffic is logged in binary mode, and the output is written into a single file in pcap format in the /var/snort_logs directory. tcpdump binary is the ultimate in speed and flexible post-processing. This nearly universal method doesn’t require the processor-intensive conversion to text. When tcpdump-style logging is used, Snort easily keeps up with very busy networks without dropping packets. So this has a number of advantages:

It allows review using open-source or commercial GUI sniffer programs; for example, Wireshark (ex Ethereal).
It allows playback into Snort or sniffers.
It is extremely quick; basically, Snort takes all the traffic and writes it to a file.

Now, what if we wanted to read back into Snort the pcap formatted log file we just created, and for Snort to decode the packets as in the previous examples? The following command reads the file back into Snort for decode:

[root@linuxtest snort]# snort -de -r snort.log.1046008361

Alternatively, you can also apply BPF filters and use the –v switch to display the traffic to the screen:

[root@linuxtest snort]# snort -v -de -r snort.log.1046008361 host
10.1.1.220 and port 23

If you have snort.log in binary mode, you can use Ethereal (See the earlier section How Does Snort Link into libpcap?) to import the file. Ethereal gives you a GUI-based sniffer, and you can review the traffic at your leisure.

Logging to a database
Logging directly to a database is one of the most useful options for reporting your Snort data and sharing it with others. Although database tables aren’t easy to read without a software client, software clients are abundant, and programs to translate the cold hard world of database entries into the warm, fuzzy, and colorful world of Web pages are also plentiful (like ACID or BASE).

Intrusion Detection Mode
When we start up Snort in default IDS mode, the default output is to alert to a text file called “alerts” in a subdirectory called “log,” and then create a subdirectory structure similar to the previous Log to Disk section.

Snort’s output facilities
Snort basically has two ways to spit out data. The Snort developers identify these with the technical sounding term output facilities. You can tell Snort to:

Alert (Alerting mode) you when an attack is happening, complete with information on

What kind of attack it is
Where it’s coming from
Where it’s going
Where to find more information about the attack

Log (Logging mode) the actual packets of the attack, showing

MAC addresses
IP addresses
Packet payload
Timestamp
TCP flags

Usually, Snort can simultaneously send alerts and log data.

Alerting Mode
When an Alert rule is matched (see the section How a Packet Is Matched earlier), the Alert action in Snort is hard-coded to do two things:

Output an event to what is called the alert facility.
Log as much as possible/desired to the configured Logging mode.

The alert facility controls the actual format of the alert and, to a certain degree, its destination. The alert facility options are as follows.

Full Full alerts format will have the alert messages in addition to the full packet headers (default).
Fast Alert is in a simple format with a timestamp, alert messages, source and destination IPs/ports.
Syslog Logs to syslog; the default alerting facilities are LOG_AUTHPRIV and LOG_ALERT.
Unixsock Sets up a UNIX domain socket and sends alerts to it.
SMB Send WinPopup messages.

The default alert facility for Snort is Full; this can be changed from the command line on startup of Snort.

Example

01/20-22:34:35.218093 [**] [1:469:1] ICMP PING NMAP [**] [Classification:
Attempted Information Leak] [Priority: 2] {ICMP} 192.168.1.68 -> 172.16.34.18

This is your Snort box telling you that someone out there is using nmap, a network-security scanning tool, to ping your system — a sure sign that a port scan will shortly follow! The preceding code says more than “You’re getting pinged.” In addition to a
few jazzy asterisks, it includes:

Date and time (including the microsecond appended to the second itself)
The SID (Snort ID), an identifier indicating which rule was tripped. This is written in the following format: [sig_generator:sig_id:sig_revision]

sig_generator indicates which part of Snort generated the alert
sig_id is the Snort signature ID, which indicates which rule was tripped
sig_revision is the revision number of this rule

A brief text message
Classification and priority of the attack
The protocol of the packet that tripped the rule
Source and destination IP addresses involved

That’s a lot! And that’s just for the alert_fast output module, which prints a minimum of information. Other modules will print the MAC addresses, TCP flags, or even the packet payload in ASCII or hex. The options aren’t limitless, but Snort can print enough detail to satisfy even the most hardcore wire head.

Logging Mode
A different log directory can be specified on the command line by using the -l switch. All ASCII (plain text) packet logs and alerts will go to this directory. If the -l switch isn’t used, logs will go to /var/log/snort by default. The Logging mode just logs full packet information to the various sources without generating an alert. The logging mode can be called directly using the log, dynamic keywords in a Snort rule, or as a secondary action from the alert keyword. The default logging mechanism writes logs in the same fashion as the output format discussed earlier in the section Log to Disk. Within the subdirectory defined by the –l switch (-l /var/log), a subdirectory is created for each client machine IP address. In the following example, a subdirectory for pc-1 has been created, and inside each subdirectory are alerts, which contain the alert messages and a packet decode. The scan.log is the output from the portscan2 preprocessor, and the alert file was created by the “Alert facility.”

[root@linuxtest log]# ls -la
drwxr-xr-x 15 root root 4096 Jun 5 23:31 .
drwxr-xr-x 6 root root 4096 Jun 2 11:13 ..
drwx------ 2 root root 4096 Jun 5 23:31 10.1.1.1
drwx------ 2 root root 4096 Jun 5 23:31 127.0.0.1
drwx------ 2 root root 4096 Jun 5 23:31 192.168.1.1
drwx------ 2 root root 4096 Jun 5 23:31 10.1.1.220
drwx------ 2 root root 4096 Jun 5 23:31 192.168.1.150
drwx------ 2 root root 4096 Jun 5 23:31 192.168.1.64
-rw------- 1 root root 622502 Jun 5 23:31 alert
-rw------- 1 root root 17732 Jun 5 23:31 scan.log

Example
There are times when you may want to log attack data without generating alerts. For example, running Snort as a souped-up packet sniffer. Here’s the same Nmap ping logged by the logging facility. It shows the details of the port scan to port 80 as well:

01/14-19:42:03.114656 0:10:67:0:B2:50 -> 0:A0:CC:D2:10:31 type:0x800 len:0x3C
192.168.1.68 -> 172.16.34.18 ICMP TTL:37 TOS:0x0 ID:44936 IpLen:20 DgmLen:28
Type:8 Code:0 ID:13988 Seq:7720 ECHO

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

01/14-19:42:03.114717 0:A0:CC:D2:10:31 -> 0:10:67:0:B2:50 type:0x800 len:0x2A
172.16.34.18 -> 192.168.1.68 ICMP TTL:255 TOS:0x0 ID:2734 IpLen:20 DgmLen:28
Type:0 Code:0 ID:13988 Seq:7720 ECHO REPLY

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

01/14-19:42:03.115157 0:10:67:0:B2:50 -> 0:A0:CC:D2:10:31 type:0x800 len:0x3C
192.168.1.68:50488 -> 172.16.34.18:80 TCP TTL:36 TOS:0x0 ID:3836 IpLen:20
DgmLen:40
***A**** Seq: 0x3C4A079E Ack: 0x498A079E Win: 0x800 TcpLen: 20
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
01/14-19:42:03.115194 0:A0:CC:D2:10:31 -> 0:10:67:0:B2:50 type:0x800 len:0x36
172.16.34.18:80 -> 192.168.1.68:50488 TCP TTL:255 TOS:0x0 ID:0 IpLen:20
DgmLen:40 DF
*****R** Seq: 0x498A079E Ack: 0x0 Win: 0x0 TcpLen: 20
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
01/14-19:42:03.420876 0:10:67:0:B2:50 -> 0:A0:CC:D2:10:31 type:0x800 len:0x3C
192.168.1.68:50468 -> 172.16.34.18:80 TCP TTL:41 TOS:0x0 ID:64826 IpLen:20
DgmLen:40
******S* Seq: 0x6E30F501 Ack: 0x0 Win: 0xC00 TcpLen: 20
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
01/14-19:42:03.420964 0:A0:CC:D2:10:31 -> 0:10:67:0:B2:50 type:0x800 len:0x3A
172.16.34.18:80 -> 192.168.1.68:50468 TCP TTL:64 TOS:0x0 ID:0 IpLen:20 DgmLen:44
DF
***A**S* Seq: 0xAC878D4E Ack: 0x6E30F502 Win: 0x16D0 TcpLen: 24
TCP Options (1) => MSS: 1460
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
01/14-19:42:03.459314 0:10:67:0:B2:50 -> 0:A0:CC:D2:10:31 type:0x800 len:0x3C
192.168.1.68:50468 -> 172.16.34.18:80 TCP TTL:47 TOS:0x0 ID:0 IpLen:20 DgmLen:40
DF
*****R** Seq: 0x6E30F502 Ack: 0x0 Win: 0x0 TcpLen: 20
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

If you’ll run Snort as an Intrusion Detection System, you need to generate alerts. Most of the time you’ll want to log relevant packet information as well so you can trace the steps of an attack packet by packet.

Logging Formats
A number of logging plug-ins are available to Snort, and are configured in the logging section of the snort.conf file. Multiple output formats are possible, so you can log to a particular syslog “logging facility” and output to a CSV format.

The best way to support multiple output plug-ins is to specify them in the Snort configuration file (snort.conf ).This is preferable, as the command-line switches will always override the options in the snort.conf, giving the message “WARNING: command line overrides rules file alert plugin!” The following output plug-ins are available to Snort:

CSV (Comma Separated Values) This output format allows alert data to be written in format easily importable to a database or spreadsheet.
Syslog Similar to the option from the alert facility, this option provides more customization on the actual syslog facility output.
Database One of the more popular output plug-ins, it allows data to be written into the following databases: MySQL, PostgreSQL,unixODBC, Oracle, and MS-SQL Server.
Null This allows Snort to alert via the Alert facility, but not create any log files.
Tcpdump This allows Snort to output log files in TCPDump format.
SnmpTrap This allows Snort to send SNMP traps into NMSs.
Unified This plug-in is the future of Snort, and is the fastest possible method of logging Snort events. It will log into a binary format with FAST alerting. The Barnyard program will read the files from the Unified format, process them, and then output to a number of formats.
XML The XML plug-in enables Snort to log in SNML (Simple Network Markup Language, a.k.a. Snort Markup Language) to a file or over a network.

If you are compiling Snort from the source code, you need to specify the links to third-party output libraries. For example, when compiling Snort with MySQL support, you need to install MySQL and its client libraries before Snort is installed, and also configure Snort to use the libraries while compiling itself. To add MySQL support, use the ./configure —withmysql=/usr/local/mysql switch. The following will configure Snort to run in its most basic intrusion detection mode, Snort will start up, log everything “Full” to the log directory, and use the snort.conf file for configured options.

[root@linuxtest snort]# snort -l ./log -c snort.conf

Snort for Honeypot Capture and Analysis
A honeypot provides security researchers with information on the latest attacks and exploits being used by the attackers.The honeypot involves placing servers on the Internet and then watching them being hacked. During this process, the researchers need to gather as much network information as possible, and then have the ability to replay the attacks or review the network traffic. The following will configure Snort to capture all the traffic in binary format:

[root@linuxtest snort]# snort -l /var/snort_logs -b

Once we have collected a large amount of data over a one-week period, for example, we want to read it back into Snort and apply signatures to it.

[root@linuxtest snort]# snort -r snort.log.1046008362 -l /var/snort_logs/
-c snort.conf

A customized snort.conf is available here for use in honeynet projects.

Logging to Databases
The database plug-ins (spo_database.c and spo_database.h) use a slightly different
methodology when writing alerts and logs (see the previous section Snort Logging). Normally, the log keyword in the Snort rule links to the log facility, and the alert option attaches it to the alert facility, but also writes to the log facility. The database plug-ins are slightly different: if the database plug-in is configured for alert, it will only receive output from alert rules, whereas if it’s configured for log, it will receive output from both log and alert rules. The following is an example configuration in the snort.conf:

output database: alert, mysql, user=snort password=x dbname=snort host=mysql
OR
output database: log, mysql, user=snort password=x dbname=snort host=mysql

The “alerts” from preprocessors (for example, portscan2) will be written to the database only if the database plug-in is set to “alert.” In that case, the actual decoded packets for alerts are created in a subdirectory in the same manner as in the section Logging Mode. If the database plug-in is set to “log,” then preprocessor alerts will not be sent to the database plug-in, but the packet decodes for the alerts will be sent (used by ACID for Layer 3 and Layer 4 decodes). This means that in “log” mode, a third-party reporting tool such as snortsnarf is needed to report on the preprocessors output, because the events are not written to the database. The database plug-in currently supports the following databases:

Snort Reporting Front Ends
Once a database has been created and the data is being logged into it, we will need a mechanism to query the database and generate reports.We can use the Analysis Console Engine for Intrusion Detection (ACID) [now BASE]. ACID is a PHP-based analysis engine that can search and process the data from databases written to them by Snort. ACID supports the following features:

Query-builder and search interface for finding alerts matching on alert meta information (for example, signature, detection time), as well as the underlying network evidence (for example, source/destination address, ports, payload, or flags).
Packet viewer (decoder) will graphically display the Layer 3 and Layer 4 packet information of logged alerts.
Alert management by providing constructs to logically group alerts to create incidents (alert groups), deleting the handled alerts or false positives, exporting to e-mail for collaboration, or archiving of alerts to transfer them between alert databases.
Chart and statistic generation based on time, sensor, signature, protocol, IP address,TCP/UDP ports, or classification.

Building the Database
Before the databases can be used, tables within the database need to be created to store the Snort data. Contained in the contrib directory are database creation scripts; for example, create_mysql or create_oracle.These scripts create the tables and fields within each specific type of database.To set up the database plug-in for MySQL, follow these steps:

Install MySQL.
Compile Snort with MySQL support.
Create a Snort user in the MySQL database and set up security.
Create the MySQL tables using the create_mysql sql script; this creates the Snort tables used to store the data.
Configure the snort.conf database line output database: log, mysql, user=snort password=xxx dbname=snort host=mysql-server the username is Snort, the database to log to is called Snort, and the MySQL server is called mysql-server).
Start up Snort. During initialization, Snort will call the output plug-ins that will make a connection to the database.

The database plug-in author Roman Danyliw has an excellent Web site that contains lots of information about the database plug-in.

Alerting Using SNMP
SNMP is a de-facto standard for inter-network management of devices. The Snort SNMP plug-in (spo_SnmpTrap.c and spo_SnmpTrap.h) can send SNMP traps and SNMP informs to NMSs.The SNMP plug-in requires the net-snmp libraries to be installed first, and Snort to be compiled with SNMP support (./configure –with-snmp). The plugin will support SNMP version 2.0 and SNMP version 3.0.

The main developers of the SNMP plug-in have a detailed overview of the Snort SNMP process.

Barnyard and Unified Output
The unified output plug-in (spo_unified.c and spo_unified.h) allows Snort to write
alerts and logs into a single binary formatted file (unified format), which allows Snort to output alerts and logs quickly and efficiently. Barnyard program reads the unified formatted file and then outputs it in a number of formats. The separation of the output-processing component of Snort allows Snort to monitor the traffic, write to the unified format on alert, and then continue monitoring traffic.The output plug-ins that normally slow Snort down are now moved to Barnyard, which processes the unified file and outputs to the following formats:

Alert_Fast Writes output in a similar fashion to the current “Alert Fast”format.
Log_Dump Writes output into a decoded ASCII packet dump.
Alert_Html Creates a series of HTML pages for alerts.
Alert_CSV Writes alerts into a CSV format (similar to the current CSV output plug-in).
Alert_Syslog Writes alerts out to syslog facilities (similar to the current syslog output plug-in).
Output_pcap Writes data out to pcap format.
Acid_DB Writes alerts/data into the database scheme used by ACID.

For Dummies elements
As of version 1.6, Snort uses output modules, or output plug-ins, to write the data sent by the logging and alerting output facilities. Snort’s alerting and logging facilities don’t actually write the data. We have see they send data to the appropriate output module, which handles the formatting and writing of the logs. Anyone can write their own output module for handling Snort’s output in specific ways, and multiple output modules can be combined for custom logging.

Some of Snort’s output modules are better suited for daemon mode and some for packet-sniffing mode. They can all be combined with one another, and used effectively no matter how you run Snort. Any option that’s specified on the command line will silently override that same option in the snort.conf file. For instance, if you have output alert_fast: snort.log in your snort.conf file, but you call snort on the command line with the -A full switch, Snort will run with full alerts, and your snort.log file will contain the fully decoded packet header as well as the alert itself.

Snort’s command-line switches
for logging and alerting Snort has many logging options that can be specified at run time on the command line. If you also specify the use of a configuration file, remember that any option listed on the command line will override that same option in the configuration file. The following options are useful when considering different logging options:
-A alert-mode This switch tells Snort to use one of various alert modes. alert- mode can be fast, full, none, or unsock (an experimental alert mode that sends alerts to a Unix socket, and is safe to ignore unless you like writing Unix socket code).
-b This option tells Snort to log packets in a tcpdump-formatted file. Using this switch, Snort will log all packets going across the wire, not just those that match an attack pattern or other rule. This makes Snort behave almost exactly like tcpdump —including the use of tcpdump-style expressions to specify which traffic to grab.
-B address-conversion-mask This switch converts all IP addresses of your local network, or home network in the binary logs, to the address indicated by address-conversion-mask. In this way, you can share binary Snort logs with others without revealing your home network address.
-C When logging packets as ASCII text, this switch prints the character data from the packet only without printing the corresponding hex data.
-d This switch prints Application-layer data when logging packets.
-e Displays Link-layer data in packet headers
-h home-net Use this option to specify your home network, which should be replaced in your binary logs with the network specified by the -B switch.
-l logging-directory This option will tell Snort to log to the specified directory, rather than the default /var/log/snort directory.
-L binary-log-file When logging in the binary tcpdump format, this switch specifies where Snort should dump its packets.
-N This option turns off packet logging. This is useful when you want to specify a snort.conf file that includes a packet logging option that you want to override. Snort will continue to generate alerts normally when this switch is used.
-O When logging packets as decoded plain text, this switch will change any IP addresses that get printed to “xxx.xxx.xxx.xxx”, unless the “home net” is specified with the -h switch — in which case, homenet IP addresses will be changed but external addresses will be left unchanged. This is another method of hiding your homenetwork information when sharing your logs with others.
-P snap-length When capturing packets, this sets the packet snaplen (the mount of data in a packet that’s captured) to the value represented here by snap-length.
-s Use this switch to send alerts to the Unix syslog facility.
-U Timestamps in all logs will be converted to UTC (Universal Coordinated Time)
-v Print packets to the console. A nearly universal Unix directive to be verbose. This is great for testing or debugging, but bad for production environments, since it will slow down your system, and cause Snort to drop packets.
-y Show the year in your log files.

Alerting modules
Snort’s got a couple of different ways to generate alert data depending on how much detail you want in your alerts, and where you want to send them. Configuration of output modules is done within the snort.conf configuration file. The configuration file probably is /usr/local/snort/etc/snort.conf. In the Windows installation the location is D:\snortapps\Snort\etc\snort.conf. Open snort.conf and find the output plug-ins section. In the default snort.conf, this section is labeled with the comment “Step #3: Configure output plug-ins.” All of the following output module configuration is done within this section.

alert_fast This is a straightforward,this data gets logged to /var/log/snort/alert by default. The alert_fast module will print alerts in a one line format to whatever file you specify. It’s fast because Snort doesn’t burn CPU cycles converting packet headers to ASCII or writing them to the output file. The syntax to use in your snort.conf file to specify the alert_fast output module is:

output alert_fast: snort.log

To use fast alerts when calling Snort on the command line, use the -A fast option. Fast alerts show the flavor of attack, its classification, source, destination,and a timestamp. Not much else gets logged using the alert_fast output module, which is one of the reasons it’s so fast.

01/16-22:57:23.872383 [**] [1:1122:4] WEB-MISC /etc/passwd [**]
[Classification: Attempted Information Leak] [Priority: 2] {TCP}
192.168.1.68:44258 -> 172.16.34.18:80

01/16-22:57:24.668612 [**] [1:1113:4] WEB-MISC http directory traversal [**]
[Classification: Attempted Information Leak] [Priority: 2] {TCP}
192.168.1.68:44266 -> 172.16.34.18:80

01/16-22:57:24.668612 [**] [119:2:1] (http_inspect) DOUBLE DECODING ATTACK [**]
{TCP} 192.168.1.68:44266 -> 172.16.34.18:80

01/16-22:57:24.767891 [**] [1:1113:4] WEB-MISC http directory traversal [**]
[Classification: Attempted Information Leak] [Priority: 2] {TCP}
192.168.1.68:44267 -> 172.16.34.18:80

01/16-22:57:24.767891 [**] [119:2:1] (http_inspect) DOUBLE DECODING ATTACK [**]
{TCP} 192.168.1.68:44267 -> 172.16.34.18:80

01/16-22:57:24.867426 [**] [1:988:6] WEB-IIS SAM Attempt [**] [Classification:
Web Application Attack] [Priority: 1] {TCP} 192.168.1.68:44268 ->
172.16.34.18:80

alert_full The alert_fast output module will print Snort alerts with the full packet headers decoded into plain text. This gives you significantly more information about an attack, but it comes at the price of significantly decreased performance, and shouldn’t really be used unless your Snort box is on a lightly trafficked network. Use this option on a network with a lot of traffic, and Snort will drop packets. Not only that, but you’ll be writing gobs of data to your hard drive, reducing free space and causing an I/O bottleneck on your system. To generate full alerts, edit your snort.conf file to specify the following output module configuration:

output alert_full: alert.full

Here we see the logs written to /var/log/snort/alert.full, as specified in the preceding output module configuration:

[**] [1:1668:5] WEB-CGI /cgi-bin/ access [**]
[Classification: Web Application Attack] [Priority: 1]
01/16-23:06:11.675382 0:10:67:0:B2:50 -> 0:A0:CC:D2:10:31 type:0x800 len:0xDD
192.168.1.68:44561 -> 172.16.34.18:80 TCP TTL:47 TOS:0x0 ID:53932 IpLen:20 DgmLen:207 DF
***AP*** Seq: 0xD5349716 Ack: 0x2B34D8BB Win: 0x16D0 TcpLen: 32
TCP Options (3) => NOP NOP TS: 322913730 135653681

[**] [1:1201:7] ATTACK-RESPONSES 403 Forbidden [**]
[Classification: Attempted Information Leak] [Priority: 2]
01/16-23:06:11.675864 0:A0:CC:D2:10:31 -> 0:10:67:0:B2:50 type:0x800 len:0x268
172.16.34.18:80 -> 192.168.1.68:44561 TCP TTL:64 TOS:0x0 ID:12687 IpLen:20 DgmLen:602 DF
***AP*** Seq: 0x2B34D8BB Ack: 0xD53497B1 Win: 0x16A0 TcpLen: 32
TCP Options (3) => NOP NOP TS: 135653685 322913730

[**] [1:1852:3] WEB-MISC robots.txt access [**]
[Classification: access to a potentially vulnerable Web application] [Priority:2]
01/16-23:06:13.035036 0:10:67:0:B2:50 -> 0:A0:CC:D2:10:31 type:0x800 len:0xDF
192.168.1.68:44572 -> 172.16.34.18:80 TCP TTL:47 TOS:0x0 ID:27543 IpLen:20 DgmLen:209 DF
***AP*** Seq: 0xD5D72DD3 Ack: 0x2BD8E79A Win: 0x16D0 TcpLen: 32
TCP Options (3) => NOP NOP TS: 322913866 135653817
[Xref => http://cgi.nessus.org/plugins/dump.php3?id=10302]

[**] [1:1145:6] WEB-MISC /~root access [**]
[Classification: Attempted Information Leak] [Priority: 2]
01/16-23:06:13.233595 0:10:67:0:B2:50 -> 0:A0:CC:D2:10:31 type:0x800 len:0xDA
192.168.1.68:44574 -> 172.16.34.18:80 TCP TTL:47 TOS:0x0 ID:5770 IpLen:20 DgmLen:204 DF
***AP*** Seq: 0xD55950D4 Ack: 0x2B16C39E Win: 0x16D0 TcpLen: 32
TCP Options (3) => NOP NOP TS: 322913886 135653837

[**] [1:1156:4] WEB-MISC apache DOS attempt [**]
[Classification: Attempted Denial of Service] [Priority: 2]
01/16-23:06:13.542489 0:10:67:0:B2:50 -> 0:A0:CC:D2:10:31 type:0x800 len:0x1D5
192.168.1.68:44577 -> 172.16.34.18:80 TCP TTL:47 TOS:0x0 ID:62470 IpLen:20 DgmLen:455 DF
***AP*** Seq: 0xD62EB27E Ack: 0x2B97F12D Win: 0x16D0 TcpLen: 32
TCP Options (3) => NOP NOP TS: 322913917 135653868

Full alerts can also be specified on the command line using the -A full switch. But unless you’re doing some network debugging or you’re on a network segment with light traffic, this option isn’t recommended.

alert_syslog Sending alerts to a log file is great, but the methods we just mentioned lack a bit of flexibility. What if you want to send the alert data to a remote logging server? Or what if your Snort sensor is on a lightly trafficked network, and you want alerts sent to the same log file as other security alerts, like invalid logins, or attempts by users to “su” to root? To add a bit of flexibility to your logging, use the alert_syslog option to send your alerts to the Unix syslog facility. Alert_syslog basically does the same thing as alert_fast: It formats Snort alerts as a single line showing what kind of attack is happening, the classification,source, and destination of the attack. Alert_syslog shines by taking advantage of the syslog daemon’s features. One of the nicest features of syslog is the ability to send logs to a remote log server. If a computer system has been compromised, it’s wise not to trust the log files on that system, since most attackers will concentrate on covering their tracks after getting in almost as much as they concentrate on cracking the system in the first place. With remote logging, the attacker will have a much harder time covering their tracks, since they must compromise both your remote logging server and the one they just broke into. Configuring Snort for syslog logging is as easy as specifying the following in your snort.conf file:
```
alert_syslog:
(You can use any one of the following facilities:)
LOG_AUTH
LOG_AUTHPRIV
LOG_DAEMON
LOG_LOCAL1
LOG_LOCAL2
LOG_LOCAL3
LOG_LOCAL4
LOG_LOCAL5
LOG_LOCAL6
LOG_LOCAL7
LOG_USER
(and any of the following priorities:)
LOG_EMERG
LOG_ALERT
LOG_CRIT
LOG_ERR
LOG_WARNING
LOG_NOTICE
LOG_INFO
LOG_DEBUG
```
The preceding options give you lots of possibilities, but if you simply want to get Snort logging to the local syslog log file and move on, enter the following in your snort.conf configuration file:
```
output alert_syslog: LOG_AUTH LOG_ALERT
```
Snort doesn’t care which syslog priority you specify as much as syslog does. That is to say that if you specify the LOG_ALERT priority, Snort will spit out the same data as if you specified the LOG_DEBUG priority. The difference matters when it comes to telling syslog where to send the data. For example, if you have the following lines in your snort.conf file (remember, you can specify multiple outputs):
```
output alert_syslog: LOG_LOCAL3 LOG_ALERT
output alert_syslog: LOG_LOCAL3 LOG_DEBUG
```
and you’ve got this in your syslog.conf file:
```
local3.debug /var/log/snort.debug
local3.alert /var/log/snort.alert
```
after running Snort for a while, both /var/log/snort.debug and /var/log/snort.alert will be identical. Of course, you could do the same thing by using one alert_syslog module and one alert_fast module, both pointed at different files:
```
output alert_syslog: LOG_LOCAL3 LOG_ALERT
output alert_fast: /var/log/snort/snort.alert
```
So why specify different priorities? Mainly because syslog wants to see some kind of priority attached to a log entry. It also comes in handy if you intend to send the same data to two different locations. If you’re really paranoid about system security, you might want to keep one copy of your snort logs on your snort system, and another identical copy on your remote logging server. This way, if your log files ever differ between the two systems, you can reasonably suspect that shenanigans are afoot, and someone’s been tampering with your logs!

Logging to a remote syslog server
So how do we configure syslog for remote logging? Thankfully, it’s not nearly as hard as you might think. There is no difference in your snort.conf file if you’re using local syslog logging or remote logging, in both cases you simply specify which facility and priority to use. The changes need to be made in the syslog.conf file on your Snort system, as well as the initialization script that starts the syslog daemon (syslogd) on the remote logging server.

To send syslog entries to a remote server instead of a local file, simply specify an @ sign and the server’s IP address instead of a local file. For example, to send all local3 facility logs to 192.168.1.51, your syslog.conf file should include the following line:

local3.* @192.168.1.51

To keep one copy of your logs locally, and one copy on a remote syslog server, you could include the following in your snort.conf file:

output alert_syslog: LOG_LOCAL3 LOG_ALERT
output alert_syslog: LOG_LOCAL3 LOG_DEBUG

and this in your syslog.conf file:

local3.debug /var/log/snort.debug
local3.alert @192.168.1.51

Naturally, you need to configure your remote logging server to accept this data, as well as tell it where to write the data. In this case, we’re sending data with the local3 facility, and telling the remote syslog server where to write the data is no different than if it originated locally:

local3.* /var/log/snort.log

To tell the syslog daemon to accept log data from remote sources, syslogd must be started with the -r switch. If you’re running Red Hat Linux or SuSe Linux, check /etc/sysconfig/syslog file. On Red Hat, change the line that reads:

SYSLOGD_OPTIONS=”-m 0”
to
SYSLOGD_OPTIONS=”-r -m 0”

And on SuSE, add a -r to your SYSLOGD_PARAMS=”” line, so it reads:

SYSLOGD_PARAMS=”-r”

If you’re running Debian GNU/Linux, look at /etc/init.d/sysklogd. About a dozen lines down in the file, change the line:

SYSLOGD=””
to:
SYSLOGD=”-r”

Once you’ve edited the appropriate file and changed the way syslogd starts up, don’t forget to restart it so your changes take effect!

Now if you look at the /var/log/snort.log file on your remote log server, you should see your alerts:

Jan 15 16:12:59 yoursnortbox.yourdomain.com snort: [1:483:2] ICMP PING CyberKit
2.2 Windows [Classification: Misc activity] [Priority: 3]: {ICMP}
192.168.200.50 -> 172.16.34.18
Jan 15 16:15:41 yoursnortbox.yourdomain.com snort: [1:483:2] ICMP PING CyberKit
2.2 Windows [Classification: Misc activity] [Priority: 3]: {ICMP}
10.64.229.250 -> 172.16.34.18
Jan 15 16:16:23 yoursnortbox.yourdomain.com snort: [1:2003:2] MS-SQL Worm
propagation attempt [Classification: Misc Attack] [Priority: 2]:
{UDP} 10.77.29.69:1282 -> 172.16.34.18:1434
Jan 15 16:17:37 yoursnortbox.yourdomain.com snort: [1:483:2] ICMP PING CyberKit
2.2 Windows [Classification: Misc activity] [Priority: 3]: {ICMP}
64.123.246.211 -> 172.16.34.18

Notice how the hostname of your Snort box is appended at the beginning of each line? You’ll be glad this information is there if you’re running a centralized log server with multiple machines logging to it.

Replacing syslog with syslog-ng
syslog is a wonderful tool that’s been in the Unix world for a long time. So long, in fact, that it’s starting to look a little long in the tooth. Enter syslog-ng — the Next Generation of syslog — a drop-in replacement that includes better remote logging and log forwarding, built-in message filtering, and logging over TCP as well as UDP protocols. (The older syslog only handles the less-secure UDP protocol.) On the drawing board for future versions of syslog-ng is message integrity and encryption.
Why should you consider syslog-ng? If our glowing description of its features hasn’t
enticed you enough,
imagine having the capability to easily split your Snort alerts out to different files depending on the nature of the attack. (While this is technically possible with traditional syslog and some hacking of your snort.conf and local.rules files, syslog-ng makes the process much easier.)
What about real-time file monitoring of all your syslog files? Or
the capability to launch specific programs based on the content of incoming log entries? Add-on software such as Swatch can help handle these tasks when you’re using the traditional syslog program,but why rely on external software when you can do it all from syslog-ng?
Even if you install syslog-ng solely for use with Snort right now, once you’ve become familiar with its power and flexibility, you’ll be amazed at what you can do. Some distributions of Linux are starting to ship with syslog-ng as an install-time option, and others have syslog-ng available as a precompiled binary. If your favorite distribution lacks a syslog-ng package, you can grab the source code and compile it for yourself (not a bad idea anyway, even if there’s a binary package available for you).

syslog-ng lives here. If you’re going to install syslog-ng, it’s a good idea to subscribe to the mailing list, or at least peruse the archives a bit. You’ll find more up-to-date information this way than by reading the Web site or even the documentation included in the syslog-ng source code. syslog-ng depends on libol, a support library that’s also available from the syslog-ng Web site. Once you’ve got both packages
downloaded, installation is relatively painless. Assuming you’ve downloaded the source tarballs to /usr/local/src/tarballs, installation is as follows :
# cd /usr/local/src
# tar -xvzf tarballs/libol-x.y.z.k.tar.gz
# tar -xvzf tarballs/syslog-ng-x.y.z.tar.gz
# cd libol-0.3.12/
# ./configure
# make
# make install
# ldconfig
# cd ../syslog-ng-1.6.1/
# ./configure
# make
# make install
Once you’ve got syslog-ng compiled, it’s time to build a syslog-ng.conf file. This can be an overwhelming task if you must start from scratch, but most folks won’t, since there are already sample configuration files included in the doc/ and contrib/ subdirectories of the syslog-ng source code. If you’ve already got a custom tailored syslog.conf file that you’re very proud of, and you sneer at the notion of someone’s
default configuration file fitting your needs, you can relax; there’s a shell script that will generate a syslog-ng.conf file from your existing syslog.conf file.

Since we’ve already customized our syslog.conf file, let’s use the script to generate an appropriate syslog-ng.conf file. Before running the script, make sure you’ve got an /etc/syslog-ng directory. We’re going to run the script, and redirect the output to this directory, creating our new configuration file:
# mkdir /etc/syslog-ng
# cd /usr/local/src/syslog-ng-x.y.z/contrib
# cat /etc/syslog.conf | ./syslog2ng > /etc/syslogng/syslog-ng.conf
You’ve got a configuration file! Pull it up in your favorite text editor and give it a gander. You’ll notice that the script has kept each line from your original syslog.conf file in the new file, but the line is commented out, so syslog-ng ignores it when initialized. Once you’ve got your configuration file set up, you’ll want to make sure you’ve got an initialization script in place so syslog-ng starts up at boot time. There are many sample initialization scripts in the contrib/ directory; find one that matches your system, and place it in your /etc/init.d directory (or wherever your initialization
scripts go for your flavor of Linux). Once syslog-ng is set to start at boot time, disable the old syslog script so syslog won’t start at boot time.

If you’re running Snort on a Windows platform, you don’t have a native syslog daemon, and the differences between the alert_syslog output module and the alert_fast output module may be so small as to not be worth your worry. If you decide that remote logging is just so cool that you’ve got to try it in Windows, grab a patch from by Frank Knobbe that lets you use syslog style remote logging from the command line, without clobbering the rest of your logging settings in your snort.conf file. The patch is available from the Snort.org Web site. If you decide that syslog by itself is such a cool idea that you’ve got to have a syslog daemon for Windows, check out the Kiwi Syslog Daemon, from Kiwi Enterprises . Kiwi Syslog Daemon comes in two versions: A freeware version that you can download and use without paying anything, and a licensed version that comes with extra features (such as database logging and better performance) for around $99.

alert_CSV CSV stands for Comma Separated Values, a nearly universal intermediate format for importing data into databases or spreadsheets. If you want to process your Snort alerts in a database that’s not natively supported by Snort, like MS Access, or import them into a spreadsheet such as Excel, or run them through your own home-brewed analysis program, the alert_CSV output module is for you. To specify it in your snort.conf file, use the following format:
```
output alert_CSV: "destination file" "format"
```
Where "destination file" is the file where you want your CSV-formatted data to land, and "format" is a comma separated list of alert data to write. If you want to log everything, you can specify default as the format to use. Table lists all of the CSV fields you can write. If you use the default format, the fields will be written in the order listed in Table, top to bottom. So to just start logging all format information to a CSV file called alert.csv, add the following entry to the snort.conf configuration file:
```
output alert_CSV: /var/log/snort/alert.csv default
```
Here’s a snippet of the alert.csv log file showing some ICMP (ping) probe
activity, using the default format we specified in the preceding alert_CSV configuration:
```
01/15-21:39:00.801134 ,ICMP PING CyberKit 2.2
Windows,ICMP,67.95.155.138,,172.16.34.18,,0:10:67:
0:B2:50,0:A0:CC:D2:10:31,0x6A,,,,,,111,0,40019,92,
20,8,0,,

01/15-21:43:07.555566 ,ICMP PING CyberKit 2.2
Windows,ICMP,213.86.221.179,,172.16.34.19,,0:10:67
:0:B2:50,0:C0:F0:2B:E5:F8,0x6A,,,,,,107,0,25381,92
,20,8,0,,

01/15-21:45:35.047068 ,ICMP PING CyberKit 2.2
Windows,ICMP,213.249.229.182,,172.16.34.18,,0:10:6
7:0:B2:50,0:A0:CC:D2:10:31,0x6A,,,,,,105,0,17518,9
2,20,8,0,,
```
Too much information? You can simplify it by telling the alert_CSV module to
log only what you want. Maybe you’re only interested in the timestamp, alert
message, source IP address, and destination IP address. Use this line in your
snort.conf file:
```
output alert_CSV: /var/log/snort/alert.csv timestamp,msg,src,dst
```
It will generate much more succinct data, such as this entry showing many
Web-based attacks against a Web server:
```
01/16-20:33:08.978678 ,ATTACK-RESPONSES 403 Forbidden,172.16.34.18,192.168.1.68
01/16-20:33:10.250312 ,WEB-MISC robots.txt access,192.168.1.68,172.16.34.18
01/16-20:33:10.490020 ,WEB-MISC /~root access,192.168.1.68,172.16.34.18
01/16-20:33:10.792501 ,WEB-MISC apache DOS attempt,192.168.1.68,172.16.34.18
01/16-20:33:11.614642 ,WEB-MISC .DS_Store access,192.168.1.68,172.16.34.18
01/16-20:33:11.709005 ,WEB-MISC .FBCIndex access,192.168.1.68,172.16.34.18
01/16-20:33:12.792244 ,WEB-CGI printenv access,192.168.1.68,172.16.34.18
```
This looks a little easier to handle. With Snort, as with all things in life, make sure you know what you need, and don’t be concerned with what you don’t need.

Logging modules
Logging modules are used to log packet information. Logging modules are typically called by alert modules in order to log packet information relevant to a particular alert, but they can also be called by some of the preprocessors, or called independently from the command line.
For IDS mode, in a nutshell:

Snort captures network traffic and
applies a preprocessor on it that normalizes the traffic into a recognizable format. If the preprocessor deems the traffic noteworthy,
it can call an output module to send an alert, or log the packet, or do both (depending on how the preprocessor is written).
Snort then compares the normalized network traffic to a list of rules.
If the packet matches a particular rule, then Snort generates an alert using the appropriate alert module (specified in snort.conf or on the command line).
When the alert is generated, Snort also calls the appropriate logging module to log details of the network packets that matched the rule. Now when you see the alert in your logs, you can go back and examine the packet information responsible for generating the alert.

Default logging in ASCII format using -l
Snort can be used to log network traffic without generating alerts. In fact, Snort started life as a hopped-up version of tcpdump (the ubiquitous packet capture program used by network geeks everywhere). The simplest way to generate logging (not alerting) is to call Snort from the command line and tell it to log packet data somewhere using the -l switch which specifies a logging directory. The -l switch is available and useful from the command line only. If you are running Snort with the -D switch for daemon mode, and you’re specifying a snort.conf file with the -c switch, you’re not going to get much use out of using the -l switch for logging packet information.

Create a test logging directory, then tell snort to send its log data there. At a
command prompt under Linux, do the following:

# mkdir /var/log/snort/test_logging
# /usr/local/bin/snort -l /var/log/snort/test_logging/

In Windows:

C:\snort\bin>mkdir c:\snort\logs
C:\snort\bin>snort -l c:\snort\logs

Let this run for a minute or so, then kill it by hitting Ctrl+C. Now take a look at the /var/log/snort/test_logging directory. You’ll see a set of subdirectories, one for each IP address that’s been sending packets to and from your network. If you look at the files in these subdirectories, you’ll find a bunch of files, named for the protocol, source port, and destination port of each packet:

# cd /var/log/snort/test_logging/
# ls
192.168.1.68 10.100.11.17 ARP
# cd 192.168.1.68/
# ls
TCP:45955-80 TCP:45961-80 TCP:45967-80 TCP:45973-80 TCP:45979-80
# less TCP:45991-80
01/16-23:34:11.865655 192.168.1.68:45991 -> 172.16.34.18:80
TCP TTL:47 TOS:0x0 ID:44483 IpLen:20 DgmLen:60 DF
******S* Seq: 0x3ED87B82 Ack: 0x0 Win: 0x16D0 TcpLen: 40
TCP Options (5) => MSS: 1460 SackOK TS: 323081793 0 NOP WS: 0
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
01/16-23:34:11.865697 172.16.34.18:80 -> 192.168.1.68:45991
TCP TTL:64 TOS:0x0 ID:0 IpLen:20 DgmLen:60 DF
***A**S* Seq: 0x933AEFD2 Ack: 0x3ED87B83 Win: 0x16A0 TcpLen: 40
TCP Options (5) => MSS: 1460 SackOK TS: 135821704 323081793 NOP
TCP Options => WS: 0
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
01/16-23:34:11.901372 192.168.1.68:45991 -> 172.16.34.18:80
TCP TTL:47 TOS:0x0 ID:44484 IpLen:20 DgmLen:52 DF
***A**** Seq: 0x3ED87B83 Ack: 0x933AEFD3 Win: 0x16D0 TcpLen: 32
TCP Options (3) => NOP NOP TS: 323081797 135821704
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
01/16-23:34:11.903218 192.168.1.68:45991 -> 172.16.34.18:80
TCP TTL:47 TOS:0x0 ID:44485 IpLen:20 DgmLen:203 DF
***AP*** Seq: 0x3ED87B83 Ack: 0x933AEFD3 Win: 0x16D0 TcpLen: 32
TCP Options (3) => NOP NOP TS: 323081797 135821704
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
01/16-23:34:11.903262 172.16.34.18:80 -> 192.168.1.68:45991
TCP TTL:64 TOS:0x0 ID:38495 IpLen:20 DgmLen:52 DF
***A**** Seq: 0x933AEFD3 Ack: 0x3ED87C1A Win: 0x16A0 TcpLen: 32
TCP Options (3) => NOP NOP TS: 135821708 323081797
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

Notice how any mention of a specific alert is conspicuously absent from these files.
If you want to see what’s happening as it happens, instead of seeing what happened after the fact. Ever bake a cake with the oven light on the whole time? It doesn’t make the cake cook any faster, but it’s kind of cool to watch it rise. For those of us who need this instant gratification, Snort has the -v switch. When logging packet data, this will send the data straight to the console. Since Snort is a descendant of tcpdump, it will take much of the same command line syntax as tcpdump, including expressions dictating what kind of traffic to process, and what to ignore. If you’re going to try running Snort with the -v switch to watch decoded packets and you’re accessing your
Snort machine over an SSH connection, make sure to tell Snort to ignore your SSH traffic, otherwise your terminal will turn into an unreadable flood of data
as Snort displays the headers for each SSH packet. Each packet sent back to your terminal will in turn have its headers displayed, causing an unending cycle of data streaming. The -v switch is great for debugging purposes, but it slows down Snort considerably, and causes Snort to drop packets. Don’t use the -v switch while
running Snort in IDS mode, or you might miss an attack.

If you want to log more detail about each packet, you can use the -d switch to dump application layer data from each packet, and you can use the -e switch to dump the link layer data from each packet. Here, we tell Snort to ignore our own SSH packets (which operate over port 22), and print all other packets to the terminal showing the application layer as well as the link layer:

# snort -vde not port 22
Running in packet logging mode
Log directory = /var/log/snort/test_logging2/
Initializing Network Interface eth0
--== Initializing Snort ==--
Initializing Output Plugins!
Decoding Ethernet on interface eth0
--== Initialization Complete ==--
-*> Snort! <*- Version 2.1.0 (Build 9) By Martin Roesch (roesch@sourcefire.com, www.snort.org)  01/16-01:22:23.654699 0:10:67:0:B2:50 -> 0:A0:CC:D2:10:31 type:0x800 len:0x6A
192.168.16.50 -> 172.16.34.18 ICMP TTL:104 TOS:0x0 ID:60592 IpLen:20 DgmLen:92
Type:8 Code:0 ID:56566 Seq:16552 ECHO
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

01/16-01:22:23.654842 0:A0:CC:D2:10:31 -> 0:10:67:0:B2:50 type:0x800 len:0x6A
172.16.34.18 -> 192.168.16.50 ICMP TTL:255 TOS:0x0 ID:35856 IpLen:20 DgmLen:92
Type:0 Code:0 ID:56566 Seq:16552 ECHO REPLY
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

Yep, we’re getting pinged (the keywords ICMP, ECHO, and ECHO REPLY clue us into this). If you want to see more interesting traffic than this, run the same command on your own Snort box and see what you get. If the output is too much to deal with, try playing around with different expressions to ignore different kinds of traffic.

using log_tcpdump
It may come as no surprise that the log_tcpdump logging module logs data to a binary tcpdump-formatted file. Logging binary data is very fast for Snort, since it skips the binary to text conversion process associated with other forms of logging.
Once you’ve got log data in a tcpdump format, you can use any one of many different tools for post processing. If you’ve been working with networks for a while, it’s possible that you already have a favorite tool for working with network packet captures. One of ours is Ethereal(now Wireshark), a great GUI packet-sniffer that can actively capture data or display previously recorded network traffic. The log_tcpdump output module takes only one argument when specified in your snort.conf file, and that is the destination file for logging its data:

output log_tcpdump: tcpdump.log

Remember, by default Snort will send all of its output to /var/log/snort unless you specify a different path, or override this setting on the command line.

When running Snort as an IDS, the log_tcpdump module is activated when packets match Snort rules and generate alerts. It will log packets that are associated with alerts only, and not log every packet that flies across the wire. Although this may sound like a limitation, it is very desirable behavior, since logging every packet on your network would quickly fill up the hard drives on your Snort system. If you’ve decided that for testing or debugging purposes logging every packet on the wire is really what you need to do, you can call Snort with the -b switch to log all packets in binary format and specify the log file with the -L switch. To log all packets to a binary format, type the following at a command line:

/usr/local/bin/snort -b -L /var/log/snort/snort.dump

When you look in the /var/log/snort/ directory, you’ll see your tcpdump.log file has a dot and a bunch of numbers stuck on the end (tcpdump.log.1074240477) This is a timestamp, indicating when this particular instance of Snort was run so it isn’t confused with other packet-capture sessions. The number is a count of the number of seconds past “the epoch,” and is a standard way of measuring time in the Unix world. (The epoch, incidentally, is 01 January 1970. It may be worth noting that the Unix programmer’s sense of time begins at the exact moment the ’60s ended.)

Snort logging to a database
Flat text files are a great format for reading, and they’re not bad for sorting through by machine. The Unix grep command is by far one of the most useful tools for sorting through log files, and there are numerous programming languages devoted solely to
manipulating text (such as awk, sed, and perl python ruby). The problem with this is that sorting through flat text files is slow, and it only gets slower the larger your files become. Binary data in a tcpdump-formatted file is great for reading with your favorite packet sniffer, or analyzing with any of the myriad packet analysis tools available, or even replaying like a tape through Snort to test new rules or look for
attacks. But analyzing these binary files takes processor power — and as with text files, the larger your binary data file becomes, the more your processor must crunch to make human-readable sense out of all the zeros and ones.

Neither of these solutions is viable when you want immediate (or close to immediate) reports on what’s been happening on your network. If your Snort sensor has been running for more than a few hours, you’re going to generate a tremendous amount of data, and flat text files and binary data just don’t scale very well. Enter the Snort database output module. By logging your alerts and packet logs to a database, you get a very stable format that scales exceptionally well, and allows for extremely fast searching and reporting. It’s not unusual to have Snort databases that are a gigabyte or so in size. By splitting each log entry into component pieces, and writing those pieces to different database tables, searching for a specific entry is fast enough that it can be done from a Webserver script to generate Web pages on the fly. Try to do that with a text file (you’d better have some errands to run while you wait for the output). These are some of the reasons why we chose to configure Snort for database output.

With the database output module, Snort has the ability to send output to many SQL databases. As of version 2.1, Oracle, UnixODBC, MS-SQL, PostgreSQL, and the ever-popular MySQL are all supported by this plug-in. If you plan to log your Snort data to a database, make sure you run the configure script with the appropriate flag to include support for your particular database format when you compile and install Snort.

Database logging isn’t available as a command-line option to Snort. Instead, it must be configured in the snort.conf file. The format to include this module is:

output database: "log | alert", "database type", "parameter list"

NOTE---The | (pipe) between log and alert is shorthand, indicating that you need to specify either log or alert as the logging method.

The database module differs from other reporting modules a bit in how it handles logs versus alerts.

If you have the log keyword in a Snort rule, when the rule is activated, it sends data on to the appropriate output module (usually log_tcpdump) by way of the log facility.
When the alert keyword is used in a Snort rule, the alert facility is used, but data is also written to the log facility. If the database plug-in is configured for alerts, it will only receive output from rules that specify the alert keyword. If the database plug-in is configured with the log option, it receives output from alert rules and log rules. Anyway the log option will work just fine for most
situations.

So if you know that you want to use the log option, and you already know what database type you’re going to use, you can move on to specifying the required parameters to make it all work. Some of these parameters must be specified; others will be filled in by Snort, if not by you. When written into your snort.conf file, each parameter is specified by a name=value pair:

host: The name or IP address of the host that’s running your database server. If you don’t include a hostname, Snort assumes you’re sending data over a Unix domain socket. If a host name or IP address is specified, Snort will use TCP/IP to send your data. If you’re running your database server on the same system as Snort, set your host to localhost.
port: The port number your database server is listening on.
password: If your database server requires authentication, this is the password to use.
dbname: This is the database username used for authentication purposes when connecting to your database.
encoding: Binary data isn’t very portable across databases, but binary data is what we’ve got in our packet payload, so some form of encoding must be done to actually store the data in the database. Your options are as follows:

hex: This is the default method. It represents binary data as a hex string, which makes for great searchability, but poor human readability without some form of post-processing. This takes up twice as much space as binary data.
base64: Binary data is represented as a base64 string, which is slightly larger than the binary data itself. This format isn’t very searchable or readable without post-processing.
ascii: Since not all binary data can be represented as ascii, you will loose some data if you go this route. This takes up slightly more space than the original binary format, but gives you excellent searchability when looking for a text string. And of course, ascii text is infinitely readable by us humans.

sensor_name: If you want to specify a name for this particular Snort sensor, do so here. If not, Snort will come up with one for you.
detail: How much detail of the offending packets should be logged?
full: This is the default, which logs all the available information about the packet, including the packet payload, and its ip/tcp options.
fast: This will only log the timestamp, message signature, source IP address, destination IP address, source port, destination port, tcp flags, and protocol. A minimalist configuration entry for database logging would look something like this:
```
output database: log, mysql, user=snortuser password=h4wg dbname=snortdb host=localhost
```

Unified logging
With the amount of software and Webdriven scripts available for pulling details from databases, database logging is the best storage mechanism to make your log details quickly available for reporting and analyzing. But for all its advantages, the database output module is still being run on your Snort sensor, even if the results are being sent to a remote database server. In fact, it’s being run by the same process that’s analyzing packets. This means valuable CPU cycles are being spent converting data and talking to your database server, instead of doing what Snort does best: capturing and analyzing network traffic. Wouldn’t it be nice if Snort didn’t worry about converting the binary data it gets from libpcap (or WinPCAP) to a format us puny humans can read? Or if it didn’t worry about shoveling data over to your database server, or syslog server, or writing log files to directories? Without these extra tasks to bog it down, Snort could process more packets and compare them to more rules even faster than it does now.

With the new unified logging format, Snort does exactly this. It keeps all of the packet data that it gets from libpcap in its native binary form, and doesn’t even bother to convert the alert data to something human-readable. Instead, it relies on an external software piece to do this work for it. This extra bit of software is Barnyard, and combined with unified logging, it is the way of the future.

Configuring unified logging for Snort is actually pretty simple. Since it’s really not doing anything other than dumping raw data, you just need to tell Snort to use the unified logging output and where it should write its data. Edit the snort.conf configuration file and add the following:

output alert_unified: unified_alert_filename
output log_unified: unified_log_filename

As with all other Snort logging, these files will wind up in /var/log/snort by default. When you look at these files, you’ll see that the filename has been appended with a bunch of numbers. This is a timestamp designed to keep different unified output files separate. As with the alert_tcpdump output files, the timestamp is the number of seconds past the epoch (that is, 01 January 1970).

Adding Visuals and Getting Reports(ex ACID current BASE)
The web front end BASE is used to analyze the data stored in a DB. BASE is the successor to ACID, the Analysis Console for Intrusion Databases, developed by Roman Danyliw at the CERT Coordination Center as a part of the AirCERT (Automated Incident Reporting) project. BASE is actively maintained and supported by a team of volunteers led by Kevin Johnson and Joel Esler.

Introduction to BASE, the Basic Analysis and Security Engine

BASE searches and processes databases containing security events logged by assorted network monitoring tools such as firewalls and IDSs. BASE is written in the PHP programming language and displays information from a database in a user friendly web front end. When used with Snort, BASE reads both tcpdump binary log formats and Snort alert formats. Once data is logged and processed, BASE has the ability to graphically display both layer-3 and layer-4 packet information. It also generates graphs and statistics based on

time
sensor
signature
protocol,
TCP/UDP port or classification.

The BASE search interface can query based on alert meta information such as

sensor
alert group
signature
classification and detection time, as well as packet data such as
source/destination addresses
ports
packet payload
packet flags

BASE allows for the easy management of alert data. The administrator can

categorize data into alert groups
delete false positives or previously handled alerts
archive and export alert data to an email address for administrative notification or further processing
Support for user logins and roles, allowing an administrator to control what is seen through the web interface.

In the case we'll examine, Snort will log alert data to a MySQL database which will then be read by BASE and displayed via an Apache web server. BASE also supports other database back ends and can display information via any web server that supports PHP.

Using BASE

You should have a functional BASE install accessible at http://www.your.domain/base, and you're ready to begin using the GUI to view and manage alerts.

Navigating the Main Screen

Once you log in, the main page shows a summary of currently logged alerts as well as various alert summary breakdowns and links to graphs

Drilling down into any of the summaries will present a list of events. Depending on the list, it is possible to drill further down and gain more detail. For example, following the link Today's alerts: unique, brings up a new screen with a summary of alerts which begin at the previous midnight.
A link labeled snort, located to the left of each signature, attempts to connect to the signature database at the Snort web site and provide more detailed information about that particular signature.

Drilling down on a source or destination IP address on any of the screens brings up a summary that includes how many times that IP was logged as a source or destination address. It also indicates the first and last time the IP was logged.
Additionally, the summary page contains links to external web-based tools that provide DNS and Whois lookup services.

Drilling down on the source or destination port's links displays a summary of ports, number of occurrences, time first seen and time last seen. Each listed port number is a hyperlink to the SANS Internet Storm Center page for that port number.

Creating Alert Groups

Alert groups can be created to group event information into user-defined categories for easy perusal. In order to create a new alert group or modify existing groups, click on the Alert Group Maintenance link at the bottom of the main page.

Next, click the Create link and fill out the name and description fields for the new group. For this example I'll create an alert group named test2 based on an alert signature. To do so,

I return to the main page and select the Unique alerts link
then decide to use the signature named IIS UNICODE CODEPOINT ENCODING.
I check the box next to that signature, then scroll to Action box at the bottom of the page.
From the drop down menu labeled {action} I select the option to ADD to AG by Name, type in test2, and click on the Selected button.
Returning to the Alert Group Maintenance screen I see that the group test2 now shows two alerts.

The Search Function

BASE has a search function that can be used to quickly search through the database for certain criteria and present it in an ordered fashion. The allowable search criteria include

Alert Group
Signature and
Alert Time.

The results can be ordered by

timestamp
signature

Unfortunately, there is no option to use an IP address as one of the criteria.

Generating Graphs

Graphs can be created from Alert Data or Alert Detection Time.The Alert Data can be graphed and charted based on a variety of options to create easily readable reports. A bar graph based on Alert Detection Time which can be used to identify periods of heavy activity. These charts and graphs allow the system administrator to visually pinpoint periods of attacks. The images created by BASE are also a valuable resource for inclusion in managerial reports and departmental presentations dealing with site security.

Getting to Know Snort’s Buddies

Snort can do its job alone, but it can do its job better with a little help from some other applications.

The busier Snort is, the more likely it’s going to drop packets, and dropped packets are packets that don’t get analyzed (like false negatives) Let Snort handle capturing and analyzing network traffic, and let other programs handle everything else when possible.

Table lists a few examples of various useful third-party programs and tools. For more on how to handle Snort’s data.

Using Snort on Your Network

Your IDS can use just one Snort system, or more than one if you need redundancy (Vs managment). For example, it is possible to divide the task of network monitoring across multiple hosts. The chief benefit of dividing tasks is redundancy—if one element of the system goes down, the network can still be monitored and protected. The previously outlined network structure can be used for passive monitoring or active monitoring.

Passive monitoring is simply the ability to listen to network traffic and log it.
Active monitoring (Snort is primarily used for active auditing) involves the ability to either:

Monitor traffic and then send alerts concerning the traffic that is discovered
Actually intercept and block this traffic

intrusion detection applications (again) also do

signature-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. and
anomaly-based detection: 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.

After dealing with a post-mortem on a compromised system, it’s amazing how helpful a Snort NIDS can be. On the flip side, it’s also frustrating when your Snort system does not log a possible attack.

Let’s take a possible attack: the IMAP login overflow attack. In this case, an attacker tries a buffer overflow to cause a remote root exploit. Snort can let you know that someone is sending an IMAP packet that contains the signature of an IMAP login overflow. Depending on how you have Snort set up, you can either monitor the output or you can be notified by e-mail. Great, now you can yank the Ethernet cable from the wall and look at the corpse 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;)

This rule checks for any packet originating from the external network (defined by EXTERNAL_NET variable) to any system on the internal network (defined by HOME_NET) to port 143, which is the IMAP port.
The msg variable defines what is sent to the Snort alert, and
the rest of the information of the packet is content based. There are definitions on the type of attack (misc-attack), the SID number (1993), and the Bugtraq reference on the attack 6298.

Then, there’s the flip side: Snort does not detect an attack on your system. Take another UNIX system you have running. This one is running Apache with FrontPage extensions (gasp!). Someone finds a new overflow on FrontPage for which say there is no Snort rule yet, and then he has your box. Not to mention, your security solution did not provide any assistance with the attack.

Snort’s Uses
Snort has three major uses:

A packet sniffer
A packet logger
A NIDS

All the uses relate to each other in a way that builds on each other.

However, it’s easiest to put the packet sniffer and the packet logger together in the same category—basically, it’s the same functionality. The difference is that with the logging functionality; you can save the packets into a file. Conversely, you can read the packet logs with Snort as well.

Using Snort as a Packet Sniffer and Logger
In its simplest form, Snort is a packet sniffer. That said, it’s the easiest way to start.
The command-line interface for packet sniffing is very easy to remember:

# snort –d –e -v

-v Put Snort in packet sniffing mode (TCP headers only)
-d Include all network layer headers (TCP, UDP, and ICMP)
-e Include the data link layer headers

Note that the -v option is required. If you run Snort on a command line without any options, it looks for the configuration file (.snortrc) in your home directory or snort.conf in /etc/snort.

You cannot use options –d and –e together without also using the –v option.
If you do, you get the same output if you use snort without any options:

root@harrykar-desktop:~# snort -de

,,_     -*> Snort! <*-  o"  )~   Version 2.8.4.1 (Build 38)    ''''    By Martin Roesch & The Snort Team: http://www.snort.org/team.html           Copyright (C) 1998-2009 Sourcefire, Inc., et al.           Using PCRE version: 7.8 2008-09-05  USAGE: snort [-options] 
Options:
......

ERROR:

Uh, you need to tell me to do something...

Fatal Error, Quitting..
root@harrykar-desktop:~#

Now, if you run snort with the –v option, you get this:

root@harrykar-desktop:~# snort -v
Running in packet dump mode

--== Initializing Snort ==--
Initializing Output Plugins!
Verifying Preprocessor Configurations!
***
*** interface device lookup found: eth0
***

Initializing Network Interface eth0
Decoding Ethernet on interface eth0

--== Initialization Complete ==--

,,_     -*> Snort! <*-  o"  )~   Version 2.8.4.1 (Build 38)    ''''    By Martin Roesch & The Snort Team: http://www.snort.org/team.html           Copyright (C) 1998-2009 Sourcefire, Inc., et al.           Using PCRE version: 7.8 2008-09-05  Not Using PCAP_FRAMES 06/09-13:30:55.228573 192.168.1.2:58815 -> 66.102.9.147:80
TCP TTL:64 TOS:0x8 ID:20939 IpLen:20 DgmLen:40 DF
***A**** Seq: 0x96F25316  Ack: 0xB24A55D7  Win: 0xFFFF  TcpLen: 20
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/09-13:30:55.266316 66.102.9.147:80 -> 192.168.1.2:58815
TCP TTL:48 TOS:0x0 ID:13577 IpLen:20 DgmLen:1470
***A**** Seq: 0xB24AD651  Ack: 0x96F25316  Win: 0xF7BF  TcpLen: 20
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/09-13:30:55.266432 192.168.1.2:58815 -> 66.102.9.147:80
TCP TTL:64 TOS:0x8 ID:20940 IpLen:20 DgmLen:40 DF
***A**** Seq: 0x96F25316  Ack: 0xB24A55D7  Win: 0xFFFF  TcpLen: 20
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/09-13:30:55.267759 66.102.9.147:80 -> 192.168.1.2:58815
TCP TTL:48 TOS:0x0 ID:13578 IpLen:20 DgmLen:1470
***A**** Seq: 0xB24ADBE7  Ack: 0x96F25316  Win: 0xF7BF  TcpLen: 20
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/09-13:30:55.267853 192.168.1.2:58815 -> 66.102.9.147:80
TCP TTL:64 TOS:0x8 ID:20941 IpLen:20 DgmLen:40 DF
***A**** Seq: 0x96F25316  Ack: 0xB24A55D7  Win: 0xFFFF  TcpLen: 20
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/09-13:30:55.269458 66.102.9.147:80 -> 192.168.1.2:58815
TCP TTL:48 TOS:0x0 ID:13579 IpLen:20 DgmLen:1470
***A**** Seq: 0xB24AE17D  Ack: 0x96F25316  Win: 0xF7BF  TcpLen: 20
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

.....etc.....
.............

^C*** Caught Int-Signal
Run time prior to being shutdown was 1.513692 seconds
===============================================================================
Packet Wire Totals:
Received:            1
Analyzed:            0 (0.000%)
Dropped:            0 (0.000%)
Outstanding:            1 (100.000%)
===============================================================================
Breakdown by protocol (includes rebuilt packets):
ETH: 0          (0.000%)
ETHdisc: 0          (0.000%)
VLAN: 0          (0.000%)
IPV6: 0          (0.000%)
IP6 EXT: 0          (0.000%)
IP6opts: 0          (0.000%)
IP6disc: 0          (0.000%)
IP4: 0          (0.000%)
IP4disc: 0          (0.000%)
TCP 6: 0          (0.000%)
UDP 6: 0          (0.000%)
ICMP6: 0          (0.000%)
ICMP-IP: 0          (0.000%)
TCP: 0          (0.000%)
UDP: 0          (0.000%)
ICMP: 0          (0.000%)
TCPdisc: 0          (0.000%)
UDPdisc: 0          (0.000%)
ICMPdis: 0          (0.000%)
FRAG: 0          (0.000%)
FRAG 6: 0          (0.000%)
ARP: 0          (0.000%)
EAPOL: 0          (0.000%)
ETHLOOP: 0          (0.000%)
IPX: 0          (0.000%)
OTHER: 0          (0.000%)
DISCARD: 0          (0.000%)
InvChkSum: 0          (0.000%)
S5 G 1: 0          (0.000%)
S5 G 2: 0          (0.000%)
Total: 0
===============================================================================
Action Stats:
ALERTS: 0
LOGGED: 0
PASSED: 0
===============================================================================
Snort exiting
root@harrykar-desktop:~#

After a while, the text scrolls off your screen. Once you press Ctrl-C, you get an output summary that summarizes the packets that Snort picked up, by network type (TCP, UDP, ICMP, IPX), data link information (including ARP), wireless packets, and any packet fragments.

Since this isn’t very useful for checking the data of the packets, we’ll run snort with the –dev option to give us the most information

If you’ve used TCPDump before, you will see that Snort’s output in this mode looks very similar. It looks very typical of a packet sniffer in general.

{date}-{time} {source-hw-address} -> {dest-hw-address} {type}
{length} {source-ip-address:port} -> {destination-ip-address:port}
{protocol} {TTL} {TOS} {ID} {IP-length} {datagram-length} {payload-length} {hex-dump} {ASCII-dump}

This is all great information you’re gathering, and Snort can collect it into a file as well as display it to standard output. Snort has built-in packet logging mechanisms that you can use to

collect the data as a file,
sort it into directories, or
store the data as a binary file.

To use the packet logging features, the command format is simple:

# snort -dev -l {logging-directory} -h {home-subnet-slash-notation}

If you wanted to log the data into the directory /var/adm/snort/logs with the home subnet 10.1.0.0/24, you would use the following:

# snort -dev -l /var/adm/snort/logs -h 10.1.0.0/24

However, if you log the data in binary format, you don’t need all the options. The binary format is also known as the TCPDump formatted data file. Several packet sniffers use the TCPDump data format, including Snort. The binary format for Snort makes the packet collection much faster because Snort doesn’t have to translate the data into a human readable format immediately. You only need two options: the binary log file option -L and the binary option -b. For binary packet logging, just run the following:

# snort -b -L {log-file}

For each log file, Snort appends a timestamp to the specified filename. Now, how do you read it? What you need to do is parse it back through Snort with filtering options. You also have the option to look at the data through TCPDump and Ethereal, as they use the same type of format for the data.

# snort [-d|e] -r {log-file} [tcp|udp|icmp]

The last item on the line inside [] is optional if you want to filter the packets based on packet type (for example,TCP). To take further advantage of Snort’s packet logging features, you can use Snort in conjunction with the Berkeley Packet Filter (BPF).

# snort –vd –r

The BPF allows packets to be filtered at the kernel level. This can optimize
performance of network sniffers and loggers by eliminating packets with the best
performance because it happens at such a low level in the operating system.
The following are some examples of BPF filters. They are commonly used for ignoring packets, and work with expressions (and, or, not). If you want to ignore all traffic to one IP address:

# snort -vd -r  not host 10.1.1.254

If you want to ignore all traffic from the 10.1.1.0 network to destination
port 80:

# snort -vd -r  src net 10.1.1 and dst port 80

If you want to ignore all traffic coming from host 10.1.1.20 on port 22:

# snort -vd -r  not host 10.1.1.20 and src port 22

Using Snort as an NIDS
Now that you understand the basic options of Snort, you can see where the IDS comes into play. To make Snort an IDS, just add one thing to the packet logging function: the configuration file.

# snort -dev -l /var/adm/snort/logs -h 10.1.0.0/24 -c /root/mysnort.conf

Your rules are in the configuration file, and they are what trigger the alerts.

Fitting In Snort

Before you start your Snort install, decide what you are protecting:

A single server
A group of systems
An entire subnet

Once you know what part of your network you want to monitor, your decision on where to place your Snort monitor practically is made for you.

Network-Based IDS

Why run Snort on a single host? The following examples are perfectly good instances of when to run Snort on a single system, because both are examples of the smallest of networks: a single host.

Your single host is a Web server locked up in a far-away cabinet in someone else’s data center. You might not want to pay the extra money for another couple units of rack-space just for a dedicated Snort system.
You’re a wireless java junkie with your own chair at the local Wi-Fi café. You might consider running Snort on your laptop to see when someone decides to — ahem — check your laptop for the latest system patch.

Once you start worrying about monitoring more than one host, you must decide whether you want to

Run Snort on each of those hosts
Run a single dedicated Snort system to watch an entire chunk of your network.

With the amount of work involved in installing and maintaining Snort, you get more bang for your buck with a dedicated Snort sensor to watch entire sections of your network.

Snort isn’t useless for monitoring a single host. But Snort only looks for attacks in network traffic. This puts Snort in the NIDS camp, regardless of whether you monitor a single host or an entire network with Snort. Snort started its life as a juiced-up version of tcpdump, the ubiquitous packet capture agent that takes raw data straight off the wire, and was enhanced to compare that data to a list of known attack patterns, alerting you when traffic patterns match attack patterns. In a nutshell, that’s what Snort does, and that’s what it does best.

NOTE---Snort can be run on a single host, configured to watch only the network traffic that is relevant to that host. This myopic monitoring does not make Snort a HIDS.
Imagine a Snort sensor that runs on the host it’s meant to monitor; that sensor only sees network traffic for that particular host. Now imagine the following scenarios: One of your admins creates a privileged account for use after he turns in his letter of resignation; an unused account for a user on a lengthy sabbatical is suddenly active again; your company’s top-secret plans are copied to a floppy disk and taken off-site; or your login program is replaced with a keystroke logger. Snort can’t detect any of these attacks while running on a single server because these attacks either happen at the console, or abuse existing privileges and don’t occur over the network directed at network services. Snort would not see any traffic that indicates an attack.

Exposing Snort to more of your network results in it watching more network traffic. The default setting in your snort.conf file is to define var HOME_NET any. This tells Snort to watch any traffic that whizzes past it and look for attacks, so getting Snort to monitor more of your network can be as simple as exposing it to more network traffic.

Finding a home for your Snort sensor
So, how do you make Snort as useful as possible? You put the Snort system(s) on your network where it will be most usefulness. Where this is depends on several factors:

how big your network is, and
how much money you can get your management to spend on Snort systems.

If you cannot get enough money to acquire enough Snort systems to achieve the optimal designs shown in Figure, you’ll need to see what you can use from a practical sense. If you need to limit your spending, forego the system inside the router and just make sure you have the Snort systems inside the subnets you want to protect.

Many network administrators set up a screening router. This enables the router to act as a poor-man’s firewall and stop packets at the network level, usually by their well-known ports. The problem with this is that many packets can be rerouted through other ports.

However, if a packet gets past your screening router, this might be a good place to put your IDS. This enables you to detect what you deem as attacks while
enabling some filtering to hopefully catch some of the problems with the router. In this case, you would want to put an IDS system on the inside of your firewall and another in between your outside router and your firewall. Here we’re also assuming that your router is filtering some traffic through the access lists as
well. You do not want your Snort system on the outside of your network because it will increase your false positive rate, and it leaves your Snort system more vulnerable to attack. Most important is the Snort

system inside your firewall. This is the one you should monitor frequently for attacks. This system should only trigger alerts from possible legitimate attacks, and produce much fewer false alerts, or a false positive. However, the Snort system in between your router and your firewall will also provide you with useful information—especially for a postmortem on a compromised system.

However, many network architectures do have a Demilitarized Zone (DMZ) for providing public services such as Web servers, FTP servers, and application servers. DMZs can also be used for an extranet (which is a semi-trusted connection to another organization), but we’ll stick to the public server DMZ architecture in this example. In this case, you would want three Snort systems:

---one inside the router,
---one inside the DMZ, and
---one inside the firewall.

The reason for the additional IDS machine is because you have an additional subnet to defend. Therefore, a good rule of thumb for an optimal situation for your Snort systems is:

One inside the router
One inside each subnet you want to protect

If you set up a Snort sensor as a dedicated NIDS, have it watch as much traffic as it can handle at one time. Why watch a single server, when you can monitor every host on your DMZ? Snort puts by default a network card in promiscuous mode, so it watches all network traffic that flies by. You can edit your snort.conf file to limit what you want Snort to react to, but the network card grabs every packet it can. The key to making Snort watch more of a network is letting it see more of that network. After all, the better you look, the more you see.

Switches, repeaters, and hubs
For a Snort user, there’s one important difference between hubs (or repeaters) and switches:

Hubs repeat data to every port. With hubs, a network card in promiscuous mode easily watches other people’s network traffic (because everyone’s packets already go to everyone else).
Switches only send data to the port where that data’s ultimate destination lies. A switch knows which MAC address is on each port. It takes data that comes in on a port (or ports) and spits it back out on another port (or ports). A switch provides you with Layer 2 (Data Link layer of the OSI seven layer model) configurability, including virtual LANs (VLANs), which allows you to subnet directly at the switch. Switches have also been used as overpriced routers. In this case, you’ll want to save your money if you’re not using your switch’s features. A switch reduces the total traffic on the network by only sending data destined for a particular device’s MAC address to the switch port that device is plugged in to.

A switch’s ability to forward traffic only to devices that the traffic is destined for means that switches are much better performers and are more scalable than hubs in a LAN.

The other side of that coin (regarding our stuff here), however, is that traffic not destined for a particular device is hidden from that device. Since your Snort box is just another device plugged into the switch, this presents a problem: If you want to monitor the entire network’s conversations, you want to be able to listen to all of conversations at once. This is easy with a hub, but difficult with a switch. Most modern switches can designate a specific port as a monitoring port. The monitoring port can watch all traffic between any port (or group of ports) on your switch. On some switches, such as Cisco switches, the monitoring port is called a Switch Port ANalyser (SPAN) port. The Snort system then takes “copies” of the packets to be analyzed. In this case, you’ll have to decide which other ports on your switch you want to monitor with the SPAN port. Usually, you will monitor just one port; otherwise, you can flood the SPAN port. This might kill the performance of both your switch and your IDS.

Consult your switch’s documentation to set up a monitoring or SPAN port. Some switches can’t be configured with a monitoring port. Those little eightport switches that cost $100 a few years ago are a good example. If your switch can’t designate a monitoring port, consider either

Using a hub to repeat the traffic that you want to monitor
Replacing your switch with one that allows you to designate a monitoring port

Location
What Snort monitors depends on where it is on your network. A typical network uses a firewall to split Internet facing servers into a DMZ, and keeps end-user workstations and internal servers in a NAT network.

A DMZ (De-Militarized Zone) network is a kind of limbo, a neither here nor there zone that has tight controls on what network traffic goes in and what comes out. Traditionally, it’s a semi-trusted network where publicly facing Internet servers reside.
NAT stands for Network Address Translation, a way to hide multiple machines using private IP space behind a much smaller chunk of public IP space. With NAT, your end-user workstations and internal file servers can initiate outgoing Internet connections, but other hosts on the Internet can’t initiate connections the other way.

Keeping servers in a DMZ keeps your NAT network secure. If one of your Internet-facing servers in your DMZ is cracked, the damage should be limited because the hacker can’t get out of the DMZ to your internal network.

Covering your assets
If your network is for a business or other organization that uses the Internet, network Internet access probably is critical to your business operating smoothly. Even e-mail can be vital to day-to-day operations, so keeping these servers safe is key. If you have publicly facing Internet servers in a DMZ, watch here for trouble: Internet access to your servers means that you can tell the entire world about www.yoursite.com, but the entire world can poke, prod, and tickle your servers, too.

Any place you have publicly facing Internet servers is a place for Snort. If you use a separate DMZ network, you must do the following:

Designate a port on your DMZ switch as a monitoring port.
Tell your snort.conf file that you want to monitor this subnet.

After watching this traffic for a while, you start to see alerts for Web server attacks and attempts to squeeze your servers for network information. Keep an eye on Snort’s alerts and start trimming your configuration to reduce false positives .

Monitoring your DMZ alerts you when someone attacks a server and tells you whether an already compromised server is attacking other servers in the DMZ. This information is critical to network forensics .

Seeing who isn’t on the guest list
In almost every case, you should monitor unfiltered Internet traffic. This traffic is directed at your network, but hasn’t had a chance to be rejected by your firewall.

Though most bad traffic gets the boot from your firewall and never touches the protected parts of your network, it’s nice to see that traffic is.

If your boss ever wants stats on how well your firewall is doing its job, this is one great resource.

Figure upstairs shows a switch in between the router and firewall. Although this isn’t necessary, it’s usually helpful to have unfiltered IP space for network troubleshooting. If there’s a switch in front of your firewall, but you can’t designate a monitoring port on it, throw a hub between your router and switch. This lets you plug your Snort sensor in front of the firewall; for many sites, it won’t introduce any bottlenecks. (A T1 line is only 1.54 Mbps, and even the cheapest hub handles 10 Mbps. Another proportion is: today lines reaches 20-50Mbps and a hub handles easy 100Mbps) If you monitor unfiltered Internet traffic, you see a lot of alerts. You should see a slew of such attack alerts as

Port scans that never make it past your firewall
Random worm activity directed at hosts that don’t exist

This data is proof that your firewall is doing its job.

Keeping tabs on the inside
Although it seems logical that you’d want to use Snort to monitor your internal NAT network filled with end-users and file servers, we don’t recommend it until you’ve gained some experience scaling and tuning your Snort system for a couple of reasons:

Bandwidth: Internal LANs typically run at 100 Mbps (now also Gbps) to ensure fast access to internal file servers or databases. Compare this to the size of the pipe from the Internet to your DMZ. If every host on your internal network has a 100 Mbps dedicated pipe (thanks to the magic of modern switches, this is now the norm), your Snort system must watch a lot of traffic at once. This is possible with Gigabit Ethernet interfaces and systems with really fast processors, but your super-fast Snort system may be pushed to its limits.
False positive alerts: Snort has a built-in notion of us VS them, which is most evident in the snort.conf settings var HOME_NET, and var EXTERNAL_NET. Snort has a very hard time correctly differentiating between legitimate internal network traffic and hostile attacks. You can get around this by setting both variables to any, but it doesn’t change the fact that Snort is looking for attacks. Snorts default set of rules assumes that your HOME_NET needs to be protected from your EXTERNAL_NET.

If your system can handle watching the big bandwidth of a LAN, Snort is your best friend for monitoring internal LAN traffic. Watching internal LAN traffic can be a great way to make sure that your users are sticking to the network policy if you have

A high-performance Snort sensor with CPU cycles and RAM/disk to spare
A highly tuned rule set

Your highly tuned rule set should include rules that you develop yourself. You can write rules to alert you if you start seeing HTTP traffic coming from anything that isn’t
a sanctioned Web server. Or consider a rule to watch for spyware trying to phone home from your internal LAN.

Pitfalls When Running Snort
Snort is a wonderful tool; however, like all tools, it has its pitfalls. Snort has three major pitfalls:

Not picking up all the packets :Snort might not pick up all packets because of the speed of the network and the speed of the promiscuous interface. This can also be dependent on the network stack implementation of the operating system.
False positive alerts :False positives are when Snort gives you a warning when it shouldn’t. Basically, a false positive is a false alarm. If you go with a default ruleset with Snort, then you will definitely get many false alarms. This can trigger a lot of alerts until you decide what is relevant to your network. The more open your network is, the more alarms you’ll want to monitor.
False negative alerts : On the opposite end, you can get false negatives. In other words, someone compromises a Snort-monitored system and your Snort system doesn’t detect it. You might think that this doesn’t happen, but when you get an e-mail from another system administrator describing a suspicious activity and your Snort system didn’t pick it up, well, this is a very real scenario. Make sure you keep your Snort rulesets up to date, and your expectations on what you expect from your Snort system

Upgrading Snort
Upgrading Snort can be quite painful for two reasons:

the ruleset syntax might change, and the interface to the alert logs. We have found both to be obstacles when trying to upgrade Snort systems, and can be quite a pain to deal with.
Additionally, Snort has changed its architecture with Snort 2.0 to increase performance and hopefully make the rulesets easier to handle. However, it will also mean a possible painful upgrade to make sure that Snort still can read your custom rulesets and use your alert interface.

Security Considerations with Snort
Even though you are using Snort to improve your security, making sure that your Snort system is as secure as possible will make the data trustworthy. If someone breaks into your Snort system, there is no reason to trust the alerts it sends, thereby making the system completely useless until after you wipe the disks and reinstall verything.

Snort Is Susceptible to Attacks
With that said, a typical Snort installation is subject to attacks. Why? You’ll want to

get in remotely (SSH) and
you’ll probably want to store the alerts in a database (MySQL or Postgres).
In addition, you’ll probably want to view the alerts with a spiffy interface that might require a Web server (Apache or IIS).

This makes your Snort system just like any other application, so stay on top of security vulnerability announcements and OS security announcements. Now, based on this information, you have several ports open on your Snort system: SSH (port 22), HTTP (port 80), HTTPS (port 443), and possibly MySQL (port 3306) or Postgres (port 5432). Now, anyone with access to a network can use NMAP and portscan your sniffer directly on its nonpromiscuous interface.

This is something that needs to be addressed because all of the preceding applications have had quite a few serious security issues, even as recently (2002 here). In addition to making sure that your applications are up to date, you need to make sure that your kernel is configured properly and also up to date. You didn’t think that running Snort allows you to disregard basic system administration practices, did you?

Snort, however, has very few in its few years of existence. It’s nice
to see a security application practice good security. The Snort core has
never had a network-based vulnerability, excluding a DoS attack if Snort
was configured in a nonstandard manner. Third party plug-ins can be
vulnerable, but they aren’t part of the Snort core, which helps keep
Snort itself secure.

Inviting More Pigs to the Party

So you want to monitor your network everywhere; you need Snort sensors in front of your firewall, behind your firewall, next to your firewall, in your DMZ, in your NAT network etc. Sound paranoid? You bet! But no two sites have the same monitoring requirements. Fortunately, Snort is modular and scalable. It’s relatively easy to deploy an army of Snort sensors, though a small squad may be more appropriate. You may be tempted to place a single Snort sensor on your network and put an armful of different subnets in your var HOME_NET variable. If Snort can see traffic on all of those subnets, it might be a good idea (if your system has the CPU and RAM/disk to keep up).

But most network architectures are so complicated that seeing network traffic for different subnets requires a different sensor for each subnet. If you watch different subnets, you must use a different network interface to listen to each subnet. This can mean either

Running separate sensors for each subnet
Putting multiple NICs in a single Snort host

A single, all-seeing Snort sensor
If you have more than one NIC (Network Interface Card) in a single Snort system, you can use the -i command line switch to control which interface to listen on. Versions of the libpcap library running on Linux kernels 2.2.x and higher let you listen to all interfaces at once using -i any. (In the old days, that required running a separate instance of Snort for each subnet you wanted to monitor.)

We don’t recommend listening on all interfaces at once. Once you start running Snort, it needs some fine-tuning. Some rules may be appropriate for your DMZ network, and some may be more appropriate for watching unfiltered Internet traffic. You might even want to run some preprocessors on one network, but not on another. Soon you realize that you want Snort custom-tailored for your network, but covering different subnets using the same configuration is more of a one-size-fits-all deployment.

NOTE---The Windows WinPcap library actually can’t watch multiple interfaces at once, so running Snort on Windows with multiple network interfaces means running multiple instances of Snort.

Single processor host
If your single processor Snort system has enough CPU power, you can run multiple
instances of Snort at once on the same CPU. Running multiple instances of Snort on your single-CPU system gives you the following benefits:

Reducing the number of individual machines running Snort eases management.
Multiple instances of the same running program are a cheap and dirty way to multi-thread.

Dual processor host
If you have a dual processor system, a different instance of Snort can run on each processor. This can be a lifesaver: If one part of your network is under an unusually heavy load, it won’t reduce the performance of the other Snort process. Figure upstairs shows two instances of Snort watching two different subnets, all running on the same server.

Multiple Network Interface Cards
Monitoring multiple subnets means running Snort with multiple Network Interface Cards (NICs). Although Snort can monitor all NICs at once in some installations, we recommend running a different instance of Snort for each NIC so you can customize Snort’s configuration for each subnet you monitor.

Adding more NICs to your Snort system shouldn’t be hard if your Operating System supports the hardware; you’ll be limited by the number of expansion cards your motherboard can handle. If you go hog-wild with your Snort install, and you run out of places to stick NICs, consider using a NIC with multiple interfaces on the card. Some PCI cards can have as many as four or more interfaces. When using multiple NICs to monitor different subnets, make sure that these NICs don’t have an IP address. If you run Snort on a headless server somewhere (headless means “no monitor”, not “no cranium”), you need one IP address for access via SSH or log forwarding over syslog or MySQL. If you’re really paranoid, you can run Snort on a system with a monitor and no IP address at all, although this severely limits Snort’s scalability.

Eyes and ears everywhere
Although running a single Snort host with multiple NICs and multiple instances of Snort is a viable solution, your network may be expansive enough that this isn’t feasible. This certainly is the case if your network has multiple physical locations. In this case, multiple Snort sensors with centralized logging are for you.

Adding Snort sensors to your network just entails setting up more hosts running Snort. For easier management, send the output from all of these sensors to the same place. This is done with the output module in your snort.conf file. Often, multiple sensors send their output to the same logging server or database server. Scaling your Snort installation across multiple hosts, multiple subnets, or multiple physical sites is a daunting affair.

Figure 2-2 shows a typical network configuration where we see the following separation of duties within our Snort architecture:

Separate Snort sensors watching different parts of a network. The dashed lines from Snort sensors to switches or hubs are un-addressed NICs that are monitoring traffic. Solid lines from Snort sensors to the NAT network are connections to addressed NICs for remote access.
A separate database server (holding our Snort alerts) and Snort ACID console running on its own Web server.

TIP1nort’s scalability makes it easy to run each sensor, log database, or console on a dedicated machine. This N-tier architecture makes your Snort system more configurable, stable, and scalable as your network grows.

TIP2: A passive Ethernet tap can hide your sensor completely from the rest of your network. You cut wires used for sending data, so you can monitor network traffic without alerting other systems of your presence. The wizards at snort.org offer a tutorial on constructing your own passive Ethernet tap. Take a spin over here for the lowdown.

Comparison of OS's & Hardware requirements for Snort

Choosing Your Operating System
Snort is distributed both as source code (which you can compile yourself) and as binary files that are pre-compiled for you.

The source code can be compiled for a number of platforms — including Linux, OpenBSD, FreeBSD, Solaris, Tru64, AIX, MacOS X and Windows. There are no known problems running Snort on any post-2000 version of Windows. Open-source tools such as Snort are not just the domain of Unix and Unix-ish operating systems anymore. Of course, actually compiling Snort on Windows is a daunting task — not recommended — but that’s where the Snort executable binaries come in handy.

Pre-compiled binaries (for Linux and Windows only) are available from the snort.org Web site. The Linux binaries are distributed in the RPM package format(but not in deb format), commonly used with RedHat Linux, the Fedora Project (a community supported RedHat Linux spin-off), and Mandrake Linux. The Windows binaries are simply EXE files. For Linux, compiling from source is the recommended method of installation. For Windows, the binary is the best way to install.

Snort runs on various operating systems, each with its advantages and disadvantages.

We would like to be able to maintain it remotely and securely. For Linux and UNIX, this means including Secure Shell (SSH) and Apache with Secure Sockets Layer (SSL). For Windows, this would mean Terminal Services (with limitation on which users and machines can connect, and Internet Information Servers [IIS]).

Running Linux: The pig digs the penguin
The Linux operating system is an extremely cool platform for running Snort. We recommend you use a modern Linux distribution that uses version 2.4 or newer of the Linux kernel. Linux Kernel version 2.4 gives you performance and security advantages over the older kernels. Linux Kernel 2.6, released in late December 2003, offers even better scalability, improved I/O performance, and support for high-end processors such as the AMD 64-bit Opteron etc.
Linux’s advantages as a Snort IDS sensor can be summed up in four Ps:

performance
pruning
patching and
price

The penguin is a top performer
The Linux TCP/IP stack (especially in the version 2.4 series and newer of Linux kernels) is excellent at handling the large amounts of data that pass through a Snort IDS network interface. Most sysadmins seem to know intuitively that Linux is a much better performer as a Web server. For example, a study at IBM’s Watson Research Center found that Linux could handle TCP/IP 21% faster than Windows 2000.

Pruning Windows versus pruning the penguin

The standard Windows installation brings with it (from Snort’s point of view) some unneeded bells and whistles — chief amongst them the Explorer graphical user interface (GUI) and numerous GUI applications such as Notepad, WordPad, and HyperTerminal. Are any of these required for Snort’s day-today functions? Certainly no one. The GUI takes up memory and CPU cycles just to run (not to mention the hard-drive space it uses). Even though you can remove some of the built-in Windows applications, there’s no way you’re getting rid of the GUI (after all, that’s what makes Windows Windows, right?)

With Linux you don’t need to run — or even install — a GUI, and you can keep applications that aren’t Snort-related down to a minimum. And Linux doesn’t throw a tantrum if you take away some of its toys. You can run it as bare-bones as you wish, streamlining it into a fast, lean machine.

Practically painless penguin patching
Because your Snort IDS is a critical part of your security infrastructure, you don’t want it to be down very often — and when it is down, not for long. There is what amounts to a holy war over which operating system is more secure, Linux or Windows. If you want drama, just check out Slashdot on any given week for the latest Linux versus Windows rants. The truth of the matter is that an improperly configured or un-patched Linux system is just as insecure as an improperly configured or un-patched Windows system.

There is a definite difference, however, in the ways Windows and Linux systems are patched. Many Windows systems administrators know the pain of having to reboot their machine after each new Service Pack or Hotfix. This downtime means a bleary-eyed sysadmin has to perform this update during an after-hours “maintenance window” (usually in the wee hours of the morning or on weekend). It also leaves you without your Snort system for several minutes (a computer eternity) while you shut the system down, wait for it to reboot, and make sure all services come back up unscathed. Now, with Microsoft taking the useful (if not always welcome) initiative of fixing security holes and releasing patches on a monthly basis, you’re almost guaranteed the pleasure of rebooting at least once per month. If you use Linux, unless there’s a critical kernel patch (rare, but not unheard of), you never need to reboot after a patch.

Downtime is a big deal for IDS's. That fifteen minutes (or more) of upgrade downtime could be the window of opportunity an attacker needs to exploit a security hole and get by undetected. It is unrealistic to never expect any downtime for upgrades, but for security’s sake, it’s in your best interest to minimize it as much as possible.

The penguin is costless
The final thing Linux has in its favor is its cost. It’s free, just like Snort itself. Large enterprises need multiple Snort sensors, which means multiple hardware and software deployments. In this case, using a free operating system can save you hundreds (or even thousands) of dollars — if you go about it right.

Pig and Windows

The Snort IDS runs on Microsoft Windows 2000 Professional and Server, XP Professional, and 2003 Server. Because of the way Snort uses the network interface (it just listens and doesn’t make connections), the Professional versions of 2000 and XP work fine (and save you hundreds of dollars in server-licensing costs).

Snort can run on Windows 95, 98, ME, NT, and XP Home — but we don’t recommend it. These versions lack support for higher-end hardware, are less stable, and have poorer security than their newer counterparts. Plus, the Windows 95, 98, and NT versions have reached their end-of-life for both mainstream and extended support — if a security hole is found that affects those versions, you’re out of luck if you want a Hotfix.

Using Windows as your Snort IDS platform is an advantage if Windows is the your organization’s primary supported operating system. You already have the Windows gurus on staff, and have support agreements with Microsoft and other vendors in place. Your Snort IDS is supposed to give you peace of mind; a good comfort level with the operating system you’re running it on contributes to that.

Another advantage to Windows is that easy-to-use Windows GUI. All Windows’ system administration tasks — from partitioning hard drives to creating users — can be performed using point-and-click applications that are the same across Windows systems (though not always exactly the same across versions of Windows). Similar tasks under Linux either require command-line operations or GUI applications that vary depending on if you run the KDE desktop, Gnome desktop, or some other Linux desktop environment.

So which operating system choose?

If you’re choosing on purely technical merit, we recommend that you run your Snort IDS on Linux. Linux systems are fast, typically have little downtime, and are very flexible and highly configurable. It’s a reliable, Swiss-Armyknife OS with a whole slew of blade options — and you can remove the blades you don’t need! In the sometimes-Byzantine world of information technology, however, not all decisions are based on purely technical criteria. If you’re more comfortable with Windows and you’re not ready to jump into supporting a Linux system, then Windows is the most practical choice.

If you choose to run your Snort IDS on Windows rather than on Linux, you’re not at a functional disadvantage! Snort has the same features on both platforms.

Sizing Up Your System

How big a computer system you need for your Snort IDS is the most difficult question to answer. It’s never a one-size-fits-all situation. What you need for running Snort depends on some variables:

The speed of your network (10 Mbps, 100 Mbps, 1000 Mbps, and so on). By and large, faster is better.
The amount of data that passes through your network during its peak. The bigger the number, the faster the system you’re likely to need.
How long you want to keep your Snort logs and alerts. The longer you keep ’em, the more space you need to store ’em.
What other services you want to run on the system (Web, PHP, MySQL, and so on). Services usually have an appetite for system resources.
How much money you can spend on hardware, software, and associated support contracts. Shoe string budgets can really stunt system size.

Yes, Snort itself is free, but you’re not going to get through this without opening the wallet a little. As you can see those variables can be quite variable from network to network and organization to organization. That’s why the Snort documentation and mailing lists are peppered with qualifying phrases about hardware requirements — “it depends,” “more is better,” and what not — even from Snort developers themselves. No cop-out, just practicality: It truly does depend on your particular needs, and more is definitely better — if you can get it. In the meantime, a few guidelines can help you choose the hardware that fits your current situation . . .

Keep the packets flowing
Snort’s job is to listen to your TCP/IP network traffic and look for signatures in the data flow that might indicate a security threat to your network and your computer systems. It has to look at anywhere between 1 to 100 or more megabytes of traffic going across the network wire every second — which means that anything that slows down your computer system also thwarts Snort’s ability to process the packets it sees.

If your hardware can’t keep up with the flow of network data packets coming across your network interface, then Snort can’t keep up. An overloaded system ends up dropping packets — and a packet dropped is a packet not analyzed for security threats — which means an attack might get in right under Snort’s nose. Net effect: Your Snort IDS system might as well be completely down.

Looking at hardware options
To keep your Snort IDS from dropping network data packets, speed is the single most important factor. One approach is to evidence a number of hardware-related bottlenecks that can occur with a Snort IDS sensor. Choosing hardware that best fits your scenario helps to keep those bottlenecks to a minimum, and network data packets under control.

Processor requirements
Examining the traffic passing through your Snort sensor takes considerable processor (CPU) speed. Also, the more preprocessors (Snort modules that sort the packets before the Snort detection engine looks at them) you’re running, the faster it needs to be.

Snort sensors that are looking at slow network speeds of 10 Mbps or less (such as a broadband or T1 connection) can get by with a budget CPU, such as a Intel Celeron or AMD Duron.
Sensors that are looking at 100 Mbps networks need at least Pentium III or Athlon processors.
A sensor watching a gigabit network needs at least a Pentium IV or Athlon XP.

The next-generation 64-bit CPUs might also be worth looking at as operating systems, compilers, and applications are written to take advantage of these processors’ capabilities. The two high level 64-bit CPUs on the market right now are Intel’s Itanium and AMD’s Opteron. Adding an extra CPU can also help. Linux, Windows 2000 Professional and Server, Windows XP Professional, and Windows 2003 Server all have Symmetric Multi-Processing (SMP) capabilities, which means they can take advantage of systems having two or more CPUs. Snort can have a processor all to itself, and leaves the other chips for other applications.

The newest Pentium IVs can also do something called Hyper-Threading, which makes a single processor behave like two processors to the OS. Windows XP, Windows 2003, and Linux Kernel 2.6 systems are especially good at taking advantage of Hyper-Threading. Hyper-Threading is a good way to get some of the advantages of a multi-processor system without the cost of adding an extra processor.

Also take into consideration what other applications you’re running besides Snort. Running a Web server, MySQL database management system, PHP server-side scripting language, and the ACID Web-based reporting console for Snort adds some overhead — especially when you’re running queries against the database to generate reports. This is a case where the dual-processor system helps. Barring that, beef up your system requirements to handle this extra load. For instance, where you may have been able to get by with a Celeron on a 10-Mbps network, the extra overhead from the additional software means you need at least a Pentium III.

Memory requirements
When we talk about memory requirements, we’re talking about actual, physical RAM chips — not mere hard-drive storage. Although (at first glance) memory may not seem such a big deal for something input/output-intensive like Snort, where its job is to suck in the network traffic, analyze it, and then spit out alerts. In reality, however, the bulk of Snort’s work is done in memory, where it buffers the network data while analyzing it. In short: The more (and faster) memory you have, the better.

Why is memory so important? Running out of RAM severely affects the performance
of your Snort IDS and can cause it to drop network data packets. When a computer system runs out of physical RAM, it starts using storage space set aside on the hard drive that acts like virtual RAM. On Linux systems this is referred to as swap space (because it’s swapping pages of memory between RAM and hard drive), and on Windows systems this is referred to as Virtual Memory (which you set via the System control-panel applet). Hard drive access is much slower than physical RAM access, so when a system starts “swapping” it slows down the entire computer, and Snort won’t have a chance to pick up and analyze every network data packet that comes in.

For Linux systems, the minimum requirement for running a Snort IDS system is 128 MB of RAM. If you’re running Windows you’re going to need more memory than a Linux system on an equivalent network to handle the overhead of the GUI. On a Windows system, start with no less than 256MB of RAM.

Hard-drive storage and speed
One of the most important things you’ll need, especially if you’re running Snort in Network-based Intrusion Detection System (NIDS) mode, is a really big hard drive. If you’re storing your data as either syslog files or in a database, you’ll need a lot of space to store all the data that the Snort’s detection engine uses to check for rule violations. . For example, our current setup for a single Snort sensor is a 9GB partition for /var.

A typical Linux installation requires 3 gigabyte of hard-drive space; a typical Windows installation requires 6 gigabytes of hard-drive space — and that’s just for the operating system! Snort requires another 60MB of hard drive space on top of that, just for the software itself. What’s going to chew up most of your disk space, however, is Snort’s logs and alerts. The amount of hard drive space required is going to vary depending on

how much data you’re keeping,
how long you’re keeping it, the amountof data coming into your network.

A good place to start is 30GB of disk space for your database/logging partition, adding more as needed.

Another question is whether you should use IDE/ATA drives or SCSI or recently SATA drives. IDE/ATA SATA drives are common on desktop computers, while SCSI drives are common on high-end servers. Gigabyte-to-gigabyte, IDE/ATA drives are much cheaper than SCSI drives. SCSI hard drive controller cards are also more expensive than IDE/ATA controllers (which these days are often simply built into motherboards).

The benefit of SCSI is in speed. You can get 10,000 and 15,000 revolutions per minute (RPMs) out of SCSI spindles, whereas
IDE/ATA drives top out at 10,000 RPMs.(recently more)
The SCSI bus speed is also faster than IDE/ATA bus speed. In general,SCSI drives perform better than IDE/ATA drives in multi-drive and RAID scenarios,whereas IDE/ATA drives perform better singly.
A relatively new IDE/ATA standard called Serial ATA (SATA) closes some of this gap by offering 150MB/s transfer rates and hot-pluggable drives, while remaining software compatible with the parallel IDE/ATA. SATA uses a new cabling standard, however, so you need SATA-compatible controller cards and hard drives.

If you can afford to spend the extra money for a system with SCSI hard drives, we recommend it. I/O is a big factor when it comes to your Snort IDS keeping up with the millions of packets flying by, and the SCSI speed gives you an advantage over an IDE system. Otherwise, try the new Serial ATA drives and controllers to get SCSI-comparable speeds at lower costs.

RAIDing your Snort IDS
RAID is an acronym for Redundant Array of Independent (or Inexpensive) Disks. It’s a way to use several hard drives in conjunction (as an array) to increase performance or reliability/speed. The industry defines eight RAID implementations (also called RAID Levels), labeled 0 through 7. We recommend the following when it comes to using RAID with your Snort IDS:
Use a hardware-based RAID controller,such as an IDE or SCSI controller card that supports RAID. Although Windows and Linux can both support software-based RAID, the performance lost by saddling the OS with taking care of RAIDing isn’t worth it on a Snort IDS sensor.
Use RAID Level 0 when you want to maximize the amount of available hard-drive space. Level 0 writes data across several hard drives in stripes. This RAID level gives you the fastest performance out of your hard drives — but if one hard drive goes out, you lose all your data! Make sure you back up Level 0 implementations regularly.
Use RAID Level 1 when you have two hard drives of the same size and want to mirror the data between them. That way, if one hard drive crashes, the other can be used as the primary hard drive until the first is replaced. RAID Level 1 does degrade performance somewhat on hard-drive writes, but hard-drive reads are faster than you get with many other RAID levels.
Use RAID Level 5 when you need a high degree of fault tolerance and good performance. If one drive goes out, the system can keep running until it’s replaced. One downside of RAID 5 is that it’s slower in writing to the hard drive than are RAID Levels 0 and 1. Another downside is that one hard drive in your array is essentially unavailable to you for storage because of the amount of space needed to store the parity information that’s used to rebuild a crashed hard drive. In other words, you lose 1/n of your overall storage space to parity information (where n is the number of hard drives in your RAID 5 array). For example, if you have three 120GB hard drives in your RAID 5 array, you really only have 240GB of storage space available. If you have eight 120GB hard drives, you only have 840GB of storage available.
RAID isn’t a requirement for a Snort sensor, but it can help you increase the system’s performance, or make sure it stays up.

Network interface cards
It is best to have at least two network interface cards (NICs) in your Snort IDS
sensor:

One NIC for managing the system remotely (for example, using SSH or a remote desktop tool to get to the system)
One or more NICs for network packet sniffing (which is Snort’s job, after all)

The benefit of having two NICs is twofold:

You can keep your management and sniffing tasks on separate NICs, so one task doesn’t interfere with the other.
You can put the management NIC on a trusted (secured, usually private) network and the sniffing NIC on an untrusted (unsecured, usually public) network. For instance, you can have the management NIC on a trusted internal network behind your firewall, and put the sniffing NIC outside your firewall (in what amounts to a hostile environment). The sniffing NIC isn’t given its own IP address (it doesn’t need one for sniffing), so it’s safe from most network-based attacks.

A too-puny or otherwise mismatched NIC is an invitation to disaster. Use
NICs on your Snort IDS sensor that fit the speed of your network. For
instance, if you’re running a 10-Mbps Ethernet network, use a 10-Mbps or
10/100-Mbps Ethernet NIC. If you’re running a 100-Mbps Ethernet network,
get a 100-Mbps Ethernet NIC. Not only does matching the NIC card speed to your network speed make good sense from the standpoint of ensuring Snort can sniff enough data, but it might help you avoid speed auto-sensing troubles.

If you’re in a high-performance network environment (especially a gigabit network or a 100-Mbps network that is highly utilized), we recommend using a server-class NIC instead of a desktop-class NIC. Server-class NICs can cost twice as much as desktop-class cards — but if the cash is available and your situation warrants the expense, they’re worth considering. Server-class NICs are designed for high performance applications that require a lot of network traffic, such as Snort. In addition, they include such features as encryption offloading and SNMP management — and those come in handy for managing your Snort IDS.

Give Snort the fastest port
say you have a switch that has mostly 100-Mbps Ethernet ports, but also a
couple of gigabit Ethernet ports. Even if you’re primarily using the 100Mbps ports for your systems, connecting your Snort IDS sensor to a gigabit port gives Snort a bigger straw to suck on while sniffing the network.

Other Software
Once you have the basic OS installed, you’re ready to go. Make sure that you have the prerequisites before you install from source:

autoconf and automake
gcc
lex and yacc (or the GNU implementations flex and bison, respectively)
The latest version of libcap from tcpdump.org

These are only necessary if you’re compiling from source code. If you are using Linux RPMs or Debian packages, you do not need these. There is other optional software you can install.This includes:

MySQL, Postgres, or Oracle (SQL databases)
smbclient if using WinPopup messages
Apache or another Web server
PHP or Perl, if you have plug-ins that require them
SSH for remote access (or Terminal Server with Windows)
Apache with SSL capabilities for monitoring (or IIS for Windows)

Installing (from scratch) Snort for Linux

When you first see the list of prerequisite software, installing Snort for Linux may seem like a daunting prospect, especially if you’re new to Linux and its eccentricities. Here we setting up Snort itself, and the MySQL database to hold your logs and alerts.

Staying Safe
If you’re going through the trouble of installing an Intrusion Detection System, you’re obviously concerned about network security. Naturally, you want to make sure that your freshly minted Snort box is adding to the overall security of your network, not detracting from it. How embarrassing would it be for your IDS itself

to be cracked in to?
Or used as a mail relay to spew spam?
Or for your Snort logs to be available for all the world to see over the Internet?

It could happen if you not pay attention. So even though your Snort implementation is locked down, your system itself might not be. Make sure you do the basics. There are some things you need to do; no excuses.

Turn off services you don’t need. Services like Telnet, the Berkeley R services, FTP, NFS, and NIS should not be running on your system In addition, make sure you don’t have any of the useless services running; for example, echo, discard, and chargen.
Maintain system integrity. Tripwire is a freeware application that checks for those backdoors and Trojans you don’t suspect. There are plenty of other freeware applications like Tripwire—AIDE and Samheim are two worth mentioning.
Firewall or TCP Wrap the services you do use. Services like SSH and MySQL should be TCP wrapped or firewalled, as they have their own security holes as well. For services that you can’t TCP Wrap such as Apache, make sure you have it configured as securely as possible. IPTables is the latest version of the Linux firewall, and there are plenty of references on how to implement it.
Encrypt and use public key authentication as much as you can. You should enable public key authentication only for OpenSSH. Another thing you might want to consider doing for Apache for using it to view logs is to use Apache-SSL and use digital certificates for clientside authentication.This helps keep the obvious people out of your system through the usual compromisable channels.
Patch, patch, patch. We cannot stress this enough. Make sure you keep your patches and packages up to date as much as possible. Stay on top of applications you use and their security announcements—the same goes for any operating system you use. For FreeBSD/NetBSD/OpenBSD, make sure you keep your ports and packages up to date. For Red Hat Linux, make sure you stay on top of the updated RPMs. For those of you who are using Debian, you’ll have the easiest time as long as you remember to run apt-get update && apt-get upgrade on a regular basis.

Services cleaning
If at all possible, you want to install Snort on a dedicated system with a fresh/ updated installation of your favorite Linux distribution. Most software is outdated. The older your initial Linux install is, the more likely there are going to be

software bugs,
security vulnerabilities, or
leftover garbage that’s just going to clutter things up.

So make sure you know what you’re getting yourself into, and start with a fresh Linux
installation. Once you’ve got Linux installed and running, it’s time to lock it down. Linux is well-known as a secure and stable operating system, but it’s just as easy to run an insecure Linux server as it is to run an insecure Windows server. Most
modern Linux distributions come with almost everything you could possibly need to run a server or workstation. But when it comes to running a secure Snort server, these optional extras are unnecessary, and can open your server up to attacks if left untended.

Keeping a low profile
The more network services you leave running on your server, the easier time an attacker is going to have cracking in. If all you want to do is monitor network traffic, and later report on it, you don’t need to run network services like a DNS server, or mail server, and you certainly don’t want to be running a file server. But how do you find out what network services are running and what aren’t?

NOTE--you’ll see the pound sign (#) and the dollar sign ($) at the beginning of a Linux command. These are basic command-line prompts, much like the C:\> prompt that Windows command-line users are accustomed to seeing. The difference here is that the dollar-sign prompt indicates that you are logged in as a regular user, while the pound-sign prompt means that you are the all powerful root user. When you see that pound-sign prompt, feel the power — but use it carefully.

To check the network status of your system, run the command netstat. If you’re logged in as root (and if you’re going to be mucking around with network services, you’d better be) you can run netstat -anp as follows to see what ports are open on your system, and what program has them open:

harrykar@harrykar-desktop:~$ sudo netstat -anp
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      3991/mysqld
tcp        0      0 0.0.0.0:10000           0.0.0.0:*               LISTEN      3965/perl
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      3822/apache2
tcp        0      0 127.0.0.1:50001         0.0.0.0:*               LISTEN      8256/firefox
tcp        0      0 0.0.0.0:1234            0.0.0.0:*               LISTEN      3200/monopd
tcp        0      0 0.0.0.0:39923           0.0.0.0:*               LISTEN      6991/seahorse-daemo
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      3266/vsftpd
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      2469/sshd
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      3645/cupsd
tcp        0      0 0.0.0.0:15000           0.0.0.0:*               LISTEN      3285/wesnothd
tcp        0      0 0.0.0.0:5688            0.0.0.0:*               LISTEN      3171/ggzd
tcp        0      0 0.0.0.0:5432            0.0.0.0:*               LISTEN      2688/postgres
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      3152/exim4
tcp        0      0 192.168.1.2:41560       216.239.59.147:80       ESTABLISHED 7429/epiphany-brows
tcp        0      0 192.168.1.2:39618       216.239.59.118:80       TIME_WAIT   -
tcp        1      0 192.168.1.2:41622       66.102.9.91:80          CLOSE_WAIT  7429/epiphany-brows
tcp        0      0 192.168.1.2:59852       209.85.137.125:5223     ESTABLISHED 22648/telepathy-gab
tcp        0      0 192.168.1.2:58593       216.239.59.103:80       ESTABLISHED 7429/epiphany-brows
tcp        0      0 192.168.1.2:40626       216.239.59.103:80       ESTABLISHED 7429/epiphany-brows
tcp        0      0 192.168.1.2:35461       208.72.34.196:80        ESTABLISHED 8256/firefox
tcp        0      0 192.168.1.2:43127       84.200.248.182:5223     ESTABLISHED 22648/telepathy-gab
tcp        0      0 192.168.1.2:39732       208.72.33.133:80        ESTABLISHED 8256/firefox
tcp        0      0 192.168.1.2:53600       216.239.59.147:80       ESTABLISHED 7429/epiphany-brows
tcp        0      0 192.168.1.2:58625       216.239.59.102:80       ESTABLISHED 7429/epiphany-brows
tcp        0      0 192.168.1.2:42687       74.125.77.121:80        ESTABLISHED 7429/epiphany-brows
tcp        0      0 192.168.1.2:39730       208.72.33.133:80        ESTABLISHED 8256/firefox
tcp        0      0 192.168.1.2:34859       65.74.134.1:80          ESTABLISHED 8256/firefox
tcp        0      0 192.168.1.2:42972       208.72.33.133:80        ESTABLISHED 8256/firefox
tcp        0      0 192.168.1.2:60603       216.239.59.104:80       ESTABLISHED 7429/epiphany-brows
tcp        0      0 192.168.1.2:39617       216.239.59.118:80       TIME_WAIT   -
tcp        0      0 192.168.1.2:60599       216.239.59.104:80       ESTABLISHED 7429/epiphany-brows
tcp        0      0 192.168.1.2:44557       216.239.59.147:80       ESTABLISHED 7429/epiphany-brows
tcp        0      0 192.168.1.2:60588       216.239.59.104:80       ESTABLISHED 7429/epiphany-brows
tcp        0      0 192.168.1.2:53599       216.239.59.147:80       ESTABLISHED 7429/epiphany-brows
tcp        0      0 192.168.1.2:39726       208.72.33.133:80        ESTABLISHED 8256/firefox
tcp6       0      0 :::139                  :::*                    LISTEN      3234/smbd
tcp6       0      0 :::22                   :::*                    LISTEN      2469/sshd
tcp6       0      0 :::5432                 :::*                    LISTEN      2688/postgres
tcp6       0      0 :::445                  :::*                    LISTEN      3234/smbd
udp        0      0 192.168.1.2:137         0.0.0.0:*                           3230/nmbd
udp        0      0 0.0.0.0:137             0.0.0.0:*                           3230/nmbd
udp        0      0 192.168.1.2:138         0.0.0.0:*                           3230/nmbd
udp        0      0 0.0.0.0:138             0.0.0.0:*                           3230/nmbd
udp        0      0 0.0.0.0:10000           0.0.0.0:*                           3965/perl
udp        0      0 127.0.0.1:45715         127.0.0.1:45715         ESTABLISHED 2688/postgres
udp        0      0 0.0.0.0:51123           0.0.0.0:*                           3621/avahi-daemon:
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           3621/avahi-daemon:
udp        0      0 192.168.1.2:123         0.0.0.0:*                           3364/ntpd
udp        0      0 127.0.0.1:123           0.0.0.0:*                           3364/ntpd
udp        0      0 0.0.0.0:123             0.0.0.0:*                           3364/ntpd
udp6       0      0 fe80::21e:2aff:febd:123 :::*                                3364/ntpd
udp6       0      0 ::1:123                 :::*                                3364/ntpd
udp6       0      0 :::123                  :::*                                3364/ntpd
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node   PID/Program name    Path
unix  2      [ ACC ]     STREAM     LISTENING     140753   6956/gconf-helper   /tmp/orbit-harrykar/linc-1b2c-0-2564b77178b40
unix  2      [ ACC ]     STREAM     LISTENING     140794   6955/pulseaudio     /tmp/.esd-1000/socket
unix  2      [ ACC ]     STREAM     LISTENING     140798   6955/pulseaudio     /home/harrykar/.pulse/18484395e96f435be4ec43c9497b4141:runtime/native
unix  2      [ ACC ]     STREAM     LISTENING     140856   6969/seahorse-agent /tmp/seahorse-Pz6u7C/S.gpg-agent
unix  2      [ ACC ]     STREAM     LISTENING     140898   6840/x-session-mana /tmp/.ICE-unix/6840
unix  2      [ ACC ]     STREAM     LISTENING     140921   6840/x-session-mana /tmp/orbit-harrykar/linc-1ab8-0-d093a88c59e8
unix  2      [ ACC ]     STREAM     LISTENING     141136   6969/seahorse-agent /tmp/orbit-harrykar/linc-1b39-0-402935b7e3976
unix  2      [ ACC ]     STREAM     LISTENING     141291   6985/gnome-settings /tmp/orbit-harrykar/linc-1b49-0-28b62a0c7b867
unix  2      [ ACC ]     STREAM     LISTENING     141357   6826/gnome-keyring- /tmp/orbit-harrykar/linc-1aaa-0-f120f9afa9e
unix  2      [ ACC ]     STREAM     LISTENING     141362   6826/gnome-keyring- /tmp/keyring-wSNC5a/socket.ssh
unix  2      [ ACC ]     STREAM     LISTENING     141365   6826/gnome-keyring- /tmp/keyring-wSNC5a/socket.pkcs11
unix  2      [ ACC ]     STREAM     LISTENING     141455   6991/seahorse-daemo /tmp/orbit-harrykar/linc-1b4f-0-e18af7c816d
unix  2      [ ACC ]     STREAM     LISTENING     2257095  22645/mission-contr /tmp/orbit-harrykar/linc-5875-0-6e9b266785a0d
unix  2      [ ACC ]     STREAM     LISTENING     141681   7009/gnome-panel    /tmp/orbit-harrykar/linc-1b61-0-4048a68dbba31
unix  2      [ ACC ]     STREAM     LISTENING     141610   7007/metacity       /tmp/orbit-harrykar/linc-1b5f-0-22a8d8ff4a0bd
unix  2      [ ACC ]     STREAM     LISTENING     7868     3388/hald           @/var/run/hald/dbus-2CjEuqIUeb
unix  2      [ ACC ]     STREAM     LISTENING     142084   7029/gconfd-2       /tmp/orbit-root/linc-1b75-0-28b12df8be890
unix  2      [ ACC ]     STREAM     LISTENING     142185   7016/firestarter    /tmp/orbit-root/linc-1b68-0-2c02fb11e0695
unix  2      [ ACC ]     STREAM     LISTENING     142603   7048/gnome-power-ma /tmp/orbit-harrykar/linc-1b83-0-197b1e2eaffc7
unix  2      [ ACC ]     STREAM     LISTENING     142609   7042/bluetooth-appl /tmp/orbit-harrykar/linc-1b82-0-76f5d55cb2354
unix  2      [ ACC ]     STREAM     LISTENING     142662   7047/update-notifie /tmp/orbit-harrykar/linc-1b87-0-197b1e2f20a91
unix  2      [ ACC ]     STREAM     LISTENING     142667   7012/nautilus       /tmp/orbit-harrykar/linc-1b64-0-57ab4aec23b3a
unix  2      [ ACC ]     STREAM     LISTENING     142996   7014/bonobo-activat /tmp/orbit-harrykar/linc-1b66-0-34f71ce6dc0e9
unix  2      [ ACC ]     STREAM     LISTENING     143085   7132/trashapplet    /tmp/orbit-harrykar/linc-1bdc-0-7efe6c0f24d11
unix  2      [ ACC ]     STREAM     LISTENING     143680   7275/quick-lounge-a /tmp/orbit-harrykar/linc-1c6b-0-5c59844e26b7b
unix  2      [ ACC ]     STREAM     LISTENING     8988     3521/bluetoothd     /var/run/sdp
unix  2      [ ACC ]     STREAM     LISTENING     143687   7278/seahorse-apple /tmp/orbit-harrykar/linc-1c6e-0-3d0066be2a64f
unix  2      [ ACC ]     STREAM     LISTENING     143752   7284/multiload-appl /tmp/orbit-harrykar/linc-1c74-0-4a74d9ac9455a
unix  2      [ ACC ]     STREAM     LISTENING     144019   7288/python         /tmp/orbit-harrykar/linc-1c78-0-7ad208b1db55b
unix  2      [ ACC ]     STREAM     LISTENING     144109   7291/python         /tmp/orbit-harrykar/linc-1c7b-0-5beca001c950
unix  2      [ ACC ]     STREAM     LISTENING     144164   7281/ruby           /tmp/orbit-harrykar/linc-1c71-0-468c04a8b30f5
unix  2      [ ACC ]     STREAM     LISTENING     144562   7312/stickynotes_ap /tmp/orbit-harrykar/linc-1c90-0-353afb7ce1f08
unix  2      [ ACC ]     STREAM     LISTENING     144643   7315/gtodo-applet   /tmp/orbit-harrykar/linc-1c93-0-30756eb7ec5ec
unix  2      [ ACC ]     STREAM     LISTENING     144850   7333/mixer_applet2  /tmp/orbit-harrykar/linc-1ca5-0-67ce87102b4e9
unix  2      [ ACC ]     STREAM     LISTENING     144884   7329/indicator-appl /tmp/orbit-harrykar/linc-1ca1-0-6429e47e56fb0
unix  2      [ ACC ]     STREAM     LISTENING     144889   7326/gnome-keyboard /tmp/orbit-harrykar/linc-1c9e-0-4580d826577ad
unix  2      [ ACC ]     STREAM     LISTENING     144916   7336/fast-user-swit /tmp/orbit-harrykar/linc-1ca8-0-442143e66563b
unix  2      [ ACC ]     STREAM     LISTENING     145090   7323/python         /tmp/orbit-harrykar/linc-1c9b-0-396ed6bfd105d
unix  2      [ ACC ]     STREAM     LISTENING     145138   7321/mono           /tmp/orbit-harrykar/linc-1c99-0-93aab55837a1
unix  2      [ ACC ]     STREAM     LISTENING     146172   7377/gnome-screensa /tmp/orbit-harrykar/linc-1cc3-0-3a51ac7d296ce
unix  2      [ ACC ]     STREAM     LISTENING     146465   7390/evolution-data /tmp/orbit-harrykar/linc-1cde-0-4c43b4de66cb3
unix  2      [ ACC ]     STREAM     LISTENING     146625   7395/evolution-exch /tmp/orbit-harrykar/linc-1ce3-0-398db87a6cf1c
unix  2      [ ACC ]     STREAM     LISTENING     146648   7036/evolution-alar /tmp/orbit-harrykar/linc-1b7c-0-398db87a8b8db
unix  2      [ ACC ]     STREAM     LISTENING     7732     3333/winbindd       /var/run/samba/winbindd_privileged/pipe
unix  2      [ ]         DGRAM                    2987     1/init              @/com/ubuntu/upstart
unix  2      [ ACC ]     STREAM     LISTENING     5962     2445/dbus-daemon    /var/run/dbus/system_bus_socket
unix  2      [ ACC ]     STREAM     LISTENING     9035     3521/bluetoothd     @/org/bluez/audio
unix  2      [ ACC ]     STREAM     LISTENING     140234   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  2      [ ACC ]     STREAM     LISTENING     9264     3587/X              @/tmp/.X11-unix/X0
unix  2      [ ACC ]     STREAM     LISTENING     2257049  22642/empathy       /tmp/empathy.harrykar.157474984
unix  2      [ ]         DGRAM                    3182     845/udevd           @/org/kernel/udev/udevd
unix  2      [ ACC ]     STREAM     LISTENING     6514     2688/postgres       /var/run/postgresql/.s.PGSQL.5432
unix  2      [ ACC ]     STREAM     LISTENING     5749     2348/acpid          /var/run/acpid.socket
unix  2      [ ACC ]     STREAM     LISTENING     9345     3621/avahi-daemon:  /var/run/avahi-daemon/socket
unix  2      [ ACC ]     STREAM     LISTENING     2257063  22642/empathy       /tmp/orbit-harrykar/linc-5872-0-6c59633d45ad0
unix  2      [ ]         DGRAM                    7898     3388/hald           @/org/freedesktop/hal/udev_event
unix  2      [ ACC ]     STREAM     LISTENING     142069   7026/dbus-daemon    @/tmp/dbus-PH6XAQHRFQ
unix  2      [ ACC ]     STREAM     LISTENING     2543985  29007/gnome-termina /tmp/orbit-harrykar/linc-714f-0-250b775c210d1
unix  2      [ ACC ]     STREAM     LISTENING     2544814  29033/python2.6     /tmp/orbit-harrykar/linc-7169-0-3b5134f6500a5
unix  2      [ ACC ]     STREAM     LISTENING     10934    3991/mysqld         /var/run/mysqld/mysqld.sock
unix  2      [ ACC ]     STREAM     LISTENING     7863     3388/hald           @/var/run/hald/dbus-J8MtQBOfbD
unix  2      [ ACC ]     STREAM     LISTENING     147373   7429/epiphany-brows /tmp/orbit-harrykar/linc-1d05-0-50d493cf47988
unix  2      [ ACC ]     STREAM     LISTENING     189911   8256/firefox        /tmp/orbit-harrykar/linc-2040-0-723bdebd63d2c
unix  2      [ ACC ]     STREAM     LISTENING     9170     3581/gdm            /var/run/gdm_socket
unix  2      [ ACC ]     STREAM     LISTENING     7730     3333/winbindd       /tmp/.winbindd/pipe
unix  2      [ ACC ]     STREAM     LISTENING     28394    3645/cupsd          /var/run/cups/cups.sock
unix  2      [ ACC ]     STREAM     LISTENING     9265     3587/X              /tmp/.X11-unix/X0
unix  15     [ ]         DGRAM                    5867     2397/syslogd        /dev/log
unix  2      [ ACC ]     STREAM     LISTENING     139568   6826/gnome-keyring- /tmp/keyring-wSNC5a/socket
unix  2      [ ACC ]     STREAM     LISTENING     140217   6945/ssh-agent      /tmp/ssh-bWVwxU6840/agent.6840
unix  2      [ ACC ]     STREAM     LISTENING     140339   6958/gconfd-2       /tmp/orbit-harrykar/linc-1b2e-0-7870703763584
unix  3      [ ]         STREAM     CONNECTED     2556776  3388/hald           @/var/run/hald/dbus-J8MtQBOfbD
unix  3      [ ]         STREAM     CONNECTED     2556775  29349/hal-acl-tool
unix  3      [ ]         STREAM     CONNECTED     2544853  6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     2544852  29033/python2.6
unix  3      [ ]         STREAM     CONNECTED     2544818  29033/python2.6     /tmp/orbit-harrykar/linc-7169-0-3b5134f6500a5
unix  3      [ ]         STREAM     CONNECTED     2544816  6958/gconfd-2
unix  3      [ ]         STREAM     CONNECTED     2544813  6958/gconfd-2       /tmp/orbit-harrykar/linc-1b2e-0-7870703763584
unix  3      [ ]         STREAM     CONNECTED     2544812  29033/python2.6
unix  3      [ ]         STREAM     CONNECTED     2544807  6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     2544806  29033/python2.6
unix  3      [ ]         STREAM     CONNECTED     2544789  6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     2544788  29033/python2.6
unix  3      [ ]         STREAM     CONNECTED     2544740  3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     2544739  29033/python2.6
unix  3      [ ]         STREAM     CONNECTED     2544063  29010/gnome-pty-hel
unix  3      [ ]         STREAM     CONNECTED     2544062  29007/gnome-termina
unix  3      [ ]         STREAM     CONNECTED     2544038  6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     2544037  29007/gnome-termina
unix  3      [ ]         STREAM     CONNECTED     2543988  29007/gnome-termina /tmp/orbit-harrykar/linc-714f-0-250b775c210d1
unix  3      [ ]         STREAM     CONNECTED     2543987  6958/gconfd-2
unix  3      [ ]         STREAM     CONNECTED     2543984  6958/gconfd-2       /tmp/orbit-harrykar/linc-1b2e-0-7870703763584
unix  3      [ ]         STREAM     CONNECTED     2543983  29007/gnome-termina
unix  3      [ ]         STREAM     CONNECTED     2543977  6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     2543976  29007/gnome-termina
unix  3      [ ]         STREAM     CONNECTED     2543974  6840/x-session-mana /tmp/.ICE-unix/6840
unix  3      [ ]         STREAM     CONNECTED     2543973  29007/gnome-termina
unix  3      [ ]         STREAM     CONNECTED     2543959  3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     2543958  29007/gnome-termina
unix  3      [ ]         STREAM     CONNECTED     2257207  6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     2257206  22642/empathy
unix  3      [ ]         STREAM     CONNECTED     2257136  6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     2257135  22648/telepathy-gab
unix  3      [ ]         STREAM     CONNECTED     2257099  22645/mission-contr /tmp/orbit-harrykar/linc-5875-0-6e9b266785a0d
unix  3      [ ]         STREAM     CONNECTED     2257097  6958/gconfd-2
unix  3      [ ]         STREAM     CONNECTED     2257094  6958/gconfd-2       /tmp/orbit-harrykar/linc-1b2e-0-7870703763584
unix  3      [ ]         STREAM     CONNECTED     2257093  22645/mission-contr
unix  3      [ ]         STREAM     CONNECTED     2257083  6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     2257082  22645/mission-contr
unix  3      [ ]         STREAM     CONNECTED     2257066  22642/empathy       /tmp/orbit-harrykar/linc-5872-0-6c59633d45ad0
unix  3      [ ]         STREAM     CONNECTED     2257065  6958/gconfd-2
unix  3      [ ]         STREAM     CONNECTED     2257062  6958/gconfd-2       /tmp/orbit-harrykar/linc-1b2e-0-7870703763584
unix  3      [ ]         STREAM     CONNECTED     2257061  22642/empathy
unix  3      [ ]         STREAM     CONNECTED     2257057  2445/dbus-daemon    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     2257056  22642/empathy
unix  3      [ ]         STREAM     CONNECTED     2257053  6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     2257052  22642/empathy
unix  3      [ ]         STREAM     CONNECTED     2257031  3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     2257030  22642/empathy
unix  3      [ ]         STREAM     CONNECTED     562485   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     562484   7429/epiphany-brows
unix  3      [ ]         STREAM     CONNECTED     547532   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     547531   7750/acroread
unix  3      [ ]         STREAM     CONNECTED     398672   7009/gnome-panel    /tmp/orbit-harrykar/linc-1b61-0-4048a68dbba31
unix  3      [ ]         STREAM     CONNECTED     398671   7390/evolution-data
unix  3      [ ]         STREAM     CONNECTED     398670   7390/evolution-data /tmp/orbit-harrykar/linc-1cde-0-4c43b4de66cb3
unix  3      [ ]         STREAM     CONNECTED     398669   7009/gnome-panel
unix  3      [ ]         STREAM     CONNECTED     321885   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     321884   7377/gnome-screensa
unix  3      [ ]         STREAM     CONNECTED     199468   6955/pulseaudio     /home/harrykar/.pulse/18484395e96f435be4ec43c9497b4141:runtime/native
unix  3      [ ]         STREAM     CONNECTED     199467   8256/firefox
unix  3      [ ]         STREAM     CONNECTED     198230   6955/pulseaudio     /tmp/.esd-1000/socket
unix  3      [ ]         STREAM     CONNECTED     198229   8256/firefox
unix  3      [ ]         STREAM     CONNECTED     190429   6955/pulseaudio     /tmp/.esd-1000/socket
unix  3      [ ]         STREAM     CONNECTED     190428   8256/firefox
unix  3      [ ]         STREAM     CONNECTED     190413   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     190412   8256/firefox
unix  3      [ ]         STREAM     CONNECTED     189980   2445/dbus-daemon    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     189979   8256/firefox
unix  3      [ ]         STREAM     CONNECTED     189914   8256/firefox        /tmp/orbit-harrykar/linc-2040-0-723bdebd63d2c
unix  3      [ ]         STREAM     CONNECTED     189913   6958/gconfd-2
unix  3      [ ]         STREAM     CONNECTED     189910   6958/gconfd-2       /tmp/orbit-harrykar/linc-1b2e-0-7870703763584
unix  3      [ ]         STREAM     CONNECTED     189909   8256/firefox
unix  3      [ ]         STREAM     CONNECTED     189906   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     189905   8256/firefox
unix  3      [ ]         STREAM     CONNECTED     189903   6840/x-session-mana /tmp/.ICE-unix/6840
unix  3      [ ]         STREAM     CONNECTED     189902   8256/firefox
unix  3      [ ]         STREAM     CONNECTED     189892   3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     189891   8256/firefox
unix  3      [ ]         STREAM     CONNECTED     161707   7750/acroread
unix  3      [ ]         STREAM     CONNECTED     161706   7750/acroread
unix  3      [ ]         STREAM     CONNECTED     161082   3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     161081   7750/acroread
unix  2      [ ]         DGRAM                    153478   7551/mount.ntfs-3g
unix  3      [ ]         STREAM     CONNECTED     148678   6955/pulseaudio     /tmp/.esd-1000/socket
unix  3      [ ]         STREAM     CONNECTED     148677   7047/update-notifie
unix  3      [ ]         STREAM     CONNECTED     147573   6955/pulseaudio     /tmp/.esd-1000/socket
unix  3      [ ]         STREAM     CONNECTED     147572   7429/epiphany-brows
unix  3      [ ]         STREAM     CONNECTED     147477   2445/dbus-daemon    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     147476   7429/epiphany-brows
unix  3      [ ]         STREAM     CONNECTED     147463   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     147462   7429/epiphany-brows
unix  3      [ ]         STREAM     CONNECTED     147460   2445/dbus-daemon    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     147459   7429/epiphany-brows
unix  3      [ ]         STREAM     CONNECTED     147376   7429/epiphany-brows /tmp/orbit-harrykar/linc-1d05-0-50d493cf47988
unix  3      [ ]         STREAM     CONNECTED     147375   6958/gconfd-2
unix  3      [ ]         STREAM     CONNECTED     147372   6958/gconfd-2       /tmp/orbit-harrykar/linc-1b2e-0-7870703763584
unix  3      [ ]         STREAM     CONNECTED     147371   7429/epiphany-brows
unix  3      [ ]         STREAM     CONNECTED     147369   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     147368   7429/epiphany-brows
unix  3      [ ]         STREAM     CONNECTED     147365   6840/x-session-mana /tmp/.ICE-unix/6840
unix  3      [ ]         STREAM     CONNECTED     147364   7429/epiphany-brows
unix  3      [ ]         STREAM     CONNECTED     147358   3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     147357   7429/epiphany-brows
unix  3      [ ]         STREAM     CONNECTED     146774   2445/dbus-daemon    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     146773   7045/python
unix  3      [ ]         STREAM     CONNECTED     146772   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     146771   7045/python
unix  3      [ ]         STREAM     CONNECTED     146767   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     146766   7045/python
unix  3      [ ]         STREAM     CONNECTED     146763   3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     146762   7045/python
unix  3      [ ]         STREAM     CONNECTED     146702   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     146701   7323/python
unix  3      [ ]         STREAM     CONNECTED     146699   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     146698   7390/evolution-data
unix  3      [ ]         STREAM     CONNECTED     146696   7036/evolution-alar /tmp/orbit-harrykar/linc-1b7c-0-398db87a8b8db
unix  3      [ ]         STREAM     CONNECTED     146695   7390/evolution-data
unix  3      [ ]         STREAM     CONNECTED     146694   7390/evolution-data /tmp/orbit-harrykar/linc-1cde-0-4c43b4de66cb3
unix  3      [ ]         STREAM     CONNECTED     146693   7036/evolution-alar
unix  3      [ ]         STREAM     CONNECTED     146692   7036/evolution-alar /tmp/orbit-harrykar/linc-1b7c-0-398db87a8b8db
unix  3      [ ]         STREAM     CONNECTED     146691   7014/bonobo-activat
unix  3      [ ]         STREAM     CONNECTED     146690   7014/bonobo-activat /tmp/orbit-harrykar/linc-1b66-0-34f71ce6dc0e9
unix  3      [ ]         STREAM     CONNECTED     146689   7036/evolution-alar
unix  3      [ ]         STREAM     CONNECTED     146669   7390/evolution-data /tmp/orbit-harrykar/linc-1cde-0-4c43b4de66cb3
unix  3      [ ]         STREAM     CONNECTED     146668   7323/python
unix  3      [ ]         STREAM     CONNECTED     146667   7323/python         /tmp/orbit-harrykar/linc-1c9b-0-396ed6bfd105d
unix  3      [ ]         STREAM     CONNECTED     146666   7390/evolution-data
unix  3      [ ]         STREAM     CONNECTED     146655   7395/evolution-exch /tmp/orbit-harrykar/linc-1ce3-0-398db87a6cf1c
unix  3      [ ]         STREAM     CONNECTED     146654   7014/bonobo-activat
unix  3      [ ]         STREAM     CONNECTED     146651   7036/evolution-alar /tmp/orbit-harrykar/linc-1b7c-0-398db87a8b8db
unix  3      [ ]         STREAM     CONNECTED     146650   6958/gconfd-2
unix  3      [ ]         STREAM     CONNECTED     146647   6958/gconfd-2       /tmp/orbit-harrykar/linc-1b2e-0-7870703763584
unix  3      [ ]         STREAM     CONNECTED     146646   7036/evolution-alar
unix  3      [ ]         STREAM     CONNECTED     146645   7014/bonobo-activat /tmp/orbit-harrykar/linc-1b66-0-34f71ce6dc0e9
unix  3      [ ]         STREAM     CONNECTED     146644   7395/evolution-exch
unix  3      [ ]         STREAM     CONNECTED     146640   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     146639   7036/evolution-alar
unix  3      [ ]         STREAM     CONNECTED     146635   6840/x-session-mana /tmp/.ICE-unix/6840
unix  3      [ ]         STREAM     CONNECTED     146634   7036/evolution-alar
unix  3      [ ]         STREAM     CONNECTED     146628   7395/evolution-exch /tmp/orbit-harrykar/linc-1ce3-0-398db87a6cf1c
unix  3      [ ]         STREAM     CONNECTED     146627   6958/gconfd-2
unix  3      [ ]         STREAM     CONNECTED     146624   6958/gconfd-2       /tmp/orbit-harrykar/linc-1b2e-0-7870703763584
unix  3      [ ]         STREAM     CONNECTED     146623   7395/evolution-exch
unix  3      [ ]         STREAM     CONNECTED     146620   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     146619   7395/evolution-exch
unix  3      [ ]         STREAM     CONNECTED     146618   3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     146617   7036/evolution-alar
unix  3      [ ]         STREAM     CONNECTED     146615   6840/x-session-mana /tmp/.ICE-unix/6840
unix  3      [ ]         STREAM     CONNECTED     146614   7395/evolution-exch
unix  3      [ ]         STREAM     CONNECTED     146604   3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     146603   7395/evolution-exch
unix  3      [ ]         STREAM     CONNECTED     146498   7390/evolution-data /tmp/orbit-harrykar/linc-1cde-0-4c43b4de66cb3
unix  3      [ ]         STREAM     CONNECTED     146497   7014/bonobo-activat
unix  3      [ ]         STREAM     CONNECTED     146496   7014/bonobo-activat /tmp/orbit-harrykar/linc-1b66-0-34f71ce6dc0e9
unix  3      [ ]         STREAM     CONNECTED     146495   7390/evolution-data
unix  3      [ ]         STREAM     CONNECTED     146481   6955/pulseaudio     /tmp/.esd-1000/socket
unix  3      [ ]         STREAM     CONNECTED     146480   7321/mono
unix  3      [ ]         STREAM     CONNECTED     146468   7390/evolution-data /tmp/orbit-harrykar/linc-1cde-0-4c43b4de66cb3
unix  3      [ ]         STREAM     CONNECTED     146467   6958/gconfd-2
unix  3      [ ]         STREAM     CONNECTED     146464   6958/gconfd-2       /tmp/orbit-harrykar/linc-1b2e-0-7870703763584
unix  3      [ ]         STREAM     CONNECTED     146463   7390/evolution-data
unix  3      [ ]         STREAM     CONNECTED     146460   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     146459   7390/evolution-data
unix  3      [ ]         STREAM     CONNECTED     146448   7009/gnome-panel    /tmp/orbit-harrykar/linc-1b61-0-4048a68dbba31
unix  3      [ ]         STREAM     CONNECTED     146447   7321/mono
unix  3      [ ]         STREAM     CONNECTED     146446   7321/mono           /tmp/orbit-harrykar/linc-1c99-0-93aab55837a1
unix  3      [ ]         STREAM     CONNECTED     146445   7009/gnome-panel
unix  3      [ ]         STREAM     CONNECTED     146439   7321/mono           /tmp/orbit-harrykar/linc-1c99-0-93aab55837a1
unix  3      [ ]         STREAM     CONNECTED     146438   7014/bonobo-activat
unix  3      [ ]         STREAM     CONNECTED     146437   7014/bonobo-activat /tmp/orbit-harrykar/linc-1b66-0-34f71ce6dc0e9
unix  3      [ ]         STREAM     CONNECTED     146436   7321/mono
unix  3      [ ]         STREAM     CONNECTED     146359   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     146358   7321/mono
unix  3      [ ]         STREAM     CONNECTED     146241   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     146240   7323/python
unix  3      [ ]         STREAM     CONNECTED     146238   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     146237   7321/mono
unix  3      [ ]         STREAM     CONNECTED     146197   2445/dbus-daemon    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     146176   7377/gnome-screensa
unix  3      [ ]         STREAM     CONNECTED     146175   7377/gnome-screensa /tmp/orbit-harrykar/linc-1cc3-0-3a51ac7d296ce
unix  3      [ ]         STREAM     CONNECTED     146174   6958/gconfd-2
unix  3      [ ]         STREAM     CONNECTED     146171   6958/gconfd-2       /tmp/orbit-harrykar/linc-1b2e-0-7870703763584
unix  3      [ ]         STREAM     CONNECTED     146170   7377/gnome-screensa
unix  3      [ ]         STREAM     CONNECTED     146164   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     146163   7377/gnome-screensa
unix  3      [ ]         STREAM     CONNECTED     146161   3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     146160   7377/gnome-screensa
unix  3      [ ]         STREAM     CONNECTED     146196   2445/dbus-daemon    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     146117   7321/mono
unix  3      [ ]         STREAM     CONNECTED     146052   2445/dbus-daemon    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     146032   7009/gnome-panel
unix  3      [ ]         STREAM     CONNECTED     146008   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     146007   7312/stickynotes_ap
unix  3      [ ]         STREAM     CONNECTED     146004   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     146003   7326/gnome-keyboard
unix  3      [ ]         STREAM     CONNECTED     145977   7009/gnome-panel    /tmp/orbit-harrykar/linc-1b61-0-4048a68dbba31
unix  3      [ ]         STREAM     CONNECTED     145976   7312/stickynotes_ap
unix  3      [ ]         STREAM     CONNECTED     145968   6955/pulseaudio     /tmp/.esd-1000/socket
unix  3      [ ]         STREAM     CONNECTED     145967   7315/gtodo-applet
unix  3      [ ]         STREAM     CONNECTED     145962   7009/gnome-panel    /tmp/orbit-harrykar/linc-1b61-0-4048a68dbba31
unix  3      [ ]         STREAM     CONNECTED     145961   7315/gtodo-applet
unix  2      [ ]         DGRAM                    145947   2445/dbus-daemon
unix  3      [ ]         STREAM     CONNECTED     145944   7009/gnome-panel    /tmp/orbit-harrykar/linc-1b61-0-4048a68dbba31
unix  3      [ ]         STREAM     CONNECTED     145943   7326/gnome-keyboard
unix  3      [ ]         STREAM     CONNECTED     145939   6955/pulseaudio     /tmp/.esd-1000/socket
unix  3      [ ]         STREAM     CONNECTED     145938   7329/indicator-appl
unix  3      [ ]         STREAM     CONNECTED     145936   2445/dbus-daemon    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     145935   7329/indicator-appl
unix  3      [ ]         STREAM     CONNECTED     145920   6840/x-session-mana /tmp/.ICE-unix/6840
unix  3      [ ]         STREAM     CONNECTED     145919   7329/indicator-appl
unix  3      [ ]         STREAM     CONNECTED     145921   7009/gnome-panel    /tmp/orbit-harrykar/linc-1b61-0-4048a68dbba31
unix  3      [ ]         STREAM     CONNECTED     145918   7329/indicator-appl
unix  3      [ ]         STREAM     CONNECTED     145884   6955/pulseaudio     /tmp/.esd-1000/socket
unix  3      [ ]         STREAM     CONNECTED     145883   7336/fast-user-swit
unix  3      [ ]         STREAM     CONNECTED     145866   2445/dbus-daemon    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     145865   7336/fast-user-swit
unix  3      [ ]         STREAM     CONNECTED     145863   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     145862   7336/fast-user-swit
unix  3      [ ]         STREAM     CONNECTED     145859   6840/x-session-mana /tmp/.ICE-unix/6840
unix  3      [ ]         STREAM     CONNECTED     145858   7336/fast-user-swit
unix  3      [ ]         STREAM     CONNECTED     145860   7009/gnome-panel    /tmp/orbit-harrykar/linc-1b61-0-4048a68dbba31
unix  3      [ ]         STREAM     CONNECTED     145857   7336/fast-user-swit
unix  3      [ ]         STREAM     CONNECTED     145851   7009/gnome-panel    /tmp/orbit-harrykar/linc-1b61-0-4048a68dbba31
unix  3      [ ]         STREAM     CONNECTED     145850   7333/mixer_applet2
unix  3      [ ]         STREAM     CONNECTED     145844   6955/pulseaudio     /tmp/.esd-1000/socket
unix  3      [ ]         STREAM     CONNECTED     145843   7323/python
unix  3      [ ]         STREAM     CONNECTED     145840   7009/gnome-panel    /tmp/orbit-harrykar/linc-1b61-0-4048a68dbba31
unix  3      [ ]         STREAM     CONNECTED     145839   7323/python
unix  3      [ ]         STREAM     CONNECTED     145838   7323/python         /tmp/orbit-harrykar/linc-1c9b-0-396ed6bfd105d
unix  3      [ ]         STREAM     CONNECTED     145837   7009/gnome-panel
unix  3      [ ]         STREAM     CONNECTED     145836   7333/mixer_applet2  /tmp/orbit-harrykar/linc-1ca5-0-67ce87102b4e9
unix  3      [ ]         STREAM     CONNECTED     145835   7009/gnome-panel
unix  3      [ ]         STREAM     CONNECTED     145834   7336/fast-user-swit /tmp/orbit-harrykar/linc-1ca8-0-442143e66563b
unix  3      [ ]         STREAM     CONNECTED     145833   7009/gnome-panel
unix  3      [ ]         STREAM     CONNECTED     145832   7329/indicator-appl /tmp/orbit-harrykar/linc-1ca1-0-6429e47e56fb0
unix  3      [ ]         STREAM     CONNECTED     145831   7009/gnome-panel
unix  3      [ ]         STREAM     CONNECTED     145830   7326/gnome-keyboard /tmp/orbit-harrykar/linc-1c9e-0-4580d826577ad
unix  3      [ ]         STREAM     CONNECTED     145829   7009/gnome-panel
unix  3      [ ]         STREAM     CONNECTED     145828   7315/gtodo-applet   /tmp/orbit-harrykar/linc-1c93-0-30756eb7ec5ec
unix  3      [ ]         STREAM     CONNECTED     145827   7009/gnome-panel
unix  3      [ ]         STREAM     CONNECTED     145826   7312/stickynotes_ap /tmp/orbit-harrykar/linc-1c90-0-353afb7ce1f08
unix  3      [ ]         STREAM     CONNECTED     145825   7009/gnome-panel
unix  3      [ ]         STREAM     CONNECTED     145297   7323/python         /tmp/orbit-harrykar/linc-1c9b-0-396ed6bfd105d
unix  3      [ ]         STREAM     CONNECTED     145296   7014/bonobo-activat
unix  3      [ ]         STREAM     CONNECTED     145293   7014/bonobo-activat /tmp/orbit-harrykar/linc-1b66-0-34f71ce6dc0e9
unix  3      [ ]         STREAM     CONNECTED     145292   7323/python
unix  3      [ ]         STREAM     CONNECTED     145291   6840/x-session-mana /tmp/.ICE-unix/6840
unix  3      [ ]         STREAM     CONNECTED     145290   7323/python
unix  3      [ ]         STREAM     CONNECTED     145168   6840/x-session-mana /tmp/.ICE-unix/6840
unix  3      [ ]         STREAM     CONNECTED     145167   7321/mono
unix  3      [ ]         STREAM     CONNECTED     145148   3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     145147   7321/mono
unix  3      [ ]         STREAM     CONNECTED     145142   7321/mono           /tmp/orbit-harrykar/linc-1c99-0-93aab55837a1
unix  3      [ ]         STREAM     CONNECTED     145140   6958/gconfd-2
unix  3      [ ]         STREAM     CONNECTED     145137   6958/gconfd-2       /tmp/orbit-harrykar/linc-1b2e-0-7870703763584
unix  3      [ ]         STREAM     CONNECTED     145136   7321/mono
unix  5      [ ]         STREAM     CONNECTED     145131   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     145130   7321/mono
unix  3      [ ]         STREAM     CONNECTED     145114   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     145113   7323/python
unix  3      [ ]         STREAM     CONNECTED     145093   7323/python         /tmp/orbit-harrykar/linc-1c9b-0-396ed6bfd105d
unix  3      [ ]         STREAM     CONNECTED     145092   6958/gconfd-2
unix  3      [ ]         STREAM     CONNECTED     145089   6958/gconfd-2       /tmp/orbit-harrykar/linc-1b2e-0-7870703763584
unix  3      [ ]         STREAM     CONNECTED     145088   7323/python
unix  5      [ ]         STREAM     CONNECTED     145086   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     145085   7323/python
unix  3      [ ]         STREAM     CONNECTED     144968   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     144967   7333/mixer_applet2
unix  3      [ ]         STREAM     CONNECTED     144957   3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     144956   7323/python
unix  3      [ ]         STREAM     CONNECTED     144927   7336/fast-user-swit /tmp/orbit-harrykar/linc-1ca8-0-442143e66563b
unix  3      [ ]         STREAM     CONNECTED     144926   6958/gconfd-2
unix  3      [ ]         STREAM     CONNECTED     144925   6958/gconfd-2       /tmp/orbit-harrykar/linc-1b2e-0-7870703763584
unix  3      [ ]         STREAM     CONNECTED     144924   7336/fast-user-swit
unix  3      [ ]         STREAM     CONNECTED     144922   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     144921   7336/fast-user-swit
unix  3      [ ]         STREAM     CONNECTED     144920   7336/fast-user-swit /tmp/orbit-harrykar/linc-1ca8-0-442143e66563b
unix  3      [ ]         STREAM     CONNECTED     144918   7014/bonobo-activat
unix  3      [ ]         STREAM     CONNECTED     144915   7014/bonobo-activat /tmp/orbit-harrykar/linc-1b66-0-34f71ce6dc0e9
unix  3      [ ]         STREAM     CONNECTED     144914   7336/fast-user-swit
unix  3      [ ]         STREAM     CONNECTED     144911   7329/indicator-appl /tmp/orbit-harrykar/linc-1ca1-0-6429e47e56fb0
unix  3      [ ]         STREAM     CONNECTED     144910   6958/gconfd-2
unix  3      [ ]         STREAM     CONNECTED     144908   6958/gconfd-2       /tmp/orbit-harrykar/linc-1b2e-0-7870703763584
unix  3      [ ]         STREAM     CONNECTED     144907   7329/indicator-appl
unix  3      [ ]         STREAM     CONNECTED     144904   7326/gnome-keyboard /tmp/orbit-harrykar/linc-1c9e-0-4580d826577ad
unix  3      [ ]         STREAM     CONNECTED     144903   6958/gconfd-2
unix  3      [ ]         STREAM     CONNECTED     144902   6958/gconfd-2       /tmp/orbit-harrykar/linc-1b2e-0-7870703763584
unix  3      [ ]         STREAM     CONNECTED     144901   7326/gnome-keyboard
unix  3      [ ]         STREAM     CONNECTED     144899   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     144898   7329/indicator-appl
unix  5      [ ]         STREAM     CONNECTED     144895   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     144894   7326/gnome-keyboard
unix  3      [ ]         STREAM     CONNECTED     144892   7326/gnome-keyboard /tmp/orbit-harrykar/linc-1c9e-0-4580d826577ad
unix  3      [ ]         STREAM     CONNECTED     144891   7014/bonobo-activat
unix  3      [ ]         STREAM     CONNECTED     144888   7014/bonobo-activat /tmp/orbit-harrykar/linc-1b66-0-34f71ce6dc0e9
unix  3      [ ]         STREAM     CONNECTED     144887   7326/gnome-keyboard
unix  3      [ ]         STREAM     CONNECTED     144897   7329/indicator-appl /tmp/orbit-harrykar/linc-1ca1-0-6429e47e56fb0
unix  3      [ ]         STREAM     CONNECTED     144886   7014/bonobo-activat
unix  3      [ ]         STREAM     CONNECTED     144883   7014/bonobo-activat /tmp/orbit-harrykar/linc-1b66-0-34f71ce6dc0e9
unix  3      [ ]         STREAM     CONNECTED     144876   7329/indicator-appl
unix  3      [ ]         STREAM     CONNECTED     144869   3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     144868   7336/fast-user-swit
unix  3      [ ]         STREAM     CONNECTED     144861   7333/mixer_applet2  /tmp/orbit-harrykar/linc-1ca5-0-67ce87102b4e9
unix  3      [ ]         STREAM     CONNECTED     144860   6958/gconfd-2
unix  3      [ ]         STREAM     CONNECTED     144859   6958/gconfd-2       /tmp/orbit-harrykar/linc-1b2e-0-7870703763584
unix  3      [ ]         STREAM     CONNECTED     144858   7333/mixer_applet2
unix  5      [ ]         STREAM     CONNECTED     144856   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     144855   7333/mixer_applet2
unix  3      [ ]         STREAM     CONNECTED     144853   7333/mixer_applet2  /tmp/orbit-harrykar/linc-1ca5-0-67ce87102b4e9
unix  3      [ ]         STREAM     CONNECTED     144852   7014/bonobo-activat
unix  3      [ ]         STREAM     CONNECTED     144849   7014/bonobo-activat /tmp/orbit-harrykar/linc-1b66-0-34f71ce6dc0e9
unix  3      [ ]         STREAM     CONNECTED     144848   7333/mixer_applet2
unix  3      [ ]         STREAM     CONNECTED     144847   3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     144846   7329/indicator-appl
unix  3      [ ]         STREAM     CONNECTED     144840   3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     144839   7326/gnome-keyboard
unix  3      [ ]         STREAM     CONNECTED     144827   3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     144826   7333/mixer_applet2
unix  3      [ ]         STREAM     CONNECTED     144820   7312/stickynotes_ap /tmp/orbit-harrykar/linc-1c90-0-353afb7ce1f08
unix  3      [ ]         STREAM     CONNECTED     144819   6958/gconfd-2
unix  3      [ ]         STREAM     CONNECTED     144818   6958/gconfd-2       /tmp/orbit-harrykar/linc-1b2e-0-7870703763584
unix  3      [ ]         STREAM     CONNECTED     144817   7312/stickynotes_ap
unix  5      [ ]         STREAM     CONNECTED     144815   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     144814   7312/stickynotes_ap
unix  3      [ ]         STREAM     CONNECTED     144813   7315/gtodo-applet   /tmp/orbit-harrykar/linc-1c93-0-30756eb7ec5ec
unix  3      [ ]         STREAM     CONNECTED     144812   7014/bonobo-activat
unix  3      [ ]         STREAM     CONNECTED     144649   7312/stickynotes_ap /tmp/orbit-harrykar/linc-1c90-0-353afb7ce1f08
unix  3      [ ]         STREAM     CONNECTED     144648   7014/bonobo-activat
unix  3      [ ]         STREAM     CONNECTED     144650   7014/bonobo-activat /tmp/orbit-harrykar/linc-1b66-0-34f71ce6dc0e9
unix  3      [ ]         STREAM     CONNECTED     144647   7315/gtodo-applet
unix  3      [ ]         STREAM     CONNECTED     144646   7315/gtodo-applet   /tmp/orbit-harrykar/linc-1c93-0-30756eb7ec5ec
unix  3      [ ]         STREAM     CONNECTED     144645   6958/gconfd-2
unix  3      [ ]         STREAM     CONNECTED     144642   6958/gconfd-2       /tmp/orbit-harrykar/linc-1b2e-0-7870703763584
unix  3      [ ]         STREAM     CONNECTED     144641   7315/gtodo-applet
unix  5      [ ]         STREAM     CONNECTED     144639   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     144638   7315/gtodo-applet
unix  3      [ ]         STREAM     CONNECTED     144634   7014/bonobo-activat /tmp/orbit-harrykar/linc-1b66-0-34f71ce6dc0e9
unix  3      [ ]         STREAM     CONNECTED     144561   7312/stickynotes_ap
unix  3      [ ]         STREAM     CONNECTED     144556   3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     144555   7315/gtodo-applet
unix  3      [ ]         STREAM     CONNECTED     144378   3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     144377   7312/stickynotes_ap
unix  3      [ ]         STREAM     CONNECTED     144203   6955/pulseaudio     /tmp/.esd-1000/socket
unix  3      [ ]         STREAM     CONNECTED     144202   7288/python
unix  3      [ ]         STREAM     CONNECTED     144200   6955/pulseaudio     /tmp/.esd-1000/socket
unix  3      [ ]         STREAM     CONNECTED     144199   7291/python
unix  3      [ ]         STREAM     CONNECTED     144197   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     144196   7295/tracker-indexe
unix  3      [ ]         STREAM     CONNECTED     144193   6955/pulseaudio     /tmp/.esd-1000/socket
unix  3      [ ]         STREAM     CONNECTED     144192   7281/ruby
unix  3      [ ]         STREAM     CONNECTED     144181   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     144180   7291/python
unix  3      [ ]         STREAM     CONNECTED     144176   7009/gnome-panel    /tmp/orbit-harrykar/linc-1b61-0-4048a68dbba31
unix  3      [ ]         STREAM     CONNECTED     144175   7281/ruby
unix  3      [ ]         STREAM     CONNECTED     144174   7281/ruby           /tmp/orbit-harrykar/linc-1c71-0-468c04a8b30f5
unix  3      [ ]         STREAM     CONNECTED     144173   7009/gnome-panel
unix  3      [ ]         STREAM     CONNECTED     144172   7281/ruby           /tmp/orbit-harrykar/linc-1c71-0-468c04a8b30f5
unix  3      [ ]         STREAM     CONNECTED     144171   7014/bonobo-activat
unix  3      [ ]         STREAM     CONNECTED     144170   7014/bonobo-activat /tmp/orbit-harrykar/linc-1b66-0-34f71ce6dc0e9
unix  3      [ ]         STREAM     CONNECTED     144169   7281/ruby
unix  3      [ ]         STREAM     CONNECTED     144167   7281/ruby           /tmp/orbit-harrykar/linc-1c71-0-468c04a8b30f5
unix  3      [ ]         STREAM     CONNECTED     144166   6958/gconfd-2
unix  3      [ ]         STREAM     CONNECTED     144163   6958/gconfd-2       /tmp/orbit-harrykar/linc-1b2e-0-7870703763584
unix  3      [ ]         STREAM     CONNECTED     144162   7281/ruby
unix  5      [ ]         STREAM     CONNECTED     144159   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     144158   7281/ruby
unix  3      [ ]         STREAM     CONNECTED     144144   7009/gnome-panel    /tmp/orbit-harrykar/linc-1b61-0-4048a68dbba31
unix  3      [ ]         STREAM     CONNECTED     144143   7291/python
unix  3      [ ]         STREAM     CONNECTED     144142   7291/python         /tmp/orbit-harrykar/linc-1c7b-0-5beca001c950
unix  3      [ ]         STREAM     CONNECTED     144141   7009/gnome-panel
unix  3      [ ]         STREAM     CONNECTED     144140   7291/python         /tmp/orbit-harrykar/linc-1c7b-0-5beca001c950
unix  3      [ ]         STREAM     CONNECTED     144139   7014/bonobo-activat
unix  3      [ ]         STREAM     CONNECTED     144138   7014/bonobo-activat /tmp/orbit-harrykar/linc-1b66-0-34f71ce6dc0e9
unix  3      [ ]         STREAM     CONNECTED     144137   7291/python
unix  3      [ ]         STREAM     CONNECTED     144135   6840/x-session-mana /tmp/.ICE-unix/6840
unix  3      [ ]         STREAM     CONNECTED     144134   7291/python
unix  3      [ ]         STREAM     CONNECTED     144112   7291/python         /tmp/orbit-harrykar/linc-1c7b-0-5beca001c950
unix  3      [ ]         STREAM     CONNECTED     144111   6958/gconfd-2
unix  3      [ ]         STREAM     CONNECTED     144108   6958/gconfd-2       /tmp/orbit-harrykar/linc-1b2e-0-7870703763584
unix  3      [ ]         STREAM     CONNECTED     144107   7291/python
unix  3      [ ]         STREAM     CONNECTED     144105   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     144104   7291/python
unix  3      [ ]         STREAM     CONNECTED     144031   7009/gnome-panel    /tmp/orbit-harrykar/linc-1b61-0-4048a68dbba31
unix  3      [ ]         STREAM     CONNECTED     144030   7288/python
unix  3      [ ]         STREAM     CONNECTED     144029   7288/python         /tmp/orbit-harrykar/linc-1c78-0-7ad208b1db55b
unix  3      [ ]         STREAM     CONNECTED     144028   7009/gnome-panel
unix  3      [ ]         STREAM     CONNECTED     144027   7288/python         /tmp/orbit-harrykar/linc-1c78-0-7ad208b1db55b
unix  3      [ ]         STREAM     CONNECTED     144026   7014/bonobo-activat
unix  3      [ ]         STREAM     CONNECTED     144025   7014/bonobo-activat /tmp/orbit-harrykar/linc-1b66-0-34f71ce6dc0e9
unix  3      [ ]         STREAM     CONNECTED     144024   7288/python
unix  3      [ ]         STREAM     CONNECTED     144022   7288/python         /tmp/orbit-harrykar/linc-1c78-0-7ad208b1db55b
unix  3      [ ]         STREAM     CONNECTED     144021   6958/gconfd-2
unix  3      [ ]         STREAM     CONNECTED     144018   6958/gconfd-2       /tmp/orbit-harrykar/linc-1b2e-0-7870703763584
unix  3      [ ]         STREAM     CONNECTED     144017   7288/python
unix  5      [ ]         STREAM     CONNECTED     144015   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     144014   7288/python
unix  3      [ ]         STREAM     CONNECTED     144013   6840/x-session-mana /tmp/.ICE-unix/6840
unix  3      [ ]         STREAM     CONNECTED     144012   7288/python
unix  3      [ ]         STREAM     CONNECTED     144002   7301/gvfsd-burn     @/dbus-vfs-daemon/socket-2PveGd68
unix  3      [ ]         STREAM     CONNECTED     144001   7012/nautilus
unix  3      [ ]         STREAM     CONNECTED     144003   7301/gvfsd-burn     @/dbus-vfs-daemon/socket-NxPCog3O
unix  3      [ ]         STREAM     CONNECTED     144000   7012/nautilus
unix  3      [ ]         STREAM     CONNECTED     143991   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     143990   7301/gvfsd-burn
unix  3      [ ]         STREAM     CONNECTED     143979   2445/dbus-daemon    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     143978   7295/tracker-indexe
unix  3      [ ]         STREAM     CONNECTED     143973   3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     143972   7288/python
unix  3      [ ]         STREAM     CONNECTED     143922   3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     143918   7281/ruby
unix  3      [ ]         STREAM     CONNECTED     143867   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     143866   7278/seahorse-apple
unix  3      [ ]         STREAM     CONNECTED     143864   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     143863   7295/tracker-indexe
unix  3      [ ]         STREAM     CONNECTED     143843   3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     143842   7288/python
unix  3      [ ]         STREAM     CONNECTED     143832   3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     143831   7291/python
unix  3      [ ]         STREAM     CONNECTED     143796   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     143795   7295/tracker-indexe
unix  3      [ ]         STREAM     CONNECTED     143769   7009/gnome-panel    /tmp/orbit-harrykar/linc-1b61-0-4048a68dbba31
unix  3      [ ]         STREAM     CONNECTED     143768   7284/multiload-appl
unix  3      [ ]         STREAM     CONNECTED     143767   7284/multiload-appl /tmp/orbit-harrykar/linc-1c74-0-4a74d9ac9455a
unix  3      [ ]         STREAM     CONNECTED     143765   7009/gnome-panel
unix  3      [ ]         STREAM     CONNECTED     143763   7284/multiload-appl /tmp/orbit-harrykar/linc-1c74-0-4a74d9ac9455a
unix  3      [ ]         STREAM     CONNECTED     143762   6958/gconfd-2
unix  3      [ ]         STREAM     CONNECTED     143761   6958/gconfd-2       /tmp/orbit-harrykar/linc-1b2e-0-7870703763584
unix  3      [ ]         STREAM     CONNECTED     143760   7284/multiload-appl
unix  5      [ ]         STREAM     CONNECTED     143757   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     143756   7284/multiload-appl
unix  3      [ ]         STREAM     CONNECTED     143755   7284/multiload-appl /tmp/orbit-harrykar/linc-1c74-0-4a74d9ac9455a
unix  3      [ ]         STREAM     CONNECTED     143754   7014/bonobo-activat
unix  3      [ ]         STREAM     CONNECTED     143749   7014/bonobo-activat /tmp/orbit-harrykar/linc-1b66-0-34f71ce6dc0e9
unix  3      [ ]         STREAM     CONNECTED     143748   7284/multiload-appl
unix  3      [ ]         STREAM     CONNECTED     143742   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     143741   7275/quick-lounge-a
unix  3      [ ]         STREAM     CONNECTED     143737   7009/gnome-panel    /tmp/orbit-harrykar/linc-1b61-0-4048a68dbba31
unix  3      [ ]         STREAM     CONNECTED     143736   7278/seahorse-apple
unix  3      [ ]         STREAM     CONNECTED     143734   7278/seahorse-apple /tmp/orbit-harrykar/linc-1c6e-0-3d0066be2a64f
unix  3      [ ]         STREAM     CONNECTED     143732   7009/gnome-panel
unix  3      [ ]         STREAM     CONNECTED     143730   3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     143729   7284/multiload-appl
unix  3      [ ]         STREAM     CONNECTED     143723   7009/gnome-panel    /tmp/orbit-harrykar/linc-1b61-0-4048a68dbba31
unix  3      [ ]         STREAM     CONNECTED     143722   7275/quick-lounge-a
unix  3      [ ]         STREAM     CONNECTED     143719   7278/seahorse-apple /tmp/orbit-harrykar/linc-1c6e-0-3d0066be2a64f
unix  3      [ ]         STREAM     CONNECTED     143717   6958/gconfd-2
unix  3      [ ]         STREAM     CONNECTED     143716   6958/gconfd-2       /tmp/orbit-harrykar/linc-1b2e-0-7870703763584
unix  3      [ ]         STREAM     CONNECTED     143715   7278/seahorse-apple
unix  3      [ ]         STREAM     CONNECTED     143714   7275/quick-lounge-a /tmp/orbit-harrykar/linc-1c6b-0-5c59844e26b7b
unix  3      [ ]         STREAM     CONNECTED     143713   7009/gnome-panel
unix  5      [ ]         STREAM     CONNECTED     143708   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     143706   7278/seahorse-apple
unix  3      [ ]         STREAM     CONNECTED     143700   7275/quick-lounge-a /tmp/orbit-harrykar/linc-1c6b-0-5c59844e26b7b
unix  3      [ ]         STREAM     CONNECTED     143699   6958/gconfd-2
unix  3      [ ]         STREAM     CONNECTED     143698   6958/gconfd-2       /tmp/orbit-harrykar/linc-1b2e-0-7870703763584
unix  3      [ ]         STREAM     CONNECTED     143697   7275/quick-lounge-a
unix  5      [ ]         STREAM     CONNECTED     143694   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     143693   7275/quick-lounge-a
unix  3      [ ]         STREAM     CONNECTED     143703   7278/seahorse-apple /tmp/orbit-harrykar/linc-1c6e-0-3d0066be2a64f
unix  3      [ ]         STREAM     CONNECTED     143692   7014/bonobo-activat
unix  3      [ ]         STREAM     CONNECTED     143690   7275/quick-lounge-a /tmp/orbit-harrykar/linc-1c6b-0-5c59844e26b7b
unix  3      [ ]         STREAM     CONNECTED     143689   7014/bonobo-activat
unix  3      [ ]         STREAM     CONNECTED     143691   7014/bonobo-activat /tmp/orbit-harrykar/linc-1b66-0-34f71ce6dc0e9
unix  3      [ ]         STREAM     CONNECTED     143686   7278/seahorse-apple
unix  3      [ ]         STREAM     CONNECTED     143679   7014/bonobo-activat /tmp/orbit-harrykar/linc-1b66-0-34f71ce6dc0e9
unix  3      [ ]         STREAM     CONNECTED     143678   7275/quick-lounge-a
unix  3      [ ]         STREAM     CONNECTED     143616   3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     143615   7278/seahorse-apple
unix  3      [ ]         STREAM     CONNECTED     143564   3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     143563   7275/quick-lounge-a
unix  3      [ ]         STREAM     CONNECTED     143346   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     143345   7009/gnome-panel
unix  3      [ ]         STREAM     CONNECTED     143237   7077/gvfsd-trash    @/dbus-vfs-daemon/socket-eLpmocou
unix  3      [ ]         STREAM     CONNECTED     143236   7012/nautilus
unix  3      [ ]         STREAM     CONNECTED     143235   7077/gvfsd-trash    @/dbus-vfs-daemon/socket-DoGAo4ET
unix  3      [ ]         STREAM     CONNECTED     143234   7012/nautilus
unix  3      [ ]         STREAM     CONNECTED     143169   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     143168   7012/nautilus
unix  3      [ ]         STREAM     CONNECTED     143161   7009/gnome-panel    /tmp/orbit-harrykar/linc-1b61-0-4048a68dbba31
unix  3      [ ]         STREAM     CONNECTED     143159   7132/trashapplet
unix  3      [ ]         STREAM     CONNECTED     143158   7132/trashapplet    /tmp/orbit-harrykar/linc-1bdc-0-7efe6c0f24d11
unix  3      [ ]         STREAM     CONNECTED     143157   7009/gnome-panel
unix  3      [ ]         STREAM     CONNECTED     143155   2445/dbus-daemon    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     143154   7018/trackerd
unix  3      [ ]         STREAM     CONNECTED     143151   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     143150   7018/trackerd
unix  3      [ ]         STREAM     CONNECTED     143146   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     143145   7140/gvfs-gphoto2-v
unix  3      [ ]         STREAM     CONNECTED     143142   2445/dbus-daemon    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     143141   7140/gvfs-gphoto2-v
unix  3      [ ]         STREAM     CONNECTED     143114   7077/gvfsd-trash    @/dbus-vfs-daemon/socket-SzPVf7Oq
unix  3      [ ]         STREAM     CONNECTED     143113   7132/trashapplet
unix  3      [ ]         STREAM     CONNECTED     143112   7077/gvfsd-trash    @/dbus-vfs-daemon/socket-2dyqhgRf
unix  3      [ ]         STREAM     CONNECTED     143111   7132/trashapplet
unix  3      [ ]         STREAM     CONNECTED     143108   7077/gvfsd-trash    @/dbus-vfs-daemon/socket-oy0w8XV8
unix  3      [ ]         STREAM     CONNECTED     143107   7132/trashapplet
unix  3      [ ]         STREAM     CONNECTED     143106   7077/gvfsd-trash    @/dbus-vfs-daemon/socket-NHwhFLS0
unix  3      [ ]         STREAM     CONNECTED     143105   7132/trashapplet
unix  5      [ ]         STREAM     CONNECTED     143101   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     143100   7132/trashapplet
unix  3      [ ]         STREAM     CONNECTED     143098   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     143097   7132/trashapplet
unix  3      [ ]         STREAM     CONNECTED     143096   7132/trashapplet    /tmp/orbit-harrykar/linc-1bdc-0-7efe6c0f24d11
unix  3      [ ]         STREAM     CONNECTED     143095   6958/gconfd-2
unix  3      [ ]         STREAM     CONNECTED     143094   6958/gconfd-2       /tmp/orbit-harrykar/linc-1b2e-0-7870703763584
unix  3      [ ]         STREAM     CONNECTED     143093   7132/trashapplet
unix  5      [ ]         STREAM     CONNECTED     143090   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     143089   7132/trashapplet
unix  3      [ ]         STREAM     CONNECTED     143088   7132/trashapplet    /tmp/orbit-harrykar/linc-1bdc-0-7efe6c0f24d11
unix  3      [ ]         STREAM     CONNECTED     143087   7014/bonobo-activat
unix  3      [ ]         STREAM     CONNECTED     143077   7014/bonobo-activat /tmp/orbit-harrykar/linc-1b66-0-34f71ce6dc0e9
unix  3      [ ]         STREAM     CONNECTED     143076   7132/trashapplet
unix  3      [ ]         STREAM     CONNECTED     143069   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     143068   7136/gvfs-hal-volum
unix  3      [ ]         STREAM     CONNECTED     143064   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     143063   7136/gvfs-hal-volum
unix  3      [ ]         STREAM     CONNECTED     143059   2445/dbus-daemon    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     143058   7136/gvfs-hal-volum
unix  3      [ ]         STREAM     CONNECTED     143048   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     143047   7009/gnome-panel
unix  3      [ ]         STREAM     CONNECTED     143045   3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     143044   7132/trashapplet
unix  3      [ ]         STREAM     CONNECTED     143006   7009/gnome-panel    /tmp/orbit-harrykar/linc-1b61-0-4048a68dbba31
unix  3      [ ]         STREAM     CONNECTED     143005   7014/bonobo-activat
unix  3      [ ]         STREAM     CONNECTED     143003   7014/bonobo-activat /tmp/orbit-harrykar/linc-1b66-0-34f71ce6dc0e9
unix  3      [ ]         STREAM     CONNECTED     143002   7009/gnome-panel
unix  3      [ ]         STREAM     CONNECTED     142999   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     142998   7014/bonobo-activat
unix  3      [ ]         STREAM     CONNECTED     142907   2445/dbus-daemon    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     142906   7021/python
unix  3      [ ]         STREAM     CONNECTED     142904   2445/dbus-daemon    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     142903   7012/nautilus
unix  3      [ ]         STREAM     CONNECTED     142867   7077/gvfsd-trash    @/dbus-vfs-daemon/socket-Wb9EZpWP
unix  3      [ ]         STREAM     CONNECTED     142866   7012/nautilus
unix  3      [ ]         STREAM     CONNECTED     142868   7077/gvfsd-trash    @/dbus-vfs-daemon/socket-l17CRQYU
unix  3      [ ]         STREAM     CONNECTED     142865   7012/nautilus
unix  3      [ ]         STREAM     CONNECTED     142859   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     142858   7077/gvfsd-trash
unix  3      [ ]         STREAM     CONNECTED     142854   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     142853   7077/gvfsd-trash
unix  3      [ ]         STREAM     CONNECTED     142850   3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     142849   7021/python
unix  3      [ ]         STREAM     CONNECTED     142825   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     142824   7012/nautilus
unix  3      [ ]         STREAM     CONNECTED     142793   6955/pulseaudio     /tmp/.esd-1000/socket
unix  3      [ ]         STREAM     CONNECTED     142792   7048/gnome-power-ma
unix  3      [ ]         STREAM     CONNECTED     142703   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     142702   7012/nautilus
unix  3      [ ]         STREAM     CONNECTED     142683   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     142682   7047/update-notifie
unix  3      [ ]         STREAM     CONNECTED     142680   2445/dbus-daemon    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     142679   7047/update-notifie
unix  3      [ ]         STREAM     CONNECTED     142670   7012/nautilus       /tmp/orbit-harrykar/linc-1b64-0-57ab4aec23b3a
unix  3      [ ]         STREAM     CONNECTED     142669   6958/gconfd-2
unix  3      [ ]         STREAM     CONNECTED     142665   7047/update-notifie /tmp/orbit-harrykar/linc-1b87-0-197b1e2f20a91
unix  3      [ ]         STREAM     CONNECTED     142664   6958/gconfd-2
unix  3      [ ]         STREAM     CONNECTED     142661   6958/gconfd-2       /tmp/orbit-harrykar/linc-1b2e-0-7870703763584
unix  3      [ ]         STREAM     CONNECTED     142659   7047/update-notifie
unix  3      [ ]         STREAM     CONNECTED     142660   6958/gconfd-2       /tmp/orbit-harrykar/linc-1b2e-0-7870703763584
unix  3      [ ]         STREAM     CONNECTED     142658   7012/nautilus
unix  3      [ ]         STREAM     CONNECTED     142650   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     142649   7012/nautilus
unix  3      [ ]         STREAM     CONNECTED     142642   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     142641   7047/update-notifie
unix  3      [ ]         STREAM     CONNECTED     142639   6840/x-session-mana /tmp/.ICE-unix/6840
unix  3      [ ]         STREAM     CONNECTED     142638   7047/update-notifie
unix  3      [ ]         STREAM     CONNECTED     142633   3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     142632   7047/update-notifie
unix  3      [ ]         STREAM     CONNECTED     142614   2445/dbus-daemon    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     142613   7048/gnome-power-ma
unix  3      [ ]         STREAM     CONNECTED     142612   7042/bluetooth-appl /tmp/orbit-harrykar/linc-1b82-0-76f5d55cb2354
unix  3      [ ]         STREAM     CONNECTED     142611   6958/gconfd-2
unix  3      [ ]         STREAM     CONNECTED     142608   6958/gconfd-2       /tmp/orbit-harrykar/linc-1b2e-0-7870703763584
unix  3      [ ]         STREAM     CONNECTED     142607   7042/bluetooth-appl
unix  3      [ ]         STREAM     CONNECTED     142606   7048/gnome-power-ma /tmp/orbit-harrykar/linc-1b83-0-197b1e2eaffc7
unix  3      [ ]         STREAM     CONNECTED     142605   6958/gconfd-2
unix  3      [ ]         STREAM     CONNECTED     142597   6958/gconfd-2       /tmp/orbit-harrykar/linc-1b2e-0-7870703763584
unix  3      [ ]         STREAM     CONNECTED     142596   7048/gnome-power-ma
unix  3      [ ]         STREAM     CONNECTED     142593   2445/dbus-daemon    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     142592   7042/bluetooth-appl
unix  3      [ ]         STREAM     CONNECTED     142589   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     142588   7048/gnome-power-ma
unix  3      [ ]         STREAM     CONNECTED     142586   6840/x-session-mana /tmp/.ICE-unix/6840
unix  3      [ ]         STREAM     CONNECTED     142585   7048/gnome-power-ma
unix  3      [ ]         STREAM     CONNECTED     142582   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     142581   7042/bluetooth-appl
unix  3      [ ]         STREAM     CONNECTED     142574   3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     142573   7042/bluetooth-appl
unix  3      [ ]         STREAM     CONNECTED     142566   3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     142565   7048/gnome-power-ma
unix  2      [ ]         DGRAM                    142383   6840/x-session-mana
unix  3      [ ]         STREAM     CONNECTED     142278   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     142277   7030/tracker-applet
unix  3      [ ]         STREAM     CONNECTED     142265   3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     142264   7030/tracker-applet
unix  3      [ ]         STREAM     CONNECTED     142188   7016/firestarter    /tmp/orbit-root/linc-1b68-0-2c02fb11e0695
unix  3      [ ]         STREAM     CONNECTED     142187   7029/gconfd-2
unix  3      [ ]         STREAM     CONNECTED     142184   7029/gconfd-2       /tmp/orbit-root/linc-1b75-0-28b12df8be890
unix  3      [ ]         STREAM     CONNECTED     142183   7016/firestarter
unix  3      [ ]         STREAM     CONNECTED     142182   2445/dbus-daemon    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     142181   7029/gconfd-2
unix  3      [ ]         STREAM     CONNECTED     142099   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     142098   7018/trackerd
unix  3      [ ]         STREAM     CONNECTED     142088   3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     142087   7027/dbus-launch
unix  3      [ ]         STREAM     CONNECTED     142090   7026/dbus-daemon    @/tmp/dbus-PH6XAQHRFQ
unix  3      [ ]         STREAM     CONNECTED     142086   7029/gconfd-2
unix  3      [ ]         STREAM     CONNECTED     142073   7026/dbus-daemon    @/tmp/dbus-PH6XAQHRFQ
unix  3      [ ]         STREAM     CONNECTED     142072   7016/firestarter
unix  3      [ ]         STREAM     CONNECTED     142071   7026/dbus-daemon
unix  3      [ ]         STREAM     CONNECTED     142070   7026/dbus-daemon
unix  3      [ ]         STREAM     CONNECTED     142056   3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     142055   7027/dbus-launch
unix  3      [ ]         STREAM     CONNECTED     142009   3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     142008   7016/firestarter
unix  3      [ ]         STREAM     CONNECTED     141849   6840/x-session-mana /tmp/.ICE-unix/6840
unix  3      [ ]         STREAM     CONNECTED     141848   7012/nautilus
unix  3      [ ]         STREAM     CONNECTED     141845   3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     141844   7012/nautilus
unix  3      [ ]         STREAM     CONNECTED     141757   6840/x-session-mana /tmp/.ICE-unix/6840
unix  3      [ ]         STREAM     CONNECTED     141756   7009/gnome-panel
unix  3      [ ]         STREAM     CONNECTED     141752   6955/pulseaudio     /tmp/.esd-1000/socket
unix  3      [ ]         STREAM     CONNECTED     141751   7009/gnome-panel
unix  3      [ ]         STREAM     CONNECTED     141744   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     141743   7009/gnome-panel
unix  3      [ ]         STREAM     CONNECTED     141684   7009/gnome-panel    /tmp/orbit-harrykar/linc-1b61-0-4048a68dbba31
unix  3      [ ]         STREAM     CONNECTED     141683   6958/gconfd-2
unix  3      [ ]         STREAM     CONNECTED     141680   6958/gconfd-2       /tmp/orbit-harrykar/linc-1b2e-0-7870703763584
unix  3      [ ]         STREAM     CONNECTED     141679   7009/gnome-panel
unix  3      [ ]         STREAM     CONNECTED     141677   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     141676   7009/gnome-panel
unix  3      [ ]         STREAM     CONNECTED     141668   3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     141667   7009/gnome-panel
unix  3      [ ]         STREAM     CONNECTED     141626   6840/x-session-mana /tmp/.ICE-unix/6840
unix  3      [ ]         STREAM     CONNECTED     141625   7007/metacity
unix  3      [ ]         STREAM     CONNECTED     141613   7007/metacity       /tmp/orbit-harrykar/linc-1b5f-0-22a8d8ff4a0bd
unix  3      [ ]         STREAM     CONNECTED     141612   6958/gconfd-2
unix  3      [ ]         STREAM     CONNECTED     141609   6958/gconfd-2       /tmp/orbit-harrykar/linc-1b2e-0-7870703763584
unix  3      [ ]         STREAM     CONNECTED     141608   7007/metacity
unix  5      [ ]         STREAM     CONNECTED     141601   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     141600   7007/metacity
unix  3      [ ]         STREAM     CONNECTED     141598   3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     141597   7007/metacity
unix  3      [ ]         STREAM     CONNECTED     141582   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     141581   6985/gnome-settings
unix  3      [ ]         STREAM     CONNECTED     141543   2445/dbus-daemon    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     141542   6991/seahorse-daemo
unix  2      [ ]         DGRAM                    141468   6991/seahorse-daemo
unix  3      [ ]         STREAM     CONNECTED     141458   6991/seahorse-daemo /tmp/orbit-harrykar/linc-1b4f-0-e18af7c816d
unix  3      [ ]         STREAM     CONNECTED     141457   6958/gconfd-2
unix  3      [ ]         STREAM     CONNECTED     141454   6958/gconfd-2       /tmp/orbit-harrykar/linc-1b2e-0-7870703763584
unix  3      [ ]         STREAM     CONNECTED     141453   6991/seahorse-daemo
unix  3      [ ]         STREAM     CONNECTED     141422   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     141421   6991/seahorse-daemo
unix  3      [ ]         STREAM     CONNECTED     141419   2445/dbus-daemon    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     141418   6991/seahorse-daemo
unix  3      [ ]         STREAM     CONNECTED     141413   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     141412   6991/seahorse-daemo
unix  3      [ ]         STREAM     CONNECTED     141375   3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     141374   6991/seahorse-daemo
unix  3      [ ]         STREAM     CONNECTED     141361   6826/gnome-keyring- /tmp/orbit-harrykar/linc-1aaa-0-f120f9afa9e
unix  3      [ ]         STREAM     CONNECTED     141359   6958/gconfd-2
unix  3      [ ]         STREAM     CONNECTED     141356   6958/gconfd-2       /tmp/orbit-harrykar/linc-1b2e-0-7870703763584
unix  3      [ ]         STREAM     CONNECTED     141355   6826/gnome-keyring-
unix  3      [ ]         STREAM     CONNECTED     141352   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     141351   6826/gnome-keyring-
unix  3      [ ]         STREAM     CONNECTED     141294   6985/gnome-settings /tmp/orbit-harrykar/linc-1b49-0-28b62a0c7b867
unix  3      [ ]         STREAM     CONNECTED     141293   6958/gconfd-2
unix  3      [ ]         STREAM     CONNECTED     141290   6958/gconfd-2       /tmp/orbit-harrykar/linc-1b2e-0-7870703763584
unix  3      [ ]         STREAM     CONNECTED     141289   6985/gnome-settings
unix  3      [ ]         STREAM     CONNECTED     141255   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     141254   6985/gnome-settings
unix  3      [ ]         STREAM     CONNECTED     141224   3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     141223   6985/gnome-settings
unix  3      [ ]         STREAM     CONNECTED     141168   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     141167   6979/gvfs-fuse-daem
unix  3      [ ]         STREAM     CONNECTED     141163   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     141162   6979/gvfs-fuse-daem
unix  3      [ ]         STREAM     CONNECTED     141140   6969/seahorse-agent /tmp/orbit-harrykar/linc-1b39-0-402935b7e3976
unix  3      [ ]         STREAM     CONNECTED     141139   6958/gconfd-2
unix  3      [ ]         STREAM     CONNECTED     141135   6958/gconfd-2       /tmp/orbit-harrykar/linc-1b2e-0-7870703763584
unix  3      [ ]         STREAM     CONNECTED     141134   6969/seahorse-agent
unix  5      [ ]         STREAM     CONNECTED     141129   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     141128   6969/seahorse-agent
unix  3      [ ]         STREAM     CONNECTED     141093   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     141091   6973/gvfsd
unix  3      [ ]         STREAM     CONNECTED     141081   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     141080   6969/seahorse-agent
unix  3      [ ]         STREAM     CONNECTED     140940   2445/dbus-daemon    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     140939   6840/x-session-mana
unix  3      [ ]         STREAM     CONNECTED     140924   6840/x-session-mana /tmp/orbit-harrykar/linc-1ab8-0-d093a88c59e8
unix  3      [ ]         STREAM     CONNECTED     140923   6958/gconfd-2
unix  3      [ ]         STREAM     CONNECTED     140920   6958/gconfd-2       /tmp/orbit-harrykar/linc-1b2e-0-7870703763584
unix  3      [ ]         STREAM     CONNECTED     140919   6840/x-session-mana
unix  3      [ ]         STREAM     CONNECTED     140873   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     140872   6840/x-session-mana
unix  3      [ ]         STREAM     CONNECTED     140869   3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     140868   6840/x-session-mana
unix  3      [ ]         STREAM     CONNECTED     140830   3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     140829   6969/seahorse-agent
unix  3      [ ]         STREAM     CONNECTED     140816   3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     140815   6955/pulseaudio
unix  3      [ ]         STREAM     CONNECTED     140783   2445/dbus-daemon    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     140782   6955/pulseaudio
unix  3      [ ]         STREAM     CONNECTED     140756   6956/gconf-helper   /tmp/orbit-harrykar/linc-1b2c-0-2564b77178b40
unix  3      [ ]         STREAM     CONNECTED     140755   6958/gconfd-2
unix  3      [ ]         STREAM     CONNECTED     140752   6958/gconfd-2       /tmp/orbit-harrykar/linc-1b2e-0-7870703763584
unix  3      [ ]         STREAM     CONNECTED     140751   6956/gconf-helper
unix  3      [ ]         STREAM     CONNECTED     140745   2445/dbus-daemon    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     140744   6958/gconfd-2
unix  3      [ ]         STREAM     CONNECTED     140342   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     140341   6958/gconfd-2
unix  5      [ ]         STREAM     CONNECTED     140325   6950/dbus-daemon    @/tmp/dbus-SkRIcZOQ1n
unix  3      [ ]         STREAM     CONNECTED     140324   6956/gconf-helper
unix  3      [ ]         STREAM     CONNECTED     140279   2445/dbus-daemon    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     140278   6955/pulseaudio
unix  3      [ ]         STREAM     CONNECTED     140258   3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     140257   6948/dbus-launch
unix  3      [ ]         STREAM     CONNECTED     140255   6950/dbus-daemon
unix  3      [ ]         STREAM     CONNECTED     140254   6950/dbus-daemon
unix  4      [ ]         STREAM     CONNECTED     140221   3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     140220   6948/dbus-launch
unix  3      [ ]         STREAM     CONNECTED     139597   2445/dbus-daemon    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     139596   3582/gdm
unix  3      [ ]         STREAM     CONNECTED     139571   2445/dbus-daemon    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     139570   6826/gnome-keyring-
unix  3      [ ]         STREAM     CONNECTED     107350   3333/winbindd
unix  3      [ ]         STREAM     CONNECTED     107349   6300/winbindd
unix  3      [ ]         STREAM     CONNECTED     107347   3333/winbindd
unix  3      [ ]         STREAM     CONNECTED     107346   6299/winbindd
unix  2      [ ]         STREAM     CONNECTED     107345   6299/winbindd       /var/run/samba/winbindd_privileged/pipe
unix  3      [ ]         STREAM     CONNECTED     28389    2445/dbus-daemon    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     28388    3645/cupsd
unix  2      [ ]         DGRAM                    12743    2814/console-kit-da
unix  2      [ ]         DGRAM                    10931    3993/logger
unix  2      [ ]         DGRAM                    10719    3965/perl
unix  3      [ ]         STREAM     CONNECTED     10023    2445/dbus-daemon    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     10022    3587/X
unix  4      [ ]         STREAM     CONNECTED     10052    3587/X              @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     10003    3582/gdm
unix  3      [ ]         STREAM     CONNECTED     9581     2445/dbus-daemon    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     9580     3678/system-tools-b
unix  3      [ ]         STREAM     CONNECTED     9541     2445/dbus-daemon    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     9540     3648/python
unix  3      [ ]         STREAM     CONNECTED     9348     2445/dbus-daemon    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     9347     3621/avahi-daemon:
unix  3      [ ]         STREAM     CONNECTED     9342     3622/avahi-daemon:
unix  3      [ ]         STREAM     CONNECTED     9341     3621/avahi-daemon:
unix  2      [ ]         DGRAM                    9339     3621/avahi-daemon:
unix  3      [ ]         STREAM     CONNECTED     9288     2348/acpid          /var/run/acpid.socket
unix  3      [ ]         STREAM     CONNECTED     9287     3587/X
unix  3      [ ]         STREAM     CONNECTED     8984     2445/dbus-daemon    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     8983     3521/bluetoothd
unix  2      [ ]         DGRAM                    8980     3521/bluetoothd
unix  2      [ ]         DGRAM                    8929     2348/acpid
unix  3      [ ]         STREAM     CONNECTED     8928     2348/acpid          /var/run/acpid.socket
unix  3      [ ]         STREAM     CONNECTED     8927     3503/acpid.socket
unix  3      [ ]         STREAM     CONNECTED     8921     3388/hald           @/var/run/hald/dbus-J8MtQBOfbD
unix  3      [ ]         STREAM     CONNECTED     8920     3503/acpid.socket
unix  3      [ ]         STREAM     CONNECTED     8900     3388/hald           @/var/run/hald/dbus-J8MtQBOfbD
unix  3      [ ]         STREAM     CONNECTED     8898     3501/fd0 because it
unix  3      [ ]         STREAM     CONNECTED     8896     2445/dbus-daemon    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     8895     3501/fd0 because it
unix  3      [ ]         STREAM     CONNECTED     8899     3388/hald           @/var/run/hald/dbus-J8MtQBOfbD
unix  3      [ ]         STREAM     CONNECTED     8884     3500/sr2 (every 2 s
unix  3      [ ]         STREAM     CONNECTED     8882     2445/dbus-daemon    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     8881     3500/sr2 (every 2 s
unix  3      [ ]         STREAM     CONNECTED     8885     3388/hald           @/var/run/hald/dbus-J8MtQBOfbD
unix  3      [ ]         STREAM     CONNECTED     8870     3499/sr1 (every 2 s
unix  3      [ ]         STREAM     CONNECTED     8867     2445/dbus-daemon    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     8866     3499/sr1 (every 2 s
unix  3      [ ]         STREAM     CONNECTED     8871     3388/hald           @/var/run/hald/dbus-J8MtQBOfbD
unix  3      [ ]         STREAM     CONNECTED     8856     3498/sr0 (every 2 s
unix  3      [ ]         STREAM     CONNECTED     8854     2445/dbus-daemon    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     8853     3498/sr0 (every 2 s
unix  3      [ ]         STREAM     CONNECTED     8084     3388/hald           @/var/run/hald/dbus-J8MtQBOfbD
unix  3      [ ]         STREAM     CONNECTED     8004     3418/event4
unix  3      [ ]         STREAM     CONNECTED     7887     3388/hald           @/var/run/hald/dbus-2CjEuqIUeb
unix  3      [ ]         STREAM     CONNECTED     7886     3389/hald-runner
unix  3      [ ]         STREAM     CONNECTED     7865     2445/dbus-daemon    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     7864     3388/hald
unix  2      [ ]         DGRAM                    7775     3364/ntpd
unix  3      [ ]         STREAM     CONNECTED     7735     3333/winbindd
unix  3      [ ]         STREAM     CONNECTED     7734     3341/winbindd
unix  3      [ ]         STREAM     CONNECTED     7634     2445/dbus-daemon    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     7633     3310/python
unix  2      [ ]         DGRAM                    7265     3200/monopd
unix  3      [ ]         STREAM     CONNECTED     7166     2445/dbus-daemon    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     7165     3191/su
unix  3      [ ]         STREAM     CONNECTED     6709     2445/dbus-daemon    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     6708     2814/console-kit-da
unix  3      [ ]         STREAM     CONNECTED     5965     2445/dbus-daemon
unix  3      [ ]         STREAM     CONNECTED     5964     2445/dbus-daemon
unix  2      [ ]         DGRAM                    5921     2422/klogd

-a shows all network connections
-n lists addresses as IP addresses (numbers) not host and domain names
-p lists the program that’s using the network

If you just ran that command, you’ll notice you got ample output. To read it before it screams off the top of your terminal, pipe the netstat command to less/more.
# netstat -anp | less
You’re really concerned with the services that are listed as LISTENING. These are network services, ready to be used and abused by anyone on the Internet, and after a default Linux install, all kinds of services are running that you don’t want or need.

The last column shows the PID (process ID) and program name that’s using that particular network resource. To stop the process right away, run kill -TERM 999 where 999 is the particular PID you want to stop. If kill -TERM won’t stop it, kill -9 will. (For more options, see the man page for kill.) That’s great for stopping the service immediately, but chances are, it’ll start back up the next time the server is rebooted.
Of course you’re thinking, But this is a Linux box! I’ll never have to reboot it! Accidents happen, hardware fails, power lines snap etc. Be prepared. To keep these services from starting up again, you have two choices:

Remove or modify the initialization script that starts the service, or
remove the entire software package.

To toy with the initialization scripts, look in the /etc/init.d/ directory. Each file in this directory is a script that stops, starts, or restarts a corresponding network service. The following output gives an example of some standard initializations scripts on a Ubuntu Linux system. What you see on your Linux system may be slightly different depending on your distribution and what software packages you chose at install-time.

harrykar@harrykar-desktop:~$ sudo ls /etc/init.d/
[sudo] password for harrykar:
acpid    killprocs      readahead
acpi-support   klogd       readahead-desktop
alsa-utils   laptop-mode      README
anacron    lighttpd      reboot
apache2    linux-restricted-modules-common  rmnologin
apmd    module-init-tools     rsync
apparmor   monopd      samba
apport    mountall-bootclean.sh     saned
atd    mountall.sh      screen-cleanup
avahi-daemon   mountdevsubfs.sh     sendsigs
binfmt-support   mountkernfs.sh     single
bluetooth   mountnfs-bootclean.sh     skeleton
bootlogd   mountnfs.sh      ssh
bootlogs.sh   mountoverflowtmp     stop-bootlogd
bootmisc.sh   mtab.sh      stop-bootlogd-single
brltty    mysql       stop-readahead
checkfs.sh   mysql-ndb      sysklogd
checkroot.sh   mysql-ndb-mgm      sysstat
clamav-freshclam  nessusd      system-tools-backends
console-setup   networking      udev
cron    NetworkManager     udev-finish
cups    ntp       ufw
dbus    ondemand      umountfs
dns-clean   openbsd-inetd      umountnfs.sh
exim4    pcmciautils      umountroot
firestarter   policykit      urandom
gdm    postgresql-8.3     usplash
ggzd    powernowd      vsftpd
glibc.sh   powernowd.early     webmin
hal    pppd-dns      wesnoth-server
halt    procps      wicd
hostname.sh   pulseaudio      winbind
hotkey-setup   rc       wpa-ifupdown
hwclock.sh   rc.local      x11-common
keyboard-setup   rcS
harrykar@harrykar-desktop:~$

The cheap-and-dirty way to stop these services from starting up is to make a new directory, and move the unwanted script to the new directory. This is like making mashed potatoes with a sledgehammer: effective but messy. The next time your server restarts, it will complain loudly about not being able to find the corresponding initialization script. Although, since it can’t find the script, the service will not start.

A more elegant method exists, but is usually different depending on which distribution of Linux you’re running.

Disabling services in Red Hat Linux
On Red Hat Linux, and most other distributions that are RPM-based (such as SuSE and Mandrake), you can use the chkconfig command to modify when these scripts are kicked off.

For example, to disable sendmail on your server, follow these steps:

1. Check to see when sendmail is called on to start and stop:

[root@redhatbox init.d]# chkconfig --list sendmail
sendmail 0:off 1:off 2:on 3:on 4:on 5:on 6:off

The numbers listed are run levels; you’re really only concerned with the default run level (which is what’s running right now, unless you did something non-default when you booted the system).

2. Check to see what run level you’re in, using the runlevel command:

[root@redhatbox init.d]# runlevel
N 3

Looks like we’re in run level 3 (the default for Red Hat, unless you’re running a GUI), and sendmail is set to run by default.

3. Disable sendmail for run levels 2, 3, 4 and 5:

[root@redhatbox init.d]# chkconfig --level 2345 sendmail off

4. Check to make sure your command actually worked:

[root@redhatbox init.d]# chkconfig --list sendmail
sendmail 0:off 1:off 2:off 3:off 4:off 5:off 6:off

Success! This process is a little less severe than removing the software package
entirely, and sendmail is a good thing to keep around, especially if you want to actually send mail someday.

Disabling services in Ubuntu and Debian GNU/Linux
In Ubuntu for each runlevel x you have a link in /etc/rcx.d to a script in /etc/init.d for the services that are to start/stop when entering this runlevel. (Links beginning with S start, those beginning with K stop a service)

So, for e.g. the FTP service, I have the /etc/init.d/proftpd startup/shutdown script plus the following set of symlinks referring to it:

/etc/rc0.d/K20proftpd -> ../init.d/proftpd
/etc/rc1.d/K20proftpd -> ../init.d/proftpd
/etc/rc6.d/K20proftpd -> ../init.d/proftpd
/etc/rc2.d/S20proftpd -> ../init.d/proftpd
/etc/rc3.d/S20proftpd -> ../init.d/proftpd
/etc/rc4.d/S20proftpd -> ../init.d/proftpd
/etc/rc5.d/S20proftpd -> ../init.d/proftpd

The procedure for disabling a service in Ubuntu is very simple: all you have to do is remove/rename the symlinks from all the runlevel-specific directories, /etc/rc*.d, so that no links are pointing to the original /etc/init.d script for your service. That original script will be kept, so you can re-enable the startup/shutdown of the service whenever you feel like using it again.

This example below shows how a service called "proftpd" was disabled on my system:

ubuntu# update-rc.d -f proftpd remove
Removing any system startup links for /etc/init.d/proftpd ...
/etc/rc0.d/K50proftpd
/etc/rc1.d/K50proftpd
/etc/rc2.d/S50proftpd
/etc/rc3.d/S50proftpd
/etc/rc4.d/S50proftpd
/etc/rc5.d/S50proftpd
/etc/rc6.d/K50proftpd

You obviously don't have to reboot your system just to stop your service though, so instead you can simply do this:

ubuntu# /etc/init.d/proftpd stop
* Stopping ftp server proftpd

That's all there is to it! In SystemV based systems instead update-rc.d one can use 2 Front-ends

sysv-rc--conf (GUI)
rcconf (TUI)

Debian
Debian Linux uses a different command respect to RH, but it follows a similar idea. The command is update-rc.d, and it gives you two general options:

You can tinker with the command syntax, and remove the service from specific run levels.
To be sure you get the job done right, you can remove the service from every run level, and here (again) you have two options:
1. The usual way to do so is to remove the init script from the/etc/init.d/ directory, and then let update-rc.d do the rest.
2. If you want to terminate the service gracefully, shut it down using the init script first, and then remove the init script.

In this section, as a classic example, we prevent sendmail from starting on our Debian system. The steps look like this:

Verify that the sendmail initialization script exists. To do so, change to the /etc/init.d directory and have a look at what’s listed there.
Create a directory to hold the initialization scripts you plan to remove:

# cd /etc/init.d
# ls sendmail
sendmail
# mkdir removed_init_scripts

Stop any running instances of sendmail:

# ./sendmail stop
Stopping Mail Transport Agent: sendmail.

Move the sendmail initialization script to the removed_init_scripts directory.

# mv sendmail removed_init_scripts/

After the initialization script is removed, run update-rc.d like this:

# update-rc.d sendmail remove
Removing any system startup links for /etc/init.d/sendmail ...
/etc/rc0.d/K20sendmail
/etc/rc1.d/K20sendmail
/etc/rc2.d/S20sendmail
/etc/rc3.d/S20sendmail
/etc/rc4.d/S20sendmail
/etc/rc5.d/S20sendmail
/etc/rc6.d/K20sendmail

Voilà! No more sendmail.

Disabling services in Gentoo Linux
Gentoo Linux (more formally known as Linux, The Next Generation) also has a script to ease the pain of manually enabling and disabling network services. Look at /sbin/rc-update. The following syntax removes the service (replace default with the run level your system booted into):

/sbin/rc-update -d yourservice default

Here’s what it looks like in action:

# cd /etc/init.d
# ls sendmail
sendmail
# rc-update -d sendmail default
* sendmail removed from the following run levels: default
* Caching service dependencies... [ ok ]
* rc-update complete.

Now that you know how to disable network services and other daemons, repeat the process for each network service that’s listening for connections until you have nothing but SSH left. To confirm, run netstat -anp again.

Only sshd should be left listening.

Compile from source code or install a binary?
Here, we’ll come across extra software that has to be installed to make your Snort box everything it wants to be. Since Snort is an open-source software project, its dependencies and prerequisite software pieces are also open-source. You must run your code through a compiler, a piece of software that turns the human-readable stuff (source code) into instructions that are specific to your machine. This is a kind of tailor-fit; the resulting machine code (often just called binary code) is optimized for your particular system.

Popping in the binary
But what about pre-compiled binaries? You may find the software we discuss available as .rpm files, .deb files, or .pkg files. These are pre-compiled binary packages: a package of files where the source-code has already been compiled for a particular architecture (i386, IA64, Sparc, whatever) and packaged with the necessary configuration files, man pages, and directions on where to put all of this stuff.

You simply tell your system to install the package, and it moves the files around accordingly. Most of the time, your package management software also checks for software dependencies and warns you accordingly, sometimes even downloading and installing the prerequisites for you (like Debian's apt-get package manager). That convenience can cost you. We favor compiling from source code instead. Read on . . .

Using the source
We’ll be telling you to download the source code and compile it yourself. Why? Well, let us count the ways . . .

Universal application. Compiling from source code is the same across all Linux distributions; a single set of instructions can guide you.
Open-source software is updated regularly. Getting the latest version can greatly enhance your peace of mind.
Each update is released as source code, not as a pre-compiled binary.Usually it’s up to someone who works for a company that markets a Linux-based product — or otherwise supports some distribution of Linux — to compile the source code to fit a specific architecture. This extra step alone often ensures that pre-compiled binary packages are a bit behind the freshly released source code — a few days at best, or several major revisions at worst. In one case, the binary package for Snort itself is so out of date that even installing it becomes a security risk. (you apt-get users know who you are.)
Compiling it yourself tailors the code to your system. Do yourself a favor — use the source, Luke! You’ll get the latest version of the software,compiled for your machine and your processor, not some faceless beige box.
Everybody needs a hobby, right? If you getinvolved in the software deeply enough, you’ll love having the source code available to dig through (or possibly even modify). If you’re not familiar with compiling software from source, just take a deep breath and take it slow. The directions we include will get you there, and all the software we list comes with ample documentation should you find yourself lost in the woods.

Securing the SSH Daemon

A daemon is just another name for a program that usually starts automatically, and runs constantly in the background.

Assumed you’ve turned off all extraneous network services and kept ’em off. There’s one remaining service to look at: the SSH daemon. Unless you like sitting at a terminal in front of your Snort box every time you need to check on it, leave the SSH daemon running so you can access your Snort system remotely.

OpenSSH is the de facto standard in modern Linux distributions because it’s open-source and free. SSH stands for Secure SHell, but how secure is it? If you’re running an older version of SSH, chances are good that your system is a far cry from being secure. To see just how secure or insecure your version is, check out their Web site for a brief history of security vulnerabilities in OpenSSH. We recommend starting with the latest (therefore most secure) version. If you’re running the SSH daemon that shipped with your Linux distribution, you’re probably running its precompiled SSH binary package.

Not a problem —exactly — except some Linux vendors (most notably Red Hat) release patched versions of their software without changing the revision number for that software package. For example, if you’re running kewlserver-3.14 and a security vulnerability is discovered, the maintainers of kewlserver normally release a software patch, and then re-release the patched software as kewlserver-3.15. Your Linux vendor may only fix the security vulnerability and not the revision number. Thus, if you install the updated .rpm (or .deb or .pkg) package, your kewlserver may no longer have a security vulnerability — but it may still report itself as kewlserver-3.14.

The moral of this story is that if you’re running software from a package, check with the maintainer of that package to make sure it’s a secure version of the software.
To upgrade your version of OpenSSH, either

Check for updated packages for your particular Linux distribution.
Grab the latest source code and start compiling.

PGP and hashing: accept no substitutes
When you download source code from the Internet, how can you be sure that what you’re downloading is exactly what the author wrote? How can you be sure that someone hasn’t tampered with the code? Even if you’re downloading the source code from some crew of self-proclaimed security gurus, how do you know someone else hasn’t already cracked their server and replaced the original code with something far more nefarious? The answer is to check the software for either

a PGP signature or
an MD5 hash.

PGP signature
To guarantee a file’s integrity, the software author uses his or her own PGP (Pretty Good Privacy) encryption key to “sign” the software. This process creates a string of characters indicating that the author — and only the author — declares that the software has not been tampered with. GnuPG is a free, open-source program that uses the OpenPGP standards and comes with most Linux distributions (if you don’t have it, you can get it. If you’re not up to speed on public-key encryption, check out the International PGP home page, where you’ll find more of documentation and FAQs.

The following demonstration uses the GnuPG command gpgv for signature verification. Chances are, you don’t already have the software author’s public key on your PGP keyring, so the following session also shows how to grab it and use it.

Traditional encryption systems relied on a single secret key to encrypt and decrypt data. This worked well, but it meant that both the sending and receiving parties had to know the secret key.
Public key encryption uses two different keys that are mathematically related to each other; one is a secret key available only to its owner, and the other is a public key available to the public at large. This encryption scheme means you can send an encrypted message to someone you’ve never met before, using his or her public key, and you can be sure that person is the only one who can decrypt it (since that person is the only one who has access to that private key).

$ wget -q ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-3.7.1p2.tar.gz
$ wget -q ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-3.7.1p2.tar.gz.sig
$ gpgv openssh-3.7.1p2.tar.gz.sig
gpgv: /home/snortfd/.gnupg/trustedkeys.gpg: keyring created
gpgv: Signature made Tue Sep 23 04:56:21 2003 CDT using DSA key ID 86FF9C48
gpgv: Can’t check signature: public key not found
$ gpg --keyserver pgp.mit.edu --recv-keys 86FF9C48
gpg: /home/snortfd/.gnupg/secring.gpg: keyring created
gpg: /home/snortfd/.gnupg/pubring.gpg: keyring created
gpg: requesting key 86FF9C48 from pgp.mit.edu ...
gpg: key 86FF9C48: public key imported
gpg: /home/snortfd/.gnupg/trustdb.gpg: trustdb created
gpg: Total number processed: 1
gpg: imported: 1
$ gpgv openssh-3.7.1p2.tar.gz.sig
gpgv: Signature made Tue Sep 23 04:56:21 2003 CDT using DSA key ID 86FF9C48
gpgv: Can’t check signature: public key not found
$ gpgv --keyring ~/.gnupg/pubring.gpg openssh-3.7.1p2.tar.gz.sig
gpgv: Signature made Tue Sep 23 04:56:21 2003 CDT using DSA key ID 86FF9C48
gpgv: Good signature from “Damien Miller (Personal Key) ”

MD5 hash
An MD5 hash is a type of encryption code generated when the encryption software examines a file and uses a mathematical “hashing” process to generate a single line of text based on the entire contents of the software file. If you change a single character in the file, the MD5 hash code is no longer the same. The following transcript shows the user downloading the latest version of Apache for Linux and checking its MD5 sum.

$ wget -q http://apache.webmeta.com/httpd/httpd-2.0.48.tar.gz
$ wget -q http://apache.webmeta.com/httpd/httpd-2.0.48.tar.gz.md5
$ cat httpd-2.0.48.tar.gz.md5
466c63bb71b710d20a5c353df8c1a19c httpd-2.0.48.tar.gz
$ md5sum httpd-2.0.48.tar.gz
466c63bb71b710d20a5c353df8c1a19c httpd-2.0.48.tar.gz

As you can see in the transcript, the MD5 sum that was published by Apache jives with the output from our own md5sum command, so we know that the software we just downloaded hasn’t been tampered with.

Configure, Make,and Make Install Defined
At first glance, Linux can be an intimidating beast, but first impressions are not always accurate. Although this might seem like a long process just to install a piece of software, it really is worth the effort. Unlike shrink-wrapped software, compiling from source code is almost always better because it is being made specifically for your system. Prepackaged software is always built for the lowest common denominator, so if the programmer’s target lowest machine is a 100MHz Pentium, that is what you get … software built to run on a 100MHz Pentium. If you have a 2GHz processor, you will not be taking advantage of all of the optimizations for your processor. When you compile software on Linux, it is being made by you, and for you. Each machine you compile it on will have its own unique
setup. We are not saying that all prepackaged software is bad, because
it’s not. But we just wanted to point out the benefits of doing it the Linux way. You’ll thank us for it later. Let’s get on with the show…

Most software developed for Linux is distributed in what is known as a tarball. A tarball is nothing more than a compressed file containing other files and/or directory structures. We like to equate it to a zip file created with WinZip (for those of us familiar with the Windows OS). Tarballs can come in several formats, the most popular end with the extensions of tgz, tar.gz, or tar.bz2. Each extension signifies a specific compression algorithm that was used to create the file. Depending on the source, the extensions might differ, but they are all capable of being extracted by modern versions of the tar program. Tar is a console program designed to create and extract compressed archives. You can read more about tar and its features. It comes as a standard package with almost every Linux distro, but you can get the latest version at that address as well.

When you receive a tarball, the first step is to extract it into a temporary
directory where you can work with it. /tmp is usually a good place to accomplish this task. Once the tarball is extracted, verify that the archive created a new directory (they usually do) with its contents. In some cases, it might extract into your current working directory. In any case, locate a file named configure. The configure file is always located in the “root” (this directory is usually named after the package name) directory of the files you just extracted. This is the main directory you will be working from to install your software package. You will almost always use these three commands successively:
./configure The configure file is a script that contains code designed to essentially “figure out” the machine on which it is running. It looks at environment variables, dependencies, and verifies what software, if any, is missing. If you watch the screen when it is running, you will see a lot of questions and answers flying by. This is exactly what is going on. It is checking to make sure that everything is where it is supposed to be. The configure script is responsible for generating the makefile, which will become important in the next step. If you see any errors here, you will need to tend to them before continuing. Most issues will be cleared up by installing whatever dependency the configure script was missing. When all dependencies are fulfilled, you can run configure ure again.
make The make command is a part of almost every UNIX/Linux installations in existence today. It is not a script like configure is, but an actual utility. Make will use the makefile created by the configure script in the last step. The primary function of make is to compile the code to be used during the final install. It accomplishes this by reading and executing the code in the makefile in a specific order determined by the configure script. The makefile is similar in layout to an initialization file in that it has “headings” or categories for each step of the make process. One of these headings is install, which is used in the next step by make install. Again, it is important to note any errors during the compilation process to make sure you take care of them before continuing.
make install This is the final step of the installation process. What make install does is fairly simple: it reads the information from the install section of the makefile and distributes the executables and other files created by make to the proper locations in the machine’s directory structure. Once this step is complete (without error), the software is installed and ready to use.

Compiling the code
The instructions for compiling software are generic and should work across the majority of Linux distributions without modifications. If you suspect that your installation is significantly different from a generic installation, or if you’re curious to see what kind of options are available, you can run ./configure --help (which makes the configure script list all options) at compile time.

OpenSSH depends on OpenSSL. OpenSSL has had its share of security vulnerabilities as well, so make sure you run the most recent version. Here’s the royal road to compiling and installing OpenSSL and OpenSSH:

Download the source code from OpenSSL and put it somewhere convenient on your system. A good place for source code is in /usr/local/src/. A good place to put downloaded software as a compressed tarball (Unix slang for a bunch of files stuck together in file with a .tar , .tar.Z, tar.gz,or .tgz extension) would be a directory such as /usr/local/src/tarballs/. You can delete the tarball and the source directory later. If (like us) you like working with a bit of a safety net, keep the tarball and source around until you’re sure you don’t need ’em anymore (say, after the next version is released). Downloading, compiling, and installing openssl looks like this:

# cd /usr/local/src/tarballs/
# wget http://www.openssl.org/source/openssl-0.9.7c.tar.gz
# wget http://www.openssl.org/source/openssl-0.9.7c.tar.gz.asc
# gpgv openssl-0.9.7c.tar.gz.asc
gpgv: Signature made Wed Mar 17 06:09:54 2004 CST using RSA key ID 49A563D9
gpgv: Can’t check signature: public key not found
# gpg --keyserver pgp.mit.edu --recv-keys 49a563d9
gpg: requesting key 49A563D9 from pgp.mit.edu ...
gpg: key 49A563D9: public key imported
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
# gpgv --keyring ~/.gnupg/pubring.gpg openssl-0.9.7d.tar.gz.asc
gpgv: Signature made Wed Mar 17 06:09:54 2004 CST using RSA key ID 49A563D9
gpgv: Good signature from “Mark Cox ”
gpgv: aka “Mark Cox ”
# cd ../
# tar -xvzf tarballs/openssl-0.9.7c.tar.gz
# cd openssl-0.9.7c/
# script ~/openssl.install.notes
# ./config shared
# make
# make test
# make install
# echo “/usr/local/ssl/lib” >>/etc/ld.so.conf
# ldconfig
# exit

tar –zxvf file.gz
The -z option specifies that the file needs to be processed through the gzip filter. You can tell if an archive was created with gzip by the .gz extension.
The -x option dictates that you want the contents of the archive to be extracted. By default, this action will extract the contents into the current working directory unless otherwise specified.
The -v option stands for verbose, which means that tar will display all files it processes on the screen. This is a personal preference and is not critical to the extraction operation.
The -f option specifies the file that tar will process. In our current example, this would be file.gz. Sometimes it might be necessary to specify a full path if the file you want to work with is located in another directory.

OpenSSL installs without a hitch (well, we can hope, right?). And every good OpenSSL needs an OpenSSH, so . . .

As a preparation for installing OpenSSH, set up the script command to keep a log of what’s going on. The code that tells script what to watch for looks like this:

# cd /usr/local/src/tarballs/
# wget ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-3.7.1p2.tar
# cd ../
# tar -xvzf tarballs/openssh-3.7.1p2.tar.gz
# cd openssh-3.7.1p2/
# script ~/openssh.install.notes
# ./configure --with-pam
# make
# make install
# exit

If your Linux distribution uses Pluggable Authentication Modules (PAM) (most, including RedHat), you’ll want to read the documentation distributed with the OpenSSH software and run configure with the --enable-pam switch. Otherwise you’ll quickly find yourself locked out of your own box!

Let your script do the watching . . .
The Unix command script watches all visible input/output through the terminal and logs it to a text file somewhere. If you’re on a fast enough system, you’re going to have a hard time keeping up with the text as it flashes skyward on your terminal. The script command is invaluable when looking for configure warnings or other errors that may not kill the configure script, but will cause headaches down the road.
The syntax is script somefile where somefile is the file to capture the terminal session; script -a somefile will append to your log file, instead of overwriting it. To exit a script session, just type exit when you’re done, and the program stops logging your terminal session.

To ensure that the SSH daemon starts when your machine does, make sure you have an initialization (init) script in /etc/init.d/. The initialization script that was there originally may not work anymore, especially if the version of SSH that came with your system lives at /usr/sbin/sshd and the one you just installed lives in /usr/local/sbin/sshd. Various handy, fresh init scripts are distributed with OpenSSH; you can find them in subdirectories of the $openssh_source/contrib/ directory.
Choose a port for the SSH daemon. Yes, you can choose the default port (22), but for an alternative — a little cyber-hot-rodding that makes good practical sense.

Bringing OpenSSH into port
Although unorthodox settings may head off a little unauthorized fumbling by users, any network-security geeks worth their weight in bits will tell you: Security-through-obscurity isn’t a recommended strategy. Even so, sometimes a “creative” departure from the default has its place. For example, why bother running the latest version of SSH on the default port (22)? Why let every one in the world bang on your SSH server when you’ll only be allowing a small handful of people (maybe only yourself) access to the machine? Here you can run the SSH daemon on a non-standard port. Pick a port that’s not already in use, and one you can remember. You have 65535 ports to choose from, so choose wisely. If you’re changing the default port that the SSH daemon listens to, you can make another couple of changes while you’re at it.
Specifically, you want to allow only SSH traffic that uses SSH protocol version 2, since it is more secure than version 1. This can cause problems with some older SSH clients though, since some only support version 1 of the protocol. Check your client before making this change.
Also, it’s a good practice to deny root logins that use SSH,
not to allow folks to connect using empty passwords.

Specify a port for the SSH daemon by editing the appropriate lines in your sshd config file. Most likely your configuration file is /etc/ssh/sshd_config if you’re using the version that came with your Linux distribution. It should be /usr/local/etc/sshd_config if you compiled from source using the default values. Those default values have pound signs (#) in front of them to indicate that what follows is a comment, and is safe to ignore. If you don’t want to use the default values, make sure you change them, and remove the pound sign. When you’re done, the following lines (not necessarily in this order) in your sshd_config file should look like this:

Port 65432
Protocol 2
PermitEmptyPasswords no
PermitRootLogin no

That’s it. You’ve got OpenSSL and OpenSSH installed and ready to rock.

Physical security
When your system is secure from a cyber-world perspective, it’s time to make sure it’s secure from a real-world perspective. The principal component of physical security is restricting physical access to the system. If you’ve already got a server-closet/systems-room/data-center environment for your servers, chances are you only allow certain folks in there. That’s great, but it’s just a start. Try to stay practical if you impose any additional physical-security measures. Start (maybe stop?) with the obvious:

Restrict access to the power switch.
Restrict access to specific CD-ROM or floppy drives by using a server case that has a locking faceplate. Keep the key in a safe place. Some other suggestions you may hear — such as using a BIOS password are overkill. Remember, you want the system to restart without intervention in case of a power outage. If you’re super-paranoid about physical access, check out the man page for your LILO or Grub, depending on which you’re using. Additional lock-down methods are available. One of the most effective security measures for physically securing your server is also one of the easiest: Unplug the keyboard. It sounds trivial, but it’s vital, especially if your server is on a switch box, sharing keyboard, video, and mouse (KVM) with other systems. We have had Linux servers spontaneously rebooted by slap-happy Windows administrators giving a three-finger salute (simultaneously pressing the Ctrl+Alt+Del keys) to every blank screen on a KVM switch when looking to log on to their Windows server. While Ctrl+Alt+Del will give you a login prompt in Windows, unless you’ve changed this default behavior, it will reboot a Linux box.

Loose ends
When you have a secure system, take a minute and look things over.

Reboot your system to make sure everything starts up as expected.
Is sshd running?
What port is it running on?
Anything else running? Use netstat -anp to make sure.
Is root allowed to log in using SSH?

If everything looks good to you you’re ready to install Snort and MySQL, and you’ll need your wits about you for this one.

Installing MySQL for Linux

MySQL touts itself as the world’s most popular open-source database, and with good reason. With more than 4 million active installations, many of the world’s largest organizations — including Yahoo!, The Associated Press, and even those rocket scientists at NASA — are running MySQL. And you can too, if you aren’t already.

Getting the code
This is one place where we deviate from our “Use the Source” mantra, and say it’s okay to use MySQL from pre-compiled binaries. In fact, the MySQL Web site recommends it.

Installing MySQL goodies from the Linux package
Since practically every version of Linux includes MySQL, you probably already have it installed. If so, you’ve got a few matters to look at:

Make sure you have both the client and server pieces installed. If you do, you can skip ahead to the Installing Snort section. If not, ask yourself whether you want to

• Compile from source
• Install binaries from MySQL.org
• Install a binary package from your Linux distribution

If you install precompiled binary packages from your Linux distribution, make sure you get all the included MySQL packages. Typically, there are separate packages for

• The client
• The server
• Documentation
• A collection of “common files” needed by both client and server

If you’re not sure about what you need, or you’re having a hard time figuring it out, try compiling from source code. (You knew we were going to say that.) There’s not too much hassle involved, but be prepared to give your compiler some time to work. This is a complex software package, and you may have time before the whole installation is finished.

Installing MySQL from source code
MySQL is available here. Make sure you check its note regarding licensing costs. MySQL is covered under the GPL (GNU Public License), and unless you want support, a warranty, or you have plans to distribute MySQL code as part of your non-open-source software, you don’t need a commercial license. There are two ways you can download MySQL:

As actual source code: You can compile it for your system.
As a glob of binary files: These have already been compiled for your system by the fine folks at MySQL. This is different than the binary package put out by your Linux vendor, in that these binaries are not specific to a certain distribution of Linux, but are released for a specific architecture, (such as i386 or IA64).

We detail (next) how to install using the source code. That’s because it should be the same regardless of which version of Linux you use.

Preparing your system for MySQL
Before installing the software on your system, save yourself some hassle:
Get it ready for a MySQL installation. First item of business is to check your system to see whether it already has a MySQL user account and group in place. Here’s what the process looks like:

1. Check for a MySQL user account by issuing this command:

#cat /etc/passwd | grep -i mysql

If the command doesn’t produce any output, then you don’t have a MySQL user account.

2. Look for a MySQL group in the /etc/group file (you need one there too), using this command:

#cat /etc/group | grep -i mysql

If you do get output from this command (or the one in Step 1), chances are you already have MySQL installed on your system. Here’s what the output looks like on a system that already has MySQL installed:

harrykar@harrykar-desktop:~$ cat /etc/passwd | grep -i mysql
mysql:x:115:130:MySQL Server,,,:/var/lib/mysql:/bin/false
harrykar@harrykar-desktop:~$ cat /etc/group | grep -i mysql
mysql:x:130:
harrykar@harrykar-desktop:~$

3. Make sure that the root user account can execute MySQL commands. To do so, check the root account’s $PATH variable to see whether the MySQL executable path

harrykar@harrykar-desktop:~$ which mysql
/usr/bin/mysql

(e.g. /usr/local/mysql/bin) is in there. If it’s not there, edit /root/.bash_profile (sometimes installed as /root/.profile) to put /usr/local/mysql/bin into the PATH statement for root. To take advantage of this change, you’ll either have to log out and then log back in, or type:

# source ~/.profile

The profile is only read at login, so this step forces your system to reread your profile and apply any changes you may have made.

4. Make sure your files and permissions are set up correctly to accommodate MySQL.
With the MySQL executable path in place and your permissions set correctly, you’re ready to compile MySQL.

Compiling and installing MySQL
Compiling the MySQL from source code (rather than installing binaries) requires a little attention to detail. For example, make sure you grabbed the right software package before you install what’s in there (remember there are different packages for the client, server, common files, and documentation).

The command tar -tvzf mysql-package.tar.gz is a handy way to check, since it will tell you what files are in a tarball without actually extracting them. Assuming you downloaded the right tarball to /usr/local/src/tarballs/, you’re ready to proceed with the installation.

Doing the installation and configuration
Here’s the drill for installing MySQL:

1. Change to the directory from which you want to unpack your MySQL source code:

# cd /usr/local/src

2. Check the MD5 sum or PGP signature on your downloaded source code and compare it to the signature on the mysql.com Web site at

# md5sum mysql.tar.gz

3. Using the tar command, un-gzip and un-tar the source code:

# tar -xvzf /usr/local/src/tarballs/mysql.tar.gz

4. Change to the mysql directory that was created in your source directory.

5. Run the configure program:

# cd mysql/
# ./configure --prefix=/usr/local/mysql

The --prefix flag identifies the directory where you want to install MySQL (we recommend /usr/local/mysql). Don’t worry if this directory doesn’t yet exist; the installation creates it.

6. Build and install MySQL with the make and make install commands:

# make
# make install

7. Run the echo and ldconfig to tell your Linux system how to find the MySQL shared libraries (which Snort needs to access):

# echo “/usr/local/mysql/lib/mysql” >>/etc/ld.so.conf
# cat /etc/ld.so.conf
# ldconfig

Here echo adds a line to your library configuration file, ld.so.conf.
The ldconfig command reloads that configuration file. Some distributions (notably Gentoo) automatically generate this file; check your distribution’s documentation if you’re unsure.

password for root
If the root password is cracked, it’s like giving anyone the keys to the city and the treasure vault. When you set a password, make it tough to crack but possible for you to remember. Avoid writing it down; if you absolutely must write it down, put it somewhere seriously secure. It’s not easy to reset the root password if you’ve forgotten it, so make it stick. Make yours something obscure to anyone but you. Using a combination of letters, numbers, and punctuation can help make it more secure, as does avoiding dictionary words, phone numbers, names, and dates.

8. Run the script command as follows:

# scripts/mysql_install_db

This command sets up the initial mysql database that MySQL uses for its internal configuration.

9. Run the mysqladmin program to set a root password for your MySQL server. You don’t want to leave your databases wide open for anyone to administer! Behold and heed our admonitory sidebar — and for maximum safety, run the mysqladmin program as shown here:

# /usr/local/mysql/bin/mysqladmin -u root -h localhost
password ‘new-password’

10. Change the permissions on the newly created directories, and run ldconfig against /usr/local/lib/:

# chown -R root /usr/local/mysql/
# chown -R mysql /usr/local/mysql/var
# chgrp -R mysql /usr/local/mysql
# cp support-files/my-medium.cnf /etc/my.cnf
# cat /etc/ld.so.conf
# echo “/usr/local/lib” >>/etc/ld.so.conf
# ldconfig -v

Checking the installation
Check to make sure all this stuff worked. Here’s how:

1. Type the following at a command prompt:

/usr/local/mysql/bin/mysqld_safe --user=mysql &

If you get no error messages, you should see the MySQL server listing in the process list:

harrykar@harrykar-desktop:~$ ps -ef | grep -i msyql
harrykar  8898  8879  0 03:04 pts/0    00:00:00 grep -i msyql

2. Check the process list for the following bunch of entries:

root      2517     1  0 Jun01 ?        00:00:00 /bin/sh /usr/bin/mysqld_safe
mysql     4084  2517  0 Jun01 ?        00:02:15 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-external-locking --port=3306 --socket=/var/run/mysqld/mysqld.sock

if you see ten or twelve of these lines, don’t panic; this is normal. If you don’t see any of these lines, check the log files in /usr/local/mysql/var/ for errors.

3. If your MySQL server is running, make sure the MySQL daemon starts and stops when your server (respectively) boots up and shuts down. If your MySQL source is in /usr/local/src/mysql, look for the following file and copy it to /etc/init.d directory:

/usr/local/src/mysql/support-files/mysql.server

MySQL — at your service
Starting and stopping the MySQL daemon at startup and shutdown works especially well when you enable MySQL as a service. You can do so by using the tools and scripts listed in the “Disabling Services” section, or you can do so manually by creating links to the initialization script from the appropriate rc.d directory.

4. To start and stop the MySQL daemon when the system enters or exits the default run levels, use the commands in the “Disabling Services” section, or issue the following commands:

# cd /etc/rc3.d
# ln -s ../init.d/mysql.server S85mysql
# ln -s ../init.d/mysql.server K85mysql
# cd ../rc2.d
# ln -s ../init.d/mysql.server S85mysql
# ln -s ../init.d/mysql.server K85mysql
# cd ../rc5.d
# ln -s ../init.d/mysql.server S85mysql
# ln -s ../init.d/mysql.server K85mysql
# cd ../init.d/
# chmod 755 mysql.server

5. Reboot your server to check the effectiveness of your initialization scripts. No time like the present. After all, Snort’s not installed yet, the machine isn’t in production, and there’ll be plenty of time for accumulating uptime soon.

Installing Snort for Linux

Is strongly recommend going to www.snort.org and downloading the very newest stable release, as you will benefit from

new functionality
bug fixes
stability
speed enhancements.

This software is constantly changing, growing, and getting better every day. Installing a base Snort system is actually pretty easy, if you don’t want any fancy frills. Here we details how to install and configure Snort and how to configure the MySQL databases for logging all of Snort’s output. Other databases are available for Snort’s logging, but MySQL is by far the most popular with Snort, and it’s got the greatest amount of support out there, so that’s what we’ve detailed.

Snort won’t run on its own, and requires some underlying software to run. Here’s a lineup of the usual suspects . . .

Setting up libpcap (Installing libpcap from Source)

One required piece of software for Snort is libpcap, a packet-capture library for Linux systems. It’s available here and installs easily. Don’t forget to check the digital signature! What is unique about this library is that it can capture packets destined for the local hosts, and can also pick up packets destined for other hosts on the network.This, in essence, means that you can place a machine in a strategic location (see Figures) on your network and have it analyze the packets that travel through. Snort requires this library to function, and it is best to download the newest version of it every time you install or upgrade Snort.The benefits of getting the newest release are twofold: You will realize increased stability and speed running the program. Even if your system already has a version of PCAP (such as Red Hat Linux) you should follow this advice.

Installing libpcap from the source tarball is relatively simple, especially for those
familiar with compiling source code. The only thing you really need to make sure
of is that you have chosen to install development tools into your original OS
install. These tools should include the following, and probably more depending
on your distribution of choice

gcc The GNU cc and gcc C compilers.This is the core of your development tools; nothing else functions without it.
automake The GNU utility for creating makefiles on-the-fly.
autoconf The GNU utility for configuring source code on-the-fly.
binutils GNU binary utilities.
make The GNU tool for making life easier for the individual compiling the code. It automates much of the process by using the makefile.

We will be following the common configure | make | make install format for building the package into the system. Don’t be afraid; this is pretty simple as long as
your system has the tools described in the last section.

Assuming you’ve downloaded the source to /usr/local/src/tarballs and you wish to untar it to /usr/local/src/ like this:

# cd /usr/local/src/tarballs
# gpgv libpcap-0.7.2.tar.gz.asc
gpgv: Signature made Wed Feb 26 01:36:50 2003 CST using DSA
key ID 89E917F3
gpgv: Can’t check signature: public key not found
# gpg --keyserver pgp.mit.edu --recv-keys 89E917F3
gpg: requesting key 89E917F3 from pgp.mit.edu ...
gpg: key 89E917F3: public key imported
gpg: Total number processed: 1
gpg: imported: 1
# gpgv --keyring=~/.gnupg/pubring.gpg libpcap-
0.7.2.tar.gz.asc
gpgv: Signature made Wed Feb 26 01:36:50 2003 CST using DSA
key ID 89E917F3
gpgv: Good signature from “tcpdump.org (SIGNING KEY)
”
# cd ../
# tar -xvzf ../tarballs/libpcap-3.7.2.tar.gz
# cd libpcap-3.7.2/
# script ~/libpcap.install
# ./configure
# make
# make install
# exit

Setting up PCRE
Snort requires PCRE to build. PCRE stands for Perl-Compatible Regular Expressions, and Snort now lets you write rules using this powerful text-matching syntax. PCRE is gaining popularity every day, and by the time you read this, you may already have it
installed on your system. We didn’t, so here’s how to get and install it:

# cd /usr/local/src/tarballs
# wget -q ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-4.5.tar.gz
# wget -q ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-4.5.tar.gz.sig
# wget -q ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/Public-Key
# gpg --import Public-Key
gpg: key FB0F43D8: public key imported
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
# gpgv --keyring ~/.gnupg/pubring.gpg pcre-4.5.tar.gz.sig
gpgv: Signature made Wed Dec 10 10:45:53 2003 CST using RSA key ID FB0F43D8
gpgv: Good signature from “Philip Hazel ”
gpgv: aka “Philip Hazel ”
# tar -xvzf tarballs/pcre-4.5.tar.gz
# cd pcre-4.5/
# script ~/notes/pcre.install
Script started, file is /root/notes/pcre.install
# ./configure
# make
# make install

Adding the /usr/local/lib line
Make sure your /etc/ld.so.conf file has a /usr/local/lib line in it, which it should if you installed MySQL as shown in the “Compiling and installing MySQL” section. If not, add it in, and run ldconfig as root. We haven’t typed exit yet, so we’re including this step in the script output for the record.

# echo “/usr/local/lib” >>/etc/ld.so.conf
# ldconfig -v
# exit

Script done, file is /root/notes/pcre.install

Downloading and compiling Snort

The latest version of the Snort source code is available . The Snort home page will list what the latest stable version available for download is. Check for new source code early and often. Updates from developers are frequent. Subscribing to the various Snort mailing lists is an easy way to keep up to date with the latest Snort news. The Snort-Announcements list is very low volume, typically limited to new software announcements. You can find a link to the mailing lists on the snort.org Web site.
Software updates typically mean new software features, so check in on the Snort Users mailing list occasionally to see what’s new, and what other people are having trouble with; chances are you might be having the same problem.

Preparing your system for Snort
Snort can run under its own user account in its own group. This arrangement allows you to run some very powerful software as someone other than root, which is always nice when you consider the fact that the software is designed to indiscriminately read and parse wild packets from the Internet.

Adding the Snort user account and group
After all that build-up installing Snort’s prerequisites, you might find the actual steps for installing Snort disappointingly simple.

1. Run the following commands as root to add the Snort user and group:

# groupadd snortgroup
# useradd -g snortgroup snortuser

2. Make a directory for your Snort configuration file. You can put it anywhere. We use /usr/local/snort/etc (the -p switch will create the parent directory /usr/local/snort as well as the etc directory underneath it).

# mkdir -p /usr/local/snort/etc

3. Create a directory for Snort’s log file. /var/log/snort sounds good to us.

# mkdir /var/log/snort

Downloading Snort
It’s time to download Snort, if you haven’t already. Don’t forget to check the PGP signature, or at least the MD5 sum. We didn’t already have the public key for the Snort.org release team — and chances are, you won’t either — so we’ve included the step to download the public key, after which you should recheck the digital signature on the tarball.

# wget -q http://www.snort.org/dl/snort-2.1.0.tar.gz
# wget -q http://www.snort.org/dl/snort-2.1.0.tar.gz.asc
# gpgv snort-2.1.0.tar.gz.asc
gpgv: Signature made Thu Dec 18 11:16:50 2003 CST using DSA key ID 1946E4A1
gpgv: Can’t check signature: public key not found
# gpg --recv-keys --keyserver pgp.mit.edu 1946E4A1
gpg: requesting key 1946E4A1 from pgp.mit.edu ...
gpg: key 1946E4A1: public key imported
gpg: Total number processed: 1
gpg: imported: 1
# gpgv snort-2.1.0.tar.gz.asc
gpgv: Signature made Thu Dec 18 11:16:50 2003 CST using DSA key ID 1946E4A1
gpgv: Can’t check signature: public key not found
# gpgv --keyring ~/.gnupg/pubring.gpg snort-2.1.0.tar.gz.asc
gpgv: Signature made Thu Dec 18 11:16:50 2003 CST using DSA key ID 1946E4A1
gpgv: Good signature from “Snort.org releases ”

Opening the Snort tarball
Let’s un-tar this pig and get compiling.

1. We’re going to work out of /usr/local/src/snort-version/ so we move up a directory to run tar.

# cd /usr/local/src
# tar -xvzf tarballs/snort-2.1.0.tar.gz

2. Run the configure script, which will make several determinations about the best way to compile the software for your system. We’ve listed some of the more popular configuration options in our text, but others may be right for you. Run the configure script with the help option ./configure —help to see what other options are available (These were harvested from the INSTALL file in the Snort 2.x.x tarball), and whether they make sense for you to use; pipe the output to more or less for easier reading, or redirect it to a file to peruse later.

--enable-debug Enable debugging options (bug reports and developers only).
--with-snmp Enable SNMP alerting code.
--enable-smbalerts Enable the SMB alerting code, which is somewhat unsafe because it executes a popen() call from within the program (which runs at root privs). You’ve been warned, use it with caution!
--enable-flexresp Enable the “Flexible Response” code, which allows you to cancel hostile connections on IP-level when a rule matches. When you enable this feature, you also need the libnet-library. See README.FLEXRESP for details. is function is still alpha, so use with caution.
--with-mysql=DIR Support for MySQL; turn this on if you want to use ACID with MySQL.
--with-mysql-libraries=DIR Specify location for mysql client library.
--with-mysql-includes=DIR Specify location for mysql header files.
--with-odbc=DIR Support for ODBC databases; turn this on if you want to use ACID with a non listed DB.
--with-postgresql=DIR Support for PostgreSQL databases; turn this on if you want to use ACID with PostgreSQL.
--with-oracle=DIR Support for Oracle databases; turn this on if you want to use ACID with Oracle.
--with-openssl=DIR Support for OpenSSL (used by the XML output plug-in).
--with-libpq-includes=DIR Set the include directories for PostgresSQL database support to DIR.
--with-libpq-libraries=DIR Set the library directories for PostgresSQL database support to DIR. Setting both of these values enables the Postgres output plug-in module.
--with-libpcap-includes=DIR If the configuration script can’t find the libpcap include files on its own, the path can be set manually with this switch.
--with-libpcap-libraries=DIR If the configuration script can’t find the libpcap library files on its own, the path can be set manually with this switch.
--enable-pthread Enable pthread support (causes snort to be linked with libpthread).
--enable-prelude Enable Prelude Hydrid IDS support.
--enable-rulestate Enable rule state configuration feature that seperates the rule state (enabled/disabled) from the action (alert, drop, log, etc) and definition.
--enable-dynamicplugin Enable dynamically loadable preprocessors, detection engine and rules libraries.
--enable-timestats Enable real-time performance statistics.
--enable-perfprofiling Enable performance profiling of individual rules and preprocessors.
--enable-linux-smp-stats Enable CPU performance statistics through proc.
--enable-inline Use the libipq interface for inline mode. May require --with-libipq
options.
--enable-ipfw Use the IPFW divert sockets for inline mode.
--enable-react Enable interception and termination of offending HTTP accesses.
--enable-flexresp2 Enable the 'Flexible Response, version 2' code, that allows you to cancel hostile connections on IP-level when a rule matches. When you enable this feature, you also need the 'libnet'-library
--enable-aruba Enable the Aruba output plugin capability that allows you to send information to an Aruba Networks Mobility Controller. See
README.ARUBA for details.
--enable-gre Enable GRE decoder. Allows Snort to decode GRE encapsulated traffic. Only supports GRE over IP. Only one layer of encapsulation will be decoded - packets with multiple GRE headers will be alerted and discarded/blocked.
--with-libxml2-includes=DIR Libxml2 include directory.
--with-libxml2-libraries=DIR Libxml2 library directory.
--with-libntp-libraries=DIR Libntp library directory.
--with-libidmef-includes=DIR Libidmef include directory.
--with-libidmef-libraries=DIR Libidmef library directory.

3. Since we just went through all the trouble of installing MySQL, you definitely want to specify the —with-mysql option. We list the MySQL directory that resulted from installing from source code. If you installed a vendor-supplied package, your MySQL files may be in a different directory. You can find the MySQL directory by typing the following:

find / -name "mysql"

4. If the configure script bails on you with an error message about not being able to find your libpcap files, you may need to specify their location as well. Look for libpcap by using this command:

find / -name "libpcap.a"

Before you start to configure and compile the software, run the script command to capture the terminal output to a file. You’ll want to read it later if there are errors, and it will come in handy the next time you want to install the software.

Compiling Snort
Other than specifying an option or two, compiling Snort is disappointingly mundane:

# script ~/notes/snort.install
Script started, file is /root/notes/snort.install
# ./configure --with-mysql=/usr/local/mysql
# make
# make check
# make install
# exit

When you’ve got a working Snort binary, you need to create a place for the Snort rules to live, and start hacking on your snort.conf file. We’ve already made the /usr/local/snort/etc directory, and we recommend putting the Snort rules in their own directory /usr/local/snort/rules. There are a couple of other configuration files that need to move too, so don’t forget those:

reference.config is a collection of URLs for references found in the Snort rules.
classification.config file helps in classifying and prioritizing alerts.

You should still be in the /usr/local/src/snort-version directory that’s holding all of the Snort source code.

# mkdir /usr/local/snort/rules
# cp rules/* /usr/local/snort/rules/
# cp etc/snort.conf /usr/local/snort/etc/
# cp etc/reference.config /usr/local/snort/etc/
# cp etc/classification.config /usr/local/snort/etc/
# cp etc/unicode.map /usr/local/snort/etc/
# cp etc/threshold.conf /usr/local/snort/etc/

The rules in /usr/local/snort/rules are rules that were included when your particular version of Snort was released. Snort rules change, and new ones are released regularly — sometimes daily — just as new threats to the Internet emerge daily. -- Right now, we’re making sure that we can get Snort running at all, so we won’t bother tinkering with the rules just yet.-- When you’ve got the necessary files moved, you’re ready to configure Snort for your network.

Configuring Snort
The first order of business after completing the Snort install is to customize it to your needs. Snort is a very flexible piece of software — detailing all its configuration options (and the best ways to take advantage of them) is something we do with much more in further steps. The steps given here get you going with a good set of generic options — which you set in the snort.conf configuration file in /usr/local/snort/etc. Go ahead and open it up with your favorite Unix text editor (vi, emacs, or pico -w ). You can also download the configuration file to another system and open it; just make sure you use a text editor that won’t mangle it. The snort.conf file is heavily commented, with useful hints at every turn.

$HOME_NET sweet $HOME_NET
If you’re only interested in watching DNS traffic that’s sent to your DNS servers, or SMTP traffic that’s sent to an SMTP server, then you can specify which host on your network sends and receives which kind of traffic. Although such a setup can conserve the resources of your Snort box, it’s also a good way to miss important network traffic — or even a potential attack. If you manage a large enough network, chances are good that you have different people managing different network services, and they might not consult you when they bring up a new DNS, SQL, SMTP, or (even) Web server. And you can bet they won’t consult you if they’re bringing up a new server “just for testing.” If all your Snort server variables are set to $HOME_NET, you’ve got those new critters covered.

Defining network variables
The first step in configuring Snort is telling it which network(s) to monitor (is the internal network address of your LAN):

1. Set the var HOME_NET variable to the slice of network you want to monitor.
You can monitor a single host, a whole network, or anything in between. The configuration file uses var HOME_NET any as a default; whatever network it sits on becomes its “home network” to monitor (not a bad default value). If your Snort box has multiple network interfaces and sits on multiple network segments, it's more daunting to scale Snort for multiple networks.

2. Tell Snort which network you consider the “external” network (You can set this to whatever subnet your external network adapter is answering requests (or in this case, listening) on). The file uses var EXTERNAL_NET any, and this is a good default value.

3. Set all server variables to $HOME_NET. Even if you’re the only person managing your network, you should realize that given enough time, your servers aren’t going to be where they were when you installed Snort, and your snort.conf file will need editing.
So unless your network configuration is truly set in stone, leaving all server variables set to $HOME_NET means Snort always knows where to look.

Specific ports on which Snort should watch for attacks
var HTTP_PORTS 80 or var ORACLE_PORTS 1521.These variables (or vars) specify specific ports on which Snort should watch for attacks. The only downside to the current implementation is that you either have to list ports in succession (for example, 80:82, which means 80 through 82 inclusive) or on separate lines. Work is underway to add support for port lists.

Defining other operating variables
The next variable to define is where your Snort rules live. We moved our rules to /usr/local/snort/rules, like this:

var RULE_PATH /usr/local/snort/rules

If you have a low-powered (or near-maxed-out) machine as your Snort box, you may want to uncomment the config detection: search-method lowmem line to make the most of your available resources.
By and large, the default settings for the Snort decoder and the detection engine can stay as-is. Tweaking the decoder is best done after you’ve already logged some network traffic — if you’re trying to lower the network noise level, having a sample to work with is a great help.
Some network traffic on the logs is also good before you try configuring the preprocessor.

For now, the default values are fine.

Other sections
Other areas of initial interest should include

the preprocessors : Preprocessers are the filters that Snort puts the incoming data stream through before it actually processes the data. If IP defragmentation is turned on helps to detect fragmentation and denial-of-service (DoS) attacks. You can also enable other preprocessors in this section to fit your particular scenario.
output plugins : The output plug-ins section defines whether Snort will use various logging and alert features, and tells it what format to use to dump the data.The ruleset section defines what the system will consider “suspicious” activity. Based on this alone, you should visit www.snort.org frequently to download the latest rulesets to ensure that your IDS is doing the job you meant for it to do—without an up-todate ruleset, your machine will be nothing more than an expensive paperweight. It is also a good practice to comment out rules that do not apply to your organization and/or needs. Unnecessary and extra rules can lead to false positive alerts from the system.
ruleset sections.

Test
Simply verify that Snort will actually run without error. To accomplish this, we will run Snort with a generic configuration/ruleset and no options. To do this, open a terminal window, type:

# snort –v

and verify that the program loads without error

Configuring the system for Snort logs
Now that Snort knows what to watch for, you need to tell it where to send its alerts when it sees something alert-worthy. Snort lets you specify multiple output plugins. For example, you can send its output to any combination of

the syslog facility
an external database
a binary tcpdump file

Here we sets up basic logging — including logging to syslog and to a MySQL database.

Logging Snort using syslog
Logging to two different destinations may seem repetitively redundant (boy, you can say that again), but it can also be very handy, especially when troubleshooting problems. If you’re like us, and you find reading a flat text file easier than pulling data from a database, you’ll be glad to have Snort logging its own status through the Unix syslog facility. Here’s how to point Snort’s snout in the right direction:

1. Uncomment and edit one of the output alert_syslog lines to read like this:

output alert_syslog: LOG_LOCAL3

You can pick any local syslog facility from 0 to 7. Just make sure it’s not already in use.

2. Edit your /etc/syslog.conf file to make sure the log facility you just specified isn’t already in use, and tell syslog which file to write the Snort logs to. For example, consider this syslog.conf file from a Red Hat system:

# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.* /dev/console
# Log anything (except mail) of level info or higher.
# Don’t log private authentication messages!
*.info;mail.none;authpriv.none;cron.none;local3.none
/var/log/messages
# The authpriv file has restricted access.
authpriv.* /var/log/secure
# Log all the mail messages in one place.
mail.* /var/log/maillog
# Log cron stuff
cron.* /var/log/cron
# Everybody gets emergency messages
*.emerg *
# Save news errors of level crit and higher in a special file.
uucp,news.crit /var/log/spooler
# Save boot messages also to boot.log
local7.* /var/log/boot.log
local3.* /var/log/snort/snort.log

The last line indicates that any logs received from the local3 syslog facility should be written to /var/log/snort/snort.log. A syslog.conf file that works like this tells syslog where to put your Snort logs.

3. Confirm that the log file is actually there. Try changing to /var/log/snort to see whether the log file exists. If it doesn’t, create it in Step 4.

4. If the snort.log file doesn’t exist, create it by using the touch command,
and then use chown to make sure the snortuser you created can write to the file:

# cd /var/log
# touch snort/snort.log
# chown -R snortuser.snortgroup snort/

These commands establish that the file is present and is owned by snortuser.

5. Restart the syslog daemon to ensure that your changes take effect.

Tell syslog where to go and Snort to shut up
Some Linux systems will write all log entries of a certain priority to the same file. In the Step 2 example given here, the Red Hat server logs anything with the priority of info to /var/log/messages (a familiar file to all you Red Hat admins). Snort can be very chatty at times, sometimes more than you want. To keep Snort log entries from popping up in your /var/log/messages file, specify that no local3 log entries go to that file. In the syslog.conf file shown in Step 2, the local3.none entry in the first uncommented line takes care of exactly that chore.

Configuring Snort to log to a MySQL database
For faster access to your Snort logs by other programs, like ACID, the Analysis Center for Intrusion Detection, you should configure Snort to log to a database. And since you just installed and configured MySQL, that’s where you’ll be sending Snort’s output.

1. In the snort.conf file, find the following line:

# output database: log, mysql, user=root password=test dbname=db host=localhost

2. Change the line so it contains the correct values for your Snort/MySQL installation. Some of these values haven’t been set yet, although some have been.
For example, we already added a snort user, so you can change the user=root section to read user=snortuser or whatever you named your snort user when you added him/her in the previous section.

3. Create a name for the database you’ve designated to hold your Snort logs.
You’ll be creating the database to go with this name soon, along with a password. (We use the placeholder snortdb as the database name in Step 5.)

4. Specify a host server. At this point, we assume that the MySQL server you’re logging in to is the same box you’re running Snort on. Your host here is 127.0.0.1 or
localhost.

5. Edit your output-database line so it resembles this one:

output database: log, mysql, user=snortuser password=h4wg dbname=snortdb host=localhost

The new unified-output plug-in allows even faster log processing, and it is truly the wave of the future. For now, leave the unified logging lines commented out.

The next section covers which rule sets to enable. From a practical standpoint, you want to have already captured some data before you decide which rules just aren’t for you.

Preparing the MySQL database for Snort
After you’ve configured Snort to log to a MySQL database, make sure that database is prepared to accept Snort’s logs. Here’s how it looks:

1. Using the mysql client, you can:

Create every database you want Snort to use for logging
Grant appropriate permissions on these databases to the Snort user account

For example, here’s a transcript of setting up the Snort databases on our server:

hawg:/# mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 7 to server version: 3.23.49-log
Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the buffer.
mysql> create database snortdb;
Query OK, 1 row affected (0.02 sec)
mysql> grant INSERT,SELECT on snortdb.* to snortuser@localhost;
Query OK, 0 rows affected (0.00 sec)
mysql> SET PASSWORD FOR snortuser@localhost=PASSWORD(‘h4wg’);
Query OK, 0 rows affected (0.00 sec)
mysql> grant CREATE,INSERT,SELECT,DELETE,UPDATE on snortdb.* to snortuser@localhost;
Query OK, 0 rows affected (0.00 sec)
mysql> flush privileges
mysql> exit
Bye
hawg:/#

When this process is complete, the databases exist, and snortuser has the appropriate permissions on them.

2. Build the database structure for each database Snort will use.
This is easy to do, thanks to the scripts included in the contrib directory where your Snort source code resides. Here’s how you get to them:

# cd /usr/local/src/snort-2.1.0/
# mysql -u root -p <./contrib/create_mysql snortdb Enter password: #

3. Make sure your Snort databases are set up and ready for action.
This transcript shows us doing just that:

# mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 10 to server version: 3.23.49-log
Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the buffer.
mysql> SHOW DATABASES;
+----------+
| Database |
+----------+
| mysql |
| snortdb |
| test |
+----------+
3 rows in set (0.00 sec)
mysql> use snortdb
Database changed
mysql> SHOW TABLES;
+-------------------+
| Tables_in_snortdb |
+-------------------+
| data |
| detail |
| encoding |
| event |
| icmphdr |
| iphdr |
| opt |
| reference |
| reference_system |
| schema |
| sensor |
| sig_class |
| sig_reference |
| signature |
| tcphdr |
| udphdr |
+-------------------+
16 rows in set (0.00 sec)
mysql> exit;
Bye
#

So now you’ve got

Snort’s prerequisite software installed and compiled,
the MySQL server installed and configured,
the Snort databases set up, and
Snort itself configured and ready to run.

Take a moment and take a deep breath —now you’re ready to make sure all this stuff actually works!

Is this thing on? Test Snort
Now we want see if all this hard work is going to pay off. We're ready to test your Snort installation. Conveniently, Snort includes a switch you can use to start it up in test mode — where it checks your configuration file, your rules, your database, everything. Here’s a typical test scenario:

1. To start testing, use -T and watch the output.
Chances are you’re going to see errors. Don’t panic, just read the error message(s), fix the problem(s), and try again.

2. Make sure Snort knows where to find its configuration file.
Remember, when you start Snort,

you have to specify where that file is — and we’re running the Snort user account as snortuser, not as root — so specify that too with -u snortuser, as follows:

hawg:/# /usr/local/bin/snort -T -u snortuser -c /usr/local/snort/etc/snort.conf

3. Success? Huzzah! Not yet? Rats. Read the error message carefully and consider these common pitfalls:

Check for typos in your config file.
Make sure a necessary file didn’t get moved.
If your problem starts looking big, take a tour of the Snort users’mailing-list archives. Open-source is as much a community as it is a set of programs. Somebody somewhere has probably run into the same problem. You’ll feel better knowing that someone else has had the same trouble, and you’ll feel a whole lot better once you get it resolved and your server is running.

Playing with rules

Snort's rules-based engine (notice that we did not say signature-based engine) collects and correlates packets based on rules. The term signature refers to nothing more than a basic definition of an attack, akin to the footprint left in the mud by the shoe of someone breaking into a house. A rule defines the attack methodology in terms of identifying the intruder, analogous to identifying how the robber broke into the house in hopes of catching the robber.

Flexibility and simplicity features were two of the initial design goals during the development of Snort and carried through during the design of the rule schema and engine support modules of the application. A tremendous number of Snort users do not use Snort to its fullest potential. The Snort feature set acts as a collection of tools wrapped up into a single application. It has

a packet capture tool
a parsing tool to analyze packets and
multiple input and output modules

When Snort captures a packet that matches the signature of a rule that you have included within your effective set of rules, it triggers that as a hit. A Snort rule can be divided into two main sections,

the rule header and
the rule body

Understanding Configuration Files
It is possible to define and use features that make it easier to use in a large or distributed environment via configuration files. Other features allow objects to be reused in multiple instances of sensors locally or remotely. Snort configuration files allow the engine to include:

variables
additional configuration files, and
additional linked include files

The rule format and testing in combination with a few performance tips and tricks will ensure that you implement the best possible set of rules for your environment, the goal for any IDS administrator or engineer.

Defining and Using Variables
You can define custom variables for use within the rulesets. Defining variables is straightforward, as they use a one-to-one substitution method. The syntax for this command is:

var desired_variable_name variable_value

These variables should be included in the rules file and can be used in place of IP addresses and networks. This first example instruction is used to define a single IP address; it defines the variable DNS_SERVER to be the address 10.1.1.2.

var DNS_SERVER 10.1.1.2

The next example rule is used to define a network address. It defines the variable INTERNAL_NET to be the class B network 10.2.0.0.

var INTERNAL_NET 10.20.0.0/16

The following example differs from the first two, because it is used to define multiple network addresses. It sets the variable INTERNAL_NETS to include a class B, class C, and single IP address.

var INTERNAL_NETS [10.1.0.0/16, 10.2.1.0/24, 10.1.1.8]

Defining and using variables in the rules is an excellent method for creating portable rules and rulesets for your organization. The Snort engine currently lets you take variables to the next level of sophistication by defining dynamic variables. Dynamic variables might be based on another variable that can be set in other parts of the configuration file, or additional include files. When declaring dynamic variables such as desired_variable_name, you would reference a previously declared variable, variable. The following are examples of dynamic variables being declared:

var EXTERNAL_WEB $DMZ_WEB
var 2PHP $INTRANET_WEBS

In the case that variable has not been defined or is illegitimate, desired_variable_
name would inherit the static_default_address value. In the case that you do not
want to include a backup static route, you might include an error message to display when the included variable is undefined.

As you can see in the following rule examples, the second section of the variable definition is separated by a colon, “:”. The area preceding the colon is used for defining the initial variable to be used, whereas the area following the colon is used to notify the engine of what to do if the variable is undefined:

var  desired_variable_name $variable:static_default_address
var  desired_variable_name $variable:?Error: the variable was undefined

This next rule defines a single dynamic IP address. Specifically, it defines the variable DNS_SERVER to have a single dynamic IP address of variable ORG_DNS_SERVER. If ORG_DNS_SERVER is undefined, then DNS_SERVER will have the value of 10.1.1.2.

var DNS_SERVER $(ORG_DNS_SERVER:10.1.1.2)

This next example uses undefined variables. It depicts a user who has selected to configure the system to print out an error message instead of statically assigning a variable.

var ENTIRE_INTERNAL_COMPANY $(INTERNAL_NETS:?Gabe, you forgot to define
INTERNAL_NETS)

As a general note, using print statements is an excellent method for debugging your rules and rulesets. Print statements can be used when debugging your Snort configuration and are specified with question marks. The text that follows the questions as seen in the previous example would be printed if the $INTERNAL_NETS variable had not been previously defined within one of the Snort configuration files.

Defining multiple addresses within a dynamic variable is just as easy as defining a single address or network. First, you must predefine a variable to encompass multiple systems, and then simply reference that variable from the dynamic variable format. In following our two-step example, the first task defines a multiple address variable, while the second task defines the dynamic variable BOSTON_ZONE to equal the value of the multi-address variable DMZ.

var DMZ [10.1.1.1, 10.1.1.2, 10.1.1.3]
var BOSTON_ZONE $DMZ

Snort incorporates numerous methods for controlling engine-related configurations to ensure that the engine and rules are tailored for each environment. Most of these configuration choices can be made in one of two ways.

The first would be to directly specify the desired configuration option via the command line when executing Snort.
The second method (and a more efficient and manageable method for enterprise environments) is defining Snort configurations in a configuration file and just telling Snort to use that configuration file when starting. Snort grabs that configuration file and reads all of the configuration options and values individually, just as if they were specified via the command line. It is highly recommended that you create and use configuration files when deploying Snort sensors in your environment, unless you are merely testing rules and engine capabilities.

Instructions for Snort configuration have a very specific format, consisting of identifying the desired configuration and its corresponding value. The values might vary; however, the format leaves no room for error. The format for defining Snort instructions is config :. The config variable informs Snort that you are about to provide an instruction to configure Snort in a specific manner. The instruction is the desired configuration you want to make with the value of value.

Using Variables for Instructions
Snort includes a robust set of instructions that you can specify to tweak each individual sensor installation for its respective environment and threat base. The following section describes each of the available instructions that can be used when defining Snort configurations via configuration files or the command line when there is a matching command line option. Not all options can be set from the command line.

The alert_with_interface_name feature allows you to append the interface name that received the packet onto the alert notice. This is especially helpful when your Snort engine is located on a multihomed system, or has multiple network interface cards (NICs) connecting the system to multiple networks simultaneously. The appropriate interface name value for this instruction is the corresponding system name of the network card. The command line operator is –I. A common example would be eth0.

alertfile The alert file instruction allows you to designate the file to be used to store all of the Snort triggered alerts. It is a helpful instruction that can allow you to make backups of the file on a routine basis or use it as input for correlation applications. There is no command-line operator for this instruction. An example value is local_alerts.log.
bpf_file The Berkeley Packet Filter (BPF) file instruction allows you to designate a file for Snort to use containing the BPF-formatted filters. The command-line operator is –F, and any filename would be an appropriate value for this instruction.
checksum_mode The checksum mode allows Snort to designate the types of packets that will be checked for proper packet checksums. No corresponding command-line operator exists, and the values are limited to all, none, noicmp, noip, notcp, and noudp. As you might have gleaned, you can directly specify to use all or none of the packets, or identify protocols to disregard.
chroot Similar to the UNIX command chroot, Snort’s modified chroot instruction can be used to specify the new desired Snort home directory. By default, Snort’s root directory is that in which the Snort executable resides. The command-line operator for this instruction is –t.
classification Defining Snort rule’s classification schemas are covered later.
daemon The daemon instruction allows you to fork the Snort process just as you would fork any other system-level process. To terminate processes that have been forked, you would merely use the kill command. The command line operator is –D for the daemon instruction.
decode_arp A valuable feature within Snort is the fact that it permits you to decode and analyze multiple types of protocols. The decode ARP instruction enables ARP decoding on the engine. The command line operator is –a. No corresponding value is required.
decode_data_link Similar to the ARP decoding instruction, the Data Link Decoding instruction decodes data link layer packet data to be included in the analysis engines, alerts, and logs. The command-line operator for the decoding data link layer instruction is –e, and no corresponding value is required.
disable_decode_alerts This instruction allows you to disregard the alerts generated during Snort’s decoding phase. The disabling decode alerts instruction does not require any corresponding value and has no corresponding command-line operator.
dump_chars_only In the case that you only want to retrieve characters, you can use the dump characters only instruction using the commandline operator –C. This instruction doesn’t need an appended value and should be used with caution because it disregards anything that is not a character.
dump_payload The dumping payload instruction can also be executed via the command-line operator –d. The feature allows you to dump all of the application layer data from the captured packets. This instruction does not require any corresponding value.
dump_payload_verbose The dumping verbose payload data instruction has the command-line operator –v and is the same as the dump_payload instruction, except that the verbose instruction dumps the entire packet starting at the Data Link layer.
interface Interface declaration is an essential feature for multihomed enterprise IDSs. Multihomed systems, or systems including multiple networkcards, can be connected to multiple networks simultaneously and thus potentially require that you use different sets of rules for different interfaces. The command-line operator –i requires as a value the name of the NIC.
logdir Setting the Snort log directory is beneficial for customizing installations for multiple e The command-line operator is –l and it takes as an argument the desired log directory. A suitable example in Windows would be C:/Snort/logs.
min_ttl The minimum Time-To-Live (TTL) instruction permits you to define sensor-wide TTL values. If a packet did not meet the defined minimum requirement, that packet would be dropped and no further rule analysis would occur on that packet. No equivalent command-line operator exists. The value is equal to the number of hops you want to declare. For example, in Snort if you defined the minimum TTL as 3, then any packet with a TTL value less than 3 would be ignored. As an additional note, configuring the minimum TTL to equal 1 would pass or accept almost all-legitimate network-based traffic. This rule can assist in dropping locally generated traffic.
no_promisc Snort allows you to directly disable promiscuous mode on your NIC; however, this function should be used with care because you will not receive all of the packets destined for other systems when you execute this command. Promiscuous mode enables your card to capture all packets on the wire. The command-line operator is –p and it does not require a corresponding value.
nolog This instruction allows you to disable all Snort logging, but does not affect the other rule action types such as alert, activate, pass, or dynamic. This configuration instruction is rarely used, because in just about all cases you will want to log certain potentially malicious packets. The instruction does not take any parameters and has a command-line equivalent of –N.
obfuscate The obfuscate instruction allows you to obfuscate IP addresses for alert and logging action events. You do not have to provide additional values since it will affect the entire sensor. The command-line operator is –O.
order You can change the order for passing or ignoring specified packets using the order instruction with a corresponding command-line operator of –o. This allows you to modify the hierarchy for rules analyzed the by sensor’s defined rulesets.
pkt_count Snort provides you with the capability of exiting or shutting down after a specified number of packets has been captured. For example, if you are conducting benchmarks or stress tests, this instruction is extremely helpful in identifying the transmission rate and level of bandwidth consumption. To use this instruction, you only need to provide it the desired total number of packets that you want to analyze via the command-line operator –n.
quiet One method to minimize user and system interaction is to enable the quiet instruction. The quiet instruction disables two main categories of system contact: banners and status reports. Enabling this instruction potentially alleviates a great deal of system clutter, and the command line operator is –q.
reference_net The reference net is analogous to the system’s home network and can be set with the reference net instruction. You can set your default home network with this instruction and its corresponding command line operator –h. To define the network, you only need to provide the desired network address as the value.
set_gid The Snort group can be modified with the set group ID instruction. This instruction is a bit outdated and rarely used since it was created to mimic the UNIX user and group schemas. It does have a command-line operator, –g.
set_uid The command-line operator to set or change the Snort user ID is –u. Along with the set group ID function, the set user ID instruction is also outdated and seldom used, since scenarios in which you would want to modify the Snort user during sensor configuration are “few are far between.”
show_year Including the year field in the timestamp is defined within the show year instruction. It is rarely used in Snort because in most cases, logging packets by year is not necessary and impractical. The corresponding command-line operator –y requires no additional values during configuration.
stateful The stateful instruction allows you to analyze a stream of packets or traffic sessions. Stateful inspection is implemented in Snort via preprocessor plug-ins, specifically the Stream4 preprocessor option. There is no corresponding command-line operator for this command.
umask The umask option permits you to inform Snort to umask during runtime. The command-line option for this command is –m, and if you want to specify this in the config file, the syntax is config umask:VALUE.
utc Snort allows you to decide which type of time reference can be associated with the captured packets and action events. By default, the local system time is referenced; however, you can choose to use the Coordinated Universal Time (UTC) as the reference point. The command line operator is –U and it does not require any additional parameters for successful implementation, as the decision inherits to all of the corresponding events.
verbose In most cases, more information is better than less when referringto logging potential malicious activity. The verbose instruction informs the system to log all of the packets in detail from the link layer to STDOUT. No additional parameters are necessary with the command-line operator –v.

Including Rule Files
Snort allows you to specify include files containing collections of rules that you can use when implementing rules. The format is similar to that of C & C++ include files #include. You must be careful when using include files, because variables and rule types defined within the include files will substitute predefined values for those variables. This means that if you used the same name for a variable locally and in an include file, then in most cases, the value for that variable will be wrong when one of the two signatures gets triggered. The format for defining include files is as follows:

include: complete_path_and_filename

The Rule Header
Snort rule headers should be considered the main portion of the signature, since the header identifies what should be done when the rule is flagged, what protocol to use, and source and destination information including ports, IP address, and networks. The mere data in the rule, or the body, has the potential to be somewhat small in comparison. The rule header can be divided into four main categories:

Rule action
Protocol
Source information
Destination information

While source and destination are key virtual fields in the rule header, it is important to note that these fields are declared with a direction instruction. The direction instruction informs the interpreter engine which of the variable fields is the source and which is the destination.

Rule Action Options
Snort currently has five rule options from which to choose when writing a rule to be implemented in your signature. The rule actions indicate to the engine what operation should take place when the rule is matched during the packet analysis phase. The rule actions are highly significant because they each have a different goal and result. When determining what rule action should be specified for your rule, you must ask yourself,

“what is the goal of the rule and
what is the level of importance if it were to occur?”
If the rule were to be triggered, would you have a reasonable amount of accuracy that a malicious user had obtained unauthorized access to a system or information?
If so, then it might be best served as an Alert action, or possibly even a custom action?. If you noticed a portscan, then it might best to merely log the packet.

Determining the rule action is critical and should be carefully thought out before designation. The five rule actions created by default are:

Pass The pass action simply ignores the packet, and then analysis continues to execute on further captured packets. In most cases, you will never need to use the pass action on a corporate or enterprise network. However, it does come in handy when you want to ignore traffic from a certain system, such as the internal DNS server or network.
Log The log rule action allows you to log the packet in a manner that you can specify during the configuration of your Snort sensor.
Alert The alert rule action logs the packet in the same manner as the Log action, and then alerts the user in a manner specified during configuration time. Alerts can be powerful actions and should be used efficiently. An alert log that is too large might prove be a nuisance or an ineffective mechanism for protecting your network.
Dynamic The dynamic action is unique in that it remains dormant until an Activate rule triggers it “on.” After it is triggered, it then acts like a Log action rule.
Activate The activate action is the most powerful rule action created by default within Snort, because when triggered, it generates an alert and then starts the specified dynamic rule. These can be an excellent for catching complex attacks, intruders using a variety of tools, or even for categorizing data in a different manner.

In addition to these five rule options, you can create custom rule types. These rule types determine how other applications output the data to other types of output plug-ins. The format is straightforward. First, designate the rule type, and then the actions that you want to occur when the rule action is specified. For example, the following rule provides for the creation of a text file log when a defined hacker anomaly is detected:

ruletype hacker_log
{
type log
log_tcpdump: hacker.txt
}

This rule is written to send an alert to two different logs when the Gabriel virus is detected:

ruletype gabriel_virus
{
type alert output
alert_syslog: LOG_AUTH LOG_ALERT
log_tcpdump: gabriel_virus.log
}

The following rule is written so that NetBIOS scans are logged to a specific log:

ruletype netbios_scanning_log
{
type log output
log_tcpdump: netbios.scan
}

Finally, this rule will update a remote database:

ruletype update_database
{
type alert output
output database: log, mysql, user=GJF password=badpass (continued)
dbname=lauryn host=10.100.2.53
}

Defining custom rule types is an excellent way to modularize your Snort sensor, and can be an efficient tool to aid with multiple sensor installations. If it helps, an analogy comparing rule types to object oriented programming (OOP) objects can be drawn, since you can create custom rule types that can be easily transferred and reused for multiple sensors; the rule types are reusable objects.

Supported Protocols
The current free version of Snort was designed to support the analysis of four
different protocols: ICMP,TCP, IP, and UDP. When designating the protocol for the rule, you simply include the type after the rule action separated by a single while space. There were additional modules created for the analysis of different types of protocols, such as 802.11, HTTP, and ARP. More information on these modules can be found on the Web. Please refer to Snort.org for more information on currently available protocol plug-ins or Snort information.

You can only specify one protocol per rule!

Assigning Source and Destination IP Addresses to Rules
The third portion of the rule header field is used to assign source and destination IP addresses pertinent to that specific rule. There are two available options for including system addresses in the rule: using individual IP addresses, or Classless Inter Domain Routing addresses (CIDR). CIDR addresses are easy to specify in a rule; however, you must first understand the format of a CIDR address block. If you wanted to write a rule that covered a class B address range for the 10.2.0.0 through 10.2.255.255 address space, you would only need to write 10.2.0.0./16. If you are ambitious, you could include the IP address 10.123.123.54 as 10.123.123.54/32 using CIDR notation. The subnet are not required or supported within Snort rules.

You cannot use domain names such as gabe.snort.org, or regular expressions for reference in the source or destination fields. Similar in most programming and scripting languages, the negation operator or “!” can be used in combination with an IP address or set of addresses to negate the value. For example, if you would like to create a rule that is valid for any system not included in your local network, you would write !10.100.4.0/24, where 10.100.4.0/24 is equivalent to your internal network space. This is an excellent method for specifying the address space for an external malicious user. A common addressing schema is to use a negated source and non-negated destination as follows:

var INTERNAL_NET 10.20.0.0/16
log tcp !INTERNAL_NET any -> $INTERNAL_NET any

The rule header will log any packet not originating from the internal network with an internal network destination address.

In addition to using CIDR notation and single IP addresses, you can also specify address ranges in a list format using brackets to enclose the IP ranges. There is no reasonable limit of commas that you can use when declaring lists within your rules; however, it might make more sense for you to declare address variables to use within the rules. Variable declarations are a sensible mechanism for minimizing rule size and reusing code. The following shows a rule header that uses the list brackets [] to log TCP traffic from 10.100.2.3, 10.100.3.0 through 10.100.3.255, and 10.101.0.0 through 10.101.255.255 going to the single IP address 10.1.1.5.

log tcp [10.100.2.3,10.100.3.0/24,10.101.0.0/16] any -> 10.1.1.5

The last unique object that you can use in the IP source and destination fields is the any command. As you might have assumed, the any command is a special wildcard reference that lets you quickly assign the entire range of possibilities. It is most commonly used in highly technical vulnerability identification rules, such as identifying a potential Unicode or buffer overflow attack. It is useful because in these scenarios, you might not want to limit the source of the attack to only external entities, and might want to include internal addresses. In most circumstances, you would want to identify all specific attacks on your systems; whether they are internal or external is initially inconsequential. The following demonstrates a common rule seen within Snort that turns it from an IDS to a packet logger. If you follow the format for the rule header, you will see that the rule logs all TCP packets from any source to any destination. A rule such as this would not need a body, since the entire rule is defined within the header. Similar rules are created using the BPF schema.

log tcp any any -> any any

Assigning Source and Destination Ports
Source and destination ports are somewhat similar in the method of declaration to that of the source and destination IP addresses within the Snort rule format. You can still use the any wildcard and the ! negation reference in the rules with the exact same usage as IP fields. It is also in that you can define single ports by directly including that port number in the following rule. Specifically, this syntax details a rule that generates an alert for TCP traffic arriving from any source, destined for port 12345 any IP. Just for your own edification, port 12345 is a common port used for the popular backdoor and remote administration program NetBus.

alert tcp any any -> any 12345

One of the obvious differences with the port’s declaration is that you do not have the option to use CIDR notation to define blocks of addresses. Moreover, Snort does not allow you to list out specific ports in brackets separated by commas similar to the case in the IP schema. However, Snort does allow you to include ranges of ports with a predefined minimum and maximum port number. If you choose to leave out the minimum and maximum port number, then the default minimum port number is 0 and the maximum number is 65535. The following rule defines a rule that logs all UDP traffic from any IP and port source, destined to any LOCAL_NET variable on ports 1 through 100.

log udp any any -> $LOCAL_NET 1:100

The next rule we’ll examine has the alert action for TCP traffic from any source IP with a source port of 0 to 1024 destined for any IP with a destination port of 0 to 1024. Another way to verbally describe this rule would be to say that it alerts all TCP traffic spawned from and destined toward a privileged port. The term privileged when referencing to computers and ports refers to ports 0 to 1024.

alert tcp any :1024 -> any :1024

The last method for writing ranges in Snort rules is to specify the beginning port number with an empty maximum port. This rule logs any TCP traffic destined for an unprivileged port, or ports 1025 and higher. It is important to understand the rule format and be able to dictate the rules in plain English, because the colon operator means equal to or greater than in the following rule, and equal to or less than in the previous rule:

log tcp any any -> any 1025:

One important detail to note is that ports are only used in TCP- and UDP based rules. The other Snort-supported protocols do not use the port fields; however, the Snort engine requires something to be specified. The wildcard any is generally the accepted value for non-TCP/UDP rules.

Understanding Direction Operators
The direction operators tell the Snort engine the proper way to read the rules. It is an effortless way to redefine the source and destination of the rule, or in some cases to disregard source and destination. Currently, there are only two direction operators: -> and <>. Note that there is no <- operator since it would only be a reverse of the -> operator, and thereby serve no real purpose. The -> operator tells the Snort engine that the source information for the rule is on the left side of the arrow, and the destin

alert tcp $EXTERNAL_NET any -> $INTERNAL_NET 139

The next example illustrators a rule that logs all TCP data transferred on privileged ports between the $INTERNAL_NET and $RESEARCH_NET variables:

log tcp $INTERNAL_NET :1024 <> $RESEARCH_NET :1024

It does not dictate nor does it care where the traffic initiates, as long as it is either the internal or research network and is destined toward the other. The <> operator is a bit more tricky and can cause quite a bit of turmoil if used improperly. As written, this rule could log quite a bit of data, thereby clogging IDS logs. It is recommended that you limit these types of rules to specific IP addresses or rules that you believe would not receive a tremendous response, because they could have negative log and performance implications.

Activate and Dynamic Rule Characteristics
Snort provides users with a very powerful tool by allowing them to define activate
and dynamic rule scenarios, thereby creating a chaining set of rules. When an activate rule is triggered, it launches the defined dynamic rule to start executing based on a few configuration specifics within that dynamic rule.

As an example, it might be against company policy to use Telnet externally because login credentials are transmitted in clear text and the subsequent policy is to use Secure Shell (SSH). In this case, you might find it necessary to log all Telnet login credentials using Snort, probably not a common use but an adequate example nonetheless. The following is an example of the activate and dynamic rules that trigger upon the use of data being sent to port 23,used by Telnet. Once the dynamic rule is triggered from the activate rule, it logs the next 20 packets as designated by the count object:

activate tcp any any -> any 23 (activates: 23; msg:" Potential Telnet Login
Credentials Logged";)dynamic tcp any any -> any 23 (activated_by: 23;
count: 20;)

A slight hybrid of the previous example would be to log credentials and any
commands or instructions sent to the system that was being accessed via Telnet. The following does not trigger on Telnet usage, it triggers when a user attempts to su to root after gaining local access to the system. The count has been increased to 100 because in this case, you want to log some of the actions conducted on the system.

activate tcp any any -> any 23 (activates: 24; msg:"SU – Root Attempt";
content:"su – root";)
dynamic tcp any any -> any 23 (activated by: 24; count: 100;)

There are a couple key differentiators for each type of action. The activate rule is exactly like the alert rule that we identified earlier , and the dynamic action is similar to that of a log rule. The activate rule does require one additional object, the activates object, specified within the body of the message. The activates object informs the engine to look for and trigger the dynamic rule that executes or is activated_by the same numerical reference. The dynamic rule takes two additional objects: activated_by and count. The activated_by object specifies the number that must be triggered to execute the rule, and the count object informs the engine the maximum number of times the dynamic rule will be executed. In this case, it will run 20 additional times once triggered, thereby logging the first 20 packets of a Telnet session and in most cases capturing the clear-text authentication credentials. Notice that the activate rule “activates” the number 23, and the dynamic rule is activated_by 23. That is the connection that binds those two rules, not the fact that by coincidence the rules have identical headers minus the action.

activate tcp any any -> any 139 (activates: 2; msg:"poor example of linked rules";)
dynamic udp any any -> any any (activated_by: 2; count: 200;)

The preceding rule, while having the proper format and specification, is a poor example and potential wasteful method for using a dynamic rule. Any TCP traffic destined for NetBIOS port 139 will activate a dynamic rule to log the next 200 UDP that the Snort sensor captures. The important aspect here is that the activate rule can spawn any type of dynamic rule that you define.

Snort’s Protocol Flow Control, first piloted in version 1.9, the user or administrator with was designed to providegreater capabilities when it came to designing complicated rules, especially at the application layer. It will allow the user to specify the direction in which the rule is supposed to trigger actions; specifically, whether it was sent from a client-server, or vice versa. Protocol Flow Control is a powerful tool that does not solely rely on the IP layer for rule specification. It will continue to launch a new large and technical subset of Snort IDS signatures. Refer to snort.org for up-to-date Snort information on this key feature.

Useful links

Ubuntuforums.org
CERT/CC

Harrykar's Techies Blog

Total Pageviews

Search: This Blog, Linked From Here, The Web, My fav sites, My Blogroll

Translate