Pourquoi y avait-il soudainement autant de 400 demandes dans mon journal d'accès?

10

Voici une petite partie de mon 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 "-" "-"

Et le volume était très énorme, certains comme cent mille de ces 400 requêtes par seconde. Et je suis presque sûr qu'il n'y a pas d'erreur sur mon site pendant cette période (pas de rapport d'erreur et je n'ai pas changé le code source)

nginx

— dotslashlu
source

5

Quelqu'un a fuzzé votre serveur. Voir également Wikipedia .

Il s'agit essentiellement d'envoyer des blocs rapides de données non valides pour voir si quelque chose se casse.

Nginx est configuré pour renvoyer une erreur d'erreur 400 lorsqu'aucune donnée de demande n'est envoyée.

Ne t'en fais pas. Nginx peut juste continuer à les faire rebondir pour toujours sans casser une sueur.

— Dayo
source

La seule chose dont il devra s'inquiéter, ce sont les fichiers journaux qui absorbent l'espace disque. C'est là que la rotation appropriée des journaux est utile.

— Justin Pearce

Même problème ici. Le nombre d'adresses IP différentes ne rend pas une attaque (fuzzing) très probable à mon avis. Toujours à la recherche d'une meilleure explication.

— Oliver

2

Vérifiez et voyez si l'adresse IP à l'origine du 400 utilise Google Chrome. Chrome utilise la pré-connexion pour établir plusieurs connexions avec le serveur et les fermer s'il n'est pas utilisé.

Puisqu'aucune demande n'est faite dans la connexion, nginx enregistrera cette erreur.

— lulalala
source

Je vois le même problème ici, et j'ai exactement le même format de fichier journal, donc je suppose que l'OP n'a pas changé la valeur par défaut. Ce qui signifie que la chaîne de l'agent utilisateur est en cours d'enregistrement - il se trouve qu'il ne contient aucune valeur. Je ne sais donc pas comment vérifier si ces clients utilisent Chrome. Je n'ai pas pu reproduire cette erreur dans le journal en utilisant Chrome 26 tout à l'heure. D'autres indices?

— Oliver

L'agent utilisateur est envoyé en tant qu'en-tête de demande, sauf si / jusqu'à ce qu'une demande soit effectuée, nginx n'a aucun moyen de connaître et de consigner la chaîne de l'agent utilisateur. Vous pouvez cependant vérifier d'autres enregistrements de journal provenant de cette adresse IP et, si une demande réelle a été faite par ce client, savoir s'il s'agissait de Chrome ou non.

— Ivan Anishchuk