Le Blog Utux

HTTP 200 GET /

pfSense, OPNsense, Endian, RouterOS

Rédigé par uTux 4 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.

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 ce mot clé