Je suis en train de réfléchir à la migration de ma gateway/firewall sous
Linux à OpenBSD. L'essentiel de ce travail consiste à porter le jeu de
règles Netfilter vers pf. J'ai (pour l'instant) deux questions.
QUESTION 1)
-----------
Mon architecture réseau ressemble à ceci :
LAN ---- LAN_IF [OpenBSD] EXT_IF ---- (Internet)
En lisant la documentation et les quelques exemples qu'elle contient* je
ne parviens pas à déterminer comment autoriser la trafic sortant du LAN
(et de la DMZ, mais la syntaxe sera la même). Laquelle de ces deux
règles faut il utiliser ?
pass in quick on $LAN_IF inet proto tcp from ($LAN_IF:network) \
to any port xyz modulate state
pass out quick on $EXT_IF inet proto tcp from ($LAN_IF:network) \
to any port xyz modulate state
QUESTION 2)
-----------
Quelles sont vraiment les différences entre les options "antispoof" et
"urpf-failed" ?
J'ai lu la doc et pour ce que j'en comprend, les deux font la même choses.
*je trouve d'ailleurs qu'il y a sur Internet bien plus de jeux de règles
Netfilter que pf pour assister le débutant, si vous connaissez quelques
liens qui pourraient m'aider...
*je trouve d'ailleurs qu'il y a sur Internet bien plus de jeux de règles Netfilter que pf pour assister le débutant, si vous connaissez quelques liens qui pourraient m'aider...
Un bon point de départ : http://home.nuug.no/~peter/pf/
-- DW
Bonjour,
*je trouve d'ailleurs qu'il y a sur Internet bien plus de jeux de
règles Netfilter que pf pour assister le débutant, si vous connaissez
quelques liens qui pourraient m'aider...
Un bon point de départ :
http://home.nuug.no/~peter/pf/
*je trouve d'ailleurs qu'il y a sur Internet bien plus de jeux de règles Netfilter que pf pour assister le débutant, si vous connaissez quelques liens qui pourraient m'aider...
Un bon point de départ : http://home.nuug.no/~peter/pf/
-- DW
Stephane Catteau
François RONVAUX devait dire quelque chose comme ceci :
QUESTION 1) -----------
Mon architecture réseau ressemble à ceci :
LAN ---- LAN_IF [OpenBSD] EXT_IF ---- (Internet)
En lisant la documentation et les quelques exemples qu'elle contient* je ne parviens pas à déterminer comment autoriser la trafic sortant du LAN (et de la DMZ, mais la syntaxe sera la même). Laquelle de ces deux règles faut il utiliser ?
pass in quick on $LAN_IF inet proto tcp from ($LAN_IF:network) to any port xyz modulate state
pass out quick on $EXT_IF inet proto tcp from ($LAN_IF:network) to any port xyz modulate state
Les deux, et je m'étonne que ce puisse être différent avec netfilter.
Lorsque les paquets en provenance du LAN arrivent sur ta passerelle, elles doivent être autorisées à entrer dans la machine, c'est le "pass in on $EXT_LAN" qui permettra cela. Mais comme le paquet ne fait que traverser la machine pour partir ensuite vers le vaste monde, il faut aussi que tu lui donnes l'autorisation de sortir de celle ci, d'où le "pass out on $EXT_IF".
Cela étant dit, la meilleure solution que j'ai trouvée consiste à utiliser les tags :
# Laisser entrer sur la passerelle ce qui peut sortir pass in quick on $EXT_LAN [ce que tu veux] tag ITS_OK # bloquer tout le reste block quick on $EXT_LAN all
# Laisser sortir tout ce qui a eu le droit d'entrer pass out quick all tagged ITS_OK keep state
Du coup tes règles ne s'occupent que des paquets entrant sur la passerelle, ce qui t'évite d'avoir à tout doubler, et donc à multiplier les risques d'erreurs humaines. Au passage, note qu'il ne faut pas mentionner l'interface pour la règle "pass out", ce qui te permet d'avoir une seule règle valable pour tous les cas de figure (connexions "LAN -> vaste monde", connexions "vaste monde -> LAN" et même chose pour la DMZ). A toi de faire la différence dans les règles en entrée.
*je trouve d'ailleurs qu'il y a sur Internet bien plus de jeux de règles Netfilter que pf pour assister le débutant, [...]
Parce qu'il y a aussi largement plus d'utilisateur de Netfilter que d'utilisateur de pf.
Merci d'avance pour vos réponses.
De rien. Cela dit, tu aurais sans doute plus de réponses sur fr.comp.securite (pis ça ferait un peu de signal en-charte pour changer)
François RONVAUX devait dire quelque chose comme ceci :
QUESTION 1)
-----------
Mon architecture réseau ressemble à ceci :
LAN ---- LAN_IF [OpenBSD] EXT_IF ---- (Internet)
En lisant la documentation et les quelques exemples qu'elle contient* je
ne parviens pas à déterminer comment autoriser la trafic sortant du LAN
(et de la DMZ, mais la syntaxe sera la même). Laquelle de ces deux
règles faut il utiliser ?
pass in quick on $LAN_IF inet proto tcp from ($LAN_IF:network)
to any port xyz modulate state
pass out quick on $EXT_IF inet proto tcp from ($LAN_IF:network)
to any port xyz modulate state
Les deux, et je m'étonne que ce puisse être différent avec netfilter.
Lorsque les paquets en provenance du LAN arrivent sur ta passerelle,
elles doivent être autorisées à entrer dans la machine, c'est le "pass
in on $EXT_LAN" qui permettra cela. Mais comme le paquet ne fait que
traverser la machine pour partir ensuite vers le vaste monde, il faut
aussi que tu lui donnes l'autorisation de sortir de celle ci, d'où le
"pass out on $EXT_IF".
Cela étant dit, la meilleure solution que j'ai trouvée consiste à
utiliser les tags :
# Laisser entrer sur la passerelle ce qui peut sortir
pass in quick on $EXT_LAN [ce que tu veux] tag ITS_OK
# bloquer tout le reste
block quick on $EXT_LAN all
# Laisser sortir tout ce qui a eu le droit d'entrer
pass out quick all tagged ITS_OK keep state
Du coup tes règles ne s'occupent que des paquets entrant sur la
passerelle, ce qui t'évite d'avoir à tout doubler, et donc à multiplier
les risques d'erreurs humaines.
Au passage, note qu'il ne faut pas mentionner l'interface pour la
règle "pass out", ce qui te permet d'avoir une seule règle valable pour
tous les cas de figure (connexions "LAN -> vaste monde", connexions
"vaste monde -> LAN" et même chose pour la DMZ). A toi de faire la
différence dans les règles en entrée.
*je trouve d'ailleurs qu'il y a sur Internet bien plus de jeux de règles
Netfilter que pf pour assister le débutant, [...]
Parce qu'il y a aussi largement plus d'utilisateur de Netfilter que
d'utilisateur de pf.
Merci d'avance pour vos réponses.
De rien. Cela dit, tu aurais sans doute plus de réponses sur
fr.comp.securite (pis ça ferait un peu de signal en-charte pour
changer)
François RONVAUX devait dire quelque chose comme ceci :
QUESTION 1) -----------
Mon architecture réseau ressemble à ceci :
LAN ---- LAN_IF [OpenBSD] EXT_IF ---- (Internet)
En lisant la documentation et les quelques exemples qu'elle contient* je ne parviens pas à déterminer comment autoriser la trafic sortant du LAN (et de la DMZ, mais la syntaxe sera la même). Laquelle de ces deux règles faut il utiliser ?
pass in quick on $LAN_IF inet proto tcp from ($LAN_IF:network) to any port xyz modulate state
pass out quick on $EXT_IF inet proto tcp from ($LAN_IF:network) to any port xyz modulate state
Les deux, et je m'étonne que ce puisse être différent avec netfilter.
Lorsque les paquets en provenance du LAN arrivent sur ta passerelle, elles doivent être autorisées à entrer dans la machine, c'est le "pass in on $EXT_LAN" qui permettra cela. Mais comme le paquet ne fait que traverser la machine pour partir ensuite vers le vaste monde, il faut aussi que tu lui donnes l'autorisation de sortir de celle ci, d'où le "pass out on $EXT_IF".
Cela étant dit, la meilleure solution que j'ai trouvée consiste à utiliser les tags :
# Laisser entrer sur la passerelle ce qui peut sortir pass in quick on $EXT_LAN [ce que tu veux] tag ITS_OK # bloquer tout le reste block quick on $EXT_LAN all
# Laisser sortir tout ce qui a eu le droit d'entrer pass out quick all tagged ITS_OK keep state
Du coup tes règles ne s'occupent que des paquets entrant sur la passerelle, ce qui t'évite d'avoir à tout doubler, et donc à multiplier les risques d'erreurs humaines. Au passage, note qu'il ne faut pas mentionner l'interface pour la règle "pass out", ce qui te permet d'avoir une seule règle valable pour tous les cas de figure (connexions "LAN -> vaste monde", connexions "vaste monde -> LAN" et même chose pour la DMZ). A toi de faire la différence dans les règles en entrée.
*je trouve d'ailleurs qu'il y a sur Internet bien plus de jeux de règles Netfilter que pf pour assister le débutant, [...]
Parce qu'il y a aussi largement plus d'utilisateur de Netfilter que d'utilisateur de pf.
Merci d'avance pour vos réponses.
De rien. Cela dit, tu aurais sans doute plus de réponses sur fr.comp.securite (pis ça ferait un peu de signal en-charte pour changer)
François RONVAUX
Bonjour,
J'ai une nouvelle question, concernant les macros cette fois. Si je créé les macros suivantes :
DMZ_IF="interface" DMZ="($DMZ_IF:network)"
PF ne remplace pas la macro DMZ dans les règles et j'obtiens un message "syntax error".
Est ce impossible de faire cela ou bien y a t il une astuce ?
Merci d'avance.
Bonjour,
J'ai une nouvelle question, concernant les macros cette fois. Si je créé
les macros suivantes :
DMZ_IF="interface"
DMZ="($DMZ_IF:network)"
PF ne remplace pas la macro DMZ dans les règles et j'obtiens un message
"syntax error".
Est ce impossible de faire cela ou bien y a t il une astuce ?
> > *je trouve d'ailleurs qu'il y a sur Internet bien plus de jeux de règ les > Netfilter que pf pour assister le débutant, [...]
Parce qu'il y a aussi largement plus d'utilisateur de Netfilter que d'utilisateur de pf.
Aussi parce que la syntaxe de pf est bien plus simple à comprendre que celle de Netfilter ....
Stephane Catteau
totof2000 n'était pas loin de dire :
*je trouve d'ailleurs qu'il y a sur Internet bien plus de jeux de règles Netfilter que pf pour assister le débutant, [...]
Parce qu'il y a aussi largement plus d'utilisateur de Netfilter que d'utilisateur de pf.
Aussi parce que la syntaxe de pf est bien plus simple à comprendre que celle de Netfilter ....
La syntaxe est plus intuitive certes, mais les macros et les tables apportent une telle puissance et une telle souplesse à pf, qu'il manque quand même quelques exemples "en situation". Rien que le coup du taguage des paquets pour ne pas avoir à se soucier de l'interface de sortie dans le cas d'une passerelle, ça mériterait d'être un peu plus, disons "médiatisé". Même chose pour la réplication du jeu de règle d'un serveur à un autre ; lorsqu'elles sont bien écrites, il suffit de changer la table contenant les ports autorisés pour le vaste monde, et le tour est joué. A l'usage ça s'avère plus sûr qu'une réécriture complète, avec les erreurs que cela implique pour toutes les règles d'administrations (qui peut accéder à SSH, où partent les logs, et ainsi de suite). Sans parler des options de contrôle du trafic qui, pour moi en tout cas, restent assez obscure à la lecture de la doc officielle.
totof2000 n'était pas loin de dire :
*je trouve d'ailleurs qu'il y a sur Internet bien plus de jeux de règles
Netfilter que pf pour assister le débutant, [...]
Parce qu'il y a aussi largement plus d'utilisateur de Netfilter que
d'utilisateur de pf.
Aussi parce que la syntaxe de pf est bien plus simple à comprendre que
celle de Netfilter ....
La syntaxe est plus intuitive certes, mais les macros et les tables
apportent une telle puissance et une telle souplesse à pf, qu'il manque
quand même quelques exemples "en situation".
Rien que le coup du taguage des paquets pour ne pas avoir à se soucier
de l'interface de sortie dans le cas d'une passerelle, ça mériterait
d'être un peu plus, disons "médiatisé". Même chose pour la réplication
du jeu de règle d'un serveur à un autre ; lorsqu'elles sont bien
écrites, il suffit de changer la table contenant les ports autorisés
pour le vaste monde, et le tour est joué. A l'usage ça s'avère plus sûr
qu'une réécriture complète, avec les erreurs que cela implique pour
toutes les règles d'administrations (qui peut accéder à SSH, où partent
les logs, et ainsi de suite).
Sans parler des options de contrôle du trafic qui, pour moi en tout
cas, restent assez obscure à la lecture de la doc officielle.
*je trouve d'ailleurs qu'il y a sur Internet bien plus de jeux de règles Netfilter que pf pour assister le débutant, [...]
Parce qu'il y a aussi largement plus d'utilisateur de Netfilter que d'utilisateur de pf.
Aussi parce que la syntaxe de pf est bien plus simple à comprendre que celle de Netfilter ....
La syntaxe est plus intuitive certes, mais les macros et les tables apportent une telle puissance et une telle souplesse à pf, qu'il manque quand même quelques exemples "en situation". Rien que le coup du taguage des paquets pour ne pas avoir à se soucier de l'interface de sortie dans le cas d'une passerelle, ça mériterait d'être un peu plus, disons "médiatisé". Même chose pour la réplication du jeu de règle d'un serveur à un autre ; lorsqu'elles sont bien écrites, il suffit de changer la table contenant les ports autorisés pour le vaste monde, et le tour est joué. A l'usage ça s'avère plus sûr qu'une réécriture complète, avec les erreurs que cela implique pour toutes les règles d'administrations (qui peut accéder à SSH, où partent les logs, et ainsi de suite). Sans parler des options de contrôle du trafic qui, pour moi en tout cas, restent assez obscure à la lecture de la doc officielle.
Stephane Catteau
François RONVAUX devait dire quelque chose comme ceci :
DMZ_IF="interface" DMZ="($DMZ_IF:network)"
[snip]
Est ce impossible de faire cela ou bien y a t il une astuce ?
Essaye en isolant uniquement la macro : DMZ="($DMZ_IF):network" Sinon, il ne te reste plus qu'à mettre directement l'interface dans la macro, donc : DMZ="sis0:network" en considérant évidement que l'interface est sis0
Merci d'avance.
De rien
François RONVAUX devait dire quelque chose comme ceci :
DMZ_IF="interface"
DMZ="($DMZ_IF:network)"
[snip]
Est ce impossible de faire cela ou bien y a t il une astuce ?
Essaye en isolant uniquement la macro :
DMZ="($DMZ_IF):network"
Sinon, il ne te reste plus qu'à mettre directement l'interface dans la
macro, donc :
DMZ="sis0:network"
en considérant évidement que l'interface est sis0
François RONVAUX devait dire quelque chose comme ceci :
DMZ_IF="interface" DMZ="($DMZ_IF:network)"
[snip]
Est ce impossible de faire cela ou bien y a t il une astuce ?
Essaye en isolant uniquement la macro : DMZ="($DMZ_IF):network" Sinon, il ne te reste plus qu'à mettre directement l'interface dans la macro, donc : DMZ="sis0:network" en considérant évidement que l'interface est sis0
Merci d'avance.
De rien
Bastien Durel
On 01/04/2009 12:57, François RONVAUX wrote:
Bonjour,
J'ai une nouvelle question, concernant les macros cette fois. Si je créé les macros suivantes :
DMZ_IF="interface" DMZ="($DMZ_IF:network)"
Bonjour,
la syntaxe pour imbriquer des macros est plutôt : DMZ="(" $DMZ_IF ":network)"
Sauf que dans ce cas, ça ne marche pas, car tu auras : DMZ = "( interface :network)"
Et que pf n'admet pas de blancs dans cette situation. Je n'ai pas de solution à proposer, cela dit :/
-- Bastien
On 01/04/2009 12:57, François RONVAUX wrote:
Bonjour,
J'ai une nouvelle question, concernant les macros cette fois. Si je créé
les macros suivantes :
DMZ_IF="interface"
DMZ="($DMZ_IF:network)"
Bonjour,
la syntaxe pour imbriquer des macros est plutôt :
DMZ="(" $DMZ_IF ":network)"
Sauf que dans ce cas, ça ne marche pas, car tu auras :
DMZ = "( interface :network)"
Et que pf n'admet pas de blancs dans cette situation. Je n'ai pas de
solution à proposer, cela dit :/
echo "" echo -n "Fetching bogon list: " cd /root $WGET $BOGON_DL if [ -s $BOGON_NEW ] then echo "bogon table found, comparing to current..." diff $BOGON_CUR $BOGON_NEW > /root/bogon-diff.txt if [ -s /root/bogon-diff.txt ] then echo "Bogon table appears to have changed." echo -n "Attempting to load new bogon table: " mv $BOGON_NEW $BOGON_CUR $PFCTL -t bogon -T flush if [ `$PFCTL -T load -f /etc/pf.conf` ] then echo "something went wrong!" else echo "success!" echo 'Diffs: (< Old > New)' /bin/cat /root/bogon-diff.txt fi else echo "Bogon table NOT changed." /bin/rm $BOGON_NEW fi /bin/rm /root/bogon-diff.txt else echo "bogon table NOT found." fi cd
Jérémy JUST
Le Mon, 30 Mar 2009 14:48:04 +0200, Damien Wyart a écrit :
Un bon point de départ : http://home.nuug.no/~peter/pf/
Il y a quelques années, un peu anxieux à l'idée de casser tout mon réseau et me monter un petit routeur sous OpenBSD, j'avais commencé par lire intégralement ce petit livre (acheté d'occasion): http://www.amazon.com/Building-Firewalls-OpenBSD-PF-2nd/dp/8391665119 et ça m'avait bien servi. Il n'est évidemment pas exhaustif, mais il donne des exemples concrets et permet de comprendre des syntaxes qu'on serait tenté de copier-coller telles quelles sans trop chercher à comprendre ce qu'elles font.
Depuis, au moins un autre bouquin est sorti, que je n'ai pas consulté: http://www.amazon.fr/Book-PF-No-nonsense-OpenBSD-Firewall/dp/1593271654
Après, ce n'est pas la peine de multiplier les bouquins et les tutoriaux: une fois qu'on a le pied à l'étrier, la doc officielle devient compréhensible et c'est parti!
-- Jérémy JUST
Le Mon, 30 Mar 2009 14:48:04 +0200,
Damien Wyart <damien.wyart@free.fr> a écrit :
Un bon point de départ :
http://home.nuug.no/~peter/pf/
Il y a quelques années, un peu anxieux à l'idée de casser tout mon
réseau et me monter un petit routeur sous OpenBSD, j'avais commencé par
lire intégralement ce petit livre (acheté d'occasion):
http://www.amazon.com/Building-Firewalls-OpenBSD-PF-2nd/dp/8391665119
et ça m'avait bien servi. Il n'est évidemment pas exhaustif, mais il
donne des exemples concrets et permet de comprendre des syntaxes qu'on
serait tenté de copier-coller telles quelles sans trop chercher à
comprendre ce qu'elles font.
Depuis, au moins un autre bouquin est sorti, que je n'ai pas consulté:
http://www.amazon.fr/Book-PF-No-nonsense-OpenBSD-Firewall/dp/1593271654
Après, ce n'est pas la peine de multiplier les bouquins et les
tutoriaux: une fois qu'on a le pied à l'étrier, la doc officielle
devient compréhensible et c'est parti!
Le Mon, 30 Mar 2009 14:48:04 +0200, Damien Wyart a écrit :
Un bon point de départ : http://home.nuug.no/~peter/pf/
Il y a quelques années, un peu anxieux à l'idée de casser tout mon réseau et me monter un petit routeur sous OpenBSD, j'avais commencé par lire intégralement ce petit livre (acheté d'occasion): http://www.amazon.com/Building-Firewalls-OpenBSD-PF-2nd/dp/8391665119 et ça m'avait bien servi. Il n'est évidemment pas exhaustif, mais il donne des exemples concrets et permet de comprendre des syntaxes qu'on serait tenté de copier-coller telles quelles sans trop chercher à comprendre ce qu'elles font.
Depuis, au moins un autre bouquin est sorti, que je n'ai pas consulté: http://www.amazon.fr/Book-PF-No-nonsense-OpenBSD-Firewall/dp/1593271654
Après, ce n'est pas la peine de multiplier les bouquins et les tutoriaux: une fois qu'on a le pied à l'étrier, la doc officielle devient compréhensible et c'est parti!
