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.

On BreachyBytes we most frequently focus on network security for enterprise networks. However I did stumble across an interesting article on Continuity Central that did a nice job breaking down the top ten threats to small and medium-sized businesses. Although these points are relevant to smaller businesses I think that many are applicable to large enterprises and home users as well. Here is their list:

1. Insiders
2. Lack of contingency plans
3. Unchanged factory defaults
4. The unsecured home
5. Reckless use of public networks
6. Loss of portable devices
7. Compromised WebServers
8. Reckless web surfing
9. Malicious HTML e-mail
10. Unpatched vulnerabilities open to known exploits

Read the article for more information.

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.

There is a lot of talk right now about security for virtual machines. My post from last week was about a company generating NetFlow data from virtual switches. Now at least two significant efforts are being announced at RSA. First, Solera Networks is releasing a free beta of a virtual network tap. Their premise is that buying virtual equivalents of IDS, IPS, etc is wasteful and expensive to enterprises. The virtual tap interfaces with Solera’s line of packet capture devices and closes the gap in network visibility in virtual environments. This approach seems stronger than Montego’s approach (NetFlow only). Solera provides the entire packet stream allowing you to do pretty much anything.

The second big announcement is from IBM, who is announcing “Phantom”, a hypervisor security layer.  This layer will let admins in virtual environments lock down the virtualized environment outside the VM instances allowing a single point of configuration to lock down a host of virtualized servers or clients. This will be a technology to keep an eye on in the coming months.

As usual, the security industry is catching up with a technology (this time around VM) that has been around for a considerable amount of time. This attention to virtual environment security is welcome but as usual a bit late in the game. The securtiy industry  is still not keeping pace with technology advances. I don’t expect it to catch up anytime soon.

Most of my posts on BreachBytes are about using flow data, primarily NetFlow, for network security, incident response and network forensics on enterprise networks. I also tend to get rather technical most of the time. For this post I want to take a step back and answer the following question: what’s the big deal about network flow data? Let me try to answer this question in a single sentence:

“Network flow data, which can be generated by all enterprise routers, provides security analysts with real-time, long-term network visibility that can be used to prevent data leakage, defend against the insider threat and enhance incident response effectiveness.”

Key Points:

1. Generated by all enterprise routers: The technology is in place, your network can generate flow data in some form.
2. Real-time: Flow reporting can be near-real time depending on configuration.
3. Network visibility: Most enterprises are essentially blind to their internal network (the Soft Gooey Center — good in candy, bad in networks).
4. Long-term: Disk is cheap and flows are small, while still providing adequate information for a variety of network security tasks.

(more…)