No. A firewall is the first layer, not the whole defence. Redis documentation says authentication exists as redundancy if the firewall fails, and the Celery security guide warns that firewall misconfiguration and temporarily disabling it are common. Add credentials, TLS, least privilege and monitoring so one mistake is not a breach.
What the vendors say
Redis documentation says access to the port should be denied to everybody but trusted clients, and that Redis is designed to be accessed by trusted clients inside trusted environments. It also explains the purpose of password authentication: to provide a layer of redundancy, so that if the firewall or another protection fails, an external client still cannot use the instance without the password.
Celery's guide makes the same point from the broker side. It says the first line of defence should be a firewall allowing only white-listed machines to reach the broker, and then adds that firewall misconfiguration, and temporarily disabling the firewall, is common in the real world. Good security policy includes monitoring firewall equipment to detect if it has been disabled, accidentally or on purpose. In other words, one should not blindly trust the firewall.
The layers
| Layer | What it stops | What it misses |
|---|---|---|
| Network rules | Outsiders reaching the port | Anyone already inside the allowed range |
| Authentication | Connections without credentials | Eavesdropping, if traffic is unencrypted |
| TLS | Reading or altering traffic in transit | A permitted client that misuses its access |
| Least privilege | A permitted client doing more than needed | Bugs in the broker itself |
| Patching | Known flaws in the broker and clients | Unknown flaws |
| Monitoring | Silent drift and attacks in progress | Nothing, if nobody reads the alerts |
Redis notes that the AUTH command, like every other command, is sent unencrypted, so a password does not protect against someone who can listen on the network. That is why TLS belongs in the stack. See How do you enable TLS for Redis clients, replicas and cluster?.
Why inside is not the same as safe
Allowed ranges are often wide. A rule that permits a whole subnet also permits every host in it, including a build runner, a forgotten test box or a compromised container. If that host can reach an unauthenticated broker, the firewall did nothing. Per-service credentials and permissions mean a compromised neighbour gets only what its account allows.
Steps
- Start with the network. Allow only application hosts to reach client ports, and only cluster nodes to reach node ports. See RabbitMQ ports and Redis Cluster ports.
- Require authentication for every broker. Retire the default accounts. See Redis ACL users and RabbitMQ guest user.
- Encrypt in transit with TLS.
- Give each service its own identity with the smallest set of permissions.
- Test the layers separately. Turn off the firewall rule in a staging copy and check that authentication still blocks you. Remove credentials in staging and check that the network rule holds.
- Monitor changes to the firewall and security group rules, and test from outside on a schedule.
- Keep brokers and client libraries patched.
Treat the test as the control
A control that has never been tested is a hope. The staging exercise in step 5 is the useful part: it shows which layer is carrying the weight, and whether any layer is missing without anyone realising.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how continuous checks catch change that a one time review would miss.
Safeguard's asset discovery and policies help you see what is running and flag risky configuration, and the free scan covers your code and dependencies.
Quick check
If my broker has a password, can I skip the firewall?
No. Redis says authentication is a redundancy layer for when other protections fail. Keep both.
How would I know the firewall was disabled?
Monitor rule changes and test the port from outside on a schedule. Celery's guide recommends monitoring firewall equipment for exactly this.
Sources
Last reviewed: 19 October 2026.
