« Live USB Tails », se protéger des « robots scanners » et de l’espionnage massif sur le Web!

Dernière modification le 12 janvier 2019

Bonjour,

Beaucoup d’entre vous ont certainement entendu parler de la distribution « Tails » (Linux) conçue pour préserver et améliorer l’anonymat et la sécurité de la vie numérique d’un internaute sur le Web et le « DarkWeb ». Aujourd’hui, nous allons découvrir pas à pas l’installation de la distribution « Tails » (Debian) sur une clé USB (Live USB), à partir d’une machine virtuelle. Parmi les risques les plus répandus sur le Web et le Darknet, les « robots scanners » sont en tête du Hit Parade avec l’espionnage massif initié par divers organismes gouvernementaux et opérateurs du Net plus ou moins officiels… Comment s’en protéger ?

Au terme de cette installation, je vous proposerai la mise en œuvre de deux scripts « Bash Linux » (TP) qui vous permettront d’optimiser la protection de votre anonymat, de bloquer les « robots scanners » en ligne et de « blacklister » des listes d’adresses IP notamment celles des institutions fédérales US ! L’objectif de ces TP est multiple, puisque vous serez en mesure de créer et d’alimenter vos propres « blacklists » au fil du temps !

Pour ceux et celles qui n’ont jamais touché au langage « Bash Linux » rassurez-vous, j’ai choisi d’adopter une approche « fun » et plus souple. Je ne vous demanderai pas d’apprendre par cœur le langage Bash Linux, ce serait faire preuve de stupidité ! (humour) Non, l’objectif est que vous compreniez et assimiliez les structures Bash Linux sous forme de « pseudo langage ». Voici un exemple type de la démarche que j’emploierai. Si je souhaite afficher à l’écran un message à l’aide de mon propre langage d’humain, j’écrirai en « pseudo langage » quelque chose du genre:

Pseudo langage humain: Afficher le message à l’écran: ‘ Je suis un visiteur fan et assidu du Blog du Hacker ! ‘

Traduction en langage Bash Linux: echo ‘ Je suis un visiteur fan et assidu du Blog du Hacker ! ‘

Sans connaître le langage Bash Linux, dans cet exemple tout le monde peut par comparaison se dire que echo est une commande Bash Linux qui permet d’afficher le texte Je suis un visiteur fan et assidu du Blog du Hacker ! à l’écran

Au terme de cette méthode d’apprentissage du langage « Bash Linux », vous serez capable de comprendre, d’écrire et d’exécuter les deux scripts Bash Linux afin d’atteindre l’objectif fixé. Etes-vous rassurés ?!?

Avant de démarrer une cascade d’opérations techniques relativement amusantes, je vous invite à prendre connaissance des risques du Web et d’une protection VPN ici Notes de sécurité avant d’installer Tails (Debian). Ces notes d’avertissement liées aux risques du Web et du « DarkWeb » sont très importantes, car elles conditionnent la réalisation de cette installation dans des conditions optimales de sécurisation et de protection de vos données personnelles ainsi que de votre environnement matériel et logiciel !

Je vais certainement vous paraître paranoïaque dans la manière d’aborder cet article, certes ! Quoi qu’il en soit vous vous rendrez compte à travers cet article qu’il est préférable d’être prudent et très vigilant ! (humour).

La grande majorité des utilisateurs de « Tails » (Debian) ont pour habitude généralement de démarrer cette distribution « Tails Live CD » ou « Tails Live USB » directement sur une machine hôte, afin de bannir provisoirement le système d’exploitation installé sur la partition système de la machine hôte (physique) et ne laisser aucune trace de leur passage « furtif » sur le Web ou le « DarkWeb ». Ma position (avis personnel) ici risque de vous sembler étrange. Effectivement, le fait d’utiliser une distribution « Tails » montée sur une « clé Live USB » ou un « Live CD » chez soi, et la démarrer directement sur une machine hôte (Tour, PC) se révèle être très risqué ! Sans rentrer dans des explications trop techniques, je pars du principe que les lectrices et les lecteurs de cet article sont de niveau débutant, c’est en partie pour cette raison que je conseille vivement de suivre cette installation de « Tails » sur une machine virtuelle (Virtualbox ou VMWARE). Dans le cadre de cet article, j’ai réalisé mon installation à partir de « VMWARE WORKSTATION 12 PRO). Pour ceux et celles qui souhaiteraient installer la version d’essai (30 jours) de VMWARE rendez-vous ici Installation VMWARE (version d’essai)

Afin de ne pas m’étaler sur des aspects trop anxiogènes et limiter le volet de l’installation de cette distribution « Tails » (Debian), j’ai décidé d’enclencher le mode « Turbo ». Pour ceux et celles qui auraient quelques difficultés liées à cette phase d’installation, je vous invite à me solliciter en laissant un commentaire. Rassurez-vous, en fonction de votre demande, je serais en mesure de vous transmettre une réponse personnalisée par mail accompagnée de belles images explicatives !

Pré-requis

une machine hôte tournant sous « Microsoft Windows » ou distribution « GNU/Linux » (installation réalisée sous Windows 8.1 Pro)
une machine virtuelle sans disque dur virtuelle, 4 Go de mémoire vive, 2 cœurs dédiés au processeur (installation réalisée sous VMWARE WORKSTATION ici)
un client VPN installé sur la machine hôte (!!! Sans Client VPN je déconseille de continuer !!!)
le fichier d’installation ISO « Tails 2.3 » (ou Tails 2.4) ici
le fichier ISO de l’utilitaire « Plop Boot Manager » intitulé plpbt-5.0.15.zip ici
une clé USB de capacité minimum de 4 Go formatée et vierge ! (installation réalisée sur une clé USB de 16 Go)

Note importante: Certaines personnes ont certainement éclaté de rire quand j’ai posté ces mots « formatée et vierge ! », bien évidemment si j’ai autant insisté sur le ton de l’humour c’est pour vous éviter de drôles de surprise durant l’introduction des phases d’installation de « Tails » ! Nous verrons plus loin comment renforcer à l’aide de scripts « Bash linux » la sécurité réseau de « Tails », notamment en bloquant les « robots scanners » de ports en ligne couramment scannés, et en détectant un trop gros volume de paquets TCP avec les flags SYN et/ou ACK et/ou FIN et/ou RST « armés ». Je proposerai pour les plus passionnés d’entre vous un script Bash Linux permettant de BLOQUER manuellement une adresse IP publique qui sera automatiquement enregistrée dans une « blacklist » (fichier texte) ou encore de BLOQUER des IP à partir de vos propres listes d’adresses IP (Blacklists IP d’institutions gouvernementales US notamment!)

Pour bien cerner l’environnement réseau à travers lequel nous allons déployer cette installation, je vous propose un schéma ci-dessous qui vous permettra d’y voir un peu plus clair (humour)

Débutons l’installation de Tails en Live USB !

I. Téléchargement du fichier ISO « Tails 2.3 »

Ici j’ai volontairement débuté mon installation sur la version « Tails 2.3 » afin de vous montrer par la suite la séquence de mise à jour automatique vers la dernière mouture « Tails 2.4 ». Si ce n’est pas déjà fait, rendez-vous sur la page Web officielle ici:

II. Configuration de l’interface réseau virtuelle VMWARE sur « VMNet8 (NAT) »

4 Go de mémoire vive et 2 cœurs dédiés au processeur. J’ai choisi de paramétrer cette interface réseau en utilisant le DHCP par translation d’adresse NAT de VMWARE par mesure de sécurité. De cette façon, toutes les connexions vers l’extérieur (hors de la machine hôte) émises par la machine virtuelle « Tails » seront protégées par la connexion VPN installée en amont sur la machine hôte (physique). Le but ici est de permettre à « Tails » de transiter en amont par un tunnel VPN avant d’accéder au « DarkWeb » via le réseau Tor (proxies) ! Vous remarquerez que j’ai supprimé le disque dur virtuel de cette VM, ceci pour des raisons de sécurité puisque nous n’en aurons pas besoin ici:

Afin de RENFORCER LA SÉCURITÉ RÉSEAU de cette VM avec « Tails », il est recommandé de JUGULER le DHCP (NAT) VMWARE à une seule et unique adresse IP. Comme vous pouvez le voir ci-dessous, j’ai fixé mon DHCP avec une adresse de début en 192.168.99.99 et une adresse de fin à 192.168.99.100 laissant ainsi une seule adresse IP interne de disponible EXCLUSIVEMENT dédiée à « Tails »:

III. Montage du fichier ISO « tails-i386-2.3 » sur le lecteur CD/DVD VMWARE

IV. Connexion de la clé USB sous VMWARE afin d’installer « Tails 2.3 »

V. Démarrage de la machine virtuelle « Tails 2.3 » sous VMWARE

Par défaut, lorsqu’une machine virtuelle démarre sous VMWARE vous ne verrez jamais l’interface Utilisateurs Bios VMWARE affichée ci-dessous car le délai d’affichage par défaut est nul. Certains utilisateurs de VMWARE préfèrent avoir accès directement à ce menu Bios VMWARE ci-dessous, sans être contraint de passer par le menu « Start Up / Power On to Firmware » que j’ai affiché plus haut (chapitre IV). Voici la méthode que vous pourrez utiliser pour chaque VM.

Note importante: ! ATTENTION ! Suivez exactement la procédure que je vais décrire ! Si vous loupez une étape, cela risque de mettre le boxon dans VMWARE !

Rendez-vous dans le Dossier de votre machine virtuelle, normalement situé dans:

C:\Utilisateurs\ »nom utilisateur »\Mes Documents\Virtual Machines\ »nom du dossier où est stocké votre VM Tails »

Vous devriez avoir ces fichiers VMWARE ci-dessous. Celui qui nous intéresse se somme ici « Boot-Tails-USB.vmx« . N’ouvrez pas le fichier ‘ .vmxf ‘ ou ‘ .vmsd ‘ ou un autre !

!!! ATTENTION !!!

Choisissez l’application « Bloc-notes » Windows ET DÉCOCHEZ » Utiliser cette application pour tous les fichiers .vmx « .

Ajouter dans le fichier ‘ .vmx ‘ de votre VM Tails la ligne de commande suivante (un espace avant et après le =) puis enregistrez le fichier ‘ .vmx ‘:

bios.bootdelay = 15000

Vous devriez normalement voir apparaître le menu « PhoenixBIOS VMWARE » ci-dessous au démarrage de la VM. Ainsi vous allez pouvoir sélectionner le démarrage de la VM sur le lecteur « CDROM » qui pointe le fichier ISO Tails 2.3 que nous allons installer juste après.

VI. Configuration du mot de passe d’administration « Tails », du réseau, du mode « Usurper toutes les adresses MAC » et démarrage de l’installation

VII. Extinction de « Tails »

Ici nous allons devoir redémarrer sur la clé Live USB Tails sous VMWARE, pour ce faire nous allons avoir besoin d’utiliser le fichier ISO de l’utilitaire « Plop Boot Manager ». Ce dernier va donc nous servir à booter la clé « Live USB Tails » que nous venons d’installer avec « Tails 2.3 » à partir de la machine virtuelle VMWARE. A ce stade, la VM « Tails est éteinte ». Vous pouvez retirer la clé USB Tails.

VIII. Montage du fichier ISO « Plop Boot Manager » plpbt.iso sous VMWARE

Démarrage de la VM avec « Plop Boot Manager » (fichier iso « plpbt.iso »), rebranchez votre clé Live USB Tails, connectez la clé USB Tails sous VMWARE, puis sélectionnez dans le menu l’option « USB » ci-dessous. Normalement, « Tails » devrez redémarrer !

IX. Configuration du volume de stockage persistant

Ce volume de stockage persistant permettra de sauvegarder vos données utiles même après l’extinction de la clé Live USB Tails:

X. Installation finalisée, « Tails 2.3 » démarre, « Tor Browser Bundle » est opérationnel

XI. Mise à jour automatique de « Tails 2.3 » vers « Tails 2.4 »

XII. Sauvegarde de sa clé Live USB Tails

Pour des raisons évidentes de sécurité (crash ou perte de votre clé USB durant vos manipulations), je vous invite à cloner (sauvegarde) dès à présent votre clé Live USB Tails 2.4. Pour ce faire il existe plusieurs utilitaires gratuits disponibles en ligne, ci-dessous j’ai utilisé « USB Image Tool ».

XIII. Vérification manuelle des connexions réseau (Tor) via une console Terminal (en tant qu’Administrateur) et de l’isolation réseau entre la « VM Tails 2.4 » et la machine hôte (physique)

Dans ce volet relativement technique je vais tenter de synthétiser mon approche en effectuant une démonstration (un exemple) permettant de savoir si oui ou non votre connexion sur le réseau Tor est conforme et sûre. Attention, je tiens à souligner qu’à travers cette démonstration je vais engager volontairement une opinion personnelle, libre à vous d’en tenir compte ou pas ! Comme vous pouvez le constater ci-dessous, au démarrage de ma clé Live USB Tails apparaît une connexion active vers un serveur Proxy hébergé chez « OVH SAS » sur le port HTTPS 443. Sans rentrer dans une polémique, il faut savoir qu’en France « OVH » applique des mesures strictes de filtrage et de vérification du trafic émis depuis le serveur utilisé par le Client vers le port 25 (« espionnage »!!??!!). Personnellement, je n’ai aucune confiance à « OVH » et autres opérateurs du Net ! Nous verrons plus loin dans cette démonstration, à l’aide de TP « Bash Linux » comment y remédier. Toujours est-il qu’une connexion vers un serveur proxy conforme sur le réseau Tor doit normalement échanger les données sur le port 9001 (et non sur le port 443). En LOCALHOST sur Tails, comme vous le savez certainement le port 9150 est configuré automatiquement à travers le navigateur « Tor Browser Bundle » (TBB) dédié aux services « Socks ».

Notes importante: Un des pré-requis que j’ai posé au tout début de cet article concernant l’installation préalable d’un « Client VPN » sur la machine hôte est nécessaire et impératif, notamment pour éviter d’être BLOQUE par votre FAI durant votre navigation sur le réseau Tor via la distribution Tails ! (certains opérateurs du Net ont l’intention de pratiquer ce même genre de censure « sauvage »…).

IP 51.254.218.247 d’un serveur proxy Tor hébergé chez « OVH SAS » (port 443!)

IP 212.83.177.183 d’un serveur Proxy hébergé chez « FREE SAS » (port 4430!)

IP 178.79.161.177 attribuée et gérée par l’organisme Officiel Européen RIPE sur le port 9001, ça rassure !!!

Afin de rassurer les plus paranoïaques d’entres vous sur l’utilisation de « Tails » à travers une machine virtuelle, j’ai pu tester durant 1 semaine l’isolation de ma VM « Tails » (VMWARE) et de ma machine hôte (physique) en exécutant des analyses réseau à l’aide de l’utilitaire bien connu « WIRESHARK« . Comme vous pouvez le voir ci-dessous, SEULE l’adresse IP 178.79.161.177 sur le port 9001 (échange de données via le réseau Tor / Tails) est active et échange avec l’adresse IP interne 192.168.99.99 (interface réseau VMWARE VMNet8 NAT) de ma VM (Tails). Je n’ai décelé aucune fuite réseau entre la VM « Tails et la machine hôte, ni au niveau du système d’exploitation hôte Windows, étant donné que j’ai en parallèle mis en place une SURVEILLANCE DRASTIQUE de tous les processus, services, drivers et fichiers sensibles (Windows et fichiers personnels) grâce à l’utilitaire « PATRIOT NG« .

Faisant partie moi-même du clan des paranoïaques, j’ai volontairement sniffé mon réseau via l’utilitaire « Netdiscover » sous « Tails » afin de TESTER la fiabilité, la stabilité et le comportement de ma machine hôte. Pour ce faire, j’ai utilisé l’outil gratuit « XARP » installé sur ma machine hôte (Windows 8.1 Pro) afin de détecter mon « sniff » (humour). Comme vous pouvez le constater à nouveau le « sniffing » (Netdiscover sous Tails) est bien détecté par « XARP » sur la machine hôte, mais apparaît en « vert », normal ! Seules les 3 adresses IP internes de mon interface réseau VMWARE (VMNet8 NAT) sont détectées, tout est normal ! Ce test démontre notamment qu’aucune adresse IP interne du DHCP VMNet8 (NAT) n’est disponible pour un éventuel « attaquant » qui ne pourra bien évidemment pas RÉALISER D’ATTAQUES « ARP POISONNING », étant donné qu’il lui sera IMPOSSIBLE d’obtenir une adresse IP en local sur le DHCP VMWARE ! Si cela peut vous rassurer, je me suis moi-même lancé toute une série d’attaques « ARP POISONNING » via une autre VM à l’aide de l’outil « Cain & Abel ». Résultat, « XARP » a bien détecté quelques attaques de type « ARP » sur l’IP 192.168.99.1, mais aucune attaque « ARP POISONNING » n’a pu aboutir ! Normal ! Je vous rappelle que cette simulation d’attaques « ARP Poisoning » ne peut se faire normalement que par le biais d’un réseau sans fil (Wifi) chez un particulier. Ici j’ai simplement souhaité tester la solidité et la fiabilité de mon environnement réseau local ainsi que le comportement d’une machine virtuelle « Tails » (Debian) et d’une machine hôte tournant sous Windows face à une attaque « ARP Poisoning ».

Continuons le délire du « parano total » en lançant un « zenmap » sur l’adresse IP locale 127.0.0.1 sous Tails. Nous sommes rassurés puisque 999 adresses IP internes ont bien été filtrées, seul le port 9050 du Proxy Tor est détecté mais impossible d’y accéder car bloqué, le port 9150 du « Service Sock Tor » est protégé.

Testons avec l’utilitaire « zenmap » l’adresse IP 192.168.1.31 de ma machine hôte sur le réseau privé. Tout semble OK puisque le port 53/TCP (DNS) est filtré ainsi que le port 514 TCP du Service Shell. Les autres ports détectés ne sont pas inquiétants étant donné qu’ils ne sont pas fonctionnels (135 RDP désactivé, 5357 SSDP/UPnP désactivés sur les services Windows, VNC inutilisable). Rassurez-vous, sous Linux nous n’avons pas ce genre de souci!

Note importante: Attention, certains systèmes ont des comportements inverses auxquels il faut être vigilant puisque un scan de ports affichant par exemple 1000 ports ouverts et 3 ports fermés ou filtrés peut signifier en réalité l’inverse c’est à dire que les 3 ports sont ouverts !

Pour ceux et celles qui souhaiteraient réaliser un test en ligne des ports ouverts et fermés sur Tails, voici le résultat du test en ligne rendu par un site Web connu (Zebulon.fr) réalisé sur ma VM « Tails ». Comme vous pouvez le voir tout est normal, seuls les ports 80 « HTTP » et 443 « HTTPS » sont ouverts. Certains d’entre vous vont certainement trouver bizarre le fait que le test en ligne ci-dessous n’affiche aucun ports fermés ?

Question pour un Champion. Pourquoi !?! (la réponse est dans l’article, répondez-moi dans un commentaire svp)

A ce stade des opérations nous pouvons affirmer sans trop prendre de risque que notre environnement réseau et système (machine hôte Windows et VM Tails) est sécurisé. Si vous avez suivi mes recommandations en tout début de cet article, je vous rappelle qu’une protection par connexion VPN est impérative mais qu’elle ne doit pas conduire à une confiance « aveugle » de l’usager… Il arrive parfois qu’une connexion VPN se coupe pour de multiples raisons à l’insu de l’internaute, rompant ainsi l’anonymat sur internet de l’usager. Afin de se protéger de ce type de coupure de connexion VPN, il faudra s’assurer que la carte réseau Ethernet de sa machine n’ait aucune passerelle par défaut (plus de détails sur cet article https://www.leblogduhacker.fr/les-risques-du-web-et-dune-protection-vpn-10-astuces-de-securite/)

Note importante: Nous verrons plus loin comment renforcer à l’aide d’un script « Bash linux » la sécurité réseau de « Tails », notamment en bloquant les « robots scanners » de ports en ligne couramment scannés, et en détectant un trop gros volume de paquets TCP avec les flags SYN et/ou ACK et/ou FIN et/ou RST « armés ». Je proposerai pour les plus passionnés d’entre vous un script Bash Linux permettant de BLOQUER manuellement une adresse IP publique qui sera automatiquement enregistrée dans une liste (fichier texte) ou encore comment BLOQUER à partir d’une liste d’adresses IP connues au préalable (liste d’adresses IP d’institutions gouvernementales US)

XIV. Travaux Pratiques sous Tails

Maintenant, nous allons pouvoir continuer cet article vers des choses beaucoup plus intéressantes en réalisant des TP (scripts Bash Linux sous Tails).

Avant d’aller plus loin, je vais vous expliquer comment installer automatiquement à chaque démarrage de Tails les utilitaires suivants que nous allons aborder à travers ces TP: nmap, zenmap, netdiscover, tshark

Débutons par l’ouverture d’un Terminal en tant qu’Administrateur sous Tails, puis éditons le fichier de configuration « live-additional-software.conf » et saisissons le nom des paquets à installer:

nano /live/persistence/TailsData_unlocked/live-additional-software.conf

Saisie des paquets nmap, zenmap, netdiscover et tashark, puis enregistrer « CTRL + O » et quitter « CTRL + X »

Note importante: Les utilitaires évoqués ici sont sans risques et réputés. L’installation d’autres applications additionnelles est à vos risques et périls !

TP n°1: Exclusion d’adresses IP publiques

Lien de téléchargement des 3 fichiers listes IP « liste_ip_gouv« , « », « US_gouv_blacklist_ip » + 1 script Bash Linux intitulé « exclusion_IP » ici

Débutons par le commencement. Vous venez de télécharger à partir du navigateur « Tor Browser Bundle » via Tails les 4 fichiers nécessaires à la réalisation de ce 1er TP. Les 4 fichiers se trouvent normalement dans le Dossier Tails intitulé « Téléchargements« . Première chose à faire, ouvrez le ‘Terminal‘ en tant qu’Administrateur à partir du menu « Applications » de Tails (en haut à gauche de l’écran). Nous allons maintenant copier les 4 fichiers situés dans le répertoire « Téléchargements » vers le répertoire Tails nommé « Persistent« , afin qu’ils soient sauvegardés de façon permanente même après l’extinction de la clé Live USB Tails. Le plus simple pour vous est d’utiliser l’explorateur de fichiers Tails à partir du menu intitulé « Emplacements » (en haut à gauche de l’écran).

Passons aux choses sérieuses ! Le script Bash Linux intitulé « » que vous venez de copier dans le dossier /home/amnesia/Persistent/ est au format texte ‘.txt’. Bien évidemment, vous vous doutez bien qu’un fichier texte ne peut être interprété en l’état par le système Tails comme script Bash Linux exécuté par le Shell lui-même.

Un script shell c’est quoi exactement ? C’est un fichier au format texte, ça vous le savez déjà, OK! C’est-à-dire que ce n’est pas un simple fichier binaire, exécutable directement par la machine (le Shell), c’est un fichier qui doit être interprété, d’où la notion d’interprétation d’un script dit « Interpréteur ».

L’interprétation c’est quoi ? Ça signifie que chaque commande inclue dans un fichier Shell au format texte doit être lue par un programme, appelé interpréteur.

Quel est le rôle d’un interpréteur ? L’interpréteur analyse chaque commande du script et la traduit « au fil de l’eau » en langage machine. Cette dernière ne peut exécuter que du langage machine par l’intermédiaire d’un script Shell et d’un interpréteur de commande. Quand on évoque les scripts Shell, l’interpréteur, c’est le shell. Dans le cas d’autres langages, comme par exemple le Perl, l’interpréteur est un programme indépendant du Shell.

Maintenant, nous allons devoir donner les droits d’exécution au script Shell (au format texte) sans lesquels il ne pourra pas être lancé par le Shell, logique ! Il existe plusieurs méthodes pour donner les droits d’exécution à un fichier Bash Linux, en voici une, tapons dans le « Terminal » cette ligne de commande:

chmod +x exclusion_IP

Certains vont certainement me poser la question: « OK Diki, mais pourquoi le fichier texte « exclusion_IP » n’est-il pas enregistré avec l’extension ‘.sh‘ puisque tu viens de nous dire que c’est un script Shell !?! »

Réponse: Je n’en ai aucune idée ! Je plaisante ! Pour faire simple disons qu’il y a deux façons de voir le « shell ».

Premièrement, on a la possibilité d’annoncer en première ligne du script Shell au format texte qu’il doit être interprété par le Shell du système installé (Tails) en tant que « script Shell ». Pour connaître quel est le Shell de son « système installé », il suffit de taper la commande suivante dans un « Terminal »:

echo $SHELL

retour: /bin/bash

Bingo ! La distribution Tails a un Shell Bash, ce qui explique que la première ligne de commande du script Shell débute par ‘#!/bin/bash‘. Vous l’aurez compris, il existe plusieurs Shell, mais le plus couramment utilisé sur un système Unix est le ‘Bash’. Sur Debian et également sur Ubuntu, l’exécutable ‘/bin/sh‘ n’est qu’un lien pointant sur ‘/bin/bash’. Dans les divers systèmes d’exploitation Windows, par analogie le programme se nomme ‘command.com’ ou ‘cmd.exe’… et « Power Shell » vous connaissez !?! bon bref ! Nous pourrions débattre des heures et de journées entières sur le sujet, mais il y a un truc qui m’a toujours fait rire est cette histoire de ‘slash’ et ‘antislash’ ! Entre nous heureusement que Microsoft Windows s’est inspiré du langage « Bash Unix/Linux » ! Imaginez un Administrateur Systèmes ayant pour mission de déployer un serveur Exchange Microsoft incluant notamment la création de 5000 comptes utilisateurs ! A l’aide de quatre ou cinq petits scripts « Power Shell » c’est bouclé ! (sourire)

Deuxièmement, on peut aussi enregistrer le script Shell avec l’extension ‘.sh‘ au lieu de ‘.txt‘, dans ce cas l’interpréteur jouera son rôle de la même façon étant donné que l’exécutable n’est qu’un lien pointant sur ‘/bin/bash’. La commande à taper dans le « Terminal » pour exécuter le script Shell sera toujours la même, c’est à dire soit:

bash exclusion_IP.txt

bash exclusion_IP.sh

bash exclusion_IP

Par convention, il est préférable d’enregistrer un script Bash Linux (format texte) sans extension et d’utiliser la commande ‘ bash exclusion_IP ‘

Décortiquons si vous le voulez bien ce script Bash Linux « exclusion_IP« ! En pseudo langage voici comment le « cerveau humain » pourrait interpréter les séquences des commandes à exécuter dans ce script Shell:

1. Déclaration du script afin qu’il soit interprété par le Shell (Bash)

1. AFFICHER quelques recommandations pour l’utilisateur du script

1. AFFECTER à la variable « REPERTOIRE » le chemin (PATH) en cours de l’utilisateur (en mode ‘Terminal’) et AFFICHER le chemin à l’écran (PATH)

1. Si les fichiers nécessaires à l’exécution du script n’existent pas, alors il faut CREER les fichiers automatiquement

1. Tant que l’utilisateur n’a pas répondu à un des 3 choix proposés (1 ou 2 ou 0), alors le script reste en exécution

1. Dans le cas où l’utilisateur opte pour le choix ‘1‘ alors LIRE l’adresse IP qu’il aura saisie puis APPLIQUER à l’adresse IP lue 3 règles pare feu (iptables). 1er règle pare feu: BLOQUER l’adresse IP sur tous les ports entrants, 2ème règle pare feu: BLOQUER le port entrant n°443 HTTPS, 3ème règle pare feu: BLOQUER le port entrant n°80 HTTP, puis ENREGISTRER (empiler) l’adresse IP lue dans le fichier ‘blacklist_ip_manuel.txt‘

1. AFFICHER les connexions internet actives

1. Dans le cas où l’utilisateur opte pour le choix ‘2‘ alors LIRE chaque adresse IP de chaque fichier (« blacklist_ip_manuel.txt », « liste_ip_gouv« , « blocklist_Zeux_IP« , « US_gouv_blacklist_ip« ) et les AFFECTER respectivement une par une à leur variable dédiée ‘ligne_IP_manuel‘, ‘ligne_IP_gouv‘, ‘ligne_IP_Zeus’ et ‘ligne_IP_US_gouv’, puis APPLIQUER pour chaque adresse IP lue 3 règles pare feu (iptables); 1er règle pare feu: BLOQUER l’adresse IP sur l’interface réseau ‘eth0’, 2ème régle pare feu: BLOQUER le port entrant n°443 HTTPS, 3ème régle pare feu: BLOQUER le port entrant n°80 HTTP

Dans le cas où l’utilisateur opte pour le choix ‘0‘ alors AFFICHER le message « C’est fini !!! A la prochaine !!! » puis ARRÊTER l’exécution du script Shell

Note importante: vous remarquerez que j’ai volontairement appliqué 3 règles afin que vous puissiez comparer la première (bloque l’adresse IP sur tous les ports entrants) avec les 2 autres (bloquent l’adresse IP uniquement sur les ports entrants HTTP 80 et HTTPS 443)

Le bloc 1 du script Shell ci-dessous correspond aux séquences n°1, 2, 3 et 4 (pseudo langage humain):

La commande (instruction) ‘echo‘ permet d’afficher sur la sortie standard (l’écran par défaut) une ligne de texte alphanumérique (caractères spéciaux inclus) qui sera interprétée en l’incluant entre guillemets » « ou pas interprétée en l’insérant entre apostrophes ‘ ‘ .

Observez les 6 premières instructions ‘echo‘ du script ci-dessous. Les 6 premières instructions ‘echo‘ affichent simplement 6 lignes de texte entre apostrophes sans saut de ligne, elles ne sont donc pas interprétées. La 7ème instruction ‘echo‘ (echo -e « *********************************** \n ») affiche une ligne de texte entre guillemets qui va reconnaître et interpréter la séquence n (antislash n) à l’aide de l’option -e devant l’instruction ‘echo‘ donnant lieu à un saut de ligne. De suite après, nous souhaitons afficher le nom du répertoire courant (PATH) où se situe l’utilisateur dans l’arborescence des répertoires en cours. Le principe est le même que précédemment, nous demandons à l’instruction ‘echo‘ de reconnaître et interpréter la séquence n (antislash n) à l’aide de l’option -e ET d’afficher le contenu de la variable $REPERTOIRE qui contient le nom du répertoire en cours (PATH). Si nous avions remplacé les guillemets par des apostrophes, alors la commande ‘echo‘ aurait affichée la ligne de texte comme suit: Vous êtes actuellement dans le répertoire suivant: $REPERTOIRE n

La commande ‘pwd‘ signifie en anglais « print working directory », elle permet d’afficher le nom du répertoire courant sur la sortie standard (l’écran par défaut). Ici nous allons utiliser ce que l’on appelle la substitution de commande à l’aide de l’instruction $( ) qui a remplacé les apostrophes inverses. L’idée générale ici est d’affecter la sortie d’un programme ou d’un script ou d’une instruction à une variable. Dans le bloc 1 ci-dessous nous avons affecter la sortie de l’instruction ‘pwd‘ (REPERTOIRE=$(pwd) ) à la variable REPERTOIRE, que nous avons affichée avec l’instruction ‘echo‘

Le jeu de commande ‘IF THEN ELSE FI‘ est un grand classique. Cette structure conditionnelle est puissante et permet de multiples combinaisons. Je préfère cantonner mon explication sur le cas abordé dans notre script ci-dessous. Ici il s’agit de vérifier si les 4 fichiers nécessaires (balcklists IP) à l’exécution du script Bash Linux sont présents dans le répertoire /home/amnesia/Persistent/ de Tails. Voici ce que cela donne en pseudo langage:

SI (IF) le fichier ( [ -f « nom du répertoire + nom du fichier » ] ) existe ALORS (THEN) une ligne de texte affichera qu’il existe déjà, SINON (ELSE) créer (instruction ‘touch‘) le fichier et afficher (instruction ‘echo‘) qu’il vient d’être créé, fin de la structure conditionnelle (FI).

Le bloc 2 ci-dessous correspond à la séquence n°5 (pseudo langage humain):

Les structures conditionnelles ‘WHILE‘, ‘UNTIL‘ et ‘FOR‘ sont des boucles. C’est-à-dire qu’elles invoquent et soumettent à une condition déterminée l’itération (ou pas) d’une suite d’instructions et/ou de commandes. Dans le bloc 2 ci-dessous, nous avons implémenté une structure « WHILE TRUE DO‘ en boucle infinie dans laquelle nous avons encapsulé plusieurs instructions (CASE, WHILE) et commandes (echo, read, iptables etc.). La condition qui permet de rompre définitivement cette boucle infinie se trouve dans le bloc 5, elle est déterminée par la valeur ‘0‘ (zéro) lue et affectée à la variable REPONSE lorsque l’utilisateur souhaite stopper et quitter le programme en cours d’exécution (script)

Le bloc 3 ci-dessous correspond aux séquences n°6 et n°7 (pseudo langage humain):

Nous allons maintenant nous intéresser à l’instruction ‘READ‘ que je trouve très intéressante puisqu’elle permet de créer des scripts interactifs. De façon plus générale elle permet l’interaction entre l’utilisateur et son clavier (entrée par défaut). Ci-dessous dans le bloc 3, l’instruction ‘CASE‘ va permettre de soumettre 3 conditions (‘1’, ‘2’ ou ‘0’) affectées à la variable déclarée et intitulée REPONSE ($REPONSE). Ainsi, à chaque fois que l’utilisateur répondra ‘1‘, l’instruction ‘READ IP‘ lira et affectera la valeur saisie au clavier à la variable IP (READ IP), la conséquence donnera lieu au blocage de l’adresse IP publique saisie grâce à la commande ‘ iptables -A INPUT -s $IP -j DROP », dans la foulée une ligne de texte sera affichée (echo) pour confirmer le bannissement et l’ajout de l’adresse IP dans le fichier dédié (blacklist) à l’aide de la commande ‘ echo $IP >> /home/amnesia/Persistent/blacklist_ip_manuel.txt ‘. Ici ‘echo‘ renvoie et empile le contenu de la variable IP au fil de l’eau dans le fichier nommé blacklist_ip_manuel.txt

Le bloc 4 ci-dessous correspond à la séquence n°8 (pseudo langage humain):

C’est ici, dans le bloc 4 ci-dessous, que l’instruction ‘WHILE‘ va délivrer toute son efficacité puisqu’elle permet l’association d’autres instructions en l’occurrence ‘READ‘ (READ ligne_IP_manuel, READ ligne_IP_gouv, READ ligne_IP_Zeus et READ ligne_IP_US_gouv). Précédemment nous étions dans le cas où la saisie d’une adresse IP par l’utilisateur était unique. Dans le cas du bloc 4 ci-dessous, nous n’avons pas besoin que l’utilisateur (vous en l’occurrence) saisisse au clavier des centaines voire des milliers d’adresses IP, vous imaginez le délire ! (rires) C’est donc une structure en boucle ‘WHILE‘ qui va LIRE (READ) à la place de l’utilisateur chaque ligne du fichier où sont enregistrés toutes les adresses IP publiques (blacklists). L’originalité de ce procédé se situe au niveau de la séquence de « lecture » induite par la structure ‘WHILE DO DONE‘ qui permet de changer l’entrée par défaut du clavier par celui d’un fichier texte (blacklists) grâce à cette structure en boucle ‘WHILE READ DO DONE < /home/amnesia/Persistent/blacklist_ip_manuel ‘ notamment.

Le bloc 5 ci-dessous correspond à la dernière séquence n°9 (pseudo langage humain):

Le bloc 5 ci-dessous permet à la boucle infinie ‘WHILE TRUE DO DONE‘ de stopper et quitter définitivement le script Bash Linux

Note importante: Je vous propose de développer vos questions à propos des commandes ‘iptables’ par commentaires. Effectivement, je préfère aborder l’aspect technique du pare feu ‘iptables’ par commentaire afin de simplifier et réduire le volume de cet article. Dans le TP n°2 plus bas, j’évoque plus en détail la commande ‘iptables’.

TP n°2: Blocage des « robots scanners » en ligne et détection de l’envoi d’un trop gros volume de paquets TCP avec les flags SYN et/ou ACK et/ou FIN et/ou RST (balayage de ports furtifs)

Attaquons le vide du sujet !

Lien de téléchargement du script intitulé ‘detect_TCP_robotscan‘ ici

Quel est l’objectif du pirate ? Le but du pirate informatique est notamment de faire du repérage et de la détection de serveurs Web afin de les identifier. Les techniques de piratage de serveurs Web sont nombreuses, de ce fait l’utilisateur d’une distribution « Tails » n’est absolument pas protéger d’une visite d’un serveur Web « vérolé » (site visité) impactant du coup la sécurité de ses données et la protection de son l’anonymat !

Comment le pirate va-t-il s’y prendre pour obtenir ces informations ? Le pirate va tout simplement utiliser un scanner ! Nous allons donc mettre en place une méthode de protection contre le scan en appliquant des règles pare feu sous ‘ iptables ’ (Firewalling)

Qu’est ce qu’un scanner ? L’intérêt d’un scanner est relativement simple. Il permet de rechercher durant un bref délai, tous les ports ouverts (entrants) sur une machine distante. Il existe différents types de scanner, certains ont pour vocation de donner la liste des ports ouverts et d’autres notamment le type et la version de l’OS tournant sur la machine distante.

L’idée de départ de ce script est d’appliquer une règle de filtrage ‘iptables‘ en écoute (‘INPUT‘) correspondant avec des adresses Ethernet (‘-m‘ MAC) de paquets entrants traversant uniquement la chaîne ‘INPUT‘ (table ‘filter’) sur le protocole ‘TCP‘ (‘-p TCP‘ charge les extension TCP) permettant ainsi la création d’un ‘name‘ (nom) intitulé « SCANNERS » (fichier) servant à inventorier les adresses IP sources (« les méchants »!) provenant du Web ou du DarkWeb (‘–rsource‘), effectuant un scan sur de multiples ports (patch ‘multiport‘ ajouté par Andreas Ferber ) à destination des ports d’écoute (‘–dports‘) couramment scannés (par les « méchants »!) qui seront « bloqués » et rendus non joignable (masqués) par la commande ‘DROP‘. Peut-être que pour certains lecteurs cette interprétation sera du charabia, ce n’est pas grave, continuons vous allez comprendre par la suite… (humour)

La syntaxe générale de la plupart des commandes ‘iptables‘ est: # iptables [commande] [règle] [extensions]

Voici comment se traduit la commande ‘iptables’ pour les ports n°20,21,22,23,25,135,136,137,139,465 et 587.

Première règle ‘iptables’ du script:

iptables -A INPUT -p tcp -m multiport –dports 20,21,22,23,25,135,136,137,139,465,587 -m recent –set –name SCANNERS –rsource -j DROP

Il est possible de définir une ou plusieurs plages de ports en utilisant ‘:‘, par exemple ‘135:139‘ au lieu de ‘135,136,137,138,139’ sera interprété par ‘iptables‘ comme suit: d‘un port supérieur ou égal à 135 dans l’intervalle d’un port inférieur ou égal à 139 = définition d’une plage de ports dans l’intervalle de 135 à 139.

La force d’iptables (firewall) est notamment de lutter contre les attaques de pirates et leurs tentatives de scan en ligne!

Cette règle est issue du Patch ‘recent‘ ajouté par Stephen FROST qui consiste à créer une liste intitulée `SCANNERS‘ contenant l’adresse IP publique des personnes (pirates, les « méchants »!) qui tentent de scanner nos ports 135 à 139 (exemple) via notre firewall, pour pouvoir ensuite les bloquer (« détruire ») pendant 3600 secondes. Ce patch permet ainsi de créer dynamiquement une liste d’adresses IP et ensuite de matcher (faire correspondre) des paquets par rapport à cette même liste.

# iptables -A FORWARD -m recent –name SCANNERS –rcheck –seconds 3600 -j DROP
# iptables -A FORWARD -p tcp -i eth0 –dport 135:139 -m recent –name SCANNERS –set -j DROP

Note importante: Dans la règle générique écrite par Stephen FROST ci-dessus, l’entrée ‘FORWARD’ de la table ‘filter’ a été utilisée pour faire correspondre l’interface réseau générique ‘eth0’ à tous les paquets TCP qui ne sont pas générés localement et ni destinés au pare-feu. Dans la règle adaptée à ce script, j’ai utilisé « INPUT » étant donné que seul le firewall est concerné par notre règle (hôte local)

Cette première règle nous a permis de « fermer » et « masquer » (ports non joignables) certains ports d’écoute couramment scannés en ligne, tout appliquant un filtre permettant de bloquer les adresses IP des « méchants pirates » ! (humour)

Deuxième règle ‘iptables’ du script:

iptables -A INPUT -m recent –update –seconds 3600 –hitcount 2 –name SCANNERS –rsource –reap -j DROP

Dans cette règle ‘iptables‘ ci-dessus, j’ai souhaité performer la première règle en affinant son fonctionnement. L’option ‘–update‘ remplace ‘–set‘ inscrite dans la première règle. Le fait que leur rôle soit pratiquement identique, elles se différencient uniquement dans la mise à jour de l’entrée (‘INPUT‘). Si l’adresse source du paquet est dans la liste alors l’entrée sera mise à jour et la règle va matcher (correspondance), sinon la règle ne matchera pas. L’option ‘–hitcount hits‘ au même titre que ‘–seconds‘ doit être utilisée avec ‘rchek‘ ou ‘update‘ ce qui est le cas ici. Le rôle de l’option ‘–hitcount hits‘ est d’engager la règle que si et seulement si la règle ne matche que si l’adresse IP est présente dans la liste ET uniquement quand on aura reçu un nombre de paquets supérieur ou égal à ‘hits‘ c’est à dire ‘2‘ ici. Tout l’intérêt de cette règle est de matcher un nombre de paquets supérieur ou égal à ‘2’ délimité dans une certaine limite de temps, ici 3600 secondes. Ça veut dire tout simplement que nous conditionnons le trafic à une règle ‘iptables » plus affinée qui à pour rôle de voir si le nombre de paquets reçus en provenance d’une adresse IP dans la liste est supérieur ou égal à ‘2’ durant 3600 secondes. En résumé, il faut donc qu’un certain nombre de paquets soient vus (2 par cycle de 3600 sec) à partir d’une adresse IP présente dans la liste pour que cette règle matche et « bloque » (DROP = détruire).

Afin de sécuriser cette règle, j’ai ajouté l’option ‘–reap‘ qui permet de purger les adresses IP des cycles précédents les plus anciens, ceci afin d’éviter que la liste soit pleine. Effectivement le nombre d’entrées possibles dans cette liste est par défaut limité à 100 sur cette distribution « Tails ». J’ai tenté d’élever le nombre limite à 1000 mais il semblerait que le fichier de configuration ne le permette pas.

Troisième régle ‘iptables » de ce script (balayage de ports furtifs):

Détection d’un envoi d’un trop gros volume de paquets TCP avec les flags SYN et/ou ACK et/ou FIN et/ou RST.

iptables -A FORWARD -p tcp –tcp-flags SYN,ACK,FIN,RST RST -m limit –limit 1/s -j ACCEPT

Cette règle va tout d’abord permettre d’examiner et de détecter l’envoi d’un trop gros volume de paquets TCP avec les flags SYN et/ou ACK et/ou FIN et/ou RST. Je ne vais pas rentrer dans la technicité réseau pure, mais disons simplement qu’en règle général l’envoi de paquets TCP avec les flags précités sont limités, ce qui sous-entend que lorsqu’il y a envoi d’un trop gros volume de paquets TCP avec ces flags cela est signe de « danger », ce n’est pas normal ! Ci-dessous un exemple concret plus parlant que j’ai fait remonter à la Team Support Tails France et US récemment. On voit bien que beaucoup de paquets TCP comportant le flag ‘ACK’ et ‘FIN’ sont émis vers ma machine hôte (ici 192.168.1.31) lors du démarrage de « Tails » sur une machine virtuelle (VMWARE) nattée sur une interface réseau « VMNet NAT », étrange ! Normalement, « Tails n’a pas à échanger sur du protocole TCP entre ma machine hôte et une source externe inconnue comme vous pouvez le voir ! Fort heureusement, j’avais pris le soin de désactiver définitivement les services SSDP et UPnP Windows de ma machine hôte afin de la protéger, c’est pour cette raison que j’ai pu détecter sur mon trafic réseau cette anomalie ci-dessous. Le but de cette règle ‘iptables’ sous « Tails » sera donc de juguler ce genre d’anomalie.

‘FORWARD‘ est de loin une des chaînes les plus intéressante inscrite dans la table « filter« . ‘FORWARD‘ s’appliquera à tous les paquets TCP qui ne sont pas générés localement et ni destinés à l’hôte local en l’occurrence le pare-feu.

‘–tcp-flags’ permet de filtrer à partir des fanions (flags) TCP: la première liste d’arguments correspond au masque c’est à dire la liste de fanions que l’on souhaite examiner ici ‘SYN,ACK,FIN,RST ‘, la deuxième liste d’arguments spécifie lesquels doivent être présents ici ‘RST‘.

‘limit‘ est un module utilisé pour limiter le taux de correspondances, il prendra en compte les correspondances un certain nombre de fois pas seconde ici ‘1/s‘

Parmi les types de scan les plus connus, la technique du scan TCP « Maimon » (du nom de celui qui l’a détecté) est notamment utilisée par le scanner « Nmap« . Cette technique est la même que celle pratiquée par les scans NUll, FIN et Xmas, à la seule différence que le paquet de test est un « FIN/ACK » comme nous pouvons le constater dans ma démonstration en « live » ci-dessous. Comme l’indique le protocole RFC 793 (TCP), un paquet RST devrait normalement être renvoyé comme réponse à un tel paquet afin de réinitialiser la connexion que le port soit ouvert ou non, ce qui n’est pas le cas de la capture réseau (WIRESHARK) que j’ai pu effectuer ! Pourquoi ?

C’est ici que ma démonstration ci-dessous intitulée « test analyse réseau 192.168.1.31 Tais pas bon 25.06.16 » est très intéressante ! En réalité, je viens de détecter une vieille ATTAQUE TCP SYN Flood de type DDoS (Distribued Denial Of Service) qui permet de paralyser et saturer une machine (ma machine hôte physique: IP 192.168.1.31) dans le but de la rendre incapable de délivrer le service qu’elle doit fournir. Cette attaque DDoS est relativement vieille et ne fonctionne plus sur les machines récentes, hormis si l’attaque est perpétrée par une armada de machines (robots pirates)

Cette attaque DDoS consiste à ce que durant l’initialisation d’une connexion, le zombie « oublie » l’accusé de réception ACK permettant de conclure la connexion. Le but de cette opération est simple puisque le zombie reste cantonné dans la file d’attente de la machine qui est de facto impactée par une capacité limitée et une inertie très grande.

Mais ce n’est pas fini ! Dans cette analyse réseau, j’ai pu détecter une autre attaque beaucoup plus dangereuse, elle s’appelle « Déni de service de haut niveau ACK + PSH » ! Vous ne rêvez pas ! J’utilise bien la distribution Tails 2.4 ! (rassurez-vous j’ai fait remonter tout ceci au Support Tails US et France)

Ce déni de service est couramment occulté voire « oublié » durant les batteries de test de sécurité réseau, en sachant pertinemment que c’est une des attaques les plus dangereuses ! Bien que l’adresse IP ne soit pas spoofée étant donné que ce n’est pas un gros souci car il suffit de se rendre avec sa Clé Live USB Tails dans un cybercafé, elle est très difficile à détecter et ne requiert pas autant de bande passante qu’un « ping flood ». Son principe est simple. Il suffit d’établir une connexion en procédant à trois poignées de main (TCP S, TCP SA, TCP A), et dans la foulée expédier une série de paquets flagés « ACK + PSH » comme nous pouvons le voire dans ma capture réseau ci-dessous !

Que se passe-t-il ensuite ? Lorsque nous envoyons un paquet TCP il est stocké dans un buffer (pile). Une fois qu’il est rempli, il est transmis au système. Si on active le flag PSH (Push), alors le paquet sera directement transmis au système. L’ingéniosité de cette technique est donc d’inonder le serveur (machine cible) à l’aide de paquets Push / ACK (accusé de réception) pour surcharger et saturer le système cible.

Note importante: Comme vous avez pu le constater, l’idée générale de ce TP est de comprendre le principe d’une règle ‘iptables’ qui reste relativement simple. Ensuite, en fonction de ce que l’on souhaite appliquer comme règles, il suffit de rechercher sur le Net les options nécessaires que l’on nomme ‘patch’ et les extensions à joindre à la commande ‘iptables’. La distribution « Tails » est idéale pour réaliser des tests et simulations notamment dans le cadre de la sécurisation de son trafic réseau. Tout est une question de passion et de curiosité !

Conclusion

La grande majorité des experts et des usagers de Tails sont relativement confiants de cette distribution Linux qui pourtant dénote certaines limites inhérentes à l’utilisation, la sécurisation et la protection de l’anonymat de l’usager.

Quels sont ses avantages ?

La navigation Internet transite automatiquement par le réseau Tor, sans qu’aucun paramétrage préalable ne soit requis.
Des utilitaires de chiffrement des communications (mail, chat) et des fichiers sont mis à la disposition de l’usager.
Le système Tails de « nature amnésique » ne laisse presque aucune trace de ses activités sur l’ordinateur hôte sur lequel il est démarré.

Quels sont ses inconvénients ?

Tails ne convient pas aux activités quotidiennes d’un utilisateur lambda étant donné qu’il n’a pas pour vocation de répondre à tous les usages du grand public.

Le réseau Tor est confronté à ses propres limites: surveillance du réseau, site Web visités « vérolés », les empreintes numériques de l’usager peuvent rapidement être confondues notamment par recoupement de leurs habitudes de connexion, de la configuration propre à leurs navigateurs (extensions, plugins, javascript…), de leurs profils…

Des failles de sécurité sont toujours possibles et rendent la distribution Tails notamment sujette à des risques de rupture de l’anonymat inhérente à l’environnement réseau utilisateur. Le fait d’utiliser Tails sur un ordinateur hors de son domicile (réseau privé) ne garantit pas l’intégrité des interactions entre l’usager (Tails) et les échanges au sein du réseau local dans lequel il opère. Dans le cadre de cet article, j’ai pu démontrer une faille de sécurité impliquant des échanges réseau (scan TCP de type « Maimon ») entre Tails et mon réseau privé (machine hôte). Croire qu’il suffit d’utiliser Tails sur un poste de l’entreprise où l’on travaille ou bien chez un ami ou encore à travers un réseau privé externe quel qu’il soit pour « être protégé » et à l’abri de tout est un leurre ! N’oublions pas que seule la connexion du navigateur « Tor Browser Bundle » est protégée mais que toutes les autres applications ou interconnexions entre Tails et le réseau privé sont ouvertes en clair sur le Web et le DarkWeb !

Il faut être conscient que la distribution Tails est toujours en cours de développement et qu’elle est soumise à de nombreuses mises à jour. Durant cette installation de Tails j’ai pu constater un bug (Gnome DeskTop Settings) et une faille de sécurité réseau générés par la mise à jour automatique de Tails 2.3 vers Tails 2.4 que j’ai fait remonter à la Team Support Tails France et US. Je vous conseille donc de rester dans l’immédiat sur la version Tails 2.3 en attendant la sortie de Tails 2.5 prévue au mois d’août 2016.

Quoi qu’il en soit, le distribution « Tails » n’est pas destinée à des profils utilisateurs grands publics, mais plutôt à des journalistes ou des lanceurs d’alertes ou des « experts ». Notons au passage que la grande majorité des concepteurs de Tails sont toujours « anonymes » à ce jour ! Pour ma part, j’estime que les FAI en France offrent suffisamment de sécurité et de protection permettant à l’utilisateur lambda d’évoluer sereinement avec un système d’exploitation classique du genre Microsoft Windows, Ubuntu Linux, Debian Linux, sans oublier les outils de protection grand public (antivirus, pare feu…)

L’anonymat sur le Net est un choix personnel qu’il convient de mesurer et d’adapter à ses propres objectifs et besoins, mais en aucun cas l’anonymat ne doit conduire l’usager à s’affranchir des lois et des règles dans le but d’entreprendre des activités illégales et néfastes à la société. Le principe du droit individuel (déclaration des droits de l’Homme et des Citoyens) ne doit pas non plus guider une partie de la « communauté anonyme » à oublier le Droit Collectif qui par extension « prime » et complète le droit individuel…

Le droit à l’anonymat est un droit fondamental inscrit dans les Droits de l’Homme et des Citoyens « Tout ce qui n’est pas défendu par la Loi ne peut être empêché, et nul ne peut être contraint à faire ce qu’elle n’ordonne pas. ». Les nombreuses tensions entre les politiques gouvernementales et les grandes firmes numériques à travers le monde reflètent aujourd’hui les énormes enjeux économiques, financiers et sociaux tendant à réduire voire supprimer le champ de ce droit fondamental. Le Droit à l’Anonymat est-il en danger ou déjà compromis ?

Dans l’attente de vos commentaires et réactions,

Je vous dis à très bientôt !

Diki

Article sous licence Creative Commons Attribution 2.0 FR