Posts tagged ‘reseau’

Ceci est un autre petit memo sur les iptables. Ici, nous allons voir comment rediriger toutes les requêtes sortantes vers un port local de notre machine. Le but est de proposer une solution pour accéder à des services qui se trouvent derrière un firewall, alors que l’on possède par exemple une connexion ssh.

Ce memo complète le précédent sur la redirection de paquets qui nous sont destinés.

Petit rappel : mise en place du NAT

Pour créer une passerelle, il faut activer le transfert de paquet et la translation d’adresses :

sysctl net.ipv4.ip_forward=1
iptables -A POSTROUTING -o eth0 -j MASQUERADE

Mise en place d’un tunnel transparent

On procède ici en deux étapes : d’abord la création du tunnel en tant que tel :

ssh -L port_local:ip_destination:port_destination user@host

port_local : c’est le port de notre machine sur lequel le service sera disponible
ip_destination : c’est l’ip (ou le nom dns) de la machine à laquelle nous voulons avoir accès
port_destination : c’est le port de la machine à laquelle nous voulons avoir accès
user@host : ce sont les utilisateurs et la machine sur laquelle nous allons nous connecter pour accéder à notre destination finale

Ensuite, nous allons automatiser la redirection des paquets avec iptables :

iptables -t nat -A OUTPUT -d $ip_destination -p tcp \
  --dport $port_destination -j REDIRECT --to-ports $port_local
iptables -t nat -A PREROUTING -d $ip_destination -p tcp \
  --dport $port_destination -j REDIRECT --to-ports $port_local

La première ligne est pour nous : elle permet à la machine elle-même d’accéder dorénavant au nouveau service comme d’habitude.
La deuxième ligne est pour le nat à proprement parler : elle permet de rediriger automatiquement les paquets des machines qui nous utilisent comme passerelle.

Plus d’informations sur le fonctionnement des iptables : iptables tutorial, très complet.

HSTS est (et j’adore ce genre de formule auxquelles on ne comprend rien) une norme qui permet de sécuriser l’accès aux sites sécurisés. HSTS signifie HTTP Strict Transport Security (précédemment nommé STS).

Limites actuelles

Aujourd’hui, le protocole HTTPS (HTTP sécurisé) est très robuste. Les principales failles de sécurité proviennent non pas du protocole de sécurisation en lui-même, mais plutôt du phishing, c’est-à-dire de l’identité réelle du site que vous visitez. Vous pouvez très bien aller sur le site par exemple de lcl.fr, mais en réalité vous êtes sur le site de lc1.fr. Pas forcément évident de faire la différence entre les deux au premier coup d’oeil.

Autre problème : vous vous connectez à un réseau wifi gratuit, et alors que vous pensez vous connecter sur le site de lcl.fr, vous êtes en réalité sur une copie de ce site, et c’est le serveur DNS (qui associe une IP à lcl.fr) qui vous trompe. Le certificat de sécurité, en revanche n’est pas valide, mais vous avez l’habitude que ça arrive sur Internet…

La solution proposée

En fait, cette solution n’est pas miraculeuse. Elle permet deux choses :

  1. Si j’arrive sur le site de ma banque, alors je suis obligatoirement en HTTPS. Cela évite les attaques qui consisteraient à y changer les liens en des liens vers un autre site avec une adresse similaire et un certificat valide.
  2. Si quelqu’un cherche à se faire passer pour ma banque et que je suis un abruti qui accepterait un certificat non valide, alors je suis protégé, car le certificat sera automatiquement refusé par mon navigateur.

Mise en place

Un site se déclare HSTS par deux manières différentes :

  • soit il fournit un header HTTP nommé Strict-Transport-Security, qui contient pour combien de temps et sur quelles parties du site appliquer HSTS  (exemple : Strict-Transport-Security: max-age=16070400; includeSubDomains) ;
  • soit il se déclare comme tel auprès des navigateurs (ou bientôt d’une autorité ?). Cette solution permet d’éviter de se faire avoir lors de la première connexion au site internet avec un navigateur tout neuf.

Une fois qu’un site est considéré comme HSTS par le navigateur :

  • Aucune connexion en HTTP non sécurisé ne sera faite. Tout passera directement par HTTPS. Les URL en HTTP (quand vous les tapez vous-même, ou bien à partir de lien trouvés sur des sites) seront automatiquement converties en HTTPS.
  • Si la liaison HTTPS contient une erreur (certificat auto-signé, ou non valide sur le domaine, …) alors la connexion sera automatiquement interrompue et aucune donnée ne sera transmise au site distant.

Conclusion

C’est une bonne couche de sécurité supplémentaire qui va être ajoutée, et qui va permettre d’éviter pas mal d’usurpation d’identité de site Internet. Internet n’est pas un monde magique où tout est rose, et il reste très important de sensibiliser les internautes aux problèmes de sécurité sur Internet, car malheureusement, une telle solution ne permet pas de protéger contre toutes les attaques.

Actuellement, Chrome 6 et Firefox 4 ont adopté la norme.

Sources : Strict Transport Security chez Chrome, la dépêche linuxfr.org sur HSTS dans Firefox

Note : la majorité des opérateurs de téléphonie mobile interdise dans leur forfait d’utiliser le mobile comme modem Internet.

Principe de fonctionnement

Le principe est simple : vous avez un ordinateur, et vous êtes en vacances (au ski, à la mer, …) et vous n’avez pas votre connexion ADSL. Vous avez un ordinateur, pratique à utiliser, qui n’a pas d’internet, et un téléphone mobile, un peu limité, mais qui peut se connecter. L’idée est donc d’utiliser la connexion internet du téléphone pour surfer sur son PC.

L’utilitaire de partage de connexion internet

Dans Windows Mobile, il y a une application nommée « Partage de connexion« . Dans cet utilitaire, vous choisissez la couche réseau à utiliser entre le téléphone et l’ordinateur, et la connexion à utiliser pour se connecter à internet. Afin d’éviter une configuration complexe du bluetooth, je conseille d’utiliser le cable de connexion USB fourni. Ca a aussi l’avantage de recharger le téléphone pendant cette utilisation.

Lorsque vous tapotez sur « Connecter », le téléphone se connecte à internet, et dans le cas de l’USB, il passe en mode « carte réseau USB ». Il prend une adresse IP (192.168.0.1 par défaut) et lance un serveur DHCP. Lorsque le PC va chercher à se connecter au téléphone, il va récupérer une IP (192.168.0.2), et aussi les DNS : aucune configuration manuelle des paramètres IP n’est nécessaire.

Note sur la carte réseau du PC : sous Windows, si vous avez installé le logiciel de synchronisation, vous devriez normalement avoir la carte réseau. Sous linux, il faut compiler le module rndis_host (Device Drivers => Network => Usb adaptaters => Multi-purpose USB networking framework => RNDIS host).

Accès au web

Pas si vite, malheureux ! Vous avez essayé de vous connecter avec Firefox ou IE et ça ne marche pas ? C’est normal ! Votre opérateur bloque sans doute les connexions internet qui ne sont pas identifiées comme « mobile ». Il suffit donc de leurrer votre opérateur en changeant le User-Agent. Pour ce faire, on peut par exemple utiliser le User-Agent switcher, extension Firefox. Il suffit de configurer un profil avec comme User-Agent celui de votre SPA : « SAMSUNG-SGH-i900/1.0 Opera 9.5 ».

A peine Vista sorti, et déjà une mouture du prochain Windows Seven disponible en version bêta.

J’ai pu la tester à partir de VirtualBox. En gros, c’est du Vista dans les interfaces. Grande différence par rapport aux autres versions : un système de dock à icônes à la Mac OS X.

Ma petite astuce du jour : pour que la connexion internet de VirtualBox fonctionne, il faut installer les Guest Additions; mais il faut d’abord penser à faire un clic-droit sur le fichier .exe pour définir la compatibilité (dans les propriétés), et mettre « Windows Vista ». Alors l’exécutable se lancera sans dire que l’OS n’est pas supporté. Alors vous récupèrerez votre résolution d’écran et surtout la carte ethernet sera alors reconnue.

En tout cas une bonne chose en apparence : ils ont gardé la même couche drivers que Vista, donc la majorité des périphériques supportés dans Vista seront supportés dans Seven.