+---------------------------------------------------------------+
| Guia rapida de tunneling IP sobre DNS Alejandro Ramos |
| 29/Mar/2005 v0.2 aramosf@unsec.net |
+---------------------------------------------------------------+
/ 1.- Introduccion /
+--------------------+
El proposito de esta guia es crear un tunel IP sobre el protocolo DNS
para conseguir salir a Internet en un entorno donde al unico servicio que
podemos acceder es un DNS que nos resuelve direcciones de Internet.
Muy practico para redes wireless en las que te permiten asociarte pero solo
te dan salida una vez te has autentificado via HTTP, previo pago. Como por
ejemplo en aeropuertos y hoteles. Estos sitios suelen tener un DNS que
resuelve dominios de Internet, requisito indispensable.
El siguiente texto va a mostar un ejemplo practico de una de estas confi-
guraciones.
El funcionamiento es sencillo, se desarrolla un servidor DNS que responde
a determinadas peticiones encapsulando en Base32 (si se realizan peticiones
mediante CNAME) o en Base 64 (si son registros TXT). El cliente sera capaz de
desencapsular la codificacion de la peticion y generar el paquete correcto.
En la actualidad existen dos aplicaciones que nos permiten realizar un
tunel atraves de DNS: nstx (http://nstx.dereference.de/nstx/) y ozymandns
(http://www.doxpara.com/). Se muestra una lista comparativa:
Ventajas de ozymandns:
* Esta escrito en perl, por lo que se puede portar a cualquier sistema
que soporte este interprete.
* Es sencillo y rapido de configurar.
Inconvenientes de ozymandns:
* Solo permite realizar un SSH o hay que realizar un tunel ssh posterior.
* El software es beta e inestable.
Ventajas de nstx:
* Permite usar cualquier tipo de servicio.
* Software antiguo y mas comprobado.
* Existen paquetes para algunas distribuciones (debian sid).
Inconvenientes de nstx:
* Tanto servidor como cliente tiene que ser linux.
* Se necesita crear un tunel con tun/tap.
Ademas de estas aplicaciones existen otras que nos permiten enviar
y recibir ficheros por DNS o usarlo para encapsular VoIP.
OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO
J J
O Ambos sistemas no usan autenticacion, alguien que conozca la O
J configuracion que se ha realizado en su sistema podria usar J
O el tunel DNS. O
J J
OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO
/ 2.- Requisitos /
+------------------+
Partimos de la premisa de que tenemos un conocimiento basico de como funciona
un servidor DNS y cuales son sus tipos de registros; A, NS, TXT...
Una configuracion tipo, en la que nuestros dispositivos van marcados entre
asteriscos podria ser la siguiente:
[*PC cliente*] ~~ wireless ~~ [ AP ]
|
[ switch ]-----[ server DNS (con acceso) ]
|
[ router ]
|
/\/\/\/\/\
[*server DNS*]-------|Internet|-----[*server tunel*]
\/\/\/\/\/
Por lo que seria necesario:
- Cliente desde el que realizar el tunel.
- Servidor DNS que podamos administrar y en el que tengamos un dominio.
- Servidor tunel, donde correra la aplicacion servidor.
- Acceso como cliente a un servidor DNS
En el ejemplo que se usara a lo largo del texto se usaran los siguientes
datos:
- Server DNS (con acceso): 10.1.2.2, sera el DNS al que tengamos acceso
como cliente y que ha de ser capaz de resolver nuestro dominio.
- Server tunel: este sistema es nuestro y en el instalaremos la parte
que sirve peticiones, es necesario que un DNS pueda preguntarle y para ello
necesita el 53/udp abierto a Internet.
- Server DNS: es indistinta la IP.
/ 3.- Configuracion DNS /
+-------------------------+
Si se tiene claro el concepto de recursividad en DNS y como funciona
no tendria por que encontrar ninguna dificultad a la hora de configurar
el dominio para poder realizar el tunel.
En el ejemplo se va a utilizar el dominio 'digitalsec.net' como referencia.
Editamos el fichero de zona de digitalsec.net, en este caso (fedora core 3
con named enjaulado): /var/named/chroot/var/named/db.digitalsec.net, y se
a?aden los siguientes registros:
t.digitalsec.net. IN NS tun.digitalsec.net.
tun IN A 65.73.147.191
Con estos dos registros lo que se esta haciendo es enviar al sistema
tun.digitalsec.net (65.73.147.191) todas las peticiones que cuelgen de
t.digitalsec.net. Es decir, si alguien pregunta por 'foo.t.digitalsec.net' el
servidor DNS que esta escuchando en t.digitalsec.net (65.73.147.191) sera el
encargado de resolver esas peticiones.
En 65.73.147.191 es donde ha estar el servidor de tunel DNS.
Esta configuracion es comun para nstx y ozymandns. Las pruebas que se han
realizado han sido con bind y todo ha funcionado correctamente, por lo que he
visto en el paquete de debian, con djbdns hace falta parchear para el caso de
nstx. Asi que si no se desean complicaciones adicionales, lo mas sencillo es
usar bind.
/ 4.- Configuracion ozymandns /
+--------------------------------+
Se obtiene el software de su url oficial: http://www.doxpara.com/, en la
actualidad la ultima version es: http://www.doxpara.com/ozymandns_src_0.1.tgz.
Para que ozymandns funcione son necesarios una serie de modulos CPAN,
se puede encontrar informacion detallada de como instalarlos en la direccion:
http://www.cpan.org/modules/INSTALL.html. Muchas distribuciones tienen
algunos de estos modulos como paquetes, por lo que no seria necesario insta-
larlos manualmente y compilarlos.
Los scripts necesarios para hacer funcionar el tunel son: nomde.pl (servidor)
y droute.pl (cliente), las demas aplicaciones incluidas en el tarball son para
otros propositos.
Una vez que se haya terminado de instalar todo lo necesario al ejecutar
los scripts en perl, no ha de existir ningun problema y ha de mostrar la ayuda:
# perl nomde.pl
nomde 0.1: Experimental DNS Server
Component of: OzymanDNS Dan Kaminsky(dan@doxpara.com)
Usage: nomde -l 10.0.1.11 servername.foo.com
Options: -i [ip address]: IP address to host for all A requests
-f [filename] : Filename to host in TXT records [b64]
-p [name] : Name/IP to return for reverse lookups[ptr]
-L [name:host:port]: Forward function to address, port
(Default: sshdns:127.0.0.1:22)
Hay que tener en cuenta que esta aplicacion es una beta y tiene algunos
fallos; la ayuda no se corresponde con las opciones reales y en el caso
concreto del "nomde.pl", el parametro -L no funciona como se espera. Este punto
se vera mas adelante cuando se configure el servidor.
- PARTE SERVIDOR - :
Este es el servicio que se ejecutara en el servidor del tunel, exactamente
en la direccion tun.digitalsec.net (65.73.147.191).
El siguiente comando dejaria lista esta parte:
# ./nomde.pl -i 127.0.0.1 t.digitalsec.net
creating TCP socket...done.
creating UDP socket...done.
waiting for connections...
Esto, por defecto permite hacer un ssh a 127.0.0.1 (es decir, al servidor que
realiza el tunel o tun.digitalsec.net) al puerto 22, esto es teoricamente
modificable con la opcion "-L", pero por un bug no funciona y si se desea que
el SSH se haga contra otra IP y puerto, habra que modificarlo en el codigo
fuente:
Con cambiar la linea 32 de nomde.pl:
"Localforward"=> \$opts{forward}
por la siguiente:
"Localforward=s"=> \$opts{forward}
Tendremos solucionado el problema.
Este comando nos permitira hacer un SSH al puerto 2222 de 82.165.25.126
# ./nomde.pl -i 127.0.0.1 -L sshdns:82.165.25.126:2222 t.digitalsec.net
creating TCP socket...done.
creating UDP socket...done.
waiting for connections...
Por otro fallo el script se "cae" de vez en cuando, para que se vuelva a
ejecutar cada vez que falle, se puede utilizar alguna solucion temporal como
la siguiente:
# while true; do ./nomde.pl -i 127.0.0.1 t.digitalsec.net; done
- PARTE CLIENTE - :
Seguiremos los mismos pasos que en el servidor para instalar los modulos
CPAN necesarios para que la ejecucion del script "droute.pl" no de ningun
problema.
# ssh -p2222 -o ProxyCommand="droute.pl sshdns.t.digitalsec.net" \
aramosf@82.165.25.126
Con esto se realizara un SSH al sistema que se le especifico anteriormente en
el servidor con la opcion -L. Notese que se ha a?adido "sshdns" delante de
t.digitalsec.net. Otra apreciacion es que el usuario y direccion IP solo seran
utilizados a la hora de comprobar si existe llave privada o si el sistema remoto
es un "know host". Si se desea cambiar la direccion destino del SSH ha de ser
en el servidor de tunel (nomde.pl) con la opcion -L.
El script droute.pl si se desea ejecutar en windows, se puede hacer mediante
el perl y el ssh de cygwin, usando los modulos de CPAN. Aunque es posible que
funcionei tambien bajo el perl de ActiveState y con otro cliente de SSH que
soporte la opcion una opcion como "ProxyCommand" del cliente openssh.
/ 5.- Configuracion nstx /
+--------------------------+
Para que nstx funcione es requisito tener compilado el kernel de los
sistemas linux con soporte para ethertap/tun. Tanto cliente como servidor.
Device Drivers --->
Networking support --->
Universal TUN/TAP device driver support
Hay veces que es necesario crear el dispositivo a mano:
# mkdir /dev/net
# mknod /dev/net/tun c 10 200
NOTA: La configuracion de tun0 tanto en servidor como en cliente se realiza
DESPUES de arrancar las aplicaciones.
- PARTE SERVIDOR - :
Se instalara como en el caso de ozymandns en tun.digitalsec.net
(65.73.147.191). Descargar el software desde: http://nstx.dereference.de/nstx/.
La ultima version en la actualidad es: nstx-1.1-beta6.tgz
Como ya se explico anteriormente, es posible que existe un paquete
con los binarios necesarios. En el caso de debian sid, el paquete se llama
"nstx", y con instalarlo con el comando "apt-get install nstx" seria suficiente,
solo habria que proceder a configurarlo en el fichero: /etc/default/nstx.
Una vez descomprimido y compilado:
# tar -zxvf nstx-1.1-beta6.tgz
# cd nstx-1.1-beta6
# make
Se tendran los binarios necesarios para la ejecucion en la parte del servidor,
que sera ejecutado con la opcion para que cambie el UID del usuario a nobody y
deje el servicio en background:
# ./nstxd -u nobody -D t.digitalsec.net
Opening tun/tap-device... using device tun0
Please configure this device appropriately (IP, routes, etc.)
Opening nameserver-socket... listening on 53/UDP
Cargar el modulo de TUN:
# modprobe -a tun
Por ultimo, se configura el interfaz con una IP interna (la que se desee):
# ifconfig tun0 172.26.0.2 netmask 255.255.255.0
- PARTE CLIENTE - :
Realizar el mismo proceso de descarga y compilacion del tarball nstx para
la parte del cliente.
Cargar el modulo de TUN:
# modprobe -a tun
Lanzar el cliente apuntando a t.digitalsec.net y al DNS al que tengamos
acceso como cliente en el ejemplo, 10.1.2.2:
# ./nxstcd t.digitalsec.net 10.1.2.2
Finalmente, configurar el dispositivo tun0 con un interfaz en la misma red
que el servidor:
# ifconfig tun0 172.26.0.1 netmask 255.255.255.0
Con esto ya deberia de existir conectividad con nuestro cliente y la ip del
servidor remoto: 172.26.0.2
/ 6.- Contramedidas /
+--------------------+
Una de las posibles opciones para evitar peticiones CNAME es usando iptables
en el router/firewall con una regla similar a esta:
# iptables -t filter -A INPUT -p udp --dport 53 \
-m string --string "CNAME" -j DROP
Para utilizar "string" en iptables, es necesario aplicar el corresponidente
parche de "patch-o-matic". El problema de utilizar este metodo es la bajada de
rendimientto del sistema, y el gran numero de paquetes que se descartan que son
falsos positivos, ademas, implementar el mismo filtro para TXT resultaria una red
con excesivos paquetes eliminados.
Una alternativa es utilizar un servidor de DNS que no acepte peticiones de la
clase TXT ni CNAME, o que compruebe el tamanyo de la respuestas para localizar
posibles peticiones empaquetadas.
El siguiente ejemplo muestra un script bastante simple en perl que realiza
esta funcion.
--------------------------------------------------------------------------------
#!/usr/bin/perl
# Mon May 16 00:00:44 CEST 2005
# Last version at: http://www.unsec.net
#
# proxy-dns, check lengh of respones and deny TXT records
#
# BUGS: All Net::DNS bugs -> SLOW!
#
use Net::DNS::Nameserver;
use Net::DNS::Resolver;
use Net::DNS;
use Getopt::Long;
use POSIX qw(strftime);
use strict;
my ($daemon, $log, $verbose, $ns, $help, $length);
my $length = 100;
my $log = "/dev/stdout";
GetOptions(
"daemon" => \$daemon,
"log=s" => \$log,
"ns=s" => \$ns,
"length=s" => \$length,
"verbose" => \$verbose,
"help" => \$help);
if(defined($help)) {
print STDERR <<"EOD";
Syntax: $0 [--daemon] [--log ] [--verbose] [--ns ] [--help]
Options:
--daemon : run script as daemon
--log : log all querys to (default: STDOUT)
--ns : use instead /etc/resolv.conf
--length : use of maximum length of reply (default: 100)
--verbose : verbose output
--help : this help
EOD
exit 1;
}
if (defined($daemon)) {
defined(my $pid = fork) or die "Error: $!";
exit if $pid;
}
open LOG, ">>$log";
print LOG scalar(localtime) . " [$0] Starting service\n";
sub reply_handler {
my ($qname, $qclass, $qtype, $peerhost) = @_;
my ($rcode, @ans, @auth, @add, $ret, $r1, $r2);
my $res = Net::DNS::Resolver->new;
$res->nameservers("$ns") if defined $ns;
my $query = $res->query($qname, $qtype);
if ($query) {
foreach my $rr ($query->answer) {
next unless $rr->type eq "$qtype";
$ret = $rr->address if $qtype eq "A";
$ret = $rr->ptrdname if $qtype eq "PTR";
$ret = $rr->nsdname if $qtype eq "NS";
if ($qtype eq "MX") {
$ret = $rr->preference . " " . $rr->exchange;
}
if (($qtype ne "TXT") || length($ret) gt $length) {
my ($ttl, $rdata) = (3600, "$ret");
push @ans, Net::DNS::RR->new("$qname $ttl $qclass $qtype $rdata");
print LOG scalar(localtime) . " [$0] $qname -> $qclass $qtype " .
"from: $peerhost reply: $rdata\n";
$rcode = "NOERROR";
} else {
print LOG scalar(localtime) . " [$0] $qname -> $qclass $qtype " .
"from: $peerhost reply: REFUSED(".length($ret).")\n";
$rcode = "REFUSED";
}
}
} else {
print LOG scalar(localtime) . " [$0] $qname -> $qclass $qtype " .
"from: $peerhost reply: NO ANSWER\n";
$rcode = "NOTAUTH";
}
return ($rcode, \@ans, \@auth, \@add, { aa => 1 });
}
my $ns = Net::DNS::Nameserver->new(
LocalPort => 53,
ReplyHandler => \&reply_handler,
Verbose => $verbose,
) || die "couldn't create nameserver\n";
$ns->main_loop;
close LOG;
--------------------------------------------------------------------------------
/ 7.- Referencias /
+------------------+
http://www.doxpara.com/Black_Ops_DNS_BH.ppt
http://www.aripollak.com/wiki/Main/SSHOverDNS
http://slashdot.org/articles/00/09/10/2230242.shtml
/ 8.- Control de cambios /
+-------------------------+
lun may 16 00:53:54 CEST 2005
+ Añadido punto de contramedidas.
+ Version en ingles.
+ Añadido control de cambios.
