Detect evidence of break-in attempts with host-based intrusion detection systems
Stop, Thief
A host-based intrusion detection system is a simple but powerful tool for finding traces of an attacker's footprint.
If your existence depends on extreme security, you could put your computers in a bunker and avoid external network connections, but unless you happen to be dealing with nuclear missiles, the realities of doing business might require you to configure some form of Internet access, and the price for joining the information superhighway is a need to watch for attackers attempting to penetrate your network.
IT professionals deploy a dizzying variety of tools for protecting the modern network, from firewalls to sophisticated intrusion prevention frameworks. (See the box titled "NIDS, IPS, HIDS.") One useful class of tools that receives less attention than it used to is the humble host-based intrusion detection system (HIDS). HIDS systems perform checks on a single host computer to look for indications of a recent attack.
NIDS, IPS, HIDS
When the alarm bells ring, the occupants of a house become aware that a burglar is present. In the world of computers, a network-based intrusion detection system (NIDS) silently raises an alert and helps the administrator track or intercept the attacker.
A related tool called an intrusion prevention system (IPS) automatically raises the drawbridge before the assumed attacker can even cross the moat; for example, by adjusting the firewall rules – either by blocking entry or by redirecting to a honeypot, where the attacker can rummage to their heart's content. Administrators can learn from observing the attacker's approach and thus improve the security of their systems.
Inspecting ransacked cabinets and broken window panes is an admittedly late way of detecting intrusions, but this approach is precisely what any host-based intrusion detection system (HIDS) does. Because latecomers typically miss out on everything in life, HIDS is not a very popular approach on today's networks. But this attitude fails to account for the fact that computer crackers often do not leave any obvious traces. Without an HIDS, the victim might not ever discover that they have had uninvited guests. A simple tool for finding information about what the attacker changed also tells the administrator where to look for malware, which is a big help during forensic analysis.
HIDS works on the principle that every attacker leaves tracks. In forensics, this assumption is known as Locard's exchange principle: Interaction always causes change. The trick is to identify this change and draw the right conclusions [1].
The HIDS was once a primary line of defense, although today's enterprise networks often opt for bigger and more comprehensive network-based systems. In the spirit of Unix, however, a simple tool with a specific purpose is often a healthy addition to the admin toolkit. A typical HIDS system takes one of the following approaches for detecting the footprint of a past attack:
- track changes to the filesystem
- analyze logfiles
- search for malware
In this article, I describe some popular HIDS tools that highlight each of these approaches. You'll also learn about some all-in-one tools that combine these techniques with a single tool.
Changes to the Filesystem
An attacker gets extreme pleasure from breaking into a third-party system through a buffer overflow. But once the intruder is inside, the work becomes much more monotonous. The attacker starts by installing a rootkit to provide convenient access. To set up a rootkit, the intruder adds software to the system and executes this software – which is something a system administrator might notice when running ps
. To use a backdoor to control the target system, the attacker needs a network listener, resulting in an open port that would normally be visible to netstat
. Attackers need to prevent their programs from appearing in the output of typical admin tools. Traditionally, intruders replaced the executables for common admin utilities like ps
and netstat
with fake versions that conceal their presence. More modern approaches, such as kernel rootkits, install a separate kernel module that blocks the visibility of rootkit processes in the kernel itself.
Administrators can identify Linux tools replaced by intruders on the basis of the different modification and creation times, the file sizes, or the fact that binaries use different inodes. In practical terms, administrators who are not using some form of automated security system will never notice the change because manual checks are far too time-consuming. Classical HIDS tools like Tripwire [2], AIDE [3], or the newer AFICK [4] provide an automated means for finding filesystem changes.
The syntax these free tools use in their configuration files is very similar. AFICK, which is written in Perl, actually advertises its Tripwire compatibility. All three tools create a list of critical files and directories, along with their modification and creation times, sizes, inode numbers, and permissions. Comparing these parameters with the results of later checks helps identify attacks.
Of course, capable attackers are likely to build their malware so that the file sizes are identical; they will set identical access times using touch
, keep the file permissions, and bundle the modified files into the same inodes (cat newps > ps
). The HIDS, however, does not just keep records of the visible data but also of the files' hash values.
AIDE even offers the ability to apply multiple hash processes in parallel to make collisions even less likely: For MD5, the probability is less than 264, and less than 2128 for SHA-256. The probability of a collision in both procedures is thus less than 2192, that is about 1.5x1058. The comparison: If you play the lottery, your chances of winning a jackpot are 7x109.
AIDE is a good example of an HIDS tool that looks for file changes. On Debian-based systems, install AIDE with
apt-get install aide
You can modify the configuration to suit your needs. To change the configuration, edit the /etc/aide/aide.conf
file, and for special cases, also /etc/aide/aide.conf.d
. The objective is to make sure AIDE keeps an eye on all the relevant programs and configuration files.
The aide.conf
file is also where your own macro definitions will reside. Studying the macro definitions can save you a huge amount of work when it comes to writing rules. AIDE detects any new files created – for example, as a consequence of a core dump, which is sometimes associated with a buffer overflow. (Core dumping is disabled by default on most current flavors of Linux [5].)
The default configuration offers meaningful rulesets for logfiles and for determining the system status. The configuration file even contains a good explanation for how to derive your own ruleset.
AIDE uses update-aide.conf
to update its configuration; you can type aide -D
to perform a syntax check. The command
aideinit -y -f
initializes the database. AIDE now computes the hashes – a process that took some 10 minutes on the virtual machine in my lab. Because a cron job is automatically installed when you install AIDE, the tool checks the changes and mails them to the root user. AIDE can also output the results to any URL (aide.conf
report_url
entry) so you can collect reports in a central location.
AIDE emulates its role models so closely – you can easily migrate the setup I just described to Tripwire.
Logs, Logs, Logs
Any admin's daily chore list should include checking the log files. Did a process unexpectedly terminate? Was the process restarted – either by a watchdog or by an attacker attempting to conceal their tracks? Do any other clues indicate attempted intrusions? Regularly investigating the logs helps you identify problems. Fortunately, some tools help administrators combat any tendency toward laziness – these tools analyze logfiles, filter out potentially critical messages, and mail the results to the admin.
Logsentry [6] (formerly called Logcheck) is a useful analysis tool: This simple but complete HIDS consists entirely of shell scripts and configuration files. Logsentry saves administrators the trouble of thinking about the right grep
commands to detect attacks on the basis of logfile analysis. Download Logsentry, then install it with the following commands:
tar -xzf logcheck-1.3.17.tar.gz cd logcheck-1.3.17 make linux
It is a good idea to set up a cron job to check your logs regularly. Still working as root, type
crontab -e
to open the crontab for editing. The line
makes sure the logcheck.sh
test script runs every hour. If you want to check more than the three logfiles configured by default, modify logcheck.sh
from line 172 using the preceding lines as an example. Logcheck defines its rules in multiple configuration files below /etc/logcheck
.
Everything in logcheck.hacking
appears right at the top of the mail message to root. The logcheck.violations
follow slightly lower down. Everything that is not excluded by ignore
ends up in the message – including Unusual system events. The only important thing is to make sure you don't leave logcheck.ignore
empty – this would be equivalent to a wildcard that ignores everything, thus rendering the tool useless.
Logsentry and its siblings save administrators some work, but this is actually all they do. Anyone who needs to inspect their logfiles regularly is likely to have programmed a simple search script of their own that filters out non-critical messages. Logsentry does exactly the opposite: When you set up the tool, you need to know exactly what critical messages look like. The tool only filters for known suspects, not for assumed non-suspects.
Also, the practice of checking logfiles relies on the attacker lacking ability. Any capable attacker will clean the logfiles on the guest system before leaving, and Logsentry will not find anything suspicious. The attacker will probably have enough time to clean up, depending on how often cron runs Logsentry. In general, a tool that looks for attackers by checking logfiles is only useful if it runs in combination with other systems.
Searching for Malware
If log analysis and file checks reveal the aftermath of an infection, it makes sense to look for the malware code. This task is handled by malware scanners, which also exist for Linux. ClamAV [7] is one example. The demarcation between malware scanners and host-based intrusion detection systems is not clearly defined; most antivirus scanners use both signatures and heuristics to detect attacks.
Programs such as Chkrootkit [8] and RKHunter [9] (a tool written in Perl) use a more specific approach; both of these tools were last updated in 2014, and you can install both on Ubuntu as root with the following commands:
apt-get install chkrootkit apt-get install rkhunter
Chkrootkit is a shell script that attempts to identify rootkits based on various parameters. You can run Chkrootkit without specifying any parameters. Among other things, the Chkrootkit script uses strings
to detect suspicious strings, checks the lastlog
to see if anyone has removed entries, checks to see if ps
is not showing certain process IDs, and looks for missing information in /proc/
(Figure 1).
RKHunter has a more sophisticated approach. The hunter's configuration file is named /etc/rkhunter.conf
. (I had some issues setting up RKHunter on my Ubuntu system – see the box titled "Ubuntu Fix.")
Ubuntu Fix
I had to do some troubleshooting when installing RKHunter on my Ubuntu system. The program had a need for lwp-request
, although it was not installed. I changed this as follows:
cpan Mock::LWP::Request
However, Perl dumped the tool into /usr/local/bin/lwp-request
, much to RKHunter's surprise – this means that you need to edit the /usr/bin/
path manually in the configuration file.
You can initialize RKHunter and check the system for rootkits and conspicuous files:
rkhunter --propupd rkhunter --check
Figure 2 gives an impression of what RKHunter considers to be a potential attack. You can run both Chkrootkit and RKHunter on a daily basis using cron, and they will thus become part of your HIDS.
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
Halcyon Creates Anti-Ransomware Protection for Linux
As more Linux systems are targeted by ransomware, Halcyon is stepping up its protection.
-
Valve and Arch Linux Announce Collaboration
Valve and Arch have come together for two projects that will have a serious impact on the Linux distribution.
-
Hacker Successfully Runs Linux on a CPU from the Early ‘70s
From the office of "Look what I can do," Dmitry Grinberg was able to get Linux running on a processor that was created in 1971.
-
OSI and LPI Form Strategic Alliance
With a goal of strengthening Linux and open source communities, this new alliance aims to nurture the growth of more highly skilled professionals.
-
Fedora 41 Beta Available with Some Interesting Additions
If you're a Fedora fan, you'll be excited to hear the beta version of the latest release is now available for testing and includes plenty of updates.
-
AlmaLinux Unveils New Hardware Certification Process
The AlmaLinux Hardware Certification Program run by the Certification Special Interest Group (SIG) aims to ensure seamless compatibility between AlmaLinux and a wide range of hardware configurations.
-
Wind River Introduces eLxr Pro Linux Solution
eLxr Pro offers an end-to-end Linux solution backed by expert commercial support.
-
Juno Tab 3 Launches with Ubuntu 24.04
Anyone looking for a full-blown Linux tablet need look no further. Juno has released the Tab 3.
-
New KDE Slimbook Plasma Available for Preorder
Powered by an AMD Ryzen CPU, the latest KDE Slimbook laptop is powerful enough for local AI tasks.
-
Rhino Linux Announces Latest "Quick Update"
If you prefer your Linux distribution to be of the rolling type, Rhino Linux delivers a beautiful and reliable experience.