Comment lutter contre les connexions VPN sortantes

Comment lutter contre les connexions VPN sortantes - Sécurité - Réseaux grand public / SoHo

Marsh Posté le 21-11-2007 à 10:04:54    

Bonjour à tous,
J'ai entendu dire qu'il serait possible d'outrepasser les règles sécurité d'un réseau en créant une connexion VPN depuis l'intérieur d'un réseau jusqu'a un serveur, à l'extérieur de ce réseau.
Les données encapsulées permettrait une naviguation totale, transparente et indetectable. Plus aucun filtrage ne serait alors éfficace.
 
Est-ce la un simple mythe, ou cela peut-il représenter un véritable danger pour un réseau?
Si oui, comment empêcher cela?
 
Merci

Reply

Marsh Posté le 21-11-2007 à 10:04:54   

Reply

Marsh Posté le 04-12-2007 à 14:48:11    

Solutions possibles :
- débrancher l'accès à Internet
- monitorer les connexions sortantes et être capable de trouver LA connexion intrus
 
Précautions :
- ne pas installer n'importe quoi
- ne pas laisser entrer d'hacker en herbe dans la boîte
- ne pas laisser entrer d'utilisateur neuneux dans la boîte

Reply

Marsh Posté le 04-12-2007 à 19:02:50    

Débrancher Internet??!! Je pourrai priver les utilisateurs d'ordinateur aussi.
En ce qui concerne la connexion intrus, ce n'est pas détectable même avec une surveillance, puisqu'il s'agit d'un tunnel HTTP. Je ne verrai qu'une connexion "normale"
 
En ce qui concerne la sélection des employés ce n'est pas moi qui m'en occupe et de toute façon n'importe qui un peu informé sur le sujet peut mettre cela en place.

Reply

Marsh Posté le 04-12-2007 à 19:36:49    

Ca dépend quel type de filtrage tu met mais oui ça se monitore/filtre

Reply

Marsh Posté le 04-12-2007 à 23:02:45    

Avec un pare-feux applicatif il me semble...

Reply

Marsh Posté le 04-12-2007 à 23:29:39    

Par définition la pare-feu applicatif intervient au niveau applicatif. C'est par exemple quand le firewall demande "firefox tente d'accèder au réseau, autoriser ?". Ça intervient au niveau d'une machine cliente et non serveur.
 
Une passerelle n'est pas faite pour travailler au niveau applicatif (enfin je me comprend quoi), cependant il y a bien le proxy dans le cas précis de l'accès internet... par exemple, on peut forcer un utilisateur a se "manifester physiquement ou intellectuellement" en validant un formulaire pour accéder à Internet, logins etc. Par-contre pour https, tu vas t'arracher les cheveux.
 
Et puis le véritable danger, c'est quand la personne malintentionnée n'est pas un utilisateur du réseau. Un utilisateur du réseau a les mêmes possibilités d'attaques que s'il passait par un VPN. Après si le danger c'est le porno et les virus au bureau, c'est pas vraiment un danger (enfin si les virus un peu) mais si tu considères cela comme un danger.


Message édité par czh le 04-12-2007 à 23:31:27
Reply

Marsh Posté le 04-12-2007 à 23:55:19    

Je vois pas pk une passerelle ne ferait pas de filtrage applicatif.
Pleins le font pour pleins de protocoles. C'est très répendu en entreprise.
Après il ya le proxy en effet.
 
En analysant déjà le traffic tu peut voir si il y a du traffic toujours entre 2 IP, là tu te rend déjà compte qu'il y a des trucs qui vont pas (surtout si ya des transferts)

Reply

Marsh Posté le 05-12-2007 à 17:46:06    

Ca je suis tout à fait d'accord. Tu peux détecter sans problème un traffic entre deux IP.
Le problème se trouvant justement au niveau du proxy.
J'ai essayé, et ça a fonctionné parfaitement. Les logs remontaient une simple connexion HTTP....

Reply

Marsh Posté le 05-12-2007 à 21:47:41    

Je@nb a écrit :

Je vois pas pk une passerelle ne ferait pas de filtrage applicatif.


 
Le firewall applicatif c'est pas vraiment applicatif, un numéro de port ne correspond pas toujours à un service.
Dans ce cas précis, les filtrages applicatifs sont plutôt inefficaces, pour empêcher le porno au boulot ouais mais pour arrêter un tunnel ssh over http c'est une autre histoire.
 
Mais bon doit bien y avoir des solutions à 20 000 euros pour faire ça.


Message édité par czh le 05-12-2007 à 22:02:04
Reply

Marsh Posté le 05-12-2007 à 22:10:54    

firewall applicatif, ça monte au dessus des ports.
Tu fait des règles sur le contenu, les méthodes http, les requêtes http elles même.
Dans du https par contre c'est moins facile, d'où les proxy

Reply

Marsh Posté le 05-12-2007 à 22:10:54   

Reply

Marsh Posté le 05-12-2007 à 22:24:36    

Je@nb a écrit :

firewall applicatif, ça monte au dessus des ports.
Tu fait des règles sur le contenu, les méthodes http, les requêtes http elles même.
Dans du https par contre c'est moins facile, d'où les proxy


 
Dans la pratique, on identifie les services par les ports, et on filtre par rapport aux services. S'il existait un tel firewall : Les paquets ne sont toujours pas constitué de contenu identifiable, que fait-tu ? que fait-tu lors d'un changement de protocole. Il est clair que la plupart des parefeu applicatifs se basent sur les couches basses pour effectuer leur traitement.
 
De toute façon, un parefeu est par définition un programme qui transgresse toutes les principes de la couche OSI, donc on ne peut pas parler de parefeu totalement applicatif, ou de totalement. Un parefeu est un parefeu point, néanmoins plus ou moins spécialisé dans quelque chose.


Message édité par czh le 05-12-2007 à 22:26:18
Reply

Marsh Posté le 05-12-2007 à 22:28:14    

Non, tu prends l7filter par exemple pour iptables il fait de l'inspection sur les protocoles eux même. Pareil pour ipp2p. Sous windows tu prends ISA Server (même si il fait bien d'autres choses, il peut filtrer les requêtes RPC, filtrer les requetes FTP pour interdire l'upload, s'occuper de h323 ou autres)
Si on parle de filtrage applicatif ça veut dire qu'on s'arrète plus haut que les ports ..., sinon on appelle ça un simple filtrage par port (sans rentrer dans des considérations statefull ou stateless).

Reply

Marsh Posté le 05-12-2007 à 22:39:37    

Je concois qu'il peut exister de tel applications, mais bon niveau fiabilité le problème reste entier, parce tout ce que font ces logiciels c'est estimer et deviner, ce qui revient à dire "Une passerelle n'est pas faite pour travailler au niveau applicatif". Paradoxalement, la passerelle reste néanmoins l'un des meilleurs endroits pour le faire.


Message édité par czh le 05-12-2007 à 22:45:54
Reply

Marsh Posté le 05-12-2007 à 22:43:08    

Je@nb a écrit :

Non, tu prends l7filter par exemple pour iptables il fait de l'inspection sur les protocoles eux même. Pareil pour ipp2p. Sous windows tu prends ISA Server (même si il fait bien d'autres choses, il peut filtrer les requêtes RPC, filtrer les requetes FTP pour interdire l'upload, s'occuper de h323 ou autres)
Si on parle de filtrage applicatif ça veut dire qu'on s'arrète plus haut que les ports ..., sinon on appelle ça un simple filtrage par port (sans rentrer dans des considérations statefull ou stateless).


 
C'est bien beau de filtrer les protocoles, mais dans le cas d'un tunnel HTTP, ce n'est qu'un simple traffique HTTp dans lequel on fait passer ce que l'on veut.
 
En gros ce n'est que très difficilement détectable. On peut considérer que l'on navigue en furtif au sein d'un réseau.

Reply

Marsh Posté le 05-12-2007 à 23:01:06    

C'est pas parce que c'est un tunnel http que tu vois rien. Tes requêtes HTTP tu vas bien les faire. Le client enverra surement des entêtes sur lesquel tu peux filtrer, le traffic ne ressemblera pas à du traffic web (dl de pages et de gif/jpg/js/swf), la méthode HTTP ne sera peut être pas un GET ou un POST (par exemple CONNECT) bref tous ces éléments là tu peux filtrer sans savoir en effet ce qui se cache dans la partie donnée du protocole http (sauf si le format est connu où dans ce cas on peut imaginer une reconnaissance). Pour HTTPS par contre non.

Reply

Marsh Posté le 06-12-2007 à 19:07:33    

Je parlais justement  de tunnel HTTPS

Reply

Marsh Posté le 06-12-2007 à 20:24:20    

Bah depuis le début tu met HTTP alors faut arriver à suivre quoi :D et depuis le début je dis que HTTPS tu peux pas faire gd chose :d

Reply

Marsh Posté le 07-12-2007 à 15:25:48    

Je parlais en effet de HTTPS. J'aurai pu le préciser plus tot. :D

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed