 |
| spit - explicaciones del dns, y dns abuse
|
|
|
|
|
|
 |
 |
.---------------------------------------------------------------------------.
| Titulo : DNS Manager. Windows NT 4.0 (v.1.0) |
| Autor : |spit| |
| Fecha | `-------------------------------------------------[-
Indice:
1.- Introduccion
2.- Estructura del DNS
3.- Solicitud de DNS y proceso de busqueda
4.- Instalacion
5.- Configuracion y alta de dominios en el DNS Manager
6.- Duda retorica
7.- NSLookup
8.- Ejemplo de alta de un dominio '.es' en nic.
9.- Bibliografia
1.- Introduccion
El servicio de DNS (Domain Name System) se utiliza para asignar nombres
a los ordenadores en Internet y nos permite traducir nombres de maquinas
(host´s) a direcciones IP y viceversa. Siempre sera mas facil recordar
un nombre que unos numeros.
Ejemplo:
Host: www.undersec.com
IP: 62.164.20.60
2.- Estructura del DNS
Cada ordenador esta formado por la sucesion jerarquica de dominios, que
estaran separados por puntos (' . ') y que empiezan por el subdominio
inferior.
Las normas para los nombres de dominios las establece InterNIC (Internet
Network Information Center). http://www.internic.net
Dominios de nivel superior de tres posiciones:
com ----- Comercial
edu ----- Educativo
gov ----- Gobierno
org ----- Organizacion
net ----- Proovedores ('Networking')
mil ----- Militar
int ----- Internacional
Dominios geograficos de dos posiciones:
es ----- España
de ----- Alemania
se ----- Suecia
at ----- Austria
ch ----- Suiza
jp ----- Japon
su ----- Union Sovietica
uk ----- Gran Bretaña
En el DNS, cada dominio por debajo de estos dominios de nivel
superior puede estar formado como maximo por 63 caracteres y no
se permite el uso de caracteres especiales. Solo esta permitido el uso
de los caracteres 'a-z', 'A-Z', '0-9', y '-'. Estos nombres deben
ser unicos.
Ejemplos:
Dominio: undersec.com
Dominio: networking-center.org
| |
| Dominio de primer nivel
Dominio de segundo nivel
Direcciones de interes:
http://www.networksolution.com
http://www.nic.es
3.- Solicitud de DNS y proceso de busqueda
Caso 1:
(1)
Cliente -------------------------------> Servidor DNS
|<---------------<-----<---------<-------|
(2)
En este caso, el cliente pide a el servidor DNS que tenga configurado
que le resuelva un host (Paso 1). Luego el servidor de DNS devuelve
al cliente si existe o no ese host y con que IP (Paso 2).
Caso 2:
(1)
Cliente -------------------------------> Servidor DNS
|<---------------<-----<---------<-------| |
(3) |(2)
|
Root Server
En este otro caso, el cliente pide a el servidor DNS que tenga configurado
que le resuelva un host (Paso 1). Luego el servidor de DNS ve que no lo
tiene en su 'cache' y manda la solucitud a un Root Server, que le devolvera
si existe o no el dominio y con que IP, pero ademas lo guardara en su 'cache'
para no tener que acudir a un Root Server la proxima vez que le pregunten
por ese mismo host (Paso 2). Acto seguido, el servidor de DNS devuelve al
cliente si existe o no ese host y con que IP (Paso 3).
4.- Instalacion
Lo primero que tienes que hacer es tener configurado en el protocolo TCP/IP el
nombre de tu PC y Dominio, y en dns pon tu ip (puesto que tu seras servidor de
dns). Luego tienes que agregar el servicio de DNS y para ello te vas al
panel de control, entorno de red, services, agregar, DNS.
Una vez agregado tendras que reiniciar la maquina. Una vez reiniciado, es
aconsejable que vuelvas a instalar el ultimo Service Pack que tuvieras metido,
para asegurarte de que todo funcionara bien (y reinicias de nuevo).
5.- Configuracion y alta de dominios en el DNS Manager
Debemos ir a las Herramientas Administrativas y abrir el DNS Manager, te creas un
'New Server', que sera tu maquina, luego pondras tu IP y a empezar a dar
de alta dominios. Una vez que agregas tu ip, saldra una especie de mundo que se
llama cache y que memoriza las direcciones ip de los servidores que no conoce,
o sea.. memoriza los dominios que no conoce. En teoria es obligatorio tener un
servidor de dns primario y otro secundario.
Como dariamos de alta un dominio?
Server List - New Server
IP:192.168.1.2 -- New Zone -- Primary -- zone name: codex.es -- zone file: codex.es.dns
Ahora nos creara una carpeta con el nombre codex.es y le damos sobre ella al
boton derecho y a propiedades.
En la ventana SOA Records:
* Serial Number: 2000030401 (los ultimos dos numeros es el numero del dominio
que se ha dado de alta en el dia y el resto es la fecha del dia puesta al reves.
Esto se hace para llebar un mejor control de los dominios).
* Intervalo de refresco: 24 Horas
* Retry Iterval: 2 Horas
* Expire Time: 30 Dias
* Minimun Default: 2 Dias
* TTL: 2 Dias
* Intervalo de refresco: El tiempo que esperara un servidor secundario
entre comprobaciones de su servidor maestro para ver si el archivo de base
de datos ha cambiado y si hay que pedir una transferencia de zona.
* Retry Iterval: El tiempo que esperara un servidor secundario antes de
volver a intentar una transferencia de zona que haya fallado.
* Expire Time: El tiempo que un servidor secundario seguira intentando
descargar una zona. Cuando haya pasado este tiempo, se rechazara la
informacion antigua de la zona.
* TTL - El tiempo que un servidor DNS tiene permitido acumular en la
cache cualquier registro del recurso de este archivo de base de datos.
Le damos a Ok y volvemos a la pantalla principal del DNS Manager. Una vez alli
vamos al menu de arriba a options -> preferences y activamos el refresco cada
5 segundos.
Volvemos a la carpeta codex.es y vemos que tenemos un record NS y otro SOA.
Nos queda crear un record tipo A y un CNAME, de forma que al final quedara de
la siguiente forma:
codex.es
codex.es NS Nombre_PC.dominio
codex.es SOA Nombre_PC.dominio
Nombre_PC A IP_del_PC
www CNAME Nombre_PC
ftp CNAME Nombre_PC
Esta forma es mala en aquellos casos en que te vayan a pedir estadisticas de
las webs que haya alojadas ya que aparece la ip del host donde esta la web y
no aparece la url de la pagina.
Esto lo conseguimos evitar de la siguiente forma:
codex.es
codex.es NS IP_del_PC
codex.es SOA IP_del_PC
Nombre_PC A IP_del_PC
www A IP_del_PC_que_ofrece_el_servio_www
ftp A IP_del_PC_que_ofrece_el_servio_ftp
Cuando estemos añadiendo los "record" nos dara la opcion de añadir un PTR,
que sale señalada por defecto. No se trata de otra cosa que de una DNS inversa.
(tendriamos que crear nosotros la zona)
Ejemplo: IP: 192.168.1.2
DNS Inversa: 1.168.192.In-addr.arpa
Recuerda añadir en la configuracion del TCP/IP, en las DNS, tu ip de la maquina.
Nota: Todos los dominios que vayais creando se iran almacenando en archivos
de texto que podreis encontrar en c:winntsystem32dns. Por ejemplo, si creo
el dominio codex.es tendre el respectivo codex.es.dns
Si queremos borrar un dominio, no nos basta con borrarlo en el dns manager, sino
que tambien tendremos que borrar su respectivo archivo de c:winntsystem32dns
Aunque a primera vista esto parezca un rollo, es bastante bueno porque si
borrais accidentalmente algun dominio, podreis acudir a ese archivo de texto para
restaurarlo 
6.- Duda retorica
Os comento cierta duda que tengo del dns maganer.. vereis, al dar de alta un
dominio, por ejemplo codex.es no me da la posibilidad de crear un registro
tipo A llamado codex.es de forma que si hiciera un ping codex.es me devolviera
la ip que se le dijera.
Ej:
codex.es A 212.79.133.40
www A 212.79.133.40
ftp A 212.79.133.40
Esto si se puede hacer con el DNS Manager del W2K.
Bien, estuve pensando un poko y lo que hice fue crear una nueva zona que se
llamara ' es ' en la cual me mete directamete todos los dominios 'es' que
tuviera y una vez ahi, creaba un registro tipo A a codex.es y si me lo
permitia.
Ej:
212.79.133.40
|
|- codex.es
|- pepito.es
|
|- es
| |- codex
| |- pepito
|
Bien, como he dicho antes, asi si me permite crear el ' codex.es A
212.79.133.40 ' pero claro, no resuelvo los dominios 'es', con lo cual pues
mi gozo en un pozo.. mi sorpresa fue cuando borre la zona 'es' porque en
codex.es se habia quedado el registro tipo A ( codex.es A 212.79.133.40 )
Si edito el archivo c:winntsystem32dnscodex.es.dns me aparece lo siguiente:
; Database file codex.es.dns for codex.es zone.
; Zone version: 3
;
@ IN SOA nt.supercable.es. . (
3 ; serial number
3600 ; refresh
600 ; retry
86400 ; expire
3600 ) ; minimum TTL
;
; Zone NS records
;
@ NS nt.supercable.es.
;
; Zone records
;
@ A 212.79.133.40
www A 212.79.133.40
Al parecer el ' codex.es A 212.79.133.40 ' lo mete como: ' @ A 212.79.133.40 '
pero si se intenta hacer de forma manual lo ignora totalmente.
Si alguien sabe algo a cerca de lo que comento aqui que se ponga en contacto
conmigo a traves de e-mail (codex@undersec.com) ya que he preguntado a bastante
gente y en varias listas de correo y nadie me ha sabido decir si esto es
posible o no.
7.- NSLookup
nslookup es una de las principales herramientas de diagnostico a la hora de depurar una arquitectura de sistema de nombres de dominio (DNS). Se puede
usar para mostrar cualquier registro de recurso de cualquier servidor DNS,
incluyendo implementaciones DNS de unix.
C:>nslookup
Default Server: seux002.supercable.es
Address: 212.79.128.3
> set type=any
> supercable.es
Server: seux002.supercable.es
Address: 212.79.128.3
supercable.es nameserver = seux005.supercable.es
supercable.es nameserver = seux002.supercable.es
supercable.es
primary name server = seux002.supercable.es
responsible mail addr = root.supercable.net
serial = 2000042401
refresh = 86400 (1 day)
retry = 3600 (1 hour)
expire = 2592000 (30 days)
default TTL = 172800 (2 days)
supercable.es MX preference = 10, mail exchanger = seux002.supercable.es
supercable.es nameserver = seux005.supercable.es
supercable.es nameserver = seux002.supercable.es
seux005.supercable.es internet address = 212.79.128.18
seux002.supercable.es internet address = 212.79.128.3
C:>nslookup
Default Server: seux002.supercable.es
Address: 212.79.128.3
> ls supercable.es
[seux002.supercable.es]
supercable.es. NS server = seux005.supercable.es
supercable.es. NS server = seux002.supercable.es
sewms001 A 212.79.128.26
cliente-212079146001.cm128.agnpa A 212.79.146.1
cliente-212079146002.cm128.agnpa A 212.79.146.2
cliente-212079146003.cm128.agnpa A 212.79.146.3
cliente-212079146004.cm128.agnpa A 212.79.146.4
cliente-212079146005.cm128.agnpa A 212.79.146.5
cliente-212079146006.cm128.agnpa A 212.79.146.6
cliente-212079146007.cm128.agnpa A 212.79.146.7
cliente-212079146010.cm128.agnpa A 212.79.146.10
cliente-212079146008.cm128.agnpa A 212.79.146.8
cliente-212079146011.cm128.agnpa A 212.79.146.11
cliente-212079146009.cm128.agnpa A 212.79.146.9
.
.
.
.
cliente-213227019135.cm256.manpd A 213.227.19.135
cliente-213227019136.cm256.manpd A 213.227.19.136
cliente-213227019137.cm256.manpd A 213.227.19.137
distribuidores A 212.79.128.11
> server 195.57.10.2
Default Server: sigrid.sodefesa.es
Address: 195.57.10.2
> ls sodefesa.es
[sigrid.sodefesa.es]
sodefesa.es. NS server = sigrid1.sodefesa.es
sodefesa.es. NS server = sigrid.sodefesa.es
ftp A 195.57.10.25
news A 194.179.3.124
poseidon A 195.57.10.25
private A 195.57.10.7
prometeus A 195.57.10.29
sigr1 A 195.57.10.53
sigrid A 195.57.10.2
sigrid1 A 195.57.10.3
www A 195.57.10.25
8.- Ejemplo de alta de un dominio ' .es ' en nic.
Aqui os pongo un ejemplo del formulario que hay que rellenar y mandar por e-mail
para dar de alta un domio 'es' en http://www.nic.es
Nota: Todo lo que vaya entre ' /* texto */ ' son comentarios mios aclaratorios
/* Conviene dar de alta el dominio en el servidor DNS de la makina
y luego mandar la solicitud. Cuando se mande el formulario, hay que hacerlo en
'Plain Text' */
------8<------------- Cortar por aqui (No enviar esta linea) ---------------
FSE Version: 1.0
SECCION 0 - Tipo Solicitud
0a. Accion a efectuar
(N|CR|B|CD)..................: N
0b. Estado Dominio (para N, CR o CD)
(R|D|MX).....................: R
0c. Dominio a expirar (para CD)..: .es
SECCION 1 - Dominio Objeto de Registro
1. Nombre Dominio...............: codex.es
SECCION 2 - Organizacion Usuaria del Nombre de Dominio /* Solo permite registrar
marcas registradas o acronimos.*/
2a. Nombre Organizacion Completo.:
2b. Forma Juridica...............:
2c. N.I.F........................: 45710999-K /* DNI con la letra del NIF */
2d. Fecha de Constitucion........: 19790320 /* año mes dia (todo junto)*/
2e. Domicilio (Calle,No...)......:
2f. Domicilio (Municipio)........:
2g. Domicilio (Cod. Postal)......:E-41010 /* el 'E-' debe mantenerse*/
2h. Domicilio (Provincia)........:
2i. Domicilio (Pais).............:SPAIN
SECCION 3 - Para Nombre de Dominio Asociado a Marca Registrada en lugar de al
Nombre Oficial de la Organizacion
3a. Marca Registrada en OEPM.....: /* nombre de la marca */
3b. Numero Inscripcion en OEPM...: /* el nuemero que sea. Ej: 23458790/X */
3c. Fecha de Concesion...........: /* año mes dia (todo junto) */
SECCION 4 - Persona de Contacto Administrativo
4a. NIC Handle...................: /* es un codigo. hay que dejarlo en blanco.
una vez registrado el dominio nos dan el NIC handle y para el proximo dominio
que queramos registrar solo tenemos que poner ese codigo, sin necesidad de rellenar
el resto de los datos.*/
4b. Nombre y Apellidos...........:
4c. Nombre Organizacion Completo.: /* lo mismo que hemos puesto en '2a'. EXACTAMENTE IGUAL. */
4d. Nombre Departamento..........:
4e. Cargo........................: /* conviene poner al gerente o director
de la empresa, ya que es la persona que figura en las escrituras. */
4f. Direccion (Calle,No...)......: /* la direccion de la empresa, no la del
gerente o director. */
4g. Direccion (Municipio)........:
4h. Direccion (Cod. Postal)......:E-
4i. Direccion (Provincia)........:
4j. Direccion (Pais).............:SPAIN
4k. E-mail.......................: /* usuario@nombredominio.es Hay que hacerlo,
sino te lo rechazan. */
4l. Numero Fax...................: +34 5 54340158 /* Formato: +34 5 54340158 (el
primer nº del prefijo no se pone. En el caso de ser de Sevilla, el '9' del '954' no se pone) */
4m. Numero Telefono..............: +34 5 54340158 /* Igual que en el '4l' */
SECCION 5 - Persona(s) de Contacto Tecnico /* Datos de la empresa proovedora (ISP). */
5a. NIC Handle...................: /* Si es el primer registro de dominio que
hago pues no tengo NIC Handle y tengo que rellenar los otros datos. En caso de tenerlo,
solo rellenariamos el '5a' */
5b. Nombre y Apellidos...........:
5c. Nombre Organizacion Completo.: /* Nombre del Proovedor */
5d. Nombre Departamento..........:
5e. Cargo........................:
5f. Direccion (Calle,No...)......:
5g. Direccion (Municipio)........:
5h. Direccion (Cod. Postal)......:
5i. Direccion (Provincia)........:
5j. Direccion (Pais).............:
5k. E-mail.......................:
5l. Numero Fax...................:
5m. Numero Telefono..............:
SECCION 6 - Persona de Contacto Facturacion /* Datos de la persona que pagara la factura. */
6a. NIC Handle...................: /* Si ya tenemos no hace falta rellenar el resto */
6b. Nombre y Apellidos...........:
6c. Nombre Organizacion Completo.: /* El mismo que hemos puesto en la seccion 5.*/
6d. Nombre Departamento..........:
6e. Cargo........................:
6f. Direccion (Calle,No...)......:
6g. Direccion (Municipio)........:
6h. Direccion (Cod. Postal)......:
6i. Direccion (Provincia)........:
6j. Direccion (Pais).............:
6k. E-mail.......................:
6l. Numero Fax...................:
6m. Numero Telefono..............:
6n. N.I.F. (Organizacion en 6c)..:
SECCIONES 7 Y 8 - Para Delegacion de Zona Asociada al Dominio
7a. Nombre Servidor Primario.....: /* nombre del servidor de DNS. Ej: ns1.arrakis.es*/
7b. Direccion IP S. Primario.....: /* la IP */
8a. Nombre Servidor Secundario...: /* nombre del servidor de DNS. Ej: ns2.arrakis.es*/
8b. Direccion IP S. Secundario...: /* la IP */
SECCION 9 - Para Registro(s) MX asociado(s) al Dominio
9a. Nombre Estafeta E-mail SMTP..: /* Esto dejarlo en blanco. */
SECCION 10 - Proveedor(es) de Servicio de Acceso a Internet
10. Acronimo de Proveedor........: /* Ej: arrakis ó interbook ó supercable ... */
/* Despues de esto aparece el tipico texto en el que nos ponen los
'requisitos' y 'deberes' para la aceptacion del dominio. */
------8<------------- Cortar por aqui (No enviar esta linea) ---------------
9.- Bibliografia
* Apuntes de clase de NT de 2º de Administracion de Sistemas Informaticos.
Curso 1999/2000.
* El gran libro de Windows NT. Ed. Marcombo, 1996 Madrid.
* Asi es Windows 2000 Server. Ed. Mac Graw Hill, 1999 Madrid
-- |CoDeX| -- - -- - -- - -- - -- - -- - -- - -- - -- - -- - -- - -- - -- - --
-- - -- - -- - -- - -- - -- - -- - -- - -- - -- - Undersec Security Team -- -
DNS Abuse
roots
http://www.ezkracho.com.ar
Conceptos Básicos.
La función de un servidor DNS (Nameserver/NS ) es la de resolver IPs a nombres y viceversa. Como funciona la
resolución? veamos:
Nuestro NS es ns.elites.com y el nombre que nos han dicho que resolvamos es "box1.intrac.victim.com".
Lo que hara nuestro nameserver es destripar la dirección en partes. Primero consultará a uno de los
ROOT-nameservers de Inet quien sirve el dominio "com". El NS tiene una lista de estos ROOT-NS con sus IPs
asociadas, luego no tiene que consultar ya que IPs tienen (sino no conseguiria resolver nunca nada). Bueno,
consulta el dominio "com". Entonces obtiene la dirección del NS que sirve al dominio "com". Después pregunta a ese
NS quien sirve el dominio "victim". Obtiene la direccion de otro NS, a éste le pregunta quien sirve el dominio "box1",
obtiene la direccion de otro NS y le pregunta que IP tiene la maquina "intrac". Asi, ya ha obtenido la IP de
"box1.intrac.victim.com", pongamos, por ejemplo, que es 134.134.134.134.
Aquí ha terminado el trabajo de nuestro NS, que además de resolver la dirección, la guarda en su cache.
La cache es un registro de las últimas direcciones que resolvió el NS, por si se consulta sobre éstas no tener que
volver a resolverlas.
Nota: Éste es el funcionamiento de un NS que soporta la función de recursividad (la mayoria). Esto significa que si
el NS no sirve la dirección que se le pide que resuelva, enviara la peticion a otro NS para que la resuelva, hasta
obtener la resolución o un error de dirección irresoluble. Si el NS no tiene esta función de recursividad,
simplemente, si sirve el dominio de la dirección que le pedimos que resuelva la resolvera, y sino nos dira que no
puede resolverla.
Por tanto, las vulnerabilidades que se explican mas adelante,
SOLO AFECTAN A SERVIDORES DNS QUE SOPORTAN RECURSION
Datagramas DNS.
El protocolo DNS se comunica por UDP, un protocolo de transporte sin conexión, es decir, que lanza el paquete a la
red, y ya no se preocupa mas de él. Ésto imposibilita que se lleve un control del flujo de la conexión, correccion de
errores, etc. Éste es un punto muy importante, pues UDP no puede, al contrario que TCP, mantener un flujo de
comunicación entre dos hosts, con los ya conocidos sequence numbers.
Si queremos spoofear o meternos en medio de una conexion UDP no tendremos que predecir estos seqnums.
Dado que el protocolo de transporte no identifica los paquetes por conexión, debe ser el protocolo DNS el que
asigne a los paquetes una "identificación" para poder saber que paquete responde a una pregunta anterior, etc.
A esta identificación se le llama QueryID y la asigna el NS que inicia la comunicación (el que hace el request). A
partir de ese momento todos los paquetes referentes a la resolucion de esa pregunta iran identificados con ese
QueryID.
Inyección de datos falsos en la cache de un NS.
A continuación viene la parte interesante, como engañar a un NS para que resuelva un nombre dado a una IP que
queramos nosotros o al revés.
Método A:Suplantación de un NS.
Para este ataque debemos disponer de:
- Un NS primario (al que pueda consultar cualquier máquina sobre un dominio)
Aca vamos
Digamos que nosotros somos m2.espejito.org (1.1.1.1) y el ns que controlamos es ns.zc.com y queremos spoofear
como xxx.panial.org al NS ns.victima.com
Se trata de hacernos pasar por el ns de xxx.panial.org y hacer creer a ns.victima.com que ha resuelto bien a
xxx.panial.org. Para crear este "paquete" con información falsa, el NS de ns.victima.com debe preguntarnos sobre
él, y en ese momento sera cuando nosotros contestemos. Pero como no somos el NS de xxx.panial.org no podemos
saber cual será el QueryID de ns.victima.com. Por tanto tenemos un problema, como sabemos el QueryID que
tendrá el paquete que preguntará sobre xxx.panial.org ?
Si hacemos una consulta a ns.victima.com sobre una dirección que sirva el ns.zc.com. ns.victima.com se pondrá
en contacto con ns.zc.com y le preguntará la dirección de www.zc.com, nuestro NS le responderá, y tan
contentos. Dado que previamente habremos sniffeado la conexion con nuestro NS por parte de ns.victima.com
preguntando por la direccion de www, sabremos con que QueryID ha preguntado.
El QueryID del protocolo DNs no es un número aleatorio o pseudo-aleatorio como el de algunas implementaciones
de TCP, sino que es secuencial, ésto es, que para cada pregunta, aumenta en uno el QueryID. Esto es así porque
el QueryID no se diseñó como un mecanismo de seguridad ante posibles spoofs, sino como una manera de controlar
que respuesta corresponde a que pregunta y al revés.
Una vez tenemos el QueryID del NS víctima creamos un datagrama DNS con la información falsa que queremos
transmitir (xxx.panial.org <-> 1.1.1.1 ), como si la enviara el NS de panial.org, y con destino a ns.victima.com.
Hacemos una consulta al ns.victima.com preguntando por alguna direccion del dominio xxx.panial.org y
inmediatamente enviamos el paquete de respuesta spoofeado.
En lugar de enviar un paquete es conveniente enviar unos cuantos, con QueryIDs consecutivos, dado que en el
tiempo en que hemos tardado entre que obtenemos el queryID y solicitamos la consulta por xxx.panial.org el NS
victima puede haber recibido otras peticiones de resolución, y por tanto el QueryID puede haber aumentado
ligeramente.
Asi, si ns.victima.com recibe antes nuestra respuesta que la respuesta del NS de xxx.panial.org (si existe) o un
error indicando que no hay tal dominio (en caso de que no exista) ya tendremos en la cache del NS víctima la
información falsa que queriamos inyectarle.
Método B: Inyección de datos en nuestra respuesta.
Para este ataque debemos disponer igual que antes de un NS primario.
Veamos..
Cuando un NS hace una consulta a otro no sabe que numero de respuestas puede obtener a su query, ni le
importa, pues todo lo que sea información lo va a recibir
Pues bien, si al hacer una consulta a un NS, además (o en lugar) de la información que solicita se le devuelve la
informacion falsa que nosotros queramos, el NS que preguntó la aceptará y ya la tendremos en la cache del DNS
que nos preguntó.
Así, lo único que debemos hacer es preparar nuestro NS (ns.zc.com) para que responda con la información falsa
(xxx.panial.org <->1.1.1.1) a las preguntas de un NS (ns.victima.com) y hacer que el NS víctima pregunte a
nuestro NS.
Este método es mucho más sencillo y efectivo que el anterior, aunque requiere mas recursos para que funcione,
debemos modificar el programa servidor de nombres o bien hacer un programa que funcione como tal, y que sirva
nuestros datos falsos.
Impacto.
Aparte del uso que todos están pensando para este tipo de ataques a DNS como tener un host personalizado al
entrar al irc... hay multitud de usos mucho más serios, en que la seguridad de muchos sistemas puede quedar
comprometida:
- NFS (Network File Sharing) en sistemas que exporten para nombres de hosts
- Servicios r* (rlogin, rsh, etc.) haciendonos pasar por "trusted hosts".
- TCP Wrappers que se basen en nombres de hosts para cortar el paso.
Conclusión.
El protocolo DNS es sensible a ataques de este tipo, y probablemente existen muchas más vulnerabilidades.
El primer ataque seria evitable si se usase un protocolo de transporte como TCP, con números de sequencia
"aleatorios" o bien usando QueryIDs tambien más o menos aleatorios.
La segunda vulnerabilidad es ya inherente al protocolo DNS, y necesitaria de una profunda revisión de la
especificación de DNS para controlar que las respuestas se correspondan con lo que hemos preguntado.
No se olviden de leer la RFC 1536
Puesta en practica del metodo B
Vamos a suponer que ya tenemos lo que necesitabamos, un host que sea NS primario de un dominio y otro host
donde haremos correr nuesto programa "inyector" de informacion falsa DNS.
Vamos a suponer esta situacion:
- Nameserver primario: ns.zc.com
- Host que corre el inyector: 134.134.134.134.
Voy a exponer aqui cual serian las modificaciones a hacer a la configuracion del demonio DNS suponiendo que este
es el "named", el que con mas probabilidad vais a encontrar en un server un*x.
Lo primero que hacemos es consultar en el fichero de configuracion del named donde almacena la informacion de
los dominios que sirve. Este fichero es el /etc/named.boot o en las nuevas versiones de bind es /etc/named.conf y
se ha modificado un poco la estructura del fichero, en cuyo caso vas a tener que adaptar las explicaciones que de
aqui un poco). En nuestro ejemplo, contiene lo siguiente:
directory /var/named
cache . root.cache
primary zc.com db.zc.com
secondary castor.org db.castor.org
Esto significa: directory /var/named : Directorio base donde almacena los ficheros de
configuracion de los dominios primary zc.com db.zc.com : Es un NS primario del dominio zc.com, y lo
almacena en el fichero db.zc.com (El que nos interesa) secondary castor.org : Es Ns secundario del dominio
castor.org, y lo almacena en el fichero db.castor.org (Este no nos interesa)
Miramos al fichero db.zc.com (que como sabemos, estara en /var/named):
zc.com. IN SOA ns.zc.com. root.zc.com. (
1997062100
28800
7200
604800
86400)
zc.com. IN NS ns.zc.com.
localhost IN A 127.0.0.1
XXX IN A 10.0.0.1
owned.zc.com. IN A 10.0.0.2
Las primeras lineas se refieren a la configuracion del dominio, quien lo gestiona, las fechas de expiracion, etc.
A continuacion esta la configuracion de los Nameservers del dominio:
zc.com. IN NS ns.zc.com.
En esta linea se especifica que el host "ns.zc.com" sirve al dominio zc.com.
Aqui es donde vamos a hacer la modificacion. Tenemos que insertar una linea en que se reconozca a nuestro host
inyector como nameserver de este dominio. A la derecha de un IN NS solo se acepta un FQDN, es decir, no
podemos poner una ip numérica. Asi que vamos a tener que crear un host y luego asignarle una IP. La primera
modificacion quedaria asi con lo que hemos supuesto antes:
zc.com. IN NS ns.zc.com.
zc.com. IN NS ns1.zc.com.
Ahora vamos que tener que asignarle la IP a este host nuevo que hemos creado (ns1.zc.com). Para asignar una IP
numerica a un FQDN, se usa el RR "IN A", tal como se puede ver en las siguientes lineas:
XXX IN A 10.0.0.1
owned.zc.com. IN A 10.0.0.2
La segunda linea, asigna la IP 10.0.0.2 al FQDN owned.zc.com. El punto al final de owned.zc.com. es muy
importante, ya que si no le ponemos punto (como a XXX) el named le pone al final el nombre del dominio (zc.com).
Asi, para insertar la linea que queremos, y segun lo que hemos supuesto antes, utilizariamos esta linea:
ns1.zc.com. IN A 134.134.134.134.
Asi ya tenemos el named configurado para el spoof. Solo nos queda recargar esta informacion en el named (killall
-HUP named), esperar a que la informacion se propague y poner a trabajar el programa inyector.
|
|
Hoy habia 8 visitantes¡Aqui en esta página!
|
|
 |
|
|
|
6.- Duda retorica
Os comento cierta duda que tengo del dns maganer.. vereis, al dar de alta un
dominio, por ejemplo codex.es no me da la posibilidad de crear un registro
tipo A llamado codex.es de forma que si hiciera un ping codex.es me devolviera
la ip que se le dijera.
Ej:
codex.es A 212.79.133.40
www A 212.79.133.40
ftp A 212.79.133.40
Esto si se puede hacer con el DNS Manager del W2K.
Bien, estuve pensando un poko y lo que hice fue crear una nueva zona que se
llamara ' es ' en la cual me mete directamete todos los dominios 'es' que
tuviera y una vez ahi, creaba un registro tipo A a codex.es y si me lo
permitia.
Ej:
212.79.133.40
|
|- codex.es
|- pepito.es
|
|- es
| |- codex
| |- pepito
|
Bien, como he dicho antes, asi si me permite crear el ' codex.es A
212.79.133.40 ' pero claro, no resuelvo los dominios 'es', con lo cual pues
mi gozo en un pozo.. mi sorpresa fue cuando borre la zona 'es' porque en
codex.es se habia quedado el registro tipo A ( codex.es A 212.79.133.40 )
Si edito el archivo c:winntsystem32dnscodex.es.dns me aparece lo siguiente:
; Database file codex.es.dns for codex.es zone.
; Zone version: 3
;
@ IN SOA nt.supercable.es. . (
3 ; serial number
3600 ; refresh
600 ; retry
86400 ; expire
3600 ) ; minimum TTL
;
; Zone NS records
;
@ NS nt.supercable.es.
;
; Zone records
;
@ A 212.79.133.40
www A 212.79.133.40
Al parecer el ' codex.es A 212.79.133.40 ' lo mete como: ' @ A 212.79.133.40 '
pero si se intenta hacer de forma manual lo ignora totalmente.
Si alguien sabe algo a cerca de lo que comento aqui que se ponga en contacto
conmigo a traves de e-mail (codex@undersec.com) ya que he preguntado a bastante
gente y en varias listas de correo y nadie me ha sabido decir si esto es
posible o no.
7.- NSLookup
nslookup es una de las principales herramientas de diagnostico a la hora de depurar una arquitectura de sistema de nombres de dominio (DNS). Se puede
usar para mostrar cualquier registro de recurso de cualquier servidor DNS,
incluyendo implementaciones DNS de unix.
C:>nslookup
Default Server: seux002.supercable.es
Address: 212.79.128.3
> set type=any
> supercable.es
Server: seux002.supercable.es
Address: 212.79.128.3
supercable.es nameserver = seux005.supercable.es
supercable.es nameserver = seux002.supercable.es
supercable.es
primary name server = seux002.supercable.es
responsible mail addr = root.supercable.net
serial = 2000042401
refresh = 86400 (1 day)
retry = 3600 (1 hour)
expire = 2592000 (30 days)
default TTL = 172800 (2 days)
supercable.es MX preference = 10, mail exchanger = seux002.supercable.es
supercable.es nameserver = seux005.supercable.es
supercable.es nameserver = seux002.supercable.es
seux005.supercable.es internet address = 212.79.128.18
seux002.supercable.es internet address = 212.79.128.3
C:>nslookup
Default Server: seux002.supercable.es
Address: 212.79.128.3
> ls supercable.es
[seux002.supercable.es]
supercable.es. NS server = seux005.supercable.es
supercable.es. NS server = seux002.supercable.es
sewms001 A 212.79.128.26
cliente-212079146001.cm128.agnpa A 212.79.146.1
cliente-212079146002.cm128.agnpa A 212.79.146.2
cliente-212079146003.cm128.agnpa A 212.79.146.3
cliente-212079146004.cm128.agnpa A 212.79.146.4
cliente-212079146005.cm128.agnpa A 212.79.146.5
cliente-212079146006.cm128.agnpa A 212.79.146.6
cliente-212079146007.cm128.agnpa A 212.79.146.7
cliente-212079146010.cm128.agnpa A 212.79.146.10
cliente-212079146008.cm128.agnpa A 212.79.146.8
cliente-212079146011.cm128.agnpa A 212.79.146.11
cliente-212079146009.cm128.agnpa A 212.79.146.9
.
.
.
.
cliente-213227019135.cm256.manpd A 213.227.19.135
cliente-213227019136.cm256.manpd A 213.227.19.136
cliente-213227019137.cm256.manpd A 213.227.19.137
distribuidores A 212.79.128.11
> server 195.57.10.2
Default Server: sigrid.sodefesa.es
Address: 195.57.10.2
> ls sodefesa.es
[sigrid.sodefesa.es]
sodefesa.es. NS server = sigrid1.sodefesa.es
sodefesa.es. NS server = sigrid.sodefesa.es
ftp A 195.57.10.25
news A 194.179.3.124
poseidon A 195.57.10.25
private A 195.57.10.7
prometeus A 195.57.10.29
sigr1 A 195.57.10.53
sigrid A 195.57.10.2
sigrid1 A 195.57.10.3
www A 195.57.10.25
8.- Ejemplo de alta de un dominio ' .es ' en nic.
Aqui os pongo un ejemplo del formulario que hay que rellenar y mandar por e-mail
para dar de alta un domio 'es' en http://www.nic.es
Nota: Todo lo que vaya entre ' /* texto */ ' son comentarios mios aclaratorios
/* Conviene dar de alta el dominio en el servidor DNS de la makina
y luego mandar la solicitud. Cuando se mande el formulario, hay que hacerlo en
'Plain Text' */
------8<------------- Cortar por aqui (No enviar esta linea) ---------------
FSE Version: 1.0
SECCION 0 - Tipo Solicitud
0a. Accion a efectuar
(N|CR|B|CD)..................: N
0b. Estado Dominio (para N, CR o CD)
(R|D|MX).....................: R
0c. Dominio a expirar (para CD)..: .es
SECCION 1 - Dominio Objeto de Registro
1. Nombre Dominio...............: codex.es
SECCION 2 - Organizacion Usuaria del Nombre de Dominio /* Solo permite registrar
marcas registradas o acronimos.*/
2a. Nombre Organizacion Completo.:
2b. Forma Juridica...............:
2c. N.I.F........................: 45710999-K /* DNI con la letra del NIF */
2d. Fecha de Constitucion........: 19790320 /* año mes dia (todo junto)*/
2e. Domicilio (Calle,No...)......:
2f. Domicilio (Municipio)........:
2g. Domicilio (Cod. Postal)......:E-41010 /* el 'E-' debe mantenerse*/
2h. Domicilio (Provincia)........:
2i. Domicilio (Pais).............:SPAIN
SECCION 3 - Para Nombre de Dominio Asociado a Marca Registrada en lugar de al
Nombre Oficial de la Organizacion
3a. Marca Registrada en OEPM.....: /* nombre de la marca */
3b. Numero Inscripcion en OEPM...: /* el nuemero que sea. Ej: 23458790/X */
3c. Fecha de Concesion...........: /* año mes dia (todo junto) */
SECCION 4 - Persona de Contacto Administrativo
4a. NIC Handle...................: /* es un codigo. hay que dejarlo en blanco.
una vez registrado el dominio nos dan el NIC handle y para el proximo dominio
que queramos registrar solo tenemos que poner ese codigo, sin necesidad de rellenar
el resto de los datos.*/
4b. Nombre y Apellidos...........:
4c. Nombre Organizacion Completo.: /* lo mismo que hemos puesto en '2a'. EXACTAMENTE IGUAL. */
4d. Nombre Departamento..........:
4e. Cargo........................: /* conviene poner al gerente o director
de la empresa, ya que es la persona que figura en las escrituras. */
4f. Direccion (Calle,No...)......: /* la direccion de la empresa, no la del
gerente o director. */
4g. Direccion (Municipio)........:
4h. Direccion (Cod. Postal)......:E-
4i. Direccion (Provincia)........:
4j. Direccion (Pais).............:SPAIN
4k. E-mail.......................: /* usuario@nombredominio.es Hay que hacerlo,
sino te lo rechazan. */
4l. Numero Fax...................: +34 5 54340158 /* Formato: +34 5 54340158 (el
primer nº del prefijo no se pone. En el caso de ser de Sevilla, el '9' del '954' no se pone) */
4m. Numero Telefono..............: +34 5 54340158 /* Igual que en el '4l' */
SECCION 5 - Persona(s) de Contacto Tecnico /* Datos de la empresa proovedora (ISP). */
5a. NIC Handle...................: /* Si es el primer registro de dominio que
hago pues no tengo NIC Handle y tengo que rellenar los otros datos. En caso de tenerlo,
solo rellenariamos el '5a' */
5b. Nombre y Apellidos...........:
5c. Nombre Organizacion Completo.: /* Nombre del Proovedor */
5d. Nombre Departamento..........:
5e. Cargo........................:
5f. Direccion (Calle,No...)......:
5g. Direccion (Municipio)........:
5h. Direccion (Cod. Postal)......:
5i. Direccion (Provincia)........:
5j. Direccion (Pais).............:
5k. E-mail.......................:
5l. Numero Fax...................:
5m. Numero Telefono..............:
SECCION 6 - Persona de Contacto Facturacion /* Datos de la persona que pagara la factura. */
6a. NIC Handle...................: /* Si ya tenemos no hace falta rellenar el resto */
6b. Nombre y Apellidos...........:
6c. Nombre Organizacion Completo.: /* El mismo que hemos puesto en la seccion 5.*/
6d. Nombre Departamento..........:
6e. Cargo........................:
6f. Direccion (Calle,No...)......:
6g. Direccion (Municipio)........:
6h. Direccion (Cod. Postal)......:
6i. Direccion (Provincia)........:
6j. Direccion (Pais).............:
6k. E-mail.......................:
6l. Numero Fax...................:
6m. Numero Telefono..............:
6n. N.I.F. (Organizacion en 6c)..:
SECCIONES 7 Y 8 - Para Delegacion de Zona Asociada al Dominio
7a. Nombre Servidor Primario.....: /* nombre del servidor de DNS. Ej: ns1.arrakis.es*/
7b. Direccion IP S. Primario.....: /* la IP */
8a. Nombre Servidor Secundario...: /* nombre del servidor de DNS. Ej: ns2.arrakis.es*/
8b. Direccion IP S. Secundario...: /* la IP */
SECCION 9 - Para Registro(s) MX asociado(s) al Dominio
9a. Nombre Estafeta E-mail SMTP..: /* Esto dejarlo en blanco. */
SECCION 10 - Proveedor(es) de Servicio de Acceso a Internet
10. Acronimo de Proveedor........: /* Ej: arrakis ó interbook ó supercable ... */
/* Despues de esto aparece el tipico texto en el que nos ponen los
'requisitos' y 'deberes' para la aceptacion del dominio. */
------8<------------- Cortar por aqui (No enviar esta linea) ---------------
9.- Bibliografia
* Apuntes de clase de NT de 2º de Administracion de Sistemas Informaticos.
Curso 1999/2000.
* El gran libro de Windows NT. Ed. Marcombo, 1996 Madrid.
* Asi es Windows 2000 Server. Ed. Mac Graw Hill, 1999 Madrid
-- |CoDeX| -- - -- - -- - -- - -- - -- - -- - -- - -- - -- - -- - -- - -- - --
-- - -- - -- - -- - -- - -- - -- - -- - -- - -- - Undersec Security Team -- -
DNS Abuse
roots
http://www.ezkracho.com.ar
Conceptos Básicos.
La función de un servidor DNS (Nameserver/NS ) es la de resolver IPs a nombres y viceversa. Como funciona la
resolución? veamos:
Nuestro NS es ns.elites.com y el nombre que nos han dicho que resolvamos es "box1.intrac.victim.com".
Lo que hara nuestro nameserver es destripar la dirección en partes. Primero consultará a uno de los
ROOT-nameservers de Inet quien sirve el dominio "com". El NS tiene una lista de estos ROOT-NS con sus IPs
asociadas, luego no tiene que consultar ya que IPs tienen (sino no conseguiria resolver nunca nada). Bueno,
consulta el dominio "com". Entonces obtiene la dirección del NS que sirve al dominio "com". Después pregunta a ese
NS quien sirve el dominio "victim". Obtiene la direccion de otro NS, a éste le pregunta quien sirve el dominio "box1",
obtiene la direccion de otro NS y le pregunta que IP tiene la maquina "intrac". Asi, ya ha obtenido la IP de
"box1.intrac.victim.com", pongamos, por ejemplo, que es 134.134.134.134.
Aquí ha terminado el trabajo de nuestro NS, que además de resolver la dirección, la guarda en su cache.
La cache es un registro de las últimas direcciones que resolvió el NS, por si se consulta sobre éstas no tener que
volver a resolverlas.
Nota: Éste es el funcionamiento de un NS que soporta la función de recursividad (la mayoria). Esto significa que si
el NS no sirve la dirección que se le pide que resuelva, enviara la peticion a otro NS para que la resuelva, hasta
obtener la resolución o un error de dirección irresoluble. Si el NS no tiene esta función de recursividad,
simplemente, si sirve el dominio de la dirección que le pedimos que resuelva la resolvera, y sino nos dira que no
puede resolverla.
Por tanto, las vulnerabilidades que se explican mas adelante,
SOLO AFECTAN A SERVIDORES DNS QUE SOPORTAN RECURSION
Datagramas DNS.
El protocolo DNS se comunica por UDP, un protocolo de transporte sin conexión, es decir, que lanza el paquete a la
red, y ya no se preocupa mas de él. Ésto imposibilita que se lleve un control del flujo de la conexión, correccion de
errores, etc. Éste es un punto muy importante, pues UDP no puede, al contrario que TCP, mantener un flujo de
comunicación entre dos hosts, con los ya conocidos sequence numbers.
Si queremos spoofear o meternos en medio de una conexion UDP no tendremos que predecir estos seqnums.
Dado que el protocolo de transporte no identifica los paquetes por conexión, debe ser el protocolo DNS el que
asigne a los paquetes una "identificación" para poder saber que paquete responde a una pregunta anterior, etc.
A esta identificación se le llama QueryID y la asigna el NS que inicia la comunicación (el que hace el request). A
partir de ese momento todos los paquetes referentes a la resolucion de esa pregunta iran identificados con ese
QueryID.
Inyección de datos falsos en la cache de un NS.
A continuación viene la parte interesante, como engañar a un NS para que resuelva un nombre dado a una IP que
queramos nosotros o al revés.
Método A:Suplantación de un NS.
Para este ataque debemos disponer de:
- Un NS primario (al que pueda consultar cualquier máquina sobre un dominio)
Aca vamos
Digamos que nosotros somos m2.espejito.org (1.1.1.1) y el ns que controlamos es ns.zc.com y queremos spoofear
como xxx.panial.org al NS ns.victima.com
Se trata de hacernos pasar por el ns de xxx.panial.org y hacer creer a ns.victima.com que ha resuelto bien a
xxx.panial.org. Para crear este "paquete" con información falsa, el NS de ns.victima.com debe preguntarnos sobre
él, y en ese momento sera cuando nosotros contestemos. Pero como no somos el NS de xxx.panial.org no podemos
saber cual será el QueryID de ns.victima.com. Por tanto tenemos un problema, como sabemos el QueryID que
tendrá el paquete que preguntará sobre xxx.panial.org ?
Si hacemos una consulta a ns.victima.com sobre una dirección que sirva el ns.zc.com. ns.victima.com se pondrá
en contacto con ns.zc.com y le preguntará la dirección de www.zc.com, nuestro NS le responderá, y tan
contentos. Dado que previamente habremos sniffeado la conexion con nuestro NS por parte de ns.victima.com
preguntando por la direccion de www, sabremos con que QueryID ha preguntado.
El QueryID del protocolo DNs no es un número aleatorio o pseudo-aleatorio como el de algunas implementaciones
de TCP, sino que es secuencial, ésto es, que para cada pregunta, aumenta en uno el QueryID. Esto es así porque
el QueryID no se diseñó como un mecanismo de seguridad ante posibles spoofs, sino como una manera de controlar
que respuesta corresponde a que pregunta y al revés.
Una vez tenemos el QueryID del NS víctima creamos un datagrama DNS con la información falsa que queremos
transmitir (xxx.panial.org <-> 1.1.1.1 ), como si la enviara el NS de panial.org, y con destino a ns.victima.com.
Hacemos una consulta al ns.victima.com preguntando por alguna direccion del dominio xxx.panial.org y
inmediatamente enviamos el paquete de respuesta spoofeado.
En lugar de enviar un paquete es conveniente enviar unos cuantos, con QueryIDs consecutivos, dado que en el
tiempo en que hemos tardado entre que obtenemos el queryID y solicitamos la consulta por xxx.panial.org el NS
victima puede haber recibido otras peticiones de resolución, y por tanto el QueryID puede haber aumentado
ligeramente.
Asi, si ns.victima.com recibe antes nuestra respuesta que la respuesta del NS de xxx.panial.org (si existe) o un
error indicando que no hay tal dominio (en caso de que no exista) ya tendremos en la cache del NS víctima la
información falsa que queriamos inyectarle.
Método B: Inyección de datos en nuestra respuesta.
Para este ataque debemos disponer igual que antes de un NS primario.
Veamos..
Cuando un NS hace una consulta a otro no sabe que numero de respuestas puede obtener a su query, ni le
importa, pues todo lo que sea información lo va a recibir
Pues bien, si al hacer una consulta a un NS, además (o en lugar) de la información que solicita se le devuelve la
informacion falsa que nosotros queramos, el NS que preguntó la aceptará y ya la tendremos en la cache del DNS
que nos preguntó.
Así, lo único que debemos hacer es preparar nuestro NS (ns.zc.com) para que responda con la información falsa
(xxx.panial.org <->1.1.1.1) a las preguntas de un NS (ns.victima.com) y hacer que el NS víctima pregunte a
nuestro NS.
Este método es mucho más sencillo y efectivo que el anterior, aunque requiere mas recursos para que funcione,
debemos modificar el programa servidor de nombres o bien hacer un programa que funcione como tal, y que sirva
nuestros datos falsos.
Impacto.
Aparte del uso que todos están pensando para este tipo de ataques a DNS como tener un host personalizado al
entrar al irc... hay multitud de usos mucho más serios, en que la seguridad de muchos sistemas puede quedar
comprometida:
- NFS (Network File Sharing) en sistemas que exporten para nombres de hosts
- Servicios r* (rlogin, rsh, etc.) haciendonos pasar por "trusted hosts".
- TCP Wrappers que se basen en nombres de hosts para cortar el paso.
Conclusión.
El protocolo DNS es sensible a ataques de este tipo, y probablemente existen muchas más vulnerabilidades.
El primer ataque seria evitable si se usase un protocolo de transporte como TCP, con números de sequencia
"aleatorios" o bien usando QueryIDs tambien más o menos aleatorios.
La segunda vulnerabilidad es ya inherente al protocolo DNS, y necesitaria de una profunda revisión de la
especificación de DNS para controlar que las respuestas se correspondan con lo que hemos preguntado.
No se olviden de leer la RFC 1536
Puesta en practica del metodo B
Vamos a suponer que ya tenemos lo que necesitabamos, un host que sea NS primario de un dominio y otro host
donde haremos correr nuesto programa "inyector" de informacion falsa DNS.
Vamos a suponer esta situacion:
- Nameserver primario: ns.zc.com
- Host que corre el inyector: 134.134.134.134.
Voy a exponer aqui cual serian las modificaciones a hacer a la configuracion del demonio DNS suponiendo que este
es el "named", el que con mas probabilidad vais a encontrar en un server un*x.
Lo primero que hacemos es consultar en el fichero de configuracion del named donde almacena la informacion de
los dominios que sirve. Este fichero es el /etc/named.boot o en las nuevas versiones de bind es /etc/named.conf y
se ha modificado un poco la estructura del fichero, en cuyo caso vas a tener que adaptar las explicaciones que de
aqui un poco). En nuestro ejemplo, contiene lo siguiente:
directory /var/named
cache . root.cache
primary zc.com db.zc.com
secondary castor.org db.castor.org
Esto significa: directory /var/named : Directorio base donde almacena los ficheros de
configuracion de los dominios primary zc.com db.zc.com : Es un NS primario del dominio zc.com, y lo
almacena en el fichero db.zc.com (El que nos interesa) secondary castor.org : Es Ns secundario del dominio
castor.org, y lo almacena en el fichero db.castor.org (Este no nos interesa)
Miramos al fichero db.zc.com (que como sabemos, estara en /var/named):
zc.com. IN SOA ns.zc.com. root.zc.com. (
1997062100
28800
7200
604800
86400)
zc.com. IN NS ns.zc.com.
localhost IN A 127.0.0.1
XXX IN A 10.0.0.1
owned.zc.com. IN A 10.0.0.2
Las primeras lineas se refieren a la configuracion del dominio, quien lo gestiona, las fechas de expiracion, etc.
A continuacion esta la configuracion de los Nameservers del dominio:
zc.com. IN NS ns.zc.com.
En esta linea se especifica que el host "ns.zc.com" sirve al dominio zc.com.
Aqui es donde vamos a hacer la modificacion. Tenemos que insertar una linea en que se reconozca a nuestro host
inyector como nameserver de este dominio. A la derecha de un IN NS solo se acepta un FQDN, es decir, no
podemos poner una ip numérica. Asi que vamos a tener que crear un host y luego asignarle una IP. La primera
modificacion quedaria asi con lo que hemos supuesto antes:
zc.com. IN NS ns.zc.com.
zc.com. IN NS ns1.zc.com.
Ahora vamos que tener que asignarle la IP a este host nuevo que hemos creado (ns1.zc.com). Para asignar una IP
numerica a un FQDN, se usa el RR "IN A", tal como se puede ver en las siguientes lineas:
XXX IN A 10.0.0.1
owned.zc.com. IN A 10.0.0.2
La segunda linea, asigna la IP 10.0.0.2 al FQDN owned.zc.com. El punto al final de owned.zc.com. es muy
importante, ya que si no le ponemos punto (como a XXX) el named le pone al final el nombre del dominio (zc.com).
Asi, para insertar la linea que queremos, y segun lo que hemos supuesto antes, utilizariamos esta linea:
ns1.zc.com. IN A 134.134.134.134.
Asi ya tenemos el named configurado para el spoof. Solo nos queda recargar esta informacion en el named (killall
-HUP named), esperar a que la informacion se propague y poner a trabajar el programa inyector.
