Bonsoir les moules,
suite à une discussion un peu trop technique pour moi avec un collègue, on se posait une question toute bête, à savoir si il était possible pour un admin réseau de détecter du remote port forwarding sur son réseau, et donc de le bloquer.
Je suppose qu'il doit être possible de bloquer les trames du protocole SSH (un outil comme wireshark les détecte comme telles il me semble), mais cette méthode ne ferait pas le distingo entre une session SSH normale et une session avec port forwarding (local ou remote) vu que c'est chiffré.
Un admin réseau qui souhaite laisser passer le SSH vers l'extérieur est il donc condamné à autoriser également le port forwarding ? (local ou remote, mais le remote me parait plus violent en terme de bafouement des règles de la sécurité réseau de l'entreprise)
Merci pour ma culture :)
# si c'est juste pour bloquer
Posté par briaeros007 . Évalué à 6.
si il veut bloquer le remote port forwarding de ssh ... il suffit de le désactiver dans le fichier de conf de ssh non ?
AllowTcpForwarding a no devrais faire l'affaire
(et ça peut être spécifié dans un "match" , donc sur certains comptes seulement)
Par contre au niveau réseau, détecter les ouvertures de flux à partir d'une machine qui ne devrais pas en ouvrir. A part ça, je vois pas trop.
[^] # Re: si c'est juste pour bloquer
Posté par cho7 (site web personnel) . Évalué à 2.
Le truc c'est que les 3/4 des gens faisant du tunneling SSH en entreprise à des fins douteuses (contournement de proxy) le font dans un environnement windows avec un putty par exemple.
Du coup on ne peut pas vraiment compter sur le fichier de conf SSH :)
[^] # Re: si c'est juste pour bloquer
Posté par Pierre Tramal (site web personnel) . Évalué à 1. Dernière modification le 23 janvier 2012 à 00:13.
Je pense que cette option se met au niveau de la configuration du serveur ssh.
Bien que dans la page man (man sshd_config), il est dit que cette option est contournable:
Note that disabling TCP forwarding does not improve
security unless users are also denied shell access, as they can
always install their own forwarders.
[^] # Re: si c'est juste pour bloquer
Posté par cho7 (site web personnel) . Évalué à 0.
Mais la personne qui tente de sortir d'un réseau ou d'y ouvrir une porte le fait via un serveur SSH distant qui lui appartient et sur lequel il a le contrôle du fichier sshd_config (et qu'il ne va pas s'interdire de le faire :o)
[^] # Re: si c'est juste pour bloquer
Posté par nono14 (site web personnel) . Évalué à 2.
à posteori, la personne se fera prendre par le système d'audit.
Système - Réseau - Sécurité Open Source
[^] # Re: si c'est juste pour bloquer
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Des fins présumées douteuses. Certains applications ne savent pas utiliser des proxys, certains proxys filtrent des sites de documentation, parfois il est si lent qu'on va plus vite avec un tunnel ssh, on peut vouloir tester une application réseau entre deux machines sans attendre 3 mois une réponse de la DSI...
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: si c'est juste pour bloquer
Posté par Nils Ratusznik (site web personnel, Mastodon) . Évalué à 1.
L'enfer est pavé de bonnes intentions : même si c'est pour travailler, que la DSI met 3 mois à répondre, contourner le proxy d'entreprise est généralement une violation de la charte informatique signée par l'employé lors de son premier jour ou lors de l'entrée en vigueur de celle-ci.
[^] # Re: si c'est juste pour bloquer
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
En général, il suffit d'envoyer un mail à son n+1 "la DSI incompétente ne me permet pas de bosser, je peux utiliser un contournement ou je livre le projet avec 3 mois de retard?".
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# passive traffic analysis
Posté par Krunch (site web personnel) . Évalué à 2.
En examinant les caractéristiques du trafic (taille des paquets, intervalle entre chaque paquets, symétrie de la connexion,...) indépendamment de son contenu on peut généralement déterminer beaucoup de choses. Donc si le tunnel est utilisé pour faire passer du HTTP par exemple, ça va se voir (si on est observateur).
En pratique, sshow utilise ce genre de technique pour récupérer des informations sur les mots de passes qui passent dans une connexion ssh : http://www.openwall.com/articles/SSH-Traffic-Analysis et fl0p (mentionné dans p0f/docs/existential-notes.txt) généralise la technique avec une base de signature qui peut s'appliquer à tout type de trafic (SSL, SSH,...) : http://lcamtuf.coredump.cx/
Du côté de la défense, le plus efficace pour brouiller les pistes semble être de multiplexer. Voir par exemple http://events.ccc.de/congress/2010/Fahrplan/events/4140.en.html ou http://events.ccc.de/congress/2006/Fahrplan/events/1478.en.html (les vidéos sont sur le wiki du Congress correspondant et probablement dans le google).
Donc pour répondre à la question :
Dans le cas général, je pense que oui. En pratique, il peut détecter certains types de trafic avec une fiabilité relativement grande et décider de sévir en conséquence (automatiquement bloquer la connexion, logguer les infractions suspectées et investiguer en examinant le poste client concerné, faire un rapport à la direction,...) ou non.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.