Prévention des mouvements latéraux avec Wireguard

Une tactique courante que vous voyez encore et encore dans les attaques de cybersécurité est un adversaire compromettant un appareil de faible valeur (comme l’ordinateur portable d’un employé de bas niveau ou un ancien serveur Web fonctionnant dans le coin d’un centre de données), puis se déplaçant latéralement de ce pied à accéder aux données et aux systèmes les plus précieux de l’entreprise. WireGuard peut aider à éviter cela, vous permettant de mettre en œuvre une segmentation du réseau à un niveau très fin (ou micro-segmentation) qui garantit qu’un adversaire ne peut pas facilement tirer parti d’une ouverture sur un point de terminaison de votre réseau pour accéder au reste du réseau.

Bien sûr, avant de mettre en œuvre la micro-segmentation, vous devriez d’abord essayer de vous occuper des bases, comme :

• Assurez-vous que tous vos systèmes sont entièrement patchés
• Appliquer des mots de passe forts
• Exiger une authentification multifacteur ou des informations d’identification basées sur le matériel
• Appliquer l’accès le moins privilégié
• Comptes séparés pour la fonctionnalité d’administration
• Mettre en œuvre la surveillance des terminaux et la détection des intrusions

Toutes ces choses aideront également à empêcher les mouvements latéraux — en plus d’empêcher un adversaire de prendre pied sur vos systèmes en premier lieu.

Micro-segmentation avec Wireguard

La segmentation traditionnelle du réseau implique souvent simplement de regrouper “comme avec comme” — mettre les PC du service des ventes sur un réseau et les PC du département d’ingénierie sur un autre réseau, ou vos serveurs Web sur un réseau et vos systèmes d’analyse de données sur un autre — et ensuite tout simplement de ne pas permettre l’accès entre les réseaux qui n’en ont pas besoin. Une segmentation plus fine au-delà de cela peut être difficile à maintenir, en particulier sur les réseaux qui attribuent des adresses IP de manière dynamique (par exemple avec DHCP) ou auxquels des ordinateurs sont ajoutés et supprimés fréquemment.

WireGuard rend la micro-segmentation beaucoup plus pratique, en utilisant le routage par clé de chiffrement pour lier en toute sécurité une adresse IP privée à un appareil. Cela vous permet d’utiliser WireGuard en combinaison avec les paramètres de base du pare-feu sur l’appareil lui-même pour empêcher tout accès non autorisé de tout autre appareil 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 pour son pare-feu, vous pouvez utiliser la configuration de pare-feu nftables simple suivante pour empêcher l’accès au serveur, 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-dessus en place, l’accès réseau au système (à l’exception de quelques éléments opérationnels de base comme ICMP ou DHCP) est limité uniquement aux pairs WireGuard, autorisés dans la propre configuration WireGuard de l’appareil.

Accès point à point

Si un appareil n’a besoin d’accéder qu’à un petit ensemble fixe d’autres appareils, vous souhaiterez peut-être le configurer, ainsi que ses pairs, avec une configuration WireGuard point à point. Par exemple, un serveur principal qui traite des travaux à partir d’une file d’attente d’événements et stocke les résultats dans une base de données peut n’avoir besoin que de trois connexions statiques : une à la file d’attente d’événements, une à la base de données et une à un système de gestion de la configuration qui peut mettez à jour le serveur principal avec les derniers logiciels et paramètres de configuration dont il a besoin pour fonctionner.

# /etc/wireguard/wg0.conf

# local settings for back-end server
[Interface]
PrivateKey = AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEE=
Address = 10.0.0.1/32
ListenPort = 51820

# remote settings for event queue
[Peer]
PublicKey = fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
Endpoint = eq.ue12.eng.corp:51820
AllowedIPs = 10.0.0.2/32

# remote settings for database
[Peer]
PublicKey = jUd41n3XYa3yXBzyBvWqlLhYgRef5RiBD7jwo70U+Rw=
Endpoint = db.ue12.eng.corp:51820
AllowedIPs = 10.0.0.3/32

# remote settings for configuration management
[Peer]
PublicKey = MMsBeTT9v/7XNWB8a/jSMn9O8olPVNduUwvUPJ6eB14=
AllowedIPs = 10.0.0.4/32

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

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

Le fichier de configuration de configuration WireGuard du serveur de gestion de la configuration peut ressembler à ceci :

# /etc/wireguard/wg0.conf

# local settings for configuration management
[Interface]
PrivateKey = CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDHA=
Address = 10.0.0.4/32
ListenPort = 51820

# remote settings for back-end server
[Peer]
PublicKey = /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
Endpoint = be34.ue12.eng.corp:51820
AllowedIPs = 10.0.0.1/32

# remote settings for other servers ...

Remarquez comment la configuration WireGuard pour le serveur principal nécessite la clé publique du serveur de gestion de la configuration, et la configuration WireGuard pour le serveur de gestion de la configuration nécessite la clé publique du serveur principal. Étant donné que chaque côté de la connexion WireGuard doit s’authentifier auprès de l’autre (c’est-à-dire l’authentification mutuelle), si un pair est compromis, 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 un connexion.

De même, un adversaire ne peut pas simplement reconfigurer un pair compromis 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 pour le serveur de gestion de la configuration dans le fichier de configuration WireGuard du serveur principal ci-dessus accepte uniquement les paquets provenant de (et envoie des paquets vers) l’adresse IP 10.0.0.4. Et le paramètre AllowedIPs pour le serveur principal dans la configuration WireGuard du serveur de gestion de la configuration accepte uniquement les paquets provenant de (et envoie des paquets vers) l’adresse IP 10.0.0.1.

Accès HUB-AND-SPOKE

Pour les appareils qui nécessitent un accès à partir de nombreux autres appareils, ou qui ne sont pas configurés avec la gestion de la configuration ou d’autres outils pour gérer leur configuration WireGuard, vous pouvez plutôt les organiser avec une configuration WireGuard hub-and-spoke. Par exemple, un serveur de messagerie qui autorise l’accès à partir de la plupart des appareils des utilisateurs finaux de votre organisation peut être mieux configuré comme un rayon connecté via un concentrateur WireGuard aux appareils qui ont besoin d’y accéder.

La configuration WireGuard d’un rayon dans cet exemple peut ressembler à ceci :

# /etc/wireguard/wg0.conf

# local settings for mail server
[Interface]
PrivateKey = AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEE=
Address = 10.0.0.1/32
ListenPort = 51820

# remote settings for hub
[Peer]
PublicKey = fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
Endpoint = hub.ue1.wk.corp:51820
AllowedIPs = 10.0.0.0/24
PersistentKeepalive = 25

Et la propre configuration WireGuard du concentrateur pourrait ressembler à ceci :

# /etc/wireguard/wg0.conf

# local settings for hub
[Interface]
PrivateKey = ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBFA=
Address = 10.0.0.2/32
ListenPort = 51820

# remote settings for mail server
[Peer]
PublicKey = /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
AllowedIPs = 10.0.0.1/32

# remote settings for Alice's workstation
[Peer]
PublicKey = jUd41n3XYa3yXBzyBvWqlLhYgRef5RiBD7jwo70U+Rw=
AllowedIPs = 10.0.0.3/32

# remote settings for Bob's workstation
[Peer]
PublicKey = MMsBeTT9v/7XNWB8a/jSMn9O8olPVNduUwvUPJ6eB14=
AllowedIPs = 10.0.0.4/32

# remote settings for other user devices ...

Un autre avantage d’une topologie hub-and-spoke est que vous pouvez exercer un contrôle d’accès plus précis entre les rayons du hub en utilisant le propre pare-feu du hub. 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 emplacement centralisé.

Par exemple, si vous avez ajouté au hub WireGuard ci-dessus un rayon VoIP, un rayon de partage de fichiers et un rayon pour le téléphone d’Alice, en ajoutant les blocs [Peer] suivants au fichier de configuration WireGuard du hub :

# remote settings for VoIP server
[Peer]
PublicKey = kAYKIv6gpBDqueaVNOsY8ddKmIC2dnnXJQ0iKzWxfBI=
AllowedIPs = 10.0.0.5/32

# remote settings for fileshare
[Peer]
PublicKey = af24MfZ5LzUedF5WlpK2+O8602g2fmiKO8dYdv8dUyI=
AllowedIPs = 10.0.0.6/32

# remote settings for Alice's phone
[Peer]
PublicKey = QHy/1+olsMKePzg/044wWUunKs/IfWzy4Ub/iJbzJ00=
AllowedIPs = 10.0.0.7/32

Vous pouvez ensuite utiliser le pare-feu du hub pour limiter le poste de travail d’Alice et le poste de travail de Bob à ne pouvoir accéder qu’au serveur de messagerie et au partage de fichiers ; et limiter le téléphone d’Alice à ne pouvoir accéder qu’au serveur de messagerie et au serveur VoIP. Vous appliquerez ces règles de contrôle d’accès en utilisant les adresses IP WireGuard de chaque appareil (rappelez-vous comme décrit ci-dessus, le routage de clé de chiffrement de WireGuard vous permet de lier en toute sécurité une adresse IP à un appareil).

Les paramètres de contrôle d’accès du pare-feu du concentrateur ressembleraient à ceci :

Consultez la section Configuration du pare-feu du guide Architecture Zero-Trust avec WireGuard pour un exemple d’ensemble de règles nftables qui vous permet d’appliquer des règles de contrôle d’accès comme ceci.

Notez que l’inconvénient d’une topologie hub-and-spoke est que, comme 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 latéralement à travers votre réseau. Il est donc important de s’assurer que vos concentrateurs sont bien renforcés, avec des correctifs à jour, aucun service réseau superflu et un accès à distance limité.