Page 1 sur 1

Firewalld 0.5.3 est-il vraiment abouti ?

Publié : 07 juin 2019, 16:11
par JMV
Voilà quelques jours que je tente de remplacer IPTABLES par FIREWALLD sur une nouvelle Centos 7. Après avoir mis à jour la version pour 0.5.3, je constate toujours des incohérences de fonctionnement et viens m'interroger ici avec le retour de votre expérience. J'en cite 2 des plus étrange :

- J'ai retiré de façon permanente le seul service en natif autorisé (à savoir SSH) de la zone EXTERNAL avant d'affecter la zone à mon interface WAN. Après test, rien ne passait en provenance de l'extérieur. Un redémarrage machine annule la manip et c'est maintenant open bar pour les internautes. Un coup d'oeil sur la zone EXTERNAL ne mentionne toujours pas le SSH en accès. Un #iptables -L affiche quant à lui en 6ème position de la chaine INPUT, soit avant les règles positionnées par FIREWALLD, une règle autorisant tous les trafics et tout s'explique. Comme FIREWALD ne peut modifier les règles à ce niveau de construction des chaines, je m'interroge sur l'interaction de FIREWALLD avec IPTABLES et sur sa fiabilité.

- Impossible de mettre des règles dans la chaine FORWARD et donc de filtrer le trafic en transit. Est-il exceptionnel de vouloir autoriser les utilisateurs de son LAN à consulter le WEB ? C'est la chaine INPUT à chaque fois concernées, même si on y inscrit des destinations autres que la machine même. Seules les options --direct ont pu me sauver...

Je vous remercie de partager votre expérience en la matière. Je retourne à IPTABLES quant à moi ...

Re: Firewalld 0.5.3 est-il vraiment abouti ?

Publié : 07 juin 2019, 16:49
par nouvo09
Je ne suis pas un fanatique du firewall mais une chose apparait sure, c'est qu'on ne doit pas mélanger firewalld et iptables.

Re: Firewalld 0.5.3 est-il vraiment abouti ?

Publié : 07 juin 2019, 16:53
par JMV
Sauf que firewalld est tout simplement une surcouche d'iptables ! Le premier ne va donc pas sans le deuxième ... C'est bien leur articulation qui pose problème dans le cas présent.