Samuel a écrit 144 commentaires

J'aime bien aussi ce qu'elle en fait avec redbean, qui est à la fois:
- un fichier zip dans lequel on peut mettre, par exemple, des scripts JS, des pages HTML, du CSS, des scripts LUA
- un exécutable compilé contre la cosmopolitan qui fait serveur web et exécute les scripts LUA que vous voulez en réponse aux requêtes. Ça embarque sqlite en bonus si vous voulez faire du travail avec une BDD.

Du coup, vous remplissez le zip avec votre webapp et vous la mettez à disposition soit des clients finaux (-> ça fait une alternative lightweight à electron), soit sur un serveur quelconque (-> ça fait une alternative lightweight à Docker pour une part significative des usages de celui-ci).

Des critiques de l'agilité cryptographique (par exemple Against Cipher Agility in Cryptography Protocols, paragon IE, en), je retiens surtout la proposition d'utiliser des protocoles versionnés, par exemple dans la présentation de paseto, un concurrent à JWT/Jose (en) :

• chaque version vient avec une seule combinaison d'algorithmes réputée sûre
• si un problème est identifié sur l'un des algos ou sur leur articulation, on change ce qu'il faut et on incrémente la version du protocole

Ça représente une forme de souplesse cryptographique (= on peut déprécier un algo) sans laisser l'utilisateur final se tirer une balle dans le pied.

Every modern web service implements a session with a user after successful authentication so that the user doesn’t have to be authenticated at every new page they visit.

Une alternative consiste à authentifier la connexion plutôt que la session, via des certificats TLS. En plus, ça rend le phishing inopérant: une réponse valide pour attacker.tld n'est pas valide pour company.tld, donc attacker.tld ne peut pas se servir de la connexion obtenue par phishing pour se faire passer pour la victime auprès de company.tld.

L'authentification par certificat peut être à 2 facteurs si on protège la clé privée par mot de passe ou code pin.

Certains, comme Armin Ronacher se sont élevés de façon véhémente contre cette nouvelle obligation imposée aux développeurs bénévoles, qui se voient "punis" d'avoir partagé gentiment leur création.

James Bennett lui répond qu'il faut être singulièrement asocial pour refuser un geste simple qui permet de limiter les risques pour tout le monde.

Le débat n'est pas sans rappeler d'autres controverses politiques actuelles, avec peu ou prou les mêmes questions en toile de fond (qui doit imposer quoi ? au bénéfice de qui ? qui est "nous" ?)

Il y a les commandes disponibles par défaut: CPU, mémoire, espace disques.
Et il y a les plugins qui sont sur la machine cliente et écris par un admin ou quelqu'un d'autres.

Du coup le serveur ne peut pas reconfigurer l'agent ou lui faire exécuter une commande arbitraire, exact ? (sauf plugin mal écrit…)

La communication est cryptée avec comme version SSl par défaut: ssl_version = TLSv1_2

Merci de la précision ! Mais du coup, ça nécessite d'avoir une autorité de certification interne (ou d'en créer une pour cet usage), exact ?

Merci pour cette présentation !

J'ai quelques questions qui me restent, notamment au regard des dégâts qu'ont pu avoir la faille solarwinds où un logiciel de supervision compromis permettait à l'intrus de prendre le contrôle de la totalité du parc :

• si je comprends bien, la supervision peut faire exécuter au système supervisé des commandes arbitraires (dans le but de remonter des infos), exact ?
• Avec quels privilèges l'agent exécute-t'il ces checks ?
• les échanges entre la supervision et l'agent semblent authentifiés par la "community string". Est-ce la même pour tous les systèmes supervisés ? Du coup, un système supervisé X peut interroger de la même manière son voisin Y supervisé lui aussi ?
• Ces échanges sont-ils chiffrés ? i.e. un attaquant qui snifferait le lien ethernet peut-il extraire la community string ?

Oui, c'est la même source qui témoigne dans Fakir et qui a répondu à Mediapart.

Sur Mediapart, on trouve aussi une explication du ménage qu'ils ont fait dans la section participative du site (a priori en accès libre).

K9mail. Je le trouve moins pratique, mais il est libre aussi.

En réalité, vu que le code Javascript qui réalise les opérations cryptographiques dans le navigateur du client vient des serveurs de ProtonMail, il faut tout de même leur faire confiance pour ne pas t’envoyer une version qui exfiltre ta phrase de passe…

C'est un problème que rencontrent toutes les solutions avec du chiffrement de bout en bout qui offrent une appli web (protonmail, matrix, bitwarden, etc.) : si un pirate prend le contrôle d'un serveur qui te sert l'app (ou se place en homme du milieu entre le client et le serveur), il peut servir un JS vérolé et récupéré les secrets.

Sais-tu si des gens commencent à travailler à traiter correctement cette difficulté ?

A priori, il serait assez simple de signer le code JS avec GPG, puis de "pinner" une association clé GPG / site distant pour indiquer aux les navigateurs de n'exécuter du code depuis ce site X que s'il est correctement signé, mais je n'ai pas connaissance de réflexion ou de début de mise en œuvre.

(Se pose bien évidemment la question de la distribution de l'info "tel site requiert telle clé publique", et on retombe soit sur la PKI du web avec tous ses défauts, soit sur du TOFU, soit sur des listes préchargées, soit une autre solution à inventer).

Attention, contrairement à ce que la présentation de l'article peut laisser entendre, seul la première partie ("L’intégralité du commentaire de l’OSI") est la traduction du communiqué de l'OSI : Open source ‘protestware’ harms Open Source.

Les parties suivantes, qui parlent de la version Notepad++ baptisée "free uyghur", ne sont pas issues du texte de l'OSI (et sont, j'imagine, l'œuvre de l'auteur de l'article indiqué sur developpez.com, Patrick Ruiz).

Ta demande couvre plusieurs aspects de la supervision :

• la remontée de métriques (= mesures en continu, discrétisé par le temps)
• la remontée de logs (= évènements ponctuels)

En général, on veut aussi un système de vérification d'état (faire des "checks" réguliers sur les métriques et/ou les logs remontés, ou vérifier à distance que le serveur web répond bien, que le certificat n'est pas trop proche de l'expiration).

Côté métriques, tu as plusieurs écoles : telegraf/influx (mode push, supervisé -> superviseur), prometheus (mode pull), collectd avec rrd ou graphite (mode push). Dans tous les cas, la visualisation se fait souvent avec grafana. Mon option favorite, c'est collectd pour la collecte et l'envoi de métriques (installé sur les "supervisés"), graphite pour le stockage et grafana pour la visu (installés sur le superviseur). Influx est plus efficace que graphite pour le stockage des métriques, mais il rend beaucoup plus difficile l'échantillonage (passer d'une résolution de 1 mesure / minute sur les dernières 24h à 1 mesure / heure sur le dernier mois, puis 1 mesure / jour sur un an). Je préfère le "push" au "pull" pour des raisons de sécurité : je ne souhaite pas que mon système de supervision ait un accès privilégié d'une façon ou d'une autre aux autres machines (sinon, ça fait un SPOF d'un point de vue sécu).

Collectd permet de récupérer les infos via ipmi si tu ne souhaites pas utiliser sensors.

Pour l'émission d'alertes et la composition d'un tableau de bord "ce qui va / ce qui va pas", j'utilise icinga2, un nagios-like. On peut interroger graphite à partir d'icinga2 pour "surveiller" les métriques. Comme je suis devOps, j'envoie mes alertes dans gitlab.

Pour la remontée de logs, je m'appuie sur systemd-journal-upload et -remote mais j'ai rencontré une fois un bug provoquant une inflation inutile de l'espace occupé par les journaux, alors je ne suis pas sûr de le recommander. rsyslog est pas mal, mais tu collectes beaucoup moins d'info que dans le journal systemd.

Ça prend un peu de temps pour configurer ça aux petits oignons, mais ça permet ensuite d'avoir une belle visibilité sur tes systèmes.

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.