Y’a plus simple mais c’est moins rigolo (updated)

Tags: , ,
Add comments

02 / 08 / 2011 – Mise à jour il-ne-faut-pas utiliser lo0 comme interface pivot, il ne faut pas. Pour une raison que j’ignore totalement, aucun autre protocole qu’ICMP n’a jamais fonctionné pendant nos tests, si d’aucuns ont une explication rationelle, je suis toutes ouïes. Le problème est résolu en utilisant les interfaces physiques.

IPsec. À l’évocation de ce terme technique, vous avez avalé d’un trait votre Gin Tonic, vous éteignez votre écran en espérant qu’il s’agisse d’un mauvais rève et vous décrivez des cercles dans votre bureau en vous frappant la tête avec une règle metallique.
Je le sais, j’étais pareil.

Et puis, avec l’ami mat, nous avons lu, épluché, factorisé, testé, pesté, hurlé, et finalement, je vous propose un petite petite bafouille sur l’art de mettre en place un tunnel IPsec entre deux machines NetBSD. Ouais.

Il me semble que cette configuration est assez classique, jugez plutot: une passerelle, chez vous, disposant d’un bridge vers un réseau quelconque d’opérateur qui fournit une adresse IP fixe publique (si ce n’est pas le cas, vous savez ce qu’il vous reste à faire), et de l’autre coté, une machine dédiée dont vous disposez chez l’un des multiples hébergeurs low-cost aujourd’hui disponibles.
Petite particularité, cette dernière, dans mon cas, est une machine virtuelle NetBSD, un domU hebergé par un dom0 Debian/GNU Linux.

En raison de cette particularité, la première étape consiste à manipuler iptables afin de translater les differents protocoles nécessaires à IPsec directement vers ma machine virtuelle. Sur mon dom0, j’ajoute donc les règles suivantes:

# isakmp
-A PREROUTING -i eth0 -p udp -m udp --dport 500 -j DNAT --to-destination 192.168.2.1:500 
# isakmp + nat-t
-A PREROUTING -i eth0 -p udp -m udp --dport 4500 -j DNAT --to-destination 192.168.2.1:4500 
# protocole ESP
-A PREROUTING -i eth0 -p esp -j DNAT --to-destination 192.168.2.1 
# protocole AH
-A PREROUTING -i eth0 -p ah -j DNAT --to-destination 192.168.2.1 

Nous considérerons que l’IP publique de cette machine est 1.2.3.4, l’IP privée du domU est 192.168.2.1.

Le logiciel que nous utiliserons pour établir notre tunnel IPsec, d’un coté et de l’autre, sera le fâmeux racoon.

Je vous jette en pâture la configuration simplifiée que j’utilise, cette dernière étant expliquée point par point à cette adresse:

# cat /etc/racoon/racoon.conf
path pre_shared_key "/etc/racoon/psk.txt";

padding {
    maximum_length 20;
    randomize off;
    strict_check off;
    exclusive_tail off;
}

listen
{
    isakmp 192.168.2.1 [500];
}

remote anonymous
{
    exchange_mode aggressive;
    dpd_delay 20;

    weak_phase1_check on;

    proposal
    {
        encryption_algorithm 3des;
        hash_algorithm sha1;
        authentication_method pre_shared_key;
        dh_group 2;
    }
}

sainfo anonymous
{
    pfs_group 2;
    encryption_algorithm 3des;
    authentication_algorithm hmac_sha1;
    compression_algorithm deflate;
}

Notez que je fais écouter isakmp sur l’adresse privée du domU.
Il faudra créer le fichier /etc/racoon/psk.txt avec des droits stricts (0600), qui contiendra l’adresse IP du peer et une passphrase:

# cat /etc/racoon/psk.txt
5.6.7.8 unepassphrasedunfortbeaugabarit

5.6.7.8 étant l’IP publique de ma passerelle.
Coté passerelle, justement, nous créons l’exacte copie de cette configuration en remplaçant l’ip d’écoute de isakmp et l’ip publique présente dans le fichier /etc/racoon/psk.txt par l’IP publique de notre machine hébergée (1.2.3.4, donc).

Ceci étant fait, il faut maintenant indiquer au noyau pour quels sous-réseaux il est nécessaire de crypter le trafic IP. Cette indication est donnée via l’outil setkey, qui lira le fichier /etc/ipsec.conf sous NetBSD (nous y reviendrons). Un peu de concentration, voici son contenu sur la machine hébergée:

# on fait le ménage
flush;
spdflush;
# et on indique nos routes
spdadd 10.0.0.1/32 10.0.0.2/32  any -P out ipsec esp/tunnel/192.168.2.1-5.6.7.8/require;
spdadd 10.0.0.2/32 10.0.0.1/32 any -P in ipsec esp/tunnel/5.6.7.8-192.168.2.1/require;

Ici, 10.0.0.1 est le “réseau” (une IP unique dans mon cas) joignable à travers IPsec, via le tunnel établi entre l’IP privée de mon domU et l’IP publique de ma passerelle. De l’autre côté, le “réseau” est 10.0.0.2.
Afin de clarifier les choses, voici la configuration coté passerelle:

flush;
spdflush;
spdadd 10.0.0.2/32 10.0.0.1/32  any -P out ipsec esp/tunnel/5.6.7.8-1.2.3.4/require;
spdadd 10.0.0.1/32 10.0.0.2/32 any -P in ipsec esp/tunnel/1.2.3.4-5.6.7.8/require;

Miroir miroir, c’est suykidikihé, on observe que la configuration est l’exacte symétrie de celle présente sur la machine hébergée à cette difference près que notre passerelle s’adresse à une IP publique, le dom0, de l’autre coté, s’occuppe de translater tout ce merdier en IP privée.
Ça va, vous suivez toujours ?
Il ne reste qu’une opération à mener pour que ces réseaux se voient: router effectivement ces divers réseaux entre eux; mais voila, pour l’instant les IPs endpoint du tunnel IPsec n’existent pas, et pour pallier à cela, nous allons une fois de plus abuser de l’ami loopback nous allons utiliser des alias sur les interfaces physiques (virtuelles dans le cas du domU) . Par exemple, sur notre domU:

# ifconfig xennet0 alias 10.0.0.1 netmask 255.255.255.255

Et sur notre passerelle:

# ifconfig sip0 alias 10.0.0.2 netmask 255.255.255.255

Reste à effectivement router ces “réseaux” entre eux, par exemple sur la passerelle:

# route add -host 10.0.0.1 10.0.0.2

Avant d’automatiser tout ce petit monde, vous pouvez d’ores et déjà réaliser quelques tests “live”. Chargez d’abord vos règles SPD des deux côtés:

# setkey -f /etc/ipsec.conf

Puis démarrez racoon en mode debug + verbose, sans passer en tâche de fond:

# racoon -F -d -v -f /etc/racoon/racoon.conf

Une fois satisfaits, nous allons pouvoir automatiser ces opérations afin qu’elles soient prises en compte à chaque boot. Non, nous n’allons pas écrire un script à la con.
Tout d’abord, nous préparons nos interfaces d’alias à l’aide du fichier /etc/ifaliases, sur notre machine hebergée par exemple:

# cat /etc/ifaliases
10.0.0.1 xennet0 255.255.255.255

Puis nous mettons en place les routes statiques:

# cat /etc/route.conf 
host 10.0.0.2 10.0.0.1

Enfin, nous indiquons à rc qu’il devra charger la base SPD et démarrer racoon à l’aide du fichier /etc/rc.conf:

ipsec=YES
racoon=YES

Et nous y voila, une connectique sûre, standard et bidirectionelle en un tournemain.

En terme de latence, ça donne ça:
Sans IPsec

64 bytes from 1.2.3.4: icmp_seq=0 ttl=52 time=21.770 ms

Avec IPsec

64 bytes from 10.0.0.1: icmp_seq=0 ttl=255 time=21.869 ms

Tranquille hein.

Je vous livre en sus les quelques liens qui nous ont aidé à peaufiner notre configuration:

  • http://www.kame.net/newsletter/20001119/
  • http://www.netbsd.org/docs/network/ipsec/
  • http://www.netbsd.org/docs/network/ipsec/rasvpn.html
  • http://wtf.hijacked.us/wiki/index.php/IPSEC-Racoon
  • http://www.mad-hacking.net/documentation/linux/networking/ipsec/nat-vpn.xml
  • http://www.lacave.net/~fred/racoon/config.html

Et vous souhaite une bonne nuit.

4 Responses to “Y’a plus simple mais c’est moins rigolo (updated)”

  1. Emile “iMil” Heitor ‘s home » Blog Archive » Mais tu tu t’ennuies dans la vie en fait ? Says:

    [...] [...]

  2. Vanhu Says:

    Boooouuuuuuuuhhhhhhhhh !!!

    Le mode aggressif, c’est le mal !!!!

    Et comme t’as l’air d’avoir des IPs fixes, y’a aucune raison technique, en plus…..

    Ensuite, on rediscutera de l’usage abusif et présentement inutile du “anonymous” :-)

  3. iMil Says:

    @Vanhu tu peux élaborer un peu en prenant connaissance de l’objectif de cette architecture ? (1 post plus haut)

  4. Vanhu Says:

    http://www.ernw.de/download/pskattack.pdf (premier que j’ai trouvé en faisant une rapide recherche google) t’expliquera pourquoi le mode aggressif c’est le mal.

    Dans la vraie vie, le seul cas ou le mode aggressif peut se “justifier”, c’est quand tu fais du roadwarrior (une passerelle, et un “truc qui a une IP pas fixe”) en PSK.
    Enfin, même la, ca se justifie pas tant que ca, y’a d’autres solutions (certificats ou authentification hybride+Xauth, par exemple).

    Dans ton cas, vu que les 2 correspondants ont l’air d’avoir une IP fixe, il suffit juste de changer le mode dans les racoon.conf (“main” au lieu de “aggressive”).

    T’auras même pas à changer les identités des correspondants de tes PSKs, puisque tu utilises déjà une identité de type IP, d’après le fichier psk et l’absence de “my_identity” dans le racoon.conf.

    Et à propos du “anonymous”, vu que t’as des IPs fixes, toujours, tu peux remplacer “remote anonymous” par “remote x.y.z.t” (l’IP de ton correspondant), comme ca t’es sur que seule cette IP la peut tenter une négociation avec toi, ca évite d’autres tentatives d’attaques par bruteforce (enfin, sauf pour quelqu’un qui connait l’IP de ton correspondant et qui sait la spoofer, mais c’est pas censé être tout le monde).

    Note: vu qu’il y a du NAT, faut toujours considérer l’IP qu’on voit du correspondant, pas forcément son IP réelle…..

    Ah, et c’est souvent limite plus simple d’utiliser le NAT-T, pour traverser du NAT, quoique dans ton cas de figure ca changera probablement pas grand chose.

Leave a Reply

WP Theme & Icons based on GlossyBlue by N.Design Studio
Banner from www.trynthlas.com
Entries RSS Comments RSS Log in
Optimization WordPress Plugins & Solutions by W3 EDGE