Pourquoi bloquer le port 22 sortant?

Je suis programmeur et j'ai travaillé pour quelques clients dont les réseaux bloquent les connexions sortantes sur le port 22. Étant donné que les programmeurs ont souvent besoin d'utiliser le port 22 pour ssh, cette procédure semble contre-productive. Au mieux, cela oblige les programmeurs à facturer l'entreprise à Internet 3G. Au pire, cela signifie qu'ils ne peuvent pas faire leur travail efficacement.

Compte tenu des difficultés que cela crée, un administrateur système expérimenté pourrait-il expliquer les avantages souhaités pour ce qui semble être une action perdant-perdant?

Je ne vois pas que quiconque ait précisé le risque spécifique lié à la redirection de port SSH en détail.

Si vous êtes à l'intérieur d'un pare-feu et que vous avez un accès SSH sortant à une machine sur l'internet public, vous pouvez SSH sur ce système public et, ce faisant, créer un tunnel afin que les utilisateurs de l'internet public puissent se connecter à un système de votre réseau, complètement. contourner le pare-feu.

Si fred est votre bureau et barney est un serveur important dans votre entreprise et que wilma est public, il exécute (sur fred):

ssh -R *: 9000: barney: 22 wilma

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

Votre pare-feu ne la voit jamais comme une connexion entrante car les données sont transmises via une connexion établie à l'origine dans la direction sortante.

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

S'ils bloquent un méli-mélo de ports, laissent passer des choses et bloquent d'autres choses au hasard (j'adore le triste récit de Paul Tomblin sur les personnes qui bloquent SSH et autorisent Telnet), soit ils ont soit un cas très étrange sécurisent leur périmètre de réseau ou leurs politiques de sécurité sont, au moins de l’extérieur, apparemment mal pensées. Vous ne pouvez pas comprendre les situations de ce genre, il suffit donc de leur facturer le tarif en vigueur pour les personnes qui souffrent et qui continuent leur journée.

S'ils bloquent TOUS les ports sauf s'il existe une analyse de rentabilisation permettant d'autoriser le trafic via ce port, ils le gèrent avec précaution car ils sont compétents dans leur travail.

Lorsque vous essayez d'écrire une application sécurisée, facilitez-vous la lecture et l'écriture d'informations par d'autres processus à votre guise, ou disposez-vous de quelques API soigneusement documentées que vous attendez des utilisateurs à appeler et que vous désinfectez soigneusement?

Gestion des risques - si vous estimez que le trafic entrant ou sortant de votre réseau sur Internet présente un risque, vous devez minimiser le nombre de façons dont le trafic peut atteindre Internet, à la fois en termes de nombre de routes et de méthodes. Vous pouvez ensuite surveiller et filtrer ces passerelles et ports "bénis" choisis pour vous assurer que le trafic qui les traverse correspond à vos attentes.

Il s’agit d’une stratégie de pare-feu «Refuser par défaut» et est généralement considérée comme une bonne idée, avec quelques mises en garde auxquelles je reviendrai. Cela signifie que tout est bloqué sauf s'il existe une raison spécifique de le débloquer, et que les avantages de la raison l'emportent sur les risques.

Edit: Je devrais préciser, je ne parle pas seulement des risques qu’un protocole soit autorisé et un autre bloqué, je parle des risques potentiels pour l’activité informatique de laisser entrer ou sortir du réseau de manière non contrôlée. façon.

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

Cela peut être ennuyeux lorsque vous êtes bloqué (e) par quelque chose qui est la position dans laquelle vous vous trouvez avec certains de vos clients. Trop souvent, les responsables du pare-feu pensent que leur travail consiste à dire "Non" au lieu de "Voici les risques, maintenant quels sont les avantages, voyons ce que nous pouvons faire".

Si vous parlez à ceux qui gèrent la sécurité réseau de vos clients, ils seront peut-être disposés à vous organiser quelque chose. Si vous pouvez identifier quelques systèmes spécifiques à leur extrémité, vous devez y accéder et / ou vous garantir que vous ne vous connecterez qu'à partir d'une adresse IP spécifique. serait simplement d'ouvrir des connexions à l'ensemble de l'internet. Ils peuvent également disposer d’une installation VPN que vous pouvez utiliser pour passer le tunnel à travers le pare-feu.

Une certaine grande société de Rochester, à New York, qui fabriquait beaucoup de films bloquait les sorties sortantes lorsque je travaillais là-bas, mais permettait l'utilisation de telnet ! Quand j'ai demandé à ce sujet, 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 fantomatiques au sujet de la sécurité plutôt que d’admettre leurs erreurs.

Je peux comprendre le blocage de la communication SSH entrante si l'entreprise refuse les connexions externes. Mais, c’est la première fois que j’entends parler d’un bloc SSH sortant.

Il est important de noter que pare-feu ne limitera probablement que l'utilisateur SSH occasionnel. Si quelqu'un veut vraiment utiliser SSH à l'extérieur (ce qui est généralement destiné à un serveur / une machine auquel il a un accès important, à l'extérieur du réseau d'entreprise), il peut facilement exécuter le serveur SSH sur un port autre que 22 (par exemple, le port 80). Le bloc sera facilement contourné.

Il existe également plusieurs outils du domaine public qui vous permettent de quitter l'entreprise via HTTP (port 80 ou port HTTPS 443) et fournissent des mandataires pour vous permettre de vous connecter au port 22 extérieur.

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

Parfois, les gens utilisent des tunnels SSH pour contourner les pare-feu sortants de base pour des protocoles tels que IM et Bittorrent (par exemple). Ceci // pourrait // avoir déclenché une telle politique. Cependant, je pense toujours que la plupart de ces outils de tunnel pourraient fonctionner sur des ports autres que 22.

Le seul moyen de bloquer ces tunnels sortants consiste à détecter la communication SSH à la volée et à bloquer (dynamiquement) ces connexions TCP.

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

À mon avis, il existe deux raisons principales de bloquer le port sortant 22.

Tout d’abord, comme certains l’ont mentionné, le transfert de port SSH peut être utilisé comme proxy ou pour contourner d’autres ports et services afin d’éviter que la politique informatique stipule qu’un tel trafic n’est pas autorisé.

Deuxièmement, de nombreux programmes malveillants / réseaux de zombies utiliseront le port 22 car il est souvent considéré comme "sécurisé" et donc autorisé. Ils peuvent ensuite lancer des processus sur ce port et les ordinateurs infectés peuvent également lancer des attaques par force brute SSH.

Le plus souvent, il s'agit plutôt de bloquer toutes les connexions sortantes, sauf si cela est nécessaire. Jusqu'à ce que vous ayez essayé, personne n'avait demandé que le port 22 soit disponible pour les connexions sortantes (seulement 80, 433, etc.). Si tel est le cas, la solution peut être aussi simple que de contacter IS / IT et de leur dire pourquoi vous avez besoin d'une exception, afin que votre station puisse établir des connexions SSH sortantes avec des hôtes spécifiques ou en général.

Parfois, il est à craindre que les personnes utilisent l’utilitaire SSH comme moyen de configurer les mandataires (via la redirection de port sur la liaison) pour contourner les autres contrôles. Cela peut être un facteur très important dans certaines industries réglementées (telles que les banques) où toutes les communications doivent être surveillées / journalisées pour des raisons juridiques (décourager les délits d'initiés, détecter / bloquer le transfert de données personnelles ou d'entreprise, etc.) ou dans les entreprises où est une grande peur des fuites internes donnant, accidentellement ou non, des secrets commerciaux. Dans ces cas, l'utilisation de votre lien 3G (ou d'autres techniques telles que la tentative de tunnelisation de SSH via HTTP) pour contourner les restrictions peut constituer une violation de votre contrat et donc une infraction de licenciement (ou, probablement pire, une infraction légale), soyez donc prudent. obtenez votre action convenue avant de l'essayer.

Une autre raison pourrait être de réduire l'empreinte sortante (aux services internes accessibles aux hôtes au sein des pare-feu de l'entreprise et au monde en général) si quelque chose de fâcheux parvient à se faire installer sur un ordinateur de l'entreprise. Si aucune connexion SSH n'est possible sur le port 22, de nombreux piratages plus simples essaient d'utiliser des connexions SSH en force brute, car l'une de leurs routes de propagation sera bloquée. Dans ce cas, vous pouvez à nouveau simplement demander qu'une exception soit ajoutée afin que votre machine puisse établir des connexions SSH, si ces connexions peuvent être justifiées aux personnes ayant le contrôle du (des) pare-feu (s).

Vos clients sont probablement en possession de données non triviales qu'ils souhaiteraient conserver. SSH sortant est une très mauvaise chose à ouvrir pour un réseau entier. Il est assez facile de contourner les mandataires, de fuir des données sensibles et d’être généralement odieux.

OMI, tout ce qui passe par le périmètre réseau / Internet doit être compris et contrôlable. Si un groupe de développeurs a besoin d'accéder à des serveurs chez un fournisseur d'hébergement via ssh, c'est très bien, mais cela doit également être documenté. En général, dans les endroits où j'ai travaillé, nous établissons des connexions VPN dédiées entre sites (hors de notre réseau interne) et évitons les protocoles clients tels que SSH sur Internet.

Parce que SSH peut être utilisé en tant que VPN. Il est crypté afin que les administrateurs réseau n'aient littéralement aucune idée de ce qui sort de leur réseau (vidage de la base de données client, etc.). Je viens de couvrir ces choses dans ma colonne mensuelle "Tunnels secrets" . Le coût de certains accès Internet 3G est bien inférieur à celui de devoir se soucier des protocoles cryptés qui canalisent vos données hors du réseau. De plus, si vous bloquez par défaut le port sortant 22 et l'inspection du trafic, vous pouvez facilement trouver SSH sur des ports non standard et ainsi trouver des personnes violant la stratégie de sécurité.

Je connais quelques personnes qui abusent des capacités de SSH pour installer un proxy SOCKS via SSH, contournant ainsi certaines restrictions du site.

Ou même une simple redirection de port ( ssh -L ....), si le port est effectivement bloqué en raison de restrictions de site, j'irais à:

• l'administrateur local et
• votre chef de projet

amenez-les à une table et laissez-les préciser la raison pour laquelle cela est bloqué. Bien sûr, vous devez avoir de bonnes raisons pour lesquelles vous devez avoir accès à un port SSH externe pour développer un produit interne (en interne: pourquoi avez-vous besoin d'un accès à boxA.example.com lorsque vous travaillez pour une société snakeoil.invalid)

Mais je n'ai pas encore vu de société bloquant les SSH sortants :)

Les réponses évidentes ont toutes été énoncées. C'est un protocole crypté qui peut être utilisé pour contourner les politiques via la création de tunnels (c'est un excellent moyen de contourner les filtres Web de l'entreprise) ainsi que contre la menace posée par les canaux de communication non autorisés (proxy inverse).

C'est vrai, telnet devrait être détruit dans n'importe quel réseau moderne. Mais, je peux voir permettre à telnet de sortir du réseau tout en bannissant ssh. Telnet est moins capable que ssh et je peux toujours surveiller le flux, en temps réel, via mes renifleurs. Si je n'ai pas de périphérique telnet dans mon réseau principal et si un utilisateur souhaite sortir telnet, qu'est-ce qui m'importe? Je peux le voir et vérifier que ce n'est pas une menace.

Bien entendu, tout cela dépend de l'idée que la politique par défaut consiste à bloquer toutes les sorties et à n'autoriser que des protocoles spécifiques. Points bonus si vous les postez avant le bord du bord.

Il ne s’agit pas de bloquer spécifiquement le port 22 car les administrateurs ont quelque chose contre SSH, mais plutôt d’ouvrir uniquement les ports dont ils savent qu’ils ont besoin d’être ouverts. Si votre administrateur n'a pas été informé de la nécessité d'ouvrir SSH, il le bloquera, selon le même principe que pour la désactivation des services inutilisés sur un serveur.

Il est clair qu'un bloc TCP / 22 sortant est facile à contourner à moins que les administrateurs du réseau n'aient déployé des efforts sérieux pour bloquer le trafic SSH de manière spécifique . De plus, les administrateurs d’actifs doivent être suffisamment au courant pour effectuer un inventaire des actifs suffisant pour capturer les modems 3G, ainsi que les adresses IP suspectes sur la deuxième carte réseau. Nous avons un service ClearWire dans notre région, nous avons donc même le WiMax en tant qu'option finale pour la sécurité de notre réseau.

Nous ne sommes pas une institution principalement concernée par les fuites d'informations. Mais si nous l'étions, nous aurions besoin de combiner une politique de sécurité réseau draconienne avec une politique d'actifs draconienne, avec un audit. Autant que je sache, je ne pense pas qu'il existe un package de sécurité prêt à l'emploi qui désactive la prise réseau d'un actif stocké avec une connexion réseau externe quelconque. C'est peut-être à venir.

En l’absence d’un tel package, le processus d’inventaire des ressources est l’un des meilleurs moyens de capturer une connexion réseau de bout en bout telle que 3G ou WiMax.

Enfin, le blocage en aveugle de TCP / 22 ne bloquera que le moins motivant des utilisateurs finaux ayant l'intention de violer l'AUP pour leur réseau de travail.

J'ai vu 22 personnes bloquées lorsqu'elles ont découvert que des personnes dirigeaient le trafic http jusqu'à 22 heures. C'était un obstacle pour ceux d'entre nous qui en avaient besoin, mais l'organisation a bien résisté.

La plupart des grandes entreprises vont tout bloquer et n'autoriser que l'accès HTTP / HTTPS via un serveur proxy.

Je serais très surpris d'entendre parler de sociétés autorisant des connexions externes directes depuis des ordinateurs de bureau ou des serveurs, sauf en cas de besoin spécifique.

Rien ne vous empêche d’exécuter votre sshd distant sur le port 80. ssh et sshd ont tous deux une option -p pour définir le port.

Bien sûr, si vos administrateurs sont intelligents, ils doivent surveiller le trafic SSH, pas seulement le trafic du port 22. Donc, il semble que vous ayez un problème de politique, pas un problème de technologie.

Comme d'autres l'ont fait remarquer, les protocoles cryptés peuvent causer des brûlures d'estomac aux personnes qui doivent se préoccuper de divers problèmes de conformité.