NAVIGATION : INDEX DU FORUM / ACCUEIL DE P2PFR / WIKI

Merci de faire une recherche avant de poster :)

Nous sommes actuellement le 28 Mars 2024 22:57

Heures au format UTC + 1 heure [ Heure d’été ]




Publier une réponse
Nom d’utilisateur:
Sujet:
Corps du message:
Saisissez votre message ici. Il ne doit pas contenir plus de 60000 caractères. 

Émoticônes
O_o :D :O ;) 8) :p :[ >( :o :s :( :o :-o :roll: :x :p2pfr: :bisous: :oops: :cry: :evil: :makeadeal: :pleure: :french: :help: :miam: :vomi: :sniper: :spit: :teleport: :wobble: :ass: :dispute: :fume: :google: :aime: :boire: :coucou: :diable:
Voir plus d’émoticônes
Taille de la police:
Couleur de la police
Options:
Le BBCode est activé
[img] est activé
[flash] est activé
[url] est activé
Les émoticônes sont activées
Désactiver le BBCode
Désactiver les émoticônes
Ne pas compléter automatiquement les liens
Question
Écrivez "humain" puis ajoutez le symbole 挧 après la lettre 'h'.:
Cette question est un moyen d’identification et de prévention contre les actions automatisées.
   

Aperçu du sujet - Du p2p derrière un routeur dont on n'a pas le contrôle
Auteur Message
  Sujet du message:   Répondre en citant
Pour ton premier problème, fallait créer un répertoire keys dans C:\Program Files\OpenVPN\easy-rsa

pour le second : tu choisis un nom à donner à ton serveur (disons MonServeur), et un nom à donner à chacun des clients (NomClient1, NomClient2, etc...)

À chaque fois qu'il te demande le nom du serveur, tu mets 'Mon serveur" et tu génères une paire de clef par client, et pour chaque client, ben tu mets le nom du client (NomClient 1 ou NomClient2 ou NomClient3...)

Le serveur, c'est l'ordinateur qui est à l'extérieur du routeur, celui qui va servir d'intermédiaire entre les clients et le reste du net. Les clients, c'est les autres ordis, celui derrière un routeur et d'autres éventuels.
Message Publié: 14 Nov 2006 08:50
  Sujet du message:   Répondre en citant
Ok, ca y est apres plusieurs tentatives, j'ai réussit a génerer le certificat d'autorité, mais je me pose une question, a qui correspondent les réferences du serveur et du client? que dois-je y mettre comme réponse??? aidez-moi svp je suis perdu...

merci bcp
Message Publié: 14 Nov 2006 00:12
  Sujet du message:  Petit problem... J'suis nul...  Répondre en citant
Bonsoir, voila mon probleme: lorsque je tentes de "sourcer var et de tout netoyer" il ne se passe rien, et lorsque j'essay de denerer le certificat d'autorité voila ce qu'il se passe:

C:\Program Files\OpenVPN\easy-rsa>build-ca.bat
Loading 'screen' into random state - done
Generating a 1024 bit RSA private key
...........++++++
..........++++++
writing new private key to 'keys\ca.key'
keys\ca.key: No such file or directory
2948:error:02001003:system library:fopen:No such process:.\crypto\bio\bss_file.c
:278:fopen('keys\ca.key','wb')
2948:error:20074002:BIO routines:FILE_CTRL:system lib:.\crypto\bio\bss_file.c:28
0:

Que faire... merci
Message Publié: 13 Nov 2006 23:46
  Sujet du message:   Répondre en citant
Qu'est-ce qu'il te manque ?
Message Publié: 13 Nov 2006 23:21
  Sujet du message:  Bon début  Répondre en citant
Salut a tous, etant étudiant, voila plusieurs jours que je cherches la réponse a ce topic en vain, et voici qu'elle apparait comme par miracle... mais elle n'est pas complète... Sniff, sniff

En tout cas c'est un bon début, on attend la suite avec impatience...
Message Publié: 13 Nov 2006 23:14
  Sujet du message:   Répondre en citant
L'attaque de l'homme du milieu marche contre diffie-hellman. D'où la combinaison de deux techniques, diffie-hellman+les certificats : l'homme du milieu peut tromper diffie-hellman, mais il n'a pas les éléments non diffusés pour l'authentification par clef publique. Enfin, de toute façon, le proxy qui va réaliser ce genre d'attaque pour décoder des flux SSL et vérifier que c'est bien du http qui passe, à mon avis, il est pas né. T'imagine les ressources qu'il faudrait, sur un proxy d'entreprise, pour vérifier la légitimité de toutes les connexions https ?
Message Publié: 09 Nov 2006 19:15
  Sujet du message:   Répondre en citant
Citer:
4 - Pourquoi il ne voit pas ? Parce que la seule façon pour lui de savoir serait de bénéficier des clefs, or la combinaison des certificats de sécurité et du protocole Diffie-Hellman est absolument incrackable en l'état actuel de nos connaissances mathématiques (un problème de logarithme discret, voir mon lien ci-dessus). Il ne peut donc jouer à l'homme du milieu.

L'attaque de l'homme du milieu elle marche toujours, l'algo en question n'est pas inattaquable ... faut un moyen supplémentaire pour s'en prémunir. (revoir le lien que tu as donné)
Message Publié: 09 Nov 2006 16:30
  Sujet du message:   Répondre en citant
tu shunte pas le proxy :

1 - tu mets en place un serveur OpenVNC tournant sur le port 443.

2 - Or OpenVNC, dans son mode par défaut, utilise SSL pour créer la connexion sécurisée

3 - Tu dis au client de passer par le proxy pour se connecter au serveur.

4 - Donc que voit le proxy : une demande de connexion vers une adresse IP, port 443. C'est autorisé (sauf si le proxy interdit les connexions vers https, mais ça, j'en connais pas). Suit un handshake SSL, toujours normal. À partir de là, les échanges sont cryptés, donc le proxy ne voit plus ce qui se passe.

4 - Pourquoi il ne voit pas ? Parce que la seule façon pour lui de savoir serait de bénéficier des clefs, or la combinaison des certificats de sécurité et du protocole Diffie-Hellman est absolument incrackable en l'état actuel de nos connaissances mathématiques (un problème de logarithme discret, voir mon lien ci-dessus). Il ne peut donc jouer à l'homme du milieu.

En conclusion, tu fais passer par le proxy exactement ce qu'il est fait pour faire passer...

Tu préfères Taillevent, Ledoyen ou l'Arpège ?
Message Publié: 09 Nov 2006 09:01
  Sujet du message:  Proxy  Répondre en citant
Bonjour, mon cher Suger

Je lis tes posts et tu dis qu'il est possible de shunter le proxy de '' ta boîte " . Si tu arrives à passer les sécurités des admins de la mienne = je te paye un super resto. :D :-D
Message Publié: 08 Nov 2006 16:34
  Sujet du message:   Répondre en citant
Ben ouais, je suis un obstiné, moi.

Y a encore deux défauts : le postrouting sous Windows (je suis sûr qu'en cherchant un peu, je peux trouver, mais j'ai la flemme pour le moment) et le titre : je le trouve pas terrible. Quelqu'un a une idée ?
Message Publié: 07 Nov 2006 18:37
  Sujet du message:   Répondre en citant
Voilà qui semble répondre à un certain post
Message Publié: 07 Nov 2006 18:14
  Sujet du message:  Du p2p derrière un routeur dont on n'a pas le contrôle  Répondre en citant
Introduction

Régulièrement, certains d'entre nous s'interrogent : est-il possible d'utiliser son p2p favori au travail, dans sa résidence universitaire ou chez ses parents, en tout cas quelque part où l'on n'a pas le contrôle sur le routeur/pare-feu.

La réponse qui est en général faite est "c'est compliqué et pas très intéressant", sans plus de détail. Cela dit, pour l'édification de tous, je vais ici présenter ce qui est, à mon avis, la meilleure méthode pour y parvenir. C'est assez long, donc je vais poster en plusieurs fois, soyez patients :)

Avertissements

1 - Où que vous soyez, vérifiez que l'utilisation du p2p n'est pas interdite.
2 - Tout particulièrement si vous êtes au travail ou dans un cadre universitaire, ne téléchargez pas de contenu protégé par des lois sur le droit d'auteur. Si vous le faites, vous risquez non seulement les peines prévues par la loi, mais aussi de vous faire virer... Ne rigolez pas, il existe des utilisations légales du p2p : la version Windaube de mon économisateur d'écran préféré ( http://www.electricsheep.org ) diffuse ses économisateurs d'écran via BT, par exemple
3 - C'est possible. Ça ne veut pas dire que c'est intéressant. Voir ci-après le matériel requis et la présentation théorique de la méthode : vous allez gâcher beaucoup de bande passante

Matériel requis

Pour pouvoir faire du p2p derrière ce qu'il est convenu d'appeler un "parefeu fasciste", il vous faut :

1 - chercher à télécharger des données via du p2p derrière un parefeu n'autorisant que certaines connexions précises (sinon, c'est pas drôle).

2 - Un ordinateur derrière ce parefeu sur lequel vous avez le droit d'installer des programmes (Si vous n'avez pas ce droit et que vous êtes sous Window$, il y a plein de façon de l'obtenir, cherchez un peu. Si vous êtes sous *nix, c'est un peu plus compliqué, mais pas impossible, du moment que vous avez un accès physique à la machine. Le plus simple, dans ce dernier cas, c'est d'installer dans ~/bin et de modifier $PATH dans son .bashrc ou .cshrc, suivant les cas. Sinon, il y a toujours la possibilité de trifouiller /etc/sudoers, mais ça, c'est pas bien).

3 - C'est là que ça se complique : un ordinateur à l'extérieur de ce parefeu, connecté à internet soit directement (ce qui n'est pas bien) soit derrière un parefeu dont vous avez le contrôle.

Un peu de théorie

Un parefeu fasciste est un parefeu qui contrôle non seulement les connexions entrantes mais aussi les connexions sortantes, n'en autorisant que certaines, à savoir au moins vers les ports 80 et 443 (http et https), parfois aussi vers les ports 21 (ftp), 25 (smtp) et 110 (pop), voire 22 (ssh). Un tel parefeu ne fait que procurer une sécurité totalement illusoire aux sysadmins (Messieurs administrateurs réseaux qui me liraient éventuellement : il y a longtemps que même les pire hackers ont compris les principes que je vais exposer ici. Si vous voulez vraiment contrôler votre réseau, la bonne solution, à mon sens, est de bloquer toutes les communications vers l'extérieur et d'avoir un serveur en DMZ qui serve non seulement de relais pour votre messagerie et autres services utilisés par vos utilisateurs, mais également où soit installés leurs navigateurs, qu'ils font tourner en remote. Passons...).

La solution à utiliser est simple en théorie, mais je m'y suis pourtant longtemps cassé les dents : pour utiliser n'importe quel service, on utilise une machine extérieure relais, vers laquelle on ouvre un tunnel http, on encrypte les données transférées, et c'est parti.

Pour ouvrir le tunnel, il y a plein de petits programmes, proxytunnel, http_tunnel, corkscrew, etc. Pour transmettre des données de façon cryptée, le meilleur programme sur le marché est OpenSSH (ssh pour secure shell), qui permet, notamment, de transmettre les données arrivant sur un port donné de la machine relais vers un port donné de la machine interne et vice-versa.

Donc, pendant longtemps, j'ai cru que la solution était là, et elle marche en effet pour pratiquement tous les services internet, d'http à irc en passant par pop, smtp et les autres : faire suivre un port externe, sur la machine relais, vers la machine bloquée et, en retour, faire suivre un port sur la machine interne vers la machine relais.

Le problème est que cela ne marche ni avec FTP, ni avec les programmes de p2p qui tous (à l'exception, semble-t-il, de utorrent) utilisent des ports aléatoires pour les connexions sortantes.

La solution est donc ailleurs : au lieu de faire suivre les connexions sortantes port par port, il faut que toutes les connexions sortantes aillent vers la machine relais, autrement dit trouver le moyen de mettre ces deux machines sur un pseudo réseau local.

Et c'est tout à fait possible : ça s'appelle un réseau privé virtuel (virtual private network, ou VPN), et il y a un excellent couple client/serveur libre, openvpn ( http://www.openvpn.org ) que nous allons donc utiliser pour parvenir à nos fins.

Vous aurez cependant immédiatement compris les deux bémols à apporter à la merveilleuse méthode que je vais vous développer dans les jours suivants :

1 - Si on a le contrôle d'une machine extérieure, pourquoi s'obstiner à faire du p2p sur sa machine interne ? A part le cas d'electricsheep que j'ai évoqué plus tôt, je pense personnellement que ça n'a strictement aucun intérêt, surtout que

2 - La machine relais va devoir utiliser sa bande passante pour recevoir les données et vous les faire parvenir, mais également pour renvoyer les données que vous lui enverrez, ce qui veut dire, en gros, que vous ne pouvez, au mieux, qu'espérer un débit de téléchargement égal à la moitié de votre bande passante montante. Autrement dit, si votre machine est seule sur une connexion ADSL2 optimale (20 Mb/s en descente, 1Mb/s en montant) vous aurez des performances équivalentes à du 512 kb/s, et encore, si votre machine interne a accès à 512kb/s de bande passante montante et descendante). Dans la pratique, il faut compter sur l'équivalent d'une connexion simétrique 128/128.

I - Mettre en place un VPN : le serveur

Pour les anglophones, il y a un très bon HOWTO là : http://openvpn.net/howto.html

Nous allons mettre en place un vpn dynamique routé. Première étape : installez OpenVPN 2 sur l'ordinateur externe, soit via votre gestionnaire de paquet, soit en téléchargeant la source ou l'exécutable Windows là : http://openvpn.net/download.html

1 - Choisir une plage d'adresse pour votre VPN.

Comme tout réseau local, votre VPN va devoir avoir une plage d'adresse. Vous pouvez choisir dans 10/8, 172.16/12 et 192.168/16 (les trois plages réservées pour les réseaux privés). D'expérience, c'est dans 10/8 qu'il y a le moins de chances de confilits avec d'autres réseaux, notamment si l'un des ordinateurs de votre VPN est un portable qui risque d'être utilisé dans des hôtels. On va prendre, par exemple, 10.8.5/24 (10.8.5.1 à 10.8.5.254), mais vous êtes libres du choix de votre plage, évidemment.

2 - Générer les clefs
La première étape va être de générer les clefs utilisées pour l'authentification, soit une paire de clefs publique/privée pour le serveur et chaque client, et un certificat d'autorité pour le serveur, qui signera chacune des clefs.

Si vous êtes sous Windows, ouvrez une fenêtre d'invite de commande et faites
Code:
cd \Program Files\OpenVPN\easy-rsa
init-config


Sous *nix,
Code:
cp /usr/share/doc/openvpn/easy-rsa/2.0 /etc/openvpn
cd /etc/openvpn


Maintenant, il faut éditer le fichier vars (ou vars.bat sous Windows) et renseigner les champs importants, soit

KEY_COUNTRY (votre pays), KEY_PROVINCE (votre région), KEY_CITY (votre ville), KEY_ORG (normalement, le nom de la boîte, mettez ce que vous voulez) et KEY_EMAIL (votre email. Ce sont des données qui sont faites pour le certificat, pas pour être transmises à l'extérieur, donc pas d'inquiétude sur la vie privée). Personnellement, je change aussi KEY-SIZE en 2048 au lieu de 1024...

Prêts ? Alors on va générer les clefs. On commence par sourcer var et tout nettoyer

Code:
Sous Windows
vars
clean-all

Sous Linux
. ./vars
./clean-all


Puis on génère le certificat d'autorité

Code:
build-ca

ou

./build-ca


Toutes les réponses par défaut devraient être bonnes, sauf une, le "Common name". Entrez là le nom que vous voulez donner à votre serveur et retenez le.

Bien, maintenant, générons la paire de clefs du serveurs et des clients. C'est tout simple

Code:
build-key [Nom du serveur]
build-key [Nom du client]

ou

./build-key [Nom du serveur]
./build-key [Nom du client]



Reste à génèrer les paramètres pour le protocole Diffie-Hellman ( http://fr.wikipedia.org/wiki/Échange_de_clés_Diffie-Hellman )

Code:

build-dh

ou ./build-dh



Ensuite, installez openvpn sur les machines du futur réseau privé, mais ne générez pas de certificats. Sous Linux, en plus, il faut faire

Code:

mkdir /etc/openvpn



3 - Répartir les clefs

Plusieurs fichiers ont été générés. Voici comment les répartir :

ca.crt doit être dans le /etc/openvpn (ou le \Program Files\OpenVPN) du serveur et de tous les clients. Le serveur garde le fichier dh{n}.pem et les fichiers [Nom du serveur].crt et [Nom du serveur].key. Chacun des clients prend les fichiers [Nom du client].crt et [Nom du client].key.

4 - Configurer le serveur

Éditez le fichier de configuration par défaut du serveur.

Changez le port de 1194 en 443
changez

;proto tcp
proto udp

en

proto tcp
;proto udp

pointez ca, cert, key et dh vers les fichiers respectifs du serveur.

pour server, mettez (dans l'exemple choisi, pour 10.8.5/24) 10.8.5.0 255.255.255.0

décommentez la ligne push "redirect-gateway"
décommentez la lignes client-config-dir ccd

ensuite, créez un sous-dossier ccd. Dedans, mettez un fichier par client portant le nom [Nom du client] dans lequel vous mettez une seule ligne

Code:
ifconfig-push IPquevoussouhaitezdonnerauclient IPquevoussouhaitezdonnerauclient+1
.

Voilà, vous n'avez plus qu'à taper

Code:
openvpn [fichier de configuration]


et voir si tout démarre normalement. Si oui, créez la règle de NAT pour envoyer les paquets arrivant du VPN vers le reste du monde.

En supposant que la route par défaut soit sur l'interface eth0, les règles sont les suivantes

Code:
iptables

iptables -t nat -A POSTROUTING -s 10.8.5.0/255.255.255.0 -o eth0 -j MASQUERADE

pf

nat on eth0 from 10.8.5.0/24 to any -> eth0

Window$
Si quelqu'un connaît le bon réglage de NAT pour un serveur OpenVPN sous Window$, je suis preneur


routez les ports utilisez par vos logiciels de p2p vers l'adresse que vous avez assignée à votre ordinateur derrière le parefeu. Exemple ici pour BT sur le port 6881 redirigé vers 10.8.5.2

Code:

iptables

iptables -t nat -A PREROUTING -p tcp --dport 6881 -j DNAT --to-destination 10.8.5.2:6881

pf

rdr on eth0 proto tcp from any to any port 6881 -> 10.8.5.2



Pour Window$, voir http://forum.p2pfr.com/ftopic15822.html

Routez le port 443 et le port 6881 (dans mon exemple) vers cet ordinateur et il est temps de passer au client

II - Mettre en place un VPN : le client

Là, c'est tout simple

Vous éditez le fichier de configuration client ( client.conf sur *nix, client.openvpn sur Windows) en pointant cert, key et ca au bon endroit, vous pointez remote sur votre machine distante (soit en utilisant son IP si vous avez une IP fixe, soit avec un dynDNS), vous réglez dev sur tun et proto sur tcp, et vous y êtes presque.

La seule chose à faire est d'ajouter une ligne http-proxy du type

http-proxy 192.168.0.1 8080

et c'est parti.

Conclusion

Voilà, vous pouvez faire du p2p derrière un parefeu fasciste, mais à mon avis, ce n'est pas très productif. Il vaut mieux faire tourner le logiciel de p2p sur la machine relais et récupèrer via le VPN les fichiers une fois téléchargés.

Vous pouvez aller boire une aspirine à ma santé.
Message Publié: 06 Nov 2006 10:59

Heures au format UTC + 1 heure [ Heure d’été ]


Aller vers:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Traduction réalisée par Maël Soucaze © 2010 phpBB.fr