Installing, configuring and using chkrootkit vulnerability scanner

In my previous post about the vulnerability scanner rkhunter , the chrootkit scanner was mentioned in the comments by the Indexator user. With a similar functionality with rkhunter, there are a number of differences that it will be interesting to consider in this article. It is also interesting that a new version of the scanner was recently released, the development of which seemed frozen since 2009.



Chkrootkit is an abbreviation for the phrase "check rootkit" (rootkit scan). In turn, rootkits are called malicious applications designed to hide server penetration and disguise as normal processes or programs in order to gain full access to the server.

The chkrootkit shell script is designed to help system administrators to check the system for known rootkits. The first question that may arise with this information is: Why the shell? Why not perl or bash, like the same rkunter? The developers sought to unify the script as much as possible so that it runs on all systems with a shell. And at the time of the beginning of script development, the same perl was far from everywhere.
')
The essence of the search is simple. Using system tools such as strings and grep (to be more precise, the FAQ on the developer’s website contains a list of used programs - awk, cut, echo, egrep, find, head, id, ls, netstat, ps, strings, sed, uname ) chkrootkit looks for suspicious parts of the code in programs, compares the running processes with the information from / proc, identifying discrepancies.

The tool consists of a number of modules responsible for different verification methods.

• chkrootkit: shell script checking system binary files for modification by rootkits.
• ifpromisc.c: interface for searching for packets interception.
• chklastlog.c: module that checks for the fact of deletion of records from the lastlog log file.
• chkwtmp.c: similar to the previous module, checks the wtmp log file.
• chkutmp.c: checks the utmp log file for signs of deletion of records.
• check_wtmpx.c: relevant to the Solaris OS. verifies that records have been deleted from the wtmpx log.
• chkproc.c: search for traces of known LKM trojans (Linux Kernel Module).
• chkdirs.c: find traces of known LKM Trojans (Linux Kernel Module).
• strings.c: analog strings utility.

Alas, the search for the fact of deleting lines from log files is not 100% guaranteed.

Currently, the latest version is 0.50 dated June 4, 2014. The developers promise scanner operation under FreeBSD starting from 2.0 and others from the * BSD family, various Linux distributions with kernels from 2.2 and higher, MacOS X, Solaris and other more exotic operating systems.

At CentOS, version 0.49 is present in the EPEL repositories, and there is no FreeBSD ports / packages. To build the latest version you will need to install gcc. Using the example of CentOS 6.x, it will look like this:

Install gcc:

yum install gcc 

Download the latest current version from the official ftp:

 wget ftp://ftp.pangeia.com.br/pub/seg/pac/chkrootkit.tar.gz 

Unpack:

 tar -xzf chkrootkit.tar.gz 

Go to the directory:

 cd chkrootkit-0.50 

We assemble modules:

 make sense 

Run the shell script:

 ./chkrootkit 

I checked it the same way on FreeBSD 10.1 - the assembly of the modules and the verification passed without problems.

In principle, it is possible not to assemble modules, and then on checks where additional modules are required, there will be errors like:

 Checking `ldsopreload'... can't exec ./strings-static, not tested Checking `lkm'... not tested: can't exec Checking `sniffer'... not tested: can't exec ./ifpromisc Checking `wted'... not tested: can't exec ./chkwtmp Checking `z2'... not tested: can't exec ./chklastlog Checking `chkutmp'... not tested: can't exec ./chkutmp 

By default, there is a complete system check for all available tests, a list of which can be obtained by running the script with the key '-l'. Unfortunately, I was not able to find in the documentation a description of all the tests that can be run, but this can be discussed in the comments.
Please note that chrootkit does not take a snapshot of the current files and does not save it in its database as the same rkunter.
As startup keys, you can specify which of the tests to run.
For example,

 ./chkrootkit aliens sniffer 

will search for malicious code and running traffic interceptors

Messages that can be issued during scanning

• not infected - the scan did not detect anything suspicious
• INFECTED - the program most likely refers to the rootkit
• not tested - the check was not performed (for this OS, there is no possibility of checking, the absence of a test module, command line parameters were set to disable this check)
• not found - the program was not found and therefore was not checked.
• Vulnerable but disabled - the probability that the application is malicious is great, but at the time of testing it was inactive.

For regular system checks, you can add the chkrootkit scan run to the scheduler as root.

 crontab -e 

 @daily ///chkrootkit | mail -s 'CHROOTKIT Daily Run' @ 

For daily full system scan with all available modules and tests, followed by sending a report to the mailbox.

In ISPmanager5, this can be configured from the convenient scheduler interface, which is located in the “System” section



But due to the high probability that an infected OS may replace values ​​during scanning, it is recommended to run chkrootkit to check the system when the server is booted in recovery mode or from a bootable live image.
In this case, the procedure is as follows:

• boot from live image
• Download the latest version of chkrootkit
• compile modules
• mount disk partitions with (potentially) infected system
• scan chkrootkit -r / mnt /

Official site of the project: http://www.chkrootkit.org/

PS: I wish that on your systems always chkrootkit showed the message “nothing found” or “not infected”.