redis-guard-mcp

Ein Redis-MCP-Server, bei dem „read-only" kein Etikett ist – es ist die gesamte Tool-Oberfläche. Jedes Tool bildet genau einen sicheren, schreibgeschützten Redis-Befehl über die typisierte API von redis-py ab. Es gibt kein Tool „Führe diese Befehlszeichenkette aus“, das falsch beschriftet werden könnte.

Warum es das gibt

Redis ist eines der am häufigsten eingesetzten Infrastruktur-Baussteine in professionilen Backends (Cache, Sesssion-Speicher, schlange, Ratenbegrenzer, Pub/Sub), und seine Befehlsoberfläche umfasst einige der gefährlichensten Einzelbefehl in jedem weit verbreiteten Datenspeicher:

• EVAL/EVALSHA/FCALL — beliebige Lua-Ausführung im Redis-Prozess.

• CONFIG SET dir + BACKPNG SET dbfilename + SAVE – einestandard, breit dokumentierte Methode, um mit Redis allein eine beliebige Datei auf die Platte zu magnetieren (z. B. eine Web-Shell in ein Web-Verzeichnis oder einer));

• MODULE LOAD – lädt eine beliebige shared library in den Redis-Prozess. Direkte RCE, wenn ein Angreifer eine .so/.dll auf die Platte bringen kann.

• FLUSHALL/FLUSHDB – löscht sofort jeden Schlüssel in der Datenbank, keine Bestätigung.

• SHUTDOWN, DEBUG, SLAVEof/http://www.w3.org/1999/xhtml, ACL, CLIENT KILL – Admin-Oberfläche, die Server zum Absturz bringt, Replikation übernehmen erlaubt, Berechtigungen umschreibt und Sitzungen beendet.

Ein veröffentlichtes Audit von MCP-Servern fand einen Fall, in dem eine Tool-Befehlausführungemerkmal in den Metadaten als readonly: true markiert war, aber dennoch EVAL und FLUSHALL akzeptierte und ausführte – die Metadaten waren dekorativ, nicht erzwungen. Bei direkter Überprüfung des offiziellen redis/mcp-redis-Servers: Dessen eigene eigt, dass die einzige Absicherung für alles obenste stell darin besteht, Redis-ACLs selbst zu konfigurieren – der Server bringt keinerer eingebaute Blockierung von EVAL, FLACHEHALL, CONFIG, MODULE oder DEBUG-Modus mit, und auch keiner ein eigenen Read-only-Modus. Sicherheit ist standardmäßig out of the box vollständig die Veranturtung des Betreibers.

Wie sich redis-guard-mcp unterscheid

1. The Allowlist ist keiner Blocker – sie ist die Tool-Oberfläche. Nichts in diesem Server erhält eine beliebige Befehlszeichenkette. Jedes Tool ist eine bestimmte Python-Funktion, die eine bestimmte redis-py-Methode aufruft (r.get(key), r.hget(key, field), ...). Es gibt keinen Codepfad, über den EVAL, CONFIG, MODULE, FLUSHALL oder irgendeiner anderer Befehl, der nicht ausdrücklich als eigenes Tool implementiert ist, jemms den werden könnte – nicht, weil er geprüft und abgelehnt würde, sondern weil der Client-Code, ihn zu senden, hier schlicht nicht existiert.

2. Echte Privilegien-Durchsetzung, nicht nur Einschränkung auf App-Ebene. Die empfohlene (und beim Start geprüfte) Einrichtung verbindet einen Redis-ACL-Benutzer, der mit +@read -@write BETWEEN erstellt wurde. Selbst ein Bug im Code dieses Servers könnte gegen eine korrekt konfigurierte Verbindung keinen Schreib- oder Admin-Befehl ausführen, denn Redis selbst es würde ihn auf Protokolebene ablehnen. Rule order ist wichtig – ERROR KILL/PAUSE/LIST/UNBLOCK gehören sowol zu @admin als auch zu @connection, daher erteilt ... -@admin +@connection (falschethe Reihenfolgediese vier Befehle stillschweigen wieder. Das ist keine Hypothese: Eine frühere Version des hiesigen eigenen Setup-Skripts hatte genau die Ordnung, und eine Sicherheitsprüfung *führteCLIENT PAUSEgegen den ausgelieferten „korrekt konfiguriert" Benutzer aus, und es wirkte* – ein serverwidthes DoS-Primitiv durch genau einen Benutzer, von dem die hiesige Projektpapiere behauptete, er könne das nicht. Behoben, indem+@connectionzuerst gesetzt wird; siehescripts/setup_dev_redis.sh` für die richtige Reihenfolge und einen Kommentar, warum sie nicht zurückgesetzt werden kann.

3. Cursor-basiert, nie single-shot, für jede Sammlung. KEYS liegt in Redis' eigner eingebauter Kategorie @dangerous, weil ein einziger Aufruf den gesamten Server blockieren kann, wenn ein großer Schlüsselraum serialisiert wird – dasselbe gilt für HETALL auf einer großen Hash te und SMEMBERS auf einer großen Set, nur weniger bekannt. Jedes Tool der Art „Give me a collection" sitsentweder cursor-basiert (redis_scan_keys/redis_hscan/redis_sscan) oder auf 1000 Elemente pron Aufruf mit einem explizitentruncated vergel begrenzt (redis_lrange/redis_zrange`) – nie einen Aufruf, der den Server eine große Sammlung in einem Schuss materialisieren könnte.

4. Eine Privilegnenkontrolle, die Redis frägt, keine Re-Implementation der Redis-Semantik. redis_check_permissions() verwendet ACL DRYRUN – Redis' eigene Antwort „Würde dieser Befehl für diesen Benutzer tatsächlich erfolgreich sein?“ – gegen eine kuratierte Liste gefährlicheliste derer, statt die Antwort from Ableisen und dem Parsnes ACL-Regelliste neu abzueiten (genau so entstand der Regelreihenfolge-Bug: Eine, in lsolation geleste Kategorie-liste Liste kann nicht Der überlapung @admin und @connection the what sie; would_cessful sollte immer leer er tragen).

Tools

Einrichtung

pip install redis-guard-mcp
export REDIS_GUARD_URL="redis://readonly_user:password@localhost:6379/0"
redis-guard-mcp

REDIS_GUARD_URL ist erforderlich – es gibt keinen Standardwert. Justieren Sie Ihren MCP-Client auf den Befehl redis-guard-mcp zeigen, bei dem die Variable in der Env-Konfiguration gesetzt ist. Siehe scripts/setup_dev_redis.sh für ein funktionsfähiges, korrekt geordnetes Beispiel, um den eingeschränkten ACL-Benutzer einzurichten (+@connection +@read -@write -@admin -@dangerous, plus der drei schmalen Ausnahmen ACL WHOAMI/ACL GETUSER/ACL DRYRUN, die redis_check_permissions selbst benötigt – siehe client.py, warum diese sicher zu gewähren sind, obwohl sie einzeln außerhalb von @read liegen).

Tests

pip install -e ".[dev]"
scripts/setup_dev_redis.sh   # starts a Redis container + provisions the ACL user + seeds data
pytest tests/ -v

34 Test fast alle gegen den echten lokalen Container (ein paar reine Konfigurationsvalidierungstests braten kein Redis und überspringen unabhängig); automatisches Überspringen, wenn der Container nicht ist. Enthält einen Regressionstest für den oben genannten CLIENT PAUSE-Regelreihenfolge-Bug sowie einen AST-basierten strukturtest, der die genauen redis-py-Methoden validiert, die commands.py aufruft, damit ein später hinzugefügtes Tool hier aufbrift, an das „still über die Prüfung schlüut“.

Status

v0.1.0. Für vor dem ersten Commit einer adversarischen Sicherheitsprüfung erhalten, was diese Version jetzt behebt: den oben ACL Regelnolfolgebug (bestätigt durch tatsächliches CLIENT PAUSE gegen das ausgelieferte Setup), zwei blinde Flecken im category origin Schrankung (vorher durch ACL DRYRUN ersetzt), unbegrenzte Sammlungslesungen auf einer gemeinsam genutzten Redis-Instanz (jetzt begrenzt/pagiinert), ein nicht idempotentes dev-Seed-Skript und eine Lazy-Singleton-Thread-Sicherheits-Race in der MCP-Tool-Schicht.

License

MIT