Archives de catégorie : Réseau

Proxy socks via SSH pour Firefox

En milieu hostile — victime de censure ou plus bêtement connecté depuis un wifi public, un hôtel, etc. — ou par volonté de ne pas trop laisser les sites consultés vous suivre géographiquement, il est préférable de pouvoir utiliser un proxy. Dans le cas qui nous intéresse, nous allons utiliser un tunnel SSH en tant que proxy SOCKS local pour le navigateur Mozilla Firefox. C’est super simple, il suffit d’avoir un compte SSH qui traîne. Pour la suite de l’exercice, ce compte SSH sera nommé “tunnel“.

Ouvrir le tunnel

Pour cela, rien de plus simple, tu prends ta ligne de commande et tu tapes :

~$ ssh -2NfCT -D 8080 tunnel@example.org

Avec cette commande tu tu connectes en tant qu’utilisateur ‘tunnel‘ sur la machine ‘example.org‘ et le tunnel est accessible en local sur le port 8080. Pour vérifier que le tunnel soit bien là :

~$ netstat -apnt

(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
[…]
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      -               
tcp        0      0 127.0.0.1:8080          0.0.0.0:*               LISTEN      4464/ssh
[…]

Nous sommes content, il y a bien SSH sur le port 8080.

Vérifier notre IP

Avant d’utiliser le proxy, nous allons vérifier notre adresse IP publique. Car une fois que le navigateur sera configuré pour utiliser le proxy, elle devra être différente et correspondre à l’adresse IP du serveur SSH utilisé.

Il existe une foule de service pour découvrir son adresse IP, mais je vais utiliser le mien : ipso.me. J’obtiens donc :

IPso.me découvre mon adresse IP - Avant proxy

Configurer Firefox pour utiliser le proxy SOCKS

Dans Firefox, ouvrir le menu “Edit > Preferences” et dans la fenêtre de dialogue choisir l’onglet “Advanced” puis “Network” et finalement le bouton “Settings” :

Firefox Preferences

Choisir l’option “Manual proxy configuration”, cela active toute une série de champs de saisies. Dans le champ “SOCKS Host” y mettre “127.0.0.1”, notre adresse de loopback (à adapter selon configuration) et dans le champ “Port” y mettre “8080” qui est le port d’écoute du tunnel. Ensuite bien s’assurer que “SOCKS v5” est sélectionné, ainsi :

Connection Settings

Tu penses en avoir fini, mais non, il manque le dernier détail qui tue : proxifier les requêtes DNS. En effet, sur Firefox elles ne passent pas par défaut via le proxy SOCKS. Il parait que d’autres navigateurs le font. Mais pour Firefox, il faut lui forcer la main. Pour cela, ouvrir (1) “about:config” (saisir “about:config” dans la barre d’adresse) puis rechercher (2) l’entrée “network.proxy.socks_remote_dns” qui est à “false” par défaut. Double cliquer (3) sur la ligne correspondante pour passer la valeur à “true” :

about:config - Mozilla Firefox

 

Vérifier

Tu retournes sur ton site préféré pour découvrir ton adresse IP et voilà :

IPso.me découvre mon adresse IP - Après proxy

Tout est pour le mieux dans le meilleur des mondes.

Note : Il n’y a pas que Firefox dans la vie. Pour lancer Chromium en mode incognito et pour qu’il utilise le proxy SOCKS sans fuite DNS, d’après cette page du site chromium.org il faut faire ainsi :

~$ chromium-browser --incognito --proxy-server="socks5://127.0.0.1:8080" --host-resolver-rules="MAP * 0.0.0.0"

 

Tester l’expédition d’emails en Java

Lorsqu’on développe un programme qui expédie des emails, plutôt que d’utiliser un vrai serveur de mails, il peut être avantageux d’utiliser un faux serveur. L’avantage c’est que cela est intégrable à des tests unitaires et qu’on évite l’erreur de manipulation qui envoie un email à tous les contacts de la base de données.

Il existe plusieurs bibliothèque pour réaliser cela :

  • devnull smtp : faire un “java -jar DevNullSmtp.jar” pour lancer une interface graphique simple qui permet de lancer un fake serveur sur le port désiré. Il ne peut pas être intégré à des tests unitaires, mais on peut visualiser en direct les messages reçus dans l’interface. Gratuit mais non libre.
  • Wiser : Bibliothèque Java qui peut être intégrée à des tests unitaires. Licence Apache 2.0
  • Dumbster : Bibliothèque Java qui peut être intégrée à des tests unitaires. Licence Apache 2.0. Projet sans mise-à-jour depuis 2005.

CDN – Content Delivery Network

Un CDN permet d’améliorer la réactivité du chargement d’une page web en déléguant l’hébergement de certains contenus à des serveurs spécialisés qui sont souvent répartis à travers le globe pour être au plus prêt des utilisateurs.

Voici un projet intéressant qui permet de se construire un CDN en utilisant GoogleAppEngine : Cirrux-Cache.

Sinon voici quelques fournisseurs de service CDN :

  1. CacheFly
  2. Amazon Cloudfront
  3. Rackspace Cloudfile
  4. Cloudlayer

HTTP et Telnet : pour tester rapidement un serveur HTTP

Voir rapidement les headers d’une reponse HTTP d’un serveur web peut s’avérer très pratique, pour cela, une réponse rapide : telnet.

Le protocole HTTP répond à la RFC 2616 du W3C.

Telnet

Pour se connecter à un serveur, faire la ligne de commande suivante :

> telnet serveur num_port

par exemple :

%> telnet www.voila.fr 80

Une fois connecté, on va demander un document. On va utiliser la méthode GET. Par exemple sur la racine du site (ie / ) :

GET / HTTP/1.0 <CRLF><CRLF>

Il est important de préciser le protocole que l’on va utiliser après le document demandé (ici on demande du HTTP/1.0, ca aurait pu être du HTTP/1.1).

Il est primordial de placer 2 <CRLF> (ie des retours à la ligne) après la commande GET, pour signaler au serveur que la commande est complète.

On peut construire des requêtes plus compliquées, en enchainant les Headers, par exemple :

GET / index.html HTTP/1.0 <CRLF>Accept : text/html, image/gif <CRLF>

User-Agent : Mozilla/4.0 (compatible ; MSIE 4.0 ; Linux X11 2.2.17) <CRLF><CRLF>

Autorisation

Les méthodes d’autorisation pour accéder à certaines zone d’un serveur HTTP répondent à la RFC 2617 du W3C.

Lorsqu’une zone du serveur est protégée par cette méthode, la demande d’un document de cette zone renvoie une réponse comme suit :

HTTP/1.0 401 Authorization RequiredDate: Wed, 23 Jan 2002 15:12:30 GMT

Server: Apache/1.3.20 (Unix)  (Red-Hat/Linux) ApacheJServ/1.1.1 mod_ssl/2.8.4 OpenSSL/0.9.6

WWW-Authenticate: BASIC realm="RealmName"

Content-Type: text/html

X-MTracker-Version: v4.0 build 49.5

Expires: Thu, 01 Jan 1970 00:00:00 GMT

Last-Modified: Wed, 23 Jan 2002 15:12:30 GMT

Cache-Control: no-cache must-revalidate

Pragma: no-cache

Le Header important est WWW-Authenticate. Si l’utilisateur n’est pas déjà authentifié pour le RealmRealmName“, une fenêtre pop-up apparaitra et demandera le login/password de l’utilisateur.

Autorisation et Telnet

Pour s’authentifier en utilisant Telnet sur un serveur HTTP avec l’autorisation ’Basic’, il faut ajouter un Header “Authorization”, suivi d’une chaine encodée BASE64 composée du login et du password. La structure de cette chaine est :

login:password

Si l’on veut s’identifier comme l’utilisateur marc qui a le password antoine, on obtient l’encodage BASE64 suivant : bWFyYzphbnRvaW5l [1].

La requête à construire pourra donc être :

GET /servlet/protected/content/ HTTP/1.0 <CRLF>

Authorization: Basic bWFyYzphbnRvaW5l <CRLF><CRLF>

Note : Attention à écrire Basic et non BASIC !

[1] obtenu grâce à la commande perl suivante : %> perl -MMIME::Base64 -e ‘print encode_base64(“marc:antoine”)’

Tunneling SSH – transfert de ports

Le but de ce document est d’expliquer les tunnels SSH. C’est à dire comment utiliser SSH pour faire passer différents protocoles, ce qui permet de sécuriser la communication (une sorte de VPN software). Si vous souhaitez plus de détails sur les différentes possibilités, cet article de Buddhika Chamith vous éclairera : SSH Tunneling Explained.

Quand on se connecte à Internet depuis un lieu public et si ce lieu de connexion ne permet pas d’accéder à des ports particuliers d’un serveur (règles de firewall restrictives), il est possible d’utiliser un serveur intermédiaire sur lequel on a un compte utilisateur et qui fait tourner un serveur ssh. C’est ce serveur qui se connectera au serveur désiré. Cette solution va aussi permettre de chiffrer la communication entre le point d’accès et le serveur intermédiaire.

Pour réaliser cela, on va utiliser un tunnel SSH. Il faut donc que l’on ai accès au port 22 du serveur intermédiaire, mais dans 90% des cas les firewalls laissent sortir le trafic sur ce port.

Le principe

Il faut créer une connexion ssh entre le pc client et le serveur intermédiaire. Cette connexion (le tunnel donc) connectera un port du pc client au serveur intermédiaire. Celui-ci va lire tout ce qu’il reçoit depuis cette connexion et re-expédier le tout vers le serveur destinataire.

attention : sous Linux, on ne peut pas connecter le tunnel sur un port local privilégié si on n’est pas root. Il faut donc prendre un port au dessus de 2000.

Exemple

Je veux lire mes mails par un accés imap. Mon serveur imap est imap.mail.com et je l’interroge sur le port 143 (le porte par défaut IMAP).  Mais le firewall ne laisse pas sortir les connexions vers le port 143.

Je vais donc établir un tunnel SSH entre le pc que j’utilise et un serveur sur lequel j’ai un accés ssh. Ce serveur s’appelle monserveurssh.com et j’ai un compte utilisateur de login moncompte. Je vais connecter le tunnel sur le port 2000 de mon pc client, comme suit :

ssh -2NfC -L2000:imap.mail.com:143 moncompte@monserveurssh.com

Cette commande ne me connecte pas sur le serveur intermédiaire, mais me rend la main de suite grâce a l’option -f combinée avec l’option -N. L’option -2 c’est pour demander à ssh d’utiliser le protocole v2 et l’option -C c’est pour demander de compresser le tunnel.

Il ne me reste plus qu’à brancher mon client mail sur le port 2000 de localhost, et je pourrai lire mes mails, comme si j’étais connecté directement au serveur de mails.

Un détail sécurité

Quand je créé des comptes utilisateurs sur mon serveur juste pour permettre du port forwarding je ne donne pas le droit de connexion au serveur. Pour cela, dans le fichier /etc/passwd je remplace le shell du compte par /sbin/nologin. Ainsi la personne qui a ce compte peut créer des tunnels SSH mais elle ne peut pas se connecter au serveur.

Sous Windows

En utilisant Cygwin et le client ssh fourni avec, cela fonctionne très bien. Putty permet aussi d’établir des tunnels pour ceux qui sont réfractaires à la ligne de commande.

Quelques liens sur le sujet

Faire un backup avec rsync

On peut utiliser ssh pour faire un backup d’une machine distante (pratique pour conserver une copie d’un site web, en ne téléchargeant que ce qui a changé depuis le dernier backup) avec rsync

rsync -v -u -a --rsh=ssh --stats user@serveur.net:/chemin/dossier/distant/a/sauver /chemin/dossier/local