Pourquoi bloquer le port 22 sortant?


61

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?


1
Le blocage des ports n’est que la moitié de la bataille. Pour terminer le cycle, vous devez vous assurer que les services que vous essayez de protéger ne fonctionnent pas sur des ports non standard.
Aharden

1
La question devrait vraiment être "Pourquoi bloquer le port 22 sortant?" car il existe un million de bonnes raisons pour lesquelles vous souhaitez exécuter votre service SSH sur un port non standard. Sortant ... pas tellement. Je mets un +1 sur la réponse de Robert Moir qui l'a très bien expliqué.
KPWINC

@KPWINC, a ajouté la clarification au titre. Merci!
runako

3
Pensez au port 22 comme une sorte de boîte à pandora. Les administrateurs réseau ne peuvent pas voir ce qui se passe dans le trafic, mais pire encore, ssh peut être utilisé en contournant la sécurité du réseau, ce qui compromet l’intégrité du réseau.
biosFF

1
@biosFF: Port 443.
Hello71

Réponses:


77

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.


1
Merci pour une réponse très perspicace. C’est l’une des rares réponses qui aborde les risques techniques (par opposition aux risques politiques) des ports de départ ouverts.
runako

6
+1 pour donner une bonne raison technique. (Cependant, cela ne peut être fait que par un interne malveillant, qui pourrait également utiliser d'autres ports que le port TCP 22 sur l'hôte distant. Avec lequel nous revenons à une politique de blocage total)
DerMike

7
Avec un protocole personnalisé et une programmation de proxy intelligente, cela pourrait se faire via HTTPS, bien que plus lentement. Tant que vous autorisez le trafic chiffré sortant, vous êtes vulnérable à ce type d '"attaque".
Michael Sondergaard

3
C'est une bonne réponse JamesF, mais ce n'est pas un problème de sécurité qui mérite d'être considéré, car cela suppose un scénario extrêmement rare et nécessite l'exploitation des serveurs / clients SSH. L'utilisateur malveillant devrait d'abord exploiter le serveur SSH (sur votre bureau) et trouver un moyen d'exploiter ensuite votre client SSH (sur l'hôte de votre entreprise). Étant donné que vous ne pouvez pas utiliser le port 22 pour accéder à l'hôte avec pare-feu d'entreprise (qui ne dispose que du port 22 sortant) et communiquer avec lui. Si votre norme de sécurité est aussi élevée, votre entreprise hôte ne devrait même pas utiliser Internet dans toutes les situations.
Dexter

1
Vous pouvez tunneler le trafic sur DNS (par exemple avec iodine) si HTTPS et SSH ne sont pas disponibles. Mais c'est très lent.
Mark K Cowan

38

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.


3
+1 pour Si tous les ports sont bloqués sauf s'il existe une analyse de rentabilisation spécifique pour autoriser le trafic via ce port; à ce stade, ils sont gérés avec soin, puis ils le font car ils sont compétents dans leur travail.
cop1152

-1 car ssh ne peut pas être surveillé par les responsables de la sécurité, mais Telnet peut l'être. Mon point est que, même s'il existe des politiques de sécurité réseau insensées, la caractériser comme "aléatoire" et "whackjob" sans une compréhension des besoins réels de l'entreprise est également très courte.
pcapademic

2
Eh bien, vous avez droit à votre opinion, bien sûr, Eric, et je changerai volontiers ces mots si vous estimez qu’ils sont péjoratifs, mais je suis assez confiant qu’une telle politique serait soit mal conçue, soit très inhabituelle.
Rob Moir

+1 pour "tous les ports"
Ian Boyd

18

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.


6
TELNET est le trou de sécurité. Il devrait être interdit (c'est juste pour que les gens prennent de meilleures décisions stupides à l'avenir).
Nik

3
Permettez-moi de préciser ici ce qu’est un trou de sécurité qui dépend de la sécurité de la surface. Si vous êtes un propriétaire de site Web et que vous essayez de vous connecter à votre serveur, TELNET est un trou. Si vous êtes un employé d’une société financière qui tente de se connecter à l’extérieur à votre serveur domestique (sur des lignes surveillées par votre employeur), SSH est le trou de sécurité pour vos employeurs!
Nik

1
Considérant combien il est facile d'usurper telnet dans les deux sens, je dirais que telnet est une faille de sécurité même pour l'entreprise qui le permet. Mais une entreprise qui le permet mais ne permet pas que ssh ne prend en aucun cas des décisions de sécurité intelligentes.
Paul Tomblin

3
Telnet est le cadeau qui ne cesse de donner. C'était correct il y a 20 ans, mais maintenant j'aimerais vraiment que cela cesse.
Rob Moir

2
Tout dépend de votre POV. Il y avait probablement des personnes qui avaient besoin d'accéder à un processus hérité via Telnet, dont nous sommes facilement vérifiables. OTOH, vous n'avez aucune idée de ce qui se passe avec SSH, les gens pourraient établir des tunnels vers des réseaux étrangers et faire toutes sortes de choses stupides. Telnet ne devrait pas être utilisé ces jours-ci, mais toute personne autorisant les SSH sortants doit chercher une nouvelle carrière.
duffbeer703

6

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.


3
Le port 443 est préférable car il est déjà supposé crypté. Les mandataires ne seront donc pas perturbés par des données étranges. Vous pouvez facilement configurer un serveur ssh en écoute sur le port 443 et à partir de là, vous pouvez aller n’importe où.
bandi

1
À un endroit où je travaillais, un de mes collègues a utilisé un programme qui tunnelise tout le trafic réseau sur un tunnel SSH via notre proxy Web vers le port 80 sur son ordinateur à la maison, et de là vers Internet. Il pouvait utiliser n'importe quel protocole qu'il souhaitait, mais il semblait que cela venait de chez lui plutôt que de l'entreprise. Heureusement, il savait à quel point les administrateurs du réseau étaient désemparés et ne risquait donc pas de se faire prendre.
Paul Tomblin

1
Bien sûr, si vous vous faites prendre après avoir traversé l'une de ces danses élaborées pour contourner le pare-feu, vous ne pouvez pas vraiment plaider l'innocence et l'ignorance. Un peu difficile de faire tout cela et de dire "désolé patron, ça" a juste fonctionné "alors je n'ai pas réalisé que je faisais quelque chose de mal."
Rob Moir

4

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.


Cela ne signifie-t-il pas qu'ils doivent également bloquer HTTPS?
runako

3
Non, ils permettent l'inspection SSL. Ce processus déchiffre HTTPS, puis recrypte les paquets sortants en injectant un certificat de confiance dans tous les postes de travail par stratégie de groupe. De cette façon, ils peuvent filtrer / analyser de la même manière qu'avec HTTP. Le secteur bancaire est l’un des environnements les plus draconiens pour verrouiller les réseaux.
Spoulson

4

À 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.


3

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).


Oui, il est fort probable que tous les services sortants non encore utilisés aient été bloqués (par défaut).
nik

Cependant, le blocage de TCP / 22 n'empêchera pas les communications sortantes sécurisées (qui peuvent être établies sur n'importe quel port aussi longtemps que l'utilisateur dispose d'un auditeur à l'extérieur, ce qui n'est pas difficile de nos jours).
nik

Si le réseau interne est utilisé pour la communication SSH, le blocage ne fonctionnera pas et si aucune communication SSH n'est requise, il n'y aura pas non plus de machines d'écoute SSH vulnérables à l'intérieur du réseau. Et la propagation typique des vers ne tente pas de forcer brutalement SSH (si vous vous inquiétez de cela, consultez en.wikipedia.org/wiki/SSHBlock ), il est plus probable que vous essayiez tcp / 445 avec vos machines Windows.
nik

3

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.


Merci d'avoir répondu. Comment gérez-vous les VPN dédiés vers des sites indépendants de votre volonté (par exemple, EC2, hôtes Web, etc.)? En règle générale, ces fournisseurs sont-ils disposés à effectuer cette configuration personnalisée à votre intention ou devez-vous généralement vous engager avec un minimum d’engagement important en termes d’activité pour les amener à le faire?
runako

2
Aussi, craignez-vous que vous obligiez les gens à utiliser des cartes 3G hors réseau pour faire leur travail? D'après mon expérience, les réseaux verrouillés conduisent inévitablement à de nombreuses cartes 3G et à d'autres contournements cachés, car les utilisateurs ne peuvent pas terminer leur travail dans le temps imparti s'ils doivent attendre que le service informatique en approuve l'utilisation, si quelqu'un sait même qui appeler pour obtenir une exception. (Un cas flagrant incluait un serveur de messagerie qui n'accepterait pas les pièces jointes entrantes provenant d'Internet. Mouais!) Je serais curieux de savoir comment vous gérez ce solde.
runako

1
Ajoutez dans le commentaire sur la redirection de port sur ssh, et je pense que ceci est la bonne réponse à la question. ssh peut être un bon protocole à autoriser via un serveur proxy. Les administrateurs peuvent surveiller ce qui se passe, bloquer la redirection de port et les utilisateurs peuvent l'utiliser pour des services de shell et de copie distants.
pcapademic

Nous sommes suffisamment grands pour que probablement 90% de nos services ne nécessitent aucune administration sortante. Généralement, lorsque nous le faisons, nous faisons d’un tunnel VPN dédié une exigence dans une RFP, ce qui tend à éliminer les fournisseurs qui ne le fournissent pas ou ne peuvent pas le fournir. À cause de cela, je pense que nous avons un nombre minimal de personnes qui utilisent des solutions de rechange 3G et similaires.
duffbeer703

En outre, vous ne pouvez pas laisser les responsables de la sécurité dicter l'accès. Vous laissez le support technique de l'application et les personnes travaillant en réseau trouver une solution acceptable, soumise à un examen de la sécurité. Élaborez cette solution tôt dans le processus et ne commencez pas le matin avec la production. Cela vous évite toutefois les retards liés au traitement DMV.
duffbeer703

2

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é.


Merci pour la perspicacité. On dirait que vous ne considéreriez pas la 3G comme un tunnel secret. Pourriez-vous expliquer pourquoi il est plus logique de laisser les gens totalement hors réseau lorsqu'ils communiquent avec Internet? Il semble que vous préfériez les périphériques non autorisés encore moins qu'un 22 ouvert pour le trafic sortant.
runako

1
"... vous pouvez facilement trouver SSH sur des ports non standard ..." Vraiment? Vous aimez la négociation SSL / TLS sur des ports autres que 443? Très curieux.
Dscoduc

Yup, vous pouvez détecter le trafic ssh, Google: snort / ssh / détection / contenu / règles, ignorons tout des autres IDS, mais si Snort peut le faire, il faudrait qu'il soit assez éclaté pour ne pas le faire aussi bien.
Kurt

1

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 :)


J'ai vu une entreprise qui bloque les SSH sortants. Ils ont également bloqué presque tout le reste et par exemple, les virus ont vérifié tous les transferts HTTP à l'aide d'un proxy. La société était un dépositaire central de valeurs.
Esko Luontola

Je travaille pour une entreprise comme celle-ci. Heureusement, SSH peut être tunnelé via https. Bien sûr, ils n'autorisent que https à porter le port 443 ... sslh à la rescousse!
Mikeage

proxytunnel FTW :)
serverhorror Le

1

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.


0

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.


0

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.


Vous pouvez personnaliser les rapports avec quelque chose comme SCCM pour obtenir ces informations. Partout où je travaille, l'utilisation d'un ordinateur portable personnel ou d'une carte de réseau étendu pour contourner la sécurité du réseau est passible de mesures disciplinaires.
duffbeer703

0

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é.


0

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.


0

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é.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.