Quel est l'intérêt de l'option sshd «UseDNS»?
Je sais ce que ça fait, mais je ne sais pas pourquoi. Quelle (s) attaque (s) empêche-t-elle?
Est-il pertinent pour toutes sortes de méthodes d'authentification? (basé sur l'hôte, mot de passe, publickey, clavier interactif ...)
L'option UseDNS est pour la plupart inutile. Si les ordinateurs clients sont sur Internet, il y a de fortes chances qu'ils n'aient pas de DNS inversé, que leur DNS inversé ne se résout pas en avant ou que leur DNS ne fournisse aucune information autre que "appartient à ce ISP ”que l’adresse IP vous indique déjà.
Dans les configurations typiques, DNS n'est utilisé que pour la journalisation. Il peut être utilisé pour l'authentification, mais uniquement si IgnoreRhosts no est spécifié dans sshd_config. Ceci est pour la compatibilité avec les anciennes installations qui utilisaient rsh, où vous pouvez dire "l'utilisateur appelé bob sur la machine appelée darkstar peut se connecter en tant que alice sans afficher d'informations d'identification" (en écrivant darkstar bob dans ~alice/.rhosts). Il n'est sécurisé que si vous faites confiance à toutes les machines susceptibles de se connecter au serveur ssh. En d'autres termes, cela est très très rarement utilisable de manière sécurisée.
Étant donné que la recherche DNS ne fournit aucune information utile, sauf dans des circonstances très particulières, elle doit être désactivée. Pour autant que je sache, la seule raison pour laquelle il est activé par défaut est qu'il est techniquement plus sécurisé (si vous êtes préoccupé par l'authentification, pas la disponibilité), même si cela ne s'applique qu'à un petit nombre de circonstances.
Un autre argument pour désactiver cette fonctionnalité est que chaque fonctionnalité superflue est inutile risque de sécurité .
J'ai ajouté un rapport de bogue (ancien mais toujours actuel) dans Ubuntu à ce sujet.
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/424371
J'ai proposé de changer la valeur par défaut en Non et d'ajouter une documentation plus récente à ce sujet:
# UseDNS - Determines whether IP Address to Hostname lookup and comparison is performed
# Default value is No which avoids login delays when the remote client's DNS cannot be resolved
# Value of No implies that the usage of "from=" in authorized_keys will not support DNS Host names but only IP addresses.
# Value of Yes supports Host names in "from=" for authorized_keys. Additionally if the remote client's IP address does not match the resolved DNS Host name (or could not be reverse lookup resolved) then a warning is logged.
Depuis la page de manuel de sshd_config(5):
UseDNS Specifies whether sshd(8) should look up the remote Host name and
check that the resolved Host name for the remote IP address maps
back to the very same IP address. The default is “yes”.
Si vous activez cette option, l'accès à partir d'un emplacement sans DNS approprié (avant et arrière) génère un avertissement dans les journaux.
Cela n'empêche donc aucune attaque, sauf qu'il aurait besoin d'une adresse distante qualifiée du client afin de ne pas enregistrer d'avertissement. Un tel avertissement peut vous aider à retrouver l'attaquant uniquement si cet enregistrement PTR a un sens.
edit: mis à jour selon le commentaire de Andrey Voitenkov .
Il est nécessaire lorsque vous utilisez l'option FROM dans un fichier authorized_keys et que vous souhaitez filtrer par noms et pas seulement par IP.
L'option FROM dans une ligne d'un fichier authorized_keys vous permet de limiter les hôtes pouvant utiliser une clé spécifique.
.
Je voudrais ajouter que sur CentOS 7 (7.1.1503) et donc Red Hat Enterprise Linux 7, j'étais incapable pour me connecter avec le paramètre par défaut de yes pour UseDNS. Après avoir supprimé les commentaires et l'avoir défini sur no, j'ai pu me connecter. Il semble donc que l'on peut en effet se voir refuser le service si DNS ne fonctionne pas correctement! Dans CentOS 6, il apparaît que la valeur par défaut est no et donc je peux ssh sans DNS fonctionnel!
Je voudrais ajouter que mon expérimentation était sur des conteneurs LXC et non sur une machine physique, au cas où cela ferait une différence!