Ataque a servidores DNS de Nicaragua

[Mario Rocha]

Estimados

Se ha filtrado la información de un posible ataque a servidores DNS de Nicaragua no especificados, buscando realizar algún tipo de envenenamiento de caché para este sábado..

El NIC.NI ha convocado a una reunión de emergencia para el día viernes a las 9:00 am en la UNI, a la cual asistiré.

Luego les comento qué sale de esto ..

Saludos

[Hugo Ruiz]

Pues el que filtró la información debe de saber ( o tiene que saber) quien va hacer estos ataques. Despues de todo, ¿No es trabajo de todos los dias de los administradores de red evitar esto?

[Jose Matus]

Apoyo lo que dice Hugo.  Quien filtró la información debe de saber.

En todo caso Mario, nos gustaría saber que decisión se ha tomado.

Saludos.

--
José Luis Matus M.
Linux User #441140

[Julio Vannini]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mario,

tenes conocimiento a cuales ISP se les ha notificado?

Quienes han confirmado atender la reunion?

Salu2!

Jose Matus wrote:
> Apoyo lo que dice Hugo. Quien filtró la información debe de saber.
>
>
> En todo caso Mario, nos gustaría saber que decisión se ha tomado.
>
> Saludos.
>
> El 23 de septiembre de 2009 16:58, Hugo Ruiz <hru...@gmail.com>
> escribió:
>
>> Pues el que filtró la información debe de saber ( o tiene que
>> saber) quien va hacer estos ataques. Despues de todo, ¿No es
>> trabajo de todos los dias de los administradores de red evitar
>> esto?
>>
>> El 23 de septiembre de 2009 16:53, Mario Rocha
>> <evoll...@gmail.com>escribió:
>>
>> Estimados
>>> Se ha filtrado la información de un posible ataque a servidores
>>> DNS de Nicaragua no especificados, buscando realizar algún tipo
>>> de envenenamiento de caché para este sábado..
>>>

>>> El NIC.NI <http://nic.ni/> ha convocado a una reunión de

>>> emergencia para el día viernes a las 9:00 am en la UNI, a la
>>> cual asistiré.
>>>
>>> Luego les comento qué sale de esto ..
>>>
>>> Saludos
>>>
>>>
>>>
>
>

- --
Julio Vannini
Asociación Nicaragüense de Astrónomos Aficionados "Carl Sagan"
ANASA
http://www.anasa.org.ni
- -------------
Coordinador para Nicaragua
Seccion Enseñanza y Divulgacion de la Astronomia
Liga Iberoamericana de Astronomia | SEDA-LIADA
http://www.liada.net
- -------------
Organizador Nacional 100 Horas de Astronomia
Astronomers Without Borders Affiliate.
Sidewalk Astronomers Member.
http://www.100hoursofastronomy.org/
- -------------
Blog Personal: http://ungaman.wordpress.com
Twitter: https://twitter.com/UngaMan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAkq6qzIACgkQShg99S7ibHP6VgCfVVOAnqqWy2MwyVqJNE7lMWxk
ctcAnjW7epDlhZpckS0sOYcXk94BEqU9
=FO6X
-----END PGP SIGNATURE-----

[Noel Vargas]

Ya había pasado demasiado tiempo desde que Kaminsky notificara del problema y algún niño quisiera probarlo contra los ISP locales...

De por sí, acá hemos estado teniendo problemas para resolver usando los DNS de ENITEL y Cablenet, no se si será el preludio o las pruebas iniciales...

2009/9/23 Julio Vannini <jvan...@gmail.com>

--
Noel Vargas Baltodano

[Mario Rocha]

Nope .. no estoy enterado .. sin embargo ya hubo otra persona que no está ligada a un ISP que me confirmó la noticia...

[Mario Rocha]

Les dejo este artículo, donde incluso hay un script para realizar una prueba de concepto ..

http://www.secureworks.com/research/articles/dns-cache-poisoning/

Me llama la atención este párrafo ... donde al menos me da la impresión de estar fuera de peligro

ISP Nameserver Admin
You can upgrade BIND to the latest version in the 9.x series, which is not vulnerable to this attack. Alternatively you may try using djbdns, an alternative to BIND written by D. J. Bernstein, author of the MTA program qmail. The djbdns software comes with a security guarantee, basically offering a monetary reward to anyone who publicly discloses legitimate buffer-overflow vulnerabilities in djbdns. Although the guarantee doesn't cover cache-poisoning attacks, I will show later in this article that djbdns offers much greater protection against such attacks when deployed properly.

Ahora bien, analizando el escenario del birthday attack, se me ocurre que con un IPS podría crearse una regla que bloqueara aquellas direcciones ip fuente que generaran un número mayor de X peticiones por segundo.



Por ejemplo, yo había encontrado hace algún tiempo una regla para iptables que funciona para frenar el exceso de sesiones SMTP, la cual dejo a continuación

iptables -A INPUT -i eth1 -p tcp -m tcp --dport 25 -m state --state NEW -m recent --set --name DEFAULT --rsource
iptables -A INPUT -i eth1 -p tcp -m tcp --dport 25 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --name DEFAULT --rsource -j DROP

Este conjunto de reglas cuenta la cantidad de sesiones hacia el puerto 25/TCP, y si hay más de 4 sesiones por minuto, se aplica una regla DROP

Modificándola para que proteger nuestro servidor DNS, podría quedar de esta forma

iptables -A INPUT -i eth1 -p tcp -m tcp --dport 53 -m state --state NEW -m recent --set --name DEFAULT --rsource
iptables -A INPUT -i eth1 -p tcp -m tcp --dport 53 -m state --state NEW -m recent --update --seconds 1 --hitcount 5 --name DEFAULT --rsource -j DROP

iptables -A INPUT -i eth1 -p udp -m udp --dport 53 -m state --state NEW -m recent --set --name DEFAULT --rsource
iptables -A INPUT -i eth1 -p udp -m udp --dport 53 -m state --state NEW -m recent --update --seconds 1 --hitcount 5 --name DEFAULT --rsource -j DROP

Si hay más de 5 sesiones dirigidas al puerto 25/UDP o 25/TCP, se aplica un DROP.

Obviamente hay que analizar bien la carga hacia el servidor DNS para saber si 5 sesiones por segundo es una carga aceptable, o bien modificarla de forma que se ajuste a nuestra realidad.

Les dejo todo esto en espera de sus comentarios .. recordemos que "soldado avisado, no muere en guerra"

Saludos

--~--~---------~--~----~------------~-------~--~----~
Has recibido este mensaje porque estás suscrito al grupo "Seguridad Software Libre Nicaragua"
Para colocar mensajes envía correo a la dirección seguridad-softwar...@googlegroups.com
Para cancelar tu suscripción a este greupo envía correo a seguridad-software-libr...@googlegroups.com
Para más opciones, visita: http://groups.google.com/group/seguridad-software-libre-nicaragua?hl=es
-~----------~----~----~----~------~----~------~--~---

[Mario Rocha]

Les dejo la siguiente lista de sitios que están infectados con virus y/o
están siendo identificados como phishing.

Si los visitan desde un equipo Windows, les recomiendo Firefox con
NoScript y Private browsing, Antivirus arriba, Firewall arriba.

Saludos

www.rsa4ever.com
www.americatravels.info
www.eqmon.net
www.contactoempresarial.net

[Joaz Rivera]

Solo en nicaragua!... que feliz serian los sysadmin y redes de otras regiones que los "hackers" por no decir otra palabra les "filtren" sus ataques. :)

Cuanto tiene esa vulnerabilidad a como dijo el maestro Noel? meses, se parcha y goodbye. nada del otro mundo.

m3chas

[Noel Vargas]

Joaz,

En muchos países se filtran los intentos de hacking, como advertencias a los sysadmin, a menos que tengan finalidades económicas o más oscuras.  En este caso, concuerdo con vos, es una falla harta conocida, existen los parches desde hace meses, así que los ISP sólo deben de mantenerse al día.

Saludos,

2009/9/24 Joaz Rivera <in...@joazrivera.com>

--
Noel Vargas Baltodano

[Mario Rocha]

Eso es algo que no entiendo .. yo periódicamente corro los actualizadores, especialmente cuando hay bugs tan ampliamente difundidos y de tan alta peligrosidad ..

De verdad hay gente tan descuidada (por no decir otra palabra) que deja estos bugs sin parchar durante tanto tiempo ?? Me cuesta mucho creer eso ..

Saludos

[Jose Sanchez]

Me mandaron esta "tragicomedia". Hittler ya no usará Java.

 

http://www.youtube.com/watch?v=mc20IkJjt_w

Para relajarse un poco.

 

Saludos

Tito

[Hugo Ruiz]

¡¡¡Excelente!!!

[Joaz Rivera]

Al fin???

Joaz Rivera
Sistemas Web - Hospedaje y dominios Web - Publicidad
in...@joazrivera.com
livemessenger: joazr...@hotmail.com
Joazrivera.com
Phone: +50584786545
Nicaragua

[Mario Rocha]

que yo sepa .. no hubo nada .. pero no hay que bajar la guardia ..

Por cierto, nadie comentó sobre las reglas del iptables que envié ..

Saludos

[Norman Garcia Aguilar]

Estos dias han habido problemas con los DNS de turbonett o soy el unico?

Saludes

--
Norman Garcia Aguilar
http://www.normangarcia.info/blog
Linux user # 444131
Ubuntu user # 15806

[Ismael Gongora]

Yo he tenido problemas con turbonett y cablenet tambien.. de cada 10 peticiones fallan como 3..

2009/9/28 Norman Garcia Aguilar <nagu...@gmail.com>

[Walter Pichardo]

Turbonett siempre ha tenido problemas con los DNS, aparte de eso siempre cuesta que se refresquen.

Mario con respecto a las reglas de Iptables lo que hace es tratar de evitar un ataque DoS, segun leyendo por ahi y lo comprobe con la dnsstuff, comentando la siguiente linea en el named.conf evita tambien que estes expuesto a un dns poision query-source address * port 53.

si actualizas el bind y siempre tienes habilitado esa linea en el test siempre te saldra vulnerable, pero si comentas las segun el test me salio passed.

supongo que esto es debido a que estas forzando que los query se hagan directamente a tu ip publico al puerto 53 tcp y udp
options {
    directory "/var/named";
    dump-file "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
    /*
     * If there is a firewall between you and nameservers you want
     * to talk to, you might need to uncomment the query-source
     * directive below.  Previous versions of BIND always asked
     * questions using port 53, but BIND 8.1 uses an unprivileged
     * port by default.
     */
     /* query-source address * port 53; #### Esta es la linea a comentar
     cleaning-interval 120;

--
===================================
Walter Pichardo
Linux User # 402402
Si te preocupas por tu salud haslo por el Planeta
===================================

[Mario Rocha]

En CentOS esa línea viene comentariada por default

         // query-source address * port 53;

Saludos