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, cela semble être une procédure contre-productive. Au mieux, cela oblige les programmeurs à facturer l'entreprise pour 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 à ce qui semble être une action perdante-perdante?
Je ne vois pas que quiconque a expliqué en détail le risque spécifique lié à la redirection de port SSH.
Si vous êtes à l'intérieur d'un pare-feu et que vous avez un accès SSH sortant à une machine sur Internet public, vous pouvez SSH vers ce système public et, dans le processus, créer un tunnel afin que les personnes sur Internet public puissent ssh vers un système à l'intérieur de votre réseau, complètement contourner le pare-feu.
Si fred est votre bureau et que barney est un serveur important dans votre entreprise et que wilma est public, il fonctionne (sur fred):
ssh -R *: 9000: barney: 22 wilma
et la connexion permettra à un attaquant ssh de porter le port 9000 sur 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 via une connexion initialement établie dans le sens sortant.
C'est ennuyeux, mais une politique de sécurité réseau tout à fait légitime.
S'ils bloquent un méli-mélo de ports, laissant passer des trucs et bloquant d'autres trucs au hasard (j'adore le triste conte de Paul Tomblin des gens qui bloquent SSH et autorisent Telnet), alors ils ont soit un cas Edge très étrange pour la façon dont ils sécuriser leur périmètre de réseau, ou leurs politiques de sécurité sont, du moins de l'extérieur, apparemment mal pensées. Vous ne pouvez pas donner un sens à des situations comme celle-ci, alors facturez-leur simplement le taux courant pour les personnes qui souffrent et continuez votre journée.
S'ils bloquent TOUS les ports à moins qu'il y ait une analyse de rentabilisation spécifique pour autoriser le trafic à travers ce port, auquel moment 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, facilitez-vous la lecture et l'écriture d'informations par d'autres processus à leur guise ou disposez-vous de quelques API soigneusement documentées que vous attendez des gens et que vous désinfectez soigneusement?
Gestion des risques - si vous pensez que le trafic vers ou depuis votre réseau vers Internet est un risque, alors vous cherchez à minimiser la quantité de façons dont le trafic peut atteindre Internet, à la fois en termes de nombre de routes et de nombre de méthodes. Vous pouvez ensuite surveiller et filtrer ces passerelles et ports "bénis" choisis pour essayer de vous assurer que le trafic qui les traverse est ce que vous attendez.
Il s'agit d'une politique de pare-feu "refus par défaut" et est généralement considérée comme une bonne idée, avec quelques mises en garde que j'aborderai. Cela signifie que tout est bloqué sauf s'il existe une raison spécifique pour le débloquer, et les avantages de la raison l'emportent sur les risques.
Edit: je dois clarifier, je ne parle pas seulement des risques d'un protocole autorisé et d'un autre bloqué, je parle des risques potentiels pour l'entreprise que les informations soient autorisées à entrer ou à sortir du réseau dans un environnement non contrôlé. façon.
Maintenant pour les mises en garde, et peut-être un plan pour libérer les choses:
Cela peut être ennuyeux lorsque vous êtes bloqué par 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 que c'est leur travail de dire "Non", au lieu de "Voici les risques, maintenant quels sont les avantages, laisse voir ce que nous pouvons faire".
Si vous parlez à celui qui gère la sécurité du réseau pour vos clients, il peut être disposé à configurer quelque chose pour vous. Si vous pouvez identifier quelques systèmes spécifiques à leur extrémité, vous devez avoir accès à, et/ou garantir que vous ne vous connecterez qu'à partir d'une adresse IP spécifique, ils peuvent être beaucoup plus heureux de créer une exception de pare-feu pour les connexions SSH pour ces conditions spécifiques qu'ils ne le font serait d'ouvrir simplement des connexions à l'ensemble d'Internet. Ou ils peuvent avoir une installation VPN que vous pouvez utiliser pour passer un tunnel à travers le pare-feu.
Une certaine grande entreprise de Rochester NY qui faisait beaucoup de films bloquait les ssh sortants quand j'y travaillais, mais permettait 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 loufoques sur la sécurité plutôt que d'admettre leurs erreurs.
Je peux comprendre le blocage des communications SSH entrantes si la société interdit les connexions externes. Mais, c'est la première fois que j'entends parler d'un bloc SSH sortant.
Ce qui est important à noter, c'est qu'un tel pare-feu ne limitera probablement que l'utilisateur SSH occasionnel. Si quelqu'un veut vraiment SSH à l'extérieur (qui sera généralement vers un serveur/machine auquel il a un accès important, en dehors 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 contourné facilement.
Il existe également plusieurs outils du domaine public qui vous permettront de quitter l'entreprise via HTTP (port 80 ou port HTTPS 443) et de fournir des procurations pour vous permettre de vous connecter au port 22 à l'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 comme IM et Bittorrent (par exemple). Ce // 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.
La seule façon de bloquer ces tunnels sortants est de détecter les communications SSH à la volée et de bloquer (dynamiquement) ces connexions TCP.
Il y a deux raisons principales de bloquer le port sortant 22, à mon avis.
Premièrement, comme les gens l'ont mentionné, la redirection de port SSH peut être utilisée comme proxy ou contourner d'autres ports et services pour éviter que la politique informatique n'indique qu'un tel trafic ne soit pas autorisé.
Deuxièmement, de nombreux logiciels malveillants/botnets 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.
C'est probablement un problème de réglementation/conformité. Votre employeur souhaite pouvoir lire/archiver toutes les communications. C'est très souvent une exigence dans des secteurs comme la banque.
Vos clients sont probablement en possession de données non triviales qu'ils souhaitent conserver. SSH sortant est une très mauvaise chose à ouvrir pour un réseau entier. Il est assez trivial de contourner les proxys, de divulguer des données sensibles et d'être généralement désagréable.
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 aux serveurs d'un fournisseur d'hébergement via ssh, c'est bien - mais cela doit également être documenté. En général, dans les endroits où j'ai travaillé, nous établissons des connexions VPN de site à site dédiées à des emplacements en dehors de notre réseau (essentiellement en étendant notre réseau interne) et évitons les protocoles clients comme SSH sur Internet.
Le plus souvent, il s'agit plus de bloquer toutes les connexions sortantes, sauf si cela est nécessaire, et jusqu'à ce que vous essayiez, 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 pour que votre station puisse établir des connexions SSH sortantes vers des hôtes spécifiques ou en général.
Parfois, il est à craindre que les gens utilisent la fonctionnalité pour utiliser SSH comme un moyen de configurer des proxys (via la redirection de port sur la liaison) pour contourner d'autres contrôles. Cela peut être un facteur très important dans certaines industries réglementées (c'est-à-dire les banques) où toutes les communications doivent être surveillées/enregistrées pour des raisons juridiques (décourager les délits d'initiés, détecter/bloquer le transfert de données d'entreprise ou personnelles, etc.) ou dans les entreprises où il y a est une grande crainte de fuites internes révélant, accidentellement ou non, des secrets commerciaux. Dans ces cas, l'utilisation de votre lien 3G (ou d'autres techniques telles que la tentative de tunneling SSH via HTTP) pour contourner les restrictions peut être une violation de votre contrat et donc une infraction de licenciement (ou, pire encore, une infraction légale), alors faites attention à obtenez votre accord 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 malencontreux parvient à se faire installer sur une machine exécutée par l'entreprise. Si aucune connexion SSH n'est possible sur le port 22, de nombreux hacks plus simples qui essaient d'utiliser des connexions SSH à force brute car l'un de leurs itinéraires de propagation seront bloqués. Dans ce cas, vous pourrez peut-être à nouveau demander qu'une exception soit ajoutée afin que votre machine puisse établir des connexions SSH, si ces connexions peuvent être justifiées par les personnes contrôlant le ou les pare-feu.
Parce que SSH peut être utilisé comme VPN. Il est crypté, donc les administrateurs réseau n'ont littéralement aucune idée de ce qui quitte leur réseau (vidage de la base de données client, etc.). Je viens de couvrir ce sujet dans ma colonne mensuelle "Tunnels secrets" . Le coût de certains réseaux Internet 3G est bien moindre que d'avoir à se soucier des protocoles cryptés acheminant vos données hors du réseau. De plus, si vous bloquez par défaut le port 22 sortant et inspectez le trafic, vous pouvez facilement trouver SSH sur des ports non standard et ainsi trouver des personnes enfreignant la politique de sécurité.
Les réponses évidentes ont toutes été énoncées. Il s'agit d'un protocole chiffré qui peut être utilisé pour contourner la politique via la création de tunnels (c'est un excellent moyen de contourner les filtres Web d'entreprise) ainsi que la menace posée par les canaux de communication non autorisés (proxy inverse).
C'est vrai, telnet devrait être détruit dans tout réseau moderne. Mais, je peux voir autoriser telnet hors du réseau tout en interdisant 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 aucun périphérique telnet sur mon réseau principal et qu'un utilisateur souhaite sortir telnet, que m'en importe. Je peux le voir et vérifier que ce n'est pas une menace.
Bien sûr, tout cela dépend de l'idée que la politique par défaut est de bloquer toutes les sorties et d'autoriser uniquement des protocoles spécifiques. Des points bonus si vous les procurez avant de toucher le bord.
Je connais quelques personnes qui abusent des capacités de SSH pour installer un proxy SOCKS via SSH, contournant ainsi certaines restrictions de 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
les amener à une table et les laisser expliquer la raison pour laquelle cela est bloqué. Bien sûr, vous devez avoir de bonnes raisons pour lesquelles vous avez besoin d'accéder à un port SSH externe pour développer un produit interne (être interne: pourquoi avez-vous besoin d'accéder à boxA.example.com lorsque vous travaillez pour une entreprise snakeoil.invalid)
Mais je n'ai pas encore vu une entreprise bloquant SSH sortant :)
De toute évidence, un bloc TCP/22 sortant est facile à contourner, sauf si les administrateurs réseau ont pris des efforts sérieux et sérieux pour bloquer le trafic SSH en particulier. De plus, les administrateurs d'actifs doivent être suffisamment compétents pour exécuter un inventaire des actifs suffisant pour intercepter les modems 3G et les adresses IP suspectes sur les 2e NIC. Nous avons le service ClearWire dans notre région, nous avons donc même WiMax comme option finale pour la sécurité de notre réseau.
Nous ne sommes pas une institution qui se préoccupe principalement des 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 l'audit. À ma connaissance, je ne pense pas qu'il existe un package de sécurité standard qui désactive la prise réseau d'un actif inventorié avec une connexion réseau externe quelconque. Cela pourrait venir.
En l'absence d'un tel package, le processus d'inventaire des actifs est l'un des meilleurs moyens de capturer une connexion réseau finale comme 3G ou WiMax.
Et enfin, le blocage aveugle de TCP/22 ne bloquera que le moindre wiley des utilisateurs finaux désireux de violer l'AUP pour leur réseau de travail.
J'ai vu 22 bloqués quand ils ont découvert que les gens dirigeaient le trafic http via 22. C'était un bouchon pour ceux d'entre nous qui en avaient besoin, mais l'organisation a tenu bon.
La plupart des grandes organisations bloqueront tout et autoriseront uniquement 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 à partir de postes de travail ou de serveurs, sauf en cas de besoin spécifique.
Rien ne vous empêche d'exécuter votre sshd distant sur le port 80. Les deux ssh et sshd ont 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. Il semble donc que vous ayez un problème de politique, pas un problème technique.
Comme d'autres l'ont souligné, les protocoles cryptés peuvent provoquer des brûlures d'estomac chez les personnes qui doivent s'inquiéter de problèmes de conformité divers.
Il ne s'agit pas de bloquer spécifiquement le port 22 parce que les administrateurs ont quelque chose contre SSH, mais plutôt d'ouvrir uniquement les ports dont ils savent qu'ils ont besoin. Si votre administrateur n'a pas été informé que SSH doit être ouvert, votre administrateur le bloquera, selon le même principe qui s'applique à la désactivation des services inutilisés sur un serveur.