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.
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.
Regardless of the size of your organization, the security challenges with open-source Content Management Systems (CMS) security are the same. In the enterprise the issue stems not from the technology or existing processes, but the fact that security is slipping through our fingers. We’ve made it too difficult for our counter parts in marketing and sales, and where there is a problem new solutions step in to solve them. We see this being enabled by the explosion of cloud platforms like Platform as a Service (PaaS), Software as a Service (SaaS) and technologies that easily work in those environments like open-source CMS applications.
As a community we have to do something about this. These activities stem from the perception that IT / Security is always going to say “no” or “make my life too hard” and I can’t help but think there is a better way to handle this. To do this, we have to be prepared to embrace technologies like open-source CMS application and be willing to silence our personal biases towards them (i.e., WordPress is insecure, which is grossly untrue). A good first steps is better understanding how these technologies might fit into existing governance and their associated security policies and tools.
Open-source CMS web applications are no different than any other applications enterprise security teams are responsible for. The principles like Defense in Depth still apply, and integrating things like Prevention, Detection and Response solutions are just as critical. The difference being that in the enterprise, these aren’t new concepts, yet when it comes to open-source CMS applications they’re dismissed.
Compromises within the open-source CMS domain are achieved through two key areas: access control and exploitation of software vulnerabilities. Here are a few tips to help enterprises think through the security challenges they face:
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…