FileGuard

FileGuard is a ServerGuard module for monitoring the integrity of important files on a Linux server. It watches the configuration on which the system's security depends and records any change as a security event.

detect a change, classify it, and register an event.

1. Why FileGuard is needed

Many attacks and administration mistakes end up changing system files: a new user appears, sudo rules change, a systemd service or cron job is added, or the SSH configuration is weakened.

Without monitoring, such changes can go unnoticed for a long time. FileGuard runs continuously and reports them immediately.

This type of protection is called File Integrity Monitoring (FIM).

2. What FileGuard monitors

The module watches configuration directories and individual critical files.

The following critical files are also monitored:

/etc/passwd
/etc/shadow
/etc/group
/etc/gshadow
/etc/sudoers
/etc/crontab
/etc/ssh/sshd_config

FileGuard protects the server's configuration. It does not create events because of ServerGuard's own operation.

3. Which events are recorded

4. How monitoring works

FileGuard uses a Linux kernel mechanism — inotify. The kernel itself reports a file change, so there is no need to constantly re-read files.

File change
       |
       v
  Linux kernel (inotify)
       |
       v
    FileGuard
       |
       +---- check: should the path be monitored
       +---- obtain the new file state
       +---- compare with the old state
       +---- determine the severity level
       +---- merge duplicates
       |
       v
   Event log

Most of the time the module is idle and places almost no load on the CPU.

5. Baseline — the reference state

On first start, FileGuard creates a baseline: a snapshot of the state of the monitored files.

Server state on first start
                |
                v
            baseline
                |
                v
     comparison with the current state

If a file later differs from the baseline, an event is created.

6. What is remembered about each file

exists   — whether the file exists
type     — file or directory
size     — size
mode     — access permissions (for example 0644)
uid/gid  — owner and group
sha256   — checksum of the contents

The contents of the files themselves are not written to the log — only metadata and the checksum. That way, confidential settings do not get into events.

7. Severity levels

Example:

[FILEGUARD] CRITICAL
Event: modified
File:  /etc/ssh/sshd_config

8. Protection against unnecessary events

To keep the log useful, FileGuard:

• ignores temporary and backup files (.tmp, .swp, .bak, and similar);
• merges duplicate events, for example when an editor saves a file in several operations;
• distinguishes between a change of contents and a change of permissions only.

9. Example event

{
  "timestamp": "2026-09-30T19:20:11+00:00",
  "type": "modified",
  "severity": "CRITICAL",
  "path": "/etc/ssh/sshd_config",
  "old_state": { "sha256": "…", "mode": "0o644" },
  "new_state": { "sha256": "…", "mode": "0o644" }
}

Time is recorded in UTC. The log keeps a limited number of the most recent events.

10. Scenario: SSH configuration change

Someone edits /etc/ssh/sshd_config
              |
              v
   inotify reports the change
              |
              v
  SHA-256 differs from the previous one
              |
              v
 event: modified, severity CRITICAL
              |
              v
 log entry + notification to the administrator

11. Background operation

FileGuard runs on the Linux server itself as a system service and does not depend on whether the ServerGuard application is open on your computer.

The state is preserved across restarts, so after a server reboot monitoring continues with the previous data.

The module shuts down gracefully when the service is stopped.

12. Notifications

FileGuard only detects and records events. Other ServerGuard modules can then use them; for example, the Telegram Bot sends a notification to the administrator.

FileGuard  →  event log  →  Telegram / ServerGuard

13. What FileGuard does not do

FileGuard is one of the layers of protection. It does not:

• block file changes;
• automatically restore changed files;
• delete malicious files;
• block users or IP addresses;
• act as an antivirus;
• analyze whether a specific line in a configuration is dangerous.

It reports what changed and when. The decision on further action is made by the administrator or other security components.

14. How to verify that it works

It is recommended to test on a test server.

1. Make sure the service is running:

sudo systemctl status serverguard-fileguard.service

2. Change a test file in a monitored directory, for example add a file to /etc/cron.d/.
3. Review the events:

sudo journalctl -u serverguard-fileguard.service -n 100 --no-pager

Continuous viewing:

sudo journalctl -u serverguard-fileguard.service -f

Do not delete or modify real system files on a production server just for a test.

15. Diagnostics

16. Recommendations

• run FileGuard as a systemd service as root;
• restrict access to the logs and state files to trusted administrators only;
• do not add directories where logs, cache, or temporary data constantly change for monitoring;
• use FileGuard together with the other modules: SSH Hardening, Security, SSH Key Guard, and Telegram notifications;
• regularly review events and investigate unfamiliar changes.

17. Summary

FileGuard turns the monitoring of important Linux files into an automatic process:

detect  →  classify  →  save  →  report

It is responsible for a separate layer of security — server configuration integrity — and together with the other ServerGuard modules forms multi-layered protection.

This documentation describes the purpose and operating principles of FileGuard at the user level. Internal implementation details belong to the developers' technical documentation.