Conclusion essentielle : gardez le tableau de bord d’administration de CasaOS privé. Si vous avez besoin d’un accès distant personnel, utilisez un VPN ou un réseau maillé privé. Si une autre personne a besoin d’une seule application, publiez uniquement cette application via un accès HTTPS contrôlé au lieu d’exposer toute l’interface de gestion de CasaOS.
Un écran de connexion n’est pas un pare-feu
CasaOS peut installer, arrêter, supprimer et reconfigurer des applications. Le tableau de bord constitue donc une interface de gestion privilégiée. La redirection de ports publics rend cette interface accessible aux scanners Internet autant qu’à vous.
Internet → application sélectionnée ou tunnel privé → pare-feu → CasaOS sur le réseau local
Utilisez un réseau privé pour l’administration
Les tunnels VPN WireGuard créent des connexions chiffrées de pair à pair sans transformer CasaOS en site web public. Cette solution convient à l’accès personnel au tableau de bord, à SSH ou à SMB depuis des appareils de confiance.
N’exposez que les applications web individuelles
Lorsqu’un service doit être public, utilisez un proxy inverse ou un tunnel sortant. Les tunnels sortants Cloudflare connectent des origines privées sans nécessiter d’adresse IP d’origine accessible publiquement ni de port entrant ouvert sur le pare-feu.
Ne redirigez pas SMB vers Internet
Pour le partage de fichiers, Microsoft recommande de bloquer le port SMB 445 accessible depuis Internet. Faites passer SMB par un VPN ou utilisez une application de partage de fichiers HTTPS pour les utilisateurs externes.
Choisissez l’accès selon le cas d’usage
| Besoin | Méthode |
|---|---|
| Administrer vous-même CasaOS | VPN/réseau maillé privé |
| Publier une application web | Proxy inverse/tunnel HTTPS |
| Partager des fichiers publiquement | Application dédiée au partage de fichiers |
| SMB à distance | VPN en premier |
Le modèle d’accès sécurisé au NAS suit le même principe. Pour ZimaOS, l’accès distant avec Zima Client propose un fonctionnement fondé sur l’accès privé.
Le ZimaBoard 2 est un hôte compact, mais ces règles d’exposition s’appliquent à tout matériel.
Vérifiez ce qui est déjà accessible
Avant de modifier quoi que ce soit, identifiez les services en écoute sur l’hôte CasaOS :
sudo ss -tulpn
Comparez ensuite ces ports avec les règles de redirection de ports du routeur, les mappages UPnP, les routes du proxy inverse et la configuration des éventuels tunnels. Un service qui écoute sur 0.0.0.0 est accessible depuis le réseau local, mais il n’est accessible depuis Internet que lorsque les règles de routage et de pare-feu le permettent.
Le TLS ne transforme pas un panneau d’administration en service public
HTTPS protège le trafic en transit. Il ne supprime ni les failles des applications, ni les mots de passe faibles, ni les attaques par bourrage d’identifiants, ni les failles d’autorisation. Un proxy inverse peut terminer le TLS et ajouter une authentification, mais le choix le plus sûr reste de garder l’administration de CasaOS hors de l’Internet public.
Séparez l’identité d’administration de l’accès invité
Si vos amis ont besoin de Jellyfin, d’une page de téléchargement de fichiers ou d’un autre service, donnez-leur des comptes dans cette application. Ne répondez pas au besoin « quelqu’un a besoin d’une seule application » en lui donnant un accès au tableau de bord du serveur. L’interface de gestion et le service destiné aux utilisateurs doivent avoir des modèles d’exposition et d’autorisation différents.
Faites de l’exposition minimale votre règle de conception
- Exposez un nom d’hôte par application publique plutôt qu’un tableau de bord qui donne accès à tout.
- Limitez SSH au VPN ou aux adresses source de confiance.
- Ne redirigez pas les sockets du démon Docker ni les API de gestion.
- Désactivez les mappages UPnP inutilisés du routeur.
- Corrigez les applications exposées à Internet plus rapidement que les outils limités au réseau local.
- Utilisez l’authentification multifacteur lorsque l’application choisie la prend en charge.
Si vous avez besoin d’une récupération d’urgence à distance
Conservez au moins un accès de gestion indépendant. Par exemple, si votre proxy inverse public tombe en panne, un VPN peut tout de même vous donner accès à CasaOS et aux journaux. Ne faites pas du proxy public l’unique moyen d’administrer le serveur qui l’héberge lui-même.
FAQ
La redirection de ports est-elle toujours dangereuse ?
Non, mais rediriger une interface d’administration privilégiée est un mauvais choix par défaut. Réduisez au minimum les services exposés et ajoutez les contrôles adaptés à l’application.
Un proxy inverse rend-il CasaOS sûr pour une exposition publique ?
Il peut ajouter le TLS et le routage, mais CasaOS reste une interface d’administration. Gardez le tableau de bord privé.
