Uzyskiwanie 408 błędów w naszych logach bez żądania lub agenta użytkownika

36

Otrzymuję wiele żądań pojawiających się w naszych logach Apache, które wyglądają tak

www.example.com:80 10.240.1.8 - - [06/Mar/2013:00:39:19 +0000] "-" 408 0 "-" "-" -

Wygląda na to, że nie ma żądań ani klienta użytkownika. Czy ktoś już to widział?

Glenn Slaven
źródło

Odpowiedzi:

29

Czy przypadkiem uruchamiasz swoje serwery internetowe w Amazon za Elastic Load Balancer?

Wygląda na to, że generują dużo 408 odpowiedzi z powodu kontroli stanu zdrowia .

Niektóre rozwiązania z tego wątku na forum:

  • RequestReadTimeout header=0 body=0

    To wyłącza 408 odpowiedzi, jeśli upłynie limit czasu żądania.

  • Zmień kontrolę poprawności ELB na inny port.
  • Wyłącz rejestrowanie adresów IP ELB za pomocą:

    SetEnvIf Remote_Addr "10\.0\.0\.5" exclude_from_log
    CustomLog logs/access_log common env=!exclude_from_log
    

I z tego postu na blogu :

  • Ustaw limit czasu żądania na 60 lub więcej.
Ladadadada
źródło
2
w moim rozumieniu narazi cię to na atak slowlori, posiadanie przyzwoitego czasu oczekiwania wydaje się przydatne w dzisiejszych czasach dla każdego używającego apache
neofutur
Jeśli jesteś za ELB, slowloris nie stanowi problemu.
Ladadadada,
2
RequestReadTimeout header=0 body=0wyłączyłby razem limit czasu odczytu żądania, nie poleciłbym tego
mikejonesey,
@Ladadadada Myślę, że nadal potrzebujesz powolnej ochrony Loris, ponieważ HTTP działa jak proxy Tcp, https jeśli odciążony będzie przekazywał żądania HTTP zamiast Tcp, jednak nie ma filtrów dla wolnych połączeń, jest tylko limit czasu na odpowiedź.
mikejonesey,
@Ladadadada się mylisz, ELB lub ALB niewiele robią, aby pomóc w zwalczaniu slowlori i wpłynie to na większość serwerów internetowych, zobacz moje pytanie AWS i problem tutaj: forums.aws.amazon.com/thread.jspa?threadID=269176
Cristiano Coelho
9

Coś łączy się z portem i nigdy nie wysyła danych. HTTP 408 jest błędem przekroczenia limitu czasu. Tutaj jest dobry opis: http://www.checkupdown.com/status/E408.html

Insyte
źródło
1
Chociaż ten link może odpowiedzieć na pytanie, lepiej jest dołączyć tutaj istotne części odpowiedzi i podać link w celach informacyjnych. Odpowiedzi zawierające tylko łącze mogą stać się nieprawidłowe, jeśli połączona strona ulegnie zmianie.
kasperd
Po właśnie przejrzeniu listy ponad 100 adresów IP, które otrzymały 408 swoich pustych wniosków, można zauważyć, że większość pochodzi z Chin kontynentalnych i podejrzewam, że problem dotyczy przede wszystkim zatorów komunikacyjnych. Przeciążenie powodujące powodzenie konfiguracji połączenia, ale nagłówek żądania nie jest wysyłany. Przepustowość transgraniczna z Chin jest bardzo przeciążona, a połączenia poza kontynentem również przybywające puste były rozproszone z Brazylii, Europy i wiejskich Stanów Zjednoczonych, które prawdopodobnie mają podobne problemy z dotarciem do serwera na zachodnim wybrzeżu USA.
ClearCrescendo,
8

Jest tu już kilka dobrych odpowiedzi, ale chciałbym zaryzykować jedną dodatkową notatkę, która nie została specjalnie poruszona. Jak wielu wcześniej wspomnianych komentujących, 408 wskazuje na przekroczenie limitu czasu; i istnieje szereg sytuacji, w których przekroczenia limitu czasu występują na serwerze WWW.

To powiedziawszy, 408 błędów może być generowanych w różnych przypadkach, gdy twój serwer jest skanowany w poszukiwaniu exploitów. Klienci w takich przypadkach rzadko prezentują agenta użytkownika i często nagle kończą połączenia, co powoduje nieudane zamknięcie tego połączenia, które może generować błąd 408.

Powiedzmy na przykład, że jestem złośliwym hakerem, który skanuje Internet w poszukiwaniu komputerów, które są nadal podatne na lukę POODLE. W związku z tym napisałem skrypt, który otwiera połączenia z dużymi fragmentami adresów IP, aby znaleźć serwery, które zaakceptują SSL w wersji 3 - później użyję tej listy do skanowania w szczególności pod kątem wykorzystania POODLE. Wszystko, co robi ten pierwszy skrypt, to nawiązywanie połączenia za pomocą openssl w celu sprawdzenia SSLv3, w następujący sposób:

openssl s_client -connect [IP]:443 -ssl3

To polecenie, w wielu konfiguracjach Apache, spowoduje wyświetlenie komunikatu 408 dokładnie tak, jak opisano. Wykonanie tej komendy na dwóch moich własnych serwerach spowodowało wpis do dziennika dostępu:

<remote IP address>  - - [04/Nov/2015:08:09:33 -0500] "-" 408 - "-" "-"

Chciałem to wyjaśnić, ponieważ nawet w sytuacji, gdy OP nie korzystał z żadnej formy równoważenia obciążenia, błędy 408 mogą wystąpić w różnych okolicznościach - niektóre złośliwe, niektóre wskazują na problemy z klientem, a niektóre na problemy z serwerem. (Zauważyłem w dzienniku dostarczonym przez OP, że lokalny adres IP został wskazany jako zdalny adres IP, ale OP nie wspomniał konkretnie o użyciu modułu równoważenia obciążenia, więc nie byłem pewien, czy OP po prostu użył adresu IP bez możliwości routingu demonstracji, podobnie jak w przypadku adresu URL)

W każdym razie, mimo że mój post, choć oczywiście jest zbyt późno, aby pomóc OP, mam nadzieję, że może pomóc innym, którzy tu przybędą, szukając rozwiązania wszystkich tych cholernych błędów przekroczenia limitu czasu.

Josh Wieder
źródło
6

Istnieje wiele przyczyn przekroczenia limitu czasu 408. Ale zacznijmy od założenia, że ​​wszystko jest w porządku, wtedy w pewnym momencie te 408 zaczną pojawiać się w twoim dzienniku dostępu - tj. 408 0 „-” „-”.

Jak wielu wskazuje w sieci, 408 oznacza, że ​​połączenie zostało nawiązane, ale żadne żądanie nie jest wysyłane w odpowiednim przedziale czasowym, dlatego serwer przerywa połączenie z 408. Jedna arogancka osoba faktycznie odpowiedziała na kogoś, kto prosi o pomoc w tej kwestii z - „Której części Limit czasu nie rozumiesz”.

Myślę, że jest to odpowiedź bardzo nowicjuszowa i pokazuje całkowity brak zrozumienia, w jaki sposób niektóre metody bezpieczeństwa działają w oprogramowaniu serwera WWW.

Wracając do początku, dlaczego widzę te wszystkie 408. Jedną z rzeczy, które będziesz miał wspólnego z resztą z nas zarządzających serwerem, jest ogromna liczba ataków, które otrzymujesz codziennie. Co teraz z nimi robisz? Cóż: używasz wybranych metod bezpieczeństwa, aby sobie z nimi poradzić, oto co się zmienia.

Weźmy bardzo prosty przykład: upuść adres IP. Zawarty w pliku iptabes (rules.v4) masz „-A ufw-user-input -s 37.58.64.228 -j DROP”. Tak więc pojawia się 37.58.64.228 zapora rozpoznaje adres IP i przerywa połączenie. W wielu konfiguracjach nawet nie wiadomo, czy puka do drzwi.

Weźmy teraz bardziej zaawansowany przykład: porzuć połączenie na podstawie niektórych kryteriów. Zawarty w pliku iptabes (rules.v4) masz „-A WEJŚCIE -p tcp -m tcp --port 80 -m ciąg - ciąg„ cgi ”- algo bm --to 1000 -j DROP”. Jest inaczej, ponieważ w tej iptable regule mówimy, spójrz na pierwsze 1000 bajtów ciągu żądania i sprawdź, czy możesz znaleźć podciąg „cgi”, a jeśli znajdziesz ten podciąg, to nie przechodź ponadto po prostu porzuć połączenie.

Tutaj metoda bezpieczeństwa jest dobra, ale jeśli chodzi o twoje logi, wprowadza w błąd. Wygenerowany 408 0 „-” „-” to najlepszy apache, jaki można zrobić w tych okolicznościach. Połączenie zostało nawiązane, a żądanie musiało zostać zaakceptowane do pewnego momentu, aby zastosować regułę porównywania ciągów, która ostatecznie daje wynik 408, ponieważ reguła spełniała kryteria zerwania połączenia. Zatem nasze małe nowicjusze nie mogłyby się bardziej mylić, gdyby próbowały. Połączenie zostało nawiązane i otrzymano żądanie (w takich okolicznościach po prostu nie będzie można go zobaczyć). Mimo że generowany jest kod 408, nie jest to „limit czasu”; Twój serwer po prostu porzucił połączenie po zgłoszeniu żądania w związku z regułą zapory. Istnieje wiele innych reguł, które tworzyłyby tę samą sytuację 408. Don'

Idealnie byłoby, gdyby pojawił się inny kod błędu generowany przez Apache, na przykład - „499”, co oznaczałoby „Serwer odczytał twoje żądanie i zdecydował, że nie można go niepokoić - Sod Off HaHa”.

Dzięki najnowszemu oprogramowaniu do serwerów internetowych można praktycznie wykluczyć ataki DOS, a nowy gen przeglądarek z funkcjami predykcyjnymi nie powoduje tego problemu, jak sugerują niektórzy.

Krótko mówiąc, 408 jest generowany, ponieważ serwer nie odpowiedział na żądanie, w przypadku klienta przekroczono limit czasu połączenia, gdy w rzeczywistości serwer odczytał żądanie, ale zrzucił połączenie z powodów innych niż przekroczenie limitu czasu oczekiwania na prośba.

Kev
źródło
2
Ale DLACZEGO to porzuciło połączenie? Widzimy, że to dzienniki serwera, a nie dzienniki klienta.
Erick Robertson,
5

Mieliśmy ten problem i przez dłuższą chwilę zastanawialiśmy się. Najlepsze rozwiązanie, jakie wymyśliliśmy, zostało zaproponowane przez zespół ELB wsparcia AWS. Zasadniczo zależy to od tego, czy wszystkie ustawienia limitu czasu serwera httpd są większe niż idle timeoutustawienia ELB (domyślnie 60 sekund).

  • Upewnij się, że Timeoutwartość dyrektywy apache jest dwukrotnie większa niż idle timeoutustawienie ELB.
  • Włącz tę KeepAlivefunkcję, upewnij się, że MaxKeepAliveRequestsjest ona bardzo duża (0 dla nieskończoności lub bardzo wysoka, jak 2000) i że KeepAliveTimeoutjest większa niż twoich ELB idle timeout.

Okazało się, że ustawienie KeepAlive(i powiązane ustawienia) specjalnie zmniejszyło liczbę 408s do efektywnie 0 (widzimy kilka, ale bardzo niewiele).

dsummersl
źródło
Niestety używam Elastic Beanstalk. Nie mam dostępnych tych opcji.
Erick Robertson,
3

Miałem ten problem za AWS Elastic Load Balancer. Kontrole stanu wygenerowały okropną liczbę 408 odpowiedzi w dzienniku.

Jedynym rozwiązaniem, które działało dla mnie, było ustawienie limitu czasu bezczynności modułu równoważącego obciążenie niższego niż limit czasu odpowiedzi testu sprawności .

Přemysl Růžička
źródło
0

Kolega niedawno zauważył, że chociaż mój ostatni post podał prawidłowe wyjaśnienie, w jaki sposób 408 może mieć związek ze środkiem bezpieczeństwa, nie zaproponował żadnego rozwiązania.

Dziennik Piped Access to moje osobiste rozwiązanie.

Poniższe elementy powinny działać od razu po instalacji w większości konfiguracji Ubuntu i przy minimalnym majsterkowaniu w innych konfiguracjach Apache. Wybrałem PHP, ponieważ jest najłatwiejszy do zrozumienia. Istnieją dwa skrypty: pierwszy zapobiega zapisywaniu 408 w twoim dzienniku dostępu. Drugi skrypt wysyła wszystkie 408 do osobnego pliku dziennika. Tak czy inaczej, wynik nie będzie już 408s w twoim dzienniku dostępu. To twój wybór, który skrypt wdrożyć.

Użyj swojego ulubionego edytora tekstu, używam nano. Otwórz plik, w którym masz dyrektywy „LogFormat” i „CustomLog”. Skomentuj oryginały zwykłym numerem i dodaj następujące. Możesz znaleźć te dyrektywy w pliku poniżej.

sudo nano / etc / apache2 / sites-available / default

LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" AccessLogPipe

CustomLog "|/var/log/apache2/PipedAccessLog.php" AccessLogPipe env=!dontlog

UWAGA: Nie loguję obrazów w moim dzienniku dostępu. W moim pliku etc / apache2 / httpd.conf dołączam wiersz

SetEnvIfNoCase Request_URI ".(gif)|(jpg)|(png)|(css)|(js)|(ico)$" dontlog

Jeśli to Cię nie interesuje, usuń env=!dontlogz CustomLogdyrektywy.

Teraz stwórz jeden z następujących skryptów PHP ( #!/usr/bin/phpjest to odniesienie do lokalizacji interpretera, upewnij się, że lokalizacja jest poprawna dla twojego systemu - możesz to zrobić, pisząc po znaku zachęty $; whereis php- powinno to zwrócić coś takiego php: /usr/bin/php /usr/bin/X11/php /usr/share/man/man1/php.1.gz. widać, że #!/usr/bin/phpjest odpowiedni dla mojej konfiguracji).

sudo nano /var/log/apache2/PipedAccessLog.php

#!/usr/bin/php
<?php
  $file = '/var/log/apache2/access.log';
  $no408 = '"-" 408 0 "-" "-"';
  $stdin = fopen ('php://stdin', 'r');
  ob_implicit_flush (true);
  while ($line = fgets ($stdin)) {
    if($line != "") {
      if(stristr($line,$no408,true) == "") {
        file_put_contents($file, $line, FILE_APPEND | LOCK_EX);
      }
    }
  }
?>

sudo nano /var/log/apache2/PipedAccessLog.php

#!/usr/bin/php
<?php
  $file = '/var/log/apache2/access.log';
  $file408 = '/var/log/apache2/408.log';
  $no408 = '"-" 408 0 "-" "-"';
  $stdin = fopen ('php://stdin', 'r');
  ob_implicit_flush (true);
  while ($line = fgets ($stdin)) {
    if($line != "") {
      if(stristr($line,$no408,true) != "") {
        file_put_contents($file408, $line, FILE_APPEND | LOCK_EX);
      }
      else {
        file_put_contents($file, $line, FILE_APPEND | LOCK_EX);
      }
    }
  }
?>

Po zapisaniu PipedAccessLog.phpskryptu; upewnij się, że root ma własność, wykonując następujące czynności po znaku zachęty $.

sudo chown -R root:adm /var/log/apache2/PipedAccessLog.php

PipedAccessLog.phpSkrypt musi odczytu / zapisu i wykonania tak wykonać następujące polecenie w wierszu $.

sudo chmod 755 /var/log/apache2/PipedAccessLog.php

Wreszcie, aby wszystko działało, musisz ponownie uruchomić usługę Apache. Wykonaj następujące czynności po znaku zachęty $.

sudo service apache2 restart

Jeśli twoje dzienniki Apache znajdują się gdzie indziej, zmień ścieżki w celu dopasowania do konfiguracji. Powodzenia.

Kev
źródło
6
Jeśli dzieje się 408, musimy dowiedzieć się, dlaczego i się ich pozbyć. Samo zapobieganie ich logowaniu lub przesyłaniu ich do innego pliku to strata czasu na serwerze. Służy również tylko do ukrycia problemu. To jak sprzątanie pokoju, wsuwając wszystko pod łóżko.
Erick Robertson
-2

Odkryłem, że liczba błędów 408 rośnie zarówno pod względem liczby, jak i częstotliwości. Rośnie również zakres adresów IP, z których pochodzą. Są one rejestrowane w osobnym pliku. Istnieją również oczywiste wzorce logów wyświetlające kolejne 408 z tych samych grup adresów IP, które nie wynikają z normalnych limitów czasu serwera, ponieważ inicjator próbuje nawiązać połączenia w odstępie około 2 lub 3 sekund w cyklicznym wzorcu (nie ma oczekiwania na przekroczenie limitu czasu przed kolejnym próba połączenia) Widzę to jako proste próby połączenia w stylu DDOS. Moim zdaniem są to rodzaj wiadomości potwierdzającej dla twórcy, że serwer jest online ... potem wrócą później z różnymi narzędziami ... Jeśli zwiększysz swój limit czasu, po prostu dajesz im większą alokację czasu do uruchomienia ich programy hakerskie w ramach.

użytkownik 282558
źródło