Module firewalld Ansible : ouvrir des ports sur RHEL/AlmaLinux

ansible.posix.firewalld: gère firewalld, le pare-feu par défaut sur RHEL 7+, AlmaLinux, RockyLinux. C'est le module n°1 RHCE 2026 pour ouvrir/fermer des ports, autoriser des services prédéfinis (http, https, ssh), et gérer les zones.

Module de la collection ansible.posix, ansible-galaxy collection install ansible.posix requis.

Options critiques : service: (nom prédéfini) ou port: (8080/tcp), state: (enabled / disabled), permanent: true + immediate: true (la règle d'or), zone:.

Ce que vous allez apprendre

• Pourquoi permanent: true ET immediate: true doivent être combinés.
• Distinguer service: (nom prédéfini) de port: (port custom).
• Segmenter les règles par zone (public, internal, dmz).
• Retirer une règle avec state: disabled (pas absent).
• Sécuriser un port avec source: pour limiter l'IP autorisée.

Prérequis

• Avoir ansible.posix installé : ansible-galaxy collection install ansible.posix.
• firewalld doit être démarré sur le managed node : systemd_service: name=firewalld state=started enabled=true.

Le piège permanent vs immediate

firewalld distingue deux états :

• runtime : règles actives maintenant (perdues au reboot).
• permanent : règles persistées dans /etc/firewalld/, chargées au reboot.

# ❌ Piege : ouvre maintenant, perd au reboot
- name: Ouvrir le service dans le pare-feu
  ansible.posix.firewalld:
    service: http
    state: enabled

# ❌ Piege : persiste mais pas applique maintenant
- name: Ouvrir le service dans le pare-feu
  ansible.posix.firewalld:
    service: http
    state: enabled
    permanent: true

# ✅ Bon : applique maintenant ET persiste
- name: Ouvrir le service dans le pare-feu
  ansible.posix.firewalld:
    service: http
    state: enabled
    permanent: true
    immediate: true

Règle absolue : toujours permanent: true + immediate: true. Sans les deux, vous tombez dans un des deux pièges classiques.

Service prédéfini (préféré)

- name: Autoriser HTTP et HTTPS
  ansible.posix.firewalld:
    service: "{{ item }}"
    state: enabled
    permanent: true
    immediate: true
  loop: [http, https]

firewall-cmd --get-services liste plus de 100 services prédéfinis : http, https, ssh, dns, dhcp, samba, ftp, smtp, etc. Préférer un service à un port quand possible, l'intent est plus clair (http plutôt que 80/tcp).

Port custom

- name: Ouvrir le port 8080/tcp pour app dev
  ansible.posix.firewalld:
    port: 8080/tcp
    state: enabled
    permanent: true
    immediate: true

Format : <port>/<protocol>, tcp, udp. Plages : 8000-8100/tcp.

Quand utiliser port: plutôt que service: : app custom sans service prédéfini, port non standard, stack interne (Prometheus 9090, Grafana 3000, etc.).

Zones firewalld

- name: SSH dans la zone internal uniquement
  ansible.posix.firewalld:
    service: ssh
    zone: internal
    state: enabled
    permanent: true
    immediate: true

- name: Bloquer SSH dans la zone public
  ansible.posix.firewalld:
    service: ssh
    zone: public
    state: disabled
    permanent: true
    immediate: true

Zones par défaut RHEL : public (la plupart du trafic), internal, trusted, dmz, block, drop. Cas d'usage : un serveur multi-interfaces (eth0 public, eth1 internal) avec règles différentes par zone.

firewall-cmd --get-default-zone donne la zone par défaut. À changer avec :

- name: Basculer la zone par défaut du pare-feu
  ansible.builtin.command: firewall-cmd --set-default-zone=internal
  changed_when: true

Limiter par IP source

- name: SSH uniquement depuis le LAN management
  ansible.posix.firewalld:
    rich_rule: 'rule family="ipv4" source address="10.10.20.0/24" service name="ssh" accept'
    state: enabled
    permanent: true
    immediate: true

rich_rule: permet des règles avancées : limit-rate, log, masquerade, restrictions IP source/destination. Plus puissant que service: simple mais plus verbeux.

Suppression

- name: Retirer le port 8080
  ansible.posix.firewalld:
    port: 8080/tcp
    state: disabled
    permanent: true
    immediate: true

Pas de state: absent pour firewalld, c'est state: disabled. La règle est retirée des fichiers permanents et des règles runtime.

Pattern complet : web stack

- name: Stack web complete
  hosts: web1.lab
  become: true
  tasks:
    - name: Installer httpd
      ansible.builtin.dnf:
        name: httpd
        state: present

    - name: Demarrer httpd
      ansible.builtin.systemd_service:
        name: httpd
        state: started
        enabled: true

    - name: Demarrer firewalld
      ansible.builtin.systemd_service:
        name: firewalld
        state: started
        enabled: true

    - name: Ouvrir HTTP et HTTPS
      ansible.posix.firewalld:
        service: "{{ item }}"
        state: enabled
        permanent: true
        immediate: true
      loop: [http, https]

Ordre : installer → démarrer service applicatif → démarrer firewalld → ouvrir le pare-feu. Le pare-feu en dernier garantit qu'il n'autorise pas du trafic vers un service pas encore prêt.

Pièges courants

Les deux premières lignes sont les deux moitiés du même piège, une règle active mais éphémère, une règle écrite mais inactive : elles disparaissent en posant toujours les deux options ensemble. Les trois suivantes tiennent à l'environnement, un service de pare-feu arrêté, une zone par défaut qui varie d'une machine à l'autre, et une valeur de state: qui ne suit pas la convention des autres modules.

Symptôme	Cause	Fix
Port marche maintenant, perd au reboot	permanent: false (défaut)	Ajouter permanent: true
permanent: true mais port non actif	immediate: false (défaut)	Ajouter immediate: true
Module firewalld is not running	firewalld pas démarré	systemd_service: firewalld started avant
Règle de zone inattendue	Zone par défaut diffère du déploiement	Spécifier zone: explicitement
state: absent ne fonctionne pas	Mauvais nom, c'est disabled	Utiliser state: disabled

Glissez pour voir

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• Module ansible.posix.firewalld: (collection requise).
• permanent: true + immediate: true = règle d'or, toujours les deux.
• service: > port: quand un service prédéfini existe (lisibilité).
• zone: pour segmenter les règles par interface.
• state: disabled pour retirer (pas absent).
• firewalld doit tourner avant le module.

Mettre en pratique

Oublier permanent: true ne se remarque qu'après un rechargement, quand la règle a disparu. Ce lab vous fait donc autoriser des services prédéfinis puis des ports custom dans une zone donnée, avant de recharger le pare-feu et de constater ce qui a survécu. Le contrôle interroge séparément la configuration runtime et la configuration permanente, ce qui rend le piège impossible à masquer.

Lab pratique

Module firewalld : gérer le pare-feu RHEL

$ dsoxlab run modules-rhel-firewalld

Environnement : VM·Durée : ~30 min

Validé : l'état du système est vérifié après reboot, pas la commande tapée.

Première fois ? Qu'est-ce que dsoxlab et comment l'installer

dsoxlab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Installer la CLI et brancher le catalogue, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
dsoxlab catalog add https://github.com/stephrobert/ansible-training

Lancer ce lab, puis valider votre travail :

dsoxlab run modules-rhel-firewalld
dsoxlab check modules-rhel-firewalld

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress. Le guide complet de dsoxlab détaille l'installation, le calcul du score et les pièges.

Pour aller plus loin

• Modules wait_for et pause : vérifier qu'un port ouvert répond réellement, au lieu de supposer que la règle suffit.
• Module sysctl : le durcissement réseau côté noyau, qui complète les règles de pare-feu.
• Module uri : pousser la vérification jusqu'à la réponse HTTP du service exposé.

×

📖 Voir la documentation →