Journal Identifier un réseau

Posté par  . Licence CC By‑SA.
Étiquettes :
12
18
nov.
2011

Bonjour à tous !

Les VPNs, c'est vraiment super pratique. Surtout quand on est étudiant et qu'on vadrouille de réseaux en réseaux dans lesquels on a pas confiance. Alors déja je vais essayer d'attiser votre paranoïa pour que je me sente moins seul dans mon délire, et ensuite je vais vous parler de ce que j'utilise en solution de VPN, et enfin je finirais par poser une petite question pour pouvoir améliorer ma petite infrastructure. Pour conclure, je vous proposerez des jolis NVidéos, mais ça c'est si vous êtes sages.

Bon, c'est parti ! Comme j'aime bien raconter ma vie, je suis étudiant, dans une école d'informatique, et je loge dans une chambre universitaire.

Dans les chambres universitaires, il n'y a pas de prises téléphoniques (pas dans la mienne en tous cas), donc impossible d'avoir une connexion à Internet. Mais comme au Crous ils sont sympas, ils nous mettent à disposition un réseau wifi nous permettant d'avoir accès à Internet. Ok, alors techniquement, c'est un wifi ouvert où tout le monde peut se connecter. Sur ce wifi qui se trouve être un réseau privé, se trouve un serveur proxy (et DNS) HTTP et HTTPS (je crois que c'est du SQUID derrière) sur authentification (avec mots de passes envoyés en clair). Ok donc alors, tout accès à un site web est logué par ce proxy, c'est écrit dans la chartre (et supprimé au bout de quelques mois ou un an me semble il). Déja, ça c'est pas terrible, mais moi ce qui me pose vraiment problème c'est quand même que ... euh, réseau wifi ouvert quoi ! Tout le monde peut lancer airodump-ng et regarder TOUT ce qui se passe. Vous vous loguez à un site web en HTTP ? Toute la résidence est suceptible de le savoir, et de connaître vos identifiants par la même occasion (ou toute autre donnée sensible qui peut transiter dans ces pages web).
Amis défenseurs du HTTP sans chiffrement parce que sinon ça consomme plus, n'oubliez pas de penser à ceux qui ont un réseau tout pourri ;-) (mais je comprends votre point de vue). La solution serait de n'aller que sur des sites en HTTPS ... Mais c'est pas forcément toujours possible.
En plus, notre seul canal de communication avec l'extérieur, c'est via du HTTP, mais comme Internet ne se résume pas au Web, et que j'aimerais bien pouvoir aller sur Jabber et me connecter en ssh quand je suis chez moi, ben je me sens assez vite limité.

À mon école, c'est un peu mieux. Pas de proxy obligatoire (pour l'instant), par contre, interdiction de communiquer via UDP vers l'extérieur, et seuls quelques ports TCP d'une liste blanche sont autorisés (mais ils suffisent pour la plupart des usages). Par contre, quand je suis connecté en wifi (oui, on a des prises ethernet dans chaque salle de cours, mais pour une question de mobilité, des fois, le wifi ça peut vraiment être pratique), j'ai un peu peur. Non, ici, le wifi n'est pas non sécurisé (double négation, youpee) puisqu'il est sécurisé via WPA. Ah, euh, WPA seulement ? Ça ne me dérangerait pas ... Si j'étais le seul à connaître la clef ! Sauf que là, toute l'école la connaît la clef ! Du coup, il existe un gros problème de sécurité, en effet, en WPA, si on connaît la clef et que l'on a réussi à capturer un handshake (les messages qui sont échangés lors d'une connexion). Et c'est vraiment pas dur, il suffit d'arriver avant tout le monde ou d'envoyer des demandes de déauthentification avec aireplay-ng.
Évidemment, même en cablé, on est pas à l'abri d'attaques genre arp spoofing.

Accessoirement, il peut toujours arriver de se connecter à des réseaux un peu douteux (macdo, hôtels, hotspot, ...).

Pour cela, avoir un serveur distant avec un accès VPN permet de créer un tunnel sécurisé entre moi et le serveur me permet de ne pas avoir à réfléchir en permanence à la question "est ce grave si quelqu'un voit ce qui transite sur le réseau ?". Des VPNs, il y en a plein. Moi, j'en ai testé deux (eh oui, depuis 2 ans que je dépends de ce genre de bidouilles, j'ai eu le temps d'améliorer le bouzin). Le premier que j'ai testé : OpenVPN. Simple à mettre en place, avec des dizaines de HowTo au mètre carré, c'est un logiciel de VPN assez puissant permettant de faire un réseau de pas mal de personnes. C'est plutôt sympa, basé sur un système de certificats pour se connecter. Mais j'ai un gros problème avec, et je ne dois pas être le seul, sous Linux. Faire une requête DNS peut prendre plusieurs secondes ! Je n'ai jamais compris d'où ça venait, et ça fait pas mal de temps que l'on dit qu'on (moi et un mec dans ma classe) qu'on va essayer de se prendre une après midi pour enquêter, mais on l'a encore jamais fait. Romain : faudrait d'ailleurs, je suis curieux !

Actuellement, j'utilise vtun et je remercie Yoann de me l'avoir fait découvrir. http://vtun.sourceforge.net/ Plus maintenu depuis plusieurs années, Vtun est un super logiciel de VPN avec lequel on peut tout faire et avec des performances vraiment super qui me convienne parfaitement. Il est dans les dépots debian / ubuntu. Il m'a fallu une petite soirée pour bien comprendre comment il se configurait, mais ça valait le coup. Pour le configurer, regardez du coté des fichiers de configuration d'exemple et de la documentation du site officiel. J'avais aussi trouvé un article de blog qui expliquait ça plutôt bien.
Par contre, par rapport à openVPN, vtun est rustre. Lui, il s'occupe juste de faire un lien entre nous et le serveur, c'est à nous de définir le serveur distant comme notre passerelle par défaut, et à nous de ne pas oublier de rajouter une route vers ce serveur sans quoi votre accès à Internet risque d'être plutôt inexistant. OpenVPN lui, s'occupe de tout automatiquement.

Pour me connecter en passant par un proxy HTTPS, j'utilise proxytunnel, un petit logiciel bien sympa qui marche impeccablement bien (ah, et mon VPN écoute sur le port 443 sinon ça ne va pas).
Du coup, aujourd'hui, j'ai un système de scripts : je lance le script correspondant à ma chambre ou à mon école selon là où je suis. Seulement voilà, j'aimerais un truc un peu plus automatique : un script qui se lance automatiquement quand je me connecte quelque part (avec mon petit network-manager) et qui détermine quel script doit être lancé : comme ça j'ai rien d'autre à faire. Mais du coup, il faut que mon ordinateur devine sur quel réseau il est. Alors, à votre avis, comment on peut faire ça facilement ? (Eh oui, en fait ce journal aurait plus sa place dans les forums !) Quels sont les caractéristiques d'un réseau ? Moi j'ai le réseau et le netmask, l'IP des serveurs DNS donnés par le serveur DHCP. Je ne peux pas me baser sur la gateway par défaut puisqu'elle peut changer quand je suis à mon école, selon la salle. Des idées ?

Si tout cela ne vous intéresse pas, je vous invite à regarder de jolies NVidéos.

  • # Preums !

    Posté par  (Mastodon) . Évalué à 5.

    Faire une requête DNS peut prendre plusieurs secondes !

    Une solution de contournement : dnsmasq

  • # requête DNS

    Posté par  . Évalué à 9.

    Faire une requête DNS peut prendre plusieurs secondes !

    Ca sent l'ipv6?

    Ceci dit, moi j'utilise ssh. ssh -D pour avoir un socks, et au besoin, ssh -w pour monter un vrai tunnel VPN. Par contre, le ssh -w pète quelquefois lorsque le wifi est vraiment mauvais. L'avantage de ssh, c'est que je n'ai plus à me soucier du réseau sur lequel je me trouve.

    • [^] # Re: requête DNS

      Posté par  . Évalué à 3.

      Ça sent plutôt le resolv.conf pas mis à jour.

      Typiquement:
      - tu es sur sur 10.42.0.0/24
      - tes/tes resolvers sont sur 10.42.1.0/24
      - et ton VPN te met une route par défaut via ton endpoint qui sait pas joindre 10.42.1.0/24 (ou les resolvers refusent de répondre vu que c'est une requete exterieur).
      - du coup, ça timeout, ça prend des plombes, je comprends même pas comment ça peut marcher sauf si tu as un 8.8.8.8 ou autre à la fin.

      • [^] # Re: requête DNS

        Posté par  . Évalué à 3.

        Pour l'IPv6, c'est pas idiot comme piste, même si ça me parraît un peu bizarre, j'essaierais un peu de faire des tests dans cette direction.

        Par contre, pour le serveur DNS, il était joignable ! Je précisais un serveur DNS adapté.

  • # ConnMan

    Posté par  . Évalué à 2.

    Il semblerait que ce soit l'objectif de ConnMan:

    http://lwn.net/Articles/456967/

    It should be automated so that it didn't have to ask the user what to do "over and over again if we knew what to do".

    "Are we on the internet?" is a surprisingly hard question to answer as the system could be connected to a hotspot that requires a login for example.

    La description est alléchante. Être capable de s'adapter à chaque réseau, peut-être remplir automatiquement les champs des formulaires de proxys captifs...

    Pour la pratique, j'ai fais un rapide test sur mon Ubuntu LTS (10.4 je pense) avec le paquet de la distribution; et je me suis retrouvé incapable de me connecter à un réseau Wifi WPA. Au bout d'une dizaine de minute, n'ayant pas trop le temps de tester à ce moment là, j'ai fais un retour arrière. Je ne pense pas qu'il faille considérer cela comme un test significatif.

    C'est un système qui a l'air très intéressant, reste à voir si les objectifs que s'est fixé l'auteur sont atteints.

  • # /etc/dhcpcd.exit-hook

    Posté par  . Évalué à 8.

    Mais du coup, il faut que mon ordinateur devine sur quel réseau il est. Alors, à votre avis, comment on peut faire ça facilement ?

    J’utilise /etc/dhcpcd.exit-hook pour ça (cf. dhcpcd-run-hooks(8) pour les détails).

    Tous les réseaux auxquels je suis amené à me connecter ont un serveur DHCP, et ces serveurs envoient généralement, en même temps que l’adresse IP allouée, plus ou moins d’informations permettant la plupart du temps d’identifier assez certainement le réseau sur lequel je me trouve.

    Ça donne à peu près ça :

    if [ x$reason = xBOUND ]; then
    case "$new_domain_name" in
        ujf.grenoble.fr)
            # réseau de l’université Grenoble I
            ;;
        fleming.local)
            # réseau de l’Institut Fleming
            ;;
        ici.local)
            # un autre réseau ici
            ;;
        ailleurs.internal)
            # un autre réseau ailleurs
            ;;
        *)
            # réseau inconnu
            ;;   
    esac
fi

    Ici, new_domain_name est le nom de domaine par défaut indiqué par le serveur DHCP. C’est je pense l’option la plus simple pour identifier le réseau auquel on vient de se connecter (malheureusement tous les serveurs DHCP ne renvoient pas nécessairement cette information — elle est optionnelle, d’après la RFC 2132, §3.17). Les autres informations possiblement utilisables, à défaut, incluent l’adresse du serveur DHCP qui vient de répondre (new_dhcp_server_identifier), l’adresse des serveurs DNS (new_domain_name_servers), le SSID dans le cas d’une connexion Wi-Fi (new_ssid), la passerelle (new_routers), etc…

    • [^] # Re: /etc/dhcpcd.exit-hook

      Posté par  . Évalué à 2.

      Je doute du respect de ce genre de normes par la plupart des réseaux sales qu'on croise. Des gens capables de bloquer du trafic selon le numéro de port ou d'imposer un proxy transparent n'en ont rien à foutre des RFC..

      Y'a aussi une RFC qui permet au serveur DHCP de préciser un serveur SMTP sortant, j'ai jamais vu le moindre serveur DHCP la proposer (ni, d'ailleurs, de client mail qui la prenne en compte).

      THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

      • [^] # Re: /etc/dhcpcd.exit-hook

        Posté par  . Évalué à 5.

        Je ne vois absolument pas le rapport entre le fait de bloquer du trafic sur des numéros de ports et le respect des RFC.

  • # SSID / MAC

    Posté par  . Évalué à 2.

    Tu pourrais te baser sur le SSID ou l'adresse MAC du point d'acces wifi.

  • # /etc/network/if-up.d/

    Posté par  (site web personnel) . Évalué à 2. Dernière modification le 18 novembre 2011 à 19:40.

    Tu peux te créer un script dans le /etc/network/if-up.d/ : Les scripts qui sont placés ici sont lancés lorsque network-manager a fait redémarrer un interface réseau (lo, eth0, wlan0, ...).

    Des variables globales sont disponibles (IFACE LOGICAL ADDRFAM METHOD VERBOSITY), et tu peux les utiliser.

    Le petit script ci-dessous permet d'avoir une trace de ces appels lorsque network-manager effectue un changement réseau :

    #!/bin/bash -norc
TRACE_FILE=/tmp/NetworkManager.log
(echo -ne `date "+%Y-%m-%d_%X"` \'$0\' ; for I in IFACE LOGICAL ADDRFAM METHOD VERBOSITY; do echo -ne " [$I=$(eval echo $`echo $I`)]"; done ; echo )>> $TRACE_FILE

    Enfin, tu peux aussi extraire des informations de ton système, afin de pouvoir identifier ton réseau. Exemples:
    NETWORK_NAME=`sed -e '/^domain/!d' -e 's/^domain *//g' /etc/resolv.conf`
GATEWAY=`LANG=C /sbin/route -n|sed -e '/^0\.0\.0\.0/!d' -e 's/^[^ ]\+ \+\([^ ]\+\).*/\1/g'`

    • [^] # Re: /etc/network/if-up.d/

      Posté par  (site web personnel) . Évalué à 1.

      /etc/network est une spécificitée Debian, NetworkManager utilise de lui-même les dispatcher dans /etc/NetworkManager/dispatcher.d:
      Il y a 4 actions (up, vpn-up, down, vpn-down) mais je n'ai pas encore explorer plus loin ...

  • # ssh

    Posté par  . Évalué à 3.

    Personnellement quand je rencontre ce genre de problème, je crée un tunnel ssh avec mon serveur

    ssh -D 12345 toi@toi.com
export http_proxy="127.0.0.1:12345"

    C'est pas autant bien qu'un vpn (enfin, je crois, je suis pas sûr), mais ça fait son job...

    • [^] # Re: ssh

      Posté par  . Évalué à 5.

      Je suis surpris.. -D crée un proxy socks (je m'en sers très souvent), pas un "http_proxy".

      Ou alors, SSH détecte du trafic de type "je passe par un proxy HTTP" et s'adapte silencieusement?

      THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

  • # IP publique ?

    Posté par  (site web personnel) . Évalué à 0.

    En regardant avec quelle IP tu sorts sur Internet, ça devrait le faire non ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.