MDULO 3.

SEGURIDAD PREVENTIVA
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.

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.

Presentacin: Endurecimiento de sistemas

(system hardening)

Video

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.

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.

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 "tail -f
/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 "ssh-copy-id -i
/home/user1/.ssh/id_rsa.pub dmzc". 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".

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".