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 <e...@levacon.net>: > 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" <jocelyn.lagare...@gmail.com> > À: "Bruno LEAL DE SOUSA" <bruno.ld.so...@gmail.com> > Cc: "Jérôme MARTINIERE" <j.martini...@groupe-alliance.com>, > 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 <bruno.ld.so...@gmail.com>: > > > 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. > >> > >> mmmmh, 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/ > -- Jocelyn Lagarenne 06 28 78 30 50 --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
