securisation navigation HTTPS (vpn ss l, webex)

Le
D.CARRE
Bonjour à tous,

A l'heure actuelle, la navigation internet de mes utilisateurs (environ
1.500) est assurée par l'intermédiaire de serveur Linux, via les outils :

Antivirus (TREND MICRO)
Proxy SQUID
filtrage d'URL OPTENET

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

Merci d'avance si vous pouvez m'éclairer

Cordialement,

Denis CARRE
Questions / Réponses high-tech
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
M'vy
Le #890497
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]

http://mvyonline.paradisia.net


_|
_| _| _|
_|_| _|_| _| _| _| _|
_| _| _| _| _| _| _|
_| _| _| _| _| _|
_| _| _| _|_|_|
_|
_|_|

"Il vaut mieux mobiliser son intelligence sur des conneries
que mobiliser sa connerie sur des choses intelligentes."
D.CARRE
Le #890496
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
Fabien LE LEZ
Le #890494
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
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
Le #890493
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
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.

Publicité
Poster une réponse
Anonyme