Practicas

Curso Seguridad en redes
(IFC03CM15)
Cuadernillo de prcticas
Pedro Pablo Gmez Martn
Septiembre, 2015
Documento maquetado con TEXiS v.1.0+.
Este documento est preparado para ser imprimido a doble cara.
Curso Seguridad en redes

(IFC03CM15)
Cuadernillo de prcticas
Septiembre, 2015
c Pedro Pablo Gmez Martn

Copyright
ndice
1. El laboratorio virtual
Pr. 1.1.
Instalar Debian
. . . . . . . . . . . . . . . . . . . . . . .
Pr. 1.2.
Conguracin de la red en Debian . . . . . . . . . . . . .
Pr. 1.3.
Modelos de red en Virtual Box . . . . . . . . . . . . . . .
Pr. 1.4.
Creacin de Debian Cliente . . . . . . . . . . . . . . . . .
Pr. 1.5.
Creacin de Ubuntu . . . . . . . . . . . . . . . . . . . . .
Pr. 1.6.
Una segunda tarjeta de red en debian servidor . . . . . .
Pr. 1.7.
Congurar el laboratorio virtual . . . . . . . . . . . . . .
Pr. 1.8.
Batera de pruebas 1: red bsica . . . . . . . . . . . . . .
Pr. 1.9.
Batera de pruebas 2: red en NAT . . . . . . . . . . . . .
11
Pr. 1.10. Batera de pruebas 3: encaminamiento y NAT
. . . . . .
12
En el prximo captulo . . . . . . . . . . . . . . . . . . . . . . . . .
14
2. Cortafuegos. iptables
15
Pr. 2.1.
Instalacin de demonios . . . . . . . . . . . . . . . . . . .
15
Pr. 2.2.
Analizando trco de red . . . . . . . . . . . . . . . . . .
16
Pr. 2.3.
Comprobacin de puertos abiertos . . . . . . . . . . . . .
17
Pr. 2.4.
Comprobacin de los puertos abiertos en remoto . . . . .
18
Pr. 2.5.
iptables: poltica por defecto
. . . . . . . . . . . . . . . .
18
Pr. 2.6.
iptables: condiciones de capa 2 y 3 . . . . . . . . . . . . .
20
Pr. 2.7.
iptables: condiciones de capa 4 . . . . . . . . . . . . . . .
21
Pr. 2.8.
iptables: DROP vs. REJECT . . . . . . . . . . . . . . . .
21
Pr. 2.9.
iptables: cadena FORWARD . . . . . . . . . . . . . . . .
22
Pr. 2.10. Seguimiento de conexiones
. . . . . . . . . . . . . . . . .
26
Pr. 2.11. Tabla NAT . . . . . . . . . . . . . . . . . . . . . . . . . .
27
29
Resumen de los parmetros de iptables . . . . . . . . . . . . . . . .
30
3. Proxies web
33
Pr. 3.1.
Los routers/cortafuegos y la capa 7
. . . . . . . . . . . .
33
Pr. 3.2.
El protocolo HTTP
. . . . . . . . . . . . . . . . . . . . .
34
vi
ndice
Pr. 3.3.
Instalando y probando squid . . . . . . . . . . . . . . . .
35
Pr. 3.4.
El protocolo HTTP con Proxy . . . . . . . . . . . . . . .
36
Pr. 3.5.
Deniendo ACLs . . . . . . . . . . . . . . . . . . . . . . .
37
Pr. 3.6.
Gestin de permisos . . . . . . . . . . . . . . . . . . . . .
38
Pr. 3.7.
Otras reglas
. . . . . . . . . . . . . . . . . . . . . . . . .
39
Pr. 3.8.
Proxy, encaminamiento y DNS . . . . . . . . . . . . . . .
40
Pr. 3.9.
Proxy transparente
41
Pr. 3.10. Proxies y HTTPS
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
Pr. 3.11. Almacenamiento de la cach

Pr. 3.12. Ficheros de registro
42
. . . . . . . . . . . . . . . .
42
. . . . . . . . . . . . . . . . . . . . .
44
Pr. 3.13. Informacin de estado de squid . . . . . . . . . . . . . . .
44
Pr. 3.14. Controlando el ancho de banda: delay pools
. . . . . . .
45
48
4. HTTP seguro
49
Pr. 4.1.
HTTP vs. HTTPS . . . . . . . . . . . . . . . . . . . . . .
49
Pr. 4.2.
SSL/TLS . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
Pr. 4.3.
Infraestructura de clave pblica
. . . . . . . . . . . . . .
51
Pr. 4.4.
HSTS: seguridad estricta HTTPS
. . . . . . . . . . . . .
52
Pr. 4.5.
HTTPS en Apache
. . . . . . . . . . . . . . . . . . . . .
53
54
5. Secure Shell (SSH)
55
Pr. 5.1.
Instalacin del servidor de SSH
Pr. 5.2.
Primera conexin: comprobando el ngerprint
. . . . . .
56
Pr. 5.3.
El chero known_hosts . . . . . . . . . . . . . . . . . . .
57
Pr. 5.4.
Encriptacin del chero known_hosts . . . . . . . . . . .
58
Pr. 5.5.
Manipulando un known_hosts encriptado . . . . . . . . .
59
Pr. 5.6.
Fingerprint en bubble babble . . . . . . . . . . . . . . . .
59
Pr. 5.7.
La importancia del ngerprint: interceptando una cone-
xin SSH
. . . . . . . . . . . . . .
55
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
Pr. 5.8.
Tnel SSH . . . . . . . . . . . . . . . . . . . . . . . . . .
61
Pr. 5.9.
Tnel dinmico con SSH (y SOCKS)
. . . . . . . . . . .
62
Pr. 5.10. FTP seguro
. . . . . . . . . . . . . . . . . . . . . . . . .
63
Pr. 5.11. Copia entre mquinas . . . . . . . . . . . . . . . . . . . .
64
Pr. 5.12. Autenticacin por clave pblica . . . . . . . . . . . . . .
65
67
6. Redes privadas virtuales (VPN)
69
Pr. 6.1.
Creacin de una VPN: el cliente . . . . . . . . . . . . . .
69
Pr. 6.2.
Instalacin del servidor . . . . . . . . . . . . . . . . . . .
72
ndice de guras
1.1.
Laboratorio virtual . . . . . . . . . . . . . . . . . . . . . . . .
1.2.
Laboratorio virtual con IPs
1.3.
Laboratorios virtuales en el aula
2.1.
Cadenas de
. . . . . . . . . . . . . .
19
6.1.
Conguracin de la red . . . . . . . . . . . . . . . . . . . . . .
70
6.2.
Abrir la conguracin de VPN
70
6.3.
Conguracin de una VPN en Ubuntu (cliente)
6.4.
Activacin de la VPN
iptables
(tabla
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
filter)
. . . . . . . . . . . . . . . . .
8
10
12
. . . . . . . .
71
. . . . . . . . . . . . . . . . . . . . . .
71
vii
Captulo 1
El laboratorio virtual
Comienza por el comienzo -dijo, muy
gravemente, el Rey- y sigue hasta que
llegues al nal; entonces paras.
Alicia en el Pas de las Maravillas; Lewis
Carroll
Resumen: En este captulo se congura un laboratorio virtual que

ser usado en el resto del curso.
En este primer captulo, vamos a instalar las mquinas virtuales sobre

las que realizaremos las prcticas del resto de captulos. Instalaremos tres
mquinas virtuales que constituirn un verdadero laboratorio donde probar
diferentes cosas. Tambin se introducirn las diferentes conguraciones de red
disponibles en el software de virtualizacin.
Dos de las mquinas virtuales tendrn Debian sin interfaz grco. La
tercera ser Ubuntu. El uso de dos mquinas sin interfaz grco nos permite
ahorrar mucha memoria, por lo que el laboratorio puede montarse en equipos
con pocos recursos, adems de forzar al alumnado a coger habilidad con el
manejo en consola.
: Instalar Debian
Prctica 1.1
El primer paso que daremos ser instalar una mquina virtual en VirtualBox con Debian. Los parmetros de creacin de la mquina son:
1. Nombre: DebianServidor
2. Sistema operativo: Linux (se rellena automticamente al poner el nombre)
1
Captulo 1. El laboratorio virtual
3. Versin: Debian (se rellena automticamente al poner el nombre). Ajusta la versin (32 o 64 bits) segn la situacin.
4. Memoria: dependiendo de la memoria del equipo fsico. Se puede incluso llegar a 128 MB aunque slo en situaciones extremas.
5. Crear disco virtual nuevo:
VirtualBox Disk Image )
Tipo VDI (
Reservado dinmicamente.
Localizacin: elegir un lugar donde haya hueco (por defecto, lo
pondr en la carpeta del usuario local).
Tamao: 8 GB es suciente, aunque se puede poner un valor ms
alto por seguridad, dado que el chero slo ocupar el espacio que
necesite realmente.
Una vez creada la mquina virtual:
1. Recorre la conguracin de la mquina recin creada. Comprueba que
el interfaz de red est congurado en NAT.
2. Arrncala. VirtualBox reconoce que es la primera ejecucin de la mquina virtual, por lo que muestra un asistente que nos ayuda a especicar la localizacin del instalador del sistema operativo. Canclalo
(lo haremos manualmente). Comprueba que la mquina no es capaz
de ejecutar nada al no tener sistema operativo lanzado (se muestra el
error
"FATAL: No bootable medium found! System halted.").
3. Introduce el.
iso
de instalacin de Debian en el CD de la mquina
virtual.
4. Lnzala de nuevo e instala Debian.
5. Observa cmo crece el tamao ocupado por el chero
.vdi
del disco
duro virtual.
: Conguracin de la red en Debian
Prctica 1.2
En Debian la conguracin de la red est en dos cheros:
/etc/network/interfaces:
IP, mscara y puerta de enlace
IFC03CM15 - Curso Seguridad en redes (Septiembre 2015)

/etc/resolv.conf:
servidores de nombres (DNS).
Analiza la conguracin actual (predenida tras la instalacin).

Para averiguar la conguracin
(sin parmetros) y
route
actual
del sistema se utiliza
(normalmente con
-n
ifconfig
para evitar la conversin
de IPs en nombres). Analiza la salida de su ejecucin, y comprala con la

conguracin original anterior. Tiene sentido el resultado? Coincide con la
de tus compaeros?
Para deshabilitar un interfaz de red se utiliza
habilitarlo de nuevo
ifup interfaz.
eth0
1. Deshabilita
y vuelve a ejecutar
ifdown interfaz,
ifconfig
y para
route.
2. Vuelve a habilitarla. Qu pueden signicar las lneas que aparecen?
Para realizar una conguracin

un esquema como el siguiente en
esttica
de una tarjeta de red se utiliza
/etc/network/interfaces:
iface eth0 inet static

address 192.168.1.2
netmask 255.255.255.0
gateway 192.168.1.1
Congura en Debian una IP ja diferente que encaje en la red de la IP
recibida de manera automtica.
Cuando cambies la conguracin, es preferible deshabilitar la tarjeta de
red
antes de modicar el chero, y volverla a habilitar despus. Tambin pue-
den hacerse ambas cosas despus de haber cambiado el chero, pero pueden
surgir problemas si la conguracin original era por DHCP.
ifup e ifdown son de alto nivel. La conguracin

ifconfig y route. Modica de nuevo la IP de
vlida dentro del segmento, usando slo ifconfig (puedes
pgina del maual). Qu ocurre si reinicias (con reboot)
La pareja de comandos
de bajo nivel se realiza con

Debian por otra
ayudarte con la
Debian tras conseguirlo?
: Modelos de red en Virtual Box
Prctica 1.3
software para el sistema

hardware ? Dnde est conecta-
La conguracin realizada en Debian es a nivel

operativo husped. Pero, qu pasa con el
da la tarjeta de red realmente? Eso lo determina el software de virtualizacin, que nos proporciona varias opciones.

Al crear la mquina virtual de Debian, el interfaz de red se congur en

NAT. Eso lo podemos cambiar en cualquier momento (incluso en caliente
con la mquina virtual lanzada) por otras opciones:
Adaptador puente: la tarjeta de red del husped se mapea directamente

a la red fsica del antrin. Cualquier cosa que el husped enve a su
tarjeta de red ser por tanto enviada (sin modicacin) por la tarjeta
de red fsica. En condiciones normales, una tarjeta de red congurada
en modo puente (
bridged )
deber recibir una IP dentro del segmento
de red al que pertenezca el antrin.
Router del aula
Red fsica
Anfitrin
Mquina virtual
1. Congura la tarjeta de red de Debian Servidor en modo puente.

2. Comprueba que
no
tienes salida a Internet.
3. Por qu es? Cmo lo solucionaras?
NAT:
la tarjeta de red del husped se conecta a un segmento de red
virtual gestionado por el software de virtualizacin. A ese segmento

hay conectado un dispositivo (tambin gestionado por software) que
hace de servidor de DHCP para l, y adems de puerta de enlace. Para
eso, hace NAT (traduccin automtica de direcciones) utilizando la IP
del antrin. En condiciones normales, las tarjetas de red conguradas
con conexin NAT se congurarn en el sistema operativo husped
como dinmicas para recibir una IP del servidor DHCP del sofware de
virtualizacin, y conseguirn acceso a la red fsica del aula gracias a la
traduccin de direcciones, saliendo con la IP del propio antrin.

Router del aula
Red fsica
Software
haciendo NAT y
servidor DHCP
Anfitrin
Mquina virtual
1. Vuelve a congura la tarjeta de red de Debian Servidor en modo

NAT.
2. Tienes salida a Internet? Por qu?
Red NAT :
el modo anterior
se replica
por cada mquina virtual. Es
decir dos mquinas virtuales en modo NAT
tes.
estarn en redes diferen-
En este modelo, se pueden crear redes NAT compartidas entre
varias mquinas, que estarn conectadas al mismo segmento y saldrn

a internet con la IP del antrin.
Red interna: la tarjeta de red del husped se conecta a un segmento de

red virtual creado por el software, al que no hay nada ms conectado
(salvo, quiz, otras mquinas virtuales).
Router del aula
Red fsica
Red interna
Anfitrin
Mquina virtual
Adaptador slo antrin:
es similar a la anterior, pero al segmento de
red virtual se conecta tambin
el host antrin, que recibe un interfaz

de red adicional. Adems, se conecta un servidor DHCP controlado por

el software de virtualizacin. En contra de lo que ocurre en la conexin
NAT, en este caso
no
hay ningn router de salida.
Puedes encontrar informacin detallada sobre la red en Virtual Box en
http://www.virtualbox.org/manual/ch06.html.

: Creacin de Debian Cliente
Prctica 1.4
Nuestro laboratorio virtual tendr dos Debian y un Ubuntu. Ya tenemos Debian instalado en la primera mquina virtual. Aprovecharemos esa
instalacin para clonarla y tener as la segunda mquina Debian.
1. Ve a Archivo - Administracin de medios virtuales. Comprueba que

aparece el disco duro de Debian Servidor.
2. Para clonarlo utilizaremos la herramienta
vboxmanage
(en consola):
<rutaVBox>\vboxmanage clonehd
<rutaMaquinas>\DebianServidor.vdi
<rutaMaquinas>\DebianCliente.vdi
El disco duro origen
(con
poweroff)
no
debe estar en uso. Por tanto debers detener
Debian Servidor antes de hacerlo.
Tambin puedes utilizar directamente el interfaz grco de Virtual Box,

con Archivo - Administrador de medios virtuales - Copiar.
3. Tras unos momentos, observa la aparicin del nuevo chero. Dependiendo de la versin de Virtual Box, en el administrador de medios
virtuales puede que haya aparecido el nuevo disco duro. La informacin inferior mostrar que no est conectado a ninguna mquina.
4. Crea una nueva mquina virtual llamada DebianCliente con unas caractersticas similares a DebianServidor. En lugar de crear un disco
duro virtual nuevo, selecciona el ya existente, DebianCliente. Comprueba en la administracin de medios virtuales que el disco duro aparece
asignado a dicha mquina.
Una vez que tenemos la mquina virtual, creada, vamos a ajustar su

conguracin.

1. Lanza Debian Cliente. Para no crear confusin,
no
lances an Debian
Servidor.
2. Observa que el nombre que recibe es
DebianServidor.
Al ser una clo-
nacin, se mantiene el nombre antiguo.

3. Modica el nombre en
/etc/hostname
y ejecuta el
script :
# /etc/init.d/hostname.sh
4. El nombre parece no cambiar. Sin embargo, es slo en el
shell.
Cierra
la sesin y entra de nuevo para ver el cambio.

5. Haz
ifconfig
para ver la conguracin de red y comprueba que est
congurada.
6. Lanza Debian Servidor y mira su IP. Hay algo que te llame la atencin?
: Creacin de Ubuntu
Prctica 1.5
Crea una nueva mquina virtual llamada Ubuntu. Asociala tanta memoria como puedas. En este caso, al tener interfaz grca, tendremos que ser
bastante generosos. Con versiones anteriores de Ubuntu poda ponerse 256
MB, pero hoy eso es ya demasiado poco. Adems, es interesante subir la cantidad de memoria de video, pues el valor por defecto (12 MB) es insuciente
para resoluciones superiores a 1024x768, e instalar las
Guest additions . Por
ltimo, si el antrin tiene un procesador con varios ncleos, merece la pena

darle al menos dos para mejorar la uidez de la respuesta.
En lugar de instalar Ubuntu usando el
.iso,
puedes utilizar el
.vdi
proporcionado entre el material.

Comprueba la conguracin de red, y asegrate de que tienes salida a
Internet.
: Una segunda tarjeta de red en debian servidor
Prctica 1.6
Para el laboratorio virtual, querremos que Debian Servidor
ter. Para eso necesita dos tarjetas de red.
haga de rou-

Router del aula
Red fsica (puente)
Debian Servidor
Red interna (virtual)
Debian Cliente
Ubuntu
Mquinas virtuales
Figura 1.1: Laboratorio virtual
1. Apaga Debian Servidor si no lo estaba ya.

2. Congura una segunda tarjeta de red en modo
red interna.
3. Lanza la mquina de nuevo. Aparece congurada la segunda tarjeta

de red? La detecta Debian?
: Congurar el laboratorio virtual
Prctica 1.7
La conguracin que vamos a usar durante todo el curso con las tres
mquinas virtuales es la mostrada en la gura 1.1.
En ella, Debian Servidor tiene su primera tarjeta de red conectada
modo puente,
en
es decir conectada directamente a la red fsica del aula, por
lo que es necesario proporcionarle una IP que no colisione con las del resto
de ordenadores del aula, y tampoco con los Debian Servidor de todos los

alumnos. Adems, en algunos momentos, querremos que las mquinas virtuales internas (Debian cliente y Ubuntu) de un alumno se conecten con
las de otro, por lo que tampoco queremos colisiones entre las IPs internas.
Para que todo resulte fcil, lo mejor es utilizar un convenio. Las aulas sue-
192.168.x.0/24. As, un alumno tendr, por ejemplo,

192.168.x.107, y otro tendr 192.168.x.112. Dado que el nmero de
len tener IPs del tipo

la IP
mquinas en el aula es reducido, lo que haremos ser que el Debian Servidor

de cada alumno tenga la misma IP que su ordenador fsico, sumando 100
al ltimo byte (192.168.x.207 y
192.168.x.212
en los ejemplos). Obvia-
mente, es necesario adaptar esto a cada aula (que requerirn en cualquier

caso IPs jas para los equipos), pero es una forma bastante sencilla de evitar
problemas.
Por otro lado, cada alumno
es dueo de una nueva red,
la red interna
creada con el segmento de red virtual interno. Para evitar conictos, asig-
10.x.n.0/24, donde x es el tercer byte

n el ltimo. As, en los ejemplos anteriores,
10.x.107.0/24 y 10.x.112.0/24. De nuevo, esta idea habr
naremos a dicho segmento la red

de la IP del antrin (aula), y
asignaramos
que adaptarla a cada contexto.

Una vez elegida la red IP del segmento, hay que asignar IPs a las mquinas. Como ser la puerta de enlace, asignaremos la primera IP a la segunda
tarjeta de red de Debian Servidor, la siguiente a Debian Cliente, y la tercera
a Ubuntu.
A modo de ejemplo concreto, si el ordenador de un alumno tiene congurada la IP
192.168.24.101,
la asignacin de IPs deber ser la mostrada
en la gura 1.2.
Para hacer esto, son necesarias dos cosas:
1. Congurar el software de virtualizacin para crear las conexiones fsicas. En el mundo real, sera similar a colocar los cables para conseguir
las conexiones de la gura.
2. Congurar las mquinas para asignar las IPs, es decir realizar la conguracin software de los Linux de las tres mquinas virtuales. Ya
hemos visto cmo hacerlo en Debian. Una fuente de informacin muy
completa sobre ello puede encontrarse en
https://www.debian.org/
doc/manuals/debian-reference/, en particular en las secciones 5.5 y

5.6. En Ubuntu (y entornos de escritorio) es preferible utilizar la aplicacin con interfaz grco de usuario para congurar el demonio del
network manager

10
Router del aula
.100
Red fsica (192.168.24.0/24)
.201
IP del anfitrin:
192.168.24.101
Debian Servidor
.1
Red interna (10.24.101.0/24)
.2
.3
Debian Cliente
Ubuntu
Mquinas virtuales
Figura 1.2: Laboratorio virtual con IPs
: Batera de pruebas 1: red bsica
Prctica 1.8
Vamos a hacer diferentes
ping entre las mquinas. Esto permite compro-
bar que todo est bien congurado. Es interesante conseguir que los alumnos
entiendan todas estas pruebas y sean capaces de hacerlas ellos mismos cuando tengan problemas, para evitarnos seguir resolviendo problemas triviales
durante todo el ao.
Se asume que inicialmente la conguracin de la red virtual es la mostrada
en la gura 1.2. Haz los siguientes
ping, intentando previamente anticipar si
funcionarn o no, y por qu.
1. Desde Debian Cliente a la
eth1
de Debian Servidor.
2. Desde el antrin (Windows) a
eth0
de Debian Servidor.
eth1
de Debian Servidor.
4. Desde el antrin (Windows) a Debian cliente.

5. Desde Debian Cliente a
eth0
de Debian Servidor.

11
6. Desde Debian Cliente a alguna IP externa (por ejemplo, la puerta de

enlace del aula).
: Batera de pruebas 2: red en NAT
Prctica 1.9
Si ponemos a Debian Servidor y a Debian Cliente en NAT, no se vern

entre ellos porque VirtualBox crea contextos diferentes para cada una. Si
queremos que ambas se vean y, aun as, salgan a Internet a travs de NAT
tenemos que crear una
Red NAT.
1. En Virtual Box, ve a Archivo - Preferencias - Red, y aade una nueva red NAT. Congura el CIDR asociado (que utilizar el servidor
de DHCP) a una red que no colisione con las dems (por ejemplo,
172.16.x.0/24).
2. Modica Debian Servidor y Debian Cliente para conectar sus tarjetas
de red (eth0) a esa nueva red.
3. Deshabilita ambas tarjetas de red.
4. Modica la conguracin para que utilicen DHCP.
5. Comprueba las IPs asignadas. Tienen sentido?
Haz las pruebas siguientes, intentando anticipar el resultado.
Operacin a realizar
Funciona?
Ping entre las mquinas virtuales

Ping desde cualquier mquina virtual al router del aula
Desde Debian Cliente, telnet al puerto 111 de Debian Servidor
Por qu?
Desde el antrin (Windows) telnet al puerto 111 de Debian

Servidor
Por qu?
Desde el antrin (Windows) ping a cualquier mquina virtual

Por qu?

12
Router del aula
Red fsica (puente)
Debian Servidor
Debian Servidor
Debian Cliente
Debian Servidor
Debian Cliente
Ubuntu
Mquinas virtuales
Debian Cliente
Ubuntu
Mquinas virtuales
Ubuntu
Mquinas virtuales
Figura 1.3: Laboratorios virtuales en el aula
Prctica 1.10
: Batera de pruebas 3: encaminamiento y NAT
Vuelve a la conguracin inicial de la red de la prctica 1.8. De nuevo,

recuerda establecer la conguracin fsica y la lgica. Algunos de los
pings
que hicimos no funcionaron porque Debian servidor no est encaminando,

lo que hace que los ordenadores de la red interna no puedan conectarse a
Internet. Hacer que un Linux encamine es cuestin de una linea:
# echo 1 > /proc/sys/net/ipv4/ip_forward

(para desactivarlo, escribimos un
0)1 .
La activacin del encaminamiento de este modo
no
sobrevive a reinicios. Pue-

13
Introduce dicha linea en Debian Servidor, y luego haz la siguiente batera de pruebas (algunas son las mismas que en el primer bloque). Como
antes, intenta anticiparte a las respuestas. Te puede servir como refencia la
gura 1.3, que muestra el esquema de la red considerando las mquinas virtuales de varios alumnos. Busca la razn por la que algunas de las pruebas
no funcionan, y trata de solucionarlo.
eth0
de Debian Servidor.
2. Desde el antrin (Windows) a Debian cliente.

3. Desde Debian cliente al antrin.
4. Desde el antrin al
eth0 Debian servidor de un compaero (al n+1).
5. Desde Debian servidor al Debian servidor n+1.

6. Desde Debian servidor al Debian cliente n+1.
7. Desde Debian cliente al Debian servidor de un compaero
distinto (por
ejemplo, n+2).
8. Desde Debian cliente al Debian cliente de otro compaero (n+3).
9. Desde Debian cliente a Internet (puerta de enlace, 8.8.8.8, google,
...).
10. Pon a Debian Servidor con
eth0
en modo NAT (en lugar de puente),
congura una IP por DHCP y repite la prueba anterior.

11. Vuelve a poner la tarjeta
eth0
de Debian Servidor en puente, y recon-
gura su IP ponindola ja.
Si es posible recongurar los routers del instituto para que conozcan

nuestras redes internas, entonces lo ms cmodo es hacerlo. Basta con aadir
la regla de que para llegar a
10.x.n.0/24
hay que ir por
192.168.x.n+100.
Ten en cuenta que adems habr que ajustar el router ADSL.

Si no es posible, entonces la nica opcin para que Debian Cliente (y
Ubuntu) tengan salida a internet es que el ltimo equipo que s conozca las
redes haga NAT, para ocultarlas. Por ejemplo, si nuestro router del aula
es un Linux o un Windows y hemos aadido las rutas, podemos congurarlo
(como profesores) para que haga NAT y el router ADSL siguiente no se vea
afectado.
En otro caso, ser Debian Servidor quin tenga que hacer NAT. As las
IPs de la red privada de cada alumno nunca se pondrn en la red fsica, y
des activar el encaminamiento automticamente en el arranque ajustando el chero
/etc/sysctl.conf.

14
todo funcionar (aunque no podremos entrar ms en esa red desde fuera).

Para eso, en Debian Servidor escribimos una linea mgica:
# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
no
Al igual que la activacin del encaminamiento IP, esta orden
es per-
sistente; ser necesario ejecutarla cada vez que lancemos Debian Servidor (o
crear un script de arranque automtico).
Si queremos
desactivar
de nuevo el NAT:
# iptables -t nat -F

Para saber ms...

Manual de Virtual Box:
http://www.virtualbox.org/manual/UserManual.html
Conguracin de Debian:
https://www.debian.org/doc/manuals/debian-reference/
Internet Core Protocols - The Denitive Guide; Eric Hall; O'Reilly
TCP/IP First-Step; Mark A. Sportack; Cisco Press
En el prximo captulo. . .
En el prximo captulo veremos el concepto de
remos a utilizar el comando
iptables
cortafuegos,
y aprende-
de Linux, que nos proporciona una
granularidad muy na en lo referente a qu datagramas siguen su camino y

cuales no.

Captulo 2
Cortafuegos. iptables
La desconanza es la madre de la
[in]seguridad.
Aristfanes
Resumen: En este captulo se recorre
iptables,
el cortafuegos de
Linux. Para eso se realizan prcticas de complejidad incremental.
La mquina Debian Servidor del laboratorio virtual es la responsable de

encaminar el trco de la red interna, por lo que hace a la vez de
para protegerla. En este captulo utilizaremos
cortafuegos
iptables para ver las opciones
disponibles y los aspectos con los que hay que tener cuidado.
Empezamos instalando varios servicios en la red para tener algo que
proteger. Adems, analizaremos brevemente los protocolos TCP y UDP para
poder comprender las opciones de
iptables
que se vern despus.
En ocasiones haremos uso de las mquinas de otra persona. Esto requiere

agilidad con la numeracin, a la vez que complica su realizacin de forma
aislada (por ejemplo en casa).
: Instalacin de demonios
Prctica 2.1
Para poder hacer pruebas con el cortafuegos, vamos a instalar en Debian

Servidor dos demonios (servicios) que se queden escuchando en puertos
TCP. En concreto, instalaremos el servidor de Telnet (puerto 23) y el servidor
Web Apache (puerto 80) :
Si tienes problemas porque el sistema busca los paquetes en el CD-Rom, modica
/etc/apt/sources.list para quitar la referencia al CD, y luego usa apt-get

update para actualizar la lista de paquetes. Tambin puedes meter el .iso en la mquina
el chero
virtual, y no tocar nada.
15
16
Captulo 2. Cortafuegos. iptables
# apt-get install telnetd apache2

En Debian, el demonio de Telnet se lanza a travs del superdemonio de Internet inetd (en concreto, la versin realizada originalmente para
openbsd-inetd). El instalador de Telnet en algunas versiones de

inetd, por lo que tenamos que hacerlo
OpenBSD,
Debian se olvidaba de reiniciar

manualmente:
# /etc/init.d/openbsd-inetd restart
Comprueba que la instalacin se ha realizado bien conectndote desde
el antrin con el navegador a la IP de Debian Servidor (vers la pgina
predenida de Apache). Conctate tambin por telnet (si el antrin no
tiene el cliente de telnet prueba desde Debian Cliente o Ubuntu). Comprueba
tambin desde Ubuntu que te puedes conectar al servidor Web usando un
navegador.
: Analizando trco de red
Prctica 2.2
Vamos a analizar brevemente diferentes tipo de trco:

1. Instala en Ubuntu
Wireshark :
# apt-get install wireshark

2. Lanza Wireshark (a travs de
3. Desde Debian Cliente, haz
www.wikipedia.org).
4. Detn el
ping,
sudo)
ping
y ponlo a escuchar.
a un destino cualquiera (por ejemplo
la captura en Wireshark, y analiza el trco que ves.
5. Desde Debian Cliente, conectate por telnet a Debian Servidor (con el

usuario
alumno).
Luego desconectate con
exit.
6. Analiza el trco que ves. Comprueba la existencia de los tres segmentos de conexin, los de cierre, y utiliza el seguimiento de la conexin
proporcionado por Wireshark para ver cmodamente la comunicacin.
Notas a nivel de coste en ancho de banda alguna diferencia entre TCP
y UDP?
Por comodidad, se pueden meter alias de direcciones MAC en el chero
/etc/ethers.
Por ejemplo:

17
08:00:27:17:41:87 MAC_DebianServidor
08:00:27:AE:42:43 MAC_DebianCliente
08:00:27:D7:62:D8 MAC_Ubuntu
Tras reiniciar Wireshark, en la diseccin de la capa 2 podrs ver el alias
de cada MAC, para identicarlas ms cmodamente. Con esto, Wireshark
puede utilizarse en clase para asentar la teora sobre encaminamiento IP, y
que el origen/destino de un datagrama no tiene por qu coindicir a nivel 2
y 3.
Tambin por comodidad se puede permitir que usuarios sin privilegios
puedan monitorizar el trco de red con Wireshark sin necesidad de lanzarlo
como administradores.
1. En un terminal, lanza la reconguracin del paquete de Wireshark:
# dpkg-reconfigure wireshark-common
2. Contesta S ante la pregunta de si quieres que los usuarios no administradores puedan capturar paquetes (y s consciente de las implicaciones).
3. Aade al usuario
alumno
en el grupo
wireshark
recin creado.
# adduser alumno wireshark

4. Cierra la sesin y vuelve a abrirla. A partir de ahora podrs lanzar
Wireshark directamente desde el men de inicio.
: Comprobacin de puertos abiertos
Prctica 2.3
Para saber qu puertos TCP tienen un proceso a la escucha usamos:
# netstat -tlnp
-t
: TCP
-l : listen
(escucha)
-n : numrico,
para que nos indique el nmero de puerto en lugar del
nombre del servicio (extrado de
/etc/services).
Este parmetro es
opcional.

18
-p
process,
para que nos indique el PID del proceso que est a la
escucha, y su nombre. Slo funciona si somos
root.
Este parmetro es
opcional.
Comprueba que en Debian Servidor los puertos de telnet y de apache
estn a la escucha, y que coinciden con los procesos esperados (est
en lugar de
telnetd).
inetd
En Windows puedes conseguir algo parecido con:
> netstat -p tcp -n -a -b

Tambin puedes utilizar la herramienta grca
TCPView.

: Comprobacin de los puertos abiertos en remoto
Prctica 2.4
Instala en Debian Cliente
nmap:
# apt-get install nmap

salo para realizar un
escaneo de puertos
de Debian Servidor y averiguar
qu puertos TCP tiene abiertos. Coincide el resultado?

Prueba a escanear los puertos de
www.educa.madrid.org.
Obtienes al-
gn resultado? Haz de nuevo el escaneo, utilizando como parmetro
-PN.
Obtienes ahora algo? Para qu sirve ese parmetro?
nmap es una herramienta muy til para anlisis de red. Tambin podemos
utilizarlo para encontrar equipos encendidos en una red:
# nmap -sP 10.x.n.0/24

: iptables: poltica por defecto
Prctica 2.5
iptables es la herramienta usada para congurar el cortafuegos de Linux
(netfilter). Su funcionamiento se basa en
cadenas de reglas, por las que se
hace atravesar a los datagramas que llegan al ncleo para decidir si se les
deja (o no) seguir su camino.
La gura 2.1 esquematiza las cadenas de reglas existentes. Se utilizar
una u otra dependiendo del origen y el destino del datagrama a procesar:

19
Capas 5 7
Capas57
Proceso local
INPUT
OUTPUT
Capas34
FORWARD
E
Encaminamiento
i
i t
Capas12
Interfaces de red
Figura 2.1: Cadenas de
iptables
(tabla
filter)
INPUT: el datagrama ha llegado por un interfaz de red cualquiera, y va

destinado a un proceso local.
OUTPUT:
el datagrama ha sido generado por un proceso local y debe
enviarse por un interfaz de red.
FORWARD:
el datagrama ha llegado por un interfaz de red, y debe ser
reenviado (estamos actuando como
routers ).
Al nal del captulo puedes encontrar tablas resumiendo los parmetros
de
iptables. En esta primera prctica vamos a probar la poltica por defecto,
es decir la decisin que se toma con aquellos paquetes para los que no haya
alguna regla especial.
1. Comprueba que puedes hacer
ping desde Ubuntu a Debian Servidor y
a un destino remoto (por ejemplo, Google).

2. Establece en Debian Servidor
INPUT.
DROP
como poltica por defecto para
# iptables -P INPUT DROP

3. Comprueba cmo aparece el cambio en el listado de reglas:
# iptables -L
Chain INPUT (policy DROP)
target
prot opt source
destination

20
Chain FORWARD (policy ACCEPT)

target
prot opt source
destination
Chain OUTPUT (policy ACCEPT)

target
prot opt source
destination
4. Siguen funcionando las dos pruebas anteriores?

5. Restablece
ACCEPT
en la cadena
INPUT,
y establece
DROP
en
OUTPUT.
Qu ocurre?
6. Restablece
ACCEPT
en la cadena
OUTPUT,
y establece
DROP
en
FORWARD.
Qu ocurre?
: iptables: condiciones de capa 2 y 3
Prctica 2.6
1. Normalmente las cadenas
INPUT
OUTPUT
se realizarn de manera si-
mtrica, es decir si no queremos permitir la salida a un determinado
OUTPUT), tambin impediremos la entrada de sus resINPUT), incluso aunque estas respuestas sea imposible
servicio (cadena
puestas (en
que lleguen.
Congura Debian Servidor para que responda cualquier cosa que llegue
desde la red interna, pero ignore lo que llegue desde la red externa (es
la conguracin que querras tener en cualquier router ADSL). Man-
OUTPUT para que sean simtricas.

Realzalo utilizando poltica por defecto DROP. Comprueba que un ping
tn sincronizadas las tablas
INPUT
entre el sistema antrin y cualquiera de las mquinas interiores continua funcionando.

2. Haz lo mismo que en el punto anterior con poltica por defecto
ACCEPT.
3. Congura Debian Servidor para que responda a todos los datagramas

enviados por Debian Cliente pero ignore a Ubuntu (o cualquier otro
potencial sistema de la red interna) y a toda la red externa. Hazlo tanto
con poltica por defecto
tablas
INPUT
En este ejercicio,
cadena es
ACCEPT.
DROP como ACCEPT, y mantn sincronizadas las
2
y OUTPUT .
no
utilices en ningn caso
-j ACCEPT
si la poltica por defecto de la

21
4. Congura Debian Servidor para que responda a
ping
desde la red
externa, pero no permita conectarse por Telnet desde dicha red. Desde
la red interna todo deber estar permitido. Implemntalo con ambas
polticas por defecto.
: iptables: condiciones de capa 4
Prctica 2.7
1. Pon en Debian Servidor
DROP como poltica por defecto para FORWARD.
Congura el cortafuegos para que Debian Cliente pueda hacer resoluciones DNS (puerto 53 de UDP).
2. Comprueba que los puertos de telnet y Web estn abiertos en Debian
Servidor. Congura el cortafuegos para que desde Debian Cliente sea
posible una conexin slo al puerto 80 (web), y desde Ubuntu slo al
23 (telnet). Utiliza como poltica por defecto
DROP

: iptables: DROP vs. REJECT
Prctica 2.8
El destino
DROP descarta el datagrama sin informar al receptor. El destino
REJECT ocasiona el envo
de un mensaje ICMP congurable (por defecto, de
puerto inalcanzable). Esto
avisa
al otro extremo que no le vamos a atender,
ahorrndole la espera de una respuesta que no llega. Tambin es una prueba

de que el sistema est encendido.
1. Lanza Wireshark en Ubuntu y ponlo a escuchar.
2. Desde Debian Cliente, asegrate de que puedes conectarte por telnet
a Debian Servidor.
3. Cierra esa sesin de telnet. En Debian Servidor pon una regla en la cadena INPUT para descartar (DROP) los segmentos destinados al puerto
de Telnet:
# iptables -F INPUT
# iptables -A INPUT -p tcp --dport telnet -j DROP

22
4. Vuelve a intentar la conexin desde Debian Cliente. sta no se llevar a

cabo. Comprueba en Wireshark que aparecen los reintentos de conexin
(mltiples mensajes
SYN)
enviados desde Debian Cliente, que no son
atendidos. Hasta que el cliente de telnet no desiste de realizar envos

no se abandona el intento de conexin.
5. En Debian Servidor cambia la regla en la cadena INPUT para que en
lugar de descartar el paquete se
rechace activamente (REJECT):
# iptables -F INPUT
# iptables -A INPUT -p tcp --dport telnet -j REJECT
Mientras no se diga otra cosa, los paquetes se rechazan con el mensaje
ICMP de
puerto inalcanzable.
6. En Debian Cliente intenta otra vez la conexin. Vers que ahora recibes
enseguida el rechazo en la conexin:
$ telnet 10.x.n.1
Trying 10.x.n.1...
telnet: Unable to connect to remote host: Connection
refused
REJECT no se admite como poltica por defecto. Cuando la poltica por
ACCEPT y se llega a un puerto en el que no hay ningn servicio escu-
defecto es
chando se enva automticamente el mensaje ICMP de puerto no disponible

(similar a lo que hara
REJECT).

: iptables: cadena FORWARD
Prctica 2.9
Vamos a congurar el cortafuegos de Debian Servidor para que permita a

la red interna acceder a Internet, pero la proteja, al mismo tiempo, de acceso
desde el exterior.
1. Instala en Debian Cliente apache (apt-get
install apache2)
para
tener un servicio en la red interna a proteger. Comprueba que puedes

acceder a l desde el antrin.
del compaero
siguiente (sumando 1 a tu IP). Ten en cuenta que el compaero anterior
2. Prueba que tienes acceso al Apache del Debian Cliente
intentar a la vez acceder a tu Debian Cliente. Recuerda que aqu

podran entrar en juego problemas de rutas.

23
3. Usando
nmap, escanea los puertos de Debian Cliente de tu compaero.
4. Asegrate de que desde Debian Cliente y Ubuntu tienes acceso a Internet.

Lo que queremos conseguir ahora es que desde la red interna se tenga
acceso a Internet, pero queremos proteger del exterior los servicios internos.
Es decir, no queremos que desde fuera se vea el servicio de Apache que
hemos instalado en Debian Cliente. Esta proteccin queremos hacerla en
Debian Servidor, que har de cortafuegos de nuestra red.
1. Pon en
DROP
la poltica por defecto para
FORWARD
y realiza de nuevo
las pruebas anteriores.

2. Congura
FORWARD
para que desde la red interna pueda accederse a
Internet. Para eso, abre el puerto 53 de UDP (DNS) y el 80 de TCP

(Web).
3. Primer intento:
#
#
#
#
iptables
iptables
iptables
iptables
-P FORWARD DROP
-F
-A FORWARD -p udp --dport 53 -j ACCEPT
-A FORWARD -p tcp --dport 80 -j ACCEPT
4. Esto no consigue que Internet funcione en la red interna, porque no

est abriendo la vuelta. Tenemos que ser cuidadosos
sentidos. Para eso, vigilamos los interfaces de red.
y aadir
los dos
5. Segundo intento:
# iptables -P FORWARD
# iptables -F
# iptables -A FORWARD
--dport 53
--sport 53
--dport 80
--sport 80
DROP
-i
-j
-i
-j
-i
-j
-i
-j
eth1 -o
ACCEPT
eth0 -o
ACCEPT
eth1 -o
ACCEPT
eth0 -o
ACCEPT
eth0 -p udp
eth1 -p udp
eth0 -p tcp
eth1 -p tcp
6. Con esto conseguimos que funcione Internet en la red interna (puedes

usar el navegador de Ubuntu, y
lynx
en Debian Cliente). Adems,
en principio, el servicio de Apache de Debian Cliente ser accesible

desde la red interna (Ubuntu), pero no desde el exterior. Comprubalo
conectndote desde el antrin al Apache de Debian Cliente.

24
7. Seguro? Prueba a escanear los puertos de tu compaero desde el

exterior (para l) con el parmetro
qu puerto
origen
-g,
que nos permite especicar
queremos usar en el escaneo:
# nmap -g 80 10.x.(n+1).2
Si t has conseguido ver el puerto 80 de tu compaero abierto, tambin
habrn visto abierto el tuyo desde n-1!
Qu ha pasado? Usando desde fuera un puerto
fuegos tiene abierto
para las respuestas
origen
que el corta-
podemos colarnos.
8. Tercer intento: en las reglas vericamos el puerto del cliente:
# iptables -P FORWARD DROP

# iptables -F
# iptables -A FORWARD -i eth1
--sport 1024:65535
--dport 1024:65535
--sport 1024:65535
--dport 1024:65535
-o eth0 -p
--dport 53
-o eth1 -p
-j ACCEPT
-o eth0 -p
--dport 80
-o eth1 -p
-j ACCEPT
udp
-j ACCEPT
udp --sport 53
tcp
-j ACCEPT
tcp --sport 80
9. Con esto evitamos que un atacante pueda utilizar puertos origen que
parecen conables para escanear nuestros puertos.
10. Seguro? Es as en todos los casos? Prueba:
# nmap -P0 -p80 -g 80 10.x.(n+1).2

-P0: no hacemos comprobacin de host
encendido con
ping (pues
el cortafuegos no deja pasar ICMP).
-p80: queremos saber nicamente el estado del puerto 80 del host

escaneado.
-g 80:
nmap
queremos usar como puerto
origen
el puerto 80.
nos dice que el puerto est ltrado; es decir no hemos recibido
respuesta (ni positiva ni negativa). El cortafuegos no nos ha dejado

entrar. Esta es la mejora respecto al caso anterior, en el que s vimos
el puerto abierto.
11. Prueba ahora sobre otro puerto:
# nmap -P0 -p8080 -g 80 10.x.(n+1).2

25
nmap
nos dice que el puerto
est cerrado,
es decir
hemos llegado
al
Debian Cliente del compaero, y nos ha contestado no hay nada en

ese puerto.
12. Algunos servicios utilizan puertos por encima de 1024, por lo que quedaran al descubierto (de estar activos).
13. Cuarto intento: negar la entrada de segmentos de
SYN.
Esto slo es
posible en TCP.

# iptables -F
--sport 1024:65535
--dport 1024:65535
--sport 1024:65535
--dport 1024:65535
-o eth0 -p
--dport 53
-o eth1 -p
-j ACCEPT
-o eth0 -p
--dport 80
-o eth1 -p
! --syn -j
udp
-j ACCEPT
udp --sport 53
tcp
-j ACCEPT
tcp --sport 80
ACCEPT
14. La nica diferencia respecto a la versin anterior es
! --syn
en la
nmap contra tu compaero y vers que

iptables no deja entrar a ninguno de nuestros segmentos del escaneo.
ltima regla. Vuelve a ejecutar
El uso de la bandera
SYN
nos evita entradas a puertos TCP de escaneos
normales. Hay otros escaneos ms extraos que an podran hacerse, pero

son mucho menos precisos.
Una desventaja ms clara es que
no
tenemos proteccin para servicios
que funcionen sobre UDP.
1. En Debian Cliente, pon un proceso a escuchar en un puerto UDP:
# nc -lup 7777
2. Cuando
tu compaero n+1
lo haya hecho, intenta llegar a l:
# nc -u 10.x.(n+1).2 7777
Si escribes algo, no le llegar.

3. Vuelve a probar, usando como puerto
origen el de DNS, y te funcionar:

26
# nc -u 10.x.(n+1).2 7777 -p 53
Podramos evitar esto poniendo

tuada
antes
una regla concreta
para ese puerto, si-
(el orden es importante!!) de las reglas de apertura de DNS.
# iptables -A FORWARD -i eth0 -o eth1 -d 10.x.n.2

-p udp --dport 7777 -j DROP
[ ... resto de reglas ... ]
Fjate que tenemos una regla
defecto sea
DROP.
-j DROP
As nos adelantamos al
incluso aunque la poltica por
ACCEPT
de reglas ms genricas
que vengan despus.

Por tanto, aunque la solucin existe, necesitamos una regla
explcita
por
cada servicio UDP interno; no podemos evitar el acceso de manera general.
: Seguimiento de conexiones
Prctica 2.10
Con la conguracin del cortafuegos

pueden entrar segmentos TCP
ACK
sin estado
que hemos usado, an
que digan venir de un puerto legal (80)
destinados a un puerto no privilegiado y que en realidad no estn asociados

a ninguna conexin existente. Adems en UDP no tenemos
SYN
por lo que
no podemos controlar quin inicia la comunicacin.

Con el mdulo
state
estado, de manera que:
convertimos a
iptables
en un cortafuegos
con
Introduciremos una nica regla por cadena para dejar pasar datagramas asociados a una conexin ya existente.
Introduciremos una nica regla por servicio que queramos abrir, dejando pasar (sin estado) nicamente al primer datagrama esperado.
La conguracin del cortafuegos con estado para dejar salir DNS y Web
desde la red interna quedara:
# iptables -P INPUT DROP

# iptables -P OUTPUT DROP
# iptables -A FORWARD -m state --state ESTABLISHED,RELATED
-j ACCEPT

27
# iptables -A FORWARD -i eth1 -o eth0 -p udp --sport 1024:65535

--dport 53 -j ACCEPT
# iptables -A FORWARD -i eth1 -o eth0 -p tcp --sport 1024:65535
--dport 80 --syn -j ACCEPT
Por cada servicio hay una sola regla que deja pasar el
inicio. Debido a ello en el caso de TCP dejamos salir
el
SYN.
datagrama de
Otra forma de
escribirlo es:
# iptables -A FORWARD -i eth1 -o eth0 -p tcp --sport 1024:65535

--dport 80 -m state --state NEW -j ACCEPT
En
/proc/net/ip_conntrack se pueden ver las conexiones conocidas por
el mdulo de estado. Genera algo de trco navegando en Ubuntu y mira el

contenido para ver las conexiones.
Ahora el cortafuegos controla tambin quin inicia las conversaciones
UDP, de modo que podremos tambin impedir la entrada UDP viniendo de
puertos supuestamente conables. Ya no necesitaramos la regla de denegacin explcita para impedir entrar al servicio UDP en el puerto 7777 a
travs del puerto origen al del DNS. Comprubalo.
: Tabla NAT
Prctica 2.11
INPUT, FORWARD y OUTPUT forman la tabla filter. Hay dos tablas ms:
nat y mangle, cada una con sus propias cadenas, que entran en juego en otros
momentos durante la vida de un datagrama en el ncleo. En esas cadenas,
destinos
(medidas a tomar si la una regla encaja) ya no son
ACCEPT
los
DROP,
sino modica la IP origen o anota el datagrama con el nmero 0x1387.

La tabla
nat se utiliza para realizar NAT :-), es decir para modicar
las
IP origen y/o destino del trco que veamos. Dispone de tres cadenas.
PREROUTING: antes
de decidir cmo encaminar un datagrama, se le hace
pasar por esta cadena. Los destinos posibles sirven para
modicar la
IP destino, de ah que deba realizarse antes de encaminar.
OUTPUT: similar a la anterior, pero para los datagramas enviados localmente.

28
POSTROUTING: una vez decidido el destino del datagrama, y que la tabla

filter ha sido comprobada, los datagramas se pasan por esta cadena.
Los destinos posibles sirven para
La tabla
nat
modicar la IP origen.
exige, automticamente, seguimiento de conexiones en el
ncleo (que puede, o no, luego usarse tambin en la tabla

bir las reglas, slo debemos preocuparnos
filter).
del primer datagrama,
Al escri-
no de sus
respuestas.
1. Queremos hacer PNAT clsico, para que un Linux haga de salida con
su IP pblica a la red interna:
# iptables -t nat -A POSTROUTING -j MASQUERADE

Normalmente pediremos tambin que el datagrama salga por el interfaz
de Internet, con
-o.
2. Queremos ponernos en medio de una comunicacin, y que un trco destinado a otra IP llegue a un servicio lanzado localmente. Por
ejemplo:
Para interceptar una comunicacin y hacernos pasar por otro
(normalmente con motivos oscuros).
Proxy transparente.
Para eso utilizamos
a)
PREROUTING
(vamos a modicar
el destino ).
Desde Debian Cliente, conectate por telnet al Debian Servidor de

tu compaero (n+1).
b)
Como todos las mquinas virtuales son iguales (nombre, usuario

y contrasea) es difcil estar seguros de dnde estamos. Utiliza
ifconfig
para comprobar que la IP es la de tu compaero, por
lo que efectivamente te has conectado a su mquina.
c)
Para hacer ms comprobaciones, pide a tu compaero que, con
who,
mire con una sesin local en Debian Servidor si ests co-
nectado (puedes hacerlo tambin t en la sesin de telnet). Haz

lo mismo en tu Debian Servidor para saber si tu compaero n-1
ha hecho lo mismo.
conectado.
Fijate en la IP remota del usuario que se ha
d)
Cierra la sesin de telnet.
e)
En Debian Servidor, introduce una entrada en
PREROUTING
redirigir el puerto de telnet al servicio local:

para
29
# iptables -t nat -A PREROUTING -i eth1 -p tcp

--sport 1024:65535 --dport telnet
-j REDIRECT --to-port 23
f)
Vuelve a realizar las pruebas anteriores. Vers que ahora la sesin

se abre
en tu debian servidor
al haber interceptado la comunica-
cin.
Para saber ms...

Linux Firewalls (Third Edition); Steve Suehring, Robert Ziegler; Sams
Publishing.
Network Troubleshooting Tools; Joseph D. Sloan; O'Reilly. Seccin
6.2.2
Los cortafuegos trabajan a nivel de capa 3 y 4, por lo que sus reglas
pueden tomar decisiones en funcin de las cabeceras de dichas capas. Con
iptables
no podemos, por ejemplo, impedir que un alumno se conecte a
Facebook, incluso aunque se est conectando a Internet a travs de un router

con GNU/Linux, pues eso entra dentro de la capa 7.
En el prximo captulo veremos
squid,
el
proxy web
por excelencia del
mundo del software libre, que monitoriza el trco HTTP y nos permite
poner reglas de mayor alto nivel de abstraccin.

30
Resumen de los parmetros de iptables

Comandos bsicos de iptables
Opcin
Descripcin
-F | --flush [<cadena>]
Vaca la cadena, o todas si no se

especica ninguna
-P | --policy <cadena> <politica>
Establece la poltica por defecto

para la cadena (la accin realizada
por defecto si no se aplica ninguna
regla), por ejemplo
-L | --list [<cadena>] [--line-numbers]
ACCEPT o DROP
Lista las reglas de la cadena o de

todas las cadenas
-A | --append <cadena> <regla>
al nal
de
al principio
de
Aade una regla nueva

la cadena
-I | --insert <cadena> <regla>
Inserta una regla

la cadena
-R | --replace <cadena> <num regla> <regla>
Sustituye una regla anterior por

otra nueva
-D | --delete <cadena> <num regla>
Borra una regla
Comandos bsicos sobre reglas en iptables

Opcin
Descripcin
[!] -i [<interfaz>]
Especica el interfaz de red de entrada del paquete (lo,
eth0, etctera). Slo

INPUT y FORWARD. Si no
encaja para las
cadenas
se especica in-
terfaz, entonces indica todos.
[!] -o [<interfaz>]
Especica el interfaz de red de salida. Slo encaja

para las cadenas
[!] -p [<protocolo>]
OUTPUT
FORWARD.
Especica el protocolo (sobre IP) del paquete. Se

permite
icmp, tcp
udp.
Si se especica proto-
colo, luego hay opciones adicionales disponibles

dependiendo de cada uno.
[!] -s <direccion>[/<mscara>]
Especica la direccin fuente del datagrama (o la

red origen si se especica mscara)
[!] -d <direccion>[/<mscara>]
Especica la direccin destino del datagrama (o

la red destino si se especica mscara)
[!] -f
-j <destino>
Indica que es un fragmento (diferente al primero).

Indica qu hacer con el paquete (-j de
puede especicar
DROP
ACCEPT
los dems soportados.

jump ). Se
o cualquiera de
31
Comandos bsicos para reglas con el protocolo ICMP

Opcin
Descripcin
[!] --icmp-type <type>
Especica el tipo del mensaje ICMP al que aplicar la regla.
Comandos bsicos para reglas con el protocolo UDP

Opcin
Descripcin
[!] --sport <puerto>[:<puerto>]

[!] --dport <puerto>[:<puerto>]
Especica el/los puerto/s origen

Especica el/los puerto/s destino
Comandos bsicos para reglas con el protocolo TCP

Opcin
Descripcin
[!] --sport <puerto>[:<puerto>]

[!] --dport <puerto>[:<puerto>]
[!] --syn
Especica el/los puerto/s origen

Especica el/los puerto/s destino
Indica que la bandera
SYN
est activa-
da (usada nicamente durante el establecimiento de una conexin)
[!] --tcp-flags <mscara> <comparacin>
Comprueba las banderas contenidas en

la mscara para ver si tienen los va-
<comparacin>.
SYN, ACK,
FIN, RST, URG, PSH, ALL y NONE. La
idea es poner en la parte de <mscara>
lores especicados en
Las posibles banderas son
todas
las
banderas
que
se
quieran
comprobar. Y luego en la parte de
<comparacin>
se pone el nombre de
las banderas que se quiere que estn activas, y se omiten las que (de
la mscara) se quieran que estn a
falso. Ambas listas de banderas tienen que estar separadas por comas
sin espacios.
SYN,RST,ACK,FIN SYN.

--syn vis--tcp-flags
As la opcin
ta antes es equivalente a
32

Captulo 3
Proxies web
No puedes pasar! Soy un servidor del
Fuego Secreto, que es dueo de la llama
de Anor. No puedes pasar!
Gandalf el gris - El seor de los anillos
(J. R. R. Tolkien)
Resumen: En este captulo se explica Squid, analizando su funcionamiento y conguracin bsica.
El cortafuegos toma decisiones sobre trco en funcin de los datos de

las cabeceras de las capas 3 y 4 (y, quiz, de la capa 2). Si queremos un
control especco sobre protocolos de la capa 7 (por ejemplo que slo el
jefe/profesor pueda acceder a las pginas de los diarios deportivos en horas
de trabajo/clase), entonces necesitamos una
aplicacin
que comprenda el
protocolo correspondiente (de capa 7), analice sus cabeceras y decida qu

hacer en funcin de ellas.
Se llama proxy a cualquier aplicacin de este estilo, que hace de intermediario entre un cliente y un servidor. El tipo de proxy ms habitual es
el proxy web, que funciona sobre los protocolos de capa 7 HTTP y HTTPS.
Adems de servir para tomar decisiones de ltrado tambin puede realizar
cach (y muchas veces se utiliza nicamente para eso).
En este captulo veremos Squid, el proxy web ms conocido en el mundo
del software libre.
: Los routers/cortafuegos y la capa 7
Prctica 3.1
Antes de subir a la capa 7, vamos a comprobar que un router (o cortafuegos)
no
necesita la capa 7 para hacer su labor.

33
34
Captulo 3. Proxies web
1. Desde Debian Cliente, crea una conexin TCP con un ordenador externo. Por ejemplo, conectate por Telnet al ordenador del profesor.
2. En otra consola de Debian Cliente (<Ctrl>-<Alt>-F2 por ejemplo),
utiliza
netstat -tn
para ver
el rastro
de esa conexin en el ncleo .
Vers la conexin con IP origen la de Debian Cliente, puerto origen

aleatorio (no privilegiado), IP destino la del ordenador del profesor, y
puerto el de telnet.
3. Haz lo mismo en Debian Servidor. Encuentras alguna traza de la
conexin?
: El protocolo HTTP
Prctica 3.2
Un proxy hace uso de la cabecera de capa 7 (protocolo de aplicacin) para
decidir cmo actuar . Por tanto, para aprender lo que podemos congurar,
lo primero es entender la cabecera del protocolo.
1. En Debian Cliente
simula
un servidor Web utilizando :
nc -lp 80
Esto
abre el puerto 80
(web) y pone a
nc
a la escucha, quien nos
mostrar por pantalla todo lo que enve el cliente. Comprueba el puerto

abierto en otra consola con
netstat -tlnp.
2. En Ubuntu, abre un navegador y conectate a la IP de Debian Cliente. No se cargar nada, pero el navegador se queda a la espera de la
respuesta.
3. Vuelve a Debian Cliente y observa la salida. Es
la cabecera HTTP
enviada por el navegador Web para solicitar la pgina principal al

servidor ejecutndose en Debian Cliente.
GET / HTTP/1.1
Host: 10.x.n.2
1
En esta ocasin
no
se especica
-l,
porque no queremos ver las aplicaciones a la
escucha de clientes, sino las conexiones ya creadas.
2
3
Tambin puede, naturalmente, usar informacin de las capas inferiores.

Si en Debian Cliente tienes lanzado Apache, detenlo primero.

35
User-Agent: Mozilla/...
Accept: text/html,...
Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Tras la ltima linea (Connection:
keep-alive)
habr otra ms en
blanco, que indica n de cabeceras, e indica al servidor que ya puede

empezar a contestar.
4. Interpreta las cabeceras. Qu crees que signican?
5. Si el navegador no ha perdido la paciencia y ha cerrado la conexin,
puedes contestarle.
4
Escribe en Debian Cliente la respuesta con una
pgina Web :
<html>
<head><title>HACKER!</title></head>
<body>
<h1>Soy un hacker!</h1>
</body>
</html>
Termina pulsando
<Ctrl>-C.
6. Repite el ejercicio poniendo en el navegador
http://10.x.n.2/index.html.
Notas alguna diferencia en la solicitud recibida en Debian Cliente?
: Instalando y probando squid
Prctica 3.3
Squid es el proxy Web por excelencia del mundo del software libre.
1. Instala squid en Debian Servidor:
apt-get install squid3

4
En realidad en este ejemplo estamos haciendo un uso indebido del protocolo HTTP
porque no enviamos cabecera de capa 7; pero los navegadores son permisivos

:-)
36
2. Comprueba, con
netstat -tlnp,
que squid se ha lanzado escuchando
en el puerto 3128.
3. Congura el navegador en Firefox para que utilice a Debian Servidor
como proxy. La opcin est un poco oculta. Ve al men Editar - Preferencias, luego a la categora Avanzado, pestaa Red, y pulsa sobre el
botn Conguracin... en la seccin de Conexin . Pon la IP de Debian
Servidor, el puerto 3128, y marca Usar el mismo proxy para todo .

4. Conectate a
http://www.educa.madrid.org.
Puedes ver que el proxy
est funcionando porque rechaza la conexin con un mensaje de acceso

denegado.
5. Congura tanto Firefox (o Chrome) como Internet Explorer del antrin para que usen tambin el proxy (Herramientas - Opciones de
Internet, Conexiones, Conguracin de LAN).
6. Cmo
forzaras
a los usuarios de la red interna a usar el proxy?
: El protocolo HTTP con Proxy
Prctica 3.4
Si ponemos un proxy, no es suciente con que el navegador nos indique en

la linea
decirle
GET
el recurso (pgina) que quiere conseguir. Tambin necesitamos
el servidor. Compruebalo:
1. En Debian Servidor, detn el demonio de squid:
# /etc/init.d/squid3 stop
2. Utiliza
nc
para pasarte por l:
# nc -lp 3128
3. Conectate de nuevo a
http://www.educa.madrid.org
desde Ubuntu.
En esta ocasin se congela esperando la respuesta del proxy.

4. Vuelve a Debian Servidor y observa la salida:
5
6
Algunas versiones lo tienen en el men Herramientas en lugar de en Editar.

Para las pruebas que realizaremos en el curso, esto ltimo no es necesario, pero s es
habitual en un uso comn de un proxy.

37
GET http://www.educa.madrid.org/ HTTP/1.1

...
5. Pulsa
<Ctrl>-C
para cancelar, y lanza de nuevo squid.
# /etc/init.d/squid start

: Deniendo ACLs
Prctica 3.5
En squid se denen
List ),
listas de control de acceso
(ACL,
Access Control
de manera que ante una nueva solicitud HTTP, se mira a qu ACLs
pertenece. Una misma solicitud
puede pertenecer a varias. Ejemplos de ACL
son:
Venir del ordenador del profesor (IP origen).
Ir a un servidor con un nombre DNS (por ejemplo
www.facebook.com).
www.marca.es
Realizarse con Internet Explorer.

Realizarse entre las 10:15 y las 10:35 de la maana.
El formato para especicar una ACL en squid es:
acl <nombre> <tipo> (cadena|"fichero")+

<nombre>: nombre de la ACL. Es preferible usar nombres claros, como
ordenaProfe, destinoRestringido, IExplorer u horarioRecreo.
<tipo>: tipo de la ACL. Indica qu parmetro de la solicitud HTTP se
mirar para saber si pertenece o no a la ACL. Por ejemplo IP origen
(src), nombre DNS destino (dstdomain y
dstdom_regex
para especi-
car una expresin regular), identicador del navegador (browser) o
rango horario (time).
Parmetros especcos del tipo. Por ejemplo las IPs de los ordenadores de los profesores, los nombres DNS de los servidores restringidos,
el identicador del navegador, o el rango de horas. Se pueden poner
simultneamente varios parmetros (se consideran unidos por una O
lgica), o un nombre de chero
entre comillas, que contendr en lineas
independientes cada parmetro.

38
El chero de conguracin de squid (/etc/squid3/squid.conf) contiene numerosos ejemplos comentados (alrededor de la linea 750) a modo de
documentacin.
Adems, en squid3 hay varias ACLs predenidas:
acl
acl
acl
acl
all src 0.0.0.0/0

manager proto cache_object
localhost src 127.0.0.1/32
to_localhost dst 127.0.0.1/32
Crea las siguientes ACL, denindolas en la zona del chero donde estn
las ACL de ejemplo.

1.
redInterna:
aquellas solicitudes que vengan de
10.x.n.0/24,
tu red
interna.
2.
redAula:
3.
ipPrivilegiada:
4.
5.
aquellas solicitudes que vengan de la red del aula.

aquellas solicitudes que vengan de Debian Cliente.
redSocial: las consultas a los sitios *.facebook.com, *.instagram.com

y *.twitter.com.
IExplorer: las realizadas desde Internet
http://www.useragentstring.com).
Relanza squid (/etc/init.d/squid
Explorer (busca ayuda en
reload)
y prueba a conectarte a
Internet de nuevo desde Ubuntu. Funciona?
: Gestin de permisos
Prctica 3.6
categorizar las solicitudes, pero no toman decisiones

sobre ellas. Para eso estn los operadores sobre ACL:
Las ACL sirven para
<tipo operador> allow|deny ([!]<listaACL>)+

<tipo operador>:
aspecto a decidir sobre la consulta. Por ejemplo
realizarla o no, mandarla a un proxy auxiliar, limitarla el ancho de

banda, etctera.
allow|deny:
uno de los dos, para permitir o denegar.

39
Lista de nombres de ACL separadas por espacio. Para que se aplique el

operador (y su decisin) la solicitud debe pertenecer a todas, por lo que
se consideran enlazadas con una Y lgica. Si se antecede un nombre de
ACL con
se considerar cierto la
El operador ms importante es
no pertenencia
a la ACL.
http_access que sirve para decidir si cur-
sar o no la solicitud. De nuevo, en el chero de conguracin se proporcionan

varios ejemplos. La que ms nos interesa es la ltima:
http_access deny all

que deniega el acceso a la ACL
all
a la que, como vimos, pertenecan
0.0.0.0/0, es decir todas.

http_access es importante. Por tanto,
las solicitudes realizadas desde la IP origen

El orden de colocacin de las
reglas que pongamos debern ir
antes
las
que sta.
Realiza las siguientes conguraciones. Conguralas
do, relanzando squid en cada una y probndolas.
cada una por separa-
1. Permitir el uso del proxy nicamente desde la red interna.

2. Permitir el uso del proxy a la red del aula nicamente desde Internet
Explorer, y a la red interna desde cualquier navegador.
3. Permitir la salida a la red interna salvo a las redes sociales. La IP de
Debian Cliente (ipPrivilegiada), sin embargo, tendr que poder salir
a cualquier sitio .
4. Quita el proxy en los navegadores del antrin.
Para recargar squid tras cada cambio, puedes utilizar:
# service squid3 reload

Si cometes algn error y el chero de conguracin no puede analizarse,
squid se cerrar. En
/var/log/syslog
puedes encontrar alguna pista sobre
el problema. Tras resolverlo, debers utilizar
restart
en lugar de
reload,
dado que squid no est lanzado y no puede recargarse.
: Otras reglas
Prctica 3.7
7
Para probar esta, tendrs que cambiar la IP de Ubuntu por la de Debian Cliente
(hacerte pasar por l), o instalar un navegador en consola en Debian Cliente como
Para congurar el proxy, escribe
export http_proxy=http://10.x.n.1:3128/
lanzarlo.

lynx.
antes de
40
Impedir que se descarguen cheros .iso (url_regex).

Evitar que los enlaces pulsados desde Google funcionen (referer_regex).
Permitir que funcione todo los sbados y domingos (time).
: Proxy, encaminamiento y DNS
Prctica 3.8
Congura squid para que se pueda utilizar desde la red interna, pero
impidiendo el uso a las redes sociales.
1. Descongura Ubuntu para que no pueda resolver nombres:

Renombra (o borra) el chero
/etc/resolv.conf.
O quita la IP del servidor en la conguracin grca y reinicia la

red.
O, quiz la opcin ms rpida, aade una regla en el cortafuegos
(iptables) para impedir la salida al puerto DNS (53) de UDP.
2. Intenta resolver cualquier nombre (por ejemplo, usando
haciendo ping a
www.google.com).
nslookup
Funciona?
3. Intenta navegar desde Ubuntu. Funciona? Por qu?

4. Restaura la conguracin de DNS para que vuelva a funcionar:
Recupera el chero
/etc/resolv.conf.
O recongura la red de nuevo grcamente.

O borra la restriccin con
iptables.
5. Comprueba que puedes volver a hacer ping.

6. En Debian Servidor, deshabilita el encaminamiento IP. Desde Ubuntu,
prueba a hacer ping a
www.google.com.
Funciona?
7. Vuelve a intentar navegar desde Ubuntu. Funciona? Por qu?

8. Haz
netstat -tnp
en Debian Servidor. Hay alguna diferencia con la
salida sin proxy?

9. Restaura el reenvo IP en Debian Servidor.

41
: Proxy transparente
Prctica 3.9
Tener que congurar el proxy en todos los navegadores de los usuarios

puede ser tedioso. Para evitarlo, podemos usar un
Usando
iptables
proxy transparente.
podamos redirigir las solicitudes cambiando la IP y
puertos destino. Podemos as redirigir cualquier cosa que intente salir por el
router llevando puerto destino 80, al puerto 3128 local.
1. Descongura el proxy en Firefox de Ubuntu para que salga directamente a la Web.
2. Usando
iptables en Debian Servidor, consigue que cualquier cosa que
intente salir al puerto 80 (Web) sea redirigido al 3128, donde espera

squid:
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80

3. Al haber quitado la conguracin del proxy, el navegador enviar la
solicitud normal (sin el nombre de la mquina en la parte
GET).
La
redireccin har que esa solicitud le llegue a Squid, que, en principio,

no la comprender. Se lo avisamos. Busca en
la linea
http_port 3128
/etc/squid3/squid.conf
y modifcala:
http_port 3128 transparent

Esto har que squid saque la mquina destino del campo
Host
de la
solicitud.
4. Comprueba que puedes navegar desde Ubuntu. Para comprobar que,
efectivamente, ests usando el proxy, muestra el chero de log de squid
en Debian Servidor y observa cmo aparecen las soliditudes:
# tail -f /var/log/squid3/access.log
5. Vuelve a descongurar el DNS en Ubuntu. Sigue funcionando ahora?
Por qu? Vuelve a recongurar el DNS.
6. Y si deshabilitaras el reenvo IP en Debian Servidor, podras navegar
desde Ubuntu?

42
: Proxies y HTTPS
Prctica 3.10
1. Mantn la conguracin del proxy transparente, permitiendo la conexin a la red interna a cualquier sitio salvo a las redes sociales.
2. Desde Ubuntu, conectate a
http://www.facebook.com
y comprueba
que est denegado.

3. Conctate ahora a
https://www.facebook.com
(observa que ahora
usamos HTTPS). Qu ocurre?

La redireccin para el proxy transparente afecta nicamente al protocolo
HTTP, pero no a HTTPS. Con este protocolo, no es posible hacer un proxy
transparente, no funcionan muchas de las comprobaciones que se pueden
hacer con HTTP, ni es posible cachear las pginas. Para entender por qu,
veamos cmo funciona un proxy HTTPS.
1. En Ubuntu, congura de nuevo el proxy en Firefox.
2. Detn squid en Debian Servidor.
3. Utiliza
nc
para hacerte pasar por squid en Debian Servidor:
$ nc -lp 3128
4. Vuelve a Ubuntu, y conctate a cualquier sitio que utilice HTTPS, por
ejemplo
https://www.google.com
5. En Debian Servidor, mira lo que ha enviado el cliente.

6. Tambin puedes hacer esta misma prueba contra squid, poniendo Wireshark a escuchar en Ubuntu. Recuerda eliminar el
la conguracin
http_port
transparent
en
de squid antes.
: Almacenamiento de la cach
Prctica 3.11

43
Las pginas y cheros descargados por squid se almacenan localmente

con la esperanza de que vuelvan a ser solicitadas y se produzca un
cach.
xito de
El lugar y el modo en el que se mantiene la cach lo especica la
directiva
cache_dir
(alrededor de la mitad de
/etc/squid3/squid.conf):
cache_dir ufs /var/spool/squid 100 16 256

ufs:
modo de guardar la cach. Hace uso de cheros y directorios nor-
males (UFS=Unix File System). Una opcin algo mejor es AUFS, que
realiza accesos asncronos en varios demonios, pero consume ms recursos.
/var/spool/squid:
ruta del directorio. Debe existir y ser escribible
para squid.
100: tamao en MB que se usar para la cach. El valor por defecto es

muy pequeo!! En funcin del disco duro, es normal ampliarlo. Si usas
una particin especca,
no
pongas nunca el tamao completo (deja
libre alrededor de un 20 %).
16:
nmero de directorios del primer nivel.
256:
nmero de directorios del segundo nivel.
En squid3, por defecto no guarda nada en disco, sino que mantiene toda
la cach en memoria.
1. Modica la conguracin de squid para que almacene los elementos
descargados en el disco duro.
cache_dir ufs /var/spool/squid3 100 16 256

2. Ejecuta
squid3
para que construya la estructura de directorios de ca-
ch:
# squid3 -z
3. Recarga la conguracin de squid.
4. Navega un poco con Ubuntu haciendo bsquedas en Google, en GoogleMaps, y en la Wikipedia.
5. De vez en cuando consulta el espacio utilizado en el directorio de cach:
# du --max-depth=1 /var/spool/squid3

44
6. Navega ahora por alguna pgina que
no
use HTTPS.
: Ficheros de registro
Prctica 3.12
Squid registra su actividad en tres cheros, todos en
access.log:
/var/log/squid:
el chero en el que se anotan todos los accesos a squid.
Es el que podemos usar para saber quin est navegando, y dnde. El

primer nmero indica la hora en la notacin Unix. Para saber cual es:
date -d @<numero>
cache.log:
anotaciones sobre el funcionamiento de squid.
netdb.state
cach
(o
store.log):
en memoria.
informacin sobre el uso de disco y la
: Informacin de estado de squid
Prctica 3.13
Es posible obtener bastante informacin sobre el estado de squid. Para

eso, squid implementa un "protocolo"propio, aparte de HTTP, HTTPS, etctera. De ese modo, soporta recibir solicitudes (por el mismo puerto en el
que est escuchando) del tipo:
GET cache_object://localhost/fichero HTTP/1.0

Accept: *.*
y te contesta con datos internos, segn el chero que le pidas.
Usando
chero
nc o telnet, prueba a hacerlo desde Debian Servidor.

mem para obtener informacin de uso de memoria.
Pide el
Intntalo desde Debian Cliente o Ubuntu. Funciona?

Hacer esto a mano es un poco aburrido. La solucin es
squidclient, que
es un programa para hacer solicitudes HTTP normales y probar as Squid

(algo as como un
wget
adaptado), pero tambin permite hacer de manera
cmoda consultas de estado. Tendrs que instalarlo:

45
# apt-get install squidclient

Para eso:
$ squidclient cache_object://localhost/mem
Tambin es posible usar un alias:
$ squidclient mgr:mem
Los cheros disponibles para solicitar son muchsimos, y estn enumerados en la documentacin de squid (mem,
idns, info, active_requests,
...).
: Controlando el ancho de banda: delay pools
Prctica 3.14
Squid permite controlar el ancho de banda cedido a los clientes utilizando

el algoritmo de
token bucket.
Para eso dene lo que llama
delay pools.
Las
directivas que nos interesan son:
delay_pools:
indica el nmero de
delay pools.
Cada uno de ellos se
identicar por un valor numrico entre 1 y el nmero establecido aqu.
delay_pools <numDelayPools>
delay_class:
indica el tipo (clase) de cada
delay pool.
delay_pools <idDelayPool> <idClase>

Squid 2 soporta tres clases:
Clase 1: dispone de una nica estructura de control (un
bucket ) agregada
aggregate bucket.
token-
para todos los clientes. Se habla de un nico
Clase 2: el trco queda limitado de manera global por una estructura de control (igual que en la clase 1), pero se aaden a l
256 estructuras ms individuales, usndose uno u otro segn los
bits 25-32 de la IP de los clientes. Est pensado para independizar
el control de trco de los clientes de una red de clase C.

46
Clase 3: el trco se limita de manera global como antes a travs
aggregate bucket.
de un
Adems, se aaden 256
network buckets,
que se eligen a partir de los bits 17-24 de la IP, y 65536 ms

escogidos a partir de los bits 17-32. Est pensado para redes de
clase B.
En squid 3 hay dos tipos ms, uno para dar soporte a la autenticacin
de usuarios, y otra para poder etiquetar las solicitudes.
delay_parameters: especica los lmites de ancho de banda de un delay
pool :
delay_parameters <idDelayPool> <rate>/<size>

[<rate>/<size>
[<rate>/<size>]]
Tanto
<rate>
<size> se miden en bytes. Un valor de -1 implica

Todo debe ir en la misma lnea (se ha separado por
como
que no hay lmite.
razones de espacio).
delay_access: especica qu conexiones usarn un determinado delay
pool
usando identicadores de ACLs.
delay_access <id> allow|deny <acls>

Si ponemos
mos
deny,
allow se utilizar ese delay pool
inmediatamente. Si pone-
se impedir y no se mirarn ms directivas
relacionados a ese
delay pool
delay_access
que pueda haber despus.
delay_initial_bucket_level <porcentaje>: establece el porcentaje

de llenado de los contenedores en el momento de arrancar Squid.
Vamos a probarlo limitando el ancho de banda para la descarga de cheros
.iso.
1. En la conguracin de Squid de Debian Servidor aade las siguientes

directivas:
# ACL para las URL's que acaban en .iso.

acl isos url_regex -i \.iso$
# Tendremos solo un delay pool...
delay_pools 1
# ... de clase 1 ...

47
delay_class 1 1
# ... para el que permitiremos rfagas de 100 KB
# y velocidades mantenidas de 1 KB (un poco extremo,
# pero para poderlo notar al probarlo) ...
delay_parameters 1 1024/102400
# ... que se utilizar en descargas de ISOs ...
delay_access 1 allow isos
# ... y nada ms.
delay_access 1 deny all
# Al inicio, la posibilidad de rfagas es completa
delay_initial_bucket_level 100
2. Recarga Squid:
# /etc/init.d/squid reload
3. En Debian servidor, monitoriza el estado de los delay pools peridicamente:
# watch -t -n 1 squidclient mgr:delay

Vers aparecer cada segundo un informe de estado:
HTTP/1.0 200 OK
Server: <Versin>
[ Resto de cabeceras HTTP ]
Connection: close
Delay pools configured: 1
Pool: 1
Class: 1
Aggregate:
Max: 102400
Restore: 1024
Current: 102400
Memory Used: 56 bytes

48
Esto nos indica el tamao mximo y la frecuencia de actualizacin, as

como el estado actual.
4. En Ubuntu, navega y observa que el estado del
delay pool
no cambia.
Ve por ejemplo a la pgina de descargas de ISOs de Debian y comienza

a descargarte uno. Puedes copiar el enlace y usar
wget.
5. Observa en Ubuntu cmo al principio la descarga empieza rpido, pero

en seguida la velocidad baja drsticamente hasta que se estabiliza en
1 KB/s.
6. Ve a Debian Servidor y comprueba cmo ha cambiado el estado de la
delay pool.
7. Cancela la descarga en Ubuntu. Vuelve a Debian Servidor y comprueba

cmo se recupera la
delay pool.
Para saber ms...

Squid: The Denitive Guide; Duane Wessels; O'Reilly. En la seccin
14.2 se describe con detalle la informacin de estado de squid mencionada en la prctica 3.13.
Squid se puede usar en clase para evitar que los alumnos entren en
lugares que no queremos. La gestin manual de las listas negras a
travs de ACLs es incmoda. Podemos usar redirectores que faciliten
la gestin, y sobre los que se apoya Squid para tomar decisiones. Dos
ejemplos son DansGuardian y SquidGuard.
Si queremos extraer estadsticas de uso de la Web en nuestra red, podemos procesar el chero de log de squid para agrupar informacin sobre
pginas ms visitadas, IPs que generan ms trco, etctera. Ejemplos de herramientas de este tipo son SARG (Squid Analysis Report
Generator), Webalizer (tambin vlido para Apache) o Calamaris.
En el prximo captulo repasaremos el protocolo HTTPS, y la conguracin de Apache para usarlo.

Captulo 4
HTTP seguro
Las conversaciones son siempre
peligrosas si se tiene algo que ocultar.
Agatha Christie
Resumen: En este captulo se revisa el funcionamiento del protocolo

de la web segura (HTTPS).
Netscape anticip una web como soporte para los negocios y las transacciones econmicas. Para que esa visin se convirtiera en realidad, necesitaba
una
web segura,
encriptada y autenticada, algo de lo que HTTP careca.
En el lejano 1995, public por primera vez SSL (la versin 2.0), que con
el tiempo se estandariz y renombr a TLS. En este captulo indagaremos
sobre su funcionamiento.
: HTTP vs. HTTPS
Prctica 4.1
HTTP es un protocolo
en claro
que no encripta las comunicaciones, por
lo que cualquiera que monitorice la comunicacin podr tener acceso a la

informacin intercambiada. HTTPS, sin embargo, encripta los mensajes.
1. Desde cualquier navegador, comprueba que Microsoft sirve su pgina
tanto en HTTP como en HTTPS. Conctate desde cualquier navegador
a
http://www.microsoft.com/
y a
https://www.microsoft.com/
2. Lanza Wireshark en Ubuntu.

3. Desde Debian Cliente, conctate al puerto 80 de
utilizando telnet o
nc.
www.microsoft.com
Comprueba en Wireshark que se han intercam-
biado unos pocos segmentos TCP.

49
50
Captulo 4. HTTP seguro
4. Desde Debian Cliente, y hablando HTTP, pide al servidor la pgina

principal.
$ nc www.microsoft.com 80
GET / HTTP/1.1
Host: www.microsoft.com
[ lnea en blanco ]
5. Comprueba que el servidor Web responde correctamente. Comprueba
tambin que en Wireshark puedes ver la comunicacin.
6. Haz lo mismo conectndote al puerto 443, utilizado por HTTPS:
$ nc www.microsoft.com 443
GET / HTTP/1.1
Host: www.microsoft.com:443
[ lnea en blanco ]
7. Comprueba que el servidor cierra la conexin inmediatamente porque
el protocolo es incorrecto. Algunos servidores son algo ms educados y
devuelven una pgina de error usando HTTP.
: SSL/TLS
Prctica 4.2
HTTPS es en realidad HTTP sobre una conexin segura conseguida utilizando el protocolo SSL/TLS.
Se puede considerar un protocolo de capa
6, aunque formalmente esta capa no existe; en cualquier caso, el protocolo es
independiente
de HTTP, y hoy se utiliza ampliamente para encapsular otros
protocolos de capa 7. Al ser un protocolo por s mismo, existen herramientas

para crear
sockets seguros
a travs de SSL/TLS.
1. Lanza de nuevo Wireshark.

2. Desde Debian Cliente, utiliza
openssl para crear un socket seguro con
el servidor web de Microsoft.
$ openssl s_client -connect www.microsoft.com:443

s_client:
queremos usar
openssl
en modo cliente.

51
-connect direccin: destino al que conectarnos. Observa que se

utiliza : para separar el nombre de dominio y de puerto.
3.
openssl
vuelca una gran cantidad de informacin. En Wireshark, ob-
serva el intercambio de muchos ms segmentos TCP de lo que ocurra

con
nc.
Es trco relativo a la fase de negociacin; todava no hay
datos de capa 7.
4. El
handshake se ha encargado de encriptar el canal. Todo lo que mande-
mos ir encriptado y no podr ser comprendido por posibles atacantes.

Enva la misma consulta HTTP que mandaste antes:
$ openssl s_client -connect www.microsoft.com:443

GET / HTTP/1.1
Host: www.microsoft.com:443
[ lnea en blanco ]
5.
openssl
muestra la respuesta dada por el servidor. Comprueba en
Wireshark que el trco es incomprensible.

6. En Debian Cliente, utiliza Mays-AvPag para subir y mira el principio de la comunicacin con el servidor. Observa que en la primera
parte nos muestra:
Certicate chain
con la cadena de certicados
que garantizan la privacidad de la comunicacin.
: Infraestructura de clave pblica
Prctica 4.3
Para conseguir encriptar la comunicacin con SSL, se utiliza, durante la

fase de negociacin, encriptacin asimtrica. Para garantizar que el servidor
es quin dice ser, necesitamos estar seguros de que la clave pblica que nos
enva es realmente suya. Para eso, se utiliza una
cadena de certicados, hasta
llegar a un certicado raz de una entidad en la que el cliente confa (y de la

que conoce la clave pblica).
1. En Ubuntu (o incluso desde el antrin), usa Firefox para conectarte de nuevo a
https://www.microsoft.com
(asegrate de que usas
HTTPS).
2. Pulsa sobre el candado a la izquierda de la direccin, y elige Ms
informacin. Vers informacin bsica sobre la pgina.

52
3. Pulsa
Ver certicado. En los detalles, observa la jerarqua de certica-
dos. Comprueba que es equivalente a la que nos mostr
openssl.
4. Apunta el nombre de las entidades certicadoras, en particular la de

orden superior.
5. Cierra las dos ventanas, y abre las opciones del navegador (Editar Preferencias en Ubuntu), ve a la seccin Avanzado, y a la pestaa
Certicados. Pulsa Ver certicados.
6. En la ventana que se abre, selecciona la pestaa Autoridades para
ver las autoridades certicadoras raz.
7. Busca el certicado raz que est utilizando el servidor de Microsoft.
8. Pulsa el botn Editar conanza... y desmarca Este certicado puede
identicar sitios web.
9. Vaca la cach del navegador, y recarga la pgina de Microsoft. Observa
el resultado.
: HSTS: seguridad estricta HTTPS
Prctica 4.4
1. Conrma que el certicado raz usado por Microsoft sigue marcado

como no conable en Firefox.
2. Microsoft y Twitter utilizan ambos el mismo certicado raz, que hemos
rechazado. Conctate a
https://twitter.com.
3. Observa que ahora Firefox
no nos deja
continuar bajo nuestra respon-
sabilidad.
4. Utilizando
openssl,
conctate manualmente a Twitter y comprueba
las cabeceras devueltas por el servidor .
$ openssl s_client -connect twitter.com:443

[ datos de certificados ]
GET / HTTP/1.1
Host: twitter.com:443
1
La salida puede ser muy larga y quiz las cabeceras no puedas llegar a verlas. Redirige
la salida a un chero, o hazlo desde un terminal grco en Ubuntu.

53
[ linea en blanco ]
[ CABECERAS HTTP ]
strict-transport-security: max-age=....
5. Comprueba la aparicin de la cabecera
strict-transport-security
HTTP Strict Transport
que fuerza al uso del conocido como HSTS (
Security ) que pide al navegador que impida
la carga de cualquier cosa
del servidor que no sea seguro.
: HTTPS en Apache
Prctica 4.5
En Debian, los cheros de conguracin de Apache estn preparados para

poder habilitar el uso de HTTPS muy fcilmente.
/etc/apache2/sites-available y comprueba la exischero default-ssl.
1. Ve al directorio
tencia del
2. Habilita ese
virtual host :
# a2ensite default-ssl
3. Dado que SSL resulta algo costoso, su soporte se encuentra en un
mdulo
de Apache que hay que activar:
# a2enmod ssl
4. Reinicia Apache:
# service apache2 reload

5. Con Firefox, conctate a Debian Servidor a travs de
aparecer un aviso porque el certicado
no
https://.
Vers
es able al no haber sido
rmado por una entidad certicadora reconocida.

6. Abre la informacin del certicado en Entiendo los riesgos Aadir
excepcin Ver. Comprueba que est rmado por s mismo. Busca la
huella digital
SHA1. No aceptes el certicado an.
7. En Debian Servidor, abre el chero de conguracin del
virtual host
default-ssl. Busca la directiva SSLCertificateFile, donde se indica

la localizacin del certicado que se enva a los clientes:

54
SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
8. Calcula la
huella digital
del certicado (todo en una lnea):
# openssl x509 -noout

-in /etc/ssl/certs/ssl-cert-snakeoil.pem
-fingerprint
x509: queremos usar openssl para realizar un tratamiento de certicados digitales (en el formato estndar conocido como X.509).
-noout:
no queremos que nos muestre el certicado (en Base64).
-in /etc...:
especica la ruta del certicado.
-fingerprint:
queremos que nos muestre la huella digital.
9. Compara el resultado con el mostrado por el navegador. Si coinciden,

se puede asumir que el certicado que ha recibido el cliente es el que
envi el servidor, por lo que no estamos siendo vctimas de ningn
ataque.
Para saber ms...

Hay documentacin sobre SSL/TLS disponible en gran cantidad de
lugares, como la wikipedia.
Documentacin de Apache
http://httpd.apache.org/docs/2.4/ssl/
En el prximo captulo veremos SSH, el protocolo seguro para abrir terminales remotos. Aunque a menudo SSH es visto nicamente como la evolucin
del protocolo de telnet, sus caractersticas son mucho ms ricas, algunas de
las cuales tambin sern exploradas.

Captulo 5
Secure Shell (SSH)

The magic words are squeamish ossifrage
Scientic American, Agosto 1977
(Martin Gardner)
Resumen: En este captulo se explica SSH, analizando su funcionamiento y conguracin bsica.
Los protocolos iniciales usados en Internet no se preocuparon por la seguridad; al n y al cabo Internet naci siendo una red pequea gestionada
por gente relativamente cercana.
Al ir creciendo, la seguridad se convirti en un problema, y se buscaron
soluciones para encriptar las comunicaciones. SSH surgi para sustituir a
telnet y a ftp, y HTTPS lo hizo para sustituir a HTTP. Ambos protocolos
se alimentaron de las tcnicas de encriptacin asimtricas, que nacieron en
1977 con la invencin del algoritmo RSA.
En este captulo veremos el funcionamiento de SSH, tanto en el lado del
cliente como del servidor.
: Instalacin del servidor de SSH
Prctica 5.1
En Debian Servidor, instala el servidor de SSH:
# apt-get install ssh

El instalador nos informa de que se genera una pareja de claves RSA,
otra DSA, otra ECDSA y una ltima ED25519. Posteriormente, el servidor
de SSH se lanzar automticamente.
Las parejas de clave pblica/privada se guardan en
/etc/ssh.
55
56
Captulo 5. Secure Shell (SSH)
ssh_host_rsa_key*
guardan la clave RSA.
ssh_host_dsa_key*
guardan la clave DSA.
ssh_host_ecdsa_key*
guardan la clave ECDSA.
ssh_host_ed25519_key*
guardan la clave ED25519.
Las claves son aleatorias; la parte pblica y privada estn relacionadas

entre s. Compara los permisos de los cheros de la parte pblica (extensin
.pub)
y parte privada (sin extensin). Tiene sentido?
: Primera conexin: comprobando el ngerprint
Prctica 5.2
Vamos a conectarnos desde Debian Cliente a Debian Servidor. El cliente

de SSH se instala por defecto en Debian, y no hay que instalar nada.
y slo por motivos pedaggicos explicados

modicar un aspecto de la conguracin del cliente :
Antes,
En Debian Cliente, abre el chero
ms adelante vamos a
/etc/ssh/ssh_config.
En la parte nal, busca la directiva
HashKnownHosts
y ponla en
No.
Desde Debian Cliente, conectate por primera vez a Debian Servidor:

57
$ ssh 10.x.n.1
The authenticity of host '10.x.n.1 (10.x.n.1)' can't be
established.
ECDSA key fingerprint is ac:d7:e5:c0:f0:c7:c0:bd:d7:4d:ed:
11:7c:cb:cf:ae.
Are you sure you want to continue connecting (yes/no)?
El servidor nos enva
su clave pblica completa
(ECDSA en este caso),
que el cliente no conoce. Nos pide que la validemos, proporcionndonos el
ngerprint
(resumen) de dicha clave pblica.
Es responsabilidad del administrador del servidor dar a conocer a todos

los clientes ese
ngerprint. Es responsabilidad de los clientes comprobarla.

ngerprint en Debian Servidor:
Como administradores, para obtener el
$ ssh-keygen -lf /etc/ssh/ssh_host_ecdsa_key

2048 ac:d7:e5:c0:f0:c7:c0:bd:d7:4d:ed:11:7c:cb:cf:ae /etc/ssh/
ssh_host_ecdsa_key.pub
Ahora
como clientes, comprobamos que son iguales, y aceptamos. El

directamente la contrasea (sin el usuario). El nombre
cliente nos pregunta
de usuario con el que nos conectamos es, si no se dice lo contrario, el mismo

con el que hemos lanzado la sesin local.
Si hubiramos querido un usuario diferente, en el cliente:
$ ssh usuario@10.x.n.1
o
$ ssh -l usuario 10.x.n.1

Cierra la sesin SSH con el servidor que tienes en Debian Cliente.
Como ocurre con telnet, hoy en da el servidor de SSH viene congurado
en Debian para impedir la conexin como
root,
por lo que tendrs que
utilizar un usuario no privilegiado.
: El chero known_hosts
Prctica 5.3
Vuelve a conectarte desde Debian Cliente a Debian Servidor. Ahora

te pedir que compruebes el
ngerprint
de la clave pblica.

no
58
Recuerda desconectarte de Debian Servidor. Una vez de vuelta en Debian Cliente abre el chero
~/.ssh/known_hosts. Comprueba que apa-
rece anotada la IP de Debian Servidor, y que tiene asociada una clave

pblica. Es la recibida de Debian Servidor, y se usa en el resto de
conexiones para comprobarla automticamente.
Conectate por SSH a los Debian Servidor de otros compaeros. Tendrs
que validar otras claves pblicas.
Comprueba cmo tu chero
known_hosts
ha crecido.
Borra la linea con la clave de Debian Servidor (10.x.n.1 que deberas

ver la primera.
Conectate de nuevo a Debian Servidor. Al haber desaparecido su clave,
el cliente te pide que vuelvas a validarla.
: Encriptacin del chero known_hosts
Prctica 5.4
En el chero
known_hosts podemos ver los nombres o IP de los servidores
que conocemos porque modicamos las opciones anteriormente, pero esto

puede ser inseguro porque es un rastro de a qu servidores SSH se ha
conectado un usuario. En realidad, se muestran los nombres y las IPs en claro
por el cambio que hicimos previamente por motivos pedaggicos. Veamos
cmo funcionarn las cosas normalmente:
Borra el chero
Abre el chero
known_hosts
de Debian Cliente
/etc/ssh/ssh_config.
En la parte nal, busca la directiva

en
Yes.
HashKnownHosts y ponla de nuevo
Conectate por SSH a Debian Servidor. Volver a pedirte que valides la

clave pblica.
Desconectate de nuevo, y conectate a varios de los Debian Servidor de
tus compaeros.
Comprueba nalmente el contenido de tu chero
known_hosts.
podrs identicar a qu IP pertenece cada clave pblica.

No
59
: Manipulando un known_hosts encriptado
Prctica 5.5
Un
known_hosts
con el nombre/IP de los servidores encriptado nos im-
pide saber si conocemos o no la clave pblica de un servidor, o incluso borrarla. Para saber si la conocemos usamos
(de
Find ).
ssh-keygen
con el parmetro
-F
$ ssh-keygen -F 10.x.n.1
# Host 10.x.n.1 found: line 1 type RSA
|1|rStrfKI5TFLSadM7CLcbHj29o4g=|s3mvA3W+lzfSSdyorRRB7bCzN+4=
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAuBLOPgu+2MwyhDWtjv4GEJQL
[ ... resto de clave pblica ... ]
/WWJN2L1AF16eHLt4Q==
Para borrar una clave pblica:
$ ssh-keygen -R 10.x.n.1
/home/alumno/.ssh/known_hosts updated.
Original contents retained as /home/alumno/.ssh/known_hosts.old
Si tenemos un chero
known_hosts
con los nombres de los servidores
sin encriptar (porque lo hemos creado con una versin antigua del cliente),
podemos encriptarlo con:
$ ssh-keygen -H
/home/alumno/.ssh/known_hosts updated.
Original contents retained as /home/alumno/.ssh/known_hosts.old
Debido al funcionamiento del almacn de claves pblicas, la conexin
al mismo servidor usando diferentes IP o diferentes nombres se considera

distinta. Prueba a conectarte desde Debian Cliente a Debian Servidor usando
la IP externa y vers que te pide que compruebes la clave pblica otra vez.

: Fingerprint en bubble babble
Prctica 5.6
Algunos
clientes
de SSH consideran que comprobar el ngerprint es inc-
modo para los usuarios porque tiene muchos nmeros y es fcil equivocarse.

60
mostrar el ngerprint que

llaman bubble babble que slo usa letras. Para averiguar el ngerprint de una
Se han inventado un formato diferente para
clave en el servidor:
$ ssh-keygen -B -f /etc/ssh/ssh_host_ecdsa_key
2048 xitot-larit-gumet-gygim-sozev-vyned-cigeb-sariv-tekuk-badus
-bexax /etc/ssh/ssh_host_rsa_key.pub

: La importancia del ngerprint: interceptando

una conexin SSH
Prctica 5.7
Para comprobar la importancia de
comprobar siempre
la clave pblica
cuando nos lo solicita el cliente, vamos a interceptar una conexin SSH.

Desde Debian Cliente, conectate por SSH a la IP externa del Debian
Servidor
del profesor.
Comprueba la clave pblica si no la tenas ya
almacenada.
Cierra la sesin.
En Debian Servidor, aade una regla en iptables para redirigir todo
el trco SSH saliente hacia
tu
servidor de SSH. Eso engaar a los
clientes de tu red interna, al conectarles con tu servidor cuando creen

que se conectan a cualquier otro:
# iptables -t nat -A PREROUTING -i eth1 -p tcp

--sport 1024:65535 --dport ssh
Desde Debian Cliente, vuelve a conectarte por SSH al Debian Servidor
del profesor:
$ ssh 10.x.m.1
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the
-middle attack)!
It is also possible that the RSA host key has just been cha
nged.

61
The fingerprint for the RSA key sent by the remote host is
20:13:ff:d8:2a:6e:d5:42:ce:dd:c4:2a:76:27:08:cf.
Please contact your system administrator.
Add correct host key in /home/alumno/.ssh/known_hosts to ge
t rid of this message.
Offending key in /home/alumno/.ssh/known_hosts:3
remove with: ssh-keygen -f "/home/alumno/.ssh/known_hosts
" -R 192.x.m.1
RSA host key for 192.x.m.1 has changed and you have request
ed strict checking.
Host key verification failed.

: Tnel SSH
Prctica 5.8
El canal seguro creado por SSH puede utilizarse para transportar datos
adicionales adems de los de la sesin interactiva (terminal).
Lanza Wireshark en Ubuntu (o en el antrin). Inicia una captura de
trco poniendo como ltro
host <ipDebianServidorProfesor>
Desde Ubuntu, conectate en el navegador al Debian Servidor del profesor, que tendr lanzado Apache.
Vuelve a Wireshark, deten la captura, y comprueba que puedes ver el
trco en claro.
Lanza de nuevo Wireshark con el mismo ltro.
Desde Ubuntu, conectate por SSH al Debian Servidor del profesor,
creando adems un tunel SSH, uniendo
un puerto local de TCP (por
ejemplo el puerto
del servidor:
5555)
con el puerto
80
$ ssh -L 5555:localhost:80 <ipDebianServidorProfesor>

En otra consola de Ubuntu, mira los puertos abiertos:
$ netstat -ltnp
Active Internet connections (only servers)
...
tcp 0 0 127.0.0.1:5555 0.0.0.0:* LISTEN
...
10312/ssh

62
Desde Ubuntu, conctate con el navegador
a tu puerto local 5555.
Vers aparecer la pgina Web del servidor. Detn la captura, y comprueba el trco. Vers que
no
hay conexin con el puerto 80, y slo
hay trco SSH.

En el equipo local el cliente de SSH se ha quedado escuchando en el
loopback. Podemos pedirle que escuche en todas las IPs. Para eso, basta con
especicar el parmetro
-g. Vuelve a conectarte al ordenador del profesor

netstat que, efectivamente, el puerto 5555 est
usndola, y comprueba con
abierto en todos los interfaces de red.
: Tnel dinmico con SSH (y SOCKS)
Prctica 5.9
El protocolo SOCKS (cuya versin 5 surgi en 1996) es un proxy genrico

de capa 7. Las aplicaciones usando SOCKS, se conectan al proxy y le piden
una conexin con un equipo remoto, para el que el servidor har simplemente
de pasarela. La versin 5 mejora a la 4 al soportar UDP.
El servidor de SSH puede simular un servidor SOCKS, y conectarlo con
el cliente a travs de un tnel. Esto nos permitir tener en el ordenador local
un servidor SOCKS que, en realidad, se ejecuta en el ordenador remoto
(servidor de SSH). El resultado es que con SSH podemos escapar de una red
protegida por cortafuegos.
Comprueba que desde Ubuntu puedes conectarte al servidor SSH del
ordenador del profesor, y navegar.
En Debian Servidor, congura
interna
#
#
#
#
no
iptables para que los equipos de la red

1
puedan salir por HTTP :
iptables
iptables
iptables
iptables
-F
-P
-A
-A
FORWARD
FORWARD ACCEPT
FORWARD -p tcp --dport 80 -j DROP
FORWARD -p tcp --dport 443 -j DROP
Comprueba que ahora ya no puedes navegar.

Conctate por SSH al Debian Servidor del profesor indicando que quieres reenvo dinmico sobre el puerto 1080 local (el predenido de
SOCKS):
La conguracin propuesta es muy sencilla, por brevedad.

63
$ ssh -D 1080 alumno@192.168.x.p

Congura en Firefox de Ubuntu el proxy SOCKS. Est en el mismo
lugar que el proxy normal. Pon
localhost como servidor, y 1080 como
puerto. Deja el resto de proxies (HTTP, SSL, FTP) vacos.

Lanza una captura de trco en Wireshark.
Intenta navegar otra vez. Comprueba que ahora s puedes. La IP con
la que ests navegando ser realmente la IP de Debian Servidor del
profesor.
Si miras el trco generado, slo vers trco DNS y SSH.
Detn la captura en Wireshark
Firefox sigue usando el DNS del equipo para resolver los nombres, en
lugar de usar el servidor SOCKS congurado en el proxy. Podemos pedirle
que tambin lo use:
En Debian Servidor, ltra tambin DNS:
# iptables -A FORWARD -p udp --dport 53 -j DROP

Comprueba que en Ubuntu ya no puedes navegar.
En las opciones de proxy de Firefox, marca DNS remoto .

Lanza de nuevo Wireshark y vuelve a intentar navegar. Comprueba
que ahora slo hay trco SSH; el DNS se encamina a travs de l al
servidor SOCKS del servidor SSH.
: FTP seguro
Prctica 5.10
Aunque SSH se suele asociar al

un FTP seguro conocido como
terminal seguro,
sftp.
tambin proporciona
El cliente est disponible siempre en
GNU/Linux. El servidor se instala automticamente con el de SSH :
En versiones antiguas de Ubuntu esta opcin no exista. Era necesario entrar en la
about:config,
network.proxy.socks_remote_dns.
conguracin na poniendo en la barra de direcciones

la variable de conguracin
En realidad,
sftp
y poner a cierto
tambin utiliza el puerto 22, igual que SSH. Aunque el funciona-
miento real es complicado, podemos pensar que
sftp se ejecuta en realidad sobre un tunel
de SSH para el que no se ha creado un terminal.

64
En Debian Cliente, usa el cliente de FTP seguro para navegar por los
cheros de Debian servidor:
$ sftp 10.x.n.1
password:
Como con SSH, no nos pregunta el nombre de usuario. Si queremos
uno diferente al nombre local actual, usaremos
Analiza los comandos disponibles (usa
nombre@servidor.
help).
Descargate algn chero, y prueba a subir otro.
sftp usa la misma infraestructura

known_hosts, etctera.
de claves que SSH, el mismo chero
: Copia entre mquinas
Prctica 5.11
sftp
tiene una losofa similar a FTP, proporcionando un interfaz in-
teractivo. Es posible copiar cheros entre mquinas usando directamente la

linea de rdenes con
scp:
alumno de Debian servidor crea
copiame.txt, con un par de lineas
En el directorio personal del usuario

un chero de texto nuevo de nombre
de texto.
Desde Debian Cliente, copia el chero usando
scp:
$ scp alumno@10.x.n.1:copiame.txt .
Desde Debian Cliente copia el chero
carpeta personal del usuario
root
/etc/network/interfaces
4
de Debian Servidor :
a la
$ scp /etc/network/interfaces root@10.x.n.1:.

El formato del comando es:
$ scp <ficheroOrigen> <ficheroDestino>

En el chero, podemos especicar una ruta remota con el formato:
Para que esto funcione, tendrs que haber habilitado la conexin para el usuario
en el servidor de SSH.

root
65
<usuario>@<maquina>:<ruta>
Si la ruta que se especica no es absoluta, se asume que parte del direc-
torio personal del usuario.
: Autenticacin por clave pblica
Prctica 5.12
Es posible autenticarnos en un servidor usando una pareja de claves
del cliente. En el cliente generamos la pareja de claves, y

servidor la clave pblica. Durante la fase de autenticacin el
pblica-privada
enviamos al
servidor comprueba que el cliente dispone de la clave privada correspondiente, demostrando as que es quin dice ser. En ese caso, le deja conectarse sin
pedir la contrasea del sistema.
Lo que vamos a hacer en esta prctica es que desde Debian Cliente (con el
usuario
alumno) podamos conectarnos a Debian Servidor (al usuario alumno,
aunque la coincidencia del nombre es insignicante) sin escribir contrasea.

En Debian cliente (como
alumno), crea una pareja de claves, que usare-
mos para autenticacin. Deja la ruta del chero propuesta, y la clave

de paso vaca.
~$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/alumno/.ssh/id_
rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/alumno/.ssh/id_
rsa.
Your public key has been saved in /home/alumno/.ssh/id_rsa.
pub.
The key fingerprint is:
2c:ca:41:89:94:ac:93:0f:7b:df:e9:9e:f8:c4:ec:03 alumno@debi
ancliente
Esto nos ha dejado la pareja de claves en
~/.ssh/id_rsa[.pub]. Po-t dsa, e incluso
dramos haber indicado que queramos usar DSA con
el tamao de la clave. El lugar donde nos ha dejado las claves es cmodo, porque es donde lo buscar el
cliente
de SSH cuando lo necesite.
Podemos proteger la clave privada, encriptndola con una frase de

paso para evitar que si alguien la consigue pueda acceder al servidor
correspondiente.

66
Fjate en los permisos de los cheros generados. La clave pblica la

pueden leer todos, pero no as la clave privada.
root podra leer nuestra clave privada.

nuestro known_hosts est codicado!
El
Ahora tenemos que enviar la clave
Una razn ms para tener
pblica
al servidor. Para eso, la
copiamos:
alumno@debiancliente:~$ scp .ssh/id_rsa.pub \

alumno@10.x.n.1:id_rsa.pub.dc
El
servidor
de SSH busca las claves pblicas usadas para autenti-
cacin automtica en
/.ssh/authorized_keys5 .
Cada clave ocupar
una linea, y podemos tener muchas concatenadas. Tenemos que conectarnos por SSH (por ltima vez, usando la contrasea tradicional), y
concatenar la clave pblica a dicho chero:
alumno@debiancliente:~$ ssh alumno@10.x.n.1

[...]
alumno@debianservidor:~$ mkdir .ssh
alumno@debianservidor:~$ chmod 700 .ssh
alumno@debianservidor:~$ cat id_rsa.pub.dc \
>> .ssh/authorized_keys
alumno@debianservidor:~$ chmod 600 .ssh/authorized_keys
alumno@debianservidor:~$ rm id_rsa.pub.dc
alumno@debianservidor:~$ exit
Tras hacer la concatenacin, podrs entrar en debian servidor sin contrasea.
Si hubieras puesto palabra de paso al generar la clave pblica/privada, el
cliente de SSH te la habra pedido para desencriptar tu clave privada y poder

demostrar al servidor que la tena. Poner frase de paso, por tanto, supone
una incomodidad que hace dudosa la utilidad de autenticarse con clave
pblica/privada . No obstante, la seguridad mejora, porque incluso aunque

alguien te viera escribir la frase de paso, no podra usarla para entrar en el
servidor al no disponer de la clave privada.
Este chero permite tambin congurar qu puede hacer un usuario conectndose
usando esa clave. Por ejemplo, podramos congurarla para que el servidor impidiera el
reenvo de puertos para ese usuario, la creacin de un TTY, o limitar el uso a un comando
concreto.
Para evitar esta incomodidad existe el agente SSH que guarda y mantiene en me-
moria esas frases de paso.

67
El uso de clave pblica/privada para autenticacin es especialmente til

para tareas automticas, como por ejemplo un demonio que haga copias de
seguridad que sean enviadas a un servidor remoto. Adems, en la conguracin predenida del demonio de SSH, es la nica forma de conectarse como
root
directamente.

En Windows tambin existen mltiples clientes de SSH. El ms conocido es PuTTY, que proporciona un cliente de SSH, uno de SFTP y uno
de SCP, entre otras herramientas. Es de cdigo abierto y est disponible
gratutamente.
Para saber ms...

SSH, The Secure Shell: The Denitive Guide; Daniel J. Barrett, Richard Silverman; O'Reilly. El captulo 3 se dedica a aspectos generales de seguridad (encriptacin, integridad, autenticacin, autorizacin;
criptografa simtrica y asimtrica y funciones hash) que es muy til
para la parte terica que tambin comparte con SSL (HTTPS).
A travs de los tneles, SSH puede utilizarse para salir de la red local
donde estamos conectados, y utilizar servicios remotos de modo que el resto
del mundo vea como nuestra la IP del servidor al que nos hemos conectado. Los tneles dinmicos (con SOCKS) proporcionan bastante versatilidad
porque no necesitamos conocer de antemano a qu lugares querremos ir. La
desventaja es que exige que el software local est preparado para usar proxies
SOCKS.
En el prximo captulo veremos el concepto de las redes privadas virtuales
(VPN), que lleva esta idea ms all, encriptando
toda
la comunicacin de la
estacin a travs de un tnel seguro, por lo que se puede utilizar en todas

las aplicaciones directamente, sin necesidad de recongurarlas.

Captulo 6
Redes privadas virtuales

(VPN)
Tres podran guardar un secreto si dos de
ellos hubieran muerto.
Benjamin Franklin.
Resumen: En este captulo se monta una VPN, tanto el cliente como

el servidor, usando PPTP.
Histricamente, cuando una empresa dispona de dos localizaciones diferentes y quera unir sus redes, deba alquilar una lnea de comunicacin
entre ambas, que serva de enlace entre sus routers. Del mismo modo, si un
trabajador quera conectarse a la red desde una localizacin remota, deba,
normalmente, realizar una llamada a la empresa para contactar con alguno
de sus
modems
que le introduca en la red.
Esto supona un alto coste de comunicacin, pues el alquiler de esas lneas

permanentes o el uso de la RTC para la conexin exiga un pago por distancia.
Al aparecer la posibilidad de conexin a Internet a travs de mecanismos
ms baratos, surgi la idea de las redes privadas virtuales (VPN), que usan
a Internet como soporte para conectar los extremos alejados, creando tneles
seguros a travs de l.
En este captulo conguraremos Ubuntu como cliente de una VPN (creada con PPTP), y posteriormente montaremos un servidor PPTP en Debian.
: Creacin de una VPN: el cliente
Prctica 6.1
Vamos a conectarnos a travs de una VPN con el Debian Servidor del

69
70
Captulo 6. Redes privadas virtuales (VPN)
profesor desde Ubuntu. Lo primero que haremos ser una prueba de que las
cosas funcionan normalmente antes de la VPN:
Asegurate de que desde Ubuntu puedes hacer
ping
a la IP
interna
del
Debian Servidor del profesor.

Pon Wireshark en Ubuntu, para ver esas solicitudes de
ping
sin en-
criptar.
Detn la captura en Wireshark.
Mira los interfaces de red y la tabla de rutas de Ubuntu. Deberas ver
un nico interfaz de red y las rutas habituales.
tracepath,
Utilizando
comprueba el camino que sigues para llegar a
esa IP, para ver que tu ordenador utiliza la puerta de enlace que era
de esperar.
tracepath 10.x.m.1 -n
Ahora congura la VPN en Ubuntu usando el asistente.
Pulsa sobre el icono de conguracin rpida de la red en la barra de

tareas:
Figura 6.1: Conguracin de la red
En el men desplegable, selecciona Congurar VPN...
Figura 6.2: Abrir la conguracin de VPN
En la ventana, pulsa Aadir para que salte el asistente de nueva VPN.

Escoge un tunel PPTP en el tipo de conexin VPN

71
(a) Parmetros generales
(b) Parmetros avanzados
Figura 6.3: Conguracin de una VPN en Ubuntu (cliente)
Establece como nombre de la VPN VPN Profe. Pon la IP externa

del Debian Servidor del profesor,
alumno
como usuario, y
esspeevpn
como contrasea.
Pulsa sobre el botn de las opciones avanzadas, y marca Use Pointto-Point encryptation (MPPE).
Cierra el asistente. De nuevo sobre el icono de la barra de herramientas,
selecciona en el men desplegable la nueva VPN para conectarte.
Figura 6.4: Activacin de la VPN
Repite las pruebas anteriores para notar las diferencias.

Al hacer ping a la IP interna del Debian Servidor del profesor, en Wireshark veremos nicamente trco encriptado (y el ping funcionar).
En los interfaces de red aparece uno nuevo (ppp0) que es el que simula
una tarjeta de red nueva conectada directamente a Debian Servidor a
travs del tunel. Recibimos una nueva IP en dicho interfaz (elegida por
el servidor), con su propia puerta de enlace. La tabla de rutas muestra

72
Captulo 6. Redes privadas virtuales (VPN)
que ya no utilizamos nuestro Debian Servidor como puerta de enlace

por defecto, sino la del tunel. Nuestro Debian Servidor slo se usa para
llegar al servidor de VPN.
La ejecucin de
tracepath
muestra la diferencia en el camino.
Desconectate de la VPN y comprueba que todo vuelve a la normalidad.
: Instalacin del servidor
Prctica 6.2
Vamos a instalar en Debian Servidor un servidor de VPN por PPTP, al

que se conectar un compaero.
Instala el servidor:
apt-get install pptpd

Modica la conguracin del servidor en
/etc/pptpd.conf
para in-
dicar qu IP utilizars como puerta de enlace, y qu IPs dars a los

clientes. Para eso, al nal del chero:
localip 172.16.n.1
remoteip 172.16.n.10-50
Abre el chero de conguracin del demonio de PPP cuando lo utiliza
PPTP, que puedes encontrar en
el valor de la directiva
name,
/etc/ppp/pptpd-options.
pptpd.
Fijate en
que es por defecto
Fijate tambin que se rechazan PAP, CHAP y MSCHAP como mtodos

de autenticacin, de modo que el servidor slo soportar MSCHAPv2, con encriptacin de 128 bits.
Aade la conguracin del servidor de nombres:
ms-dns <IP DNS aula>

Establece la contrasea de los clientes. Para eso, abre el chero de
texto situado en
/etc/ppp/chap-secrets.
Es una tabla con cuatro
columnas:
Nombre del usuario que quiere autenticarse. Ponemos

alumno
73
Nombre del servidor. En este caso, la especicada en la directiva
name
de
pptpd-options, pptpd.
esspeevpn.
Contrasea del usuario. Ponemos
La IP que daremos a ese usuario (til para asignaciones jas).

Asignamos una aleatoria del rango congurado antes; para eso
dejamos un
*.
En resumen:
alumno pptpd esspeevpn *

Relanzamos el servidor:
/etc/init.d/pptpd restart
Cuando nuestro compaero haya creado su VPN, conguramos una nueva
conexin por VPN en Ubuntu, nos conectamos a ella y la probamos.
Para saber ms...

Virtual Private Networks; Charlie Scott, Paul Wolfe, Mike Erwin; O'Reilly.
Es un poco antiguo, por lo que los captulos para poner en marcha una
VPN no son tiles; sin embargo los captulos introductorios (1-4) explicando los conceptos siguen sindolo.

Qu te parece desto, Sancho? Dijo Don Quijote

Bien podrn los encantadores quitarme la ventura,
pero el esfuerzo y el nimo, ser imposible.
Segunda parte del Ingenioso Caballero
Don Quijote de la Mancha
Miguel de Cervantes
Buena est dijo Sancho ; frmela vuestra merced.

No es menester rmarla dijo Don Quijote,
sino solamente poner mi rbrica.
Primera parte del Ingenioso Caballero
Don Quijote de la Mancha
Miguel de Cervantes

Practicas

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Practicas

Hochgeladen von

Copyright:

Verfügbare Formate

Curso Seguridad en redes

Pedro Pablo Gmez Martn

Documento maquetado con TEXiS v.1.0+.

Este documento est preparado para ser imprimido a doble cara.

Curso Seguridad en redes

c Pedro Pablo Gmez Martn

Conguracin de la red en Debian . . . . . . . . . . . . .

Modelos de red en Virtual Box . . . . . . . . . . . . . . .

Creacin de Debian Cliente . . . . . . . . . . . . . . . . .

Una segunda tarjeta de red en debian servidor . . . . . .

Congurar el laboratorio virtual . . . . . . . . . . . . . .

Batera de pruebas 1: red bsica . . . . . . . . . . . . . .

Batera de pruebas 2: red en NAT . . . . . . . . . . . . .

Pr. 1.10. Batera de pruebas 3: encaminamiento y NAT

Analizando trco de red . . . . . . . . . . . . . . . . . .

Comprobacin de puertos abiertos . . . . . . . . . . . . .

Comprobacin de los puertos abiertos en remoto . . . . .

iptables: poltica por defecto

iptables: condiciones de capa 2 y 3 . . . . . . . . . . . . .

iptables: condiciones de capa 4 . . . . . . . . . . . . . . .

iptables: DROP vs. REJECT . . . . . . . . . . . . . . . .

iptables: cadena FORWARD . . . . . . . . . . . . . . . .

Pr. 2.10. Seguimiento de conexiones

Pr. 2.11. Tabla NAT . . . . . . . . . . . . . . . . . . . . . . . . . .

Resumen de los parmetros de iptables . . . . . . . . . . . . . . . .

Los routers/cortafuegos y la capa 7

Instalando y probando squid . . . . . . . . . . . . . . . .

El protocolo HTTP con Proxy . . . . . . . . . . . . . . .

Proxy, encaminamiento y DNS . . . . . . . . . . . . . . .

Pr. 3.10. Proxies y HTTPS

Pr. 3.11. Almacenamiento de la cach

Pr. 3.13. Informacin de estado de squid . . . . . . . . . . . . . . .

Pr. 3.14. Controlando el ancho de banda: delay pools

HTTP vs. HTTPS . . . . . . . . . . . . . . . . . . . . . .

Infraestructura de clave pblica

HSTS: seguridad estricta HTTPS

5. Secure Shell (SSH)

Instalacin del servidor de SSH

Primera conexin: comprobando el ngerprint

Encriptacin del chero known_hosts . . . . . . . . . . .

Manipulando un known_hosts encriptado . . . . . . . . .

Fingerprint en bubble babble . . . . . . . . . . . . . . . .

La importancia del ngerprint: interceptando una cone-

Tnel dinmico con SSH (y SOCKS)

Pr. 5.10. FTP seguro

Pr. 5.11. Copia entre mquinas . . . . . . . . . . . . . . . . . . . .

Pr. 5.12. Autenticacin por clave pblica . . . . . . . . . . . . . .

6. Redes privadas virtuales (VPN)

Creacin de una VPN: el cliente . . . . . . . . . . . . . .

Instalacin del servidor . . . . . . . . . . . . . . . . . . .

Laboratorio virtual con IPs

Laboratorios virtuales en el aula

Abrir la conguracin de VPN

Conguracin de una VPN en Ubuntu (cliente)

Resumen: En este captulo se congura un laboratorio virtual que

En este primer captulo, vamos a instalar las mquinas virtuales sobre

Captulo 1. El laboratorio virtual

5. Crear disco virtual nuevo:

VirtualBox Disk Image )

"FATAL: No bootable medium found! System halted.").

de instalacin de Debian en el CD de la mquina

: Conguracin de la red en Debian

En Debian la conguracin de la red est en dos cheros:

IP, mscara y puerta de enlace

Curso Seguridad en redes

Curso Seguridad en redes

Conguracin de la red en Debian . . . . . . . . . . . . .

Congurar el laboratorio virtual . . . . . . . . . . . . . .

Analizando trco de red . . . . . . . . . . . . . . . . . .

Primera conexin: comprobando el ngerprint

Encriptacin del chero known_hosts . . . . . . . . . . .

La importancia del ngerprint: interceptando una cone-

Pr. 5.12. Autenticacin por clave pblica . . . . . . . . . . . . . .

Abrir la conguracin de VPN

Conguracin de una VPN en Ubuntu (cliente)

Resumen: En este captulo se congura un laboratorio virtual que

: Conguracin de la red en Debian

En Debian la conguracin de la red est en dos cheros:

Analiza la conguracin actual (predenida tras la instalacin).

2. Vuelve a habilitarla. Qu pueden signicar las lneas que aparecen?

Para realizar una conguracin

antes de modicar el chero, y volverla a habilitar despus. Tambin pue-

ifup e ifdown son de alto nivel. La conguracin

de bajo nivel se realiza con

La conguracin realizada en Debian es a nivel

Al crear la mquina virtual de Debian, el interfaz de red se congur en

de red al que pertenezca el antrin.

1. Congura la tarjeta de red de Debian Servidor en modo puente.

la tarjeta de red del husped se conecta a un segmento de red

virtual gestionado por el software de virtualizacin. A ese segmento

1. Vuelve a congura la tarjeta de red de Debian Servidor en modo

En este modelo, se pueden crear redes NAT compartidas entre

Red interna: la tarjeta de red del husped se conecta a un segmento de

Adaptador slo antrin:

el host antrin, que recibe un interfaz

Tambin puedes utilizar directamente el interfaz grco de Virtual Box,

para ver la conguracin de red y comprueba que est

Guest additions . Por

ltimo, si el antrin tiene un procesador con varios ncleos, merece la pena