Tutoriales y Manuales
Entradas Mensuales
-
►
2024
(Total:
1077
)
- ► septiembre (Total: 50 )
-
►
2023
(Total:
710
)
- ► septiembre (Total: 65 )
-
►
2022
(Total:
967
)
- ► septiembre (Total: 72 )
-
►
2021
(Total:
730
)
- ► septiembre (Total: 56 )
-
►
2020
(Total:
212
)
- ► septiembre (Total: 21 )
-
►
2019
(Total:
102
)
- ► septiembre (Total: 14 )
-
►
2017
(Total:
231
)
- ► septiembre (Total: 16 )
-
►
2016
(Total:
266
)
- ► septiembre (Total: 38 )
-
►
2015
(Total:
445
)
- ► septiembre (Total: 47 )
-
►
2014
(Total:
185
)
- ► septiembre (Total: 18 )
-
▼
2013
(Total:
100
)
-
▼
diciembre
(Total:
8
)
- Tutorial Avidemux para cortar, unir, convertir vídeos
- HandBrake y libdvdcss para copiar DVD's protegidos
- DDoS Deflate, script bash para mitigar ataques DoS
- Seguridad DNS en BIND (named) y registros IPv6
- SteamOS Beta ya disponible
- Niveles RAID (Tipos, ventajas e inconvenientes)
- Medir velocidad de las DNS: mejores y más rápidas
- Gestión de paquetes en Linux con Yum
- ► septiembre (Total: 3 )
-
▼
diciembre
(Total:
8
)
-
►
2011
(Total:
7
)
- ► septiembre (Total: 1 )
Blogroll
Etiquetas
seguridad
(
396
)
privacidad
(
364
)
google
(
354
)
ransomware
(
341
)
vulnerabilidad
(
305
)
Malware
(
264
)
Windows
(
246
)
android
(
244
)
cve
(
237
)
tutorial
(
236
)
manual
(
221
)
software
(
205
)
hardware
(
196
)
linux
(
125
)
twitter
(
117
)
ddos
(
95
)
WhatsApp
(
92
)
Wifi
(
85
)
cifrado
(
77
)
herramientas
(
75
)
hacking
(
73
)
sysadmin
(
67
)
app
(
65
)
Networking
(
56
)
nvidia
(
53
)
ssd
(
51
)
youtube
(
50
)
adobe
(
43
)
firmware
(
43
)
office
(
41
)
hack
(
40
)
firefox
(
36
)
contraseñas
(
32
)
eventos
(
32
)
antivirus
(
31
)
juegos
(
31
)
cms
(
30
)
flash
(
28
)
anonymous
(
27
)
apache
(
26
)
MAC
(
25
)
programación
(
25
)
exploit
(
23
)
multimedia
(
23
)
javascript
(
22
)
Kernel
(
20
)
ssl
(
19
)
SeguridadWireless
(
17
)
documental
(
16
)
Forense
(
15
)
conferencia
(
15
)
Debugger
(
14
)
lizard squad
(
14
)
técnicas hacking
(
13
)
auditoría
(
12
)
delitos
(
11
)
metasploit
(
11
)
Virtualización
(
10
)
adamo
(
9
)
reversing
(
9
)
Rootkit
(
8
)
Ehn-Dev
(
7
)
MAC Adress
(
6
)
antimalware
(
6
)
oclHashcat
(
5
)
Entradas populares
-
Después de ver qué es una vCPU y la diferencia entre núcleos (cores) e hilos en los procesadores, pasamos a explicar toda la nomenclatura d...
-
Un conector HDMI dummy o fantasma no es más que un HDMI que simula que hay una pantalla conectada. Tienen una variedad de propósitos útil...
-
En WhatsApp se han dicho verdaderas barbaridades. Todos hemos cometido el error de escribir algo en caliente . Y de arrepentirnos. Tal vez ...
Seguridad DNS en BIND (named) y registros IPv6
domingo, 22 de diciembre de 2013
|
Publicado por
el-brujo
|
Editar entrada
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
Por defecto servidor bind (named) está configurado para ser recursivo (fichero de configuración named.conf)
Permitiendo al grupo "redlocal"
Si somos recursivos se pueden producir ataques de varios tipos:
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).
Fichero /etc/named.conf
Para BIND 9.8 y 9.9
Si elegimos auto se descarga la root key la primera vez que se ejecuta
Para BIND 9.7, es manual:
Disponibles en:
https://www.isc.org/downloads/bind/bind-keys/
Posibles Errores:
Limitar la frecuencia de las transferencias de zona:
Máximo de memoria para la caché:
Soluciones: asjutar tamaño udp-size a 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.
Son los servidores "forwarders" que renuncian nuestras consultas, suelen ser como en nuestro caso a querys de reversos ( .in-addr.arpa)
Añadir el número de ficheros abiertos:
Permitir más clientes recursivos (por defecto son 100)
Errores host unreachable o network unreachable
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
O en el fichero sysctl.conf
O bien en el fichero /etc/sysconfig/network-scripts/ifcfg-eth0
Por defecto son 100:
Añadir al fichero de configuración named.conf
Los registros Ipv6 se hacen con AAAA (cuatro A's) que es el equivalente al registro A de ipv4
Por supuesto se puede mezclar registros ipv4 con registros ipv6 (siempre y cuando tengamos la pila dual) (dual (IPv4/IPv6) IP stacks)
O de una manera más simple y organizada:
O muchos servicios usan el subodminio (Google, Facebook, Youtube) o previfo ipv6 para indicarlo:
Para comprobar si funciona correctamente podemos hacer una query (consulta con dig a localhost)
O preguntando al servidor público de Google DNS
Y en named.conf
Servidores OpenDNS IPv4
Servidores OpenDNS IPv6
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 {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 no;
}
recursion yes;Creando una ACL:
allow-query { localhost; };
allow-recursion { localhost; };
allow-query-cache { localhost; };
acl redlocal {
127.0.0.1;
192.168.0.2;
192.168.0.1/24;
};
Permitiendo al grupo "redlocal"
recursion yes;O usando las vistas (views):
allow-query { localhost; redlocal; };
allow-recursion { localhost; redlocal; };
allow-query-cache { localhost; redlocal; };
//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 */Las llaves DLV ((DNSSEC Look-aside Validation) son un recurso adicional utilizado en aquellos servidores DNSSEC con recursividad.
bindkeys-file "/etc/named.iscdlv.key";
managed-keys-directory "/var/named/dynamic";
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 {Para "firmar" las zonas tenemos varias opciones
type master;
file "elhacker.net.zone.signed";
};
- 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 {Limitando el número total de las transferencias de zona solicitada
transfers-per-ns 2;
};
options {Limitando el número total de las transferencias de zona servida
transfers-in 10;
};
options {Limitando la duración de la transferencia de un dominio en minutos:
transfers-out 10;
};
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 {Y en IPv6
edns no;
};
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 ....En algunos casos puede deberse a utilizar la opción query-source en named.conf
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
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.options {// no usarquery-source address * port 53;}
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="-4Tambié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 Ipv6Top 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.153El orden por defecto de prioridad IPv4-IPv6 es cíclico o basado en round-robin.
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
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
- 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
Enviar por correo electrónico
Escribe un blog
Compartir en X
Compartir con Facebook
Compartir en Pinterest
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.