Problème sur génération de règles de filtrage avec alias
-
Bonjour à tous
J'étais en train de tester une règle afin de renforcer la sécurité autour du DNS quand je suis tombé sur quelque chose "d'étrange".
Version :
2.1-BETA1 (i386)
built on Wed Dec 12 10:59:50 EST 2012
FreeBSD 8.3-RELEASE-p5Cette règle :
me génère dans rules.debug :[...] # User-defined rules follow anchor "userrules/*" block return in quick on $LAN inet proto { tcp udp } from 192.168.147.0/24 to 192.168.147.254 port 53 label "USER_RULE: DNS enforcing" pass in quick on $LAN inet from 192.168.147.0/24 to any keep state label "USER_RULE: Default allow LAN to any rule" # at the break! label "USER_RULE: Default allow LAN IPv6 to any rule" [...]alors que cette règle :
me génère :[...] # User-defined rules follow anchor "userrules/*" block return in quick on $LAN inet proto { tcp udp } from 192.168.147.0/24 to ! 192.168.147.254 port 53 label "USER_RULE: DNS enforcing" pass in quick on $LAN inet from 192.168.147.0/24 to any keep state label "USER_RULE: Default allow LAN to any rule" # at the break! label "USER_RULE: Default allow LAN IPv6 to any rule" [...]Est-ce normal ou est-ce un bug ? (notez la subtile différence au niveau du point d'exclamation dans la règle correspondante)
Le but de cette règle est d'empécher toute requète DNS vers un autre serveur que le pfsense.
Avec l'adresse IP en dur dans la règle, ça fonctionne bien, mais avec l'alias "LAN Address" ça me fait l'opposé (test avec nslookup et 8.8.8.8 comme DNS alternatif) -
Renforcer la sécurité en traitant la question du dns est certes une bonne idée. Tres paradoxal dans ce contexte puisque vous utilisez un vpn pptp qui repose sur un algorithme cassé (rc4) qui, de plus, a été mal implémenté par Microsoft. Ce problème me semble plus important encore que celui du dns.
Pour en revenir à votre post, vous etes sur une version beta ce qui implique des bugs potentiels importants. Avez vous consulté le forum dédié à cette version ?
Cela dit vos règles sont trop laxistes. Sur Lan interdisez tout par défaut … Sauf ce qui est explicitement autorisé comme udp/53 vers 192.168.147.254 et sans doute tcp/80, tcp/443. D'autres selon vos besoins et politique de sécurité. Et tout ira bien pour dns sous réserve que vos dns publics soient sûrs.
Utilisez plutôt reject que block pour tcp. -
Merci pour votre réponse
Ici le contexte est un environnement de test et non une machine de prod, donc effectivement les règles sont souples et pas rationnelles par rapport à ce que j'ai mis en oeuvre.
J'ai regardé, pfSense 2.0.1-RELEASE n'est pas affecté.
Ceci dit, une autre situation produit le même résultat :
me donnepass in quick on $DMZ1 inet from 172.16.147.254/24 to 192.168.147.0/24 keep state label "USER_RULE: Allow DMZ1 to WAN IPv4" # at the break! label "USER_RULE: Allow DMZ1 to WAN IPv6"La fonction "Not" dans la page de création de règles semble ne pas fonctionner comme il se doit visiblement.
Je vais continuer de chercher dans le forum de la v2.1.0 s'il n'ya pas d'infos là-dessus.
Je jetterai un oeil sur la redmine aussi -
Plutôt que l'opérateur !, je préfère les 2 règles à suivre :
- Block règle vers LAN
- Pass règle vers any
Cela fait certes 2 règles mais je suis sûr du résultat.
-
JDH propose une soution très intéressante : elle contourne le problème et apporte une autre possibilité :
Remplacer ce genre de règle :
par ça :
Permet de logger seulement les erreurs sans se retrouver avec un journal qui explose à cause des flux autorisés.
Merci JDH ;)