J'ai partagé sur slack la clé privée du vpn

Salut tout le monde,

Grosse boulette de ma part qui met en péril mon réseau à la maison

J’ai partagé sur les serveurs publiques de slack dans le cadre d’une conversation privée avec un devops de ma boîte la configuration du vpn d’accès aux serveurs de la boîte, incluant la clé privée.

Il a dit qu’il ne pouvait pas avant demain en régénérer une car ça impliquait de redémarrer à distance le vpn, et il ne voulait pas prendre le risque qu’il crash.

Du coup sa solution c’était de couper mon accès temporairement. D’après lui ça éviterait à des tiers de scanner mon réseau local, de lire tous mes paquets IP etc.

Le problème c’est que j’ai toujours accès aux sites normalement accessibles uniquement via le vpn et je peux toujours lancer ce dernier. Ces 2 faits me laissent penser qu’en fait il n’a toujours pas coupé l’accès alors qu’il a sous-entendu qu’il l’avait fait.

Du coup j’ai peur qu’un tiers ayant accès aux serveurs slack ou bien mon collègue lui-même, ou encore quelqu’un d’autre, ne puisse hacker mon réseau de chez moi… Y a rien à faire n’est-ce pas ? Je suis obligé d’attendre jusqu’à demain matin qu’il régénère une nouvelle clé privée ?

PS : je précise qu’à l’origine ma demande concernait un accès à un site sous vpn qui ne fonctionnait pas, j’avais besoin de l’aide de ce devops pour savoir pourquoi je n’y avais pas accès, pour pouvoir faire un dev.

Merci !

Salut,

De ce que je comprends, ça a l’air d’être un problème interne à ton entreprise. Qu’est-ce qui fait que tu poses la question ici et pas à tes collègues ?

Bein c’est du réseau quoi, rendre publique une clé privée de vpn. Normalement mon collègue devait révoquer mon accès, et demain régénérer la clé mais l’accès semble tjrs opérationnel, du coup n’importe qui ayant pris connaissance de ma clé peut apparemment hacker mon réseau chez moi. Apparemment.

Du coup ça me stresse. Et le collègue qui est aussi un co patron ne répond plus vu qu’il est 18h quoi

Du coup sa solution c’était de couper mon accès temporairement. D’après lui ça éviterait à des tiers de scanner mon réseau local, de lire tous mes paquets IP etc.

Quoi ?

Dit comme ça, ça a l’air complètement fantaisiste. Soit il y a plus de détails de sa part et omis, soit tu as mal compris quelque chose, soit il raconte n’importe quoi.

J’ai partagé sur les serveurs publiques de slack dans le cadre d’une conversation privée avec un devops de ma boîte la configuration du vpn d’accès aux serveurs de la boîte, incluant la clé privée.
[…]
du coup n’importe qui ayant pris connaissance de ma clé peut apparemment hacker mon réseau chez moi. Apparemment.

Qui connaît la clef privée aujourd’hui ? Ton collègues DevOps (qui y avait déjà accès si c’est lui qui gère le VPN) et l’entité Slack (de façon abstraite). C’est tout.

Certes, ce n’est pas idéal d’avoir fait fuiter la clef, mais ça reste quand même largement gérable, surtout si une nouvelle clef sera générée dès demain matin. Le risque me semble maîtrisé, il n’y a pas lieu de s’inquiéter. Ton collègue est un professionnel et il sait sûrement ce qu’il fait.

Si si il m’a dit qu’on pouvait faire un scan de mon réseau vu qu’il y a le même sous-masque ip que je ne sais quoi, et donc chercher des failles, et aussi lire tous mes paquets etc. Il a tout expliqué sauf que j’y connais rien donc je capte pas.

Je suis déçu qu’il n’ait pas mis fin à mes accès ce soir comme il avait dit. Jcomprends pas pk il ne l’a pas fait

Maintenant je stresse qu’il ou que qlq de slack m’espionne voire espionne mes parents

Le VPN c’est ce qui permet à ta machine de rejoindre le réseau interne de ton boulot. Si tu as laisser fuiter tes identifiants, peut-être qu’il a la possibilité de voir en clair¹ le trafic que tu fais passer vers ce VPN.

Mais ça n’est pas l’inverse, le VPN n’est pas un pont des machines de ton boulot vers ton réseau interne chez toi, donc il n’y a pas de raison pour que quiconque y ait accès.

Il te suffit de ne pas être connecté au VPN, non ?

Par ailleurs, ton collègue avait déjà certainement accès à la clef privée du VPN avant l’incident, si c’est lui qui l’administre. L’incident sur Slack n’a donc absolument rien changé à ce niveau.

Même en divulguant la clef privée du VPN, ça ne suffit pas à déchiffrer les communications, soit dit en passant. La clef privée du VPN permet plutôt d’authentifier les certificats délivrés à chaque employé. Le risque ici est de pouvoir forger des certificats valides frauduleusement, et ainsi pouvoir avoir accès au VPN de l’entreprise.

Selon comment est configuré le VPN, il peut être possible d’avoir accès à ta machine (en mode bridge ou en mode routé avec l’option p2p si c’est OpenVPN). Que ce soit avec un accès au VPN légitime ou non, d’ailleurs.

Solution pour mitiger ce risque : ne pas être connecté au VPN, tout simplement.

Par la suite, quand tout sera rentré dans l’ordre, tu pourras aussi faire des règles de firewalling sur ta machine pour éviter des scan de ta machine à travers le VPN (que n’importe quel autre collègue peut faire, et a toujours pu faire indépendamment de l’incident Slack).

Ce VPN, imagine-le comme un switch de bureau partagé avec tes collègues. (s’il est en mode bridge).

Oui c’est bien ce que je pensais. Genre il me suffirait de déco le VPN. Mais jsp, dans ses explications il n’avait pas l’air de dire ça. Je pense que j’ai dû mal comprendre une partie.

Hmm en tout cas il a dit que même si c’est du HTTPS , l’accès se ferait sans pb.

Par la suite, quand tout sera rentré dans l’ordre, tu pourras aussi faire des règles de firewalling sur ta machine pour éviter des scan de ta machine à travers le VPN (que n’importe quel autre collègue peut faire, et a toujours pu faire indépendamment de l’incident Slack).

c’est facile à faire ?

Chaque système a sa façon de faire, mais en l’occurrence je ne pense pas que ce soit difficile car le besoin est simple. On veut simplement réguler l’accès à des ports ouverts sur ta machine et accessibles via l’interface tun0 ou tap0 (c’est le nom que porte habituellement une interface VPN). La règle du firewall dirait alors « Rejeter toute nouvelle connexion entrante sur tous les ports via l’interface tun0 (ou tap0) ».

L’exemple classique, qui arrive souvent à mes collègues, c’est leur serveur HTTP de dev qui écoute sur 0.0.0.0:80 et [::]:80 c’est à dire sur toutes les interfaces, y compris celle du VPN. Quand ils laissent leur serveur configuré ainsi, ou sans firewall, on peut donc se connecter à leur serveur Web local. (cela peut quand même s’avérer utile quand on collabore ensemble, parfois)

Quand tu utiliseras le VPN en conditions normales, tu peux scanner ta propre machine via l’interface du VPN pour savoir à quoi ça ressemble depuis l’extérieur. À partir de là, tu peux déjà voir si tu as des services ouverts et accessibles. Sur Linux, il y a l’outil nmap (à installer) qui permet de faire cela. (tu dois alors exécuter le nmap sur l’adresse IP assignée à ton interface tun0 ou tap0. La commande ip addr te permettra de voir cela, si tu as Linux).

Bien entendu, tu peux aussi techniquement scanner tes collègues si tu connais leur adresse IP de VPN. Si tu le fais, assure-toi d’avoir leur accord avant, car faire un scan sans autorisation n’est pas quelque chose d’anodin et cela pourrait te causer des ennuis

Mon collègue est en train de faire des modifs sur mon ordi depuis 45min. Mais du coup ça m’empêche de bosser. Je dois rattraper ce temps ce soir ? Ou vu que ce n’est pas de ma faute et que je ne suis pas du tout arrivé en retard au télétravail, ça compte comme du temps de travail ?

Bon allez, on va s’arrêter ici.

C’est considéré comme du temps de travail normal.

D’une manière générale, les règles du travail sur site s’appliquent au travail à distance : si ces heures supplémentaires sont effectuées à la demande de l’employeur, elles doivent être payées. Si elles relèvent de l’initiative du salarié, elles peuvent ne pas être payées. Renseigne-toi auprès de ton patron, selon les besoins du projet et ta volonté d’en prester ou non, ou ton règlement intérieur.

Mais nous ne sommes pas devins, ni là pour répondre à la moindre question lors d’un épisode de panique.