Sécurisation DNS avancée

DANE

https://danetools.com/

TLSA

Usage Field

• Usage 0 (PKIX-TA: Certificate Authority Constraint) : Permet de spécifier une CA public autorisé a générer des certificats pour votre domaine. Si une autre CA génère un certificat pour votre domaine, ce certificat sera considéré invalide (du point de vue de DANE).
• Usage 1 (PKIX-EE: Service Certificate Constraint) : Permet de spécifier quel certificat serveur est valide. La chaine de certification sera tout de même vérifiée (et doit être valide).
• Usage 2 (DANE-TA: Trust Anchor Assertion) : Permet de spécifier sa propre CA (non public ; générée et gérée soit même) comme étant valide pour ce domaine.
• Usage 3 (DANE-EE: Domain Issued Certificate) : Permet de spécifier directement un certificat serveur même en dehors de toute chaine de certification. Aucune chaine de certification n'est nécessaire dans ce mode.

Selector Field

• Selector 0 - Cert: Utilisation d'un certificat complet
• Selector 1 - SPKI: utilisation du sujet de la clé publique (SubjectPublicKeyInfo). Cette option permet de ne pas avoir à régénérer le champ TLSA a chaque renouvellement de certificat (a condition d'utiliser la même CSR à chaque fois (et donc la même clé privé) ; pratique pour letsencrypt par exemple).

Matching-Type Field

• 0 - Full: Pas de hash, les données sont directement comparés
• 1 - SHA-256: SHA-256 hash
• 2 - SHA-512: SHA-512 hash

Hash-slinger

tlsa --create --port 443 --protocol tcp --usage 3 --mtype 2 --certificate /etc/ssl/yourca/yourcert.pem yourserv.domain.tld.

SSHFP

pourquoi ?

En l'état actuel des choses, lorsque vous vous connectez à un nouveau serveur ssh, votre client doit (s'il ne le fait pas, changez en) vous informer que le serveur sur lequel vous tentez de vous connecter d'identifie avec une certaine fingerprint :

The authenticity of host 'wiki.csnu.org (2001:41d0:2:475e::201)' can't be established.
RSA key fingerprint is 20:c2:7e:a9:f5:c2:8b:ca:c7:08:47:06:a0:74:e0:06.
Are you sure you want to continue connecting (yes/no)?

Si vous confirmez la fingerprint, elle sera ajouté au fichier ~/.ssh/known_hosts et ssh ne vous demandera plus de confirmation a moins que la clé ssh change.

Problème : Vous avez probablement vérifié que vous vous connecté au bon nom dns (voir à la bonne ip), mais avez vous vérifié l'identité du serveur via sa fingerprint ssh ? Probablement pas. Pourtant, vous devriez. C'est ici que vient se glisser le champ sshfp : il permet de spécifier, dans la zone dns, un hash correspondant aux différentes fingerprint utiisé par le serveur ssh "officiel" du domaine en question. Si la zone est de surcroît signée avec dnssec, vous ajoutez ainsi une grosse couche de sécurité à votre installation ssh.

Génération avec ssh-keygen

Cette commande est a utiliser sur le serveur pour lequel vous voulez générer les champs de sécurité dns.

La syntaxe est simple : ssh-keygen -r <hostname de votre serveur>

ssh-keygen -r wiki.csnu.org.

Cela devrait vous sortir une série de champ DNS que vous pouvez copier directement dans votre zone dns. N'oubliez pas de mettre a jour le SERIAL de la zone et de recharger la zone dans votre serveur dns ensuite.

Génération avec hash-slinger

Pour debian wheezy, vous pouvez télécharger directement le paquet hash-slinger sur le site packages.debian.org. Installez le avec dpkg -i et réglez les dépendances par la suite avec aptitude -f install.

ssh-keyscan -t rsa,dsa,ecdsa wiki.csnu.org. > sshkeys
sshfp -k sshkeys

Ou vous pouvez aussi tout faire avec sshfp :

sshfp --scan wiki.csnu.org.

Cela devrait vous sortir une série de champ DNS que vous pouvez copier directement dans votre zone dns. N'oubliez pas de mettre a jour le SERIAL de la zone et de recharger la zone dans votre serveur dns ensuite.

Forcez la vérification dns sur le client ssh

Par défaut, openssh ne vérifie pas les enregistrements DNS SSHFP. Pour activer la vérification, editez le fihchier de configuration de votre client ssh (~/.ssh/config par exemple) et ajoutez y la ligne suivante :

VerifyHostKeyDNS ask

De cette manière, il sera necessaire que la clé soit confirmée a la fois par dns et par StrictHostKeyChecking. Si vous souhaitez faire confiance automatiquement aux nouvelles clés ssh obtenue par dns (aka ajouter directement la clé dans votre fichier known_hosts sans que celà vous soit demandé), modifiez la ligne de cette manière : VerifyHostKeyDNS yes. Notez que même dans ce cas, ssh n'ajoutera automatiquement la clé QUE si le serveur dns utilisé pour résoudre l'hostname a utilisé dnssec pour authentifier le résultat !