Redes y Seguridad en Ambiente Unix

Laboratorio 3.2
”Servicio de Nombres de Dominio”
Docente: Pedro González Mercado
Otoño 2009

Resumen
Si se requiere entregue los resultados en un documento aparte señalan-
do número de pregunta que responde junto con su su respuesta. Entregue
en formato PDF, esto puede hacerlo con herramientas tanto en windows
como en linux.
Es encarecidamente recomendado revisar la documentación entregada
por el docente a cargo, con el fin de tener claros los conceptos utilizados
en las distintas actividades de esta guı́a.
Esta guı́a en particular se basa en el conocimiento de la configuración
de zonas maestras y zonas reversas en un servidor DNS, la explicación de
estos conceptos no es parte de esta guı́a ya que es un prerequisito para
trabajar con nombres de dominio.
Si se necesita aclaración al respecto de los conceptos técnicos nece-
sarios para entender los registros de recursos DNS (RR), el documento
recomendado es el RFC 1035, y para conceptos globales de DNS el RFC
1034.
Esta guı́a también se basa en los conocimientos adquiridos en el labo-
ratorio 3.1 para configuración estática de interfaces en RH/CentOS.
Requerimientos : Para esta práctica puede utilizar una instalación de
Linux RHEL5.2/CentOS5.2, Proporcionada por el docente

1
Redes y Seguridad en ambiente Unix -lab 3.2 2

Actividad 1: Configuración de VMware

Detalles de la Actividad:
Esta actividad puede ser omitida en el caso de realizar esta guı́a en equipos
reales, en este dirijase inmediatamente a la actividad 2.
Se utilizará VMware Workstation/Server, para lo cual se indicarán las op-
ciones basadas en la interfaz gráfica en VMWare Workstation , pero esto no
significa ningún problema para su realización con VMWare Server. También es
Posible realizar con equipos reales (con Redhat 5.2 instalado), sujeto a disponi-
bilidad de los recursos.
Se generará la siguiente topologı́a usando VMWare y 2 máquinas virtuales.

Figura 1: Topologı́a red 172.16.10.0/24

Para esta topologı́a es recomendable usa la máquina virtual entregada llama-

da ”CentOS52-services”, y clonar dicha máquina para obtener ambos servidores
(no es necesario mas de 256mb de memoria ram para cada máquina virtual),
el cliente puede ser obtenido con la imagen llamada ”Centos52-lite” entregada
ú otra a elección que use redhat/CentOS/debian, sin interfaz gráfica (para este
cliente no es necesario mas de de 64mb de memoria ram).
Una vez instalados estas máquinas virtuales procedas a iniciarlas y asegura-
rese de que ninguna arranca interfaz gráfica (runlevel 3)

Metodologı́a
Realice los pasos indicados, verificando su correcta ejecución y comparando
resultados con sus compañeros. En esta actividad (1) no es necesario documentar
nada pues es un entorno de preparación básico
Redes y Seguridad en ambiente Unix -lab 3.2 3

Actividad 2: Interfaces de Red

Detalles de la Actividad:
Se recomienda leer el manual de route(1) y la documentación en /usr/share/doc/initscripts-
8.45.19.EL/sysconfig.txt para entender con mayor claridad las opciones adecua-
das para el correcto cumplimiento de los objetivos que se le solicitan, ası́ como
también el laboratorio 3.1 Recuerde siempre verificar sobre que directorio es-
ta lanzando los comandos las rutas pueden variar dependiendo de donde este
localizado, para saber su posición actual use el comando pwd(1).
1. En las máquinas virtuales llamada ”CentOS52-Services” cree editando
el archivo ”/etc/sysconfig/network-scripts/ifcfg-eth0” la configura-
ción necesaria para que la interfaz ”eth0”,de cada máquina pueda obtener
los siguientes requisitos:
inicio estático (no dhcp)
inicio automático
dirección como indica el diagrama de la topologı́a, para cada máquina
2. Verifique que el servicio ”named” En cada máquina este desactivado, pue-
de verificar esto con el comando #service named status, que indicará el
estado del servicio.
3. En la máquina virtual llamada ”CentOS52-lite” que usará como cliente
edite su configuración de red para que adquiera la dirección ip 172.16.10.16/24
4. Finalmente compruebe que todas las máquinas pueden comunicarse entre
si usando el comando ping para verificar la conectividad de capa de red.

Metodologı́a
Para cada uno de los resultados que entregue en su respuesta indique:
1. Lı́nea(s) de comandos utilizada(s)
2. Un listado con los resultados requeridos(si aplica)

Actividad 3: Configuración de BIND

Detalles de la Actividad:
Se recomienda leer el manual de named.conf(5) como referencia adicional
ala entregada al principio del laboratorio, para entender con mayor claridad
las opciones adecuadas para el correcto cumplimiento de los objetivos que se le
solicitan.
Recuerde siempre verificar sobre que directorio esta lanzando los comandos
las rutas pueden variar dependiendo de donde este localizado, para saber su
posición actual use el comando pwd(1).
Redes y Seguridad en ambiente Unix -lab 3.2 4

1. En el servidor maestro verifique con el comando #rpm -qa | grep bind

la existencia de los siguientes paquetes instalados:
bind-9.3.4-6
bind-chroot-9.3.4-6
bind-utils-9.3.4-6
2. Comprobada la existencia de estos paquetes, edite con nano(1) o vim(1)
un archivo bajo ”/var/named/chroot/etc/” llamado named.conf, y ve-
rifique que entre todas las sentecias incluidas en ese archivo contenga las
siguientes sentencias(si no lo posee agréguela):

listen-on port 53 {172.16.10.10;};

allow-query {any;};
recursion yes;
query-source port 53;
include "rsuzones/rsuzones.conf";

3. Tal como se puede apreciar en el paso anterior , la directirva include

hace referencia a un directorio ”rsuzones” y un archivo ”rsuzones.conf”,
estos deben ser creados bajo ”/var/named/chroot/etc/” y asegurar que
los permisos de estos sean rwxr-x— y su propiedad sea ”root.named”.

4. Edite con vim(1) o nano(1) el archivo ”rsuzones.conf ” anteriormente

creado y agregue el siguiente contenido:

zone "enterprise.com"{
type master;
file "rsuzones/enterprise.com";
};

zone "10.16.172.in-addr.arpa"{
type master;
file "rsuzones/172.16.10.zone";
};

5. Los archivos anteriormente declarados en el paso anterior corresponden a

la configuración de la zona maestra del dominio ”enterprise.com” y su zona
reversa para la subred ”172.16.10.0/24”, estos archivos deben ser creados
bajo el directorio ”/var/named/chroot/etch/rsuzones”(ej: touch(1)).

6. Edite con vim(1) ó nano(1) el archivo ”enterprise.com” anteriormente

declarado y creado, de forma que contenga la siguiente información, la cual
indica los registros de recursos para la zona ”enterprise.com”. El caracter
”;” en este archivo representa el comienzo de un comentario.(no confundir
con el fin de linea del archivo ”named.conf”
Redes y Seguridad en ambiente Unix -lab 3.2 5

$TTL 1D;
@ IN SOA ns1.enterprise.com. admin.enterprise.com. (
2009001; Serial
1M; Refresco en 1 minuto
2H; Reintento en 2 horas
1D; Expira en 1 dia
1D); TTL minimo en cache

@ IN NS ns1.enterprise.com.
@ IN NS ns2.enterprise.com.
@ IN MX 10 maserv.enterprise.com.
@ IN TXT "BIND 9 ENTERPRISE.COM"

@ IN A 172.16.10.10
ns1 IN A 172.16.10.10
ns2 IN A 172.16.10.15
maserv IN A 172.16.10.11
serinet IN A 172.16.10.12
devser IN A 172.16.10.13

www IN CNAME serinet.enterprise.com.

mail IN CNAME maserv.enterprise.com.
imap IN CNAME maserv.enterprise.com.

7. Ahora al igual que el paso anterior pero esta vez con el archivo ”172.16.10.zo-
ne”, que corresponde a la zona reversa de la subred 172.16.10.0, editelo
de forma que contenga las siguientes sentencias:

$TTL 1D; tiempo de vida en el servidor esclavo

@ IN SOA ns1.enterprise.com. admin.enterprise.com. (
2009001; Serial
1M; Refresco en 1 minuto
2H; Reintento en 2 horas
1D; Expira en 1 dia
1D); TTL minimo en cache

@ IN NS ns1.enterprise.com.
@ IN NS ns2.enterprise.com.

10 IN PTR ns1.enterprise.com.
11 IN PTR maserv.enterprise.com.
12 IN PTR serinet.enterprise.com.
13 IN PTR devserv.enterprise.com.
15 IN PTR ns2.enterprise.com.
Redes y Seguridad en ambiente Unix -lab 3.2 6

8. Hasta el momento hemos configurado BIND para que posea autoridad

sobre una zona (enterprise.com) y pueda hacer resoluciones de nombres y
resoluciones reversas segÚn lo recomendado en el RFC 1035 y relacionados
con el servicio de nombres de dominio, ahora debemos reiniciar el daemon
”named” para que los cambios en la configuración tengan efecto, esto lo
realizamos con el comando #service named restart y de no haber algún
error de escritura, reiniciará el daemon adecuadamente.
9. ahora podemos comprobar la existencia de este servicio (daemon) con
el comando #netstat -tnpl y ver en que dirección está escuchando el
puerto 53 tcp y con #netstat -unpl para ver el que esta sucediendo con
el puerto 53 udp, en ambos caso debemos ver proceso ”named” en el socket
172.16.10.10:53.

Metodologı́a
Realice paso a paso lo indicado y preste atención a los siguientes puntos:

1. Localización del archivo editado

2. Sentencias aplicadas y su efecto en la configuración

Actividad 4: Comprobación con el cliente

Detalles de la Actividad:
En la siguiente actividad se realizará una configuración en la máquina virtual
llamada ”CentOS52-lite”, de forma que pueda probar la resolución de nom-
bres a través del servidor anteriormente configuraddo. Es recomendable leer la
documentación de resolv.conf(5) y dig(1) , para tener una mejor comprensión de
la resolución de nombres de domino por parte del resolver de las distribuciones
de Linux/Unix. Los parámetros de red fueron configurados en la actividad 2 a
modo de que existiera conectividad de capa de red con el servidor configurado
en el paso anterior

1. Ahora se debe configurar el servidor de nombres utilizado para las resolu-

ciones de nombres a direcciones y viceversa. edite el archivo ”/etc/resolv.conf ”
y en él asegurese de que solamente contenta esta información:

nameserver 172.16.10.10
nameserver 172.16.10.15

2. Ahora es necesario realizar las pruebas de resolución de nombres, y para

esto utilizaremos el comando ”dig”, el cual puede realizar resoluciones
y resoluciones reversas asi como transferencias de zona, lo que es ideal
para este caso. Use los siguientes comandos para comprobar el correcto
funcionamiento del servidor BIND configurado.
Redes y Seguridad en ambiente Unix -lab 3.2 7

#dig serinet.enterprise.com
#dig mail.enterprise.com
#dig -x 172.16.10.13
#dig enterprise.com
#dig enterprise.com -t axfr
Estos comandos nos proveen de distintos tipos de información que se puede
obtener de una zona determinada (dominio).
El primer comando busca el valor del registro A del nombre serinet que
contiene la dirección IP definida para ese host.
El segundo comando intenta obtener también el registro de tipo A pero
primero se encontrará con un registro de tipo CNAME que contiene el
nombre del verdadero host tras el sobrenombre (CNAME) y se hará una
segunda resolución para finalmente entregar el resultado esperado (la di-
rección IP del host maserv).
El tercer comando realiza una resolución inversa esta vez buscando el
contenido del registro PTR asociado a esa dirección IP 172.16.10.13, cuyo
resultado deberı́a ser devserv.enterprise.com
El cuarto comando busca el registro tipo A para el dominio enterprise.com,
este usualmente es el mismo que el asociado al comienzo de autoridad
(SOA), en este caso deberı́a ser congruente con lo mencionado y entregar
la dirección IP del host ns1.enterprise.com (172.16.10.10)
El quinto comando es lo que llamamos una transferencia de zona completa
(full), es representado con el registro de tipo AXFR, el resultado de este
comando son todos los registros configurados en la zona enterprise.com
(cabe destacar que el comando -t puede entregar información de otros
tipos de registro, com MX, SOA, etc)

Metodologı́a
Realice paso a paso lo indicado y preste atención a los siguientes puntos:

1. Localización del archivo editado

2. Sentencias aplicadas y su efecto en la configuración

3. Opciones de las lı́neas de comandos ejecutadas

4. Resultados obtenidos
Redes y Seguridad en ambiente Unix -lab 3.2 8

Actividad 5: Control de acceso a las Consultas

Detalles de la Actividad:
En la siguiente actividad se realizará una configuración en la máquina vir-
tual llamada ”CentOS52-Services”, de forma utilizar listas de acceso para
restringir quienes acceden a consultar por las zonas autoritativas del servidor
BIND. Es recomendable leer la documentación de named.conf(5) , para tener
una mejor comprensión de las opciones de configuración de BIND.
Para esta actividad se considera que el host cliente tiene asignada inicial-
mente la dirección 172.16.10.16/24

1. Edite el archivo ”/var/named/chroot/etc/rsuzones/rsuzones.conf ”

y agregue al principio de este archivo la siguiente información:

acl confianza {172.16.10.0/24;};

acl seguros {
172.16.10.14;
172.16.10.15;
};

De esta forma estamos definiendo dos listas de acceso las cuales nos per-
miten simplificar el proceso de control de acceso a recursos del servidor.
Ambas listas de acceso ilustran formas diferentes de ingresar restriccio-
nes/permisos ya sea por rangos de direcciones o hosts especı́ficos.
2. Ahora dentro del mismo archivo, en la declaración de las zonas , edite de
forma que quede de la siguiente manera:

zone "enterprise.com"{
type master;
file "rsuzones/enterprise.com";
allow-query{confianza;};
allow-transfer{seguros;};
};

zone "10.16.172.add-in.arpa"{
type master;
file "rsuzones/172.16.10.zone";
allow-query{seguros;};
};

3. Ahora debemos indicarle a BIND que recargue la configuración, esto lo

hacemos usando el comando #service named reload (restart también
sirve) para hacer uso de las listas de acceso recientemente definidas.

4. Ahora desde el cliente, ejecutamos los comandos:

Redes y Seguridad en ambiente Unix -lab 3.2 9

#dig imap.enterprise.com
#dig -x 172.16.10.10
#dig enterprise.com -t axfr
El resultado de estos comandos deberia ser positivo solamente en el pri-
mero ya que la dirección del host cliente es 172.16.10.16 la cual coincide
con la lista de acceso (acl) ”confianza” la que le hemos permitido hacer
consultas (allow-query).
Para las otras dos consultas el resultado debe ser negativo (arrojar Status:
REFUSED) dado que la lista de acceso ”seguros” no coincide con la direc-
ción actual del cliente, y la transferencia de zona fallará (arrojar Transfer
failed.)

Metodologı́a
Realice paso a paso lo indicado y preste atención a los siguientes puntos:

1. Sentencias aplicadas y su efecto en la configuración

2. Resultados obtenidos dadas las modificaciones

Actividad 6: Zonas Esclavas

Detalles de la Actividad:
En la siguiente actividad se realizará una máquina virtual clonada de la
máquina virtual configurada con el servidor BIND, esta imagen será llamada
”CentOS52-Services2”.(nombre dado durante la clonación)
Es recomendable leer la documentación de named.conf(5) , para tener una
mejor comprensión de las opciones de configuración de BIND.
Para esta actividad se considera que esta máquina tiene asignada inicialmen-
te la dirección 172.16.10.15/24, que es necesaria para ser consistente con las con-
figuraciones hechas en actividades anteriores. Se requiere que esta máquina(CentOS52-
Servicios2) tenga una configuración similar a la máquina ÇentOS52-Servicios”de
modo que named.conf ya esté configurado de igual forma salvo la dirección que
escucha en el puerto 53 (aca debe ser 172 .16.10.15). todo esto es para ahorrar
tiempo, pero como práctica es recomendable volver a configurar los archivos
para reforzar su comprensión
Una buena práctica es clonar la máquina ”Serviciosüna vez ya configurada
(actividades anteriores) y realizar las adaptaciones necesarias (configuración de
interfaz de red y named.conf) para su correcto funcionamiento.
Cabe destacar que aca no es necesario la creación de los archivos de zona,
pues automáticamente serán creados cuando la sincronización entre maestro y
esclavo es realizada, basta con configurar el lugar destino.
Configure los siguientes Pasos:
Redes y Seguridad en ambiente Unix -lab 3.2 10

1. Ahora edite el archivo rsuzones/rsuzones.conf edite la declaración de zonas

de forma que quede de la siguiente manera:

acl maestros {172.16.10.10;};

zone "enterprise.com"{
type slave;
masters {maestros;};
file "rsuzones/enterprise.com";
allow-query{confianza;};
allow-notify{maestros;};
};

zone "10.16.172.add-in.arpa"{
type slave;
masters {maestros;};
file "rsuzones/172.16.10.zone";
allow-query{confianza;};
allow-notify{maestros;};
};

El esclavo verificará cambios al maestro cada vez que se cumpla el tiempo

de refresco declarado en las zonas.(refresh), como se puede notar las zonas
son de tipo ”slave” y su servidor maestro esta declarado como 172.16.10.10
, las consultas están permitidas para la acl ”confianza” y un nuevo paráme-
tro permite ser notificado de cambios (serial) por ”maestros” exclusiva-
mente.
2. Una vez realizado los pasos anteriores, verifique la correcta configuración
y proceda a reiniciar el servicio named con el comando ”#service na-
med restart”, cualquier otro cambio importante puede ser reeplazdo el
”restart” por ”reload”.
3. Usando el comando ”#tail -f /var/log/messages”, podemos dejar cons-
tatemente en ejecución y a la espera de cambios la visualización del registro
de eventos global, el cual notificará cualquier transacción que bind haga.
Mediante el cual podremos observar los intentos de transferencias de zo-
nas completas (AXFR) e incrementales (IXFR) entre maestro y esclavo,
cabe destacar que cada un minuto (tiempo refresh) se pueden ver estos
intentos siempre que exista algúna variante en el archivo de configuración
del servidor maestro (notificación de serial).
4. Una vez que haya notado alguna sincronización realizada, pruebe desde el
”Cliente” usar el comando #dig www.enterprise.com @172.16.10.15
para consultar al segundo servidor (esclavo) por este registro en enterpri-
se.com y de esta manera comprobar que el servidor esclavo ya está listo
para responder autoritativamene para esta zona.
Redes y Seguridad en ambiente Unix -lab 3.2 11

Limpieza
Después de obtenidos los resultados,puede eliminar las máquinas virtuales
duplicadas tanto del disco duro como de los favoritos de VMware