Présentation :
J'utilise souvent le système de fichiers NFS entre les serveurs du même réseau interne. Mais parce que l'ouverture de rpcbind à Internet est considérée comme non sécurisée, j'avais besoin de le protéger. J'aurais pu le faire avec le pare-feu, mais comme le seul service que je voulais protéger de l'accès à Internet, je ne voulais pas m'embêter avec le pare-feu pour cette tâche et j'ai décidé d'utiliser à la place le bon vieux système TCP Wrappers : hosts.allow et hosts.deny fichiers.
Méthode :
– Refuser l'accès à rpcbind à tous (fait dans /etc/hosts.deny )
– Autoriser 2 exceptions :les hôtes sur mon réseau local (fait dans /etc/hosts.allow )
Hypothèses :
Le serveur NFS est connecté à Internet et à notre LAN interne (192.168.100.0/24) et a l'IP :12.34.56.78 (juste un exemple) et 192.168.100.1.
Les 2 hôtes que je veux autoriser à se connecter au serveur NFS sont 192.168.100.2 et 192.168.100.3
J'ai un autre serveur (192.168.100.4) dans ce LAN privé qui ne devrait pas être autorisé à se connecter au serveur NFS.
Étapes :
Modifiez (ou créez s'il n'existe pas) le fichier /etc/default/rpcbind et ajoutez la ligne suivante :OPTIONS="-w -l -h 192.168.100.1"
Editez le fichier /etc/hosts.allow et ajoutez la ligne suivante :rpcbind :192.168.100.2 192.168.100.3
Editez le fichier /etc/hosts.deny et ajoutez la ligne suivante :rpcbind :ALL
Vérification de la configuration :
Connectez-vous à n'importe quel autre serveur sur le même réseau LAN local (aucun de ceux ci-dessus autorisés) disons à partir de 192.168.100.4 et lancez la commande suivante :rpcinfo -p 192.168.100.1
Sortie : rpcinfo :impossible de contacter le portmapper :rpcinfo :RPC :erreur d'authentification ; pourquoi =Identifiant client trop faible
Ensuite, connectez-vous à n'importe quel serveur Internet (par exemple au 45.67.78.89) et essayez la commande :rpcinfo -p 12.34.56.78
Sortie : rpcinfo :impossible de contacter le portmapper :RPC :erreur du système distant - Connexion refusée
Connectez-vous maintenant à l'un des 2 serveurs autorisés (par exemple, 192.168.100.3) et lancez la commande :rpcinfo -p 192.168.100.1
Sortie : rpcinfo -p 192.168.100.1
programme vers service de port proto
100000 4 tcp 111 portmapper
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100000 4 udp 111 portmapper
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 49123 status
100024 1 tcp 55198 status
100003 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
....... et ainsi de suiteBonne nouvelle :
Nous pouvons voir que 192.168.100.4 et tout serveur Internet ne sont pas autorisés à se connecter à rpcbind mais 192.168.100.3 est autorisé.
Informations supplémentaires :
Juste pour le fun, vérifions les logs :grep rpcbind /var/log/auth.log
Sortie : 7 oct. 20:51:30 nfsserver rpcbind :connexion depuis 192.168.100.4 vers dump() :demande d'un hôte non autorisé
7 oct. 20:51:56 nfsserver rpcbind :connexion depuis 45.67.78.89 to dump() :demande d'un hôte non autorisé
Vérifions maintenant la configuration des wrappers TCP pour l'hôte 192.168.100.2tcpdmatch rpcbind 192.168.100.2
Sortie : client :adresse 192.168.100.2
serveur :processus rpcbind
accès :accordé
Résultat :
rpcbind le service est désormais protégé et accessible uniquement depuis les 2 serveurs connectés à notre LAN interne.