Je suis cependant complètement confus. Quel est l'avantage de sécurité ici?

Rien. Le scénario le plus probable est que quelque chose entre les deux expire la connexion après 5 minutes pour économiser les ressources. Cela pourrait être un pare-feu, un accélérateur WAN, un accélérateur SSL, etc. Ou ce pourrait être juste un mauvais paramètre par défaut. Qui sait?

Les administrateurs réseau ont souvent des préoccupations différentes de celles des autres, qui peuvent souvent entrer en conflit avec les autres. Nous travaillons dans un monde en silo où l'image holistique n'est pas prise en compte.

Ne supposez pas qu'il y a une raison particulièrement bonne pour chaque paramètre, mais laissez de la place pour le potentiel que le délai de 5 minutes soit une solution rapide pour un autre problème qu'ils rencontrent, et votre problème d'application était un retour .

Cela ressemble à un bon exemple de "culte du fret" de sécurité. Un contrôle de sécurité a été implémenté à l'aveugle sans comprendre le contexte impliqué ni même l'implémenter correctement.

De manière générale en sécurité, le point d'un timeout d'inactivité permet de réduire le risque de situations où une machine client est laissée sans surveillance et un utilisateur malveillant accède à la machine et exécute des commandes non autorisées dessus. L'équilibre dans ces délais d'expiration a tendance à être celui de la convivialité (qui favorise plus ou pas de délai d'expiration) et de la sécurité (qui favorise des délais d'expiration plus courts).

Vous pouvez parfois repérer la culture du fret de sécurité avec exactement ce que vous avez mentionné, à savoir que les opérateurs du système vous aident en fait à contourner le contrôle nominal (dans votre cas en recommandant d'utiliser des keep-alives)

Je suis cependant complètement confus. Quel est l'avantage de sécurité ici?

Ce n'est peut-être pas une question de sécurité mais pour une raison différente. Malheureusement, votre question n'offre que votre point de vue, nous ne pouvons donc que spéculer sur la vraie raison.

Une explication pourrait être qu'il existe un simple filtre de paquets avec état où les états expirent après 120 secondes d'inactivité. Cela signifie que toutes les données transférées après cette inactivité seront bloquées car il n'y a plus d'état ouvert. La raison en est peut-être un appareil qui n'a que des ressources très limitées et ne peut donc pas garder trop d'états ouverts en même temps, par exemple un pare-feu qui a été conçu avec 10 utilisateurs à l'esprit mais qui est maintenant utilisé par 100 utilisateurs.

Bien sûr, il se peut aussi que un BOFH exécute le système, ce qui est probablement plus votre point de vue sur le problème :) Mais c'est difficile à dire sans avoir plus d'informations sur le système actuel .

Comme vous l'avez peut-être remarqué, cela n'a absolument rien à voir avec la sécurité. Au lieu de cela, la pratique consistant à supprimer les connexions TCP dormantes de longue durée est liée à des bogues - c'est une solution de contournement pour les logiciels bogués.

L'un des exemples les plus célèbres de logiciels laissant les sessions TCP en suspens est Internet Explorer ( au moins jusqu'à la version 7). IE avait l'habitude de ne pas terminer correctement les sessions TCP, de sorte que, sur le PC / ordinateur portable / téléphone client, la prise est considérée comme fermée, le serveur voit toujours la connexion comme ouverte. Et IE n'est que l'un des exemples les plus connus. Il existe de nombreux logiciels bogués.

Alors, pourquoi un serveur devrait-il s'en soucier? Parce que chaque socket ouvert est également un descripteur de fichier ouvert. Ne pas gérer cette situation entraîne le serveur à manquer de descripteur de fichier. En théorie, le serveur peut également manquer d'ID de socket, mais ce nombre est beaucoup, beaucoup plus élevé que le nombre de descripteurs de fichiers ouverts qu'un système d'exploitation peut gérer.

Pour cette raison, diverses implémentations de la pile TCP incluent un timeout sur les sockets morts. Sur certains systèmes d'exploitation, vous pouvez configurer ce délai.

Vous avez presque toujours un timeout sur une session TCP inactive implémentée dans les routeurs, les commutateurs et toutes ces machines réseau de bas niveau. Cela n'a pas grand-chose à voir avec la sécurité dans le sens de la protection contre une attaque délibérée, mais essayez simplement de ne pas épuiser les ressources en raison d'un logiciel bogué qui ne parvient pas à fermer la connexion ou d'autres erreurs matérielles dans le réseau externe empêchant le paquet de fermeture d'atteindre sa destination.

En raison de ces éventuelles pannes transcendantes, un équipement réseau (normalement jamais réinitialisé à moins d'être interrompu) qui n'expirerait jamais une connexion inactive se terminerait par une pénurie de ressources et se générerait lui-même un déni de service ...

Le pire, c'est qu'il s'agit souvent de systèmes à faibles ressources (faible coût) et pour cette raison, les administrateurs réseau s'efforcent de réduire le risque que leur partie tombe en panne sous la charge et a donc tendance à utiliser timeouts agressifs. C'est la raison pour laquelle on utilise la connexion TCP Keep Alive (si le keep alive emballé passe, il y a quelque chose à l'autre bout) combiné avec de courts délais d'expiration du réseau.

Mais le vrai problème ici est que les développeurs d'applications en savent peu les utilisations du réseau et que les administrateurs réseau ne se soucient pas beaucoup des applications de haut niveau. La vie est comme ça ...