Avantages de tuer des sessions après 5 minutes?
J'ai affaire à un serveur qui n'est pas le mien à configurer. Quelque chose quelque part entre moi et ce serveur tue toute connexion après 5 minutes si aucun trafic ne passe entre les deux machines. Cela inclut les connexions actives où une commande est en cours d'exécution sur le serveur; en particulier, j'ai démontré que cette déconnexion se produit à l'aide d'une connexion SSH (exécution d'une commande bash qui n'imprime aucune sortie pendant plus de 5 minutes) et d'une base de données SQL (exécution d'une commande SQL qui dure plus de 5 minutes). Il se déconnecte également si je vais lire quelque chose et que je n'envoie aucune commande pendant 5 minutes, bien sûr.
Pour le paramètre SSH, le groupe responsable du serveur a recommandé d'activer le côté client Keep Alive. Ils n'ont fourni aucune suggestion pour les connexions à la base de données.
Je suis cependant complètement confus. Quel est l'avantage de sécurité ici? Pour SSH, je peux contourner complètement leurs paramètres du côté client, et ils recommandent même de le faire. (Ce dernier signifie qu'il ne peut même pas y avoir d'argument de "sécurité par l'obscurité", car il ne sera pas obscur parce que chaque utilisateur devra le savoir. J'ai découvert par moi-même avant même de le recommander.) Pour les deux, cela dégrade manifestement la disponibilité. Je pourrais potentiellement voir que la déconnexion de sessions actives après quelques heures d'inactivité pourrait être bénéfique (bien que les menaces possibles de longues sessions ouvertes ne soient pas immédiatement claires pour moi.), Mais toutes les 5 minutes ? Cela signifie que je ne peux même pas lire un message DBA.SE pendant que je travaille sur mon SQL sans être déconnecté. Est-ce aussi ridicule que cela puisse paraître pour moi, ou y a-t-il quelque chose qui me manque?
Clarifications
Certains points ont été mentionnés dans les commentaires, je voudrais donc clarifier un peu.
- Je suis en mesure de reproduire systématiquement le délai d'expiration à 5 minutes. J'ai utilisé des commandes qui enregistrent un horodatage côté serveur toutes les quelques secondes, et après une déconnexion, le dernier horodatage enregistré était toujours exactement 5 minutes après le premier horodatage. Les déconnexions n'ont donc jamais été sporadiques.
- Peu de temps après avoir écrit ce billet, les administrateurs système/réseau ont répondu que c'était effectivement intentionnel. Je cite: "Plus de retombées du délai de 5 minutes fixé sur les F5 il y a quelques semaines?" Je ne sais pas ce qu'est un F5; certains googleurs suggèrent que c'est un commutateur très cher, ce qui correspond à quelqu'un qui essayait de trouver une solution de contournement pour mes connexions DB mentionnant plus tard les paramètres du commutateur.
(Je ne pense pas que ces informations invalident les réponses.)
Cela ressemble à un bon exemple d'un sécurité "cargo culte" . Un contrôle de sécurité a été mis en œuvre à l'aveuglette sans comprendre le contexte impliqué ni même le mettre en œuvre correctement.
De manière générale, en matière de sécurité, l'intérêt d'un délai d'inactivité est de réduire le risque de situations où une machine cliente est laissée sans surveillance et où un utilisateur malveillant arrive sur la machine et exécute des commandes non autorisées sur celle-ci. L'équilibre dans ces délais d'attente a tendance à être celui de l'utilisabilité (qui favorise les délais d'attente plus longs ou aucun) et de la sécurité (qui favorise les délais d'attente 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 l'utilisation de subsistances)
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 réglage par défaut. Qui sait?
Les administrateurs réseau ont souvent des préoccupations différentes de celles de tout le monde, ce qui peut souvent entrer en conflit avec les autres. Nous travaillons dans un monde cloisonné où l'image holistique n'est pas prise en compte.
Ne présumez 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 était une solution rapide pour un autre problème qu'ils rencontrent, et votre problème d'application était un retour de souffle.
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 une raison différente. Malheureusement, votre question n'offre que votre point de vue, nous ne pouvons 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 également que n BOFH exécute le système, ce qui est probablement plus votre avis sur le problème :) Mais cela est difficile à dire sans avoir plus d'informations sur le système réel.
Comme vous l'avez peut-être remarqué, cela n'a rien à voir avec la sécurité. Au lieu de cela, la pratique de tuer les connexions dormantes de longue durée TCP ont à voir avec les bogues - c'est une solution de contournement pour les logiciels bogués.
L'un des exemples les plus connus de logiciels quittant TCP sessions suspendues est Internet Explorer (au moins jusqu'à la version 7). IE avait l'habitude de ne pas terminer = TCP sessions correctement donc sur le PC/ordinateur portable/téléphone client, le socket est considéré comme fermé, le serveur voit toujours la connexion ouverte. Et IE n'est que l'un des les exemples les plus connus. Il existe de nombreux logiciels de buggy.
Alors, pourquoi un serveur devrait-il s'en soucier? Parce que chaque socket ouvert est également un descripteur de fichier ouvert. Si vous ne gérez pas cette situation, le serveur manque 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 délai d'expiration sur les sockets morts. Sur certains systèmes d'exploitation, vous pouvez configurer ce délai d'expiration.
Vous avez presque toujours un délai d'expiration 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 juste essayez de ne pas épuiser les ressources en raison de l'échec de la fermeture de la connexion du logiciel buggy 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 défaillances transitoires, un équipement réseau (normalement jamais réinitialisé sauf s'il est cassé) qui ne temporiserait jamais une connexion inactive se terminerait par une privation de ressources et 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 se bloque sous charge et, en tant que tel, a tendance à utiliser des délais d'attente agressifs . C'est la raison pour laquelle l'utilisation de keep alive TCP (si le pack keep alive emballé passe, il y a quelque chose à l'autre extrémité) combinée à de courts délais d'attente réseau.
Mais le vrai problème ici est que les développeurs d'applications connaissent peu les utilisations de réseau de bas niveau et que les administrateurs réseau ne se soucient pas beaucoup des applications de haut niveau. La vie est comme ça ...