Titre alternatif

Pour ceux qui pourraient être éventuellement gênés par le titre provocateur de ce document, voici un second titre plus politiquement correct:

«Exemple de contournement d'une politique sécurité».

Contexte

La majorité des entreprises utilise des couples proxy/firewall embarquant un antivirus HTTP et un filtrage d’URL (sites sur le sport, les informations, réseaux sociaux, webmail, etc...) ainsi que le filtrage de protocoles autres que HTTP/HTTPS (jabber, IRC, etc...).
Ces limitations ont plusieurs objectifs:

• La sécurité de l'infrastructure informatique de votre entreprise
  • L'antivirus utilisé sur le proxy HTTP utilise un moteur antivirus différent que celui installé sur votre poste de travail pour doubler les chances d'intercepter les logiciels malveillants. Si c'est le même moteur antivirus (même éditeur) qui est utilisé cela ne sert qu’a ralentir le flux HTTP.
  • Le filtrage d'URL bloque les sites interdits par la loi (protection juridique de votre entreprise)
  • Tracer (à minima) l’activité de ses salariés sur Internet (entête des emails, sites visités), pour être capable d’identifier un salarié (protection juridique).
• Évite de surcharger le lien Internet: Attendre les 23 heures de téléchargement annoncés pour récupérer en urgence un gros correctif chez Microsoft car l'ensemble de vos collègues est en train de regarder la coupe du monde sur un site de streaming est assez énervant.
• Leur compétitivité: Les entreprises évoluant dans les domaines sensibles (défense, banquaire, pharmaceutique, etc…) doivent essayer de contrôler les informations sortantes, et donc éviter que leurs employés n'utilisent des services en ligne pour stocker des documents internes. Il est très facile de savoir si l’on se trouve dans ce type d'environnement: Les accès aux ports USB et au graveur CD/DVD des postes de travail sont verrouillés, votre téléphone cellulaire personnel y est interdit d’accès.

Ce document explique comment contourner le filtrage d’URL de type «liste noire» (c’est à dire qui interdit un ensemble de sites connus, et autorise tout le reste).
La solution proposée dans ce document ne permet pas d'éviter les solutions de type « liste blanche », c'est à dire celles qui n'autorisent qu'une liste d’URL référencées.

Attention!

Relisez entièrement la charte d'utilisation de votre poste de travail (qui vous a été demandé de signer avant votre première connexion) pour vérifier qu'il n'est pas:

• Explicitement interdit d'utiliser le protocole SSH/SSL vers Internet
• Ou d'utiliser toute méthode permettant de contourner les systèmes de sécurité (on parle bien de contourner et non pas de désactiver car cette méthode ne désactive aucun système de sécurité)

Vous n'avez pas signé la charte ? On ne vous l'a jamais donné: Vous ne pouvez pas savoir ce qui est interdit… Une ressource utile à lire en tant que salarié: Le forum des droits sur internet.

Le principe

Cet exemple présente une méthode très simple s'appuyant sur un multiplexeur HTTPS/SSH (sslh) couplé à un serveur SSH ainsi qu'au choix: Un serveur HTTPS ou un stunnel (logiciel de tunnel SSL).
Le principe est d’installer ces services sur une machine vous appartenant (appelé serveur de rebond) et disposant d’une IP publique.
Le but va ensuite d’être, depuis votre poste de travail au bureau, d'atteindre votre serveur de rebond pour, à partir de celui-ci, accéder aux ressources d’Internet sans filtrage.

Multiplexeur SSH/HTTPS: sslh

Le rôle de sslh est d'intercepter les requêtes arrivant sur le port 443 et de les re-diriger vers le bon service:

• Vers SSH si la requête «ressemble» à du SSH
• Vers HTTPS si la requête «ressemble» à du HTTPS

Les avantages de sslh sont:

• D’avoir deux services accessible au travers de l'unique port HTTPS
• De rendre la présence du serveur SSH (accessible par le port 443) plus discret à une rapide analyse

Son utilisation est optionnelle, mais très pratique.
Juste un problème: La version officielle ne supporte que l’IPv4.

Serveur SSH

Le protocole SSH a été conçu pour remplacer Telnet en chiffrant les connexions, mais il sait faire beaucoup plus... Comme créer des tunnels TCP chiffrés.
De plus, et c'est ce qui va nous intéresser ici: le serveur SSH intègre un proxy SOCKS supporté nativement par la majorité des navigateurs.
Il est inclu par défaut dans la majorité des distribution linux (sauf Ubuntu: apt-get install openssh-server).

Serveur HTTPS

Le protocole HTTPS sert à transporter du HTTP encapsulé dans du TLS (anciennement SSL).
Il existe donc plusieurs solutions pour ce service, ce document en présente deux:

• Shell In A Box : Qui est un serveur HTTPS embarquant un émulateur de terminal. Utile si votre objectif n'est que l'accès console à vos machines coûte que coûte.
• Stunnel: Qui est un outil de création de tunnel SSL. L’utilisation de tunnel SSL est plus discrette que l’utilisation de tunnel SSH (le protocole HTTPS reposant sur SSL et non pas sur SSH).

Variables utilisées dans ce document

Pour le reste de l’exemple, on va utiliser les noms suivants:

• Adresse IP du serveur proxy de l'entreprise: 10.10.10.10
• Port d'écoute du serveur proxy de l'entreprise: 8080
• Compte utilisateur sur le serveur proxy de l'entreprise:login-entreprise et mdp-entreprise
• Nom ou IP de votre machine personnelle (serveur de rebond) ayant une IP publique: tutu.kicks-ass.net
  • kicks-ass.net est  un nom de domaine dynamique (ici chez dyndns.com)

• Compte utilisateur sur votre machine personnelle : login-maison et mdp-maison

Comment connaitre l'IP et le port de mon proxy ?

Pour cela il suffit de lancer votre navigateur et d'aller:

• Pour Internet Explorer: Outils, Option Internet, Connexion, Paramètres réseau... Et de récupérer les infos qu'il y a dans la case «Adresse» et «port»
• Pour Firefox: Outils, Option, Avancé, Réseau, Paramètres, Et de récupérer les infos qu'il y a dans «proxy HTTP» et «port»

Si votre navigateur n'indique rien dans les champs sus-cités, mais utilise un script de configuration automatique:

1. Copier l'URL du script, exemple: http://proxy.entreprise.fr/proxy.pac
2. Le coller dans le champ URL de votre navigateur et appuyer sur entrée: Il va vous demander d'enregistrer le fichier proxy.pac, faites-le.
3. Ouvrir ce fichier avec un éditeur de fichier texte et trouver l'adresse et le port de votre proxy (en général sur le port 8080 ou 3128)

Paramétrage de votre serveur de rebond

Les exemples donnés dans ce document le sont pour une machine sous FreeBSD.

sslh

La première étape est l'installation du multiplexeur sslh.
Voici comment l’installer par les ports (ou par «pkg_add -r sslh»):

cd /usr/port/net/sshl
make install clean

Maintenant reste à le configurer, pour cela ajouter ces lignes dans le /etc/rc.conf:

#Enable sslh
sslh_enable="YES"
sslh_ssltarget="localhost:4200"
sslh_sshtarget="localhost:8022"
sslh_sshtimeout="4"

Ces lignes déclarent à sslh de rediriger le HTTPS vers le port localhost:4200 et le SSH vers le port localhost:8022.
Puis lancer-le:

/usr/local/etc/rc.d/sslh start

SSH

Voici un exemple de fichier /etc/ssh/sshd_config.
Pour limiter, un peu, les attaques brut-force de mot de passe, on change le port d'écoute (le mieux étant de faire écouter le SSH sur son localhost uniquement, car l'accès se fait désormais au travers de sslh… Ou encor mieux utiliser des certificats à la place des mots de passe).

Voici un exemple de fichier sshd_config :

# On utilise un autre port que celui par défaut Port 8022 #On bloque l'accès par le compte root PermitRootLogin no #On permet le tunneling AllowTcpForwarding yes #On permet de faire des reverse Tunnels GatewayPorts yes #Optimisation pour le keepalive de la session SSH TCPKeepAlive yes ClientAliveInterval 30 ClientAliveCountMax 99999 #Ligne standard pour le SFTP Subsystem sftp /usr/libexec/sftp-server

Serveur HTTPS

Il ne reste plus que le serveur HTTPS.
Ici plusieurs solutions sont disponibles, ce document en présente deux.

Shell In A Box

Outil parfait pour avoir un accès console au travers d’un navigateur web.
Voici comment l'installer, toujours sous le meilleur OS du monde (ou par «pkg_add -r shellinabox»):

cd /usr/port/net/www/shellinabox
make install clean

Maintenant reste à le configurer, pour cela ajouter ces lignes dans le /etc/rc.conf:

# Enable shell-in-a-box
shellinaboxd_enable="YES"

Puis le lancer:

/usr/local/etc/rc.d/shellinaboxd start

Stunnel

À rédiger.

Redirection de port

Si vous êtes derrière une Box ADSL réalisant du NAT, il va falloir maintenant la paramétrer la redirection du port 443 vers votre machine de rebond (google est votre ami).

Paramétrage du poste client (au bureau)

1ère étape: Montage du tunnel SSH à travers le proxy

Client Linux/BSD

Le client SSH inclu avec les Linux/BSD n’est pas capable, tout seul, d’utiliser un proxy HTTP (contrairement à Putty sous Windows).
Il faut l’assister avec un logiciel du type corkscrew(«pkg_add -r corkscrew» sous FreeBSD)

Puis on crée le dossier ~/.ssh/config avec ce contenu:

ProxyCommand /usr/local/bin/corkscrew 10.10.10.10 8080 %h %p ~/.ssh/myauth

Et on renseigne le login et mot de passe dans le fichier ~/.ssh/myauth :

login-entreprise:mdp-entreprise

Il faut ensuite protéger le fichier ~/.ssh/myauth:

chmod 600 ~/.ssh/myauth

Puis on crée un tunnel SSH SOCKS (tunnel dynamique):

ssh -p 443 -N -D 1080 tutu.kicks-ass.net

Client MS Windows

Pour limiter les traces sur le poste de travail, utiliser des versions portables de:

• Portable Putty
• Portable Firefox

Et les stocker les sur une une clef USB.
Maintenant on lance Putty et on configure une nouvelle session:

• Host name (or IP address): Nom ou IP de notre machine personnelle tutu.kicks-ass.net
• Port: 443
• Protocol: SSH
• Saved Sessions: Un joli nom qui ressemble à du boulot (serveur dev java par exemple).

Il faut maintenant déclarer le proxy de l'entreprise dans «Connection », « Proxy » :

• Proxy type: HTTP
• Proxy hostname: 10.10.10.10
• Port: 8080
• Username: login-entreprise
• Password: mdp-entreprise

Ajouter un tunnel dynamique:

• Source port: 1080 (prendre un autre s'il n'est pas disponible sur votre poste de travail)
• Cocher la case: dynamic

Enregistrement des paramètres:

1. retourner sur l'écran Session
2. cliquer sur Save

Vérifier la connectivité SSH

Lancer la session Putty, il devrait vous demander le login et le mot de passe de votre serveur SSH (attention ce n'est pas le login/mot de passe de votre compte sur le proxy).

login as: login-maison Using keyboard-interactive authentication. Password: mdp-maison [moi@tutu ~]$

La connexion doit être acceptée pour que la suite du document  fonctionne !

Si cela ne fonctionne pas: Soit vous avez fait une erreur quelque part, soit le proxy de l'entreprise est correctement configuré et vérifie la validité du protocole qui utilise le port 443.
Il faut donc essayer de se connecter sur le serveur HTTPS.

Laissez cette fenêtre active pour le reste de l’exemple (car c’est votre tunnel) !

2ème étape: Déclaration du proxy SOCK sur vos applications (ex: Firefox)

Sous firefox entrer l'URL about:config (je n'utilise pas le menu Outils/Option/Réseau car un bug d'affichage sur Firefox 3.0.3 empêche cette configuration).
Puis configurer les paramètres suivants:

• Vérifier que les entrées suivantes sont à 0:
• network.proxy.http
• network.proxy.ftp
• network.proxy.gopher

• network.proxy.socks: 127.0.0.1
• network.proxy.socks_port: 1080
• network.proxy.socks_remote_dns: true
• network.proxy.socks_version: 5
• network.proxy.type: 1

3ème étape: Si le SSH est interdit ou ne fonctionne pas

Si le proxy est correctement configuré pour détecter la conformité du protocole circulant sur le port 443  (et interdit votre SSH à la place de SSL), vous pouvez, grâce au multiplexeur sslh vous connecter en SSL:

1. Soit par l’utilisation de Shell in a box: Il suffit de lancer votre navigateur à destination de votre serveur de rebond
2. Soit par l’utilisation de stunnel.

Voici comment utiliser stunnel:

À rédiger

S’amuser encore plus

Partager avec les copains… et les copines !

Une fois que vous avez sué eau et sang pour arriver à surfer tranquille, voici comment faire pour donner l’accès à vos collègues…. C’est très simple (et c’est plus rigolo de se faire virer à plusieurs).
Il suffit, au niveau du forwarding de port dans Putty, de cocher la case « Local ports accept connections from other hosts ».

Et maintenant, il ne reste plus à vos collègues, qu'à configurer leur navigateur pour utiliser le proxy SOCKS de votre poste de travail ;-)
Ca veut dire, que si dans votre entreprise, l’IP de votre PC de bureau est le : 192.168.1.20. Ils devront configurer leur navigateur pour aller sur le proxy :
192.168.1.20, sur le port 1080.

Sous Linux/BSD, il suffit d'ajouter l'option -g à la ligne SSH.

Cette option de partage de votre accès est très instructive, car elle vous place désormais dans le rôle du «contact administratif» de votre IP publique et des devoirs que cela implique.
Je m’explique:
Grâce à cette manipulation, vos 6 collègues, grâce à vous, peuvent aller surfer sur l’ensemble des sites (sans filtrage)… Car techniquement parlant c’est comme s’ils surfaient depuis chez vous.
Si un de vos collègues s’amuse, à travers votre tunnel, à insulter votre supérieur hiérarchique sur facebook … À votre avis, suite à l’enquête de police qui va prouver que le message vient de votre IP… Comment allez-vous faire pour prouver que ce n’était pas vous ET identifier l'auteur du message ? :-)

Faire autre chose que du surf

Les tunnels SSH permettent de faire plein de choses !!!
Un exemple (volontairement compliqué car on n’utilise pas la fonction de proxy sock) avec la radio en ligne : Vous voulez écouter nounours box (au bureau).
Et pour ça, vous avez donc téléchargé VLC portable  sur votre clef usb.

Récupérer le fichier pls :
http://radio.nounoursbox.com/nounours.pls


Récupèrer l’adresse du site : rs1.radiostreamer.com
Et le port : 8040
Puis remplacer dans ce fichier l’adresse « rs1.radiostreamer.com », par « 127.0.0.1 » :
Dans putty ajouter un nouveau tunnel SSH :

Puis on relancer la connexion …. Et lancer le fichier .pls modifié dans VLC.

Accéder à son PC bureau depuis Internet!

Le plus rigolo avec les tunnels SSH, est qu'il est possible, depuis votre serveur de rebond, de remonter le tunnel pour atteindre votre poste client (à l'intérieur de l'entreprise).
Voici un exemple avec un petit serveur WEB portable  lancé sur votre PC du bureau. Voici le principe:

Une fois votre serveur WEB portable lancé, il suffit d'ajouter ce tunnel SSH dans putty:

Puis à partir de n'importe quel poste sur Internet, lancer un navigateur et entrer cette URL:
http://tutu.kicks-ass.net:8080
Et voilà! Le tour est joué! Vous avez accès à votre serveur du bureau!
Maintenant vous pouvez essayer avec un serveur VNC, etc.... La commande sous Linux/BSD est :

ssh -v -p 443 -N -R 8080:localhost:80 tutu.kicks-ass.net

Comment s’en protéger ?

Plaçons nous du «coté lumineux» de la force maintenant.

L'aspect technique

Le proxy et/ou le firewall doivent vérifier à minima le respect protocolaire en vérifiant qu’à travers le port 80 ne cirule que du HTTP et qu’à travers le port 443 que du SSL par l’usage de filtre applicatif comme l7-filter: Mais ce travail vous permettra de limiter l'usage de tunnel SSH uniquement.
Concernant les tunnels SSL, à part une étude poussée (statistiques comportementales par l’analyse des logs par exemple), il est difficile de prouver la différence entre un tunnel SSL et un serveur HTTPS.
La méthode la plus efficace de filtrage d’URL est l’utilisation de liste blanche (n’autorisant qu’une liste de site autorisé) par le blocage de l’ensemble des accès vers des serveurs personnels…

Ce document ne parle pas des Tunnel DNS, mais pour les bloquer il faut que les serveurs DNS internes n’interrogent pas les seveurs DNS Internet de votre FAI.
Lorsqu'un navigateur est configuré pour utiliser un proxy, il envoie l'URL brute (sans résolution de nom) au proxy. C’est le proxy qui résoud le nom DNS, c’est donc uniquement le proxy qui doit avoir accès aux DNS de votre FAI.

L’aspect humain

Le jeu du chat (l'admin réseaux/sécurité) et de la souris (le salarié) est une course sans fin. Les moyens de protection (gros consommateur de moyen et de personnel) à mettre en œuvre doivent simplement être en relation avec le coût d’une divulgation non contrôlée de vos données .

C'est pourquoi, pour la majorité des entreprises (manipulant des données non sensibles) je trouve plus intelligent d’éviter de démarrer ce jeu en ne bloquant pas les sites «non professionnel» mais limitant leur débit).

Exemple 1: Sites consommateurs de bande passante

Dans cet exemple l’administrateur réseau en a marre de la lenteur de son accès internet. Il lance un rapide audit (ntop), et surprise: C’est youtube et dailymotion qui consomment la majorité de la bande passante.

1. Première idée bête et méchante: Bloquer ces sites, mais cela risque de pousser pas mal d’utilisateurs à chercher des méthodes de contournement (et donc démarrer le jeu du chat et de la souris).
2. Seconde idée plus intelligente (donc pas très courante): Comme il y a déjà un proxy pour logger l’activité des salariés (obligation légale), il l’utilise pour réduire (ou simplement dé-prioritiser) la bande passante liée à ces URLs en utilisant la fonctionnalité delay_pools de squid par exemple.

L’usage du second choix, permettra toujours aux salariés d’aller sur Youtube (on évite de les pousser à trouver une solution de contournement) tout en préservant l’usage professionnel de votre accès Internet.

Exemple 2: «Protection de la productivité»

Superbe argument commercial de l’ensemble des marchants de solution de filtrage d’URL…

Second exemple, pour lequel la direction d’une entreprise a réussi à faire croire à l'administrateur réseau que son rôle était aussi de «protéger» la productivité des employés (qui est le rôle du management) en lui demandant de bloquer les services de discussion en ligne...
L’admin s’exécute malgré que ce service:

1. Ne consomme pas de la bande passante (contrairement à youtube et consort).
2. Ne soit pas le meilleur vecteur de fuite d’information (si vous avez accès à gmail, autant l’utiliser directement pour l’envoi de grosses pièces jointes).

Une fois que le salarié va découvrir que, par exemple  «Google Chat» ne fonctionne plus, qu'est ce qu'il va naturellement faire en premier ? Pas se mettre à travailler 10 heures par jour… non, il va chercher un moyen de retrouver (facilement) ce service, en utilisant par exemple son téléphone personnel 3G.
Résultat:

1. Vous n'avez «protégé» en rien la productivité de cet employé. Si la personne s'ennuie au travail (si si ça existe), ce n'est pas en bloquant ces services en ligne que vous aller résoudre son problème.
2. Vous n’avez plus aucune visibilité sur son activité… Avant de filtrer ce service vous aviez la capacité technique de générer des stats sur son usage de l’accès internet, mais maintenant ce n’est plus possible.

La cohérence des restrictions

Vos utilisateurs accepteront très facilement les restrictions que vous leur imposez si votre justification est compréhensible.

=> N’essayez pas de leur expliquer que pour empêcher la fuite d’information, vous avez bloqué ll’accès aux webmails, google chat, google docs et autres sites équivalents si, en même temps, vous n’avez pas verrouillé sur l’ensemble des postes de travail l’accès au graveurs CD/DVD et ports USB… Votre justification ne sera pas cohérente, donc incomprise, donc contournée.