In our last installment we reviewed the important fundamentals of using Snort, the popular and excellent open-source intrusion detector, and effective locations in your network for Snort detectors. Today we're going to make it go, using Ubuntu Server Edition 8.04 LTS. Which is too long a name to say more than once, so let's call it Ubuntu Server. It shares the same package repositories as desktop edition, but with some important differences. The kernel is tuned for server duties, it's stripped-down to the essentials needed for running a LAN server, and you don't get the X Window System. That's right, it presents a bare command-line interface.
Fear not the command line — servers should not have graphical environments because they are resource hogs, and they introduce instabilities. One way to get a friendlier administration interface is to run sshfs on a remote PC. sshfs is a quick, easy way to mount remote directories and filesystems, which you can then use just as though they were installed locally, and you can use your preferred graphical editors and file managers. You need openssh-server installed and running on Ubuntu Server. Install sshfs and fuse-utils on your remote PC, create a local mountpoint, and then mount the remote directory you want to work in. This example mounts the /etc/ directory from the Ubuntu server on the remote PC named Xena:
carla@xena:~$ sudo aptitude install sshfs fuse-utils
carla@xena:~$ mkdir temp/
carla@xena:~$ sshfs alrac@ubuntu:/etc temp/
Use the mount command to verify that it worked:
carla@xena:~$ mount | grep sshfs
sshfs#alrac@ubuntu:/etc on /home/carla/temp type fuse (rw,nosuid,nodev,max_read=65536,user=carla)
temp is in my home directory, but I still need root permissions to edit the files.
Installing and Configuring Snort
First, a brief word on package management: These days I need a compelling reason to ever build anything from sources. Dependency-resolving package managers like Aptitude and Yum are wonderful things that save time and headaches— installing, updating, and removing software are easy and fast, and security and bugfixes are pushed out automatically.
You need two network interfaces on your Snort box, one for Snort to listen on and one management interface. Some folks like to play tricksy games with trying to make a single interface do both- don't. NICs are inexpensive and using two separate interfaces is easier and safer. The management interface is configured just like any other host on your LAN. The listening interface is configured in stealth mode, without an IP address, and must be set to promiscuous mode, which means it listens to all packets that come down the wire. Here is a complete example configuration file, /etc/network/interfaces, for Ubuntu Server and any Debian-ish distribution:
# The loopback network interface auto lo iface lo inet loopback #Snort's stealth listening interface auto eth0 iface eth0 inet manual up ifconfig eth0 0.0.0.0 up up ip link set eth0 promisc on down ip link set eth0 promisc off down ifconfig eth0 down #management interface auto eth1 iface eth1 inet dhcp
After changing your network interface configuration, restart networking:
$ sudo /etc/init.d/networking restart
Then confirm that your listening interface is correctly configured:
$ ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:0a:cd:15:95:92 inet6 addr: fe80::20a:cdff:fe15:9592/64 Scope:Link UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 [...]
Perfect! No IP address, the interface is up, and PROMISC mode is on.
Now install Snort on Ubuntu Server with this command:
$ sudo aptitude install snort
To get the thorough and excellent Snort documentation, run sudo aptitude install snort snort-doc, or install the documentation separately on another PC. Ubuntu will install everything you need to get up and running, including oinkmaster and snort-rules-default.
The installer will ask you what address range you want Snort to monitor. To specify multiple ranges, make a comma-delimited list with no spaces, like 192.168.1.0/24,192.168.2.0/24. It selects eth0 by default, so if you don't want to use eth0 you'll have to change it by running sudo dpkg-reconfigure snort. This creates a special configuration file just for Debian, /etc/snort/snort.debian.conf. Don't edit this file- use dpkg-reconfigure. You ought to run this anyway to make sure the settings are correct for you. For example, by default Snort sends a daily email to root, but if you don't log in as the root user you'll never see it.
Ubuntu starts Snort with a passle of options, which you can see by running:
# ps ax | grep snort
/usr/sbin/snort -m 027 -D -d -l /var/log/snort -u snort -g snort -c /etc/snort/snort.conf -S HOME_NET=[192.168.1.0/24,192.168.2.0/24] -i eth0
It takes some digging to unearth all the Snort command options and what they do. snort -? displays a list, which is good and helpful but some of the descriptions are a bit terse. Here is what Ubuntu's Snort incantation means:
-m sets the umask to 027, which means files created by the Snort user default to mode 640, and directories to 750.
-D mean run in daemon mode.
-c is "read this configuration file".
-l specifies the Snort logging directory. Always give Snort its own logging directory.
-u and -g tell which user and group the Snort daemon will run as.
-S lets you define rules and variables just like you see in /etc/snort/snort.conf.
-i means network interface.
Not Using PCAP_FRAMES
/var/log/daemon.log contains the startup output from Snort. On most Linux systems you'll see the "Not Using PCAP_FRAMES" message at the end. This is not a fatal flaw, but a performance issue related to memory management. You can fix it by adding the environment variable PCAP_FRAMES=max. Where do you do this? On Linux it's a confusing crapshoot. The sure way is to add this line to /etc/init.d/snort, right after the PATH= statement:
Restart Snort with /etc/init.d/snort restart, and the daemon.log message will change to "Using PCAP_FRAMES = max". The harder your Snort system works, the more it will appreciate having this option enabled.
Snort comes with a great set of rules. Chances are you don't need all of them, so your next job is to visit Section 6 of /etc/snort/snort.conf and comment out the unnecessary rules. You'll get false alarms and poorer performance by not being selective. If you're not running a Web server, comment out the Web rules. The same goes for IMAP, POP, IIS, and so forth. When you're in doubt, leave the rule active. Whenever you change snort.conf you should restart Snort:
$ sudo /etc/init.d/snort restart
Now what? Now comes the real work- analyzing all the data that Snort captures. There are some excellent tools for this that we'll cover in our next and final installment.