Quentin Demoulière

Mon blog personnel

Administration système

Double facteur d'authentification SSH avec la Yubikey de Yubico

Rédigé par Quentin Demouliere - - Aucun commentaire

Pourquoi un double facteur d'authentification ?

"Le mot de passe est actuellement le système le plus couramment utilisé pour authentifier un utilisateur. Il n’offre plus le niveau de sécurité requis pour assurer la protection de biens informatiques sensibles, car différentes techniques d’attaque permettent de le trouver facilement."

Wikipédia

La yubikey est une clef USB simulant un clavier USB et permettant de générer un mot de passe à usage unique appelé OTP. Ainsi, l'idée est d'obtenir une authentification forte à l'aide d'un double facteur d'authentification pour le daemon OpenSSH. Concernant son fonctionnement, voici l'explication très claire fournie par aeris sur son blog :

"À l’intérieur de la Yubikey se trouve une clef AES en écriture seule (pas de lecture possible de la clef), possédée aussi par Yubico (l’entreprise fabriquant la Yubikey).

À chaque appui sur le bouton de la clef, celle-ci va émettre une chaîne composée de son identifiant de clef, d’un compteur de session (s’incrémente à chaque branchement de la clef), d’un compteur d’horloge (s’incrémente 8× par seconde) et d’un compteur d’utilisation (s’incrémente à chaque appui sur le bouton). La chaîne complète est chiffrée avec la clef AES interne, et envoyée ainsi à l’application qui cherche à vous authentifier.

Votre application va alors contacter le serveur de Yubico et lui soumettre la chaîne chiffrée. Le serveur possédant lui aussi la clef AES, il peut déchiffrer les données et les vérifier. S’il est capable de déchiffrer les données et que l’identifiant d’utilisateur correspond bien à celui associé à la clef, on est en présence d’une clef valide. Si les valeurs de tous les compteurs sont bien strictement supérieures à celles de la dernière chaîne validée, on est en présence d’un nouveau identifiant et non d’un rejeu d’une chaîne interceptée."

Si vous souhaitez en apprendre davantage sur le fonctionnement de cette petite clef, je vous renvoie à l'excellente conférence qui a eu lieu lors de Pas Sage en Seine 2011 : https://numaparis.ubicast.tv/videos/pses-yubikey/ mais aussi plus récemment lors des RMLL 2014 : http://video.rmll.info/channels/#securite_.

Lire la suite de Double facteur d'authentification SSH avec la Yubikey de Yubico

Réinitialiser une borne Wifi TP-Link N600 fonctionnant avec OpenWRT

Rédigé par Quentin Demouliere - - Aucun commentaire

Comme j'ai eu un petit souci avec ma borne Wifi TP-LINK N600 (que je vous recommande chaudement par ailleurs) fonctionnant avec le firmware OpenWRT, j'ai cherché un petit moment comment restaurer la configuration par défaut d'OpenWRT. Et j'ai fini par trouver la procédure.

Lire la suite de Réinitialiser une borne Wifi TP-Link N600 fonctionnant avec OpenWRT

De l'intérêt d'un MX de secours dans le cadre de la gestion de mon service mail personnel

Rédigé par Quentin Demouliere - - Aucun commentaire

La redondance, les sauvegardes sont des notions primordiales en informatique. La tolérance de pannes doit faire partie des critères majeurs à prendre en considération y compris dans le cadre de l'auto-hébergement.

Ainsi, je dispose de 4 serveurs DNS maitre et esclaves autoritaires sur ma zone et d'un système de backup incrémentiel pour sauvegarder tout ce qui est important. Jusqu'à présent, j'avais fait le choix de ne disposer que d'un unique serveur SMTP pour les raisons suivantes :

  1. En cas de crash d'un serveur SMTP, les autres serveurs de messagerie tenteront de lui renvoyer les mails qui lui sont destinés pendant quelques jours (5 jours par défaut).
  2. Trop souvent (à tort), le MX secondaire est peu protégé, il devient la proie des spammeurs en tout genre.
  3. Augmentation des risques et des problèmes liés à la configuration de deux services SMTP au lieu d'un.
  4. Si le MX de secours se trouve sur un site distant (solution optimale), cela complique la possibilité pour celui-ci de délivrer les mails directement dans les boites utilisateurs.
  5. Le serveur de secours ne fait pas forcément de contrôle des destinataires. Ne sachant pas quels destinataires sont valides pour les domaines dont il est serveur de secours, il accepte tous leurs messages et essaie de les délivrer au serveur primaire. Celui-ci va ensuite refuser les destinataires invalides, obligeant le serveur de secours à renvoyer ces messages à leurs expéditeurs. C'est ce que l'on appelle les notifications indésirables.
  6. L'argument ci-dessus entraîne deux conséquences majeures, possibilité de saturation de la file d'attente et envoi de notifications indésirables sur des adresses mails d'utilisateurs réels utilisées par les spammeurs.

Lire la suite de De l'intérêt d'un MX de secours dans le cadre de la gestion de mon service mail personnel

Mise à jour de Debian Wheezy vers Debian Jessie

Rédigé par Quentin Demouliere - - Aucun commentaire

Debian 8.0 Jessie est sorti le samedi 25 avril 2015 en version release et stable. C'est donc l'occasion pour upgrader ses serveurs tournant sous Wheezy la version antérieure. Pour ma part, j'ai réalisé quelques tests sur une machine virtuelle avant de me lancer sur des machines physiques.

Comme je n'aime pas Systemd, vous l'aurez compris :p,  et que Jessie supporte toujours Sysvinit, j'ai fait en sorte de garder ce gestionnaire d'init. Voilà les différentes étapes que j'ai réalisé afin de réaliser cette mise à jour :

$ sudo -s
# tmux new -s upgrade
# echo -e 'Package: *systemd*\nPin: origin ""\nPin-Priority: -1' > /etc/apt/preferences.d/systemd

 

Je n'oublie pas de modifier mon fichier sources.list afin de basculer vers les dépôts de Jessie :

# vim /etc/apt/sources.list
deb http://ftp.fr.debian.org/debian/ jessie main contrib non-free
deb-src http://ftp.fr.debian.org/debian/ jessie main contrib non-freedeb
http://security.debian.org/ jessie/updates main contrib non-free
deb-src http://security.debian.org/ jessie/updates main contrib non-free
deb http://ftp.fr.debian.org/debian/ jessie-updates main contrib non-free
deb-src http://ftp.fr.debian.org/debian/ jessie-updates main contrib non-free
deb http://ftp.fr.debian.org/debian/ jessie-backports main contrib non-free
deb-src http://ftp.fr.debian.org/debian/ jessie-backports main contrib non-free

 

Aptitude, cet outil magique !

# aptitude update && aptitude safe-upgrade
# aptitude dist-upgrade

 

La troisième ligne me permet de dire au système Debian que je ne veux pas de systemd et que je préfère sysvinit. Pour cela, on passe par le système de Pin Entry, gestionnaire de priorités avec l'outil apt-get. Et voilà, enjoy !

PS : À noter que sur l'un de mes serveurs où j'utilise php5-fpm, le système de gestion des dépendances m'a obligé à installer libsystemd. Tant que ça reste une librairie. Voici également un site sympa qui explique clairement comment conserver sysvinit.

Mettre en place des salons de discussion sur son serveur XMPP Prosody

Rédigé par Quentin Demouliere - - Aucun commentaire

J'utilise XMPP depuis maintenant un peu plus d'un an sur un serveur Debian disposant de Prosody, le tout auto-hébergé. J'avais envi de pouvoir créer un salon de discussion afin de parler avec plusieurs personnes en même temps lorsque l'occasion ou le besoin se présente.

Je vous rassure rien de bien compliqué. Sur votre serveur XMPP, dans le fichier de configuration Prosody :

$ sudo vim /etc/prosody/prosody.cfg.lua

-- Définir les comptes autorisés à créer des salons sur le serveur avec séparation par
-- une virgule
admins = { "votrecompte@votredomain.dom" }
------ Components ------
Component "conference.votredomain.dom" "muc"
restrict_room_creation = true

 

Il reste à ajouter une nouvelle entrée dans votre serveur DNS faisant autorité sur votre zone :

_xmpp-server._tcp.conference.votredomain.dom. 18000 IN SRV 0 5 5269 votreserveurxmpp.votredomain.dom.

 

N'oubliez pas de relancer votre service DNS.

Avec votre client de messagerie instantanée préféré, joigniez-vous à une conférence, créez votre salon et invitez vos amis. Enjoy ;-)