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

Я получаю много запросов в наших логах apache, которые выглядят так

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

Кажется, нет запроса и пользовательского агента. Кто-нибудь видел это раньше?

Вы случайно не используете свои веб-серверы в Amazon за Elastic Load Balancer?

Кажется, они генерируют много 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 или выше.

Что-то подключается к порту, а затем никогда не отправляет данные. 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 ошибок могут возникать при различных обстоятельствах - некоторые злонамеренные, некоторые указывают на проблему с клиентом, а некоторые указывают на проблему с сервером. (В журнале, предоставленном OP, я заметил, что в качестве удаленного IP-адреса был указан локальный IP-адрес, но в OP не упоминалось конкретно использование балансировщика нагрузки, поэтому я не был уверен, что OP просто использовал немаршрутизируемый 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 строка - строка" cgi "--algo bm --to 1000 -j DROP". Это отличается, потому что в этом правдоподобном правиле мы говорим, посмотрите на первые 1000 байтов строки запроса и посмотрите, сможете ли вы найти подстроку "cgi", и если вы найдете эту подстроку, то не переходите далее просто сбросьте соединение.

Здесь метод безопасности хорош, но, насколько ваши логи, вводит в заблуждение. Сгенерированный 408 0 "-" "-" - лучшее, что может сделать Apache в этих условиях. Соединение было установлено, и запрос должен был быть принят до определенного момента, чтобы применить правило сравнения строк, которое в конечном итоге приводит к 408, потому что ваше правило соответствовало критериям для сброса соединения. Итак, наши маленькие новички не могли ошибаться, если пытались. Соединение было установлено, и был получен запрос (вы просто не сможете увидеть его в этих обстоятельствах). Хотя генерируется 408, это не «Тайм-аут»; ваш сервер просто разорвал соединение после того, как был сделан запрос в соответствии с правилом брандмауэра. Есть много других правил, которые создали бы такую ​​же ситуацию. Дон»

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

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

Короче говоря, 408 генерируется, потому что сервер не ответил на запрос, так что для клиента истекло время ожидания соединения, когда в действительности сервер прочитал запрос, но разорвал соединение по причинам, отличным от ожидания ожидания запрос.

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

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

Мы обнаружили, что KeepAliveнастройка (и соответствующие настройки) специально сократила количество 408 с до 0 (мы видим несколько, но очень мало).

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

Единственное решение , которое работало для меня было иметь Idle Timeout службы балансировки нагрузки в настройки ниже , чем его Timeout Check здравоохранения Response .

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

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

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