# 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`](https://github.com/Tecnativa/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](Setup.md) for hardening steps, and consult [Troubleshooting](Troubleshooting.md) when diagnosing issues.