¿Por qué de repente había tantas 400 solicitudes en mi registro de acceso?

10

Debajo hay una pequeña parte de mi acceso_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 "-" "-"

Y el volumen era muy grande, algunos como cien mil de estas 400 solicitudes por segundo. Y estoy bastante seguro de que no hay errores en mi sitio en ese período de tiempo (sin informe de error y no cambié el código fuente)

nginx

— dotslashlu
fuente

5

Alguien estaba Fuzzing su servidor. Ver también Wikipedia .

Básicamente implica enviar bloques rápidos de datos no válidos para ver si algo se rompe.

Nginx está configurado para devolver un error de error 400 cuando no se envían datos de solicitud.

No te preocupes por eso. Nginx puede seguir rebotando para siempre sin sudar.

— Dayo
fuente

De lo único que tendrá que preocuparse es de los archivos de registro que absorben espacio en disco. Aquí es donde es útil la rotación adecuada del registro.

— Justin Pearce

El mismo problema aqui. La cantidad de direcciones IP diferentes no hace que un ataque (fuzzing) sea muy probable en mi opinión. Todavía estoy buscando una mejor explicación.

— Oliver

2

Compruebe y vea si la dirección IP que causa el 400 está usando Google Chrome. Chrome usa la conexión previa para establecer varias conexiones con el servidor y cerrarlas si no se usa.

Como no se realiza ninguna solicitud en la conexión, nginx registrará este error.

— lulalala
fuente

Veo el mismo problema aquí, y tengo exactamente el mismo formato de archivo de registro, así que supongo que el OP no cambió el valor predeterminado. Lo que significa que la cadena del agente de usuario se está registrando; simplemente sucede que no contiene ningún valor. Así que no estoy seguro de cómo verificar si esos clientes están usando Chrome. Yo mismo no pude reproducir este error en el registro con Chrome 26 en este momento. ¿Alguna otra pista?

— Oliver

El agente de usuario se envía como un encabezado de solicitud, a menos que / hasta que se realice una solicitud, nginx no tenga medios para conocer y registrar la cadena del agente de usuario. Sin embargo, puede verificar otros registros que provienen de esa dirección IP y, si alguna solicitud real fue hecha por ese cliente, saber si era Chrome o no.

— Ivan Anishchuk