Avancé 20 minHardening

Air-gapper sa machine d'inférence

Pour les contextes les plus sensibles (défense, juridique de haut niveau, recherche confidentielle), "local" n'est pas assez : il faut air-gap — isoler physiquement la machine de tout réseau extérieur. Ce guide montre comment configurer un poste Linux (et macOS/Windows à un moindre degré) pour une inférence LLM sans la moindre fuite possible, et comment quand même mettre à jour les modèles via transferts contrôlés.

Par Mohamed Meguedmi·Màj 2026-02-10·Testé sur Windows, macOS, Linux

#Quand air-gapper

Données classifiées
Défense, renseignement, secret industriel de haut niveau.
Compliance stricte
Données de santé sous certification HDS, données financières sous ACPR, données juridiques couvertes par secret professionnel absolu.
Environnements air-gap existants
Si votre organisation a déjà une pratique air-gap, le LLM doit s'y intégrer.
Paranoia raisonnée
Pour un avocat travaillant sur des dossiers ultra-sensibles, un poste dédié air-gappé est une protection de bon sens.
!
Coût ergonomique
Un poste air-gappé est moins pratique au quotidien : chaque update, chaque modèle, chaque document passe par une clé USB et un protocole. Réservez aux cas où le gain de sécurité le justifie.

#Le principe

"Air-gap" vient du réseau : on met un "trou d'air" entre la machine et tout câble ou ondes connectés à Internet. Les données entrent et sortent uniquement par support physique contrôlé (clé USB scannée, partage NFS vers un réseau interne sans accès extérieur).

#1. Préparer la machine

OS minimal
Ubuntu Server ou Debian sans GUI si c'est un serveur d'inférence. Pas de snap connecté au store, pas de tracker du genre apt-daily-upgrade.
Comptes utilisateurs dédiés
Un compte pour l'usage LLM, sudo restreint. Pas de navigateur web installé.
Wi-Fi désactivé au BIOS
Physiquement absent pour un serveur, désactivé au firmware pour un laptop. Bluetooth aussi.
Pas de dual boot avec un OS connecté
Une partition "habituelle" créerait une faille via le swap ou des fichiers partagés.

#2. Firewall strict

ufw deny par défaut
sudo ufw default deny outgoing
sudo ufw default deny incoming

# Autoriser UNIQUEMENT localhost
sudo ufw allow out to 127.0.0.0/8
sudo ufw allow in from 127.0.0.0/8

# Si vous êtes sur un LAN isolé interne (pas d'Internet) :
sudo ufw allow out to 192.168.50.0/24
sudo ufw allow in from 192.168.50.0/24

sudo ufw enable
sudo ufw status verbose
Règles côté routeur aussi
Si vous êtes dans un LAN interne, doublez la sécurité côté routeur : les machines air-gap doivent être sur un VLAN sans route vers le WAN. La défense en profondeur paye.

#3. Exceptions localhost uniquement

Ollama et ses amis parlent naturellement sur localhost:11434. Le firewall ci-dessus autorise localhost, donc Ollama + Open WebUI cohabitent sans problème.

Vérifier qu'Ollama n'écoute que localhost
sudo ss -tlnp | grep ollama
# Doit afficher 127.0.0.1:11434 et NON 0.0.0.0:11434
# Si 0.0.0.0 : corriger via OLLAMA_HOST=127.0.0.1:11434

#4. Transférer modèles et mises à jour

Une machine air-gappée a besoin de recevoir : les modèles (quelques Go), les mises à jour logicielles (Ollama, llama.cpp), parfois des documents à traiter.

  1. 01
    Sur une machine connectée (scanner)
    Téléchargez le modèle (ollama pull mistral sur cette machine). Exportez-le : ollama list puis cp ~/.ollama/models/... sur une clé USB.
  2. 02
    Scan antimalware
    Passez la clé au ClamAV ou équivalent. Pour les contextes très sensibles, utilisez une "data diode" qui ne laisse passer les données que dans un sens.
  3. 03
    Sur la machine air-gap
    Copiez depuis la clé vers ~/.ollama/models/. Ollama détecte le modèle automatiquement au prochain lancement.
Exporter un modèle Ollama
# Sur la machine connectée
ollama pull mistral:7b-instruct-q4_K_M
# Copier le dossier complet ~/.ollama/models/manifests/registry.ollama.ai/library/mistral
# ET le blob correspondant dans ~/.ollama/models/blobs/

#5. Tester l'étanchéité

Test mode avion
Débranchez câble et Wi-Fi. Lancez votre workflow LLM complet. Tout doit marcher.
Test tcpdump
sudo tcpdump -i any -n not port 22 et tapez sur Ollama. Vous ne devez voir QUE du trafic loopback.
Test DNS
cat /etc/resolv.conf : aucun DNS externe. host google.com doit échouer (pas de résolution hors LAN interne).
Test pings
ping 8.8.8.8 doit échouer (no route to host).
tcpdump filtré
# Ne rien afficher si étanche, loopback seulement sinon
sudo tcpdump -i any -n 'not (host 127.0.0.1 or host ::1) and not (net 192.168.50.0/24)'

#Audit régulier

Mensuel : reconfirmer le firewall
sudo ufw status. Aucune règle ajoutée par inadvertance ("juste pour essayer un truc") ne doit persister.
Mensuel : scanner les binaires
Surtout après mise à jour d'Ollama/llama.cpp. sha256sum des binaires, comparaison avec le site officiel lors du transfert.
Trimestriel : réinstaller propre
Pour les contextes très stricts, réimager la machine périodiquement. Élimine les backdoors potentiels accumulés.
Annuel : revue complète
Nouvelle menace ? Nouveau matériel ? Rapport d'audit formel, archivage.
Ce guide vous a aidé ?

Un retour, une erreur, une précision ? Faites-nous signe, ça améliore le guide pour tout le monde.