Security is critical

Suppose you've spent months -- if not years -- of your life learning the hottest Web technologies. You've read developerWorks articles, you've bought books, you've played around in your Mac OS X Terminal and on your Windows® shell. And you've managed to build a terrific Web application, with nearly 100 pages -- some static HTML and some generated with PHP scripts. You've even started to add some Ajax technologies and cool effects to make your sites more interactive and responsive. You're on top of the Web programming world.

Then, you wake up one morning, and all that's left of your site is a full-page banner ad for a site you'd rather not be associated with. On top of that, your shopping cart has slowed to a crawl because thousands of packets of useless data are slamming into your Web site, creating annoyance and outright anger in your customer base.

As dramatic as that may sound, most serious Web developers know someone personally to whom a scenario like this has happened, or it has happened to them. No matter how great your sites and applications are, if they're not secured, and they're even mildly successful, those sites are targets. Whether it's a twelve-year-old acting out, or a professional hacker performing corporate espionage, Web sites are more vulnerable to attackers than any other type of application. The Internet is publicly accessible by anyone with twenty dollars a month (or a little wire-splicing skill, even). Your job is to protect your sites, not just develop them.

Security isn't someone else's job

Right now, you might be shaking your head in frustration, thinking of "that guy in the office down the hall" who handles security. You might be thinking that it's that guy's job to handle security. While that may be positionally true, it's not practically true. If you don't perform at least some degree of intrusion detection -- and hopefully prevention -- you're trusting you site to... well... "that guy." And, chances are, you stand to lose a lot more if things go wrong with your site.

While not every developer can be a security expert, all developers should know enough to perform some basic network and traffic analysis and to build rudimentary security into their applications. Or, worst case, a developer should be able to communicate what's needed to a security technologist, and follow up to ensure their sites are indeed protected. Of course, because you're the developer, that makes security part of your job.

Basic security isn't difficult

While it's very daunting to master the OSI network model, learn everything about TCP/IP, and dig through packets two times a day, every day, it's not that hard to learn the basics of intrusion detection and prevention (terms I define in more detail a little later on). With this article, and a second part coming soon, you'll be a competent security manager who can speak the language of security, and find out what's going on in your application without waiting in an IS or IT queue.

So close your favorite IDE (or at least minimize it), fire up a terminal or shell, and dig into security for a few hours. You won't be sorry, and your applications -- and the customers who pay for them -- will be all the better.

Back to top

Snort: an intrusion detection tool

For most system and network administrators, Snort is a common, familiar tool. Unfortunately, the same can't be said for Web programmers. Snort -- if mentioned at all -- is lumped in with technical tools like traceroute or ipconfig, and assumed to be well out of the Web developer's domain.

Snort is a lot more than an administrator's tool, though. It's an intrusion detection system -- not just a tool. While it's primarily used from the command line, it's still very accessible to a Web programmer, as well as administrators. It's open source, which means it's free, and unlike many open source tools, it's very well maintained. There's good documentation (online as well as in books; see Resources for links), and by the time you read this article (and probably the next), you'll know as much about Snort as many network and security administrators.

So what is an intrusion detection system, anyway?

Today there are more open networks than ever before. Intranets are still common, but secured sections of an otherwise publicly accessible site is more common. For the enterprising hacker, that's a lot less work. Instead of trying to penetrate a network and find a domain or network they're completely unaware of, the hacker only has to infiltrate a portion of a network that they do know about.

Intrusion detection is recognizing an unexpected access to a network; the access could be as simple as a Web page being accessed improperly (perhaps a secured admin form or shell access to the entire root directory of a Web site). On the other hand, an intrusion can be very sophisticated, such as changing DNS tables so that requests to one site all get redirected to another, hacker-controlled domain or replacing the .htaccess file on an Apache Web server with a more permissive one, allowing a hacker to add, remove, and change user information, including passwords.

The detection part, of course, is all about recognizing -- and then preventing -- this sort of thing from happening. So when it comes to a tool or system that focuses on intrusion detection, you're talking about anything from a high-end professional firewall from Cisco to a simple Snort installation. Because not many organizations can drop tens and even hundreds of thousands of dollars into high-end hardware, an open source application like Snort is perfect for getting basic intrusion detection running with minimal expenses and hassles.

You're sure this is my problem?

It's true that both intrusion detection and Snort usage extends well beyond Web sites and into larger network security issues. As a Web developer, there's no reason to become a Snort expert, or budget 20% of your Web development time to intrusion detection. The intent of good developer-oriented intrusion detection is to get the maximum benefit with the least amount of time. The idea is to spend a little bit of time at each revision of your Web site and prevent the most common attacks on your site.

Back to top

Getting Snort

So, now do you get Snort? Begin by pointing your Web browser to the Snort Web site (see Resources). There's a large "GET SNORT" link on the left, just under the pig with the big nose. (Seriously. The logo for Snort is a ping pig with a large nose, presumably snorting.) As of this writing, the latest production-ready version is 2.8. Everything in these articles will apply to any 2.x version of Snort, though, with little to no modification.

If you're on Linux® or Windows, you can download a binary. The binaries are available by clicking the Click to view binaries >>" link just under the production file listing.

• If you're on Windows, click the binaries link, and then the win32/ link. There's an .exe file, called Snort_2_8_0_2_installer.exe, that you can click to download Snort.
• For Linux, select the binaries link, and then click linux/. You'll have a choice of several RPMs, including a few with preconfigured support for MySQL and PostreSQL. Choose the RPM you want, and you're all set.

If you want to dig a little deeper, or if you're on a non-Windows or non-Linux system (like Mac OS X, for example), you should download the GZipped TAR file from the main download link, called something similar to snort-2.8.0.2.tar.gz (the file name might be slightly different if the release version has changed since this article was written and published). This file is the source for Snort, and you can build from this source for your particular platform.

Back to top

Installing Snort from source code

There are three basic categories of installation:

• Installing from source on a UNIX®-type platform (UNIX, Linux, Mac OS X, Cygwin)
• Installing from an RPM on Linux
• Installing from a Windows .exe installer

If you're on a UNIX-type platform, you can build Snort from source code. This is the most flexible option, and ensures Snort is built just for your system. It takes a little bit more work, but isn't as complex as many source-code installations. Again, if you're a Web developer and have a little bit of command-line or terminal experience, you'll be able to handle installation without much of a problem.

Snort wants several libraries in place, particularly if you're installing from source code. So, before you deal with the Snort package itself, you should get these libraries in place.

Getting a C compiler on Mac OS X

You'll need a C compiler to install Snort from source code. Most Linux and UNIX platforms provide a C compiler called gcc, so no extra steps are required. For Mac OS X users, though, the gcc compiler doesn't get installed by default.

To get gcc for Mac OS X, visit the Apple Developer Connection (see Resources), sign in, and select Downloads. You'll see lots of categories on the right side of the page. Select Developer Tools, and then look for Xcode. Download the Xcode 2.5 disk image for Tiger or earlier versions of Mac OS X (that's 10.4.x or earlier); if you're on Leopard (10.5.x or later), select Xcode 3.0. These are big downloads, with lots more than just a C compiler, so be patient.

Finally, open the disk image and, navigate into the Installer folder. Run the installer, walk through the prompts, and you're ready to go. To confirm you've got gcc installed, just execute the command gcc:

[bdm0509:~/Desktop] gcc
powerpc-apple-darwin8-gcc-4.0.1: no input files

This is an error (you didn't give gcc anything to compile), but it indicates that your system has the compiler installed. You should get a similar response from UNIX, Linux, Solaris, or Cygwin on Windows.

Adding PCRE support

Snort requires Perl Compatible Regular Expressions, or PCRE. You can download this library for free online (see Resources) for a variety of platforms. Expand the .tar.gz file into a directory, and change to that directory:

[bdm0509:~/Desktop] tar xzf pcre-7.6.tar.gz 
[bdm0509:~/Desktop] cd pcre-7.6

Now, configure this installation with the configure script (you'll follow this same process with Snort in a moment). The results are shown in Listing 1.

                [bdm0509:~/Desktop/pcre-7.6] ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
...
Lots more output here...
...
config.status: executing script-chmod commands
config.status: executing delete-old-chartables commands

pcre-7.6 configuration summary:

    Install prefix .................. : /usr/local
    C preprocessor .................. : gcc -E
    C compiler ...................... : gcc
    C++ preprocessor ................ : g++ -E
    C++ compiler .................... : g++
    Linker .......................... : /usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld
    C preprocessor flags ............ : 
    C compiler flags ................ : -O2
    C++ compiler flags .............. : -O2
    Linker flags .................... : 
    Extra libraries ................. : 

    Build C++ library ............... : yes
    Enable UTF-8 support ............ : no
    Unicode properties .............. : no
    Newline char/sequence ........... : lf
    \R matches only ANYCRLF ......... : no
    EBCDIC coding ................... : no
    Rebuild char tables ............. : no
    Use stack recursion ............. : yes
    POSIX mem threshold ............. : 10
    Internal link size .............. : 2
    Match limit ..................... : 10000000
    Match limit recursion ........... : MATCH_LIMIT
    Build shared libs ............... : yes
    Build static libs ............... : yes
    Link pcregrep with libz ......... : no
    Link pcregrep with libbz2 ....... : no
    Link pcretest with libreadline .. : no

All that's left is to "make" the program, which builds and compiles the code, and install it into the proper places on your system. Most programs, tools, and utilities (PCRE and Snort included) let you perform both these steps with one command: make install. However, before you run this command, you should either log in as a root user or use the sudo command. Most packages like Snort and PCRE will want to write to protected directories that a typical user can't access. With a root user, or the sudo command, this isn't a problem. You should see something similar to Listing 2.

                [bdm0509:~/Desktop/pcre-7.6] sudo make install
Password:
test -z "/usr/local/lib" || ./install-sh -c -d "/usr/local/lib"
 /bin/sh ./libtool --mode=install /usr/bin/install -c  'libpcre.la' 
     '/usr/local/lib/libpcre.la'
/usr/bin/install -c &.libs/libpcre.0.0.1.dylib /usr/local/lib/libpcre.0.0.1.dylib
(cd /usr/local/lib && { ln -s -f libpcre.0.0.1.dylib libpcre.0.dylib || 
     { rm -f libpcre.0.dylib && ln -s libpcre.0.0.1.dylib libpcre.0.dylib; }; })
(cd /usr/local/lib && { ln -s -f libpcre.0.0.1.dylib libpcre.dylib || 
     { rm -f libpcre.dylib && ln -s libpcre.0.0.1.dylib libpcre.dylib; }; })
/usr/bin/install -c .libs/libpcre.lai /usr/local/lib/libpcre.la
/usr/bin/install -c .libs/libpcre.a /usr/local/lib/libpcre.a
chmod 644 /usr/local/lib/libpcre.a
ranlib /usr/local/lib/libpcre.a
----------------------------------------------------------------------
Libraries have been installed in:
   /usr/local/lib
...
Lots more output here...
...
test -z "/usr/local/include" || ./install-sh -c -d "/usr/local/include"
 /usr/bin/install -c -m 644 'pcre.h' '/usr/local/include/pcre.h'
 /usr/bin/install -c -m 644 'pcrecpparg.h' '/usr/local/include/pcrecpparg.h'
 /usr/bin/install -c -m 644 'pcre_stringpiece.h' 
     '/usr/local/include/pcre_stringpiece.h'
test -z "/usr/local/lib/pkgconfig" || ./install-sh -c -d "/usr/local/lib/pkgconfig"
 /usr/bin/install -c -m 644 'libpcre.pc' '/usr/local/lib/pkgconfig/libpcre.pc'
 /usr/bin/install -c -m 644 'libpcrecpp.pc' '/usr/local/lib/pkgconfig/libpcrecpp.pc'

With these libraries and tools in place, you're ready to move on to the core Snort configuration and installation.

Configuring Snort

After you've downloaded the .tar.gz file with the Snort source code, expand it into a directory you can easily access. You can use a command like this:

[bdm0509:~/Desktop] tar xzf snort-2.8.0.2.tar.gz

Or you can double-click on the file in Mac OS X to let your GUI unzip tool handle the expansion. You'll get a folder like snort-2.8.0.2, and the contents should look something like Listing 3.

                [bdm0509:~/Desktop/snort-2.8.0.2] ls
COPYING
ChangeLog
LICENSE
Makefile.am
Makefile.in
RELEASE.NOTES
aclocal.m4
config.guess
config.h.in
config.sub
configure
configure.in
contrib
depcomp
doc
etc
install-sh
ltmain.sh
m4
missing
mkinstalldirs
preproc_rules
rpm
schemas
snort.8
src
templates
verstuff.pl
ylwrap

Now, switch to the directory you've created. Run configure, which is a script that attempts to auto-configure the installation for you. Your output should look like Listing 4.

                [bdm0509:~/Desktop/snort-2.8.0.2] ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific 
   portions of Makefiles... no
checking for style of include used by make... GNU
checking for gcc... gcc
...
lots more output...
...
config.status: creating doc/Makefile
config.status: creating contrib/Makefile
config.status: creating schemas/Makefile
config.status: creating rpm/Makefile
config.status: creating preproc_rules/Makefile
config.status: creating m4/Makefile
config.status: creating etc/Makefile
config.status: creating templates/Makefile
config.status: creating src/win32/Makefile
config.status: creating config.h
config.status: executing depfiles commands

Install Snort on your system

After installing PCRE, you should know what's next: running make install, again either as the root user or with the sudo command. Your output should look something like Listing 5.

                [bdm0509:~/Desktop/snort-2.8.0.2] sudo make install
Password:
Making install in src
Making install in sfutil
gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../src -I../../src/sfutil 
  -I/sw/include -I../../src/output-plugins -I../../src/detection-plugins 
  -I../../src/dynamic-plugins -I../../src/preprocessors 
  -I../../src/preprocessors/flow -I../../src/preprocessors/portscan  
  -I../../src/preprocessors/flow/int-snort  -I../../src/preprocessors/HttpInspect/include 
  -I../../src/preprocessors/Stream5 -I../../src/target-based  -I/usr/local/include 
  -fno-strict-aliasing  -g -O2 -Wall -DDYNAMIC_PLUGIN -fno-strict-aliasing 
  -c sfghash.c
...
Lots more output...
...
Making install in preproc_rules
make[2]: Nothing to be done for `install-exec-am'.
make[2]: Nothing to be done for `install-data-am'.
make[2]: Nothing to be done for `install-exec-am'.
test -z "/usr/local/share/man/man8" || ./install-sh -c -d "/usr/local/share/man/man8"
 /usr/bin/install -c -m 644 './snort.8' '/usr/local/share/man/man8/snort.8'

Don't worry if you don't see lots of changes in the expanded directory you're running configure and make from. Most of the work here is done in the directories your system uses for binary files, libraries, and executables.

Back to top

Installing Snort from an RPM on Linux

RPM stands for RPM Package Manager. (Yes, the acronym is essentially recursive. Not very sensible, but very much factual.) RPMs on Linux are packages you can easily install, as RPM support is core to every Linux distribution out there. After you've downloaded an RPM from the Snort Web site, simply run the rpm command with the file name you downloaded as the argument, as shown in Listing 6.

                [bdm0509@pegasus]# rpm -ivh snort-2.8.0.2-1.RH5.i386.rpm
Preparing...     ################################################ [100%]
   1:snort       ################################################ [100%]

The ivh options stand for install, verbose, and hash, which installs the package while telling you what's going on (as well as giving you hash-mark status indicators). In this case, the installation is on Red Hat, but you'll see similar results on any Linux distribution.

As with installing Snort from source code, you will probably need to either log in as the root user to run this command or use the sudo command to install the RPM as the supervisor. Because Snort wants its binaries to live in generally protected directories like /usr/bin or /usr/local/bin, installation requires more permissions than most typical user accounts on a standard system.

Back to top

Installing Snort from a Windows binary installer

Your downloaded Windows installer will be named similar to Snort_2_8_0_2_Installer.exe. Run the installer, confirm to Windows that you trust the application, and accept the Snort license agreement.

Select the database support

Your first decision is what sort of database support you want. Figure 1 shows the screen that lets you choose between the default setup, a SQL Server-capable configuration, or an Oracle-capable configuration.

The options on this screen all apply to logging; Snort can log to databases when it sniffs packets. (If that sounded confusing, it will all make sense before you finish this article.) If you don't want to log to a database, and would prefer logging only to files, or if you want to log to a MySQL database or an ODBC-accessible database like Microsoft Access, choose the first option. Otherwise, select the option for SQL Server or Oracle.

Select the components to install

Next are the components you can have included with your installation (see Figure 2).

There are four options: Snort itself, dynamic modules, documentation, and schemas. There's no good reason not to install all of these, and at 24 MB or so for a complete installation, you should leave all of these checked and continue.

Choose your installation directory

By default, Snort wants to install in C:\Snort, as shown in Figure 3.

This default directory is a good first choice. Because Snort doesn't have lots of GUI components, it doesn't really belong in the typical Windows application-installation directory of C:\Program Files. Unless you've got a standard installation directory for programs like Snort, stick with the default here.

Install and close

Oddly, Snort doesn't give you a very helpful "I'm finished" screen right away. Instead, you just get a completed status bar with a Close button (see Figure 4).

Click Close, and then you get the expected pop-up window letting you know that Snort is (almost) ready to go (see Figure 5).

Install WinPcap

Snort tells you in no uncertain terms that there are installations left to take care of before Snort is ready to go. The first of these is WinPcap. WinPcap is short for Windows Packet Capture Library, and it provides certain types of network access that Snort needs for its IDS and packet sniffing functions. Visit the WinPcap Web site (see Resources), and select the Get WinPcap link.

Select the latest stable download; at this writing, that's 4.0.2. The download includes a Windows installer you can start by double-clicking (see Figure 6).

Installation is a couple of clicks of the Next button, and that's it. WinPcap is ready to go.

Edit paths

The next instruction is a bit of a red herring, at least as far as this article is concerned. Snort's installation suggests you edit the snort.conf file to see where to look for rules and other configuration files. While this is important, it's getting a bit ahead. For now, installation of Snort and WinPcap is enough to get you going.

However, there is one more step you should take before continuing on. You need to add to your PATH statement the Snort executable, which is located in C:\Snort\bin\snort.exe (assuming you chose the default installation directory). Getting to where you can set this is a bit operating system-dependent. You want to find the System Properties dialog (in Control Panel or accessible from Control Panel > System), select Advanced System Properties, and look for a button or tab called Environment Variables.

There will be two boxes (similar to Figure 7). You want the upper of the two, user variables, which apply to just your user. (You probably don't want everyone on your system running Snort, regardless of all the security hoops some programs make you jump through.)

Select the upper New... button, unless you've already got an entry for PATH. If you do have an entry, then select Edit... In the dialog box, enter PATH as the variable name, and C:\Snort\bin as the value. Figure 8 shows what you should have when you're done.

Select OK, and then close all your dialog boxes. Open a command prompt and type snort, and you should see output like Figure 9.

Note: This step is repeated below, in the section entitled Run the Snort binary, but it's worth getting ahead now if you're on Windows because the steps to correct any problems are all related to the environment variable setup.

Back to top

Testing your installation

There are several steps you need to take after your installation is complete to make sure Snort is running on your system and is behaving properly. All are simple, but you should perform each step every time you install a new version of Snort or install Snort on a new machine.

Run the Snort binary

The simplest test you can perform is to run the snort command. To begin, change to any random directory on your machine. And just to be safe, don't run this in your Snort installation directory, either. You should get output similar to Listing 7.

                [bdm0509:~] snort
   ,,_     -*> Snort! <*-
  o"  )~   Version 2.8.0.2 (Build 75)  
   ''''    By Martin Roesch & The Snort Team: http://www.snort.org/team.html
           (C) Copyright 1998-2007 Sourcefire Inc., et al.
           Using PCRE version: 7.6 2008-01-28

USAGE: snort [-options] <filter options>
Options:
   -A         Set alert mode: fast, full, console, test or none  (alert file alerts only)
              "unsock" enables UNIX socket logging (experimental).
   -b         Log packets in tcpdump format (much faster!)
   -B <mask>  Obfuscated IP addresses in alerts and packet dumps using CIDR mask
   -c <rules> Use Rules File <rules>
   -C         Print out payloads with character data only (no hex)
   -d         Dump the Application Layer
   -D         Run Snort in background (daemon) mode
   -e         Display the second layer header info
   -f         Turn off fflush() calls after binary log writes
   -F <bpf>   Read BPF filters from file <bpf>
   -g <gname> Run snort gid as <gname> group (or gid) after initialization
   -G <0xid>  Log Identifier (to uniquely id events for multiple snorts)
   -h <hn>    Home network = <hn>
   -H         Make hash tables deterministic.
   -i <if>    Listen on interface <if>
   -I         Add Interface name to alert output
   -k <mode>  Checksum mode (all,noip,notcp,noudp,noicmp,none)
   -K <mode>  Logging mode (pcap[default],ascii,none)
   -l <ld>    Log to directory <ld>
   -L <file>  Log to this tcpdump file
   -M         Log messages to syslog (not alerts)
   -m <umask> Set umask = <umask>
   -n <cnt>   Exit after receiving <cnt> packets
   -N         Turn off logging (alerts still work)
   -o         Change the rule testing order to Pass|Alert|Log
   -O         Obfuscate the logged IP addresses
   -p         Disable promiscuous mode sniffing
   -P <snap>  Set explicit snaplen of packet (default: 1514)
   -q         Quiet. Don't show banner and status report
   -r <tf>    Read and process tcpdump file <tf>
   -R <id>    Include 'id' in snort_intf<id>.pid file name
   -s         Log alert messages to syslog
   -S <n=v>   Set rules file variable n equal to value v
   -t <dir>   Chroots process to <dir> after initialization
   -T         Test and report on the current Snort configuration
   -u <uname> Run snort uid as <uname> user (or uid) after initialization
   -U         Use UTC for timestamps
   -v         Be verbose
   -V         Show version number
   -w         Dump 802.11 management and control frames
   -X         Dump the raw packet data starting at the link layer
   -y         Include year in timestamp in the alert and log files
   -Z <file>  Set the performonitor preprocessor file path and name
   -?         Show this information
<Filter Options> are standard BPF options, as seen in TCPDump
Longname options and their corresponding single char version
   --logid <0xid>                  Same as -G
   --perfmon-file <file>           Same as -Z
   --pid-path <path>               Specify the path for the Snort PID file
   --snaplen <snap>                Same as -P
   --help                          Same as -?
   --version                       Same as -V
   --alert-before-pass             Process alert, drop, sdrop, or reject before pass, 
                                   default is pass before alert, drop,...
   --treat-drop-as-alert           Converts drop, sdrop, and reject rules into alert 
                                   rules during startup
   --process-all-events            Process all queued events (drop, alert,...), 
                                   default stops after 1st action group
   --dynamic-engine-lib <file>     Load a dynamic detection engine
   --dynamic-engine-lib-dir <path> Load all dynamic engines from directory
   --dynamic-detection-lib <file>  Load a dynamic rules library
   --dynamic-detection-lib-dir <path> Load all dynamic rules libraries from 
                                   directory
   --dump-dynamic-rules <path>     Creates stub rule files of all loaded rules libraries
   --dynamic-preprocessor-lib <file>  Load a dynamic preprocessor library
   --dynamic-preprocessor-lib-dir <path> Load all dynamic preprocessor libraries from 
                                   directory
   --dump-dynamic-preproc-genmsg <path>  Creates gen-msg.map files of all loaded 
                                   preprocessor libraries
   --create-pidfile                Create PID file, even when not in Daemon mode
   --nolock-pidfile                Do not try to lock Snort PID file
   --disable-inline-initialization Do not perform the IPTables initialization in inline 
                                   mode.
   --loop <count>                  In combination with the -r <tf> option, 
                                   this will read the tcpdump file continuously
                                   for <count> times.  A value of 0 will read the pcap 
                                   until Snort is killed.
ERROR: 

Uh, you need to tell me to do something...

Fatal Error, Quitting..

This ends in an error, but the process does several important things:

1. It confirms that the Snort binary is installed and on your path. That just means you can run it from any directory on your machine.
2. It gives you important information about your version of Snort and its dependent libraries. Notice this output near the top of the output:

   ,,_ -*> Snort! <*- o" )~ Version 2.8.0.2 (Build 75) '''' By Martin Roesch & The Snort Team: http://www.snort.org/team.html (C) Copyright 1998-2007 Sourcefire Inc., et al. Using PCRE version: 7.6 2008-01-28

   
   This lets you easily see what version of Snort and PCRE you're running.
3. It gives you a simple rundown of the commands you can issue to Snort.

Sniff with Snort

You know that Snort is an intrusion detection system, but how does it detect intrusion? Among other things, Snort (and most other high-end IDSes) sniffs network traffic. A sniffer is a tool or device that has a network card and watches network traffic between computers. Some sniffers are "third-party," and sniff traffic between machines external to the sniffer itself. Other sniffers sniff traffic between a network and the machine the sniffer itself is on. We'll talk a lot more about sniffing in the next article, so if you're still a little unsure about sniffing, don't worry about it.

For now, though, sniffing is a simple and useful way to make sure that Snort is not only installed, but working and capable of monitoring network traffic. Run the snort command with the -v flag, which tells Snort to sniff network traffic and print out information to the console. Listing 8 shows the output from running snort -v on a Mac OS X machine.

                [bdm0509:~] snort -v
Running in packet dump mode

        --== Initializing Snort ==--
Initializing Output Plugins!
Verifying Preprocessor Configurations!
***
*** interface device lookup found: en0
***

Initializing Network Interface en0
ERROR: You don't have permission to sniff.
Try doing this as root.
Fatal Error, Quitting..

Yes, that's an error, and it's printed here for an important purpose: Snort requires pretty extensive permissions to do much at all. Sniffing is a basic operation, but it's clear that without root permission, or at least the ability to use sudo, it's tough to make much use of Snort.

Try the same command, but this time running under the supervisor account. You should get output similar to Listing 9. You'll have to use Ctrl+C to exit, as Snort will run indefinitely.

                [bdm0509:~] sudo snort -v
Password:
Running in packet dump mode

        --== Initializing Snort ==--
Initializing Output Plugins!
Verifying Preprocessor Configurations!
***
*** interface device lookup found: en0
***

Initializing Network Interface en0
Decoding Ethernet on interface en0

        --== Initialization Complete ==--

   ,,_     -*> Snort! <*-
  o"  )~   Version 2.8.0.2 (Build 75)  
   ''''    By Martin Roesch & The Snort Team: http://www.snort.org/team.html
           (C) Copyright 1998-2007 Sourcefire Inc., et al.
           Using PCRE version: 7.6 2008-01-28

Not Using PCAP_FRAMES
03/31-08:55:12.179192 192.168.1.102:64862 -> 239.255.255.253:427
UDP TTL:1 TOS:0x0 ID:10292 IpLen:20 DgmLen:64
Len: 36
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

03/31-08:55:12.179498 192.168.1.102:64863 -> 239.255.255.253:427
UDP TTL:1 TOS:0x0 ID:10293 IpLen:20 DgmLen:64
Len: 36
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

03/31-08:55:12.180121 192.168.1.102:64864 -> 239.255.255.253:427
UDP TTL:1 TOS:0x0 ID:10294 IpLen:20 DgmLen:64
Len: 36
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

03/31-08:55:12.180278 192.168.1.102:64865 -> 239.255.255.253:427
UDP TTL:1 TOS:0x0 ID:10295 IpLen:20 DgmLen:64
Len: 36
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

03/31-08:55:12.247880 192.168.1.102:64866 -> 192.168.1.255:137
UDP TTL:64 TOS:0x0 ID:10296 IpLen:20 DgmLen:78
Len: 50
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

03/31-08:55:12.248297 192.168.1.103:137 -> 192.168.1.102:64866
UDP TTL:64 TOS:0x0 ID:8075 IpLen:20 DgmLen:90
Len: 62
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

03/31-08:55:12.599248 192.168.1.102:55381 -> 192.168.1.101:139
TCP TTL:64 TOS:0x0 ID:10297 IpLen:20 DgmLen:64 DF
******S* Seq: 0x42127B5E  Ack: 0x0  Win: 0xFFFF  TcpLen: 44
TCP Options (8) => MSS: 1460 NOP WS: 0 NOP NOP TS: 1428368232 0 
TCP Options => SackOK EOL 
...
LOTS more output here
...
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

03/31-08:55:21.976018 0.0.0.0:68 -> 255.255.255.255:67
UDP TTL:64 TOS:0x0 ID:48134 IpLen:20 DgmLen:328
Len: 300
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

03/31-08:55:21.976800 ARP who-has 192.168.1.104 tell 192.168.1.1

03/31-08:55:22.968515 192.168.1.1:67 -> 255.255.255.255:68
UDP TTL:150 TOS:0x0 ID:6040 IpLen:20 DgmLen:576
Len: 548
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

03/31-08:55:22.977578 ARP who-has 192.168.1.104 tell 192.168.1.104

^C*** Caught Int-Signal
Run time prior to being shutdown was 14.231224 seconds
===============================================================================
Packet Wire Totals:
   Received:           78
   Analyzed:           78 (100.000%)
    Dropped:            0 (0.000%)
Outstanding:            0 (0.000%)
===============================================================================
Breakdown by protocol (includes rebuilt packets):
      ETH: 78         (100.000%)
  ETHdisc: 0          (0.000%)
     VLAN: 0          (0.000%)
     IPV6: 0          (0.000%)
  IP6 EXT: 0          (0.000%)
  IP6opts: 0          (0.000%)
  IP6disc: 0          (0.000%)
      IP4: 71         (91.026%)
  IP4disc: 0          (0.000%)
    TCP 6: 0          (0.000%)
    UDP 6: 0          (0.000%)
    ICMP6: 0          (0.000%)
  ICMP-IP: 0          (0.000%)
      TCP: 57         (73.077%)
      UDP: 14         (17.949%)
     ICMP: 0          (0.000%)
  TCPdisc: 0          (0.000%)
  UDPdisc: 0          (0.000%)
  ICMPdis: 0          (0.000%)
     FRAG: 0          (0.000%)
   FRAG 6: 0          (0.000%)
      ARP: 3          (3.846%)
    EAPOL: 0          (0.000%)
  ETHLOOP: 0          (0.000%)
      IPX: 0          (0.000%)
    OTHER: 4          (5.128%)
  DISCARD: 0          (0.000%)
InvChkSum: 0          (0.000%)
  Upconvt: 0          (0.000%)
  Up fail: 0          (0.000%)
   S5 G 1: 0          (0.000%)
   S5 G 2: 0          (0.000%)
    Total: 78        
===============================================================================
Action Stats:
ALERTS: 0
LOGGED: 0
PASSED: 0
===============================================================================
Snort exiting

This probably doesn't make a lot of sense right now, and that's OK. You're going to know a lot more about what's going on before you're finished with the series. For now, the task is to make sure Snort is installed correctly. If you can run Snort as a sniffer, you're ready to go on to using Snort, not just issuing confusing commands to it.

Back to top

But I don't have root access!

By now, you've surely figured out that Snort wants to do more than most user accounts are allowed. Even assuming you can talk your network or system administrator into installing Snort -- and shame on them if they didn't have it installed already -- you're still stuck with a limited view of the world using Snort unless you've got some extra privileges.

However, there's a fair distance between the typical user account and a root user (or the privileges you're granted through the sudo command). Most administrators are willing, given a good and well-presented reason, to let you broach at least a bit of that distance. Here's a rational approach to getting your admins to let you use Snort and granting you the permissions you'll need to make that happen:

Get Snort installed

First, get Snort installed. Again, some admins will have Snort already available. Also keep in mind that Snort doesn't have to be running on the machine you want to protect and sniff. For example, you may have several Web sites on several servers. While it would be great if Snort was running and accessible on all those servers and you could easily telnet in and use the program, you can still get a lot of information by running Snort on your own machine and pointing it at the servers running your sites. So, you may be able to use Snort to do what you want from your own desktop or laptop (again, this isn't ideal, but it's at least a step in the right direction).

If your admins give you a blank look when you mention Snort, point them to this article or some of the Snort books mentioned in Resources. They may be a lot nicer with your permissions if you help them out with protecting the servers they're responsible for.

Make sure you can run Snort

Your next priority is to ensure you can run the snort command. Because Snort is installed in /usr/local/bin (at least by default), this can be as simple as opening that directory to all users or your user account, or at least making that particular binary available to your user (or perhaps a group that your user account can be added to). The best way to do this is to start with the most restrictive request possible. Ask your admin if they'll make /usr/local/bin/snort runnable by your specific user account.

In reality, most admins are overworked and over-busy. Often, they'll grant you more permissions than you ask for, but they'll also appreciate you not asking them something they see as ridiculous, such as granting your account access to all the treasured executable programs on the servers they're responsible for. And often, you'll get something in between, such as being put into a group that can access several programs like Snort that aren't common, but aren't as potentially dangerous as something like changing a password or deleting a user account.

Make sure you can use Snort

Unfortunately, Snort wants to write to lots of restricted directories, as well as to run in them. This means that often, even if you can run Snort, you can't use it to do anything productive. Here's where taking the steps listed, as well as reading this series, comes into play.

First, lots of things that Snort does by default in restricted directories, it can do by request to non-protected directories. So, you can choose to have Snort log to directories you already have access to, and reduce some of the permissions issues. But, ultimately, you're still going to run into errors like Listing 10:

[bdm0509:~] snort -v
Running in packet dump mode

        --== Initializing Snort ==--
Initializing Output Plugins!
Verifying Preprocessor Configurations!
***
*** interface device lookup found: en0
***

Initializing Network Interface en0
ERROR: You don't have permission to sniff.
Try doing this as root.
Fatal Error, Quitting..

The bad news is that there's no good way to get around this; it requires permissions that are typically associated with root users. But the good news -- and the reason this article is of use to Web developers and not just system and network administrators -- is that anything you configure and run on your local machine applies to Snort running on a production machine. So, as you build configuration files, learn how to log alerts, and develop rules for Snort, all on your local installation (perhaps on a laptop, even), you're building a system for detecting intrusions that works anywhere.

While most admins won't give you free reign, many will allow you to supply them scripts and rules files (we'll talk more about rules in the next article) that they can run for you -- often while you're looking over their shoulder. Best case? Perhaps not, but it's still going to offer your site protection, and that's the bottom line.

Get logs and alerts mailed to you

The unfortunate truth about most IDSes, and most administrators, is that problems are caught and ignored pretty frequently. Admins have a lot of work, and even if you've properly set up Snort and fed it solid rules, you may not have a safe system. Most intrusions require action. That's why, if possible, you should get your admin to mail you the log and alert files that you'll soon have Snort generating. You can ask for this to be done weekly, as an automated job, but you may also want to configure Snort to auto-mail you as well as admins when problems occur. Again, figure out the configurations to make this happen on your machine, and then hand them to your admin so they don't have to do the work.

So, whether you're the root user, a network admin with supervisor privileges, or a Web developer who struggles to get PHP scripts installed because of a protective system administrator, you can still benefit from a solid understanding of Snort.

Back to top

Three functions to play with

At this point, you should have a working installation of Snort and some solid ideas about getting Snort running even in semi-restrictive environments. Before finishing this article, though, here's a chance to look ahead -- and play around -- with Snort's three basic functionalities. This gives you a head start on the next article, and lets you start thinking concretely about what Snort can do for your systems.

Snort is a packet sniffer

A packet is simply a formatted bit of data. Networks tend to consider data not in large chunks, nor in tiny bytes, but in packets. A packet provides not only data, but a short bit of information about that data. That allows packet senders to indicate what type of data is being sent, and packet receivers to learn a bit about a packet's data (called its payload) before digging into the data itself.

A packet sniffer is a tool that sniffs, or investigates, packets. With Snort, you can inspect network traffic at the packet level, allowing you to see raw data, as well as the information the packet receiver attached to the raw data itself. This is what you got when you used the snort with the -v flag. When you run Snort as a packet sniffer, you get three things:

1. Information about where Snort is logging information to and the network interface it's inspecting.
2. The packets Snort is sniffing, being sent to and from the indicated network interface.
3. A summary of everything Snort did in this running (printed when you end the sniffing, usually with Ctrl+C).

In the next article, you'll learn about exactly what's in these packets and how to start making rudimentary analyses on these packets. For now, see if you can figure out, for each packet, what each bit of information is that's reported for a packet. Here's a single packet's output:

03/31-08:55:12.180121 192.168.1.102:64864 -> 239.255.255.253:427
UDP TTL:1 TOS:0x0 ID:10294 IpLen:20 DgmLen:64
Len: 36

If you're not sure, try sniffing packets on your own machine, with your own installation of Snort. You also might want to check and see what your IP address is to help. That should allow you to piece together anything you're not already sure about.

Snort is a packet logger

Packet sniffing is great, but as you've seen, Snort's packet sniffing mode assumes you're hunched over your display, eagerly watching as thousands of lines of network data flies by. Of course, you've got sites to design and worlds to take over, so that's not optimal. By adding the -l switch to Snort, you tell it to log packets to a directory of your choosing (see Listing 11):

[bdm0509:~/Documents/developerworks/snort_1] sudo snort -l myLogDir/
Password:
Running in packet logging mode
Log directory = myLogDir/

        --== Initializing Snort ==--
Initializing Output Plugins!
Verifying Preprocessor Configurations!
***
*** interface device lookup found: en0
***

Initializing Network Interface en0
Decoding Ethernet on interface en0

        --== Initialization Complete ==--

   ,,_     -*> Snort! <*-
  o"  )~   Version 2.8.0.2 (Build 75)  
   ''''    By Martin Roesch & The Snort Team: http://www.snort.org/team.html
           (C) Copyright 1998-2007 Sourcefire Inc., et al.
           Using PCRE version: 7.6 2008-01-28

Not Using PCAP_FRAMES

Note that this command starts Snort in the foreground; if you press Ctrl+C at this point, and get your terminal prompt back, you stop Snort's logging. So you should either run Snort as a packet logger in a window you can minimize and ignore, or better yet, as a long-running process (perhaps as a daemon or system process).

When you do exit this process, Snort gives you the same summary data as before. But, it also creates a file of the packets it sniffed in the directory you indicated:

[bdm0509:~/Documents/developerworks/snort_1] ls myLogDir/
snort.log.1206998502

Open this file, and you'll get even more detailed information about the packets that were sniffed while Snort was running. Remember, though, if you had to run Snort as supervisor (using sudo) or root, you'll have to open the file using the same permissions.

Take a look at this file; it looks a bit different from the sniffer output shown above. In fact, it's a lot less usable -- until you learn how Snort can analyze its own files. That's also a subject for the next article, so while you're experimenting with Snort, work with the command-line version, the packet sniffer, but hold off on the packet logger for now.

Snort is an IDS (or NIDS)

Ultimately, both packet sniffing and packet logging -- as well as analysis on those logs -- are subsystems of an Intrusion Detection System (or, as Snort is sometimes called, an NIDS, Network Intrusion Detection System). This is where Snort really shines. It's also where things get quite involved and fairly tricky. Because the types of intrusions change rapidly, Snort has a set of rules that you can download from the Snort site that details these intrusions and allows Snort to look for them. The rules change frequently, keeping up with (or at least trying to) the various types of attacks that are going on.

Additionally, you'll need to configure Snort and tell it what to do when it senses an attack. This is where that network and system admin you were being nice to earlier is going to save your site... let them do the work of responding to attacks. But if you can make them aware of attacks by handing them configuration and rules files, you're already way ahead of the game.

If you're impatient, and simply can't wait to try out Snort as an IDS, try running snort -A, which puts Snort in alert mode. You'll have to fiddle a bit to get things working, but this is a great testbed for Snort while you're waiting on the next article.

Back to top

Conclusion

Web development is about more than HTML and CSS, and Web programming is about more than Java™ code, C++, and PHP. Ultimately, you're building functional applications. All your code is for naught if users can't hop online and buy items from their favorite vendor or find out how much the newest abstract watercolor from their local gallery costs. And no matter how well-honed your programming and design skills, users can't -- or won't -- use hacked applications, Web pages with inappropriate pictures, or online shopping carts that quote them prices way too high, or even worse for the vendor, way too low. A good developer and designer, then, is more than a coder. They're at least somewhat involved in protecting their assets, much like a good investor. The longer their work runs properly, the more they're worth.

Snort is arguably the best and easiest-to-use, as well as (certainly) the cheapest, intrusion detection system you'll find. It installs in just a few minutes, it's easy to get and run, and it's flexible. From packet sniffing to analysis to alerting you or an admin to possible intrusions, Snort protects your work from attack. By now, you should have Snort running on at least one machine (and maybe several, on different platforms, if you've really followed along), and performing some basic packet sniffing. You should also be curious about what's in those packets and what else Snort will let you do.

While you're waiting on details about those packets, and thinking about what types of alerts a good IDS will detect, continue to play around with Snort. Here are a few ideas to keep you busy. First, start Snort up in packet sniffing of packet analysis mode. Then, try a few of these scenarios:

• If you've got a Web server on the machine sniffing packets, point a browser on a different machine to that Web server and browse around. Note the IP address of the different machine (the one with the browser). What do you see in the packet logs or output from Snort? Can you find the Web traffic?
• Try telnetting or FTPing from a different machine to the machine sniffing. What sort of traffic do you see then?
• Create a directory on your Web server that has no index.html (or .php or .htm, and so on). Put several files in that directory, and allow anonymous directory listings. Point your different machine's browser at that directory. Is the traffic different (and the packets that represent that traffic) from a normal HTML or PHP page? How?
• Set up authentication, using an Apache .htaccess file or whatever your server provides. Access the protected resource from another machine. What do the packets look like? What about when you successfully log in? What about when you fail to log in with valid credentials?

These are just a few ideas, but they'll give you a great idea about the packets that are flying around in a typical Web server request/response model. See if you can get some ideas about what is "normal" traffic, and what's not. Then come back in a month, and I'll talk a lot more about alerts, rules, and preventing serious intrusions to your system.

Resources

Learn

• Everything about Snort begins with the Snort Web site.
  
  
• Red Hat Linux has a nice feature on securing your Red Hat Linux system with Snort. It's a bit dated, but the basic concepts all still apply.
  
  
• If you want the power of Snort, but would prefer a commercial product with professional support, check out Sourcefire's IDS built on top of Snort.
  
  

Get products and technologies

• The Snort downloads home has all the Snort binaries and source file downloads.
  
  
• You can download a C compiler for Mac OS X from the Apple Developer Connection. You'll need an account, but registration and download is free.
  
  
• Download the Perl Compatible Regular Expressions library.
  
  
• WinPcap allows Snort link-layer network access on Windows platforms.
  
  
• Managing Security with Snort and IDS Tools (Kerry Cox and Christopher Gerg, O'Reilly Media, Inc.) provides a more general introduction to security, as well as a ton of Snort-specific content for managing your sites.
  
  
• The Snort Cookbook (Angela Orebaugh, Simon Biles, and Jacob Babbin, O'Reilly Media, Inc.) is a terrific resource for getting into Snort and performing specific tasks, ranging from basic installation to advanced intrusion detection and network optimization.
  
  

Discuss

• developerWorks blogs: Get involved in the developerWorks community.
  
  

About the author

Brett McLaughlin is a bestselling and award-winning non-fiction author. His books on computer programming, home theater, and analysis and design have sold in excess of 100,000 copies. He has been writing, editing, and producing technical books for nearly a decade, and is as comfortable in front of a word processor as he is behind a guitar, chasing his two sons around the house, or laughing at reruns of Arrested Development with his wife. His last book, Head First Object Oriented Analysis and Design, won the 2007 Jolt Technical Book award. His classic Java and XML remains one of the definitive works on using XML technologies in the Java language.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Security is critical
• Snort: an intrusion detection tool
• Getting Snort
• Installing Snort from source code
• Installing Snort from an RPM on Linux
• Installing Snort from a Windows binary installer
• Testing your installation
• But I don't have root access!
• Three functions to play with
• Conclusion
• Resources
• About the author
• Comments

Next steps from IBM

WebSphere Application Server can take you to the next step in the evolution of Web Development that lends itself to the creation of rich Web 2.0 user interfaces.

---

• Try: Download a free trial version of WebSphere Application Server Community Edition, a pre-integrated, lightweight Java 5 application server built on Apache Tomcat and other best-of-breed open source software such as OpenEJB, Apache Axis, and Apache Derby..
• Article: This article introduces you to the web development with WebSphere Application Server Feature Pack for Web 2.0. Its a good look at solutions for creating Ajax-based web apps and mashups.
• Tutorial: This tutorial takes you through the PHP and Java steps to master Facebook application Web development with the no-charge WebSphere Application Server Community Edition Web server.
• Demo: This demo showcases the WebSphere Application Server Community Edition administrative console feature set and walks you through deployment of a Web application.
• Buy: WebSphere Application Server - Express

My developerWorks community

Dig deeper into Web development on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers