|< Day Day Up >|
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:
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.
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.
|< Day Day Up >|