Du modèle au réseau : exposer un serveur d'inférence local sans ouvrir la porte aux intrus

Le problème de l'exposition réseau en inférence locale

L'inférence locale d'IA implique l'exécution d'un modèle entraîné sur une infrastructure propre, qu'il s'agisse d'un serveur dédié ou d'un poste de travail. Le scénario principal de l'inférence distribuée est qu'un serveur de modèle compatible avec l'API OpenAI fonctionne sur un hôte centralisé et que les clients distants envoient des requêtes à son point de terminaison via le réseau. Cette topologie confère au serveur un rôle central dans la gestion de la capacité de calcul, du stockage des modèles et de l'accès réseau pour plusieurs clients.

Le risque principal survient lorsque le serveur doit être accessible depuis d'autres appareils du réseau local ou depuis un réseau privé virtuel (VPN) sans être exposé à Internet. Contrairement aux configurations d'isolement total, où le service n'écoute que sur l'adresse locale, ou aux audits de confidentialité qui vérifient l'intégrité du fichier, ce guide se concentre sur le scénario intermédiaire : l'exposition contrôlée. L'objectif est de combler le fossé entre « le serveur fonctionne en local » et « je peux l'utiliser depuis mon portable sur le même réseau en toute sécurité », en fournissant une configuration défensive par défaut.

La distinction fondamentale entre l'isolement total et l'exposition contrôlée réside dans la gestion explicite des flux de données sortants et entrants. Dans un scénario d'isolement strict, le serveur ne communique qu'avec lui-même, éliminant ainsi la surface d'attaque réseau, mais limitant également l'utilité collaborative du modèle. L'exposition contrôlée, en revanche, introduit une dépendance aux mécanismes de routage réseau pour acheminer les requêtes des clients distants vers le point de terminaison local. Cette transition nécessite une compréhension précise de la manière dont les paquets sont filtrés avant d'atteindre le processus d'inférence, car le simple fait que le service soit actif sur un port ne garantit pas qu'il soit accessible, ni qu'il soit sécurisé si l'accès est permis. La configuration défensive par défaut doit donc intégrer une logique de rejet par défaut pour tout trafic non explicitement autorisé, ce qui transforme le réseau local en une zone de confiance restreinte plutôt qu'en un espace ouvert.

Le rôle central du serveur dans la gestion de la capacité de calcul implique également une responsabilité accrue en matière de disponibilité et de stabilité. Lorsque plusieurs clients distants envoient des requêtes simultanées, le serveur doit non seulement traiter les inférences, mais aussi gérer la file d'attente des requêtes et la mémoire allouée à chaque session. Une exposition réseau mal configurée peut entraîner une saturation rapide des ressources, non pas par une attaque malveillante, mais par un usage légitime intensif. Par conséquent, la configuration de l'exposition doit prendre en compte les limites de performance du matériel hôte, en définissant des seuils de concurrence ou des mécanismes de limitation de débit au niveau du proxy ou du pare-feu, afin de prévenir les pannes de service dues à une surcharge inattendue du réseau local.

Configuration de l'interface d'écoute : l'adresse de liaison

L'adresse de liaison (bind address) détermine sur quelles interfaces réseau le serveur écoute. Par défaut, des outils comme Ollama se lient à 127.0.0.1:11434, ce qui signifie que seuls les processus de l'hôte lui-même peuvent y accéder. Cette valeur par défaut est correcte pour la plupart des cas et doit être maintenue si aucun accès distant n'est requis.

Pour permettre l'accès depuis d'autres appareils, il est nécessaire de modifier cette adresse. Définir OLLAMA_HOST=0.0.0.0 ou utiliser -p 11434:11434 dans Docker publie le service sur toutes les interfaces, y compris l'interface publique si le pare-feu ne le bloque pas. C'est extrêmement dangereux car l'API d'Ollama n'inclut pas d'authentification intégrée. Quiconque peut accéder au port peut exécuter des modèles, en télécharger d'autres ou saturer le CPU/GPU. L'option recommandée pour les réseaux privés est de définir l'adresse de l'interface spécifique (par exemple, l'IP du réseau local ou l'adresse du tunnel VPN) plutôt que 0.0.0.0.

La modification de l'adresse de liaison implique une prise de conscience des implications sur la résolution des noms d'hôtes et la configuration des routes réseau. Lorsque le serveur est lié à une adresse IP spécifique du réseau local, les clients doivent connaître cette adresse exacte pour établir la connexion. Cela contraste avec l'utilisation de 0.0.0.0, où le serveur répond sur toutes les interfaces disponibles, ce qui peut créer des ambiguïtés si l'hôte possède plusieurs cartes réseau ou des interfaces virtuelles. Dans un environnement Docker, l'utilisation de -p 11434:11434 crée un pont entre le conteneur et l'hôte, mais la sécurité dépend alors entièrement des règles du pare-feu de l'hôte, car le conteneur lui-même n'applique pas de filtrage réseau par défaut. Il est donc essentiel de vérifier que l'interface réseau cible est bien celle attendue et que les règles de routage ne redirigent pas le trafic vers une interface non sécurisée.

Le choix entre une adresse IP locale et une adresse de tunnel VPN a des conséquences directes sur la latence et la fiabilité de la connexion. L'accès via le réseau local est généralement plus rapide et plus stable, car il ne dépend pas d'une connexion Internet externe. En revanche, l'accès via un tunnel VPN ajoute une couche de chiffrement et de routage qui peut introduire une latence supplémentaire, mais offre une sécurité accrue en limitant l'accès aux clients authentifiés dans le tunnel. Cette distinction est cruciale pour les applications sensibles à la latence, où chaque milliseconde compte, et où l'ajout d'une couche de sécurité ne doit pas dégrader les performances de manière significative. La configuration doit donc être testée dans les conditions réelles d'utilisation pour s'assurer que les performances restent acceptables.

Contrôles d'accès : authentification et CORS

Un aspect critique de la sécurité des serveurs d'inférence locale est le manque d'authentification native dans de nombreux outils. Ollama, par exemple, n'inclut pas de clé API, de connexion ni de limitation de débit. La seule liste d'autorisation qu'il possède, OLLAMA_ORIGINS, ne contrôle que les origines du navigateur pouvant l'appeler (CORS) ; elle n'empêche pas curl ou un script d'une autre machine de l'utiliser. Cela signifie que l'authentification doit être implémentée au niveau du réseau ou via un proxy inverse.

Pour des outils comme LM Studio, la configuration en mode sans interface graphique (headless) permet d'activer le service sur le réseau. Cependant, la vérification de l'écoute sur le port (1234 par défaut) doit être réalisée avec soin. Si l'authentification est requise, la meilleure pratique est de placer un proxy inverse (nginx, Traefik ou Caddy) devant le service. Le proxy termine le TLS, exige un mot de passe ou un jeton, puis transmet les requêtes au service local sur 127.0.0.1. Ainsi, le service d'inférence maintient la liaison sur l'adresse locale et le proxy est le seul processus qui écoute sur le port public ou du réseau local.

L'absence d'authentification native dans Ollama signifie que toute requête valide au format API est traitée sans vérification de l'identité de l'expéditeur. Cela crée un risque élevé de confusion de service, où un client non autorisé peut envoyer des requêtes qui consomment des ressources de calcul ou modifient l'état du serveur, comme le téléchargement de nouveaux modèles. Le mécanisme CORS, contrôlé par OLLAMA_ORIGINS, est conçu pour les navigateurs web et ne s'applique pas aux requêtes effectuées par des outils en ligne de commande comme curl ou des scripts Python. Par conséquent, la sécurité ne peut pas reposer sur les en-têtes HTTP envoyés par le client, mais doit être implémentée au niveau de la couche réseau, où le proxy inverse peut inspecter les requêtes avant de les transmettre au service local. Cette approche garantit que seules les requêtes provenant de sources autorisées et correctement authentifiées atteignent le serveur d'inférence.

La configuration en mode headless de LM Studio présente des défis similaires, mais avec des différences subtiles dans la gestion des ports et des interfaces. Le port 1234 par défaut doit être vérifié pour s'assurer qu'il n'est pas déjà utilisé par un autre service sur l'hôte, ce qui pourrait entraîner des conflits de port et des échecs de démarrage du service. La vérification avec netstat ou ss permet de confirmer que le service écoute bien sur l'interface attendue et non sur l'adresse locale uniquement. Si un proxy inverse est utilisé, il est important de configurer les en-têtes de transfert correctement pour que le service d'inférence puisse identifier l'adresse IP réelle du client, ce qui est essentiel pour les journaux d'audit et les règles de limitation de débit. Une configuration incorrecte des en-têtes peut masquer l'origine des requêtes, rendant difficile la détection des accès non autorisés.

Protection périmétrique : pare-feu et filtrage des ports

La configuration du pare-feu de l'hôte est la dernière ligne de défense pour limiter l'accès à des ports spécifiques et aux adresses IP autorisées. Sur les systèmes Linux, on peut utiliser ufw ou iptables pour restreindre l'accès au port 11434 (Ollama) ou 1234 (LM Studio) uniquement aux adresses IP du réseau local ou du VPN. Sur Windows, le Pare-feu Windows avec des règles avancées permet de définir des règles d'entrée autorisant le trafic uniquement depuis des plages d'IP spécifiques.

Il est crucial de fermer le port dans le pare-feu si l'exposition réseau n'est pas utilisée. Si vous configurez OLLAMA_HOST=0.0.0.0 et ouvrez le port dans le pare-feu, vous publiez un serveur d'inférence sans authentification sur tout Internet. Des scanners comme Shodan indexent des milliers d'instances d'Ollama ouvertes, et une instance exposée est trouvée et utilisée de manière abusive en quelques heures. Par conséquent, la règle d'or est : n'exposez jamais directement le port d'inférence sans une couche d'authentification et de chiffrement.

La configuration du pare-feu sur Linux avec ufw nécessite une attention particulière à l'ordre des règles, car la première règle correspondante est appliquée. Si une règle autorisant le trafic depuis le réseau local est placée après une règle de rejet global, elle n'aura aucun effet. Il est donc recommandé de définir d'abord les règles d'autorisation spécifiques, puis d'appliquer une règle de rejet par défaut pour tout le reste du trafic. Cette approche garantit que seules les adresses IP autorisées peuvent accéder au port d'inférence, tandis que tout autre trafic est bloqué. Sur Windows, la configuration des règles avancées du pare-feu suit une logique similaire, mais avec une interface graphique qui peut simplifier la gestion des règles. Il est crucial de tester chaque règle après sa création pour s'assurer qu'elle fonctionne comme prévu et qu'elle n'interfère pas avec d'autres services réseau.

L'exposition accidentelle d'un serveur d'inférence sans authentification sur Internet peut avoir des conséquences graves, non seulement en termes de consommation de ressources, mais aussi en termes de confidentialité des données. Les scanners comme Shodan indexent régulièrement les ports ouverts sur Internet, et une instance d'Ollama exposée peut être détectée en quelques heures. Une fois détectée, l'instance peut être utilisée pour exécuter des modèles coûteux en calcul, saturer le GPU ou même télécharger des modèles malveillants. Pour prévenir ce risque, il est essentiel de maintenir le port d'inférence fermé dans le pare-feu lorsque l'exposition réseau n'est pas nécessaire, et de ne l'ouvrir que lorsque la configuration de sécurité complète, y compris l'authentification et le chiffrement, est en place. Cette discipline de configuration est la clé pour éviter les incidents de sécurité liés à l'exposition réseau.

Vérification empirique et scénarios avancés

La vérification empirique est essentielle pour confirmer que seuls les clients autorisés peuvent se connecter et que le service n'est pas accessible depuis Internet. Depuis un appareil du réseau local, on peut utiliser curl pour tester la connexion : curl http://IP_SERVEUR:11434/api/tags. Si la connexion est refusée, le pare-feu ou la configuration de l'adresse de liaison fonctionne correctement. Depuis un appareil hors du réseau local (par exemple, en utilisant une connexion mobile), la connexion doit échouer. Des outils comme netstat ou ss sur l'hôte permettent de vérifier sur quelles interfaces le service écoute.

Pour un accès distant sécurisé, l'utilisation d'un VPN WireGuard auto-hébergé est l'option recommandée. On définit OLLAMA_HOST comme l'adresse du tunnel (par exemple, 10.8.0.1), et seuls les paires du VPN pourront se connecter. Internet ne peut toujours rien voir sur le port d'inférence. Dans les environnements d'entreprise avec plusieurs utilisateurs, l'authentification doit être gérée via un proxy inverse avec intégration au Active Directory ou à un système d'identité centralisé, en veillant à ce que chaque utilisateur ait des permissions spécifiques et que les identifiants soient stockés dans un coffre-fort approuvé.

La vérification empirique avec curl et netstat permet de confirmer que la configuration de l'adresse de liaison et du pare-feu fonctionne comme prévu. En exécutant curl depuis un appareil du réseau local, on peut vérifier que la connexion est établie et que les données sont renvoyées correctement. En exécutant la même commande depuis un appareil hors du réseau local, on doit s'attendre à un échec de connexion, ce qui confirme que le pare-feu bloque le trafic non autorisé. L'utilisation de netstat ou ss sur l'hôte permet de vérifier les interfaces sur lesquelles le service écoute, ce qui est utile pour détecter les configurations inattendues, comme une écoute sur 0.0.0.0 alors qu'une adresse spécifique était prévue. Ces vérifications doivent être effectuées régulièrement, en particulier après toute modification de la configuration réseau ou du pare-feu, pour s'assurer que la sécurité est maintenue.

L'utilisation d'un VPN WireGuard pour l'accès distant offre une solution robuste pour sécuriser les connexions à distance. En définissant OLLAMA_HOST comme l'adresse du tunnel, le serveur n'écoute que sur l'interface du tunnel, ce qui signifie que seuls les clients connectés au VPN peuvent accéder au service. Cette approche élimine la nécessité d'exposer le port d'inférence sur Internet, réduisant ainsi la surface d'attaque. Dans les environnements d'entreprise, l'intégration avec un système d'identité centralisé permet de gérer les permissions de manière fine, en attribuant des rôles spécifiques à chaque utilisateur. Les identifiants doivent être stockés dans un coffre-fort approuvé pour éviter les fuites de données et assurer la conformité aux politiques de sécurité de l'organisation. Cette configuration combine la sécurité du VPN avec la gestion centralisée des identités, offrant une solution complète pour l'accès distant sécurisé.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.