đŸ Archived View for lord.re âș posts âș 130-reflexe-dane âș index.gmi captured on 2022-06-03 at 23:08:03. Gemini links have been rewritten to link to archived content
âĄïž Next capture (2024-08-18)
-=-=-=-=-=-=-
-------------------------------------------------
[11/10/2018] - ~5mins - #dns #dnssec #sécu #knot
-------------------------------------------------
J'ai déjà plusieurs fois abordé DNSSEC et une fois survolé DANE mais je vais en remettre une couche.
Bon déjà reprenons vite fait du début.
Il s'agit d'un ajout au protocole DNS ajoutant de la crypto permettant d'assurer l'intégrité des réponses DNS.
Le but est de s'assurer que les données que vous échangez avec votre résolveur sont authentiques, elles restent toute fois lisibles, le but n'est pas de rendre votre trafic DNS illisible par votre FAI !
Si vous utilisez un rĂ©solveur DNS qui valide DNSSEC vous pouvez ĂȘtre assurĂ© qu'une rĂ©ponse est authentique si elle a le petit flag *ad* (quand vous utilisez la commande dig).
Ăa se base sur tout un systĂšme de crypto Ă base de clĂ©s publiques et privĂ©es qui sont changĂ©es rĂ©guliĂšrement (le roll) avec deux principaux types de clĂ©s :
- les *KSK* qui sont les key signing key qui servent à signer d'autre clés
- les *ZSK* qui sont les zone signing key qui servent Ă signer les enregistrements de votre zone
DNSSEC est une chaĂźne, signer votre zone c'est bien mais pas suffisant.
Il faut que la zone parente soit elle aussi signée et surtout il faut un ptit morceau sur la zone parente qui lie votre zone (DS).
Si ce n'est pas le cas la chaĂźne de certification n'est pas complĂšte et donc pas de DNSSEC.
Une fois tout ceci mis en place (c'est pas bien compliquĂ©, franchement faite-le !), les infos prĂ©sentes dans votre zone peuvent ĂȘtre distribuĂ©e de façon sĂ»re.
On peut donc s'amuser à y mettre des données un poil sensibles.
Sensibles mais publiques.
Le DNS ce sont des données publiques.
Mais alors pourquoi sensibles ?
Bha sensible dans le sens oĂč maintenant qu'on peut s'assurer qu'elles n'ont pas Ă©tĂ© alterĂ©, ces donnĂ©es peuvent attester de l'authenticitĂ© d'une information (typiquement attester que tel certificat est LE certificat utilisĂ© par un service).
DANE est exactement l'application de ce principe : le certificat utilisé par tel service est celui-ci.
Le logiciel peut donc vérifier que le certificat présenté par le service est bien identique au certificat publié dans le DNS.
DANE permet donc d'assurer Ă un utilisateur qu'il n'est pas en train de subir une attaque de type Man-In-The-Middle.
DANE repose donc sur DNSSEC mais Ă©galement sur le fait que ça doit ĂȘtre implĂ©mentĂ© par chaque logiciel voulant l'appliquer (logique).
Malheureusement, aucun logiciel grand public ne l'utilise.
Ăa serait pourtant un sacrĂ© pas en avant dans la sĂ©curisation du web.
Le jour oĂč Chrome l'adopte le reste de l'industrie s'y mettra mais avant⊠Ćuf/poule.
Et voilĂ \o/ DNSSEC est en place.
Bon en vrai c'est un tout petit peu plus compliqué.
Avec Knot, dans votre fichier de conf oĂč vous dĂ©clarez vos diffĂ©rentes zones, vous devez attribuer une politique de signature.
Celle par défaut peu convenir mais perso j'ai pas envie de me faire chier à changer la KSK trop souvent donc j'ai défini ma mienne :
policy:
- id: ecdsa
algorithm: ecdsap384sha384
zsk-lifetime: 7d
ksk-lifetime: 700d
ksk-size: 384
zsk-size: 384
puis dans votre zone :
zone:
- domain: lord.re.
file: lord.re
dnssec-signing: on
dnssec-policy: ecdsa
Et voilà Knot va se démerder en créant les clés les faire tourner et tout.
Maintenant vous
ref "/posts/129-DNSSEC-chez-ovh-et-online" >}} transmettez le DS chez votre registrar
.
Pour l'instant Knot ne va pas commencer à rouler les clés tant que le DS n'est pas publié.
Une fois fait il faut lui signaler avec *<kbd>knotc zone-ksk-submitted lord.re</kbd>*.
VoilĂ votre zone devrait ĂȘtre bien signĂ©e et tout, vous n'avez plus rien Ă faire jusqu'au prochain roulement de KSK dans 700 jours (mettez un rappel).
DANE c'est le gentil nom de la technique mais en vrai il s'agit juste d'un enregistrement de type *TLSA* dans votre zone DNS.
Prenons un cas concret : *lord.re* .
On va utiliser le
.
Donc lĂ si comme tout le monde vous avez un certificat signĂ© par LetsEncrypt, le mieux est d'utiliser un *TLSA 312* qui a l'avantage de ne pas devoir ĂȘtre renouvelĂ© tous les 90 jours quand le certificat est renouvelĂ©.
Les enregistrements TLSA 312 s'appuient sur la clé publique qui n'est pas modifiée à moins de manuellement en régénérer une.
Donc, il faut copier/coller votre certificat *cert.pem* dans l'emplacement prévu dans le générateur.
Avec acme-client ça se trouve dans */etc/ssl/acme/lord.re/cert.pem* .
Le numéro de port dépendra du service que vous voulez protéger par cette technique.
Pour le web c'est *443 et le protocole tcp*.
Et enfin entrez le nom de la machine qui héberge le service *lord.re* dans l'exemple.
Ăa vous pond une longue ligne Ă ajouter Ă votre zone.
Sur votre serveur DNS hébergeant la zone DNS vous pouvez : *<kbd>knsupdate <br>server 127.0.0.1<br>zone lord.re<br>update add _443._tcp.lord.re 600 TLSA 3 1 2 enriuetjesuisuntrÚsmauvaisgénérateurd'aléatoireuirnse==</kbd>*
Et voilĂ :-)
Et maintenant on le teste sur
si c'est pour un serveur web ou sur bien sur
si c'est pour du mail.
Bon c'est franchement pas dur.
Ăa se fait en prĂšs de deux minutes.
Maintenant il faut chopper le réflexe : *à chaque fois que vous créez un nouveau certificat ou que vous utilisez un certificat existant sur un nouveau service, pensez à ajouter l'enregistrement TLSA qui va avec.*
Si le réflexe est adopté par de nombreux sysadmin l'implémentation par les logiciels pourrait avoir lieu un de ces jours (admirez l'optimisme).
Bon pour cet article j'ai volontairement plantĂ© mes zones DNS afin d'expĂ©rimenter et tout mais au moins c'est clean et dans ma tĂȘte et pour vous.
------------------------------------
------------------------------------
[11/10/2018] [dns dnssec sécu knot]
------------------------------------
[>> Suivant >>] â Recompresser ses photos et ses vidĂ©os
[<< Précédent <<] ⟠Gestion de l'enregistrement DS chez OVH et Online pour votre DNSSEC