Behebung häufiger Sicherheitskonfigurationsprobleme in RabbitMQ

Sicherheitskonfigurationsprobleme in RabbitMQ äußern sich normalerweise in fehlgeschlagenen Anmeldungen, 403 ACCESS_REFUSED-Fehlern oder TLS-Handshakes, die nie abgeschlossen werden. Die Behebung hängt davon ab, wo die Verbindung fehlschlägt: Authentifizierung, Vhost-Zugriff, Ressourcenberechtigungen oder Zertifikatsvalidierung.

Verwenden Sie diesen Leitfaden, um diese Ebenen der Reihe nach zu überprüfen. Er konzentriert sich auf praktische RabbitMQ-Befehle und Konfigurationspunkte, die Sie ohne Rätselraten überprüfen können.

Probleme mit Benutzerberechtigungen und Zugriffskontrolle

Das häufigste Sicherheitsproblem resultiert aus falschen Benutzerberechtigungen. RabbitMQ verwendet ein granulare Zugriffskontrollsystem, das auf Tags und Ressourcenberechtigungen (configure, write, read) für Exchanges, Queues und Bindings basiert.

Diagnose fehlender Berechtigungen

Wenn eine Anwendung keine Verbindung herstellen, Nachrichten veröffentlichen oder konsumieren kann, besteht der erste Schritt darin, die effektiven Berechtigungen des Benutzers zu überprüfen. Sie können das RabbitMQ Management Plugin Interface oder das Befehlszeilentool rabbitmqctl verwenden.

Häufige Symptome:

• Die Verbindung wird geöffnet, aber Veröffentlichungs- oder Konsumvorgänge schlagen mit ACCESS_REFUSED fehl.
• Der Benutzer kann in einem vorhandenen Exchange veröffentlichen, aber keine Queue deklarieren.
• Derselbe Benutzername funktioniert in einem Vhost, schlägt aber in einem anderen fehl.

Überprüfen von Benutzer-Tags und -Berechtigungen mit rabbitmqctl

Um die Tags und Berechtigungen des Benutzers zu überprüfen, verwenden Sie:

rabbitmqctl list_users
# Suchen Sie nach dem Benutzer und seinen Tags (z. B. administrator, management)

rabbitmqctl list_user_permissions username
# Zeigt die Vhosts an, in denen der Benutzer configure-, write- und read-Berechtigungen hat.

rabbitmqctl list_permissions -p /your_vhost
# Zeigt Berechtigungen für alle Benutzer in einem Vhost an.

Behebung von Berechtigungslücken

Berechtigungen müssen auf der Virtual Host (Vhost)-Ebene festgelegt werden und müssen oft auf der Ressourcen-Ebene (Exchange/Queue) verfeinert werden.

Beispiel: Gewähren Sie einem Anwendungsbenutzer Zugriff auf Ressourcen, die mit app. auf /app_vhost beginnen:

rabbitmqctl set_permissions -p /app_vhost app_user "^app\\." "^app\\." "^app\\."

RabbitMQ-Berechtigungen sind reguläre Ausdrücke in dieser Reihenfolge: configure, write, read. Vermeiden Sie für die Produktion ".*", es sei denn, die Anwendung besitzt wirklich jede Ressource in diesem Vhost. Wenn app_user nur in orders_exchange veröffentlicht und von processing_queue konsumiert, gewähren Sie Schreibzugriff auf den Exchange-Namen und Lesezugriff auf den Queue-Namen.

Das Tag administrator ist für RabbitMQ-Verwaltungsbenutzer gedacht, nicht für normale Anwendungen. Es gewährt umfassenden Verwaltungszugriff und sollte nicht als Abkürzung zur Behebung von App-Berechtigungen verwendet werden.

Authentifizierungsfehler

Authentifizierungsfehler treten auf, wenn der Broker die Anmeldeinformationen des Benutzers (Benutzername/Passwort) ablehnt, bevor die Zugriffskontrollprüfungen beginnen.

Häufige Ursachen

• Nicht übereinstimmende Passwörter: Das Client-Geheimnis stimmt nicht mit dem in RabbitMQ gespeicherten Passwort überein.
• Falscher Benutzername oder Vhost in der URI: AMQP-URLs enthalten den Vhost-Pfad, daher wird / als %2F codiert.
• Nicht übereinstimmender Authentifizierungsmechanismus: Beispielsweise erfordert ein TLS-Client-Zertifikatsfluss möglicherweise den EXTERNAL-Mechanismus, während Benutzername/Passwort-Clients typischerweise Mechanismen wie PLAIN oder AMQPLAIN verwenden.

Fehlerbehebung bei der Authentifizierung mit Logs

Authentifizierungsfehler werden vom Broker protokolliert. Bei vielen Linux-Paketen befinden sich die Logs unter /var/log/rabbitmq/; containerisierte Bereitstellungen senden Logs normalerweise an stdout oder den Container-Log-Treiber.

Suchen Sie nach Zeilen, die Folgendes enthalten:

=ERROR REPORT==== YYYY-MM-DD HH:MM:SS ===
Error in server: {auth_failed,<<...>>}

Zurücksetzen oder Ändern von Passwörtern

Wenn Anmeldeinformationen verloren gegangen sind oder der Verdacht besteht, dass sie kompromittiert wurden, setzen Sie sie sofort zurück:

# Ändern Sie das Passwort für 'app_user'
rabbitmqctl change_password app_user new_secure_password

SSL/TLS- und Zertifikatskonfigurationsfehler

Bei der Erzwingung sicherer Kommunikation (AMQPS oder sichere WebSockets) sind Probleme mit Zertifikaten und Trust Stores häufige Sicherheitskonfigurationskopfschmerzen.

Symptome eines SSL/TLS-Fehlers

• Client-Verbindungsversuche laufen zeitlich aus oder werden sofort abgelehnt.
• Der Client meldet Fehler wie SSL handshake failed, certificate verify failed oder unknown ca.

Wichtige Konfigurationsprüfungen

A. Serverzertifikatsüberprüfung

Stellen Sie sicher, dass die vom RabbitMQ-Server präsentierte Zertifikatskette gültig und vom Client vertrauenswürdig ist.

1. Server-Setup überprüfen: Überprüfen Sie, ob die korrekten Zertifikats- (.pem oder ähnlich) und Schlüsseldateien in der rabbitmq.conf-Datei für den Listener referenziert werden:

   # Beispiel rabbitmq.conf-Ausschnitt
   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
   

2. Client-Trust-Store überprüfen: Wenn das Serverzertifikat selbstsigniert oder von einer privaten CA signiert ist, muss der Client dieser CA vertrauen.

B. Cipher- und Protokollkonflikte

Wenn sich Client und Server nicht auf eine gemeinsame Cipher-Suite oder TLS-Version einigen können (z. B. Client unterstützt nur TLS 1.2, aber der Server ist nur für TLS 1.3 konfiguriert), schlägt der Handshake fehl.

Definieren Sie unterstützte TLS-Versionen explizit in rabbitmq.conf, wenn Sie eine strenge Protokolldurchsetzung benötigen. Andernfalls ist RabbitMQ von der TLS-Unterstützung abhängig, die von der zugrunde liegenden Erlang/OTP-Laufzeitumgebung und Ihrer RabbitMQ-Version bereitgestellt wird.

# Explizite Definition erlaubter Versionen (z. B. Erzwingen von TLS 1.2 und 1.3)
ssl_options.versions.tcp = [tlsv1.2, tlsv1.3]

C. Client-Zertifikatsauthentifizierung (mTLS)

Wenn Clients Zertifikate vorlegen müssen:

1. Setzen Sie ssl_options.verify = verify_peer.
2. Setzen Sie ssl_options.fail_if_no_peer_cert = true, wenn ein Client-Zertifikat erforderlich ist.
3. Konfigurieren Sie ssl_options.cacertfile oder ssl_options.cacerts_path, damit RabbitMQ der CA vertraut, die die Client-Zertifikate signiert hat.
4. Konfigurieren Sie die zertifikatsbasierte Authentifizierung, üblicherweise mit dem Plugin rabbitmq_auth_mechanism_ssl, und stellen Sie sicher, dass die Zertifikatsidentität einem erwarteten RabbitMQ-Benutzernamen zugeordnet wird.

Probleme mit dem Virtual Host-Zugriff

Benutzer können nur auf Ressourcen innerhalb der Vhosts zugreifen, für die ihnen explizit Zugriff gewährt wurde.

Der Standard-VHost (/)

Wenn ein Benutzer erstellt, aber keinem Vhost zugewiesen wird, kann er keine Verbindung herstellen oder arbeiten. Wenn Sie den Standard-VHost (/) verwenden, stellen Sie sicher, dass der Benutzer dort Berechtigungen hat.

Verwenden Sie die Verwaltungsoberfläche oder rabbitmqctl, um die Vhosts aufzulisten, für die der Benutzer Berechtigungen hat:

rabbitmqctl list_user_vhosts username

Wenn der Benutzer Zugriff auf einen Vhost namens billing_vhost benötigt, stellen Sie sicher, dass der Benutzer verknüpft ist:

rabbitmqctl set_permissions -p billing_vhost app_user "^billing\\." "^billing\\." "^billing\\."

Fazit

Überprüfen Sie RabbitMQ-Sicherheitsfehler in der Reihenfolge: zuerst Listener und TLS, dann Anmeldeinformationen, dann Vhost-Zugriff, dann configure/write/read-Berechtigungen. Diese Reihenfolge verhindert, dass Sie Berechtigungen neu schreiben, wenn das eigentliche Problem eine schlechte AMQP-URL, eine nicht vertrauenswürdige CA oder eine fehlende Vhost-Gewährung ist.