fix: bind Redis to 127.0.0.1 to prevent exposure in host network mode

[kamjin3086]

Summary

• Security fix: Adds --bind 127.0.0.1 to the bundled redis-server command in deploy/docker/supervisord.conf
• When running with network_mode: host (common for transparent proxy setups like daed), Redis was listening on 0.0.0.0 by default, exposing it to the entire network without any authentication
• The application already connects to Redis via localhost:6379, so this change has zero impact on functionality

Problem

The Crawl4AI Docker image bundles a Redis server managed by supervisord. When users deploy with network_mode: host (which is the recommended approach for transparent proxy compatibility), the Redis server binds to 0.0.0.0:6379 by default. This means:

1. Unauthenticated access — Redis has no password set (password: "" in config.yml)
2. Network-wide exposure — Any host on the same network can connect directly
3. Known attack vector — Redis RCE via CONFIG SET dir / CONFIG SET dbfilename is a well-documented exploitation path

I discovered this on my own server after noticing 19,000+ SSH brute-force attempts coming through an frp tunnel — while investigating, I found Redis was also wide open on 0.0.0.0:6379.

Solution

One-line change in deploy/docker/supervisord.conf:

-command=/usr/bin/redis-server --loglevel notice
+command=/usr/bin/redis-server --bind 127.0.0.1 --loglevel notice

Why this is safe

• Crawl4AI's server.py connects to Redis via localhost:6379 (line 211-212)
• 127.0.0.1 IS localhost — the application works identically
• No configuration changes needed in config.yml
• No breaking changes for any deployment mode (bridge, host, etc.)

Alternative approaches considered

Approach	Pros	Cons
--bind 127.0.0.1 (this PR)	Minimal change, zero risk, works for all modes	None
Add requirepass	Defense in depth	Requires config.yml + env var changes for users
Remove network_mode: host	Better isolation	Breaks transparent proxy setups (daed, etc.)

Testing

Verified on a live deployment with network_mode: host:

# Before fix
$ ss -tlnp | grep 6379
LISTEN  0  511  0.0.0.0:6379  0.0.0.0:*

# After fix
$ ss -tlnp | grep 6379
LISTEN  0  511  127.0.0.1:6379  0.0.0.0:*

# Application still works
$ curl http://localhost:11235/health
{"status":"ok","version":"0.8.6"}

---

Thanks for building such a great tool — this was discovered during a security audit of my own deployment. Hope this helps other users avoid the same pitfall!