Почему в моем журнале доступа появилось так много 400 запросов?

10

Ниже приведена маленькая часть моего access_log

118.186.8.50 - - [19/Dec/2011:22:42:57 +0800] "-" 400 0 "-" "-"
05
118.186.8.50 - - [19/Dec/2011:22:42:57 +0800] "-" 400 0 "-" "-"
06
118.186.8.50 - - [19/Dec/2011:22:42:57 +0800] "-" 400 0 "-" "-"
07
118.186.8.50 - - [19/Dec/2011:22:42:57 +0800] "-" 400 0 "-" "-"
08
118.186.8.50 - - [19/Dec/2011:22:42:57 +0800] "-" 400 0 "-" "-"
09
220.173.136.39 - - [19/Dec/2011:22:43:22 +0800] "-" 400 0 "-" "-"
10
220.173.136.39 - - [19/Dec/2011:22:43:22 +0800] "-" 400 0 "-" "-"
11
220.173.136.39 - - [19/Dec/2011:22:43:22 +0800] "-" 400 0 "-" "-"
12
220.173.136.39 - - [19/Dec/2011:22:43:22 +0800] "-" 400 0 "-" "-"
13
220.173.136.39 - - [19/Dec/2011:22:43:22 +0800] "-" 400 0 "-" "-"
14
220.173.136.39 - - [19/Dec/2011:22:43:22 +0800] "-" 400 0 "-" "-"

И объем был очень огромный, примерно сто тысяч из этих 400 запросов в секунду. И я почти уверен, что в этот период на моем сайте не было ошибок (нет отчетов об ошибках, и я не изменил исходный код)

nginx dotslashlu
источник

Ответы:

5

Кто-то Fuzzing ваш сервер. Также см. Википедию .

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

Nginx настроен на возврат ошибки 400, когда данные запроса не отправляются.

Не беспокойся об этом. Nginx может просто продолжать прыгать на них вечно, не потея.

Dayo
источник
Единственное, о чем ему придется беспокоиться, это файлы журнала, занимающие место на диске. Вот где правильная ротация журнала полезна.
Джастин Пирс
Та же проблема здесь. Количество разных IP-адресов, на мой взгляд, не делает атаку (фаззинг) очень вероятной. Все еще ищу лучшее объяснение.
Оливер
2

Проверьте и посмотрите, использует ли IP-адрес, вызывающий 400, Google Chrome. Chrome использует предварительное соединение, чтобы установить несколько соединений с сервером и закрыть их, если они не используются.

Поскольку в соединении не делается никаких запросов, nginx запишет эту ошибку.

lulalala
источник
Я вижу ту же проблему здесь, и у меня точно такой же формат файла журнала, поэтому я предполагаю, что OP не изменил значение по умолчанию. Это означает, что строка агента пользователя записывается в журнал - так получилось, что она не содержит никакого значения. Поэтому я не уверен, как проверить, используют ли эти клиенты Chrome. Я сам не мог воспроизвести эту ошибку в журнале, используя Chrome 26 только сейчас. Любые другие намеки?
Оливер
Пользовательский агент отправляется как заголовок запроса, если / до тех пор, пока не будет сделан запрос, nginx не имеет возможности узнать и зарегистрировать строку пользовательского агента. Однако вы можете проверить другие записи журнала, поступившие с этого IP-адреса, и, если фактический запрос был фактически сделан этим клиентом, узнать, был ли это Chrome или нет.
Иван Анищук