From Computing and Software Wiki

Revision as of 23:04, 25 March 2008

Communications and Computer Network Protocol Design Models

There are different models to describe communications and computer network protocol design:

The Five-Layer TCP/IP Model: Description/Attacks/Defense

Application layer

Description: The application layer is used by most programs for network communication. Data is passed from the program in an application-specific format, then encapsulated into a transport layer protocol.

Since the IP stack has no layers between the application and transport layers, the application layer must include any protocols that act like the OSI's presentation and session layer protocols. This is usually done through libraries.

Data sent over the network is passed into the application layer where it is encapsulated into the application layer protocol. From there, the data is passed down into the lower layer protocol of the transport layer.

The two most common end-to-end protocols are TCP and UDP. Common servers have specific ports assigned to them (HTTP has port 80; Telnet has port 23; etc.) while clients use ephemeral ports. Some protocols, such as File Transfer Protocol and Telnet may set up a session using a well-known port, but then redirect the actual user session to ephemeral ports.

Routers and switches do not utilize this layer but bandwidth throttling applications do, as with the Resource Reservation Protocol (RSVP).

An example of an attack:

SQL injection:

SQL injection is a technique that exploits a security vulnerability occurring in the database layer of an application. The vulnerability is present when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and thereby unexpectedly executed. It is in fact an instance of a more general class of vulnerabilities that can occur whenever one programming or scripting language is embedded inside another.

Take a simple login page where a legitimate user would enter his username and password combination to enter a secure area to view his personal details or upload his comments in a forum.

When the legitimate user submits his details, an SQL query is generated from these details and submitted to the database for verification. If valid, the user is allowed access. In other words, the web application that controls the login page will communicate with the database through a series of planned commands so as to verify the username and password combination. On verification, the legitimate user is granted appropriate access.

Through SQL Injection, the hacker may input specifically crafted SQL commands with the intent of bypassing the login form barrier and seeing what lies behind it. This is only possible if the inputs are not properly sanitised (i.e., made invulnerable) and sent directly with the SQL query to the database. SQL Injection vulnerabilities provide the means for a hacker to communicate directly to the database.

The technologies vulnerable to this attack are dynamic script languages including ASP, ASP.NET, PHP, JSP, and CGI. All an attacker needs to perform an SQL Injection hacking attack is a web browser, knowledge of SQL queries and creative guess work to important table and field names. The sheer simplicity of SQL Injection has fuelled its popularity.

A way to defense:

A network-based intrusion detection (IDS) tool such as Snort can be set up to detect certain types of SQL injection and XSS attacks as they occur. Snort actually has a default rule set that contains signatures for detecting these intrusions. However, they can be easily bypassed by an attacker, mainly by converting the malicious input string into its hex-encoded value.

Transport layer

Description: The transport layer's responsibilities include end-to-end message transfer capabilities independent of the underlying network, along with error control, fragmentation and flow control. End to end message transmission or connecting applications at the transport layer can be categorized as either:

  1. connection-oriented e.g. TCP
  2. connectionless e.g UDP

The transport layer can be thought of literally as a transport mechanism e.g. a vehicle whose responsibility is to make sure that its contents (passengers/goods) reach its destination safely and soundly, unless a higher or lower layer is responsible for safe delivery.

The transport layer provides this service of connecting applications together through the use of ports. Since IP provides only a best effort delivery, the transport layer is the first layer of the TCP/IP stack to offer reliability. Note that IP can run over a reliable data link protocol such as the High-Level Data Link Control (HDLC). Protocols above transport, such as RPC, also can provide reliability.

An example of an attack:

Port Scan Attack:

A Port Scan is one of the most popular reconnaissance techniques attackers use to discover services they can break into. All machines connected to a network run many services that use TCP or UDP ports. A port scan helps the attacker find which ports are available. Essentially, a port scan consists of sending a message to each port, one at a time. The kind of response received indicates whether the port is used and can therefore be probed further for weakness.

A way to defense:

Placing a NIDS on the outside of the external firewall will give an early warning advantage, as it should enable the administrator to detect the port scans that typically indicate the start of hacker activity. However, not all scans will be followed by an actual attack, as the hacker may determine that the network currently has no weaknesses that they can exploit. This could lead to large number of alerts that do not require attention. One common yet dangerous effect of this is that the staff may lose faith in the IDS and start ignoring alerts. External firewall can be used to provide alerts for the traffic that it has denied. By placing NIDS inside the DMZ (De-Militarized Zone, a part of the network that is neither "inside" nor "outside" the corporate entity) the advantage that could be taken is that the tailoring of NIDS attack signature database can be done to consider only those attacks that are applicable to the systems in the DMZ; at the same time the firewall will have blocked all other traffic.

Network layer

Description: Network layer solves the problem of getting packets across a single network. Examples of such protocols are X.25, and the ARPANET's Host/IMP Protocol.

With the advent of the concept of internetworking, additional functionality was added to this layer, namely getting data from the source network to the destination network. This generally involves routing the packet across a network of networks, known as an internetwork or (lower-case) internet.

In the Internet protocol suite, IP performs the basic task of getting packets of data from source to destination. IP can carry data for a number of different upper layer protocols; these protocols are each identified by a unique protocol number: ICMP and IGMP are protocols 1 and 2, respectively.

Some of the protocols carried by IP, such as ICMP (used to transmit diagnostic information about IP transmission) and IGMP (used to manage IP Multicast data) are layered on top of IP but perform internetwork layer functions, illustrating an incompatibility between the Internet and the IP stack and OSI model. All routing protocols, such as OSPF, and RIP are also part of the network layer. What makes them part of the network layer is that their payload is totally concerned with management of the network layer. The particular encapsulation of that payload is irrelevant for layering purposes.

An example of an attack:

Denial of Service attack - SYN Flooding:

The basis of the SYN flooding attack lies in the design of the 3-way handshake that begins a TCP connection. In this handshake, the third packet verifies the initiator's ability to receive packets at the IP address it used as the source in its initial request, or its return reachability. Figure 1 shows the sequence of packets exchanged at the beginning of a normal TCP connection.

The Transmission Control Block (TCB) is a transport protocol data structure (actually a set of structures in many operations systems) that holds all the information about a connection. The memory footprint of a single TCB depends on what TCP options and other features an implementation provides and has enabled for a connection. Usually, each TCB exceeds at least 280 bytes, and in some operating systems currently takes more than 1300 bytes. The TCP SYN-RECEIVED state is used to indicate that the connection is only half open, and that the legitimacy of the request is still in question. The important aspect to note is that the TCB is allocated based on reception of the SYN packet— before the connection is fully established or the initiator's return reachability has been verified.

This situation leads to a clear potential DoS attack where incoming SYNs cause the allocation of so many TCBs that a host's kernel memory is exhausted. In order to avoid this memory exhaustion, operating systems generally associate a "backlog" parameter with a listening socket that sets a cap on the number of TCBs simultaneously in the SYN-RECEIVED state. Although this action protects a host's available memory resource from attack, the backlog itself represents another (smaller) resource vulnerable to attack. With no room left in the backlog, it is impossible to service new connection requests until some TCBs can be reaped or otherwise removed from the SYN-RECEIVED state.

Depleting the backlog is the goal of the TCP SYN flooding attack, which attempts to send enough SYN segments to fill the entire backlog. The attacker uses source IP addresses in the SYNs that are not likely to trigger any response that would free the TCBs from the SYN-RECEIVED state. Because TCP attempts to be reliable, the target host keeps its TCBs stuck in SYN-RECEIVED for a relatively long time before giving up on the half connection and reaping them. In the meantime, service is denied to the application process on the listener for legitimate new TCP connection initiation requests. Figure 2 presents a simplification of the sequence of events involved in a TCP SYN flooding attack.

A way to defense:

Both end-host and network-based solutions to the SYN flooding attack have merits. Both types of defense are frequently employed, and they generally do not interfere when used in combination. Because SYN flooding targets end hosts rather than attempting to exhaust the network capacity, it seems logical that all end hosts should implement defenses, and that network-based techniques are an optional second line of defense that a site can employ.

End-host mechanisms are present in current versions of most common operating systems. Some implement SYN caches, others use SYN cookies after a threshold of backlog usage is crossed, and still others adapt the SYN-RECEIVED timer and number of retransmission attempts for SYN-ACKs.

Because some techniques are known to be ineffective (increasing backlogs and reducing the SYN-RECEIVED timer), these techniques should definitely not be relied upon. Based on experimentation and analysis (and the author's opinion), SYN caches seem like the best end-host mechanism available.

This choice is motivated by the facts that they are capable of withstanding heavy attacks, they are free from the negative effects of SYN cookies, and they do not need any heuristics for threshold setting as in many hybrid approaches.

Among network-based solutions, there does not seem to be any strong argument for SYN-ACK spoofing firewall/proxies. Because these spoofing proxies split the TCP connection, they may disable some high-performance or other TCP options, and there seems to be little advantage to this approach over ACK-spoofing firewall/proxies. Active monitors should be used when a firewall/proxy solution is administratively impossible or too expensive to deploy. Ingress and egress filtering is frequently done today (but not ubiquitous), and is a commonly accepted practice as part of being a good neighbor on the Internet. Because filtering does not cope with distributed networks of drones that use direct attacks, it needs to be supplemented with other mechanisms, and must not be relied upon by an end host.

Data link layer

Description: The link layer, which is the method used to move packets from the network layer on two different hosts, is not really part of the Internet protocol suite, because IP can run over a variety of different link layers. The processes of transmitting packets on a given link layer and receiving packets from a given link layer can be controlled both in the software device driver for the network card, as well as on firmware or specialist chipsets. These will perform data link functions such as adding a packet header to prepare it for transmission, then actually transmit the frame over a physical medium.

For Internet access over a dial-up modem, IP packets are usually transmitted using PPP. For broadband Internet access such as ADSL or cable modems, PPPoE is often used. On a local wired network, Ethernet is usually used, and on local wireless networks, IEEE 802.11 is usually used. For wide-area networks, either PPP over T-carrier or E-carrier lines, Frame relay, ATM, or packet over SONET/SDH (POS) are often used.

An example of an attack:

Media Access Control (MAC) Address spoofing:

MAC spoofing attacks involve the use of a known MAC address of another host to attempt to make the target switch forward frames destined for the remote host to the network attacker. By sending a single frame with the other host's source Ethernet address, the network attacker overwrites the CAM table entry so that the switch forwards packets destined for the host to the network attacker. Until the host sends traffic it will not receive any traffic. When the host sends out traffic, the CAM table entry is rewritten once more so that it moves back to the original port.

A way to defense:

The best way to protect against MAC spoofing is for an intelligent WLAN system to automatically detect MAC spoofing attacks and exclude offending machines from attaching to the WLAN. This is done in several ways:

Detection and Containment - One way to prevent MAC spoofing attacks is to flag any occurrence in which the manufacturer name of a detected WLAN adapter differs from the known OUI (Organizationally Unique Identifier) for that equipment. Once detected, an intelligent WLAN system can prevent the known attacker from connecting to any nearby APs or any APs located throughout the entire WLAN.

Physical layer

Description: The Physical layer is responsible for encoding and transmission of data over network communications media. It operates with data in the form of bits that are sent from the Physical layer of the sending (source) device and received at the Physical layer of the destination device.

Ethernet, Token Ring, SCSI, hubs, repeaters, cables and connectors are standard network devices that function at the Physical layer. The Physical layer is also considered the domain of many hardware-related network design issues, such as LAN and WAN topology and wireless technology.

An example of an attack:

There is not much to be said about the attack on this layer. Some one can physically take away your network card or unplug your internet cable.

A way to defense:

Don't let people touch your computer :)

Network Intrusion Detection System

A NIDS captures all traffic of the network, detects the attacks and gives alarms to the user/administrator.

Capture

IDS use different methods to capture the relevant data to be analyzed. A very well known method is pcap.

pcap consists of an application programming interface (API) for capturing network traffic. Unix-like systems implement pcap in the libpcap library(packet capture library); Windows uses a port of libpcap known as WinPcap.

Monitoring software may use libpcap and/or WinPcap to capture packets travelling over a network and, in newer versions, to transmit packets on a network at the link layer, as well as to get a list of network interfaces for possible use with libpcap or WinPcap.

libpcap and WinPcap also support saving captured packets to a file, and reading files containing saved packets; applications can be written, using libpcap or WinPcap, to be able to capture network traffic and analyze it, or to read a saved capture and analyze it, using the same analysis code. A capture file saved in the format that libpcap and WinPcap use can be read by applications that understand that format.

libpcap and WinPcap provide the packet-capture and filtering engines of network intrusion detection systems. They are usually installed at the data link layer but they can be installed at any desired layer and they capture the net work traffic from that layer all the way up. Filters can be applied so that the NIDS can can sniff the data in a desired way. for example:

- request a list of all packets except the ones that use UDP.

- request a list of all packets all packets going through TCP and usnig port 80.

Detection

The typical function of a NIDS is based on a set of signatures, each describing one known intrusion threat. ANIDS examines network traffic and determines whether any signatures indicating intrusion attempts are matched.

The simplest and most common form of NIDS inspection is to match string patterns against the payload of packets captured on a network link.

For instance, consider the (simplified) signature shown here:

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80 (content:‘‘/usr/bin/perl’’)

It is a A simple intrusion detection rule, taken from snort, a widely-used open-source NIDS. This signature matches all TCP/IP packets originating from computers outside the monitored domain (i.e., the $EXTERNAL NET), destined to the web servers of the monitored domain (i.e., the $HTTP SERVERS at port 80 ), and containing the string “/usr/bin/perl” in the payload. If the NIDS determines that a packet matches this rule, it infers that a malicious client may be trying to make the web server execute the perl interpreter, hoping to gain unauthorized access. To decide whether a packet matches the signature, the NIDS needs to check the (TCP/IP) packet header for the specified values (i.e., $EXTERNAL NET, $HTTP SERVERS, 80). In addition, the NIDS needs to check whether the payload contains the string “/usr/bin/perl”.

There are two main algorithms for pattern matching:

E2xB: A domain­specific string matching algorithm for intrusion detection:

In this context, we present ÌÎÍ}Ï\Ð , a string matching algorithm that is designed specifically for the relatively small input size (in the order of packet size) and small expected matching probability that is common in a NIDS environment.

These assumptions allow string matching to be enhanced by first testing the input (e.g., the payload of each packet) for missing fixed-size sub-strings of the original signature string, called elements. The false positives induced by ÌÎ͇Ï\Ð , e.g., cases with all fixed-size sub-strings of the signature showing up in arbitrary positions within the input, can then be separated from actual matches using standard string matching algorithms"

Boyer-Moore algorithm:

Boyer-Moore algorithm

The Boyer-Moore algorithm is considered as the most efficient string-matching algorithm in usual applications. A simplified version of it or the entire algorithm is often implemented in text editors for the «search» and «substitute» commands.

The algorithm scans the characters of the pattern from right to left beginning with the rightmost one. In case of a mismatch (or a complete match of the whole pattern) it uses two precomputed functions to shift the window to the right. These two shift functions are called the good-suffix shift (also called matching shift and the bad-character shift (also called the occurrence shift).

One of the best references in string matching is: http://www-igm.univ-mlv.fr/~lecroq/string/

Alert

After a NIDS detects an attack. An Alert is given. Alerts can be generated on real-time or run-time basis.

Reconfigure firewall Configure the firewall to filter out the IP address of the intruder. However, this still allows the intruder to attack from other addresses. Checkpoint firewall's support a "Suspicious Activity Monitoring Protocol (SAMP)" for configuring firewalls. Checkpoint has their "OPSEC" standard for re-configuring firewalls to block the offending IP address.

chime Beep or play a .WAV file. For example, you might hear a recording "You are under attack".

SNMP Trap Send an SNMP Trap datagram to a management console like HP OpenView, Tivoli, Cabletron Spectrum, etc.

NT Event Send an event to the WinNT event log.

syslog Send an event to the UNIX syslog event system.

send e-mail Send e-mail to an administrator to notify of the attack.

page Page (using normal pagers) the system administrator.

Log the attack Save the attack information (timestamp, intruder IP address, victim IP address/port, protocol information).

Save evidence Save a tracefile of the raw packets for later analysis.

Launch program Launch a separate program to handle the event.

Terminate the TCP session Forge a TCP FIN packet to force a connection to terminate.

False Alarms & How To Provide Them

Network-based intrusion detection systems (NIDS) perform in-depth packet analysis in order to enumerate attackers who are attempting to expose network and service vulnerabilities. NIDS devices can also aid in identifying misuse patterns and gathering forensic data. By examining network traffic in real time, NIDS devices can alert users to possible attacks and/or take predefined responsive actions to help mitigate the threat. By providing an additional layer of protection above and beyond access control devices such as a firewall, NIDSs can be a valuable addition to the security arsenal. However, network intrusion detection has been criticized for its propensity to generate a perceived large amount of false positives and false negatives. Effective NIDS device management can appreciably reduce these reporting inaccuracies

False Positives

The term false positive is a broad and somewhat vague term that describes a situation in which an NIDS device trigger an alarm in a when there is malicious activity or attack occurring. Other common terms used to describe this condition are "false alarms" and "benign trigger". False alarm is the better term to describe this behavior since "false positive" gives the impression that IDS technology itself is fundamentally flawed and benign trigger gives the impression that there is no possibility for a true false positive to exist. Here I will use the term false alarm to describe the general condition of an alarm being generated without a true security related event. False alarms are the Internet security equivalents of the boy who cried wolf. They are problematic because by triggering unjustified alerts, they diminish the value and urgency of real alerts.

False Negatives

False negative is the term used to describe a network intrusion device's inability to detect true security events under certain circumstances. In other words, malicious activity is not detected and alerted. Fortunately, there are actions that can be taken to reduce the chance of false negative conditions without increasing the number of false positives. The difficulty in creating this "balance" is to create a more manageable NIDS deployment without introducing extra risk. First, however, we need to analyze how network intrusion detection systems detect these attacks so we can understand the consequences associated with our actions.

How to Avoid False Alarms

Common techniques that can be used to reduce false alarms include placing the NIDS device behind a firewall, tuning signatures to only include certain platforms and or services offered on the network, and reduction through thorough network analysis. Each of these techniques has potential benefits and drawbacks.

Placing the NIDS Behind a Firewall

Placing the NIDS behind a firewall is a common technique that is very easy to implement. This technique requires no alteration of the default configuration of the device and very little expertise. When an alarm is received there is a high percentage of certainty that is it a real threat than if the NIDS was not behind the firewall. However, there are still instances where it will trigger benign alarms, such as the web page posted by Joe sys-admin about the Code Red worm from the example in the the first article in this series. There also exists a potential for false negatives such as denial of service events. The DAA formula for this design would be as follows:

Reconnaissance attempts = 3 (host sweeps may be recognized, port scans probably not) DOS recognition = 3 (The IDS will only see DOS attacks on services allowed through the network firewall) Service compromise = 5 DAA = 15

Tuning NIDS Signatures

Another common and relatively easily deployable solution is to tune the NIDS device's signatures to only watch for services or operating system-specific conditions that apply to the network being monitored. This requires more skill and vulnerability knowledge than does placing the device behind a firewall and it is less prone to false alarms. However if we analyze the DAA formula we realize that the fruits of our labor our not really realized.

Reconnaissance attempt = 5 (host sweeps and port scans recognized) DOS recognition = 5 (device will see all DOS attacks on network) Service Compromise = 3 (will allow an attack until the attacker triggers an alarm that actually effects the network being monitored) DAA = 15

Network Analysis

The most laborious solution is to reduce false alarms through network analysis. This requires considerable networking knowledge, expertise, analysis and some imagination. In this design, the NIDS device is placed outside the firewall with a full complement of signatures. Alarms are analyzed and then tuned very specifically to eliminate common false alarms. The engineer must be careful not to introduce false negative conditions through alarm filtering. Done correctly, this method is very effective in mitigating risk. Most of this analysis is done within the first few weeks of implementation, however some ongoing analysis is required. The DAA for this method reflects its effectiveness.

Reconnaissance attempt = 5 (host sweeps and port scans recognized) DOS recognition = 5 (will see all DOS attacks on network) Service Compromise = 5 (will alert on any attack at a service) DAA = 25

Host based & Network based IDS

Host-Based IDS (HIDS)

Host-based systems were the first type of IDS to be developed and implemented. These systems collect and analyze data that originate on a computer that hosts a service, such as a Web server. Once this data is aggregated for a given computer, it can either be analyzed locally or sent to a separate/central analysis machine. One example of a host-based system is programs that operate on a system and receive application or operating system audit logs. These programs are highly effective for detecting insider abuses. Residing on the trusted network systems themselves, they are close to the network’s authenticated users. If one of these users attempts unauthorized activity, host-based systems usually detect and collect the most pertinent information in the quickest possible manner. In addition to detecting unauthorized insider activity, host-based systems are also effective at detecting unauthorized file modification.

On the down side, host-based systems can get unwieldy. With several thousand possible endpoints on a large network, collecting and aggregating separate specific computer information for each individual machine may prove inefficient and ineffective. In addition, if an intruder disables the data collection on any given computer, the IDS on that machine will be rendered useless because there is no backup.

Possible host-based IDS implementations include Windows NT/2000 Security Event Logs, RDMS audit sources, Enterprise Management systems audit data (such as Tivoli), and UNIX Syslog in their raw forms or in their secure forms such as Solaris' BSM; host-based commercial products include RealSecure, ITA, Squire, and Entercept, to name a few.

Network-Based IDS (NIDS)

As opposed to monitoring the activities that take place on a particular network, Network-based intrusion detection analyzes data packets that travel over the actual network. These packets are examined and sometimes compared with empirical data to verify their nature: malicious or benign. Because they are responsible for monitoring a network, rather than a single host, Network-based intrusion detection systems (NIDS) tend to be more distributed than host-based IDS. Software, or appliance hardware in some cases, resides in one or more systems connected to a network, and is used to analyze data such as network packets. Instead of analyzing information that originates and resides on a computer, network-based IDS uses techniques like “packet-sniffing” to pull data from TCP/IP or other protocol packets traveling along the network. This surveillance of the connections between computers makes network-based IDS great at detecting access attempts from outside the trusted network. In general, network-based systems are best at detecting the following activities:

Unauthorized outsider access: When an unauthorized user logs in successfully, or attempts to log in, they are best tracked with host-based IDS. However, detecting the unauthorized user before their log on attempt is best accomplished with network-based IDS.

Bandwidth theft/denial of service: These attacks from outside the network single out network resources for abuse or overload. The packets that initiate/carry these attacks can best be noticed with use of network-based IDS.

Some possible downsides to network-based IDS include encrypted packet payloads and high-speed networks, both of which inhibit the effectiveness of packet interception and deter packet interpretation. Examples of network-based IDS include Shadow, Snort!, Dragon, NFR, RealSecure, and NetProwler.

HIDS and NIDS Used in Combination

The two types of intrusion detection systems differ significantly from each other, but complement one another well. The network architecture of host-based is agent-based, which means that a software agent resides on each of the hosts that will be governed by the system. In addition, more efficient host-based intrusion detection systems are capable of monitoring and collecting system audit trails in real time as well as on a scheduled basis, thus distributing both CPU utilization and network overhead and providing for a flexible means of security administration.

In a proper IDS implementation, it would be advantageous to fully integrate the network intrusion detection system, such that it would filter alerts and notifications in an identical manner to the host-based portion of the system, controlled from the same central location. In doing so, this provides a convenient means of managing and reacting to misuse using both types of intrusion detection.

That said, as an organization introduces an IDS into its network to augment its current information security strategy, the primary focus of the intrusion detection system should be host-based. Although network intrusion detection has its merits and certainly must be incorporated into a proper IDS solution, it has historically been incapable of evolving to comply with the growing technology of data communications. Most NIDS perform miserably, if at all, on switched networks, fast networks of speeds over 100 Mbps, and encrypted networks. Furthermore, somewhere in the range of 80 - 85 percent of security incidents originate from within an organization. Consequently, intrusion detection systems should rely predominantly on host-based components, but should always make use of NIDS to complete the defense. In short, a truly secure environment requires both a network and host-based intrusion detection implementation to provide for a robust system that is the basis for all of the monitoring, response, and detection of computer misuse.

Open source IDS: Prelude and Snort

snort

Snort is a free and open source Network Intrusion prevention system (NIPS) and network intrusion detection system (NIDS) utilizing a rule-driven language, which combines the benefits of signature, protocol and anomaly based inspection methods. With millions of downloads to date, Snort is the most widely deployed intrusion detection and prevention technology worldwide and has become the de facto standard for the industry. It is capable of performing packet logging and real-time traffic analysis on IP networks. Snort was written by Martin Roesch and is now developed by Sourcefire, of which Roesch is the founder and CTO. Integrated enterprise versions with purpose built hardware and commercial support services are sold by Sourcefire. Snort performs protocol analysis, content searching/matching, and is commonly used to actively block or passively detect a variety of attacks and probes, such as buffer overflows, stealth port scans, web application attacks, SMB probes, and OS fingerprinting attempts, amongst other features. The software is mostly used for intrusion prevention purposes, by dropping attacks as they are taking place. Snort™ can be combined with other software such as SnortSnarf, sguil, OSSIM, and the Basic Analysis and Security Engine (BASE) to provide a visual representation of intrusion data. With patches for the Snort source from Bleeding Edge Threats, support for packet stream antivirus scanning with ClamAV and network abnormality with SPADE in network layers 3 and 4 is possible with historical observation. ( These patches seem to be no longer maintained ) Sourcefire became public in 2007 (NASD:FIRE) after Check Point's attempt to acquire it in 2005 fell through as both companies mutually withdrew from the acquisition process. Sourcefire recently purchased the ClamAV open source project.

http://www.snort.org/

Prelude-IDS, open source hybrid IDS framework

Prelude is an open source Unix based Network-Based Intrusion Detection System. It is released under the GPL license, and is similar to Snort.

Prelude is an Hybrid IDS framework, that is, it is a product that enable all available security application, be it opensource or proprietary, to report to a centralized system. In order to achieve this task, Prelude relies on the IDMEF (Intrusion Detection Message Exchange Format) IETF standard, that enables different kinds of sensors to generate events using an unified language.

Prelude benefits from its ability to find traces of malicious activity from different sensors (Snort, honeyd, Nessus Vulnerability Scanner, Samhain, over 30 types of systems logs, and many others) in order to better verify an attack and in the end to perform automatic correlation between the various events.

Prelude is committed to providing an Hybrid IDS that offers the ability to unify currently available tools into one, powerful, and distributed application.

http://www.prelude-ids.org/