General discussion on security hardening

Sangokuss commented 3 years ago

Lynis est un logiciel libre d'audit de sécurité (simple et pouvant retourner quelques faux positifs) mais qui a le mérite de donner quelques pistes pertinentes aux sysadmins débutants souhaitant contrôler et améliorer la sécurité par défaut de leurs systèmes.

Cet outil n'est pas magique, mais il permet par exemple de constater qu'un système Yunohost obtient un score (ou hardening index) inférieur à 60 après installation. Score qu'il est assez aisé (et pertinent) de faire progresser, sans pour autant y dépenser toute son énergie, ni vérouiller totalement le système.

Rappel : « hardening » (ou durcissement) est un terme anglais signifiant « durcissement » . Appliqué à la sécurité d’un système d’information, il s’agit donc d’améliorer la sécurité d’un système, d’un réseau ou d’une application via le durcissement de sa configuration ou de sa structure.

La suite des propositions ci-dessous vise donc à renforcer, en restant raisonnable, le niveau général de sécurité d'un système Yunohost et complète les règles déjà énoncées sur le site Yunohost dans la rubrique « Sécurité » :

Durcissement du /boot : ~# nano /etc/fstab Puis modifier les options de montage de la partition de la manière suivante : defaults,nodev,nosuid,noexec NB : selon le partitionnement, c'est également application à /home

Durcissement SSH : L'essentiel des recommandations de Lynis peuvent être suivies.

Limiter l'accès à l'interface d'administration du serveur (ici par exemple au seul réseau local, surtout si l'administration à distance n'est indispensable, ou bien restreindre à votre ip fixe de confiance pour le faire) : Editer /etc/nginx/conf.d/yunohost_admin.conf.inc et /etc/nginx/conf.d/yunohost_api.conf.inc et ajouter :

allow xxx.xxx.x.0/24;
deny all;

Modier l'umask utilisé : Pour ma part, je recommande de modifier l'Umask en 077 plutôt que 022, en modifiant le fichier /etc/login.defs NB : d'autres options sont disponibles dans ce fichier, je recommande de l'explorer.

Utilisation de 2 serveurs DNS disctincts : Utilisation de 2 serveurs de nom de domaine : personnellement, j'utilise mes DNS personnels, mais ceux de Quad9, 1.1.1.1, LDN/FDN, ... peuvent faire l'affaire selon votre degré d'exigence.

Si les ports suivants ne vous sont pas indisqpensables, ceci peut vous être utile : Voici comment désactiver les périphériques USB / Firewire (hdmi) / Thunderbolt via kernel :

~# echo 'install usb-storage /bin/true' >> /etc/modprobe.d/disable-usb-storage.conf
~# echo "blacklist firewire-core" >> /etc/modprobe.d/firewire.conf
~# echo "blacklist thunderbolt" >> /etc/modprobe.d/thunderbolt.conf

Utilisation de portsentry : Assez inhabituel (voir méconnu), le logiciel portsentry est à mon sens complémentaire du fal2ban déjà installé sur Yunohost. L'idée est assez simple : bannir les IP trop intrusives de manière définitive (càd celles qui feraient des scans de ports principalement). Cette documentation est déjà très bien faîte : https://wiki.debian-fr.xyz/Portsentry La listes des IP blacklistée est alors centralisée dans le fichier /etc/hosts.deny /!\ Mais penser à bien whitelister vos adresses IP pour l'administration du serveur... sous peine de vous « auto-bannir » :rofl:

Facultatifs, mais pertinent :

Installer les paquets suivants : rkhunter, lynis, apt-listbugs, debian-goodies, debsecan, debsums, fail2ban, portsentry (cité ci-dessus), chkrootkit, usbguard (pour en savoir plus sur usbguard : https://brlnd-tech.eu/blog/index.php/2020/10/26/renforcer-la-securite-de-vos-serveurs-linux-avec-usb-guard-gestionnaire-de-peripheriques-de-stockage/ ).
configurer les /etc/issue et /etc/issue.net avec un beau Warning/Avertissement.

alexAubin commented 3 years ago

Merci pour ton retour :+1: Je vois qu'il y a des choses qui sont assez difficilement automatisables mais il y a peut-être des morceaux qu'on pourrait automatiser (ou mettre sous forme de setting)

À minima on pourrait aussi inclure ces recommendations dans https://yunohost.org/#/security (qui commence à beaucoup dater...)

configurer les /etc/issue et /etc/issue.net avec un beau Warning/Avertissement.

Est-ce que tu peux élaborer sur l'intérêt de ça ? De ce que j'avais compris le fait d'avoir un /etc/issue(.net) custom a tendance à éloigner les attaquants car le serveur sonne un peu + comme un truc configuré aux petits oignons qu'un truc standard ? Est-ce que c'est ça ?

Installer les paquets suivants: ..., debian-goodies, ... debsums, ...

Tu pourrais élaborer sur l'utilité d'un point de vue sécurité de ces deux paquets ?

Sangokuss commented 3 years ago

Merci pour ton retour +1 Je vois qu'il y a des choses qui sont assez difficilement automatisables mais il y a peut-être des morceaux qu'on pourrait automatiser (ou mettre sous forme de setting)

À minima on pourrait aussi inclure ces recommendations dans https://yunohost.org/#/security (qui commence à beaucoup dater...)

configurer les /etc/issue et /etc/issue.net avec un beau Warning/Avertissement.

Est-ce que tu peux élaborer sur l'intérêt de ça ? De ce que j'avais compris le fait d'avoir un /etc/issue(.net) custom a tendance à éloigner les attaquants car le serveur sonne un peu + comme un truc configuré aux petits oignons qu'un truc standard ? Est-ce que c'est ça ?

Oui, c'est exactement cela : certains bots passent leurs chemins directs, en effet.

Installer les paquets suivants: ..., debian-goodies, ... debsums, ...

Tu pourrais élaborer sur l'utilité d'un point de vue sécurité de ces deux paquets ?

Debian-goodies fournit notamment le « checkrestart », commande permettant d'y voir plus clair sur la necessité de relancer un service ou même le serveur (surtout après une mise à jour).

Debsums vérifie les sommes de contrôle MD5 des paquets Debian installés, mais à faire à la main, donc moins pertinent pour le débutant qui ne le fera sans doute jamais.

Sangokuss commented 3 years ago

Ayant un peu de temps ce soir, voici en complément quelques actions de durcissement du kernel que j'applique via édition du fichier /etc/sysctl.d/99-sysctl.conf en ajoutant les lignes suivantes :

# Divers
fs.suid_dumpable = 0
kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2
kernel.yama.ptrace_scope = 1
kernel.sysrq = 0: 
# Contrôle l'utilisation des syncookies TCP
# Activer les protections SYN-flood
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_synack_retries = 5
# Prévenir contre les 'attaques syn flood' courantes
net.ipv4.tcp_syncookies = 1

Rappel : il faut redémarrer ou faire un ~# sysctl -p pour apliquer.

alexAubin commented 3 years ago

Salut,

tant qu'on y est, vu que tu sembles avoir un peu d'XP en sécurité, est-ce que tu as un avis sur https://github.com/YunoHost/issues/issues/1120

Edit: et https://github.com/YunoHost/issues/issues/1515 + https://github.com/YunoHost/example_ynh/pull/136/files qui peut aussi être appliqué au core dans une certaine mesure ;)

Sangokuss commented 3 years ago

Bonjour matinal,

Je pense en effet que systemd est un point sur lequel il faut porter son attention, en particulier par les options de durcissement qu'il fournit, si on souhaite améliorer le niveau général de sécurité de Yunohost. Par exemple en renforçant l'isolation des services tournant sur le serveur. D'autant que les fonctionnalités ici proposées par systemd sont indépendantes du langage d'implémentation du service.

De mémoire, il y a un excellent article sur le sujet (sur le site de Redhat) : https://www.redhat.com/sysadmin/systemd-secure-services

Sangokuss commented 3 years ago

Petit complément sur la configuration par défaut de nginx (security.conf.inc) :

more_set_headers "Content-Security-Policy : upgrade-insecure-requests"; more_set_headers "Content-Security-Policy-Report-Only : default-src https: data: 'unsafe-inline' 'unsafe-eval' "; more_set_headers "X-Content-Type-Options : nosniff"; more_set_headers "X-XSS-Protection : 1; mode=block"; more_set_headers "X-Download-Options : noopen"; more_set_headers "X-Permitted-Cross-Domain-Policies : none"; more_set_headers "X-Frame-Options : SAMEORIGIN"; more_set_headers "Referrer-Policy: strict-origin"; more_set_headers "Permissions-Policy: camera=(self), fullscreen=(*), geolocation=(self), payment=()";

;-)

JOduMonT commented 3 years ago

Voici quelques réflexions:

FSTAB et les options

Durcissement du /boot : ~# nano /etc/fstab Puis modifier les options de montage de la partition de la manière suivante : defaults,nodev,nosuid,noexec

J'aime bien l'idée, mais

ça vaut dire que tous le monde doit RTFM et installer leur Debian avec une partition pour boot
appliquer defaults qui est l'équivalent de (rw,suid,dev,exec,auto,nouser,async) puis ensuite appliqué nodev, noexec, nosuid c'est un peu redondant; dans mon cas j'applique souvent noatime et quand c'est possible nodev, noexec, nosuid sans defaults.
nosuid sur /home et/ou /var/www va créer des ennuis puisque beaucoup de scripts d'installation de YNH chown les répertoires
noexec sur /home et/ou /var/www va parfois créer puisque certains script YNH exécute des scripts tel que node et python

PortSentry vs Fail2Ban pour les recidiviste

Utilisation de portsentry

Avec Fail2Ban, il ya la possibilité d'avoir une liste permanente pour les recidiviste.

UPDATE: en fait recidive est déjà configuré dans Yunohost donc installer PortSentry alourdierait le système sans apporter plus de sécurité.

Debian-Goodies

Tu pourrais élaborer sur l'utilité d'un point de vue sécurité de ces deux paquets ?

Debian-goodies fournit notamment le « checkrestart », commande permettant d'y voir plus clair sur la necessité de relancer un service ou même le serveur (surtout après une mise à jour).

Ce pacquets est effectivement intéressant pour réduire le temps de non disponibilité des services

Socket UNIX vs Stack TCP

Pour faire un durcissement et amélioré les performances, il serait peut-être préférable de connecter les applications via des SOCKET au lieu d'utiliser la stack réseau example pour wordpress

PHP vers MYSQL: define('DB_HOST', 'localhost:/var/run/mysqld/mysqld.sock' );
NGINX vers PHP: listen = /run/php/php7.4-fpm.sock
REDIS: unixsocket /var/run/redis/redis.sock

Mais encore là, ce n'est pas possible avec tous les applications et si à long terme YunoHost désire faire de la redondance ou diviser la charge en tier (proxy - appli - base de donnée) ça serais à déconfigurer.

Lynis

De mémoire Debian et Ubuntu de base score 55-57;
J'ai personnellement déjà scorer 97 avec un LEMP basé sur Ubuntu et un Ubuntu hébergeant du Docker, c'est assez facile ya des scripts ansible prémaché par konstruktoid et dev-sec; mais lorsque d'autres techniciens ont pris la main sur les systèmes c'était une rééducation complète et du coup le client à dit pas de temps à perdre.

Mais de quel côté vient la menace ?

En sommes, oui le durcissement c'est bien, mais il faut également profiler l'ennemi potentiel et surtout de quel côté du pare-feu celui-ci sera situé. Si la menace vient de l'internet; personnellement je crois que...

la plus grande menace c'est d'exposer le fait qu'on utilise Yunohost donc le fait que l'addresse du portail soit statique
comme Yunohost fait c'est de limité les ports exposé POP et IMAP sont déjà sécurisé en exposant seulement la version TLS/SSL, on pourrait être extremiste et bloquer le port 80 mais bon pour les simplets qui font encore des requêtes en HTTP clair ça serait la galère.
durcir les services exposés tel que NGINX, php, dovecot, postfix, SSH... et un bon début c'est de cacher la version du service utilisée.
un gros changement qui aurait potentiellement un grand impact côté sécurité, si c'est bien expoité; serait de passer de IPTables à NFTables et ainsi proposé des filtres par pays. En fait, avec quelques clients on fait cela, on ouvre l'accès au serveur à des pays spécifique, donc sachant que les utilisateurs d'une tel application sont seulement en France, on bloque le reste du monde. Oui c'est possible de faire avec IPTables mais c'est gourmand en ressrouce.
je vais y penser ;)...

Sangokuss commented 3 years ago

Bonsoir,

Tout d'abord, merci pour le complément ! :+1:

Pour rappel du contexte du post : on m'a demandé mon avis, je l'ai donc donné. Et il n'engage que moi :wink:

Le point positif à mon avis dans nos échanges, c'est à minima d'éclairer (et/ou de faire se questionner) un peu les utilisateurs sur le champ des possibles pour qu'ensuite ils puissent faire leurs choix. Et donc, au delà des bonnes pratiques élémentaires (qui ne sont pas rappelé, volontairement, ici), d'avoir quelques pistes pour durcir en fonction de la menace à laquelle ils souhaitent se protéger (tout cela est donc assez subjectif).

Bref, voici quelques remarques complémentaires :

pour le /etc/fstab : oui, c'est extrême. Mais pour une infra bien configurée de base, qui fait tourner des applications tels Nextcloud, Dokuwiki, webapp,... le durcissement proposé via nodev,noexec et nosuid sur le /boot et /home est à mon avis essentiel (ici, dans mon propos, on part du fichier de base auquel on ajoute simplement les options, c'est donc très simple à faire et ça évite pas mal de petits ennuis) et ne pose aucun problème ;
Pour Fail2ban / Portsentry : je ne suis pas d'accord car ces deux outils, au fonctionnement bien différents, répondent à des besoins différents. Pour simplifier, Fail2ban bloque les attaques de type force brute, alors que portsentry bloquera les scan de ports -> ils sont donc complémentaires :wink:
Pour le reste, nous sommes d'accord :-)

Après, je lance l'idée : on pourrait peut-être dégager quelques incontournables et scripter le tout pour proposer une première solution de durcissement ! A réfléchir :-)

JOduMonT commented 3 years ago

Merci pour ta mise en contexte

côté fstab, je suis tout a fait en accord avec toi, les données applicatives devrait être à tout de moins dans une partition ayant noexec
j'avoue ne pas connaitre PortSentry et avec ton explication, effectivement cela me semble complémentaire ;)

Donc nous sommes 100% d'accord Je vais me faire un ynh-dev sur mon proxmox et débuté le durcissement

Donc j'ai dumpter les controls Lynis, on pourrait peupler le fichier afin de fixer "l'issue" relevé par Lynis qu'en penses-tu ? https://github.com/JOduMonT/lynis-ynh

alexAubin commented 2 years ago

Moar security tips: https://github.com/decalage2/awesome-security-hardening

YunoHost / issues