next up previous
Next: 3 Configuring Snort Up: The Snort FAQ Previous: 1 Background

Subsections

2 Getting Started

2.1 Where do I find binary packages for BlueHat BSD-Linux-RT?

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

2.2 How do I run Snort?

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.

2.3 Where are my log files located? What are they named?

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.

2.4 Why does Snort complain about /var/log/snort?

It requires this directory to log alerts to it. Try running the command:

    mkdir -p /var/log/snort
Make sure the logging directory is owned by the user Snort is running as.

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

2.6 Libpcap complains about permissions problems, what's going on?

You are not running Snort as root or your kernel is not configured correctly.

2.7 I've got RedHat and ....

Check your version of libpcap. If it's not $>=$ 0.5, you should update.

2.8 Where do I get the latest version of libpcap?

You can find the most current version at:

http://www.tcpdump.org

You might also want to have a look at Phil Wood's patches to libpcap for Linux:

http://public.lanl.gov/cpw/

2.9 Where do I get the latest version of Winpcap?

http://winpcap.polito.it/


2.10 What version of Winpcap do I need?

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.

2.11 Why does building Snort complain about missing references?

You must configure libpcap with the -install-incl option. (On Red Hat, install the libpcap-devel rpm.)

2.12 Why does building snort fail with errors about yylex and lex_init?

You need the lex and yacc tools or their gnu equivalents flex and bison installed.

2.13 I want to build a Snort box. Will this $<$Insert list of hardware$>$ handle $<$this much$>$ traffic?

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:

  1. MIPS (Fast CPU)
  2. RAM (More is *always* better)
  3. I/O (Wide, fast busses and high performance NIC)
  4. AODS (Acres Of Disk Space)

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)

2.14 What are CIDR netmasks?

(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

2.15 What is the use of the ``-r'' switch to read tcpdump files?

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.


next up previous
Next: 3 Configuring Snort Up: The Snort FAQ Previous: 1 Background
2005-03-21