Cher journal,
Voilà presque deux ans (ça passe) que je bosse sur un outil (lsfw) qui permet de lister les règles de pare-feux appliquées entre deux points d'un réseau.
Le but est d'aider les administrateurs réseaux à répondre aux questions existentielles : « bon sang, quelles sont les règles de là à là, dit ? », ou « pourquoi ça passe [pas], hein ?». Ce qui n'est pas forcément trivial sur un gros réseau avec plein de règles et plusieurs routeurs/pare-feu sur le chemin.
L'outil interprète la configuration des équipements et émule le comportement (au niveau IP) du filtrage et du routage pour permettre de lister les règles. À ce jour il interprète les règles de routeur Cisco, de pare-feu Cisco PIX/module FWSM et de Packet Filter (version OpenBSD >= 4.7) avec quelques limitations (voir la doc pour les limitations).
Par exemple, sur une config d'exemple (voir https://2011.jres.org/archives/108/index.htm), je veux savoir les règles appliquées avec une IP source 1.2.3.4 vers une IP 192.168.0.2 protocol TCP, port source dynamic (ie > 49152) et port destination http. La requête est :
lsfw> probe on R1|10.0.3.1 1.2.3.4 192.168.0.2 tcp dyn:http
-------- Routed probes --------
Path:
On: R1 (cisco router #1)
FastEthernet1/0 (internet)
interface IP: 10.0.3.1 network: 10.0.3.0/24
FastEthernet1/1 (INTERNAL)
interface IP: 10.0.1.254 network: 10.0.1.0/24
nexthop: 10.0.1.1
On: P1 (firewall #1)
em0 (em0)
interface IP: 10.0.1.1 network: 10.0.1.0/24
em1 (em1)
interface IP: 192.168.0.254 network: 192.168.0.0/24
nexthop: 192.168.0.0/24
R1 (cisco router #1)
Matching ACL on input: FastEthernet1/0 (internet)
ACCEPT r1-conf #34: [INTERNET_IN] permit ip any any
DENY [INTERNET_IN] *** implicit deny ***
Matching ACL on output: FastEthernet1/1 (INTERNAL)
ACCEPT r1-conf #69: [INTERNAL_OUT] permit ip any any
DENY [INTERNAL_OUT] *** implicit deny ***
P1 (firewall #1)
Matching ACL on input: em0 (em0)
DENY ./conf/pf.conf #26: block all
ACCEPT ./conf/pf.conf #33: pass proto tcp from any to 192.168.0.2 port { http, https }
Matching ACL on output: em1 (em1)
DENY ./conf/pf.conf #26: block all
ACCEPT ./conf/pf.conf #33: pass proto tcp from any to 192.168.0.2 port { http, https }
Global ACL result is: ACCEPT
Global routing result is: ROUTED
L'outil affiche le chemin, puis les règles qui matchent et enfin un diagnostic si ça passe ou non (Sachant que plus la requète est précise plus la réponse l'est)
Voilà grosso modo. Si vous êtes intéressé voir la doc :
https://listes.cru.fr/wiki/jtacl/index
Actuellement, je travaille plutôt coté références croisés et suite de tests (pour nos besoins internes).
Pour finir, l'outil est beaucoup utilisé au boulot. Ce qui fait qu'il est maintenu par rapport à notre config (et je ne promet rien pour les autres config, je ferais au mieux). je m'en suis aussi pas mal servi pour convertir des règles Cisco vers du bon Packet Filter, en contrôlant le résultat avec des tests de non régression.
Voili, voilou... Qu'en dites vous ? Je n'ai pas trouvé d'équivalent de ce soft pourtant bien utile (c'est libre, voir la licence).
# moi je trouve ça super
Posté par Christophe Turbout . Évalué à 10.
je plussoie cet outil qu'un étudiant de master que j'encadre est en train d'utiliser pour son projet d'année. Il doit faire une ihm et si ça fonctionne bien (croisons les doigts), on a prévu un patch à vous fournir ... mais j'attends de voir le résultat avant ...
l'idée : pouvoir via une interface web le mettre à dispo de correspondants pas forcément spécialistes du réseaux mais qui ont effectivement besoin de savoir que le port p est ouvert entre 2 machines qu'ils administrent sans téléphoner aux admins réseaux.
[^] # Re: moi je trouve ça super
Posté par Patrick Lamaizière (site web personnel) . Évalué à 2.
Merci pour le soutien !
On est intéressé ! On a le même besoin vis à vis de nos correspondants. L'outil n'est pas fait pour être mis dans les mains d'un utilisateur lamba et on a renoncé à ça (pas le temps). Mais ce serait utile.
N'hésitez pas à me contacter en privé si ça peut aider.
Perso mon prochain projet et d'effectuer un suivi administratif des règles et je compte pas mal sur l'outil comme vérificateur. Mais rien n'est encore fait, d'ailleurs si des gens ont bossé là dessus ou ont des pointeurs je prends.
les pixels au peuple !
# Firewalking
Posté par UnixJunkie . Évalué à 2.
Excellent projet! L'outil gère-t-il l'IPv6?
Pour une analyse "en aveugle", plus limitée mais ne nécessitant pas d'accès aux jeux de règles, il y a "firewalk", intégré à nmap, qui est très utile également.
[^] # Re: Firewalking
Posté par Patrick Lamaizière (site web personnel) . Évalué à 2.
Oui, ce serait dommage qu'un outil commencé en 2010 ne prenne pas ça en compte. Pour l'appli une adresse IP est un nombre avec un préfixe réseau (ie y'a pas de vraiment de différence entre une adresse IPv6 et IPv4, ou une adresse et un réseau, hormis les fourchettes acceptables).
Le moteur fonctionne avec l'ipv6, pour les équipements il y a quelques règles IPV6 prisent en compte pour les Cisco, Packet Filter devrait être OK en très grande partie.
Ceci dit comme on ne fait pas tellement d'IPv6, je n'ai pas trop testé ça et il y a sûrement quelques bugs. Ça n'empèche qu'on y échappera pas (à l'ipv6), alors pas de soucis pour corriger les pb à ce niveau.
Je vais regarder firewalk, connaissais pas merci.
les pixels au peuple !
# Souvenirs ...
Posté par ecid . Évalué à 1.
Bonjour,
Ça me rappelle ce que j'avais codé il y a quelques années pour du Firewall CheckPoint.
Les règles étaient tellement nombreuses et il y avait tellement d'objets que cet "outil" était indispensable. J'avais également pris en compte les "jokers"pour répondre à ce genre de questions:
- Qui peut accéder en http sur le serveur X?
- Quels sont les serveurs qui sont accessibles en ssh?
Ça permettait de rajouter des objets dans les règles au meilleur endroit plutôt que de recréer une règle supplémentaire. Le code (Perl) est malheureusement resté dans la boîte pour laquelle je bossais à l'époque. Le seul soft que j'avais trouvé et qui faisait de l'analyse sur les règles était celui d'algosec. Entre temps, il semble que d'autres soient arrivés sur ce créneau comme niiconsulting
[^] # Re: Souvenirs ...
Posté par Patrick Lamaizière (site web personnel) . Évalué à 2.
J'avais regardé pour faire de l'analyse des règles, ce serait intéressant mais je ne pense pas avoir le temps de jamais m'y pencher.
L'approche utilisée par l'appli est justement de ne pas analyser les règles, c'est complètement de la responsabilité de l'équipement émulé de se démerder, comme sur un vrai réseau ; ce qui fait que c'est très souple pour l'ajout d'équipement puisqu'il n'y a pas de prérequis. D'un autre coté ça ne facilite pas l'analyse à un niveau plus élevé.
les pixels au peuple !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.