Quel firewall pour Buster et au delà ?
Le
Olivier

--00000000000033c97b057f1aa208
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Bonjour,
Je maintiens depuis des années un script qui configure le firewalling =
sur
des serveurs.
Ce script est installé dans /etc/network/if-pre-up.d
Il comprend une bonne trentaine de règles iptables dont des règle=
s pour le
NAT.
J'ai lu que Linux remplaçait iptables par nftables.
Par ailleurs, la technologie eBPF semble aussi très prometteuse.
J'ai toute confiance sur l'existence dans Buster et ses successeurs de
moyens pour conserver le bon fonctionnement de scripts iptables.
Néanmoins, je me demande si le moment n'est pas le bienvenu pour juste=
ment
pour sauter le pas en réécrivant mes scripts iptables avec autre =
chose.
On annonce ici ou là:
- une plus grande pérennité
- de meilleurs performances
- une syntaxe plus simple.
Je serai très heureux d'échanger ici des réflexions sur le s=
ujet.
Voici en vrac quelques questions et réflexions:
1. Avez-vous un retour d'expérience positif ou non sur un passage
d'iptables à firewalld, en général (ie sur Stretch, Jessie, =
) ?
2. Trouvez-vous facilement de l'aide (mailing lists, documentation en
ligne, publications, ) sur la version 0.6.3 de firewalld (celle de
Buster) ?
3. Comme le suggère la réponse à une question dans [1], doit=
-on vraiment
voir eBPF comme une cuisine interne à Linux et se focaliser sur firewa=
lld ?
4. Commentaires et suggestions ?
[1]
https://developers.redhat.com/blog/2018/08/10/firewalld-the-future-is-nftab=
les/
Slts
--00000000000033c97b057f1aa208
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir="ltr"><div dir="ltr"><div>Bonjour,</div><div><br></div><div>Je=
maintiens depuis des années un script qui configure le firewalling su=
r des serveurs.</div><div>Ce script est installé dans /etc/network/if-=
pre-up.d</div><div>Il comprend une bonne trentaine de règles iptables =
dont des règles pour le NAT.</div><div><br></div><div>J'ai lu que =
Linux remplaçait iptables par nftables.</div><div>Par ailleurs, la tec=
hnologie eBPF semble aussi très prometteuse.</div><div><br></div><div>=
J'ai toute confiance sur l'existence dans Buster et ses successeurs=
de moyens pour conserver le bon fonctionnement de scripts iptables.</div><=
div>Néanmoins, je me demande si le moment n'est pas le bienvenu po=
ur justement pour sauter le pas en réécrivant mes scripts iptable=
s avec autre chose.</div><div><br></div><div>On annonce ici ou là:</di=
v><div>- une plus grande pérennité</div><div>- de meilleurs perfo=
rmances</div><div>- une syntaxe plus simple.</div><div><br></div><div>Je se=
rai très heureux d'échanger ici des réflexions sur le su=
jet.</div><div>Voici en vrac quelques questions et réflexions:</div><d=
iv><br></div><div>1. Avez-vous un retour d'expérience positif ou n=
on sur un passage d'iptables à firewalld, en général (ie=
sur Stretch, Jessie, ) ?</div><div><br></div><div>2. Trouvez-vous facil=
ement de l'aide (mailing lists, documentation en ligne, publications, .=
..) sur la version 0.6.3 de firewalld (celle de Buster) ?</div><div><br></d=
iv><div>3. Comme le suggère la réponse à une question dans [=
1], doit-on vraiment voir eBPF comme une cuisine interne à Linux et se=
focaliser sur firewalld ?</div><div><br></div><div>4. Commentaires et sugg=
estions ?</div><div><br></div><div></div><div>[1] <a href="https://develo=
pers.redhat.com/blog/2018/08/10/firewalld-the-future-is-nftables/">https://=
developers.redhat.com/blog/2018/08/10/firewalld-the-future-is-nftables/</a>=
</div><div><br></div><div>Slts<br></div><div><br></div></div></div>
--00000000000033c97b057f1aa208--
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Bonjour,
Je maintiens depuis des années un script qui configure le firewalling =
sur
des serveurs.
Ce script est installé dans /etc/network/if-pre-up.d
Il comprend une bonne trentaine de règles iptables dont des règle=
s pour le
NAT.
J'ai lu que Linux remplaçait iptables par nftables.
Par ailleurs, la technologie eBPF semble aussi très prometteuse.
J'ai toute confiance sur l'existence dans Buster et ses successeurs de
moyens pour conserver le bon fonctionnement de scripts iptables.
Néanmoins, je me demande si le moment n'est pas le bienvenu pour juste=
ment
pour sauter le pas en réécrivant mes scripts iptables avec autre =
chose.
On annonce ici ou là:
- une plus grande pérennité
- de meilleurs performances
- une syntaxe plus simple.
Je serai très heureux d'échanger ici des réflexions sur le s=
ujet.
Voici en vrac quelques questions et réflexions:
1. Avez-vous un retour d'expérience positif ou non sur un passage
d'iptables à firewalld, en général (ie sur Stretch, Jessie, =
) ?
2. Trouvez-vous facilement de l'aide (mailing lists, documentation en
ligne, publications, ) sur la version 0.6.3 de firewalld (celle de
Buster) ?
3. Comme le suggère la réponse à une question dans [1], doit=
-on vraiment
voir eBPF comme une cuisine interne à Linux et se focaliser sur firewa=
lld ?
4. Commentaires et suggestions ?
[1]
https://developers.redhat.com/blog/2018/08/10/firewalld-the-future-is-nftab=
les/
Slts
--00000000000033c97b057f1aa208
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir="ltr"><div dir="ltr"><div>Bonjour,</div><div><br></div><div>Je=
maintiens depuis des années un script qui configure le firewalling su=
r des serveurs.</div><div>Ce script est installé dans /etc/network/if-=
pre-up.d</div><div>Il comprend une bonne trentaine de règles iptables =
dont des règles pour le NAT.</div><div><br></div><div>J'ai lu que =
Linux remplaçait iptables par nftables.</div><div>Par ailleurs, la tec=
hnologie eBPF semble aussi très prometteuse.</div><div><br></div><div>=
J'ai toute confiance sur l'existence dans Buster et ses successeurs=
de moyens pour conserver le bon fonctionnement de scripts iptables.</div><=
div>Néanmoins, je me demande si le moment n'est pas le bienvenu po=
ur justement pour sauter le pas en réécrivant mes scripts iptable=
s avec autre chose.</div><div><br></div><div>On annonce ici ou là:</di=
v><div>- une plus grande pérennité</div><div>- de meilleurs perfo=
rmances</div><div>- une syntaxe plus simple.</div><div><br></div><div>Je se=
rai très heureux d'échanger ici des réflexions sur le su=
jet.</div><div>Voici en vrac quelques questions et réflexions:</div><d=
iv><br></div><div>1. Avez-vous un retour d'expérience positif ou n=
on sur un passage d'iptables à firewalld, en général (ie=
sur Stretch, Jessie, ) ?</div><div><br></div><div>2. Trouvez-vous facil=
ement de l'aide (mailing lists, documentation en ligne, publications, .=
..) sur la version 0.6.3 de firewalld (celle de Buster) ?</div><div><br></d=
iv><div>3. Comme le suggère la réponse à une question dans [=
1], doit-on vraiment voir eBPF comme une cuisine interne à Linux et se=
focaliser sur firewalld ?</div><div><br></div><div>4. Commentaires et sugg=
estions ?</div><div><br></div><div></div><div>[1] <a href="https://develo=
pers.redhat.com/blog/2018/08/10/firewalld-the-future-is-nftables/">https://=
developers.redhat.com/blog/2018/08/10/firewalld-the-future-is-nftables/</a>=
</div><div><br></div><div>Slts<br></div><div><br></div></div></div>
--00000000000033c97b057f1aa208--
Alors je suis une truffe pour tout ce qui est réseaux mais j'ai quand
même l'impression qu'il y a un quiproquo sur nftables/firewalld, non?
Firewalld n'est qu'une surcouche à, auparavant iptables, désormais
nftables? Un peu comme Shorewall
D'après ce que j'ai compris, le paquet iptables sera dans la prochaine
version Debian et ne sera pas un pseudo-paquet pointant vers nftables,
mais utilisera le backend nftables dans le noyau mais en conservant la
syntaxe iptables? Et si on souhaite utiliser véritablement nftables, il
est possible (au moins pour le moment) d'utiliser l'ancienne syntaxe
iptables ou la nouvelle syntaxe dédiée nftables?
Didier, truffe réseau en mal de culture ad-hoc ;-)
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Le ven. 11 janv. 2019 à 16:24, Wallace
encore de longues années.
Pour une machine "ancienne", on devrait pouvoir la passer à Buster san s
modification.
Par contre, pour une nouvelle machine, je pense qu'on peut avoir intér êt à
se poser la question d'une autre syntaxe ou d'un autre niveau d'abstraction .
--000000000000d69128057f312eae
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Ca voudrait donc dire que iptables ne fait plus parti du kernel?<br>
<br>
--000000000000d69128057f312eae--
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Le ven. 11 janv. 2019 à 17:55, Wallace
Justement, j'ai compris que BPF, c'était la cuisine interne de Linux: on
configure avec nftables ou firewalld ou autre et c'est nftables qui
s'appuie sur BPF à l'insu de l'administrateur.
Bien entendu, je peux avoir compris de travers et je serai ravi qu'une
personne plus qualifiée que moi me corrige ;-)))
--0000000000006f6170057f31d2c8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div bgcolor="#FFFFFF"><p>Clairement vu ce que je ressort de la convers ation, quitte à
faire un saut autant sauter directement à BPF. --0000000000006f6170057f31d2c8--
Je connaissais l'existence des différentes versions de (Berkeley) Packet
Filter ((B)PF) dans les différentes versions de BSD en tant que pare-feu.
De ce que je crois comprendre, Linux utilise déjà certaines briques de
l'infrastructure BPF (qui serait une interface aux couches réseau plus
qu'un simple pare-feu) et dont la pure partie pare-feu n'aurait jamais
été intégrée à Linux ni à ses distributions. eBPF est la prochaine
itération de BPF qui semble offrir des possibilités tellement
avantageuses par rapport à l'existant que Linux cherche à en profiter,
l'une des possibilités étant de la faire fonctionner en coordination
avec nftables.
Tout ça au conditionnel parce que signé La Truffe Réseau ;-)
Le Fri, 11 Jan 2019 16:23:44 +0100,
Wallace