regit/opensvpOpensvp est un outil de sécurité implémentant des « attaques » permettant de tester la résistance des pare-feu aux attaques au niveau du protocole.
Opensvp est un outil de sécurité implémentant des « attaques » permettant de tester la résistance d'un pare-feu aux attaques de niveau protocole. Il implémente des attaques classiques ainsi que de nouveaux types d'attaques contre les passerelles de couche applicative (appelées helpers dans le monde Netfilter).
Par exemple, opensvp est capable, sous certaines conditions (voir l'explication ci-dessous pour plus de détails), d'ouvrir un pin hole dans un pare-feu protégeant un serveur ftp : même si la politique de filtrage garantit que seul le port 21 est ouvert vers le serveur, vous pouvez ouvrir « n'importe quel » port sur le serveur en utilisant opensvp.
Prenons 192.168.2.3 comme serveur exécutant ftp, placé derrière un pare-feu. Si l'utilisateur, en root, exécute::
opensvp --attacker -t 192.168.2.3 --helper ftp --port 23 -v -i eth0
Il disposera alors d'un accès temporaire au port 23 du serveur, indépendamment des règles du pare-feu.
Le document « Secure use of iptables and connection tracking helpers » https://home.regit.org/netfilter-en/secure-use-of-helpers/ décrit la méthode de protection contre ce type d'attaque.
Voir le chapitre suivant pour une description précise de l'attaque implémentée.
Étant sur un réseau directement connecté au pare-feu via l'interface eth0, l'attaquant peut exécuter la commande suivante ::
opensvp --attacker -t 192.168.2.3 --helper ftp --port 23 -v -i eth0
192.168.2.3 est l'adresse du serveur FTP et 23 est le port que nous voulons ouvrir sur le serveur.
Il est ensuite possible de se connecter à 192.168.2.3 sur le port 23 après une attaque réussie.
Il est possible pour un client d'envoyer un message de commande forgé qui est interprété par les pare-feu comme une possible ouverture de connexion dynamique.
Il est possible d'utiliser un serveur standard pour envoyer l'attaque mais avec un serveur personnalisé, vous connaîtrez la transformation effectuée par l'éventuelle passerelle NAT.
Une session typique est la suivante. Sur le serveur dont l'adresse IP est 1.2.3.4, vous pouvez exécuter ::
$ opensvp --server --helper irc -v
Sur le client, vous pouvez ensuite exécuter ::
$ opensvp --client -t 1.2.3.4 --helper irc --port 23 -v 2.3.4.5:23 should be opened from outside
Sur le serveur, le message suivant est affiché ::
You should be able to connect to 2.3.4.5:23
Ici, 2.3.4.5 est l'adresse publique du client.
Sur l'attaquant, vous devez démarrer opensvp et indiquer la file Netfilter utilisée et l'interface de sortie ::
Vous devez ensuite utiliser iptables pour envoyer dans l'espace utilisateur le trafic que vous voulez masquer au mécanisme de reconnaissance de protocole ::
iptables -I INPUT -p tcp --sport 443 -j NFQUEUE iptables -I OUTPUT -p tcp --dport 443 -j NFQUEUE
Lorsque vous avez terminé, appuyez sur CTRL+C pour interrompre le processus d'attaque.
Certains protocoles réseau utilisent plusieurs connexions pour l'échange entre un client et un serveur. L'exemple le plus connu est ftp, où les commandes passent par une connexion sur le port 21 et où les échanges de données se font avec deux modes différents (connexion depuis le port 20 ou connexion dynamique).
Certaines implémentations de pare-feu intègrent une passerelle de couche applicative (ALG) afin de détecter cette connexion parallèle et de l'autoriser dynamiquement. D'autres solutions consistent à utiliser un relais applicatif (proxy transparent) ou à ouvrir tous les flux possibles (lire presque tout).
L'ALG analyse le trafic, détecte et analyse la commande envoyée entre les pairs pour déclarer les paramètres des connexions parallèles. Une fois cela fait, ils ouvrent temporairement des pin holes dans le pare-feu pour laisser passer le trafic probable.
L'idée de cette attaque est de forger ce type de messages afin d'ouvrir des pin holes dans le pare-feu, mais des pin holes qui n'auraient pas dû être ouverts.
Condition :
Le scénario est le suivant :
Un sniffer sur le réseau de l'attaquant capture un paquet du flux du protocole
Le paquet forgé est envoyé sur l'interface connectée au pare-feu
Le pare-feu renvoie le paquet au client et attend désormais un paquet avec des caractéristiques basées sur les entrées de l'attaquant
Cette attaque est une application directe du principe décrit. Dès qu'un paquet de données est reçu, l'attaquant envoie une commande DCC forgée.
Dans cette attaque, la connexion cliente est ouverte par l'attaquant. Il se connecte au serveur ftp derrière un pare-feu et initie une connexion réelle. Une fois la session établie, il lance l'attaque en envoyant une commande 227 forgée.
Si IPv6 est utilisé, la même attaque est réalisée avec une commande 229 forgée.
Cible possible
La principale contrainte de ces attaques est que l'attaquant doit se trouver sur un réseau
directement connecté au pare-feu.
Ainsi, les principales possibilités sont :
* Attaque depuis un LAN d'utilisateurs
* Attaque dans une ferme d'hébergement
Les deux cas peuvent conduire à une exposition grave d'informations en donnant à l'attaquant
accès à des services non protégés.
Linux
~~~~~
Cette attaque est connue pour fonctionner sur les pare-feu Netfilter IPv4 si rp_filter est
défini à 0 (ce n'est heureusement pas la valeur par défaut).
Il n'existe actuellement aucune implémentation de filtrage de chemin inverse pour IPv6 ; le pare-feu
n'est donc pas protégé et la protection doit être configurée dans les règles du pare-feu (voir
le chapitre suivant).
Certains logiciels de pare-feu sont connus pour être vulnérables :
* fwbuilder : une politique spécifique doit être configurée
* shorewall : les versions récentes corrigent le problème
* edenwall : vulnérable
L'attaque fonctionne à la fois pour les pare-feu passerelle et les pare-feu locaux. Sur un pare-feu local,
le filtrage FORWARD doit être activé et une règle ESTABLISHED ACCEPT doit être configurée sur
cette chaîne. Cela peut être le cas des systèmes exécutant des machines virtuelles.
Défense contre l'attaque
========================
Linux
-----
Voir le document suivant dédié au sujet : https://home.regit.org/netfilter-en/secure-use-of-helpers/
Autres OS et équipements
------------------------
La condition de base est d'activer un anti-spoofing strict et, si possible, de contrôler le chargement des ALG.