Aller au contenu principal ↑ ↓
Sujet: Comprendre le log de firewalld (Lu 5273 fois) sujet précédent - sujet suivant

Comprendre le log de firewalld

Bonjour à toutes et tous

J'ai enfin réussi à avoir plus d'information sur l'activité de firewalld dans son log (modification de la ligne LogDenied=all dans /etc/firewalld/firewalld.conf). Il était vraiment très peu loquace !

Je vois qu'il y a beaucoup d'activités qui ne semblent pas liées à la machine en elle-même ; soit je ne comprends pas l'information dans le log soit je ne comprends pas ce qui se passe sur mon réseau.

Voici un exemple d'activité enregistrée dans le log de firewalld et que je ne comprends pas :
Code: [Sélectionner]
2020-01-14T19:14:43.464607+01:00 linux-q3fi kernel: [  658.678849] FINAL_REJECT: IN=eth0 OUT= MAC=01:00:5e:00:00:fb:80:82:23:7d:8d:e1:08:00 SRC=192.168.0.31 DST=224.0.0.251 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=50574 PROTO=2

Ma compréhension : la source (192.168.0.31), qui est mon téléphone, essaye de contacter 224.0.0.251 (je ne sais pas qui sait mais ce n'est pas sur mon réseau et encore moins la machine dont le log du pare-feu est issu) et c'est rejeté par le pare-feu de mon serveur HTPC qui n'est pas une de ces adresses.

Où est-ce que je rate une étape ?

Merci pour vos lumières.

A+

Re : Comprendre le log de firewalld

Répondre #1 –
The tag is FINAL_REJECT, which tells us that this message was created by the catch-all,
final REJECT rule that's at the end of our input chain. (source: un livre)
-> Ton paquet a été rejeté, ceci est dû à la dernière ligne de la CHAIN INPUT de la table FILTER (ou une autre, je ne sais pas trop), selon ce qui est écrit

When using REJECT rules an ICMP packet is sent indicating the port is unavailable. (source internet)
-> le client qui a envoyé le paquet rejeté est informé du rejet

01:00:5e:00:00:fb -> ton adresse mac (codée sur 6 octets)
80:82:23:7d:8d:e1 -> l'adresse mac de la destination
08:00 -> je ne sais pas ?

LEN : la longueur total du paquet IP (l’entête et les données)

TOS: type de service, (0x00)  Normal-Service
PREC: la precedence (...)
On trouve ces deux champs dans l’entête du paquet.

TTL : time to live , 1 ce n'est pas beaucoup non ?

ID: The datagram ID is either the
packet ID or the segment to which this TCP fragment belongs.

PROTO: type de protocole contenu dans le paquet: 2 = IGMP,  internet group management protocol.
(tcp = 6 ; udp = 17 )

Quant à 224.0.0.251, apparemment c'est l'adresse  IP Multicast
When an mDNS client needs to resolve a hostname, it sends an IP multicast query message that asks the host having that name to identify itself. That target machine then multicasts a message that includes its IP address. All machines in that subnet can then use that information to update their mDNS caches.
=> Un client a émis une requête mDNS pour résoudre un nom d’hôte, il cherche l'IP ce nom d’hôte (je pense que tu es ce nom d’hôte). Ta machine, en réponse à cette requête, répond en Multicast, c'est a dire à toutes les machines de ton sous-reseau (dans un cas simple, il n'y a pas de sous-reseau, et je pense que ta machine a donc répondu à cette requête en Mulicast sur ton réseau local, avec cette ip Multicast 224.0.0.251 ; donc ici un peu comme un broadcast mais pour répondre à une requête pour resoudre un nom d'hote)
Le paquet aurait été envoyé, tous les hôtes qui auraient reçu cette réponse auraient pu mettre à jour leur table de nom d'hote.

Et d'ailleurs, c'est peut-être la raison pour laquelle TTL=1. (supposition)

Pour finir, je ne sais pas non plus pourquoi ce paquet a été intercepté... Si tu ne vois aucune règles interdisant l’émission de ce paquet, c'est possible que 'conntrack' (connexion track je pense...) soit impliqué, c'est un truc qui analyse les connexions et ainsi chaque paquet a un état (un STATE):  ETABLISHED, RELATED, NEW, INVALID, ou autres.
Un paquet a l’état 'INVALID' quand il n'appartient à aucune des autres états.

iptables est un parefeu "statefull". En plus des analyses d'ip et de ports, il il donne un état à chaque paquet et en tire naturellement des conséquences...

Re : Comprendre le log de firewalld

Répondre #2 –
Merci @denebe
C'est très complet.

En fait, comme tu le dis, il apparaît qu'il y a des connections entre les machines de mon réseau qui se font "naturellement".
La réponse est probablement dans la définition / rôle du MULTICAST que je ne comprends pas.
Je vais continuer à chercher.

Merci encore pour ton temps à me répondre de façon détaillées.

A+

Re : Comprendre le log de firewalld

Répondre #3 –
Salut,

pour commencer, deux ouvrages sur le multicast (pas seulement):

Si tu n'as aucune idée de ce qu'est une adresse multicast, peut-être ne connais-tu pas le broadcast alors. Si c'est le cas, je t'invite vivement à lire les trois premières parties de ce cours sur les réseaux TCP. C'est un cours très abordable pour débuter, et très intéressant.
Pourquoi ? Parce qu'une adresse Multicast ressemble énormément à une adresse de Broacast. Si tu as compris le pourquoi du comment d'une adresse de Broadcast et comme elle est utilisée, alors tu cerneras beaucoup mieux les adresses de Multicast.
Ce tuto explique aussi ce qu'est le TTL... (Time to Live)

===================================

Citation (Architecture des réseaux fixes) , page 251:
"La technique multicast permet la transmission de données d'une source vers plusieurs destinataires. Comme pour la technique broadcast, elle permet la diffusion des données. A l'inverse du flux broadcast qui est cantonné dans un réseau et qui ne traverse pas les routeurs , le flux multicast est diffusé à travers tous les réseaux interconnectes par les routeurs. La technique multicast presente l'avantage par rapport à la technique unicast de ne diffuser qu'un seul exemplaire du flux, plutôt que d'imposer un flux par destinataires, ce qui optimise grandement la consommation des ressources"
[...]

Architecture des réseaux fixes , page 252:
Le protocole IGMP (Internet Group Management Protocol) est utilisé par l’hôte de réseau qui désire recevoir le flux multicast d'un groupe. La requete IGMP est un message multicast diffusé uniquement à l’intérieur du réseau LAN de l’hôte.

18.1 de Services et Réseaux v5.0, page 171:
Une adresse IP Multicast de classe D est toujours une adresse de destination [...]
Les adresses comprises entre 224.0.0.1 /24 et 224.0.0.255 /24, d'usage local, sont reserves pour des protocoles de routage ou de bas niveau (quelques soit leur TTL, ces multicast ne sont pas propages par les routeurs).

Quelques exemples de d'adresses IP multicast locales (224.0.0.x) réservées (well-know):
224.0.0.1 -> tous les nœuds multicast du réseau local
224.0.0.2 -> tous les routeurs multicast du réseau local
...
224.0.0.12 -> tous les serveurs et relais DHCP
...
224.0.0.251 -> mDNS (source: https://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml , Internet Assigned Numbers Authority (IANA))
Le Multicast DNS est décrit dans la RFC6762.

Les groupes associés à des adresses well-known sont ainsi permanents, même dans le cas ou ils ne contiennent aucun membre.

Les autres groupes sont temporaires et assignés manuellement à une adresse IP multicast en fonction des besoins et des applications; ils sont alors créés à la demande et supprimés lorsqu'ils ne servent plus (lorsqu'ils ne comportent plus de membres).

18.2.1 de Services et Réseaux v5.0, page 176:
Les messages IGMP sont normalement toujours encapsulés et transmis dans des paquets IP avec un TTL fixé à 1, les routeurs supprimant le paquet (le TTL passant ca 0), sans envoyer de message ICMP  en retour.

Exemple concret d'une utilisation du multicast, VLC: Comment utiliser VLC pour faire du streaming audio et vidéo vers plusieurs ordinateurs en vous servant du multicast

A la page 13 de Quelques mots sur la technologie multicast de Nicolas Meneceur, on apprend que le protocole IGMP sert à la gestion des groupes: rejoindre un groupe, quitter un groupe, maintenir un groupe...

=================================

Mon interprétation d'hier est  erronée je pense (je cherche avec mes petits moyens), mais ça ne change pas grand chose au principe, dans le sens que 224.0.0.251 est une adresse multicast.

Pourquoi ? Deux raisons à cela:
  • Comme tu l'as écrit dans ton premier post, l'IP source correspond à ton téléphone
  • le 18.1 du livre Service et reseau v5.0 indique qu'une IP multicast de classe D (c'est le cas) est toujours une adresse de destination

Interprétation du jour :) :
  • Ton téléphone (192.168.0.31) émet une requête IGMP (qui a à voir avec mDNS), qui est un message multicast. Il utilise l'adresse multicast de destination 224.0.0.251. Ce paquet utilise le protocole IGMP et a cette adresse multicast, c'est écrit dans le log
  • Ton switch, ta box, ton routeur reçoit ce paquet dont l'adresse de destination multicast est 224.0.0.251, il sait ce qu'il doit en faire. Selon les cas, la diffuser à un groupe d'ordinateurs. Présentement il t'envoie ce paquet.
  • ton parefeu intercepte ce paquet et le rejette

Re : Comprendre le log de firewalld

Répondre #4 –
https://www.bortzmeyer.org/6762.html

Multicast DNS permet de résoudre un nom de domaine en données (par exemple en adresses IP) sur le réseau local, sans faire appel à un serveur DNS configuré. Le demandeur claironne la question et la machine qui se reconnaît répond. Les noms résolus par Multicast DNS utilisent presque toujours le pseudo-TLD .local, décidé par Apple.

Le problème que tente de résoudre Multicast DNS est celui du réseau local rempli de petites machines (smartphones, tablettes, grille-pains, etc) et pas d'administrateur réseaux compétent pour configurer le tout.

Re : Comprendre le log de firewalld

Répondre #5 –
Merci @denebe

De la lecture en perspective !  :D  8)

Donc, Multicast est défini par défaut sur mon réseau local par la box Free je suppose ?
Mon PC serveur reçoit la requête mais la bloque parce que j'ai limité le pare-feu au strict nécessaire, vu que cette machine est accessible de l'extérieur par HTPP/S par port forwarding.

C'est un bon résumé (très vulgarisé certes...) ?

Merci encore

A+

Re : Comprendre le log de firewalld

Répondre #6 –
Je précise que je ne suis pas informaticien, j'essaie de démêler tout ça et d'y comprendre un peu quelque chose. J'ai du dire quelques boulettes, mais tout en essayant d'avoir une logique (quand même)

Citation de: squid-f – le
De la lecture en perspective !  :D  8)
Je te conseille surtout le début du cours d'openclassroom, limpide, clair, facile, et en plus important, même si ce n'est pas ce qui nous intéresse ici...
Citation de: squid-f – le
Donc, Multicast est défini par défaut sur mon réseau local par la box Free je suppose ?
oui, je dirais pareil. Tout ça est implémenté dans la box, de telle manière qu'elle sache 'router' correctement ce genre de paquet. Et ici, non seulement le router, mais "multiplier" ce paquet et les envoyer vers chacun des hôtes connectés.
Citation de: squid-f – le
Mon PC serveur reçoit la requête mais la bloque parce que j'ai limité le pare-feu au strict nécessaire, vu que cette machine est accessible de l'extérieur par HTPP/S par port forwarding.

C'est un bon résumé (très vulgarisé certes...) ?
Exactement

Selon moi, c’était tout simplement ton téléphone qui essayait d'interagir avec ton réseau local. Je dis avec ton réseau local, car ce même paquet a du atterrir sur tous les hôtes de ton réseau...
Laisse ton parefeu comme il est, surtout qu'avec les téléphones, on ne sait jamais vraiment ce qui se trame...