Rendu Hardening partie II : Linux
Rendu Hardening partie II : Linux.........................................................................................1
Mise en place......................................................................................................... 1
Sécurisation des fichiers et répertoires.................................................................. 4
AppArmor............................................................................................................... 5
Désactiver les modules et fonctionnalités.............................................................. 6
Génération des certificats SSL............................................................................... 6
Configuration iptables...........................................................................................10
Journalisation et alertes........................................................................................11
Schéma de notre architecture
Mise en place
Voici les configuration que nous avons mis en place pour le serveur web apache et le
reverse proxy nginx
Apache :
nano /etc/http/[Link]
nano /srv/http/[Link]
systemctl restart httpd
Nginx :
Création de 2 dossiers pour ensuite configurer le reverse proxy
mkdir -p /etc/nginx/sites-available
mkdir -p /etc/nginx/sites-enabled
Maintenant écrivons le fichier de configuration du proxy
nano /etc/nginx/sites-available/[Link]
Activer la configuration du site grâce à un lien symbolique
ln -s /etc/nginx/sites-available/[Link] /etc/nginx/sites-enabled/
Modifications du fichier de configuration principale de nginx pour qu’il prenne en compte ce
nouveau fichier
nano /etc/nginx/[Link]
systemctl restart nginx
Nous pouvons tester notre configuration en faisant un curl depuis le proxy
Sécurisation des fichiers et répertoires
Créer un utilisateur nginx pour le service
useradd -r -s /sbin/nologin nginx
Modifier le fichier de conf pour qu’il utilise l’utilisateur nouvellement créé
nano /etc/nginx/[Link]
Créer un nouveau dossier séparé pour stocker les logs
mkdir /etc/logs_reverse
touch [Link]
chown nginx:nginx /etc/logs reverse/
chmod 700 /etc/logs reverse/
Modifier le fichier de configuration nginx pour qu’il pointe vers ce fichier d’erreur pour les
logs
nano /etc/nginx/[Link]
Définir les droits d’accès des fichiers nginx en suivant la politique du moindre privilège
chown -R root:root /etc/nginx
chmod 755 /etc/nginx
chmod 755 /etc/nginx/sites-available
chmod 755 /etc/nginx/sites-enabled
find /etc/nginx -type f -exec chmod 644 {} \;
chown root:root /etc/nginx/*
chmod 755 /usr/sbin/nginx
AppArmor
Il y a eu un problème au niveau de l'installation, il manquait des modules dans le noyau et il
aurait fallu le recompiler.
Néanmoins, voici la procédure que nous aurions suiv
AppArmor marche avec des profiles, on en crée un pour nginx
nano /etc/apparmor.d/usr/sbin/nginx
Après avoir créé ce profil, il faut le charger
apparmor_parser -r /etc/apparmor.d/usr/sbin/nginx
Et voilà, le profil est activé. Ceci est un exemple de ce que nous aurions pu mettre en place
sans les soucis de modules dans le noyau
Désactiver les modules et fonctionnalités
D’abord il faut savoir quels sont les modules utilisés par notre NGINX grâce à cette
commande
nginx -V 2>&1 | grep -- --with
Maintenant que nous avons la liste, il ne nous reste plus qu’à aller commenter dans le fichier
/etc/nginx/[Link] les lignes contenant “include” suivi du module que l’on souhaite
désactiver.
Exemple pour FastCGI
Pour ce qui est des restrictions d’accès, on pourrait imaginer que l’on souhaiterait que notre
site ne soit accessible que depuis le subnet interne de l’entreprise. On pourrait alors modifier
le fichier [Link] comme ceci
nano /etc/nginx/[Link]
Cependant dans notre cas nous n’allons pas l’implémenter car nous souhaitons que notre
site soit accessible depuis internet
Génération des certificats SSL
Afin de sécuriser la connexion entre les clients et le proxy, nous commençons par générer
une clé privée RSA à l’aide de la commande suivante : openssl genpkey -algorithm RSA
-out /etc/ssl/private/[Link] -aes256
Par la suite, nous créeons une demande de signature de certificat : openssl req -new -key
/etc/ssl/private/[Link] -out /etc/ssl/private/[Link]
On génère ensuite un certificat auto signé : openssl x509 -req -days 365 -in
/etc/ssl/private/[Link] -signkey /etc/ssl/private/[Link] -out
/etc/ssl/certs/[Link]
Nous allons ensuite modifier le fichier de configuration [Link] afin d’activer la
sécurisation par certificat SSl et d’incrémenter le certificat et la clé précédemment créés :
Nous en profitons également pour forcer l’utilisation des protocols TLS 1.2 et 1.3 afin de
limiter les risques de sécurité mais également pour désactiver les suites de chiffrement
faibles.
Nous ajoutons également le bloc nécessaire à la redirection des requêtes http vers Https.
Ensuite, nous alimentons le fichier de configuration du reverse proxy afin d’activer l’écoute
sur le port 443 et ajouter toutes les informations de configuration nécessaires :
Une fois cela effectué, nous vérifions la configuration à l’aide de la commande nginx -t et
redémarrons le service nginx :
Nous pouvons ensuite vérifier le bon fonctionnement de notre reverse proxy en tapant son
adresse dans le navigateur :
Tout est parfaitement fonctionnel, nous pouvons passer à la suite du devoir.
Configuration iptables
Nous allons implémenter des règles iptables sur nos 2 machines
Proxy
Web
Journalisation et alertes
Pour faire cela, nous allons utiliser un script bash
Il nous faut installer msmtp pour pouvoir envoyer les alertes par mail
pacman -S msmtp
nano ~/.msmtprc
chmod 600 ~/.msmtprc
Il ne reste plus qu’à le mettre dans le crontab pour qu’il soit exécuté régulièrement
crontab -e
Pour résumer, ce script recherche dans le fichier de logs nginx les lignes contenant error et
les stock dans un fichier temporaire.
Ensuite, si le fichier temporaire n’est pas vide, il envoie un mail d’alerte avec le détail des
erreurs contenues dans le fichier temporaire.
Grâce au crontab l’exécution de ce script est automatique et assure donc une surveillance
du service.
