Tag

SSL

Browsing
PHP: résoudre l'erreur "file_get_contents(): SSL operation failed with code 1" photo

J'ai récemment joué avec l'API de YouTube pour pouvoir récupérer diverses informations sur les vidéos afin d'ajouter au site les données structurées idoines.

Il se trouve qu'en local, lorsque l'on utilise file_get_contents(), on peut obtenir une erreur de ce type lorsque le serveur n'est pas configuré avec le bundle de certificats OpenSSL:

Warning: file_get_contents(): SSL operation failed with code 1. OpenSSL Error messages: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed in ...php on line 2

Warning: file_get_contents(): Failed to enable crypto in ...php on line 2

Warning: file_get_contents(https://........f=json): failed to open stream: operation failed in ...php on line 2

Si cela vous arrive, plusieurs solutions s'offrent à vous.

Méthode 1: configuration de PHP côté machine/serveur

1. Vérifiez qu'OpenSSL est bien installé sur votre machine (il devrait l'être sur le serveur!).

2. Ajoutez cette ligne à la configuration de PHP, dans votre php.ini:

openssl.cafile=/usr/local/etc/openssl/cert.pem

3. Redémarrez le service PHP.

Méthode 2 : une fonction qui utilise curl au lieu de file_get_contents()

Au lieu de m'embêter à configurer OpenSSL ou à toucher à PHP dans un conteneur docker (Local), il se trouve que l'on peut réécrire la fonction file_get_contents() avec une fonction maison qui utilise curl.

Voici la fonction en question:

/*
Custom CURL function that mimicks file_get_contents()
@returns false if no content is fetched
Matt Biscay (https://mattbiscay.com)
*/
function sky_curl_get_file_contents( $URL ){
	$c = curl_init();
	curl_setopt( $c, CURLOPT_RETURNTRANSFER, 1 );
	curl_setopt( $c, CURLOPT_URL, $URL );
	$contents = curl_exec( $c );
	curl_close( $c );
	if( $contents ) :
		return $contents;
	else:
		return false;
	endif;
}

La fonction retourne false si la requête échoue, ce qui est très utile pour éviter de faire des appels à des valeurs d'un tableau qui n'existe pas. On peut alors réfléchir à un autre moyen de peupler les champs de données structurées (mais c'est un sujet à aborder une autre fois).

Dernièrement, je suis tombé sur un os lors du renouvelement d'un certificat Let's Encrypt d'un site qui tourne sur un serveur avec Plesk.

Il se trouve que le renouvellement était tout simplement impossible à cause d'une erreur 400 Bad Request:

Attempting to renew cert (example.com) from /etc/letsencrypt/renewal/example.com.conf produced an unexpected error: Failed authorization procedure. www.example.com (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://www.example.com/.well-known/acme-challenge/2VQAX5eA_dSyl1RB5MjfcHr9YinF8T7nw3Z6OxU5Zu4: "<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>400 Bad Request</title>\n</head><body>\n<h1>Bad Request</h1", example.com (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://example.com/.well-known/acme-challenge/e4Y1e16A6e3czI1106dJiz6BMqsKjJxz21XaqvrHLZQ: "<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>400 Bad Request</title>\n</head><body>\n<h1>Bad Request</h1". Skipping.

Après avoir passé pas mal de temps à auditer le site, les .htaccess, la configuration du serveur... il se trouve que la solution est très simple - mais encore faut-il le savoir car cela n'est marqué nulle part!

Sous Plesk:

1. rendez-vous dans le workspace du site en question.

2. cliquez sur SSL/TLS certificates.

3. décochez la case Redirect from http to https:

Relancez maintenant le renouvellement du certificat Let's Encrypt. Il devrait maintenant se renouveler sans aucun problème.

Aujourd'hui, nous allons voir comment héberger un nouveau domaine sur le serveur, en simplifiant au maximum les procédures.

Serveur dédié : transférer et héberger un nouveau domaine sur votre serveur photo

Le nom de domaine sera réservé chez OVH et le site hébergé sur notre serveur Debian. Nous allons servir le site avec NginX en HTTPS grâce à un certificat SSL fourni gratuitement par Let's Encrypt.

Enfin, on utilisera le serveur email existant et on ajoutera la configuration OpenDKIM pour signer et authentifier tous les emails sortants du domaine.

Nom de domaine

J'achète mes noms de domaine chez OVH parce que le prix est relativement raisonnable (comparé à mon ancien registrar).

Au moment de la commande, faites pointer le nouveau domaine vers les DNS du serveur.

Si votre serveur n'est pas chez OVH, il suffit d'aller dans Domaines > Serveurs DNS et de renseigner le DNS primaire et secondaire de votre serveur.

Configuration DNS dans BIND

Une fois le domaine commandé, si vous vous rendez dans le Manager OVH, vous vous rendrez compte que le bouton DNS est en rouge : c'est normal puisqu'il nous faut paramétrer notre nouveau domaine dans BIND, notre serveur de noms.

On édite la configuration de BIND :

nano /etc/bind/named.conf.local

et on lui indique que nous créons une nouvelle zone :

zone "example.com" {
        type master;
        file "/etc/bind/example.com.hosts";
        allow-query { any; };
};

On crée maintenant notre fichier de zone:

nano /etc/bind/example.com.hosts
$ttl 84600
$ORIGIN example.com.

@       IN      SOA     XXXXXX.kimsufi.com. root.example.net. (
                        2018012801
                        14400
                        3600
                        604800
                        84600 )

; NAMESERVERS
 IN     NS      XXXXXX.kimsufi.com.
 IN     NS      ns.kimsufi.com.

example.com.   IN      A       XXX.XXX.XXX.XXX
example.com.   IN      AAAA    4001:41d0:1:4462::1
example.com.   IN      MX      10 mail.example.net.

www.example.com.       IN      A        XXX.XXX.XXX.XXX
www.example.com.       IN    AAAA    4001:41d0:1:4462::1
www       IN A          XXX.XXX.XXX.XXX

Ps: example.net est le domaine principal du serveur.

Pous vérifions la configuration BIND:

named-checkconf -z

et nous redémarrons BIND pour prendre en compte nos changements et activer notre nouveau fichier de zone:

service bind9 restart

Vous pouvez vérifier votre configuration DNS à l'aide de l'outil ZoneMaster.

Configuration du bloc serveur sous NginX

On commence par créer le répertoire qui va accueillir les fichiers du site et on lui attribue les bons droits:

mkdir -p /home/example/public_html
chown -R www-data:www-data /home/example/public_html
chmod 755 /home/example/public_html

On crée également un fichier index.php à la racine du site pour éviter une erreur 403 plus tard lors de la génération du certificat SSL :

echo "" >> /home/example/public_html/index.php

On crée maintenant le répertoire de cache du site, toujours avec les bons droits:

mkdir -p /home/nginx-cache/example
chown -R www-data:www-data /home/nginx-cache/example
chmod 755 /home/nginx-cache/example

Voici le server block de départ, en HTTP simple :

server {
       listen         80;
       listen    [::]:80;
       server_name    example.com www.example.com;
       #return         301 https://$server_name$request_uri;
        root /home/example/public_html;
        index index.php index.html;
}

On active le site :

ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/

On teste la configuration de NginX et on redémarre le service:

nginx -t
service nginx restart

On crée maintenant le certificat SSL avec Let's Encrypt :

certbot certonly --webroot -w /home/example/public_html -d example.com -d www.example.com

Aujourd'hui, je vous montre comment j'ai mis en place un certificat ECDSA avec Let's Encrypt, que j'utilise depuis l'année dernière.

Serveur dédié : créer un certificat ECDSA avec Let's Encrypt photo

Let's Encrypt a annoncé il y a quelques mois qu'il sera possible au courant de l'année 2018 de créer des certificats ECDSA, pour plus de sécurité et de rapidité.

L'algorithme ECDSA

L'algorithme ECDSA (abbréviation d'Elliptic Curve Digital Signature Algorithm) a été proposé pour la première fois par Scott Vanstone en 1992.

Les signatures basées sur l'algorithme d'ECS, l'ancêtre de ECDSA, présente plusieurs avantages majeurs par rapport aux algorithmes RSA : leur taille est plus réduite et ils sont créés bien plus rapidement.

La vérification basée sur les algorithmes ECC est extrêmement rapide également.

Les avantages d'utiliser ECDSA par rapport à RSA

L'utilisation d'ECDSA pour les signatures numériques présente d'importants avantages, dont notamment:

  • un niveau de sécurité élevé,
  • pas de problèmes avec la performance d'applications,
  • un processus rapide de signature et de vérification (40% plus rapide que RSA),
  • adapté à la montée en puissance de la sécurité des applications,
  • support pour les pré-requis modernes de l'industrie

Une sécurité et une rapidité accrues donc, avec un usage de données réduit. Parfait.

Création d'un certificat ECDSA avec Let's Encrypt

1. On crée les nouveaux répertoires pour notre certificat ECDSA:

mkdir -p /etc/letsencrypt/live-ecdsa/example.com/letmp
mkdir -p /etc/letsencrypt/live-ecdsa/example.com/backup
cd /etc/letsencrypt/live-ecdsa/example.com

2. On crée une clé privée avec l'algorithme secp384r1:

openssl ecparam -genkey -name secp384r1 > privkey-p384.pem

3. On crée un Certificate Signing Request (CSR):

openssl req -new -sha256 -key privkey-p384.pem -subj "/CN=example.com" -reqexts SAN -config <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\nsubjectAltName=DNS:example.com,DNS:www.example.com,DNS:mail.example.com,DNS:static.example.com")) -outform der -out csr-p384.der

4. On demande la création du certificat chez Let's Encrypt:

cd letmp
certbot certonly -a webroot --webroot-path /home/public_html -d example.com -d www.example.com -d mail.example.com -d static.example.com --csr /etc/letsencrypt/live-ecdsa/example.com/csr-p384.der --renew-by-default --agree-tos --cert-path /etc/letsencrypt/live-ecdsa/example.com/cert_ecdsa.pem --fullchain-path /etc/letsencrypt/live-ecdsa/example.com/fullchain_ecdsa.pem --chain-path /etc/letsencrypt/live-ecdsa/example.com/chain_ecdsa.pem

5. Il reste à éditer la configuration de votre serveur de fichier. Sous NginX:

nano /etc/nginx/sites-available/example.com

ajoutez-y le nouveau certificat:

    # Let's Encrypt : ECDSA CERT
    ssl_certificate /etc/letsencrypt/live-ecdsa/example.com/fullchain_ecdsa.pem;
    ssl_certificate_key /etc/letsencrypt/live-ecdsa/example.com/privkey-p384.pem;

et on redémarre NginX:

service nginx restart

Voilà, vous venez de mettre en place votre certificat ECDSA. Voyons maintenant comment cela se passe pour la mise à jour.

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. J'ai planté le serveur... ou comment 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é : ajout de mod_spdy pour accélérer la connexion TLS-SSL sous Apache
  43. Serveur dédié : installer la dernière version d'OpenSSL sous Debian
  44. Serveur dédié : activer l'IP canonique du serveur sous Apache
  45. Serveur dédié : mise à jour vers PHP 5.6
  46. MySQL : convertir les tables MyISAM au format InnoDB
  47. Serveur dédié : optimiser toutes les images GIF avec GIFsicle
  48. Serveur dédié : migration de MySQL vers MariaDB
  49. BASH : lister, bloquer et débloquer des adresses IP avec iptables
  50. Serveur dédié : produire une meilleure réserve d'entropie avec haveged
  51. Serveur dédié : mettre en place DNSSEC pour sécuriser les DNS du domaine
  52. Serveur dédié : mise en place du protocole DANE
  53. 8 règles d'or pour bien déployer DNSSEC et DANE
  54. Serveur dédié : installer PHP7 FPM avec FastCGI sous Debian
  55. Serveur dédié : réduire les connexions TIME_WAIT des sockets et optimiser TCP
  56. Fail2Ban: protéger Postfix contre les attaques DoS de types AUTH, UNKNOWN et EHLO
  57. Serveur dédié : mettre à jour Apache et configurer le mod_http2 pour HTTP/2
  58. Serveur dédié : ajouter le domaine à la liste HSTS preload
  59. Serveur dédié : ajouter l'authentification DMARC à Postfix et BIND
  60. Serveur dédié : à la recherche de l'inode perdue ou comment résoudre le problème "no space left on device"
  61. Serveur dédié : installer NginX avec support HTTP2 et certificat SSL, PHP, MariaDB sous Debian

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 2017, 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 SSL et TLSv1 pour ne garder que TLS v1.1 et TLS v1.2.

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é.

Bonne mise à jour.

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.

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

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.

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. J'ai planté le serveur... ou comment 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é : ajout de mod_spdy pour accélérer la connexion TLS-SSL sous Apache
  43. Serveur dédié : installer la dernière version d'OpenSSL sous Debian
  44. Serveur dédié : activer l'IP canonique du serveur sous Apache
  45. Serveur dédié : mise à jour vers PHP 5.6
  46. MySQL : convertir les tables MyISAM au format InnoDB
  47. Serveur dédié : optimiser toutes les images GIF avec GIFsicle
  48. Serveur dédié : migration de MySQL vers MariaDB
  49. BASH : lister, bloquer et débloquer des adresses IP avec iptables
  50. Serveur dédié : produire une meilleure réserve d'entropie avec haveged
  51. Serveur dédié : mettre en place DNSSEC pour sécuriser les DNS du domaine
  52. Serveur dédié : mise en place du protocole DANE
  53. 8 règles d'or pour bien déployer DNSSEC et DANE
  54. Serveur dédié : installer PHP7 FPM avec FastCGI sous Debian
  55. Serveur dédié : réduire les connexions TIME_WAIT des sockets et optimiser TCP
  56. Fail2Ban: protéger Postfix contre les attaques DoS de types AUTH, UNKNOWN et EHLO
  57. Serveur dédié : mettre à jour Apache et configurer le mod_http2 pour HTTP/2
  58. Serveur dédié : ajouter le domaine à la liste HSTS preload
  59. Serveur dédié : ajouter l'authentification DMARC à Postfix et BIND
  60. Serveur dédié : à la recherche de l'inode perdue ou comment résoudre le problème "no space left on device"
  61. Serveur dédié : installer NginX avec support HTTP2 et certificat SSL, PHP, MariaDB sous Debian

Apache : résoudre l'erreur "421 Misdirected Request" photo

Après la mise à jour d'Apache et HTTP/2, il est apparu un nouveau type d'erreur : l'erreur 421 Misdirected Request.

Erreur 421 : erreur de configuration mod_ssl entre Virtual Hosts

Ce type d'erreur arrive lorsque:

  1. HTTP/2 est activé,
  2. les paramètres SSL de plusieurs Virtual Hosts diffèrent du serveur responsable du handshake SSL/TLS.

En analysant le changelog d'Apache 2.4.18, je me suis rendu compte que si les paramètres SSL et notamment la liste des ciphers utilisables ne sont pas équivalentes entre les différents Virtual Hosts, alors l'erreur 421 est déclenchée.

Solution : harmoniser la configuration mod_ssl

La solution est donc toute simple, il suffit de comparer la configuration mod_ssl des Virtual Hosts et l'harmoniser de manière à lisser les différences. Je vous recommande un outil comme Meld pour comparer les différences entre vos fichiers.

Meld est disponible dans les dépôts de base, vous pouvez l'installer sur votre machine de dév avec un simple:

apt-get install meld

Le domain sharding ou servir les ressources statiques sur un sous-domaine

Sur le site, cela est dû à la mise en place du domain sharding que j'avais mis en place il y a quelques années pour charger plusieurs fichiers ressources en parallèle et accélérer les temps de chargement.

HTTP/2 promet beaucoup de choses et apparemment le domain sharding serait maintenant devenu inutile. J'attends un peu de voir comment vont évoluer les choses avant de changer toute ma configuration et éditer tous mes liens.

C'est sur toutes les lèvres : 2015 aura vu l'arrivée de PHP7 et de la révision du protocole HTTP qui passe à la version 2, en remplacement du mod_spdy de Google.

Tout cela promet pas mal de gains de performance donc il est très tentant de le vérifier par nous-mêmes.

Serveur dédié : mettre à jour Apache et configurer le mod_h2 pour HTTP/2 photo

HTTP/2 : une évolution du protocole HTTP

Avec HTTP/1.1, la vie des développeurs n'était pas simple. L'optimisation d'un site revenait à plusieurs techniques qui tournaient toutes autour de l'idée de minimiser le nombre de requêtes HTTP vers un serveur d'origine.

Un navigateur ne peut ouvrir qu'un nombre limité de connexions TCP simultanées vers une origine et le chargement des ces ressources via chacune de ces connexions est un processus en série : la réponse de chaque ressource doit être retournée avant que la réponse de la ressource suivante ne soit envoyée. C'est ce qu'on appelle le head-of-line blocking.

HTTP/2 promet donc une gain de perfomance d'environ 30%, sans avoir à gérer ni minification ni concaténation dans le processus de création et déploiement des pages.

Plus besoin (normalement!) d'optimiser les connexions TCP ou les requêtes HTTP avec la création de sprites, le chargement des ressources directement dans le corps des pages, la concatenation ou la création de sous-domaines pour charger les ressources en parallèle (domain sharding) pour contourner les limitations d'HTTP 1.1.

Optimiser pour HTTP/2

Avec HTTP/2, il faut maintenant concentrer les efforts d'optimisation sur les scénarios de cache du site. La nouvelle règle est d'utiliser de petites ressources, granulaires, qui peuvent être mises en cache indépendamment et transferrées en parallèle.

Serveur dédié : mettre à jour Apache et configurer le mod_http2 pour HTTP/2 photo

Ce changement est possible grâce aux nouvelles fonctions de multiplexing et de compression des entêtes d'HTTP/2.

Le multiplexing permet à plusieurs requêtes de partager une connexion TCP unique, ce qui permet le chargement de plusieurs ressources en parallèle, sans le délai dû à la création de connexions multiples. Cela élimine le problème d'head-of-line blocking que l'on rencontre avec HTTP/1.1.

La compression des entêtes réduit encore davantage la pénalité lors du chargement de plusieurs ressources (requêtes HTTP multiples) puisque l'overhead de chaque requête est plus petit que leur équivalent non-compressé en HTTP/1.1.

HTTP/2 offre aussi la hiérarchisation des flux (stream prioritization) qui permet aux navigateurs de spécifier dans quel ordre ils souhaitent recevoir les ressources, ainsi que le server push qui laisse le serveur envoyer des ressources supplémentaires par anticipation, alors que le navigateur ne sait pas encore qu'il en aura besoin.

Cela implique donc pas mal de changements dans les manières et l'état d'esprit d'optimisation par rapport à HTTP/1.1.

Configuration initiale du serveur

Mon serveur dédié tourne sur la dernière version stable de Debian, c'est-à-dire sous Jessie à l'heure où j'écris ces lignes, qui ne dispose que d'Apache 2.4.10. Or le module http2 ne fonctionne qu'à partir d'Apache 2.4.17.

Il va donc falloir mettre Apache à jour ! Nous allons temporairement basculer sur les dépôts sid le temps de mettre à jour Apache et OpenSSL.

[box type="warning"]Note : l'opération suivante n'est pas sans danger. Nous allons installer des paquets sid (still in development) donc instables en lieu et place de nos paquets d'origine, obsolètes mais testés.[/box]

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. J'ai planté le serveur... ou comment 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é : ajout de mod_spdy pour accélérer la connexion TLS-SSL sous Apache
  43. Serveur dédié : installer la dernière version d'OpenSSL sous Debian
  44. Serveur dédié : activer l'IP canonique du serveur sous Apache
  45. Serveur dédié : mise à jour vers PHP 5.6
  46. MySQL : convertir les tables MyISAM au format InnoDB
  47. Serveur dédié : optimiser toutes les images GIF avec GIFsicle
  48. Serveur dédié : migration de MySQL vers MariaDB
  49. BASH : lister, bloquer et débloquer des adresses IP avec iptables
  50. Serveur dédié : produire une meilleure réserve d'entropie avec haveged
  51. Serveur dédié : mettre en place DNSSEC pour sécuriser les DNS du domaine
  52. Serveur dédié : mise en place du protocole DANE
  53. 8 règles d'or pour bien déployer DNSSEC et DANE
  54. Serveur dédié : installer PHP7 FPM avec FastCGI sous Debian
  55. Serveur dédié : réduire les connexions TIME_WAIT des sockets et optimiser TCP
  56. Fail2Ban: protéger Postfix contre les attaques DoS de types AUTH, UNKNOWN et EHLO
  57. Serveur dédié : mettre à jour Apache et configurer le mod_http2 pour HTTP/2
  58. Serveur dédié : ajouter le domaine à la liste HSTS preload
  59. Serveur dédié : ajouter l'authentification DMARC à Postfix et BIND
  60. Serveur dédié : à la recherche de l'inode perdue ou comment résoudre le problème "no space left on device"
  61. Serveur dédié : installer NginX avec support HTTP2 et certificat SSL, PHP, MariaDB sous Debian

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 http://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.

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. J'ai planté le serveur... ou comment 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é : ajout de mod_spdy pour accélérer la connexion TLS-SSL sous Apache
  43. Serveur dédié : installer la dernière version d'OpenSSL sous Debian
  44. Serveur dédié : activer l'IP canonique du serveur sous Apache
  45. Serveur dédié : mise à jour vers PHP 5.6
  46. MySQL : convertir les tables MyISAM au format InnoDB
  47. Serveur dédié : optimiser toutes les images GIF avec GIFsicle
  48. Serveur dédié : migration de MySQL vers MariaDB
  49. BASH : lister, bloquer et débloquer des adresses IP avec iptables
  50. Serveur dédié : produire une meilleure réserve d'entropie avec haveged
  51. Serveur dédié : mettre en place DNSSEC pour sécuriser les DNS du domaine
  52. Serveur dédié : mise en place du protocole DANE
  53. 8 règles d'or pour bien déployer DNSSEC et DANE
  54. Serveur dédié : installer PHP7 FPM avec FastCGI sous Debian
  55. Serveur dédié : réduire les connexions TIME_WAIT des sockets et optimiser TCP
  56. Fail2Ban: protéger Postfix contre les attaques DoS de types AUTH, UNKNOWN et EHLO
  57. Serveur dédié : mettre à jour Apache et configurer le mod_http2 pour HTTP/2
  58. Serveur dédié : ajouter le domaine à la liste HSTS preload
  59. Serveur dédié : ajouter l'authentification DMARC à Postfix et BIND
  60. Serveur dédié : à la recherche de l'inode perdue ou comment résoudre le problème "no space left on device"
  61. Serveur dédié : installer NginX avec support HTTP2 et certificat SSL, PHP, MariaDB sous Debian

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.

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

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...).

Par exemple, prenons un jeu de dés virtuels : l'entropie permettrait d'améliorer la qualité de l'aléa pour ne pas tomber toujours sur les mêmes nombres.

Serveur dédié : améliorer la qualité du chiffrement en générant une réserve d'entropie additionnelle avec haveged photo

Il existe deux grands outils aléatoires sous Linux : /dev/random et /dev/urandom.

/dev/random est un fichier spécial qui sert de générateur de nombres aléatoires (ou éventuellement de générateur de nombres pseudo-aléatoires). Il utilise comme source d'aléa les interruptions matérielles recueillies auprès de pilotes de périphériques et d'autres sources, et les traite à l'aide de fonctions de hachage cryptographiques. La lecture du fichier est bloquée quand l'activité du système (entropie) n'est pas suffisante, quitte à provoquer un temps de latence.

/dev/urandom fonctionne de façon analogue en dehors du fait que la lecture n'est pas bloquante : il continue de produire des données "aléatoires" même lorsque la réserve d'entropie se vide ; l'aléa produit est donc moins aléatoire. En résulte une qualité médiocre des données générées, qui pourraient être des redites des données précédentes. Apparaissent ainsi d'importants risques de sécurité sur un serveur de production, surtout s'il nécessite des fonctions cryptographiques.

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

Les dangers d'une entropie trop faible pour les services d'un serveur

Prenons un serveur qui utilise des services chiffrés avec SSL/TLS comme un serveur HTTPS, un serveur de mails entrants/sortants, SSH, SFTP, un client bittorrent...

Si l'un de ces services a besoin de générer de l'aléa alors que toute la réserve d'entropie a été épuisée, il devra faire une pause pour attendre que cette réserve se reconstitue, ce qui peut provoquer un temps de latence excessif dans les applications.

Pire, la plupart des applications récentes définissent leur propre graine aléatoire (random seed) au moment de l'installation ou recourent à /dev/urandom pour éviter le blocage et risquent de pâtir de la mauvaise qualité des données aléatoires générées.

La graine aléatoire (random seed) est un nombre utilisé pour l'initialisation d'un générateur de nombres pseudo-aléatoires. Toute la suite de nombres produite par le générateur découle de la valeur de la graine de façon déterministe.

Le choix d'une graine aléatoire est une étape cruciale en cryptologie et en sécurité informatique puisqu'elle est souvent générée à partir des composants matériels du système ou bien d'un matériel cryptographique spécifique.

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

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. J'ai planté le serveur... ou comment 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é : ajout de mod_spdy pour accélérer la connexion TLS-SSL sous Apache
  43. Serveur dédié : installer la dernière version d'OpenSSL sous Debian
  44. Serveur dédié : activer l'IP canonique du serveur sous Apache
  45. Serveur dédié : mise à jour vers PHP 5.6
  46. MySQL : convertir les tables MyISAM au format InnoDB
  47. Serveur dédié : optimiser toutes les images GIF avec GIFsicle
  48. Serveur dédié : migration de MySQL vers MariaDB
  49. BASH : lister, bloquer et débloquer des adresses IP avec iptables
  50. Serveur dédié : produire une meilleure réserve d'entropie avec haveged
  51. Serveur dédié : mettre en place DNSSEC pour sécuriser les DNS du domaine
  52. Serveur dédié : mise en place du protocole DANE
  53. 8 règles d'or pour bien déployer DNSSEC et DANE
  54. Serveur dédié : installer PHP7 FPM avec FastCGI sous Debian
  55. Serveur dédié : réduire les connexions TIME_WAIT des sockets et optimiser TCP
  56. Fail2Ban: protéger Postfix contre les attaques DoS de types AUTH, UNKNOWN et EHLO
  57. Serveur dédié : mettre à jour Apache et configurer le mod_http2 pour HTTP/2
  58. Serveur dédié : ajouter le domaine à la liste HSTS preload
  59. Serveur dédié : ajouter l'authentification DMARC à Postfix et BIND
  60. Serveur dédié : à la recherche de l'inode perdue ou comment résoudre le problème "no space left on device"
  61. Serveur dédié : installer NginX avec support HTTP2 et certificat SSL, PHP, MariaDB sous Debian

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.

openssl-grey

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.

Aujourd'hui, on va s'atteler à sécuriser le serveur de mail, géré par Postfix et Courier, pour utiliser notre certificat SSL et en ajoutant le Perfect Forward Secrecy.

Ce tutoriel part du principe que votre serveur tourne sous Debian et que vous avez suivi le tutoriel précédent sur Postfix avec gestion d'utilisateurs virtuels, c'est-à-dire que le serveur de mail doit déjà être opérationnel.

email-security

Vérification du fonctionnement du serveur de mail

On commence par vérifier que le serveur est capable d'envoyer des mails avec :

echo "test" | mail -s testsubject user@example.com

Si le mail est reçu, passez à l'étape suivante.

Configuration du certificat SSL

Nous allons concaténer la clé et le certificat pour Courier :

cd /etc/ssl
cat skyminds.net.key  skyminds_net.crt >> courier-key-crt-dh.pem

et on va y inclure un échange de clés Diffie-Hellman :

openssl dhparam 2048 >> courier-key-crt-dh.pem

On ajoute une autre clé DH en 2048 bits:

openssl gendh -out /etc/postfix/dh_2048.pem -2 2048

L'échange de clés Diffie-Hellman - du nom de ses auteurs Whitfield Diffie et Martin Hellman - est une méthode par laquelle deux personnes nommées conventionnellement Alice et Bob peuvent se mettre d'accord sur un nombre (qu'ils peuvent utiliser comme clé pour chiffrer la conversation suivante) sans qu'une troisième personne appelée Ève puisse découvrir le nombre, même en ayant écouté tous leurs échanges. Cela sécurise un peu plus l'échange.

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. J'ai planté le serveur... ou comment 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é : ajout de mod_spdy pour accélérer la connexion TLS-SSL sous Apache
  43. Serveur dédié : installer la dernière version d'OpenSSL sous Debian
  44. Serveur dédié : activer l'IP canonique du serveur sous Apache
  45. Serveur dédié : mise à jour vers PHP 5.6
  46. MySQL : convertir les tables MyISAM au format InnoDB
  47. Serveur dédié : optimiser toutes les images GIF avec GIFsicle
  48. Serveur dédié : migration de MySQL vers MariaDB
  49. BASH : lister, bloquer et débloquer des adresses IP avec iptables
  50. Serveur dédié : produire une meilleure réserve d'entropie avec haveged
  51. Serveur dédié : mettre en place DNSSEC pour sécuriser les DNS du domaine
  52. Serveur dédié : mise en place du protocole DANE
  53. 8 règles d'or pour bien déployer DNSSEC et DANE
  54. Serveur dédié : installer PHP7 FPM avec FastCGI sous Debian
  55. Serveur dédié : réduire les connexions TIME_WAIT des sockets et optimiser TCP
  56. Fail2Ban: protéger Postfix contre les attaques DoS de types AUTH, UNKNOWN et EHLO
  57. Serveur dédié : mettre à jour Apache et configurer le mod_http2 pour HTTP/2
  58. Serveur dédié : ajouter le domaine à la liste HSTS preload
  59. Serveur dédié : ajouter l'authentification DMARC à Postfix et BIND
  60. Serveur dédié : à la recherche de l'inode perdue ou comment résoudre le problème "no space left on device"
  61. Serveur dédié : installer NginX avec support HTTP2 et certificat SSL, PHP, MariaDB sous Debian

Rapport de faute d’orthographe

Le texte suivant sera envoyé à nos rédacteurs :