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&#39;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&#39;ai toute confiance sur l&#39;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&#39;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&#39;é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&#39;expérience positif ou n=
on sur un passage d&#39;iptables à firewalld, en général (ie=
sur Stretch, Jessie, ) ?</div><div><br></div><div>2. Trouvez-vous facil=
ement de l&#39;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--
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
didier gaumet
Le #26505051
Le 11/01/2019 à 15:44, Wallace a écrit :
Bonjour,
Merci d'avoir lancé le sujet qui trottait dans mon esprit.
Actuellement on gère iptables grâce à Shorewall qui fait très bien le
travail et permet de retrouver une lecture similaire à une configuration
de firewall appliance. C'est pratique pour que tout le monde soit au
diapason sur la lecture. Y a Ferm qui fait pareil aussi.
Shorewall a déjà annoncé qu'il ne partirait pas dans ce chantier de
refonte étant trop lié à iptables.
Personnellement je n'ai rien à reprocher à iptables et j'envisage donc
de continuer de l'utiliser. Mais si l'on est bloqué par une suppression
de iptables et obligation de passer sur nftables alors il va falloir
anticiper.
Il y a du coup deux questions :
- y a t il eu une annonce quand on retrait du kernel ou le End Of Life
de iptables?
- nftables est il forcément lié à firewalld? ou est-ce que l'on peut
parler directement au kernel comme avant?

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 ;-)
Olivier
Le #26505071
--000000000000d69128057f312eae
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Le ven. 11 janv. 2019 à 16:24, Wallace
Ca voudrait donc dire que iptables ne fait plus parti du kernel?
Je pense que des scripts iptables fonctionneront sans modification pendan t

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--
Olivier
Le #26505086
--0000000000006f6170057f31d2c8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Le ven. 11 janv. 2019 à 17:55, Wallace
Clairement vu ce que je ressort de la conversation, quitte à faire u n saut
autant sauter directement à BPF.

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--
didier gaumet
Le #26505094
Le 11/01/2019 à 18:13, Olivier a écrit :
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 ;-)))

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 ;-)
Thierry Despeyroux
Le #26505122
non pas de date fixée
Le Fri, 11 Jan 2019 16:23:44 +0100,
Wallace
Le 11/01/2019 à 16:05, didier gaumet a écrit :
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éso rmais
nftables? Un peu comme Shorewall

Aucune idée je n'ai pas encore creusé le sujet.
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?

Ca voudrait donc dire que iptables ne fait plus parti du kernel?
J'ai rien trouvé en news à ce sujet.
Néanmoins quand on voit un article comme celui là :
https://cilium.io/blog/2018/04/17/why-is-the-kernel-community-replacing-i ptables/
On peut se dire que nftables est un remplaçant à peine plus
performant. BPF semble bien plus prometteur pour les réseaux à plus
de 10Gbs.
Didier, truffe réseau en mal de culture ad-hoc ;-)

On ne peut pas tout maitriser et j'avoue avoir un peu lâcher ce sujet
vu qu'iptables fait le boulot et qu'on a pas encore été confron té à
des interfaces à plus de 10Gbs...
Publicité
Poster une réponse
Anonyme