|
<< Klicken Sie, um das Inhaltsverzeichnis anzuzeigen >> Navigation: Technisches > Anmelde-Drosselung und Reverse Proxy |
Der EMIL-Server bremst wiederholte fehlgeschlagene Anmeldeversuche serverseitig aus, um das Erraten von Kennwörtern, PINs und Schnittstellen-Zugangsdaten (Brute-Force) wirkungslos zu machen. Diese Drosselung arbeitet vollständig auf dem Server und greift einheitlich an allen drei Anmeldewegen:
• dem normalen Client-Login (Benutzer/Kennwort),
• dem RITA-PIN-Login am Tablet,
• dem FHIR-Token-Endpunkt (client_credentials der Schnittstellen-Clients).
Alle drei teilen sich denselben Zähler und dieselbe Konfiguration. Gezählt wird je echter Absender-IP-Adresse. Ein erfolgreicher Login setzt den Zähler dieser Adresse sofort zurück; nach einer einstellbaren Ruhephase ohne weitere Fehlversuche verfällt er ebenfalls.
Jeder Fehlversuch erhöht einen Zähler für die Absender-IP. Der Server antwortet dann verzögert, wobei die Wartezeit mit jedem weiteren Fehlversuch exponentiell wächst (ab dem zweiten Versuch spürbar) und bei einem Höchstwert gedeckelt wird. Optional kann ab einer harten Schwelle ganz abgeklemmt werden: Der Server antwortet dann sofort mit HTTP 429 (Too Many Requests) und einem Retry-After-Hinweis, ohne überhaupt noch zu prüfen - das schont zusätzlich die Arbeits-Threads des Servers.
Die Drosselung wird in der config.ini des Servers im Abschnitt [SECURITY] eingestellt. Alle Werte sind optional; fehlt der Abschnitt, gelten die hier gezeigten Voreinstellungen:
[SECURITY]
THROTTLEENABLED=1
THROTTLEBASEMS=500
THROTTLEMAXMS=10000
THROTTLERESETSEC=900
THROTTLEHARDLIMIT=5
TRUSTEDPROXIES=127.0.0.1;::1
• THROTTLEENABLED - Drosselung ein (1) oder aus (0). Voreinstellung 1.
• THROTTLEBASEMS - Grundwartezeit in Millisekunden nach dem ersten Fehlversuch. Sie verdoppelt sich mit jedem weiteren Fehlversuch (500, 1000, 2000, 4000 ...). Voreinstellung 500.
• THROTTLEMAXMS - Obergrenze für diese Wartezeit in Millisekunden. Voreinstellung 10000 (10 Sekunden).
• THROTTLERESETSEC - Ruhephase in Sekunden: Bleiben so lange weitere Fehlversuche einer Adresse aus, wird ihr Zähler vergessen. Voreinstellung 900 (15 Minuten).
• THROTTLEHARDLIMIT - harte Schwelle: Ab so vielen Fehlversuchen wird die Adresse sofort mit HTTP 429 abgewiesen (kein Warten mehr). 0 schaltet das harte Abklemmen ab, es wird dann nur verzögert. Voreinstellung 5.
• TRUSTEDPROXIES - Liste vertrauenswürdiger Reverse-Proxy-Adressen (siehe unten). Voreinstellung 127.0.0.1;::1.
Hinweis: Mit der Voreinstellung THROTTLEHARDLIMIT=5 liefert der Server nach fünf Fehlversuchen derselben Adresse ein klar erkennbares HTTP 429. Setzt man THROTTLEHARDLIMIT=0, wird das harte Abklemmen abgeschaltet und die Drosselung ist von außen kaum sichtbar - es wird dann nur langsamer geantwortet.
Damit die Drosselung je Absender greift, muss der Server die echte Adresse des anfragenden Geräts kennen. Steht zwischen den Clients und dem Server ein Reverse Proxy (etwa Caddy), so ist aus Sicht des Servers zunächst nur der Proxy der Absender - alle Anfragen kämen dann unter ein und derselben Adresse an, und eine einzelne Adresse könnte sämtliche Nutzer aussperren.
Deshalb wertet der Server den vom Proxy gesetzten Kopfzeilen-Eintrag X-Forwarded-For (ersatzweise X-Real-IP) aus - aber nur dann, wenn die Anfrage tatsächlich von einer in TRUSTEDPROXIES eingetragenen Proxy-Adresse kommt. Ein Gerät, das direkt mit dem Server spricht, kann seinen Zähler-Schlüssel also nicht durch eine gefälschte Kopfzeile umgehen.
• Proxy auf demselben Rechner wie der Server: Der Proxy meldet sich als 127.0.0.1 bzw. ::1 - das ist bereits voreingestellt. Es genügt sicherzustellen, dass der Proxy X-Forwarded-For setzt (Caddys reverse_proxy tut das von sich aus).
• Proxy auf einem anderen Rechner (oder in einem Container): Dessen IP-Adresse muss in TRUSTEDPROXIES ergänzt werden (mehrere durch Semikolon oder Komma getrennt), sonst wird X-Forwarded-For ignoriert und alle Clients teilen sich einen Zähler.
Ein passendes, minimales Caddyfile sieht so aus (der Proxy leitet auf den HTTPS-Port des Servers weiter und setzt X-Forwarded-For automatisch):
emil.example.org {
reverse_proxy 127.0.0.1:8444
}
Ein häufiger Aufbau: EMIL läuft im lokalen Netz, und nur die FHIR-Schnittstelle wird über einen ins Internet gestellten Reverse Proxy von außen erreichbar gemacht. Das funktioniert mit der Drosselung problemlos und sogar besonders sauber, weil beide Wege gleichzeitig korrekt behandelt werden:
• Lokale Clients und RITA-Tablets erreichen den Server direkt. Ihr Absender ist die echte Adresse im LAN - sie wird unverändert als Zähler-Schlüssel verwendet, ganz ohne X-Forwarded-For.
• Externe FHIR-Clients kommen über den Reverse Proxy. Steht dessen Adresse in TRUSTEDPROXIES und setzt er X-Forwarded-For, so drosselt der Server je echtem externen Client - genau die Geräte aus dem Internet, die man begrenzen möchte.
Wichtig sind dafür zwei Punkte: Erstens muss die Adresse, unter der der Proxy beim Server ankommt, in TRUSTEDPROXIES stehen (bei lokalem Proxy bereits durch die Voreinstellung abgedeckt). Zweitens muss der Proxy X-Forwarded-For weiterreichen. Die lokalen Clients sind davon unberührt: Da ihr direkter Absender nicht in TRUSTEDPROXIES steht, würde eine etwaige gefälschte X-Forwarded-For-Kopfzeile von ihnen ohnehin ignoriert.
Hinweis: Mehrere externe Schnittstellen-Clients, die sich denselben Internet-Anschluss teilen (gemeinsame öffentliche Adresse), zählen gemeinsam. Das ist dem IP-basierten Verfahren eigen und in der Praxis unkritisch, da ein erfolgreicher Token-Abruf den Zähler sofort zurücksetzt.
Verwandt mit der Anmeldesicherheit ist der serverseitige Signaturschlüssel für die ausgestellten Sitzungs-Token (JWT). Er wird im Abschnitt [CONFIG] der config.ini unter JWTSALT geführt und vom Server selbst verwaltet: Ist er zu kurz oder veraltet, erzeugt der Server automatisch einen neuen, ausreichend langen Zufallswert und vermerkt den Zeitpunkt unter LASTSALTRENEWAL. Dieser Wert muss nicht von Hand gesetzt werden; er darf nicht weitergegeben werden. Der FHIR-Token-Endpunkt nutzt einen eigenen, getrennt in der Datenbank verwalteten Schlüssel.
Nach jeder Änderung in der config.ini muss der Applikationsserver über den Dienst ITC Serverguard neu gestartet werden, damit die Werte wirksam werden.