January 26th, 2004, 01:18 PM
A look into IDS/Snort Whole thing by QoD
Here is the full article, all 3 parts.
A look into IDS/Snort
Januray, 7th 2004
Over the years IDS has gained popularity amongst organizations, with the rise of security risks, we needed a methods of detecting and possibly stopping intrusions. Last year alone (2002) we were hit with many viruses which could have been avoidable. In this paper we will discuss some of the concepts behind IDS, an infant technology that till recently has saw demand in businesses.
Disclaimer and Copyright:
Copyright © 2004 , 2005 Q.o.D <QoDwriting@gawab.com>
This document is free software; you can redistribute and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version.
This document is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
1.1What is an IDS?
Intrusion detection systems(IDS) could be defined as a system that employs process of gathering information (though logs or sniffing) and analyzing that information for possible attempts of intrusion. Throughout this paper Intrusions would be referring to both misuse and intrusions unless otherwise specified. Intrusions are attacks originating from outside of your network, while misuse on the other hand refers to attacks that originate from the inside of you network.
To further clarify this definition think of a burglar alarm or a surveillance system that watches your house when you are on vacation. If you house is robed then you could use logs from the burglar alarm and the video tape from the surveillance camera to identify the robber. An IDS functions in much the same way on your network that constantly looks through the network packets trying to detect an intrusion. Once an intrusion is detected it will take the proper action that you specified (sending an email to the security guy in the network, or just logging the alert). It is important that you understand that just like a surveillance camera, IDS is used for detection and not prevention.
Numerous IDS types are in the market today, although this paper will talk about HIDS, DIDS, and Hybrid IDS our main focus would be NIDS. Please note that IDS is not effective if you lack essential security. For example do not expect an IDS to be effective on a network that uses telnet or FTP for authentication and does not have a firewall in place.
1.2 With firewalls
IDS is just an added layer of protection that substitutes of what firewalls lack, this includes:
1. Reliable logs
Most attackers (or at least smart ones) will clean up after they are done with there system compromise. Implemented effectively, IDS could block attackers from editing the IDS log files or at least present some more difficult challenge for the attacker.
These logs are also important if you later want to prosecute the attacker, remember that logs would be your only evidence that the attack even took place, and the attacker was the one who cracked your system.
2. Detailed logs
A good IDS will provide you with a detailed log and a captured packet of the attack. This might help you fix the problem with your security.
3. Real-time alert
Real-time alerting would notify you when an attack is underway this is definitely important against attacks that depend on speed and how much your system could handle before it crashes, an example of such attack is a Denial of Service(Dos) attack.
4. Detecting prelude(beginnings) of an attack
Since most hackers need to follow a process before attacking a network, beginning mostly with footprinting and network probing (portscaning, vulnerability scanning, etc.). It is quite possible that a smart admin (or a lucky one) could be able to catch an attack before it even happens.
5. Insider threat
While firewalls do a great job in detecting attacks originating from the outside of the network, they could do little to stop or even detect attacks originating from the inside. A recent study done by CSI/FBI 2003 showed that 45% of reported attacks originated from the inside of the network, mainly because they know too much about the systems around them and the daily routine.
6. Possible policy violation
For example some networks prohibits the use of P2P programs, such as Kazaa and GNUTella because the expose your network to many security threats. A good IDS could be configured to detect these kinds of programs on your network and report their use to the network or system administrator.
One thing to keep in mind though, just like you would not put money on the street, monitor it and expect it to be there the following morning, you should not leave your network wide open and vulnerable expecting your IDS to help you. An IDS does not substitute for security they just aid in making it better.
Over the years many types of ID systems have emerged, but only two NIDS and HIDS are widely used today. HIDS (Host based intrusion detection) functions by examining your log files, these logs might include your system logs or application logs, they then search for unexpected system behavior and report them. HIDS is installed on your system you want to monitor and will only detect actions on that host (See figure 1.2). Some of the best examples of HIDS include Honey pot, PortSentry, Tripwire(the most popular HIDS on Linux), and even RPM could be used as an HIDS.
There are two main types of HIDS:
1) Target monitoring HIDS
This type detects changes in some of the important files, like index.html if you are running a website. The target monitoring works by constantly checking the hash of the files (MD5 is the most popular) and comparing it to the previous hash, if any thing is different it logs it and takes the appropriate action. Tripwire is famous for this type of detection.
2) Log monitoring HIDS
Deferent from the target monitoring HIDS is different from target monitoring in many ways. It works by searching the logs for suspicious behavior, for example if user Joe has escalated his privilege to root then an alarm goes on and the HIDS takes the proper action.
Some of the advantages of using HIDS over other types of IDS technologies include:
1) Could cost less than NIDS
HIDS does not require any dedicated hardware.
2) Logs could offer more detail about the attack
HIDS records every action the attacker takes on the system. HIDS like honeypots even log the attackers keystrokes.
3) Produces ess false negatives
HIDS could detect attacks that might appear to be normal to a NIDS.
4) Can Handle encrypted attacks.
5) Detects what happens to your system after the attack
6)Works well with mobile devices such as laptops
While some of the disadvantages include:
1) Only detects attacks after they have occurred.
2) Could be disabled by a talented attacker
if the attacker hacks your system, he might be able to disable or alter the logs so the HIDS would lead in becoming untrustworthy.
3) Produces some CPU overhead, this is troublesome if you need every bit of your CPU processes.
4) HIDS is not available for every OS
Because of the way they work, HIDS tend to be OS specific especially the in the Log monitoring HIDS, so an HIDS that is made for a FreeBSD server cannot be used for Windows 2000 server. So if you have an old or rare OS it might be hard for you to find a good HIDS.
5) HIDS has no knowledge of the system around them
One thing that this is important is when an attacker attacks you from a system on your network that does not have HIDS installed and you have a trust relationship with.
6) Each system that you need to monitor must have HIDS installed on it.
This might lead to higher costs on large networks.
7) If the IDS has no centralized logging capability monitoring it would lead to an administrator's nightmare.
8) HIDS can not log attacks if it is turned off
If an attacker uses a denial of service(DoS) attack against your system and it goes down, you will not know what happens next. And if the attack makes the system go down instantly then the HIDS might not be able to detect anything.
As you might see HIDS has its good and bads, another type of IDS, Network based IDS (NIDS) will be discussed next. Keep in mind that this paper focuses more on NIDS and not HIDS.
The most popular and widely deployed IDS today is the Network based IDS. NIDS serves a different function than the HIDS, it monitors the entire network instead of just on system like a burglar alarm at your house. They do that by analyzing the network packets and not the logs. They receive the packets by sniffing the network(sniffing and how it works is discussed later).
There are two main types of NIDS although they function similarly they offer a different type of service at the end:
1) Network based IDS
This type works by sniffing the network off the network, by putting the network interface card into promiscuous mode. They could easily monitor an entire network, and are the most popular.
2) Network node based IDS
Network node based IDS on the other hand only monitor the host they reside on, similar to HIDS but they analyze the network packets and not the logs. One advantage that this type has over the other is that not all network cards are able to function in promiscuous mode.
Some of the most popular NIDS include Snort, Cisco secure IDS, BlackICE Guard, ISS Realsecure, Dragon, and Shadow. But by far Snort is the most widely used and preferred NIDS, we will discuss Snort later.
1) One NIDS should be enough to monitor a network
This might not be true for a huge network, but it is true for medium and small sized networks. There are two advantages for this: 1) Central logging capability, so you do not want to go from . workstation to workstation to analyze the logs, 2) It is cheaper.
2) Real time detection and alerting
since many hackers follow a pattern to attack your network, you might be able (with some luck) be able to detect and stop the alert in real time.
You could drop a NIDS into a network, without caring about obsolete operating system and it will still detect attack, although i would recommend you tweak the NIDS to stop getting false alarms.
4) Independent system
This could be a disadvantage and an advantage, a disadvantage would be that you need another system, an advantage would be that the NIDS will not consume your precious system resources.
5) Detecting lower level attacks
NIDS function at the network layer and because of that they are able to detect low level attacks such as arp spoofing etc...
1) Misses some attacks
Going back to the fact that NIDS operate at the network layer. Some NIDS do not make sense of higher level protocols such as HTTP. They are greatly however challenged by encryption, which will be discussed later in this paper.
2) Single point of failure
If your NIDS goes down because of some sort of a DoS attack then all of your IDS system will fail.
3) Tends to produce higher false alerts than HIDS.
4) Some network cards do not support promiscuous mode.
5) Most current NIDS do not function well under high speed networks such as Gigabyte Ethernet.
As you have seen several limitations of NIDS it would become apparent that you will need a combination of both NIDS and HIDS on your network. This is the primary reason why a new bread of IDS has emerged hybrid based IDS.
1.5 Hybrid IDS
This is a new breed of IDS in what some security people believe is the future. They combine the goods(and some the bads) of both HIDS and Network node IDS. There are some disadvantages though in using hybrid IDS:
1) This is an infant technology and some commercial products could be expensive. There is however a great open source hybrid IDS called Prelude which could be found at www.Prelude-IDS.org . Some of the commercially available hybrid IDS include NFR HIDS, and Stormwatch.
2)They can only monitor one host just like the HIDS.
LIDS (Linux IDS) is a Linux kernel patch that would allow users to limit the power of root, by giving programs the rights they need, with no excess. LIDS currently support both the 2.2 and the 2.4 kernel. The importance of this comes when a program is compromised and gives the attacker right to whatever the owner was, so if it was root then the attacker will have GOD access to the system. If LIDS implemented however and a process running as root is compromised it will limit the attacker to whatever root has access to, for example root might not be able to run ' rm -fr /* '.
From the LIDS FAQ:
"LIDS is an enhancement of Linux kernel written by Xie Huagang and Philippe Biondi. It implements several security features that are not in the Linux kernel natively. Some of these include: mandatory access controls (MAC), a port scan detector, file protection (even from root), and process protection."
One noticeable disadvantage to LIDS is that they are hard to configure, and if implemented wrong they would break the applications.
DIDS (Distributed IDS) compose of multiple HIDS or NIDS sensors reporting to a main system called the management station. This is mostly seen in large organizations with multiple subnets, networks, and offices.
1) Central logging, and management.
2) Makes updating and modifying rules for the systems a "piece of cake".
1)Not all NIDS and HIDS support this function, some only support DIDS from the same manufacturer.
1.6 Signature based Detection
Now that we have what IDS and types out of the way we will see how the IDS nows what is an intrusion. The first oldest and widely used method is Signature based detection. Signature based detection works by analyzing each packet against a know attack signature, like an Anti-virus scanner. Signatures are a database of attack signatures, and a signature is a unique characteristic or pattern that must be followed to be successful, by defining how the attack would look like. Signature files include key strings such as ../.. , commands like cmd.exe, or even text such as "login failed".
The IDS follows some basic steps:
1) The logs or packets are captured
2) The logs and packets are normalized if they use a different format that the IDS can't detect.
3) The captured are then are compared byte by byte against every attack signature that you have loaded with your IDS.
4) The action you specify is then taken.
Many of the modern IDSs in the market today use signature based detection, and they are sometimes used in conjunction with protocol based analysis. Protocol based analysis analyzes network packets and detects ones that violate the standards(code red is easily detected by them). In Snort signature files are called rule files, other IDSs use different name, for example SHADOW uses the name filters.
1) They are fast.
If implemented correctly, they are able to detect intrusions faster than any other analyzing method.
2) Highly customizable
With some IDSs you will be able to make your own rules and delete the owns you do not know.
3) The signature files are released often
Again this is dependent on your IDS provider. With Snort the signature files are released within a day or even hours after the attack goes into the wild.
1) False positives
Signature files tend to be general about the attack, this is due to the fact that if an attacker could change some option or a variant of the attack attacks your network then the signature files will not match and the IDS will not detect it. So using general signature files will detect those attacks but will produce higher false positives(discussed later).
2) False negatives
If an attack has no written signature for your IDS and you did not bother to make one then you have two options. 1) Forget about it and follow the method of "Security by obscurity." or 2) Make an IDS signature for your IDS your self(difficult in some products). The signature based IDS could also be evaded by skillful attackers(discussed later).
3) Do not make sense of encrypted packets
4) Needs updating
If you do not constantly update your signature files then variations or new attacks will not be detected by your IDS.
5) Prone to Denial of Service attacks (discussed later in this paper).
18 Anomaly based detection
Anomaly based detect is different in that it determines what is normal system activity and what is not, by learning it. Although this technology is in its infancy and has not left the research labs, they are still a valid topic to talk about. Commonly referred as AI(Artificial Intelligence) they work not by analyzing network traffic, but rather by defining what is authorized and unauthorized network or host behavior. This is determined during its training phase. The training phase is the time the IDS need to configured to detect normal traffic from abnormal traffic could take weeks if not months, and it usually needs heavy administration. This type of detection is also called behavior, abnormality, or statistical IDS. To get a better picture on how they work i will give you an example:
If Kevin logs in to his computer Monday through Friday from 8:00 A.M. to 3:30 P.M. to the companies FTP server and then one day he logs in on Saturday at 3:00 A.M. then you will know that there is something is heuristic(not normal) and the Anomaly detection should detect it.
Although there are no products that use Anomaly based detection solely there are some IDS that use them, some of the best examples is SHADOW which is open sources and could be found at www.nswc.navy.mil/ISSEC/CID , other product that use this technology are Snort and ISS Real Secure.
1) Could detect never before seen attacks
Because they are based on what is normal behavior and what is not, almost all attacks are heuristic by nature.
2) Difficult to evade
Because they do not use signatures they are difficult to evade.
3) Active research area
1) False Positives
Because of the unpredictable nature of your networks and employee's action (maybe Kevin did log on to that FTP server, and not some other guy across the world).
2) False Negatives
Anomaly based detection assumes that every attack starts with scanning, this is not true because an attack could just try the most resent exploit on you and if he is lucky he will be successful, because of that they tends to miss most OS exploits, buffer overflows, and P2P attacks.
3) Hard to configure
Configuring what is normal and what is not requires great knowledge about your network. It is also possible that if you miss-configure your IDS it would result in a great amount of false positives and false negatives.
1.9 Other methods of detection
Other methods of detection that IDs use that are not heavily mentioned in this paper include:
1) Protocol based Anomaly IDS
This method of detection looks for any abnormality in the way the packet was assembled or delivered. They would also watch for packets that do not follow their standards.
2) Audit trails
This method of detection analyzes the system log files for signs of intrusions. It is mostly used on HIDS.
3) Target based
IDSs that use target based detection usually detect intrusions or changes to files. This is done by doing a hash of the files periodically, and checking them to the previous results.
1.10 False Positives
One of the many problems with IDS is that they are prone to many false positives, as a matter of fact almost 90% of all alerts are false positives. False positives is best described as Stefan Axelsson said: "If you call everything with a large red nose a clown, you'll spot all the clowns, but also Santa's reindeer, Rudolph, and Vice versa." This is a great example of what are false positives. They are alerts and logs that classify authorized strange behavior as an attack while in fact it is not.
The reason why false positives are problematic is that they waste precious time and resources. They are administrative intensive and will not affect your network. But because every alert needs to be analyzed this could require many people to do, and these people might miss the real attack.
There are many reasons that cause false positives:
1) Poorly written attack signatures.
Because attack signatures are often written general enough to detect variants of the attack, they also produce a higher false positive rate. As an example, say there is a signature files that detects when a cmd.exe is passed your web server, this would catch many attacks against your web server. But what if a user (Kevin) has a password of cmd.exe, every time Kevin will log in the IDS will generate a false positive.
2) Poorly Configure IDS
Tuning your IDS to work with your network is your best choice against false positives, remember that it might take you weeks if not months just to fine tune your IDS. A couple of guidelines include:
1) Do not put attack signatures that you will not need. Not only that is process intensive, but it is also wastefully. If you do not have an FTP server why would you be afraid of it being attacked, and why would you need the FTP attack signatures?
2) Do not detect hosts that you do not have on your network. If you have 100 computers on your network, then you would only need to monitor those 100 systems, and not the whole subnet.
3) Remove attack signatures that produce too many false positives. Not all attack signatures are created equal, so if you find an attack signature that produces too much false positives, they you could rewrite the attack signature, or just delete it.
1.11 False negatives
False negatives on the other hand are when an IDS does not detect a real attack, and they cause more havoc than false positives. They are usually cause by new exploits(0-day), variants of known attacks, or an none-updated IDS signature file. To defeat them make sure that you secure your network, and also keep your signature files up-to-date.
Sniffing, which is also called eavesdropping or wiretapping, is similar to the wiretaps that the FBI installs on suspected criminals. It is used by the NIDS to capture all the traffic on your network. They serve two functions:
1) For you:
Used by the NIDS as there source of analysis, without them the NIDS will have nothing to analyze.
2) Against you:
If an attacker installs a sniffer on your network he would be able to see the contents of every packet that is there, and make sense of the unencrypted ones. So he might be able to pickup some passwords that are used in FTP and telnet sessions(that are sent in clear text).
Some of the best sniffers around include TCPDump, Etheral, Snoop, Sniffit, Snort , DSniff, and Ethrape. As you could see there are many sniffers out there, but the best ones have to be TCPDump, Etherreal, DSniff, and Snort.
How sniffers work in a paragraph:
They work by putting your network interface card into promiscuous mode. While normally the NIC card would only accept packets that are sent to its MAC address. In promiscuous mode the NIC will accept all the network packets on the wire. One thing to keep in mind however is that not all NIC cards could go in promiscuous mode.
1.13 IDS placement debate
This is a debatable question, that depends on what is your threat and what is your network like, something I do not know and obviously can not decide for you. Putting your IDS inside or outside of your firewall.
Placing your IDS inside your firewall would make your IDS not being ale to detect attacks on your firewall something that sometimes defeats the purpose of the IDS in the first place. But it will detect attacks from the inside of your network.
Placing your IDS on the outside of your firewall, will make your IDS detect all the attacks targeting your network from the inside, but will not make your IDS detect attacks from the inside of the network. This would also produce higher false positives.
The best option in my opinion is to place your IDS inside an outside your firewall, that way your will get the best of the two. The only disadvantage is that this will you analyze two logs instead of just one.
The best discussion (in my view) on this topic is in the Snort FAQ, here is the section for the Snort FAQ (www.snort.org/docs):
2.5 Where's a good place to physically put a Snort sensor?
This is going to be heavily influenced by your organizations policy, and what you want to detect. One way of looking at it is determining if you want to place it inside or outside your firewall. Placing an IDS outside of your
firewall will allow you monitor all attacks directed at your network,
regardless of whether or not they are stopped at the firewall. This almost certainly means that the IDS will pick up on more events than an IDS inside the firewall, and hence more logs will be generated. Place an IDS inside your firewall if you are only interested in monitoring traffic that your firewall let pass. If resources permit, it may be best to place one IDS outside and one IDS inside of your firewall. This way you can watch for everything directed at your network, and anything that made it's way in.
ADDENDA AD NAUSEUM
Note: So this one still gets a lot of traffic even though it's in the FAQ. Erek Adams has noted this comprehensive and authoritative discussion of this perpetual discussion item - mildly edited, also see faq question about switches hubs and taps -dr
If your router/switch can do port mirroring then just connecting a network IDS to it would be fine. Else a hub could be another option. Most of network IDS can have a NIC that acts as a passive sniffer anyway.
As to where to place the sensor. I would go for both, one to monitor the
external, one for the internal. I work in a distributor for security products, so over instrumentation is fun And in any case, if the traffic do not pass by the Sensor it will not get monitored. So some people deploy IDS on their internal segments too I believe.
In ``front'' of the firewall(s):
Pro: Higher state of alert you know what attacks you are facing.
Con: Wall to Wall of data, boring? If your firewall has NAT turned on, tracking the sources originating from your internal network is difficult.
``Behind'' the firewall(s):
Pro: Only what gets through the firewall gets monitored? Less load on the IDS analyst. You get to see what hosts are sending traffic to the internet.
Con: Less idea of the state of the environment, false sense of safety.
Where should IDS be placed relative to firewalls? Explore the pros and cons off placing IDS inside or outside firewall. What are the drawbacks of each?
* MARCUS RANUM from NFR Security: "I'd put mine inside. Why should I care if someone is attacking the outside of my firewall? I care only if they succeed, which my IDS on the inside would ideally detect. Placing the IDS on the outside is going to quickly lull the administrator into complacency. I used to have a highly instrumented firewall that alerted me whenever someone attacked it. Two weeks later I was deleting its alert messages without reading them. Another important factor arguing for putting it inside is that not all intrusions come from the outside or the firewall. An IDS on the inside might detect new network links appearing, or attackers that got in via another avenue such as a dial-in bank.''
* CURRY from IBM: ``The IDS should be placed where it will be able to see as much of the network traffic you're concerned about as possible. For example, if you're concerned about attacks from the Internet, it makes the most sense to put the IDS outside the firewall. the most sense to put the IDS outside the firewall. This gives it an "unobstructed" view of everything that's coming in. If you put the IDS inside the firewall, then you're not seeing all the traffic the bad guys are sending at you, and this may impact your ability to detect intrusions.''
* SUTTERFIELD from Wheel Group: ``IDS ideally plays an important role both inside and outside a firewall. Outside a firewall, IDS watches legitimate traffic going to public machines such as e-mail and Web servers. More importantly IDS outside a firewall will see traffic that would typically be blocked by a firewall and would remain undetected by an internal system. This is especially important in detecting network sweeping which can be a first indication of attack. External systems will also give you the benefit of monitoring those services that firewalls determine are legitimate. Putting an IDS inside the firewall offers the added benefit of being able to watch traffic internal to the protected network. This adds an important element of protection against insider threats. The major drawback of IDS inside a firewall is that it cannot see a good deal of important traffic coming from untrusted networks and may fail to alert on obvious signals of an impending attack.''
* CHRIS KLAUS from ISS: ``Outside the firewall is almost always a good idea-it protects the DMZ devices from attack and dedicates an additionalprocessor to protecting the internal network. Just inside the firewall is also useful-it detects attempts to exploit the tunnels that exist through the firewall and provides an excellent source of data for how well your firewall is working. Throughout your intranet may be the best place for IDS deployment, however. Everyone agrees that attacks aren't the only things we're worried about-there's internal mischief, fraud, espionage, theft, and general network misuse. Intrusion detection systems are just as effective inside the network as outside, especially if they're unobtrusive and easy to deploy.''
* GENE SPAFFORD: ``The IDS must be inside any firewalls to be able to detect insider abuse and certain kinds of attacks through the firewall. IDS outside the firewall may be useful if you want to monitor attacks on the firewall, and to sample traffic that the firewall doesn't let through However, a true IDS system is likely to be wasted there unless you have some follow-through on what you see.''
* Bottom Line:
DRAGOS RUIU: ``just pick a spot you're likely to look at the logs for :-)''
You have heard the experts and now you should decide what is best for your network..
In the next section we will be talking about Snort as the IDS of choice, see you then.
In part I you learned what are ID system, the different types, and different methods of detecting intrusions. In this part we will be mainly focusing on Snort, one of the leading ID system, that is both effective and open source.
2.1 What is Snort?
Snort is a network IDS that was developed by Marty Rosech in 1998, since then it has gained tremendous popularity (more than half a million Snort sensors are deployed world wide). Its popularity is due to several reasons, mainly because it is licensed under the GPL, it is a robust sniffer, and it could function as a sniffer, packet logger, or IDS. These are mainly the reasons why most security professionals prefer it over other commercial ID systems. The README included in the Snort package has this to say:
Snort is an open source network intrusion detection system, capable of performing real-time traffic analysis and packet logging on IP networks. It can perform protocol analysis and content searching/matching in order 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 uses a flexible rules language to describe traffic that it should collect or pass, as well as a detection engine that utilizes a modular plugin architecture. Snort has a real- time alerting capability as well, incorporating alerting mechanisms for syslog, user specified files, a UNIX socket, or WinPopup messages to Windows clients using Samba's smbclient.
Snort has three primary functional modes. It can be used as a straight packet sniffer like tcpdump(1), a packet logger (useful for network traffic debugging, etc), or as a full blown network intrusion detection system.
Snort logs packets to many formats, including tcpdump(1) binary format or Snort's decoded ASCII format to a hierarcical set of directories that are named based on the IP address of the remote host.
Plugins allow the detection and reporting subsystems to be extended. Available plugins include database or XML logging, small fragment detection, portscan detection, and HTTP URI normalization, IP defragmentation, TCP stream reassembly and statistical anomaly detection.
2.2 Why Snort
This question I had to ask, I really do not remember why i picked Snort to be my IDS of choice when i was starting out with IDS, but one thing is for certain there are many reasons you would pick Snort over other ID systems. So I asked Sieve (a developer for the PHLAK Linux distribution) why he picked Snort over other commercial ID systems, here is his answer:
"Snort is versatile, can be used as an IDS, IPS (intrusion prevention system), scrubber, Inline firewall, etc... It has a huge user-base that updates signatures all the time, It is open source so if you ever need to edit the code for a specific reason the code is available, and it is free. What is there not to like."
There are other reasons why you would choose Snort over other ID systems, some include:
1) Snort is passive, which leads it to monitor any system on your network with no configuration to the target computer.
2) Portable and Fast
3) Snort is able to log to numerous databases include Oracle, Microsoft SQL Server, MySQL, and PostGre SQL
4) Flexible and simple, Snort uses plugins for all of its functions so you could drop plugins and remove then as you wish.
5) Snort rule file (signatures) are easy to write and are effective
6) Snort is ported to every major operating system
2.3 History of Snort
Since its first release to the public in 1998 by Marty Rosech, Snort has saw tremendous growth. It has become probably the best and most preferred IDS in the industry today. A couple of facts support that: A) At 2003 500,000 networks had Snort sensors. B) In November of 2003, the website reported that 70,000 people downloaded Snort.
Snort does not demand much to run as a matter a fact it could run on any major OS you could think of. Lets take a moment and see which OSes does Snort support:
Although Snort supports all of these OSes, it usually runs best under the OpenBSD, FreeBSD, and Linux systems. Snort also works on many CPU architectures:
One thing to keep in mind is that although Snort works on windows, it is still not the perfect choice. Snort also requires the Libpacap (Winpacap on windows) to be installed (available at www.tcpdump.com). Libpcap takes the packets off the wire and feeds them to Snort. Libpacap is also the reason why Snort is able to work on all these OSes.
As for hardware requirements, this will depend on the network you need to monitor. If your network is small with about 3 PCs, a Pentium II 300MHZ will work fine, the opposite will go if your network is large. As a rule of thumb you need to follow the Snort FAQ's advice:
MIPS (Fast CPU)
RAM (More is *always* better)
I/O (Wide, fast buses and high performance NIC)
AODS (Acres Of Disk Space)
2.5 Installing Snort
Snort is installed simply by compiling it, although there are precompiled binaries, i still prefer to compile it. Just follow these steps:
1) Download the most recent Snort tarball from www.snort.org
2) tar -xvzf snort-version.tgz where the version is the version number you downloaded.
3) Go to the directory where you extracted Snort cd snort-version
7) make install
8) mkdir /var/log/snort
9) mkdir /etc/snort
10) cp rules/* /etc/snort/
11) cd /etc
12) vi snort.conf
13) edit the text after the var RULE_PATH so you will see var RULE_PATH /etc/snort/
14) snort -devc snort.conf
15) Monitor the logs
2.6 Running Snort
Snort is run through the command line, and has very few commands. Some of the most important are described here. From the ERADME file:
snort -[options] <filters>
-b Log packets in tcpdump format. All packets are logged
in their native binary state to a tcpdump formatted
log file called "snort.log". This option results in
much faster operation of the program since it doesn't
have to spend time in the packet binary->text
converters. Snort can keep up pretty well with 100Mbps
networks in "-b" mode.
-c <cf> Use configuration file <cf>. This is the rules file
which tells the system what to log, alert on, or pass!
-C Dump the ASCII characters in packet payloads only, no
-d Dump the application layer data
-D Run Snort in daemon mode. Alerts are sent to
/var/log/snort/alert unless otherwise specified.
-g <gname> Run Snort as group ID <gname> after initialization.
This switch allows Snort to drop root priveleges after
it's initialization phase has completed as a security
-i <if> Sniff on network interface <if>.
-l <ld> Log packets to directory <ld>. Sets up a hierarchical
directory structure with the log directory as the base
starting directory, and the IP address of the remote
peer generating traffic as the directory which packets
packets from that adress are stored in. If you do not
use the -l switch, the default logging directory is
-p Turn off promiscuous mode sniffing. Useful for places
where that can screw up your host severely.
-P <snaplen> Set the snaplen of Snort to <snaplen>. This filters how much of each packet gets into Snort, the default is the MTU for the interface that Snort is currently listening on.
-q Quiet. Don't show banner and status report.
-T Snort will start up in self-test mode, checking all the supplied
command line switches and rules files that are handed to it and
indicating that everything is ready to proceed. This is a good
switch to use if daemon mode is going to be used, it verifies that
the Snort configuration that is about to be used is valid and
won't fail at run time.
-v Be verbose. Prints packets out to the console. There
is one big problem with verbose mode: it's still kind
of slow. If you are doing IDS work with Snort, don't
use the -v switch, you WILL drop packets (not many, but
-? Show the usage summary and exit.
2.7 Snort modes
Snort runs in three different mode, as described in the README file:
Snort has three primary run-time modes: sniffer, packet logger, and networkintrusion detection.
Sniffer Mode: When in this mode, Snort reads and decodes all packets fromthe network and dumps them to the stdout. To put Snort into straight sniffing mode, use the "-v" verbose switch. This will dump the packet headers only.
You can see the headers + the packet payloads by specifying the "-v" and "-d" switch. To print a dump of the raw bytes in the entire packet, specify the "-X" switch. If you specify the "-X" switch, the -d switch is overridden. You can filter the traffic that shows up in this mode by using BPF filters.
Packet Logger Mode: This mode logs the packets to the disk in their decoded ASCII format. This mode is activated merely by specifying a directory to log packets to with the "-l" switch. This will log packets into the specified logging directory in a heirarchy of directories based upon the IP addresses of the packets on the wire. To log the packets in terms of the network being monitored (i.e. the directories created under the logging directory are the IP addresses of the remote/non-home hosts) use the "-h" switch. To log the packets in their raw binary format to the disk, use the "-b" switch. Logging the packets in this format will allow them to be run through other tools like Ethereal, tcpdump, etc. Packet logger mode can be mixed with sniffer mode switches with no ill effects, however logging performance may be impacted by the slowness of the terminal.
Intrusion Detection Mode: Snort enters IDS mode when a configuration file is specified with the "-c" switch. Output formats, rules, preprocessor
configuration, etc are all specified in the configuration file. Logger mode
is essentially disabled when in IDS mode, but that's ok because you specify which packets you want to log when in IDS mode. See the rule document (above) for how to write your own rules. When an alert rule goes off the alert data is logged to the alerting mechanism (be default a file called "alert" in the logging directory) in addition to being logged to the logging mechanism. The default logging directory is /var/log/snort, which can be changed using the "-l" switch.
2.8 Snort internal components
Snort follows a simple way of detecting intrusions and so do most ID systems.
The Libpcap was originally written for a program called TCPDump. It captures layer 2 packets and then passes them to Snort for analysis. Because the libpcap library is portable, so is Snort.
2.8.2 Packet decoder
Snort's packet decoder acts like a translator to the many technologies that are out there. It is a series of decoders that normalize the packet format so it could be sent to the detection engine.
The Preprocessor is the last place the packet will go to before going through the detection engine. They consist of plugins that function in a variety of ways from HTTPURL string normalization to assembling fragmented packets. Lets look at some of the more popular preprocessors in use:
1) Frag2: Assembles fragmented packets before sending them to the detection engine. It is also used to block evasion techniques discussed in section 3.
2) Stream4: Used to keep the state of the packets, so portscanning such as NMap's SYN scans will be detected, it will also block IDS DoS tools such as Snot and Stick.
3) HTTP_Decode: because of HTTP's wide use, rarely do you see a server that would just accept those rules, for example IIS will accept unicode, it is up to the HTTP_Decode to normalize those requests so no false negatives will occur.
4) Portscan2: Detects portscans.
2.8.4 Detection engine:
The detection engine is where every packet is examined bit by bit against every attack signature. If the packet fails all the tests then the packet is dropped. On the other hand if the packet matches an attack it is passed to alerting or logging components.
2.8.5 Alerting and logging engine
After Snort detects an intrusion it passes the packet to the alerting and logging engine. The ouput of the log is defined in the configuration files of snort, and you are able to log in a TCPDump format, to Barnyard, to a database, etc... There is a difference bettween Snort's logging and alerting, as the FAQ says:
4.19 What is the difference between ``Alerting'' and ``Logging''?
There are two primary output facilities in Snort, logging and alerting. The alerting facility exists to let you know that something interesting has happened. The logging facility exists to log full packet information to the output format (pcap, ascii, database, etc).
The "alert" action in Snort is hard coded to do two things when an event is detected by Snort, write an event to the alert facility and log as much as
possible/desired to the output facility. The "log" action merely logs the current packet to the logging facility without generating an alert. This is done so you can log interesting things (telnet sessions, whatever) without having to generate an alert on every packet.
The database plugin is something of an anomaly because it doesn't separate the two functionalities very much. The "log" option attaches the log facility and the "alert" option attaches it to the alert facility. What this means in practical terms is that if the db plugin is in alert mode, it will only receive output from alert rules, whereas if it's in "log" mode it will receive output from both log and alert rules.
2.9 What are the Rules?
Rule files are the attack signatures that the detection engine use to spot detections. They are written in a language that is easy to write yet robust. Each rule is written on one line, and contains two parts:
1) Rule header:
Generate the alert you wanted it to make, and then logs the packet.
The protocol could be UDP or TCP.
Originating IPs are the addresses from which the IPs need to originate. You could have this option setup something like this: 192.168.2.1/24 which will cause it to only log traffic if the rule is triggered from the 192.168.2.x subnet.
Originating port is set to any. any means all.
Destination IP addresses, in this case it is set to all HTTP servers.
2) Rule options
msg:"WEB-ATTACKS /etc/shadow access"
Displays this message in the logfile, so you would know what the log means at first glance.
Applies the rule to a direction of traffic flow. In this case it will apply the rule only if the packet is flowing to the server. The stream4 preprocessor keeps track of the flow of traffic and its connection state.
The detection engine uses the content field to try and match the attack to the signature. For this example the packet must contain the /etc/shadow for an intrusion to be detected.
Disregards case sensitivity, so if an attacker passes the /eTc/ShADOW string it will still be detected.
Snort rule unique identifier. It is also the number that will give you more information on the specific rule and attack.
Version number for the rule.
To learn more about what this text is and how to write your own please go to:
2.10 A look at snort.conf
snort.conf is the main configuration file of snort. No fancy GUI and all needs to edited manually. Luckily it is very easy to configure your snort.conf because it is heavily commented and there are just a couple of options you need to worry about. A snort.conf file will look something like this (note: this is not the full configuration file just part of it):
# http://www.snort.org Snort 2.1.0 Ruleset
# Contact: firstname.lastname@example.org
# $Id: snort.conf,v 1.133 2003/12/18 17:05:07 cazz Exp $
# This file contains a sample snort configuration.
# You can take the following steps to create your own custom configuration:
# 1) Set the network variables for your network
# 2) Configure preprocessors
# 3) Configure output plugins
# 4) Customize your rule set
# Step #1: Set the network variables:
# You must change the following variables to reflect your local network. The
# variable is currently setup for an RFC 1918 address space.
# You can specify it explicitly as:
# var HOME_NET 10.1.1.0/24
# or use global variable $<interfacename>_ADDRESS which will be always
# initialized to IP address and netmask of the network interface which you run
# snort at. Under Windows, this must be specified as
# $(<interfacename>_ADDRESS), such as:
var HOME_NET $eth0_ADDRESS
# You can specify lists of IP addresses for HOME_NET
# by separating the IPs with commas like this:
# var HOME_NET [10.1.1.0/24,192.168.1.0/24]
# MAKE SURE YOU DON'T PLACE ANY SPACES IN YOUR LIST!
# or you can specify the variable to be any IP address
# like this:
#var HOME_NET any
There are tools that offer GUI configuration for Snort, one that i found to be good was IDS center available from: http://www.engagesecurity.com/products/idscenter/ one thing to keep in mind however is that IDS center is currently only available for Windows.
2.11 Tools to look at
There are many tools for Snort, ones that I found interesting were:
1) Analysis Console for Intrusion Databases
"The Analysis Console for Intrusion Databases (ACID) is a PHP- based analysis engine to search and process a database of security events generated by various IDSes, firewalls, and network monitoring tools."
2) Eagle X
"A free 99% pre-configured IDS for Windows using Snort and IDScenter, Apache, PHP (ACID) and MySQL."
3) Inline Snort
"GIDS (Gateway IDS) mode for snort."
4) Oink Master
"Oinkmaster is simple but useful Perl script released under the BSD license to help you update/manage your Snort rules and disable/enable/modify certain rules after each update (among other things). It will tell you exactly what had changed since the last update, so you'll have total control of your rules. "
"fast output system for snort."
6) More contributed tools and plugins
In part II you saw some of the basics of Snort, what it offers, and why do people prefer it. In this part we are going to talk about some of the challenges of IDS especially NIDS. Techniques described here are general, and most ID systems should have found ways to stop them.
3.1 Architectural problems with NIDS
Many problems face IDS, and were mostly discussed in the disadvantages of NIDS in part I. We will be focusing some more on these ways, and discuss ways to fix the problems.
Switches work by making each port act as its own network segment, so if you send something to PC1 it is not going to send to PC2. This is much different and effective than the hubs, that is why switches are sometimes called intelligent hubs. This is a problem for NIDS that rely on sniffing the network, the reason is that if you put the sniffer on a port on the switch it will only see packets sent to it, and nothing else. There are two main ways to go around this problem:
1) Using spanning ports
Some of the high end switches currently have SPAN ports on them. Span ports are port that are a mirror of the traffic passed through the switch. As you see in the following exhibit:
2) Installing Taps or Hubs
Similar to the concept of telephone taping implemented by the FBI, taps take all the traffic from the wire before it even goes to the switch. Hubs could be used as taps, as in the following network:
Both solutions have disadvantages. For example using span ports degrades your switch's performance dramatically, and getting the switches could be costly. Hubs on the other hand are half duplex so implementing a hub as you tap will slice your network performance by 50%.
3.1.2 Fast Ethernet
Gigabyte and 10 Gigabyte Ethernet are not a dream now, and many people are starting to use them. Because of the NIDS architecture, and the way it has to pickup each packet and analyze it, Gigabyte or 10 Gigabyte networks could be nearly impossible to Handel by an out of the box IDS. The only way for the NIDS to function at such high speeds is by tweaking it to your network's need, and follow the steps outlined in the reduce false positives section. One thing to note is that a properly configured Snort IDS will be able to Handel 1 Gigabyte Ethernet almost no problems.
Since NIDS function at such a low layer (network) they have no means of decrypting or understanding encrypted packets. Therefor encrypted attacks are never detected by the IDS. The best way to combat this is by installing a HIDS on important machines that are commonly attacked such as web servers, or by installing the encryption keys on the NIDS itself so for every encrypted packet it would decrypt it and then check for a signature match.
3.2 Evading the IDS
Evasion is a technique that eludes the IDS from detecting a real attack, and thus rendering a false negative, thus defeating the purpose of implementing an IDS in the first place. Evasion techniques work by making the packet appear not to match an attack signature (while in fact it is the attack), and thus fooling your IDS. Although there are some evasions that work against HIDS we will be mostly focusing on NIDS since they are more popular. Some of the techniques that are described here have been presented in a paper called "A look at whisker's anti-IDS tactics" written by Rain Forrest Puppy(RFP) which is available at his website at www.wiretrip.net/rfp. The techniques are also implemented by a CGI vulnerability scanner program by RFP called whisker (discussed later). Although we are not going to talk about how to use the tools, I would heavily recommend that you test them against your IDS, if your IDS is deceived then it might be time to update or switch to another IDS since these tools have been around a while. We are also not going to discuss each and every commands, but rather some of the common and effective ones.
Throughout the examples we will be showing you multiple ways that an attacker could evade the following rule (signature):
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-ATTACKS /etc/shadow access"; flow:to_server,established; content:"/etc/shadow"; nocase; sid:1372; classtype:web-application-activity; rev:4
Which basically says to alert when a request for the /etc/shadow file comes from an external network to the web server on http ports. The reason we chose this rule is because not only it is simple but also is a common file that an attacker will go after.
3.3 Evasion through URL
We have all heard about the traversal attack against IIS, these are common attacks against unpached web servers. These evasion are problematic to NIDS in particular because NIDS operate at the network layer and does not make much sense of the application layer or how the target machine will interpret the attack. If you do not understand how HTTP requests work, here is an overview from "A look at whisker's anti-IDS tactics" by RFP (www.wiretrip.net/rfp):
It is important to understand the components of an HTTP request. As defined by RFC 1945:
1. The method of request; typically GET, HEAD, POST, etc. Indicates what data format the server should expect and provide.
2. The URI, which is otherwise the page you are requesting. It can be relative ('/some/file') or absolute ('http://server/some/file'). Sometimes referred to as URL, but URL typically denotes an absolute URI (includes scheme--ftp:, http:--as well as server name).
3. The version, which is always in the format of "HTTP/x.x". Common versions are 0.9, 1.0, and 1.1. v0.9 is otherwise known as "simple requests".
4. All three components make up a 'request'. Each component is separated by a space.
Most IDS vendors currently are not fooled by these kinds of evasions, Snort for example has a preprocessor called HTTP_decode to deal with these kinds of evasions.
3.3.1 Self referenced directory
This technique is quite simple, in its simplest form it would look something like this:
GET ./././etc/./././shadow HTTP/1.0
Because the signature will not match the attack GET /etc/shadow HTTP/1.0 the attack will pass undetected by the IDS.
3.3.2 Reverse transversal
By using the same idea as the transversal attack. Attacker found out that by going into a directory and getting back out they would be able to evade the IDS. The attack evasion would look something like this:
GET /etc/kevin/../john/../shadow HTTP/1.0
The directory could be anything, even none existing directories will work. Keep in mind that this could go on just going into a directory and out forever.
3.3.3 Long URL
Most ID systems have some sort of a maximum limit that a packet could be kept in memory, when that quota goes beyond the limit then the packet is discarded. Long URL functions by making the attack go beyond that maximum limit. For the sake of brevity i will not put an entire evasion but rather a stopped down version on what it would look like:
GET /etc/wade/../museum/../walkingetc.../shadow HTTP/1.0
This attack would be as long as the attacker wants it to be, but usually they will send the attack long enough to evade most ID systems.
3.3.4 Double slashes
Since it is introduction HTTP has undergone many changes, and by far has become on the most popular protocols in use. Because of this popularity, many diversities have occurred. Web server take input that were never defined by any standard. This popes a great challenge for IDS as they will not know if a packet is an attack or just a user not knowing what he is doing. One of the many inputs that web servers accept is double slashes in place of a single slash. So although // would look different from / , they will be both interpreted the same way by the web server.
GET //etc//shadow HTTP/1.0
Triple slashes could also be used
GET ///etc///shadow HTTP/1.0
3.3.5 Extra spaces
Putting an extra space between parameters sometimes would fool the IDS
GET /etc/wade/../themusium/../walkingonthestreetwhenimetyou/../shadow HTTP/1.0
Note: There are two spaces between GET and /etc/shadow
Just like IDS are sometimes fooled by extra spaces. They are also sometimes evaded by using tabs instead of spaces.
GET /etc//shadow HTTP/1.0
Note: There is a tab between GET and /etc/shadow
3.3.7 \ (Backward slashes)
*nix bases OS use forward slashes(/) when representing directories, the Internet also uses /, but Windows does not use forward slashes, instead they use backward slashes(\). Web servers such as Microsoft IIS Server will accept backward slashes instead for forward ones.
GET \etc\shadow HTTP/1.0
3.3.8 Case sensitivity
Web servers interpret both the words WiLL, WIll, and will the same, while ID systems sometimes do not. You might be able to evade the IDS using this method.
GET /ETc/shADOw HTTP/1.0
3.3.9 URL encoding
Many people from around the world use the Internet, and most of them do not speak English. The web offerers such language to coexist on the Internet by using a universal language such as Unicode. Attackers found that by changing some of the letters or numbers of the attack to there equivalence of ASCII or Unicode they could successfully evade the IDS.
GET %2f%65%74%63%2f%76%68%61%64%6f%77 HTTP/1.0
This attack is the same attack as GET /etc/shadow HTTP/1.0 in ASCII format. And since there are multiple ways to encode each letter (usually 4 or more) an attack would be able to find at least 1000 ways to present the attack to the target system, this is not counting Unicode.
3.3.10 Other evasion techniques
There are many other evasion techniques that are not discussed in this paper, here are just some that you might find interesting for research:
2) Parameter hiding
3) Premature URL ending
4) Fake parameters
5) Null method
6) Session splicing
You could also use any of the previously discussed evasions with each other.
Whisker is one of the very few tools that use evasion techniques in there scans, lets take a moments and ask what is whisker. From the whisker README:
What is whisker?
The primary purpose of whisker is to be a URL scanner, which is used to search for known vulnerable CGIs on websites. Whisker does this by both scanning the the CGIs directly as well as crawling the website in order to determine what CGIs are already currently in use.
Whisker is officially listed as deprecated, and RFP suggests that you check out tools like Nikto (www.cirt.net/code/nikto.shtml). Other tools that actually make use of whisker is Nessus (www.nessus.org) which has an option (through the libwhisker) to try to evade the IDS in its scan by using some of the ways described before.
3.5 Denial of Service (DoS)
Denial of service attacks serve mainly focus on two weaknesses in IDS.
1) The human factor
Some tools designed specifically to DoS IDS do that by generating tremendous amounts of false positives that the administrator cannot handle. Think about getting 20K of alerts each day, you will not be able to go through each one of them and analyze them carefully. They also work by burring the real attack between those false positives and thus masquerading the real attack. The disadvantage in this method is that the attack is somewhere in the logs, but it might take some time to find it.
2) The IDS it self
DoSing the IDS it self on the other tries to take the IDS off line by flooding it with too much false positives. This would cause the IDS to run out of memory, or run out of disk space all that would ultimately lead to an IDS crash. Some also try to keep the IDS busy with too much false packets that the IDS will start dropping any new ones and thus making the attack pass by undetected.
There are two tools that currently do just that.
From the http://www.eurocompton.net/stick/projects8.html:
Stick - This is an IDS stress tool used to evaluate the bottle neck point in an IDS in an operational environment. Stick will not be released anytime soon for the exception of IDS vendors.
During testing it was discovered that ISS Real Secure v5.5 would turn itself off via error. I have sent the code to ISS (Chris Rollard) via a friend to insure that it went to a knowledgeable group in ISS. I have on my own accord contacted other vendors, some of which are not affected by this technique.
Over the last couple months I've been finishing up work on stick. I was planning to release a paper in the coming week and the tool in a month or two from now when IDS vendors have had time to make modifications to handle it.
The tool uses the Snort rule set and produces a C program via lex that when compiled will produce an IP packet capable of triggering that rule from a spoofed IP range (or all possible IP addresses) into a target IP range. A function is produced for each rule and a loop then executes these rules in a random order. The tool currently produces these at about 250 alarms per second.
A Linux based snort will hit 100% CPU and start dropping packets. The stress on recording and disk IO is another problem.
ISS Real Secure dies two seconds after the attack begins. This was tested numerous times. Other IDS and even sniffers (especially with DNS lookups) had problems of
from the Snot README:
Snot is an arbitrary packet generator, that uses snort rules files as its source of packet information. It attempts at all times to randomize information that is not contained in the rule, to hamper the generation of 'snot detection' snort rules.
It can be used as an IDS evasion tool, by using specific decoy hosts, or just something to keep your friendly IDS monitoring staff busy.
It has been tested to run on *BSD, Linux, Win2k, NT4.0 and Win98.
Snort 1.8 has stream4 tcp state code. This will defeat TCP attacks with single packets. Use UDP or ICMP rules instead for the moment
So is Snort vulnerable to these type of attacks, yes and no. From the Snort FAQ
1.9 Is snort vulnerable to IDS noise generators like "Stick" and "Snot"?
It is now possible to defeat these kinds of noise generators with the (see FAQ 3.17) preprocessor. Even without the stream4 preprocessor enabled, snort will weather the alert storm without falling over or losing a lot of alerts due to its highly optimized nature. Using tools that generate huge amounts of alerts will warn a good analyst that someone is trying to sneak by their defenses.
Although we are not going to talk about this type of evasion in this paper we will just introduce the idea. Fragmentation is when a big packet gets chopped up(fragmented) into smaller ones. Each Fragmented packet contains a sequence number to be assembled in the correct order. Fragmentation occurs naturally on every network, but sometimes they are used to hide the attack. Take this for example.
When this attack is sent the IDS will see RCAKTA which does not match the real attack ATTACK. There are some tools that automate that for you, the best and well known fragroute is one of them. Also note that in Snort the frag2 preprocessor handles fragments.
Looking at the above examples and the many ways that IDS is challenged you might have a second thought about implementing IDS on your network. If your IDS is implemented correctly you should not worry or run in any of these problems.
Apendex A: Books on IDS
Books on Snort
There are three main books on Snort in the market at the time of this writing:
Snort 2.0 Intrusion Detection
Thanks to MCSEWorld.com for providing me a copy.
Rating 9 out of 10
Intrusion Detection with Snort
Thanks to Sams for giving out a copy to my local LUG.
Rating 8 out of 10
Intrusion Detection with SNORT: Advanced IDS Techniques Using SNORT, Apache, MySQL, PHP, and ACID
Full free ebook is available at (thanks you for making it open source):
Add books on IDS
Cleanup the format of the paper
Links to good sites for IDS
great IDS papers
check the grammar
Good plugins for snort
installing ACID and Apache
Writing your own rules
A better look at snort.conf
I would like to thank you for reading this document, and would like to thank mcseworld.com, snort.org, tigershark (anitonline.com), family, snort.org, talug.org, etc...
Neet PDF is attached.
January 26th, 2004, 01:22 PM
here is also the text, so you could edit it and play with it, just remember to give credit to QoD and put the email address of my self and the date.
January 27th, 2004, 10:00 PM
I plan to use parts of your tuts in some of mine, if that's OK. Maybe you could help me co-author some if and when I get the time to undertake another project.
These IDS papers have been some mighty-fine work, Q.o.D. hope you write some more.
Parting is such sweet sorrow!
January 27th, 2004, 10:41 PM
you could use any part of it if you want, just put the name, email, and link to the article in the paper you will use it in, also your paper must also be GPL, or The GNU Free documentation licence.
and i will be happy to coauthor with your, as long as the subect interests me
glad someone like it.
February 5th, 2004, 05:17 AM
This is a very good intro to IDS. You touched on the different types of IDS's, mode of operation for them as well as how possible attacks are detected. I like how you mentioned more than once how architecture is a critcle part of deploying a working IDS. You also gave brief notes on pro's and con's of all touched points. Over all a very good, although note indepth, intro to IDS's.
Don\'t be a bitch! Use Slackware.
February 6th, 2004, 09:42 PM
i tried to make it as indepth as possible, but i could not put everything i knew into it, i simply do not have time
February 27th, 2004, 03:03 AM
i find it amazing that this tutorial was featured here
just found it today, was searching for snort news and there was link to it on the DC snort users group.