Beruflich Dokumente
Kultur Dokumente
Herramientas de
Gestión de la
Seguridad de Redes
Curso 2014/15
Resumen de la asignatura
para http://apuntrix.com
Índice
1. Descripción del problema de Seguridad en redes. Tipos de ataques 1
1.1. Introducción, orientaciones para el estudio y objetivos . . . . . . . . . . . . . . . . 1
1.2. Unas cuantas preguntas que ayudan a definir mejor el problema . . . . . . . . . . 1
1.3. Soluciones “perfectas” y soluciones razonables. . . . . . . . . . . . . . . . . . . . . 3
1
Se tienen que conocer dos temas complejos:
1. Los distintos tipos de ataques posibles.
4. Sistemas criptográficos. Son sistemas que permiten, de varias formas distintas, mantener
la integridad y la autenticación de mensajes o datos, así como la privacidad o confidencia-
lidad de los mismos.
5. Sistemas antivirus. Son aplicaciones locales o distribuidas que permiten defenderse de los
virus informáticos.
6. Sistemas de análisis de vulnerabilidades. Son aplicaciones que permiten buscar en siste-
mas y aplicaciones instalados bugs o vulnerabilidades conocidas.
7. Sistemas de detección de intrusiones. Son sistemas o aplicaciones que permiten, en tiem-
po real, detectar determinados tipos de ataques y alertar sobre ellos.
8. Estándares para sistemas de gestión de seguridad. Como el ISO/IEC 27001, que permite
organizar los procesos y procedimientos de gestión de la seguridad de cualquier organiza-
ción.
La seguridad en las redes puede ser más o menos completa, pero siempre tiene un componente
económico. Se debe tener en cuenta el dinero (o recursos de todo tipo) que van a ser empleados
en cada una de las siguientes tareas:
Adquisición de herramientas hardware y software.
2
El tiempo empleado en la administración, mantenimiento y reconfiguración para permitir
nuevos servicios, auditar las herramientas, etc.
El tiempo empleado en poner en marcha un sistema de gestión de seguridad.
Una serie de sentencias formales (normas) que deben cumplir todas las personas
que tengan acceso a cualquier información y/o tecnología de una organización.
Una buena política de seguridad debe cumplir una serie de normas generales, de sentido común:
1. Debe poderse implantar. Se deben tener unas normas de comportamiento para los usua-
rios y administradores, unas “políticas de uso aceptable”.
2. Debe entenderse. Debería de explicarse a todo el personal de la organización el alcance de
no cumplirla.
3. Debe cumplirse. Debe contemplar una serie de procedimientos de auditoría y de sanciones
adecuadas a cada una de las posibles infracciones. Debe estar respaldada completamente
por la dirección de la organización.
4. Debe definir responsabilidades. No puede ser igual el papel de un usuario que el de un
administrador.
5. Debe permitir que siga realizándose el trabajo normal. Debe ofrecerse seguridad, pero
no al precio de que no funcione la organización.
6. Debe ser exhaustiva. Debe tener en cuenta todos los componentes del sistema.
7. Debe incluir mecanismos de respuesta. Habrá que tener en cuenta qué se debe hacer al
sufrir un ataque, cómo pararlo, cómo identificar al atacante y cómo responder al ataque.
8. Debe tener mecanismos de actualización. Esto es, simplemente, por el principio enuncia-
do de que la seguridad es un proceso.
3
2. La seguridad en los elementos físicos existentes en una red
2.1. Introducción
Todas las redes están compuestas por una serie de dispositivos físicos, máquinas, que tienen
una mayor o menor capacidad de control pero que no dejan de ser máquinas. Son las piezas
básicas del sistema. Se comunican entre sí utilizando uno o varios medios de transmisión, ha-
bitualmente cables o mediante sistemas inalámbricos.
Tanto los medios de transmisión como las máquinas son susceptibles de ataques contra su
seguridad, desde dos puntos de vista:
Ataques físicos, en los que se busca la destrucción parcial o total del dispositivo concreto.
Ataques “lógicos” en los que, buscando los mismos objetivos que los anteriores, no se
dispone de un acceso físico al dispositivo.
Centrándose en los ataques lógicos, primero hay que identificar los elementos que se tienen que
considerar:
Canales de comunicación y cableados típicos.
Repetidores.
Hubs o concentradores.
Conmutadores.
Encaminadores.
4
2.3. Repetidores, hubs y conmutadores (o switches)
Un repetidor no es más que un amplificador de la señal, con dos puertos. Sólo implementa
funciones del nivel 1 de OSI. Es difícilmente atacable por no tener nada realmente configurable.
Los hubs son repetidores multipuerto que soportan cables de par trenzado en una topología
en estrella. Cada nodo se comunica con el hub, que a su vez amplifica la señal y la transmite por
cada uno de los puertos. Los hubs funcionan de nuevo en el nivel 1 de OSI, y son especialmente
susceptibles a ataques de tipo monitorización mediante sniffers.
Los conmutadores o switches implementan hasta el nivel 2 de OSI por lo menos, aunque
existen también los “conmutadores de nivel 3”, cuyas funcionalidades coinciden con las de los
enrutadores: son capaces de aprender las direcciones MAC de cada nodo conectado a cada uno
de sus puertos, crear una tabla de direcciones y gestionar el tráfico con respecto a ella, evitando
así los ataques de tipo monitorización con sniffers.
Otra técnica típica de los conmutadores es la de permitir el establecimiento de las redes de
área local virtuales o VLANs. Las VLANs son grupos de ordenadores relacionados lógicamente
entre sí por un número de grupo (número de VLAN) y configurados por el administrador del
conmutador. Concretamente, se configuran los puertos de cada conmutador, asociándolos a una
o más VLANs. Esto conduce a una mayor segmentación lógica de los equipos.
Siempre que hay más posibilidades de configuración, hay más posibilidades de ataques.
Existen 2 métodos para acceder al conmutador para administrarlo:
1. A través de la consola, una conexión local y directa al conmutador.
2. Remotamente, ya sea por telnet, ssh o http.
2.4. Encaminadores
Los encaminadores o routers son dispositivos de red que no sólo incorporan la función de
filtrado, sino que también determinan la ruta hacia el destino de cada mensaje, es decir, hacen
una selección del camino óptimo, empleándose tanto en redes de área local como de área extensa.
Implementan, al menos, los niveles 1, 2 y 3 de OSI, pero suelen implementarlos todos y así
permitir todos los medios de acceso a su configuración.
Actúan sobre los paquetes transferidos entre los niveles de red (nivel de direcciones IP) de
las estaciones, a diferencia de los conmutadores que lo hace sobre las tramas al nivel de enlace
de datos (nivel de direcciones MAC).
Su funcionamiento se basa en la utilización de un esquema de direccionamiento jerárquico
y lógico que distingue la dirección de un dispositivo dentro de la red y la dirección de la red.
Con ese reconocimiento, el encaminador es capaz de construir tablas de rutas, que le ayudarán
a decidir por qué camino envía el mensaje.
Un encaminador es susceptible de sufrir distintos tipos de ataques:
1. Ataques de denegación de servicio, sin necesidad de acceso.
2. Ataques de acceso para modificación de información, casi siempre de las tablas de rutas.
5
2.5. Los servidores y otras máquinas
El resto de las máquinas de una red suelen ser:
Máquinas de uso final de un usuario.
Dispositivos móviles como teléfonos inteligentes.
6
3. La seguridad en los elementos software existentes en una red
3.1. Introducción
Lo que se suele llamar seguridad del software incluye aspectos tan diversos como el control
autorizado del acceso, la gestión de cuentas y de privilegios de usuario, la protección de ficheros,
la protección frente a virus, el diseño seguro del software, la seguridad de las bases de datos. . .
Las primeras investigaciones tenían que ver con el acceso privado a sistemas compartidos:
si una buena cantidad de usuarios comparten un sistema, ¿cómo se puede obligar a que se
cumplan determinadas reglas de acceso?
Esta pregunta sigue siendo válida hoy en día, pero hay más:
¿Cómo se puede mantener una base de datos en la que diferentes usuarios tienen diferentes
privilegios de acceso?
¿Cómo se puede asegurar que las aplicaciones que se utilizan son correctas y que no han
sido modificadas?
¿Se puede estar seguro de que los datos no han sido modificados?
¿Puede fácilmente una compañía hacer cumplir una determinada política de licencias para
su software?
Para poder hablar de control de acceso conviene definir una serie de términos. Casi todo se basa
en un sujeto, que tiene acceso a un objeto. El sujeto suele ser un usuario y el objeto un fichero,
pero no necesariamente. El sujeto podría ser un proceso informático y el objeto otro proceso
informático.
Se puede definir el control de acceso de dos maneras distintas:
1. ¿Qué puede hacer cada uno de los diferentes sujetos?
2. ¿Qué puede hacerse sobre los diferentes objetos?
Tradicionalmente, los sistemas operativos simplemente administraban ficheros y recursos, así
que se definía el control en función de ellos.
Además, el acceso no es nunca del tipo “todo o nada”. Por ejemplo UNIX tiene tres tipos de
permiso de acceso diferente: read, write y execute.
Los mismos conceptos de seguridad de los que se habla para sistemas valen para las aplica-
ciones. Además, se ha de tener en cuenta la modularidad del software.
Por otro lado, se suele definir cualquier protocolo como:
Un conjunto de mensajes de comunicación entre dos entidades, que suelen ser procesos en
diferentes sistemas.
Una serie de normas para el intercambio de esos mensajes.
Hoy en día puede uno fijarse especialmente en los protocolos de la familia IP, que son responsa-
bles de más del 90 % del tráfico de mensajes general de todas las redes. Tal familia no fue creada
teniendo muy en cuenta la seguridad. No obstante se ha mejorado bastante, y se puede decir
que se dispone de herramientas para configurar una red bastante segura, a la vez que funcional
y útil, con IP.
7
Ficheros (u otras estructuras de datos) de gestión del sistema, como el fichero de usuarios
de UNIX, /etc/passwd, o el fichero de autorización de usuarios de Windows NT, el SAM.
Cualquiera de estas partes del sistema operativo interactúa con una cuarta entidad, que es el
subsistema de seguridad. Habitualmente, todos estos subsistemas utilizan una serie de concep-
tos:
Monitor de referencia. La parte del software que controla todos los accesos a objetos por
parte de los sujetos.
Trusted Computing Base. Todos los mecanismos de protección interna –hardware, firmware,
partes del sistema operativo, etc.– que son responsables de que se cumpla la política de
seguridad.
Kernel seguro. Toda la parte del kernel que implemente el concepto de monitor de referen-
cia.
Hay una gran cantidad de código, que podría estar fuera del kernel, que está dentro del mismo.
En el caso de los sistemas operativos se trata de que exhiban una buena administración. Esto
suele significar al menos tres cosas:
1. Tratar de trabajar con sistemas operativos que tengan una certificación de seguridad.
Cualquier sistema operativo debe estar configurado, desde el punto de vista de la seguridad,
con al menos las siguientes características:
Una buena política de copias de seguridad de los datos, incluyendo si las hay, bases de
datos.
Una buena política de gestión de cuentas de usuario, de la que se hablará más en los temas
5 y 6.
Una buena política de gestión del sistema de ficheros, eligiendo un sistema de ficheros
que permita el control de acceso más granular posible. Por ejemplo control de acceso por
grupos y control de acceso por usuario.
Integridad de los ficheros. Hay que intentar asegurar que todos los ficheros no sufran
cambios que no sean los deseados.
Una buena gestión de los ficheros de log. Deben estar bien configurados y, sobre todo, hay
que leerlos, automáticamente o manualmente.
Hay que estar bien preparados contra las amenazas previsibles: puertas traseras, bombas
lógicas, virus, gusanos, etc.
Hay que tener una buena política de seguridad física.
El caso de los teléfonos móviles es un claro ejemplo de los problemas que implica el uso
de software o sistemas cada vez más complejos. Con el incremento de las funcionalidades de
dichos terminales ha sido necesario dotarlos de sistemas operativos complejos, lo que ha hecho
que estos dispositivos móviles pasen a tener ahora los mismos problemas de seguridad que los
equipos “tradicionales”.
Esta misma reflexión es aplicable a los sistemas operativos de conmutadores, encaminadores,
puntos de acceso y demás dispositivos de red. Al incrementar las posibilidades de configura-
ción y de servicios ofrecidos por estos dispositivos sus sistemas operativos son cada vez más
complejos y por tanto pueden presentar nuevos riesgos de seguridad.
Es responsabilidad de los sistemas operativos el controlar el acceso que hacen las aplicaciones
a los recursos, es necesario usar software que garantice en la medida de lo posible que el uso
8
que hacen de los recursos a los que tienen acceso es el esperado y no utilicen dichos recursos de
forma inadecuada.
Finalmente, no hay que olvidar el factor decisivo: el factor humano. Un término, Peopleware,
expresa informadamente y con cierta dosis de humor, la necesidad de que el personal de gestión
de los sistemas esté cuidadosamente elegido y sea formado y “re-formado”.
9
3. Cuando el mensaje anterior llega al cliente, el proceso cliente crea su sesión en su propia
tabla de sesiones y contesta con un tercer mensaje, en el que las direcciones y los números
de puerto coinciden con los del mensaje primero, el bit de SYN está deshabilitado, el bit
de ACK está habilitado, el NSEC-1 tendrá el valor de NSEC-1 − previo más el número de
bytes de este mensaje y el NACK-1 tendrá un valor de NSEC-2 +1.
Este comportamiento, 3-step handshake, una especie de saludo entre máquinas, es el de una
“máquina de elementos finitos”. Es predecible y esto será bueno para una defensa inteligente.
Todos los mensajes generados por aplicaciones con transporte UDP comparten una cabecera
de UDP muy pobre para la seguridad. La cabecera UDP sólo tiene 2 campos relevantes: los dos
números de puerto. Tan poca información traerá problemas graves.
Por otro lado, los mensajes de protocolos de nivel de red (ICMP, OSPF, . . . ) comparten sólo
la cabecera IP. Aquí, la aproximación a la seguridad pasa por el conocimiento de cada protocolo,
de su cabecera y de su funcionamiento.
Finalmente, se llega a las aplicaciones con información de transporte. Para estar al tanto de
todas las inseguridades, habría que conocerlas bien todas, pero conviene tener en cuenta una
serie de datos generales:
IP no fue diseñado para proporcionar seguridad, sino para transportar mensajes. En su
diseño no hay nada sobre cómo autenticar sistemas o cómo enviar mensajes secretos (crip-
tográficos).
Hay una serie de ataques, basados en particularidades de los protocolos, y que se cono-
cen desde hace bastante tiempo. Por ejemplo, los relacionados con sniffers, los ataques de
suplantación (spoofing) de direcciones IP, el secuestro de sesiones Telnet, etc.
La mayor parte de los virus y gusanos que se propagan por la red, lo hacen en forma de
partes de mensajes de correo (SMTP).
El soporte de nuevas aplicaciones, alrededor del audio y del vídeo en tiempo real y de la
cantidad necesaria de la transmisión.
Nuevas capacidades que hagan posible una comunicación mucho más segura.
Con respecto a este último punto, se desarrollaron una serie de protocolos que se conocen con
el nombre de IPSec. Las necesidades del comercio electrónico, y muy en particular la necesidad
de la creación de Redes Privadas Virtuales seguras, provocaron que se portara IPSec a IPv4. Las
condiciones de diseño de IPSec fueron:
Que las funciones de seguridad no deben afectar a la red existente o a las operaciones de
Internet.
Que se pudieran encriptar todos los mensajes, excepto los necesarios para el encamina-
miento.
Que se proporcione autentificación de máquinas origen y destino.
Que se mantenga flexible el proceso técnico de asignación de claves, por razones de segu-
ridad criptográfica.
Que los algoritmos matemáticos utilizados fueran de la criptografía estándar.
10
Que no se cerrara la elección de tales algoritmos, para poder añadir cualquier otro en el
que se pusiera de acuerdo la comunidad.
Tales protocolos son:
11
Los niveles de seguridad evaluada (Evaluation Assurance Levels). Definen una escala de
medición de los criterios de evaluación de PPs y STs. Estos niveles son 7, desde EAL1 a
EAL7.
Los EALs se han desarrollado con el objetivo, entre otros, de preservar los conceptos de
seguridad usados para desarrollos previos como TCSEC.
Los Common Criteria no son el único estándar de seguridad utilizado hoy en día. Otro de los más
reconocidos internacionalmente es el ISO/IEC 27001 que se estudiará en el tema 6. Esta norma
establece los criterios de seguridad que debe seguir un SGSI (Sistema de Gestión de la Seguridad
de la Información).
12
4. Métodos de ataque a equipos y redes
4.1. Introducción
Los ataques dirigidos a los dispositivos de red están realizados por personas. Se puede decir
que donde hay dinero, hay criminales, con lo que asuntos como el sabotaje remoto al control de
cajeros automáticos o la pornografía infantil, pasan a ser perfectamente factibles también en las
redes.
El ciberespacio cambia las formas de los ataques y, como consecuencia, se deben adecuar las
formas de las defensas. La red Internet tiene varias características que hacen que los ataques
puedan ser mucho peores en cierto sentido, que son::
El aspecto automático de los ataques. Los ordenadores son potentes en las tareas repetiti-
vas. Se puede dejar una máquina tratando de descifrar contraseñas de manera automática.
El aspecto remoto de los ataques. Es casi tan fácil conectarse a un ordenador en París desde
Madrid que desde Tokio. Los aspectos legales de todo esto no están aún controlados.
La velocidad de propagación de los ataques. Cualquier atacante puede conseguir muchas
de las herramientas de ataque que necesitará.
El objetivo de este tema es presentar al lector los distintos tipos de ataques dirigidos a dispositi-
vos de red, analizándolos desde el punto de vista del atacante profesional. Tal atacante necesitará
de ciertas herramientas, las cuales se dirigen siempre a alguna de las siguientes actividades:
Obtención de información sobre los equipos y redes que se pretende atacar.
Acceso no autorizado a información con intención de verla, eliminarla, cambiarla o una
combinación de alguna de tales actividades.
Denegación de servicio, sea de la red, del acceso a Internet, de un servidor, etc.
El objetivo del tema es que el lector entienda los riesgos a los que se enfrentan los responsables
de seguridad de sistemas informáticos y redes.
Internos. Es obvio que estar dentro de la organización facilita mucho el ataque. Puede
haber ataques profesionales internos, pero también por mala aplicación de la política de
seguridad. ataques no maliciosos de usuarios internos que, simplemente, prueban herra-
mientas con toda su buena intención.
13
Otro criterio, verdaderamente relevante, tiene que ver con la personalidad del atacante. De estos
atacantes se habla más adelante en torno a la Ingeniería Social, verdadera disciplina en la que
están basados algunos de los casos de ataques más espectaculares. Se demuestra que no tiene
sentido invertir millones de euros en una gran infraestructura de seguridad si no se ha tenido
en cuenta la formación y entrenamiento del personal de la empresa.
Si se catalogan por el objetivo que persiguen así como por el tipo de técnicas utilizadas, se
puede hablar de los siguientes tipos de ataques:
Ataques encaminados a la obtención de información sobre los objetivos a atacar.
Ingeniería social.
Herramientas informáticas para la obtención de información sobre hosts de red.
Uso de escuchadores de paquetes o sniffers.
Análisis de metadatos.
14
4.3.2. Herramientas informáticas
Otra técnica es el uso de comandos y herramientas informáticas para la obtención de la
información.
Por ejemplo, el comando ping permite obtener la información de qué direcciones IP tienen
las máquinas de red a la que se quiere atacar. Hacer ping a la dirección de broadcast de la red
permite obtener información de qué direcciones IP se están usando en una red y cuáles no.
Otro comando muy utilizado es nslookup. Gracias a este comando se pueden obtener las
direcciones IP públicas asociadas a un dominio en Internet.
Una vez se conocen las direcciones IP, el atacante puede utilizar una herramienta de tipo port
scanner. Una vez elegida una dirección IP, permite ver qué aplicaciones o servicios están activos
en la máquina, a base de tratar de crear sesiones TCP o de enviar mensajes sencillos UDP.
Otro tipo de herramientas que se puede utilizar son los analizadores de vulnerabilidades.
Permiten identificar posibles vulnerabilidades en los servicios abiertos, así como en el sistema
operativo de la máquina objetivo. Para ello testean los servicios encontrados contra una base de
datos de vulnerabilidades conocidas.
Otras técnicas del mismo estilo consisten en aprovechar comandos como el finger de UNIX,
que da información de los usuarios de un sistema o como primitivas de algunas aplicaciones IP.
15
Obtención de información por aplicaciones de compartición de disco.
Obtención de información por mala configuración de protocolos mal autenticados.
Mala administración en los filtros de paquetes, lo que da lugar a posibles ataques de tipo
suplantación o spoofing.
La gente tiende a usar contraseñas fáciles de recordar. Si se obliga a tener contraseñas difíciles
de recordar, es muy probable que el usuario la escriba en algún sitio. Además, las contraseñas
se almacenan en ficheros en el sistema encriptadas. Las contraseñas de las cuentas de usuario
usan uno u otro método de una sola vía, de manera que el resultado de aplicar el algoritmo de
encriptación (hash) no sirve para, aplicando un supuesto algoritmo inverso, obtener el original.
Dependiendo de la seguridad del sistema operativo, tal información puede estar disponible al
atacante. Una vez se dispone de esa información, sólo hay que aplicar un programa cracker, que
lo que hace es aplicar el algoritmo de hash a toda una lista de palabras y comparar el resultado
con el hash del que se dispone para cada cuenta de usuario.
Cuando se habla de relaciones de confianza mal administradas, se está haciendo referencia a
los comandos remotos de Berkeley, que permiten ejecutar remotamente comandos en sistemas.
En este caso, un sistema A, que confía en un sistema B, permite que un usuario del sistema B,
con un nombre de cuenta común ejecute cualquier cosa, bajo esa cuenta de usuario, en el sistema
A. La confianza se basa en las direcciones IP de los equipos.
Hay dos puntos que suelen hacer la situación más grave: lo normal es que también B confíe
en A, y suele pasar que una de las cuentas para las que esto funcione sea la del administrador
del sistema. La razón de estas configuraciones es sencilla: la comodidad de trabajar de sistema a
sistema, sin el engorro de las contraseñas.
Hay más relaciones de confianza que pueden ser utilizadas, como las zonas wi-fi abiertas.
Este sistema de funcionamiento de conexión automática que simplifica enormemente el uso de
redes inalámbricas, es a su vez un punto de vulnerabilidad. Un atacante puede establecer un
punto de acceso que suplante la identidad de un punto de acceso abierto. Esta técnica de ataque
es conocida como Rogue AP y se puede englobar también dentro de los ataques de tipo Man-in-
the-Middle.
Si se trabaja en una red con sistemas UNIX, es típico disponer de servidores NFS (Network
File System). Esta configuración mal administrada puede resultar muy peligrosa. Suele haber,
típicamente, dos problemas graves:
Hay una configuración por defecto que hace que una vez elegidos los directorios a servir
por la red, se exporten con permisos de lectura y escritura.
Si el administrador no se toma en serio los posibles problemas, puede permitir que el
administrador del cliente trabaje en su sistema, también, como administrador.
En el entorno Windows de compartición de directorios, aparecen los mismos problemas que en
el caso anterior.
Otra vía de entrada a sistemas y redes es a través de protocolos con una mala administración
de su autenticación. Quizás el caso más extendido sea el del protocolo SNTP (Simple Network
Management Protocol). Este protocolo es el encargado de la gestión remota de dispositivos en
red tiene varias versiones. En las más antiguas, el mecanismo de autenticación es un community
string que se transmite sin encriptar y que suele ser el valor por defecto, public, haciendo a todo
el mundo más fácil el acceso al dispositivo objetivo.
Otro caso típico es el de las organizaciones, habitualmente grandes, que administran toda la
información de encaminamiento de su red mediante protocolos como OSPF (open Shortest Path
First) o EIGRP (Enhanced IGRP), que disponen de un mecanismo de autenticación que hace que
los mensajes de actualización de rutas, enviados entre los distintos encaminadores, se hagan con
tal información de autenticación, que además suele ir encriptada. Si los dispositivos no están
configurados, cualquier encaminador se cree cualquier mensaje de actualización de cualquier
otro encaminador del mismo protocolo, haciendo muy sencillo colocar uno falso en medio.
Llegados a este punto, hay que definir lo que se entiende por spoofing: pretender ser “algo”
o “alguien” que no se es. El caso más extendido es el conocido como IP Spoofing, en el cual una
máquina “suplanta” la dirección IP de otra. La máquina a la que se suplanta tiene disponible
accesos (o relaciones de confianza) que están vetados para el atacante. Tales ataques suelen tener
tres objetivos:
16
Como parte de un ataque en el que, además, se dispone de un medio (sniffer) para obtener
todo el mensaje de vuelta del equipo atacado, con la obvia intención de hacerse con toda
la información.
¿Cómo triunfan tales ataques? En muchos casos, por la mala administración de los encamina-
dores intermedios. Es muy sencillo parar muchos de ellos sin más que colocar filtros en los
encaminadores, consistentes en no permitir que ningún usuario envíe mensajes con una direc-
ción IP fuente que no esté en el rango de direcciones de la red interna.
Otra suplantación que se puede encontrar es la de DNS, de la que se hablará en el siguiente
apartado.
17
4.6. Ataques basados en vulnerabilidades de software
Son ataques que se aprovechan de que las características de uso de algunas aplicaciones, el
para qué están diseñadas, se convierten en vulnerabilidades.
Es el caso de las macros de arranque de algunas aplicaciones, que permiten realizar modifi-
caciones de ficheros y/o modificar la propia aplicación, como en Microsoft Word.
El lenguaje de programación Postscript tiene una serie de primitivas que permiten que, al
arrancar el visor de documentos, se busquen ficheros para modificarlos o borrarlos.
Los applets de ActiveX se pueden descargar en el ordenador de un cliente de forma que, al
ejecutarse, realicen tareas no deseadas.
Se podría llamar efecto autoplay a este conjunto de situaciones, recordando quizás la más
tonta de todas: la característica de poder arrancar, automáticamente, una aplicación residente en
un CD o pendrive nada más introducirlo en su lector.
Hay que comentar el asunto de las cookies. Sirven para realizar tareas muy útiles, pero tam-
bién para otras no demasiado correctas. Se conocen por ejemplo los casos de cookies usados para
perseguir a los usuarios de sitio en sitio de la red, para hacerse un perfil de su “personalidad” y
también para descubrir la identidad de un usuario concreto.
Se han de abordar ahora las vulnerabilidades provocadas por una mala implementación
de protocolos y aplicaciones. La más conocida, denominada buffer overflow, puede provocar
ataques de dos tipos:
Ataques de tipo denegación de servicio, tratados más adelante en este tema.
Ataques para obtener acceso a un sistema.
Estos últimos tienen que ver con variables del programa, que no se han chequeado correctamen-
te, ni su longitud ni su tipo de datos. El atacante coloca una secuencia de bytes mayor que el
espacio de memoria reservado para la variable, sobrescribiendo en las siguientes posiciones de
memoria. En tales posiciones están los valores de punteros a la pila que indican por qué parte
del programa hay que continuar la ejecución. El atacante puede redirigir el programa para que
ejecute las instrucciones embebidas, previamente, en los datos de entrada.
Otro tipo de ataques son las inyecciones de código SQL o SQL Injections. Son especialmente
utilizados para atacar aplicaciones web. El atacante trata de aprovechar los parámetros de entra-
da de la aplicación para modificar la consulta SQL que la aplicación hace sobre la base de datos
subyacente y así tratar de obtener acceso a la aplicación o extraer datos de la misma a los que
supuestamente no debe tener acceso.
Bajo este mismo criterio de ataques por vulnerabilidades de software entrarían los problemas
debidos a las llamadas puertas falsas o backdoors. Son parte del código de una aplicación sólo
conocido por sus fabricantes. Esto permite que haya opciones del software sólo conocidas para
quien lo ha construido. Habitualmente, es imposible reconocer este tipo de ataques.
Hoy en día, con el movimiento del free software, los usuarios de sistemas como Linux o
FreeBSD sí disponen del código fuente de sus sistemas y aplicaciones, pero aún así hay que
remarcar dos aspectos importantes:
La mayor parte del software que se utiliza no está incluido en ese movimiento.
Incluso en el caso del resto del software es difícil asegurar que no existen tales puertas,
hasta que alguien las detecta.
18
Ataques DOS distribuidos o DDOS.
Una vez más, hay que referirse a la poca importancia dada a la seguridad en el diseño de
muchos protocolos. En este sentido, se puede hablar por ejemplo de los ping floods, consistentes
en enviar muchos más mensajes ICMP de los que el host destino puede gestionar normalmente.
Otro ataque típico de este estilo es el causado por aplicaciones de tipo smurf , en el que se
envían pings a la dirección de broadcast de la red donde reside la víctima, habiendo colocado
como dirección IP fuente del envío la del equipo que se quiere atacar. Esto provoca que todo
el resto de equipos de la red colaboren, inocentemente, en sobrecargar la tarjeta de red de la
víctima.
Otra forma de aprovecharse de cómo funciona IP es empleando ataques de tipo teardrop, en
los que se envían fragmentos IP con longitudes y desplazamientos desde el inicio del mensaje
que se solapan, provocando un gran uso de recursos (en vano) para tratar de arreglar tales
fragmentos.
Otro tipo de ataque DOS muy extendido es el de los SYNfloods. Para entenderlos correc-
tamente, hay que recordar el mecanismo de 3 step handshake, en el que por cada petición de
conexión del cliente a un servidor éste crea una entrada en la tabla de sesiones semi-establecidas
de TCP. Solo cuando le llega al servidor un mensaje de aceptación del cliente, se borra la entrada.
Si a eso se le suma que tales entradas tienen un tiempo de vida relativamente grande y que la
tabla tiene una longitud, en general, bastante corta, se entenderá el ataque. Habitualmente basta
con enviar enviar 10 paquetes de tipo SYN cada dos minutos a un servicio en la víctima para
bloquear el servicio.
Finalmente existen lo que se conoce como ataques DOS distribuidos, que se tratan de ata-
ques DOS como los ya citados pero que no tienen una única fuente del ataque, sino cientos o
miles.
Virus. Por este término se conoce a aquél código malicioso que se pega o adjunta a otro
archivo. Para que la máquina se infecte es necesario que el usuario ejecute el archivo infec-
tado, por tanto es necesaria la intervención del usuario para su propagación.
Gusanos (worms). Este tipo de software malicioso tiene la peculiaridad de que es capaz
de replicarse a sí mismo. Una vez que un gusano infecta un sistema se extenderá a otros
equipos conectados a la misma red. No se necesita la intervención del usuario para su
propagación.
Troyanos. Son programas aparentemente útiles para el usuario pero que en realidad rea-
lizan una función completamente distinta. Pueden ser destructivos o no destructivos. En
este último caso, se han observado dos tipos de comportamiento:
• Programas con capacidad para buscar y obtener por sí solos información relevante
almacenada en ficheros.
• Programas que abren puertas, creando puertos de servidor de Telnet o ssh al que
conectarse en remoto, o que hibernan. Este tipo de troyanos son los que convierten a
la máquina infectada en un zombi o bot.
Spyware o software espía. Este último tipo de software malicioso cuando infecta un siste-
ma lo que hace es guardar información sobre la actividad del usuario sin que este lo sepa.
La información que registran dependerá de su objetivo.
19
4.9. Ataques a dispositivos móviles
Hasta hace unos años los dispositivos móviles eran prácticamente inatacables, su software
era sencillo y sin prácticamente funcionalidad. La nueva generación de teléfonos inteligentes
incorporan sistemas operativos que les proporcionan gran funcionalidad. Este software cada vez
más complejo, unido a la conexión permanente de dichos terminales a Internet y al hecho de que
los terminales pueden contener información deseable para los atacantes, hace de los dispositivos
móviles un objetivo cada vez más apetecible para los atacantes.
Las técnicas utilizadas para atacar dispositivos móviles son las mismas que las utilizadas para
atacar cualquier otro tipo de dispositivo. El hecho de que estos dispositivos estén gran parte del
tiempo fuera de la organización hace que sean más vulnerables a los ataques. Algunas de las
técnicas de ataque más utilizadas son:
Falsas aplicaciones de redes sociales. Troyanos que pretenden obtener las credenciales de
acceso.
Aplicaciones que contienen código malicioso. Las aplicaciones que se pueden instalar en
este tipo de terminales pueden contener otros tipos de software malicioso.
Mucho software malicioso creado para dispositivos móviles utiliza el hecho de que nor-
malmente los usuarios no leen los permisos que garantizan a las aplicaciones.
Otro de los métodos de ataque favoritos es a través de redes inalámbricas abiertas. En este
tipo de redes la información viaja sin cifrar, por lo que un atacante puede estar escuchando
el tráfico que viaja por una red de este tipo y obtener así múltiples usuarios y contraseñas.
20
5. Defensas básicas ante ataques
5.1. Introducción
Se puede caracterizar la seguridad física de los sistemas. Engloba todo tipo de situaciones,
desde el sistema de alarma conectado a la policía que avisa de que un ladrón intenta entrar en
el edificio donde residen las máquinas, hasta la llave del sistema de alimentación, que hace más
difícil al personal no autorizado apagar las máquinas.
Si se supone que la seguridad física está suficientemente bien cubierta, el siguiente paso que
una persona debe dar para acceder a la información de los ordenadores que se quiere proteger,
es acceder a una cuenta en tales máquinas. En este caso, se habla de controles de acceso lógicos.
En el mundo actual, el acceso de un individuo a una serie de aplicaciones y datos suele darse
cada vez más desde una localización remota, lo que ha terminado por hacer aparecer arquitec-
turas de autenticación y autorización más sofisticadas, conocidas como AAA (Authentication,
Authorization, Accounting), que suelen involucrar, en la parte local de la red, el uso de protoco-
los AAA, como el RADIUS o el TCACS/+.
Otro aspecto básico es el tratamiento de seguridad que se le da a los propios datos. Hay
sistemas de ficheros con mayor nivel de granularidad en cuanto al control de acceso, como
los que permiten dividir el tipo de acceso por usuarios y no por grupos. Igualmente, algunos
permiten la encriptación simple de ficheros, utilidad a tener en cuenta.
Finalmente, se va a analizar la seguridad que se tiene en cuenta, y la que debería tenerse
realmente, para los propios medios de almacenamiento en el que residen los datos.
Se trata de montar un perímetro de seguridad alrededor de las máquinas que se consideran vul-
nerables. Este perímetro debe estar aplicado especialmente sobre los servidores con información
especialmente relevante, asegurando que sólo las personas autorizadas disponen de un acceso
físico directo a la máquina. De igual manera, aquellos conmutadores y encaminadores que con-
tengan información relevante sobre el tráfico de los mensajes que circulan por la organización
deben estar protegidos por tal perímetro de seguridad.
También los terminales de los usuarios deberán estar protegidos en mayor o menor medida.
Esta protección mínima supone un reto especialmente difícil de cumplir para todos los dispositi-
vos móviles. Los usuarios portan estos dispositivos tanto dentro como fuera de la organización.
A este respecto han surgido una serie de utilidades que permiten bloquear o borrar los datos de
aquellos terminales sustraídos o extraviados.
Algunas de las medidas aplicables dependiendo de la importancia de la máquina dentro del
perímetro son:
Agrupar físicamente, en la medida de lo posible, las máquinas relevantes, en una habita-
ción suficientemente segura.
21
Tales habitaciones deben estar a la vista de cualquiera que visite la organización.
Tales habitaciones deben estar protegidas mediante medidas, que serán más o menos drás-
ticas, dependiendo del nivel de seguridad deseado.
3. En el caso de sistemas UNIX, hacer únicamente uso de la cuenta root cuando sea necesario,
trabajando mientras en una cuenta personal de usuario.
4. Si el sistema lo permite, habilitar el bloqueo de cuentas tras un cierto número de intentos
fallidos. Hay que ser prudente en este aspecto, debido a que este mismo bloqueo puede
usarse para desplegar un ataque de denegación de servicio.
22
6. No permitir contraseñas triviales, que sean palabras de un diccionario o listas de carac-
teres ASCII, ni permitir repeticiones triviales de contraseñas, habilitando un histórico de
las mismas.
7. Explicar a los usuarios las razones de la necesidad del cambio periódico de contraseña.
8. Suele ser una buena idea usar acrónimos como contraseñas.
9. Hacer el esfuerzo de no tener la misma contraseña en distintas máquinas o servicios.
No hay que olvidar que para que los atacantes puedan lanzar sus ataques de obtención de
contraseñas deben disponer de la información de los hashes de las contraseñas. Esto se puede
prevenir asegurando los ficheros que contienen tal información. En sistemas UNIX se debe co-
locar tal información en el fichero /etc/shadow, del que sólo el administrador tiene permisos de
lectura, al contrario que el /etc/passwd tradicional. Por su parte, el fichero de contraseñas, en hash,
de Windows Server, es un fichero que siempre está bien protegido (en NTFS) y es difícil de robar.
Otras medidas de autenticación que parecen tener un gran futuro se basan en lo que uno
es, en la biometría. En casi todas las aplicaciones biométricas, los datos (voz, retina, huellas,
etc.) se almacenan en una base de datos, de manera muy parecida al caso de las contraseñas. La
biometría funcionará bien sólo si el sistema verificador puede comprobar dos cosas distintas:
1. Que los datos biométricos recibidos vinieron de la persona correcta en el momento de la
verificación.
2. Que tales datos coinciden con los datos maestros almacenados en el fichero de datos bio-
métricos.
Si no suceden ambos, el sistema puede ser muy inseguro. La biometría no exige una certificación,
lo que la hace más fácil de usar y a la vez más vulnerable.
Finalmente, la tercera forma tradicional de autenticación es algo que uno tiene, los sistemas
de tarjetas conocidas como access tokens. Se inserta el token que se tiene en el sistema de control
y el ordenador lo verifica.
El problema más serio es que tales tokens se pueden robar o copiar. El sistema no autentica a la
persona, sino al token. Una solución ampliamente usada es combinar el token con una contraseña.
En el caso de acceso remoto a una red, ha de conocerse lo que se denomina sistemas AAA,
formados por una serie de componentes que se enumeran a continuación:
El servidor de acceso a la red o NAS, que es el punto de acceso a la red remota, en
la propia localización de tal red. Puede ser un encaminador, un cortafuegos, un sistema
UNIX o Windows o un sistema especial diseñado únicamente como NAS.
El servidor de autenticación AAA, que es el sistema con el que se comunica el NAS,
pasándole éste al servidor AAA la información de autenticación recibida desde el equipo
que pretende acceder. El servidor AAA comprueba tal información y envía al servidor
NAS su decisión de autenticación.
Los protocolos de autenticación, que son los que comunican el NAS con un servidor
AAA. Funcionan en la parte interna de la red protegida. Los más extendidos son RADIUS
y TACACS/+.
En redes grandes, puede haber más de un NAS y más de un servidor AAA, lo que da lugar a
una necesidad de coordinación entre ellos.
Las siglas AAA tienen el siguiente significado:
1. Authentication: el NAS, con su propia base de datos o mediante comunicación RADIUS o
TACACS/+ con el servidor AAA, autentica al usuario remoto.
2. Authorization: el NAS, mediante su comunicación con el servidor AAA, autoriza al usuario
para diferentes tipos de operaciones.
3. Accounting: función optativa, permite almacenar en el servidor AAA la información de
quién ha hecho qué cosas.
RADIUS (Remote Access Dial In User) es un protocolo compuesto por:
23
Un protocolo, con un formato de trama que usa UDP/IP.
Un cliente (el NAS).
Un servidor (el servidor AAA).
Los servidores RADIUS pueden actuar como clientes proxies para otro tipo de servidores de
autenticación. Las transacciones entre cliente y servidor RADIUS se autentican usando un secreto
compartido, que nunca se envía por la red. Además, cualquier contraseña de usuario se envía
encriptada. Los servidores RADIUS admiten cualquiera de los métodos de autenticación citados
anteriormente (contraseñas, biometrías o access tokens).
TCACS/+ (Terminal Access Controller Access Controller Access Control System Plus) es un proto-
colo que cumple las normas básicas de cualquier sistema AAA, y que además tiene las siguientes
características:
Utiliza transporte TCP, con un servidor que espera mensajes por el puerto 49.
La cabecera de datos de aplicación de la trama TCACS/+ está encriptada.
Se usa tanto para acceso remoto como para redes LAN.
Soporta casi cualquier método de autenticación, igual que RADIUS.
En coordinación con cortafuegos o encaminadores de Cisco que hagan de NAS, puede
enviar listas de control de acceso, por usuario, en la fase de autorización, al NAS.
24
6. Una respuesta completa a los problemas de seguridad en re-
des de información
6.1. Introducción
La política de seguridad es la forma razonable de contestar, ordenadamente, a los distintos
problemas de seguridad que pueden aparecer en las redes de cualquier organización. Las orga-
nizaciones no deben amoldarse a una política de seguridad, sino que ésta debe ser desarrollada
para una determinada organización, servir de guía para un correcto sistema de gestión de la
seguridad y cumplir con las disposiciones legales del país.
Algunas de sus características más relevantes son:
Define el comportamiento apropiado para cada caso.
Establece qué herramientas, procesos y procedimientos de gestión son necesarios.
Sirve para comunicar un consenso del uso de datos, información y aplicaciones dentro de
la organización.
Proporciona una base para la demostración del uso inapropiado de recursos, por parte de
empleados, clientes o colaboradores externos.
El desarrollo de una política de seguridad obliga a tomar decisiones delicadas. Hay que explicar
por qué se toman tales decisiones y cuáles son los peligros que se tratan de evitar. Los aspectos
esenciales de cualquier política de seguridad son:
Se analiza cuáles suelen ser los objetivos concretos de la política de seguridad.
Se definen las características imprescindibles de cualquier política de seguridad.
Se analizan aspectos clave para intentar hacer un diseño correcto de una política de segu-
ridad.
Se enumeran los puntos clave de seguridad para los componentes de cualquier red.
Se presentan las herramientas, procesos y procedimientos que ayudan a implementar una
política de seguridad.
Se presentan los estándares más significativos y las buenas prácticas actuales para procesos
de gestión de la seguridad.
Se presentan las leyes españolas más significativas, que hay que tener en cuenta a la hora
de elaborar la política de seguridad.
La seguridad es un proceso continuo, no es un producto que se instala y se configura, y necesita
un cuidado en el día a día.
25
Debe definir responsabilidades.
Debe permitir que siga realizándose el trabajo normal.
Hay que elegir el grupo, o persona, que hace que se cumplan cada una de las políticas y el
grupo director, que vela por el cumplimiento general.
Es buena idea que la política sea revisada por un grupo de la gente sobre la cual tendrá
efecto.
Cada política particular debe establecer, claramente, las razones de su necesidad, qué as-
pectos cubre, qué responsabilidades supone, qué duración tiene y el personal de contacto.
Siendo aún más concretos, se debe definir cuántas políticas o normas debe tener esa política
de seguridad. No suele ser buena idea tener sólo un gran documento sino muchos pequeños,
enlazados consistentemente.
Se puede hablar de algunas normas clave que estarán en cualquier política:
Normas de uso aceptable de equipos y servicios, especialmente significativa hoy en día
por el uso generalizado de portátiles, teléfonos móviles inteligentes y tabletas.
Normas de acceso remoto.
26
Otras normas posibles pueden tener en cuenta aspectos más específicos de la organización como:
Encriptación aceptable.
Proveedores de conexión a Internet aceptables.
Proveedores de software aceptables.
Seguridad en las adquisiciones.
Auditoría.
Valoración de riesgos.
...
Hay que señalar la importancia de la política de seguridad como eje del proceso de seguridad.
Como resultado de las normas emanadas de la primera versión de la política de seguridad, se
implementarán todos los procesos de seguridad física y lógica. Esto se puede considerar como
el primer paso del proceso.
El siguiente paso es la fase de monitorización de la red, en busca de incumplimientos de
la política de seguridad y posibles nuevas amenazas no tenidas en cuenta. Si de esta fase se
deduce que hay que hacer algún cambio en la política de seguridad para evitar incumplimientos
o para tener en cuenta nuevas amenazas posibles, se estará empezando a crear la “versión 2” de
la política.
La siguiente sería la fase de análisis de vulnerabilidades, que sirve para buscar problemas
relacionados con bugs en sistemas operativos o aplicaciones en cualquier tipo de máquina en la
red.
Finalmente, con todos los cambios necesarios consolidados, habrá que aplicar la nueva ver-
sión de la política de seguridad a todos los dispositivos que se vean involucrados, así como a los
procedimientos necesarios. Y aquí se repite la primera fase y la rueda seguirá girando.
27
¿Qué acceso se le da a una persona que viene a colaborar, en términos de ordenador, cuenta
y nivel de acceso?
¿Es necesaria la implantación de cámaras de seguridad?
Incluso podría ser necesario plantearse la necesidad de tener un centro en otro lugar físico.
Toda política de seguridad debe tener normas sobre uso aceptable, que definan el uso apropiado
de los recursos informáticos de la organización. Los usuarios deberían leer y firmar tales nor-
mas, como parte del proceso de petición de cuentas de trabajo. Debe establecer claramente la
responsabilidad de los usuarios con respecto a la protección de la información.
Otra política muy necesaria es la que hace explícitas las normas sobre acceso remoto a los
recursos informáticos de la organización. Es algo esencial para organizaciones grandes en las
que las redes están dispersas geográficamente. Debe cubrir todos los métodos disponibles para
acceder, remotamente, a los recursos de la red interna.
Otra política fundamental es la que trata de la protección de la información, que debe dar
una guía sobre el procesado, almacenamiento y transmisión de la información por parte de los
28
usuarios. Su objetivo fundamental es garantizar que la información está protegida apropiada-
mente frente a la posible modificación o revelación. Otro aspecto importante que debe cubrir es
la definición de los niveles de sensibilidad de la información de la organización, qué información
es pública, cuál es semi-pública y cuál está restringida y a qué niveles.
Actualmente de estas consideraciones se derivan consecuencias muy importantes para el
cumplimiento de la LOPD.
Otra política es la que debe tratar de la seguridad perimetral, que debe describir de forma
general cómo se mantiene tal seguridad, qué nivel debe tener, quién o quiénes son responsables
de mantenerla y cómo se gestionan los cambios de hardware y software de los dispositivos en el
área del perímetro de seguridad.
La siguiente política básica que se cita es la política de protección frente a posibles ataques
de virus informáticos. Esta política debe proporcionar las líneas generales de los informes sobre
infecciones por virus, así como los procedimientos de contención de dichas infecciones.
Otra política que debe aparecer siempre es la que tiene que ver con las contraseñas. Debe
contener las directrices de cómo gestionar las contraseñas de usuario y administrador, así como:
Las reglas de creación de las contraseñas.
Las reglas de cómo evitar la revelación de contraseñas.
Las reglas para el desarrollo de aplicaciones en las que haga falta la contraseña.
Las reglas de uso de todo tipo de contraseñas de protocolos, como por ejemplo el string de
comunidad de SNMP.
Otra política típica es la que describe los procedimientos a seguir frente a incidentes de seguri-
dad, los procedimientos de gestión de incidentes. Es imposible tener preparadas respuestas para
todo tipo de incidentes, pero esta política debería cubrir, al menos, los incidentes más típicos,
aquellos de los que sabe que hay mayor incidencia.
Datos de nivel Básico: son aquellos datos personales que no se clasifican como de
nivel Medio o Alto.
Datos de nivel Medio: algunos ejemplos serían los relativos a la comisión de infraccio-
nes administrativas o penales, aquellos de los que sean responsables Administraciones
Tributarias o los Servicios Comunes de la Seguridad Social.
29
Datos de nivel Alto: los que se refieran a datos de ideología, afiliación sindical, re-
ligión, creencias, etc. Los que contengan o se refieran a datos recabados para fines
policiales sin consentimiento de las personas afectadas.
Las empresas que se dediquen a la realización de publicidad por la red, tienen las siguientes
obligaciones añadidas:
La identificación del anunciante debe ser muy clara.
El carácter publicitario del mensaje debe resultar inequívoco.
Cualquier oferta debe estar claramente identificada como tal y debe expresar de forma
clara las condiciones de participación.
30
El envío de mensajes publicitarios por Internet o mediante mensajes SMS debe hacerse
únicamente con el consentimiento del destinatario.
Para los operadores de telecomunicaciones, los proveedores de acceso a Internet, los prestadores
de servicios de alojamiento de datos y los buscadores no son responsables de los contenidos que
transmiten o alojan o a los que facilitan acceso, si no participan en su elaboración.
Introducir los elementos comunes que han de guiar la actuación de las Administraciones
públicas en materia de seguridad de las tecnologías de la información.
Aportar un lenguaje común para facilitar la interacción de las Administraciones Públicas,
así como la comunicación de los requisitos de seguridad de la información a la Industria.
31
Los certificados de seguridad son expedidos por Organismos de Certificación reconoci-
dos, a productos o sistemas informáticos que hayan sido satisfactoriamente evaluados por
servicios de evaluación, conforme a los Criterios Comunes.
• Asegurar que las evaluaciones de los productos y sistemas informáticos de los res-
pectivos perfiles de protección se llevan a cabo de acuerdo con normas rigurosas y
consistentes.
• Propiciar el aumento de los productos y sistemas informáticos y de los perfiles de
protección evaluados, con nivel de seguridad creciente, disponibles en el mercado.
Eliminar la carga de trabajo que supone la duplicación, en distintos países, de las evalua-
ciones de los productos y sistemas informáticos.
Disminuir el gasto del proceso de evaluación y de certificación de los productos y sistemas
informáticos y perfiles de protección.
Los conceptos clave de los Criterios Comunes son:
El perfil de protección (PP) Define un conjunto de requerimientos y objetivos de seguridad, in-
dependientes de la implementación, para una cierta categoría de productos o sistemas,
con parecidas necesidades por parte del consumidor, desde el punto de vista de seguridad
informática.
El objetivo de la evaluación (TOE) Un producto o sistema informático, que es sujeto de una
evaluación.
El objetivo de seguridad (ST) Contiene los requerimientos y objetivos de seguridad de un TOE,
específico e identificado, y define las medidas funcionales y de seguridad, ofrecidas por el
TOE, para alcanzar los requerimientos establecidos.
Se dispone de un catálogo de componentes de seguridad que ayudan a formar las definiciones
de los requerimientos de seguridad. Tal catálogo incluye:
Auditorías.
Soporte criptográfico.
Protección de datos del usuario.
Identificación y autenticación.
Administración de la seguridad.
Los niveles de seguridad evaluada (EAL) definen una escala de medición de los criterios de
evaluación de PPs y STs, y son 7.
32
La implementación de una serie de controles para gestionar los riesgos en el contexto del
negocio de la organización.
La monitorización del rendimiento del SGSI.
Comprobar: medir el rendimiento de los procesos contra los objetivos del SGSI, notificando
los resultados a la dirección para su revisión.
Actuar: basándose en las revisiones, realizar acciones preventivas y correctivas para alcan-
zar la mejora continua del SGSI.
Hoy en día no se puede pretender mantener una buena política de seguridad sin tener en cuenta,
en mayor o menor detalle, el estándar ISO/IEC 27001.
33
7. Introducción a los métodos no criptográficos para la implan-
tación de la política de seguridad
7.1. Introducción
Se va a hacer una descripción de las herramientas, procesos y tecnologías que se analizarán
en detalle en los siguientes temas, sin tener en cuenta sus posibles usos criptográficos. Es impor-
tante señalar que algunos de tales elementos, como ciertos cortafuegos o encaminadores, usan
también métodos criptográficos para una serie de tareas como la creación y el mantenimiento de
redes privadas virtuales.
No se pretende, con este pequeño tema, más que establecer claramente la batería de he-
rramientas disponibles desde puntos de vista no criptográficos, para implantar una política de
seguridad en una organización.
Implementación:
medidas básicas,
cortafuegos, redes
privadas virtuales, etc.
Análisis de Monitoriza-
vulnerabilida- Política de Seguridad ción:
des: auditorías,
analizadores y sistemas de
pruebas detección de
intrusiones
Los elementos no criptográficos que hay que tener en cuenta dentro de la fase de implemen-
tación son:
Los honeypots, equipos o redes falsos, en el sentido de que desde el nombre hasta los
procesos del sistema todo está modificado, creando un entorno que parece real pero no lo
es. El objetivo de este entorno es capturar la información de los atacantes que accedan.
Los sistemas de detección de intrusiones. Como se verá en el tema 11, los hay de diversos
tipos, aunque casi todos se dedican a analizar el tráfico de una red en busca de patrones de
ataque. Generalmente pueden lanzar alarmas, generar registros de log y, en algunos casos,
parar tales ataques.
Para la fase de análisis de vulnerabilidades del proceso de seguridad se debe tener en cuenta:
34
Los laboratorios de pruebas, cuyo objetivo es, esencialmente, disponer de una red separa-
da de la real, en la que se puedan ir probando los distintos tipos de ataques que podrían
suceder en la red real, probando igualmente las medidas de defensa.
Tolerancia a fallos de los servidores más significativos. Bien sea con un equipo completa-
mente redundante o mediante una solución de tipo cluster.
Un plan de recuperación de la situación actual, tras un posible desastre, que perfectamente
puede ser físico.
Una organización de gestión de la red cuyo objetivo sea, esencialmente, mantener funcio-
nando la mayor cantidad de tiempo posible los sistemas.
35
8. Introducción a los cortafuegos
8.1. Introducción
Los cortafuegos aparecieron debido al cambio de condiciones en la informática, en las redes
y en la forma de afrontar los problemas de seguridad informática.
Un cortafuegos implementa una aproximación basada en red a la consecución de la seguridad
de redes. Desde un punto de vista ideal, un cortafuegos debe tener las siguientes características:
Todo el tráfico de “dentro a fuera” y de “fuera a dentro” debe pasar a través del cortafue-
gos.
Sólo aquel tráfico autorizado, basándose en la política de seguridad, puede seguir su ca-
mino.
El cortafuegos es completamente inatacable.
Ninguno de los cortafuegos actuales cumple estos requisitos completamente.
36
8.3. Los filtros de paquetes
Un filtro de paquetes está ubicado en la frontera entre la red que se trata de proteger y el
resto del mundo. Un sitio muy habitual suele ser en la conexión final con el proveedor de acceso
a Internet.
Los filtros de paquetes operan en el nivel de red (nivel IP) y de transporte (TCP y UDP) y
filtran paquetes IP, basándose en los valores de algunos campos de las cabeceras de IP, TCP y
UDP.
Cada filtro está compuesto por una serie de reglas, que utilizarán de distintas formas tales
valores, que se contrastarán en orden en busca de una coincidencia.
Un filtro de paquetes examina cada paquete entrante y:
1. Obtiene los contenidos de las cabeceras citadas del paquete.
2. Contrasta los valores contra los configurados en las reglas del filtro.
3. Si cumple lo enunciado en una regla, aplica una de las dos únicas condiciones posibles: lo
permite o lo descarta.
Las máquinas que actúan como filtros de paquetes pueden tener muchas interfaces. Depende de
la política de seguridad en qué interfaces se colocan filtros. No tiene por qué ser en todas. Otra
consideración importante es en qué sentido se aplica el filtro.
Los campos de las cabeceras que se usan como criterios de filtrado son:
Las direcciones IP de origen y de destino del mensaje.
Los números de puerto de origen y de destino del mensaje.
El tipo de protocolo o número de protocolo.
Una serie de opciones de la cabecera TCP, como los bits de sincronización, de final, de
ACK, etc.
Cualquier buen filtro tiene, además, que tener expresiones que permitan especificar números de
puerto o rangos de números de puerto.
Estos filtros de paquetes son actualmente muy comunes y, aunque se pueden implementar
en paquetes software como IPTables, lo más común es verlos funcionando en prácticamente
cualquier encaminador.
Tienen una serie de puntos débiles que hay que tener en cuenta:
Si la configuración llega a hacerse muy grande, puede hacerse difícil el mantenimiento.
Si se tiene que hacer una excepción ocasional, puede ser que haya que cambiar toda la
configuración.
No permiten realizar ningún control a nivel de usuario ni a nivel de datos.
No es fácil filtrar protocolos con más de una conexión activa simultáneamente.
No suelen guardar registro de los accesos de los usuarios.
¿Cómo se expresan estas reglas de filtrado? Habitualmente estas reglas se especifican como una
tabla de condiciones y acciones que se consulta de forma ordenada hasta encontrar una regla
que permita decidir sobre la acción a realizar sobre un determinado paquete.
La forma de añadir estas reglas y la estructura final de la tabla de reglas dependerá de la
implementación concreta que se use. Cada solución tendrá su propia sintaxis o herramientas de
configuración. El funcionamiento es similar en todos los casos y se puede ilustrar con el siguiente
ejemplo.
La Figura 2 nos muestra la topología de una red hipotética que queremos proteger usando
un filtro de paquetes.
La siguiente tabla muestra una hipotética tabla de reglas de filtrado para el filtro de paquetes
del diagrama:
Si al cortafuegos del ejemplo llega un paquete proveniente de una máquina perteneciente a
la red 192.168.0.0, se bloqueará su paso independientemente de la red de destino. Igualmente,
todo el tráfico hacia la red 124.21.0.0 será detenido y bloqueado por el cortafuegos.
37
155.15.11.0 124.21.0.0
Todas las redes
externas
eth0
Filtro de paquetes
eth1 eth2
Redes a
192.168.0.0 proteger 192.168.1.0
Por el contrario, todo el tráfico que se reciba proveniente de la red 192.168.1.0 a través del
puerto 80 será admitido por el cortafuegos.
Pero, ?qué sucederá cuando llegue un paquete proveniente de la red 192.168.1.0 hacia la red
155.15.11.0 a través del puerto 80? Una de las reglas indica que dicho paquete puede pasar y
otra nos dice que se le debe denegar el paso. El resultado final dependerá de la implementación
particular del cortafuegos y del orden en que se analizará la tabla de reglas.
¿Qué pasaría si un atacante utilizara técnicas de suplantación de IP? El atacante podría enviar
sus paquetes suplantando una dirección IP perteneciente a la subred 192.168.1.0 y conseguir así
que sus paquetes atravesasen el firewall y llegasen a su destino. Por ello, es necesario también
identificar los interfaces de red por los que han de llegar los paquetes para que dichas reglas
sean efectivas.
El número N es un valor entre 1 y 99 que sirve para relacionar las reglas de la misma ACL. Las
llaves ({}) indican que hay que poner una de las dos opciones: permit o deny. La “máscara” es
opcional, lo que se indica mediante corchetes ([]). Cuando se usa, indica qué bits de la dirección
IP previa son significativos.
Hay que recordar tres puntos importantes, válidos tanto para las ACL standard como para
las extended:
1. Al final de todas las reglas existe una más (que no pone el administrador) implícita, que
deniega el resto del tráfico que no coincida con ninguna de las reglas ACL.
38
2. Hay una serie de palabras clave que se pueden utilizar para hacer las reglas más legibles.
Por ejemplo, en lugar de 144.21.13.12 0.0.0.0, se puede escribir host 142.21.13.12, o en lugar
de escribir 0.0.0.0 0.0.0.0 se puede escribir any.
3. El comando access-list sólo sirve para construir la ACL, pero no la aplica a ninguna interfaz.
Para aplicar la ACL a una interfaz concreta, se debe pasar a lo que Cisco denomina “modo de
configuración de la interfaz” y aplicar el comando ip access-group. La sintaxis es:
Las ACL de tipo extended comparten todas las demás características de las standard, pero tienen
un sintaxis más complicada atendiendo a que permiten filtrar utilizando muchos otros criterios:
En este caso, N es un número entre 100 y 199, “protocolo” es la referencia al campo de número
de protocolo de la cabecera IP y “op” es un operador que permite indicar incluso hasta rangos
de números de puerto. “op” puede ser:
lt: menor que
ne: distinto a
range: permite expresar un rango de números
Si, para la misma red del ejemplo anterior, buscamos que se cumpla la siguiente política:
39
8.4. Los Gateways de aplicación o servidores Proxy
Los servidores proxy soportan filtros a nivel de aplicación, en lugar de a nivel de red/trans-
porte como lo hacían los filtros de paquetes. Un cortafuegos de esta tecnología lo es para un
protocolo de aplicación, se puede decir que hay un proceso proxy por cada protocolo que se
quiera filtrar. Típicamente, un servidor proxy funciona en una máquina con dos placas que re-
side entre los clientes y el servidor real, e intercepta las peticiones de los clientes de servicios
particulares.
El servidor proxy evalúa tales peticiones de servicio y decide qué tráfico sigue adelante y qué
tráfico se corta. Un servidor proxy también suele proporcionar NAT (Network Address Translation),
que oculta las direcciones IP reales de los equipos de la red interna, cambiándolas por otra antes
de que los mensajes correspondientes se envíen “hacia fuera”.
Entre los puntos fuertes de los gateways de aplicación se pueden señalar:
Permiten filtrar a nivel de aplicación, lo que quiere decir que se puede filtrar por operacio-
nes concretas de protocolo (p.ej. comando put del protocolo FTP).
Pueden tener un proceso separado por protocolo, no tienen que tratar de hacerlo todo a la
vez.
Hacen extremadamente sencillo restringir el acceso a un servicio: si no hay proxy, no hay
servicio.
Simplifica enormemente las reglas de filtrado en el encaminador. Sólo se debe permitir el
tráfico hacia la pasarela de aplicación y bloquear el resto.
Permite un grado de ocultación de la estructura de la red protegida.
Entre los posibles problemas de los servidores proxy se encuentran:
Al funcionar un proceso proxy por servicio, se deben tener multitud de ellos.
Depende de qué tecnología concreta se seleccione, puede pasar que se tengan que usar
distintos clientes, servidores, o ambos.
Pueden llegar a ser un cuello de botella tremendo para el tráfico.
40
9. Tecnologías de última generación en cortafuegos
9.1. Introducción
Lo que se podría denominar última generación de la tecnología de cortafuegos se basa esen-
cialmente en dos características:
El uso de la tecnología de inspección de tráfico que incluye el estado completo de las
transacciones, o tecnología stateful inspection.
La acumulación de características de seguridad, antes no asociadas con los cortafuegos,
que hacen de estos una especie de super dispositivos de seguridad.
La tecnología de inspección completa del tráfico se basa en que el cortafuegos pueda obtener,
almacenar, manipular y utilizar información que se obtenga de todos los niveles de comunica-
ción, incluyendo las aplicaciones. Con esa información el cortafuegos debe decidir si deja pasar
el tráfico, lo rechaza, lo encripta, etc. La idea subyacente es que no es suficiente examinar cada
mensaje IP de manera aislada.
Recordemos los tres tipos de tráfico IP:
Mensajes IP de aplicaciones basadas en sesiones TCP.
Mensajes IP de aplicaciones basadas en el protocolo UDP.
Mensajes IP de protocolos de nivel de red, tal como ICMP, OSPF, etc.
41
Tabla Función Cadena Función de la cadena
Filtra paquetes dirigidos a la
FORWARD
red protegida.
FILTER Filtrado de paquetes
Filtra paquetes destinados al
INPUT
cortafuegos.
Filtra paquetes procedentes del
OUTPUT
cortafuegos.
Cambia la dirección IP de
Network Address PREROUTING
NAT destino (DNAT).
Translation
Cambia la dirección IP de
POSTROUTING
origen (SNAT).
Modificación de Modificación de los bits QoS de
MANGLE
cabeceras TCP las cabeceras TCP.
Si el destino del paquete se encuentra en la red protegida por el cortafuegos será inspecciona-
do por las cadenas FORWARD de las distintas tablas. Cuando llegue a la tabla POSTROUTING
de NAT esta comprobará si es necesario cambiar la dirección IP de origen (SNAT). Si pasa estos
filtros el paquete llegará al destinatario final.
Si el destinatario del paquete es el propio cortafuegos, el paquete pasará por las cadenas IN-
PUT de las tablas Mangle y Filter. Si el paquete pasa estos filtros será entregado a la aplicación
destinatario en el cortafuegos. Así mismo, los paquetes de salida originados en el propio corta-
fuegos pasarán por la cadena OUTPUT. La Figura 3 muestra el diagrama de flujo que siguen los
paquetes a través de las distintas tablas y cadenas de IPTables.
Si no se especifica una tabla IPTables considerará por defecto que se quiere añadir a la table
Filter. La Tabla 4 muestra los posibles tipos de operación que se pueden definir.
Operación Descripción
-A <cadena> Añadir la regla al final de la cadena indicada.
-F <cadena> Borrar todas las reglas de la cadena indicada.
-L <cadena> Listar las reglas de la cadena indicada.
-P <cadena> Añadir una acción por defecto a la regla indicada.
La opción de añadir reglas por defecto permitirá establecer una acción a realizar para todos
los paquetes que no cumplan ninguna otra regla. Si se quiere establecer una política restrictiva se
añadirán reglas de bloqueo en las tres cadenas de la tabla Filter como se muestra a continuación:
42
Paquete Entrante
Red A
Tabla Filter
Enrutado
Cadena OUTPUT
Datos para el
Sí cortafuegos? No
Tabla Mangle
Enrutado
Cadena POSTROUTING
Respuesta del
firewall Tabla NAT
Cadena POSTROUTING
Red B
Las reglas mostradas establecen por defecto la acción DROP para las tres cadena de la tabla
filter. La Tabla 5 muestra las acciones más comúnmente utilizadas.
Además de indicar la tabla, cadena y operación a realizar, será necesario establecer criterios
de filtrado. Estos criterios van a permitir definir a qué paquetes se debe aplicar dicha regla. Para
ello se podrán utilizar las direcciones de origen y/o destino del paquete, la interfaz de red por
la que llega, el tipo de protocolo, etc.
La Tabla 6 muestra algunos de los filtros que se pueden utilizar con IPTables, mientras que
la Tabla 7 muestra algunos de los modificadores más comunes a utilizar con dichos filtros.
El siguiente ejemplo permite entender la estructura de las reglas:
-s 0/0 especifica que se aplicará a cualquier dirección IP. Por ejemplo la opción -s
192.168.1.0/24 equivale a indicar 192.168.1.0 con una máscara de red 255.255.255.0.
-o eth1 indica que se aplicará al tráfico cuyo destino esté en la interfaz de red eth1.
43
Operación Descripción
ACCEPT El paquete se entrega al sistema operativo para ser procesado.
DROP El paquete es bloqueado.
LOG La información del paquete se envía al proceso encargado de registrar el
log. A continuación IPTables continua comparando el paquete con las
siguientes reglas de la cadena.
REJECT El paquete es bloqueado pero en este caso se envía al origen un mensaje de error.
DNAT Para hacer NAT en destino cambiando la dirección IP de origen.
-to-destinationipaddress
SNAT Para hacer NAT en origen cambiando la dirección IP de destino.
-to-source<address>[-<address>][:<port>]
MASQUERADE Para hacer NAT de origen. Por defecto la dirección IP de origen es la que usa el
interfaz de red del cortafuegos.
Operación Descripción
-p <tipo-protocolo> Permite especificar el protocolo de red del paquete (tcp, udp, idmp. . . )
-s <direccion-ip> Permite especificar la IP de origen.
-d <direccion-ip> Permite especificar la IP de destino.
-i <interfaz> Permite especificar el interfaz de red de entrada del paquete.
-o <interfaz> Permite especificar el interfaz de red de salida del paquete.
-p tcp -dport 80 indica que se aplicará a todo el tráfico TCP con puerto de destino el
puerto 80.
Por último -j ACCEPT indica que dicho tráfico será permitido.
La siguiente regla indicaría a IPTables que debe permitir todo el tráfico ICMP entrante:
La regla de LOG deberá situarse antes que la regla DROP o REJECT, ya que en caso contrario el
paquete sería rechazado antes de que se comparase con la regla de registro. Las siguientes reglas
muestran un ejemplo de lo que sería necesario incluir para registrar y rechazar todo el tráfico
ICMP entrante:
Una máquina interna podría lanzar una petición a una página web alojada en un servidor ex-
terno, pero la respuesta de dicho servidor no podría alcanzar dicha máquina. Por tanto, será
necesario añadir una regla a la cadena INPUT para permitir el tráfico relacionado con conexio-
nes salientes:
44
Modificador Descripción
-p tcp -sport <port> Permite especificar el puerto TCP de origen del paquete.
-p tcp -dport <port> Permite especificar el puerto TCP de destino del paquete.
-p tcp -syn Permite especificar paquetes de inicio de conexión TCP (flag SYN
activado).
-p udp -sport <port> Permite especificar el puerto UDP de origen del paquete.
-p udp -dport <port> Permite especificar el puerto UDP de destino del paquete.
-icmp-type <type> Permite filtrar por el tipo de petición ICMP. Los valores más usados
son echo-reply y echo-request.
Una vez añadida esta regla será necesario permitir la retransmisión de paquetes por el núcleo
del sistema operativo. Será necesario ejecutar el siguiente comando:
#echo 1 > /proc/sys/net/ipv4/ip_forward
A continuación habrá que añadir otra regla a la tabla NAT de forma que permita hacer NAT de
origen, sustituyen la IP de origen de los paquetes salientes por la dirección IP del cortafuegos.
A la vista de la red externa el cortafuegos será el que origina los paquetes (x.x.x.x/24 representa
el rango de direcciones IP de la red interna):
#iptables -t nat -A POSTROUTING -o eth0 -s x.x.x.x/24 -j MASQUERADE
Finalmente será necesario incluir reglas que permitan la retransmisión de aquellos paquetes
salientes (-o eth0) que correspondan a conexiones nuevas, ya establecidas y/o relacionadas,
y la retransmisión de aquellos paquetes entrantes (-i eth0) que correspondan a conexiones ya
establecidas o relacionadas:
A continuación será necesario añadir una regla DNAT que “traduzca” la dirección de destino a
la dirección IP del servidor (en el ejemplo 192.168.1.50):
También será necesario añadir una regla SNAT para que los paquetes de respuesta enviados
por el servidor de correo, de forma que presenten como dirección origen la dirección IP del
cortafuegos. El cliente de correo habrá lanzado la petición a dicha IP y esperará la respuesta
de esa IP y no de la dirección IP del servidor (en el ejemplo la dirección IP del cortafuegos es
192.168.0.50).
Por último será necesario añadir una regla que permita reenviar los paquetes recibidos a la
máquina en la que esté instalado el servidor de correo electrónico. Si no se añadiese esa regla el
paquete se quedaría en el firewall y no pasaría al servidor correspondiente:
#iptables -A FORWARD -p tcp --dport 25 -j ACCEPT
45
9.2.5. Guardar y restaurar reglas de filtrado
Una vez se reinicia el cortafuegos las reglas que se hayan añadido se perderán y el cortafuegos
volverá a su estado original. Para evitar la pérdida de reglas configuradas, se podrá usar el
comando iptables-save para guardar dicha configuración en un fichero:
#iptables-save>cortafuegos.cfg
Además existe la posibilidad de crear un script sh que se podrá configurar para ser ejecutado al
iniciar el sistema, el cual contenga los diferentes comandos con las reglas que se quieren añadir
al cortafuegos.
Internet
Red externa
ethernet 0
Ethernet 0 nivel seg. 0
interface outside
ASA Firewall
Ethernet 2
Los niveles de seguridad ASA indican si una interfaz es más fiable o menos fiable desde un
punto de vista relativo respecto a otra interfaz. Esta característica determina cómo funcionan las
reglas del ASA:
1. Como situación por defecto, desde cualquier interfaz con un nivel de seguridad mayor que
otra interfaz se puede enviar tráfico a esta segunda.
2. A la inversa no se puede acceder, a menos que haya una lista de control de acceso (ACL)
que lo permita. Esta lista, además, se denomina excepción del ASA.
46
3. La red que se desee proteger más debe estar conectada a la interfaz inside. De esta forma
nadie podrá acceder a esta interfaz salvo que esté específicamente permitido.
4. La red en la que confiemos menos debe estar conectada a la interfaz outside. Desde esta
interfaz no se tiene acceso a ningún equipo en las demás interfaces, a no ser que se permita
explícitamente.
5. Por defecto, entre dos interfaces con mismo nivel de seguridad, no hay comunicación.
Implementar NAT mediante los comandos nat y global, que crean una asociación entre
direcciones en la interfaz inside y direcciones globales en la interfaz outside.
Definir rutas estáticas o por defecto para cada interfaz, o al menos para la interfaz outside,
con el comando route.
Con esta configuración mínima, el ASA protege completamente la red de la interfaz inside, por
lo que hacen falta excepciones ASA si se quiere acceder a ella desde cualquier otra. Para ello,
primero se crean asociaciones estáticas de direcciones IP internas con direcciones IP externas
(NAT estático) mediante el comando static. Después se crean los filtros de excepción mediante
el comando access-list, que crea una lista de acceso igual que si fuera un encaminador Cisco y el
comando access-group, que la aplica en una interfaz.
Cada asociación NAT (estática o dinámica) que se produce al atravesar el ASA un mensaje,
crea una estructura de gestión interna del ASA, conocida como xlate, que se mantiene mientras
exista alguna conexión TCP o sesión UDP asociada a ella. Hay que darse cuenta de que asociadas
con una xlate pueden haber múltiples conexiones, por ejemplo simultáneamente una conexión
http y una conexión ftp.
47
La redundancia completa o stateful, en la que hay que usar una interfaz Ethernet 100 Mbps
en cada ASA sólo para conseguirla. Con ella, las conexiones TCP permanecen activas y se
dice que se proporciona redundancia y conexión completa.
48
10. Introducción a las herramientas de análisis de vulnerabili-
dades de seguridad
10.1. Introducción
El gran número de vulnerabilidades de seguridad del software provoca que haya que afrontar
el hecho de la aparición de nuevos virus o, en general, de ataques que se aprovechan de dichas
vulnerabilidades.
Se puede definir un analizador de vulnerabilidades como un programa que busca, de ma-
nera automatizada, vulnerabilidades de seguridad en una aplicación o en un sistema. Existen
diferentes tipos:
Los que buscan vulnerabilidades en aplicaciones y/o sistemas en tiempo real, en situacio-
nes de uso real.
Los que buscan vulnerabilidades en el código de las aplicaciones o sistemas (SSCA), inde-
pendientemente del estado de uso de las mismas.
Informar al personal responsable. Los administradores de red de los equipos que se vayan
a analizar deben estar al tanto de la situación.
49
10.2.1. Instalación y uso de Nmap
Para lanzar un escaneo simplemente hay que indicar la dirección IP del host que deseamos
escanear o su dominio. Si se desea escanear un sector de la red bastará con indicar en “target”
la dirección de la red y la máscara con la que se define el rango de direcciones que se desea
escanear.
El siguiente paso consiste en elegir el tipo de escaneo que queremos lanzar. Podemos escribir
a mano el comando Nmap que queremos usar, o podemos elegir entre los distintos perfiles de
escaneo preconfigurados en Zenmap.
Cuanto más intenso sea el perfil seleccionado, más peticiones se enviarán al host o hosts
objetivo y, por tanto, será más fácil que dicha actividad sea detectada por las herramientas de
seguridad de la red en que resida el objetivo del escaneo.
Una vez lanzado el escaneo, Nmap muestra los resultados conforme se van obteniendo.
50
10.4. Herramientas de análisis de vulnerabilidades en código fuente
Los analizadores de vulnerabilidades en código fuente (SSCA) se pueden usar para exami-
nar código heredado y también como herramienta rutinaria en el ciclo de desarrollo de software.
El análisis estático de código fuente es una técnica de detección de errores que no requiere la
ejecución del programa. Estas herramientas están diseñadas para detectar vulnerabilidades de
seguridad que, si no se tienen en cuenta, pueden convertirse en agujeros de seguridad explota-
bles una vez el programa esté disponible y en uso.
51
11. Introducción a las herramientas de detección de intrusiones
11.1. Introducción
Nos centraremos ahora en la fase de monitorización del desarrollo de un proceso de se-
guridad. En ella, hay que preocuparse de revisar todos los registros de alarmas y de auditoría
de cualquier programa o sistema que los mantenga, pero una vez más, ésta es una medida de
reacción frente a sucesos que ya han ocurrido. Una fase de monitorización correcta debe tener
en cuenta medidas de prevención y tales medidas se consiguen con herramientas denominadas
sistemas de detección de intrusiones.
En los últimos años han ido apareciendo soluciones que realizan esta labor de manera au-
tomática. Los primeros utilizaban lo que se conocía como detección de anomalías. No tuvieron
mucho éxito pues producían muchos falsos positivos.
El problema esencial de este tipo de sistemas se puede resumir diciendo que hay demasiada
variación en la forma en la que los usuarios se comportan en una red como para que este tipo
de detección sea eficaz.
Los sistemas IDS usados hoy en día son todos ellos basados en firmas. Tales firmas de ataque
son mensajes concretos, o grupos de mensajes, que indican con una cierta fiabilidad que hay un
ataque en curso. Una firma sería un conjunto de reglas, típicas de una actividad, que se asocia
claramente con una intrusión en la red.
Otro criterio de clasificación de los sistemas IDS es en función de dónde se colocan en la
topología de la red de la organización:
Pueden colocarse en un segmento de red, en cuyo caso monitorizan el tráfico que circula
por ese tramo de red. En este caso, se habla de IDS basados en red.
Pueden colocarse como salvaguarda de un solo sistema y en este caso, se habla de IDS
basados en el sistema. Sólo protegen un sistema y a cambio resultan más baratos.
Suele ser normal que el control se haga de manera remota, por dos razones:
Si hay varios IDS en la organización, para llevar el control centralizado desde un solo sitio
de la organización.
Por facilidad de administración, pues los sistemas en sí no suelen permitir una gestión
gráfica.
Las características generales que deben cumplir cualquiera de estas herramientas son:
Deben tener actualizaciones frecuentes. Tales actualizaciones deben ser sencillas de reali-
zar.
Deben tener capacidad de adaptación al entorno, es decir, se deben poder crear nuevas
firmas y, de forma flexible, poder decidir si se buscan más ciertos tipos de firmas que otras.
Deben exhibir un buen rendimiento, sobre todo si se habla de redes con un gran volumen
de tráfico.
Hay además una serie de aspectos a tener en cuenta a la hora de desplegar los IDS en la red:
El primero es dónde colocarlo. Lo mejor es disponer de varios. Si sólo se va a trabajar con
uno, suele ser normal ponerlo en la red externa al cortafuegos. Hay que ser consciente de
que, en esta disposición, los ataques a máquinas internas originados en el interior de la red
no son monitorizados por el IDS.
Es también importante considerar dónde se va a conectar el IDS a la red. Para que realice
su labor deberá ser capaz de capturar todo el tráfico de la red que se desea analizar.
Otro aspecto importante es el de los falsos negativos, los ataques reales no detectados.
Además, dependiendo de múltiples factores, puede que no se esté comprobando todas las
firmas de las que se dispone.
Hay que tener cuidado también con los falsos positivos. Esto puede llegar incluso a ser
utilizado por un atacante para tratar de dejar fuera de servicio al IDS.
Hay que tener preparado cómo se va a realizar la respuesta a incidentes. Demasiadas
alertas, incluso siendo reales, pueden provocar una parada del servicio.
52
11.2. Caso práctico: Snort
Snort es una herramienta de software libre multiplataforma, capaz de funcionar como escu-
chador de paquetes (sniffer) y como detector de intrusiones basado en red, capaz de monitorizar
el segmento de red al que está conectado. Este programa tiene tres modos de funcionamiento:
Sniffer: en este modo Snort captura los paquetes entrantes y los va mostrando en pantalla
en tiempo real.
Registro de paquetes: en este modo Snort captura los paquetes entrantes y los guarda en
un fichero para poder ser explorados y analizados posteriormente.
IDS (Intrusion Detection System): en este modo de funcionamiento Snort captura el tráfico
entrante y lo analiza en busca de riesgos de seguridad. Este es el modo de funcionamiento
de Snort más complejo y más configurable.
Iniciar Snort en modo escuchador de paquetes es bien sencillo. Bastará con ejecutar el siguiente
comando:
#snort -v
Snort seguirá mostrando paquetes por pantalla hasta que se cancele la acción, momento en el
que mostrará información estadística de los paquetes analizados.
Si se desea, se puede ampliar la información mostrada por Snort para que muestre además
de las cabeceras el contenido de los paquetes capturados por medio del comando
#snort -vd
E incluso se puede pedir que añada la información correspondiente a la capa de enlace por
medio del comando
#snort -vde
En caso de querer usarlo como capturador de paquetes, lo normal es usarlo de forma que registre
los paquetes en un fichero de log. Para ello se ejecutará Snort mediante
Así mismo se puede indicar que sólo registre la información correspondiente a un rango de
direcciones IP:
Otra de las opciones interesantes de Snort es que la información registrada se puede guardar en
formato binario, de forma que el fichero generado pueda ser analizado por cualquier herramien-
ta de análisis compatible con tcpdump:
Donde snort.conf es el nombre del fichero de configuración principal de Snort. Al ejecutar este
comando Snort empezará a cotejar los paquetes capturados, con las reglas indicadas en dicho
fichero de configuración para determinar si es necesario tomar alguna acción.
Si Snort se va a utilizar como solución IDS a largo plazo, es recomendable eliminar la opción -
v. De esta forma se evitará que muestre por pantalla la salida. Así mismo, puede no ser necesario
registrar los datos de la capa de enlace. Teniendo en cuenta estas consideraciones, la forma más
sencilla y más eficiente de lanzar Snort como IDS es:
53
Opción Descripción
-A fast Modo de alerta rápido. Guarda la información básica de la alerta que consiste en la
fecha y hora del registro, el mensaje de alerta y la dirección IP y puerto de origen y
destino.
-A full Modo de alerta completo. Este es el modo de salida por defecto si no se especifica el
modo de salida.
-A unsock Envía las alertas a un socket UNIX en el que estará escuchando otro programa.
-A none Desactiva el registro de alertas.
-A console Mostrará las alertas por pantalla.
De esta forma Snort registrará aquellos paquetes que cumplen alguna de las reglas especificadas
en el fichero snort.conf. La información se guardará en ficheros ASCII, y dependerá del modo
de salida seleccionado, lo cual se puede hacer mediante la opción -A tal y como se recoge en la
Tabla 8.
Existe además la posibilidad de enviar las alertas al registro del sistema (syslog) mediante el
parámetro -s, para ello habría que ejecutar
#snort -d -l /log/snort -c snort.conf -s
Snort clasifica las alertas en 5 niveles de prioridad donde las de nivel 1 identifican las alertas de
seguridad más serias y las de nivel 5 las menos significativas.
Si se desea usar esta herramienta como IDS continuo, lo normal será ejecutarlo como un
servicio o daemon del sistema y automatizar su puesta en marcha en el arranque del sistema. Para
lanzar Snort como servicio hay que utilizar el parámetro -D con cualquiera de las combinaciones
de parámetros vistas anteriormente. Por ejemplo:
Snort tiene tres modos básicos de funcionamiento que se pueden configurar mediante el pará-
metro -Q, que son:
Inline: en este caso Snort permite el uso de reglas de tipo drop que causarán el rechazo de
aquellos paquetes que disparen la alerta. En este modo Snort es también una herramienta
de prevención de intrusiones o IPS, ya que puede reaccionar ante los ataques detectados.
Passive: este es el modo IDS, en el que las reglas de tipo drop no son cargadas.
Inline-Test: este modo de funcionamiento simula el modo Inline, permite la evaluación de
las reglas drop pero no afecta al tráfico.
El fichero snort.conf contiene la configuración particular con la que se desea lanzar Snort como
IDS. Este fichero contendrá muchos parámetros, quizás los más relevantes son los referentes a
las reglas que se aplicarán sobre el tráfico capturado. Dichas reglas se basan en las firmas o
signatures de ataque para detectar las amenazas. Para evitar tener un fichero de configuración
enorme y difícil de mantener, se permite incluir otros ficheros por medio de la orden include.
De esta forma se podrán generar diferentes diferentes ficheros de reglas que posteriormente se
podrán insertar en el archivo snort.conf, por ejemplo:
include /etc/snort/rules/name.rules
Las reglas de Snort son el corazón del IDS, son las que van a tratar de identificar huellas o
patrones de tráfico que correspondan a actividad sospechosa y generar las alertas o acciones
necesarias. A continuación se muestra de ejemplo una regla que trata de localizar paquetes en
cuyo contenido están los datos “00 01 86 a5”:
54
alert tcp any any -> (content:”|00 01 86 a5|”; msg:”mounted access”;)
Lo primero que indica la regla es la acción a realizar. En la regla del ejemplo se indica la acción
alert, pero esta no es la única disponible. Algunas de las posibles acciones son:
alert: genera una alerta que se incluye en el registro de alerta seleccionado y además guarda
en el registro los paquetes que han provocado la alerta.
log: guarda registro de los paquetes.
pass: ignora el paquete.
drop: bloquea el paquete y lo guarda en el registro.
Sensor Sguil
Sensor Sguil
Se accede a esta información desde terminales de escritorio por medio del cliente Sguil, el
cual es multiplataforma.
Para que los sensores Sguil sean capaces de capturar el tráfico de su segmento de red, de-
berán estar conectados o bien a un concentrador (hub) o bien a un conmutador que haya sido
configurado para enviar copia de todos los paquetes de datos que pasen por él al puerto en el
que esté conectado el sensor. Cada uno de estos sensores utiliza diferentes herramientas para
monitorizar el tráfico y obtener la información necesaria:
55
Sguil hace uso de Snort para obtener alertas de seguridad y/o intrusión.
Sguil integra también SANCP (Security Analyst Network Connection Profiler), una herramien-
ta que permite obtener información estadística del tráfico analizado, para obtener datos de
sesiones TCP.
Una segunda instancia de Snort se encarga de recolectar copias de todos los paquetes que
pasan por el sensor (funciones de sniffer de Snort).
Gracias a tcpflow es capaz de reconstruir datos de la capa de aplicación.
Gracias a P0f es capaz de analizar las huellas del tráfico TCP/IP y detectar así el sistema
operativo de los integrantes en la comunicación.
Una instancia de MySQL guarda toda la información obtenida por Snort.
La aplicación cliente permite conectar con cualquier servidor Sguil por medio de su dirección IP.
Sguil utiliza Snort como su fuente principal de alertas de seguridad. La novedad principal que
presenta es que muestra dichas alertas a través de su interfaz gráfico.
La ventana principal de Sguil muestra las alertas registradas por Snort, y dichas alertas se
actualizan en tiempo real conforme Snort registra nuevos riesgos de seguridad. Las alertas se
presentan en la mitad superior, divididas en tres niveles. El primer nivel recoge las alertas más
severas, el central las de menor riesgo y el inferior a las menos severas. Estos niveles se corres-
ponden con los niveles de prioridad de Snort. La parte inferior se divide a su vez en dos mitades.
En la parte izquierda puede mostrar diferente información sobre la alerta que se haya seleccio-
nado. En la parte derecha, dependiendo del tipo de paquetes capturados que hayan provocado
la alerta, la información será diferente. Además en esta parte se muestra un botón (snort.org) que
si se pulsa nos llevará a la url correspondiente a la documentación sobre la alerta seleccionada
en el sitio web de Snort.
Si se pulsa con el botón derecho del ratón sobre una de las alertas, se abrirá un nuevo menú
con las siguientes opciones:
Historia del evento (Event History): muestra cualquier comentario o estado de validación
de la alerta que le haya asignado un analista al revisar las alertas capturadas por Sguil.
Transcripción (Transcription): si es posible generará una transcripción completa de la sesión.
Esto puede ser especialmente útil para sesiones de protocolos en texto plano sin cifrar,
como pueden ser Telnet, SMTP, etc. En la transcripción se podrá ver la interacción completa
entre el atacante y la máquina objeto del ataque.
Forzar nueva transcripción (Transcript - Force New): regenera la transcripción generada an-
teriormente. Es útil cuando se genera una transcripción de una sesión todavía abierta.
Ethereal: abre la aplicación Ethereal la cual muestra los paquetes que han generado la alerta
y que han sido capturados.
Forzar nuevo Ethereal (Ethereal - Force New): permite indicar a Ethereal que debe inspeccionar
los nuevos paquetes originados en una sesión abierta.
El objetivo de toda esta información adicional sobre el ataque es que el analista de seguridad
pueda determinar las acciones del atacante, y así entender los pasos de dicho ataque. El objetivo
final es que el analista sea capaz de tomar decisiones gracias a dicha información.
11.4. Honeypots
Este término hace referencia a un equipo “falsificado”, en el sentido que desde el nombre
hasta los procesos del sistema, pasando por todas las cuentas de usuario y de todos los ficheros
de datos, está modificado para capturar información de los atacantes.
Quizás lo más adecuado es decir de estos sistemas que son señuelos usados para obtener da-
tos sobre el comportamiento de intrusos. Normalmente estos señuelos parecen contener vulnera-
bilidades. Mediante este método, los administradores pueden recoger datos sobre la identidad,
el acceso usado y los métodos de ataque utilizados.
56
Todo el conocimiento obtenido de esta manera se puede usar para prevenir ataques sobre los
sistemas reales en producción, así como para conseguir que los recursos del atacante se empleen
en sistemas señuelo.
Las ventajas obtenidas suelen ser:
Parar los ataques. Habrá menos atacantes que invadan una red diseñada para monitorizar
su actividad con detalle.
Detectar ataques. Al no ser máquinas en producción sino señuelos, cualquier actividad
sobre ellos será considerada sospechosa, ya que nadie de la organización trabajará contra
dicho sistema.
Educar sobre los métodos usados para atacar sistemas.
Detectar ataques internos, pues se puede ubicar en redes internas.
Crear confusión, pues los datos falsos de los honeypots suelen confundir a los atacantes.
Cuanto más integrado en la red se tenga, más ventajas se obtendrán. Múltiples expertos defien-
den que se ubique en la red interna, pues con ello:
Se pueden aprovechar mejor los registros de operación del encaminador o del cortafuegos.
Se puede configurar el encaminador o cortafuegos para que envíen una alerta al adminis-
trador cuando alguien se conecte al señuelo.
Es más sencillo configurar cualquiera de los dos tipos de equipos para proteger la red real
en caso de resultar gravemente afectado el señuelo.
El sistema debe tener un nombre atractivo, debe tener varios niveles de log, incluyendo siempre
una copia a la que le sea imposible de acceder al atacante. Otro nivel de log interesante es poner
un sniffer en el segmento del señuelo. Este sniffer puede ser a su vez un IDS como Snort, que
además ayude a identificar los patrones de ataque usados sobre el honeypot.
Para ayudar a entender el nivel de ataque conseguido suele guardarse una imagen de los
binarios del sistema.
Una vez el señuelo ha sido realmente comprometido, suele ser interesante pararlo y volver a
colocarlo, pero con nuevas vulnerabilidades, para aprender nuevas técnicas de ataque.
Podemos presentar distintas categorías en las que habitualmente se clasifican los sistemas
honeypots:
Honeypots de baja interacción: estos son los más sencillos de instalar y configurar ya
que proporcionan una funcionalidad muy básica. Este tipo de honeypots emulan una serie
de servicios y el atacante puede simplemente interactuar con dichos servicios emulados.
El principal valor que nos reportan este tipo de honeypots es la detección de escaneos
de puertos o de intentos no autorizados de conexión. Son las soluciones que suponen
un menor riesgo pero también son los que menos información sobre el intruso obtienen.
Están orientados a capturar comportamientos de intrusión conocidos, y no son válidos
para tratar de descubrir nuevos métodos y técnicas de intrusión. También son útiles con
fines estadísticos.
Honeypots de interacción media: este tipo de soluciones tienen más capacidad de inter-
acción con el intruso. Están diseñados para dar cierta respuesta y pueden llegar a simular
algunas vulnerabilidades conocidas o el comportamiento de algunos servidores. Cuanto
más realista es la funcionalidad, más fácil será que el intruso pueda penetrar más allá del
honeypot. Las soluciones integradas en este grupo pueden conseguir bastante más informa-
ción que las del grupo anterior. Se puede incluso llegar a capturar el código de algunos
gusanos, las actividades de nuestro atacante, descubrir la forma en la que el atacante acce-
de a nuestro sistema, etc.
Honeypots de alta interacción: estos son los que nos van a proporcionar la mayor cantidad
de información sobre el atacante y sus métodos. Son los sistemas que implican un mayor
nivel de riesgo, ya que lo que presentamos al intruso es un sistema real con el que inter-
actuar, nada es simulado. Podemos descubrir nuevas herramientas usadas por los intrusos
57
e identificar nuevas vulnerabilidades. Lo único que diferencia estos sistemas de sistemas
reales es que en los honeypots no hay ningún tipo de información relevante. También supo-
nen el caso de mayor riesgo, ya que si el sistema es comprometido, puede llegar a ser usado
como una plataforma sobre la que lanzar nuevos ataques. Por ello, este tipo de soluciones
se suelen implantar en sistemas muy controlados, evitando que el sistema pueda llegar a
ser usado para atacar otros sistemas.
El concepto de honeynet es una red en la que todo el tráfico entrante y saliente se analiza y se
cataloga. Dentro de la red se establecen distintos sistemas de producción estándar, que propor-
cionan servicios reales. En el futuro podrían estar integradas en una red real en producción,
haciéndolas más difíciles aún de detectar. En última instancia, una honeynet no es otra cosa que
una combinación de varios honeypots funcionando de forma conjunta a través de la red.
El proyecto de honeynet tiene dos objetivos concretos:
Adelantarse al uso real de amenazas y vulnerabilidades que se usan en Internet.
Formar e informar a la comunidad de profesionales de seguridad.
Se puede hacer otra clasificación distinta en función del tipo de máquina sobre el que se va a
poner en marcha el sistema honeypot.
Honeypots físicos: estos sistemas corren sobre una máquina física. Normalmente suelen
ser soluciones de alta interacción.
Honeypots virtuales: se pueden instalar sobre una máquina física una serie de máquinas
virtuales e instalar las soluciones honeypots sobre las mismas. Esto va a permitir tener varios
honeypots distintos sobre la misma máquina física. Este tipo de estructuras van a permitir
escalabilidad, así como economizar en los recursos disponibles para poner en marcha el
sistema.
58
indexado por los buscadores. Para que este servicio no pueda ser encontrado accidentalmente
por visitantes legítimos, GHH queda oculto tras un link invisible que sólo los rastreadores de
los buscadores pueden encontrar. GHH se instala sobre un servidor Apache, y automáticamente
detecta cómo se ha encontrado el sitio web peticionado y por tanto puede evitar registrar el
tráfico de visitantes legítimos. Adicionalmente GHH detecta si ha sido encontrado por alguna
búsqueda maliciosa.
Otro proyecto de software libre para UNIX/LINUX es Honeyd, posiblemente el honeypot de
baja interacción más versátil que se puede encontrar. Permite crear una serie de máquinas vir-
tuales en la red, las cuales pueden ser configuradas para simular que están ofreciendo diferentes
servicios, así como diferentes sistemas operativos. Honeyd es altamente configurable:
Permite asumir tantas direcciones IP no usadas como se desee.
En una misma máquina física se puede llegar a crear cientos de máquinas virtuales simu-
ladas.
Cada máquina virtual puede asumir una personalidad diferente.
Uno muy especial es Honeynet, un proyecto dedicado al estudio de los distintos ataques a redes.
Honeynets son Honeypots de alta interacción. La idea es sencilla: construir una red con varios
servidores funcionando exactamente igual que los que se pueden encontrar en cualquier orga-
nización. Lo habitual es poner en marcha estos sistemas detrás de un método de control de
acceso, como puede ser un cortafuegos y esperar a ver qué intentos de intrusión recibe. Al ser
sistemas completos, estos pueden ser reconocidos, atacados y explotados completamente. Ho-
neynet proporciona todas las funcionalidades de los honeypots pero es mucho más: esta solución
permite capturar tanto las amenazas conocidas como las desconocidas, lo que lo convierte en
una estupenda herramienta de investigación para determinar quiénes son los atacantes, qué he-
rramientas usam, qué tácticas emplean e incluso cuáles son sus motivaciones. Hay tres aspectos
fundamentales en una arquitectura Honeynet:
1. Control de datos: este aspecto es el que va a mitigar el riesgo que una honeynet supone. Los
equipos que componen la honeynet pueden ser completamente comprometidos. Por ello es
necesario establecer un sistema que nos permita evitar que las máquinas comprometidas
puedan ser utilizadas para lanzar ataques contra otros sistemas. Es necesario automatizar
el control de datos y no hacerlo depender de una intervención manual que pueda llegar
demasiado tarde. Se puede, por ejemplo, limitar el número de conexiones salientes a un
cierto número por día, asegurándose que la máquina comprometida no va a poder ser
usada para lanzar ataques de denegación de servicio.
2. Captura de datos: otro aspecto fundamental es el conseguir capturar toda la actividad del
intruso sin que este se de cuenta de que se encuentra en una honeynet.
3. Recogida de información: cuando se despliegan varias honeynets en diferentes redes, será
necesario recopilar dicha información de forma centralizada y agregarla.
Finalmente citaremos a Argos, un nuevo tipo de honeypot virtual de alta interacción desarrollado
para sistemas UNX/LINUX. La novedad que supone es que es capaz de detectar ataques para
los que todavía no existe ningún parche. Argos permite ejecutar máquinas virtuales, pero con
la peculiaridad de que mantiene estrechamente monitorizadas dichas máquinas virtuales para
determinar el punto exacto en el tiempo en el que el honeypot ha sido comprometido. Argos
monitoriza el flujo de datos tratando de encontrar el punto en el que el intruso lanza el ataque
real. Asume que en un ataque real se tratará de rebosar el buffer (buffer overflow), por lo que
se suministrará un script que sea capaz de sobrescribir determinadas áreas de la memoria en-
viando datos malformados. Cuando un ataque es detectado, Argos realiza una descarga de la
información de la memoria y es capaz por tanto de registrar la huella del ataque.
59
12. Diseño seguro de redes: alta disponibilidad y redundancia
12.1. Introducción
En los entornos de red actuales un factor que hay que tener en cuenta es el de la alta dispo-
nibilidad de las redes y de los servicios que éstas ofrecen. En este entorno las técnicas de alta
disponibilidad van haciéndose un hueco como soluciones necesarias.
Se podría pensar que el 99 % del tiempo del año funcionando es suficiente, pero el 1 % del
tiempo del año no funcionando significa 83 horas al año. Cuando se habla de alta disponibilidad
se habla de “los tres nueves” (99,999 % del tiempo funcionando), lo que quiere decir un tiempo
de caída permitido de 5 minutos al año. Existe una medida estándar del nivel de disponibilidad
de un dispositivo cualquiera, que se puede expresar como:
TMEF
Disponibilidad =
TMEF + TMR
siendo TMEF el Tiempo Medio Entre Fallos y TMR el Tiempo Medio de Reparación. Tal nivel
de disponibilidad requiere tratar de evitar una serie de posibles problemas lógicos, físicos y
organizativos:
Entre los problemas lógicos a tratar de evitar están:
Se va a utilizar como marco de referencia el modelo OSI, para poder seguir un método en la
discusión empezando por analizar los problemas del nivel físico y subiendo por el modelo de
capas hasta llegar al nivel de aplicaciones.
60
Si se han completado las tres fases anteriores, hay que poner la gente que administrará la
nueva situación. Hay que tratar de construir una infraestructura de administración robusta
e intuitiva.
Una vez se ha completado el ciclo, se identifica otra tecnología y se vuelve a empezar. Si se quiere
seguir siendo competitivo, el ciclo no puede parar y la red debe estar disponible permanente-
mente. Así pues, las soluciones que proporcionan alta disponibilidad sin hacer mucho mayor la
complejidad de la red son soluciones interesantes.
Desde el punto de vista de la alta disponibilidad, se suele introducir el concepto de Ad-
ministración de Niveles de Servicio. Estos niveles sirven para enlazar, con un cierto punto de
vista nuevo, la tecnología con el proceso de negocio. La parte más importante de todo este reto
es el mantenimiento de la alta disponibilidad de las redes. Para crear una red de este tipo, el
administrador de red suele tener que utilizar herramientas de prácticamente todos los niveles
del modelo OSI (Figura 6).
61
Redundancia de dispositivos físicos. Por ejemplo, dos o más encaminadores proporcio-
nando los mismos servicios a los mismos usuarios.
Agregación de enlaces. Mediante protocolos como el IEEE 802.3ad, el cual da redundancia
en el sentido de que si falla un enlace, el resto continua pasando datos aunque sea a una
velocidad menor.
Otro aspecto de la redundancia es el de la trayectoria redundante de los datos. La capacidad
de proporcionar varios caminos de datos redundantes está distribuida por todos los niveles del
modelo OSI.
62
Otro protocolo con un objetivo parecido es HSRP (Hot Standby Router Protocol), desarrollado
por Cisco. En este caso el protocolo establece un encaminador por defecto de alta disponibili-
dad. HSRP envía mensajes multicast del tipo hello a una dirección concreta (224.0.0.2 ó 224.0.0.102)
usando el puerto 1985 a todos los otros encaminadores HSRP, para definir la prioridad de los
encaminadores. El encaminador con una prioridad configurada más alta actuará como enca-
minador virtual y responderá a la petición ARP de las máquinas conectadas a la LAN. Si este
encaminador falla, el siguiente de prioridad más alta tomaría el lugar del anterior, consiguiendo
así un failover transparente del encaminador por defecto.
63
Discos RAID. Son una solución usada en casi todos los subsistemas para proporcionar
mejor disponibilidad de los datos, tanto en términos de protección como de acceso.
Replicación de los datos. Esta técnica se utiliza para protegerse contra un fallo del subsis-
tema de almacenamiento completo. Puede realizarse dentro de un centro de datos local
o a largas distancias. En cualquiera de los dos casos el resultado final es que se tienen
dos subsistemas de almacenamiento independientes, cada uno de ellos con una copia en
tiempo real de los datos.
La conectividad con el subsistema de almacenamiento es casi tan importante como su propia
integridad. La manera mediante la cual se tiene el acceso a la información almacenada es crucial.
En este caso se puede señalar una característica clave:
Interfaces redundantes. Cada unidad lógica de disco debe estar accesible a través de varias
interfaces.
La redundancia hardware del subsistema implica cuestiones ya previamente analizadas que se
pueden resumir:
Redundancia de la alimentación.
Redundancia de controladores. Este tipo de soluciones disponen de doble controladora de
forma que en el caso de que una de ellas falle la otra pueda seguir suministrando acceso a
los datos.
Conveniencia de tener discos preparados para el caso de que un disco físico falle, de ma-
nera automática, en caliente.
El proceso basado en LAN, que usa una interfaz LAN de cada cortafuegos y un conmuta-
dor entre ambos, evitando así la limitación de distancia anterior.
Además se habla de dos tipos de proceso de recuperación con respecto a la capacidad de recu-
peración:
Proceso de recuperación normal. En este caso, las conexiones TCP que hubieran se pier-
den, obligando a las aplicaciones a volver a conectarse. No existe una pérdida cero de
conectividad.
Proceso de recuperación completa. Éste método permite el mantenimiento de toda la in-
formación de estado de las tablas de conexión de los cortafuegos, por lo que no se pierde
ninguna conexión y no hay necesidad de reconexión.
64
13. Introducción a la criptografía como herramienta de seguri-
dad en redes
13.1. Introducción
El término criptografía significa “escondido”. El objetivo de la criptografía es ocultar el sig-
nificado del mensaje, lo que se realiza mediante el cifrado o encriptación del mismo.
Se dividen las técnicas criptográficas generales en dos ramas:
La transposición, en la que las letras de un mensaje se colocan de una manera distinta a la
original.
La sustitución, en la que se sustituyen unas por otras.
El criptoanálisis es la técnica que consiste en descubrir los mensajes cifrados.
En este tema se va a hacer una descripción de los aspectos más importantes de la aplicación
de esta disciplina a la seguridad en las comunicaciones y redes.
Hoy en día, para trabajar con el nivel de seguridad que permite la criptografía, hay que usar
protocolos como SSL, que asegura las conexiones web, o IPSec, conjunto de protocolos estándar
de Internet, que aseguran el tráfico IP por Internet. Hay que conocer asimismo otros protocolos
de seguridad como ssh.
Tales protocolos están construidos usando algoritmos criptográficos. Estos algoritmos son
construcciones matemáticas que transforman los mensajes que se desea asegurar.
65
1. Funciones de una sola vía (hash). Permiten mantener la integridad de los datos. Se utilizan
como parte de los mecanismos de lo que se denomina firma digital.
2. Algoritmos de clave secreta o de criptografía simétrica. Permiten mantener la privacidad,
o confidencialidad, de los mensajes o textos almacenados una vez cifrados por alguno de
estos métodos.
3. Algoritmos de clave pública o de criptografía asimétrica. Se emplean principalmente
para la autenticación de documentos, textos o mensajes mediante certificados digitales y
las firmas digitales.
He aquí algunas de las preguntas típicas que se suelen hacer para decidir la longitud de las
claves de los sistemas criptográficos:
¿A cuántos mensajes se va a aplicar la misma clave y con qué frecuencia? Si la clave se va
a reutilizar mucho está más expuesta a un ataque, luego debería ser más larga.
¿Cuál es el perjuicio (y cuánto) ocasionado por un atacante que se haya hecho con la clave?
En general, cuanto más larga la clave, más segura, luego si el perjuicio posible es grave,
debería ser larga también.
¿El contenido del mensaje debe ser mantenido en secreto mucho tiempo? Si es éste el caso,
la clave debe ser larga.
Una combinación de ambas técnicas: la idea es disponer de “lo mejor de los dos mundos”,
haciendo las labores más repetitivas mediante hardware y aquellas más especiales desde
un programa.
El proceso criptográfico de las comunicaciones de datos tiene lugar siempre en una de las tres
siguientes localizaciones:
En una aplicación. La aplicación procesa los datos y deja los resultados en disco para otro
proceso informático, que los vaya a usar.
En el protocolo de transporte. En este caso, el propio protocolo de transporte implementa
directamente el proceso criptográfico.
Por el propio medio de transporte. El proceso es llevado a cabo por el propio medio de
transporte, por ejemplo, por un cableado especial.
Se suele hablar, en el caso de protocolos IP, de cuatro localizaciones típicas:
66
Criptografía a nivel de aplicación. El cifrado y descifrado se hace por un programa sepa-
rado del que proporciona el transporte de red o por el mismo programa. PGP y ssh.
Criptografía entre procesos. La aplicación escribe el mensaje a un proceso intermedio
entre ella y el protocolo de transporte, en inglés conocido como IPC. Este método está
como “encajado” en la metodología de la aplicación. SSL.
Criptografía de protocolo transparente. Una serie de protocolos IP especializados se utili-
zan para transportar los mensajes, tras cifrarlos y viceversa.
Un buen sistema criptográfico es bastante inmune, se podría decir que matemáticamente inmu-
ne, a casi cualquier tipo de ataque. El problema reside en el ser humano y, más concretamente, la
administración del sistema de seguridad que hace en las redes donde se aplican estos sistemas.
67
14. Métodos criptográficos: sistemas de clave privada, sistemas
de clave pública y funciones de una sola vía
14.1. Introducción
Los algoritmos criptográficos son las piezas básicas con los que se construyen primero los
protocolos y, después, los sistemas criptográficos completos.
Este libro pretende describirlos, definirlos, ver sus ventajas y sus inconvenientes y hacer una
relación de los protocolos y sistemas típicos donde se utilizan.
El tema comienza presentando los algoritmos de criptografía simétrica, llamada también de
clave secreta o de clave privada.
Se analizan después las funciones de una sola vía (hash). Se pueden usar para mecanismos
de almacenamiento seguro de contraseñas de cuentas de acceso a sistemas operativos o a redes,
o como piezas imprescindibles en el mecanismo de la firma digital.
Finalmente el tema presenta los algoritmos de criptografía asimétrica o de clave pública. La
revolución de éstos consistió en hacer desaparecer del todo la necesidad de que, como sucede
en otros métodos criptográficos, haya que compartir una clave para poder cifrar y descifrar
mensajes entre origen y destino.
68
es un bloque de 64 bits de datos legibles y la salida de datos correspondiente es un bloque de
datos de 64 bits de datos cifrados.
La longitud de la clave en DES es de 56 bits. Se expresa como un número de 64 bits pero
cada octavo bit se usa para chequeo de paridad.
Utiliza una red de Feistel de 16 iteraciones y dos permutaciones, inversa una de la otra, que
se aplican al principio y al final del proceso.
El único problema real de DES es la longitud de su clave, 56 bits, que resulta claramente
corta frente al avance actual de la velocidad de cálculo de los ordenadores, lo que hace factible
un ataque de tipo “fuerza bruta”.
Han ido apareciendo distintas variantes del algoritmo. La más utilizada con diferencia es la
conocida como Triple DES, ilustrada en la Figura 7.
Otro algoritmo de clave simétrica muy importante es el AES (Advanced Encryption Standard).
Entre sus características principales se deben citar:
No es de tipo Feistel.
Tiene un tamaño de clave variable, siendo el estándar de 256 bits.
Su diseño se ha realizado pensando en su funcionamiento en los procesadores de 8 bits de
las tarjetas inteligentes y en las CPU de 32 y 64 bits.
El tamaño del bloque de texto de entrada del proceso es de 128 bits o un múltiplo de 4
bytes.
El número de etapas es flexible.
69
Colisión simple. Conocido el texto original, T, será computacionalmente imposible obtener
otro texto, T’, tal que el resumen de T y el de T’ sean el mismo.
Un hash es algo así como una huella dactilar digital, sirve para identificar algo mucho mayor.
Cualquiera podría calcular el hash de este libro, pero dado el hash de este libro, es imposible
crear otro libro cuyo hash tenga el mismo valor, o derivar, del hash de este libro, el texto original.
Estas funciones son además públicas. Su seguridad no reside en el proceso, sino en la natu-
raleza, de un solo camino, del proceso.
Su uso más habitual es el de garantizar la integridad, por ejemplo para garantizar que un
fichero no ha sido modificado. Si se quiere verificar que alguien tiene el mismo fichero, bastará
con pedir que se calcule el hash, ambos resúmenes deben ser idénticos.
En general, se usan funciones de una sola vía sin clave, para que cualquiera pueda verificar
el hash, pero si esta propiedad no es deseada, se puede utilizar también funciones de una sola
vía que dependen de una clave. Se habla entonces de código de autenticación de mensaje o
MAC (Message Authentication Code). En este caso, el valor del hash es una función tanto del texto
original como de la clave. La teoría es exactamente idéntica a lo anterior.
Todas las funciones de una sola vía se basan en la idea de una función de compresión, que
provoca un resumen de longitud n, dada una entrada de longitud mayor m.
Los datos de entrada a la función de compresión son un bloque del mensaje del que se quiere
obtener el resumen, M (i ), y el resumen de salida, h(i − 1), del proceso de los bloques previos de
texto. La salida de datos, h(i ), es el hash de todos los bloques hasta el punto analizado.
Este valor de resumen, junto con el siguiente bloque del mensaje, se convierte en la siguiente
entrada de datos de la función de compresión. Finalmente, el hash del mensaje completo es el
hash del último bloque. Los dos algoritmos de una sola vía más utilizados hoy en día son el MD5
y el SHA-1.
Con MD5, tras un procesado inicial, se divide el texto de entrada en bloques de 512 bits,
divididos en 16 sub-bloques de 32 bits. El resultado de la ejecución del algoritmo es un conjunto
de 4 bloques de 32 bits, que se concatenan para formar el resumen final de 128 bits.
Lo primero que se hace es ajustar el mensaje para que su longitud resulte 64 bits más pequeña
de un múltiplo de 512. Este ajuste es un solo bit a 1, añadido al final del mensaje, seguido de
todos los ceros que sean necesarios. Después se añade al resultado una representación de 64 bits
de la longitud del mensaje y se inicializan 4 variables:
A = 0x01234567
B = 0x89abcde f
C = 0x f edcba98
D = 0x76543210
70
14.4. Algoritmos de clave pública o de criptografía asimétrica
En esencia, la criptografía asimétrica consiste en lo siguiente:
Cada participante genera una pareja de claves relacionadas entre sí. Una es la denominada
clave pública del participante y la otra es la denominada clave privada. Deducir la privada
conociendo la pública debe ser computacionalmente muy complicado.
Un ejemplo típico de uso de sistemas criptográficos asimétricos es la firma digital. Las firmas
digitales proporcionan un nivel de autenticación de mensajes parecido al de los MAC citados en
la sección anterior.
La forma más sencilla de conseguir una “firma digital” mediante cifrado asimétrico consiste
en los siguientes pasos:
1. El participante A tiene un mensaje que quiere enviar a otra serie de participantes, incluido
el participante B.
2. El participante A cifra el mensaje mediante su clave privada. Como ésta es sólo suya, el
propio mensaje cifrado es la firma del participante A.
3. La clave pública del participante A es conocida por todo el mundo. Cualquiera puede
descifrar el mensaje verificando, asimismo, que el participante A lo firmó.
De esta manera, la firma es función del mensaje. La firma cambia si se cambia el mensaje. Un
atacante no puede “obtener” la firma de una mensaje y “pegarla” en otro documento.
Esto es sólo una aproximación teórica sencilla. No se cifran los mensajes mediante estas
técnicas y no se “firman” los mensajes así. Como se verá en el siguiente tema, se firma el hash
del mensaje.
De entre todos los algoritmos asimétricos el más popular es el algoritmo RSA. Hoy en día su
uso es prácticamente universal como método de autenticación y firma digital y es componente
principal de protocolos y sistemas como IPSec, SSL, PGP, etc.
El método de obtención de una pareja de claves pública y privada (K, K’) es el siguiente:
71
1. Se eligen aleatoriamente dos números primos grandes, p y q.
2. Se calcula el producto N = pq.
1
d=
e mód (( p − 1)(q − 1))
La clave K’ es la pareja de números (d, N ). Hay que señalar que si se desconocen los
factores de N, este cálculo resulta prácticamente imposible.
El cifrado, C, de un mensaje M se hace mediante la siguiente expresión:
C = Me mód N
M = Cd mód N
Un ejemplo ayudará a entenderlo mejor. Supóngase que Bernardo quiere enviar un mensaje
a Alicia. ¿Cómo genera la pareja de claves Alicia?
1. Elige dos números primos enormes, p = 17 y q = 11, que mantiene en secreto. Calcula su
producto, N = 187.
Ahora Bernardo decide que va a enviar el mensaje “XANA” a Alicia. Primero lo divide en
bloques, uno por carácter. Se explora lo que hace el método para el primer carácter, X. El carácter
X se representa en ASCII como 1011000, que es 88 en el sistema decimal, así que para este
ejemplo, M es igual a 88.
Bernardo usa la clave pública de Alicia, K, y obtiene que C = 11.
Cuando el mensaje llega a Alicia, ésta debe descifrar cada dígito y empieza por el primero
que le llega que es el 11. Para ello usa su clave privada, (23, 187) para obtener que M = 88, que
como ya se ha visto, representa la X en ASCII.
Desde el punto de vista técnico no se ha demostrado que no pueda aparecer un método que
permita descifrar un mensaje sin usar la clave privada y sin factorizar el módulo N.
Otro algoritmo asimétrico fundamental para los sistemas actuales de seguridad, para IPSec,
es el algoritmo conocido como de Diffie-Hellman. El algoritmo de Diffie-Hellman tiene como
objetivo generar una clave secreta para el uso de un algoritmo de cifrado simétrico, por ejemplo
DES, pero sin necesidad de intercambiar la clave y utilizando para ello, si fuera necesario, un
canal de comunicación inseguro como Internet.
Dos participantes generan, independientemente y sin intercambiársela, la misma clave secreta
de uso para cifrar un mensaje. Se dice que “se ponen de acuerdo” en una clave.
El aparato matemático es simple, está basado en la función de una sola vía N x mód P. El
procedimiento es el siguiente:
1. Los dos participantes se ponen de acuerdo en dos números primos grandes, N y P, tal que
N es menor que P.
2. El participante A elige al azar un número entero grande, x, y envía Z = N x mód P al
participante B.
72
3. El participante B elige, de igual manera, otro número, y, y envía W = N y mód P al
participante A.
4. El participante A calcula k = W x mód P.
7x mód 11
73
15. Certificación, autenticación e integridad de la información.
Firma digital y PKI
15.1. Introducción
En la actualidad, y especialmente para el tráfico que atraviesa redes inseguras como Internet,
es normal que se busque asegurar, más aún que la privacidad, la autenticación, la integridad y
otras propiedades como el no repudio.
Se retoma el concepto de firma digital. Este tipo de sistemas de firma digital, basados en la
clave pública de cada uno de los participantes, necesitan alguna forma segura de certificación de
tal clave pública. Esto ha hecho introducir distintos estándares, de los cuales el más significativo
es el X.509.
En este modelo, cada participante tiene un certificado X.509 que certifica su identidad. ¿Quién
garantiza al resto de los participantes que ese certificado es válido? Aquí aparecen las Autorida-
des de Certificación (AC).
Si el emisor niega haber enviado un mensaje, ¿cómo comprueba el receptor que el men-
saje que le ha llegado es realmente del emisor? Se habla aquí de no repudio del emisor.
El emisor debe asumir todas las responsabilidades derivadas de la información que ha
enviado.
Si el receptor niega haber recibido un mensaje, ¿cómo comprueba el emisor, que ha enviado
el mensaje al receptor, que efectivamente se envió? A esto se le denomina no repudio del
receptor.
Para conseguir todas estas propiedades se utilizan varias combinaciones de algoritmos cripto-
gráficos asimétricos y funciones de una sola vía y casi todas ellas pasan por la utilización de
firmas digitales.
Esencialmente, se necesita introducir una tercera figura, a la que podemos llamar Fiador, que
mantiene una clave privada, dentro de un sistema de criptografía simétrica, para cada partici-
pante del sistema.
En el caso en que Alicia desee enviar un mensaje a Bernardo, los pasos que se siguen con
este esquema son los siguientes:
1. Alicia encripta el mensaje M utilizando la clave Ka, obteniendo C (Ka( M )), y lo envía al
Fiador.
2. El fiador comprueba la integridad de Alicia, desencripta el mensaje para obtener M y, en-
criptándolo con Kb, envía a Bernardo tanto el mensaje M como la identidad de Alicia y la
“firma” C (Ka( M )), C (Kb( M, A, C (Ka( M )))).
Como tanto Alicia como Bernardo confían en el Fiador, el procedimiento es seguro. En el caso de
que la clave del algoritmo simétrico sea segura, se puede afirmar que, además de la privacidad,
se obtiene a la vez la integridad y autenticidad del mensaje, ya que es únicamente el ususario
emisor el que puede crear ese mensaje.
Lo que no se puede alcanzar con este método es la doble autenticación de mensaje y emisor.
Otra aproximación a este problema es hacer que el Fiador sea un KDC, Key Distribution
Center, una especie de distribuidor de claves de confianza que debe compartir una clave, que
suele denominarse maestra, con todos los participantes de este sistema. La tarea del KDC es
74
distribuir una clave de sesión. Tal clave de sesión está protegida, siguiendo el modelo, por la
clave maestra citada.
Un buen ejemplo de este modelo es el sistema Kerberos. En la actualidad, sólo está imple-
mentada la función de autenticación. En la red existe un servicio Kerberos, que actúa como algo
más que el Fiador de antes, proporcionando una autenticación segura en la red y permitiendo a
un usuario acceder a diferentes máquinas servidoras de la red. Habitualmente usa como algo-
ritmo simétrico el ya explicado DES, compartiendo una clave secreta diferente con cada entidad
de la red. Lo que demuestra la identidad (y autentica) es el conocimiento de tal clave secreta.
Para un usuario humano la clave secreta no es más que una contraseña. Al conocer Kerberos
todas las claves secretas puede crear mensajes que demuestren a una entidad la identidad de
otra entidad. Gestiona también la creación de claves de sesión, que se dan sólo a un cliente y a
un servidor, que sirven para cifrar la comunicación entre ellas y que desaparecen al acabar tal
comunicación.
Hay que tener en cuenta una serie de fases de autenticación:
La fase de obtención de credenciales, ya sean tickets o autenticadores.
La fase de petición de autenticación frente a un servicio con el que se desea establecer una
conexión.
La fase de presentación de credenciales al servidor.
Terminología típica del sistema Kerberos:
Hay en el sistema usuarios, clientes y servidores, personas o máquinas con necesidad de
autenticarse en la red controlada por Kerberos.
El principal es una entidad o cliente, que ha sido previamente autenticado por un servidor
de autenticación.
Un servicio es una entidad abstracta ofrecida por un servidor.
La información que se utiliza para autenticarse son las credenciales. El objetivo de las cre-
denciales es minimizar el número de veces que un usuario tiene que teclear su contraseña.
El modelo Kerberos mantiene dos tipos de credenciales distintas: los tickets y los autenticadores.
Un ticket, Tcs, es necesario para que la identidad del cliente pase, de una manera segura, del
servidor de autenticación al servidor final. Su información consta de:
Nombre del cliente que quiere conectarse.
Nombre del servidor con el que se desea conectarse.
Dirección IP del cliente.
Tiempo de validez del ticket.
Una clave de sesión para el cliente y el servidor, sea, por ejemplo, Kcs.
y va cifrada con la clave secreta del servidor.
Un autenticador, Acs, se genera cada vez que un cliente desea usar un servicio en el servidor.
Contiene la siguiente información:
Nombre del cliente.
La información temporal del momento de creación.
La dirección IP del cliente.
que va cifrada mediante Kcs.
El autenticador tiene dos propósitos. El primero es que, al contener texto legible cifrado con
la clave de sesión, demuestra que quien lo genera conoce tal clave. El segundo es que parte de
esa información es la fecha de creación. Un atacante que obtiene el ticket y un autenticador no
puede pretender repetirlos si no es muy rápidamente.
Cuando un cliente quiere conectarse a un servidor en la red tiene que dar los siguientes
pasos:
75
1. El cliente pide permiso al servicio Kerberos para conectarse al servidor.
2. Kerberos comprueba que este cliente puede conectarse al servidor.
3. Si es así, le envía un ticket, Tcs, que contiene la clave de sesión entre el cliente y el servidor,
Kcs, y que servirá para que el cliente le pruebe al servidor que es quien dice ser.
4. El cliente crea, con esta clave Kcs, un autenticador, Acs, que servirá para demostrarle al
servidor su identidad.
5. El cliente envía al servidor el ticket y el autenticador.
6. El servidor valida ambos datos y, si son correctos, permite la conexión del cliente.
Las contraseñas nunca viajan por la red, lo cual es una buena propiedad de seguridad. Sin
embargo, se necesita al menos un servidor Kerberos que puede convertirse en un cuello de botella.
Genera un hash del mensaje, H1, mediante una función de una sola vía.
Este hash H1 es cifrado con la clave privada del emisor y el resultado es lo que se conoce
como firma digital, FD, que se envía adjunta al mensaje.
Para comprobar la autenticidad e integridad del mensaje, el receptor realiza las siguientes ope-
raciones:
Si ambos resúmenes H1 y H2 coinciden, se puede afirmar que el mensaje ha sido enviado por el
propietario de la clave pública utilizada.
Es un mecanismo suficientemente seguro pero tiene un inconveniente. Todo sistema cripto-
gráfico de firma digital descansa sobre un pilar fundamental: la autenticidad de la clave pública
de cada participante. Si no se puede asegurar esta característica, en realidad se está ante una
más que probable situación de fraude. Para corregir este problema, se crearon los certificados
digitales.
76
15.4. La necesidad de certificación. El estándar X.509 y las autoridades de
certificación
Un certificado digital es un documento que certifica que una entidad determinada, como
puede ser un usuario, una máquina, un dispositivo de red o un proceso, tiene una clave pública
determinada.
Las nuevas preguntas son: ¿cómo se certifica? y ¿quién lo certifica? Hay que acudir al concep-
to de Autoridad de Certificación (AC), otra entidad, que suele ser un servicio en una máquina,
que emite y gestiona tales certificados, y que tiene una propiedad muy importante pero poco
matemática: se puede confiar en ella.
La forma en la que la AC hace válido al certificado es firmándolo digitalmente. Así, si B,
el receptor de un documento firmado por A, dispone de un certificado de A, bien porque A lo
adjuntó al enviar el mensaje, bien porque B lo tenía ya, y tal certificado está firmado por una AC
en la que ambos confían, A podrá autenticar el documento.
Una AC sería como una suerte de notario, un tercero del que todos los participantes se fían
para llevar a cabo la tarea citada. El certificado digital tiene un formato estándar conocido como
X.509. Un certificado digital X.509 tiene los siguientes campos:
Versión del formato del certificado, normalmente la versión X.509v3.
Número de serie del certificado, SN. Es un identificador numérico único dentro del domi-
nio de certificación de la CA.
Algoritmo de firma y parámetros, que identifican el algoritmo asimétrico y la función de
una sola vía usados para firmar el propio certificado.
Emisor del certificado, que es el nombre de la AC.
Fechas de inicio y de final de validez del certificado.
El nombre del propietario de la clave pública que aparece firmada en el certificado.
La información de identificación del algoritmo utilizado, la clave pública del usuario y una
serie de parámetros opcionales llamados extensiones del certificado.
La firma digital de la AC, es decir, el resultado de cifrar, mediante el algoritmo asimétrico
y la clave privada del AC, el hash obtenido del documento X.509.
Es muy importante señalar que cada navegador lleva ya instalados una serie de ellos.
El proceso habitual con que dos participantes, A y B, que confían en una AC, obtienen cada
uno sus certificados para poder autenticarse el uno al otro es el siguiente:
1. A y B generan una pareja de claves pública y privada. Las AC siempre podrán descifrar
todos los mensajes cifrados con las claves de que disponen.
2. A y B generan una petición de certificado y la envían a la AC.
3. La AC, una vez comprobadas las respectivas identidades, transforma las peticiones en
certificados digitales y envía, a A y B, dos certificados digitales a cada uno: el requerido
individualmente y el propio certificado digital de la AC, necesario más adelante en el
proceso de certificación.
4. A y B respectivamente, instalan su certificado digital y el de la AC.
Cuando más adelante A y B quieren autenticarse, se intercambian certificados digitales y com-
prueban su validez. A continuación se analiza el proceso en uno de ellos, por ejemplo en B:
1. B recibe el certificado de A.
2. Utilizando el método de la firma digital en recepción, comprueba que la firma es correcta.
Para ello necesita descifrar la firma digital del certificado recibido mediante la clave pública
de la AC.
3. Si la firma del certificado es correcta, debería comprobar si el periodo de validez es correcto
y si este certificado no está en la lista de revocación.
77
4. Si la firma es correcta, el periodo también y el certificado no está revocado, se acepta el
certificado y se considera autenticado.
¿Cómo puede B fiarse de que el certificado de la AC que tiene es correcto? La respuesta es
simple: el propio certificado digital de la AC lleva la clave pública de la AC y la firma digital de
la AC, que hay que recordar que está cifrada con la clave privada de la AC. Entonces, si se calcula
el hash del propio certificado de la AC se debe obtener lo mismo que al descifrar, mediante su
clave pública, la firma digital del certificado de la AC.
Son creadas por la AC, que las mantiene en cualquier sitio alcanzable y administrable por
la AC.
Cuando un participante no se fía de su clave pública, se lo comunica al AC, para que le
revoque el certificado y le genere uno nuevo, obviamente a partir de otra clave pública.
La AC debe, en ese momento, revocar tal certificado. Esto consiste en meterlo en la CRL.
Además, la CRL está firmada por el AC.
Si se busca en varios lugares, hay que distribuirla periódicamente.
Hay que recordar que la CRL se debe consultar cada vez que se va a usar un certificado para
comprobar que éste sigue siendo válido.
En cada certificado hay una extensión CRL que incluye el punto de distribución de la CRL.
En el lado de los participantes, hay que seguir siempre el mismo procedimiento de trabajo,
hay que almacenar certificados e información relacionada. Esta información es de tres tipos:
Certificados personales, de identidad del participante.
Certificados de AC y de AR.
78
Bastantes autoridades de certificación soportan mecanismos automáticos de petición y obtención
de certificados. Por ejemplo se puede citar el SCEP (Simple Certificate Enrollment Protocol).
El SCEP es un protocolo que opera entre el cliente y la AC. El proceso de petición de certifi-
cado es siempre el mismo, aunque el proceso de comprobación depende de si el certificado de
identidad se aprueba manualmente o de manera automática.
Mediante SCEP, el proceso tendría los siguientes pasos:
1. Envío de la petición de certificado de la AC a la AC. La AC envía un certificado propio.
2. El cliente SCEP verifica el certificado del AC, genera su pareja de claves, genera la petición
PKCS #10 de certificado propio y se lo envía a la AC.
3. La AC procesa la petición, incluyendo este paso el procedimiento de aprobación, genera
un certificado para el cliente y lo envía.
Además de decidir el sistema de PKI que se va a utilizar, una buena organización de autentica-
ción debe de tener en cuenta:
Una política de seguridad con respecto a la certificación, con su ámbito de actuación y
estructura claramente definida, así como sus relaciones con otras PKI.
Deberá estar clarísimamente definido el procedimiento de aprobación de certificados: cuán-
do puede ser automático, cuándo manual y en qué casos requerirá una seguridad mayor.
Deberá estar claramente definida la política con respecto a la lista de revocación de certifi-
cados.
Todas estas cuestiones hacen que la administración segura de una PKI sea algo especialmente
sofisticado y costoso.
79
El más evidente es el hecho de que no haya ninguna entidad u organización en la que todo
el mundo confíe y cuyo juicio sea inapelable.
Otro problema grave para este mundo del comercio por Internet, basado en el país, es el de la
unicidad del nombre del propietario del certificado. Al estar basada la identidad en tal nombre,
es fácil que haya problemas de identificación en el nombre como para diferenciar a todos los
“Juan García” posibles.
Otro problema es el relacionado con los sistemas (casi todos) que no tienen en cuenta correc-
tamente las listas de revocación de certificados (CRL). Si no se soportan en el sistema, ¿cómo
se revoca un certificado? y, si no se soporta tal revocación, ¿cómo se detecta que una clave haya
sido comprometida, para poder revocarla?
Los certificados digitales y las PKI hay que usarlos correctamente si se desea un cierto nivel
de seguridad y, en la actualidad, hay aún mucho trabajo que hacer en el campo de la confianza.
80
16. Protocolos criptográficos más habituales
16.1. Introducción
Un protocolo es simplemente un conjunto de mensajes, intercambiados entre dos o más
participantes. Todos los participantes deben conocer el protocolo y los pasos concretos que deben
dar en cada fase de ejecución. Debe ser también lo más completo posible, de manera que haya
definida una acción concreta para cada posible situación que se encuentre en su ejecución.
Un protocolo criptográfico es un protocolo que usa métodos criptográficos, independiente-
mente de que su objetivo final vaya más allá de lo que estos permiten conseguir.
Los sistemas criptográficos tienen muchas orientaciones y objetivos. Se puede estar hablando
de redes privadas virtuales, cuyo objetivo esencial es asegurar todo el tráfico IP que circula por
redes consideradas inseguras, o de sistemas de comercio electrónico o de sistemas seguros de
correo electrónico.
Quizás el grupo de protocolos criptográficos más famosos en el mundo de las redes IP sea el
conocido bajo el nombre de grupo de IPSec. Estos protocolos trabajan en equipo para construir
un túnel IP seguro entre participantes en una red que los usen. Son los protocolos más utilizados
para el despliegue de redes privadas virtuales.
Finalmente se analizará el protocolo PGP, un buen ejemplo de un protocolo utilizado para
asegurar todo el tráfico de correo electrónico por Internet.
81
Los cuatro componentes principales del protocolo SSL son:
Registro, un nivel que recibe los datos, en forma de bloques no vacíos, del nivel superior
y los encapsula.
Handshake, el proceso que determina los parámetros criptográficos que se van a utilizar
dentro de la sesión y se usa o no compresión. Opera sobre el nivel de Registro.
Alerta, un cierto tipo de contenido, soportado por el nivel de Registro, que se encarga de
adecuar la severidad y la descripción de una alerta.
Otro problema típico es el uso fraudulento de una tarjeta correcta. El vendedor no tiene
forma de saber nada más que si la tarjeta es correcta o no.
Un problema “clásico” es el caso de una tienda de Internet con muchos compradores que
confían en ella por su seriedad. En la tienda hay servidores SSL. A cada cliente se le pide
sólo los primeros dígitos de su tarjeta de crédito, para evitar que el número sea transmitido
varias veces por Internet. Pero la seguridad en el cortafuegos tiene un agujero que permite
a un atacante penetrar y llegar al fichero de la base de datos de clientes de la tienda.
82
El vendedor.
El equipo, controlado por un banco, que hace de “pasarela” de pago.
La necesidad estricta de certificación (X.509) es la base fundamental de la seguridad del proto-
colo, además de que cada entidad participante conoce únicamente la información que necesita.
Lo que se consigue es lo siguiente:
Que el vendedor no tenga acceso a la información de pago.
Que el banco no tenga acceso a la información de los pedidos.
SET permite administrar tareas típicas asociadas a la actividad comercial, como el registro
del titular o del vendedor, autorizaciones, anulaciones, etc.
El comprador cifra su número de tarjeta de crédito con la clave pública de la pasarela de pago,
de forma que el vendedor recibe un mensaje cifrado y no puede ver el número de la tarjeta, pero
sí puede guardarlo y, sobre todo, enviarlo al banco.
El proceso completo del protocolo SET es el siguiente:
1. El comprador llena la orden de compra y selecciona el botón de pagar. Aquí comienza SET.
2. El comprador envía la orden y la información de pago al vendedor. Se crean dos mensajes,
uno con la información de la orden de compra y el número de la orden. Este mensaje
se cifra mediante un algoritmo simétrico (DES) y se encapsula, cifrando el resultado de la
operación mediante la clave pública del vendedor. El segundo mensaje lleva la información
de pago. El paso final es la firma del comprador de ambos mensajes.
3. El vendedor envía la información de pago a su banco. En el equipo del vendedor se genera
una petición de autorización, se le calcula un hash y se firma por el vendedor, para probar
su identidad a su propio banco. Se cifra, con un método simétrico, y se firma con la clave
pública del banco.
4. El banco verifica la validez de la petición. El banco verifica la identidad del vendedor, desci-
fra la información de pago del cliente y su identidad. Genera una petición de autorización
para el banco del comprador, la firma, y se la envía al otro banco.
5. El banco del comprador, el banco emisor de la tarjeta usada, autoriza la transacción, des-
pués de confirmar la identidad del cliente y que éste tiene saldo. Aprueba la petición de
autorización, la firma y se la envía al primer banco.
6. El banco del vendedor autoriza la transacción, la firma y la envía al comprador.
7. El servidor del vendedor completa la transacción, mostrando al comprador que la tarjeta
fue aprobada, la conformidad del pago, y procesa la orden de compra.
8. El vendedor envía un mensaje de compra a su nuevo banco, para generar el cargo en la
cuenta del cliente y acreditar la misma cantidad en su propia cuenta.
9. El banco del comprador notifica al mismo del cargo hecho, cosa que puede suceder, por
ejemplo, en el estado de cuenta que se le envía periódicamente.
83
IPSec proporciona autenticación de extremo a extremo del tráfico, en cuanto a los equipos,
dejando de lado la autenticación de usuario.
IPSec debe mantener flexible todo el proceso de administración de las claves necesarias
para cualquiera de los tipos de cifrado que utiliza.
Las características de seguridad que ofrece IPSec son:
Integridad de los datos transmitidos en los mensajes IP.
Autenticación del origen de los datos, es decir, de la dirección IP.
Modo transporte: en este modo se protege todo el paquete menos la cabecera IP. Es el modo
típico para cuando entre los dos extremos no hay ningún encaminador, las direcciones IP
de los extremos son de la misma red y no se quiere cifrar la propia cabecera IP.
Modo túnel: en este modo se desea proteger todo el paquete, incluyendo la cabecera de IP,
lo que obliga a utilizar una nueva cabecera de IP. Es el caso típico de empleo de IPSec, con
privacidad, para el tráfico de A a B a través de una red privada virtual en la que se desea
que todo el paquete IP vaya cifrado, pero se necesita, al menos, las direcciones IP origen y
destino para que los encaminadores intermedios puedan realizar su función.
84
el protocolo Internet Security Association and Key Management Protocol (ISAKMPB). El material
relacionado con las claves de cifrado lo proporcionaría este protocolo.
Una asociación de seguridad es una conexión, en un solo sentido, que proporciona un de-
terminado conjunto de servicios de seguridad a los paquetes IP a los que se le aplica. Al ser
asociaciones en un solo sentido implica que habrá que establecer dos asociaciones de seguridad
para asegurar el tráfico entre dos puntos de la red. Cada AS está identificado por:
Un SPI (Security Parameter Index).
La dirección IP destino de la conexión.
Un identificador, que sirve para conocer qué servicios de seguridad se están utilizando,
AH o ESP.
Las asociaciones de seguridad se crean dinámicamente cuando empieza una nueva sesión IPSec.
Hay dos bases de datos relacionadas con ellas:
La SPD (Security Policy Database), que especifica las políticas de aplicación al tráfico IP de
las características de seguridad. Es la que define las AS concretas.
La SAD (Security Association Database), que contiene los parámetros asociados con cada una
de las AS individuales activas.
IPSec pone en marcha la protección requerida conforme a lo estipulado en una SPD.
En el procesado de una comunicación IPSec extremo a extremo, se crea un entrada en la
SAD por cada asociación de seguridad que se negocia y se controla mediante la especificación
correspondiente de la SPD.
Cada una de las entradas de la SAD representa una asociación de seguridad negociada entre
los extremos y, como consecuencia, es muy ilustrativo del proceso señalar alguno de los campos
más significativos de cualquier SAD, que son:
Si la AS utiliza el protocolo AH, el algoritmo de hash, las claves, etc.
Si la AS usa el protocolo ESP, el algoritmo de cifrado simétrico, las claves, etc.
El tiempo de vida de la AS.
El modo de uso del protocolo ESP que puede ser transporte o túnel.
Cuando el proceso de IPSec convierte un mensaje típico de IP en un mensaje protegido, por
ejemplo por AH, aparece una nueva cabecera de AH entre la cabecera de IP y el resto del
mensaje.
85
16.5. El protocolo PGP (Pretty Good Privacy)
PGP realmente es una utilidad más que un único protocolo de seguridad. Se va a analizar en
esta sección únicamente las características básicas, que le han hecho realmente un estándar “de
facto” verdaderamente popular. PGP ofrece tres tipos de servicio:
Confidencialidad. Permite a un usuario, mediante cifrado, garantizar que solamente el
destinatario podrá leer el mensaje.
Autentificación. Permite a un usuario firmar un documento antes de enviarlo.
Integridad. La firma antes mencionada tiene la particularidad de que depende no sólo de
la identidad del remitente sino también del contenido del mensaje,por lo que si este es
alterado, la firma ya no es válida.
La firma PGP es un proceso opcional que consiste en una función MD5: primero se crea un hash
del mensaje, éste se encripta con la clave privada del emisor y, finalmente, se adjunta al propio
mensaje.
La compresión se utiliza para reducir el tamaño del mensaje y el algoritmo que se usa es el
mismo que con las utilidades ZIP. Es importante señalar que PGP comprime los datos después
de la firma, pero antes del cifrado, de forma que la firma resulta comprimida.
El proceso de envío de un mensaje PGP sería el siguiente:
1. Se crea un mensaje y se comprime.
2. Se genera una clave de sesión.
PGP divide el mensaje en fragmentos PGP de 50.000 caracteres o menos, haciéndolo como el
último paso en el proceso de envío de un mensaje.
El modelo PGP usa el modelo de confianza en web. Una vez se intercambian las claves, éstas
se retienen en un anillo de claves, que realmente es un fichero protegido por una palabra de
paso.
Cada clave del anillo de claves tiene un propietario y cada propietario tiene su campo de
confianza del propietario, con la que el propietario del anillo indica el nivel de confianza que se
tiene del primero.
Los algoritmos típicos que soporta PGP son:
Para la creación de firmas digitales, RSA/SHA y DSS/SHA.
Para la cifra del mensaje, IDEA, AES y 3DES o RSA.
86
17. Introducción a las redes privadas virtuales
17.1. Introducción
Una red privada virtual (RPV o VPN) es una conexión segura creada a través de una red
pública. Tienen tres usos principales:
La Intranet de la organización: una VPN sirve para conectar piezas disjuntas de la misma
red. En este caso, las comunicaciones seguras son, habitualmente, de red a red, no llegan a
los ordenadores particulares de las redes disjuntas.
La Extranet que es, realmente, una modificación simple del caso anterior en la parte técnica,
compleja en la parte de la seguridad. Parte de las redes disjuntas no pertenecen a la misma
organización, sino a otras. La dificultad estriba, esencialmente, en la implementación de la
política de seguridad referente a tales tipos de conexiones.
Los usuarios móviles de una organización: los usuarios de una red que trabajan desde
su casa, o que están en continuo cambio de ubicación, pueden hoy conectarse a su red,
mediante una llamada local al proveedor de Internet y mediante una VPN.
Hay que explorar el concepto de calidad de servicio. El control del tráfico se hace basándose en
algún criterio que permita identificarlo:
Direcciones IP fuente y destino.
Números de puerto fuente y destino.
87
El caso de las VPN origen-intermedio es el de las redes usadas por los usuarios móviles. Un
usuario a través de Internet va a conectarse con su red, pero no puede pensarse que el proveedor
de Internet le proporcione los servicios de seguridad que necesita. Por esa razón las funciones
se van a implementar en su equipo (un extremo de la VPN) y en el dispositivo intermedio de
entrada en su red.
Reducción de costes. Permiten reemplazar caras líneas privadas punto a punto por líneas
mucho más económicas. Al usar líneas dedicadas punto a punto era necesario tener un
enlace dedicado entre todos los puntos de la organización.
Mejora de la seguridad. La suite de protocolos TCP/IP es inherentemente insegura. Cualquier
implementación de VPN incluirá algún tipo de soporte criptográfico, lo cual incrementará
necesariamente la seguridad.
Integración de los datos. Ya que van a permitir integrar todos los datos de una organización
con sus oficinas remotas, sus proveedores, sus colaboradores y sus clientes.
Flexibilidad y escalabilidad. Cada sede de la organización podrá tener líneas con diferente
velocidad en función de sus necesidades, así mismo, será muy sencillo tanto cambiar el
ancho de banda asignado a cada sede. Por otro lado, será sencillo el incorporar nuevas
sedes en distintas localizaciones.
Simplificación de las operaciones. Las operaciones de administración y mantenimiento se ve-
rán simplificadas y reducidas.
88
Los servidores de certificación.
Las pasarelas de seguridad son dispositivos entre la red privada y la red pública que aseguran
que no haya intrusiones no deseadas en la red privada. Suelen ser también los que proporcio-
nan las capacidades de cifrado y tunneling (cortafuegos, encaminadores o dispositivos hardware
específicos para VPN).
Los servidores de políticas de seguridad suelen mantener listas de control de acceso y otro
tipo de informaciones de seguridad necesarios para la operación correcta de las pasarelas de
seguridad.. Es muy habitual usar un servidor AAA, ya sea mediante TACACS/+ o RADIUS,
para la pasarela de seguridad.
Si la red privada virtual es grande, es muy normal que use, para la autenticación de usuarios
y de dispositivos, certificados digitales, lo que obligará a implementar una PKI, con autoridades
de certificación, que pueden ser externas o internas.
Una de las principales consideraciones con respecto a la red es de qué capacidades disponen
los dispositivos de seguridad y encaminamiento.
Las ubicaciones típicas para colocar dispositivos de extremo a extremo de una red privada
virtual varían, puede ser el propio cortafuegos, puede ser el encaminador de la organización, se
puede situar entre ambos, o más allá del encaminador, entre éste y el primer encaminador del
proveedor de acceso a Internet.
Para poder separar más claramente las funciones, se suele hablar de una pasarela VPN como
del dispositivo hardware que sólo implementa las funciones de una VPN. Tales funciones se
pueden resumir diciendo que tal dispositivo es el punto extremo de túneles de clientes remotos.
Las pasarelas VPN tienen que hacer tunneling, cifrado, autenticación y administración de
claves. Si la pasarela VPN tiene un puerto WAN, puede instalarse de dos maneras. En una de
ellas, se coloca entre la conexión al proveedor de acceso y la Intranet propia. Otra opción sería
disponer de una topología como la anterior para el tráfico que deba ir cifrado y de otra entrada
a la red para el que no deba ir cifrado.
Cuando la pasarela VPN no dispone de un puerto WAN, sino únicamente de conexiones
Ethernet, suele haber cuatro configuraciones posibles:
Colocar la pasarela antes del encaminador y del resto de la red interna.
Colocar la pasarela detrás del encaminador y antes del resto de la red interna.
89
Piénsese, por ejemplo, en la gestión de fallos de funcionamiento. O bien se añaden segmentos de
red en los que el tráfico no vaya cifrado o hay que disponer de capacidad de cifrado y descifrado
en muchos puntos de la red, lo que no parece muy adecuado.
Otro reto en el mantenimiento está muy ligado con la configuración de la seguridad. Consiste
en la generación, distribución y mantenimiento de las claves con las que se cifra y se descifra el
tráfico. Si el número de participantes no es pequeño, este problema es particularmente evidente.
Según va mejorando la capacidad de los ordenadores, los algoritmos usados para crear y usar
tales claves se van haciendo más débiles y necesitan actualizaciones.
Por si todo lo anterior fuera poco no se debe olvidar los problemas normales de manteni-
miento de cualquier red, que también aparecen en una VPN. Se ha de recordar al menos estos
cuatro:
Problemas físicos, como que un cable se ha roto.
Problemas relacionados con el direccionamiento IP, que, en este caso, se ven agravados por
la necesidad del uso de NAT.
90
Fase 2 y 3: la pasarela VPN remite las credenciales de autenticación del usuario al servidor
de autenticación.
Fase 4: una vez que el usuario ha sido autenticado, la pasarela de la VPN le mostrará la
lista de aplicaciones a las que el usuario puede acceder con su cuenta.
Fase 5: una vez que se ha seleccionado la aplicación comienza la comunicación cliente-
servidor que será encapsulada dentro del túnel SSL. Esta comunicación siempre pasará a
través de la pasarela o proxy.
Esta simplicidad tiene también sus riesgos de seguridad, los cuales podemos agrupar en tres
grandes grupos:
Integridad de los dispositivos remotos: los equipos usados para acceder de forma remota a la
VPN no serán controlados por los administradores de la organización.
Historial del navegador del equipo remoto: el navegador del equipo remoto que acceda a la
VPN-SSL guardará en su historial de navegación la actividad que haya realizado. Si la
conexión se hizo desde un equipo público al que puede tener acceso más personas, dicha
información puede ser muy valiosa para un atacante con acceso a dicha máquina.
Acceso al portal: para acceder a este tipo de VPNs sólo es necesario conocer la URL de la
pasarela de aplicación. Estos portales de aplicación son susceptibles a ataques de fuerza
bruta de contraseñas.
Finalmente en el caso de VPLS la tabla contendrá información sobre las direcciones MAC.
91
El proveedor del servicio creará un LSP para cada circuito virtual entre las sedes de un cliente.
Cuando el encaminador del proveedor (PE) recibe un paquete de un encaminador de cliente
(CE), éste consulta la tabla de información correspondiente. Si el destino del paquete es un
encaminador de cliente (CE) de otra sede, el paquete será encapsulado al añadirle una cabecera
MPLS que contendrá la etiqueta del LSP que le corresponda.
El hecho de que sea el proveedor de servicios el que gestione el núcleo de la red del cliente
presenta una serie de inconvenientes:
La elección de protocolos de encaminamiento estará limitada a los protocolos admitidos
por el proveedor.
92
18. Introducción a la seguridad de Redes Inalámbricas
18.1. Introducción
Durante el presente tema se pretende hacer una pequeña introducción a los problemas de
seguridad que presentan las redes inalámbricas, así como las diferentes medidas y protocolos
que podemos utilizar para mitigar dichos riesgos.
18.2.5. Encriptación
Las redes inalámbricas usan la encriptación para ocultar el contenido de una comunicación,
de forma que sólo los usuarios autorizados pueden ver el contenido real de la comunicación.
Clave WEP.
93
Clave compartida WPA.
Autenticación contra una base de datos centralizada.
Los datos de las comunicaciones inalámbricas viajan por el aire, siendo susceptibles de ser in-
terceptados por cualquiera. Es necesario buscar un método para asegurar la privacidad de esta
información, sobre todo en protocolos que no usan encriptación para comunicarse.
Aparece el problema de integridad de la información. Un atacante también puede modificar
los paquetes interceptados y enviarlos a su destino con la información alterada. Es necesario
encontrar algún método para poder asegurar que la información recibida no ha sido manipulada
por el camino.
18.3.3.3. Ataques de fuerza bruta Este tipo de ataques son utilizados para tratar de obtener
la clave que se está usando para cifrar una determinada comunicación o para conectar con un
determinado punto de acceso. Básicamente lo que el atacante hace es probar todas las posibles
claves hasta dar con la correcta.
18.3.3.4. Ataques Man-in-the-Middle Este tipo de ataques se basa en el hecho de que el ata-
cante puede ver y manipular el flujo de datos entre dos elementos de la red. De esta manera el
atacante puede tanto ver lo que el usuario está haciendo como manipular lo que este ve. Dos
ejemplos de los ataques de este tipo más utilizados son los siguientes:
Suplantación ARP. Es necesario recordar el funcionamiento de algunos procesos de redes
locales.
Cuando una máquina quiere establecer una comunicación con otra máquina situada en la
misma red local, dicha máquina dispondrá de la dirección IP del destinatario. Dado que
ambas máquinas están en la misma red local la máquina origen puede enviar paquetes
directamente a la máquina destino, pero para ello necesitará conocer la dirección MAC de
dicho destinatario.
Para determinar la dirección MAC del destinatario, la máquina emisora enviará un paque-
te de requerimiento ARP. Este paquete se envía por medio de un broadcast. Dicho paquete
94
contiene la dirección IP para la cual se desea saber la dirección MAC. El atacante responde-
rá al paquete de solicitud ARP indicando su propia dirección MAC, y a la vez interceptará
el paquete de respuesta emitido por el destinatario para conocer su dirección MAC.
De esta forma el emisor enviará los paquetes al atacante y él los podrá retransmitir o no
al destinatario según le interese. Por este método el atacante no sólo ve la actividad del
cliente sino que es capaz de manipular los datos que este recibe.
Servidor DHCP falso. Un atacante puede llegar a establecer su propio servidor DHCP. Este
servidor DHCP falso interceptará las solicitudes DHCP realizadas por los usuarios y a
todos ellos les indicará que él mismo va a ser la puerta de enlace predeterminada. De esta
forma, todos los paquetes enviados por el cliente a la red pasarán por la máquina atacante.
18.3.4.1. Vulnerabilidades de los clientes de redes inalámbricas Podríamos dividir estas vul-
nerabilidades en tres categorías:
1. Comunicaciones inseguras
Si la comunicación no se ha cifrado el atacante puede verla cuando ésta viaja por el medio,
y hay muchas posibilidades de que el cliente pueda ser explotado para atacar al sistema.
2. Configuraciones por defecto
Ya sean usuarios y contraseñas por defecto, servicios innecesarios activados o configuracio-
nes de cifrado débiles, una gran cantidad de configuraciones por defecto elegidas por los
fabricantes han sido fuente de grandes preocupaciones para los administradores de red.
La mayoría de los usuarios configuran sus teléfonos para que estos comprueben auto-
máticamente y de forma periódica si tienen nuevos correos. Este comportamiento puede
suponer un grave problema de seguridad.
Muchos sistemas usan cookies para probar que un usuario se ha autenticado correctamente
en el sitio web. Si un atacante es capaz de capturar dicha cookie será capaz de conectar con
el sitio remoto haciéndose pasar por el cliente que está autenticado correctamente.
3. Confundir al cliente para que se comunique con el atacante
Si el atacante puede forzar al cliente a conectarse con él en vez de al punto de acceso seguro
el atacante tendrá muchas posibilidades de poder comprometer al cliente.
En muchos casos el atacante desplegará su propio punto de acceso con el mismo ESSID
que el punto de acceso que trata de suplantar, de esta manera engañará al cliente para que
se conecte con él en vez de con el punto de acceso seguro. El atacante puede utilizar herra-
mientas para des-autenticar al cliente con el punto de acceso seguro para a continuación
comenzar a enviar paquetes baliza con el ESSID que sabe que el cliente va a buscar para
conectar.
18.3.4.2. Factores que agravan las vulnerabilidades de los clientes de redes inalámbricas
Factores que hacen que las vulnerabilidades de los clientes de las redes inalámbricas puedan
ser especialmente graves:
Hay gran cantidad de usuarios de las redes inalámbricas. Un atacante lo único que tiene
que hacer es situarse en el rango de dicha red y “ver qué puede encontrar”. Seguro que
encuentra una gran cantidad de clientes que puede usar como objetivo.
95
Los clientes de las redes inalámbricas no son monitorizados de forma tan detallada como
los puntos de acceso. Esto hace que un atacante tenga más posibilidades de pasar desaper-
cibido para el sistema si se concentra en atacar a los clientes.
18.4.1.2. Privilegios mínimos Este principio implica dar a los usuarios acceso solamente a los
recursos que necesiten para desempeñar su trabajo.
18.4.1.4. Asegurar la infraestructura de red No hay que cometer el error de sólo asegurar los
distintos servidores y sistemas de la red, es de vital importancia asegurar también los distintos
componentes de la infraestructura de red (cortafuegos, encaminadores, conmutadores y puntos
de acceso).
18.4.1.5. Detección de puntos de acceso no autorizados Este tipo de puntos de acceso debería
ser identificado y eliminado lo antes posible.
18.4.1.6. Cambiar configuraciones por defecto Es de especial importancia cambiar las confi-
guraciones por defecto de todos los componentes de la red inalámbrica. Es uno de los vectores
de ataque más usados, pueden ser puntos de entrada a nuestra red para un atacante conocedor
de los mismos.
96
18.4.2.1. Cajas de Faraday Consiste en producir interferencias alrededor del perímetro de
seguridad de la compañía de forma que no puedan entrar señales inalámbricas del exterior y, a
su vez, que las señales inalámbricas interiores no puedan cruzar al exterior.
Este tipo de medidas pueden llegar a ser muy costosas, y gracias a antenas de alta ganancia
un atacante puede llegar a recoger hasta la más mínima señal inalámbrica.
18.4.2.2. Filtros de direcciones MAC El filtrado de direcciones MAC permite a los admi-
nistradores definir listas con las direcciones MAC de aquellos clientes que tienen permitido el
acceso a la red.
En apartados anteriores se ha analizado lo fácil que es para un atacante capturar los paquetes
de las distintas comunicaciones inalámbricas que se producen en su radio de acción. Los paque-
tes capturados contendrán la dirección MAC del emisor de los paquetes. Para un atacante es
muy sencillo conseguir la dirección MAC de un cliente autorizado y usar dicha dirección para
suplantarlo.
Por otro lado, además es un método muy laborioso de administrar.
18.4.2.3. Ocultación del SSID El administrador puede configurar los puntos de acceso de su
red para que omitan el SSID de la red en sus paquetes baliza. Esto es una medida inútil ya que
los atacantes pueden llegar a obtener el SSID de la red con una sencilla captura de paquetes de
solicitud de conexión de los clientes autorizados a conectar con dicha red.
18.4.3.3. Conmutadores Incluso los conmutadores se pueden usar para segmentar la red
inalámbrica de la red física. La forma más básica la podemos obtener usando conmutadores
para segmentar la red a nivel 2 por medio de VLANs.
Normalmente se asignará un rango de direcciones IP a cada subred, y la única manera de
que dos dispositivos situados en segmentos distintos se comuniquen entre sí será por medio de
alguna puerta de enlace de nivel 3 como puede ser un encaminador o un cortafuegos.
18.4.3.4. Sistemas de detección de intrusiones Este tipo de sistemas detectan posibles intru-
siones en los sistemas, monitorizando para ello el tráfico de red buscando determinados patrones
de acciones.
Además de desplegar una de estas soluciones, es necesario dedicar especial atención a en
qué punto de la red se va a colocar. En caso de querer usar un sistema IDS en nuestra red
inalámbrica, este deberá situarse en un punto capaz de “escuchar” todas las comunicaciones
que pasen por los puntos de acceso a la red.
18.4.3.5. Honeypots Estos sistemas están especialmente configurados para atraer la atención
de los atacantes, evitando de esta manera que centren sus esfuerzos en sistemas reales y propor-
cionando información sobre el atacante y sus métodos.
Se puede construir un honeypot sencillo simplemente desplegando un punto de acceso total-
mente aislado y sin acceso de ningún tipo a la red interna.
97
18.5. Medidas criptográficas para protección de redes inalámbricas
Se ha comentado ya la necesidad de proporcionar privacidad e integridad a las comunica-
ciones inalámbricas. Los protocolos 802.11 disponen de una serie de métodos de autenticación
y encriptación que van a permitir a las redes inalámbricas proporcionar dicha privacidad e inte-
gridad.
18.5.1.1. WEP como método de autenticación WEP soporta dos mecanismos de autenticación:
autenticación por clave compartida y autenticación abierta.
En el caso de autenticación abierta el proceso es muy sencillo. El cliente envía al punto de
acceso una solicitud de autenticación y este entiende que por el mero hecho de que el cliente le
haga dicha solicitud, éste ya debe tener acceso a la red inalámbrica.
En la autenticación por clave compartida se usa una clave WEP para verificar que el usuario
debería tener acceso a la red inalámbrica. El cliente y el punto de acceso siguen el siguiente
proceso:
1. El cliente envía al punto de acceso una solicitud de autenticación.
2. El punto de acceso envía al cliente un número pseudo-aleatorio.
3. El cliente cifra ese valor usando para ello la clave WEP y lo envía de nuevo al punto de
acceso.
4. El punto de acceso cifra el número pseudo-aleatorio con su copia de la clave WEP y com-
prueba que el valor obtenido coincide por el recibido del cliente.
18.5.1.2. WEP como método de cifrado WEP proporciona cifrado en el nivel 2 del modelo
OSI, el correspondiente a la capa de enlace o MAC. Usa un sistema de clave compartida de 40 o
104 bits.
El sistema WEP requiere configurar la clave de cifrado en el punto de acceso y posteriormente
en todos aquellos clientes que se quieran conectar a esa red inalámbrica.
El hecho de compartir una clave entre muchos usuarios es un claro punto de vulnerabilidad.
WEP utiliza el algoritmo de cifrado RC4, que tiene la peculiaridad de que dos paquetes no
pueden ir cifrados con la misma clave. Por ello, para cifrar un determinado paquete este incluirá
un número pseudo-aleatorio de 24 bits llamado vector de inicialización.
El hecho de que los paquetes cifrados incluyan en texto sin cifrar el valor del vector de
inicialización hace que WEP no sea un algoritmo de autenticación y cifrado seguro.
18.5.1.3. Vulnerabilidades y ataques a redes con cifrado WEP En 2001 el cifrado WEP fue
roto atacando la vulnerabilidad que supone el envío en texto sin cifrar del vector de iniciali-
zación de 24 bits. El ataque FMS permite a un atacante descubrir la clave WEP simplemente
capturando de forma pasiva paquetes de comunicación de la red atacada. Posteriormente han
salido revisiones y mejoras de este ataque.
En estos momentos existen herramientas que realizan este proceso de forma automática.
Como conclusión, WEP es un proceso de autenticación y cifrado que todavía encontramos en
innumerables instalaciones inalámbricas y que dada su conocida vulnerabilidad es una medida
de seguridad inutil.
98
18.5.2. WPA (WiFi Protected Access)
El protocolo WPA fue desarrollado como sustituto de WEP. WPA es capaz de funcionar en la
mayoría de las tarjetas de red inalámbricas y puntos de acceso con una simple actualización de
su firmware.
18.5.2.2. Algoritmo de cifrado de WPA2 WPA2 todavía soporta el algoritmo de cifrado TKIP
pero ha incorporado una nueva opción más segura que se conoce como CCMP o AES. AES es
un algoritmo de cifrado mucho más seguro que TKIP. Siempre que sea posible es recomendable
configurar los puntos de acceso para que usen el algoritmo WPA2 CCMP.
18.5.2.3. Vulnerabilidades y ataques a redes con cifrado WPA WPA también presenta sus
vulnerabilidades que deben ser tenidas en cuenta.
99
El sistema y la máquina del usuario pueden realizar el proceso de autenticación sin inter-
vención del usuario
18.5.3.1. Autenticación de usuarios RADIUS permite autenticar usuarios en una gran varie-
dad de escenarios y tecnologías, incluyendo las redes inalámbricas. Proporciona autenticación,
autorización y registro de las actividades de los usuarios. Los servidores RADIUS pueden ser
sistemas autónomos que autenticarán a los usuarios contra una base de datos de usuarios local.
100