Vous avez sécurisé votre domaine avec DNSSEC et DANE ? Très bien ! Il a cependant quelques petites choses à garder à l’esprit pour anticiper les difficultés et bien gérer la maintenance.
De la rigueur dans la gestion des enregistrements DS (DNSSEC) et TLSA (DANE)
Les enregistrements au niveau du DNS sont à manipuler avec précaution, ce ne sont pas le genre de choses que l’on peut configurer une bonne fois pour toute. On ne publie pas des enregistrements DS (DNSSEC) et TLSA (DANE) par effet de mode.
Les zones DNSSEC doivent être signées régulièrement et les enregistrements TLSA mis à jour en cas de changement de certificats TLS. Si la maintenance n’est pas assurée correctement, le domaine risque d’être injoignable.
Automatiser la signature de la zone DNS
Vous devez absolument mettre en place un crontab qui signe votre zone DNS automatiquement et vous informe du bon fonctionnement de votre zone.
Mettre à jour les enregistrements TLSA avant la chaine de certificat du serveur
Vous devez absolument mettre à jour les enregistrements TLSA avant de mettre à jour la chaine de certificat du serveur (déploiement de nouvelles clés ou utilisation d’un nouveau certificat TLS issu par une autorité de certification).
Lorsque vous mettez à jour votre certificat, vous devez garder les anciens enregistrements TLSA dans votre fichier de zone et ajouter les nouveaux enregistrements TLSA.
Les anciens et les nouveaux doivent donc coexister, le temps que les enregistrements DNS soient mis à jour, après quelques TTLS (quelques jours seulement).
Par exemple, la key1 est déployée initialement sur le serveur :
_25._tcp.mail.example.com. IN TLSA 3 0 1 Code language: CSS (css)On ajoute la nouvelle clé key2 pendant quelques jours, juste derrière la key1 :
_25._tcp.mail.example.com. IN TLSA 3 0 1
_25._tcp.mail.example.com. IN TLSA 3 0 1 Code language: CSS (css)Après le déploiement de la key2, on supprime la key1 :
_25._tcp.mail.example.com. IN TLSA 3 0 1 Code language: CSS (css)SMTP : choisir le bon type d’enregistrement TLSA
Pour le SMTP, l’usage du certificat pour l’enregistrement TLSA doit être soit DANE-TA(2) or DANE-EE(3). Les usages PKIX-TA(0) et PKIX-EE(1) ne sont pas supportés.
Un sélecteur et un hash TLSA valides
Attention à bien vérifier que le sélecteur TLSA est bien valide et que le hash de l’enregistrement TLSA est bien celui du certificat. Il vaut mieux extraire ce hash depuis le certificat TLS en ligne de commande.
Le hash TLSA doit être généré uniquement à partir de la forme binaire ASN.1 DER du certificat ou de la clé publique (au format SPKI) et non dans un autre format.
La disponibilité sélective de STARTTLS
La disponibilité sélective de STARTTLS n’est pas compatible avec DANE. Il faut donc s’assurer que STARTTLS est toujours activé ou que les enregistrements TLSA pour DANE ne sont pas publiés pour ce domaine.
Autoriser les requêtes TLSA dans le parefeu
Si le domaine est validé par DNSSEC, il faut s’assurer que le parefeu autorise les requêtes TLSA à joindre le serveur de nom de domaine, sur tous les types d’adresses, en IPv4 comme IPv6.
Implémentation partielle
DANE ne protège votre domaine que si le domaine est validé par DNSSEC, si tous les hôtes MX sont également dans des zones validées par DNSSEC (leurs enregistrements A/AAAA sont « sécurisés »), et tous les hôtes MX possèdent des enregistrements TLSA "_25._tcp".
La publication d’enregistrements TLSA pour DANE pour vos serveurs SMTP ne fait sens que si vous prévoyez à long terme de publier des enregistrements TLSA pour tous vos hôtes MX.
C’est comme cela que vous limiterez le nombre et l’impact d’attaques au niveau du transport SMTP (STARTTLS downgrade ou autres attaques).
Inspiré des Common Mistakes de Dane SMTP Validator.
Synopsis » Monter un serveur dédié de A à Z
- Serveur dédié : installation d’Apache, PHP, MySQL et Webmin
- Serveur dédié : créer la base de données MySQL et importer WordPress
- Serveur dédié : créer et activer un Virtual Host sous Apache
- Serveur dédié : changer les DNS du nom de domaine et le faire pointer vers le serveur
- Serveur dédié : sécurisation des services avec iptables et fail2ban
- Serveur dédié : sécurisation de la couche TCP/IP
- Serveur dédié : création d’un serveur mail Postfix (sécurisé avec Saslauthd et certificat SSL) et Courier (accès POP et IMAP) utilisant une base MySQL d’utilisateurs/domaines virtuels
- Serveur dédié : sécuriser Apache 2 avec ModSecurity
- Serveur dédié : CHMOD récursif sur des fichiers ou répertoires en ligne de commande
- Serveur dédié : installer APC comme système de cache et configurer Varnish comme reverse-proxy pour Apache pour améliorer les performances
- Serveur dédié : afficher la véritable IP derrière un reverse-proxy comme Varnish
- Serveur dédié : intégrer SSH à WordPress pour mettre à jour le core, les plugins et les thèmes
- Serveur dédié : installer la dernière version d’APC par SVN
- Serveur dédié : analyse des performances du serveur
- Serveur dédié : mettre à jour le noyau Debian de la Kimsufi
- Serveur dédié : sauvegarde automatique des fichiers avec Backup Manager sur le serveur de sauvegarde OVH
- Serveur dédié : configurer la limite mémoire pour PHP et Suhosin
- Bash : supprimer tous les fichiers et sous-répertoires d’un répertoire
- Serveur dédié : impossible de se connecter à un port distant
- Rsync: rapatrier les fichiers du serveur à la maison
- Bash : réparer les tables MySQL en cas de crash
- Serveur dédié : création d’une seedbox avec Transmission
- Serveur dédié : des paquets LAMP à jour sous Debian
- Serveur dédié : mise à jour vers Debian 7 Wheezy
- Serveur dédié : activer X11 forwarding pour SSH
- Serveur dédié : optimiser toutes les images JPG et PNG avec OptiPNG et JpegOptim
- Postfix : résoudre l’erreur “fatal: www-data(33): message file too big”
- Serveur dédié : mise en place de l’IPv6
- WordPress : accorder les bonnes permissions aux fichiers et dossiers avec chown et chmod
- WordPress : héberger les images sur un sous-domaine
- Serveur dédié : ajouter l’authentification SPF, Sender-ID et DKIM à Postfix et Bind9 avec opendkim
- Apache : lorsque le domaine seul (sans WWW) renvoie une erreur 403
- Serveur dédié : sécuriser Apache avec HTTPS (HTTP avec la couche TLS/SSL) en Perfect Forward Secrecy
- Serveur dédié : passer WordPress en HTTPS (TLS/SSL)
- Serveur dédié : configurer Webmin en TLS avec un certificat SSL
- Serveur dédié : configurer Transmission pour accéder au WebUI via TLS-SSL
- Serveur dédié : installer et configurer Varnish 4
- Serveur dédié : passage au mod FastCGI et PHP-FPM avec Apache MPM Worker
- Récupérer un serveur Kimsufi après un plantage de kernel avec le mode rescue OVH
- Serveur dédié : configurer Postfix et Courier pour utiliser TLS-SSL en Perfect Forward Secrecy
- Serveur dédié : retirer Varnish, devenu inutile avec HTTPS
- Serveur dédié : installer la dernière version d’OpenSSL sous Debian
- Serveur dédié : activer l’IP canonique du serveur sous Apache
- Serveur dédié : mise à jour vers PHP 5.6
- MySQL : convertir les tables MyISAM au format InnoDB
- Serveur dédié : optimiser toutes les images GIF avec GIFsicle
- Serveur dédié : migration de MySQL vers MariaDB
- BASH : lister, bloquer et débloquer des adresses IP avec iptables
- Serveur dédié : produire une meilleure réserve d’entropie avec haveged
- Serveur dédié : mettre en place DNSSEC pour sécuriser les DNS du domaine
- Serveur dédié : mise en place du protocole DANE
- 8 règles d’or pour bien déployer DNSSEC et DANE
- Serveur dédié : installer PHP7 FPM avec FastCGI sous Debian
- Serveur dédié : optimiser la couche TCP
- Fail2Ban: protéger Postfix contre les attaques DoS de types AUTH, UNKNOWN et EHLO
- Serveur dédié : mettre à jour Apache pour HTTP/2
- Serveur dédié : ajouter le domaine à la liste HSTS preload
- Serveur dédié : ajouter l’authentification DMARC à Postfix et BIND
- Serveur dédié : à la recherche de l’inode perdue ou comment résoudre le problème “no space left on device”
- Serveur dédié : installer NginX avec support HTTP2 et certificat SSL, PHP, MariaDB sous Debian
Vous voulez un site WordPress ou WooCommerce qui soit à la fois rapide et performant? Vous êtes au bon endroit.
