Mostrando entradas con la etiqueta tcpdump. Mostrar todas las entradas
Mostrando entradas con la etiqueta tcpdump. Mostrar todas las entradas

miércoles, 11 de abril de 2018

Identificando servidores DNS IPv6 Open Resolvers

Introducción

Como muchos de ustedes saben, tener servidores DNS Open Resolvers es muy negativo, tanto para el que deja el servicio abierto como para la seguridad en Internet en general.
Este tipo de servidores se utilizan como vector de ataques de DDoS por amplificación ya que a partir de un mensaje de consulta de pequeño tamaño, se puede obtener una respuesta mucho mayor. De esta manera, ese servidor DNS se convierte en un amplificador de tráfico muy potente ya que sus consultas amplificadas pueden dirigirse a una IP específica, la cual recibiría todo ese volumen de tráfico, ocasionándole indisponibilidad de sus servicios. Para este ataque ni siquiera es necesario que el hardware esté controlado por el atacante.
Este es un problema que en WARP nos preocupa porque hemos recibido mucho reportes de incidentes relacionados a esta vulnerabilidad. Por esta razón en conjunto con el área de I+D estamos llevando a cabo un proyecto con el objetivo de conocer el estado actual de la región, identificar los open resolvers y de forma proactiva alertar y recomendar una posible corrección de la configuración de este servicio.

Identificando un DNS Open Resolvers en IPv6 (DNS abiertos)

Identificar servidores Open Resolvers o servidores DNS abiertos en el mundo de IPv4 es muy sencillo, debido a la poca longitud del espacio de IPv4 (2**32).
En el mundo de IPv6 es imposible poder verificar cada una de las direcciones IP y ejecutar una prueba de Open Resolver. Dicha prueba puede durar miles de años.

¿Cómo se identifica un DNS Open Resolver?

Un servidor DNS recursivo solo debería responder consultas (queries) a todos los clientes que se encuentren dentro de su misma red y debería rechazar cualquier otra que provenga de fuera. Por ejemplo, los servidores DNS del ISP ACME solo deberían responder a consultas de sus propios clientes, a más nadie.
La identificación se hace realizando una consulta de un nombre de dominio a los servidores DNS. En caso que el servidor DNS responde con una respuesta válida, entonces es considerado Open Resolver. Si por el contrario, devuelve un rechazo (Query refused) o sencillamente hace timed out se encuentra bien configurado, por lo que no es un Open Resolver.

¿Cómo se consiguen los resolvers de IPv6?

LACNIC administra un servidor que puede ser llamado: Root Server Reverso, específicamente la letra “D”, es decir, d.ip6-servers.arpa. Gran cantidad de consultas a direcciones IP reversas de la región de LACNIC pasan a través de este servidor, en líneas generales este servidor SOLO recibe consultas de servidores DNS. Aquí es donde obtienen las direcciones IPv6 de los DNS que realizan consultas.

Procedimiento & Algoritmo

    1. En el servidor actualmente se realiza una captura de 2.5 millones de paquetes con el filtro del puerto 53 y destinados únicamente a la dirección IP de dicho equipo.
    2. De la captura anterior se ubican solo direcciones IPv6 origen (se eliminan paquetes mal formados, errores, etc). Se desprecia menos de 1% de los paquetes
    3. De las direcciones IPv6 obtenidas en el paso 2 se crea una lista de direcciones IPs unicast (es decir, se eliminan duplicados)
    4. Un script toma cada dirección IPv6 del listado del punto 3, y realiza una consulta a la dirección www.lacnic.net hacia esa dirección, verifica recursividad y el estado de la respuesta.
    5. En caso de ser un Open Resolver dicha dirección IP quedará registrada para su posterior análisis y notificación a la organización responsable de ese recurso.

Diagrama de bloques

Vista de los Resultados

Conclusiones Primarias

Para esta primera instancia, observamos aproximadamente unos 33,514 registros de consultas realizadas al Root Server Reverso “D” administrado por LACNIC.
Luego de analizar estos primeros datos obtenidos, observamos que la región más afectada por servidores open resolver sería la de APNIC con el 19.23% de los datos obtenidos para esa zona. Para la región de Ripe obtuvimos la mayor cantidad de información, curiosamente el porcentaje de servidores mal configurados es casi insignificante (0.93%).
En lo que respecta a nuestra región detectamos 39 open resolvers (4.56%) de los 817 registros recolectados, donde existen solo 3 casos que la dirección IP se repite más de una vez.

Estudios similares

Referencias

Para leer sobre Open Resolvers se recomienda este link: https://www.certsi.es/blog/dns

Realizado por:

Dario Gomez & Alejandro Acosta


lunes, 12 de septiembre de 2011

Ejemplos de hping

Ejemplos de hping:

Enviar paquetes TCP SYN al puerto 0 en la máquina example.com (nótese que hping  incrementara el puerto origen en 1 por cada paquete enviado):
#hping example.com-S-V  


Enviar los paquetes TCP SYN al puerto 443 en el host example.com:
#hping example.com -S-V-443 p  

Enviar paquetes TCP al puerto 443 en el host example.com con los flags SYN + ACK encendidos en conjunto:  
#hping example.com-S-A-V-443 p  

Enviar paquetes TCP al puerto 443 en el host example.com con el SYN + ACK FIN + set:  
#hping example.com -S-A-F-443 V-p  

Enviar paquetes TCP SYN cada 5 segundos en el puerto 443 en el host example.com:  
#hping example.com -S-443 V-p-i 5  

Enviar paquetes TCP SYN cada 100.000 microsegundos (es decir, cada 0,1 segundos o 10 por segundo) en el puerto 443 en el host example.com. Tenga en cuenta que se ha eliminado detallado:  
#hping example.com -S-p 443-i u100000

Enviar paquetes TCP SYN cada 10.000 microsegundos (es decir, cada 0,01 segundos, o 100 por segundo) en el puerto 443 en el host example.com:  
#hping example.com-S-p 443-i u10000  

Enviar paquetes TCP SYN cada 10.000 microsegundos (es decir, cada segundo de 0,01 o 100 por segundo) en el puerto 443 en el host example.com. Parar después de 500 paquetes:  
#hping example.com-S-p 443-i-c u10000 500  

Enviar paquetes UDP al puerto 111 en el host example.com (argumento - udp puede ser sustituido por -2): #hping example.com - udp-V-111 p

Enviar paquetes ICMP echo request para recibir example.com (argumento - icmp puede ser sustituido por -1): 
#hping example.com - icmp-V 

Enviar ICMP paquetes de solicitud de marca de tiempo para organizar example.com:  
#hping example.com - icmp - icmp-ts-V 

 Escaneo de puertos TCP 100 a 110 en el host example.com (argumento - el examen puede ser sustituido con -8)
#hping example.com-V - scan 100-110  

Enviar paquetes UDP falsa a partir de host de origen para recibir 192.168.1.150 example.com
#hping example.com - udp - parodia 192.168.1.150  

Enviar paquetes UDP falsa a varios de IP de origen aleatoria para recibir example.com
#hping example.com - udp - rand-fuente  

Enviar paquetes UDP con la parte de datos rellena con 100 bytes para albergar example.com
#hping example.com-V - udp - los datos de 100  

Enviar paquetes UDP con la parte de datos rellena con 100 bytes, pero con el contenido de payload.txt para albergar example.com (la carga útil se truncará si es menor de lo especificado por el argumento - de datos) 
 #hping example.com-V - udp - payload.txt archivo - los datos de 100


Más info:
El presente documento es una traducción con una pequeña adaptación de:
http://rationallyparanoid.com/articles/hping.html  (documento sencillo y practivo que me pareció excelente)

martes, 17 de agosto de 2010

Utilizar Linux como Teredo cliente

Introduccion:
Conectarse a una red IPv6 desde la casa u oficina hoy en dia es muy sencillo. Existen varias maneras y en este documento voy a explicar a instalar teredo y usarlo de manera muy sencilla y en pocos pasos.

Situacion:

Deseo utilizar mi servidor Linux como cliente Teredo para tener conectividad IPv6 en mi red IPv4 (el cual es a su vez nateada). En mi caso hice las pruebas desde un equipo Linux Mandriva 2010 y utilizando el servidor teredo de remlab.net

Solucion:
La solucion recomendada es utilizar el cliente Teredo para Linux llamada Miredo la cual es OpenSource, de distribucion gratuita es funciona muy bien.

Procedimiento:
1) Lo primeo es bajar Miredo de la pagina web en el URL: http://www.remlab.net/files/miredo/?C=N;O=D

2) Luego es necesario desempaquetarlo y compilarlo, en mi caso hice lo siguiente:
a) tar -jxvf miredo-1.2.3.tar.bz2
b) cd miredo-1.2.3
c) ./configure --without-Judy
d) make
e) make install

3) Finalmente ejecute Miredo con el comando:
/usr/local/sbin/miredo (luego de ejecutarlo espero entre 5-20 segundos para esperar que se cree la interfaz teredo y reciba su direccion ipv6)

Como comentario adicional el archivo de configuracion queda almacenado en:
/usr/local/etc/miredo/miredo.conf donde puedes cambiar el teredo server que deseas utilizar. Recomiendo que ubiques un servidor cercano a tu ubicacion geografica.

Para revisar:
La manera sencilla de revisar es haciendo por ejemplo un ping6 a ipv6.google.com.
Por otro lado, Miredo crea una interfaz logica en el sistema llamada teredo, la puedes revisar con el comando ifconfig. Por ejemplo:

ifconfig

teredo Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet6 addr: fe80::ffff:ffff:ffff/64 Scope:Link
inet6 addr: 2001:0:53aa:64c:18f6:6288:41b0:c5c8/32 Scope:Global
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1280 Metric:1
RX packets:243 errors:0 dropped:0 overruns:0 frame:0
TX packets:403 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:41816 (40.8 KiB) TX bytes:40042 (39.1 KiB)

Sobre la interfaz puedes utilizar herramientas como tcpdump o wireshark. Por ejemplo seria tcpdump -i teredo. Puedes tambien apreciar los paquetes entrantes y salientes los cuales se van a incrementar a medida que utilizar la conectividad IPv6

Por ultimo, tambien puedes revisar este post para probar tu conectividad IPv6
acostanetwork.blogspot.com/2009/04/probar-ipv6.html


Mas Informacion:
http://git.remlab.net/cgi-bin/gitweb.cgi?p=miredo.git;a=blob_plain;f=README;hb=HEAD

http://www.remlab.net/miredo/doc/miredo.8.html

miércoles, 14 de abril de 2010

Como capturar el bit recursion desired con tcpdump en un query DNS

Problema: El día de hoy escuchando el Podcast de Mr DNS escuché la idea de tomar el Bit de recursividad (recursion desired) en un paquete DNS. En ese momento me pareció buena idea intentarlo y por ello el presente post. Solución: Lo primero que hice fue hacer una captura y analizarla con Tcpdump y adicionalmente averiguar especificamente como es un paquete de pregunta DNS. Para esto último conseguí el siguiente paquete el cual tomé de: An Illustrated Guide to the Kaminsky DNS Vulnerability En este sentido, me interesa tomar el bit RD cuando se encuentre encendido. Debido a que tcpdump permite obtener el encendido/apagado de los bits pero en octetos hay que darse cuenta que el bit RD es el bit menos significativo del octeto numero 10 dentro del paquete UDP. En otras palabras, en el gráfico anterior cada "linea" tiene 4 octetos (32 bits). Si comenzamos a contar desde el Campo Source Port de UDP hasta el campo Query ID (incluyendo) existen 9 octetos. Por ello los próximos 8 bits son los flags del paquete DNS y el último de estos 8 (de izquierda a derecha) es el RD. En un query standard DNS estos 8 bits generalmente vienen de la manera: 00000001, por ello el comando tcpdump que necesitamos es el siguiente: #tcpdump -i eth0 udp[10] == 1 and port 53 Captura del wireshark: Links importantes: http://www.unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html Mr DNS Podcast
check out this page
LEAF DOMICILE Buy Marijuana Online, CBD Oil,Vape Store, Weed For Sale – Leaf Domicile Delivery Buy Weed Online at Leaf Domicile A wide collection of Weed Buds, Isolates, Hash, Vape Pens, Wax, Cartridges,Seeds, Concentrates, Edibles, CBD Oil for sale Buy Marijuana Online,Buy Weed Online,Weed For Sale,Buy kush online,- https://leafdomicile.com/ THC edibles for sale, order edibles, where can I buy edibles, mail order weed, buy wax online, buy cbd vape oil, pre rolled joints for sale, pre rolled joints for sale, buy kush online, where to buy dabs online, weed dabs for sale, wax for sale,

miércoles, 20 de mayo de 2009

Capturar más de 68 o 96 bytes con tcpdump

Varias veces he tenido la necesidad de capturar y luego analizar más de la información que guarda tcpdump por defecto (con la opción -w) luego de guardarla en un archivo.

TCPDUMP generalmente solo captura 96 bytes del paquete que viaja en el el cable, este valor por lo general es suficiente para analizar ethernet, ip, tcp/udp, icmp. Sin embargo, por ejemplo el contenido de un paquete grane HTTP imposible.

Por ello, en caso de tener la limitante antes mencionada la solución es el flag -s:

Ejemplo de captura por defecto:

tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes


0 packets captured
0 packets received by filter
0 packets dropped by kernel

Ejemplo de captura de todo el paquete en el cable:



[root@localhost tmp]# tcpdump -s 0
tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
^C

Notese el flag -s en el pase de parametros para tcpdump. Otros flags importantes:

* port
* host
* dst port
* src port
* dst host
* src host
* -w file

y es muy importante recordar que se puede contruir expresiones como las siguientes:

#tcpdump -s 0 dst port 23 and host 1.1.1.1 -w sniff.dump

Con el ejemplo anterior veremos que solo capturará paquetes donde el puerto destino sea 23 y contenga (origen o destino) el host 1.1.1.1

No voy a indicar más ejemplos porque la red se encuentra llena de ejemplos de tcpdump.

Suerte!

Una mejora práctica en el Transporte DNS sobre UDP en IPv6

Por Hugo Salgado y Alejandro Acosta Introducción y planteamiento del problema En el presente documento queremos discutir sobre un draft (bor...