IP Over DNS

kironux · Le 08/08/2012, à 11:05

Bonjour à tous,

Deux fabuleux liens :
http://blog.uggy.org/post/2007/03/27/dn … quetes-DNS
http://www.h-i-r.net/2010/03/dns-tunnel … x-and.html

HTTP Proxy Socks over SSH over DNS.

Epic, c'est juste Epic.
(bypassing like a boss /o/)

Dernière modification par kironux (Le 10/08/2012, à 13:31)

Morgiver · Le 08/08/2012, à 11:35

Si je comprend bien, avec cette technique, tu contourne une restriction de port via le DNS ?

kironux · Le 08/08/2012, à 11:51

Oui, toutafay

Par exemple, on va prendre un exemple tout simple.
=> Un Rapsberry Pi @Home avec un NDD comme NoIP/DynDNS/DtDNS
Une petite balade, connexion à un point d'accès sans-fil (hotspot) d'un opérateur quelconque.
(Juste la connexion, pas l'authentification sur le portail captif avec les logins)
=> Vérification si les requêtes DNS passent (c'est le cas sur de nombreux hotspot, tout est bridé et seules les résolutions DNS passent)
=> Lancement de l'outil et hop :

Une IP Publique avec un NDD et une petite machine derrière qui s'occupe de traiter les requêtes avec dns2tcp et on peut utiliser les hotspots sans aucun login...

Et ça permet de passer énormément de pare-feu, il faut que celui-ci soit performant et bien configuré (il faut analyser les trames jusqu'au niveau 6 (au moins) du modèle OSI, autant dire qu'il faut un bon pare-feu...).

Il faut des systèmes performants en détection d'intrusion et des analyses constantes pour remarquer ça.
(Si on fait une analyse de trame en local, ça va sauter aux yeux, évidemment... )

Dernière modification par kironux (Le 08/08/2012, à 11:55)

billou · Le 08/08/2012, à 11:55

Très intéressant, par contre sont un peu à la bourre sur leurs tutoriels non?
Sur les dépôts AUR je suis une version au dessus.

1 aur/dns2tcp 0.5.2-2 (12)
    Dns2tcp is a tool for relaying TCP connections over DNS

gnales · Le 08/08/2012, à 11:56

magnifique
est ce que tu peu créé le faux serveur DNS sur ton ordinateur pour qu'il y accède par Lo ?

Dernière modification par gnales (Le 08/08/2012, à 12:01)

Morgiver · Le 08/08/2012, à 12:25

Dans ma ville, ya un FAI qui propose à ses client de partager leur connexion WIFI (aucune incidence sur la sécurité, ni même sur la bande passante, c'est sur un circuit différent).

Bref, ce truc on peut s'y connecter, ça propose un portail avec différent abonnement proposé et une fenetre de connexion pour les gens déjà client.

En gros, une connexion est déjà établie. Avec cette technique je pourrais contourner le bridage donc ?

kironux · Le 08/08/2012, à 13:15

billou a écrit :

Très intéressant, par contre sont un peu à la bourre sur leurs tutoriels non?
Sur les dépôts AUR je suis une version au dessus.
1 aur/dns2tcp 0.5.2-2 (12)
    Dns2tcp is a tool for relaying TCP connections over DNS

Oui, mais je t'assure que tant que tu t'accorde à peu près sur les versions, ça fonctionne bien

Par exemple, côté serveur j'ai ceci :

Package: dns2tcp
Versions:
0.5.2-1 (/var/lib/apt/lists/ftp.fr.debian.org_debian_dists_squeeze_main_binary-amd64_Packages) (/var/lib/dpkg/status)
 Description Language:
                 File: /var/lib/apt/lists/ftp.fr.debian.org_debian_dists_squeeze_main_binary-amd64_Packages
                  MD5: b6f006bd6b7256e3d2a8a3ea301a7617


Reverse Depends:
Dependencies:
0.5.2-1 - libc6 (2 2.2.5)
Provides:
0.5.2-1 -

Côté client, j'ai également (presque) la même chose :

Package: dns2tcp
Versions:
0.5.2-1 (/var/lib/apt/lists/fr.archive.ubuntu.com_ubuntu_dists_precise_universe_binary-amd64_Packages) (/var/lib/dpkg/status)
 Description Language:
                 File: /var/lib/apt/lists/fr.archive.ubuntu.com_ubuntu_dists_precise_universe_binary-amd64_Packages
                  MD5: b6f006bd6b7256e3d2a8a3ea301a7617
 Description Language: en
                 File: /var/lib/apt/lists/fr.archive.ubuntu.com_ubuntu_dists_precise_universe_i18n_Translation-en
                  MD5: b6f006bd6b7256e3d2a8a3ea301a7617


Reverse Depends:
  dns2tcp:i386,dns2tcp
Dependencies:
0.5.2-1 - libc6 (2 2.4) dns2tcp:i386 (0 (null))
Provides:
0.5.2-1 -

(Debian Squeeze pour serveur et côté client j'ai Ubuntu 12.04)

gnales a écrit :

à c'est beaux ça
est ce que tu peu créé le faux serveur DNS sur ton ordinateur pour qu'il y accède par Lo ?

J'ai fait le test chez moi, un NDD chez DtDNS et l'ouverture du port sur la box vers l'IP.
Depuis un client Linux là où je me trouve actuellement, et hop.
=> Utilitaire dns2tcp en écoute sur le port 1024 en local vers l'IP publique @home avec ssh comme type de ressource
=> SSH en local vers le port 1024 (donc qui sera envoyé @home) et proxy socks en écoute en local sur le port 8080
=> Configuration de firefox pour utiliser le proxy socks local sur le port 8080.
=> Have fun \o/

Morgiver a écrit :

Dans ma ville, ya un FAI qui propose à ses client de partager leur connexion WIFI (aucune incidence sur la sécurité, ni même sur la bande passante, c'est sur un circuit différent).
Bref, ce truc on peut s'y connecter, ça propose un portail avec différent abonnement proposé et une fenetre de connexion pour les gens déjà client.
En gros, une connexion est déjà établie. Avec cette technique je pourrais contourner le bridage donc ?

Il y a des chances, oui.
Mais bon, c'est pas très honnête...

Dernière modification par kironux (Le 08/08/2012, à 13:16)

Morgiver · Le 08/08/2012, à 13:31

Kironux a écrit :

Il y a des chances, oui.
Mais bon, c'est pas très honnête...

En fait, je me pose la question, parce que ca a l'air de faire son petit buzz cette technique.
Je me demande si une parade ne serait pas vite développée.

Je sais que certains admin réseaux deviendrait fou à l'idée qu'on puisse contourner leur systèmes de bridage, rien que celui de mon taff par exemple

kironux · Le 08/08/2012, à 13:45

Bah ça reste compliqué, si tu regarde les trames tu verra qu'en fait, toutes les requêtes sont envoyées de la manière suivante :
XXXXXXXXX.sousdomaine.domaine.extension

Tout le trafic est en UDP et les pare-feu n'y voient souvent que du feu... (désolé, pour le jeu de mot...)
Mais, des systèmes conçus pour détecter les anomalies, comme les IDS te trouveront très vite, soit par la taille des trames, soit par leur nombre excessif (vu qu'il y a très peu de cas de figure où l'on a besoin d'autant de trafic UDP et de type DNS)...

Dernière modification par kironux (Le 08/08/2012, à 13:45)

MacArony · Le 09/08/2012, à 11:41

J'ai pas compris comment on configurais tout le bouzin, un tuto "pour les nuls" ?

kironux · Le 09/08/2012, à 15:10

Tu dois avoir :
-Une IP Publique (Ligne internet personnelle (ADSL)/Serveur dédié/...) "derrière" laquelle il y aura une machine qui s'occupera d'avoir la partie "serveur" de dns2tcp.
-Un nom de domaine (ou un sous-domaine comme DtDNS/DynDNS/NoIP/...) configuré pour que toutes les requêtes issues du sous-domaine pointent vers l'IP Publique décrite précédemment, c'est le cas avec DtDNS (qui fait des pointages DNS de type CNAME)

Je vais prendre mon exemple :
Une Ubuntu chez toi (qui doit répondre quand tu en as besoin).
Dessus, on installe un client DtDNS pour que ton NDD (disons example.suroot.com) corresponde toujours à ton IP publique (prenons 98.45.73.12).
Tu y installe également le paquet dns2tcp et tu "ouvre" le port 53 sur ta *box vers l'IP locale de ta Ubuntu.
On configure la Ubuntu pour qu'elle puisse répondre (vu qu'on a déjà le NDD, l'IP, et l'ouverture de port); Pour ce faire, tu édites le fichier /etc/dns2tcp.conf de la manière suivante :

listen = 0.0.0.0
port = 53
user=nobody
chroot = /tmp
domain = example.suroot.com
ressources = myssh:127.0.0.1:22

A adapter, si nécessaire (la partie "domain" au moins).

Ensuite, comme indiqué, il y a SSH, parce qu'on exploiter un Proxy Socks via SSH, permettant d'utiliser très simplement n'importe quel logiciel
Donc on installe le paquet openssh-server pour que le service SSH sur la Ubuntu soit disponible.

Toute les étapes précédentes dont je viens de parler ne sont à effectuer qu'une seule fois.
La seule étape à faire à chaque fois que l'on veut y accéder (sauf si le programme est lancé au démarrage) est la commande suivante pour lancer la partie serveur de dns2tcp :

dns2tcpd -d 1 -F -f /etc/dns2tcpd.conf

Ça, c'était pour la partie serveur, donc la fois suivante, il y a seulement la commande "dns2tcpd..." à lancer côté serveur.

Maintenant, côté client (une autre Ubuntu, par exemple), tu installes également le paquet dns2tcp et le paquet openssh-client.
Vu que le "example.suroot.com" correspond à ton IP publique, tu peux faire une résolution via la commande nslookup :

nslookup example.suroot.com

Tu récupérera une adresse IP, ici, on a pris 98.45.73.12.

Il faut initier le "tunnel" UDP, avec les informations fournies précédemment.

dns2tcpc -c -r myssh -l 5002 -z example.suroot.com 98.45.73.12

Ici, cela veut dire que le NDD utilisé sera example.suroot.com, que les transactions iront vers l'IP 98.45.73.12 et que pour transiter via celle-ci, il faut passer par le port 5002 en local, sur ta machine client.
Actuellement, tu as un tunnel prêt à faire passer le ssh sur le port 5002, il n'y a plus qu'à l'exploiter :

ssh -D 8080 -p 5002 127.0.0.1

Ici, cela veut dire qu'on va faire initier une connexion vers nous-même, vers le port 5002, donc vers dns2tcp qui renverra le tout vers l'IP 98.45.73.12 en masquant les demandes dans des trames UDP de type DNS via le sous-domaine example.suroot.com.
Le port 8080 indique qu'un proxy socks écoute en local sur ce port là.
Ce qui veut dire que tu peux configurer Firefox/Chromium/... pour qu'ils utilisent le serveur proxy local (localhost) sur le port 8080, ces demandes iront vers le client SSH qui les fera passer du port local 8080 vers le port local 5002, donc vers dns2tcp,....
A l'autre bout du tunnel, le service se débrouillera pour initier les connexions depuis son IP publique, et donc tu apparaîtra sur le net via l'IP publique vers où tu monte le tunnel.

Pour résumer, une fois que tout est paramétré.
Tu met en écoute la partie serveur de dns2tcp :
dns2tcpd -d 1 -F -f /etc/dns2tcpd.conf
Ensuite, côté client, tu n'auras plus qu'à lancer la partie client :
dns2tcpc -c -r myssh -l 5002 -z example.suroot.com 98.45.73.12
ssh -D 8080 -p 5002 127.0.0.1

Et voilà

EDIT : En fait, après re-lecture, c'est plutôt long (faut avoir l'habitude de bidouiller un tout petit peu quand même ^^').

Dernière modification par kironux (Le 09/08/2012, à 15:11)

maxpoulin64 · Le 09/08/2012, à 22:13

Ça semble vraiment fou comme technique!

Quelqu'un l'a mis en place et saurais dire ce que ça donne en terme de performances? Faudrait pas tuer les serveurs DNS par spam de requêtes, sinon c'est déjà plus louche

kironux · Le 09/08/2012, à 22:20

C'est toi qui a la charge du serveur DNS
Et oui, j'ai mis personnellement en place la technique, selon les méthodes décrites dans les liens et les quelques explications.

Côté performance, t'es limité par l'upload de la liaison internet où tu as mis en place le serveur dns2tcp.
J'ai testé, et les performances, c'est pas fameux, faudra que j'essaye un téléchargement, mais google prends 3-4 secondes pour se charger quand même... (page d'accueil)
Je testerais avec quelques sites demain pour te donner un meilleur aperçu

maxpoulin64 · Le 09/08/2012, à 23:04

kironux a écrit :

C'est toi qui a la charge du serveur DNS
Et oui, j'ai mis personnellement en place la technique, selon les méthodes décrites dans les liens et les quelques explications.
Côté performance, t'es limité par l'upload de la liaison internet où tu as mis en place le serveur dns2tcp.
J'ai testé, et les performances, c'est pas fameux, faudra que j'essaye un téléchargement, mais google prends 3-4 secondes pour se charger quand même... (page d'accueil)
Je testerais avec quelques sites demain pour te donner un meilleur aperçu

Je suis pas d'accord avec qui reçoit la charge du serveur DNS. À moins d'installer un serveur DNS sur sa machine, c'est le DNS du FAI qui reçoit la charge de faire une requête sur le serveur DNS distant. Par exemple, si je demande "google.com", c'est pas mon PC qui va contacter Google, mais bien le DNS de mon FAI qui va le faire, pour me renvoyer seulement le résultat final.

Que ma machine distante soit chargée, je m'en fous. C'est le serveur intermédiaire qui risque de se manger une claque, ainsi que les plusieurs centaines d'utilisateurs du réseau victime du bypass qui vont voir leurs requêtes DNS ralentir.

Pour l'upload, je suis pas très limité, j'ai un serveur OVH dans le datacenter BHS

Je vais faire des tests, je donnerai les résultats ici

EDIT: Finir une phrase incomplète. Sujet, verbe, complément...

Dernière modification par maxpoulin64 (Le 09/08/2012, à 23:05)

kironux · Le 09/08/2012, à 23:17

kironux a écrit :

dns2tcpc -c -r myssh -l 5002 -z example.suroot.com 98.45.73.12

L'IP que tu vois, 98.45.73.12, c'est l'IP où vont aller toutes les requêtes DNS.
Extrait de la doc' :

dns2tcpc [ -h ] [ -c ] [ -z domain zone ] [ -d debug_level ] [ -r resource ] [ -k key ] [ -f config_file ] [ -e command ] [ -T request type ] [ -l local_port ] [ server ]
dns2tcpc is a network tool used to encapsulate TCP communications in DNS. When connections are received on a specific port all TCP traffic is sent to the remote dns2tcpd server and forwarded to a specific host and port.

Source : http://dev.man-online.org/package/main/dns2tcp/
Plus précisément : http://dev.man-online.org/man1/dns2tcpc/

Demain je ferais des tests de téléchargements et j'exporterais les données collectées via Wireshark

Dernière modification par kironux (Le 09/08/2012, à 23:54)

kironux · Le 10/08/2012, à 11:25

Et voilà, je viens de lancer le serveur dns2tcp (dns2tcpd).

Côté client, j'ai lancé le client dns2tcpc, proxy socks via ssh.

Et voilà le tout :
La capture :

Wireshark n'affiche que des trames UDP (et je n'ai aucun filtre en place sur le logiciel à ce moment là)
(Je peux uploader le fichier au format raw pour que tu puisse y jeter un coup d'oeil si tu le souhaite )

Un essai de téléchargement :

(C'est pas fameux... mais il y a les limitations des trames en UDP de type DNS...)

Voilà le test speedtest :
http://www.speedtest.net/result/2111759454.png
(Oui, ça fait mal...)

~ 25 secondes pour ouvrir doc.ubuntu-fr.org...
(Autant le dire tout de suite, ne supprimez pas le cache de votre navigateur )

Evidemment, si vous avez un serveur dédié dans un datacenter et que c'est celui-ci qui le serveur dns2tcp... Les débits seront corrects.

NB: J'ai jamais précisé que c'était une solution "viable", juste un moyen de contournement

EDIT :
Et voilà la capture via tcpdump :
http://pastebin.com/xiVP6Keq (expire dans un mois)
(J'ai pas pu tout mettre, mais il y a le début, et mis à part deux trois requêtes ARP, tout le trafic transite vers l'IP en DNS )

Dernière modification par kironux (Le 10/08/2012, à 13:30)

kironux · Le 11/08/2012, à 11:34

On peut éviter la couche SSH si on ne veut qu'utiliser le protocole HTTP, le plus simple est alors d'enregistrer une ressource en tant que proxy, et installer (sur la machine ayant dns2tcpd (demon, soit côté serveur)) un serveur proxy, comme Squid.

J'ai pas mal travaillé avec Squid, je conseille le tutoriel :
http://irp.nain-t.net/doku.php/220squid:start
Excellent tutoriel, en quelques minutes, le proxy peut-être mis en place.
Or, petit soucis, si vous passez par Squid, vous allez vous retrouver considéré comme passant par un proxy, ce qui est gênant, et on a pas forcément envie de le signaler, le plus simple est encore de demander à Squid de se faire passer pour un client lambda (donc proxy totalement anonyme, du type qui est très recherché ("High Anonymity Proxy") car il n'enverra pas votre IP dans les entêtes du protocole, et se comportera totalement comme un client standard, en tout point).
Pour ce faire, il suffit de rajouter les directives suivantes à la fin du fichier de configuration :

request_header_access Allow allow all
request_header_access Authorization allow all
request_header_access WWW-Authenticate allow all
request_header_access Proxy-Authorization allow all
request_header_access Proxy-Authenticate allow all
request_header_access Cache-Control allow all
request_header_access Content-Encoding allow all
request_header_access Content-Length allow all
request_header_access Content-Type allow all
request_header_access Date allow all
request_header_access Expires allow all
request_header_access Host allow all
request_header_access If-Modified-Since allow all
request_header_access Last-Modified allow all
request_header_access Location allow all
request_header_access Pragma allow all
request_header_access Accept allow all
request_header_access Accept-Charset allow all
request_header_access Accept-Encoding allow all
request_header_access Accept-Language allow all
request_header_access Content-Language allow all
request_header_access Mime-Version allow all
request_header_access Retry-After allow all
request_header_access Title allow all
request_header_access Connection allow all
request_header_access All deny all

(Source : http://www.squid-cache.org/Doc/config/r … er_access/ )
Très pratique pour surfer tranquillement via un proxy situé @home (ou sur un dédié/VPS) sans être fiché comme un utilisateur de proxy.
Il suffit de faire un test sur les sites suivants :
http://whatismyipaddress.com/proxy-check
http://www.lagado.com/proxy-test
Ce sont deux testeurs de proxy très performants, ils analysent chaque entrée de la trame et permet d'évaluer si on passe ou non par un proxy.
Par exemple, chez Orange, pendant plusieurs mois, lorsque je faisais le test depuis mon mobile (via le réseau mobile), il passait par un proxy, sur de nombreux sites, il n'était pas détecté, car seuls quelques tests basiques sont effectués, par contre, sur les deux liens que je viens de donner précédemment, les tests sont bien plus poussés )

De plus, si la machine est située derrière un NAT, seul le port 53 doit être "ouvert" en UDP, tout passera par celui-ci.

Et voilà

Dernière modification par kironux (Le 11/08/2012, à 11:37)

Alexandre Fenyo · Le 18/08/2012, à 17:23

Il y a encore d'autres outils que ceux indiqués précédemment, pour faire du tunneling sur DNS, disponibles sur de nombreux systèmes d'exploitation, hormis iOS. On en dénombre au moins 9 : VPN-over-DNS, Iodine, Element53, MagicTunnel, Heyoka, Dns2tcp, NSTX, OzymanDNS and DNScat. Parmi eux, on en trouve pour Android, Mac OS X, Windows, Linux et les systèmes de type Unix. Sur le forum dédié à cette technologie, pleins d'infos sur le sujet: http://ipoverdns.com

Avec certains, c'est à vous d'installer le serveur de tunnels, avec d'autres un serveur est déjà fourni, ça simplifie tout ! Regardez par ex du côté de VPN-over-DNS

renaud07 · Le 18/08/2012, à 19:49

Bonjour,

J'ai une autre méthode qui me viens en tête, par contre je ne sais pas si elle fonctionne si quelqu'un veux bien la tester ça serait sympa

Puisque l'on parle d'utiliser le port DNS, pourquoi ne pas tout simplement faire écouter le serveur SSH sur le port 53, l'ouvrir sur la box et du coté client se connecter au serveur via le port 53 et ensuite de faire une redirction dynamique du port (au hasard) 1234 du coté client et ensuite dans firefox mettre proxy socks 127.0.0.1:1234

C'est tout de même plus simple non ?

C'est ce que je faisais dans mon lycée en passant par le port SSH vu que celui-ci était ouvert et à moi la liberté ! Merci putty

Dernière modification par renaud07 (Le 18/08/2012, à 19:51)

renaud07 · Le 18/08/2012, à 20:55

J'ai un petit soucis qui m'empêche de faire quoi que ce soit : je n'arrive pas à ouvrir le port 53 sur mon serveur (debian squeeze), j'ai beau faire un :

iptables -A INPUT -p tcp -i eth0 --dport 53 -j ACCEPT

ou

iptables -A INPUT -p tcp -i eth0 --dport domain -j ACCEPT

Quand je fait un nmap 127.0.0.1, il n’apparaît pas dans les ports ouverts, mais il est bien présent quand je fais un iptables -L et bizarrement il n'y a que quand je passe la commande avec domain que ça fonctionne car si je fais avec 53 rien ne se passe.

iptables -L :

root@serveur:/home/tunnel# iptables -L
Chain INPUT (policy DROP)
target     prot opt source               destination         
fail2ban-apache  tcp  --  anywhere             anywhere            multiport dports www,https 
fail2ban-ssh  tcp  --  anywhere             anywhere            multiport dports ssh,sftp 
fail2ban-apache-overflows  tcp  --  anywhere             anywhere            multiport dports www,https 
fail2ban-apache-multiport  tcp  --  anywhere             anywhere            multiport dports www,https 
fail2ban-ssh-ddos  tcp  --  anywhere             anywhere            multiport dports ssh 
fail2ban-apache-noscript  tcp  --  anywhere             anywhere            multiport dports www,https 
ACCEPT     all  --  anywhere             anywhere            state ESTABLISHED 
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:ssh 
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:www 
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:https 
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:3128 
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:netbios-ssn 
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:microsoft-ds 
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:mysql 
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:domain  <---------
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     icmp --  anywhere             anywhere

nmap 127.0.0.1 :

root@serveur:/home/tunnel# nmap 127.0.0.1

Starting Nmap 5.00 ( http://nmap.org ) at 2012-08-18 20:53 CEST
Interesting ports on localhost (127.0.0.1):
Not shown: 991 closed ports
PORT      STATE SERVICE
22/tcp    open  ssh
80/tcp    open  http
111/tcp   open  rpcbind
139/tcp   open  netbios-ssn
443/tcp   open  https
445/tcp   open  microsoft-ds
3128/tcp  open  squid-http
3306/tcp  open  mysql
10000/tcp open  snet-sensor-mgmt

Mais où est-il passé ?

C'est grave docteur ?

Dernière modification par renaud07 (Le 18/08/2012, à 21:01)

Alexandre Fenyo · Le 20/08/2012, à 20:46

Bonne idée mais ça ne marchera pas : le principe d'IP sur DNS n'est pas de faire une connexion directe entre un client (ton PC ou mobile) et ton serveur DNS sur Internet (qui est le terminateur DNS), ce type de connexion directe n'est jamais permise car le principe d'une bonne config firewall c'est de tout fermer par défaut et de n'ouvrir que ce qu'on a besoin d'ouvrir. Or on n'a pas besoin d'ouvrir l'accès au port 53 TCP ou UDP à tout Internet pour permettre des requêtes DNS. On permet simplement le client de faire des requêtes vers le RESOLVER DNS qui est fourni dans la réponse DHCP au moment où le client découvre son IP. Or ce Resolver DNS n'est pas sur Internet mais chez le fournisseur qui t'a donné cette IP.

Mettre un serveur SSH sur port 53 ne marchera donc pas.

Désolé!

renaud07 a écrit :

Bonjour,
J'ai une autre méthode qui me viens en tête, par contre je ne sais pas si elle fonctionne si quelqu'un veux bien la tester ça serait sympa
Puisque l'on parle d'utiliser le port DNS, pourquoi ne pas tout simplement faire écouter le serveur SSH sur le port 53, l'ouvrir sur la box et du coté client se connecter au serveur via le port 53 et ensuite de faire une redirction dynamique du port (au hasard) 1234 du coté client et ensuite dans firefox mettre proxy socks 127.0.0.1:1234
C'est tout de même plus simple non ?
C'est ce que je faisais dans mon lycée en passant par le port SSH vu que celui-ci était ouvert et à moi la liberté ! Merci putty

Alexandre Fenyo · Le 20/08/2012, à 20:47

C'est pas grave, c'est simplement que ton DNS il écoute sur le port 53 UDP et pas sur le port 53 TCP, or tu fais tous tes iptables et nmap en TCP uniquement !!

renaud07 a écrit :

J'ai un petit soucis qui m'empêche de faire quoi que ce soit : je n'arrive pas à ouvrir le port 53 sur mon serveur (debian squeeze), j'ai beau faire un :

iptables -A INPUT -p tcp -i eth0 --dport 53 -j ACCEPT

ou

iptables -A INPUT -p tcp -i eth0 --dport domain -j ACCEPT

Quand je fait un nmap 127.0.0.1, il n’apparaît pas dans les ports ouverts, mais il est bien présent quand je fais un iptables -L et bizarrement il n'y a que quand je passe la commande avec domain que ça fonctionne car si je fais avec 53 rien ne se passe.

iptables -L :

root@serveur:/home/tunnel# iptables -L
Chain INPUT (policy DROP)
target     prot opt source               destination         
fail2ban-apache  tcp  --  anywhere             anywhere            multiport dports www,https 
fail2ban-ssh  tcp  --  anywhere             anywhere            multiport dports ssh,sftp 
fail2ban-apache-overflows  tcp  --  anywhere             anywhere            multiport dports www,https 
fail2ban-apache-multiport  tcp  --  anywhere             anywhere            multiport dports www,https 
fail2ban-ssh-ddos  tcp  --  anywhere             anywhere            multiport dports ssh 
fail2ban-apache-noscript  tcp  --  anywhere             anywhere            multiport dports www,https 
ACCEPT     all  --  anywhere             anywhere            state ESTABLISHED 
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:ssh 
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:www 
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:https 
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:3128 
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:netbios-ssn 
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:microsoft-ds 
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:mysql 
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:domain  <---------
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     icmp --  anywhere             anywhere

nmap 127.0.0.1 :

root@serveur:/home/tunnel# nmap 127.0.0.1

Starting Nmap 5.00 ( http://nmap.org ) at 2012-08-18 20:53 CEST
Interesting ports on localhost (127.0.0.1):
Not shown: 991 closed ports
PORT      STATE SERVICE
22/tcp    open  ssh
80/tcp    open  http
111/tcp   open  rpcbind
139/tcp   open  netbios-ssn
443/tcp   open  https
445/tcp   open  microsoft-ds
3128/tcp  open  squid-http
3306/tcp  open  mysql
10000/tcp open  snet-sensor-mgmt

Mais où est-il passé ?

C'est grave docteur ?

renaud07 · Le 20/08/2012, à 21:13

Merci pour la réponse, je vais retenter avec udp voir si ça marche mieux.

renaud07 · Le 20/08/2012, à 21:24

Je crois que j'ai compris, c'est normal que je vois rien quand je fais un nmap car si le service est pas démarré le port correspondant n’apparaît pas, mais maintenant j'ai un problème de démarrage de dns2tcp voilà ce que ça me mets :

root@serveur:~# dns2tcpd -d 1 -F -f /etc/dns2tcpd.conf
21:12:10 : Debug options.c:97	Add resource ssh:127.0.0.1 port 22
21:12:10 : Debug options.c:97	Add resource smtp:127.0.0.1 port 25
21:12:10 : Debug socket.c:55	Listening on 127.0.0.1:53 for domain your.domain.tld
Starting Server v0.5.2...
21:12:10 : Debug main.c:132	Chroot to /tmp
19:12:10 : Debug main.c:142	Change to user nobody

Et ça ne va pas plus loin. Une idée ? Qu'est ce que vient faire le port 25 là-dedans ?

Dernière modification par renaud07 (Le 29/08/2015, à 03:16)

renaud07 · Le 20/08/2012, à 21:37

C'est bon finalement, je m'étais trompé de fichier de configuration ! J'éditais le fichier /etc/dns2tcp.conf au lieu de /etc/dns2tcpd.conf

Dernière modification par renaud07 (Le 29/08/2015, à 03:17)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 08/08/2012, à 11:05

IP Over DNS

#2 Le 08/08/2012, à 11:35

Re : IP Over DNS

#3 Le 08/08/2012, à 11:51

Re : IP Over DNS

#4 Le 08/08/2012, à 11:55

Re : IP Over DNS

#5 Le 08/08/2012, à 11:56

Re : IP Over DNS

#6 Le 08/08/2012, à 12:25

Re : IP Over DNS

#7 Le 08/08/2012, à 13:15

Re : IP Over DNS

#8 Le 08/08/2012, à 13:31

Re : IP Over DNS

#9 Le 08/08/2012, à 13:45

Re : IP Over DNS

#10 Le 09/08/2012, à 11:41

Re : IP Over DNS

#11 Le 09/08/2012, à 15:10

Re : IP Over DNS

#12 Le 09/08/2012, à 22:13

Re : IP Over DNS

#13 Le 09/08/2012, à 22:20

Re : IP Over DNS

#14 Le 09/08/2012, à 23:04

Re : IP Over DNS

#15 Le 09/08/2012, à 23:17

Re : IP Over DNS

#16 Le 10/08/2012, à 11:25

Re : IP Over DNS

#17 Le 11/08/2012, à 11:34

Re : IP Over DNS

#18 Le 18/08/2012, à 17:23

Re : IP Over DNS

#19 Le 18/08/2012, à 19:49

Re : IP Over DNS

#20 Le 18/08/2012, à 20:55

Re : IP Over DNS

#21 Le 20/08/2012, à 20:46

Re : IP Over DNS

#22 Le 20/08/2012, à 20:47

Re : IP Over DNS

#23 Le 20/08/2012, à 21:13

Re : IP Over DNS

#24 Le 20/08/2012, à 21:24

Re : IP Over DNS

#25 Le 20/08/2012, à 21:37

Re : IP Over DNS

Pied de page des forums