Archivo

Entradas Etiquetadas ‘analisis red’

Asimetrías de tráfico en Cortafuegos

Miércoles, 22 de Julio de 2015 Comentarios desactivados

La mayoría de las veces los cortafuegos se ponen en modo “activo”, empleándose com router de interconexión de las diversas redes,  algo diferente a los cortafuegos de “aplicación” o pasarela como  FWTK o en su versión comercial (Gauntlet), que diferenciaban bien el tráfico, después se paso a utilizar los cortafuegos como routers y de ahí a pensar que las iptables son un firewall…

Ahora con los cortafuegos de “capa 7” (¿ cuando ha tenido TCP/IP 7 capas?) , se pueden poner muchas veces en “modo  trasparente” y esto hace que en muchas situaciones donde antes “no pasaba nada” ahora no funcione el tráfico , como puede  verse en el siguiente en el que un equipo dentro de una misma red hacía de router para una red interna distinta de la “ruta por defecto” y que no presentaba “problemas” hasta que se incluyo un cortafuegos de “nueva generación” transparente y en medio..

En el siguiente esquema se muestra como estaban situados los equipos:

red_interna

red_interna

En principio, no hay problemas hay un router y por defecto y el tráfico por defecto va al router y este llega va y vuelve sin problemas, el cortafuegos inspecciona el tráfico y no se ven problemas.

trafico_a_internet

tráfico a internet

El tráfico de las máquinas pasa por el cortafuegos con destino al router , este envía los paquetes IP a internet y la vuelta viene por el mismo sitio.

Para acceder a la red interna se tenían muchas opciones, pero lo “más cómodo” fue que el router principal tuviera una ruta definida de forma estática a esta red interna empleando un equipo interno que conectaba con la otra red, de forma que el tráfico a la red interna se enrutara por el equipo interno que hacía de router:

trafico_asimetrico

tráfico asimétrico

Ahora bien esto creaba un tráfico asimétrico los paquetes “de ida” de las estaciones de trabajo se dirigían al router (es su router por defecto), de ahí el router las reenviaba al equipo en la misma red interna que hacía routing y de ahí a la red interna, ahora bien el router interno no empleaba el router principal para reenviar los paquetes IP de vuelta, ya que al estar las máquinas en la misma red se enviaban directamente.

Al poner el cortafuegos en modo transparente este solamente veía los paquetes de ida (dos veces eso sí), por lo que por ejemplo para permitir el tráfico HTTP/HTTPS permitía el primer paquete (SIN) , que inspeccionaba, pero después al no tener el paquete de SIN/ACK , los siguientes paquetes no los enviaba al estar esperando este SIN/ACK.

En los equipos la conexión TCP/IP se establecía (ya que llegaba el SIN/ACK) pero después al bloquear el tráfico el cortafuegos no se podían enviar datos, ¿la forma final para depurar y comprobar que estaba pasando esto ?, emplear en el equipo de usuario una captura de paquetes y ver que la direcciones MAC que se empleaban en la comunicación no eran las que tenían que ser, ya que aunque los paquetes se enviaban al router principal era el router interno el que enviaba después a nivel interno el trafico.

trafico_macs

trafico_macs

Por defecto tcpdump no muestra la información de la direcciones MAC, por lo que hay que indicarlo con la opción -e y después comprobar en la tabla arp (arp -an ) a que equipo corresponde cada una de las MAC.

Se pueden establecer varias soluciones, que por diversos motivos se fueron descartando:

Poner rutas más especificas en los equipos de forma que no utilizarán el router principal para acceder a esta red sino que fueran directamente a la red interna, sin embargo los equipos se configuran por DHCPD y resulta que la opción de configurar varias rutas (RFC-3442 Classless Static Routes) no funciona en algunas de las estaciones de trabajo.

Forzar en el router interno a que el tráfico con destino la red de usuarios sea enviado al router principal, esto obligaría a emplear enrutamiento por fuente en este router (el routing normal suele ser por “destino”) y configurar el router principal para que cuando le llegue este tráfico no se queje mucho (algo raro que una máquina de la misma red envíe trafico a traves de el en vez de directamente.

Al final se decidió establecer una red de conexión “punto a punto” (un /30) entre los dos routers, de forma que el router secundario no estuviera en la misma red que los equipos de usuarios, estableciendo incluso una VLAN separada, de esta forma el tráfico al final pase por el cortafuegos siempre y no haya problemas de conexión.

IMG_20150717_110702

tráfico simétrico

Al final el tráfico pasa dos veces por el cortafuegos (qué se le va a hacer ), pero es un tráfico simétrico y el cortafuegos puede inspeccionarlo , comprobar que todo va correcto, no solo a nivel IP sino a nivel de aplicación y proteger de forma adecuada a los usuarios.

Categories: sistemas Tags: , ,

DNSChanger , algunas nueces

Miércoles, 11 de Julio de 2012 Comentarios desactivados

 

Con el problema de seguridad de DNSChanger, ha habido mucha difusión mediatica y se indicaba que para muchos usuarios el día 9 de Julio iba a ser el cataclismo, al no funcionarles correctamente su conexión a Internet, en http://www.dcwg.org/ hay mucha más información sobre todo esto.

El problema venía siendo arrastrado desde hace mucho tiempo ya que muchos equipos de todo el mundo habían sido infectados y el “virus/gusano/troyano,etc” había cambiado los DNS para apuntar a unos controlados por los atacantes, que aprovechaban las consultas para falsear las consultas, de forma que podían redigir a voluntad las consultas de DNS, por ejemplo haciendo que al buscar www.tubanco.es fueras a otra dirección de internet.

Desde  finales del año pasado el FBI intervino estos servidores y todo el tráfico de DNS era respondido correctamente , pero el mandado judicial acababa este 9 de Julio, por lo que desde RedIRIS se planteo mitigar el problema interceptando las consultas a los servidores que iban a dejar de funcionar y poniendo nosotros un servidor que respondiera (y registrara) las consultas.

Al final desde luego ha habido mucho ruido pero pocas “nueces”, ya que al final había menos de 15 equipos infectados en toda la red de RedIRIS (unos 2 Millones de direcciones IP ), por lo que no parece significativo el número de infecciones.

Gracias a tener registrado las consultas que hacen las máquinas sin embargo hemos podido encontrar algunas “nueces” interesantes como las siguientes:

Un equipo todavía infectado por un conficker.

Conficker es un gusano con más de dos años de actividad que se intenta conectar periodicamente a un equipo para recibir instrucciones, los  nombre de los equipos a los que se intenta conectar se  generan de forma pseudo-aleatoria cada día ,  en http:// confickerworkinggrou.org hay más información incluyendo unas gráficas sobre el número de infecciones que se detectan cada día. ( http://www.confickerworkinggroup.org/wiki/pmwiki.php/ANY/InfectionTracking  )

Viendo las consultas se se aprecia una máquina haciendo consultas al DNS  buscando dominios “bastante raros” (la IP origen se ha cambiado a AAA.BB.CC.144 ).
2012-07-05 19:48:55.400426 IP AAA.BB.CC.DDD.1025 > 85.255.113.118.domain:61962+ A? zcgqlzyo.ws. (29)
2012-07-05 19:49:00.556635 IP AAA.BB.CC.DDD.1025 > 85.255.113.118.domain:59401+ A? lrgrbypi.com. (30)
2012-07-05 19:49:12.853223 IP AAA.BB.CC.DDD.1025 > 85.255.113.118.domain:19720+ A? kodutaunnpx.ws. (32)
2012-07-05 19:49:23.056254 IP AAA.BB.CC.DDD.1025 > 85.255.113.118.domain:40718+ A? cxxejithkhp.info. (34)
2012-07-05 19:49:28.227979 IP AAA.BB.CC.DDD.1025 > 85.255.113.118.domain: 8462+ A? zcrfcywrlh.biz. (32)
2012-07-05 19:49:38.430740 IP AAA.BB.CC.DDD.1025 > 85.255.113.118.domain: 40973+ A? ojbpb.net. (27)
.....
2012-07-06 09:37:48.887692 IP AAA.BB.CC.DDD.1025 > 85.255.113.118.domain: 8191+ A? ksccwristsl.com. (33)
2012-07-06 09:37:56.168755 IP AAA.BB.CC.DDD.1025 > 85.255.113.118.domain: 50429+ A? zakoeer.ws. (28)
2012-07-06 09:38:01.324965 IP AAA.BB.CC.DDD.1025 > 85.255.113.118.domain: 46588+ A? temvb.info. (28)
2012-07-06 09:38:06.574691 IP AAA.BB.CC.DDD.1025 > 85.255.113.118.domain: 19708+ A? bbiiz.ws. (26)
2012-07-06 09:38:11.777818 IP AAA.BB.CC.DDD.1025 > 85.255.113.118.domain: 4578+ A? dtvlrhl.info. (30)
2012-07-06 09:38:16.934003 IP AAA.BB.CC.DDD.1025 > 85.255.113.118.domain: 9185+ A? sclmyhiyxa.biz. (32)

Otro caso curioso  que aparece en los logs es este:

2012-07-09 19:31:28.150676 IP AAA.BB.CC.17.35627 > 67.210.14.61.domain: 19061+ MX? att.net. (25)
2012-07-09 19:31:28.270993 IP AAA.BB.CC.17.35634 > 67.210.14.62.domain: 64862+ A? scc-mailrelay.att.net. (39)
2012-07-09 19:31:28.481642 IP AAA.BB.CC.17.35656 > 67.210.14.61.domain: 13448+ MX? rocketmail.com. (32)
2012-07-09 19:31:28.550584 IP AAA.BB.CC.17.35662 > 67.210.14.62.domain: 51788+ MX? aol.com. (25)
2012-07-09 19:31:30.071473 IP AAA.BB.CC.17.35738 > 67.210.14.61.domain: 32104+ A? mx1.rog.mail.yahoo.com. (40)
2012-07-09 19:31:30.311212 IP AAA.BB.CC.17.35753 > 67.210.14.62.domain: 27165+ A? fpo.mail.dk. (29)
2012-07-09 19:32:23.634079 IP AAA.BB.CC.17.37220 > 67.210.14.62.domain: 20212+ MX? talktalk.net. (30)
2012-07-09 19:32:23.970319 IP AAA.BB.CC.17.37255 > 67.210.14.62.domain: 58452+ MX? kodel.com. (27)
2012-07-09 19:32:24.134301 IP AAA.BB.CC.17.37273 > 67.210.14.62.domain: 44514+ MX? vocollect.com. (31)
2012-07-09 19:32:24.853948 IP AAA.BB.CC.17.37339 > 67.210.14.62.domain: 39530+ MX? uchicago.edu. (30)
.....
2012-07-10 13:20:10.089107 IP AAA.BB.CC.17.49746 > 67.210.14.61.domain: 63686+ MX? yahoo.co.uk. (29)
2012-07-10 13:20:10.128946 IP AAA.BB.CC.17.49750 > 67.210.14.62.domain: 34710+ A? mx-eu.mail.am0.yahoodns.net. (45)
2012-07-10 13:20:12.159913 IP AAA.BB.CC.17.49762 > 67.210.14.61.domain: 64173+ MX? verizon.net. (29)
2012-07-10 13:20:12.239307 IP AAA.BB.CC.17.49766 > 67.210.14.62.domain: 27468+ MX? btinternet.com. (32)
2012-07-10 13:20:12.568931 IP AAA.BB.CC.17.49778 > 67.210.14.61.domain: 37659+ MX? wanadoo.fr. (28)
2012-07-10 13:20:13.268954 IP AAA.BB.CC.17.49782 > 67.210.14.62.domain: 31907+ MX? orange.fr. (27)
2012-07-10 13:20:13.429057 IP AAA.BB.CC.17.49796 > 67.210.14.61.domain: 64758+ MX? yahoo.com. (27)
2012-07-10 13:20:13.488950 IP AAA.BB.CC.17.49799 > 67.210.14.62.domain: 51148+ A? mta6.am0.yahoodns.net. (39)
2012-07-10 13:20:25.361551 IP AAA.BB.CC.17.49814 > 67.210.14.61.domain: 12389+ MX? sbcglobal.net. (31)

Donde se aprecia que el equipo, (que no es un servidor de correo) esta haciendo muchas consutas de DNS de tipo “MX”,  una análisis en mas detalle indica que este equipo, un Linux parece estar comprometido y se esta empleando para enviar SPAM.

También  posible “adivinar” si el equipo infectado en cuestión es un “Mac” e incluso si tiene el IPv6 activado o no, de otro de los equipos infectados:

2012-07-05 20:05:04.088957 IP AAA.BBB.CC.187.49974 > 85.255.115.155.domain: 41711+ PTR? b._dns-sd._udp.0.CC.BBB.AAA.in-addr.arpa. (58)
2012-07-05 20:05:04.089648 IP AAA.BBB.CC.187.61248 > 85.255.115.155.domain: 33128+ PTR? db._dns-sd._udp.0.CC.BBB.AAA.in-addr.arpa. (59)
2012-07-05 20:05:04.089887 IP AAA.BBB.CC.187.63188 > 85.255.115.155.domain: 54465+ TXT? cf._dns-sd._udp.0.CC.BBB.AAA.in-addr.arpa. (59)
2012-07-05 20:06:27.569295 IP AAA.BBB.CC.187.57867 > 85.255.115.155.domain: 4630+ PTR? 187.CC.BBB.AAA.in-addr.arpa. (45)
2012-07-05 20:06:27.609607 IP AAA.BBB.CC.187.62491 > 85.255.115.155.domain: 39982+ PTR? 8.3.9.b.9.d.e.f.f.f.f.d.e.1.a.f.b.0.0.0.8.1.e.4.Y.Y.Y.Y.X.X.X.X.ip6.arpa. (90)
2012-07-05 20:06:27.653437 IP AAA.BBB.CC.187.60475 > 85.255.115.155.domain: 62266+ PTR? 8.3.9.b.9.d.e.f.f.f.f.d.e.1.a.f.b.0.0.0.0.0.0.0.0.0.0.0.0.c.e.f.ip6.arpa. (90)
2012-07-05 20:06:27.679686 IP AAA.BBB.CC.187.59874 > 85.255.115.155.domain: 13440+ PTR? 1.195.168.192.in-addr.arpa. (44)
2012-07-05 20:06:27.695459 IP AAA.BBB.CC.187.52476 > 85.255.115.155.domain: 22310+ PTR? 1.124.168.192.in-addr.arpa. (44)

Se observa que el equipo hace muchas consultas vía DNS de tipo PTR y TXT a una zona “in-addr.arpa” algo especial , buscando por ahí son consultas típicas del protocolo “Bonjour” de Apple,  http://www.dns-sd.org/ ,  ( 4 primeras lineas ), además el equipo hace conexiones a zonas “ip6.arpa” , lo que indica que además tiene activado el IPv6  (siguientes dos lineas ) y por ultimo las dos ultimas lineas preguntando por la inversa dentro de un rango privado (192.168.124.1) parecen indicar que el equipo se encuentra detras de algún tipo de router / NAT .

 

Categories: Incidentes Tags: , ,