2º ASIR / Servicios en Red e Internet (SERI)

Práctica : "ud1p1 Instalación del Laboratorio de redes

por Manuel Aragonés

Recursos facilitados en el Aula:

- Software de virtualización: Virtual Box Oracle (https://www.virtualbox.org/wiki/Downloads)
- Imagen ISO Linux Debian
- Imagen ISO Linux Debian Gráfico
- Imagen ISO Windows 7
- Imagen ISO Windows Server 2012
- Imagen ISO Zentyal
- Imagen ISO Pfsense
- Imagen ISO CentOS 7
- Manuales, Internet.

Crearemos una infraestructura de subredes mediante la Virtualización de hosts con diferentes

sistemas operativos dentro de cada equipo Anfitrión del ordenador del Aula.
Dicha infraestructura se convertirá en nuestro Laboratorio para el modulo de SERI para el
desarrollo del estudio y práctica de los distintos temas que veremos a lo largo de todo el curso.
El software de virtualización que usaremos será el software Libre Virtual Box de la
empresa Oracle Configuración de las máquinas virtuales
Debemos prestar especial atención a la hora de configurar las Maquinas Virtuales (MV) a la
memoria RAM asignada a la MV y a las conexiones de red de las tarjetas virtuales.

Conexión de red
En general, todo software de virtualización ofrece los siguientes tipos de conexión:

o Red Interna. La conexión de la MV se conecta a una

Red Virtual Interna al software de Virtualización y
totalmente aislada de la Red Física a la que está
conectada la máquina Anfitriona.

1
o Adaptador Puente (Bridge).La conexión de red de la
MV se conecta a la misma Red Física a la que está
conectado el sistema Anfitrión real pero con total
independencia de la misma, gracias a que dispondrá de
una dirección IP especifica perteneciente a la Red Física.
De esta forma, cualquier datagrama enviado o recibido por la
tarjeta de red de la MV pasará por la tarjeta de Red Física de
la maquina Anfitriona, pero con una dirección IP distinta.

o NAT. La MV accede a la misma Red Física a la que está conectado el

sistema anfitrión a través de la propia dirección IP del sistema
anfitrión mediante NAT.
Un encaminador NAT virtual gestionado por el software de
virtualización se encarga de ello.

4
Esquema de la infraestructura del Laboratorio SERI

5
 2.1 Instalación y configuración MV Debian Cliente "debianClienteXX"
o Realiza la instalación del SO Linux Debian a partir de la imagen ISO facilitada en el Aula
o Respeta la configuración de usuarios y claves propuestas
o No debes instalar la parte gráfica.
o Selecciona un particionado guiado
o Nombra a tu Maquina Virtual "debianClienteXX" y crea el usuario "alumno" con
la clave "passetg0" y la misma password para el usuario administrador "root"
o Inicia sesión en debianClienteXX con el usuario root
o Averigua el nombre de los interfaces de red con el comando:
# ip address
# ifconfig
o Vamos a configurar el direccionamiento IP de acuerdo a tu esquema de Laboratorio.
o Configura los parámetros de red del adaptador de red en modo Red Interna con la IP:
10.X.0.2/24
o Para ello, edita el fichero de configuración de las interfaces de red en Linux:
# nano /etc/network/interfaces
Con la siguiente configuración:
auto enp0s3
allow-hotplug enp0s3
iface enp0s3 inet static
address 10.X.0.2
netmask 255.255.255.0
gateway 10.X.0.1
dns-nameservers 213.0.88.85
o O también puedes editar el fichero de configuración para Servidores DNS:
# nano /etc/resolv.conf
nameserver 213.0.88.85
o Reinicia el Servicio de Red para aplicar los cambios realizados, con el comando:
# /etc/init.d/networking restart
O también puedes hacerlo con el comando:
# service networking restart
o Vamos a comprobar que tenemos los Repositorios bien configurados, para ello comprueba:
# nano /etc/apt/sources.list
Tienes un contenido equivalente a (si no, no se ha modificado en la instalación, modificalo):

6
o Ahora vamos a actualizar los repositorios mediante el comando:
# apt-get update
o Ahora vamos a actualizar el sistema:
# apt-get upgrade

o Linux Debian, no trae el comando sudo, vamos a instalarlo en el sistema por su

usabilidad (adapta tu MV para permitir la conexión a Internet de la forma que consideres)
# apt-get install sudo (si no lo tiene instalado, en Debian 10 vuelve a venir instalado)
# nano /etc/sudoers Añadimos por cada nuevo usuario de Linux su uso:
alumno ALL=(ALL)ALL
Salimos grabando de nano con Ctrol +X

2.2. Instalación y configuración MV Debian Servidor "debianServidorXX", a partir de

la Clonación de la MV creada anteriormente.

En esta práctica vamos a configurar la MV con el SO debian como Encaminador o

Router y con función NAT por iptables para la Red Virtual.
o Crea una nueva MV en Virtual Box con la imagen ISO debian (clonala de la MV Debian anterior) a la
que llamaremos debianServidorXX y a la que le asignaremos
(descarga 25 MB, en disco 95 MB aprox)
2 Interfaces de red que conectaremos
enp0s3 a la Red Física (Modo puente)
enp0s8 a la Red Virtual interna (Red interna)
o Configura las siguientes direccionamientos IP
enp0s3: DHCP
enp0s8: 10.X.0.1 /24
o Al realizar la clonación nos guarda el mismo nombre del hostname, vamos a cambiarlo: Edita el
fichero de configuración del nombre de host, según tu asignación del Laboratorio:
# nano /etc/hostname
debianClienteXX (ejemplo debianCliente01)
o Lanza el script del hostname para leer el nuevo nombre.
# /etc/init.d/hostname.sh (No Debian 10)
o Edita el fichero /etc/hosts con el comando: #nano /etc/hosts y asocia el nombre debianClienteXX
con la dirección IP de bucle interno (127.0.1.1) como se indica:
127.0.0.1 localhost
127.0.1.1 debianClienteXX

o Para ver reflejado el cambio de nombre de equipo deberás cerrar sesión o reiniciar.

o Comprueba si lo realizado hasta ahora es suficiente para que debianServidorXX

encamine entre la red interna y la externa.
Para ello arranca las 2 maquinas virtuales creadas hasta ahora y desde la MV
"debianClienteXX" ejecuta los siguientes comandos:
dSXX# ip address
dSXX# ping 10.X.0.2
dSXX# ping 8.8.8.8
dCXX# ping 8.8.8.8 [No debería realizar el ping. Esto es debido a que la MV
debianServidor00 no enruta de forma predeterminada, lo realizaremos más adelante. ]
dSXX# ip route [Visualiza su Tabla de Rutas, debe tener 3
entradas] dSXX# route -n
dSXX# netstat -r
7
 2.2 Instalación y configuración MV Ubuntu Desktop "debianGraficoXX" , a partir de la
Clonación de la MV "debianClienteXX"

o Crea una nueva MV en Virtual Box con la imagen ISO debian (clónala de la MV
debianClienteXX) a la que llamaremos debianGraficoXX.
o Respeta la configuración de usuarios y claves propuestas
o Renombra el hostname como realizamos en la MVs anterior.
o Asegúrate de conseguir tener acceso a Internet y tener bien configurado los DNS.
o Ahora a partir del sistema Debian de consola vamos a instalar el Escritorio Ligero LXDE para Debian:

#apt-get update
#apt-get install xserver-xorg-video-all
#apt-get install lxde xorg

o Reinicia el sistema y arrancara automáticamente el modo gráfico LXDE.

o Inicia sesión en debianGraficoXX con el usuario alumno
o Instalación de un navegador web grafico ligero
# apt-get install epiphany-browser

Algunos de los pings que hicimos en el apartado anterior no funcionaron porque debianServidor no
tiene servicio de Encaminamiento habilitado, lo que impide que los ordenadores de la Red Interna
no puedan conectarse a otras redes fuera de ella (incluido Internet).
Hacer que Linux realice la tarea de Encaminamiento, es cuestión de una línea:

# echo 1 > /proc/sys/net/ipv4/ip_forward

Para deshabilitarlo escribiríamos un "0".

Sin embargo, este modo de habilitación es modo no permanente, de forma, que si queremos
hacerlo permanente, modificaremos directamente en el fichero de configuración de Linux:

# nano /etc/sysctl.conf

Y eliminar el comentario "#" del comienzo de la línea

net.ipv4.ip_forward = 1

1) Vuelve a poner el adaptador enp0s3 de debianServidor en modo puente. Y configura

mejor para que el Servicio de NAT lo haga tu debianServidor mediante la orden de
iptables (NAT no persistente), de esta forma conseguiremos que a los paquetes de los
Clientes de nuestra Red Interna se les haga NAT y por tanto tengan salida a Internet:
# iptables -t nat -A POSTROUTING -o enp0s3 -j MASQUERADE
Repite el apartado 9)
12) Desde el debianCliente al debianCliente de otro compañero
Ejemplo del proceso NAT

Ejemplo-2 del proceso

NAT / MASQUERADE

Netfilter es un framework disponible en el núcleo Linux que permite interceptar y manipular

paquetes de red. Dicho framework permite realizar el manejo de paquetes en diferentes estados
del procesamiento. Netfilter es también el nombre que recibe el proyecto que se encarga de
ofrecer herramientas libres para cortafuegos basados en Linux.
El componente más popular construido sobre Netfilter es iptables, una herramienta de cortafuegos que
permite no solamente filtrar paquetes, sino también realizar traducción de direcciones de red (NAT) para
Ipv4 o mantener registros de log. El proyecto Netfilter no sólo ofrece componentes disponibles como
módulos del núcleo sino que también ofrece herramientas de espacio de usuario y librerías.
iptables es el nombre de la herramienta de espacio de usuario mediante la cual el administrador
puede definir políticas de filtrado del tráfico que circula por la red. El nombre iptables se utiliza
frecuentemente de forma errónea para referirse a toda la infraestructura ofrecida por el proyecto
Netfilter. Sin embargo, el proyecto ofrece otros subsistemas independientes de iptables tales
como el connection tracking system o sistema de seguimiento de conexiones, que permite encolar
paquetes para que sean tratados desde espacio de usuario. Iptables es un software disponible en
prácticamente todas las distribuciones de Linux actuales.
11
Connection Tracking (conntrack) de Netfilter.
Netfilter guarda una tabla en /proc/net/ip_conntrack con las conexiones aceptadas, las
establecidas y las relacionadas, para mantener en todo momento el estado del firewall y saber
que conexiones permitir y cuales no.

Revisa el contenido de la tabla ip_conntrack para ver el seguimiento de las conexiones

establecidas por el proceso NAT de iptables, mediante el comando

# cat /proc/net/ip_conntrack

12
 PARTE WINDOWS

4.1. Instalación y configuración MV Windows XP/7: "winClienteXX"

o Realiza la instalación del SO Windows XP/7 a partir de la imagen ISO facilitada en el Aula.
o Respeta la configuración de usuarios y claves propuestas.
o Importante: Deshabilita la instalación de actualizaciones automáticas.
o Configura los parámetros de red del adaptador de red en modo Red Interna con la IP 10.X.0.4 /24
o Accede a las propiedades del protocolo de Internet versión 4 TCP/IPv4 (Menú Inicio, Panel Control,
Redes e Internet, Centro de redes y recursos compartidos, Conexión de área local, Propiedades,
Protocolo de Internet versión 4) y añade la configuración:
IP: 10.X.0.4
Mascara: 255.255.255.0
Puerta enlace: 10.X.0.1
DNS: 213.0.88.85
o Comprueba la conexión a Internet desde Windows XP.
o Configura el nombre del equipo accediendo a la ventana "Cambios en el dominio o nombre del
equipo" (Menú Inicio, Panel de Control, Sistema y Seguridad, Sistema, Cambiar configuración,
Cambiar...), asignándole el nombre winClienteXX y lo incluiremos en el grupo de trabajo VIRTUAL..
o Reinicia el sistema para activar la nueva configuración

4.2 Instalación y configuración MV Windows Server 2012: "winServidorXX"

o Realiza la instalación del SO Windows Server 2012 a partir de la imagen ISO facilitada en el Aula.
o Respeta la configuración de usuarios y claves propuestas.
o Importante: Deshabilita la instalación de actualizaciones automáticas.
o Configura los parámetros de red del adaptador de red en modo Red Interna con la IP 10.X.0.5 /24
o Accede a las propiedades del protocolo de Internet versión 4 TCP/IPv4 (Menú Inicio, Panel Control,
Redes e Internet, Centro de redes y recursos compartidos, Conexión de área local, Propiedades,
Protocolo de Internet versión 4) y añade la configuración:
IP: 10.X.0.5
Mascara: 255.255.255.0
Puerta enlace: 10.X.0.1
DNS: 213.0.88.85
o Comprueba la conexión a Internet desde Windows Server.
o Configura el nombre del equipo accediendo a la ventana "Cambios en el dominio o nombre del equipo"
(Menú Inicio, Panel de Control, Sistema y Seguridad, Sistema, Cambiar configuración, Cambiar...),
asignándole el nombre winServidorXX y lo incluiremos en el grupo de trabajo VIRTUAL.
o Reinicia el sistema para activar la nueva configuración

13
PARTE SISTEMAS INTEGRADOS

5.1 Instalación y configuración de la MV Zentyal en la Red Virtual

Manuales Zentyal:
https://wiki.zentyal.org/wiki/Es/4.1/Zentyal_4.1_Documentacion_Oficial

http://www.zentyal.com/es/
s
Zentyal es un Servidor de Red unificada de código abierto para PYMEs.

Puede actuar gestionando la infraestructura de red como puerta de enlace a Internet

(Gateway) gestionando las amenazas de seguridad, como Servidor de oficina, como
Servidor de comunicaciones unificadas o una combinación de estas.

Zentyal es un SO Linux basado en Ubuntu que incluye multitud de herramientas para:

Gestión de redes (Cortafuegos, Encaminamiento, NAT, Reglas para múltiples
Puertas de enlace, balanceo de carga, VPN.
Infraestructura de red (DHCP, DNS, Servidor
Radius) Proxy HTTP con SQUID y DansGuardian
Sistema de detección de intrusos, con
SNORT Servidor de Correo
Servidor Web
Trabajo en grupo
Servidor VozIP

o Crea una nueva MV llamada zentyalXX con 2 Adaptadores de red e instala el SO a

partir de la imagen ISO facilitada en el Aula.
o Respeta la configuración de usuarios y claves propuestas.
o Arranca la MV e inicia sesión en Zentyal.
o Instala la infraestructura básica de red.
o Nada más entrar al sistema verás un formulario de acceso en el navegador web que en
cuando te logues te llevara al Panel de Control de Zentyal donde verás todos los
Servicios que puedes instalar y configurar.

Panel de Administración vía web (permite su acceso tanto Local como Remoto)

14
5.2. Configuración TCP/IP, NAT y Encaminador en Zentyal

Zentyal gestiona todas sus configuraciones agrupadas por Modulos , y cada uno de estos
modulos puede estar activo o no. Por tanto, para el correcto funcionamiento de la configuración
de los parametros de cada modulo éste debe estar activo en Estado de los Modulos.

Configura los parametros de direccionamiento IP de los 2 adaptadores de red de Zentyal,

de forma que, tenga las mismas IPs que los otros Encaminadores.

Desde el entorno grafico a través del Navegador web,

- Para cualquier cambio de cualquier parametro 1º hay que pulsar el boton "Cambiar" y
al final el boton amarillo "Guardar cambios" de arriba a la derecha.

Busca en el panel y configura lo siguiente:

a) Cambio de idioma a Español

b) Configuración de los 2 Adaptadores de red

eth0: Acceso WAN - Red Fisica; 192.168.y.0

eth1: Red Interna: 10.X.0.1

c) Configura IP de la Puerta de Enlace correspondiente a la IP- Puerta Enlace IES

d) Comprueba su conectividad
- Clientes de tu Red Interna a eth1 de Zentyal
e) Una vez asegurado de la prueba anterior, habilita el Encaminamiento para que los
equipos Clientes puedan salir a Internet a través del Encaminador-NAT Zentyal
f) Comprueba su conectividad
- Clientes de tu Red Interna a Router IES a través de Zentyal
- Clientes de tu Red Interna a Internet.
g) Prueba el acceso remoto al Panel de Control de Zentyal desde el equipo ubuntuClienteXX.

15
 5.3. Comprobación de la conectividad

o Asegúrate de tener arrancadas todas las MVs

o Inicia sesión en debianXX con uno de los dos usuarios disponibles (root o alumno)
o Realiza un ping al resto de MV's

a) Habilitar respuesta a ping

o Los sistemas Linux tienen habilitada por defecto la respuesta a pings, pero en Windows 7
y 2012 no. Por tanto, habilita en el Firewall de Windows el uso compartido de archivos, o
bien, desde el Firewall de Windows, buscamos la regla de tráfico entrante de pings (Inicio,
Panel de Control, Firewall de Windows, Configuración Avanzada, Reglas de Entrada...)

6. Configuración encaminador red local virtual con Pfsense

En esta práctica vamos a configurar el encaminador NAT de la red virtual para permitir la
comunicación entre la red virtual y el exterior.
Disponemos de varias alternativas para esta tarea. En general, esto es posible
configurando cualquiera de los SO (tanto Linux como Windows) para realizar esta función
de encaminador o router.
Pero en los últimos años, han surgido varias distribuciones Linux y FreeBSD
(https://www.freebsd.org/es/) adaptando su configuración como Cortafuegos y encaminadores
NAT como es el caso de:
Pfsense http://www.Pfsense.org/index.php
IPFire http://www.ipfire.org/
Pfsense https://www.pfsense.org/

6.1 Instalación y configuración del ENCAMINADOR+NAT con Pfsense

El perfil que tendra la MV “pfsense” sera la de ENCAMINADOR + NAT

Para ello deberemos hacerle trabajar con 2 adaptadores de red que será necesario configurarselos
antes de la instalación del sistema.

Crear una MV con la siguiente configuración

Memoria RAM: 512 MB

Tamaño HD: 8 GB
Configuración de Adaptadores de red
• Adaptador 1. Modo puente (em0)
• Adaptador 2. Red Interna (em1)
16
Inciamos el sistema, pulsando 1 para el arranque multiusuario

Importante en la siguiente pantalla pulsar I de INSTALLER (instalador) para conseguir que el sistema se
instale en el HD de la MV sino arrancara en modo live

- Instalación “auto”
- Elimina el archivo ISO del CD
Observamos los datos de configuracion por defecto:
- Como la IP que haya podido recibir del Servidor DHCP (Ej. 192.168.1.41)
17
- La denominación de los adaptadores de red WAN: em0, LAN: em1 (192.168.1.1)

18
 ➔ Desde el anterior menu, cambia la dirección IP del adaptador LAN para que tenga la IP
10.X.0.1 (la misma que tu debianServidorXX (ten en cuenta que en principio tienen el mismo
ROL y que no los ejecutaremos normalmente de forma simultanea)

Luego nos preguntara si queremos ACTIVAR un Servidor DHCP para la LAN le decimos que NO.

Despues nos preguntara si queremos volver al protocolo HTTP o bien dejarlo en HTTPS para el
acceso al panel de control, le diremos que NO queremos volver a HTTP.

19
Asegurate de tener como ENCAMINADOR+NAT solo el pfsense encendido.

6.2. Comprobación de la instalación

La forma más sencilla consiste en ver si los sistemas de la Red Virtual Interna ya disponen
de acceso a la Red Exterior / Internet

o Realiza los siguientes pings desde cualquier MV de la Red Virtual (debian, windows7,...)
ping IP-Gateway-del-Aula
ping 213.0.88.85
ping www.google.es

o Comprueba el acceso vía web desde cualquier ordenador de la Red Interna (por
seguridad, solo se podrá acceder desde aquí) a la Administración del sistema Pfsense
Introduce el usuario admin/passetg0 para acceder:
Observa los puertos que tiene abierto desde consola
https:// 10.X.0
7.CentOS 7 configuración de red

- Identificar las interfaces de red

# ip add
Ejemplo: enp0s3
- Ir al path /etc/sysconfig/network-scripts/
# cd /etc/sysconfig/network-scripts/
- Localizar el fichero cuyo nombre contiene el nombre del interfaz de red
anterior. Ejemplo: ifcfg-enp0s3
# vi ifcfg-enp0s3
- Cambia o modifica los siguientes parámetros del fichero
………………………………….
BOOTPROTO=static
IPV6INIT=no
IPV6_AUTOCONF=no
DEVICE=enp0s3
ONBOOT=yes
IPADDR0=10.0.0.6
PREFIX0=24
GATEWAY0=10.0.0.1
DNS1=8.8.8.8[213.0.88.85]
……………………………………...
Salir grabando <ESC> :wq

Notas
- BOOTPROTO determina el tipo de configuración que tiene la interfaz, puede ser:
none (ninguna),
static (estática)
dhcp (asignación de ip dinámica por dhcp). Por lo general en un servidor siempre se debe
configurar como static.

- ONBOOT si la interfaz de red que estás configurando debe de levantarse de forma automática cuando arranca el
servicio network entonces debes configurar esta opción como “yes” de lo contrario el servidor arrancará y la interfaz
permanecerá desactivada hasta que manualmente la actives. Recuerda que CentOS 7 siempre configura esta
opción como “no” por lo que no tendrás conexión a la red por default en la interfaces de red.

-IPADDR0 es la primera dirección IP de la interfaz, recuerda que puede haber varias.

21
-PREFIX0 es el pefijo de red, antes llamado NETMASK de la primera IP, recuerda que puede haber varias.

-GATEWAY0 es la puerta de enlace o la pasarela de la primera IP y puede haber varias.

-DNS1 es la dirección IP del servidor de resolución de nombres de

dominio Test de la red en Centos

Para ello debemos reiniciar las interfaces, en esta versión se hace con systemctl

# systemctl stop NetworkManager

# systemctl disable NetworkManager

Ahora reiniciamos el Servicio

# systemctl restart network.service

Comprueba el nuevo direccionamiento IP

# ip addr

Esquema de la infraestructura final con todas las MVs

2º ASIR / Servicios de red e Internet (SERI)

UD2. Instalación de servicios de configuración dinámica de sistemas: DHCP (Dynamic
Host Configuration Protocol o Protocolo de Configuración Dinámica de Host)
DHCP es un protocolo de Red de tipo Cliente/Servidor de Capa de Aplicación cuya función es
realizar la configuración de red automática de equipos clientes dentro de la arquitectura TCP/IP.
El Servidor mantiene una lista de direcciones IP dinámicas disponibles y se las va asignando a
los clientes durante un tiempo limitado conforme se producen Peticiones o Solicitudes, según
van venciendo las concesiones éstas se pueden renovar o liberar definitivamente y por tanto
pasar a estar nuevamente disponibles para nuevos clientes DHCP.

Su utilización tiene muchas ventajas como facilitar la tarea administrativa del administrador de
redes, mayor flexibilidad en la movilidad de clientes entre distintas redes, los cambios de
configuraciones se realizan más cómodamente.
Como inconvenientes, se puede plantear la generación de paquetes por difusión o broadcast,
pero sin embargo éstos son mínimos limitados al que envía el Cliente para descubrir los
Servidores DHCP alcanzables en el dominio de difusión.
Sin embargo, no resulta recomendable para la configuración de equipos de Servidor, ya que un
fallo en el Servidor DHCP podría dejar a éstos inutilizados.
Existe una Tecnología que puede ser útil para mantener la conectividad en redes pequeñas ante
el fallo del Servidor DHCP, basada en zeroconf.org:
o APIPA (Direccionamiento Privado Automático del Protocolo de Internet) es un protocolo
que utilizan los sistemas que funcionan bajo Windows para obtener la configuración de
red cuando el sistema está configurado para obtener una dirección dinámicamente y al
iniciar éste no encuentra un servidor DHCP .
Este protocolo asigna una dirección IP en el rango 169.254.0.1 - 169.254.255.254/16
o Otras implementaciones de esta tecnología son:
El demonio Avahi en Linux "avahi-autoipd" busca recursos de la red y se
conecta a ellos automáticamente. El demonio Avahi facilita compartir archivos e
impresoras, y actúa como un servidor DHCP y DNS.
Y Bonjour para Apple.

Los puertos de escucha de

DHCPv4 son: Servidor: 67 /UDP
Cliente: 68 / UDP
Los puertos de escucha de
DHCPv6 son:
Servidor: 547 /UDP
Cliente: 548 / UDP
TCP Puertos en Servicio Failover
Servidor 647 /TCP
El funcionamiento del Servicio DHCP está
basado en el Modelo Cliente / Servidor y está
formado por los siguientes componentes:
Servidor DHCP
Cliente DHCP
Protocolo DHCP

Agentes de retransmisión DHCP. Escuchan peticiones de clientes DHCP y las retransmiten a

servidores DHCP ubicados en otras redes. Se utilizan para centralizar la configuración del
servicio DHCP en múltiples redes.

En una misma red es posible que convivan equipos configurados de forma Dinámica y
otros de forma Estática.
Si un mismo equipo tiene configurado un direccionamiento estático y dinámico, los parámetros
estáticos sobrescriben los dinámicos.
1
Tipos de asignación por el Servidor DHCP
Existen 3 tipos de asignaciones DHCP de un Servidor a un Cliente:
- Asignación manual o estática (Reservas) . Consiste en asignar direcciones IP
concretas a maquinas concretas. A cada dirección física (MAC) le corresponde una
dirección IP preasignada por el Administrador de redes.

- Asignación dinámica. El Servidor elige una dirección de un grupo de direcciones

disponibles
(rango/ámbito). Realiza una concesión de la dirección IP al cliente durante un plazo
limitado (lease time)

- Asignación automática . Asigna direcciones IP de forma permanente a máquinas cliente la

primera vez que hacen la solicitud al servidor DHCP y hasta que el cliente las libera.
En este caso, el plazo de concesión es ilimitado, a diferencia de las dinámicas.

Ámbito y Rango
Se puede definir un ámbito como un agrupamiento administrativo de equipos o clientes de
una red que utilizan el servicio DHCP.
Dentro de ese ámbito se reserva un Rango de direcciones IP para otorgar a los clientes de
dicho ámbito, Ej.: 192.168.1.100 a 192.168.1.200
Normalmente, el administrador de red creará un ámbito para cada subred y los
parámetros de configuración de red para los clientes.
En un mismo servidor DHCP se pueden configurar
tantos ámbitos y rangos como sea necesario.

Exclusiones
Un conjunto de direcciones pueden ser excluidas
de un rango para no asignarlas a clientes DHCP.
Normalmente se suelen excluir del rango
aquellas direcciones IP que corresponden a
equipos que precisan de una dirección IP fija
como Servidores, Routers o Firewalls y que se
configuraran manualmente de forma Estática.

Reservas
Consiste en la asignación de una dirección IP fija a una dirección MAC de un host, y se suele
asignar a aquellos host con Recursos Compartidos que precisan de su localización por los Clientes,
como Servidores de Aplicaciones, Impresoras, NAS, etc, para que siempre tengan la misma
dirección IP. De forma que cuando un host con una dirección MAC reservada solicite un alquiler al
Servidor DHCP, siempre obtendrá la misma dirección IP. (Es algo parecido a configurarlo
manualmente, pero en este caso dependiendo del Servidor DHCP para su configuración).

Tiempo de concesión (lease time)

El plazo del contrato, concesión o alquiler es el tiempo durante que un cliente DHCP
mantiene como propios los datos de configuración de Red que le otorgó el Servidor.
Cada vez que el cliente arranca, cada cierto tiempo o bien cuando se alcanza el límite de la
concesión el cliente tiene que solicitar su renovación.
Una vez vencido el tiempo, el Servidor puede renovar la información del cliente, asignarle
otra nueva o extender el plazo manteniendo la misma información.
En servidores DHCP de Windows el tiempo de concesión por defecto es de 8 días, pero en una
red con un gran número de direcciones IP disponibles y donde la configuración raramente
cambia, el administrador puede ampliar el tiempo de concesión y así reducir el tráfico derivado
de las solicitudes de renovación por parte de los clientes.

2
 Servidores DHCP
El servidor escucha por defecto en el puerto 67/UDP en DHCPv4 y 547/UDP en
DHCPv6 Los parámetros que puede configurar de forma automática:

Dirección IP
Máscara de
subred Puerta
de enlace DNS
Nombre de dominio DNS
Tiempo máximo de espera de
ARP Servidores POP3
Servidor
WINS etc
Ejemplos de Servidores DHCP
ISC DHCP (https://www.isc.org/dhcp/)
Microsoft Server 2012/2019 (https://www.microsoft.com/es-es/cloud-platform/windows-
server-comparison)
Servidores DHCP integrados en routers (IP Easy en routers CISCO
y Linksys) Distribuciones Linux (Zentyal, IPCop, pfsense, etc)

Clientes DHCP
El cliente escucha por defecto en el puerto 68/UDP.
Estos clientes vienen integrados por defecto, en los sistemas Windows /
Linux / Apple IPv4
Acción Clientes Windows Clientes Linux
Consultar dirección IP ipconfig /all ifconfig
ip add show
Liberar dirección IP concedida ipconfig /release dhclient -r
Solicitar renovación DHCP ipconfig /renew dhclient

IPv6
Acción Clientes Windows Clientes Linux
Consultar dirección IP ipconfig /all ifconfig
ip add
Liberar dirección IP concedida ipconfig /release6 dhclient -v -r -6
Solicitar renovación DHCP ipconfig /renew6 dhclient -v -6

Protocolo DHCP

Está basado en el protocolo BOOTP.

Su funcionamiento es el siguiente:
Cuando un cliente DHCP se conecta a la red envía una solicitud en forma de Broadcast o
Difusión a través de la red a la que pertenece.
Todos los servidores alcanzados por la solicitud responden al cliente con sus respectivas
propuestas. El Cliente acepta una de ellas haciéndoselo saber al Servidor elegido.
El Servidor elegido otorga la información de configuración de red previamente
gestionada por el administrador de la red junto al tiempo de concesión (lease time).
Esta información se mantiene asociada a dicho cliente mientras éste no desactive su interfaz
de red o no expire el plazo del contrato o concesión.
La renovación de la concesión de la configuración de red puede implicar una nueva configuración,
bien mantener la misma configuración o bien una extensión del plazo. Y se puede producir cuando:
o El cliente arranca
o Cada cierto tiempo o bien cuando se alcanza el límite de la concesión.

3
btener una concesión
La situación de partida, es que tenemos un Servidor DHCP configurado para ofrecer ya
información de red a los clientes y tenemos un equipo cliente configurado por DCHP.
El dialogo de paquetes que se produce para la configuración DHCP del cliente lo vemos en
el siguiente esquema:

Etapas y mensajes DHCP que se generan en el dialogo:

o Descubrimiento DHCP
(DHCPDISCOVERY). Enviado por el
cliente para detectar Servidores DHCP
o Oferta DHCP ( DHCPOFFER). Enviado
por el/los Servidor/es que reciben el
paquete anterior del cliente. Si el cliente
no recibe mensajes tipo DHCPOFFER,
expira la petición y
reenvíaunnuevomensaje
DHCPDISCOVERY.
o Solicitud DHCP ( DHCPREQUEST). El
cliente de todas las ofertas recibidas
anteriormente elige normalmente la
primera que le llega, para ello, envía
un paquete por broadcast tipo
DHCPREQUEST, poniendo el nombre
(ID) del servidor elegido. Si el servidor
al leer el paquete ve que no contiene
su dirección considera su oferta
rechazada.
o Reconocimiento positivo DHCP
(DHCPACK ) o negativo ( DHCPNAK ).
El servidor envía un paquete
DHCPACK, si la dirección IP que
le ofreció aún está disponible.
Y un paquete DHCPNAK en
caso contrario.
Si el cliente recibe el paquete DHCPACK, deberá comprobar que ésta es
válida y no está duplicada.
Si es válida, el cliente se inicializa con la configuración dada por el Servidor.
Si es inválida, el cliente envía un paquete DHCPDECLINE al Servidor y vuelve al paso 1.
El cliente puede liberar por su cuenta una concesión enviando un paquete DHCPRELEASE, bien
por ejemplo, si cambiamos el equipo de subred o bien, si la forzamos a liberarla de forma manual.
4
Otros casos:

DHCPREQUEST:
Anteriormente, hemos visto que este paquete lo envía el Cliente al Servidor para solicitar
parámetros ya enviados (con DHCPOFFER) por un servidor y declinar otras ofertas de otros
servidores, pero también se envia este tipo de mensaje para:
o Confirmar la dirección válida, por ejemplo trás reiniciar la máquina.
o Renovar el tiempo de validez de una dirección IP en particular.

Varios Servidores DHCP en una misma red

En una misma red pueden coexistir varios servidores DHCP, por ejemplo, para ofrecer
una mayor Tolerancia a Fallos y así ofrecer una Alta Disponibilidad.
Cuando elegimos esta opción los Servidores DHCP no se comunican entre ellos (1) para
establecer criterios de configuración, sino que es el Administrador de red quien configura
dichos Servidores de forma independiente y consistente, basta con ofrecer rangos de IPs
distintos en cada Servidor. Dialogo gráfico entre un cliente DHCP y varios Servidores DHCP:

(1) Existe el protocolo DHCP Failover

Protocol implementado por ejemplo en
Windows Server, que permite crear una
base de datos de peticiones común
sincronizando un mismo Rango de IPs
entre 2 Servidores DHCP distintos que
dan servicio a la misma red.
- Un servidor DHCP será designado
como primario (este otorga las
peticiones) y el otro como secundario
(actuará cuando si falla el primario).
- Este modelo también puede emplearse
como Balanceo de carga, para repartirse
el trabajo entre los 2 servidores

5
 Dar servicio a varias subredes
Hasta ahora hemos contemplado solo la posibilidad de que uno o varios Servidores
pudieran atender peticiones clientes DHCP de una única subred.

Si se dispone de varias redes interconectadas por Routers en las que se quiere configurar el
servicio DHCP tenemos 2 opciones:
o Configurar un DHCP en cada subred . Esta opción implica un aumento del trabajo administrativo
y del equipamiento necesario ya que habrá que colocar un Servidor DHCP en cada subred.

o Configurar un Servidor DHCP desde una ubicación centralizada a varias subredes .

Un servidor centralizado
Tenemos varias opciones de configuración:

Conectar el servidor directamente a las distintas redes según figura:

Que los enrutadores/routers que interconectan las redes tengan la capacidad de retransmitir
los paquetes del protocolo DHCP entre dichas redes, habilitando el encaminamiento necesario
en sus tablas de rutas.
Instalar un Agente de retransmisión ( relay agent ) DHCP en algún equipo y configurarlo para
escuchar los paquetes de difusión utilizados por el protocolo DHCP y redirigirlos a un servidor
DHCP específico, según figura:

6
 En este caso, un único Servidor DHCP está atendiendo diferentes subredes de la empresa, de
forma que cuando reciba una petición cliente identificará de qué subred proviene para poder darle
una dirección IP válida para esa subred. Si tenemos diferentes ámbitos para las distintas subredes
el servidor elegirá una dirección sin usar del ámbito que corresponda con esa subred.

Agentes de retransmisión DHCP (DHCP relay agent)

Un Relay Agent es un software que se instala en un equipo o enrutador configurado para
escuchar difusiones DHCP procedentes de clientes DHCP y, a continuación, retransmitir
dichos mensajes a los Servidores DHCP ubicados en distintas redes.

Existen 2 tipos de relay agent:

Aquellos que funcionan en Servidores. De forma que se necesita de un
Servidor que funcione como relay agent.

Aquellos que están integrados en Routers. Estos routers deberán ser adecuadamente
configurados para que retransmitan los paquetes DHCP intercambiados entre cliente
y servidor, serán los routers en este caso quienes actúen como relay agent.

7
Formato del mensaje DHCPv4 (Cabecera)

Código Operación: Indica si es Solicitud (1) o Respuesta(2)

Tipo de Hardware: Ej, Ethernet o redes IEEE 802
Longitud: De la dirección MAC
Saltos
Identificador de transacción: para relacionar peticiones y respuestas
Tiempo: tº en sg desde que se inicio el proceso
Indicador/flags: El bit más significativo de este campo se utiliza como flag de difusión

8
 DHCP v6

https://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-
solution/ whitepaper_c11-689821.html

Seguridad

La utilización de un Servidor DHCP conlleva muchas ventajas, sin embargo, al no llevar ningún
mecanismo de autentificación hace que sea vulnerable a diferentes tipos de ataques:

Suplantación del servidor DHCP (DHCP spoofing ). Servidores no autorizados podrían

proporcionar información falsa a los clientes suplantando al servidor autorizado.

Denegación de servicio . Esta técnica consiste en agotar el rango de direcciones a asignar para
así evitar que un cliente pueda obtener una configuración de red. El proceso es el siguiente, un
cliente no autorizado solicita una IP al servidor DHCP y una vez concedida cambia su dirección
MAC para pedir una nueva, y así sucesivamente hasta agotar el rango de IPs disponibles.

Hombre en medio (man in the middle) .Un cliente no autorizado puede responder a un cliente
que busca un Servidor DHCP y otorgarle una dirección IP válida, pero darle como puerta de
enlace su propia dirección IP. De esta forma, el cliente manda los paquetes al atacante.

En las LANs se pueden configurar los switches para protegerse de estos ataques mediante
DHCP snooping. Tras activar esta función, se declara de confianza el puerto por el que genera
respuestas el servidor DHCP autorizado, siendo todos los demás puertos no fiables.

2º ASIR: Servicios de Red e Internet (SERI)

Servicio de red : "DHCP"
Práctica : "ud2p1 Instalación y configuración del servicio DHCP en
Windows Server, Zentyal y pfsense"

Recursos:
- Laboratorio SERI
- Internet

Parte I: Windows Server 2012/ 2019

Para esta práctica vamos a cambiar el Direccionamiento IP Estático de las máquinas Clientes
(dC,dG,wC) para que tengan Direccionamiento IP Dinámico, para ello:
Instala y configura el servidor DHCP de la MV winServidorXX con las siguientes opciones:
Nota: Recuerda que la dirección de subred Interna, es 10.X.0.0/24, pero en el Direccionamiento IP Dinámico vamos a realizar
nuevos valores de IPs.

o El Servidor deberá ofrecer un rango de direcciones IP comprendidas entre 10.X.0.40 y

10.X.0.60 en la red 10.X.0.0/24.
o Proporcionará los siguientes parámetros a los Clientes DHCP:
o Tiempo de concesión: 10 días
o Máscara de red: 255.255.255.0
o Puerta de enlace: 10.X.0.1
o Servidor DNS: Router Aula, 213.0.88.85
o Nombre de Dominio: etgXX.com (XX=nº de tu Red Interna)
Y: Al equipo winClienteXX se le asignará siempre la dirección IP Automática 10.X.0.40 (por Reserva).
Z: Al equipo debianGraficoXX se le asignará una dirección IP dinámica.
AA: Al equipo debianClienteXX se le asignará una dirección IP dinámica.
BB: Al equipo centosXX se le asignará una dirección IP dinámica.

- Las MVs con debian a 512 MB

- MV winClienteXX con Windows 7/XP con solo 512 MB
- MV winServidorXX con Windows Servidor a 2048 MB, con 2 o más procesadores
- MV debianGraficoXX a 1024 MB.
Instalación

1. Arranca tu MV winServidorXX e inicia sesión con el usuario admin / Passetg0

IMPORTANTE: Configura las "Actualizaciones de Windows" para que NO se instalen (Inicio, Panel
de Control , Windows update, Cambiar configuración ,y selecciona "No buscar actualizaciones"
Asegurate de haber cambiado el nombre de equipo de tu MV Servidor al propuesto winServidorXX
(siendo XX el n.º de tu Laboratorio)

Una vez autentificado es

preciso que instales
el Servicio DHCP,
para ello debes ir a:

Administrador del
Servidor +
Agregar roles y
características.
(normalmente en Windows desde aquí iremos agregando los Servicios de red)

- Buscamos y marcamos el
Servidor DHCP y nos saldrá
un asistente de instalación

Lee la información mostrada

y realiza su instalación.

o Windows Server, cada vez que se instala un Servicio, crea un acceso a una Herramienta de
Administración de dicho Servicio.
o Windows Server, también dispone de una especie de una Herramienta llamada “Consola de
Administración de Microsoft” en el ingles MMC, desde donde se pueden ir centralizando todas las
herramientas de administración de Servicios desde una sola ventana, vamos a aconstumbrarnos a
trabajar desde esta ventana “mmc”, para ello escribe en Buscar: mmc y pulsa enter
Consola por defecto:

# Primero, guardala con un nombre (por ejemplo “AdminServicios.msc” y en un sitio

accesible como el Escritorio, porque casi siempre administraremos desde aquí.
# Agrega un nuevo Complemento, con el nuevo Servicio DHCP recién instalado, solo puedes
agregar los Servicios que previamente has instalado, luego esta tarea la haremos repetidas
veces. Puedes agregar algún otro componente como el Firewall, y Servicios (locales).
# Cada vez que realizas un cambio en tu Consola de Administración debes guardar /sobreescribir su info.
Configuración del Servidor DHCP en winServidorXX
-. El siguiente paso consiste en definir el ámbito DHCP, donde indicaremos el rango de IPs posibles,
especifica los siguientes parámetros:
Nombre ámbito: ambitoXX
Rango IPs: 10.X.0.40-10.X.0.60 / 24
Gateway: 10.X.0.1
Nombre Dominio: etgXX.com
o Realiza, una reserva IP en tu Servidor DHCP con la IPv4 10.X.0.40 para el equipo winClienteXX.
o Realiza un rango de Exclusión de 10.X.0.42 a 10.X.0.45, supuestamente dedicado
para Servidores con direccionamiento Estático, u otros recursos compartidos.
o Si el servidor DHCP se está instalando en un equipo que actúa como Controlador de dominio (DC)
será necesario autorizarlo.

Observa un pequeño icono verde que indica, que se encuentra en Ejecución

- Puedes revisar los ficheros log del servidor almacenados en:

%windir%\system32\dhcp Clientes DHCP y concesiones
o Antes de configurar nuestros clientes DHCP de las MV vamos a instalar el Software
Sniffer de tráfico de red “wireshark” en la MV “winClienteXX” para realizar las capturas de las
tramas de datos que se producen como consecuencia de la comunicación entre el Cliente/Servidor.

o Arranca tu equipo winClienteXX.

o Ejecuta la aplicación wireshark y pon a grabar el tráfico de tramas y configura su adaptador de red para
que reciba su configuración como Cliente DHCP. Reinicia el networking si es necesario.

o Aplica el filtro de paquetes adecuado. Ejemplo: udp.port == 67

Observa las como se capturan las 4 tipos de tramas DHCP en una 1ª concesión a un Cliente DHCP
o Aporta pantallazo de las capturas de mensajes DHCP:
# De la 1ª concesión
# Renovación de una Concesión
# Liberación de una Concesión
# Analisis de puertos UDP
o Una vez realizado, verifica su IP mediante consola con ipconfig |more . ¿Corresponde la IP con lo esperado?

o Arranca ahora tu MV debianGraficoXX y debianClienteXX, pfsenseXX y configuralos para

que reciban su direccionamiento IP mediante el Servidor DHCP.

Incluye en tu práctica el pantallazo donde se reflejen las concesiones de tus direcciones IP

otorgadas por el Servidor DHCP a tus 4 MVs, como muestra el ejemplo de la figura:

Nota:
En la configuración IP de Debian Grafico, puedes realizarlo desde su archivo
/etc/network/interfaces, como en Debian, o bien, desde su Entorno Grafico, pero NO desde los
sitios al mismo tiempo, porque puede llevar a resultados no deseados.

Comprueba la IP asignada actualmente:

ip address
Libera la asignación IP actual:
dhclient -v -r enp0s3
Solicita una nueva asignación de dirección IP:
dhclient -v
Vuelve a comprobar la IP asignada
Comprueba que tienes conexión a Internet.

o Aporta pantallazos de las asignaciones DHCP pedidas anteriores, y de las capturas de las tramas
más importantes en la comunicación DHCP entre Cliente y Servidor.
Configura el Servicio DCHP IPv6 dentro de Windows Server

Deberá ofrecer direcciones dinamicas DHCP IPv6, con las siguientes restricciones:
o Prefijo de Red: 2001:1000:acdc:id-redinterna:: con Longitud del prefijo de subred 64
o IPv6 Estatica de tu Windows Server: 2001:1000:acdc:id-redinterna::1000

o Puerta de Enlace: 2001:1000:acdc:id-redinterna::1

o Servidores DNS: 2001:1000: acdc:id-redinterna::2 y 2001:1000:acdc:id-redinterna::3
o Configura un rango de ambito DHCPv6 para los primeros 50 valores hexadecimales
o Configura una Reserva para el winCliente00 con la IPv6 2001:1000:acdc:id-redinterna::4
o Realiza las exclusiones que creas convenientes

o Aporta pantallazo de las capturas de mensajes DHCP mediante wireshark:

De la 1ª concesión
Renovación de una Concesión
Liberación de una Concesión
Análisis de puertos UDP
Observa los cambios entre DHCPv6 y DHCPv4, referidos principalmente a los tipos de mensajes, y al
modo en que envía la Solicitud el cliente al Servidor, en IPv4 mediante Broadcast y en IPv6 mediante
Multicast (con efecto broadcast).
Parte II: Zentyal
o Prepara tu infraestructura de red para trabajar ahora con la MV de Zentyal
o Instala y configura el Servidor DCHP en la MV Zentyal

Actualiza la lista
Selecciona DHCP Server
Instalar
Activar modulo DHCP
Guardar cambios.

o Realiza la siguiente configuración para los clientes DHCP:

o Rango de IPs 10.X.0.70-10.X.0.80

o Gateway : 10.X.0.1
o Nombre Dominio: etgZentyalXX.com
o DNS: 213.0.88.85, 8.8.4.4

Tests:
- Haz que tus MVs clientes:
debianClienteXX, winClienteXX, debianGrafico XX
obtengan ahora una nueva configuración IP a partir del Servidor DHCP de Zentyal.
3. Prueba las conectividades.
4. Consulta el Registro DHCP de las asignaciones DHCP realizadas por Zentyal
5. Aporta pantallazos de las configuraciones.

Parte III: Pfsense

1) Configura el Servicio DHCP con las siguientes configuraciones en la MV “pfsense”
Rango de IPs 10.X.0.100-10.X.0.120
Gateway : 10.X.0.1
DNS: 213.0.88.85, 8.8.4.4
Nombre Dominio: etgPfsenseXX.com
2) Comprueba las concesiones DHCP (leases) ofrecidas.
2º ASIR: Servicios de Red e Internet(SERI)
Servicio de red: "DHCP"
Práctica : "ud2p2 Instalación y configuración del servicio DHCP en Linux
Debian"
Recursos:
- Laboratorio SERI.
- Internet

Instalación y configuración básica de un Servidor DHCP en Linux ISC

DHCP es el servidor DHCP más utilizado en sistemas Linux.
Está disponible en los repositorios de software de las principales distribuciones de Linux.
http://www.isc.org/downloads/dhcp/
Vamos a realizar su instalación en la MV "debianServidorXX"

Parte I: DHCPv4 en Linux ISC-DHCP-SERVER

1. Instalación de ISC-DHCP-SERVER
Nota: Con las MVs de los Servidores DHCP de la práctica anterior apagados.
Vamos a instalar en la MV debianServidorXX un nuevo Servidor DHCP basado en ISC-DHCP-
SERVER
# apt-get update
# apt-get install isc-dhcp-server
Nota: Te dará fallo en la instalación final debido a que aún no está configurado
Comprueba el aviso de Error actual:
# systemctl status isc-dhcp-server.service
o bien
# service isc-dhcp-server status
Observa que el Estado Active:failed
# tail /var/log/syslog

2. Configuración
o Edita el fichero de configuración para los registros log del sistema, donde añadiremos que
guarde los logs del dhcp:
# nano /etc/rsyslog.conf
Agrega la linea:
local7.* /var/log/dhcp.log

- Edita el fichero /etc/default/isc-dhcp-server, donde le indicaremos porque Interface de red (de

las 2 que tiene) escuchará las peticiones DHCP, para ello configura:
INTERFACESv4="id-interface" id-interface=name adaptador tu Red Interna
- Y finalmente, edita el fichero de configuración de DHCP /etc/dhcp/dhcpd.conf, donde a partir de
la siguiente figura donde muestra datos de ejemplo, debes adaptar la configuración mostrada a la
pedida.
- Otros ficheros de interés

o SERVIDOR: /var/lib/dhcp/dhcpd.leases Almacena todas las concesiones

DHCP que asigna a los clientes (IP, tiempos, etc)
o CLIENTE: /var/lib/dhcp/dhclient.leases Almacena las concesiones y
renovaciones recibidas por parte del Servidor.

Nota importante:
Aconstumbrate a crear una copia de los ficheros de Configuración de Linux antes de
modificarlos. Ejemplo:
# cp /etc/dhcp/dhcpd.conf /etc/dhcp/dhcpd.conf.bak
o Edita el fichero de configuración de DHCP /etc/dhcp/dhcpd.conf, para la siguiente
configuración:
Opciones de configuración para el Servidor DHCP de Linux en debianServidorXX
Interface de escucha de peticiones: eth1
Configura al Servidor DHCP como autoritario
Rango de direcciones IP a ofrecer: 10.X.0.20 a 10.X.0.30 en la red de tu
Laboratorio 10.X.0.0/24
Con los siguientes parámetros a los Clientes DHCP o
Tiempo de concesión: 1 día
o Máximo tiempo de concesión: 8 días
o Mínimo tiempo de concesión: 1 hora
o Mascara de red 255.255.255.0
o Puerta de Enlace: 10.X.0.1
o Servidor DNS primario 192.168.X.1
o Servidor DNS secundario 213.0.88.85
o Dominio “etgDebianXX.com”
Configura una reserva, para que la MV "winClienteXX" siempre reciba la IP 10.X.0.4
Incluye en tu práctica el contenido del nuevo archivo dhcpd.conf 3.
Pruebas del Servicio ISC-DHCP-SERVER en debian Linux - Analisis de los
paquetes generados con wireshark.
- Arranca y configura adecuadamente las MVs clientes debianCliente, debianGrafico y winCliente
para que reciban ahora la configuración automática de los parámetros de red desde este nuevo
Servidor DHCP en Linux.
- Pon a grabar/capturar paquetes en tu Red Interna. -
Arranca el Servidor DHCP de tu MV debianServidor -
Comprueba el puerto UDP/67 abierto
- Comprueba que el estado del Servicio esté en ejecución (active running) - Verifica
que el proceso se está ejecutando
- Comprueba los ficheros LOG especifico del paquete y general del sistema
- Analiza los mensajes capturados en el Sniffer como consecuencia de la asignación
automática de IPs por parte del Servidor y aporta los recortes a tu práctica.
- Comprueba las conexiones clientes DHCP realizadas en el Servidor DHCP Debian.
- Comprueba la nueva configuración de Red Dinámica de tus hosts clientes incluidos la inclusión
en el nuevo dominio
Linux etgDebianXX.com (#nano /etc/resolv.conf)
- Comprueba que sigues manteniendo la conexión a Internet con la nueva configuración de red
Dinámica.
- Comprueba en los hosts linux Clientes DHCP la info de la concesion/lease:
¿Qué tiempo de renovación tiene configurado el cliente dhcp?
- Incluye en tu práctica el contenido del archivo dhcpd.leases del Servidor con las
conexiones clientes realizadas.
Parámetros más habituales isc-dhcp-server

option-routers Asigna la IP de Gateway a los Clientes

default-lease-time Informa del tiempo, en segundos, que dura el contrato asignado a la
dirección IP, a menos que el cliente solicite la renovación.
max-lease-time Como el cliente puede solicitar un tiempo de concesión, con este
parámetro se establece un límite máximo a la misma.
De esta forma se evita que un cliente DHCP solicite una concesión por
tiempo indefinido.
min-lease-time Especifica la cantidad mínima de tiempo, en segundos, que será
mantenida una asignación de direcciones.
subnet .. netmask .. { Crea un ámbito DHCP para una Subred especifica donde configurar los
[parametros] parámetros DHCP a los clientes (como gateway, broadcast, mascara
[declaraciones] subred, nombre dominio, etc)
} Ejemplo:
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.10 192.168.1.254;
option subnet-mask 255.255.255.0;
option routers 192.168.1.1;
option broadcast-address 192.168.1.255;
option domain-name-servers 8.8.8.8, 8.8.4.4;
}
host etiqueta-equipo{ Se utiliza para aplicar parámetros y declaraciones a una maquina en particular, por
[parametros] ejemplo para hacer una Reserva.
[declaraciones] Ejemplo de Reserva IP:
} host clienteReserva {
hardware-ethernet 34:43:5 4:a3:b5:c6;
fixed-address 192.168.1.9;
}
authoritative La configuración correcta para la red es la definida en el servidor DHCP. Poner
este parámetro al comienzo del archivo de configuración supone que el servidor
DHCP reasignará direcciones a los clientes mal configurados por el motivo que sea,
incluída una configuración nueva del servidor.

not authoritative La función de este parámetro es justo la contraria del anterior. Es decir: la
configuración del servidor de DHCP no es concluyente y los clientes mal
configurados que sean detectados por el servidor, seguirán con su configuración
intacta.
Parte II: DHCPv6 en Linux ISC-DHCP-SERVER

Práctica

o partir del fichero de configuración-ejemplo:

/etc/dhcp/dhcpd6.conf

Se pide realizar las siguientes configuraciones en el Servidor DHCP de

debianServidorXX para que realize asignaciones Dinámicas con DHCPv6 :

- Rango de Direcciones IPv6 Unicast Global para 50 IPs, consecutivas a partir de la

IPv6 del debianServidorXX
- Prefijo de Red: 2001:1000:acdc:XX:: /64 (siendo XX= nº tu Red Interna)
- Servidores DNS
2001:4860:4860::8888, 2001:4860:4860::8844 -
Nombre de Dominio
"etgXXDebianV6.com"
- Tiempo de Concesion por defecto: 8 dias
- Tiempo de Concesion preferido: 5 dias
- Tiempo de Renovación: 5 minutos
- Reserva una IPv6 fija para la MV winClienteXX, de valor IPV6
2001:1000:acdc:XX::44 /64
- Ejecucion del ISC DHCPv6 Server
# dhcpd -6 -cf /etc/dhcp/dhcpd6.conf -lf /var/lib/dhcp/dhcpd6.leases
- Observa bien la salida de ejecución del comando, si tienes errores debes solucionarlos -
Compueba que tienes el nuevo puerto 547/UDP para DHCPv6 abierto
- Pon a grabar tu Wireshark, realiza las capturas con desglose de capa 7 de la 1ª concesión y
Renovación
- Configura a tus clientes (dC,dG,wC) para que reciban una IPv6 del ISC-DHCP-SERVER -
Linux:
• Libero la IPv6: # dhclient -6 -v -r enp0s3
• Solicito IPv6: # dhclient -6 -v
• Consulto IPv6: # ip -6 addr
• Consulto Tabla Rutas Ipv6: # ip -6 route
Parte III: DHCP en Linux: DHCPv4 Relay Agent

En esta práctica vamos a poner en estudio y análisis el escenario de 2 dominios de Broadcast o Difusión
separados entre ellos por otro Dominio de Broadcast utilizando un único Servidor DHCP.
Para su funcionamiento debemos configurar un Agente de Retransmisión DHCP o DHCP Relay Agent
que sea capaz de reenviar las peticiones clientes DCHP (DHCPDISCOVERY) del Dominio de Broadcast alejado
hacia el Servidor DHCP de otra subred y que éste a su vez sea capaz de poder encaminar los mensajes de
respuesta (DHCPOFFER) hacia la subred del Relay Agent.
CC: Análisis con wireshark
DD: Servidor DHCP v4 en Debian Linux
EE: DHCPv4 Relay Agent en Debian Linux

Crea 3 rangos de DHCP v4

distintos uno por cada
subred

Puedes usar tu MV
"debianCliente" para instalar
aquí el DHCP Relay Agent.

# apt-get install isc-dhcp-relay

Instalación del DHCP Relay Agent

# apt-get update
# apt-get install isc-dhcp-relay
# dhcrelay <IP-Salida-Reenvio-ServidorDHCP>
Notas:
- Recuerda configurar el Enrutamiento IPv4 necesario para este Escenario para permitir que los
clientes de cada subred puedan acceder a Internet cada uno desde su propia subred. Si necesitas
agregar alguna ruta estática en las tablas de rutas averigua los comandos necesarios por Internet.
Tests
- Comprueba que los hosts clientes reciben las Ips Dinámicas esperadas del Servidor DHCP y del uso del Relay.

- Comprueba las concesiones/leases en el Servidor DHCP -

Comprueba la conectividad a Internet de los Clientes
- Comprueba la conectividad entre los 2 hosts Clientes de las diferentes Redes Internas Entrega
de documentación de la práctica:
- Contenido de los parámetros configurados en los Archivos:
/etc/dhcp/dhpcd.conf /etc/default/isc-dhcp-server
/etc/default/isc-dhcp-relay

- Tablas de Rutas de los 4 equipos y las IPs de cada adaptador enp0sX

2º ASIR / Servicios de red e Internet (SERI)

UD3. Sistema de Nombres de Dominio: DNS (Domain Name System)

Índice UD3
Características y funcionamiento
Espacio de nombres de dominio
Servidores de nombres. Zonas, tipos servidores, Servidores
raíz Qué papel o rol pueden tener los Servidores DNS
Cómo resuelve un cliente DNS (resolver) una
consulta DNS Resolución inversa
Base de Datos DNS. Tipos de registros de
recursos Transferencias de zona
Actualizaciones de DNS dinámicas
(DDNS). Protocolo DNS
Seguridad DNS

Características y funcionamiento
o Para facilitar el uso de los servicios y recursos que ofrece una red se han creado Sistemas de nombres utilizados
por Servicios de resolución de nombres que permiten asociar nombres sencillos con direcciones numéricas.

oExisten Sistemas de nombres planos y sistemas de nombres jerárquicos, mientras los sistemas planos lo
basan todo en un único fichero sin ningún tipo de estructura como es el caso del fichero hosts, los
jerárquicos utilizan organizaciones y estructuras para su administración y gestión distribuida.
Nota Ubicación del fichero hosts:
En Windows: C:\Windows\System32\drivers\etc\hots
En Linux Debian: /etc/hosts
oInicialmente, se utilizaba un modelo de fichero plano, donde residían todos los nombres de equipos
(hosts) con sus respectivas direcciones IP localizado en un servidor central. Los equipos de la red
obtenían periódicamente por FTP el archivo y así podían usar los nombres que contenía.

oEl sistema anterior funcionaba bien hasta que el incremento de los hosts que iban apareciendo en Internet
le convirtió en un sistema poco eficaz (por sobrecarga del trafico, dificultad en el mantenimiento, etc).

o El nuevo sistema jerárquico de DNS fue introducido en 1983.

oEl sistema DNS actual se basa en una Base de Datos distribuida entre múltiples equipos (servidores de
nombres) y se indexa según un esquema de nombres jerárquico (espacio de nombres de dominio). A los
servidores de nombres se les pueden realizar preguntas y para ello se usan programas (clientes DNS) que
dialogan con los servidores en base a unas reglas (protocolo DNS).

o El Servidor DNS puede almacenar varios tipos de información sobre cada nombre de dominio:
Resolución de nombres (búsqueda directa). A partir de un nombre de dominio obtengo la IP asociada
Resolución inversa de direcciones (búsqueda inversa). A partir de una IP obtengo el nombre
de dominio asociado.
Resolución de servidores de correo . Dado un nombre de dominio, por ejemplo "gmail.com", obtener
el servidor a través del cual debe realizarse la entrega del correo electrónico ("smtp.gmail.com")

oTambién se puede utilizar DNS para balanceo de carga, obtención de claves públicas, ubicación de
servidores para un servicio determinado, listas negras de spam, etc.

1
¿Con qué componentes trabaja el Servicio DNS?

Espacio de nombres de dominio (domain name space). Conjunto de nombres que se pueden utilizar
para identificar máquinas o servicios de una red.
Base de datos DNS. Distribuida y redundante que almacena la información. Se organiza en zonas que
almacenan la información en lo que se conoce como Registros de recursos (RR, Resource Records).
Servidores de nombres (o servidores DNS). Programas que guardan parte de la BD DNS (zonas) y que
responden a las peticiones clientes.
Clientes DNS (resolvers). Programas que realizan preguntas a los servidores de nombres y procesan las
respuestas. Protocolo DNS. Conjunto de normas y reglas en base a las cuales "dialogan" los clientes y los
servidores DNS. Ejemplo de Registro de Recursos (RR) de 2 zonas "asir.es; informatica.es":

¿Cómo funciona el Servicio DNS?

FF: Se basa en el modelo Cliente / Servidor.
GG: El Servidor abre por defecto el puerto 53/UDP.
HH: La transferencia de zonas entre maestro y esclavo, si se configuran, se realizan por el puerto 53/TCP.
II: Los clientes DNS (resolvers) preguntan a los Servidores de Nombres.
JJ: Los Servidores de Nombres también se comunican entre sí:
Pueden realizar preguntas a otros servidores de nombres cuando no tienen la información por la
que le han preguntado.
Pueden intercambiar información sobres sus Zonas (transferencia de zona).

2
Espacio de nombres de dominio
Es el conjunto de nombres que se pueden utilizar para identificar máquinas o servicios de una red.
Conceptos:
1. Nombres de dominio
Puede estar formado por una o varias cadenas de caracteres separadas por puntos. No distingue entre
mayúsculas y minúsculas.
Ejemplo:
- "pc01.redes.etg.es."
- "com."
- "marte.etg.es."
- "google.com."
El conjunto de nombres forman el denominado espacio de nombres de dominio que se puede representar
mediante una estructura jerárquica organizada en forma de árbol.
Todos los nombres forman un árbol donde cada nodo se separa de los otros nodos por un punto, según ejemplos:
Ejemplo 1: Ejemplo 2:

Nivel superior o TLD (Top

Level Domains)

Como consecuencia de la organización jerárquica de los nombres de dominio es posible utilizar los
términos dominio y subdominio.

2. Nombres relativos y absolutos (FQDN)

Cuando se hace referencia a un dominio usando un nombre se puede emplear su nombre relativo o
su nombre absoluto.

Nombre relativo: es necesario conocer el contexto del dominio superior para determinar a qué
nombre se hace referencia exactamente.
En el ejemplo anterior: miempresa, rioja, ventas, servidor1 serían nombres Relativos

Nombre absoluto o FQDN (Full Qualified Domain Names): nombre formado por todas las partes
separadas por puntos empezando por el nodo inferior y subiendo hasta el nodo raíz (el punto, que
aunque no se suela poner en los accesos URL internamente para el Servidor DNS si se utiliza).
En el ejemplo anterior:
servidor1.ventas.rioja.miempresa.com.

3
3. Administración de Nombres de Dominio en Internet. Delegación
La administración y organización del espacio de nombres de dominio de Internet se distribuye entre
múltiples empresas estando coordinadas por la ICANN (Internet Corporation for Assigned Names and
Numbers- Coorporación de Internet para la asignación de nombres y números). https://www.icann.org/es

- Dominio raíz y la ICANN. Es una organización sin ánimo de lucro que tiene como objetivo garantizar
que Internet sea estable, operativa y segura. Administra el dominio raíz y mantiene un registro de los
dominios de primer nivel o nivel superior / TLD existentes.
- Dominios TLD (Top level Domain) y los operadores de registro
(registry). Los dominios de nivel superior o TLD son clasificados en:
Dominios Genéricos (gTLD).
✗ uTLD- No Patrocinados. Se pueden alquilar sin restricciones. Están gestionados por
la ICANN. Ejs: ".com", ".info", ".org", ".net",..
✗ sTLD- Patrocinados: Existen limitaciones a la hora de contratar estos
dominios. Están patrocinados por diferentes instituciones.
Ejs: ".edu",".gov",".travel", ".asia", ..
Ej.: https://www.bcn.travel/
Dominios Geográficos (ccTLD-country code TLD). Creados por IANA. Existen unos 243
gestionados por los distintos gobiernos mediante organizaciones propias.
Ejs: ".es", ".fr", ".uk",”.us”, ...
arpa. Usado como infraestructura técnica de Internet. Ej. "in-addr.arpa" y "ip6.arpa" se
usan para resolución inversa de direcciones IP.
Reservados: "localhost", "test","example", "invalid".
Listado completo: https://en.wikipedia.org/wiki/List_of_Internet_top-level_domains

# Delegación. La administración descentralizada de DNS (basado en las BD distribuidas en múltiples

Servidores) se basa en la delegación. Esta consiste en la organización que administra un dominio
cede la administración de uno, varios o todos sus subdominios a otras organizaciones.
Por ejemplo, ICANN delega la administración de los TLD a determinadas organizaciones
acreditadas, por ejemplo, el dominio "es" es delegado a Red.es (http://www.red.es).

Y a su vez, por ej, red.es delega el dominio "upm.es" a la Universidad Politécnica de Madrid y
ésta a su vez delega la administración del dominio "fi.upm.es" a la Facultad de Informática.

La división de un dominio en subdominio no implica siempre ceder su delegación.

Además, si una organización delega un subdominio en otra no tiene por qué informar a "su superior".

La organización que administra un dominio es responsable de los nombre usados en ese

dominio, de las direcciones IP asociados a ellos y, del funcionamiento y mantenimiento de
nombres que almacenan esa información.

# Registro de dominios. Agentes registradores

La adquisición de un dominio en Internet se denomina registro de dominio. Para ello, el usuario o registrador
ha de contactar con la empresa registradora autorizada por ICANN y se comprueba en primer lugar que el
dominio deseado no pertenece a nadie. Una vez aceptas las condiciones, la empresa registradora contacta con
el ICANN o autorizados y realiza los trámites. De este modo en unas horas el dominio está disponible.

Registrar un dominio consiste en "reservar" o “alquilar” el nombre durante un tiempo (normalmente un año)
para poder crear subdominios y asociarlos a una IP, suelen ofrecer otros servicios como alojamiento de paginas
web, correo electronico, etc.
Estas empresas "registradoras" pueden registrar nombres de dominio de 2º nivel (por ejemplo "etg.es",
"midominio.com", …

Actividad
➢Busca distintas empresas registradoras autorizadas en España y establece una comparativa de
los servicios y precios ofrecidos.

4
Servidores de nombres / Servidores DNS
Son programas que guardan información sobre nombres de dominio y resuelven las peticiones
clientes DNS y otros servidores DNS. Almacenan por tanto, una parte de la base de datos DNS.
Ej. En Linux Bind (bind9). Actualmente versión 9.X https://www.isc.org/bind/
Windows Server. https://technet.microsoft.com/es-es/library/cc725925.aspx

Por defecto escuchan peticiones en los puertos 53/UDP.

Zonas
Los Servidores DNS mantienen información de una parte del espacio de nombres de dominio que se conoce
como zona (por ejemplo, el servidor DNS del instituto ETG almacena la información de la zona "etg.es" ).

o Cuando un servidor mantiene una zona se dice que es autorizado (authoritative) para esa zona.
o Las archivos de zonas se almacenan en ficheros de texto plano o en BD (LDAP, etc).
o El contenido del archivo de zona incluirá lo que se conoce como Registro de Recursos (RR).
o Según el tipo de información que se asocie con un nombre de dominio se utiliza un tipo de RR.
o Un RR está formado por los siguientes campos:
Propietario. Indica el nombre del dominio en que se encuentra el recurso que se define en el RR. Si
este campo aparece vacio, toma el valor del campo del registro anterior.
TTL. (time to live). Indica el tiempo de vida de este registro en la caché de un Servidor de nombres.
Es un campo opcional.
Clase. Identifica la familia de protocolos que se debe utilizar. Por ejemplo, la clase IN de Internet
(protocolos TCP/IP).
Tipo. Indica el tipo de recurso para este registro. (ver tipos mas abajo)
Datos. Es el valor que se desea asociar al campo nombre de dominio.

Ejemplo
Propietario TTL Clase Tipo Datos
wikipedia.org. 3600 IN A 91.198.174.192

5
- Los principales tipos de RR:

o "A" (Address): Se usa para traducir Nombres de servidores a su dirección IPv4

o AAAA: Idem para IPv6
o "PTR" (Pointer/indicador): O Registro inverso, funciona a la inversa del tipo "A", es decir, traduce
una IP en su Nombre de dominio.
o "CNAME" (Canonical name): Se usa para crear Nombres de servidores adicionales o alias. Suele ser
usado cuando están corriendo múltiples servicios (como FTP y HTTP) en un servidor con una sola
IP. En este caso, cada servicio tiene su propia entrada DNS (ej. ftp.dominio.com, www.dominio.com).
Se escribe primero el Alias y luego el nombre real. Ej:
www.dominio.com. IN CNAME servidor1.dominio.com.
ftp.dominio.com. IN CNAME servidor1.dominio.com.
o "NS" (Name Server): Asocia el Servidor DNS con la zona que resuelve. Ej:
; Servidor DNS del Dominio etg.es
etg.es. IN NS servidorDNS.etg.es.

o "SOA" (Start of Authorit/Autoridad de la zona): Proporciona info sobre el Servidor DNS primario
de la zona. Ejemplo:
NombreDominio IN SOA NsPrimario Admin ns Primario Opciones
etg.es. IN SOA Dns1.etg.es. admincorreo.etg.es.(3434343434; N.º de serie
14400; Actualización
300; Reintento
604800; Caducidad
7200); Valor TTL
o "MX" (Mail Exchange/Intercambio de correo): Asocia un Nombre de dominio a una lista de Servidores de Correo
para ese dominio.
Organización de los registros:
<nombreDominio><clase><tipo
RR><TTL><Datos> Actividad: Haz uso de las herramientas dig de escritorio online :

o http://www.kloth.net/services/dig.php
o De Google para averiguar info DNS de distintos dominios https://toolbox.googleapps.com/apps/dig/

6
Ejemplo:
Sea un esquema de red El fichero de zona de resolución directa del
dominio etg.es.
que se almacena en un Servidor DNS que está en el
equipo de IP 10.10.0.10 y cuyo nombre es
"dns1.etg.es."
Ejemplo, Configuración de la zona Directa en un
Servidor BIND

....
etg.es. IN NS dns1.etg.es.
dns1.etg.es. IN A 10.10.0.10
venus.etg.es. IN A 10.10.0.11
marte.etg.es. IN A 10.10.0.12
jupiter.etg.es. IN A 10.10.0.13
www.etg.es. IN CNAME venus.etg.es.
ftp.etg.es. IN CNAME marte.etg.es.
....

→ Una zona no es lo mismo que un dominio:

o Un dominio es un subárbol del espacio de nombres del dominio.

o Una zona es "una base de datos completa para un subárbol podado del espacio de dominios". Las zonas contienen
información de recursos que componen esa zona y se clasifican en RR almacenándose en un fichero de zona.
o Una zona puede decidir si delega o no alguno de sus subdominios.
oImaginemos que el Instituto "etg.es" ha delegado el subdominio "informatica.etg.es", en los
profesores del departamento de informática.
oExistirá otro Servidor DNS que sea autorizado para el nuevo dominio "informatica.etg.es" y que almacenen
el fichero de zona del dominio.
o Y planteando que otro subdominio, por ejemplo, "secretaria.etg.es" no se ha delegado.

Observa el gráfico del árbol de DNS de este ejemplo:

delegado No delegado (sin servidor DNS)

7
 Actualmente existen 13 servidores raíz especificados, con los nombres de la forma letra.root-servers.net, donde letra va desde la A a la M.
Esto no quiere decir que haya 13 servidores físicos, cada operador utiliza equipos informáticos redundantes para ofrecer un servicio fiable,
incluso si falla el hardware o el software. Además, nueve de los servidores se operan en múltiples localizaciones geográficas, utilizando
una técnica de enrutamiento de llamada anycast, proporcionando un mayor rendimiento y aún mayor tolerancia a fallos.

Anycast: es una forma de direccionamiento en la que la información es enrutada al mejor destino desde el punto de vista de la topología de la red.
Un paquete enviado a una dirección anycast es entregado a la máquina más próxima desde el punto de vista del tiempo de latenc ia.
En anycast también hay una asociación de una dirección destino a varias máquinas. La diferencia está en que se selecciona una
de estas máquinas para ser la destinataria de la información.

Consulta las siguientes direcciones para saber más:

https://www.iana.org/domains/root/servers
https://root-servers.org/
https://www.dimensis.com/num-180-los-root-server-el-arbol-de-13-raices

¿Qué es la ICANN? https://www.icann.org/es

Ejemplo: Fichero de Zona de Resolución Directa del dominio etg.es, cuyo nombre es "dns1.etg.es."

....
etg.es. IN NS dns1.etg.es.
dns1.etg.es. IN A 10.10.0.10
venus.etg.es. IN A 10.10.0.11
marte.etg.es. IN A 10.10.0.12
jupiter.etg.es. IN A 10.10.0.13
www.etg.es. IN CNAME venus.etg.es.
ftp.etg.es. IN CNAME marte.etg.es.

; subdominio informatica.etg.es. DELEGADO

informatica.etg.es. IN NS dns1.informatica.etg.es.
dns1.informatica.etg.es. IN A 10.20.0.1

; subdominio secretaria.etg.es. NO DELEGADO

pc01.secretaria.es. IN A 10.30.0.1
pc02.secretaria.es. IN A 10.30.0.2
www.secretaria.es. IN CNAME pc01.secretaria.es.
...

Ejemplo: Fichero de zona de resolución directa (Servidor BIND) "informatica.etg.es." delegado

....
informatica.etg.es. IN NS dns1.informatica.etg.es.
dns1.informatica.etg.es. IN A 10.20.0.1
pc01.informatica.etg.es. IN A 10.20.0.2
pc02.informatica.etg.es. IN A 10.20.0.3
www.informatica.etg.es. IN CNAME pc01.informatica.etg.es.
....

Para mejorar el funcionamiento del servicio, DNS permite almacenar una misma zona en varios
servidores DNS, ofreciendo así balanceo de carga, rapidez y una mayor tolerancia a fallos.
Teniendo esto en cuenta, es posible distinguir entre:
o Zonas maestras o primarias
o Zonas esclavas o secundarias

8
¿Qué papel o rol pueden tener los Servidores DNS?

Según la función que desempeñe un Servidor DNS pueden clasificarse en:

o Servidor maestro o primario
o Servidor esclavo o secundario
o Servidor cache
o Servidor reenviador (forwarder)
o Servidor solo autorizado

Un mismo servidor puede reunir distintas funciones, por ejemplo, puede simultáneamente ser Maestro
de una zona, secundario de otra zona y actuar a su vez como caché.

Servidor maestro/primario

Define una o varias zonas para las que es autorizado.

Sus ficheros de zona locales son de lectura y escritura.
Si un cliente DNS u otro Servidor DNS le pregunta por un nombre de dominio para el que es
autorizado, consultara su fichero de zona y responderá a la petición.
Si un cliente DNS u otro Servidor DNS le pregunta por un nombre de dominio para el que no es autorizado,
tendrá que buscar la información en otros Servidores DNS o responder que no conoce la respuesta.

Servidor esclavo/secundario

Define una o varias zonas para las que es autorizado.

La diferencia con un maestro es que obtiene los ficheros de zona de otro servidor autorizado para la zona
(normalmente un servidor maestro) mediante un proceso que se denomina transferencia de zona.
Los ficheros de zona son de solo lectura.
La modificación de estos archivos es realizada por el servidor maestro.
6. El funcionamiento ante las peticiones clientes es similar al de un servidor maestro.
7. Pueden existir varios servidores esclavos para una misma zona. Las
principales razones son: o Reducir y repartir la carga entre varios
servidores
o Favorecer la tolerancia a fallos (implantando al menos un Servidor primario y uno secundario
para cada zona).
o Reducir el tiempo de respuesta.
8. Lo ideal es que los Servidores DNS de una zona estén ubicados en redes y localizaciones diferentes
para evitar que un problema (fallo eléctrico, ataque de denegación de servicio) les afecte simultáneamente y
deje sin servicio de resolución a los nombres de dicha zona.

Servidor caché

3) El proceso de resolución de nombres es costoso ya que utiliza los recursos de la red y los recursos
de los equipos que ejecutan los servidores y clientes.
4) Para mejorar los tiempos de respuesta de las consultas, reducir la carga de los equipos y disminuir
el tráfico de red, los servidores de nombres pueden actuar como servidores cache.
5) Cuando un servidor DNS recibe una pregunta sobre un nombre de dominio de una zona para la que
no es autorizado, es decir, de un nombre del que no tiene info, puede preguntar (si así se ha configurado) a
otros servidores para que le den la respuesta.
6) Si el servidor actúa como cache guarda durante un tiempo (TTL, Time to live) las respuestas a las
últimas preguntas que ha realizado a otros servidores de nombres.
De forma, que cada vez que un cliente DNS u otro servidor DNS le formule una pregunta, consulta en primer
lugar en su memoria cache ahorrándose la pregunta a otros servidores si ya la había hecho anteriormente.

9
Un servidor DNS es solo cache (caching only Server) cuando:
2) No tiene autoridad sobre ningún dominio.
3) Pregunta a otros servidores para resolver las peticiones
de los clientes DNS y guarda las respuestas en cache.

Servidor No Reenviador y Reenviador (forwarder)

Cuando un servidor DNS recibe una pregunta sobre un nombre de dominio del que no dispone
información puede preguntar a otros servidores DNS.
Cabe distinguir entre 2 posibilidades:
Servidor No Reenviador. El propio Servidor DNS se encarga de procesar la consulta a diversos
servidores DNS y empezando por los servidores DNS raíz.

Ejemplo 1. Servidor No Reenviador

10
 No reenvía consultas a otro
servidor y tiene la
Recursividad activada.

Ejemplo 2. Servidor No Reenviador

11
 Servidor Reenviador. Reenvía la consulta a otro servidor DNS, que se denomina Reenviador o
Forwarder para que se encargue de resolverla.

Por tanto, un reenviador es un servidor DNS que otros servidores DNS

designan para reenviarle consultas.
Se utilizan para minimizar las consultas y el tráfico de peticiones DNS desde una
red hacia Internet (por ejemplo, si en una intranet tengo 3 servidores DNS y uno
funciona como reenviador, los otros 2 los configuro para que soliciten las
peticiones al Reenviador y éste a Internet).
Permite a los equipos locales compartir la cache DNS del reenviador
minimizando los tiempos de respuesta.

Ejemplo 1: Servidor Reenviador / Forwarder

Servidor DNS raíz "."

Servidor DNS
Actúa como reenviador
Recursividad activada Servidor DNS autorizado para ".com."

Servidor DNS autorizado

para "globomantics.com"

Servidor DNS
Reenvía consultas

12
Ejemplo 2: Servidor Reenviador / Forwarder

Servidores raíz:
https://root-servers.org/
https://www.iana.org/domains/root/servers

Ejemplos de Servidores DNS

BIND (https://www.isc.org/bind/ )
Servidor DNS de Microsoft (https://docs.microsoft.com/en-us/previous-versions/windows/it-
pro/windows-server-2003/cc772774(v=ws.10)?redirectedfrom=MSDN )
PowerDNS (https://www.powerdns.com )

Servidores DNS Públicos España

https://public-dns.info/nameserver/es.html

13
Servidor solo autorizado / autoritativo (authoritative only)
El termino autorizado se usa para describir un servidor que:
Es encargado de almacenar la info completa de la zona.
No responde a preguntas que no sean relativas a sus zonas, es decir, no pregunta a otros servidores DNS.
Esto implica que no tiene activada la recursividad, no es reenviador y no actúa como caché.
Debe haber al menos uno por zona:
Un servidor Maestro
Un servidor Esclavo son servidores autorizados para la zona en la que se han configurado.

Servidor no autorizado / no autorizativo.

Son aquellos que no almacenan los datos de una zona completa. Según la función que realizan pueden ser:
o Servidores Renviadores
o Servidores Cache

¿Cómo resuelve un cliente DNS (resolver) una consulta DNS?

Se considera que un resolver es cualquier software capaz de preguntar a un servidor DNS e interpretar sus respuestas.
Proceso de resolución del resolver:
o El resolver consulta la cache de resolución de nombres del hosts (si está configurada). Si obtiene
respuesta se la entrega a la aplicación.
o Si el nombre buscado no estaba en cache, el resolver busca en el archivo hosts local del equipo.
En windows: %SYSTEMROOT%\system32\drivers\etc\hosts
En linux/unix: /etc/hosts
o Si el nombre buscado no está en el archivo hosts, el resolver efectuará una consulta recursiva al servidor
DNS que esté configurado y le entregará la respuesta a la aplicación.

Las consultas a un servidor DNS pueden ser de 2 tipos:

o Recursivas
o Iterativas

Consultas recursivas.
Aquella en la que el servidor DNS tiene una respuesta completa o exacta.
Hay 3 posibles respuestas:
Respuesta positiva: da la info del nombre requerido. En ella se indica si es autorizada o no.
No es posible saber si el servidor que responde con autoridad es maestro o esclavo para el dominio preguntado.
Respuesta negativa: indica que el nombre no se pudo resolver (NXDOMAIN).
Una indicación de error: por ejemplo, no se puede preguntar a otros servidores por un fallo en la red.

Consultas iterativas / no recursiva.

Aquella en la que el servidor DNS puede proporcionar una respuesta parcial.
Hay 4 posibles respuestas:
o Respuesta positiva: da la info del nombre requerido. En ella se indica si es autorizada o no.
o Respuesta negativa: indica que el nombre no se pudo resolver (NXDOMAIN).
o Respuesta indicando una referencia a otros servidores, autorizados o no, a los que se puede
preguntar para resolver la petición.
o Una indicación de error.

14
Resolución recursiva.
- La solicitud de una búsqueda recursiva hace solicitudes sucesivas de la dirección IP al dominio y si no la obtiene,
hace nuevas solicitudes hasta encontrarla.
- En este modo, ante una consulta que no sabe resolver, el servidor hará una petición a otro servidor, y éste nos
proporcionará la respuesta.
- Este modo se utiliza en Servidores Internos, no en servidores públicos.
- El servidor trabaja por nosotros.
- Además, el servidor cachea la respuesta, para poder utilizarla en caso de que se repita la consulta.
Idea : Nuestro servidor DNS, al no saber la respuesta, lanza la consulta a otro Servidor DNS y éste se encarga de
resolver la IP final que será enviada a nuestro Servidor DNS (menos tráfico en Red interna).
- Caso tipico de configurar a nuestro Servidor DNS local con un Servidor Reenviador.
Si el servidor DNS está configurado con un Reenviador, el Reenviador se utiliza antes de que se utilice un Servidor Raiz.

Ejemplo: Resolución con consulta Recursiva del Servidor DNS (actuando como Reenviador)

15
Resolución no recursiva / iterativa. En este modo, el servidor nos indicará qué otro servidor (nos facilitara su
dirección IP) puede resolvernos la consulta solicitada para una zona en cuestión.
Tras ello, tendremos que realizar nuevamente la consulta a este nuevo servidor y así sucesivamente hasta conseguir la IP final.
Genera más tráfico de red interna, porque es nuestro Servidor quién relanza las iterativas consultas a los distintos servidores de
distinto nivel, al no tener configurado un Reenviador.
“Nuestro Servidor” se encargara de realizar el trabajo.
Es el modo por defecto, y el que se utiliza en los servidores públicos de Internet.
En este caso, también se cachea la consulta.
Es el funcionamiento de una consulta a un Servidor DNS Raiz para que me de la IP de otro Servidor DNS de 1º
nivel o TLD (ejemplo .es) y que una vez la sepa, nuestro Servidor haga una nueva consulta a este Servidor DNS -
TLD y asi sucesivamente. Mi servidor DNS genera trafico con el resto de servidores DNS.

Ejemplo: Resolución con consultas Iterativas del Servidor DNS (no tiene Reenviador configurado)

16
Cache y TTL
Los clientes y los servidores DNS mantienen en memoria cache, si están configurados para ello, las
respuestas a las peticiones que realizan a otros servidores.
El tiempo que guardan las respuestas en cache se llama TTL (Time To Live) y se define en los Ficheros de zona.
Se recomienda que el TTL positivo (respuestas positivas) sea guardado 1 día o más y los registros que
cambien poco de 2 a 3 semanas de TTL; y los TTL negativo de unas 3 horas.
El administrador del Servidor DNS debe priorizar entre disminuir el tráfico de red (aumentando los
TTL) o que los registros sean más coherentes (disminuyéndolos).
Recursividad y cache
Para que un servidor DNS pregunte a otros servidores cuando recibe consultas recursivas tiene que tener
activada la recursividad, que está asociada a la cache. Es decir, para que un servidor pregunte a otros y
almacene las respuestas en su cache tiene que resolver consultas recursivas.

Resolución Inversa.
Viene a resolver peticiones del tipo ¿cuál es o cuáles son los nombres de dominio asociados a la
dirección IP 120.129.32.2?
- Mapeo de direcciones IP y dominio arpa
La resolución de direcciones IP funciona igual que la resolución de nombres de dominio.
Las direcciones IP se tratan como nombres donde cada byte es un dominio que cuelga de los dominios:
ipv4: "in-addr.arpa"
ipv6: "ip6.arpa"
Cuando usamos una dirección IP para realizar una petición DNS inversa, por ejemplo:
10.12.0.3, realmente estamos preguntando por el nombre de dominio: "3.0.12.10.in-addr.arpa"

o Zonas
Los servidores deben almacenar en sus ficheros de zonas los registros de los recursos que asocien los nombres a las IP.
Pueden existir también, servidores maestros y esclavos.
Se estructuran también como estructura jerárquica en forma de árbol.
Ejemplo de Fichero de la zona de resolución inversa 0.10.10.in-addr.arpa que permite resolver las
peticiones inversas sobre direcciones IP de la red 10.10.0.0/24 (servidor BIND)
.....
0.10.10.in-addr.arpa. IN NS dns1.etg.es.
10.0.10.10.in-addr.arpa. IN PTR dns1.etg.es.
11.0.10.10.in-addr.arpa. IN PTR venus.etg.es.
12.0.10.10.in-addr.arpa. IN PTR marte.etg.es.
13.0.10.10.in-addr.arpa. IN PTR jupiter.etg.es.
.....

17
Puedes consultar los tipos de RR existentes en:
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml

Base de datos DNS: Tipos de Registros de recursos (RR)

SOA
Ejemplo de Registro "SOA" (Start of authority). Define una serie de opciones generales de la zona.
etg.es. IN SOA dns1.etg.es. admin.etg.es.(
1 ; nº de serie
604800 ; tº refresco
86400 ; tº reintento
2419200 ; tº expiracion
604800 ) ; TTL negativo

MNAME Nombre FQDN del servidor de nombres maestro del dominio

Ej: dns1.etg.es.
Contacto Correo de la persona responsable del dominio. (la @ es reemplazada por un ".")
Ej: admin.etg.es
Serial Versión del Fichero de zona. Debe ser incrementado cada vez que el fichero se modifique. Para que
los servidores esclavos sepan si el maestro ha cambiado.
Ej: formato fecha aaaammdd y agregarle 2 digitos más para los cambios del mismo día
Ej: 2018110501
Actualización Tiempo que esperan los servidores esclavos para preguntar al maestro si hay cambios en la zona.
(refresh) Recomendado entre 1200 y 43200 sg (12 horas)
Reintentos Si la transferencia de zona ha fallado, indica el tiempo que espera el servidor esclavo antes de
(retry) volver a intentarlo.
Caducidad Tiempo que el servidor esclavo puede estar intentando contactar con el maestro para ver si hay
(expire) cambios en la zona.
TTL negativo Tiempo mínimo que se almacenan las respuestas negativas sobre la zona

NS
Name Server, permite establecer el/los servidores de nombres autorizados en una zona.
etg.es. IN NS dns1.etg.es. ; Servidor DNS maestro
etg.es. IN NS dns2.etg.es. ; Servidor DNS esclavo
etg.es. IN NS dns.etg.org. ; Servidor DNS esclavo
.....
A
(Address) Establece una correspondencia entre un nombre de dominio completamente cualificado (FQDN) y una IPv4

AAAA
Establece una correspondencia entre un nombre de dominio completamente cualificado (FQDN) y una IPv6
CNAME
Permite crear un alias para nombres de dominios especificados en registros A y AAAA
Hay que tener en cuenta que el uso de muchos CNAME perjudica el rendimiento de los servidores DNS.
Cuando se pregunta por un alias hay que buscar 2 veces en el fichero de zona para dar la respuesta final.
MX
(Mail Exchange) Permite definir equipos encargados de la entrega de correo en el dominio. Son
consultados por los agentes de transporte de correo SMTP (MTA, Mail Transport Agent). Ejemplo:

etg.es. IN MX 10 mail1.etg.es.
etg.es. IN MX 20 mail2.etg.es.

mail1.etg.es. IN A 191.100.120.221
mail2.etg.es. IN A 191.100.120.222
18
Es posible definir varios registros MX para un mismo dominio, es decir, varios servidores de correo para
ese dominio. En cada registro se especifica un nº positivo (0 65535) que determina la preferencia en el
caso de que existan varios registros MX.
Un nº menor indica mayor preferencia.

SRV
(Services Record) Permite definir equipos que soportan un servicio en particular.
Ejemplo:
_http._tcp.etg.es. IN SRV 0 5 80 www.etg.es.
_ldap._tcp.etg.es. IN SRV 0 0 389 ldap.etg.es.

Windows usa los SRV en los servidores DNS de un dominio para identificar los controladores de dominio
(DC), servidores Kerberos, servidores web, servidores de correo, etc.

PTR
(Pointer Record) Establece una correspondencia entre nombres de direcciones IPV4 e IPV6 y nombres de dominio.
Se utilizan tanto en las zonas de resolución directa como inversa.
Ejemplo:
225.120.100.191.in-addr.arpa IN PTR ns1.etg.es.
226.120.100.191.in-addr.arpa IN PTR ns2.etg.es.

Transferencias de zona
Al proceso por el cual los servidores DNS que declaran zonas esclavas o secundarias obtienen los ficheros
de zona (los registros RR) de otros servidores DNS autorizados para esas zonas, se le denomina transferencia de
zona. Existen diversas formas de llevarlo a cabo y es posible configurarlo en los servidores DNS.
El objetivo es que todos los servidores autorizados para una zona tengan la misma información.
Los servidores maestros usan el puerto 53 / TCP para el intercambio de datos en las transferencias de zonas.

Tipos de transferencias de zona

• T. de zona completas (AXFR). El servidor maestro le envía al esclavo todos los datos de la zona.
• T. de zona incrementales (IXFR) . Si el fichero de zona tiene muchos registros, la transferencia de
zona completa pueden consumir mucho ancho de banda. En una T. incremental, el servidor maestro
le envía al esclavo solo los datos que han cambiado desde la última transferencia de zona realizada.

¿Cómo se realiza el proceso de la transferencia de zona?

Se puede iniciar de 2 maneras:
- El servidor esclavo pregunta al maestro para comprobar si hay cambios en los ficheros de zona.
Lo hace cuando se inicia por primera vez y posteriormente, cada cierto tiempo de forma periódica
(especificado en el campo refresh del registro SOA.
- El servidor maestro notifica (NOTIFY) al esclavo/s que se han producido cambios en sus ficheros de zona.
Cuando se actualiza un fichero de zona el servidor maestro envía un mensaje de notificación NOTIFY a los esclavos.
- Lo ideal es que los Servidores DNS de una zona estén ubicados en redes y localizaciones diferentes para
evitar que un problema (por ejemplo, un fallo eléctrico o un ataque de DoS) les afecte simultaneamente y
deje sin servicio de resolución a los nombres de dicha zona.

19
Ejemplo de IPv6
Zona directa
….
www IN A 192.168.0.3
mail IN A 192.168.0.32
www IN AAAA 2001:db8::3
mail IN AAAA 2001:db8::32
….

Zona Inversa

@ IN NS zona.com.
6.d.f.b.9.5.e.f.f.f.7.2.0.0.2.0 IN PTR host1.zona.com.
6.7.e.4.5.4.e.f.f.f.0.d.f.1.2.0 IN PTR host2.zona.com.

- Fichero de zona IPv6 Inversa

Ejemplo para una direccion de red IPv6: f.e.c.0.0.0.0.0.0.0.0.0.a.9.8.7 (fec0:0:0:a987)
Su definición de zona será:
zone "7.8.9.a.0.0.0.0.0.0.0.0.0.c.e.f.ip6.arpa" {
type master;
file "/etc/bind/db.zonav6";
};

En el archivo /etc/bind/named.conf.options debemos incluir la clausula:

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

20
Actualizaciones dinámicas: DNS Dinámico (DDNS, Dynamic DNS)

Para que los usuarios tengan acceso a los recursos DNS correctamente, es fundamental que los
servidores DNS estén actualizados.
La actualización de los registros de recursos RR de un fichero de zona se pueden hacer manualmente o dinámicamente.

➔ Actualizaciones manuales. En este caso el administrador crea, modifica o elimina los registros de los
recursos del fichero de zona.
Cuando el volumen de actualizaciones de los ficheros de zona es elevado y hay varias zonas o cuando
en una red se asignan direcciones IP mediante DHCP y se quieren registrar dichos nombres DNS de los
clientes DHCP, el trabajo del administrador y las probabilidades de equivocarse y no mantener
actualizados los ficheros de zona crece considerablemente.

➔ Actualizaciones dinámicas. Proceso por el cual mediante una fuente externa (clientes DNS, servidor
DHCP) puede actualizar los registros de recursos RR de una zona sin que el administrador del servidor
DNS tenga que editar dichos ficheros manualmente.

Observa el siguiente esquema del proceso DDNS:

Para que las actualizaciones dinámicas puedan ser realizadas:

Directamente por los equipos:
Hay que configurar el cliente DNS de cada equipo
Hay que configurar el servidor DNS para que permita actualizaciones dinámicas por
parte de los equipos.
Por servidores DHCP
Hay que configurar adecuadamente el servidor DHCP.
Hay que configurar los clientes DHCP para que envíen su nombre al servidor DHCP
o configurar el servidor DHCP para que les asigne un nombre.
Hay que configurar el servidor DNS para que permita actualizaciones dinámicas por
parte del servidor DHCP.
Las actualizaciones dinámicas son muy útiles para reducir la carga de trabajo que impone el
mantenimiento de una zona estática pero habilitarlas en un servidor DNS supone un riesgo
para la seguridad. Ya que si una fuente externa no autorizada consigue enviar
actualizaciones dinámicas al servidor sus ficheros de zona serán "envenenados". Luego
conlleva incluir mecanismos para asegurar que las actualizaciones solo puedan ser realizadas
por fuentes autorizadas.

21
DNS Dinámico en Internet.

Los proveedores de acceso a Internet (ISP, Internet Services Provider) asignan una dirección IP por
DHCP al router que nos conecta a su red ( a no ser que contratemos una dirección IP fija).
La dirección IP puede cambiar cada cierto tiempo o cada vez que se apaga o enciente el Router, por lo tanto,
no tenemos el control sobre ella.
¿Qué ocurre si queremos asignar un nombre de dominio asociado a la IP del Router para ofrecer Servicios,
por ejemplo, un servidor web en nuestra red?
¿Qué IP le asociamos a nuestro nombre de dominio?, la que tengamos en el momento actual, ¿Y si cambia?

Existen webs que ofrecen servicios DNS Dinámico en Internet. Permiten registrar un nombre DNS y
actualizar su dirección IP "en tiempo real".
Lo habitual es configurar un programa en el Router de conexión a Internet o en un equipo de la
red para que actualice el servidor DNS cuando la IP asignada por DHCP cambie.
Los routers que se comercializan actualmente suelen integrar estos programas.

Algunas webs que ofrecen servicios de DDNS en Internet son:

NO-IP https://www.noip.com/ (Servicio Gratuito)

DynDNS https://dyn.com/ (Servicio Pago)
FreeDNS Servicio Gratuito)
EasyDNS (Servicio de Pago)
ZoneEdit (Servicio Gratuito)
NameCheap (Servicio Gratuito)
ChangeIP (Servicio Gratuito)
Dyns.cx (Servicio Gratuito)
Don Dominio (Servicio Gratuito)

Configuración DDNS en un Router ADSL

22
Protocolo DNS

Determina las reglas de los diálogos entre los clientes y los servidores DNS.
El formato de un mensaje DNS es el mostrado en la siguiente figura:

Header: Indica cuales son las secciones

presentes, tipo de mensaje y otros
campos

Question: Campos que definen una

consulta a un servidor de nombres

Answer: RRs que responden a la consulta

Authority: RRs que apuntan a los

servidores de nombre autoritativos.

Additional: RRs que contienen

información adicional.

RR- Registro de Recursos

Los mensajes de consulta entre clientes y servidores de DNS tienen un formato establecido.
Este formato es el siguiente:

IDENTIFICACIÓN PARÁMETROS
Nº DE SOLICITUDES Nº DE RESPUESTAS
Nº DE AUTORIDAD Nº DE REGISTROS ADICIONALES
Consulta/s (sección de solicitudes)
• de respuestas (sección de respuestas)
RR de autoridad (sección de respuestas)
RR con información adicional (sección de respuestas)

23
Seguridad DNS
DNS ha sufrido muchos tipos de ataques y se han publicado múltiples vulnerabilidades.
Además, la información que se puede obtener de los servidores DNS de una organización se puede utilizar
como punto de partida para otros tipos de ataques.
Amenazas
Servidores DNS
Ataques contra el propio servidor aprovechando vulnerabilidades (uso de exploits)
Ataques de denegación de servicio (DoS)
Modificación de los archivos de zona.
Consultas de clientes DNS a otros servidores DNS
Envenenamiento de la cache del cliente DNS suplantando al servidor DNS remoto y enviando registros
incorrectos.
Consultas de servidores DNS a otros servidores DNS
Envenenamiento de la cache del cliente DNS suplantando al servidor DNS remoto y enviando registros
incorrectos.
Transferencias de zona.
Suplantación del servidor maestro que envía registros de recursos a los
esclavos. Actualizaciones dinámicas a servidores DNS.
Suplantación de la fuente externa que envía las actualizaciones al servidor DNS.

Mecanismos de seguridad
Las vulnerabilidades y amenazas a DNS están relativamente controladas
Seguridad local en los servidores DNS
Actualizar a las últimas versiones y parches de seguridad
En sistemas Linux ejecutar el servidor en un entorno chroot.
Configurar adecuadamente los privilegios de acceso a los ficheros de zonas.
Realizar copias de seguridad de los archivos de zona.
Evitar puntos de fallo y prevenir ataques DoS creando al menos un servidor secundario por
cada zona, distribuyendo los servidores DNS en diferentes redes y ubicaciones, etc.
Seguridad en las Transferencias de Zona y actualizaciones dinámicas.
Utilizar Cortafuegos para controlar las solicitudes de transferencia de zona y/o actualizaciones dinamicas.
Mecanimsos TSIG y TKEY que proporcione autenticacion entre servidores

24

UD3 El Servidor DNS

ud3p1. Práctica "Servicio DNS en Windows Server con función Cache, Reenviador, Maestro "

Recursos:
Laboratorio del aula
Objetivos:
Parte I:
Instalar y configurar un Servidor DNS en Windows Server para que actúe como solo Caché y responda a consultas recursivas.
Posteriormente, lo configuraremos para que reenvíe las consultas recursivas a un 2º Servidor DNS liberando de tráfico a la red virtual.
Parte II:
Creación de una Zona "etgXX.es" como "autorizado" y función de Servidor Maestro para el Servidor DNS de
Windows Server instalado en la Parte I para las búsquedas de Resolución directa e inversa. Entrega:

nombre práctica: "ud3p2 NombreApellidos"

Aporta pantallazos de los procesos realizados en tu documentación
Parte I
- Instalación
Para la instalación del Servidor DNS debemos decidir si queremos instalarlo como Servidor DNS Local o
integrarlo con el Servicio de Nombres del Directorio Activo de Windows Server (AD DS). En este último
caso, la instalación del Servidor DNS se realiza al mismo tiempo que la instalación del Directorio Activo, lo
que significa que dicho equipo lo convertiremos en un Controlador de Dominio (DC) de nuestro Dominio.
Para esta práctica, instalaremos el Servidor DNS como servidor local sin la instalación del Directorio Activo.
Inicia sesión en la MV "WinServidorXX" con el usuario administrador
Ejecuta la herramienta "Administrador del Servidor"
Desde la configuración del Servidor local seleccionando Agregar Roles y características y Siguiente.
Selecciona la función Servidor DNS y siguiente.

1
Observa y lee atentamente la siguiente información que nos muestra

o Trás completar la instalación, en el menú Inicio, Herramientas Administrativas se ha creado la

entrada DNS que permite acceder a la consola de administración del Servidor. Agrega en tu
Consola de Administración MMC el complemento DNS (ya tenias el DHCP) y abre tu consola.

o Introducimos la contraseña para el Modo de restauración de servicios de directorio (Pa$$w0rd)

o Abre un terminal, ejecuta el comando netstat -ano y comprueba que el servidor escucha en el
puerto 53. netstat -ano |find "53" |find "LISTENING"

2
 Puertos de red usados por DNS

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-
and-2008/ dd197515(v=ws.10)?redirectedfrom=MSDN

Ahora debemos configurar en el resolver de esta MV que el 1º Servidor DNS es la propia maquina.
(127.0.0.1).
Configura todos tus equipos Clientes con el direccinamiento IP estático del final de la práctica ud1p1.
Configura la Dirección IP Estática de tu MV Windows Server : 10.X.0.5/24

KK:Configuración del Servidor como solo Caché

Por defecto, el servidor está configurado como solo cache (no es autorizado de ninguna zona) que
responde a consultas recursivas (tiene la recursividad activada).
2.1 Comprueba que el servidor resuelve nombres de dominio de Internet configurando el cliente DNS para que utilice
el servidor DNS instalado en la máquina local (127.0.0.1) y usa el comando nslookup para resolver un
nombre, por ejemplo www.google.es.
1.1. Para que el servidor pueda iniciar consultas recursivas tiene que conocer cuáles son los
servidores DNS raíz, que en terminología de Microsoft se denominan Sugerencias de raíz de la
zona derecha. Observa los servidores raíz y su dirección IP.

Direcciones IP de los
Servidores DNS Raíz o
Sugerencias de raíz
predeterminados en
Windows Server

Estas Sugerencias de raiz,

solo se utilizaran en el caso
que no tengamos ningún
Reenviador configurado

3
 1.2. Inicia sesión en debianClienteXX como root.
1.3. Configura el resolver para que utilice como Servidor DNS el instalado en el Windows Server WinServidorXX
(10.XX.0.5)
1.4. Usa el comando nslookup www.google.es y comprueba que el Servidor DNS de Windows
es quien resuelve.

1.5. Usa el comando dig para preguntar por un nombre de dominio diferente al usado en el punto 1.4.
Comprueba el tiempo de respuesta.
1.6. Vuelve a usar el comando dig para preguntar por el mismo nombre de dominio. Comprueba que
el tiempo de respuesta es mucho menor porque el servidor ha consultado su cache.
1.7. Ejecuta sucesivas veces el mismo comando y observa como el campo TTL de los registros de
recursos de la respuesta decrementa.
1.8. Desde la MV WinServidorXX, accede a la consola de administración del DNS.
1.9. Activa la vista avanzada en el menu Ver, Avanzada.
1.10. En la parte izquierda de la ventana aparece una entrada que permite consultar la cache
del Servidor. Busca los nombres de dominio por los que has estado preguntado y observa que,
como consecuencia de la resolución de consultas recursivas, hay más información.
Ejemplo:

1.11. Borra la caché del Servidor DNS. Botón derecho sobre el equipo y “Borrar cache”,
repite los comandos de dig y comprueba que los tiempos de consulta vuelven a aumentar con
la primera Resolución y cuando la cachea los tiempos vuelven de nuevo a disminuir.

- Configuración del servidor para que reenvíe consultas a Reenviadores (forwarders)

Accede a la consola de administración DNS
Botón derecho sobre el Servidor DNS "WINSERVIDORXX"+ Reenviadores.
Haz clic en editar y añade el servidor DNS de Google. Según figura:

4
 Inicia la MV "debianGraficoXX" e inicia una captura de Wireshark en modo promiscuo.
Desde la MV "debianClienteXX" ejecuta el comando:
nslookup www.tiernoparla.es
Para la captura desde Wireshark y analiza el tráfico DNS capturado.
Repite el proceso con el mismo dominio (una vez que ya tenemos su información en caché) y
observa ahora las tramas capturadas para resolver la petición cliente DNS.
Análisis y comparativa del tráfico de captura de paquetes DNS ante las siguientes situaciones:
Resolución de una petición DNS ya existente en cache del Servidor DNS con reenviador.
Resolución de una petición DNS ya existente en cache del Servidor DNS sin reenviador.
Resolución de una petición DNS no existente en cache del Servidor DNS y sin configuración de Reenviador
Resolución de una petición DNS no existente en cache del Servidor DNS y con configuración de Reenviador 4.1
¿En qué caso/s se producen menos paquetes de intercambio DNS en tu Red Interna para resolver una consulta
DNS?
4.2 ¿Y en qué caso se produce más paquetes de datos DNS en tu Red Interna?

Parte II:

Vamos a configurar el servidor DNS de Windows como Servidor Maestro

- El Servidor DNS solo servirá a nuestra Red Interna, es decir, será un Servidor DNS local.
- Actuará como Maestro y tendrá autoridad sobre la Zona de Resolución Directa
etgXX.es; Con las siguientes restricciones:
o Crearemos una Zona con el nombre etgXX.es
Nota: Recuerda que XX debe hacer corresponder con el 2º byte de tu Red Interna
# No se permitirán actualizaciones dinámicas.
# El servidor DNS maestro del dominio será
(registro NS): winservidorXX.etgXX.es
# Los nombres de los equipos serán los representados en el esquema de la Red Interna (registros
A), es decir: debianClienteXX, debianGraficoXX,winClienteXX, debianServidorXX
# Se configurarán los siguientes alias (registros CNAME):
ns1.etgXX.es será un alias de winservidorXX.etgXX.es

5
 www.etgXX.es será un alias de debianClienteXX.etgXX.es
ftp.etgXX.es será un alias de winservidorXX.etgXX.es
mail.etgXX.es será un alias de debianGraficoXX.etgXX.es
El equipo debianClienteXX.etgXX.es actuará como Servidor de Correo de dominio (registro MX).
Representa mediante un grafo tu árbol de zona.
El tiempo en cache TTL de las respuestas negativas de la zona será de 3 horas.
o Actuará como Maestro y tendrá autoridad sobre la Zona de Resolución Inversa de la red 10.XX.0.0/24
• No se permitirán actualizaciones dinámicas.
• El servidor DNS maestro del dominio será winservidorXX.etgXX.es (registro NS)
• Las direcciones IP de los equipos se corresponderán con las representadas en el esquema
de direccionamiento estático del Laboratorio de la Red Interna (registros PTR).
• El tiempo en cache TTL de las respuestas negativas de la zona será de 3 horas.

Configura los equipos de tu Red Interna para que usen todos el Servidor DNS configurado en tu
Windows Server y añadan el sufijo etgXX.es a los nombres de dominio no FQDN.

1. Configuración del sufijo DNS del equipo (necesario al no trabajar con Dominios)
Desde el equipo “winservidorXX” sitúate en las Propiedades de tu Equipo y en la “Configuración avanzada
del sistema” pulsa en “Mas” y añádele e introduce el nombre de tu zona “etgXX.es”. Reinicia el equipo

Observa, dejar habilitado que se

cambie el sufijo DNS principal cuando
este equipo pertenezca a un Dominio.

o Configuración de la Zona de Resolución Directa.

2.1. Accede a tu consola MMC y en el nodo de DNS, haz clic con el botón derecho y selecciona Zona nueva.
2.2. Lee la info del asistente y pulsa Siguiente.
2.3. Selecciona Zona principal y Siguiente
2.4. Introduce como nombre de Zona “etgXX.es” y Siguiente.
2.5. Deja habilitado la opción Crear un Fichero de Zona con este nombre y mantén el nombre
que sugiere el asistente. Siguiente.
2.6. Recuerda las restricciones de configuración de la Zona Resolución Directa y configúralas

6
2.7. Observa que se ha creado una entrada en “Zonas de búsqueda directa” con el nombre de tu zona

2.8. Pincha sobre el nombre de la Zona y observa en la zona central de la consola los Registros de
Recursos (RR) del Fichero de zona que se han creado automáticamente: SOA y NS

2.9. Haz doble clic sobre el registro SOA y observa sus propiedades . Configura el TTL negativo
con el valor pedido.

Recuerda que:
El tiempo que guardan las respuestas en cache se llama TTL
(Time To Live) y se define en los Ficheros de zona.
Se recomienda que el TTL positivo (respuestas positivas) sea
guardado 1 día o más y los registros que cambien poco de 2 a 3
semanas de TTL; y los TTL negativo de unas 3 horas.

TTL para Respuestas negativas, es decir, respuestas para

consultas a nombres que no existen.

2.10. Haz ahora doble clic sobre el Registro NS y observa sus propiedades. Fíjate que el campo de
la dirección IP aparece como desconocido. Debido a que aún no hemos creado el Registro A
correspondiente a ese equipo “winservidorXX.etgXX.es”
2.11. Crear los registros A necesarios para los nombres de todos tus equipos de tu Red Interna,
incluye para la práctica también tu "debianServidorXX":
o Sobre la zona “etgXX.es” haz clic con el botón
derecho del ratón y selecciona Host Nuevo (A)
o Configura su Nombre y la IP estática que tenga.
Si tuviéramos la Resolución Inversa activa podríamos
marcar el Registro PTR asociado.

2.12. Crea los Registros CNAME para los alias pedidos en la Resolución
Directa. Para mayor seguridad en su configuración asegúrate de buscar/Examinar el nombre del
Host destino dentro de tu Zona de Resolución Directa a través de los Registros A ya creados.

2.13. Crea el Registro MX para definir un Servidor de Correo para tu zona.

o Sobre la zona "etgXX.es" haz clic con el botón derecho del ratón y selecciona Nuevo
intercambio de correo (MX)
o Deja en blanco el campo Host o dominio secundario e introduce el nombre del servidor
de correo pedido. Deja 10 como prioridad.
2.14. Observa la figura y aporta el mismo pantallazo pero de tu configuración de Zona etgXX.es de
tu Red Interna con tus hostname.

7
 2.15. Comprobaciones. Realiza las configuraciones necesarias en tus equipos clientes incluido
el debianServidorXX para que tengan tu nuevo Servidor DNS de Windows Server. Y realiza las
comprobaciones de resolución DNS en un equipo mediante el comando nslookup al dominio que
tú quieras. Realiza la operación 2 veces al mismo dominio para observar lo rápido que realiza la
resolución una vez que tu Servidor DNS incorpora dichos registros. Comprueba que, por
supuesto, es la IP de tu Servidor DNS quien resuelve en dichas consultas.

2.16. Comprobaciones de los Registros de Zona de tu Fichero. Realiza las siguientes

comprobaciones desde un cliente DNS (ejemplo tu "debianClienteXX) de tu Red Interna
configurado adecuadamente. Comprueba que resuelve adecuadamente.
nslookup www.etgXX.es
nslookup ftp.etgXX.es
nslookup mail.etgXX.es
nslookup ns1.etgXX.es
nslookup debianGraficoXX.etgXX.es
etc.…

o Observa en las siguientes figuras el mensaje cuando aparece o no "Non-authoritative answer".

Dependiendo de si el equipo del nombre que pedimos resolver nuestro Servidor DNS es o no
autorizado para esa Zona (si lo es para los host de nuestra Red Interna gracias a los
Registros y no lo será para el resto)

2.17 Comprueba ahora que responde tambien a las consultas de los nombres Relativos (NO FQDN).
Tests:
nslookup www
nslookup debianGrafico00
dig debianServidor00
etc ….

8
9
 o Configuración de la Zona de Resolución Inversa
3.1. Desde tu Servidor DNS de Windows accede a la administración del DNS y sobre Zonas de
búsqueda inversa haz clic con el botón derecho del ratón y selecciona Zona nueva de tipo
principal con el identificador de tu Red Interna 10.XX.0 .
Observa el Nombre de la zona de búsqueda inversa que determina el asistente.
Conserva el nombre del Fichero propuesto.
No admitas actualizaciones dinámicas en la zona.
3.2. Observa desde el panel de administración DNS la ejecución de tu nueva Zona de
resolución inversa "0.XX.10.in-addr.arpa"

3.3. Haz clic en tu Zona de Resolución Inversa y observa los Registros de Recursos (RR) creados
automáticamente (SOA, NS). Configura el TTL negativo o mínimo en 3 horas.
3.4. Haz doble clic sobre el registro NS y observa sus propiedades. Observa como en el campo de la IP del nombre
del dominio del equipo si aparece su dirección IP ya que se creó un RR "A" en la resolución directa.
3.5. Crea los registros PTR para los nombres de los equipos de la Red Interna. Sobre la zona
0.XX.10.in-addr.arpa haz clic con el botón derecho del ratón y selecciona Nuevo puntero (PTR).

3.6. Comprobaciones. Desde un equipo de tu Red interna (ej., debianCliente) comprueba que tu Servidor
DNS resuelve también ahora todas las consultas Inversas sobre los hosts de tu Zona creada.
Ejemplo:

Observa que no aparece el mensaje de "no autorizado" para

la resolución de esta consulta porque lo resuelve
directamente tras la consulta de su Fichero de Zona.

Comprueba una resolución inversa externa (no autorizada para nuestro Servidor DNS) y observa su mensaje.

UD3 El Servidor DNS

ud3p2. Práctica "Servicio DNS BIND9 en Linux Debian. Caché,
Reenviador, Maestro” Zonas de Resolución Directa e Inversa
Recursos:
Laboratorio del aula
Objetivos:
Instalar y configurar un Servidor DNS BIND9 (http://bind9.net/) en Linux Debian para que ver los principales usos de éste como caché y
como Servidor Maestro de una Zona directa e inversa.
Entrega:
nombre práctica: "ud3p2 NombreApellidos"
Aporta pantallazos de los procesos realizados en tu documentación

El servidor DNS BIND9, al igual que el de Microsoft Windows, admite distintos modos de funcionamiento:
Servidor caché DNS

Servidor DNS maestro

Servidor DNS esclavo

Parte 1: Servicio DNS en Linux Debian con función de solo Cache

Vamos a instalar el Servidor DNS BIND en el host debianClienteXX para que actúe como solo caché
y responda a consultas recursivas.
Posteriormente, le configuraremos para que reenvíe las consultas recursivas a otro Servidor DNS.
El servidor DNS BIND es el más utilizado en Internet.
Instalación
LL: Inicia tu host debianClienteXX e instala el servicio BIND
apt-get update
apt-get install bind9
MM:Comprueba que el servidor BIND se ha iniciado al terminar su instalación, sino inicialo.
Consulta ahora el nombre del demonio "named" que es el que controla su ejecución.
ps -ef | grep named
Consulta la versión de BIND instalado
# dpkg -l bind9
 - Comprueba que el Servidor DNS está escuchando en los puertos 53/udp y 53/tcp

- En Debian, los archivos de configuración de Bind se almacenan en

/etc/bind. Y los principales archivos de configuración son:
/etc/bind/named.conf
Fichero de configuración principal
No se suele modificar
Almacena la configuración de las diferentes Zonas generadas
por defecto en el momento de la instalación.
Incluye los ficheros (referenciados con la directiva include)
/etc/bind/named.conf.options
/etc/bind/named.conf.local
/etc/bind/named.conf.default-zones

/etc/bind/named.conf.options
- Fichero de configuración de opciones generales del Servidor

/etc/bind/named.conf.local
- Fichero de configuración de Zonas
- Se declaran las zonas de Resolución Directa e Inversa del Servidor.

/etc/bind/named.conf.default-zones
- Contienen la declaración de las zonas por defecto que tiene creadas BIND.

/var/log/daemon.log
/var/log/syslog
- Ficheros donde se almacenan información del sistema en tiempo de ejecución. Útil para detectar errores.

Ficheros de zonas
# Ficheros que definen los registros de recursos de cada zona.
# Son referenciados desde las declaraciones de zonas en /etc/bind/named.conf.local
# Al instalar el servidor DNS se crean un conjunto de archivos de zonas por
defecto referenciados desde /etc/bind/named.conf.defaults-zones, estos ficheros
son:
/etc/bind/db.root: Servidores raíz (versiones anteriores a Debian 10)
/usr/share/dns/root.hints: Servidores raíz (Debian 10)
/etc/bind/db.local: Resolución directa del bucle local
/etc/bind/db.127: Resolución inversa del bucle local
/etc/bind/db.0: Resolución inversa del broadcast
/etc/bind/db.255: Resolución inversa del broadcast
o Realiza una copia de seguridad de los archivos de configuración (named.conf.options y named.conf.local)

Configuración del Servidor DNS como solo caché

Por defecto, el servidor está configurado como solo cache (no es autorizado para ninguna zona) que
responde a consultas recursivas (tiene la recursividad activada).
# Verifica que tu Servidor DNS BIND resuelve nombres de dominio de Internet configurando el cliente
DNS para que utilice el servidor DNS instalado en la máquina local (127.0.0.1) y usa el comando
nslookup para resolver un nombre.

o Para que el servidor pueda iniciar consultas recursivas tiene que conocer cuáles son los servidores
DNS raíz. Consulta el fichero /usr/share/dns/root.hints y observa los servidores raíz y su dirección IP.
 Realiza la captura de paquetes mediante Wireshark durante la ejecución las resoluciones DNS y
analiza el tráfico capturado.
Inicia sesión en debianGrafico y configura el resolver para que use como servidor DNS el
instalado en debianCliente.
Usa el comando dig para resolver un nombre de dominio diferente al usado en el
punto 1. Comprueba el tiempo de respuesta.

Vuelve a repetir el paso 4 con el mismo nombre de dominio.

Comprueba el tiempo de respuesta y observa que el tiempo es mucho menor que antes, al responder tu
Servidor DNS. Vuelve a ejecutarlo sucesivas veces y observa como el TTL de los RR decrementa.

o Averigua en Internet y realiza las comprobaciones pertinentes en tu Servidor DNS:

De que forma puedes observar el contenido de la Caché que el Servidor DNS va almacenando en
las peticiones que realiza.

De que forma puedes limpiar o borrar el contenido de la Caché de tu Servidor DNS sin tener que reiniciar el host.

Configuración del Servidor DNS para que reenvíe consultas a Reenviadores (forwaders)

# Edita el fichero de configuración /etc/bind/named.conf.options y configura como reenviador el

Servidor DNS de Google (8.8.8.8).
# Reinicia el servicio DNS para actualizar los cambios.
service bind9 restart
# Verifica en los ficheros logs:
Del sistema (/var/log/syslog) que no se han producido fallos al arrancar el servicio bind.
tail /var/log/syslog
Fichero log por defecto de bind:
cat /var/log/daemon.log | grep “named”

Realiza la captura de paquetes mediante Wireshark durante la ejecución las resoluciones DNS, y
analiza el tráfico capturado.

Parte 2: Configuración del Servidor DNS Bind como Primario (Maestro) para una
Zona de Resolución Directa y una Zona de Resolución Inversa
Configuración del Servidor DNS BIND9 Maestro en debianClienteXX
El Servidor DNS sólo servirá a la Red Interna.
Actuará como Maestro y tendrá Autoridad sobre el dominio "etgXX.es"
Nota: Recuerda que XX es el valor del 2º byte de tu Red Interna, cualquier otro valor invalidara la práctica.
o No se permitirán actualizaciones dinámicas.
o El servidor DNS maestro del dominio será debianClienteXX.etgXX.es (registro NS)
o Los nombres de los equipos serán los usados en la Red Interna (registros A)
o Deberás configurar los siguientes alias (registros CNAME):

Alias FQDN
ns1.etgXX.es debianClienteXX.etgXX.es
www.etgXX.es debianClienteXX.etgXX.es
ftp.etgXX.es winServidorXX.etgXX.es
mail.etgXX.es debianGraficoXX.etgXX.es

o El equipo debianClienteXX.etgXX.es actuará como Servidor de Correo del Dominio (registro

MX)
o El tiempo en cache de las respuestas negativas de la Zona será de 3 horas.
 Actuará como maestro y tendrá Autoridad sobre la zona de Resolución Inversa de la red 10.XX.0.0/24
No se permitirán actualizaciones dinámicas.
El servidor DNS maestro del dominio será debianClienteXX.etgXX.es (registro NS)
Las direcciones IP de los equipos se corresponderán con las del esquema de tu Red Interna. (registro PTR)
El tiempo en cache de las respuestas negativas de la Zona será de 3 horas.

Configura los equipos de la Red Interna para que usen el Servidor DNS instalado en
debianClienteXX y añadan el sufijo etgXX.es a los nombres de dominio no FQDN.

Configuración del dominio de búsqueda

o Desde el host debianClienteXX y edita el fichero /etc/resolv.conf y escribe la info personalizada para
tu nombre de dominio etgXX.es :

Configuración de la Zona de Resolución Directa en BIND9

Recuerda que la info de las Zonas tanto directa como inversa se configura en el fichero /etc/bind/named.conf.local
o Edita dicho fichero e introduce la info necesaria para cumplir los requisitos pedidos anteriormente
adaptado a tu nombre de dominio y dirección oficial de tu Red Interna.
Ejemplo:
Este fichero aún no
existen, lo crearemos
a continuación.

2. Vamos a crear el Fichero de zona directa /etc/bind/db.etgXX.es como copia del fichero existente
db.local, luego realiza una copia y llámale como indicaste en tu zona directa.
Deberás ser muy respetuoso con la sintaxis (espacios, puntos, etc)

TTL positivo por defecto

TTL negativo por defecto

@ equivale al nombre de la
zona "etg00.es"

Como no termina en "." equivale

a "debianGrafico00.etg00.es."
 Notas
A todos los nombres de dominio que se indican sin el punto final (nombres no cualificados), se
les añade el nombre de la zona.
Es importante terminar con un "." los nombres que se escriban con el nombre de dominio completo (FQDN).
La falta o posición equivocada de un "." suele ser una causar común de errores en el DNS
Si el primer campo de una línea RR se deja en blanco, se toma el valor de la línea del RR anterior.
o BIND9 incluye 2 herramientas para verificar la sintaxis y semántica de los archivos de configuración y
archivos de zona:
a. Comprueba el Fichero de configuración principal named.conf.local con el comando
named-checkconf named.conf
b. Comprueba el Fichero de zona con el comando
named-checkzone etgXX.es /etc/bind/db.etgXX.es
9. Una vez nos aseguramos que no tenemos errores sintaxis/semántica reiniciamos el Servicio DNS
service bind9 restart
10. Consultamos el LOG para ver si ha habido fallos al arrancar
tail /var/log/syslog
11. Usa los comandos nslookup y dig, desde tu propio Servidor DNS, para comprobar que tu Servidor
DNS resuelve las consultas directas sobre todos los nombres de la zona "etgXX.es".

12. Vuelve a realizar el apartado anterior pero ahora

desde el host debianGraficoXX. Prueba
exactamente los comandos utilizando el nombre
sin cualificar (no completo):

nslookup www
nslookup ftp
nslookup www.etgXX.es
nslookup debianServidorXX

Si no te resuelve correctamente, soluciónalo.

13. Vamos a comprobar las resoluciones DNS desde un equipo cliente

Windows, arranca tu MV XP/7 y configura tu equipo cliente con el
Servidor DNS de tu Red Interna.
Resuelve las siguientes peticiones de
resolución: c:/> nslookup www
c:/> nslookup ftp
c:/> nslookup www.etgXX.es
c:/> nslookup mail

- Si no te resuelve correctamente, soluciónalo.

Configuración de la Zona de Resolución Inversa en BIND9

7) Edita el fichero de configuración named.conf.local y declara la Zona de Resolución Inversa para tu Red Interna
10.XX.0.0/24, tal y como se muestra en la figura:

Nueva Zona para la

Resolución Inversa de tu
Red Interna 10.XX.0,0/24

Fichero aún no creado

4) Crea el nuevo Fichero de Zona de resolución inversa db.10.XX.0 dentro del directorio /etc/bind.
Añade las directivas y los registros de recursos (RR) necesarios para cumplir con los requisitos de la
práctica, tal y como muestra la figura:
Equivale al nombre de la
zona 0.33.10.in-addr.arpa

Como termina sin "." equivale

a 1.0.33.10.in-addr.arpa

Como termina en "." no se completa

con el nombre de la zona

Ya tenemos la Zona Inversa creada y configurada para los hosts de nuestra Red Interna, vamos
ahora, a verificar que todo está bien.
Para ello, igual que hicimos antes con la Zona Directa, primero realizamos las siguientes comprobaciones:
12) named-checkconf named.conf
13) named-checkzone 0.XX.10.in-addr.arpa /etc/bind/db.10.XX.0
Reiniciamos el servicio BIND9
Consultamos el fichero log del sistema
Comprobamos mediante los comandos nslookup y
dig que el Servidor DNS resuelve correctamente
las peticiones DNS inversas de nuestra Zona.

Desde el propio host Servidor DNS (recuerda

que la IP del servidor DNS es la del loopback)
Desde el equipo de tu Red Interna de Windows (XP/7),
realiza las siguientes resoluciones. Observa como ahora
conoce bien la equivalencia del nombre con la IP del
Servidor que resuelve.
Parte 3: Transferencia de Zona

A partir del fichero “ud3-Anexo Transferencia de Zona entre Servidores DNS” realiza la
parte de transferencia de zona para Servidores DNS Bind en Linux usando los siguientes Mvs
como Servidores:

Servidor DNS Maestro: debianClienteXX

Servidor DNS Esclavo: debianGraficoXX

Creación de un Servidor DNS Secundario (o esclavo) y habilitar

la Transferencia de Zona entre el DNS Maestro y DNS esclavo
¿Qué es una Transferencia de zona?
Las Transferencias de zona DNS, a veces
llamadas AXFR por el tipo de solicitud, es un
tipo de transacción de DNS.
Es uno de varios mecanismos disponibles para
administradores para replicar bases de datos
DNS a través de un conjunto de servidores DNS.
- La transferencia puede hacerse de dos formas
completa (AXFR) o incremental (IXFR)
- Se producirá una transferencia de zona durante cualquiera de los siguientes escenarios:
Al iniciar el servicio DNS en el servidor DNS secundario.
Cuando caduca el tiempo de actualización.
Cuando se guardan los cambios en el archivo de zona principal y hay una notificación lista.
¿Cómo funciona?
Una transferencia de zona utiliza el Protocolo de Control de Transmisión (TCP) para el transporte, y
toma la forma de una transacción de cliente-servidor. El cliente que solicita una transferencia de zona
puede ser un servidor esclavo o servidor secundario, que solicita datos de un servidor maestro.

La parte de la base de datos que se replica es una zona.

Los campos de este registro de recursos SOA, en particular, el "número de serie",
determinan si la transferencia de datos necesita ocurrir o no.
El cliente compara el número de serie del registro de recursos SOA con el número de serie en la última copia de
ese registro de recursos que tiene. Si el número de serie del registro que está siendo transferido es mayor, los
datos en la zona se considera que han "cambiado" (de alguna manera) y el esclavo procede a solicitar la
transferencia real de datos de zona. Si los números de serie son idénticos, los datos en la zona se considerará que
no ha "cambiado", y el cliente puede seguir utilizando la copia de la base de datos que ya tiene, si tiene una.

El proceso de transferencia de datos real comienza por el cliente de enviar una consulta (opcode 0) con el
QTYPE especial (tipo de consulta) AXFR (valor 252) a través de la conexión TCP con el servidor.
El servidor responde con una serie de mensajes de respuesta, que comprende todos los
registros de recursos para cada nombre de dominio en la "zona".
La primera respuesta comprende el registro de recursos SOA de la zona ápice. Los otros datos
siguen sin un orden determinado.
El final de los datos es señalado por el servidor de repitiendo la respuesta que contiene el registro
de recursos SOA para la zona de ápice.

Lo anterior describe la transferencia de zona completa.

La Transferencia de zona incremental difiere de transferencia de zona completa en los siguientes aspectos:

Los cliente utiliza el QTYPE IXFR especial (valor 251) en lugar del AXFR QTYPE.
Los cliente envía el registro de recursos SOA de la zona ápice que en la actualidad cuenta, en su caso,
en el mensaje IXFR, dejando que el servidor saber qué versión de la "zona" que cree que es actual.
Aunque el servidor puede responder de la manera normal AXFR con los datos completos de la zona,
también puede responder con un lugar de transferencia de datos "incrementales". Este último comprende
la lista de cambios en los datos de zona, en la zona para el número de serie, entre la versión de la zona
que el cliente informa al servidor como que tiene y la versión de la zona que es actual en el servidor.
 Los cambios comprenden dos listas, una de los registros de recursos que se elimina y uno de los
registros de recursos que se insertan. (Una modificación de un registro de recurso se representa
como una eliminación seguido por una inserción.)
La transferencia de zona es totalmente iniciada por el cliente. Aunque los servidores pueden enviar un
mensaje NOTIFICACIÓN (NOTIFY) a los clientes (que se les ha informado acerca de) cada vez que se ha
realizado un cambio en los datos de zona, la programación de las transferencias de zona está totalmente bajo
el control de los clientes. Los clientes programan las transferencias de zona en un principio, cuando sus
bases de datos están vacíos, y posteriormente a intervalos regulares, en un patrón controlado por los valores
en los campos "refrescar", "reintentar", y "caducar" en el registro de recursos SOA de la zona ápice.

DNS Maestro DNS Esclavo

o Intercambio de Registros SOA (UPD/53)
o Establecimiento de la Conexion TCP (TCP/53)
o Tramas DNS IXFR o AXFR (TCP/53) SOA query
o Fin de la Conexión TCP (TCP/53)

SOA answer
Transferencia de
Zona
AXFR o IXFR query

AXFR o IXFR answer

¿Cómo se configura en Windows Server?

o S.DNS-1 primario
o S.DNS-2 secundario
Instalo el servicio
Creo nueva zona Directa + Permito todas las actualizacs dinamicas
Sobre la zona creada (q debe llamarse igual que la creada en el S.DNS-
1), ej etg.es boton dcho+ propiedades + Cambiar Tipo o Perfil del Servidor
Zona Secundaria (almacena una copia de una zona existente). Balanceo carga +
Tolerancia a fallos
Agrego la IP del S.DNS-1 (desde la misma ventana)

o S.DNS-1 primario
Creo el nuevo Registro A sobre el nuevo host S.DNS2
Sobre la zona Directa creada + boton decho + propiedades +
transferencia de zona
Sel. "Permitir transferencia de zona"
Aqui, puedo, definir QUE servidores están autorizados para la transf de zona
Agrego "Servidores de nombres "
Sobre la ventana anterior, pulso boton "Notificar" para configurar
automaticamente que se le notifica cuando existan cambios.

NN: S. DNS-2 Secundario.

Creo una nueva Zona Secundaria (crea una copia de una zona q ya existe en otro Servidor)
Sobre la zona creada “etg.es” + boton derecho + Transferir desde Maestro
 3

Y actualizando / F5, compruebo q el Servidor Secundario recibe la copia de toda la Zona

del Maestro 3. Idem para la Zona Inversa
CAPTURAS DE TRAFICO

Caso: AXFR: Transferencia de Zona Completa (252)

Caso: IXFR (Incremental): El Servidor DNS Principal notifica una Actualización de la

Zona al DNS Secundario
CASO: AXFR (Completa) para la Zona R. Inversa incluye TCP y UDP

Detalle de la Trama “AXFR query”

Detalle de la Trama “AXFR Response”
¿Cómo se configura en Debian Linux?
-----------------------------------------------------------
En el host S. DNS-1 Primario (debianCliente00)
-----------------------------------------------------------

1) Creando la zona Master en /etc/bind/named.conf.local

zone "etg00.es" IN {
type master;
file "/etc/bind/etg00.es";
notify yes ; // permite notificar los cambios al Esclavo cuando sucedan
allow-transfer { 10.0.0.3; }; // IP del Servidor esclavo autorizado
};
O también
zone "etg00.es" {
type master;
file "/etc/bind/etg00.es";
also-notify { 10.0.0.3; }; // IP del Servidor esclavo autorizado
};
2) Creacion del Archivo de Zona /etc/bind/db.etg00.es:

$ORIGIN .
$TTL 86400 ; 1 day
etg00.es IN SOA etg00.es. root.etg00.es (
2010122801 ; serial
7200 ; refresh (2 hous)
7200 ; retry (2 hours)
2419200 ; expire (5 weeks 6 days 16 hours)
86400 ; minimum (1 day)
)
$TTL 14400 ; 4 hours
.....
@ IN NS debianCliente00
@ IN NS debianGrafico00 ; IMPORTANTE
debianCliente00.etg00.es. IN A 10.0.0.2
debianGrafico00.etg00.es. IN A 10.0.0.3
....
ns1 IN CNAME debianCliente00
ns2 IN CNAME debianGrafico00
--------------------------------------------------------------
En el host S. DNS-2 Secundario (debianGrafico00)
---------------------------------------------------------------
Instalo el bind9 Enable
AXFR transfers
Creo la nueva zona Secundaria/Esclavo /etc/bind/named.conf.local
zone "etg00.es" {
type slave;
file "/var/lib/bind/db.etg00.es";
 masters { 10.0.0.2; }; // IP del S. Primario
}
+ No hace falta crear el archivo db.etg00.es, lo creara el automaticamente

IMPTE:
--------------------------------------------------------------------------------
- Hacer los tests a los 2 servidores dns para detectar posibles errores.
- En la Notificacion por cambio IXFR, ante cambios en Primario HAY QUE
CAMBIAR/AUMENTAR EL NUMERO DE VERSION DEL PRIMARIO PARA QUE AL COMPARAR
CON EL ESCLAVO, SE ACTUALICE
- Path de ubicacion de los volcados de Cache: /var/cache/bind
especificado en /etc/bind/named.conf.options
options {directory /var/cache/bind; }
que se realicen por: # rndc dumpdb -cache, crea el archivo /var/cache/bind/named_dump.db
--------------------------------------------------------------------------------
TESTs
/etc/bind/# named-checkconf named.conf
/etc/bind/# named-checkzone etgXX.es /etc/bind/db.etgXX.es

Analisis de LOGs
tail /var/log/daemon.log
tail /var/log/syslog

UD4 Servicio de Transferencia de archivos

El servicio FTP

Ubicación en la pila de
protocolos

Aplicació
n FTP
Transport
e TCP
Re
d IP
El Servicio FTP hace uso del protocolo de Capa 7 FTP (siglas en inglés de File Transfer Protocol, 'Protocolo
de Transferencia de Archivos'), es un protocolo de red para la transferencia de archivos entre sistemas
conectados a una red TCP (Transmission Control Protocol), basado en la arquitectura cliente-servidor.

Desde un equipo cliente se puede conectar a un servidor para descargar archivos desde él o
para enviarle archivos, independientemente del sistema operativo utilizado en cada equipo.

El servicio FTP es ofrecido por la capa de aplicación del modelo de capas de red TCP/IP al usuario,
utilizando normalmente el puerto de red 20 y el 21.
 Puertos 20/TCP DATA Port
21/TCP Control Port

Componentes del Servicio

Clientes FTP. Acceden al Sistema de ficheros del equipo donde están instalados y establecen conexiones con los
servidores FTP para realizar diversas órdenes en sobre dicho sistema (subir, bajar archivos, crear, modificar,
borrar carpetas, etc). Siempre dependerá de los permisos con los que se pueda conectar el Cliente al Servidor.
o Interprete de Protocolo (PI) de Usuario. Controla las conexiones del Canal de Control
o Proceso de Transferencia de Datos (PTD) del Cliente. Controla las conexiones del Canal de
Datos
Servidores FTP. Prestan el Servicio a través de sus puertos 20,21/tcp y acceden al Sistema de
ficheros del equipo donde están instalados, manejando las conexiones con el Cliente.
o Interprete de Protocolo (PI) de Usuario. Controla las conexiones del Canal de Control
o Proceso de Transferencia de Datos (PTD) del Cliente. Controla las conexiones del
Canal de Datos

1
Modos de conexión del cliente: Modos activo y pasivo
En este proceso de comunicación entre cliente y servidor, el cliente puede actuar en modo
activo o en modo pasivo.

1. Modo Activo

En modo Activo, el servidor siempre crea el canal de datos en su puerto 20, mientras que en el lado del cliente el
canal de datos se asocia a un puerto aleatorio mayor que el 1024. Para ello, el cliente manda un comando PORT
al servidor por el canal de control indicándole ese número de puerto, de manera que el Servidor FTP pueda abrirle
una conexión de datos por donde se transferirán los archivos y los listados, en el puerto especificado siendo una
conexión entrante para el cliente. En este modo Activo de actuar el Servidor FTP, es importante recordar que si el
Cliente tiene Cortafuegos, bien en su equipo o bien en el Router de entrada a la Red donde se ubique el Cliente,
esta Conexión Entrante que intenta establecer el Servidor FTP podría ser bloqueada, dado que normalmente es el
Cliente el que inicia las conexiones y en este caso es al contrario.

Los pasos de una conexión FTP en modo activo se

muestran en el siguiente esquema:

Lo anterior tiene un grave problema de seguridad, y es que la máquina cliente debe estar dispuesta a aceptar
cualquier conexión de entrada en un puerto superior al 1024, con los problemas que ello implica si tenemos el
equipo conectado a una red insegura como Internet. De hecho, los cortafuegos que se instalen en el equipo para

2
evitar ataques seguramente rechazarán esas conexiones aleatorias. Para solucionar esto se
desarrolló el modo pasivo.
2. Modo Pasivo

En este modo las conexiones del Canal de Control funcionan de la misma manera al modo Activo, sin embargo, en
el Canal de Datos es el Cliente quién establecerá las conexiones con el Servidor FTP, es decir, tiene un
funcionamiento típico del modelo Cliente/Servidor en todo momento con el rol que tienen asignado cada uno.

El puerto 20/TCP del Servidor en este modo no se utiliza.

Funcionamiento:

El Cliente establece una conexión TCP (con su puerto Origen>1023, ej. 1035/tcp) sobre el puerto
TCP de control 21/tcp del Servidor que permanece a la escucha.

Cuando el cliente quiere trabajar con el Modo Pasivo envía un comando 'PASV' sobre el puerto del
canal de control, el servidor FTP le indica por este canal el puerto al que debe conectarse el cliente
para realizar la transferencia de datos (mayor a 1023 del servidor , ej. 2040/tcp).

A continuación es el Cliente el que establece la conexión TCP para el Canal de Datos (en el modo
Activo era el Servidor quién la iniciaba) con puerto Origen TCP mayor a 1023 (normalmente el
siguiente al que uso en la conexión anterior ej. 1036/tcp) hacia el puerto del Canal de Datos del
servidor TCP especificado anteriormente (2040/tcp).
A partir de ese momento, se realiza la transferencia de datos entre Cliente y Servidor por el Canal de Datos.

Por último, se cerrará la conexión establecida a instancia normalmente del Cliente.

Antes de cada nueva transferencia tanto en el modo Activo como en el Pasivo, el cliente debe enviar
otra vez un comando de control (PORT o PASV, según el modo en el que haya conectado), y el
servidor recibirá esa conexión de datos en un nuevo puerto aleatorio (si está en modo pasivo) o por
el puerto 20 (si está en modo activo).

Observa la figura:

3
Los pasos de una conexión FTP en modo
activo se muestran en el siguiente esquema:

Tipos de transferencia de ficheros

Es importante conocer cómo debemos transportar un archivo a lo largo de la red. Si no utilizamos
las opciones adecuadas podemos destruir la información del archivo. Por eso, al ejecutar la
aplicación FTP, debemos acordarnos de utilizar uno de estos comandos (o poner la correspondiente
opción en un programa con interfaz gráfica):

Tipo ASCII. Se transmite byte a byte. Adecuado para transferir archivos que sólo contengan
caracteres imprimibles (archivos ASCII, no archivos resultantes de un procesador de texto),
por ejemplo páginas HTML, pero no las imágenes que puedan contener.
Tipo Binario. Se transmite bit a bit. Este tipo es usado cuando se trata de archivos
comprimidos, ejecutables para PC, imágenes, doc, archivos de audio...

Ejemplos de cómo transferir algunos tipos de archivo dependiendo de su extensión:

En la red existen diversas soluciones de software que desarrolla este tipo de tecnología, los más
conocidos, son Filezilla (software libre) y CuteFTP (shareware)

Tipos de acceso

¿Cómo puedo acceder a un Servidor FTP?

Para realizar una petición Cliente FTP desde un ordenador, necesitamos tener instalado el
software cliente necesario, éste acceso se puede realizar desde:

Navegadores web. Simplemente cambiando el protocolo http:// por ftp:// y a continuación

el URL o bien la IP del Servidor FTP.
Por comando desde un terminal o consola, tanto Windows/Linux/MAC vienen con el software
cliente instalado y disponible para su uso. Simplemente ejecutando el comando: ftp
A través de algún Software especifico Cliente FTP como Filezilla Client, smartFTP también otros
programas GUI de desarrollo Web como Frontpage, Dreamweaver, Aptana, etc, suelen traer este
software para realizar desde ellos la administración de ficheros del contenido de un Servidor Web.
4
 Filezilla Client: https://filezilla-project.org/download.php?type=client
SmartFTP: (https://www.smartftp.com/),

¿Con qué usuario me puedo conectar al Servidor FTP?

Un Servidor FTP puede estar configurado para permitir 2 tipos de acceso distintos:

Acceso anónimo. Los servidores FTP anónimos ofrecen sus servicios libremente a todos
los usuarios, es decir, no precisan una cuenta de usuario especifica.
Son accesos limitados en permisos, normalmente solo se tiene permiso de Lectura, es
decir, para ver y descargar archivos desde el Servidor remoto a local.
La forma de acceso es con el login "anonymous" o bien "ftp" y sin contraseña
Acceso de usuario. En este acceso se realiza el proceso típico de autenticación de login
y password especifico para ese usuario.
De forma que los permisos otorgados serán específicos para cada usuario, principalmente en
las carpetas a las que suele acceder.
Lo habitual es darle un acceso exclusivo a una carpeta con permisos de Lectura y Escritura
pero que no pueda navegar por carpetas de nivel superior (padre). A este proceso se le dice
que se "enjaula" al usuario en dicha carpeta (home de usuario).
Seguridad
Un problema básico de FTP es que está pensado para ofrecer la máxima velocidad en la conexión,
pero no la máxima seguridad, ya que todo el intercambio de información, desde el login y password
del usuario en el servidor hasta la transferencia de cualquier archivo, se realiza en texto plano sin
ningún tipo de cifrado, con lo que un posible atacante puede capturar este tráfico, acceder al
servidor y/o apropiarse de los archivos transferidos.

Si queremos aportar Seguridad al Servicio de Transferencia de ficheros podemos optar entre:

- Hacer uso de FTPS o FTP/SSL. Que consiste en encapsular tanto el proceso de Autenticación
como la transferencia de ficheros bajo SSL (Secure Sockets Layer) o en TLS (Transport Layer
Security) para ofrecer comunicaciones seguras.
Gracias a la utilización de algoritmos criptográficos y certificados digitales se puede garantizar la
Confidencialidad y la Integridad de la información transmitida, así como la Autenticación de los Servidores.

o También son de gran utilidad aplicaciones como scp y sftp, incluidas en el paquete SSH, que
permiten transferir archivos pero cifrando todo el tráfico.

5
Principales comandos del Servicio FTP

LIST Este comando permite que se vuelva a enviar la lista de archivos y directorios presentes
en el directorio actual. Esto se envía a través del DTP pasivo. Es posible indicar un
nombre de directorio en el parámetro de este comando. El servidor de DTP enviará la
lista de archivos del directorio ubicado en el parámetro.

STOR Este comando (store [almacenar]) le pide al servidor de DTP que acepte los datos enviados
por el canal de datos y que los almacene en un archivo que lleve el nombre que se da en los
parámetros. Si el archivo no existe, el servidor lo crea; de lo contrario, lo sobrescribe.

RETR Este comando (RETRIEVE [RECUPERAR]) le pide al servidor de DTP una copia del
archivo cuya ruta de acceso se da en los parámetros.

RNTO Este comando (rename from [renombrar a]) permite volver a nombrar un archivo. En los
parámetros indica el nombre del archivo que se va a renombrar y debe estar
inmediatamente seguido por el comandoRNFR.

DELE Este comando (delete [borrar]) permite que se borre un archivo, cuyo nombre se da en los
parámetros. Este comando es irreversible y la confirmación sólo puede darse a nivel cliente.

Más info: http://www.ietf.org/rfc/rfc959.txt

6
Comunicación entre Procesos: Sockets
¿Qué es un Socket?
# Un socket es una interfaz de entrada-salida de datos que permite la intercomunicación entre Procesos.

# Los Procesos pueden estar ejecutándose en el mismo o en distintos sistemas, unidos mediante una red.

# Un socket por tanto, es un mecanismo mediante el cual se comunican procesos con el fin
primordial de intercambiar información de forma bidireccional entre distintas máquinas.

# Los sockets permiten la comunicación entre Procesos, como los teléfonos permiten la
comunicación entra las personas.

Tipos de Socket

o Socket Stream son los más utilizados, hacen uso del protocolo
TCP. Por tanto, orientado a la conexión. Son los más utilizados.

o Socket Datagram hacen uso del protocolo UDP. No

orientado a la conexión.

o Socket Raw. Pensados para investigación y desarrollo de

nuevos protocolos de comunicación.
Comunicación por medio de Sockets tipo Stream

Para establecer la comunicación entre el Cliente y el Servidor se deben realizar los siguientes pasos:

o Cliente y Servidor crean el socket con la función socket(), la cual devuelve el descriptor, utilizado
para conectarse, enviar y recibir datos. El descriptor posee la información del dominio (donde se
encuentran los procesos) donde se realiza la conexión, el tipo de socket y el protocolo.

o Se nombra el socket en el servidor con la función bind(), la cual se utiliza para asignarle
una dirección IP y un puerto por donde escuchará las solicitudes del cliente.
o El Servidor entra en estado Escucha de conexiones con la función listen().

o El Cliente solicita la conexión por medio de la función connect(); dicha función quedará
bloqueada hasta que el servidor acepte la conexión o bien si no hay servidor en el sitio
indicado, saldrá dando un error. En esta llamada se debe facilitar la dirección IP del servidor
y el numero de Servicio (puerto) que se desea.
o El Servidor acepta la conexión con la función accept() y retorna el descriptor del Socket.

o Cuando se establece la comunicación tanto el cliente como el servidor pueden enviar con
la función write() y recibir con la función read() datos y archivos.
o Se finaliza la comunicación tanto en el cliente como en el servidor mediante la función close().
UD4 El Servicio FTP
ud4p1. Práctica "Servicio FTP en Windows Server 2019”
Recursos:
Laboratorio del aula
https://www.iis.net/learn/publish/using-the-ftp-service
http://www.iis.net/learn/publish/using-the-ftp-service/configure-ftp-with-iis-manager-authentication-in-iis-7#03
https://www.iis.net/learn/publish/using-the-ftp-service/cse-curated-view-ftp-security-settings
Objetivos:
- Administración del Servicio FTP en Windows
Server Entrega:
Evaluación en el Aula

Parte I: Servicio FTP en Windows Server

1. Instalación del Servicio FTP en Windows.

Situación: Nuestra MV “winServidorXX” ya tiene instalado el Servicio DNS con el prefijo “etgXX.es”.
Ahora procederemos a instalar el nuevo Servicio de transferencia de Archivos o FTP en dicha MV winServidorXX.
o Windows incluye esta Función o Rol dentro del llamado Servidor IIS (Internet Information
Server) donde incluye otros servicios como HTTP, etc.
oInstala exclusivamente el Servicio FTP y la Consola de administración IIS

Recuerda instalar, de momento, exclusivamente, el panel de control de administración IIS y el Servicio FTP

- Una vez instalado correctamente, nos ha debido crear una nueva Herramienta de Administración llamada
“Administrador de Internet Information Services (IIS) ”, para acceder a ella puedes hacerlo
directamente desde Herramientas Administrativas y también desde la Consola MMC.
 -

Agrega desde la Consola MMC que ya debes tener creada el nuevo complemento IIS versión 10 de
administrativo Windows Server 2019 para poder administrarlo también desde esta Consola.
2. Creación de un Nuevo Sitio FTP
o En la practica, crearemos la siguiente estructura de
Datos: C:/FTP/LocalUser
/admin
/userftp1
/userftp2

2.1 Autenticación Básica

Como ya comentamos en teoría, existe la posibilidad en FTP de crear sitios anónimos o de acceso
público (con credenciales estándars o conocidas, como anonymous) y crear sitios FTP Básicos
con credenciales de usuarios específicos.
OO: Vamos a crear un nuevo Sitio FTP con Autenticación Básica para los siguientes
credenciales de usuarios y con los siguientes permisos:

Nombre de Contraseña Recurso Ficheros Permisos Aislamiento de

Usuario Usuarios
admin Passetg0 admin file_admin.txt Leer, Escribir SI
userftp1 Passetg0 userftp1 file_userftp1.txt Leer, Escribir SI
userftp2 Passetg0 userftp2 file_userftp2.txt Leer SI
anonymous --- Public Public.txt Leer SI

- Crea los nuevos usuarios, en nuestro caso serán Usuarios Locales al sistema aunque
realmente deberían ser Usuarios del Dominio, y recursos antes de la instalación del nuevo Sitio.

Agregar un Nuevo Sitio FTP desde la Herramienta administrativa IIS

Nos sale un asistente para especificar el nombre y la carpeta de nuestro Sistema de Ficheros.
Importante coger el Directorio padre que contiene el “LocalUser” ya creado.
A continuación nos pedirá los datos referidos a la Dirección IP y si utilizamos Certificado Digital para
configurar el Sitio FTP seguro con SSL, esto lo veremos en la siguiente práctica, de momento aquí, no
utilizaremos SSL para este sitio FTP.

A continuación, nos sale una ventana para poder elegir la Autenticación así como la Autorización
referida a qué usuario/s podrán tener acceso a los recursos y con qué Permisos, de momento solo
indica que se Habilite la Autenticación Básica y el resto lo configuraremos más tarde.

Una vez completado las opciones del Asistente, el Servicio FTP ya queda funcionando.
Comprueba que esta escuchando correctamente el puerto 21/tcp

C:\> netstat -ano| find ”21” | find “LISTENING”

 2.2 Reglas de Autorización de FTP
Primero es importante que sobre el Sitio FTP “FTP Laboratorio XX” demos Permiso de “Lectura”
a nuestros usuarios para permitir la navegación a las Recursos.

A continuación, sobre cada una de los Recursos del Sitio creado, definiremos ahora las Reglas de Autorización de
Acceso sobre ese Recurso, definiendo qué Usuarios y con qué Permisos puede acceder a los recursos creados para el FTP.

- Configura los Permisos de la tabla anterior sobre los Recursos creados.

Ejemplo de Reglas de Autorización de Permiso para el usuario “admin”

o Configura el resto de usuarios con los permisos pedidos.

Comprueba desde el propio Servidor “winServidorXX” mediante comandos ftp que ya tienes acceso al Sitio FTP.
# Acceso ftp 10.0.0.5

Comprueba mediante un ls o dir,

en qué carpeta hace inicio sesión

Comprueba que cualquier usuario

de los autorizados puede moverse
libremente por los recursos del Sitio

o Comprueba y reconfigura en caso necesario, que tu Servidor DNS en winServidorXX el alias

“ftp.etgXX.es” apunte ahora a tu Servidor FTP real.
Acceso ftp.etgXX.es

Comandos FTP consola.

Comprueba tienen los permisos otorgados y los qué no.

 Para evitar que los usuarios puedan acceder a recursos que no son los inicialmente asignados debemos
“enjaular” los usuarios.

2.3 Aislar o “enjaular” usuarios a su carpeta “home”.

Esta función permite que el usuario una vez que se autentique con el Servidor FTP no pueda “salir” de
su carpeta, es decir, no pueda subir a carpetas superiores quedando de esa forma “enjaulado”.
En Windows debemos definir estructuras de carpetas especificas para permitir esta función, de acuerdo a:

Realiza el Aislamiento de los Usuarios a sus carpetas según la tabla anterior.

o Comprueba ahora que tus usuarios

están enjaulados y no pueden salir
de su home asignado

Ejemplo:
3. Operaciones específicas por FTP

3.1 Desde linea de comandos FTP (del host MV winClienteXX)

Realizando las siguientes operaciones:

oConectate como “userftp1” (ftp.etgXX.es)

oCrea una nueva carpeta llamada “datos”

oSube a la carpeta creada dos nuevos archivos

Ejemplo de Conexión FTP

3.2 Desde el Explorador de Archivos

o Ejemplo de Conexión para el usuario “userftp1”

Contenido Recurso FTP

 3.3 Desde del Navegador web

o Ejemplo de Conexión FTP

para el usuario “userftp1”

Contenido Recurso FTP remoto:

3.4 Software Cliente FTP Filezilla .

Descarga e instala en la MV “winClienteXX” el Filezilla Client .

Desde el Software Cliente FTP Filezilla. Abre la MV “winCliente” e instalate este funcional y muy
utilizado software gratuito para realizar conexiones FTP a servidores FTP.

- Desde el menú de Archivo + Nuevo Sitio, create distintas conexiones una para cada Usuario creado.

Realiza las siguientes operaciones de transferencia de archivos:

o Realiza operaciones de transferencia simplemente arrastrando los ficheros entre las ventanas de Local y Remoto
oSelecciona múltiples ficheros y carpetas desde Local y subelas al Servidor
o Crea nueva carpeta en el Servidor Remoto con botón derecho (recuerda que los Permisos de
escritura solo los tienen admin y userftp1)
oRealiza operaciones de renombre de ficheros en el Servidor
oRealiza operaciones de borrado en el Servidor
oCrea un nuevo fichero en el Servidor
Realiza las siguientes capturas de tráfico FTP con Wireshark
o Realiza capturas de tramas de red FTP en modo conexión Activa. Localiza el comando “PORT”
o Realiza capturas de tramas de red FTP en modo conexión Pasiva. Localiza el comando “PASV”
o Comprueba que el servicio FTP es “No seguro” y que sus tramas NO van cifradas, aporta
pantallazo de la autenticación básica de un usuario, ejemplo “admin” y que se averiguan
facilmente sus credenciales de usuario (nombre usuario y clave.)

Parte II: Servicio FTP Anónimo en Windows Server

o Realiza tú ahora la configuración de un Recurso para tener acceso “Anonimous” a nuestro Sitio
FTP y recuerda que solo debe tener permiso de Lectura.
UD4 Servicio de Transferencia de archivos
Práctica: "ud4p2 Servidor proFTPd en Linux Debian"
Objetivos:
Configurar y administrar un Servicio de Red FTP en Linux.
Recursos:
Laboratorio, Recursos del Aula Virtual.
Software libre:
Linux Debian, proftpd, webmin, Filezilla, wireshark
Actualmente existen múltiples servicios de red que permiten a la transferencia de ficheros, como son:
A través de servicios de correo electrónico (adjuntando ficheros)
Servicios web mediante el protocolo HTTP haciendo uso de los hipervínculos para
descargar ficheros directamente.
Servicios P2P (Peer to Peer) de descarga, por ejemplo, con el protocolo
BitTorrent Servicios para compartir recursos en red (Samba/SMB/CIFS)

FTP sigue siendo una opción popular como forma de distribuir o transferir grandes colecciones de
archivos, a pesar del aumento de bittorrent, y el creciente número de servidores HTTP.

FTP es un método que a menudo se pasa por alto para almacenar y dar acceso a los archivos, en
muchos casos, los servidores FTP han sido retirados en lugar de servidores web como Apache.

Pero hay una gran cantidad de casos en los que ofrecer acceso a través de FTP tiene sentido,
incluso con las limitaciones de FTP - más notablemente la dificultad de los cortafuegos y los
riesgos de seguridad que implica el uso de contraseñas en texto plano como veremos.

Existen diferentes tipos de servidores FTP empaquetados dentro de Debian, que se puede ver a través de:
# apt-cache search ftp-server
Algunos de los servicios FTP linux más utilizados son:
proftpd http://www.proftpd.org/
vsftpd https://security.appspot.com/vsftpd.html
pure-ftpd http://www.pureftpd.org/project/pure-ftpd

o Servidor FTP proftpd

Uno de los servidores FTP más populares es proftpd, en nuestro caso lo instalaremos
dentro del Laboratorio SER concretamente en la MV Linux Cliente denominada
debianClienteXX, con la idea de analizar los paquetes que se generan dentro de la Red
Interna para las funciones de transferencia de archivos.
o apt-get install proftpd

Comprueba que tienes el puerto 21/tcp abierto

Comprueba la versión de proftpd instalada
# proftpd --version

Si deseamos detener el servidor antes de mayores configuraciones se puede hacer con:

PP: /etc/init.d/proftpd stop
QQ: service proftpd stop
1
Archivo de configuración /etc/proftpd/proftpd.conf
La configuración de proftpd se lleva a cabo a través del archivo de
configuración de /etc/proftpd/proftpd.conf.
2. Instalación de una Herramienta de Administración de Sistemas y Servicios Linux: webmin

Consulta en Internet su instalación, dado que hay que agregar nuevas fuentes en el Repositorio de Linux
y validar su integridad mediante clave.

Figura: Webmin

- Crea un usuario webmin para que solo administre el Servidor FTP, con
credenciales: login: adminftp
pwd: passetg0
- Prueba su acceso y comprueba que solo puede administrar ese servicio.

2
3. Instalación de Software Cliente FTP Filezilla

Instala el SW Filezilla Cliente en tu Maquina Virtual de Windows 7, si aún no lo tienes.

4. Configuración básica Servidor FTP proftpd

Vamos a configurar los siguientes parámetros en el fichero /etc/proftpd/proftpd.conf,
realiza antes una copia de seguridad.
Nombre de nuestro Servidor
ServerName "hostname_MV"
Obligamos a que cada usuario FTP inicien siempre en su directorio (Enjaulado)
DefaultRoot ~
A continuación descomentamos el parámetro "RequiereValidShell" para que los usuarios que
no tengan acceso a la shell puedan usar el servicio
RequireValidShell off
- Creamos un límite de usuarios, con el fin de que solo los usuarios que especifiquemos
podrán usar el Servicio
<Limit LOGIN>
o esta línea indicara los usuarios que se pueden logear al Servicio
AllowUser alumno
# denegamos el Servicio para el resto de usuarios
DenyAll
</Limit>
# Reiniciamos el servicio
/etc/init.d/proftpd restart
# A partir de Debian 10, tenemos que instalar un Cliente FTP:
apt install lftp

Comprobamos el acceso desde el mismo servidor

$ lftp -u alumno 127.0.0.1
o lftp -u alumno debianClienteXX
Especificamos el usuario y password y observamos que entramos en la carpeta home del usuario
"alumno" y que está "enjaulado" en ella, es decir, no puede salir de esa carpeta por seguridad.
Dentro de ella, tiene permiso total, es decir, subir o descargar archivos, crear directorios,
borrar, etc. lftp alumno@debianCliente00:/> ? Nos visualiza los comandos FTP
disponibles Salimos con bye, exit, quit

o Hemos probado con un usuario del Sistema Linux, dado, que esto no es lo más
habitual, vamos a crear distintos usuarios los cuales no queremos que accedan al Sistema
Linux es decir, a la shell, sino simplemente pueda acceder al Servicio FTP.
Para ello, introducimos el siguiente comando:
useradd -m -s /bin/false nombreUsuario
passwd nombreUsuario
-m: Crea el directorio /home/nombreUsuario.
o Crea los siguientes usuarios FTP con su home por defecto

loginUsuario Password home "enjaulado"

userftp1 passetg0 /home/userftp1
userftp2 passetg0 /home/userftp2

Nota: Si quisiéramos usar un directorio home diferente al nombre de

usuario, Ejemplo:
# useradd -m -d /var/www/html -s /bin/false nombreUsuario
3
 # Realiza las siguientes operaciones FTP:

o Crea 2 ficheros de texto dentro de la ruta /home/alumno

o Conectate como usuario “userftp1”
o Comprueba los comandos básicos con ?
o Comprueba que está “enjaulado” en su home.
o Crea un directorio con el mismo nombre que el usuario
o Sube con un mismo comando (mput) los archivos creados anteriormente.
o Renombra uno de los ficheros subidos por otro nuevo.
o Descarga el fichero renombrado.
o Desconectate y comprueba el fichero descargado.

o Creación de un usuario FTP "webmaster" para la Administración del

contenido de una página Web del Servidor Web Apache
- Asegúrate de tener instalado el servicio apache2 en tu MV, sino instalalo (apt install apache2) Observa la
siguiente tabla con comandos básicos de linux sobre creación de usuarios, grupos, permisos:

Comando Significado
# groupadd grupo-web Creamos el grupo-web
# chown -R :grupo-web Damos permisos recursivos y hacemos propietario al
/var/www/html "grupo-web" en /var/www/html

# chmod -R g+rw /var/www/html Damos permisos de Lectura y Escritura al grupo

propietario "grupo-web" del actual árbol de
directorios /var/www
# useradd -g grupo-web -d Creamos el nuevo usuario "webmaster":
/var/www/html -s /bin/false -g grupo-web: Hace que el usuario sea asignado al grupo-web
En este caso no ponemos -m dado que /var/www ya existe (Si tenemos
webmaster instalado el apache2)
-d: Carpeta home del usuario donde se le "enjaulara"
-s /bin/false: Impedimos que el usuario inicie sesión en el sistema linux,
solo lo queremos para FTP
# passwd webmaster Asignamos su clave passetg0
# usermod -G grupo-web webmaster Agregamos al usuario "webmaster" al "grupo-web"

# usermod -G grupo-web www-data Agregamos al usuario "www-data" al "grupo-web"

o Crea la siguiente cuenta de usuario FTP y grupo:

Vamos a crear un usuario con el perfil de "Administración del contenido Web" del Servidor
web Apache, cuyo contenido web, se almacena por defecto en la ruta "/var/www/html".
- Vamos a crear un nuevo grupo a los que añadiremos tanto el usuario ftp "webmaster" como
al usuario de Apache "www-data" y asignar el nuevo grupo a los directorios que nos interesen,
en este caso /var/www/html con permisos de Lectura y Escritura para dichos usuarios.

loginUsuario Password home Grupo Permisos

"enjaulado"
webmaster passetg0 /var/www/html grupo-web Lectura
Escritura

4
 o Configuramos de nuevo el archivo /etc/proftpd/proftpd.conf para
permitir el acceso a los nuevos usuarios creados.

o Realiza las siguientes comprobaciones:

Ver usuarios creados y su configuración: # nano /etc/passwd

Ver los grupos creados: # nano /etc/group
Ver las contraseñas encriptadas: # nano /etc/shadow

o Reiniciamos el Servicio
o Reconfigura el Servicio DNS Bind de la MV debianClienteXX para que resuelva
correctamente el nombre DNS:
ftp.etgXX.es
Comprobamos el acceso de los nuevos usuarios desde un equipo remoto winClienteXX a través del
software cliente FTP Filezilla y desde línea de comandos a través del nombre DNS ftp.etgXX.es.

Realiza operaciones de subida y descarga de ficheros entre tu equipo Local (windows) y

tu equipo Servidor remoto (servidor FTP), crea directorios, borra archivos, etc
comprobando que se cumplen los permisos asignados con todos los usuarios.
Aporta pantallazos del proceso.

Mas sobre usuarios y grupos:

http://www.ite.educacion.es/formacion/materiales/85/cd/linux/m1/
administracin_de_usuarios_y_grupos.html

o Análisis de tramas mediante Wireshark de una transferencia de datos al subir

un Fichero al Servidor FTP (STOR) en Modo Pasivo.
Con uno de los usuarios creados anteriormente realiza una conexión FTP y sube al Servidor FTP el fichero:

fichero-prueba-NombreApellidos.dat

Con el contenido:

"Soy el contenido del fichero y he sido subido al Servidor por Nombre y Apellidos"

Analiza los siguientes paquetes:

Establecimiento de la primera conexión TCP para el Canal de Control

Paquete de petición del Cliente FTP del Modo Pasivo, con detalle de puertos
Proceso de autenticación del Acceso del usuario
Paquete que envía el Cliente ejecutando el comando FTP de subida de archivo
Establecimiento de la conexión TCP para el canal de datos para subir el archivo
Transferencia de datos que produce la subida del archivo al Servidor
Cierre final de la primera conexión TCP que se abrió para el canal de control

7. Servidor FTP proftpd Autenticación Anónima

A partir de la documentación de ayuda que viene en el fichero /etc/proftpd/proftpd.conf y

consultas a Internet reconfigura y adapta tu Servidor FTP para permitir las conexiones anónimas
a un recurso que previamente debes definir y con permisos de solo Lectura.

5
UD4 Servicio de Transferencia de archivos
Práctica: "ud4p3 Servidor FTP sobre SSL/TTL”
Parte I: En Linux Debian
Parte II: En Windows Server
Objetivo:
Usar Certificados de seguridad de clave pública para encriptar las comunicaciones de una
conexión FTP entre los clientes y el Servidor
Recursos:
Laboratorio e Internet
Videotutorial:
Recurso disponible en el Aula
Software:
Openssl, proftpd, wireshark, IIS

Parte I: En Linux Debian

SSL/TLS
Secure Sockets Layer (SSL; en español «Capa de Conexión Segura») y su sucesor

Transport Layer Security (TLS; en español «Seguridad de la Capa de Transporte»)

Son protocolos criptográficos que proporcionan comunicaciones seguras

por una red, comúnmente en Internet.

Usan certificados X.509 y por lo tanto criptografía asimétrica para

autenticar a la contraparte con quien se están comunicando, y para
intercambiar una llave simétrica.

Esta sesión es luego usada para cifrar el flujo de datos entre las partes.
Esto permite la confidencialidad del dato/mensaje, y códigos de autenticación de mensajes para
integridad. Varias versiones del protocolo están en aplicaciones ampliamente utilizadas como
navegación web, correo electrónico, fax por Internet, mensajería instantánea, y voice-over-IP (VoIP).

La versión TLS actual es la TLS 1.2 definida en Agosto de 2008 (en borrador la TLS 1.3)

Opciones de seguridad
Hay varias opciones de seguridad que puede activar el proftpd, el más notable es el uso de seguridad TLS.

- Instalación de OpenSSL (https://www.openssl.org/)

apt install openssl

- Creación de un Certificado de clave pública y configuración de proftpd para su

uso y encriptar las comunicaciones FTP (FTPS- ftp secure)

Para utilizar TLS tendremos que generar un nuevo Certificado de seguridad, el que cual generara un par
de claves (publica y otra privada), y actualizar el archivo de configuración del servidor FTP para usarlo.

Para generar el Certificado lo podemos crear con el comando openssl, que está contenido en el paquete
OpenSSL:

o openssl req -new -x509 -days 365 -nodes -out proftpd-rsa.csr -keyout proftpd-
rsa-key.key

1
Donde:
proftpd-rsa.csr - Contiene la Clave Publica certificada (se enviara al otro extremo)
proftpd-rsa-key.key – Contiene la Clave Privada (no transmitida a nadie, es personal e intransferible)
o Al crear el Certificado asigna Datos de acuerdo a tu Red interna y nombre de Servidor
o Observa los permisos de los archivos generados y su contenido cifrado
o Guarda el fichero del Certificado proftpd-rsa.csr en el directorio /etc/ssl/certs
o Guarda el fichero de la Clave Publica en el directorio /etc/ssl/private

o En el archivo /etc/proftpd/proftpd.conf habilita la directiva

Include /etc/proftpd/tls.conf
RR: A partir de ProFTPD 1.3.3rc1, mod_tls solo acepta conexiones de datos SSL / TLS que
reutilizan la sesión SSL de la conexión de control, como medida de seguridad, para permitir No
reutilzar la session de control deberemos configurar el siguiente parámetro:
TLSOptions NoSessionReuseRequired
- Ahora vamos a configurar nuestro Certificado de Clave Pública creado anteriormente con OpenSSL
para que el Servidor Proftp trabaje con él y así nuestras comunicaciones por FTP sean ahora seguras.
Para ello en el archivo /etc/proftpd/tls.conf, realiza la siguiente configuración:
<IfModule mod_tls.c>
Habilitamos las conexiones para el protocolo
TLS TLSEngine on
TLSLog /var/log/proftpd/tls.log
Usamos el Protocolo Criptografico TLS en su version 1, en lugar del anterior
SSL TLSProtocol TLSv1.2
Obligamos a los usuarios a conectarse al FTPS (no por FTP)
TLSRequired on
# Configuramos nuestro Certificado previamente creado (Clave Publica)
TLSRSACertificateFile /etc/ssl/certs/proftpd-rsa.csr
- configuramos la Clave Privada generada
TLSRSACertificateKeyFile /etc/ssl/private/proftpd-rsa-key.key
- Impedimos que los clientes presenten sus propios
Certificados TLSVerifyClient off
- Obligamos a que las comunicaciones FTP sean solo Seguras –
FTPS TLSRequired on
</IfModule>

mas info: http://www.proftpd.org/docs/howto/TLS.html

o Revisa la sintaxis de proftpd
o Revisa los ficheros LOG: del Sistema, del proftpd, y de TLS (sus nombre los encontraras
en los ficheros de configuración anteriores)

# Conexión cliente FTP

usando cifrado TLS con
el Servidor FTP
Creamos un nuevo perfil de Sitio
FTP y la novedad es elegir un
FTP explicito con TLS

Cuando accedemos desde el

Filezilla Cliente, con el nuevo perfil
del sitio FTPS, por primera vez nos
muestra la siguiente pantalla, dando
info sobre el Certificado (Algoritmo
de encriptación usado, caducidad
del Certificado, huella digital etc.)

2
Caso ejemplo, subiremos el fichero "nuevo.txt" desde local al Servidor FTPS
Este es el listado de comandos/respuestas obtenidos desde el Filezilla, donde vemos la verificación del
Certificado de seguridad TLS

4. Análisis de paquetes mediante wireshark

Realiza una nueva conexión FTP Segura con TLS (FTPS) para subir un nuevo archivo al Servidor
FTP realizando la captura de paquetes de esa comunicación.
Analiza dicha captura identificando los siguientes paquetes:

Comprueba que tanto en el proceso de Autenticación de las credenciales de usuario como en el

proceso de transferencia de archivos su contenido, no se ven en texto claro.

Reconstruye el Flujo de Datos TCP para observar que ahora va todo cifrado.

Verifica ahora que el acceso FTP (sin cifrar) no está permitido en el Servidor

3
Parte II: En Windows Server

Servidor FTP sobre SSL/TLS en Windows Server 2019 creando un Certificado

digital a través de una Solicitud a la Entidad Certificadora (CA) del Servidor.

Se pide:

Se desea crear en la MV “winServidorXX” del Laboratorio un Servicio de FTPS mediante el uso de un

Certificado solicitado a la Autoridad de Certificación (CA) del Windows Server que permita cifrar las
conexiones FTP entre Cliente y Servidor que permita los accesos al Sitio creado en la práctica anterior pero
de forma cifrada haciendo uso del Certificado creado específicamente para nuestro Sitio FTP.

Una Autoridad Certificadora (CA) es una Entidad de Confianza encargada de Emitir y Revocar
Certificados Digitales utilizados para la Criptografía de Clave Publica y la firma electrónica.
En nuestro caso será de utilización para la ver el proceso de Solicitud, Emisión de un Certificado
Digital de Clave Publica para garantizar la Seguridad en las comunicaciones digitales a través del
Protocolo TLS (Transport Layer Security) utilizado en FTPS.

o Para instalar la Autoridad de Certificación deberemos instalar el Servicio de Certificado del

Directorio Activo. (con sus valores por defecto).
Después de la instalación nos dará un Warnning, porque deberemos Configurar el Servicio.

Configurando el Servicio de Certificado del AD, como:

o Entidad de certificación
o CA Independiente
o CA Raíz
o Creando nueva Clave Privada
o Algoritmo SHA1 de 2048 de longitud
o Duración: 5 años

4
o Nos crea una nueva Herramienta Administrativa llamada “Entidad de Cerficación” desde donde
se realizaran las operaciones de Emisión, revocacion, etc de Certificados digitales.
o Agrega la nueva Herramienta a tu Consola MMC.

Trabajaremos desde 2 opciones de configuración:

oPor un lado, de “Certificados de Servidor” de IIS. Desde donde crearemos la Solicitud de un Certificado
oPor otro lado, desde la “Entidad de Certificación (CA)” que recogerá la Solicitud anterior, la emitirá y creará
el Certificado para el Sitio FTPS. Igual procedimiento realizaríamos para un Sitio Web seguro (https).

o Crea 1º una Solicitud de Certificado desde “Certificados de Servidor”

Completa los Datos de tu Certificado Digital personal para FTPS de igual forma que hicimos en Linux, especificando
Datos relativos siempre a tu Red Interna y tus datos personales (nombre, etc).
Con Criptografía RSA de longitud de clave 2018 bits

5
o Herramienta de “Entidad de Certificación”
Desde aquí enviaremos la Solicitud a nuestra CA, dando validez y Autenticidad.

o Posteriormente debes realizar el proceso de “Emitir” la Solicitud anterior

o A continuación, Guardamos el “Certificado” ya emitido como Fichero (exportación). Valores por
defecto.
o Desde la HHAA del IIS “Certificado del Servidor”, realizamos el proceso de “Completar la Solicitud”
seleccionando el nuevo Certificado ya emitido por la CA y ya tendremos listo el Certificado para ser
utilizado por cualquier Servicio, en nuestro caso por el Servidor FTP de Windows Server.
o Podemos ver los Detalles del Certificado

6
 o A continuación, ya con nuestro Certificado listo, solo nos queda reconfigurar el Servicio FTP de
Windows Server para que trabaje con el Certificado Digital y pueda cifrar las comunicaciones para que
están sean ahora seguras, igual que hicimos en Linux.
o Desde la utilidad Configuración SSL de FTP, realiza este proceso para ahora TODAS las
conexiones FTP sean seguras utilizando el Certificado Digital que acabamos de Emitir por la CA

o Probamos el acceso desde Filezilla (Solo conexiones TLS)

o Resuelve adecuadamente por FQDN a través del Servidor DNS de Windows Server:
ftp.etgXX.es

o Comprueba las conexiones FTP mediante Filezilla de TODOS los usuarios de la práctica anterior
verificando que los permisos son correctos y que los usuarios estén enjaulados.

o Comprueba en Wireshark que tanto en el proceso de Autenticación de las credenciales de

usuario como en el proceso de transferencia de archivos su contenido no se ven en texto claro.

UD5 Servidores Web (http / https)

El protocolo HTTP

HTTP (Hyper Text Transfer Protocol), protocolo de transferencia

de hipertexto, es un protocolo de Capa Aplicación que permite
acceder a información hipermedia en equipos remotos.
Es un servicio basado igual que los anteriores, en el Modelo
Cliente/Servidor y constituye la base de la WWW (world wide
web o simplemente web).

El protocolo fue desarrollado por el CERN (Centro Europeo de

Investigación Nuclear) en 1989 y actualmente su desarrollo y evolución
está controlado por el Organismo W3C (Worl wide web Consortium), comunidad internacional que crea
estándares web (como por ejempo XHTML, CSS, XML) http://www.w3c.es

Con la publicación de la versión 1.1 de HTTP, Tim Berners-Lee estableció la primera comunicación entre
un cliente y un servidor usando el protocolo HTTP en 1989.

Se le considera el padre de la Web.

Componentes
Agente de usuario: Al cliente que efectúa la petición a través de un navegador web u otro programa
se le conoce como "user agent" (agente de usuario).

Servidor web: Atienden las peticiones de los clientes web y les envían los recursos solicitados.

Recursos. Documentos, vídeos, imágenes, audio, aplicaciones, buzones de correo, etc.

accesibles a través hipervínculos y transmitidos desde el Servidor web.

Protocolo HTTP. Conjunto de normas y reglas en base a las cuales “dialogan” los clientes, los
servidores web y los proxies. Usa TCP como protocolo de transporte y como puerto estándar el 80.

URI/URL. A la información transmitida se la llama recurso y se le identifica mediante un "URL"

(Localizador uniforme de recursos). El acceso a otros recursos desde una misma página se realiza a
través de hipervínculos o hiperenlaces (hiperlinks o simplemente links).

Cookies. HTTP es un protocolo sin estado, es decir, que no guarda información sobre conexiones
anteriores. El desarrollo de aplicaciones web necesita frecuentemente mantener estado. Para esto se
usan las cookies, que es información que un Servidor puede almacenar en el Cliente.
Más sobre cookies https://blog.ensalza.com/politica-de-cookies/
https://ayudaleyprotecciondatos.es/2018/03/05/guia-uso-cookies/#Que_son_las_Cookies

Proxy web. Programas intermediarios entre clientes y servidores web. Pueden actuar como
cortafuegos y/o almacenar datos en cache para aumentar el rendimiento.

1
 Diferencias Web Proxy vs VPN:
Web proxy vs VPN https://computerhoy.com/noticias/internet/proxy-vs-vpn-que-diferencias-hay-80107

Características de un servidor Proxy:

o Enmascara la IP original
o Protege solo el acceso a un programa específico
o Es más fácil configurarlo
o Generalmente más barato que el VPN

Características de un VPN:
Cifra y protege la totalidad de tu tráfico, no solo el de un programa
También enmascara la IP original
Es también sencilla de configurar
En general es algo más cara que un servidor Proxy

Tecnologías web. Utilizadas para desarrollar aplicaciones basadas en la Web (XHTML, CSS, XML,
Ajax, XQuery, Xpath, etc.)

Páginas web dinámicas . Páginas que precisan de otros servicios y programas (Gestor de Base de
Datos, Lenguaje del lado del Servidor tipo PHP, JSP) para realizar sus peticiones del cliente
completas. Por ejemplo, cuando un usuario quiere realizar una compra o hacer una reserva en un
hotel, se precisa consultas y modificaciones en las bases de datos del Servidor.

Páginas web, sitios web y aplicaciones web

Pagina web. Es un documento hipermedia o conjunto de información electrónica relacionada (texto, audio,
imágenes, video, etc) que normalmente contiene hipervínculos a otras páginas web o recursos.

Las páginas web están escritas en distintos lenguajes, HTML, XHTML, CSS, Javascript, flash, applets,
que son interpretados y/o ejecutados por los navegadores. Para algunos de estos componentes de
código se precisan extensiones instaladas en los navegadores (JVM, plugin flash, etc).

Su contenido puede ser estático (almacenado en un Servidor web) o dinámico (se genera en el servidor
web al ejecutar un conjunto de instrucciones de un determinado lenguaje, ej., PHP).

2
Sitio web. Es un conjunto de páginas web relacionadas y accesibles a partir de un mismo nombre de dominio DNS o IP.
Dicho colección de archivos se almacenan en el Servidor web en un directorio por defecto:
SS: En el caso del Servidor Web Apache en /var/www/html
TT: En el caso de Windows Server en: C:/inetpub/wwwroot/

Aplicación web. Aquella donde el usuario interactúa con un navegador que accede a los servicios y
recursos que ofrece un servidor web (por ejemplo, un buscador, una tienda electrónica o
e-commerce, un cliente de correo web, una suite ofimática en la nube tipo Drive de Google o Onedrive de
Microsoft (cloud computing).

Servidores web
Los servidores web o HTTP son los programas que atienden las peticiones web/http, procesan e
interpretan el código escrito en diferentes lenguajes y envían a los clientes los recursos solicitados.

Los recursos pueden estar localizados en el mismo equipo donde se ejecuta el Servidor o en otros equipos de la red.

Por defecto, el servidor http escucha en el puerto 80/TCP

Por defecto, el servidor https (http en modo cifrado) escucha en el puerto 443/TCP

Los principales servidores web del mercado: Cuota de mercado de Servidores web:

Apache http server http://httpd.apache.org/

Nginx http://wiki.nginx.org/Main
IIS (Internet Information Server) de Microsoft https://www.iis.net/overview

Fuente: https://w3techs.com/technologies/overview/web_server
Enero 2019 Enero 2020

3
Servidor de aplicaciones web
Es un software que ofrece diferentes contenedores en los que se ejecutan distintos componentes que
interactúan entre sí para proporcionar un servicio a una empresa.

Entre los contenedores siempre suele existir un contenedor Web que recibe peticiones HTTP, FTP, etc.

Además suelen existir más contenedores que ejecutan otros componentes, basados en la mayoría de los
casos en la tecnología J2EE (Java Enterprise Edition).

Ejemplos de Servidores de Aplicaciones:

GlassFish https://glassfish.java.net/
Jboss http://www.jboss.org/
WebSphere https://www.ibm.com/es-es/marketplace/java-ee-runtime . IBM WebSphere Application
Server proporciona un rango de entornos de ejecución Java EE 7 seguros y flexibles, disponibles en
local o en cualquier cloud público, privado o híbrido.
Geronimo. http://geronimo.apache.org/

Clientes web / Navegadores web

Programas que es usado por los clientes para acceder a los recursos de la Web. Pueden actuar
como clientes de diferentes protocolos (como http, https, ftp, smb, etc).

Aunque la W3C crea estándares para tecnologías web, los navegadores, en determinados aspectos, no
cumplen completamente los estándares. Esto supone un problema para los desarrolladores de aplicaciones
web que tienen que adaptarlas para que se muestren y funcionen correctamente en varios navegadores,
incluso entre diferentes versiones de un mismo navegador

- Navegadores habituales: Mozilla Firefox, Konqueror, Google Chrome, Safari, Opera, Edge, etc
- Algunos navegadores en modo texto: Lynx, www-browser, links, etc.

4
Proxy Web
En el ámbito de las redes un proxy hace referencia a un programa que actúa como intermediario de otro.
Sus funciones son diversas y de ahí derivan sus nombres.

Un proxy Web o proxy HTTP/HTTPS hace de intermediario entre un Cliente web y un Servidor web.

Según el comportamiento y la función que realizan pueden ser proxy directos o inversos.

o Proxy directo (forward proxy). Recibe la petición iniciada por un cliente web y se la traslada al
Servidor web. La solicitud del cliente (URL) es hacia el Servidor web no hacia el Proxy, éste solo
hace de intermediario o representante del cliente.
#Usado para optimizar y filtrar los accesos (contenidos, hosts) a Internet por parte de una
empresa u organización.
# Aparte de la función anterior, de filtrado, también nos puede proporcionar la función de proxy-caché. En este caso,
se mantiene un espacio en disco compartido que actúa de caché compartida por múltiples usuarios con la
consiguiente mejora en los tiempos de acceso para consultas coincidentes y reduciendo tráfico de red externo.

Si la página no ha cambiado desde que se cargó en caché la devuelve inmediatamente,

ahorrándose mucho tráfico dado que solo envía un paquete por la red para comprobar la versión. Si la
versión es antigua o simplemente no se encuentra en la caché, lo solicita al servidor remoto, lo devuelve al
cliente que lo pidió y guarda o actualiza una copia en su caché para futuras peticiones.

Ejemplo de Servidor Proxy Web:

Linux: Squid http://www.squid-cache.org/

Windows: WinGate

Usos derivados/ventajas de los proxy-web

# Reducción del tráfico
# Mejora de la velocidad
5
 Filtrado de contenido
Esconder al Servidor Web la identidad del que solicita cierto contenido. (Sólo la verá el proxy-web)
Control de accesos. Permite recopilar info sobre qué hosts acceden a qué sitios.
Volumen de datos generados por qué hosts/subred y en qué momento, etc .
Los proxies web, pueden ser transparentes, esto, es una combinación de un servidor proxy con un
Cortafuegos de manera que las conexiones son interceptadas y desviadas hacia el proxy sin necesidad de
configuración en el cliente, y habitualmente sin que el propio usuario conozca de su existencia. Este tipo de
proxy es habitualmente utilizado por las empresas proveedoras de Acceso a Internet.

o Proxy inverso (reverse proxy). Es un servidor proxy situado en el alojamiento de uno o más
servidores web. Todo el tráfico procedente de Internet y con destino en alguno de esos servidores
web es recibido por el servidor proxy.
En este caso, la solicitud del cliente (URI) es hacia el proxy (aunque para los clientes sea en
apariencia un servidor web normal).
Hay varias razones para ello:
o Seguridad: el servidor proxy es una capa adicional de defensa a nuestros Servidores Web,
primero por que ocultamos la tecnología y las características de los Servidores detrás del proxy
eliminando el acceso directo desde Internet hacia ellos.
Podemos ademas hacer uso de módulos de Apache por ejemplo, para inspeccionar el tráfico como son el WAF
(Web Application Firewall) o el ModSecurity para bloquear cualquier request malicioso, o el ModEvasive para los
ataques DOS, y muchos controles para reducir las posibilidades de una posible intrusión.
- Se suele ubicar en la DMZ.

o Cifrado / Aceleración SSL : cuando se crea un sitio web seguro, habitualmente el cifrado SSL no lo hace el mismo
servidor web, sino que es realizado en un equipo ajeno equipado incluso con hardware de aceleración SSL/TLS.
o Distribución o Balanceo de Carga : el proxy puede distribuir la carga entre varios servidores web. En
ese caso puede ser necesario reescribir la URL de cada página web (traducción de la URL externa a
la URL interna correspondiente, según en qué servidor se encuentre la información solicitada).
o Caché de contenido estático : Un proxy inverso puede descargar de trabajo a los servidores web
almacenando contenido estático como imágenes u otro contenido gráfico. También puede
almacenar contenido generado dinámicamente pero que pueda ser en alguna medida reutilizable.

6
Un ejemplo típico de una implementación con Proxy Inverso (reverse proxy)

Más info: https://httpd.apache.org/docs/trunk/es/howto/reverse_proxy.html

7
Protocolo HTTP
Protocolo de comunicación en la Web, que utiliza el protocolo TCP como protocolo de transporte que determina los
tipos de peticiones que los clientes pueden enviar, así como el formato y estructura de las respuestas.

Desde su desarrollo en 1989, ha pasado por varias versiones:

HTTP/0.9 - Obsoleta
HTTP/1.0 -
HTTP/1.1 - Versión más usada actualmente
HTTP/2 – Borradores surgen en Mayo 2015

Funcionamiento básico de una petición Cliente a un Servidor HTTP

o El usuario introduce una URL en la barra de direcciones del navegador o cliquea sobre un
hipervínculo.

oEl navegador analiza la URL si se ha utilizado un nombre DNS previamente invoca al resolver DNS para que
le resuelva el nombre por una IP, y si no se indica el número de puerto se conectará al puerto 80 del Servidor
y se establece una conexión TCP con el servidor web.

o Cuando se ha establecido la conexión TCP, el navegador envía un mensaje HTTP de petición que depende del
URL.

o El Servidor envía un mensaje de respuesta que depende de la petición enviada y del estado del
servidor.

o Se cierra la conexión TCP automáticamente.

Mensajes HTTP de petición

Están formados por 3 partes:

o Línea inicial de petición, incluye:

Método utilizado (GET,POST..)
URL, y si la conexión se establece con un servidor proxy.
Versión del protocolo. Actualmente la más utilizada es la HTTP 1.1
o Línea/s de cabecera:
Conjunto de pares de nombre/valor, denominados cabeceras, que determinan cómo será
procesada la petición por parte del Servidor. Cada cabecera se indica en una línea.
Por ejemplo, la cabecera Accept: text/html indica que el navegador es capaz de procesar código
HTML.
Si no hay cabecera se envía un 0.
o Cuerpo del mensaje (opcional). Contiene parámetros o ficheros a enviar al Servidor.
Ejemplo de mensaje que es enviado por un Cliente a un Servidor HTTP
8
Mensaje HTTP de Respuesta
Están formados por 3 partes:

# Línea inicial de respuesta (línea de

estado) Versión HTTP utilizada
Código de estado o código de error que informa al Cliente de cómo ha sido procesada
la petición. Algunos ejemplos:
Código 200: Petición se ha procesado correctamente y que el recurso se envía al cliente
Código 404: No found. Un clásico. Recurso no
encontrado. Texto explicativo del código de estado
# Línea/s de cabecera
Conjunto de pares nombre/valor denominados cabeceras que describen los datos y la forma
en que son enviados al cliente. Cada cabecera en una línea.
Ejemplo:
la cabecera Content-Type: text/html indica que se envía código HTML que deberá interpretar el
navegador. Si no hay cabeceras se envía un 0.

# Cuerpo del mensaje (opcional). Queda determinado por el tipo de recursos solicitado.
Ejemplo de mensaje de Respuesta que es enviado por el Servidor HTTP a un cliente ante una petición de un recurso

Autenticación HTTP
La autenticación que ofrece HTTP no es segura y por ello la autenticación se traslada a las aplicaciones web. En las
aplicaciones web actuales la autenticación se basa en el uso de formularios XHTML en los que se introducen usuario y
clave que son enviados al servidor (usando parámetros de los métodos GET o POST), donde son tratados por alguna
aplicación escrita en un lenguaje como PHP, JSP, ASP, Ruby, etc. o en el uso de Certificados Digitales y HTTPS.

Seguridad
HTTP no es un protocolo seguro:

o El intercambio de información se realiza en texto plano. Es vulnerable a ataques de análisis de tráfico de red
(sniffing).

o Los mecanismos de autenticación (Basic, Digest) no son seguros.

oNo se usan mecanismos para garantizar que los equipos involucrados en la transferencia son quienes
dicen ser. Es vulnerable a ataques de suplantación de identidad (spoofing y man-in-the-middle)

-Existen ataques basados en el robo o falsificación de cookies y/o parámetros enviados en la URL o en el
contenido de los mensajes, y que permiten al atacante "robar la identidad de un usuario y suplantarle en
webs" (bancos, webmails, redes sociales, etc).

Busca info en Internet sobre 2 ataques web muy extendidos, XSS y SQL Injection.

9
Sistema criptográfico
El sistema criptográfico es un conjunto de operaciones que permiten transmitir info de forma privada y
segura entre emisor y receptor.
El mecanismo de cifrado consiste en aplicar un algoritmo sobre un texto en claro de forma que se
obtenga otro compuesto por letras y símbolos que solo el receptor pueda leer.

Los dos métodos de cifrado son:

oClave asimétrica: Es el sistema que utiliza la misma clave tanto para cifrar como para descifrar
el mensaje. Previamente, esta debe ser compartida entre emisor y receptor.
Ventaja: Su velocidad en el cifrado/descifrado

Inconveniente: la clave al viajar en texto claro puede ser interceptada por un intruso.

oClave asimétrica. Procedimiento que corrige el inconveniente anterior y sin embargo pierde la ventaja
también del anterior siendo un proceso más lento. En este método, se utilizan 2 claves: una pública que se
puede enviar a todos los usuarios, y otra privada, que su propietario debe mantener en secreto y protegida.
Las 2 claves son complementarias, es decir, lo que se cifa con una solamente lo puede descifrar la otra y viceversa.

Su principal ventaja es que, como solo se transmite la clave pública, aunque ésta sea interceptada, las
transmisiones seguras no se verán compremetidas.

Inconveniente: proceso muy lento.

Los dos elementos básicos utilizados por este sistema de cifrado son el Certificado Digital y la Firma electrónica.

Método de Clave Simétrica Método de Clave Asimétrica

10
El protocolo HTTPS
El protocolo HTTPS o HTTP Secure es un protocolo que utiliza SSL (Secure Sockets Layer) o en TLS (Transport
Layer Security) para encapsular mensajes HTTP y establecer conexiones serguras entre Cliente y Servidor.

Como vimos en la práctica de FTPS o FTP bajo TLS, gracias a la utilización de algoritmos criptográficos y
Certificados Digitales se puede garantizar, la Confidencialidad y la Integridad de la información transmitida,
así como la Autenticidad de los servidores. Aunque no se puede hablar de una seguridad completa, el uso
de certificados digitales en las transmisiones dificulta mucho su desencriptado de forma fraudulenta.

Uso en el URL: https://

Puerto por defecto: 443/tcp

En la actualidad todos los sitios o sites que manejan información personal y/o confidencial de los usuarios
(emails, redes sociales, bancos, comercio electrónico, etc) usan HTTPS (o lo deberían hacer).

El proceso de cifrado mediante claves asimetricas es muy lento, por lo que no se aplica para cifrar páginas
web. En su lugar, HTTPS emplea una combianción de algoritmos de clave asimétrica (SSL) y simétrica (TLS).

14. Para preparar un Servidor Web que acepte conexiones HTTPS, el administrador debe crear un certificado de
clave pública para el servidor web. Este certificado debe estar firmado por una Autoridad de Certificación
(Certification Authority, CA) para que el navegador web lo acepte y no desconfie de nuestro site.

15. La autoridad CA certifica que el titular del certificado es quien dice ser.

16. Los navegadores web generalmente son distribuidos con los certificados raíz firmados por la mayoria
de las autoridades de certificación por lo que estos pueden verificar certificados firmados por ellos.

Ejemplo de
Autoridades Certificadoras
incluidas en un Navegador:

8) Existe una CA administrada por la comunidad que otorga gratuitamente Certificados de clave
pública, CAcert (http://www.cacert.org/).

9) Ejemplo de un site seguro https://es.wikipedia.org y los datos de su Certificado y la Autoridad

Certificadora (DigiCert Inc) que “certifica” quien dice ser:

11
Detalle del Certificado
usado por Wikipedia.org

12
5) Actualmente la mayor parte de las empresas que ofrecen sus Servicios de Web Hosting
incluyen ya un Certificado en el Servidor para el Cliente que contrata dicho servicios.

Ejemplo: https://www.strato.es/hosting/

Las organizaciones pueden también ser su propia Autoridad de Certificación, particularmente si son
responsables de establecer acceso a navegadores de sus propios sitios (por ej, sitios en una
compañía Intranet, o Universidades). Estas pueden fácilmente agregar copias de su propio certificado
firmado (autofirmado) a los certificados de confianza distribuidos con el navegador.

Usar Certificado como control de acceso.

El sistema puede también ser usado para la autenticación de clientes con el objetivo de limitar el acceso a un
servidor web a usuarios autorizados. Para hacer esto el administrador del sitio típicamente crea un Certificado
para cada usuario, un certificado que es guardado dentro de su Navegador web. Normalmente, este contiene el
nombre y la dirección de correo del usuario autorizado y es revisado automáticamente en cada reconexión para
verificar la identidad del usuario, potencialmente sin que que cada vez tenga que ingresar una contraseña.

13
 Ejemplo de acceso a un site mediante el uso de DNI electrónico

Funcionamiento SSL/TSL

Con el protocolo HTTPS, el servidor se autentica frente al cliente mediante el Certificado digital de
Clave Pública, mientras que el cliente lo hace puede hacer a través de un usuario y una contraseña.

El procedimiento es el siguiente:

La primera vez que el cliente contacta con el servidor este último le envía, mediante su certificado
(actualmente X.509), la Clave Pública.

Más info Certificado X.509 https://es.wikipedia.org/wiki/X.509

El cliente acepta dicha clave y genera otra clave simétrica llamada master secret (posiblemente usando
el protocolo criptográfico Diffie-Hellman) de forma aleatoria.

El cliente cifra un nombre de usuario y una contraseña para acceder al servicio web mediante la
clave simétrica generada.

El cliente cifra la clave simétrica con la clave pública del servidor. Para ello utiliza el sistema de criptografía asimétrica.

Se transmiten al servidor tanto el usuario y la contraseña cifrados como la clave simétrica cifrada.

El servidor descifra la clave simétrica a través de su Clave Privada.

La clave simétrica permite descifrar el nombre de usuario y la contraseña que han viajado cifrados a través de la red.

El servidor comprueba si el usuario tiene acceso al servicio web. En caso afirmativo, la conexión se habrá
completado. A partir de este momento, cifrará las páginas web con la clave simétrica antes de transmitirlas y
el cliente, una vez las reciba, podrá descifrarlas usando esta misma clave.

El protocolo HTTPS es rápido y seguro porque aporta la rapidez del cifrado asimétrico y aumenta su
seguridad, ya que, gracias al cifrado asimétrico, la clave simétrica es transmitida entre el cliente y el
servidor sin comprometer su confidencialidad.
14
El protocolo también permite que el cliente se autentique usando sus propias claves asimétricas en vez del
usuario y la contraseña.

Repasa el funcionamiento de SSL/TLS

https://aulavirtual32.educa.madrid.org/ies.tiernogalvan.parla/pluginfile.php/7902/mod_resource/content/2/
Comunicaciones%20seguras%20con%20TLS.pdf

15
Alojamiento virtual de sitios web (web virtual hosting)
http://httpd.apache.org/docs/2.4/vhosts/

Consiste en simular que existen varias máquinas con sus respectivos sitios
web sobre un solo Servidor web, es decir, alojar varios sitios web (por
ejemplo, www.smr.es, www.asir.es, www.dam.es) en un mismo servidor.

También se usan los términos hosts virtuales, servidores virtuales

y sitios virtuales para referirse a este tipo de configuración.

El uso de servidores web virtuales permite reducir el número de hosts

físicos necesarias.

Se pueden diferenciar 3 tipos de alojamiento virtual:

1. Alojamiento virtual basado en IPs

El servidor tendrá diferentes direcciones IP por cada servidor web virtual.

o Cada servidor virtual atenderá peticiones en una dirección IP diferente.

oPara esta configuración, la máquina, donde se ejecuta el servidor web, debe tener varias tarjetas de red
configuradas cada una con una dirección IP o hay que asignar varias direcciones IP (alias o interfaces
virtuales) a una misma tarjeta de red.

Ejemplo, creación de Interfaces virtuales en Debian

o Static IP address
auto enp0s3
iface eth0 inet static address
192.168.1.100 netmask
255.255.255.0 network
192.168.1.0 broadcast
192.168.1.255 gateway
192.168.1.1

o Virtual interface
o Static IP address
auto enp0s3:0
iface enp0s3:0 inet static
address 192.168.1.101
netmask 255.255.255.0
Ejemplo, distintos dominios sobre distintas IPs en un mismo Servidor Web:
http://www.site1.com o http://198.10.20.100
http://www.site2.com o http://198.10.20.101

2. Alojamiento virtual basado en nombres

El servidor permite alojar varios nombres de dominio sobre la misma dirección IP.

Cada servidor virtual atiende las peticiones de un nombre de dominio.

Este tipo de alojamiento se permitió a partir de HTTP 1.1. El servidor web es capaz de diferenciar el nombre
de dominio por el que pregunta el cliente porque en el mensaje de petición HTTP se envía la cabecera Host
con el nombre de dominio.

16
Es la forma de alojamiento más habitual, ya que reduce el uso de las IPs y simplifica y facilita la administración
centralizada de los servidores. La mayoría de las empresas que ofrecen servicios de web hosting (alojamiento web) en
Internet se basan en este tipo de alojamiento virtual basado en nombres. Nos dan espacio y recursos en un servidor
web virtual que asocian con nuestro nombre de dominio. De forma que una misma IP pueden alojar cientos de dominios.

Ejemplo:

http://www.site1.com o http://198.10.20.100
http://www.site2.com o http://198.10.20.1 00
El Servidor Web analizando el parámetro host de la Cabecera sabrá distinguir un dominio de otro

3. Alojamiento virtual basado en puertos.

Cada servidor virtual atiende peticiones en una dirección IP y/o dominio: puerto diferentes.

Consiste en combinar el alojamiento basado en IP y/o nombre con el uso de varios puertos a la escucha.

Ejemplo:

http://www.smr.es:80
http://www.asir.es:8080
http://www.dam.es:80

o En un mismo Servidor web se pueden combinar entre los distintos tipos de alojamiento virtual.
o El servidor web Apache admite los 3 tipos de alojamientos comentados.

Veamos los casos de configuración de hosts virtuales (VirtualHost) más habituales en Apache:

17
EJEMPLOS DE TIPOS DE VIRTUALHOTS
http://httpd.apache.org/docs/2.4/vhosts/examples.html

Ejemplo 1: VirtualHost basado en Nombres

http://httpd.apache.org/docs/2.4/vhosts/name-based.html

El Servidor tiene una única dirección IP y varios alias (CNAME) que apuntan a esa misma máquina en DNS.

Se desea ejecutar un Servidor web para www.example.com y other. example.org en esta máquina.

Notas:
Los asteriscos referencian a cualquier IP.
Al escribirse primero el virtualhost www.example.com tendría la prioridad más alta y es el predeterminado o
principal. Esto es, si se recibe cualquier solicitud que no coincida con una de las directivas ServerName
especificadas, será servida por este primer VirtualHost.
Se puede reemplazar “*” por la dirección IP real del sistema. En este caso el argumento VirtualHost debe
coincidir con el argumento NameVirtualHost

Ejemplo 2: VirtualHost basado en IP

http://httpd.apache.org/docs/2.4/vhosts/ip-based.html

El Servidor tiene 2 IPs (172.20.30.40 y 172.20.30.50) y se quiere asociarlas a 2 dominios distintos

(www.example.com, www.example.org) con distinto contenido.

18
Ejemplo 3 VirtualHost basado en puertos

El Servidor tiene una única IP, y queremos servir distintos contenidos web asociados a distintos
dominios utilizando puertos distintos (80, 8080).

Ejemplo 4: Configuración de Apache, para servir el mismo contenido en diferentes direcciones IP (como
una dirección interna y otra externa).

El servidor tiene 2 IPs (192.168.1.1 y la 172.20.30.40)

El servidor está ubicado entre una Red Interna y una Red Externa.
Para la Red Externa el nombre server.example.com resuelve a la dirección externa
172.20.30.40 Y para la Red Interna ese mismo nombre se resuelve en la IP interna 192.168.1.1
El servidor se configura para que responda a las Solicitudes tanto Externas como Interna
con el mismo contenido, con una sola sección VirtualHost.

En la Red Interna se puede usar el alias "server" en lugar del nombre completo del host server.example.com En
la lista de direcciones IP se pueden reemplazar por "*" que hará que el servidor responda en todas las
direcciones IP que tenga.

19
Ejemplo 5: VirtualHost mixto basado en IP y basado en Puertos
En este caso, tenemos: el servidor tiene 2 direcciones Ips
172.20.30.40 asociado a www.example.com en los puertos de escucha 80 y 8080
172.20.30.50 asociado a www.example.org en los puertos de escucha 80 y 8080

Ejemplo 6: VirtualHost mixto basado en IP y basado en Nombres

20
Control de acceso: Permisos en Apache
https://httpd.apache.org/docs/2.4/es/howto/access.html

Anteriormente a la versión 2.4 de Apache, era posible definir IPs/ nombres de dominio que pudieran acceder
a un recurso del servidor utilizando las directivas Order, Allow y Deny dentro de las secciones <Directory>,
<Fle>, etc. Aunque estas directivas siguen pudiendo utilizarse gracias a un módulo de compatibilidad, han
sido reemplazadas por las directivas Require, RequireAll, RequireAny y RequireNone.

Cuando se realiza la conexión desde un Cliente web, el servidor comprueba si el acceso al recurso está autorizado.
Si la solicitud está autorizada devuelve el recurso.
Si no, devuelve un código de error 403 Forbbiden

Control de acceso por host (IP/nombre)

Directivas:
Require host <nombreHost>
Require ip <direccion_ip>

En la primera línea, <nombreHost> es el FQDN de un nombre de dominio (o un nombre parcial del

dominio); puede proporcionar múltiples direcciones o nombres de dominio, si se desea.

En la segunda línea, <direccion_ip> es la dirección IP, una dirección IP parcial, una red con su
máscara, o una especificación red/nnn CIDR. Pueden usarse tanto IPV4 como IPV6.

Ejemplos:

En formato CIDR

Usando IPv6

Por nombres, los hosts cuyo nombre terminan en las siguientes cadenas estarían autorizados:

21
En el siguiente ejemplo, estar autorizado el equipo localhost

Se puede hacer uso de ‘not’ para negar un argumento y por tanto, autorizara los que NO cumplan esa condición.

RequireAll. Agrupa condiciones, de forma que, autorizara el acceso a aquellos que cumplan todas las
condiciones incluidas.

Ejemplo: Permitira a todos excepto a la IP especificada

RequireAny. Agrupa condiciones, de forma que, autorizará el acceso a cualquiera que cumpla alguna
de las condiciones especificadas.
Ejemplo: Permitira a los usuarios que pertenezcan al grupo ‘sales’ o bien a los autenticados a través de
LDAP del departamento ‘sales’

- Aquí no se permite la clausula ‘not’

RequireNone. Agrupa condiciones, de forma que, autorizará el acceso si ninguna de las condiciones
especificadas se cumple.

Ejemplo: Para permitir el acceso, el usuario no debe pertenecer ni al grupo de ‘temps’ ni a los grupos
LDAP de ‘Temporary’ ni a ‘Employees’.

Entre ellas, también se pueden anidar.

Ejemplo: Para acceder al recurso ‘/www/mydocs’, el usuario debe ser el ‘superadmin’ o pertenecer tanto al
grupo ‘admins’ y al grupo LDAP de Administradores y pertenecer al grupo de ‘sales’ (ventas) o tener ‘sales’
de atributo de departamento de LDAP. Además, para acceder al recurso, el usuario no debe pertenecer ni al
grupo de ‘temps’ ni a los grupos LDAP de ‘Temporary’ ni a ‘Employees’.

22
UD5 Servicio Web (HTTP, HTTPS)
Práctica ud5p1: "IIS (Internet Information Services) de Microsoft"
IIS es un software que incluye un servidor web junto a otros servicios adicionales para el sistema de Microsoft de
Windows principalmente de la versión Server, aunque existen versiones limitadas para otras versiones.

Los servicios que incluye son: FTP, SMTP, NNTP, HTTP/HTTPS.

IIS se basa en el uso de distintos módulos que le permiten tener la capacidad de procesar distintos tipos
de contenido web. Por ejemplo, incluye ASP (Active Server Pages) y ASP.NET. Aunque también pueden
ser incluidos otros módulos de otros fabricantes como PHP o Perl.

Caso práctico
Instalación de IIS en la MV winServidorXX del Laboratorio, para ello tendrás como recursos:

- Enlaces externos de Microsoft:

Instalación IIS en Server
https://www.iis.net/learn/install/installing-iis-85/installing-iis-85-on-windows-server-
2012-r2 Administrar un website con IIS en Server
https://technet.microsoft.com/es-
es/library/hh831515%28v=ws.11%29.aspx Mas info:
https://www.iis.net/learn/get-started/whats-new-in-iis-85

Sitio Web

Un sitio es un contenedor de aplicaciones web al que se puede obtener acceso a través de uno o
varios enlaces únicos.

Un enlace de sitio web es la combinación de una dirección IP, un puerto (expresado como nombre DNS,
ejemplo www.misitio.com:80 o normalmente www.misitio.com) en los que el Servidor web realiza
escuchas de las solicitudes realizadas a ese sitio web.

Directorios virtuales
o Un directorio virtual es un nombre de directorio que se especifica en IIS y se asigna a un
directorio físico en un servidor local o remoto.

o El nombre de directorio pasa a formar parte de la dirección URL de la aplicación y los usuarios pueden
solicitar la dirección URL desde un navegador web para obtener acceso al contenido del directorio físico,
como una página web o una lista de directorios y archivos adicionales. Si específica para el directorio virtual
otro nombre que para el directorio físico, les resultará más difícil a los usuarios detectar la estructura real de
los archivos físicos en su servidor porque la dirección URL no está asignada directamente a la raíz del sitio.
Se pide:
o Instalación de IIS (Servicio WEB)-> Característica “Servidor web”
Nos creará la estructura de directorios C:/inetpub
Desde la herramienta administrativa para el IIS tendremos ahora la posibilidad de gestionar nuestros
sitios web, agrega dicho complemento a la consola MMC de trabajo de prácticas anteriores.

No modifiques las opciones por defecto de instalación.

Trás la instalación accede a la Herramienta de Administración IIS o a través de tu Consola
MMC - IIS se configura editando propiedades en la consola de administración:
Existen 4 niveles de administración en IIS que son aplicables a los 4 servicios (HTTP, FTP, SMTP, NNTP):
Administración en el nivel del Servidor
Administración en el nivel del Sitio
Administración en el nivel del Directorio
Administración en el nivel de los archivos
UU: Las tareas básicas se pueden realizar con los asistentes, pero para configurar
aspectos avanzados hay que utilizar las ventanas de propiedades de los sitios, directorios,
…
Los parámetros configurados para un Objeto (servidor físico o virtual, directorio físico
o virtual o archivo) los heredan (si es aplicable) de manera automática los objetos de
los niveles inferiores.
- Estos parámetros heredados se pueden sobrescribir en cualquiera de los niveles inferiores.
- Se pueden configurar como se heredan las propiedades con la herramienta “Delegación de características.

Pincha sobre el nombre del equipo en la parte izquierda, observa que en la parte central aparecen
las opciones de configuración globales del servidor Web IIS (que se aplicarán a todos los sitios Web
creados). Cada sitio Web hereda las configuraciones globales y puede sobrescribirlas.
 Crea un nuevo Sitio Web, llamado “webies” con las siguientes parámetros
Nombre sitio: miweb_Red_XX
Ruta acceso física: C:\inetpub\wwwroot\miweb
Enlace: HTTP, IP: 10.X.0.5, puerto 80
Nombre del host: www.etgXX.es
Crea un fichero index.html dentro de la ruta anterior con el siguiente contenido web:

- Creación de Directorios Virtuales.

Un directorio virtual es un directorio del servidor que no está dentro del directorio de publicación
habitual, es decir, un directorio que no depende de C:\Inetpub\wwwroot pero que sí que se puede
acceder a través del servidor web como si estuviera dentro de dicho directorio.

Crea los siguientes Directorios virtuales con la siguiente configuración:

Directorio Directorio físico URL acceso al directorio Permisos
Virtual virtual

SMR C:/Users/Administrador/Documents/smr http://www.etgXX.es/smr Lectura y ejecución

DAM C:/Users/Administrador/Documents/dam http://www.etgXX.es/dam Lectura y ejecución

ASIR C:/Users/Administrador/Documents/asir http://www.etgXX.es/asir Lectura y ejecución

 o Creación de páginas Web básicas personalizadas para cada Sitio

Web: Nota: donde dice "profe" especifica tu Nombre y Apellidos

Servidor Web con Sitios Web SEGURO (HTTPS)

# Vamos a cifrar dichos servicios mediante el uso del TLS que nos facilita Microsoft, a través de la
creación de los Certificados digitales.
En este caso, para ello crea un nuevo Certificado Digital de Clave Publica mediante una Solicitud de
Certificado hacia una Entidad Certificadora que crearemos en nuestro Servidor, éste se encargara de
emitir el Certificado que será el que utilizaremos en nuestros sites.
De forma que debemos habilitar los siguientes sites bajos SSL mediante el uso del
Certificado: https://www.etgXX.es
https://www.etgXX.es/asir
https://www.etgXX.es/smr
https://www.etgXX.es/dam

Evaluación de la práctica.
La práctica será evaluada en el Aula de la siguiente manera:

o El profesor deberá acceder a través de la Red Física del Aula a los Servidores IIS de cada
alumno mediante el uso de un Navegador web.
Para ello, el alumno deberá tener correctamente configurado los Servidores DNS y IIS con los
Sitios Web pedidos.
o No se pide documentación escrita para esta práctica.

El alumno deberá facilitar al profesor los siguientes datos:

o IP de la enp0s3 de su MV debianServidorXX (Router de la Red Interna del Laboratorio

del alumno) en el momento de la Evaluación (dado que es por DHCP y
pudiera cambiar), para agregar la Ruta de la Red
Interna del alumno al ordenador del Profesor.

o IP de la MV winServidorXX.etgXX.es con el Servidor

DNS del alumno, para que resuelva correctamente
los nombres de los Sitios Web del alumno.

o Nombres DNS completos de los sitios web

creados para los siguientes tests:
o Conexiones inseguras HTTP
http://www.etgXX.es
 http://www.etgXX.es/asir
http://www.etgXX.es/smr
http://www.etgXX.es/dam

o Conexiones seguras HTTPS

https://www.etgXX.es
https://www.etgXX.es/asir
https://www.etgXX.es/smr
https://www.etgXX.es/dam

UD5 Servidor Web (HTTP)

Práctica: "ud5p2 Servidor Web Apache 2.4 en Linux"
Objetivos:
Configurar y administrar un Servidor Web Apache en Linux: Directorios Virtuales. Autenticación básica y permisos.
Recursos:
Laboratorio, Recursos del Aula Virtual e Internet
Documentación de Apache: http://httpd.apache.org/docs/2.4/
Guía rápida directivas Apache: https://httpd.apache.org/docs/2.4/mod/quickreference.html
Software libre:
Linux Debian, Apache, webmin

- Instalación de Apache 2
Realiza una instantánea de tu MV antes de realizar la práctica.
http://httpd.apache.org/

Realiza la instalación del servicio web de apache en la máquina virtual debianClienteXX. Apache es el servidor
web más popular y usado en Internet, pudiéndose instalar en múltiples SOs (Linux, Unix, Windows, MAC, ..).

o apt-get update
o apt-get install apache2

El servidor web Apache tiene múltiples opciones de configuración y su funcionalidad se puede ampliar
mediante algunos modulos.

Para arrancar/parar/reiniciar el Servidor:

service apache2 start|stop|restart

Comprobaciones tras la instalación:

Consulta en Internet el comando para comprobar la versión del paquete recien instalado.
Comprueba que ha abierto correctamente el puerto 80/tcp (configurado en
/etc/apache2/ports.conf (directiva Listen 80)
Comprueba que se ha creado un nuevo usuario llamado "www-data" que se incluye en el
grupo "www-data". Son el usuario y el grupo con los que se ejecutan los procesos hijos de
Apache que se encargan de atender las peticiones.
cat /etc/passwd
cat /etc/group
Comprueba el directorio /var/www/html donde se almacenara por defecto el contenido web a ofrecer por el
Servidor Apache. (directiva DocumentRoot del fichero /etc/apache2/sites-available/000-default.conf)
Su propietario es el usuario root y su grupo es root.
Compruébalo. Es el directorio raíz del Servidor virtual por defecto.

VV: Archivos de configuración

info: http://httpd.apache.org/docs/2.4/

Apache se configura editando directivas en ficheros de configuración.

https://httpd.apache.org/docs/2.4/mod/quickreference.html

Comprueba que se han creado los archivos de configuración en el directorio /etc/apache2 y consulta el contenido.

1
 2.1 /etc/apache2/apache2.conf
- Contiene un conjunto de directivas sobre el comportamiento del Servidor.
- Las directivas que no se especifiquen, utilizan su valor por defecto.
- En la mayoría de los sistemas se utiliza un fichero denominado httpd.conf en el que se
almacenan todas las directivas de configuración. En las distribuciones basadas en debian se suele utilizar
como fichero principal de configuración apache2.conf.
- Desde este fichero se incluyen, usando la directiva Include otros ficheros de configuración por ejemplo,
“Include ports.conf”, que es el fichero donde se especifican los puertos que abrira el Servidor Web Apache.

2.2 /etc/apache2/ports.conf
Se llama o incluye desde el fichero principal anterior.
Se definen las IPs y puertos en los que escucha el Servidor. Se agregan tantos “Listen
<nºpto>” como puertos queramos que escuche nuestro servidor. Por defecto: Listen 80 (TCP) y si el
módulo “ssl_module” o “mod_gnutls.c” está activo también escuchará en el puerto seguro 443/tcp

2.3 Directorios de configuración de Módulos

/etc/apache2/mods-available/
- Directorio de configuración de módulos disponibles
- Contiene los ficheros de extensión .load y .conf
- Los ficheros de extensión .load, contienen todo lo necesario para cargar ese módulo.
- Los ficheros de extensión .conf contienen la configuración para iniciar ese Modulo.

/etc/apache2/mods-enabled/
o Directorio de configuración de módulos habilitados
o Contiene enlaces simbólicos a los ficheros de mods-available
o Los enlaces que se encuentren en este directorio serán los modulos a cargar al
iniciar Apache (se incluyen en el fichero apache2.conf).
→ Comprueba si está activo por defecto el módulo para las conexiones seguras SSL.

2.4 Directorios de configuración de Sitios o Servidores Virtuales (virtualhost)

/etc/apache2/sites-available/
# Directorio de configuración de los sitios virtuales.
# Contiene los ficheros de configuración de los sitios virtuales disponibles.
# Por defecto, está creado el fichero default con la configuración del
denominado servidor virtual por defecto.

/etc/apache2/sites-enabled/
o Directorio de configuración de virtualhost habilitados.
o Contiene los enlaces simbólicos a los ficheros de sites-availables.
o Los enlaces que se encuentren en este directorio serán los virtualhost
de Apache que están disponibles y por tanto, disponibles para el usuario final.
o Se incluyen en el fichero apache2.conf por orden alfabético.
o Por defecto, está creado el fichero 000-default.conf que es un
enlace al fichero default de sites-availables/000-default.conf.

2.5 Directorio de configuraciones locales

/etc/apache2/envvars
o Variables de entorno que utiliza el comando apache2.ctl. Por ejemplo,
define la variable de entorno que define el usuario y grupo que usa Apache:

2
3. Virtualhost por defecto
En Apache es posible diferenciar entre:

o Servidor principal. Servidor que atiende las peticiones si no se configuran Virtualhost

o Servidor virtual/Virtualhost. Como ya comentamos Apache soporta los 3 tipos de
Alojamiento de host virtual (basado en IP, basado en Nombres y basados en Puertos).

Para configurar cada Virtualhost se utiliza la directiva:

<Virtualhost>
....
</Virtualhost>
Acciones

o Consulta el directorio /etc/apache2/sites-available y comprueba que están creados los archivos:

000-default.conf: Fichero con la configuración del Virtualhost por defecto para el protocolo HTTP
default-ssl.conf: Fichero con la configuración del VirtualHost por defecto para el protocolo HTTPS

o Consulta el directorio /etc/apache2/sites-enabled y comprueba que existe el fichero 000-

default.conf que es el enlace simbólico a /etc/apache2/sites-available/000-default.conf
# En este directorio apareceran los websites que tenemos activos. Observa que por
defecto, el website para el https no tiene enlace.

o Consulta el fichero 000-default.conf y verifica que hay creado un Virtualhost que escucha en todas
las direcciones IP. Observa que su directorio raíz, en la directiva DocumentRoot es /var/www/html y
comprueba que existe realmente un archivo tipo index.html que es el que carga por defecto.

o Instala un Navegador Web en modo consola llamado lynx en tu MV debianClienteXX

apt-get install lynx
Ejemplos de uso:
lynx localhost
lynx 10.X.0.2
lynx www.etgXX.es

o Accede desde una MV gráfica de tu Red Interna y abre un Navegador web gráfico y accede a tu
Servidor Web Apache, mediante su nombre DNS. Reconfigura tu Servidor DNS BIND9 con Zona
etgXX.es para que resuelva bien:
http://www.etgXX.es

o Haz una pequeña modificación al contenido del index.html y verifica que puedes entrar
correctamente desde una MV cliente de tu Red Interna con el nombre DNS del site:

3
La configuración de Apache queda determinada por un conjunto de directivas que se escriben en los
ficheros de configuración.
Importante:
Dependiendo del entorno en el que se escriban determinadas directivas de configuración, estas afectarán al
comportamiento del servidor en general, a un servidor virtual, a un directorio en concreto, a un fichero, etc.

Existen directivas (por ejemplo <Virtualhost></Virtualhost>, <Directory></Directory>,<Files></Files>..) que

actúan como contenedores de otras directivas y permiten configurar ámbitos del servidor concretos.

Fichero de configuración /etc/apache2/apache2.conf, se puede dividir en 3 secciones:

Sección 1: Directivas globales

Define los aspectos globales del Servidor.
Ejemplo: El número máximo de clientes concurrentes (MaxKeepAliveRequests), los ficheros de LOGs,
el directorio donde están los ficheros de configuración, etc
Sección 2: Directivas de funcionamiento del servidor principal
Agrupa las directivas que definen el comportamiento principal del Servidor principal.
También definen el comportamiento por defecto de todos los servidores virtuales que se
configuren (incluido un posible servidor virtual por defecto)
Sección 3: Directivas de configuración de los servidores virtuales
Directivas relacionadas con los servidores virtuales que se definan.

Parte 1: Configuración del Servidor Apache 2.4

Objetivo: Familiarizarse con los ficheros y las directivas de configuración de Apache
realizando algunas configuraciones.

Ficheros a servir por defecto (Directory Index)

Al realizar una petición web a nuestro Servidor Apache, por defecto, nos carga un fichero (index.html) sin
necesidad de especificar el nombre, esto se configura en la directiva DirectoryIndex y es heredada por
el servidor virtual por defecto. (/etc/apache2/sites-available/000-default.conf).

o Crea un nuevo fichero en /var/www/html y llamalo etg.html con el contenido HTML que desees
sin borrar el anterior y cambia la directiva para que cargue automáticamente el nuevo contenido del
fichero.

o Reinicia el servicio y comprueba los cambios.

4
Opciones sobre directorios (<Directory>..</Directory> y Options Indexes)
En el fichero /etc/apache2/sites-available/000-default.conf, la directiva:
<Directory /var/www/html>
……..
</Directory>
Contiene a su vez las directivas que determinan como Apache sirve el contenido de ese directorio, sus
subdirectorios y archivos.
El mismo resultado puede obtenerse usando ficheros .htaccess
(https://httpd.apache.org/docs/2.0/es/howto/htaccess.html)
Todos los directorios que estén dentro de /var/www/html heredan su configuración.
Esta configuración se puede sobrescribir usando la directiva <Directory>

Crea un nuevo directorio “datos” con un nuevo fichero index2.html, agregando la siguiente directiva
<Directory /var/www/html/datos>
DirectoryIndex index2.html
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Require all granted
</Directory>

Indexes: Se activan los indices de directorio para el directorio ../datos

FollowSymLinks: Aspecto de seguridad, que permite que se sigan los enlaces
simbolicos.
AllowOverride: Decide si permite o no el uso de ficheros .htaccess. Por
seguridad y rendimiento de Apache es preferible no usarlos, configurando esta
directiva a None.
https://httpd.apache.org/docs/current/es/mod/core.html#allowoverride
Require all granted Con esta directiva se permiten todas las solicitudes.

Desde la MV w7 descarga unas imagenes y subelas por FTP a la carpeta

“/var/www/html/datos” con el usuario “webmaster” para poder incluirlas en tu archivo
index2.html. Tendrás que resolver el tema de permisos.
Verifica la nueva configuración
Acceso http://www.etg00.es/datos

5
Logs (ErrorLog, CustomLog, LogFormat)
Consulta el fichero /etc/apache2/sites-available/000-default.conf

¿Cuál es el fichero de LOG y en qué ubicación se encuentra (directiva ErrorLog) ?

Puedes consultar el log de Apache también en el log del sistema de la forma habitual:
# tail /var/log/syslog

Códigos del error (ErrorDocument)

Vamos a configurar el Servidor virtual por defecto para que cuando no encuentre una página, error 404
visualice los siguientes contenidos:

a) Si el fichero o directorio cuelga directamente del directorio raiz del website muestre el mensaje:

“Pagina no encontrada en el site www.etgXX.es”

Ejemplos:
ErrorDocument 404 "mensaje de error"
ErrorDocument 404 /no_encontrada.html

o Si el fichero o directorio solicitado cuelga del directorio ../datos/ del website y éste no existe, que
muestre un web personalizada a través del uso de una plantilla.

Accede al URL: https://dovethemes.com/free-404-error-page-website-templates/

descárgate una Plantilla que más te guste para mostrar una web personalizada referida al Error 404.

Personalizala a tu gusto

Ejemplo:

Modifica el fichero /etc/apache/sites-available/000-

default.conf Verifica la nueva configuración
Comprueba los mensajes de Error diferenciados según del lugar donde se produzcan

6
Parte 2: Configuración de Directorios Virtuales.
Recuerda que los directorios virtuales en un Servidor Web son referencias que permiten acceder a
directorios que físicamente están fuera del directorio principal del home.

En esta práctica veremos como crear Directorios Virtuales y combinarlo a su vez con un sistema de
Autenticación básica de usuarios de Apache para que según sea la cuenta de usuario pueda o no acceder
a un Directorio especifico, para conseguir esto haremos uso también de los Permisos (Require) que
posibilita Apache dentro de cada Directory definido en un VirtualHost.

17. Consulta el fichero: “ud5p2 Anexo Autenticacion usuarios.pdf”

10) Crearemos un fichero de Credenciales de Usuario que lo haremos accesible para Apache dentro
del fichero oculto llamado .htaccess, con los siguientes usuarios:

Login/password
alumno1/passetg0
alumno2/passetg0
alumno3/passetg0

6) Crearemos la estructura de datos necesaria que contendrá los directorios con el contenido web
necesario para esta práctica:

Directorio Contenido web Permisos Alias

/var/www/html alumnos.html Todos -----

/home/alumno1 alumno1.html Sólo usuario “alumno1” www.etgXX.es/alumno1

/home/alumno2 alumno2.html Sólo usuario “alumno2” www.etgXX.es/alumno2

/home/alumno3 alumno3.html Sólo usuario “alumno3” www.etgXX.es/alumno3

/var/www/html/descargas descargas.html Sólo Grupo “alumnos” ----

Contenido web:

/var/www/html/alumnos.html

7
/home/alumno1/alumno1.html

/home/alumno1/alumno2.html

/home/alumno1/alumno3.html

/var/www/html/descargas/descargas.html

Configura el proceso de Autenticación básica para que cada usuario solo pueda acceder al
Directorio de su “usuario” y al Directorio común “descargas”.

Proceso de Autenticación Básica en Apache. Lo ideal en este proceso es realizarlo

además junto al cifrado de la comunicación con un Certificado Digital (HTTPS)

8
 Creación de los Directorios virtuales

www.etgXX.es/alumno1 => /home/alumno1

www.etgXX.es/alumno2 => /home/alumno2
www.etgXX.es/alumno3 => /home/alumno3
Existen 2 formas de crearlos:

Utilizando la directiva Alias

Creando un enlace simbólico dentro del directorio raíz (se debe configurar con la opción
FollowSymLinks) que apunte a otro directorio.

Directorios Virtuales (usando la directiva Alias)

Ejemplo:

Alias “/alumno” “/home/alumno”

<Directory /home/alumno>
DirectoryIndex index.html
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Require all granted
</Directory>

Directorios Virtuales (usando enlaces simbólicos)

Creando un enlace simbólico mediante el comando:

# ln -s <path destino> <enlace>

Ejemplo: Si queremos crear el enlace simbólico /var/www/html/blog que apunte a

/home/alumno/blog, lo haríamos con el comando linux:

# ln -s /home/alumno/blog /var/www/html/blog

Verifica que está definida la opción "FollowSymLinks" en la configuración del directorio /var/www/html

Options Indexes FollowSymLinks MultiViews

Acceso: http//www.etgXX.es/blog

Nota: Para borrar el enlace simbolico:

o rm /var/www/html/blog
unlink <nombre_enlace>

Caso 3: Configuración de Módulos en Apache 2

Apache es un Servidor modular. El núcleo del servidor tiene las funcionalidades básicas que se
pueden ampliar añadiendo módulos adicionales.

Cada modulo agrupa un conjunto de funcionalidades y directivas para configurarlas.

9
Existen múltiples modulos que puedes consultar en https://modules.apache.org/ y
http://httpd.apache.org/docs/2.4/es/mod/

Existen 2 tipos de módulos:

Módulos estáticos que se añaden cuando se compila Apache

Módulos que se cargan dinámicamente cuando se inicia el servidor. Si el servidor se compila con la opción
DSO (Dynamic Shared Object) se podrán cargar modulos dinámicos con la directiva LoadModule.
La directiva <IfModule nombre-modulo>.... </IfModule> permite especificar directivas que se tendrán en cuenta si el
modulo indicado está cargado.
Recuerda que:
/etc/apache2/mods-available : Contiene los modulos disponibles para cargar.
/etc/apache2/mods-enabled : Contiene los enlaces simbólicos a los modulos ya cargados.
Consulta el contenido de uno de los modulos, ej. userdir.conf y comprueba cómo se carga el
modulo desde el fichero userdir.load

El modulo userdir
Vamos a analizar el estudio de los módulos mediante la instalación de uno de ellos, como es el userdir.

Userdir es un modulo de Apache que hace posible que todos los usuarios con acceso a un
servidor tengan una carpeta llamada public_html en la cual puedan alojar sus páginas y archivos web.
Comprueba primero que no está ya activo el modulo en /etc/apache2/mod-
enabled Activación de un nuevo modulo
a2enmod userdir
Reinicia apache2
Comprueba ahora que se ha creado el enlace simbólico en la ruta anterior.
Si quisiéramos deshabilitar un modulo ya habilitado lo haríamos con el comando:
a2dismod nombre-modulo
Consulta el fichero /etc/apache2/mod_enabled/userdir.conf y observa cómo está habilitado el uso de
directorios personales para todos los usuarios excepto para el usuario root y que public_html es el nombre del
subdirectorio que pueden crear los usuarios en su directorio home para poner sus páginas personales.
Es decir, cualquier usuario que tenga en su home el directorio public_html, podrá publicar contenido
web. Crea dicho directorio y un archivo index.html personalizado para el usuario alumno.

Verifícalo mediante el acceso URL: http://www.etg00.es/~alumno/

10
 ¿Cómo harías para que se cargara
también la pagina web mediante el URL:
http://www.etgXX.es/alumno ?

UD5 Servidor Web (HTTP/HTTPS)

Práctica: "ud5p3 Servidor web Apache 2.4. Múltiples VirtualHosts"
Objetivos:
Crear varios Alojamientos de Sitios virtuales o VirtualHosts
Configurar sitios webs seguros (HTTPS) mediante OpenSSL
Recursos:
Laboratorio, Internet
Software Libre:
Apache, webmin, openSSL

Parte I: Alojamiento virtual de Sitios Web o Virtualhost

http://httpd.apache.org/docs/2.4/vhosts/examples.html
Como comentamos anteriormente crear un Alojamiento Virtual de Sitios web o Virtualhost consiste en
simular que existen distintos "servidores web" o máquinas cada una con su respectivo contenido.
Esto se podía hacer de 3 formas:
- Alojamiento virtual basado en IP
- Alojamiento virtual basado en Nombres
- Alojamiento virtual basado en Puertos

Caso A: "Alojamiento virtual basado en Nombres"

Podríamos usar el fichero /etc/apache2/sites-available/000-default.conf, modificando el contenido de este,

o bien, crear un nuevo fichero con el nombre de nuestro sitio, vamos a crear un nuevo site, para ello
deberemos deshabilitar el sitio por defecto.
Crea 2 nuevos directorios con un fichero index.html dentro.

o Crea 2 nuevos directorios con un fichero index.html dentro. Importante que los
“DocumentRoot” estén separados
/var/www/html/sitio1
/var/www/html/sitio2
o Crea los archivos de configuración de los nuevos sitios
<VirtualHost *:80>
ServerAdmin webmaster@sitio1.com
DocumentRoot /var/www/sitio1
DirectoryIndex index.html
ServerName www.sitio1.com
Options Indexes FollowSymLinks MultiViews
</VirtualHost>
<VirtualHost *:80>
ServerAdmin webmaster@sitio2.com
DocumentRoot /var/www/sitio2
DirectoryIndex index.html
ServerName www.sitio2.com
Options Indexes FollowSymLinks MultiViews
</VirtualHost>
o Habilitamos los nuevos sitios, a través de sus archivos de configuración
a2ensite sitio1.conf
a2ensite sitio2.conf
o Comprobamos la creación de los enlaces simbólicos en /etc/apache2/sites-enabled
o Reiniciamos el servicio Apache
o Ahora debes configurar en tu Servidor DNS Bind de Linux tus nuevas zonas asociando las IPs
con los servicios adecuados.
Verifica el correcto funcionamiento del Servicio DNS

o Habilita un nuevo index.html para el site www.etgXX.es, y activalo

1
 WW: Comprueba el correcto funcionamiento
Tests Parte I

Caso B: "Alojamiento virtual basado en IPs"

Crea una Interface Virtual en la MV “debianClienteXX” para que responda también desde ahí a las
peticiones web que vengan solicitando el nuevo sitio web “www.sitio2.com”.

Crear 2 sitios web basados en IPs para que responda a las siguientes peticiones web:

10.X.0.2 http://www.sitio1.com

10.X.0.20 http://www.sitio2.com

Caso C: "Alojamiento virtual basado en Puertos"

Crear 2 sitios web basados en Puertos , con distinto contenido web, para que responda a las
siguientes peticiones web:

http://www.etgXX.es:80

http://www 2 .etgXX.es:8080

2
Parte II:
HTTPS: HTTP Seguro.
Instalación de OpenSSL para el protocolo HTTPS
Hypertext Transfer Protocol Secure (en español: Protocolo seguro de transferencia de hipertexto),
más conocido por sus siglas HTTPS, es un protocolo de aplicación basado en el protocolo HTTP
destinado a la transferencia segura de datos de Hipertexto, es decir, es la versión segura de HTTP.
Es utilizado principalmente por entidades bancarias, tiendas en línea, y cualquier tipo de
servicio que requiera el envío de datos personales o contraseñas.
El sistema HTTPS utiliza un cifrado basado en SSL/TLS para crear un canal cifrado (cuyo nivel de
cifrado depende del servidor remoto y del navegador utilizado por el cliente) más apropiado para el
tráfico de información sensible que el protocolo HTTP. De este modo se consigue que la
información sensible (usuario y claves de acceso normalmente) no pueda ser usada por un
atacante que haya conseguido interceptar la transferencia de datos de la conexión, ya que lo único
que obtendrá será un flujo de datos cifrados que le resultará imposible de descifrar.
HTTP opera en la capa más alta del modelo OSI, la capa de aplicación; pero el protocolo de
seguridad opera en una subcapa más baja, cifrando un mensaje HTTP previo a la transmisión y
descifrando un mensaje una vez recibido.

El puerto estándar para este protocolo es el 443.

Las URLs de HTTPS comienzan con "https://"
Configuración del servidor
- Para preparar un servidor web que acepte conexiones HTTPS, el administrador debe crear un
certificado de clave pública para el servidor web.
- Este certificado debe estar firmado por una autoridad de certificación para que el navegador web lo
acepte. La autoridad certifica que el titular del certificado es quien dice ser. Los navegadores web
generalmente son distribuidos con los certificados raíz firmados por la mayoría de las autoridades de
certificación por lo que estos pueden verificar certificados firmados por ellos.
- El Secure Socket Layer se utiliza para cifrar el flujo de datos entre el servidor web y el cliente web (el navegador).
- SSL hace uso de lo que se conoce como la criptografía asimétrica, comúnmente conocida como la criptografía
de clave pública (PKI). Con la criptografía de clave pública, se crean dos claves, una pública y otra privada.
Cualquier cosa cifrada con una de las llaves sólo se puede descifrar con su clave correspondiente. Así, si una
secuencia de mensajes o datos se cifra con la clave privada del servidor, se puede descifrar solamente usando
su clave pública correspondiente, asegurando que los datos sólo podrían haber llegado desde el servidor.

- Instalación (es probable que lo tengas ya instalado de la práctica de FTP Seguro (FTPS))
apt-get install openssl

Paso 1: Creación de una Clave privada

El kit de herramientas OpenSSL se utiliza para generar una clave RSA privada y CSR (Certificate
Signing Request). También se puede utilizar para generar certificados auto-firmados que pueden ser
utilizados para propósitos de prueba o uso interno.
o El primer paso es crear nuestra clave privada RSA. Esta clave es una clave RSA de una
longitud de bits (1024,2048,4096,..) que se cifra usando Triple-DES (des3) y se almacena en un
formato PEM para que sea legible como texto ASCII.
oEntramos en la carpeta /etc/ssl/private y desde ahí generamos la clave privada RSA (en la práctica FTPS, a la
vez que creábamos el Certificado creábamos también la Clave Privada aquí lo separamos para ver otras formas)

# openssl genrsa -des3 -out server.key 4096

genrsa:
-des3: Uso del Algoritmo de Cifrado Triple-DES
-out: Identifica el fichero de salida que tendrá la Clave privada
4096: longitud de la clave en bits (a mayor longitud, mayor seguridad)

3
 Obtenemos el fichero server.key

Paso 2: Creación del Certificado CSR

Una vez generada la clave privada , se puede generar la CSR (Certificate Signing Request, o
solicitud de firma de Certificado).
Un CSR o Certificate Signing Request es un bloque de texto cifrado que normalmente es generado en el servidor donde el certificado SSL será utilizado.
El CSR contiene información que será incluida finalmente en el certificado SSL, como por ejemplo tu nombre o el de la empresa, la dirección, el país de residencia o el common name (dominio para el que es
generado el SSL), además de estos datos también incluirá un clave pública que será incluida también en tu certificado.

La CSR se utiliza entonces de las siguientes maneras:

Idealmente, la CSR se enviaría a una autoridad de certificación (CA o AC), tales como Thawte o
Verisign quien verificará la identidad del solicitante y emitira nuestro certificado firmado.
La segunda opción es la de autofirmar nosotros la CSR, que será lo que hagamos a
continuación, con el comando:

# openssl req -new -days 365 -key server.key -out server.csr

req: Request para la petición

new: nueva petición
key: archivo desde el que se leerá la clave Privada (creada anteriormente)
out: archivo de CSR generado

Nos preguntara por distintos datos. Estos son los atributos X.509 del certificado.
Una de las indicaciones será para Common Name. Es importante que este campo se rellene con el
nombre de dominio completo (FQDN) del servidor que será protegido por SSL.
Si el sitio web para ser protegida será https://public.akadia.com, a continuación, introduciriamos
public.akadia.com en esta pantalla.
Completamos unos datos en el proceso de Creación del Certificado, y cuando termine ya
estará listo el Certificado.
Obtenemos el fichero server.csr
El elemento que debemos exportar es el .csr (En este caso, server.csr)

Paso 3: AutoFirma del Certificado.

En este punto tendremos que generar un Certificado autofirmado debido a que no planeamos tener el
Certificado firmado por una CA o por probar la nueva implementación de SSL.

Recuerda: Que este Certificado generará un error en el navegador del cliente en el

sentido de que la autoridad de certificado de firma es desconocida y no de confianza.

Para generar un certificado temporal que es válido para 365 días, ejecutamos el siguiente comando:

# openssl x509 -in server.csr -out server.crt -req -signkey server.key -days 365

req: indica que se solicita un Certificado X.509 para ser firmado

-out: indica el fichero de salida server.crt, que es un Certificado con formato X.509
-days: Validez del Certificado

Obtenemos el fichero server.crt

o Da permisos de solo Lectura para el propietario sobre los ficheros: .key, .csr, .crt
chmod 400 server.*
o Cambio el grupo a "ssl-cert" los ficheros: .key, .csr, .crt
chgrp ssl-cert server.*
oAhora con el nuevo grupo, cambio los permisos de nuevo para darles también solo Lectura al grupo ssl-cert
chmod 440 server.*
o Activamos el modulo SSL y el site SSL
/etc/apache2/ ls mods-avalaible

4
 o Activamos el modulo SSL
# a2enmod ssl
o Reiniciamos el servicio Apache
#service apache2 restart
Comprobamos que tenemos el nuevo puerto 443 /tcp para el protocolo HTTPS
o Activamos el site SSL
# a2ensite 000-default-ssl
Recargamos el servicio Apache
#service apache2 reload
Editamos el fichero default-ssl como nuevo site disponible
nano /etc/apache2/sites-available
Y modificamos los parámetros siguientes, especificando los ficheros de nuestro Certificado SSL

Recargamos el servicio Apache

# service apache2 reload
Arrancamos ahora el Servidor Apache
# service apache2 start
Nos pedirá la clave y listo ya está funcionando nuestro site Apache seguro

Otra forma de crear el Certificado sería, sin clave privada para el Acceso al Certificado.
1º Creamos la solicitud del Certificado y nuestra Clave Privada
# openssl req -nodes -newkey rsa:2048 -keyout etg00.key -out etg00.csr

2º Creación del Certificado y la Autofirma.

# openssl x509 -req -in etg00.csr -signkey etg00.key -out etg00.crt -days 365

Tests Parte II https://www.etg00.es

5
Configura ahora lo necesario para que tu Servidor Apache atienda distintas peticiones web
HTTPS en cada uno de los 3 sitios creados en la práctica anterior.

o Cada sitio HTTPS con un Certificado distinto

Tests:
a) Test https://www.etg00.com b) Test https://www.sitio1.com c) Test https://www.sitio2.com

Evaluación de la práctica en el Aula de los 6 websites (Parte I, Parte II), no se pedirá documentación a
subir en el AulaVirtual

El contenido del index.html principal debe incluir el siguiente contenido y accesos:

Práctica ud5p3. Apache. Distintos VirtualHosts basados en

Nombres HTTP: Modo no seguro
o http://www.etgXX.es
o http://www.sitio1.com
o http://www.sitio2.co
m HTTPS: Modo seguro
o https://www.etgXX.es
o https://www.sitio1.com
o https://www.sitio2.com
Tu nombre y apellidos

6
 Parte III: Permisos sobre Directorios en websites de Apache 2
Fuente:
https://httpd.apache.org/docs/2.4/howto/access.html
https://httpd.apache.org/docs/2.4/upgrading.html
https://httpd.apache.org/docs/2.4/mod/mod_authz_core.html

o Asigna los siguientes permisos de acceso por directorios:

Sobre el Directorio principal o raiz del website http://www.etgXX.es, permite solo el acceso a la
IP 10.X.0.4 (winClienteXX) el resto no podra acceder a ese directorio.
Sobre el Directorio /var/www/html/datos permite el acceso a todos.

o Asigna los siguientes permisos de acceso por directorios:

Sobre el Directorio principal o raiz del website http://www.etgXX.es , permite solo el acceso a
todos los hosts de la Red interna el resto no podra acceder a ese directorio.
Sobre el Directorio /var/www/html/datos permite el acceso a todos.

o Asigna los siguientes permisos de acceso por directorios:

o Configura el mensaje de Error 403 con el contenido “Permiso no permitido en este directorio”
Sobre el Directorio principal o raiz del website http://www. sitio1.com , permite solo el acceso:
O bien al localhost
O bien a la IP 10.X.0.3 (debianGraficoXX)
Sobre el Directorio principal del http://www.sitio2.com, permite a todos los hosts de la Red
interna excepto a la IP 10.X.0.4

18. Asigna los siguientes permisos de acceso por directorios:

Al Directorio /var/www/html a todos
Al directorio /var/www/html/datos a todos excepto al equipo con IP 10.X.0.4

Adjuntar documento a la Tarea del Aula Virtual con las resoluciones de las siguientes partes:

Parte I : Casos B y C
Parte III.

UD6 Servicio de Correo Electrónico

➢ Servidor de Correo Saliente SMTP (25)
➢ Servidor de Correo Entrante POP3 (110), IMAP (143)

Introducción
El servicio de correo electrónico (email) ofrece a los usuarios la posibilidad de
enviarse mensajes (correos electrónicos) a través de una red TCP/IP.
Es uno de los servicios más utilizados en Internet por particulares y empresas.
oLa característica principal es que permite ese intercambio de mensajes entre usuarios sin necesidad de
que el Emisor y el Receptor establezcan una conexión previa. Es decir, la comunicación es asíncrona.
o Este servicio no garantiza que los mensajes lleguen a su destino ni asegura que el remitente sea quien dice
ser.
oEl protocolo SMTP (Protocolo para la Transferencia Simple de Correo Electrónico) es el protocolo
utilizado en la transferencia de mensajes de correo.
o El servicio de correo electrónico está basado en el modelo Cliente/Servidor.
o El Servidor SMTP escucha en el puerto TCP 25

Componentes
Mensajes de correo. Mensajes de texto que pueden incluir documentos adjuntos.
Direcciones y cuentas de correo. Los usuarios disponen de direcciones de correo (ej.
alumno@etg.es) asociadas a una cuenta de correo.
Servidores de correo. Conjunto de componentes que permiten el reenvío de mensajes de correo electrónico.
Buzones de correo (mailbox). Las cuentas de correo tienen asociados buzones de correo en los
cuales se depositan y almacenan los mensajes (al igual que una dirección postal tiene un buzón físico).
 Agentes de Transferencia de Correos (MTA, Mail Transfer Agent o mail relay). Procesos
que se encargan de recibir el correo o de reenviarlo (relay) a otros agentes de transporte.
En el caso de tener que retransmitir o reenviar un correo (mail relay) éste
puede ser: Directamente al MTA del destinatario
A otro MTA intermediario (llamado smart host)
En la actualidad está funcionalidad de email relay es muy importante que este controlada y restringida
porque sino, podría ser utilizada por usuarios desconocidos con fines publicitarios o maliciosos, es decir,
mensajes no deseados por los destinatarios o habitualmente conocido como SPAM o “correo basura”.
Pueden actuar como cliente y servidor del protocolo SMTP. Es el componente principal y
por ello, es habitual usar el término de MTA como sinónimo de Servidor de correo.
Agente de Entrega de Correos (MDA, Mail Delivery Agent). Procesos que se encargan de recibir y
depositar los mensajes de correo en los buzones de los destinatarios. Son invocados por los MTAs.
Servidores POP/IMAP. Procesos que permiten a los clientes de correo acceder a los buzones
para obtener, consultar, borrar o modificar los mensajes almacenados. La comunicación entre
ellos y los clientes se realiza según las normas de los protocolos POP y/o IMAP.
La diferencia fundamental entre ellos, es que mientras POP accede y descarga los
correos a local (borrándolos del Servidor) el protocolo IMAP accede y mantiene los
correos en el Servidor (y es el usuario el que los gestiona).
Componentes adicionales. Añaden funcionalidades y se integran con el MTA y el MDA.
Ejemplos; filtros antispam, sistemas de autenticación, listas de distribución, etc.
Clientes de correo o Agentes de Usuario de Correo (MUA, Mail User Agent). Programas que permiten a
los usuarios escribir, enviar y consultar o manipular los correos almacenados en sus buzones. Actúan como
clientes SMTP para enviar correos y pueden actuar como clientes POP/IMAP para acceder a los buzones.
Protocolos. La comunicación entre los diferentes componentes del servicio se basa en los siguientes protocolos:

Protocolos de transferencia de correo:

SMTP y SMTP Extendido (ESMTP)
Comunicación entre clientes (MUAs) y MTAs y comunicación entre MTAs
Protocolos de entrega de
correo: POP e IMAP
Comunicación entre clientes (MUAs) y servidores POP/IMAP.
1
Observa el esquema básico de
funcionamiento de los protocolos
y procesos implicados.

Puertos habituales de los Protocolos No seguros implicados

Protocolo No seguro Puerto/s TCP
SMTP 25 / 2525 /587
POP3 110
IMAP 143

Puertos habituales de los Protocolos Seguros implicados

Protocolo + SSL/TLS Puerto/s TCP

SMTPS (SMTP+SSL/TSL) 25 / 465 /587 /2526
POP3S (POP+SSL/TLS) 995
IMAPS (IMAP+SSL/TLS) 993

Esquema de los componentes en los Servicios de Correo

2
Funcionamiento básico en el envío/recepción de Emails

- Un usuario escribe un email usando un Cliente de Correo (MUA), con la siguiente estructura:
Dirección del Emisor del email: profesor@daw.es
Dirección del Destinatario del email: alumno@asir.es
Cuerpo del mensaje (texto, imágenes, archivos, etc)
- El Cliente de Correo (MUA) envía el email usando el protocolo SMTP. Dándose las siguientes posibilidades:
Envío a un Servidor de Correo Local (MTA local), si en la misma máquina donde esta el Cliente de
correo hay un MTA.
A un Servidor de Correo Remoto (MTA):
Al servidor de correo del usuario destinatario (el del dominio asir.es). No es habitual porque el
servidor de correo debería estar configurado para no permitir correos de cualquier origen.
Al servidor de correo del usuario que envía el mensaje (el del dominio daw.es). Es lo habitual
porque, los MTAs deben estar configurados para recibir y/o reenviar correo solo de usuarios,
dominio, equipos o redes autorizados.
- El servidor de correo (MTA) recibe el mensaje usando el protocolo SMTP.
Si el correo está dirigido a un usuario cuyo buzón está en el servidor local, el correo se almacena en
el buzón del usuario (lo puede hacer el MDA). → Recepción del correo.
Si el correo está dirigido a un usuario que no tiene cuenta en el
servidor. Existen 2 posibilidades:
Envía el correo al Servidor de Correo del destinatario del mensaje. → Retransmisión del correo.
Envía el correo a otro Servidor de correo (que se denomina relay o smart host) que vuelve a realizar el
mismo proceso. → Reenvío del correo (relay).
Debe estar configurado para admitir correos del usuario, dominio, equipo o red desde donde se envía.
Es importante diferenciar entre recepción de correo, retransmisión y reenvío (relay).
Por tanto, los MTAs de los Servidores de correo se encargan de reenviar los mensajes a otros MTAs
si el destinatario del mensaje no tiene cuenta en ellos (añadiendo info, de modo que se pueda saber
por los MTA que ha pasado). Si el destinatario si tiene cuenta en el Servidor se almacena el mensaje
en el buzón (lo puede hacer el MDA).
Los usuarios utilizan los Clientes de Correo (MUA) para acceder a Servidores POP
(descargando) o IMAP (consultando) los mensajes de sus buzones de correo.

1. Envío de correo y DNS

Los MTAs determinan cuál es el siguiente MTA al que tienen que enviar un mensaje en función de la
dirección de correo de destino (y por supuesto de su configuración).
Para averiguar la dirección IP del servidor de correo consultan logicamente a un Servidor DNS.
Recuerda que los DNS tienen el registro MX para referenciar al Servidor de Correo de un Dominio.

3
 2. Recepción o entrega de Correos
Cuando un usuario quiere consultar su buzón de correo para leer sus mensajes, puede optar entre:
- Iniciar sesión en el Servidor de correo (no es lo habitual, se refiere a que un usuario puede login de sesión en el
Servidor de Correo). Y acceder al buzón directamente (o carpeta) o usar desde aquí un Cliente de correo
(MUA). - Aunque este funcionamiento lo veremos en prácticas, en la realidad no se suele dar el caso.
- Desde otro host, usar un Cliente de Correo (MUA) configurado con los datos del Servidor de Correo
(SMTP,POP/IMAP) para que se comunique con dicho Servidor y poder acceder a su Cuenta con sus credenciales.
Ejemplo 1: En el equipo Cliente hay un MTA local que es capaz de reenviar correos a otros MTAs.

Ejemplo 2: El Cliente envía directamente el mensaje al MTA de su Dominio. Típico caso

4
Ejemplo 3: El Cliente usa el MTA de otro dominio “otro.es” para enviar su correo

Ejemplo 4: El Cliente usa el MTA del destinatario “asir.es” para enviar su correo.

5
Servidores “open relay”
Son servidores de correo (MTA) que permite el reenvío de correo desde cualquier lugar sin controlar
ni verificar de donde viene y de quién proviene.
Al no restringir ni controlar el reenvío de correo puede ser empleado para enviar SPAM, virus, etc.

Para controlar el SPAM y los correos maliciosos se han creado listas en las que se incluyen rangos de
IPS, dominio, etc que son susceptibles de contener MTAs que actúan como open relay .
Estas listas son consultadas por otros MTAs y por otros servicios para rechazar o no aceptar correo que
procede de esas fuentes.
Un servidor puede ser open relay porque está mal configurado y/o porqué ha sido
atacado. Comprueba si tu servidor actúa como Open Relay Mail Servers:
http://www.abuse.net/relay.html

Servidores “smart host”

Son servidores que reciben mensajes de otros MTAs que van dirigidos a destinatarios que no tiene cuentas en él.
Su función es por tanto reenviarlos:
o Directamente al destinatario.
o O bien, a otro Servidor que actúa como smart host o intermediario.
# Debe estar configurado para permitir solo el reenvío de correos de determinados usuarios,
dominios, IPs, etc. Si no es así se consideraría open relay.

Servidores principales y secundarios

Al igual que en otros servidores (DNS, DHCP, etc) para aumentar el rendimiento, la seguridad y la
disponibilidad es habitual configurar múltiples servidores, en este caso varios Servidores de Correo (MTA) para un
mismo dominio. Recuerda que es posible configurar en un Servidor DNS varios registros MX correspondientes a
distintos servidores de Correo para un mismo dominio, de forma que primero se intenta enviar el correo al principal, de
mayor prioridad DNS cuanto más bajo es su valor, y si no es posible se accede a los secundarios.

6
Servidores de primer nivel y de segundo nivel.
En las empresas medianas y grandes es habitual configurar varios Servidores de Correo para
gestionar los correos y su comunicación con Internet.

Un ejemplo de arquitectura es la siguiente:

# Servidores de primer nivel (denominados estafetas de 1º

nivel): - Gestionan el correo entrante y saliente de la empresa
- Disponen de fuertes mecanismos de seguridad (antivirus, antispam, filtros, etc)
- Reciben el correo de Interne y otras redes y lo reenvían a los Servidores internos (denominados de
segundo nivel) - Reciben el correo de los Servidores de 2º nivel y lo reenvían (actuando como smart
host) hacia otros Servidores de correo externos.
- Reciben peticiones POP/IMAP desde clientes externos que quieren obtener el correo almacenado en sus buzones.

# Servidores de segundo nivel (o estafetas de 2º nivel):

o Proporcionan servicio a los usuarios de la empresa.
oReciben mensajes de los clientes de correo de la empresa y los reenvían, según el destinatario, a otros
servidores de 2º nivel internos o a Servidores de 1º nivel.
o Reciben correos de los Servidores de 1º nivel y de otros Servidores de 2º nivel.
o No establecen conexiones directamente con el exterior.
Ejemplo: Infraestructura 1

Ejemplo: Infraestructura 2

7
Diferencias entre POP e IMAP

POP: Post Office Protocol (Protocolo de oficina de correos) es un protocolo de comunicación que se utiliza
para obtener desde un programa de escritorio (Thunderbird, Outlook, Windows Mail, etc) los mensajes de
correo electrónico almacenados en un servidor remoto.
Por defecto, según son descargados por el usuario a Local son borrados del Servidor.
Ventaja: Consulta de los emails offline.

IMAP: Internet Message Access Protocol (Protocolo de acceso a mensajes de Internet), es un protocolo de
comunicación que se utiliza para acceder a los mensajes electrónicos alojadas en un servidor remoto.

o En IMAP todas las acciones realizadas en los mensajes (leer, mover, eliminar,..) se realizan directamente en el servidor,
mientras que con POP, por defecto, está configurado para descargar todos los mensajes del servidor de correo al ordenador
desde el que se conecta. Esto significa que todas las acciones realizadas en los mensajes (leer, mover, borrar,..) se
realizarán en el propio ordenador. Al descargarse, por defecto, se eliminan los mensajes del servidor.

UD6 Servicio de Correo Electrónico

Práctica: ud6p1 Servicio de Correo en Linux (Postfix y Dovecot)

A) Instalación y pruebas del MTA Postfix en Linux

http://www.postfix.org/
Objetivos: Instalaremos el MTA Postfix y Dovecot en Linux para que envie y reciba correos
del dominio etgXX.es entre diferentes usuarios a través de sus Cuentas de Correo.
Recursos: Laboratorio, Internet
http://www.postfix.org/postconf.5.html
http://www.postfix.org/addon.html
Ejemplos de configuración de Postfix según propósito: http://www.postfix.org/STANDARD_CONFIGURATION_README.html
Software libre: Postfix, Dovecot, webmin

Postfix, es un MTA para sistemas Unix/Linux. Es rápido, modular y "fácil de administrar y configurar" (comparado con otros MTAs
como Sendmail). Tiene muchas opciones de configuración y su funcionalidad se puede ampliar mediante módulos o paquetes
adicionales (http://www.postfix.org/addon.html).

Instalación
- Instalación del Servidor de Correo Postfix en debianGraficoXX
Asegúrate que en los ficheros, /etc/hosts y /etc/hostname el nombre del
equipo es: debianGraficoxx.etgXX.es.
Instalaremos postfix desde los repositorios oficiales
apt-get update
aptitude install postfix
Si nos detecta que ya existe un pequeño servidor de correo instalado (exim4), y nos pregunta si
queremos desinstalarlo, le diremos que si.c
Lee los tipos de configuración base que te ofrece Postfix.
Selecciona Sitio de Internet.
Introduce el nombre de dominio que gestionara Postfix como local, en este caso, será
tu dominio etgXX.es
- Al instalar el Servidor se crean:
Los archivos de configuración en /etc/postfix
El usuario postfix que se incluye en el grupo postfix
Certificados digitales autofirmados para conexiones STMPS.
o Postfix se configura editando parámetros en ficheros de configuración.
Comprueba que se han creado los archivos de configuración a partir del directorio /etc/postfix y
consulta el contenido de los ficheros:
/etc/postfix/main.cf
Fichero de configuración principal de postfix
 En este fichero se definen un conjunto mínimo de parámetros de configuración
(http://www.postfix.org/ postconf.5.html), cada parámetro se especifica en una línea con el formato:
parámetro = valor
Si una línea comienza con un espacio es que continúa el parámetro anterior.
Se puede utilizar $parámetro para asignar el valor de un parámetro a otro.
Los parámetros que no se especifiquen en el fichero, utilizan su valor por defecto.
/etc/postfix/master.cf
Fichero de configuración del demonio maestro de Postfix
Especifica como Postfix interactúa con diferentes procesos para lograr la entrega de correo.

- Comprueba que el Servidor de correo está iniciado

ps -ef |grep postfix
Comprueba que el Servidor está escuchando en el puerto TCP 25 / SMTP
netstat -ltn

1
 - Consulta los ficheros de log de Postfix
/var/log/mail.log: Fichero principal de logs en el que se registra todo lo sucedido
relacionado con el envió de correo
/var/log/mail.info: Fichero donde se registran las acciones del Servidor
/var/log/mail.err : Fichero donde se registran los Errores
/var/log/mail.warn :Fichero donde se registran los Avisos o Warnings

Configuración por defecto

La configuración por defecto de postfix es la siguiente:

# Gestiona cuentas de usuarios locales con el nombre de dominio etgXX.es
# Solo permite el reenvío de correos enviados desde el propio equipo.
#Permite conexiones SMTP y conexiones SMTPS en el puerto 25 usando STARTTLS (usando un
Certificado Digital autofirmado)
# No tiene configurada ningún tipo de autenticación SMTP
#Permite el reenvío de correos destinados a cualquier dominio y envía los correos
directamente a los destinatarios.
#Los buzones de los usuarios se almacenan en formato mailbox en el directorio /var/mail y no tienen
limitación de tamaño.
➢ Comprueba la versión instalada en tu host
$sudo postconf mail_version
➢ Para comprobar los parámetros que tenemos configurados:
sudo postconf -n
➢ Para comprobar los valores por defecto del resto de parámetros:
sudo ostconf -d
o Instalación de Dovecot (protocolos IMAP/143 y POP3/110)
https://wiki2.dovecot.org/
https://wiki2.dovecot.org/quickconfiguration

Dovecot es un Servidor POP3/IMAP4 para Sistemas Linux rápido y fácil de administrar.

Permitirá a los usuarios de la Red Interna acceder a sus buzones de
correo Solo se permitirán conexiones seguras POP3S e IMAP4S
Los métodos de autenticación permitidos serán PLAIN y LOGIN

Instalación (aprox 2MB)

apt-get update
➢ aptitude install dovecot-pop3d dovecot-imapd

El fichero de configuración principal

/etc/dovecot/dovecot.conf
Comprueba que el servidor esta iniciado
o sudo ps -ef | grep dovecot
Comprueba la versión Dovecot instalada
$ sudo dovecot --version
Comprueba que el Servicio está activo
$ sudo service dovecot status
Comprueba que el servidor está a la escucha en los
puertos: 110/tcp (POP), 143/tcp (IMAP), para puertos
No seguros 993 /tcp , 995 /tcp para puertos Seguros

2
Usuarios y pruebas del Servidor.
Postfix puede gestionar cuentas de correo de:
o Usuarios locales con cuenta en el Sistema
o Usuarios virtuales (almacenados en Bases de Datos, Servicio de Directorio, ...)

Vamos a crear unos usuarios locales leonidas y jerjes de prueba, con la password habitual:
adduser leonidas
adduser jerjes
Instala el Servicio Telnet (te abrirá el puerto 23/TCP)
apt-get install telnetd
El Servicio Telnet nos permite realizar Conexiones Remotas en el equipo donde se instala el
Servicio, nos abre por defecto el puerto 25/TCP
Vamos a enviar un email del usuario leonidas a jerjes (a través del usuario root) via Telnet

o Haz inicio de sesión como Jerjes y comprueba en /var/mail, que se ha creado el email, con el nombre del
usuario remitente, en este caso “jerjes” y abre el archivo que contiene el email (nano /var/mail/jerjes)

3
6. Envía un nuevo email de respuesta ahora desde el usuario jerjes para el usuario leonidas, del tipo:

Saludamos al Servidor

Indicamos el Emisor el email

Indicamos el Receptor del email

Cuerpo del mensaje (datos)

Final del mensaje

Salir del telnet y enviar

o Comprobamos de nuevo /var/mail/ y veremos que tenemos dos ficheros cada uno guardara los
emails de cada usuario.

Haz inicio de Sesión ahora con Leonidas y comprueba el contenido de los Emails recibidos:

4
Comprueba que los permisos de los archivos (Buzones de correo) de los usuarios son muy restrictivos, y no
permite acceder ni verlos los de otro usuario. Verifica con Leonidas que no puedes ver los emails de Jerjes.

o Test del Servidor de Entrada con Dovecot, ahora realizaremos la prueba de Telnet al puerto 110/TCP –
POP3 para poder visualizar los Correos, es decir, desde el punto de vista de Servicios en este caso no trabaja
SMTP con el 25/tcp sino que necesitamos manejar el Servicio de Entrada con POP3 a través de Dovecot

Nos conectamos con un login

Ponemos su Clave

Comprobamos el estado
(vemos q existe 1 email)
Hacemos un Listado

Abrimos el Email

→ Comprueba igualmente el Buzón del usuario “jerjes” con el Sercivio Dovecot, y aporta el pantallazo.

9 . Vamos a instalar en debianGraficoXX un sencillo Software de Cliente de Correo para pruebas,

será el paquete mailutils (aprox 11 MB), que contiene el cliente mail:
aptitude install mailutils

o Enviamos ahora 2 nuevos emails haciendo uso de esta utilidad.

a )Haz inicio de sesion con el usuario Leonidas y envia a Jerjes un nuevo correo

5
o Ctrol + D para pasar de linea en cada bloque

o Haz inicio de sesión con Jerjes comprueba que ha recibido su email y leelo, y contesta a
Leonidas y revisa posteriormente su correo.

19. Instala el paquete de administración para Linux Webmin en debianGraficoXX

20. Comprueba que tienes los Servidores refrescados Postfix (smtp), Dovecot (po3/imap)
21. Vamos a comprobar de nuevo los Servicios mediante el envio de un nuevo email a través de Webmin.
Accede a Servidores + Lectura de Correo de Usuarios. Y desde ahí, selecciona un usuario que sepas
que ya ha recibido algún email de los apartados anteriores (ej. Jerjes).
Haz clic sobre “Componer un nuevo correo” y envía un nuevo email desde (jerjes@etgXX.es) a
otro usuario (leonidas@etgXX.es) haciendo uso del dominio de tu zona DNS etgXX.es

11) Comprueba ahora el Buzón del Destinatario “leonidas@etgXX.es” y comprueba el

contenido del correo enviado.

Instalación del Cliente de Correo Gráfico Thunderbird en WinClienteXX

6
 1. Descarga e instala el software libre Thunderbird en la MV winClienteXX.etgXX.es

– Vamos a configurar ahora desde el fichero /etc/dovecot/dovecot.conf cuál es nuestra Red de

Confiranza con el parámetro de Dovecot:
login_trusted_networks = 10.X.0.0/24
Para definirle desde qué redes confiables se podrán autenticar los usuarios en el Servidor.

– Reiniciamos el Servicio de Dovecot

service dovecot restart

Una vez instalado Thunderbird, desde el menú Herramientas + Configuración de cuenta, agregaremos
las Cuentas de Correo para los usuarios ya creados.
En este punto, asegurate de que tu Servidor DNS tiene correctamente configurado el Registro MX y que
puede resolver, ademas de añadir 3 nuevos alias (smtp, pop3 e imap) sobre el host debianGraficoXX.

smtp.etgXX.es
pop3.etgXX.es
imap.etgXX.es

Comprueba sus resoluciones antes de realizar las configuraciones de creación de cuentas en el Thunderbird.
Crea, por tanto, las cuentas de correo para con los datos de los Servidores SMTP y POP3 o IMAP para los usuarios:

jerjes@etgXX.es
leonidas@etgXX.es

7
Agrega ahora, la Cuenta de Correo del usuario:

leonidas@etgXX.es

Comprueba sus Bandejas de Entrada:

Prueba a enviar y recibir correos desde este Cliente de Correo Thunderbird entre los 2 usuarios siempre
con los nombres de Dominio (leonidas@etgXX.es y jerjes@etgXX.es ) y comprobando su recepción.

8
Configuración SMTPS y STARTTLS (SSL/TLS)
Por defecto Postfix está configurado en /etc/postfix/main.cf para permitir conexiones SMTP y SMTPS en
el puerto 25 usando STARTTLS con el certificado digital:

Podríamos usar nuestros propios Certificados Digitales con openSSL de las formas ya vistas en prácticas
anteriores y configurando los parámetros de la figura anterior con los ficheros de Clave Pública y Privada.

Configuración de los protocolos POPS / 995 e IMAPS /993

Consulta las versiones instaladas de tus servidores de Correo.
dovecot –version
dpkg -s postfix

Como habrás observado mientras que Postfix trabaja por defecto en modo seguro mediante STARTTLS, en Dovecot no.

En versiones anteriores Dovecot abría por defecto también los puertos seguros 995/tcp y 993/tcp haciendo
uso de un Certificado que creaba automáticamente dovecot.pem.

Comprueba si es tu caso.

oInstala el OpenSSL en debianGraficoXX y crea un Certificado Digital mediante openSSL exclusivo para
los protocolos pops e imaps.
o Actualmente el fichero de configuración de SSL de Dovecot esta en

/etc/dovecot/conf.d/10-ssl.conf
Donde vamos a configurar los siguientes parámetros para nuestro Certificado:

Si usas clave Simétrica para proteger la Clave Privada (.key) del Certificado deberás usar también el parámetro:
ssl_password_key = <tupasssword>

Graba, reinicia el servicio, comprueba el estado y que los nuevos puertos de Dovecot para conexiones
Seguras estén abiertos:
995/tcp para pops
993/tcp para imaps

9
Configura en el Cliente de Correo Thunderbird a tu nuevo
acceso seguro para imaps/pop3s

o Realiza el cambio para todas tus Cuentas de Correo para

utilizar Conexiones Seguras para tus Servidores de Correo.

Consulta y acepta tu nuevo Certificado creado para el Servidor IMAP

Captura con tu wireshark el envío de un nuevo email (uso de

STARTTLS) y lectura mediante IMAPS (uso de SSL/TLS) para comprobar
que ahora sí toda la comunicación del envío/recepción del Correo es
segura (cifrada)

10
o Establecimiento de la conexión:
 Transmisión de Datos (parcial, se generan muchas tramas):

o Cierre de la conexión

1
1
7
23

22