Utilisez Google Authenticator sans smartphone

Je vous parle, depuis quelques semaines, de Google Authenticator afin de sécuriser vos connexions à différents services : compte Google bien entendu mais également Dropbox, WordPress, LastPass (la liste devrait s'allonger assez rapidement ...). C'est certainement l'un des systèmes les plus performants pour sécuriser l'accès à vos comptes. Mais comment faire si vous ne disposez pas d'un smartphone (c'est encore possible ça 😉 ) ou bien si votre téléphone se trouve dans une autre pièce et que vous n'avez pas envie de vous déplacer ...

Un module pour Google Chrome est désormais disponible. Ce dernier après une configuration rapide (mais toutefois sans utilisation de code barres - il va falloir saisir votre clé secrète à 16 caractères) vous communiquera vos codes à usage unique à l'instar de l'application mobile. Attention toutefois à n'installer ce module que sur un PC de confiance !

Le module "GAuth Authenticator" est disponible ICI

L’authentification à facteurs multiples pour votre blog WordPress

Vous cherchez un moyen de renforcer la sécurité de votre blog WordPress (auto-hébergé) ? Vous devriez aller jeter un coup d’œil du côté du plugin "Google Authenticator". Comme son nom l'indique, ce dernier va vous permettre d'intégrer le système d'authentification "en deux étapes" de Google à votre propre blog.

L'intégration et la configuration semble être assez simple :

  • installation et activation du plugin
  • paramétrage du module au sein de l'interface d'administration de WordPress
  • scan du code-barres d'auto-configuration avec l'appli pour smartphone

  • et c'est terminé ! Vous devriez normalement voir apparaître un champ supplémentaire au sein de la fenêtre d'authentification.

Vous perdez votre smartphone ? Pas d’inquiétude, vous pourrez accéder de nouveau à votre blog en supprimant (avec un accès ftp, ssh ...) le plugin de votre arborescence WordPress (d'où l’intérêt d'opter pour un mot de passe ftp/ssh assez fort). Le plugin vous permet également de maintenir un accès par mot de passe (afin que certaines applications puissent accéder à votre blog par exemple). Mais dans ce cas vous diminuez bien sûr l'efficacité du dispositif !

Il est bon de noter, au passage, que Google Authenticator commence à être utilisable avec de nombreuses autres solutions que les produits de Google : WordPress mais également LastPass, Dropbox, vos propres serveurs SSH ... A mon avis ce système va rapidement s'imposer comme un standard pour l'accès à pas mal de sites web et dispositifs sur le net.

Pour ceux qui ne qui ne savent pas ce qu'est une authentification à facteurs multiples, je vous conseille la lecture de  mon billet de la semaine dernière ("Les 3 news de la semaine" / titre "Dropbox permet désormais l’authentification à facteurs multiples").

  • Le plugin WordPress se trouve ICI
  • Google Authenticator pour Android est disponible sur le Play Store : ICI (pour les autres : iOS, Blackberry ... vous n'avez qu'à chercher par vous même ;-))

Twitter propose une connexion HTTPS permanente …

Si vous utilisez régulièrement l'interface web de Twitter à partir d'un hot spot public vous devriez activer cette nouvelle option !

En effet, et à l'instar de ce que Googe proposait il y a quelques mois pour Gmail, il est désormais possible de forcer la connexion en mode HTTPS (voir l'annonce officielle ICI).

C'est plutôt une bonne nouvelle quand on connait la simplicité d'utilisation d'une application comme FireSheep !

Attention : pour le moment la version mobile de Twitter (accessible au travers de l'URL : http://mobile.twitter.com ) n'est pas encore concernée par cette option. Vous devez donc vous assurer de bien vous connecter avec https://mobile.twitter.com ).

La réaction de Google après la découverte des applications malveillantes

On apprenait, dans la semaine, la découverte de 21 applications malveillantes au sein de l'Android Market (ICI). Google vient de publier un article sur son blog dédié aux mobiles ( ICI) en réaction à cette annonce .

Visiblement le problème est  pris au sérieux et des mesures spécifiques ont été mises en œuvre : désinstallation à distance des programmes malveillants et application automatique d'un patch de sécurité sur les mobiles affectés. Enfin les utilisateurs concernés seront prévenus par mail.

Google annonce également la mise  en place de nouvelles mesures spécifiques visant à améliorer la sécurité du Market.

L'Android Market est un système ouvert et c'est une très bonne chose. Toutefois, il faut constater que cette ouverture ne permet pas de garantir un niveau de sécurité optimal. Il serait peut être intéressant que Google s'inspire de ce que fait Mozilla pour son système d'extensions Firefox (ou Thunderbird) avec le concept d’approbation. A vous de décider, ainsi, si vous prenez (ou pas), le risque d'installer un module "non approuvé".

 

 

Firesheep : quand utiliser un hot spot wifi devient une activité risquée …

Vous ne le savez peut être pas encore, mais depuis quelques semaines une nouvelle extension pour Firefox a vu le jour. Son nom : Firesheep. Cette dernière a pour vocation d'intercepter tous les paquets réseau qui transitent (en clair) sur un hot spot WiFi, de repérer les cookies afin de permettre à tout un chacun et sans aucune connaissance particulière, de se connecter à votre insu, sur votre compte Twitter, Facebook  ...

Je pense qu'une petite vidéo vous permettra d'y voir un peu plus clair ...

Inquiétant non ?

Pas de panique ! Si vous souhaitez vous protéger plusieurs solutions sont envisageables :

  • crypter tout le trafic en utilisant systématiquement un tunnel VPN dès que vous êtes connecté à un hot-spot publique (vous sortez ainsi sur le net par le biais de la connexion de votre boulot par exemple ou bien au travers de la connexion de votre domicile). Il existe également une multitude d'offre sur le net en la matière. L'avantage de cette solution est de vous protéger également de toute interception de mots de passe habituellement véhiculés en clair : POP/IMAP par exemple. Si vous souhaitez en savoir plus vous pouvez consulter le WiKi de @korben en cliquant ICI
  • n'utiliser que le protocole HTTPS pour naviguer sur le net. Pas toujours très simple, heureusement une extension est là pour vous aider. Il s'agit de "HTTPS Everywhere" téléchargeable ICI
  • utiliser une nouvelle extension Firefox permettant de détecter la présence d'un Firesheep au sein d'un hot-spot. Il s'agit de "BlackSheep" (ouais ok ça devient un peu tordu mon truc:-) ). L'extension est téléchargeable ICI . Attention quand même :  Mozilla n'a pas, pour le moment, testé cette extension, moi non plus d'ailleurs et visiblement certains utilisateurs semblent avoir rencontrés quelques problèmes ...

Pour conclure : soyez prudents!

[HOWTO] Automatisez la sauvegarde de vos serveurs avec « Rdiff-Backup »

Si vous administrez des serveurs Linux vous vous êtes déjà probablement interrogé sur la meilleure façon de sauvegarder vos systèmes et données. La télé-sauvegarde est une option particulièrement intéressante. Bien que Rsync paraîsse naturellement le dispositif le mieux adapté à cette tâche une autre solution existe : Rdiff-backup.

Moins connu, ce dernier présente de nombreux avantages : une gestion optimisée des incréments, la création d'un miroir de fichiers ou de répertoires, la gestion automatisée de l'effacement des anciens incréments, la compression des données transférées ... Rdiff-Backup est utilisable en "local" mais également dans le cadre d'un système de télé-sauvegarde. Dans ce cas les échanges sont cryptés en utilisant (de manière transparente) le protocole SSH.

L'objectif de ce how-to est de présenter une méthode permettant de réaliser une sauvegarde à distance, sécurisée, automatisée, sans aucune intervention de la part de l'administrateur (les procédures d'authentification reposant sur un système de clés asymétriques).

La distribution utilisée pour la création de ce how-to est une "Ubuntu 10.04 LTS server", mais il ne devrait pas y avoir beaucoup de différences si vous utilisez un autre Linux. Un serveur SSH doit également être présent sur les 2 machines.

Dernière précision : afin de simplifier cette procédure j'utilise volontairement l'utilisateur "root" pour réaliser la sauvegarde. Pour optimiser la sécurité, les "puristes" pourront bien entendu adapter cette  méthode  avec un autre compte utilisateur ...

Dans le cadre de ce tutoriel nous allons utiliser deux serveurs :

  • "srv-prod ": qui correspond au serveur "à sauvegarder" (IP dans ce how-to : 192.168.0.157)
  • "srv-backup" : qui correspond au serveur destiné à héberger la sauvegarde de srv-prod

On procède tout d'abord à l'installation de "Rdiff-Backup" en lançant (sur les 2 serveurs) la commande

apt-get install rdiff-backup

On va ensuite générer les clés SSH nécessaires à l'authentification de "srv-backup" auprès de "srv-prod". Créez (si ce n'est pas déjà fait) sur "srv-backup" un répertoire nommé "/root/.ssh/". On lance ensuite (sur ce même serveur)  la commande suivante :

ssh-keygen -t rsa -b 4096

Répondez de la manière suivante aux questions posées par l'application :

Enter file in which to save the key (/root/.ssh/id_rsa): /root/.ssh/rdiff_id_rsa

Ne rien mentionner en réponse à la question "Enter passphrase (empty for no passphrase):". Idem pour "Enter same passphrase again:"

Suite à cette opération, vous trouverez 2 fichiers au sein du répertoire "/root/.ssh" :

  • rdiff_id_rsa : qui correspond à votre clé privée
  • rdiff_id_rsa.pub : votre clé publique (qui devra, par la suite, être positionnée sur le serveur de production ...

Pour ce faire il est nécessaire d'éditer le fichier "rdiff_id_rsa.pub" (avec un petit "cat /root/.ssh/rdiff_id_rsa.pub" par exemple). Vous devriez obtenir une chaîne de la forme :

Bien entendu le contenu de votre fichier sera différent car il s'agit de clés générées aléatoirement (heureusement ... 😉 )

Copiez ensuite cette chaîne de caractères afin de pouvoir la coller dans le fichier "/root/.ssh/authorized_keys2" du serveur de production ("srv-prod"). Dans l'hypothèse où ce répertoire (".ssh") et ce fichier ("authorized_keys2") n'existent pas il sera nécessaire de les créer manuellement. Attention aux droits à appliquer sur le fichier "authorized_keys2" qui doivent être positionnés à 644 ("chmod 644 /root/.ssh/authorized_keys2"). Il faut également s'assurer de copier la chaîne de caractères tel-quel sans y ajouter aucun caractère n'y retour chariot.

Une fois la clé copiée, il est nécessaire d'y ajouter (sur "srv-prod") certaines options comme illustré dans l'exemple ci-dessous :

Les directives à placer devant la clé sont les suivantes (il ne vous reste plus qu'à copier / coller ...) : "command="rdiff-backup --server --restrict-read-only /",no-port-forwarding,no-X11-forwarding,no-pty ". Il s'agit de mesures de sécurités complémentaires. En effet le serveur de backup s'authentifiant de manière automatisée, il est intéressant de limiter les opérations réalisables avec ce compte (pas de terminal, opération en lecture seule uniquement, pas de forward de ports ...).

Sur le serveur "srv-backup" créez le fichier "/root/.ssh/config". Ce dernier va intégrer les éléments nécessaires à la connexion automatique au serveur de production. Le contenu de ce fichier est le suivant :

host 192.168.0.157
hostname 192.168.0.157
user root
identityfile /root/.ssh/rdiff_id_rsa
compression yes
protocol 2

Bien entendu vous devez remplacer l'IP (192.168.0.157) par l'adresse de votre serveur de prod (ou bien par son nom pleinement qualifié). Vous pouvez également modifier le paramètre "compression" en le passant à "no" si vous ne souhaitez pas compresser les données échangées entre les deux serveurs.

Créez ensuite, sur "srv-backup" un répertoire au sein duquel seront stockées les données sauvegardées. Par exemple "mkdir /backup"

Il ne reste plus qu'à essayer de générer une sauvegarde d'un des répertoires du serveur de production ("/etc" par exemple) en utilisant une commande du style :

rdiff-backup -v 5 root@192.168.0.157::/etc /backup/etc

Vous allez voir apparaître un message du type :

The authenticity of host '192.168.0.157 (192.168.0.157)' can't be established.
RSA key fingerprint is 60:6b:12:0a:6f:bf:98:da:83:5c:43:16:f2:72:3c:29.
Are you sure you want to continue connecting (yes/no)?

répondez "yes" (cette question ne sera plus posée par la suite). Vous devriez voir la sauvegarde se réaliser. Un petit contrôle du répertoire "/backup/etc" confirme la présence des fichiers.

Vous pouvez automatiser (via le crontab) cette tâche de sauvegarde en vous inspirant, après adaptation, de ce script (merci à  @ledeuns pour sa contribution ) :

#!/bin/bash</p>
RETCODE=""

### Sauvegarde ###

/usr/bin/rdiff-backup  root@192.168.0.157::/var /backup/var
if [ $? -ne 0 ]; then RETCODE="VAR;"; fi
/usr/bin/rdiff-backup  root@192.168.0.157::/etc /backup/etc
if [ $? -ne 0 ]; then RETCODE="ETC;$RETCODE"; fi
/usr/bin/rdiff-backup root@192.168.0.157::/home /backup/home
if [ $? -ne 0 ]; then RETCODE="HOME;$RETCODE"; fi
/usr/bin/rdiff-backup root@192.168.0.157::/root /backup/root
if [ $? -ne 0 ]; then RETCODE="ROOT;$RETCODE"; fi
/usr/bin/rdiff-backup root@192.168.0.157::/usr /backup/usr
if [ $? -ne 0 ]; then RETCODE="USR;$RETCODE"; fi

### Effacement des increments datant de plus de 2 semaines (2W) ###

/usr/bin/rdiff-backup --force --remove-older-than 2W /backup/var/
if [ $? -ne 0 ]; then RETCODE="DELVAR;$RETCODE"; fi
/usr/bin/rdiff-backup --force --remove-older-than 2W /backup/etc/
if [ $? -ne 0 ]; then RETCODE="DELETC;$RETCODE"; fi
/usr/bin/rdiff-backup --force --remove-older-than 2W /backup/home/
if [ $? -ne 0 ]; then RETCODE="DELHOME;$RETCODE"; fi
/usr/bin/rdiff-backup --force --remove-older-than 2W /backup/root/
if [ $? -ne 0 ]; then RETCODE="DELROOT;$RETCODE"; fi
/usr/bin/rdiff-backup --force --remove-older-than 2W /backup/usr/
if [ $? -ne 0 ]; then RETCODE="DELUSR;$RETCODE"; fi

### Envoi du rapport par mail ###

if [ -z $RETCODE ]; then
echo "" | mail -s "Sauvegarde effectuee" votre@adresse.fr
else
echo "$RETCODE" | mail -s "Sauvegarde en erreur" votre@adresse.fr
fi

Ce how-to n'ayant pas vocation à décrire d'une manière exhaustive le fonctionnement de Rdiff-Backup, je vous invite à consulter le manuel détaillé disponible à cette adresse (vous pourrez y découvrir l'ensemble des commandes et options disponibles) !

  • Le site officiel est disponible ICI

« Microsoft Live Services » : utilisez des mots de passe à usage unique !

Le fait de s'authentifier avec un simple mot de passe sur un PC "publique" (cybercafé, bibliothèque, hôtel ...) peut présenter des risques importants d'interception des identifiants de connexion (de part la présence d'un keylogger ou toute autre saloperie du même type ... ) Pour pallier à ce problème il existe une technique particulièrement efficace : les mots de passe à usage unique (aussi apellés OTP pour "One time Password").

Le principe est simple : le mot de passe que vous utilisez n'est valable qu'une seule fois et de ce fait même si cette information vous est dérobée elle ne sera pas ré-utilisable. Certains hébergeurs d'email propose ce service à leurs clients depuis un certain temps (c'est le cas de Fastmail par exemple).

Si vous utilisez les services en ligne de Microsoft (Hotmail par exemple) vous allez pouvoir, à votre tour, utiliser un tel système (c'est plutôt une bonne nouvelle juste avant les départs en vacances ...). Le système est pratique et simple d'utilisation (surtout si vous ne suivez pas les indications fournies sur le site ... 😉 )  : sur la page d'authentification, vous choisissez "s'authentifier avec un mot de passe à usage unique", vous renseignez votre identifiant, votre numéro de GSM et vous recevez par SMS un mot de passe valable une seule fois ...

Petite explication en images  ...

  • Il est tout d'abord nécessaire d'associer son numéro de téléphone portable à son compte Microsoft Live. Pour ce faire, connecter-vous à l'adresse http://sms.live.com et suivez les indications. Ne vous inquiétez pas si à l'issue de cette opération vous recevez un message vous indiquant que le service SMS n'est pas disponible dans votre zone géographique, tout fonctionne bien quand même ... Petit rappel : le système attend un numéro (au format "international") de la forme +336... (et pas un 06...)

  • l'opération d'association du numéro étant réalisée, vous pouvez tester immédiatement ce nouveau mode d'authentification. Au sein de la fenêtre de connexion cliquez sur le lien "obtenir un code à usage unique ..."

  • Mentionnez ensuite votre identifiant Live et cliquez sur "demander un code"

  • Il ne vous reste plus qu'à saisir votre numéro de GSM (celui qui a été précédemment associé à votre compte) et de cliquer sur "Envoyer un SMS" pour recevoir votre mot de passe qui pourra être saisi au sein de l'écran précédent !
  • Je trouve ce système particulièrement pratique et efficace (dommage que je n'utilise aucun service MS Live ... 😉  )

    Une question me vient immédiatement à l'esprit : "Mais qu'est-ce qu'attend Google pour proposer ce type de fonctionnalité ????"

Failles de sécurité Acrobat et Flash : petit guide de survie !

Vous avez certainement vu passer cette info : Acrobat Reader et Flash Player présentent (une fois de plus) des failles de sécurité importantes. L'affaire est d'autant plus sérieuse que les exploits sont désormais largement disponibles et donc à la portée de tous ...

Adobe a annoncé la publication d'un correctif pour Flash Player dès le 10 juin. Il y a donc de fortes chances pour que la faille soit comblée au moment où vous lirez ces lignes (n'oubliez pas de mettre à jour ...). En attendant essayez de limiter vos consultations aux seuls sites de confiance ! Si vous utilisez Firefox vous pouvez également installer NoScript afin de vous protéger (ce plug-in est téléchargeable ICI).

Le problème est différent pour Acrobat Reader : l'éditeur ne prévoit pas de correctif avant le 29 juin !!! Il est donc important de prendre quelques mesures de précaution.

La faille de sécurité en question utilise le fichier "authplay.dll". Il est donc conseillé de supprimer (ou de renommer) ce fichier afin de limiter le risque (par contre vous risquez de voir planter Acrobat Reader si vous tentez d'ouvrir un PDF intégrant du Flash mais bon ça ne me semble pas très grave ...).

  • Sous Windows, ce fichier se trouve à cet emplacement : "C:\Program Files\Adobe\Reader 9.0\Reader\authplay.dll for Adobe Reader or C:\Program Files\Adobe\Acrobat 9.0\Acrobat\authplay.dll"
  • Sous Linux : à partir du répertoire d'installation du reader : "Reader9/Reader/intellinux/lib/" (effacer le fichier nommé "libauthplay.so.0.0.0")

Et si vous en profitiez pour remplacer votre lecteur PDF par une solution libre certainement moins sensibles aux attaques ? Quelques pistes ICI ...

UPDATE du 11/06 : la mise à jour (10.1) de Flash Player est désormais disponible ICI

Spam Test … Les résultats après une année.

Durant le mois d'avril 2009 (il y a exactement 413 jours) je lançais une petite expérience visant à vérifier dans quelles conditions une adresses e mail mentionnée (en clair) sur un site web était utilisée par les spammeurs. Je ne vais pas vous expliquer à nouveau les conditions de cette expérimentation, ceux qui n'ont pas suivi le premier épisode peuvent aller faire un petit tour ICI.

Après une année d'expérimentation, les résultats sont les suivants :

Pour l'adresse n'étant pas protégée par greylisting (uniquement SpamAssassin) :

  • nombre total de spams reçus durant la période : 1 942
  • nombre de spam / jour (moyenne) : 4,7
  • nombre de spams détectés par "SpamAssassin" : 1 861
  • taux de détection des spams par "SpamAssassin" : 96%
  • nombre de spams non détectés : 81

Pour l'adresse protégée par greylisting (SpamAssassin + Postgrey) :

  • nombre total de spams reçus durant la période : 298
  • nombre de spam / jour (moyenne) : 0,72
  • nombre de spams détectés par "SpamAssassin" : 207
  • taux de détection des spams par "SpamAssassin" : 69%
  • nombre de spams non détectés : 91

On peut donc en conclure qu'une adresse e mail utilisée "en clair" sur une page web est assez rapidement victime de spam (on s'en doutait un peu ...). Heureusement, les outils disponibles (SpamAssassin et Postgrey dans mon cas) remplissent bien leur mission (96% de taux de détection pour Spamassassin). La technique du "greylisting" est quand à elle particulièrement utile, surtout pour les administrateurs car elle permet de diminuer, d'une manière significative, la charge des serveurs de messagerie !

Photo : Yogma

Quatre licences NOD32 « Smart Security » à gagner !

Avec quelques jours de retard le Père Noël vient de passer sur le blog ...

Vous connaissez l'anti-virus Eset NOD32 mais vous n'avez jamais eu l'occasion de le tester ? La société ATHENA Global Services (l'importateur français de cette solution) m'a gentiment fourni 4 licences (valables 1 an) de la suite de sécurité "Eset NOD32 Smart Security"* que j'ai décidé d'offrir aux lecteurs de mon blog.

Comment faire pour participer ? C'est très simple, il suffit de poster un commentaire en mentionnant votre adresse email. J'effectuerais un petit tirage au sort dans le courant de la semaine prochaine (les gagnants recevront leur licence par mail) !

Découvrir "Eset NOD32 Smart Security" : cliquez ICI

EDIT du 10/1/2010 :

Bon je viens de procéder au tirage au sort (vu le nombre de réponses ça n’a pas été trop compliqué ;-) ).

Les gagnants sont :

- Romain
- Sandrine
- Greg
- The Bloom

Je vous fait passer les licences demain (lundi 11/1) dans la journée par mail !

Crédit photo : fdecomite