Section 9.6. Snort
9.6. SnortSnort is an Intrusion Detection System, or IDS. An IDS monitors incoming network traffic and looks for things that seem suspicious. For example, Snort will watch incoming Web requests and match those requests against its database of known vulnerabilities; if a request looks suspicious, it will record specific details in its log files. This can help you to detect a compromise quickly after it happens, and take immediate steps to fix the problem. 9.6.1. Installing SnortSnort isn't part of the Fedora archive, but it's available from the Snort project's Website. Follow the Download link, and look for the pre-compiled binary packages. At the time of writing, Snort is only available as an RPM package for Fedora Core 3, but this package installs fine on Fedora Core 4. While you're at the Snort Website, you should also download a set of Snort rules; there's a big orange link on the right-hand side of the download page. Snort rules are configuration files that tell Snort what to look for when it searches for evidence of intrusions. Three official rule sets are provided by Sourcefire , the company that maintains Snort: the subscription release, which contains the very latest rules, but requires a paid subscription; the registered user release, which contains the latest rules five working days after they appear in the subscription release, and only requires a free registration; and the unregistered user release, which is updated with every major release of Snort. There is also the "community rules" release, which contains rules that are contributed by the Snort user community, and have been only briefly tested by Sourcefire. Download the set of rules that you're most comfortable with. I'd recommend the registered user release. Note: Snort rules are being constantly updated by Sourcefire; you should check for new rules at least once a week. 9.6.2. Setting Up SnortThe Snort RPM installs Snort with a good initial configuration: you shouldn't need to change too much to have the program running usefully. It's possible to configure Snort in many different and complicated ways; the Snort manual and FAQ, available from the Snort project's Website, will help here. For the moment, we'll work with the default configuration, except for a couple of things. First, Snort needs to know where your local network is, so that it doesn't alert you to "suspicious" traffic originating from the local network. Also, we should set up Snort so that it uses its full logging mode to provide you with the most useful information it can. Open the file /etc/snort/snort.conf in a text editor and locate the following section: /etc/snort/snort.conf (excerpt)
This section of snort.conf defines your server's home network. Comment out the var HOME_NET any line, uncomment the var HOME_NET 10.1.1.0/24 line, and enter your local network's subnet, or the machine's IP address if it's not part of a local network. (A network administrator should be able to help here if you're not sure.) For example, if your subnet was 192.168.1.0/24, snort.conf should be edited as shown below. /etc/snort/snort.conf (excerpt)
Next, open the file /etc/sysconfig/snort and locate the following section: /etc/sysconfig/snort (excerpt)
After making a backup of the file, change ALERTMODE=fast to ALERTMODE=full. This will set up Snort to produce more output, which will adversely affect its performance. If you find that your server is running slowly, consider changing this setting back to ALERTMODE=fast. Finally, you'll need to extract the rules you've downloaded using the tar command: [root@swinetrek kermit]# tar -x -z -f \ > /home/kermit/Desktop/snortrules-snapshot-CURRENT.tar.gz \ > -C /etc/snort [root@swinetrek kermit]# Once you've configured Snort correctly, you can start the snortd daemon. 9.6.3. Using SnortSnort stores its logs in the /var/log/snort directory. Snort's default setup will log alerts in the file /var/log/snort/alert. Whenever Snort detects suspicious traffic, it writes a description of the traffic into the alert file. To perform a simple test of this, try to access http://servername/wwwboard/passwd.txt from a machine outside of your network. This should return a standard 404 Page Not Found error (assuming that you don't have wwwboard installed, that is!), but will cause Snort to log an alert . Now, return to your server, and look in /var/log/snort/alert. You should see a block of text that looks something like this: /var/log/snort/alert (excerpt)
This is all rather overwhelming, so let's take a closer look, line by line. /var/log/snort/alert (excerpt)
The first line is the key: it tells you what the suspicious activity involved. Snort has a rule that watches for HTTP requests for the file /wwwboard/passwd.txt, because a software package called WWWBoard contains a security hole that makes the password file publicly accessible. Since you tried to access that file, Snort logged the access attempt. You can see from the above line that the alert was triggered by a rule which is part of the WEB-CGI set of rules, which means that it was a potential attack on the Web server, or an application installed on the Web server. In this case, the attack was made on WWWBoard. If you don't have WWWBoard installed, you can rest easy: someone was trying to exploit a vulnerability in WWWBoard, but you are not vulnerable. /var/log/snort/alert (excerpt)
The second line of the alert explains what sort of alert it is; in this case, it is an "attempted information leak." Each Snort rule defines suspicious activity, then categorizes that activity. This was a "priority 2" alert, meaning "fairly serious." Priority levels range from 1 (potentially very serious) to 5 (not very serious at all). Again, though, it's only fairly serious if you have WWWBoard installed; Snort doesn't know whether you do or not, so it flags this as being, potentially, a fairly serious vulnerability. /var/log/snort/alert (excerpt)
The third line tells you when the attack happened, and where it came from. In this case, the attack happened on the 26th October (10/26) at 2:47 a.m. (02:47:33.815036), and it was made from IP address 192.168.0.100 (the first one listed), which should be the IP of the machine you used to make the test. This will allow you to work out whether you're being attacked repeatedly from one IP address; if you are, it might be worth using your firewall (see above) to block all connections from that IP address by adding a new rule that denies access to the service from that IP address. Since this example is an attack on your Web server, you could block access to port 80 from the IP address flagged in the alert (192.168.0.100) using Firestarter. /var/log/snort/alert (excerpt)
The fourth and fifth lines contain detailed network information, which may be useful to a network administrator. If you already understand that line, you'll know whether the information in it is useful in diagnosing the attack; if you don't understand this information, you may want to call in some network technicians in the event of an attack. These details are not usually all that useful, so it's not something that warrants too much worry. /var/log/snort/alert (excerpt)
Line 5 provides links to references to help you find out the details of the attack. Each URL that's listed explains the WWWBoard passwd.txt vulnerability, as you can see in Figure 9-11. Figure 9-11. The WWWBoard passwd.txt vulnerability explained. These descriptions should allow you to understand the nature of the vulnerability, and identify whether you are vulnerable to compromise. They'll also explain workarounds or solutions to prevent your continuing vulnerability. For example, the description of the WWWBoard vulnerability explains how it can be fixed: edit the wwwadmin.pl script to change the location of the passwd.txt file. Now that you understand what Snort stores in its alert file, you need to remember to check that alert file. The best Intrusion Detection System in the world is completely useless if, even though it detects intrusions, no-one notices that it's doing so. The primary way to check is simply to do what we did above: manually look in the file on a regular basis, and examine each alert to see if it represents a potential vulnerability. However, having to remember regularly to look at the file is boring, and boring tasks get forgotten. It's much better to set up a system explicitly to notify you of Snort alerts, rather than having to remember them yourself. 9.6.4.1. Setting up a Nightly EmailOne way to ensure that you're reminded is to have the system email you each night with details of any alerts that were logged in the previous day. While it would be nice to be alerted to a potential compromise the instant it happens, in practice, most system administrators are too busy to respond to an alert instantly. A daily email gives you the chance to review the alerts at a reasonable pace, and to take action to close off any security holes, without demanding your availability twenty-four hours a day. The Snort Website links to various data analysis tools. These take your raw Snort logs and uses them to create nice reports . For a simple nightly email, a good tool is snortalog. Download snortalog and extract it to /usr/local: [root@swinetrek kermit]# tar -x -p -f \ > /home/kermit/Desktop/snortalog_v2.3.0.tgz -C /usr/local [root@swinetrek kermit]# Running snortalog isn't difficult, but it does require that you change the working directory to /usr/local/snortalog_v2.3/. [root@swinetrek kermit]# cd /usr/local/snortalog_v2.3/ [root@swinetrek snortalog_v2.3]# ./snortalog.pl < \ > /var/log/snort/alert subject: IDS Statistics generated on Wed Oct 26 23:13:53 2005 The log begins at : Wed 26 09:58:27 The log ends at : Wed 26 22:58:42 Total of Lines in log file : 2330 Total of Logs Dropped : 0 ( 0.00%) Total events in table : 372 Source IP recorded : 5 Destination IP recorded : 21 Host logger recorded : 1 with 1 interface(s) Signatures recorded : 21 Classification recorded : 5 Severity recorded : 3 Portscan detected : 0 Version: 2.3.0 Jeremy CHARTIER, <jeremy.chartier@free.fr> Date: 2004/12/02 11:31:03 [root@swinetrek snortalog_v2.3]# This brief summary shows that 21 different types of suspicious traffic were identified by Snort between October 26th at 9.58 a.m. and October 26th at 10.58 p.m. The summary can then prompt you to dig further into the alert file itself, to identify what those different types of suspicious traffic were, and whether you need to do anything about them. To set the system up so that the report is mailed to you nightly, simply add an entry to /etc/crontab , as shown below. /etc/crontab
That line simply schedules the command abovewhich generated the summaryto run daily, and to email the results to the root user, whose mail is readable by you. Now you have a daily nudge to check the Snort logs if there seems to be a problem. 9.6.4.2. Further ReportingSome Snort data analysis tools provide much (much!) more comprehensive and detailed reports, and you may want to investigate these tools if you need to get further into this area. One of the best is SnortSnarf, which produces a detailed HTML report that considers the alerts in your Snort alert file from a variety of different angles, and makes it very easy to pore through your files and understand what the alerts indicate. Again, to expand SnortSnarf, use the tar command: [root@swinetrek kermit]# tar -x -z -f > /home/kermit/Desktop/SnortSnarf-050314.1.tar.gz -C /usr/local [root@swinetrek kermit]# Before you can generate a report, you need to install the Time::ParseDate Perl module . A Perl module is nothing more than a piece of code that can be used by many different Perl scripts. The most popular modules are hosted at the Comprehensive Perl Archive Network (CPAN) . Mercifully, the CPAN Perl module makes installing the Time::ParseDate module easy. [root@swinetrek kermit]# perl -MCPAN -e 'install Time::ParseDate' /usr/lib/perl5/5.8.6/CPAN/Config.pm initialized. CPAN is the world-wide archive of perl resources. It consists of about 100 sites that all replicate the same contents all around the globe. Many countries have at least one CPAN site already. The resources found on CPAN are easily accessible with the CPAN.pm module. If you want to use CPAN.pm, you have to configure it properly. If you do not want to enter a dialog now, you can answer 'no' to this question and I'll try to autoconfigure. (Note: you can revisit this dialog anytime later by typing 'o conf init' at the cpan prompt.) Are you ready for manual configuration? [yes] The first time you run CPAN, you'll be asked if you want to configure CPAN manually, or if you'd rather let it configure itself. Most of the time, CPAN's automatic configuration will work fine, so enter no: Are you ready for manual configuration? [yes] no The following questions are intended to help you with the configuration. The CPAN module needs a directory of its own to cache … Installing /usr/share/man/man3/Time::Timezone.3pm Installing /usr/share/man/man3/Time::DaysInMonth.3pm Writing /usr/lib/perl5/site_perl/5.8.6/i386-linux-thread-multi /auto/Time-modules/.packlist Appending installation info to /usr/lib/perl5/5.8.6 /i386-linux-thread-multi/perllocal.pod /usr/bin/make install -- OK [root@swinetrek kermit]# If you need to configure CPAN to use HTTP or FTP proxies, you can enter yes and go through the configuration process step by step. Generating a report is very similar to running snortalog. The Perl script will return some warnings, but these can safely be ignored: [root@swinetrek kermit]# cd /usr/local/SnortSnarf-050314.1 [root@swinetrek SnortSnarf-050314.1]# ./snortsnarf.pl \ > /var/log/snort/alert Using an array as a reference is deprecated at include/SnortSnarf/HTMLMemStorage.pm line 290. Using an array as a reference is deprecated at include/SnortSnarf/HTMLAnomMemStorage.pm line 266. [root@swinetrek SnortSnarf-050314.1]# Load /usr/local/SnortSnarf-050314.1/snfout.alert/index.html in your Web browser to see the full report, as shown in Figure 9-12. Figure 9-12. A SnortSnarf report. |
EAN: 2147483647
Pages: 92