Procesos y

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

2. La seguridad en los elementos físicos existentes en una red 4

2.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Los sistemas de cableado o inalámbricos . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Repetidores, hubs y conmutadores (o switches) . . . . . . . . . . . . . . . . . . . . . 5
2.4. Encaminadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.5. Los servidores y otras máquinas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3. La seguridad en los elementos software existentes en una red 7

3.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Los Sistemas Operativos y las aplicaciones . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Los protocolos y aplicaciones IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Mejoras de seguridad con IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.5. Criterios de evaluación de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4. Métodos de ataque a equipos y redes 13

4.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2. Taxonomía de los tipos de ataque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3. Ataques orientados a la obtención de información sobre el objetivo . . . . . . . . . 14
4.3.1. Ingeniería social . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3.2. Herramientas informáticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3.3. Escuchadores o sniffers de paquetes . . . . . . . . . . . . . . . . . . . . . . . 15
4.3.4. Análisis de metadatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.4. Ataques basados en la mala administración de sistemas . . . . . . . . . . . . . . . 15
4.5. Ataques basados en vulnerabilidades de los protocolos de red . . . . . . . . . . . . 17
4.5.1. Ataques Man-in-the-Middle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.6. Ataques basados en vulnerabilidades de software . . . . . . . . . . . . . . . . . . . 18
4.7. Ataques de denegación de servicio (DOS) . . . . . . . . . . . . . . . . . . . . . . . . 18
4.8. Ataques por medio de código malicios . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.9. Ataques a dispositivos móviles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5. Defensas básicas ante ataques 21

5.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.2. Controles de acceso físico a sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.3. Control de acceso lógico a sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.4. Otros controles simples de acceso a la información . . . . . . . . . . . . . . . . . . 24

6. Una respuesta completa a los problemas de seguridad en redes de información 25

6.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.2. ¿Qué es una política de seguridad? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.3. Aspectos físicos de la política de seguridad . . . . . . . . . . . . . . . . . . . . . . . 27
6.4. Aspectos lógicos de la política de seguridad . . . . . . . . . . . . . . . . . . . . . . 28
6.5. Aspectos legales de la política de seguridad . . . . . . . . . . . . . . . . . . . . . . 29
6.5.1. Ley Orgánica de Protección de Datos Personales (LOPD) . . . . . . . . . . 29
6.5.2. Ley de Servicios de la Sociedad de la Información y Comercio Electrónico
(LSSICE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.5.3. El Esquema Nacional de Seguridad (ENS) . . . . . . . . . . . . . . . . . . . 31
6.6. Aspectos organizativos de la política de seguridad . . . . . . . . . . . . . . . . . . 31
6.6.1. El estándar ISO/IEC 15408 Common Criteria . . . . . . . . . . . . . . . . . . 31
6.6.2. El estándar ISO/IEC 27001 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.6.3. Las buenas prácticas de ITIL™ y la norma ISO/IEC 20000 . . . . . . . . . . 33
 7. Introducción a los métodos no criptográficos para la implantación de la política de
seguridad 34
7.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.2. Herramientas para la puesta en marcha de la política de seguridad . . . . . . . . . 34
7.3. Otros elementos a tener en cuenta . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

8. Introducción a los cortafuegos 36

8.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
8.2. Ventajas, inconvenientes y tipos de cortafuegos . . . . . . . . . . . . . . . . . . . . 36
8.3. Los filtros de paquetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.3.1. Las ACL (Listas de Control de Acceso) de los encaminadores Cisco . . . . 38
8.4. Los Gateways de aplicación o servidores Proxy . . . . . . . . . . . . . . . . . . . . . 40
8.5. ¿Qué se puede mejorar? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

9. Tecnologías de última generación en cortafuegos 41

9.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
9.2. Caso de estudio, el modelo IPTables . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
9.2.1. Procesado de paquetes en IPTables . . . . . . . . . . . . . . . . . . . . . . . 41
9.2.2. Sintaxis de las reglas IPTables . . . . . . . . . . . . . . . . . . . . . . . . . . 42
9.2.3. Uso de IPTables como puerta de enlace de la red . . . . . . . . . . . . . . . 44
9.2.4. Redirección de tráfico entrante (DNAT) . . . . . . . . . . . . . . . . . . . . . 45
9.2.5. Guardar y restaurar reglas de filtrado . . . . . . . . . . . . . . . . . . . . . . 46
9.3. Caso de estudio: el modelo Cisco ASA . . . . . . . . . . . . . . . . . . . . . . . . . . 46
9.3.1. ¿Qué son los niveles ASA? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
9.3.2. Configuración básica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
9.3.3. Otras características avanzadas de ASA . . . . . . . . . . . . . . . . . . . . . 47

10. Introducción a las herramientas de análisis de vulnerabilidades de seguridad 49

10.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
10.2. Caso práctico: la herramienta Nmap . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
10.2.1. Instalación y uso de Nmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
10.3. Caso práctico: la herramienta Nessus . . . . . . . . . . . . . . . . . . . . . . . . . . 50
10.3.1. Instalación y uso de Nessus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
10.4. Herramientas de análisis de vulnerabilidades en código fuente . . . . . . . . . . . 51
10.4.1. Características generales de las herramientas SSCA . . . . . . . . . . . . . . 51
10.4.2. Tipos de herramientas SSCA . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
10.4.3. ¿Qué herramienta seleccionar? . . . . . . . . . . . . . . . . . . . . . . . . . . 51

11. Introducción a las herramientas de detección de intrusiones 52

11.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
11.2. Caso práctico: Snort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
11.3. Caso práctico: Sguil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
11.4. Honeypots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
11.4.1. Ejemplo de honeypots reales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

12. Diseño seguro de redes: alta disponibilidad y redundancia 60

12.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
12.2. Diseño de soluciones de alta disponibilidad . . . . . . . . . . . . . . . . . . . . . . 60
12.3. Los problemas de infraestructura y soluciones . . . . . . . . . . . . . . . . . . . . . 61
12.4. Los problemas en el nivel 2 de OSI y soluciones . . . . . . . . . . . . . . . . . . . . 62
12.5. Los problemas en el nivel 3 de OSI y soluciones . . . . . . . . . . . . . . . . . . . . 62
12.6. Consideraciones para el resto de los niveles OSI . . . . . . . . . . . . . . . . . . . . 63
12.7. Consideraciones para el almacenamiento en red: SAN (Storage Area Networks) . . . 63
12.8. Consideraciones sobre dispositivos de seguridad . . . . . . . . . . . . . . . . . . . 64
13. Introducción a la criptografía como herramienta de seguridad en redes 65
13.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
13.2. Elementos básicos de cualquier sistema criptográfico . . . . . . . . . . . . . . . . . 65
13.3. Distintos niveles criptográficos en el software de redes y sistemas . . . . . . . . . . 66
13.4. Tipos de ataques a sistemas criptográficos . . . . . . . . . . . . . . . . . . . . . . . . 67

14. Métodos criptográficos: sistemas de clave privada, sistemas de clave pública y

funciones de una sola vía 68
14.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
14.2. Algoritmos de clave privada o de criptografía simétrica . . . . . . . . . . . . . . . . 68
14.3. Funciones de una sola vía (one way hash) . . . . . . . . . . . . . . . . . . . . . . . . 69
14.4. Algoritmos de clave pública o de criptografía asimétrica . . . . . . . . . . . . . . . 71

15. Certificación, autenticación e integridad de la información. Firma digital y PKI 74

15.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
15.2. Autenticación, integridad y no repudio . . . . . . . . . . . . . . . . . . . . . . . . . 74
15.3. Los sistemas de firma digital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
15.4. La necesidad de certificación. El estándar X.509 y las autoridades de certificación 77
15.5. Los modelos de infraestructura de clave pública o PKI . . . . . . . . . . . . . . . . 78
15.6. Problemas de seguridad de las firmas digitales y de las PKI . . . . . . . . . . . . . 79

16. Protocolos criptográficos más habituales 81

16.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
16.2. Protocolos de comercio electrónico: SSL . . . . . . . . . . . . . . . . . . . . . . . . . 81
16.3. Protocolos de comercio electrónico: SET . . . . . . . . . . . . . . . . . . . . . . . . . 82
16.4. Los protocolos IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
16.4.1. El protocolo AH - Authentication Header . . . . . . . . . . . . . . . . . . . . . 84
16.4.2. Protocolo ESP - Encapsulating Security Payload . . . . . . . . . . . . . . . . . 84
16.4.3. Las asociaciones de seguridad en IPSec . . . . . . . . . . . . . . . . . . . . . 84
16.4.4. Un ejemplo básico de uso de IPSec . . . . . . . . . . . . . . . . . . . . . . . 85
16.5. El protocolo PGP (Pretty Good Privacy) . . . . . . . . . . . . . . . . . . . . . . . . . . 86

17. Introducción a las redes privadas virtuales 87

17.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
17.2. Caracterización de las redes privadas virtuales . . . . . . . . . . . . . . . . . . . . . 87
17.2.1. Ventajas e inconvenientes de las VPN . . . . . . . . . . . . . . . . . . . . . . 88
17.2.2. Arquitectura y planificación de VPNs . . . . . . . . . . . . . . . . . . . . . . 88
17.2.3. Rendimiento, mantenimiento y seguridad . . . . . . . . . . . . . . . . . . . 89
17.3. VPN mediante SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
17.4. VPN a través de redes MPLS (Multi Protocol Label Switching) . . . . . . . . . . . . . 91

18. Introducción a la seguridad de Redes Inalámbricas 93

18.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
18.2. Redes inalámbricas, conceptos básicos. . . . . . . . . . . . . . . . . . . . . . . . . . 93
18.2.1. 802.11 a/b/g/n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
18.2.2. Puntos de acceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
18.2.3. SSID, BSSID, dirección MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
18.2.4. Paquetes baliza (beacons) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
18.2.5. Encriptación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
18.3. Teoría de ataques a redes inalámbricas . . . . . . . . . . . . . . . . . . . . . . . . . 93
18.3.1. Problemas de autenticación, privacidad e integridad . . . . . . . . . . . . . 93
18.3.2. Ataques. Fase de reconocimiento . . . . . . . . . . . . . . . . . . . . . . . . . 94
18.3.3. Tipos de ataques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
18.3.4. Ataques a clientes de redes inalámbricas . . . . . . . . . . . . . . . . . . . . 95
18.4. Medidas no criptográficas para protección de redes inalámbricas . . . . . . . . . . 96
18.4.1. Principios de diseño seguro para redes inalámbricas . . . . . . . . . . . . . 96
18.4.2. Malas defensas no criptográficas . . . . . . . . . . . . . . . . . . . . . . . . . 96
18.4.3. Buenas defensas no criptográficas . . . . . . . . . . . . . . . . . . . . . . . . 97
18.5. Medidas criptográficas para protección de redes inalámbricas . . . . . . . . . . . . 98
18.5.1. WEP (Wired Equivalent Privacy) . . . . . . . . . . . . . . . . . . . . . . . . . . 98
18.5.2. WPA (WiFi Protected Access) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
18.5.3. WPA2-Enterprise con arquitectura de certificados digitales . . . . . . . . . 99
1. Descripción del problema de Seguridad en redes. Tipos de
ataques
1.1. Introducción, orientaciones para el estudio y objetivos
Desde el punto de vista del objetivo de este libro, todos los sistemas exhiben una serie de
propiedades interesantes.
Los sistemas son complejos y capaces de interactuar.
Muchos de ellos hacen cosas no pensadas por sus creadores y usuarios. Se dice formalmente
que los sistemas tienen propiedades no buscadas. Por ejemplo, la forma en que los teléfonos
móviles han cambiado la manera en la que las personas quedan para verse, o cómo los aparatos
de aire acondicionado han cambiado la manera en la cual se transmiten las enfermedades y
catarros. Los sistemas de los que se ocupa este libro tienen estas propiedades no buscadas o
bugs.
Un bug es una clase de “fallo del sistema” que no se debe confundir con que el sistema no
funcione correctamente. Cuanto más complejo y sofisticado sea el sistema, mayor es el número
de bugs que contiene.
Algunos de estos bugs se pueden transformar en problemas de seguridad informática. La su-
ma de tales bugs provoca lo que conocemos como “agujeros de seguridad”. Si son aprovechados
por alguien, los sistemas sufrirán ataques a su seguridad.
Todos estos bugs y vulnerabilidades hacen que sea difícil conseguir que un sistema sea segu-
ro. Los sistemas seguros son difíciles de obtener. Los sistemas complejos seguros son aún más
difíciles de construir.
Contra este tipo de problemas, se han desarrollado tecnologías informáticas que parecen
impecables pero que a su vez, están compuestas de sistemas que pueden exhibir los mismos
problemas citados.
Ayudará bastante pensar que la seguridad es un sistema dentro de sistemas mayores, es un
proceso que hace intervenir todas las tecnologías y, especialmente, el sentido común de los seres
humanos que la gestionan.
Pensemos en un buen sistema de seguridad de un banco: debe tener en cuenta la prevención,
la detección y la respuesta al problema concreto.
Se tratará en este tema de identificar cuáles son las preguntas que deberían hacerse para
definir mejor el sistema que uno quiere asegurar, proponiendo una solución imperfecta pero
realista, basada en lo que se llamará política de seguridad del sistema.

1.2. Unas cuantas preguntas que ayudan a definir mejor el problema

El objetivo prioritario deseado es conseguir la seguridad más completa para los sistemas y
redes de comunicación. Deben hacerse una serie de preguntas clave:
A) ¿Qué es lo que se quiere tener protegido?
Esta pregunta debería tener asociada la realización de un inventario de los activos de la orga-
nización, entendiendo como tales los sistemas, redes, aplicaciones, elementos de red, bases de
datos y, en general, cualquier tipo de activo, físico o no, que se quiera tener asegurado.
No todos los activos tendrán el mismo valor y éste será un criterio muy importante a la hora
de establecer una estrategia de cara a la seguridad. Hay que evaluar con detalle el valor de los
activos y lo que costaría protegerlos, haciendo un buen análisis de riesgos, que trataremos más
adelante.
B) ¿Contra quién se quiere proteger? o, expresado de otra forma, ¿en quién se puede confiar
y en quién no?, ¿quiénes son los posibles atacantes?
Como respuesta suele desarrollarse un modelo de confianza. Se debe decidir qué empleados
tienen acceso a qué activos y por qué, y qué tipo de acceso (físico o lógico) van a tener. Asimismo
se deberá pensar en qué tipo de acceso van a tener los posibles clientes de la organización.
Además, se debe estudiar quién y por qué querría atacar a la organización. Esto hará incluir
una categoría de individuos que no ha aparecido aún: los “malos” de la película.
C) ¿Cómo se quiere proteger? o, más concretamente, ¿qué tecnologías, herramientas, sistemas
concretos, procesos se van a utilizar para protegerlo?

1
Se tienen que conocer dos temas complejos:
1. Los distintos tipos de ataques posibles.

2. Las distintas defensas posibles.

A esto se dedican el resto de temas de este texto.
No será posible nunca conocer todos los distintos tipos posibles de ataques. Un buen
profesional ha de conformarse con conocer el mayor número posible y estar bien informado
sobre todos los nuevos que van apareciendo.
Los tipos más importantes de ataques son cuatro:
Ataques para obtener información. Son ataques “no intrusivos”, que tienen como objetivo
obtener información.
Ataques de acceso no autorizado. Son ataques de acceso de personas no autorizadas a los
sistemas. Suelen ser pruebas, sin mayor interés que demostrarse a sí mismos que pueden
llegar a ese sistema.
Ataques con revelación de información. Una vez se tiene el acceso anterior, se puede
utilizar ese acceso para acceder a información secreta.
Ataques de denegación de servicio. Buscan dejar no disponible un sistema, un servicio o
una red. Este tipo de ataques no suele necesitar ningún acceso previo a ningún sistema y
son prácticamente imparables.
Algunas de las más importantes defensas que tenemos son:
1. Esquemas de seguridad de sistemas operativos. Se deben mantener unos buenos esque-
mas de seguridad de ficheros, usuarios y aplicaciones, así como servicios de red controla-
dos desde tales sistemas.
2. Sistemas de identificación o autentificación seguros. Hay muchos y muy razonables, des-
de las contraseñas hasta los sistemas biométricos, certificados digitales, etc.
3. Sistemas de cortafuegos (o firewalls). Sistemas de control de la información en forma de
mensajes que entran o salen de una red.

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.

D) ¿Cuánto dinero se puede emplear en implantar y mantener el proceso de seguridad?

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.

El tiempo empleado en configurarlas y educar a los usuarios en su uso.

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.

El tiempo empleado en volver a una situación estable.

Para tratar de enfocar el problema con acierto se debe tener cuanto más conocimiento mejor de
qué se puede perder, qué se quiere proteger, de quién se quiere proteger, quién puede querer
atacar, cómo pueden ser los ataques, cuáles pueden ser las defensas y cuánto se puede invertir.
Se debería tratar de resumir todo este conocimiento en un análisis de riesgos.

1.3. Soluciones “perfectas” y soluciones razonables.

Contra problemas tan complejos como éstos se puede hacer una aproximación completa,
teniendo como objetivo que, en el sistema concreto, la probabilidad de sufrir un ataque sea lo
más cercana a cero. A esta aproximación se le da el nombre de “aproximación militar”.
Tal aproximación pasa por cumplir y hacer cumplir una serie de requisitos formidables sobre
todas las partes de la organización que va a ser asegurada.

La no aceptación de ningún código de aplicación no desarrollado siguiendo las propias

normas de seguridad.
La no aceptación de ningún sistema operativo, de ningún dispositivo, suficientemente com-
probado (tecnología menos moderna).
No conectarse a Internet o, si ya se estuviese conectado, desconectarse de ella y construir
una red propia.
Poner en marcha esta solución perfecta no es posible. Se tiende a implementar una aproximación
realista, en la cual se tienen en cuenta todos los factores citados en el apartado anterior, pero
también el no gastarse todo el presupuesto de la organización y sus recursos implementándola.
En el marco de esta implementación se define la política de seguridad como:

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.

Máquinas utilizadas por los usuarios, especialmente servidores.

2.2. Los sistemas de cableado o inalámbricos

Cuando se considera un circuito eléctrico como una red Ethernet que usa cables de par tren-
zado, el estado del voltaje está continuamente cambiando para transmitir la información, lo que
introduce la primera inseguridad: la interferencia electromagnética.
La radiación electromagnética puede medirse y obtener, a partir de ella, la señal que está
viajando por el cable. Una solución obvia consiste en usar cables apantallados, que no solo
protegen la información que viaja a través del medio frente a escuchas indeseadas, sino que
además la protegen contra interferencias que puedan distorsionarla. Los ejércitos disponen de
productos TEMPEST, que van desde cables apantallados hasta edificios enteros apantallados,
pasando por conmutadores, hubs, etc.
Otra solución es usar cable de fibra óptica que es completamente inmune a las interferencias
citadas.
Otro aspecto importante a tener en cuenta es que los segmentos de red en que no existan
conmutadores y no se tenga un control muy exhaustivo de quién está conectado, se corre el
riesgo de que alguien esté usando un analizador de protocolos o sniffer, que permite “ver” el
tráfico de cualquier equipo a cualquier otro equipo, aprovechando la capacidad de casi cualquier
tarjeta de red Ethernet de trabajar en modo “promiscuo”.
Se puede también usar la transmisión sin cable, mediante lasers o infrarrojos. El principal
inconveniente es la facilidad de cortar el servicio.
Los problemas de seguridad de las WLAN están divididos en los problemas de los dispo-
sitivos físicos y en las señales de radio transmitidas. Con una correcta elección del receptor de
radio, se puede obtener cualquier transmisión de este tipo de tecnología. En este caso, la seguri-
dad se apoya, especialmente, en las técnicas de acceso a los puntos de acceso, en la criptografía
utilizada en emisores y receptores y en su posible configuración y uso.

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.

Si se accede al conmutador mediante la consola, únicamente hay que conocer la información de

la contraseña asociada a esa cuenta. La otra forma de acceder al conmutador, es basándose en
un protocolo de una aplicación IP. Un conmutador debe implementar al menos el nivel 2 de OSI,
pero sólo con el fin de poder gestionarlo de manera remota.
Habitualmente, los conmutadores tienen, además, unas listas de direcciones IP desde las
cuales está permitido acceder al conmutador.

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.

3. Ataques basados en la falta de autentificación. Se tratan de mensajes enviados en cualquie-

ra de los protocolos citados, con una información de rutas errónea y que, al no “preguntar”
el encaminador a quién la manda y aceptarla sin problemas, permite controlar en parte la
red. Hay dos modalidades para este tipo de ataques:

Enviar información muy errónea, para volver “loca” a la red.

Enviar mensajes a dos encaminadores, explicándoles que la ruta más corta entre ellos
pasa por el segmento de red al que está conectado el atacante.

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.

Máquinas que ofrecen servicios o servidores.

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.

3.2. Los Sistemas Operativos y las aplicaciones

Todos los Sistemas Operativos comparten, con pequeñas diferencias, una estructura interna
parecida:
Un kernel o núcleo es el corazón del sistema operativo. Suele controlar todas las opera-
ciones de entrada y salida, permite que muchos programas funcionen a la vez y divide y
administra los recursos entre todos ellos. En muchos casos, incluye el sistema de ficheros.
Una serie de programas de utilidad utilizados por el propio kernel o por los usuarios.
Pueden ser pequeños como el comando /bin/ls o grandes como las shells o los sistemas de
ventanas.

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.

2. Entender la certificación de seguridad. Las personas responsables de los sistemas deben

entender cuál es su papel a jugar, tanto desde el punto de vista de la certificación como
desde el punto de vista de la política de seguridad.
3. Como consecuencia, aplicar los puntos concretos relacionados con lo anterior a los sistemas
particulares.

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

3.3. Los protocolos y aplicaciones IP

Conviene hacer un pequeño repaso a los puntos clave del conjunto de protocolos IP, en la
versión usada actualmente por casi todo el mundo, IPv4:
El protocolo primordial es IP, encargado de enviar mensajes, decidiendo por dónde y que
gestiona la tabla de encaminamiento, en base a su conocimiento del esquema de direccio-
namiento IP.
En el nivel de transporte se dispone de un protocolo orientado a conexión (TCP) y otro
que funciona sin conexión previa (UDP).
En el nivel de aplicaciones, éstas funcionan siguiente el modelo cliente-servidor, y los nú-
meros de puerto juegan un papel fundamental para entender su funcionamiento.
Desde el punto de vista de la estructura, los mensajes IP pueden ser de tres tipos:
1. Mensajes generados por una aplicación que tenga transporte TCP.
2. Mensajes generados por una aplicación que tenga transporte UDP.
3. Mensajes generados por protocolos del nivel de red como ICMP o IGRP.
Todos ellos comparten algo fundamental: una cabecera IP, que contiene varias cosas fundamen-
tales desde el punto de vista de la seguridad:
La dirección IP del destino del mensaje.
La dirección IP origen del mensaje.
El número de protocolo utilizado (TCP, ICMP, etc. . . ).
Información de fragmentación del mensaje.
Todos los mensajes generados por aplicaciones con transporte TCP tienen en común una cabe-
cera TCP. Esta incluye información fundamental como:
El número de puerto origen del mensaje.
El número de puerto destino del mensaje.
El número de secuencia, indicando el número de bytes enviados.
El número de ACK, que indica el último byte recibido.
Una serie de bits, indicativos de opciones de la sesión TCP.
Hay que recordar cómo es la creación de una sesión TCP. Entre un cliente y un servidor IP,
independientemente de la localización en la red y obviando el problema del encaminamiento:
1. Cuando un usuario arranca su cliente, se envía a la red un mensaje en el que van la
dirección IP de destino y el número de puerto de destino. Este mensaje lleva, además,
el bit de SYN habilitado, el bit de ACK deshabilitado, un número de secuencia propio
denominado NSEC-1 y el número de ACK, NACK-1, con valor cero pues se está en el
primer paso de la creación de la sesión y el servidor todavía no sabe nada sobre el cliente.
2. El mensaje llega al servidor que, si lo acepta, crea una entrada en la tabla de sesiones
“semi-establecidas” de TCP y contesta con un mensaje, con las direcciones y números de
puerto cambiados con respecto al anterior, con el bit SYN y el bit ACK habilitados, con
el NSEC propio, NSEC-2 y el número de ACK, NACK-2, con el valor correspondiente a
NSEC-1 +1. El servidor esperará a recibir el siguiente mensaje, para borrar la entrada de la
tabla de conexiones embriónicas y dar de alta la sesión en la tabla de sesiones establecidas.

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

Muchas de las implementaciones de los protocolos de aplicación más significativos (http,

smtp, etc.) se basan en código modular, en el que se podría garantizar la seguridad de cada
módulo, pero es prácticamente imposible garantizar la seguridad del sistema completo.

3.4. Mejoras de seguridad con IPv6

Existen una serie de razones que han llevado a que se tenga que mejorar el protocolo de
Internet IPv4:
La necesidad de un espacio de direcciones mucho más extenso.

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:

AH (Authentication Header). Proporciona autenticación e integridad.

ESP (Encapsulating Security Payload). Proporciona confidencialidad, así como, opcionalmen-
te, integridad y autenticación.
KMP (Key Management Protocol). Proporciona intercambio seguro de claves y administra-
ción de todo el proceso criptográfico de claves.

3.5. Criterios de evaluación de seguridad

A principios de los años ochenta se desarrolló un grupo de normas conocidas como la Trusted
Computer System Evaluation Criteria (TCSEC). Esta normativa está prácticamente obsoleta, no
contempla el hecho de que el sistema que se evalúe esté en una red. No obstante se pueden citar
los niveles de seguridad y su correspondencia dentro de esta normativa:
D, protección mínima.

C, protección discrecional. Dividido en dos subniveles, C1 y C2. El C1 (menor seguridad)

presenta una seguridad discrecional, con lo que existe algún nivel de protección a nivel de
equipos físicos. El C2 presenta el medio de acceso controlado, incorporando el registro de
auditoría y los privilegios de operación configurables.

B, protección obligatoria. Existen tres subniveles. El B1 (menor seguridad) presenta una

seguridad etiquetada, incorporando la seguridad en multinivel. El nivel B2 presenta una
protección estructurada, por lo que cualquier objeto existente tiene su protección asignada
por defecto. El nivel B3 presenta dominios de seguridad, con lo que se pueden gestionar
diferentes dominios de instalación de los equipos físicos.
A, protección verificada. Sólo tiene un subnivel, el A1, que incorpora el diseño verificado.
En él se realiza un proceso exhaustivo de diseño, control y verificación.
Desde 1990, la ISO ha estado trabajando en los criterios de evaluación de la seguridad de siste-
mas de información (ISO/IEC 15408), que son conocidos como los Common Criteria. La creación
de este estándar como medida de evaluación de la seguridad proporciona un marco común en el
que determinar los niveles de seguridad y confianza que implementa un determinado producto
o sistema.
Los conceptos clave de los Criterios Comunes son:
Perfil de Protección - PP (Protection Profile). Define un conjunto de requerimientos y
objetivos de seguridad, independientes 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 la seguridad informática.
Objetivo de la Evaluación - TOE (Target Of Evaluation). Un producto o sistema informá-
tico, que va a ser objetivo de una evaluación.
Objetivo de Seguridad - ST (Security Target). 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.
Requisitos funcionales de seguridad. Definen un comportamiento deseado en materia de
seguridad de un determinado producto o sistema IT que se agrupan en una serie de clases.
Requisitos de garantías de seguridad. Establecen los niveles de confianza que ofrecen
funciones de seguridad del producto o sistema en base a los requisitos que se satisfacen a
lo largo del ciclo de vida del producto o sistema.

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.

4.2. Taxonomía de los tipos de ataque

Una buena clasificación no se puede hacer sin un buen criterio. Existen varios buenos crite-
rios, dependiendo de lo que se quiera analizar. Atendiendo a un criterio de completitud, se van
a utilizar varios de ellos.
Desde el punto de vista del origen del ataque, los ataques son:
Externos. Cuando el atacante origina su ataque desde el exterior de una organización.
Puede ser desde un sitio desconocido de Internet o desde una dirección en la que se confía,
pero que ha sido suplantada.

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.

Otro criterio es la complejidad del ataque. Se puede hablar de ataques:

No estructurados. Son ataques, habitualmente inocentes, basados en herramientas bastante
normales, que pueden tener distintos tipos de objetivos.
Estructurados. Estos son los más peligrosos. En ellos se emplean muchos de los métodos
concretos y herramientas de las que se va a hablar más adelante. Son ataques “procedi-
mentados”, que tratan de no dejar cabos sueltos, en los que se trata de borrar las huellas
del ataque y en los que se tienen en cuenta distintos puntos de ataque y de retirada.

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.

Ataques basados en la mala administración de sistemas.

Ataques basados en vulnerabilidades de los protocolos de red.
Ataques basados en vulnerabilidades del software.
Ataques encaminados a sabotear un servicio.

Este último criterio será el que se va a usar en el resto del tema.

4.3. Ataques orientados a la obtención de información sobre el objetivo

Todas aquellas técnicas cuyo objetivo final es la obtención de información sobre la organiza-
ción objeto del ataque. El atacante trata de hacerse con información que posteriormente le pueda
ayudar a continuar con el ataque.
Encontramos tres tipos de técnicas distintas:

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.

4.3.1. Ingeniería social

El término describe a un conjunto de prácticas cuyo objetivo es la obtención de información
por medio de la manipulación de usuarios legítimos, los cuales serán confundidos para ofrecer
dicha información de forma voluntaria o incluso sin darse cuenta de ello.
Puede ser tan sencillo como mirar por encima del hombro cuando un usuario legítimo está
introduciendo su contraseña, o tan complejo como conseguir entrar en las instalaciones de la
organización haciéndose pasar por personal de mantenimiento.
Según Kevin Mitnick, la ingeniería social se basa en cuatro principios fundamentales:
Todos queremos ayudar.
La primera reacción es siempre de confianza hacia el otro.

No nos gusta decir no.

A todos nos gusta que nos alaben.
Uno de los métodos de ataque de ingeniería social más extendidos es el phising. Esta técnica con-
siste en enviar de forma masiva correos en los que se indica al usuario que hay algún problema
con su cuenta y que necesita restablecerla.
El enlace mostrado en el correo electrónico parece genuino, pero el sitio web al que se acce-
derá realmente en caso de pulsar sobre el mismo no será el sitio web real de la entidad.
Contra la ingeniería social basta un poco de sentido común y de conocimiento por parte de
los usuarios de estas técnicas. La información de los usuarios será esencial para combatir este
tipo de ataques.

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.

4.3.3. Escuchadores o sniffers de paquetes

Las herramientas de tipo sniffer permiten obtener todo el tráfico que circula por la red. Es
importante el punto en el que se sitúa el atacante, como se conecta a la red atacada, para determi-
nar qué tráfico será capaz de interceptar. Si su equipo está conectado a través de un conmutador
(switch), por su forma de funcionamiento sólo recibirá aquellos paquetes destinados específica-
mente para él, así como el tráfico broadcast, a no ser que, a su vez, el conmutador esté configurado
para que todo el tráfico que circula por él se copie al puerto donde se esté usando el sniffer. Si la
conexión a la red es a través de un concentrador el atacante recibirá copia de todos los paquetes
que viajan a través del mismo.
Este tipo de ataques inicialmente requieren que el atacante consiga conectarse de forma física
a la red de la organización. Los puntos de acceso inalámbricos de la organización son puntos
muy vulnerables a la intercepción de paquetes, ya que un atacante puede llegar a interceptar
todos los paquetes que pasen a través del mismo.
El tráfico capturado incluye todos los datos que no vayan cifrados, pero también toda la
información de identificación de usuarios que viaje en texto claro.
Hay disponibles gran cantidad de aplicaciones que permiten la captura de paquetes que
viajan por la red, quizás la más conocida y extendida sea Wireshark. Esta herramienta permite
además capturar y guardar el tráfico para su posterior análisis.

4.3.4. Análisis de metadatos

Los metadatos son campos de texto que van incluidos en gran cantidad de archivos, se puede
encontrar información sobre la fecha de creación y modificación, usuario que lo ha creado,
programa utilizado para su edición, . . . Estos ficheros pueden además estar proporcionando
información sensible como puede ser nombres, teléfonos, direcciones de correo, etc.
Los metadatos son una fuente invisible de fuga de información que en muchas ocasiones es
ignorada o incluso desconocida. Es buena práctica eliminar este tipo de información de todos
aquellos documentos hechos públicos por parte de la organización.

4.4. Ataques basados en la mala administración de sistemas

No se puede hacer una separación muy estricta entre algunos de los ataques que se van a
ver en este apartado y los de los apartados siguientes. Se tomará el riesgo de tener que hablar
de ataques mixtos, que se aprovechan de vulnerabilidades de software o de la implementación
de protocolos de red y de mala administración a la vez. Se puede hablar de los siguientes tipos
de ataques:
Robo de nombres de usuario y de contraseñas asociadas.
Acceso basado en relaciones de confianza mal administradas.

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.

Como parte de un ataque muy sofisticado, en el que se trata de “convencer” al objetivo

que cree una sesión TCP con nosotros.
Como parte de un ataque de denegación de servicio, en el que, para tener éxito, basta con
que el atacado acepte paquetes de la dirección IP suplantada.

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

4.5. Ataques basados en vulnerabilidades de los protocolos de red

Muchos de los protocolos de la pila TCP/IP están diseñados pensando en un ambiente ami-
gable en el que no hay por qué esperar ningún tipo de actuación maliciosa o criminal.
El protocolo SMTP no exige autenticación, lo que permite enviar un mensaje de correo elec-
trónico a cualquiera, poniendo como dirección de correo saliente la que se desee y como nombre
de máquina también el que se quiera, haciendo lo que se podría llamar suplantación de correo
electrónico. Al no pedir ningún tipo de autenticación para el envío de correos, el servidor SMTP
puede ser utilizado por un atacante para el envío masivo de correos electrónicos no deseados
(spam) desde el servidor.
En el apartado anterior se ha hecho referencia a los engaños a encaminadores. Hay protocolos
de encaminamiento como RIP o IGRP que no disponen de ningún método de autenticación,
siendo especialmente sencillo realizar las mismas operaciones citadas en el apartado anterior.
Otra manera de engañar a un encaminador es generar mensajes ICMP (Internet Control Message
Protocol) de tipo redirect incorrectos, indicando que la ruta a usar es la que interese para recibir
el tráfico deseado.

4.5.1. Ataques Man-in-the-Middle

En este tipo de ataques el atacante trata de situarse entre dos terminales legítimos, haciendo
que la comunicación entre ambos pase a través de él.
Entre este tipo de ataques encontramos los de suplantación de un servidor DNS, lo que se
conoce como DNS Spoofing. DNS es un servicio que tampoco requiere autenticación, cuando un
terminal envía un mensaje de traducción al sistema, este no comprueba quién ha respondido a
dicho mensaje. Un atacante puede interceptar dicha petición y responder a la petición del cliente
haciéndose pasar por su servidor DNS y proporcionarle una dirección IP que no se corresponde
al servicio que el cliente está solicitando.
Dentro de una LAN las diferentes máquinas conectadas necesitan saber la dirección MAC
de los otros equipos con los que se desean conectar. Para ello hacen uso del protocolo ARP. Se
envía un paquete de solicitud ARP broadcast que contiene la dirección IP por la que se pregunta
y se esperará a que la máquina con dicha dirección IP le envíe un paquete de respuesta ARP
indicando qué dirección MAC corresponde a su dirección IP.
El protocolo ARP no tiene ningún mecanismo de autenticación. Un atacante puede intercep-
tar las peticiones ARP de una máquina conectada a la misma LAN, y responder que la dirección
IP del servicio destino corresponde a su propia MAC. Esta técnica es conocida como ARP Spoo-
fing.
Otro protocolo objeto de ataques de este tipo es DHCP, que permite a un equipo conectado a
una red obtener la información necesaria para configurar su conexión IP a dicha red. Un atacante
puede establecer un servidor DHCP falso (Rogue DHCP) el cual atenderá aquellas peticiones
DHCP que reciba, proporcionando al usuario una dirección IP válida para la red a la que se
conecta, pero a su vez proporcionando su propia dirección IP como puerta de enlace y servidor
DNS.

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.

4.7. Ataques de denegación de servicio (DOS)

Estos ataques, conocidos por sus siglas en inglés Denial Of Service, tienen como objetivo que se
pierda el acceso a un recurso. Habitualmente, lo consiguen sobrecargando el uso de un recurso
interno, entre los cuales los más típicos son el disco, el ancho de banda, alguna de las muchas
tablas internas de gestión de aplicaciones y sistemas o buffers de memoria.
Se pueden clasificar de la siguiente manera:
Ataques DOS basados en peculiaridades de protocolos.
Ataques DOS basados en malas implementaciones de aplicaciones.
Ataques DOS basados en SYN floods.

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.

4.8. Ataques por medio de código malicios

Otro tipo de ataque muy peligroso es el de los llamados generalmente virus informáticos.
Unos pueden aprovecharse de vulnerabilidades de aplicaciones concretas para obtener informa-
ción o para dejar un troyano. Otros pueden tener como objetivo simplemente hacer inoperativo
un sistema, una red o una aplicación. ¿Qué son los virus?.
Los virus informáticos son programas con la capacidad de replicarse a sí mismos sin el
consentimiento del usuario. Existen muchos tipos de virus, de acuerdo al lugar donde se alojan
en el ordenador o para lo que están programados. Dependiendo de su forma de actuar, podemos
definir varios tipos de software malicioso:

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.

5.2. Controles de acceso físico a sistemas

La seguridad física debe ser tenida en cuenta en cada sitio de una forma particular. No
se puede hacer una aproximación completa, pues la puesta en marcha será inevitablemente
específica. Pero sí se puede hacer un análisis de los elementos generales involucrados, para
intentar ayudar a formular un plan, una política de seguridad física, adecuada.
Para saber hasta qué punto resulta importante la seguridad física, podemos hacernos las
siguientes preguntas:
En cada ordenador o dispositivo físico de trabajo, ¿hay más de una persona que tenga
acceso físico?
Si una persona tuviera un problema mental grave y rompiera el dispositivo con un martillo,
¿qué daños produciría a la organización?

¿Qué sucedería si alguien de la competencia directa de la organización accediera a él sin

saberlo nadie de la organización?
Si hubiera un desastre grave en el edificio, ¿desaparecerían los datos y la información
relevantes de la organización?

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.

5.3. Control de acceso lógico a sistemas

Cualquier acceso lógico está asociado con dos operaciones:
Identificación, mediante la que el usuario dice quién es.
Autenticación, mediante la que el usuario prueba que realmente lo es.
Una vez autenticado, el sistema de control de acceso impone qué puede hacer el usuario y qué
no puede hacer. El sistema de control de acceso debe hacer bien dos cosas:
1. Debe permitir el acceso al usuario correctamente autenticado.
2. Debe impedir el acceso a los demás.
Debería, a ser posible, guardar también un buen registro de auditoría de todas las entradas e
intentos fallidos.
El intento de acceso se puede realizar:
En local, desde la propia consola, en el PC de usuario.
En remoto, desde una localización remota al equipo con el que se va a conectar, a través de
la red telefónica o a través de Internet.

La validación de acceso, el control de acceso, la comprobación de la información de la autenti-

cación puede hacerse:
En la base de datos de información local del sistema donde se conecta el usuario.
En una base de datos residente en una máquina servidora de autenticación, por ejemplo
un servidor NIS+ en UNIX o en un controlador de dominio en el caso de Windows Server.
A través de un NAS, dentro de una arquitectura AAA.
Sea como sea, las medidas de identificación y autenticación se centran en una de tres cosas
distintas:

Algo que se sabe, que se conoce, típicamente contraseñas.

Algo que se es, medidas que utilizan la biometría.
Algo que se tiene, los access tokens.
La aproximación tradicional es la contraseña. Las medidas básicas de una buena gestión de
contraseñas serían:
1. Si el acceso va a ser remoto, a través de una red, implementar el uso de ssh en lugar de
Telnet o de rlogin.
2. No disponer de más de una cuenta privilegiada en cada máquina.

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.

5. Habilitar el cambio de contraseñas periódico y obligatorio, que dependerá de la política

de seguridad.

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.

5.4. Otros controles simples de acceso a la información

Se debe ahora hacer énfasis en varios aspectos que permiten mejorar la seguridad de las
redes:
La utilización de sistemas de ficheros suficientemente seguros.
La posibilidad de encriptación de ficheros en el sistema de ficheros.
La necesidad de la destrucción de datos importantes de los discos que se dejan de utilizar.
Protección básica contra virus y código malicioso.
Los nuevos retos que suponen los terminales móviles.
Uso de cifrado en redes inalámbricas.
En los sistemas de hoy en día, se puede hablar del sistema de ficheros FAT y de todos los demás.
FAT no permite imponer una granularidad mínima. Cualquier usuario que ha accedido a un
sistema, cuyos ficheros estén organizados mediante FAT tiene acceso a cualquiera de ellos. Si se
puede, en todos los casos, se debe evitar el uso de FAT en las máquinas de la organización.
Los sistemas UNIX y LINUX disponen de la capacidad de encriptar ficheros, simplemente
utilizando una clave de criptografía simétrica o asimétrica, haciendo prácticamente imposible
obtener la información sin conocer la clave. Se hace normalmente mediante un programa cono-
cido como PGP. Igualmente, en sistemas Windows Server se dispone también de esta capacidad,
a través del Encrypting File System o EFS.
A nivel mundial cada año se retiran millones de discos. De ellos, sólo alrededor de un 10 %
han sido saneados correctamente, y alrededor del 64 % contienen sistemas de ficheros completa-
mente montables. Para evitar problemas, se debe aclarar, dentro de la política de seguridad qué
hacer con los discos que se retiran:
Destruir físicamente el disco, dejándolo inutilizable.
Destruirlo magnéticamente, dejándolo igualmente inutilizable.
Sobrescribir los datos del disco, para que no se puedan recuperar.
Para terminar, hay que citar la problemática que supone el uso de redes inalámbricas abiertas
que no usen ningún tipo de cifrado. Cuando se usan este tipo de redes la información viaja por
el aire a disposición de cualquiera que quiera capturar el tráfico. Al usar redes inalámbricas sin
cifrado, dicha información no sólo podrá ser capturada sino que además será legible para el
atacante por no ir dicha información cifrada.

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.

6.2. ¿Qué es una política de seguridad?

Una política de seguridad se define como “una serie de normas que deben cumplir todas las
personas que tengan acceso a cualquier información y/o tecnología de una organización”.
El propósito principal es informar a los usuarios, trabajadores y personal de dirección, de los
requisitos obligatorios para proteger los valores tecnológicos y la información de la organización.
Otro propósito es proporcionar una base para adquirir, configurar y auditar los sistemas de
ordenadores y las redes.
El uso adecuado de las herramientas de seguridad también debería ser parte de la política
de seguridad. Los objetivos que se buscan vendrán determinados por la capacidad que se tenga
de cumplir con una serie de aspectos, como son:
Debe poderse implantar.
Debe entenderse.
Debe hacerse cumplir.

25
 Debe definir responsabilidades.
Debe permitir que siga realizándose el trabajo normal.

Debe ser exhaustiva.

Debe incluir mecanismos de respuesta.
Debe tener mecanismos de actualización.
Debe cumplir la legislación.

Se ha de contemplar el principio de privilegio mínimo, que consiste en tratar de minimizar

el número de usuarios con privilegios de administrador, el conjunto de equipos externos con
acceso a sistemas locales y, en general, el número de situaciones en las que alguien o algo tienen
privilegios de acceso.
Otro aspecto importante que se debe tratar de conseguir es el tener más de un nivel de
defensa y, a poder ser, de distinta naturaleza.
Es una buena idea disponer de un punto central de gestión de la seguridad, en el que centra-
lizar la gestión de la autenticación, autorización, del tráfico de seguridad, que soporte así mismo
el registro de eventos centralizado y las alarmas.
Otra buena técnica es la de identificar los puntos más débiles de la organización.
Es importante seguir también el principio de “cierre completo”, que consiste en garantizar
que, en el caso de ataque con éxito a un componente de seguridad, el sistema de seguridad no
pasa a permitir el acceso completo a toda la red, sino a no permitir ningún acceso.
Quizás el más importante es el principio de simplicidad, que persigue que se cumplan todos
los anteriores a la vez que se puede gestionar todo el sistema de manera simple y entendible.
Es el principio que debe dirigir la propia construcción de cada norma, que no debería ser de un
tamaño mayor de dos páginas.
Otros aspectos de diseño que pueden ayudar a imaginarse cómo será la política de seguridad
son:
Hay que elegir al equipo de desarrollo de la política, pensando en todos los grupos de la
organización.
Debe haber una “política de políticas” que establezca el proceso de diseño de cada política.

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.

Normas de protección de la información.

Normas sobre la seguridad perimetral.
Normas básicas de seguridad física.
Normas sobre respuestas a incidentes.

Normas de contraseñas aceptables.

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.

6.3. Aspectos físicos de la política de seguridad

Debe estar claramente estipulado quién tiene derecho a acceder, y en qué casos concretos, a
cada uno de los siguientes dispositivos:
Encaminadores, especialmente los de perímetro de seguridad.
Conmutadores y puntos de acceso inalámbrico.
Servidores, especialmente aquellos que dispongan de la información más sensible de la
organización.
Cualquier tipo de cortafuegos.
Cualquier tipo de punto extremo de una red privada virtual, que suelen ser, realmente,
encaminadores y cortafuegos.
Cualquier manejador de medios de almacenamiento.
Así mismo, la política de seguridad debe delimitar claramente la forma en la que se transporta
información sensible en dispositivos físicos. Igualmente, debe haber unas normas claras sobre el
control de acceso a los edificios donde estén situados los ordenadores y redes de la organización,
identificando:
¿Quién puede entrar en el edificio?
¿Quién puede entrar a determinadas salas del edificio, donde residan las máquinas identi-
ficadas como especialmente sensibles?
¿Cómo debe garantizarse tal tipo de acceso?
¿Quién puede acceder a determinados dispositivos específicos de salida, como impresoras?
¿Qué documentos no deben tener copias en papel sueltas?

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?

¿Es necesaria la presencia de guardias de seguridad?

Se ha de señalar la importancia de disponer de los procedimientos para la copia periodística de
la información, especialmente de la más relevante. Se debe disponer al menos de copias de:
La información de ordenadores de los sistemas centrales.

La información de ordenadores de las redes de área local.

La información de aplicaciones y de bases de datos.
La información sobre cuentas de usuario y privilegios de acceso de las mismas.

Incluso podría ser necesario plantearse la necesidad de tener un centro en otro lugar físico.

6.4. Aspectos lógicos de la política de seguridad

Se puede separar lo que se denomina normas básicas como:
Política de uso aceptable.
Política de acceso remoto.
Política de protección de la información.

Política de seguridad perimetral, aunque ésta implicará también procedimientos de confi-

guración de encaminadores y posiblemente de cortafuegos.
Política de protección antivirus.
Política de contraseñas, de la que dependerán los procedimientos de servidores, estaciones
de trabajo, portátiles y otros dispositivos móviles y acceso remoto y a través de redes
privadas virtuales.
Política de actuación frente a incidencias.
Entre las que no serían normas básicas se encuentran:

Política de uso de los sistemas de detección de intrusiones.

Política de gestión de los logs de sistemas y de auditoría.
Política de administración de los laboratorios de seguridad, en los que se harán todas las
pruebas posibles fuera de la red real, en búsqueda de posibles vulnerabilidades.

Política de comunicaciones inalámbricas.

Política de uso de redes privadas virtuales.
Cualquier otra política aplicable a las características de la organización.

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.

6.5. Aspectos legales de la política de seguridad

Cualquier política de seguridad debe tener en cuenta obligatoriamente el panorama legal
actual en España. Es necesario conocer al menos las leyes que prácticamente siempre habrá que
tener en cuenta.

6.5.1. Ley Orgánica de Protección de Datos Personales (LOPD)

El Tribunal Constitucional define la Protección de Datos de Carácter Personal como el dere-
cho fundamental que garantiza a toda persona
. . . un poder de control sobre sus datos personales, sobre su uso y destino, con
el propósito de impedir su tráfico ilícito y lesivo para la dignidad y derecho del
afectado.
La legislación afecta a cualquier empresa u organismo público de nuestro país, porque todos
ellos manejan datos de carácter personal de personas físicas.
Se pasa ahora a describir algunos de los aspectos más prácticos de la LOPD y su reglamento.
La LOPD establece varios tipos de datos personales según dos criterios:
1. Según su importancia. Clasifica a los datos personales en función de la relación que tienen
esos datos personales con el derecho a la intimidad. Se refiere a la ideología, religión,
creencias, afiliación sindical, origen racial, vida sexual, etc.
2. Según su seguridad. La clasificación se realiza basándose en las medidas de seguridad
que se deben cumplir cuando se posean datos personales, y existen tres niveles:

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.

El responsable de un fichero o tratamiento es la entidad, persona u órgano administrativo que

decide sobre la finalidad, el contenido y el uso del tratamiento de los datos personales. Una
empresa es responsable de los ficheros que contienen datos sobre sus empleados y clientes.
El encargado del fichero o tratamiento es la persona física o jurídica, pública o privada, u
órgano administrativo que, solo o junto a otros, trate datos de carácter personal por cuenta del
responsable del fichero, gracias a la existencia de un contrato de servicios que define el ámbito
de actuación y la prestación del servicio.
La Agencia Española de Protección de Datos (AEPD) protege los derechos de los ciuda-
danos, es el ente encargado de velar por el cumplimiento de la normativa, y actúa de forma
totalmente independiente de las Administraciones Públicas.
La LOPD indica que se deben adoptar las medidas técnicas necesarias para garantizar la
seguridad de los datos personales y evitar su alteración, pérdida, tratamiento o acceso no auto-
rizado.

6.5.2. Ley de Servicios de la Sociedad de la Información y Comercio Electrónico (LSSICE)

La LSSICE tiene como objeto:
. . . la regulación del régimen jurídico de los servicios de la sociedad de la in-
formación y de la contratación por vía electrónica, en lo referente a las obligaciones
de los prestadores de servicios, incluidos los que actúen como intermediarios en la
transmisión de contenidos por las redes de telecomunicaciones, las comunicaciones
comerciales por vía electrónica, la información previa y posterior a la celebración de
contratos electrónicos, las condiciones relativas a su validez y eficacia y el régimen
sancionador aplicable a los prestadores de servicios de la sociedad de la información.
Esta ley hace referencia a aspectos de los servicios de la sociedad de la información, en particular,
al comercio electrónico en el mercado interior.
Uno de los aspectos más importantes de la ley consiste en la definición de “servicios de la
sociedad de la información”. Se refiere a toda actividad que se realice en la red “siempre que
represente una actividad económica para el prestador”, con lo que se entiende que el prestador
obtiene un beneficio económico como resultado de ofrecer tal servicio.
Siguiendo las pautas comunitarias, se prevé que las asociaciones y organizaciones comer-
ciales, profesionales y de consumidores, elaboren y apliquen códigos de conducta de ámbito
nacional.
Los códigos de conducta deberán ser accesibles por vía electrónica en castellano y, en cada
uno de los distintos ámbitos territoriales de España en que se ofrezcan servicios, también en la
correspondiente lengua oficial.
Se hace ahora un pequeño resumen de las obligaciones que deben de cumplir las empresas
que se dediquen a este tipo de actividades. La LSSICE obliga a que tales empresas muestren, en
su página web, la siguiente información:
Denominación social, NIF, domicilio y dirección de correo electrónico.
Códigos de conducta a los que se adhiere.
Precios de los productos o servicios que ofrecen.

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.

6.5.3. El Esquema Nacional de Seguridad (ENS)

ENS regula el acceso electrónico de los ciudadanos a los Servicios Públicos. Su objeto es es-
tablecer la política de seguridad en la utilización de medios electrónicos y está constituido por
principios básicos y requisitos mínimos que permitan una protección adecuada de la informa-
ción. Los objetivos principales del ENS son los siguientes:
Crear las condiciones necesarias de confianza en el uso de los medios electrónicos que
permitan a los ciudadanos y a las Administraciones Públicas, el ejercicio de derechos y el
cumplimiento de deberes a través de estos medios.

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.

El ámbito de aplicación del ENS es:

La Administración General del Estado, Administraciones de las Comunidades Autónomas
y las Entidades que integran la Administración Local.
Los ciudadanos en sus relaciones con las Administraciones Públicas.

Las relaciones entre las distintas Administraciones Públicas.

Define lo que entiende como seguridad de las redes y la información de la siguiente manera:
. . . la capacidad de resistir, con un determinado nivel de confianza, los accidentes
o acciones ilícitas o malintencionadas que comprometan la disponibilidad, autentici-
dad, integridad y confidencialidad de datos y aplicaciones.
Los principios básicos que considera el ENS están muy relacionados con el estándar ISO/IEC
27001.

6.6. Aspectos organizativos de la política de seguridad

Analizaremos brevemente algunos de los aspectos organizativos más significativos que hay
que tener en cuenta siempre que se quiera hacer una política profesional. En este sentido se
muestra el que seguramente sea uno de los estándares más importantes, el ISO/IEC 15408.
También presentaremos un estándar internacional aceptado ampliamente, el ISO/IEC 27001,
y haremos una breve introducción a la gestión de la seguridad dentro del marco de buenas
prácticas conocido con el nombre de ITIL y de su relación con el estándar ISO/IEC 20000.

6.6.1. El estándar ISO/IEC 15408 Common Criteria

En el año 2000 varios países firmaron un convenio sobre el reconocimiento de los certificados
de criterios comunes en el campo de la seguridad de la tecnología de la información. Hay que
remarcar una serie de ideas y datos importantes sobre este convenio:
El conjunto de los países miembros representaban el 85 % del mercado mundial de la
tecnología de la información.
El convenio parte de la premisa de que la utilización de productos y sistemas de tecnologías
de la información, cuya seguridad ha sido certificada, es una de las garantías principales
para proteger la información y los sistemas que la manejan.

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.

Entre los objetivos que motivan el convenio figuran:

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

6.6.2. El estándar ISO/IEC 27001

Esta norma es otro estándar internacional, dedicado a la organización de la seguridad de
las tecnologías de la información. Establece los requisitos que debe cumplir un SGSI (Sistema
de Gestión de la Seguridad de la Información) para su certificación en términos de procesos de
seguridad a nivel organizativo.
Un SGSI es una parte del sistema de gestión de una organización, basado en una aproxima-
ción a los riesgos del negocio, que permite establecer, implementar, operar, monitorizar, revisar,
mantener y mejorar la seguridad de la información de una organización.
La creación de un SGSI es una decisión estratégica de la organización y debe ser apoyada y
supervisada por la dirección.
ISO/IEC 27001 aplica una aproximación por procesos a la gestión de la seguridad, haciendo
especial énfasis en la importancia de:

La necesidad de establecer una política de seguridad y unos objetivos concretos.

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.

La mejora continua basada en la medición continuada de los objetivos.

ISO/IEC 27001 adopta además el modelo PDCA (ciclo de Demming, Plan-Do-Check-Act) y el mo-
delo se aplica para estructurar todos los procesos del SGSI. Las actividades principales asociadas
al modelo PDCA aplicadas al SGSI son:

Planificar: establecer políticas, objetivos, procesos y procedimientos que sean relevantes

para la gestión de los riesgos y para mejorar la seguridad de la información.
Hacer: implementar y operar los elementos del SGSI (política, controles, procesos y proce-
dimientos).

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.

6.6.3. Las buenas prácticas de ITIL™ y la norma ISO/IEC 20000

ITIL (Information Technology Infraestructure Library) es la Biblioteca de Infraestructuras de Tec-
nologías de la Información. Son un conjunto de 5 libros principales que contienen un enorme
conjunto de buenas prácticas para la gestión de los servicios de tecnologías de la información.
ITIL se basa en la idea del ciclo de vida del servicio TI. Un servicio TI debe planificarse
(fase de estrategia), diseñarse (fase de diseño), implementarse (fase de transición), operarse y
mantenerse (fase de operación) y debe estar sujeto siempre al ciclo PDCA de mejora continua.
ITIL es una aproximación muy sofisticada de todas las tareas a realizar para ofrecer y con-
trolar servicios TI, aproximación por procesos parecida a lo visto en la sección anterior, pero en
este caso teniendo en cuenta muchos más procesos.
Cualquiera de estos procesos de ITIL ejecuta una serie de actividades que utilizan datos
de entrada y crean unos resultados de salida alineados con los objetivos de cada proceso en
particular.
Para llevar todo esto a cabo cada proceso usa una serie de recursos y capacidades, organiza-
das a su vez en funciones. Los recursos y capacidades no son más que la financiación, el personal
y los aspectos básicos necesarios para la puesta en marcha de cualquier estructura de este estilo.
Hay dos procesos ITIL especialmente significativos para este tema:
El proceso Gestión de la seguridad, que es responsable del diseño de la política de seguri-
dad de cualquier servicio TI. ITIL hace aquí uso exhaustivo de la terminología y los detalles
de la norma ISO/IEC 27001, haciendo especial referencia a la importancia de implantar un
SGSI.

El proceso de Gestión de accesos, que es el responsable de que se cumpla la política de

seguridad diseñada en el proceso anterior para cada servicio.
Es importante señalar que una organización no puede certificarse en ITIL, al no ser éste un
estándar sino un conjunto de buenas prácticas. No obstante, ITIL sí está relacionado con una
norma muy importante en el mundo de la Gestión de Servicios TI: el estándar ISO/IEC 20000,
que permite certificar un servicio como que cumple todo un conjunto de buenas prácticas de
implementación de gestión de servicios, que van mucho más allá de la gestión de la seguridad.

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.

7.2. Herramientas para la puesta en marcha de la política de seguridad

Recordemos lo que se ha denominado el proceso de seguridad, mostrado en la Figura 1.

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

Figura 1: Las fases del proceso de seguridad.

Los elementos no criptográficos que hay que tener en cuenta dentro de la fase de implemen-
tación son:

Medidas básicas, físicas y lógicas, analizadas en el tema 5.

Los cortafuegos, que son dispositivos variados que implementan una serie de funciones
de filtrado de mensajes.
Hay que recordar que la configuración de tales cortafuegos dependerá de lo que se haya decidido
desarrollar como política de seguridad.
Dentro de la fase de monitorización se debe tener en cuenta:
Los procedimientos clásicos de auditoría y de análisis de logs, que conllevan hacer una
exploración, en busca de señales “extrañas”, de los distintos registros de actividad de
sistemas y dispositivos de seguridad.

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.

Los equipos de ataque, grupos de personas, internos o externos a la organización, que

se dedican a buscar posibles vulnerabilidades en sistemas, así como en seguridad física y
lógica.
Los analizadores (o scanners) de vulnerabilidades, programas especializados en buscar
problemas de seguridad en sistemas operativos, aplicaciones y dispositivos de seguridad,
que, por un lado, ayudan a los equipos ante los ataques citados y, por otro lado, sirven
para buscar en sistemas bugs de seguridad.
Para acabar esta sección, es importante remarcar la diferencia entre los dos niveles de trabajo
con todas estas herramientas:
1. Un nivel de conocimiento de cómo configurar las herramientas.

2. Un nivel de conocimiento de la seguridad deseada, es decir, de la política de seguridad

que se debe aplicar.
Debe quedar claramente estipulada la mayor relevancia del segundo nivel sobre el primero.

7.3. Otros elementos a tener en cuenta

Los procedimientos y herramientas necesarios para mantener la fiabilidad del sistema, la alta
disponibilidad de la información, no son criptográficos y contemplan, en su diseño, técnicas de
tolerancia a fallos. Estas técnicas consisten en que el software o el hardware proporcionen una
cierta redundancia frente a posibles eventos negativos que pueden ocurrir.
De entre estas técnicas, se pueden resaltar las siguientes:
Unidades de disco redundantes.
Copia de seguridad de los datos.

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.

8.2. Ventajas, inconvenientes y tipos de cortafuegos

Entre los puntos fuertes de los cortafuegos, se pueden citar:
Se pueden utilizar como un punto esencial de aplicación de la política de seguridad.
Pueden soportar técnicas avanzadas de autenticación de manera eficaz.
Suelen resultar un buen sitio para centralizar alarmas y registros de tráfico.
Comparados con un sistema de propósito general tienen menos configuración.
Comparados con un sistema, necesitan muy pocos usuarios definidos para llevar a cabo su
configuración y mantenimiento.
La política general de diseño del tráfico suele ser restrictiva: no se deja pasar ningún tipo de
tráfico, salvo el que esté explícitamente permitido.
Se debe remarcar también cuáles son los puntos débiles de los cortafuegos, entre ellos:
Su uso puede significar el dejar de utilizar una serie de servicios que no se consideren
seguros a través de un cortafuegos.
Pueden provocar una sensación de seguridad falsa.
Si no se usan conjuntamente con otras medidas de seguridad se produce la centralización
de todas las medidas en un único sistema.
Si son muy sofisticados, pueden necesitar una configuración muy complicada.
Pueden representar un cuello de botella para el tráfico de red.
Además, ningún cortafuegos puede evitar problemas que se originan en la parte protegida de la
red.
Aunque no hay una tipología oficial, normalmente se habla de cuatro tipos de cortafuegos:
1. Los filtros de paquetes, que suelen ser encaminadores que filtran el tráfico basándose en
combinaciones de diferentes campos de las cabeceras IP, TCP y UDP de cada mensaje.
2. Gateways de aplicaciones, también llamados “servidores proxy”, que suelen ser equipos
intermedios que aceptan peticiones entrantes de servicios de red y realizan las llamadas
adecuadas a favor de cada cliente del servicio correspondiente.
3. Cortafuegos de tipo stateful inspection, o de filtrado dinámico de paquetes, que son capaces
de mantener el estado de cada sesión a través del cortafuegos y cambiar las reglas de
filtrado dinámicamente.
4. Cortafuegos híbridos, que suelen tener unas propiedades que son resultado de la combi-
nación de las propiedades de los citados anteriormente.

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

Figura 2: Topología de red del ejemplo de filtrado de paquetes.

Origen Destino Interfaz origen Interfaz destino Protocolo Puerto Acción

192.168.0.0 * * * * * Denegar
192.168.1.0 192.168.0.0 * * * * Permitir
* 192.168.0.0 * * * * Denegar
* 124.21.0.0 * * * * Denegar
192.168.1.0 * * * TCP 80 Permitir
* 155.15.11.0 * * * * Denegar
Tabla 2: Ejemplo de tabla de reglas de filtrado.

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.

8.3.1. Las ACL (Listas de Control de Acceso) de los encaminadores Cisco

Las Access Control Lists, o ACLs, de los encaminadores de Cisco Systems son de dos tipos:
standard y extended.
Las ACL de tipo standard está compuestas de una serie de reglas ordenadas (ACE), cada
una de las cuales sólo usan como criterio la dirección IP de origen del mensaje, y tienen como
sintaxis:

router(config)# access-list N {permit|deny} dir-IP-origen [máscara]

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:

router(config)# interface nombre-interface

router(config)# ip access-group N {in|out}

Por “nombre-interface” se refiere a la sintaxis propia de Cisco, por ejemplo ethernet-0. N es el

número que identifica la ACL que se quiere asociar a la interfaz. Finalmente, para indicar que
la ACL se aplica al tráfico entrante por esa interfaz, se debe indicar in y si se aplica al tráfico
saliente por esa interfaz se debe indicar out.
Imaginemos que queremos proteger una red interna, conectada al interface ethernet-1, de
manera que dejaremos pasar todo el tráfico proveniente de la red externa (conectada al interface
ethernet-0) menos el que venga de la red 144.21.0.0. La ACL y su aplicación sería:

router(config)# access-list 1 deny 144.21.0.0 0.0.255.255

router(config)# access-list 1 permit any
router(config)# interface ethernet-1
router(config-if)# ip access-group 1 in

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:

router(config)# access-list N {permit|deny} protocolo dir-IP-origen

[mascara-origen] [op puerto-origen] dir-IP-destino [mascara-destino]
[op puerto-destino]

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

le: menor o igual que

gt: mayor que
ge: mayor o igual que
eq: igual a

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:

No dejar entrar el tráfico Telnet externo, salvo de la dirección 155.15.11.1.

Permitir el tráfico, de cualquier tipo, de la dirección 133.11.1.3.
No dejar entrar tráfico general salvo de la red 144.21.0.0.
La lista de acceso sería:

router(config)# access-list 101 permit ip host 133.11.1.3 any

router(config)# access-list 101 permit tcp 155.15.11.1 any eq 23
router(config)# access-list 101 permit ip 144.21.0.0 0.0.255.255 any

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.

8.5. ¿Qué se puede mejorar?

Más allá de lo ya analizado, suele haber varias aproximaciones:
Trabajar con tecnología stateful inspection, que se analizará en el siguiente tema.
Reunir varias de las tecnologías citadas junto con distintos tipos de sistemas de autentica-
ción, AAA, para crear cortafuegos mucho más sofisticados.
Crear distintas arquitecturas o topologías de seguridad en torno al cortafuegos.
Esta última idea consiste en expandir la idea de una única máquina en la intersección de varias
redes y sustituir una máquina por varias. En este contexto hay que introducir siempre el concepto
de red DMZ (zona desmilitarizada), que es una red directamente enlazada con el cortafuegos
que se esté utilizando.
Se suele trabajar con una DMZ para colocar en ella aquellos servicios de la red de la orga-
nización que se desea estén accesibles por Internet, pero que no se quieren tener en las mismas
redes de la organización por cuestiones de seguridad.
También se puede ir más allá y crear una arquitectura más “paranoica” consistente en dos
DMZs, una externa y otra interna. La DMZ externa contendrá elementos que sean menos sensi-
bles desde el punto de vista de la seguridad. Esta topología se crea a partir de dos cortafuegos,
el primero separando la red externa de la DMZ externa, y el segundo separando la DMZ externa
de la DMZ interna y a la vez de la red interna de la organización.
Estas soluciones tan seguras tienen como talón de Aquiles el hecho de que habrá que contar
con un grupo de personas encargado de configurar distintas máquinas, con distintas tecnolo-
gías, de manera que todas cumplan el papel que tengan asignado en la política de seguridad
correspondiente.

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.

9.2. Caso de estudio, el modelo IPTables

Hoy en día IPTables viene preinstalado en la mayoría de distribuciones Linux disponibles,
siendo por tanto uno de los cortafuegos más utilizados.
El objetivo de este epígrafe es presentar una introducción a la administración de esta potente
herramienta.

9.2.1. Procesado de paquetes en IPTables

Todos los paquetes que son inspeccionados por IPTables pasan por una serie de tablas o
cadenas (chains). Cada una de estas tablas está dedicada a un determinado tipo de actividad y
está controlada por un conjunto de reglas específicas para ese tipo de tráfico.
IPTables tiene tres tablas. La primera de ellas es la tabla mangle, la cual se encargará de
modificar los bits de la cabecera TCP para definir los valores de la calidad de servicio (QoS).
La siguiente tabla corresponde a la tabla de filtrado y es la que se encarga de la función de
filtrado de paquetes, es decir, la que decidirá si un paquete puede continuar su camino o no.
Esta tabla está compuesta de tres cadenas con sus correspondientes reglas de filtrado:
FORWARD: filtra los paquetes dirigidos a la red protegida por el cortafuegos.
INPUT: filtra los paquetes dirigidos al cortafuegos.
OUTPUT: filtra los paquetes que se originan desde el cortafuegos.
La tercera y última tabla es la que gestiona la traducción de direcciones de red (NAT). Esta tabla
contiene dos cadenas con sus correspondientes reglas de filtrado:
PREROUTING: hace NAT para los paquetes en los que es necesario cambiar la dirección
IP de destino.
POSTROUTING: hace NAT para los paquetes en los que es necesario cambiar la dirección
IP de origen.
La Tabla 3 muestra un resumen de las distintas tablas que componen IPTables.
Inicialmente los paquetes son examinados por la cadena PREROUTING de la tabla Mangle.
A continuación se examinarán en la cadena cadena PREROUTING de la tabla NAT y se com-
probará si es necesario modificar la dirección IP de destino (DNAT). Una vez inspeccionado por
estas dos cadenas el paquete es encaminado.

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.

Tabla 3: Resumen de tablas y cadenas de IPTables.

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.

9.2.2. Sintaxis de las reglas IPTables

Cuando un paquete llegue al cortafuegos irá pasando por las distintas tablas en el orden en
que se ha presentado. Dentro de cada cadena el paquete se comparará de forma secuencial con
las distintas reglas de la misma, si el paquete cumple todos los criterios de alguna de las reglas
se ejecutará la acción indicada por dicha regla.
Cuando un paquete cumple una regla de una cadena, se ejecutará la acción indicada por la
misma y no se verificará con las siguientes reglas de la misma cadena. Por tanto, el orden en que
se añadan dichas reglas debe ser tenido en consideración.
La estructura de una regla de IPTables sigue el siguiente patrón:

#iptables -t <tabla> -[tipo_operacion] [cadena] -[parametros] -j <accion>

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.

Tabla 4: Tipos de operaciones en IPTables.

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:

#iptables -P INPUT DROP

#iptables -P OUTPUT DROP
#iptables -P FORWARD DROP

42
 Paquete Entrante

Red A

Tabla NAT Tabla Mangle

Cadena POSTROUTING Cadena PREROUTING

Tabla Mangle Tabla NAT

Cadena POSTROUTING Cadena PREROUTING

Tabla Filter
Enrutado
Cadena OUTPUT

Datos para el
Sí cortafuegos? No

Tabla NAT Tabla Mangle Tabla Mangle

Cadena OUTPUT Cadena INPUT Cadena FORWARD

Tabla Mangle Tabla Filter

Cadena OUTPUT Cadena FORWARD

Tabla Mangle
Enrutado
Cadena POSTROUTING

Respuesta del
firewall Tabla NAT
Cadena POSTROUTING

Procesado local Tabla Filter

Paquete Saliente
de datos Cadena INPUT

Red B

Figura 3: Diagrama de flujo de un paquete en IPTables.

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:

#iptables -A FORWARD -i eth0 -s 0/0 -o eth1 -d 192.168.1.50 -p tcp --dport

80 -j ACCEPT

Al no especificar la tabla la regla se añadirá a la tabla Filter. Es como -t filter.

-A añadirá la regla al final de la cadena FORWARD de la tabla Filter.
-i eth0 especifica que se aplicará a todo el tráfico que provenga del interfaz de red eth0.

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

Tabla 5: Acciones más comunes para las reglas IPTables.

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.

Tabla 6: Criterios de filtrado habituales.

-d 192.268.1.50 indica que se aplicará al tráfico cuyo destino sea la IP 192.168.1.50.

-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:

#iptables -A INPUT -p ICMP -s 0/0 -j ACCEPT

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:

#iptables -A INPUT -p ICMP -j LOG

#iptables -A INPUT -p ICMP -j DROP

9.2.3. Uso de IPTables como puerta de enlace de la red

Se puede configurar IPTables para que por defecto permita el tráfico saliente y en cambio
bloquee el entrante:

#iptables -p INPUT DROP

#iptables -p FORWARD DROP
#iptables -p OUTPUT ACCEPT

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:

#iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

44
 Modificador
-p tcp -sport <port>
-p tcp -dport <port>
-p tcp -syn
-p udp -sport <port>
-p udp -dport <port>
-icmp-type <type>
Descripción
Permite especificar el puerto TCP de origen del paquete.
Permite especificar el puerto TCP de destino del paquete.
Permite especificar paquetes de inicio de conexión TCP (flag SYN
activado).
Permite especificar el puerto UDP de origen del paquete.
Permite especificar el puerto UDP de destino del paquete.
Permite filtrar por el tipo de petición ICMP. Los valores más usados
son echo-reply y echo-request.

Tabla 7: Modificadores de filtrado habituales.

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:

#iptables -A FORWARD -o eth0 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

#iptables -A FORWARD -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

9.2.4. Redirección de tráfico entrante (DNAT)

Si dentro de la red protegida hay alojados servidores que se desean hacer públicos será
necesario usar las opciones NAT de destino (DNAT) que presenta IPTables para redirigir los
paquetes entrantes destinados a dichos servicios.
El primer paso será añadir una regla que permita el tráfico entrante en el puerto correspon-
diente a dicho servicio. En el caso se un servidor SMTP sería:
#iptables -A INPUT -p tcp --dport 25 -j ACCEPT

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):

#iptables -t nat -A PREROUTING -p tcp --dport 25 -j DNAT --to 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).

#iptables -t nat -A POSTROUTING -p tcp --dport 25 -j SNAT --to 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

Como complementario, el comando iptables-restore carga las reglas almacenadas en el

fichero de configuración:
#iptables-restore 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.

9.3. Caso de estudio: el modelo Cisco ASA

ASA (Adaptative Security Appliance) es el nombre genérico de toda una familia de disposi-
tivos de Cisco Systems™. Los dispositivos ASA combinan en una sola máquina características
avanzadas de cortafuegos tipo stateful inspection y de tipo filtro de paquetes, junto con las carac-
terísticas de un sistema de detección de intrusiones muy potente. Se van a describir algunas de
las capacidades no criptográficas más relevantes del ASA.

9.3.1. ¿Qué son los niveles ASA?

El algoritmo ASA es el cerebro del dispositivo ASA. Cada una de las interfaces del ASA tiene
asociado lo que se conoce como nivel de seguridad, un número entre 0 y 100. Una ASA puede
tener hasta 12 interfaces físicas distintas (muchas más virtuales), pero hay siempre al menos
2, la que recibe el nombre de inside con nivel de seguridad igual a 100, y outside con nivel de
seguridad igual a 0. Estos niveles determinan la red considerada más segura y la red considerada
más insegura. Una topología típica de una red con un ASA podría ser la de la Figura 4.

Internet

Red externa
ethernet 0
Ethernet 0 nivel seg. 0
interface outside

ASA Firewall
Ethernet 2

Red interna Red perimetral

ethernet 1 ethernet 2
nivel seg. 100 Ethernet 1 nivel seg. 50
interface inside interface dmz

Figura 4: Topología típica de una red con un ASA.

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.

9.3.2. Configuración básica

Esta configuración pasa por los siguientes puntos:
Asignar un nombre y un nivel de seguridad a cada interfaz, con el comando nameif.
Habilitar y configurar el tipo y la velocidad de cada interfaz, mediante el comando interface.
Asignar una dirección IP a cada interfaz con el comando ipaddress.

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.

9.3.3. Otras características avanzadas de ASA

Una de ellas es su capacidad de filtro de lo que Cisco llama “código activo”. Concretamente
se puede conseguir que no se descargue ningún applet de Java o control de ActiveX desde una
dirección IP sospechosa.
También hay que resaltar la capacidad de filtrar peticiones http a direcciones url concretas,
permitiendo decidir qué sitios web no deben poder visitarse desde una red concreta.
Mediante el uso de la inspección dinámica de seguridad de protocolos, el ASA es capaz
de identificar las asignaciones dinámicas de puertos y permitir el intercambio de datos en estos
puertos durante conexiones específicas.
El ASA dispone también de un IDS, un módulo hardware llamado AIP-SSM, que proporcio-
na servicios de IDS muy avanzados.
El ASA soporta también AAA, autenticación, autorización y contabilidad de uso de recursos
de usuarios, basándose en un mecanismo de tipo proxy, que permite controlar el acceso a un
servidor residente en una de las interfaces desde una máquina residente en otra de las interfaces.
Este mecanismo (cut-through proxy) permite que el usuario se identifique mediante Telnet, FTP
o HTTP.
Se puede también componer una salvaguarda para el caso de que un ASA falle. Concreta-
mente, con la topología de redundancia de ASA (o failover), cuando un ASA falla, otro toma
inmediatamente su lugar. Existen dos formas de hacer esta topología:
La redundancia estándar, en la que los dos cortafuegos ASA están conectados por un cable
especial de failover. En este caso, cuando sucede el cambio de papeles, las conexiones TCP
se pierden y las aplicaciones cliente deben reconectarse.

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.

Se hace importante entender determinadas definiciones, como:

Falso positivo: el hallazgo de una vulnerabilidad por parte de uno de estos buscadores
que, una vez analizada, resulta no serlo.
Falso negativo: una vulnerabilidad de seguridad que el analizador no ha sido capaz de
detectar.

Verdadero positivo: una vulnerabilidad detectada que es real.

Para utilizar los analizadores correctamente hay que considerar también los siguientes puntos:
Ejecutarlos frecuentemente. La herramienta hay que ejecutarla con una periodicidad que
decidirá la política de seguridad concreta de la organización.
Tener en cuenta el impacto en el tráfico de la red. Habrá que considerar el momento de la
ejecución y hacerlo fuera de las horas habituales de trabajo.
Tener en cuenta el impacto de algunos tests. Algunos analizadores podrían provocar, en
algunos sistemas más vulnerables, la parada de servicios.

Informar al personal responsable. Los administradores de red de los equipos que se vayan
a analizar deben estar al tanto de la situación.

10.2. Caso práctico: la herramienta Nmap

Nmap (Network Mapper) es una herramienta de código abierto para el escaneo de puertos
y auditorías de seguridad. Nmap permite detectar los hosts activos en una red, determinar
qué tipos y versiones de sistemas operativos utiliza cada host, qué tipo de cortafuegos o filtros
de paquetes se están utilizando, etc. Actualmente incluye también la posibilidad de instalar la
herramienta con un interfaz gráfico que facilita su uso (Zenmap).
Las características destacables de Nmap son:
Flexibilidad: permite utilizar diferentes técnicas para mapear redes, incluso cuando éstas
están protegidas.
Potencia: Nmap ha sido utilizado para escanear redes con cientos de miles de hosts conec-
tados a la misma.
Documentación: Nmap está ampliamente documentado en varios idiomas.

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.

10.3. Caso práctico: la herramienta Nessus

Nessus es una herramienta de análisis de vulnerabilidades de seguridad cuya funcionalidad
es la de ayudar a detectar posibles vulnerabilidades en las máquinas escaneadas. Utiliza una
tecnología conocida como Nessus Professional-Feed, que es mantenida por un equipo experto
en investigación y búsqueda de vulnerabilidades.
Las características más significativas de Nessus son:
Análisis en profundidad. Nessus realiza un análisis a alta velocidad sobre los programas
analizados. Puede completar una auditoría de redes de hasta 100 hosts en unos pocos
minutos.
Auditoría de servicios móviles. Puede integrarse para obtener una visión completa de la
parte móvil de una organización y del estado de cada dispositivo en cuanto a vulnerabili-
dades.
Auditoría antivirus, de botnets y procesos maliciosos. Es capaz de detectar procesos ma-
liciosos en ordenadores con Windows. Mejora la organización del antivirus, estudiando y
analizando posibles amenazas relacionadas con las “amenazas persistentes avanzadas” o
APTs. Identifica rápidamente infecciones debidas a botnets y servidores web con contenido
malicioso.
Integración de gestión de parches de seguridad. Nessus se integra fácilmente con pro-
ductos típicos de gestión de parches y actualizaciones. Puede así permitir comparaciones
y emitir informes de discrepancias.

10.3.1. Instalación y uso de Nessus

Nessus está disponible para Linux, Windows, Mac OS X, etc. y también tiene disponibles ver-
siones del cliente para terminales móviles. Desde las últimas versiones el cliente es simplemente
un cliente web.
La primera vez que se accede será necesario proceder a la configuración inicial de la aplica-
ción, donde hay que registrar un suministrador de plug-ins. Estos plug-ins son los que permiten
al servidor Nessus realizar los escaneos de vulnerabilidades. Aunque es una herramienta co-
mercial, Nessus pone a disposición de usuarios individuales la posibilidad de obtener una Home
Feed de forma gratuita.
Una vez descargados los plug-ins se iniciará el servidor y la aplicación mostrará ya el interfaz
principal. Dicha pantalla será la que se presentará a partir de este momento cada vez que se
arranque el cliente Nessus.
Para lanzar un nuevo escaneo habrá que pulsar sobre la opción de aladir (Add). En la ventana
siguiente habrá que definir el objetivo, dirección IP o dominio de la máquina a escanear. Dentro
de las opciones hay que indicar el tipo de análisis que se desea realizar.
Este tipo de escaneos testeará el host especificado contra todos los plug-ins predeterminados
en cada caso.
Para analizar los resultados obtenidos, se seleccionará el report que se desea ver y se pul-
sará sobre el botón Browse. En la primera pantalla se muestra el resumen de vulnerabilidades
descubiertas agrupadas por su riesgo.

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.

10.4.1. Características generales de las herramientas SSCA

Cualquiera de estas herramientas sigue el mismo proceso cuando se aplica a una pieza de
código fuente:

1. El código a analizar se transforma en un “modelo”, un conjunto de estructuras de datos

que representan el código.
2. Se analiza este modelo siguiendo una serie de reglas variadas y/o propiedades concretas
de código.

3. Se muestran los resultados.

Es importante señalar que mientras que las herramientas de código abierto muestran los algorit-
mos usados en profundidad, las herramientas comerciales sólo dan información general, lo que
hace complicado entender sus fallos.

10.4.2. Tipos de herramientas SSCA

Existen diferentes esquemas que permiten categorizar las herramientas SSCA. La clasificación
más usada hace referencia al propósito general de cada herramienta y diferencia entre:
De chequeo de estilos: estas herramientas (por ejemplo lint) hacen chequeos basados en
análisis sintáctico y léxico, que permiten descubrir problemas como inconsistencias en lla-
madas funciones, valores de vuelta de funciones, funciones que se invocan con diferente
número de argumentos, etc. Este análisis no hace ningún tipo de simulación sobre lo que
sucedería en tiempo de ejecución.
De tipo bug finding: con este nombre se habla de herramientas SSCA que simplemente
avisan de las ubicaciones en el código donde el programa va a comportarse de forma
“sospechosa”. Su diseño permite el análisis de programas de millones de líneas de código
y, según proclaman sus creadores, provoca un número bajo de falsos positivos. Son todas
herramientas comerciales.
De tipo security review: estas herramientas son mucho más estrictas en la búsqueda úni-
camente de problemas de seguridad. Los vendedores de estas herramientas señalan que su
diseño implementa una combinación de chequeo de propiedades y técnicas complejas. A
pesar de provocar más falsos positivos, buscan no dejar ninguna codificación sospechosa.

10.4.3. ¿Qué herramienta seleccionar?

Existen más de 40 herramientas SSCA disponibles, pero no puede afirmarse que ninguna
haya alcanzado un nivel de seguridad suficiente como para decir que son 100 % útiles. Por
lo tanto la recomendación sería usar varias o ser especialmente prudente con los resultados
obtenidos mediante su 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

#snort -vde -l /log/snort

Así mismo se puede indicar que sólo registre la información correspondiente a un rango de
direcciones IP:

#snort -vde -l /log/snort -h 192.168.1.0/24

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:

#snort -vde -l /log/snort -b

Se va a analizar ahora su funcionalidad principal como sistema detector de intrusiones o IDS.

Para iniciar esta funcionalidad habrá que ejecutar el siguiente comando:

#snort -vde -l /log/snort -c snort.conf

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:

#snort -d -l /log/snort -c snort.conf

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.

Tabla 8: Opciones de salida de Snort.

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

Las alertas registradas por Snort tendrán la siguiente estructura:

[**] [128:4:1] Mensaje de alerta [**]
[Classification:xxxxxx] [Priority: 3]
Información capturada

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:

#/usr/local/bin/snort -d -l /var/log/snortlogs -c /usr/snort/snort.conf -D

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.

reject: además de bloquear el paquete y guardarlo en el registro envía un paquete de res-

puesta de tipo reset para comunicaciones TCP o una respuesta de tipo port unreachable para
UDP.
sdrop: bloquea el paquete pero no lo guarda en el registro.

La creación de reglas de Snort se escapa al objetivo de esta asignatura.

Para que Snort sea un IDS efectivo, será necesario actualizar las reglas periódicamente con
las nuevas que se vayan publicando.

11.3. Caso práctico: Sguil

Sguil es una aplicación de software libre desarrollada “por analistas de seguridad, para ana-
listas de seguridad”, cuyo objetivo es proporcionar una integración de diferentes herramientas
de seguridad. Sguil almacena las alertas generadas por el IDS a la vez que almacena un registro
con el contenido completo de los paquetes capturados junto con otra información adicional que
pueda ayudar al analista de seguridad a determinar la existencia de un ataque.
Un sistema Sguil está compuesto por un servidor y un número variable de sensores repartidos
a lo largo de la red. La Figura 5 muestra la arquitectura estándar de un sistema monitorizado
con Sguil. Cada uno de los sensores realizará tareas de monitorización de la seguridad en su
segmento de red y reportará la información obtenida al servidor Sguil.

Sensor Sguil

Cliente Sguil Servidor Sguil

Sensor Sguil

Figura 5: Arquitectura de un sistema de monitorización 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.

11.4.1. Ejemplo de honeypots reales

Empezaremos analizando Deceptiontoolkit. Fue el primer honeypot de baja interacción de
código abierto. Este honeypot escucha los puertos no usados por la máquina y presenta una
serie de servicios en dichos puertos con los que el intruso puede interactuar. El objetivo de
dichos servicios es responder al intruso de manera que le haga pensar que nuestro sistema es
vulnerable a sus métodos de ataque.
Uno de los más populares es Back Office Friendly (BOF). Posiblemente el honeypot de baja
interacción más sencillo. Es una aplicación gratuita para sistemas Windows que puede monito-
rizar hasta siete servicios. El principal valor añadido que aporta BOF es el funcionar como una
alarma que detecta y avisa de posibles ataques. BOF simplemente escucha los siete servicios que
tiene configurados y cuando recibe una conexión con alguno de ellos, el intento de acceso queda
registrado y se genera una alarma. Si se instala este honeypot en la red interna y se detectan
intentos de acceso quiere decir que hay algún problema en las defensas perimetrales. El mayor
riesgo de este honeypot no está en él mismo, sino en el sistema sobre el que está instalado. Si no
es seguro, el intruso no podrá comprometer los servicios que presenta el BOF, pero puede ser
que llegue a comprometer el ordenador sobre el que se ha instalado este honeypot.
Otro honeypot interesante es Tiny Honeypot. Es una solución de código abierto para UNIX/-
LINUX de funcionamiento muy simple. Acepta cualquier conexión recibida en cualquier puerto
y a todas ellas les presenta una shell de root con la que el atacante puede interactuar. A conti-
nuación procede a registrar toda la información que pueda. Lo que pretende Tiny Honeypot es
hacer creer al intruso que su ataque ha sido efectivo y que ha conseguido un acceso privilegiado
a la máquina.
Otro ejemplo es GHH - Google Hack Honeypot, una herramienta de código abierto disponi-
ble para UNIX/LINUX y Windows. GHH es un nuevo tipo de honeypot orientado a la detección
de un nuevo tipo de tráfico malicioso, el de hacking a través de buscadores. Actualmente los
buscadores realizan una indexación de todos los sitios web que pueden encontrar, pero en esa
indexación se está recuperando también información sensible de algunos servidores web mal
configurados. Estas búsquedas pueden llevar al atacante a obtener contraseñas, cámaras web,
ficheros de log, servidores vulnerables, aplicaciones publicadas erróneamente, etc. Lo que ha-
ce GHH es emular un servidor web vulnerable con errores de configuración, permitiendo ser

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.

• La emulación de los sistemas no se realiza sólo a nivel de aplicación sino también a

nivel de la pila de IP.
• Puede escuchar cualquier puerto TCP, UDP o atender a peticiones ping ICMP.
• Para los puertos TCP se pueden configurar scripts de emulación de servicios tan com-
pletos como se desee.

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:

• Los puntos únicos de fallo en las redes.

• Las paradas necesarias para actualizaciones.
• Los periodos largos de rearranque o conmutación activo/pasivo.
• Los sistemas no suficientemente probados.

Entre los problemas organizativos se pueden señalar:

• Los tiempos excesivos de reparación de hardware y de software.

• Los problemas operacionales y de procedimientos.

Entre los problemas físicos hay que tener en cuenta:

• Las condiciones medioambientales poco apropiadas.

• Los desastres naturales: terremotos, ciclones, etc.
• Los accidentes como incendios, derrumbamientos, etc.

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.

12.2. Diseño de soluciones de alta disponibilidad

La red o redes de una organización son una necesidad. Si no funcionan, se pone en una
situación crítica a la propia organización. Las redes se han convertido en factores críticos de
éxito para la organización que se quiere analizar.
Las organizaciones de redes de muchas organizaciones se ven envueltas en un ciclo de trabajo
permanente, en el que la alta disponibilidad es una necesidad. En este ciclo, siguiendo las apro-
ximaciones típicas de organizaciones con gran experiencia como Cisco, se pueden diferenciar
cuatro fases:
En la primera se identifica una tecnología nueva y necesaria y se implementa, por ejemplo
el correo electrónico o el comercio electrónico.
Una vez identificada e implementada, aparece la necesidad de que llegue a todos los rin-
cones de la organización. Pueden ser necesarios más conmutadores, más ancho de banda,
dispositivos nuevos, etc.
En la tercera fase se aplican servicios a la nueva tecnología. Podrían hacer falta servicios
de administración, de seguridad, de aplicaciones nuevas, etc.

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

Figura 6: El modelo de referencia OSI.

Si se piensa en la infraestructura de la red como el conjunto de los dispositivos y aplicaciones

y se piensa que cualquiera de ellos puede fallar, se define el camino que se debe analizar para
identificar problemas y soluciones en cualquiera de ellos.

12.3. Los problemas de infraestructura y soluciones

El diseño de una infraestructura sólida del nivel físico es el primer bloque de esta construc-
ción.
Una de las consideraciones básicas es el mantenimiento de una tensión constante para los
dispositivos físicos que componen la red. Una de las formas habituales de conseguirlo es usar
fuentes de alimentación duales que comparten la carga. Si una falla, la otra seguirá propor-
cionando corriente al dispositivo. Otra manera de dar mayor seguridad es usar dos tomas de
alimentación distintas, provenientes de empresas eléctricas diferentes.
Otra solución típica es el uso de sistemas de alimentación ininterrumpida o SAI, el cual
permitirá que se mantenga la necesaria integridad del servicio, protegiendo a su vez los equipos
conectados al SAI contra fluctuaciones en la tensión.
Otra característica importante que hay que tener en cuenta es que ningún componente dentro
de una “caja” debe depender de otros componentes dentro de la misma “caja”. Esto se denomina
inteligencia distribuida, y con este diseño la falta de disponibilidad de uno o más elementos
dentro del sistema no afecta al resto de los elementos.
En el diseño del núcleo, el centro de datos y los dispositivos de red se implementan mediante
el uso de sistemas redundantes. Además de la redundancia interna de los dispositivos se puede
añadir aún más redundancia mediante métodos como el dual-homing (sistemas con dos tarjetas
de red) y los caminos alternativos que se analizan más adelante.
Desde el punto de vista de los métodos de redundancia del hardware se pueden añadir los
siguientes:

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.

12.4. Los problemas en el nivel 2 de OSI y soluciones

El punto clave es cómo obtener ventajas de las características de la infraestructura y aumentar
la disponibilidad del sistema sin necesidad de propagar mensajes de broadcast. El problema es
que haya un único camino de datos que puedan recorrer los mensajes de broadcast.
Para resolverlo el protocolo más implementado es el STP (Spanning Tree Protocol), que utiliza
caminos con bucle (más que redundantes). El STP permite la existencia de bucles físicos en un
área de nivel 2, situación que normalmente provocaría resultados muy desagradables, a base de
crear una topología lógica sin bucles. Se dice en esta situación que la topología ha convergido,
pero desde el punto de vista de la alta disponibilidad hay varios factores relacionados con el
STP que hay que tener en cuenta:
El tiempo de recuperación tras un fallo de un dispositivo y el tiempo que tarda el STP en
re-converger después de un fallo de enlace o dispositivo.

El hecho de añadir o eliminar un equipo de la red.

La puesta en marcha o la eliminación de un nuevo enlace (o varios) de la red.
Cualquiera de los factores citados es un cambio en la topología. Una red STP converge basán-
dose en una serie de temporizadores que son ajustables pero que en todo caso, pueden resultar
demasiado grandes en muchos casos.
Por esta razón se creó el protocolo de re-convergencia rápida, que tiene como objetivo que
las redes puedan reconverger tras un cambio de topología en aproximadamente un segundo.
Otra manera de ayudar a reducir el problema es implementando el protocolo de STP múlti-
ples. Con este protocolo el administrador de red puede crear varios árboles ST, reduciendo de
forma considerable la exposición de la red a los problemas de convergencia en el caso de fallos
o durante el mantenimiento de sistemas.

12.5. Los problemas en el nivel 3 de OSI y soluciones

En este caso hay que referirse a los protocolos de encaminamiento adaptativo de IP, desa-
rrollados para permitir que los encaminadores conozcan dinámicamente su entorno local y
compartan esta información. Para poder determinar el camino óptimo hay toda una serie de
encaminadores que participan en un algoritmo distribuido. Existen dos tipos de encaminamien-
to adaptativo: los basados en algoritmos de vector-distancia y los basados en algoritmos de
estado de enlace.
Hay una pregunta que está en el centro del problema de la alta disponibilidad: ¿qué sucede
cuando falla un encaminador? Lo que sucede depende de su ubicación en la red y de qué otros
dispositivos lo estén usando. Si se ha diseñado la red como de alta disponibilidad no debería
de pasar nada especial, habrá otro encaminador que empiece a encaminar los mensajes y se
recalculará la nueva ruta. Pero si el encaminador que ha dejado de funcionar es del backbone, el
resultado puede ser catastrófico.
Por otro lado, para todas aquellas redes que disponen únicamente de un encaminador por
defecto, el hecho de perder el encaminador significa que quedan completamente aisladas.
Para tratar de arreglar esta situación se ha desarrollado el VRRP (Virtual Router Redundancy
Protocol). VRRP utiliza dos encaminadores físicos, uno en funciones de master y el otro de bac-
kup, configurados como un único encaminador virtual con una única IP virtual para los dos.

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.

12.6. Consideraciones para el resto de los niveles OSI

Sería muy arriesgado hacer la equivalencia entre el tiempo activo de la red y el tiempo activo
del servicio. Puede darse perfectamente el caso de que los tres niveles más bajos de OSI estén
perfectamente operativos y que a pesar de ello las necesidades del día a día del negocio, o los
servicios de red necesarios, no estén funcionando correctamente.
Se suelen introducir políticas de gestión de niveles, entendiendo la palabra política como la
capacidad de la red de servir distintos niveles de servicios a los varios elementos que componen
la red. Las políticas clasifican el tráfico de la red paquete a paquete, y dependiendo de esta
clasificación obligarán a que se realice alguna acción o se aplicará un determinado nivel de
servicio.
Todo esto quiere decir que se deben emplear dispositivos de red que sean capaces de reco-
nocer distintos tipos de tráfico, sean capaces de asignar prioridades y sean capaces de tomar
acciones basándose en la información de niveles superiores al nivel 3.
En el contexto de alta disponibilidad, la clasificación de los paquetes se podría basar en un
puerto físico, en una dirección de nivel 2 ó 3 o de una aplicación indicada por la información
del nivel 4. Basándose en esta clasificación, al paquete se le puede aplicar algún tipo de política
antes de enviarlo a la red.

12.7. Consideraciones para el almacenamiento en red: SAN (Storage Area

Networks)
Una infraestructura de almacenamiento de alta disponibilidad es el punto clave para conse-
guir la completa disponibilidad de los datos. Para conseguirlo se tienen en cuenta una serie de
componentes:
Tecnología de discos RAID.
Múltiples copias de discos en un sistema cluster o granja de servidores.

El uso de clusters a distancia.

Las redes de área de almacenamiento o SAN.
Las copias de seguridad fiables en cinta.

La arquitectura SAN permite la creación de configuraciones de alta disponibilidad a nivel de

toda la organización que son escalables. Hay tres aspectos claves identificables como críticos
para diseñar una solución de alta disponibilidad para el subsistema de almacenamiento:
Protección de los datos.
Conectividad del subsistema.

Redundancia hardware del subsistema.

Dentro de lo que se considera protección de los datos hay a su vez tres puntos concretos a tener
en cuenta:
Memorias secundarias (caché) redundantes. Mediante estas memorias secundarias, cuando
un servidor ejecuta una operación de escritura los daos no van al disco sino que se quedan
en esta caché, para completar la operación más tarde “bajando” los datos de la caché al
disco.

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.

12.8. Consideraciones sobre dispositivos de seguridad

La alta disponibilidad para dispositivos de seguridad de una red es significativamente im-
portante. En muchas situaciones es además imposible de evitar. Si la política de seguridad de la
organización obliga a que todo el tráfico que proviene del exterior pase por un cortafuegos, en
el momento en que el cortafuegos deje de funcionar la red quedará aislada del resto del mundo.
Así pues cada vez es más normal plantearse topologías en las que se dispone de dos corta-
fuegos para que, en el caso de fallar uno, el otro tome su lugar en el más breve lapso posible de
tiempo.
Se habla del cortafuegos primario y del cortafuegos secundario. El primario es el activo, y
el secundario es el cortafuegos de reserva, que está preparado para tomar el control en caso de
que falle el primario.
Desde el punto de vista de la ubicación física de los dispositivos, se suele hablar de dos tipos
de procesos de redundancia:
El proceso estándar de redundancia, en el que ambos cortafuegos están conectados entre sí
mediante un cable especial llamado cable de recuperación, que suele ser de longitud corta.

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.

13.2. Elementos básicos de cualquier sistema criptográfico

Los elementos básicos de cualquier sistema criptográfico actual son:
Algoritmos criptográficos.
Texto “en claro” o texto legible.
Texto cifrado.
Claves.
Generadores de números “más o menos” al azar.
Valores realmente al azar.
Semillas.
Históricamente, la primera aproximación era sencilla. Se creaba un algoritmo secreto, no público,
que permitía intercambiar información en un lenguaje secreto.
El siguiente paso de mejora consiste en refinar el sistema mediante dos características clave:
1. Cualquier algoritmo que se utilice debe ser público. No se empieza a utilizar mientras no
quede suficientemente claro que es seguro y difícil de atacar.
2. Todos los algoritmos dependen de (al menos) una clave, que hay que administrar para que
sea segura. Esto significa que la propia clave debe ser segura y que habrá que cambiarla
con cierta periodicidad.
¿Qué nuevo problema aparece? El de la gestión y distribución de claves. Pero ahora éste es un
problema menor si se tiene la seguridad de que la clave se cambia mediante un procedimiento
seguro y con una cierta periodicidad.
No hay seguridad en el algoritmo, toda la seguridad está en la clave. Si se está usando un
proceso débil criptográficamente para generar tales claves, entonces se puede afirmar que el
sistema completo es débil.
Una forma de abordar el problema es utilizar generadores de números “más o menos” al
azar. Tal generación suele ser un proceso en dos partes. Usando un número elegido lo más al
azar posible como semilla para un generador de los citados, se obtiene un resultado que, a su
vez, se usa como nueva semilla, haciendo así el proceso más largo pero más seguro.
Las tres clases de algoritmos criptográficos utilizados hoy en día son:

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.

Se pueden afirmar dos principios fundamentales de la gestión de algoritmos criptográficos:

1. La seguridad de un algoritmo criptográfico reside en su clave.
2. Si las claves son débiles, la transmisión secreta tendrá una seguridad débil.
Hay dos condiciones fundamentales para tener claves criptográficas potentes desde el punto de
vista de la seguridad del sistema:
1. Hay que generar y usar claves seguras.
2. Hay que cambiar tales claves con frecuencia.

13.3. Distintos niveles criptográficos en el software de redes y sistemas

Desde el punto de vista de la implementación informática, la criptografía se puede incluir
en:

Procesos software: se implementa como un programa o parte de un programa. Esto per-

mite actualizaciones y modificaciones sencillas, pero puede hacer lenta la ejecución.
Mecanismos hardware: entra en la lógica interna del chip y las funciones pueden ser
llamadas directamente.

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.

Criptografía de nivel de enlace. La implementación es vía hardware, en el cable, y el

mensaje entero se cifra y se descifra. KG-84 militares.
La selección del método criptográfico dependerá de la política de seguridad, de la estrategia a
seguir para desplegar el sistema de seguridad deseado y de las posibilidades técnicas y econó-
micas.

13.4. Tipos de ataques a sistemas criptográficos

Hay un criterio fundamental para clasificarlos, que es la cantidad de información de la que
dispone el atacante. Se puede hablar de distintos ataques:
Ataques en los que sólo se dispone del texto cifrado. Suponiendo que el atacante conoce el
algoritmo que se está utilizando, el ataque es muy difícil de realizar con éxito.
Ataques con texto legible conocido. Si el atacante tiene parejas de teto legible y su corres-
pondiente texto cifrado, y además conoce el algoritmo, el ataque empieza a ser accesible.
No obstante, si se obtiene la clave una vez pasado mucho tiempo y el sistema criptográfico
está bien administrado, ésta servirá de poco.
Ataques eligiendo el texto legible. Se tiene acceso a un dispositivo criptográfico, del que
se desconoce el algoritmo utilizado, pero se puede cifrar el texto deseado y examinar el
resultado, tantas veces como se desee, intentando descubrir el propio algoritmo de cifrado.
Este procedimiento recibe el nombre de criptoanálisis diferencial y fue el método usado
para descifrar los mensajes de la máquina Enigma.
Métodos “poco ortodoxos”. Cuando el atacante amenaza, extorsiona o chantajea a un in-
dividuo, que está en poder de la clave. Éste es un tipo de ingeniería social y es, frecuente-
mente, la forma más sencilla de romper un sistema criptográfico.

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.

14.2. Algoritmos de clave privada o de criptografía simétrica

En estos algoritmos lo esencial es que la clave K, que sirve tanto para cifrar un texto como
para descifrarlo, sea compartida sólo entre los participantes en el sistema. Por eso se dice que la
clave es privada y que los algoritmos son simétricos.
Entre sus puntos fuertes se pueden destacar:
Operan más rápido que los algoritmos de clave pública, llegando a ser hasta 1000 veces
más rápidos.
Han servido como base para los sistemas criptográficos basados en hardware.
Entre sus puntos débiles, se pueden destacar:
Requieren un sistema de distribución de la clave muy seguro.
En el momento en que la clave cae en manos no autorizadas el sistema deja de funcionar.
Esto obliga a llevar una administración compleja.
Si se asume que es necesaria una clave por cada pareja de usuarios de una red, el número
total de claves crece rápidamente con el número de usuarios.
Entre los algoritmos típicos de clave secreta la mayoría son de la modalidad que se denomina
cifrado por bloques, llamado así porque lo que se hace es dividir el mensaje en bloques de
tamaño fijo, y aplicar el algoritmo de cifrado a cada uno de ellos, siendo la salida del algoritmo
otro bloque de la misma longitud de texto cifrado.
Todos ellos se basan en dos conceptos clásicos del mundo de la criptografía: la confusión y
la difusión.
Se entiende por confusión la propiedad que consiste en tratar de ocultar cualquier relación
entre la clave, el texto legible y el texto cifrado.
Se entiende por difusión el intento de repartir el peso, o la influencia, de cada bit del texto
legible original dentro del mensaje cifrado.
Se combinan la confusión (a base de sustituciones simples) y la difusión (a base de permu-
taciones) en lo que se conoce como cifrado de producto, y la mayoría de algoritmos se basan
en capas distintas de permutaciones y sustituciones, siendo el algoritmo final no mucho más
que una combinación de operaciones de sustitución y permutación repetida un cierto número
de veces.
En muchos de estos cifrados se aplica la estructura conocida como red de Feistel, en la que
se define un cifrado de producto iterativo, en el cual la salida de cada iteración se usa como
entrada para la siguiente.
Uno de los algoritmos de cifrado simétrico más populares es el DES (Data Encryption Stan-
dard). DES es un algoritmo de cifrado por bloques de 64 bits. La entrada de datos al algoritmo

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.

Figura 7: Sistema Triple DES.

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.

14.3. Funciones de una sola vía (one way hash)

El propio concepto de una función de una sola vía es crucial para la criptografía hoy en
día. Reciben su nombre (una sola vía) debido a su naturaleza matemática. Dado un mensaje x,
es muy fácil calcular el resultado f ( x ). A este f ( x ) se le denomina hash de x. Suele traducirse
como “resumen de x” o también como message digest de x.
Lo verdaderamente característico de este tipo de algoritmos es que debe ser prácticamente
imposible dado el hash f ( x ), obtener x. Como definición de “prácticamente imposible” se podría
afirmar que se tardaría millones de años en conseguirlo.
Este tipo de funciones deben cumplir además de la unidireccionalidad, una serie de carac-
terísticas:
Compresión. Dado un mensaje de cualquier longitud, el hash debe tener una longitud fija.
Difusión. El hash debe ser una función compleja de todos los bits del mensaje o texto
original. La modificación de un bit del mensaje debería modificar, al menos, la mitad de
los bits del hash.
Facilidad de cálculo del hash. A partir de un mensaje o texto debe ser sencillo calcular su
hash.

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

a las que se denomina variables de encadenamiento.

En este paso se inicia el bucle principal del algoritmo, que se ejecuta tantas veces como
bloques de 512 bits hay en el mensaje. El bucle principal tiene 4 iteraciones. En cada una de
ellas se utiliza una operación distinta 16 veces, cada una de las cuales ejecuta una función no
lineal sobre 3 de las 4 variables. Una vez hecho esto, se añade el resultado a la cuarta variable,
un sub-bloque del texto y una constante. Rota el resultado a la derecha un número variable de
bits y añade el resultado a una de las 4 variables. Como paso final, el resultado se usa como
reemplazo de una de las 4 variables.
Quizás el algoritmo de una sola vía que más confianza ofrece hoy en día es el SHA-1 (Secure
Hash Algorithm). Produce un hash de 160 bits a partir de bloques de 512 bits del mensaje original.
SHA-1 emplea cinco variables de 32 bits. El bucle principal tiene 4 iteraciones de 20 operaciones
cada una.
No resulta extraño que se propusiera como mecanismo de autenticación segura para entor-
nos como SSL o IPSec una operación MAC en la que intervenga una función de una sola vía,
conociéndose al mecanismo como HMAC.
HMAC usa una función de una sola vía (típicamente MD5 o SHA-1) como una especie de
caja negra, una clave mayor que el tamaño del hash en bits, una función lógica XOR, además
de operaciones de relleno de bits, para crear una especie de resumen dependiente de una clave
privada.

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.

La clave pública es realmente pública, todo el mundo puede conocerla.

La clave privada es realmente privada, sólo cada participante conoce su propia clave pri-
vada.
Cualquiera que conozca la clave pública del participante A puede cifrar con ella un men-
saje, pero sólo el participante A puede descifrar ese mensaje, mediante su clave privada.
Matemáticamente el algoritmo se basa en las funciones de una sola vía con puerta falsa. El
descifrado es la parte más complicada: sin la clave privada es prácticamente imposible. La idea
básica es usar una función fácil de calcular en una dirección y muy difícil en la contraria como,
por ejemplo, la factorización de enteros. Dados dos números primos, es sencillo multiplicarlos
y obtener su producto, pero dado un único producto, puede ser imposible, desde el punto de
vista práctico, factorizar el número y recuperar los dos factores.
Entre los puntos fuertes de los sistemas criptográficos de clave pública se pueden citar:
Permiten conseguir autenticación y no repudio para muchos protocolos criptográficos.

Suelen emplearse, también, dentro de un sistema híbrido, en colaboración con cualquiera

de los otros métodos criptográficos.
Permiten tener una administración sencilla de claves.
Entre los puntos débiles se pueden señalar:

Son algoritmos más lentos que los de clave secreta.

Sus implementaciones son comúnmente hechas en sistemas software.
Para una gran red de usuarios y/o máquinas, requieren un sistema de certificación de la
autenticidad de las claves públicas.

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.

3. Se elige otro número primo relativo a ( p − 1) y (q − 1), e.

4. Esta pareja de números (e, N ) juntos constituyen la clave pública K. Además el valor N
debe ser distinto para cada participante, lo que depende de su elección de p y q.
5. La clave privada K’ se calcula usando el hecho de que existe un número d tal que:

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

y el descifrado del mensaje C se hace mediante la expresió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.

2. Elige otro número primo e = 7.

3. La clave pública es (7, 187). El valor d, parte de la clave privada, es el resultado de calcular
la inversa de 7 módulo 160. Este valor se calcula siguiendo el algoritmo de Euclides y, en
este caso, resulta ser 23, luego la clave privada es (23, 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.

5. El participante B calcula k0 = Z y mód P.

En realidad, lo que sucede es que k = k0 = N xy mód P. Cualquiera que esté escuchando por
el canal inseguro puede conocer, como mucho, N, P, Z y W. A menos que pueda calcular el
logaritmo discreto y recuperar x o y, no podrá solucionar el problema. La clave secreta, que los
dos participantes han calculado de manera independiente, es k.
Supóngase que Alicia y Bernardo se han puesto de acuerdo en que N = 7 y P = 11, con lo
que la función elegida, para este caso, es:

7x mód 11

Alicia y Bernardo harán lo siguiente:

1. Alicia elige un número x = 3 y Bernardo otro y = 6.
2. Alicia calcula Z = 2 y Bernardo W = 4.
3. Alicia y Bernardo se intercambian Z y W.

4. Alicia calcula 43 mód 11, obteniendo 9.

5. Bernardo calcula 26 mód 11, obteniendo también 9 como resultado.
Estos sistemas, como ya se ha visto, exhiben dos problemas:
La necesidad de uso de claves largas.

La necesidad de certificación de claves públicas.

El primero de los problemas parece tener una solución sencilla, debido a que los ordenadores
son cada vez más potentes y rápidos.
Si todo un sistema de autenticación depende de tales claves públicas y no se dispone de un
mecanismo de certificación de tales claves, se está expuesto a todo tipo de problemas de fraude
y de suplantación.

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

15.2. Autenticación, integridad y no repudio

La autenticación es la propiedad que permite demostrar que uno es quien dice ser.
La integridad es la propiedad que permite garantizar que una serie de datos no han sido
modificados.
El no repudio es una propiedad intrínsecamente ligada con la autenticación. En esencia el
no repudio es la necesidad de asociar un mensaje con su creador. Las comunicaciones seguras
pueden resultar muy minusvaloradas si no se puede hacer responsables a los originadores de
mensajes de haberlos originado.
El problema se puede resumir en dos cuestiones:

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.

15.3. Los sistemas de firma digital

Los requisitos que debe cumplir la firma digital son los siguientes:

Debe ser fácil de generar.

Debería ser irrevocable, no rechazable por el firmante.
Debería ser única, sólo el emisor debería ser capaz de generarla.
Debe ser fácil de reconocer por cualquier receptor de un mensaje.

Debe depender del mensaje y del emisor.

Una firma digital está compuesta por una serie de datos, asociados a un mensaje, que permiten
asegurar la identidad del firmante y la integridad del mensaje. El hecho de estar usando una
firma digital no implica que el mensaje esté cifrado. Puede estarlo o no.
Los sistemas de firma digital son todos más o menos iguales, diferenciándose esencialmente
en el algoritmo de criptografía asimétrica que utilicen.
El más popular de los sistemas de firma digital es el basado en RSA. Con él, pueden utili-
zarse distintas funciones de una sola vía (MD5, SHA-1) y la cifra asimétrica que se usa es la ya
analizada RSA.
En este modelo, el procedimiento de firma de un mensaje es:

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:

Separa el mensaje de la firma.

Calcula el hash del mensaje, H2, mediante la función convenida.
Descifra la firma, FD, mediante la clave pública del emisor, obteniendo el hash original H1.

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.

15.5. Los modelos de infraestructura de clave pública o PKI

Se puede definir una PKI, o infraestructura de clave pública, como el conjunto de hardware,
software, personas, políticas y procedimientos necesarios para crear, almacenar, distribuir, gestio-
nar y revocar certificados digitales.
Con una PKI es posible generar y distribuir claves en un entorno seguro, así como que
las autoridades de certificación emitan claves, certificados y CRL (Certificate Revocation List) de
manera segura.
Las piezas clave de cualquier PKI son las autoridades de certificación. Además se dispone de
dos modelos generales de PKI, el modelo central y el modelo jerárquico.
En el modelo central hay una única autoridad de certificación, la AC raíz, que firma todos
los certificados. Cada participante en la PKI, que necesite un certificado, envía una petición a la
AC raíz.
En el modelo jerárquico, la capacidad de firma de un certificado se delega en una estructura
jerárquica. El punto superior de la jerarquía es la AC raíz, que firma certificados de las AC subor-
dinadas. Éstas, a su vez, firman certificados de AC inferiores o, directamente, de participantes en
la red. En el caso de Cisco, el AC raíz está ubicado en San José pero, en lugar de hacer que sus
30.000 empleados hagan una petición de certificado a San José, se colocaron, estratégicamente,
una serie de AC subordinados por todo el mundo.
Hay distintos métodos de petición de certificados. El más común, usado en la implementación
de IPSec para redes privadas virtuales, es el basado en los PKCS (Public Key Infraestructure
Standards). Entre las más relevantes de estas normas está la PKCS #10, que describe las normas
sintácticas de creación de las peticiones de certificados.
Otro aspecto muy significativo a plantearse a la hora de implantar una PKI es la manera en
que se van a administrar las listas de revocación de certificados (CRL).
Estas listas deben ubicarse en uno o varios sitios de la red, alcanzables tanto por las AC como
por los participantes. Su administración consiste en lo siguiente:

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.

Peticiones de certificados PKCS #10.

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.

15.6. Problemas de seguridad de las firmas digitales y de las PKI

A pesar de todas las ventajas, hay una serie de inconvenientes de seguridad que hay que
tener en cuenta a la hora de implementar una PKI concreta.
La mayor parte de los usuarios no sabe si se está usando o no una PKI y no saben cómo
interactuar con tales sistemas.
Empecemos por qué no todas las aplicaciones aceptan los mismos certificados digitales, hay
una falta real de interoperabilidad. Además, existen problemas de confianza entre AC de distin-
tas organizaciones, que puede imposibilitar la verificación con éxito de cadenas de certificación
cuya AC raíz sea desconocida.
Podemos encontrarnos aún aplicaciones que no acepten certificados digitales.
Además, los certificados digitales pueden falsificarse y aprovecharse de que los usuarios no
son capaces de diferenciar entre uno válido y otro inválido.
Si la política de seguridad de la AC es pobre, el sistema completo está en peligro. Por ejemplo,
podría pasar un tiempo peligrosamente largo entre que se revoca un certificado y se actualizan
todos los servidores que mantienen la CRL.
Las PKI terminan presentando problemas de escalabilidad, cuando el número de certifica-
dos emitidos para los usuarios va creciendo, debido a que las listas de revocación deben ser
consultadas en cada operación si se desea una implantación seria y robusta.
Otro problema grave es el relacionado con el no repudio. Se asume que, realmente, sólo
el participante conoce su clave privada. Como consecuencia, cuando se descifra un mensaje
firmado con tal clave privada NO se puede afirmar que lo firmó el propietario de la clave. Se ha
tomado el término “no repudio” de la literatura académica criptográfica, en la que quiere decir
únicamente que el algoritmo de firma digital no es atacable, y se le está dando un significado
legal muy peligroso: el propietario de la clave puede ser responsable de lo que se haga con tal
clave.
Otro parámetro de configuración muy importante que puede ocasionar problemas es el pe-
riodo de validez de los certificados.
El más grave de los problemas está relacionado con eso que se ha denominado el Peopleware.
Son toda una serie de aspectos relacionados con la confianza depositada en las autoridades de
certificación, especialmente en el tráfico certificado por Internet.

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.

16.2. Protocolos de comercio electrónico: SSL

Hoy en día cada vez más transacciones comerciales se realizan desde cualquier lugar y en
cualquier momento. A toda esta nueva forma de hacer negocios se le conoce con el nombre de
comercio electrónico.
Al realizar una operación comercial por una red como Internet se presentan nuevos proble-
mas:
La tienda virtual a la que el cliente se ha conectado, ¿existe realmente?
Una vez enviada la información de la tarjeta de crédito, ¿hay una seguridad total de que
no se cambia la información del pedido realizado?
¿Se tratará la información de la tarjeta de crédito de manera privada?
¿Tiene el vendedor la seguridad de que el cliente le ha facilitado datos correctos y no
información falsa?
La solución a estos problemas se consigue gracias al uso de protocolos criptográficos.
En la actualidad, los navegadores más habituales tienen SSL como herramienta de seguridad.
Un dato importante del uso de SSL es su transparencia desde el punto de vista de un usuario.
Si la página se identifica como “https” entonces el navegador utiliza automáticamente SSL para
lograr una comunicación confidencial entre el navegador que usa el usuario y el servidor que
contiene la página.
Las capacidades de seguridad que proporciona el protocolo son:
Autenticación
Privacidad
Intercambio de claves
Tales características se consiguen al implementar el protocolo vía la interacción de los dos únicos
componentes necesarios:
El cliente SSL, que suele ser un navegador web. Es el iniciador de la comunicación segu-
ra. Tiene la obligación de hacer una propuesta de algoritmos de seguridad para abrir la
negociación del protocolo.
El servidor SSL, normalmente un servidor web, que tiene la obligación de elegir entre
las propuestas de seguridad del cliente. Decide también qué se va a utilizar durante la
conversación.

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.

Cambio Cifra, el proceso responsable de iniciar las negociaciones de los parámetros de

seguridad.
El nivel de Registro recibe datos del nivel superior y lo fragmenta en bloques de texto sin cifrar.
El resto de procesado del nivel consiste en cifrado o compresión.
Todos los fragmentos del mensaje van cifrados y los MAC (Message Authentication Code) se
definen dependiendo de la cifra especificada para la conexión.
Una vez se ha completado el handshake, el cliente y el servidor tienen ya el material necesa-
rio para autenticar y proteger los mensajes entre ambos. El proceso de cifrado y autenticación
transforma los bloques del mensaje en texto cifrado SSL.
Al iniciarse una sesión SSL el cliente y el servidor se ponen de acuerdo en:

La versión del protocolo.

Los algoritmos de cifrado.
Opcionalmente, si debe haber autenticación o no.
La cifra de clave pública, para generar claves secretas compartidas.

El problema mayor de SSL es el de la autenticación opcional y su control. Si no hay autenti-

cación parece claro que algunos de los problemas citados al principio de esta sección siguen
existiendo, pero incluso con autenticación algunos otros siguen sin resolverse y todo este tipo de
indefiniciones pueden dar lugar a otras situaciones peligrosas como las siguientes:
Alguien crea una tienda en Internet para vender un producto. Su servidor usa SSL con
muy buenas condiciones de seguridad, pero al no ser obligatoria la autenticación, sin ella.
Habrá compradores que faciliten su número de tarjeta de crédito sin pedir más referencias.
Al poco tiempo el servidor desaparece de Internet y el creador también. No se puede
reclamar a nadie. El “timador” puede empezar a usar toda la información recogida de
forma fraudulenta.

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.

16.3. Protocolos de comercio electrónico: SET

Para intentar evitar muchas de las debilidades citadas se creó el protocolo SET (Secure Electro-
nic Transactions). Como único objetivo del diseño estaba el comercio electrónico, no suponiendo
una mejora en cuanto a la seguridad de la comunicación, sino en el propio proceso de comercio
electrónico.
Su principal ventaja es la obligatoriedad de la autenticación de todas las partes implicadas
en el proceso de comercio electrónico. El protocolo SET dirige el diálogo entre las tres entidades
fundamentales:
El cliente, poseedor de la tarjeta de crédito.

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.

16.4. Los protocolos IPSec

En la actualidad se ha convertido en el grupo de estándares, para implementación de todo
todo tipo de redes privadas virtuales, más ampliamente aceptado por la industria y por los
usuarios.
Se diseñó específicamente para IPv6 y es compatible con la versión IPv4 del protocolo. El
diseño de IPSec está orientado a proteger el tráfico de red entre dos dispositivos cualesquiera en
una red, manteniendo los siguientes principios:
Las funciones de seguridad no deben afectar a las operaciones ya existentes en la red.
Cualquier dato, salvo los obligatoriamente necesarios para encaminar mensajes, debe po-
der cifrarse.

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.

Privacidad de los datos transmitidos en los mensajes IP.

Protección contra repetición de mensajes.
Todos los algoritmos criptográficos utilizados en IPSec son estándar, lo que permite asegurar la
fácil compatibilidad con otros mecanismos. IPSec utiliza tres protocolos diferentes e indepen-
dientes, lo que hace más fácil, también, la modularidad de la implementación. Tales protocolos
independientes son:
El protocolo AH (Authentication Header).
El protocolo ESP (Encapsulating Security Payload).

El protocolo ISAKMP (Key Management Protocol).

16.4.1. El protocolo AH - Authentication Header

AH proporciona integridad y autenticación de los datos, pero no proporciona privacidad de
los mismos. La autenticación y la integridad se consiguen mediante funciones HMAC aplicadas
al paquete de datos. HMAC involucra el uso de una clave secreta compartida entre los dos
extremos. AH utiliza habitualmente MD5-HMAC o SHA-1-HMAC.
AH protege el payload de IP y todos los campos de cabecera de un datagrama IP, excepto los
campos mutables. Opera directamente por encima de IP.

16.4.2. Protocolo ESP - Encapsulating Security Payload

ESP proporciona la privacidad de los datos aunque, opcionalmente, puede proporcionar tam-
bién integridad y autenticación. Es independiente de AH. Para la integridad y la autenticación
los algoritmos son los mismos que para AH. Para la privacidad se usa DES, 3DES o AES.
La cabecera del paquete IP no está protegida por ESP. ESP opera directamente sobre IP. ESP
se puede operar, además, en dos modos diferentes:

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.

16.4.3. Las asociaciones de seguridad en IPSec

En redes IPv4 IPSec se usa para situaciones concretas, sobre todo para la configuración de
redes privadas virtuales. En ellas, juega un papel esencial el concepto de asociación de seguridad
(AS), que consiste en el establecimiento de un conjunto de atributos de seguridad commpartidos
entre dos entidades en la red que soportan comunicaciones seguras con IPSec. Los atributos
pueden ser algoritmos criptográficos, claves de cifrado y parámetros que se asociarán con los
datos de red que usarán la conexión. El marco de trabajo para el establecimiento de las AS es

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.

16.4.4. Un ejemplo básico de uso de IPSec

Se va a analizar ahora la creación de un túnel IPSec en una de las situaciones más habituales
de uso de los protocolos analizados, una red privada virtual de red a red, en la que desde un
equipo A se quiere crear una conexión segura con un equipo B en otra parte de la red.
1. El encaminador X recibe el tráfico de A a B, que cumple las condiciones de ser procesado
por una asociación de seguridad.
2. El encaminador X, mediante IKE, se autentica con su remoto, Z, y negocia las asociaciones
de seguridad para crear un canal de comunicaciones seguro entre ambos (creación de una
AS de tipo IKE).
3. Mediante esa AS IKE, ambos encaminadores negocian una AS para el tráfico específico de
A y B, denominada asociación de seguridad IPSec. Los parámetros de seguridad de esta
AS se utilizan para proteger los mensajes intercambiados entre A y B, en su tránsito por la
red no fiable.
4. La transferencia de datos se puede hacer ya de manera segura.

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.

3. Se cifra el mensaje mediante esta clave secreta.

4. Se cifra la clave de sesión mediante la clave pública del receptor.
5. Se envían la clave de sesión y el mensaje cifrado al receptor.

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.

Para la compresión, ZIP.

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.

17.2. Caracterización de las redes privadas virtuales

Las características buscadas para una VPN son las siguientes:
Integridad de los datos.

Privacidad de los mensajes.

Autenticación de los participantes.
Control de acceso. Asegurar que los participantes autenticados tienen acceso únicamente
a los datos a los que están autorizados.

Auditoría y registro de actividades. Asegurar el correcto funcionamiento y la capacidad

de recuperación.
Calidad del servicio. Asegurar un buen rendimiento, que no haya una degradación poco
aceptable en la velocidad de transmisión.

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.

Opciones de tipo de servicio (bits TOS).

Otro criterio que sirve, también, para caracterizar una VPN es preguntarse dónde empieza y
dónde acaba la VPN. El punto de inicio y de final de una VPN suelen venir determinados por
dónde tienen lugar las funciones previamente comentadas (privacidad, autenticación, etc.). Con
respecto a esta pregunta, se puede hablar de tres tipos de redes privadas virtuales:

Redes privadas virtuales de extremo a extremo.

Redes privadas virtuales intermedias.
Redes privadas virtuales origen-intermedio.
En el caso de las VPN de extremo a extremo, las funciones típicas de una VPN se implementan
en el ordenador emisor y en el receptor. Antes de dejar el emisor, los datos han sido asegurados
y viajan así hasta llegar al receptor.
En el caso de las VPN intermedias, que es el más habitual, los datos de la sesión dejan el emi-
sor sin ningún tipo de formato especial, y así llegan a un dispositivo intermedio (encamianador,
cortafuegos, etc.) que es el que va a crear el tráfico VPN y lo va a transmitir por la red insegura.

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.

17.2.1. Ventajas e inconvenientes de las VPN

La ventaja más evidente es la posibilidad de tener acceso a los datos de manera segura desde
cualquier lugar. Entre las ventajas más significativas encontramos:

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.

Las VPN también conllevan algunos inconvenientes:

Aunque se abaratan los costes respecto a las soluciones punto a punto, su puesta en marcha
supondrá gastos.
Dado que los datos que viajan por una VPN lo hacen a través de una red pública, esto
tiene sus riesgos de seguridad.

Si se usan diferentes protocolos (IPSec, SSL) se incrementará la complejidad del sistema.

Al viajar los datos a través de una red pública habrá momentos en los que la congestión
de la red repercuta negativamente sobre la velocidad o rendimiento de la VPN.

17.2.2. Arquitectura y planificación de VPNs

Hay dos componentes esenciales, uno es el proceso conocido como tunneling, que hace que la
red sea “virtual” y el otro está compuesto por una serie de servicios de seguridad, que permiten
que los datos de la VPN se mantengan privados.
En una VPN no se mantienen enlaces permanentes, sino que se crean conexiones entre dos
partes de ella, según sea necesario. En tales conexiones, la propia infraestructura de Internet
resulta oculta gracias al concepto de tunneling. Lo que se hace es crear una conexión especial
entre dos extremos, en la que el extremo de inicio del túnel encapsula sus paquetes dentro de
mensajes IP para su tránsito por Internet.
Por otro lado, los servicios de seguridad deben implementar todas las necesidades comenta-
das en temas anteriores, esto lleva al uso de una serie de posibles protocolos, de los que el más
usado es el conjunto IPSec.
Desde el punto de vista de componentes, hay cuatro típicos en la arquitectura de una VPN:
La red Internet, o la red no segura.
Las pasarelas de seguridad.
Los servidores de política de seguridad.

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.

Colocar la pasarela como otro nodo de la red interna.

Colocar la pasarela en paralelo con el encaminador de acceso a la red interna.

17.2.3. Rendimiento, mantenimiento y seguridad

Es imposible evitar el problema del rendimiento del tráfico de la red. Si los túneles VPN de-
ben parecer transparentes a los usuarios y a las aplicaciones, tales túneles no pueden convertirse
en cuellos de botella para el tráfico de la red.
Se puede hablar de dos factores fundamentales de una VPN, que afectan a su rendimiento:
La velocidad y fiabilidad del tráfico que atraviesa Internet.
La “fortaleza” del procesado de cifrado de la VPN en los ordenadores y en las pasarelas
VPN de seguridad.
Es un punto a tener en cuenta el que los dispositivos VPN dispongan de tarjetas de cálculo
especiales para el cifrado. Es una solución más cara pero más rápida.
Los principios de mantenimiento de una VPN son fundamentalmente los de cualquier red.
El rendimiento es uno de ellos, el resto son:

Gestión de fallos de funcionamiento en la red.

Gestión de la configuración de los dispositivos.
Gestión de la auditoría y de la contabilidad del uso de recursos.
Gestión de la seguridad.

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.

Problemas de aplicaciones que no funcionan.

Problemas de usuarios.

17.3. VPN mediante SSL

Cada día se está extendiendo más el uso de redes privadas virtuales que usan SSL como pro-
tocolo para garantizar la integridad y privacidad del tráfico de la red VPN. SSL es un protocolo
desarrollado para asegurar y cifrar las comunicaciones web de las aplicaciones de comercio elec-
trónico. Es capaz de proporcionar autenticación, integridad y confidencialidad cliente-servidor
por medio de certificados digitales.
Es posible utilizarlo para construir túneles VPN a través de Internet. En este caso lo que se
hace es utilizar SSL en vez de IPSec para cifrar las comunicaciones que mantiene un usuario
remoto con la red de la organización. El acceso del usuario es a través de un proxy o pasarela
de aplicación, por lo que el cliente no se conectará directamente a la red de la organización, sino
que lo hará a través de dicha pasarela. El uso de SSL hace que la conexión tenga lugar en la capa
de aplicación, y no en la capa de red como sucedía con IPSec.
El uso de VPNs por medio de SSL presenta una serie de ventajas sobre las VPNs que utilizan
IPSec:
No es necesario usar clientes VPN. En estos casos no es necesario instalar ningún tipo
de software cliente. El usuario remoto sólo necesitará tener instalado en su terminal un
navegador web. Todo el proceso de cifrado y descifrado en el lado cliente será realizado
por el módulo SSL del navegador web.
Reducción de problemas de interoperabilidad. Es raro que se produzcan problemas de
interoperabilidad entre el cliente y el servidor SSL.

Desaparición de problemas relacionados con cortafuegos. El tráfico SSL no tiene ningún

tipo de problemas cuando debe atravesar dispositivos NAT y dado que SSL es un proto-
colo altamente extendido los cortafuegos normalmente dejan pasar este tipo de tráfico sin
ningún tipo de problemas.
Control de acceso más granular. El tráfico SSL corresponde con tráfico del nivel de aplica-
ción, lo que va a permitir asegurar que los usuarios remotos sólo tengan acceso a aquellas
aplicaciones específicas para sus necesidades.
Los túneles VPN-SSL simplifican enormemente el uso de la solución por parte de los clientes
dado que los pasos que estos deben realizar para acceder a los recursos de la organización no
requieren ningún tipo de conocimiento técnico.
El proceso de conexión desde el punto de vista del usuario consta de cinco fases:
Fase 1: el usuario conecta por medio de su navegador web con el sitio web de la VPN-SSL,
para ello sólo deberá indicar la dirección del sitio web. El portal de acceso pedirá al usuario
que introduzca sus credenciales.

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.

17.4. VPN a través de redes MPLS (Multi Protocol Label Switching)

Las redes MPLS (Multi Protocol Label Switching) son un tipo de redes privadas de comuni-
cación que tienen la peculiaridad de que utilizan etiquetas de nivel 2 de OSI para tomar las
decisiones de encaminamiento. MPLS permite encaminar paquetes de cualquier protocolo de
red gracias a dichas etiquetas.
Las redes MPLS son orientadas a conexión y los paquetes son transmitidos a través de ru-
tas preconfiguradas, o LSPs (Label Switching Paths), en función de las etiquetas asignadas a los
paquetes.
Cuando el conmutador MPLS recibe un paquete, examinará la etiqueta del mismo para de-
terminar qué LSP le corresponde. Una vez identificado dicho LSP consultará su propia tabla de
encaminamiento para determinar por qué enlace debe retransmitirlo, así como la etiqueta para
el próximo salto.
Hay tres tipos de VPNs sobre MPLS:
VPNs de nivel 3. El proveedor del servicio participa en el encaminamiento de nivel 3 del
cliente. Son a las que normalmente nos referimos cuando se habla de VPN-MPLS.
VPNs de nivel 2. El proveedor de servicios interconecta las sedes del cliente a través de
tecnología de nivel 2 (capa de enlace). Son especialmente atractivas para aquellos clientes
que quieran mantener el control de su propio encaminamiento de nivel 3.
LANs privadas virtuales. El cliente ve la red completa del proveedor de servicios como un
gran conmutador, de esta forma la red de área amplia (WAN) del cliente es como una gran
red unificada a la que acceder mediante Ethernet.
La privacidad la conseguirá el proveedor manteniendo tablas de información individuales para
cada cliente, así como para cada una de las sedes que tenga conectadas. La información que
contengan dichas tablas será diferente en función del tipo de VPN:
En el caso de VPNs de nivel 3 la tabla contendrá los diferentes rangos de direcciones IP.
En el caso de VPNs de nivel 2 la tabla contendrá las direcciones de nivel 2.

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.

La convergencia origen-destino es controlada principalmente por el proveedor del servicio.

La fiabilidad de la RPV dependerá enormemente de la competencia del proveedor del
servicio.
Este tipo de soluciones crea una dependencia del proveedor de servicio que en muchos
casos es difícil de romper.

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. Redes inalámbricas, conceptos básicos.

18.2.1. 802.11 a/b/g/n
802.11 es el nombre del grupo de trabajo del IEEE encargado de definir estándares para las
redes de área local inalámbricas. El IEEE define cada uno de esos estándares o generaciones
con una letra. Los cambios principales de una versión a otra vienen dados por la velocidad
de transmisión, la técnica de modulación empleada, y la compatibilidad o no con versiones
anteriores.
Hay que tener en cuenta que determinadas herramientas sólo funcionarán para un estándar
específico.

18.2.2. Puntos de acceso

Las redes inalámbricas pueden operar de dos formas: ad-Hoc o en modo infraestructura. En
el primero de ellos los clientes se conectan directamente entre sí, mientras que en el segundo
modo los clientes se conectan a la red a través de un punto de acceso.
La función básica de los puntos de acceso es conectar tecnologías diferentes (redes cableadas
e inalámbricas) entre sí.

18.2.3. SSID, BSSID, dirección MAC

El SSID, BSSID y la dirección MAC son identificadores esenciales en una red inalámbrica. El
SSID (Service Set Identifier) es el nombre asociado a la red inalámbrica. El BSSID (Basic Service Set
Identifier) identifica de forma única un punto de acceso específico. Por último la dirección MAC
identifica a cada uno de los enlaces de red que puedan tener tanto los clientes como los puntos
de acceso.

18.2.4. Paquetes baliza (beacons)

Los puntos de acceso emiten paquetes de baliza. Estos paquetes de tipo broadcast contienen
la información específica sobre la configuración del punto de acceso.

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.

18.3. Teoría de ataques a redes inalámbricas

Para ser capaces de asegurar las comunicaciones a través de redes inalámbricas es necesario
tener conocimiento de los tipos de ataque que se pueden producir sobre las mismas.

18.3.1. Problemas de autenticación, privacidad e integridad

En las comunicaciones a través de redes inalámbricas debemos preocuparnos por la autenti-
cación de usuarios de la red así como de asegurar la privacidad e integridad de las comunica-
ciones.
En este escenario es más necesario que nunca autenticar a los usuarios que acceden a la red.
Los métodos usados más comúnmente en redes inalámbricas son:

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.2. Ataques. Fase de reconocimiento

En cualquier ataque la primera fase será la de reconocimiento. Éste puede ser tanto pasivo
como activo. El propósito de los ataques pasivos es evitar que la actividad del atacante sea
detectada por el sistema.
Los puntos de acceso emiten paquetes baliza y los atacantes escucharán dichos paquetes para
tratar de identificar las redes disponibles y obtener así los datos de dicha red inalámbrica.

18.3.3. Tipos de ataques

18.3.3.1. Captura pasiva de paquetes Para poder capturar el tráfico de una red inalámbrica
lo único que necesita un atacante es estar dentro del rango de acción de dicha red. Muchos de
los protocolos de red más utilizados son inseguros por naturaleza, ya que no cifran la informa-
ción que transmiten. Simplemente usando un capturador de paquetes el atacante será capaz de
interceptar y reconstruir los datos que se están enviando.
Algunos de los protocolos que envían información sin cifrar son HTTP, SMTP, FTP, POP3 e
IMAP. En muchos casos las credenciales también pueden ser interceptadas ya que también se
envían como texto sin cifrar.
Este tipo de ataques hacen patente la necesidad de cifrar las comunicaciones de nuestra red
inalámbrica.

18.3.3.2. Captura y decodificación En caso de que las comunicaciones inalámbricas vayan

cifradas, el atacante tiene la posibilidad de capturar dicho tráfico para posteriormente tratar de
romper el cifrado y extraer la información.
Esta posibilidad se debe tener en cuenta a la hora de decidir la tecnología de comunicaciones
a utilizar. Puede que la inalámbrica no sea la más adecuada para determinadas organizaciones
si la información es altamente sensible.

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. Ataques a clientes de redes inalámbricas

Los administradores de red tratan de reforzar la seguridad de sus puntos de acceso, pero en
ocasiones dejan huecos que los atacantes pueden aprovechar, normalmente en los dispositivos
usuarios de red.

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.

Los clientes de redes inalámbricas continuamente mandan paquetes broadcast informando

de su existencia. Si un cliente no está asociado a un punto de acceso, el atacante dispon-
drá de información muy valiosa para tratar de confundir al cliente y hacer que este se
comunique con él.

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. Medidas no criptográficas para protección de redes inalámbricas

Se va a pasar a detallar los principios de diseño de redes inalámbricas que nos permitirán
hacerlas más seguras.

18.4.1. Principios de diseño seguro para redes inalámbricas

Los principios presentados son tanto de aplicación a redes inalámbricas como a cualquier
sistemas de redes cableadas.

18.4.1.1. Defensa en profundidad La idea principal consiste en usar diferentes tecnologías

para tratar de asegurar la red y no sólo una.

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.3. Segmentación de la red Es adecuado segmentar distintos grupos de sistemas en

distintos segmentos de la red interna en vez de tener a todos dentro de un único segmento
general. Si una organización desea proporcionar acceso a Internet para sus visitantes a través de
una red inalámbrica, es conveniente que cree un segmento de red para dicha red inalámbrica y
otro para la red interna de la empresa.
No es recomendable unir en una única red todos los sistemas.
La forma más básica de segmentar la red en el nivel 2 es a través de LANs virtuales. Una
LAN virtual divide los conmutadores de red en múltiples conmutadores virtuales. En este esce-
nario para interconectar distintas VLAN se usará un dispositivo de nivel 3 como puede ser un
cortafuegos o un encaminador.

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.

18.4.1.7. Privacidad e integridad Se debe tratar de garantizar la privacidad e integridad de

las comunicaciones que pasan a través de una red inalámbrica. Para ello será necesario autenticar
a los usuarios que acceden a la misma y, por otro lado, será necesario cifrar las comunicaciones
para asegurar su privacidad y poder realizar comprobaciones de integridad.
Los protocolos WEP, WPA y WPA2 permiten tanto autenticar como cifrar las comunicaciones.

18.4.2. Malas defensas no criptográficas

Se presentan una serie de medidas no criptográficas y que aunque, aparentemente, pro-
porcionan seguridad a la red inalámbrica, en realidad sólo proporcionan una falsa ilusión de
seguridad ya que son vulnerables.

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. Buenas defensas no criptográficas

Medidas que sí aportan mayor seguridad al sistema.

18.4.3.1. Cortafuegos El uso de cortafuegos puede permitir segmentar el tráfico de la red

inalámbrica del de la red interna, o segmentar el tráfico de distintos segmentos de red inalám-
brica.
Muchas de las soluciones de cortafuegos disponibles hoy en día proporcionan otras funcio-
nalidades más allá del control de acceso de nivel 3. Algunos incluyen detección de intrusiones,
antivirus, etc. Enrutar el tráfico de la red inalámbrica a través de un cortafuegos de este tipo
aporta nuevas capas de seguridad a la red.

18.4.3.2. Encaminadores En el caso de no poder usar un cortafuegos, es recomendable usar

algún tipo de segmentación de nivel 3, y los encaminadores son una plataforma perfecta para
llevarla a cabo.

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. WEP (Wired Equivalent Privacy)

Proporciona tanto funciones de autenticación como de cifrado.

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.

La autenticación por medio de clave compartida es una vulnerabilidad en sí misma. El hecho

de que un atacante que esté “escuchando” las comunicaciones de la red pueda capturar tanto el
valor pseudo-aleatorio sin cifrar como el valor una vez cifrado, hace que para él sea muy sencillo
romper esa clave de cifrado.

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.1. Algoritmo de cifrado de WPA La tecnología que le permite a WPA funcionar en

hardware existente se denomina TKIP (Temporal Key Integrity Protocol). TKIP utiliza el algoritmo
RC4 para el cifrado de datos. TKIP cifra cada paquete con una única clave de cifrado. Esen-
cialmente, TKIP implementa una versión más segura de lo que trataba de hacer el protocolo
WEP.
WPA-PSK (Pre-Shared Key) establece una clave que es compartida entre todos los dispositivos
que desean conectarse a la red inalámbrica. En este caso la clave es ahora de 256 bits.
WPA-Enterprise es mucho más complejo de desplegar y configurar. Esta implementación
requiere de la implantación de servidores en la red que se encargarán de autenticar a los usuarios
de forma individual.

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.

1. Obtención de la clave compartida WPA

El proceso de autenticación con WPA es similar al que se producía con WEP, y presenta la
misma vulnerabilidad. Es decir, el atacante podrá “escuchar” los paquetes que viajen por
la red y poseerá esos valores pseudo-aleatorios tanto cifrados como sin cifrar, información
que podrá utilizar para tratar de averiguar la clave WPA.
Esta vulnerabilidad hace que la longitud y complejidad de la clave WPA compartida sea
extremadamente importante para la seguridad de la red.
2. Suplantación de paquetes de de-autenticación WPA
Para que el atacante sea capaz de romper la clave WPA necesita escuchar numerosos pa-
quetes de inicio de conexión de clientes para obtener suficientes combinaciones de números
pseudo-aleatorios cifrados y sin cifrar.
En estas situaciones el atacante puede usar herramientas que suplanten los paquetes de
cierre de sesión que enviaría el punto de acceso al cliente. Este proceso producirá mayor
tráfico de paquetes de solicitud de la red que el atacante podrá utilizar para agilizar el
proceso de obtención de la clave WPA.

3. Ataque de denegación de servicio WPA

Un atacante puede llegar a usar los paquetes de de-autenticación WPA para dejar fuera
de servicio la red inalámbrica. Para ello tendrá que enviar paquetes de cierre de conexión
a todos los clientes que estén conectados, y seguir enviándoselos cada vez que vuelvan a
iniciar la conexión.

18.5.3. WPA2-Enterprise con arquitectura de certificados digitales

La mejor solución para aquellos entornos que demanden la máxima seguridad la encuentran
usando WPA2-Enterprise con certificados digitales para autenticar a los usuarios y cifrar las
comunicaciones.
Al usar certificados digitales se obtienen los siguientes beneficios:
Los certificados digitales proporcionan un sistema de autenticación más robusto.
Los certificados digitales son más difíciles de comprometer o robar.

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.

18.5.3.2. Uso de certificados digitales El uso de certificados digitales es opcional. La arqui-

tectura básica del sistema es la misma, sólo que en este caso hay que añadir una autoridad de
certificación a la misma.
Es necesario entender que para poder utilizar WPA2-Enterprise con arquitectura de certifica-
dos digitales será necesario disponer también de una infraestructura de clave pública (PKI) que
pueda gestionar los certificados de los usuarios, es decir, será necesario desplegar una autoridad
de certificación que sea capaz de gestionar los certificados digitales.

100