Я отримую багато запитів у наших журналах apache, які виглядають приблизно так
www.example.com:80 10.240.1.8 - - [06/Mar/2013:00:39:19 +0000] "-" 408 0 "-" "-" -
Здається, немає запиту та агента користувача. Хтось бачив це раніше?
Я отримую багато запитів у наших журналах apache, які виглядають приблизно так
www.example.com:80 10.240.1.8 - - [06/Mar/2013:00:39:19 +0000] "-" 408 0 "-" "-" -
Здається, немає запиту та агента користувача. Хтось бачив це раніше?
Відповіді:
Ви випадково запускаєте свої веб-сервери в Amazon за еластичним балансиром навантаження?
Здається, вони отримують багато 408 відповідей завдяки їхнім медичним перевіркам .
Деякі рішення з теми форуму:
RequestReadTimeout header=0 body=0
Це вимикає 408 відповідей, якщо запит вичерпується.
Вимкнути журнал для IP-адрес ELB за допомогою:
SetEnvIf Remote_Addr "10\.0\.0\.5" exclude_from_log
CustomLog logs/access_log common env=!exclude_from_log
І з цього блогу :
RequestReadTimeout header=0 body=0
відключив б час запиту на час читання, я б не рекомендував цього
Щось підключається до порту, а потім ніколи не надсилає дані. HTTP 408 - помилка "тайм-аут". Тут є хороша реєстрація: http://www.checkupdown.com/status/E408.html
Тут вже є кілька хороших відповідей, але я хотів би загрожувати ще однією додатковою запискою, яка не була конкретно розглянута. Як багато з попередніх коментаторів вже згадувалося, 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-адресою)
У будь-якому випадку, навіть незважаючи на те, що мій пост, якщо, очевидно, занадто пізно вдень, щоб допомогти ОП, сподіваємось, це може допомогти іншим, хто приїздить сюди, шукаючи рішення для всіх цих проклятих помилок тайм-аута.
Існують різні причини 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 генерується через те, що сервер не відповів на запит, тому що стосується клієнта, час з'єднання вичерпано, коли насправді сервер прочитав запит, але припинив з'єднання з інших причин, ніж очікування очікування на запит.
У нас була ця сама проблема, і ми спантеличували її надто довго. Найкраще рішення, яке ми запропонували, запропонувала команда ELB підтримки AWS. По суті, це залежить від того, щоб налаштування часу очікування вашого сервера httpd було більше, ніж налаштування ELB idle timeout
(яке за замовчуванням становить 60 секунд).
Timeout
значення директиви apache вдвічі більше idle timeout
встановленого для вашого ELB.KeepAlive
функцію, переконайтеся, що MaxKeepAliveRequests
вона дуже велика (або 0 для нескінченного або дуже високого рівня, як 2000), і що KeepAliveTimeout
більше, ніж у ELB idle timeout
.Ми з’ясували, що налаштування KeepAlive
(та пов’язані з ним налаштування) спеціально зменшили кількість 408s до 0 (ми бачимо декілька, але дуже мало).
У мене ця проблема стояла позаду AWS Elastic Balancer Balancer. Перевірки здоров’я генерували жахливу кількість 408 відповідей у журналі.
Єдине рішення, яке працювало для мене, полягало в тому, щоб встановити час очікування режиму очікування балансового механізму нижче, ніж час очікування реакції перевірки здоров'я .
Нещодавно колега зауважив, що в той час, коли мій останній пост дав вагомі пояснення, як 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 розташовані в іншому місці, то змініть шляхи відповідно до вашої конфігурації. Щасти.
Я виявив, що 408 помилок збільшується як за кількістю, так і за частотою. Діапазон IP-адрес, з яких вони походять, також зростає (вони реєструються у власному окремому файлі). Існують також очевидні шаблони журналів, що відображають послідовні 408-х з тих самих груп IP, які не пов’язані з нормальними тайм-аутами сервера, оскільки ініціатор намагається з'єднати приблизно 2 або 3 секунди один від одного за циклічною схемою (немає очікування очікування очікування до іншого спроба підключення) Я бачу це як прості спроби підключення стилю DDOS. На мою думку, це тип підтвердження для оригінатора, що сервер перебуває в Інтернеті ... потім вони повертаються пізніше за допомогою різних інструментів .... Якщо ви збільшите інтервал очікування, ви просто надаєте їм більший time_allocation для запуску їхні хакерські програми в межах.