Ce podcast traite de la modification de la signature d’un virus, c’est une technique qui fut beaucoup utilisée, il y a quelques années, lorsque les éditeurs d’antivirus ne se basaient que sur la base virale pour détecter un virus.

La majeure partie de ce podcast est une démonstration, où un anti-virus qui au départ, comportait des signatures virales, n’en possède plus à la fin et marche toujours aussi bien.

Bon visionnage !

Je vous invite à lire le podcast si dessous en plein écran et en résolution 720p, dans une qualité inférieure, les textes peuvent ne pas être visibles.

Le programme de cette certification se concentre essentiellement sur l’attaque et très peu sur la défense. Il est en effet pratique de savoir comment attaquer afin d’être efficace lorsqu’il s’agit de défendre. Un des projets sur lesquels je travaille est le mécanisme de défense des anti-virus et comment le contourner.

La finalité de ce projet est la création d’un virus totalement indétectable par les anti-virus. Ce podcast, que j’ai réalisé pour mon école Ingésup, est en quelque sorte une préface à toute une série d’articles sur ce projet.

Google Storage for Developpers fournit un espace de stockage illimité et hautement disponible, ainsi qu’une interface RESTFull, ce n’est pas la peine de le comparer avec Dropbox, mais avec le service d’amazon : Amazon S3 (que dropbox utilise).

Organisation

Chaque fichier envoyé sera stocké sur le Cloud Google, c’est à dire sur une multitude de serveurs répartis à travers le monde. Chaque fichier pourra donc être accessible de n’importe, le serveur sera choisit de manière transparente en fonction de son temps de réponse. Les données étant répliquées sur plusieurs serveur, plus besoin de sauvegarde, si un des serveurs tombe, le fichier sera toujours disponible grâce aux autres serveurs.

Comme sur Amazon, des répertoires racines doivent être créés. Appelés Bucket, ces répertoires doivent avoir un nom en minuscule selon le principe d’un alias de nom de domaine. Ce bucket pourra en effet être atteint depuis un alias de l’url de google storage : nom_du_bucket.commondatastorage.googleapis.com .

Chaque bucket peut ensuite contenir :

• des fichiers
• des dossiers
• des buckets

Une gestion des ACL (Access Control List ou encore gestion des droits) fait également partie intégrante du système de fichiers, il existe 3 droits pouvant être appliqués à des domaines mails ou encore des comptes google spécifiés explicitement.

• READ : droit de lecture uniquement
• WRITE : droit de lecture et d’écriture
• FULLCONTROL : ce droit permet d’attribuer tout les droits à un fichier, y compris les droits de modification des ACL

Une fonctionnalité interessante est la possibilité de reprendre un envoi ou un téléchargement, imaginons qu’un envoi d’un très gros fichier de plusieurs centaines de Mo ai été interrompu par une coupure de connection, il est possible de reprendre l’upload exactement où la coupure c’est produite.

Par contre, c’est dommage (mais en même temps très dur à gérer), mais un fichier sur le serveur ne peut être modifié. Ainsi, lors de la modification d’un fichier, ce fichier est supprimé, puis renvoyé. Il est considéré comme un fichier totalement différent du premier, et sa date de « modification » devient donc sa date de création, le libéllé dans l’explorateur est « Last upload ».

La compression du flux est également gérée, en envoyant un fichier, il est possible d’utiliser la compression gZip, le temps de transfert sera réduit, la bande passante (BP facturée ^^)  sera également réduite.

Lors de l’envoi d’un fichier, ce fichier est considéré comme inexistant, et n’apparait donc pas dans notre bucket. Dès que le serveur a entièrement reçu le fichier, il apparait instantanément, et est immédiatement disponible. De la même façon, une fois supprimé, il n’apparait plus et renvoi une 404 immédiatement.

Google storage utilise le protocole HTTPS pour l’échange de fichier, nos données sont donc sécurisées (relativement bien) pendant toute la durée du transit.

Interface Web

Mieux vaut une petite démonstration avec quelques screenshot que des explications imbuvables :

Ligne de commande

Là une partie un tout petit peu plus technique… Google fournit un utilitaire développé en Python qui est un client RESTFull pour Google Storage.

L’avantage par rapport à l’interface Web est que nous avons accès à la quasi-totalité des fonctions REST, notamment la gestion des ACL que nous n’avons pas encore sur l’interface Web.

Cet utilitaire s’appelle GSUtil et son utilisation est plutôt simple :

Pour reprendre le même exemple que ci-dessus :

Création d’un bucket : gsutil mb gs://jeremy

Création d’un dossier : gsutil mb gs://jeremy/test

Envoi d’un fichier : gsutil cp Lorem\ Ipsum.txt gs://jeremy/

Liste du dossier : gsutil ls -l gs://jeremy

Affichage du fichier : gsutil cat gs://jeremy/Lorem\ Ipsum.txt

Suppression de fichier : gsutil rm gs://jeremy/Lorem\ Ipsum.txt

Gestion des acls :

• Tout d’abord récupérer la configuration acl existante : gsutil getacl gs://jeremy/Lorem\ Ipsum.txt > acl.txt
• Ensuite éditer ce fichier en fonction des nouvelles ACL
• Puis renvoyer le fichier : gsutil setacl acl.txt gs://jeremy/Lorem\ Ipsum.txt

Prix

Je vous ai dit en début d’article que l’espace de stockage était illimité ? oui, mais pas sans coût.

Voici le tableau de prix donné par google, la facturation se fait en fonction de la taille des données transitants entre l’utilisateur et les serveurs, et de l’espace de stockage utilisé.

• Utilisation d’espace de stockage : $0.17/Go/mois
• Réseau
  • Envoi des données
    • $0.10/Go
  • Téléchargement des données
    • $0.15/Go pour l’Amerique, l’Europe, le Moyen-Orient et l’Afrique
    • $0.30/Go pour l’Asie-Pacifique
• Requêtes
  • PUT, POST, LIST—$0.01 pour 1,000 requêtes
  • GET, HEAD—$0.01 pour 10,000 requêtes

Posons le décor : tu viens d’arriver dans un hôtel, tu t’installes confortablement afin de profiter de la connexion internet offerte gratuitement et de pouvoir téléphoner à ta tante Gertrude gratuitement grâce à ton compte SIP, et là ! Misère de misère, les ports SIP sont  bloqués, logique, l’hôtelier préfère faire payer les communications avec une légère surtaxe ! [IRONIE ON] Oui oui, cet exemple est sorti de mon imagination, non non, ça ne m’est jamais arrivé… [IRONIE OFF]

Le problème est le même si tu désires jouer à un jeu dont les ports sont bloqués.

Ce qu’on va donc réaliser, c’est un VPN entre son ordinateur, appelons le A, et son serveur personnel S situé chez soi ou encore chez un hébergeur, S doit bien entendu être affranchi de toute limitation au niveau des ports. S doit également posséder un serveur SSH accessible depuis un port débloqué à l’hôtel. Généralement le port 22 par défaut est débloqué, cela ne devrait donc pas poser de problème.

Pour rappel un VPN (Virtual Private Network) permet de se connecter à un réseau distant et d’envoyer tout le trafic réseau par cette nouvelle connexion.

Mais quels sont les avantages de cette méthode par rapport à un VPN PPTP, L2TP ou OpenVPN ???

Pratiquement aucun, ce tunnel va juste être très rapide à configurer, seulement quelques lignes de commandes seront nécessaires, sécurisé grâce au tunnel SSH, et souvent les ports requis par PPTP ou L2TP sont bloqués.

Bon, un petit schémas pour résumer peut-être ?

VPN et tunnel SSH, schémas

C’est plus clair ? En fin de compte, tout le trafic transitera au travers d’un tunnel SSH, notre ordinateur sera donc connecté au réseau distant (192.168.0.0) comme s’il en faisait parti.

Bien maintenant, on sait où on va, mais on sait pas trop comment ! Pas de panique je ne te largue pas comme ça juste avec le principe ^^, la théorie est faite, place à la pratique.

Configuration du server SSH

Quelques petits prérequis afin que notre tunnel s’établisse correctement, nous allons devoir modifier un petit peu la configuration de notre serveur SSH :

Ce fichier est généralement situé ici : /etc/ssh/sshd_config
Vous devez vérifier que les réglages suivant soit paramétrés comme ceci :

X11Forwarding yes

PermitTunnel yes

PermitRootLogin yes

Ensuite il nous faut activer la redirection des paquets, désactivé par défaut sur la majorité des Linux.

sudo echo 1 > /proc/sys/net/ipv4/ip_forward

Puis finalement redemarrer le serveur SSH :

sudo /etc/init.d/sshd restart

Création du Tunnel SSH

Sur la machine cliente (Ordinateur A sur notre schémas), la commande permettant de creer le tunnel est celle-ci :

sudo ssh -NTfv -w 11:10 root@ip_du_serveur_S

Passons en revu les différentes options :

• N : empêche l’execution d’une commande
• T : n’alloue pas un terminal TTY à cette instance de connection SSH
• f : executé en arrière plan
• v : mode verbose, afin d’afficher les différents messages
• w : lie deux interfaces, nous allons avoir l’interface tun11 sur Ordinateur A et tun10 sur Serveur S. Les deux auraient pu être tun10 ou encore tun0, mais je voulais bien les différencier pour ne pas les confondre. De plus dans mon cas tun0 est déjà utilisé sur mon serveur pour un VPN.
• C : je ne l’ai pas mise, à essayer avec, cette option permet de compresser les données, du coup gain énorme de bande passante, mais perte de réactivité, pour des jeux à bannir, pour des page web à utiliser.

Désormais, si tout c’est bien passé, nous avons notre tunnel SSH entre notre serveur et notre pc, il ne nous reste plus qu’a configurer les interfaces TUN et rediriger tout le traffic vers ce tunnel pour faire un pseudo-vpn.

Configuration des interfaces TUN

Sur notre machine cliente Ordinateur A :

sudo ifconfig tun11 192.168.0.61 pointopoint 192.168.0.60

si Ordinateur A tourne sous osx :

sudo ifconfig tun11 192.168.0.61 192.168.0.60

et sur notre serveur distant S :

sudo ifconfig tun10 192.168.0.60 pointopoint 192.168.0.61

ou sous osx :

sudo ifconfig tun10 192.168.0.60 192.168.0.61

Ces deux commandes a exécuter permette de définir une adresse ip aux interfaces TUN et de les lier en mode point-à-point pour simplifier les choses à l’interface distante.

Pour tester la configuration, faites un ping vers 192.168.0.60 depuis l’ordinateur A :

ping 192.168.0.60

Si 192.168.0.60 répond, c’est que vous êtes correctement relié au réseau distant.

Faites de même avec 192.168.0.61 depuis le serveur S pour tester dans l’autre sens.

Redirection du trafic et création des routes

Depuis le serveur S, nous allons redirigé tout le traffic envoyé par l’ordinateur A au travers de l’interface eth0 relié au réseau local.

sudo arp -sD 192.168.0.61 eth0 pub

Désormais, tout est bouclé du côté serveur, vous pouvez fermer votre terminal distant.

Maintenant sur ordinateur A, nous allons configurer les routes.

Pour voir les routes déjà configurée :

netstat -nr

sur linux :

sudo route add -net 192.168.0.0 netmask 255.255.255.0 gw 192.168.0.61 tun11
sudo route add ip_du_serveur_S gw 172.16.0.254 eth0
sudo route del default gw 172.16.0.254 eth0
sudo route add default gw 192.168.0.61 tun11

sur mac :

sudo route add -net 192.168.0/24 192.168.0.61
sudo route add ip_du_serveur_S 172.16.0.254
sudo route delete default 172.16.0.254
sudo route add default 192.168.0.61

And it’s done !!!

Un petit test dans un navigateur depuis Ordinateur A sur le site http://monip.org devra montrer l’IP internet du réseau du serveur S. Si ce n’est pas le cas, il faut retester les ping, puis si tout est bon, vérifier les routes, il y a surement une erreur de ce coté là.

Edit: Il se peut que vous n’arriviez pas à joindre des adresses Web, si c’est votre cas,un petit ping des dns google :

ping 8.8.8.8

Si le ping passe, alors c’est que vos DNS ne sont pas correct, allez dans vos préférences réseau et changez les par :

8.8.8.8
4.4.4.4

(Ce sont les serveurs DNS de google).

Et normalement tout devrais fonctionner.

Si le ping 8.8.8.8 ne passe pas, vous devez surement avoir un problème dans votre configuration des routes, vérifiez là.