Re: [FRnOG] [TECH] detection VPN SSL
> Le 9 mars 2016 à 08:27, Pierre Colombier a écrit : > > Je suis d'accord avec ça. > > J'ajouterai que les methodes de contournement sont potentiellement des > nuisances bien pires que celles que l'on essaie de bloquer. > Il existe des methodes de tunelling sur DNS qui explosent inmanquablement le > cache du resolveur local. > Et là, à part des quotas, je n'ai pas franchement trouvé de solution > technique. > > Mon expérience en la matière c'est que le mieux est d'aller voir le gars qui > abuse pour une petite explication du genre > > "écoute, c'est dans l'intéret de tout le monde que les règles de filtrage > restent relativement simples et je n'ai pas envie de passer du temps à > bloquer tes tentatives de contournement de la sécurité. Par contre, il > faudrait quand voir à ne pas trop me prendre pour un con. Là, je passe > l'éponge, mais si tu n'arretes pas ça tout de suite, je vais être obligé de > faire un rapport à la direction." > > En l'occurence, je ne m'étais pas déplacé, et je n'ai même pas identifié le > bonhomme. > J'ai juste réduit son traffic internet à 1kbps. > Il n'a pas fallu 5 minutes pour qu'il vienne râler ;) Quel outils utilises tu pour ça ? Faut vraiment être couillonette pour Être en tort et venir râler... > > > > On 09/03/2016 07:19, Michel Py wrote: >>> David Ponzone a écrit : >>> Le plus simple c’est d’ajouter dans le règlement intérieur de la société >>> que les >>> connexions VPN sortantes personnelles sont interdites sous peine de >>> sanction grave. >> Rapport efficacité / prix imbattable, en effet. Ca va pas tout empêcher, >> mais c'est la première chose à faire. Parce que filtrer les geeks barbus de >> la liste du FRnOG qui contournent les filtrages de la boite sans aucun >> besoin, juste pour la difficulté, ç'est du travail. >> >> Michel. >> >> --- >> Liste de diffusion du FRnOG >> http://www.frnog.org/ > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] detection VPN SSL
Bonjour à tous, merci beaucoup de vos retours, j'ai mis beaucoup de temps à repondre mais la discussion était très interessante, je vais reflechir à comment tourner ça mais vous m'avez bien confirmer ce que je pensais : c'est tres dur/impossible à detecter à moins de mettre le prix et meme avec ça, on ne fera globalement que faire chié les utilsateus légitimes, les barbues ou les hackers qui aurait reussi à s'infiltré passerons simplement par un autre endroit. 2016-03-11 11:45 GMT+01:00 Eric Belhomme : > Le 10/03/2016 19:21, Michel Py a écrit : > > C'est pour çà que dans le fil de cryptolock, je disais à David que > > d'interdire les .zip dans le mail, c'est une arme à double tranchant. > > Dans certains environnements super restrictifs oui, avec des > > utilisateurs un peu sophistiqués non. > > Pas mieux : les barrières n'emmerdent que les utilisateurs légitimes ! > C'est comme les tourniquets à l'entrée du métro, ça n'emmerde *que* ceux > qui ont leur titre de transport en bonne et due forme... > > -- > Rico > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > -- Jocelyn Lagarenne 06 28 78 30 50 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] detection VPN SSL
Le 10/03/2016 19:21, Michel Py a écrit : > C'est pour çà que dans le fil de cryptolock, je disais à David que > d'interdire les .zip dans le mail, c'est une arme à double tranchant. > Dans certains environnements super restrictifs oui, avec des > utilisateurs un peu sophistiqués non. Pas mieux : les barrières n'emmerdent que les utilisateurs légitimes ! C'est comme les tourniquets à l'entrée du métro, ça n'emmerde *que* ceux qui ont leur titre de transport en bonne et due forme... -- Rico --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] detection VPN SSL
> Sylvain Vallerot a écrit : > Perso j'ai toujours trouvé essentiel d'avoir la capacité de consulter ma box > et de pouvoir > sortir un SSH vers mes serveurs depuis chez un employeur (ou maintenant, un > client). Pareil, et j'ai des outils qui sont pas forcément installés chez le client dont je me sers tout le temps. > C'est beaucoup mieux pour le "geek barbu" de ne pas avoir à commettre ce qui > pourrait être qualifié de faute grave, pour l'admin > de n'être pas en guerre incessante contre eux. Reste à convaincre le DSI > qu'un risque contrôlé c'est mieux qu'une guerre larvée. +1 Et pour l'admin de d'avoir le retour du geek barbu quand il trouve quelque chose, d’où le bâton ET la carotte. > D'un autre côté le geek barbu a de plus en plus souvent un accès 3G ou 4G qui > lui permettra > d'avoir les accès dont il a besoin sans passer par le réseau de l'entreprise. Justement, c'est ce que je mentionnais dans un billet plus tôt : quand le geek barbu commence à se servir de son mobile, çà va déteindre sur les collègues non-geek, et quand tu as l'employé non-geek qui commence à se servir de gmail au bureau et de copier des fichiers entre son mobile et son PC avec une clé USB OTG, ta belle sécurité du réseau tout d'un coup elle vaut plus un caramel mou. C'est pour çà que dans le fil de cryptolock, je disais à David que d'interdire les .zip dans le mail, c'est une arme à double tranchant. Dans certains environnements super restrictifs oui, avec des utilisateurs un peu sophistiqués non. En plus d'interdire les VPN dans le manuel de l'employé, il faut aussi interdire la copie de fichier en provenance de mobile et la connexion des mobiles sur le réseau. Pour charger son mobile, utiliser un chargeur qui se branche sur la prise de courant, absolument interdit de charger son mobile avec un câble USB qui se connecte sur le PC. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] detection VPN SSL
Le 08/03/2016 21:48, Tristan Mahé a écrit : ça m'étonne que personne n'ai mentionné les iodines ( http://code.kryo.se/iodine/README.html ) et autres vpn-ws dans les trucs à detecter si tu veux vraiment couper toutes les solutions VPN... ou encore https://en.wikipedia.org/wiki/ICMP_tunnel . Ou alors tout en même temps comme ça semble être implémenté dans softether(.org). Je ne connaissait pas softether mais ça à l'air intéressant: client et serveur Open Source et multi-plateformes, multi-protocoles (SSL/TLS, L2TP-IPSec, SSTP, DNS, ICMP, etc.), NAT traversal, firewalling, L2 virtual switch pour ceux qui veulent... Quelqu'un utilise ce soft ? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] detection VPN SSL
> Le 10 mars 2016 à 08:34, Sylvain Vallerot a écrit : > > > D'un autre côté le geek barbu a de plus en plus souvent un accès 3G > ou 4G qui lui permettra d'avoir les accès dont il a besoin sans passer > par le réseau de l'entreprise. > A! Merci, ça faisait quelques messages que je me demandais si j'étais revenu 10 ans en arriere :) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] detection VPN SSL
Bonjour à tous, On 09/03/2016 19:20, Michel Py wrote: > seulement regarder ses emails olé-olé sur son serveur à la maison. Pourquoi olé-olé ? Perso j'ai toujours trouvé essentiel d'avoir la capacité de consulter ma box et de pouvoir sortir un SSH vers mes serveurs depuis chez un employeur (ou maintenant, un client). AMHA ça devrait passer par une politique qui prend en compte ce genre de besoins (i.e. autoriser ceux qui en ont besoin à faire ce genre de choses, quittes à passer par un routeur dédié avec une access-list dédiée) et une convention qui rend les choses officielles pour tout le monde. C'est beaucoup mieux pour le "geek barbu" de ne pas avoir à commettre ce qui pourrait être qualifié de faute grave, pour l'admin de n'être pas en guerre incessante contre eux. Reste à convaincre le DSI qu'un risque contrôlé c'est mieux qu'une guerre larvée. D'un autre côté le geek barbu a de plus en plus souvent un accès 3G ou 4G qui lui permettra d'avoir les accès dont il a besoin sans passer par le réseau de l'entreprise. Bonne journée --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] detection VPN SSL
On Wed, Mar 9, 2016, at 19:20, Michel Py wrote: > > Radu-Adrian Feurdean a écrit : > > De maniere plus generale, impliquer le RH (pour la partie sanctions) est > > nettement plus efficace. > > Ceci étant dit, il ne faut pas voir que le coté "bâton". Des fois, la > carotte çà marche mieux. Je suis d'accord avec ca. L'approche n'est pas que c'est le RH qui regarde les logs et convoque, mais bien l'equipe securite/IT/whatever qui fait une qualification en amont, en utilisant le cerveau diponible. Mais il y a des cas (a ne pas negliger) ou la sanction s'impose. Rien que se faire rappeler a l'ordre peut calmer quelques-uns. --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] detection VPN SSL
> Pierre Colombier a écrit : > Il existe des methodes de tunelling sur DNS qui explosent inmanquablement le > cache du resolveur local. Oui, c'est ce dont Tristan parlait un peu plus tôt. > Radu-Adrian Feurdean a écrit : > De maniere plus generale, impliquer le RH (pour la partie sanctions) est > nettement plus efficace. Ceci étant dit, il ne faut pas voir que le coté "bâton". Des fois, la carotte çà marche mieux. > Dans une boite (IT interne), essayer de faire de l'ordre uniquement par de la > technique, ca finit toujours dans un jeu "chat et souris". Le jeu du chat et de la souris, il continue à se faire que tu le suives ou pas. C'est pour çà que des fois une carotte au geek qui essaie de traverser tes mesures sans but malicieux çà peut te faire gagner du temps pour rester à jour des dernières nouveautés. Le coup du VPN à travers DNS qui de bouffe le cache du serveur, c'est mieux de comprendre comment çà marche quand il n'y a pas de menace réelle que quand c'est un "vrai" hacker qui en veut à tes données pas seulement regarder ses emails olé-olé sur son serveur à la maison. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] detection VPN SSL
Le 09/03/2016 11:32, Louis a écrit : > Bonne idée. Il faut penser à définir ce qu'est un VPN. Si je fais du > tunneling ssh, est-ce que c'est du VPN? > Est-il vraiment nécessaire de répondre à ça ? -- Rico, evidemment que c'en est, la fonctionnalité a même été implémenté pour cela ! --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] detection VPN SSL
Bonne idée. Il faut penser à définir ce qu'est un VPN. Si je fais du tunneling ssh, est-ce que c'est du VPN? Le 9 mars 2016 à 07:04, David Ponzone a écrit : > Le plus simple c’est d’ajouter dans le règlement intérieur de la société > que les connexions VPN sortantes personnelles sont interdites sous peine de > sanction grave. > > > > Le 9 mars 2016 à 06:42, Michel Py a > écrit : > > Jocelyn Lagarenne a écrit : > particulierement ce genre de VPN SSL, les autres sont simple à filtrer). > > > Les autres ne sont pas simples à filtrer. Bon PPTP c'est facile à filtrer, > mais voir plus bas : > > Tristan Mahé a écrit : > ça m'étonne que personne n'ai mentionné les iodines ( > http://code.kryo.se/iodine/README.html ) et autres vpn-ws > > > Par exemple. J'ai essayé récemment, sur un réseau "complètement sécurisé", > çà a marché ! > > Jocelyn, filtrer les VPNs c'est une guerre dont on ne voit pas la fin, > tout comme le glaive contre le bouclier. Principe de l'action et de la > réaction : chaque fois que tu filtres quelque chose, le résultat est que > quelqu'un va trouver un mécanisme pour le contourner. > > Un VPN, c'est encapsuler les données à l'intérieur de quelque chose > d'autre. On peut plus faire de VPN transporté sur PPTP ? on fait du VPN > transporté sur SSL. On peut plus faire de VPN transporté sur SSL ? on fait > du VPN transporté sur DNS. Le monde ne s'arrête pas de tourner à chaque > fois qu'une solution de contournement est trouvée, la solution de > remplacement est déjà en cours. > > RFC 1149 pour les VPN ! > > Tout ça pour dire que le plus simple est peut-être le contrôle du parc > > > Ce n'est pas plus simple. Nice try, no cigar. > > Michel. > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > > > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] detection VPN SSL
On Wed, Mar 9, 2016, at 07:04, David Ponzone wrote: > Le plus simple c’est d’ajouter dans le règlement intérieur de la société > que les connexions VPN sortantes personnelles sont interdites sous peine > de sanction grave. +1 De maniere plus generale, impliquer le RH (pour la partie sanctions) est nettement plus efficace. Dans une boite (IT interne), essayer de faire de l'ordre uniquement par de la technique, ca finit toujours dans un jeu "chat et souris". --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] detection VPN SSL
Je suis d'accord avec ça. J'ajouterai que les methodes de contournement sont potentiellement des nuisances bien pires que celles que l'on essaie de bloquer. Il existe des methodes de tunelling sur DNS qui explosent inmanquablement le cache du resolveur local. Et là, à part des quotas, je n'ai pas franchement trouvé de solution technique. Mon expérience en la matière c'est que le mieux est d'aller voir le gars qui abuse pour une petite explication du genre "écoute, c'est dans l'intéret de tout le monde que les règles de filtrage restent relativement simples et je n'ai pas envie de passer du temps à bloquer tes tentatives de contournement de la sécurité. Par contre, il faudrait quand voir à ne pas trop me prendre pour un con. Là, je passe l'éponge, mais si tu n'arretes pas ça tout de suite, je vais être obligé de faire un rapport à la direction." En l'occurence, je ne m'étais pas déplacé, et je n'ai même pas identifié le bonhomme. J'ai juste réduit son traffic internet à 1kbps. Il n'a pas fallu 5 minutes pour qu'il vienne râler ;) On 09/03/2016 07:19, Michel Py wrote: David Ponzone a écrit : Le plus simple c’est d’ajouter dans le règlement intérieur de la société que les connexions VPN sortantes personnelles sont interdites sous peine de sanction grave. Rapport efficacité / prix imbattable, en effet. Ca va pas tout empêcher, mais c'est la première chose à faire. Parce que filtrer les geeks barbus de la liste du FRnOG qui contournent les filtrages de la boite sans aucun besoin, juste pour la difficulté, ç'est du travail. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] detection VPN SSL
> David Ponzone a écrit : > Le plus simple c’est d’ajouter dans le règlement intérieur de la société que > les > connexions VPN sortantes personnelles sont interdites sous peine de sanction > grave. Rapport efficacité / prix imbattable, en effet. Ca va pas tout empêcher, mais c'est la première chose à faire. Parce que filtrer les geeks barbus de la liste du FRnOG qui contournent les filtrages de la boite sans aucun besoin, juste pour la difficulté, ç'est du travail. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] detection VPN SSL
Le plus simple c’est d’ajouter dans le règlement intérieur de la société que les connexions VPN sortantes personnelles sont interdites sous peine de sanction grave. > Le 9 mars 2016 à 06:42, Michel Py a > écrit : > >> Jocelyn Lagarenne a écrit : >> particulierement ce genre de VPN SSL, les autres sont simple à filtrer). > > Les autres ne sont pas simples à filtrer. Bon PPTP c'est facile à filtrer, > mais voir plus bas : > >> Tristan Mahé a écrit : >> ça m'étonne que personne n'ai mentionné les iodines ( >> http://code.kryo.se/iodine/README.html ) et autres vpn-ws > > Par exemple. J'ai essayé récemment, sur un réseau "complètement sécurisé", çà > a marché ! > > Jocelyn, filtrer les VPNs c'est une guerre dont on ne voit pas la fin, tout > comme le glaive contre le bouclier. Principe de l'action et de la réaction : > chaque fois que tu filtres quelque chose, le résultat est que quelqu'un va > trouver un mécanisme pour le contourner. > > Un VPN, c'est encapsuler les données à l'intérieur de quelque chose d'autre. > On peut plus faire de VPN transporté sur PPTP ? on fait du VPN transporté sur > SSL. On peut plus faire de VPN transporté sur SSL ? on fait du VPN transporté > sur DNS. Le monde ne s'arrête pas de tourner à chaque fois qu'une solution de > contournement est trouvée, la solution de remplacement est déjà en cours. > > RFC 1149 pour les VPN ! > >> Tout ça pour dire que le plus simple est peut-être le contrôle du parc > > Ce n'est pas plus simple. Nice try, no cigar. > > Michel. > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] detection VPN SSL
> Jocelyn Lagarenne a écrit : > particulierement ce genre de VPN SSL, les autres sont simple à filtrer). Les autres ne sont pas simples à filtrer. Bon PPTP c'est facile à filtrer, mais voir plus bas : > Tristan Mahé a écrit : > ça m'étonne que personne n'ai mentionné les iodines ( > http://code.kryo.se/iodine/README.html ) et autres vpn-ws Par exemple. J'ai essayé récemment, sur un réseau "complètement sécurisé", çà a marché ! Jocelyn, filtrer les VPNs c'est une guerre dont on ne voit pas la fin, tout comme le glaive contre le bouclier. Principe de l'action et de la réaction : chaque fois que tu filtres quelque chose, le résultat est que quelqu'un va trouver un mécanisme pour le contourner. Un VPN, c'est encapsuler les données à l'intérieur de quelque chose d'autre. On peut plus faire de VPN transporté sur PPTP ? on fait du VPN transporté sur SSL. On peut plus faire de VPN transporté sur SSL ? on fait du VPN transporté sur DNS. Le monde ne s'arrête pas de tourner à chaque fois qu'une solution de contournement est trouvée, la solution de remplacement est déjà en cours. RFC 1149 pour les VPN ! > Tout ça pour dire que le plus simple est peut-être le contrôle du parc Ce n'est pas plus simple. Nice try, no cigar. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] detection VPN SSL
Hello, ça m'étonne que personne n'ai mentionné les iodines ( http://code.kryo.se/iodine/README.html ) et autres vpn-ws dans les trucs à detecter si tu veux vraiment couper toutes les solutions VPN... Le fait d'enforce un proxy sur tcp/443 en cassant les connections 'longues', tu va casser websocket avec, et n'empechera pas le reconnect auto ;) Tout ça pour dire que le plus simple est peut-être le contrôle du parc et/ou l'injection du CA dans les postes clients ;) My 2 cents... On 03/08/2016 03:44 AM, Erik LE VACON wrote: > Bonjour, > > Sans faire de uutbound SSL Decryption via un SSL Forward Proxy, tu risques un > jeu du chat et de la souris éternel. > Le filtrage par IP cible via présence d'un reverse selon un format peut > aider, mais le mec qui tape une instance AWS ou un VPS chez un gros hébergeur > de contenu "standard" te ferme la porte des blocs IP sortants sans risquer de > bloquer du trafic légitime. > Si ton client a des moyens, seul l'interco en coupure d'un boitier de > déchiffrement "on the fly" via présentation d'un certificat bidon "on > behalf" du serveur cible, présente une efficacité supérieure vis-à-vis d'un > filtrage par ip/domaine cible, regex sur fqdn, etc... > Le processus est le suivant: le boitier intercepte les requêtes SSL/TLS > sortantes; et génère un certif à la volée du site cible. En général, même la > date de validité est "fakée" pour reprendre celle du site cible. > Concrètement, l'autorité de délivrance du fake-certif est le boitier > lui-même, ce qui génère un warning côté utilisateur si l'AC du boitier n'est > pas ajoutée aux AC "clean" du browser client (lourd à mettre en oeuvre sur > les grosses infras composites) > Autant dire que le petit malin aura un warning à la connexion s'il n'est pas > en mode "ignore cert warnings/self-signed certifs" sur son client VPN, donc > soit ca le calme, soit il va chercher une alternative. > Plusieurs constructeurs proposent de tels boitiers (PaloAlto par ex) avec des > résultats inégaux selon les contextes. > Bon courage (c'est le genre de défis où on sait quand ca commence .... ;) > ) > > My two... > > - Mail original - > De: "Jocelyn Lagarenne" > À: "Bruno LEAL DE SOUSA" > Cc: "Jérôme MARTINIERE" , > frnog-t...@frnog.org > Envoyé: Mardi 8 Mars 2016 11:56:24 > Objet: Re: [FRnOG] [TECH] detection VPN SSL > > Merci de vos retours. > > 2016-03-08 11:40 GMT+01:00 Bruno LEAL DE SOUSA : > >> Hello, >> >> Le proxy est interne ou externe ? >> Ils doivent obligatoirement passer par le proxy ? >> >> J'ai connu un cas où le proxy était externe et pour protéger des VPN, la >> règle était : >> >>- On bloque tous les connexions chiffrées https, ssl-smpt, pptp, etc... >>- On autorise la sortie https uniquement vers le proxy >> >> Ainsi toutes les connexions vpn étaint bloquées. >> >> les proxies sont internes, tout passe par eux. mais je ne comprend pas en > quoi cela va bloquer les VPN SSL. En effet on peut bloquer les VPN du type > PPTP, IPsec, ssh etc, mais concernant les vpn ssl utilisant la connexion du > navigateur, il me semble que cela ne change rien. Je me trompe peut etre. > Je vais faire des tests avec un serveur opensource : adito voir ce que ça > me genere comme traffic. > > > >> A+ >> >> Le 8 mars 2016 à 11:19, Jérôme MARTINIERE < >> j.martini...@groupe-alliance.com> a écrit : >> >>> Bonjour, >>> >>> Quel est le but final du filtrage ? >>> >> limiter les fuites d'information, et mieux contrôler notre réseaux. > L'entreprise possède plusieurs 100aine d'utilisateurs dont beaucoup > d'informaticiens, et cela devient de plus en plus dur de "maîtriser" le > réseau. > > >>> Sans casser le chiffrage par un proxy, il est possible de filtrer par >>> FQDN ou classes d’IP, notamment pour exclure les tunnels vers des IP de FAI >>> « grand public » par exemple ou vers les fournisseurs de proxy web. >>> >>> h, je vais voir ce qu'il est possible de faire avec ça, je n'y avais > pas spécialement pensé. est ce que c'est réellement réalisable ? j'avais > penser en effet à un whitelistage, mais je me suis dit que ça deviendrait > ingerable tres vite ... mais peut etre au niveau classes d'IP, cela fera > deja un filtre... > > > >> Cordialement, >>> Jérôme MARTINIERE >>> >>> De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part >
Re: [FRnOG] [TECH] detection VPN SSL
merci de vos retours. Oui en effet j'ai vu ce genre de boitier et les documents de l'ANSSI dessus : http://www.ssi.gouv.fr/uploads/IMG/pdf/NP_TLS_NoteTech.pdf personnellement je n'aime pas trop ce genre de choses, mais on devra surement y venir un jour ou l'autre au niveau des entreprises. est ce que quelqu'un a déjà utilisé des solutions comme adito (aka openvpn ALS) : https://sourceforge.net/projects/openvpn-als ? je n'ai pas encore pu testé, mais je voudrais confirmer ce que je pense : le traffic vpn est totalement encapsulé dans du https donc totalement "indetectable" d'un point de vu proxy/firewall/IDS si ce n'est en cassant le https ou en gérant des catégorisations sur le proxy ou via les catégories d'IP. si vous avez des exemples dans vos boites comment vous gérez la gestion des VPNs je suis très interessé aussi (au sens autorisé/interdit si interdit, est ce que vous le controlé et si oui: comment, particulierement ce genre de VPN SSL, les autres sont simple à filtrer). merci encore de vos differents retours. 2016-03-08 12:44 GMT+01:00 Erik LE VACON : > Bonjour, > > Sans faire de uutbound SSL Decryption via un SSL Forward Proxy, tu risques > un jeu du chat et de la souris éternel. > Le filtrage par IP cible via présence d'un reverse selon un format peut > aider, mais le mec qui tape une instance AWS ou un VPS chez un gros > hébergeur de contenu "standard" te ferme la porte des blocs IP sortants > sans risquer de bloquer du trafic légitime. > Si ton client a des moyens, seul l'interco en coupure d'un boitier de > déchiffrement "on the fly" via présentation d'un certificat bidon "on > behalf" du serveur cible, présente une efficacité supérieure vis-à-vis d'un > filtrage par ip/domaine cible, regex sur fqdn, etc... > Le processus est le suivant: le boitier intercepte les requêtes SSL/TLS > sortantes; et génère un certif à la volée du site cible. En général, même > la date de validité est "fakée" pour reprendre celle du site cible. > Concrètement, l'autorité de délivrance du fake-certif est le boitier > lui-même, ce qui génère un warning côté utilisateur si l'AC du boitier > n'est pas ajoutée aux AC "clean" du browser client (lourd à mettre en > oeuvre sur les grosses infras composites) > Autant dire que le petit malin aura un warning à la connexion s'il n'est > pas en mode "ignore cert warnings/self-signed certifs" sur son client VPN, > donc soit ca le calme, soit il va chercher une alternative. > Plusieurs constructeurs proposent de tels boitiers (PaloAlto par ex) avec > des résultats inégaux selon les contextes. > Bon courage (c'est le genre de défis où on sait quand ca commence .... > ;) ) > > My two... > > - Mail original - > De: "Jocelyn Lagarenne" > À: "Bruno LEAL DE SOUSA" > Cc: "Jérôme MARTINIERE" , > frnog-t...@frnog.org > Envoyé: Mardi 8 Mars 2016 11:56:24 > Objet: Re: [FRnOG] [TECH] detection VPN SSL > > Merci de vos retours. > > 2016-03-08 11:40 GMT+01:00 Bruno LEAL DE SOUSA : > > > Hello, > > > > Le proxy est interne ou externe ? > > Ils doivent obligatoirement passer par le proxy ? > > > > J'ai connu un cas où le proxy était externe et pour protéger des VPN, la > > règle était : > > > >- On bloque tous les connexions chiffrées https, ssl-smpt, pptp, > etc... > >- On autorise la sortie https uniquement vers le proxy > > > > Ainsi toutes les connexions vpn étaint bloquées. > > > > les proxies sont internes, tout passe par eux. mais je ne comprend pas en > quoi cela va bloquer les VPN SSL. En effet on peut bloquer les VPN du type > PPTP, IPsec, ssh etc, mais concernant les vpn ssl utilisant la connexion du > navigateur, il me semble que cela ne change rien. Je me trompe peut etre. > Je vais faire des tests avec un serveur opensource : adito voir ce que ça > me genere comme traffic. > > > > > A+ > > > > Le 8 mars 2016 à 11:19, Jérôme MARTINIERE < > > j.martini...@groupe-alliance.com> a écrit : > > > >> Bonjour, > >> > >> Quel est le but final du filtrage ? > >> > > limiter les fuites d'information, et mieux contrôler notre réseaux. > L'entreprise possède plusieurs 100aine d'utilisateurs dont beaucoup > d'informaticiens, et cela devient de plus en plus dur de "maîtriser" le > réseau. > > > > > >> Sans casser le chiffrage par un proxy, il est possible de filtrer par > >> FQDN ou classes d’IP, notamment pour exclure les tunnels vers des IP de > FAI > >> « grand public »
Re: [FRnOG] [TECH] detection VPN SSL
Bonjour, Sans faire de uutbound SSL Decryption via un SSL Forward Proxy, tu risques un jeu du chat et de la souris éternel. Le filtrage par IP cible via présence d'un reverse selon un format peut aider, mais le mec qui tape une instance AWS ou un VPS chez un gros hébergeur de contenu "standard" te ferme la porte des blocs IP sortants sans risquer de bloquer du trafic légitime. Si ton client a des moyens, seul l'interco en coupure d'un boitier de déchiffrement "on the fly" via présentation d'un certificat bidon "on behalf" du serveur cible, présente une efficacité supérieure vis-à-vis d'un filtrage par ip/domaine cible, regex sur fqdn, etc... Le processus est le suivant: le boitier intercepte les requêtes SSL/TLS sortantes; et génère un certif à la volée du site cible. En général, même la date de validité est "fakée" pour reprendre celle du site cible. Concrètement, l'autorité de délivrance du fake-certif est le boitier lui-même, ce qui génère un warning côté utilisateur si l'AC du boitier n'est pas ajoutée aux AC "clean" du browser client (lourd à mettre en oeuvre sur les grosses infras composites) Autant dire que le petit malin aura un warning à la connexion s'il n'est pas en mode "ignore cert warnings/self-signed certifs" sur son client VPN, donc soit ca le calme, soit il va chercher une alternative. Plusieurs constructeurs proposent de tels boitiers (PaloAlto par ex) avec des résultats inégaux selon les contextes. Bon courage (c'est le genre de défis où on sait quand ca commence ;) ) My two... - Mail original - De: "Jocelyn Lagarenne" À: "Bruno LEAL DE SOUSA" Cc: "Jérôme MARTINIERE" , frnog-t...@frnog.org Envoyé: Mardi 8 Mars 2016 11:56:24 Objet: Re: [FRnOG] [TECH] detection VPN SSL Merci de vos retours. 2016-03-08 11:40 GMT+01:00 Bruno LEAL DE SOUSA : > Hello, > > Le proxy est interne ou externe ? > Ils doivent obligatoirement passer par le proxy ? > > J'ai connu un cas où le proxy était externe et pour protéger des VPN, la > règle était : > >- On bloque tous les connexions chiffrées https, ssl-smpt, pptp, etc... >- On autorise la sortie https uniquement vers le proxy > > Ainsi toutes les connexions vpn étaint bloquées. > > les proxies sont internes, tout passe par eux. mais je ne comprend pas en quoi cela va bloquer les VPN SSL. En effet on peut bloquer les VPN du type PPTP, IPsec, ssh etc, mais concernant les vpn ssl utilisant la connexion du navigateur, il me semble que cela ne change rien. Je me trompe peut etre. Je vais faire des tests avec un serveur opensource : adito voir ce que ça me genere comme traffic. > A+ > > Le 8 mars 2016 à 11:19, Jérôme MARTINIERE < > j.martini...@groupe-alliance.com> a écrit : > >> Bonjour, >> >> Quel est le but final du filtrage ? >> > limiter les fuites d'information, et mieux contrôler notre réseaux. L'entreprise possède plusieurs 100aine d'utilisateurs dont beaucoup d'informaticiens, et cela devient de plus en plus dur de "maîtriser" le réseau. > >> Sans casser le chiffrage par un proxy, il est possible de filtrer par >> FQDN ou classes d’IP, notamment pour exclure les tunnels vers des IP de FAI >> « grand public » par exemple ou vers les fournisseurs de proxy web. >> >> h, je vais voir ce qu'il est possible de faire avec ça, je n'y avais pas spécialement pensé. est ce que c'est réellement réalisable ? j'avais penser en effet à un whitelistage, mais je me suis dit que ça deviendrait ingerable tres vite ... mais peut etre au niveau classes d'IP, cela fera deja un filtre... > Cordialement, >> >> Jérôme MARTINIERE >> >> De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part >> de Jocelyn Lagarenne >> Envoyé : mardi 8 mars 2016 10:45 >> À : frnog-t...@frnog.org >> Objet : [FRnOG] [TECH] detection VPN SSL >> >> Bonjour à tous, >> >> je me retrouve face à un dilemme. On me demande de proposer une solution >> pour détecter/bloquer les VPN SSL non autorisés mais autant que je sache le >> traffic au travers d'un proxy est identique à un traffic https. il est donc >> impossible de le detecter non ? ou est ce que je fais fausse route ? >> Il est techniquement envisageable de casser le https sur les proxys mais >> ce n'est pas une recommandation que j'aime. >> la seul solution que je vois est de détecter les connexions SSL "longue" >> et de vérifier ce qu'elles sont (eliminer les faux positives comme par >> exemple gtalk), mais je ne suis meme pas sure que des logs proxy puissent >> me donner cette information. &
Re: [FRnOG] [TECH] detection VPN SSL
Le 2016-03-08 09:44, Jocelyn Lagarenne a écrit : > Bonjour à tous, > > je me retrouve face à un dilemme. On me demande de proposer une solution > pour détecter/bloquer les VPN SSL non autorisés mais autant que je sache le > traffic au travers d'un proxy est identique à un traffic https. il est donc > impossible de le detecter non ? ou est ce que je fais fausse route ? > Il est techniquement envisageable de casser le https sur les proxys mais ce > n'est pas une recommandation que j'aime. > la seul solution que je vois est de détecter les connexions SSL "longue" et > de vérifier ce qu'elles sont (eliminer les faux positives comme par exemple > gtalk), mais je ne suis meme pas sure que des logs proxy puissent me donner > cette information. > > Auriez vous des idées/suggestions ? avez vous déjà eu ce genre de cas dans > vos entreprises ? > > d'avance merci de vos retours > > Cordialement, Les VPN ont un port par défaut qui diffère du port HTTPS, mais effectivement ils utilisent souvent le TCP/443 pour traverser les proxys ou pour éviter les QOS non-neutres.Effectivement, il est inconcevable de casser du HTTPS ou de faire du man in the middle, pour autant il y a des solutions. La première c'est la gestion de parc en interdisant les logiciels de VPN, mais cela implique d'avoir la main sur tout le parc et sur tous les équipements qui se connectent. La seconde c'est de travailles avec un système de blacklist. Elle consiste à relever les IP jointes en SSL sur le port 443 et à faire 2 vérifications simples. D'abord un simple reverse de l'IP donne généralement de bonnes infos sur l'usage de cette IP. Ensuite avec un telnet sur le port 443 de l'IP en question, on peut voir si c'est un serveur HTTP au bout ou autre chose. La difficulté reste de faire ça à grande échelle ou d'automatiser ça mais ça me semble la bonne solution. Solarus --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] detection VPN SSL
Merci de vos retours. 2016-03-08 11:40 GMT+01:00 Bruno LEAL DE SOUSA : > Hello, > > Le proxy est interne ou externe ? > Ils doivent obligatoirement passer par le proxy ? > > J'ai connu un cas où le proxy était externe et pour protéger des VPN, la > règle était : > >- On bloque tous les connexions chiffrées https, ssl-smpt, pptp, etc... >- On autorise la sortie https uniquement vers le proxy > > Ainsi toutes les connexions vpn étaint bloquées. > > les proxies sont internes, tout passe par eux. mais je ne comprend pas en quoi cela va bloquer les VPN SSL. En effet on peut bloquer les VPN du type PPTP, IPsec, ssh etc, mais concernant les vpn ssl utilisant la connexion du navigateur, il me semble que cela ne change rien. Je me trompe peut etre. Je vais faire des tests avec un serveur opensource : adito voir ce que ça me genere comme traffic. > A+ > > Le 8 mars 2016 à 11:19, Jérôme MARTINIERE < > j.martini...@groupe-alliance.com> a écrit : > >> Bonjour, >> >> Quel est le but final du filtrage ? >> > limiter les fuites d'information, et mieux contrôler notre réseaux. L'entreprise possède plusieurs 100aine d'utilisateurs dont beaucoup d'informaticiens, et cela devient de plus en plus dur de "maîtriser" le réseau. > >> Sans casser le chiffrage par un proxy, il est possible de filtrer par >> FQDN ou classes d’IP, notamment pour exclure les tunnels vers des IP de FAI >> « grand public » par exemple ou vers les fournisseurs de proxy web. >> >> h, je vais voir ce qu'il est possible de faire avec ça, je n'y avais pas spécialement pensé. est ce que c'est réellement réalisable ? j'avais penser en effet à un whitelistage, mais je me suis dit que ça deviendrait ingerable tres vite ... mais peut etre au niveau classes d'IP, cela fera deja un filtre... > Cordialement, >> >> Jérôme MARTINIERE >> >> De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part >> de Jocelyn Lagarenne >> Envoyé : mardi 8 mars 2016 10:45 >> À : frnog-t...@frnog.org >> Objet : [FRnOG] [TECH] detection VPN SSL >> >> Bonjour à tous, >> >> je me retrouve face à un dilemme. On me demande de proposer une solution >> pour détecter/bloquer les VPN SSL non autorisés mais autant que je sache le >> traffic au travers d'un proxy est identique à un traffic https. il est donc >> impossible de le detecter non ? ou est ce que je fais fausse route ? >> Il est techniquement envisageable de casser le https sur les proxys mais >> ce n'est pas une recommandation que j'aime. >> la seul solution que je vois est de détecter les connexions SSL "longue" >> et de vérifier ce qu'elles sont (eliminer les faux positives comme par >> exemple gtalk), mais je ne suis meme pas sure que des logs proxy puissent >> me donner cette information. >> >> Auriez vous des idées/suggestions ? avez vous déjà eu ce genre de cas >> dans vos entreprises ? >> >> d'avance merci de vos retours >> >> Cordialement, >> -- >> Jocelyn Lagarenne >> >> --- >> Liste de diffusion du FRnOG >> http://www.frnog.org/ >> > > > > -- > Bruno LEAL DE SOUSA > IT System and Network Administrator > Co-founder and editor of *Bidouille-IT* : http://bidouilleit.com > > « Failure is the foundation of success, and the means by which it is > achieved. » - *Lao Tzu* > -- Jocelyn Lagarenne 06 28 78 30 50 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] detection VPN SSL
Hello, Sinon tu éduque tes décisionnaires/clients et tu leur explique que les VPN c'est forcément pas le mal : Si c'est pour éviter les fuites de données, il faut une sécurité de bout en bout qui commence par interdire aux gens d'installer n'importe quoi sur leur station de travail/portable. Interdire les VPN ne servira a rien sinon. Si c'est pour une question de responsabilité (mec qui fait du torrent avec la fibre @work ou qui visite des sites peu recommendables) le problème ne se pose pas car on va remonter au niveau du fournisseur de VPN qui lui aura un compte avec des info associées à la connexion. Et si le fournisseur te renvois la balle, et bien le simple log des CONNECT pourra te permettre de lier la connexion à la personne. Et détecter le connections longues, c'est bien, mais comment tu fait la diff entre un websocket SSL, un longpooling ajax HTTPS et un VPN? Et pour information j'ai déjà contourné ce genre de restriction a la noix quand j'était étudiant avec un VPN OpenVPN tcp 443, des gros buffer, des gros timeout et un reconnect agressif, le tout sur une box OVH perso à 5€. My 20 cents Le 8 mars 2016 à 10:44, Jocelyn Lagarenne a écrit : > Bonjour à tous, > > je me retrouve face à un dilemme. On me demande de proposer une solution > pour détecter/bloquer les VPN SSL non autorisés mais autant que je sache le > traffic au travers d'un proxy est identique à un traffic https. il est donc > impossible de le detecter non ? ou est ce que je fais fausse route ? > Il est techniquement envisageable de casser le https sur les proxys mais ce > n'est pas une recommandation que j'aime. > la seul solution que je vois est de détecter les connexions SSL "longue" et > de vérifier ce qu'elles sont (eliminer les faux positives comme par exemple > gtalk), mais je ne suis meme pas sure que des logs proxy puissent me donner > cette information. > > Auriez vous des idées/suggestions ? avez vous déjà eu ce genre de cas dans > vos entreprises ? > > d'avance merci de vos retours > > Cordialement, > -- > Jocelyn Lagarenne > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > -- Nathan Delhaye 06 69 27 64 25 0805 696 494 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] detection VPN SSL
Hello, Le proxy est interne ou externe ? Ils doivent obligatoirement passer par le proxy ? J'ai connu un cas où le proxy était externe et pour protéger des VPN, la règle était : - On bloque tous les connexions chiffrées https, ssl-smpt, pptp, etc... - On autorise la sortie https uniquement vers le proxy Ainsi toutes les connexions vpn étaint bloquées. A+ Le 8 mars 2016 à 11:19, Jérôme MARTINIERE a écrit : > Bonjour, > > Quel est le but final du filtrage ? > > Sans casser le chiffrage par un proxy, il est possible de filtrer par FQDN > ou classes d’IP, notamment pour exclure les tunnels vers des IP de FAI « > grand public » par exemple ou vers les fournisseurs de proxy web. > > Cordialement, > > Jérôme MARTINIERE > > De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part > de Jocelyn Lagarenne > Envoyé : mardi 8 mars 2016 10:45 > À : frnog-t...@frnog.org > Objet : [FRnOG] [TECH] detection VPN SSL > > Bonjour à tous, > > je me retrouve face à un dilemme. On me demande de proposer une solution > pour détecter/bloquer les VPN SSL non autorisés mais autant que je sache le > traffic au travers d'un proxy est identique à un traffic https. il est donc > impossible de le detecter non ? ou est ce que je fais fausse route ? > Il est techniquement envisageable de casser le https sur les proxys mais > ce n'est pas une recommandation que j'aime. > la seul solution que je vois est de détecter les connexions SSL "longue" > et de vérifier ce qu'elles sont (eliminer les faux positives comme par > exemple gtalk), mais je ne suis meme pas sure que des logs proxy puissent > me donner cette information. > > Auriez vous des idées/suggestions ? avez vous déjà eu ce genre de cas dans > vos entreprises ? > > d'avance merci de vos retours > > Cordialement, > -- > Jocelyn Lagarenne > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > -- Bruno LEAL DE SOUSA IT System and Network Administrator Co-founder and editor of *Bidouille-IT* : http://bidouilleit.com « Failure is the foundation of success, and the means by which it is achieved. » - *Lao Tzu* --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] detection VPN SSL
Bonjour, Quel est le but final du filtrage ? Sans casser le chiffrage par un proxy, il est possible de filtrer par FQDN ou classes d’IP, notamment pour exclure les tunnels vers des IP de FAI « grand public » par exemple ou vers les fournisseurs de proxy web. Cordialement, Jérôme MARTINIERE De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de Jocelyn Lagarenne Envoyé : mardi 8 mars 2016 10:45 À : frnog-t...@frnog.org Objet : [FRnOG] [TECH] detection VPN SSL Bonjour à tous, je me retrouve face à un dilemme. On me demande de proposer une solution pour détecter/bloquer les VPN SSL non autorisés mais autant que je sache le traffic au travers d'un proxy est identique à un traffic https. il est donc impossible de le detecter non ? ou est ce que je fais fausse route ? Il est techniquement envisageable de casser le https sur les proxys mais ce n'est pas une recommandation que j'aime. la seul solution que je vois est de détecter les connexions SSL "longue" et de vérifier ce qu'elles sont (eliminer les faux positives comme par exemple gtalk), mais je ne suis meme pas sure que des logs proxy puissent me donner cette information. Auriez vous des idées/suggestions ? avez vous déjà eu ce genre de cas dans vos entreprises ? d'avance merci de vos retours Cordialement, -- Jocelyn Lagarenne --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] detection VPN SSL
Bonjour, On peut quand même voir le FQDN contacté dans la requête CONNECT envoyée au proxy, tu peux te baser la dessus. Une solution courante consiste à utiliser du filtrage d'URL par catégories: * tu bloques bien sur la catégorie contenant les VPNs ou proxys distants, pour les services de VPN connus. * ensuite il faut bloquer tout ce qui n'est pas catégorisé, ce qui permet de ne pas autoriser le vpn ssl "maison" qu'un de tes utilisateurs aurait monté sur son serveur dédié ou à la maison. Par contre, du coup, ça oblige à gérer les autorisations de sites non catégorisés. C'est consommateur en temps et cela peut être gênant pour les utilisateurs. L'analyse des logs est plus compliquée à faire et il va être difficile de dissocier un gros téléchargement qui a pris du temps et un tunnel à partir de la durée de connexion ou du nombre d'octets transférés. Le 8 mars 2016 à 10:44, Jocelyn Lagarenne a écrit : > Bonjour à tous, > > je me retrouve face à un dilemme. On me demande de proposer une solution > pour détecter/bloquer les VPN SSL non autorisés mais autant que je sache le > traffic au travers d'un proxy est identique à un traffic https. il est donc > impossible de le detecter non ? ou est ce que je fais fausse route ? > Il est techniquement envisageable de casser le https sur les proxys mais ce > n'est pas une recommandation que j'aime. > la seul solution que je vois est de détecter les connexions SSL "longue" et > de vérifier ce qu'elles sont (eliminer les faux positives comme par exemple > gtalk), mais je ne suis meme pas sure que des logs proxy puissent me donner > cette information. > > Auriez vous des idées/suggestions ? avez vous déjà eu ce genre de cas dans > vos entreprises ? > > d'avance merci de vos retours > > Cordialement, > -- > Jocelyn Lagarenne > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] detection VPN SSL
Bonjour à tous, je me retrouve face à un dilemme. On me demande de proposer une solution pour détecter/bloquer les VPN SSL non autorisés mais autant que je sache le traffic au travers d'un proxy est identique à un traffic https. il est donc impossible de le detecter non ? ou est ce que je fais fausse route ? Il est techniquement envisageable de casser le https sur les proxys mais ce n'est pas une recommandation que j'aime. la seul solution que je vois est de détecter les connexions SSL "longue" et de vérifier ce qu'elles sont (eliminer les faux positives comme par exemple gtalk), mais je ne suis meme pas sure que des logs proxy puissent me donner cette information. Auriez vous des idées/suggestions ? avez vous déjà eu ce genre de cas dans vos entreprises ? d'avance merci de vos retours Cordialement, -- Jocelyn Lagarenne --- Liste de diffusion du FRnOG http://www.frnog.org/