Entries Tagged 'Réseau' ↓

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.

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

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 Realm “RealmName“, 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”)’

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 recoit 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 priviligié 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éé 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

• Remote Desktop and SSH tunneling,
• X over SSH2,
• Documentation sur Putty en francais avec une section sur le transfert de ports

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