SSTIC 2012 - Utilisation malveillante des suivis de connexion
Par Eric Leblond @Regiteric
L’auteur nous fait un topo sur les techniques de suivis d’états de Netfilter, sachant que c’est aussi applicable avec d’autres solutions de firewalling. Netfilter utilise un système de marquage des paquets pour effectuer le suivi des connexions. Le problème vient avec FTP n co ou on à un canal de communication et l’ouverture de connexions de façon dynamique ce qui fout bien la zone. De ce fait, netfilter doit être capable de découvrir dans les échanges FTP les ports qui seront à suivre. C’est implémenté sous la forme d’un ALG : Application Layer Gateway. Ce sont les fameux helpers de netfilter.
Ainsi, un certain nombre de protocoles ont déjà leur helper disponible dans le noyau linux.
Des questions se posent quand à la sécurité du filtrage lorsqu’on utilise des helpers. Ainsi est-ce qu’un attaquant peut détourner le fonctionnement du helper, et est-ce que ça n’implique pas de transformer son pare-feu en open-bar.
En lisant la RFC de FTP, il est possible d’établir des connexions dans tout les sens (loose=0), heureusement cette option est désactivée par défaut. IRC c’est pareil, il est possible d’établir des connexions arbitraires entre le client et n’importe quel autre IP sur le net (DCC n co). Donc en abusant des helpers, il est envisageable de provoquer l’ouverture de ports vers l’extérieur.
Une doc à été faite dans l’équipe NetFilter pour expliquer comment utiliser les helpers de façon sûre.
L’autre technique d’abus du conntrack, c’est d’effectuer du spoofing quand on est derrière le pare-feu. Ainsi en ouvrant une connexion légitime puis en craftant un paquet avec une IP destination spoofée et un port spoofé, le pare-feu ouvre alors le port demandé en sortie.
Pour lutter contre ça, il existe rp_filter, mais c’est désactivé par défaut.
Les outils sont disponibles ici: https://github.com/regit
