Total Pageviews

Search: This Blog, Linked From Here, The Web, My fav sites, My Blogroll

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 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.
  1. 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.
  2. 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:
  1. Network-based, IDSs that monitor network backbones and look for attack signatures are called network-based IDSs (NIDS)
  2. 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)
  3. 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.
  1. HIDS protects only the host system on which it resides, and
  2. 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.


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:

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.
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
  1. Layer 1 (Physical): Layer 1 is your physical network connection. For instance, your Ethernet network interface card (NIC).
  2. 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.
  3. 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.
  4. 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.
  5. 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.

  • 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.
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,, 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
  • 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.


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:
  1. sniffer: Sniffer mode simply reads the packets off the network and displays them in a continuous stream on the console.
  2. packet logger: Packet logger mode logs the packets to the disk.
  3. 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.
  4. 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.

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
  • 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:

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:
  1. 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".
  2. 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.
  3. 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.
  4. 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.
  5. 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.


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:, the user opens his Web browser and types, 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, 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.
  1. When Snort starts up, the network card is placed into promiscuous mode by the libpcap library.
  2. 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.
  3. When it receives the packets from the network card driver, it then runs the ProcessPacket() function (in the decode.c source code).
  4. The ProcessPacket function calls the DecodeEthPkt function, which decodes the Ethernet frame.
  5. From within the DecodeEthPkt function, the DecodeIP function decodes the IP protocol.
  6. 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


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:
  1. Preprocessors
  2. Detect engines and plug-ins
  3. Output plug-ins

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:
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 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 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.
  1. An initial conversation is carried out; this is known as the three-way handshake.
  2. Once the connection is set-up, data is transferred.
  3. 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 ->
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
  1. by sending a initial SYN to a server.
  2. 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


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!


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
[**] [117:1:1] (spp_portscan2) Portscan detected from 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 -> XMAS

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

10/06-20:35:47.000000 TCP src: dst:
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,, 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.

(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:

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

(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;)
(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 ->
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 ( on source port (1056) connecting to the Linux server ( 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 -> 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 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 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 []), and then creates a file for each unique session. Contained in each file is the decoded traffic in ASCII representation format. Therefore, in the 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]# 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 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
  1. What kind of attack it is
  2. Where it’s coming from
  3. Where it’s going
  4. Where to find more information about the attack
  • Log (Logging mode) the actual packets of the attack, showing
  1. MAC addresses
  2. IP addresses
  3. Packet payload
  4. Timestamp
  5. 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.


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

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]
  1. sig_generator indicates which part of Snort generated the alert
  2. sig_id is the Snort signature ID, which indicates which rule was tripped
  3. 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
drwx------ 2 root root 4096 Jun 5 23:31
drwx------ 2 root root 4096 Jun 5 23:31
drwx------ 2 root root 4096 Jun 5 23:31
drwx------ 2 root root 4096 Jun 5 23:31
drwx------ 2 root root 4096 Jun 5 23:31
-rw------- 1 root root 622502 Jun 5 23:31 alert
-rw------- 1 root root 17732 Jun 5 23:31 scan.log

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 -> 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 -> 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 -> TCP TTL:36 TOS:0x0 ID:3836 IpLen:20
***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 -> 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 -> TCP TTL:41 TOS:0x0 ID:64826 IpLen:20
******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 -> TCP TTL:64 TOS:0x0 ID:0 IpLen:20 DgmLen:44
***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 -> TCP TTL:47 TOS:0x0 ID:0 IpLen:20 DgmLen:40
*****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
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:
  1. Install MySQL.
  2. Compile Snort with MySQL support.
  3. Create a Snort user in the MySQL database and set up security.
  4. Create the MySQL tables using the create_mysql sql script; this creates the Snort tables used to store the data.
  5. 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).
  6. 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 “”, 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} ->

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

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

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

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

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

  • 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 -> 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 -> 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 -> 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 =>]

    [**] [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 -> 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 -> 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:
    (You can use any one of the following facilities:)
    (and any of the following priorities:)
    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, your syslog.conf file should include the following line:

local3.* @

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 @

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:


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


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


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 snort: [1:483:2] ICMP PING CyberKit
2.2 Windows [Classification: Misc activity] [Priority: 3]: {ICMP} ->
Jan 15 16:15:41 snort: [1:483:2] ICMP PING CyberKit
2.2 Windows [Classification: Misc activity] [Priority: 3]: {ICMP} ->
Jan 15 16:16:23 snort: [1:2003:2] MS-SQL Worm
propagation attempt [Classification: Misc Attack] [Priority: 2]:
{UDP} ->
Jan 15 16:17:37 snort: [1:483:2] ICMP PING CyberKit
2.2 Windows [Classification: Misc activity] [Priority: 3]: {ICMP} ->

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

    01/15-21:43:07.555566 ,ICMP PING CyberKit 2.2

    01/15-21:45:35.047068 ,ICMP PING CyberKit 2.2

    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,,
    01/16-20:33:10.250312 ,WEB-MISC robots.txt access,,
    01/16-20:33:10.490020 ,WEB-MISC /~root access,,
    01/16-20:33:10.792501 ,WEB-MISC apache DOS attempt,,
    01/16-20:33:11.614642 ,WEB-MISC .DS_Store access,,
    01/16-20:33:11.709005 ,WEB-MISC .FBCIndex access,,
    01/16-20:33:12.792244 ,WEB-CGI printenv access,,

    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:
  1. Snort captures network traffic and
  2. applies a preprocessor on it that normalizes the traffic into a recognizable format. If the preprocessor deems the traffic noteworthy,
  3. it can call an output module to send an alert, or log the packet, or do both (depending on how the preprocessor is written).
  4. Snort then compares the normalized network traffic to a list of rules.
  5. 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).
  6. 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 ARP
# cd
# 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 ->
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 ->
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 ->
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 ->
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 ->
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 (, 01/16-01:22:23.654699 0:10:67:0:B2:50 -> 0:A0:CC:D2:10:31 type:0x800 len:0x6A -> 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 -> 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
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:
  1. 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.
  2. 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.
  3. 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,

  1. I return to the main page and select the Unique alerts link
  2. then decide to use the signature named IIS UNICODE CODEPOINT ENCODING.
  3. I check the box next to that signature, then scroll to Action box at the bottom of the page.
  4. 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.
  5. 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.

  1. Passive monitoring is simply the ability to listen to network traffic and log it.
  2. 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 (Build 38) '''' By Martin Roesch & The Snort Team: Copyright (C) 1998-2009 Sourcefire, Inc., et al. Using PCRE version: 7.8 2008-09-05 USAGE: snort [-options]


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

Fatal Error, Quitting..

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 (Build 38) '''' By Martin Roesch & The Snort Team: 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 ->
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 ->
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 ->
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 ->
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 ->
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 ->
TCP TTL:48 TOS:0x0 ID:13579 IpLen:20 DgmLen:1470
***A**** Seq: 0xB24AE17D Ack: 0x96F25316 Win: 0xF7BF TcpLen: 20


^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:
Snort exiting

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, you would use the following:

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

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

If you want to ignore all traffic from the 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 on port 22:

# snort -vd -r  not host 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 -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

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, 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 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 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
  • 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:
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* LISTEN 3991/mysqld
tcp 0 0* LISTEN 3965/perl
tcp 0 0* LISTEN 3822/apache2
tcp 0 0* LISTEN 8256/firefox
tcp 0 0* LISTEN 3200/monopd
tcp 0 0* LISTEN 6991/seahorse-daemo
tcp 0 0* LISTEN 3266/vsftpd
tcp 0 0* LISTEN 2469/sshd
tcp 0 0* LISTEN 3645/cupsd
tcp 0 0* LISTEN 3285/wesnothd
tcp 0 0* LISTEN 3171/ggzd
tcp 0 0* LISTEN 2688/postgres
tcp 0 0* LISTEN 3152/exim4
tcp 0 0 ESTABLISHED 7429/epiphany-brows
tcp 0 0 TIME_WAIT -
tcp 1 0 CLOSE_WAIT 7429/epiphany-brows
tcp 0 0 ESTABLISHED 22648/telepathy-gab
tcp 0 0 ESTABLISHED 7429/epiphany-brows
tcp 0 0 ESTABLISHED 7429/epiphany-brows
tcp 0 0 ESTABLISHED 8256/firefox
tcp 0 0 ESTABLISHED 22648/telepathy-gab
tcp 0 0 ESTABLISHED 8256/firefox
tcp 0 0 ESTABLISHED 7429/epiphany-brows
tcp 0 0 ESTABLISHED 7429/epiphany-brows
tcp 0 0 ESTABLISHED 7429/epiphany-brows
tcp 0 0 ESTABLISHED 8256/firefox
tcp 0 0 ESTABLISHED 8256/firefox
tcp 0 0 ESTABLISHED 8256/firefox
tcp 0 0 ESTABLISHED 7429/epiphany-brows
tcp 0 0 TIME_WAIT -
tcp 0 0 ESTABLISHED 7429/epiphany-brows
tcp 0 0 ESTABLISHED 7429/epiphany-brows
tcp 0 0 ESTABLISHED 7429/epiphany-brows
tcp 0 0 ESTABLISHED 7429/epiphany-brows
tcp 0 0 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* 3230/nmbd
udp 0 0* 3230/nmbd
udp 0 0* 3230/nmbd
udp 0 0* 3230/nmbd
udp 0 0* 3965/perl
udp 0 0 ESTABLISHED 2688/postgres
udp 0 0* 3621/avahi-daemon:
udp 0 0* 3621/avahi-daemon:
udp 0 0* 3364/ntpd
udp 0 0* 3364/ntpd
udp 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 saned
atd screen-cleanup
avahi-daemon sendsigs
binfmt-support single
bluetooth skeleton
bootlogd ssh mountoverflowtmp stop-bootlogd stop-bootlogd-single
brltty mysql stop-readahead mysql-ndb sysklogd 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
exim4 pcmciautils umountroot
firestarter policykit urandom
gdm postgresql-8.3 usplash
ggzd powernowd vsftpd powernowd.early webmin
hal pppd-dns wesnoth-server
halt procps wicd pulseaudio winbind
hotkey-setup rc wpa-ifupdown rc.local x11-common
keyboard-setup rcS

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

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

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
# 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

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
$ wget -q
$ 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 --recv-keys 86FF9C48
gpg: /home/snortfd/.gnupg/secring.gpg: keyring created
gpg: /home/snortfd/.gnupg/pubring.gpg: keyring created
gpg: requesting key 86FF9C48 from ...
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
$ wget -q
$ 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
# wget
# 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 --recv-keys 49a563d9
gpg: requesting key 49A563D9 from ...
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/
# 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
# 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
  1. • Compile from source
  2. • Install binaries from
  3. • 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
  1. • The client
  2. • The server
  3. • Documentation
  4. • 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

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

(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 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/
# cat /etc/
# ldconfig

  • Here echo adds a line to your library configuration file,
  • 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/
# echo “/usr/local/lib” >>/etc/
# 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/ --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:

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 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 --recv-keys 89E917F3
gpg: requesting key 89E917F3 from ...
gpg: key 89E917F3: public key imported
gpg: Total number processed: 1
gpg: imported: 1
# gpgv --keyring=~/.gnupg/pubring.gpg libpcap-
gpgv: Signature made Wed Feb 26 01:36:50 2003 CST using DSA
key ID 89E917F3
gpgv: Good signature from “ (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
# wget -q
# wget -q
# 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/ 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/
# 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 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 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
# wget -q
# 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 1946E4A1
gpg: requesting key 1946E4A1 from ...
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 “ 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
  • --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/ /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.

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

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!
# 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 or

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

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.
| Database |
| mysql |
| snortdb |
| test |
3 rows in set (0.00 sec)
mysql> use snortdb
Database changed
| 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;

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


The next example rule is used to define a network address. It defines the variable INTERNAL_NET to be the class B network


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.


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:


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


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

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 [,,]

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=

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 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 through address space, you would only need to write If you are ambitious, you could include the IP address as using CIDR notation. The subnet are not required or supported within Snort rules.

You cannot use domain names such as, 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 !, where 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:

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, through, and through going to the single IP address

log tcp [,,] any ->

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 for up-to-date Snort information on this key feature.

Useful links