AID(E)ing you to get Server Baselines!

Latest response

Being a Security-ologist, I'm constantly looking for ways to improve how I and my customers run computers. There are dozens, nah, hundreds of ways for the bad guys to get in and take advantage of you. Sadly, a lot of vulnerabilities can be mitigated with some simple procedures and operational rigor. You can't be vulnerable to an attack if the service they are using as an attack vector is not install or properly secured using something like SELinux.

A common tactic used no matter what the Operating System might be is to modify critical files or programs to mask the intruder. These "trojan horses" will lurk on your network waiting to be executed or until they are triggered to deliver their payload. In most complex networks with properly layered security there might be a slew of mitigation options (firewalls, VLANing, Network-based Intrusion tools, Client-side protections) but oftentimes this could be too late or lost in a flood of network chatter.

One way we can help to mitigate this risk is by understanding what's install on our servers and using Host-based Intrusion tools. Some folks will use the term "server baseline" to refer to a record of what is installed on a server and how your critiical files are configured. There are several great vendors out there selling some very good products that you can purchase to help fulfill this need, but if you're like me you look to Linux and FOSS first before investing your budget and resources. The tool included to do this with RHEL is called AIDE - Advanced Intrusion Detection Environment. AIDE does file and directory integrity checking - ie - it'll help write up your baseline and then keep things monitored to ensure it stays that way!

We've got a knowledgebase article to get you started off:

How to use and configure aide (Advanced Intrusion Detection Environment) in Red Hat Enterprise Linux ?

This package is not installed by default, but with a simple yum install aide you'll be zipping along your way down the path to better Security. AIDE has a ton of knobs and dials that can be tweaked via /etc/aide.conf and a complete list of options can be found at /usr/share/doc/packages/aide/manual.html.

To use aide, you first have to create the AIDE database, so go ahead and tell AIDE what you're interested in looking at and save the conf file. Next run

`aide --config-check`

and work through any issues with your configuration (drat those twisty regular expressions!). Now you're ready to initialize the databse for use

`aide -i`

That will hum along for a bit. As soon as that's done you can save that baseline database off to media or a SECURED place on the network for later reference. Now you're ready to use that data and compare your system back to this baseline periodically. To test things out run

`aide --check`

Keep in mind that after any configuration change, patch update, major change, make sure to rescan your system to avoid false positive messages and lots of running around, hand-waving, fire-drills. But that's it, you know have a server baseline that you can scan and report against periodically to ensure your files stay the way you want them.

AIDE isn't the biggest or best tool ever, but what it does it does extremely well and for no outlay of cash. You could fairly easily combine the check output into an alert or send over to a centralized monitoring system for further investigation. So that's one use case, how are all of you out there in the Community using AIDE or similar tools? We'd really love for you to share!

Responses

how can I check to see if aide is already on a red server

yum list installed | grep aide

is there a way that aide can be configured to only utilize a certain % of system resources or be "throttled"?

Brian,

I am glad someone asked this question.

Aide definitely has its benefits, but the load it puts on system resources, especially in virtual environments or systems with large filesystems, isn't one of them. In the past I have run aide on ~1000 VM installation and management of the server load during the runs was problematic. I spread the load across mutiple time intervals to prevent 'thundering herd', but even then it would still cause unwanted impact.

One strategy is to 'nice' the process, but this has limited real world impact. Another more modern option (el7 only) is to the cap the CPU it is using in a systemd unit file, eg.

[Service]
ExecStart=/usr/local/bin/aide_script.sh
CPUQuota=15%
Slice=aide.slice

It is definitely a useful tool when actively maintained to manage drift or configuration change by including it in system patch update processes so that it doesn't drift to the point that people start ignoring the output. Where it really starts to show value is when you feed the output into a SIEM and collate the data from multiple systems to present trends... this also makes it easier to spot the false positives when they occur that can then be added to a list of specific exceptions.

For critical system files I would suggest placing them under management of a configuration management tool such as Puppet (Enterprise)/Ansible (Tower). Not only will this quickly identify changes/drift, it can redmediate them (including backup/filebucketing) without additional interaction with the system.

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.