Si, todos en el mismo lugar y esa red no forma parte de la red de los resolver, estaba pensando pedir ayuda al área de redes ;)
Atte.
MDS
________________________________
De: dns-esp-bounces(a)listas.nic.cl
Para: DNS en español
Enviado: Wed Jun 06 21:38:04 2012
Asunto: Re: [dns-esp] Actualización resolver
Pero todos están en el mismo lugar?
este puede estar expuesto a un trafico al que no lo estan los otros.
Es la 10.30.40.50 parte de tu red?
Slds
as
On 5 Jun 2012, at 13:29, Del Solar Navarrete Maria Cristina wrote:
Gracias, pero es que es extraño, porque 8 resolver ya he actualizado 7 y sólo 1 presenta ese síntoma y digamos que la configuración es similar para todos :S
Atte.
{
M. Cristina Del Solar N. _ TAM ISP
Ingeniería UNIX
Subg. Ingeniería Serv. Outsourcing TI
Gerencia SERTI - Entel S.A.
*
De: dns-esp-bounces(a)listas.nic.cl [mailto:dns-esp-bounces@listas.nic.cl] En nombre de Mauricio Vergara Ereche
Enviado el: martes, 05 de junio de 2012 12:19
Para: DNS en español
Asunto: Re: [dns-esp] Actualización resolver
Hola!
Lo más probable es que necesites crear unas ACL y agregarlas al allow-recursion {}; dentro del options
Al cambiar a una versión más nueva, el resolver te pide especificar de dónde pueden hacerle las consultas.
Saludos!
El 5 de junio de 2012 12:07, Del Solar Navarrete Maria Cristina <MDelSolar(a)entel.cl> escribió:
Estimados
Estoy actualizando mis resolver y en uno de ellos veo el siguiente mensaje:
Jun 5 11:48:48 sobek named[2382]: client 10.30.40.50#46402: query (cache) 'www.entel.cl/A/IN' denied
Jun 5 11:48:48 sobek named[2382]: client 10.30.40.50#38542: query (cache) 'www.entel.cl/A/IN' denied
Jun 5 11:53:39 sobek named[2382]: client 10.30.40.50#37488: query (cache) 'www.google.cl/A/IN' denied
Jun 5 11:53:39 sobek named[2382]: client 10.30.40.50#32820: query (cache) 'www.google.cl/A/IN' denied
Jun 5 11:53:48 sobek named[2382]: client 10.30.40.50#39428: query (cache) 'www.entel.cl/A/IN' denied
Jun 5 11:53:48 sobek named[2382]: client 10.30.40.50#46799: query (cache) 'www.entel.cl/A/IN' denied
Jun 5 11:58:38 sobek named[2382]: client 10.30.40.50#53043: query (cache) 'www.google.cl/A/IN' denied
Jun 5 11:58:38 sobek named[2382]: client 10.30.40.50#60089: query (cache) 'www.google.cl/A/IN' denied
Jun 5 11:58:48 sobek named[2382]: client 10.30.40.50#53536: query (cache) 'www.entel.cl/A/IN' denied
Jun 5 11:58:48 sobek named[2382]: client 10.30.40.50#33498: query (cache) 'www.entel.cl/A/IN' denied
Algún indicio?
Actalicé a RH 6.2, bind 9.7.3-8.P3
Es necesaria alguna otra información?
Gracias de antemano
{
M. Cristina Del Solar N. _ TAM ISP
Ingeniería UNIX
Subg. Ingeniería Serv. Outsourcing TI
Gerencia SERTI - Entel S.A.
*
La información contenida en esta transmisión (y sus documentos adjuntos), es confidencial y no puede ser usada o difundida por personas distintas a su(s) destinatario(s). El uso no autorizado por los representantes legales de ENTEL S.A., de la información contenida en esta transmisión puede ser sancionado criminalmente de conformidad con la ley chilena. Si ha recibido esta transmisión por error, por favor destrúyala y notifique al remitente. Atendido que no existe certidumbre que el presente mensaje no ha sido modificado como resultado de su transmisión por correo electrónico, o retrasmitido sin alteración alguna; Entel S.A. no será responsable del contenido del mismo ni puede entenderse como emanado de sus representantes legales o transmitido con la autorización previa de ellos.
_______________________________________________
dns-esp mailing list
dns-esp(a)listas.nic.cl
https://listas.nic.cl/mailman/listinfo/dns-esp
--
Mauricio Vergara Ereche
+56 99 1241718
Viña del Mar/Santiago - CHILE
http://mave.cero32.cl
La información contenida en esta transmisión (y sus documentos adjuntos), es confidencial y no puede ser usada o difundida por personas distintas a su(s) destinatario(s). El uso no autorizado por los representantes legales de ENTEL S.A., de la información contenida en esta transmisión puede ser sancionado criminalmente de conformidad con la ley chilena. Si ha recibido esta transmisión por error, por favor destrúyala y notifique al remitente. Atendido que no existe certidumbre que el presente mensaje no ha sido modificado como resultado de su transmisión por correo electrónico, o retrasmitido sin alteración alguna; Entel S.A. no será responsable del contenido del mismo ni puede entenderse como emanado de sus representantes legales o transmitido con la autorización previa de ellos._______________________________________________
dns-esp mailing list
dns-esp(a)listas.nic.cl
https://listas.nic.cl/mailman/listinfo/dns-esp
La informaci�n contenida en esta transmisi�n (y sus documentos adjuntos), es confidencial y no puede ser usada o difundida por personas distintas a su(s) destinatario(s). El uso no autorizado por los representantes legales de ENTEL S.A., de la informaci�n contenida en esta transmisi�n puede ser sancionado criminalmente de conformidad con la ley chilena. Si ha recibido esta transmisi�n por error, por favor destr�yala y notifique al remitente. Atendido que no existe certidumbre que el presente mensaje no ha sido modificado como resultado de su transmisi�n por correo electr�nico, o retrasmitido sin alteraci�n alguna; Entel S.A. no ser� responsable del contenido del mismo ni puede entenderse como emanado de sus representantes legales o transmitido con la autorizaci�n previa de ellos.
Estimados
Estoy actualizando mis resolver y en uno de ellos veo el siguiente mensaje:
Jun 5 11:48:48 sobek named[2382]: client 10.30.40.50#46402: query (cache) 'www.entel.cl/A/IN' denied
Jun 5 11:48:48 sobek named[2382]: client 10.30.40.50#38542: query (cache) 'www.entel.cl/A/IN' denied
Jun 5 11:53:39 sobek named[2382]: client 10.30.40.50#37488: query (cache) 'www.google.cl/A/IN' denied
Jun 5 11:53:39 sobek named[2382]: client 10.30.40.50#32820: query (cache) 'www.google.cl/A/IN' denied
Jun 5 11:53:48 sobek named[2382]: client 10.30.40.50#39428: query (cache) 'www.entel.cl/A/IN' denied
Jun 5 11:53:48 sobek named[2382]: client 10.30.40.50#46799: query (cache) 'www.entel.cl/A/IN' denied
Jun 5 11:58:38 sobek named[2382]: client 10.30.40.50#53043: query (cache) 'www.google.cl/A/IN' denied
Jun 5 11:58:38 sobek named[2382]: client 10.30.40.50#60089: query (cache) 'www.google.cl/A/IN' denied
Jun 5 11:58:48 sobek named[2382]: client 10.30.40.50#53536: query (cache) 'www.entel.cl/A/IN' denied
Jun 5 11:58:48 sobek named[2382]: client 10.30.40.50#33498: query (cache) 'www.entel.cl/A/IN' denied
Algún indicio?
Actalicé a RH 6.2, bind 9.7.3-8.P3
Es necesaria alguna otra información?
Gracias de antemano
{
M. Cristina Del Solar N. _ TAM ISP
Ingeniería UNIX
Subg. Ingeniería Serv. Outsourcing TI
Gerencia SERTI - Entel S.A.
*
La información contenida en esta transmisión (y sus documentos adjuntos), es confidencial y no puede ser usada o difundida por personas distintas a su(s) destinatario(s). El uso no autorizado por los representantes legales de ENTEL S.A., de la información contenida en esta transmisión puede ser sancionado criminalmente de conformidad con la ley chilena. Si ha recibido esta transmisión por error, por favor destrúyala y notifique al remitente. Atendido que no existe certidumbre que el presente mensaje no ha sido modificado como resultado de su transmisión por correo electrónico, o retrasmitido sin alteración alguna; Entel S.A. no será responsable del contenido del mismo ni puede entenderse como emanado de sus representantes legales o transmitido con la autorización previa de ellos.
se ha descubierto una vulnerabilidad en el servidor de nombres de
dominio Bind, que podría provocar una denegación de servicio en el
proceso named.
El procesamiento de determinados registros DNS donde el campo rdata es
de tamaño cero o está vacio, puede producir resultados inesperados. Los
servidors recursivos pueden fallar o divulgar direcciones de memoria al
cliente. Además, los servidores secundarios pueden fallar al reinicio
después de realizar una transferencia de zona que contenga estos
registros. Los servidores maestros podrían también corromper los datos
de la zona si la opción de zona /"auto-dnssec"/ tiene el valor /"maintain"/.
*Impacto:*
* Denegación de servicio en bind
http://www.cert.inteco.es/securityAdvice/Actualidad/Avisos_seguridad_tecnic…
Saludos.
Buenas tardes,
Mi nombre es Francisco Vargas y soy ingeniero de una compañía de cable. Estoy encargado de la administración de los DNS.
He recibido un ataque que consistió en la saturación de mis servidores a través de peticiones a "ripe.net". Parece ser una especie de botnet que se propagó por varios CPUs (108 direcciones IP consultaban desmedidamente hacia ese dominio) de nuestros clientes. Mis DNSs están configurados con Bind y la plataforma sólo responde a las direcciones IP de nuestros clientes.
¿Alguien sabe de algún virus que pueda causar este tipo de problemas? Otro punto importante es que se activó en el mismo momento; es decir, parece que el botnet pudo haber sido activado a través de un C&C.
Justo antes del ataque logré capturar esta petición sospechosa (que fue denegada):
May 28 11:53:21 XXXXXXXX named[5841]: client 80.82.70.138#53: query (cache) 'ripe.net/ANY/IN<http://ripe.net/ANY/IN>' denied
May 28 11:28:15 XXXXXXXX named[4367]: client 80.82.70.138#53: query (cache) 'ripe.net/ANY/IN<http://ripe.net/ANY/IN>' denied
Además las peticiones que inundaron mis servidores eran de la siguiente forma (elimino la dirección IP por no ser de interés):
29-May-2012 14:53:11.185 client DIRECCION_IP#32768: query: ripe.net IN ANY +ED (DIRECCION_IP_DE_NUESTRO_SERVER)
Quisiera alguna retroalimentación; en estos momentos estoy controlando el ataque mediante listas de acceso que deniegan solicitudes de estos clientes.
¿Alguien sabe alguna forma de hacer que Bind deniegue respuestas a IPs que hacen peticiones desmedidas? ¿O alguna forma de control similar?
LES RUEGO AYUDARME CON ESTE ASUNTO.
Saludos,
Ing. Francisco Vargas
Hola lista,
Tengo una consulta y creo que este es el sitio ideal para la misma.
Como ustedes saben, al menos en bind y en varias herramientas
online que permiten administrar zonas DNS no es posible apuntar el
registro @ a un CNAME (limitante del RFC 1033).
Mi pregunta es que artilugio usan ustedes en estos casos?. Es un
problema muy grande porque muchos proveedores piden apuntar el dominio
a un CNAME (pe. google y amazon). Es muy triste quedarse sin el www.
Con lo anterior quiero decir que no puedo hacer:
@ IN CNAME www12-gf-cloudservice.amazon.com (esto es lo que quiero)
pero si puedo
@ IN A 192.168.1.1
Alguna idea?
Gracias a todos,
Saludos,
Alejandro Acosta,
http://blog.acostasite.com
Hola a todos los listeros de este nueva comunidad, yo por aca nuevamente
molestando.....
Algún documento, link mas menos actualizado referente a políticas o
configuraciones de seguridad para Bind9 ???
he encontrado varios pero no son del todo claros y mas de alguno se
contradice con otro, ademas de no tener una suficiente explicación o
fundamentos del porque aplicar una regla u otra.
les comento la configuracion que he realizado para tener un panorama mas
claro
tengo un dns primario y secundario, ambos poseen 2 ethernet una esta
mirando al mundo con una ip publica y la otra apuntando a una lan...
IP local NS1 172.16.1.2/24
IP local NS2 172.16.1.3/24
aquí el named.conf.local del ns1
acl "slaves" {
172.16.1.3;
};
zone "midominio.cl" {
type master;
file "/etc/bind/db.midominio";
allow-query { any; }; //Permitimos consultas a cualquier host
allow-transfer { slaves; }; //Permitimos transferencias solamente a los
esclavos
};
zone "84.77.164.in-addr.arpa" {
type master;
file "/etc/bind/db.164";
allow-query { any; }; //Permitimos consultas a cualquier host
allow-transfer { slaves; }; //Permitimos transferecias solamente a los
esclavos
};
Aquí el named.conf.local del ns2
zone "midominio.cl" {
type slave;
file "/etc/bind/slave/db.midominio";
masters {172.16.1.2; };
};
zone "84.77.164.in-addr.arpa" {
type slave;
file "/etc/bind/slave/db.164";
masters {172.16.1.2; };
};
ambos equipos solo se pueden administrar desde la lan ademas tienen un
shorewall por el cual se han bloqueado todos los puertos hacia internet
botando todos los paquetes que no pertenezcan a solicitudes del puerto 53
tanto tcp como udp
alguna idea??? fundamentos??
todo sera muy bien recibido por este chiquillo que esta ansioso de seguir
aprendiendo DNS, que es un tema que me esta enamorando mucho...
--
**********************************************
Pablo Figueroa Alvarez
Linux user N° 379917 - counter.li.org
**********************************************