Récit d'une attaque portmap

Rédigé par uTux - - 3 commentaires

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

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

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

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

Free + bridge + IPv6

Rédigé par uTux - - 11 commentaires

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

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

Principe

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

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

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

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

Mise en place

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

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

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

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

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

Comment tester

Conclusion

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

Récit d'une nuit au datacenter

Rédigé par uTux - - 4 commentaires

Mon blog a pour sous-titre "le sysadmin qui raconte des histoires". Voici donc le récit d'une nuit passée au datacenter pour remettre en fonctionnement nos serveurs suite à une coupure électrique.

Dans la nuit du 30 Juin au 1er Juillet 2015 un important incident électrique a eu lieu dans l'Ouest de la France, impactant de nombreuses villes en Bretagne et dans les Pays de Loire. J'étais d'astreinte cette nuit là et je ne parvenais pas à dormir en raison de la chaleur (38°c en fin de soirée).

0h00. Je constate que plusieurs de nos serveurs ne répondent pas : absence de ping et pas d'accès IPMI / iDRAC donc impossible de faire quoi que ce soit à distance. Je dois donc me rendre en urgence au datacenter.

01h00. Arrivé sur place je croise d'autres techniciens venus eux aussi réparer leurs serveurs. J'entre mais n'ayant pas le code pour ouvrir la baie je suis obligé d’appeler mon collègue. Celui ci me le fourni et me propose de venir me filer un coup de main : vu la situation j'accepte. Une fois la baie ouverte je fais un contrôle visuel des voyants, tout est au vert, la raison de la panne est donc plus profonde. En branchant un PC sur le switch de la baie je fais un premier diag et je constate que les machines virtuelles sont toutes en carafe ainsi que deux serveurs physiques. Je note aussi que les quelques équipements fonctionnels ont un uptime d'à peine une heure, il y a donc eu un redémarrage général (non prévu).

01h30. J'ai trouvé la cause du non démarrage des VMs : le datastore iSCSI est offline. Heureusement je parviens à le remonter rapidement : le daemon iscsi-target était arrêté sur le SAN. Après l'avoir lancé je remonte les VMs, tout passe sauf quelques vieux serveurs Windows qui affichent des BSOD. Je charge une iso win2k3 puis tente des chkdsk mais rien à faire. Mon collègue est arrivé et a emmené de quoi tenir : des gâteaux et de l'eau. Nous attaquons donc ensemble le diagnostic de ces VMs Windows qui ne veulent pas démarrer et comprenons qu'il faut les mettre sur même serveur Xen qu'avant leur exctinction. En effet notre infra Xen est composée de 3 serveurs reliés à un datastore et les VMs peuvent démarrer dessus au choix. Cela ne pose pas de problèmes pour Linux, en revanche un vieux Windows n'aime pas. Nous faisons donc plusieurs essais jusqu'à trouver le serveur qui leur convient, nous paramétrons ensuite Xen pour que ces VMs précisent ne puisse démarrer que sur celui-là.

03h00. Les machines virtuelles sont maintenant fonctionnelles mais pas certains serveurs physiques, nous cherchons donc la raison. En fait un switch réseau a perdu partiellement sa configuration, probablement parce qu'elle n'a pas été sauvegardée dans la flash. En effet si vous avez fait du Cisco vous savez probablement qu'il y a plusieurs niveaux de sauvegarde de la configuration : le running-config (effacé au redémarrage) et le startup-config (permanent). Après avoir réaffecté les VLANs aux bons ports, les serveurs physiques repassent enfin en UP, sauf un.

03h30. Sur ce serveur réticent nous branchons un écran + clavier et constatons qu'il est bloqué au niveau de Grub. Après avoir booté un LiveCD de Gparted nous lançons une réparation du RAID1 logiciel qui est cassé à l'aide de mdadm. Mais la reconstruction ne suffit pas, Grub refuse toujours de booter. Nous démarrons alors à nouveau sur le LiveCD et faisons un chroot pour réinstaller Grub, à coup de update-grub et grub-install (sur sda puis sdb). Cette fois ça fonctionne !

04h30. Échange téléphonique avec le CTO qui nous aide à vérifier que tous les services sont bien rétablis. Nous corrigeons les derniers problèmes existants.

6h00. Nous partons nous coucher pour pouvoir attaquer la journée à 09h00. En ouvrant la porte de sortie du datacenter je constate qu'il fait jour et que le sol est humide alors que j'y suis rentré de nuit sous une chaleur étouffante. J'aperçois aussi d'autres techniciens aller et venir avec des serveurs sous le bras, nous ne sommes donc pas les plus malchanceux.

Résumé : Une brève coupure électrique a provoqué l’extinction puis l'allumage de nos équipements. 1 serveur physique a cassé son RAID1, le datastore pour Xen n'a pas correctement démarré, et le switch a perdu partiellement sa configuration. Malgré la fatigue nous avons gardé la tête froide, aidés par l'adrénaline et les gâteaux. Nous avons résisté à cette épreuve du feu, en équipe, et avons gagné 1 journée de repos en compensation.

Pourquoi Pluxml ?

Rédigé par uTux - - 16 commentaires

Mon blog est "propulsé" par Pluxml, ce n'est pas une surprise. Le choix de ce moteur de blog a été difficile car il en existe de très nombreux avec leurs avantages et inconvénients.

Je suis "un vieux" du net, j'ai connu dotclear1 donc pour moi un CMS c'est principalement un bidule en PHP qui offre une interface d'administration dans laquelle je rédige mes articles et génère des aperçus avant de publier. J'ai donc rapidement écarté tous les moteurs de blog "statiques", c'est à dire ceux qui "compilent" un fichier d'entrée au format markdown vers une page html car même si j'aime beaucoup l'idée (un simple serveur web sans dépendance suffit pour publier les pages) ce n'est pas ce que je recherche.

J'ai regardé du côté de Ghost pour le look très attirant et le dynamisme du projet. Malheureusement, c'est du Node. Ce langage est probablement super du point de vue développeur mais du point de vue sysadmin c'est une horreur. Il y a des tonnes de dépendances à installer et à maintenir et il faut toujours une version bien précise car la compatibilité n'est pas assurée. Donc on compile, on lance des scripts qui compilent les dépendances et on prie pour que ça ne pète pas. Ajoutons aussi à cela le fait que Ghost ne prend pas en charge les commentaires et qu'il y a un consensus sur le fait d'utiliser Disqus pour ça... or moi je n'ai pas envie, je ne veux pas sous-traiter les commentaires et je ne veux pas forcer les gens à s'inscrire pour pouvoir discuter !

J'ai ensuite essayé Wordpress mais je l'ai rapidement écarté car c'est un CMS qui a tellement de facettes qu'on ne sait plus vraiment à quoi il sert, de plus sa complexité (au niveau code) le rend difficile à bidouiller. Dotclear a aussi eu droit à un essai. Je ne l'ai pas trouvé déplaisant malheureusement je ne suis pas très fan du thème par défaut et n'ai pas envie d'en télécharger sur le web, c'est trop risqué et peu original.

Donc ce bon vieux Pluxml s'est finalement imposé. Le thème de base est simple, utilise du responsive design, et est facile à modifier. L'interface d'administration est classique et je suis complètement familier avec. Bien sûr Pluxml n'est pas parfait, il a plusieurs défauts :

  • Pas de support markdown
  • Ps d'éditeur wysiwyg
  • Pas de moteur de recherche
  • Trop dépendant envers Apache
  • Pas d'antispam dans les commentaires

Si vous connaissez des moteurs de blogs alternatifs à Pluxml, qui ne sont pas en Node, qui gèrent les commentaires, ça m'intéresse car je suis toujours à la recherche de nouvelles aventures !

YunoHost pour mon cloud perso

Rédigé par uTux - - 5 commentaires

Qu'est-ce que le cloud ? C'est d'abord un terme commercial qui veut dire "je veux tes données, tes logiciels, tes bottes et ta moto je m'en occupe pour toi". Mais pas toujours heureusement car on peut avoir du cloud géré par soi même et c'est même une solution avantageuse. Le cloud c'est un ensemble de services synchronisé ou au moins accessibles depuis plusieurs endroits. Par exemple si j'ajoute un élément dans mon calendrier sur Thunderbird je veux qu'il apparaisse sur mon téléphone automatiquement et ça c'est possible avec le cloud. Il existe de nombreuses solutions propriétaires mais aussi des libres. Avant d'aller plus loin voici mes besoins :

  • E-mail
  • Agenda
  • Contacts
  • Fichiers (dropbox-like)

J'utilise depuis 2 ans YunoHost qui est une solution libre prête à l'emploi pour installer son propre serveur de "cloud". Techniquement c'est Debian + un ensemble de services de base (LDAP, MySQL, XMPP, SMTP, IMAP) auxquels des "applications" viennent se greffer. Le tout est géré par une interface Web et un portail SSO (authentification 1 fois puis accès à toutes les applications).

L'installation se fait soit avec une ISO soit un script à exécuter sur Debian 7 ou 8. Ensuite on se connecte à l'interface d'administration web puis on créé ses domaines, ses utilisateurs, et on installe ses applications comme par exemple Roundcube pour les e-mail. L'application sera automatiquement configurée pour se connecter au serveur mail et au LDAP afin d'authentifier les utilisateurs, c'est aussi simple que ça.

Le portail YunoHost.

Voici quelques applications que j'utilise :

  • Baikal : serveur caldav/carddav pour agenda/contacts.
  • Z-Push : connecteur ActiveSync pour mon Windows Phone.
  • Seafile : Dropbox-like avec interface web et client lourd.
  • TinyTinyRSS : lecteur de flux RSS.
  • DokuWiki : wiki perso.
  • Zerobin : pour copier-coller du texte et le partager en 1 lien.
  • Jirafeau : partage rapide de fichiers.
  • Movim : que j'utilise comme client XMPP web.

YunoHost a une belle interface, c'est coloré, c'est sexy, c'est moderne. L'équipe est sympathique et souvent disponible sur leur salon XMPP (support@conference.yunohost.org). Et si vous voulez packager vos propres applications, le système est assez simple. Il faut faire des scripts bash faisant appel à des fonctions de l'api yunohost (exemple : création d'une database et d'un utilisateur) puis stocker le tout sur github. L'URL du dépôt sera ensuite utilisée pour installer l'application.

Utilisateur de Yunohost depuis deux ans je suis plus que satisfait, c'est une excellente solution pour celui qui veut avoir son propre serveur sur Linux mais n'a pas le temps ou les compétences pour tout configurer soit-même. Je recommande.

Fil RSS des articles de cette catégorie