Preventing Lateral Movement With WireGuard

Une stratégie courante que vous voyez à nouveau et à nouveau dans les attaques de sécurité informatique est une adversaire qui compromise un équipement de basse valeur (comme un ordinateur portable d’un employé de niveau inférieur, ou un ancien serveur web en coin d’une datacenter), puis se déplace horizontalement à partir de cette base pour accéder aux données et systèmes les plus précieux de l’entreprise. WireGuard peut aider à prévenir cela, permettant d’implémenter une segmentation réseau au niveau très fin (c’est-à-dire la micro-segmentation) qui assure que l’adversaire ne peut pas facilement exploiter un ouverture sur un point de terminaison dans votre réseau pour accéder au reste du réseau.

Bien sûr, avant d’implémenter la micro-segmentation, vous devriez d’abord essayer de prendre soin des bases, comme :

• Assurer que tous vos systèmes sont pleinement patchés
• Appliquer des mots de passe forts
• Exiger une authentification à deux facteurs ou des identifiants basés sur le matériel
• Appliquer l’accès au moins privilégié
• Séparer les comptes pour la fonctionnalité administrateur
• Mettre en œuvre la surveillance des points de terminaison et la détection d’intrusion

Toutes ces choses aideront également à prévenir le mouvement latéral — en plus de prévenir un adversaire de gagner une base sur vos systèmes dans un premier temps.

Micro-segmentation With WireGuard

La segmentation traditionnelle du réseau implique souvent simplement de regrouper les ordinateurs selon des critères similaires (par exemple, les ordinateurs du département Ventes sur un réseau et ceux du département Ingénierie sur un autre). Cela peut être réalisé en désactivant l’accès entre les réseaux qui ne le nécessitent pas. La segmentation fine au-delà de cela peut être difficile à maintenir, surtout sur les réseaux qui attribuent des adresses IP dynamiquement (par exemple, avec DHCP) ou où des ordinateurs sont ajoutés et supprimés fréquemment.

WireGuard rend la micro-segmentation beaucoup plus pratique en utilisant le routage par clé cryptographique pour lier de manière sécurisée une adresse IP privée à un appareil. Cela permet d’utiliser WireGuard en combinaison avec des paramètres de pare-feu de base sur l’appareil lui-même pour empêcher tout accès non autorisé depuis d’autres appareils sur n’importe quel réseau, même le réseau auquel l’appareil est physiquement connecté.

Par exemple, pour un serveur Linux avec nftables comme pare-feu, vous pouvez utiliser la configuration de pare-feu nftables suivante simple pour empêcher l’accès au serveur à partir d’autres réseaux sauf via WireGuard :

#!/usr/sbin/nft -f
flush ruleset

define pub_iface = "eth0"
define wg_iface = "wg0"
define wg_port = 51820

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;

        # accept all loopback packets
        iif "lo" accept
        # accept all icmp/icmpv6 packets
        meta l4proto { icmp, ipv6-icmp } accept
        # accept all packets that are part of an already-established connection
        ct state vmap { invalid : drop, established : accept, related : accept }
        # drop new connections over rate limit
        ct state new limit rate over 1/second burst 10 packets drop

        # accept all DHCPv6 packets received at a link-local address
        ip6 daddr fe80::/64 udp dport dhcpv6-client accept
        # accept all WireGuard packets received on a public interface
        iifname $pub_iface udp dport $wg_port accept
        # accept all packets from the WireGuard network
        iifname $wg_iface accept

        # reject with polite "port unreachable" icmp response
        reject
    }
}

```chain forward {
    type filter hook forward priority 0; policy drop;
    reject with icmpx type host-unreachable
}

Avec un pare-feu basé sur l’hôte comme celui-ci en place, l’accès au système (sauf pour quelques éléments opérationnels de base comme ICMP ou DHCP) est restreint uniquement aux pairs WireGuard autorisés dans la configuration propre du dispositif.

Accès Point-to-Point

Si un appareil nécessite un accès à un petit ensemble fixe d’autres appareils, vous pouvez envisager de configurer l’appareil et ses pairs avec une configuration WireGuard point-to-point. Par exemple, un serveur back-end qui traite des tâches à partir d’une file d’attente d’événements et stocke les résultats dans une base de données peut simplement avoir trois connexions statiques : une vers la file d’attente d’événements, une vers la base de données et une vers un système de gestion de configuration qui peut mettre à jour le serveur back-end avec les dernières paramètres logiciels et de configuration dont il a besoin pour fonctionner.

Figure 1. Exemple de réseau WireGuard point-to-point avec micro-segmentation

La configuration WireGuard du serveur back-end dans cet exemple pourrait ressembler à ceci :

# /etc/wireguard/wg0.conf

# paramètres locaux pour le serveur back-end
[Interface]
PrivateKey = AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEE=
Address = 10.0.0.1/32
ListenPort = 51820

# paramètres distants pour la file d'attente d'événements
[Peer]
PublicKey = fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
Endpoint = eq.ue12.eng.corp:51820
AllowedIPs = 10.0.0.2/32

# paramètres distants pour la base de données
[Peer]
PublicKey = jUd41n3XYa3yXBzyBvWqlLhYgRef5RiBD7jwo70U+Rw=
Endpoint = db.ue12.eng.corp:51820
AllowedIPs = 10.0.0.3/32

# paramètres distants pour la gestion de la configuration
[Peer]
PublicKey = MMsBeTT9v/7XNWB8a/jSMn9O8olPVNduUwvUPJ6eB14=
AllowedIPs = 10.0.0.4/32

Le serveur est configuré avec sa propre clé privée WireGuard et son propre adresse IP WireGuard, ainsi que la clé publique et l’adresse IP WireGuard de chaque pair autorisée à se connecter à lui. Chaque pair est configurée dans son propre bloc [Peer].

Un côté de chaque connexion WireGuard doit savoir l’adresse IP physique et le port qu’il peut utiliser pour se connecter à l’autre extrémité de la connexion, ce qui est spécifié via le paramètre Endpoint pour cette pair. Dans l’exemple ci-dessus, le serveur back-end sait comment se connecter aux serveurs de file d’attente des événements et de base de données (en utilisant leurs noms DNS internes), donc il a un paramètre Endpoint spécifié pour chacun. Il n’a pas de Endpoint spécifié pour le serveur de gestion de la configuration, car il s’attend que le serveur de gestion de la configuration sache comment se connecter à lui via l’adresse IP physique du réseau propre au serveur back-end.

Le fichier de configuration WireGuard local du serveur de gestion de la configuration peut ressembler à ce qui suit :

# /etc/wireguard/wg0.conf

# paramètres locaux pour la gestion de la configuration
[Interface]
PrivateKey = CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDHA=
Address = 10.0.0.4/32
ListenPort = 51820

# paramètres distants pour le serveur back-end
[Peer]
PublicKey = /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
Endpoint = be34.ue12.eng.corp:51820
AllowedIPs = 10.0.0.1/32

# paramètres distants pour d'autres serveurs ...

Observez comment la configuration de WireGuard pour le serveur principal nécessite la clé publique du serveur de gestion des configurations, et la configuration de WireGuard pour le serveur de gestion des configurations nécessite la clé publique du serveur principal. Comme chaque côté de la connexion WireGuard doit s’authentifier à l’autre (c’est-à-dire une authentification mutuelle), si un pair est compromise, un adversaire ne peut pas simplement le reconfigurer pour se connecter à d’autres pairs — les autres pairs eux-mêmes doivent être pré-configurés pour permettre une connexion.

De même, un adversaire ne peut pas simplement reconfigurer un pair compromise pour utiliser une adresse IP WireGuard de son choix — le paramètre AllowedIPs de l’autre côté de la connexion limite les adresses IP qui seront acceptées pour le pair. Le paramètre AllowedIPs du serveur de gestion des configurations dans la configuration de WireGuard du serveur principal ne permet que les paquets provenant (et envoyant des paquets à) l’adresse IP 10.0.0.4. Et le paramètre AllowedIPs du serveur principal dans la configuration de WireGuard du serveur de gestion des configurations ne permet que les paquets provenant (et envoyant des paquets à) l’adresse IP 10.0.0.1.

Accès Hub-and-Spoke

Pour les appareils nécessitant un accès de nombreux autres appareils, ou qui ne sont pas configurés avec la gestion des configurations ou d’autres outils pour gérer leur configuration WireGuard, vous pourriez plutôt organiser ces appareils avec une configuration hub-and-spoke WireGuard. Par exemple, un serveur de messagerie qui permet l’accès à la plupart des appareils utilisateurs de votre organisation pourrait être mieux configuré comme une spoke connectée via un hub WireGuard au dispositifs nécessitant son accès.

Figure 2. Exemple de réseau hub-and-spoke WireGuard avec micro-segmentation

L’avantage d’une topologie hub-and-spoke est que chaque spoke individuel n’a besoin d’être configuré qu’avec un seul pair — le hub — au lieu de tous les autres pairs auxquels il peut se connecter.

La configuration WireGuard d’une spoke dans cet exemple pourrait ressembler à ce qui suit :

# /etc/wireguard/wg0.conf

# paramètres locaux pour le serveur de messagerie
[Interface]
PrivateKey = AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEE=
Address = 10.0.0.1/32
ListenPort = 51820

# paramètres distants pour le hub
[Peer]
PublicKey = fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
Endpoint = hub.ue1.wk.corp:51820
AllowedIPs = 10.0.0.0/24
PersistentKeepalive = 25

Et la configuration du hub lui-même pourrait ressembler à ce qui suit :

# /etc/wireguard/wg0.conf

# paramètres locaux pour le hub
[Interface]
PrivateKey = ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBFA=
Address = 10.0.0.2/32
ListenPort = 51820

# paramètres distants pour le serveur de messagerie
[Peer]
PublicKey = /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
AllowedIPs = 10.0.0.1/32

# paramètres distants pour le bureau d'Alice
[Peer]
PublicKey = jUd41n3XYa3yXBzyBvWqlLhYgRef5RiBD7jwo70U+Rw=
AllowedIPs = 10.0.0.3/32

# paramètres distants pour le bureau de Bob
[Peer]
PublicKey = MMsBeTT9v/7XNWB8a/jSMn9O8olPVNduUwvUPJ6eB14=
AllowedIPs = 10.0.0.4/32

# paramètres distants pour les autres appareils utilisateur ...

Un autre avantage d'une topologie en étoile est que vous pouvez exercer un contrôle d'accès plus fin-grainé parmi les branches de l'étoile en utilisant le pare-feu de l'étoile. Cela vous permet d'appliquer des règles de contrôle d'accès par service à tous les pairs du réseau WireGuard dans un seul emplacement centralisé.

Par exemple, si vous ajoutez une branche VoIP, une branche de partage de fichiers et une branche pour le téléphone d'Alice à l'étoile WireGuard ci-dessus, en ajoutant les blocs `[Peer]` suivants au fichier de configuration WireGuard de l'étoile :

```bash
# paramètres distants pour le serveur VoIP
[Peer]
PublicKey = kAYKIv6gpBDqueaVNOsY8ddKmIC2dnnXJQ0iKzWxfBI=
AllowedIPs = 10.0.0.5/32

# paramètres distants pour le partage de fichiers
[Peer]
PublicKey = af24MfZ5LzUedF5WlpK2+O8602g2fmiKO8dYdv8dUyI=
AllowedIPs = 10.0.0.6/32

# paramètres distants pour le téléphone d'Alice
[Peer]
PublicKey = QHy/1+olsMKePzg/044wWUunKs/IfWzy4Ub/iJbzJ00=
AllowedIPs = 10.0.0.7/32

Vous pourriez ensuite utiliser le pare-feu de l’étoile pour limiter le travail d’Alice et celui de Bob à pouvoir accéder uniquement au serveur de messagerie et au partage de fichiers ; et limiter le téléphone d’Alice à pouvoir accéder uniquement au serveur de messagerie et au serveur VoIP. Vous appliqueriez ces règles de contrôle d’accès en utilisant les adresses IP WireGuard de chaque appareil (rappel comme décrit ci-dessus, le routage cryptographique de WireGuard vous permet de lier une adresse IP à un appareil de manière sécurisée).

Les paramètres de contrôle d’accès du pare-feu de l’étoile seraient quelque chose comme ceci :

Voir la section Configuration du pare-feu de la Architecture Zero-Trust avec WireGuard pour un exemple de règles nftables qui vous permettent d’appliquer des règles de contrôle d’accès comme celles-ci.

Notez que le désavantage d’une topologie hub-and-spoke est que, car le hub peut se connecter à un grand nombre d’appareils, le hub lui-même sera une cible attrayante pour un adversaire essayant de se déplacer horizontalement dans votre réseau. Ainsi, il est important de vous assurer que vos hubs sont bien sécurisés, avec des correctifs à jour, sans services réseau supplémentaires et avec un accès distant limité.

1/5/2023

by Justin Ludwig

• WireGuard
• Réseautage
• Sécurité
• nftables
• Point à Point
• Hub et Spoke