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 mon 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 contenues dans la capture faite précédemment. Elles sont indispensables 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 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

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

MIFARE : comment copier un badge Mifare Classic

Les badges Mifare Classic, vous en avez déjà tous vu. Le badge Vigik pour rentrer chez soi ou la carte permettant de passer les portiques au travail utilisent en réalité cette technologie. C’est probablement le plus répandu des badges, notamment grâce à son faible coût d’acquisition. Malheureusement on est à des lieues d’avoir un système qu’on peut considérer comme sécurisé. Voyons comment nous pouvons faire une copie.

Badge VIGIK
Badge VIGIK

Lecteur de badge MIFARE en entreprise
Lecteur de badge MIFARE en entreprise

Préparation

Vous allez avoir besoin de :

  • Un PC. Cela peut être un portable ou un fixe mais il est essentiel que cela ne soit pas une machine virtuelle, le timing étant très important
  • Un lecteur de carte NFC. Je possède pour ma part un ACS ACR122U, pas cher et qui fait le taff
  • Kali Linux, une distribution de pen-testing. Je vous conseille de copier l’ISO sur une clé USB pour avoir plus de peps au démarrage. Cela requiert toutefois un PC capable de démarrer en UEFI.

Structure d’un badge MIFARE

Les badges mifare sont assimilables à une carte à puce, c’est à dire qu’ils doivent être vu non pas comme une mémoire morte lisible (tel que les bandes magnétiques) sans fil mais plutôt comme un mini-ordinateur aux capacités très réduites. En l’occurrence, l’accès en lecture ou en écriture peut être limité à la soumission d’une clé que le badge va lui-même valider.

Le badge a une capacité de stockage, en général de 1Ko, divisé en 16 secteur. Pour chaque secteur, deux clés sont définies permettant l’accès à ce secteur. Il n’est pas obligatoire d’avoir des clés distinctes pour chaque secteur.

Récupération d’une clé

Nous allons faire appel à mfoc pour dumper le contenu du badge mais cela ne peut se faire qu’à la condition d’avoir au moins une clé permettant d’accéder en lecture aux différents secteurs du badge. Dans le cas où aucune clé n’est connue, on se retrouve dans la situation ci-dessous où mfoc n’est d’aucune utilité.

C’est à ce moment que mfcuk intervient, dont le rôle est de brute-forcer une clé (A ou B) d’un secteur particulier. L’opération de brute-force a duré 32 minutes.

Attention, il existe aujourd’hui des badges (Mifare DESFire EV1 par exemple) qui résistent au brute-force. C’est le cas de mon badge pour accéder à mon bureau. On les distingue par le fait que la valeur de diff Nt est très proche voire même identique à celle de auths (qui compte le nombre d’essais). Si c’est le cas, mfcuk ne sera d’aucune utilité. Il semble y avoir une solution à ces badges mais je dois pousser plus loin mes recherches je n’ai plus de badge DESFIRE EV1 pour tester.

Dump du badge MIFARE

Désormais en possession d’une clé, nous allons pouvoir dumper le contenu de la carte dans un fichier.

J’ai pu avoir en main plusieurs badges vigik résidentiel provenant de plusieurs résidences. Il est triste de constater que la clé A était la même. Autrement dit désormais en possession de cette clé, j’ai de bonnes chances de copier un badge vigik non pas en 30 minutes mais en 8 secondes. L’opération se fait également très bien avec un smartphone Android rooté.

Il ne reste plus qu’à se procurer une carte MIFARE Classic 1k vierge en s’assurant que le bloc 0 soit inscriptible, sachant qu’il s’agit du bloc dans lequel est contenu le numéro de série (ou UID) du badge, comme vous pouvez le constatez dans la capture ci-dessus.

Un peu de politique

Historique

L’article L.111-6-3 du code de la construction et de l’habitation créé par la loi n° 2005-516 du 20 mai 2005 rend obligatoire l’accès aux parties communes des opérateurs : La Poste ainsi que les autres opérateurs titulaires de l’autorisation prévue à l’article L. 3 du code des postes et des communications électroniques, ainsi que les porteurs de presse.

Si vous choisissez de ne pas équiper un immeuble du système VIGIK®, vous avez l’obligation juridique de trouver une alternative pour garantir l’accès de ces opérateurs.
Certains opérateurs ne sont pas tenus d’accepter des solutions spécifiques (par exemple, La Poste n’accepte pas de badge résident de digicodes ou clés).

Dit autrement, les immeubles ont depuis 2005 obligations d’installer le système VIGIK car La Poste n’acceptera rien d’autre. Le système résidentiel VIGIK a été craqué en 2008, à une période où les badges résidentiels étaient loin d’être déployés partout. 10 ans plus tard, rien n’a changé, il est de commune mesure d’installer ce système dans les nouveaux immeubles en construction.

Le VIGIK opérateur

Dans l’historique, j’ai précisé résidentiel car les badges VIGIK des opérateurs reposent sur un mode de fonctionnement différent. Les opérateurs disposent dans leur locaux d’une borne leur permettant de « charger leur badge pour ~24h ». Voler le pass d’un facteur n’aura donc qu’un intérêt assez limité.

Au niveau des résidences, le système VIGIK est équipé de l’heure ainsi que de la partie publique d’une clé RSA de 1024 bits. Toutes les résidences en France ont cette même clé installée.
Les opérateurs ont dans leur locaux un dispositif ayant un accès limitée (du moins je l’espère) à la partie privée de la clé RSA dont le but est de générer une signature dans le badge des opérateurs valable 1 jour, signature qui va pouvoir être validée par le système VIGIK installé dans les résidences. La clé RSA a été extraite mais elle reste à ce jour et à ma connaissance toujours inviolée.

Pour résumer

Nous avons vu à quel point le système basé sur les badge MIFARE Classic était vulnérable. Mais est-ce le seul ? Ci-dessous une liste des points noir de ce genre d’installation, qui je le rappelle est presque devenu une norme en France :

  • Le système VIGIK résidentiel n’est pas un système de sécurité mais une commodité pour rentrer dans l’immeuble
  • La remarque vaut aussi pour les entreprises utilisant des badges MIFARE Classic (et à confirmer pour les badges EV1)
  • L’accès au mode de programmation des plaques de rue est beaucoup trop facile, notamment parce que le code d’accès est souvent celui par défaut (un peu comme les carte SIM, sauf qu’il s’agit là d’une fainéantise d’un professionnel censé respecter les règles de l’art…). À défaut de cloner un badge, on peut à la place enregistrer son propre badge en base, cela ne prend moins d’une minute et un peu plus d’une dizaine de touches à presser.
Plaque de rue Urmet
Plaque de rue Urmet

Pour aller plus loin

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

Packager Gitlab

Pour diverses raisons, je vomis Debian, Ubuntu, CentOS et autres distributions populaires. Au contraire, je prends mon pied avec Gentoo, et plus récemment avec Alpine. Je ne m’étendrais pas plus que cela, ce sujet mérite à mon avis un poste dédié. La plupart du temps, je m’y retrouve mais pour GitLab, une aventure a commencé.

Il était une fois…

Pour l’historique, j’ai commencé avec SVN pour gérer mes sources et ceux de ma boîte. A cette époque là, il n’existait pas réellement d’alternative cloud, il fallait gérer soi-même l’hébergement, ce que j’ai fait naturellement.

Puis il y a eu des déplacements, l’impossibilité de fetcher le dépôt SVN sur le téléphone ou lorsque je n’étais pas sur mon poste de travail ou tout simplement le souhait de vouloir consulter une version spécifique du code sans devoir récupérer la copie à partir de mon poste. Pour rappel, contrairement à git ou mercurius, une copie de travail svn ne contient qu’une seule version (la base de travail) et les modifications en cours (les fichiers modifiés par rapport à la base). L’historique est consultable à travers un client svn mais est en réalité stocké sur un serveur svn. Un serveur « git » est un abus de langage au sens où git est un VCS décentralisé : la copie sur un serveur git contient autant d’information que la copie sur un poste de travail, autrement dit : il est possible de consulter tout l’historique d’un dépôt uniquement à partir d’une copie sur un poste de travail en déconnecté. C’est l’un des points forts de git, mais rend de fait les dépôts locaux assez fat. J’avais déjà mis en place redmine, un outil de gestion de projet relativement simple, pour la gestion des accès et il proposait un accès web aux dépôts. Ca a fait le taff durant plusieurs années.

Pendant ce temps, l’écosystème git se développe, github devient incontournable, des alternatives cloud apparaissent avec bitbucket, gitorius, gitlab, les outils permettant d’utiliser git sans prises de têtes deviennent assez matures, il est temps d’abandonner svn pour git, les avantages de git n’étant plus dans l’ombre de sa ligne de commande ô-combien puissante, mais horrible d’utilisation. Eventuellement nos projets passent sous git mais toujours sous gestion redmine.

En parallèle je fais une excursion professionnelle sous TFS 2010, le produit s’intégrant bien avec une gestion centralisé de la sécurité sous Active Directory. J’ai expérimenté TFS et son VCS propriétaire TFVC au travers d’un projet web. TFVC est une véritable horreur côté dev, chaque fichier modifié devant d’abord être marqué modifiable. TFS est en soit pas mal, mais TFVC ne figure pas dans ses points forts, étant en outre un VCS centralisé à l’instar de SVN.

Et un jour (automne 2016), Gitlab est arrivé sur la table. Un clone de github, que j’apprécie pour sa simplicité et la notion de merge-request, à installer chez soi (on-premise). Gitlab propose des packages d’installation pour les distributions usuelles mais rien pour Gentoo, si ce n’est l’installation from source. J’avoue ne pas être très surpris. J’y vais donc à suivre le tutoriel d’installation à partir des sources et, afin de contrôler les fichiers installés et faciliter les mises à jour, créer les ebuilds (packages Gentoo boites blanches).

Gitlab

Gitlab est un produit complexe. Chacun de ses composants a sa propre installation, qui fonctionne mais n’est pas clean d’un point de vue packaging (il n’y a pas de clean up des codes sources go après compilation par exemple, ce qui ne sert à rien au runtime). L’écriture des ebuilds est en soit un petit challenge, que je relève haut la main… jusqu’à ce que gitlab passe à ruby 2.3 à partir de leur mouture 9.x. Gentoo est encore à ce jour coincé en ruby 2.2. Impossible de mettre à jour Gitlab, je le laisse en état pendant plusieurs mois en attendant de trouver une solution qui m’éviterais d’installer un ruby 2.3 instable sous Gentoo.

Plusieurs mois plus tard je monte une plateforme Docker, pour l’instant standalone. Il est peut-être temps de voir s’il l’on peu dockeriser Gitlab. Gitlab propose sa propre image Docker officielle mais elle est basée sur Ubuntu (et pas la dernière) et comme dit au début, c’est à vomir. Rien que par la surcharge pondérale des images docker basées sur Ubuntu/Debian en comparaison de Alpine, surcharge qui ne les rendent même pas plus pratique à l’utilisation. Faite donc un less sur l’image Cassandra, Oops ya pas, on tente view alors, ah bah ça n’existe pas, et vi n’est pas non plus fournit. En 5MB, alpine fournit tout ça de base et plus. Je ne fais pas spécialement de pub pour Alpine mais il est difficile de ne pas s’énerver quand on se retrouve à poil à débugger une image fat et moisie.

Maîtrisant plutôt bien l’installation source de Gitlab ainsi que le packaging Alpine, je me lance dans la création d’une image Docker permettant de faire tourner une version à jour de Gitlab. Cela ma conduit à créer plusieurs packages intermédiaires, ruby2.3, yarn (node js), gitlab-shell, gitlab-gitaly. Après pas mal d’effort, j’arrive à avoir une image fonctionnelle en 10.2.5 ! Youpi !!

git-archive

Mais c’est aussi là que j’arrête l’image custo. Alors que l’image officielle de gitlab arrive à intégrer Gitlab et toutes ses dépendances et même plus (postgresql, redis, mattermost, prometheus), mon image ne contient que Gitlab et se prend 100Mo de plus, même en supprimant les packages non-nécessaires au runtime. Frustrant mais s’explique notamment par le manque d’instructions sur le clean, celles-ci étant décrites dans le cookbook ayant servi à concevoir l’image officielle. Mais je n’ai pas le courage de déchiffrer ce qu’à fait le chef.
J’ai mis beaucoup d’effort dans la conception de cette image Docker mais ce n’est pas assez pour qu’elle soit prod-ready, contrairement aux ebuilds Gentoo. Cette fois, j’abandonne, Ubuntu a gagné. J’ai converti la base de données mysql en postgresql pour pouvoir utiliser l’image officielle Docker et c’est dessus que je vais rester. Cette défaite va me permettre de me focus sur d’autres projets à hacker 🙂

Le travail n’aura pas été totalement vain. J’aurais appris au moins deux choses :

  • l’architecture de Gitlab
  • savoir sacrifier certaines choses pour pouvoir se concentrer sur d’autres

Sur cette fin, je félicite d’avance les acharnés qui m’auront lu jusqu’au bout :p

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

rc-status ne voit pas crond

J’ai observé sur mon routeur Alpine que le daemon crond affichait tout le temps crashed.

Alors même qu’il était vivant vu que  pidof crond me renvoyait bien un PID.

Une analyse du script init.d revèle que le pid devrait se trouver dans le fichier  /var/run/crond.pid . Que nenni mon ami, ce fichier contient un PID inexistant, voilà pourquoi rc-status  affiche n’importe quoi !

C’est courant lorsque le script init.d récupère le PID du process qu’il lance, alors que ce dernier se fork encore une fois afin de pouvoir fonctionner en background.

On va résoudre ça vite fait. Examinons s’il est possible que crond crée le pid file, ou alors qu’il ne passe pas en arrière plan lui-même mais laisse faire start-stop-daemon.

Au vu des paramètres possibles, je dirais qu’on va tester crond en foreground. On édite donc /etc/conf.d/crond  pour préciser à crond de rester en background.

Et on relance le service avec rc-service crond restart . Et voilà c’est terminé ! … et là on remarque qu’il n’y a plus de crond du tout ! Et pas de messages d’erreur non plus.

Aux grand maux les grands remèdes, je sors l’artillerie lourde afin de comprendre ce qu’il s’est passé pour de vrai. Le passage intéressant est à la fin; il n’est pas nécessaire de lire toutes ces horreurs.