Pourquoi ce dossier ?

Il peut être parfois intéressant de sortir par un VPN. Par exemple pour contourner un blocage de site ou pour accéder à du contenu qui n'est pas encore disponible dans le pays où l'on habite. Le soucis c'est qu'utiliser un VPN implique généralement plusieurs choses :

- Installer un logiciel sur son ordinateur
- Envoyer inconditionnellement tout son trafic par le VPN à partir du moment où le client VPN est démarré
- Beaucoup de difficultés si l'on souhaite utiliser le VPN sur un appareil mobile, tel qu'un smartphone

La solution proposée dans ce dossier est de configurer le VPN sur un serveur (et non sur le client) et d'utiliser un proxy HTTP installé sur le même serveur pour communiquer avec le VPN. Le client peut alors sélectivement utiliser le proxy (par le bias d'un fichier .pac par exemple) pour router son trafic Web selon ses besoins.

Le schéma ci-dessous résume la architecture :




Avant de commencer

Je vous propose quelques lectures en rapport avant de se lancer dans le vif du sujet :

- Policy routing avec Packet Filter
- Gérer multiples tables de routage avec setfib
- Article de Wikipedia sur le PAC
- La documentation officielle Packet Filter


Configuration requise

Pour réaliser ce projet, nous allons utiliser les applications et services suivants :

- Le service VPN TunnelBear qui se base sur OpenVPN ; vous pouvez utiliser le service de votre choix.
- FreeBSD 8.2 avec support multiples tables de routage (important !)
- Squid 3.1


Configuration

TunnelBear

Téléchargez et installez l'application proposée car elle vous permettra de créer un compte gratuit avec 500Mo de quota mensuel. Ils ont des abonnements payants si vous avez besoin de plus de 500Mo mensuel. Localisez les fichiers suivants et copiez-les sur le serveur dans /usr/local/etc/openvpn :

- tbearProd.ovpn
- ca.crt
- key.crt
- key.key

Démarrez la connexion VPN avec le client officiel sur le serveur souhaité et utilisez la commande netstat pour déterminer l'IP du serveur et son port (443 normalement).

Installez ensuite /usr/ports/security/openvpn en choisissant "PW_SAVE Interactive passwords may be read from a file". Créez un fichier /usr/local/etc/openvpn/password lisible uniquement par root avec votre login et mot de passe sur deux lignes.

Nous allons maintenant créer une configuration tunnelbear.conf à partir de tbearProd.ovpn. Le mien ressemble à ceci :



Configurez /etc/rc.conf pour activer OpenVPN :



Enfin, démarrez la connexion VPN, et vérifiez avec ifconfig que vous parvenez à vous connecter :



Si le VPN démarre correctement, nous pouvons passer à la configuration du proxy Squid.

Squid

Installez /usr/ports/www/squid31 en prenant soin de désélectionner toutes les options pour alléger l'installation. Côté configuration, si vous ne voulez pas qu'on sache que vous surfez par un proxy, je vous conseille d'ajouter les directives suivantes dans votre configuration :



Nous n'allons pas démarrer Squid de la façon habituelle (en l'activant dans rc.conf) car nous avons besoin qu'il démarre en utilisant une table de routage alternative. Pour ce faire, nous allons utiliser un script rc spécifique qui aura comme rôle de configurer les routes et démarrer Squid :

/usr/local/etc/rc.d/setfibroutes

Redémarrez le serveur (si possible) pour vérifier que tous les services (OpenVPN et Squid) démarrent correctement.

Utilisation reply-to avec PF

Si vous tentez d'utiliser le Squid à ce stade, vous allez constater qu'il ne fonctionne pas ; en effet il reçoit bien les requêtes sur l'interface publique re0 du serveur, mais il répond vers tun0, ce qui ne peut pas fonctionner. Pour éviter ce soucis, nous allons utiliser une règle très utile de PF :

/etc/pf.conf


Note : 22222 est le port d'écoute du proxy Squid.

Relancez PF et normalement tout fonctionne maintenant. Squid répond bien sur l'interface publique pour discuter avec le client, et utilise l'interface tun0 pour sortir.


Conclusion

J'espère que vous avez aimé ce petit dossier et n'hésitez pas à faire des remarques si vous en avez, bien sûr.

Nous avons déjà évoqué certaines fonctionnalités avancées de PF, par exemple la protection anti DOS et le filtrage IPv6. Dans cet article, nous allons explorer les possibilités de policy routing ou politique de routage en français. Ce type de configuration est nécessaire quand le routeur dispose de plusieurs accès Internet et que vous souhaitez contrôler les flux.

Ci-dessous un schéma de principe :



Plusieurs remarques importantes :

- le routeur, installé en FreeBSD 8.1 x64, offre déjà les fonctionnalités de NAT/FW
- vlan1 et tun1 ont des IP publiques statiques (mais seulement vlan1 a une route par défaut)
- le laptop et serveur ont le routeur comme gw vers Internet


Gestion des flux entrants

Pour commencer, nous allons configurer PF pour que l'interface tun1 puisse répondre à l'ICMP echoreq (ping) et que le serveur Web soit accessible depuis les deux IP publiques. Le routeur héberge un serveur SSH sur port 2222, nous allons autoriser les connexions depuis tun1.

Pour ce faire, nous allons utiliser l'option reply-to qui permet de forcer le chemin de retour ailleurs que par la route par défaut.

pf.conf



Cet exemple est assez explicite et ne contient que la partie qui nous intéresse, à savoir le routage des flux. On peut noter que l'adresse de la passerelle de l'interface pppoe_gw est configurée statiquement, car elle est utilisée par l'option reply-to pour router les paquets.

Un autre cas de figure qui est intéressant de gérer c'est les flux sortants.

Gestion de flux sortants

Le but cette fois-ci sera de contrôler par quel lien passera le traffic (naté) sortant.

Ceci peut présenter plusieurs intérêts :

- router des flux sensibles (SSH, VoIP, jeux en ligne) via un lien dédié
- dédier un lien à un utilisateur ou à un groupe d'utilisateurs
- réduire les coûts en routant les flux non critiques via un lien bon marché
- améliorer la performance en profitant des accords de peering de plusieurs opérateurs, en routant par exemple vers Google via l'opérateur qui a la meilleure connectivité vers Google

Ainsi de suite.

Ceci se fait avec l'option route-to, comme dans l'exemple ci-dessous :



Cet exemple se contente de rerouter les flux vers http://myip.dk/ via tun1, alors que la passerelle par défaut est vlan1.

On peut formuler plusieurs remarques par rapport au fonctionnement de cet exemple :

- Le re-routage des flux sortants se fait en deux étapes : routage vers la bonne interface ($pppoe_if), puis réécriture de l'IP source.
- La règle de pass in est appliquée avant le NAT, qu'on applique donc bien sur l'interface de sortie souhaitée $pppoe_if.
- Les règles de NAT sont évaluées de haut en bas. La première règle qui correspond est appliquée ; il faut donc mettre la directive par défaut en bas, et les exceptions en haut.

Conclusion

PF est un outil très flexible pour réaliser de la politique de routage statiques grâce aux options reply-to et route-to.

Historique :
- 20110216 : première version
- 20110222 : refonte de la partie sur les flux sortants

A l'heure où j'écris ces lignes, dans un peu plus de 400 jours les reserves de blocs IPv4 seront épuisés. Alors que beaucoup d'opérateurs disposent de réseaux IPv6 au niveau des backbones, la connectivité native tarde à arriver vers les extrêmités du réseau, c'est-à-dire chez les clients. Le déploiement limité d'IPv6 native n'encourage pas les fournisseurs de contenus à migrer leurs services en IPv6 du fait d'un intérêt limité. Le tunnelbroker apparaît alors comme une solution de transition peu coûteuse et facile à déployer.

Dans ce dossier, nous allons configurer une machine FreeBSD avec un tunnelbroker pour offrir une connectivité IPv6 sécurisée vers des machines d'un réseau local.

Typologie

Nous allons travailler avec une machine FreeBSD 8.0 ayant une seule carte réseau physique (em0), reliée sur le réseau local. La connectivité Internet IPv4 arrive par une interface virtuelle (vlan1), dont l'interface parent est em0.

Configuration d'un tunnel basique

Plusieurs sociétés offrent de la connectivité IPv6 tunnelisée. Nous allons utiliser le service Tunnelbroker de Hurricane Electric qui propose des options intéressantes comme la délégation RDNS ou l'allocation de plusieurs subnets.

Creez un compte sur le site de HE.

Séléctionnez ensuite "Create Regular Tunnel" et saisissez votre IPv4 publique (fixe de préférence). Vous allez pouvoir créer un /64 routé et générer la configuration pour divers systèmes d'exploitation, dont FreeBSD. Dans cet exemple nous allons supposer que votre IP publique est 85.1.2.3 et que votre /64 alloué est 2001:11:22:33::/64.

Cela nous donne :



Ifconfig permet de vérifier que le tunnel a bien été créé :



Utilisez ensuite la commande ping6 pour vérifier que le tunnel fonctionne :



Si cela ne fonctionne pas et que vous avez un firewall sur la passerelle, il se peut qu'il soit configuré pour bloquer le traffic tunnelé. Voici un exemple de configuration PF pour autoriser le traffic du tunnel :



En supposant que cette partie fonctionne, nous allons maintenant voir comment étendre cette connectivité IPv6 au réseau local.

Routage d'un subnet

Retournez dans l'interface Tunnelbroker et demandez l'allocation du /48 routé ; nous allons utiliser un subnet /64 de ce /48 pour connecter notre réseau local. Dans cet exemple nous supposons que le /48 alloué est 2001:44:55::/48 et que le subnet /64 "LAN" est 2001:44:55:1::/64.

Vous allez configurer une IP du subnet LAN sur l'interface em0 :



Pour activer le routage entre le subnet "LAN" et le subnet "WAN", il convient d'activer le forwarding IP :



En configurant une machine du réseau local en IPv6 manuelle, 2001:44:55:1::2 par exemple, vous devriez pouvoir constater le bon fonctionnement de l'ensemble :



Nous voyons ici l'IP de notre routeur (2001:44:55:1::1), puis l'IP de l'endpoint du tunnel (2001:11:22:33::1).

Filtrer le traffic IPv6 avec PF

A ce stade vous avez normalement un réseau IPv6 fonctionnel, mais non sécurisé dans la mesure où les IP sont publiques et le traffic n'est pas du tout filtré, juste routé. Nous allons utiliser PF pour filtrer le traffic directement au niveau du routeur. Ma configuration PF contient beaucoup de règles ; par soucis de lisibilité les règles ici ne concernent que le tunnel IPv6 :



Cette configuration bloque tout le traffic entrant sauf ICMP, Web vers "macmini_v6" et ssh de "ext_server", et autorise ICMP, TCP et UDP sortant. Elle s'applique à toutes les machines en IPv6.

Autoconf

Une des fonctionnalités très pratiques de l'IPv6 est l'autoconf qui permet sans DHCP aux machines d'obtenir des IP statiques grâce à la MAC de la carte réseau. Sous FreeBSD, le router advertisement daemon ou rtadvd permet la fonctionnalité d'autoconf. Pour l'utiliser, il faut éditer rc.conf et rtadvd.conf :

/etc/rc.conf


/etc/rtadvd.conf


Démarrez rtadvd pour profiter de l'autoconf IPv6.

Démarrage automatique des services

Pour finir, nous allons configurer l'auto démarrage des services dans rc.conf :

rc.conf


Au prochain reboot de la machine, les services devraient monter automatiquement.

Conclusion

Avec un tunnelbroker, il est plutôt facile de déployer un réseau IPv6 de transition, en attendant un déploiement plus généralisé d'IPv6 native.

Historique

- 19 juin 2010 : version initiale

Free propose plusieurs méthodes pour relier le boîtier ADSL et le boîtier TV HD : Wi-Fi, Freeplugs ou câble Ethernet directement. Dans cet article, nous allons voir comment transporter le flux TV sur un réseau Ethernet existant composé de plusieurs switchs.

Typologie

Le schéma suivant illustre le raccordement entre les différents éléments :



Fonctionnement

Les 4 ports du miniswitch + le port jaune "boîtier TV" forment un mini switch 5 ports ; nous pouvons donc utiliser un port du switch 4 ports pour recevoir le flux TV. Niveau réseau, Internet est accessible sans VLAN, alors que le contenu TV est transmis sur le VLAN 100, avec paquets taggés. Il nous suffit donc d'acheminer ce VLAN à travers le réseau.

Configuration

La configuration est assez simple en CLI habituel Cisco. Je suppose ici que la Freebox ADSL est relié sur le port 1, que l'uplink vers le switch non manageable se fait sur le port 3, que le VLAN "LAN" est 1 (vlan natif) et que le VLAN "internet" est 2.



Démarrez maintenant le boîtier TV, qui devrait passer l'étape "Réseau" sans soucis.

Conclusion

Il est tout à fait possible de se passer des freeplugs !

Pourquoi ?

Sécuriser un site par connexion SSL apporte deux choses :
- cela empêche qu'on puisse intercepter et décoder une transmission entre le navigateur et le serveur Web
- cela garantit que le site visité est bien celui qu'il prétend être

Par exemple, une injection DNS (DNS poisoning) pourrait amener le navigateur sur un serveur différent, mais cela provoquerait un avertissement au niveau du navigateur parce qu'il est impossible de connaître la clef privée du serveur authentique.

Fonctionnement de la persistance HTTP

Comme le HTTP est stateless, Netscape a inventé les cookies pour stocker des informations persistantes entre plusieurs accès successifs. Voici comment cela fonctionne :

- Le navigateur effectue une première requête HTTP (GET ou POST par exemple) sur le serveur Web
- Le serveur retourne un cookie dans les entêtes HTTP, qu'il sauvegarde localement
- Le navigateur sauvegarde également ce cookie
- Aux connexions suivantes, le navigateur transmet son cookie
- Le serveur reconnaît le cookie, permettant d'identifier le navigateur

Le serveur Web a la possibilité de stocker diverses informations dans le cookie, comme le nom d'utilisateur, la date de dernière visite, ainsi de suite. Les informations contenues dans la session sont sécurisées parce qu'elles sont conservées localement sur le serveur ; le navigateur ne peut modifier les informations du cookie de session. Par contre, si le cookie est intercepté pendant sa transmission, une personne malveillante pourrait se faire passer pour l'utilisateur légitime et modifier son mot de passe ou visualiser les informations de son compte, par exemple.

Les pièges à éviter

Le problème réside dans la possibilité de pouvoir accéder simultanément au serveur Web en HTTP normal et SSL. En effet, on peut identifier les deux cas suivants qui pourraient entraîner la perte du cookie de session :

- L'application délivre en HTTP non sécurisé le cookie de session initial

Le cookie restera valide même si la suite de la navigation se fait par une connexion sécurisée.

- Le navigateur accède en HTTP non sécurisé après une navigation sécurisée

Le navigateur va alors transmettre son cookie, précédemment protégé, en clair sur le réseau.

Que faire ?

Il convient de suivre les consignes suivantes pour sécuriser la transmission du cookie de session :

- Empêcher l'application d'émettre son cookie en HTTP non sécurisé

On peut utiliser mod_rewrite pour imposer une redirection http:// vers https:// au niveau du serveur Web. De cette manière, l'application hébergée n'a jamais la possibilité de transmettre son cookie de façon non sécurisée.

- Envoyer ses cookies avec le flag secure

Ce flag informe le navigateur qu'il ne doit jamais divulguer son cookie si la connexion n'est pas sécurisée.

En PHP, on peut procéder comme ceci :



Attention : il est important de respecter l'ordre des commandes dans l'exemple précédent ; la fonction ini_set() doit d'exécuter avant session_start().

Conclusion

Assez simple : il ne faut pas se contenter d'activer mod_ssl pour sécuriser un site Web !

Historique

- Version intiale : 25/12/2009