Recently, I presented you with a network-based security suite called BackTrack. Most of the tools presented with BackTrack are classified into network-based Intrusion Detection Services (IDS). This time, I'll concentrate on the other side of the fence and discuss the host-based side of intrusion detection with a great open-source tool.
What Is OSSEC HIDS?
Host Intrusion Detection Services (HIDS) detects possible security flaws and threats at a host level. OSSEC not only scans all those log files, checks file integrity, and performs rootkit detections, but also provides for active response based upon results from the aforementioned. OSSEC can scale from local installation on one server or host machine to installation on every machine on your network as it can be configured to run in a server-to-client environment. Clients can then forward events to a centralized server, which analyzes the results and determines whether action should be taken either with active response or with simple email alerts to your account or pager.
Since OSSEC is well-documented, I won't cover installation instructions. Instead, I'll point you to the Web site, explain the installation order (which is important in a server-to-agent setup), and explain the many options it offers. If you simply want to see what OSSEC can do for you, I suggest choosing a local installation, which will give you the chance to explore the software without worrying about the fuss of setting up a server and agents.
Installation
OSSEC agents run on Linux and Windows, which makes it perfect if you have a mixed environment. If you choose to run it on Windows clients, however, a Linux server is required since only the agent is supported on Windows.
To quickly get going, you can visit the Web site's getting started section, which walks you through installation. If you're installing OSSEC with the server-to-agent setup, it's important that you install a working server before you load the agents. All OSSEC communications between the server and agents are encrypted, so you must create authorization keys on the server side, which will need to be transferred onto the agents during installation. For a client installation, the only information necessary is the IP address of the OSSEC server and the authorization credential key.
Configuration Options
Once OSSEC is up and running, one main configuration file (ossec.conf) offers many options split into various sections and is located where you choose (the default is /var/ossec). The global section allows for things such as email notifications, SMTP settings, and alerting levels defined from 0 (least important) to 16 (most important). Inside the syscheck elements, you'll find options to include or remove directories on the system to perform checksums, check ownership and permissions, and check frequencies, among other things. Other sections to take note of are the following elements: rootcheck, alerts, localfile, remote, and client options.
Rules
In the root of your installation (/var/ossec on mine), you'll find a rules directory containing 32 rules in the form of XML files. These include rules for Apache, FTP, IMAP, NAMED, PAM, Postfix, Sendmail, SMB, SSHD, and many more. Open up the syslog_rules.xml file and take a look:
core_dumped|failure|error|attack|bad|illegal|denied|
refused|unauthorized|fatal|Segmentation Fault|Corrupted
Rule 1001 checks the /etc/securetty file. On a Linux system, this file lists what TTY devices root can access. The section declaring what the BAD_WORDS are references rule number 1002. If any of the strings match this rule, the system will generate a level 7 alert and pass it along up the chain. Rule 1003 searches for messages that seem abnormally large in size. These are examples of only a few rules in the syslog_rules.xml file.
OSSEC is highly customizable in that it offers the ability to add rules to the already long set of rules included. Although much work is already done to provide complete rule sets, feel free to write your own rules. For example, you can create rules to set frequencies of specific events before alerting will occur (e.g., alert only if condition X fails within a set amount of time). Check out the rule option sections for a long list of values if the default sets aren't what you're seeking.
Active Response
OSSEC allows you to automatically respond to events or series of events, providing timely active response. This can be anything from a simple alert to a command script you write yourself. For example, if you notice a port scan occurring, you could close it off.
While this might seem like a very good idea, some risks are involved. If the attempt to access the system or services is legitimate and OSSEC reports it as malicious, then you've just blocked yourself or a user out of the resource requested. Also, if intruders somehow discover active responses are being used, they could launch a possible denial of service (DoS) attack, locking you completely out of your own systems.
By default, the tool comes with scripts to automatically add IP addresses to the /etc/hosts.deny file, automatically drop users with firewall rules, and completely disable accounts. These powerful examples of the active responses you can add to your system are located in the /var/ossec/active-response directory. Create new scripts, place them here, and salt to your taste.
Monitor Away
When you decide to set a system up, make sure you assign a server and only one or two clients while you learn. At first, OSSEC is so excessively verbal (as it's designed to be), you'll get sick of receiving email alerts (if you've set up notifications) until you customize alerts to your liking. By default, if file integrities change on a predictable schedule, the system ignores that file after three changes. An instance of this would be anti-virus software in which files change once or twice daily. Remember that you can add anything you'd like to ignore to the configuration file.
Regardless of your skill level, OSSEC presents ease of use to the beginner. And for the avid monitoring junkie, it offers highly customizable options and scalability to include host intrusion detection on your networks.
Max Hetrick is a PC Support Analyst/Specialist who holds a certification as an MCSA. He also has experience with installation and maintenance of Linux operating systems from the PC to server levels. Max can be reached at
LATEST COMMENTS
MC Press Online