Des appareils inconnus dans votre console RustDesk ? Enquêtez d'abord

La présence d’un appareil inconnu dans la console RustDesk ne suffit pas à en identifier la cause. Le sandboxing antivirus est une explication connue, mais le même symptôme peut aussi résulter d’une configuration compromise, d’un enregistrement non autorisé, d’un jeton exposé ou d’une erreur de déploiement.

La réponse courte

Certains produits antivirus/EDR exécutent des binaires inconnus dans des sandboxes cloud. Si un sandbox reçoit une version du client contenant votre configuration serveur et parvient à atteindre le serveur d’ID, il peut s’enregistrer brièvement. Cependant, une adresse IP appartenant à un fournisseur cloud ou un nom de machine inhabituel ne prouve pas cette explication ; les attaquants utilisent eux aussi des hébergeurs cloud. Conservez et examinez les preuves avant d’écarter l’incident.

En détail

Pourquoi cela se produit

Les clients RustDesk peuvent s’enregistrer auprès du serveur d’ID/rendez-vous configuré dès qu’ils s’exécutent et parviennent à l’atteindre. Cela fait de l’exécution en sandbox une cause plausible, comme l’explique une discussion publique sur GitHub, mais cela signifie aussi que toute personne disposant d’un client configuré ou de données de déploiement valides peut produire un enregistrement similaire.

Avant de qualifier l’incident, examinez les journaux d’enregistrement et de connexion du serveur, l’heure de première apparition de l’appareil ainsi que son adresse IP source, les registres de déploiement et le canal de distribution des clients personnalisés. Le cas échéant, changez les mots de passe exposés, les jetons API/de déploiement, ainsi que la configuration ou les clés du serveur. Vérifiez si les mêmes identifiants ont été réutilisés ailleurs et si l’appareil inconnu a tenté ou établi une session.

Comment l’empêcher

Deux paramètres de la console permettent de résoudre ce problème ; celui qui vous convient dépend du fait que vous intégriez encore activement ou non de nouveaux appareils réels.

Option 1 — désactiver entièrement l’enregistrement de nouveaux appareils. Si votre liste d’appareils est globalement stable et que vous n’ajoutez pas régulièrement de nouvelles machines, c’est la solution la plus simple : rendez-vous dans Paramètres → Autres → Désactiver les nouveaux appareils sur la console web. Plus aucun nouvel appareil ne pourra s’enregistrer, qu’il s’agisse d’un sandbox ou non.

Option 2 — exiger un jeton de déploiement. Si vous déployez encore régulièrement de nouveaux appareils (un MSP qui intègre des clients, une équipe IT qui image de nouvelles machines), un paramètre global consistant à « désactiver les nouveaux appareils » vous mettrait des bâtons dans les roues. Activez plutôt Paramètres → Autres → Exiger un déploiement pour les nouveaux appareils, créez un jeton API (permission Devices, Lecture et écriture), puis faites en sorte que votre processus d’installation exécute la commande de déploiement documentée sur chaque appareil :

rustdesk --deploy --token <api_token>

Le nom exact de l’option peut changer d’une version à l’autre : considérez ceci comme illustratif et vérifiez la syntaxe actuelle dans la documentation de RustDesk Server Pro avant de l’intégrer à un script. Seul un appareil présentant un jeton valide est ajouté à votre inventaire. Un scan antivirus en sandbox — qui n’a aucun moyen de connaître ou de fournir ce jeton — échoue à s’enregistrer, tandis que votre déploiement réel continue de fonctionner normalement. C’est aussi le mécanisme que les MSP utilisent pour intégrer des appareils via un RMM ou une installation scriptée, sans qu’un technicien ait à se connecter manuellement sur chaque machine.

Un contrôle connexe, plus ciblé : si vous préférez laisser l’enregistrement ouvert mais simplement garder les appareils non assignés hors de vue tant que vous ne les avez pas examinés, il existe aussi Paramètres → Autres → Seul l’administrateur peut accéder aux appareils non assignés — cette option n’empêche pas l’enregistrement, mais elle garantit que les utilisateurs standards ne pourront ni voir ni toucher à quoi que ce soit qui apparaît avant que vous ayez eu l’occasion de l’examiner.

Comment évaluer le résultat

L’enregistrement seul ne prouve pas qu’un attaquant a contrôlé un autre terminal, mais il s’agit tout de même d’une activité non autorisée tant qu’elle n’est pas expliquée. Un enregistrement de courte durée qui coïncide avec un scan de sécurité connu et qui n’est suivi d’aucun accès peut appuyer l’hypothèse du sandbox. Des sessions inattendues, un enregistrement répété, l’utilisation d’identifiants valides ou la distribution d’un client configuré en dehors de son canal prévu nécessitent une réponse à incident.

Qui pose cette question

Les nouveaux opérateurs de serveurs — administrateurs IT comme MSP — rencontrent généralement ce cas de figure quelques jours après la mise en place d’un serveur auto-hébergé, avant d’avoir renforcé les contrôles d’enregistrement. Une enquête rapide est essentielle, car un scan bénin et un enregistrement non autorisé peuvent se ressembler dans la console.

Questions connexes

• Générer un client personnalisé à votre marque : consultez la documentation RustDesk.
• Qu’est-ce qui compte comme appareil géré dans RustDesk ?
• Consultez les versions actuelles de RustDesk et les correctifs de sécurité
• RustDesk pour les MSP : un outil unique, auto-hébergé et personnalisable Vous voyez un appareil que vous ne reconnaissez pas ? Conservez les journaux pertinents, restreignez les nouveaux enregistrements, changez tout secret potentiellement exposé, et contactez le support RustDesk en fournissant des détails de diagnostic non sensibles si la cause reste incertaine.