Repeat after me:
wget http://www.snort.org/downloads/snort-stable.tgz tar zxvf snort-stable.tgz cd snort-stable ./configure make su make install mkdir /var/log/snort cd etc vi snort.conf snort -D -c snort.conf exit
...and if you want to use our binary package uninstaller :-):
cd snort-stable; make uninstallAnd if you must, you can find some binaries at http://www.snort.org/dl/binaries/. You can also find Snort in most BSD ports' trees.
Run Snort in sniffer mode and make sure it can see the packets.
snort -dv{
Then run it with the HOME_NET set appropriately for the network you're defending in your rules file. A default rules file comes with the snort distribution and is called ``snort.conf'' You can run this basic ruleset with the following command line:
snort -A full -c snort.conf
If it's all set right, make sure the interface is in promiscuous mode by running the command from another window:
ifconfig -a
The output from ifconfig should show if the interface is in promiscuous mode. If it's not, there should be a way to set it manually.
Note that the default output mode (-A full) of Snort should not be used except in very controlled environments. It is the slowest way to run Snort and presents several hard to recover from problems with inode creation on filesystems.
For people doing real IDS work, use something like (-A fast -b) to combine fast alert mode with tcpdump binary log files or use the unified format coupled with barnyard.
The default location for logs is /var/log/snort. If snort is started with ``-l
directory
'', then the logs will be located in the directory specified.
In the past, running Snort in daemon mode (-D) produced a file named ``snort.alert.'' For consistency's sake, this has been changed. Running Snort in both standard or daemon modes (-D) will produce a file named ``alert.''
Note the log file naming convention changed between 1.8 and 1.9. That funny alphanumeric soup at the end of the new names is a UNIX timestamp. This helps avoid file conflicts.
It requires this directory to log alerts to it. Try running the command:
mkdir -p /var/log/snortMake sure the logging directory is owned by the user Snort is running as.
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. Or else a hub could be another option. Most network IDSes 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 does 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 of placing IDS inside or outside firewall. What are the drawbacks of each?
Bottom Line:
DRAGOS RUIU: ``Just pick a spot you're likely to look at the logs for. :-)''
You are not running Snort as root or your kernel is not configured correctly.
Check your version of libpcap. If it's not 0.5, you should update.
You can find the most current version at:
You might also want to have a look at Phil Wood's patches to libpcap for Linux:
It depends. If you only have one processor, you can use the most current
version (3.x). If you have a SMP box, you'll have to use either an older
version ( 2.3) or the 3.x version plus a patch from http://www.ntop.org/winpcap.html.
You must configure libpcap with the -install-incl option. (On Red Hat, install the libpcap-devel rpm.)
You need the lex and yacc tools or their gnu equivalents flex and bison installed.
That depends. Lower the number of rules is a standard performance increase. Disable rules that you don't need or care about. There have been many discussions on 'tweaking performance' with lots of 'I handle XX mb with a ___ machine setup.' being said. Look at some of the discussions on the snort-users mailing lists.
Here is an oft quoted bit on the subject from Marty:
``Hardware/OS recommendations''
Ok, here are the guidelines and some parameters. Intrusion detection is turning into one of the most high performance production computing fields that is in wide deployment today. If you think about the requirements of a NIDS sensor and the constraints that they are required to operate within, you'll probably start to realize that it's not too hard to find the performance wall with a NIDS these days.
The things a NIDS needs are:
A NIDS also needs to be pretty quick internally at doing its job. Snort's seen better days in that regard (when 1.5 came out the architecture was a lot cleaner) but it's still considered to be one of the performance leaders available.
As for OS selection, use what you like. When we implement Data Acquisition Plugin's in Snort 2.0 this may become more of a factor, but for now I'm hearing about a lot of people seeing alot of success using Snort on Solaris, Linux, *BSD and Windows 2000. Personally, I develop Snort on FreeBSD and Sourcefire uses OpenBSD for our sensor appliance OS, but I've been hearing some good things about the RedHat Turbo Packet interface (which would require mods for Snort to use, not to mention my general objection to RedHat's breaking stuff all the time). (ed note: take a drink, see FAQ 7.2 -dr)
(Excerpt from url: http://public.pacbell.net/dedicated/cidr.html)
CIDR is a new addressing scheme for the Internet which allows for more i efficient allocation of IP addresses than the old Class A, B, and C address scheme.
CIDR Block | Equivalent Class C | Addresses |
/27 | 1/8th of a Class C | 32 hosts |
/26 | 1/4th of a Class C | 64 hosts |
/25 | 1/2 of a Class C | 128 hosts |
/24 | 1 Class C | 256 hosts |
/23 | 2 Class C | 512 hosts |
/22 | 4 Class C | 1,024 hosts |
/21 | 8 Class C | 2,048 hosts |
/20 | 16 Class C | 4,096 hosts |
/19 | 32 Class C | 8,192 hosts |
/18 | 64 Class C | 16,384 hosts |
/17 | 128 Class C | 32,768 hosts |
/16 | 256 Class C | 65,536 hosts |
/15 | 512 Class C | 131,072 hosts |
/14 | 1,024 Class C | 262,144 hosts |
/13 | 2,048 Class C | 524,288 hosts |
For more detailed technical information on CIDR, check out the following RFCs:
RFCs are available at http://www.rfc-editor.org/rfcsearch.html
Used in conjunction with a Snort rules file, the tcpdump data can be analyzed for hostile content, port scans, or anything else Snort can be used to detect. Snort can also display the packets in a decoded format, which many people find is easier to read than native tcpdump output.