Obtenir 408 erreurs sur nos journaux sans demande ni agent utilisateur

Je reçois beaucoup de demandes dans nos journaux Apache qui ressemblent à ceci

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

Il semble n'y avoir aucune demande et aucun agent d'utilisateur. Quelqu'un a-t-il déjà vu cela avant?

Êtes-vous par hasard en train d'exécuter vos serveurs Web dans Amazon derrière un Elastic Load Balancer?

Il semble qu'ils génèrent beaucoup de 408 réponses en raison de leurs bilans de santé .

Certaines des solutions de ce fil de discussion:

• RequestReadTimeout header=0 body=0

  Ceci désactive les 408 réponses si une requête arrive à expiration.

• Remplacez le contrôle de santé ELB par un autre port.

• Désactiver la journalisation pour les adresses IP ELB avec:

  SetEnvIf Remote_Addr "10\.0\.0\.5" exclude_from_log
  CustomLog logs/access_log common env=!exclude_from_log
  

Et à partir de ce blog :

• Ajustez le délai d'attente de votre demande à 60 ou plus.

Quelque chose se connecte au port et n’envoie jamais de données. HTTP 408 est une erreur "timeout". Il y a une bonne écriture ici: http://www.checkupdown.com/status/E408.html

Il y a déjà pas mal de bonnes réponses ici, mais je voudrais hasarder une note supplémentaire qui n'a pas été spécifiquement abordée. Comme plusieurs des précédents commentateurs déjà mentionnés, 408 indique un délai d'expiration; et il existe toute une série de circonstances dans lesquelles des délais d'attente se produisent sur un serveur Web.

Cela dit, 408 erreurs peuvent être générées dans une variété de cas où votre serveur est analysé pour des exploits. Dans de tels cas, les clients présentent rarement un agent d'utilisateur et mettent souvent fin aux connexions de manière abrupte, ce qui entraîne un arrêt inopiné de cette connexion pouvant générer une erreur 408.

Par exemple, supposons que je sois un hacker ignoble qui analyse Internet pour trouver des ordinateurs toujours vulnérables à la vulnérabilité POODLE. En tant que tel, j’ai écrit un script qui ouvre des connexions à de grandes quantités d’adresses IP pour trouver des serveurs acceptant la version 3 de SSL. Plus tard, j’utiliserai cette liste pour analyser de manière ciblée l’exploit POODLE. Tout ce que ce premier script fait est d’établir une connexion en utilisant openssl pour vérifier SSLv3, comme ceci:

openssl s_client -connect [IP]:443 -ssl3

Cette commande, dans de nombreuses configurations d’Apache, produira un message 408 exactement comme vous l’avez décrit. L'exécution de cette commande sur deux de mes propres serveurs a entraîné cette entrée dans le journal des accès:

<remote IP address>  - - [04/Nov/2015:08:09:33 -0500] "-" 408 - "-" "-"

Je tenais à préciser que même dans une situation où OP n’utilisait aucune forme d’équilibrage de la charge, des erreurs 408 peuvent survenir dans diverses circonstances, certaines malveillantes, certaines indiquant des problèmes avec le client et d’autres indiquant des problèmes avec le serveur. (J'ai remarqué dans le journal fourni par OP qu'une adresse IP locale était indiquée comme adresse IP distante, mais OP ne mentionnant pas spécifiquement l'utilisation d'un équilibreur de charge, je ne savais pas si OP avait simplement utilisé une adresse IP non routable aux fins de démonstration, comme il l'a fait avec l'URL)

Quoi qu'il en soit, même si mon message est manifestement beaucoup trop tard dans la journée pour aider le PO, il pourrait peut-être aider les autres qui arrivent ici à chercher une solution à toutes ces fichues erreurs de délai d'attente.

Il existe différentes raisons pour un délai d'attente 408. Mais partons du principe que tout va bien, puis à un moment donné, ces 408 apparaissent dans votre journal d’accès - c’est-à-dire 408 0 "-" "-".

Comme beaucoup de personnes le signalent sur le net, un 408 représente une connexion établie, mais aucune demande n'est envoyée dans l'échelle de temps appropriée. Le serveur interrompt la connexion avec un 408. Une personne arrogante a en fait répondu à une personne qui demandait de l'aide à ce sujet avec - "Quelle partie de Timeout tu ne comprends pas".

Je pense que c'est vraiment une réponse novice et démontre un manque total de compréhension du fonctionnement de certaines méthodes de sécurité avec un logiciel de serveur Web.

Revenons donc au début, pourquoi vois-je toutes ces 408? Une des choses que vous aurez en commun avec le reste d’entre nous qui gérons un serveur est la grande quantité d’attaques que vous recevez quotidiennement. Maintenant, que faites-vous à propos de ceux-ci? Eh bien: vous utilisez les méthodes de sécurité que vous avez choisies pour les gérer, c’est ce qui change.

Prenons un exemple très simple, déposez une adresse IP. Inclus dans un fichier iptabes (rules.v4) vous avez "-Ufw-user-input -s 37.58.64.228 -j DROP". 37.58.64.228, le pare-feu reconnaît l'adresse IP et interrompt la connexion. Dans de nombreuses configurations, vous ne sauriez même pas que c'est frappé à la porte.

Prenons maintenant un exemple plus avancé, Supprimez la connexion en fonction de certains critères. Dans un fichier iptabes (rules.v4), vous avez "-A INPUT -p tcp -m tcp --dport 80 chaîne -string" cgi "--algo bm --to 1000 -j DROP". Ceci est différent parce que dans cette règle iptable nous disons de regarder les 1 000 premiers octets de la chaîne de requête et de voir si vous pouvez trouver une sous-chaîne de "cgi" et si vous trouvez cette sous-chaîne, alors n'allez pas du tout. plus loin, il suffit de laisser tomber la connexion.

Ici, la méthode de sécurité est bonne, mais trompeuse en ce qui concerne vos journaux. Le 408 0 "-" "-" généré est ce que apache peut faire de mieux dans ces circonstances. La connexion a été établie et la demande a dû être acceptée jusqu'à un certain point pour appliquer la règle de comparaison de chaînes qui aboutit à un code 408, car votre règle remplissait les critères pour que la connexion soit abandonnée. Ainsi, nos petits chéris novices ne pourraient pas avoir plus tort s'ils essayaient. Une connexion a été établie et une demande a été reçue (vous n'en aurez tout simplement pas la visibilité dans ces circonstances). Bien qu'un 408 soit généré, il ne s'agit pas d'un "délai d'attente"; votre serveur a simplement interrompu la connexion après que la demande a été faite en association avec votre règle de pare-feu. Il existe de nombreuses autres règles qui créeraient la même 408 situation. Don'

Idéalement, il y aurait un autre code d'erreur généré par Apache, par exemple - "499", ce qui signifierait "Le serveur lit votre requête et décide qu'il ne pouvait pas être dérangé de vous divertir - Sod Off HaHa".

Avec le dernier logiciel de serveur Web, vous pouvez pratiquement exclure les attaques de type DOS et le nouveau gène des navigateurs intégrant des fonctionnalités prédictives ne cause pas ce problème, comme certains l’ont suggéré.

En bref, la 408 est générée parce que le serveur n’a pas répondu à la requête. Par conséquent, la connexion a expiré, alors que le serveur a lu la requête mais a interrompu la connexion pour des raisons autres que le délai d’attente. une requête.

Nous avons eu ce problème même et avons été perplexes à ce sujet pendant un bon bout de temps. La meilleure solution que nous avons proposée a été suggérée par l'équipe ELB du support AWS. Cela repose essentiellement sur le fait de s'assurer que les paramètres de délai d'attente de votre serveur httpd sont tous supérieurs à votre idle timeoutparamètre ELB (défini par défaut à 60 secondes).

• Assurez-vous que la Timeoutvaleur de votre directive apache est le double de celle idle timeoutde votre ELB.
• Activez la KeepAlivefonctionnalité, assurez-vous qu’elle MaxKeepAliveRequestsest très grande (0 pour infini ou très élevé, comme 2000) et KeepAliveTimeoutsupérieure à votre ELB idle timeout.

Nous avons constaté que le KeepAliveparamètre (et les paramètres associés) réduisait spécifiquement la quantité de 408 à 0 (nous en voyons peu, mais très peu).

J'ai eu ce problème derrière AWS Elastic Load Balancer. Les bilans de santé ont généré une quantité affreuse de 408 réponses dans le journal.

La seule solution qui a fonctionné pour moi a consisté à définir le paramètre Délai d'inactivité de Load Balancer plus bas que le délai de réponse de la vérification d'intégrité .

Un collègue a récemment fait remarquer que si mon dernier message expliquait de manière valable comment une 408 pouvait être associée à une mesure de sécurité, il ne proposait aucune solution.

Piped Access Log est ma solution personnelle.

Ce qui suit devrait fonctionner immédiatement avec la plupart des configurations Ubuntu et avec un minimum de retouches sur les autres configurations Apache. J'ai choisi PHP parce que c'est le plus facile à comprendre. Il existe deux scripts: le premier empêche l’écriture d’un fichier 408 dans votre journal d’accès. Le second script envoie les 408 dans un fichier journal séparé. Dans les deux cas, le résultat n’a plus 408s dans votre journal d’accès. C'est à vous de choisir le script à implémenter.

Utilisez votre éditeur de texte préféré, j'utilise nano. Ouvrez le fichier où vous avez vos directives 'LogFormat' et 'CustomLog'. Mettez les originaux avec le # habituel et ajoutez le texte suivant. Vous pouvez trouver ces directives dans le fichier ci-dessous.

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

REMARQUE: je n'enregistre pas les images dans mon journal d'accès. Dans mon fichier etc / apache2 / httpd.conf, j'inclus la ligne

SetEnvIfNoCase Request_URI ".(gif)|(jpg)|(png)|(css)|(js)|(ico)$" dontlog

Si cela ne vous intéresse pas, supprimez le env=!dontlogde la CustomLogdirective.

Créez maintenant l’un des scripts PHP suivants ( #!/usr/bin/phpréférence à l’emplacement de l’interprète, assurez-vous que cet emplacement est correct pour votre système - vous pouvez le faire en tapant à l’invite $; whereis php- ceci devrait retourner quelque chose comme php: /usr/bin/php /usr/bin/X11/php /usr/share/man/man1/php.1.gz. peut voir #!/usr/bin/phpest juste pour ma configuration).

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);
      }
    }
  }
?>

Ayant sauvé le PipedAccessLog.phpscript; assurez-vous que la racine est la propriété en exécutant ce qui suit à l’invite $.

sudo chown -R root:adm /var/log/apache2/PipedAccessLog.php

Le PipedAccessLog.phpscript nécessitera des autorisations de lecture / écriture et d’exécution; exécutez les opérations suivantes à l’invite $.

sudo chmod 755 /var/log/apache2/PipedAccessLog.php

Enfin, pour que tout fonctionne, vous devez redémarrer le service Apache. Exécutez ce qui suit à l’invite $.

sudo service apache2 restart

Si vos journaux Apache sont situés ailleurs, modifiez les chemins en fonction de votre configuration. Bonne chance.

J'ai constaté que 408 erreurs augmentent en nombre et en fréquence. La gamme d'adresses IP à partir desquelles ils proviennent est également en augmentation (elles sont enregistrées dans leur propre fichier séparé). Il existe également des modèles de journal évidents affichant des fichiers 408 consécutifs appartenant aux mêmes groupes d’IP, qui ne sont pas dus à des délais d’expiration normaux du serveur, car l’émetteur tente de se connecter à un intervalle de 2 ou 3 secondes dans un modèle cyclique (il n’ya pas de délai d'attente avant un autre tentative de connexion) Je les vois comme de simples tentatives de connexion de style DDOS. À mon avis, il s’agit d’un type de message de confirmation indiquant à un créateur que le serveur est en ligne ... puis qu’ils reviennent plus tard avec différents outils .... Si vous augmentez votre délai d’expiration, vous leur donnez simplement une plus grande durée pour pouvoir être exécutée. leurs programmes de piratage au sein.