Mitigation Strategy: Disable Default Guest User
1. Disable Default Guest User
-
Description:
- Locate the RabbitMQ configuration file (
rabbitmq.conf
oradvanced.config
). - Open the configuration file.
- Set
loopback_users = none
(advanced format) or{rabbit, [{loopback_users, []}]}.
(Erlang term format). - Save the file.
- Restart the RabbitMQ server.
- Verify by attempting to connect with the
guest
user.
- Locate the RabbitMQ configuration file (
-
Threats Mitigated:
- Unauthorized Access (Critical): Prevents use of the default
guest
user/password. - Privilege Escalation (High): If
guest
has excessive permissions.
- Unauthorized Access (Critical): Prevents use of the default
-
Impact:
- Unauthorized Access: Risk reduced from Critical to Low.
- Privilege Escalation: Risk reduced from High to Low.
-
Currently Implemented: Implemented in production via Ansible playbook
rabbitmq_config.yml
. -
Missing Implementation: Missing in the staging environment.
Mitigation Strategy: Strong, Unique Credentials (within RabbitMQ)
2. Strong, Unique Credentials (within RabbitMQ)
-
Description:
- Identify all RabbitMQ user accounts.
- Generate strong, unique passwords for each user (password manager recommended).
- Update passwords using
rabbitmqctl change_password <username> <new_password>
. - Document passwords securely. Note: This focuses on managing passwords within RabbitMQ. External password policies are not directly RabbitMQ-server related.
-
Threats Mitigated:
- Unauthorized Access (High): Reduces risk of password guessing/brute-forcing.
- Credential Stuffing (High): Prevents reuse of stolen credentials.
-
Impact:
- Unauthorized Access: Risk reduced from High to Medium.
- Credential Stuffing: Risk reduced from High to Medium.
-
Currently Implemented: Partially. Strong passwords used in production, managed via password manager.
-
Missing Implementation: Some dev/test environments use weak passwords.
Mitigation Strategy: Limit User Permissions (Principle of Least Privilege)
3. Limit User Permissions (Principle of Least Privilege)
-
Description:
- Identify user roles (producers, consumers, admins).
- Define minimum necessary permissions for each role:
- Virtual Host Access.
- Configure Permissions (exchanges/queues).
- Write Permissions (exchanges).
- Read Permissions (queues).
- Use RabbitMQ's permission model (regular expressions) to define permissions. Be specific; avoid broad wildcards. Example:
rabbitmqctl set_permissions -p /my_vhost my_user "" "my_queue" ".*"
. - Create separate user accounts for each role.
- Regularly review and audit permissions.
-
Threats Mitigated:
- Privilege Escalation (High): Limits access for compromised accounts.
- Data Breach (Medium): Reduces potential damage from compromised accounts.
- Accidental Misconfiguration (Medium): Reduces risk of accidental resource deletion/modification.
-
Impact:
- Privilege Escalation: Risk reduced from High to Low.
- Data Breach: Risk reduced from Medium to Low.
- Accidental Misconfiguration: Risk reduced from Medium to Low.
-
Currently Implemented: Partially. Basic role separation exists, but permissions are not granular enough.
-
Missing Implementation: Permissions are too broad in many cases. Comprehensive review needed.
Mitigation Strategy: TLS/SSL Encryption (Server Configuration)
4. TLS/SSL Encryption (Server Configuration)
-
Description:
- Obtain TLS/SSL certificates.
- Configure RabbitMQ in
rabbitmq.conf
:listeners.ssl.default = 5671 ssl_options.cacertfile = /path/to/ca_certificate.pem ssl_options.certfile = /path/to/server_certificate.pem ssl_options.keyfile = /path/to/server_key.pem ssl_options.verify = verify_peer ssl_options.fail_if_no_peer_cert = true
- Restart RabbitMQ. Note: This focuses on the server-side TLS configuration. Client configuration is not included here.
- For cluster, configure inter-node communication to use TLS.
-
Threats Mitigated:
- Eavesdropping (High): Prevents intercepting messages.
- Man-in-the-Middle (MitM) Attacks (High): Prevents impersonation/modification.
- Data Breach (Medium): Protects data in transit.
-
Impact:
- Eavesdropping: Risk reduced from High to Low.
- Man-in-the-Middle Attacks: Risk reduced from High to Low.
- Data Breach: Risk reduced from Medium to Low (for data in transit).
-
Currently Implemented: Implemented for client-to-server in production. Self-signed certs in dev/test.
-
Missing Implementation: Inter-node communication not yet secured with TLS.
Mitigation Strategy: Connection Limits
5. Connection Limits
-
Description:
- Determine a reasonable maximum number of concurrent connections.
- In
rabbitmq.conf
, setmax_connections = <value>
. Example:max_connections = 1024
. - Save and restart RabbitMQ.
- Monitor connection counts.
-
Threats Mitigated:
- Denial of Service (DoS) (High): Prevents connection exhaustion.
-
Impact:
- Denial of Service (DoS): Risk reduced from High to Medium.
-
Currently Implemented: Implemented with
max_connections = 1024
in all environments. -
Missing Implementation: No per-user connection limits.
Mitigation Strategy: Message Rate Limiting (Queue Length Limit - Server-Side)
6. Message Rate Limiting (Queue Length Limit - Server-Side)
-
Description:
- Identify queues susceptible to flooding.
- Determine a reasonable maximum queue length.
- Set the
x-max-length
argument when creating/modifying the queue. Example (usingrabbitmqctl
):rabbitmqctl set_policy -p /my_vhost my_queue_limit "^my_queue$" '{"max-length": 1000}' --apply-to queues
. - Monitor queue lengths.
-
Threats Mitigated:
- Denial of Service (DoS) (Medium): Prevents queue flooding.
- Resource Exhaustion (Medium): Limits memory/disk usage by queues.
-
Impact:
- Denial of Service (DoS): Risk reduced from Medium to Low.
- Resource Exhaustion: Risk reduced from Medium to Low.
-
Currently Implemented: Implemented on a few critical queues in production.
-
Missing Implementation: Not consistently applied to all queues.
Mitigation Strategy: Resource Alarms (Memory and Disk)
7. Resource Alarms (Memory and Disk)
-
Description:
- Determine appropriate memory and disk space thresholds.
- Configure
vm_memory_high_watermark.relative
inrabbitmq.conf
. Example:vm_memory_high_watermark.relative = 0.4
. - Configure
disk_free_limit.absolute
inrabbitmq.conf
. Example:disk_free_limit.absolute = 50MB
. Note: This focuses on configuring the alarms within RabbitMQ. External monitoring/alerting systems are not included. - Regularly review and adjust thresholds.
-
Threats Mitigated:
- Denial of Service (DoS) (High): Provides early warning of resource exhaustion.
- System Instability (High): Prevents crashes due to resource exhaustion.
-
Impact:
- Denial of Service (DoS): Risk reduced from High to Medium.
- System Instability: Risk reduced from High to Low.
-
Currently Implemented: Basic alarms configured.
-
Missing Implementation: Thresholds may need fine-tuning.
Mitigation Strategy: Minimize Enabled Plugins (Server-Side Action)
8. Minimize Enabled Plugins (Server-Side Action)
-
Description:
- List enabled plugins:
rabbitmq-plugins list
. - Identify unnecessary plugins.
- Disable unnecessary plugins:
rabbitmq-plugins disable <plugin_name>
. - Restart RabbitMQ.
- Regularly review.
- List enabled plugins:
-
Threats Mitigated:
- Vulnerability Exploitation (Medium): Reduces attack surface.
-
Impact:
- Vulnerability Exploitation: Risk reduced from Medium to Low.
-
Currently Implemented: Initial review done; unnecessary plugins disabled.
-
Missing Implementation: Regular reviews not yet part of standard procedures.
Mitigation Strategy: Secure Inter-node Communication (Clustering)
9. Secure Inter-node Communication (Clustering)
-
Description:
- Obtain TLS/SSL certificates.
- Configure
ssl_options
for therabbit
application in the configuration file (rabbitmq.conf
oradvanced.config
). This involves specifying paths to certificate and key files, similar to client-server TLS configuration, but within therabbit
application section. - Restart RabbitMQ nodes.
-
Threats Mitigated:
- Eavesdropping (High): Prevents interception of inter-node traffic.
- Man-in-the-Middle (MitM) Attacks (High): Prevents impersonation or modification of cluster communication.
- Data Breach (Medium): Protects cluster management and data replication traffic.
-
Impact:
- Eavesdropping: Risk reduced from High to Low.
- Man-in-the-Middle Attacks: Risk reduced from High to Low.
- Data Breach: Risk reduced from Medium to Low (for inter-node traffic).
-
Currently Implemented: Not implemented.
-
Missing Implementation: This is a critical missing piece for cluster security.