{"id":565,"date":"2026-07-04T10:19:31","date_gmt":"2026-07-04T10:19:31","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=565"},"modified":"2026-10-07T22:03:12","modified_gmt":"2026-10-07T22:03:12","slug":"vps-intrusion-detection-fail2ban-rkhunter-aide","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/vps-intrusion-detection-fail2ban-rkhunter-aide\/","title":{"rendered":"Intrusion Detection on a VPS: Fail2ban, AIDE and Rootkit Scans That Survive Reboots"},"content":{"rendered":"
\n\n\n

A firewall and updated packages stop known attacks; they do nothing about a compromised binary or a modified system file. Intrusion detection on a VPS answers three distinct questions: who is currently attacking, is there a rootkit present, and has anything on disk changed since you last trusted it. Fail2ban, RKHunter and AIDE answer those three questions respectively \u2014 and they only work if their output survives a reboot and reaches a human.<\/p>\n\n\n\n

Fail2ban: Blocking the Obvious, Logging the Rest<\/h2>\n\n\n\n

Fail2ban reads logs and adds firewall rules on repeat offenders. The common mistake is tuning it so aggressively that a mistyped password locks you out of your own box. Use findtime<\/code> and maxretry<\/code> deliberately, and always whitelist your own management path.<\/p>\n\n\n\n

sudo cp \/etc\/fail2ban\/jail.conf \/etc\/fail2ban\/jail.local\nsudo tee \/etc\/fail2ban\/jail.local <<'EOF'\n[DEFAULT]\nbantime  = 3600\nfindtime = 600\nmaxretry = 5\nignoreip = 127.0.0.1\/8 ::1 YOUR.MGMT.IP\/32\n\n[sshd]\nenabled = true\nmode    = aggressive\n\n[nginx-http-auth]\nenabled = true\nEOF\nsudo systemctl enable --now fail2ban<\/code><\/pre>\n\n\n\n
Verify the jails actually load rather than assuming:<\/p>\n\n\n\n
sudo fail2ban-client status\nsudo fail2ban-client status sshd<\/code><\/pre>\n\n\n\n
The recidive jail matters on internet-facing hosts. It watches Fail2ban’s own ban history and issues long bans to IPs that return repeatedly \u2014 a single sshd jail only sees one service.<\/p>\n\n\n\n
RKHunter: Scanning for Rootkits and Suspicious State<\/h2>\n\n\n\n
RKHunter checks for known rootkit signatures, hidden files, and unexpected modifications to system binaries. Its weakness is false positives from legitimate package updates, which is exactly why you baseline it on a clean install.<\/p>\n\n\n\n
sudo apt install rkhunter -y\nsudo rkhunter --propupd          # record known-good properties NOW\nsudo rkhunter --check --sk<\/code><\/pre>\n\n\n\n
--propupd<\/code> must be re-run after every legitimate system upgrade. Skip that step and every future scan reports the package manager’s own changes as warnings, training you to ignore real alerts. Schedule the scan and route the output somewhere durable:<\/p>\n\n\n\n
sudo tee \/etc\/systemd\/system\/rkhunter.service <<'EOF'\n[Unit]\nDescription=RKHunter scan\n[Service]\nType=oneshot\nExecStart=\/usr\/bin\/rkhunter --cronjob --report-warnings-only --rwo\nEOF\nsudo systemctl enable --now rkhunter.timer<\/code><\/pre>\n\n\n\n
AIDE: Detecting Change You Did Not Make<\/h2>\n\n\n\n
AIDE builds a cryptographic database of file hashes, permissions and timestamps, then compares against it. The value is in the baseline: an alert that a file changed is noise unless you know it should not have. Initialize on a freshly hardened system:<\/p>\n\n\n\n
sudo apt install aide -y\nsudo aideinit\nsudo mv \/var\/lib\/aide\/aide.db.new \/var\/lib\/aide\/aide.db\nsudo aide --check<\/code><\/pre>\n\n\n\n
On a small VPS, a full scan competes for disk I\/O with your workloads. Constrain AIDE to the paths that matter instead of the whole filesystem:<\/p>\n\n\n\n