Tony Perez On Security, Business, And Life
The last few posts have been about deploying and configuring OSSEC as an important tool in your security suite. In this article I will provide you a script I wrote to help you quickly deploy OSSEC.
This script assumes you are deploying on a Linux distribution (e.g., Fedora, Ubuntu, CentOS, or Debian). It will force you to choose a distribution OS before it runs, this ensures it installs the appropriate dependencies based on the distribution type.
The previous OSSEC articles went through through the process of installing OSSEC and deploying a distributed architecture. This article will focus on configuring OSSEC to make better sense of WordPress activity.
WordPress is a powerful open-source Content Management System (CMS). Its biggest security weakness has always been its biggest blessing – its extensibility (e.g., plugin, themes, etc…). The years at Sucuri have taught me that post-compromise there is nothing more important than have good logs. They are the key to understanding what happened. They are also the key to identifying a bad actors intent before their actions materialize into something nefarious.
Fun fact: The premise of the Sucuri Security plugin was almost exclusively for this visibility. Over the years we added more features to accommodate a more robust application security toolset, but that was always a secondary objective. In fact, the premise of the Sucuri plugin was actually built based on the lessons Daniel learned with OSSEC.
This article assumes you already have OSSEC deployed. If you need a refresher, refer to the Part I of OSSEC for website security, written March 2013.
OSSEC is popular open-source Host Intrusion Detection System (HIDS). It was founded by Daniel Cid, and currently maintained by a very large community of security professionals. Please note that I don’t my installations off the official repo, instead I run directly off Daniel’s repo (instructions in the last post).
In the following series I’m going to share the foundational elements of my OSSEC deployments. We’ll start by placing emphasis on the importance of deploying a distributed architecture in this article, making use of the Agent / Manager options. In future articles you can expect insights into the best way to configure for CMS applications like WordPress, tuning the engine to make use of the alerts, and notifications.
If you have questions, don’t hesitate to ask.
This a quick post, for those of you that manage multiple agents under your manager, there might be instances where your email notifications will group different agent notifications together.
This has to do with two things:
By default, OSSEC has a max email setting in their configuration, when it reaches the max, it will then group and email all remaining emails. In this instance, it bundles them all together, which leads to different messages from different agents being bundled.
I recently saw some discussion in the OSSEC distribution list of someone having an issue with getting OSSEC
If you’re familiar with OSSEC, then you know syscheck, if you’re not then this section will get you caught up – I hope.
Syscheck is the integrity checking daemon within OSSEC. It’s purpose is simple, identify and report on changes within the system files. The way it works is simple, when you first install OSSEC it runs an initial syscheck scan, this scan will go through and capture the check sum of every file on the system (every file you have identified in your configuration file – /var/ossec/etc/ossec.conf). Once the baseline is set, syscheck is able to perform change detection by comparing all the checksums on each scan. If it’s not a 1 for 1 match, it reports it as a change. If new files are added, it identifies it as new, and reports it.
Simple, right? Right…
I was playing with OSSEC HIDS
Error: PostgreSQL client libraries not installed.
I was a bit frustrated with it, it seems as it if requires both MySQL and PostgreSQL to be installed to finish compiling. To get around this just install PostgreSQL that seems to do the trick.
OSSEC HIDS
Being that my focus is on website security my employment and utilization of the product will be as such. I won’t talk much to the configuration and monitoring of large scale enterprises, but will likely get into large n-tier implementations of web enterprises. This could include the utilization of load balancers, web servers and database servers, and possibly some storage devices. Pretty straight forward stuff.
So naturally, as of late, I have found myself doing more than I probably need to on my servers and in the process causing more headaches then required. One of those issues has been with the communication between my agents and the mother-ship (command control) server with my OSSEC installs. For more details information, be sure to check out the OSSEC Host-Based Intrusion Detection Guide
The first thing to understand is how to check the status of your agents and easiest way to do that is running the following on the server install (my mothership):
# /var/ossec/bin/agent_control -lc
This will list out all your agents and if they are active it’ll read Active. If they are inactive, they don’t read inactive unfortunately, they just don’t show up.