Cours sur les serveurs web par Luc Didry

Luc Didry, qui se présent lui-même comme un Administrateur Systèmes, Perliste fou, Debianeux convaincu, Libriste radical, est également connu sous son pseudonyme de Framasky et pour ses activités d' Administrateur systèmes au sein de l'association Framasoft.

Il est (a été ?) également enseignant pour la formation de la Licence Professionnelle Administration de Systèmes, Réseaux et Applications à base de Logiciels Libres (asrall.fr, adresse qui redirige vers le programme de la formation.

Ses cours (avec quelques exercices en bas de page) sont mis à disposition sur son site https://luc.frama.io/cours-asrall/serveurs_web/index.html. Au sommaire :
- Introduction
- Autres élément de configuration
- Les hôtes virtuels & les journaux
- Redirections, contrôles d'accès & chiffrement
- CGI & cache
- Mesures de performance

Des tutoriels sur Apache et Nginx et leurs configurations, j'en ai lu un certain nombre et ce cours est probablement le meilleur que j'ai lu. A la sortie, on a une très bonne référence pour la compréhension des fichiers de configuration d'Apache et Nginx, avec une comparaison entre eux, leurs spécificités et caractéristiques, avec les différentes options et leurs rôles respectifs.

Pour tout comprendre du contenu des fichiers de configuration d'Apache et Nginx, dans le détail, mais de façon claire, précise et pédagogue, je ne peux donc que recommander de lire ce cours. J'ai compilé tout ça dans un document LibreOffice, il y en a pour 70 pages... De quoi s'occuper quelques heures. Et un grand MERCI à Luc aka Framasky pour ce super boulot et sa mise à disposition.

Yunohost – Goaccess – Rapport HTML depuis des logs d’un serveur web

Présentation de GoAcess

GoAccess présente des statistiques en lisant les logs de votre serveur Web, non pas en exécutant du code côté utilisateur.

Site : https://goaccess.io/

GoAccess fonctionne en ligne de commande et présente par défaut ses résultats dans la console, en temps réel. Une série de panels (que l'on peut étendre individuellement) présentent les différents types de données : nombres de visiteurs uniques, URL non trouvées, OS, etc. Classique. Il est également possible de générer une − plutôt jolie − page html

Le site GoAccess : analyse simple et efficace des logs d'un serveur Web - https://hal-9000.fr/?s11R3Q a fait un tutoriel qui montre qu'il est assez simple d'installer et d'utiliser GoAccess.

Autres tutoriels présentant des astuces complémentaires :
- Goaccess : un autre outil de Web Analytics par Denis Szalkowski
- GoAccess – Des logs web en temps réel et en cli

GoAccess répond à mon besoin

J'ai étudié différents systèmes permettant de générer des rapports à partir de logs, je connais un peu ELK (ElasticSearch, LogStash, Kibana), mais ça reste très complexe et un peu usine à gaz pour mon besoin qui est de tout simplement superviser / avoir des rapports issus des logs de mon serveur Yunohost. Donc GoAcess correspond bien à mon besoin.

Par défaut, Yunohost conserve les logs du serveur Nginx un certain temps (il faudra que je regarde en détail la configuration de logrotate), cela convient

Automatisons un peu tout ça...

L'objectif est d'avoir des rapports réguliers en HTML. Pour ça, j'ai mis en place une tâche CROn qui va faire une concatènation des différents fichiers de logs et générer un seul et même rapport HTML via GoAccess qui contient donc une visualisation graphique de l'ensemble des données issues de ces logs. Je peux ensuite m'envoyer le rapport par mail, le récupérer, le mettre à disposition dans un espace dédié du serveur web...

#/bin/bash

# On fait le cat dans /tmp pour que ce soit effacer ensuite
cat /var/log/nginx/blog.genma.fr-access.log* > /tmp/blog.genma.fr-access.full.log
echo "Goacess - Lancement de la generation des rapports HTML"
goaccess --log-format=COMBINED -f /tmp/blog.genma.fr-access.full.log -a -o BlogFullReport.html
# Le fichier BlogFullReport.html contient un beau rapport HTML complet généré par Goaccess.
echo "Goacess - Fini"

Yunohost ?

Yunohost propose la création de coquille vide pour des applications, via les Multi Custom Webapp, une version forkée des Custom Webapp qui permettent d'en créer plusieurs.

J'installe l'application en indiquant comme paramétrage :
- Nom de l'application : GoAccess
- Adresse et chemin : moninstanceyunohost.fr et /goacess comme sous répertoire
- Utilisateur : genma

Ca mouline (il y a la création et modification de la configuration nginx qui se fait) et ensuite j'ai bien une tuile "GoAccess" dans la liste des applications et un dossier "/var/www/webapp_genma/GoAccess" dans lequel j'ai par défaut le fichier "index.html".

Il ne reste qu'à ajouter au script ci-dessus une ligne du type

mv /tmp/BlogFullReport.html /var/www/webapp_genma/GoAccess

et depuis un navigateur web, en étant connecté à Yunohost d'aller sur
https://moninstanceyunohost.org/goacess/BlogFullReport.html

pour avoir le beau rapport généré par GoAccess !

Aller plus loin ?

Il suffit de faire un script un peu plus avancé, de le mettre en tâche planifiée (cron) et de créer par exemple un fichier index.html qui contiendra par exemple une série de liens :
- BlogFullReport_Jour1.html
- BlogFullReport_Jour2.html
- BlogFullReport_Jour3.html
- InstanceFullReport_Jour1.html
- InstanceFullReport_Jour2.html
- InstanceFullReport_Jour3.html

Ici les fichers InstanceFullReport_JourX.html étant généré par une ligne faisant appel à GoAcess mais pour un cumul de logs de fichiers Nginx pour l'instance (cumul des fichiers de log nginx pour monistanceyunohost.fr).

Debian – Rester sur une version ; passer de stable en stable

Yunohost n'est pas compatible avec Stretch

Debian Stretch est sortie en version stable au début de l'été. Pour le détail, voir la dépêche Linuxfr Debian 9 : Stretch déploie ses tentacules.

Les changements apportés par cette version sont suffisamment importantes pour que Yunohost ne soit pas encore compatible. Pour rappel, Yunohost repose sur Debian en n'étant qu'une surcouche (les manipulations spécifiques à Debian restent possibles, même si il faut savoir ce que l'on fait pour ne pas casser la compatibilité avec Yunohost).

Pour en savoir plus, voir le sujet dans le forum : Debian Stretch | YunoHost is NOT YET compatible | YunoHost N'EST PAS ENCORE compatible

Comment rester sur une version de Debian

Comme indiqué dans le message du forum, il faut donc conserver la mention "jessie" comme version dans le fichier sources.list et autres.

$ cat /etc/apt/sources.list
deb http://url_du_depot.fr jessie main
deb-src http://url_du_depot.fr jessie main
deb http://security.debian.org/ jessie/updates main
deb-src http://security.debian.org/ jessie/updates main

Autre façon de faire, avec la commande sed, pour remplacer "main" par "jessie".
Dans le fichier "install" de l'application non officielle (à utiliser en connaissance de cause)
no_stretch_ynh

# Backup old sources.list
sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak

sudo cp -R /etc/apt/sources.list.d /etc/apt/sources.list.d.bak

# Change sources.list with "stable" as distribution
sudo sed -i "s@ stable \+main@ jessie main@g" /etc/apt/sources.list
sudo sed -i "s@ stable-updates @ jessie-updates @g" /etc/apt/sources.list
sudo sed -i "s@ stable/updates @ jessie/updates @g" /etc/apt/sources.list

# Idem for sources.list.d/*.list
sudo sed -i "s@ stable \+main@ jessie main@g" /etc/apt/sources.list.d/*.list
sudo sed -i "s@ stable-updates @ jessie-updates @g" /etc/apt/sources.list.d/*.list
sudo sed -i "s@ stable/updates @ jessie/updates @g" /etc/apt/sources.list.d/*.list

Ou au contraire, comment migrer d'une version stable à une autre

Si on souhaite faire des montées de version stable en version stable pour suivre les évolutions de Debian (pour un serveur ou un poste bureautique sur lequel cela est possible), au contraire, on aura un fichier sources.list du type :

$ cat /etc/apt/sources.list
deb http://url_du_depot.fr stable main
deb-src http://url_du_depot.fr stable main
deb http://security.debian.org/ stable/updates main
deb-src http://security.debian.org/ stable/updates main

Et si c'est en version testing de Debian que l'on veut être (pourquoi pas), ce sera donc :

$ cat /etc/apt/sources.list
deb http://url_du_depot.fr testing main
deb-src http://url_du_depot.fr testing main
deb http://security.debian.org/ testing/updates main
deb-src http://security.debian.org/ testing/updates main

Wget derrière un SSO

SSO ???

Un ensemble de page derrière un SSO (abréviation en anglais Single Sign-On : SSO) ou authentification unique est une méthode permettant à un utilisateur d'accéder à plusieurs applications informatiques (ou sites web sécurisés) en ne procédant qu'à une seule authentification.. C'est le fameux système que l'on retrouve en entreprise où on se connecte une fois pour accéder aux différentes applications de l'Intranet. Pour des infrastructures variées et complexes, il y a lemonldap par exemple. Ou pour Yunohost, il y a SSOwat, un SSO pour nginx, écrit en Lua.

Ma problématique

Sur une des applications de l'Intranet de l'entreprise dans laquelle je travaille, j'ai eu à récupérer différentes pages via l'outil Wget. Soucis, wget ne permet pas de se connecter au SSO.

Au lancement de Wget, l'application ne me voyant pas connecté, je suis renvoyé vers le SSO et ma page récupérée par Wget, même si le lien est correct contient deux champs HTML "Identifiant et mot de passe", soit la mire de connexion.

A l'arrivée sur la page de l'application, il y a une vérification de la présence du cookie d'authentification et comme wget ne le fournit pas, on est renvoyé vers l'authentification.

La solution ?

On lance Firefox dans lequel on a ajouté l'extension Export Cookies. On se connecte sur le site (on a donc un cookie d'authentification qui est créé). On exporte ce cookie via le menu "Outils -> Export Cookies" et on sauvegarde le ficher cookies.txt.

Puis on relance la commande wget qui va bien, avec les options qui vont bien à savoir :

wget --load-cookies cookies.txt -p --no-check-certificate https://application.enterprise.com/page01.htmlt -O ./Applicaton_page01.html

--no-check-certificate pour éviter le soucis avec https
--load-cookies cookies.txt : charge le cookie d'authentification sur le SSO

Firefox, un profil démo pour montrer le tracking

Quelques rappels préalable :
- Le tracking publicitaire ou pistage est un terme qui comprend des méthodes aussi nombreuses et variées que les sites web, les annonceurs et d'autres utilisent pour connaître vos habitudes de navigation sur le Web. Cela comprend des informations sur les sites que vous visitez, les choses que vous aimez, n'aimez pas et achetez. Ils utilisent souvent ces données pour afficher des pubs, des produits ou services spécialement ciblés pour vous.
- Chaque bouton de partage sur les réseaux sociaux affichés (J'aime de Facebook etc.) informe alors le site associé que l'on a consulté tel ou tel site. Facebook et autres ont alors une copie de notre historique de consultation de sites Internets (et ce même en mode Navigation privé)
- Google fournit un service de statistique, Google Analytics, qui permet d'avoir un certain nombre d'informations. Le fait que cet outil d'analyse soit intégré sur différents sites web remontent à Google le fait que vous consultez ces sites...

But de ce tutoriel

Le but de ce tutoriel est de pouvoir montrer facilement et aisément ces affirmations concernant le tracking et la façon dont on est suivi à la trace sur Internet. Cela permet de faire des démonstrations lors d'une animation, d'un atelier, d'un Café vie privée ou autre...

Le principe des profils dans Firefox

Un profil Firefox est associé à un dossier et un ensemble de sous-dossiers qui contiennent tout l'environnement nécessaire au bon fonctionnement de Firefox. Il y aura les fichiers de caches, les favoris, les extensions... tout ce qui concerne l'utilisateur. Tous ces fichiers sont stockés dans le répertoire par défaut (sur C :/nomUtilisateur/Documents & Settings/Firefox ou /home/nomUtilisateur/.mozilla/ sous Gnu/Linux), on peut les déplacer à la création du profil dans un autre dossier, un conteneur TrueCrypt/Veracrypt (pour plus de sécurité par exemple)

Un utilisateur peut avoir plusieurs profils.

Création d'un profil Demo sous Firefox

Firefox permettant la création de profils, pour pouvoir faire des démonstrations du nombre de trackers et scripts en tout genre des différents sites webs et sensibiliser aux blocages de ces derniers, ainsi qu'aux publicités (le débat sur la rémunération des sites Internet et de l'affichage ou non des publicités est mis de côté. On aborde ici la seule problématique du profilage et de la vie privée sur Internet), on créera un profil Demo. Pour ce faire, on lance Firefox avec l'option -p et on crée un profil.

Voir mon tutoriel Création d'un profil sous Firefox pour le détail.

Préparation du profil démo

Une fois le profil Demo crée, on n'ajoute aucune extension, on surfe sur différents sites sur lesquels on l'habitude d'aller. Sur quelques minutes, heures ou quelques jours selon ce que l'on veut comme niveau de détail. On efface rien. On conserve l'historique, les cookies, les fichiers temporaires.

On installe Lightbeam

On installe Lightbeam dans le profil Démo. Lightbeam est une extension pour Firefox qui fait appel à des visualisations interactives pour vous montrer avec quels sites tiers vous communiquez sans le savoir. À mesure que vous naviguez, Lightbeam vous révèlera les coulisses du Web d'aujourd'hui, y compris les parties les moins visibles pour l'utilisateur moyen. Lightbeam - Un coup de projecteur sur ceux qui vous surveillent.

Et on observe... On voit alors que le surf effectué sans aucune extension montre que pour X sites consultés, ce sont des dizaines d'autres que l'on a pas consultés qui sont pourtant au courant de ces visites... Montrer le contenu de ce profil est Lightbeam en démonstration permet de bien sensibiliser à toutes ces problématiques de suivi à la trace sur le web.

Comment bloquer tout ça ?

Pour bloquer tout ça, on fera une présentation de l'installation des extensions :
- Ublock-origin
- Ghostery
- Privacy badger
- Request Policy
Idéalement, on peut refaire un profil Demo_Avec_blocage dans lequel on aura installé ces extensions et consulter les mêmes sites que le profil démo, on installera et lancera Lightbeam et on comparera alors le résultat.

Yunohost, Let’s Encrypt, A+ in SSLLabs – English version

French version / Version française : https://blog.genma.fr/?Yunohost-Let-s-Encrypt-A-au-SSLLabs

Prerequisites : You need to have some knowledge about Let's Encrypt, How SSL/TLS configuration works (basics).

I've followed How to : Install Let's Encrypt certificates and it works. Nothing to say, it helps to have a secured connexion. But in order to have the best TLS configuration, I've test my domain domain and subdomains on the https://www.ssllabs.com/ website. The Default Let's Encrypt configuration gives a B level as results. It's confirmed with the Calomel SSL addons on Firefox. So the Default TLS & Let's Encrypt configuration is not optmised.

Attention : more the grade is high, more the access to the website is restricted. Old browsers (on old computer O.S. or old Smartphone O.S. like Android 2.2, 4.0...) won't be able to connect to your websites.

Only using Firefox in it's latest version on each off my devices (PC or smartphone), it's not a problem for me to have the best grade.

So I've read many how to secure nginx. I've compared the nginx configuration files theses how-o preconize with the one Yunohost has by default. The default nginx file in Yunohost is secured (obsolete algorithm are disabled). But I've gone deeper with some modification.

Nginx Configuration file of my subdomain : /etc/nginx/conf.d/blog.mydomain.org.conf :

ssl_protocols TLSv1.1 TLSv1.2;
#ssl_ciphers ALL:!aNULL:!eNULL:!LOW:!EXP:!RC4:!3DES:+HIGH:+MEDIUM;
ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';

To compare to he one Aeris (the hacktivist) recommands, for an extrem configuration :

TLSv1.2 + EECDH + AESGCM + SHA-2 only :P

What is missing in order to have a better level grade in SSLLabs test, it's Diffie Hellman. We need to generate a file for Diffie Hellman, it's done with :

sudo mkdir -p /etc/nginx/ssl &&
sudo openssl rand 48 -out /etc/nginx/ssl/ticket.key &&
sudo openssl dhparam -out /etc/nginx/ssl/dhparam4.pem 4096

It takes times, depending on processor performance and the capacity to generate random numbers.

After the file generation, in each nginx configuration file of each domain and subdomains, you have to to this :

nano /etc/nginx/conf.d/blog.mydomain.org.conf
# Uncomment the following directive after DH generation
openssl dhparam -out /etc/ssl/private/dh2048.pem -outform PEM -2 2048
# ssl_dhparam /etc/ssl/private/dh2048.pem;
ssl_dhparam /etc/nginx/ssl/dhparam4.pem;

After, you verify ngix configuration files are ok with the command :
nginx -t

You restart nginx with :
service nginx restart

You can now restest your domain on SSLLabs and your grade will be an A+ normally.

Aeris says to me on Twitter

Remove EDH completely. Avoid the (very long) (and weak) DH generation. No compatibility trouble AFAIK.