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 – Supervision du trafic réseau

Dans mon billet Yunohost - Supervision en ligne de commande, je parlais de quelques commandes que j'utilise pour faire de la supervision / monitoring de ma machine Yunohost (les commandes étant des commandes génériques d'administration d'un système GNU/Linux). Dans ce billet, je m'attarderai plus sur les commandes liées au réseau que j'utilise.

Ces commandes ont été testée sur Debian dans mon cas, mais devraient marcher sur n'importe quel distribution Linux.

netstat

Outil qui permet de voir les ports et connexions en cours :

$ netstat -puant
$ netstat -lapute

Oui l'ordre des options donne un mot explicite, mais au moins c'est facile à retenir et on a là un bonne combinaison des options de la commande.

Ce type de commande donne un résultat comme

Proto Recv-Q Send-Q Adresse locale Adresse distante Etat PID/Program name
tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN -

Cette commande est intéressante car elle permet de très rapidement voir quels sont les ports ouverts et utilisés et d'alors régler / affiner le paramétrage de son pare-feu / firewall.

Nethogs

Nethogs permet de surveiller par processus, l'usage de la bande passante en temps réel. Par processus ce sont tous les logiciels utilisant le réseau : client SSH, navigateur etc.

Si en lançant la commande

sudo nethogs eth0
creating socket failed while establishing local IP - are you root?

vous avez une erreur, c'est liée au fait que la version packagée dans Debian n'est pas la dernière version et pour ne pas avoir cette erreur, il faut compiler la dernière version. C'est très rapide eFt ça se fait depuis les sources en suivant ce tutoriel par exemple.

Une fois que c'est fait, on peut lancer la commande et on a alors le résultat :

netHogs version 0.8.5
PID USER PROGRAM DEV SENT RECEIVED
11145 genma sshd: genma@pts/0 eth0 0.131 0.064 KB/sec
? root unknown TCP 0.000 0.000 KB/sec
(...)
TOTAL 0.131 0.064 KB/sec

iftop

Iftop est une commande qui est au réseau ce que Htop est au processus. Iftop liste toutes les connexion en IPv4 et IPv6 que la machine fait et indique l'adresse IPv4 ou IPv6 cible avec laquelle le serveur (ici une machine Yunohost) communique. On n'a pas le type de connexion, juste Ip source / Ip Cible et les consommations en bande passante / quantité de données échangées en temps réel.

Si vous voulez par exemple voir le trafic sous forme d'adresses IP, il suffit d'ajouter l'option -n. On peut afficher les différents ports impliqués dans le trafic grâce à l'options -P.

Il y a d'autres options mais ceux sont les deux que j'utilise principalement.

Dans la liste des connexions, je vois par exemple
- ma connexion SSH
- une connexion vers freeplayer.freebox.fr, ce qui correspond au fait que je monte le répertoire partagé de la freebox v6 (fonction NAS)
- ...

J'ai par exemple pu voir avec la commande iftop un certain nombre de connexion établie dans le sens locale vers des serveurs de cache DNS, en IPv4 et IPv6. C'est toujours marrant de voir que le résolveur de DNS locale travaille...

Conclusion

Netstat, Nethogs et Iftop, trois commandes que j'utilise régulièrement et de façon complémentaire. Si vous avez d'autres outils du même type, les commentaires du billet sont ouverts pour recevoir vos conseils et suggestions.

Yunohost, Let’s Encrypt, A+ au SSLLabs

Prérequis pour comprendre cet article Connaitre Let's Encrypt, le principe de SSL/TLS, savoir mettre en place la configuration de Let's Encrypt.

Dans le cadre de l'autohébergement de mon cloud personnel sur Yunohost, j'ai remplacé le certificat autosigné par un certificat Let's Encrypt, pour le domaine principal ainsi que les sous-domaines. Pour ce, j'ai suivi le tutoriel How to : Install Let's Encrypt certificates, pas à pas. Ca marche, le certificat est mis en place et permet d'avoir une connexion sécurisée de qualité.

Toutefois, comme je cherche à avoir la configuration TLS (pour les connexions HTTPS) la meilleure possible, j'ai testé l'adresse de mon nom de domaine (et des sous-domaine associé) sur le site https://www.ssllabs.com/. Par défaut la configuration est bonne et correct mais ne donne qu'une note de B comme résultat.

Ce qui est confirmé avec une extension comme Calomel SSL qui montre que la configuration n'est pas optimum/la plus élevée.

Attention : plus la note est élevée, plus la configuration est stricte et rend incompatible l'accès avec les anciennes versions des navigateurs (d'ordinateur ou d'OS mobile).

N'accédant à ce cloud personnel que par un navigateur récent, Firefox, quelque soit mon appareil (PC ou smartphone), ce n'est pas un soucis et mon but est donc d'obtenir la meilleur note possible.

Par défaut la configuration est bonne mais donne donc un B comme résultat. J'ai donc regardé ce que m'indiquait le résultat du test du SSLLabs, j'ai consulté différents tutoriaux sur comment sécuriser nginx...

J'ai comparé les modifications faites à la configuration nginx conseillée à celle qui est mise en place par défaut par Yunohost, la configuration est bien faite et sécurisée (les algorithmes obsolètes sont désactivés par exemple). J'ai toutefois été un peu plus loin en apportant quelques modifications :
Extrait de la configuration de Nginx /etc/nginx/conf.d/blog.mondomaine.org.conf :

ssl_protocols TLSv1.1 TLSv1.2;
#ssl_ciphers ALL:!aNULL:!eNULL:!LOW:!EXP:!RC4:!3DES:+HIGH:+MEDIUM;
# On réduit les différents algos de chiffrement utilisable
ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';

A comparer avec ce que recommande Aeris par exemple, en configuration extrême :

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

Ce qu'il manque pour avoir une meilleure note, c'est d'avoir du Diffie Hellman. Il faut générer le fichier pour Diffie Hellman, ce qui se fait via :

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

C'est assez long, ça prend une bonne dizaines de minutes (et est très dépendant de la puissance processeur et la génération de nombres aléatoires...)

Ensuite, dans la configuration de Nginx de chacun des domaines et sous-domaine on modifie le fichier de la façon suivante :

# nano /etc/nginx/conf.d/blog.mondomaine.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;

Une fois ces modifications apportées, on valide que la configuration nginx est sans erreur

nginx -t

On redémarre alors nginx via

service nginx restart

Et on peut de nouveau tester la configuration sur le site du SSLLabs. Et normalement on devrait avoir une note supérieure.

Yunohost – Supervision en ligne de commande

Date de dernière mise à jour 07 juillet 2016

Avec Yunohost, je me suis mis sérieusement à l'administration système pour comprendre ce qui se passe sur ma machine et surveiller les accès et connexions etc. J'accède donc à ma machine via SSH (via une clef) en réseau locale ou à distance et dans ce billet, je comptais évoquer quelques-uns des outils et commandes que j'utilise. Le but n'est pas de faire un cours complet, juste un listing / une sorte d'aide mémoire partagé. Si vous même avez des conseils, des outils préférés non listés, n'hésitez pas à commenter.

Je suis susceptible de compléter ce billet au fur et à mesure de ma montée en compétence, d'où la date de mise à jour ci-dessus.

Consommation mémoire et listing des processus

Pour ça j'utilise la commande top dans sa version améliorée, à savoir

Htop

Pour aller plus loin, j'utilise

Glances

donne la consommation mémoire, les processus, l'espace disque...

Je vous renvoie vers Glances - An eye on your system de Nicolargo.

Pour le réseau

Nethogs

qui permet de surveiller par processus, l'usage de la bande passante en temps réel.

Pour voir les ports et connexions en cours,

$ netstat -puant
$ netstat -lapute

Analyses des logs

Pour l'analyse des logs, je fais pour l'instant des

tail -f /var/log/monfichier.log

Pour Fail2ban, je regarde ce qui se passe au niveau des différentes jails via

fail2ban-client status ssh

par exemple

Je commence à utiliser GoAccess - Visual Web Log Analyzer qui permet de voir les logs de façon un peu plus graphique et sympa comme le monte l'image suivante :

SSH derrière un proxy, Sslh

Le proxy du boulot

Actuellement je suis en mission chez un client et derrière un proxy (voir à ce sujet mes différents billets taggués proxy). Les seuls ports ouverts sur ce proxy sont les ports 80 (http) et 443 (https).

Ayant un Raspberry qui tourne chez moi derrière ma Freebox, je peux me connecter dessus en SSH en passant par le port 443. Dans Putty ou Kitty, j'ai défini le proxy, le fait d'utiliser le port 443. J'arrive par SSH sur le port 443 de la Freebox. Sur la Freebox, j'ai défini que le port 443 était redirigé vers le port SSH du Raspberry Pi (22 par défaut). Dans Firefox, il me suffit alors de lui dire d'utiliser le proxy local créé pour que ma connexion Internet se fasse via la Freebox. Pour plus de détail, voir le tutoriel détaillé et complet que l'on trouve ici Contourner un proxy (au boulot…) via SSH et Putty.

Avec Yunohost déjà en place

Or sur ma Freebox, les ports 80 et 443 sont déjà ouverts et redirigés vers les ports correspondant du Raspberry pi sur lequel tourne Yunohost. Il n'y a donc pas de place, le port 443 est déjà utilisé/dédié aux connexions httpS au serveur web de Yunohost

Si je souhaite pouvoir me connecter en SSH sur mon Raspberry depuis la connexion Internet de mon lieu de travail, il faut que je sorte via le port 443... Et donc j'arrive sur le port 443 de la Freebox...

Une solution simple ?

Une solution simple et non technique est donc de passer par la connexion 3G/4G du téléphone (La connexion via le téléphone se fait via un abonnement Freemobile et les différents ports testés en sortie du PC (et en entrée sur la Freebox) ne sont pas bloqués/filtrés. Le téléphone me sert alors de modem). Ainsi je ne suis plus bloqué/filtré par le proxy et j'arrive via un autre port sur le serveur SSH (22 par défaut). Laissant le port 443 pour le https.

Oui mais si je veux quand même utiliser SSH depuis le réseau derrière un proxy ?

Une autre solution plus technique : Sslh

SSLH est un multiplexeur, qui permet de gérer les requêtes venant du port 443 pour rediriger vers les services SSH et SSL, ce qui permet par exemple de creuser un tunnel SSH et outre passer les règles des proxys professionnel ou tout simplement sécuriser sa connexion lors d'accès à des spots wifi public.
- SSLH : HTTPS et SSH sur le même port !
- SSLH : choisir le protocole ssl par défaut en cas de timeout

Dit autrement, on arrive sur la Freebox, via https ou SSH via le port 443. Les connexions sont redirigées par la Freebox sur le Raspberry. Et c'est SSLH qui tourne sur le Raspberry qui lui va déterminer si la connexion est de type https ou SSH et rediriger alors vers le bon service (ngnix ou le serveur SSH). Je n'ai pas encore mis en place ce système, mais ça ne saurait tarder. A suivre donc.