6.4 Securing the Sensor Itself

It should be obvious that protecting the integrity of the systems responsible for monitoring and maintaining the security of your network is very important. You need to protect the integrity not just of your NIDS systems but of your syslog servers, authentication servers, monitoring, and management tools. One strategy that I employ is a management network. This network is behind its own firewall and access to the systems contained within the management network is closely controlled. The systems inside do not even participate in the same authentication domains as the systems on the inside of the network. The only openings in the firewall are those that are needed to get monitoring traffic to the systems that watch the environment.

Closely managing the Snort systems is important. The operating systems should be configured according to industry-accepted best practices and should be kept up-to-date with patches and updates. After all, a compromised IDS sensor would have access to all the traffic to and from your most sensitive systems—a dangerous situation, to say the least.

6.4.1 Choose an Operating System

I squirm uncomfortably when people ask me what operating system they should use for a particular function. I carefully try to avoid discussions about religion, politics, and operating systems—all for the same reason. They're too controversial. However, I will briefly put on my consultant hat and walk you through the process of deciding which operating system to use for your Snort sensor.

I started my Information Technology career doing Microsoft phone tech support for the launch of Windows 95. My background in modems and networking (Commodore 64, 300 baud modem at the beginning of things) quickly got me into a mentor role. My MCSE certification was first in NT 3.51. I consider myself a Windows expert. That said, about five years ago I discovered Linux and BSD. I liked the fact that I could strip the system down to just the services I wanted. It made administration much easier (and the side effect was better general security). I hated the fact that my Windows servers needed to be rebooted all the time to keep them running. Linux had outstanding uptime.

Now, if I build a system, it's a Linux box (RedHat or Suse are nice) more often than not. My desk at work has three systems: a Windows XP laptop, a Suse Laptop, and a FreeBSD server. At home I have a Debian server (my mail server), a Suse linux server (test box), a FreeBSD server (Web Server), and a Windows gaming system. I spend about 60% of my time in a Unix-based environment of some sort. If I am going to build a server, it will be either Debian or FreeBSD, since I can build a minimum configuration and keep it up to date very easily. (I really like FreeBSD, but my company has standardized on Redhat as a Linux server OS). The recent changes in Suse are pretty exciting, too.

I share this information to give you a frame of reference for my approach to choosing an appropriate operating system. There are several things to consider; supportability, performance, stability, and security are at the top of the list:

Supportability

Very often, the decision of which operating system to use is based on what you know how to run. Choose an operating system that you know how to configure and maintain effectively. If you know Windows well and little or nothing about Linux, use Windows! I'm speaking about a Snort system that will be relied on to secure a network. If you are just playing or testing, installing and configuring Linux or FreeBSD Snort sensor might be a nice way to learn a new OS. Most of the web resources dedicated to running Snort lean towards a Linux-based installation. It is arguably easier to "strip down" a Linux or BSD system—Windows installs a lot of things you just don't need.

Performance

It is generally accepted (and I'm opening a real can of worms here) that the network stack on Linux and BSD is faster than the Windows network stack. In my experience, it seems that a Linux sensor can watch higher bandwidth levels than Windows using a given configuration. This makes sense when you consider that Snort (and the underlying infrastructure of libpcap) is written for a Unix-based operating system.

Stability

It used to be an easy argument that Linux and BSD were much more stable than Windows. That really isn't as true anymore for a well configured and patched Windows system. I would still argue that a competently administered Unix-based operating system has better uptime compared to Windows (email me with your arguments). When considering stability, you may find yourself going back to the supportability issues.

Security

I can lock down and secure a Windows system as well as I can lock down a Linux or FreeBSD system. The problem is, it has been much (much!) more work to keep a Windows system secure over time. The number of patches released for Windows services has been nearly overwhelming. There have certainly been patches for other operating systems and Unix-based services. However, there have been fewer in general, and since Unix-based operating systems tend to run fewer services, there is a smaller chance that you will be affected by a particular vulnerability. For security-related tasks, I tend to migrate to Linux or BSD over Windows.

6.4.2 Configure Interfaces

Along with the creation of a controlled management network, there are more steps to be taken to protect the integrity of your security systems.. Snort sensors should be configured with at least a pair of interfaces. One of these interfaces will be on the management network; all alerting and management traffic will use this interface, keeping it away from prying eyes. Snort will use the other interface as a monitoring point. This interface will not be configured with an IP address, so it will be invisible to hosts on that network. This is commonly referred to as a stealth interface. Keeping the listening interface invisible to the other systems on the network makes keeping the sensor secure much easier.

We discussed using SPAN ports in a switched network to allow the monitoring of switched ports. SPAN ports can actually help hide your Snort sensors, since they can be configured to only transmit traffic from monitored ports and not listen to interfaces plugged into them.

6.4.3 Disable Unnecessary Services

If a service is not needed for the business function of a server, it should not be installed or enabled. The fewer services running on a system, the fewer potential issues need to be secured and kept up-to-date. This is an essential step to making a system secure.

6.4.4 Apply Patches and Updates

These days, there are always updates and patches that need to be applied to the operating system and services—especially on a freshly installed system. This is true no matter what operating system you use. As time goes by, it is important that administrators keep abreast of newly discovered vulnerabilities in their operating system and services. If possible, establish a maintenance window for when updates will be made to your systems. This will allow you to establish a change routine—notify necessary people that the system will be unavailable, test the updates on a test system, and establish a back-out plan so that if the change blows up, you can go back to the initial system state.

6.4.5 Utilize Robust Authentication

Where possible, use stronger authentication than just a simple username and password. The weaknesses inherent in passwords are well-documented. Passwords can be attacked through dictionary attacks or simple brute-force. If you do need to use passwords, utilize mechanisms (varies from operating system to operating system) that enforce passwords of a certain length and complexity. Force the users to pick different passwords by remembering the last few they've used. Force the passwords to be changed periodically (every 60 days or so). Most importantly, configure the authentication mechanism to lock out the account after a certain number of consecutive failed password guesses (I prefer locking the account after five failed guesses).

If you can, employ a stronger mechanism for authenticating users (it's not possible in most environments). Smart cards (and PKI), one-time password generators, or biometric mechanisms are excellent choices.

I do have some reservations about biometric authentication. While very convenient and certainly better than passwords, this method has one serious flaw. When someone loses their smart card or one-time password-generating device, the old one is marked as revoked in the authentication system and a new card or mechanism is issued. If someone intercepts or finds a way to decipher the digital representation of a biometric authentication, how can I revoke a thumb or a retina?

6.4.6 Monitor System Logs

It is very important that the system is configured to generate logs and that those logs are reviewed regularly for signs of system, hardware, or configuration problems (including signs of intrusion). Auditing authentication, system function, and hardware operation is a good place to start. If possible, send the logs to a central syslog server (hopefully located on your controlled management network). This makes it much easier to review the logs and establish some correlation of events across multiple systems and networks.