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

Cómo averiguar la versión de BIND

Hoy os quiero presentar un pequeño truco para averiguar la versión de bind que está empleando un servidor DNS aunque éste la tenga oculta. Hace un tiempo publiqué cómo poder ocultar la versión de bind que estábamos empleando y hoy vamos a ver cómo ese método no sirve de nada.
Para hacer la prueba, vamos a necesitar instalar el comando fpdns, que no es más que un pequeño script que se emplear para realizar un  'fingeprinting' a servidores DNS y averiguar así la versión que están ejecutando.
El paquete esté disponible en los repositorios de las principales distribuciones y en Debian/Ubuntu, la instalación es muy sencilla,


shell> apt-get install fpdns
Una vez está instalado, tenemos el siguiente resultado, en comparativa entre una petición vía dig,
shell> dig -c CH -t txt version.bind @ns1.miempresa.com
...
;; QUESTION SECTION:
;version.bind.                  CH      TXT
...
a un petición con el nuevo comando,
shell> fpdns -D miempresa.com
fingerprint (miempresa.com, 212.244.X.X): ISC BIND 9.2.3rc1 -- 9.6.1-P1 
Como podéis observar, la versión del servidor bind9 que se está ejecutando nos dice que que es la 9.2.3rc1 -- 9.6.1. Puesto que tengo acceso al servidor, compruebo y corroboro lo que fpdns dice y efectivamente la versión instalada es la 9.7.3. Como se puede ver, no acertó exactamente pero sí no dio una idea muy próxima de qué versión se está empleando.
Leer más

Bind9, denegación de servicio

ICS, Internet System Consortium, encargada de desarrollar el famoso servidor DNS BIND ha liberado una nueva versión del mismo que corrige un fallo de seguridad. Este fallo de seguridad puede provocar una denegación de servicio ante una consulta especialmente manipulada.
Dicha vulnerabilidad, calificada como crítica, tiene asignado el código CVE-2013-4854 y fue reportada por Maxim Shudrak a través del programa de Zero Day Initiative de HP. Afecta a las versiones de las ramas 9.7, 9.8 y 9.9 del servidor. La rama 9.6 no está afectada y la rama 9.10 tampoco. Para el resto de las ramas, existe ya un parche oficial, a excepción de la 9.7, que ICS avisó en un comunicado que no aplicaría el parche por estar descontinuada.
El fichero que contiene el fallo es el lib/dns/rdata/generic/keydata_65533.c y el parche aplicado es muy sencillo,
...
    isc_buffer_activeregion(source, &sr);
-   if (sr.length < 4)
+   if (sr.length < 16)
       return (ISC_R_UNEXPECTEDEND);
...
Para servidores Debian en versión stable o oldstable ya está el parche aplicado y sólo debemos actualizar para no vernos afectados.
Más información:
La entrada Bind9, denegación de servicio la puedes leer en Puppet Linux.
Leer más

2 vistas en DNS

Desde la versión 9 de bind, éste permite establecer una configuración más compleja de las zonas DNS. Concretamente en lo que a vistas se refiere. Si estamos en una organización de tamaño medio/grande lo más probable es que el número de equipos sea elevado y también que exista una configuración de red con DMZ, VLAN's, etc. En estos esquemas de red, cuando tú accedes a tu web, local.net, no es lo mismo estar dentro que estar fuera de la red de la oficina. Desde fuera realmente quién debe contestar es una IP pública, mientras que desde dentro, debería de contestar una IP privada. La IP de DMZ del servidor en cuestión. Para conseguir este tipo de comportamiento necesitamos emplear las múltiples vistas del DNS. Es decir, tendríamos una primera vista local (IP's del rango locales) y una vista externa (IP's públicas). La primera para trabajar en la oficina y la segunda para Internet. Por supuesto lo que exista en una vista no debe ni tiene que existir en la otra.
A nivel ya de configuración vamos a emplear las view de bind. Las ventajas que esto ofrece es que permite en un único daemon ejecutar varias vistas y todas ellas sobre un único interfaz de red (IP). Vamos por lo tanto a inventar los datos para poner un ejemplo que clarifique lo que estamos comentando. Lógicamente los datos son inventados y las IP's públicas distan mucho de la realidad.
115.26.35.2/8Rango público
192.168.0.0/24Rango privado/DMZ
Y tenemos 3 servidores, con sus respectivos servicios ejecutándose con la siguiente configuración. Suponemos que existe un firewall que hace NAT entre la IP pública y la IP privada y que permite diferenciar la DMZ de la red local de la empresa.
Nombre
IP pública
IP privada
ns.local.net 115.26.35.4 192.168.0.4
www.local.net 115.26.35.6 192.168.0.6
mail.local.net 115.26.35.7 192.168.0.7
Puesto que partimos de un bind ya instalado, su instalación no la vamos a detallar, simplemente vamos a editar los ficheros de configuración que correspondan para que el servicio funcione con dos vistas.
El primer fichero a editar es /etc/bind/named.conf. Puesto que nos interesa que sea escalable, para futuras incorporaciones de ficheros y servicios, este fichero contendrá los includes necesarios.
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.dmz";
include "/etc/bind/named.conf.externo";

Como podemos observar desplegamos para que sea más fácil de comprender los named en 3 ficheros completamente independientes.

Nótese aquí que el fichero de configuración de las DMZ's está antes que el de las zonas externas. Esto debe ser así, por que es más restrictivo.
  1. named.conf.options
    Este fichero contiene las opciones de configuración globales del servicio.
    options {
       directory "/var/cache/bind";
       allow-query { any; };
       allow-recursion { any; };
       auth-nxdomain no;
       version "bind-9";
    };
    
  2. named.conf.dmz
    Fichero de configuración para la vista de DMZ. Las primeras líneas contienen las acl's a nivel de IP's que se van a tener en cuenta para saber si un equipo debe leer esta vista o no. Puesto que es más restrictivo, este fichero de debe cargar antes.
    acl "dmz" {
       192.168.0.0/24;
       192.168.1.0/24;
       127.0.0.1
    };
    
    view "dmz" {
       match-clients { "dmz"; };
       include "/etc/bind/named.conf.base";
       zone "local.net" {
          type master;
          file "/etc/bind/directas/local.net.dmz";
       };
       include "/etc/bind/named.conf.master.common";
       include "/etc/bind/named.conf.rev";
    };
    
  3. named.conf.externo
    Este fichero contiene la información para la vista externa y como se puede observar en la segunda línea, hace match para todos los clientes, de ahí que deba ser el último en colocarse. También y como medida de seguridad está la línea allow-transfer { none; }, simplemente para indicar que ningún servidor es secundario.
    view "externo" {
       match-clients { any; };
       include "/etc/bind/named.conf.base";
       zone "local.net" {
          type master;
          notify-source 192.168.0.4;
          allow-transfer { none; }
          file "/etc/bind/directas/local.net.externo";
       };
       include "/etc/bind/named.conf.master.common";
       include "/etc/bind/named.conf.rev";
    };
    
En este punto ya tenemos todo configurado y sólo queda por rellenar los valores de los ficheros local.net.dmz y local.net.externo, que tendrá los nombres e IP's. Aquí únicamente debemos de tener en cuenta no poner una IP pública o privada en el fichero incorrecto.
  • local.net.dmz
    $TTL 3600
    @  IN  SOA  ns.local.net.  root.local.net.  (
            2010022401
             86400
             7200
             2592000
             3600 )
    
             IN     NS            ns.local.es.
             IN     MX     10     mail.local.net
    
    ns       IN     A       192.168.0.4
    www      IN     A       192.168.0.6
    mail     IN     A       192.168.0.7
    
  • local.net.externo
    $TTL 3600
    @  IN  SOA  ns.local.net.  root.local.net.  (
             2010022401
             86400
             7200
             2592000
             3600 )
    
             IN     NS            ns.local.es.
             IN     MX     10     mail.local.net
    
    ns       IN     A       115.26.35.4
    www      IN     A       115.26.35.6
    mail     IN     A       115.26.35.7
    
Después de esto simplemente tendremos que hacer un restart del servicio bind y las nuevas vistas (dmz y externo) serán cargadas automáticamente, simplificando enormemente trabajar desde la oficina empleando nombres.
Leer más

Peticiones DNS cifradas


Cada vez más se empieza a escuchar que los proveedores de Internet o ISP's están controlando y restringiendo el tráfico que generamos. Una de las formas más sencillas y también más simples de saltar es el control del DNS. Un nombre DNS no es más que una forma fácil de acordarse de una IP, que es la que realmente sirve el contenido. Si bien todos nos tuviéramos que acordar de la IP 173.194.66.94 cada vez que accediésemos a Google fijo que éste tendría muchas menos visitas. Esto es lo que hace el DNS, simplificar.
Pues bien, de la misma forma que simplifica, también es fácil obtener las cadenas a las que deseas acceder y evitar que las visites. Por ejemplo, cada vez que vayas a Google, mandarte a Yahoo! o a una web que indique que el contenido está prohibido. Esto con un ataque MITM (Ataque Man-in-the-middle) es fácil de realizar y los ISP's realmente están a ese nivel con nosotros.
Por suerte existe un proyecto que ofrece una versión libre de DNS's, OpenDNS. Éste nos ofrece las mismas garantías que el resto de servidores DNS que están disponibles por la red, pero tiene a mayores la peculiaridad de que acepta tráfico DNS encriptado y por supuesto lo devuelve encriptado. Por lo tanto, la idea sería tener una implementación https bajo el protocolo DNS.
Visitando la web de OpenDNS se nos linka a un proyecto, DNSCrypt, que hace exactamente lo que hemos comentado anteriormente. Cifra nuestro tráfico entre origen y destino evitando las molestas escuchas, convirtiendo nuestro equipo local en nuestro proveedor de DNS, que lanza posteriormente las consultas fuera. Vamos a ver cómo instalarlo y usarlo.
  1. Descargamos el código desde github
  2. Extraemos y compilamos el código
    shell> tar xxvf dnscrypt-proxy-1.2.0.tar.gz
    shell> cd dnscrypt-proxy-1.2.0
    shell> ./configure
    shell> make
    shell> make install
    
  3. Arrancamos el servicio
    shell> dnscrypt-proxy --daemonize
    
  4. Cambiamos el servidor DNS del equipo
    Por defecto en los equipos Linux tendremos que editar el fichero /etc/resolv.conf y dejarlo con el siguiente contenido.
    nameserver 127.0.0.1
    
  5. Comprobamos
    shell> dig www.google.es
    
Aunque las preguntas las estemos a realizar a nuestro DNS local, realmente las está respondiendo OpenDNS y toda la comunicación irá cifrada, creando así una comunicación DNS segura.

La entrada Peticiones DNS cifradas la puedes leer en Puppet Linux.
Leer más

Replicar punto de montaje: bind mount

En algunas ocasiones puede resultar, cuando menos útil, poder tener accesible desde dos paths diferentes un subconjunto de un árbol de directorios. Esto lo podemos lograr mediante lo que se conoce como bind mount.
Desde el comando mount con la opción -o bind podemos realizar este tipo de montaje especial. Por ejemplo, si queremos tener la misma información que está en una partición localizada bajo /var/www y /usr/local/www, se podría hacer así.
shell> mount -o bind /usr/local/www /var/www
Con lo que, una vez montados se podría ver lo mismo en ambos lugares.
# ls /var/www/
extra  site.com index.html
# ls /usr/local/www/
extra  site.com index.html
Para hacerlo automáticamente cuando el sistema se arranque, habrá que incluirlo en /etc/fstab con la siguiente sintaxis.
/var/www   /usr/local/www   none   bind   0   0
Replicando lo que haya en /vaw/www en /usr/local/www.
Leer más

Fallo de seguridad en BIND



Ayer fue descubierta una nueva vulnerabilidad 0-day en el servidor DNS Bind, que parece afectar a todas las versiones, provocando una denegación de servicio (DoS). El código asociado a dicha vulnerabilidad es el (CVE-2011-4313) y el fallo reportado es el siguiente:



Los servidores afectados fallan luego de registrar un error en query.c con el siguiente mensaje: "INSIST(! dns_rdataset_isassociated(sigrdataset))".
Hay reportes de múltiples versiones afectadas, incluyendo todas las versiones de ISC BIND9 soportadas en producción para este momento.
ISC está investigando activamente la causa raíz y trabajando para producir actualizaciones que previenen la falla.
La solución propuestas es actualizar a una versión con un parche paliativo, todavía no oficial del Bind9.
Más info:
https://www.isc.org/advisorycve20114313ES
Leer más

Round Robin DNS


Una de las formas más simples de escalar una aplicación web (o cualquier otro servicio) es la conocida como Round Robin DNS. RR-DNS es una técnica de balanceo de carga realizada desde los propios servidores DNS y no desde una máquina dedicada.
Round Robin es un algoritmo que permite seleccionar elementos de forma equitativa y por orden. Generalmente lo que se hace es crear una lista con todos los elementos y éstos luego son devueltos en orden. Cuando se ha recorrido toda la lista, se comienza de nuevo. Si se aplica este algoritmo a DNS, se puede comprender la forma de funcionamiento. Un nombre DNS tiene varias IP's detrás que pueden contestar a él, albergadas en diferentes servidores. Cuando un cliente pide la página, se envía a un servidor, al siguiente cliente se le mandará al siguiente servidor y así siempre. La carga se distribuye a través de los N equipos que formen el cluster, pero todo desde un DNS.
Leer más

Cómo oculta la versión de BIND

bind es un servidor DNS de los más comúnmente usados en sistemas GNU/Linux y es por ello que también tiene ciertas vulnerabilidades conocidas. Es cierto que gracias a su popularidad se parchean muy rápido, pero muchos de los administradores de sistemas no aplican esos parches tan rápidamente.
Una forma de 'proteger' el sistema, aunque no la mejor ni la más fiable, desde luego, es ocultar la versión. Saber la versión de bind que se está a ejecutar en un servidor remoto es bastante simple con el comando dig y es por ello que sí se debería de ocultar.
shell> dig -c CH -t txt version.bind @ns1.miempresa.com
...
;; QUESTION SECTION:
;version.bind.                  CH      TXT

;; ANSWER SECTION:
version.bind.           0       CH      TXT     "9.3.1"
...
Como se observa, descubrir la versión de bind es sencillo, sólo es cuestión de preguntarle al servidor y éste responderá, siempre que sea un bind.

Podemos ofuscar la información de la versión

Dentro del fichero de configuración de bind (/etc/bind/named.conf.options) se puede poner añadir la opción version, con el valor que se desea mostrar, pudiendo así engañar a la persona que lo consulta.
options {
        version "3.1";
};
Si ahora se vuelve a lanzar la petición de versión al servidor:
shell> dig -c CH -t txt version.bind @ns1.miempresa.com
...
;; QUESTION SECTION:
;version.bind.                  CH      TXT

;; ANSWER SECTION:
version.bind.           0       CH      TXT     "3.1"
...

Cómo ocultamos la versión del servidor

bind permite establecer un valor none a la variable version con el que se consigue no devolver nada ante la petición de versión. Es una forma rápida y sencilla de ocultar la versión de bind ejecutada.
options {
        version none;
};
Si ahora se vuelve a lanzar la petición de versión al servidor:
shell> dig -c CH -t txt version.bind @ns1.miempresa.com
...
;; QUESTION SECTION:
;version.bind.                  CH      TXT
...

Existen formas de poder averiguar, o cuando menos aproximarse a la versión de bind que está instalada aunque se aplique este pequeño truco. Mira como aquí.
Leer más

Formulario de contacto

Nombre

Correo electrónico *

Mensaje *

Últimos comentarios