Security

Security & Hardening

LogForge has direct access to your Docker daemon, so a few guardrails go a long way. This checklist focuses on practical defenses without overhauling your deployment.

Network exposure

• Bind to loopback: In Compose, set "127.0.0.1:HOST:CONTAINER" for every published port unless a reverse proxy handles access.
• Reverse proxy: Terminate TLS and enforce authentication (Basic Auth, OAuth, SSO) before exposing any LogForge UI on the internet.
• Segmentation: Place LogForge on an internal network/VPN when managing production clusters.

Docker socket protection

• Avoid direct mounts where possible. The backend and Watchtower sidecar inherit root-equivalent control via /var/run/docker.sock.
• Proxy pattern: Use docker-socket-proxy or similar to allow only the API endpoints LogForge requires (e.g., container inspection, logs, restart).
• Credentials: If you expose the backend API beyond localhost, enforce authentication so unauthorised users cannot pivot to the Docker daemon.

Secrets & credentials

• Store SMTP/webhook tokens in Docker secrets or environment variables sourced at runtime (never commit to git).
• Rotate credentials regularly and review the Notifier delivery history for unexpected destinations.
• Use secret scanners to ensure no sensitive strings enter container logs (and therefore alert payloads).

Host hygiene

• Keep Docker Engine patched; apply security updates promptly.
• Enable automatic restarts (already configured) so services come back after host reboot.
• Limit who can run docker compose on the host; they effectively have root access through the socket.

LogForge configuration

• Auto-update: Leave AUTO_UPDATE=true unless you have a change-management requirement. Staying current patches vulnerabilities quickly.
• Access control: Premium tiers provide RBAC and multi-user support. For the core edition, rely on network controls and reverse proxy auth.
• Audit trails: Periodically export alert history and notifier logs for compliance.

Monitoring & alerts

• Create self-check rules that fire when LogForge services stop sending heartbeats.
• Monitor the Watchtower container for update failures or repeated restarts.
• Forward host system logs to your SIEM to correlate with LogForge events.

Backups & recovery

• Snapshot the named volumes (logforge_core_data, logforge_notifier_data, logforge_alert_engine_data) on a schedule.
• Document the restore procedure: recreate containers with the same compose file, restore volumes, re-issue TLS/credentials.

Stay aligned with the rest of the documentation: revisit Setup for hardening steps, and consult Troubleshooting when diagnosing issues.