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 NeoX . Évalué à 4.
je dirais que tu as bloqué les paquets IPv4 mais pas les paquets ICMP :p
[^] # Re: ping = ICMP
Posté par WhiteCat . É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 nono14 (site web personnel) . Évalué à 4.
normal les ports 0-1023 sont pas bloqués :p
Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
[^] # Re: ping = ICMP
Posté par WhiteCat . Évalué à 1.
Ba je veux pas bloquer ces ports. Je veux juste bloquer tout ce qui vient (ou va) vers 172.16.30.254.
Sur la doc Red Hat (enfin c'est juste un post de forum mais bon) c’est pas précisé qu'il faut spécifier des ports en plus : https://access.redhat.com/discussions/1342573
[^] # Re: ping = ICMP
Posté par NeoX . Évalué à 3. Dernière modification le 14 décembre 2016 à 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 WhiteCat . É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 NeoX . Évalué à 2.
[^] # Re: ping = ICMP
Posté par WhiteCat . Évalué à 2. Dernière modification le 14 décembre 2016 à 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 nono14 (site web personnel) . Évalué à 2.
tcpdump ou wireshark pour voir les paquets en temps réel
Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
[^] # Re: ping = ICMP
Posté par WhiteCat . É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 nono14 (site web personnel) . É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 - Ouvert à de nouvelles opportunités
[^] # Re: ping = ICMP
Posté par WhiteCat . É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 nono14 (site web personnel) . Évalué à 3. Dernière modification le 14 décembre 2016 à 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 - Ouvert à de nouvelles opportunités
[^] # Re: ping = ICMP
Posté par WhiteCat . Évalué à 2.
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 NeoX . Évalué à 1.
heu, c'est iptables--save pour sortir ce qu'il y a en cours avec iptables ;)
[^] # Re: ping = ICMP
Posté par Marotte ⛧ . Évalué à 2. Dernière modification le 14 décembre 2016 à 21:59.
Non. Enfin oui et non.
iptables --list(-L) va bien te sortir les règles de filtrage courantes.iptables-savelui 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 NeoX . Évalué à 3.
tu as regardé à quelles zones etaient rattachées tes cartes reseaux ?
si ca se trouve tu met un regle sur une zone, mais les cartes sont dans une autre zone
et
et dans la sortie de ton test
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 WhiteCat . É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 Donk . Évalué à 1.
Pour écouter le trafic dhcp, tu peux utiliser dhcpdump
[^] # Re: Trafic dhcp
Posté par WhiteCat . É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 Donk . É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 WhiteCat . É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 pralines . É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 WhiteCat . Évalué à 2.
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 ?!
Merci pour l'info. Je viens de tester et en effet ça marche bien ! J'ai pu blacklister mon serveur DHCP légitime.
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 claudex . Évalué à 3.
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 WhiteCat . Évalué à 2.
J'avais rajouté la "rule" de blocage pour la destination et la source en fait aussi.
[^] # Re: Trafic dhcp
Posté par claudex . É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 NeoX . Évalué à 3.
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 WhiteCat . Évalué à 2.
OK c'est bon à savoir !
[^] # Re: Trafic dhcp
Posté par nono14 (site web personnel) . É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 - Ouvert à de nouvelles opportunités
# Destination
Posté par claudex . É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.