Servidores DNS Raíz bajo ataque - Root DNS servers under attack

Leyendo algunos mails pendientes me encontré con una de los boletines de SANS que reportaba un ataque de DDOS a los servidores de nombre raíz. Efectivamente, entre el 30 de Noviembre y el 1 de Diciembre último, los servidores raíz fueron víctimas de un número inusual de consultas DNS.

Estos servidores mantienen la zona raíz, donde comienzan todas las consultas DNS recursivas y por lo tanto el correcto funcionamiento de estos servidores es crucial para la salud de Internet.

Podemos obtener la lista de servidores DNS raíz con una simple consulta desde la consola:

juan@juan-VirtualBox:~$ dig +short -t NS .
i.root-servers.net.
j.root-servers.net.
k.root-servers.net.
d.root-servers.net.
e.root-servers.net.
l.root-servers.net.
a.root-servers.net.
h.root-servers.net.
m.root-servers.net.
f.root-servers.net.
c.root-servers.net.
b.root-servers.net.
g.root-servers.net.
juan@juan-VirtualBox:~$

a partir de los nombres queda claro que cada uno de los servidores raíz se identifica por una letra en el abecedario. De momento hay servidores de la A a la M (13 servidores). Vale aclarar que en realidad detrás de cada uno de estos nombres hay en realidad muchas instancias del servidor respondiendo. Según Wikipedia a Octubre de 2014 había unos 504 servidores reales respondiendo consultas.

Horarios del ataque

 

• El primer ataque comenzó a las 06:50 UTC del 30 de Noviembre y se extendió  hasta aproximadamente las 09:30 UTC.
• El segundo ataque inició a las 05:10 UTC del 1 de Diciembre y se extendió hasta casi las 06:10 UTC.

Algunos sitios indican, erróneamente, que se trató de un ataque de amplificación y reflexión, sin embargo no parece haberlo sido. Según detalla la propia gente de www.root-servers.org en su informe, el ataque tuvo las siguientes características:

• Durante el primer ataque, las consultas eran sobre un único dominio.
• Durante el segundo ataque, las consultas involucraban diferentes dominios.
• Buena parte de la flota de servidores recibieron este número excesivo de consultas, aunque no todos. Posiblemente por la naturaleza anycast de las direcciones IP de los servidores raíz. 
• Extrañamente las direcciones origen de las consultas DNS parecían estar distribuidas aleatoriamente dentro del espacio de direcciones IPv4.
• El pico máximo de consultas fue de alrededor de 5 millones de consultas por servidor raíz. 

Impacto

Afortunadamente el impacto del ataque fue casi nulo. Si confirmaron que algunos de los enlaces que conectan a los servidores raíz se vieron saturados, lo cual generó algunos retardos en las resoluciones destinadas a estos servidores. Una vez mas la robustez del mecanismo de anycast y la simplicidad de UDP mostraron ser un muy buena arquitectura para uno de los servicios mas críticos de Internet.

I hunt sys admins... yo no, la NSA!

Acá les traigo un nota de zdnet que habla de como la NSA utiliza los administradores de sistemas como puerta de acceso a las redes de su interés. En esencia todo se trata de como lo llaman ellos SIGINT, recabar información a partir de la interceptación  de comunicaciones, información que luego procesan y asocian a otras para en definitiva utilizarla como entrada a sistemas como DISCOROUTE y QUANTUM.

Estos sistemas desarrollados por ellos mismos se encargan en mayor o menor medida de, a partir de la información (redes, IPs, nombres, cuentas de correo, configuraciones de routers, etc), proporcionar acceso a las terminales de los Sys admins que administran las redes objetivo. Una vez conseguido el acceso los chicos de CNE (Compute Network Exploitation) toman la posta y... el resto es cuento conocido. Parece ficción, ¿cierto?

Para quienes quieran profundizar y ver que NO se trata de ficción, The Intercept publicó el texto de donde se escribió la nota. Una lectura recomendada sin dudas!

Me gustaría rescatar unos puntos particulares que vi en el texto:

• La NSA no solo recolecta la información que sabe que le servirá para determinada actividad en el corto plazo, sino que recolecta mucha mas información aún, información que luego podría ser eventualmente útil. Este proceso por el cual recolectan volúmenes increíbles de información lo llaman SIGINT.
• Los Sysadmin no somos el objetivo de la NSA, al menos no en la mayoría de los casos, sino simplemente son quienes tienen acceso a las redes de comunicación en las cuales están interesados. NSA -Nada personal sysadmins...
• Cuentan con herramientas muy interesantes como QUANTUM a partir de la cual con una determinada entrada de información pueden ganar acceso sencillamente (en la mayoria de los casos) los puestos de trabajo de los Sysadmins. 
• Otra herramienta que parece aún tener éxito es DISCOROUTE, con la cual obtienen información de los routers de una red a través del uso del conocido " y aun no extinto y no se porque" Telnet. Si... al parecer aún quedan Telnets dando vuelta por la basta Internet.
• Mencionan también cómo identifican los Sysadmins a través de conexiones SSH, aclaran que si bien no pueden interpretar (será que no?) el contenido de una comunicación de este tipo, si pueden reconocer sesiones SSH exitosas y NO exitosas. Esto parece complicado, pero de hecho no lo es, una sesión SSH fallida tiene un intercambio de paquetes muy limitado y corto, por lo tanto consideran una sesión exitosa (de sysadmin) a toda aquella sesión SSH que tenga una longitud mayor a la de una sesión fallida.

De estos puntos me parece que una buena parte se pueden tratar fácilmente.

• No conozco un buen motivo para que los routers tengan IPs públicas. Si fuese posible que se administraran por IPs privadas no sería tan sencillo accederlos desde el exterior.
• Las estaciones de trabajo de los administradores. Lo mismo que los routers, si tuviesen IPs privadas no podrían ser accedidas desde Internet directamente.
• Telnet, Why in the world would you use it??? Calculo que el principal motivo por el que aún se usan es porque los equipos mas viejos no soportan protocolos seguros como SSH. De vuelta, se podría subsanar utilizando por ejemplo VPNs.

Alguna otra reflexión???

Protegiendo nuestro servidor con fail2ban - Parte 1 "Protegiendo SSH"

Hoy les traigo una aplicación muy interesante que nos ayudará a proteger nuestro servidor. Es un hecho que si nuestro servidor está en internet, se encuentra expuesto todo el tiempo a un sin número de robots que buscan huecos por donde colarse (desde scanners de sitios web, hasta ataques de diccionario a cuentas de usuarios). Esta aplicación se llama Fail2ban.

El funcionamiento de Fail2ban es muy sencillo y se puede resumir en los siguientes pasos:

1-Lectura de logs y comparación con expresiones regulares

2-Aplicación de una acción por un tiempo determinado

3-Remoción de la acción una vez pasado el tiempo

Entonces se puede decir que Fail2ban nos presenta una forma sencilla de detectar patrones en los logs y tomar acciones en consecuencia, acciones que luego pueden ser revertidas. Estas acciones pueden ser desde aplicar reglas en el firewall, enviar un correo electrónico, reiniciar un servicio, lo que sea que precisen.

En esta "Parte 1" vamos a ver cómo instalarlo y configurarlo para proteger nuestro servidor de ataques de diccionario al servicio SSH.

La instalación es sencilla ya que se encuentra en los repositorios de prácticamente cualquier distro, en este caso usamos Ubuntu 12.04.4 LTS

root@ubuntu:~# apt-get install -y fail2ban

Una vez instalado podemos ver los archivos de configuración ubicados en /etc/fail2ban

root@ubuntu:~# ls /etc/fail2ban/

action.d  fail2ban.conf  filter.d  jail.conf

root@ubuntu:~# 

fail2ban.conf: contiene los parámetros generales de configuración del servicio, como las opciones de logging.

jail.conf: aquí es donde definiremos las jaulas (jails) que fail2ban procesará. El archivo se encuetra divido en la etiqueta [DEFAULT] que contiene variables generales que aplican a todas las jails y luego una etiqueta del tipo [JAIL_NAME] por cada jail creada. Una jail está compuesta mínimamente por las variables enabled, port, filter y logpath, además se puede sobreescribir las variables del tag [DEFAULT] para personalizar aún mas la jaula. 

action.d: en este directorio se encuentran los archivos que definen las acciones disponibles a tomar dentro de las jails.

filter.d: en este directorio se encuentran los filtros disponibles para utilizar en las jails.

El jail que utilizaremos es el llamado ssh, cuya configuración es:

[ssh]

enabled  = true

port     = ssh

filter   = sshd

logpath  = /var/log/auth.log

maxretry = 6

enabled: nos permite activar y desactivar el jail de manera sencilla, solo admite el valore true o false.

port: indica el puerto del servicio que se está queriendo proteger, en este caso ssh es luego reemplazado por 22.

filter: define el archivo (dentro de /etc/fail2ban/filter.d) que contendrá las expresiones regulares que se utilizaran para esta jaula. Las expresiones regulares nos permitiran definir qué tipo de logs serán una detección positiva de un problemas (failregex) y cuales no (ignoreregex).

logpath: esta variable indica el archivo de donde se leerán los logs a analizar. Ubuntu envía los logs de autenticación al archivo /var/log/auth.log, por lo tanto es el archivo indicado.

maxretry: indica la cantidad de veces que se aceptarán coincidencias en las expresiones regulares de la jaula, cuando este límite se alcanza, dentro del margen de tiempo (variable XXX) se ejecutará la acción definida para la jaula (en este caso XXX).

Como se podrán imaginar nos faltan algunas cosas, si recuerdan uno de los pasos del funcionamiento de fail2ban consistía en ejecutar una acción y en este jail no vemos nada de esto. Esto se debe a que estamos utilizando la acción poder defecto provista por el tag [DEFAULT], esta acción se encargará de insertar en el firewall una regla que denegará el acceso a puerto SSH a la IP que haga un número excesivo de intentos de acceso fallidos. Cuál es el número excesivo? 6, como indica la variable maxretry de la jail ssh. Otro valor interesante y que no se encuentra especificado entre los valores default, es el intervalo de tiempo que se analizará. Este intervalo está definido por la variable findtime (valor por defecto 600 segundos), de esta forma podemos indicarle al jail que busque intentos fallidos de logs en los últimos 600 segundos (10 minutos) y que si encuentra mas de 6 de una misma IP aplique la acción default.

Antes de comenzar a probar el funcionamiento reiniciemos el servicio para corroborar que esté todo funcionando correctamente:

root@ubuntu:/home/juan# service fail2ban restart
 * Restarting authentication failure monitor fail2ban                    [ OK ] 
root@ubuntu:/home/juan# 

Excelente! Ahora podemos ver que fail2ban agregó una nueva cadena a iptables:

root@ubuntu:/home/juan# iptables-save 
# Generated by iptables-save v1.4.12 on Thu Mar  6 05:10:23 2014
*filter
:INPUT ACCEPT [41:3079]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [23:2444]
:fail2ban-ssh - [0:0]
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh
-A fail2ban-ssh -j RETURN
COMMIT
# Completed on Thu Mar  6 05:10:23 2014
root@ubuntu:/home/juan#

fail2ban-ssh es la cadena correspondiente al jail ssh y es donde se insertarán las IPs que sean detectadas como peligrosas por el jail.

No mas teoría xD, probemos si realmente funciona (recuerden que no hemos cambiado absolútamente nada en el archivo jail.conf). Nuestro escenario de prueba consiste en las IPs:

172.16.62.149 - servidor a proteger ubuntu
172.16.62.1 - atacante moon

Supongamos que el atacante ya hizo un escaneo previo de la red y encontró varias direcciones IP con el servicio SSH escuchando en el puerto 22. Una de esas direcciones es nuestro servidor, asumiendo que los usuarios suelen usar contraseñas débiles, el paso siguiente sería comenzar a probar pares usuario/contraseña hasta que eventualmente adivine alguno y consiga acceso.

Simulamos un robot haciendo 6 intentos fallidos de autenticación de la siguiente manera:

juan@moon:~$ ssh pepe@172.16.62.149
pepe@172.16.62.149's password: 
Permission denied, please try again.
pepe@172.16.62.149's password: 
Permission denied, please try again.
pepe@172.16.62.149's password: 
Permission denied (publickey,password).
juan@moon:~$ ssh pepe@172.16.62.149
pepe@172.16.62.149's password: 
Permission denied, please try again.
pepe@172.16.62.149's password: 
Permission denied, please try again.
pepe@172.16.62.149's password: 
Connection closed by 172.16.62.149
juan@moon:~$ 

como pueden ver, luego del sexto intento fallido hemos perdido acceso al puerto 22.
Desde el servidor podemos ver claramente la nueva regla que fue agregada a iptables:

root@ubuntu:/home/juan# iptables-save 
# Generated by iptables-save v1.4.12 on Thu Mar  6 05:10:23 2014
*filter
:INPUT ACCEPT [41:3079]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [23:2444]
:fail2ban-ssh - [0:0]
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh
-A fail2ban-ssh -s 172.16.62.1/32 -j DROP
-A fail2ban-ssh -j RETURN
COMMIT
# Completed on Thu Mar  6 05:10:23 2014
root@ubuntu:/home/juan#

la regla descarta expecíficamente los paquetes de origen 172.16.62.1 que se dirijen al puerto 22. La forma correcta de ver en qué estado se encuentra una jail en particular es la siguiente:

root@ubuntu:/home/juan# fail2ban-client status ssh
Status for the jail: ssh
|- filter
|  |- File list: /var/log/auth.log 
|  |- Currently failed: 1
|  `- Total failed: 7
`- action
   |- Currently banned: 1
   |  `- IP list: 172.16.62.1
   `- Total banned: 1
root@ubuntu:/home/juan# 

Bien, funciona!! pero qué sucedió?

Escencialmente lo que sucedió fue lo siguiente:

-La jail ssh estaba pendiente de los logs que se escribían en /var/log/auth.log
-En un momento determinado detecto que en los últimos 5 minutos alguien había realizado al menos 6 intentos fallidos de login al servidor. Esto lo podemos ver fácilmente acá:

root@ubuntu:/home/juan# cat /var/log/auth.log |grep "Failed password"
Mar  6 04:39:26 ubuntu sshd[976]: Failed password for juan from 172.16.62.1 port 37492 ssh2
Mar  6 05:13:28 ubuntu sshd[1514]: Failed password for invalid user pepe from 172.16.62.1 port 37539 ssh2
Mar  6 05:13:31 ubuntu sshd[1514]: Failed password for invalid user pepe from 172.16.62.1 port 37539 ssh2
Mar  6 05:13:35 ubuntu sshd[1514]: Failed password for invalid user pepe from 172.16.62.1 port 37539 ssh2
Mar  6 05:13:40 ubuntu sshd[1516]: Failed password for invalid user pepe from 172.16.62.1 port 37542 ssh2
Mar  6 05:13:43 ubuntu sshd[1516]: Failed password for invalid user pepe from 172.16.62.1 port 37542 ssh2
root@ubuntu:/home/juan# 

-Aplicó la acción correspondiente a la jail, esto lo podemos ver en el archivo de logs de fail2ban (/var/log/fail2ban.log)

...

2014-03-06 05:13:42,764 fail2ban.actions: WARNING [ssh] Ban 172.16.62.1

...

-Diez minutos después fail2ban quita la regla del firewall y todo vuelve a la normalidad

...

2014-03-06 05:23:43,610 fail2ban.actions: WARNING [ssh] Unban 172.16.62.1

...

Como verán, su funcionamiento es sencillo. Si abren el archivo /etc/fail2ban/filter.d/sshd.conf podrán ver las distintas expresiones regulares que serán consideradas como ataques,  una de ellas es:


 ^%(__prefix_line)sFailed (?:password|publickey) for .* from (?: port \d*)?(?: ssh\d*)?$

Algunas consideraciones sobre esta implementación:

-Frena a los atacantes por solo 10 minutos (se podría incrementar este valor sin complicaciones), lo cual a veces es mas que suficiente para engañar a los robots y hacerles creer que el host se apagó y que no deberían perder tiempo intentando.
-No protege a usuarios con claves triviales como usuario juan y password juan, y demás cosas que pueden ser adivinadas en unos pocos intentos.

Recomendaciones:

-Si administras servidores utilizando SSH, usa un par de claves pub/priv en lugar de contraseña.
-No permitir el acceso de root por SSH.

Veremos que se me ocurre para la parte 2!!! Saludos!

TA13-088A: DNS Amplification Attacks

Hace un par de días recibí un correo de US-CERT con el título "TA13-088A: DNS Amplification Attacks" y me llamó poderosamente la atención que esto siga siendo un problema en la red.

Según el último análisis hecho por la gente de Open Resolver Project (http://openresolverproject.org/ 2013-06-30):


35086838 servers responded to udp/53 probe
30085246 gave the correct answer to the A? for the DNS name queried
30556493 responses had recursion-available bit set


Es decir que existen alrededor de 35 millones de servidores DNS, de los cuales 30 millones responderían consultas recursivas, esto es aproximadamente el 87% del total (bastante, no?). 

A ver..., a priori tener un servidor DNS que responde consultas recursivas no es un pecado capital, de hecho es una gran funcionalidad en casos como el de la siguiente figura:

Un DNS recursivo brinda una serie de ventajas:

• Permite que las aplicaciones no tengan que cargar con el proceso de resolución de nombres.
• Definir políticas en cuanto al acceso a determinados dominios.
• En el caso de tener un firewall principal que controle el tráfico entrante y saliente de la organización, solo sería necesario abrir el puerto 53 (UDP/TCP) para el servidor de DNS y no para todas las IPs.
• Por lo general los servidores recursivos además son servidores cache, es decir que guardan las respuestas obtenidas por un plazo de tiempo, esto implica reducciones de tiempo y de consumo de ancho de banda.

Entonces cuál es el problema con tener un DNS recursivo?

El problema radica principalmente en la capacidad de un atacante de falsificar la dirección IP de origen (conocido como IP spoofing) en una consulta de dns. Sumado a esto, las consultas DNS tienen una particularidad muy interesante y util en este contexto:

Las respuestas suelen ser mucho mas grandes que las preguntas.

Por ejemplo, una consulta sencilla donde solo queremos los registros NS que corresponden a la raíz del servicio de nombres:


juan@moon:~$ dig -t ns .

; <<>> DiG 9.7.3 <<>> -t ns .
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- 43559="" font="" id:="" noerror="" opcode:="" query="" status:="">
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 15

;; QUESTION SECTION:
;.                              IN      NS

;; ANSWER SECTION:
.                       194627  IN      NS      i.root-servers.net.
.                       194627  IN      NS      j.root-servers.net.
.                       194627  IN      NS      m.root-servers.net.
.                       194627  IN      NS      g.root-servers.net.
.                       194627  IN      NS      k.root-servers.net.
.                       194627  IN      NS      b.root-servers.net.
.                       194627  IN      NS      e.root-servers.net.
.                       194627  IN      NS      l.root-servers.net.
.                       194627  IN      NS      c.root-servers.net.
.                       194627  IN      NS      h.root-servers.net.
.                       194627  IN      NS      f.root-servers.net.
.                       194627  IN      NS      a.root-servers.net.
.                       194627  IN      NS      d.root-servers.net.

;; ADDITIONAL SECTION:
j.root-servers.net.     603710  IN      A       192.58.128.30
m.root-servers.net.     198503  IN      A       202.12.27.33
m.root-servers.net.     254964  IN      AAAA    2001:dc3::35
g.root-servers.net.     603710  IN      A       192.112.36.4
k.root-servers.net.     603710  IN      A       193.0.14.129
b.root-servers.net.     603710  IN      A       192.228.79.201
e.root-servers.net.     603497  IN      A       192.203.230.10
l.root-servers.net.     601827  IN      A       199.7.83.42
l.root-servers.net.     601827  IN      AAAA    2001:500:3::42
c.root-servers.net.     603710  IN      A       192.33.4.12
h.root-servers.net.     603710  IN      A       128.63.2.53
f.root-servers.net.     603710  IN      A       192.5.5.241
a.root-servers.net.     442939  IN      A       198.41.0.4
a.root-servers.net.     599900  IN      AAAA    2001:503:ba3e::2:30
d.root-servers.net.     603710  IN      A       199.7.91.13

;; Query time: 24 msec
;; SERVER: 200.49.130.47#53(200.49.130.47)
;; WHEN: Sun Jul  7 00:25:00 2013
;; MSG SIZE  rcvd: 504

juan@moon:~$ 

Capturando con wireshark la consulta anterior vemos:

La respuesta es casi 10 veces mas grande que la pregunta (podrían existir casos aún peores, pruebe con dig -t ANY . @8.8.8.8 ... 1600 bytes!). Esta particularidad hace al protocolo DNS una potencial herramienta de denegación de servicio muuuuy interesante. 

Si extrapolamos un poco los números:

• Digamos que podemos hacer 10 consultas por segundo, eso serían 590 bytes, recibiríamos 5460 bytes en respuestas.
• Digamos que podemos hacer 100 consultas por segundo, eso serían 5900 bytes en consultas y unos 54600 bytes en respuestas.

Dificilmente logremos realizar una DoS realizando 100 consultas por segundo... la amenaza está realmente en el trabajo en equipo, es decir en las Botnets. 

Si un atacante contara con una botnet pequeña de unos 2000 equipos infectados generando unas 10 consultas por segundo, podría generar un bruto de 10920000 (5000*10*546) bytes, aproximadamente 10 Gbytes de tráfico en respuestas!!! Pero todavía queda algo por arreglar, claramente no podríamos exigirle este tráfico a un solo servidor DNS... necesitamos poder distribuir las consultas en mas de un servidor; pero eso no debería ser un impedimento según la gente de OpenResolvers.org, ya que hay millones de servidores DNS recursivos abiertos.

Ahora supongamos que además, el atacante es capaz de cambiar la IP de origen con que salen las consultas DNS de cada uno de los miembros de la botnet, por la IP de la víctima... eso significaría que estos 10 Gbytes estarían volviendo no a los nodos de la botnet sino a la IP víctima, colapsando así su ancho de banda y produciendo una denegación de servicio.

Cómo evitarlo?
Evitar denegaciones de servicio no es un tema sencillo y en la mayoría de los casos lo mejor que podamos hacer solamente reducirá el riesgo de sufrir una o disminuirá un poco su impacto.

Las siguiente medidas son de ayuda:

• Deshabilitar las consultas recursivas en los servidores que no las precisen, por ejemplo aquellos servidores que solo son autoritativos.
• Si las consultas recursivas son necesarias, se pueden tomar dos medidas: limitar la funcionalidad a un número acotado de IPs o limitar la cantidad de consultas por segundo permitidas.
• Verificación de direcciones IP, los ISP deberían combatir el IP spoofing, aca va un RFC que presenta una solución a este problema http://tools.ietf.org/html/bcp38 .

Cómo saber si mi servidor de DNS es vulnerable?

Una buena herramienta para ver si nuestros servidores son vulnerables es la siguiente http://www.dnsinspect.com/ . Con solo introducir nuestro nombre de dominio la aplicación hace una serie de pruebas a los servidores DNS declarados de la zona y prepara un breve informe. Este contiene los resultados de las pruebas junto con una serie de advertencias, sugerencias/recomendaciones para aplicar sobre las configuraciones de los mismos.

Cuántos somos en esta red???

mmm un poco falto inspiración últimamente, terminando los parciales (o no, no estoy muy seguro xD). Hoy me entró la necesidad de poder saber al "instante" la totalidad de hosts conectados a una LAN, (que necesidades las mías xD).
Lo primero que me vino a la mente fue hacer un ping a cada host de la red, pero cabe la posibilidad de que los hosts no respondan las ECHO-Request ICMP, entonces me estaría perdiendo alguno que otro. Entonces lo mas recomendable me pareció ser utilizar ARP (Address Resolution Protocol), protocolo esencial en las redes LAN para traducir las direcciones de red (IP en este caso) a direcciones de capa de enlace (Ethernet MAC address en este caso).

Cabe aclarar que las comunicaciones entre hosts que pertenecen a un mismo segmento LAN se realiza mediante direcciones MAC, las direcciones IP realmente se utilizan cuando los hosts se encuentran en diferentes redes.

Volviendo al tema... buscando alguna aplicación que sea útil para esta tarea me encontré inicialmente con "arping" (parte del paquete iputils), que justamente nos permite crear paquetes ARP.

Primero aproximación con arping:
Podemos ver que el host 192.168.0.1 está activo y respondió a la primer consulta, entonces no fue necesario enviar mas. "-f deja de enviar ni bien recibe una respuesta" "-c 2 máximo de consultas".

root@moon:/home/juan# arping -f -c 2 -I eth0 192.168.0.1
ARPING 192.168.0.1 from 192.168.0.36 eth0
Unicast reply from 192.168.0.1 [00:08:54:29:06:__]  0.876ms
Sent 1 probes (1 broadcast(s))
Received 1 response(s)

Definitivamente esto no es lo que queria, tener que repetir el comando mas de 200 veces para recorrer todo la red C no está en mis planes, si bien podría hacerse con un script, no me interesa.

Buscando un poco mas encontré a don "arp-scan", el nombre es bastante explícito xD. Es bastante mas flexible que arping y nos permite realizar consultas a un rango de direcciones, una única dirección, o toda la red. El man de arp-scan es un poco rebuscado, pero se deja leer :D.

Probando arp-scan:
Ahora si!, escaneamos un rango de direcciones de la red, desde 192.168.0.1 a 192.168.0.48 y nos encontramos con 4 hosts activos!

root@moon:/home/juan# arp-scan -I eth0 -q -r 1 192.168.0.1-192.168.0.48
Interface: eth0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.6 with 48 hosts (http://www.nta-monitor.com/tools/arp-scan/)
192.168.0.1    00:08:54:29:06:__   
192.168.0.10    00:27:19:dc:d7:__   
192.168.0.20    00:e0:4c:a8:89:__   
192.168.0.26    00:19:66:38:0a:__   

4 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.6: 48 hosts scanned in 0.539 seconds (89.05 hosts/sec).  4 responded

Logré lo que pretendía, pero claramente se enviaron 48 ARP-Request con mi dirección IP como origen de la consulta. Que a dónde voy?, simple, si se trata de nuestra red no hay problema, nadie va a quejarse al ver tanto interés por parte de una dirección por conocer a todos los hosts activos, pero si no se trata de nuestra red? en el último caso sería muy interesante poder evitar que nuestra dirección de red y nuestra MAC se incluyeran en las consultas :D. Claro que si!!!, arp-scan nos permite alterar los campos del paquete ARP para lograr esto :D.

Arp-scan e IP spoof:
Acá va el primer intento por anonimizar (existe?) las consultas. "-s 192.168.0.45" es la dirección que figurará como origen en la consulta, ahora ya no ponemos en juego nuestra dirección IP real! pero claro xD, aún enviamos nuestra dirección MAC original, es decir que aún somos un blanco fácil...

root@moon:/home/juan# arp-scan -I eth0 -r 1 -q -s 192.168.0.45 192.168.0.1-192.168.0.48
Interface: eth0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.6 with 48 hosts (http://www.nta-monitor.com/tools/arp-scan/)
192.168.0.1    00:08:54:29:06:_   
192.168.0.10    00:27:19:dc:d7:_   
192.168.0.20    00:e0:4c:a8:89:_   
192.168.0.26    00:19:66:38:0a:_   

4 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.6: 48 hosts scanned in 0.465 seconds (103.23 hosts/sec).  4 responded
root@moon:/home/juan#

Arp-scan e IP spoof + MAC spoof V1:
El primer intento fue ir directamente a lo fácil y alterar todos los campos utilizando arp-scan, pero mi sorpresa fue estaa... Al cambiar tanto la dirección mac (de la consulta, como la que va dentro del paquete) como la dirección IP de origen, las respuestas no son capturadas correctamente por arp-scan (puede verificarse con wireshark (por ejemplo) que las consultas y respuestas se completan perfectamente) y podríamos creer que el host no está activo (192.168.0.1 está activo, aunque no lo parezca). Si bien es totalmente factible corroborar los hosts activos viendo las respuestas desde wireshark, estaríamos complicando mas el panorama, y esa jamás fue la idea :D.

root@moon:/home/juan# arp-scan -I eth0 -r 1 -q -S 00:11:22:33:44:55 -u 00:11:22:33:44:55 -s 192.168.0.45 192.168.0.1
Interface: eth0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.6 with 1 hosts (http://www.nta-monitor.com/tools/arp-scan/)

0 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.6: 1 hosts scanned in 0.347 seconds (2.88 hosts/sec).  0 responded
root@moon:/home/juan#

Arp-scan e IP spoof + MAC spoof V2:
En esta versión primero cambiamos la dirección MAC de nuestro adaptador de red, utilizando macchanger (a decir verdad no es necesario utilizarlo, puede hacerse tranquilamente con ifconfig) y luego lanzamos nuestro querido arp-scan, para encontrarnos finalmente con los hosts activos, pero esta vez ocultando completamente nuestra identidad dentro de la red.

root@moon:/home/juan# macchanger -m 00:11:22:33:44:55 eth0
Current MAC: 00:24:21:6d:00:36 (unknown)
Faked MAC:   00:11:22:33:44:55 (Cimsys Inc)
root@moon:/home/juan# arp-scan -I eth0 -r 1 -q -S 00:11:22:33:44:55 -u 00:11:22:33:44:55 -s 192.168.0.45 192.168.0.1-192.168.0.48
Interface: eth0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.6 with 48 hosts (http://www.nta-monitor.com/tools/arp-scan/)
192.168.0.1    00:08:54:29:06:__   
192.168.0.10    00:27:19:dc:d7:__   
192.168.0.20    00:e0:4c:a8:89:__   
192.168.0.26    00:19:66:38:0a:__   

4 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.6: 48 hosts scanned in 0.476 seconds (100.84 hosts/sec).  4 responded
root@moon:/home/juan#

Algunas consideraciones:
-"Arp-scan e IP spoof" aunque parezca que fuimos cuidadosos no lo fuimos, wireshark detectó que una dirección MAC estaba asociada a dos direcciones de red, la dirección actual y la dirección falsa, esto podría haber disparado alarmas en alguno de los hosts y haber alertado al administrador.
-Podría darse el caso donde la IP que elijamos para ocultarnos ya esté asignada en la red, seria interesante elegir una dirección que difícilmente esté en uso, para evitar conflictos de direcciones que puedan alarmar a los usuarios de los hosts o el administrador mismo.
-Si si, esto es la previa para un ataque MITM (hombre en el medio), posiblemente en la próxima entrada :D.
-arping no me permitió utilizar una dirección que no fuese la que tiene asignada la interface eth0, un poco de mal gusto xD.
-Había pensado en una mas, pero se me acaba de olvidar :D.

Ahora si que me bajó el sueño!

Pequeeeeña intro MDNS (Multicast DNS):

Hoy (01/04/2010), mientras preparaba la próxima entrada del blog "casualmente" tenía wireshark corriendo y me encontré con un paquete que me llamó poderosamente la atención. El protocolo es MDNS, lo había visto antes pero siempre creí que se trataba de alguna de las aplicaciones que estaba corriendo.

Intro:

Googleando un poco encontré de que se trata: "Multicast DNS is a way of using familiar DNS programming interfaces, packet formats and operating semantics, in a small network where no conventional DNS server has been installed." (http://www.multicastdns.org/). Es decir, se trata de una implementación del protocolo de resolución de nombres (DNS) para redes de área local, donde no existe un servidor DNS real. Producto de los grupos Zero Configuration Networking y DNS Extensions, creado con el objetivo de facilitar la configuración de redes locales que no cuentan con un servidor de nombres propio.

Según el draft (http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt) "Clients performing DNS-like queries for DNS-like resource records by sending DNS-like UDP query and response packets over IP Multicast to UDP port 5353." se trata de clientes realizando consultas tipo DNS por registros tipo DNS enviando paquetes (tipo DNS) al puerto 5353 UDP  sobre direcciones IP Multicast (JA!, para los que creen que las clase D no se usan jajaaj).

Las direcciones Multicast o clase D van de 224.0.0.0 a 239.255.255.255, y se caracterizan por: una dirección Multicast está asociada con un grupo de receptores interesados, cuando uno de los interesados envía un paquete a una dirección Multicast todos los demás lo reciben, los routers que se encuentren entre estos interesados deben ser capaces de reenviar estos paquetes a cada uno de ellos.

Al tratarse de una dirección Multicast, todos los asociados reciben todos los paquetes, y de esta manera las caches de nombres se mantienen actualizadas. Cada respuesta a una consulta Multicast DNS trae un campo donde se especifica el tiempo de validez que tiene la respuesta, luego de que expire ese tiempo es necesario volver a efectuar la consulta.

Este servicio de DNS cuenta también con un TLD (Top-Level Domain) propio y es ".local.". Todo FQDN (Fully Qualified Domain Name, nombre completo xD) que finalice con ".local." se lo considera de enlace local, es decir... es un análogo a las direcciones IP privadas, que sólo valen en el ámbito local de la red y de nada sirven fuera de ella. Toda consulta DNS que finalice con ".local." debe ser enviada a la dirección 224.0.0.251 (si se trata de IPv4, o FF02::FB si se trata de IPv6).

Existen 3 tipo de consultas: las consultas convencionales 1-consulta->1-respuesta, 1-consulta->N-respuestas y el ultimo tipo que consiste en consultas continuas.

En fin... eso es mas o menos a modo de introducción :D. Si realmente querés saber mas, está el link del borrador mas arriba, de ahora en mas voy a intentar controlar/activar/desactivar este servicio de mi laptop. Resulta ser que en la mayoría de las distribuciones de GNU/Linux viene instalado por defecto un servicio que implementa este protocolo, y se llama Avahi (http://avahi.org/). Avahi es capaz de publicar y descubrir dispositivos, y servicios disponibles en la red local, sin necesidad de realizar configuración alguna.

Veamos si el servicio está corriendo :D  (hagamos de cuenta que nunca vi el paquete con wireshark xD):
"Lo sospeché desde un principio..." asi es, tengo corriendo como demonio a avahi-daemon

Buscando un poco mas se puede ver que escucha en el puerto UDP 5353 de todas las interfaces disponibles, a la espera de consultas/respuestas que pueden provenir de cualquier dirección de red.

Ahora probemos la facilidad de uso de este protocolo. La lan de prueba está compuesta por 2 hosts, la laptop con direccion 192.168.206.1 (nombre moon) y una vm con dirección 192.168.206.134 (nombre ubuntu). Ambos hosts tienen instalado Ubuntu 9.10, que trae por defecto instalado avahi-daemon versión 0.6.25. Ninguno de los host recibió algún tipo de configuración de este servicio, ambos corren como fueron instalados. En el host moon estará nuestro amigo wireshark capturando los paquetes para ver lo que sucede :D.

Buscando a "ubuntu" desde "moon":

Sabemos que está conectadp a la red un host de nombre "ubuntu", pero no sabemos la dirección IP que le fue asignada, y no contamos con un servidor DNS local :D, maldita sea!, pero para eso está corriendo avahi-daemon. Para conocer la dirección de ese host nos basta con hacer un "ping ubuntu.local.", como muestra la imagen

ahora veamos lo que capturó nuestro amigo :D.
Wireshark nos muestra 4 paquetes MDNS, los dos primeros son la resolución directa del nombre de host "ubuntu.local.".
-192.168.206.1 (moon) envía una consulta MDNS a 224.0.0.251 (Multicast IP Address) preguntando por la dirección de "ubuntu.local.".
-192.168.206.134 (ubuntu) envía una respuesta MDNS a 224.0.0.251 (Multicast IP Address) diciendo que 192.168.206.134 corresponde al "host ubuntu.local.".
Los últimos dos paquetes son la resolución inversa, es decir, intenta averiguar el nombre que le corresponde a la dirección 192.168.206.134, esto debe ser una suerte de mecanismo de seguridad, para ver que sean consistentes:
-192.168.206.1 (moon) envía una consulta inversa a la dirección 224.0.0.251, consultando por el nombre que le corresponde a "134.206.168.192.in-addr.arpa.".
-192.168.206.134 (ubuntu) rsponde a la dirección 224.0.0.251, diciendo que esa dirección le corresponde al nombre "ubuntu.local.".

Exáctamente lo mismo podemos observar si ahora realizamos el ping desde ubuntu hacia moon.local.

Publicando y Descubriendo servicios:

Junto con MDNS se puede utilizar algo llamado DNS-SD (DNS-Service Discovery), que consiste en dar a conocer y encontrar servicios locales utilizando MDNS. De nuevo se trata de algo de simple puesta en marcha. Como ejemplo publicaremos dos servicios en el host de nombre moon (FQDN moon.local.), un servidor web en el puerto 80 y un ftp en el puerto 21. El proceso de publicación de los servicios consiste en crear un archivo con sintaxis XML en el directorio /etc/avahi/services/, con la condición que el nombre del archivo debe finalizar en ".service" (sin las comillas :D), como el siguiente:

Para entender bien la sintaxis basta con dar una breve leída a "man avahi.service" :D. Luego de configurar adecuadamente los servicios que querramos reiniciamos el demonio avahi con "avahi-daemon -r" y listo, toda la magia de la publicación de servicios es esa jajaja. Ahora hay que comprobar que los servicios están siendo publicados, para eso instalé dos porgramas mdns-scan y mzclient, NO instalen mdns-scan es DEMASIADO BASICO (ni siquiera recibe parámetros y solo busca types "_workstation"). Primero veamos los hosts que se encuentran utilizando MDNS ejecutamos mzclient como en la próxima imagen (-r se encarga de resolver los nombres de los hosts):

moon tiene 3 direcciones MAC diferentes porque se trata de las 3 interfaces de red, dos virtuales y la eth0 real. Entonces los hosts siguen bien configurados, ahora busquemos los servicios publicados :D. Para eso usamos la opcion -t, que indica la etiqueta type del archivo de servicios, buscamos primero si hay servicios tipo "_http._tcp", incluimos -r para que resuelva nombres:

Ahora busquemos el ftp :D:

Ambos servicios fueron asociados al nombre "moon.local" con dirección 192.168.206.1, como lo configuramos y como debe ser. Eso es gran parte de la publicación de servicios, para mas información http://avahi.org :P.

Deteniendo el demonioooooooo:

Si nos iteresa detener el demonio solo por un momento o reiniciarlo, lo podemos hacer directamente mediante el script ubicado en /etc/init.d. Ejecutamos sudo /etc/init.d/avahi-daemon stop, o mas elegantemente sudo service avahi-daemon stop, para detenerlo, cambiamos stop por restart, para reiniciarlo y start para iniciarlo cuando está detenido.

Deshabilitando temporalmente al demonio:
Si queremos deshabilitarlo temporalmente pero no borrarlo del sistema podemos recurrir a un pequeño truquillo :D. La idea básicamente consiste en que sencillamente el demonio nunca se inicie xD, y esto lo podemos lograr alterando el script de inicio del demonio, ubicado en "/etc/init/avahi-daemon.conf". Como se ve en la imagen hay que comentar la linea de "start".

En definitiva, se trata de un servicio bastante útil, pero que sinceramente no necesito tener activo en este momento. Posiblemente en una LAN donde todo el tiempo entran y salen dispositivos diferentes sea de suma utilidad, pero no lo veo tan así en una LAN chica con poco cambio de los dispositivos.

Redes IP y Subnetting

Para poder escribir sobre subnettig tengo 2 opciones: partir del supuesto que todos sabemos qué es una red IP o partir explicando qué es una red IP. Como ya terminé los parciales en la facultad (es decir, me sobra un poco de tiempo), voy a empezar por el camino mas largo xD.

Haciendo un mini repaso, sabemos que las direcciones IP están formadas por 32 bits, divididos en 4 octetos que se suelen escribir en decimal para hacer nuestra vida un poco más hermosa xD. Entonces la dirección 11000000101010000000000000000001 la expresamos como 192.168.0.1. En la figura se muestra parte del proceso.


En la siguiente imagen se ven 7 Hosts interconectados, divididos en 3 redes conectadas mediante un router. Todos los Host de una red comparten cierta parte de su dirección IP, precisamente esta parte que comparten se llama dirección de red. En el ejemplo, se ve que los Hosts de la RED 0 comparten los primeros 24 bits de sus direcciones IP, es decir, tienen como dirección de red 190.68.0.0/24. El /24 nos indica que la dirección de red está formada por los primeros 24 bist de la dirección IP, a este número se lo llama máscara de red, y suele representarse en el mismo formato que las direcciones IP, en este caso sería 255.255.255.0.


Con estos nuevos datos ya podemos saber la dirección de red de un interfase si conocemos su máscara de red, el proceso es simple. Hay que realizar la operación AND lógico entre los 32 bits de la dirección IP y los 32 bits de la máscara de red.


Resumiendo un poco todo lo dicho, ahora sabemos que una dirección IP está formada por dos partes, la dirección de red (indicada por la máscara de red) y la del Host.

Antes de olvidarme voy a hacer una aclaración; las direcciones IP se asignan a una interfaz (una interfaz es la frontera entre el Host y el enlace físico, simplificando… la placa de red) de un Host, no al Host en si mismo. ¿Qué quiero decir?, que un mismo Host puede tener mas de una interfaz (como ser el caso de los routers), aunque no sea muy común, y por eso se considera siempre el caso donde los Hosts sólo tienen una interfaz que los une a la red.

En un principio el esquema de direccionamiento IP se había organizado en 5 clases (A, B, C, D y E). Las redes de clase A cuentan con 7 bits para identificar redes y 24 bits para indicar Hosts. Las de clase B 14 bits para redes y 16 para Hosts. Las redes clase C emplean 21 bits para redes y 8 bits para Hosts. Las redes de clase D tienen un propósito especial, y las de clase E son para investigación. En el siguiente cuadro queda bien aclarado este tema de la división entre red y Host.

Este direccionamiento por clases fue pronto dejado de lado, debido a que no era muy elástico y malgastaba grandes cantidades de direcciones. Por ejemplo, una organización que tuviera 500 hosts que direccionar no podría usar una clase C, porque esta clase direcciona solamente 2^8 – 2 hosts (hay 2 direcciones que son de uso especial, las trato mas adelante), osea 254, entonces debería usar una clase B, en este caso contaría con 2^16 - 2 direcciones para sus hosts… pero esto es 65534 direcciones, de las cuales sólo usará 500… es decir malgastaría 65034 direcciones. Por este motivo se malgastaban muchas direcciones y pronto fue necesario re pensar el sistema de direccionamiento IP.

Así fue que surgió un nuevo estándar propuesto por la IETF llamado CIDR (Classless Interdomain Routing), enrutado interdominio sin clases. Con este nuevo estándar ahora las clases fueron dejadas un poco de lado, permitiendo que la longitud de la parte de red de una dirección IP pueda tener cualquier tamaño. Con CIDR nuestra organización del ejemplo ya puede obtener un bloque de direcciones más acotado (y por ende mas barato xD) con 9 bits para hosts tendríamos 2^9 – 2 = 510 direcciones disponibles, lo que es mucho mas preciso. Entonces las direcciones disponibles para la organización serán de la forma a.b.c.d/23 (donde 23 indica la máscara de red).

Otra nota importante! Existe un conjunto de direcciones IPs, llamadas direcciones privadas, que no pertenecen al grupo de direcciones asignadas en Internet o públicas. Estas se separaron para crear las redes locales y de esta forma disminuir el uso de direcciones públicas. Para que una red privada tenga acceso a Internet debe contar con una puerta de enlace que realice NAT o un servidor Proxy que contará con una dirección pública que le dará acceso a Internet a esa red privada. Aca dejo un link donde se listan las direcciones IP privadas y un poco mas de información: http://es.wikipedia.org/wiki/Direcci%C3%B3n_IP

Subnetting:

Es en este punto en el que nace el concepto de Subnetting. Subnetting es el proceso por el cual se toman bits correspondientes a hosts en la dirección IP para armar subredes. De esta forma podemos obtener a partir de una dirección de red varias subredes de menor tamaño. A partir de este momento nuestras direcciones IP tendrán 3 partes, un número de red, un número de subred y un número de Host dentro de la subred.

Veamos un ejemplo para aclarar el tema, supongamos que tenemos una dirección de red como la siguiente 192.168.2.0. Para los perdidos (o los que no leyeron el link que puse antes), esta es una dirección IP privada (NO PUEDE EXISTIR EN INTERNET), y por su formato podemos decir que es de clase C, entonces su máscara de red debe ser /24 (255.255.255.0). Sin aplicar Subnetting estamos frente a una red clase C que nos permite direccionar 2^8 – 2 hosts (interfaces en realidad, recuerden).

Voy a aprovechar para explicar el porqué del “- 2”, dentro de una red (también en las subredes) existen 2 direcciones que no se pueden asignar a una interfaz (o Host) porque son de propósito específico. Estas direcciones son la primera y la última, y se llaman dirección de red y dirección de broadcast respectivamente. La primera indica la red o subred y la última se utiliza para enviar paquetes a todos los miembros de la red o subred. En el caso de nuestro ejemplo la dirección de red es 192.168.2.0 (si!! El resultado de aplicar la máscara con el AND lógico xD) y la dirección de broadcast consiste en poner en 1 todos los bits que se usan para determinar el Host de la red o subred, en nuestro caso es el 4 octeto, entonces nos queda 192.168.2.255 como dirección de broadcast. E ahí la explicación de porque quitar dos direcciones del total, porque esas NO se pueden asignar a interfaz alguna.

Continuando con el ejemplo, ahora supongamos que tenemos una sola red con 100 computadoras repartidas en la organización. Por cierto motivo (privacidad, seguridad, desempeño, tiempo de sobra, etc.) se toma la decisión de dividir esa gran red en 2 redes más pequeñas con 50 computadoras cada una. Las llamaremos Subred Ventas, Subred RRHH. Ahora empezamos con los cálculos: dijimos que queremos armar 2 redes, entonces podríamos tomar 2 bits de los hosts para así poder armar 2^2 - 2 subredes (descartamos la primera y la última subred), es decir 2! Que precisión xD, sólo vamos a desperdiciar una (esto no estaba planeado jaja).

La siguiente imagen muestra el proceso:


De esa forma conformamos las dos redes, donde cada red tiene un espacio de direcciones para 62 interfaces.

El Subnetting se puede hacer sobre cualquier clase de redes, es decir sobre una red Clase A, B, etc. La esencia es que siempre que hagamos Subnetting vamos a obtener varias redes de menor cantidad de hosts (se disminuyen en potencia de 2 por cada bit que tomamos del campo de Host de la dirección IP). La subred entonces queda determinada por esta nueva Máscara de subred.

Como verán en una red de clase B que tenemos 14 bits que definen la red y 16 bits que definen el Host se pueden obtener buenas combinaciones para muchas subredes con muchos hosts, por ejemplo, tomando 6 bits para subredes obtendríamos 62 subredes con 1022 direcciones asignables (jeej me crees?? Probalo).

Cualquier duda, sugerencia, o consulta con respecto al tema, está MAS que bien recibida. Espero que haya expresa bien las ideas ajaja, un saludo. JJ.