Section 9.5. Turning off Nonessential Services

9.5. Turning off Nonessential Services

One step beyond using your firewall to restrict access to services is to turn off services themselves if they don't need to be running: a service can't be compromised if it isn't turned on! In this section, you'll see which network services are running in a default Fedora Core installation, and how to turn them off if you don't need to use them.

To configure the services that start automatically when the server is booted , open the Service Configuration tool (Applications > System Settings > Server Settings > Services) and make sure the tool displays the configuration for runlevels 3, 4, and 5 by selecting Edit Runlevel > Runlevel All . All the services running on the machine are displayed; note that not all of these are network services. Click on a service to see a brief description of it. Fedora Core ships with a lot of services that, for security reasons, are disabled by default, which makes your job here an easier one.

For example, if you're not using NFS to make files available over the network (if you're not sure what this means, then you're probably not using NFS!), you can safely disable the NFS services portmap , rpcgssd , rpcidmapd , and rpcsvcgssd . NFS is used to share files between Linux and other UNIX-like machines. Similarly, if you're not using Samba to share files (usually with Windows machines), you should disable Samba's smb service.

If you prefer, you can also disable and enable services from the command line using the chkconfig command . For instance, to disable the smb service, enter:

[root@swinetrek kermit]#

/sbin/chkconfig smb off

[root@swinetrek kermit]#

To enable the service, use:

[root@swinetrek kermit]#

/sbin/chkconfig smb on

[root@swinetrek kermit]#

The chkconfig --list command displays a list of all the services on the machine, showing whether each is enabled or disabled.

9.6. Snort

Snort 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 Snort

Snort 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 Snort

The 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)

###################################################
# Step #1: Set the network variables:
#
# You must change the following variables to reflect your local
# network. The variable is currently setup for an RFC 1918 address
# space.
#
# You can specify it explicitly as:
#
# var HOME_NET 10.1.1.0/24
#
# or use global variable $<interfacename>_ADDRESS which will be 
# always initialized to IP address and netmask of the network 
# interface which you run snort at.  Under Windows, this must be 
# specified as $(<interfacename>_ADDRESS), such as:
# $(\Device\Packet_{12345678-90AB-CDEF-1234567890AB}_ADDRESS)
#
# var HOME_NET $eth0_ADDRESS
#
# You can specify lists of IP addresses for HOME_NET by separating
# the IPs with commas like this:
#
# var HOME_NET [10.1.1.0/24,192.168.1.0/24]
#
# MAKE SURE YOU DON'T PLACE ANY SPACES IN YOUR LIST!
#
# or you can specify the variable to be any IP address like this:

var HOME_NET any

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)

###################################################
# Step #1: Set the network variables:
#
# You must change the following variables to reflect your local 
# network. The variable is currently setup for an RFC 1918 address
# space.#
# You can specify it explicitly as:

var HOME_NET 192.168.1.0/24

# or use global variable $<interfacename>_ADDRESS which will be 
# always initialized to IP address and netmask of the network 
# interface which you run snort at.  Under Windows, this must be 
# specified as $(<interfacename>_ADDRESS), such as:
# $(\Device\Packet_{12345678-90AB-CDEF-1234567890AB}_ADDRESS)
#
# var HOME_NET $eth0_ADDRESS
#
# You can specify lists of IP addresses for HOME_NET by separating
# the IPs with commas like this:
#
# var HOME_NET [10.1.1.0/24,192.168.1.0/24]
#
# MAKE SURE YOU DON'T PLACE ANY SPACES IN YOUR LIST!
#
# or you can specify the variable to be any IP address like this:
#
# var HOME_NET any

Next, open the file /etc/sysconfig/snort and locate the following section:

/etc/sysconfig/snort (excerpt)

# How should Snort alert? Valid alert modes include fast, full, 
# none, and unsock.  Fast writes alerts to the default "alert"
# file in a single-line, syslog style alert message.  Full writes
# the alert to the "alert" file with the full decoded header as 
# well as the alert message.  None turns off alerting. Unsock is
# an experimental mode that sends the alert information out over a 
# UNIX socket to another process that attaches to that socket.
# -A {alert-mode}
# output alert_{type}: {options}
ALERTMODE=fast

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 Snort

Snort 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)

[**] [1:807:11] WEB-CGI /wwwboard/passwd.txt access [**]
[Classification: Attempted Information Leak] [Priority: 2]
10/26-02:47:33.815036 192.168.69.36:5335 -> 192.168.69.28:80
TCP TTL:128 TOS:0x0 ID:2463 IpLen:20 DgmLen:564 DF
***AP*** Seq: 0x7DC78CE4  Ack: 0xAC48865C  Win: 0xFFFF  TcpLen: 20
[Xref => http://cgi.nessus.org/plugins/dump.php3?id=10321]
 [Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=1999-0954]
 [Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=1999-0953]
 [Xref => http://www.securityfocus.com/bid/649]
 [Xref => http://www.whitehats.com/info/IDS463]

This is all rather overwhelming, so let's take a closer look, line by line.

/var/log/snort/alert (excerpt)

[**] [1:807:11] WEB-CGI /wwwboard/passwd.txt access [**]

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)

[Classification: Attempted Information Leak] [Priority: 2]

{% if main.adsdop %}{% include 'adsenceinline.tpl' %}{% endif %}

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)

10/26-02:47:33.815036 192.168.69.36:5335 -> 192.168.69.28:80

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)

TCP TTL:128 TOS:0x0 ID:2463 IpLen:20 DgmLen:564 DF
***AP*** Seq: 0x7DC78CE4  Ack: 0xAC48865C  Win: 0xFFFF  TcpLen: 20

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)

[Xref => http://cgi.nessus.org/plugins/dump.php3?id=10321]
 [Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=1999-0954]
 [Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=1999-0953]
 [Xref => http://www.securityfocus.com/bid/649]
 [Xref => http://www.whitehats.com/info/IDS463]

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 Email

One 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

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/

# run-parts
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly

32 3 * * * cd /usr/local/snortalog_v2.3/ && ./snortalog.pl 
    < /var/log/snort/alert  sendmail root@localhost

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 Reporting

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