Comment un administrateur réseau bloque-t-il le SSH inversé en entreprise?
Pare-feu donné
- entrant: tous sont bloqués
- sortant: autoriser le port 80, 443
Problème
- les collègues sont toujours en mesure de ssh vers le périphérique domestique par le port 80/443, et d'établir un tunnel ssh inverse d'une entreprise à l'autre, et plus loin de la maison à l'entreprise.
Question
- En plus de demander aux RH d'ajouter une règle de pénalité dans le manuel de politique de l'entreprise, est-il possible pour l'administrateur réseau de bloquer le ssh inverse de manière technique?
Le trafic SSH est différent de HTTP et HTTPS. Le trafic SSH est simplement tunnelé via le port 80 ou 443 (c'est-à-dire ssh -p80...) peut être détecté en regardant le premier paquet de réponse contenant déjà la version SSH et non la version HTTP ou TLS ServerHello. Mais vous pouvez également simplement imposer l'utilisation d'un proxy HTTP à l'intérieur du réseau, ce qui rend l'utilisation de SSH simple impossible.
Cela laisse la possibilité de tunneler SSH à l'intérieur d'un autre protocole, comme simplement créer un tunnel via le proxy en utilisant une demande CONNECT ou même masquer la connexion SSH dans une connexion TLS complète, en utilisant HTTP simple, en utilisant WebSockets, avec DNS ou similaire. C'est beaucoup plus difficile à détecter, bien que certaines analyses statistiques puissent aider car SSH montre un comportement différent du trafic HTTP normal. Mais une telle analyse peut être facilement confondue avec le trafic WebSockets courant.
À la fin, c'est une course et vous devriez vous demander pourquoi vous vous concentrez sur les tunnels SSH de toute façon. Ces tunnels ne sont qu'un outil pour transporter des données entre l'intérieur et l'extérieur. De tels transports de données peuvent également être effectués à l'aide de HTTP/HTTPS normaux, peuvent être effectués à l'aide de clés USB, etc. Et pour avoir une politique: il est plus sûr d'avoir une liste blanche sur ce qui est autorisé que d'avoir une liste noire sur ce qui n'est pas autorisé.
Un moyen de le rendre un peu plus difficile pourrait être d'avoir un proxy HTTP en place afin que les connexions ne puissent plus être établies directement sur 80/443 à moins que ce ne soit une connexion HTTP valide, mais même cela peut être contourné en utilisant quelque chose comme - Proxytunnel . Une autre façon de contourner cela serait d'exécuter simplement une console Web et d'y accéder normalement via 80/443.
Le rendre plus difficile pour eux ne les arrêtera probablement pas, mais au final, si vous avez dans votre politique que ce n'est pas autorisé et que vous surveillez le réseau, des avertissements peuvent être donnés aux personnes qui enfreignent cette règle.
Ici, ils ont bloqué SSH via le port 443 en bloquant la méthode CONNECT du proxy HTTP.
Une deuxième solution consiste à utiliser une fausse page de connexion. L'utilisation d'un proxy peut demander un mot de passe, ce qui est normalement demandé par le navigateur ou entré dans les champs d'authentification dans les applications qui peuvent utiliser un proxy. Mais vous pouvez contourner cela sur le serveur proxy en utilisant une fausse page de connexion qui demande un login/mot de passe.
Cette méthode est horrible, car seule l'application qui affiche cette page peut passer par le proxy. PuTTY par exemple, ne peut pas afficher cette page et ne peut donc pas s'authentifier auprès du proxy.
La première question devrait être de savoir pourquoi les utilisateurs/administrateurs utilisent des tunnels ssh inversés. J'ai travaillé dans une entreprise qui avait un VPN vraiment mal implémenté pour la gestion à distance, qui ne permettait qu'une connectivité à un serveur Citrix avec des outils médiocres, nous avons donc utilisé des tunnels distants SSH pour gérer correctement nos serveurs à distance. Les tunnels n'étaient autorisés qu'à partir d'un hôte bastion. L'hôte a été configuré avec l'authentification par mot de passe désactivée, la connexion root désactivée et l'authentification par clé activée. Le tunnel inverse a permis des connexions ssh en retour à la DMZ, puis à partir de l'hôte bastion, les utilisateurs ne pouvaient accéder qu'à une poignée d'autres hôtes bastion. Au lieu de descendre dans le terrier du lapin pour bloquer la tunnellisation ssh avec les mandataires d'interception MITM, les IDS, le blocage de l'accès aux adresses IP des administrateurs et les pare-feu DPI. Fournir une meilleure solution aux utilisateurs/administrateurs, répondant à leurs besoins, puis mettre en œuvre une politique RH et la faire appliquer.
Luajit via Suricata IDPS fournit des mécanismes avancés pour contrôler SSH ainsi que les tunnels SSL/TLS pour empêcher la Subversion du proxy, les shells inversés, et al.
Consultez ce guide assez complet, mais pas entièrement complet, pour trouver des certificats auto-signés utilisant Suricata et luajit - https://www.stamus-networks.com/2015/07/24/finding-self -signed-tls-certificats-suricata-et-luajit-scripting /
Demander comment sécuriser ssh ouvre une boîte de vers, voici ces vers.
Certains seront fous quand je dis cela, mais c'est quelque chose d'assez simple qui peut être accompli et "aurait dû être construit de cette façon" il y a longtemps.
Cela peut être fait, la plupart qui ne sont pas d'accord sont des voisins, et probablement responsables des vulnérabilités auxquelles nous sommes actuellement confrontés dans le monde ... Je m'éloigne du sujet.
La suggestion ci-dessus de forcer tout le trafic à travers des procurations qui nécessitent une visibilité sur le trafic avant la remise est un bon début et devrait être un concept déployé sur et aligné sur votre réseau et vos politiques et méthodologies de sécurité physique, parfois jusqu'à l'ordinateur portable du gardien de sécurité/mobile faisant le devoir de salle.
Contrôlez vos postes clients. Câblez-les de manière appropriée. Séparez du sans fil. Avoir une surveillance constante des statistiques sur les "terminaux stupides" du client. Usb désactivé. Fournir des concentrateurs d'alimentation pour les personnes qui ont besoin d'électricité. Demandez à toutes les exportations de passer par un processus d'approbation, qui comprend des procédures d'administration informatique.
Les logiciels sur ces postes de travail peuvent être une plate-forme simple avec une capacité minimale qui fournit une interface Web ou une application cliente qui les guidera en toute sécurité vers des ressources accessibles qui ne conviennent qu'à leur rôle.
Le sans fil doit être évité sauf sur un tronc complètement différent.
Des services tels que les "plates-formes de médias sociaux" devraient être "sur-contrôlés" car ils devraient être davantage de fausses alertes que de véritables alertes, afin que l'entreprise puisse bénéficier des informations entrant et sortant d'un réseau de médias sociaux "utilisées".
Tout cela provient d'un agent de soutien de bas niveau qui a trop de temps à consacrer. Cependant, si vous disposez d'un réseau avec ces méthodologies déployées, vous attesterez qu'il est important de connaître les allées et venues de vos employés, non pas une atteinte à la vie privée, mais un atout. Sur votre lieu de données sécurisées, la seule chose que quiconque devrait avoir à cacher est l'entreprise et ses données, y compris qui les gère et comment.
De nos jours, si vous avez une raison pour l'assurance de l'information, vous avez besoin de l'assurance de ces personnes assurant de fournir des informations sécurisées.
Plus besoin pour les employés de déplacer les données de l'entreprise aussi librement qu'aujourd'hui.
Tout cela peut être considérablement atténué au minimum, et encore moins appliqué avec des protocoles de sécurité physique ainsi que pour limiter les aspects photographie et vidéo des méthodes d'exfil de données en plus du stylo et du papier habituels, des "lecteurs USB tueurs", etc.