Le HTTPS se démocratise peu à peu et, pour plusieurs raisons, j’ai décidé de migrer l’intégralité de mes sites. Je vais vous expliquer aujourd’hui comment effectuer une transition simple de HTTP vers HTTPS en utilisant le service Let’s Encrypt.

Si tu en as rien à secouer des raisons qui m’ont poussé à migrer vers HTTPS, je t’invite à passer directement à la « Présentation de Let’s Encrypt » ou carrément au tutoriel si t’es complètement YOLO.

1. Pourquoi passer à HTTPS

a. Un meilleur référencement

Cela fait un moment que Google crie haut et fort qu’il favorise dans son classement les sites qui utilisent HTTPS au lieu de HTTP. Pour ma part, j’ai envie d’avoir un meilleur référencement car cela me permettra probablement de toucher plus de visiteurs et d’attirer l’attention sur le blog (et éventuellement mes autres sites / blogs).

De plus, début septembre, le géant de Mountain View franchissait un nouveau cap en annonçant qu’à partir de Janvier 2017, l’affichage de l’URL des sites en HTTP allait être modifié au sein de son navigateur Chrome.

Google indiquera bientôt qu'un site n'est pas sécurisé

Bon OK, cela ne concerne pas toutes les pages mais seulement celles qui comportent une saisie de mot de passe ou d’informations bancaires (dans un premier temps). Quoi qu’il en soit, sur une page en HTTP, l’URL sera précédée de « Non sécurisé », une indication très explicite pour l’internaute… Je me dis que cette indication lancée aux utilisateurs sera peut être étendue à TOUTES les pages HTTP le jour où Google-le-tout-puissant l’aura décidé et je préfère anticiper ça que de me retrouver à devoir faire une migration « en urgence ».

 

b. Des informations sécurisées

C’est la deuxième raison et qui est surement plus importante que celle énoncée juste avant : je veux que les informations que j’envoie et que je reçois du serveur soient chiffrées. Cela diminue le risque d’interception des informations qui transitent (mots de passes entre autres) par quelqu’un de mal intentionné.

Vous me direz « oui mais c’est toujours possible… ». Certes, mais au moins ce sera déjà un peu plus compliqué de récupérer une information exploitable tout de suite comme ça l’était jusqu’à présent. De plus, HTTPS permet de garantir au client (toi, mon petit visiteur inconnu) que les informations qui transitent entre le serveur et ton PC n’ont pas été altérées ! Je le fais donc pour moi, mais aussi un peu pour mes visiteurs.

Passons maintenant dans le vif du sujet.

 

2. Let’s Encrypt : qu’est ce que c’est ?

Let’s Encrypt est une autorité de certification (CA), libre, automatisée et gérée pour le bénéfice du public. C’est un service fourni par le Internet Security Group (ISRG).

Let’s Encrypt délivre aux utilisateurs les certificats numériques dont ils ont besoin afin de leur permettre d’implémenter HTTPS (SSL / TLS) pour leurs sites web, gratuitement, de la manière la plus simple possible, pour créer un Web plus sécurisé avec un haut degré de confientialité.

Les principes clés derrière Let’s Encrypt sont:

    Gratuit : Let’s Encrypt est entièrement gratuit ! (mais vous pouvez leur faire un don pour soutenir l’initiative)
    Automatique : Vous pouvez obtenir et renouveler vos certificats automatiquement.
    Sécurisé : Let’s Encrypt se base sur TLS 1.2 avec chiffrement en 2048 bits.
    Transparent : Tous les certificats délivrés ou révoqués seront enregistrées publiquement et disponibles pour quiconque souhaite les inspecter.
    Ouvert : Le protocole de délivrance et de renouvellement automatique sera publié en tant que norme ouverte que les autres pourront adopter.
    Indépendant : Tout comme les protocoles Internet sous-jacents, Let’s Encrypt est un effort conjoint au profit de la communauté, au-delà du contrôle de toute une organisation.

Et pour terminer, Let’s Encrypt est soutenu par quelques grands noms du monde informatique :

Let's Encrypt : de nombreux soutiens

Mais tout n’est pas rose puisque vos certificats générés depuis Let’s Encrypt ont une durée de vie « courte » : 90 jours. Le gros avantage, c’est que vous pouvez automatiser leur renouvellement sans problème… Suivez le guide !

 

3. Migrer ses sites web de HTTP vers HTTPS avec Let’s Encrypt

Le tutoriel suivant va vous expliquer comment mettre en place un certificat SSL Let’s Encrypt sur un de vos sites internet pour le passer en HTTPS. Les pré-requis sont les suivants :

– Système d’exploitation Ubuntu 16.04 configuré et opérationnel (vous pouvez également adapter le tutoriel à votre distribution)

– Serveur web Apache configuré avec un virtualhost

La première étape est d’installer le client qui permet de récupérer le certificat depuis l’autorité de certification et par la suite de renouveler vos certificats. Il en existe plusieurs mais Let’s Encrypt recommande l’utilisation de Certbot : https://certbot.eff.org/

On commence donc par installer le package :

sudo apt-get install python-letsencrypt-apache 

Ensuite, une fois que le package est installé vous pouvez créer votre premier certificat. A savoir que vous pouvez créer un certificat pour un seul domaine à la fois et ça se passe avec cette commande :

sudo letsencrypt --apache -d nom_de_domaine.com

Si vous avez des sous-domaines à passer en HTTPS également, vous pouvez taper cette commande à la place :

sudo letsencrypt --apache -d nom_de_domaine.com -d www.nom_de_domaine.com -d sd2.nom_de_domaine.com

Il est recommandé de mettre d’abord le domaine principal suivi par autant de sous-domaines que vous en avez. Certbot va vous demander une adresse e-mail puis si vous voulez que l’accès HTTPS soit obligatoire (Secure) ou optionnel (Easy) :

Let's Encrypt : HTTPS ou HTTP+HTTPS

Pour ma part, j’ai choisi « Secure » pour tous mes sites et c’est passé nickel ! Dès que vous voulez accéder à votre site en HTTP, vous êtes automatiquement redirigé vers le HTTPS et pourquoi laisser un accès HTTP quand on peut faire du full HTTPS ? Cette redirection est mise en place par Certbot directement dans le fichier vhost de votre domaine qui contient désormais ces lignes en plus :

RewriteEngine on
RewriteCond %{SERVER_NAME} =nom_de_domaine.com [OR]
RewriteCond %{SERVER_NAME} =www.nom_de_domaine.com
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,QSA,R=permanent]

Si tout fonctionne et que vous souhaitez tester votre nouveau domaine en HTTPS, vous pouvez le faire à l’adresse suivante : https://www.ssllabs.com/ssltest/analyze.html?d=nom_de_domaine.com (remplacer nom_de_domaine.com par votre nom de domaine personnel bien entendu…) 

Let's Encrypt : Test du site en HTTPS

 

Si par hasard la commande lestencrypt pour générer le certificat ne fonctionne pas, jetez un coup d’oeil du coté de votre pare-feu, les ports sont peut être fermés.

 

4. Automatisation du renouvellement des certificats

Pour renouveler les certificats que vous avez généré, il faut taper la commande suivante :

sudo letsencrypt renew

Vous devriez voir apparaitre la liste des certificats que vous avez déjà généré avec un message indiquant qu’un renouvellement est inutile.

Comme c’est une opération à répéter régulièrement et que l’on risque d’oublier de le faire 9 fois sur 10, nous allons mettre en place un cron :

sudo crontab -e

Et y ajouter la ligne suivante :

0 2 5 * * /usr/bin/letsencrypt renew >> /var/log/le-renew.log

Ainsi, le 5 de chaque mois à 2h00 du matin votre serveur vérifiera tout seul comme un grand si vos certificats doivent être renouvelés et s’en chargera lui même !

Passer vos sites en HTTPS devrait donc être maintenant un jeu d’enfant !

Sponsornot : Zéro collaboration

Read More

Comme vous le savez surement, j’héberge moi même mes sites internet sur un serveur dédié loué chez Online.net. En début de semaine, j’ai constaté des ralentissements importants sur l’ensemble de mes sites, ainsi que des problèmes de synchronisation MySQL entre les dis sites et leurs bases de données respectives. Je me connecte donc en SSH sur mon dédié et balance donc une petite commande « top » pour afficher les processus qui tournent.

A ma grande surprise, la liste n’est composée que d’une succession de services Apache2 qui vont et viennent et surchargent ainsi la totalité ou presque des ressources de mon serveur. La charge processeur culmine autour de 99% d’utilisation en constant, alors que d’ordinaire je suis plutôt entre 5 et 10%…

Mon premier réflexe : redémarrer le service Apache2 :

sudo service apache2 restart

Je patiente quelques secondes le temps que le service remonte et refait un « top ». Même constat, mon serveur est toujours à fond… Du coup, je file jeter un petit coup d’oeil aux logs et là, surprise :

mon-user@mon-serveur:~$ cd /var/log/apache2/
mon-user@mon-serveur:/var/log/apache2$ ll
total 786200
drwxr-x--- 2 root adm 4096 sept. 21 06:25 ./
drwxr-xr-x 14 root root 4096 sept. 24 06:25 ../

-rw-r----- 1 root adm 163781250 sept. 24 20:00 access.log
-rw-r----- 1 root adm 245624497 sept. 21 06:25 access.log.1
-rw-r----- 1 root adm 6488434 juil. 20 06:24 access.log.10.gz
-rw-r----- 1 root adm 6781312 juil. 13 06:25 access.log.11.gz
-rw-r----- 1 root adm 5014221 juil. 6 06:25 access.log.12.gz
-rw-r----- 1 root adm 6811034 juin 29 06:25 access.log.13.gz
-rw-r----- 1 root adm 6491920 juin 22 06:25 access.log.14.gz
-rw-r----- 1 root adm 8740091 juin 15 06:25 access.log.15.gz
-rw-r----- 1 root adm 13286015 juin 8 06:25 access.log.16.gz

-rw-r----- 1 root adm 7343230 sept. 24 20:00 error.log
-rw-r----- 1 root adm 13729544 sept. 21 06:25 error.log.1
-rw-r----- 1 root adm 602268 juil. 20 06:25 error.log.10.gz
-rw-r----- 1 root adm 569964 juil. 13 06:25 error.log.11.gz
-rw-r----- 1 root adm 483897 juil. 6 06:25 error.log.12.gz
-rw-r----- 1 root adm 334804 juin 29 06:25 error.log.13.gz
-rw-r----- 1 root adm 457884 juin 22 06:25 error.log.14.gz
-rw-r----- 1 root adm 853488 juin 15 06:25 error.log.15.gz
-rw-r----- 1 root adm 780921 juin 8 06:25 error.log.16.gz

-rw-r----- 1 root adm 4917534 sept. 24 20:00 other_vhosts_access.log
-rw-r----- 1 root adm 9301167 sept. 21 06:25 other_vhosts_access.log.1
-rw-r----- 1 root adm 66098 juil. 20 06:25 other_vhosts_access.log.10.gz
-rw-r----- 1 root adm 89567 juil. 13 06:25 other_vhosts_access.log.11.gz
-rw-r----- 1 root adm 52761 juil. 6 06:25 other_vhosts_access.log.12.gz
-rw-r----- 1 root adm 63852 juin 29 06:25 other_vhosts_access.log.13.gz
-rw-r----- 1 root adm 60675 juin 22 06:25 other_vhosts_access.log.14.gz
-rw-r----- 1 root adm 87682 juin 15 06:25 other_vhosts_access.log.15.gz
-rw-r----- 1 root adm 204479 juin 8 06:25 other_vhosts_access.log.16.gz

Je vous laisse comparer la taille des archives de log de septembre, avec celle des autres mois que j’ai volontairement laissé. Vous pouvez constater que pour septembre la quantité de logs s’est envolée et cela m’a mis la puce à l’oreille.

J’affiche le contenu du fichier access.log afin de voir qu’est ce qui accède à mon serveur, et parmi les quelques requêtes légitimes (je ne peux malheureusement pas me vanter de comptabiliser des millions de visites / mois ;)) je détecte 4 IPs qui ne requêtent pas de façon « normale » :

mon-user@monserveur:/var/log/apache2$ cat access.log | grep ip-suspecte
ip-suspecte - - [22/Sep/2014:19:39:21 +0200] "POST /xmlrpc.php HTTP/1.0" 200 544 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
ip-suspecte - - [22/Sep/2014:19:39:21 +0200] "POST /xmlrpc.php HTTP/1.0" 200 544 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
ip-suspecte - - [22/Sep/2014:19:39:22 +0200] "POST /xmlrpc.php HTTP/1.0" 200 544 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
ip-suspecte - - [22/Sep/2014:19:39:22 +0200] "POST /xmlrpc.php HTTP/1.0" 200 544 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
ip-suspecte - - [22/Sep/2014:19:39:22 +0200] "POST /xmlrpc.php HTTP/1.0" 200 544 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
ip-suspecte - - [22/Sep/2014:19:39:22 +0200] "POST /xmlrpc.php HTTP/1.0" 200 544 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
ip-suspecte - - [22/Sep/2014:19:39:22 +0200] "POST /xmlrpc.php HTTP/1.0" 200 544 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
ip-suspecte - - [22/Sep/2014:19:39:22 +0200] "POST /xmlrpc.php HTTP/1.0" 200 544 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
ip-suspecte - - [22/Sep/2014:19:39:22 +0200] "POST /xmlrpc.php HTTP/1.0" 200 544 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
ip-suspecte - - [22/Sep/2014:19:39:22 +0200] "POST /xmlrpc.php HTTP/1.0" 200 544 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
ip-suspecte - - [22/Sep/2014:19:39:23 +0200] "POST /xmlrpc.php HTTP/1.0" 200 544 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
ip-suspecte - - [22/Sep/2014:19:39:23 +0200] "POST /xmlrpc.php HTTP/1.0" 200 544 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
ip-suspecte - - [22/Sep/2014:19:39:23 +0200] "POST /xmlrpc.php HTTP/1.0" 200 544 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"

Au total : 200000 requêtes en 24h de cette simple IP, et il y en avait 3 autres, certes beaucoup moins virulentes mais pour le serveur s’en était trop.

On m’a demandé pourquoi je n’avais pas installé Fail2Ban. Et bien si, Fail2Ban était pourtant bel est bien installé ! Le problème, c’est que lorsqu’on épluche les logs on voit que l’attaquant fait un POST sur un fichier bien précis d’une installation WordPress : xmlrpc.php. La réponse du serveur à cette requête est 200 « Requête traitée avec succès », il n’y a donc aucune erreur de renvoyer… L’attaque passe ainsi entre les mailles de Fail2Ban dans sa configuration de base…

Une recherche sur Internet m’a permis d’identifier cette attaque comme étant une tentative d’exploit d’une vulnérabilité connue de WordPress. Comme il s’agit aussi d’une tentative d’injection SQL, j’ai jeté un oeil aux logs concernés :  

mon-user@mon-serveur:/var/log/mysql$ ll
total 36
drwxr-s--- 2 mysql adm 4096 sept. 25 06:25 ./
drwxr-xr-x 14 root root 4096 sept. 25 06:25 ../
-rw-r----- 1 mysql adm 0 sept. 25 06:25 error.log
-rw-r----- 1 mysql adm 20 sept. 24 06:25 error.log.1.gz
-rw-r----- 1 mysql adm 20 sept. 23 06:26 error.log.2.gz
-rw-r----- 1 mysql adm 1059 sept. 22 14:15 error.log.3.gz
-rw-r----- 1 mysql adm 20 sept. 21 06:25 error.log.4.gz
-rw-r----- 1 mysql adm 20 sept. 20 06:25 error.log.5.gz
-rw-r----- 1 mysql adm 20 sept. 19 06:25 error.log.6.gz
-rw-r----- 1 mysql adm 20 sept. 18 06:25 error.log.7.gz

Pour la journée du 22 septembre, la taille des logs a été multipliée par 50 environ, preuve qu’il s’agit bien d’une tentative d’exploit de la faille sur la fonctionnalité Pingback de WordPress. Je vous indiquerai dans un prochain tutoriel comment configurer Fail2Ban pour qu’il prenne en compte cette attaque sur vos installations WordPress.

Après un WhoIs sur les différentes IPs, 2 provenaient de serveurs hébergés chez Online et 2 de chez Elcatel. Ayant toujours été très bien renseigné par l’assistance du premier, je les ai contacté pour leur faire part du problème et ils m’ont guidé pour déclencher un abuse. La hotline Online ? Toujours au top (je vous invite à lire mon article sur mon expérience avec eux) !

Dans la foulée, pour stopper cette surcharge assez handicapante avant le traitement du signalement, j’ai créé 4 règles dans le firewall du serveur :

mon-user@mon-serveur:/~$ sudo ufw deny from ip-suspecte-1
mon-user@mon-serveur:/~$ sudo ufw deny from ip-suspecte-2
mon-user@mon-serveur:/~$ sudo ufw deny from ip-suspecte-3
mon-user@mon-serveur:/~$ sudo ufw deny from ip-suspecte-4
mon-user@mon-serveur:/~$ sudo ufw disable
mon-user@mon-serveur:/~$ sudo ufw enable

La charge serveur est instantanément retombée à son niveau d’origine et les sites internet et autres services hébergés sont redevenus fluides.

Moralité : superviser son serveur est indispensable pour traiter au plus vite ce genre d’attaque…

Sponsornot : Zéro collaboration

Read More

Un petit tutoriel (et un pense bête pour moi ! o/) pour montrer/rappeler comment rediriger les visiteurs de http://adressedusite.tld vers http://www.adressedusite.tld !

 

Sur un serveur web tournant sous Apache, avec le mod_rewrite installé et activé (ce qui est le cas de base en principe) il suffit de créer un fichier nommé .htaccess à la racine du site ou de le modifier si il existe déjà, et d’y ajouter le code suivant :

RewriteEngine On 

RewriteCond %{HTTP_HOST} ^adressedusite.tld$ 

RewriteRule ^(.*) http://www.adressedusite.tld/$1  [QSA,L,R=301]

On enregistre le fichier et on fait un petit test en chargeant : http://adressedusite.tld. Si le fichier .htaccess est correct, la page sera automatiquement redirigée vers http://www.adressedusite.tld.

Sponsornot : Zéro collaboration

Read More