Отримання 408 помилок у наших журналах без запиту чи агента користувача


36

Я отримую багато запитів у наших журналах apache, які виглядають приблизно так

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

Здається, немає запиту та агента користувача. Хтось бачив це раніше?


Відповіді:


29

Ви випадково запускаєте свої веб-сервери в Amazon за еластичним балансиром навантаження?

Здається, вони отримують багато 408 відповідей завдяки їхнім медичним перевіркам .

Деякі рішення з теми форуму:

  • RequestReadTimeout header=0 body=0

    Це вимикає 408 відповідей, якщо запит вичерпується.

  • Змініть перевірку стану здоров'я ELB на інший порт.
  • Вимкнути журнал для IP-адрес ELB за допомогою:

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

І з цього блогу :

  • Відрегулюйте час очікування на запит до 60 або вище.

2
наскільки я розумію, це піддасть вас нападу уповільнення, мати пристойний reqtimeout здається корисним сьогодні для всіх, хто використовує apache
neofutur

Якщо ви стоїте за ELB, slowloris - це не проблема.
Ladadadada

2
RequestReadTimeout header=0 body=0відключив б час запиту на час читання, я б не рекомендував цього
mikejonesey

@Ladadadada Я думаю, що вам все ще потрібен повільний захист loris, оскільки http працює як проксі-сервер tcp, https, якщо вивантажений буде пересилати http-запити, а не tcp, однак немає фільтрів для повільних з'єднань, є лише час очікування відповіді.
mikejonesey

@Ladadadada ви неправі, ELB або ALB робить мало нічого, щоб допомогти проти slowloris, і це вплине на більшість веб-серверів, дивіться моє запитання AWS та вирішуйте
Кріштіану Коельо

9

Щось підключається до порту, а потім ніколи не надсилає дані. HTTP 408 - помилка "тайм-аут". Тут є хороша реєстрація: http://www.checkupdown.com/status/E408.html


1
Хоча це посилання може відповісти на питання, краще включити сюди суттєві частини відповіді та надати посилання для довідки. Відповіді лише на посилання можуть стати недійсними, якщо пов’язана сторінка зміниться.
kasperd

Щойно переглянувши список із 100+ IP-адрес, які отримують 408s на свої порожні запити, помітно, що більшість з материкового Китаю, і я підозрюю, що проблема пов'язана насамперед із заторами. Перевантаженість внаслідок чого налаштування з'єднання вдається, але заголовок запиту не надсилається. Поперечна пропускна здатність кордону від Китаю дуже перевантажена, і з'єднання, що не входять до материка, також прибувають порожніми, були розсіяні з Бразилії, Європи та сільських США, які, правдоподібно, мають подібні проблеми при досягненні сервера США на Західному узбережжі.
ClearCrescendo

8

Тут вже є кілька хороших відповідей, але я хотів би загрожувати ще однією додатковою запискою, яка не була конкретно розглянута. Як багато з попередніх коментаторів вже згадувалося, 408 вказує на тайм-аут; і існує чимала кількість обставин, за яких на веб-сервері виникають тайм-аути.

З огляду на це, 408 помилок може бути сформовано у різних випадках, коли ваш сервер перевіряється на подвиги. Клієнти в таких випадках рідко представляють користувальницький агент і часто різко припиняють з'єднання, що призводить до абортивного відключення для цього з'єднання, що може призвести до помилки 408.

Наприклад, скажімо, що я підступний хакер, який сканує Інтернет на комп’ютери, які все ще вразливі до вразливості POODLE. Як такий, я написав сценарій, який відкриває з'єднання з великими фрагментами IP-адрес, щоб знайти сервери, які приймуть SSL версії 3 - пізніше я скористаюся цим списком, щоб спеціально перевірити експлуатацію POODLE. Все, що робить цей перший скрипт - це встановити з'єднання за допомогою openssl для перевірки наявності SSLv3, наприклад:

openssl s_client -connect [IP]:443 -ssl3

Ця команда в багатьох конфігураціях Apache призведе до повідомлення 408 точно так, як ви описали. Виконання цієї команди на двох моїх власних серверах призвело до цього запису до журналу доступу:

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

Я хотів зробити це зрозумілим, навіть якщо в ситуації, коли OP не використовує будь-яку форму врівноваження навантаження, 408 помилок можуть виникати за різних обставин - деякі шкідливі, деякі вказують на проблеми з клієнтом, а деякі вказують на проблеми з сервером. (Я помітив у журналі, наданому ОП, що локальний IP позначається як віддалений IP, але ОП конкретно не згадував про використання балансира навантаження, тому я не був впевнений, чи ОП просто використовував IP без маршрутизації для своїх цілей демонстрації, як це робилося з URL-адресою)

У будь-якому випадку, навіть незважаючи на те, що мій пост, якщо, очевидно, занадто пізно вдень, щоб допомогти ОП, сподіваємось, це може допомогти іншим, хто приїздить сюди, шукаючи рішення для всіх цих проклятих помилок тайм-аута.


6

Існують різні причини 408 тайм-ауту. Але давайте почнемо з припущення, що все нормально, то в якийсь момент ці 408 почнуть з’являтися у вашому журналі доступу - тобто 408 0 "-" "-".

Як багато хто зазначає в мережі, 408 являє собою з'єднання, але не надсилається запит у відповідному часовому масштабі, тому сервер припиняє з'єднання з 408. Один зарозумілий чоловік насправді відповів на когось, хто просив допомоги з цього питання. - "Яку частину таймауту ви не розумієте".

Я думаю, що це дуже відповідь новачка і демонструє повне нерозуміння того, як деякі методи безпеки функціонують із програмним забезпеченням веб-сервера.

Тож до початку, чому я бачу всі ці 408-і. Одне, що ви матимете спільне з рештою нас, що керують сервером, - це величезна кількість атак, які ви отримуєте щодня. Тепер, що ви робите з цим? Добре: ви використовуєте обрані методи безпеки для боротьби з ними, ось що змінюється.

Візьмемо дуже простий приклад, відкиньте IP адресу. У файлі iptabes (rules.v4) у вас є "-A ufw-user-input -s 37.58.64.228 -j DROP". Таким чином, разом з цим приходить 37.58.64.228 брандмауер розпізнає IP-адресу та припиняє з'єднання. У багатьох конфігураціях ви навіть не знаєте, що стукає у двері.

Тепер давайте скористаємося більш просунутим прикладом: Перервіть з'єднання на основі деяких критеріїв. У файлі iptabes (rules.v4) ви маєте "-A INPUT -p tcp -m tcp --dport 80 -m string --string" cgi "--algo bm - to 1000 -j DROP". Це відрізняється тим, що в цьому правилі iptable ми говоримо, перегляньте перші 1000 байт рядка запиту і побачимо, чи зможете ви знайти підрядку "cgi", і якщо ви знайдете цю підрядку, то не переходьте далі, просто киньте з'єднання.

Тут спосіб безпеки хороший, але наскільки ваші журнали не вводять в оману. Створений 408 0 "-" "-" є найкращим апашем, який можна зробити за цих обставин. З'єднання було встановлено, і запит повинен був бути прийнятий до певного моменту, щоб застосувати правило порівняння рядків, яке в кінцевому підсумку призводить до 408, оскільки ваше правило відповідає критеріям відхилення з'єднання. Отже, наші маленькі початківці кохані не могли бути більше помилятися, якби спробували. Було встановлено зв’язок і отримано запит (ви просто не матимете видимість у цих умовах). Хоча генерується 408, він не є "таймаутом"; ваш сервер просто відмовився від з'єднання після того, як було зроблено запит у зв’язку з вашим правилом брандмауера. Є багато інших правил, які створили б ту саму ситуацію 408. Дон '

В ідеалі був би ще один код помилок, сформований Apache, наприклад - "499", що означатиме "Сервер прочитав ваш запит і вирішив, що його просто не можна турбувати, розважаючи вас - Sod Off HaHa".

За допомогою найновішого програмного забезпечення для веб-серверів ви можете практично виключити атаки DOS, а новий ген браузерів, що містять можливості прогнозування, не викликає цієї проблеми, як вважають деякі.

Коротше кажучи, 408 генерується через те, що сервер не відповів на запит, тому що стосується клієнта, час з'єднання вичерпано, коли насправді сервер прочитав запит, але припинив з'єднання з інших причин, ніж очікування очікування на запит.


2
Але ЧОМУ це перервало зв’язок? Ми бачимо, що це журнали сервера, а не клієнтські журнали.
Ерік Робертсон

5

У нас була ця сама проблема, і ми спантеличували її надто довго. Найкраще рішення, яке ми запропонували, запропонувала команда ELB підтримки AWS. По суті, це залежить від того, щоб налаштування часу очікування вашого сервера httpd було більше, ніж налаштування ELB idle timeout(яке за замовчуванням становить 60 секунд).

  • Переконайтесь, що Timeoutзначення директиви apache вдвічі більше idle timeoutвстановленого для вашого ELB.
  • Увімкніть KeepAliveфункцію, переконайтеся, що MaxKeepAliveRequestsвона дуже велика (або 0 для нескінченного або дуже високого рівня, як 2000), і що KeepAliveTimeoutбільше, ніж у ELB idle timeout.

Ми з’ясували, що налаштування KeepAlive(та пов’язані з ним налаштування) спеціально зменшили кількість 408s до 0 (ми бачимо декілька, але дуже мало).


На жаль, я використовую еластичну паску. У мене немає цих варіантів для мене.
Ерік Робертсон

3

У мене ця проблема стояла позаду AWS Elastic Balancer Balancer. Перевірки здоров’я генерували жахливу кількість 408 відповідей у ​​журналі.

Єдине рішення, яке працювало для мене, полягало в тому, щоб встановити час очікування режиму очікування балансового механізму нижче, ніж час очікування реакції перевірки здоров'я .


0

Нещодавно колега зауважив, що в той час, коли мій останній пост дав вагомі пояснення, як 408 може асоціюватися з заходом безпеки, він не запропонував рішення.

Журнал доступу до труб - це моє особисте рішення.

У більшості конфігурацій Ubuntu та з мінімальним позначенням інших конфігурацій Apache слід працювати нижче. Я вибрав PHP, тому що це найлегше зрозуміти. Є два сценарії: перший запобігає запису 408 у ваш журнал доступу. Другий скрипт відправляє всі 408s в окремий файл журналу. У будь-якому випадку результат не більше 408 у вашому журналі доступу. Це ваш вибір, який сценарій реалізувати.

Використовуйте улюблений текстовий редактор, я використовую нано. Відкрийте файл, де у вас є директиви "LogFormat" та "CustomLog". Прокоментуйте оригінали за допомогою звичайного # та додайте наступне. Ви можете знайти ці директиви у наведеному нижче файлі.

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

ПРИМІТКА. Я не реєструю зображення у своєму журналі доступу. У свій файл etc / apache2 / httpd.conf я включаю рядок

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

Якщо це не цікавить вас , то видалити env=!dontlogз CustomLogдирективи.

Тепер створіть один із наступних скриптів PHP ( #!/usr/bin/phpце посилання на розташування інтерпретатора, переконайтесь, що місце розташування є правильним для вашої системи. Ви можете це зробити, ввівши в рядок $; whereis php- це має повернути щось подібне php: /usr/bin/php /usr/bin/X11/php /usr/share/man/man1/php.1.gz. Як ви бачимо #!/usr/bin/php, підходить для моєї настройки).

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);
      }
    }
  }
?>

Збереживши PipedAccessLog.phpсценарій; переконайтеся, що root має право власності, виконавши наступне у рядку $.

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

PipedAccessLog.phpСкрипт потрібен для читання / запису і дозвіл на виконання так виконати наступне в $ рядки.

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

Нарешті, щоб отримати все необхідне, потрібно перезапустити послугу Apache. Виконайте наступне у запиті $.

sudo service apache2 restart

Якщо ваші журнали Apache розташовані в іншому місці, то змініть шляхи відповідно до вашої конфігурації. Щасти.


6
Якщо 408-ті відбуваються, нам потрібно з’ясувати, чому і позбутися від них. Просто запобігти їх реєстрації або передачі їх до іншого файлу - це марна трата часу сервера. Він також служить лише для приховування проблеми. Це як прибирати свою кімнату, засунувши все під ліжко.
Ерік Робертсон

-2

Я виявив, що 408 помилок збільшується як за кількістю, так і за частотою. Діапазон IP-адрес, з яких вони походять, також зростає (вони реєструються у власному окремому файлі). Існують також очевидні шаблони журналів, що відображають послідовні 408-х з тих самих груп IP, які не пов’язані з нормальними тайм-аутами сервера, оскільки ініціатор намагається з'єднати приблизно 2 або 3 секунди один від одного за циклічною схемою (немає очікування очікування очікування до іншого спроба підключення) Я бачу це як прості спроби підключення стилю DDOS. На мою думку, це тип підтвердження для оригінатора, що сервер перебуває в Інтернеті ... потім вони повертаються пізніше за допомогою різних інструментів .... Якщо ви збільшите інтервал очікування, ви просто надаєте їм більший time_allocation для запуску їхні хакерські програми в межах.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.