Malicious network traffic (such as worms, hacking attempts, etc.) has certain patterns to it. You could monitor your network traffic with a sniffer and look for this malicious traffic manually but that would be an impossible task. Enter IDS (Intrusion Detection System) software which automates the process of sniffing, examining, and upon finding something suspicious, alerting.
IDS has been called the burglar alarm of computer networks and is an important part of network perimeter security. WIthout an IDS you have no idea if someone is probing or attacking your servers (unless the attack is so overwhelming that it results in a denial of service). Having this information can let you know if you need to make some firewall changes or harden the OS on a particular server a bit more.
You may see the term IPS for Intrusion Prevention Systems which takes things one step further, having the IDS adjust the firewall when it discovers something. Smart people disagree on the use of IPSs as it, in effect, gives an attacker some control of your firewall.
Snort (www.snort.org) is the most widely-used IDS software applicaton and it’s open source and included with Debian. There are two flavors of IDSs, host-based and network-based. Snort is a network-based IDS that can monitor all of the traffic on a network link to look for suspicious traffic. Typically, a network-based IDS is set up to monitor a DMZ or the internal network right behind the firewall so it alerts to any possible threats that your firewall didn’t catch.
There is a Web interface that works with Snort called BASE (Basic Analysis and Security Engine) which is based on ACID (Analysis Console for Intrusion Databases) which we’ll set up. BASE uses what’s commonly referred to as a LAMP server (Linux, Apache, MySQL, PHP) so we’ll need to install those applications as well.
Because LAMP servers tend to attract hackers we’ll want to put the Snort box on an internal network but this requires setting up your Snort box with two NICs. One NIC is connected to your internal network with an appropriate IP address for that network (like 172.24.1.20). This internal address is the one we point our Web browsers at when we want to look at the BASE Web pages. The other NIC does NOT have an IP address. It plugs into whatever network segment you want to monitor, like your DMZ or even your Interent segment outside of your firewall. Snort puts this NIC into promiscuous mode so it can snort up all the traffic it sees (basically it’s Snort’s snout). By not putting an IP address on Snort’s promiscuous NIC you can get away with plugging this NIC into a DMZ link or even outside of your firewall (on your Internet link).
On this page we assigned an address to the eth0 interface and we’ll be using eth1 as the promiscuous interface. Adjust these values for your system as necessary.
If you run the Debian installer with two NICs installed in the system, it will let you choose if you want to configure eth0 or eth1 with an IP address. However, this necessitates that you use the netcfg/disable_dhcp=true switch when you start the Debian installation. (We specify using this switch on our Installation page.) If you have more than one brand of NIC to choose from it’ll make your life a little easier if you use NICs by two different manufacturers as it will be easier to determine which NIC Debian designates as the eth0 interface and which NIC is designated as the eth1 interface.
Connecting the promiscuous NIC into the segment you want to monitor is not as easy as just plugging it into a switch port. Because switches segment each port into it’s own little collision domain, if you do plug the promiscuous NIC into a switch port it’ll only see broadcast traffic. You need to either tap into the link you want to monitor using a hub, or you have to do port spanning on your switch. If you’re interested in monitoring traffic coming in from the Internet, given that most Internet (broadband) connections are less than 10 megabit you can pick up an old 4-port 10-meg hub on eBay to tap into this link. (Just make sure you’re getting a hub as many people use the terms hub and switch interchangeably.) If you want to monitor traffic on your internal network, you could configure port spanning on your switch. Port spanning simply takes all of the traffic on one or more switch ports and duplicates it to a span port that has a monitoring device connected. Consult your switch documentation on how to set this up.
The above diagram shows how you’d use a hub to monitor the traffic coming in from a cable or DSL modem. Note that Snort’s promiscuous NIC is located before the cable/DSL router. (Most cable/DSL routers have some limited firewall capabilities.) In this case, in order to determine the HOME_NET value (discussed below) you’d have to know the IP address that your router pulled from your ISP’s DHCP server. The easiest way to find out what IP address your router pulled is to visit a Web site like whatsmyipaddress.com that displays your “external” IP address when you visit the site.
NOTE: There’s no law saying that both NICs can’t be connected to the same network (even the same switch). If you wanted to monitor your internal network for possible virus or worm traffic, both NICs would be connected to the same network. The promiscuous NIC would be connected to a span port sucking up the traffic and the addressed NIC is used for accessing the BASE Web pages.
Snort has a “rule base” that contains patterns or “signatures” of malicious traffic much like an antivirus program has a database of virus signatures that it uses to compare to streams of program code. Also like antivirus software, you can download updates to Snort’s rule base file. Unlike an antivirus signature database, you can tweak the rules in Snort’s rule base to minimize false alerts. You can also choose which rules you want Snort to use and which to ignore to taylor Snort to your network environment. For example, a Snort rule may closely resemble the traffic patterns of a custom-written Web application that your organization uses. In this case you would disable this rule so you don’t get false-positive alerts when the application is used.
| Installing Snort |  |
Lets start setting up the LAMP server by installing MySQL with the command:
apt-get install mysql-server
You’ll be prompted to enter a password for the MySQL root account (equivalent to the sa password in MS SQL). We’ll be needing it in a few minutes. If you haven’t already done so, install Apache next with the command:
apt-get install apache2
Now finish the LAMP server setup with the command:
apt-get install php5
Now that we have our LAMP server components installed we can install Snort. Because we have MySQL installed we can use the MySQL-specific Snort (version 2.7) package.
| What Is HOME_NET ?The HOME_NET variable in Snort’s configuration file should contain (in CIDR format) the network that you want to protect, i.e. the network that your servers are on, i.e. the network you are going to plug the promiscuous NIC into. This may not be the same network that the addressed NIC on your Snort box plugs into. |
Install the package with the command:
apt-get install snort-mysql
The first thing it asks for is the HOME_NET value. If your servers are on a Class C network (or subnet) with an address like 192.168.1.15 then enter 192.168.1.0/24 for the HOME_NET CIDR block. If your servers are on a Class B network with an address of something like 172.24.3.15 then enter 172.24.0.0/16 for the HOME_NET CIDR block. In our diagram above, lets say your router pulled an IP address of 64.233.161.147. You could just enter that as a Class C CIDR block of 64.233.161.0/24.
The next screen tells you that no database has been set up for Snort. Press Enter and then, with the default Yes selected, press Enter again.
Snort will finish installing and it will end with an error (error code 1). That error was generated because Snort failed to start. Snort failed to start because it’s not configured yet. In short, no problem.
Next we’ll install the BASE Web interface with the command:
apt-get install acidbase
You’ll see an informational screen about the include path (just press Enter) and a manual configuration informational screen (just press Enter.)
Next you’ll be prompted to configure the database for acidbase. Select the default ‘Yes’ by pressing Enter. Then on the next screen ‘mysql’ will be selected so just press Enter.
Next you’ll be prompted to enter the password for the MySQL “administrative user” which is root so enter the MySQL root password that you entered above when you installed MySQL.
You’ll then be prompted to create and confirm an application password for the acidbase database. Note that this is not the password for the MySQL root account you just entered. This password should not be the same as your MySQL root password because it’s stored in clear text. Once these are entered the acidbase installation will finish. (You’ll get the snort-mysql error code 1 again but don’t worry about it for now.)
The next thing we have to do is alias the BASE directory to our Apache “Web root” so we can include it in a browser URL. To do that we need to enter some statements into the Apache default configuration file. Luckily the statements we need to enter are in a file that was installed with the acidbase package. Open the Apache default configuration file with the command:
nano /etc/apache2/sites-available/default
Cursor down to the bottom of the file. The last line in the file is the </VirtualHost> statement. Put your cursor on the blank line just above this statement and press Ctrl-r and in the “File to insert” field enter:
/etc/acidbase/apache.conf
and press Enter. Cursor up a few lines to the line that reads:
allow from 127.0.0.0/255.0.0.0
and change the network address and subnet mask to match the machines on your local network that will be accessing the BASE Web pages. For example, change it to192.168.1.0/255.255.255.0 for a Class C internal network. You can change both the address and subnet mask to all zeros if you want don’t want any address restrictions on who can access the BASE Web pages.
Now do a Ctrl-x and press ‘y’ at the prompt to save the changes and press Enter to write the file.
During the acidbase installation we were prompted to create a Snort database. However, now we have to use a pre-defined script to build the structure (tables, fields, etc.) of the database. Change directories with the command:
cd /usr/share/doc/snort-mysql
and enter the following command to run a script which creates the database structure. Note that that is a pipe symbol after create_mysql.gz in the command. Also note that you want to enter the application password that you entered during the acidbase install, not the MySQL root password. If you don’t remember what you entered, cat the/etc/acidbase/database.php file. Also be sure to NOT put a space between the -p and the password itself.
zcat create_mysql.gz | mysql -u snort -D snort -papplicationpassword
If you don’t see anything be glad. The only time executing this command will print out anything is if there was an error. With the database configured Snort can now start. However, there is a ‘flag’ file that we need to delete to indicate that we have the database configured. Enter the command:
rm /etc/snort/db-pending-config
to delete this file. With that flag gone we need to do a little installation housekeeping with the command:
dpkg –configure –pending
Because our promiscuous NIC wasn’t “up” when we installed Snort, it just assumed we wanted to use the NIC that was up. We need to tell Snort to use our promiscuous NIC. We do this by reconfiguring Snort with the command:
dpkg-reconfigure snort-mysql
For the “Snort start method” accept the default boot selection, tab to OK and press Enter.
At the informational screen on interfaces, tab to OK and press Enter.
Assumming your promiscuous NIC is the second NIC in your system, change the interface value to eth1 instead of eth0 and then tab to OK and press Enter.
On the next screen the HOME_NET value you entered during the package installation should still be there (if not, re-enter it) so just tab to OK and press Enter.
Next you are asked if you want to disable promiscuous mode on the interface you entered. Accept the default No by pressing Enter.
Next you are asked if you want to change Snort’s testing order. Accept the default No by pressing Enter.
Leave the “Additional custom options” field blank, tab to OK and press Enter.
Next you have the option of receiving daily summaries by e-mail. If you answer ‘Yes’ to this, and enter a recipient other than the default ‘root’ entry (be sure to enter a full e-mail address), see the section below on setting up e-mail services.
For now, accept the default value of 1 for minimum occurances by tabbing to OK and pressing Enter.
The next screen lets you know that Snort hasn’t been set up to write entries to a database. Press Enter at OK and again at Yes to set this up.
When it asks for a “Database server hostname” enter localhost and tab to OK and press Enter.
Next it will ask you for the name of an existing database. Enter snort, tab to OK and press Enter.
In the “Username” field enter snort, tab to OK and press Enter.
In the “password” field enter the application password you chose earlier, tab to OK and press Enter. Then press Enter again at the information screen.
You’ll see messages that Snort failed to start because eth1 was not available. We need to change the way Snort starts so it uses our promiscous NIC. Snort is set to run as a daemon automatically at boot up but with that configuration it won’t bring up our promiscuous NIC (eth1). Disable this with the command:
mv /etc/rc2.d/S20snort /etc/rc2.d/_S20snort
We’ll create a startup script of our own to bring up our promiscuous NIC and set it not to respond to arp requests (so hackers don’t discover we’re monitoring the network segment). Fire up a text editor with the command:
nano /etc/init.d/runsnort.sh
and enter the following two commands:
| ifconfig eth1 up -arp /etc/init.d/snort start |
Exit the editor saving the file. Now we need to make our script executable with the command:
chmod 750 /etc/init.d/runsnort.sh
All scripts that could be run when the system boots, no matter the runlevel, are put in the /etc/init.d directory but it’s the runlevel that determines which of these scripts actually gets run when the system boots up. Debian’s default runlevel is 2 so we need to create a symbolic link to our script in the runlevel 2 directory. Do that with the command:
ln -s /etc/init.d/runsnort.sh /etc/rc2.d/S95runsnort
Reboot your system. Everything should now come up automatically. (When Snort starts it will indicate which NIC it’s using.) Connect your promiscuous NIC to the network segement you want to montior, either by using a hub or spanning a switch port, and test it out.
You can make sure the promiscuous NIC came up during the bootup process by entering the command:
ifconfig
The promiscuous NIC (eth1) should be listed and NOT have an “inet addr” (IP address) entry while the NIC you’ve assigned an IP address to should.
Next, make sure Snort is seeing network traffic on the promiscuous NIC by entering the command:
snort -i eth1 -v
This will run a second instance of Snort in verbose mode. The destination IP addresses of the traffic displayed should be within the network address space of the HOME_NET value you specified earlier. Press Ctrl-C to stop the display and exit the second instance of Snort.
We’ve got Snort up and running but there’s still some minor BASE stuff we need to take care of. This next bit of setup is done via a Web browser. Get on another system on the network and fire up a browser (or fire up a browser on your Snort box if you installed the X-Windows and browser packages) and enter the following URL using the IP address you assigned to the addressed NIC of your Snort box:
http://172.16.1.52/acidbase/
You should see the BASE banner graphic and, right underneath it, a message saying that the database “appears to be incomplete/invalid.” On the next line you’ll see a Setup page link. Click on that.
One the right side of the next page you’ll see a Create BASE AG button. Click on that.
You should see a series of red Successfully created and Successfully INSERTED messages displayed. Further down on the left side of the page, click on the Main page link. This is the BASE home page and it will update automatically every three mintues.
| What If Nothing Is DisplayedHaving all “0%” showing for the traffic graphs on the BASE home page is what we’re hoping for (no suspicious traffic) but if nothing is ever displayed you may have a problem. The most common cause of the BASE Web pages never displaying any statistics or alert information when you know there should be is an incorrect HOME_NET value. Check to make sure the value you set for the HOME_NET variable matches the address space of the network segment you’re monitoring. |
Snort’s default configuration file is the /etc/snort/snort.conf file. However, there is also a /etc/snort/snort.debian.conf file. The Debian-specific file is where the settings are stored when you run the dpkg-reconfigure command. This Debian-specific configuration file is used by the /etc/init.d/snort startup script and the settings in it take precedence over the corresponding settings in the /etc/snort/snort.conf file.
Next we have to take care of setting up the summary e-mails that Snort sends out.
| Setting Up Snort E-mailing | |
If you answered ‘No’ to receiving summary e-mails from Snort or you accepted the default ‘root’ recipient, you can skip to the “Managing Rules” section.
By default, the Debian installer installs the Exim mail server package and configures it to only handle local (between accounts on the server) delivery. We need to set up our server to act as an e-mail client (like Outlook or Thunderbird) to your SMTP server so it can send the daily summary e-mails Snort generates to an “outside” (non-local) e-mail address.
We reconfigure Exim with the command:
dpkg-reconfigure exim4-config
Press Enter at the configuration information screen. On the configuration selection screen, because Snort won’t be receiving any mail, select the “mail sent by smarthost; no local mail” option.
Next it asks for a “system mail name”. This should have the same domain name as your e-mail address. For example, if your e-mail address is fred@flinstone.com then your system mail name should be something like debian.flintstone.com (the first part of the name should be the hostname of your server and the second part would be your, or your ISP’s, domain). Again, because no one should be trying to send e-mails to your Snort server, it shouldn’t matter that your server’s name isn’t in your ISP’s DNS.
Accept the default 127.0.0.1 address for an incoming SMTP connection.
On the “other destinations” screen, backspace everything out of the field (so it’s blank) and tab to OK and hit Enter.
Because you used your ISP’s domain name you can just accept the default value for the “visible domain” value.
In the “outgoing smarthost” field, backspace out whatever is there and enter the name or IP address of your ISP’s SMTP server (the same SMTP server you have entered in your e-mail client program (Thunderbird, Outlooks, etc.).
Accept the default ‘No’ to keeping DNS queries minimal and hit Enter.
Accept the default ‘No’ to splitting the configuration files and hit Enter.
Exim will then restart automatically with your new configuration.
Since day one you needed to use an ID (your e-mail ID) and password to access your received (POP) e-mail messages. These days more and more ISPs are starting to require those same credentials to send (SMTP) e-mail messages. If your ISP requires SMTP authentication you’ll need to edit an Exim file to supply those credentials. Enter the command:
nano /etc/exim4/passwd.client
and enter an asterisk, your e-mail login ID, and your e-mail password, separated by colons, like so:
*:billgates:loveslinux
Exit the editor saving the changes. Snort can now use Exim as an e-mail client to send the daily summaries. Don’t be surprised if you don’t get any e-mails. Snort will only send them when it’s detected suspicious traffic. If you don’t see any stats on the graphs on the BASE home page, you won’t get any e-mails.
| Managing Rules | |
By design, the /etc/snort/snort.conf configuration file holds all the rules Snort will use for traffic comparisons. While this is logically the case, it is not physically true.
If you open the /etc/snort/snort.conf file in a text editor and page down to section 6 and read the comments. Below the comments you’ll see a bunch of include statements where various rule files (located in the /etc/snort/rules directory) are included into the configuration file. The actual rules themselves are not entered directly into the configuration file to simplify management. Note that the include statements that have a pound symbol (#) in front of them are the disabled rules. (Note that you can disable rules by disabling an entire rule file inthe /etc/snort/snort.conf file, or by disabling individual rules within a rule file as you will see below.)
Any rule files that start out with the word community are rules written by Snort users. They do go through a couple checks by the Snort team to make sure they won’t break your Snort installation, but they don’t get the same scrutiny as those rules written by the Snort team. As you’ll see in the configuration file, quite a few of these community rule files are enabled by default. If you’re getting a lot of false alerts related to a specific application, you may want to try disabling the community rule file in Snort’s configuration file as a first step and then try and narrow it down.
If you want to play around with editing or customizing rules, always make a backup copy of the original rule file before you start making any changes. This will make it easy to restore the default operation should an errant rule change hose things up.
If you want to create your own rules from scratch, add them to the local.rules file. This file is empty but included by default. Make sure to give your own rules a SID (see below) of 1000000 (one million) or higher.
The rule files are text files so you can open them up in any text editor. For example, open one of the rule files with the command:
nano /etc/snort/rules/web-iis.rules
If you page down you’ll see that the individual rules all start with the alert keyword. Quite a few rules have a pound (#) character in front of alert to comment them out to disable them. (You can comment out individual rules in a rule file or you can comment out an entire rule file in Snort’s configuration file.)
If you cursor down to a rule and arrow to the right eventually you’ll see the SID keyword. Each individual rule has it’s own unique SID. As you’ll see below, if you ever modify a rule, you’ll want to make note of its SID.
Full article:
Linux Security Blog 