Firewall Piercing (2)
Mardi 5 juillet 2005 à 13 h 48
La partie précédente, publiée il y a longtemps, expliquait comment jouer sur le net depuis un réseau local où seuls quelques ports TCP sont directement ouverts sur le net. Certaines méthodes permettent d'obtenir un tel port, quand il n'est pas directement ouvert sur le Firewall. Bien sûr, vous prenez vos responsabilités, le mieux c'est quand même d'aller voir l'admin et de lui demander d'ouvrir un port spécifique, avec vos arguments tous prêts, si c'est pour jouer ça ne va pas gêner le reste du réseau. P2P vous pouvez toujours rêver. Attention, les actions suivantes sont très certainement en désaccord avec la charte d'utilisation que VOUS avez signée dans votre campus.
Il va falloir un peu de connaissance unix. Sur de nombreux réseaux universitaires, on trouve un serveur ssh qui fait le lien vers l'extérieur, donc qui a forcément un port ouvert directement (22).
Première méthode : le sshd autorise le port forwarding, on va donc faire un remote port forwarding. Le principe : un port local (de votre machine) va être forwardé par le sshd sur un port d'une machine extérieure. Au hasard, 22 puisqu'il passe le firewall. Bilan : "ssh -R 7777:machine_du_pote_externe:22 login@server_ssh" et vous appliquez l'article précédent en remplaçant machine_externe:80 par localhost:7777 , et bien sûr le serveur cubehub doit écouter sur le port 22 cette fois-ci. Cette méthode est plutôt discrète au niveau du trafic généré, les ports sont standards ssh, et bonus, tout est chiffré (il semble que le chiffrement du trafic n'affecte pas trop la latence, en tout cas avec les tests que j'ai faits)
Deuxième méthode, pas de port forwarding autorisé par le serveur ssh. On va ouvrir un port nous-mêmes, et là c'est du trafic inhabituel si quelqu'un analyse les logs réseau. Il s'agit en fait de lancer un programme exécutable sur le serveur ssh lui-même, qui va forwarder le port comme le ferait un ssh pour lequel c'est autorisé. Si vous avez un compte sur le serveur ssh, vous avez forcément un répertoire home où vous pourrez uploader des fichiers via scp. Par exemple, les sources d'un programme en C qui fait le port forwarding, comme jumpgate, si un compilateur est disponible. (C'est souvent le cas, tapez cc ou gcc pour voir) Si aucun compilateur n'est disponible, il faudra faire la cross-compilation de chez vous et uploader le binaire.
Ensuite, il n'est peut-être pas possible d'exécuter des binaires directement, par exemple si les home sont montées en noexec. Il reste une solution, si un environnement java est présent (tapez java pour voir), là, qdpf est fait pour vous.
Il va falloir un peu de connaissance unix. Sur de nombreux réseaux universitaires, on trouve un serveur ssh qui fait le lien vers l'extérieur, donc qui a forcément un port ouvert directement (22).
Première méthode : le sshd autorise le port forwarding, on va donc faire un remote port forwarding. Le principe : un port local (de votre machine) va être forwardé par le sshd sur un port d'une machine extérieure. Au hasard, 22 puisqu'il passe le firewall. Bilan : "ssh -R 7777:machine_du_pote_externe:22 login@server_ssh" et vous appliquez l'article précédent en remplaçant machine_externe:80 par localhost:7777 , et bien sûr le serveur cubehub doit écouter sur le port 22 cette fois-ci. Cette méthode est plutôt discrète au niveau du trafic généré, les ports sont standards ssh, et bonus, tout est chiffré (il semble que le chiffrement du trafic n'affecte pas trop la latence, en tout cas avec les tests que j'ai faits)
Deuxième méthode, pas de port forwarding autorisé par le serveur ssh. On va ouvrir un port nous-mêmes, et là c'est du trafic inhabituel si quelqu'un analyse les logs réseau. Il s'agit en fait de lancer un programme exécutable sur le serveur ssh lui-même, qui va forwarder le port comme le ferait un ssh pour lequel c'est autorisé. Si vous avez un compte sur le serveur ssh, vous avez forcément un répertoire home où vous pourrez uploader des fichiers via scp. Par exemple, les sources d'un programme en C qui fait le port forwarding, comme jumpgate, si un compilateur est disponible. (C'est souvent le cas, tapez cc ou gcc pour voir) Si aucun compilateur n'est disponible, il faudra faire la cross-compilation de chez vous et uploader le binaire.
Ensuite, il n'est peut-être pas possible d'exécuter des binaires directement, par exemple si les home sont montées en noexec. Il reste une solution, si un environnement java est présent (tapez java pour voir), là, qdpf est fait pour vous.