Security Considerations with Snort

Even though you are using Snort to improve your security, making sure that your Snort system is as secure as possible will make the data trustworthy. If someone breaks into your Snort system, there is no reason to trust the alerts it sends, thereby making the system completely useless until you wipe the disks and reinstall everything.

Snort Is Susceptible to Attacks

With that said, a typical Snort installation is subject to attacks. Why? You'll want to get in remotely (SSH) and you'll probably want to store the alerts in a database (MySQL or Postgres). In addition, you'll probably want to view the alerts with a spiffy interface that might require a Web server (Apache or IIS).

Based on this scenario, you will have several ports open on your Snort system: SSH (port 22), HTTP (port 80), HTTPS (port 443), and possibly MySQL (port 3306) or Postgres (port 5432). Now, anyone with access to a network can use NMAP and portscan your sniffer directly on its non-promiscuous interface. This makes your Snort system just like any other application, so stay on top of security vulnerability announcements and OS security announcements.

This is something that needs to be addressed because all of the preceding applications have had quite a few serious security issues, even as recently as last year (2002). In addition to making sure that your applications are up to date, you need to make sure that your kernel is configured properly and also up to date. You didn't think that running Snort allows you to disregard basic system administration practices, did you?

Note

All applications end up with some discovered vulnerability; however, Snort's are minimal. For a security application, SSH seems to have the lead on the amount of security vulnerabilities discovered.

Snort, however, has very few in its few years of existence. It's nice to see a security application practice good security. The Snort core has never had a network-based vulnerability, excluding a DoS attack if Snort was configured in a nonstandard manner. Third party plug-ins can be vulnerable, but they aren't part of the Snort core, which helps keep Snort itself secure. Table 29.2 lists Snort's vulnerabilities to date.

Table 29.2: Snort's Vulnerabilities to Date

Version	Vulnerability	Fixed
1.8	Snort dumps core. This was a bug in the stream preprocessing.	1.8.1
Prior to 1.8.1	Unicode HTTP encoding to IIS can be used to bypass Snort.	1.8.1
1.8.3	DoS attack from incorrect ICMP handling.	1.8.4
1.8.6	State problems were generated by fragroute.	1.8.7 beta1
1.9.0 and earlier	Buffer overflow in the RPC preprocessor plug1.9.1	2.0

Securing Your Snort System

Even though your Snort implementation is locked down, your system itself might not be. Make sure you do the basics. There are some things you need to do; no excuses:

• Turn off services you don't need. Services like Telnet, the Berkeley R services, FTP, NFS, and NIS should not be running on your system. In addition, make sure you don't have any unnecessary services running, for example, echo, discard, and chargen.

• Maintain system integrity. Tripwire is a freeware application that checks for those backdoors and Trojans you don't suspect. There are plenty of other freeware applications like Tripwire—AIDE and Samheim are two worth mentioning.

• Firewall or TCP Wrap the services you do use. Services like SSH and MySQL should be TCP wrapped or firewalled, as they have their own security holes as well. For services that you can't TCP Wrap, such as Apache, make sure you have it configured as securely as possible. IPTables is the latest version of the Linux firewall, and there are plenty of references on how to implement it.

• Encrypt and use public key authentication as much as you can. You should enable public key authentication only for OpenSSH. You might want to consider using Apache-SSL for viewing Apache logs and using digital certificates for client-side authentication. This helps keep the obvious people out of your system through the usual vulnerable channels.

• Patch, patch, patch. We cannot stress this enough. Make sure you keep your patches and packages up to date as much as possible. Stay on top of applications you use and their security announcements—the same goes for any operating system you use. For FreeBSD/NetBSD/OpenBSD, make sure you keep your ports and packages up to date. For Red Hat Linux, make sure you stay on top of the updated RPMs. For those of you who are using Debian, you'll have the easiest time as long as you remember to run apt-get update && apt-get upgrade on a regular basis.