Forum Linux.redhat firewalld, l'Advance des pare-feux ?

Posté par . Licence CC by-sa
Tags :
0
14
déc.
2016

Bonjour,

Je post ici pour vous demander si c'est moi qui suis con et ne sais pas utiliser firewalld, ou bien si ce pare-feu est une merde qui ne fais même pas le minimum qu'on lui demande ?

Alors j'ai eu ma première expérience quand j'ai voulu m'intéresser un peu à ce pare-feu lorsqu'il est apparu avec CentOS 7.
Je me suis logiquement tourné vers la doc officielle de Red Hat, et j'avais constaté alors que le simple argument "--permanent" ne fonctionnait pas. Bon a priori aujourd'hui cela semble bien fonctionner mais on voyait déjà que ça partait mal dès le début. Le truc qui a été jeté par les dev en prod sans QA.

Puis j'avais mis de côté ma "formation" à ce pare-feu pendant un long moment jusqu'à la semaine dernière. J'avais un besoin que je vous expose brièvement. Dans la boîte où je bosse, sur un réseau isolé qui contient quelques machines dont on ne maîtrise pas totalement ce qu'il y a dessus, je soupçonnais le fait qu'il y ai un 2e serveur DHCP sur le LAN. Chose anormale.
Je me suis donc dit que j'allais mettre un PC avec Fedora sur le réseau et que j'allais bloqué avec le pare-feu du PC l'adresse IP du serveur DHCP légitime. Ainsi s'il y a un 2e serveur DHCP c'est forcément lui qui devrait répondre à mon PC.

Donc je configure firewalld pour bloquer l'adresse IP de mon serveur DHCP légitime :
# firewall-cmd --permanent --add-rich-rule="rule family=ipv4 source address=172.16.30.254/32 drop"
success

# systemctl restart firewalld

# firewall-cmd --list-all
FedoraWorkstation (active)
target: default
icmp-block-inversion: no
interfaces: wlp1s0
sources:
services: dhcpv6-client ssh mdns samba-client
ports: 1025-65535/udp 1025-65535/tcp
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
rule family="ipv4" destination address="172.16.30.254/32" drop

Donc tout est OK. Normalement je ne suis plus censé pouvoir communiquer avec 172.16.30.254 ?!

$ ping 172.16.30.254
PING 172.16.30.254 (172.16.30.254) 56(84) bytes of data.
64 bytes from 172.16.30.254: icmp_seq=1 ttl=64 time=3.20 ms
64 bytes from 172.16.30.254: icmp_seq=2 ttl=64 time=6.32 ms
C
--- 172.16.30.254 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 3.202/4.764/6.327/1.564 ms

WTF ?!

  • # ping = ICMP

    Posté par . Évalué à 4.

    rule family="ipv4" destination address="172.16.30.254/32" drop
    Donc tout est OK. Normalement je ne suis plus censé pouvoir communiquer avec 172.16.30.254 ?!

    $ ping 172.16.30.254
    PING 172.16.30.254 (172.16.30.254) 56(84) bytes of data.
    64 bytes from 172.16.30.254: icmp_seq=1 ttl=64 time=3.20 ms
    64 bytes from 172.16.30.254: icmp_seq=2 ttl=64 time=6.32 ms
    C
    --- 172.16.30.254 ping statistics ---
    2 packets transmitted, 2 received, 0% packet loss, time 1001ms
    rtt min/avg/max/mdev = 3.202/4.764/6.327/1.564 ms

    WTF ?!

    je dirais que tu as bloqué les paquets IPv4 mais pas les paquets ICMP :p

    • [^] # Re: ping = ICMP

      Posté par . Évalué à 2.

      Ah ah OK j'avoue mon test est foireux :D
      Ceci dit, j'ai toujours des paquets DNS qui passent très bien avec 172.16.30.254 donc le blocage ne fonctionne vraiment pas.

      J'ai ajouté :
      # firewalld-cmd --permanent --add-icmp-block=echo-reply

      Mais le ping passe toujours aussi bien…

      • [^] # Re: ping = ICMP

        Posté par (page perso) . Évalué à 4.

        normal les ports 0-1023 sont pas bloqués :p

        Système - Réseau - Sécurité Open Source

      • [^] # Re: ping = ICMP

        Posté par . Évalué à 3. Dernière modification le 14/12/16 à 12:23.

        il manque peut-etre un sens au blocage.

        si ca se trouve, avec ta regle tu bloques les icmp-echo-reply qui viennent de TA machine
        mais si depuis cette machine, tu fais un ping vers une autre,
        tu emet un icmp-echo-request, et la machine en face te repond avec un reply.

        avec iptables il y a la notion d'interface IN/OUT
        et des regles INPUT et OUTPUT

        ca ne m'etonnerait pas qu'on ait des moyens similaires avec firewalld

        • [^] # Re: ping = ICMP

          Posté par . Évalué à 2.

          Oui c’est ce que je me suis dit aussi, du coup j'ai aussi ajouté le blocage "echo-request" mais c’est pareil.

          • [^] # Re: ping = ICMP

            Posté par . Évalué à 2.

            autre question, tu fais la regle firewalld sur quel machine ?
            et tu fais ton test de ping depuis quelle machine ?

            • [^] # Re: ping = ICMP

              Posté par . Évalué à 2. Dernière modification le 14/12/16 à 12:25.

              Je fais tout depuis la même machine (un PC portable sur Fedora 24).
              L'adresse IP 172.16.30.254 que j'essaye de bloquer est un modem-routeur D-Link.

              • [^] # Re: ping = ICMP

                Posté par (page perso) . Évalué à 2.

                tcpdump ou wireshark pour voir les paquets en temps réel

                Système - Réseau - Sécurité Open Source

                • [^] # Re: ping = ICMP

                  Posté par . Évalué à 2.

                  Ben oui et ça me montre que les paquets passent tranquillement sans problème, je ne suis pas plus avancé :D

                  • [^] # Re: ping = ICMP

                    Posté par (page perso) . Évalué à 3.

                    Bien sur que si, tu identifies les paquets ( protocole, sens, ip, ports, … )

                    C'est le seul moyen de trouver quand on connait pas ça par coeur.

                    Système - Réseau - Sécurité Open Source

                    • [^] # Re: ping = ICMP

                      Posté par . Évalué à 2.

                      Je ne suis pas sûr de bien comprendre ce que tu me suggères.
                      J'ai bien sûr déjà regardé ce qui passe sur le réseau de ma carte avec Wireshark, c'est pour ça que je vois bien des requêtes DNS passer de/vers 172.16.30.254 alors que le firewalld est censé bloquer tout le traffic de/vers cette IP.

                      • [^] # Re: ping = ICMP

                        Posté par (page perso) . Évalué à 3. Dernière modification le 14/12/16 à 14:45.

                        firewall-cmd --list-all

                        FedoraWorkstation (active)
                        target: default
                        icmp-block-inversion: no
                        interfaces: wlp1s0
                        sources:
                        services: dhcpv6-client ssh mdns samba-client
                        ports: 1025-65535/udp 1025-65535/tcp
                        protocols:
                        masquerade: no
                        forward-ports:
                        source-ports:
                        icmp-blocks:
                        rich rules:
                        rule family="ipv4" destination address="172.16.30.254/32" drop

                        ça parait clair les ports inférieurs à 1024 sont pas bloqués

                        rule family="ipv4" destination address="172.16.30.254/32" drop

                        ajouter source pour avoir:
                        rule family="ipv4" source address="172.16.30.254/32" drop
                        ou rule family="ipv4" address="172.16.30.254/32" drop ?

                        Si tu sais pas ce que ça fait, listes les règles ça doit utiliser iptables, non ?

                        C'est le soucis des couches d'abstraction, on sait pas ce que ça fait en dessous.

                        Système - Réseau - Sécurité Open Source

                        • [^] # Re: ping = ICMP

                          Posté par . Évalué à 2.

                          Si tu sais pas ce que ça fait, listes les règles ça doit utiliser iptables, non ?

                          En effet, aucune trace de mon IP 172.16.30.254 avec "iptables --list"
                          Même après reboot tu PC.

                          • [^] # Re: ping = ICMP

                            Posté par . Évalué à 1.

                            heu, c'est iptables--save pour sortir ce qu'il y a en cours avec iptables ;)

                            • [^] # Re: ping = ICMP

                              Posté par . Évalué à 2. Dernière modification le 14/12/16 à 21:59.

                              Non. Enfin oui et non. iptables --list (-L) va bien te sortir les règles de filtrage courantes.

                              iptables-save lui va te sortir les commandes qu’il faut exécuter pour mettre en place ces règles.

                              Ce n’est pas la même chose. Même si au fond c’est la même information, un --list te sort un truc plus lisible qu’iptables-save…

                              Après avoir lu tout le fil je penche pour la piste : "les ports <1025 ne sont pas filtrés par firewalld" évoquée par nono14

                              Pourquoi ? c’t’une bonne question…

                              Perso j’utilise shorewall, j’en suis tout à fait satisfait.

                  • [^] # Re: ping = ICMP

                    Posté par . Évalué à 3.

                    tu as regardé à quelles zones etaient rattachées tes cartes reseaux ?

                    https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-using-firewalld-on-centos-7

                    si ca se trouve tu met un regle sur une zone, mais les cartes sont dans une autre zone

                    firewall-cmd --get-default-zone

                    et

                    firewall-cmd --get-active-zones

                    et dans la sortie de ton test

                    target: default
                    icmp-block-inversion: no
                    interfaces: wlp1s0

                    j'imagine que c'est la carte wifi ?
                    c'est la dessus du tu veux bloquer, ou c'est sur le filaire ?

                    • [^] # Re: ping = ICMP

                      Posté par . Évalué à 2.

                      Oui c’est bien la bonne zone et la bonne carte :

                      # firewall-cmd --get-default-zone
                      FedoraWorkstation

                      # firewall-cmd --get-active-zone
                      FedoraWorkstation
                      interfaces: wlp1s0

                      wlp1s0 est effectivement ma carte WiFi, sur laquelle je veux faire le blocage. La carte filaire n'est pas connectée.

  • # Trafic dhcp

    Posté par . Évalué à 1.

    Pour écouter le trafic dhcp, tu peux utiliser dhcpdump

    • [^] # Re: Trafic dhcp

      Posté par . Évalué à 2.

      Merci pour la suggestion, mais d'après la doc ça ne fait que parser (de manière plus complète je suppose) les dump de tcpdump. Donc je ne vois pas en quoi ça m'aide.
      Ah et puis le paquet est pas dispo sur Fedora :/

      • [^] # Re: Trafic dhcp

        Posté par . Évalué à 1.

        Il va t'afficher, en direct, toutes les requêtes dhcp qu'il voit passer sur le réseau

        • [^] # Re: Trafic dhcp

          Posté par . Évalué à 2.

          Comme Wireshark donc. Mais ça ne m'aide en rien. Moi je veux forcer mon PC à communiquer avec un serveur DHCP inconnu, et pour ça je dois définitivement couper la communication entre mon PC et mon serveur DHCP légitime (afin qu'il ne me réponde pas).
          Si mon PC obtient un bail DHCP de mon serveur DHCP légitime, mon PC ne fera plus beaucoup de requêtes DHCP et donc aucune raison de voir un autre serveur DHCP dans mes traces réseau.

          • [^] # Re: Trafic dhcp

            Posté par (page perso) . Évalué à 2.

            je ne suis pas expert réseau, mais je pense que tu ne vas pas y arriver comme ça

            ton pc fedora n'a pas encore d'adresse ip, il ne peut donc pas s'adresser à un serveur dhcp en spécifiant son @ip (celle du serveur),
            au lieu de ça, le pc client va envoyer un message en broadcast à toutes les machines du réseau, le premier serveur dhcp à répondre va te proposer une adresse ip

            je ne sais pas si tu peux refuser l'offre venant d'un serveur spécifique, sur mon client dchp, j'ai vu des options whitelist/blacklist mais je n'ai pas essayé

            en revanche, si tu as la main sur le serveur dhcp officiel, tu peux probablement le configurer pour ne pas communiquer avec l'@mac de ton pc fedora de test

            Envoyé depuis mon Archlinux

            • [^] # Re: Trafic dhcp

              Posté par . Évalué à 2.

              ton pc fedora n'a pas encore d'adresse ip, il ne peut donc pas s'adresser à un serveur dhcp en spécifiant son @ip (celle du serveur), au lieu de ça, le pc client va envoyer un message en broadcast à toutes les machines du réseau, le premier serveur dhcp à répondre va te proposer une adresse ip

              OK je vois ce que tu veux dire.
              Cependant si je regarde mes traces réseaux Wireshark, je vois ma requête DHCP partir (de 0.0.0.0 vers 255.255.255.255) et une réponse revenir de mon serveur DHCP légitime (172.16.30.254). Donc si mon pare-feu bloque cette IP, je n'aurais pas du voir cette trame. Enfin je pense.
              Ou alors Wireshark peut voir toutes les paquets/trames réseaux avant même que le pare-feu ne s'en occupe ?!

              je ne sais pas si tu peux refuser l'offre venant d'un serveur spécifique, sur mon client dchp, j'ai vu des options whitelist/blacklist mais je n'ai pas essayé

              Merci pour l'info. Je viens de tester et en effet ça marche bien ! J'ai pu blacklister mon serveur DHCP légitime.

              en revanche, si tu as la main sur le serveur dhcp officiel, tu peux probablement le configurer pour ne pas communiquer avec l'@mac de ton pc fedora de test

              J'ai la main dessus mais c'est un serveur DHCP intégré à un routeur D-Link et y'a pas d'option pour bloquer une machine à ce niveau. Dommage oui sinon ça aurait été plus simple !

              • [^] # Re: Trafic dhcp

                Posté par (page perso) . Évalué à 3.

                Donc si mon pare-feu bloque cette IP

                Sauf que ton parefeu bloque les paquets à destination de cette IP pas les paquets venant de cette IP.

                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                • [^] # Re: Trafic dhcp

                  Posté par . Évalué à 2.

                  J'avais rajouté la "rule" de blocage pour la destination et la source en fait aussi.

                  • [^] # Re: Trafic dhcp

                    Posté par (page perso) . Évalué à 3.

                    Dans ce cas, il faut voir si firewalld n'accepte pas par défaut les paquets RELATED.

                    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

              • [^] # Re: Trafic dhcp

                Posté par . Évalué à 3.

                Ou alors Wireshark peut voir toutes les paquets/trames réseaux avant même que le pare-feu ne s'en occupe ?!

                oui wireshark voit les paquets quand ils arrivent sur l'interface
                donc AVANT le firewall.

                c'est d'ailleurs le piege quand tu fais du diag,
                il faut ensuite aller voir dans les logs du firewall pour savoir si c'est ACCEPT ou REJECT/DROP

                ou quand c'est une regle traversante, (WAN-LAN par exemple) il faut voir sur la carte sortante,
                et si tu ne precises pas, si tu vois une seule ligne c'est que c'est bloqué quelques parts dans le firewall

                • [^] # Re: Trafic dhcp

                  Posté par . Évalué à 2.

                  oui wireshark voit les paquets quand ils arrivent sur l'interface
                  donc AVANT le firewall.

                  OK c'est bon à savoir !

          • [^] # Re: Trafic dhcp

            Posté par (page perso) . Évalué à 2.

            C'est pas certain , tu connais les paquets de niveau 2 ?

            Aucune chance de filtrer cela avec iptables => arptables pour le niveau 2

            Le dhcp ça fonctionne au niveau 2 avant d'obtenir une ip pour le client.

            ça depend de l'architecture, des switchs, tu vois pas forcement les requetes dhcp, c'est pas un hub…

            Système - Réseau - Sécurité Open Source

  • # Destination

    Posté par (page perso) . Évalué à 3.

    Alors je ne connais pas firewalld mais il faudrait savoir si tu bloque en INPUT, en FORWARD ou en OUTPUT. Si tu bloque en forward, ça ne change rien pour ta machine. En plus, tu bloque la destination, mais en DHCP, on fait du broadcast pour demander qui peut donner une IP, donc ça ne change pas grand chose. Il faudrait mieux bloquer les paquets provenant de ton dhcp que ceux allant vers ton dhcp.

    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.