Aujourd'hui, la problématique de sécurité qui me préoccupe concerne tout
ce qu'il est possible d'encapsuler dans le HTTPS (VPN SSL, et sessions
de prise de main à distance type WEBEX).
Je souhaiterais savoir quelles sont les possibilités d'empêcher ce type
d'accès (ou tout au moins de l'interdire par défaut, mais de le rendre
possible à la demande), sans pour autant bien évidemment interdire toute
la navigation HTTPS (sur le port 443).
A quel niveau interdire celà ? Au niveau de SQUID ? au niveau des postes
de travail (tous en Windows XP) ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
M'vy
Bonjour,
Étant donné la nature du flux SSL crypté, il est impossible d'analyser le protocole pour savoir ce que l'on fait. Tout le flux qui transit n'est que du HTTP crypté.
Une des parades possibles est le filtrage, il faut faire un audit sur les adresses IPs les plus demandées (ou avec beaucoup de traffic) et tester avec une requète s'il s'agit vraiment d'un site internet. Si ce n'est pas un site, il est fort possible que la machine distante réponde à la requète. (Car un tunnel SSL n'est pas, en général, prévu pour répondre à ce type de demande, il attend plutôt des données à rediriger vers une application).
On ne peut pas bloquer tout le trafic par défaut, car on ne sait pas à priori si le flux est légal, ou non. Après, il faut aussi sensibiliser les utilisateurs à la sécurité, et leur faire respecter la charte informatique.
J'espère avoir pu faire avancer un peu les choses.
EnjoY!
-- Yves "M'vy" Stadler Étudiant en sécurité informatique Université Paul Verlaine [MIM/SSIC]
"Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes."
Bonjour,
Étant donné la nature du flux SSL crypté, il est impossible d'analyser
le protocole pour savoir ce que l'on fait. Tout le flux qui transit
n'est que du HTTP crypté.
Une des parades possibles est le filtrage, il faut faire un audit sur
les adresses IPs les plus demandées (ou avec beaucoup de traffic) et
tester avec une requète s'il s'agit vraiment d'un site internet. Si ce
n'est pas un site, il est fort possible que la machine distante réponde
à la requète. (Car un tunnel SSL n'est pas, en général, prévu pour
répondre à ce type de demande, il attend plutôt des données à rediriger
vers une application).
On ne peut pas bloquer tout le trafic par défaut, car on ne sait pas à
priori si le flux est légal, ou non. Après, il faut aussi sensibiliser
les utilisateurs à la sécurité, et leur faire respecter la charte
informatique.
J'espère avoir pu faire avancer un peu les choses.
EnjoY!
--
Yves "M'vy" Stadler
Étudiant en sécurité informatique
Université Paul Verlaine [MIM/SSIC]
Étant donné la nature du flux SSL crypté, il est impossible d'analyser le protocole pour savoir ce que l'on fait. Tout le flux qui transit n'est que du HTTP crypté.
Une des parades possibles est le filtrage, il faut faire un audit sur les adresses IPs les plus demandées (ou avec beaucoup de traffic) et tester avec une requète s'il s'agit vraiment d'un site internet. Si ce n'est pas un site, il est fort possible que la machine distante réponde à la requète. (Car un tunnel SSL n'est pas, en général, prévu pour répondre à ce type de demande, il attend plutôt des données à rediriger vers une application).
On ne peut pas bloquer tout le trafic par défaut, car on ne sait pas à priori si le flux est légal, ou non. Après, il faut aussi sensibiliser les utilisateurs à la sécurité, et leur faire respecter la charte informatique.
J'espère avoir pu faire avancer un peu les choses.
EnjoY!
-- Yves "M'vy" Stadler Étudiant en sécurité informatique Université Paul Verlaine [MIM/SSIC]
"Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes."
D.CARRE
Bonjour,
Pour ce qui est de l'analyse du flux SSL crypté, si c'est possible, mais à condition de faire de l'intermédiation SSL (proxy SSL qui rompt le flux crypté de bout en bout), mais nous n'envisageons pas ce type de réponse.
Je ne parle même pas de tunnels SSL purs, mais bien de passerelles HTTPS (type VPN SSL ou session de prise de main à distance type WebEx, de plus en plus utilisées par les plateformes de support).
En fait je suis d'accord avec vous sur le principe qu'il est particulièrement compliqué de mettre en oeuvre une sécurité de ce type au niveau du proxy, on peut donc éventuellement restreindre la question aux postes de travail (sous windows XP), par rapport à des blocages d'activeX par exemple, ou d'autres restrictions de ce genre que nous pourrions mettre en oeuvre via GPO ...
Merci pour votre réponse
Bonjour,
Pour ce qui est de l'analyse du flux SSL crypté, si c'est possible, mais
à condition de faire de l'intermédiation SSL (proxy SSL qui rompt le
flux crypté de bout en bout), mais nous n'envisageons pas ce type de
réponse.
Je ne parle même pas de tunnels SSL purs, mais bien de passerelles HTTPS
(type VPN SSL ou session de prise de main à distance type WebEx, de plus
en plus utilisées par les plateformes de support).
En fait je suis d'accord avec vous sur le principe qu'il est
particulièrement compliqué de mettre en oeuvre une sécurité de ce type
au niveau du proxy, on peut donc éventuellement restreindre la question
aux postes de travail (sous windows XP), par rapport à des blocages
d'activeX par exemple, ou d'autres restrictions de ce genre que nous
pourrions mettre en oeuvre via GPO ...
Pour ce qui est de l'analyse du flux SSL crypté, si c'est possible, mais à condition de faire de l'intermédiation SSL (proxy SSL qui rompt le flux crypté de bout en bout), mais nous n'envisageons pas ce type de réponse.
Je ne parle même pas de tunnels SSL purs, mais bien de passerelles HTTPS (type VPN SSL ou session de prise de main à distance type WebEx, de plus en plus utilisées par les plateformes de support).
En fait je suis d'accord avec vous sur le principe qu'il est particulièrement compliqué de mettre en oeuvre une sécurité de ce type au niveau du proxy, on peut donc éventuellement restreindre la question aux postes de travail (sous windows XP), par rapport à des blocages d'activeX par exemple, ou d'autres restrictions de ce genre que nous pourrions mettre en oeuvre via GPO ...
Merci pour votre réponse
Fabien LE LEZ
On 21 Dec 2007 13:29:59 GMT, "D.CARRE" :
Je ne parle même pas de tunnels SSL purs, mais bien de passerelles HTTPS
Du point de vue d'un intermédiaire (proxy, passerelle...), il me semble que c'est la même chose : le client ouvre une connexion TCP vers le serveur, ils commencent à causer en SSL, et là, tu n'as plus aucun moyen de savoir ce qu'ils se disent.
En fait je suis d'accord avec vous sur le principe qu'il est particulièrement compliqué de mettre en oeuvre une sécurité de ce type au niveau du proxy,
Ben... Soit tu "casses" le SSL (en déchiffrant/rechiffrant au niveau du proxy), soit tu en es réduit à de vagues analyses heuristiques qui risquent de ne pas te mener loin.
on peut donc éventuellement restreindre la question aux postes de travail (sous windows XP), par rapport à des blocages d'activeX par exemple,
Déjà, si tu interdis l'accès à IE et tu n'installes pas Java sur les postes, tu seras plus tranquille.
Sinon, une idée marrante pour occuper ton week-end : les postes de travail n'ont pas d'accès à Internet (même à travers un proxy) ; par contre, chaque utilisateur peut acccéder, via NX <http://en.wikipedia.org/wiki/NX_technology>, à une machine virtuelle sous Linux (par exemple), avec juste un Firefox (ou Opera) paramétré aux petits oignons, qui, lui, a accès au web. C'est presque équivalent à avoir un deuxième PC pour le web, de façon à protéger le PC principal.
On 21 Dec 2007 13:29:59 GMT, "D.CARRE" <uso.NOSPAM@fr.st>:
Je ne parle même pas de tunnels SSL purs, mais bien de passerelles HTTPS
Du point de vue d'un intermédiaire (proxy, passerelle...), il me
semble que c'est la même chose : le client ouvre une connexion TCP
vers le serveur, ils commencent à causer en SSL, et là, tu n'as plus
aucun moyen de savoir ce qu'ils se disent.
En fait je suis d'accord avec vous sur le principe qu'il est
particulièrement compliqué de mettre en oeuvre une sécurité de ce type
au niveau du proxy,
Ben... Soit tu "casses" le SSL (en déchiffrant/rechiffrant au niveau
du proxy), soit tu en es réduit à de vagues analyses heuristiques qui
risquent de ne pas te mener loin.
on peut donc éventuellement restreindre la question
aux postes de travail (sous windows XP), par rapport à des blocages
d'activeX par exemple,
Déjà, si tu interdis l'accès à IE et tu n'installes pas Java sur les
postes, tu seras plus tranquille.
Sinon, une idée marrante pour occuper ton week-end : les postes de
travail n'ont pas d'accès à Internet (même à travers un proxy) ; par
contre, chaque utilisateur peut acccéder, via NX
<http://en.wikipedia.org/wiki/NX_technology>, à une machine virtuelle
sous Linux (par exemple), avec juste un Firefox (ou Opera) paramétré
aux petits oignons, qui, lui, a accès au web.
C'est presque équivalent à avoir un deuxième PC pour le web, de façon
à protéger le PC principal.
Je ne parle même pas de tunnels SSL purs, mais bien de passerelles HTTPS
Du point de vue d'un intermédiaire (proxy, passerelle...), il me semble que c'est la même chose : le client ouvre une connexion TCP vers le serveur, ils commencent à causer en SSL, et là, tu n'as plus aucun moyen de savoir ce qu'ils se disent.
En fait je suis d'accord avec vous sur le principe qu'il est particulièrement compliqué de mettre en oeuvre une sécurité de ce type au niveau du proxy,
Ben... Soit tu "casses" le SSL (en déchiffrant/rechiffrant au niveau du proxy), soit tu en es réduit à de vagues analyses heuristiques qui risquent de ne pas te mener loin.
on peut donc éventuellement restreindre la question aux postes de travail (sous windows XP), par rapport à des blocages d'activeX par exemple,
Déjà, si tu interdis l'accès à IE et tu n'installes pas Java sur les postes, tu seras plus tranquille.
Sinon, une idée marrante pour occuper ton week-end : les postes de travail n'ont pas d'accès à Internet (même à travers un proxy) ; par contre, chaque utilisateur peut acccéder, via NX <http://en.wikipedia.org/wiki/NX_technology>, à une machine virtuelle sous Linux (par exemple), avec juste un Firefox (ou Opera) paramétré aux petits oignons, qui, lui, a accès au web. C'est presque équivalent à avoir un deuxième PC pour le web, de façon à protéger le PC principal.
D.CARRE
Du point de vue d'un intermédiaire (proxy, passerelle...), il me semble que c'est la même chose : le client ouvre une connexion TCP vers le serveur, ils commencent à causer en SSL, et là, tu n'as plus aucun moyen de savoir ce qu'ils se disent.
Pas dans le cas d'une intermédiation SSL, où il y a bien rupture de session et de chiffrement ... Le certificat présenté au client est d'ailleurs celui du proxy ssl.
Déjà, si tu interdis l'accès à IE et tu n'installes pas Java sur les postes, tu seras plus tranquille.
inenvisageable
Sinon, une idée marrante pour occuper ton week-end : les postes de travail n'ont pas d'accès à Internet (même à travers un proxy) ; par contre, chaque utilisateur peut acccéder, via NX <http://en.wikipedia.org/wiki/NX_technology>, à une machine virtuelle sous Linux (par exemple), avec juste un Firefox (ou Opera) paramétré aux petits oignons, qui, lui, a accès au web. C'est presque équivalent à avoir un deuxième PC pour le web, de façon à protéger le PC principal.
inenvisageable également !
Je sais que ce que je cherche à faire est possible ... Je l'ai vu quand j'étais prestataire au sein d'un grand groupe publique français ...
Depuis le poste de travail (XP, IE6), il était tout à fait possible de s'authentifier en HTTPS sur un portail VPN SSL (un juniper secure access, pour ne pas le nommer). De là, les applis web fonctionnaient tout à fait, à travers le vpn ssl. En revanche, les ActiveX ou Java, permettant par exemple d'initier une session RDP sur un serveur Windows, ne fonctionnaient pas, pas plus que la possibilité de monter un accès réseau sur le LAN distant ... Mais je ne sais par quel biais tout celà était rendu impossible.
Du point de vue d'un intermédiaire (proxy, passerelle...), il me
semble que c'est la même chose : le client ouvre une connexion TCP
vers le serveur, ils commencent à causer en SSL, et là, tu n'as plus
aucun moyen de savoir ce qu'ils se disent.
Pas dans le cas d'une intermédiation SSL, où il y a bien rupture de
session et de chiffrement ... Le certificat présenté au client est
d'ailleurs celui du proxy ssl.
Déjà, si tu interdis l'accès à IE et tu n'installes pas Java sur les
postes, tu seras plus tranquille.
inenvisageable
Sinon, une idée marrante pour occuper ton week-end : les postes de
travail n'ont pas d'accès à Internet (même à travers un proxy) ; par
contre, chaque utilisateur peut acccéder, via NX
<http://en.wikipedia.org/wiki/NX_technology>, à une machine virtuelle
sous Linux (par exemple), avec juste un Firefox (ou Opera) paramétré
aux petits oignons, qui, lui, a accès au web.
C'est presque équivalent à avoir un deuxième PC pour le web, de façon
à protéger le PC principal.
inenvisageable également !
Je sais que ce que je cherche à faire est possible ... Je l'ai vu quand
j'étais prestataire au sein d'un grand groupe publique français ...
Depuis le poste de travail (XP, IE6), il était tout à fait possible de
s'authentifier en HTTPS sur un portail VPN SSL (un juniper secure
access, pour ne pas le nommer). De là, les applis web fonctionnaient
tout à fait, à travers le vpn ssl. En revanche, les ActiveX ou Java,
permettant par exemple d'initier une session RDP sur un serveur Windows,
ne fonctionnaient pas, pas plus que la possibilité de monter un accès
réseau sur le LAN distant ... Mais je ne sais par quel biais tout celà
était rendu impossible.
Du point de vue d'un intermédiaire (proxy, passerelle...), il me semble que c'est la même chose : le client ouvre une connexion TCP vers le serveur, ils commencent à causer en SSL, et là, tu n'as plus aucun moyen de savoir ce qu'ils se disent.
Pas dans le cas d'une intermédiation SSL, où il y a bien rupture de session et de chiffrement ... Le certificat présenté au client est d'ailleurs celui du proxy ssl.
Déjà, si tu interdis l'accès à IE et tu n'installes pas Java sur les postes, tu seras plus tranquille.
inenvisageable
Sinon, une idée marrante pour occuper ton week-end : les postes de travail n'ont pas d'accès à Internet (même à travers un proxy) ; par contre, chaque utilisateur peut acccéder, via NX <http://en.wikipedia.org/wiki/NX_technology>, à une machine virtuelle sous Linux (par exemple), avec juste un Firefox (ou Opera) paramétré aux petits oignons, qui, lui, a accès au web. C'est presque équivalent à avoir un deuxième PC pour le web, de façon à protéger le PC principal.
inenvisageable également !
Je sais que ce que je cherche à faire est possible ... Je l'ai vu quand j'étais prestataire au sein d'un grand groupe publique français ...
Depuis le poste de travail (XP, IE6), il était tout à fait possible de s'authentifier en HTTPS sur un portail VPN SSL (un juniper secure access, pour ne pas le nommer). De là, les applis web fonctionnaient tout à fait, à travers le vpn ssl. En revanche, les ActiveX ou Java, permettant par exemple d'initier une session RDP sur un serveur Windows, ne fonctionnaient pas, pas plus que la possibilité de monter un accès réseau sur le LAN distant ... Mais je ne sais par quel biais tout celà était rendu impossible.
