Le Blog Utux

HTTP 200 GET /

systemd, c'est bien.

Rédigé par uTux 22 commentaires

Systemd est un système d'init "moderne" qui remplace le vieillissant sysvinit. L'init c'est le premier process qui démarre après le boot et qui va "orchestrer" le lancement des services : réseau, logs, ssh ... Mais wikipedia explique cela mieux que moi.

Dire que systemd a provoqué de nombreuses polémiques et levées de boucliers de la part des utilisateurs est un euphémisme, c'est un beau bazar dans lequel des troll s'affrontent au lance-flammes. On lui reproche de nombreuses choses : réinventer l'eau chaude alors que sysvinit marche bien, être monolithique et donc contraire à la philosophie UNIX, être le cheval de troie de Red Hat pour à terme remplacer de plus en plus de composants dans Linux, ne pas être portable sur les autres OS, etc. Je pense que la plupart des critiques sont vraies et que dans quelques années nos distributions ne seront plus GNU/Linux mais SystemD/Linux. Néanmoins il est intéressant d'observer qu'après 6 ans d'existence, systemd s'est imposé partout à l'exception de Gentoo (+et Slackware) et ce n'est pas par hasard.

Je ne vais pas énumérer point par point les fonctionnalités de systemd, je vais me contenter d'en présenter deux aspects que je trouve intéressants : création d'un service et d'un containers (nspawn).

Création d'un service

Avez-vous déjà écrit des scripts d'init pour un logiciel sur Linux ? Moi oui. Et entre sysvinit et systemd, c'est le jour et la nuit. Prenons pour exemple Nginx :

C'est quand même beaucoup plus simple avec systemd puisqu'une grosse partie du boulot est faite nativement, par exemple la gestion du pid et des logs. Pour sysvinit par contre c'est au développeur du script de prévoir tous les cas, de coder la vérification du pid, des logs, bref c'est long et pas forcément utile puisque même sur Windows on ne fait plus ça depuis 20 ans.

Création d'un container

Systemd est très lié à Linux et aux cgroups, il est possible d'isoler des processus dans leur propre contexte, de là à créer des containers avec une application ou un système entier il n'y a donc qu'un pas qui a été franchit. Pour l'exemple on va créer un container ubuntu-server-16.04 à partir d'une image cloud (pour nous épargner les étapes debootstrap qui n'ont pas vraiment d'intérêt dans cet article) :

root@localhost:~# wget https://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-root.tar.gz
root@localhost:~# mkdir /srv/containers/xenial01
root@localhost:~# tar -xf xenial-server-cloudimg-amd64-root.tar.gz -C /srv/containers/xenial01

Note : sur les versions plus récentes de systemd (non disponible sur Debian Jessie), l'utilitaire machinectl permet de télécharger et déployer une image automatiquement. Voir la section Examples de la documentation machinectl.

Puis démarrer un shell dans le container afin de pouvoir créer un mot de passe root :

root@localhost:~# systemd-nspawn -D /srv/containers/xenial01/
Spawning container xenial01 on /srv/containers/xenial01.
Press ^] three times within 1s to kill container.
/etc/localtime is not a symlink, not updating container timezone.
root@xenial01:~# passwd
Enter new UNIX password: 
Retype new UNIX password: 
passwd: password updated successfully
root@xenial01:~# exit

Maintenant on peut - si on veut - démarrer complètement le container :

root@localhost:~# systemd-nspawn -bD /srv/containers/xenial01/
Spawning container xenial01 on /srv/containers/xenial01.
Press ^] three times within 1s to kill container.
/etc/localtime is not a symlink, not updating container timezone.
systemd 229 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR
+SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ 
-LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN)
Detected virtualization systemd-nspawn.
Detected architecture x86-64.

Welcome to Ubuntu 16.04 LTS!

Ensuite la séquence de démarrage s'affiche et il est possible de se loguer, puis d'arrêter le container avec la commande poweroff :

Ubuntu 16.04 LTS ubuntu console

ubuntu login: root
Password: 
Last login: Mon May 23 09:12:29 UTC 2016 on console
run-parts: /etc/update-motd.d/98-fsck-at-reboot exited with return code 1
root@ubuntu:~# poweroff

Si on ne spécifie aucune option au niveau du réseau, le container utilisera l'interface de l'hôte. Attention donc aux services qui écoutent sur les mêmes ports, typiquement SSH, le mieux est encore d'utiliser une interface réseau virtuelle. Je ne rentre volontairement pas dans les détails afin de ne pas faire un article indigeste, mais il est possible d'aller plus loin notamment au niveau des interfaces réseau (bridge, macvlan, veth), des limitations du système (mémoire, cpus...) ou encore de l'intégration avec SELinux. On peut aussi utiliser debootstrap, dnf ou pacstrap pour créer un container (pas besoin d'une image cloud). Pour cela voir la documentation systemd-nspawn et systemd.resource-control (elles ne sont pas si indigestes que ça).

Systemd-nspawn est une alternative intéressante à LXC permettant de gérer des containers thin (on lance uniquement une application) ou thick (on lance tous les services) sans avoir à installer quoi que ce soit.

BONUS : sous debian, ça ne change rien pour les utilisateurs

Si je peux comprendre que beaucoup de gens n'aiment pas systemd et ne souhaitent pas l'utiliser, en revanche je ne comprends pas pourquoi cette grogne est focalisée chez les utilisateurs de debian au point de créer le fork devuan. Parce que si vous êtes utilisateur de debian, systemd ne change rien pour vous. Tout d'abord le boulot est fait par les mainteneurs des paquets, vous n'avez jamais touché à un système d'init de votre vie, et avec systemd vous n'y toucherez pas non plus. Ensuite, si vous faites un peu de sysadmin, là encore rien ne change pour la majorité des opérations.

Voici pour comparer la manière dont on démarre apache :

root@localhost:~# service apache2 start # avec sysvinit
root@localhost:~# service apache2 start # avec systemd

C'est pareil, parce que debian est une distribution pour fainéants (comme moi) très bien foutue. Même chose pour le réseau, ça se gère toujours dans /etc/network/interfaces rien ne change.

Sous Archlinux par contre tout change par exemple le fichier /etc/rc.conf a disparu au profil de fichiers éclatés pris en charge par systemd. Ce n'est pas méchant mais il a fallu réapprendre certaines choses. Malgré une grogne passagère la chose semble avoir bien été acceptée par les utilisateurs, en tous cas ils ne sont pas partis forker leur distribution.

Conclusion

Au final, après avoir lu tant de troll, tant de FUD sur systemd, je trouve que c'est plutôt bien. C'est simple à utiliser et c'est puissant puisqu'on peut imaginer un jour remplacer LXC et cela ouvre plein de possibilités au niveau des serveurs, par exemple avoir des instances apache et nginx isolées dans les containers thin, ou encore des applications portables à la manière de Snap ou xdg-app. Pour 99% des utilisateurs de Linux la transition est transparente puisque prise en charge en amont par les mainteneurs.

Je prends donc le risque d'invoquer une armée de troll dans les commentaires mais moi j'approuve systemd.

ESET Nod32 usurpe mes certificats SSL ?

Rédigé par uTux 5 commentaires

J'ai un ordinateur de gaming sous Windows avec l'antivirus ESET Nod32 (il me restait une licence dans un coin). Et ce matin j'ai remarqué un truc intéressant : ce bougre usurpe l'identité de mes certificats SSL. En effet mon blog, utux.fr, est signé par Let's Encrypt. Or, sur ma machine avec ESET Nod32 installé, voici ce que Firefox affiche :

ESET

ESET installe sa propre autorité de certification dans Windows (ce qui rend l'usurpation possible) et re signe les certificats que vous utilisez. Pourquoi ? Le but des certificats signés c'est pas justement de valider la chaîne de confiance jusqu'au serveur ? D'empêcher des interceptions ? Ce que fait ESET Nod32 est justement ce que l'on cherche à éviter non ? Que se passe-t-il si une porte dérobée est découverte dans Nod32 et permet à des personnes mal intentionnées de signer tout et n'importe quoi sur ma machine ?

Chiffrement : merci Apple

Rédigé par uTux Aucun commentaire

Avec quelques jours de retard, je livre aussi mes réactions sur le déchiffrement de l'iPhone par le FBI. En résumé ils ont été contactés par une entreprise (dont le nom n'a pas été révélé) qui leur a "vendu" les détails d'une faille permettant de casser ou contourner la sécurité de l'appareil. Donc le FBI a accès aux données et n'a plus besoin de Apple. Beaucoup de gens y voient donc l'échec de la firme à la pomme car le système ne serait pas infaillible.

Et pourtant c'est faux, cela prouve encore une fois qu'on se focalise sur cette affaire bien précise alors que l'enjeu c'est le chiffrement. Apple n'a jamais voulu défendre un terroriste, ni même bloquer une enquête du FBI par plaisir. Non, leur but était de préserver leur système de chiffrement en refusant de l'affaiblir car cela aurait eu des conséquences néfastes pour tout le monde.

Le fait que le chiffrement ait été cassé/contourné n'est pas une première : les failles ça existe depuis toujours, sur tous les systèmes. Le fait que le FBI en ait acheté une prouve d'ailleurs que c'est un véritable business. Il est probable que le mystérieux interlocuteur connaissait cette faille depuis longtemps et attendait de la vendre au plus offrant.

La pression est donc retombée mais il est peu probable que cette affaire soit terminée pour autant. Attendons de voir la suite.

Récit d'une attaque portmap

Rédigé par uTux 3 commentaires

Tout a commencé avec des problèmes de lenteur sur notre connexion à internet au bureau. Un petit tour dans l'interface d'administration de la Freebox a montré une utilisation importante de la bande passante en upload même la nuit lorsque toutes les stations de travail sont éteintes. Heureusement derrière la Freebox il y a un routeur sous Linux par lequel tout le trafic passe, nous avons donc des outils plus poussés pour analyser ce qui transite.

iptraf a montré que le trafic n'était pas émis depuis une station de travail mais était généré en local (par le routeur lui-même) : était-il compromis ? Présence d'un rootkit ? Une petite vérification des processus avec ps et top semble indiquer que non, rien d'anormal. J'ai également vérifié à coup de md5sum que les binaires bash, ps, w, who, top n'avaient pas été altérés (en comparant avec une version sauvegardée il y a 1 mois).

Donc le routeur génère le trafic mais ne semble pas compromis, d'où vient donc le problème ? Sortons l'artillerie lourde : tcpdump. On sniffe 10secondes de trafic puis on récupère notre fichier pour l'ouvrir dans wireshark, c'est plus simple à lire. L'analyse montre un trafic composé exclusivement de paquets UDP / protocole Portmap. Une petite recherche rapide sur Google "high portmap trafic" me mène vers des articles d'Aout 2015 détaillant une forme de ddos basée sur portmap. C'est un ddos par amplification, c'est à dire que nous recevons des requêtes forgées qui font que nous générons ensuite des attaques vers d'autres serveurs. Or il se trouve que suite à un lourd historique (dette technique) la configuration du pare-feu était incorrecte et le port 111/UDP (portmap) du routeur était accessible depuis internet. La fermeture de ce port a mis fin aux attaques.

tcpdump / wireshark sont les meilleurs amis du sysadmin, et j'ai découvert également iptraf qui permet d'avoir une vue d'ensemble du trafic ce qui permet d'établir un premier diagnostic. Un pare-feu bien configuré est indispensable car même si des services ne sont pas utilisés ou sont censés répondre uniquement en local, des failles sont toujours possibles.

Free + bridge + IPv6

Rédigé par uTux 16 commentaires

Comme je l'ai dit dans mon article sur la fibre Free, la Freebox n'est vraiment pas terrible, j'ai donc rapidement acheté un routeur pour la remplacer. J'ai pris un Asus RT-AC66U, modèle relativement satisfaisant qui supporte le Wi-Fi 5GHz mais aussi plusieurs firmwares alternatifs (actuellement Merlin).

J'ai beaucoup hésité à écrire cet article sachant qu'il serait indigeste, mais il constitue un bon exercice pour IPv6 et peut aider ceux qui ont leur Freebox en bridge.

Principe

En IPv4 le principe est simple : on configure la Freebox en bridge ce qui permet au routeur de récupérer directement l'IP publique. A lui ensuite de faire le NAT pour donner l'accès à internet aux machines du réseau. Mais en IPv6, comment fait-on ?

Tout d'abord la stack IPv4 ne change pas, on va configurer notre IPv6 à côté sans incidence. On n'utilise pas de "NATv6" mais du bon vieux routage à l'ancienne, avec de la délégation de préfixe, bref un vrai réseau tout propre. En fait, chaque machine du réseau aura une "IPv6 publique" (cette affirmation est un pléonasme). On va avoir besoin de :

  • 1 sous-réseau IPv6 en /64 pour la partie WAN, avec 2 adresses (Freebox et Routeur côté WAN)
  • 1 sous-réseau IPv6 en /64 pour la partie LAN, avec 1 adresse (Routeur côté LAN)

Voici ce que cela donne avec un schéma et des adresses bidon :

Mise en place

La première chose à faire consiste à se rendre dans l'interface de configuration de la freebox grâce à l'adresse mafreebox.free.fr qui fonctionne même si vous êtes en bridge.

Puis rendez-vous dans : Paramètres de la Freebox, onglet Mode avancé, Configuration IPv6.

  1. A cocher, bien évidemment.
  2. Adresse IPv6 de lien local de la Freebox.
  3. Le premier préfixe qu'on va déléguer au routeur (pour le WAN). Notez qu'il se termine par 5430.
  4. Mettre l'adresse IPv6 de lien local de l'interface WAN du routeur (à récupérer par exemple avec ip addr ou ifconfig en SSH sur le routeur).
  5. Le second préfixe qu'on va aussi déléguer au routeur (pour le LAN cette fois). Il se termine par 5431.
  6. Mettre l'adresse IPv6 de lien local de l'interface WAN du routeur - la même que pour le point 4.
  7. Encore un préfixe, mais on ne va pas l'utiliser, on a tout ce qu'il nous faut !

Maintenant, on passe à la configuration du routeur. Voici pour l'Asus RT-AC66U :

  1. Type de connexion, ici c'est du statique.
  2. Le WAN du routeur (premier préfixe 5430 suivi de ::2).
  3. 64.
  4. Le WAN freebox (premier préfixe 5430 suivi de ::1).
  5. Le LAN du routeur (second préfixe 5431 suivi de ::1).
  6. 64.
  7. Pour info.
  8. Type d'advertisement sur votre LAN. Le stateless laisse les machines s'auto-configurer. Stateful est du DHCPv6. Il vaut mieux sélectionner stateless.

Comment tester

Conclusion

La Freebox n'a pas une seule IPv6, ni même un seul réseau IPv6, elle en a plusieurs. Et dans notre cas elle en délègue deux à notre routeur. Les avantages ? Possibilité de gérer vous-même le pare-feu (la Freebox n'en a pas) et aussi de modifier plusieurs éléments (comme les DNS diffusés).

Fil RSS des articles de cette catégorie