Samuel a écrit 133 commentaires

Tout dans un seul fichier, ce ne serait pas supportable.

La configuration nginx par défaut, pour Debian, résout ce problème avec :

http {
        # snip
        include /etc/nginx/conf.d/*.conf;
        include /etc/nginx/sites-enabled/*;
}

Avec l'idée que chaque bloc serveur dispose d'un fichier correspondant dans /etc/nginx/sites-available/ et activé par un lien depuis /etc/nginx/sites-enabled/.

Comment vous feriez pour gérer plusieurs configurations?

Actuellement, tout ce qui arrive sur le 80 (j'ai un reverse proxy en amont) est renvoyé vers un port en particulier selon le domaine et le sous-domaine. Je trouve que c'est pratique.

Nginx peut servir plusieurs domaines sur le même port et la même adresse IP.

Par exemple, la configuration suivante est valide et fait bien ce qu'on attend :

server {
    listen 80;
    listen ::80;
    server_name application1.example.com;
    # la configuration de application 1, avec les blocs location si tu veux ...
}

server {
    listen 80;
    listen ::80;
    server_name application2.example.net;
    # la configuration de application 2, avec les blocs location si tu veux ...
}

server {
    listen 80;
    listen ::80;
    server_name application3.example.fr application3.example.net;
    # la configuration de application 3, avec les blocs location si tu veux ...
}

nginx va se baser sur l'hôte demandé dans la requête HTTP pour sélectionner le bon bloc server.

Référence : Server names (doc nginx).

Je cherche à minimiser le nombre d'applications qui tournent sous root : le moins j'en ai, le mieux je me porte.

En l'occurrence, ce qui a initialement motivé l'écriture de cet article, c'est la faille PHP-FPM local root vulnerability publiée en octobre 2021 : les workers FPM peuvent contaminer le processus maître et, si le maître est root, gagner les pleins pouvoirs sur la machine. Déléguer à FPM le rôle de créer les workers en tant qu'utilisateurs distincts nécessite de donner à FPM les droits root : je passe donc par systemd pour remplir cette fonction (systemd ayant déjà ces droits par nature) et je retire les droits root à PHP-FPM.

Pour des applications graphiques, on peut installer des applications depuis flathub avec flatpak (via "Logiciels" sous Gnome) et restreindre les droits avec flatseal.

Mais on se rapproche des conteneurs, avec leur principal défaut : ils embarquent leurs dépendances, donc si une faille touche une librairie partagée, type openssl, il faut attendre que l'empaqueteur de chaque application qui l'embarque mette à jour sa librairie (ou, s'agissant de flatpak, la version de la plate-forme sur laquelle il repose).

Cette faille combine des caractéristiques qui la rendent dangereuse :

• elle n'est pas sur un logiciel lui-même, mais sur une bibliothèque
• elle rend vulnérable la plupart des logiciels qui utilisent cette bibliothèque, avec une surface d'attaque assez importante et difficile à circonscrire (= toute chaîne contrôlée par l'attaquant susceptible de se retrouver dans les logs d'une façon ou d'une autre)
• si j'ai bien compris, dès que l'attaquant peut soumettre une chaîne, il a le choix entre plusieurs vecteurs d'attaque : ldap, dns ou autre (les exploits actuels et les réponses se concentrent sur ldap)
• c'est une dépendance java, donc liée statiquement et pas dynamiquement dans les logiciels (contrairement à une faille openssl qui est patchée une fois pour toute sur nos Linux en mettant à jour le paquet RPM ou DEB)

Le délai de correction sera donc assez long : il faut que la bibliothèque soit mise à jour puis que chaque logiciel qui l'utilise soit mis à jour (sachant qu'une partie de ces logiciels ne sont de toute façon plus maintenus !)

Pour se protéger en attendant que ça soit correctement patché quelqu'un de plus compétent que moi m'a proposé d'ajouter le drapeau suivant sur les lignes de commande : -Dlog4j2.formatMsgNoLookups=true (je n'ai pas testé si ça avait un impact réel ou non).

Cet exploit incite à la sobriété numérique dans les développements : il repose sur une fonction qui est déployée partout mais pour laquelle on a trouvé aucun exemple public d'utilisation légitime :

This feature is not used as far as we've been able to tell searching github and stackoverflow, so it's unnecessary for every log event in every application to burn several cpu cycles searching for the value.

source : bugtracker log4j

Pareil, je pige pas trop: c'est un truc qu'on peut chopper ou c'est systemd lui-même qui est en cause?

De ma lecture de l'article, ce n'est pas systemd qui est en cause : dans la partie "persistence", ils indiquent qu'il se démarre comme service systemd (ou via un script d'init pour les autres init).

C'est simplement qu'ils ont nommé le virus "systemd-daemon", ce qui est malin pour tromper l'administrateur peu averti, qui n'y fera pas attention.

Du coup, il me semble qu'il faudrait corriger le titre du lien ci-dessus, qui me semble inexact.

Si la censure se fait via les résolveurs DNS des FAIs je vois pas en quoi DoH change quoi que ce soit.

Précisions :

1. Tous les FAI ne sont pas soumis à la censure, seuls les 4 plus gros le sont (ce qu'explique @pbeyssac)
2. En pratique, les FAI contrôlent les box et autoconfigurent leurs DNS sur la box, puis ces box indiquent (via DHCP) aux clients d'utiliser la box comme proxy DNS. Mais ça va configurer le système d'exploitation. Dns-over-HTTPS est déployé sur Firefox à titre expérimental avec une autre configuration par défaut : c'est le résolveur de cloudflare qui est présent par défaut. Et ça ne concernera que les requêtes DNS provenant de Firefox.

Oui, il est toujours possible de passer la censure outre si on sait ce qu'est un résolveur DNS. C'est une différence notable avec des situations de censures plus brutales (Russie ? Chine ? Iran ?)

@pbeyssac en parlait justement sur twitter hier.

En résumé : en France, la censure d'internet est ordonnée par la police (terrorisme), l'Arjel (jeux en ligne) et la justice (partage de la culture et des connaissances), via les résolveurs DNS des FAI.

Mais le gouvernement est confronté à la montée en puissance du DNS over HTTPS et se demande comment réagir : demander aux nouveaux résolveurs par défaut des navigateurs (Cloudflare…) de censurer aussi ? Interdire DoH ?

nginx fait proxy mail : ça doit correspondre à ton cas d'usage.

En même temps, ce n'est pas parce que Google est l'auteur du navigateur qu'on utilise qu'il est légitime à espionner les sites qu'on visite. Actuellement, il le fait, mais c'est tout à fait discutable.

Cf. Google’s Privacy Sandbox—We’re all FLoCed (qui était passé dans les liens récemment) :

But to the typical consumer, the first party is not the web browser they are using, but the web site they are visiting. Think of it this way. When I call my dad using Verizon, I assume my dad and I are the only people in the conversation. The two of us are the first parties. I did not call my dad and Verizon; there aren’t three of us on the call. But under Google’s rules, Verizon is a first party to the call, and they should be able to advertise to us based on the restaurants or movies—or health or financial issues—we discussed on our call.

So let’s follow the phone call analogy to the web. Let’s say I sit down and “call” the New York Times using my Chrome web browser—HTTP instead of my phone. Here, the consumer considers the New York Times a first party—just like when I call my dad. The New York Times also considers the consumer its first party (i.e. customer). It’s ridiculous to consider Google a first party to this interaction just because I am using Chrome, even if the New York Times hires Google to place ads or track analytics on its website. Google, just as Verizon, is just a service provider. Google could ask consumers for opt-in consent to be treated as a first party, but consumers are as likely to do that as they are to consent to Verizon listening in to their phone calls. So, Google just anoints itself a first party anyway. After all, it’s Google’s sandbox.

Bonjour,

Je t'invite à regarder les fichiers de configuration de php-fpm que tu trouveras sous /etc/php/7.0/fpm/ (sous Debian, mais peut-être sous /etc/php-fpm ailleurs … ou un truc du genre).

Là, tu pourras trouver sous quel utilisateur php-fpm lance les scripts et où il stocke ses journaux (chez moi - Debian - c'est le fichier /var/log/php7.3-fpm.log). Là aussi, consulter le journal te donnera plus d'informations.

Sur le problème de droits d'accès, vérifie aussi les répertoires parents de .../nextcloud : il faut que www-data ait les droits rx sur chacun des répertoires parents.

Bon courage !

Sur ma Debian, mariadb écoute en local par défaut. Dans le fichier /etc/mysql/mariadb.conf.d/50-server.conf, j'ai :

# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
bind-address            = 127.0.0.1

[...]
# * Security Features
[...]
# For generating SSL certificates you can use for example the GUI tool "tinyca".
#
#ssl-ca = /etc/mysql/cacert.pem
#ssl-cert = /etc/mysql/server-cert.pem
#ssl-key = /etc/mysql/server-key.pem
#
# Accept only connections using the latest and most secure TLS protocol version.
# ..when MariaDB is compiled with OpenSSL:
#ssl-cipher = TLSv1.2
# ..when MariaDB is compiled with YaSSL (default in Debian):
#ssl = on

Par contre, avec YaSSL on est limité à TLSv1.1 et Debian utilise YaSSL depuis 2014, suite à des embrouilles de licence autour d'OpenSSL 😐 .

Dans quel cas de figure un serveur de base de données serait exposé depuis internet ?

Dans le cloud Azure proposé par Microsoft, c'est l'option par défaut :

• la base de données sur le cloud Azure SQL Database, exposé sur tout internet
• l'application sur le cloud "web apps"

L'authentification entre les 2 se fait soit via mot de passe, soit via authentification Azure Active Directory (exemple en .net). Dans cette dernière situation, la gestion des droits d'accès se fait dans l'Active Directory du cloud.

Sans fail2ban et sur le port 22, j'ai un nombre environ 2 fois plus élevé de tentatives de connexions. Sur la moitié du mois de février 2021 (du 7 au 22), j'ai 10478 tentatives dont :

• 733 admin
• 493 user
• 349 support
• …

J'imaginais que l'effet de fail2ban serait plus massif que ça. Avec/sans on semble être dans un rapport de 1 à 2.

De mon côté, l'authentification par mot de passe est désactivée.

Nginx aussi démarre en root. Et c'est plutôt normal sous Linux vu que c'est un prérequis (la capability CAP_NET_BIND_SERVICE), par défaut, pour avoir accès au port 80.

Ça n'est pas obligé. Il y a un hack non documenté qui permet de faire de l'activation par socket avec systemd et donc de le faire tourner sous utilisateur non privilégié.

Mon fichier nginx.socket :

[Unit]
PartOf=nginx.service
[Socket]
# fd: 3
ListenStream=80
# fd: 4
ListenStream=0.0.0.0:80
# fd: 5
ListenStream=443
# fd: 6
ListenStream=0.0.0.0:443
BindIPv6Only=ipv6-only

Mon fichier nginx.service :

# On a besoin de nginx.socket pour ouvrir les ports et les envoyer à nginx
[Unit]
After=nginx.socket
Requires=nginx.socket
[Service]
PIDFile=/run/nginx/pid
ExecStart=/usr/sbin/nginx -g 'daemon on; master_process on;'
ExecStop=-/sbin/start-stop-daemon --quiet --stop --retry QUIT/5 --pidfile /run/nginx/pid
TimeoutStopSec=5

Environment=NGINX=3:4:5:6:
NonBlocking=true

User=www-data
# Puis plein d'options de confinement avec systemd : NoNewPrivileges=true, CapabilityBoundingSet=, ...

Puis le fichier nginx.conf :

http {
        server {
            # Les directives listen ci-dessous sont assez fictives : en réalité, nginx va écouter
            # sur des "file descriptor" (fd) passés en paramètre (cf. /etc/systemd/system/nginx.socket)
            listen [::]:80 default_server; # fd: 3
            listen 80 default_server;      # fd: 4
            #[...]
        }
        server {
            listen [::]:443 ssl default_server; # fd: 5
            listen 443 ssl default_server;      # fd: 6
            #[...]
        }
}

Le seul truc qu'on perd, c'est systemctl reload nginx : ça n'est pas possible car dans ce cas le nginx oublie les "file descriptors" en entrée et tente d'attraper les ports, il ne peut pas. Il faut donc faire restart à chaque fois.

Page 24 du rapport, on trouve les recommandations suivantes :

• "Mettre à jour les applications"
• "Limiter l'exposition Internet des outils de supervision" -> "ne pas exposer les interfaces web de ces outils sur Internet ou restreindre l’accès à celles-ci en mettant en œuvre des mécanismes de sécurité non applicatifs (certificat client TLS, authentification basic par le serveur web)."
• "Renforcer la sécurité des serveurs" -> "le profil Renforcé du guide de RECOMMANDATIONS DE CONFIGURATION D’UN SYSTÈME GNU/LINUX".

Ce dernier document est une bonne ressource quiconque souhaite sécuriser sérieusement un serveur (au-delà de la configuration de base qui est, souvent, déjà assez bonne).

Est-ce qu'on peut migrer de Debian classique vers Yunohost ?

Oui ! Ça peut s'installer comme surcouche après avoir installé une Debian basique.

Par contre, dans ce cas il faut choisir Debian buster (stable). La migration sera a priori aisée vers bullseye (yunohost se charge de migrer les applications et tout ce qu'il faut au moment où tu lui demandes).

Bonjour,

Si tu envisages d'installer nextcloud, je te conseille Yunohost : c'est une Debian avec une surcouche de gestion d'applications, parmi lesquelles on trouve nextcloud. Ça limite grandement les étapes d'installation, donc les erreurs possibles.

À défaut, il me semble que Debian est une bonne base pour la sécurité sur le temps long : tant que tu restes avec des applications qui sont sur les repository officiels, tu as assez peu de risques de voir ton système cassé en cas de montée de version. Pour l'immédiat, je te conseille d'installer Bullseye, l'actuelle testing qui devrait être stabilisée dans l'année, ça t'évitera d'avoir à faire la montée de version de Buster (supportée jusqu'à juillet 2022) à Bullseye.

Avec Debian, il faut penser à installer la mise à jour automatique des paquets.

Bon courage !

La liste est bien trop longue pour avoir une pertinence sur la prise de décision; et si tu te limites aux briques principales, tu risque de zapper celle qui sera à l'origine de la faille (récemment sudoedit, pas certains que sudo fasse partie des briques que tu aurais listé spontanément)

Ça permet justement de mettre en valeur l'intérêt d'une distribution GNU/Linux. Écrire "Debian 10 Buster (apache 2.4.38, PHP 7.3, mariadb 10.3)", c'est affirmer que tu suis la distribution Debian (et les mises à jour) sur ces paquets, donc que tu es autant à jour que la distribution Debian 10, ce qui est tout à fait bon jusqu'à juillet 2022 (d'où l'intérêt du lien vers la page release). Préciser PHP7.3 permet de signaler au lecteur attentif qu'il y a un choix fait de suivre la politique Debian (tenter de maintenir la version PHP toute la durée de vie de la distrib, même quand cette version n'est officiellement plus supportée, en backportant les patchs de sécurité), mais il est possible de lister PHP en-dehors de Debian 10 si on fait les mises à jour autrement (backports, sury ou autre).

En pratique, sous réserve de mettre en place les mises à jour automatiques, pas mal de projets peuvent donc lister uniquement 1 composant : la distribution employée et sa version (bien qu'il soit plus pertinent de préciser les 2-3 principales* applications installées depuis les dépôts Debian). Celles qui nécessitent une application qui n'est pas fournie par la distribution doivent ajouter cette application au premier niveau.

Pousser les gens à changer de logiciel perce qu'une brique n'a pas eu besoin d'évoluer depuis longtemps risque de les pousser vers des solutions moins testées, voir permettre à des gens de se spécialiser dans le renouvellement des briques pour y rajouter des trucs indésirables;

L'idée est de pousser les gens à aller vers des solutions maintenues.

Assez rapidement, le décideur se rend compte qu'un logiciel stable est moins coûteux qu'un logiciel tout récent : on privilégiera Ubuntu LTS à la dernière version, RHEL à Fedora, un noyau LTS à celui le plus récent, etc.

Enfin, en tant que développeur (open source depuis peu :P) je suis incapable de te donner une date pour les biques que je code.

Il est très difficile de garantir une "durée de maintenance", on ne peut pas faire ça tout seul. Il faut une organisation (entreprise ou communauté) pour rendre effective cette garantie dans le temps. Et cette contrainte pousse à automatiser les processus (mises à jour, tests, rebuilds,…), ce qui est une bonne chose.

C'est l'enjeu de cette proposition: rendre ces questions "plus visibles". Pas en définissant une mesure 100% objective mais en donnant un indicateur lisible (bien qu'imparfait - même les produits non périmés peuvent faire l'objet de rappels).

D'autres l'ont eu avant moi. De façon analogue, Kyle Rankin, de purism, fait remarquer que la signature des packages d'une distribution Linux est analogue à la fermeture avec le "plop" de ton pot de confiture, il garantit que personne n'a altéré le produit entre l'usine et chez toi. Par contre, ça ne protège pas contre une infection qui a lieu à l'usine elle-même. Pour ça, il n'y a pas d'arme magique mais la transparence apportée par l'aspect "libre" du logiciel et les reproducible builds permettent d'avancer dans la bonne direction.

Salut,

Les "checks" réseaux/système et l'analyse des journaux visent le même objectif (maintenance préventive via détection de problèmes le plus tôt possible), sont assez proches ("évènements", "dans le temps") mais ont une différence fondamentale :

1. les checks/vérifications se font sur une base régulière (surveillance "quasi-continue" de l'état du service)
2. les journaux lèvent des alertes ponctuelles, liées à des évènements particuliers

La relation qu'il peut y avoir entre les deux, c'est de 1 vers 2 : un check qui échoue lève une alerte dans les logs. Il ne "reste" alors plus qu'à surveiller les logs, c'est-à-dire :

• les rassembler (rsyslog, systemd-journal-remote, ELK pour des besoins plus complexes)
• les présenter de façon accessible et "cherchables". En CLI, journalctl fait le job, en GUI, systemd-journal-gatewayd est un peu fruste mais j'en propose une nouvelle version (sans succès pour le moment).
• alerter, à partir de là (mail, SMS, ce que tu veux) en fonction de la gravité de l'alerte. Un premier niveau sans doute assez simple serait de lever une alerte pour les évènements de criticité 0 (emergency) à 4 (warning), puis mettre en place une whitelist d'alertes mineures pour ne pas lever trop d'alertes.

Je me suis justement lancé il y a quelques jours dans l'écriture d'un journal sur "la supervision" (métriques, checks, journaux). Mais les urgences font que ça attendra sans doute un peu.

EDIT : ah, et il y a un aspect sur lequel je ne réponds pas. Centreon, je ne sais pas, mais les nagios-like permettent de "checker" des choses qui ne sont pas des métriques. Par exemple: tel port est-il ouvert ? Tel certificat TLS est-il valide ? (date ? autorité ? sujet ?)
Prometheus part de l'idée que "tout est métrique", et on lève des alertes à partir de là. À mon sens, c'est une erreur (on peut certes convertir un état "on/off" en métrique 0/1, mais c'est vouloir adapter la réalité de ce qu'on fait à l'outil ou l'idée qu'on a sous la main plutôt que l'inverse).

Salut,

Je ne connais pas logstash, mais je connais un peu systemd : il dispose d'un système de templates (modèles) permettant de faire quelque chose comme :

$ cat /etc/systemd/system/my_cmd@.service
[Service]
ExecStart=/usr/bin/my_cmd --foo %i

$ sudo systemctl start my_cmd@bar1.service
$ sudo systemctl enable my_cmd@bar2.service --now

etc.

Ça fait bien ce que tu imagines : ça démarre une instance du service avec le paramètre bar1, puis en installe une autre avec le paramètre bar2.

Et tu peux faire la même chose avec des timer, pour des appels réguliers.

Salut,

Je ne suis pas sûr de comprendre : est-ce l'invité (Ubuntu) qui ne doit pas avoir de GUI ou l'hôte (Debian) ?

Si c'est l'invité, tu peux utiliser la solution de virtualisation que tu veux : au moment de l'installation, tu désactives l'environnement de bureau (installation serveur), ou tu utilises directement ubuntu server, qui n'installe pas d'environnement graphique par défaut.

Si c'est l'hôte (Debian), tu peux installer libvirt-daemon puis gérer en ligne de commande avec virsh ou à distance, depuis un autre ordinateur, avec virt-manager (fichier > ajouter une connexion > cocher Connect to remote host over SSH).

Merci pour la découverte de rbw ! Je suis content de voir qu'il existe un client alternatif, qui ne soit pas développé par Bitwarden, inc. Ça me rassure quand à la sécurité et la résilience de l'ensemble.

J'avais hésité à héberger une instance familiale de bitwarden_rs avec yunohost, mais je ne l'ai pas fait pour des raisons de sécurité. La sécurité du client web de bitwarden est au maximum la sécurité du système qui l'héberge : si mon serveur se retrouve compromis d'une façon ou d'une autre, l'attaquant aura la possibilité de modifier le code envoyé aux clients de façon à exfiltrer les mots de passe.

Le même problème se pose pour le client web officiel, mais je fais davantage confiance à bitwarden inc. pour sécuriser très solidement leurs serveurs.

Du coup, ton expérience m'intéresse : as-tu pris en compte cette question de sécurité ? As-tu mis en place des défenses plus spécifiques ?