Automated detection and response to attacks
Learn how to monitor and block attacks without lifting a finger.
One of the first things I learned about computer security was logging . If you don't have logs, then trying to reconstruct what happened when something breaks, or when you get broken into, is almost impossible. The second thing I learned was that you have to centralize your logging; this is the only way to get a complete picture and ensure that an attacker can't simply wipe the logs on a compromised host, leaving you nothing to work with. But none of this will alert you to an attacker or, even more importantly, stop an attacker from getting in. It will simply give you something to look at once you figure out you have been broken into. For this, you need a human being in the loop, right? Well, you either need a human being or some smart software.
Wouldn't it be great if you could monitor critical logfiles (like mail and web) and actually have something respond to attacks, notifying you and even blocking the attacker from further access if you so wished? Well you're not the only one. Daniel B. Cid is the lead developer of the OSSEC project, an effort to build an open source host-based intrusion detection system . OSSEC uses a traditional server and agent approach: You install the agent software on each system you want to monitor, and a central server collects all the data and sends out alerts. Additionally, the OSSEC project has released a web-based interface; however, it is only capable of reporting. Unfortunately, it can't be used to configure the system.
When installing OSSEC, you have three options. The server option allows you to have it monitor itself and collect alerts from other systems. The agent option simply monitors local events and fires anything interesting off to the server. The local option runs the monitoring locally and can send email alerts, but it does not listen for any remote agents (so if you have one server or want to test it, this is the option for you). Simply download the OSSEC package (ossec-hids-2.0.tar.gz") and unpack it to a directory:
# wget http://www.ossec.net/files/ossec-hids-2.0.tar.gz # tar -zxf ossec-hids-2.0.tar.gz # cd ossec-hids-2.0 # ./install.sh
Now you simply choose your language, your server type, and whether you want to run the integrity check daemon, run the rootkit detection engine, enable active response, and enable the firewall to block attacks. If you are setting the system up as an agent, you also need to point it to your server and paste in the agent key. The agent key is a long string used to secure communications between an agent and the server, preventing fake messages from being injected, and so on. Why is it important to prevent spoofed or fake messages from being sent to the server?
If an attacker can trigger fake or spoofed attacks and a system blocks IP addresses or users because of this, the attacker can easily block legitimate systems and lock users out. In a worst case scenario, you might have to break into your own system if your accounts are locked out, which is why most HIDS and NIDS support whitelisting (see the "HIDS vs. NIDS" box). Administrators simply create a list of hosts and networks that are critical. Of course, determining which hosts are critical depends on the exact setup (DNS, email, file servers, authentication servers, routers, etc. are all a good place to start). With OSSEC, the whitelist is held in the ossec.conf file (by default, this is kept in /var/ossec/etc/), and you can specify individual hosts or networks:
<global> <white_list>127.0.0.1</white_list> <white_list>18.104.22.168</white_list> <white_list>10.0.0.0/8</white_list> <white_list>192.168.0.0/16</white_list> </global>
HIDS vs. NIDS
Host-based intrusion detection systems (HIDS) are generally defined as applications that run on specific systems and monitor local logfiles, inbound network activity, and other items to detect hostile behavior. The advantage of HIDS is that it has deeper access to a system and can correlate local events easily (e.g., a web application error followed by a new user being added). The disadvantage of HIDS is that you must install software on each system you want to protect and manage many endpoints.
Network intrusion detection systems (NIDS) typically consist of one or more network-based sensors deployed at network choke points (such as firewalls) or attached to switches that are configured to replicate traffic to the sensor. The advantage of NIDS is that you can cover large portions of a network and network traffic with a minimal number of sensors. The disadvantage of NIDS is that you could miss internal attacks that don't cross monitored networks, and you can't see deeply into a system.
The OSSEC program comes with its own control program called ossec-control. Additionally, when installed on Red Hat Linux or CentOS, a standard set of rc.d/init scripts will be added, allowing the OSSEC services to be control through the standard chkconfig utility. When OSSEC is running, you should see a number of programs running.
The monitoring processes generally need to run as root:
USER PID COMMAND ossecm 17381 /var/ossec/bin/ossec-maild root 17385 /var/ossec/bin/ossec-execd ossec 17389 /var/ossec/bin/ossec-analysisd root 17393 /var/ossec/bin/ossec-logcollector root 17405 /var/ossec/bin/ossec-syscheckd ossec 17409 /var/ossec/bin/ossec-monitord
Buy this article as PDF
New release marks the arrival of AMD’s unified driver strategy.
A new study by IDC charts big changes in the big hardware market.
Azure CTO says Redmond has already considered the unthinkable.
Lead developer quells rumors that the Debian version is slated for center stage.
MSBuild is now just another GitHub project as Redmond continues its path to the light.
New rules emphasize collegiality in coding.
Upstart lands in the dust bin as a new era begins for Linux.
HP's annual Cyber Risk report offers a bleak look at the state of IT.
But what do the big numbers really mean?