Document Type: Architectural Constraints & Known Limitations
System: Fedora 43 / Docker Compose Deployment
Last Updated: 2026-01-17

Wazuh agent running in a Docker container cannot read host journald logs.

systemd-journald uses socket-based IPC (AF_UNIX with namespace checks) that enforces:

• PID namespace isolation
• cgroup membership verification
• Explicit trust relationships

Docker containers are intentionally excluded from cross-namespace access.

• Rule 100030 (Firewall Packet Drop) cannot be triggered from containerized agent
• Rule 100031 (Port Scan Detection) similarly affected

✅ SOLVED via Systemd Log Export.

The workaround documentation below is kept for historical context.

1. Host systemd service exports journald → /var/log/firewall/firewall.log via syslog format.
2. Docker volume mounts file → Container /var/log/firewall.log.
3. Wazuh reads via standard syslog localfile config.
4. Result: Full detection enabled (Rule 100030 verified).

While direct journald access remains impossible, this bridging solution provides robust, production-grade ingestion without violating container isolation.

Suricata in host network mode requires a specific network interface to exist.

Suricata uses AF_PACKET sockets bound to interface names (e.g., enp0s3). If the interface doesn't exist, the container exits.

• Suricata container fails on systems with different interface names
• IDS rules (100101-100107) won't trigger

Events take 10-30 seconds to propagate from log → Wazuh → Filebeat → Elasticsearch.

• Wazuh analysisd batch processing
• Filebeat harvester intervals
• Elasticsearch refresh interval (default 1s, but bulk indexing)

• pipeline-test with 5s wait shows false negative (+0 docs)
• Alert verification may require multiple retries

• Increase wait time to 30s for reliable testing
• Use retry loops with exponential backoff (currently 6 retries × 5s)

Elasticsearch runs as a single node with no replication.

• Cluster status is yellow (unassigned replica shards)
• Data loss if container fails
• No horizontal scaling

• Deploy 3+ node cluster for production
• Use persistent volumes with backup strategy

Several containers require elevated privileges:

• firewall-iptables: CAP_NET_ADMIN + host network
• ids-suricata: CAP_NET_ADMIN, CAP_NET_RAW, CAP_SYS_NICE
• vpn-wireguard: CAP_NET_ADMIN, CAP_SYS_MODULE

• Containers with network_mode: host can see all host traffic
• Privilege escalation risk if container is compromised

• Use read-only mounts where possible (:ro)
• Apply SELinux labels (:z already used)
• Limit container capabilities to minimum required

WireGuard VPN is configured with static peers (PEERS=1).

• New VPN clients require container restart
• No dynamic peer enrollment

• Implement proper key management
• Consider WireGuard with external configuration store

Log files grow unbounded:

• logs/api/security.json
• logs/nginx/access.log
• logs/suricata/eve.jsonl

• Disk exhaustion over time
• Potential container failures

• Implement log rotation via logrotate or Docker logging driver
• Set max file sizes in Docker daemon config

Credentials are stored in plaintext:

• .env file contains DB passwords
• LDAP admin password in compose file
• No secrets management

• Use Docker secrets or external vault
• Never commit .env to version control
• Rotate credentials regularly

MailHog is a development mail server that does not deliver external emails.

• test-killchain expects alerts visible at http://localhost:8025
• No real alerting in this configuration

• Replace with SMTP relay (SendGrid, SES, etc.)
• Configure Wazuh email integration with real SMTP

Wazuh agent uses automatic registration which can cause:

• Duplicate agent entries on container recreation
• ERROR: Duplicate agent name requiring manual cleanup

• Use manage_agents -r <id> to remove stale agents
• Consider pre-provisioned agent keys for production