Tienda Wifi

Tienda Wifi
CiudadWireless es la tienda Wifi recomendada por elhacker.NET

Entradas Mensuales

Síguenos en:

Canal Oficial Telegram de elhacker.NET Grupo Facebook elhacker.NET Twitter elhacker.NET Canal Youtube elhacker.NET Comunidad Steam: Grupo elhacker.NET Mastodon

Entradas populares

PostHeaderIcon Seguridad DNS en BIND (named) y registros IPv6


DNS corresponde a las siglas en inglés de "Domain Name System", es decir, "Sistema de nombres de dominio". La función de este sistema es organizar e identificar dominios. Berkeley Internet Name Domain (BIND) es el servidor DNS por excelencia usando en Internet.





La asignación de nombres a direcciones IP es ciertamente la función más conocida de los protocolos DNS. Por ejemplo, si la dirección IP del sitio FTP de elhacker.net es 91.126.217.153, la mayoría de la gente llega a este equipo especificando ftp.elhacker.net y no la dirección IP. Además de ser más fácil de recordar, el nombre es más fiable. La dirección numérica podría cambiar por muchas razones, sin que tenga que cambiar el nombre.

bind8 está totalmente obsoleto y debemos usar bind9

Servidor DNS público (abierto) (Consultas recursivas)

Una consulta recursiva, es una consulta DNS a un dominio que nosotros no administramos (respuestas autoritativas) pero respondemos igualmente haciendo uso de los forwarders. Es decir aceptamos consultas (querys) dns a cualquiera que pregunte.

Se calcula que hay más 30 millones de servidores DNS recursivos (open) vulnerables (a fecha de Octubre de 2013) -Reporte de http://openresolverproject.org

Comprobar si una IP es "open resolver"

dig +short test.openresolver.com TXT @IP


Por defecto servidor bind (named) está configurado para ser recursivo (fichero de configuración named.conf)

options {
         recursion no;
}
Nuestro servidor puede ser recursivo, pero siempre aceptando sólo peticiones de nuestra red local o de nuestros clientes mediante ACL's (Listas de acceso)

recursion yes;
allow-query { localhost; };
allow-recursion { localhost; };
allow-query-cache { localhost; };
Creando una ACL:

acl redlocal {
  127.0.0.1;
  192.168.0.2;
  192.168.0.1/24;
};

Permitiendo al grupo "redlocal"

 recursion yes;
allow-query { localhost; redlocal; };
allow-recursion { localhost; redlocal; };
allow-query-cache { localhost; redlocal; };
O usando las vistas (views):

//Put all your “trusted” IPs in here.
acl "inside" {
127/8; 10.0.10/24; 192.168.1/24; };
//zone declarations go here.
view "inside" {
match-clients { "inside"; };
recursion yes;
};
//Same zone declarations go here too.
view "outside" {
match-clients { any; };
recursion no;
};


Si somos recursivos se pueden producir ataques de varios tipos:


  • DNS Cache Poisoning Attacks  (aprovechando el TTL)
  • DNS Amplification and Reflection Attacks
  • Ataques DDoS

Por defecto no deberíamos aceptar transferencias ni actualizaciones de zona de nadie:

options {
allow-update { none; };
allow-transfer { none; };
}

Logging en named.conf


Una parte muy importante es guardar los logs

logging { channel default_syslog {
// Send most of the named messages to syslog.
syslog local2;
severity debug;
};
channel audit_log {
// Send the security related messages to a separate file.
file "/var/named/bind/named.log";
severity debug;
print-time yes;
};
category default { default_syslog; };
category general { default_syslog; };
category security { audit_log; default_syslog; };
category config { default_syslog; };
category resolver { audit_log; };
category xfer-in { audit_log; };
category xfer-out { audit_log; };
category notify { audit_log; };
category client { audit_log; };
category network { audit_log; };
category update { audit_log; };
category queries { audit_log; };
category lame-servers { audit_log; };
}; 


Configuración avanzada


DNS Security Extensions (DNSSEC)


DNSSEC permite asegurar la autenticidad de la respuesta DNS. Siempre que el navegador envíe una petición, ésta se devuelve con una clave de autentificación, que atestigua que la IP reenviada es correcta.

Para entender el DNSSEC, se debe entender qué es la asymmetric cryptography (criptografía asimétrica). Esta consiste en dos claves: una pública y otra privada.

La clave privada suele generarse en información cifrada, mientras la clave pública solo permite la lectura.
La clave privada es necesaria para generar una clave pública. Por lo tanto, si tu clave pública cifrada o tu información es corrupta, no podrá leer la información.

Actualmente se recomienda cambiar la ZSJ cada 3 meses y la KSK cada año y debe tener presente que ha de validar su zona TLD.

En el caso de DNSSEC, después de que el administrador haya añadido un cifrado a ese área(RRSIG), el DNS de cada campo usa su clave privada y hace disponible una clave pública (DNSKEY), por lo que usted podrá leer. Y nosotros pasamos una huella en el registro clave (DS).


  • ZSK : Compuesta de una clave pública y una clave privada, se usan para consignar los campos en el área. Estas claves son desconocidas para el registro.
  • KSK : Compuesta de una clave pública y una clave privada, se usan solo para consignar las claves ZSK. Estas claves son consignadas por un campo DS en la zona parental.
  • DNSKEY : Campos que contienen la clave pública.
  • DS : Esta es un truncamiento de una DNSKEY, es reenviado a la zona parental.


Fichero /etc/named.conf

dnssec-enable yes;
dnssec-validation yes;

Para BIND 9.8 y 9.9

Si elegimos auto se descarga la root key la primera vez que se ejecuta
dnssec-validation auto
dnssec-lookaside auto

Para BIND 9.7, es manual:

/* Path to ISC DLV key */
bindkeys-file "/etc/named.iscdlv.key";
managed-keys-directory "/var/named/dynamic";
Las llaves DLV ((DNSSEC Look-aside Validation) son un recurso adicional utilizado en aquellos servidores DNSSEC con recursividad.
trusted-keys {
dlv.isc.org. 257 3 5 "BEAAAAPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2 brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+jAGl2FZLK8t+ 1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5 ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte/URk Y62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboM QKtUdvNXDrYJDSHZws3xiRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VSt TDN0YUuWrBNh";
};


Disponibles en:

https://www.isc.org/downloads/bind/bind-keys/

zone "elhacker.net" IN {
type master;
file "elhacker.net.zone.signed";
};
Para "firmar" las zonas tenemos varias opciones


  •  dnssec-keygen
  • dnssec-tools (zonesigner)


Posibles Errores:

25-Dec-2013 12:42:53.427 error (no valid RRSIG) resolving 'd1.whatsapp.net.dlv.isc.org/DS/IN': 8.8.4.4#53

Opciones de seguridad

Las transferencias de zona pueden consumir muchos recursos.

Limitar transferencias solicitadas de dominio:

options {
transfers-per-ns 2;
};
Limitando el número total de las transferencias de zona solicitada

options {
transfers-in 10;
};
Limitando el número total de las transferencias de zona servida


options {
transfers-out 10;
};

Limitando la duración de la transferencia de un dominio en minutos:


options {
max-transfer-time-in 180;
};

Limitar la frecuencia de las transferencias de zona:

options {
max-refresh-time 86400; // refresh should never be more than a day
min-refresh-time 1800; // or less than 30 minutes }; 

Response Rate Limiting (RRL)

BIND9  permite a un administrador limitar el número máximo de respuestas por segundo que se envían a un cliente.
 rate-limit {
    responses-per-second 5;
    window 5;
};

 Limitando los recursos

Máximo 2 GB de RAM:

options {
datasize 2g;
};

Máximo de memoria para la caché:

options {
max-cache-size  2g;
};

Errores comunes fichero syslog


Dec 19 22:48:42 ns2 named[31598]: success resolving 'weblist.teamspeak.com/A' (in 'teamspeak.com'?) after disabling EDNS
Dec 19 22:48:44 ns2 named[31598]: success resolving 'www.google.es/A' (in 'google.es'?) after reducing the advertised EDNS UDP packet size to 512 octets
Dec 19 22:48:44 ns2 named[31598]: success resolving 'clients3.google.com/A' (in 'google.com'?) after disabling EDNS

Soluciones: asjutar tamaño udp-size a 512:

edns-udp-size 512;

La variable max-udp-size controla el max que tu envias, edns-udp-size lo que recibes.

Se puede deshabilitar edns (fuera de la clausula options), pero no es una opción recomendada.

server 0.0.0.0/0 {
       edns no;
};
Y en IPv6

server ::/0 {
       edns no;
};

error (unexpected RCODE REFUSED) resolving
20-Dec-2013 10:39:47.838 error (unexpected RCODE REFUSED) resolving '129.230.114.75.in-addr.arpa/PTR/IN': 71.44.33.20#53
20-Dec-2013 10:39:47.981 error (unexpected RCODE REFUSED) resolving '129.230.114.75.in-addr.arpa/PTR/IN': 71.44.37.20#53
20-Dec-2013 10:39:49.716 error (unexpected RCODE REFUSED) resolving '104.16.114.75.in-addr.arpa/PTR/IN': 71.44.37.20#53
20-Dec-2013 10:39:49.856 error (unexpected RCODE REFUSED) resolving '104.16.114.75.in-addr.arpa/PTR/IN': 71.44.33.20#53

Son los servidores "forwarders" que renuncian nuestras consultas, suelen ser como en nuestro caso a querys de reversos ( .in-addr.arpa)

Gestión de Errores y Rendimiento (Tunning)


named[pid]: socket(SOCK_RAW): Too many open files

Añadir el número de ficheros abiertos:

options {
files number;
};

  • clients-per-query
  • tcp-clients
  • recursive-clients


no more recursive clients: quota reached

Permitir más clientes recursivos (por defecto son 100)

options { recursive-clients 2000;};

Errores host unreachable o network unreachable
error (host unreachable) resolving ....
error (host unreachable) resolving 'hotmail.com/AAAA/IN': 209.244.0.4#53
error (host unreachable) resolving 'gmail.com/AAAA/IN': 8.8.8.8#53
En algunos casos puede deberse a utilizar la opción query-source en named.conf

options {
 // no usar
  query-source address * port 53;
} 
Recordemos que el query-soruce sólo se aplica a las consultas salientes, es decir, al tráfico saliente y las entrantes seguirán siendo por el puerto 53, pero puede ser peligroso, concecntrar todo el tráfico (entrante y saliente) por el mismo puerto dando incluso eventuales errores.


error (network unreachable) resolving ...
error (network unreachable) resolving 'e.root-servers.net/AAAA/IN': 2001:500:2f::f#53
error (network unreachable) resolving 'dns.ovh.net/A/IN': 2001:500:2d::d#53
 error (network unreachable) resolving 'ns.ovh.net/A/IN': 2001:41d0:1:1983::1#53

Vemos que hay dirección IPv6

Si los errores son network unreachable es muy probable que las peticiones sean a servidores DNS IPv6 y y si nosotros no tenemos una red dual-stack (IPv4 + IPv6) no somos capaces de leer la respuesta.

Para solucionarlo podemos añadir la opción -4 para arrancar Bind (named) en el fichero /etc/sysconfig/named

OPTIONS="-4
También podemos deshabilitar por completo la red IPv6 en grub.conf con el parámetro:

ipv6.disable=1

O en el fichero sysctl.conf

# disable ipv6
net.ipv6.conf.eth0.disable_ipv6 = 1
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

O bien en el fichero /etc/sysconfig/network-scripts/ifcfg-eth0

IPV6INIT=no
IPV6_AUTOCONF=no

limit responses to 188.165.235.0/24
stop limiting error responses to 176.221.80.0/24

Por defecto son 100:

clients-per-query increased to 15
clients-per-query decreased to 13

Registros AAAA ipv6

El porcentaje del uso de IPv6 se va extendiendo y en este momento el 90,1% de TLD'S ya aceptan Ipv6


Top Level Domains (TLDs): 362

TLDs with IPv6 nameservers: 326
Percentage of TLDs with IPv6 nameservers: 90.1%  

Añadir al fichero  de configuración named.conf

options {
...
listen-on-v6 {any};
...
}

Los registros Ipv6 se hacen con AAAA (cuatro A's) que es el equivalente al registro A de ipv4

www.elhacker.net.    IN    A     2001:4860:4860:0:0:0:0:8888
foro.elhacker.net.    IN    A     2001:4860:4860:0:0:0:0:8888


Por supuesto se puede mezclar registros ipv4 con registros ipv6 (siempre y cuando tengamos la pila dual) (dual (IPv4/IPv6) IP stacks)

www.elhacker.net.    IN    A    91.126.217.153
foro.elhacker.net.    IN    A    91.126.217.153
www.elhacker.net.    IN    AAAA     2001:4860:4860:0:0:0:0:8888
foro.elhacker.net.    IN    AAAA     2001:4860:4860:0:0:0:0:8888
El orden por defecto de prioridad IPv4-IPv6 es cíclico o basado en round-robin.

O de una manera más simple y organizada:

www    IN    A    91.126.217.153
       .    IN    AAAA    2001:4860:4860:0:0:0:0:8888
foro      IN    A     91.126.217.153
            IN    AAAA     2001:4860:4860:0:0:0:0:8888
 
Ejemplo de configuración: 
 
$TTL 1h ; Default TTL
@ IN SOA ns.elhacker.net. webmaster.elhacker.net. (
 2013122001 ; serial
 1h  ; slave refresh interval
 15m  ; slave retry interval
 1w  ; slave copy expire time
 1h  ; NXDOMAIN cache time
 )

;
; domain name servers
;
@ IN NS ns.elhacker.net.


 O muchos servicios usan el subodminio (Google, Facebook, Youtube) o previfo ipv6 para indicarlo:

 ipv6.elhacker.net.    IN    AAAA     2001:4860:4860:0:0:0:0:8888

Para comprobar si funciona correctamente podemos hacer una query (consulta con dig a localhost)

dig -6 +short @::1  www.elhacker.net AAA

O preguntando al servidor público de Google DNS

dig @2001:4860:4860::8888 www.elhacker.net. AAAA +cd

Registros Inversos (Reversos) PTR con IPv6

 Los registros llamados IN-ADDR.ARPA  pasan a ser  IP6.ARPA

; IPv6 PTR entries
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.0.2.0.1.0.2.0.8.f.4.0.1.0.a.2.ip6.arpa. IN PTR ns.elhacker.net.

Y en named.conf

zone "2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.0.2.0.1.0.2.0.8.f.4.0.1.0.a.2.ip6.arpa"
{
 type master;
 file "/etc/bind/2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.0.2.0.1.0.2.0.8.f.4.0.1.0.a.2.ip6.arpa";
};

Servidores públicos DNS en formato IPv6

Servidores DNS Google IPv4
  • 8.8.8.8
  • 8.8.4.4
Servidores DNS Google IPv6
  • 2001:4860:4860::8888
  • 2001:4860:4860::8844

Servidores OpenDNS  IPv4
  • 208.67.222.222
  • 208.67.222.220

Servidores OpenDNS  IPv6
  • 2620:0:ccc::2
  • 2620:0:ccd::2


0 comentarios :

Publicar un comentario

Los comentarios pueden ser revisados en cualquier momento por los moderadores.

Serán publicados aquellos que cumplan las siguientes condiciones:
- Comentario acorde al contenido del post.
- Prohibido mensajes de tipo SPAM.
- Evite incluir links innecesarios en su comentario.
- Contenidos ofensivos, amenazas e insultos no serán permitidos.

Debe saber que los comentarios de los lectores no reflejan necesariamente la opinión del STAFF.