11.3 Monitoring and Logging

11.3 Monitoring and Logging

A firewall controls what gets in; monitoring tells you what actually happened. Kali inherits Debian's full logging and auditing toolchain, and the KLCP exam expects you to know which tool answers which question: where logs live, how to query them, how they're rotated, and how to detect that a machine has been tampered with.

rsyslog and the /var/log Layout

rsyslog is the traditional system logging daemon. It receives messages tagged with a facility (what subsystem produced them: auth, kern, mail, daemon...) and a priority (severity from debug up to emerg), then routes them according to /etc/rsyslog.conf and files under /etc/rsyslog.d/. The result is the classic text-file layout in /var/log:

You can inject your own test messages with the logger command (logger -p auth.warning 'test message'), which is handy for verifying routing rules. Firewall log lines from section 11.2's LOG target arrive via the kernel facility, so they land in kern.log (and typically syslog as well).

journalctl and the systemd Journal

Alongside rsyslog, systemd captures service output and metadata in a binary journal, queried with journalctl. The journal is not a replacement you can ignore — on a systemd-based Kali, much service output (including early-boot messages) exists only in the journal. Core flags:

• journalctl -u ssh.service — logs for one unit
• journalctl -b — current boot only (-b -1 for the previous boot)
• journalctl -f — follow, like tail -f
• journalctl --since '2026-07-26 08:00' --until '2026-07-26 09:00' — time window
• journalctl -p err — filter by priority (err and above)
• journalctl -k — kernel messages, like dmesg

By default the journal may be volatile (kept in /run/log/journal and lost at reboot); creating /var/log/journal/ or setting Storage=persistent in /etc/systemd/journald.conf makes it survive reboots.

logrotate

Logs grow without bound unless something prunes them. logrotate — run daily via systemd's logrotate.timer (historically cron.daily) — rotates, compresses, and eventually deletes old logs. Global settings live in /etc/logrotate.conf; per-service drop-ins live in /etc/logrotate.d/. A stanza specifies the rotation frequency (weekly), how many generations to keep (rotate 4), whether to compress old logs (compress), and what to do after rotation (often reloading the daemon so it reopens its log file). Knowing where these files live is a favorite exam check.

logcheck: Pushed Log Review

Nobody reads syslog cover to cover every morning. logcheck automates the review: it runs hourly by default, reads the files listed in /etc/logcheck/logcheck.logfiles, filters out known-boring entries using the rule sets under /etc/logcheck/cracking.d/, /etc/logcheck/violations.d/ and /etc/logcheck/ignore.d.{paranoid,server,workstation}/, and emails a digest of everything anomalous to the administrator. Its personality is set by a reporting level in /etc/logcheck/logcheck.conf — workstation (very aggressive filtering), server (the default), or paranoid (report almost everything). The value for the exam is conceptual: logcheck inverts monitoring from pull (you remember to look) to push (anomalies come to you).

Rootkit Scanners: rkhunter and chkrootkit

If an attacker does get in, their next move is usually hiding. Rootkits replace or subvert system binaries (ps, ls, netstat, login) to conceal processes, files, and connections. Kali's two classic scanners:

• rkhunter (Rootkit Hunter): checks for known rootkit signatures, suspicious file properties and permissions, hidden files, wrong strings in common binaries, and unexpected network ports. Typical workflow: rkhunter --update to refresh its data, rkhunter --check to scan, and rkhunter --propupd to accept a new baseline after legitimate system updates — otherwise yesterday's apt upgrade becomes today's false positive storm.
• chkrootkit: a lighter, complementary scanner that checks system binaries against signatures of known rootkits and looks for telltales like interfaces in promiscuous mode or tampered lastlog/wtmp/utmp records. Running just chkrootkit performs the standard battery of tests.

Run both; they overlap but catch different things. Neither is authoritative — treat alerts as leads, not verdicts.

Real-Time Activity: top

top is the interactive process monitor the book singles out: it lists running processes sorted by CPU use by default, and you re-sort with P (CPU), M (memory), T (cumulative CPU time) and N (PID). k kills a process by PID and r renices one. The security value is pattern recognition — an unfamiliar process running as www-data, or eating CPU on a box that hosts nothing, is exactly the anomaly worth chasing. Each desktop also ships a graphical equivalent (xfce4-taskmanager on Kali's Xfce, gnome-system-monitor, ksysguard).

Auditing Packaged Files with dpkg --verify

dpkg --verify (or dpkg -V) compares installed files against the MD5 checksums dpkg recorded at install time in /var/lib/dpkg/info/<package>.md5sums, printing one line per file that fails. Each character of the leading field is one metadata test; dpkg only implements two of them — position 2 (file mode, shown as M) and position 3 (MD5 digest, shown as 5) — so every other position is permanently ?:

# dpkg -V
??5??????   /lib/systemd/system/ssh.service
??5?????? c /etc/libvirt/qemu/networks/default.xml

The letter after the code marks the file type: c means a conffile, so the second line is a legitimately edited configuration file, while the first is a packaged unit file someone modified in place instead of using a systemd override. Know the tool's limit: an attacker with root can rewrite those md5sums files, so dpkg -V is a triage aid, not proof — APT's signature verification is the real defence.

AIDE: File-Integrity Monitoring

AIDE (Advanced Intrusion Detection Environment) takes the opposite approach to signature scanning: it builds a cryptographic database of file attributes — hashes, sizes, permissions, timestamps — and later reports anything that changed. The workflow is strict about ordering:

1. Install AIDE on a known-clean system and run aideinit. On Debian and Kali that wrapper runs aide --init, writes the new database to /var/lib/aide/aide.db.new, and installs it as the reference database /var/lib/aide/aide.db — it only stops to ask if a reference database already exists.
2. Let the packaged daily job (/etc/cron.daily/aide) do the checking, or run one by hand with aide.wrapper --check; the Debian wrapper regenerates the runtime configuration from /etc/aide/aide.conf and /etc/aide/aide.conf.d/ before calling aide. Findings land in /var/log/aide/ and in the administrator's mail.
3. Each daily run writes a candidate database to /var/lib/aide/aide.db.new. When every reported change was legitimate — say an apt full-upgrade — promote that file over /var/lib/aide/aide.db to re-baseline; otherwise investigate before you overwrite anything.

Configuration lives in /etc/aide/aide.conf, which defines which paths are watched and which attributes are compared per path. The integrity of the whole scheme rests on the baseline being clean — initialize it before the box ever touches an untrusted network, and ideally store a copy of the database offline, since a competent attacker who owns the box can re-baseline AIDE to hide their changes.

The Intrusion-Detection Mindset for a Pentest Box

Why does a machine built for offense need defense? Because your Kali box is itself a high-value target: it holds engagement notes, credentials harvested during tests, exploit code, and client data. Compromise of the pentest platform is a reportable incident for your client. So layer the basics: default-DROP firewall rules, services enabled only when needed (Kali already ships with SSH, Apache, and PostgreSQL disabled by default), persistent journals, logcheck or equivalent alerting, periodic rkhunter/chkrootkit runs, and an AIDE baseline taken on day one. Monitoring is not about achieving perfect prevention; it is about shortening the time between compromise and detection — and on an assessment, being able to prove your own infrastructure stayed clean.