Pourquoi bloquer le port 22 sortant ?

Je ne vois pas que quelqu'un ait expliqué en détail le risque spécifique lié au transfert de port SSH.

Si vous vous trouvez à l'intérieur d'un pare-feu et que vous disposez d'un accès SSH sortant vers une machine située sur l'Internet public, vous pouvez vous connecter en SSH à ce système public et, ce faisant, créer un tunnel permettant aux personnes situées sur l'Internet public de se connecter en SSH à un système situé à l'intérieur de votre réseau, en contournant complètement le pare-feu.

Si fred est votre bureau et que barney est un serveur important de votre entreprise et que wilma est public, en cours d'exécution (sur fred) :

ssh -R*:9000:barney:22 wilma

et se connecter permettra à un attaquant de se connecter au port 9000 de wilma et de parler au démon SSH de Barney.

Votre pare-feu ne le voit jamais comme une connexion entrante, car les données sont transmises par une connexion qui a été établie à l'origine dans le sens sortant.

C'est ennuyeux, mais c'est une politique de sécurité du réseau tout à fait légitime.

S'ils bloquent un mélange de ports, laissant passer certaines choses et bloquant d'autres au hasard (j'adore la triste histoire de Paul Tomblin sur les gens qui bloquent SSH et autorisent Telnet), alors soit ils ont un cas limite très étrange pour la façon dont ils sécurisent leur périmètre réseau, soit leurs politiques de sécurité sont, de l'extérieur du moins, apparemment mal pensées. On ne peut pas donner de sens à ce genre de situation, alors il suffit de leur faire payer le tarif en vigueur pour les personnes qui sont pénibles et de poursuivre sa journée.

S'ils bloquent tous les ports à moins qu'il n'y ait une raison commerciale spécifique d'autoriser le trafic par ce port, auquel cas il est soigneusement géré. alors ils le font parce qu'ils sont compétents dans leur travail.

Lorsque vous essayez d'écrire une application sécurisée, faites-vous en sorte que d'autres processus puissent lire et écrire des informations comme bon leur semble ou avez-vous quelques API soigneusement documentées que vous vous attendez à ce que les gens appellent et que vous aseptisez soigneusement ?

Gestion des risques - si vous estimez que le trafic en provenance ou à destination de votre réseau et à destination d'Internet constitue un risque, vous cherchez à minimiser le nombre de voies par lesquelles le trafic peut atteindre Internet, tant en termes de nombre de routes que de nombre de méthodes. Vous pouvez ensuite surveiller et filtrer ces passerelles et ports "bénis" choisis pour vous assurer que le trafic qui y transite correspond à vos attentes.

Il s'agit d'une politique de pare-feu de type "refus par défaut" qui est généralement considérée comme une bonne idée, avec quelques réserves que je vais évoquer. Cela signifie que tout est bloqué à moins qu'il n'y ait une raison spécifique de le débloquer et que les avantages de cette raison l'emportent sur les risques.

Edit : Je dois préciser que je ne parle pas seulement des risques liés à l'autorisation d'un protocole et au blocage d'un autre, mais aussi des risques potentiels pour l'entreprise si l'on permet à l'information d'entrer ou de sortir du réseau de manière incontrôlée.

Maintenant, les mises en garde, et éventuellement un plan pour libérer les choses :

Il peut être ennuyeux d'être bloqué dans quelque chose, ce qui est la position dans laquelle vous vous trouvez avec certains de vos clients. Trop souvent, les responsables du pare-feu pensent qu'il leur appartient de dire "Non", au lieu de dire "Voici les risques, maintenant quels sont les avantages, voyons ce que nous pouvons faire".

Si vous parlez à la personne qui gère la sécurité du réseau de vos clients, elle peut être disposée à mettre en place quelque chose pour vous. Si vous pouvez identifier quelques systèmes spécifiques auxquels vous devez accéder, et/ou garantir que vous ne vous connecterez qu'à partir d'une adresse IP spécifique, ils seront peut-être plus heureux de créer une exception au pare-feu pour les connexions SSH dans ces conditions spécifiques que d'ouvrir des connexions à l'ensemble de l'Internet. Il se peut également qu'ils disposent d'une installation VPN que vous pouvez utiliser pour traverser le pare-feu.

Une certaine grande entreprise de Rochester NY qui produisait beaucoup de films bloquait le ssh sortant quand j'y travaillais, mais autorisait telnet ! Quand j'ai posé la question, ils ont dit que ssh était une faille de sécurité.

En d'autres termes, les entreprises prennent parfois des décisions stupides, puis inventent des excuses bidons sur la sécurité plutôt que d'admettre leurs erreurs.

Je peux comprendre le blocage des communications SSH entrantes si l'entreprise interdit les connexions externes. Mais c'est la première fois que j'entends parler d'un blocage des communications SSH sortantes.

Ce qu'il est important de noter, c'est qu'un tel pare-feu ne limitera probablement que l'utilisateur SSH occasionnel. Si quelqu'un veut vraiment utiliser SSH à l'extérieur (généralement vers un serveur ou une machine auquel il a un accès important, en dehors du réseau de l'entreprise), il peut facilement exécuter le serveur SSH sur un port autre que 22 (disons le port 80). Le blocage sera facilement contourné.

Il existe également plusieurs outils du domaine public qui vous permettront de sortir de l'entreprise par HTTP (port 80 ou HTTPS port 443) et fourniront des proxys pour vous permettre de vous connecter au port 22 à l'extérieur.

Edit : Ok, attendez une seconde, j'ai une idée de pourquoi cela pourrait être une politique.

Parfois, les gens utilisent des tunnels SSH pour contourner les pare-feu sortants de base pour des protocoles comme la messagerie instantanée et Bittorrent (par exemple). Ceci //peut//être à l'origine d'une telle politique. Cependant, je continue à penser que la plupart de ces outils de tunnels pourraient fonctionner sur des ports autres que 22.

La seule façon de bloquer ces tunnels sortants est de détecter la communication SSH à la volée et de bloquer (dynamiquement) ces connexions TCP.

C'est probablement un problème de réglementation/conformité. Votre employeur veut pouvoir lire/archiver toutes les communications. C'est très souvent une exigence dans des secteurs tels que la banque.