Le service portmap correspond à un démon assignant les ports de manière dynamique pour les services RPC tels que NIS et NFS. Il a de faibles mécanismes d'authentification et a la capacité d'attribuer une vaste gamme de ports aux services qu'il contrôle. Pour cette raison, il est très difficile de le sécuriser.
![]() | Note |
---|---|
La sécurisation de portmap affecte uniquement les implémentations NFSv2 et NFSv3, vu que NFSv4 n'en a plus besoin. Si vous planifiez d'implémenter un serveur NFSv2 ou NFSv3, portmap est alors requis et la section suivante s'applique. |
Si vous exécutez des services RPC, vous devriez suivre ces règles élémentaires.
Il est important d'utiliser des enveloppeurs TCP afin de limiter le nombre de réseaux et d'hôtes ayant accès au service portmap puisqu'il n'est doté d'aucune forme d'authentification interne.
De plus, utilisez seulement des adresses IP lors de la restriction de l'accès au service. Évitez d'utiliser les noms d'hôtes car ils peuvent être falsifiés par empoisonnement DNS ou autres méthodes.
Pour restreindre encore plus l'accès au service portmap, il est bon d'ajouter des règles IPTables au serveur et de limiter l'accès à des réseaux spécifiques.
Ci-dessous figurent deux exemples de commandes IPTables autorisant les connexions TCP au service portmap (en attente de requêtes sur le port 111) à partir du réseau 192.168.0/24 et de l'hôte local (qui est nécessaire pour le service sgi_fam utilisé par Nautilus). Tous les autres paquets sont ignorés.
iptables -A INPUT -p tcp -s! 192.168.0.0/24 --dport 111 -j DROP iptables -A INPUT -p tcp -s 127.0.0.1 --dport 111 -j ACCEPT |
Afin de limiter le trafic UDP de la même manière, utilisez la commande suivante :
iptables -A INPUT -p udp -s! 192.168.0.0/24 --dport 111 -j DROP |
![]() | Astuce |
---|---|
Reportez-vous au Chapitre 7 pour obtenir de plus amples informations sur l'implémentation de pare-feu à l'aide des commandes IPTables. |
Précédent | Sommaire | Suivant |
Sécurité du serveur | Niveau supérieur | Sécurisation de NIS |