332.2 Host Intrusion Detection

Weight: 5

Description: Candidates should be familiar with the use and configuration of common host intrusion detection software. This includes managing the Linux Audit system and verifying a system's integrity.

Key Knowledge Areas:

  • Use and configure the Linux Audit system

  • Use chkrootkit

  • Use and configure rkhunter, including updates

  • Use Linux Malware Detect

  • Automate host scans using cron

  • Use RPM and DPKG package management tools to verify the integrity of installed files

  • Configure and use AIDE, including rule management

  • Awareness of OpenSCAP

Partial list of the used files, terms and utilities:

  • auditd

  • auditctl

  • ausearch, aureport

  • auditd.conf

  • audit.rules

  • pam_tty_audit.so

  • chkrootkit

  • rkhunter

  • /etc/rkhunter.conf

  • maldet

  • conf.maldet

  • rpm

  • dpkg

  • aide

  • /etc/aide/aide.conf

Thread Detections Tools

The important thing about threat detection tools is that these are post-incident tools. That means you are alerted once your system has been already compromised!

The tools you need to know about:

  • AIDE : standard intrusion detection tool

  • OPENScap : RedHat tool for system monitoring

  • Linux Malware Detect : another tool for detecting malicious software

  • Rkhunter : hunt rootkits

  • Chkrootkit : hunt rootkits

For the test it is important to:

  • know commands and options

  • good understanding of concepts

  • Know configuration directives

AIDE

Advanced Intrusion Detection Environment (AIDE) is a powerful open source intrusion detection tool that uses predefined rules to check the integrity of files and directories in the Linux operating system. AIDE has its own database to check the integrity of files and directories.

AIDE helps monitor those files that are recently changed or modified. You can keep track of files or directories when someone tries to modify or change them.

How AIDE works?

AIDE maintains a database of file signaturesand verifies file signatures periodically (when configured).

Is AIDE secure?

AIDE is secured by SELinux. SElinux secures the AIDE process with mandatory access control. It defines process types (domains) for each process running on the system. SELinux AIDE policy is very flexible, allowing users to set up their AIDE processes in as secure a method as possible.

There is a possibility that in some of the Linux distributions, AIDE is not installed. You need to install it first.

You can check the version of AIDE using aide -v .

/etc/aide.conf

In AIDE, the path of the configuration file is /etc/aide.conf. This configuration can initialize or check the database. In this configuration, some rules are already predefined such as PERMS, NORMAL, LSPP, DATAONLY, and so on. These custom rules contain many defaults related to permissions, inodes, numbers of links, acl, selinux, etc. One example of a custom rule is :

Where:

  • p: permission

  • i : inode

  • N : number of links

  • u : user

  • g : group

  • acl : access control list

  • selinux : SELinux security context

These rules help in tracking and detecting files. If you put PERMS rules on any directory or files, then all these rules are implemented for tracking and monitoring. Using all these declared rules, you can also create your custom rules, which are a combination of multiple rules.

Before initializing the AIDE database, it is important to set rules for directories or files. You can do this in the /etc/aide.conf file itself. Suppose you want to keep track of the /etc/passwd file so that you can put rules like PERMS on that file to check the integrity of the file using an AIDE database.

AIDE Implementation

To implement AIDE on your system, you need to initialize the database. Using this AIDE database, an integrity check is run on all the files and directories. The AIDE database generates in the /var/lib/aide directory. You can also check the context of this directory using:

This directory has aide_db_t context set by SELinux. This context is used when you want to treat the files as AIDE database content. AIDE logs are stored in the /var/log/aide directory and this directory also has aide_log_t context.

To initialize the AIDE database, use the command:

This command generates a gzipped file of the database. You can use the zipped file for integrity checking purposes.

It is important to keep a copy of the database on offline media for maximum security.

Suppose you need to monitor the /etc/hosts file. So that if someone tries to enter a file or tries to modify it in your absence, then you can check that file using AIDE.

After installing AIDE on your system, make an entry in the /etc/aide.conf file with customized rules. You need to monitor files for changes in permissions, groups, ownership, and file access time. You can then select any customized rules that contain all these points.

Here I put the FIPSR ruleset because these custom rules contain the maximum normal rules.

NOTE: Before writing anything to the aide.conf file, always make a backup.

In the /etc/aide.conf file, you can write filename with this custom rule:

After this, you can initialize the database using the aide --init command. This generates a gzip file with the name of aide.db.new.gz. Move this file inside the default directory of the AIDE database with the name of aide.db.gz

In this way, you can set the database in the proper location.

After AIDE is made aware of the current file system status, it can detect file system changes by comparing against the known status. To verify the integrity, use:

This command gives you output in detail. If the /etc/hosts file is modified, then it clearly prompts you with the last modified file.

If you want to update the AIDE database after doing new entries in aide.conf , use:

What is SCAP?

SCAP stands for Security Context Automation Protocol. And that is a community project started by Redhat.

OpenSCAP

OpenSCAP is an auditing tool that utilizes the Extensible Configuration Checklist Description Format (XCCDF). XCCDF is a standard way of expressing checklist content and defines security checklists. It also combines with other specifications such as CPE, CCE, and OVAL, to create a SCAP-expressed checklist that can be processed by SCAP-validated products.

OpenSCAP Features:

1. Security Compliance

In order to minimize the threat of an attack on computer infrastructure, or even completely prevent it, many institutions in both the private and public sectors have adopted the concept of enforcing a security policy or a security benchmark. These policies define security requirements which all systems used by the institution must meet. It applies not only to systems physically located within the organizations, but often to any third party environments have access to the organizations’ computer infrastructures. In some cases, these policies are defined by government regulations, but many businesses adopt their own security policies even if they are not specifically required to do so by law.

2. Vulnerability Assessment

Any organization wishing to protect itself against these attacks must set up a proper and sustainable vulnerability management policy. A good policy satisfies multiple key concepts, which include:

  • Detailed knowledge of the underlying computer infrastructure

  • Continuous delivery of certified information about currently known security flaws and their impact

  • Quick identification of the current security status of each system (security analysis)

  • Prompt reaction — capability to instantly perform corrective operations where necessary (remedial action)

  • Possibility to perform security analysis in automated,unattended way on regular basis, regardless of the infrastructure’s complexity

  • Availability of proper software tools to carry out these tasks with minimal effort while preventing or at least minimizing outage periods

Packages:

  • Debian: libopenscap8

  • Red Hat: openscap-scanner

Be aware of what it is! that is enough for LPIC3 exam.

maldet

Linux Malware Detect (LMD) is a malware scanner for Linux released under the GNU GPLv2 license, that is designed around the threats faced in shared hosted environments. It uses threat data from network edge intrusion detection systems to extract malware that is actively being used in attacks and generates signatures for detection. In addition, threat data is also derived from user submissions with the LMD checkout feature and from malware community resources.

How maldet works?

maldet uses external signatures to check for threats. maldet can be configured to scan a system regularly

Installing LMD

LMD is not available from online repositories but is distributed as a tarball from the project’s web site. The tarball containing the source code of the latest version is always available as a link, where it can be downloaded with wget command:

run install.sh to install:

if you inspect install.sh, you will see that it not only installs the tool but also performs a pre-check to see if the default installation directory (/usr/local/maldetect) exists. If not, the script creates the installation directory before proceeding.

Finally, after the installation is completed, a daily execution via cron is scheduled by placing the cron.daily script (refer to the image above) in /etc/cron.daily. This helper script will, among other things, clear old temporary data, check for new LMD releases, and scan the default Apache and web control panels (i.e., CPanel, DirectAdmin, to name a few) default data directories.

There are two other packages which are usually used with maldet as plugins:

  • inotify: gives real time monitoring option

  • ClamAV: Antivirus Engine

Note: That these are only the basic instructions to install ClamAV in order to integrate it with LMD. We will not go into details.

Configuring Linux Malware Detect

The configuration of LMD is handled through /usr/local/maldetect/conf.maldet and all options are well commented to make configuration a rather easy task. In case messed up, you can also refer to /maldetect-1.6.4/README for further instructions.

/usr/local/maldet/monitor_paths contains paths that maldet should watch. Main configuration file is in /usr/local/maldet/conf.maldet

In the configuration file you will find the following sections, enclosed inside square brackets:

  1. EMAIL ALERTS

  2. QUARANTINE OPTIONS

  3. SCAN OPTIONS

  4. STATISTICAL ANALYSIS

  5. MONITORING OPTIONS

Each of these sections contains several variables that indicate how LMD will behave and what features are available.

email_alert

0 to disable email alerts

1 to enable email alerts

email_addr Email address to send reports to

autoupdate_signatures

0 disables automatic signature updates

1 enables automatic signature updates

autoupdate_version

0 disables automatic LMD updates

1 enables automatic LMD updates

Do not forget, that it requires some firewall rules to update!

scan_clamscan If clamav is installed, maldet will use clamav scanning for improved performance

0 disables clamav integration.

1 enables clamav integration.

quarantine_hits

0 does not quarantine on detection

1 does quarantine on detection

Important: Please note that quar_clean and quar_susp require that quar_hits be enabled (=1).

Testing Linux Malware Detect

use maldet -a command to scan:

see reports:

maldet -e will also do the same thins and show the results.

Options

use maldet --help for full review.

Rootkit detection

Rootkits are one of the worst things that can happen to a system and they are one of the most dangerous attacks, more dangerous than usual malware and viruses, both in the damage they cause to the system and difficulty in finding and detecting them. Rootkits can stay on your system for a long time without the user even noticing and it can cause some serious damage to the system. Kernel modules are common targets for rootkits as they are loaded with root access.

The word rootkit comes from the root user, which is the administrator account on Linux systems and Unix-clones. The kit refers to a toolkit, or a set of tools.

When using tools that check for rootkits, it is important you can trust the binaries those tools may reference

Note: AIDE may also detect rootkits

chkrootkit

The chkrootkit security scanner searches for signs that the system is infected with a ‘rootkit’.

chkrootkit can identify signs of over 70 different rootkits (see the project’s website for a list).

Please note that an automated tool like chkrootkit can never guarantee a system is uncompromised. Nor does every report always signify a genuine problem: human judgement and further investigation will always be needed to assure the security of your system.

note: chkroot kit package is avaiable on Debian based systems, but installing them on Redhat based systems needs more effort.

chkrootkit will check for rootkits

chkrootkit -q will check for rootkits and have less verbose output

Configuration file located at /etc/chkconfig.conf

Rkhunter

Rkhunter (Rootkit Hunter) is an open-source Unix/Linux based scanner tool for Linux systems released under GPL that scans backdoors, rootkits, and local exploits on your systems.

It scans hidden files, wrong permissions set on binaries, suspicious strings in the kernel, etc. To know more about Rkhunter and its features visit http://rkhunter.sourceforge.net/.

  1. Updating Rkhunter

Run rkhunter --update to to update rkhunter signatures and fill the database properties.

One of the checks rkhunter performs is to compare various current file properties of various commands, against those it has previously stored. --propupd command option causes rkhunter to update its data file of stored values with the current values. (obviously there is no current data for the the first run) So , lets fill the Rkhunter data file :

Note: There is a configuration file for rkhunter in /etc/rkhunter.conf. It allows for configuration of which directories rkhunter will check as well as log file locations and such.

check via Rkhunter

We can either run rkhunter manually:

during the check it asks for user prompt again and again, to avoid that run it witch cron switch:

--report-warning-only or --rwo is the same as -q in chkrootkit

Take a quick look at log files generated /var/log/rkhunter/rkhunter.log:

System Auditing with Auditd

Auditing vs. Logging

• Logs vary by system and software(depends on service config).

  • syslog (typically written in /var/log)

  • systemd-journald (uses syslog by default)

• Auditing goes deeper than logs ,Audit runs at the OS level.

  • auditd process handles auditing

  • Writes to /var/log/audit/audit.log

  • Contains the following types of information:

  1. Type of audit

  2. Timestamp (in EPOC)

  3. PID

  4. UID (Effective UID)

  5. Audit UID (original UID - who started process, think setuid)

  6. Sess: session id (important for even correlation)

  7. subj: selinux info

  8. msg: message Name of the executable

  9. Binary

The audit system has two core components, namely:

  • user-space applications and utilities/tools, and

  • kernel-side system call processing – this accepts system calls from user-space applications and passes them through three types of filters, namely: user, task, exit, or exclude

Auditd

Auditd is short for Linux Audit Daemon. Auditd is the userspace component to the Linux Auditing System. Sysadmins use audits to discover security violations and track security-relevant information on their systems. Based on preconfigured rules and properties, the audit daemon (auditd) generates log entries (/var/log/audit/audit.log) to record information about the events happening on the system . Administrators use this information to analyze what went wrong with the security policies and improve them further by taking additional measures.

auditd is built into Red Hat distributions and may be installed in Debian.

There are a number of user-space tools for managing and retrieving information from the audit system:

  • auditctl – a utility for controlling the kernel’s audit system.

  • ausearch – a utility for searching audit log files for specific events.

  • aureport – a utility for creating reports of recorded events.

/etc/audit/auditd.conf

The audit configuration file is located at /etc/audit/auditd.conf. The file contains the default configuration parameters that alter the behavior of the auditd daemon. The parameters here allow you to control how the service runs, such as defining the location of the log file, maximum number of log files, log format, how to deal with full disks, log rotation and many more options.

ausearch

Use the ausearch tool to search audit logs. By default, it searches the /var/log/audit/audit.log file. some important options:

example:

try ausearch -ui 0 to see all events of uid 0 which is root.

auditctl

With the auditctl tool, you can add auditing rules on any system call you want.

Ordering is important for rules to function as intended, and the service works on a first-match-win basis.

the important options:

Define audit rules

The next step defines the watch rule. This rule tracks whether a file or directory is triggered by certain types of access, including read, write, execute, and attribute changes.

The syntax to define watch rules is:

To audit user creation actions, first, add a watch to the /etc/passwd file to track write and attribute change access, and add a custom key to log all messages (this custom key is useful to filter log messages):

Next, add a new user. Doing so changes the /etc/passwd file:

Finally, check to see if auditd logged the change.

also grep user-modify /var/log/audit/audit.log will give the similar reports:

Define persistent audit rules

To make auditing rules persistent across reboots, add them to the /etc/audit/rules.d/audit.rules file (or /etc/audit/rules.d). This file contains auditctl commands as they would be entered on the command line but without the auditctl command in front.

as an example lets define persistent rules in the audit.rules file to watch /etc/passwd file for changes.

aureport

Use the aureport tool to query and create audit reports based on audit logs.

For example, to generate a report of all executable events, run:

some other options:

autrace

autrace is a command line utility that runs a program until it exits, just like strace; it adds the audit rules to trace a process and saves the audit information in /var/www/audit/audit.log file. For it to work (i.e before running the selected program), you must first delete all existing audit rules.

Lets draw a big picture, it might be usefull for people who want to know more:

/usr/share/doc/audit

it is important to know that there are some pre-defined audit rules in /usr/share/audit

pam_tty_audit

The pam_tty_audit PAM module is used to enable or disable TTY auditing. By default, the kernel does not audit input on any TTY.

for example to Audit all administrative actions. add bellow line to pam_tty_audit :

and use aureport --tty . for more information read man pam_tty_audit .

Sending auditd messages to remote systems

Install audispd-plugins package To send to auditd on another server:

Configure client system:

  • Edit /etc/audisp/plugins.d/au_remote.conf

Set active=yes

  • Edit /etc/audisp/audisp-remote.conf

Set remote_server = target-server-hostname

Configure auditd server :

  • Edit /etc/audi/auditd.conf:

Set tcp_listen_port = <port_num>

Note there is not a default port Set SELinux port context for chosen port

Restart auditd: requires reboot

Sending auditd messages to remote syslogd

Edit /etc/audisp/plugins.d/syslog.conf

Set active=yes

that's all.

.

.

.

resources:

https://www.redhat.com/sysadmin/linux-security-aide

https://www.teimouri.net/what-is-openscap/#:~:text=OpenSCAP%20is%20an%20auditing%20tool,content%20and%20defines%20security%20checklists.

https://www.rfxn.com/projects/linux-malware-detect/

https://www.tecmint.com/install-linux-malware-detect-lmd-in-rhel-centos-and-fedora/

https://linuxhint.com/about_rootkits_detection_and_prevention/

https://linux-audit.com/intrusion-detection-linux-rootkits/

https://www.kali.org/tools/chkrootkit/

https://www.tecmint.com/install-rootkit-hunter-scan-for-rootkits-backdoors-in-linux/

https://linuxhint.com/auditd_linux_tutorial/

https://www.redhat.com/sysadmin/configure-linux-auditing-auditd

https://www.tecmint.com/linux-system-auditing-with-auditd-tool-on-centos-rhel/

https://www.tecmint.com/audit-linux-process-using-autrace-on-centos-rhel/

https://documentation.suse.com/sles/12-SP4/html/SLES-all/cha-audit-comp.html

https://goteleport.com/blog/linux-audit/

https://documentation.suse.com/sles/12-SP4/html/SLES-all/cha-audit-comp.html

.

Previous332.1 Host HardeningNext332.3 Resource Control

Last updated