CentOS 7 : Utilisation et configuration de firewalld

I. Présentation

Vous l’avez certainement remarqué, depuis la version 7, les distributions CentOS ou RedHat Enterprise possèdent pas mal de nouveautés.

Dans ce tutoriel, je vous propose de découvrir l’une d’elles, parmi tant d’autres. Je veux parler du service firewalld et de son utilitaire firewall-cmd, permettant de manipuler les flux réseau et de remplacer avantageusement iptables.

Dans un premier temps, nous rappellerons brièvement comment fonctionne le pare-feu iptables et quel est son mode opératoire avant d’expliquer en quoi l’utilitaire firewall-cmd peut améliorer la vie des administrateurs et quelles sont ses fonctionnalités novatrices.

II. Rappels sur le pare-feu iptables

Il ne faut pas s’y tromper, comme nombre d’autres distributions CentOS7 utilise l’ensemble netfilter intégré au noyau linux, et attaché au programme iptables, afin d’accéder aux paquets circulant au travers de la pile Réseau du système. Ce sous-système fournit l’interface nécessaire à l’inspection et à la manipulation des paquets. Cela autorise alors l’implémentation d’un pare-feu (aussi appelé firewall). Toutefois, la distribution CentOS7 outre son service iptables, est configuré avec un service alternatif appelé firewalld  remplissant le même office que son prédécesseur. Mais alors, à quoi cela sert-il me direz-vous ? C’est ce que nous allons découvrir maintenant.

L’outil iptables s’installe via le package éponyme et il en existe plusieurs version. On peut tout à fait connaître cette dernière via la commande ci-dessous :

# iptables --version

REMARQUE: l’outil est installé de façon primaire dans le répertoire /usr/sbin/iptables ou dans /sbin/iptables. Mais, dans la mesure où l’utilitaire lui-même est considéré plus comme un service que comme un binaire important, la localisation principale de celui-ci reste /usr/sbin/iptables.

Ce programme est une application autorisant un utilisateur à configurer la sécurité ou du moins, les tables de sécurité du pare-feu, fournies par le pare-feu du noyau linux. Cette fonction manipule également les chaînes qu’un utilisateur peut ajouter ou supprimer, au niveau des règles du firewall, afin d’ajuster la sécurité de ses équipements. En somme, iptables s’appuie sur différents modules du noyau linux, ainsi que différents protocoles permettant aux administrateurs réseau, ou aux administrateurs système d’en tirer profit.

Les règles iptables ne peuvent être exécutées que si l’on possède le privilège du super-utilisateur root et ces dernières s’appuient sur les notions de chaines (aussi appelées points d’inspection du trafic) et de tables pilotées par des règles de sécurité. On peut schématiser cela par le graphe ci-dessous :

Les règles permettent alors de filtrer les flux selon le type de chaîne impliquée. On peut facilement lister l’ensemble des règles sur l’ensemble des chaînes grâce à la commande suivante :

# iptables -L

On peut également vider l’intégralité d’une chaîne en particulier, via la commande suivante :

# iptables -F <Chaîne>

Mais, dès que l’on effectue une modification quelconque sur l’une de ces chaînes, il est nécessaire de recharger l’intégralité de la configuration ou d’arrêter et redémarrer le service :

# systemctl reload iptables

ou

# systemctl restart iptables

Ainsi, ce service présente l’énorme inconvénient de ne pas être dynamique. C’est pourquoi, les développeurs ont imaginé une extension dette fonctionnalité permettant d’être intégralement gérée de façon dynamique : firewalld.

REMARQUE: pour celles et ceux qui n’ont pas besoin d’un tel niveau de réactivité, il est toujours possible de n’utiliser que le service iptables et les tables netfilter. Mais, il est dommage de ne pas se servir des fonctionnalités et des nouveautés proposées par la distribution. De plus, parmi les services de filtrage proposés par Linux, iptables n’est pas le seul, on peut compter aussi sur ebtables.

III. Le service firewalld

Le service firewalld est un des nombreux services de la nouvelle architecture SystemD adossée au type dbus fournissant les éléments suivants:

  • une applet
  • une interface graphique
  • une interface en ligne de commande
  • une interface D-Bus

Ce service est lui-même un moyen de dialogue entre le module netfilter du noyau linux et ses modules complémentaires. Ainsi, en interne, on peut manipuler les différentes commandes mentionnées précédemment, c’est-à-dire :

  • iptables
  • ip6tables
  • ebtables

Elles sont utilisées pour gérer les règles de sécurité du module netfilter et de ses dépendances. La configuration par défaut se trouve dans les fichiers du répertoire /usr/lib/filrewalld, dans le format XML. Toutefois, la configuration standard, effectuée par l’administrateur du système, est placée dans le répertoire /etc/firewalld. L’ensemble reste accessible au niveau Réseau, au travers de l’interface standard NetworkManager (ou via les commandes ifconfig ou ip). On peut ainsi représenter l’architecture selon le graphe ci-dessous :

Cette souplesse modulaire permet un certain nombre de fonctionnalités,  autorisant même la gestion des règles d’applications externes pour la virtualisation ou la gestion de service d’impression. Mais, de façon basique, on peut administrer :

  • les zones des différents réseaux.
  • les règles via services, ports, protocoles ou interfaces.
  • les règles personnalisées avec notion de priorité.
  • les droits de configuration des utilisateurs.

IV. La gestion des zones

Pour une configuration classique, un réseau est découpé en zones auxquelles seront appliquées des politiques de sécurité distinctes. On peut ainsi isoler les postes des ressources humaines d’avec ceux utilisés pour la bureautique. Ces derniers pouvant accéder à Internet, on devra traiter le cas d’isolation des autres postes afin de protéger contre les accès frauduleux. Chaque zone du réseau est associé un ensemble de services  accessibles de l’extérieur en fonction  de la confiance accrédité à la zone en question.

Chaque interface réseau peut être ainsi affectée à une zone particulière et on disposera toujours d’une zone par défaut pour les interfaces ou les flux  réseau non affectés explicitement à une zone particulière.

ATTENTION: la politique par défaut du pare-feu est d’autoriser l’ensemble du trafic sortant, ainsi que les connexions précédemment établies. Il convient donc d’en tenir compte pour établir sa politique de sécurité personnalisée.

On distingue alors les zones prédéfinies suivantes :

  • zone drop: le niveau le plus bas de confiance. Toute connexion entrante est supprimée sans notification et seules les connexions sortantes sont autorisées.
  • zone block: zone similaire à celle-ci-dessus, mais au lieu de supprimer les connexions entrantes sans notification, ces flux sont rejetés à l’aide d’un message icmp-host-prohibited (ou icmp6-adm-prohibited pour IPv6).
  • zone public: représente l’ensemble des réseaux publics ou non sécurisés. On ne fait pas confiance aux autres ordinateurs ou serveurs mais, on peut traiter les connexions entrantes au cas par cas à l’aide de règles.
  • zone external: représente les réseaux externes lorsque l’on utilise le pare-feu local comme une passerelle. Dans ce cas, la zone est configurée pour le "masquerading NAT" et les réseaux internes demeurent ainsi privés mais accessibles.
  • zone internal: représente l’autre face de la zone external, utilisée pour la portion interne d’une passerelle. Les serveurs sont totalement accrédités et certains services supplémentaires peuvent mêmes être disponibles.
  • zone dmz: utilisée pour les serveurs au sein d’une zone démilitarisée ou DMZ. Seules quelques connexions entrantes sont alors autorisées.
  • zone work: utilisées pour des machines de travail permettant de faire confiance à la plupart des serveurs du réseau. Quelques services supplémentaires pourront être autorisés.
  • zone home: une zone de sécurité personnelle. Cela implique la plupart du temps que l’on fait confiance aux autres machines et que certains autres services peuvent aussi être accrédités.
  • zone trusted: permet de faire confiance à toutes les machines du réseau. Il s’agit du niveau de confiance le plus élevé à utiliser avec précaution.

Afin de lister les différentes zones disponibles il faut exécuter l’instruction :

# firewall-cmd --get-zones

Les règles que l’on établit alors au sein de ces différentes zones sont de deux natures différentes. Il peut s’agit de règles immédiates ou de règles permanentes. Par défaut, si l’on ne précise pas, les règles instituées le sont de façon immédiate. Lorsqu’une règle est ajoutée ou modifiée, le comportement du pare-feu en cours d’exécution est automatiquement modifié. Mais, si l’on ne stipule pas l’option --permanent, lors du prochain redémarrage, le pare-feu retrouvera ses anciennes règles et son comportement ultérieur.

REMARQUE: la plupart des opérations issues de la commande firewall-cmd peuvent être établies de façon permanente afin d’indiquer le caractère non éphémère de la configuration. Par ailleurs, le service firewalld est installé par défaut sur la plupart des images de CentOS7, mais n’est pas activé.

Si le service n’est pas présent sur le système, il convient de l’installer via la commande suivante :

# yum install firewalld

En tant que service, on peut administrer firewalld en l’arrêtant :

# systemctl stop firewalld

Ou, au contraire, en le démarrant :

# systemctl start firewalld

Une fois le service installé, il faut alors l’activer et redémarrer son serveur :

# systemctl enable firewalld# reboot

Ensuite, pour connaître l’état de son pare-feu, il suffit simplement d’exécuter l’instruction ci-dessous :

# firewall-cmd --state

Lorsque le service n’est pas actif, on devrait recevoir l’affichage ci-dessous (dans le cas contraire, la réponse est ‘running’ :

On peut alors déterminer quelle est la zone sélectionnée comme zone par défaut :

# firewalld-cmd --get-default-zone

Dans la mesure où, nous n’avons fourni au service firewalld aucune commande pour dévier du protocole standard et de la zone par défaut, aucune interface n’est configurée pour être mappée sur une autre zone et celle-ci sera  la seule zone active. Cela peut se vérifier avec la commande :

# firewall-cmd --get-active-zones

Il est aussi possible de lister la configuration de l’ensemble des zones via la commande firewall-cmd --list-all-zones. Afin d’afficher les règles associées à une zone publique, on peut exécuter la commande ci-dessous:

# firewall-cmd --list-all

Bien évidemment, il est possible de détailler l’ensemble de la configuration d’une zone particulière en exécutant la commande ci-dessous:

# firewall-cmd --zone=work --list-all

Afin de forcer la modification de la zone par défaut, on peut ainsi utiliser l’option --set-default-zone. Par exemple pour forcer l’utilisation de la zone dmz par défaut, on exécutera l’instruction ci-dessous:

# firewall-cmd --set-default-zone=dmz

A défaut d’attacher ses interfaces réseau à la zone par défaut, chacune des cartes réseau (donc chacune des interfaces), doit être liée à une zone distincte. Cela peut être modifié grâce à l’une des options --add-interface ou --change-interface, comme le montre la commande suivante (où l’on associe l’interface ens160 à la zone work):

# firewall-cmd --zone=work --change-interface=ens160

De la même façon, on peut aussi supprimer l’interface dédiée d’une zone en utilisant l’option --remove-interface:

# firewall-cmd --remove-interface=ens49 --zone=work

Par ailleurs, on peut délibérément créer ses propres zones d’administration en utilisant l’option --new-zone:

# firewall-cmd --new-zone=privateweb

Dans l’exemple précèdent, on vient ainsi de créer une zone personnalisable appelée privateweb qui apparaîtra lors des requêtes effectuées à l’aide de l’option --get-zones.

ATTENTION: là encore, si l’on ne mentionne pas l’option --permanent, cette nouvelle zone disparaîtra dès le prochain redémarrage du service. Sinon, on peut également simplement recharger la configuration pour que cette nouvelle modification soit désormais prise en compte par le pare-feu :

# firewall-cmd --reload

Dans certains cas plus complexe, on peut avoir besoin de créer une règle spécifique sans ajouter uniquement un port ou un service à une zone. Ce type de règle est justement appelée règle structurée (ou rich rules en anglais). Imaginons que l’on souhaite, par exemple, bloquer le trafic d’une machine ayant l’adresse privée 192.168.1.7 dans notre réseau local. Voici ce que l’on pourrait écrire comme règle structurée :

# firewall-cmd --zone=linuxconfig --add-rich-rule="rule \
    family="ipv4" \
    source address=192.168.1.7 \
    service name=ssh \
    reject \

REMARQUE: la dernière ligne de cet exemple, autorise un mode opératoire parmi les trois proposés par défaut : accept, reject ou drop. La famille s’apparente à IPv4 ou IPv6.

V. La gestion des services

Outre son découpage en zones, le service firewalld permet également de gérer les différents services du système, de la même façon que l’on a vu précédemment pour l’administration des zones. Ainsi, on peut lister les services autorisés ou disponibles :

# firewall-cmd --get-services

REMARQUE: on peut disposer de plus de détails à propos de chacun de ces services en éditant leur fichier .xml au sein du répertoire /usr/lib/firewalld/services :

Pour autoriser un service spécifique, au niveau d’une zone, il suffit alors d’utiliser l’option --add-service.

Exemple: ajout du service web (tcp/80 ou HTTP) pour la zone public:

# firewall-cmd --zone=public --add-service=http

Bien évidemment, si l’on ne précise pas l’option --zone l’ajout s’effectuera alors sur la zone désignée par défaut. Par ailleurs, dans l’exemple précédent, l’ajout se fera de façon dynamique mais non permanente, puisque l’option --permanent n’est pas mentionnée. Pour vérifier que l’opération d’ajout s’est effectuée correctement, on peut utiliser l’une des options suivantes : --list-all ou --list-services.

Nous verrons un peu plus loin qu’ouvrir un port ou une plage de port est très facile. Mais on peut vite perdre ce à quoi sert le port en question ou la plage concernée. En effet, si l’on désactive un service, sur un serveur, on peut être amené à chercher un moment avant de retrouver quels sont les ports attachés à ce service particulier. Plutôt que de perdre du temps, il suffit simplement de configurer un service particulier en recopiant le fichier du service à personnaliser depuis le répertoire /usr/lib/firewalld/services dans le répertoire /etc/firewalld/services.

 

Exemple: recopie du fichier de service SSH :

# cp /usr/lib/firewalld/services/ssh.xml /etc/firewalld/services

On peut alors ajuster et personnaliser la configuration de ce service directement dans la copie que l’on vient de faire. Imaginons que l’on souhaite juste changer le port actif du service SSH de 22 en 2022, il suffira de modifier le texte de la copie en :

<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>SSH</short>
  <description>Secure Shell (SSH) is a protocol for logging into and executing commands on remote machines. It provides secure encrypted communications. If you plan on accessing your machine remotely via SSH over a firewalled interface, enable this option. You need the openssh-server package installed for this option to be useful.</description>
  <port protocol="tcp" port="2022"/>
</service>

ATTENTION: il s’agit ici de l’une des rares fois où il faut recharger la configuration du pare-feu en exécutant la commande suivante :

# firewall-cmd --reload

Parmi les nombreuses options de l’outil, on distingue un mode appelé panic pouvant être utilisé uniquement dans des situations où on rencontre de sérieux problèmes avec l’environnement réseau. Lorsque ce mode est actif, toutes les connexions existantes sont ignorées et tous les paquets entrant et sortant sont supprimés. L’activation d’un tel mode de fonctionnement s’obtient en exécutant l’instruction suivante :

# firewall-cmd --panic-on

A l’inverse, pour sortir de ce mode de fonctionnement, il suffit simplement d’exécuter :

# firewall-cmd --panic-off

Pour savoir dans quel mode opératoire on se trouve, il est possible d’interroger le pare-feu via la commande suivante :

# firewall-cmd --query-panic

ATTENTION: ces modes de fonctionnement ne sont valables que dans le cas où l’on ne mentionne pas l’option --permanent : c’est-à-dire en mode runtime.

VI. La gestion des ports

Dans certains cas, il existe des scenarii où les services ne répondent pas aux prérequis de notre infrastructure. Dans cette situation, on peut alors ouvrir spécifiquement un port sur la zone en question, de la même façon qu’on l’a fait pour la gestion des services.

Ainsi, l’ouverture d’un port spécifique s’effectuera à l’aide de l’option --add-port de la façon suivante :

# firewall-cmd --zone=public --add-port=1521/tcp

On peut alors vérifier que l’opération se termine correctement en exécutant la commande ci-dessous, permettant d’afficher les ports ouverts dans la zone par défaut:

# firewall-cmd --list-ports

REMARQUE: dans le cas précédent, la commande permet d’ajouter le port TCP/1521 (service sql*net) sur la zone public de façon dynamique. Si l’on souhaite l’ajouter de façon permanente, il faut penser à utiliser l’option --permanent.

Afin d’éviter l’accroissement de l’écriture de nombreuses règles, il est également possible d’ajouter non pas un port mais une plage de ports en séparant le premier et le dernier de la plage avec un tiret :

# firewall-cmd --zone=public --add-port=3990-4100/udp

Dans certains cas de figure, on peut être amené à effectuer un transfert de flux d’un port vers un autre. On parle alors de port forwarding. Le pare-feu firewalld le permet également. Dans le cas, par exemple où l’on souhaite transférer un flux du port TCP/22 (SSH) vers un port d’un autre service TCP/3800, on devra alors exécuter la commande suivante :

# firewall-cmd --zone=work --add-forward-port=22:proto=tcp:toport=3800

De la même façon, lorsque l’on souhaite faire en sorte que tous les équipements du réseau interne utilisent la même adresse IP à l’extérieur (on parle alors de port masquerading), on peut également mettre cela en place, depuis le firewall, via l’instruction suivante :

# firewall-cmd --zone=external --add-masquerade

Au travers du mode en ligne de commande, on peut parfaitement configurer des règles spécifiques, écrite à l’identique (ou presque) de celles du pare-feu iptables, en utilisant l’option éponyme --direct.

Exemple: ajout d’un port TCP/3600:

# firewall-cmd --direct --add-rule ipv4 filter INPUT 0 -p tcp --dport 3600 -j ACCEPT

ATTENTION: ce genre de règle ne doit être utilisée qu’en dernier ressort, lorsque l’on ne peut absolument pas ajouter de service via l’option --add-service.

Pour supprimer une règle, de la même façon qu’on en ajoute une avec l’option --add-rule, il suffit d’utiliser l’option --remove-rule. L’avantage de ce mode direct c'est que l'on peut ajouter dynamiquement les règles, sans avoir à recharger la configuration. On peut ainsi lister l’ensemble des règles ajoutées en direct grâce à la commande :

# firewall-cmd --direct --get-all-rules

RAPPEL: comme pour le pare-feu iptables, il est également possible d’appliquer une règle, non plus à une adresse IP, mais à un ensemble d’adresses via les règles ipset. Ces règles sont de deux natures :

  • hash:ip
  • hash:net

Dans les deux cas, pour créer une règle ipset permanente, on peut exécuter la commande suivante :

# firewall-cmd --permanent --new-ipset=blacklist --type=hash:ip

On doit alors bien évidemment recharger la configuration avant d’entrer la liste des adresses à utiliser dans cette liste nouvellement créées:

# firewall-cmd --reload
# firewall-cmd --ipset=blacklist --add-entry=192.168.1.30
# firewall-cmd --ipset=blacklist --add-entry=192.168.1.31

Si l’on souhaite lister le contenu de la nouvelle liste d’adresses, on peut exécuter l’instruction ci-dessous:

# firewall-cmd --info-ipset=blacklist

L’opération inverse de suppression d’un membre d’une liste s’effectue via la commande suivante :

# firewall-cmd --ipset=blacklist --remove-entry=192.168.1.31

Suite à cela, il est alors possible de lister les membres restants de notre liste grâce à la commande ci-dessous :

# firewall-cmd --ipset=blacklist --get-entries

Si au lieu de supprimer un ou plusieurs éléments d’une liste ipset on souhaite supprimer la liste elle-même, alors il faut procéder à l’opération suivante :

# firewall-cmd --permanent --delete-ipset=blacklist

REMARQUE: à la suite de cette dernière commande il faut également recharger la configuration du pare-feu. On peut également lister les listes ipset restantes en utilisant l’option --get-ipsets.

VII. La gestion des modules et du mode offline

Il peut arriver que l’on ait besoin de télécharger certains modules spécifiques. Plutôt que d’utiliser un fichier rc.local il est préférable d’avertir le pare-feu firewalld au travers du répertoire /etc/modules-load.d .

Exemple: ajout d’options pour FTP:

# echo ip_nat_ftp > /etc/modules-load.d/firewalld-ftp.conf
# echo ip_conntrack_ftp >> /etc/modules-load.d/firewalld-ftp.conf

En parlant des modules, il arrive parfois que l’on ait besoin d’ajouter de nouvelles règles de sécurité lorsque le pare-feu n’est pas encore actif. C’est notamment le cas, lors des installations via Anaconda ou kickstart. On peut alors utiliser la commande firewall-offline-cmd, prévue à cet effet. Imaginons que nous souhaitions ouvrir le port TCP/22 (SSH), avec l’utilitaire iptables, on ajouterait la ligne ci-dessous, au fichier de configuration /etc/sysconfig/iptables :

-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT

Mais, grâce à la commande firewall-offline-cmd, il suffit simplement d’exécuter:

# firewall-offline-cmd --direct --add-rule ipv4 filter INPUT 0 -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT

A l’identique du fonctionnement d’iptables, il est également possible de sauvegarder la configuration complète du pare-feu grâce aux commandes suivantes (ip6tables –S pour IPv6):

# iptables –S > firewalld_rules

VIII. L'interface graphique

Le service firewalld, comme nous l’avons mentionné au début de ce tutoriel possède également une interface graphique que l’on peut lancer directement depuis un shell grâce à la commande firewall-config :

ATTENTION : cette interface doit disposer du service firewalld actif (sinon, l’interface elle-même ne s’ouvrira jamais), et on doit être connecté au compte root sinon, il faudra saisir le mot de passe du super-utilisateur :

Cette interface autorise les mêmes fonctionnalités qu’en mode commande, à savoir la gestion des zones, des services, des ports et des règles ipset, ainsi que des modules spéciaux. Il existe également une applet liée à l’interface X11 du système appelée firewall-applet permettant de visualiser l’état du pare-feu ainsi que les problèmes relatifs à un utilisateur ou à un environnement applicatif particulier. Cette applet peut être installée via le package firewall-applet.

IX. Conclusion

Voilà, avec tout cela vous êtes parés pour sécuriser vos serveurs et vos machines en filtrant plus finement et de façon plus sécurisée les flux, les services et les ports pour lesquels on a une entière confiance. Pour celles et ceux qui ont encore des doutes, il est toujours possible de conserver le mode de fonctionnement antérieur à base de règles iptables.

Mais, il est vrai qu’il est quand même fortement conseillé d’utiliser le nouvel outil firewalld et ses fonctionnalités étendues, plutôt qu’un outil devenant de facto obsolète d’ici quelques temps (ou du moins qui risque de le devenir).

Un bémol toutefois, il est raisonnable de n’utiliser qu’un seul outil à la fois. Si vous êtes habitués à l’un ou l’autre des outils, conservez votre mode de fonctionnement. Mais, surtout n’activez pas simultanément iptables et firewalld, sinon vous risquez d’avoir un comportement hasardeux voire même contradictoire car les règles pourraient se chevaucher ou s’annihiler.

Partagez cet article Partager sur Twitter Partager sur Facebook Partager sur Linkedin Partager sur Google+ Envoyer par mail

Philippe PIERRE

A exercé de nombreuses années en tant qu'administrateur de base de données et comme administrateur Système Unix/Linux. Il a enseigné les réseaux au CNAM (Paris). Aujourd'hui, employé en tant qu'ingénieur infrastructure, au sein d'un laboratoire pharmaceutique et administrant un cluster de calculs HPC, il connaît parfaitement les environnements GNU/Linux dans le cadre d'une entreprise et des systèmes de haute disponibilité. Il aime partager son expérience.

Nombre de posts de cet auteur : 69.Voir tous les posts

9 thoughts on “CentOS 7 : Utilisation et configuration de firewalld

  • La création d’un IPSET n’a d’utilité que si rattaché à une zone 😉
    Après, ce qu’il faut ajouter, c’est qu’une zone peut soit être déclenchée par son interface, soit par les sources IP de l’ipset.
    Cependant, pour améliorer la sécurité du réseau (pour de l’intranet), il est possible de cumuler l’interface et un IPSET (ou une adresse / tranche IP) pour accéder au service défini dans la zone. Pour cela, il faut définir une règle riche (ce qui permet aussi de loguer éventuellement les connections).

    Sinon, je suis en attente d’une sécurisation des flux sortants, sans passer par les règles directes (que vous utilisez par les commandes iptables) car le risque est grand d’obtenir des conflits entre ces règles et celles des fichiers de zones (ce qui est déjà le cas avec les règles de flux entrants).

    Répondre
    • Bonsoir,
      Effectivement. D’accord avec vous: la création d’un ipset n’a d’utilité que si il est rattaché à une zone. De plus, une zone peut être associée par son interface ou par les sources IP de la plage ipset.
      Pour ce qui est des flux sortants, on peut sécuriser en forçant un proxy (éventuellement même avec un reverse proxy). Cela reporte les flux sur une passerelle mandataire que l’on peut alors mieux contrôler au travers d’un portail captif.
      Enfin, effectivement l’utilisation de règles directes et celles des fichiers de zones simultanément, peuvent à coup sûr provoquer des conflits.
      Merci pour votre commentaire. J’essaierai à l’occasion de compléter le tutoriel avec vos remarques.

      Répondre
  • Bonjour

    J’ai configuré la rich-rule sudo firewall-cmd –permanent –zone public –remove-rich-rule ‘rule family= »ipv4″ source address= »192.168.0.1″ service name= »http » log prefix= »http_192.168.0.1″ accept’ mais je ne vois aucun log dans /var/log

    cdt

    Répondre
    • Bonjour,

      Pour ce qui concerne les logs, il faut peut-être regarder comment est configuré rsyslogd (dans /etc/rsyslog.conf). Il se peut que les journaux soient redirigés vers un autre répertoire ou un autre fichier. Par défaut le tout se trouve dans messages. Mais, il se peut que cela soit rediriger ailleurs. On peut normalement voir l’activité du kernel buffer (ou buffer ring), au niveau de dmesg (fichier /var/log/dmesg ou commande dmesg).
      Sans plus d’éléments de contexte c’est difficile de déterminer ce qui pose problème 🙂

      Cordialement
      Ph. PIERRE

      Répondre
  • Bonjour, merci pour ce post c’est très intéressant.
    J’ai centos 7 sur un VPS, je veux qu’une application soit accessible depuis internet comme par exemple https://mon-ip-externe:PPPP/mon_application; pour cela j’ai fait ceci:
    firewall-cmd –permanent –add-port=PPPP/tcp mais à ma grande surprise je ne peux pas accéder à l’application.

    Répondre
    • Je pense qu’il manque deux choses:
      1°) le choix de la zone
      2°) l’ajout de l’adresse IP

      Au final on devrait avoir quelque chose comme ça:
      firewall-cmd –permanent –zone=public –add-source= –add-port=PPPP/tcp

      A tester donc avec ce descriptif afin d’ajouter l’url et le port en question sur la zone publique.
      Normalement, cela devrait régler votre problème.

      Cordialement
      Ph. PIERRE

      Répondre
      • merci pour votre réaction,
        –add-source=? , quelle adresse dois-je mettre?

        Répondre
        • Bonsoir,

          Il faut mettre l’adresse IP du serveur Web portant l’application web (c’est-à-dire l’adresse IP du serveur où se trouvent les pages http).

          Attention: je n’avais pas vérifié mais en relisant les options de la commande mentionnée précédemment devraient porter un double tiret:
          firewall-cmd –permanent –zone=public –add-source= –add-port=PPPP/tcp

          De plus PPPP/tcp doit être le n° du port de l’url (si elle est différente de 80/tcp).

          Répondre
  • D’accord !
    Merci beaucoup, c’est vraiment gentil de votre part.

    Répondre

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.