Quatre façons de regarder les journaux WireGuard
|
Important
|
Traduction d’un article du site Pro Custodibus Le contenu de cette page est la traduction Française de l’article Four Ways to View WireGuard Logs de Justin Ludwig |
Quatre façons de visualiser les journaux WireGuard
WireGuard ne fait pas de journalisation par défaut. Cependant, voici quatre outils que vous pouvez utiliser pour générer une journalisation complète de WireGuard pour le débogage, l’analytique, la gestion des informations et événements (SIEM) ou les forensiques d’incident :
Dyndbg
Si vous utilisez le module noyau Linux WireGuard (sur les versions du noyau 5.6 ou plus récentes), vous pouvez activer la journalisation dyndbg de WireGuard, qui envoie des messages de journalisation au tampon de message de noyau, kmsg. Vous pouvez ensuite utiliser l’utilitaire standard dmesg pour lire ces messages. De plus, de nombreux systèmes Linux ont un démon de journalisation comme rsyslogd ou journald qui capturent et stockent automatiquement ces messages.
Tout d’abord, activez la journalisation dyndbg de WireGuard avec les commandes suivantes :
# modprobe wireguard
# echo module wireguard +p > /sys/kernel/debug/dynamic_debug/control
Notez que lorsque vous exécutez cela via sudo au lieu d’être l’utilisateur root, vous devez utiliser tee pour envoyer la commande dyndbg dans le fichier de contrôle, comme suit :
$ sudo modprobe wireguard
$ echo module wireguard +p | sudo tee /sys/kernel/debug/dynamic_debug/control
Une fois que vous avez fait cela, vous pourrez voir les messages de journalisation WireGuard dans la fonctionnalité de message de noyau, si votre système est configuré avec rsyslogd, journald ou un démon de journalisation similaire. Avec rsyslogd, vérifiez le fichier /var/log/kern.log ou /var/log/messages. Avec journald, exécutez journalctl -ek.
Pour capturer ces messages dans leur propre fichier de journal, vous pouvez les suivre avec la commande dmesg en utilisant l’indicateur -w (suivre) :
# touch /var/log/wireguard-dyndbg.log
# dmesg -wT | grep wireguard >> /var/log/wireguard-dyndbg.log
(La balise -T ajoute des horodatages à ces messages.)
Ceci est le journalisation que vous verrez lorsque le module WireGuard est initialisé et lorsque l’interface WireGuard démarre :
[Sat Mar 6 20:13:23 2021] wireguard: WireGuard 1.0.20201112 chargé. Consultez www.wireguard.com pour plus d'informations.
[Sat Mar 6 20:13:23 2021] wireguard: Copyright (C) 2015-2019 Jason A. Donenfeld <Jason@zx2c4.com>. Tous droits réservés.
[Sat Mar 6 20:35:33 2021] wireguard: wg0: Interface créée
[Sat Mar 6 20:35:33 2021] wireguard: wg0: Pair 1 créée
Et vous verrez des journaux comme celui-ci pour chaque échange de clés WireGuard :
[Sat Mar 6 20:45:15 2021] wireguard: wg0: Réception de l'initiation d'échange de clés de la part de la pair 1 (203.0.113.2:51820)
[Sat Mar 6 20:45:15 2021] wireguard: wg0: Envoi de la réponse d'échange de clés à la pair 1 (203.0.113.2:51820)
[Sat Mar 6 20:45:15 2021] wireguard: wg0: Paire de clés 1 créée pour la pair 1
[Sat Mar 6 20:45:25 2021] wireguard: wg0: Réception du paquet keepalive de la part de la pair 1 (203.0.113.2:51820)
Et vous verrez des journaux comme celui-ci après que une pair n’ait été inactive pendant un certain temps :
[Sat Mar 6 20:57:19 2021] wireguard: wg0: Réinitialisation de toutes les clés pour la pair 1 (203.0.113.2:51820), car nous n'avons pas reçu une nouvelle paire depuis 540 secondes
[Sat Mar 6 20:57:19 2021] wireguard: wg0: Paire de clés 1 détruite pour la pair 1
Les pairs seront numérotés dans l’ordre d’ajout depuis le chargement du module WireGuard. Cela peut rendre difficile l’identification des pairs, en particulier si vous avez plusieurs pairs actifs simultanément.
Voici le texte corrigé :
Vous pouvez utiliser ces journaux pour suivre les adresses IP externes qui se connectent à votre réseau WireGuard. L’adresse IP et le port suivant la pair dans la sortie indiquent l’adresse IP et le port actuels de la pair distante (c’est-à-dire son point de terminaison). Dans la sortie ci-dessus, la pair 1 a un point de terminaison de 203.0.113.2:51820.
Vous pouvez également utiliser cette journalisation pour suivre les tentatives de connexion refusées. Vous verrez un message comme celui-ci lorsque une paire tente de se connecter mais échoue à l’authentification :
[Sat Mar 6 20:41:31 2021] wireguard: wg0: Échange de clés invalide initié par 203.0.113.2:51820
Et un message comme celui-ci lorsque une paire tente d’envoyer un paquet non autorisé à travers le tunnel :
[Sat Mar 6 20:43:04 2021] wireguard: wg0: Paquet avec une source IP non autorisée (10.0.0.3) de la paire 1 (203.0.113.2:51820)
Vous pouvez désactiver cette journalisation en pipeant la même commande dans le fichier de contrôle dyndbg comme ci-dessus, en remplaçant l’indicateur +p par l’indicateur -p :
# echo module wireguard -p > /sys/kernel/debug/dynamic_debug/control
Tcpdump
Tcpdump vous permet de journaliser chaque paquet individuel envoyé et reçu par WireGuard. Vous pouvez l’installer via le package tcpdump sur la plupart des distributions Linux. Pour journaliser les en-têtes des paquets UDP enveloppant le contenu crypté de WireGuard, exécutez-le comme suit (où 51820 est le ListenPort dans votre configuration de WireGuard) :
# touch /var/log/wireguard-tcpdump.log
# tcpdump -ttttni any 'udp port 51820' >> /var/log/wireguard-tcpdump.log
(L’indicateur -tttt ajoute la date au timestamp ; l’indicateur -n saute les recherches de noms d’hôtes ; et l’indicateur -i any inclut toutes les interfaces.)
Cela vous permettra de suivre les adresses IP distantes qui se connectent à votre interface locale de WireGuard. Un échange de clés de WireGuard et une courte requête et réponse HTTP cryptées ressembleront à ceci :
2021-03-06 20:45:15.829578 IP 203.0.113.2.51820 > 198.51.100.1.51820: UDP, length 148
2021-03-06 20:45:15.830338 IP 198.51.100.1.51820 > 203.0.113.2.51820: UDP, length 92
2021-03-06 20:45:15.831375 IP 203.0.113.2.51820 > 198.51.100.1.51820: UDP, length 96
2021-03-06 20:45:15.831457 IP 198.51.100.1.51820 > 203.0.113.2.51820: UDP, length 96
2021-03-06 20:45:15.832152 IP 203.0.113.2.51820 > 198.51.100.1.51820: UDP, length 96
2021-03-06 20:45:15.832173 IP 203.0.113.2.51820 > 198.51.100.1.51820: UDP, length 176
2021-03-06 20:45:15.832245 IP 198.51.100.1.51820 > 203.0.113.2.51820: UDP, length 96
2021-03-06 20:45:15.833497 IP 198.51.100.1.51820 > 203.0.113.2.51820: UDP, length 240
2021-03-06 20:45:15.833610 IP 198.51.100.1.51820 > 203.0.113.2.51820: UDP, length 384
2021-03-06 20:45:15.834184 IP 203.0.113.2.51820 > 198.51.100.1.51820: UDP, length 96
2021-03-06 20:45:15.834412 IP 203.0.113.2.51820 > 198.51.100.1.51820: UDP, length 96
2021-03-06 20:45:15.834463 IP 198.51.100.1.51820 > 203.0.113.2.51820: UDP, length 96
Dans la sortie ci-dessus, 198.51.100.1 est l’adresse IP de l’interface Ethernet sur le hôte local, et 203.0.113.2 est l’adresse IP du point de terminaison distant WireGuard (le point de terminaison distant écoute également sur le port 51820, mais la commande ci-dessus capturera une sortie similaire même si le point de terminaison distant était sur un autre port). L’adresse listée en premier est l’origine du paquet, et la deuxième est sa destination.
Vous pouvez ajuster la quantité d’informations à inclure sur chaque ligne via les indicateurs -v (verbose) et -e (en-tête au niveau du lien). La version ci-dessus est la plus silencieuse. Voici
Voici la version la plus verbale du texte :
# tcpdump -evvvttttni any 'udp port 51820'
2021-03-06 22:39:55.835971 In 06:01:1a:2a:77:f7 ethertype IPv4 (0x0800), length 192: (tos 0x88, ttl 64, id 59094, offset 0, flags [none], proto UDP (17), length 176)
203.0.113.2.51820 > 198.51.100.1.51820: [udp sum ok] UDP, length 148
2021-03-06 22:39:55.836701 Out 06:24:d3:09:8d:9b ethertype IPv4 (0x0800), length 136: (tos 0x88, ttl 64, id 43866, offset 0, flags [none], proto UDP (17), length 120)
198.51.100.1.51820 > 203.0.113.2.51820: [bad udp cksum 0x1896 -> 0x2b0a!] UDP, length 92
2021-03-06 22:39:55.837752 In 06:01:1a:2a:77:f7 ethertype IPv4 (0x0800), length 140: (tos 0x0, ttl 64, id 59095, offset 0, flags [none], proto UDP (17), length 124)
203.0.113.2.51820 > 198.51.100.1.51820: [udp sum ok] UDP, length 96
2021-03-06 22:39:55.837869 Out 06:24:d3:09:8d:9b ethertype IPv4 (0x0800), length 140: (tos 0x0, ttl 64, id 43867, offset 0, flags [none], proto UDP (17), length 124)
198.51.100.1.51820 > 203.0.113.2.51820: [bad udp cksum 0x189a -> 0xdf5f!] UDP, length 96
2021-03-06 22:39:55.838587 In 06:01:1a:2a:77:f7 ethertype IPv4 (0x0800), length 140: (tos 0x0, ttl 64, id 59096, offset 0, flags [none], proto UDP (17), length 124)
203.0.113.2.51820 > 198.51.100.1.51820: [udp sum ok] UDP, length 96
2021-03-06 22:39:55.838618 In 06:01:1a:2a:77:f7 ethertype IPv4 (0x0800), length 220: (tos 0x0, ttl 64, id 59097, offset 0, flags [none], proto UDP (17), length 204)
203.0.113.2.51820 > 198.51.100.1.51820: [udp sum ok] UDP, length 176
2021-03-06 22:39:55.838748 Out 06:24:d3:09:8d:9b ethertype IPv4 (0x0800), length 140: (tos 0x0, ttl 64, id 43868, offset 0, flags [none], proto UDP (17), length 124)
198.51.100.1.51820 > 203.0.113.2.51820: [bad udp cksum 0x189a -> 0x906d!] UDP, length 96
2021-03-06 22:39:55.839637 Out 06:24:d3:09:8d:9b ethertype IPv4 (0x0800), length 284: (tos 0x0, ttl 64, id 43869, offset 0, flags [none], proto UDP (17), length 268)
198.51.100.1.51820 > 203.0.113.2.51820: [bad udp cksum 0x192a -> 0x369a!] UDP, length 240
2021-03-06 22:39:55.839693 Out 06:24:d3:09:8d:9b ethertype IPv4 (0x0800), length 428: (tos 0x0, ttl 64, id 43870, offset 0, flags [none], proto UDP (17), length 412)
198.51.100.1.51820 > 203.0.113.2.51820: [bad udp cksum 0x19ba -> 0xbcd9!] UDP, length 384
2021-03-06 22:39:55.840335 In 06:01:1a:2a:77:f7 ethertype IPv4 (0x0800), length 140: (tos 0x0, ttl 64, id 59098, offset 0, flags [none], proto UDP (17), length 124)
203.0.113.2.51820 > 198.51.100.1.51820: [udp sum ok] UDP, length 96
2021-03-06 22:39:55.840456 Out 06:24:d3:09:8d:9b ethertype IPv4 (0x0800), length 140: (tos 0x0, ttl 64, id 59099, offset 0, flags [none], proto UDP (17), length 124)
198.51.100.1.51820 > 203.0.113.2.51820: [udp sum ok] UDP, length 96
Pour enregistrer la sortie de tcpdump au format raw pcap, utilisez l’option -w :
# tcpdump -i any 'udp port 51820' -G 86400 -w /var/log/wireguard-tcpdump.pcap
(L’option -G 86400 permet de rotationner ce fichier une fois par jour.)
Vous pouvez afficher ces fichiers .pcap avec tcpdump lui-même, en utilisant l’option -r, ou avec d’autres outils d’analyse, tels que Wireshark.
Vous pouvez également utiliser tcpdump pour enregistrer les paquets qui sont envoyés à l’intérieur du tunnel WireGuard. Exécutez-le comme suit pour enregistrer les en-têtes de paquet envoyés via le tunnel (où wg0 est le nom de votre interface WireGuard) :
# touch /var/log/wireguard-tunnel-tcpdump.log
# tcpdump -ttttni wg0 >> /var/log/wireguard-tunnel-tcpdump.log
Cela vous permettra
Voici le texte corrigé :
Pour suivre exactement ce qui est envoyé via votre réseau privé virtuel WireGuard, la requête HTTP courte et la réponse ci-dessus apparaîtront comme suit lors de l’enregistrement des paquets à l’intérieur du tunnel :
2021-03-06 20:45:15.831399 IP 10.0.0.2.34770 > 10.0.0.1.8080: Flags [S], seq 2745122483, win 62167, options [mss 8881,sackOK,TS val 3110592290 ecr 0,nop,wscale 6], length 0
2021-03-06 20:45:15.831425 IP 10.0.0.1.8080 > 10.0.0.2.34770: Flags [S.], seq 586324343, ack 2745122484, win 62083, options [mss 8881,sackOK,TS val 1651797146 ecr 3110592290,nop,wscale 6], length 0
2021-03-06 20:45:15.832176 IP 10.0.0.2.34770 > 10.0.0.1.8080: Flags [.], ack 1, win 972, options [nop,nop,TS val 3110592293 ecr 1651797146], length 0
2021-03-06 20:45:15.832214 IP 10.0.0.2.34770 > 10.0.0.1.8080: Flags [P.], seq 1:78, ack 1, win 972, options [nop,nop,TS val 3110592293 ecr 1651797146], length 77: HTTP: GET / HTTP/1.1
2021-03-06 20:45:15.832227 IP 10.0.0.1.8080 > 10.0.0.2.34770: Flags [.], ack 78, win 969, options [nop,nop,TS val 1651797147 ecr 3110592293], length 0
2021-03-06 20:45:15.833466 IP 10.0.0.1.8080 > 10.0.0.2.34770: Flags [P.], seq 1:155, ack 78, win 969, options [nop,nop,TS val 1651797148 ecr 3110592293], length 154: HTTP: HTTP/1.0 200 OK
2021-03-06 20:45:15.833593 IP 10.0.0.1.8080 > 10.0.0.2.34770: Flags [FP.], seq 155:452, ack 78, win 969, options [nop,nop,TS val 1651797148 ecr 3110592293], length 297: HTTP
2021-03-06 20:45:15.834212 IP 10.0.0.2.34770 > 10.0.0.1.8080: Flags [.], ack 155, win 970, options [nop,nop,TS val 3110592295 ecr 1651797148], length 0
2021-03-06 20:45:15.834428 IP 10.0.0.2.34770 > 10.0.0.1.8080: Flags [F.], seq 78, ack 453, win 966, options [nop,nop,TS val 3110592295 ecr 1651797148], length 0
2021-03-06 20:45:15.834447 IP 10.0.0.1.8080 > 10.0.0.2.34770: Flags [.], ack 79, win 969, options [nop,nop,TS val 1651797149 ecr 3110592295], length 0
Dans la sortie ci-dessus, l’adresse IP de l’interface locale WireGuard est 10.0.0.1, et l’adresse IP du pair distant WireGuard est 10.0.0.2. Un serveur HTTP s’exécute sur le port 8080 de l’hôte local, auquel le hôte distant se connecte via le tunnel WireGuard (en utilisant le port TCP éphémère 34770 à l’intérieur du tunnel). Tcpdump inclut les lignes de requête HTTP et d’état de réponse dans sa sortie (GET / HTTP/1.1 et HTTP/1.0 200 OK à la fin des lignes 4 et 6).
Vous pouvez utiliser le journalisation tcpdump sur le port UDP 51820 (premier exemple) pour suivre les adresses IP externes qui se connectent à votre réseau WireGuard ; et le journalisation tcpdump sur l’interface wg0 (dernier exemple) pour suivre les pairs qui utilisent votre réseau (et ce qu’ils accèdent au sein du réseau).
Iptables
Similaire à tcpdump, la cible LOG de iptables vous permet de journaliser chaque paquet envoyé et reçu par WireGuard. La plupart des systèmes Linux utilisent iptables ou son frère plus récent nftables pour définir leur pare-feu.
Si vous utilisez iptables, vous pouvez exécuter les commandes suivantes pour ajouter des règles iptables qui journaliseront l’information d’en-tête des paquets IPv4 transportant du contenu crypté WireGuard (où 51820 est le ListenPort dans votre configuration WireGuard) :
# iptables -I INPUT -p udp --dport 51820 -j LOG --log-prefix 'wireguard iptables: ' --log-level 7
# iptables -I OUTPUT -p udp --sport 51820 -j LOG --log-prefix 'wireguard iptables: ' --log-level 7
Si vous utilisez le réseau IPv6, remplacez iptables par ip6tables; ou si vous utilisez à la fois IPv4 et IPv6, exécutez les deux variantes.
Une fois que vous avez fait cela, vous pourrez voir les paquets WireGuard journalisés dans le tampon du message du noyau. Si votre système est configuré avec rsyslogd, journald ou un démon de journalisation similaire, vous pouvez l’utiliser pour voir cette journalisation. Avec rsyslogd, vérifiez le fichier /var/log/kern.log ou /var/log/messages.
J’ai corrigé les fautes d’orthographe et la grammaire du texte, tout en conservant sa structure Markdown originale.
Voici le texte corrigé :
Pour capturer ces journaux dans un fichier spécifique, vous pouvez utiliser la commande dmesg avec le drapeau -w (suivre) :
# touch /var/log/wireguard-iptables.log
# dmesg -wT | grep 'wireguard iptables:' >> /var/log/wireguard-iptables.log
Cela vous permettra de suivre les adresses IP distantes qui se connectent à votre interface locale WireGuard. Un échange de clés WireGuard et une courte requête et réponse HTTP cryptées ressembleront à ceci :
[Sat Mar 6 20:45:15 2021] wireguard iptables: IN=eth0 OUT= MAC=06:24:d3:09:8d:9b:06:01:1a:2a:77:f7:08:00 SRC=203.0.113.2 DST=198.51.100.1 LEN=176 TOS=0x08 PREC=0x80 TTL=64 ID=39062 PROTO=UDP SPT=51820 DPT=51820 LEN=156
[Sat Mar 6 20:45:15 2021] wireguard iptables: IN= OUT=eth0 SRC=198.51.100.1 DST=203.0.113.2 LEN=120 TOS=0x08 PREC=0x80 TTL=64 ID=48534 PROTO=UDP SPT=51820 DPT=51820 LEN=100
[Sat Mar 6 20:45:15 2021] wireguard iptables: IN=eth0 OUT= MAC=06:24:d3:09:8d:9b:06:01:1a:2a:77:f7:08:00 SRC=203.0.113.2 DST=198.51.100.1 LEN=124 TOS=0x00 PREC=0x00 TTL=64 ID=39063 PROTO=UDP SPT=51820 DPT=51820 LEN=104
[Sat Mar 6 20:45:15 2021] wireguard iptables: IN= OUT=eth0 SRC=198.51.100.1 DST=203.0.113.2 LEN=124 TOS=0x00 PREC=0x00 TTL=64 ID=48535 PROTO=UDP SPT=51820 DPT=51820 LEN=104
[Sat Mar 6 20:45:15 2021] wireguard iptables: IN=eth0 OUT= MAC=06:24:d3:09:8d:9b:06:01:1a:2a:77:f7:08:00 SRC=203.0.113.2 DST=198.51.100.1 LEN=124 TOS=0x00 PREC=0x00 TTL=64 ID=39064 PROTO=UDP SPT=51820 DPT=51820 LEN=104
[Sat Mar 6 20:45:15 2021] wireguard iptables: IN=eth0 OUT= MAC=06:24:d3:09:8d:9b:06:01:1a:2a:77:f7:08:00 SRC=203.0.113.2 DST=198.51.100.1 LEN=204 TOS=0x00 PREC=0x00 TTL=64 ID=39065 PROTO=UDP SPT=51820 DPT=51820 LEN=184
[Sat Mar 6 20:45:15 2021] wireguard iptables: IN= OUT=eth0 SRC=198.51.100.1 DST=203.0.113.2 LEN=124 TOS=0x00 PREC=0x00 TTL=64 ID=48536 PROTO=UDP SPT=51820 DPT=51820 LEN=104
[Sat Mar 6 20:45:15 2021] wireguard iptables: IN= OUT=eth0 SRC=198.51.100.1 DST=203.0.113.2 LEN=268 TOS=0x00 PREC=0x00 TTL=64 ID=48537 PROTO=UDP SPT=51820 DPT=51820 LEN=248
[Sat Mar 6 20:45:15 2021] wireguard iptables: IN= OUT=eth0 SRC=198.51.100.1 DST=203.0.113.2 LEN=412 TOS=0x00 PREC=0x00 TTL=64 ID=48538 PROTO=UDP SPT=51820 DPT=51820 LEN=392
[Sat Mar 6 20:45:15 2021] wireguard iptables: IN=eth0 OUT= MAC=06:24:d3:09:8d:9b:06:01:1a:2a:77:f7:08:00 SRC=203.0.113.2 DST=198.51.100.1 LEN=124 TOS=0x00 PREC=0x00 TTL=64 ID=39066 PROTO=UDP SPT=51820 DPT=51820 LEN=104
[Sat Mar 6 20:45:15 2021] wireguard iptables: IN=eth0 OUT= MAC=06:24:d3:09:8d:9b:06:01:1a:2a:77:f7:08:00 SRC=203.0.113.2 DST=198.51.100.1 LEN=124 TOS=0x00 PREC=0x00 TTL=64 ID=39067 PROTO=UDP SPT=51820 DPT=51820 LEN=104
[Sat Mar 6 20:45:15 2021] wireguard iptables: IN= OUT=eth0 SRC=198.51.100.1 DST=203.0.113.2 LEN=124 TOS=0x00 PREC=0x00 TTL=64 ID=48535 PROTO=UDP SPT=51820 DPT=51820 LEN=104
[Sat Mar 6 20:45:15 2021] wireguard iptables: IN=eth0 OUT= MAC=06:24:d3:09:8d:9b:06:01:1a:2a:77:f7:08:00 SRC=203.0.113.2 DST=198.51.100.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=39108 PROTO=UDP SPT=51820 DPT=51820 LEN=40
Dans la sortie ci-dessus, 198.51.100.1 est l’adresse IP de l’interface Ethernet sur le hôte local, et 203.0.113.2 est l’adresse IP du point de terminaison distant WireGuard (le point de terminaison distant écoute également sur le port 51820, mais les règles iptables ci-dessus captureront une sortie similaire même si le point de terminaison distant était sur un autre port).
Vous pouvez également utiliser iptables pour enregistrer les paquets qui sont envoyés à l’intérieur du tunnel WireGuard. Exécutez les commandes suivantes pour enregistrer les en-têtes des paquets envoyés via le tunnel vers et depuis le système lui-même (où wg0 est le nom de votre interface WireGuard) :
# iptables -I INPUT -i wg0 -j LOG --log-prefix 'tunnel wireguard iptables: ' --log-level 7
# iptables -I OUTPUT -o wg0 -j LOG --log-prefix 'tunnel wireguard iptables: ' --log-level 7
Et exécutez les commandes suivantes pour enregistrer les en-têtes des paquets envoyés via le tunnel vers et depuis d’autres hôtes (si le système opère comme un routeur pour d’autres hôtes sur son réseau) :
# iptables -I FORWARD -i wg0 -j LOG --log-prefix 'tunnel wireguard iptables: ' --log-level 7
# iptables -I FORWARD -o wg0 -j LOG --log-prefix 'tunnel wireguard iptables: ' --log-level 7
Cela vous permettra de suivre exactement ce qui est envoyé via votre réseau privé virtuel WireGuard. La courte requête HTTP et la réponse ci-dessus apparaîtront ainsi lors de l’enregistrement des paquets à l’intérieur du tunnel :
[Sat Mar 6 20:45:15 2021] tunnel wireguard iptables: IN=wg0 OUT= MAC= SRC=10.0.0.2 DST=10.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=25937 DF PROTO=TCP SPT=34770 DPT=8080 WINDOW=62167 RES=0x00 SYN URGP=0
[Sat Mar 6 20:45:15 2021] tunnel wireguard iptables: IN= OUT=wg0 SRC=10.0.0.1 DST=10.0.0.2 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=8080 DPT=34770 WINDOW=62083 RES=0x00 ACK SYN URGP=0
[Sat Mar 6 20:45:15 2021] tunnel wireguard iptables: IN=wg0 OUT= MAC= SRC=10.0.0.2 DST=10.0.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=25938 DF PROTO=TCP SPT=34770 DPT=8080 WINDOW=972 RES=0x00 ACK URGP=0
[Sat Mar 6 20:45:15 2021] tunnel wireguard iptables: IN=wg0 OUT= MAC= SRC=10.0.0.2 DST=10.0.0.1 LEN=129 TOS=0x00 PREC=0x00 TTL=64 ID=25939 DF PROTO=TCP SPT=34770 DPT=8080 WINDOW=972 RES=0x00 ACK PSH URGP=0
[Sat Mar 6 20:45:15 2021] tunnel wireguard iptables: IN= OUT=wg0 SRC=10.0.0.1 DST=10.0.0.2 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=2583 DF PROTO=TCP SPT=8080 DPT=34770 WINDOW=969 RES=0x00 ACK URGP=0
[Sat Mar 6 20:45:15 2021] tunnel wireguard iptables: IN= OUT=wg0 SRC=10.0.0.1 DST=10.0.0.2 LEN=206 TOS=0x00 PREC=0x00 TTL=64 ID=2584 DF PROTO=TCP SPT=8080 DPT=34770 WINDOW=969 RES=0x00 ACK PSH URGP=0
[Sat Mar 6 20:45:15 2021] tunnel wireguard iptables: IN= OUT=wg0 SRC=10.0.0.1 DST=10.0.0.2 LEN=349 TOS=0x00 PREC=0x00 TTL=64 ID=2585 DF PROTO=TCP SPT=8080 DPT=34770 WINDOW=969 RES=0x00 ACK PSH FIN URGP=0
[Sat Mar 6 20:45:15 2021] tunnel wireguard iptables: IN=wg0 OUT= MAC= SRC=10.0.0.2 DST=10.0.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=25940 DF PROTO=TCP SPT=34770 DPT=8080 WINDOW=970 RES=0x00 ACK URGP=0
[Sat Mar 6 20:45:15 2021] tunnel wireguard iptables: IN=wg0 OUT= MAC= SRC=10.0.0.2 DST=10.0.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=25941 DF PROTO=TCP SPT=34770 DPT=8080 WINDOW=966 RES=0x00 ACK FIN URGP=0
[Sat Mar 6 20:45:15 2021] tunnel wireguard iptables: IN= OUT=wg0 SRC=10.0.0.1 DST=10.0.0.2 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=2586 DF PROTO=TCP SPT=8080 DPT=34770 WINDOW=969 RES=0x00 ACK URGP=0
Dans la sortie ci-dessus, l’adresse IP de l’interface locale WireGuard est 10.0.0.1, et l’adresse IP du pair distant WireGuard est 10.0.0.2. Un serveur HTTP s’exécute sur le port 8080 de l’hôte local, auquel l’hôte distant se connecte via le tunnel WireGuard (en utilisant le port TCP éphémère 34770 à l’intérieur du tunnel).
Vous pouvez utiliser la journalisation iptables sur le port UDP 51820 pour suivre les adresses IP externes qui se connectent à votre réseau WireGuard ; et la journalisation iptables sur l’interface wg0 pour suivre les pairs qui utilisent votre réseau (et ce qu’ils accèdent au sein du réseau).
Vous pouvez supprimer des règles iptables en exécutant la même commande que celle que vous avez utilisée pour les ajouter, sauf en remplaçant le drapeau -I (ou le drapeau -A pour les règles ajoutées) par le drapeau -D. Par exemple, vous pouvez supprimer les deux dernières règles ajoutées ci-dessus en exécutant les commandes suivantes :
# iptables -D FORWARD -i wg0 -j LOG --log-prefix 'tunnel wireguard iptables: ' --log-level 7
# iptables -D FORWARD -o wg0 -j LOG --log-prefix 'tunnel wireguard iptables: ' --log-level 7
Pour vérifier les règles actives que vous pourriez vouloir supprimer, exécutez iptables-save (iptables-save n
e fait pas en réalité de sauvegarde, il n’enregistre qu’une liste de toutes les règles actives dans un format qui peut être enregistré et restauré.
Pro Custodibus
Si vous exécutez l’agent Pro Custodibus sur un hôte, vous pouvez utiliser Pro Custodibus pour capturer et gérer la journalisation WireGuard pour vous. Vous pouvez afficher la journalisation WireGuard dans l’interface utilisateur Pro Custodibus, ou vous pouvez l’exporter vers vos propres systèmes d’analyse, SIEM ou autres systèmes de journalisation.
L’interface utilisateur Pro Custodibus montrera l’historique des échanges de clés pour un point de terminaison WireGuard spécifique, ainsi qu’un total en cours de bytes envoyés et reçus :
Vous pouvez également utiliser Pro Custodibus pour suivre quand l’adresse IP utilisée par un pair WireGuard change, ainsi que d’autres modifications de configuration WireGuard à chaque hôte surveillé :
Et pour rendre toutes ces informations de journalisation utiles, Pro Custodibus vous offre des visualisations visuelles pratiques montrant les pairs qui se connectent aux autres pairs au fil du temps :
De plus, Pro Custodibus dispose de notifications automatiques pour vous informer de changements soudains dans les adresses IP utilisées par vos pairs WireGuard (ou d’autres comportements suspects) :
3/6/2021
par Justin Ludwig
by Justin Ludwig translated by: Patrice Le Guyader