I have a bad habit of providing articles here that either are filled with code/CLI/trickets of information, or doing a multi-part series on some topic. I love writing of Linux and the world around it, and my passion has been security for ages. There’s always that sense when I’m writing that there’s more to add or I should provide a bit more meat to a block. This time I’m going to change it around a little, though. Instead, I’m wanting to give an opinion piece on something that has really affected me lately, HIDS (host-based intrusion detection system), and their use. HIDS systems are one of those that you are supposed to set it and forget it, as well as one that a lot of people don’t seem to really take notice of. While they can serve different purposes, a lot share the same characteristics of monitoring the system for certain events and alerting people when something happens. Thus, any HIDS system can be broken down to 3 different components: Monitor the system Compare checksums Alert when a difference occurs That’s it. The field itself is pretty small, as well. You typically see them combined with other systems as well such as a NIDS/IPS or more on a low-scale purpose. There’s one popular system, OSSEC, that is supported by Trend Micro. While originally during the span of 2009-2011 I believe, it wasn’t updated very much, it really has been given a new path and taken more under constant control. It allows agentless (RPC-based), server/client and local set ups, and can also log to a database (which I advise against, and I’ll get to that in a little bit). Server/client is useful if you have multiple servers to monitor, while local is what you would choose to just monitor the machine that OSSEC resides on (i.e.: you have only 1 server and you want to monitor that). Like I said, HIDS tend to at least allow logging to a database, which a lot of SIEMs (security information & event management) systems take advantage of. The problem in this is that some HIDS systems don’t make the task easy of parsing throw the entries. OSSEC is one of them. The database structure itself is pretty nice and easily followed, until you want to get the data of the alert that was triggered. While it exists, there’s no correlation between the event’s time and the data of the alert, as OSSEC stores every new line of an alert as a new entry. This gets is to be very troubling when you’re trying to figure out what happened, and your boss is on your behind at 3 AM demanding answers. SIEMs usually get around this by using log parsers (greylog, for example), so OSSEC still logs to a standard file, and custom log analysis rules are made to match OSSEC’s alert entries, for example. This is nice, but it really restricts you to one system. There is another option, however. I’ve stumbled upon another HIDS that has a better flowing database structure, called Samhain. While installing and configuring Samhain can be a bit more challenging, the benefits could potentially outweigh the initial trouble. What I’m talking about is that all the alerts are stored in table, so there’s no normalization going on, and all the data is in one entry, so there’s no needing to figure out an overly complex SQL query to combine all the data into one. It does, however, pose its own issue in that not a lot of SIEMs natively support it. For example, AlienVault/OSSIM, a very popular commercial/community SIEM comes in its own distro/ISO, and has you using OSSEC to manage system file management. Which, is fine if you want a system preconfigured, but there’s also times where having more fine-grain control should be used. A lot of people implement a HIDS to comply with standards (i.e.: PCI-DSS 10.5 ruleset requires a system to monitor logs and system files). But, even if you don’t need one, HIDS typically also check files like utemp to monitor user account access. They are a very viable tool that every network should have, but is often neglected due to the scarce awareness that they have.