> For the complete documentation index, see [llms.txt](https://book.bsdcn.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://book.bsdcn.org/ask/flat/chapter-30-security-auditing/di-30.2-jie-ru-qin-jian-ce-xi-tong-ids.md). # 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: ```sh 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: ```sh # 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: ```sh # 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. ```sh mtree: /bin checksum: 492144657 ``` If no binaries in the directory have changed, **/home/ykla/.bin\_chksum\_output** will be an empty file. ```sh # 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: ```sh # touch /bin/cat ``` Run the verification command again: ```sh # 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: ```sh # cat /home/ykla/.bin_chksum_output ``` The output should resemble the following: ```sh 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://book.bsdcn.org/ask/flat/chapter-30-security-auditing/di-30.2-jie-ru-qin-jian-ce-xi-tong-ids.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.