Archivo del sitio

[DNS] ¿Cómo afecta nuestra ineficiencia y desidia?

Si, he agarrado una “onda” de escribir sobre DNS, es que he estado montando una serie de servidores de correo y por más que uno trata de “seguir las normas” (cómo llorarle a tu ISP para que te registre el puntero reverso PTR para nombre de tu intercambiador de correo, hace 2 años que le monté el servidor de correo a un cliente y aún hoy, su ISP no le ha configurado dicha solicitud de PTR) se encuentra con cada caso, que a veces “raya” en la ineficiencia.

A veces hablar de “eficiencia” es tan difícil, porque está tan arraigada la “comodidad” de “no hacer nada esperando que otro lo haga”, que a veces raya en la indolencia …

¿Recuerdan mi anterior post, sobre la equivocada concepción de las RFC 1912 y 2902 y cómo ciertos “ISP” incorporan punteros “localhost” a la zona DNS de sus clientes, exponiendo sus clientes a problemas.

Pero, así como “Facebook” expone sus gráficos de “eficiencia energética” en “cuánto cuesta un LIKE”, y gracias a la pregunta del amigo @jbo de twitter, decidí averiguar,

¿Cuánto de nuestra ineficiencia afecta al mundo?

En lo que respecta a DNS, estos son los resultados:

En la gráfica (origen: ICANN DSC) podemos ver la popularidad de los TLD (Top-Level Domain) más “frecuentes” qué le llegan a los servidores L-ROOT (ICANN LACNIC) en un momento cualquiera, como vemos, ni siquiera es “hora laboral” y tenemos estadísticas “interesantes”:

icann-2

* Brasil, Argentina, Chile y México son en ese orden los dominios latinoaméricanos más populares …

Pero, ¿qué vemos allí casi de primero?, ese no es … OMG! “.LOCAL”, ¿ese no es el “pseudo-TLD” que nos recomienda Microsoft en sus configuraciones de Active Directory?

icann-1

A las 4 am, ICANN recibe unos 250 consultas POR SEGUNDO de servidores Windows mal configurados y estaciones de trabajo (de esos mismos dominios) tratando de resolver “.LOCAL” contra los servidores públicamente establecidos; sin embargo, en horas “de mucho tráfico” los L-ROOT pueden recibir hasta 2700 solicitudes por segundo, siendo el cuarto TLD más activo (y el primero de los inválidos), incluso por encima de de TLDs válidos cómo “.ORG” ó “.GOV|.GOB”.

¿Y dónde dejamos los “.HOME” de switches y enrutadores Nortel, el “.BELKIN” de los access point y enrutadores de internet caseros, el “.LOCALDOMAIN” (de muchos Linux también mal configurados) los “.CORP” de los Active Directory 2008 y los más extraños de todos “.bamovistarwifi” e “.invalid”.

Aunque la gente no lo crea, las solicitudes INVALIDAS contra los ROOT-SERVERS de ICANN representan el 35% del TRÁFICO REGIONAL de DNS, es decir, ¿la infraestructura Internet debe soportar un 35% de tráfico causado por ineptos que no saben cómo configurar bien una zona DNS?.

Ser popular no siempre es bueno …

Me sorprendió ver la popularidad del “pseudo-dominio” localhost y el puntero “localhost” (la RFC-1912, lo indica claramente, “localhost” debe ser una zona completa, con su respectivo reverso, respondiendo a solicitudes LOCALES, no expuesta a respuestas desde “afuera” de la red), solicitudes para resolver ¿Quién es “LOCALHOST”? y ¿Quién será ese lindo 127.0.0.1? representan el 2.5% del tráfico, qué aunque parezca “poco”, representan algo así cómo 15 millones de solicitudes AL DIA, tráfico inútil (que tomando el cuenta solamente el tamaño de la trama de resolución DNS para localhost) representan 1.34GB de datos viajando por nuestros ISP, DNS y ROOT-SERVERS para ir a preguntar ¿quién es 127.0.0.1?.

Como la vida misma

Vamos a una tienda, compramos un enrutador, lo dejamos “por defecto”, luego, montamos un “Active Directory” cómo “los grandes genios de Microsoft nos sugieren hacerlo” y así vamos dejando “cabos sueltos” sin arreglar, ¿cómo estamos afectando al crecimiento de Internet con nuestra ineficiencia?, es por demás perturbador saber que, según anti-abuse.org, el 89% del tráfico de correo actualmente sea SPAM ¿en cuánto estamos contribuyendo a ello?, ¿cuántas veces vemos “parpadear” las lucecitas de nuestro modem, aunque no lo estemos utilizando y no le prestamos atención?

Ineficiencia es egoísmo …

Entonces, ¿crees que eres “solo tú”?, tú eres el único que configuró un Active Directory con “miempresa.local”, dejaste el enrutador con “default.belkin” y pusiste un servidor DNS recursivo en un resolver donde el /etc/hosts dice que nos llamamos “localhost.localdomain”, ¿crees que eres tú sólo?, ¿crees que no hay más nadie como tú, contaminando, conciente ó inconcientemente el tráfico de toda la Internet?.

Es igual a lanzar una lata de cerveza al mar, “es simplemente una sola”, dirás …

Y luego te informan que millones de personas “como tú”, lanzaron cosas al mar y ahora tenemos “El parche de basura del Atlántico” un área de 1600 Km2 de extensión de sólo basura plástica …

Imagina ese tráfico inútil como “basura de nuestro tiempo” y que contribuyes día a día, a que la basura se vaya incrementando, los ROOT-SERVER tienen que invertir en más infraestructura, más gasto, más energía y más polución, solo para satisfacer tú necesidad de “poder resolver 127.0.0.1” …

¿Quieres seguir lanzando la lata al mar, o quieres ser parte del cambio? …

[Linux] Instalación rápida de un DNS caché

Con el advenimiento de los problemas DNS o los fallos de resolución (el sábado pasado DNS1.CANTV.NET dejó de resolver por un par de horas), además como una buena práctica de gestión de tu plataforma, es importante contar con un servidor DNS caché.

En este caso, instalaremos dnsmasq, tanto para Debian como para Fedora/CentOS.

La razón de este artículo fue un compañero que me llamó presuroso, “tenemos problemas con el correo!, auxilio!, se está quedando represado y están fallando las resoluciones DNS”, rápidamente le envié mi guía de DNS caché y solventó su problema, ¿por qué no solventarle el problema a los demás?, aquí la publico.

DNSmasq es un servicio muy sencillo y fácil de configurar, con muchas guías disponibles, este simplemente es una más 🙂

Preámbulo

Un DNS caché es una herramienta que se encarga de hacer las consultas DNS contra servidores externos y almacenarlas el tiempo previsto por el REFRESH de la zona, así, nos ahorramos un montón de tráfico “hacia afuera” a preguntarle a DNS de Google o de CANTV (o el que sea tu ISP).

Para el trabajo utilizaremos una aplicación muy ligera, conocida como DNSmasq, acá las instrucciones para instalarlo.

Instalación

Para instalar en Debian GNU/Linux debemos ejecutar:

aptitude install dnsmasq

Para Fedora, debemos ejecutar:

yum install dnsmasq

Para CentOS, tenemos qué, previamente, añadir los repositorios EPEL para descargar de allí dnsmasq

rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm

Y luego si ejecutamos la instalación

yum install dnsmasq

Luego de esto, aseguraremos la instalación, para ello, debemos crear un usuario y grupo (por defecto, dnsmasq se instala y correo como root ó como nobody):

groupadd -r dnsmasq
useradd -r -g dnsmasq dnsmasq

A partir de acá, pasamos a configurar el servicio.

Configuración de DNSmasq

Primero, guardamos el archivo de configuración “original” (por si acaso!):

cp /etc/dnsmasq.conf /etc/dnsmasq.conf.orig

Y creamos uno con el siguiente contenido:

archivo: /etc/dnsmasq.conf
#
# Configuration file for dnsmasq acting as a caching nameserver.
#
# Format is one option per line, legal options are the same
# as the long options legal on the command line. See
# "/usr/sbin/dnsmasq --help" or "man 8 dnsmasq" for details.
#
# Updated versions of this configuration file may be available at:
#
#   http://www.g-loaded.eu/2010/09/18/caching-nameserver-using-dnsmasq/
#
#
# Basic server configuration
#
listen-address=127.0.0.1
port=53
bind-interfaces
user=dnsmasq
group=dnsmasq
pid-file=/var/run/dnsmasq.pid
## Logging #
log-facility=/var/log/dnsmasq.log
log-queries
## Name resolution options #
domain-needed
bogus-priv
dns-forward-max=150
cache-size=1000
neg-ttl=3600
resolv-file=/etc/resolv.dnsmasq
no-poll

NOTA: si queremos evitar que dnsmasq lea las entradas del /etc/hosts simplemente agregamos “no-hosts” luego de “no-poll”.

Este archivo simplemente define un dnsmasq como “caching nameserver” con un tamaño de caché de 1000 entradas y un caché negativo (tiempo que se guarda una resolución NXDOMAIN como válida) de una hora.

Guardamos luego el archivo y le damos los privilegios necesarios:

chown dnsmasq.dnsmasq /etc/dnsmasq.conf
chmod 0640 /etc/dnsmasq.conf

Creando el resolv para DNSmasq

El archivo “/etc/resolv.conf” apunta al DNS que debería resolver nuestras direcciones, y este debe ser, obviamente, “127.0.0.1”, o sea, nuestro propio dnscaché.

archivo: /etc/resolv.conf
nameserver 127.0.0.1

Sin embargo, dnsmasq cuenta con su propio archivo, donde se definen los servidores DNS que consultará recursivamente por direcciones:

archivo: /etc/resolv.dnsmasq
nameserver 8.8.8.8 #DNS de GOOGLE, mi favorito
nameserver [Primer DNS de tu ISP]
nameserver [segundo DNS de tu ISP]

Gestionando el log

Hemos creado un log, para gestionar los mensajes de dnsmasq (y la opción “log-queries” creará una bitácora con todas las direcciones que nuestros “usuarios” consultan), pero este log no es el “oficial”, así que hay que incorporarlo al logrotate:

Creamos el archivo con el siguiente contenido:

archivo:  /etc/logrotate.d/dnsmasq

/var/log/dnsmasq.log {
monthly
missingok
notifempty
delaycompress
sharedscripts
postrotate
[ ! -f /var/run/dnsmasq.pid ] || kill -USR2 `cat /var/run/dnsmasq.pid`
endscript
create 0640 dnsmasq dnsmasq
}

Y aplicamos la regla de logrotate ejecutando:

/usr/sbin/logrotate  /etc/logrotate.conf -f

Ya con esto, sólo nos hace falta, iniciar el servicio.

Arranque y parada

Para poder iniciar al arranque del sistema, en Debian ejecutan:

update-rc.d dnsmasq defaults

Y en Fedora/centOS:

chkconfig dnsmasq on

Para luego, iniciar el servicio con:

service dnsmasq start

Con lo cual ya está en operación tu caché de DNS, ¿por qué no probarlo?

Pruebas

Lo más ideal, es realizar una serie de consultas, para determinar su velocidad, para ello utilizamos la herramienta “dig”

Por ejemplo, una consulta sobre un dominio .gob.ve a google (8.8.8.8) le toma:

$ dig @8.8.8.8 -t A localhost.saren.gob.ve
;; Query time: 198 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Apr 26 03:06:12 2013
;; MSG SIZE rcvd: 56

Y a CANTV.NET

;; Query time: 105 msec
;; SERVER: 200.44.32.10#53(200.44.32.10)
;; WHEN: Fri Apr 26 03:39:59 2013
;; MSG SIZE rcvd: 56

Pero consultando 2 veces (una para que resuelva, la segunda ya responde desde caché) a nuestro servidor DNS:

$dig @127.0.0.1 -t A localhost.saren.gob.ve
;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Apr 26 03:42:29 2013
;; MSG SIZE rcvd: 56

Lo cual no solo es una mejora significativa en velocidad, sino una además, un ahorro notable de ancho de banda de resoluciones DNS innecesarias.

DNS: Haciendo las cosas bien

Del artículo anterior ([Linux DNS]) y de los recientes acontecimientos de ataques a páginas web, me doy a la tarea de escribir algunos consejos que podrían ser útiles a algunos administradores de DNS, ciertamente no soy un experto en DNS, pero viendo algunos “fallos” en la configuración de algunos DNS oficiales, pues quisiera ayudar un poquito en la enseñanza.

Hace un par de días atrás, una caída masiva en los servidores “.gob.ve” me llevó a hacer algunas revisiones, que llevaron a este artículo (y a la queja de: ¿cómo es eso que los servidores web del SIBCI, VTV, VIVE y otros medios públicos están configurados en redundancia, pero organismos importantes como PRESIDENCIA.GOB.VE, SAIME o SENIAT, no lo están?, ¿qué es más importante para nosotros?), espero sea tomado como una ayuda a entender algunas cosas en las que se está fallando.

El problema

Estaba revisando la definición de algunas zonas, por ejemplo, sirvase a visitar este análisis simple de la zona DNS del SENIAT:

http://www.intodns.com/seniat.gov.ve

Y observe los fallos y advertencias allí nombrados (situación semejante se repite en DNS como SAREN o SAIME), el propio DNS de la empresa CANTV (cantv.com.ve) reporta que su “hostname” es > dns1.cantv.net.cantv.com.ve (de hecho, parece ser que todo DNS gubernamental *parqueado* en CANTV.NET sufre los mismos defectos, son una plantilla de “copy&paste”), tambien podemos revisar los del CNTI:

http://www.intodns.com/cnti.gob.ve

Para otro tipo de fallas, que ya explicaremos más adelante.

Explicando lo básico de una Zona

Veamos una zona básica, extraída del ejemplo anterior:

;
; coopera.net
;
$ORIGIN coopera.net.
$TTL    86400
@       IN      SOA     dns1.coopera.net. hostmaster.coopera.net. (
                         2011051701     ; Serial
                         86400          ; Refresh
                          7200          ; Retry
                        2419200         ; Expire
                         60480 )       ; Negative Cache TTL
; definicion de Nameservers
       IN      NS      dns1.coopera.net.
       IN      NS      dns2.coopera.net.
; punteros A de los DNS
dns1.coopera.net. IN A 144.76.25.227
dns2.coopera.net. IN A 144.76.25.228
; puntero de la zona
@       IN      A       144.76.25.228
www     IN      A       144.76.25.228
; informacion de hardware de este DNS
        IN      HINFO   VM-XEN "Debian Wheezy 7.0"
; puntero de intercambio de correo
        IN      MX      5    correo.coopera.net.
correo IN A 144.76.25.229
; informacion del administrador de la zona
       IN      RP      jesuslara
jesuslara IN TXT        "Jesus Lara, (58) 555-5555"

@ORIGIN: Define el nombre de dominio de la zona (útil para realizar INCLUDES)
SOA: “Start of Authority”, nos dice QUIEN es la autoridad en un dominio, tiene la siguiente forma:

IN SOA MNAME: Lo que sigue a la palabra SOA es el MNAME, representa el NOMBRE MAESTRO (MASTER NAME) o Servidor maestro y primario de la ZONA, el servidor maestro no solamente debe estar listado en nuestra lista de NS (NameServers) sino que además, debe ser el primero.

Le sigue al MNAME el responsable de la zona (RNAME), es el correo (en el formato “nombre.dominio”) de quien es el administrador del dominio, dicho correo DEBE existir (he visto quienes lo configuran como “root.midominio” pero, envías un correo a dicha dirección y rebota), por cuestiones de convenciones, se recomienda que sea alguno de los alias administrativos “hostmaster” ó “postmaster” (RFC 2142).

Luego le siguen los valores de de la zona, el primero es el SERIAL, un valor incremental, que debe ser cambiado para notificar al demonio RNDC (y al resto de servidores) que la zona ha sido cambiada y que notifique los cambios, puede ser cualquier valor, por convención (Los libros de O’really media ayudaron “algo”) el serial de la zona tiene la forma  “YYYYMMDDXX” donde los primeros 8, son la fecha (ej: 20130520) y los 2 últimos, un par de dígitos incrementales (representan el número de cambios realizados durante el día).

Los tiempos de la Zona

Los valores de la zona son importantes para describir cómo se comportan las actualizaciones de la misma, el primero es el valor REFRESH e indica la cantidad de segundos que una zona puede esperar para ser refrescada “o transferida” a un servidor esclavo, por ejemplo, dicho valor para zonas muy volátiles puede ser pequeño, pero no menor a 1200 segudos, y para zonas con pocos cambios, entre 8 a 12 horas (43200), en la mayoría de los casos, como BIND notifica de los cambios, se puede implementar un refrescamiento de un día, o más incluso (86400).

Retry, es el valor de re-intento, ¿qué pasa si contacto una zona y esta falla?, un servidor esclavo puede esperar una cantidad para re-intentar la consulta/transferencia desde el maestro, debe ser un valor bajo, entre una hora (3600) a 3 minutos (180).

Expire: representa el tiempo que una zona es “válida” luego de una caída del servidor maestro de la zona, debe ser siempre un valor alto, entre 2 a 4 semanas (1209600 a 2419200), para permitir cualquier caída “larga” del sistema.

Minimun TTL: o “negative caching time”, es importante para la “operación” de los Cache de DNS, es el tiempo máximo en que un servidor de DNS puede responder “correctamente” cuando se presenta un NXDOMAIN en la respuesta autoritativa de la zona, como DNS es un servicio que debería garantizar la estabilidad ante todo, dicho valor no debe ser mayor a 10800 segundos (3 horas como máximo).

Definiendo Name Servers

Los “Name Servers” son simplemente, los servidores que responden como “autoritativos” (dueños) de la zona DNS, de los múltiples errores que puede haber con esto, hay 4 de consideración:

  • Single point of Failure: Esto representa la imposibilidad de responder desde varios puntos, sea porque el dominio no configura “al menos” 2 servidores de nombres (la RFC 2182 indica que deberían existir *al menos* 2 ó 3 servidores de nombres para un dominio) ó porque los DNS de este dominio están todos en la misma sub-red (se daña el switch o el router de esa sub.net y ¡adiós DNS!).
  • Missing Nameservers: A veces, configuramos 2 o más servidores de nombres (como el caso del Ministerio de Educación Superior: http://www.intodns.com/mppeu.gob.ve) y los servidores que configuramos están, o fuera de servicio (apagados) o han dejado de responder autoritativamente a nuestro dominio, como Administrador de DNS, es nuestra responsabilidad mantener la red de resolución de nombres de nuestro dominio.
  • Stealth NS records: Se refiere a que, en nuestra zona DNS, hacemos referencia a los NS primario y secundario de nuestro dominio, pero, ante nuestro registrar (ejemplo: NIC.VE de Venezuela) indicamos otro servidor, causando qué, cuando uno consulta a NIC.VE por “mppeu.gob.ve” este responda “dns.mes.gob.ve es el autoritativo de la zona MPPEU”, si vas y le preguntas a dns.mes.gob.ve, este indicará que “le he delegado esa responsabilidad a dns.mppeu.gob.ve”, causando varias consultas, donde solo debería ocurrir una, además, la zona mppeu.gob.ve no contiene registros NS para “mes.gob.ve”, por lo que la zona está desconfigurada (en pocas palabras, un dominio está respondiendo como un autoritativo, de otro dominio, pero ese otro dominio, no lo reconoce en sus NS, como su autoritativo).
  • Recursive Queries: estamos acostumbrados a ver los DNS de Windows Server, que responden a todo (direcciones propias y además ajenas) esto, conocido como “recursive resolver” es un error, ya que tu servidor de nombres puede responder por “cualquier cosa” y no solamente por tu dominio, en este caso podemos ver:
dig @dns.mes.gob.ve google.com.ve
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @dns.mes.gob.ve google.com.ve
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65202
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 13, ADDITIONAL: 8

;; QUESTION SECTION:
;google.com.ve. IN A

;; ANSWER SECTION:
google.com.ve. 41 IN A 74.125.140.106
google.com.ve. 41 IN A 74.125.140.147
google.com.ve. 41 IN A 74.125.140.99
google.com.ve. 41 IN A 74.125.140.103
google.com.ve. 41 IN A 74.125.140.104
google.com.ve. 41 IN A 74.125.140.105

Acá podemos ver cómo el servidor autoritativo del Ministerio del Poder Popular para la Educación Superior (que agrupa las universidades!, una de ellas, la que da informática y sistemas donde estudié, xD) responde consultas como un servidor de nombres recursivo, exponiéndolo fácilmente a una denegación de servicio basada en consultas recursivas envenenadas.

Como dato final de los nameservers, el MNAME en el SOA, siempre debería estar listado en la lista de Name Servers de la Zona, por ello un “MNAME” indicando “localhost” no solo es un error, sino una mala (muy mala) interpretación de los conceptos de DNS.

El “puntero de la zona” y WWW

¿qué pasa si escribimos un dominio sin agregar WWW?, lo que debería ocurrir, es ser enviado al servidor web asociado a WWW, sin embargo si visitan http://seniat.gob.ve verán que no abre ninguna página web y su navegador web le indicará que dicha página no existe, ¿a qué se debe esto?, pues a la ausencia del puntero de la zona (el registro A más básico, sin nombre), este se escribe así:

@       IN      A       144.76.25.228

Y representa que, en ausencia de cualquier sub-dominio, se entregará este servidor al cliente, un simple registro que evita muchos problemas.

Otro caso es WWW que DEBE ser un puntero A y no un CNAME, ¿por qué?, porque entonces cuando yo pido http://www.cnti.gob.ve, entonces este me enviará a otro nombre, que a su vez, me devolverá la IP, causando 2 consultas donde solo debería existir una, ¿comprenden?

;; QUESTION SECTION:
;www.cnti.gob.ve. IN A
;; ANSWER SECTION:
www.cnti.gob.ve. 0   IN CNAME  cnti.gob.ve.
cnti.gob.ve. 1200    IN A      190.9.128.98

Esto se solventa con la definición de un puntero @ y un puntero A para WWW, esto también aplica para servidores de correo (RFC-821 Section 3.1) los nombres deben ser siempre punteros A principales, jamás deben ser CNAME; la confusión aplica cuando preguntas por “www.google.com” y este responde que es un CNAME, la única razón para realizar esto, cuando tienes una granja de servidores y un servicio de aceleración permite entregar el servidor con el mínimo TTL más próximo a tí, por lo que el segundo lookup al DNS, es superfluo:

www.google.com. 36545 IN CNAME www.l.google.com.
www.l.google.com. 294 IN A 209.85.153.104

Pero ese no es el caso del CNTI, ¿cierto?.

El intercambio de correo

Otro de los lugares donde se cometen más “errores” es en la configuración del intercambio de correo, por ejemplo, seniat.gob.ve|seniat.gov.ve indica en su configuración que su servidor MX es correo.seniat.gov.ve, sin embargo, en la vida real (y hasta finales del año pasado, ultima vez que revisé), cuando recibes correo del SENIAT, quien lo envía es un servidor Microsoft Exchange que se reporta como:

nomacovasuli.seniat.gov.ve
(
Received: from nomacokadru.seniat.gov.ve ([10.156.80.84]) by nomacovasuli.seniat.gov.ve with Microsoft SMTPSVC(6.0.3790.4675);
Received: from RECEOCKADRU.seniat.gov.ve ([10.163.128.74]) by nomacokadru.seniat.gov.ve with Microsoft SMTPSVC(6.0.3790.4675);
)

Incluso en el HELO/EHLO del servidor de correo, sin embargo, dicho puntero A (o CNAME) no se encuentra en la zona SENIAT.GOV.VE, por lo que cualquier resolución inversa es imposible.

El otro error, es cuando, bueno, un día se dañó el servidor de correo, lo cambiaron, pero no actualizaron las entradas MX, por ejemplo:

http://www.intodns.com/inces.gob.ve

En este caso, indica qué el intercambiador es:

10   mail.inces.gob.ve   200.11.149.166

Sin embargo, cuando recibes correo de allí, lo recibes de:

Received: from mail.inces.gob.ve ([200.11.149.162]) <--- IP verdadera del cliente
        by mx.google.com with ESMTP id gz2si4186023vcb.4.2012.12.20.16.22.19;

Lo que representa un verdadero “dolor de cabeza” si comienzo a bloquear como “Lame Server” a un servidor que me desea entregar un correo a nombre de “inces.gob.ve” pero dicho servidor no se corresponde al MX que debería entregarmelo.

Y lo peor, es la configuración de IP del host que “hostea” este servidor de correo:

Received: from localhost (localhost [127.0.0.1])
	by mail.inces.gob.ve (Postfix) with ESMTP id E0ED556DC2F

Exponiendo a los “hackers” incluso las IPs “privadas de la sub.-red:

Received: from [10.50.0.58] (unknown [10.0.0.220])
	by mail.inces.gob.ve (Postfix) with ESMTP id BD5FD56DE4C

El otro problema que suele ocurrir con servidores de correo (precisamente de este mismo dominio), es la ausencia de un puntero reverso (reverse PTR record) en la zona inversa de quien me provee los DNS, por ejemplo, en CANTV (quien le provee las IPs públicas a INCES), debería existir una zona inversa:

166.149.11.200.in-addr.arpa -> mail.inces.gob.ve

Y esta zona inversa retornar el nombre del servidor de correo (¿no?, esa IP es mía, única y debería retornar el nombre de mi servidor), sin embargo ocurre que:

166.149.11.200.in-addr.arpa ->  200-11-149-166.estatic.cantv.net

Si en la configuración de mi correo, decido no aceptar correo de servidores que no tienen puntero reverso (útil para evitar correo de servidores de SPAM, que contratan cualquier VPS y montan allí un servidor de correo LAME), como mínimo este correo caerá en la carpeta de SPAM (o no llegará) y los administradores se preguntarán, ¿por qué?

Tips finales

En la semana de las elecciones, un grupo de hackers y chicos de lulzsec, se dedicaron a atacar servidores de la APN de Venezuela, considero que es muy importante entender que más de la mitad de la responsabilidad la tienen malos administradores, que desconocen mucho de lo que, por responsabilidad, la nación les ha encomendado proteger (como aquél, que le toca la seguridad de servidores y solo allí comienza a aprender “iptables” en vez de utilizar herramientas ya probadas, o el que configura un postfix-courier sin conocer en lo más mínimo las RFC orientadas a servidores de correo).

Insisto, no me puedo considerar un “experto” de DNS, pero cuando hacemos el siguiente experimento:

ping localhost.saren.gob.ve
PING localhost.saren.gob.ve (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_req=1 ttl=64 time=0.025 ms
64 bytes from localhost (127.0.0.1): icmp_req=2 ttl=64 time=0.042 ms

Me pregunto ¿en qué estaba pensando el administrador que creó ese puntero A apuntando a “localhost”? o ¿en qué estaba pensando VTELCA al contratar a una empresa (DATTATEC) para administrar los DNS y sin embargo, dicha empresa ni siquiera responde a dichos Dominios?

http://www.intodns.com/vtelca.gob.ve

dig @200.58.116.42 -t SOA vtelca.gob.ve
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @200.58.116.42 -t SOA vtelca.gob.ve
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 44763
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
 
;; QUESTION SECTION:
;vtelca.gob.ve. IN SOA

Considero importantísimo, que si se desea “pregonar” la “eficiencia o nada”, primero comencemos por admitir que estamos haciendo muchas cosas mal, espero que este artículo sea un “granito de arena”, para que “manual en mano”, los administradores de DNS comiencen a asumir su responsabilidad, de leer las RFC y verdaderamente, aprender y configurar DNS.

Saludos y ¡Happy Hacking!

Actualización

Según la RFC-1912, Se deben crear las zonas “directas” y “reversas” a la sub-net loopback (localhost <> 0.0.127.in-addr-arpa) para evitar “el error” qué resoluciones “127.0.0.1” alcancen a los ROOT-SERVERS; dichas zonas deben estar en una “vista interna” para no causar tráfico innecesario a los ROOT-SERVERS y al sistema DNS mundial, y sin embargo, el 1% de las resoluciones DNS que llegan a los ROOT-SERVERS son para la dirección “127.0.0.1”, algo así como lo que pasa en muchas Zonas DNS de CANTV:

;; ANSWER SECTION:
localhost.saren.gob.ve. 21600 IN A 127.0.0.1

Delegar a los DNS, la responsabilidad de resolución de DNS “internos” y de los hosts (/etc/hosts ó windows/system32/drivers/hosts) o de la zona loopback, es un muy mal entendimiento del concepto plasmado en la RFC-1912.


			

[Linux-DNS] Vistas DNS e INCLUDE: dos increíbles aliados

Este artículo debería llamarse “El DNS para los pobres”, se trata de una situación que realmente es “bastante común”, como lo es, que un servidor “resolver recursivo” gestione varios DNS de una misma institución y que, además, resuelva direcciones “internas” y “externas” en un mismo ambiente.

Un amigo fué quien me hizo la consulta, me preguntó ¿cómo hago para que el servidor DNS, resuelva direcciones internas si está en mi red local, pero externas, si me consultan desde afuera? y además,  “solo tengo una máquina virtual y administro unas 5 cooperativas, ¿cómo hago para *facilitar* la administración de mi DNS?”, si tienes una situación similar con tus DNS, deberías leer el artículo.

La situación

Mi amigo tiene un servidor DNS en una máquina virtual, resuelve las direcciones “externas” (es autoritativo de su dominio) pero también las internas, además, debe gestionar los dominios de varias cooperativas, todas ellas comparten un único servidor Web, luego de explicarle me dijo “¿por qué no publicas esa ayuda?” y pues, aquí está.

Todas las cooperativas comparten servidor DNS y Servidor de correo y existen una serie de “hosts internos” (como el antivirus) comunes dentro del datacenter para servirle a las 5 cooperativas que comparten el edificio.

¿Cómo simplificar al máximo la administración?

Definir mis “amigos”

Lo primero que debemos hacer es crear en el archivo “named.conf” (si se encuentran usando Debian, es preferible hacerlo en “/etc/bind/named.conf.options”) una “ACL” (Access Control List) definiendo “quien” es mi red interna.

En este caso, he agregado lo siguiente:

archivo: /etc/named.conf.options
// definicion de mi red DMZ
acl internas {
 127.0.0.0/8;
 192.168.20.0/24;
 localnets;
};

Donde 192.168.20.0/24 constituye la sub-red de nuestra DMZ, además, en localnets (otra ACL) incorporé la lista de sub-nets dentro de la empresa:

// definicion de mi red interna
acl localnets {
 172.16.20.0/24;
 192.168.1.0/24;
};

De esta manera, cada vez que se incorpore una nueva sub-red, simplemente la agrego a “localnets” y recargo el servidor.

Interna y Externa

Las vistas son la manera de definir qué verá la red de internas y que verán los usuarios “externos”, para ello, incorporo al “named.conf” la definición de las vistas, la “interna” y la “externa”, de la siguiente manera:

view "interna" {
 match-clients { internal; };
 additional-from-auth yes; 
 additional-from-cache yes;
zone "." {
 type hint;
 file "/etc/bind/db.root";
};
zone "localhost" {
 type master;
 file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
 type master;
 file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
 type master;
 file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
 type master;
 file "/etc/bind/db.255";
};
zone "coopera.net" {
 type master;
 file "/etc/bind/zonas/internas/coopera.net.zone";
 allow-query { internas; };
};
zone "servicioscoopera.net" {
 type master;
 file "/etc/bind/zonas/internas/servicioscoopera.net.zone";
 allow-query { internas; };
};
zone "20.16.172.in-addr.arpa" {
 type master;
 file "/etc/bind/zonas/internas/20.16.172.zone";
 allow-query { internas; };
};
};

La vista “interna”, incorpora la zona “punto”, mis zonas internas, además, se permite consultarlas únicamente a personas que hagan “match” con clientes que estén en las subredes especificadas en la acl “internas”, evitando así que cualquier cliente obtenga “por error” una IP interna.

Por el contrario, la vista “externa” permite que cualquiera (excepto redes “internas”) la consulte:

view "external" {
 match-clients { !internal; any; };
 recursion no;
 zone "servicioscoopera.net" {
   type master;
   file "/etc/bind/zonas/servicioscoopera.net.zone";
   allow-query { any; };
 };
 zone "coopera.net" {
   type master;
   file "/etc/bind/zones/coopera.net.zone";
   allow-query { any; };
 };
};

Las zonas internas serán definidas en la carpeta “/etc/bind/zonas/internas” y las externas en “/etc/bind/zonas”.

Definiendo y compartiendo Zonas

Para simplificar, debemos decidir cual dominio será el autoritativo para el resto (en nuestro caso, el falso dominio “coopera.net” será el autoritativo para el resto, y se realizarán los cambios en el NIC registrar para que “dns1.coopera.net” y “dns2.coopera.net” sean los autoritativos para el resto de las zonas.

Así, el resto de valores (MX, HINFO, puntero A @ y WWW, y NS) serán compartidos por el resto de las zonas.

La zona primaria de COOPERA.NET quedará de la siguiente manera:

;
; coopera.net
;
$ORIGIN coopera.net.
$TTL    86400
@       IN      SOA     dns1.coopera.net. hostmaster.coopera.net. (
                         2011051701     ; Serial
                         86400          ; Refresh
                          7200          ; Retry
                        2419200         ; Expire
                         60480 )       ; Negative Cache TTL
; definicion de Nameservers
       IN      NS      dns1.coopera.net.
       IN      NS      dns2.coopera.net.
; punteros A de los DNS
dns1.coopera.net. IN A 144.76.25.227
dns2.coopera.net. IN A 144.76.25.228
; puntero de la zona
@       IN      A       144.76.25.228
www     IN      A       144.76.25.228
; informacion de hardware de este DNS
        IN      HINFO   VM-XEN "Debian Wheezy 7.0"
; puntero de intercambio de correo
        IN      MX      5    correo.coopera.net.
correo IN A 144.76.25.229

En este caso, lo más básico de la zona fué definido, NS (nameservers), puntero MX (Mail Exchange) e incluso WWW, pero, ¿qué les parece si usamos “INCLUDE” para compartir la información común de esta zona?

Compartiendo información de Zona

Imaginen este caso, el día de mañana cambio de servidor de correo, o en su defecto, incorporo otro servidor adicional, o cambio de proveedor para cambiar los DNS, si tengo 5 zonas, tendría que cambiar 5 archivos para cambiar las IPs, agregar un segundo servidor web ó un nuevo servidor de correo, ¿cómo simplificarlo?, en nuestra ayuda viene “INCLUDE”.

Si utilizamos “INCLUDE” (parte de bind9) podemos separar el archivo en “partes” que incluiremos después, en este caso, utilizando INCLUDE, la zona queda así:

archivo: /etc/bind/zonas/coopera.net.zone
;;
;; coopera.net
;;
$ORIGIN coopera.net.
$TTL    86400
@       IN      SOA     dns1.coopera.net. hostmaster.coopera.net. (
                         2011051701     ; Serial YYYYMMDDXX
                         86400          ; Refresh
                          7200          ; Retry
                        2419200         ; Expire
                         60480 )       ; Negative Cache TTL
; definicion de Nameservers
$INCLUDE /etc/bind/zonas/ns.coopera
; puntero de la zona
$INCLUDE /etc/bind/zonas/www.coopera
; puntero de intercambio de correo
$INCLUDE /etc/bind/zonas/mx.coopera
; informacion del administrador del dominio
$INCLUDE /etc/bind/zonas/adm.coopera

Si nos damos cuenta, se ha “simplificado” bastante el archivo, creando 3 archivos “aparte” para NS, WWW y MX y uno adicional para RP (opcional)

archivo: /etc/bind/zonas/ns.coopera
       IN      NS      dns1.coopera.net.
       IN      NS      dns2.coopera.net.
; punteros A de los DNS
dns1 IN A 144.76.25.227
dns2 IN A 144.76.25.228
archivo: /etc/bind/zonas/www.coopera
@       IN      A       144.76.25.228
www     IN      A       144.76.25.228
; informacion de hardware de este DNS
IN      HINFO   VM-XEN "Debian Wheezy 7.0"
archivo: /etc/bind/zonas/mx.coopera
        IN      MX      5    correo
correo IN A 144.76.25.229
archivo: /etc/bind/zonas/adm.coopera
        IN      RP      jesuslara
jesuslara IN TXT        "Jesus Lara, (58) 555-5555"
Se preguntarán ¿y cómo funciona eso?, la declaración de $ORIGIN al inicio de la zona primaria, hace qué en todos los archivos INCLUIDOS, la zona sea utilizada para “reemplazar” el dominio, entonces, en el archivo “mx.coopera”, si en $ORIGIN dice “coopera.net” eso se traducirá en “correo.coopera.net”, si estás en la zona “servicioscoopera.net” entonces reemplazará por “correo.servicioscoopera.net” y así suscesivamente.
Como verán, si cambio las IPs de los NS en el archivo “ns.coopera”, se cambiará en absolutamente TODAS las zonas que incluyan este archivo.

Entonces, crear una nueva zona, será tan sencillo como, copiar el archivo de zona COOPERA.NET.ZONE y reemplazar el dominio “coopera.net” por el que corresponda, si usan VIM esto es tan fácil como abrir el archivo y escribir:

:%s/coopera.net/servicioscoopera.net/g

(NOTA: se lee “dos puntos”, luego %s (sustitución), /{lo que se quiere reemplazar}/{reemplazo}/g de manera “global”)

¿Y el serial de la zona?, si usan VIM, pueden “reemplazar” el serial de la zona “original” con:

:%s/\<\d\{10}/\=strftime("%Y%m%d00")/

Esto, tomará el primer grupo de 10 dígitos y los reemplazará con la fecha actual, seguida de “00” (puede cambiar ese número, por un incremental por cada zona).

Conclusiones

La zona interna serían los mismos archivos, pero obviamente, respondiendo a IPs de la zona interna (e incorporando, por ejemplo, una lista de hosts donde se declaren punteros A comunes, como “antivirus” o “directorio”), la administración se ha simplificado al máximo y por ejemplo, agregar un nuevo servidor MX a TODAS las zonas declaradas, pasa por simplemente editar UN SOLO ARCHIVO (mx.coopera) y se cambiarán TODAS las zonas, quedando únicamente el cambio del serial de todas ellas y como estamos en LINUX, esto es tan fácil como ejecutar “SED”:

sed -i 's/20[0-1][0-9]\{7\}/'`date +%Y%m%d%I`'/g' /etc/bind/zonas/*.zone

Esto, cambiará en todos los archivos “.zone” el serial existente, por la fecha actual, preservando el serial, solamente quedaría ejecutar:

rndc reload

Y todas las zonas se verán cambiadas, ¿fácil, no? …

Recordando el hecho de ver DNS “oficiales” tan mal configurados (por allí vi uno de una institución pública que tenía un puntero que resolvía como dirección “127.0.0.1” (there is no place like localhost!) y otras donde el hostname del SOA no correspondía a ningún servidor, creo que comenzar con artículos que ayudan a la mejor configuración de nuestros DNS es lo mejor para apoyar …

[Plataforma libre para tu empresa] Introducción

Contar con una plataforma de IT libre para tu empresa debería ser algo fácil y sencillo; sin embargo, la diversidad de modos de configuración, de distribuciones y de necesidades hace que encontrar una documentación completa una tarea titanica.

El plan [Plataforma libre en tu empresa] es un conjunto de ayudas recopiladas y probadas durante años y que agrupan las necesidades más básicas de toda empresa pública o privada, muchas de las tareas comunes han sido resumidas a scripts automatizados o instaladores desasistidos.

Motivación

Mis amigos y conocidos siempre me preguntaban por mis “recetas” para la instalación de diversos servicios, y aún cuando puedo afirmar que este es mi modo de vida, también comprendo que la falta de documentación en nuestro idioma, fácil y entendible es lo que ha frenado en mucho la implementación de plataformas libres y abiertas.

Yo he sufrido también el problema de encontrar documentación al día, incluso en inglés, por lo que durante algún tiempo me he acostumbrado a coleccionar “howtos” y hasta poseo un wiki cortesía del proyecto GNU donde los he ido publicando frecuentemente.

Sin embargo, alguien me comentó la posibilidad de crear una empresa ficticia y documentar todo el proceso de instalar desde cero toda la plataforma IT necesaria, incluímos la migración desde diversos servicios privativos.

Contenido

* Sistema Operativo GNU/Linux Debian, instalación y trucos
* Virtualización y contenedores: Xen, LXC, roles, templates y administración vía libvirt
* OpenLDAP como servicio de directorio
* DNS y DHCP
* Autenticación de servidores basado en nss y pam-ldap, sudo-ldap
* Seguridad de servidores Debian, firewall-iptables, fail2ban y Tomoyo
* Compartir archivos e impresoras, Samba y CUPS
* Migración desde MS Active Directory
* Correo electrónico básico: dovecot y postfix
* Servicios de correo y archivos corporativos sobre Debian: Zimbra, SoGo y openKM
* Mensajería básica y comunicaciones: Ejabberd y Asterisk

Todos los servicios estan centralizados alrededor del directorio LDAP y simplificada su instalación lo más que se puede.

Futuro

El futuro es construir una distribución GNU/Linux basada en Debian/Canaima, para servidores con documentación 100% en español, y fácil de seguir por cualquier persona dedicada a sistemas y soporte.

Si algún día se me ocurre combinar y editar mejor este contenido en un libro, les haré saber! 😉

Consigan un equipo y manos a la obra!

[postfix] SPF o agregando de a poco al wiki

He comenzado a paso de hormiguita a reactivar la inclusión de artículos en mi wiki, sobre todo aquellos referentes a la plataforma de directorio libre.

El siguiente es la posibilidad de incorporar protección SPF (Sender Policy Framework) a la recepción del correo, con esto, evitamos la “falsificación” de identidades de ciertos correos.

Con SPF, nuestro servidor de correo interroga al cliente, para determinar si él “en verdad” es el MX (via nombre A o puntero PTR en el DNS) del dominio por el cual está ofreciendo el correo, además, verifica en la entrada SPF del dominio si está prohibido aceptar correo de alguien quien no sea el MX o el PTR.

Observen que esto es “más compatible” con los modos, que protegerse via MX/NS lookups en el smtp_client_restrictions.

El Enlace acá: http://phenobarbital.gnu.org.ve/doku.php/weyu:postfix:spf

A %d blogueros les gusta esto: