Re: [FRnOG] [TECH] detection VPN SSL

[Bensay 1]

> 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

[Jocelyn Lagarenne]

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

[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/

RE: [FRnOG] [TECH] detection VPN SSL

[Michel Py]

> 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

[David Ponzone]

> 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

[Sylvain Vallerot]

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

[Radu-Adrian Feurdean]

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

[Eric Belhomme]

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

[Radu-Adrian Feurdean]

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

[Pierre Colombier]

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

[Michel Py]

> 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

[David Ponzone]

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

[Michel Py]

> 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

[Tristan Mahé]

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" <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.
>>>
>>> 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

[Jocelyn Lagarenne]

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
> FA

Re: [FRnOG] [TECH] detection VPN SSL

[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" <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.
>>
>> 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

Re: [FRnOG] [TECH] detection VPN SSL

[Solarus Lumenor]

 

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

[Jocelyn Lagarenne]

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.
>>
>> 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

[Nathan delhaye]

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

[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.

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 ?
>
> 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

[Jérôme MARTINIERE]

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

[Denis VINCIGUERRA]

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

[Jocelyn Lagarenne]

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/