Risques et mesures de protection

Comprenez les accès accordés, les limites du chiffrement et les vérifications à effectuer avant de partager une connexion ou de modifier le réseau.

Exposition réseau et authentification

Risques liés à l’écoute sur 0.0.0.0

0.0.0.0 écoute sur toutes les interfaces IPv4, pas seulement le Wi-Fi actuel. Ce réglage ne publie pas à lui seul le port sur Internet : les redirections du routeur, le pare-feu et le routage déterminent son accessibilité. Sans authentification, un service accessible peut devenir un proxy ouvert : des tiers peuvent consommer votre bande passante, accéder aux ressources joignables par le Mac ou les routes proxy, et faire associer des abus à votre IP publique. Préférez une adresse privée précise. Si 0.0.0.0 est nécessaire, activez l’authentification et limitez les adresses sources avec un pare-feu. N’exposez pas directement le port HTTP/SOCKS en clair à un réseau non fiable. L’authentification seule ne chiffre pas la connexion.

Risques sans authentification

Sans authentification, tout client admis par les contrôles d’accès réseau du port d’écoute peut utiliser le proxy sans identifiants. Une adresse privée ou le même Wi-Fi ne garantit pas la confiance ; les requêtes ne peuvent pas être attribuées de façon fiable à chaque utilisateur. Des tiers peuvent consommer votre bande passante ou accéder aux ressources joignables, et des abus peuvent être associés à votre IP publique. Activez l’authentification sauf si un réseau isolé limite strictement l’accès aux appareils de confiance.

Redirections et ports d’écoute SOCKS

Une redirection locale expose le service cible via votre Mac. Une redirection distante expose, via le serveur SSH, un service accessible depuis le Mac. Une écoute distante en bouclage appartient au serveur, pas au Mac ; d’autres utilisateurs autorisés du serveur peuvent y accéder. Une exposition plus large dépend aussi de sa politique SSH et de son pare-feu. Conservez l’authentification propre aux bases de données, bureaux distants et services Web.

L’écoute SSH SOCKS ordinaire est distincte du partage réseau authentifié. Les identifiants du partage ne la protègent pas automatiquement. Préférez 127.0.0.1 et vérifiez écoute, droits du serveur et pare-feu avant d’élargir l’accès. :: est une adresse générique IPv6, pas une limitation aux réseaux privés. Voir les redirections locales et distantes.

Chiffrement et identité du serveur SSH

SSH chiffre le tunnel entre le Mac et le serveur SSH, mais pas automatiquement les liaisons client–écoute ou serveur–destination. Utilisez au besoin HTTPS de bout en bout ou le chiffrement du protocole cible. Le serveur SSH et la destination doivent rester dignes de confiance. Un tunnel ne sécurise pas un service malveillant et ne garantit pas l’anonymat.

Vérifiez la première empreinte de clé d’hôte par un canal fiable. Expliquez toute modification avant de réinitialiser la confiance ; ne désactivez pas la vérification stricte pour contourner une alerte. Mot de passe, clé privée et OTP vous authentifient ; la clé d’hôte authentifie le serveur. Voir la confiance SSH.

Couverture du routage et du DNS

Vérifiez l’ordre des règles, la règle par défaut et le DNS de la règle correspondante. DIRECT choisit explicitement un accès direct. Configurez le repli sans supposer un passage automatique à DIRECT après un échec PROXY. Résolution et connexion de l’app peuvent suivre des chemins différents. Un DNS via proxy ne transforme pas un DNS amont TCP/53 ordinaire en DoH.

Un proxy HTTP manuel, SSH SOCKS ou le routage transparent n’est ni un VPN universel ni un coupe-circuit garanti. Les apps peuvent ignorer le proxy, utiliser leur DNS, réutiliser des connexions ou émettre du trafic non pris en charge. HTTP CONNECT n’assure pas un transfert UDP général. Vérifiez l’app, le protocole et le chemin IPv4/IPv6. Voir règles, DNS et limites SOCKS.

Risques du mode passerelle

Le mode passerelle est expérimental et ne prend en charge ni l’authentification par identifiant et mot de passe ni l’authentification multi-utilisateur. Celle du mode proxy ne protège pas le trafic de la passerelle ; le filtrage IP ne vérifie pas l’identité. Utilisez uniquement un LAN de confiance isolé et limitez les IP sources. La modification du transfert IP et des règles de filtrage nécessite une autorisation administrateur et peut interrompre le réseau. La liaison vers le Mac n’est pas chiffrée ; IPv6 peut contourner les règles. Avec plusieurs passerelles, des chemins aller/retour différents peuvent provoquer délais d’attente, coupures ou échecs de redirection. La veille, la fermeture de l’app ou un changement d’adresse interrompent le partage. Rétablissez ensuite la passerelle et le DNS d’origine des clients. Il s’agit d’un avertissement, pas d’une procédure de configuration validée.

Administration Enterprise et certificats

Les réglages Enterprise sont réservés à l’édition Enterprise. L’accès Web/API peut exposer la configuration et les commandes autorisées ; la console et les fichiers sont particulièrement sensibles. Initialisez l’administrateur localement, limitez l’accès réseau et les rôles, et n’accordez que les commandes nécessaires. Le verrouillage de l’app ne remplace pas l’authentification API, administrateur ou proxy.

Utilisez un HTTPS vérifié sur les chemins non fiables. Le client doit faire confiance à une CA privée et le certificat doit couvrir le nom de connexion. Importez uniquement des identités fiables et protégez leurs clés privées. Le TLS du proxy HTTPS ne protège que son écoute, sans chiffrer le port HTTP/SOCKS distinct ni ajouter UDP. La réinitialisation du jeton API est indépendante des sessions Web administrateur. Voir Enterprise et TLS.

Identifiants, sauvegardes et partage

Les URL de proxy et commandes shell copiées peuvent contenir des mots de passe exposés par la synchronisation du presse-papiers, l’historique ou les journaux. Masquez identifiants, jetons, adresses et données personnelles avant de partager un diagnostic. Protégez les clés SSH et utilisez des identifiants distincts aux droits minimaux.

Une sauvegarde de configuration peut contenir des identifiants dans sa partie chiffrée par mot de passe. Conservez sauvegarde et mot de passe en sécurité, séparément. Elle n’inclut pas les fichiers de clés privées, identités TLS/clés privées de CA, comptes administrateur/jetons API, activités Enterprise ni données de déverrouillage de l’app ; prévoyez leur récupération séparément. Les partages QR excluent les identifiants mais révèlent la configuration. Toute personne ayant QR et mot de passe peut importer. L’expiration ne révoque pas une copie déjà importée. Voir sauvegarde et partage QR.

Automatisation et connexions sans surveillance

Vérifiez scripts locaux/distants et actions après connexion avant activation : ils utilisent les droits du compte Mac ou SSH concerné. Inspectez destinations, écoutes, règles et scripts des profils importés. Groupes de démarrage et tentatives automatiques peuvent rouvrir plusieurs connexions sans nouveau clic. Le verrouillage de l’app ne coupe pas les tunnels actifs. Vérifiez membres des groupes et réglages de démarrage/reconnexion avant de laisser le Mac sans surveillance. Voir automatisation.

Disponibilité, confidentialité et responsabilité

Veille, changements réseau, limites en amont et trop de connexions peuvent interrompre le service ou épuiser les ressources. Un état SSH vert ne prouve pas la disponibilité de la destination. Les statistiques et historiques sont des indicateurs, pas une preuve de sécurité ni une facturation exhaustive. Ne partagez que les réseaux et services autorisés. Les fournisseurs appliquent leurs propres règles ; les abus peuvent être associés à l’IP de sortie. Voir dépannage.

Avant de rendre un service accessible

• Identifiez tous les utilisateurs et réseaux pouvant atteindre chaque écoute, y compris les réseaux routés et utilisateurs du serveur distant.
• Activez l’authentification et le chiffrement adaptés ; vérifiez les identités SSH/TLS.
• Vérifiez sources autorisées, ordre, règle par défaut et DNS ; testez d’abord un client autorisé.
• Vérifiez démarrage, reprises, groupes et scripts ; préparez les anciens réglages réseau et une récupération distincte des clés/certificats.
• Surveillez ressources et connexions ; arrêtez les partages devenus inutiles.

En cas de soupçon d’utilisation non autorisée

1. Arrêtez le partage, l’écoute ou la connexion concernés ; arrêtez aussi le service de gestion si cet accès est touché.
2. Réduisez l’exposition du pare-feu/routeur et révoquez comptes, identifiants ou jetons concernés. Réinitialiser un jeton ne déconnecte pas le navigateur.
3. Conservez les journaux nécessaires en privé, vérifiez les accès serveur/destination, règles, groupes et actions de démarrage.
4. Rétablissez les anciens réglages passerelle/DNS des clients modifiés, puis réactivez uniquement les accès nécessaires et vérifiez avec un client fiable.