Matt Biscay: développeur WordPress et WooCommerce pour SkyMinds
Hébergement OVH : passer à TLS 1.2 pour WooCommerce et PayPal photo 1

Hébergement OVH : passer à TLS 1.2+ pour WooCommerce et PayPal

Si vous possédez une boutique en ligne et que vous acceptez PayPal comme moyen de paiement, vous n’êtes pas sans savoir qu’à partir du 30 juin, PayPal exigera une connexion TLS version 1.2 pour gérer la transaction entre votre boutique et PayPal.

Concrètement, votre serveur ou votre hébergement doit être configuré pour servir les pages en HTTPS (certificat SSL obligatoire) et avec une version d’OpenSSL qui donne la priorité au protocole TLS version 1.2+.

Hébergement OVH : passer à TLS 1.2 pour WooCommerce et PayPal photo 1

Chez OVH, la version d’OpenSSL dépend de la version de PHP configurée pour votre hébergement et surtout du mode utilisé. Pour avoir la dernière version d’OpenSSL, il faut absolument être en mode Stable.

Cela ne prend que quelques minutes à configurer.

TLS sur un serveur dédié

Dans le cas de votre serveur dédié, il suffit de mettre à jour OpenSSL et d’éditer la configuration du serveur (Apache / nginx) pour désactiver les protocoles SSL, TLSv1, TLS v1.1 pour ne garder que TLS v1.2 et TLS v1.3.

TLS sur un hébergement mutualisé OVH

Dans le cadre d’un hébergement mutualisé OVH voici la marche à suivre. Commencez par vous rendre dans le Manager OVH puis :

  1. activer le certificat SSL Let’s Encrypt.
  2. choisir une version de PHP récente en mode Stable.
  3. passer l’intégralité de votre WordPress / Woocommerce en https (si ce n’est déjà fait mais si vous avez une boutique en ligne, ce devrait être le cas depuis longtemps).

En image, voici ce que cela donne :

Hébergement OVH : passer à TLS 1.2 pour WooCommerce et PayPal photo

C’est l’étape 2 qui est primordiale pour activer TLS 1.2 : cela permet de passer d’OpenSSL 0.9.8 à OpenSSL 1.0.1t à l’heure où j’écris ces lignes.

Vérification TLS v1.2

Pour connaître la version d’OpenSSL en vigueur sur votre serveur :

openssl version

Enfin, pour savoir si la connexion entre votre serveur et les serveurs de PayPal se fait bien à l’aide du chiffrement TLS 1.2, lancez cette commande sur votre serveur/hébergement dans un terminal :

php -r '$ch = curl_init(); curl_setopt($ch, CURLOPT_URL, "https://tlstest.paypal.com/"); var_dump(curl_exec($ch)); var_dump(curl_error($ch));'

Si la connexion est bien servie en TLS 1.2, le résultat devrait être :

PayPal_Connection_OKbool(true)
string(0) ""

Voilà, en espérant que cela puisse vous servir. C’est simple à mettre en place et ne prend que quelques minutes pour retrouver un chiffrement plus sécurisé.

Si vous avez besoin d’un développeur WooCommerce professionel pour mettre tout cela en place, contactez-moi.

Bonne mise à jour.

Serveur dédié : ajouter l'authentification DMARC à Postfix et BIND photo

Serveur dédié : ajouter l’authentification DMARC à Postfix et BIND

Notre serveur de mail possède une identification SPF, Sender-ID et DKIM et est sécurisé par un certificat TLS. Nous allons aujourd’hui voir comment lui adjoindre l’authentification DMARC.

Aux origines de l’authentification des emails

Les technologies d’authentification des emails SPF et DKIM ont été développées afin de fournir une plus grande assurance sur l’identité de l’expéditeur d’un message.

L’adoption de ces technologies a augmenté régulièrement mais le problème des emails frauduleux et trompeurs n’a pu etre réglé.

Il existe une multitude d’environnements et de systèmes différents pour envoyer des emails, et on fait souvent appel à des applications tierces pour gérer les envois.

S’assurer que chaque message peut être authentifié avec SPF ou DKIM n’est pas une mince affaire étant donné que le traitement des emails se fait en temps réel.

Si le propriétaire d’un domaine envoie un groupe de message et que certains peuvent être authentifiés et d’autres non, alors les récipiendaires de ces messages sont obligés de faire la distinction entre les messages légitimes qui ne sont pas authentifiés et les messages frauduleux qui ne sont pas authentifiés non plus.

Par nature, les algorithmes de spam sont sujets aux erreurs et doivent évoluer constamment pour répondre aux nouvelles tactiques des spammeurs. Au final, certains messages frauduleux parviendront toujours à atteindre la boite de réception du destinataire final.

Le seul moyen de résoudre ces problèmes est de partager l’information entre l’expéditeur et le destinataire. Les destinataires vont fournir des informations sur leur infrastructure d’authentification des messages et les expéditeurs vont dire aux destinataires quoi faire lorsqu’un message reçu n’est pas authentifié.

En 2007, Paypal a été pionnier dans cette approche et a construit un système avec l’aide de Yahoo! Mail puis Gmail. Les résultats ont été très probants, menant à une baisse du nombre des emails frauduleux qui se faisaient passer comme venant des serveurs de Paypal acceptés par les destinataires.

DMARC : un protocole d’authentification email

DMARC, qui signifie Domain-based Message Authentication, Reporting and Conformance est un protocole d’authentification email qui se base sur les protocoles SPF et DKIM – maintenant largement déployés – en ajoutant une fonction de rapport qui permet aux expéditeurs et destinataires d’améliorer et vérifier la protection du domaine contre les emails frauduleux.

DMARC se base sur le processus d’authentification des messages entrants et aide les destinataires à déterminer si les message est “aligné” avec ce que le destinataire connaît de l’expéditeur. Sinon, DMARC inclut une manière de gérer les messages “non-alignés”.

Voici le principe de fonctionnement de DMARC :

Serveur dédié : ajouter l'authentification DMARC à Postfix et Bind9 photo

Il est important de noter que DMARC est basé à la fois sur les spécifications de DKIM (DomainKeys Identified Mail) et SPF (Sender Policy Framework) qui sont toujours en cours de développement par l’IETF.

Lire la suite

Sommaire de la série Monter un serveur dédié de A à Z

  1. Serveur dédié : installation d’Apache, PHP, MySQL et Webmin
  2. Serveur dédié : créer la base de données MySQL et importer WordPress
  3. Serveur dédié : créer et activer un Virtual Host sous Apache
  4. Serveur dédié : changer les DNS du nom de domaine et le faire pointer vers le serveur
  5. Serveur dédié : sécurisation des services avec iptables et fail2ban
  6. Serveur dédié : sécurisation de la couche TCP/IP
  7. 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
  8. Serveur dédié : sécuriser Apache 2 avec ModSecurity
  9. Serveur dédié : CHMOD récursif sur des fichiers ou répertoires en ligne de commande
  10. Serveur dédié : installer APC comme système de cache et configurer Varnish comme reverse-proxy pour Apache pour améliorer les performances
  11. Serveur dédié : afficher la véritable IP derrière un reverse-proxy comme Varnish
  12. Serveur dédié : intégrer SSH à WordPress pour mettre à jour le core, les plugins et les thèmes
  13. Serveur dédié : installer la dernière version d’APC par SVN
  14. Serveur dédié : analyse des performances du serveur
  15. Serveur dédié : mettre à jour le noyau Debian de la Kimsufi
  16. Serveur dédié : sauvegarde automatique des fichiers avec Backup Manager sur le serveur de sauvegarde OVH
  17. Serveur dédié : configurer la limite mémoire pour PHP et Suhosin
  18. Bash : supprimer tous les fichiers et sous-répertoires d’un répertoire
  19. Serveur dédié : impossible de se connecter à un port distant
  20. Rsync: rapatrier les fichiers du serveur à la maison
  21. Bash : réparer les tables MySQL en cas de crash
  22. Serveur dédié : création d’une seedbox avec Transmission
  23. Serveur dédié : des paquets LAMP à jour sous Debian
  24. Serveur dédié : mise à jour vers Debian 7 Wheezy
  25. Serveur dédié : activer X11 forwarding pour SSH
  26. Serveur dédié : optimiser toutes les images JPG et PNG avec OptiPNG et JpegOptim
  27. Postfix : résoudre l’erreur “fatal: www-data(33): message file too big”
  28. Serveur dédié : mise en place de l’IPv6
  29. WordPress : accorder les bonnes permissions aux fichiers et dossiers avec chown et chmod
  30. WordPress : héberger les images sur un sous-domaine
  31. Serveur dédié : ajouter l’authentification SPF, Sender-ID et DKIM à Postfix et Bind9 avec opendkim
  32. Apache : lorsque le domaine seul (sans WWW) renvoie une erreur 403
  33. Serveur dédié : sécuriser Apache avec HTTPS (HTTP avec la couche TLS/SSL) en Perfect Forward Secrecy
  34. Serveur dédié : passer WordPress en HTTPS (TLS/SSL)
  35. Serveur dédié : configurer Webmin en TLS avec un certificat SSL
  36. Serveur dédié : configurer Transmission pour accéder au WebUI via TLS-SSL
  37. Serveur dédié : installer et configurer Varnish 4
  38. Serveur dédié : passage au mod FastCGI et PHP-FPM avec Apache MPM Worker
  39. Récupérer un serveur Kimsufi après un plantage de kernel avec le mode rescue OVH
  40. Serveur dédié : configurer Postfix et Courier pour utiliser TLS-SSL en Perfect Forward Secrecy
  41. Serveur dédié : retirer Varnish, devenu inutile avec HTTPS
  42. Serveur dédié : installer la dernière version d’OpenSSL sous Debian
  43. Serveur dédié : activer l’IP canonique du serveur sous Apache
  44. Serveur dédié : mise à jour vers PHP 5.6
  45. MySQL : convertir les tables MyISAM au format InnoDB
  46. Serveur dédié : optimiser toutes les images GIF avec GIFsicle
  47. Serveur dédié : migration de MySQL vers MariaDB
  48. BASH : lister, bloquer et débloquer des adresses IP avec iptables
  49. Serveur dédié : produire une meilleure réserve d’entropie avec haveged
  50. Serveur dédié : mettre en place DNSSEC pour sécuriser les DNS du domaine
  51. Serveur dédié : mise en place du protocole DANE
  52. 8 règles d’or pour bien déployer DNSSEC et DANE
  53. Serveur dédié : installer PHP7 FPM avec FastCGI sous Debian
  54. Serveur dédié : optimiser la couche TCP
  55. Fail2Ban: protéger Postfix contre les attaques DoS de types AUTH, UNKNOWN et EHLO
  56. Serveur dédié : mettre à jour Apache pour HTTP/2
  57. Serveur dédié : ajouter le domaine à la liste HSTS preload
  58. Serveur dédié : ajouter l’authentification DMARC à Postfix et BIND
  59. Serveur dédié : à la recherche de l’inode perdue ou comment résoudre le problème “no space left on device”
  60. Serveur dédié : installer NginX avec support HTTP2 et certificat SSL, PHP, MariaDB sous Debian
Du bunker au cloud : les hébergeurs de la cybercriminalité (et des gouvernements) photo 1

Du bunker au cloud : les hébergeurs de la cybercriminalité (et des gouvernements)

Internet est basé sur une architecture bien réelle, avec des serveurs hébergés dans des datacenters dans le monde entier.

Les cybercriminels aussi utilisent des serveurs pour archiver les données qu’ils volent ou pour maintenir toute une infrastructure comme l’envoi de spams ou scams.

Dans les années 2000, des hébergeurs appelés “bulletproof hosters” (l’équivalent internet des banques suisses) offraient de stocker des données sans poser de questions et surtout sans répondre à celles des autorités – devenant ipso facto les repaires préférés des cybercriminels.

Certains appartiennent même au folklore d’internet comme le bunker anti-nucléaire CyberBunker – datant de la guerre froide -, The Pirate Bay ou la principauté auto-proclamée de Sealand, ancienne plateforme pétrolière basée dans les eaux internationales et reconvertie en un datacenter uniquement accessible par hélicoptère.

Cependant, la plupart de ces endroits précurseurs ont subi des raids ou ont été dans l’obligation de cesser leurs activités et les cybercriminels ont depuis stocké leurs données ailleurs.

Le documentaire The Most Dangerous Town: Where Cybercrime Goes to Hide, réalisé par l’éditeur d’antivirus Norton, traite de l’évolution des lieux d’hébergement des données.

Aujourd’hui, les pirates n’utilisent plus de bunkers ou de plateformes pétrolières mais préfèrent se cacher au vu et au su de tous, derrière une vitrine d’une entreprise qui semble légale.

Les cybercriminels préfèrent maintenant utiliser des hébergeurs standards et cacher leurs activités à travers l’utilisation de serveurs proxies et VPN.

Une autre tactique employée, visible dans le documentaire, est l’utilisation d’appartements vides comme adresse professionnelle.

Ils peuvent ainsi changer très rapidement d’adresse au moindre mouvement des forces de police et plus rapidement que la délivrance des mandats de perquisition.

La cybercriminalité est donc passée du monde caché et souterrain des bunkers au monde aérien du cloud, nuage d’informations qui permet de cacher leurs exactions.

Tout cela rend bien sûr leur identification et arrestation bien plus difficiles pour les forces de l’ordre.

Serveur dédié : ajouter le domaine à la liste HSTS preload photo 1

Serveur dédié : ajouter le domaine à la liste HSTS preload

Maintenant que votre site est servi en HTTPS à l’aide d’un certificat SSL/TLS et sécurisé par DNSSEC et DANE, il est maintenant temps de l’ajouter à la liste HSTS preload.

HSTS (HTTP Strict Transport Security) est un entête de réponse qui demande au navigateur de toujours utiliser SSL/TLS pour communiquer avec votre site.

Qu’importe si l’utilisateur ou le lien qu’il clique spécifie HTTP, HSTS forcera l’usage d’HTTPS.

Toutefois, cela laisse l’utilisateur vulnérable lors de sa toute première connexion à un site. L’HSTS preloading corrige donc cela.

Serveur dédié : ajouter le domaine à la liste HSTS preload photo 1

L’HSTS preloading

Il existe une liste qui permet d’inclure un domaine dans la liste HTTP Strict Transport Security preload de Chrome.

Il s’agit d’une liste de sites qui sont codés en dur dans Chrome comme étant uniquement servis en HTTPS.

Firefox, Safari, IE 11 and Edge ont également des listes HSTS preload qui incluent la liste de Chrome.

Pré-requis

Il y a quelques pré-requis avant de pouvoir être inclus dans la liste HSTS preload. Votre site doit:

  • avoir un certificat valide,
  • rediriger tout le trafic HTTP vers HTTPS, c’est-à-dire n’être servi qu’en HTTPS uniquement,
  • servir tous les sous-domaines en HTTPS, même le sous-domaine www si un enregistrement DNS existe pour ce sous-domaine,
  • servir un entête HSTS pour les requêtes HTTPS avec une date d’expiration supérieure à 18 semaines (10886400 seconds), les tokens includeSubdomains et preload doivent impérativement être spécifiés. Si vous servez une redirection depuis votre site HTTPS, cette redirection doit obligatoirement contenir l’entête HSTS.
  • L’entête HSTS doit être présent dans le VirtualHost HTTP aussi, juste avant la redirection vers le VirtualHost HTTPS.

Lire la suite

Sommaire de la série Monter un serveur dédié de A à Z

  1. Serveur dédié : installation d’Apache, PHP, MySQL et Webmin
  2. Serveur dédié : créer la base de données MySQL et importer WordPress
  3. Serveur dédié : créer et activer un Virtual Host sous Apache
  4. Serveur dédié : changer les DNS du nom de domaine et le faire pointer vers le serveur
  5. Serveur dédié : sécurisation des services avec iptables et fail2ban
  6. Serveur dédié : sécurisation de la couche TCP/IP
  7. 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
  8. Serveur dédié : sécuriser Apache 2 avec ModSecurity
  9. Serveur dédié : CHMOD récursif sur des fichiers ou répertoires en ligne de commande
  10. Serveur dédié : installer APC comme système de cache et configurer Varnish comme reverse-proxy pour Apache pour améliorer les performances
  11. Serveur dédié : afficher la véritable IP derrière un reverse-proxy comme Varnish
  12. Serveur dédié : intégrer SSH à WordPress pour mettre à jour le core, les plugins et les thèmes
  13. Serveur dédié : installer la dernière version d’APC par SVN
  14. Serveur dédié : analyse des performances du serveur
  15. Serveur dédié : mettre à jour le noyau Debian de la Kimsufi
  16. Serveur dédié : sauvegarde automatique des fichiers avec Backup Manager sur le serveur de sauvegarde OVH
  17. Serveur dédié : configurer la limite mémoire pour PHP et Suhosin
  18. Bash : supprimer tous les fichiers et sous-répertoires d’un répertoire
  19. Serveur dédié : impossible de se connecter à un port distant
  20. Rsync: rapatrier les fichiers du serveur à la maison
  21. Bash : réparer les tables MySQL en cas de crash
  22. Serveur dédié : création d’une seedbox avec Transmission
  23. Serveur dédié : des paquets LAMP à jour sous Debian
  24. Serveur dédié : mise à jour vers Debian 7 Wheezy
  25. Serveur dédié : activer X11 forwarding pour SSH
  26. Serveur dédié : optimiser toutes les images JPG et PNG avec OptiPNG et JpegOptim
  27. Postfix : résoudre l’erreur “fatal: www-data(33): message file too big”
  28. Serveur dédié : mise en place de l’IPv6
  29. WordPress : accorder les bonnes permissions aux fichiers et dossiers avec chown et chmod
  30. WordPress : héberger les images sur un sous-domaine
  31. Serveur dédié : ajouter l’authentification SPF, Sender-ID et DKIM à Postfix et Bind9 avec opendkim
  32. Apache : lorsque le domaine seul (sans WWW) renvoie une erreur 403
  33. Serveur dédié : sécuriser Apache avec HTTPS (HTTP avec la couche TLS/SSL) en Perfect Forward Secrecy
  34. Serveur dédié : passer WordPress en HTTPS (TLS/SSL)
  35. Serveur dédié : configurer Webmin en TLS avec un certificat SSL
  36. Serveur dédié : configurer Transmission pour accéder au WebUI via TLS-SSL
  37. Serveur dédié : installer et configurer Varnish 4
  38. Serveur dédié : passage au mod FastCGI et PHP-FPM avec Apache MPM Worker
  39. Récupérer un serveur Kimsufi après un plantage de kernel avec le mode rescue OVH
  40. Serveur dédié : configurer Postfix et Courier pour utiliser TLS-SSL en Perfect Forward Secrecy
  41. Serveur dédié : retirer Varnish, devenu inutile avec HTTPS
  42. Serveur dédié : installer la dernière version d’OpenSSL sous Debian
  43. Serveur dédié : activer l’IP canonique du serveur sous Apache
  44. Serveur dédié : mise à jour vers PHP 5.6
  45. MySQL : convertir les tables MyISAM au format InnoDB
  46. Serveur dédié : optimiser toutes les images GIF avec GIFsicle
  47. Serveur dédié : migration de MySQL vers MariaDB
  48. BASH : lister, bloquer et débloquer des adresses IP avec iptables
  49. Serveur dédié : produire une meilleure réserve d’entropie avec haveged
  50. Serveur dédié : mettre en place DNSSEC pour sécuriser les DNS du domaine
  51. Serveur dédié : mise en place du protocole DANE
  52. 8 règles d’or pour bien déployer DNSSEC et DANE
  53. Serveur dédié : installer PHP7 FPM avec FastCGI sous Debian
  54. Serveur dédié : optimiser la couche TCP
  55. Fail2Ban: protéger Postfix contre les attaques DoS de types AUTH, UNKNOWN et EHLO
  56. Serveur dédié : mettre à jour Apache pour HTTP/2
  57. Serveur dédié : ajouter le domaine à la liste HSTS preload
  58. Serveur dédié : ajouter l’authentification DMARC à Postfix et BIND
  59. Serveur dédié : à la recherche de l’inode perdue ou comment résoudre le problème “no space left on device”
  60. Serveur dédié : installer NginX avec support HTTP2 et certificat SSL, PHP, MariaDB sous Debian
Fail2Ban: protéger Postfix contre les attaques AUTH DoS photo

Fail2Ban: protéger Postfix contre les attaques DoS de types AUTH, UNKNOWN et EHLO

Aujourd’hui, Jac m’envoie un message pour m’informer que sa redirection email ne fonctionne plus.

Je lance donc un terminal et vérifie les logs de Postfix, qui chargent des dizaines de lignes d’erreurs de ce type:

Dec 15 16:30:33 mail postfix/smtpd[5912]: connect from static-68-236-203-102.nwrk.east.verizon.net[68.236.203.102]
Dec 15 16:30:34 mail postfix/smtpd[5912]: lost connection after AUTH from static-68-236-203-102.nwrk.east.verizon.net[68.236.203.102]
Dec 15 16:30:34 mail postfix/smtpd[5912]: disconnect from static-68-236-203-102.nwrk.east.verizon.net[68.236.203.102]
Dec 15 16:30:34 mail postfix/smtpd[5908]: connect from static-68-236-203-102.nwrk.east.verizon.net[68.236.203.102]
Dec 15 16:30:34 mail postfix/smtpd[5908]: lost connection after AUTH from static-68-236-203-102.nwrk.east.verizon.net[68.236.203.102]
Dec 15 16:30:34 mail postfix/smtpd[5908]: disconnect from static-68-236-203-102.nwrk.east.verizon.net[68.236.203.102]

Comme vous pourvez le constater, ça débite et ça impacte forcément les ressources du système. Voyons donc comment nous pouvons y mettre un terme.

Fail2Ban: protéger Postfix contre les attaques AUTH DoS photo

Pré-requis : fail2ban

Nous allons utiliser fail2ban, un compagnon très utile pour surveiller les logs et analyser les comportements néfastes à l’aide d’expressions régulières.

Je vous invite à relire le guide d’installation de fail2ban.

Nouvelle définition dans fail2ban : postfix-auth

Nous ajoutons donc une nouvelle définition, [postfix-auth], dans notre fichier jail.local:

nano /etc/fail2ban/jail.local

On l’ajoute à la fin des déclarations pour les serveurs mails :

[postfix-auth]
enabled     = true
filter      = postfix.auth
action      = iptables-multiport[name=postfix, port="http,https,smtp,submission,pop3,pop3s,imap,imaps,sieve", protocol=tcp]
#           sendmail[name=Postfix, dest=you@mail.com]
logpath     = /var/log/mail.log

Je désactive volontairement l’envoi des notifications, ce serait un comble.

Lire la suite

Sommaire de la série Monter un serveur dédié de A à Z

  1. Serveur dédié : installation d’Apache, PHP, MySQL et Webmin
  2. Serveur dédié : créer la base de données MySQL et importer WordPress
  3. Serveur dédié : créer et activer un Virtual Host sous Apache
  4. Serveur dédié : changer les DNS du nom de domaine et le faire pointer vers le serveur
  5. Serveur dédié : sécurisation des services avec iptables et fail2ban
  6. Serveur dédié : sécurisation de la couche TCP/IP
  7. 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
  8. Serveur dédié : sécuriser Apache 2 avec ModSecurity
  9. Serveur dédié : CHMOD récursif sur des fichiers ou répertoires en ligne de commande
  10. Serveur dédié : installer APC comme système de cache et configurer Varnish comme reverse-proxy pour Apache pour améliorer les performances
  11. Serveur dédié : afficher la véritable IP derrière un reverse-proxy comme Varnish
  12. Serveur dédié : intégrer SSH à WordPress pour mettre à jour le core, les plugins et les thèmes
  13. Serveur dédié : installer la dernière version d’APC par SVN
  14. Serveur dédié : analyse des performances du serveur
  15. Serveur dédié : mettre à jour le noyau Debian de la Kimsufi
  16. Serveur dédié : sauvegarde automatique des fichiers avec Backup Manager sur le serveur de sauvegarde OVH
  17. Serveur dédié : configurer la limite mémoire pour PHP et Suhosin
  18. Bash : supprimer tous les fichiers et sous-répertoires d’un répertoire
  19. Serveur dédié : impossible de se connecter à un port distant
  20. Rsync: rapatrier les fichiers du serveur à la maison
  21. Bash : réparer les tables MySQL en cas de crash
  22. Serveur dédié : création d’une seedbox avec Transmission
  23. Serveur dédié : des paquets LAMP à jour sous Debian
  24. Serveur dédié : mise à jour vers Debian 7 Wheezy
  25. Serveur dédié : activer X11 forwarding pour SSH
  26. Serveur dédié : optimiser toutes les images JPG et PNG avec OptiPNG et JpegOptim
  27. Postfix : résoudre l’erreur “fatal: www-data(33): message file too big”
  28. Serveur dédié : mise en place de l’IPv6
  29. WordPress : accorder les bonnes permissions aux fichiers et dossiers avec chown et chmod
  30. WordPress : héberger les images sur un sous-domaine
  31. Serveur dédié : ajouter l’authentification SPF, Sender-ID et DKIM à Postfix et Bind9 avec opendkim
  32. Apache : lorsque le domaine seul (sans WWW) renvoie une erreur 403
  33. Serveur dédié : sécuriser Apache avec HTTPS (HTTP avec la couche TLS/SSL) en Perfect Forward Secrecy
  34. Serveur dédié : passer WordPress en HTTPS (TLS/SSL)
  35. Serveur dédié : configurer Webmin en TLS avec un certificat SSL
  36. Serveur dédié : configurer Transmission pour accéder au WebUI via TLS-SSL
  37. Serveur dédié : installer et configurer Varnish 4
  38. Serveur dédié : passage au mod FastCGI et PHP-FPM avec Apache MPM Worker
  39. Récupérer un serveur Kimsufi après un plantage de kernel avec le mode rescue OVH
  40. Serveur dédié : configurer Postfix et Courier pour utiliser TLS-SSL en Perfect Forward Secrecy
  41. Serveur dédié : retirer Varnish, devenu inutile avec HTTPS
  42. Serveur dédié : installer la dernière version d’OpenSSL sous Debian
  43. Serveur dédié : activer l’IP canonique du serveur sous Apache
  44. Serveur dédié : mise à jour vers PHP 5.6
  45. MySQL : convertir les tables MyISAM au format InnoDB
  46. Serveur dédié : optimiser toutes les images GIF avec GIFsicle
  47. Serveur dédié : migration de MySQL vers MariaDB
  48. BASH : lister, bloquer et débloquer des adresses IP avec iptables
  49. Serveur dédié : produire une meilleure réserve d’entropie avec haveged
  50. Serveur dédié : mettre en place DNSSEC pour sécuriser les DNS du domaine
  51. Serveur dédié : mise en place du protocole DANE
  52. 8 règles d’or pour bien déployer DNSSEC et DANE
  53. Serveur dédié : installer PHP7 FPM avec FastCGI sous Debian
  54. Serveur dédié : optimiser la couche TCP
  55. Fail2Ban: protéger Postfix contre les attaques DoS de types AUTH, UNKNOWN et EHLO
  56. Serveur dédié : mettre à jour Apache pour HTTP/2
  57. Serveur dédié : ajouter le domaine à la liste HSTS preload
  58. Serveur dédié : ajouter l’authentification DMARC à Postfix et BIND
  59. Serveur dédié : à la recherche de l’inode perdue ou comment résoudre le problème “no space left on device”
  60. Serveur dédié : installer NginX avec support HTTP2 et certificat SSL, PHP, MariaDB sous Debian
8 règles d'or pour un bon déploiement de DNSSEC et DANE photo

8 règles d’or pour bien déployer DNSSEC et DANE

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 

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 

Après le déploiement de la key2, on supprime la key1 :

_25._tcp.mail.example.com. IN TLSA 3 0 1 

Lire la suite

Sommaire de la série Monter un serveur dédié de A à Z

  1. Serveur dédié : installation d’Apache, PHP, MySQL et Webmin
  2. Serveur dédié : créer la base de données MySQL et importer WordPress
  3. Serveur dédié : créer et activer un Virtual Host sous Apache
  4. Serveur dédié : changer les DNS du nom de domaine et le faire pointer vers le serveur
  5. Serveur dédié : sécurisation des services avec iptables et fail2ban
  6. Serveur dédié : sécurisation de la couche TCP/IP
  7. 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
  8. Serveur dédié : sécuriser Apache 2 avec ModSecurity
  9. Serveur dédié : CHMOD récursif sur des fichiers ou répertoires en ligne de commande
  10. Serveur dédié : installer APC comme système de cache et configurer Varnish comme reverse-proxy pour Apache pour améliorer les performances
  11. Serveur dédié : afficher la véritable IP derrière un reverse-proxy comme Varnish
  12. Serveur dédié : intégrer SSH à WordPress pour mettre à jour le core, les plugins et les thèmes
  13. Serveur dédié : installer la dernière version d’APC par SVN
  14. Serveur dédié : analyse des performances du serveur
  15. Serveur dédié : mettre à jour le noyau Debian de la Kimsufi
  16. Serveur dédié : sauvegarde automatique des fichiers avec Backup Manager sur le serveur de sauvegarde OVH
  17. Serveur dédié : configurer la limite mémoire pour PHP et Suhosin
  18. Bash : supprimer tous les fichiers et sous-répertoires d’un répertoire
  19. Serveur dédié : impossible de se connecter à un port distant
  20. Rsync: rapatrier les fichiers du serveur à la maison
  21. Bash : réparer les tables MySQL en cas de crash
  22. Serveur dédié : création d’une seedbox avec Transmission
  23. Serveur dédié : des paquets LAMP à jour sous Debian
  24. Serveur dédié : mise à jour vers Debian 7 Wheezy
  25. Serveur dédié : activer X11 forwarding pour SSH
  26. Serveur dédié : optimiser toutes les images JPG et PNG avec OptiPNG et JpegOptim
  27. Postfix : résoudre l’erreur “fatal: www-data(33): message file too big”
  28. Serveur dédié : mise en place de l’IPv6
  29. WordPress : accorder les bonnes permissions aux fichiers et dossiers avec chown et chmod
  30. WordPress : héberger les images sur un sous-domaine
  31. Serveur dédié : ajouter l’authentification SPF, Sender-ID et DKIM à Postfix et Bind9 avec opendkim
  32. Apache : lorsque le domaine seul (sans WWW) renvoie une erreur 403
  33. Serveur dédié : sécuriser Apache avec HTTPS (HTTP avec la couche TLS/SSL) en Perfect Forward Secrecy
  34. Serveur dédié : passer WordPress en HTTPS (TLS/SSL)
  35. Serveur dédié : configurer Webmin en TLS avec un certificat SSL
  36. Serveur dédié : configurer Transmission pour accéder au WebUI via TLS-SSL
  37. Serveur dédié : installer et configurer Varnish 4
  38. Serveur dédié : passage au mod FastCGI et PHP-FPM avec Apache MPM Worker
  39. Récupérer un serveur Kimsufi après un plantage de kernel avec le mode rescue OVH
  40. Serveur dédié : configurer Postfix et Courier pour utiliser TLS-SSL en Perfect Forward Secrecy
  41. Serveur dédié : retirer Varnish, devenu inutile avec HTTPS
  42. Serveur dédié : installer la dernière version d’OpenSSL sous Debian
  43. Serveur dédié : activer l’IP canonique du serveur sous Apache
  44. Serveur dédié : mise à jour vers PHP 5.6
  45. MySQL : convertir les tables MyISAM au format InnoDB
  46. Serveur dédié : optimiser toutes les images GIF avec GIFsicle
  47. Serveur dédié : migration de MySQL vers MariaDB
  48. BASH : lister, bloquer et débloquer des adresses IP avec iptables
  49. Serveur dédié : produire une meilleure réserve d’entropie avec haveged
  50. Serveur dédié : mettre en place DNSSEC pour sécuriser les DNS du domaine
  51. Serveur dédié : mise en place du protocole DANE
  52. 8 règles d’or pour bien déployer DNSSEC et DANE
  53. Serveur dédié : installer PHP7 FPM avec FastCGI sous Debian
  54. Serveur dédié : optimiser la couche TCP
  55. Fail2Ban: protéger Postfix contre les attaques DoS de types AUTH, UNKNOWN et EHLO
  56. Serveur dédié : mettre à jour Apache pour HTTP/2
  57. Serveur dédié : ajouter le domaine à la liste HSTS preload
  58. Serveur dédié : ajouter l’authentification DMARC à Postfix et BIND
  59. Serveur dédié : à la recherche de l’inode perdue ou comment résoudre le problème “no space left on device”
  60. Serveur dédié : installer NginX avec support HTTP2 et certificat SSL, PHP, MariaDB sous Debian
Serveur dédié : mise en place du protocole DANE photo 2

Serveur dédié : mise en place du protocole DANE

Aujourd’hui, je vous montre comment mettre en place le protocole DANE sur votre serveur.

En pré-requis, votre domaine doit:

  1. être servi en HTTPS avec un certificat TLS valide,
  2. être signé par DNSSEC.

Cela prend environ 20 minutes à configurer, auxquelles s’ajouteront quelques heures afin que la résolution DNS avec les changements soit complète.

DANE : l’authentification TLS sans autorité de certification

Serveur dédié : mise en place du protocole DANE photo 2

DANE (DNS-based Authentication of Named Entities) est un protocole qui permet aux certificats X.509 – généralement utilisés pour TLS – d’être liés au DNS en s’appuyant sur DNSSEC.

L’IETF a défini DANE dans la RFC 6698 comme un moyen d’authentifier des clients TLS et des serveurs sans passer par une autorité de certification (AC).

Cette démarche s’enregistre dans une logique de sécurisation des accès clients-serveurs pour d’une part sécuriser les requêtes DNS effectuées depuis les postes clients au travers des protocoles/mécanismes DNSSEC et TLS, et d’autre part mieux sécuriser les accès chiffrés des clients vers le serveurs.

Le chiffrement TLS est actuellement basé sur des certificats qui sont délivrés par des Autorités de Certification (AC ou Certificate Authority, CA en anglais).

Or, ces dernières années ont vu un certain nombre d’AC qui ont souffert de sérieux problèmes d’intrusions et de failles de sécurité, ce qui a permis la délivrance de certificats pour des sites très connus à des personnes qui ne détenaient pas ces domaines.

Faire confiance à un large nombre d’Autorités de Certification peut être un problème, étant donné que n’importe laquelle d’entre elles, si elle est compromise, pourrait délivrer un certificat pour n’importe quel nom de domaine.

Le protocole DANE permet à l’administrateur d’un nom de domaine de certifier les clés utilisées dans les clients ou serveurs TLS de ce domaine en les insérant au niveau du DNS.

DANE a donc besoin que les enregistrements DNS soient signés avec DNSSEC pour que son modèle de sécurité fonctionne.

De surcroit, DANE permet à l’adminstrateur du domaine de spécifier quelle autorité de certification est autorisée à délivrer des certificats pour une ressource particulière, ce qui résoud le problème des autorités de certification qui sont capables de délivrer des certificats pour n’importe quel nom de domaine.

Serveur dédié : mise en place du protocole DANE photo 3

Les enregistrements TLSA

DANE utilise des enregistrements TLSA, qui incluent l’empreinte du certificats X.509 qui protège un nom de domaine.

Nous devons tout d’abord générer cet enregistrement TLSA en nous basant sur le certificat installé sur notre serveur. Ensuite, cet enregistrement TLSA sera ajouté à notre zone DNS.

Lire la suite

Sommaire de la série Monter un serveur dédié de A à Z

  1. Serveur dédié : installation d’Apache, PHP, MySQL et Webmin
  2. Serveur dédié : créer la base de données MySQL et importer WordPress
  3. Serveur dédié : créer et activer un Virtual Host sous Apache
  4. Serveur dédié : changer les DNS du nom de domaine et le faire pointer vers le serveur
  5. Serveur dédié : sécurisation des services avec iptables et fail2ban
  6. Serveur dédié : sécurisation de la couche TCP/IP
  7. 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
  8. Serveur dédié : sécuriser Apache 2 avec ModSecurity
  9. Serveur dédié : CHMOD récursif sur des fichiers ou répertoires en ligne de commande
  10. Serveur dédié : installer APC comme système de cache et configurer Varnish comme reverse-proxy pour Apache pour améliorer les performances
  11. Serveur dédié : afficher la véritable IP derrière un reverse-proxy comme Varnish
  12. Serveur dédié : intégrer SSH à WordPress pour mettre à jour le core, les plugins et les thèmes
  13. Serveur dédié : installer la dernière version d’APC par SVN
  14. Serveur dédié : analyse des performances du serveur
  15. Serveur dédié : mettre à jour le noyau Debian de la Kimsufi
  16. Serveur dédié : sauvegarde automatique des fichiers avec Backup Manager sur le serveur de sauvegarde OVH
  17. Serveur dédié : configurer la limite mémoire pour PHP et Suhosin
  18. Bash : supprimer tous les fichiers et sous-répertoires d’un répertoire
  19. Serveur dédié : impossible de se connecter à un port distant
  20. Rsync: rapatrier les fichiers du serveur à la maison
  21. Bash : réparer les tables MySQL en cas de crash
  22. Serveur dédié : création d’une seedbox avec Transmission
  23. Serveur dédié : des paquets LAMP à jour sous Debian
  24. Serveur dédié : mise à jour vers Debian 7 Wheezy
  25. Serveur dédié : activer X11 forwarding pour SSH
  26. Serveur dédié : optimiser toutes les images JPG et PNG avec OptiPNG et JpegOptim
  27. Postfix : résoudre l’erreur “fatal: www-data(33): message file too big”
  28. Serveur dédié : mise en place de l’IPv6
  29. WordPress : accorder les bonnes permissions aux fichiers et dossiers avec chown et chmod
  30. WordPress : héberger les images sur un sous-domaine
  31. Serveur dédié : ajouter l’authentification SPF, Sender-ID et DKIM à Postfix et Bind9 avec opendkim
  32. Apache : lorsque le domaine seul (sans WWW) renvoie une erreur 403
  33. Serveur dédié : sécuriser Apache avec HTTPS (HTTP avec la couche TLS/SSL) en Perfect Forward Secrecy
  34. Serveur dédié : passer WordPress en HTTPS (TLS/SSL)
  35. Serveur dédié : configurer Webmin en TLS avec un certificat SSL
  36. Serveur dédié : configurer Transmission pour accéder au WebUI via TLS-SSL
  37. Serveur dédié : installer et configurer Varnish 4
  38. Serveur dédié : passage au mod FastCGI et PHP-FPM avec Apache MPM Worker
  39. Récupérer un serveur Kimsufi après un plantage de kernel avec le mode rescue OVH
  40. Serveur dédié : configurer Postfix et Courier pour utiliser TLS-SSL en Perfect Forward Secrecy
  41. Serveur dédié : retirer Varnish, devenu inutile avec HTTPS
  42. Serveur dédié : installer la dernière version d’OpenSSL sous Debian
  43. Serveur dédié : activer l’IP canonique du serveur sous Apache
  44. Serveur dédié : mise à jour vers PHP 5.6
  45. MySQL : convertir les tables MyISAM au format InnoDB
  46. Serveur dédié : optimiser toutes les images GIF avec GIFsicle
  47. Serveur dédié : migration de MySQL vers MariaDB
  48. BASH : lister, bloquer et débloquer des adresses IP avec iptables
  49. Serveur dédié : produire une meilleure réserve d’entropie avec haveged
  50. Serveur dédié : mettre en place DNSSEC pour sécuriser les DNS du domaine
  51. Serveur dédié : mise en place du protocole DANE
  52. 8 règles d’or pour bien déployer DNSSEC et DANE
  53. Serveur dédié : installer PHP7 FPM avec FastCGI sous Debian
  54. Serveur dédié : optimiser la couche TCP
  55. Fail2Ban: protéger Postfix contre les attaques DoS de types AUTH, UNKNOWN et EHLO
  56. Serveur dédié : mettre à jour Apache pour HTTP/2
  57. Serveur dédié : ajouter le domaine à la liste HSTS preload
  58. Serveur dédié : ajouter l’authentification DMARC à Postfix et BIND
  59. Serveur dédié : à la recherche de l’inode perdue ou comment résoudre le problème “no space left on device”
  60. Serveur dédié : installer NginX avec support HTTP2 et certificat SSL, PHP, MariaDB sous Debian
Serveur dédié : mettre en place DNSSEC pour sécuriser les DNS du domaine photo

Serveur dédié : mettre en place DNSSEC pour sécuriser les DNS du domaine

Aujourd’hui, nous allons mettre en place DNSSEC afin d’ajouter une couche de sécurité supplémentaire dans la gestion des DNS de notre domaine.

Principe de fonctionnement du DNS

Le DNS (Domain Name System) est un maillon clé du fonctionnement d’Internet car la quasi-totalité des services en ligne utilisent des noms de domaine à un moment ou à un autre.

Le DNS est organisé sous la forme d’une arborescence inversée, avec une « racine » dont dépendent les différentes « branches ».

Au premier niveau de l’arborescence se trouvent les « Top Level Domains » (TLD) ou domaines de premier niveau, comme les .fr, .com, .net etc.

Au second niveau, nous avons les noms de domaine « classiques » comme « skyminds.net ».

Fonctionnant comme une base de données distribuée sur des millions de machines, le DNS repose sur des interactions entre ces machines permettant d’identifier celle qui est la plus susceptible de pouvoir répondre à la requête d’un internaute.

Serveur dédié : mise en place de DNSSEC pour sécuriser les DNS d'un nom de domaine photo 2

Dans l’exemple ci-dessus, l’utilisateur veut se connecter au site http://www.wikipedia.fr. Il envoie sa requête via son navigateur. Celle-ci est reçue par un serveur dit « résolveur » qui a pour première mission d’identifier la machine sur laquelle est installé le nom de domaine wikipedia.fr.

Le résolveur s’adresse d’abord à la « racine » du DNS, qui lui indique quels sont les serveurs « faisant autorité » (c’est-à-dire compétents) pour .fr puisque le nom de domaine est en .fr.

Dans un second temps, les serveurs du .fr indiquent à leur tour au résolveur que le nom de domaine wikipedia.fr est hébergé sur tel serveur.

Celui-ci est alors en mesure d’indiquer au navigateur l’adresse IP du serveur web hébergeant les contenus du site web www.wikipedia.fr.

Ce schéma se vérifie quel que soit le site web auquel on souhaite accéder.

DNSSEC : authentifier l’origine et l’intégrité des données

DNSSEC, acronyme de Domain Name System Security Extensions, désigne un ensemble défini d’extensions de sécurité du protocole DNS, standardisé par l’IETF dans la RFC 4033.

Serveur dédié : mise en place de DNSSEC pour sécuriser les DNS d'un nom de domaine photo

DNSSEC signe cryptographiquement les enregistrements DNS et met cette signature dans le DNS. Ainsi, un client DNS méfiant peut récupérer la signature et, s’il possède la clé du serveur, vérifier que les données sont correctes.

Cela permet de s’assurer que les données obtenues par résolution DNS proviennent de la zone légitime du nom de domaine (authentification de l’origine des données) et que les données ne sont pas altérées lors du transfert (intégrité des données).

Ces extensions de sécurité font de DNSSEC une composante essentielle des communications Internet qui nécessitent un haut niveau de confiance dans l’infrastructure DNS.

DNSSEC utilise un mécanisme reposant sur une paire de clés ayant des rôles complémentaires. La première clé, privée, crée une signature par chiffrement; alors que la seconde clé, publique, vérifie les signatures par déchiffrement:

Serveur dédié : mise en place de DNSSEC pour sécuriser les DNS d'un nom de domaine photo 4

Contrairement à d’autres protocoles comme SSL/TLS, DNSSEC ne sécurise pas juste un canal de communication mais il protège les données et les enregistrements DNS, de bout en bout. Ainsi, il est efficace même lorsqu’un serveur intermédiaire trahit l’intégrité des données (DNS menteur).

Les attaques par empoisonnement de cache

DNSSEC répond spécifiquement aux attaques par empoisonnement de cache : le résolveur est alors “intoxiqué” pour qu’il considère le serveur « pirate » comme légitime, en lieu et place du serveur d’origine.

Cette opération permet notamment de capter et de détourner les requêtes vers un autre site web sans que les utilisateurs puissent s’en rendre compte : ils risquent alors de confier leurs données personnelles en se croyant sur le site légitime.

Serveur dédié : mise en place de DNSSEC pour sécuriser les DNS d'un nom de domaine photo 3

Le bon fonctionnement du DNS dépend donc de la fiabilité des données transmises à chaque étape. Les extensions de sécurité du DNS cherchent à répondre à cette contrainte en assurant l’intégrité des données transitant sur le réseau, notamment entre résolveurs et serveurs faisant autorité.

Pré-requis avant de configurer DNSSEC

Avant de commencer, voici quelques pré-requis essentiels :

1. votre domaine doit être correctement configuré auprès de votre registrar et hébergeur au niveau DNS,

2. votre serveur possède suffisamment d’entropie pour la génération des clés de sécurité,

3. vous avez fait une copie de sauvegarde : site, base de données, enregistrements DNS, configuration BIND.

Vérifiez que vous êtes bien prêt. Ce tutoriel prend à peu près 30 minutes à réaliser.

Lire la suite

Sommaire de la série Monter un serveur dédié de A à Z

  1. Serveur dédié : installation d’Apache, PHP, MySQL et Webmin
  2. Serveur dédié : créer la base de données MySQL et importer WordPress
  3. Serveur dédié : créer et activer un Virtual Host sous Apache
  4. Serveur dédié : changer les DNS du nom de domaine et le faire pointer vers le serveur
  5. Serveur dédié : sécurisation des services avec iptables et fail2ban
  6. Serveur dédié : sécurisation de la couche TCP/IP
  7. 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
  8. Serveur dédié : sécuriser Apache 2 avec ModSecurity
  9. Serveur dédié : CHMOD récursif sur des fichiers ou répertoires en ligne de commande
  10. Serveur dédié : installer APC comme système de cache et configurer Varnish comme reverse-proxy pour Apache pour améliorer les performances
  11. Serveur dédié : afficher la véritable IP derrière un reverse-proxy comme Varnish
  12. Serveur dédié : intégrer SSH à WordPress pour mettre à jour le core, les plugins et les thèmes
  13. Serveur dédié : installer la dernière version d’APC par SVN
  14. Serveur dédié : analyse des performances du serveur
  15. Serveur dédié : mettre à jour le noyau Debian de la Kimsufi
  16. Serveur dédié : sauvegarde automatique des fichiers avec Backup Manager sur le serveur de sauvegarde OVH
  17. Serveur dédié : configurer la limite mémoire pour PHP et Suhosin
  18. Bash : supprimer tous les fichiers et sous-répertoires d’un répertoire
  19. Serveur dédié : impossible de se connecter à un port distant
  20. Rsync: rapatrier les fichiers du serveur à la maison
  21. Bash : réparer les tables MySQL en cas de crash
  22. Serveur dédié : création d’une seedbox avec Transmission
  23. Serveur dédié : des paquets LAMP à jour sous Debian
  24. Serveur dédié : mise à jour vers Debian 7 Wheezy
  25. Serveur dédié : activer X11 forwarding pour SSH
  26. Serveur dédié : optimiser toutes les images JPG et PNG avec OptiPNG et JpegOptim
  27. Postfix : résoudre l’erreur “fatal: www-data(33): message file too big”
  28. Serveur dédié : mise en place de l’IPv6
  29. WordPress : accorder les bonnes permissions aux fichiers et dossiers avec chown et chmod
  30. WordPress : héberger les images sur un sous-domaine
  31. Serveur dédié : ajouter l’authentification SPF, Sender-ID et DKIM à Postfix et Bind9 avec opendkim
  32. Apache : lorsque le domaine seul (sans WWW) renvoie une erreur 403
  33. Serveur dédié : sécuriser Apache avec HTTPS (HTTP avec la couche TLS/SSL) en Perfect Forward Secrecy
  34. Serveur dédié : passer WordPress en HTTPS (TLS/SSL)
  35. Serveur dédié : configurer Webmin en TLS avec un certificat SSL
  36. Serveur dédié : configurer Transmission pour accéder au WebUI via TLS-SSL
  37. Serveur dédié : installer et configurer Varnish 4
  38. Serveur dédié : passage au mod FastCGI et PHP-FPM avec Apache MPM Worker
  39. Récupérer un serveur Kimsufi après un plantage de kernel avec le mode rescue OVH
  40. Serveur dédié : configurer Postfix et Courier pour utiliser TLS-SSL en Perfect Forward Secrecy
  41. Serveur dédié : retirer Varnish, devenu inutile avec HTTPS
  42. Serveur dédié : installer la dernière version d’OpenSSL sous Debian
  43. Serveur dédié : activer l’IP canonique du serveur sous Apache
  44. Serveur dédié : mise à jour vers PHP 5.6
  45. MySQL : convertir les tables MyISAM au format InnoDB
  46. Serveur dédié : optimiser toutes les images GIF avec GIFsicle
  47. Serveur dédié : migration de MySQL vers MariaDB
  48. BASH : lister, bloquer et débloquer des adresses IP avec iptables
  49. Serveur dédié : produire une meilleure réserve d’entropie avec haveged
  50. Serveur dédié : mettre en place DNSSEC pour sécuriser les DNS du domaine
  51. Serveur dédié : mise en place du protocole DANE
  52. 8 règles d’or pour bien déployer DNSSEC et DANE
  53. Serveur dédié : installer PHP7 FPM avec FastCGI sous Debian
  54. Serveur dédié : optimiser la couche TCP
  55. Fail2Ban: protéger Postfix contre les attaques DoS de types AUTH, UNKNOWN et EHLO
  56. Serveur dédié : mettre à jour Apache pour HTTP/2
  57. Serveur dédié : ajouter le domaine à la liste HSTS preload
  58. Serveur dédié : ajouter l’authentification DMARC à Postfix et BIND
  59. Serveur dédié : à la recherche de l’inode perdue ou comment résoudre le problème “no space left on device”
  60. Serveur dédié : installer NginX avec support HTTP2 et certificat SSL, PHP, MariaDB sous Debian
Serveur dédié : générer de l'entropie additionnelle avec Haveged photo

Serveur dédié : produire une meilleure réserve d’entropie avec haveged

Sur notre serveur dédié, nous avons parfois besoin de générer des nombres aléatoires avec une forte entropie, par exemple lorsque l’on génère une clé SSH, un certificat SSL/TLS ou une clé pour DNSSEC.

Aujourd’hui, je vous propose donc un article un petit peu plus théorique, qui nous permettra d’améliorer la qualité des données aléatoires et l’entropie générale de notre serveur.

On commence donc par la théorie et on enchaîne sur la partie technique.

L’entropie ou le caractère aléatoire sous Linux

Le chiffrement est basé sur deux facteurs principaux : les nombres premiers et les nombres aléatoires.

Sous Linux, les nombres aléatoires sont générés par le pseudo random number generator (PRNG) qui génère des données aléatoires depuis les interruptions matérielles (clavier, souris, accès disque, accès réseau…) et depuis d’autres sources provenant du système d’exploitation.

Serveur dédié : générer de l'entropie additionnelle avec Haveged photo 1

Une interruption matérielle (en anglais Interrupt ReQuest ou IRQ) est une interruption déclenchée par un périphérique d’entrée-sortie d’un microprocesseur ou d’un microcontrôleur.

Ce caractère aléatoire ou aléa, que l’on désigne sous le terme entropie, est utilisé principalement pour le chiffrement comme SSL/TLS mais peut aussi avoir plein d’utilisations pratiques (génération de mots de passe, de clés, de chaînes de caractères aléatoires…).

Lire la suite

Sommaire de la série Monter un serveur dédié de A à Z

  1. Serveur dédié : installation d’Apache, PHP, MySQL et Webmin
  2. Serveur dédié : créer la base de données MySQL et importer WordPress
  3. Serveur dédié : créer et activer un Virtual Host sous Apache
  4. Serveur dédié : changer les DNS du nom de domaine et le faire pointer vers le serveur
  5. Serveur dédié : sécurisation des services avec iptables et fail2ban
  6. Serveur dédié : sécurisation de la couche TCP/IP
  7. 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
  8. Serveur dédié : sécuriser Apache 2 avec ModSecurity
  9. Serveur dédié : CHMOD récursif sur des fichiers ou répertoires en ligne de commande
  10. Serveur dédié : installer APC comme système de cache et configurer Varnish comme reverse-proxy pour Apache pour améliorer les performances
  11. Serveur dédié : afficher la véritable IP derrière un reverse-proxy comme Varnish
  12. Serveur dédié : intégrer SSH à WordPress pour mettre à jour le core, les plugins et les thèmes
  13. Serveur dédié : installer la dernière version d’APC par SVN
  14. Serveur dédié : analyse des performances du serveur
  15. Serveur dédié : mettre à jour le noyau Debian de la Kimsufi
  16. Serveur dédié : sauvegarde automatique des fichiers avec Backup Manager sur le serveur de sauvegarde OVH
  17. Serveur dédié : configurer la limite mémoire pour PHP et Suhosin
  18. Bash : supprimer tous les fichiers et sous-répertoires d’un répertoire
  19. Serveur dédié : impossible de se connecter à un port distant
  20. Rsync: rapatrier les fichiers du serveur à la maison
  21. Bash : réparer les tables MySQL en cas de crash
  22. Serveur dédié : création d’une seedbox avec Transmission
  23. Serveur dédié : des paquets LAMP à jour sous Debian
  24. Serveur dédié : mise à jour vers Debian 7 Wheezy
  25. Serveur dédié : activer X11 forwarding pour SSH
  26. Serveur dédié : optimiser toutes les images JPG et PNG avec OptiPNG et JpegOptim
  27. Postfix : résoudre l’erreur “fatal: www-data(33): message file too big”
  28. Serveur dédié : mise en place de l’IPv6
  29. WordPress : accorder les bonnes permissions aux fichiers et dossiers avec chown et chmod
  30. WordPress : héberger les images sur un sous-domaine
  31. Serveur dédié : ajouter l’authentification SPF, Sender-ID et DKIM à Postfix et Bind9 avec opendkim
  32. Apache : lorsque le domaine seul (sans WWW) renvoie une erreur 403
  33. Serveur dédié : sécuriser Apache avec HTTPS (HTTP avec la couche TLS/SSL) en Perfect Forward Secrecy
  34. Serveur dédié : passer WordPress en HTTPS (TLS/SSL)
  35. Serveur dédié : configurer Webmin en TLS avec un certificat SSL
  36. Serveur dédié : configurer Transmission pour accéder au WebUI via TLS-SSL
  37. Serveur dédié : installer et configurer Varnish 4
  38. Serveur dédié : passage au mod FastCGI et PHP-FPM avec Apache MPM Worker
  39. Récupérer un serveur Kimsufi après un plantage de kernel avec le mode rescue OVH
  40. Serveur dédié : configurer Postfix et Courier pour utiliser TLS-SSL en Perfect Forward Secrecy
  41. Serveur dédié : retirer Varnish, devenu inutile avec HTTPS
  42. Serveur dédié : installer la dernière version d’OpenSSL sous Debian
  43. Serveur dédié : activer l’IP canonique du serveur sous Apache
  44. Serveur dédié : mise à jour vers PHP 5.6
  45. MySQL : convertir les tables MyISAM au format InnoDB
  46. Serveur dédié : optimiser toutes les images GIF avec GIFsicle
  47. Serveur dédié : migration de MySQL vers MariaDB
  48. BASH : lister, bloquer et débloquer des adresses IP avec iptables
  49. Serveur dédié : produire une meilleure réserve d’entropie avec haveged
  50. Serveur dédié : mettre en place DNSSEC pour sécuriser les DNS du domaine
  51. Serveur dédié : mise en place du protocole DANE
  52. 8 règles d’or pour bien déployer DNSSEC et DANE
  53. Serveur dédié : installer PHP7 FPM avec FastCGI sous Debian
  54. Serveur dédié : optimiser la couche TCP
  55. Fail2Ban: protéger Postfix contre les attaques DoS de types AUTH, UNKNOWN et EHLO
  56. Serveur dédié : mettre à jour Apache pour HTTP/2
  57. Serveur dédié : ajouter le domaine à la liste HSTS preload
  58. Serveur dédié : ajouter l’authentification DMARC à Postfix et BIND
  59. Serveur dédié : à la recherche de l’inode perdue ou comment résoudre le problème “no space left on device”
  60. Serveur dédié : installer NginX avec support HTTP2 et certificat SSL, PHP, MariaDB sous Debian
Serveur dédié : installer la dernière version d'OpenSSL sous Debian photo

Bash : lister et redémarrer tous les services qui utilisent libssl après une mise à jour d’OpenSSL

Lorsque l’on met à jour OpenSSL, tous les services qui utilisent les librairies SSL et qui sont chargés en mémoire ne rechargent pas les librairies (dont libssl) qui viennent d’être mises à jour.

Idéalement, il faudrait rebooter le système mais lorsqu’il s’agit d’un serveur, ce n’est pas toujours possible. Si les services ne sont pas redémarrés (restart) ou rechargés (reload) après une mise à jour, ils seront toujours vulnérables aux problèmes de sécurité que corrige la nouvelle version.

Voici donc comment détecter les services qui utilisent les librairies d’OpenSSL afin de les redémarrer et éviter de rebooter la machine.

Lister les services qui utilisent libssl

Vérifiez que votre système possède la commande lsof. Elle devrait normalement être prise en charge par votre gestionnaire de paquets.

Pour lister les services qui utilisent OpenSSL, il suffit de vérifier lesquels utilisent le paquet libssl en les classant par ordre alphabétique et en supprimant les doublons:

lsof | grep libssl | awk '{print $1}' | sort | uniq

Résultat:

apache2
fail2ban-
opendkim
php5-fpm
tlsmgr

Il ne vous reste plus qu’à redémarrer les services présents dans cette liste qui font appel à OpenSSL.

Lister les services qui utilisent une ancienne version de libssl

Si vous avez mis à jour OpenSSL mais que vous n’avez pas redémarré votre serveur, il est possible que certains services utilisent toujours une ancienne librairie non-patchée d’OpenSSL.

Lire la suite

boite-mail-pole-emploi-navigateur-perime

Pole Emploi utilise des navigateurs obsolètes

Aujourd’hui, j’ai eu le plaisir de recevoir un mail de la part de quelqu’un qui travaille chez Pole Emploi. Rien qui sorte de l’ordinaire jusque là.

Enfin, jusqu’à ce que j’arrive à la fin du message et que je remarque ceci :

boite-mail-pole-emploi-navigateur-perime

FireFox 17, dont la date de sortie remonte au 20 novembre 2012, soit presque 3 ans… ce n’est pas comme s’il y avait des attaques et des problèmes de sécurité entre temps (Poodle, Heartbleed, la fin de SSL…).

C’est légérement inquiétant, surtout que la mise à jour vers la dernière version de FireFox ne représente aucune complication réelle depuis la version 17.

Bref, “drôle” de politique de sécurité chez Pole Emploi ! J’espère que leurs serveurs sont mieux sécurisés que leurs postes clients.

Postfix : résoudre l'erreur SASL

Postfix : résoudre l’erreur “Untrusted TLS connection established to Gmail”

postfix-logo

En vérifiant les logs de mon serveur mail, je me suis aperçu que, malgré mon certificat, la connexion du serveur à un serveur sortant n’était pas entièrement chiffrée.

Voici comment remédier à ce problème.

Postfix : “untrusted connection SMTP”

Concrètement, voici la transcription du log d’une connexion SMTP dite “untrusted connection SMTP” :

postfix/cleanup: message-id=<9@mail.example.com>
opendkim: DKIM-Signature field added (s=mail, d=example.com)
postfix/qmgr: from=<user@example.com>, size=483, nrcpt=1 (queue active)
postfix/smtp: Untrusted TLS connection established to gmail-smtp-in.l.google.com[2a00:1450:4013:c01::1a]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
postfix/smtp: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[2a00:1450:4013:c01::1a]:25, delay=1.5, delays=0.12/0.06/0.55/0.73, dsn=2.0.0, status=sent (250 2.0.0 OK 1430771763 z16si1523612wjr.190 - gsmtp)
postfix/qmgr: removed</user@gmail.com></user@example.com>

Comme on peut le constater, notre connexion TLS n’est pas chiffrée de bout en bout :

Untrusted TLS connection established to gmail-smtp-in.l.google.com[2a00:1450:4013:c01::1a]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)

Solution : ajouter la directive smtp_tls_CAfile

J’ai pour habitude de mettre les mêmes valeurs pour les directives smtp_* et smtpd_* mais dans ce cas précis, il faut modifier la valeur de la directive smtp_tls_CAfile.

On édite le fichier de configuration de Postfix :

nano /etc/postfix/main.cf

On modifie smtp_tls_CAfile pour pointer vers le fichier /etc/ssl/certs/ca-certificates.crt:

###
# Trusted TLS connection to gmail-smtp
# by Matt 
# https://www.skyminds.net
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
###

et on redémarre Postfix :

service postfix restart

Trusted TLS connection established

Après un envoi de test, voici ce que nous donnent les logs:

postfix/cleanup: message-id=<a@mail.example.com>
opendkim: DKIM-Signature field added (s=mail, d=example.com)
postfix/qmgr: from=<user@example.com>, size=483, nrcpt=1 (queue active)
postfix/smtp: Trusted TLS connection established to gmail-smtp-in.l.google.com[74.125.136.27]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
postfix/smtp: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[74.125.136.27]:25, delay=1.1, delays=0.12/0.07/0.31/0.58, dsn=2.0.0, status=sent (250 2.0.0 OK 1430772064 jt5si24487408wjc.48 - gsmtp)
postfix/qmgr: removed</user@gmail.com></user@example.com></a@mail.example.com>

Et voilà, connexion vers les serveurs SMTP chiffrée et validée comme trusted!