Recevoir des erreurs 408 dans nos journaux sans demande ou agent utilisateur

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

Cela étant dit, les erreurs 408 peuvent être générées dans divers cas où votre serveur est balayé à la recherche d'exploits. Dans de tels cas, les clients présentent rarement un agent utilisateur et mettent souvent fin brusquement aux connexions, ce qui entraîne une fermeture abrupte pour cette connexion pouvant générer une erreur 408.

Par exemple, disons que je suis un vilain pirate informatique qui balaie Internet à la recherche d'ordinateurs encore vulnérables à la vulnérabilité POODLE. J'ai donc écrit un script qui ouvre des connexions à de gros blocs d'adresses IP pour trouver des serveurs qui accepteront SSL version 3 - plus tard je vais utiliser cette liste pour rechercher spécifiquement 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 donnera, dans de nombreuses configurations d'Apache, un message 408 exactement comme vous l'avez décrit. En exécutant cette commande sur deux de mes propres serveurs, j'ai obtenu cette entrée dans le journal d'accès:

  - - [04/Nov/2015:08:09:33 -0500] "-" 408 - "-" "-"

Je tenais à le préciser car même dans une situation où l'OP n'utilisait aucune forme de répartition de charge, des erreurs 408 peuvent se produire 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 l'OP qu'une adresse IP locale était indiquée comme adresse IP distante, mais l'OP n'a pas spécifiquement mentionné l'utilisation d'un équilibreur de charge, je ne savais donc pas si l'OP avait simplement utilisé une IP non routable à des fins de démonstration, comme il l'a fait avec l'URL)

De toute façon, même si mon message est évidemment beaucoup trop tard dans la journée pour aider l'OP, j'espère qu'il pourra aider d'autres personnes qui arrivent ici à la recherche d'une solution à toutes ces maudites erreurs de délai d'attente.

Quelque chose se connecte au port puis ne transmet jamais de données. HTTP 408 est une erreur "timeout". Il y a une bonne explication ici: http://www.checkupdown.com/status/E408.html

Il existe diverses raisons pour un délai d'attente 408. Mais commençons d'abord par un postulat selon lequel tout va bien puis à un moment donné, ces 408 commencent à apparaître dans votre journal d'accès - c'est-à-dire 408 0 "-" "-".

Comme beaucoup le soulignent sur le net, un 408 représente une connexion établie mais aucune requête n'est envoyée dans le délai approprié, donc le serveur abandonne la connexion avec un 408. Un individu arrogant a en fait répondu à quelqu'un demandant de l'aide sur ce problème avec - "Quelle partie du délai d'attente ne comprenez-vous pas".

Je pense que c'est une réponse très novice et démontre un total manque de compréhension de la manière dont certaines méthodes de sécurité fonctionnent avec les logiciels de serveur web.

Revenons donc au début, pourquoi vois-je tous ces 408. Une chose que vous aurez en commun avec le reste d'entre nous qui gérons un serveur est la quantité énorme d'attaques que vous recevez chaque jour. Maintenant, que faites-vous à ce sujet? Eh bien: vous utilisez vos méthodes de sécurité choisies pour y faire face, voilà ce qui change.

Prenons un exemple très facile, Bloquer une adresse IP. Inclus dans un fichier iptabes (rules.v4) vous avez "-A ufw-user-input -s 37.58.64.228 -j DROP". Donc vient 37.58.64.228, le pare-feu reconnaît l'IP et abandonne la connexion. Dans de nombreuses configurations, vous ne saurez même pas qu'il a sonné à la porte.

Prenons maintenant un exemple plus avancé, Abandonner la connexion en fonction de certains critères. Inclus dans un fichier iptabes (rules.v4) vous avez "-A INPUT -p tcp -m tcp --dport 80 -m string --string "cgi" --algo bm --to 1000 -j DROP". C'est différent car dans cette règle iptable, nous disons de regarder les 1000 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 plus loin, abandonnez simplement la connexion.

Ici, la méthode de sécurité est bonne, mais en ce qui concerne vos journaux, elle est trompeuse. Le 408 0 "-" "-" généré est le meilleur qu'Apache puisse faire 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 des chaînes qui aboutit finalement à un 408 car votre règle satisfaisait les critères pour que la connexion soit abandonnée. Nos chers novices ne pourraient pas être plus à côté de la plaque 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é, ce n'est pas un 'Délai d'attente'; votre serveur a simplement abandonné la connexion après que la demande ait été faite en association avec votre règle de pare-feu. De nombreuses autres règles créeraient la même situation de 408. Ne prenez pas trop littéralement l'explication du code d'erreur du serveur 408 - 'Le délai d'attente de la requête est épuisé'.

Idéalement, il y aurait un autre code d'erreur généré par Apache, par exemple - '499' ce qui signifierait 'Le serveur a lu votre requête et a décidé qu'il ne pouvait tout simplement pas être dérangé de vous divertir - Débrouillez-vous HaHa'.

Avec les derniers logiciels de serveur web, vous pouvez pratiquement exclure les attaques par déni de service et la nouvelle génération de navigateurs incorporant des capacités prédictives ne causent pas ce problème comme certains l'ont suggéré.

En bref, le 408 est généré car le serveur n'a pas répondu à la demande, donc du point de vue du client, la connexion a expiré, alors qu'en réalité le serveur a lu la demande mais a abandonné la connexion pour d'autres raisons que l'attente d'une requête.

Nous avons eu ce problème même problème, et nous l'avons examiné pendant un certain temps. La meilleure solution que nous avons trouvé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 au paramètre idle timeout de votre ELB (qui est par défaut de 60 secondes).

• Assurez-vous que la valeur de la directive Timeout de votre apache est deux fois supérieure au paramètre idle timeout de votre ELB.
• Activez la fonction KeepAlive, assurez-vous que MaxKeepAliveRequests est très grand (soit 0 pour infini soit très élevé, comme 2000), et que KeepAliveTimeout est supérieur au idle timeout de votre ELB.

Nous avons constaté que le paramètre KeepAlive (et les paramètres associés) réduisait spécifiquement la quantité de codes de réponse 408 à 0 de manière efficace (nous en voyons quelques-uns, mais très peu).