LAMP

Comment faire pour sécuriser une installation LAMP « standard » ? Voici quelques informations, à adapter ou à compléter.

Mise-à-jour automatique du système

Pour tout système informatique, la meilleure des hygiènes est de faire les mises-à-jour du système et des logiciels importants dès que possible.

Installer un pare-feu

Bien que cela ne garantisse aucunement une sécurité absolue, tout comme un antivirus, cela reste une protection de base indispensable. Pour ma part j’aime bien shorewall, mais il n’est qu’une interface d’iptables qu’on peut trouver pratique (ou pas ) ; ufw fait aussi bien l’affaire.

Durcir le système

Cela consiste à désactiver voir désinstaller tous les services et applications dont on ne se sert pas. Cela réduit la surface d’attaque, c’est-à-dire le nombre de possibilités d’attaquer le système.

Installer un HIDS/HIPS

ossec, psad…

Installer des anti-rootkit

Tout comme un [[HIDS|HIDS/HIPS]], cela n’a de sens que si on surveille l’activité de ces outils. Plusieurs outils sont présents dans les distributions Ubuntu : rkhunter, chkrootkit, unhide…

Installer l’essentiel

$ apt install apache2
$ apache2ctl configtest
$ apt install mysql-server
$ apt install php libapache2-mod-php php-mcrypt php-mysql 

Installer les modules utiles

C’est là que ça se complique. Pour les modules PHP, on fait son choix dans :

$ apt-cache search php- | less

Pour voir ce qui est installé :

$ dpkg -l | grep php

Sécuriser apache

Cacher les informations sensibles

Dans le fichier de configuration apache, modifier ou ajouter les valeurs suivantes :

ServerTokens Prod
ServerSignature Off
TraceEnable Off
Options all -Indexes
Header unset ETag
Header always unset X-Powered-By
FileETag None 

En production, il est toujours préférable de minimiser les informations fournies car elles peuvent être utilisées par des attaquants. Par contre, en développement, c’est l’inverse car cela facilite le débogage. Les headers font parties des informations à cacher.

Attention : certaines directives peuvent être modifiées par la configuration de chaque hôte virtuel ou même de modules (tels que modsecurity !). Il faudra peut-être les reporter ou les supprimer, pour éviter les conflits de paramétrage.

Désactiver l’affichage des répertoires

$ a2dismod autoindex

C’est radical. Curiosité : il ne faut pas répondre yes/no mais 'Yes, do as I say!‘. Trop marrant.

Autres commandes utiles

$ a2query -m : Liste des modules apache activés

Vérifier les accès aux répertoires

Désactiver les modules et fonctions inutiles (CGI, SSI)

Installer un WAF, tel que mod_security

$ apt install libapache2-modsecurity
$ a2enmod security2
$ cp /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf 

vvv

vi conf-available/security.conf

Modifier modsecurity.conf en ajout ou modifiant :

SecRuleEngine On
SecResponseBodyAccess Off ??? On me paraît une meilleure option... SecRequestBodyLimit 8388608 (ou plus)
SecRequestBodyNoFilesLimit 131072
SecRequestBodyInMemoryLimit 262144 

Dans le fichier /etc/apache2/mods-enabled/security2.conf, ajouter les règles minimales, ou ajouter les règles OWASP si vous les avez récupérées.

IncludeOptional /usr/share/modsecurity-crs/*.conf
IncludeOptional /usr/share/modsecurity-crs/base_rules/*.conf 

Installer mod_evasive (optionnel)

Pour lutter (un peu) contre les DDoS.

Je ne suis pas persuadé qu’on puisse lutter activement contre une attaque DDoS à partir du serveur lui-même

Sécuriser MySQL

Installation sécurisée

$ mysql_secure_installation

L’utilitaire demandera plusieurs actions :

• Utiliser le plugin de validation de mot de passe. N’activer que si vous êtes sûr de vous, les règles peuvent être un peu strictes pour un usage standard.
• Modifier le mot de passe root. A ne faire que si le mot de passe entré lors de l’installation est trop faible.
• Suppression des utilisateurs anonymes : oui, sans discussion.
• Interdiction d’accès distant pour root : oui, sans discussion.
• Suppression des bases de test et des privilèges associés : oui (recommandé)
• Rechargement des rôles et privilèges : oui.

Accès local uniquement

Théoriquement, l’utilitaire précédent effectue ce réglage pour root.

Séparation des rôles (des utilisateurs)

Local infile

Il suffit d’ajouter une ligne dans la section [mysqld] du fichier de configuration de MySQL(/etc/mysql/mysql.conf.d/mysqld.cnf) :

local-infile = 0

A quoi sert cette option ? A charger rapidement un fichier texte dans une base MySQL. A moins d’en avoir vraiment besoin autant désactiver cette fonction qui peut introduire beaucoup de saletés dans la base de données, de façon persistante.

Sécuriser phpMyAdmin

xxx

Sécuriser PHP

Masquer les informations (si possible)

En premier lieu, il faut trouver les fichiers .ini actifs par la commande :

php --ini | grep "Loaded Configuration File"

Sans oublier les fichiers utilisés par le serveur http d’Apache… Ensuite, il fait modifier certains paramètres de façon à masquer les informations inutilement exposées.

expose_php = Off
display_errors = Off
mail.add_x_header = Off 

Désactiver les modules inutiles et/ou dangereux

Dans le(s) même (s) fichier(s) .ini, on utilise le paramètre suivant :

disable_functions = show_source,system,shell_exec,passthru,exec,phpinfo,popen,proc_open,allow_url_fopen,curl_exec,curl_multi_exec 

Pour ce qui est des fonctions à désactiver, c’est vous qui voyez, en fonction de ce que votre site doit utiliser ! On peut ainsi désactiver des fonctions comme phpinfo, particulièrement bavarde !

Désactiver l’exécution à distance

Contrôler les paramètres sensibles

taille upload, max exec time, open_basedir)

Sécuriser l’OS

Tripwire, tiger, SELinux/AppArmor

Sources

• https://www.rosehosting.com/blog/how-to-secure-your-lamp-server/
• https://tecadmin.net/security-tips-for-lamp-stack-on-linux/
• https://gist.github.com/zachbrowne/53a1e009a8c2c8a84b82c909559dfe27
• https://www.digitalocean.com/community/tutorials/how-to-install-and-secure-phpmyadmin-on-ubuntu-16-04
• https://www.digitalocean.com/community/tutorials/how-to-install-linux-apache-mysql-php-lamp-stack-on-ubuntu-16-04