Ich habe eine Django-Web-App, in der die Leute Kommentare schreiben und die Kommentare anderer positiv bewerten / bewerten. Der Webserver ist gunicorn + nginx (Reverse Proxy). Die Datenbank ist postgresql. Die DB- und Web-App befinden sich auf zwei verschiedenen Ubuntu-basierten Maschinen.
Einige böswillige Benutzer haben angefangen, die Abstimmungsfunktion zu missbrauchen, und haben sich innerhalb weniger Minuten Tausende von Stimmen gegeben (oder andere abstimmen lassen). Meine Server erhalten effektiv DDOS, wenn ein solches Skript ausgeführt wird. Einige dieser Personen sind auch andere Benutzer, indem sie ihre Cookies stehlen!
Ich möchte dieses Verhalten frühzeitig auf Nginx-Ebene erkennen. Ich dachte, ich würde fail2baneine Richtlinie installieren und schreiben. Eine Richtlinie kann dann sein, wenn innerhalb von 15 Sekunden mehr als 10 Stimmen von einer IP stammen, diese IP für 30 Minuten ins Gefängnis schicken (dh auf eine Jail-URL umleiten).
Jetzt in meinem access.log, eine Stimme ( nach oben oder unten) erstellt die folgende: 31.13.113.83 - - [14/Feb/2016:06:51:10 +0000] "POST /vote/ HTTP/1.1" 302 5 "http://example.com/?sorg_service_id_internal=373234912870626%3BAfq3$.
Da ich neu dabei bin, brauche ich Hilfe bei der Umsetzung meiner Richtlinien. Wird failregex = ^ \vote\in den .confDateien [Definition]und in Folgendem enthalten sein jail.local:
Hinweis: Für mich ist auch interessant, wie dies die Leistung der Web-App beeinflussen kann. Ist die Implementierung fail2banIhrer Erfahrung relativ gering oder fallen erhebliche Kosten an? Angenommen, dies ist die einzige Richtlinie, die ich implementiere. Die Diskussion hier scheint zu suggerieren, dass es mit dem RAM teuer werden könnte?
Da dies eine Konfigurationsfrage ist, migriere ich zu SuperUser
schroeder vor 8 Jahren
1
Klingt, als hätten Sie ernstere Probleme als nur DoS, wenn böswillige Benutzer dies alles können.
multithr3at3d vor 8 Jahren
0
@Korockinout13 Wir untersuchen das XSS-Problem gesondert (Sie können gerne etwas aus Ihrem Kopf vorschlagen), aber was den Wahlbetrug angeht, denke ich, dass "fail2ban" das auf der Webserver-Ebene einfangen kann und das Verhalten zu bestrafen lässt tun. "Fail2ban" ist daher ein kritischer Teil der Strategie. Wenn Sie meine Frage gesehen haben, können Sie eine Antwort vorschlagen.
Hassan Baig vor 8 Jahren
0
Dies hilft Ihnen, die Anforderungen und / oder Verbindungen zu begrenzen, wodurch das Hämmern Ihres Backends verhindert wird. Dann würde ich einen Check hinzufügen, wenn der Benutzer bereits für einen bestimmten Beitrag gestimmt hat, und eine zweite Abstimmung verweigern, falls dies der Fall ist. Sie können dann immer noch das Protokoll überprüfen 503 (Service Temporarily Unavailable)und mit fail2ban diejenigen heraushalten, die (zu häufig) Nginx-Limits auslösen.
Ich habe nichts über `503 (Service vorübergehend nicht verfügbar)` verstanden. Können Sie das an einem Beispiel verdeutlichen?
Hassan Baig vor 7 Jahren
0
Mit einem dieser Module legen Sie ein Limit fest. Das Limit wird ausgelöst. Der Anforderer erhält eine 503. Diese wird auch in der access.log protokolliert. Sie können dies für das fail2ban verwenden, um die IP der Anforderer zu blockieren, wenn nginx das Hämmern erkennt. Auf diese Weise wird Ihr Backend durch nginx und nginx durch fail2ban geschützt, das iptables (Firewall, Paket-Drop) verwendet.
unNamed vor 7 Jahren
0