Eine WAF und Rate Limiting ohne separaten Edge-Anbieter

Viel von dem, was ein dedizierter Edge-/WAF-Anbieter verkauft, ist eigentlich einfach ein Reverse-Proxy, der seine Arbeit richtig macht: den Request prüfen, bevor er die App erreicht, nicht danach. Railyard betreibt bereits einen Web-Proxy vor den Apps jedes Servers — das hier sind die Regeln, die dort laufen, die meisten davon konfigurierbar direkt im Settings → Networking-Tab der App, keine separate Anbieterbeziehung nötig.

Was heute live ist, ohne Einschränkung

• Passwort- und IP-Regeln. Setz ein Passwort auf ein Staging- oder Admin-Tool in einem Feld; erlaube oder verweigere bestimmte Adressen oder CIDR-Bereiche, wobei alle anderen einen sauberen 403 bekommen.
• Redirects und Rewrites — bis zu 100 Regeln, der Reihe nach geprüft, der erste Treffer gewinnt. 301/302/307/308 oder ein rewrite innerhalb derselben App, der den Query-String behält. Deaktiviert während des Wartungsmodus, sodass eine Redirect-Regel niemals einen echten Ausfall verschleiert.
• Response-Header und CORS, bis zu 50 Regeln. Setz einen Header, oder entferne einen, den deine App geschickt hat, mit -Name. CORS-Preflights werden vom Proxy selbst beantwortet und erreichen die App nie — was auch bedeutet, dass eine passwortgeschützte App Preflights korrekt mit 401 statt mit einer zuerst durchsickernden CORS-Antwort beantwortet.
• Dein eigenes SSL-Zertifikat. Füge ein PEM-Zertifikat und einen Key ein; Railyard prüft, dass der Key zum Zertifikat passt, das Zertifikat jetzt gültig ist, und dass es tatsächlich eine der Adressen der App abdeckt — vor dem Speichern, nicht nachdem etwas kaputtgeht. Verschlüsselt gespeichert, nie von der API zurückgegeben, und absichtlich aus railyard.yml herausgehalten, damit ein privater Key nie in Git landet.
• Fehler- und Wartungsseiten, mit dem echten Statuscode (502/503/504) statt einem generischen leeren Fehler.

Was echt ist, aber noch ausrollt — ehrlich gesagt

Drei Features existieren und sind heute vollständig konfigurierbar, brauchen aber Railyards eigenes Edge-Proxy-Image auf einem Server, das noch flächendeckend ausgerollt wird. Bis ein bestimmter Server es hat, ist die Regel gespeichert, aber nicht angewendet, und sowohl die Settings-Karte als auch das Deploy-Log sagen das deutlich — nichts gibt vor, aktiv zu sein, wenn es das nicht ist:

• Web Application Firewall — jeder Request wird gegen das OWASP Core Rule Set geprüft (SQL-Injection, XSS, die anderen Standard-CRS-Kategorien), bevor er die App erreicht. Drei Modi: aus, detect (geloggt, blockiert nie — der richtige erste Schritt, um zu sehen, was es verhindert hätte, bevor man Enforcement einschaltet), und block (durchgesetzt, gibt 403 zurück).
• Rate Limiting — Requests pro Minute pro Client-IP, einstellbar für die ganze App und pro Pfad (/login 10, /api/* 120). Über dem Limit gibt es 429 mit Retry-After. Eine echte Einschränkung, die man kennen sollte: Zähler leben im Speicher jedes einzelnen Servers, sodass eine über mehrere Server verteilte App das Limit pro Server bekommt, nicht als globale Summe — und hinter Cloudflare oder einem anderen Proxy sieht jeder Besucher aktuell wie die IP dieses Proxys aus.
• Länderblocking — Zweibuchstaben-Länder-Allow-/Block-Listen, UNK für Adressen ohne bekanntes Land, geprüft vor Rate Limits, Redirects oder der App selbst. Private und interne Adressen kommen immer durch, unabhängig davon.

Warum die Ehrlichkeit hier speziell wichtig ist

Eine WAF, die still nicht durchsetzt, ist schlimmer als keine WAF, weil sie falsches Vertrauen erzeugt — genau das eine, was sich diese Produktkategorie nicht leisten kann, falsch zu machen. Im Produkt selbst klar “gespeichert, aber noch nicht angewendet” zu sagen, nicht nur in einem Changelog, ist die tatsächliche Absicherung dagegen, und es ist es wert, das auch hier zu sagen, statt zu implizieren, alles oben sei gleichermaßen live.

Vollständige Referenz: Edge-Regeln.