Référence des ports
Port 512 (TCP) – rexec
Service d'exécution distante Berkeley hérité qui transmet les identifiants en clair sur le réseau.
État par défaut
Obsolète et désactivé sur les systèmes modernes, mais encore présent sur les hôtes Unix anciens et dans les images de laboratoire comme Metasploitable.
Attaques courantes
- Capture d'identifiants en clair par écoute réseau
- Abus de l'authentification basée sur la confiance via les fichiers .rhosts
- Force brute des identifiants contre le démon rexec
- Exécution de commandes à distance sur les hôtes mal configurés
Durcissement
- Désactiver complètement rexec et utiliser SSH (port 22) à la place
- Retirer rexecd de inetd/xinetd et désinstaller le paquet r-services
- Bloquer le port 512 entrant sur le pare-feu de périmètre
- Auditer et supprimer tout fichier de confiance .rhosts et hosts.equiv
Commande nmap
nmap -p512 --script rexec-brute,banner <target>Remplacez <target> par l’hôte ou la plage que vous êtes autorisé à scanner.
Qu'est-ce qui tourne sur le port 512 ?
Le port 512 est le port bien connu de rexec, l'un des r-services Berkeley hérités d'exécution de commandes à distance. Un client soumet un nom d'utilisateur, un mot de passe et une commande, et le démon rexecd l'exécute sur l'hôte distant. Il date d'une époque de réseaux de confiance et est obsolète depuis des décennies, mais il subsiste sur les systèmes Unix anciens et les images de laboratoire délibérément vulnérables comme Metasploitable.
Pourquoi c'est important pour la sécurité
rexec n'a aucun chiffrement : noms d'utilisateur, mots de passe et commandes
transitent en clair, si bien que quiconque se trouve sur le chemin peut capturer
les identifiants. Pire, la famille r-services prend en charge l'authentification
basée sur la confiance via les fichiers .rhosts et hosts.equiv, qui
peuvent accorder un accès sans aucun mot de passe s'ils sont usurpés ou mal
configurés. Combinés, ces éléments font de rexec l'un des points d'entrée hérités
les plus faciles à trouver pour un attaquant.
Comment il est attaqué
L'attaque la plus simple est l'écoute passive pour récolter les identifiants en clair. Avec les fichiers de confiance en jeu, les attaquants usurpent un hôte de confiance pour exécuter des commandes sans s'authentifier. Ils mènent aussi une force brute de la connexion rexec et utilisent tout identifiant valide pour l'exécution de commandes à distance sur l'hôte.
Liste de durcissement
Désactivez complètement rexec et utilisez SSH (port 22) pour l'exécution
distante. Retirez rexecd de inetd/xinetd et désinstallez le paquet r-services.
Bloquez le port 512 entrant sur le pare-feu de périmètre, et auditez et
supprimez tout fichier de confiance .rhosts et hosts.equiv accordant un accès
sans mot de passe. La commande nmap ci-dessus sonde le service et teste
l'authentification sur les systèmes que vous êtes autorisé à tester.
Ports liés
Questions fréquentes
- rexec sur le port 512 est-il sûr à utiliser ?
- Non. rexec est un r-service Berkeley hérité qui transmet noms d'utilisateur, mots de passe et commandes en clair sans aucun chiffrement. Il est trivialement intercepté et devrait être remplacé par SSH.
- Par quoi remplacer rexec ?
- SSH sur le port 22 fournit une exécution de commandes à distance chiffrée et authentifiée. Désactivez rexec, supprimez son démon et utilisez SSH pour toute exécution distante à la place.