How to configure a host-based Intrusion Detection System on CentOS

How to configure a host-based Intrusion Detection System on CentOS

One of the first security measures that any system administrator wants to deploy on its production server is the file tampering detection mechanism. Criminals tamper with not only the file content, but also the file attributes.

AIDE is a host-based open-source Intrusion Detection System. AIDE checks the integrity of system binary files and basic configuration files by checking the inconsistency of many file attributes, including permissions, file types, index nodes (inode), link quantity, Link name, user, user group, file size, block count, modification time, access time, creation time, access control list (acl), SELinux security context, xattrs, and md5/sha checksum.

AIDE builds a File Attribute Database by scanning the file system of A (untampered) Linux server. Then, it checks the file attributes of the server against the database, and then sends a warning once the index file changes during server running. For this reason, AIDE must re-index protected files whenever the system is updated or the configuration file is changed for a legitimate reason.

For some customers, their security policies may require some Intrusion Detection System (IDS) to be installed on the server ). However, whether users require IDS or not, system administrators can deploy IDS.

Install AIDE on CentOS or RHEL

The initial installation (and first running) of AIDE should be performed on the system where the operating system is just installed, without any service being exposed to the Internet or even the LAN. At this early stage, we can minimize the risk of all intrusion and tampering from the outside. In fact, this is the only way to ensure that the system is clean when AIDE builds its initial database.

For this reason, after installing aide using the # yum install AIDE command, we need to disconnect our machine from the network and execute some basic configuration tasks, as described below.

Configure AIDE

The default configuration file is located in/etc/aide. conf. This file provides several example protection rules (such as FIPSR, NORMAL, DIR, and DATAONLY). Each rule is followed by an equal sign and a list of file attributes to be checked, or any predefined rule (separated by + ). You can also use this format to define any custom rules.

 

FIPSR = p + I + n + u + g + s + m + c + acl + selinux + xattrs + sha256

NORMAL = FIPSR + sha512

For example, the above example means that the NORMAL rule will check the inconsistency of the following attributes: permission (p), index node (I), link quantity (n), user (u) user Group (g), size (s), modification time (m), Creation Time (c), access control list (acl), SELinux (selinux), xattrs (xattr) and SHA256/SHA512 checksum (sha256 and sha512 ).

The defined rules can be flexibly used for different directories and files (expressed using regular expressions ).

The exclamation point before the entry (!) Tell AIDE to ignore sub-directories (or files in the directory) and define another rule for sub-directories.

In the above example, PERMS is the default rule for/etc and Its subdirectories and files. However, there are no rules that will apply to the backup files (that is,/etc/. * ~) in/etc /.*~), It will not be applied to the/etc/mtab file. For some selective subdirectories or files in/etc, the NORMAL rule is applied to replace the default rule PERMS.

Defining appropriate rules and applying them to a proper position in the system is the most difficult part of the AIDE process, but using good judgment is a good start. An empirical rule is that do not check unnecessary attributes. For example, checking the modification time of files in/var/log or/var/spool will certainly result in a large number of false positives, because many applications and daemon often write content to these locations. In addition, checking multiple checksum may enhance security, but the cost is that the AIDE Runtime is extended.

 

In addition, if you use the MAILTO variable to specify the email address, you can send the check result to your mailbox. Place the following line to any location in/etc/aide. conf.

 

MAILTO = root @ localhost

Run AIDE for the first time

Run the following command to initialize the AIDE database:

# Aide -- init

The/var/lib/aide/aide.db.new.gz file generated based on/etc/aide. conf must be renamed to/var/lib/aide/aide.db.gz so that AIDE can read it:

# Mv/var/lib/aide/aide.db.new.gz/var/lib/aide.db.gz

Now it is time to compare the database and execute our first system check. To do this, just run:

# Aide

When no call is available, AIDE uses -- check.

If no changes have been made after the database is created, AIDE returns the OK message after the check.

 

 

Manage AIDE in a production environment

After building the initial AIDE database, you often need to update protected servers for various legitimate reasons, which is part of daily system management activities. After each server update, you must re-build the AIDE database to add the changed content to the database. Therefore, use the following command:

# Aide -- update

To use AIDE to protect production systems, it may be better to schedule a scheduled task to regularly use AIDE to check for any inconsistency. For example, arrange AIDE to run once a day and send the result to the email address:

# Crontab-e

0 0 ***/usr/sbin/aide -- check |/usr/bin/mail-s "AIDE run for $ HOSTNAME" your@email.com

Test the file tampering check function of AIDE.

The following test scenarios demonstrate how AIDE Checks file integrity.

Test scenario 1

Add a new file (such as/etc/fake ).

# Cat/dev/null>/etc/fake

 

 

Test scenario 2

We may wish to change the File Permission to see if it can be detected.

# Chmod 644/etc/aide. conf

Test scenario 3

Finally, modify the file content (for example, add a comment line to/etc/aide. conf ).

Echo "# This is a comment">/etc/aide. conf

On the screen above, the first column shows the file attributes, the second column shows the values in the AIDE database, and the third column shows the updated values of those attributes. The blank section in the third column indicates that the attribute has not been changed (ACL in this example ).

Conclusion

If you really think you are in this situation: there are good reasons to think that the system has been tampered with, but at first glance you cannot find out what may have been changed, A host-based intrusion detection system such as AIDE is very helpful because it helps you identify what has been changed as soon as possible, rather than making guesses and wasting valuable time.