Ungewöhnliche Treffer von Amazon Application Load Balancer

Ich habe mehrere Amazon-Anwendung und elastische Lastenausgleicher mit mehreren Servern hinter ihnen. Problem ist Load-Balancer-Anfragen an Server mit URLs wieUngewöhnliche Treffer von Amazon Application Load Balancer

app-0 (out): info: GET /administrator/pma/ 200 1261.343 ms - 19185 
    app-0 (out): 
    app-0 (out): info: GET /administrator/PMA/ 200 1287.396 ms - 19185 
    app-0 (out): 
    app-0 (out): info: GET /administrator/admin/ 200 1180.192 ms - 19185 
    app-0 (out): 
    app-0 (out): info: GET /phpMyAdmin2/ 200 1184.603 ms - 19185 
    app-0 (out): 
    app-0 (out): info: GET /phpMyAdmin3/ 200 1262.463 ms - 19185 
    app-0 (out): 
    app-0 (out): info: GET /phpMyAdmin4/ 200 1297.300 ms - 19185 
    app-0 (out): 
    app-0 (out): info: GET /phpMyAdmin-3/ 200 1188.261 ms - 19185 
    app-0 (out): 
    app-0 (out): info: GET /php-my-admin/ 200 1183.684 ms - 19185 
    app-0 (out): 
    app-0 (out): info: GET /PMA2011/ 200 1258.948 ms - 19185 
    app-0 (out): 
    app-0 (out): info: HEAD /PMA2013/ 200 1290.279 ms - 19185 
    app-0 (out): 
    app-0 (out): info: HEAD /PMA2014/ - - ms - - 
    app-0 (out): 
    app-0 (out): info: GET /PMA2015/ 200 1182.416 ms - 19185 
    app-0 (out): 
    app-0 (out): info: GET /PMA2016/ 200 1261.733 ms - 19185 
    app-0 (out): 
    app-0 (out): info: GET /PMA2017/ 200 1289.620 ms - 19185 
    app-0 (out): 
    app-0 (out): info: GET /PMA2018/ 200 1185.837 ms - 19185 
    app-0 (out): 
    app-0 (out): info: GET /pma2011/ 200 1178.948 ms - 19185 
    app-0 (out): 
    app-0 (out): info: GET /pma2012/ 200 1229.194 ms - 19185 
    app-0 (out): 
    app-0 (out): info: GET /pma2013/ 200 1320.295 ms - 19185 
    app-0 (out): 
    app-0 (out): info: GET /pma2014/ 200 1185.979 ms - 19185 
    app-0 (out): 
    app-0 (out): info: GET /pma2015/ 200 1180.451 ms - 19185 
    app-0 (out): 
    app-0 (out): info: GET /pma2016/ 200 1181.597 ms - 19185 
    app-0 (out): 
    app-0 (out): info: GET /pma2017/ 200 1271.013 ms - 19185 
    app-0 (out): 
    app-0 (out): info: GET /pma2018/ 200 1185.556 ms - 19185 
    app-0 (out): 
    app-0 (out): info: GET /phpmyadmin2011/ 200 1224.569 ms - 19185 
    app-0 (out): 
    app-0 (out): info: GET /phpmyadmin2012/ 200 1177.819 ms - 19185 
    app-0 (out): 
    app-0 (out): info: GET /phpmyadmin2013/ 200 1261.961 ms - 19185 
    app-0 (out): 
    app-0 (out): info: GET /phpmyadmin2014/ 200 1184.600 ms - 19185 
    app-0 (out): 
    app-0 (out): info: GET /phpmyadmin2015/ 200 1186.763 ms - 19185 
    app-0 (out): 
    app-0 (out): info: GET /phpmyadmin2016/ 200 1177.270 ms - 19185 
    app-0 (out): 
    app-0 (out): info: GET /phpmyadmin2017/ 200 1253.435 ms - 19185 
    app-0 (out): 
    app-0 (out): info: GET /phpmyadmin2018/ 200 1300.840 ms - 19185 
    app-0 (out): 
    app-0 (out): info: GET /phpmanager/ 200 1184.614 ms - 19185

Es gibt viele weitere URLs wie diese. Ich habe keine SQL oder so etwas auf meinem Server installiert. Das erstickt meinen Server einige Male. Port 80 ist nicht direkt auf dem Server geöffnet. Nur Loadbalancer darf über den Port 80 auf den Server zugreifen.

Quelle

2017-09-20 Asif Saeed

https://unix.stackexchange.com/questions/374756/how-to-handle-aggressive-http-requests-from-the-same-ip – titogeo

Aber warum ist Ihr Server zurück 200. bist du sicher, dass kein anderer Prozess auf Ihrem Server läuft. Ich habe gesehen, dass in der Vergangenheit jemand in unseren Server gehackt und den minecraft-Server gestartet hat und wir begannen, zu viele HTTP-Anfragen zu sehen – titogeo

Sie können dies nicht im ELB selbst beheben. Der Grund dafür ist, dass Ihre Anwendung die Anfrage tatsächlich verarbeitet und eine ganze Weile dauert, um dies zu tun (über 1 Sekunde), was wahrscheinlich viel CPU-Leistung und möglicherweise sogar Speicher verbraucht (alles hängt natürlich von der Anwendung ab)).

Sie können das Problem möglicherweise mindern, indem Sie eine Art Filter- oder Caching-Layer vor Ihrem ELB platzieren (Dienste wie CloudFlare können dies möglicherweise handhaben), um die Belastung Ihrer Server zu verringern. Sie können Ihrem Webserver auch eine gewisse Logik hinzufügen, um sicherzustellen, dass diese Anrufe nicht an Ihre Anwendung weitergeleitet werden. Schließlich können Sie auch sicherstellen, dass diese Aufrufe Ihr Setup nicht überlasten, indem Sie entweder sicherstellen, dass diese Anforderung eine 404-Nachricht auslöst (wahrscheinlich sollte dies der Fall sein) und 404 Nachrichten prompt und leicht oder durch (automatisches) Skalieren Ihres Setups (z eine tatsächliche kurzfristige Lösung sein, bis Sie es auf andere Weise beheben können, wenn die Vermeidung von Ausfallzeiten das Hauptanliegen ist.

Quelle

2017-09-20 14:40:40

Diese Angriffssignatur sieht wie Jorgee aus. Es ist eine Art von Schwachstellen-Scanner. Hier sind meine Protokolle aus einem Jorgee auf meinem Server scannen:

Sep 20 09:36:50 "HEAD http://x.x.x.x:80/administrator/PMA/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee" 
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/administrator/admin/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee" 
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/phpMyAdmin2/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee" 
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/phpMyAdmin3/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee" 
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/phpMyAdmin4/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee" 
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/phpMyAdmin-3/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee" 
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/php-my-admin/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee" 
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/PMA2011/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee" 
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/PMA2012/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee" 
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/PMA2013/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee" 
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/PMA2014/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee" 
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/PMA2015/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee" 
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/PMA2016/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee" 
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/PMA2017/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee" 
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/PMA2018/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee" 
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/pma2011/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee" 
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/pma2012/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee" 
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/pma2013/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee" 
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/pma2014/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee" 
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/pma2015/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee" 
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/pma2016/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee" 
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/pma2017/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee" 
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/pma2018/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee" 
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/phpmyadmin2011/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee" 
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/phpmyadmin2012/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee" 
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/phpmyadmin2013/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee" 
Sep 20 09:37:00 "HEAD http://x.x.x.x:80/phpmyadmin2014/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee" 
Sep 20 09:37:00 "HEAD http://x.x.x.x:80/phpmyadmin2016/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee" 
Sep 20 09:37:00 "HEAD http://x.x.x.x:80/phpmyadmin2017/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee" 
Sep 20 09:37:00 "HEAD http://x.x.x.x:80/phpmyadmin2018/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee" 
Sep 20 09:37:00 "HEAD http://x.x.x.x:80/phpmanager/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee"

Dieser Artikel einige Vorschläge, aber sie alle arbeiten auf der Serverebene und nicht auf der ELB-Ebene.

Sie können den Zugriff nicht mithilfe von Sicherheitsgruppen blockieren, da sie keinen Mechanismus zum Verweigern haben, sondern nur zulassen.

Sie könnten versuchen, IPs automatisch zu blockieren, indem Sie Netzwerk-ACLs mit einem benutzerdefinierten fail2ban-Filter verwenden.

Quelle

2017-09-20 15:03:41

Es gibt eine Lösung auf AWS Elastic Load Balancer-Ebene, die ich in meinen Anwendungen hatte. In der AWS Elastic Beanstalk-Umgebung wurde ein Problem mit der Meldung von Integritätsmeldungen mit Nachrichten wie requests to the ELB are failing with 5xx gemeldet. Wir haben das Problem untersucht und das war wegen Jorgee bot und einigen anderen Standard-Scanner.

Was ich getan habe, war im Grunde erstellen Web-ACL mit Regel string condition zu Host Header mit einer definierten Domäne für meine Anwendung entsprechen. Also, wenn Bot versucht, ELB mit seiner IP-Adresse anzufordern (was sie normalerweise tun), wird es 403. Keine Gesundheitswarnung mehr auf EB-Umgebungslevel und wir können diese Anfragen immer noch leicht mit Cloudwatch verfolgen, damit wir wissen, was mit Bots los ist .

Es gibt einige Hinweise, die ich auf https://www.mkubaczyk.com/2017/10/10/use-aws-waf-block-bots-jorgee-500-status-elastic-beanstalk mit Schritt für Schritt Anweisungen gemacht habe, um eine solche Regel zu erstellen. Ich hoffe es hilft! Es erfordert nur AWS Application Load Balancer, aber das ist kein großes Problem, wie Sie leicht neue Umgebung mit eb-cli mit --elb-type application Flag erstellen können. :-)

Quelle

2017-10-10 16:24:54 mkubaczyk

Ungewöhnliche Treffer von Amazon Application Load Balancer

Antwort

Verwandte Themen