DNS Protocol enforcement

Protección de smartdefense con fecha de junio del 2006, en «teoría». Los cachondos dicen que «attackers attemp to send and illegal DNS packet sent over TCP or UDP with the hope that it will enter the network undected».

Debido a las ultimas petadas del bind y, como el tema se esta poniendo chungo montamos un nuevo servidor DNS que no petara para hacer forward de peticiones hacia nuestro proveedor.
Configuración normal y corriente…
options {
listen-on port 53 { x.x.x.x; };
directory «/var/named»;
dump-file «/var/named/data/cache_dump.db»;
statistics-file «/var/named/data/named_stats.txt»;
memstatistics-file «/var/named/data/named_mem_stats.txt»;
allow-query { any; };
}

Nada raro, arrancas y funciona «bien». Tenemos un huevo de trafico, asi que, al poco rato empiezo a ver paquetes denegados en el firewall…
«server to client packet of and old UDP session», cada vez mas. El caso es que la resolución de nombres funciona, pero la sensación es que va muy lento…
La resolución de DNS la tenemos dividia en 3 dominios (de Windows), es decir, el dominio A (el de los pc’s clientes) resuelve lo que cachea y lo que no sabe se lo pasa al servidor B, este resuelte a los servidores y lo que no conoce lo pasa al C que lo unico que hace es forward hacia el DNS externo (el nuevo) y este resuelve todos nuestros dominios y, ademas contesta a las peticiones de los 3 anteriores.
Como tardaba mucho en resolver, quite la resolución por root servers y l e puse forwarders hacia nuestro ISP… Todavia peor, mas paquetes denegados, errores del tipo «FORMERR resolving»…
Lo dejamos hacia los root servers, que para eso estan, pero se siguen perdiendo paquetes
Para que los servidores salgan a internet «temporalmente» atraviesan dos fw-1 con diferentes versiones pero con la misma configuración de smardefense…en el segundo se empiezan a ver parquetes UDP de respuestas de DNS ¿?¿? (denegados), tiene pinta que el primero esta haciendo algo para que el segundo empiece a ver las vueltas como nuevas y las procese por la politica.
Llegados a este punto, el culpable apunta al smartdefense, asi que, regla de dns protocol enforcement en monitorización.
Se siguen viendo los paquetes (pero ahora pasan), el DNS empieza a resolver a una «velocidad normal» y el segúndo firewall deja de ver los paquetes de las vueltas…
Que alguien me lo explique…En la base de datos de checkpoint no dicen nada
Lo curioso del tema es que haya empezado a fallar hoy, el servidor lleva montado 10 días por lo menos. No tengo tan claro que la regla del smartdefense tenga la culpa, curiosamente, los servidores con linux no dejan de fucnionar, solo cascan las peticiones de DNS de los servidores de dominio (que son W3k). Un dominio que falla desde el DS funciona directamente desde el servidor DNS y funciona bien desde otro linux que resuelve a través del servidor DNS afectado (y todo pasa por los mismos dos fw’s).
Serán distintas las peticiones de DNS ?.
En el log del servidor DNS A (que es un controlador de dominio) no se ve nada raro, casi todas las entradas son del tipo:
«20090930 10:15:52 127C PACKET 01F061D0 UDP Snd 212.187.162.134 6632 Q [0000 NOERROR] A (6)update(9)microsoft(3)com(5)nsatc(3)net(0)»
En fin, otra cosa rara mas, unas horitas sin que la gente pueda ver su facebook (que al final es lo que les encabrona).

4 comentarios sobre «DNS Protocol enforcement»

  1. sesion udp, que cosas tiene el fw-1
    Interesante, no entiendo muy bien el erro ese de «server to client packet of and old UDP session», en udp la sesion es el source port del cliente, lo que no entiendo es como sabe si es old o no XD si no hay ese control en UDP que yo recuerde, no? XD

    gabi

    1. sesion udp
      XD si que mantiene una «tabla de estados» de sesiones UDP. Por defecto tiene 40 segundos (de cabeza) de timeout. Lo curioso del tema es que el fw «que se comía» los paquetes no decia nada.. :).

  2. Debug
    Para ver problemas en el dns…
    rndc querylog -> muestra una linea con cada query
    rndc trace, cada vez que lo ejecutas subes 1 nivel la traza, asi se puede verr todo lo que hace (incluidas las vueltas).
    Se ven cosas como esta:
    client 172.16.145.51#45554: query (cache) ‘www.facebook.com/A/IN’ approved
    createfetch: http://www.facebook.com A
    fctx 0xb5608808(www.facebook.com/A’): create
    fctx 0xb5608808(www.facebook.com/A’): join
    fetch 0xb7f545a8 (fctx 0xb5608808(www.facebook.com/A)): created
    fctx 0xb5608808(www.facebook.com/A’): start
    fctx 0xb5608808(www.facebook.com/A’): try
    fctx 0xb5608808(www.facebook.com/A’): cancelqueries
    fctx 0xb5608808(www.facebook.com/A’): getaddresses
    fctx 0xb5608808(www.facebook.com/A’): query
    resquery 0xb560f278 (fctx 0xb5608808(www.facebook.com/A)): send
    resquery 0xb560f278 (fctx 0xb5608808(www.facebook.com/A)): sent
    resquery 0xb560f278 (fctx 0xb5608808(www.facebook.com/A)): senddone
    resquery 0xb560f278 (fctx 0xb5608808(www.facebook.com/A)): response
    Xd, esta es una de las que funcionan
    Y esta de cuando fallaban…

  3. linux rocks!
    Me hizo mucha gracia cuando dijiste:

    > curiosamente, los servidores con linux no dejan de fucnionar, solo cascan las peticiones
    > de DNS de los servidores de dominio (que son W3k).

    Yo desde hace un par de años solo administro servidores con linux y soy feliz 🙂 este tipo de cosas extrañas no me volvieron a ocurrir.

    SEO UK

Los comentarios están cerrados.