Monitoring Installation & Lifecycle
Relevant source files
The following files were used as context for generating this wiki page:
The monitoring system in the DNS Hardening Parrot project provides automated oversight of the system's security posture. Its primary purpose is to detect and log unauthorized modifications to critical DNS configurations, specifically targeting the removal of immutable flags on /etc/resolv.conf, the status of the Unbound service, and the integrity of DNS over TLS (DoT) connections.
The lifecycle encompasses automated installation via interactive scripts, periodic execution through cron jobs, stateful monitoring of hardening transitions, and a clean uninstallation process. This system ensures that once the environment is hardened via scripts/dns_harden.sh, any compromise is immediately recorded and potentially alerted via desktop notifications.
Sources: MONITORING.md:1-12, CHANGELOG.md:10-18
Installation Lifecycle
The installation process is managed by dns_monitoring_install.sh, which acts as a wrapper to deploy monitoring scripts to the system's binary path and schedule them using the cron daemon.
Deployment Workflow
- Root Verification: The script ensures it is running with elevated privileges.
- Interactive Configuration: The user selects a monitoring interval (5, 15, 30, or 60 minutes).
- Binary Deployment: Monitoring and alert scripts are moved to
/usr/local/bin/and granted execution permissions. - Scheduling: Cron entries are created for both
dns_monitor.shanddns_alert.sh.
The diagram shows the sequential steps taken by the installer to establish periodic monitoring.
Sources: scripts/dns_monitoring_install.sh:10-60
Monitoring Components
The system utilizes three distinct scripts to handle manual checks, stateful logging, and critical alerts.
| Script | Purpose | Log Location |
|---|---|---|
dns_status.sh | Manual on-demand status check with visual indicators. | Terminal Output |
dns_monitor.sh | Stateful monitoring that logs only when status changes. | /var/log/dns_hardening_monitor.log |
dns_alert.sh | Immediate logging and notification of security compromises. | /var/log/dns_hardening_alerts.log |
Sources: MONITORING.md:108-115, scripts/dns_status.sh:1-40
Stateful Monitoring Logic
dns_monitor.sh maintains persistence using a state file at /var/run/dns_hardening.state. It compares the current status of the immutable flag against the last known state to prevent log spamming.
This flowchart illustrates the stateful logic used to minimize redundant logging.
Sources: scripts/dns_monitor.sh:1-35
Alerting and TLS Verification
The system includes specific checks for the health of the encrypted DNS tunnel.
Alert Conditions
dns_alert.sh triggers an alert if any of the following conditions are met:
- The immutable flag (
i) is missing from/etc/resolv.conf. - The localhost resolver (
127.0.0.1) is no longer the primary nameserver. - The
unboundservice is not active.
Sources: scripts/dns_alert.sh:18-35
TLS Monitoring
The dns_tls_monitor.sh script specifically validates DNS over TLS (DoT) by checking active connections on port 853.
The sequence diagram demonstrates how the system forces DNS traffic to verify that encrypted tunnels are being established correctly.
Sources: scripts/dns_tls_monitor.sh:22-45, UNBOUND_TLS_STATUS.md:65-80
Uninstallation Lifecycle
The dns_monitoring_uninstall.sh script provides a mechanism to revert all changes made during the installation phase.
- Cron Removal: It uses
grep -vto strip the specific monitoring lines from the root crontab. - Binary Cleanup: Deletes the scripts from
/usr/local/bin/. - Optional Log Purge: Interactively asks the user whether to delete historical logs and state files.
Sources: scripts/dns_monitoring_uninstall.sh:13-43
Conclusion
The Monitoring Installation & Lifecycle provides a robust framework for ensuring the continued integrity of the DNS hardening measures. By combining stateful logging, active TLS verification, and automated lifecycle management, the system provides a continuous audit trail and immediate notification of configuration drifts or service failures.
Sources: MONITORING.md:158-170, CHANGELOG.md:40-50