[freebsd] regles pf qui ne chargent pas au boot

Le
patpro ~ patrick proniewski
Bonjour,

J'ai un serveur FreeBSD 8.2 qui fonctionne correctement, à part quelques
petits points de détail.
Entre autres choses, si je le reboote, les règles du firewall PF ne sont
pas chargée quand le système démarre.

J'ai pourtant bien ces lignes dans mon /etc/rc.conf :

pf_enable="YES" # Set to YES to enable packet filter (pf)
pflog_enable="YES" # Set to YES to enable packet filter logging

Après reboot, j'ai ça :

# pfctl -s all
No ALTQ support in kernel
ALTQ related functions disabled
FILTER RULES:

INFO:
Status: Enabled for 3 days 01:46:57 Debug: Urgent

State Table Total Rate
current entries 0
searches 43387599 163.3/s
inserts 0 0.0/s
removals 0 0.0/s
Counters
match 43387599 163.3/s
bad-offset 0 0.0/s
fragment 0 0.0/s

OS FINGERPRINTS:
696 fingerprints loaded


Alors que bien sûr, j'ai un paquet de règles dans mon /etc/pf.conf.
Je n'ai rien trouvé dans le dmesg.boot, dans messages, ni ailleurs.

Une idée ?

patpro

--
A vendre : KVM IP 16 ports APC
http://patpro.net/blog/index.php/2008/01/12/133
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Paul Gaborit
Le #24048421
À (at) Fri, 09 Dec 2011 00:05:42 +0100,
patpro ~ patrick proniewski
J'ai un serveur FreeBSD 8.2 qui fonctionne correctement, à part quelques
petits points de détail.
Entre autres choses, si je le reboote, les règles du firewall PF ne sont
pas chargée quand le système démarre.

J'ai pourtant bien ces lignes dans mon /etc/rc.conf :

pf_enable="YES" # Set to YES to enable packet filter (pf)
pflog_enable="YES" # Set to YES to enable packet filter logging


[...]

Une idée ?



Ici, ça marche avec juste la ligne suivante en sus :

pf_rules="/etc/pf.conf" # rules definition file for pf

Mais, a priori, c'est le réglage par défaut.

Que se passe-t-il après un restart de pf (via /etc/rc.d/pf) ?

--
Paul Gaborit -
patpro ~ patrick proniewski
Le #24048501
In article Paul Gaborit
À (at) Fri, 09 Dec 2011 00:05:42 +0100,
patpro ~ patrick proniewski
> J'ai un serveur FreeBSD 8.2 qui fonctionne correctement, à part quelques
> petits points de détail.
> Entre autres choses, si je le reboote, les règles du firewall PF ne sont
> pas chargée quand le système démarre.
>
> J'ai pourtant bien ces lignes dans mon /etc/rc.conf :
>
> pf_enable="YES" # Set to YES to enable packet filter (pf)
> pflog_enable="YES" # Set to YES to enable packet filter logging
[...]
>
> Une idée ?

Ici, ça marche avec juste la ligne suivante en sus :

pf_rules="/etc/pf.conf" # rules definition file for pf

Mais, a priori, c'est le réglage par défaut.




Je l'ai ajouté, mais ça ne change rien. Au redémarrage, pf ne charge
toujours pas les règles, mais il est par contre bien activé.

Que se passe-t-il après un restart de pf (via /etc/rc.d/pf) ?



si je lance manuellement /etc/rc.d/pf, les règles sont chargées
correctement.

Est-il envisageable que l'ensemble des IP de la machine ne soit pas
disponible au moment où pf tente de charger les règles pendant le boot ?
C'est un serveur web qui dispose de 40 adresses IP.
39 sont sur une ligne ipv4_addrs_em0="..." et 1 est sur une ligne
ipv4_addrs_em1="..."

patpro

--
A vendre : KVM IP 16 ports APC
http://patpro.net/blog/index.php/2008/01/12/133
Paul Gaborit
Le #24049101
À (at) Fri, 09 Dec 2011 07:17:37 +0100,
patpro ~ patrick proniewski

Est-il envisageable que l'ensemble des IP de la machine ne soit pas
disponible au moment où pf tente de charger les règles pendant le boot
?



C'est possible (et même courant si on utilise DHCP par exemple) mais, à
mon avis, sans aucune importance puisqu'on peut même utiliser des
interfaces inexistantes dans les règles. PF charge quand même la règle
et, si l'interface vient à exister, elle sera appliquée.

C'est un serveur web qui dispose de 40 adresses IP.
39 sont sur une ligne ipv4_addrs_em0="..." et 1 est sur une ligne
ipv4_addrs_em1="..."



Belle collection d'IP ! Mais franchement, je ne vois pas en quoi cela
pourrait jouer.

En activant le debug au niveau loud (dans pf.conf), PF sera sûrement
plus causant au boot...

--
Paul Gaborit -
patpro ~ Patrick Proniewski
Le #24049671
In article Paul Gaborit
À (at) Fri, 09 Dec 2011 07:17:37 +0100,
patpro ~ patrick proniewski

> Est-il envisageable que l'ensemble des IP de la machine ne soit pas
> disponible au moment où pf tente de charger les règles pendant le boot
> ?

C'est possible (et même courant si on utilise DHCP par exemple) mais, à
mon avis, sans aucune importance puisqu'on peut même utiliser des
interfaces inexistantes dans les règles. PF charge quand même la règle
et, si l'interface vient à exister, elle sera appliquée.

> C'est un serveur web qui dispose de 40 adresses IP.
> 39 sont sur une ligne ipv4_addrs_em0="..." et 1 est sur une ligne
> ipv4_addrs_em1="..."

Belle collection d'IP ! Mais franchement, je ne vois pas en quoi cela
pourrait jouer.



moi non plus, mais c'est la seule machine que j'ai qui présente ce
problème, et en prime c'est la seule qui utilise la syntaxe
ipv4_addrs_em0="..." dans son rc.conf pour les interfaces réseau

En activant le debug au niveau loud (dans pf.conf), PF sera sûrement
plus causant au boot...



hmmm le problème c'est de pouvoir lire ces messages. En fait, le
chargement de PF se fait après la fin de ce que je trouve dans le dmesg.
Il y a un moyen de récupérer ce qui est affiché à la console dans un
fichier de log ?

patpro

--
Je cherche à changer d'air -> http://www.patpro.net/cv
Eric Masson
Le #24049711
patpro ~ Patrick Proniewski
'Lut,

hmmm le problème c'est de pouvoir lire ces messages. En fait, le
chargement de PF se fait après la fin de ce que je trouve dans le dmesg.
Il y a un moyen de récupérer ce qui est affiché à la console dans un
fichier de log ?



dmesg -a ne résoudrait pas ton problème, des fois ?

--
<<Article 6.2 : L'abonné s'engage à conserver secret les éléments
constitutifs de son identification (nom d'utilisateur, mot de passe de
connexion, adresse e-mail, mot de passe de messagerie).
-+- FAI in : GNU - Mon adresse email est classée secret-défense -+-
patpro ~ Patrick Proniewski
Le #24049851
In article Eric Masson
patpro ~ Patrick Proniewski
'Lut,

> hmmm le problème c'est de pouvoir lire ces messages. En fait, le
> chargement de PF se fait après la fin de ce que je trouve dans le dmesg.
> Il y a un moyen de récupérer ce qui est affiché à la console dans un
> fichier de log ?

dmesg -a ne résoudrait pas ton problème, des fois ?



complètement. Ma blonditude m'a rattrapé, ça m'apprendra à pas lire le
man.

Et donc, le mystère est levé :

---------------------------
Starting pflog.
Enabling pf
Dec 9 07:12:39 pflogd[486]: NSSWITCH(_nsdispatch): ldap, passwd,
endpwent, not found, and no fallback provided
No ALTQ support in kernel
ALTQ related functions disabled
Dec 9 07:12:39 pflogd[486]: [priv]: msg PRIV_OPEN_LOG received
no IP address found for smtp.univ-lyon2.fr
/etc/pf.conf:60:
could not parse host specification

pfctl:
Syntax error in config file: pf rules not loaded

No ALTQ support in kernel
ALTQ related functions disabled
No ALTQ support in kernel
ALTQ related functions disabled
pf enabled
---------------------------

La ligne du pf.conf incriminée est :

pass out log quick proto tcp from any to smtp.univ-lyon2.fr port 25 user
80 keep state label " to smtp:25 output"

Visiblement, si ça résout pas au moment du boot, c'est cuit. Je vais
remplacer par l'IP, mais c'est un peu relou.

patpro

--
Je cherche à changer d'air -> http://www.patpro.net/cv
Eric Masson
Le #24049961
patpro ~ Patrick Proniewski
'Lut,

Visiblement, si ça résout pas au moment du boot, c'est cuit. Je vais
remplacer par l'IP, mais c'est un peu relou.



Il te faudrait une config pf minimaliste au boot que tu étendrais une
fois que la résolution dns serait opérationnelle, ce serait plus propre.

--
svp un site pour mesurer mon debit de merde ?
-+- G in GNU : Le retour de la pompe à merde -+-
Paul Gaborit
Le #24050321
À (at) Fri, 09 Dec 2011 14:57:11 +0100,
patpro ~ Patrick Proniewski
La ligne du pf.conf incriminée est :

pass out log quick proto tcp from any to smtp.univ-lyon2.fr port 25 user
80 keep state label " to smtp:25 output"

Visiblement, si ça résout pas au moment du boot, c'est cuit. Je vais
remplacer par l'IP, mais c'est un peu relou.



C'est peut-être "relou" mais c'est sain.

Là, vos règlages firewall dépendent d'une réponse DNS. Ce DNS est-il
sécurisé ? Fiable ? Que faire si l'adresse IP change ? etc.

L'adresse IP fixe est quand même bien plus sûr. ;-)

Un moyen de répondre au besoin : utiliser une table à la place du nom et
mettre à jour cette table après le boot (une fois que le DNS répond
correctement) et de manière régulière (si l'adresse change)...

--
Paul Gaborit -
Paul Gaborit
Le #24050311
À (at) Fri, 09 Dec 2011 15:33:27 +0100,
Eric Masson
patpro ~ Patrick Proniewski
'Lut,

Visiblement, si ça résout pas au moment du boot, c'est cuit. Je vais
remplacer par l'IP, mais c'est un peu relou.



Il te faudrait une config pf minimaliste au boot que tu étendrais une
fois que la résolution dns serait opérationnelle, ce serait plus propre.



Je viens de trouver une discussion de 2007 qui suggère aussi une
solution de ce genre :


--
Paul Gaborit -
patpro ~ Patrick Proniewski
Le #24050191
In article Eric Masson
patpro ~ Patrick Proniewski
'Lut,

> Visiblement, si ça résout pas au moment du boot, c'est cuit. Je vais
> remplacer par l'IP, mais c'est un peu relou.

Il te faudrait une config pf minimaliste au boot que tu étendrais une
fois que la résolution dns serait opérationnelle, ce serait plus propre.



C'est une solution mais j'aime les choses simples ;)
Puis bon, je maitrise les IP que j'ai mises en dur dans la conf, je ne
dépend pas d'autres personnes qui pourraient par exemple changer l'IP du
smtp.

patpro

--
Je cherche à changer d'air -> http://www.patpro.net/cv
Publicité
Poster une réponse
Anonyme