Snort has four main IDS components: the packet capture engine, the preprocessor plug-ins, the detection engine, and the output plug-ins.
The first component is the packet capture engine that picks up traffic using libpcap or WinPcap (both of which will from now on be collectively referred to simply as "pcap"). pcap is a library that enables applications to receive datagrams, parcels through which datalink-level data (data at level two of the seven-layer OSI model) are carried. The network interface card (NIC) physically captures the network traffic and passes it on to drivers that interface with the OS kernel. After the kernel processes the data, pcap then takes the data from the kernel and passes them on to Snort applications, which are normally drivers that interface with the third Snort component, the preprocessor plug-ins. For example, the data go through a bpf interpreter if the kernel supports it. The interpreter decides to which applications the data will be passed. If the no interpreter exists, pcap sends all the packets to the applications, which need to have filters to avoid being bombarded with data.
Snort's preprocessor plug-ins test and inspect packet data they receive from pcap, determining what to do with each packet-whether to analyze it, change it, reject it, and/or generate an alert because of it. The preprocessor plug-ins are highly advantageous because they establish a structure for dealing with packets before they're sent to the next component. Preprocessors modify URIs and URLs to conform to a standard format, provide stateful analysis of TCP/IP traffic, detect portscans, decode RPC packets, decode telnet packets, as well as serve other functions. They also alleviate having to deal with a wide range of undesirable and potentially malicious packet data, including data that could crash Snort or radically deteriorate its performance. Unless a preprocessor plug-in has rejected certain input, it passes it to the next component, the detection engine.
The third major component is the detection engine. Packets are first decoded in a manner that defines the packet structure for layer two protocols, and then layer three protocols, and so on. This enables the detection engine to systematically compare data within every packet it receives to the rule options. This engine then conducts basic tests on whatever part(s) of each packet contain(s) a particular string or value associated with a rule, and then performs another such test using the next rule, and so forth until tests for all rules Snort knows about have been done. Any match is a "hit." The detection engine then moves on to the next packet. A variety of plug-ins (which at the latest count numbered 22, as of version 2.0.2) can also be used to conduct extra detection tests on packets. Every keyword option in every rule is, in fact, associated with a plug-in which, if used, increases the detection engine's capability to identify attacks.
The final major component of Snort is the output plug-ins, the major purpose of which is to produce information to be displayed to intrusion detection analysts. Snort creates alerts based on alerting rules within the preprocessors, the decode engines, and the detection engine. An example of the output of the output plug-ins appears in section "Snort Output." Other output plug-ins perform a variety of other functions, as discussed in the following technical note.
As mentioned in previous chapters, many changes are in store for intrusion detection and intrusion prevention. Some of these changes could actually be negative- at least from the perspective of intrusion detection. For example, the Gartner Group, a technology research and consulting organization, asserts that IDSs will soon be relics of the past. Gartner says that IDSs have not established themselves in the IT marketplace, that they produce too low a return on investment (ROI) for all the resources expended, and that excessive false alarms and misses have greatly impaired their usefulness. Gartner predicts that intrusion prevention technology will prevail in the belief that shutting off intrusions altogether is better than allowing intrusions to occur and just monitoring them. Accordingly, Gartner recommends that IT organizations turn to firewalls, not IDSs. Many IT security experts denounced Gartner's prediction, though, saying that Gartner does not really understand how intrusion detection fits in with a layered defense approach (of which many believe that intrusion detection is a critical part) and that intrusion detection technology is still growing and improving.
Regardless of whatever sliver of truth there may or may not be in Gartner's prediction, two things are certain-intrusion detection is still a long way from being mature, and intrusion prevention technology is in its infancy. Massive changes are in store for both areas. This chapter focuses on some of the areas within intrusion detection and intrusion prevention in which substantial and beneficial progress is likely to occur. These areas include the following:
The continued reduction in reliance on signatures in intrusion detection
The growth of intrusion prevention
Advances in data correlation and alert correlation methods
Advances in source determination
Inclusion of integrated forensics functionality in IDSs and IPSs
Greater use of honeypots
Bro is intended for use by sites requiring flexible, highly customizable intrusion detection. It is important to understand that Bro has been developed primarily as a research platform for intrusion detection and traffic analysis. It is not intended for someone seeking an "out of the box" solution. Bro is designed for use by Unix experts who place a premium on the ability to extend an intrusion detection system with new functionality as needed, which can greatly aid with tracking evolvi 24224d36y ng attacker techniques as well as inevitable changes to a site's environment and security policy requirements.
Since Bro is open source and runs on commodity PC hardware, it provides a low-cost means to experiment with alternative techniques. Some sites may wish to run a commercial IDS as their front-line of defense, and then also run Bro as a way to:
Bro is a network-based IDS. It collects, filters, and analyzes traffic that passes through a specific network location. A single Bro monitor, strategically placed at a key network junction, can be used to monitor all incoming and outgoing traffic for the entire site. Bro does not use or require installation of client software on each individual, networked computer.
Bro policy scripts are programs written in the Bro language. They contain the "rules" that describe what sorts of activities are deemed troublesome. They analyze the network activity and initiate actions based on the analysis. Although the Bro language takes some time and effort to learn, once mastered, the Bro user can write or modify Bro policies to detect and alert on virtually any type of network activity.
Bro comes with a rich set of policy scripts designed to detect the most common Internet attacks while limiting the number of false positives, i.e., alerts that confuse uninteresting activity with the important attack activity. These supplied policy scripts will run "out of the box" and do not require knowledge of the Bro language or policy script mechanics.
Bro policies incorporate a signature matching facility that looks for specific traffic content. For Bro, these signatures are expressed as regular expressions, rather than fixed strings. Bro adds a great deal of power to its signature-matching capability because of its rich language. This allows Bro to not only examine the network content, but to understand the context of the signature, greatly reducing the number of false positives. Bro comes with a set of high value signatures policies, selected for their high detection and low false positive characteristics.
Bro not only looks for signatures, but can also analyze network protocols, connections, transactions, data amounts, and many other network characteristics. It has powerful facilities for storing information about past activity and incorporating it into analyses of new activity.
Bro policy scripts can generate output files recording the activity seen on the network (including normal, non-attack activity). They can also generate problem alerts to event logs, including the operating system syslog facility. In addition, scripts can execute programs, which can, in turn, send e-mail messages, page the on-call staff, automatically terminate existing connections, or, with appropriate additional software, insert access control blocks into a router's access control list. With Bro's ability to execute programs at the operating system level, the actions that Bro can initiate are only limited by the computer and network capabilities that support Bro.
The Bro distribution includes a tool, snort2bro, which converts Snort signatures into Bro signatures. Along with translating the format of the signatures, snort2bro also incorporates a large number of enhancements to the standard set of Snort signatures to take advantage of Bro's additional contextual power and reduce false positives.
Architecturally, Bro is layered into three major components. It uses the now-standard libpcap packet-capture library developed by LBNL's Network Research Group to filter the packet stream in the kernel for high performance.
The filtered packets are then passed along to Bro's event engine, which reduces the filtered stream into a series of higher-level events. These events reflect network activity in policy-neutral terms. That is, what has happened but not why or whether it is significant.
Finally, Bro's policy script interpreter executes event handlers written in the custom Bro scripting language. These scripts express a site's security policy, i.e., what actions to take when the monitor detects different types of activity. The scripting language is very powerful, allowing Bro to track detailed information about the network's activity. Scripts can generate real-time alerts and can also execute arbitrary programs. This last means that Bro can respond to attacks. For example, at LBNL the operational Bro's configuration will sometimes block a remote Internet host from further access to the Laboratory's network, which can be viewed as a form of reactive firewall.
Cisco:
Both the IDS and IPS versions of this feature center around the ip audit set of commands. And both offer three possible actions in response to a detected threat:
Alarm
Sends a notification to your network management system. There are a few different options available for doing this. Alarms can be sent by Syslog. Alternatively, prior to IOS Version 12.3(14)T, you could send alarms using Post Office Protocol (POP). However, this option has since been deprecated and we do not recommend using it, even if you are still running an IOS version that supports it.
Drop
Instructs the router to simply drop any offending packets. This response is only appropriate for certain types of attacks, particularly those that use nonsession-based protocols such as UDP.
Reset
When you configure a reset a session in response to matching a particular signature, it forwards the packet on to the destination, but with the TCP RST flag set to force the end device to immediately drop the session.
It is important to note that you can (and probably should) apply all three of these options to most rules. This way you will always receive notification that the system has detected a problem, and the router will always attempt to deal with the problem in the most effective way: resetting the session if possible, and dropping the packet if there is no session to reset.
Team up intrusion detection and intrusion prevention systems for greatest security.
Layered security is the key to protecting any size network, and for most companies, that means deploying both intrusion detection systems (IDS) and intrusion prevention systems (IPS). When it comes to IPS and IDS, it's not a question of which technology to add to your security infrastructure - both are required for maximum protection against malicious traffic. In fact, vendors are increasingly combining the two technologies into a single box.
At its most basic, an IDS device is passive,
watching packets of data traverse the network from a monitoring port, comparing
the traffic to configured rules, and setting off an alarm if it detects
anything suspicious. An IDS can detect several types
of malicious traffic that would slip by a typical firewall, including network
attacks against services, data-driven attacks on applications, host-based
attacks like unauthorized logins, and malware like
viruses, Trojan horses, and worms. Most IDS products use several methods to
detect threats, usually signature-based detection, anomaly-based detection, and
stateful protocol analysis.
The IDS engine records the incidents that are logged by the IDS sensors in a
database and generates the alerts it sends to the network administrator.
Because IDS gives deep visibility into network activity, it can also be used to
help pinpoint problems with an organization's security policy, document
existing threats, and discourage users from violating an organization's
security policy.
The primary complaint with IDS is the number of false positives the technology
is prone to spitting out - some legitimate traffic is inevitable tagged as bad.
The trick is tuning the device to maximize its accuracy in recognizing true
threats while minimizing the number of false positives; these devices should be
regularly tuned as new threats are discovered and the network structure is
altered. As the technology has matured in the last several years, it has gotten
better at weeding out false positives. However, completely eliminating them
while still maintaining strict controls is next to impossible - even for IPS,
which some consider the next step in the evolution of IDS.
At its most basic, an IPS has
all the features of a good IDS, but can also stop
malicious traffic from invading the enterprise. Unlike an IDS,
an IPS sits inline with traffic flows on a network, actively shutting down
attempted attacks as they're sent over the wire. It can stop the attack by
terminating the network connection or user session originating the attack, by
blocking access to the target from the user account, IP address, or other
attribute associated with that attacker, or by blocking all access to the
targeted host, service, or application.
In addition, an IPS can respond to a detected threat in two other ways. It can
reconfigure other security controls, such as a firewall or router, to block an
attack. Some IPS devices can even apply patches if the host has particular
vulnerabilities. In addition, some IPS can remove the malicious contents of an
attack to mitigate the packets, perhaps deleting an infected attachment from an
email before forwarding the email to the user.
Because IDS and IPS devices sit in different spots on the
network, they can - and should - be used concurrently. An IPS product installed
at the perimeter of the network will help stop zero day attacks, such as worms
and viruses, in their tracks - even the newest threats can be blocked with
rigorous tuning. An IDS product installed inside the firewall will monitor
internal activity, guarding against the ever-present insider threat, and lend
greater visibility into security events, past and present.
Choosing a product that offers both technologies can be the most cost-effective
and efficient approach. "With one device that does IDS and IPS, you can enable
IDS on part of the network and enable IPS on a different part. It's almost a
virtual device," says Sanjay Beri, senior director of
product management at Juniper Networks, a network infrastructure vendor based
in
Intrusion detection has morphed into intrusion prevention. Here's what the near - and far - future hold for IDS and IPS.
IT security technology evolves quickly, forever trying to stay one step ahead of the myriad threats constantly bombarding enterprise networks. What started as intrusion detection systems (IDS quickly morphed into intrusion prevention systems (IPS). Now many security vendors offer devices that integrate both technologies into a single appliance. The forward motion toward increasingly proactive protection continues. What does the near - and far - future hold for IDS/IPS technology?
A series of recent vendor announcements promise a spate of new IPS products
on tap for 2007. They aim to extend intrusion prevention to all network
endpoints and to even the largest carrier networks. On May 22 at the 2007 Interop conference in
IBM will launch the Proventia Network Intrusion
Prevention System GX6116 by the end of this year's second quarter. Designed for
the core of larger enterprise and carrier networks, it will support throughput
of as fast as 15Gbps, provide inspection for as much as 6Gbps of traffic, and
protect against eight network segments. Similarly, McAfee announced the
upcoming IntruShield 10 Gigabit Ethernet IPS
appliances, which will launch in the second half of 2007. These are built for
10GigE and IPv6 networks and will perform as fast as 10Gbps. Also, in February,
Austin-based IPS vendor Tipping Point revealed its plans for an IPS for
laptops; this solution would close the gap often opened up when guest users log
on to corporate networks.
One computer science researcher is even looking to apply a theory about how the
human immune system functions - called the Danger Theory - to IDS technology.
Dr. Uwe Aickelin, an
associate professor at the
An intrusion detection system (IDS) generally detects unwanted manipulations of computer systems, mainly through the Internet. The manipulations may take the form of attacks by crackers.
An intrusion detection system is used to detect several types of malicious behaviors that can compromise the security and trust of a computer system. This includes network attacks against vulnerable services, data driven attacks on applications, host based attacks such as privilege escalation, unauthorized logins and access to sensitive files, and malware (viruses, trojan horses, and worms).
An IDS is composed of several components: Sensors which generate security events, a Console to monitor events and alerts and control the sensors, and a central Engine that records events logged by the sensors in a database and uses a system of rules to generate alerts from security events received. There are several ways to categorize an IDS depending on the type and location of the sensors and the methodology used by the engine to generate alerts. In many simple IDS implementations all three components are combined in a single device or appliance.
In a network-based intrusion-detection system (NIDS), the sensors are located at choke points in the network to be monitored, often in the demilitarized zone (DMZ) or at network borders. The sensor captures all network traffic and analyzes the content of individual packets for malicious traffic. In systems, PIDS and APIDS are used to monitor the transport and protocols illegal or inappropriate traffic or constructs of language (say SQL). In a host-based system, the sensor usually consists of a software agent, which monitors all activity of the host on which it is installed. Hybrids of these two systems also exist.
In a passive system, the intrusion detection system (IDS) sensor detects a potential security breach, logs the information and signals an alert on the console and or owner. In a reactive system, also known as an intrusion prevention system (IPS), the IDS responds to the suspicious activity by resetting the connection or by reprogramming the firewall to block network traffic from the suspected malicious source. This can happen automatically or at the command of an operator.
Though they both relate to network security, an intrusion detection system (IDS) differs from a firewall in that a firewall looks outwardly for intrusions in order to stop them from happening. Firewalls limit access between networks to prevent intrusion and do not signal an attack from inside the network. An IDS evaluates a suspected intrusion once it has taken place and signals an alarm. An IDS also watches for attacks that originate from within a system.
This is traditionally achieved by examining network communications, identifying heuristics and patterns (often known as signatures) of common computer attacks, and taking action to alert operators. A system which terminates connections is called an intrusion prevention system, and is another form of an application layer firewall.
NIDS
Network Intrusion Detection Systems are placed at a strategic point or points within the network to monitor traffic to and from all devices on the network. Ideally you would scan all inbound and outbound traffic, however doing so might create a bottleneck that would impair the overall speed of the network.
HIDS
Host Intrusion Detection Systems are run on individual hosts or devices on the network. A HIDS monitors the inbound and outbound packets from the device only and will alert the user or administrator of suspicious activity is detected
Signature Based
A signature based IDS will monitor packets on the network and compare them against a database of signatures or attributes from known malicious threats. This is similar to the way most antivirus software detects malware. The issue is that there will be a lag between a new threat being discovered in the wild and the signature for detecting that threat being applied to your IDS. During that lag time your IDS would be unable to detect the new threat.
Anomaly Based
An IDS which is anomaly based will monitor network traffic and compare it against an established baseline. The baseline will identify what is "normal" for that network- what sort of bandwidth is generally used, what protocols are used, what ports and devices generally connect to each other- and alert the administrator or user when traffic is detected which is anomalous, or significantly different, than the baseline.
An intrusion prevention system is a computer security device that monitors network and/or system activities for malicious or unwanted behavior and can react, in real-time, to block or prevent those activities. Network-based IPS, for example, will operate in-line to monitor all network traffic for malicious code or attacks. When an attack is detected, it can drop the offending packets while still allowing all other traffic to pass. Intrusion prevention technology is considered by some to be an extension of intrusion detection (IDS) technology. The term "Intrusion Prevention System" was coined by Andrew Plato who was a technical writer and consultant for *NetworkICE.
Intrusion prevention systems (IPS) were invented in the late 1990s to resolve ambiguities in passive network monitoring by placing detection systems in-line. A considerable improvement upon firewall technologies, IPS make access control decisions based on application content, rather than IP address or ports as traditional firewalls had done. As IPS systems were originally a literal extension of intrusion detection systems, they continue to be related.
The first commercial/retail IPS was the BlackICE
product from NetworkICE Corporation. It debuted in
1998 with a business and personal version of the product. It provided host and
in-line network IPS capabilities using protocol analysis as its core detection
technique. The first products were BlackICE Desktop
(a host-IPS for end-user systems) BlackICE Guard (an
in-line network IPS) and BlackICE Sentry (a passive,
IDS solution).
Intrusion prevention systems may also serve secondarily at the host level to deny potentially malicious activity. There are advantages and disadvantages to host-based IPS compared with network-based IPS. In many cases, the technologies are thought to be complementary.
An Intrusion Prevention system must also be a very good Intrusion Detection system to enable a low rate of false positives. Some IPS systems can also prevent yet to be discovered attacks, such as those caused by a Buffer overflow.
The role of an IPS in a network is often confused with access control and application-layer firewalls. There are some notable differences in these technologies. While all share similarities, how they approach network or system security is fundamentally different.
An IPS is typically designed to operate completely invisibly on a network. IPS products do not have IP addresses for their monitoring segments and do not respond directly to any traffic. Rather, they merely silently monitor traffic as it passes. While some IPS products have the ability to implement firewall rules, this is often a mere convenience and not a core function of the product. Moreover, IPS technology offers deeper insight into network operations providing information on overly active hosts, bad logons, inappropriate content and many other network and application layer functions.
Application firewalls are a very different type of technology. An application firewall uses proxies to perform firewall access control for network and application-layer traffic. Some application-layer firewalls have the ability to do some IPS-like functions, such as enforcing RFC specifications on network traffic. Also, some application layer firewalls have also integrated IPS-style signatures into their products to provide real-time analysis and blocking of traffic. Application firewalls do have IP addresses on their ports and are directly addressable. Moreover, they use full proxy features to decode and reassemble packets. Not all IPS perform full proxy-like processing. Also, application-layer firewalls tend to focus on firewall capabilities, with IPS capabilities as add-on. While there are numerous similarities between the two technologies, they are not identical and are not interchangeable.
Unified Threat Management (UTM), or sometimes called "Next Generation Firewalls" are also a different breed of products entirely. UTM products bring together multiple security capabilities on to a single platform. A typical UTM platform will provide firewall, VPN, anti-virus, web filtering, intrusion prevention and anti-spam capabilities. Some UTM appliances are derived from IPS products such as 3Com's X-series products. others are derived from firewall products, such as Juniper's SSG or Cisco's ASA appliances. And still others were derived from the ground up as a UTM appliance such as Astaro or Fortinet. The main feature of a UTM is that it includes multiple security features on one appliance. IPS is merely one feature.
Access Control is also an entirely different security concept. Access control refers to general rules allowing hosts, users or applications access to specific parts of a network. Typically, access control helps organizations segment networks and limit access. While an IPS has the ability to block access to users, hosts or applications, it does so only when malicious code has been discovered. As such, IPS does not necessarily serve as an access control device. While it has some access control abilities, firewalls and network access control (NAC) technologies are better suited to provide these features.
IPS systems have some advantages over intrusion detection systems (IDS). One advantage is they are designed to sit inline with traffic flows and prevent attacks in real-time. In addition, most IPS solutions have the ability to look at (decode) layer 7 protocols like HTTP, FTP, and SMTP which provides greater awareness. When deploying NIPS however, consideration should be given to whether the network segment is encrypted or not as many products are unable to support inspection of such traffic.
A host based IPS (HIPS) is one where the intrusion-prevention application is resident on that specific IP address, usually on a computer.
Other types of HIPS are home information packs - these can be viewed at https://www.hipsco.co.uk
A network based IPS is one where the IPS application/hardware and any actions taken to prevent an intrusion on a specific network host(s)is done from a host with another IP address on the network (This could be on a front-end firewall appliance.)
Network intrusion prevention systems (NIPS) are purpose-built hardware/software platforms that are designed to analyze, detect, and report on security related events. NIPS are designed to inspect traffic and based on their configuration or security policy, they can drop malicious traffic.
A content based IPS (CBIPS) inspects the content of network packets for unique sequences, called signatures, to detect and hopefully prevent known types of attack such as worm infections and hacks.
A key development in IDS/IPS technologies was the use of protocol analyzers. Protocol analyzers can natively decode application-layer network protocols, like HTTP or FTP. Once the protocols are fully decoded, the IPS analysis engine can evaluate different parts of the protocol for anomalous behavior or exploits. For example, the existence of a large binary file in the User-Agent field of an HTTP request would be very unusual and likely an intrusion. A protocol analyzer could detect this anomalous behavior and instruct the IPS engine to drop the offending packets.
Not all IPS/IDS engines are full protocol analyzers. Some products rely on simple pattern recognition techniques to look for known attack patterns. While this can be sufficient in many cases, it creates an overall weakness in the detection capabilities. Since many vulnerabilities have dozens or even hundreds of exploit variants, pattern recognition-based IPS/IDS engines can be evaded. For example, some pattern recognition engines require hundreds of different signatures (or patterns) to protect against a single vulnerability. This is because they must have a different pattern for each exploit variant. Protocol analysis-based products can often block exploits with a single signature that monitors for the specific vulnerability in the network communications.
Rate based IPS (RBIPS) are primarily intended to prevent denial of service and Distributed Denial of Service attacks. They work by monitoring and learning normal network behaviors. Through real-time traffic monitoring and comparison with stored statistics, RBIPS can identify abnormal rates for certain types of traffic e.g. TCP, UDP or ARP packets, connections per second, packets per connection, packets to specific ports etc. Attacks are detected when thresholds are exceeded. The thresholds are dynamically adjusted based on time of day, day of the week etc., drawing on stored traffic statistics.
Unusual but legitimate network traffic patterns may create false alarms. The system's effectiveness is related to the granularity of the RBIPS rulebase and the quality of the stored statistics.
Once an attack is detected, various prevention techniques may be used such as rate-limiting specific attack-related traffic types, source or connection tracking, and source-address, port or protocol filtering (black-listing) or validation (white-listing).
A network intrusion detection system (NIDS) is an intrusion detection system that tries to detect malicious activity such as denial of service attacks, port scans or even attempts to crack into computers by monitoring network traffic.
The NIDS does this by reading all the incoming packets and trying to find suspicious patterns. If, for example, a large number of TCP connection requests to a very large number of different ports are observed, one could assume that there is someone committing a "port scan" at some of the computer(s) in the network. It also (mostly) tries to detect incoming shellcodes in the same manner that an ordinary intrusion detection systems does.
A NIDS is not limited to inspecting incoming network traffic only. Often valuable information about an ongoing intrusion can be learned from outgoing or local traffic as well. Some attacks might even be staged from the inside of the monitored network or network segment, and are therefore not regarded as incoming traffic at all.
Often, network intrusion detection systems work with other systems as well. They can for example update some firewalls' blacklist with the IP addresses of computers used by (suspected) crackers.
The first step in the evaluation process should be to identify the importance
of each of the topics listed in the following sections. The importance of
individual criteria is likely to change from organisation
to organisation. In many cases a topic will also
require the identification of features specific to the network and systems to
be monitored.
The main performance requirement of a NIDS is to detect intrusions. However the
definition of a intrusion is currently unclear. In
particular, many vendors and researchers appear to consider any attempt to
place malicious traffic on the network as a intrusion.
In reality a more useful system will log malicious traffic and only inform the
operator if the traffic posses a serious threat to the security of the target
host. Snort is tending towards this direction with the use a
alert classification ranging from 1 to 10. With 1
representing a point of interest only and 10 representing a major threat to
security.
All NIDSs should be capable of detecting known
vulnerabilities. However research (Allen 2000) (NSS
2001) indicates that many commercial IDS fail to detect recently discovered
attacks. On the other hand if a vulnerability or attack is known all systems
should be patched, or workarounds applied thus the need for a NIDS to detect
these events will be removed. Unfortunately the reality is that many systems
are not patched or upgraded as vulnerabilities are discovered. This is clearly
indicated by the number of system compromises that occur everyday, and the fact
that most of the problems on the SANS top twenty list are predominantly old
well known problems, with fixes available.
This must be the most important feature of any IDS. It is the IDS that can
detect attacks that are not yet known which will justify its implementation.
New vulnerabilities are discovered every day. By its very nature these are also
the most difficult attacks to detect.
This refers to the ability of the NIDS to identify the relative importance of
any attack. To return to the example already given the use of a windows exploit
on a UNIX system is not of high importance. However if the alert is raised, and
the analyst must investigate every alert, a mechanism should be available to
distinguish the relevance of different alerts.
Any IDS should be able to continue consistantly
operate in all circumstances. The application and operating system should be
capable of running for years without segmentation faults or memory leakage.
A important function of a NIDS is to consistently
report identical events in the same manner. One disadvantage of a product using
signature recognition is the ability of different users to configure different
alerts to provide different messages. Thus traffic on one network may trigger a
different alert to the same traffic on another system of the same type. A
number of efforts are currently underway to solve this problem. Both securityfocus and CVE provide databases of known
vulnerabilities, and exploits targeting them.
The system should also be able to withstand attempts to compromise it. If a attacker can identify a NIDS on a network it will could
prove to be a valuable asset. It is also possible the attacker will attempt to
disable the system using DoS or DDoS
techniques. The system should be able to withstand all of these types of
attack.
The information provided to the analyst when a alert
is raised should be enough to clearly identify the reason the event causing the
event to be raised, and the reason this event is of interest. It should also
provide links to vulnerability databases, such as bugtraq
or CVE to assist the analyst in determining the relevance and appropriate
reaction to a particular alert.
The alert should also identify the source of the alert and the target system.
Further information such as a whois or DNS lookup on a IP address would be also be beneficial.
Identification of the potential severity of a attack.
Some alerts are triggered by events to related to
information gathering, such as port scanning. Although this information may be
relevant if a more serious attack in launched the volume of scanning that
occurs on the internet makes it impractical to investigate every time a network
is scanned. On the other hand indication that a local hosts
has been compromised by a trojan should be given
higher priority.
Another useful (although currently non existent) feature of a NIDS should be to
indicate the outcome of a attack. In most cases a alert simply indicates that a attempt has been made. It is
then the responsibility of the analyst to search for correlating activity to
indicate the outcome of the attack. If a NIDS were to present the analyst with
a list of other alerts generated by the target host, and a summary of other
(non alert) traffic the evaluation of the outcome could be greeted accelerated.
The legal validity of the data collected by any IDS is of extreme importance if
any legal will be taken against the attacker. A disturbingly large number of
systems do not collect the actual network packets,
instead they simply record their own interpretation of events. A more robust systems will also capture and store the
network traffic, as well as raising the alert.
One of the greatest risks of a IDS is that once the
system is implemented it will not be utilised to its
full capabilities. Often the reason for this is due to the complexity of
configuring and maintaining the system. It is also important that a IDS can be optimised for a
particular network. There is no point in monitoring for web server exploits if
there is not a web server on the network.
Unfortunately the usability of a system is usually inversely proportional to
the flexibility and customisability of that system.
The desire for flexibility can configurable of the system will be determined by
the users of the system, the network in which it will be operating and the
level of functionality required from the system.
If the system is to be maintained by a network administrator who is also
responsible for standard network management he or she is unlikely to have the
time available to optimise and configure the system
so useability will be a primary consideration. On the
other hand if a intrusion analyst if employed
specifically to manage intrusion detection a more complex system with greater
functionality may be desired.
The NIDS should be capable of being optimised for the
systems on the network. As mentioned earlier there is no point in performing
http analysis if a web server is not operating on the network under inspection.
The level of traffic on the network will also determine the intensity of
analysis performed. A simple system suitable for a single network segment with
low traffic will be able to combine the sensor and analysis functions within
the single unit. A network with high levels of traffic may need to separate the
sensor and analysis functions across different hosts.
There are also a number of other configuration options that may apply to
particular situations. For example in some situations the NIDS (ie analyst) may not be allowed to view the contents of
packets on the network. In this case it should be possible to configure the
NDIS to only examine (and store) the header information from the packets.
Most organisations grow and expand over time. As they
expand so do their supporting infrastructure, include computer networks. Any
IDS should be capable of expanding with the network. As new network segments
are added new NIDS may also be needed. Will it be possible to consolidate the
reports from multiple NIDS into a single user interface? Another important
question will be the storage of this information. If a small network is
monitored data storage may be possible in flat files. However as the amount of
data collected grows it may be necessary to transfer this data storage into a
database.
Research has proven that the most effective intrusion detection requires
correlating information from a range of sources. This includes NIDS, HIDS,
system logs, firewall logs and any other information sources available. At the
time of writing the Intrusion Detection Working Group (IDWG) had submitted a
number of documents defining standards for communication between IDSs. It is expected that these will be released as RFCs in the near future.
Once these standards are implemented any IDS using the standard protocols will
be able to communicate with and other IDS. This will enable a
organisation to implement a range of IDS from
different vendors and still maintain interoperability.
The level of vendor support required in a
implementation will be determined by the skill levels of the staff implementing
the system. However as staff turnover rates are common in the IT industry it is
worthwhile considering the level of support that is available from the vendor.
Any signature based IDS is dependant upon it signatures to detect intrusions.
The abilities of these systems to detect new, or even
modified intrusions has been shown to be poor (Allen 2000). In order for these
systems to be effective updated signatures must be available as new
vulnerabilities and exploits are discovered.
Many signature based systems now allow the operator to create their own
signatures. This can allow the system to monitor for new alerts as they are
discovered without relying on the vendor to supply updates. However monitoring
vulnerabilities and writing signatures as they occur is a demanding task.
Consider the amount of traffic on bugtraq in a single
day.
Selecting and implementing a NIDS is a challenging task. There are a number of
factors to be considered, and these factors will change from situation to
situation. In order to ensure a sucessful
implementation a organisation
should determine its requirements and then locate a system that meets them.
A recent evolution in the security technology space has been the convergence of intrusion-prevention systems (IPS) and firewall technologies. This has given birth to new technology called Next Generation Firewalls. Next generation firewalls leverage their existing deep packet inspection engine by sharing this functionality with an intrusion protection engine. As part of this process, streams which have been allowed by the firewall are subsequently submitted for malicious stream analysis to the IPS engine. The reuse of the deep packet inspection engine brings about a significant increase in performance and helps administrators get a consolidated security view of their network. With time, these firewalls could potentially start including other content processing technologies like anti-virus which can leverage the deep packet inspection technologies to provide comprehensive protection.
|
