Archives de mots clés: sécurité

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

 

KeepassX, un “coffre-fort” électronique pour vos mots de passe !

Utiliser le même mot de passe partout, ce n’est pas une bonne idée, et ce n’est tout simplement pas possible (de nombreux sites Web imposent leur propre politique de création de mot de passe.

Ecrire ses mots de passe sur un cahier ou pire, sur des post-it collés un peu partout, ce n’est pas une bonne idée non plus !

La solution ? utiliser un logiciel pour gérer les mots de passe. Ceux-ci sont stockés dans un fichier protégé par un mot de passe qu’il vaut mieux ne pas oublier, d’ailleurs.

J’en ai trouvé un rapidement, libre bien entendu. Il s’agit de KeepassX ,disponible pour toutes les plates-formes et dans pas mal de langues (dont le français). Il existe même port pour Android. Pratique si on stocke le fichier sur un cloud !

Les plus courageux pourront installer le logiciel à partir du code source, mais un PPA existe pour Ubuntu. Voici la procédure d’installation que j’ai trouvée ici:

sudo echo "
#keepassx
deb http://ppa.launchpad.net/keepassx/ppa/ubuntu lucid main
deb-src http://ppa.launchpad.net/keepassx/ppa/ubuntu lucid main" >> /etc/apt/sources.list
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 095F1873
sudo apt-get update
sudo apt-get install keepassx

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.

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