-- Leo's gemini proxy
-- Connecting to lord.re:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini
-------------------------------------------------
[27/10/2017] - ~18mins - #dns #réseau #adminsys #knot #dane #dnssec
-------------------------------------------------
Bon bon ces derniers temps je trifouille pas mal mon DNS. Pour les deux du fond qui viennent de se réveiller le DNS c'est l'annuaire de référence de l'Internet. Mais en fait c'est très réducteur de dire ça. En vrai le DNS c'est un système de base de données qui peut faire tout un tas de truc et pas uniquement convertir des noms en adresse IP. Allez, c'est parti pour le DNS Méga Guide 2017 !
<!--more-->
Bon il y aura quelques redites de précédents articles sur le sujet mais le but ici est d'aborder à peu près tout histoire d'être exhaustif.
Historiquement lorsqu'on voulait contacter une machine sur le réseau Internet, il fallait connaitre son adresse. Le nombre de machine du réseau grandissant, un fichier texte était échangé pour trouver les autres machines du réseau. C'était très manuel mais peu efficace. Et là : PAF le DNS. Bref une base de donnée distribuée/répliquée/déleguée mondiale.
Le DNS est un arbre qui fonctionne par délégation. Typiquement *www.lord.re* devrait en vrai se dire *www.lord.re.* (remarquez le point à la fin). C'est un chemin qui se lit de droite à gauche.
- Donc on a la racine *.* tout à droite, c'est geré par l'*ICANN*.
- Ensuite *.re* qui est le TLD (Top Level Domain, aussi apellé extension d'un nom de domaine), c'est non plus geré par l'ICANN mais délegué à l'*AFNIC* (qui gère les domaines français dont le .re qui est le domaine de la Réunion).
- Puis on trouve *.lord* qui n'est plus geré par l'AFNIC mais par *moi* (car je le loue auprès d'un registrar).
- Et pour finir *www* qui pointe vers le serveur que je gère également, mais j'aurai pu le délégué à quelqu'un.
Bon maintenant on va aller beaucoup plus loin par la pratique. On va donc monter un serveur DNS faisant autorité sur votre nom de domaine.
Bon déjà on achète pas un nom de domaine, mais on le loue pour un à dix ans auprès d'un registrar (revendeur autorisé). La plupart des registrars proposent d'héberger le service DNS chez eux mais franchement… on préfère le faire soit-même !
Auprès de votre registrar vous aurez donc à remplir les *Glue Records. C'est ce qui lie votre serveur DNS à votre domaine auprès du niveau supérieur. En gros c'est ce qui va permettre aux gens de contacter votre serveur DNS. Donc il va falloir indiquer le nom du serveur DNS ayant autorité sur la zone ainsi que son adresse IP. Une fois fait vous n'aurez quasiment plus rien à faire auprès de votre registrar. Dans mon cas le serveur DNS est zapp.lord.re qui a pour IP : 62.210.201.160* .
Bon maintenant installer son serveur DNS… Débrouillez-vous. Dans mon cas j'ai non pas choisis le vénérable Bind mais le brave *Knot que je trouve bien plus sympa. Il vous simplifiera la vie au niveau de la configuration et gère DNSSEC tout seul comme un grand. Knot est fait par les gens de Nic.cz qui gèrent donc les noms de domaine tchèques .cz . Ce sont les mêmes gens qui ont fait le logiciel Bird qui est un logiciel de routage libre. Ils ont aussi fait les Turris dont l'=> https://lord.re/posts/44-turris-omnia/ Omnia qui est mon routeur actuel. Ce sont des fanas du réseau et de l'Opensource. Des gens biens. Ils poussent à fond la démocratisation de DNSSEC car ils ont fait des extensions pour les navigateurs afin de vérifier le
des sites que vous consultez.
Bon déjà on l'installe et ensuite on créer le fichier de conf. Il est ultra simple et logique je vous le mets dans sa quasi-intégralité ici :
server:
user: knot:knot
listen: [ "0.0.0.0@53", "::@53" ]
log:
- target: /var/log/knot.log
any : info
acl:
- id: acl_localupdate
address: 127.0.0.1
action: update
control:
listen: knot.sock
remote:
- id: localupdate
address: 127.0.0.1
template:
- id: default
storage: /var/lib/knot/zones
acl: [ "acl_localupdate" ]
kasp-db: /var/lib/knot/kasp
zone:
- domain: lord.re.
file: lord.re
dnssec-signing: on
dnssec-policy: default
Tout est bien rangé dans sa section, acl contient les règles d'accès (pour modifier), template permet d'appliquer des règlages similaires à plusieurs zones, et zone va contenir toutes vos zones (Thx Cpt Obvious). Bon du coup maintenant vos fichiers de zones vont devoir se fouttre dans /var/lib/knot/zones. Knot va générer de lui même les clefs et chiffrer votre zone DNSSEC.
Monter un serveur DNS secondaire.
Cette partie sera ajoutée un peu plus tard ;-)
La seule chose qu'il vous reste à faire auprès de votre registrar va être de publier votre DS record ou la DNSKEY de la KSK chez votre registrar. Dis comme ça, c'est effrayant mais c'est pas bien compliqué. Cette opération permet de terminer la chaîne de confiance nécessaire à DNSSEC. Selon les registrar il va vous falloir soit le DS soit le DNSKEY complet.
- Pour obtenir le *DS* : *keymgr lord.re list vous listera toutes les clés actives. Il faut repérer la *KSK* et noter son *tag*. Et maintenant keymgr lord.re ds 42754* (42754 étant le tag vu à la commande précédente). Et là vous devriez voir trois enregistrements. Votre registrar vous en demandera un, il s'agit en fait de la même chose mais selon trois méthode de hash différent et là, plus c'est long meilleur c'est pour votre sécurité.
- Pour obtenir le *DNSKEY* un simple *keymgr lord.re dnskey 42754* et voilà.
Vous devrez réiterer cette opération à chaque renouvellement de la KSK (à faire manuellement une fois tous les deux ans voir une fois par an). En gros DNSSEC s'appuie sur deux types de clés : la *ZSK* qui signe votre zone. Celle-ci a une taille relativement faible. Du coup on la change constamment (une fois par mois par défaut). Mais du coup pour pas se faire chier à la transmettre au registrar chaque mois, on utilise une autre clé, la *KSK*. La KSK signe la ZSK. Et on publie uniquement la KSK au registrar. Celle-ci est plus longue et est changée beaucoup moins fréquemment.
À partir de maintenant vous n'entendrez parler de votre registrar que pour renouveller votre nom de domaine avant son expiration :-).
On peut mettre tout un tas de truc, commençons par l'indispensable :
- *SOA* : Le Start of Authority est indispensable puisque c'est lui qui défini qui est le maître de la zone, le mail de contact et les valeurs d'expiration. Dans mon exemple :
lord.re. 3600 IN SOA zapp.lord.re. lord.lord.re. 2015033233 3600 7200 3600 180
Donc le serveur master (ayant autorité) est zapp.lord.re., le mail de contact est lord.lord.re. (remarquez la syntaxe étrange car l'arobase est remplacée par un point (il y a surement moyen d'avoir des adresse mail non parseable)). Vient ensuite le serial 2015033233 qui doit être incrémenté à chaque modification (vous oublierez et aurez des surprises) et les valeurs d'expirations.
- *MX* : Le Mail eXchange indique le(s) serveur(s) de réception des emails. On peut en mettre plusieurs et indiquer des priorités c'est pas mal. Vous pouvez bien entendu faire pointer ça vers d'autres domaines que le votre (héberger vos mails sur mx.truc.machin et pas forcément dans votre zone).
lord.re. 2600 IN MX 10 zapp.lord.re.
Là on voit que le serveur de mail est sur zapp.lord.re et qu'il a la priorité 10.
- *NS* : Le Name Server indique les serveurs DNS ayant autorité sur la zone. Généralement on pointe vers un nom de machine et faut que ce nom de machine ait un enregistrement A valide (l'ouroboros, m'voyez).
lord.re. 3600 IN NS zapp.lord.re.
Le nameserver de ma zone est aussi zapp.lord.re.
- *A* et *AAAA* : Il s'agit de l'enregistrement le plus classique. Vous liez un nom de machine à une adresse IPv4 (A) ou IPv6 (AAAA).
lord.re. 600 IN A 92.167.84.9
Et enfin on voit que lord.re. pointe vers l'ip 92.167.84.9.
Bon généralement on se contente de ça je verrai les enregistrements plus exotiques plus loin.
Il existe trois façon de modifier sa zone DNS.
1. La première est la moins élégante : éditer le fichier de zone et dire à Knot de recharger la zone depuis le fichier. Franchement pas terrible. En plus faut bien penser à incrémenter le serial. Je vous le recommande surtout pas.
2. La seconde est celle que j'utilisais pendant longtemps et que j'ai
qui consiste à utiliser *nsupdate (ou sa version made in knot, knsupdate*). C'est bien, la syntaxe est pas trop affreuse mais franchement je m'en souviens jamais, je me retape mon article à chaque fois ou presque.
3. La dernière est plus récente et passe directement par *knotc* pour faire faire les modifs de la zone.
On ouvre le fichier /var/lib/knot/zones/lord.re. On fait les modifs en faisant gaffe à la syntaxe, on _incrémente le serial_. On teste la syntaxe de la zone avec *knotc zone-check lord.re et enfin on recharge avec knotc zone-reload lord.re*. Voilà voilà.
On lance *knsupdate* ce qui va vous ouvrir un shell interactif.
server 127.0.0.1 (ouai on pourrait l'utiliser à distance avec un peu de crypto)
zone lord.re.
update add|del lechamps 600 A 1.2.3.4 (selon si on veut ajouter ou supprimmer)
send
Et voilà. C'est assez simple. On peut foutre les commandes dans un fichier texte à donner à manger à nsupdate également. Ça permet de scripter le truc même si la troisième méthode est meilleure pour scripter.
Et si vous voulez le faire à distance il va falloir d'abord sécuriser le truc :
1. Créer une clé pour authentifier
2. Renseigner cette clé dans la conf
3. Donner les droits à cette clé de modifier la zone
4. Utiliser cette clé à distance
5. Profit
Voilà le détail des étapes:
1. *<kbd>keymgr -t nom-de-la-clé</kbd>*
2. À mettre dans votre /etc/knot/knot.conf
{{< highlight yaml >}}
key:
- id: nom-de-la-clé
algorithm: hmac-sha384
secret: euisrneuisrnesuinesunresuirnesiaunesiaurentauisretauisr
{{< / highlight >}}
3. On donne le droit à cette clé de modifier votre zone :
{{< highlight yaml >}}
acl:
- id: update-via-ma-cle
key: nom-de-la-clé
action: update
zone:
- domaine: lord.re.
…
acl: update-via-ma-cle
{{< / highlight >}}
4. *<kbd>nsupdate -y hmac-sha384:nom-de-la-clé:euisrneuisrnesuinesunresuirnesiaunesiaurentauisretauisr</kbd>*
5. Voilà voilà
Tout va se faire via la commande spéciale knot :
knotc zone-begin lord.re
knotc zone-(un)set lord.re. truc.lord.re. 600 A 1.2.3.4 (que vous pouvez répéter autant de fois que le voulez)
knotc zone-diff lord.re. (c'est optionnel mais ça permet d'avoir un résumé des modifs qui seront appliquées)
knotc zone-commit lord.re.
et voilà c'est pris directement en compte.
Bon l'outil pour envoyer des requêtes et lire les réponses DNS le plus sympa est *dig* (ou kdig pour la version made in knot). Donc un ptit *dig lord.re* vous sortira :
; <<>> DiG 9.11.2 <<>> lord.re
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13708
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;lord.re. IN A
;; ANSWER SECTION:
lord.re. 600 IN A 92.167.84.9
;; Query time: 13 msec
;; SERVER: 10.0.0.254#53(10.0.0.254)
;; WHEN: Wed Oct 11 19:03:54 CEST 2017
;; MSG SIZE rcvd: 52
Bon ça raconte quoi tout ça ? Les trucs importants sont le *status: NOERROR* qui vous indique dans ce cas que c'est bon. Vous trouverez souvent du *NXDOMAIN* qui veut dire Non eXistant Domain, bref ça n'existe pas (l'erreur 404 http quoi) et également le *SERVFAIL* qui indique un souci du serveur.
Ensuite les flags sont sympa surtout le *ad* qui indique que la chaîne DNSSEC est valide.
On trouve ensuite la *QUESTION SECTION* qui montre quelle était votre requête et la *ANSWER SECTION* qui est la réponse obtenue. On voit ensuite le temps qu'a mis la réponse à arriver ainsi que le serveur consulté.
Vous pouvez indiquer quel serveur utiliser en ajoutant *@8.8.8.8* par exemple. Vous pouvez également demander un autre type d'enregistrement en le spécifiant et vous pouvez également demander une réponse validée par DNSSEC. exemple : *dig lord.re @8.8.8.8 +dnssec MX ou dig @8.8.8.8 +dnssec lord.re MX* (c'est plus logique dans cet ordre je trouve).
Avec ça vous couvrez la majeure partie des utilisations.
Traditionnellement on utilise donc plus souvent le DNS comme un simple annuaire pour traduire des noms en adresse IP. Mais on peut également se servir du DNS pour d'autres choses.
Un usage assez courant est le système de DNSBL : DNS Black List. C'est un système qui consiste à créer une liste noire de machines. C'est très utilisé dans les systèmes antispam. En gros on consulte un serveur DNS spécifique, en lui demandant quel est l'adresse de machine.qui.spamme.com ? et il répond avec une adresse IP de la forme *127.a.b.c* avec a, b et c qui correspondent à des valeurs prédéfinies. Si c'est différent de 0 il y a des chances que ce soit du spammeur. C'est un système au final très basique mais rapide et très léger à implémenter.
Voyons plutôt voir comment _nous_ on peut s'en servir. Petit à petit on a rajouté pas mal de nouveaux types d'enregistrements dans le DNS dont certains vraiment très utiles voir indispensables.
Lorsque vous vous connectez à un serveur *SSH*, il envoie son empreinte lors de la connexion. Cela vous permet de vous assurer que vous vous connectez à la bonne machine : si l'empreinte a changé par rapport à une session précédente votre client SSH va vous l'afficher. Le souci est donc lors de la première connexion : Comment être sûr que la première connexion est sûre ? Et bien en publiant l'empreinte dans votre zone DNS par exemple ?
L'empreinte SSH de votre serveur peut donc être collée dans un enregistrement *SSHFP*. Pour la générer, sur le serveur SSH lancez la commande *ssh-keygen -r lord.re*.
lord.re IN SSHFP 1 1 1516af909e7de59af0e4b7cbaefb81c5ddf36b70
lord.re IN SSHFP 1 2 f144fd71beb47a02cc904e305cc35c6ffe034e67b92aa54d1e382c1c1900a104
lord.re IN SSHFP 2 1 83664295d1e46c80cc3ba7865294cbd1649f6350
lord.re IN SSHFP 2 2 c1c1de2b19e6d4e451a9057a3ccc40a53ca29b69c7e2dd006ff4e8884c062ee6
lord.re IN SSHFP 3 1 1929f7d32788a5884d862d2c28a226c73fd62944
lord.re IN SSHFP 3 2 990dfb4b2f3486fb6bf5e5e5a3dd02344da6f42ce5b02992385dfbde30c5d24d
lord.re IN SSHFP 4 1 493848772bcb5b6225424e58e5274984d825f01a
lord.re IN SSHFP 4 2 335d5e9ec2d901b7ffd693fe614f73e4ad0afa40c72d9867dadfd155016c0029
Vous obtiendrez les enregistrements tout bien formatté à coller dans votre zone. Maintenant il est conseillé de dire à votre client SSH de vérifier la présence de SSHFP, donc dans /etc/ssh/ssh_config ajoutez l'option *VerifyHostKeyDns yes* (ou ask). Voilà un bon moyen simple d'améliorer un chouilla la sécurité de SSH. Faites le pour tous vos serveurs SSH.
Là on double le nombre de champs utiles !
lord.re. 600 IN CAA 0 iodef "mailto:lord-x509@lord.re"
lord.re. 600 IN CAA 0 issue "letsencrypt.org"
lord.re. 600 IN CAA 0 issuewild "letsencrypt.org"
La première ligne indique un mail à contacter en cas de comportement suspicieux. La seconde indique quelle CA est autorisée à signer des certs classiques alors que la troisième quelle CA est autorisée à signer des certificats de type wildcard (les certificats qui fonctionnent pour tous les sous-domaines).
Pour *TLSA* c'est un poil plus complexe. Il s'agit d'une des applications de la norme *DANE* (ou DNS Authentication of Named Entities) qui consiste à publier le certificat (ou son hash) d'un service utilisant TLS. En gros DANE pourrait permettre de se passer des CA en plaçant la confiance non plus dans un tier mais dans le DNS. Malheureusement c'est implémenté à peu près nulle part. Cependant on peut conjuguer les CA et TLSA pour accroitre la sécurité. Donc on créer un certificat, on le fait signer par une CA et on le publie dans sa zone DNS. On peut donc l'appliquer à n'importe quel service utilisant TLS : http, smtp, imap, irc, … bref à peu près tout.
Bon là on va pas se faire chier, on va faire comme tout le monde et utiliser
.
- Donc là vous entrez les différents champs (3/1/1)
- Vous collez le certificat (pas la clé privée !)
- le numéro de port du service en question (443 pour https par exemple)
- le protocole utilisé (tcp pour https)
- le nom de domaine concerné par le certificat (www.lord.re par exemple ou juste lord.re)
Et pouf le bouton generate vous filera la jolie ligne à ajouter à votre zone. À noter que pour être conforme à DANE, il faut impérativement que votre zone soit validée via DNSSEC (c'est pas mon cas pour lord.re, pour une sombre histoire de registrar qui veux toujours pas accepter le DS record, bref -___- ).
Ici c'est la folie. Le mail étant un des plus vieux protocoles d'Internet, il y a pas mal de trucs qui s'y sont greffés pour combattre le spam et aussi améliorer l'authenticité des mails. Commençons gentiement.
C'est le plus simple de la bande. Celui-là spécifie quelles sont les machines/ip qui sont autorisées à envoyer des mails en provenance de votre domaine. En théorie si vous avez une configuration classique, les seules machines qui enverront du mail en provenance de votre domaines seront les machines déclarées en MX.
Il existe un champ de type *SPF* mais il est
(dommage), il faut placer ça dans un champs TXT.
lord.re. 600 IN TXT "v=spf1 mx -all"
Ça veut dire les MX sont autorisés et tout le reste doit être jeté (le boulot de l'antispam). Rien d'autre à faire pour ça.
Le *Domain Keys Identified Mail* est un système de signatures cryptographiques qui va signer le mail et ses entêtes. Les serveurs SMTP traitant le mail vont donc devoir vérifier que ça coïncide avec la clé publiée dans le DNS. En gros ça empêche que le message et ses entêtes soient modifiés et cela atteste que c'est bien votre serveur qui sont à l'origine de ce mail.
Ce coup-ci il va falloir configurer votre pile mail pour qu'elle signe vos mails. Je vous laisse vous débrouiller pour ça (hors scope de cet article, mais sachez que rspamd sait très bien faire cela). Bref vous allez donc avoir une clé publique que vous allez publier dans un TXT avec cette allure :
default._domainkey.lord.re. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC06MC2/9/YtSn9BS09oMN26UdKO6DMGlCWYsodQ8P+t2CzsSzqUJxaszJmWZglqZyXRjaCMAFUoOF7GiyhXhqM4rSLGxaPHfrLK7f9YlJYAnqdhzEJdEjP8/vkJoMTJxINP9gEBi+wGSGEhoha514NHHtZ4g+QbJZliahwAjl0BQIDAQAB"
Donc les serveurs mails qui recevront vos mails avec les entêtes DKIM vérifieront votre champ DNS qui va bien pour vérifier que c'est ok. Mais rien n'indique ce qu'ils doivent faire si ça ne correspond pas.
Ha bha le voilà le truc qui va indiquer aux autres serveurs que faire de vos mails si le SPF et/ou le DKIM déconne. *DMARC* est donc complémentaire aux deux précédents. C'est encore un enregistrement de type TXT qui a cette gueule
_dmarc.lord.re. 600 IN TXT "v=DMARC1;p=none;pct=100;rua=mailto:lord-dmarc@lord.re;ruf=mailto:lord-dmarc@lord.re;sp=none;adkim=s;aspf=s"
C'est plutôt explicite :
- le *p=none* indique la politique que doivent adopter les autres serveurs vis-à-vis de vos mails. Avec *none*, c'est indifférent. Si vous êtes absolument sûr de vos règlages vous pouvez mettre *quarantine* voir *reject* pour que ça soit carrément rejeté.
- Le *rua* et *ruf* vous permet d'être contacté par les serveurs mails pour recevoir des rapports
- Et enfin *adkim=s* et *aspf=s* indique que vous voulez une vérif stricte du spf et dkim, c'est-à-dire que le nom doit être parfaitement le même (le mode r pour *relaxed* permet d'émettre depuis un sous-domaine contrairement au *strict*).
Mon conseil c'est de commencer pépère avec une politique à none et si dans six mois vous avez pas de soucis, de monter d'un cran en passant à quarantine et pourquoi pas plus tard à reject. Si c'est pas bon, vous risqueriez de vous tirer une balle dans le panard !
Celui-là c'est un ptit nouveau. Il est pas encore vraiment sorti de l'œuf à vrai dire, mais il est prometteur mais un peu chiant à mettre en place car il dépend du DNS mais aussi d'un serveur web… Ouai il va falloir mettre du json dans .well-known de votre serveur web. C'est pour ça que je l'ai pas encore mis en place mais je pense le faire à terme.
Donc en gros celui-là permet de spécifier comment doivent réagir les serveurs mails se connectant aux votres concernant la crypto : vous pouvez exiger de refuser la connexion si ce n'est pas chiffré. C'est donc vraiment très intéressant d'un point de vue protection de la vie privée de vos mails.
Ça a cette allure ```_mta-sts.lord.re. IN TXT "v=STSv1; id=20160831085700Z;"```. En gros ça donne un numéro de politique à suivre. Ensuite il faudra aller piocher dans le json à quoi correspond la politique correspondant à cet id. À mon avis ça aurait pu tenir dans le DNS toussa mais bon…
Celui-là non plus je ne l'utilise pas (en fait je ne chiffre pas du tout mes mails). Mais il permet de publier sa clé publique dans sa zone DNS. C'est un peu mieux que d'utiliser un serveur de clé publique. N'utilisant pas le truc j'approfondierai pas plus mais il existe
.
Pour résumer on se protège du spoof grâce à DKIM et SPF. On s'assure de l'intégrité de ses mails via DKIM et DMARC. On s'assure(ra) que personne ne puisse lire les mails grâce à STS (en dehors des serveurs émission/réception) et on s'assure même que les serveurs eux-mêmes ne puissent lire le contenu grâce à PGP. Voilà notre stack mail est blindée.
Ouai vite fait une ptite conclusion. Le DNS contient des données qui sont publiques mais dont l'authenticité est de plus en plus critique. Modifier des requêtes DNS (enfin les réponses) à la volée pour modifier une clé PGP ou SSHFP ça pourrait avoir des conséquences assez désastreuses. C'est pour ça qu'il est indispensable de déployer *DNSSEC* sur votre domaine. Avec knot c'est vraiment simple. D'ailleurs est-ce que votre résolveur DNS actuel valide DNSSEC ?
-
-
-
-
-
-
------------------------------------
------------------------------------
[27/10/2017] [dns réseau adminsys knot dane dnssec]
------------------------------------
-- Response ended
-- Page fetched on Sat May 18 04:05:23 2024