Le Blog Utux

HTTP 200 GET /

pfSense, OPNsense, Endian, RouterOS

Rédigé par uTux 3 commentaires

J'utilise depuis quelques années un routeur ASUS RT-AC66U branché sur la freebox en bridge, principalement pour avoir du WiFi en 5GHz (le 2,4 étant saturé chez moi) mais aussi pour des fonctionnalités qui n'existaient pas quand je me suis abonné, par exemple le pare-feu et les dns ipv6. Ce montage fonctionne plutôt bien mais le routeur arrive aujourd'hui à ses limites :

  • Problèmes de performances avec OpenVPN (client et serveur) probablement à cause du CPU faiblard (MIPS 600 MHz). Les débits ne dépassent pas 1 Mbps.
  • Le firmware alternatif ASUS Merlin que j'utilisais a abandonné le support du RT-AC66U. J'ai du rebasculer sur le firmware ASUS officiel, toujours maintenu mais avec beaucoup moins de fonctionnalités.
Asus RT AC66U

J'envisage donc de changer de routeur et de mettre à niveau ma stack réseau avec au passage un ou plusieurs switches supportant les VLANs. J'ai envisagé plusieurs pistes :

  • Partir sur un routeur Mikrotik, car j'ai déjà travaillé avec ce matériel et j'adore RouterOS. De plus les prix sont très raisonnables.
  • Acheter un Linksys WRT (les gros routeurs bleus) car ces modèles ont l'air d'avoir une grosse communauté et énormément de firmwares alternatifs toujours maintenus.
  • Miser sur un APU Alix + pfSense / OPNsense. L'intérêt du x86 est que quasiment tous les OS fonctionnent dessus en natif.

Le routeur Linksys WRT a été rapidement éliminé car je prends le risque de retomber dans la même situation qu'avec le RT-AC66U, à savoir les firmwares communautaires qui ne sont plus maintenus ou trop limités.

J'ai été très tenté par un routeur Mikrotik malheureusement le support d'OpenVPN est extrêmement sommaire et ne correspond pas à mon besoin. Il est possible d'utiliser de l'IPsec (en IKEv2) mais pour une raison que j'ignore le flux ne passe pas à travers ma Freebox.

L'achat d'un APU Alix en x86 s'impose donc. Pour rappel, il s'agit d'un des nombreux modèles de SBC (Single Board Computer) au format mini-ITX construit par PC Engines. Grands fans de CPU AMD à basse consommation et de multiples interfaces réseau, ils sont très prisés pour faire des routeurs. En prime l'architecture x86-64 permet de faire tourner quasiment n'importe quel OS: Windows, Linux, FreeBSD, OpenBSD... ce qui donne au final un petit serveur mieux qu'un Raspberry Pi, même si le prix est bien plus élevé. L'inconvénient des APU Alix est qu'ils ne sont pas vendus dans la plupart des boutiques françaises, il faut donc aller chercher sur Amazon, eBay, Varia Store, ou d'autres revendeurs.

Alix APU 4d4

Pas de Wifi sur ce modèle, je vais devoir brancher mon Asus RT-AC66U configuré en mode point d'accès. En fait il est possible d'avoir du wifi directement sur le routeur Alix, mais c'est plus compliqué quand on veut du double bande 2,4 et 5 GHz car il faut deux cartes.

Reste à choisir l'OS qui sera installé pour faire office de routeur. Pour cela j'ai testé dans des machines virtuelles pfSense, OPNsense et Endian. Voici les résultats de ce POC :

  • Endian a une interface web trop limitée qui n'a quasiment pas évolué au cours des dernières années et ne permet pas de gérer un serveur OpenVPN, il faut passer par la CLI. J'ai donc abandonné assez rapidement cette solution.
  • OPNsense n'a pas été facile à prendre en main, l'interface moderne n'est pas très intuitive mais au final j'ai pu faire tout ce que je voulais. Malheureusement ma première mise à jour s'est faite dans la douleur, et lors de la seconde j'ai perdu la fonctionnalité de serveur DHCP. J'ai aussi de gros problèmes de lenteurs de l'interface avec Linux + Firefox ESR alors qu'avec Chrome pas de problèmes. Je n'ai donc pas un bon retour d'expérience concernant la fiabilité du produit.
  • pfSense est donc le gagnant par élimination. L'interface est différente d'OPNsense mais les fonctionnalités et la logique sont les mêmes. Le système de mises à jour est différent puisqu'il ne fonctionne pas par parquets mais au niveau de l'image dans son ensemble.

Il faut maintenant que je prenne le temps de configurer tout ça.

Monter ses partages à la demande avec Autofs

Rédigé par uTux 3 commentaires

Je me connecte régulièrement avec mon laptop à des partages Samba/CIFS de mon NAS. Pour cela j'utilise la commande suivante à chaque démarrage:

$ sudo mount -t cifs //192.168.1.1/partage /mnt/partage/ -o user=utux

J'aimerai que ce soit automatique. Le problème est que je ne peux pas utiliser le /etc/fstab car au moment où il est exécuté le réseau n'est pas prêt (wifi ou client openvpn). Il existe bien l'option _netdev mais elle n'a jamais fonctionné pour moi. Ce cas d'usage montre bien les limites des montages Linux qui ne sont pas adaptés à la mobilité et aux environnements dynamiques.

Bonne nouvelle, il existe une alternative: autofs qui s'appuie sur automount. Contrairement à mount, il connecte le partage lorsqu'on y accède (et pas au démarrage) et le déconnecte si on ne l'utilise pas. Il a aussi de nombreuses autres fonctionnalités:

  • Un système de templates utile quand on a de nombreux partages.
  • Support de plusieurs protocoles (cifs, nfs, raw...).
  • Auto-découverte des partages.
  • Consommation de ressources moindre (déconnecte les partages non utilisés)
  • Meilleure tolérance aux coupures réseau.

Installation sous Debian / Ubuntu:

$ sudo apt install autofs

Créer/éditer le /etc/auto.master:

/mnt	/etc/auto.nas --timeout 300 --browse

Créer/éditer le /etc/auto.nas:

partage -fstype=cifs,credentials=/home/utux/.autofs_creds,user=utux,uid=utux,rsize=8192,wsize=8192 ://192.168.1.1/partage

Créer le fichier /home/utux/.autofs_creds:

username=utux
password=secret

Mettre le /home/utux/.autofs_creds en chmod 0600:

$ chmod 0600 /home/utux/.autofs_creds

Mettre le /etc/auto.nas en chmod 0644

$ sudo chmod 0644 /etc/auto.nas

Démarrer le service:

$ sudo systemctl start autofs

Tester:

$ ls /mnt/partage

Si cela ne fonctionne pas:

$ sudo systemctl stop autofs
$ sudo automount -f –v

Notez que cela ne fonctionnera pas si le /etc/auto.nas est exécutable:

$ sudo chmod -x /etc/auto.nas

Autofs est génial et solutionne mes problèmes de montage de partages en mobilité.

EDIT 15/03/2020: Smb version 4, ajout uid pour corriger des problèmes de droits.

Firewalld, c'est bien

Rédigé par uTux 6 commentaires

Il y a deux ans j'affirmais aimer systemd dans l'article systemd, c'est bien. Aujourd'hui je parle de Firewalld, un service et ensemble d'outils permettant de gérer le pare-feu sous Linux.

La base du firewall sous Linux c'est iptables, et quand on a compris et beaucoup pratiqué, c'est pas si compliqué. Mais il y a toujours deux points qui me gênent:

  • Il n'y a pas de service officiel pour charger les règles au démarrage, il faut faire son propre script ou en emprunter à droite à gauche.
  • Les règles sont quand même indigestes et bas niveau, ce qui n'est pas toujours nécessaire.

Firewalld implémente un système de "zones" dans lesquelles vous allez définir des paramètres, autoriser des services: internet, public, dmz... elles peuvent être définies à partir de l'interface ou de la source, c'est assez souple. Le paramétrage se fait soit en cli (firewalld-cmd) soit graphiquement (firewall-config) ou encore au travers d'une api et introduit la notion de "permanent" pour savoir si il faut conserver les modifications au démarrage.

Bien entendu, firewalld est un service système donc il n'y a pas de script à écrire pour charger ses règles au boot, il suffit de l'activer dans sytemd.

Firewalld est présent sur Fedora, CentOS, RedHat mais peut être installé sur d'autres sytèmes comme Debian car il est proposé dans les dépôts. Et moi, je migre mes serveurs sur Firewalld avec prise en charge par Ansible, parce que je gagne un temps fou et je fais les choses proprement.

Merci Red Hat ces logiciels qui terminent en "d" et qui modernisent un peu Linux :)

Toujours de sérieux trous chez Free mobile

Rédigé par uTux 8 commentaires

J'ai été client Free Mobile en 2012 mais cela n'a pas duré car au bout de 6 mois la qualité du réseau internet 3G s'est considérablement dégradée : les sites en https, Youtube et Google Play ne marchaient plus du tout. Ce problème est connu depuis toujours et survient lorsque l'abonné accroche une antenne Orange en itinérance, et c'est souvent le cas vu qu'il y a peu d'antennes Free Mobile.

J'ai récemment retenté l'expérience car mademoiselle utux, ma copine, avait besoin d'un forfait pas cher. J'ai sauté sur une vente privée à 3,99€ / mois pour le forfait normalement proposé à 19,99€ et dès réception de la carte SIM nous avons pu l'essayer. Il s'avère qu'en ville (Nantes) ça marche plutôt bien car y a beaucoup d'antennes Free Mobile, par contre en campagne c'est la galère, on passe toujours sur de l'itinérance Orange et donc internet ne fonctionne plus. Sur l'autoroute par exemple il est impossible de lire une vidéo Youtube et difficile de charger une carte sur Google Maps alors que mon téléphone sous Sosh n'a aucun problème (nous l'avons d'ailleurs utilisé comme point d'accès durant le voyage).

Free Mobile en 2016 c'est donc toujours du vent, du bluff renforcé par des publicités et des tarifs agressifs agrémentés de dénigrement de la concurrence. Et ce marketing est visiblement efficace car on trouve beaucoup de gens persuadés que si tu n'as pas 50GB de data dans ton forfait c'est que tu es un pigeon. Je n'utilise jamais plus de 500 Mo par mois même avec de la synchronisation ActiveSync (YunoHost + Z-Push) et la seule fois où j'ai atteint ma limite de consommation (3Go à l'époque, 5Go aujourd'hui) est quand j'ai passé 1 semaine sans connexion à internet fixe.

L'accord d'itinérance Free / Orange n'est pas éternel et le désengagement va d'ailleurs bientôt commencer. Lorsque les vannes seront totalement coupées tous ceux qui n'habitent pas en ville vont se retrouver en zone blanche et cela représente beaucoup de monde.

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.

Fil RSS des articles de cette catégorie