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

Что-то подключается к порту, но не отправляет данные. HTTP 408 - ошибка «тайм-аут». Здесь есть хорошая запись: http://www.checkupdown.com/status/E408.html

У нас была именно эта проблема, и мы долго над ней ломали голову. Лучшее решение, которое мы придумали, было предложено командой ELB службы поддержки AWS. По сути, это зависит от того, чтобы все настройки тайм-аута вашего httpd-сервера превышали значение вашего ELB таймаута простоя (по умолчанию 60 секунд).

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

Существуют различные причины тайм-аута 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 "-" "-" - лучшее, что может сделать apache в этих обстоятельствах. Соединение было установлено, и запрос должен был быть принят до определенного момента, чтобы применить правило сравнения строк, которое в конечном итоге приводит к ошибке 408, потому что ваше правило соответствует критериям для разрыва соединения. Так что наши маленькие новички не могли ошибиться больше, если бы попытались. Установлено соединение и получен запрос (вы только что выиграли при таких обстоятельствах не видеть его). Хотя генерируется 408, это не «Тайм-аут»; ваш сервер просто разорвал соединение после того, как запрос был сделан в соответствии с вашим правилом брандмауэра. Есть много других правил, которые могут создать ту же ситуацию 408. Не принимайте слишком буквально объяснение кода ошибки сервера 408 - «Превышено время ожидания запроса».

В идеале должен быть другой код ошибки, сгенерированный Apache, например - «499», что будет означать «Сервер прочитал ваш запрос и принял его просто. Вас не смущает развлечение - черт возьми, ха-ха '.

С помощью новейшего программного обеспечения для веб-серверов вы можете практически исключить атаки DOS, а новое поколение браузеров, включающих в себя функции прогнозирования, не вызывает этой проблемы, как некоторые предполагают.

Короче говоря,

Коллега недавно заметил, что, хотя в моем последнем сообщении дается верное объяснение того, как 408 может иметь связь с мерой безопасности, он не предлагает решения.

Журнал Piped Access - мое личное решение .

Следующее должно работать "из коробки" в большинстве конфигураций Ubuntu и с минимальными изменениями в других конфигурациях Apache. Я выбрал PHP, потому что его легче всего понять. Есть два сценария: первый предотвращает запись 408 в ваш журнал доступа. Второй сценарий отправляет все сообщения 408 в отдельный файл журнала. В любом случае в вашем журнале доступа не будет больше 408. Какой скрипт реализовать - решать вам.

Используйте свой любимый текстовый редактор, я использую nano. Откройте файл, в котором находятся директивы 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 находятся где-то еще, измените пути в соответствии с вашей конфигурацией. Удачи.

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 находятся где-то еще, измените пути в соответствии с вашей конфигурацией. Удачи.

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 для запуска их программы взлома внутри.

У меня возникла эта проблема за AWS Elastic Load Balancer. Проверки работоспособности генерировали ужасное количество ответов 408 в журнале.

Единственное решение, которое сработало для меня, заключалось в том, чтобы установить таймаут простоя балансировщика нагрузки ниже , чем его работоспособность Тайм-аут ответа проверки .

Здесь уже есть несколько хороших ответов, но я хотел бы рискнуть еще одним замечанием, которое не было специально рассмотрено. Как уже упоминалось многими предыдущими комментаторами,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 могут возникать в различных обстоятельств - некоторые злонамеренные, некоторые указывают на проблемы с клиентом, а некоторые указывают на проблемы с сервером. (Я заметил в журнале, предоставленном OP, что локальный IP-адрес был указан как удаленный IP-адрес, но OP конкретно не упомянул использование балансировщика нагрузки, поэтому я не был уверен, что OP просто использовал немаршрутизируемый IP-адрес для этих целей демонстрации, как он это сделал с URL-адресом)

В любом случае, хотя мой пост явно слишком поздно, чтобы помочь OP, надеюсь, он может помочь другим, которые прибывают сюда в поисках решения всех этих чертовых ошибок тайм-аута .