Samuel a écrit 144 commentaires

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 ?

La commande pour afficher les règles du pare-feu avec nftables :

# nft list ruleset

On trouve plein d'infos dans le wiki de nftables. Par contre, je ne vois pas comment/où une telle limite serait appliquée !

Et surtout, tu peux facilement scripter un test qui sera lancé par nagios (ou système compatible, comme icinga2 que j'utilise pour cet usage).

Le test doit simplement afficher une ligne de résultat et retourner un code d'erreur entre 0 (OK) et 3 (état inconnu). Cf. la documentation "plugin API" de Nagios.

Ce contenu a déjà été lié ici même.

Sinon, vu que tu es sur un cloud, pourquoi ne pas avoir ajouté un second disque durant la manip ?

Je n'ai pas été très précis : c'était pas un cloud, mais un serveur privé virtuel. Il était possible de commander un disque supplémentaire, mais l'idée était aussi de faire l'opération à moindre coût (sans achat supplémentaire).

Et pour info, un fdisk sur un device lvm est inutile sauf pour un disque de boot. C'est même problématique lorsque tu le fais sur des LUNS d'un SAN que tu veux agrandir.

Peux-tu développer ? Ici, c'est un disque virtuel que l'hébergeur met à ma disposition, donc j'imagine bien qu'il y a un LVM en-dessous (ou toute autre techno du genre). C'est "gênant" dans ce cas ?

Est-ce que tu es simplement en train de dire que la fonction "table de partition" est redondante avec les fonction de gestion d'espace avec LVM ?

Mais ici comme j'ai voulu mettre du LVM: la table de partition m'a permis de créer l'espace LVM sur la deuxième moitié du disque (vgcreate vg-data /dev/sdb2), copier les données sur le volume créé sur cet espace, ajouter la partition sur la première moitié du disque (fdisk) et l'ajouter à l'espace LVM (vgextend vg-data /dev/sdb1) pour pouvoir utiliser les 50Go. Donc j'empile effectivement LVM sur une table de partition. Aurait-il été possible de faire la même opération sans table de partition ?

Hello,

ddrescue, dd_rescue, myrescue : récupérer ses données après un crash disque : cet article est très complet et pédago sur les solutions de récupération de données. Je m'en suis servi plusieurs fois !

Chouette initiative !

Mais j'ai pas compris le sens de l'affiche : tu es pour ou contre le télé-travail permanent ? Le point d'exclamation semble dire que tu y es favorable, mais le sous-titre #PlusJamaisCa semble dire le contraire. Je suis perplexe.

J'ai dû aussi me mettre à niveau sur les flux de travail git (première question), c'est-à-dire la façon d'organiser et présenter l'historique de ton code. Ces 2 ressources éclairent un peu les choses :

• Introduction to gitlab flow : différentes façons (git flow, github flow) avant de présenter celle qu'ils préconisent (gitlab flow)
• Clean and linear history with GitLab, en contrepoint : vante un flux permettant un historique linéaire (ce qui semble plus adapté pour des "petits" projets ou organisations).

Après, une fois que tu as choisi ta politique, tu trouveras de l'aide sur les différentes commandes git pour les mettre en œuvre (branch, rebase, merge…).

Je viens de tester : Quicksy est très bien, en effet ! Il facilite l'entrée dans XMPP.

Cependant, à cause d'Omemo, la compatibilité est assez mauvaise avec les autres clients web. Movim ne supporte pas omemo, j'ai pas réussi à faire fonctionner pidgin et quicksy, et converse.js supporte omemo mais pas le transfert de fichier (qui est une fonction assez importante pour nous).

Je crois qu'on va en rester à kiwi IRC. Je regrette l'absence d'application native android user-friendly et la difficulté à faire du partage de fichier.

Remarque : Windows permet facilement de redimensionner la partition sur laquelle il est installé, libérant la place nécessaire pour installer Linux sur le disque à côté. L'outil pour faire ça s'appelle diskmgmt.msc.

A priori, tu n'auras donc pas besoin de réinstaller Windows.

Par contre, il faut faire attention lors de l'installation de Linux à ne pas effacer de partitions, pour bien laisser Windows à sa place! L'installeur détectera automatiquement la présence de windows et grub te laissera le choix au démarrage de lancer Linux ou Windows.

Le courrier que j'ai envoyé :

Bonjour monsieur, madame

Si cette adresse mail est professionnelle, c'est aussi une donnée personnelle selon la définition de l'article 4 de la réglementation générale sur protection des données, et à ce titre protégée par cette réglementation.
Votre message consiste est ainsi un "traitement" (défini dans le même article) et témoigne de l'existence probable de plusieurs "traitements" préalables relatifs à des données personnelles me concernant (au moins nom et adresse e-mail).

Dès lors, sauriez-vous m'indiquer :

• les données sur ma personne que vous avez en main
• les finalités du traitement automatisé de mes données
• les conditions de licéité de ce traitement (conditions définies à l'article 6 de la réglementation) et les éléments vous permettant de juger qu'elles sont remplies
• les destinataires ou catégories de destinataires auxquels mes données à caractère personnel ont été ou seront communiquées,
• quelle source vous a transmis mes données personnelles

Je vous demande en outre de supprimer toutes les données me concernant de votre base.

Je vous remercie du soucis que vous accorderez à la protection de mes données et au respect des lois en vigueur.

Bonjour,

Suite à un spam reçu récemment, j'ai envoyé un courrier à l'expéditeur demandant :

• la copie des données qu'ils détiennent sur moi
• sur quelle base légale ont-ils collecté et utilisent-ils mon adresse mail (qui est une donnée personnelle au sens du RGPD)
• par quel biais ils ont obtenu mon adresse mail
• et bien entendu, l'effacement des données me concernant

Tout cela est prévu par le RGPD.

Résultat, j'ai reçu un mail dans l'heure avec les données me concernant + un lien vers une page de la cnil précisant que les adresses mail pro peuvent être collectées sur la base de l'opt-out, mais pas de réponse sur le reste, le mail venant d'un acteur tiers que je ne connaissais pas (probablement le "data-broker" qui a revendu mon adresse à la boîte qui me sollicitait). J'ai renvoyé un mail rappelant mes demandes et demandant qui avait collecté cet email et à quel moment cet acteur m'avait mis en mesure de m'opposer à la réutilisation cette info, n'ayant aucun souvenir de ça.

Résultat, j'ai été rappelé une demi-heure plus tard par une personne m'expliquant que ce qu'ils faisaient était légal et qu'il n'y avait pas de soucis, il me désinscrivait. Il avait l'air inquiet. Du coup, ça vaut le coup de tenter de temps en temps, comme mesure d'intimidation vis-à-vis de ces gens !

J'avoue n'avoir aucune idée de comment traduire les messages de scripts… en C, je sais faire, mais en sh? Ceci est un appel à bonne âme: un journal sur comment traduire du script serait plussé par au moins moi :)

S'il y a peu de chaînes de caractères, on peut se contenter de définir un fichier shell par langue, chacun exportant les variables contenant les chaînes de caractères dans une langue particulière, puis au moment de la conception de l'initrd copier la langue voulue dans l'image.

en_US.UTF-8.sh :

CUW_PLEASE_UNLOCK="Please enter passphrase for unlocking %s"

fr_FR.UTF-8.sh :

CUW_PLEASE_UNLOCK="Merci d'entrer la phrase de passe pour déverrouiller %s"

Puis dans le script générant la page web :

. /lib/cryptroot-unlock-web/strings.sh
[...]
printf "<div>$CUW_PLEASE_UNLOCK</div>" "$MY_DEVICE_TO_BE_UNLOCKED"

Blague à part, systemd impacte vraiment l'initrd? Pour dracut, il me semblait que c'est juste un système de de build, une sorte d'autotools spécialisé, et clevis, je connais pas.

systemd peut se charger de déverrouiller un périphérique et chercher le programme approprié pour récupérer le mot de passe auprès de l'utilisateur si besoin. On pourrait imaginer ajouter un "provider de mot de passe" consistant en ce petit serveur. Par contre, un initrd n'embarque a priori pas systemd, donc je ne sais pas si c'est pertinent de chercher dans cette direction.

clevis est un système générique pour déverrouiller des choses, avec plusieurs mécanismes pour stocker/récupérer le secret voulu. Parmi ces mécanismes : sss (Shamir secret) pour diviser le secret en plusieurs bouts, tpm2 pour stocker la clé sur un module matériel dédié à la protection des secrets (Hardware security module), tang consistant à verrouiller le secret par une clé présente sur un serveur, permettant de faire en sorte que le déverrouillage ne se fasse que si l'ordinateur est sur le réseau avec ce serveur (network-bound disk encryption). Clevis est notamment utilisé pour déverrouiller des disques LUKS dans des initrd générés par dracut (cf. par exemple clevis-dracut dans Debian).

À vrai dire, c'est un tout petit prototype et je n'ai pas le temps d'améliorer pour le moment. Ce qui manque, au minimum :

• faire fonctionner TLS (sinon, c'est clairement dangereux !)
• packager pour Debian

Ensuite, dans une optique d'utilisabilité plus large il faudrait :

• (pour les utilisateurs) permettre de traduire les messages automatiquement
• (pour les utilisateurs) implémenter un code javascript qui lit la clé depuis l'URL (la clé serait placée après un #, à la fin de l'URL) : ça permettrait de confier la clé de déchiffrement sous forme d'un simple lien (qui serait lui-même proposé dans un document HTML, PDF ou ce que tu veux sur une clé USB confié au "gardien du secret")
• (pour les administrateurs) utiliser une solution plus générique pour la configuration de l'initrd (dracut, clevis ou systemd-*). Chacune de ces solutions aboutit à une proposition d'architecture assez différente.

J'ai fait une version basique avec un routeur sous openwrt récemment, c'est assez facile !

Voici la recette:

• Une box OpenWRT avec 3 ports : un pour contrôler la machine (« LAN » client DHCP, port SSH ouvert), deux pour s’intercaler sur le lien réseau qu’on veut écouter (si on veut écouter A ↔ B, on place la box C entre les 2 : A ↔ C ↔ B, ça nécessite un câble de plus).
• Installer tcpdump sur la box
• Le port de contrôle : zone = LAN / INPUT = ACCEPT / OUTPUT = ACCEPT
• Le port d’espionnage : zone = WAN / INPUT = DROP / OUTPUT = DROP / FORWARD = DROP (pas sûr que ça soit nécessaire)
• Le port d’espionnage = interface bridge sur les deux interfaces (eth1 / eth2 ou whatever), protocol = unmanaged / cocher force link et décocher « use builtin IPv6 management » (ça évite d’émettre des trames réseau) / assign zone = wan.

Puis la configuration de /etc/config/network :

config interface 'lan'
        option ifname 'eth0'
        option proto 'dhcp'

config interface 'wan'
        option type 'bridge'
        option proto 'none'
        option ifname 'eth1 eth2'
        option delegate '0'
        option force_link '1'

(selon les modèles, c'est parfois eth0.1 et .2 qu'il faut indiquer plutôt que eth1/2)

Et celle de /etc/config/firewall :

config defaults
        option syn_flood '1'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'

config zone
        option name 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        option network 'lan'

config zone
        option name 'wan'
        option input 'DROP'
        option output 'DROP'
        option network 'wan6 wan'
        option forward 'DROP'

Pour écouter, y'a plus qu'à se connecter SSH sur la machine et faire : tcpdump -i br-wan -o mon-ecoute.pcap, puis récupérer et ouvrir ce fichier avec wireshark. Comme le fichier grossit rapidement, il vaut mieux faire ça pas trop longtemps et sur une clé USB, ou envoyer ça directement sur le réseau et le récupérer sur une autre machine)

Bon, pour intégrer burp ou mitmproxy, c'est sans doute un peu plus de travail. Il est possible d'installer python sur openwrt, donc mitmproxy doit pouvoir l'être aussi.

Note que dans cette configuration, la box est "indétectable" par le réseau qu'elle espionne. Si cette fonctionnalité ne t'es pas nécessaire car tu la mets sur le même réseau que le lien que tu veux débugger/surveiller, tu peux simplifier la configuration et mettre une seule interface "br-lan", client DHCP et accès INPUT/OUTPUT ouvert. Mais il faudra alors soit ajouter des filtres pour la capture tcpdump, soit écrire la capture dans un fichier mais pas l'afficher dans ta session SSH ou l'envoyer sur le réseau car sinon tu crées une boucle qui explose très très vite :) .