Je suis en train de m'arracher les cheveux sur le comportement d'une
règle de filtrage de PF. Je relis en boucle le manuel et je ne
comprends toujours pas. J'aimerais avoir une explication formulée
autrement.
J'ai deux machines, et un pare-feu sous OpenBSD au milieu. Je
voudrais écrire des règles PF pour pouvoir me connecter d'une machine
à l'autre en SSH.
Avec cette règle-ci, j'arrive à me connecter:
pass out quick from $prv_hosts to $dmz_hosts flags S/SA modulate state
mais pas avec celle-ci:
pass in quick from $prv_hosts to $dmz_hosts flags S/SA modulate state
Je suis en train de m'arracher les cheveux sur le comportement d'une
règle de filtrage de PF. Je relis en boucle le manuel et je ne
comprends toujours pas. J'aimerais avoir une explication formulée
autrement.
J'ai deux machines, et un pare-feu sous OpenBSD au milieu. Je
voudrais écrire des règles PF pour pouvoir me connecter d'une machine
à l'autre en SSH.
Avec cette règle-ci, j'arrive à me connecter:
pass out quick from $prv_hosts to $dmz_hosts flags S/SA modulate state
mais pas avec celle-ci:
pass in quick from $prv_hosts to $dmz_hosts flags S/SA modulate state
Je suis en train de m'arracher les cheveux sur le comportement d'une
règle de filtrage de PF. Je relis en boucle le manuel et je ne
comprends toujours pas. J'aimerais avoir une explication formulée
autrement.
J'ai deux machines, et un pare-feu sous OpenBSD au milieu. Je
voudrais écrire des règles PF pour pouvoir me connecter d'une machine
à l'autre en SSH.
Avec cette règle-ci, j'arrive à me connecter:
pass out quick from $prv_hosts to $dmz_hosts flags S/SA modulate state
mais pas avec celle-ci:
pass in quick from $prv_hosts to $dmz_hosts flags S/SA modulate state
Note que je ne suis pas sur d'avoir bien compris ; soyons plus clair :
Cette règle ne s'applique donc qu'à if1, elle est équivalente à :
pass out quick on if1 from $prv_hosts to $dmz_hosts
flags S/SA modulate state
Tout dépend de ce que tu as avant ; si tu a un « block all » en début
de configuration, je doute que cette règle suffise pour que ça
fonctionne car le paquet ne rentrera pas dans FW via if0.
Si tu veux que A puisse accéder à B sur le port ssh :
pass from if0:network to if1:network proto tcp port ssh keep state
Note que je ne suis pas sur d'avoir bien compris ; soyons plus clair :
Cette règle ne s'applique donc qu'à if1, elle est équivalente à :
pass out quick on if1 from $prv_hosts to $dmz_hosts
flags S/SA modulate state
Tout dépend de ce que tu as avant ; si tu a un « block all » en début
de configuration, je doute que cette règle suffise pour que ça
fonctionne car le paquet ne rentrera pas dans FW via if0.
Si tu veux que A puisse accéder à B sur le port ssh :
pass from if0:network to if1:network proto tcp port ssh keep state
Note que je ne suis pas sur d'avoir bien compris ; soyons plus clair :
Cette règle ne s'applique donc qu'à if1, elle est équivalente à :
pass out quick on if1 from $prv_hosts to $dmz_hosts
flags S/SA modulate state
Tout dépend de ce que tu as avant ; si tu a un « block all » en début
de configuration, je doute que cette règle suffise pour que ça
fonctionne car le paquet ne rentrera pas dans FW via if0.
Si tu veux que A puisse accéder à B sur le port ssh :
pass from if0:network to if1:network proto tcp port ssh keep state
Quand on filtre sur « in » ou « out », il faut que le paquet, en
plus du match sur la règle « in » ou « out », puisse traverser l'autre
interface.
Quand on filtre sur « in » ou « out », il faut que le paquet, en
plus du match sur la règle « in » ou « out », puisse traverser l'autre
interface.
Quand on filtre sur « in » ou « out », il faut que le paquet, en
plus du match sur la règle « in » ou « out », puisse traverser l'autre
interface.
$prv_hosts $dmz_hosts
+-------+ +----+ +-------+
|Machine|____________| FW |____________|Machine|
| A | $prv_if| |$dmz_if | B |
+-------+ +----+ +-------+Cette règle ne s'applique donc qu'à if1, elle est équivalente à :
pass out quick on if1 from $prv_hosts to $dmz_hosts
flags S/SA modulate state
Je m'aperçois que j'aurais pu encore simplifier les règles que je
donnais. Disons:
pass out quick on $dmz_if from $prv_hosts to $dmz_hosts keep stateTout dépend de ce que tu as avant ; si tu a un « block all » en début
de configuration, je doute que cette règle suffise pour que ça
fonctionne car le paquet ne rentrera pas dans FW via if0.
Oui, j'ai effectivement un « block in all », qui, dans ce sens, fait
comme tu dis. Pour essayer de comprendre, j'ai réduit mon pf.conf à sa
plus simple expression, et je n'ai plus que ces deux règles.
Je pense comprendre ce que tu expliques. Quand on filtre sur « in »
ou « out », il faut que le paquet, en plus du match sur la règle « in »
ou « out », puisse traverser l'autre interface.
Si tu veux que A puisse accéder à B sur le port ssh :
pass from if0:network to if1:network proto tcp port ssh keep state
Effectivement, ça marche. Mais j'aimais bien le contrôle de
l'interface d'entrée; ça me paraît être une donnée parfaitement fiable
(puisque c'est le pare-feu qui la génère, et non le paquet qui
l'apporte). Est-ce qu'il y a un moyen de faire quand même ce contrôle.
J'ai écrit ça, qui marche, mais ça oblige à passer par des tags, ce
qui me semble bien compliqué pour un problème simple:
pass in on $prv_if from $prv_hosts to any tag FROM_PRV
block return all
pass from $prv_hosts to $dmz_hosts tagged FROM_PRV keep state
$prv_hosts $dmz_hosts
+-------+ +----+ +-------+
|Machine|____________| FW |____________|Machine|
| A | $prv_if| |$dmz_if | B |
+-------+ +----+ +-------+
Cette règle ne s'applique donc qu'à if1, elle est équivalente à :
pass out quick on if1 from $prv_hosts to $dmz_hosts
flags S/SA modulate state
Je m'aperçois que j'aurais pu encore simplifier les règles que je
donnais. Disons:
pass out quick on $dmz_if from $prv_hosts to $dmz_hosts keep state
Tout dépend de ce que tu as avant ; si tu a un « block all » en début
de configuration, je doute que cette règle suffise pour que ça
fonctionne car le paquet ne rentrera pas dans FW via if0.
Oui, j'ai effectivement un « block in all », qui, dans ce sens, fait
comme tu dis. Pour essayer de comprendre, j'ai réduit mon pf.conf à sa
plus simple expression, et je n'ai plus que ces deux règles.
Je pense comprendre ce que tu expliques. Quand on filtre sur « in »
ou « out », il faut que le paquet, en plus du match sur la règle « in »
ou « out », puisse traverser l'autre interface.
Si tu veux que A puisse accéder à B sur le port ssh :
pass from if0:network to if1:network proto tcp port ssh keep state
Effectivement, ça marche. Mais j'aimais bien le contrôle de
l'interface d'entrée; ça me paraît être une donnée parfaitement fiable
(puisque c'est le pare-feu qui la génère, et non le paquet qui
l'apporte). Est-ce qu'il y a un moyen de faire quand même ce contrôle.
J'ai écrit ça, qui marche, mais ça oblige à passer par des tags, ce
qui me semble bien compliqué pour un problème simple:
pass in on $prv_if from $prv_hosts to any tag FROM_PRV
block return all
pass from $prv_hosts to $dmz_hosts tagged FROM_PRV keep state
$prv_hosts $dmz_hosts
+-------+ +----+ +-------+
|Machine|____________| FW |____________|Machine|
| A | $prv_if| |$dmz_if | B |
+-------+ +----+ +-------+Cette règle ne s'applique donc qu'à if1, elle est équivalente à :
pass out quick on if1 from $prv_hosts to $dmz_hosts
flags S/SA modulate state
Je m'aperçois que j'aurais pu encore simplifier les règles que je
donnais. Disons:
pass out quick on $dmz_if from $prv_hosts to $dmz_hosts keep stateTout dépend de ce que tu as avant ; si tu a un « block all » en début
de configuration, je doute que cette règle suffise pour que ça
fonctionne car le paquet ne rentrera pas dans FW via if0.
Oui, j'ai effectivement un « block in all », qui, dans ce sens, fait
comme tu dis. Pour essayer de comprendre, j'ai réduit mon pf.conf à sa
plus simple expression, et je n'ai plus que ces deux règles.
Je pense comprendre ce que tu expliques. Quand on filtre sur « in »
ou « out », il faut que le paquet, en plus du match sur la règle « in »
ou « out », puisse traverser l'autre interface.
Si tu veux que A puisse accéder à B sur le port ssh :
pass from if0:network to if1:network proto tcp port ssh keep state
Effectivement, ça marche. Mais j'aimais bien le contrôle de
l'interface d'entrée; ça me paraît être une donnée parfaitement fiable
(puisque c'est le pare-feu qui la génère, et non le paquet qui
l'apporte). Est-ce qu'il y a un moyen de faire quand même ce contrôle.
J'ai écrit ça, qui marche, mais ça oblige à passer par des tags, ce
qui me semble bien compliqué pour un problème simple:
pass in on $prv_if from $prv_hosts to any tag FROM_PRV
block return all
pass from $prv_hosts to $dmz_hosts tagged FROM_PRV keep state
Dans la règle si dessus il est dit de laisser passer les paquets du
réseau attaché à l'interface if0 vers le réseau attaché à l'interface
if1.
prv_hosts=$prv_if:network
dmz_hosts=$dmz_if:network
# ifconfig pflog0 up
# tcpdump ${others_options} -i pflog0
Dans tous les cas, je te conseille vivement la lecture de
<http://www.bgnett.no/~peter/pf/>.
Dans la règle si dessus il est dit de laisser passer les paquets du
réseau attaché à l'interface if0 vers le réseau attaché à l'interface
if1.
prv_hosts=$prv_if:network
dmz_hosts=$dmz_if:network
# ifconfig pflog0 up
# tcpdump ${others_options} -i pflog0
Dans tous les cas, je te conseille vivement la lecture de
<http://www.bgnett.no/~peter/pf/>.
Dans la règle si dessus il est dit de laisser passer les paquets du
réseau attaché à l'interface if0 vers le réseau attaché à l'interface
if1.
prv_hosts=$prv_if:network
dmz_hosts=$dmz_if:network
# ifconfig pflog0 up
# tcpdump ${others_options} -i pflog0
Dans tous les cas, je te conseille vivement la lecture de
<http://www.bgnett.no/~peter/pf/>.
imagine une machine comme la mienne, avec quatre interfaces :
Ce qui est autorisé à rentrer par une interface n'est pas autorisé à
ressortir n'importe par n'importe quelle interface.
ce qui arrive vu que j'ai placé le serveur NTP sur la passerelle (je
sais, c'est mal).
Le mieux, selon moi, c'est de ne filtrer que sur le 'in' et de laisser
les TAG faire le reste.
pass in quick from $prv_hosts to $dmz_hosts tag PERMIT flags S/SA
modulate state [les autres règles]
block return in log quick from $prv_hosts to any
block return in quick all
pass out quick all tagged PERMIT
[Les règles "out" spécifiques à la passerelle (NTP, plus FTP, HTTP et CVS
pour les mises à jour)]
block return out quick all
Au final, excepté pour ce qui concerne la machine elle-même, tu n'as que
des règles "in". De cette façon, la maintenance est largement
simplifiée, puisque tu ne risques pas d'oublier de modifier la règle
"out" associée, et parce que la lecture de l'ensemble est beaucoup plus
facile.
imagine une machine comme la mienne, avec quatre interfaces :
Ce qui est autorisé à rentrer par une interface n'est pas autorisé à
ressortir n'importe par n'importe quelle interface.
ce qui arrive vu que j'ai placé le serveur NTP sur la passerelle (je
sais, c'est mal).
Le mieux, selon moi, c'est de ne filtrer que sur le 'in' et de laisser
les TAG faire le reste.
pass in quick from $prv_hosts to $dmz_hosts tag PERMIT flags S/SA
modulate state [les autres règles]
block return in log quick from $prv_hosts to any
block return in quick all
pass out quick all tagged PERMIT
[Les règles "out" spécifiques à la passerelle (NTP, plus FTP, HTTP et CVS
pour les mises à jour)]
block return out quick all
Au final, excepté pour ce qui concerne la machine elle-même, tu n'as que
des règles "in". De cette façon, la maintenance est largement
simplifiée, puisque tu ne risques pas d'oublier de modifier la règle
"out" associée, et parce que la lecture de l'ensemble est beaucoup plus
facile.
imagine une machine comme la mienne, avec quatre interfaces :
Ce qui est autorisé à rentrer par une interface n'est pas autorisé à
ressortir n'importe par n'importe quelle interface.
ce qui arrive vu que j'ai placé le serveur NTP sur la passerelle (je
sais, c'est mal).
Le mieux, selon moi, c'est de ne filtrer que sur le 'in' et de laisser
les TAG faire le reste.
pass in quick from $prv_hosts to $dmz_hosts tag PERMIT flags S/SA
modulate state [les autres règles]
block return in log quick from $prv_hosts to any
block return in quick all
pass out quick all tagged PERMIT
[Les règles "out" spécifiques à la passerelle (NTP, plus FTP, HTTP et CVS
pour les mises à jour)]
block return out quick all
Au final, excepté pour ce qui concerne la machine elle-même, tu n'as que
des règles "in". De cette façon, la maintenance est largement
simplifiée, puisque tu ne risques pas d'oublier de modifier la règle
"out" associée, et parce que la lecture de l'ensemble est beaucoup plus
facile.
Avec les règles d'antispoofing, il y a de bonnes chances que les
filtrages sur « les IP du réseau attaché à l'interface » et sur « la
traversée de l'interface » donnent la même chose, mais, qui sait, un
paquet habilement forgé pourrait ne pas être bloqué par « antispoof ».
prv_hosts=$prv_if:network
dmz_hosts=$dmz_if:network
J'ai même des listes d'IP beaucoup plus restrictives pour les
différents sous-réseaux.
Je ne sais plus si c'est ce document ou le livre de Jacek Artymiak
qui conseille de ne considérer que le côté « in » ou « out » du
routeur, mais pas les deux. Ce conseil est peut-être finalement
fondé. ;)
Avec les règles d'antispoofing, il y a de bonnes chances que les
filtrages sur « les IP du réseau attaché à l'interface » et sur « la
traversée de l'interface » donnent la même chose, mais, qui sait, un
paquet habilement forgé pourrait ne pas être bloqué par « antispoof ».
prv_hosts=$prv_if:network
dmz_hosts=$dmz_if:network
J'ai même des listes d'IP beaucoup plus restrictives pour les
différents sous-réseaux.
Je ne sais plus si c'est ce document ou le livre de Jacek Artymiak
qui conseille de ne considérer que le côté « in » ou « out » du
routeur, mais pas les deux. Ce conseil est peut-être finalement
fondé. ;)
Avec les règles d'antispoofing, il y a de bonnes chances que les
filtrages sur « les IP du réseau attaché à l'interface » et sur « la
traversée de l'interface » donnent la même chose, mais, qui sait, un
paquet habilement forgé pourrait ne pas être bloqué par « antispoof ».
prv_hosts=$prv_if:network
dmz_hosts=$dmz_if:network
J'ai même des listes d'IP beaucoup plus restrictives pour les
différents sous-réseaux.
Je ne sais plus si c'est ce document ou le livre de Jacek Artymiak
qui conseille de ne considérer que le côté « in » ou « out » du
routeur, mais pas les deux. Ce conseil est peut-être finalement
fondé. ;)
Si l'on commence à douter la dessus, on peut aussi se dire qu'un autre
paquet encore plus habilement forgé va contourner la règle block et
ainsi de suite... Faudrait pas tomber dans la paranoïa non plus. ;-)
Généralement on dit que le filtrage des flux sortants ne sert à rien
d'autre que de créer des problèmes.
Si l'on commence à douter la dessus, on peut aussi se dire qu'un autre
paquet encore plus habilement forgé va contourner la règle block et
ainsi de suite... Faudrait pas tomber dans la paranoïa non plus. ;-)
Généralement on dit que le filtrage des flux sortants ne sert à rien
d'autre que de créer des problèmes.
Si l'on commence à douter la dessus, on peut aussi se dire qu'un autre
paquet encore plus habilement forgé va contourner la règle block et
ainsi de suite... Faudrait pas tomber dans la paranoïa non plus. ;-)
Généralement on dit que le filtrage des flux sortants ne sert à rien
d'autre que de créer des problèmes.
Le mieux, selon moi, c'est de ne filtrer que sur le 'in' et de laisser
les TAG faire le reste.
Donc tu confirmes que pour filtrer confortablement sur les interfaces,
on est plus ou moins obligé de jouer avec les tags?
pass in quick from $prv_hosts to $dmz_hosts tag PERMIT flags S/SA
modulate state [les autres règles]
block return in log quick from $prv_hosts to any
block return in quick all
pass out quick all tagged PERMIT
[Les règles "out" spécifiques à la passerelle (NTP, plus FTP, HTTP et CVS
pour les mises à jour)]
block return out quick all
Ne serait-il pas plus fin de stocker dans le tag le nom de l'interface
d'entrée, plutôt que simplement l'autorisation de sortie? Je pense par
exemple à des règles qui commenceraient par:
pass in on $prv_if from $prv_hosts to any tag PRV
pass in on $dmz_if from $dmz_hosts to any tag DMZ
pass in on $ext_if from any to any tag EXT
block in all
Merci.
Le mieux, selon moi, c'est de ne filtrer que sur le 'in' et de laisser
les TAG faire le reste.
Donc tu confirmes que pour filtrer confortablement sur les interfaces,
on est plus ou moins obligé de jouer avec les tags?
pass in quick from $prv_hosts to $dmz_hosts tag PERMIT flags S/SA
modulate state [les autres règles]
block return in log quick from $prv_hosts to any
block return in quick all
pass out quick all tagged PERMIT
[Les règles "out" spécifiques à la passerelle (NTP, plus FTP, HTTP et CVS
pour les mises à jour)]
block return out quick all
Ne serait-il pas plus fin de stocker dans le tag le nom de l'interface
d'entrée, plutôt que simplement l'autorisation de sortie? Je pense par
exemple à des règles qui commenceraient par:
pass in on $prv_if from $prv_hosts to any tag PRV
pass in on $dmz_if from $dmz_hosts to any tag DMZ
pass in on $ext_if from any to any tag EXT
block in all
Merci.
Le mieux, selon moi, c'est de ne filtrer que sur le 'in' et de laisser
les TAG faire le reste.
Donc tu confirmes que pour filtrer confortablement sur les interfaces,
on est plus ou moins obligé de jouer avec les tags?
pass in quick from $prv_hosts to $dmz_hosts tag PERMIT flags S/SA
modulate state [les autres règles]
block return in log quick from $prv_hosts to any
block return in quick all
pass out quick all tagged PERMIT
[Les règles "out" spécifiques à la passerelle (NTP, plus FTP, HTTP et CVS
pour les mises à jour)]
block return out quick all
Ne serait-il pas plus fin de stocker dans le tag le nom de l'interface
d'entrée, plutôt que simplement l'autorisation de sortie? Je pense par
exemple à des règles qui commenceraient par:
pass in on $prv_if from $prv_hosts to any tag PRV
pass in on $dmz_if from $dmz_hosts to any tag DMZ
pass in on $ext_if from any to any tag EXT
block in all
Merci.
Généralement on dit que le filtrage des flux sortants ne sert à rien
d'autre que de créer des problèmes.
On dirait qu'il peut aussi servir aussi à montrer qu'on n'a pas tout
compris au filtrage...
Généralement on dit que le filtrage des flux sortants ne sert à rien
d'autre que de créer des problèmes.
On dirait qu'il peut aussi servir aussi à montrer qu'on n'a pas tout
compris au filtrage...
Généralement on dit que le filtrage des flux sortants ne sert à rien
d'autre que de créer des problèmes.
On dirait qu'il peut aussi servir aussi à montrer qu'on n'a pas tout
compris au filtrage...