Système

SimpleSAMLphp, le “couteau suisse de l’authentification”

Lorsqu’on héberge de nombreux serveurs ou services Web, un problème se pose forcément un jour ou l’autre: la multiplication des pages d’authentification et des procédures de gestion des utilisateurs. Pour ne rien arranger, elles sont toutes indépendantes les unes des autres. Vous me direz qu’il est possible d’utiliser (par exemple) un annuaire LDAP ou un service d’autehtification centralisé tel que OAuth, mais cela ne règle pas la corvée des authentifications multiples.

Une solution existe, elle s’appelle “SSO” (pour Single Sign On). De nombreuses implémentations libres existent: Shibboleth, Jasig CAS (liste non exhaustive). Ces dernières ont cependant un inconvénient de taille: elles s’appuient sur des technologies JAVA …

En cherchant un peu, je suis tombé sur le projet SimpleSAMLphp qui va bien au délà de mes espérances: comme son nom l’indique, il est écrit en PHP et supporte nativement deux des principaux protocoles SSO:

  • SAML
  • Shibboleth

Mais sa structure est modulaire et d’autres fonctionnalités sont également disponibles:

  • CAS
  • OAuth
  • OpenID
  • MemCookie

Le logiciel est très bien documenté et de nombreux exemples sont fournis: authentification LDAP, SQL, Facebook, Google, LinkedIn, Windows Live, …

Voici mon premier tuto sur le sujet: mise en place d’un Idp (fournisseur d’identité) SAML / CAS basée sur SimpleSAMLphp.

“SimpleBan”: une alternative à “fail2ban” compatible IPv6

“fail2ban”, c’est puissant, mais ce n’est pas (nativement) compatible IPv6 !

Sans avoir la prétention de ré-inventer la roue, j’ai écrit un petit script shell très simple qui fonctionne sur le même principe:

  • parser les logs à la recherche de motifs,
  • extraire les adresses IP de ces motifs,
  • bloquer les adresses IP.

Le but est de bloquer les adresses IP “indélicates”. Ce script Bash n’a pas besoin de base de données et fonctionne de la façon suivante:

  • lancement régulier via “crontab”,
  • parcours des logs avec “logtail”,
  • extraction des adresses IP avec “grep” et “sed”,
  • mise en place des règles de blocage avec “iptables” et “ip6tables”
  • planification de la suppression des règles de blocage avec “atq”,
  • sérialisation des commandes “iptables” / “ip6tables” avec “tsp”.

La configuration est beaucoup plus simple qu’avec “fail2ban”, la seule difficulté étant l’écriture des motifs de détection et d’extraction.

Script sur le Wiki

Site du projet

 

Redémarrer une machine quand “reboot” ou “shutdown -r now” ne veulent rien savoir !

Mésaventure arrivée grâce à un fichu disque USB défectueux: les commandes “reboot” et “shutdown -r now” ne voulaient rien savoir, et impossible de tuer le processus de copie bloqué. Il existe une alternative moins risquée que le redémarrage “électrique violent”:

echo s > /proc/sysrq-trigger # Flusher les buffers d'IO pour ne pas perdre de données
echo u > /proc/sysrq-trigger # Démonter puis Remonter toutes les partitions en Read-Only
echo b > /proc/sysrq-trigger # Forcer le reboot de la machine

Source

Rustine pour un serveur Web antédilluvien

Pas facile de maintenir un serveur qui tourne depuis presque 10 ans sur une vénérable Debian Etch … Cela fait bien longtemps qu’il n’y a plus de mises à jour de sécurité pour cette distribution. Il héberge une application critique: un serveur Sympa qui gère pas loin de 1500 listes de diffusion. Heureusement, ce dernier est installé à partir des sources et n’est pas complètement à la ramasse.

Cependant, les failles s’accumulent, notamment du côté du serveur Apache et surtout d’OpenSSL. Certaines peuvent être colmatées avec un peu de configuration, par contre il est impossible de corriger la faille CRIME en l’état: la version d’Apache est trop ancienne pour permettre la désactivation de la compression TLS. Enfin la version d’OpenSSL supporte, au mieux TLS 1.0 …

J’ai essayé deux solutions:

  • Passer le service derrière un reverse-proxy Nginx => impossible de faire fonctionner correctement le CGI de Sympa avec le SSO Cas !
  • Remplacer Apache par Nginx / fcgi-wrapper => effets de bord indésirables …

Troisième et dernière solution: compiler et installer Apache + OpenSSL + fastcgi sans écraser les composants déjà présents sur le système.

Quelques contraintes à respecter:

  • Rester en Apache 2.2.x
  • Passer à OpenSSL >= 1.x.x (support de TLSv1 et TLSv2)
  • Lien statique entre OpenSSL et Apache
  • Les module ne sont pas intégrés à Apache (sauf OpenSSL)
  • Conserver mod_fastcgi (fastcgid poserait des problèmes)
  • Conserver mod_security
  • Quelques coups de lime pour compiler des vieux machins avec du neuf (OpenSSL v1.0.2e) !

Reste ensuite à ré-écrire la configuration d’Apache (récupérer celle du serveur d’origine n’est pas un bonne idée) et debugger petit à petit.

La rustine permettra de tenir 2 ou 3 mois, en attendant la prochaine Ubuntu LTS (16.04), pour la migration sur la dernière version de Sympa (encore une procédure bien compliquée …).

=> Procédure de compilation le Wiki.

Renouvellement automatique de certificat Let’s Encrypt

“Let’s Encrypt, le retour …”

La procédure disponible ici permet de renouveller automatiquement le certificat électronique d’un serveur. Le script détermine automatiquement les alias à partir de la configuration d’un serveur Nginx, mais il est possible d’en spécifier d’autres, pour un serveur IMAP, par exemple.

Le “plus compliqué” est de trouver et d’installer le bon certificat (le chemin peut changer lorsqu’il y a une modification dans la liste des hosts passés en alias).

Choix difficile entre un moteur de blog et un moteur de Wiki …

Après de nombreux tests, je constate que WordPress n’est pas très pratique lorsqu’il s’agit de rédiger des documents qui intègrent du code et des scripts. Il offre pourtant des fonctionnalités intéressantes, mais c’est un peu une usine à gaz.

Alors plutôt que de me battre avec des plugins (qui de toutes façon ne me conviennent pas):

  • pour le blog, je conserve WordPress,
  • pour les docs, j’utilise ce que connais le mieux: Dokuwiki.

Mes doc’s et tutoriels

Installer Nginx et OpenSSL (compilé en statique)

Cette procédure permet d’installer une version récente de “Nginx” en intégrant une version également récente d’OpenSSL (compilée en statique) sur une vieille distribution Debian ou Ubuntu (plus maintenue / obsolète).

Il s’agit d’une rustine qui permet de contourner les failles des implémentation obsolètes d’OpenSSL:

  • améliorer la sécurité SSL/TLS lorsque la mise à jour d’Apache ou de libSSL est difficile voire impossible,
  • remplacer un vieux serveur Apache 2 / OpenSSL (pas de mise à jour possible) par un frontal Nginx configuré en reverse-proxy.

La mise en oeuvre nécéssite quelque modifications de configuration:

  • désactiver l’écoute sur https/433 du serveur Apache,
  • changer le port d’écoute http/80 Apache (par exemple http/8080),
  • configurer Nginx en reverse-proxy / mandataire SSL
    • écoute sur http/80 => “redirect temporary” vers https/443
    • écoute sur https/443 => reverse-proxy vers http/8080 assuré par le serveur Apache.

Cette procédure ne casse pas les paquets et les librairies installés sur la machine (libSSL est compilée en statique avec Nginx).

Cette procédure a été écrite pour Debian Lenny (5.0).

Procédure sur le Wiki

Installer Nginx à partir du code source

Le script suivant permet d’installer automatiquement la version la plus récente de “Nginx” et de profiter des dernières innovations telles que le protocole HTTP/2.

  • Installation préalable du paquet “nginx-light” pour bénéficier de l’arborescence Debian,
  • Téléchargement du code source,
  • Compilation et installation:
    • intégration du module externe “header more” qui permet de jouer avec toutes les entêtes HTTP,
    • options de compilation: HTTP/2, SSL, IPv6, WebDav.

Cette procédure a été écrite pour Ubuntu 14.04 LTS.

Procédure sur le Wiki