Intrusion Detection and Integrity Checks with AIDE in Linux

 Advanced Intrusion Detection Environment (AIDE) is an open-source utility designed to monitor and protect the integrity of files on a Linux system. AIDE creates a database of file attributes and uses it to perform regular checks for changes, additions, or deletions in system files, alerting you to potential security breaches. When properly used AIDE helps to protect the system internally, by providing a layer of protection against viruses, rootkits, malware, and detection of unauthorized activities.

 

Why Use AIDE?

1. Detect Unauthorized Changes: AIDE can identify unauthorized changes to critical system files, helping you catch intrusion attempts promptly.
2. File Integrity Monitoring: It offers continuous file integrity monitoring, making it ideal for ensuring the stability and security of your server.
3. Customizable Rules: AIDE allows you to define specific rules for monitoring, tailoring its functionality to your unique server environment.
4. Alerts and Reports: It generates detailed reports and alerts when changes are detected, making it easier to respond to security incidents.

 

Install AIDE

AIDE is readily available in all the operating system software repositories.

 

# yum install aide

Initilize AIDE

Check if the AIDE database is created and initialized using:

 

# aide --check

 

You might end up with the below error, its because the AIDE database has not been created and initialized.

 

[root@delme ~]# aide --check

Couldn't open file /var/lib/aide/aide.db.gz for reading

 

Create and Initialize AIDE Database using:

 

# aide --init

 

Initializing the AIDE database will take some time as its building a database with entries of the files in the server for integrity checks.

 

As you can see from the logs, the new AIDE DB has been created at ‘/var/lib/aide/aide.db.new.gz’.

 

            [root@delme ~]# aide --init

Start timestamp: 2023-10-17 17:19:48 +0000 (AIDE 0.16)

AIDE initialized database at /var/lib/aide/aide.db.new.gz

 

 

Running the AIDE check now will again error out because the AIDE is still not in the location AIDE needs it to be.

 

[root@delme ~]# aide --check

Couldn't open file /var/lib/aide/aide.db.gz for reading

 

We need to rename the AIDE created in the initialization step as follows:

 

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

 

Running an AIDE check should complete successfully.

 

[root@delme ~]# aide --check

Start timestamp: 2023-10-18 09:34:17 +0000 (AIDE 0.16)

AIDE found differences between database and filesystem!!

 

Summary:

  Total number of entries:    152841

  Added entries:         0

  Removed entries:       0

  Changed entries:       2

 

---------------------------------------------------

Changed entries:

---------------------------------------------------

 

f   ...    .C... : /root/dead.letter

f           C    : /var/spool/anacron/cron.daily

 

---------------------------------------------------

Detailed information about changes:

---------------------------------------------------

 

File: /root/dead.letter

  SHA512   : jdMY+0A4RF8MDhMhdE1GvbQbxo695cYf | Q9XC53FBoeyLpzXe7bcUvEex0C/EwNZq

             KoS4la95t3np7LxoeMmH943uDFipAq8d | v1BNdB8ZlDwIgMTemCoUSeOWtz1CowZ3

             Q3VgvcerraMGjo6TVP1FHg==         | G/nTFnnCNr9ihxO/NGeTtg==

 

File: /var/spool/anacron/cron.daily

  SHA512   : MAp+To9ckjKmE7nZl5/J5M9EXxsgks8O | BsPYbhD/SXkrAdJ4Z4V6ng7BhrFJmqeZ

             wv/5ABt5bMMxWkrjOci3mQhRKfOoNV/h | IJ87kg0X3xVlJYrXV9MR7+0BJ90/0wg2

             eQBfHpitQxsAY2867cU2FQ==         | TI+f0QyA7lChmEYPer2QxQ==

 

---------------------------------------------------

The attributes of the (uncompressed) database(s):

---------------------------------------------------

/var/lib/aide/aide.db.gz

  MD5      : fkL+BqnpQdU/i6i3Y3kYqg==

  SHA1     : soqet8oNzHlY9RyDvmHxkqqHY50=

  RMD160   : yIFtCdBrYrt8XY0YipYaMMLP6N0=

  TIGER    : Cbz88BLcGNlurtyIUeizs8KOjof0vc97

  SHA256   : mZK5eTK5nHYDxp/Q7bpCjBtZXa8o8jTx

             INo+S3qXTVE=

  SHA512   : ASgbZO1egNtthUi4TkMqDuQFpKwUr7bh

             SHkdcSscF6rN2p0EKqdd27qmjDf3cr7X

             nCuHDXZrTfYwPSy46KGfdQ==

 

End timestamp: 2023-10-18 09:34:49 +0000 (run time: 0m 32s)

[root@delme ~]#

 

As you can see AIDE has detected 2 changes in the system since the DB is initialized/updated. Review those changes and make sure everything is fine.

 

Once verified, you should update the AIDE DB to include the known changes using the --update command option.

 

However, if there are changes in the filesystem, which is usually the case when you update the DB, AIDE will create a new DB as follows. You need to back up the old and rename the newly generated one to be the main db.

 

[root@delme ~]# aide --update

Start timestamp: 2023-10-18 09:44:02 +0000 (AIDE 0.16)

AIDE found differences between database and filesystem!!

New AIDE database written to /var/lib/aide/aide.db.new.gz

 

Summary:

  Total number of entries:    152841

  Added entries:         0

  Removed entries:       0

  Changed entries:       2

 

Rename the AIDE Db to include newly modified/added files:

 

# mv /var/lib/aide/aide.db.gz /var/lib/aide/aide.db.$(date +%d%m%y%H%M).gz

 

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

 

Running a check again should give you a clean summary provided there are no further changes in the system.

 

AIDE configuration

AIDE’s configuration file is /etc/aide.conf file. You can customize the rules for file monitoring based on your needs. For example, you can add or exclude specific directories or files from monitoring.

The AIDE confirmation file contains the directives that defines the database location, where the new database be created when running an update, default rules, files and directories to be included in the database for monitoring and so on.

 

The following are the default rules, that can be applied to the files and directories to be added to the DB.

#p:      permissions

#i:      inode:

#n:      number of links

#u:      user

#g:      group

#s:      size

#b:      block count

#m:      mtime

#a:      atime

#c:      ctime

#S:      check for growing size

#acl:           Access Control Lists

#selinux        SELinux security context

#xattrs:        Extended file attributes

#md5:    md5 checksum

#sha1:   sha1 checksum

#sha256:        sha256 checksum

#sha512:        sha512 checksum

#rmd160: rmd160 checksum

#tiger:  tiger checksum

 

#haval:  haval checksum (MHASH only)

#gost:   gost checksum (MHASH only)

#crc32:  crc32 checksum (MHASH only)

#whirlpool:     whirlpool checksum (MHASH only)

 

#R:             p+i+n+u+g+s+m+c+acl+selinux+xattrs+md5

#L:             p+i+n+u+g+acl+selinux+xattrs

#E:             Empty group

#>:             Growing logfile p+u+g+i+n+S+acl+selinux+xattrs

 

 

You can create custom rules of your choice using the above default rules.

There are few custom rules already in the configuration file as follows.

 

# NORMAL = R+sha512

NORMAL = p+i+n+u+g+s+m+c+acl+selinux+xattrs+sha512

 

# For directories, don't bother doing hashes

DIR = p+i+n+u+g+acl+selinux+xattrs

 

# Access control only

PERMS = p+u+g+acl+selinux+xattrs

 

# Logfile are special, in that they often change

LOG = p+u+g+n+S+acl+selinux+xattrs

 

# Content + file type.

CONTENT = sha512+ftype

 

# Extended content + file type + access.

CONTENT_EX = sha512+ftype+p+u+g+n+acl+selinux+xattrs

 

# Some files get updated automatically, so the inode/ctime/mtime change

# but we want to know when the data inside them changes

DATAONLY =  p+n+u+g+s+acl+selinux+xattrs+sha512

 

You may define rules to watch files and directories. The configuration file contains several default rules that does a job of monitoring files, but you are free to tweak.

 

An example rule set:

Check everything for all files under the /root directory with the exception of checking for permissions only for the hidden files under /root.

 

            /root/\..* PERMS

     /root   CONTENT_EX

 

Use the following to help you detect any changes in data inside all files/directory under /etc/.

        /etc/   DATAONLY 

 

You may specify to ignore files and directories using “!” as follows:

            # Files under there directores are too volatile, hence do not include in the AIDE database

!/usr/src

!/usr/tmp

 

Some thoughts on setting up the AIDE rules

There are currently thirteen attributes that AIDE can log including permissions, owner, group, size, all three timestamps (atime, ctime, and mtime), plus lower-level stuff like inode, block count and number of links .

You need to review the rules in the AIDE configuration file and set proper regular expression matching the files you need to monitor is key to effective use of AIDE. If you are monitoring too many file and directories you might end up with extremely long logs to go through. On the other hand a narrow set of rules could risk missing an important change on your system.

 

Run System Integrity Checks Frequently

AT the very minimum AIDE should be configured to run every week or ideally everyday. You could setup a cornjob as follows.

        0 0 * * * /usr/sbin/aide --check

 

How to remove malwares and virus from Linux servers

 

Linux servers are renowned for their resilience and security. However, even the most robust systems can fall prey to malware. When malicious software breaches your Linux server's defences, knowing how to eliminate it is paramount. In this comprehensive guide, we will walk you through the steps necessary to remove malware from your Linux server, including utilizing the helpful tools like 'rkhunter', 'clamav'.

 

However, prevention is better than cure. We will take a quick look into few other tools like 'Snort' for intrusion detection and 'Aide' for system integrity checks.

 

1. Isolate and Assess the Damage

Your initial step when dealing with malware is to isolate the infected server. Disconnect it from the network to prevent further contamination and assess the extent of the damage. Look for signs of unauthorized access, altered or deleted files, and unusual system behavior.

 

2. Identify the Malware

Accurate identification of the malware is crucial. Use trusted antivirus or anti-malware tools compatible with Red Hat Linux, such as ClamAV or rkhunter, to scan your server. These tools can detect known malware signatures, though be mindful of false positives when taking action.

 

2.1 Install ClamAV Antivirus and scan the server.

You need to enable the EPEL repository for installing software like ClamAV and rkhunter.

 

    # yum --enablerepo ol8_developer_EPEL install clamav clamav-update

 

Once installed you need to update the ClamAV antivirus database using:

 

# freshclam 

 

 

Then, you should do a full scan of the server using the following command:

 

        # clamscan -r /

 

ClamAV will print a scan summary after the scan is finished.

 

2.2. Install rkhunter and scan the server

The 'rkhunter' is a specialized tool for detecting rootkits and other intrusions. This tool is adept at detecting rootkits, which are often used by malware to maintain unauthorized access to a system. 'RkHunter' can provide an extra layer of security by identifying any suspicious activities.

 

You can install it on your Linux server using (RedHat based falvours):

 

# yum --enablerepo ol8_developer_EPEL install rkhunter

 

Scan your server for rootkits and malwares using:

 

# rkhunter --check

 

The RkHunter will first analyse the system binaries, libraries and strings for any known infections. Then it will check for rootkits, ports known for being used for trojans and backdoors, start-up files for malwares and so on. It will also perform various other security checks on the server. 

 

And finally, it will print a summary of the results.

 

3. Quarantine and Backup

Once the malware is identified, quarantine infected files.

Take backups of important files before any further actions, but keep in mind that the backed up files could be infected. Backups serve as a safety net, allowing you to recover in case of unforeseen issues during the removal process.

 

4. Manual Inspection

Some malware may evade automated detection. Thoroughly inspect critical system files and directories manually. Look for suspicious changes, new files, or unexpected processes running on your Linux server.

 

5. Disable Unnecessary Services

Disable or shut down any unnecessary services or applications on your server. Malware often exploits vulnerabilities in these services. Keep your software and the operating system of the server up to date to patch known vulnerabilities.

 

6. Remove Malicious Code

If you've identified the malware's code within your server, remove it. Caution is crucial during this process, as editing system files can be risky. Seek expert advice if you're uncertain.

 

7. User Accounts and Permissions

Review user accounts and permissions on your Linux server. Disable or remove suspicious or unnecessary accounts. Reset the passwords for all accounts and enforce strong password policies.

8. Intrusion Detection System

Implement an Intrusion Detection System (IDS) to monitor server activity and detect any unusual behavior. Linux supports various IDS solutions; you can consider using Snort or Suricata.

 

We shall review how to install and configure Snort on Linux systems on another post.

 

9. System Integrity Checks

Regularly perform system integrity checks on your Linux server using tools like AIDE (Advanced Intrusion Detection Environment) to detect any file changes.

 

# yum install aide

 

Initialize aide database

# aide --init

 

 

Check for any changes in the system using the following command.

 

# aide --check 

 

As you can see I created a file testfile.txt and aide detected it.

 

At times, the only option would be to restore from a good known backup or rebuilding the system from scratch. Prevention is always better than cure and you should follow all the security best practices like applying patches, updates and making use of good AntiVirus, Rootkit, IDS are crucial steps. Always prioritize proactive security measures to protect your server.

 

Depricated SSL/TLS Protocols and Ciphers you should not use

 As cybersecurity threats evolve, older SSL/TLS protocols and ciphers that were once considered secure have become deprecated due to vulnerabilities and weaknesses. Here are some of the deprecated SSL/TLS protocols and ciphers:

Deprecated SSL/TLS Protocols:

1.     SSLv2: SSL version 2 is highly insecure and has numerous vulnerabilities, including susceptibility to various attacks like the BEAST attack. It's considered completely obsolete and should not be used.

2.     SSLv3: SSL version 3 is also deprecated due to vulnerabilities like POODLE (Padding Oracle On Downgraded Legacy Encryption). It's no longer considered secure.

3.     TLS 1.0: TLS 1.0 is deprecated because it's vulnerable to attacks like BEAST and POODLE. It lacks some modern security features found in newer TLS versions.

4.     TLS 1.1: TLS 1.1 is considered weak and is also deprecated in many security-conscious environments.

Deprecated SSL/TLS Cipher Suites:

1.     RC4: The RC4 cipher is deprecated due to multiple vulnerabilities, including biases that allow for practical attacks. It's recommended to avoid using RC4 in favor of stronger ciphers like AES.

2.     DES (Data Encryption Standard): DES is considered weak due to its small key size, making it vulnerable to brute-force attacks. It's deprecated in favor of stronger encryption algorithms.

3.     3DES (Triple Data Encryption Standard): While 3DES was once considered secure, its key length and vulnerability to certain attacks make it deprecated in favor of more robust encryption algorithms.

4.     EXPORT Cipher Suites: These cipher suites were designed to comply with export restrictions on encryption technology in the 1990s. They have extremely weak key lengths and are deprecated.

5.     NULL Cipher Suites: These cipher suites provide no encryption, making data transmission completely insecure. They should never be used.

6.     Anon Cipher Suites: Anonymous cipher suites don't require the server to present a digital certificate, making them susceptible to man-in-the-middle attacks. They are deprecated for security reasons.

7.     Cipher Suites with Weak Key Lengths: Cipher suites with key lengths less than 128 bits (e.g., 40-bit or 56-bit keys) are deprecated due to their vulnerability to brute-force attacks.

It's crucial to keep your SSL/TLS configurations up to date and avoid using deprecated protocols and ciphers to maintain a high level of security for your web services. Most modern web browsers and servers have deprecated these older protocols and ciphers as well, and it's essential to configure your systems to use only strong, secure options to protect against potential security threats.