La leccin 1 incluye una descripcin de las principales barreras de seguridad (medidas preventivas) y las

lecciones 2 y 3 las desarrollan de forma prctica.

La leccin 2 se centra en el robustecimiento de sistemas (system hardening) y es eminentemente

prctica. Las dos primeras unidades proporcionan una descripcin general de proceso y establecen las
bases para el esto de actividades. La idea la leccin es comenzar con un servidor configurado de forma
poco segura y robustecerlo. Entre los ejercicios, todos ellos guiados, se intercalan dos presentaciones en
vdeo sobre lo que se va a necesitar en los ejercicios siguientes. La primera introduce el filtrado de
paquetes con IPTABLES y la segunda los fundamentos criptogrficos de SSH.

La leccin 3 se centra en la seguridad perimtrica. El objetivo de la leccin es configurar el filtrado de

paquetes en un cortafuegos con subred filtrada. Para ello, las tres primeras unidades proporcionan
nuevamente la base terica necesaria y el resto son ejercicios guiados para lograr el objetivo.

Video:08

Medidas preventivas
Las medidas preventivas son las que se toman para evitar que los ataques lleguen a
tener xito (apartado "prevencin" del proceso general de la seguridad, leccin 1.3).
Estas medidas se pueden agrupar en 4 barreras bsicas:
La seguridad fsica. Responsable de impedir el acceso fsico a los sistemas.
La autenticacin de usuarios. Una vez se tiene acceso al sistema (fsico o
remoto), es la responsable de identificar a los usuarios y de aceptarlos o
rechazarlos.
El control de acceso a los recursos. Una vez el usuario ha sido autenticado,
los procesos que lance estarn convenientemente etiquetados con su identidad.
El control de acceso es el mecanismo que permite establecer qu puede hacer
cada usuario con cada recurso del sistema.
El control de acceso a/desde otros sistemas. Responsable de ofrecer de forma
selectiva servicios a usuarios que acceden desde otros sistemas, as como de
permitir el acceso controlado a otros sistemas.

Estas 4 barreras se describen con ms detalle en los apartados siguientes. No obstante,

en lo referente a la seguridad preventiva conviene tener en cuenta tres ideas o
principios generalmente aplicables: reducir la superficie de ataque, tener cuidado con
"el eslabn ms dbil" y aplicar el principio de menor privilegio.

Reducir la superficie de ataque

Una estrategia bsica consiste en reducir al mximo las posibles vas de entrada al
sistema. Esto supone limitar al mximo el acceso a los sistemas, siempre teniendo en
cuenta que no existe la seguridad absoluta y que, por tanto, el objetivo debe ser
mantener un compromiso entre la seguridad y la utilidad del sistema.

Por ejemplo, un porttil u ordenador personal en muchos casos no necesita ofrecer

ningn servicio a otros ordenadores. Si se mantienen desactivados servicios como el
acceso remoto, la comparticin de ficheros, etc., indudablemente el sistema estar ms
seguro, ya que los posibles atacantes necesitarn buscar otras vas de acceso, como el
acceso fsico. No obstante, hay que tener en cuenta que cuando se utilizan servicios
tambin se est expuesto. Por ejemplo, un sitio web malicioso (o que haya sido
comprometido) podra explotar una vulnerabilidad del navegador del ordenador
personal e instalar un programa malicioso que permita el control remoto del
ordenador. Incluso si el ordenador estuviera completamente aislado de otros sistemas,
sera posible comprometerlo a travs de un medio de almacenamiento extrable, como
una memoria USB.

A nivel prctico y relacionndola con las 4 barreras, esta estrategia supone:

Limitar el acceso fsico al sistema.

Restringir los usuarios autorizados.
Restringir el acceso a los recursos.
Restringir servicios ofrecidos y utilizados.

Tener cuidado con el eslabn ms dbil

En seguridad informtica se utiliza mucho el smil de una cadena para hablar de la
seguridad de los sistemas. Igual que una cadena es tan fuerte como el ms dbil de sus
eslabones (da igual qu eslabn ha sido, la cadena est igualmente rota), los sistemas
son tan seguros como el ms inseguro de sus componentes. Este smil es til, ya que
pone de manifiesto la dificultad de conseguir un elevado nivel de seguridad.
Efectivamente, el atacante solamente necesita encontrar un punto dbil, mientras que
el responsable de seguridad debe proteger todas las posibles vas de ataque.

Otra forma de ilustrar esta idea es la frase que dice que "de nada sirve levantar muros
en el desierto" (porque la gente no lo escalar, sino que lo rodear). Esta idea incide
en la inutilidad de centrarse demasiado en un componente y hacerlo extremadamente
seguro (el muro en el desierto), mientras existen otros componentes mucho ms
dbiles.

Aplicar el principio del menor privilegio

El principio del menor privilegio consiste en ejecutar cada accin con el menor nivel
de privilegio posible. De esta forma, en caso de que algo funcione de forma diferente
a la esperada (por error, accidente o intencionadamente), los efectos negativos estarn
ms acotados y ser ms fcil detectar y corregir el problema. A nivel prctico, este
principio se puede aplicar de mtiples formas, y se volver a l frecuentemente a lo
largo del mdulo. Un ejemplo sera la ejecucin de un servidor web:

Sera preferible ejecutarlo usando un usuario no privilegiado a ejecutarlo como

administrador del sistema.
Sera preferible ejecutarlo en una mquina dedicada a ejecutarlo en una
mquina con otros servicios.
Sera preferible separar el servidor web en varios servidores cuando se manejan
datos de diferente sensibilidad, de forma que cada uno solamente pueda acceder
a los datos realmente necesarios.
Sera preferible alojar la mquina que contiene al servidor en una red separada
de la red corporativa.

Seguridad fsica
Se puede definir la seguridad fsica como el conjunto de medidas dirigidas a controlar
el acceso fsico a los sistemas. Lgicamente estas medidas forman parte de las
medidas de control de acceso fsico a las instalaciones. El objetivo, desde el punto de
vista de la seguridad informtica, es que el nivel de seguridad fsica sea adecuado. O,
dicho de otra forma, que la seguridad fsica no sea el "eslabn ms dbil de la
cadena". Aunque muchas medidas pueden ser igualmente aplicables a ambas
categoras, resulta til distinguir entre la proteccin de los componentes fsicos y la
proteccin de los datos.

Proteccin de los componentes fsicos

Las medidas de proteccin deben comenzar por asegurar que el entorno fsico resulta
apropiado para el funcionamiento de los sistemas. Sin tratar de ser exhaustivos, ser
necesario mantener una temperatura adecuada, evitar el exceso de polvo o de
humedad, la presencia de insectos, ruido electromagntico, vibraciones... Adems, se
debe disponer de los mecanismos de monitorizacin adecuados para detectar
desviaciones en temperatura, humedad... Por otra parte, tambin ser necesario
considerar posibles situaciones excepcionales (sean accidentales o intencionadas),
como inundaciones, fuegos, terremotos...
El siguiente elemento es un adecuado control de acceso fsico a los sistemas,
habitualmente integrado en el control de acceso a las instalaciones corporativas. No
obstante, en el caso de sistemas especialmente importantes, ser necesario tener en
cuenta la existencia de elementos como suelos elevados, falsos techos, conducciones
de aire...

Otro aspecto igualmente importante son las dependencias donde trabajan los
administradores de sistemas u otros usuarios con acceso privilegiado. Sus sistemas
pueden ser puntos de acceso al sistema (sus direcciones IP pueden estar permitidas a
traves de cortafuegos, pueden tener almacenadas claves o informacin sensible...). Por
lo tanto, un atacante podra optar por acercarse a uno de estos puestos (en vez de a los
servidores alojados en el centro de datos, mucho ms protegido) y, simplemente,
conectar una memoria USB son software malicioso. Otro elemento de riesgo es la
existencia de espacios difanos, paredes transparentes o, incluso, ventanas, que
puedan permitir grabar a estos usuarios mientras trabajan con su sistema (capturando
la pantalla o cmo teclean una contrasea).

Finalmente, tambin es necesario considerar la posibilidad los robos y los actos de

vandalismo (un martillo o unas tijeras pueden ser buenas herramientas para causar un
ataque de denegacin de servicio, si se tiene acceso fsico). Si bien el robo de un
ordenador de sobremesa o, sobre todo, de los servidores, pueden ser evitados con
cierta facilidad, hoy en da resulta mucho ms difcil proteger otro tipo de elementos
como los porttiles, las tabletas o los mviles, que pueden contener igualmente
informacin sensible.

Proteccin de los datos

Aunque las medidas anteriores tambin sirven para proteger los datos, hay aspectos
especficos que se explican mejor pensando exclusivamente en los datos.
Efectivamente, los datos son transmitidos a travs de diferentes tipos de redes, cada
una de las cuales supone sus propios retos.

Las redes cableadas, por ejemplo, solamente son ms seguras que las inalmbricas en
tanto en cuanto requieren acceso fsico a las mismas. De ah que su proteccin debe
ser incluida en el plan de seguridad fsica. No es infrecuente que hayan conectores de
red en lugares de acceso pblico, como cafeteras, salas de espera o de reuniones...
Cualquier roseta desatendida puede ser una posible va de acceso directo a la
informacin, sin necesidad de atravesar el cortafuegos corporativo. En cualquier caso,
un buen uso de la criptografa es un complemento ideal para las medidas de acceso
fsico.
Las redes wifi son cada vez ms frecuentes y, por comodidad, suelen ser utilizadas por
personal de la empresa, por lo que suelen transportar informacin confidencial.
Incluso aunque se utilicen puntos de acceso con WPA2, salvo que se utilice una
configuracin empresarial, el hecho de usar una clave precompartida por todos los
usuarios, hace difcil mantener el secreto. En este caso, a diferencia de las redes
cableadas, el acceso fsico puede no ser necesario, ya que las ondas electromagnticas
no quedan completamente confinadas al interior de las salas y/o los edificios en los
que se utilizan. Por este motivo, nuevamente es necesario utilizar adecuadamente
mecanismos criptogrficos.

Un caso aparte son las redes mviles, que no forman parte de la infraestructura
corporativa, pero que, cada vez ms, transportan informacin sensible. En este caso, la
seguridad fsica no puede ser el camino para mantener la seguridad de los datos. La
forma de proteger esta informacin es un uso especialmente cuidadoso de la
criptografa.

Adems de los datos en trnsito, es necesario prestar atencin al almacenamiento de

copias de la informacin: copias de seguridad, en los sistemas de impresin
modernos... El acceso fsico a cualquiera de estas copias debe estar igual de
controlado que a los dispositivos que se utilizan para manejar dicha informacin. En
el caso de las copias que se almacenen remotamente, la informacin debe estar
fuertemente cifrada, pues debe soportar el paso del tiempo y la mejora de las
herramientas para romper el cifrado. Por ltimo, es necesario planificar correctamente
los procedimientos para destruir la informacin en los medios de almacenamiento que
vayan siendo desechados.

Autenticacin de usuarios
El objetivo de la autenticacin de usuarios comprobar la identidad de un usuario,
aceptndole como tal si demuestra su identidad o rechazndole, en caso contrario.

Los principales mecanismos de autenticacin encajan en una de estas cuatro

categoras:

Posesin de un secreto. Al que solamente el usuario sabe. Por ejemplo, el

tpico usuario y contrasea.
Posesin de un objeto. Algo a lo que solamente el usuario tiene acceso. Por
ejemplo, una llave USB o una tarjeta inteligente.
Un atributo del usuario. Algo caracterstico del usuario, bien sea de su
cuerpo, como la huella dactilar, o de su comportamiento, como su tono de voz.
 Multifactorial. Usar dos o ms tcnicas de las anteriores combinadas
(mltiples factores).

Para evaluar la bondad de estos mecanismos se usan como criterio los siguientes
parmetros:
Tasa de falsas aceptaciones. La probabilidad de que el sistema acepte como
vlido a un impostor. Por ejemplo, un impostor (I) adivina la contrasea del
usuario (U) y el sistema acepta a I como si fuera U.
Tasa de falsos rechazos. La probablidad de que el sistema deniegue el acceso a
un usuario autorizado. Por ejemplo, se autentica por la voz, pero un usuario tiene
una afeccin de garganta y el sistema no reconoce su voz.

Lgicamente, el sistema ideal sera aqul que tiene unas tasas de falsas aceptaciones y
de falsos rechazos igual a 0. Sin embargo, al analizar a continuacin los diferentes
mecanismos se ver que es dificil hacer muy bajas simultneamente ambas tasas.

Posesin de un secreto: usuarios y contraseas

Usar una combinacin de usuario y contrasea es, con mucho, el mtodo ms habitual
basado en la posesin de un secreto. Efectivamente, el sistema asume que solamente
el usuario conoce su contrasea y, por lo tanto, basta con que el usuario demuestre que
la conoce para que el sistema le valide.

Hay varios motivos por los que el mtodo de usuario y contrasea es tan popular:

No requieren hardware especializado. A diferencia de otros mtodos, la el

usuario y la contrasea se pueden introducir mediante un teclado normal, sin
necesidad de un lector de tarjetas o de huellas dactilares, por ejemplo.
Son sencillas de implantar. Estn incluidas en todos los sistemas, con un
amplio soporte tanto para los administrador de sistemas y aplicaciones, como
para los desarrolladores de software.
Permiten acceso remoto. A diferencia de otros mtodos, se pueden utilizar a
travs de la red. Por ejemplo, el cliente puede enviar la contrasea a travs de un
canal cifrado para que el servidor la valide, o el servidor puede enviar un reto
aleatorio cifrado con la contrasea del usuario que ste debe resolver...

Sin embargo, las contraseas pueden presentar un elevado nmero de falsas

aceptaciones, ya que usarlas correctamente requiere la participacin de todos los
usuarios (el eslabn ms dbil sera el usuario con la contrasea ms dbil). En
general, las contraseas presentan los siguientes riesgos:
 Pueden ser adivinadas. Bien por ordenadores o por personas. Contraseas
cortas, palabras de diccionario o aqullas basadas en datos personales pueden ser
fcilmente adivinadas mediante ingeniera social y/o programas especializados
(como John The Ripper o Crack).
Pueden ser observadas. Si la contrasea se transmite a travs de un canal
inseguro, puede ser observada mientras se transmite a travs de la red. Si se
almacena de forma poco segura puede ser recuperada del medio de
almacenamiento. Un programa malintencionado la pueda grabar segn se
teclea...
Pueden ser transferidas a usuarios no autorizados. El sistema no puede
evitar que los usuarios compartan contraseas. Por ejemplo, los miembros de un
proyecto, un usuario que solicita ayuda a otro. Mediante ingeniera social puede
ocurrir que un usuario acabe trasfiriendo su contrasea a un atacante que, por
ejemplo, se hace pasar por un administrador de sistemas.
Pueden ser usadas en mltiples sitios con diferente nivel de seguridad. La
dificultad de gestionar un elevado nmero de contraseas robustas causa que sea
habitual reutilizar las contraseas en diferentes contextos (personal y
profesional, sitios web con diferente nivel de confianza, sitios web y
servidores...). Hay que tener en cuenta que la contrasea es tan segura como el
lugar menos seguro en el que se utiliza.

Por lo tanto, usar de forma segura las contraseas requiere una buena educacin de
todos los usuarios para que utilicen contraseas robustas, y conozcan y eviten los
riesgos.

Posesin de un objeto
El sistema exige a los usuarios que demuestren que tienen acceso a un objeto que los
identifica. Ejemplos habituales son los dispositivos utilizados para generar
contraseas de un solo uso, las tarjetas inteligentes, las llaves USB o, ms
recientemente, la posesin de un telfono mvil.

Atributos del usuario: tcnicas biomtricas

Las tcnicas biomtricas se basan en caractersticas propias de cada persona, ya sean
fisiolgicas o patrones de comportamiento que le caracterizan.

Con las tcnicas fisiolgicas se aprovecha alguna caracterstica propia del cuerpo de
las personas, ya sea su cara, el patrn de retina del ojo, la forma de su mano o las
habituales huellas dactilares. En principio, estas tcnicas pueden conseguir al mismo
tiempo una baja tasa de falsas aceptaciones como de falos rechazos. No obstante, es
necesario tener en cuenta que la precisin del mtodo depende mucho de la
implementacin. Por ejemplo, depende de cuantos puntos se utilicen para representar
(y comparar) las huellas dactilares. Dependiendo de la implementacin, el sistema
puede ser engaado. Por ejemplo, el reconocimiento de caras tiene que ser capaz de
distinguir entre la imagen de una persona real y la de una fotografa. Aunque
tradicionalmente han sido sistemas caros, ya que necesitan dispositivos
especializados, en los ltimos aos, debido a su popularizacin, el precio ha bajado
significativamente.

Cuando se utlizan patrones de comportamiento, se aprovecha algun tipo de accin que

solamente el usuario autorizado sabe realizar. Por ejemplo, la forma de pronunciar una
determinada frase, la forma de firmar, la cadencia a la hora de teclear una frase...
Nuevamente son sistemas precisos (baja tasa de falsas aceptaciones y falsos rechazos)
sobre el papel, pero dependen de la implementacin (por ejemplo, deben evitar que la
frase a pronunciar pueda haber sido grabada previamente, en el caso del
reconocimiento de voz).

Control de acceso a los recursos

Una vez autenticado un usuario, el sistema operativo permite la ejecucin de procesos
para atenderle, desde un intrprete de rdenes a un entorno grfico de escritorio. En
cualquier caso, todos los procesos creados a partir de la autenticacin inicial van
asociados al usuario al que representan en el sistema. El sistema operativo lo anota en
las esctructura de datos de control del proceso (el BCP, o bloque de control de
proceso), en una zona de memoria fsica que solamente es accesible en el modo
supervisor del procesador (o en el nivel ms alto de privilegio, si dispone de ms de
dos niveles). De esta forma, los procesos no pueden cambiar esta informacin de
identidad. Adicionalmente, los sistemas operativos suelen permitir la creacin de
grupos de usuarios, para facilitar la gestin del sistema, por lo que cada proceso est
asociado con un usuario e, indirectamente, a travs del usuario, con una serie de
grupos de usuarios.

A partir de esta informacin, el sistema operativo debe controlar qu operaciones

puede realizar cada proceso con los diferentes recursos del sistema, desde ficheros a
procesos, pasando por conexiones de red, acceso a dispositivos o a diferentes zonas de
memoria. Dependiendo del tipo objeto (recurso) del que se trate, estarn definidas
diferentes operaciones, que se corresponden con los tipos de acceso que pueden ser
especificados. A modo de ejemplo, se pueden nombrar los siguientes:

Relativos al sistema de ficheros: lectura, escritura, ejecucin, aadir datos al

final, consultar los atributos, listar el contenido de un directorio, aadir una
entrada en un directorio...
 Relativos a la comunicacin entre procesos: enviar o recibir un mensaje, enviar
un evento o seal...
Relativos a dispositivos fsicos: imprimir, grabar audio y/o vdeo, realizar una
foto, leer una huella dactilar, dar formato a un disco...
Relativos a la administracin del sistema: cambiar la contrasea, aadir
usuarios, eliminarlos, gestionar grupos de usuarios, realizar una copia de
seguridad, establecer una conexin de red...

Respecto a los mecanismos de control de acceso, los hay de dos clases, control de
acceso discreccional y control de acceso obligatorio. La diferencia fundamental entre
ambos modelos es quin establece qu tipos de acceso estn permitidos para cada
usuario o grupo.
En el control de acceso discreccional (DAC, Discretionary Access Control) existe el
concepto de dueo del objeto, que habitualmente es el usuario que lo crea. El usuario
que es dueo del objeto tiene la capcidad de establecer quin puede acceder al objeto
y qu operaciones puede realizar con l. Por ejemplo, el que crea un fichero puede
decidir si puede leerlo todo el mundo o solamente ciertos usuarios y/o grupos de
usuarios.
En cambio, en el control de acceso obligatorio (MAC, Mandatory Access Control),
existe la figura del administrador de seguridad, que es el nico que puede establecer
quin puede acceder a cada uno de los objetos y qu operaciones puede realizar con
l. La ventaja de este tipo de sistemas es que permite establecer garantas que no
dependen de la colaboracin de los usuarios, mientras que el discreccional tiene la
ventaja de una mayor flexibilidad.

Control de acceso a/desde otros sistemas

Finalmente, esta cuarta barrera preventiva es responsable de controlar las
interacciones a travs de la red que realiza cada sistema, tanto en el sentido de
controlar el acceso desde otros sistemas a los servicios ofrecidos, como desde el punto
de vista del acceso a servicios ofrecidos por otros sistemas.

Control del acceso desde otros sistemas

Este es el enfoque ms tradicional, cuyo objetivo es garantizar que solamente los
usuarios autorizados pueden usar los diferentes servicios, hacindose efectivas las
restricciones establecidas en la poltica de seguridad de la organizacin. El solamente
hace referencia a garantizar que el sistema no es utilizado por usuarios no autorizados,
ni para el acceso a los servicios o informacin del propio sistema ni como pasarela
para atacar a otros sistemas (de la propia organizacin o de terceros).
Para conseguir que este control sea efectivo se trabaja a varios niveles:

Limitar el acceso al sistema. Limitar las posibilidades de acceso al sistema a

travs de la red, tanto mediante herramientas de seguridad perimtrica (filtrado
de paquetes, proxies) como de nodo (filtrado de paquetes, cortafuegos
personales...). Esta primera capa de proteccin evita que los paquetes del
atacante puedan siquiera llegar al sistema, limitando la posibilidad de explotar
posibles vulnerabilidades.
Limitar los servicios ofrecidos. En la misma lnea de reducir la superficie de
ataque, solamente deben ofrecerse aquellos servicios que realmente son
imprescindibles y solamente desde donde sea necesaria su utilizacin. A esta
segunda capa corresponde una configuracin cuidadosa de los servicios y sus
opciones, controlando el acceso bien mediante mecanismos propios del servicio,
bien mediante programas especializados como los encapsuladores (por
ejemplo, tcpwrappers o xinetd).
Limitar la utilizacin de los servicios. Utilizar mecanismos de autenticacin
de usuarios apropiados para el acceso a travs de la red, de forma que se puedan
aplicar adecuadamente los controles de acceso a los recursos ya discutidos.

Control de acceso a otros sistemas

El enfoque complementario supone limitar, o controlar, el acceso desde el sistema a
otros nodos, dificultando as que un sistema comprometido pueda ser usado para
atacar a otros sistemas (propios o de terceros). A diferencia del caso anterior, en el que
se trataba de evitar que un atacante pudiera comprometer el sistema, en este caso el
objetivo es detectar el intento de acceso para evitar la propagacin del ataque. En este
sentido se pueden utilizar tanto herramientas perimetrales como mecanismos
ofrecidos por el propio sistema, como filtrado de paquetes o limitacin del acceso a
Internet en base a perfiles de aplicaciones.

Leccin 2: Asegurando clientes y servidores

En esta leccin se plantea, desde un punto de vista prctico, cmo endurecer los
sistemas (del ingls, system hardening). El endurecimiento, aseguramiento o
robustecimiento, dependiendo de la traduccin elegida, consiste, bsicamente, en
aplicar en cada sistema las medidas preventivas que se consideren apropiadas en
funcin del nivel de seguridad que se desea conseguir. Las medidas a aplicar van a
depender de la funcin que vaya a desempear cada sistema y de ah el ttulo de la
leccin, que hace referencia a los diferentes riesgos asumidos por clientes y
servidores.
Siguiendo con el enfoque prctico del curso, en esta leccin se har el hardening de la
mquina extc de NETinVM. Para contextualizar adecuamente las diferentes acciones
prcticas, la leccin incluye tres vdeos introductorios, cada uno de los cuales precede
a los ejercicios en los que se aplican los conceptos introducidos.
El primer vdeo, "Endurecimiento de sistemas (system hardening)" explica en qu
consiste el endurecimiento de sistemas e incluye las recomendaciones necesarias para
conseguirlo. El vdeo comienza por las aplicables a cualquier tipo de sistema, contina
con las especficas para servidores y finaliza con las recomendaciones para mquinas
con el rol de cliente. Siguiendo con las recomendaciones de este vdeo, los primeros
ejercicios consisten en aplicar los parches disponibles para extc y limitar los servicios
en ejecucin.
El siguiente paso sera limitar el acceso a los servicios. Para conseguirlo se utilizan
habitualmente programas envolventes (wrappers) como tcpd o xinetd y, por supuesto,
el filtrado de paquetes. Para hacer ms corta la leccin, se ha optado por utilizar
nicamente el filtrado de paquetes y, por eso, el segundo vdeo "Filtrado de paquetes
con IPTABLES", explica el soporte para filtrado de paquetes en Linux
(Netfilter/Iptables) y muestra cmo utilizarlo en los nodos de NETinVM.
Lgicamente, el siguiente ejercicio consiste en configurar el filtrado de paquetes en un
servidor (extc, en este caso).
Finalmente, es necesario robustecer al mximo los servicios que es necesario ofrecer.
Como cada servicio tiene sus propios problemas de seguridad, se ha optado por
utilizar como caso de ejemplo el servicio SSH, necesario para la administracin
remota de servidores. SSH se apoya fuertemente en tcnicas criptogrficas para
garantizar su seguridad y, por tanto, es necesario tener claras algunas ideas bsicas
sobre criptografa para poder configurar y utilizar adecuadamente esta herramienta.
Por eso, el tercer vdeo "Criptografa en SSH" introduce los conceptos bsicos de
criptografa necesarios para entender SSH y sus mecanismos de seguridad, mostrando
cmo se pueden utilizar estos conceptos para trabajar con SSH aprovechando la
autenticacin mediante criptografa asimtrica. La leccin finaliza con ejercicios en
los que se robustece el servidor SSH de extc y se utiliza la criptografa asimtrica para
la autenticacin y para la realizacin de tareas especficas de administracin remota.

Video:09

Ejercicio: Restaurar la copia de seguridad para la unidad

En esta unidad se va aprender a robustecer un servidor Linux. Para que el ejercicio
resulte ms realista, es necesario comenzar en un escenario diferente al que viene por
defecto con NETinVM. Aprovechando la posibilidad de realizar y restaurar copias del
estado de las mquinas UML, se prodecer a restaurar un estado preparado
especficamente para este ejercicio en el que el servidor dmzc tiene una configuracin
poco segura.
El estado est almacenado en el fichero "uml_machines_2015-07-30_10-
04_hardening.tgz", incluido como copia de seguridad en la NETinVM del curso. (La
descripcin de cmo hacer copias de seguridad y cmo restaurarlas est incluida en la
demostracin "Copias de seguridad de las UMLs").
Aviso
Al restaurar una copia de seguridad se elimina el estado actual de las UML. Por lo
tanto, se recomienda realizar una copia de seguridad antes.
Acciones a realizar:
1. Comprobar que las mquinas UML estn paradas.
2. Realizar, si no se ha hecho antes, una copia del estado actual y etiquetarlo
adecuadamente renombrando el fichero resultante.
3. Restaurar la copia de seguridad indicada.

Ejercicio: Preparar una configuracin de UMLs

personalizada
Para los ejercicios siguientes, se va a utilizar dmzc como ejemplo de servidor poco
seguro en el que ir aplicando las diferentes medidas para robustecer los sistemas.
Durante los ejercicios se van a usar las siguientes mquinas UML:
dmzc. Ejemplo de servidor mal configurado.
fw. Necesario para que dmzc pueda acceder a las diferentes redes UML y a
Internet.
exta. Mquina con acceso desde la red externa.
inta. Mquina con acceso desde la red interna.

Para que solamente se pongan en marcha las UMLs indicadas, ser necesario
modificar el guin "uml_run_my_uml.sh". (La forma de hacerlo se describe en la
unidad Ejercicio: Puesta en marcha de un cierto conjunto de UMLs).
Acciones a realizar:
1. Editar el guin "uml_run_my_uml.sh" para que solamente se ejecuten las
mquinas indicadas.
2. Lanzar las mquinas UML usando el icono "Run my UMLs".
3. Comprobar que efectivamente se han puesto en marcha las mquinas esperadas
Ejercicio: Aplicar parches
Cada distribucin de Linux tiene su propias herramientas para la gestin de paquetes,
pero en todas existe la opcin de instalar actualizaciones. En el caso de Debian, la
herramienta de gestin de paquetes se denomina apt-get, y la forma de actualizar el
sistema es ejecutar las siguientes rdenes:
apt-get update
apt-get upgrade

La primera actualiza la informacin sobre los paquetes disponibles en los repositorios.

Y la segunda permite aplicar las actualizaciones disponibles. Esta segunda orden
muestra la lista de cambios que se realizarn en el sistema y solicita confirmacin
antes de continuar.
Aviso: esta copia de dmzc tiene una lista anticuada de repositorios, por lo que es
necesario ejecutar antes la orden "sh /mnt/tmp/update_apt-get.sh" como "root"
en dmzc. (En caso de haber borrado este fichero, se puede descargar de
nuevo: update_apt-get.sh. Si se descarga en "base", es necesario guardarlo en la
carpeta "/home/user1/uml/mntdirs/tmp/").
Acciones a realizar:
1. Ejecutar la orden "sh /mnt/tmp/update_apt-get.sh".
2. Actualizar la mquina dmzc.

Durante la actualizacin, puesto que se actualiza la librera del sistema ("libc"), es

normal que se sugiera reiniciar algunos servicios. Se debe seleccionar "Ok" en el
cuadro de dilogo que aparece.
Tras la actualizacin, si se intenta una nueva actualizacin, apt-get upgrade debera
indicar que no hay cambios pendientes:
root@dmzc:~# apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Accin a realizar: comprobar que no quedan cambios pendientes en dmz

Ejercicio: Limitar los servicios en ejecucin

Lgicamente, la mejor forma de reducir los servicios en ejecucin es no instalar (o eliminar) los
paquetes de los servicios que no se van a utilizar. De todas formas, desactivar los servicios en
Debian es sencillo, pues basta con usar la orden insserv.
Sin embargo, lo primero es saber qu servicios estn en ejecucin. Para ello se puede usar la
orden netstat o, la ms reciente, ss. Por ejemplo, con netstat
root@dmzc:~# netstat --inet --listen -np
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address
State PID/Program
name
tcp 0 0 0.0.0.0:59646 0.0.0.0:*
LISTEN
1189/rpc.statd
tcp 0 0 0.0.0.0:2049 0.0.0.0:*
LISTEN
-
tcp 0 0 0.0.0.0:111 0.0.0.0:*
LISTEN
1175/portmap
tcp 0 0 0.0.0.0:80 0.0.0.0:*
LISTEN
1386/apache2
tcp 0 0 0.0.0.0:45840 0.0.0.0:*
LISTEN
-
tcp 0 0 0.0.0.0:22 0.0.0.0:*
LISTEN
1509/sshd
tcp 0 0 0.0.0.0:36089 0.0.0.0:*
LISTEN
1369/rpc.mountd
udp 0 0 127.0.0.1:941
0.0.0.0:*
1189/rpc.statd
udp 0 0 0.0.0.0:49362
0.0.0.0:*
1369/rpc.mountd
udp 0 0 0.0.0.0:111
0.0.0.0:*
1175/portmap
udp 0 0 0.0.0.0:36209
0.0.0.0:*
-
udp 0 0 0.0.0.0:2049
0.0.0.0:*
-
udp 0 0 0.0.0.0:48280
0.0.0.0:*
1189/rpc.statd
root@dmzc:~#

El resultado informa de que hay procesos escuchando en 7 puertos TCP y en 6 de UDP. Muchos
puertos estn asociados con servicios bien conocidos, y estn incluidos en el fichero
"/etc/services". La orden "netstat" puede consultar este fichero y dar una salida ms fcil de leer
si eliminamos la opcin "-n" (de numeric).
De los puertos asignados, en TCP estn en escucha el 2049 (nfs), 111 (sunrpc), el 80 (www) y
el 22 (ssh). Adems, "netstat" nos indica que, por ejemplo, en el puerto 22 de TCP est
escuchando el proceso con identificador (PID) 1509 y que el programa que est ejecutando este
proceso en "sshd". Puesto que no estn enlazados con ninguna direccin concreta, todos los
servicios pueden ser usados desde cualquier IP. Sin embargo, el puerto 2049 no est asociado con
ningn proceso, lo que indica que es el propio ncleo de Linux el que est escuchando. De forma
similar se puede observar que en UDP estn abiertos tambin los puertos 111 (sunrpc) y 2049
(nfs).

Los puertos no asignados pueden haber sido usados por cualquier aplicacin. Sin embargo, si
est en marcha el servidor portmap (servicio 111, sunrpc), las aplicaciones que usan RPC
(Remote Procedure Calls) pueden registrarse con el portmapper para que los clientes sepan a qu
puertos deben conectarse. ste es el caso de servicios asociados a NFS como el estado (status,
ofrecido por rpc.statd), cerrojos (nlockmgr, ofrecido directamente por el ncleo en este caso) o el
montaje de sistemas NFS (mountd, ofrecido por rpc.mountd). La forma de saber qu puertos
estn usando los servidores que usan RPCs es usar la orden "rpcinfo":
root@dmzc:~# rpcinfo -p
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 48280 status
100024 1 tcp 59646 status
100021 1 udp 36209 nlockmgr
100021 3 udp 36209 nlockmgr
100021 4 udp 36209 nlockmgr
100021 1 tcp 45840 nlockmgr
100021 3 tcp 45840 nlockmgr
100021 4 tcp 45840 nlockmgr
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100005 1 udp 49362 mountd
100005 1 tcp 36089 mountd
100005 2 udp 49362 mountd
100005 2 tcp 36089 mountd
100005 3 udp 49362 mountd
100005 3 tcp 36089 mountd
root@dmzc:~#

Accin a realizar: comprobar los servicios activos en dmzc usando netstat (o ss) y rpcinfo.
Lo siguiente es averiguar el nombre de los servicios que lanzan a los procesos que estn
aceptando conexiones. Aunque en este caso ms o menos coinciden, puede ser necesario realizar
cierta tarea de averiguacin. Los nombres de los servicios se corresponden con los guiones de
intrprete de rdenes que estn alojados en el directorio "/etc/init.d".

Una vez se sabe el nombre del servicio, ser necesario hacer dos cosas:
 1. Parar el servicio. Para ello se utiliza la orden "service nombre_de_servicio stop".
2. Cambiar la configuracin para que el servicio no se ponga en marcha la prxima vez que
arranque el sistema. Para ello se usa la orden "insserv" con la opcin "-r".

Acciones a realizar:
1. Parar los servicios "nfs-kernel-server", "nfs-common", "portmap" y "apache2".
2. Cambiar la configuracin del sistema para que estos servicios no se activen en el prximo
arranque.
3. Rearrancar dmzc.
4. Comprobar que solamente ofrece el servicio SSH.

Video:14

Ejercicio: Configurar el filtrado de paquetes en el

servidor
Desde el punto de vista de la seguridad del servidor, el objetivo principal es limitar el
trfico entrante al estrictamente necesario. Para ello, se propone la siguiente
configuracin:

Cambiar la poltica de las cadenas INPUT y FORWARD para que por defecto
dejen caer los paquetes.
Dejar la poltica de OUTPUT para que permita pasar todos los paquetes.
Permitir el trfico entrante a travs de la interfaz de loopback.
Permitir el trfico entrante correspondiente a conexiones establecidas y/o
relacionadas.
Permitir conexiones entrantes de SSH desde base (la IP de base en la red DMZ
es 10.5.1.1).
Permitir consultas entrantes de tipo ICMP ECHO REQUEST.

Lgicamente, aunque esta configuracin resulta apropiada como ejemplo, debe ser
adaptada para permitir todos los servicios que el servidor ofrezca (ej: HTTP, HTTPS,
DNS, FTP...). Adems, restringir el trfico saliente permitira reducir el dao que
podra realizar el servidor a otros sistemas en caso de ser comprometido, o detectar las
intrusiones si se registran los paquetes salientes denegados. Sin embargo, habra que
tener en cuenta que en caso de que el atacante consiguiera acceso como root, podra
cambiar fcilmente la configuracin del filtrado de paquetes.
De cara a comprobar la efectividad del filtrado de paquetes, conviene poner en marcha
algunos servicios adicionales que no deberan ser accesibles una vez en marcha el
filtrado. (En un caso real, la recomendacin es no conectar el sistema a la red hasta
que no est configurado el filtrado de paquetes y, desde luego, no ejecutar ningn
servicio que no sea estrictamente necesario).

Acciones a realizar:
1. En dmzc, poner en marcha los servicios portmap y apache2.
2. Desde base, comprobar que:
Es posible conectarse por SSH.
Responde a ping (por defecto enva ICMP ECHO REQUEST).
Es posible obtener un listado de los servicios basados en RPC
registrados en dmzc. (Sugerencia: usar la orden "rpcinfo -p dmzc").
Es posible acceder al servidor HTTP. (Sugerencia: usar "wget dmzc").
3. Desde base, como root, realizar un barrido de puertos sobre dmzc para
corroborar la informacin previa.

Una vez comprobado que dmzc est expuesta, es el momento de aplicar el filtrado de
paquetes y observar la diferencia.
Acciones a realizar:
1. Configurar dmzc de forma limite el trfico segn la configuracin anterior.
2. Desde base, comprobar que:
Responde a ping (por defecto enva ICMP ECHO REQUEST).
Es posible conectarse por SSH.
No es posible obtener un listado de los servicios basados en RPC
registrados en dmzc. (Sugerencia: usar la orden "rpcinfo -p dmzc").
No es posible acceder al servidor HTTP. (Sugerencia: usar "wget
dmzc").
3. Desde base, como root, realizar un barrido de puertos sobre dmzc para
corroborar la informacin previa.
4. Desde dmzc, comprobar que los servicios portmap y apache2 siguen activos.
(Sugerencia: usar rpcinfo y wget usando como nombre de nodo localhost).
5. Arrancar dmzd.
6. Desde dmzd, comprobar que:
dmzc responde a ping .
No es posible conectarse por SSH a dmzc.
No es posible obtener un listado de los servicios basados en RPC
registrados en dmzc. (Sugerencia: usar la orden "rpcinfo -p dmzc").
No es posible acceder al servidor HTTP de dmzc. (Sugerencia: usar
"wget dmzc").
7. Desde dmzd, como root, realizar un barrido de puertos sobre dmzc para
corroborar la informacin previa.
Finalmente, una vez comprobada la configuracin, debe hacerse permanente. En
Debian, la forma ms sencilla de hacerlo es instalar el paquete iptables-persistent, que
se encarga de hacerlo. Una vez instalado el paquete, lo nico que hace falta es rellenar
el fichero "/etc/iptables/rules" con la configuracin adecuada para IPTABLES
(obtenida, por ejemplo, con iptables-save).
Acciones a realizar:
1. Instalar en dmzc el paquete iptables-persistent.
2. Guardar la configuracin de IPTABLES en "/etc/iptables/rules".
3. Rearrancar dmzc.
4. Comprobar que la configuracin sigue aplicada tras rearrancar.

Video:15

Ejercicio: Robustecer el servidor SSH

La configuracin del servidor SSH se halla en el fichero "/etc/ssh/sshd_config". El
servidor la lee una vez al arrancar y posteriormente cada vez que recibe la seal
SIGHUP. Por tanto, cuando se cambia el fichero de configuracin es necesario
informar al servidor usando la orden "service ssh reload".

Aunque existen mltiples aspectos que considerar, los ms relevantes son:

Restringir el acceso al servidor. Aunque es recomendable usar herramientas

complementarias como tcpd y el filtrado de paquetes para limitar el acceso al
servidor, se puede limitar las interfaces en que escucha el servidor usando la
opcin ListenAdress.
Permitir nicamente la versin 2 del protocolo SSH. La versin 1 es menos
segura, y todos los servidores y clientes actuales soportan la versin 2.
(Opcin Protocol).
Cambiar el puerto de escucha. Muchos de los intentos de ataque van
dirigidos a servidores SSH que escuchan en el puerto 22. Aunque cambiar el
puerto de escucha no protege frente a ataques dirigidos, s evitar muchos
intentos. Lo mejor es usar un puerto no privilegiado, como el 50000.
(Opcin Port).
Deshabilitar mtodos de autenticacin inseguros, y todos los que no se
vayan a usar. La autenticacin basada en nodos es insegura
 (opciones RhostsRSAAuthentication y HostbasedAuthentication), y tambin lo
es permitir el acceso sin contrasea (opcin PermitEmptyPasswords). Si es
posible, dejar nicamente la autenticacin mediante clave privada (se aborda en
el siguiente ejercicio).
Utilizar preferiblemente autenticacin mediante clave privada. (Se aborda
en el siguiente ejercicio).
Restringir los usuarios que pueden acceder mediante SSH. Se puede
permitir selectivamente que solamente accedan ciertos usuarios y/o grupos
(opciones AllowUsers y AllowGroups). Alternativamente se puede denegar
selectivamente el acceso a ciertos usuarios y/o grupos
(opciones DenyUsers y DenyGroups). Sin embargo, desde el punto de vista de la
seguridad, siempre es preferible denegar por defecto y permitir explcitamente
(primera opcin).
Restringir el acceso del administrador. Aunque el acceso por SSH,
especialmente si se usa criptografa asimtrica, es seguro, es recomendable
impedir el acceso directo del administrador (opcin PermitRootLogin) y exigir a
los usuarios que usen su o, mejor, sudo, para realizar tareas de administracin.

El servidor SSH enva sus mensajes al registro del sistema usando el

identificador auth, por lo que en Debian 6 los mensajes van a "/var/log/auth.log". Una
forma sencilla de monitorizar este fichero para comprobar el funcionamiento del
servicio es mediante la orden "tailf/var/log/auth.log".
Acciones a realizar:
1. Configurar de forma segura el servidor SSH de dmzc, permitiendo el acceso
mediante usuario y contrasea al usuario user1 exclusivamente. (La
autenticacin por clave privada se abordar en el siguiente ejercicio).
2. Asegurarse de que el servidor carga la la nueva configuracin.
3. Comprobar que los cambios son efectivos.

Ejercicio: Autenticacin mediante criptografa asimtrica

en SSH
Usar criptografa asimtrica aumenta la seguridad (respecto a la contrasea
tradicional), pues el usuario necesita tener acceso a la clave privada que, a su vez, est
protegida por una contrasea robusta (idealmente una frase de paso).

El primer paso para usar criptografa asimtrica es crear un par de claves en la

mquina desde la que se va a iniciar la conexin al servidor SSH. En este caso se
usar como mquina de trabajo base.example.net. La orden ssh-keygen crea un par de
claves RSA (la pblica y la privada). Ambas son almacenadas por defecto en el
directorio ".ssh" del directorio inicial del usuario. La clave privada se denomina por
defecto "id_rsa" y la pblica "id_rsa.pub".
Acciones a realizar:
1. Crear un par de claves RSA en base.example.net como usuario user1. (Es
importante usar una frase de paso segura).
2. Localizar el fichero con la clave pblica y el fichero con la clave privada.

El segundo paso es depositar una copia de la clave pblica en el servidor. La copia (el
contenido del fichero con la clave pblica) debe ser aadida al fichero
".ssh/authorized_keys" del directorio inicial del usuario correspondiente en el
servidor. Por ejemplo, para permitir el acceso como user3, la copia debera ser
aadida al fichero "/home/user3/.ssh/authorized_keys". (Si el directorio no existe,
debe ser creado con permisos de lectura, escritura y ejecucin exclusivamente para el
dueo, sin ningn permiso para el resto).
Una vez aadida la copia, si se intenta una conexin SSH, el sistema debe solicitar la
frase de paso con la que desbloquear la clave privada. La peticin viene del cliente
SSH, pues el servidor nunca solicita la clave privada; lo que hace es enviar un reto
cifrado con la clave pblica del usuario, de forma que sea necesario usar la clave
privada para resolverlo.

Acciones a realizar:
1. Si no existe, crear el directorio "/home/user1/.ssh" en dmzc con permisos
solamente para el dueo. (Sugerencia: usar "mkdir -m go= /home/user1/.ssh").
2. Depositar la copia de la clave pblica en "/home/user1/.ssh/authorized_keys".
3. Probar a conectarse desde base a dmzc como user1.
4. Comprobar que se solicita la frase de paso de la clave privada y no la
contrasea de user1 en dmzc.

Nota
Alternativamente, se puede usar en base, como "user1", la orden "sshcopyidi
/home/user1/.ssh/id_rsa.pubdmzc". El programa "ssh-copy-id" se encarga de
comprobar que la clave no est registrada en dmzc y, si no lo est, de transferir la
copia de la clave pblica al sitio adecuado ("/home/user1/.ssh/authorized_keys"),
creando la carpeta ".ssh" si es necesario.

Ejercicio: Usar el agente de autenticacin de SSH.

Aunque usar la criptografa asimtrica tal y como se ha sugerido en el ejercicio
anterior es seguro, tener que introducir la frase de paso de la clave privada cada vez
que se desea iniciar una conexin resulta incmodo. Afortunadamente, el agente de
autenticacin es un proceso que guarda en memoria principal una copia sin cifrar de
las claves privadas que se le indiquen. Cuando se est ejecutando y el cliente de SSH
necesita acceder a una clave privada, primero trata de obtenerla del agente y, si tiene
xito, no solicita la frase de paso. Por tanto, solamente habr que introducir la frase de
paso una vez por sesin.

En los entornos grficos como KDE es habitual que el agente de ejecucin se inicie
automticamente al iniciar la sesin grfica. Si es as, se pueden aadir claves
directamente. ste es el caso de base. Para comprobar que se tiene acceso al agente de
autenticacin basta con ejecutar la orden "ssh-add -l". La respuesta debe ser similar a
sta:
user1@base:~> ssh-add -l
The agent has no identities.
user1@base:~>

Si, en cambio, el mensaje es "Could not open a connection to your authentication

agent.", entonces es necesario lanzarlo ejecutando la siguiente orden en la terminal de
"base" que vayamos a utilizar:
eval $(ssh-agent)

La misma orden ssh-add permite tambin aadir claves privadas al agente (y

eliminarlas). Por ejemplo, para aadir una copia de la clave privada al
agente, user1 simplemente tendra que usar la orden "ssh-add
/home/user1/.ssh/id_rsa". Lgicamente este proceso requiere introducir la frase de
paso.
Si todo va bien, el listado de claves debera incluir un elemento:
user1@base:~> ssh-add -l
2048 ed:ad:15:59:fc:48:d1:e0:97:42:67:81:b6:aa:71:37 [MD5]
/home/user1/.ssh/id_rsa (RSA)
user1@base:~>

A partir de ese momento, el acceso a cualquier servidor en el que est registrada esta
clave, debera realizarse sin necesidad de volver a introducir la frase de paso.
Acciones a realizar:
1. Aadir la clave privada generada en el ejercicio anterior al agente de
autenticacin en base. (Como user1).
2. Conectarse desde base a dmzc como user1.
3. Comprobar que no es necesario introducir la frase de paso ni la contrasea.

Ejercicio: Usar claves para tareas especficas

Un aspecto muy interesante de la autenticacin mediante criptografa asimtrica en
SSH es la posibilidad de configurar el servidor para que aplique opciones de
configuracin especficas en funcin de la clave que utilice el cliente. As, por
ejemplo, si un usuario tiene un contenido como ste (donde parte de la clave ha sido
sustituida por puntos suspensivos por legibilidad) en su fichero
".ssh/authorized_keys":
user1@dmzc:~$ cat /home/user1/.ssh/authorized_keys
ssh-rsa AAAA...nhfzxa9 user1@base
no-X11-forwarding ssh-rsa AAAA...Wtua+7 user1 - clave dos
command="/usr/local/bin/backup-server" ssh-rsa AAAA...gxgeZrn user1 - clave
tres
user1@dmzc:~$

Entonces se cumple lo siguiente:

La primera clave no tiene restricciones.
Con la segunda no se pueden redirigir las conexiones X.
Con la tercera, independientemente de la orden que se intente ejecutar, lo que
ocurrir es que se ejecutar el programa "/usr/local/bin/backup-server".

Estos ejemplos estn descritos en la pgina del manual de authorized_keys. Aunque

todas son interesantes, la tercera permite delegar tareas que pueden ser iniciadas
remotamente de forma automtica. Para ello bastara usar una clave privada sin frase
de paso.
Aunque de forma general se recomienda usar frases de paso robustas y usar el agente
de autenticacin para no tener que teclearlas frecuentemente, en este caso, al estar
limitado el efecto que se puede causar, el riesgo es menor. Y, de todas formas, sigue
siendo necesario el acceso a la clave privada, que debe estar bien protegida.

Acciones a realizar:
1. Crear un nuevo par de claves fcilmente identificable. (Sugerencias: no poner
frase de paso, usar un nombre adecuado para el fichero como
"clave_mantenimiento", y un comentario igualmente indicativo como "Clave
para mantenimiento").
2. Copiar la clave pblica en el "authorized_keys" de user1 en dmzc.
3. Editar el fichero para que con la nueva clave solamente se pueda averiguar
quin est conectado y qu est ejecutando (orden "/usr/bin/w").
4. Comprobar que, usando la nueva clave, independientemente de lo que se
intente, lo nico que se obtiene es el listado esperado. (Sugerencias: asegurarse
antes de que el agente de autenticacin no tiene identidades cargadas; si las
tiene, eliminarlas con "ssh-add -D"; y usar la opcin "-i" para indicar qu clave
debe usar el programa "ssh").
Leccin 3: Asegurando el permetro
En esta leccin se plantea un modelo de seguridad basado en el control de acceso a
nivel de red. Si al hablar de asegurar clientes y servidores se haca nfasis en las
medidas que se podan aplicar a nivel de nodo, en la seguridad perimtrica se pone el
foco en limitar el acceso entre diferentes redes. El vdeo introductorio "Seguridad
perimtrica" explica el concepto de seguridad perimtrica y el de cortafuegos, e
introduce brevemente las dos tecnologas bsicas de su diseo y construccin,
los proxies y el filtrado de paquetes.
Para mantener el nivel prctico del curso, en esta leccin se realizarn ejercicios que
en permitirn, en conjunto, configurar adecuadamente el encaminador de
NETinVM(la mquina fw), de forma que se tenga un cortafuegos operativo basado en
la estructura habitual de subred filtrada. Para ello, el texto "Descripcin del
cortafuegos de NETinVM" explica la estructura utilizada y el papel de fw, y
proporciona la base necesaria pra la realizacin de los ejercicios. Aunque no es
necesario, s resulta recomendable tener fresco el trabajo realizado al asegurar la
mquina extc y, en particular, el vdeo introductorio "Filtrado de paquetes con
IPTABLES" de la leccin "Asegurando clientes y servidores".

Video:13

Descripcin del cortafuegos de NETinVM

La propia estructura de NETinVM se centra alrededor de su cortafuegos, formado por los
siguientes elementos:

La red perimtrica o DMZ.

Los nodos bastin alojados en la red perimtrica. Por defecto se usan el servidor Web y el
servidor FTP, pero es posible usar igualmente las mquinas intc, intd, inte e intf.
El encaminador y filtro de paquetes, fw.
Esta estructura es habitual en la bibliografa y se suele recomendar para la mayor parte de usos,
ya que permite tanto ofrecer servicios como utilizarlos de forma razonablemente segura.

Ofreciendo servicios
A la hora de ofrecer servicios, los puntos ms dbiles siempre son los nodos bastin que ofrecen
los servicios. Efectivamente, para ofrecer el servicio deben ser accesibles directamente desde
Internet y, por tanto, se convierten en el principal vector de entrada. Por este motivo, estos nodos
se fortifican lo mximo posible (de ah el nombre de nodos bastin), tal y como se ha visto en la
leccin 3.2.
Con esta estructura de subred filtrada, la principal fortaleza es que en caso de que se vea
comprometido un nodo bastin, la red interna todava est protegida por el encaminador fw, que
limita el acceso desde los nodos bastin a la red interna. Esta barrera extra de seguridad permite
reaccionar antes de que los nodos internos sean atacados.
Adems, el propio encaminador supone una primera barrera de proteccin para los nodos
bastin, ya que, mediante el filtrado de paquetes, puede restringir el acceso exclusivamente a los
puertos estrictamente necesarios.

Finalmente, usar una subred filtrada permite separar los servicios en diferentes nodos bastin, en
funcin del tipo de servicio, su riesgo y/o la sensibilidad de la informacin.

Utilizando servicios
Esta estructura tambin protege a los clientes que necesitan utilizar servicios externos. El
encaminador evita el acceso directo desde Internet a la red corporativa y puede restringir el
trfico entrante al trfico de respuesta al generado por los clientes.

De cara a la utilizacin de servicios externos, esta estructura permite el acceso controlado a los
servicios externos, tanto mediante el acceso filtrado a travs del encaminador, como a travs
de proxies alojados en la subred filtrada.
El filtrado de paquetes permite restringir el acceso directo desde la red interna hacia Internet a
aquellos clientes y a aquellos servicios que establezca la poltica de seguridad corporativa.
Adems, en caso de servicios que deban ser accedidos a travs de un proxy, el filtrado permite
restringir el acceso de los clientes al proxy (en la red perimtrica) y del proxy a los servidores
reales.

Otras consideraciones
Con respecto a la estructura habitual, NETinVM une en una nica mquina (fw) los
encaminadores interno y externo. Esto supone un cierto aumento del riesgo con respecto a
utilizar dos mquinas diferentes, pero teniendo en cuenta que los encaminadores no necesitan
ofrecer servicios y que suelen tener implementaciones especialmente robustas de los protocolos
de red, supone un compromiso razonable entre seguridad, complejidad y recursos a utilizar (cada
mquina virtual extra cuenta).
Por supuesto, es posible realizar otras variaciones, como utilizar ms de una subred filtrada o
segmentar la red corporativa, pero ello complicara el trabajo con NETinVM.

Ejercicio: Preparar el entorno para el resto de

actividades
En esta leccin se aprender a configurar un encaminador con filtrado de paquetes.
Para ello se realizar una configuracin desde cero de fw, que interconecta las redes
externa (ext), interna (int) y perimtrica (dmz). Para ello, durante la prctica se
utilizarn, adems de fw, las mquinas exta, dmza, inta e intb. Se usa una mquina por
red para probar la conectividad y el acceso a los servicios y, en el caso de la red
interna, se usan dos, ya que inta ser la mquina del administrador del servidor web,
mientras que intb es una mquina de la red corporativa sin tareas relacionadas con la
administracin de los sistemas.
Puesto que fw viene en NETinVM ya configurado por defecto, ser necesario restaurar
una copia de seguridad en la que fw arranque sin realizar filtrado de paquetes. El
estado est almacenado en el fichero "uml_machines_2015-07-30_10-31_fw-
configuration.tgz". (La descripcin de cmo hacer copias de seguridad y cmo
restaurarlas est incluida en la demostracin "Copias de seguridad de las UMLs").
Aviso
Al restaurar una copia de seguridad se elimina el estado actual de las UML. Por lo
tanto, se recomienda realizar una copia de seguridad antes.
Acciones a realizar:
1. Comprobar que las mquinas UML estn paradas.
2. Realizar, si no se ha hecho antes, una copia del estado actual y etiquetarlo
adecuadamente renombrando el fichero resultante.
3. Restaurar la copia de seguridad indicada.
4. Editar el guin "uml_run_my_uml.sh" para que solamente se ejecuten las
mquinas indicadas.
5. Lanzar las mquinas UML usando el icono "Run my UMLs".
6. Comprobar que efectivamente se han puesto en marcha las mquinas esperadas.

Ejercicio: Configurar el acceso a fw

Aunque fw viene configurado de fbrica, en este ejercicio se proceder a realizar una
configuracin desde cero, como ejemplo prctico de cmo configurar un encaminador
para filtrar paquetes. A diferencia de los clientes y servidores, en el caso de fw la
mayor parte de la configuracin se aplicar a la cadena FORWARD, ya que es la
mquina que interconecta las redes externa (ext), interna (int) y perimtrica (dmz).
El primer paso, sin embargo, es configurar fw como un nodo que no necesita ofrecer
ningn servicio. Por lo tanto, una buena configuracin de partida sera la del nodo
servidor de la unidad "Ejercicio: Configurar el filtrado de paquetes en el servidor",
pero sin ofrecer servicio SSH. Esta configuracin obliga a utilizar la consola para
administrar fw (algo que no es incmodo en NETinVM, pero que podra serlo en un
caso real), pero mantiene la configuracin de fw ms sencilla.
Aviso: esta copia de fw tiene una lista anticuada de repositorios, por lo que es
necesario ejecutar antes la orden "sh /mnt/tmp/update_apt-get.sh" como "root"
en dmzc. (En caso de haber borrado este fichero, se puede descargar de
nuevo: update_apt-get.sh. Si se descarga en "base", es necesario guardarlo en la
carpeta "/home/user1/uml/mntdirs/tmp/").
Acciones a realizar:
1. Configurar fw con la configuracin planteada.
2. Convertir la configuracin en permanente usando el paquete iptables-
persistent.
3. Usando nmap en exta, dmza e inta, comprobar que fw no ofrece ningn
acceso desde ninguna de las tres redes.
4. Comprobar que s responde a ICMP ECHO REQUEST desde las tres redes.

Ejercicio: Activar el reenvo IP

El siguiente paso ser habilitar el encamiento IP de forma permanente (que siga
habilitada aunque se rearranque el sistema). Para ello, es necesario descomentar la
lnea con "net.ipv4.ip_forward=1" en el fichero "/etc/sysctl.conf".

Si se desea activar temporalmente el reenvo (o si se desea activarlo sin reiniciar el

sistema, despus de haber editado "/etc/systctl.conf") basta con ejecutar "echo 1
>/proc/sys/net/ipv4/ip_forward" o "sysctl net.ipv4.ip_forward=1". La configuracin
actual se puede obtener de forma similar, mediante las rdenes "cat
/proc/sys/net/ipv4/ip_forward" o "sysctl net.ipv4.ip_forward". En ambos casos un
valor 1 indica que est activo y un valor 0 indica que no.

Acciones a realizar:
1. Editar el fichero "/etc/sysctl.conf" tal y como se ha indicado.
2. Rearrancar fw.
3. Comprobar que el reenvo IP est activo.

Ejercicio: Permitir el acceso desde la red interna a la red

externa
A continuacin ser necesario configurar la cadena FORWARD para que permita el
trfico de las redes corporativas (int y dmz) entre s y con el resto del mundo (ext,
Internet). En este caso se desea ocultar la estructura interna de la red corporativa, por
lo que tambin ser necesario configurar fw para que traduzca las direcciones de
origen usando SNAT.
Sin embargo, el primer paso ser configurar el acceso desde la red interna a la red
externa y al resto del mundo. Suponiendo, para simplificar, que no se desea restringir
demasiado este acceso, se debe permitir el siguiente trfico a travs de la cadena
FORWARD:

Todo el trfico de conexiones establecidas o relacionadas para los protocolos

TCP, UDP e ICMP.
Todo el trfico que entre en fw a travs de la interfaz eth2 (la interna), con
protocolo TCP, UDP o ICMP, con direcciones IP de origen en el rango
10.5.2.0/24, y que vaya a salir a travs de la interfaz eth0 (la de la red externa).

Para comprobar el funcionamiento y aprender lo mximo posible, se recomienda tener

en marcha durante todo el proceso el analizador de trfico wireshark en base,
capturando el trfico de las interfaces tap0, tap1 y tap2.
Acciones a realizar:
1. (Recomendado). Poner en marcha wireshark en base capturando el trfico
de tap0, tap1 y tap2.
2. (Recomendado). Probar a lanzar un ICMP ECHO REQUEST desde inta con
destino a exta y comprobar que el paquete llega a fw y no lo atraviesa.
3. Aadir las reglas de filtrado apropiadas segn la configuracin anterior. (No se
debe alterar el filtrado de las cadenas INPUT y OUTPUT).
4. Comprobar la conectividad de inta con exta usando ICMP ECHO REQUEST.
5. (Recomendado). Usando wireshark, identificar los paquetes intercambiados.
6. Comprobar la conectividad de inta con exta usando SSH.
7. Guardar las reglas en "/etc/iptables/rules".

Ejercicio: Configurar SNAT

A continuacin, se aadir SNAT, que es conveniente para ocultar la estructura interna
de las redes corporativas; pero, adems, en este caso, tambin es necesario para que
los paquetes que salgan de NETinVM a travs de base vuelvan a travs de fw. La
configuracin de SNAT debe cumplir los siguientes requisitos:
Todos los paquetes que abandonen fw por la interfaz eth0 (la que est conectada
a la red ext) y que provengan de la red interna (10.5.2.0/24) deben cambiar su IP
de origen para que sea la de fw en esa interfaz (10.5.0.254).
Puesto que la IP 10.5.0.254 es fija, es conveniente usar SNAT y no
MASQUERADE. El motivo es que as es ms eficiente, ya que
MASQUERADE debe consultar la IP de la interfaz cada vez que procesa un
paquete.

Acciones a realizar:
 1. Aadir las reglas de filtrado apropiadas segn la configuracin anterior.
(Ntese que en este caso se tiene que trabajar con la cadena POSTROUTING de
la tabla "nat").
2. Comprobar la conectividad de inta con exta usando ICMP ECHO REQUEST.
3. (Recomendado). Usando wireshark, identificar los paquetes intercambiados,
comprobando que la IP de origen del paquete que llega a exta es la de la interfaz
externa de fw.
4. Comprobar la conectividad de inta con exta usando SSH.
5. Comprobar la conectividad de inta con el exterior (si el ordenador anfitrin
tiene conectividad). (Sugerencia: probar con un "ping -c 1").
6. Guardar las reglas en "/etc/iptables/rules".

Ejercicio: Permitir el acceso a la red perimtrica

Finalmente, ser necesario agregar reglas para permitir el acceso desde y hacia la red
perimtrica. En particular, es necesario tener en cuenta las siguientes consideraciones:

Los nodos de esta red actan como nodos bastin y debe limitarse el acceso a
ellos tanto desde Internet como desde la red interna. Ser necesario permitir el
acceso a los servicios que ofrecen y, en su caso, permitir el acceso desde las
mquinas de la red interna que tengan tareas administrativas.
Estos nodos estn necesariamente expuestos a ataques desde Internet (pues
tienen que ofrecer servicios), por lo que es necesario proteger a los nodos de la
red interna de cualquier tipo de acceso no deseado desde los nodos bastin. De
esta forma, en caso de que un nodo bastin sea comprometido, se podr detectar
y tratar el incidente antes de que afecte a la red corporativa.

Por este motivo se modificar la configuracin de fw para que permita los siguientes
tipos de acceso:
Acceso TCP desde cualquier mquina (interna o externa) a la mquina dmza (IP
10.5.1.10, alias www.example.net), exclusivamente al servicio HTTP (puerto 80).
Acceso SSH desde inta.example.net (10.5.2.10) a dmza.

Acciones a realizar:
1. Aadir las reglas necesarias para completar la configuracin de fw.
2. Comprobar que es posible acceder al servicio HTTP tanto desde la red interna
como desde la externa.
3. Comprobar, con nmap, que no es posible acceder a ningn puerto ms (en la
red interna, probarlo tambin desde intb, pues desde inta est permitido el
acceso SSH).
4. Comprobar que es posible conectarse por SSH desde inta.
5. Comprobar que desde dmza no es posible acceder a ningn puerto ni de inta ni
de intb.
6. Guardar las reglas en "/etc/iptables/rules".