BreachBytes

The OSSEC project is one that I have been familiar with for a while but have never had the time or energy to properly evaluate for myself. I even made its installation an option for a lab in a network security tools course I taught but I never had the time to sit down and look carefully at the system.

I started my installation with a Ubuntu 10.4 server that was hosting a Subversion repository and little else. My first step was clicking my way through several links to finally get to the installation instructions I needed. Don’t bother with the Getting Started page; it won’t get you started. Its more of a feature list and overview. The First Steps page is a better place to go. Scroll down to Install It and click on Installation guides page. Finally some instructions!

These are adequate instructions but do not mention that if your system doesn’t have gcc and make it won’t work as the system must be built from source. I found this tutorial for installing OSSEC on Ubuntu 9 and had no further problems completing the install. The OSSEC installation materials could be improved by incorporating some of the additional information found that tutorial.

In most cases OSSEC is deployed on multiple servers within an organization. The system, a Host-based Intrusion Detection System (HIDS), monitors only a single host. In my case I only had one host to monitor so this part of my setup was complete. In a real network setting the system administrators would have to install the software on every server. This is non-trivial for very large networks with diverse server types – many of which will not have the build tools installed to compile the software.

Once I got my new HIDS installed it was time to start the service. A simple shell command starts the HIDS: ‘/var/ossec/bin/ossec-control start’. That was it! Pretty soon after starting the service I started getting email alerts of people trying to log into the machine via ssh connections from obvious account names like root, testing and admin. Here’s an example:

OSSEC HIDS Notification.
2010 Aug 09 17:13:16

Received From: localhost->/var/log/auth.log
Rule: 5712 fired (level 10) -> "SSHD brute force trying to get access to the system."
Portion of the log(s):

Aug  9 17:13:15 localhost sshd[29833]: Invalid user webadmin from x.x.x.x
Aug  9 17:13:13 localhost sshd[29831]: Invalid user tomcat from x.x.x.x
Aug  9 17:13:11 localhost sshd[29829]: Invalid user samba from x.x.x.x
Aug  9 17:13:09 localhost sshd[29827]: Invalid user office from x.x.x.x
Aug  9 17:13:08 localhost sshd[29825]: Invalid user alias from x.x.x.x
Aug  9 17:13:06 localhost sshd[29822]: Invalid user recruit from x.x.x.x
Aug  9 17:13:04 localhost sshd[29820]: Invalid user sales from x.x.x.x

Next steps

In future posts I will go into installing the web interface and the usability and effectiveness of OSSEC.

An article written by my partner Ben Uphoff has been published by (IN)SECURE Magazine. Scroll down to page 68 for the full text of the article.

Ben has done a great job of outlining what it takes to perform effective incident investigation using Net/FSE for in-depth alert analysis. I’d like to outline some of the snippets from the article that support the point that network intrusions, breaches and incidents are inevitable and the only way to perform proper incident investigation is to “keep it all.”

A core belief at Packet Analytics is that despite the best efforts of security vendors and practitioners, incidents are inevitable. There are simply too many threats and too many angles of attack. Technology on enterprise networks evolves so quickly that it is nearly impossible to keep up with the ever-changing threat landscape. For this reason, network breaches and security incidents must be seen as part of doing business in a connected world. Enterprises can mitigate the risk of a breach by following best practices and preparing a comprehensive incident response and recovery plan.

One challenge with working with network event data is that you can never be sure what event information is relevant until after the fact. For example, enterprises did not see value in storing DNS logs until DNS exfiltration attacks started appearing. With no historical log of DNS activity, those that fell victim to such attacks had no way of definitively knowing the extent of the data leakage resulting from the breach.

Contrary to the “keep it all” approach, SIMs try to reduce data volume at the collection points by aggregating similar events into statistical summaries that are then fed into the correlation engine, losing potentially valuable information in the process. Summaries are useful for the correlation engine but not for deep analysis of network events

We look forward to starting a dialog on the “keep it all” strategy and how we can improve the effectiveness of security and network operations in performing Network Event Analysis. Please post a comment.

Incident response (IR) is a critical responsibility for network security analysts and system administrators. Anyone operating a network should have an incident response plan in place so that when a network breach occurs everyone involved knows their roles and responsibilities. If a plan is not in place (or nearly as bad, the employees have not been trained to execute the plan) a simple incident can quickly be blown out of proportion and cause damage to the reputation of the organization and its employees.

To most people, IR means a call to action when a new threat emerges or the network is breached (broken in to). Most people think of IR solely in this capacity but responding to an event or incident is too complex to lump into a single category. This article extends the IR concept by breaking the traditional “response” component into three separate areas:

1. Response: the initial set of actions taken by system administrators and security analysts to asses the situation and stop the incident from spreading.
2. Recovery: this step involves getting effected machines back online and returning to regular operations.
3. (Public) Relations: even after the incident is contained and corrected, there may be PR fallout from the incident. This step is overlooked almost universally.

(more…)