Traefik

Je me suis mis à tater traefik ce week-end afin d’avoir quelque chose de plus fiable avec Let’s Encrypt, que mon script un peu bancale. En effet il s’agit d’un reverse proxy écrit en go, pensé micro-services et, avec intégration Let’s Encrypt.

Cela rentre à priori parfaitement dans mon cadre d’utilisation. À savoir, 90% de ce que je souhaite publier, que cela soit interne ou public, sont des containers Docker. Est-ce que traefik pourra remplacer nginx, mon reverse proxy actuel ? C’est ce que nous allons voir.

Refactorisation

Dans mon architecture précédente, je mélangeais un peu les rôles de reverse proxy et serveur http. Les deux rôles étant gérés par nginx, cela me permettait d’éviter un petit gaspillage de RAM en ayant plusieurs instance de nginx. Lorsqu’on héberge tout sur seulement 32Go, on essaie de grapiller là où l’on peut ! Mais c’est de l’histoire ancienne cela et je peux bien sacrifier quelques Mo supplémentaires depuis que j’ai upgradé mon nuc à 64Go de RAM. Mon hyperviseur est cosy maintenant.

L’intérêt est qu’en utilisant traefik, je m’oblige à séparer les deux rôles et donc à avoir quelque chose de plus propres. En effet, si je souhaite migrer un service, je n’ai qu’à le rsync sur une autre machine et faire chauffer les containers. Il n’est plus nécessaire de porter la configuration du reverse proxy à la main, puisque celle-ci est intégrée à ma stack Docker. Et surtout l’ajout d’un backend ne nécessite pas de recharger traefik, contrairement à nginx.

Et l’autre atout phare, comme mentionné précédemment, est l’intégration directe de Let’s Encrypt. Il n’est plus nécessaire d’écrire un script, de le lancer régulièrement pour quémander un nouveau certificat, remplacer le fichier et raffraichir la conf du reverse proxy. traefik le fait pour toi, et ça marche du premier coup !

J’ai pu ainsi passer de ça :

 

nginx en tant que reverse proxy, ssl endpoint et serveur http

À ca :

traefik comme reverse proxy et ssl endpoint, nginx en tant que serveur http

Bon ok, en image ce n’est pas transcendent.

Mais la conf est cool

Le container traefik pèse 80Mo là où nginx se content de 20Mo. On reste sur du container léger et la différence de taille provient surtout du binaire traefik (68Mo à lui tout seul). On reconnait bien ici la signature go.

Pour l’installer, rien de plus simple qu’un docker-compose.yml par défaut avec :

  • les ports qu’on souhaite exposer à l’extérieur
  • un réseau « DMZ » qui sera commun à traefik et les points d’entrée de mes autres stack
  • le fichier de configuration de traefik.toml
  • un fichier nommé acme.json et qui va contenir les clés privées générées et certificats émis par Let’s Encrypt
  • on trust traefik en lui donnant l’accès à la socket de contrôle de Docker pour qu’il détecte automatiquement les containers et les intègre en fonction de la configuration

En option, j’ai fixé l’ip du container sur la pate DMZ. traefik ajoute également les en-têtes X-Forwarded-For* aux backends. Avoir une ip fixe facilite la configuration du trust du reverse proxy au niveau des backends.

Note: le choix de l’ip dépend bien évidemment du subnet avec lequel le réseau dmz a été créé (explicitement ou implicitement).

Le fichier de configuration de traefik, traefik.toml, va permettre de configurer :

  • s’il faut auto-demander des certificats auprès de Let’s Encrypt et quel type de clé privée générer, EC256 pour ma part plutôt que le fat RSA
  • les versions de TLS activés ainsi que les ciphers disponibles
  • et le plus important: d’ajouter un container automatiquement, s’il a les labels qu’il faut

Mis à part le cas nexus que je détaillerais plus bas, ce fichier de configuration est complètement agnostique de ce que je vais coller au cul de traefik. Exit la conf d’un virtual host qui fait péter tout le serveur !

Préparer Docker

Comme mentionné précédemment, j’utilise un réseau docker nommé dmz pour relier traefik avec les backends. A part le nom et un espace suffisamment grand, c’est un réseau tout ce qu’il y a de plus normal:

Ajouter des backends Docker à traefik

Pour connecter un container à traefik, grâce à la configuration de traefik, tout se fait dans la définition même du container, au moyens de labels. Cela signifie que:

  • je n’ai pas besoin de toucher à la configuration principale de traefik
  • je n’ai pas besoin de redémarrer traefik

Par exemple voici la configuration de nginx sur la stack faisant marcher ce blog:

 

 

Par défaut, le protocol utilisé pour communiquer avec le backend est http mais il est aussi possible de spécifier h2c ou https.

h2c est utilisé pour autoriser le HTTP2 sur un canal non-SSL. Considérant la connexion traefik ↔ nginx comme totalement fiable, cela me permet de bénéficier des atouts du HTTP2 sans le surcoût du chiffrement dû à la couche SSL.

https est aussi disponible, notamment lorsque le backend ne support QUE ce moyen de transport. C’est par exemple le cas de unms de Ubiquity.

Rediriger vers du non Docker

Bien que traefik s’interface très bien dans un monde pleins de containers, il est aussi capable de servir de reverse proxy vers des backends autre, par exemple mon NAS.

En effet traefik dispose de pleins de providers autre que Docker, dont File. Celui-ci permet de définir des frontends et backends à la main.

Par exemple pour proxifier la page web de mon NAS, j’ai simplement du déclarer un frontend et un backend dans le fichier de configuration de traefik.

1 container, 2 backends

traefik sait aussi gérer des cas plus particuliers. Celui de nexus par exemple, qui est un gestionnaire de dépôt open-source. Nexus gère des dépôts de plusieurs type (docker, nuget…) et à ce titre nécessite des endpoints différents.

À l’aide d’une syntaxe étendue, traefik support la définition de plusieurs frontends et backends. Pour nexus, j’ai défini deux couples, web et registry, ayant chacun un frontend et un backend.

Cela permet de voir que traefik fonctionne vraiment comme un passe-plat :

  • le frontend, qui est un endpoint exposé par traefik pour accéder à un backend (ou plusieurs dans le cas d’une configuration en failover ou load-balancing)
  • un ou des backends, qui sont des endpoints que peut appeler traefik

 

On remarquera au passage l’utilisation du label traefik.frontend.whitelist.sourceRange, qui permet de restreindre l’accès à un frontend (ici tous ceux de nexus) à un subnet particulier.

Egalement l’ajout de l’en-tête HSTS avec les deux labels traefik.frontend.headers.STSPreload et traefik.frontend.headers.STSSeconds.

Parce qu’il faut bien râler

Au final traefik a entièrement rempli sa mission. Mais c’est un produit encore relativement jeune, notamment sur les points suivants :

  • impossibilité de demander un certificat RSA pour un frontend particulier (tout RSA ou tout ECDSA, pas de mix possible).
  • impossibilité d’autoriser un certificat invalide pour un backend particulier (tout ou rien ici encore)
  • parfois traefik ne voit pas le redémarrage d’un container, il faut alors le restarter à nouveau pour qu’il soit vu et intégré correctement

Cela dit, ce sont des points assez mineurs. traefik, je valide.

IPv6 sur EdgeRouter (Red by SFR / SFR)

Petit achievement aujourd’hui, j’ai réussi à avoir l’IPv6 de mon fournisseur d’accès directement depuis mon routeur EdgeRouter-4. Pour remettre en contexte, ma box SFR est dans son carton. Le seul équipement de SFR que j’utilise est l’ONT, qui converti un signal fibre en cuivre entre-autre.

Jusqu’à présent, j’utilisais un tunnel IPv6-in-IPv4 fourni par Hurricane. C’est gratuit, la bande passante est plutôt grosse, mais n’arrange sûrement pas à réduire la latence par rapport à une connectivité IPv6 directement fournie par l’opérateur (du moins, je pense).

Pourquoi ?

Avant de détailler comment j’ai fait, j’aimerais expliquer pourquoi je n’utilise pas la box de l’opérateur, après tout elle est gratuite et propose plein de fonctionalités, non ? C’est vrai mais… non, pour plein de raisons :

  • en matière de sécurité, je trouve totalement malsain d’avoir une box opérateur, propriété de l’opérateur, contrôlée par l’opérateur au sein de son réseau local. L’utilisation d’un routeur sous mon contrôle évite une fuite des données vers l’opérateur. Distinction franche entre mon réseau local et le réseau opérateur.
  • si je change d’opérateur, je n’ai pas à reconfigurer mon réseau interne. Seul la patte WAN sera modifiée. J’ai zéro adhérence avec mes opérateurs Internet ou de téléphonie.
  • je n’ai plus de téléphone fixe et la merdasse télévisuelle ne m’encourage pas à utiliser le décodeur fournit. Au pire, il s’agit juste de VLAN à faire passer, donc là aussi la box n’est pas indispensable
  • j’ai vraiment plus de fonctionnalités avec mon routeur que toutes les box opérateurs réunies. Je peux monter un tunnel GRE, IPSec v2, avoir des routes conditionnelles etc… Il s’agit de fonctionnalités que j’utilise.
  • Ca marche (avez-vous déjà utilisé l’interface d’administration de la box Orange) ?
  • Ca marche vraiment. Impossible de faire fonctionner un tunnel IPSec le plus bidon possible en utilisant la box Orange.
  • Ca marche même sous stress, là où la box opérateur plante avec un simple DoS (désolé Nunzz ^^ »)

Il est clair que remplacer sa box n’est pas à la portée de tout le monde, mais rien que pour la fiabilité, ça donne envi.

Mimer la box opérateur

Le plus simple pour trouver comment faire est encore d’analyser la communication entre la box opérateur et le réseau opérateur. Cela tombe bien, j’avais justement un switch manageable ce qui m’a permis de mettre en place un port mirroring et ainsi pouvoir sniffer le traffic depuis mon pc portable en live.

Contrairement à ce que j’avais lu ici ou , j’ai été ravi de lire que l’obtention d’un bloc IPv6 se fait de manière non seulement simple mais suivant les standards (enfin presque) ! En effet, le bloc IPv6 s’obtient via le protocole DHCPv6 en 4 messages :

  • SOLICIT: le client hurle (broadcast) à la recherche d’un serveur DHCP
  • ADVERTISE: un serveur DHCP répond à l’aide
  • REQUEST: le client souhaite obtenir une délégation sur un bloc IPv6
  • REPLY: le serveur, tout aimable qu’il est, répond positivement à la requête

Capture de la requête DHCPv6
Capture de la requête DHCPv6

Bloc IPv6 vs IPv4

De prime abord, le processus pour obtenir une IPv6 semble plus compliquée. Cette apparente complexitée s’explique par le fait qu’il n’y a pas de NAT en IPv6 (enfin si mais on va supposer que non). Cela signifie que tout équipement souhaitant aller sur Internet ne peut pas utiliser l’IP du routeur, comme cela se fait en IPv4 mais doit avoir sa propre IPv6 routable. Routable par opposition à une IPv6 privée (commençant par fe80:) qui pourrait être l’équivalent du 192.168.x.y en IPv4.

Pour répondre à cette problématique d’IP routable, on a deux choix de réseaux :

  • il n’y a plus de réseau local, uniquement le réseau de l’opérateur dont vous et tout vos équipements font parti. Cette solution n’est absolument pas raisonnable tant pour l’usager que pour l’opérateur d’un point de vue de la sécurité.
  • le réseau local de chaque utilisateur et le réseau opérateur, séparés par un routeur

La solution retenue est bien entendue la seconde. Sans IP routable, la communication d’un périphérique est limitée à son réseau local. L’obtention d’une IPv6 se fait donc par un appareil se trouvant lui aussi dans le réseau local, c’est à dire la box opérateur.

Cette box va donc demander à l’opérateur quels sont les IPs qu’il peut distribuer en local, c’est le prefix delegation (PD). L’opérateur fournit à chaque box, qui en fait la demande, une délégation sur un préfixe IPv6 (ou bloc IPv6), ce qui va permettre deux choses :

  • la box va pouvoir distribuer une IP dans ce pool aux objects connectés
  • ce bloc sera routé depuis Internet vers la box (pinger une IP de ce pool va arriver sur le routeur, qui forwardera (ou pas) le paquet)

Patcher Wide-DHCPv6

L’OS EdgeMax est tout à fait en mesure de gérer intégralement la stack IPv6, au moins en CLI vu que la GUI tarde à le gérer proprement. En tant que client DHCPv6, il utilise wide-dhcpv6 pour obtenir une prefix delegation. Là où ça coince, est que le serveur attend deux informations qu’il n’est pas possible de setter dans la configuration de wide-dhcpv6 :

  • le client identifier (option 1) avec un DUID de type 3 (link-layer adress) et non 1 (link-layer adress plus time). Ce pré-requis est obligatoire. Actuellement la valeur est l’adresse mac de la box côté LAN mais pour plus de sûreté, prenez la valeur indiquée dans la capture
  • le vendor class (option 16) qui est l’id du modèle de la box. Il s’agit d’un paramètre optionnelle pour le moment.

Requête DHCPv6 avec les deux options à reproduire
Détail de la requête DHCPv6

Vu que Ubiquiti est respectueux de la licence GPL, j’ai pu récupérer le code source patché de wide-dhcpv6 et commencer à travailler me casser les dents dessus.

Fixer les bugs n’étaient pas une mince affaire. Le EdgeRouter fonctionne sous une architecture MIPS. J’ai donc du monter une vm avec qemu, elle-même dans une VM linux puisque je suis sous Windows, afin de pouvoir compiler la chose. Le débuggage avait comme un arrière goût des années 80 : une compilation qui prend 15 minutes à chaque fois et des outils franchement pas pratique, genre gdb. Et une doc complètement inexistante bien entendu, avec des noms de variables incompréhensible. Au-secours !

Mais j’ai fini par me sortir de ce sable mouvant, voici donc les patches ubnt-wide-dhcpv6-201.tar

Comme c’est ultra chiant à compiler, voici également le binaire à glisser à la place de /usr/sbin/dhcp6c sur le routeur.

Au passage, Ubuntu sous Hyper-v Gen 2, ça marche 🙂

Configurer le Edgerouter

Il va falloir au préalable récupérer quelques informations contenu dans la capture faite précédemment. Elles sont indispensable pour pouvoir configurer proprement le EdgeRouter :

  • le DUID dans le message SOLICIT
  • le vendor class value dans le message SOLICIT
  • le prefix

Il y a 3 sections à configurer :

  • le dhcpv6 pour obtenir un préfixe côté WAN
  • le radvd (router-advert) pour distribuer les préfixes côté LAN
  • l’override de l’adresse mac de l’interface WAN

Ci-dessous ma configuration EdgeRouteur :

SFR distribue un préfix /56. Un réseau local avec radvd utilise un préfix en /64. Cela signifie que vous pouvez avoir 256 réseaux locaux. Récupérez le préfixe distribué par SFR (depuis la box par exemple) et choisissez un sous-préfixe en /64 pour votre LAN. C’est ce qu’il faudra renseigner dans interfaces -> ethernet ethx -> ipv6 -> router-advert -> prefix.

Fixez également l’IPv6 de l’interface LAN du routeur, afin de pouvoir spécifier un serveur DNS qui écoute sur la stack IPv6, c’est le paramètre interfaces -> ethernet ethx -> ipv6 -> router-advert -> name-server.

Enfin remplacer l’adresse mac de l’interface WAN par celle de l’opérateur. Ce n’est pas obligatoire mais devrait mieux supporter les évolutions du réseau de l’opérateur.

Afin de mieux mimer les requêtes DHCPv6 (et parce que de toute façon parce qu’il n’est pas possible de générer le bon fichier de conf en cli), on va écraser complètement le fichier généré par la section dhcpv6-pd par notre propre version.

Je donne ici un exemple où je récupère un préfix en /56 de SFR et j’assigne deux /64 pour mes deux réseaux locaux :

  • eth0, qui est le réseau principal
  • eth0.213 qui est mon réseau lab

Cela permet de mettre en évidence le rôle des paramètres sla-id et sla-len. sla-len est la différence entre le /56 donné par l’opérateur et le /64 que j’assigne à un réseau, soit 64-56=8.

sla-id est de longeur sla-len, il peut donc avoir une valeur entre 0 et 255 inclus. C’est le nombre qui sera suffixé au préfix. Par exemple mon préfixe donné est 2a02:8428:1234:3300::/56. Alors :

  • avec un sla-id de 1, le subnet de eth0 sera 2a02:8428:1234:3301::/64
  • avec un sla-id de 213, le subnet de eth0.213 sera 2a02:8428:1234:33d5::/64

Il ne reste plus qu’à rendre la configuration et le binaire persistent, à l’aide de /config/user-data et d’un petit script de restauration. Jetez un oeil à mon article de présentation de l’ER-4 pour se faire.

Plus

Ca marche aussi avec Sosh / Orange. Il faudra sniffer le traffic entre la box et l’ONT afin de récupérer les bonnes options et valeurs.

Source

Repérer un bridage opérateur

Les opérateurs Internet nous proposent des connexions fibres jusqu’à 1GB/s pour 15€/mois. Et cela sans engagement. Dès l’installation, on constate souvent que l’annonce est respectée. Alors oui, l’opérateur pourrait annoncer des débits jusqu’à 1TB/s, tant qu’il y a du débit, il ne ment pas techniquement. Mais est-on loin de ce qui est vendu ?

Quand le lièvre devient tortue…

21 mai 2018, j’ai la fibre chez moi depuis à peine deux semaines ainsi qu’un routeur qui envoi du bois. nperf m’annonce 851,69Mb/s en descendant et 201.47Mb/s en montant. Deal honoré. Fin septembre, je refais la mesure et là j’obtiens 500Mb/s en descendant et 170Mb/s en montant. Histoire d’être sûr, les mesures ont bien entendues été effectuées plusieurs fois sur plusieurs jours. De 85% de débit effectif, je suis donc passé avec les mois à 50% seulement. Pour le paysan que je suis, je n’ai aucune garantie minimale de débit, mais quand même ! Est-ce passager, est-ce que les équipements de l’opérateur sont en souffrance ?

Mi-octobre, changement d’opérateur. Je passe de SFR RED à SFR RED avec le même abonnement. Le payeur est différent mais SFR refuse explicitement un transfert de contrat, d’où changement, pose d’un jour de congé et réception de nouvelles box (même modèle) par le technicien. Je précise pour la suite qu’à part l’ONT (convertisseur signal optique en signal Ethernet), rien n’a changé. Même routeur, même câble optique et je n’ai pas été recâblé au niveau du PMZ (l’armoire verte dans la rue).

Le test sur la « nouvelle » connexion me donne 801Mb/s en descendant et 121Mb/s en montant.

Excuse me, what the fuck?
Excuse me, what the fuck?

la tortue deviEnt scribe

Je me suis donc mis à mesurer régulièrement la qualité de ma connexion Internet. Il existe pour cela une version en ligne de commande de speedtest. Accompagné d’un petit script que voici et alimentant un fichier au format CSV, nous allons donc avoir du quantitatif, qu’on pourra visualiser avec par exemple un simple fichier Excel.

Pour que mes systèmes restent propres, j’utilise une bête image docker contenant le binaire speedtest-cli.

Il ne reste plus qu’à ajouter le script dans crond et c’est parti.

Le fichier CSV ressemble à :

On y trouve respectivement :

  • la date UTC,
  • l’id du serveur avec lequel s’est fait le test de débit
  • le ping moyen en ms
  • le débit descendant en Mb/s
  • le débit montant en Mb/s

Pour ma part, j’ai testé avec le serveur le plus proche, et le serveur de mon opérateur le plus proche.

Note: il faudra peut-être passer un coup de sed pour corriger le séparateur de décimales avant de faire avaler le fichier par Excel.

EdgeRouter 4

J’ai enfin eu la fibre ! après avoir bataillé avec notre syndic et la mairie pour pousser SFR à fibrer l’immeuble pendant plusieurs année ! On pourra dire que SFR a pris son temps. Me voilà donc avec une offre fibre à 1GB/s descendant et 200MB/s montant et un APU, mon ancien routeur, aux abois. En effet un speed test avec la box opérateur me donne un débit réel (mais non-garanti) de 830MB/s descendant, 260MB/s montant et un ping à 10ms, c’est un résultat très honorable par rapport à l’offre commerciale. Avec l’APU en revanche il m’est plus que difficile de dépasser le 300MB/s en descendant, ce qui se voit assez bien avec un htop montrant que le CPU est complètement à genou.

J’ai du coup craqué sur un EdgeRouter 4 de chez Ubiquiti pour remplacer mon APU et bien évidemment laisser la box SFR au placard. Uniquiti propose des produits que je trouve assez intéressant :

  • la cible sont les professionnels et éventuellement les particuliers bidouilleurs dont je fais parti
  • le matériel contient des circuit dédiés permettant de décharger le processeur des opérations réseaux, DPI et IPSec
  • la consommation est très faible : seulement 13W sur ce modèle
  • le logiciel est ouvert à la modification (dans le sens : il peut faire bien plus que ce qu’à prévu initialement le fabricant)
  • il est doté d’un port console pour pouvoir réparer le boitier même quand on a tout cassé
  • la partie logicielle repose entièrement sur une stack Debian, sur lequel Ubiquiti a rajouté une interface web et en ligne de commande pour piloter le boitier.
  • le prix est plus que raisonnable au vu de la qualité du matériel et de l’efficacité

EdgeRouter ou APU ?

Honnêtement c’est un petit bijou. Initialement j’avais pris une carte APU pour être au commande de tout. Le EdgeRouter respecte cela en tout point :

  • on peut rajouter ou enlever des daemons
  • eventuellement il est possible de compiler un logiciel et le faire exécuter par le EdgeRouter, en gardant à l’esprit que le CPU n’est pas non plus un i7 dernier cri
  • tous les services sont open-source, la partie propre à EdgeRouter étant la couche de gestion. Ainsi on retrouve dhcpd, dnsmasq, openssh, iptables, ipsec, radvd, strongswan, python, ddclient, dhclient, le kernel linux, busybox, monit, ntpd…
  • les backups sont totalement consistentes avec la CLI

Je me retrouve donc avec un système opérationnel robuste et plus simple à gérer et sur lequel je ne suis pas limité autrement que par les capacités matérielles.

J’ai listé dans le dernier paragraphes les articles qui m’ont aidé à modifier le router selon mon goûts et vais détaillé comment fonctionne un routeur Ubiquiti.

Les fondations du EdgeRouter

Comme je l’ai indiqué en introduction, le routeur repose sur une base totalement open-source :

Pour être plus précis, l’OS en question est EdgeOS, qui est un fork de Vyatta, lui-même basé sur Debian.

Pour des soucis d’efficacité énergétique, le CPU utilisé, un quad-core, repose sur une architecture mips64 (tout, mips ou arm, sera plus efficient que l’archi x86/amd64) :

il existe quelques modules propriétaires (du moins, je n’ai pas réussi à trouver où étaient les codes sources) permettant de faire appels aux différents circuits d’accélération matérielle :

La surcouche Ubiquiti

Le EdgeRouter peut se gérer de 4 manières différentes :

  • par l’interface web
  • par l’interface en ligne de commande (CLI)
  • directement en ssh comme dans toute distribution Linux, avec le risque de voir ses changements écrasés par la configuration de l’interface web/cli ou par un reboot
  • grâce à /config

L’interface web est assez limitée en comparaison de la CLI mais pourra convenir à un usage très simple ou très standard. Personnellement je la trouve trop limitée ce qui la rend un peu inutile à mon goût si ce n’est voir visuellement le traffic en temps réel et la santé générale du système.

Dashboard EdgeRouter
Dashboard EdgeRouter

La CLI

La ligne de commande est accessible soit via l’interface Web (en haut à droite), soit via SSH, que je trouve de loin plus pratique à une émulation de console à travers une page web.

Il existe 3 modes à la CLI :

  • les commandes bash habituelles
  • show, permettant de consulter différentes informations au runtime
  • configure, permettant d’accéder à la configuration du routeur

Il est inutile que je détaille le premier mode, il s’agit juste de bash. Exactement il s’agit de vbash, pour lequel l’auto-complétion des fichiers et dossiers ne fonctionnent pas. Sans chercher plus loin, un sudo su me permet de retrouver un bash « normal ». Les deux autres modes en revanches sont la spécificité de EdgeOS et sont assez facile à prendre en main. En effet elles sont dotées de l’auto-complétion : un simple TAB-TAB permet d’afficher les sous-commandes possibles.

show Show

Chow chow

La commande show permet de récupérer un certain nombre d’informations sur le routeur à travers une interface unifiée (un truc complètement raté dans le monde de l’open-source) :

On peut ainsi explorer facilement tout ce que peux offrir show et les sous-commandes étant relativement explicite, deviner la bonne commande est plutôt aisé.

configure

De manière similaire à la commande show, le mode configure est aussi doté de la même d’auto-complétion. On rentre dans ce mode simplement en exécutant configure.

On peut alors

  • show: consulter tout ou partie de la configuration
  • set: modifier un paramètre
  • commit: appliquer les changements effectués de manière non-persistante (perdu au prochain redémarrage)
  • save: persister la configuration
  • edit: peut être vu comme une sorte de « cd subSection »
  • exit: remonter d’un cran (aka « cd .. ») ou quitter le mode configure si l’on est déjà au top-level

Ci-dessous un exemple mettant en évidence la commande edit, laquelle permet d’utiliser show ou set sans devoir spécifier le chemin du paramètre entier, edit permettant de changer de contexte ou de descendre dans l’arborescence. Ainsi plutôt que d’avoir à taper show interfaces ethernet eth2 , le edit interfaces  me permet de ne taper que show ethernet eth2 pour avec le même résultat.

Ubiquiti a fait preuve d’ingéniosité en concevant le fichier de configuration se trouvant dans /config/config.boot . Il s’agit d’un fichier texte lisible dans un format similaire à du JSON. On remarque que ce fichier respecte la même hiérarchie que le mode configure. Par cette simple idée, s’approprier la logique du mode configure devient un vrai jeu d’enfant. Il s’agit aussi du config tree que l’on trouve dans l’interface web.

/config

Dernier petit bijou, le dossier /config . Contrairement au reste, le contenu de ce dossier sera préservé à travers une mise à jour du firmware. Grosso-modo, toutes nos bidouilles doivent se trouver ici.

On va y trouver :

  • le fichier de configuration /config/config.boot
  • les scripts de post-initialization dans /config/scripts/post-config.d/
  • les autres fichiers à garder dans /config/user-data/

Les scripts initialisation m’ont servi entre autres à :

  • ajouter des paquets supplémentaire (nsd3, htop, screen, unbound)
  • remplacer dnsmasq par unbound
  • ajouter des daemons supplémentaires
  • configurer unbound et autres en copiant /config/user-data/root/ dans /

Script me permettant d’installer des paquets supplémentaires :

Script permettant la fusion de /config/user-data/root/ dans / et effectuant d’autres opérations spécifiques :

Mot de la fin

J’espère que cette introduction facilitera votre prise en main. Personnellement j’étais un peu frileux à l’idée de prendre du matos semi-propriétaire mais je suis au final extrêmement satisfait de cet investissement et je ne peux que le recommander pour toute personne ne souhaitant pas avoir un équipement étranger (la box opérateur) dans son réseau local. En bon passionné que je suis, j’attends avec impatience une nouvelle version majeure du firmware qui nous emmènerais sur un kernel 4.x, le kernel 3.10 actuellement utilisé n’étant plus supporté. J’ai lu que la principale difficulté provenant du constructeur CPU qui rechignerait à fournir un SDK compatible avec une version récente de Linux.

Source

Authentification Nextcloud en SAML (avec ADFS)

Nextcloud est une solution open-source en alternative à Dropbox et consort. C’est une solution plutôt simple à mettre en place mais comme toujours, SAML complique les choses. A commencer par une documentation relativement pauvre, ce qui conduit à tâtonner jusqu’à trouver la bonne configuration. Sans plus tarder, voici comment configurer Nextcloud pour déléguer l’authentification à ADFS en SAML.

Pré-requis

  • Un Nextcloud déjà configuré
  • Un IdP qui marche, il s’agira ici de ADFS 4.0 (Windows Server 2016)
  • Un certificat signé par une autorité reconnue par l’IdP, avec sa clé privée. La clé doit obligatoirement être du RSA. Ce certificat sera assigné au SP (Service Provider), c’est à dire Nextcloud afin de déchiffrer les requêtes SAML de l’ADFS passant à travers le navigateur. Ce certificat est optionnel dans l’absolu mais le tutoriel suppose qu’il existe.

Configuration de ADFS

Nextcloud propose des méta-data permettant de configurer rapidement l’IdP, cependant ces metadatas sont incomplets et l’on ne peut donc se reposer dessus pour faire une configuration fonctionnelle. Il va donc falloir tout faire à la main.

Dans le gestionnaire ADFS, nous créons un nouveau RP Trust de type Claims Aware.Add Relying Party - Claims aware?Vu que les metadatas générés par Nextcloud ne sont pas suffisants, la configuration du Relying Party Trust va se faire manuellement.

Add Relying Party - MetadataNous donnons un nom à ce Relying Party Trust pour le différencier des autres, avec éventuellement un commentaire à destination des administrateurs.Add Relying Party - Name

Cette étape est optionnelle. Nous allons ici renseigner le certificat demandé dans les pré-requis.

Add Relying Party - Token Encryption

Nous spécifions ensuite le endpoint vers lequel ADFS va rediriger le navigateur après l’authentification. Celui-ci doit être https://[nom.de.domaine.de.nextcloud]/apps/user_saml.acs .

Add Relying Party - Service Provider EndpointNous spécifions l’ID avec lequel Nextcloud va se déclarer auprès de l’ADFS dans les requêtes SAML. Celui-ci doit être https://[nom.de.domaine.de.nextcloud]/apps/user_saml/saml/metadata .

Add Relying Party - Service Provider IdentifierL’écran suivant permet de spécifier les personnes pouvant s’authentifier avec succès avec ADFS pour accéder à Nextcloud. Pour mon cas, j’indique tout le monde.

Add Relying Party - Access Control PolicyLe Relying Party Trust est enfin créé mais nous allons devoir compléter la configuration en l’éditant immédiatement.

Gestionnaire ADFS - Liste des Relaying Party TrustsDans l’onglet Signature, nous allons spécifier le même certificat que celui utilisé dans l’onglet Encryption.

Edit Relying Party Trust - SignatureNextcloud ne supporte pour le moment que l’utilisation du SHA-1, particularité que nous précisons dans l’onglet Advanced.

Edit Relying Party Trust - Hash algorithmNous pouvons valider les changements.

Configuration des claims

Viens ensuite la configuration des claims, c’est à dire d’une part les informations sur l’utilisateurs qui seront transmises à Nextcloud et d’autre part le mapping de ces informations.
Pour cela, nous allons ouvrir la boîte de dialogue d’édition des claims et ajouter deux règles de transformations :

Edit Relying Party Trust - Claims issuanceLa première règle est simple et sert à définir l’id de l’utilisateur côté Nextcloud.

Edit Relying Party Trust - NameIDLa seconde règle va permettre de transmettre l’email et le nom d’affichage de l’utilisateur.

Edit Relying Party Trust - User attributesLa configuration côté ADFS est désormais totalement terminée. Nous pouvons donc maintenant poursuivre avec NextCloud.

Configuration de Nextcloud

Nextcloud vient avec un plugin nommé « SSO & SAML authentication ». Celui-ci doit au préalable être activé dans la page listant les Apps afin d’ajouter une section au niveau de l’administration.

Une fois cela fait, vous trouverez ci-dessous les paramètres miroir à ce que nous avons paramétré précédemment dans ADFS. Prenez garde au warning afin d’éviter un tour en base de données si les choses tournent mal !

Le premier certificat à indiquer dans la section Service Provider Data est celui généré en pré-requis que nous avons renseigné comme token de chiffrage dans ADFS. Il doit être indiqué sous forme PEM, c’est à dire sous forme d’une chaîne en base-64 entouré des balises  « —–BEGIN CERTIFICATE—– » et « —–END CERTIFICATE—–« .

Nextcloud - SSO & SAML Authentication - Service Provider DataDans la section Identity Provider, on fera attention à distinguer l’ID de l’IdP, lequel n’est pas une url et est par défaut http://[nom.de.domaine.de.adfs]/adfs/services/trust , sans le s dans http, du endpoint de l’IdP dans le second champ. Le certificat à indiquer dans les options cachées de l’Identity Provider est le token de signature de ADFS. Il se récupère dans la console ADFS dans Services > Certificates. Nextcloud s’attend à la partie publique du token, donc le certificat. Comme précédemment Nextcloud s’attend à ce que le certificat soit sous forme PEM.

La section suivante tire partie des informations envoyées par ADFS, notamment le nom d’affichage de l’utilisateur et son email. Les noms d’attributs peuvent être obtenus dans ADFS en cliquant sur le bouton View Rule Language ou bien en analysant les requêtes SAML lorsqu’elles ne sont pas chiffrées.

Nextcloud - SSO & SAML Authentication - Identity Provider DataEnfin la dernière partie spécifie si le dialogue SAML est signé, chiffré et part qui. Dans le cas où Nextcloud est derrière un reverse proxy, il pourrait être nécessaire de désactiver l’option Indicates if the SP will validate all received XML.

Nextcloud - SSO & SAML Authentication - Security

It works!

Nextcloud - Login via SSO

Vous devriez à partir de maintenant pouvoir vous connectez à Nextcloud de manière totalement transparente. N’oubliez pas de désactiver l’option .

Je pense qu’on peut faire mieux, notamment au niveau des claims où certain attributs me semblent inutile mais parce que ça marche je n’ai pas poussé ces tests. J’espère ainsi pouvoir vous éviter l’enfer, ça sera pour une prochaine fois.

Enjoy!

Je me suis fait hack (encore)

Me voilà de retour d’une très sympathique semaine de ski pour constater un peu par hasard et après une bonne nuit de sommeil une activité suspecte sur mon routeur, un hack ?

Un cafard se balade sur mon routeur

Que vois-je ? L’utilisateur build qui ouvre une connexion ssh en live ?! build est un compte que j’utilise pour build des packages pour Alpine Linux. Avant de me faire une vm dédiée à cette tâche, avec largement plus de capacité, c’est mon routeur (sous Alpine) qui s’occupait de la compilation. Le routeur est un bi-coeur faiblard cadencé à 1GHz épaulé par 4Go de RAM à comparer à une machine virtuelle armée de 8 vCPUs et de 8Go de RAM, ce n’est pas exactement la même chose sur les temps de compilation.

Si un gus a réussi à ssh mon routeur, c’est qu’il est exposé sur Internet, plutôt normal pour un routeur. Et comme je souhaite pouvoir m’y connecter à distance, SSH est accessible sur son port standard. Je suis absolument contre la sécurité par l’obscurantisme, dont l’analogie serait de cacher la clé sous le tapis. Je n’ai donc pas remappé le port 22 ailleurs. Quant au mot de passe de ce compte, ça devait très certainement être build aussi… Ca peut paraître stupide sauf que mes accès ssh ne sont pas censés accepter des logins par mot de passe. Enfin c’est ce que je croyais.

Désinfection au Raid⚡

Après une vérification rapide de /etc/ssh/sshd_config , j’ai pu confirmer, et corriger, que sshd acceptait bien les logins par mot de passe. Je suppose que j’ai dû être un peu fatigué lorsque j’ai mis à jour sshd la dernière fois. Plus de fun que de mal, le petit malin aura tenté tout un tas de binaires pré-compilés pour escalader en privilèges ou faire miner ma box mais sans la glibc ni compilateurs, c’est un peu dur de les faire exécuter, sans compter grsec qui masque tous les process non-ownés en cours d’exécution et l’absence de sudo.

Ci-dessous l’activité de l’indésirable, on peut voir aux commandes employées et fautes de frappes que l’attaque était manuelle.

Il aurait pu explorer mon réseau interne. En effet la présence de l’interface ppp0 avec la commande ifconfig indique assez clairement une connexion « perso » ou du moins signifiant un équipement pas installé en datacentre. J’en suis presque déçu. On peut même y lire de la frustration lorsqu’il tant vers la fin les commandes apt-get  et yum . Rien que pour avoir pu déguster ce nectar, je ne regrette pas ma mauvaise configuration.

J’espère que ça t’aura amusé au moins autant qu’à moi. Je suis cependant preneur de tout moyen de tracer ce connard script-kiddie en obtenant son wallet ETH à partir des informations ci-dessus, je prends !

Et si tu veux jouer avec sa toolbox : 20180128_hack_tools.tar

Synchroniser un certificat SSL avec reverse proxy et serveur IIS

Dans la continuation de mes articles sur Let’s Encrypt, voici un petit article permettant de résoudre un problème qui se pose lors de l’utilisation d’un reverse proxy.

Soit la situation suivante :

  • un serveur applicatif HTTPS utilisant le magasin de certificat de Windows, accédé en direct par les postes de travail internes
  • un reverse proxy HTTPS permettant d’accéder à ce serveur applicatif depuis Internet

On se retrouve alors avec potentiellement 2 serveurs HTTPS distinct donc deux certificats distincts. On pourrait les aligner, mais les certificats Let’s Encrypt ayant une durée de vie de 3 mois, la surcharge induite pour effectuer ce travail manuellement commence à peser, à moins d’automatiser cette opération avec un simple script.

Initialisation

La première fois est manuelle, et consiste à charger le certificat avec sa clé privée, donc obligatoirement sous forme PFX, depuis le reverse proxy vers le serveur applicatif. Cela va servir à charger la clé privée au niveau du serveur applicatif, opération qui ne sera pas faite ultérieurement, et donc simplifie la maintenance d’un point de vue de la sécurité. En effet il suffira par la suite de récupérer uniquement le certificat, donc la partie publique, ce qui se fait simplement en faisant une requête HTTPS au reverse proxy.

Récursion Répétition

Comme dit au premier paragraphe, la clé privée ne change pas, seul le certificat est renouvelé régulièrement auprès de Let’s Encrypt. Le script va donc :

  1. Effectuer une requête HTTPS au reverse proxy, en spécifiant l’hôte permettant de sélectionner le bon site (via l’extension SNI)
  2. La réponse, quelque soit le résultat HTTP (200, 404, 401…) contient le certificat, qu’on importe dans le magasin de certificat
  3. Le magasin de certificat contient la clé privée, ajouté précédemment, et un certificat sans clé privée mais dont la clé publique correspond à la clé privée. On va exécuter un programme qui va permettre de réassocier ces deux éléments
  4. La dernière étape consiste à reconfigurer IIS pour utiliser le nouveau certificat.

C’est l’objectif du script ci-dessous qui pourra être exécuté de manière périodique via le planificateur de tâches.

Enjoy !

Synchronisation asymétrique entre deux dossiers distants

J’ai écrit un (très) petit script qui me permet de synchroniser à sens unique deux dossiers distants.

Ce script s’exécute une fois par jour par cron. À chaque exécution, il va récupérer du dossier source tout ce qui aura été créé ou modifier depuis la dernière bonne exécution du script. Cette synchronisation asymétrique me permet de vider régulièrement le dossier local, qui est dans l’usage un tampon, sans que les éléments déplacés ne soient à nouveaux resynchronisés à partir du dossier distant.

 

Analyser l’impact d’une mise à jour ESXi

Lorsqu’on met à jour à la main un ESXi, il est possible d’analyser les paquets qui vont être installés, ceux qui vont être mis à jour, et ceux qui ne vont pas être touchés. On a alors une sortie qui ressemble à ça.

Comme on peut le voir, il est difficile d’avoir une vue claire permettant de savoir quel paquet va être mis à jour et en quelle version. J’ai à ces fins écris un petit script en PowerShell permettant d’améliorer la lisibilité de la sortie.

Il suffit de remplacer le contenu de $in  par ta sortie et $result  contiendra désormais la liste des packages impactés avec la version d’origine et la version de destination. Il est de même rapide de voir les paquets définitivement supprimés, les nouveaux et ceux qui ne seront pas impactés par la mise à jour.

Enjoy.

 

Description de l’authentification via NTLM en HTTP

Format Lien

Petit article que j’ai déniché expliquant comment fonctionne une authentification avec un site web utilisant le fournisseur NTLM. Note: je ne dis pas si c’est bien ou pas d’utiliser NTLM, juste de savoir comment ça marche.

Cela explique toutefois pourquoi je n’arrive pas à reverse-proxifier un site web qui utilise NTLM pour authentifier le client avec nginx.

NTLM Authentication Scheme for HTTP