Wie eine Anwendung vor automatischen Scans geschützt wird

Ein automatischer Scan ist ein Programm, das massenhaft Adressen besucht und allen dieselbe Frage stellt: Liegt hier eine vergessene Datei, eine alte Verwaltungsseite, eine bekannte Schwachstelle? Es weiß nicht, wer Sie sind. Es weiß nur, dass die Adresse existiert. Der Test kostet den Absender fast nichts. Deshalb bekommt ihn jede öffentliche Website.

OWASP, die offene Sicherheits-Community, beschreibt ihn als unerwünschte automatische Nutzung, die „Tag für Tag“ weitergeht. Sie weist auch darauf hin, dass dabei oft ganz normale Funktionen einer Anwendung ausgenutzt werden, nicht ein defektes Bauteil. Das passt zu dem, was die Logs eines Servers zeigen. Eine neue Anwendung kann kurz nach dem Start getestet werden, lange bevor ihr Publikum sie kennt.

Die nützliche Frage lautet also: „Was passiert, wenn man uns scannt?“ Bei einer einfachen Firmenwebsite lautet die Antwort oft: „nichts Wichtiges“. Bei einer Plattform mit Kundendaten lohnt sich ein Schutz, der von Anfang an geplant ist.

Scanner suchen nach Fehlern, die häufig genug sind, dass sich der Versuch lohnt. Ihre Anfragen sind einfach und wiederholen sich, deshalb sind sie leicht zu erkennen. Die Tabelle zeigt typische Ziele und was der Scanner sich jeweils erhofft. Es ist eine Liste, die jeder Scanner abarbeitet, egal, worum es auf der Website geht.

In einer sauber gebauten Anwendung gibt es diese Dateien nicht, also hat keine dieser Anfragen Erfolg. Das Problem ist die Menge. Tausende solcher Anfragen füllen die Logs, verbrauchen Ressourcen und verdecken die eine Anfrage, auf die es ankommt. Werden sie früh gestoppt, bleibt das Bild klar.

Ein Filter vor der Anwendung prüft jede Anfrage und stoppt die schädlichen, bevor sie die Anwendung erreichen. Bei AWS ist das AWS WAF, eine Web Application Firewall. Einfach gesagt ist es ein Filter, der schädlichen Datenverkehr nach Regeln stoppt, die Sie selbst festlegen.

AWS beschreibt es als Dienst, der die HTTP- und HTTPS-Anfragen an die geschützten Ressourcen überwacht. Er steuert den Zugriff nach Kriterien wie der IP-Adresse, von der eine Anfrage kommt, oder den Werten in der URL. Passt eine Anfrage auf eine Sperrregel, erhält sie die HTTP-Antwort 403, also „verboten“, oder eine eigene Antwort.

Die Regeln können wir selbst schreiben. Es gibt außerdem fertige Regelgruppen, die AWS pflegt. In der Infrastruktur, die wir in der Fallstudie zu einer Gesundheitsplattform in den USA beschreiben, hatte der Filter 23 Regeln: Anfragelimits pro Besucher, geografische Beschränkungen, fertige Gruppen für gängige schädliche Eingaben und ausdrückliche Sperren für Anfragen, die `.env`, `.git`, phpMyAdmin oder PHP-Dateien verlangen.

Hartnäckige Scanner werden durch zwei Mechanismen gebremst, die zusammenarbeiten. Eine ratenbasierte Regel zählt die Anfragen und begrenzt die, die zu schnell kommen. Ein kleines automatisches Skript liest danach die Logs, erkennt die, die weiter scannen, und sperrt sie bei jeder Rückkehr länger. Der erste Mechanismus deckt die Schübe ab, der zweite die Hartnäckigkeit.

AWS beschreibt den ersten als Regel, die eingehende Anfragen zählt, sie nach Kriterien Ihrer Wahl gruppiert und eine Aktion auslöst, wenn ein Besucher innerhalb des Zeitfensters das Limit überschreitet. Ein Mensch, der eine Seite durchstöbert, kommt nie in die Nähe eines solchen Limits. Ein Scanner mit Hunderten Anfragen pro Minute erreicht es sofort.

Für den zweiten Mechanismus nutzen wir AWS Lambda. Es führt Code als Reaktion auf Ereignisse oder nach Zeitplan aus, ohne dass wir Server verwalten. In der erwähnten Fallstudie lief ein Python-Skript alle drei Minuten, erkannte Scanner in den Logs und sperrte sie mit wachsender Dauer. Die Steigerung ist wichtig: Der erste Verstoß bringt eine kurze Sperre, Hartnäckigkeit eine längere. Eine versehentliche Sperre läuft bald von selbst ab.

Die Reihenfolge für ein solches System ist kurz:

1. Wir legen fest, was legitim ist. Wir erfassen die echten Pfade, die Methoden und die Länder, aus denen Ihre Nutzer kommen.

2. Wir fügen die fertigen Regelgruppen hinzu. Sie decken weithin bekannte schädliche Eingaben ab, ohne dass wir jedes Muster einzeln schreiben.

3. Wir fügen ausdrückliche Sperren hinzu für die Dateien und Seiten, die Ihre Anwendung nie ausliefert.

4. Wir fügen ein Ratenlimit pro Besucher hinzu, mit Ausnahmen nur für die wenigen Stellen, die berechtigt viele Anfragen erhalten, etwa die Registrierung.

5. Wir lassen die Log-Prüfung nach Zeitplan laufen, damit wiederkehrende Besucher längere Sperren bekommen.

6. Wir prüfen die Logs am Anfang jede Woche, um legitime Nutzer zu finden, die versehentlich gesperrt wurden.

Man sieht es, indem man die Logs liest, die vorab so organisiert werden, dass sie leicht lesbar sind. Amazon CloudWatch Logs Insights erlaubt es, Logs mit Abfragen zu durchsuchen und auszuwerten. Wir bereiten gespeicherte Abfragen für die üblichen Fragen vor: Welche Anfragen lieferten 4xx- oder 5xx-Fehler, welche Besucher wurden umgeleitet, welche Adressen wirken verdächtig, was hat der Filter blockiert.

Die AWS-Dokumentation hält fest, dass Abfragen gespeichert, erneut ausgeführt und in Dashboards eingebunden werden können. So wird eine einmalige Untersuchung zur Routine. Ein Filter braucht regelmäßige Aufmerksamkeit, um aktuell zu bleiben. Eine gespeicherte Abfrage mit den „blockierten Anfragen dieser Woche“ liest sich in einer Minute. Sie zeigt, ob die Regeln noch zum echten Datenverkehr passen.

Logs beantworten auch Fragen im Nachhinein. Sagt ein Kunde „gestern konnte ich mich nicht anmelden“, sehen Sie, ob der Filter ihn blockiert hat und warum. Danach korrigieren Sie die Regel anhand der Fakten.

Die Anwendung muss auf dem Server prüfen, was sie erhält, egal, was der Filter durchgelassen hat. Der Filter kennt die Regeln Ihres Unternehmens nicht. Das Input Validation Cheat Sheet von OWASP empfiehlt, nur das zu akzeptieren, was für jedes Feld vorgesehen ist, statt jede schädliche Zeichenfolge aufzuzählen.

Derselbe Leitfaden erklärt, dass Prüfungen im Browser leicht umgangen werden. Sie dienen der sofortigen Rückmeldung an den Nutzer, der Server muss sie wiederholen. Deshalb ist der Filter nur eine Schicht des Schutzes. Die OWASP Top 10, die bekannteste Liste der kritischsten Risiken von Webanwendungen, beschreibt Risiken in der Art, wie Anwendungen gebaut werden. Die löst der richtige Entwurf der Anwendung, über jede Firewall hinaus.

Hierher gehören auch weitere gute Praktiken: aktuelle Software, für jeden Nutzer nur der Zugriff, den er braucht, und Geheimnisse, die außerhalb des Codes gespeichert sind. Sie sind Teil unserer Arbeitsweise. Die Infrastrukturseite, also den Filter, die Logs und die Zugriffsregeln, deckt die Leistung Infrastruktur auf AWS ab.

Weitere Schichten braucht es für alles, was den Massen-Scans entgeht. Der Filter behebt keine Fehler im Code und erkennt kein gestohlenes Passwort. Er beurteilt auch keine Anfrage, die völlig normal aussieht, aber mit böser Absicht gestellt wird. Gezielte Angriffe brauchen ihren eigenen Schutz.

Jede Schicht hat ihre eigene Aufgabe. AWS GuardDuty ist zum Beispiel ein Dienst zur Erkennung von Bedrohungen. Er beobachtet Aktivität und Logs in Ihrem AWS-Konto auf Anzeichen ungewöhnlichen Verhaltens. Datensicherungen, Zugriffskontrolle und ein Plan, wer handelt, wenn ein Alarm kommt, zählen so viel wie jede Regel.

Was Sie mit dieser Anordnung gewinnen, ist konkret: Der große Teil des automatischen Datenverkehrs wird mit geringen Kosten gestoppt, die Logs bleiben gut lesbar, die selteneren ernsten Versuche fallen leichter auf. Wenn Sie eine Plattform planen und ihren Schutz von Anfang an wollen, beschreiben Sie sie in einer Projektanfrage.