Por que de repente houve tantos 400 pedidos no meu log de acesso?

10

Abaixo estão uma pequena parte do meu 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 "-" "-"

E o volume era muito grande, alguns como cem mil desses 400 pedidos por segundo. E tenho certeza de que não há erros no meu site nesse período (nenhum relatório de erro e eu não alterei o código-fonte)

dotslashlu
fonte

Respostas:

5

Alguém estava confundindo seu servidor. Veja também a Wikipedia .

Basicamente, envolve o envio de blocos rápidos de dados inválidos para ver se algo quebra.

Nginx está definido para retornar um erro de erro 400 quando nenhum dado de solicitação é enviado.

Não se preocupe com isso. O Nginx pode continuar saltando para sempre sem suar a camisa.

Dayo
fonte
A única coisa com a qual ele terá que se preocupar é com os arquivos de log que absorvem o espaço em disco. É aqui que a rotação adequada do log é útil.
23611 Justin Pearce
Mesmo problema aqui. A quantidade de endereços IP diferentes não torna muito provável um ataque (confuso) na minha opinião. Ainda estou procurando uma explicação melhor.
Oliver
2

Verifique e veja se o endereço IP que causa o 400 está usando o Google Chrome. O Chrome usa a pré-conexão para estabelecer várias conexões com o servidor e fechá-las se não forem usadas.

Como nenhuma solicitação é feita na conexão, o nginx registrará esse erro.

lulalala
fonte
Estou vendo o mesmo problema aqui e tenho exatamente o mesmo formato de arquivo de log, portanto, assumo que o OP não alterou o padrão. O que significa que a string do agente do usuário está sendo registrada - acontece que ela não contém nenhum valor. Portanto, não sei como verificar se esses clientes estão usando o Chrome. Eu mesmo não consegui reproduzir esse erro no log usando o Chrome 26 agora. Alguma outra dica?
Oliver
O agente do usuário é enviado como um cabeçalho da solicitação, a menos que / até que uma solicitação seja feita, o nginx não tem como conhecer e registrar a cadeia de caracteres do agente do usuário. No entanto, você pode verificar outros registros de log provenientes desse endereço IP e, se alguma solicitação real tiver sido realmente feita por esse cliente, saber se era Chrome ou não.
Ivan Anishchuk 17/01