30.2 Intrusion Detection Systems (IDS)

mtree generates directory checksum specifications using a seed value, which can be compared afterwards to identify file changes. This section covers the complete workflow of specification creation, simulated tampering, and verification.

Intrusion Detection System (IDS)

Verifying the integrity of system files and binaries is an important means for system administrators and security teams to stay informed of changes. Any software capable of monitoring system changes is collectively referred to as an Intrusion Detection System (IDS).

FreeBSD natively includes a basic IDS — mtree. However, while nightly security emails report changes, the information is stored locally, and a malicious user may still have the opportunity to tamper with records to cover their actions. Therefore, it is advisable to create a separate set of binary signatures and place them in a read-only directory owned by root; storing them on a removable USB disk or a remote server is even better.

It is recommended to run freebsd-update IDS after each update. Currently, this command is incompatible with PkgBase, producing the following error:

freebsd-update is incompatible with the use of packaged base.  Please see
https://wiki.freebsd.org/PkgBase for more information.

Generating a Specification File

The built-in mtree tool can generate a specification of directory contents. Specification generation relies on a seed value (a numeric constant), which is also required for subsequent checks, to determine whether files or binaries have been modified. Without knowledge of the seed value, it is extremely difficult or even infeasible for an attacker to forge or match checksums.

It is recommended to generate specifications for directories containing binaries and configuration files, as well as all directories containing sensitive data. Common targets include /bin, /sbin, /usr/bin, /usr/sbin, /usr/local/bin, /etc, and /usr/local/etc.

The following example generates a set of SHA-512 hash values for each system binary under /bin and stores them in a hidden file /home/ykla/.bin_chksum_mtree in the user's home directory:

# mtree -s 123456789 -c -K cksum,sha512 -p /bin > /home/ykla/.bin_chksum_mtree

Tip

The 123456789 and /home/ykla in the above example are placeholders and must be replaced with actual values.

123456789 represents the seed value, which should be chosen randomly. The seed value should be memorized and must not be disclosed.

The output should resemble the following:

mtree: /bin checksum: 492144657

At the same time, care should be taken to prevent malicious users from obtaining the seed value and checksum output.

Specification File Structure

The mtree format describes a collection of file system objects, typically used to create or verify directory hierarchies.

An mtree file consists of a series of lines, each describing one file system object (mtree always ignores leading whitespace).

FreeBSD system specifications are stored in the /etc/mtree directory.

The specification file created earlier can illustrate its format and content:

#	   user: ykla	# User who created the specification
#	machine: ykla	# Hostname of the machine
#	   tree: /bin	# Directory path
#	   date: Mon May  4 18:35:28 2026	# Date and time the specification was generated

# .
/set type=file uid=0 gid=0 mode=0555 nlink=1 flags=uarch	# ①
.               type=dir mode=0755 nlink=2 time=1777888070.971124000
    \133        nlink=2 size=11384 time=1777874933.000000000 \
                cksum=490895202 \	# ②
                sha512=a86c4119b31f6b51a61de9b257e195f3809ed16360ba1bec7f75a13e10c24c2959338f59735f8fea76cf32b140194487080b2dd33374d09cf003ea0cf5ccfbf2
    cat         size=13424 time=1777874930.000000000 cksum=3028726120 \	# ③
                sha512=3512dafe9764cd4dd94941cd0e9fb35f3c430bb39bd2897fe1011d33b7477bf2e7bf0dd4cc0268aef42ee87dafa987c6e1a3c96a8062ab27feb737849422ecc6
    chflags     size=7944 time=1777874930.000000000 cksum=3958012774 \	# ③

……partial output omitted below……

Content explanation:

• ①: The /set special command defines partial settings extracted from the analysis file.
• ②: References the parsed directory, indicating its type, mode, hard link count, and UNIX-format modification time, among other information.
• ③: References a file, showing its size, time, and a series of integrity checksum hash values.

Verifying the Specification File

To verify whether binaries have changed, compare the current directory contents against the previous specification and write the results to a file.

This command requires the same seed value used to generate the original specification:

# mtree -s 123456789 -p /bin < /home/ykla/.bin_chksum_mtree >> /home/ykla/.bin_chksum_output

This command should output the same /bin checksum as when the specification was created.

mtree: /bin checksum: 492144657

If no binaries in the directory have changed, /home/ykla/.bin_chksum_output will be an empty file.

# cat /home/ykla/.bin_chksum_output
#

To simulate a change, first use touch to modify the timestamp of /bin/cat, then run the verification command:

# touch /bin/cat

Run the verification command again:

# mtree -s 123456789 -p /bin < /home/ykla/.bin_chksum_mtree >> /home/ykla/.bin_chksum_output
mtree: /bin checksum: 492144657

Then check the output content of the /home/ykla/.bin_chksum_output file:

# cat /home/ykla/.bin_chksum_output

The output should resemble the following:

cat:    modification time (Mon May  4 14:08:50 2026, Mon May  4 18:42:53 2026)

The above is an example of command output showing the situation after metadata modification.

Exercises

1. Use mtree to create an integrity baseline for the /etc directory, then manually modify /etc/motd and add a user, and run mtree again to detect changes. Map each detection output to the corresponding modification operation and explain the meaning of each detection record.
2. Consult the documentation for AIDE (Advanced Intrusion Detection Environment), compare the differences in features between mtree and AIDE, and explain why AIDE is typically chosen over the system's built-in mtree in production environments.
3. Design an experiment: install a rootkit demonstration tool (such as chkrootkit), run it and read its detection logic, and analyze based on IDS principles why integrity checking tools can or cannot detect kernel-level rootkits.