Ein schon seit vielen Jahren im Einsatz befindliches Bash-Skript habe ich unlängst aufgehübscht und “zum Codeberg” getragen.1 Der HTTP Limiter ist meine Antwort auf die vielen Bots, Scraper und Pentest-Tools, die unablässig gegen die offenen Ports eines Hosts im Internet “klopfen”.
Wobei “klopfen” eindeutig Untertreibung ist. Was einst als “Grundrauschen” daher kam, ist immer mehr zum Normalzustand geworden. Mit spürbaren Folgen: Logfiles wachsen schneller und lassen einen blind werden. Die Bearbeitung von sinnlosen Requests verbraucht mehr CPU, RAM und Traffic. Besonders anfällig gegen DDOS2 sind REST-APIs von Unternehmen mit ihren langsamen Datenbankanbindungen, meist in trägen Frameworks und Programmiersprachen programmiert.
Der HTTP Limiter ist natürlich nur eine “poor man’s defense” von einzelnen und kleinen Systemen. Deutlich wirksamer sind Loadbalancing-Cluster und sogenannte Proof-of-Work-Systeme wie beispielsweise Anubis.3 Doch manchmal muss es einfach und schnell sein, und da reicht der HTTP Limiter vollkommen aus. Es packt in der ufw before.rules seine iptables-Chains und wertet Requests aus noch bevor sich irgendwelche höheren Services sich damit beschäftigen müssen. Dabei gelten folgende Regeln:
- Erlaube maximal 100 neue Verbindungen binnen 10 Sekunden von einer einzelnen IP.
- Erlaube maximal 250 Verbindungen aus einem IPv4 /24 Subnet.
- Erlaube maximal 250 Verbindungen aus einem IPv6 /64 Subnet.
Das sind über Jahre ermittelte Richtwerte, die sich für die typischen Websites und selbst betriebenen Services im Mittelstand bewährt haben. Your mileage may vary und die Regeln können beliebig angepasst werden.
Wer mag, kann ja alles auf den moderneren nftables-Stack bringen und es auch für andere Distributionen anpassen, die möglicherweise vom “Debian-Way” abweichen.
In diesem Sinne,
Tomas Jakobs