Les bornes WiFi publiques (celles ou vous ne rentrez pas de clé WEP ou WPA lors de la connexion) peuvent vraiment dépanner, mais présentent aussi un risque non négligeable. En effet, les données que vous échangez avec la borne se baladent dans l’air sans être cryptées, et peuvent très facilement être interceptées. Dans cet article, je vais présenter rapidement la démarche à suivre pour snifer une connexion, et se connecter à la place d’une victime sur son compte facebook.

Pour snifer une connexion WiFi, nous allons avoir besoin des outils suivants : airmon-ng qui est disponible dans la suite aircrack-ng, avec une carte WiFi compatible avec le mode monitor, et de wireshark

Il faut commencer par passer sa carte WiFi en mode monitor avec la commande suivante (à adapter avec le nom de votre carte WiFi)

# airmon-ng start wlan0

Si tout se passe bien, airmon passe alors votre carte WiFi en mode monitor, en disant quelque chose de semblable à ça : « (monitor mode enabled on mon0) ». Il faut alors prendre note du nouveau nom de l’interface, dans mon cas mon0.

Il faut ensuite lancer wireshark, et lancer la capture sur l’interface en mode monitor, mon0 dans mon cas. Wireshark va alors lister tout ce qui passe dans l’air.

Pour les exemples, voilà quelques cas fait sur mon ordinateur en local, mais ceci ne change rien par rapport aux paquets issus d’un WiFi public.

Sur ces screenshots, nous pouvons voir ce qui se passe lors d’une connexion à un serveur FTP, et une connexion à un site quelconque. Et le nom d’utilisateur ainsi que son mot de passe ( « test » sur les images) apparaissent en clair, pas très sécurisé tout ça … Et c’est le cas avec TOUTES les connexions à des site internet n’utilisant pas le ssl (adresse en https://)

Poussons le vice un peu plus loin, certains sites, comme facebook, proposent de rester connecté pour les prochaines visites, on ne verra donc pas le mot de passe. Nous allons donc récupérer le cookie, et le mettre dans firefox pour avoir accès à la page facebook de notre victime, et pouvoir faire ce que l’on veux sur sa page. (testé ce matin pendant un cours, et ça marche ^^)

Pour chercher dans la grosse quantité d’information dans wireshark, il est possible d’utiliser le filtre « http contains facebook ». Il faut alors chercher une page qui contient un cookie, comme la page d’accueil.

Sur la ligne cookie, faire clique droit, copier.

Le cookie de la victime est alors récupéré, il n’y a plus qu’à le mettre dans notre navigateur préféré, comme Firefox (aussi compatible avec Epiphany). Firefox gère les cookies dans des fichiers sqlite, j’ai donc écrit rapidement un petit script pour créer un fichier de cookie et y insère automatiquement les données extraites de wireshark dedans. Le script est téléchargeable ici, et nécessite d’avoir le programme sqlite3.

Il faut l’exécuter en lui donnant en paramètre le domaine du site auquel appartient le cookie, il faut coller le cookie issu de wireshark dans un fichier nommé « cookies.txt » dans le même répertoire que celui du script, et le script créé un fichier « cookies.sqlite ». Pour notre cas :

$ ./dump2sqliteCookie.sh .facebook.com

Il faut ensuite déplacer le cookie généré à la place de celui de firefox dans le dossier « ~/.mozilla/firefox/********.default/ ». Puis relancer firefox, et aller sur la page http://www.facebook.com et vous devriez arriver sur le mur facebook de votre victime avec le possibilité de faire n’importe quoi.

Comme vous pouvez le voir, cette manipulation reste relativement simple, et ne nécessite aucun piratage de machines. De plus, là j’ai présenté une version « artisanale », il doit très certainement y avoir des outils qui font tout ça automatiquement. Il est donc préférable de réfléchir à 2 fois avant d’utiliser un réseau WiFi public, et de ne pas échanger de données sensibles dessus.

Il faut toute fois noter que sur les sites internet en https, il n’est pas possible de récupérer les données de cette manière. Pour protéger la totalité du trafic, on peut aussi envisager de mettre en place un tunnel ssh qui permet de crypter la totalité du trafic entre votre machine, et celle qui héberge le serveur ssh, donc sur toute la zone critique entre vous et la borne WiFi.

Introduction :

Fail2ban est un programme qui lit les fichiers log de serveurs de votre machine (apache, ssh,…) pour bannir temporairement les ip de machines qui tentent de se connecter à votre ordinateur. En d’autres termes, celui qui essaye différents mots de passe pour se connecter à votre machine ne pourra pas le faire longtemps (avec la même ip du moins !).

Est-ce vraiment utile ? :

Partons sur quelque chose de simple : on utilise un mot de passe de 8 caractères ; on utilise uniquement les 26 lettres de l’alphabet (en minuscule) et les 10 chiffres, soit 36 caractères ; ce qui donne au final 36^8 combinaisons possibles (environ 3000 milliards de mots de passe).

En sachant que par défaut, Fail2ban bloque une ip pendant 600 secondes (10 minutes) au bout de 3 tentatives infructueuses, on a alors :

- si la personne ne change pas d’ip, il lui faudra plus d’1 million d’années
- si la personne arrive à changer d’ip toute les secondes, il lui faudra 30.000 ans et au minimum 600 ip différentes

Donc, en gros (sauf erreur de ma part), essayer de forcer le mot de passe par brute force sur une machine avec Fail2ban, c’est pas gagner !
Par contre, sans Fail2ban, si on peut essayer 10 millions de mots de passe par seconde, en maximum 3 jours c’est fini ! (bon, après, 10 millions par secondes, ça fait beaucoup…).

À noter que souvent, par défaut, les services font en sorte qu’on ne puisse essayer un mot de passe que toute les 2 ou 3 secondes, ce qui normalement suffit contre le brute force, mais on est jamais trop prudent !

Bon, laissons tomber ce paragraphe qui a essayé d’être une pseudo démonstration de l’intérêt de Fail2ban (en espérant en avoir convaincus certains !) pour passer à son installation.

Installation :

Coté installation, rien de bien compliqué, le paquet est présent dans les dépôts de la plupart des distributions GNU ; ainsi, il suffira de faire sur Debian/Ubuntu :

$ aptitude install fail2ban

Ensuite, vérifier qu’il est bien lancé avec la commande (en root) :

$ /etc/init.d/fail2ban status

ou

$ fail2ban-client status

Configuration :

Pour ceux qui ne veulent pas se prendre la tête, ils peuvent s’arrêter tout de suite : les réglages par défaut vont très bien !

Pour les autres, les 2 fichiers a modifier sont :

–> /etc/fail2ban/fail2ban.conf :

Ici, pas grand chose à régler :

- loglevel (niveau de détail des logs) : il est par défaut à 3 (info)
- logtarget (emplacement du fichier log de Fail2ban, pour savoir ce qu’il fait) : il est par défaut égal à /var/log/fail2ban.log
- socket par défaut égal à /var/run/fail2ban/fail2ban.sock

–> /etc/fail2ban/jail.conf :

Plus intéressant, ce fichier contient :

- ignoreip : liste des ip que Fail2ban ignore (pratique si on est en ip fixe et que l’on ne se souvient jamais de ses mots de passe !)
- bantime : temps durant lequel une ip est bannie (en seconde)
- destemail : adresse mail pour recevoir les notifications
- liste des services à analyser avec :

• enabled : autoriser Fail2ban a surveiller ce service
• port : port
• filter : fichier filtre utiliser (ils sont stockés dans /etc/fail2ban/filter.d)
• logpath : emplacement du fichier log du service
• maxretry : nombres de tentatives avant de bannir l’ip

Il est de plus conseillé d’enregistrer ces 2 fichiers de configuration sous le nom de fail2ban.local et de jail.local pour qu’ils ne soient pas effacer lors d’une mise à jour du programme !

Voilà, je crois que vous savez tout !

N’hésitez pas à me signaler un éventuel oubli ou erreur en commentaire !

Plus d’infos :

Manuel de Fail2ban (en)

Introduction :

Tout le monde utilise un service de messagerie instantanée pour discuter, mais peu savent qu’en réalité, leurs conversations circulent en clair sur le réseau.
Vous me direz après tout : « Ce n’est pas bien grave, je ne fais rien de mal ! » mais est-ce vraiment une bonne raison ? Si vous discutez dans la rue avec un ami, vous n’aimez pas forcement que des gens s’arrêtent pour écouter ; et bien la c’est pareil !
Voyons donc comment on peut arranger tout ça :

GnuPG :

Pour créer les clefs nécessaires au filtrage, nous allons utiliser GnuPG et son GUI GPA (The GNU Privacy Assistant).
Commencez donc d’abord par installer les 2 paquets en question :

$ aptitude install gnupg2 gpa

Ensuite, ouvrez GPA.

Et créez une nouvelle paire de clef pour chiffrer vos conversations (le principe de clef public / clef privée ne sera pas expliqué ici) : Clefs > Nouvelle Clef ; puis remplissez comme tel.

Vous voilà maintenant avec votre paire de clef prête à servir !

L’échange de clef :

Il va falloir maintenant faire parvenir votre clef publique à votre ami (oui, il faut un ami pour faire ça !) et lui va vous faire parvenir la sienne (qu’il aura crée de la même façon).

Pour cela, rien de plus simple :

Dans GPA, faites un clic droit sur la clef Gajim Pseudo, puis Exporter la clef.
Enregistrez là puis faites la parvenir à votre ami (par mail, clef USB, pigeon voyageur, …) et une fois la clef en sa possession faites (toujours dans GPA), Clefs > Importer une clef ; et vous devriez alors voir votre clef ajouter à la liste.

Configuration de Gajim :

Il ne reste plus qu’a configurer Gajim :

• Commencer par lui renseigner votre clef personnelle : Édition > Comptes > Choisissez votre compte > Informations personnelles > Choisissez une clef > Choisissez votre clef (vous pouvez également lui faire retenir le mot de passe de la clef pour ne pas à avoir à le retaper à chaque fois)

• Associez ensuite la clef de votre ami à son compte : faites un clic droit sur son pseudo > Assigner une clef OpenPGP > Choisissez la clef de votre ami

Et voilà, c’est fini, vous avez accès au bouton magique qui doit être activé pour que la discussion soit chiffrée :