Overblog
Editer l'article Suivre ce blog Administration + Créer mon blog
28 septembre 2012 5 28 /09 /septembre /2012 13:48

Avec ma plus grande considération pour mes confrères à Sophos, je voudrais lever une petite alerte concernant leur article :

http://nakedsecurity.sophos.com/2012/08/28/unpatched-java-exploit-spreads-like-wildfire/

 

Plus particulièrement, concernant la solution "protection via pare-feu de Windows". L'idée de base me semble pertinente : limiter l'accès réseau des composants de la machine virtuelle Java, ici vulnérable, pour réduire la surface d'exposition à des codes d'exploitation.

L'idée présentée dans l'article de Sophos est de mettre en oeuvre des règles dans le pare-feu de Windows, afin d'autoriser uniquement l'accès réseau intranet à la machine Java. Ceci réduit effectivement dans le principe, le seuil d'exposition de Java à des sites malveillants (ou légitimes mais compromis).

 

Cependant, quelques points :

 

1-  il faut avoir Vista, 7, ou 8, car le pare-feu Windows filtrant dans le sens sortant n'existait pas sous XP.

 

2- il faut avoir une politique de filtrage de flux en "liste blanche", c'est à dire que tout flux non explicitement déclaré dans les règles de pare-feu, serait refusé par défaut. Ceci est une règle assez "état de l'art" à mon avis, mais très dure à mettre en oeuvre dans la vraie vie. D'ailleurs, me semble-t-il, nombre d'entités ont simplement et purement désactivé le pare-feu de XP et 7, par GPO !

 

3- Déclarer l'intranet de l'entité dans règles pare-feu, par classes d'adresses, est possible. Mais pour des machines en mobilité, la connexion sur la Box ADSL de la maison se fait aussi sur des classes d'adresses privées (ex : 192.168.X.Y). Donc attention aux profils du pare-feu pour le déploiement de telles régles (profils de réseau privé / domaine).

 

4- J'arrive à mon plus gros point. La législation Française impose aux entreprises de disposer de traces des accès Internet de leurs employés. La technique la plus communément utilisée pour filtrer et générer ces traces, est la mise en oeuvre d'un mandataire (proxy). Or, ce dernier a... une adresse IP interne (pour l'accès depuis les machines clientes) !!  et au niveau TCP, quand on fait passer une connexion par un mandataire, la connexion entre le client et le mandataire se fait sur des IP de classes privées.

 

Exemple :

Client 192.168.1.10

Proxy : 192.168.1.253

Serveur HTTP demandé : 6.7.8.9

 

Le client demande l'accès au serveur HTTP dont l'IP est : 6.7.8.9, via le proxy.

La connexion entre le client et le proxy, qui prend à sa charge la session HTTP, correspond en fait à des sessions TCP entre 192.168.1.10 et 192.168.1.253, donc des IP privées. CQFD.

 

 

DONC, la mise en oeuvre du filtrage sur plages d'adresses telle que présentée par Sophos, ne marche pas si l'entité dispose de mandataires (proxies). Il faut penser à retirer les adresses des proxies de la liste des IP autorisées dans le pare-feu Windows pour la machine virtuelle Java.

 

J'ai fait, par curiosité, une reproduction, qui confirme mes craintes.

 

Évidemment, si je poste cet article aujourd'hui, c'est aussi en lien avec l'actualité sécurité pour Oracle : http://www.silicon.fr/faille-java-oracle-securite-78942.html  1.1 milliard de machines concernées par une nouvelle faille, touchant Java 1.5, 1.6, et 1.7.

 

Partager cet article

Repost0

commentaires