Procesos y Herramientas Para La Seguridad de Redes

C

M

Y

CM

MY

CY CMY

K

Procesos y herramientas para la seguridad de redes

En un mundo en el que todos utilizamos herramientas que llamamos “sociales” para la comunicación personal y profesional, y en el que buena parte de nuestra información viaja por las redes o se guarda en la “nube”, todos deberíamos conocer los fundamentos mínimos para mantener una actitud prudente en nuestra vida digital. Hoy en día, cuando los currículos se buscan por Internet, los documentos se entregan en dispositivos USB, las conferencias se hacen por la red y, en definitiva, el trabajo profesional y el estudio se apoyan inevitablemente en los ordenadores, teléfonos móviles y redes, se hace más necesario que nunca saber qué se puede y qué se debe hacer en cuanto a seguridad informática. En un mundo en el que se discute sobre si se debe perder privacidad para obtener seguridad, y, se nos pretende convencer de que esto traerá seguridad completa, es interesante recordar que , como dijo Benjamin Franklin, únicamente hay dos cosas seguras al 100%: la muerte y el pago de impuestos. La sociedad necesita profesionales bien cualificados para trabajos especializados en proporcionar seguridad a datos, sistemas y redes de comunicación. Para ellos, muy especialmente los alumnos de los grados de Ingeniería en la Universidad española, este libro pretende ser una introducción práctica a asuntos y conocimientos sobre los que tendrán que profundizar. Pero además, los autores hemos pretendido también hacer un libro que, de manera amena pero estricta, ayude al público en general a entender situaciones que, cada vez más, son rutinarias.

ISBN: 978-84-362-6716-7

Editorial

02307

colección Grado 9 788436 267167

GR

Procesos y herramientas para la seguridad de redes Gabriel Díaz Orueta Ignacio Alzórriz Armendáriz Elio Sancristóbal Ruiz Manuel Alonso Castro Gil


GABRIEL DÍAZ ORUETA IGNACIO ALZÓRRIZ ARMENDÁRIZ ELIO SANCRISTÓBAL RUIZ MANUEL ALONSO CASTRO GIL

UNIVERSIDAD NACIONAL DE EDUCACIÓN A DISTANCIA

PROCESOS Y HERRAMIENTAS PARA LA SEGURIDAD DE REDES

Quedan rigurosamente prohibidas, sin la autorización escrita de los titulares del copyright, bajo las sanciones establecidas en las leyes, la reproducción total o parcial de esta obra por cualquier medio o procedimiento, comprendidos la reprografía y el tratamiento informático y la distribución de ejemplares de ella mediante alquiler o préstamos públicos.

© Universidad Nacional de Educación a Distancia Madrid 2014 www.uned.es/publicaciones © Manuel Alonso Castro Gil, Gabriel Díaz Orueta, Ignacio Alzórriz Armendáriz, Elio Sancristóbal Ruiz.odas nuestras publicaciones han sido sometidas a un sistema de evaluación antes de ser editadas. ISBN electrónico: 978-84-362-6838-6 Edición digital: marzo de 2014

ÍNDICE

Presentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

Tema 1. DESCRIPCIÓN DEL PROBLEMA DE SEGURIDAD EN REDES. TIPOS DE Introducción, orientaciones para el estudio y objetivos . . . . . . . . . . . . . . Unas cuantas preguntas que ayudan a definir mejor el problema Soluciones «perfectas» y soluciones razonables . . . . . . . . . . . . . . . . . . . . . . . Conocimientos y competencias adquiridas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Palabras clave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ejercicios resueltos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ejercicios de autoevaluación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17 19 22 30 35 36 37 37 38

Tema 2. LA SEGURIDAD EN LOS ELEMENTOS FÍSICOS EXISTENTES EN UNA RED 1. Introducción, orientaciones para el estudio y objetivo . . . . . . . . . . . . . . . 2. Los sistemas de cableado o inalámbricos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. Repetidores, hubs y conmutadores (switches) . . . . . . . . . . . . . . . . . . . . . . . . . . 4. Encaminadores (routers) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5. Los servidores y otras máquinas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6. Conocimientos y competencias adquiridas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7. Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8. Palabras clave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9. Ejercicios resueltos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10. Ejercicios de autoevaluación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41 43 45 48 53 55 58 59 59 59 61

ATAQUES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1. 2. 3. 4. 5. 6. 7. 8.

Tema 3. LA

SEGURIDAD EN LOS ELEMENTOS SOFTWARE EXISTENTES EN

UNA RED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1. 2. 3. 4.

Introducción, orientaciones para el estudio y objetivos . . . . . . . . . . . . . . Los sistemas operativos y las aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Los protocolos y aplicaciones IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mejoras de seguridad con IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63 65 67 73 79

7


5. 6. 7. 8. 9. 10.

Criterios de evaluación de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conocimientos y competencias adquiridas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Palabras clave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ejercicios resueltos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ejercicios de autoevaluación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

80 87 88 88 89 90

Tema 4. MÉTODOS DE ATAQUE A EQUIPOS Y REDES . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1. Introducción, orientaciones para el estudio y objetivos . . . . . . . . . . . . . . 2. Taxonomía de los tipos de ataques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. Ataques orientados a la obtención de información . . . . . . . . . . . . . . . . . . . 3.1. Ingeniería social . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2. Herramientas informáticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3. Escuchadores o «sniffers» de paquetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4. Análisis de metadatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4. Ataques basados en la mala administración de sistemas . . . . . . . . . . . . 5. Ataques basados en vulnerabilidades de protocolos de red . . . . . . . . . 5.1. Ataques Man-in-the-Middle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6. Ataques basados en vulnerabilidades del software . . . . . . . . . . . . . . . . . . . . 7. Ataques de denegación de servicio (DOS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8. Ataques por medio de código malicioso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9. Ataques a dispositivos móviles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10. Conocimientos y competencias adquiridas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11. Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12. Palabras clave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13. Ejercicios resueltos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14. Ejercicios de autoevaluación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

93 95 97 99 99 101 103 105 106 114 116 119 125 130 133 136 136 137 137 138

Tema 5. DEFENSAS BÁSICAS ANTE ATAQUES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1. Introducción, orientaciones para el estudio y objetivos . . . . . . . . . . . . . . 2. Controles de acceso físico a sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. Controles de acceso lógico a sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4. Otros controles simples de acceso a la información . . . . . . . . . . . . . . . . . . 5. Conocimientos y competencias adquiridas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6. Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7. Palabras clave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8. Ejercicios resueltos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9. Ejercicios de autoevaluación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

141 143 145 147 157 162 163 163 164 165

8

ÍNDICE

Tema 6. UNA

RESPUESTA COMPLETA A LOS PROBLEMAS DE SEGURIDAD EN

REDES DE INFORMACIÓN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1. 2. 3. 4. 5.

6.

7. 8. 9. 10. 11.

Introducción, orientaciones para el estudio y objetivos . . . . . . . . . . . . . . ¿Qué es una política de seguridad? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Aspectos físicos de la política de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Aspectos lógicos de la política de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . Aspectos legales de la política de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1. Ley Orgánica de Protección de Datos, LOPD . . . . . . . . . . . . . . . . . . . . . 5.2. Ley de Servicios de la Sociedad de la Información y Comercio Electrónico, LSSICE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3. El Esquema Nacional de Seguridad, ENS . . . . . . . . . . . . . . . . . . . . . . . . . Aspectos organizativos de la política de seguridad . . . . . . . . . . . . . . . . . . . . 6.1. El estándar ISO/IEC 15408 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2. El estándar ISO/IEC 27001 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3. Las buenas prácticas de ITIL® e ISO/IEC 20000 . . . . . . . . . . . . . . . . Conocimientos y competencias adquiridas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Palabras clave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ejercicios resueltos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ejercicios de autoevaluación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

167 169 170 178 181 185 186 193 196 201 202 204 207 211 211 212 212 213

Tema 7. INTRODUCCIÓN A LOS MÉTODOS NO CRIPTOGRÁFICOS PARA Introducción, orientaciones para el estudio y objetivos . . . . . . . . . . . . . . Herramientas para puesta en marcha de la política de seguridad Otros elementos a tener en cuenta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conocimientos y competencias adquiridas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Palabras clave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ejercicios resueltos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ejercicios de autoevaluación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

215 217 218 222 224 224 224 225 226

Tema 8. INTRODUCCIÓN A LOS CORTAFUEGOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1. Introducción, orientaciones para el estudio y objetivos . . . . . . . . . . . . . . 2. Ventajas, inconvenientes y tipos de cortafuegos . . . . . . . . . . . . . . . . . . . . . . . 3. Los filtros de paquetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1. Ejemplo: las ACL de los encaminadores Cisco . . . . . . . . . . . . . . . . . . . 4. Los gateways de aplicación o servidores proxy . . . . . . . . . . . . . . . . . . . . . . . . .

229 231 233 235 244 247

LA IMPLANTACIÓN DE LA POLÍTICA DE SEGURIDAD . . . . . . . . . . . . . . . . . . .

1. 2. 3. 4. 5. 6. 7. 8.

9


5. 6. 7. 8. 9. 10.

¿Qué se puede mejorar?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conocimientos y competencias adquiridas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Palabras clave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ejercicios resueltos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ejercicios de autoevaluación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

250 254 255 256 256 258

Tema 9. TECNOLOGÍAS DE ÚLTIMA GENERACIÓN EN CORTAFUEGOS . . . . . . . . . . 1. Introducción, orientaciones para el estudio y objetivos . . . . . . . . . . . . . . 2. Caso práctico: el modelo IPTables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1. Procesado de paquetes en IPTables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2. Sintaxis de las reglas de IPTables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3. IPTables como puerta de enlace de la red . . . . . . . . . . . . . . . . . . . . . . . . . 2.4. Redirección de tráfico entrante (DNAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5. Guardar y restaurar reglas de filtrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6. Herramientas gráficas de configuración. . . . . . . . . . . . . . . . . . . . . . . . . . . 3. Caso de estudio: el modelo Cisco ASA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1. ¿Qué son los niveles ASA? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2. Configuración básica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3. Otras características avanzadas del ASA . . . . . . . . . . . . . . . . . . . . . . . . . . 4. Conocimientos y competencias adquiridas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5. Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6. Palabras clave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7. Ejercicios resueltos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8. Ejercicios de autoevaluación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

261 263 268 269 272 276 277 278 282 283 284 286 287 293 293 294 294 295

Tema 10. INTRODUCCIÓN A LAS HERRAMIENTAS DE ANÁLISIS DE VULNERABILIDADES DE SEGURIDAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1. Introducción, orientaciones para el estudio y objetivos . . . . . . . . . . . . . . 2. Caso práctico: la herramienta Nmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1. Instalación y uso de Nmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. Caso práctico: la herramienta Nessus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1. Instalación y uso de Nessus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4. Herramientas de análisis en código fuente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1. Características generales de las herramientas SSCA. . . . . . . . . . . . 4.2. Tipos de herramientas SSCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3. ¿Qué herramienta seleccionar? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5. Conocimientos y competencias adquiridas . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

297 299 302 303 310 311 318 319 320 321 323

ÍNDICE

6. 7. 8. 9.

Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Palabras clave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ejercicios resueltos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ejercicios de autoevaluación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

324 324 324 325

Tema 11. INTRODUCCIÓN A LAS HERRAMIENTAS DE DETECCIÓN DE Introducción, orientaciones para el estudio y objetivos . . . . . . . . . . . . . . Caso práctico: Snort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Caso práctico: Sguil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Honeypots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1. Ejemplos de honeypots reales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conocimientos y competencias adquiridas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Palabras clave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ejercicios resueltos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ejercicios de autoevaluación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

327 329 334 343 350 355 362 363 364 364 365

Tema 12. DISEÑO SEGURO: ALTA DISPONIBILIDAD Y REDUNDANCIA . . . . . . . . . 1. Introducción, orientaciones para el estudio y objetivos . . . . . . . . . . . . . . 2. Diseño de soluciones de alta disponibilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. Los problemas de infraestructura y soluciones . . . . . . . . . . . . . . . . . . . . . . . . 4. Los problemas en el nivel 2 de OSI y soluciones . . . . . . . . . . . . . . . . . . . . . . . 5. Los problemas en el nivel 3 de OSI y soluciones . . . . . . . . . . . . . . . . . . . . . . . 6. Consideraciones para el resto de los niveles OSI . . . . . . . . . . . . . . . . . . . . . . 7. Consideraciones para el almacenamiento en red: SAN. . . . . . . . . . . . . . . 8. Consideraciones para los dispositivos de seguridad . . . . . . . . . . . . . . . . . . 9. Conocimientos y competencias adquiridas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10. Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11. Palabras clave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12. Ejercicios resueltos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13. Ejercicios de autoevaluación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

367 369 371 374 376 377 379 380 382 385 385 385 386 387

INTRUSIONES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1. 2. 3. 4. 5. 6. 7. 8. 9.

Tema 13. INTRODUCCIÓN A LA CRIPTOGRAFÍA COMO HERRAMIENTA DE SEGURIDAD EN REDES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1. Introducción, orientaciones para el estudio y objetivos . . . . . . . . . . . . . . 2. Elementos básicos de cualquier sistema criptográfico . . . . . . . . . . . . . . . 3. Distintos niveles criptográficos en el software de redes y sistemas

389 391 395 400

11


4. 5. 6. 7. 8. 9.

Tipos de ataques a sistemas criptográficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conocimientos y competencias adquiridas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Palabras clave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ejercicios resueltos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ejercicios de autoevaluación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

403 405 406 407 407 408

Tema 14. MÉTODOS CRIPTOGRÁFICOS: SISTEMAS DE CLAVE PRIVADA, SISIntroducción, orientaciones para el estudio y objetivos . . . . . . . . . . . . . . Algoritmos de clave privada o de criptografía simétrica . . . . . . . . . . . . . Funciones de una sola vía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Algoritmos de clave pública o de criptografía asimétrica . . . . . . . . . . . . Conocimientos y competencias adquiridas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Palabras clave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ejercicios resueltos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ejercicios de autoevaluación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

411 413 416 421 427 437 438 438 438 440

Tema 15. CERTIFICACIÓN, AUTENTICACIÓN E INTEGRIDAD DE LA INFORMACIÓN. FIRMA DIGITAL Y PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1. Introducción, orientaciones para el estudio y objetivos . . . . . . . . . . . . . . 2. Autenticación, integridad y no repudio de la información . . . . . . . . . . 3. Los sistemas de firma digital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4. El estándar X.509 y las autoridades de certificación. . . . . . . . . . . . . . . . . . 5. Los modelos de infraestructura de clave pública o PKI . . . . . . . . . . . . . . 6. Problemas de seguridad de las firmas digitales y de las PKI . . . . . . . . 7. Conocimientos y competencias adquiridas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8. Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9. Palabras clave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10. Ejercicios resueltos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11. Ejercicios de autoevaluación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

443 445 447 453 456 462 470 473 474 475 475 476

Tema 16. PROTOCOLOS CRIPTOGRÁFICOS MÁS HABITUALES. . . . . . . . . . . . . . . . . . . 1. Introducción, orientaciones para el estudio y objetivos . . . . . . . . . . . . . . 2. Protocolos de comercio electrónico: SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. Protocolos de comercio electrónico: SET. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4. Los protocolos IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

479 481 483 491 494

TEMAS DE CLAVE PÚBLICA Y FUNCIONES DE UNA SOLA VÍA . . . . . . . .

1. 2. 3. 4. 5. 6. 7. 8. 9.

12

ÍNDICE

4.1. El protocolo AH - Authentication Header . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2. El protocolo ESP - Encapsulating Security Payload . . . . . . . . . . . . . 4.3. Las asociaciones de seguridad en IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4. Un ejemplo básico de uso de IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . El protocolo PGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conocimientos y competencias adquiridas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Palabras clave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ejercicios resueltos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ejercicios de autoevaluación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

496 497 499 503 505 510 511 511 511 513

Tema 17. INTRODUCCIÓN A LAS REDES PRIVADAS VIRTUALES . . . . . . . . . . . . . . . . 1. Introducción, orientaciones para el estudio y objetivos . . . . . . . . . . . . . . 2. Caracterización de las redes privadas virtuales (RPV). . . . . . . . . . . . . . . . 2.1. Ventajas e inconvenientes de las RPV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2. Arquitectura y planificación de RPVs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3. Rendimiento, mantenimiento y seguridad . . . . . . . . . . . . . . . . . . . . . . . . 3. Configuración típica de una RPV que use IPSec . . . . . . . . . . . . . . . . . . . . . . . 4. RPV mediante SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5. RPV a través de redes MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6. Conocimientos y competencias adquiridas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7. Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8. Palabras clave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9. Ejercicios resueltos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10. Ejercicios de autoevaluación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

515 517 519 523 525 531 535 543 549 554 555 556 556 557

Tema 18. INTRODUCCIÓN A LA SEGURIDAD DE REDES INALÁMBRICAS . . . . . . 1. Introducción, orientaciones para el estudio y objetivos . . . . . . . . . . . . . . 2. Redes inalámbricas. Conceptos básicos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1. 802.11 a/b/g/n. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2. Puntos de acceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3. SSID, BSSID, dirección MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4. Paquetes baliza (Beacons) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5. Encriptación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. Teoría de ataques a redes inalámbricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1. Problemas de autenticación, privacidad e integridad . . . . . . . . . . 3.2. Ataques. Fase de reconocimiento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3. Tipos de ataques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4. Ataques a clientes de redes inalámbricas . . . . . . . . . . . . . . . . . . . . . . . . . .

559 561 562 562 563 563 564 564 564 564 566 567 572

5. 6. 7. 8. 9. 10.

13


4. Medidas no criptográficas para protección de redes inalámbricas 4.1. Principios de diseño seguro para redes inalámbricas . . . . . . . . . . 4.2. Malas defensas no criptográficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3. Buenas defensas no criptográficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5. Medidas criptográficas para protección de redes inalámbricas . . . . 5.1. WEP (Wired Equivalent Privacy) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2. WPA (Wi-Fi Protected Access) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3. WPA2-Enterprise con Certificados digitales . . . . . . . . . . . . . . . . . . . . . . 6. Conocimientos y competencias adquiridas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7. Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8. Palabras clave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9. Ejercicios resueltos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10. Ejercicios de autoevaluación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

575 575 578 579 582 582 585 588 591 591 591 592 593

Solucionario a los ejercicios de autoevaluación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

595

14

PRESENTACIÓN

Hace ya casi diez años que parte de los autores de este libro que tienes en tus manos publicamos otro, llamado Seguridad en las comunicaciones y en la información, para la colección de Unidades Didácticas de la UNED. Su objetivo era doble: servir como texto base, adecuado a las exigencias didácticas de la UNED, para la asignatura del mismo nombre, y ser el primer libro escrito en español que cubriera, a nivel introductorio pero completo, las diferentes facetas de una disciplina que cualquier profesional iba a necesitar para su trabajo. Hoy volvemos a intentarlo, actualizando muchos de los contenidos de aquel libro e incluyendo nuevos conocimientos, procesos y herramientas. En estos diez años, y de forma paralela al crecimiento y ubicuidad de las redes de comunicación, la seguridad informática se ha convertido en una disciplina imprescindible para un buen profesional y necesaria para prácticamente cualquier persona, venga del campo y disciplina que venga. Hemos asistido a su crecimiento en cuanto a desarrollos y problemas nuevos, pero también en cuanto a su necesidad de estar en el día a día rutinario de todo el mundo. La sociedad necesita profesionales bien cualificados para trabajos especializados en proporcionar seguridad a datos, sistemas y comunicaciones. Para ellos este libro pretende ser una introducción práctica a asuntos y conocimientos sobre los que tendrá que profundizar. Pero además los autores hemos pretendido también hacer un libro que, de manera amena pero estricta, ayude al público en general a entender situaciones que, cada vez más, son rutinarias. En un mundo en el que todos utilizamos herramientas que llamamos «sociales» para la comunicación personal y profesional, y en el que buena parte de nuestra información viaja por las redes o se guarda en la «nube», todos deberíamos conocer los fundamentos mínimos para mantener una actitud prudente en nuestra vida digital.

15


En un mundo en el que hasta los currículums se buscan por Internet, los documentos se entregan en dispositivos usb, las conferencias se hacen por la red y, en definitiva, el trabajo profesional y el estudio se apoyan inevitablemente en ordenadores, teléfonos móviles y redes, toda persona con criterio debe saber que lo que se puede y lo que se debe hacer no es ya lo mismo que hace una generación. En un mundo en el que se discute sobre si se debe perder privacidad para obtener seguridad, y se nos pretende convencer de que esto traerá seguridad completa, es interesante recordar que, como dijo Benjamin Franklin, únicamente hay dos cosas seguras al 100%: la muerte y el pago de impuestos. El libro ilustra las debilidades y vulnerabilidades de seguridad más habituales, así como los principios de defensa básicos de sistemas y redes. Analiza desde diferentes puntos de vista cómo clasificar los ataques a la seguridad de datos, sistemas y comunicaciones, asociándolos con las soluciones más habituales. Introduce, con ejemplos prácticos, las herramientas más habituales para la defensa en redes, como cortafuegos, analizadores de vulnerabilidades y sistemas de detección de intrusiones. Intenta hacer una introducción amena a la criptografía aplicada, sin la cual no se puede entender cómo mantener la integridad y privacidad de los datos locales o en forma de mensajes por la red. Analiza los procesos y herramientas que hay que conocer para entender cómo se realiza la autenticación de personas y dispositivos en cualquier tipo de red. El lector podrá aprender cómo aplicar los algoritmos criptográficos más utilizados, así como los protocolos de comunicación creados a partir de los mismos. Los certificados digitales y la firma digital, cada vez más extendidos, y muy poco entendidos, aparecen claramente ligados a su uso habitual. Hemos intentado pues hacer una obra que, siguiendo una vez más los criterios didácticos de la UNED, sirva de guía en español para un público muy variado, aun pensando muy especialmente en los alumnos de los grados de Ingeniería en la Universidad española. No sabemos aún si hemos conseguido nuestro objetivo pero esperamos que nuestro entusiasmo y esfuerzo os sea de ayuda en vuestra trayectoria académica, profesional y personal. Éste ha sido, en realidad, nuestro objetivo principal. Los autores

16

Tema 1

Descripción del problema de seguridad en redes. Tipos de ataques

1. Introducción, orientaciones para el estudio y objetivos 2. Unas cuantas preguntas que ayudan a definir mejor el problema 3. Soluciones «perfectas» y soluciones razonables 4. Conocimientos y competencias adquiridas 5. Bibliografía 6. Palabras clave 7. Ejercicios resueltos 8. Ejercicios de autoevaluación

1. INTRODUCCIÓN, ORIENTACIONES PARA EL ESTUDIO Y OBJETIVOS Nuestro mundo está cada vez más repleto de sistemas, compuestos por máquinas y por programas. Casi cada objeto que nos rodea es un sistema, compuesto por una o varias máquinas, controladas por una o varias piezas de componentes que se denominan software, que no son sino programas de ordenador. Muchos de esos sistemas (ordenadores, dispositivos de red, teléfonos inteligentes, tabletas, etc.) forman parte de redes, privadas o de empresa, públicas, grandes o pequeñas, interconectadas unas con otras y comunicándose entre sí mediante otro gran sistema hardware (cables o inalámbrico), gestionado, a su vez, por un conjunto de aplicaciones con diferentes objetivos, a los que se denominan protocolos de comunicaciones. La red Internet es, seguramente, el sistema más complejo que se haya desarrollado jamás. Está compuesto por muchos millones de ordenadores de todo tipo interconectados mediante una red física de complejidad sin igual que, además, crece sin parar. Así mismo, cada ordenador contiene gran cantidad de programas que interactúan entre sí (en el mismo sistema) o con otros programas alojados en otros ordenadores de la red. Este sistema, al que se denomina Internet, suele estar recibiendo, y procesando, información de muchos millones de personas a la vez. Esta información no sólo proviene ya de seres humanos, sino que se genera incluso de forma automática. Internet, compuesta por las redes y los sistemas, ha modificado desde hace unos años todas las formas habituales de comunicación, revolucionando los hábitos de vida y formas de trabajar de todos los sectores de la sociedad. Por otro lado, y desde el punto de vista del objetivo de este libro, todos los sistemas exhiben una serie de propiedades interesantes.

19


Los sistemas son complejos y capaces de interactuar. Tomando como ejemplo un ordenador: sus miles de programas tienen cada uno su propio trabajo que realizar, pero, también, desarrollan este trabajo basándose en la interacción con sus semejantes en el mismo ordenador y en otros ordenadores. Otra propiedad curiosa (y, a veces, desagradable) de los sistemas es que muchos de ellos hacen cosas no pensadas (ni diseñadas) por sus creadores y usuarios. Se dice formalmente que los sistemas tienen propiedades no buscadas. Como ejemplos, se puede citar la forma en que los teléfonos móviles han cambiado la manera en la que las personas quedan para verse o, a veces, la forma en la que se enamoran, etc. O, también, se puede pensar en cómo los aparatos de aire acondicionado han cambiado la manera en la cual se transmiten las enfermedades y catarros. Incluso han cambiado las fechas del año en las es que es más frecuente constiparse. Los sistemas de los que se ocupa este libro, especialmente los ordenadores de todas clases y con cualquier tipo de software, tienen estas propiedades no buscadas (bugs). Un bug es una clase de «fallo del sistema» muy típico de la informática; es, simplemente, una propiedad no deseada de un sistema, que no se debe confundir con que el sistema no funcione correctamente. Puede que un bug provoque que el sistema no funcione correctamente o puede que el bug provoque simplemente comportamientos que no estaban planeados. Está además demostrado que 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 en los sistemas y protocolos. La suma de tales bugs de seguridad y de las vulnerabilidades de seguridad originadas en un desarrollo incorrecto, precipitado (o ambas cosas a la vez) de las aplicaciones y del software en general, provocan lo que conocemos como «agujeros de seguridad». Si son aprovechados por alguien mal intencionado, los sistemas y las redes en los que están sufrirán ataques a su seguridad. Todos estos bugs y vulnerabilidades hacen que sea difícil conseguir que un sistema, como puede ser la red de una Universidad, de una empresa, o, más aún, la red Internet, sea seguro. Los sistemas seguros son difíciles de obtener. Los sistemas complejos seguros son aún más difíciles de construir.

20

DESCRIPCIÓN DEL PROBLEMA DE SEGURIDAD EN REDES. TIPOS DE ATAQUES

Como se estudiará a lo largo de este libro, los ataques a la seguridad de sistemas y redes se aprovechan de esa complejidad de la que se está hablando, ya sea para realizar ataques de obtención de información (de contraseñas de sistemas y aplicaciones o de datos), ataques de acceso no autorizado a sistemas, aplicaciones, etc., ataques de modificación de información o de borrado de información o ataques de denegación de servicio, que tienen como consecuencia la inhabilitación de un servidor Web o de correo y, en general, no poder usar un recurso concreto. Veremos como este último tipo de ataques han llegado recientemente a inhabilitar Internet en una parte del mundo. Contra este tipo de problemas, se han desarrollado tecnologías informáticas que, como los cortafuegos o la criptografía de comunicaciones, parecen impecables. Desde luego, son necesarios, como se verá más adelante, pero, a su vez, están compuestos de sistemas, que pueden (y, por desgracia, suelen) exhibir los mismos problemas citados. Si uno se dedica a investigar los ejemplos recientes de problemas de seguridad en sistemas y redes (una sencilla búsqueda en Internet proporciona cientos de reportes sobre incidencias de este tipo), citados en la introducción general, comprobará que prácticamente todos (incluidos los que tienen que ver con problemas en sistemas de seguridad) están relacionados con esas propiedades de los sistemas que se han citado previamente. Ayudará bastante pensar, desde el principio (y a lo largo de todo el libro), que, con todos sus componentes hardware, software, etc., la seguridad es un sistema dentro de sistemas mayores, más que un producto o un conjunto de ellos, más que una o varias tecnologías, la seguridad es un proceso, que hace intervenir todas las tecnologías, todos los productos, todas las herramientas y, especialmente, el sentido común de los seres humanos que la gestionan, ese mismo sentido común que «es el menos común de los sentidos». Por otro lado, «no hay nada nuevo bajo el sol». La seguridad de las redes, sistemas y datos usa nuevas herramientas y procedimientos, nuevas tecnologías, pero no será digna de uso si no utiliza las viejas técnicas de seguridad humana que se llevan usando (cuando se usan) miles de años en muy diversas circunstancias. Pensemos, por ejemplo, en un buen sistema de seguridad de un banco: debe tener en cuenta la prevención, la detección y la respuesta al proble-

21


ma concreto. Debe tener una cámara acorazada para proteger el dinero, joyas, etc. (prevención), debe tener alarmas para identificar a los posibles ladrones (detección) y debe contactar con los guardias (o la policía) para que los detenga (respuesta). La seguridad informática de la que se ocupa este libro suele tener muy en cuenta la prevención (cortafuegos, criptografía, etc., como se verá más adelante) pero está evolucionando en cuanto a las otras dos (que también se tratarán en el libro). Se utilizan cada vez más herramientas de detección (como los sistemas de detección de intrusiones) y herramientas, procedimientos y sistemas (muchas veces humanos) de análisis y gestión de riesgos y auditoria de vulnerabilidades. Con todo esto en mente, 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, explorando alguna solución aparentemente perfecta (pero solo aparentemente), y proponiendo una solución imperfecta pero realista, basada en lo que se llamará política de seguridad del sistema, herramienta básica para la seguridad y concepto del que se hablará constantemente en este libro, pues será la «idea-motor» del resto del libro. 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. Para ello, se va a delimitar más el problema usando una vieja táctica pedagógica: hacerse preguntas clave. Nuestra primera pregunta clave debe resultar evidente, es de esperar, a estas alturas: 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 organizació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. Por supuesto, 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

22


seguridad. Por ejemplo, supóngase una empresa con una base de datos con información de sus productos. Digamos que esta base de datos es accesible a los posibles clientes por Internet. Supóngase que se tiene una copia de seguridad de la base de datos suficientemente buena y que se tiene un plan de recuperación de la base de datos en caso de pérdida de datos. Supóngase que el coste de tal recuperación se estima en 5.000 €. ¿Tiene sentido poner en marcha un sistema de prevención de ataques que cueste 50.000 €? La respuesta suele ser ¡NO!, pero, y si la empresa solo vende por Internet, ¿en cuánto dañaría su imagen ese ataque y perdida? Esta situación hay que evaluarla con detalle haciendo un buen análisis de riesgos, del que se tratará más adelante. Como ya se ha comentado, esto no es más que aplicar ideas generales a la informática. Cuando se va a contratar un seguro para nuestra casa, también se realiza un inventario para la compañía de seguros. El objetivo del inventario es poder obtener una idea precisa de la cuantía de las perdidas en caso de robo. Otra pregunta que ayudará mucho a definir el problema es: 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 a esta pregunta suele desarrollarse un modelo de confianza. Con este análisis, se debe decidir qué empleados tienen acceso a que activos y por qué, qué tipo de acceso se va a dar a cada persona de cada organización que colabore con la empresa, qué tipo de acceso (físico o lógico) van a tener, es decir, acceso a ordenadores, redes y datos. Asimismo, se deberá pensar en qué tipo de acceso van a tener los posibles clientes de la organización. La cosa se complica un poco (y suele hacerlo) si alguno de los clientes es, además, colaborador de la organización. Además, se debe estudiar, con cuidado y detalle, quién y por qué querría atacar a la organización. Esto, que está muy ligado con lo anterior, hará incluir una categoría de individuos que no ha aparecido aún: los «malos» de la película. Podría parecer que son clases separadas, que estos últimos son de una categoría distinta a la de los empleados, compañeros, colaboradores o clientes; pero esto no suele ser así, desgraciadamente.

23


Si uno estudia distintos estudios sobre perdidas económicas debidas a ataques informáticos (por ejemplo los que se pueden consultar en http:// www.fbi.gov/, http://www.inteco.es, http://www.cert.org/, http://www.sans. org/), observa que se dan una serie de características comunes: 1. Alrededor del 65% (el 55% en unas encuestas, el 75% en otras) de los encuestados reconocen haber sido atacados (perdidas de datos, perdida de información, inhabilitación de servidores o de acceso a redes, cambio de información, robo, fraude, etc.) en los dos últimos años. 2. Alrededor del 60% de los encuestados reconocen que algunos de sus ataques fueron realizados desde el interior de sus organizaciones. 3. Alrededor del 60% de los encuestados reconocen que algunos de sus ataques fueron realizados mediante conexiones desde la red Internet. 4. Prácticamente todos los encuestados reconocen haber sufrido más incidentes de este estilo que en el año anterior. Con esto se llega a la conclusión de que el perfil del posible atacante no hay que buscarlo solo en un «usuario» de la red Internet, sino también dentro de la organización. En cuanto a los tipos de atacantes, se debe empezar hablando del hacker. Es ésta una palabra que ha cambiado de significado con el tiempo. Al principio, los hackers eran simplemente personas muy expertas en un sistema operativo, protocolos, etc., que, en el caso de encontrarse fallos de seguridad de un sistema, lo notificaban al fabricante, incluso, a veces, facilitando, además, una posible solución. Tales personas existen todavía y, aunque sus hallazgos suelen ser bien interesantes, hay una polémica, hoy en día, sobre si hacen bien o mal a la industria informática. Independientemente de esto último, hoy en día se ha pasado a darle un sentido peyorativo a la palabra hacker, pensando en alguien que, por distintas motivaciones (venganza, ira, cuestiones religiosas, políticas o simplemente reto intelectual), ataca las redes o sistemas de una organización. Algunos ejemplos de tales motivaciones son: • Empleados que son despedidos injustamente, desde su punto de vista y que dejan en los sistemas de la empresa «sorpresas» que destruyen datos de la organización o la dañan de muy diferentes maneras.

24


• Empleados que creen ser injustamente pagados, a menudo en comparación con algún compañero suyo, y alteran los registros de personal propios, de los compañeros o de ambos. • Defensores de los derechos civiles (principalmente en los EE.UU.) que atacan a los servidores Web de organizaciones racistas y, por supuesto, el caso contrario. • Hackers que roban mensajes de correo electrónico de unos políticos, para otros políticos. • Individuos que acceden a sitios Web muy conocidos (por ejemplo, el del periódico New York Times) para cambiar su contenido, por razones de línea editorial u otras. • Todos los ejemplos de los últimos años relacionados con el fenómeno «wikileaks» Un caso especial es el de «Anonymous», un seudónimo usado internacionalmente por diferentes grupos y/o individuos para —poniéndose o no de acuerdo con otros— realizar en su nombre acciones o publicaciones individuales o concertadas. Desde el 2008 Anonymous se manifiesta en acciones de protesta a favor de la libertad de expresión, de la independencia de Internet y en contra de diversas organizaciones. Otro tipo de atacante es el «amateur que juega» (en EE.UU. se les llama «wannabes», despectivamente). El perfil suele ser el de una persona joven (o muy joven), sin experiencia en sistemas ni de redes, que usa herramientas automatizadas contra sistemas por Internet, para ver qué pasa. Como citaba uno de ellos en una revista, ¿para qué voy a jugar «a matar marcianitos» en mi PC, pudiendo desconectar redes enteras de Internet?, esto es mucho más emocionante. En este caso si hay una diferencia con la vida «no informática». En la «vida real», un ladrón profesional puede llegar a «formar» a una serie de aprendices con disciplina, esfuerzo, entrenamiento y, sobre todo, mucho tiempo, hasta conseguir que alguno consiga el «título» de ladrón profesional. Hay que insistir, cuesta mucho tiempo. Una persona, suficientemente brillante, pero desequilibrada, puede crear una aplicación que desconecte redes (o solo sistemas) de Internet, valiéndose de las numerosas vulnerabilidades existentes en ellos, hacerla fácil de uso, crear un manual de usua-

25


rio de la herramienta y publicarla en Internet, accesible a mucha gente a la vez, que la podrán usar de forma incontrolada para estas y otras muchas aplicaciones. Estamos hablando de herramientas reales, que han causado muchos problemas y que forman parte de lo que, más adelante, se definirán como «herramientas de ataque por denegación de servicio». Suelen pedir como entrada de datos el nombre del sistema que se quiere desconectar y, como mucho, el nombre de otro sistema por el que se quiera hacer pasar el atacante. Colocadas «sabiamente» en determinados Web o servidores ftp, son accesibles a decenas de miles de «amateurs» en pocos días y estos solo tienen que probar repetidamente contra multitud de sitios «a ver qué pasa». Los amateurs son muy peligrosos. Hay un tercer tipo de atacante, cada vez más numeroso y más peligroso: el profesional. Se conoce como tal al individuo que presta (interesada o desinteresadamente) sus conocimientos y experiencia para atacar un objetivo concreto, que puede ser el robo, la alteración de información con fines delictivos o el sabotaje. Lo que les caracteriza especialmente es el modo «profesional» de atacar. Al igual que un ladrón que pretende robar en una serie de casas de una calle obtiene primero la mayor cantidad de información de cada casa, piso, vecino, portero, automóviles, etc., el profesional obtiene una gran cantidad de información para estar bien seguro de cuáles son los puntos débiles y por dónde puede empezar su trabajo. El siguiente paso suele ser el ataque de acceso a algún sistema, pero borrando sus huellas y sin alterar nada (o lo menos posible). Suele dejarse varios caminos de huida posibles, suele atacar mediante saltos (conexiones de equipo a equipo) y tener muy claro dónde, cuándo y durante cuánto tiempo estará seguro en su ataque. Suele tener muy claro que el atacado debe defender todas sus posiciones, el solo tiene que encontrar el eslabón más débil y aprovecharse del dicho de que «una cadena es tan segura como su eslabón más débil». Además, estos profesionales se alían en verdaderas organizaciones «cibercriminales», que aprovechan las múltiples vulnerabilidades existentes y las herramientas de ataque en continuo desarrollo (como las «botnets» de las que hablaremos en varios temas del libro) para crear un verdadero «modelo de negocio» en la red, basado en la oferta de diferentes «servicios» de ataque a cambio de una contraprestación económica. Todos las fuerzas de orden público internacionales siguen sus pasos en lo que puede catalogarse como «guerra global» contra el crimen organiza-

26


do en Internet. Muy relacionados con este tipo de situaciones son los continuos ataques entre servicios militares de diferentes países por Internet, que ha dado lugar a la aparición del término «ciberguerra», que está poniendo en peligro desde la seguridad de instalaciones civiles y militares en muchos países hasta, por ejemplo, misiones concretas de la OTAN en zonas de conflicto. Otra pregunta muy importante para caracterizar finalmente el problema es: C) ¿Cómo se quiere proteger? o, más concretamente, ¿qué tecnologías, herramientas, sistemas concretos, procesos se van a utilizar para protegerlo? Para contestar bien a esta pregunta se tienen que conocer dos temas complejos: i) los distintos tipos de ataques posibles, ii) las distintas defensas posibles, y a esto se dedican el resto de temas de este libro. Antes de seguir adelante, hay que hacer un comentario muy importante. No será posible nunca conocer todos los distintos tipos de ataques. Es imposible que lo haga nadie, pues nadie puede abarcar todo lo hecho y todo lo que se puede estar haciendo ahora y se podrá hacer más adelante. Así, un buen profesional ha de conformarse con conocer el mayor número posible y estar bien informado sobre todos los nuevos que van apareciendo. No obstante, y antes de estudiarlos con más detalle en el tema 4 de este libro, se van a enumerar, como introducción, los tipos más importantes: • Ataques para obtener información. Son ataques «no intrusivos», que tienen como objetivo obtener información (como direcciones IP de redes y sistemas, sistemas operativos de cada equipo, números de puerto abiertos, aplicaciones y sus versiones, contraseñas, etc.). • 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. Pueden ser peligrosos si el acceso se hace, además, a través de una cuenta privilegiada del sistema.

27


• 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, con idea de aprovecharse de esa información, de borrarla o, peor aún, de modificarla con algún fin no demasiado lícito. • Ataques de denegación de servicio. Buscan dejar no disponible un sistema, un servicio o una red, habitualmente agotando el recurso, sea este el ancho de banda, espacio en disco, conexiones TCP, etc. Desafortunadamente, este tipo de ataques no suele necesitar ningún acceso previo a ningún sistema y en el caso de algunos, como los DDOS («Distributed Denial Of Service») son prácticamente imparables. Éstos serían los más importantes, pero, además, hay que recordar que el atacante no tiene por qué cumplir fielmente con un tipo de ataque determinado. Cada vez más, los ataques suelen ser combinaciones de varios de estos ataques. En cuanto a las defensas posibles, aspecto muy relacionado obviamente con el anterior, se van a incluir igualmente en este libro, algunas de las más importantes: 1. Esquemas de seguridad de sistemas operativos. Especialmente para el caso de servidores con información muy relevante y de dispositivos de gestión de red, se deben mantener unos buenos esquemas de seguridad de ficheros, usuarios y aplicaciones, así como de servicios de red controlados desde tales sistemas. Hoy en día, además, estos esquemas son fundamentales para todo tipo de dispositivos móviles. 2. Sistemas de identificación o autenticación seguros. Hay muchos y muy razonables, desde las contraseñas hasta los sistemas biométricos, certificados digitales, tarjetas de identificación o distintas combinaciones. Se pueden usar tanto para acceso local a dispositivos como para acceso remoto. 3. Sistemas de cortafuegos (o firewalls). Sistemas de control de la información en forma de mensajes que entran o salen de una red. Se han convertido en esenciales y los hay de muchos tipos distintos. 4. Sistemas criptográficos. Son sistemas que permiten, de varias formas distintas, mantener la integridad y la autenticación de mensa-

28


jes o datos, así como la privacidad o confidencialidad de los mismos. Se integran en protocolos y en parte de distintos sistemas operativos y aplicaciones, que usan algoritmos criptográficos suficientemente probados. 5. Sistemas antivirus. Son aplicaciones locales, o distribuidas, que permiten defenderse de los virus informáticos, nombre que reciben algunas aplicaciones utilizadas para cualquiera de los ataques citados más arriba y que se explorarán en más detalle a lo largo del libro. 6. Sistemas de análisis de vulnerabilidades. Son aplicaciones que permiten buscar en sistemas y aplicaciones instaladas distintos bugs o vulnerabilidades conocidas, para decidir si se corrigen (parchean), se cambian de versión o se dejan como están. 7. Sistemas de detección de intrusiones. Son sistemas o aplicaciones que permiten, en tiempo real, detectar determinados tipos de ataques y alertar sobre ellos, a la vez que, en algunos casos, pueden pararlos. 8. Estándares para sistemas de gestión de seguridad, como el ISO/ IEC 27001, que se describe en el tema 6 y que permite organizar los procesos y procedimientos de gestión de la seguridad de cualquier organización. Una vez conocidos los ataques y las posibles defensas, se deberá decidir qué defensas se eligen frente a que ataques. Aunque esto no podrá hacerse hasta haber contestado a la pregunta más comprometida de todas: 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, como sucede para cualquier problema de seguridad. 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, que implementen algunas de las defensas citadas.

29


• El tiempo empleado en configurarlas y educar a los usuarios en su uso. • 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, con todos los procedimientos, roles y responsabilidades asociadas. • El tiempo empleado, en muchos casos, en volver a una situación estable, después de la inconveniencia para los usuarios de alguno de los nuevos sistemas. Así pues, resumiendo, 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. Finalmente, se debería tratar de resumir todo este conocimiento en un análisis de riesgos que, de manera condensada, tendría 4 puntos clave: 1. Valorar los activos. 2. Entender todas las posibles amenazas. 3. Monitorizar y conocer todas las debilidades y vulnerabilidades del sistema. 4. Tratar de poner en marcha todas las medidas posibles para disminuir la probabilidad de tener pérdidas. 3. SOLUCIONES «PERFECTAS» Y SOLUCIONES RAZONABLES Aunque este tema es únicamente descriptivo (como su nombre indica), ya se ha visto qué tipos de problemas se pueden encontrar para asegurar, en lo posible, las redes de comunicaciones. Éstos son realmente complejos y con muchas connotaciones físicas y lógicas. Contra problemas tan complejos como éstos se puede hacer una aproximación completa, en el sentido de tratarlos como problemas científicos, estudiarlos de manera analítica, teniendo como objetivo que, en el sistema concreto, la probabilidad de sufrir un ataque sea lo más cercana a cero.

30


A esta aproximación, que ahora se va a desarrollar, se le da el nombre de «aproximación militar». Tal aproximación, que sería perfecta si lograra su objetivo —probabilidad de sufrir un ataque igual a cero— pasa por cumplir y hacer cumplir una serie de requisitos formidables sobre todas las partes de la organización que va a ser asegurada y llevaría a adoptar una serie de decisiones de mucho peso, como por ejemplo: • 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 comprobado, lo que suele querer decir, tecnología menos moderna. • La no aceptación de ninguna actualización de ningún sistema operativo hasta que hubiera pasado un margen suficiente de «exposición» al mundo real como para estar «tranquilos». • No conectarse a Internet o, si ya se estuviese conectado, desconectarse de ella y constituir una red propia. Durante años hubo organizaciones, como los ejércitos, algunos sistemas del transporte ferroviario japonés, proyectos de investigación de tecnología militar, etc., que intentaron poner en marcha esta solución perfecta, pero no es posible. Hoy en día, es imposible pensar en implementar con éxito las decisiones citadas en prácticamente cualquier organización. Cualquiera que lea una revista de informática actual, podría pensar que con la cantidad de herramientas disponible de todo tipo, esto no debería ser así; pero conviene recordar, una vez más, que la seguridad no es un producto, sino un proceso, en el que están involucrados desde sistemas software y hardware, redes, aplicaciones, organizaciones y personas. La criptografía, por ejemplo, no ha sido nunca en su historia tan potente y nunca ha sido tan fácilmente burlada como hoy en día. Existen muchas herramientas, pero hay que saber usarlas, no solo en el sentido de configurarlas, sino en el sentido de dirigirlas en el sentido adecuado, con la estrategia válida, que, por supuesto, tiene que tener en cuenta el componente económico. En este sentido es en el que se habla de una aproximación realista, en la cual se tienen en cuenta todos los factores citados en el apartado ante-

31


rior, pero también el de no gastarse todo el presupuesto de la organización y sus recursos, que debe seguir funcionando y cumpliendo sus objetivos, sean éstos de negocio (telecomunicaciones, financieros, energéticos, etc.) o públicos (sanidad, transporte, educación, etc.). Y en el marco de esta aproximación se define lo que se denomina política de seguridad. Siguiendo los criterios más comúnmente aceptados, como los del «IETF Site Security Handbook», se puede definir 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.

El propósito principal de una política de seguridad debe ser informar a los usuarios, trabajadores y personal de dirección de los requisitos obligatorios para proteger los valores tecnológicos e información de la empresa. La política debería especificar los mecanismos a través de los cuales estos requisitos puedan ser conocidos. Otro objetivo de la política de seguridad debe ser proporcionar una base para adquirir, configurar y auditar todos los dispositivos y las redes. Por tanto, emplear un conjunto de herramientas de seguridad sin una política de seguridad implícita, no tendría mucho sentido. Una buena política de seguridad debe cumplir una serie de normas generales, una vez más, de sentido común: 1. Debe poderse implantar. Como consecuencia de ella, se deben tener unas normas de comportamiento para los usuarios 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, así como el significado técnico y legal de una serie de conceptos que se irán analizando en detalle en el libro, como confidencialidad, integridad, identificación, autenticación, etc. 3. Debe cumplirse. Debe contemplar una serie de procedimientos de auditoría, para comprobar que no es «papel mojado», sino que está, realmente, cumpliéndose. Debe contemplar, igualmente, sanciones adecuadas a cada una de las posibles infracciones. En este sentido, es muy importante señalar que debe estar respaldada completa-

32


mente por la dirección de la organización, sin tal apoyo nunca se puede llevar a cabo. 4. Debe definir responsabilidades. No puede ser igual el papel de un usuario que el de un administrador de una gran red, en el sentido de las distintas responsabilidades. 5. Debe permitir que siga realizándose el trabajo normal. Si no fuera así, se estaría en la aproximación militar: no se permite un nuevo servicio, hasta que sea completamente seguro. Debe ofrecerse seguridad, pero no al precio de que no funcione la organización. Debe implicar un análisis de riesgos, teniendo en cuenta el precio de la seguridad frente a la probabilidad de pérdida. 6. Debe ser exhaustiva. Debe tener en cuenta todos los componentes del sistema, es decir, debe incluir como objetivos asegurar: • Componentes físicos. • Sistemas informáticos (ordenadores personales, portátiles, servidores, hosts, dispositivos móviles, etc.) y su software. • Aplicaciones en red de los sistemas. • Dispositivos de red (encaminadores, conmutadores, etc.) y su software. • Sistemas de gestión de red. • Organizaciones humanas, individuos, departamentos, divisiones, colaboradores externos, clientes, etc. 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 enunciado de que la seguridad es un proceso. Al descubrir mediante una auditoria por ejemplo, un fallo en el sistema de seguridad no contemplado en la política, hay que poder hacer una nueva versión de la misma e implementarla. Habrá que tener en cuenta muchos más detalles, como se verá en el tema 6. No es este el momento de profundizar en ellos, pero su enumeración dará una idea de conjunto de su importancia:

33


• Contemplar el principio de privilegio mínimo necesario. • Contemplar el principio de defensa en profundidad, con la existencia de más de un nivel de defensas. • Contemplar el principio de diversidad de defensa, con la existencia de defensas de distintos tipos. • Tener conocimiento permanente de los puntos débiles de la organización. • Participación universal del personal de la organización. • Simplicidad de los mecanismos de seguridad. Esta aproximación es, en el fondo, la aplicación (compleja a veces, sencilla otras veces) del sentido común al problema existente. Aun así, todavía hay muchas organizaciones en las que debería estar utilizándose, pero no se hace. En las encuestas previamente citadas, se sigue teniendo alrededor de un 30% de los encuestados sin ninguna política de seguridad y un ¡70%! con una política de seguridad que reconocen que no se cumple, ni se mantiene. En el mundo actual, y se está haciendo día a día, la mayor parte de las organizaciones adoptarán, más tarde o temprano, una aproximación semejante. En España, el cumplimiento de leyes como la LOPD (Ley Orgánica de Protección de Datos), la LSSICE (Ley de Servicio de Sistemas de Información y Comercio Electrónico), o el Esquema Nacional de Seguridad, está obligando ya a muchas empresas a poner en marcha esta aproximación. Solo se verá la solución perfecta (que nunca lo es del todo) en contadas ocasiones. La enumeración de dispositivos y herramientas no criptográficas utilizadas para hacer cumplir la política de seguridad no sería completa sin hacer referencia a lo que suele denominarse diseño seguro de redes. Esto hace referencia a la seguridad, en un sentido distinto al usado habitualmente en este libro. En realidad, se estaría hablando, más bien, del concepto de fiabilidad del sistema, de alta disponibilidad de la información. Los procedimientos y herramientas utilizadas para mantener tal fiabilidad 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.

34


4. CONOCIMIENTOS Y COMPETENCIAS ADQUIRIDAS Se ha hecho una descripción introductoria de cuál es el objetivo que se quiere definir y en el que se quiere profundizar a lo largo de este libro: • Las redes de comunicaciones están presentes, hoy en día, en todos los sitios. • Tales redes son, en realidad, complejos «sistemas de sistemas», formados por muchos y muy diferentes dispositivos trabajando e interactuando entre sí, almacenando e intercambiando datos de todas clases, y usadas y gestionadas por seres humanos. • Todas estas máquinas, dispositivos, sistemas y subsistemas exhiben una serie de propiedades que hacen que no sean completamente predecibles cuando trabajan solas o en comunicación, como por ejemplo los bugs, algunos de los cuales se traducen en problemas de falta de fiabilidad y precisión, otros en falta de seguridad. • Tales problemas, unidos a una posible mala gestión técnica y la aceleración del trabajo del día a día, hacen que se hayan desarrollado, y lo sigan haciendo, todo tipo de ataques de obtención de información, de robo, sabotaje, denegación de servicio, etc. • Todas las organizaciones están, de una manera u otra, expuestas a ese tipo de ataques, pero pocas tienen en cuenta algo más que sistemas de prevención que, como se ve todos los días en la vida real, no son suficiente para parar tales ataques. Pocas tienen en cuenta temas como son los mecanismos de detección y respuesta. Para precisar más el problema, deben plantearse una serie de preguntas: • ¿Qué es lo que se quiere tener protegido? • ¿Contra quién se quiere proteger? • ¿Cómo se quiere proteger? • ¿Cuánto dinero se puede emplear en implantar y mantener el sistema de seguridad? que ayudarán a identificar muchos detalles necesarios, como los datos más importantes de la organización, el modelo de confianza en la organización,

35


qué tipo de ataques se puede sufrir más probablemente, y a un análisis de riesgos, que permita abordar el problema con mucha más información. Se ha visto, también, la importancia que tiene, hoy en día, una buena política de seguridad, verdadero eje director del proceso de seguridad, que debe ser modificable, implantable y resultado de una decisión consciente de la dirección, en un mundo en el que, raramente, se puede permitir el lujo de abordar el problema con el objetivo de que el ataque sea completamente imposible. Finalmente, hay que remarcar, otra vez, la idea de que la seguridad a aplicar a un sistema no es el resultado de una ecuación matemática, no se consigue comprando uno u otro producto, o ambos, ni contratando el mayor experto anti-hacker (o hacker) del mundo. Es un proceso complejo que debe apoyarse, obviamente, en las herramientas sofisticadas de seguridad de que se dispone actualmente, pero no deja de ser un proceso, que hay que vigilar, mantener y alimentar. En los siguientes temas se explorarán, ya con más detalle, muchos de estos aspectos descritos aquí, empezando por los elementos hardware y software habituales en las redes de comunicación, siguiendo con los métodos de ataque, tratando de normalizarlos, y viendo sus posibles defensas, para llegar a una definición más exhaustiva de una buena política de seguridad en el tema 6.

5. BIBLIOGRAFÍA CENTRO CRIPTOLÓGICO NACIONAL, accesible desde https://www.ccn.cni.es/ COMPUTER EMERGENCY RESPONSE TEAM, SEI, CARNEGIE MELLON, accesible desde http://www.cert.org/ HISPASEC, Una al día, servicio gratuito de noticias y análisis sobre seguridad en español, accesible en http://unaaldia.hispasec.com/ INTECO-CERT, Centro de respuesta a incidentes de seguridad TIC, Instituto Nacional de Tecnologías de la Comunicación, accesible en http://cert.inteco. es/cert/INTECOCERT/ SANS INSTITUTE, accesible desde http://www.sans.org/

36


6. PALABRAS CLAVE Bug, vulnerabilidad, hacker, ataques, política de seguridad, principios, soluciones.

7. EJERCICIOS RESUELTOS 1. Un bug es: a) Una consecuencia, imposible de evitar, del mal diseño de los compiladores actuales. b) Una herramienta de seguridad, diseñada para detectar problemas en las comunicaciones. c) Una propiedad, no deseada, de un sistema informático. d) Un tipo de virus informático. Solución: c. 2. Para evitar completamente cualquier tipo de ataque informático a los sistemas: a) Se debe comprar las mejores herramientas de seguridad disponibles en el mercado y formar a todo el personal en su uso. b) Se debe contratar al hacker de más prestigio de la comunidad informática y hacerle responsable de la seguridad de la organización. c) Se debe confiar en la suerte y hacer lo que se pueda. d) No hay manera de evitarlos completamente. Solución: d. 3. La política de seguridad de una organización debe tener alguna de las siguientes características: a) b) c) d)

Debe ser completamente secreta, excepto para un grupo de elite. Debe incluir mecanismos de respuesta, frente a posibles ataques. Debe conseguir que los usuarios no tengan que conocerla. Debe cubrir solo los aspectos de sistemas operativos de la organización.

Solución: b.

37


4. En el contexto de seguridad de las comunicaciones, un sistema de detección de intrusiones es: a) Un sistema que permite, en tiempo real, detectar determinados tipos de ataques y alertar sobre ellos, a la vez que, en algunos casos, puede pararlos. b) Un sistema cerrado de TV, que consigue detectar a cualquier ladrón informático que trate de penetrar en la organización. c) Un sistema de localización de posibles atacantes en Internet. d) Un sistema que permite conocer cualquier envío no deseado de información por las redes de comunicaciones. Solución: a. 5. Un sistema que proteja frente a accesos no autorizados al servidor Web de la organización en Internet, a la vez protege el sistema frente a ataques de denegación de servicio: a) Verdadero, pues estos sistemas llevan implícita tal defensa. b) Verdadero, pues estos sistemas tienen una seguridad completa. c) Falso, pues los ataques de denegación de servicio no necesitan tener un acceso autorizado al sistema que atacan. d) Falso, pues los ataques de denegación de servicio atacan directamente al sistema de autorización del sistema. Solución: c. 8. EJERCICIOS DE AUTOEVALUACIÓN 1. ¿Qué tipo de sistema es uno que permite mantener la privacidad de los mensajes enviados entre teléfonos móviles? a) b) c) d)

Un sistema antivirus. Un sistema de detección de intrusiones. Un sistema cortafuegos. Un sistema criptográfico.

2. ¿Cuál de las siguientes NO es una característica típica de cualquier política de seguridad? a) Debe ser implantable. b) Debe ser exhaustiva.

38


c) Debe cubrir todas las responsabilidades comerciales adecuadas. d) Debe ser actualizable. 3. En una aproximación razonable al problema de la seguridad, no se debe conectar ningún dispositivo a Internet hasta estar completamente seguro de que no sufrirá ataques a) b) c) d)

Falso, según esto ningún equipo estaría conectado a Internet. Verdadero, ésta es la aproximación que utiliza, por ejemplo, el ejército. Verdadero, por esta razón es tan complicada esta disciplina. Falso en parte, es cierto pero sólo para los dispositivos móviles.

4. ¿Cuál de las siguientes leyes no es importante para la puesta en marcha de una política de seguridad? a) La LOPD, Ley Orgánica de Protección de Datos. b) La LH, Ley Hipotecaria. c) La LSSICE, Ley de Servicio de Sistemas de Información y Comercio Electrónico. d) El ENS, Esquema Nacional de Seguridad. 5. ¿Cuál de los siguientes puede resultar más peligroso, desde un punto de vista general, para cualquier tipo de organización? a) b) c) d)

Un wannabe. Un empleado despedido sin privilegios previos. Un hacker que busca problemas de seguridad para avisar de ellos. Una organización cibercriminal.

39

Tema 2

La seguridad en los elementos físicos existentes en una red

1. Introducción, orientaciones para el estudio y objetivos 2. Los sistemas de cableado o inalámbricos 3. Repetidores, hubs y conmutadores (switches) 4. Encaminadores (routers) 5. Los servidores y otras máquinas 6. Conocimientos y competencias adquiridas 7. Bibliografía 8. Palabras clave 9. Ejercicios resueltos 10. Ejercicios de autoevaluación

1. INTRODUCCIÓN, ORIENTACIONES PARA EL ESTUDIO Y OBJETIVOS Todas las redes están compuestas por una serie de dispositivos físicos, máquinas, que tienen una mayor o menor capacidad de control mediante programación software, pero no dejan de ser máquinas, con una misión concreta en la red. Es radicalmente importante considerar sus posibles inseguridades, teniendo en cuenta que, en cierto sentido, son las piezas básicas del sistema. Esas máquinas, además, se comunican entre sí utilizando uno o varios medios de transmisión, habitualmente cables de una tecnología determinada, unos más susceptibles que otros a determinados problemas de seguridad. Hoy en día, además, cada vez son más las redes que, enteramente o en parte, se comunican mediante sistemas inalámbricos, que exhiben sus problemas particulares desde el punto de vista de la seguridad. Tanto los medios de transmisión como las distintas máquinas son susceptibles de ataques contra su seguridad, desde dos puntos de vista: • Ataques físicos a su seguridad, en los que se busca la destrucción parcial o total del dispositivo concreto y, como consecuencia, la inhabilitación, total o parcial, de la red en la que prestan sus servicios. • Ataques «lógicos» a su seguridad, en los que, buscando los mismos objetivos que los anteriores, no se dispone de un acceso físico y, como consecuencia, no se pueden realizar o, aun disponiendo de acceso físico, no es el método preferido para el ataque. Aunque no se vaya a desarrollarlos, hay que considerar los ataques físicos, es decir, los ataques en los que los dispositivos resultan dañados físicamente. Estos ataques son relativamente fáciles de evitar, disponiendo de

43


una buena política de seguridad física, que evite el acceso físico a tales sistemas por parte de personal no autorizado. Centrándose en los ataques lógicos, hay que entender cada una de las responsabilidades de los elementos hardware típicos de una red y cada una de sus posibles inseguridades, para considerarlas de cara a la política de seguridad. Así pues, primero hay que identificar los elementos que se tienen que considerar: • Canales de comunicación y cableados típicos: par trenzado, fibra óptica, sin olvidarse de considerar la comunicación inalámbrica. • Repetidores. • Hubs o concentradores. • Conmutadores. • Encaminadores. • Máquinas utilizadas por los usuarios, especialmente servidores. Para su estudio posterior ayudará el recordar los niveles OSI que deben implementar muchos de estos dispositivos. Se incluye la figura 2.1, como recordatorio de cada una de las funciones que realizan. No obstante, se examinan con más detalle en los siguientes apartados.

Figura 2.1. Niveles OSI de dispositivos en sistemas de comunicaciones.

44

LA SEGURIDAD EN LOS ELEMENTOS FÍSICOS EXISTENTES EN UNA RED

2. LOS SISTEMAS DE CABLEADO O INALÁMBRICOS En las comunicaciones digitales, una diferencia de potencial (o voltaje, si se prefiere) implica un 1 binario y otra (o la ausencia de alguna) marca el 0 binario. Como se sabe, este formato simple hace bastante resistente al «ruido» a las comunicaciones digitales, pero, a su vez, implica un cierto inconveniente, que consiste en la necesidad de transmitir 8 de tales elementos binarios para cada carácter. Cuando se considera un circuito eléctrico, como por ejemplo una red Ethernet que usa cables de par trenzado, el estado del voltaje está constantemente cambiando para transmitir información, lo que introduce la primera inseguridad: la interferencia electromagnética. La interferencia electromagnética es producida por circuitos de corriente alterna, los que existen en las comunicaciones analógicas y digitales. Si se pudiera «ver» a los electrones en el cable, se podría observar que, al cambiar el voltaje y fluir la corriente por el cable, los electrones tienden a «colocarse» sobre todo en la superficie del cable, mientras que el punto central del cable no mostraría «movimiento» electrónico. Si se incrementa la potencia, se empieza a radiar energía, con un ángulo de 90º al flujo de corriente. Lo verdaderamente importante es que esta radiación está en relación directa con la señal en el cable. Además, si se hace mayor la frecuencia o el voltaje, crece también la cantidad de energía radiada. Esta radiación electromagnética puede medirse y obtener, a partir de ella, la señal que está viajando por el cable. De hecho, hace muchos años que se dispone de dispositivos para tal medición, que se conectan alrededor del cable, para medir la señal que viaja por el conductor central. Una vez registrados los «pulsos» digitales, simplemente hay que convertirlos de formato binario a un formato más entendible. Una solución obvia, pero no por ello comúnmente desplegada, es usar cables apantallados, de los que se dispone también hace tiempo, pero que son más caros y presentan otros problemas de montaje que no son objeto de este libro. Estos cables no solo protegen la información que viaja a través del medio de transmisión frente a «escuchas» indeseadas, sino que además la protegen contra interferencias que puedan distorsionarla hasta el punto de inhabilitarla. Una forma alternativa de medir el peligro al que se está expuesto con este tipo de problemas es mirar la gran cantidad de dinero que gastan

45


los ejércitos en disponer de lo que, en su jerga, se denomina productos TEMPEST, que empiezan por cables apantallados, pero pueden ser conmutadores (o cualquier dispositivo) apantallados y que pueden llegar a habitaciones, o incluso edificios enteros, apantalladas. Otra solución, que se puede usar completa o parcialmente, dependiendo de la necesidad y del presupuesto es usar cable de fibra óptica que, además de permitir en muchas ocasiones una mayor velocidad de transmisión, es completamente inmune a las interferencias citadas, pues la transmisión se basa en señales de luz. Otro aspecto importante a tener en cuenta (al que se volverá en breve) es que en los segmentos de red en que no existan conmutadores y no se tenga un control muy exhaustivo de quién está conectado con un equipo al segmento, 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». Hasta hace unos años, no era fácil disponer de un «sniffer», pero, hoy en día, existes muchas herramientas gratuitas (diseñadas para gestión, no para ataques de red) que permiten capturar el tráfico que viaja por la red y aprovechar los conocimientos de IP de cada uno, para obtener, realmente, mucha información. Se puede también usar transmisión sin cable, mediante lasers o infrarrojos. El principal inconveniente es la facilidad de cortar el servicio, interrumpiendo la señal. Aunque se analizarán detalladamente los problemas específicos que supone el uso de comunicaciones y redes inalámbricas o «wireless» en el tema 18, conviene hacer una introducción de los problemas que presenta este tipo de tecnología de comunicación. Se puede definir una red inalámbrica (WLAN - Wireless LocalArea Network) como un sistema flexible de comunicación de datos, que suele implementarse como extensión, o alternativa a una red de área local (LAN - Local Area Network) tradicional, dentro de un edificio o entre varios edificios (modelo campus). Las WLANS usan señales electromagnéticas de radio para comunicar información de un punto a otro, sin necesidad de ningún cable.

46


Las ondas de radio son conocidas, en este marco, como portadoras de radio, ya que su única función es llevar energía al receptor remoto. Los datos que se transmiten se superponen sobre la portadora, lo que se conoce como modulación de la portadora por la información que se transmite. Esta operación hace que la señal de radio ocupe más de una frecuencia. Puede haber varias portadoras de radio en el mismo espacio a la vez, sin interferir entre sí, si se transmite en diferentes frecuencias de radio. Para extraer los datos, el receptor de radio selecciona una frecuencia de radio, a la vez que rechaza todo el resto de señales de radio, de otras frecuencias. En una configuración típica (como la de la figura 2.2) un dispositivo transmisor/receptor, denominado «punto de acceso», conecta los dispositivos inalámbricos a la red de cable. Tal dispositivo recibe, almacena y transmite los datos entre la WLAN y la red cableada. Un único punto de acceso puede soportar un grupo pequeño de usuarios y funcionar en un rango de entre 100 m y 1 km, dependiendo de la tecnología concreta. El punto de acceso (o la antena conectada a él) suele estar montada en alto. Los usuarios acceden a la WLAN a través de adaptadores WLAN específicos, normalmente implementados como tarjetas del dispositivo.

Figura 2.2. Red con dispositivos inalámbricos.

Las comunicaciones inalámbricas siguen el estándar 802.11 del Instituto de Ingenieros Eléctricos y Electrónicos (IEEE). Dicho estándar dispone en estos momentos de 4 versiones (a/b/g/n), cada una de las cuales deter-

47


mina la velocidad de transmisión, la técnica de modulación utilizada, así como la compatibilidad o no con otras versiones. En estos momentos, la velocidad de transmisión de las redes inalámbricas está entre los 11 Mbps y los 100 Mbps. Los problemas de seguridad de las WLAN están divididos en los problemas de los dispositivos físicos y en las señales de radio transmitidas. Es evidente que, 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 seguridad 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. Como se verá en los temas sobre criptografía, una cosa es disponer de una herramienta adecuada y otra muy distinta es usarla correctamente. Baste decir, solo a modo de idea, que muchas redes WLAN han sido atacadas con éxito (esto quiere decir que se ha obtenido toda la información que fluía por ellas) porque o bien la criptografía que se podía usar no se usaba (caso muy habitual) o bien estaba configurada con un algoritmo criptográfico débil, una selección de clave pobre, un cambio de clave muy infrecuente o una combinación de todos estos factores. 3. REPETIDORES, HUBS Y CONMUTADORES (O SWITCHES) Hay que recordar (figura 2.1) que un repetidor no es más que un amplificador de la señal, con dos puertos. Solo implementa funciones del nivel 1 de OSI. Se usan, simplemente, para extender la distancia máxima para la que un cable funciona correctamente. El repetidor recibe la señal en uno de sus puertos, la amplifica (si lleva «ruido» también) y la transmite por el otro puerto. Se puede pensar en romperlo, pero es difícilmente «atacable», por no tener nada realmente configurable. Los hubs (o concentradores) son, en esencia, repetidores multipuerto que soportan cables de par trenzado en una topología de 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 en el nivel eléctrico, es decir, otra vez el nivel 1 de OSI. El funcionamiento de los hubs los hace especialmente susceptibles a los ataques de tipo monitorización mediante «sniffers». Un atacante conectado a cualquiera de los puertos del hub reci-

48


birá copia de todos los paquetes que este reciba desde cualquiera de las estaciones conectadas al mismo. Hasta hace pocos años, se disponía de puentes (o «bridges») como segmentadores de datos. No se va a hablar de ellos aquí pues, prácticamente, han desaparecido, siendo sustituidos por dispositivos, combinación de hub y puente, que se denominan conmutadores (switches). Comparados con los anteriores, los conmutadores son muy «inteligentes». Implementan (figura 2.1) hasta el nivel 2 de OSI, por lo menos, aunque hay que señalar que existen también los llamados «conmutadores de nivel 3», cuyas funcionalidades coinciden con las de los encaminadores que se verán en el siguiente epígrafe. Esto quiere decir que, en sus funciones básicas, 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. En concreto, un mensaje que vaya a una estación concreta, viajará por el cable que una el conmutador y la citada estación, y solo por ese cable, evitando, así, los ataques de tipo monitorización con sniffers, citados en el apartado anterior. Otra técnica típica de los conmutadores, y que colabora para una mayor seguridad, 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, gracias al software de configuración, residente en el sistema operativo 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, a la vez que permite organizar mejor las máquinas por tareas o por departamentos. Desafortunadamente, siempre que hay más posibilidades de configuración, hay más posibilidades de ataques. Hay que recordar del tema 1 que, si hay un sistema operativo, habrá bugs, algunos de ellos harán posible atacar el conmutador y, como consecuencia, la red. ¿Cómo? Hay 2 métodos para acceder al conmutador para administrarlo: • A través de la consola, una conexión local y directa al conmutador. • Remotamente, ya sea por telnet, ssh o http.

49


De manera general, un conmutador tiene un sistema operativo y un juego de cuentas de usuario, de las cuales una de ellas se usa como la cuenta de administración. Si se accede al conmutador mediante la consola, únicamente hay que conocer la información de la contraseña asociada a esa cuenta. Desde el punto de vista de seguridad, hay que tener el acceso físico al conmutador (o, al menos, a los más importantes) suficientemente asegurado y la contraseña de acceso debe de ser distinta de la que proporcione, por defecto, el proveedor del conmutador. Tal contraseña, además, habrá que cambiarla con una cierta periodicidad y no publicarla. Todos los detalles de cómo hacerlo deberían de formar parte de la política de seguridad. La otra forma de acceder al conmutador, suponiendo que se conoce la contraseña de la cuenta, es basándose en un protocolo de una aplicación IP. Esto tiene una consecuencia inmediata que se debe resaltar: un conmutador debe implementar al menos el nivel 2 de OSI, pero, sólo con el fin de poder gestionarlo de manera remota, de hecho implementa todos los niveles OSI, tiene una dirección IP y es administrable mediante IP. Habitualmente, los conmutadores tienen, además, unas listas de direcciones IP desde las cuales está permitido acceder al conmutador, por ejemplo los conmutadores Catalyst de Cisco Systems. Tal lista, obviamente, debe estar cuidadosamente configurada con las direcciones IP de los equipos de uso habitual de los posibles administradores del conmutador, pero que lo deba estar no quiere decir que lo esté. Al no ser obligatoria tal configuración, en prácticamente todos los modelos se puede dejar la lista vacía, significando que se puede acceder desde cualquier dirección IP, con el riesgo que esto entraña. Una vez se tiene un equipo desde el cual acceder, este se puede acceder mediante telnet, siempre que la dirección IP desde la cual se haga esté en la lista de direcciones permitidas. El uso de telnet tiene posibles efectos desagradables. Como se repetirá en el tema 3, telnet es una aplicación que no encripta el nombre de usuario ni la contraseña que se usa para el acceso. Como consecuencia, cualquiera con un acceso «promiscuo» y un analizador de protocolos podría obtener tal información y usarla posteriormente para conectarse, o intentarlo, al conmutador. En los modelos más modernos, se va imponiendo la sustitución del protocolo telnet por el protocolo ssh (de «secureshell»). Su uso desde el punto

50


de vista del administrador es idéntico al de telnet, pero todo el tráfico resulta encriptado, haciendo mucho más segura la comunicación. Otra forma de acceso remoto para gestión a un conmutador, cada vez más empleado, es mediante http. Su funcionamiento es sencillo de entender: se implementa un servidor http en el conmutador, que, a su vez, da acceso a una aplicación típica web, que es la que sirve para administrar el conmutador remotamente. Basta con introducir en un navegador web la URL (Uniform Resource Locator) que identifica al conmutador, normalmente su dirección IP, por ejemplo, http://dirección-IP-conmutador/ para obtener la ventana con la petición de identificación. Si uno conoce, como antes, el nombre de usuario y la contraseña, podrá acceder a la configuración del conmutador. Este procedimiento se puede refinar, usando https, una variación del protocolo http, que trabaja con SSL (Secure Socket Layer), protocolo criptográfico (del que se hablará en el tema 16) que, bien configurado, permite exigir un certificado digital correspondiente al equipo desde el cual se realiza la conexión. Además, se puede establecer que la identificación y autenticación (aspectos de seguridad de los que se hablará mucho más en otros temas del libro) no se haga en el conmutador, es decir, se puede pedir que la prueba de que uno es quien dice ser (en términos de cuenta de usuario) se realice en un sistema distinto, que trabaje con un protocolo AAA (Authentication, Authorization, Accounting), como RADIUS o TACACS/+. No hay que asustarse por la gran cantidad de términos, muchos de ellos probablemente desconocidos por el lector, que se han mencionado. Muchos de estos términos se aclaran en otras secciones del libro. Su aparición aquí es para resaltar lo importante que se ha vuelto el asegurar el correcto acceso a los conmutadores en una red, entre otras cosas porque son elementos presentes en prácticamente cualquier red que se plantee. En un acceso permitido, o sea, siendo quien se debe ser, ¿qué pasos de seguridad hay que cumplir para acceder? 1. Hay que conocer el nombre y contraseña correctos. 2. Hay que estar usando una dirección IP correcta.

51


3. Como consecuencia, para SSL, hay que tener un certificado digital correcto. Como se verá en el tema 16, esto tiene muchas más connotaciones de gestión y de seguridad, pero, por ahora, se supone que se dispone de uno correcto. 4. Hay que conocer la dirección IP correcta del conmutador para abrir la sesión Web. 5. Una vez en la ventana, se teclea el nombre y la contraseña, que será contrastado contra un servidor de autenticación, usando, por ejemplo, el protocolo RADIUS. 6. Ya se está dentro. Ahora, hay que saber cómo configurarlo. Parece difícil colarse… pero, hay que recordar: cuanto más complejo es un sistema, más difícil es asegurarlo. Revisando la anterior lista punto a punto otra vez: 1. ¿Se ha modificado periódicamente la contraseña? 2. ¿Hay una lista de direcciones IP autorizadas bien configurada, o está vacía? 3. ¿La versión de SSL no tiene «agujeros» de seguridad, como por ejemplo los descritos en http://unaaldia.hispasec.com/2013/02/multiplesvulnerabilidades-en-la.html? 4. ¿Hay una sola o varias direcciones IP en el conmutador? 5. ¿Está activo el servidor AAA?, si no, ¿se dispone de un servidor alternativo de «backup»?, o ¿se está preparado para tener que acceder solo en local? 6. Éste no es un punto menor. Con el auge de las herramientas gráficas, cada vez es más fácil configurar mal un conmutador, si no se conoce bien el entorno, porque nadie se lo ha enseñado. Muchos problemas de seguridad tienen su causa en el desconocimiento, no mal intencionado, que deja desconfigurado, o mal configurado, el sistema operativo del conmutador. Y, por último, ¿se ha tenido en cuenta, en todos los puntos de seguridad, los ataques que, para tener éxito, no necesitan de un acceso al conmutador? Hay que recordar del tema 1 los ataques de denegación de servicio

52


(o ataques DOS). Alguien podría pensar que siendo tan pequeño el sistema operativo de un conmutador, diseñado solo para gestionarlo, no va a tener bugs que permitan tales ataques… pues estaría equivocado. Tales ataques existen, se dan y en muchos modelos de muchos fabricantes. Como muestra, un botón, aparecido como «Security Advisory» de Cisco, en septiembre de 2012: (http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/ cisco-sa-20120926-ecc): Vulnerabilidad de Denegación de servicio en switches Cisco Catalyst Serie 4500E Los switches Cisco Catalyst serie 4500E con el motor de supervisión 7L-E presentan una vulnerabilidad ante ataques de tipo denegación de servicio al procesar paquetes especialmente diseñados que causan el reinicio del dispositivo. Cisco ha publicado una nueva actualización de software que corrige esta vulnerabilidad.

Es decir, se puede hacer «caer», repetidamente, un conmutador y, como consecuencia, dejarlo fuera de servicio, con todo el potencial de caída de la red correspondiente, desde una situación remota, sin más que conocer la versión del conmutador y su dirección IP. Apurando, para probar si la versión es una de las buscadas, se puede, simplemente, enviar los paquetes maliciosos al switch y esperar. Resumiendo, los dispositivos físicos de la red, de nivel bajo en la arquitectura OSI, deben también tenerse en cuenta en la política de seguridad, especialmente los conmutadores. Hay que pensar qué mecanismos de seguridad se imponen para ellos, para el acceso a los mismos y para su gestión, incluyendo la auditoria de posibles vulnerabilidades de su sistema operativo. 4. ENCAMINADORES Los encaminadores (o routers) son dispositivos de red que no solo 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 la arquitectura OSI (figu-

53


ra 2.1), pero, al igual que los conmutadores, suelen implementarlos todos y, así, permitir todos los medios de acceso a su configuración explicados para los conmutadores. Difieren de los conmutadores, fundamentalmente, en que 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 hacen sobre las tramas al nivel de enlace de datos (nivel de direcciones MAC), y por otro lado, ambos son idealmente transparentes a las estaciones finales que comunican. Normalmente, las estaciones finales tienen definido el encaminador al que deben dirigirse para solicitar los servicios de encaminamiento. Su funcionamiento se basa en la utilización de un esquema de direccionamiento jerárquico y lógico (definido por el administrador, siguiendo las normas de una arquitectura particular, por ejemplo IP, por contraste al direccionamiento físico del nivel 2, por ejemplo, las direcciones MAC de Ethernet), que distingue la dirección de un dispositivo dentro de la red y la dirección de la red. Con ese conocimiento, el encaminador es capaz de construir «tablas de rutas», que le ayudarán a decidir por qué camino envía el mensaje. Para ello, deben incorporar protocolos de nivel de red y, por lo tanto, se trata de elementos dependientes del protocolo de la red. La actualización de estas tablas de rutas se lleva a cabo en función del tipo de encaminador, los cuales pueden ser estáticos, dinámicos o los que permiten los dos tipos de actualización a la vez. En el primer caso, dicha actualización la realiza el administrador de la red. En el segundo, son los protocolos de encaminamiento quienes se encargan de la notificación automática del cambio o avería mediante mensajes de difusión entre los encaminadores. Obviamente, casi el 90% de los encaminadores son IP, es decir, sus mensajes son mensajes de aplicaciones y protocolos de la familia IP. Sus protocolos de encaminamiento más típicos son RIP (Routing Internet Protocol) versiones 1 y 2, OSPF (Open Shortest Path First), IGRP (Internet Gateway Routing Protocol), EIGRP (Enhanced IGRP), estos dos últimos de Cisco Systems, BGP (Border Gateway Protocol) y otros. Un encaminador es susceptible de sufrir distintos tipos de ataques: 1. Ataques de denegación de servicio, sin necesidad de acceso. Las técnicas usadas son idénticas a las comentadas para los conmutadores en el apartado anterior y un buen ejemplo, una vez más de Cisco,

54


puede verse en la siguiente url: http://tools.cisco.com/security/center/ content/CiscoSecurityAdvisory/cisco-sa-20130410-asr1000. 2. Ataques de acceso para modificación de información, casi siempre de las tablas de rutas. Suelen realizarse mediante los métodos citados en el caso de conmutadores, como telnet, ssh, AAA, etc. 3. Ataques basados en la falta de autenticación. Se verán con más detalle en el tema 4, pero se tratan de mensajes enviados en cualquiera de los protocolos citados, con una información de rutas errónea y que, al no «preguntar» el encaminador 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 2 encaminadores, explicándoles (mediante rutas falsas) que la ruta más corta entre ellos, pasa por el segmento de red al que está conectado el atacante, de esta manera podrá «sniffar» la información con mayor facilidad. Al igual que en el caso de los conmutadores, las soluciones a estos problemas suelen ser claras, pero no fácilmente implementables. Es claro, no obstante, que habrá que tenerlos en cuenta a la hora de desarrollar e implementar la política de seguridad. 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, pudiendo denominarlas estaciones de trabajo para no tener que hacer referencia a un sistema operativo concreto (Windows, UNIX o LINUX, Mac OS, etc.). • En los últimos años hemos visto la proliferación de dispositivos móviles como teléfonos inteligentes (smartphones) o tabletas (tablets). Este tipo de terminales son también máquinas de uso final de usuarios pero con la peculiaridad en cuanto a su movilidad y sus sistemas operativos propios (Android, iOS, Windows Phone, Firefox OS…). • Máquinas que ofrecen servicios, o servidores, que suelen tener como sistema operativo alguna modalidad de UNIX, LINUX o Windows

55


Server, aunque hay un buen número de servidores con otros sistemas, como Netware u OpenVMS. Como se verá en temas posteriores, una buena política de seguridad debe hacer responsable a cada usuario de buena parte de la seguridad de su estación de trabajo, especialmente de: • la seguridad de su cuenta de usuario y contraseña, pues, a través de ellas, se tiene acceso a datos y aplicaciones compartidas, correo, etc.; • la seguridad de sus ficheros y directorios personales. Se supone que nadie más que el propio usuario debe estar interesado en ellos. Para ello, deberá disponer de un buen antivirus y de un buen sistema de ficheros. Los nuevos dispositivos móviles (teléfonos inteligentes y tabletas) presentan, además de los retos en cuanto a seguridad del resto de estaciones de trabajo, retos propios que deben ser tenidos en cuenta. • En el caso de dispositivos móviles el usuario será responsable además de su seguridad física cuando dicho terminal se traslade fuera de las instalaciones de la organización evitando así su robo o extravío. El hecho de que los usuarios lleven siempre en el bolsillo estos dispositivos ha hecho que el perímetro a proteger se haya vuelto «difuso» y por tanto mucho más difícil de controlar por los responsables de seguridad de las organizaciones. • Hasta hace unos años los teléfonos móviles eran terminales básicos con software muy básico y poca funcionalidad. En estos momentos la nueva generación de teléfonos inteligentes y tabletas presentan sistemas operativos con capacidad IP completa, conectados permanentemente a Internet y capaces de prestar innumerables servicios. Sus sistemas operativos son tan complejos como las de cualquier estación de trabajo tradicional y presentarán los mismos retos de seguridad que veremos en temas posteriores. En cuanto a la seguridad de los servidores, se debe tener en cuenta varias cosas: • Si son servidores de datos, hay que tener en cuenta, como se verá en el tema 12, los diseños redundantes y otros aspectos que garanticen suficientemente la disponibilidad de tales datos.

56


• Si son servidores de autenticación, es decir, de los que permiten o no el acceso a una serie de máquinas a los usuarios, por ejemplo un servidor Solaris con NIS+ (Network Information Services) o un servidor Windows Server que sea un Controlador de Dominio, hay que tener en cuenta la correcta configuración de su propio sistema de seguridad, de forma que esté bien configurado con un sistema de ficheros seguro, como el NTFS de Windows o el AdvFS de Compaq Tru64 UNIX. • Si son servidores de aplicaciones, como un servidor de correo electrónico o un servidor DNS, un servidor www, ftp o de cualquier otra aplicación IP típica, hay que tener especialmente configuradas tales aplicaciones. Esto se verá en más detalle más adelante, cuando se estudie por un lado las particularidades de IP y, por otro, los ataques típicos a cada aplicación. No obstante, hay una serie de consideraciones generales que valen para todos: • Los servidores deben estar ubicados físicamente en lugar seguro, tanto más seguro cuanto más «delicado» sea su contenido. Esto es debido a que, como se verá, el acceso físico suele ayudar mucho para cualquier tipo de ataque. • Su ubicación topológica en la red debería cumplir el mismo principio. Debe estar en una parte de la red especialmente asegurada y, a poder ser, conectado a un puerto individual de un conmutador, para evitar ataques de monitorización con analizadores de protocolos. • Las aplicaciones de los servidores son programas. Es decir, como se verá en el tema siguiente, tienen vulnerabilidades que hay que tener en cuenta y cuyo número crece, no es siempre el mismo. Hay que habilitar en la política de seguridad los mecanismos para auditarlos correctamente. En el siguiente tema se profundizará un poco más en los retos de seguridad que presentan sistemas operativos, protocolos y aplicaciones.

57


6. CONOCIMIENTOS Y COMPETENCIAS ADQUIRIDAS A lo largo de este tema se han presentado los principales problemas de seguridad que presentan los elementos físicos presentes en cualquier red. • En cualquier sistema de comunicaciones existen tres piezas clave: los emisores, los receptores y el medio de comunicación. • A lo largo de este tema se ha tratado de los componentes hardware que deben ser tenidos en cuenta en cualquier proceso de seguridad. • Dentro de cualquier red hay una serie de dispositivos, como puede ser el cableado o los hubs, que son claramente hardware. • Se ha visto que no todos los cables ofrecen la misma seguridad, que siempre será más seguro trabajar con par trenzado apantallado o con fibra óptica. • Se ha hecho una breve introducción a la comunicación inalámbrica y se ha visto que, en este caso, en el medio lo importante es la capacidad de encriptar correctamente. • Se ha visto que los hubs y repetidores son suficientemente «tontos» como para no preocuparse mucho de ellos. • Sin embargo, se han descrito muchos de los posibles problemas que se pueden tener (algunos muy graves) si se piensa que no hay que dedicar un buen espacio (y tiempo) en la política de seguridad a la configuración correcta y mantenimiento de los conmutadores y de los encaminadores. Es esencial elegir correctamente cuáles se van a usar, cómo y quién los va a configurar, cómo será su mantenimiento y su auditoria. • Se ha terminado hablando de las máquinas de usuario o servidores. Ellas son la razón última de casi todo lo que se hace en seguridad de redes. Finalmente, son ellas las emisoras y receptoras, sean estaciones de trabajo o servidores, pero no hay que olvidar que, en realidad, el emisor y el receptor últimos son procesos de cada uno de los sistemas operativos. • Se han introducido los retos de seguridad propios de los terminales móviles como son teléfonos inteligentes y tabletas, los cuales incrementan el perímetro de seguridad de la organización y lo hacen «difuso».

58


En el tema siguiente se profundizará en cómo se comunican aquellos procesos, que son los que en última instancia realizan la comunicación, en cada sistema operativo y mediante qué protocolos de comunicación. 7. BIBLIOGRAFÍA GARFINKEL, S.; SPAFFORD, G.; SCHWARTZ, A. (2003): Practical UNIX and Internet Security. 3.ª edicion, O’Reilly Media. OLIVA, N.; CASTRO M.; LOSADA, P.; DÍAZ, G. (2006): Sistemas de cableado estructurado. Editorial RA-MA. 8. PALABRAS CLAVE 802.11, AAA, concentrador, encaminador, conmutador, hub, LAN, OSI, par trenzado, puente, punto acceso, router, sniffer, switch, VLAN, WLAN. 9. EJERCICIOS RESUELTOS 1. Los encaminadores son máquinas más seguras que los hubs por: a) Porque implementan hasta el nivel 3 de la arquitectura OSI, y los hubs solo hasta el nivel 1. b) No son necesariamente más seguros. Depende de su configuración concreta. c) Tiene mecanismos físicos de seguridad adicionales. d) Son más seguros los hubs, al no tener ninguna configuración especial que realizar en ellos. Solución: d. 2. ¿Cuáles de las siguientes características son típicas de los productos TEMPEST? a) Protegen frente a desastres naturales, como tempestades. b) Son productos que están apantallados frente a la interferencia electromagnética. c) Los hay desde un simple cable apantallado hasta un edificio apantallado. d) No ofrecen mucha más seguridad pero, en cambio, son muy baratos. Solución: b. 59


3. Las VLAN (redes de área local virtuales) son: a) Redes locales montadas en secreto, basándose en técnicas criptográficas secretas. b) Grupos de ordenadores, relacionados lógicamente entre sí, por un número de grupo (o de VLAN) y configurados por el administrador de un conmutador. c) Grupos de ordenadores, en distintas redes IP, en distintas situaciones geográficas, dependientes de distintos encaminadores y conmutadores. d) Un nuevo desarrollo de seguridad, probado únicamente como piloto, en el MIT. Solución: b. 4. Para la gestión remota de un encaminador o de un conmutador siempre es más seguro: a) Acceder a él mediante ssh o telnet, que da, además, las mejores prestaciones de velocidad. b) Acceder a él mediante http, al poder usar la criptografía SSL. c) Depende, en cada caso de cómo esté configurado. No hay una solución claramente más segura que otra. d) No puede accederse remotamente. Solución: c. 5. Para una mayor seguridad se deben usar sistemas operativos en las máquinas con el siguiente criterio: a) Todos los servidores deben ser LINUX. Es el más probado con diferencia. b) Todas las máquinas deben ser Windows, excepto los servidores que deben ser UNIX, a poder ser de un fabricante con soporte de su producto. c) No hay un criterio único. La decisión dependerá de muchos factores, entre otros la estabilidad, las aplicaciones que se vayan a usar y los criterios de autenticación de usuarios. d) Todos los servicios deben ser mainframes como MVS, sistemas de IBM lo suficientemente desconocidos como para no temer ataques sobre él. Solución: c.

60


10. EJERCICIOS DE AUTOEVALUACIÓN 1. Los conmutadores o switches son: a) Dispositivos de red que permiten determinar la ruta que debe seguir un mensaje entre diferentes segmentos de red. b) Dispositivos de red que reciben la señal por uno de sus puertos, la amplifica y la transmite por el resto de puertos. c) Son dispositivos de red cuya funcionalidad es la de un concentrador (hub) y un puente. d) Dispositivos de red que solo implementan funciones de nivel 1 del modelo OSI. 2. Indique cuál de las siguientes afirmaciones es correcta: a) Un atacante conectado a un switch podrá capturar todo el tráfico generado por las máquinas conectadas al mismo gracias a herramientas de tipo «sniffer». b) Un atacante conectado a un hub podrá capturar todo el tráfico generado por las máquinas conectadas al mismo gracias a herramientas de tipo «sniffer». c) Un atacante conectado a un enrutador podrá capturar todo el tráfico generado por las máquinas conectadas al mismo gracias a herramientas de tipo «sniffer». d) Todas las anteriores son correctas. 3. Indique cuál de las siguientes afirmaciones es correcta: a) A la hora de elegir el tipo de red a implantar habrá que elegir entre redes cableadas y redes inalámbricas, pudiéndose implantar una sola de ellas. b) Hay que evitar el uso de redes inalámbricas siempre que sea posible ya que el su tráfico esta accesible a todo el mundo y no puede ser protegido de ninguna manera. c) Los puntos de acceso son necesariamente enrutadores a los que se les ha habilitado de conexión inalámbrica. d) Un punto de acceso es un elemento de red que permite conectar los elementos inalámbricos a una red física. 4. Indique cuál de las siguientes afirmaciones es correcta: a) Los encaminadores son dispositivos de red que implementan al menos los niveles 1,2 y 3 del modelo OSI.

61


b) Los encaminadores actúan sobre los paquetes a nivel de red, es decir, a nivel de direcciones IP. c) RIP, OSPF y BGP son algunos de los protocolos de encaminamiento utilizados por los encaminadores para determinar las rutas de entrega óptima de los paquetes. d) Todas las afirmaciones anteriores son correctas. 5. Indique cuál de las siguientes afirmaciones es correcta: a) Los dispositivos móviles, como teléfonos inteligentes y tabletas, son simples dispositivos de usuario con los mismos problemas que los dispositivos fijos. b) Los servidores no necesitan medidas o consideraciones de seguridad adicionales que no se deban tener en cuenta también para los terminales de usuario. c) Los dispositivos móviles, como teléfonos inteligentes y tabletas, son dispositivos de usuario que presentan los mismos problemas que los dispositivos «fijos» y a su vez presentan problemas propios derivados de su movilidad. d) Todas las anteriores son correctas.

62

Tema 3

La seguridad en los elementos software existentes en una red

1. Introducción, orientaciones para el estudio y objetivos 2. Los sistemas operativos y las aplicaciones 3. Los protocolos y aplicaciones IP 4. Mejoras de seguridad con IPv6 5. Criterios de evaluación de seguridad 6. Conocimientos y competencias adquiridas 7. Bibliografía 8. Palabras clave 9. Ejercicios resueltos 10. Ejercicios de autoevaluación

1. INTRODUCCIÓN, ORIENTACIONES PARA EL ESTUDIO Y OBJETIVOS En este tema se va a tratar de un asunto que tiene ya unos cuantos años de historia y que, con el paso de los años, no ha hecho más que complicarse. Lo que se suele llamar seguridad del software incluye aspectos tan diversos como el control autorizado (o no) 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... Además, en la era de Internet, hablar de la seguridad de sistemas y de la seguridad de la red, separadamente, no tiene mucho sentido. A pesar de ello, y por tratar de ser más didácticos, por ir por partes, así se va a hacer. La mayor parte de las primeras investigaciones dedicadas a la seguridad del software tenían que ver con el acceso privado a sistemas compartidos: si una buena cantidad de usuarios comparten un sistema (cada uno de ellos con una serie de permisos para hacer ciertas cosas y ver ciertos datos), ¿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. Por ejemplo: • ¿Cómo se puede mantener una base de datos (cuanto más grande más difícil) 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?

65


Para poder hablar de control de acceso que es, en el fondo, de lo que se está hablando continuamente, 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, una comunicación entre procesos, por ejemplo, un «plug-in». Objetos típicos podrían ser, también, un registro de una base de datos, una impresora, una zona de la memoria del sistema. Dependiendo de la situación, el mismo programa puede ser un sujeto, en una determinada relación de control de acceso, y un objeto en otra. Se puede definir, además, el control de acceso de 2 maneras distintas: • ¿Qué puede hacer cada uno de los diferentes sujetos? • ¿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. Sin embargo, los sistemas operativos más modernos se definen más bien como los que ofrecen aplicaciones, servicios a usuarios finales, como el acceso a una gran base de datos que suele tener sus propios mecanismos de control de acceso. Además, el acceso no es nunca del tipo «todo o nada». Por ejemplo, UNIX/LINUX tiene tres tipos de permiso de acceso diferente: read, write y execute, que son independientes entre sí. Si solo se tiene permiso de lectura sobre un fichero, solo se podrá leer el fichero, pero no modificarlo. Esto se verá con más detalle más adelante. Los mismos conceptos de seguridad, de los que se habla para sistemas, valen para las aplicaciones. En este caso, además, se ha de tener en cuenta la modularidad del software de muchas de las aplicaciones, que complica, más aún, la búsqueda de seguridad en ellas. Por otro lado, se suele definir cualquier protocolo (incluidos todos los de la suite de protocolos de IP, popularmente conocidos como TCP/IP) 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.

66

LA SEGURIDAD EN LOS ELEMENTOS SOFTWARE EXISTENTES EN UNA RED

Esto no es más que otro tipo de aplicaciones, eso sí, con una responsabilidad especial en todas las redes, pues son los que transmiten todos los mensajes entre equipos. Hoy en día puede uno fijarse especialmente en los protocolos de la citada familia IP, que, además de ser los que hacen que Internet sea un hecho, son responsables de más del 90% del tráfico de mensajes general de todas las redes. Desafortunadamente, tal familia no fue creada teniendo muy en cuenta la seguridad. La razón es sencilla de entender: el objetivo de las redes para las que iban a funcionar los protocolos de la familia IP era el intercambio de información académica y científica, no el comercio electrónico. No obstante, se ha mejorado bastante y, como se verá, entre lo que se ha mejorado de la versión actualmente más implantada (IPv4) y lo que se ha portado a ésta desde la nueva versión (IPv6), se puede decir que se dispone de herramientas para configurar una red bastante segura, a la vez que funcional y útil, con IP. Finalmente, hay que conocer qué criterios comunes, más o menos estándar, se pueden aplicar para tener una mayor confianza o no de la seguridad de un sistema operativo, aplicación o producto software en general. Se describirán los criterios tradicionales, no demasiado útiles hoy en día, del Department of Defense (DoD) de los EE.UU., conocidos como el TCSEC, pero, también, se va a describir otro conjunto de criterios, basados en los anteriores, pero mucho más prácticos, y consensuados internacionalmente, conocidos como los «Common Criteria», un estándar de la ISO, el ISO/IEC 15408. 2. LOS SISTEMAS OPERATIVOS Y LAS APLICACIONES Primero hay que centrarse en los sistemas operativos más usados. Aunque se podría decir que entre los distintos sistemas Windows, los distintos sistemas UNIX (incluyendo todas las versiones del LINUX) y MacOS se estaría hablando de más del 95% de ellos, no hay que desdeñar otros sistemas operativos como OpenVMS, Novell Netware o sistemas mainframe. Los sistemas operativos anteriores se refieren a terminales fijos o dispositivos portátiles tradicionales (ordenadores portátiles). En el caso de teléfonos inteligentes (smartphones) y tabletas (tablets) los dos sistemas operativos principales son iOS y Android.

67


Todos ellos comparten, con pequeñas diferencias, una estructura interna parecida. Todos ellos contienen: • Un kernel (o núcleo) es el corazón del sistema operativo. Es un programa especial, que se carga en el ordenador, al arrancar éste. Suele controlar todas las operaciones de entrada y salida, permite que muchos programas funcionen a la vez y divide y administra los recursos (tiempo de CPU y memoria) entre todos ellos. En muchos casos, incluye el sistema de ficheros, que, a su vez, controla cómo se almacenan los ficheros y directorios en los discos duros del sistema. En los sistemas modernos, hay una serie de controladores de dispositivos que se pueden cargar y descargar, dinámicamente, en el kernel. • Una serie de programas de utilidad utilizados por el propio kernel o por los usuarios. Unos pueden ser pequeños, como, por ejemplo el comando /bin/ls en UNIX, que permite ver los ficheros almacenados en un directorio, y otros grandes, como las shells de UNIX (por ejemplo /bin/sh o /bin/csh) o los sistemas de «ventanas» de UNIX o de Windows. • 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. Desde el punto de vista de la seguridad, cualquiera de estas «partes» del sistema operativo interactúa con una cuarta entidad, que es el subsistema de seguridad, que determina cómo funciona el sistema con respecto a los usuarios y a la administración del sistema. Habitualmente, todos estos subsistemas utilizan una serie de conceptos: • Monitor de referencia. La parte del software que controla todos los accesos a objetos, por parte de sujetos. Por ejemplo, cuando un proceso hace una llamada para acceder a un documento, el monitor de referencia interrumpe para comprobar si la llamada está prohibida o se permite. • «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.

68


• Kernel seguro. Toda parte del kernel que implemente el concepto de monitor de referencia. La implementación de todo esto en un sistema real es difícil. No hay que olvidarse de que el sistema, además de seguro, debe ser funcional. Esto ha hecho, especialmente en los últimos años, que los kernels dejen de tener una propiedad que viene muy bien para implementar lo anterior: la simplicidad. Como dice Bruce Schneier en su libro Secrets and Lies (bibliografía), … los sistemas operativos modernos están infectados con una enfermedad conocida como hinchazón del kernel.

Hay una gran cantidad de código, que podría estar fuera del kernel, que está dentro del mismo. Siendo prácticos, hay que reconocer que hay posibles problemas estructurales, pero hay que dedicarse a gestionar bien lo que se puede. Dennis Ritchie, creador del lenguaje C y co-creador, junto con Ken Thompson, del primer sistema UNIX, escribió, hace unos cuantos años: UNIX no se diseñó para que fuera especialmente seguro. Se diseñó con las características necesarias para hacer posible una buena seguridad.

Esta frase valdría para cualquiera de los sistemas operativos de servidor con los que se trabaja habitualmente: UNIX/LINUX, Windows Server, OpenVMS, etc. En el caso de las estaciones, la situación es la misma, todos los sistemas citados tienen, hoy en día, una versión típica de usuario y una o varias de servidor. Es decir, en el caso de los sistemas operativos se trata, también, de que exhiban una buena administración. Como se verá en el tema 6, esto suele significar, al menos, 3 cosas: • Tratar de trabajar con sistemas operativos que tengan una certificación de seguridad, lo más comúnmente aceptada. • Entender la certificación de seguridad. Las personas responsables de los sistemas, especialmente de los servidores, 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 particular.

69


• Como consecuencia, aplicar los puntos concretos relacionados con lo anterior a los sistemas particulares. Las certificaciones (que se tratarán más adelante) y la política de seguridad no pueden conseguir, por sí solas, que se disponga de sistemas fiables. 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, a poder ser, un sistema de ficheros que permita el control de acceso más granular posible. Por ejemplo, además de control de acceso por grupos, control de acceso por usuario, como las ACLs (listas de control de acceso) en algunos sistemas UNIX, como Tru64 UNIX o AIX. En el otro extremo, el sistema de ficheros FAT de Windows no dispone de ningún control de acceso. • Integridad de los ficheros. Hay que intentar, y ya se verá que hay medios para ello, asegurar que todos los ficheros, o, al menos, los más importantes desde el punto de vista de la política de seguridad, no sufran cambios que no sean deseados. • Una buena gestión de los ficheros de log (auditoria). Deben estar bien configurados, bien controlados y, sobre todo, hay que leerlos, automáticamente (mediante herramientas de análisis) o «a mano», pero, si se dispone de logs, hay que hacerles caso. • Hay que estar bien preparados contra las «amenazas» previsibles: «puertas traseras», bombas lógicas, virus, «gusanos» (worms), caballos de Troya y herramientas de seguridad usadas malintencionadamente. Cuando se hable de ataques (tema 4) y defensas (casi el resto del libro), se analizarán con detalle. Hay que tener una buena política de seguridad física. No hay que olvidar que muchos ataques suceden más fácilmente con un acceso físico a la máquina.

70


Lo dicho hasta ahora sirve para todos los sistemas operativos, tanto para los sistemas de ordenadores como los sistemas para dispositivos móviles (smartphones y tablets). El caso de estos últimos dispositivos ha supuesto nuevos retos de seguridad, los problemas descritos en este apartado se ven agravados en este caso por el hecho de que estos dispositivos abandonan continuamente el «perímetro de seguridad» de la organización, siendo la protección de sus recursos especialmente necesaria. 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. Hasta hace unos años los dispositivos móviles carecían prácticamente de otra funcionalidad que no fuese la realización de llamadas o el envío de mensajes de texto. Para realizar dichas funciones necesitaban un sistema operativo sencillo y prácticamente imposible de comprometer. Con el incremento de las funcionalidades de dichos terminales ha sido necesario dotarlos de sistemas operativos complejos similares a los que encontramos en estaciones de trabajo y servidores, lo que ha hecho que estos dispositivos móviles pasen a tener ahora los mismos problemas de seguridad que dichos equipos. Esa misma reflexión es de aplicación a los sistemas operativos de conmutadores, encaminadores, puntos de acceso, y demás dispositivos de red de los que se habló en el tema 2. Al incrementar las posibilidades de configuración y servicios ofrecidos por estos dispositivos sus sistemas operativos son también cada vez más complejos y por tanto pueden presentar nuevos riesgos de seguridad inexistentes hasta entonces. Se ha hablado hasta ahora de los sistemas operativos, pero no hay que olvidarse que este no es el único software que se ejecuta en los terminales y servidores, de hecho la utilidad de los ordenadores y las comunicaciones viene dadas por las diferentes aplicaciones que se ejecutan en los mismos. Si bien es responsabilidad de los sistemas operativos el controlar el acceso que hacen estas aplicaciones a los recursos es necesario utilizar software que garantice, en la medida de lo posible, que el uso que hacen de los recursos a los que tiene acceso es el esperado y no utilice dichos recursos de forma inadecuada (ya sea de forma maliciosa o por errores de programación).

71


Antes se ha hablado de que es necesario utilizar, siempre que sea posible, sistemas operativos que dispongan de alguna certificación de seguridad. Dichas certificaciones se expiden no solo para sistemas operativos sino también para aplicaciones, por tanto será recomendable usar aplicaciones que consten con algún tipo de certificación de seguridad, especialmente para aquellos servicios que traten con información sensible de la organización. Un ejemplo particular de un intento de garantizar la seguridad de las aplicaciones los encontramos en los portales de descargas de aplicaciones para dispositivos móviles. Tanto Apple como Google, creadores de los sistemas operativos iOS y Android respectivamente, han creado portales donde los usuarios pueden buscar aplicaciones para sus dispositivos móviles. En dichos portales se trata de controlar en mayor o menor medida (Apple tiene políticas mucho más restrictivas que Google a la hora de aceptar las aplicaciones que se publican en su portal) que las aplicaciones que se distribuyen a través de los mismos son seguras para el usuario (aunque el sistema no es infalible y han llegado a publicar aplicaciones peligrosas, especialmente en el caso del portal de Google). Los terminales que tienen instalados los sistemas operativos de estas compañías inicialmente solo dejan instalar aplicaciones publicadas en sus respectivos portales de descargas (aunque dicha protección puede ser eliminada de forma sencilla en el caso de Android y no tan fácilmente en el caso de iOS). Finalmente, no hay que olvidar el factor decisivo, el factor que puede hacer que todo lo que se pueda usar como defensas no sirva para nada, el factor más complejo y sofisticado de todos: el factor humano. Uno de los mayores expertos en gestión de proyectos, Tom de Marco, inventó un término, Peopleware, que expresa, informáticamente y con cierta dosis de humor, la necesidad de que el personal de gestión de los sistemas esté elegido cuidadosamente y sea formado y «re-formado», pues, sin ello, no se podrá nunca estar suficientemente seguros de la fiabilidad de los sistemas y de la confianza que hay que tener en ellos. Resulta curioso comprobar cómo, en tiempos en los que hay cada vez más métodos novedosos, además de los clásicos, de formación, ésta se convierte en algo infravalorado, llevando a situaciones en las que los puestos de trabajo se ocupan cubriendo anuncios como «Se busca expertos en varios sistemas operativos, con experiencia en gestión de bases de datos y lenguajes de desarrollo, nunca mayores de 30 años».

72


3. LOS PROTOCOLOS Y APLICACIONES IP No se va a hacer una exposición completa de la tecnología IP, pero conviene, antes de hablar de seguridad IP y de seguridad en aplicaciones, hacer un pequeño repaso a los puntos clave de ese conjunto de protocolos que se conoce como la familia de protocolos IP, en la versión usada actualmente por casi todo el mundo, IPv4. Tomemos prestado, para la primera parte del repaso, una analogía de uno de los padres de IP y de Internet, Vint Cerf, sobre cómo funciona una red IP: El protocolo IP puede enviar una novela, página a página, numeradas y pegadas, en la parte trasera de tarjetas postales. Todas las postales de cada usuario se juntan y son transportadas por los mismos camiones a sus destinos, en los cuales se reordenan. Algunas veces, las postales llegan en desorden. Algunas veces, puede que una postal no llegue, pero se puede usar los números de página para pedir otra copia. Pero, y esto es clave para la seguridad, cualquiera del servicio postal, que gestiona las tarjetas postales, puede leer su contenido, sin que el emisor o el receptor se den cuenta.

Otro aspecto que hay que recordar es, siguiendo el símil, los «tipos de tarjetas», los protocolos que conforman la familia de protocolos de IP. No es el momento de profundizar, pero conviene repasar la figura 3.1, recordando que: • 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 direccionamiento 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, encontramos, entre otras muchas, las aplicaciones de la figura 3.1. Todas funcionan siguiendo el modelo cliente servidor, y los números de puerto (por ejemplo, 23 para Telnet o 25 para SMTP) juegan un papel fundamental para entender su funcionamiento.

73


Figura 3.1. Estructura de la familia de protocolos de la familia IP.

Desde el punto de vista de la estructura, los mensajes IP pueden ser de tres tipos, mostrados en la figura 3.2: • Mensajes generados por una aplicación que tenga transporte TCP. • Mensajes generados por una aplicación que tenga transporte UDP. • Mensajes generados por protocolos del nivel de red (en que reside el propio IP), como ICMP o IGRP.

Figura 3.2. Estructura de los distintos tipos de mensajes IP.

74


Todos ellos comparten algo fundamental: una cabecera IP, que contiene, a su vez, varias cosas fundamentales desde el punto de vista de la seguridad: • La dirección IP destino del mensaje. • La dirección IP origen del mensaje. • El número de protocolo, que indica de qué protocolo es la siguiente cabecera, por ejemplo 1 para ICMP o 6 para TCP. • Información de fragmentación del mensaje. Si está fragmentado o no, y, si lo está, qué número de fragmento es. También hay que resaltar que todos los mensajes generados por aplicaciones con transporte TCP tienen en común una cabecera TCP. Esto incluye información que es fundamental, como se verá, desde el punto de vista de seguridad, como es: • El número de puerto origen del mensaje, que identifica un proceso en el sistema origen. • El número de puerto destino del mensaje, que identifica un proceso en el sistema destino. • 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, por ejemplo si el mensaje es indicativo de uno de los dos primeros pasos de la creación de la sesión, llevará el bit SYN habilitado (con valor 1), si es un mensaje en el que se da cuenta de haber recibido uno previamente en esa sesión, llevará el bit ACK habilitado, etc. Como se verá, las sesiones TCP permiten medidas de defensa más sofisticadas, razón por la cual suele decirse que TCP es más fiable que UDP. Hay que recordar, en ese sentido, cómo es la creación de una sesión TCP (figura 3.3), desde que un usuario arranca un cliente en su máquina, hasta que se ha creado la sesión TCP, que será completamente identificable, en cualquiera de los dos sistemas, por los valores: (Dir. IP origen, n.º puerto origen, Dir. IP destino, n.º puerto destino) que aparecen mediante el comando netstat.

75


Figura 3.3. Secuencia de mensajes en la creación de una sesión TCP.

Si se mira el detalle de la figura 3.3, se puede ver cómo es el establecimiento de una sesión TCP entre un cliente y un servidor IP, independientemente de su localización en la red, y obviando el problema del encaminamiento: 1. Para ello, hay que recordar que cuando un usuario arranca su cliente, se envía a la red un mensaje en el que van la dirección IP destino (tecleada directamente por el usuario o tras una traducción DNS) y el número de puerto destino (obtenido del fichero de servicios, en el que se asocian los números de puerto del servidor con el nombre del servicio, por ejemplo, 23 para Telnet o 80 para http). Este mensaje lleva, además, el bit de SYN habilitado, el bit de ACK deshabilitado (con valor 0), 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 no sabe nada del cliente, hasta este momento. 2. El mensaje llega al servidor, al proceso servidor, que, si lo acepta, crea una entrada en la tabla de sesiones «semi-establecidas» de TCP, una tabla llamada así porque lleva la cuenta de qué sesiones están «a medio hacer» (y que habrá que tener en cuenta cuando se hable de ataques de tipo denegación de servicio) 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

76


NSEC-1 + 1. El servidor esperará a recibir el siguiente mensaje, para borrar la entrada de la tabla de conexiones embriónicas («a medio hacer») y dar de alta la sesión en la tabla de sesiones establecidas. 3. Cuando el mensaje anterior llega al cliente, al proceso cliente, éste 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 NSEC1 tendrá un valor de NSEC1-previo más el número de bytes de este mensaje y el NACK1 tendrá un valor de NSEC-2 + 1. Este comportamiento, conocido como «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, como se verá, para una defensa inteligente. Hay que seguir con los tipos de mensajes (figura 3.2). Todos los mensajes generados por aplicaciones con transporte UDP comparten una cabecera de UDP, una cabecera muy pobre para la seguridad. La cabecera UDP, desde el punto de vista de seguridad, solo tiene dos campos relevantes: los dos números de puerto. UDP por tanto proporciona poca información para controlar el tráfico de estas aplicaciones. Como se podrá observar más adelante, esto traerá problemas graves. Finalmente, los mensajes de protocolos del nivel de red (ICMP, OSPF, IGRP, EIGRP y otros) comparten solo la cabecera IP. Aquí, la aproximación a la seguridad pasa por el conocimiento de cada protocolo, de su cabecera y de su funcionamiento. Cada uno tiene sus particularidades, algunas de las cuales pueden dar lugar a problemas, como, por ejemplo, la posibilidad de hacer preguntas (de tipo ping) a una dirección de difusión (broadcast) del ICMP o la falta de autenticación de los mensajes de protocolos de encaminamiento, sea ésta completa, caso de RIPv1 o IGRP, o sea por no estar implementado como en el caso de OSPF o EIGRP. Finalmente, se llega a las aplicaciones con información de transporte. Para estar al tanto de todas sus inseguridades, habría que conocerlas bien todas. Podría ayudar, solo ayudar, pensar en las estadísticas (siempre aproximadas) del tráfico por Internet: entre http, SMTP y ftp se está hablando de alrededor del 80% del tráfico.

77


No se va a hacer un tratamiento exhaustivo, pero conviene tener en cuenta una serie de datos generales: • IP no fue diseñado para proporcionar seguridad, sino para transportar mensajes (paquetes) de un ordenador a otro. En su diseño no hay nada sobre cómo autenticar sistemas o cómo enviar mensajes secretos (criptográficos). • Hay una serie de ataques, basados en particularidades de los protocolos (que no son bugs, sino solo modos de funcionamiento internos), que se discuten más adelante en este libro con detalle, y que se conocen desde hace bastante tiempo. Por ejemplo, los relacionados con sniffers, que se aprovechan de que aplicaciones como Telnet o ftp envían sus datos de autenticación (nombre de usuario y contraseña) en texto claro, los ataques de suplantación (spoofing) de direcciones IP o de servidores DNS, http, etc; el «secuestro» de sesiones Telnet, el redireccionamiento de mensajes con fines ilícitos, etc. • La mayor parte de los virus y gusanos (tema 4), que, hoy en día, se propagan por la red, en forma de partes de mensajes de correo (SMTP). • Muchas de las implementaciones de los protocolos de aplicación más significativos (http, SMTP, nuevos protocolos multimedia) se basan en código modular, en el que se podría (y se puede) garantizar la seguridad de cada módulo, pero es prácticamente imposible (sobre todo cuando el número de módulos es grande y la procedencia diversa) garantizar la seguridad del sistema completo. Finalmente, unas palabras sobre el llamado «código móvil», en el que se puede englobar distintas tecnologías como JavaScript, Java, ActiveX y los «plug-ins» descargables. Todas y cada una de estas opciones de código, así como las famosas cookies, han demostrado tener, en mayor o menor grado, problemas de seguridad, relacionados con un mal diseño desde el punto de vista de seguridad, malas implementaciones, malos usos o todo a la vez. Por otro lado, es innegable su importancia en el mundo IP. Todo el mundo las utiliza, en mayor o menor medida, muchas veces sin saber que lo están haciendo. Habrá que volver a ellos cuando se analicen, con más detenimiento, los distintos tipos de ataques, en el tema 4.

78


4. MEJORAS DE SEGURIDAD CON IPv6 La versión 4 de la familia IP, en particular el protocolo de Internet (IPv4), proporciona los mecanismos de comunicación básica para redes IP y para la red Internet. Los años han demostrado que el diseño es flexible y potente. Pero hay una serie de razones que han hecho que se mejore, que se cree una nueva versión: • La necesidad de un espacio de direcciones mucho más extenso. • El soporte de nuevas aplicaciones, alrededor del audio y del video en tiempo real y de la calidad necesaria de la transmisión. • Nuevas capacidades que hagan posible una comunicación mucho más segura, necesaria para muchas de las aplicaciones en el entorno del denominado comercio electrónico. Con respecto a este último punto, se desarrollaron, en el marco de la versión 6 de IP (IPv6), una serie de protocolos, que se conocen con el nombre de IPSec. Estos protocolos, originalmente definidos en 1995 en los RFC 1825, 1826, 1827, 1828 y 1829, fueron redefinidos en 1998 en los RFCs del 2401 al 2412, y finalmente en 2005 se produjo la tercera generación de documentos, recogidos en los RFCs 4301 a 4309. Estos protocolos se desarrollaron para IPv6, con la idea del despliegue rápido del propio IPv6. Esto no ha sido así, pero 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. De esta manera, se dispone de un conjunto de protocolos de seguridad, potentes y flexibles, que funcionan bien en IPv4 y en IPv6. Si se portan sistemas a IPv6, el comportamiento de seguridad con IPSec está garantizado, al haber sido desarrollados originalmente para tal versión. 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 pudiera encriptar todos los mensajes, excepto los necesarios para el encaminamiento. • Que se proporcione autenticación de máquinas origen y destino, dejando a otros elementos la autenticación de usuarios. • Que se mantenga flexible el proceso técnico de asignación de claves, por razones de seguridad criptográfica.

79


• Que los algoritmos matemáticos utilizados fueran de la criptografía estándar, para asegurar la interoperabilidad. • Que no se cerrara la elección de tales algoritmos, para poder añadir, en el momento que se necesitara, cualquier otro algoritmo criptográfico en el que se pusiera de acuerdo la comunidad. Tales protocolos son: • AH (AuthenticationHeader). Proporciona autenticación e integridad. • ESP (Encapsulating Security Payload). Proporciona confidencialidad, así como, opcionalmente, integridad y autenticación. • KMP (Key Management Protocol). Proporciona intercambio seguro de claves y administración de todo el proceso criptográfico de claves. No se va a entrar ahora en el detalle, pues no es éste el tema al que le corresponde. En los temas 16 y 17 se verá como ha mejorado, espectacularmente, la seguridad de las comunicaciones en redes, el despliegue de los protocolos IPSec, sobre redes que usen como base IPv6 o sobre las redes actuales con IPv4. 5. CRITERIOS DE EVALUACIÓN DE SEGURIDAD Hay ya una historia de más de 30 años de esfuerzos para tratar de normalizar, homologar o certificar, de alguna forma, eso que se está llamando seguridad de los productos informáticos. Tan importante es la situación como para que organismos como la Organización para la Cooperación y el Desarrollo en Europa (OCDE) haya publicado repetidamente «Guías para la seguridad de los sistemas de información y redes». La versión más reciente es la correspondiente a la sesión 1037, de julio de 2002, cuyo documento en español se puede consultar en: http://www.oecd.org/internet/ieconomy/34912912.pdf En ella, se anima a crear una cultura de la seguridad, y se indican una serie de principios y recomendaciones generales, que hacen aún más relevante la búsqueda de la homologación o certificación citada. A principios de los años 80 se desarrolló en EE.UU. un grupo de normas conocidas como la Trusted Computer System Evaluation Criteria

80


(TCSEC). Tal normativa está, prácticamente, obsoleta. Baste decir que no contempla, con seriedad, el hecho (hoy en día imprescindible) de que el sistema que se evalué, esté en una red. No obstante, en aras de un mejor desarrollo, se puede citar los niveles de seguridad y su correspondencia dentro de esta normativa: • D, protección mínima. • C, protección discrecional. Está dividido en dos subniveles, el C1 y el 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, así como identificación de usuarios. 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, B1, B2 y B3. 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. Por último, el nivel B3 presenta dominios de seguridad, con lo que se pueden gestionar diferentes dominios de instalación de los equipos físicos, así como se garantiza un terminal de usuario con conexión segura. • A, protección verificada. Solo 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, incluyendo la distribución fiable desde la fábrica hasta el usuario final, con la correspondiente protección durante la expedición. En la siguiente década, otros países tomaron una serie de iniciativas análogas, dirigidas a desarrollar nuevos criterios de evaluación, construidos a partir de los conceptos del TCSEC estadounidense, tratando de hacerlos más flexibles y adaptables a lo que estaba siendo (y ha seguido siendo) la evolución natural de la informática. En este sentido, en el año 1991 se publica, en Europa, el Information Technology Security Evaluation Criteria (ITSEC), gracias al esfuerzo de Holanda, Francia, Alemania y Gran Bretaña. Por otro lado, en 1993, en Canadá se publica la Canadian Trusted Computer Product Evaluation Criteria (CTCPEC), tratando de reunir y desarrollar las aproximaciones citadas del ITSEC y TCSEC.

81


También en 1993, en EE.UU., se publicó el borrador de Federal Criteria for Information Technology Security (FCITS), una segunda aproximación, tratando de combinar los conceptos americanos y europeos. Por otro lado, desde 1990, la International Organization for Estándarization (ISO) había estado trabajando en el desarrollo de una serie de normas internacionales, para los criterios de evaluación de la seguridad de sistemas de información (ISO/IEC 15408), que son conocidos, popularmente, como los Common Criteria. En dicha normativa se recogen los estándares anteriores y en Mayo de 2000, en Baltimore (EE.UU.), se ratificó la adhesión de Alemania, Australia, Canadá, España, EE.UU., Finlandia, Francia, Grecia, Italia, Noruega, Nueva Zelanda, Países Bajos y Reino Unido, al Convenio sobre el reconocimiento de los certificados de criterios comunes en el campo de la seguridad de la tecnología de la información. Posteriormente, en Noviembre de 2000, se incorporó Israel. Antes de entrar en detalles más técnicos, hay que remarcar una serie de ideas y datos importantes sobre tal «convenio»: • El conjunto de los países miembros representaban, en 1999, más del 65% del mercado mundial de la tecnología de la información, un dato del European Information Technology Observatory. • El convenio parte de la premisa de que la utilización de productos y sistemas de la tecnología 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. • Los certificados de seguridad son expedidos, por Organismos de Certificación reconocidos, a productos o sistemas informáticos, que hayan sido satisfactoriamente evaluados por servicios de evaluación, conforme a los Criterios Comunes (norma ISO/IEC 15408). El convenio detalla los requisitos que han de cumplir los Certificados de Criterios Comunes, los Organismos de Certificación y los Centros de Evaluación. • Entre los objetivos que motivan el convenio figuran: a) Asegurar que las evaluaciones de los productos y sistemas informáticos y de los respectivos perfiles de protección (adecuados a

82


cada caso) se llevan a cabo de acuerdo con normas rigurosas y consistentes. b) 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. c) Eliminar la carga de trabajo que supone la duplicación, en distintos países, de las evaluaciones de los productos y sistemas informáticos, gracias a la aceptación internacional de los certificados. d) Disminuir el gasto del proceso de evaluación y de certificación de los productos y sistemas informáticos y perfiles de protección, en razón de la economía de escala. La creación de este estándar como medida de evaluación de la seguridad de determinados productos o sistemas informáticos proporciona un marco común con el que determinar los niveles de seguridad y confianza que implementa un determinado producto o sistema, de esta manera, los consumidores podrán conocer el nivel de confianza y seguridad de los productos o sistemas que les son ofertados. Se examinarán ahora los conceptos clave de los Criterios Comunes: • 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 seguridad informática. Se ha desarrollado para soportar la definición de normas funcionales, y como una ayuda a la formulación de especificaciones procedimentales. Los hay para cortafuegos, bases de datos relacionales, sistemas, etc. • Objetivo de la Evaluación - TOE (Target of Evaluation). Un producto o sistema informático, que va a ser objeto 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. Cuando el ST dice ser conforme a uno o más PPs, esto forma la base de una evaluación.

83


• 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: — Auditorias. — Comunicaciones. — Soporte criptográfico. — Protección de datos del usuario. — Identificación y autenticación del usuario. — Administración de la seguridad. — Privacidad o confidencialidad. — Protección de las funciones de seguridad del TOE. — Utilización de recursos: tolerancia a fallos, prioridad de servicio, etc. — Acceso al objetivo de evaluación. — Canales de comunicación seguros. • 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. Define las siguientes clases: — Gestión de la configuración. — Operación y entrega. — Desarrollo. — Documentación y guías. — Prueba. — Evaluación de vulnerabilidades. — Evaluación de perfiles de protección (PPs). — Evaluación de objetivos de seguridad (STs). — Mantenimiento de garantías. • Los niveles de seguridad evaluada (Evaluation Assurance Levels). Definen una escala de medición de los criterios de evaluación de PPs

84


y STs. Estos niveles son 7, con las siguientes asociaciones de seguridad: — EAL1: Realizadas pruebas de funcionalidad. — EAL2: Realizadas pruebas de estructuración. — EAL3: Realizadas, metódicamente, pruebas y chequeos. — EAL4: Diseñado, chequeado y probado metódicamente. — EAL5: Diseñado y probado semiformalmente. — EAL6: Diseño verificado semiformalmente, y probado. — EAL7: Diseño verificado formalmente, y probado. Hay que añadir que los EALs se han desarrollado con el objetivo, entre otros, de preservar los conceptos de seguridad usados para desarrollos previos. A modo de ejemplo, se puede ver, en la tabla 3.1, la equivalencia con los niveles de las normas TCSEC e ITSEC. Para entrar en mucho más detalle, se puede visitar el web de los Criterios Comunes: http://www.commoncriteriaportal.org Tabla 3.1. Equivalencia de las normas de Criterios Comunes con las TCSEC e ITSEC Criterios comunes —

TCSEC de EE.UU. D: Protección mínima

ITSEC europeos E0

EAL1

—

—

EAL2

C1: Seguridad discrecional

E1

EAL3

C2: Control de acceso

E2

EAL4

B1: Seguridad etiquetada

E3

EAL5

B2: Protección estructurada

E4

EAL6

B3: Dominios de seguridad

E5

EAL7

A1: Seguridad verificada

E6

85


En la web de los Criterios Comunes se puede consultar el listado de los productos evaluados con el nivel de seguridad evaluado (http://www. commoncriteriaportal.org/products/). En dicho listado se puede encontrar, por ejemplo, varias versiones de la base de datos de Oracle, con EAL4, el subsistema criptográfico de los encaminadores y cortafuegos de Cisco, así como las últimas versiones del software de cortafuegos de Checkpoint, con EAL4, o el sistema operativo Solaris de Sun, el AIX de IBM, el Windows 2008 Server de Microsoft, o el Mac OS X 10.6 de Apple, etc. Como punto final, hay que decir que los Common Criteria no son el único estándar de seguridad utilizado hoy en día, al contrario, actualmente encontramos gran cantidad de estándares de evaluación de la seguridad, algunos de ellos admitidos internacionalmente y en cambio otros a nivel de país o de grupos de países. Quizás otro de los estándares de seguridad 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 cumplir un SGSI (Sistema de Gestión de la Seguridad de la Información).

86


6. CONOCIMIENTOS Y COMPETENCIAS ADQUIRIDAS En junio de 1996, el cohete Arianne 5, de la Agencia Europea del Espacio (ESA) explotó, nada más despegar, debido a un error en su programación. El programa trató de almacenar un número de 64 bits en un espacio de memoria de 16 bits, provocando un «desbordamiento de buffer» (fallo del que, como se verá más adelante, se aprovechan algunos hackers). Su origen, bastante explicativo, fue que esa pieza de software, suficientemente probada para los vuelos del cohete Arianne 4, no se actualizó, por considerarse «innecesaria» tal actualización (se supone que, también, más caro), al portar el software a la versión de control del Arianne 5. Con tanta medida de seguridad (kernels seguros, medidas de control de acceso, protocolos seguros, criptografía fuerte, etc.), parecería que se dispone de todo lo que hace falta. Entonces, ¿por qué se sigue teniendo tantos problemas?, ¿por qué cada vez es más difícil?, ¿por qué no se ve que las cosas vayan mejor? La razón está en ver claramente que «el papel aguanta lo que se le ponga». En la teoría, en el diseño, todo funciona perfectamente, pero cuando se implementa tal diseño, la estadística sigue diciendo que sigue habiendo muchos fallos, muchos bugs, muchas implementaciones mal acabadas, mal administradas, mal usadas. No obstante, hay que conocer de qué se dispone y tratar de utilizarlo juiciosamente. En este tema, se ha querido señalar que: • Todo sistema operativo tiene una parte, conocida como subsistema de seguridad, que interactúa con el resto del sistema, para determinar el control de acceso de los sujetos a los objetos, que suelen ser usuarios accediendo a ficheros o aplicaciones. • Tanto los sistemas operativos como las aplicaciones utilizadas pueden contener bugs o fallos de seguridad que permitan accesos no autorizados a los recursos. • Los sistemas operativos y los productos utilizados deberían estar certificados en un grado tal que cumplieran las condiciones de nuestra política de seguridad. En ese sentido, se puede seguir los criterios de los Common Criteria, normas ISO/IEC 15408.

87


• Además, debe ponerse en marcha, de acuerdo con la política de seguridad, una administración y un mantenimiento del sistema y de los productos, suficientemente fiable. • Hay que tener en cuenta que, en el mundo de hoy, los protocolos que se usan son los de la familia de IP. Cuanto más se conozcan, y en detalle, más fácil será entender los ataques de red de los que hablará el tema siguiente. Cada uno de ellos tiene sus peculiaridades de seguridad, sin tener en cuenta que las implementaciones no tienen por qué ser completamente fiables. • No obstante, se puede afirmar que cualquier aplicación con transporte TCP es más fiable que cualquiera con transporte UDP, debido a la existencia de la sesión TCP, con una «vida» claramente determinada. • Aunque sin entrar, aún, en detalles, se ha visto que la llegada (relativa) de IPv6 ha llevado a las redes actuales a disponer de unas herramientas muy potentes desde el punto de vista de la seguridad como son los protocolos IPSEC. • Se puede afirmar, asimismo, que se dispone, por primera vez, de un conjunto de normas suficientemente amplio, flexible y consensuado por la industria y los usuarios, de evaluación de la seguridad de sistemas y productos informáticos, los ya citados Common Criteria. 7. BIBLIOGRAFÍA TANENBAUM, A.; WOODHULL, A. (2006): Operating Systems Design and Implementation. 3.ª edición. Prentice Hall. SCHNEIER B. (2000): Secrets & Lies (Digital Security in a Networked World). John Wiley & Sons. COMMON CRITERIA web oficial, URL: http://www.commoncriteriaportal.org 8. PALABRAS CLAVE Android, Common Criteria, iOS, IPSec, IPv4, IPv6, ISO/IEC 15408, kernel, LINUX, Mac OS, software, TCP, TCSEC, UDP, UNIX, Windows.

88


9. EJERCICIOS RESUELTOS 1. El kernel de un sistema operativo es: a) El programa que controla toda la seguridad del sistema operativo. b) El nombre que recibe el centro físico del ordenador. c) La parte del sistema operativo que controla la administración de recursos. d) Una nueva aplicación de seguridad para Windows. Solución: c. 2. La seguridad de los datos frente a accesos no autorizados la garantiza cualquier sistema de ficheros de cualquier sistema operativo: a) Verdadero, hoy en día cualquiera puede hacerlo. b) Falso, depende de qué sistema de ficheros. Por ejemplo FAT no puede hacerlo. c) Falso, el sistema de ficheros nunca se ocupa de estos asuntos. d) Verdadero, pero, además, depende de la gestión de usuarios. Solución: b. 3. Los mensajes IP pueden ser de: a) 4 clases distintas: sólo IP, mensajes de aplicaciones con transporte TCP, de aplicaciones con transporte UDP y de protocolos del mismo nivel 3. b) 3 clases distintas: mensajes de aplicaciones con transporte TCP, de aplicaciones con transporte UDP y de protocolos del mismo nivel 3. c) 2 clases distintas: mensajes de aplicación con transporte TCP y de aplicaciones con transporte UDP. d) Muchas clases distintas, dependiendo de la aplicación y el protocolo de encaminamiento. Solución: b. 4. ¿A que se denomina IPSEC? a) A un protocolo de comunicaciones, desarrollado, por IBM, para su arquitectura de comunicaciones. b) Al conjunto de protocolos (AH, ESP y KMP), normalizados en RFCs, que se usarán cuando se porten las redes a IPv6.

89


c) A una serie de normas, desarrolladas por Cisco Systems, y aprobadas después por la industria y los usuarios, que permiten crear productos que encriptan las cabeceras de aplicación de los mensajes IP. d) Al conjunto de protocolos (AH, ESP y KMP), normalizados en RFCs, que se desarrollaron para IPv6, se han portado a IPv4, y que permiten enviar mensajes IP con autenticación, integridad y confidencialidad. Solución: d. 5. Los Criterios Comunes (Common Criteria) de seguridad son: a) El nombre popular, con el que se hace referencia a la norma ISO/IEC 15408, que proporciona criterios, suficientemente consensuados a nivel internacional, de evaluación de la seguridad de los productos y sistemas informáticos. b) El nombre que reciben los criterios del gobierno de los EE.UU. de América, de evaluación de la seguridad de los productos y sistemas informáticos. c) El nombre de las recomendaciones de la OCDE, para el análisis y desarrollo de los sistemas de evaluación de la seguridad, provenientes de las normas ITSEC. d) El nombre de un libro famoso, sobre el arte del engaño en la historia de la seguridad. Solución: a. 10. EJERCICIOS DE AUTOEVALUACIÓN 1. Respecto a los sistemas operativos indique la afirmación correcta: a) Los sistemas operativos actuales disponen de un subsistema de seguridad que los hace completamente inmunes ante posibles ataques. b) Los sistemas operativos cada vez más complejos que llevan los teléfonos inteligentes los han hecho susceptibles a problemas de seguridad que no tenían los teléfonos de hace unos años que solo servían para llamar por teléfono y enviar mensajes de texto. c) El kernel del sistema operativo debe controlar el acceso de los usuarios a los distintos archivos del dispositivo. d) Todas las anteriores son correctas.

90


2. Indique cuál de las siguientes afirmaciones es correcta: a) Los programas ejecutados en los terminales y servidores también pueden implicar riesgos de seguridad que deben ser tenidos en cuenta. b) Si el sistema operativo instalado tiene correctamente implantados los mecanismos de seguridad necesarios los programas instalados nunca supondrán un problema de seguridad. c) Los teléfonos inteligentes y tabletas no tienen aplicaciones problemáticas ya que en ellos solo se pueden instalar aplicaciones aprobadas por los fabricantes de los sistemas operativos. d) Todas las afirmaciones son falsas. 3. Indique cuál de las siguientes afirmaciones es verdadera: a) El protocolo de transporte UDP debe iniciar una sesión mediante el procedimiento «3-step handshake» antes de iniciar la transmisión. b) El protocolode transporte ICMP debe iniciar una sesión mediante el procedimiento «3-step handshake» antes de iniciar la transmisión. c) El protocolo de transporte TCP debe iniciar una sesión mediante el procedimiento «3-step handshake» antes de iniciar la transmisión. d) El protocolo de transporte IGRP debe iniciar una sesión mediante el procedimiento «3-step handshake» antes de iniciar la transmisión. 4. Indique cuál de las siguientes afirmaciones es correcta: a) IPSec es un conjunto de protocolos cuyo objetivo es poder realizar comunicaciones IP más seguras. b) IPSec fue originalmente desarrollado para IPv6 y portado posteriormente a IPv4. c) Los protocolos IPSec se encuentran definidos en los RFCs 4301 a 4309. d) Todas las anteriores son correctas. 5. En los Common Criteria, ¿qué define la escala de medición de los criterios de evaluación?: a) b) c) d)

El perfil de protección (PP). El nivel de seguridad evaluado (EAL). El objetivo de evaluación (TOE). El objetivo de seguridad (ST).

91

Tema 4

Métodos de ataque a equipos y redes

1. Introducción, orientaciones para el estudio y objetivos 2. Taxonomía de los tipos de ataques 3. Ataques orientados a la obtención de información sobre el objetivo 3.1. 3.2. 3.3. 3.4.

Ingeniería social Herramientas informáticas Escuchadores o «sniffers» de paquetes Análisis de metadatos

4. Ataques basados en la mala administración de sistemas 5. Ataques basados en las vulnerabilidades de los protocolos de red 5.1. Ataques Man-in-the-Middle 6. Ataques basados en vulnerabilidades del software 7. Ataques de denegación de servicio 8. Ataques por medio de código malicioso 9. Ataques a dispositivos móviles 10. Conocimientos y competencias adquiridas 11. Bibliografía 12. Palabras clave 13. Ejercicios resueltos 14. Ejercicios de autoevaluación

1. INTRODUCCIÓN, ORIENTACIONES PARA EL ESTUDIO Y OBJETIVOS Conviene recordar lo citado en el tema 1 sobre el parecido entre los ataques a redes y servidores y los «ataques» o amenazas a la seguridad del «mundo real». Los ataques dirigidos a los dispositivos de red que se desea proteger están, finalmente, realizados por personas. Se puede pensar en algunos: robos de bancos, malversaciones y fraudes, invasión de la confidencialidad, sabotaje, espionaje, etc. Todo este tipo de problemas existen, también, en las redes de las organizaciones actuales. Por ejemplo, se puede decir, sin temor a equivocarse, 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. Pero, desde un punto de vista más técnico, sí hay diferencias, se podría decir que 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 citados ataques puedan ser mucho peores, en cierto sentido. Esas características son: • El aspecto automático de los ataques. Si en algo son potentes los ordenadores, es en las tareas repetitivas. Se puede dejar una máquina tratando de descifrar contraseñas de manera automática, mientras el atacante se va a pasar el fin de semana a esquiar, con la tranquilidad de que su «trabajador» no se va a cansar, ni se va a quejar. • El aspecto remoto de los ataques. Es casi tan fácil conectarse a un ordenador en Paris desde Madrid que desde Tokio. En ese sentido, se dice que Internet «no tiene fronteras». Lo grave es que los aspectos legales de todo esto no están, aún, controlados. Como dijo John Gilmore: The Internet treats censorship as a damage and routes around it (Internet trata a la censura como algo dañino y lo rodea).

95


La aún escasa legislación internacional al respecto ayuda en gran manera a los atacantes. • La velocidad de propagación de los ataques. Cualquier atacante puede conseguir, con mucha facilidad, y en un tiempo record, muchas de las herramientas de ataque que necesitará. Si es un amateur, le bastará con conseguir las aplicaciones y empezar a usarlas. Si se habla de un profesional, seleccionará entre las mejores aplicaciones, buscará, incluso, aquellas de las que se dispone del código fuente (para modificarlo a su gusto), pero, unos y otros, podrán disfrutar de ellas en un tiempo incomparablemente menor del que necesitarían en el mundo no cibernético. El objetivo de este tema es presentar al lector los distintos tipos de ataques dirigidos a dispositivos de red, clasificándolos en atención a criterios diversos, pero analizándolos después, en detalle, desde el punto de vista del atacante «profesional». Tal atacante necesitará uno o varios tipos de herramientas para llevar a cabo, con éxito, su proyecto concreto. Estas herramientas (algunas más bien metodología que herramientas) se dirigen siempre a alguna (o varias a la vez) de las siguientes actividades, ya citadas en el tema 1 del libro: • 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. Este tema es fundamental para entender el resto del libro, que va enfocado a cómo parar (o intentarlo) todos y cada uno de los ataques enumerados en el. Para entender bien cómo defenderse de un ladrón, hay que «pensar» como un ladrón y, aunque, obviamente, no se pretende hacer ninguna apología de la inseguridad de las redes, si se va a hacer un análisis, suficientemente exhaustivo, de sus debilidades y problemas de seguridad. El objetivo del tema es por tanto que el lector entienda los riesgos a los que se enfrentan los responsables de seguridad de sistemas informáticos y redes, así como las diferentes técnicas de ataque a las que dichos responsables de seguridad deben enfrentarse.

96

MÉTODOS DE ATAQUE A EQUIPOS Y REDES

2. TAXONOMÍA DE LOS TIPOS DE ATAQUE Una buena clasificación no se puede hacer sin un buen criterio. En este caso, existen varios buenos criterios, dependiendo de lo que se quiera analizar. Atendiendo a un criterio de completitud, se van a utilizar varios de ellos. Se empieza por uno sencillo, pero interesante. Desde el punto de vista del origen del ataque, se puede decir que los ataques son: • Externos. Cuando el atacante origina su ataque desde el exterior de una organización concreta, se dice que el ataque es externo. Esto puede ser desde un sitio desconocido de Internet o desde una dirección en la que se confía, pero que ha sido suplantada. Como se verá, esta característica es esencial para cierto tipo de ataques a una red, que realiza el control de acceso basado, entre otros criterios, en direcciones IP. • Internos. Por muchas de las razones expuestas hasta ahora, y muchas que vendrán más adelante, es obvio que estar dentro de la organización facilita mucho el ataque. Tal ataque ha de ser visto, además, desde un punto de vista amplio. Puede haber ataques «profesionales» internos, pero, también, por mala aplicación de la política de seguridad (o por una mala política de seguridad), ataques no maliciosos de usuarios internos que, simplemente, «prueban» herramientas con toda su buena intención. Otro criterio que conviene utilizar, para una mejor caracterización de cada ataque, es la complejidad del ataque. En este sentido, se puede hablar de ataques: • No estructurados. Son ataques, habitualmente inocentes, basados en herramientas bastante normales, que pueden tener distintos tipos de objetivos, y ser muy peligrosos, pero, en general, fácilmente reconocibles. Por ejemplo, un ataque interno, para «probar» la corrección de los elementos de seguridad, basado en una herramienta, de libre distribución, de denegación de servicio. Una característica típica de estos ataques es que o bien es una sola herramienta la puesta en marcha o son varias, pero sin ninguna estructuración entre ellas. • Estructurados. Estos son los más peligrosos. Son ataques que se enfocan como un proyecto. En ellos se emplean muchos de los métodos concretos y herramientas de las que se va a hablar más adelante en

97


este tema. Además, son ataques «procedimentados», es decir, que tratan de no dejar cabos sueltos, en los que se trata de borrar las huellas del ataque y en los que se tiene en cuenta distintos puntos de ataque y de retirada. Habitualmente, aunque sean los más peligrosos, son los menos habituales. Otro criterio, verdaderamente relevante, tiene que ver con la personalidad del atacante. Su formación, experiencia y capacidad de comunicación pueden ser fundamentales a la hora de desarrollar un ataque, especialmente si es uno estructurado y se usa en la fase de obtención de información. 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 más espectaculares de ataques, por ejemplo, a bancos. Tales «ingenieros» demuestran que no tiene ningún sentido invertir millones de euros en una gran infraestructura, física y lógica, de seguridad, si no se ha tenido en cuenta, en la política de seguridad, la formación y entrenamiento del personal de la empresa u organización. Finalmente, si se catalogan por el objetivo que persiguen así como por el tipo de técnicas utilizadas, y sin perjuicio de que tal catálogo tenga, después, una necesidad de clasificación más granular, 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 y sus implementaciones. • Ataques basados en vulnerabilidades del software. • Ataques encaminados a sabotear un servicio, como un servidor web, un servidor SMTP, el espacio libre en disco de un ordenador, el acceso a (o desde) una red. A todos ellos, se les denomina ataques de denegación de servicio. Teniendo en cuenta que, si se utiliza este último criterio, es muy fácil resaltar, a la vez, los otros criterios citados, será éste el que se va a usar en el resto del tema. Para cada tipo se explicará la técnica concreta usada en cada uno de ellos para a continuación poner ejemplos reales de aplicación de la misma.

98


3. ATAQUES ORIENTADOS A LA OBTENCIÓN DE INFORMACIÓN SOBRE EL OBJETIVO Esta categoría de ataques agrupa todas aquellas técnicas cuyo objetivo final es la obtención de información sobre la organización objeto del ataque. Por medio de este tipo de ataques el atacante trata de hacerse con información que posteriormente le pueda ayudar a continuar con el ataque hasta conseguir comprometer el sistema objetivo. Dentro de esta categoría de ataques encontramos tres tipos de técnicas distintas, todas ellas orientadas a la obtención de distinto tipo de información sobre la maquina o maquinas atacadas: • 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. El objetivo de estas técnicas es la obtención de información que pueda ser utilizada para preparar un ataque mucho más peligroso, al disponer de mucha información sobre el entorno informático y, a veces también, humano y organizativo, del objetivo a atacar. 3.1. Ingeniería social Por el término «ingeniería social» se 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. No hay una única forma de ingeniería social, son muchas las posibles fórmulas empleadas por el atacante para conseguir la información deseada. Puede ser tan sencillo como mirar por encima del hombro cuando un usuario legitimo está introduciendo su contraseña de ingreso al sistema, o tan complejo como conseguir entrar en las instalaciones de la organización objetivo haciéndose pasar por personal de mantenimiento autorizado.

99


Una organización puede usar las mejores herramientas de protección de sus sistemas informáticos y aun así resultar comprometida simplemente porque un usuario facilitó, de buena fe, sus credenciales de acceso a alguien que le llamó por teléfono diciendo que era del departamento de sistemas y que necesitaban dicha información para hacer unas comprobaciones. Según Kevin Mitnick, famoso hacker conocido por ser especialmente habilidoso en el uso de este tipo de técnicas, 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. Pero las técnicas de ingeniería social no solo se basan en interacción directa entre el atacante y un usuario, ya sea por contacto telefónico o por interacción cara a cara. Los atacantes también pueden usar otros medios para tratar de engañar al usuario. Uno de los métodos de ataque de ingeniería social más extendidos y más comunes, en los que se usan medios electrónicos para engañar a los usuarios, es el phishing. Esta técnica consiste en enviar de forma masiva correos supuestamente remitidos por entidades bancarias, o redes sociales en las que se indica al usuario que hay algún problema con su cuenta y que necesita restablecerla, para ello deberá acceder a una página web de la cual se proporciona el link. La figura 4.1 muestra un ejemplo de este tipo de correos electrónicos, en este caso de suplantación de una entidad bancaria. El enlace mostrado en el correo electrónico parece genuino y realmente perteneciente a la entidad bancaria, pero el sitio web al que se accederá realmente en caso de pulsar sobre el mismo no será el sitio web real de la entidad, sino un sitio web que imitará y hará creer al usuario que efectivamente ha accedido al sitio web de la entidad suplantada y donde facilitará al atacante su usuario y contraseña a través del supuesto formulario de restauración de la cuenta. En los casos más elaborados, el atacante usa la información obtenida para validar la información recibida con el sitio suplantado y reenviando después al usuario al sitio real de

100


Figura 4.1. Ejemplo de phishing en el que el atacante suplanta la identidad de una entidad bancaria.

la entidad, consiguiendo de esta manera hacer más creíble el proceso y evitar levantar sospechas en el usuario. 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 formación de los usuarios será esencial para combatir este tipo de ataques. 3.2. Herramientas informáticas Otra técnica dirigida a la obtención de información sobre el objetivo es el uso de comandos y herramientas informáticas, en muchos casos no diseñadas específicamente para un ataque, para la obtención de dicha información. Por ejemplo, el comando ping, que permite obtener la información de qué direcciones IP tienen las máquinas de la red a la que se quiere atacar. Hay una modalidad, consistente en hacer ping a la dirección de broadcast de la red, que permite obtener información de qué direcciones IP se están usando en una red y en cuáles no.

101


Otro comando muy utilizado es nslookup. Gracias a este comando se puede obtener las direcciones IP públicas asociadas a un dominio en Internet. Gracias a ella se puede llegar a obtener además la dirección o direcciones IP del servidor de correo de dicha organización lanzando una consulta sobre su registro MX. Una vez se conocen las direcciones IP, el atacante puede utilizar una herramienta de tipo «port scanner». Estas herramientas permiten, una vez elegida una dirección IP, ver qué aplicaciones o servicios están activos en la máquina, a base de tratar de crear sesiones (en el caso de TCP) o de enviar mensajes sencillos de tipo UDP, haciendo variar uno a uno, el número de puerto destino de cada mensaje. Según el modo en que se envíen esos mensajes de sondeo la actividad del «port scanner» será más fácil o difícil de detectar, ya que pueden llegar a generar un tipo de tráfico fácil de identificar si no se lanzan de forma dosificada. Quizás la herramienta de escaneo de puertos más conocida y extendida es nmap. Esta herramienta de código abierto está disponible para múltiples plataformas (Linux, Windows, MacOs X, Solaris…) e incluye varias funciones para realizar búsquedas de puertos abiertos difíciles de detectar por las herramientas de detección de intrusiones. Además, permite identificar el sistema operativo que se está atacando por medio de un algoritmo que identifica los patrones en los paquetes en los paquetes que devuelve la máquina víctima. Una vez que ha obtenido el listado de puertos abiertos realiza conexiones con todos ellos para obtener la información sobre la aplicación que se está utilizando en cada uno de ellos así como la versión de la misma. Por ejemplo, si se crea una conexión TCP con un servidor ftp, el propio servidor se «presenta», diciéndonos que versión de servidor ftp se está usando. La figura 4.2 muestra parte del resultado que se obtiene con un escaneo de puertos realizado por nmap. Otro grupo de herramientas que se pueden utilizar, una vez se conoce la IP pública del objetivo del ataque, son los analizadores de vulnerabilidades. Estas herramientas 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. Herramientas como Nessus o Metaexploit Framework son en realidad herramientas para la realización de auditorías de seguridad, pero pueden ser usadas a su vez por atacantes para la identificación de vulnerabilidades, con el objetivo de explotarlas.

102


Figura 4.2. Resultado de un escaneo de puertos obtenido con nmap.

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. Por ejemplo, en el caso de SMTP, las primitivas VRFY y EXPN dan información sobre usuarios y direcciones de correo electrónico de la máquina donde funciona el servidor SMTP. Hay que remarcar que cuanto más conocimiento se tenga del lenguaje interno de cada una de las aplicaciones y sus protocolos, más fácil será aprovecharse de cada una de las distintas vulnerabilidades que van apareciendo y poniéndose en conocimiento de todo el mundo, a través de cada fabricante o de servicios independientes. Véase por ejemplo: http://www.hispasec.com/ o http://www.cert.org/ 3.3. Escuchadores o «sniffers» de paquetes Las herramientas de tipo «sniffer» permiten, si se dispone de un enlace a una red sin conmutadores, obtener todo el tráfico que circula por la red. Estas aplicaciones, son pequeños programas que se instalan en el ordenador. Es importante el punto en el que se sitúa el atacante, como se conecta a la red atacada, para determinar que tráfico será capaz de interceptar. Si

103


su equipo está conectado a través de un conmutador (switch), por su forma de funcionamiento, solo recibirá aquellos paquetes destinados específicamente para el, así como el tráfico broadcast, a no ser que, a su vez, el conmutador esté configurado (o el atacante consiga configurarlo) para que todo el tráfico que circula por el se copie al puerto donde se esté usando el sniffer. En cambio, si la conexión a la red es a través de un concentrador (hub) el atacante recibirá copia de todos los paquetes que viajen 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. Si bien esto no es fácil en muchos casos, hay que recordar la enorme expansión en los últimos años de la tecnología inalámbrica. Como se verá en el tema 18 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 usuario que viaje en texto claro, la autenticación en servicios como POP3, SMTP o Telnet viaja por la red sin ningún tipo de cifrado, lo que permite a un atacante que capture dichos paquetes obtener directamente nombres de usuario y contraseña. Al poder capturar toda la información sin cifrar no solo están en peligro las credenciales de usuarios, sino también los datos transferidos. Así, por ejemplo, un atacante puede llegar a capturar todos los paquetes de una transferencia de archivos a través de ftp y reconstruir los archivos transferidos a partir de esos paquetes interceptados. 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 analizar cientos de protocolos distintos, y no solo se puede utilizar para analizar tráfico en tiempo real sino que permite además capturar y guardar el tráfico para su posterior análisis. Está disponible para múltiples plataformas, como pueden ser UNIX/LINUX, Windows, MacOs X, Solaris… La figura 4.3 muestra tráfico capturado por Wireshark en el que se puede observar que se han obtenido los datos de usuarios y contraseña de una cuenta POP de correo electrónico.

104


Figura 4.3. Ejemplo de captura realizada con Wireshark.

3.4. Análisis de metadatos No se puede cerrar este epígrafe sin hablar de la información que puede obtener un atacante mediante el análisis de los metadatos de archivos generados desde la organización atacada. Los metadatos son campos de texto que van incluidos en gran cantidad de archivos, prácticamente todas las aplicaciones ofimáticas incorporan este tipo de información en los ficheros editados por ellas. Entre otra información se puede encontrar información sobre la fecha de creación y modificación del mismo, usuario que lo ha creado, programa utilizado para su edición,… Pero estos ficheros pueden además estar proporcionando información sensible como puede ser nombres, teléfonos, direcciones de correo, rutas en las que se almacenan los archivos, coordenadas geográficas en las que se realizó una fotografía, etc., y todo ello sin que el usuario sea consciente de ello, ya que estos datos no se ven a simple vista. Existe gran cantidad de herramientas gratuitas que permiten extraer los metadatos de los archivos. Por ejemplo Exiftool está especializada en la ob-

105


tención de metadatos de fotografías, se pueden encontrar también herramientas que extraen los metadatos de todos los archivos publicados en un servidor web. Los metadatos son por tanto una fuente invisible de fuga de información que en muchas ocasiones es ignorada o incluso desconocida. Es buena práctica el eliminar este tipo de información de todos aquellos documentos hechos públicos por parte de la organización, especialmente aquellos que se hacen públicos a través de la página web de la misma. 4. ATAQUES BASADOS EN LA MALA ADMINISTRACIÓN DE SISTEMAS Realmente 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. Desafortunadamente para los que se dedican a establecer seguridad en redes, los «inventores» de ataques no se atienen a un criterio muy estricto. Aun así, se tomará el riesgo, en este apartado, 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, y se puede hablar, entonces, de los siguientes tipos de ataques: • Robo de nombres de usuario y de contraseñas asociadas. • Acceso basado en relaciones de confianza mal administradas. • 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, lo que las hace más fáciles de averiguar. Por otro lado, si se obliga (como parte de la política de seguridad) a tener contraseñas difíciles de recordar, es muy probable que el usuario la escriba (o la registre) en algún sitio, lo cual no parece muy adecuado, desde el punto de vista de la seguridad (por desgracia es muy común encontrar la contraseña de un equipo escrita en un post-it pegada en el monitor). Una opción, fa-

106


cilitada ya por algunos sistemas operativos, es ayudar a los usuarios a elegir contraseñas fáciles de recordar, pero difíciles de obtener por el atacante. En este sentido, se hablará de este asunto otra vez en el tema siguiente. Además, las contraseñas se almacenan en ficheros en el sistema, eso sí, se almacenan «encriptadas». Como se verá en el tema 14, las contraseñas de las cuentas de usuario usan uno u otro método de una sola vía («oneway hash»), que consiste, esencialmente, en aplicar un algoritmo de este tipo, de manera que el resultado (al que suele llamarse hash o digest) no sirve para, aplicando un supuesto algoritmo inverso, obtener el original. No existe tal tipo de algoritmos inversos, de ahí el nombre de «una sola vía». Lo que se almacena es el hash de la contraseña para cada usuario. Dependiendo de la seguridad del sistema operativo, de cómo esté administrado, tal información (residente en /etc/passwd o en /etc/shadow en UNIX o en un fichero SAM en los sistemas Windows) puede estar accesible al atacante. Un sistema, con mala administración del sistema de ficheros y una cuenta de invitado (que no debería existir nunca), puede facilitar el que se obtenga esa información. Una vez se dispone de esa información, solo hay que aplicar un programa cracker, que lo que hace es aplicar el algoritmo de hash a toda una lista de palabras (más o menos extensa) y comparar el resultado con el hash del que se dispone para cada cuenta de usuario. Normalmente, las listas son o un diccionario (en el idioma deseado) o una lista de todas las combinaciones posibles de todos los caracteres del estándar ASCII extendido. En el primer caso, se habla de un cracker de tipo diccionario y, si la contraseña era sencilla, en minutos se dispone de ella. En el segundo caso, se habla de un cracker de tipo «fuerza bruta», que es, por definición, infalible. Solo tiene un problema: puede tardarse mucho en obtener la contraseña buscada. Por eso, como se verá, es esencial cambiar la contraseña con cierta periodicidad, de esta forma aun cuando el atacante consiga descifrar la contraseña, esta dejará de ser válida en un corto espacio de tiempo.. Basta con ir a un buscador, por ejemplo Google, y buscar «password cracker» para obtener cientos de ellos diferentes. No obstante, por completitud, se citan algunos de los más típicos: • Brutus: Es una herramienta de ataque de fuerza bruta por la red. Está diseñado sólo para Windows, pero puede usarse para UNIX/LINUX con ayuda de las herramientas Wine y Crossover. Funciona contra ser-

107


vicios de red de sistemas remotos e intenta obtener contraseñas usando ataques de diccionario y fuerza bruta, además de ataques híbridos. Soporta entre otros HTTP, POP3, FTP, SMB, Telnet, IAMP y NTP. Para protocolos no soportados hay además plug-ins disponibles. • John the Ripper: Es una aplicación de línea de comandos, que soporta varios sistemas operativos, entre otras varias versiones de UNIX/LINUX y Windows. Hay versiones gratuitas y de pago, siendo ambas muy potentes. Hay que tener en cuenta que muchos sistemas antivirus marcan este programa como un virus o un troyano. • L0phtcrack: Desarrollado por L0pht Heavy Industries para mostrar las debilidades de seguridad del sistema de autenticación de Windows. Su popularidad es tan grande que cualquier herramienta de volcado de contraseñas las vuelca en formato compatible con L0phtCrack. Intenta obtener la contraseña, mediante diferentes métodos de ataque: diccionario, fuerza bruta, ataques híbridos, etc. Usado con el hardware apropiado, ninguna contraseña está segura. Tiene también una versión para equipos UNIX/LINUX y permite el uso gratis durante 15 días. Hay aún dos aspectos más a remarcar: • Si el usuario que tiene una contraseña fácil, la repite en todos los sistemas para los que tiene acceso, el ataque puede ser mucho más demoledor. • Si, además, en la red estamos utilizando aplicaciones como Telnet o ftp, y no hay conmutadores, por muy difícil que sea la contraseña, basta con disponer de un sniffer, del que ya se ha hablado, para obtener, con suma facilidad, nombres de usuario y contraseñas. El atacante puede pensar que la contraseña es muy «rara», pero lo importante es que ya la tiene. Cuando se habla de relaciones de confianza mal administradas, se está haciendo referencia, esencialmente, 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 (y en sus usuarios), permite (gracias a la configuración de ficheros como /etc/hosts.equiv y /.rhosts en UNIX/LINUX) que un usuario del sistema B, con un nombre de cuenta común (o permitido por la configuración de los ficheros citados) ejecute cualquier cosa, bajo esa cuenta de usuario, en el sistema A. La «confianza»

108


se basa en las direcciones IP de los equipos, que es lo que suele aparecer en estos ficheros, junto con los nombres de usuarios permitidos. Hay dos puntos que suelen hacer la situación más grave: lo normal es que, también, B confíe en A (y que la situación se extienda a otras máquinas) y suele pasar que una de las cuentas para las que esto funciona, sea la del administrador del sistema (root en UNIX o administrador en Windows Server), con lo que el peligro es mucho mayor. La razón de estas configuraciones tan peligrosas es sencilla: la comodidad de trabajar de sistema a sistema, sin el «engorro» de las contraseñas. Los comandos más típicos y extendidos en este tipo de «entornos de confianza» son: • rlogin. Comando que permite hacer log-in de un sistema a otro sin contraseña, si se parte de un sistema en el que el sistema remoto «confía». La sintaxis es muy sencilla: rlogin nom-sis-remoto (o dirección IP sistema remoto)

• rcp. Comando que permite copiar ficheros de un sistema a otro, en iguales condiciones que el anterior. Su sintaxis es: rcp especificación-fichero-local especificación-fichero-remoto

o rcp especificación-fichero-remoto especificación-fichero-local

por ejemplo: rcp /home/prog/proyecto.dat 122.44.1.3:/oculto/secreto

• rsh. Comando que permite ejecutar cualquier comando de la shell remota, en el sistema remoto. Su peligrosidad depende, principalmente, de la cuenta que se haya suplantado. Su sintaxis es: rsh (nombre o dir-IP sistema remoto) ejecutable

Si, por ejemplo, se está en la cuenta root de un sistema en el que se confía, el comando: rsh 122.44.1.1 ‘cd /; rm –r *’

borraría todo el contenido de todos los discos del sistema UNIX remoto. Puede que un atacante no sea capaz de comprometer un sistema A directamente debido a que las medidas de protección del mismo hagan difícil su acceso, pero si consigue comprometer a un sistema B en el que su

109


Figura 4.4. Ejemplo de ataque basado en la explotación de relaciones de confianza.

objetivo confía, podrá acceder al sistema que desea atacar con los mismos privilegios que disponga B en el sistema A. La figura 4.4 muestra un diagrama de esta situación. Esta no es la única forma en que un atacante puede explotar dicha relaciona de confianza, el atacante podría llegar a suplantar la dirección IP del sistema B para hacerse pasar por el. Se hablará de esta técnica un poco más adelante en este epígrafe. Hay más relaciones de confianza que pueden ser utilizadas por un atacante para comprometer un sistema. En los últimos años la tecnología inalámbrica se ha hecho cada vez más común hasta llegar al punto de ser prácticamente omnipresente en nuestras vidas. La extensión ha sido tal, que cada vez encontramos más zonas wi-fi abiertas que los dispositivos pueden utilizar de forma gratuita. Cuando un dispositivo móvil conecta por primera vez con un punto de acceso abierto (y por tanto sin contraseña ni cifrado como se verá en el tema 18) se establece una relación de confianza entre el dispositivo y el punto de acceso en cuestión, de forma que la próxima vez que el terminal esté cerca del punto de acceso se conectará de forma automática. 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 suplan-

110


te la identidad de un punto de acceso abierto (para lo que copiará su SSID como se verá en el tema 18) de forma que a cuando un terminal móvil que tenga establecida una relación de confianza con el punto de acceso suplantado entre en el radio de acción del punto de acceso falso, este se conectará automáticamente con él, por lo que todo el tráfico de red generado pasará a partir de ese momento a través del atacante. La figura 4.5 muestra un diagrama de funcionamiento de esta técnica de ataque conocida como Rogue AP y que se puede englobar también dentro de los ataques de tipo Man-in-the-Middle que se explican en el siguiente apartado.

Figura 4.5. Ejemplo de ataque Rogue AP.

Si se trabaja en una red con sistemas UNIX/LINUX, es típico disponer de servidores NFS (Network File System), que permiten acceder a directorios y discos de sistemas remotos, como si fueran locales, lo cual, una vez más, es realmente cómodo. Esta configuración, mal administrada, puede resultar muy peligrosa. Toda la información de configuración reside en un fichero conocido como /etc/exports, en el que se configura qué directorios se «exportan» y, para cada uno de ellos, con qué permisos: permiso solo para leer la información o permiso para leer y escribir (con lo que se puede también borrar en UNIX). Suele haber, típicamente, dos problemas graves: • Hay una configuración por defecto, en muchos sistemas, que hace que una vez elegidos los directorios a servir por la red, se exporten con permiso de lectura y escritura, dejando un gran agujero de segu-

111


ridad. Este «agujero» resulta aún mayor si se trabaja, en los clientes, con un entorno gráfico UNIX/LINUX típico, en el que hay una opción para «pedir», desde el cliente, la lista de servidores y qué exportan cada uno y cómo lo exportan. • Si el administrador no se toma en serio los posibles problemas, puede, además, permitir que el administrador del cliente trabaje en su sistema, también, como administrador, con lo que cualquiera trabajando en una cuenta de administrador, y que acceda a un directorio en el servidor, exportado de esta manera, puede trabajar como administrador en ese servidor. Si se cambia el entorno y se piensa en el entorno Windows de compartición de directorios, aparecen los mismos problemas que en el caso anterior. En este caso, la administración es particularmente sencilla. Se pincha en el directorio a compartir, en sus propiedades, se comparte el directorio y ya está. No hay posibilidad sencilla de permitir acceso solo a determinados usuarios y solo en determinadas condiciones. Es particularmente peligroso en sistemas Windows «antiguos» como Windows 95 o Windows 98, en los que no se exige autenticación en el dominio de Windows. Esto se complica, aún más, cuando se tiene en cuenta la multitud de bugs encontrados en el protocolo SMB (Server Message Block) de Microsoft, protocolo responsable de tales transferencias de ficheros. 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 SNMP (Simple Network Management Protocol). Este protocolo, encargado de la gestión remota de dispositivos en red tiene diferentes versiones. En las más «antiguas», versiones 1 y 2, el mecanismo de autenticación entre los agentes y la estación de gestión es un «community string», que se transmite sin encriptar de ninguna manera y que suele ser el valor por defecto, public, haciendo a todo el mundo, incluido el atacante, más fácil el acceso al dispositivo objetivo, pudiendo ser éste, incluso, la estación de gestión de red. Así, sin más que «esniffar» se puede obtener mucha información de la red y de la gestión SNMP de cada equipo. Se dispone de una versión 3 mejorada, con encriptación implícita, pero es, desgraciadamente, muy normal, ver habilitado por defecto el comportamiento de la versión 1 en muchas redes.

112


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, más o menos sofisticado, 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. Esto es así, si está configurado, pues si no lo está (caso muy habitual), cualquier encaminador se «cree» cualquier mensaje de actualización de cualquier otro encaminador del mismo protocolo, haciendo muy sencillo «colocar» uno falso en medio (que puede ser, incluso, un sistema Windows Server o UNIX/LINUX configurados como encaminador OSPF) y «obligar» a los otros encaminadores a que toda (o solo determinada) información pase a través de ellos. Esto por no hablar en detalle (que se hará en el apartado de denegación de servicio) de que el atacante puede «volver loca» a la red, implantado rutas falsas desde su «supuesto» encaminador. Llegados a este punto, hay que definir, para seguir adelante, lo que se entiende por «spoofing» o suplantación: pretender ser «algo» o «alguien» que no se es. En realidad, usar una cuenta «crackeada» es una suplantación de personalidad. El caso más extendido de este tipo de técnicas es el conocido como IP spoofing, en el cual una máquina «suplanta» la dirección IP de otra (véase la figura 4.6). La intención resulta obvia: la máquina a la que se suplanta tiene disponible accesos (o relaciones de confianza), que están vetados para el atacante.

Figura 4.6. Esquema de un ataque de tipo IP spoofing.

113


Tales ataques suelen tener 3 objetivos: • Como parte de un ataque en el que, además, se dispone de un medio (sniffer, encaminador suplantado) para obtener todo 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 se verá, por ejemplo, el ataque Mitnick-Shimomura). • 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 encaminadores intermedios. Como se verá en el tema 8, es muy sencillo «parar» muchos de ellos sin más que colocar filtros en los encaminadores, siguiendo los criterios del RFC 2827, consistentes en no permitir que ningún usuario, de la red que se administra, envíe mensajes con una dirección IP fuente que no esté en el rango de direcciones de la red interna. Desafortunadamente, para acabar del todo, habría que conseguir que esto fuera así en todos los encaminadores de los proveedores de acceso a Internet, y, por ahora, parece muy complicado. Otra suplantación que se puede encontrar es la de DNS (Domain Name System), de la que se hablará en el siguiente apartado. 5. ATAQUES BASADOS EN VULNERABILIDADES DE LOS PROTOCOLOS DE RED Para que las comunicaciones de red sean posibles se han desarrollado una gran cantidad de protocolos que las hacen posibles. Muchos de estos protocolos se diseñaron hace años, cuando las redes de comunicación eran una tecnología incipiente, y sin tener en cuenta consideraciones de seguridad, el objetivo era que las comunicaciones funcionasen y en muchos casos nadie se paró a pensar que implicaciones de seguridad podrían llegar a tener estos protocolos. Como decimos, muchos de los protocolos de la pila TCP/IP están diseñados pensando en un ambiente «amigable», en el que no hay por qué esperar ningún tipo de actuación maliciosa o criminal. Tal es el caso del protocolo TFTP (Trivial File Transfer Protocol) que, como se sabe, permite

114


hacer copias de ficheros entre cliente y servidor, sin autenticación ninguna, con lo que cualquiera que sepa en qué dirección IP hay un servidor tftp puede, con suma facilidad, conseguir una copia de los ficheros almacenados en el servidor (habitualmente, versiones de sistemas operativos de conmutadores o encaminadores, o ficheros de configuración de tales dispositivos o de cortafuegos) y puede, también, «poner» sus propios ficheros, con lo que esto puede simplificar de conocimiento, y posible alteración, de la estructura administrativa de la red. Otro protocolo que tampoco exige autenticación es SMTP (Simple Mail Transfer Protocol), lo que permite, conociendo el lenguaje interno del protocolo, enviar un mensaje de correo electró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. Esto no solo se puede utilizar para «hacerse pasar por otro», pidiendo que se conteste a una dirección real del atacante, sino que sirve, de la misma manera, para hacer un ataque con un objetivo intimidatorio o, simplemente, de «tomadura de pelo». Realmente, para hacer el ataque solo es necesario un cliente Telnet, pedir que se conecte al puerto 25, que es el puerto por defecto del protocolo SMTP y conocer las primitivas más relevantes del protocolo (HELO, MAIL FROM, etc). Así sería un ataque desde un cliente Telnet: $ telnet servidor-smtp.com 25 aquí habría un texto de presentación del servidor, indicando nombre y versión HELO satanas.cadiz.com Å presentación de qué dominio viene el mensaje aquí se obtiene un mensaje de OK MAIL FROM:[email protected]Å la identificación «falsa» otro mensaje de Sender OK RCPT TO:mailto:[email protected]Å dirección correcta del receptor del correo Otro mensaje de Recipient OK DATA Aquí se escribiría el mensaje que se quiere enviar, acabándolo con un carácter «.» en una línea . otro mensaje de DATA OK QUIT $

115


Realmente, es muy sencillo y da una buena idea de la relevancia de trabajar o no con autenticación sobre SMTP. Si no se hace (como por otro lado, es lo general), se está expuesto a recibir correo electrónico, sin saber muy bien quién lo envía. Por otro lado, al no pedir ningún tipo de autenticación para el envío de correos electrónicos, el servidor SMTP puede ser utilizado por un atacante para el envío masivo de correos electrónicos no deseados (SPAM) desde el servidor, apareciendo este como el remitente y por tanto origen de dichos correos no deseados. Es recomendable por tanto configurar el servidor de correo para denegar el reenvío de correos electrónicos a cuentas externas cuando dichos correos no provengan de un usuario autenticado y autorizado para ello. En el apartado anterior se ha hecho referencia a los «engaños» a encaminadores, variando su tabla de encaminamiento, mediante mensajes falsos de actualización de rutas, aprovechándose de la falta de configuración de la autenticación de los protocolos de encaminamiento como OSPF o EIGRP. Hay otros protocolos de encaminamiento, como RIP (Routing Internet Protocol) o IGRP (Internet Gateway Routing Protocol), que no disponen de ningún método de autenticación, siendo especialmente sencillo realizar las mismas operaciones citadas antes, y obligando, muy seriamente, a plantearse en la política de seguridad de la red que lo mejor es no usar ninguno de ellos. Otra manera de «engañar» a un encaminador (o a un servidor) y hacerle que envíe sus mensajes a través de rutas diferentes de las correctas es generar mensajes de 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. La base de estos ataques es la misma que en el caso anterior: la falta de autenticación entre el receptor y el emisor del mensaje ICMP. 5.1. Ataques Man-in-the-Middle Entre las técnicas de ataque que aprovechan las vulnerabilidades de los protocolos de red encontramos la familia de ataques Man-in-the-Middle («hombre en el medio»). 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.

116


Entre este tipo de ataques encontramos los ataques de suplantación de un servidor DNS, lo que se conoce como DNS Spoofing. Dado que DNS es un servicio que tampoco requiere autenticación, cuando un terminal envía un mensaje de traducción al sistema, este no comprueba quien 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 corresponde al servicio que el cliente está solicitando sino la del propio atacante, de manera que todas las comunicaciones entre el terminal y el servicio suplantado tendrán lugar a través del atacante. Dentro de una LAN las diferentes máquinas conectadas a la misma necesitan saber la dirección MAC de los otros equipos con los que se desean conectar. Para ello hacen uso del protocolo ARP (Address Resolution Protocol), que permite obtener la dirección MAC correspondiente a una determinada dirección IP. Para ello se envía un paquetes de solicitud ARP broadcast que contiene la dirección IP por la que se pregunta y se esperará a que la maquina con dicha dirección IP le envíe un paquetes de respuesta ARP indicando que dirección MAC corresponde a su dirección IP. El protocolo ARP, al igual que los vistos anteriormente no tiene ningún mecanismo de autenticación. Un atacante puede interceptar 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. Si el atacante intercepta tanto la petición del cliente solicitando la MAC del servidor, como la petición del servidor cuando este solicita la MAC del cliente, y a ambos les proporciona su propia dirección MAC como la dirección MAC del interlocutor que cada uno de ellos busca, los paquetes que el cliente quiera enviar al servidor los estará enviando al atacante, el cual podrá retransmitirlos, interceptarlos o incluso manipularlos. Igualmente los paquetes que el servidor envíe al cliente pasarán también a través del atacante. Esta técnica es conocida como ARP Spoofing, la figura 4.7 muestra el funcionamiento de este tipo de ataques. Otro protocolo objeto de ataques tipo Man-in-the-Middle es el protocolo DHCP (Dynamic Host Configuration Protocol), que permite a un equipo conectado a una red obtener la información necesaria para configurar su conexión IP a dicha red. Cuando el equipo se conecte a la red lanzará una

117


Figura 4.7. Funcionamiento de un ataque ARP Spoofing.

petición DHCP broadcast solicitando a cualquier servidor DHCP de la red una dirección IP que utilizar así como las direcciones IP de la puerta de enlace y servidor DNS de la red. Un atacante puede establecer un servidor DHCP falso (lo que se conoce como un 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, consiguiendo de esta forma que todo el tráfico del cliente se encamine a través de él. La figura 4.8 muestra el esquema de funcionamiento de este tipo de ataques.

Figura 4.8. Funcionamiento de un ataque Rogue DHCP.

118


6. ATAQUES BASADOS EN VULNERABILIDADES DE SOFTWARE En esta sección se estudian los ataques que se aprovechan de que las características de uso de algunas aplicaciones, es decir, el para qué están diseñadas, se convierte en vulnerabilidades. A menos que estas aplicaciones realicen un gran esfuerzo en el chequeo de los datos de entrada (como es en el caso de Java, aún con problemas), tales características nuevas se pueden usar para, a veces sin intención, incluso sin saberlo el usuario que realiza el ataque, modificar la información del equipo atacado. Es el caso, por ejemplo, de las macros de arranque de algunas aplicaciones, que permiten realizar modificaciones de ficheros y/o modificar la propia aplicación, para, incluso, auto replicarse, como en el caso de los virus macro de Microsoft Word. El lenguaje de programación de Postscript tiene una serie de primitivas, que permiten que, al arrancar el «visor» de postscript, se busquen ficheros, para modificarlos o borrarlos. Los applets de ActiveX se pueden descargar en el ordenador de un cliente, con muy poca seguridad, de forma que, al ejecutarse, realicen tareas no deseadas. Por ejemplo, cambiar transacciones financieras (si el ordenador dispone de tal posibilidad), transfiriendo dinero donde no debería ir. Se podría llamar «efecto autoplay» a este conjunto de situaciones, recordando otra más, 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, lo que ha provocado todo tipo de situaciones desagradables a los propietarios de los equipos en donde se leen tales dispositivos, preparados con el software de ataque. Siguiendo con este tipo de ataques, basados en vulnerabilidades por diseño de software, hay que comentar el asunto de los cookies. Básicamente, un cookie es un pequeño trozo de datos que un servidor web le da a un navegador. Éste, a su vez, lo almacena en el equipo del usuario y se lo devuelve al servidor, cuando el navegador vuelve a conectarse con el servidor. Sirven para realizar tareas muy útiles, pero, tambié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» como navegador de Internet y, también, para descubrir la identidad de un usuario concreto.

119


Para acabar este tipo de vulnerabilidades hay que hablar un poco de Java, quizás el único lenguaje de programación diseñado específicamente para código móvil y con una estructura de seguridad en su diseño. Aun así, últimamente ha sido una preocupación constante para los analistas de seguridad dada la gran cantidad de vulnerabilidades detectadas, que Oracle trata de parchear con sus actualizaciones. Se ha de abordar ahora las vulnerabilidades provocadas por una mala implementación de protocolos y aplicaciones, y sus ataques asociados. Quizás la más conocida, famosa y persistente es la que se denomina buffer overflow o «desbordamiento de memoria». Puede provocar ataques de 2 tipos diferentes: • Ataques de tipo denegación de servicio, tratados más adelante en este mismo tema. • Ataques para obtener acceso a un sistema. Estos últimos, que pueden causar un gravísimo problema por dejar «abierto» el sistema son los que se tratan aquí. Tienen que ver con variables del programa, que no se han chequeado correctamente, ni su longitud ni su tipo de datos. El atacante «coloca» (o envía por la red) una secuencia (string) de bytes mayor que el espacio de memoria reservado para la variable, sobrescribiendo en las siguientes posiciones de memoria, como en la figura 4.9.

Figura 4.9. Ataque de desbordamiento de memoria.

En tales posiciones, a menudo, están los valores de punteros a la pila, que indican por qué parte del programa hay que continuar la ejecución. Adecuando, cuidadosamente, los bytes de información de entrada, el ata-

120


cante puede redirigir al programa para que ejecute las instrucciones embebidas, previamente, en los datos de entrada. Es decir, el atacante consigue que el programa ejecute su propio código. A tales datos suele denominárseles como datos maliciosos. Quizás el más famoso, y estudiado, es el usado por el worm de Morris, que provocó, en 1988, que el 10% de Internet (alrededor de 6.000 servidores, entonces) dejarán de funcionar. Explotaba un bug del programa fingerd de UNIX, que, simplemente, devuelve la identidad de un usuario; era (y es) un programa «benigno», pero tenía (afortunadamente ya no) un bug, que consistía en que no limitaba el tamaño de los datos de entrada de petición de identidad. Si se usaban tamaños mayores de 512 bytes, desbordaba la memoria. Morris escribió una «entrada» de datos, que le permitía a su programa ejecutarse como root e instalarse en la máquina atacada. Lo que hace esta historia, ya sobrepasada, más descorazonadora, es el hecho de que, desde entonces, los ataques debidos a este tipo de problemas no han hecho sino aumentar mucho. Cada año hay varios avisos del CERT o de fabricantes (Cisco, Sun, Nortel, HP, Microsoft, IBM, etc.) avisando de distintos problemas similares en sus productos. Otro tipo de ataques que se engloban dentro de los ataques por vulnerabilidades de software son las inyecciones de código SQL o SQL Injection (SQLi). Este tipo de ataques son especialmente utilizados para atacar aplicaciones web. El atacante trata de aprovechar los parámetros de entrada 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. El caso más sencillo de los ataques tipo SQLi lo encontramos en aquellos sitios web que no comprueban los valores introducidos en los formularios de autenticación. Normalmente, cuando un usuario trata de obtener acceso a una aplicación web, se le presentará con un formulario en el que debe introducir su usuario y contraseña. Con esa información la aplicación lanzará la siguiente consulta SQL: SELECT idusuarioformtabla_usuarios WHERE nombre_usuario = ‘$usuario’ and clave = ‘$clave’;

121


Un atacante podrá introducir las credenciales de acceso mostradas en la figura 4.10, «transformando» de esta manera la sentencia SQL que ejecuta el servidor.

Figura 4.10. Datos utilizados para hacer un ataque de inyección SQL.

Al procesar los parámetros la sentencia que realmente se ejecutará será: SELECT idusuarioformtabla_usuarios WHERE nombre_usuario = ‘Administrador’ and clave = ‘’ or ‘1’=’1’;

Dicha consulta hará que el atacante acceda al sistema, y que además lo haga con la cuenta del administrador y por tanto con privilegios completos. Esto es solo un ejemplo de lo que un atacante puede llegar a lograr por medio de estos ataques, un atacante puede usarlos para: • Saltarse restricciones de acceso. • Elevación de privilegios. • Extracción de información de la base de datos. • Conseguir la parada de sistema de gestión de la base de datos (esto se podría considerar un ataque de tipo denegación de servicio que se verán en el siguiente epígrafe). • Ejecución de comandos en el contexto del usuario de la base de datos dentro del servidor.

122


Bajo este mismo criterio de ataques por vulnerabilidades de software entrarían los problemas debidos a las llamadas «puertas falsas». Se conoce con este nombre a la parte del código solo conocido por sus fabricantes. Para entenderlo, hay que pensar que, raramente, se dispone del código fuente de las aplicaciones comerciales. Se tiene el ejecutable, pero nada más. Esto ha permitido (y permite) que haya opciones del software solo conocidas para quien lo ha construido. Habitualmente, es imposible reconocer este tipo de ataques, pues hablamos de algo de lo que no se conoce su existencia. Aprovechándose de esa circunstancia, Dennis Ritchie y Ken Thompson, creadores del sistema UNIX primitivo, estuvieron años disponiendo de una entrada, como administradores, a cualquier sistema UNIX, usando un comando del depurador de código dbx, solo conocido por ellos dos. La «puerta» se descubrió cuando, como consecuencia de una gran operación de compra de equipos VAX con sistema UNIX BSD, en los años 80 del siglo pasado, el departamento de estado de los EE.UU. realizó una auditoría completa (hay que pensar en el dinero empleado en tal operación, ¡mucho dinero!) del código del sistema operativo, comparando, línea a línea, el código fuente «en papel» con el código fuente en las máquinas y descubriendo código no documentado. 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, aun así, hay que remarcar dos aspectos importantes: • La mayor parte del software que se utiliza (alrededor del 80% por lo menos) no está incluido en ese movimiento, con lo que la situación de «oscurantismo» es tal como la comentada. • Incluso en el caso del resto del software es difícil asegurar que no existen tales puertas, hasta que alguien las detecta. El usuario normal (es decir, casi todo el mundo) usa el software, no lo analiza en busca de problemas. Ésta es una tarea de programadores únicamente. No se podría acabar este apartado sin decir que, además, el software es cada vez más complejo, con una infinidad de dependencias entre módulos que hacen que, aun siendo suficientemente seguros cada uno de los módulos individuales, no se pueda asegurar lo mismo del conjunto como unidad. En este sentido, aplicaciones extensas y complejas, como el programa Sendmail de correo electrónico de UNIX, el servidor web Internet Information Server de Windows o cualquiera de los sistemas operativos modernos

123


de hoy en día, no dejan de tener bugs del tipo citado, que hacen que la vigilancia, en la política de seguridad, sea cada vez más relevante. Siguiendo estimaciones de la Universidad de Carnegie Mellow, puede afirmarse que, en cada mil líneas de código, hay entre 5 y 15 bugs. La mayoría son simples, no afectan al rendimiento y no se notan nunca, pero todos pueden poner en peligro la seguridad. Se suele pensar que, al ser anunciados los bugs de seguridad, junto con su correspondiente «parche», no hay más que aplicar el parche. Para empezar, la mayor parte de las veces, el fabricante que anuncia el problema, y la solución, no es el que la ha descubierto. Reacciona frente al problema, pero ha habido una ventana de vulnerabilidad entre el momento en que se descubre el problema y el momento en que se anuncia. Esta ventana, en realidad, es mayor, pues la aplicación del parche, aún conocido, no es automática. Hay más cosas que hacer, así que, aunque los parches estén disponibles, la vulnerabilidad persiste. Hay que tener en cuenta, además, que una vez se conoce una vulnerabilidad hay atacantes que construyen pequeños programas conocidos como exploits que tratan de aprovechar dicha vulnerabilidad en su beneficio. Dichos programas se suelen propagar a través de la red hasta el punto de que prácticamente cualquiera, sin grandes conocimientos informáticos, puede ser capaz de aprovechar dicha vulnerabilidad simplemente ejecutando el exploit que ha creado un atacante experimentado. De los exploits, los realmente peligrosos son los conocidos como exploits de día 0 (0-day-exploits). Este término se utiliza para referirse a exploits que atacan vulnerabilidades todavía no reportadas o conocidas por los analistas de seguridad, lo que hace que el ataque realizado gracias al exploit sea muy difícil de detectar y detener. Se puede leer que, si se usaran las últimas versiones de cada sistema y aplicación, se evitarían el 99% de los ataques. Ésta es una buena razón para decir lo buenas herramientas que son los analizadores de vulnerabilidades, pero tanto para los que defienden como para los que atacan. Realmente, la situación es peor: se instala la versión 1.0 de un software, pasan los meses o años, se reportan cientos de bugs, con sus parches, y llega la versión 2.0. La versión 2.0 es más extensa, tiene nuevas características y mucho código nuevo, lo que implica muchos bugs nuevos.

124


7. ATAQUES DE DENEGACIÓN DE SERVICIO (DOS) Estos ataques, generalmente bastante destructivos, conocidos en inglés por sus siglas Denial Of Service, tienen como objetivo que se pierda el acceso a un recurso. No están dirigidos a obtener ningún acceso no autorizado, sino a no permitir el uso de un recurso concreto, sea éste un servidor, un encaminador, un conmutador o una red. 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, desde los más simples a los más sofisticados, 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», quizás los más típicos. • 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 como causa última de algunos ataques DOS. En ese sentido, se puede hablar, por ejemplo, de los ping floods, consistentes en enviar muchos más mensajes ICMP de los que el host destino (o la red destino) puede gestionar normalmente. Existen, para ello, aplicaciones especialmente diseñadas como el fping, que envía mensajes ICMP a la velocidad máxima que la tarjeta de red del equipo pueda aguantar. 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. También se pueden utilizar peculiaridades del protocolo de transporte TCP como herramientas de ataque. En este sentido, sobresalen ataques como los de las aplicaciones land, en las que se envía un paquete TCP con los puertos y direcciones IP modificados con los mismos valores, lo

125


que hace creer al equipo víctima, que está hablando consigo mismo, hasta que esta situación provoca una sobrecarga en las tablas internas de IP, TCP o ambos. 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 solapan, provocando un gran uso de recursos (en vano) para tratar de «arreglar» tales fragmentos. Esto deja, en el mejor de los casos, en rendimiento muy bajo al proceso que controle IP en el equipo atacado. Dentro de los ataques DOS no es pequeño, además de especialmente virulento, el subtipo de los provocados por malas implementaciones de aplicaciones o protocolos. Quizás el más famoso, que afectó a equipos Windows NT y Solaris entre otros, es el ping de la muerte. No es más que un caso especial de los ya citados ataques por desbordamiento de memoria, en el cual basta con enviar mensajes ICMP de tipo ping con una longitud de datos del ping mayor que 65510 bytes. Esto provoca, en estos casos, la sobre-escritura en posiciones de memoria ocupadas por el sistema operativo, haciendo, en la mayoría de los casos, que el equipo sufra un crash y deje de funcionar. Afortunadamente, hay una actualización para cada sistema en el que se ha conocido el problema. Otro ejemplo sería un ataque «Out Of Band (OOB) data crash», en el que el atacante envía un paquete TCP con el bit Urgent Pointer a 1, el ordenador víctima no lo puede gestionar correctamente y el equipo deja de funcionar y se reinicia. También entraría en esta categoría la vulnerabilidad sufrida por todos los encaminadores de Cisco con versión del sistema operativo inferior a la 12.0, en la que, si el encaminador tenía habilitado el servidor web (situación habitual para hacer su gestión en remoto) y el atacante conocía una de las direcciones IP de la víctima, bastaba con abrir el navegador, indicar como URL a conectarse el siguiente: http://dirección-IP-encaminador/%%

y esperar. En segundos, el encaminador había sufrido un crash. Es importante señalar que continuamente, las principales compañías de dispositivos de red (Cisco, Juniper, Nortel, 3Com) y de sistemas (IBM,

126


HP, SUN, Microsoft) avisan de este tipo de vulnerabilidades. Hay que contar con ellas y no pensar en que se conocen todas, ni mucho menos. Otro tipo de ataques DOS muy extendido, al punto de que a veces se confunde DOS con únicamente este subtipo, es el de los SYNfloods. Para entenderlos correctamente, hay que recordar el mecanismo de «3 stephandshake» comentado en el tema anterior, 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, una tabla que lleva la cuenta de qué sesiones están “a medio hacer”». Solo cuando le llega al servidor un mensaje de aceptación del cliente (mensaje número 3 del «3 stephandshake»), se borra la entrada. Si a eso se le suma que tales entradas tienen un tiempo de vida relativamente grande y que la tabla de conexiones en estado embriónico tiene una longitud, en general, bastante corta, se entenderá el ataque. Se ilustra esta técnica de ataque en la figura 4.11.

Figura 4.11. Ataque de tipo SYN FLOOD TCP.

Habitualmente, basta con enviar 10 paquetes de tipo SYN (mensaje 1 de la creación de una sesión TCP) cada dos minutos a un servicio en la víctima, para bloquear el servicio. Cuando la tabla de conexiones semi-estable-

127


cidas se llena, ya no admite más entradas. La dirección IP fuente del ataque es una dirección suplantada (indicada como «NADIE» en la figura 4.11), de forma que las contestaciones del servidor (mensajes de tipo 2 de creación de sesión) se pierden. No va a haber ningún mensaje de tipo 3. Además, se puede seguir enviando mensajes de ataque al mismo puerto y a distintos puertos. Esto deja todo TCP deshabilitado, incapaz de funcionar normalmente para las conexiones legítimas y ha sido la fuente de desconexiones de redes enteras de Internet, en casos en los que la víctima era un encaminador de conexión a Internet. Una herramienta que permite este tipo de ataques (ni mucho menos única, pero muy fácil de usar) es el programa neptune, que funciona en muchas plataformas UNIX/LINUX. Es un ataque muy difícil de combatir, aunque, como se verá en el tema 9, hay soluciones, si tenemos entre el atacante y la víctima un cortafuegos, sofisticado, suficientemente bien configurado. Como final de este apartado, se va a explicar qué se conoce como ataques DOS distribuidos. Es sencillo: se trata de ataques DOS como los ya citados, pero que no tienen una única fuente del ataque, sino cientos o miles.

Figura 4.12. Esquema de un típico ataque DOS distribuido.

128


En estos ataques (figura 4.12), primero se «infectan» cientos (o miles) de ordenadores inseguros (algo relativamente fácil ahora, con cientos de miles de ordenadores conectados permanentemente a Internet vía ADSL, con una dirección IP estática), a los que, dependiendo del programa que se utilice, se denomina «zombies» o «agentes» del ataque. Tal «infección» consiste en un troyano, un programa de ataque, que se instala en los agentes. Es un programa «benigno» para ellos, no les hace ningún daño, pero los convierte en «soldados» a la espera de órdenes del atacante. Suele haber, además, dos tipos de «colaboradores»: los «handlers», desde los cuales se infecta a los agentes y los agentes, desde los cuales se ataca. Esta diferenciación hace aún más difícil la búsqueda hacia atrás de la dirección IP real, desde la cual se ha preparado, y lanzado, el ataque. Finalmente, el atacante los coordina, cuando lo considera necesario, para lanzar, desde todos ellos a la vez, el ataque sobre la víctima. Las defensas tradicionales (y muchas de las no tradicionales, de las que se hablará en el tema 9) no suelen funcionar con tal cantidad de mensajes de DOS y el ataque tiene éxito en muchos casos. Esta estructura, en la que hay una serie de ordenadores infectados bajo control externo, es lo que se conoce como BotNets, una de las amenazas más extendidas y peligrosas que se encuentra hoy en día en Internet. Hay mucha información, y muy completa, sobre algunos de los más estudiados (trin00, tribefloodnetwork, stacheldrath, mstream, etc.) en la web del CERT (http://www.cert.org). Existen herramientas que tratan de proteger y mitigar los efectos de los ataques de denegación de servicio distribuidos, pero en la mayor parte de los casos no pueden evitar el que afecte en alguna medida el rendimiento del sistema atacado. Un ejemplo de la peligrosidad de las BotNets y los ataques de denegación de servicio distribuido es el ataque que en marzo del 2013 sufrieron los servidores de SpamHaus, una organización sin ánimo de lucro dedicada a combatir el spam en Internet. El ataque utilizó una red de bots, con unos 1.000 ordenadores infectados y controlados por los atacantes y logró no solo inutilizar los servicios proporcionados por esta compañía, sino que además consiguió que Internet perdiera velocidad en distintas partes del mundo. Las soluciones reales contra este tipo de ataques pasarían por hacer seguros, por «vacunar», como si de una epidemia se tratara, todos los orde-

129


nadores individuales conectados a Internet. Pero, incluso en el caso de que los cortafuegos personales tuvieran un 99% de penetración del mercado y estuvieran instalados y configurados perfectamente, existirían todavía suficientes ordenadores individuales inseguros, como para probar con tal tipo de ataques. 8. ATAQUES POR MEDIO DE CÓDIGO MALICIOSO Otro tipo de ataque muy peligroso, y extendido, es el de los llamados de forma general virus informáticos. Tales ataques son de muy distinta naturaleza, pues no aprovechan todos los mismos problemas. Unos pueden aprovecharse de vulnerabilidades de aplicaciones concretas (como se vio en el apartado dedicado a los ataques basados en vulnerabilidades de software), para obtener información o para dejar un troyano, del que luego se hablará. Otros pueden tener como objetivo, simplemente, hacer inoperativo un sistema, una red o una aplicación. Pero ¿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: • Sector de arranque (o arranque maestro): Estos se alojan en el sector del disco que se carga al encender el ordenador; fueron los primeros virus que se desarrollaron y si tienen capacidades «stealth», pueden ocultarse de programas antivirus ya que es el primer código que se ejecuta en el ordenador. • Infectan archivos: Estos se alojan en ficheros del sistema, que pueden ser programas ejecutables, o bien en archivos de datos como scripts (secuencias de comandos que se ejecutan por algún intérprete en alguna aplicación). Tal es el caso de los virus de macro. • De propagación automática desde el receptor: Empezaron a aparecer a mediados del año 2001. Aprovechan malas funcionalidades en los sistemas de correo electrónico para expandirse como «gusanos» («worms») y atacar a todos los ordenadores correspondientes a los usuarios cuya dirección de correo electrónico aparece en las listas del receptor del ataque. El ataque se ejecuta cuando, al llegarnos un

130


mensaje de correo electrónico, abrimos el fichero adjunto al texto. Entre los que se han hecho, tristemente, más famosos se debe citar al Code-Red y al NIMDA. No se va a hacer una exposición muy detallada, debido a la extensión de los tipos de ataques de los que se debe de hablar. Además, sería inútil tratar de ser exhaustivos, pues todos los meses aparecen miles nuevos. Este tipo de amenazas tienen muchas veces un gran éxito por la mala (o nula) configuración de los programas antivirus. Como se remarcará en los temas 5 y 6, se ha de tener un antivirus instalado en cada equipo, actualizado de manera periódica, pero permanente, y el personal de seguridad ha de estar al tanto de todas las «novedades». Si esto no se hace así, es solo cuestión de tiempo que se reciba un «regalito», por vía física (un CD, un diskette un pendrive) o por un correo electrónico y que, además, se expanda por la organización, gracias al desprevenido receptor. Dependiendo de su forma de actuar, podemos definir varios tipos de software malicioso (o malware). Aunque normalmente a todos ellos se les conoce de forma genérica como virus informáticos, cada tipo tiene su nombre específico: • Virus: Por este término se conoce a aquel 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 infectado, por tanto, es necesaria la intervención del usuario para su propagación. La gravedad de la infección dependerá de lo que el virus esté programado para hacer, puede ser desde una simple molestia o puede llegar a dañar nuestros archivos, software, etc. Para su distribución será necesario que el usuario remita el archivo infectado a otras máquinas. • Gusanos (worms): Este tipo de software malicioso tiene la peculiaridad de que es capaz de replicarse a si mismo. Una vez que un gusano infecta un sistema creará copia de si mismo en la memoria del mismo y a su vez es se extenderá a otros equipos conectados a la misma red. La diferencia fundamental con los virus, por tanto, es que en este caso no se necesita la intervención del usuario para su propagación. Al igual que los virus, la gravedad de la infección por un gusano dependerá de lo que esté programado para hacer. En todo caso, un gusano siempre tendrá un efecto negativo en la red por el tráfico que

131


genera al replicarse, hasta tal punto que en algunos casos puede llegar a bloquear una red. El primer gusano fue el creado por Robert Morris en 1988, ya comentado en este mismo tema. Morris, en aquel momento estudiante de la universidad de Cornell, escribió este gusano sin intenciones maliciosas, el objeto del programa era tratar de determinar el tamaño de Internet. El programa utilizaba vulnerabilidades conocidas en los comandos de Unix finger y sendmail para propagarse de un equipo a otro. El error (o al menos el defiende que fue un error) que cometió Morris, fue que el programa no comprobaba cuando llegaba a una máquina si esta había sido infectada anteriormente, por lo que una máquina podía ser infectaba varias veces, y cada proceso adicional ralentizaba la máquina un poco, hasta el punto que tras varias infecciones la máquina quedaba inutilizada. Se estima que el gusano afecto a unas 6.000 máquinas Unix, lo que en aquel momento suponía el 10% de una incipiente Internet, creando un gran pánico y provocando la desconexión de gran parte de la red, hasta tal punto que el día 3 de noviembre de 1988 se conoce como el «Jueves Negro» debido a los problemas causados por este gusano. • Troyanos: Los famosos caballos de Troya, llamados así por la similitud con el famoso caballo de madera de la batalla de Troya, contada por Homero, son programas aparentemente útiles para el usuario pero que en realidad realizan una función completamente distinta. Tales «troyanos» pueden ser destructivos, poniéndose en marcha en un momento predeterminado por el propio programa o pueden ser no destructivos. En este último caso, se han observado dos tipos de comportamiento en alguno de los conocidos: — Programas con capacidad para buscar, y obtener, por sí solos, como servicios en Windows o daemons en UNIX (que son los procesos de sistema en UNIX), información relevante almacenada en ficheros, como el ratc.c. — Programas que «abren puertas», creando puertos servidor de Telnet o ssh, como portd.c. al que conectarse en remoto, o que «hibernan». Este tipo de troyanos son los que convierten a la máquina infectada en un bot perteneciente a una BotNet a la espera de ser activados en remoto en un ataque de tipo DDOS («Distributed Denial Of Service») como se ha visto en la sección anterior.

132


• Spyware o software espía: Este último tipo de software malicioso cuando infecta un sistema lo que hace es guarda información sobre la actividad del usuario sin que este lo sepa. La información que registran dependerá de su objetivo, puede ser desde la información de páginas web visitadas por el usuario hasta las contraseñas del usuario o sus datos de tarjetas de crédito por el simple método de registrar todas las teclas pulsadas (keyloggers). Habitualmente este tipo de software malicioso cambia la configuración del sistema causando reducción de la velocidad de la red, cambio de páginas por defecto, perdida de conexión a Internet, evitar que otros programas funcionen (especialmente software antivirus), etc. 9. ATAQUES A DISPOSITIVOS MÓVILES No se puede acabar el tema sin mencionar los ataques específicamente dirigidos a dispositivos móviles. Hasta hace unos años los dispositivos móviles, especialmente teléfonos, eran prácticamente inatacables, su software era un software sencillo y sin prácticamente funcionalidad, lo que hacía muy difícil elaborar ataques que los afectasen. Pero esto ha cambiado, la nueva generación de teléfonos inteligentes (smartphones) y tabletas, incorporan sistemas operativos que les proporcionan de gran funcionalidad, convirtiéndolos en realidad en pequeños ordenadores móviles. Ese 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 motivaciones de los ataques a este tipo de dispositivos son muy variadas: • En una gran cantidad de casos el objetivo es la obtención de nombres de usuario y contraseña de cuentas de correo electrónico, nombres de usuario y contraseña de cuentas de redes sociales o datos de conexión a cuentas bancarias. • En otros casos el objetivo es la obtención de los datos alojados en el terminal. Estos datos pueden ser números de teléfono y contacto que los atacantes pueden vender posteriormente a compañías de envío de publicidad. En este tipo de ataques los objetivos más comunes son

133


terminales empresariales que pueden contenten información comprometida que los atacantes pueden usar o vender posteriormente. • Es común encontrar ataques que lo que hacen es provocar que el terminal sea suscrito a servicios de mensajería de pago, con el consiguiente perjuicio económico para el usuario. • En ocasiones los terminales móviles son bloqueados o «secuestrados» por el atacante, el cual se ofrece a liberarlo por el pago de una determinada cantidad de dinero. • Por último, este tipo de dispositivos pueden ser también objeto de software malicioso que los convierta en bots pertenecientes a una BotNet. Las técnicas utilizadas para atacar dispositivos móviles son las mismas que las utilizadas para atacar cualquier otro tipo dispositivo, y por tanto son las mismas que se han visto a lo largo de este tema. El hecho de que estos dispositivos estén gran parte del tiempo fuera de la organización, y por tanto fuera de la protección de algunas de las medidas de seguridad implementadas por la misa, hacen que sean más vulnerables a dichos ataques. Algunas de las técnicas de ataque más usadas: • Falsas aplicaciones de redes sociales. Troyanos que aparentemente proporcionan al usuario funcionalidad para interactuar con las redes sociales cuando lo que pretenden es obtener sus credenciales de acceso a la misma así como la información publicada. • Aplicaciones que contienen código malicioso. Además de Troyanos, las aplicaciones que se pueden instalar en este tipo de terminales pueden contener otros tipos de software malicioso. Pese a que las tiendas de aplicaciones tratan de revisar las aplicaciones en ellas publicadas tratando de evitar precisamente que se publiquen aplicaciones con funcionalidad oculta, no pueden evitar que alguna se cuele y sea publicada. • Mucho software malicioso creado para dispositivos móviles utiliza el hecho de que normalmente los usuarios no leen los permisos que garantizan a las aplicaciones. Cuando una aplicación es instalada en un teléfono inteligente, se presenta una lista de los privilegios que se deben conceder a dicha aplicación para su funcionamiento (acceso

134


a los contactos, posibilidad de hacer llamadas, acceso a la posición GPS…). Los usuarios deberían revisar dicha lista de permisos y no instalar aquellas aplicaciones que soliciten permisos que no deberían necesitar para realizar su funcionalidad aparente. Los atacantes usan por tanto la costumbre de los usuarios de aceptar sin leer esa lista de permisos. Este tipo de ataques pertenecerían a la rama de la ingeniería social. • Otro de los métodos de ataque favoritos a dispositivos móviles 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 o tokens de acceso a cuentas de correo o redes sociales, datos sobre los usuarios, contenido de sus comunicaciones, etc. • En el apartado 4 de este tema se ha explicado como un atacante puede crear un falso punto de acceso que suplante al punto de acceso de una wifi abierta que el usuario use habitualmente para hacer un ataque de tipo Man-in-the-Middle. Gracias a esta técnica el atacante no solo consigue que todas las comunicaciones originadas por el cliente pasen a través de él, sino que puede llevar el ataque más lejos y aprovechar para instalar código malicioso en el terminal de forma que pueda utilizarlo como parte de una BotNet o como una puerta de acceso a la organización que desea atacar cuando el dispositivo móvil se conecte a la red corporativa de la misma. A la vista de la nueva dimensión que toman los ataques cuando su objetivo son dispositivos móviles, es más sencillo entender por qué este tipo de terminales son, cada vez más, una mayor fuente de preocupación para los responsables de seguridad de las organizaciones.

135


10. CONOCIMIENTOS Y COMPETENCIAS ADQUIRIDAS Como se ha visto, éste de las redes puede ser un mundo realmente peligroso. El objetivo del tema ha sido presentar al lector los riesgos a los que se enfrentan los responsables de seguridad de los sistemas informáticos. El lector a lo largo de la lectura del tema: • Ha podido tomar conciencia de la gran cantidad de ataques que pueden sufrir los diferentes dispositivos de las redes. • Ha podido conocer los diferentes tipos y técnicas de ataque. • Ha podido conocer ejemplos de cada una de las técnicas. • Ha sido consciente de la necesidad de establecer una política de seguridad que trate de confrontar los problemas de seguridad expuestos a lo largo del tema. Finalmente, un comentario importante: casi todos los ataques tienen su correspondiente defensa a utilizar. El marco de una política de seguridad correcta debe indicar cómo utilizar, configurar y mantener, cada una de esas defensas.

11. BIBLIOGRAFÍA BEJTLICH, R. (2005): The Tao of Network Security Monitoring. Ed. Addison Wesley. RANDO E.; ALONSO, C. (2012): Hacking de Aplicaciones Web: SQL Injection. Ed. Informática 64. TRONCOSO, R.; RAMÍRED, F. J. (2013): Microhistorias: anécdotas y curiosidades de la Informática. Ed. Informática 64. INTYPEDIA, INFORMATION SECURITY ENCYCLOPEDIA, enciclopedia gratuita en video sobre seguridad informática, accesible en http://www.criptored. upm.es/intypedia

136


UN

INFORMÁTICO EN EL LADO DEL MAL,

blog sobre seguridad informática de Chema Alonso, reputado consultor de seguridad, en el que se pueden encontrar gran cantidad de artículos de divulgación sobre seguridad informática, descargable desde http://www.elladodelmal.com/

12. PALABRAS CLAVE Ataque, BotNet, Buffer Overflow,DoS, DDoS,Exploit, Gusano, Ingenieria Social, Malware, Man-in-the-Middle, Metadatos, Metaexploit, Nmap, PuertaTrasera, Rogue AP, Sniffers, Spoofing, SQL Injection, Troyano, Virus, Wireshark. 13. EJERCICIOS RESUELTOS 1. Los escuchadores de paquetes permiten interceptar todo el tráfico que viaja por la red escuchada. a) Verdadero. El atacante solo tiene que lanzar el programa y capturará toda la información que viaje por la red. b) Verdadero. Para ello el atacante deberá conectarse a un conmutador (switch) de red y lanzar el programa de captura de paquetes. c) Verdadero. Para ello el atacante deberá conectarse a un concentrador (hub) de la red y lanzar el programa de captura de paquetes. d) Falso. No es posible capturar todos los paquetes de una red. Solución: c. 2. ¿En qué consiste un ataque de tipo Rogue AP? a) El atacante suplanta la dirección IP de un punto de acceso para confundir a los usuarios y hacer que envíen sus comunicaciones a través de el. b) El atacante suplanta el SSID de un punto de acceso para confundir a los usuarios y hacer que envíen sus comunicaciones a través de el. c) El atacante suplanta la dirección MAC de un punto de acceso para confundir a los usuarios y hacer que envíen sus comunicaciones a través de el. d) Ninguna de las anteriores. Solución: b.

137


3. ¿Cuál de los siguientes ataques NO pertenece a los ataques de tipo Manin-the-Middle? a) b) c) d)

Ping flood. ARP Spoofing. Rogue DHCP. DNS Spoofing.

Solución: a. 4. ¿En qué consisten los ataques de tipo SQL Injection? a) El atacante suplanta un servidor SQL para tratar de confundir al usuario para que le envíe a el las consultas SQL. b) El atacante desborda la memoria de la aplicación por medio de consultas SQL. c) El atacante introduce consultas SQL completas dentro de los parámetros de la aplicación web. d) El atacante trata de manipular la consulta SQL que se ejecuta en la aplicación por medio de los parámetros de entrada de la misma. Solución: d. 5. ¿Cuál de las siguientes técnicas de ataque trata de dejar inutilizados los servicios atacados?: a) b) c) d)

Ping flood. Ataques distribuidos de denegación de servicio (DDoS). Ataques de Denegación de servicio (DOS). Todos los anteriores.

Solución: d.

14. EJERCICIOS DE AUTOEVALUACIÓN 1. La utilización de cualquier protocolo de encaminamiento en una red es suficientemente seguro. a) Falso, pues solo algunos permiten autenticación (OSPF, EIGRP) y, aún así, ésta debe estar correctamente configurada. b) Verdadero, pues hoy en día todos encriptan sus mensajes.

138


c) Verdadero, siempre que sean protocolos de nivel de aplicación. d) Falso, solo es verdad para RIP e IGRP. 2. Los bugs de aplicación no son un problema real de seguridad, ya que son comunicados siempre primero a los usuarios. a) b) c) d)

Verdadero, si no fuera así no les compraría nadie. Verdadero, pues tienen sus equipos de seguridad siempre trabajando. Falso, habitualmente uno se entera con bastante tiempo de retraso. Falso, es imposible que los detecten.

3. ¿En qué se basa un ataque de tipo TCP SYN FLOOD? a) En el algoritmo de Dïjkstra aplicado al protocolo TCP. b) En la obtención de mensajes SYN mediante desbordamientos de memoria. c) En poder hacer correctamente un reset a sesiones TCP establecidas. d) En la existencia de una tabla, de dimensión finita, de sesiones TCP en estado embriónico. 4. ¿En qué se basa un taque de tipo desbordamiento de memoria? a) En la escasez de memoria del equipo atacado. b) En la escasez de memoria de la aplicación atacada. c) En que no se chequea, desde la aplicación, ni la longitud de los datos de entrada de una variable, ni su tamaño. d) En que no se chequea, desde la aplicación, la conexión IP creada con el equipo del atacante. 5. Con el término BotNet se hace referencia a:. a) Una estructura en la que un atacante, a través de una serie de agentes, controlan cientos o miles de equipos «zombies» infectados con un software que los pone bajo el control de dichos agentes. b) Nos referimos a un ataque de tipo Man-in-the-Middle. c) Es un tipo de virus informático que infecta a un ordenador y lo pone bajo el control de un «agente». d) Ninguna de las anteriores.

139

Tema 5

Defensas básicas ante ataques

1. Introducción, orientaciones para el estudio y objetivos 2. Controles de acceso físico a sistemas 3. Controles de acceso lógico a sistemas 4. Otros controles simples de acceso a la información 5. Conocimientos y competencias adquiridas 6. Bibliografía 7. Palabras clave 8. Ejercicios resueltos 9. Ejercicios de autoevaluación

1. INTRODUCCIÓN, ORIENTACIONES PARA EL ESTUDIO Y OBJETIVOS Tal y como se verá en el siguiente tema, no puede haber ningún plan de seguridad, ninguna buena política de seguridad, que no tenga en cuenta los aspectos esenciales de los que se va a tratar en este tema. Mucho antes de introducir otras medidas de seguridad más sofisticadas (cortafuegos, criptografía en su uso en redes), hay que plantearse medidas básicas. Tales medidas son fundamentales y, además, lo han sido históricamente, pues engloban la prevención frente a situaciones que podían ser peligrosas, incluso cuando los ordenadores y sistemas no formaban redes. De esta manera se puede caracterizar, por ejemplo, la seguridad física de los sistemas. Engloba todo tipo de situaciones que pueden suceder antes de que se esté tecleando delante del ordenador, desde el sistema de alarma conectado a la policía que avisa, en mitad de la noche, 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. Habitualmente, es un aspecto de la seguridad que se tiene muy poco en cuenta, pero es realmente importante, más hoy en día que tanto los móviles como las tabletas son dispositivos que llevamos encima de manera permanente. Por otro lado, 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. Todo usuario de un sistema debe disponer de una «cuenta» en dicho sistema. Si se dice que el trabajo es en un entorno de red, es muy posible que el control de acceso de ese usuario se haga en una máquina físicamente distinta a la que está usando para conectarse, pero no deja de ser un control de acceso lógico. Es, además, especialmente importante si se tiene en cuen-

143


ta que tal control de acceso, en un entorno distribuido, determina qué aplicaciones se pueden usar en el entorno y a qué datos se tiene acceso. Hay, actualmente, diferentes formas de «tener» una cuenta legalmente, uniendo la identificación del usuario con distintos métodos de autenticación, que hay que conocer para poder evaluar cuál es el más idóneo en cada situación. En el mundo actual, además, 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 arquitecturas 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 protocolos AAA, como el RADIUS o el TACACS/+, que se deben conocer, haciendo más sencilla la elección en cada caso. De una u otra manera, estos mecanismos AAA están cada vez más extendidos, uniéndose en muchas situaciones (como en redes privadas virtuales) con sistemas de autenticación extendida más sofisticados. Otro aspecto básico, que debe formar parte de cualquier política de seguridad, es el tratamiento de seguridad que se le da a los propios datos. Hay que tener en cuenta la seguridad implícita de los distintos sistemas de ficheros, ya que no todos proporcionan una seguridad correcta para depende qué tipos de datos. Hay sistemas de ficheros con un 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 para información especialmente sensible. Finalmente, se va a analizar la seguridad que se tiene en cuenta, y la que debería tenerse, para los propios medios de almacenamiento en que residen los datos, un asunto que raramente se estudia y que puede ser clave de muchos problemas, a la vez que es sencillo de tratar con los medios actuales. En realidad, es otro aspecto de la seguridad física que, no obstante, se puede tratar de manera independiente. Es importante señalar, antes de empezar, que estas medidas, por más que sean básicas y que parezcan de uso evidente en cualquier sistema y red, no son tan evidentes. Se pueden evitar muchos ataques, muy fácilmente, disponiendo de un buen plan de seguridad física y de una buena política de control de accesos. En el tema 4 se ha visto cómo una mala administración de estas herramientas deja abierto el campo a los ataques, pero, para poder ad-

144

DEFENSAS BÁSICAS ANTE ATAQUES

ministrar bien cualquier sistema, se ha de conocer, primero, de qué opciones se dispone y cómo ha de hacerse una correcta implementación de cada una de ellas. Tales defensas básicas son, así pues, fundamentales. El objetivo de este tema es, por tanto, presentar al lector todas estas medidas básicas que deben ser tenidas en cuenta en cualquier política de seguridad. 2. CONTROLES DE ACCESO FÍSICO A SISTEMAS La seguridad física es una de las formas de seguridad más comúnmente olvidadas, debido a que los aspectos que engloba (amenazas, prácticas y tipos de protección) son diferentes dependiendo de cada organización. La seguridad física debe ser tenida en cuenta en cada sitio de una forma particular, no es algo que un vendedor de sistemas operativos pueda pre-instalar, no se puede descargar de Internet e instalar en el sitio. Precisamente por estas razones no se puede hacer una aproximación completa, pues la puesta en marcha será, inevitablemente, específica. Pero si se puede hacer un análisis de los elementos generales involucrados, para dar un punto de vista amplio de qué aspectos se han de tener en cuenta, junto con recomendaciones importantes, para intentar ayudar a formular un plan, una política de seguridad física, adecuada. Para saber hasta qué punto resulta importante, para una organización, la seguridad física se puede seguir la aproximación clásica de Simson Garfinkel, en su libro Practical UNIX & Internet Security, haciéndose 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 (aún uno momentáneo) 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?

145


La última pregunta será contestada en el tema 12, pero las otras establecen, claramente, una serie de posibles problemas relacionados con el uso no autorizado de un ordenador, para fines ilícitos dentro de una organización. Se trata, simplemente, de montar un perímetro de seguridad alrededor de las máquinas que se consideran vulnerables, bien porque lo son en sí mismas, porque su robo, su destrucción o su puesta fuera de servicio resulta grave para la organización, bien porque, desde ellas, se puede acceder fácilmente a otras que cumplen lo citado previamente. Este perímetro de seguridad debe estar aplicado especialmente sobre los servidores con información especialmente relevante, asegurando que solo las personas autorizadas disponen de un acceso físico directo a la máquina. De igual manera, aquellos conmutadores y encaminadores que contengan 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. Pero no solo los servidores deben estar protegidos por ese perímetro de seguridad, también los terminales de los usuarios deberán estar protegidos por dicho perímetro en mayor o menor medida. Esta protección mínima supone un reto especialmente difícil de cumplir para todos aquellos dispositivos móviles, como pueden ser ordenadores portátiles, pero especialmente es el caso de teléfonos móviles y tabletas. Los usuarios portan estos dispositivos tanto dentro como fuera de la organización, por lo que el control de acceso a los mismos es realmente complicado, especialmente en el caso de robo o pérdida. A este respecto han surgido una serie de utilidades que permiten bloquear o borrar los datos de aquellos terminales sustraídos o extraviados, permitiendo así cierto grado de protección. Aunque no sirvan más que como reglas generales, se enumeran algunas medidas típicas, aplicables dependiendo de la importancia de las máquinas dentro del perímetro: • Agrupar físicamente, en la medida de lo posible, las máquinas relevantes, en una habitación suficientemente segura, desde el punto de vista de la construcción. • Tales habitaciones no deben estar a la vista de cualquiera que visite la organización.

146


• Tales habitaciones deben estar protegidas mediante medidas, que serán más o menos drásticas, dependiendo del nivel de seguridad deseado. • Una de tales medidas puede ser la necesidad de disponer de una tarjeta identificativa para poder acceder a la habitación. • Otra podría ser la necesidad de identificarse en un control «humano», un guardia de seguridad, por ejemplo. • Tales medidas podrían combinarse, de manera que hubiera que identificarse ante el guardia primero y demostrar, después, que se es quien se dice ser también mediante la tarjeta. • Se podría controlar qué herramientas se lleva encima para entrar. En casos de problemas físicos se podría entrar con tales herramientas, en otros casos, estaría prohibida la entrada. Hay que pensar que se dispone de medios suficientes para poder imponer una política correcta de control de acceso lógico, que se ha estudiado y se está aplicando, pero es indudable que la vieja idea jerárquica de que a algunas estancias sólo puede acceder determinado personal es una ayuda más, a veces inestimable. Si alguien ha «robado» la contraseña del administrador de un sistema susceptible, pero tal administrador solo puede identificarse como tal desde la consola del equipo, y el atacante no tiene acceso físico a la consola, se habrá evitado parte del ataque, o se habrá hecho más difícil. Ésta es, al menos, la función principal de cualquier sistema físico de seguridad: hacerle más difícil al atacante el posible ataque. 3. CONTROL DE ACCESO LÓGICO A SISTEMAS Asumiendo que solo aquellos que tienen derecho a trabajar en un ordenador o dispositivo en general lo usan, el siguiente aspecto básico a considerar es el acceso lógico. Cualquier acceso de estas características está asociado con dos operaciones ya citadas, muy relacionadas con asuntos del día a día como las tarjetas de crédito. Tales operaciones son: • Identificación, mediante la que el usuario dice quién es. • Autenticación, mediante la que el usuario prueba que, realmente, lo es.

147


Una vez autenticado, el sistema de control de acceso impone qué puede hacer el usuario y qué no puede hacer. Hay que darse cuenta que, a veces, esto significa tener acceso a determinados ficheros e información, otras veces puede ser disponer de acceso completo a un servidor, otras veces será acceso al espacio web en un servidor web, a una cuenta de correo en un servidor de correo electrónico, etc. Lo realmente importante es que, para identificar al usuario, se necesita alguna medida de control de acceso. En realidad, el sistema de control de acceso debe hacer bien 2 cosas: • Debe permitir el acceso al usuario correctamente autenticado. • Debe impedir el acceso a los demás. Tal sistema debe ser suficientemente bueno como para permitir el acceso al usuario correcto y, a la vez, muy difícil de duplicar para 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 del usuario o de otra persona. • 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 autenticación puede hacerse: • En la base de datos de información local del sistema donde se conecta el usuario, por ejemplo /etc/passwd o /etc/shadow en Linux o UNIX o un fichero SAM en una máquina con Windows. • En una base de datos residente en una máquina «servidora de autenticación», por ejemplo en un servidor NIS+ en UNIX o en un controlador de dominio en el caso de Windows Server. • A través de un NAS (Network Access Server), dentro de una arquitectura AAA, caso que será analizado más tarde. 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.

148


• 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, es la más extendida. Al acceder a un sistema informático, se teclea un nombre de usuario y una contraseña, cuando se va a usar un cajero automático, se introduce la tarjeta personal y se teclea el PIN (Personal Identification Number), que no es otra cosa que una contraseña. En el tema anterior se ha citado ya la importancia que tiene, desde el punto de vista de la seguridad, disponer de una buena administración de las bases de datos de información de seguridad. No obstante, se va a hacer una enumeración de los puntos clave de esta correcta administración. Dependiendo del nivel de seguridad requerido, serán suficientes para cualquier instalación que desee un buen nivel de seguridad. 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, cuidando de elegir una versión de ssh que se conozca que no tiene vulnerabilidades. 2. No disponer de más de una cuenta privilegiada en cada máquina, típicamente root en el caso de sistemas UNIX o Linux o administrator en el caso de sistemas Windows. 3. En el caso de sistemas UNIX/LINUX, hacer únicamente uso de la cuenta root cuando sea necesario, trabajando, mientras, en una cuenta personal de usuario. Si el acceso es remoto, mediante ssh, acceder con una cuenta de usuario y, después, emplear el comando su, para «convertirse» en administrador de la máquina remota. 4. Si el sistema lo permite (así es en el caso de muchos LINUX, Tru64 UNIX, AIX y sistemas Windows Server), 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 contra una cuenta determinada, sin más que intentar el acceso, sabiendo que no se puede por no conocer la contraseña, un determinado número de veces.

149


5. Habilitar el cambio de contraseñas periódico y obligatorio, no permitiendo que un usuario disponga de la misma contraseña durante un cierto periodo, que dependerá de la política de seguridad aplicada al equipo concreto de que hablemos. Un periodo medio aceptable suele ser un mes. 6. No permitir repeticiones triviales de contraseñas, habilitando un histórico de las mismas que, hoy en día, es una herramienta normal de cualquier sistema operativo de servidor. 7. No permitir contraseñas triviales, que sean palabras de un diccionario o listas de caracteres ASCII (como AAAAAA). 8. Explicar a los usuarios las razones de la necesidad del cambio periódico de contraseña, así como de las restricciones a las posibles contraseñas, como parte de la política de seguridad de la organización. 9. Suele ser buena idea, siempre que los usuarios así lo entiendan y sepan gestionarla, usar, como contraseñas, acrónimos con caracteres numéricos y alfanuméricos combinados. Por ejemplo, una buena contraseña podría ser MqidvaCe12, que es el acrónimo de «Me quiero ir de vacaciones a Cádiz el 12». 10. Hacer el esfuerzo de no tener la misma contraseña en distintas máquinas o servicios, lo que debilita mucho la seguridad de todas las cuentas asociadas. Hay casos de contraseñas capturadas en el acceso de inocentes a sitios web, creados a propósito para este menester, por ejemplo sitios que contienen pornografía, o de apuestas, en los que el usuario desprevenido coloca la misma contraseña que utiliza para su vida laboral, obteniendo el atacante así, sin gran esfuerzo, la contraseña que necesitará para sus tareas. Dependiendo del tipo de atacante del que se quiera proteger, un sistema con contraseñas largas (al menos, 8 caracteres) y fuertes puede estar suficientemente asegurado. Pero esto está cambiando sin parar gracias a la ley de Moore (aumento progresivo de la potencia de cálculo de los ordenadores), que hace que las contraseñas fuertes de hoy sean débiles para mañana mismo. No obstante, 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 (tema 4). Esto se puede prevenir

150


asegurando los ficheros que contienen tal información. No es fácil en los sistemas de acceso muy general, pero es cuestión de cómo se implemente la política de seguridad al respecto. En sistemas UNIX/LINUX, se debe colocar tal información en un fichero /etc/shadow, del que solo el administrador tiene permiso de lectura, al contrario que el /etc/passwd tradicional, legible por cualquier usuario. Cualquier sistema UNIX/LINUX actual permite esta operación, si no es ya la norma, como en el caso de una instalación básica de Solaris o RedHat Linux. El fichero de contraseñas, en hash, de Windows Server, es un fichero que, siempre que se use NTFS como sistema de ficheros, está bien protegido 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. La idea no puede ser más sencilla: el usuario mismo es su autenticador. La voz le permite identificarse para entrar en su casa o un scan de su retina le permite el paso a las salas seguras de su oficina o la huella dactilar le permite acceder al ordenador o firmar sus mensajes de correo. En realidad, es la forma más antigua de identificación. En casi todas las aplicaciones biométricas, los datos (voz, retina, huella dactilar, etc.) se almacenan en una base de datos, de manera muy parecida al caso de las contraseñas. Además de las técnicas citadas (reconocimiento de voz, de retina o de huella dactilar), existen otras, algunas muy curiosas, relacionadas con la forma de la firma de cada persona; entre ellas se pueden destacar: • Reconocimiento de los detalles de la geometría de la mano. • Reconocimiento de los detalles de la geometría de la cara. • Scan del iris del ojo. • Reconocimiento de los detalles de la geometría, y otros aspectos, de la firma personal, como la presión sobre el lápiz, la velocidad de la firma, etc. Unas son más fiables que otras, la huella dactilar mucho más todavía que el reconocimiento de la cara, pero la tecnología va mejorando. Incluso

151


se plantean sistemas de autenticación que utilizan varias medidas biométricas para verificar la identidad del usuario. Parece un campo que solo puede mejorar, pero hay que utilizarlo con cuidado, funcionará bien sólo si el sistema verificador puede comprobar dos cosas distintas: • Que los datos biométricos recibidos vinieron de la persona correcta en el momento de la verificación. • Que tales datos coinciden con los datos «maestros» almacenados en el fichero de datos biométricos. Si no suceden ambos, el sistema puede ser muy inseguro. Se puede pensar que el sistema de acceso remoto a una organización exige la huella dactilar del usuario para permitir el acceso. El usuario pone su dedo en un lector en el teclado y el ordenador envía la huella dactilar digital al sistema remoto, que la comprueba y permite el acceso. El ataque simplemente consistiría en robar la huella dactilar del usuario y enviarla remotamente. La biometría no exige una certificación, como en el caso de la criptografía pública (como se verá más adelante), lo que la hace más fácil de usar y, a la vez, más vulnerable. A veces, además, los posibles fallos del programa de reconocimiento pueden traer aparejados otros problemas no tenidos en cuenta. Sólo a modo de ejemplo, se puede leer a Bruce Schneier en el número de Septiembre de 2002 de la revista The Atlantic, donde se estudia el caso de Identix (Minnesota), uno de las mayores compañías de reconocimiento por detalles del rostro. Identix dice que, como resultado de una serie de test independientes, puede afirmar que su software FaceIt tiene un 99,32% de éxito en el reconocimiento. FaceIt estaba en uso, en la fecha citada, en el aeropuerto de Boston y lo que sus test indican es que al comparar el rostro de un pasajero con el de una lista de terroristas buscados, sólo se equivoca el 0,68% de las veces (técnicamente se dice que tiene un 0,68% de falsos positivos). Si se aceptan los resultados de los test, y que las fotos de los terroristas son de buena calidad, esto quiere decir que, de los 25 millones de pasajeros que utilizan el aeropuerto de Boston al año, alrededor de 170.000 (el 0,68%) han sido mal identificados. Un sistema de reconocimiento que falle 500 veces al día puede ser, más que una gran ventaja, un gran problema, algo que se termine por ignorar, tal y como realmente sucedió.

152


Finalmente, la tercera forma tradicional de autenticación es algo que uno tiene, los sistemas de tarjetas conocidas como access tokens. La idea básica es, también, muy sencilla. Se inserta el token que se tiene en el sistema de control y el ordenador (o lo que sea a lo que se quiera acceder) lo verifica. El problema más serio es que tales tokens se pueden robar. Si alguien roba las llaves del domicilio de una persona, puede entrar en su casa. En realidad, el sistema no autentica a la persona, sino al token. Una solución ampliamente usada es combinar el token con una contraseña, algo muy parecido a una tarjeta de crédito. Otro problema de este tipo de soluciones es que el token se puede, también, copiar. Para determinado tipo de accesos remotos (explicados en más detalle más adelante en este tema) y algunos locales, este tipo de tokens necesita de algún tipo de «lector» asociado donde el usuario puede introducir el token. No obstante no en todos los casos es así, para los casos en los que no se dispone de un lector asociado se suelen utilizar dos métodos: • «Challenge/reply». El token es una mini calculadora, con un teclado numérico y una pantalla diminuta. Cuando el usuario quiere acceder, el sistema remoto le envía un «challenge». El usuario escribe el challenge en su token, que calcula la réplica apropiada, el usuario la escribe en el ordenador y se la envía al sistema remoto. El sistema remoto repite el cálculo, compara su resultado con el enviado y, si coinciden, el usuario es autenticado. Normalmente, se usa un cierto tipo de mecanismo de una sola vía, como los citados en el tema 14. De este tipo son las «tarjetas de coordenadas» que proporcionan algunos bancos a los usuarios para autenticar ciertas operaciones para las cuales la contraseña no es suficiente. Cuando el usuario solicita una operación de este tipo, el banco solicitará al usuario que le indique el valor que proporciona dicha tarjeta para unas coordenadas determinadas, si el resultado proporcionado por el usuario coincide con el esperado por el banco la operación se llevará acabo, en caso contrario quedará cancelada. • Un sistema basado en tiempo. El token es el mismo tipo de calculadora, pero sólo dispone de una pequeña pantalla. Los números en la

153


pantalla cambian regularmente, por ejemplo una vez por minuto. El sistema remoto le pide al usuario que escriba los números que ve en la pantalla. Si coinciden con lo esperado por el remoto, el usuario es autenticado. Los tokens de SecurID, por ejemplo, usan este método. Desde luego, previamente puede haber una petición de contraseña y alguna medida más auxiliar, pero estos son los métodos típicos. En realidad, el sistema es tan seguro como lo sea el token. Es bastante seguro, los problemas podrán aparecer en la red y en el servidor remoto de autenticación. Otro token muy conocido, y útil, es el que almacena una lista de contraseñas correctas, pero que, una vez usadas, pierden su validez, son los sistemas conocidos como de contraseña de un sólo uso, OTP, o «one-time passwords» en inglés. Si la lista se almacena de manera segura, el sistema es seguro. En el caso de acceso remoto a una red, ha de conocerse lo que se denomina sistemas AAA (Authentication, Authorization, Accounting), formados por una serie de componentes (Figura 5.1) que se enumeran a continuación: • El servidor de acceso a la red o NAS (Network Access Server), 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/ LINUX o Windows configurado como tal o un sistema especial diseñado únicamente como NAS. Es el «intermediario» entre el sistema desde el cual se pretende acceder y la red a la que se pretende acceder. Es el que recibe la petición de acceso remoto y puede, en algunos casos, conceder directamente la autenticación si está configurado de esa manera. • 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, sirviendo de lenguaje común para las peticiones de autenticación del NAS al servidor AAA y las contestaciones de éste al NAS. Los más extendidos, con diferencia, son RADIUS y TACACS/+.

154


Figura 5.1. Componentes de un sistema AAA de acceso remoto.

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, haciendo más compleja la administración, pero resultando la red más segura frente a accesos remotos. Si, por ejemplo, un NAS no puede comunicarse con su servidor AAA (por estar éste caído), podrá hacerlo con un servidor AAA secundario. Las siglas AAA tienen el siguiente significado: • Authentication: el NAS, con su propia base de datos, o, más habitualmente, mediante su comunicación RADIUS o TACACS/+ con el servidor AAA, autentica al usuario remoto. • Authorization: el NAS, prácticamente siempre mediante su comunicación con el servidor AAA, autoriza al usuario para diferentes tipos de operaciones, según la configuración para ese usuario en el servidor AAA. • Accounting: realmente es una función optativa, que permite, cuando el servidor AAA así lo permite, almacenar en el servidor AAA la información de quién ha hecho qué cosas, durante cuánto tiempo, pudiendo llegar a enlazarse esta actividad con una aplicación que facture directamente, como en el caso de algunas compañías telefónicas. Los protocolos que implementan esta aproximación son parecidos, en cuanto a que cumplen lo esencial de lo citado hasta ahora, pero tienen sus diferencias significativas. RADIUS (Remote Access Dial In User) es un protocolo desarrollado por Livingston Enterprises Inc. y está compuesto por: • Un protocolo, con un formato de trama que usa UDP/IP.

155


• 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, como una especie de clave compartida entre cliente y servidor. Además, cualquier contraseña de usuario se envía encriptada. Los servidores RADIUS admiten, prácticamente, cualquiera de los métodos de autenticación citados anteriormente (contraseñas, biometría o accesstokens). Tiene, así mismo, la posibilidad de modificarse para incluir la funcionalidad de contabilidad (accounting), pues su distribución es en formato fuente, así como su API, que es completamente pública. Esto último hace que sea casi universalmente aceptado y que cualquier NAS (encaminador, cortafuegos, etc.) de cualquier fabricante lo soporte. Sus implementaciones más habituales en el mercado son las de Livingston, Lucent, Ascend y Cisco (Cisco Secure Access Control Server, CSACS). Los números de puerto oficiales son 1812 para autenticación y 1813 para accounting, aunque tradicionalmente se usan también 1645 para autenticación y 1646 para accounting. TACACS/+ (Terminal Access Controller Access Control System Plus) es un protocolo desarrollado por Cisco, 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 TACACS/+, está encriptada. • Se usa tanto para acceso remoto como para redes LAN. • Soporta casi cualquier método de autenticación, al 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, aspecto que, como se verá en los temas sobre cortafuegos, puede resultar muy importante.

156


En el caso de TACACS/+, la única implementación completa es la ya citada antes del Cisco Secure Access Control Server o CSACS, de Cisco. Como cierre de esta sección, es importante citar que estos sistemas AAA pueden, perfectamente, coordinarse con otros métodos de autenticación de equipos y de usuarios remotos a través de redes privadas virtuales, tanto si el NAS hace de punto extremo de una red privada virtual, como si la autenticación de tal red se hace a través de otro dispositivo «ad-hoc». 4. OTROS CONTROLES SIMPLES DE ACCESO A LA INFORMACIÓN Se debe ahora hacer énfasis en varios aspectos, simples, 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. Ya se ha citado en el tema anterior la necesidad de plantearse en qué sistemas de ficheros guardar los datos más relevantes de la organización. En realidad, en los sistemas de hoy en día, se puede hablar del sistema de ficheros FAT (File Allocation Table) y todos los demás. El FAT, sistema de ficheros por defecto para muchos de los sistemas Windows antiguos, es un sistema de ficheros que no permite imponer una granularidad mínima. Cualquier usuario que ha accedido a un sistema, cuyos ficheros estén organizados mediante FAT (sistema que puede ser, perfectamente, Windows NT), tiene acceso a cualquiera de ellos. Así que se puede deducir una primera norma: si se puede, en todos los casos, evitar el uso de FAT en las máquinas de la organización. Una vez dicho esto, y para hacer una panorámica suficientemente amplia, se puede explorar qué sistemas de ficheros existen, por sistemas operativos.

157


En el caso de Windows, el asunto es sencillo: hay que utilizar el NTFS (New Technology File System), disponible como estándar a partir de Windows 2000 server. Entre otras cosas, el NTFS permite granularidad de acceso a ficheros, sea el acceso local o remoto, por grupos y por usuarios, pudiendo así diseñar el acceso a un determinado fichero o directorio con mucho detalle. Hay que recordar, no obstante, que la implementación no es semejante en todas las versiones, pudiéndose encontrar sistemas Windows no suficientemente «parcheados» en los que, por ejemplo, el grupo Everyone tiene acceso completo (lectura, escritura, borrado y ejecución) a cualquier fichero. En el caso de UNIX, cualquier sistema UNIX dispone de una versión del Berkeley Tahoe File System, conocido como UFS (Unix File System) en la mayor parte de ellos. Este sistema de ficheros tiene granularidad de grupo de usuarios, pero tiene sólo tres tipos de acceso: de lectura, de escritura y de ejecución, estando el acceso de borrado acoplado al de escritura, es decir, que si se tiene derecho de escribir en un fichero, se puede borrar tal fichero. Es bastante más que el FAT, pero menos de lo que dispone el NTFS. No obstante, casi cualquier sistema UNIX actual dispone, además, de otro sistema de ficheros propietario que amplía las propiedades de seguridad del citado UFS. Así, por ejemplo, el Tru64 UNIX, de HP, dispone del Advanced File System, AdvFS, y el AIX, de IBM, del Journal File System, JFS, que permiten una mayor granularidad, a través de lo que se denomina listas de control de acceso (ACLs o Access Control Lists en sus siglas en inglés). Tales listas permiten detallar el acceso usuario a usuario y son una implementación de las listas de control de acceso de la norma POSIX (Portable Operating System IX), que lo hacen posible gracias a comandos como el setacl, que permite establecer tales ACLs y el comando getacl, que permite, a quien tiene derecho, ver las listas de cada fichero. En el caso de sistemas LINUX, estos soportan gran cantidad de sistemas de archivos que han ido surgiendo con los años y las mejoras incluidas en sus diferentes distribuciones. El núcleo de los sistemas LINUX integra gran cantidad de sistemas de archivos y el usuario podrá definir cuál usar en cada disco o dispositivo. El primer sistema de archivos diseñado específicamente para LINUX fue EXT (Extended File System) el cual cuenta ya con 4 versiones, cada una de las cuales ha ido añadiendo funciona-

158


lidad al sistema. Así mismo los sistemas LINUX pueden utilizar otros sistemas, como XFS, JFS, ReiserFS, BRRFS, etc., algunos de los cuales ha heredado de UNIX. En línea con lo anterior, estos mismos sistemas y otros UNIX y LINUX, disponen de la capacidad de encriptar ficheros, simplemente utilizando una clave de criptografía simétrica o asimétrica (detalles que se tratarán en el tema 14), haciendo prácticamente imposible obtener la información sin conocer tal clave. La implementación más extendida de esta capacidad se lleva a cabo mediante versiones de un programa conocido como PGP (por sus siglas en inglés de Pretty Good Privacy), del que se hablará más adelante en este mismo libro. Obviamente, es importante no distribuir tal clave. Igualmente, en sistemas Windows Server se dispone también de esta capacidad, a través del Encrypting File System o EFS. La encriptación de ficheros relevantes aparece como una necesidad básica en caso de que surja la necesidad de decidir qué hacer, y cómo, con los discos que ya no se va a utilizar. A nivel mundial cada año se retiran millones de discos. De ellos, según un estudio de Simson Garfinkel y AbhiShelat (IEEE Security & Privacy, febrero de 2003), sólo alrededor de un 10% han sido saneados (término que se explica en breve) correctamente, alrededor del 64% contienen sistemas de ficheros completamente montables, el resto no tendrán sistemas fácilmente montables, pero, aun así, se puede extraer información de ellos. En el estudio citado, se dan detalles de la información obtenida para el estudio realizado: • Información corporativa, perteneciente a diferentes puestos. • Cartas y mensajes sobre distintos tratamientos de enfermedades padecidas por el dueño del disco o alguno de sus familiares. • Cartas de amor. • Pornografía. Para evitar tales problemas, se debe aclarar, dentro de la política de seguridad qué hacer con los discos que se retiran. En el mismo estudio se proponen las siguientes medidas, para el correcto saneamiento de

159


los discos, y así evitar la posible obtención de información contenida en ellos: • Destruir físicamente el disco, dejándolo inutilizable. • Destruirlo magnéticamente, dejándolo, igualmente, sin uso posible. • Sobrescribir los datos del disco, para que no se puedan recuperar. En cualquier caso, los usuarios deben conocer que, cuando deciden «borrar» los ficheros en su sistema operativo, no los están borrando realmente. Los datos permanecen, sea cual sea el sistema de ficheros que se utilice, solo que hay que leerlos con utilidades especiales, no disponibles en el sistema operativo, como DriveSpy (de digitalintel) para Windows o The Coroner’s Toolkit (porcupine.org) para sistemas UNIX/LINUX. Hay múltiples utilidades para sobrescribir en los discos antes de retirarlos (algunas gratuitas). Por ejemplo, Eraser, es una herramientas para sistemas Windows gratis, fácil de usar y que permite eliminar completamente la información contenida en el disco, para ello borra dicha información repetidas veces hasta que esta es irrecuperable por medio de herramientas de análisis forense digital, o DataGone (de Powerquest), que tiene distintos patrones de borrado. No obstante, hay que recordar que cuanto más conscientes sean los usuarios del problema, más tenderán a utilizar las capacidades de encriptación de los sistemas de ficheros citados con anterioridad, haciendo más irrelevante todo lo dicho en los párrafos anteriores. Otro aspecto esencial hoy en día a la hora de proteger la información contenida en los sistemas informáticos es el uso de herramientas que protejan dichos sistemas contra virus y código malicioso. Como se vio en el tema 4, este tipo de amenazas pueden tener diferentes propósitos, entre ellos puede estar la obtención de información privada o la destrucción del a misma, por tanto, es necesario implantar soluciones «anti-virus» que permitan proteger dicha información de ese tipo de ataques. En estos momentos hay cientos de soluciones «anti-virus» en el mercado para todas las plataformas. Algunas de ellas son herramientas gratuitas y muchas de ellas son comerciales. Independientemente de la solución implantada, es necesario que dicha herramienta sea actualizada continuamente con las huellas de nuevos virus descubiertos, ya que de lo contrario

160


la solución «anti-virus» dará una falsa sensación de protección que podrá ser perjudicial. En el tema 2 se describieron los nuevos retos que presentan los cada vez más presentes dispositivos móviles (teléfonos inteligentes y tabletas). Dichos dispositivos normalmente contienen información que también debe ser protegida. Los sistemas operativos de estos terminales implementan también sistemas de archivos que definen permisos de acceso a los datos alojados en el mismo. Así, los archivos de una aplicación solo son inicialmente accesibles por la propia aplicación, quedando por tanto aislados y protegidos contra el acceso desde otras aplicaciones de terceros. Este nivel de protección inicial, no obstante, puede ser modificado por el usuario. Así, cuando el usuario instala una aplicación, o cuando una aplicación ya instalada quiere acceder a datos que inicialmente no le perteneces, el sistema operativo preguntará al usuario si debe conceder permiso para ello o no. Por tanto, es necesario que el usuario lea y entienda los permisos que una aplicación está solicitando y evalúe si dicho acceso es necesario y/o seguro. Para terminar este apartado, como ya se explicó en el tema 4 y se hará con más detalle en el tema 18, 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 ese tráfico, ya sea su destinatario o un posible atacante. Al usar redes inalámbricas sin cifrado, dicha información no solo podrá ser capturada sino que además será legible para el atacante por no ir dicha información cifrada. Como medida básica de protección por tanto debemos considerar el evitar, en la medida de lo posible, el uso de redes inalámbricas abiertas, y en caso de tener que hacerlo ser consciente de su vulnerabilidad y evitar enviar información comprometida (información confidencial, credenciales de acceso, etc.) a través de la misma.

161


5. CONOCIMIENTOS Y COMPETENCIAS ADQUIRIDAS Se ha tratado de exponer las medidas básicas de seguridad que hay que tener en cuenta para una aproximación básica. Se ha resaltado la necesidad de imponer controles físicos a los equipos más importantes y susceptibles de ser atacados, creando a su alrededor un perímetro de seguridad, a base de distintos controles físicos. Igualmente, se ha remarcado la importancia de unos buenos controles de acceso lógico, para accesos locales y remotos, basados en: • Algo que se conoce, como las contraseñas. • Algo que se es, datos biométricos. • Algo que se tiene, como los «access tokens». Se han enumerado recomendaciones para una buena configuración de los sistemas de contraseñas, así como la importancia de la formación de los usuarios a este respecto, tanto para sistemas servidores como para estaciones de trabajo personales. Se han enumerado las ventajas e inconvenientes de los sistemas biométricos actuales, haciendo énfasis en su mejora constante, pero también en los peligros de los falsos positivos. Igualmente, se han descrito los distintos tipos de tokens, sus ventajas e inconvenientes y su relación con los sistemas de control de acceso local y remoto. En este sentido, se han definido los sistemas AAA, sistemas de control de acceso remoto, que, gracias al uso de protocolos como RADIUS o TACACS/+, permiten mantener un alto nivel de seguridad, si están bien implementados y bien configurados, para tales accesos remotos. Se ha remarcado el hecho de que todos los sistemas de ficheros de los sistemas operativos con los que normalmente se trabaja no son iguales, señalando que hay que tratar de usar, al menos en los sistemas más importantes, sistemas que, como el NTFS de Windows o el AdvFS de Tru64 UNIX, permiten un mayor detalle (incluso a nivel de usuario específico) en el control de acceso a los ficheros. También son importantes las capacidades de encriptación de ficheros que proporcionan aplicaciones como PGP o sistemas como el EFS de Windows, haciendo mucho más complicada la obten-

162


ción de información, aun disponiendo del fichero que, en este caso, está encriptado. También es importante recordar que hay que pensar qué uso se va a hacer de los discos duros, cuando se vayan a retirar, teniendo disponibles herramientas para el saneamiento de los discos, antes de su retiro definitivo de la máquina donde estaba instalado. Igualmente, es necesario proteger los sistemas contra código malicioso que pueda acceder o eliminar la información que deseamos proteger, lo cual se puede conseguir por medio de herramientas «anti-virus». Los nuevos dispositivos móviles presentan también retos en cuanto a la protección de información que deben ser entendidos por los usuarios de los mismos. Por último, se ha recordado el riesgo que supone el uso de redes inalámbricas abiertas en las que la información viaja sin cifrar, y como se deberá evitar su uso en la medida de lo posible. Todas ellas son sólo medidas básicas, habrá que complementarlas, dentro de la política de seguridad, con otras mucho más sofisticadas, pero, justo por ser básicas, sin ellas no tendría mucho sentido pensar que se dispone de una buena seguridad en los equipos de las redes que se gestionan.

6. BIBLIOGRAFÍA GARFINKEL, S.; SPAFFORD, G.; SCHWARTZ, A. (2003): Practical UNIX and Internet Security. 3.ª edición. O’Reilly Media. GARFINKEL, S.; SHELAT, A. (2003): Remembrance of Data Passed: A Study of Disk Sanization Practices. IEEE Security & Privacy, publicado por IEEE Computer Society.

7. PALABRAS CLAVE AAA, Access Token, ACL, AdvFS, EFS, EXT, FAT, JFS, NAS, NIS, NTFS, RADIUS, SAM, TACACS/+, UFS.

163


8. EJERCICIOS RESUELTOS 1. RADIUS permite autenticación únicamente mediante «access token» en un sistema de control de acceso remoto. a) Verdadero, solo TACAS/+ permiten otras autenticaciones. b) Falso, RADIUS sólo permite autenticación local. c) Falso, RADIUS es un protocolo que permite trabajar, prácticamente, con cualquier tipo de autenticación. d) Verdadero, otras implementaciones son muy caras. Solución: c. 2. ¿Qué sistema de ficheros se seleccionaría, desde el punto de vista de la seguridad, para una máquina con Windows Server? a) b) c) d)

FAT, por ser el más extendido y conocido. UFS, por disponer de mayor detalle en el control de acceso. RFS (Remote File System) pues solo se puede acceder remotamente. NTFS, por disponer de las mejores características de seguridad para sistemas Windows.

Solución: d. 3. Es necesario imponer un perímetro de seguridad física alrededor del encaminador más importante de la organización. a) Verdadero, pues se puede quemar con facilidad. b) Verdadero, pues es más fácil el acceso informático, disponiendo del acceso físico. c) Falso, en un encaminador no hay ningún dato relevante para una organización. d) Falso, en los encaminadores no hay cuentas de usuario mediante las que acceder. Solución: b. 4. ¿Qué se debe hacer con un disco duro de un servidor que se retira para cambiarlo por otro más rápido y de mayor capacidad? a) Nada, regalárselo tal cual a quien lo necesite. b) «Sanearlo», eliminar físicamente la información relevante, o toda.

164


c) Borrar todos los ficheros antes, con la herramienta del sistema operativo. d) No se debe cambiar nunca un disco de un servidor. Solución: b. 5. Los sistemas biométricos garantizan, por su propia naturaleza, el acceso seguro de un usuario remoto. a) Falso, pues alguien podría robar los datos biométricos del usuario y hacerse pasar por él. b) Verdadero, ya que nos basamos en algo que se es. c) Verdadero, pues es imposible tener dos retinas idénticas. d) Falso, pues no se usan para acceso remoto. Solución: a. 9. EJERCICIOS DE AUTOEVALUACIÓN 1. Indique cuál de los siguientes se consideran protocolos AAA: a) b) c) d)

NATFS y FAT. ACL y PGP. RADIUS y TACACS/+. Todos los anteriores.

2. Indique cuál de las siguientes se consideran medidas de seguridad básica: a) Se debe establecer un perímetro de seguridad alrededor de los servidores de la organización. b) Los servidores se concentrarán (en la medida de lo posible) en una habitación lo suficientemente segura. c) Se deberá controlar el acceso al CPD (Centro de Proceso de Datos) de forma que solo el personal autorizado tenga acceso al mismo. d) Todas las anteriores. 3. ¿Cuál de las siguientes afirmaciones no es correcta?: a) El sistema de autenticación más extendido es la autenticación por contraseña. b) El administrador utilizará siempre la cuenta de superusuario en su interacción con los servidores.

165


c) Una buena gestión de contraseñas obligará a los usuarios a cambiarla cada cierto tiempo. d) No es buena idea tener la misma contraseña para todas las máquinas o servicios, ya que si la contraseña es comprometida se habrá comprometido el acceso a todos ellos. 4. ¿Cuáles son los componentes de un sistema AAA?: a) El único componente necesario es un servidor de autenticación AAA. b) Es necesario disponer de un servidor de autenticación AAA y algún protocolo de autenticación como RADIUS o TACACS+. c) Se necesita un servidor de acceso a la red o NAS y un servidor de autenticación AAA. d) Será necesario un servidor de acceso a la red o NAS, un servidor de autenticación AAA y un protocolo de autenticación que comunique ambos servidores. 5. ¿Cuál de las siguientes afirmaciones es correcta?: a) Es necesario instalar algún tipo de herramienta antivirus que se actualice periódicamente como parte de las medidas básicas de protección de datos. b) No se debe usar nunca redes inalámbricas abiertas. c) En terminales móviles es imposible que una aplicación tenga acceso a los datos de otra aplicación instalada en el terminal. d) Desde el punto de vista de seguridad será conveniente seleccionar el sistema de archivos NTFS para sistemas operativos LINUX.

166

Tema 6

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

1. Introducción, orientaciones para el estudio y objetivos 2. ¿Qué es una política de seguridad? 3. Aspectos físicos de la política de seguridad 4. Aspectos lógicos de la política de seguridad 5. Aspectos legales de la política de seguridad 5.1. Ley Orgánica de Protección de Datos, LOPD 5.2. Ley de Servicios de la Sociedad de la Información y Comercio Electrónico, LSSICE 5.3. El Esquema Nacional de Seguridad, ENS 6. Aspectos organizativos de la política de seguridad 6.1. El estándar ISO/IEC 15408 6.2. El estándar ISO/IEC 27001 6.3. Las buenas prácticas de ITIL® e ISO/IEC 20000 7. Conocimientos y competencias adquiridas 8. Bibliografía 9. Palabras clave 10. Ejercicios resueltos 11. Ejercicios de autoevaluación

1. INTRODUCCIÓN, ORIENTACIONES PARA EL ESTUDIO Y OBJETIVOS Como ya se explicó en el tema 1, 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. Es muy importante recalcar la importancia de la política de seguridad en una organización. Las organizaciones 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 de la organización y cumplir las disposiciones legales del país. La política de seguridad de una organización es algo así como las normas, reglas o leyes (escritas, cuanto más públicas, mejor) que rigen la vida de la organización en cuanto a qué se puede hacer y qué no se puede hacer. 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. Como en todos los aspectos de la vida en los que hay que tomar decisiones basándose en la confianza o desconfianza que se tiene con respecto a la gente, el desarrollo de una política de seguridad obliga a tomar decisiones delicadas, imponiendo una serie de normas que pueden provocar malestar en el grupo. Hay que explicar, claramente, por qué se toman tales decisiones y cuáles son los peligros que se tratan de evitar.

169


En este tema se va a hacer un análisis amplio de cuáles son los aspectos esenciales de cualquier política de seguridad. Entre ellos: • 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 seguridad. • 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. En este momento será bueno recordar que la seguridad es un proceso continuo, que la política para lograrla debe estar en constante actualización, que la seguridad no es un producto que se instala y se configura, que necesita un cuidado en el día a día, que hace que no sea posible ver en ella una aplicación como otra cualquiera. Nuevos usuarios, nuevas aplicaciones y nuevos procedimientos operativos de la organización obligan, continuamente, a tenerla actualizada, a estar vigilantes y a pensar, a veces paranoicamente, en sus posibles fallos. 2. ¿QUÉ ES UNA POLÍTICA DE SEGURIDAD? Si se recuerda lo citado en el tema 1, se puede definir de manera sencilla una política de seguridad 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 de una política de seguridad es informar a los usuarios, trabajadores y personal de dirección, de los requisitos obligato-

170

UNA RESPUESTA COMPLETA A LOS PROBLEMAS DE SEGURIDAD EN REDES DE INFORMACIÓN

rios para proteger los valores tecnológicos y la información de la organización. La política debería especificar los mecanismos a través de los cuales estos requisitos puedan ser conocidos. Otro propósito es proporcionar una base para adquirir, configurar y auditar los sistemas de ordenadores y las redes. Por tanto, emplear un conjunto de herramientas de seguridad, sin una política de seguridad implícita, no tendría mucho sentido. El uso adecuado de estas herramientas también debería ser parte de la política de seguridad. Esto implica especificar qué se puede y qué no se puede hacer con los componentes del sistema, incluyendo el tipo de tráfico que viaja en las redes. Los objetivos concretos que se buscan vendrán determinados, en buena parte, por la capacidad que se tenga de cumplir con una serie de aspectos ya comentados en el tema 1, como son: • Debe poderse implantar. • Debe entenderse. • Debe hacerse cumplir. • 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 Como se verá también en este tema, la política de seguridad debe estar alineada con una serie de políticas de «gobierno» de la organización, como los planes de disponibilidad, de capacidad y de continuidad del negocio de la propia organización. Igualmente, debe cumplir, en la medida de lo posible, una serie de características de diseño, enunciadas también en el tema 1, que se van a desarrollar ahora en más detalle. Se ha de contemplar siempre el principio de privilegio mínimo, que consiste en tratar de minimizar el número de usuarios con privilegios de

171


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, que no necesita para que el trabajo salga adelante. Otro aspecto importante que debe tratar de conseguirse es el ilustrado por los principios de defensa en profundidad y de diversidad de defensa. Se debe intentar tener más de un nivel de defensa y, a poder ser, de distinta naturaleza para, de esta forma, hacer más difícil el trabajo del supuesto atacante que no sólo debe vencer más de una defensa, sino que cada una le obliga a tener distintos tipos de conocimiento. Es una buena idea disponer de un punto central de gestión de la seguridad, en el que centralizar 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. Como se analiza más adelante esto ayudará a la correcta implantación de un Sistema de Gestión de Seguridad de la Información (SGSI) que siga el estándar ISO/IEC 27001. Otra buena técnica es la de identificar los puntos más débiles de la organización. Por ejemplo, cualquier configuración avanzada del cortafuegos más sofisticado del que se disponga es inútil si también se puede acceder a la organización mediante un punto de acceso inalámbrico y una contraseña estática. Es importante seguir también el principio del «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 ya ningún acceso. Quizás el más importante, y más difícil de conseguir, 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. Además, es el principio que debe dirigir la propia construcción de cada norma, que no debería ser de un tamaño mayor de 2 páginas. Otros aspectos de diseño, mucho más prácticos, pueden ayudar a «imaginarse» cómo será esa política de seguridad: • Hay que elegir, con sumo cuidado, el equipo de desarrollo de la política, pensando en todos los grupos de la organización y teniendo en cuenta que la política deberá ser periódicamente actualizada.

172


• Debe haber una «política de políticas», que establezca el proceso de diseño de cada política. Este proceso debe especificar, por ejemplo, quién desarrolla el borrador inicial de la política, qué grupos deben revisarla, cuál es el proceso de aprobación y cuál el proceso de implementación. • 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. El tamaño del grupo director dependerá del tamaño de la organización y el del grupo responsable de cada política dependerá de lo específica que sea la política concreta. Dependerán asimismo de si se está implantando algún SGSI en la organización o no. • Es buena idea que la política sea revisada, antes de su aprobación, por un grupo de la gente sobre la cual tendrá efecto. • Cada política particular, cada norma debe establecer, claramente, las razones de su necesidad, que aspectos 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, pues es más fácil mantenerlos de esta manera. El número absoluto de normas no existe, dependerá de cada organización, de cada red, de cada sitio de la red. Es fácil imaginar una serie de normas que deberán estar presentes en cualquier organización, mientras que muchas no tendrán cabida en todas ellas. Lo que para algunas será fundamental, en otros ni siquiera tendrá sentido. No obstante, 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. Cuando el uso de portátiles, teléfonos inteligentes o tabletas era casi nulo, el perímetro de seguri-

173


dad era relativamente fácil de fijar. Actualmente el perímetro fijo ya no existe y los datos y el acceso remoto de la organización viajan, en muchos casos, con nosotros. • Normas básicas de seguridad física. • Normas sobre respuestas a incidentes. • Normas de contraseñas aceptables Otras normas posibles pueden tener en cuenta aspectos más específicos de cada organización, como: • Encriptación aceptable. • Proveedores de conexión a Internet aceptables, incluyendo acceso mediante teléfonos móviles y tabletas. • Proveedores de software aceptables. • Seguridad en las adquisiciones. • Auditoria. • Valoración de riesgos. • Seguridad de equipos en las zonas DMZ. • Redes Privadas Virtuales. • Seguridad de los servidores. • Laboratorios de prueba de problemas de seguridad. • Sistemas anti-virus. • Seguridad de encaminadores y conmutadores. • Seguridad en las comunicaciones inalámbricas. • Cortafuegos aceptables. Es necesario remarcar, además, la necesidad de que todas ellas cumplan con cualquier obligación legal en el marco de las leyes del país donde se quiera imponer la política. Finalmente, antes de ver, paso a paso, los distintos aspectos de las normas referentes a los componentes que hay en las redes, hay que señalar la

174


importancia de la política de seguridad como eje del proceso de seguridad. La figura 6.1 permite ver la seguridad como una rueda, en la que la política permite guiar el proceso de mantenimiento de seguridad.

Figura 6.1. La seguridad como un proceso y la política como su guía.

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, lo que incluye, también, configuración de encaminadores, cortafuegos, redes privadas virtuales (asuntos todos que se detallan más adelante en el libro), etc. Esto se puede considerar como el primer paso del proceso (figura 6.2), es el «echar a andar» la rueda, la fase de puesta en marcha del proceso de seguridad. Pero si solo se hiciera esto, se estaría incumpliendo normas básicas, ya citadas en el tema 1, y que, también forman una buena política de seguridad. El siguiente paso (figura 6.3) 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. Como se verá más adelante en el libro, esta fase implica gestionar los registros de actividades y de auditoría y suele implicar la puesta en marcha,

175


Figura 6.2. Fase de puesta en marcha del proceso de seguridad.

Figura 6.3. Fase de monitorización del proceso de seguridad.

176


configuración y mantenimiento de lo que se llama sistemas de detección de intrusiones, de los que se hablará en el tema 11. 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.

Figura 6.4. Fase de análisis de vulnerabilidades.

La siguiente sería la fase de análisis de vulnerabilidades, que sirve para buscar, mediante scanners, o analizadores, de vulnerabilidades (analizados en el tema 10) problemas relacionados con bugs en sistemas operativos o aplicaciones en cualquier tipo de máquina de la red. Como se puede ver en la figura 6.4, de ella se puede deducir, también, si habrá que hacer algún cambio en la política de seguridad, ayudando, así, a consolidar la que podría llamarse «versión 2» de la política. Finalmente, con todos los cambios necesarios consolidados, habrá que aplicar la nueva versión de la política de seguridad a todos los dispositivos que se vean involucrados, así como a los procedimientos necesarios (figura 6.5). Y aquí se repite la primera fase, y la rueda seguirá girando.

177


Figura 6.5. Consolidación del proceso de seguridad.

La periodicidad con la que cada una de las fases debe ponerse en marcha depende, claramente, de la política, que debe tener en cuenta el tamaño de la red y otros múltiples factores. No es tan importante trabajar con una periodicidad concreta como señalar la importancia de ver la política de seguridad de una organización como algo en constante cambio, que permite que el mantenimiento de la seguridad sea un proceso vivo y administrable de forma estructurada y organizada.

3. ASPECTOS FÍSICOS DE LA POLÍTICA DE SEGURIDAD Cualquier política de seguridad debe tener en cuenta una serie de procedimientos relacionados con la seguridad física, tanto en el aspecto del control de acceso físico a equipos, como en el de tener planes de contingencia y emergencia, así como de recuperación frente a desastres. Estos planes serán el objeto del análisis del tema 12, por lo que únicamente se citarán en este tema.

178


Debe estar claramente estipulado quién tiene derecho a acceder, y en qué casos concretos, a cada una 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, que permita acceder a soportes magnéticos con información sensible. Asimismo, la política de seguridad debe delimitar claramente la forma en la que se transporta información sensible en dispositivos físicos de procesado (portátiles, tabletas y teléfonos inteligentes) y de almacenamiento (disco sólidos, dispositivos USB, etc.) móviles. 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 al edificio? • ¿Quién puede entrar a determinadas salas del edificio, donde residan las máquinas identificadas como especialmente sensibles? • ¿Cómo debe garantizarse tal tipo de acceso? Podría ser mediante algún tipo de token de acceso o mediante medidas biométricas, etc. • ¿Quién puede acceder a determinados dispositivos específicos de salida, como impresoras? • ¿Qué documentos no deben tener copias en papel sueltas y dónde destruirlas y cómo destruirlas? • ¿Qué acceso se le da a una persona que viene a colaborar, en términos de ordenador, cuenta, nivel de acceso? Lo mismo hay que tener en cuenta para una visita, si es que se diera el caso de necesitar acceso.

179


• ¿Es necesaria la implantación de cámaras de seguridad? Si lo es, ¿qué condiciones debe cumplir la empresa contratada a tal fin? • ¿Es necesaria la presencia de guardias de seguridad? Se debe tener en cuenta otra serie de ideas, cuya implantación o no dependerá de su utilidad para cada organización, entre las cuales se pueden resaltar: • Las actividades críticas deben de situarse lejos de las áreas de acceso público. • Los edificios deben ser discretos y se deben minimizar las indicaciones sobre su propósito, evitando signos obvios de las actividades realizadas en ellos. • Los listines de los teléfonos y de las salas de la organización no deben identificar localizaciones informáticas (excepto las oficinas y áreas de recepción). • Los materiales peligrosos y/o combustibles deben almacenarse a una distancia de seguridad del emplazamiento de los ordenadores. Un ejemplo muy simple es un vaso de agua, si es derramado en uno de los servidores podría causar graves daños a los servicios que realiza la empresa. • El equipamiento de copias de seguridad y las propias copias de seguridad deben ubicarse en sitios diferentes y a una distancia conveniente de seguridad. • Se debe instalar equipamiento apropiado de seguridad: detectores de calor y humos, salidas de emergencia y sistemas de extinción de incendios. Todo este equipamiento debe revisarse periódicamente de acuerdo con las instrucciones de los fabricantes. Los empleados deben estar entrenados en su uso adecuado. • Los procedimientos de emergencia deben estar bien documentados y revisados regularmente. Aunque se analizará en más detalle en el tema 12, se ha de señalar la importancia de disponer de los procedimientos para la copia periódica de la información, especialmente de la más relevante, que incluya, además,

180


un cierto control de calidad, para asegurar que la copia de datos es inmediatamente utilizable. Se debe disponer al menos de copias de: • La información de ordenadores de los sistemas centrales. • La información de ordenadores de la 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, en el que residan todas estas copias, disponiendo así de una seguridad física adicional. 4. ASPECTOS LÓGICOS DE LA POLÍTICA DE SEGURIDAD Entre las normas y procedimientos relacionados con aspectos lógicos se puede separar lo que se denomina normas básicas o fundamentales, 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 configuración de encaminadores y, posiblemente, de cortafuegos y puntos finales de redes privadas virtuales. • Política de protección anti-virus. • 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 incidentes. Entre las que no serían normas básicas, pero, aun así, en una organización extensa serían importantes, se tendrían: • Política de uso de sistemas de detección de intrusiones, tanto de tipo red como de tipo host, de la que se hablará en extensión en el tema 11.

181


• 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, entre otras cosas, se harán todas las pruebas posibles fuera de la red real, en búsqueda de posibles vulnerabilidades de seguridad en sistemas de todo tipo, con ayuda de analizadores de vulnerabilidades (aspecto que se estudia en el tema 10) y de herramientas propias. • Política de comunicaciones inalámbricas, cubriendo todas las características de seguridad asociadas, que se discuten en el tema 18. • Política de uso de redes privadas virtuales. • Cualquier otra política aplicable a las características de la organización concreta. Al ser éste un libro que no trata solamente de políticas de seguridad, en este tema se analizan sólo las políticas del primer grupo o fundamentales, dejando para los temas siguientes algunas de las del segundo bloque. 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 normas, 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 almacenada en sus cuentas. Debe señalar qué permisos (por ejemplo de lectura y de copia) pueden tener los usuarios sobre ficheros que tengan accesibles, pero no sean suyos. Debe estipular, igualmente, el uso aceptable del correo electrónico, del acceso web y de todo tipo de acceso a Internet (hoy especialmente universal gracias a todo tipo de dispositivos móviles inteligentes), así como discutir los usos aceptables, no relacionados con el objeto de la organización, de los recursos informáticos. Otra política muy necesaria es la que hace explicitas las normas sobre acceso remoto a los recursos informáticos de la organización. Es algo esencial, especialmente para organizaciones grandes en las que las redes están dispersas geográficamente e, incluso, se han extendido a hogares de empleados. Debe cubrir todos los métodos disponibles para acceder, remotamente, a los recursos de la red interna: • Acceso mediante modem, vía SLIP o PPP.

182


• Acceso mediante RDSI o ADSL. • Acceso mediante ssh o telnet, desde Internet. • Acceso mediante cualquier tipo de red privada virtual. Esto último quiere decir que debe expresar claramente la necesidad de completarse con normas más específicas sobre, por ejemplo, redes privadas virtuales. Para cada uno de los posibles métodos de acceso, hay que especificar si están permitidos o no, quien, en qué función, puede usar alguno de los permitidos y cómo, además de cualquier restricción horaria que se decida aplicar al acceso. Otro análisis típico que suele contener es qué restricciones debe haber sobre el acceso remoto a los datos de la organización. 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 usuarios. Su objetivo fundamental es garantizar que la información está protegida apropiadamente (esto incluye el cumplimiento de las leyes al respecto, como se verá más adelante en este mismo tema) frente a la posible modificación o revelación. Algunos expertos defienden la necesidad de que esta norma sea firmada por los nuevos empleados de una organización, como parte de su orientación inicial en la empresa. 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. Así mismo, debe estipular, claramente, bajo qué circunstancias especiales (si existe alguna) puede no tenerse en cuenta tales niveles. Estos niveles determinarán, además, otros aspectos importantes: • ¿Cómo se va a almacenar y a transmitir la información más sensible? • ¿En qué sistemas puede almacenarse tal tipo de información? • ¿Qué información sensible puede imprimirse en dispositivos inseguros? • ¿Cómo se asegura que tal información desaparece de los dispositivos de almacenamiento que se van a retirar (véase el tema 5)? Actualmente de estas consideraciones se derivan consecuencias muy importantes para el cumplimiento de la LOPD, cumplimiento que exige,

183


por ejemplo, delimitar claramente quién es el responsable de cada fichero que contenga datos personales de cualquier clase. Otra política relacionada con todo lo anterior 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. Debe establecer quién puede realizar una serie de operaciones privilegiadas como: • ¿Quién puede obtener acceso privilegiado a sistemas en el perímetro? • ¿Cuál es el procedimiento de cambio de configuración de un dispositivo del perímetro (cortafuegos, encaminador, etc.) y cómo se aprueba tal cambio? • ¿Quién tiene derecho a obtener información sobre la configuración del perímetro, listas de control de acceso de encaminadores, etc.? • ¿Cuál es el periodo de revisión de la configuración de tales dispositivos, en ausencia de incidencias? Lo normal es que sólo un pequeño grupo de personas, relacionadas con la seguridad y dirección de gestión de la red, tengan tales derechos, pero, con la política quedará más claramente establecida. La siguiente política básica que se cita es la política de protección frente a posibles ataques por 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. También debe contener las explicaciones de los distintos niveles de riesgo dependiendo del tipo de virus, así como la necesidad de selección del tipo de programa antivirus que se vaya a utilizar y debe discutirse la frecuencia de actualización de los datos del mismo software. 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 de administrador, así como: • Las reglas de creación de las contraseñas. • Las reglas de cómo evitar la revelación de contraseñas.

184


• 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. Por último, otra política típica es la que describe los procedimientos a seguir frente a incidentes de seguridad, 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 se sabe que hay mayor incidencia. Entre ellos, como ya se ha visto en el tema 4, se podrían citar la obtención de información por medios automáticos (port scans, etc.), los ataques de denegación de servicio, las intrusiones no permitidas a servidores, las cuentas capturadas o cualquier caso de uso no apropiado. Algunas características que debería tener cualquier política de esta clase serían: • Debería definir cómo gestionar la investigación de comportamientos anómalos, además de la investigación de ataques de intrusión. • Debería definir un equipo de respuestas a incidentes de seguridad, con funciones y responsabilidades claramente estipuladas. • Debería definir cuándo hay que notificar un incidente y a quién debe ir tal notificación dirigida. • Debería definir qué información hay que registrar y guardar, especialmente la que tenga, según la legislación de cada país, capacidad probatoria. • Debería definir cómo hacer un seguimiento del incidente concreto y quién debe encargarse de tal seguimiento. 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. Éste es un aspecto que ha variado mucho en los últimos años, que está obligando a implantar una serie de normas y procedimientos que antes no existían. Aunque no se pretende ha-

185


cer un compendio exhaustivo de todas, es necesario, al menos, conocer las que prácticamente siempre habrá que tener en cuenta. 5.1. Ley Orgánica de Protección de Datos Personales (LOPD) El Tribunal Constitucional, en su sentencia 292/2000, define la Protección de Datos de Carácter Personal como el derecho 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 sobre protección de datos establece límites al grado de intrusión en nuestra intimidad que las nuevas tecnologías pueden generar. Así pues 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 (empleados, clientes, colaboradores, etc.). Todos ellos deben adecuarse a la legislación actual sobre protección de datos contemplando una doble perspectiva: por un lado, el respeto a los derechos de los ciudadanos y, por otro, su funcionamiento interno y la seguridad de su información. La LOPD es la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal. Adapta la legislación española a la Directiva europea y su ámbito de aplicación comprende todos los ficheros que contengan datos de carácter personal, con independencia de que se trate de ficheros automatizados o en formato papel. El RLOPD (Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de Desarrollo de la LOPD y que entró en vigor el día 19 de abril de 2008, desarrolla la LOPD y consolida la doctrina reguladora establecida por la AEPD (Agencia Española de Protección de Datos) en sus instrucciones y expedientes sancionadores, así como la interpretación que de la LOPD han efectuado los Tribunales a través de la jurisprudencia. El RLOPD incrementa la protección ofrecida a los datos de carácter personal, pero, por otra parte, establece ciertas especialidades para facilitar la implantación de medidas de seguridad, que inciden sobre todo en el ámbito de las PYMES.

186


Este nuevo Reglamento, que sustituye al RMS 994/99, establece, entre otras cosas, las medidas de seguridad para los ficheros no automatizados, regula las relaciones entre el Responsable del Fichero y el Encargado del Tratamiento (permitiendo además la subcontratación), introduce novedades importantes con respecto a los ficheros sobre solvencia patrimonial y crédito y respecto al ejercicio de derechos. Se pasa ahora a describir algunos de los aspectos más prácticos de la LOPD y su reglamento, con la vista puesta en cómo obligarán a modificar cualquier política de seguridad. La LOPD establece varios tipos de datos personales y la clasificación se puede llevar a cabo 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. Hay datos personales especialmente protegidos que están recogidos en los artículos 7 y 8 de la LOPD: los referidos a la ideología, religión, creencias, afiliación sindical, origen racial o étnico, salud, vida sexual, y comisión de infracciones penales o administrativas. 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 (Art. 81 RLOPD): • Datos de nivel Básico: Son aquellos datos personales que no se clasifican como de nivel Medio o de nivel Alto. • Datos de nivel Medio. Sin pretender ser exhaustivos, algunos ejemplos serían los relativos a la comisión de infracciones administrativas o penales, aquellos de los que sean responsables Administraciones tributarias y se relacionen con el ejercicio de sus potestades tributarias o aquellos de los que sean responsables las Entidades Gestoras y Servicios Comunes de la Seguridad Social y se relacionen con el ejercicio de sus competencias. • Datos de nivel Alto: los que se refieran a datos de ideología, afiliación sindical, religión, creencias, origen racial, salud o vida sexual, los que contengan o se refieran a datos recabados para fines policiales sin consentimiento de las personas afectadas o aquellos que contengan datos derivados de actos de violencia de género.

187


A continuación se exponen algunas de las definiciones básicas y de las obligaciones principales que la ley impone a los responsables de los ficheros de datos de carácter personal y demás personas que intervienen en algún momento en el tratamiento de los mismos. 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. Por ejemplo, una empresa es responsable de los ficheros que contienen datos sobre sus empleados y clientes o un Ayuntamiento es responsable del fichero del padrón. Algunas de las obligaciones principales que tienen los responsables de ficheros son: • Notificar la inscripción de los ficheros en el Registro de la AEPD. • Informar a los titulares de los datos sobre la recogida de los mismos. • Obtener el consentimiento para el tratamiento de los mismos. • Facilitar y garantizar el ejercicio de los derechos de oposición al tratamiento, acceso, rectificación y cancelación. • Asegurar que los datos son de calidad, es decir, adecuados, veraces y obtenidos lícita y legítimamente, y tratados conforme a la finalidad con la que se recogieron: no usarlos para otros fines, no recoger más datos de los necesarios, mantenerlos actualizados, y cancelarlos si ya no son necesarios. El encargado del fichero o tratamiento es la persona física o jurídica, pública o privada, u órgano administrativo que, sólo 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. Por ejemplo, una empresa que presta servicios para la realización de envíos postales o un gestor administrativo que confecciona las nóminas y gestiona el fichero de personal. Es importante señalar que tanto el Responsable del fichero como el encargado del tratamiento, pueden ser sancionados si no cumplen con sus obligaciones. La Agencia Española de Protección de Datos (AEPD) protege los derechos de los ciudadanos, es el ente encargado de velar por el cumplimiento de la normativa, y actúa de forma totalmente independiente de las Administraciones Públicas.

188


La AEPD informa y ayuda, tanto a los ciudadanos como a los responsables de fichero y encargados de tratamiento a ejercitar y a cumplir las obligaciones correspondientes en cada caso. Se encarga de facilitar el derecho de consulta de los ciudadanos permitiendo acceder a la información básica de todos los ficheros públicos y privados registrados. Además realiza, de forma preventiva, inspecciones sectoriales de oficio, para evaluar el cumplimiento de todas las garantías previstas en la normativa, detectando deficiencias y formulando recomendaciones para su corrección. En caso de incumplimiento y dependiendo de la infracción, la multa para la organización que incumple la ley puede llegar hasta los 600.000 €. El responsable del fichero debe notificar la creación del fichero al Registro General de Protección de Datos (RGPD) de la AEPD, en los siguientes casos: • Con anterioridad al uso del fichero. • Cuando se producen cambios en el mismo que afectan al registro. • Cuando cesa el uso del fichero. La acción de registrar el fichero implica que éste cumple con todas las exigencias legales. Es una operación gratuita que permite que los titulares de los datos puedan conocer quién es el responsable del fichero, por si necesitan ejercitar sus derechos de acceso, rectificación, cancelación y oposición. La NO notificación de un fichero, supone una sanción que puede ir de leve a grave dependiendo del caso. El acceso al registro (RGPD) es público y gratuito. A la hora de recoger datos personales, los afectados deben ser informados correctamente, indicándoles: • Para qué se utilizarán los datos. • Informando del fichero y de sus tratamientos. • Quién es el responsable del fichero o su representante. • Los destinatarios de la información (en su caso). • De las consecuencias de la obtención de los datos o de la negativa a suministrarlos. • De la posibilidad de ejercitar los derechos de acceso, rectificación, cancelación y oposición.

189


La ley exime del deber de informar sobre algunos de los aspectos anteriores cuando se deduzcan de la naturaleza de los propios datos personales y de las circunstancias en las que se realiza la recogida de los mismos. Toda esta información debe incluirse en los formularios de recogida de los datos. Toda persona tiene derecho a saber si sus datos personales van a incluirse en un fichero y qué tratamientos se realizarán con los mismos. En el caso de que los datos personales no se hubieran recogido directamente del interesado, el responsable del fichero debe informarle de la recogida de los mismos en el plazo de 3 meses siguientes al registro de los datos, excepto si ya hubiera sido informado con anterioridad. El incumplimiento del deber de informar está tipificado como falta leve. La Ley especifica que debe haber un consentimiento expreso y escrito para el tratamiento de datos especiales: de ideología, religión, creencias y afiliación sindical. La Ley especifica que debe haber un consentimiento expreso pero no necesariamente escrito para el tratamiento de datos de relacionados con la salud, el origen racial y la vida sexual. 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 autorizado. Las medidas se aplicarán a ficheros y tratamientos (tanto automatizados como no automatizados), y al responsable del fichero y al encargado del tratamiento. El artículo 9 de la LOPD condiciona las medidas al estado de la tecnología, la naturaleza de los datos, que marcará su nivel de seguridad, y los riesgos a los que estén expuestos. El nuevo Reglamento RLOPD obliga a adoptar toda una serie de cambios técnicos a los que obliga el cumplimiento de la LOPD. Algunos de los cambios, que pueden ser más ilustrativos son: • Artículo 89: «1. Las funciones y obligaciones de cada uno de los usuarios o perfiles de usuario con acceso a los datos de carácter personal y a los sistemas de información estarán claramente definidas y documentadas en el documento de seguridad. También se definirán las funciones de control o autorizaciones delegadas por el responsable del fichero o tratamiento. 2. El responsable del fichero o tratamiento adoptará las medidas necesarias para que el personal conozca de una

190


forma comprensible las normas de seguridad que afecten al desarrollo de sus funciones, así como las consecuencias en que pudiera incurrir en caso de incumplimiento». • Artículo 90: «Deberá existir un procedimiento de notificación y gestión de las incidencias que afecten a los datos de carácter personal y establecer un registro en el que se haga constar el tipo de incidencia, el momento en que se ha producido, o en su caso, detectado, la persona que realiza la notificación, a quién se le comunica, los efectos que se hubieran derivado de la misma y las medidas correctoras aplicadas». • Artículo 91: «1. Los usuarios tendrán acceso únicamente a aquellos recursos que precisen para el desarrollo de sus funciones. 3. El responsable del fichero establecerá mecanismos para evitar que un usuario pueda acceder a recursos con derechos distintos de los autorizados». • Artículo 92: «1. Los soportes y documentos que contengan datos de carácter personal deberán permitir identificar el tipo de información que contienen, ser inventariados y sólo deberán ser accesibles por el personal autorizado para ello en el documento de seguridad. Se exceptúan estas obligaciones cuando las características físicas del soporte imposibiliten su cumplimiento, quedando constancia motivada de ello en el documento de seguridad. 2. La salida de soportes y documentos que contengan datos de carácter personal, incluidos los comprendidos y/o anejos a un correo electrónico, fuera de los locales bajo el control del responsable del fichero o tratamiento deberá ser autorizada por el responsable del fichero o encontrarse debidamente autorizada en el documento de seguridad. 3. En el traslado de la documentación se adoptarán las medidas dirigidas a evitar la sustracción, pérdida o acceso indebido a la información durante su transporte. 4. Siempre que vaya a desecharse cualquier documento o soporte que contenga datos de carácter personal deberá procederse a su destrucción o borrado, mediante la adopción de medidas dirigidas a evitar el acceso a la información contenida en el mismo o su recuperación posterior». • Artículo 93: «1. El responsable del fichero o tratamiento deberá adoptar las medidas que garanticen la correcta identificación y au-

191


tenticación de los usuarios. 2. El responsable del fichero o tratamiento establecerá un mecanismo que permita la identificación de forma inequívoca y personalizada de todo aquel usuario que intente acceder al sistema de información y la verificación de que está autorizado. 3. Cuando el mecanismo de autenticación se base en la existencia de contraseñas, existirá un procedimiento de asignación, distribución y almacenamiento que garantice su confidencialidad e integridad». Algunas de las medidas aplicables a datos de nivel alto son: • Artículo 101: «1. La identificación de los soportes se deberá realizar utilizando sistemas de etiquetado comprensibles y con significado que permitan a los usuarios con acceso autorizado a los citados soportes y documentos identificar su contenido, y que dificulten la identificación para el resto de personas. 2. La distribución de los soportes que contengan datos de carácter personal se realizará cifrando dichos datos o bien utilizando otro mecanismo que garantice que dicha información no sea accesible o manipulada durante su transporte. Asimismo, se cifrarán los datos que contengan los dispositivos portátiles cuando éstos se encuentren fuera de las instalaciones que están bajo el control del responsable del fichero. 3. Deberá evitarse el tratamiento de datos de carácter personal en dispositivos portátiles que no permitan su cifrado. En caso de que sea estrictamente necesario, se hará constar motivadamente en el documento de seguridad y se adoptarán medidas que tengan en cuenta los riesgos de realizar tratamientos en entornos desprotegidos». • Artículo 103: «1. De cada intento de acceso se guardarán, como mínimo, la identificación del usuario, la fecha y hora en que se realizó, el fichero accedido, el tipo de acceso y si ha sido autorizado o denegado. 2. En el caso de que el acceso haya sido autorizado, será preciso guardar la información que permita identificar el registro accedido. 3. Los mecanismos que permiten el registro de accesos estarán bajo el control directo del responsable de seguridad competente sin que deban permitir la desactivación ni la manipulación de los mismos. 4. El período mínimo de conservación de los datos registrados será de dos años». • Artículo 104:» Cuando, conforme al artículo 81.3 deban implantarse las medidas de seguridad de nivel alto, la transmisión de datos de ca-

192


rácter personal a través de redes públicas o redes inalámbricas de comunicaciones electrónicas se realizará cifrando dichos datos o bien utilizando cualquier otro mecanismo que garantice que la información no sea inteligible ni manipulada por terceros». 5.2. Ley de Servicios de la Sociedad de la Información y Comercio Electrónico (LSSICE) La Ley 34/2002, de 11 de julio, de servicios de la sociedad de la información y de comercio electrónico (LSSICE) tiene como objeto: … la regulación del régimen jurídico de los servicios de la sociedad de la informació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 incorporó a la jurisdicción española la Directiva Europea 2000/31/CE, que hace referencia a aspectos de los servicios de la sociedad de la información, en particular, al comercio electrónico en el mercado interior. Dadas las incertidumbres en materia jurídica existentes, se pretende establecer un marco jurídico que ofrezca garantías y confianza para el empleo de estos servicios. Uno de los aspectos más importantes de la ley consiste en la definición de «servicios de la sociedad de la información». Según la definición: … engloba, además de la contratación de bienes y servicios por vía electrónica, el suministro de información por dicho medio (como el que efectúan los periódicos o revistas que pueden encontrarse en la Red), las actividades de intermediación relativas a la provisión de acceso a la Red, a la transmisión de datos por redes de telecomunicaciones, a la realización de copia temporal de las páginas de Internet solicitadas por los usuarios, al alojamiento en los propios servidores de información, servicios o aplicaciones facilitados por otros o a la provisión de instrumentos de búsqueda o de enlaces a otros sitios de Internet, así como cualquier otro servicio que se preste a petición in-

193


dividual de los usuarios (descarga de archivos de vídeo o audio…), siempre que represente una actividad económica para el prestador. Estos servicios son ofrecidos por los operadores de telecomunicaciones, los proveedores de acceso a Internet, los portales, los motores de búsqueda o cualquier otro sujeto que disponga de un sitio en Internet a través del que realice alguna de las actividades indicadas, incluido el comercio electrónico.

Por tanto, según lo aquí expuesto, 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 «actividad económica para el prestador» supone que el prestador obtiene un beneficio económico como resultado de ofrecer tal servicio. De todo esto se puede deducir que el resto de servicios, que no suponen una actividad económica, no son servicios de la sociedad de la información. Siguiendo las pautas comunitarias, se prevé que «las Administraciones Públicas fomentarán a través de la coordinación y el asesoramiento, que las asociaciones y organizaciones comerciales, profesionales y de consumidores elaboren y apliquen códigos de conducta de ámbito nacional, y en su caso comunitario, que afecten a sus intereses con objeto de hacer efectivo lo dispuesto en esta ley». 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. Tales empresas están, también, obligadas a comunicar el nombre de dominio que utilicen al Registro Mercantil u otro Registro público en que estén inscritas. Si se realizan contratos on-line, debe aparecer, además, la siguiente información:

194


• Trámites a seguir para ejecutar el contrato on-line. • Condiciones generales a que, en su caso, se sujete el contrato. y confirmar la celebración del contrato por vía electrónica, mediante el envío de un acuse de recibo del pedido realizado. Las empresas que se dediquen a la realización de publicidad por la red o, más en general, por vía electrónica, 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, concurso o juego promocional debe estar claramente identificado como tal y debe expresar de forma clara e inequívoca las condiciones de participación. • El envío de mensajes publicitarios por Internet o mediante mensajes SMS debe hacerse únicamente con el consentimiento del destinatario. Asimismo, el mensaje debe estar claramente identificado como «Publicidad» y debe haber un procedimiento sencillo para revocar el consentimiento previo. Para los operadores de telecomunicaciones; los proveedores de acceso a Internet (ISPs); los prestadores de servicios de alojamiento de datos y los buscadores hay, además, otro conjunto de obligaciones: • Colaborar con los órganos públicos para la ejecución de resoluciones que no puedan cumplirse sin su ayuda. • Retener los datos de tráfico relativos a las comunicaciones electrónicas, de acuerdo con lo que establezca el Reglamento de desarrollo de la Ley. Por otro lado, tales empresas no son responsables de los contenidos que transmiten o alojan o a los que facilitan acceso, si no participan en su elaboración. Pero si resultarán responsables si conocen su ilicitud y no actúan rápidamente para retirarlos o imposibilitar el acceso a ellos. La LSSICE, por otro lado, ofrece nuevas garantías y derechos en Internet: • Derecho a obtener información sobre los prestadores de servicios (nombre, domicilio, dirección de correo electrónico, etc.) y los precios de los productos o servicios que ofrecen.

195


• Respecto a la publicidad, derecho a conocer la identidad del anunciante, a no recibir mensajes promocionales no solicitados y a oponerse en cualquier momento a la recepción de los que hubieran autorizado. • En la contratación, derecho a conocer los pasos necesarios para contratar por Internet, a acceder a las condiciones generales de la contratación antes de realizar su pedido y a obtener un acuse de recibo del vendedor que le asegure que su pedido ha llegado al vendedor. • Si el consumidor realiza una compra a través de Internet, además se beneficia del régimen de protección que contempla la Ley de ordenación del comercio minorista para todas las ventas a distancia. 5.3. El Esquema Nacional de Seguridad (ENS) El Real Decreto 3/2010, de 8 de enero, por el que se regula el Esquema Nacional de Seguridad en el ámbito de la Administración Electrónica, regula el citado Esquema previsto en el artículo 42 de la Ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los Servicios Públicos. Su objeto es establecer 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 información. El Esquema Nacional de Seguridad es necesario para establecer aspectos comunes relativos a la seguridad en la implantación y utilización de los medios electrónicos por las Administraciones Públicas, al objeto de crear las condiciones necesarias para la confianza en el uso de los citados medios electrónicos que permita el ejercicio de derechos y el cumplimiento de deberes a través de estos medios. 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.

196


• 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 Esquema Nacional de Seguridad es el establecido en el artículo 2 de la Ley 11/2007: • A la Administración General del Estado, Administraciones de las Comunidades Autónomas y las Entidades que integran la Administración Local, así como las entidades de derecho público vinculadas o dependientes de las mismas. • A los ciudadanos en sus relaciones con las Administraciones Públicas. • A las relaciones entre las distintas Administraciones Públicas. Están excluidos del ámbito de aplicación del ENS los sistemas que tratan información clasificada regulada por Ley 9/1968 de 5 de abril, de Secretos Oficiales y sus normas de desarrollo. Establece una serie de principios básicos de seguridad: • Fundamentar la confianza en los sistemas electrónicos regulados por la norma. • Custodia de la información por parte de la administración pública. • Prevención frente a interrupciones o modificaciones fuera de control. • Garantizar el acceso frente a personas no autorizadas. 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, autenticidad, integridad y confidencialidad de datos y aplicaciones.

Se divide en 10 capítulos más una serie de disposiciones. Presenta una serie de anexos muy importantes a título técnico, donde se establecen: • La categoría de los sistemas. • Las medidas de seguridad. • La auditoría de seguridad. • Glosario de términos.

197


Los principios básicos que considera el ENS son: a) Organización e implantación del proceso de seguridad. b) Análisis y gestión de los riesgos. c) Gestión de personal. d) Profesionalidad. e) Autorización y control de los accesos. f) Protección de las instalaciones. g) Adquisición de productos. h) Seguridad por defecto. i) Integridad y actualización del sistema. j)

Protección de la información almacenada y en tránsito.

k) Prevención ante otros sistemas de información interconectados. l)

Registro de actividad.

m) Incidentes de seguridad. n) Continuidad de la actividad. o) Mejora continua del proceso de seguridad. Estos principios están muy relacionados, como veremos en la sección siguiente de este tema con la puesta en marcha de un Sistema de Gestión de la Seguridad, que se base en el estándar ISO/IEC 27001. Al no pretender este libro más que hacer una introducción al ENS y llamar la atención sobre la necesidad de su cumplimiento en cualquier ámbito de las Administraciones Públicas, se pasa ahora a resaltar únicamente algunos artículos especialmente significativos. Por ejemplo, el artículo 6, sobre la gestión de la seguridad basada en los riesgos, que dice: El análisis y gestión de riesgos será parte esencial del proceso de seguridad y deberá mantenerse permanentemente actualizado. La gestión de riesgos permitirá el mantenimiento de un entorno controlado, minimizando los riesgos hasta niveles aceptables. La reducción de estos niveles se

198


realizará mediante el despliegue de medidas de seguridad, que establecerá un equilibrio entre la naturaleza de los datos y los tratamientos, los riesgos a los que estén expuestos y las medidas de seguridad.

El artículo 13 versa sobre análisis y gestión de riesgos, y dice que: Cada organización que desarrolle e implante sistemas para el tratamiento de la información y las comunicaciones realizará su propia gestión de riesgos. Esta gestión se realizará por medio del análisis y tratamiento de los riesgos a los que está expuesto el sistema. Sin perjuicio de lo dispuesto en el anexo II, se empleará alguna metodología reconocida internacionalmente.

El artículo 18, sobre adquisición de productos de seguridad, que dice: En la adquisición de productos de seguridad de las tecnologías de la información y comunicaciones que vayan a ser utilizados por las Administraciones públicas se valorarán positivamente aquellos que tengan certificada la funcionalidad de seguridad relacionada con el objeto de su adquisición. La certificación deberá estar de acuerdo con las normas y estándares de mayor reconocimiento internacional, en el ámbito de la seguridad funcional.

El artículo 24 versa sobre incidentes de seguridad, que dice: Se establecerá un sistema de detección y reacción frente a código dañino. Se registrarán los incidentes de seguridad que se produzcan y las acciones de tratamiento que se sigan. Estos registros se emplearán para la mejora continua de la seguridad del sistema.

Es muy relevante asimismo la importancia del Anexo 1 de la Ley, sobre la categoría de seguridad de los sistemas, según el cual los sistemas se categorizan en base a una serie de criterios: • El impacto que tendría sobre la organización un incidente de seguridad. • La repercusión de la organización para: — Alcanzar sus objetivos. — Proteger los activos a su cargo. — Cumplir sus obligaciones diarias de servicio. — Respetar la legalidad vigente. — Respetar los derechos de las personas.

199


Las dimensiones determinan el impacto de seguridad de una organización. Quedan identificadas por sus iniciales: Disponibilidad [D], Autenticidad [A], Integridad [I], Confidencialidad [C] y Trazabilidad [T]. La dimensión de la seguridad se circunscribe en diferentes niveles: BAJO, MEDIO. ALTO. Un servicio puede verse además afectado por una o varias dimensiones de la seguridad. Se hablará de seguridad de nivel bajo, y se aplicarán medidas en consecuencia a ese nivel, cuando las consecuencias de un incidente de seguridad causen un perjuicio limitado, por ejemplo: • La reducción de forma apreciable de la capacidad de la organización para atender eficazmente con sus obligaciones corrientes, aunque estas sigan desempeñándose. • El sufrimiento de un daño menor por los activos de la organización. • El incumplimiento formal de alguna ley o regulación, que tenga carácter de subsanable. • Causar un perjuicio menor a algún individuo, que aún siendo molesto pueda ser fácilmente reparable. Se hablará de seguridad de nivel medio, y se aplicarán medidas en consecuencia a ese nivel, cuando las consecuencias de un incidente de seguridad causen un perjuicio grave, por ejemplo: • La reducción significativa de la capacidad de la organización para atender eficazmente a sus obligaciones fundamentales, aunque estas sigan desempeñándose. • El sufrimiento de un daño significativo por los activos de la organización. • El incumplimiento material de alguna ley o regulación, o el incumplimiento formal que no tenga carácter de subsanable. • Causar un perjuicio significativo a algún individuo, de difícil reparación. Se hablará de seguridad de nivel alto, y se aplicarán medidas en consecuencia a ese nivel, cuando las consecuencias de un incidente de seguridad causen un perjuicio muy grave, por ejemplo:

200


• La anulación de la capacidad de la organización para atender a alguna de sus obligaciones fundamentales y que éstas sigan desempeñándose. • El sufrimiento de un daño muy grave, e incluso irreparable, para los activos de la organización. • El incumplimiento grave de alguna ley o regulación. • Causar un perjuicio grave a algún individuo, de difícil o imposible reparación. En consecuencia, el ENS decide que un sistema de información será de categoría ALTA si alguna de sus dimensiones de seguridad alcanza el nivel ALTO; será de categoría MEDIA si alguna de sus dimensiones de seguridad alcanza el nivel MEDIO, y ninguna alcanza un nivel superior o será de categoría BÁSICA si alguna de sus dimensiones de seguridad alcanza el nivel BAJO, y ninguna alcanza un nivel superior. Por último es también importante señalar que, en función de las naturalezas de las medidas, éstas pueden diferenciarse en: • Marco organizativo. Constituido por el conjunto de medidas relacionadas con la organización global de la seguridad. • Marco operacional. Formado por las medidas a tomar para proteger la operación del sistema como conjunto integral de componentes para un fin. • Medidas de protección. Se centran en proteger activos concretos, según su naturaleza y la calidad exigida por el nivel de seguridad de las dimensiones afectadas. 6. ASPECTOS ORGANIZATIVOS DE LA POLÍTICA DE SEGURIDAD No se puede acabar un tema que trate sobre políticas de seguridad sin analizar, al menos 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 ese sentido se muestra el que seguramente es uno de los estándares más importantes para la selección de programas de aplicación y sistemas operativos, el estándar ISO/IEC 15408.

201


Por otro lado, no es en vano que algunos de los mayores expertos en temas de seguridad llevan años alertando de que hay herramientas y métodos técnicos suficientes, pero casi siempre falla el aspecto humano y esto implica organizar cómo se usan todas esas herramientas correctamente. Es siguiendo esta idea que se presenta un estándar internacional aceptado ampliamente, el ISO/IEC 27001, y se hace 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.1. El estándar ISO/IEC 15408 Common Criteria Aunque ya se analizó en el tema 3, se descrtibe aquí por ser parte importante de cualquier política de seguridad. Desde 1990, la Organización Internacional de Estandarización (ISO) había estado trabajando en el desarrollo de una serie de normas internacionales, para los criterios de evaluación de la seguridad de sistemas de información (ISO/IEC 15408), que son conocidos, popularmente, como los Common Criteria. Finalmente, en mayo de 2000, en Baltimore (EE.UU.), se ratificó la adhesión de Alemania, Australia, Canadá, España, EE.UU., Finlandia, Francia, Grecia, Italia, Noruega, Nueva Zelanda, Países Bajos y Reino Unido, al Convenio sobre el reconocimiento de los certificados de criterios comunes en el campo de la seguridad de la tecnología de la información. Desde entonces, se han incorporado muchos otros países. Antes de entrar en detalles más técnicos, hay que remarcar una serie de ideas y datos importantes sobre tal «convenio: • El conjunto de los países miembros representaban, en 2009, más del 85% del mercado mundial de la tecnología de la información, un dato del European Information Technology Observatory. • 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. • Los certificados de seguridad son expedidos, por Organismos de Certificación reconocidos, a productos o sistemas informáticos, que hayan

202


sido satisfactoriamente evaluados por servicios de evaluación, conforme a los Criterios Comunes (norma ISO/IEC 15408). El convenio, que consta de 18 artículos, 11 anexos y un apéndice, especifica, con detalle, los requisitos que han de cumplir los Certificados de Criterios Comunes, los Organismos de Certificación y los Centros de Evaluación. • Entre los objetivos que motivan el convenio figuran: — Asegurar que las evaluaciones de los productos y sistemas informáticos y de los respectivos perfiles de protección (adecuados a cada caso) 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 evaluaciones de los productos y sistemas informáticos, gracias a la aceptación internacional de los certificados. • Disminuir el gasto del proceso de evaluación y de certificación de los productos y sistemas informáticos y perfiles de protección, en razón de la economía de escala. Se examinarán ahora los conceptos clave de los Criterios Comunes: El perfil de protección - PP. 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 seguridad informática. Se ha desarrollado para soportar la definición de normas funcionales, y como una ayuda a la formulación de especificaciones procedimentales. Los hay para cortafuegos, bases de datos relacionales, sistemas, etc. 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. Cuando el ST dice ser conforme a uno o más PPs, esto forma la base de una evaluación.

203


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: • Auditorias. • Soporte criptográfico. • Protección de datos del usuario. • Identificación y autenticación. • Administración de la seguridad. • Privacidad o confidencialidad. • Protección de las funciones de seguridad del TOE. • Utilización de recursos: tolerancia a fallos, prioridad de servicio, etc. • Canales de comunicación seguros. Los niveles de seguridad evaluada - EAL. Definen una escala de medición de los criterios de evaluación de PPs y STs. Estos niveles son 7, con las siguientes asociaciones de seguridad: • EAL1: Realizadas pruebas de funcionalidad. • EAL2: Realizadas pruebas de estructuración. • EAL3: Realizadas, metódicamente, pruebas y chequeos. • EAL4: Diseñado, chequeado y probado metódicamente. • EAL5: Diseñado y probado semiformalmente. • EAL6: Diseño verificado semiformalmente, y probado. • EAL7: Diseño verificado formalmente, y probado. Hay que añadir que los EALs se han desarrollado con el objetivo, entre otros, de preservar los conceptos de seguridad usados para desarrollos previos. 6.2. El estándar ISO/IEC 27001 Esta norma es otro estándar internacional, publicado en octubre de 2005 y dedicado a la organización de la seguridad de las tecnologías de la información.

204


La norma 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 aproximació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. Son componentes esenciales de un sistema así los siguientes: • Estructura organizativa. • Políticas. • Planificación. • Responsabilidades definidas. • Buenas prácticas. • Procedimientos de actuación. • Procesos de gestión. • Recursos suficientes. Hay que darse cuenta de que 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. Su implementación dependerá de los objetivos establecidos, los requisitos de seguridad, los procesos involucrados y la propia estructura de la organización. Cualquier tipo de organización necesita definir y gestionar muchas actividades para lograr un funcionamiento eficaz y eficiente. Se llama proceso, en este contexto, a una actividad que utiliza recursos y los gestiona para transformar sus entradas en salidas. La identificación, uso, interacción y gestión de un conjunto de procesos por parte de una organización se suele denominar «aproximación por procesos». 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.

205


• 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 (o de Demming). PDCA son las siglas de «Plan - Do - Check - Act» y el modelo se aplica para estructurar todos los procesos del SGSI, así como en muchos otros entornos y marcos generales de buenas prácticas, como ITIL. 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, con el objetivo de conseguir resultados satisfactorios con respecto a los objetivos. • Hacer: implementar y operar los elementos del SGSI: política, controles, procesos y procedimientos. • 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 alcanzar la mejora continua del SGSI. El ISO/IEC 27001 va acompañado, además, de una serie de documentos que lo complementan, siendo alguno de los más significativos los siguientes: • ISO/IEC 27000: un vocabulario estándar para las normas de un SGSI, el único documento gratuito de la familia. • ISO/IEC 27002: Un código de buenas prácticas para la gestión de la seguridad de la información. Ayuda a poner en marcha las prácticas necesarias para cumplir los requisitos exigidos para la certificación ISO/IEC 27001. • ISO/IEC 27004: Un nuevo estándar sobre métricas de gestión de seguridad de la información. • ISO/IEC 27005: El estándar propuesto para gestión de riesgos. • ISO/IEC 27006: Una guía para el proceso de registro y certificación. • ISO/IEC 27007: Una guía para hacer auditorías de un SGSI.

206


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. Es importante señalar que, por ejemplo, en algunos concursos para proyectos, en diferentes sectores económicos, no se puede entrar siquiera a concursar si el servicio que se va a ofrecer no está certificado como ISO/IEC 27001. 6.3. Las buenas prácticas de ITIL™ y la norma ISO/IEC 20000 ITIL (Information Technology Infrastructure Library) es la Biblioteca de Infraestructuras de Tecnologías de la Información. Son un conjunto de 5 libros principales (y muchos más opcionales) que contienen un enorme conjunto de buenas prácticas para la gestión de los servicios de tecnologías de la información. Se han convertido hace ya bastante tiempo en un marco común de implementación para la gestión de tales servicios. ITIL se basa en su idea del ciclo de vida del servicio TI (figura 6.6). Muy brevemente, un servicio TI (servicio de Tecnologías de la Información) 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 (fase de mejora continua).

Figura 6.6. El ciclo de vida de un servicio TI en ITIL.

207


ITIL es una aproximación muy sofisticada de todas las tareas a realizar para ofrecer y controlar 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, que cubren temas muy diversos. Para hacerse una idea baste la enumeración de algunos de los procesos más significativos: • Gestión Financiera del servicio. • Gestión de relaciones con el negocio. • Gestión de niveles de servicio. • Gestión del catálogo de servicios. • Gestión del portfolio de servicios. • Gestión de proveedores. • Gestión de la disponibilidad. • Gestión de la capacidad. • Gestión de la seguridad. • Gestión de la continuidad. • Gestión de los activos del servicio y de la configuración. • Gestión de la entrega del servicio y su despliegue. • Gestión del conocimiento del servicio. • Gestión del cambio. • Gestión de incidencias. • Gestión de problemas en el servicio. • Gestión de eventos. • Gestión de accesos. • Gestión de la mejora continua. Cualquiera de estos procesos de ITIL ejecuta una serie de actividades, que utilizan datos de entrada, crean unos resultados de salida, alineados con los objetivos de cada proceso en particular. Los objetivos se fijan de manera cuantitativa y tienen asociados una serie de métricas que permiten implementar un ciclo PDCA continuo (ver figura 6.7).

208


Figura 6.7. Estructura básica de un proceso de ITIL.

Para llevar todo esto a cabo cada proceso usa una serie de recursos y capacidades, organizadas, a su vez, en funciones. Sin entrar en mayor detalle, las funciones definidas en ITIL son el Centro de Servicio al Usuario, la función de Gestión Técnica, la función de Gestión de Aplicaciones y la función de Gestión de Operaciones TI. 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 de Gestión de la seguridad, que es responsable del diseño de la política de seguridad de cualquier servicio TI que la organización ofrezca o vaya a ofrecer, y de la propia política de seguridad de la organización. ITIL hace aquí un uso exhaustivo de la terminología y de los detalles de la norma ISO/IEC 27001, haciendo especial referencia a la importancia de implantar un SGSI. Este proceso aparece en la fase de diseño del servicio.

209


• El proceso de Gestión de accesos, que es responsable de que se cumpla la política de seguridad diseñada en el proceso anterior para cada servicio. Debe hacer que se cumplan todas las características de privacidad, integridad, autenticación y control de acceso correspondientes. Aparece en la fase de operación del servicio. ITIL nació a finales de la década de 1980 en el Reino Unido, como iniciativa del equivalente al Ministerio de Comercio británico. En 2007 apareció la versión 3 y en 2011 se ha hecho una actualización (no una nueva versión) de textos y procesos, siendo esta actualización la versión última oficial. Es importante señalar que una organización no puede certificarse en ITIL, al no ser un estándar sino un conjunto de buenas prácticas. Sin embargo, si hay certificaciones individuales que, de mayor a menor nivel, permiten alcanzar una certificación de «ITIL fundamentos» a «Experto de ITIL», pasando por varios niveles intermedios. No obstante, ITIL si 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 (como en el caso de ITIL) mucho más allá de la gestión de la seguridad. Como en el caso ya analizado de ISO/IEC 27001 e ISO/IEC 20000 es cada vez más obligatorio para la vida de los proveedores de servicios TI, que ven cómo, en muchos casos, deben tener esta certificación.

210


7. CONOCIMIENTOS Y COMPETENCIAS ADQUIRIDAS La competencia más importante adquirida en este tema es la que implica saber cómo organizar una política de seguridad de las redes de una organización, al menos en sus puntos esenciales. Es evidente que la propia naturaleza de la creación de cualquier política de seguridad hace necesario conocer en detalle múltiples características de la organización para la que se va a desarrollar. Se estaría faltando a la verdad si se dijera que existe una metodología perfecta para la creación de una política de seguridad. No obstante, fuera cual fuera la organización habría que tener en cuenta siempre una serie de factores, que son los analizados en este tema. En este tema se han establecido toda una serie de principios de diseño básicos, que debe cumplir cualquier política de seguridad, así como la importancia de la actualización continua de la política. Igualmente se han enumerado y analizado las normas más habituales y necesarias de cualquier política de seguridad. Se ha puesto de manifiesto la necesidad de ver la seguridad como un proceso continuo, con una serie de fases que se repetirán de forma cíclica. Se ha hecho una introducción de algunas de las leyes españolas más significativas para la creación de cualquier política de seguridad, como la LOPD; la LSSICE y el Esquema Nacional de Seguridad. Igualmente se han introducido algunas de las normas internacionales y marcos de referencia más importantes, que ayudan siempre a la creación de una buena política de seguridad, como el ISO/IEC 15408, ISO/IEC 20000, ISO/IEC 27001 o las buenas prácticas de ITIL.

8. BIBLIOGRAFÍA Y REFERENCIAS AGENCIA ESPAÑOLA DE PROTECCIÓN DE DATOS, URL: http//www.agpd.es ESQUEMA NACIONAL DE SEGURIDAD, URL: https://www.ccn-cert.cni.es/index. php?option=com_content&view=article&id=2687&lang=es BERNARD, P. (2011): Foundations of ITIL®. Ed. Van Haren Publishing. ITIL OFFICIAL SITE, URL: http://www.itil-officialsite.com/

211


ISO 2000 CERTIFICACIÓN, URL: http://www.isoiec20000certification.com/ ISO 27000 DIRECTORY, URL: http://www.27000.org/index.htm ITSMF ESPAÑA, URL: http://www.itsmf.es La protección de datos personales, soluciones en entornos Microsoft, V2.0, libro gratuito, descargable desde URL: http://download.microsoft.com/ download/C/2/6/C2689C05-2B67-4D11-BD2A-43CF9DBCE59E/Libro_ LOPD_V2_Alta.pdf 9. PALABRAS CLAVE AGPD, ENS, ISO/IEC 15408, ISO/IEC 20000, ISO/IEC 27001, ITIL, LOPD, LSSICE, Normas de seguridad, políticas de seguridad. 10. EJERCICIOS RESUELTOS 1. ¿Cuál de los siguientes es un principio que ha de tenerse en cuenta en la elaboración de cualquier política de seguridad? a) b) c) d)

Principio de negación de servicio. Principio de privilegio mínimo. Principio de multiplicidad activa. Principio de organización por procesos.

Solución: b. 2. ¿Cuál de las siguientes NO es una fase del proceso continuo de seguridad, que se basa en la política de seguridad diseñada previamente? a) b) c) d)

Fase de implementación. Fase de monitorización. Fase de planificación activa. Fase de análisis de vulnerabilidades.

Solución: c. 3. ¿De qué nivel de seguridad hay que considerar, con respecto a la LOPD, a los datos personales sobre historia clínica almacenados en un Hospital? a) De nivel alto.

212


b) De nivel bajo. c) De nivel medio. d) Dependerá de si el Hospital es público o privado. Solución: a. 4. ¿Cuál o cuáles de las siguientes instituciones están obligadas al cumplimiento del ENS? a) b) c) d)

La Agencia Tributaria del Estado. La consejería de turismo de una comunidad autónoma. Una universidad pública. Todas.

Solución: d. 5. ¿Cuál de las siguientes NO es una fase del ciclo de vida del servicio TI en ITIL? a) b) c) d)

Fase de Monitorización del servicio. Fase de Estrategia del servicio. Fase de Diseño del servicio. Fase de Operación del servicio.

Solución: a. 11. EJERCICIOS DE AUTOEVALUACIÓN 1. ¿En cuál de las fases PDCA de un SGSI en ISO/IEC 27001 se ubicará la configuración de seguridad de un enrutador? a) b) c) d)

Comprobar. Planificar. Hacer. Actuar.

2. Si una organización mantiene para su trabajo un fichero con los datos de nombre, apellidos, dirección y número de teléfono de sus empleados ¿En qué caso NO está obligado a notificar al RGPD la existencia de este fichero? a) En el caso de tener menos de 50 registros. b) Tiene que notificarlo siempre.

213


c) En el caso de ser un negocio privado. d) En casos de relevancia menor. 3. ¿Cuál de los siguientes procesos de ITIL se encarga de hacer que se cumpla la política de seguridad de cada servicio? a) b) c) d)

Gestión de la seguridad. Gestión de incidencias. Gestión de accesos. Gestión de la continuidad.

4. Si se dispone de un móvil de empresa, ¿cuál de las siguientes normas de una política de seguridad deben tenerlo en cuenta? a) b) c) d)

Política de uso aceptable. Política de acceso remoto. Solo la a. La a y la b.

5. Una empresa proveedora de servicios TI quiere obtener una certificación que demuestre que cumple estándares internacionales sobre gestión de servicios TI, ¿Para cuál o cuáles de los siguientes estándares puede intentar certificar su servicio? a) b) c) d)

214

ITIL. ISO/IEC 15408. ISO/IEC 20000. ISO/IEC 9000.

Tema 7

Introducción a los métodos no criptográficos para la implantación de la política de seguridad

1. Introducción, orientaciones para el estudio y objetivos 2. Herramientas para la puesta en marcha de la política de seguridad 3. Otros elementos a tener en cuenta 4. Conocimientos y competencias adquiridas 5. Bibliografía 6. Palabras clave 7. Ejercicios resueltos 8. Ejercicios de autoevaluación

1. INTRODUCCIÓN, ORIENTACIONES PARA EL ESTUDIO Y OBJETIVOS En este breve tema 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. Se elige tal aproximación por cuestiones didácticas, pero es importante señalar que algunos de tales elementos, como algunos 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. En realidad, aun analizando los dispositivos desde tal punto de vista, se va a intentar hacer énfasis en las funciones que cubren, dentro de la política de seguridad. En primer lugar, se va a hacer una enumeración de cada una de las herramientas y/o procedimientos que implementan funciones de seguridad, sin hacer uso de métodos criptográficos. Cada una de estas herramientas se asocia con una fase del proceso de seguridad analizado en el tema 6. En la misma sección del tema se examinará con más detalle el papel de los cortafuegos, como herramientas fundamentales hoy en día en cualquier red. Después se va a hacer un repaso por el resto de herramientas y procedimientos, definiendo, en una primera aproximación qué es el análisis de logs, las auditorias, qué son los analizadores de vulnerabilidades y qué son los sistemas de detección de intrusiones. Finalmente, se hará referencia a qué se entiende por diseño seguro de redes, que hace énfasis en todo aquello que se puede utilizar para mantener una mejor disponibilidad de las máquinas y sistemas que componen las redes. No se pretende, con este pequeño tema, más que establecer claramente la batería de herramientas disponibles desde puntos de vista no criptográficos, para implantar una política de seguridad en una organización.

217


Igualmente, hay que recordar que ya se han señalado los aspectos más significativos a implantar, dentro de una política de seguridad, en equipos servidores y estaciones de trabajo, en el tema 5. Por esa razón, en los siguientes cinco temas se analizan con detalle las funciones de seguridad que realizan toda otra serie de dispositivos y programas en la red, más relacionados únicamente con la seguridad de la propia red. 2. HERRAMIENTAS PARA LA PUESTA EN MARCHA DE LA POLÍTICA DE SEGURIDAD Vendrá bien volver a recordar lo que se ha denominado el proceso de seguridad, en la figura 7.1. Las herramientas que se van a analizar cubren distintas fases del proceso y se las ubicará en cada una de las fases.

Figura 7.1. Las fases del proceso de seguridad.

Los elementos no criptográficos, que hay que tener en cuenta dentro de la fase de implementación o de puesta en marcha de cada versión de la política de seguridad, son:

218

INTRODUCCIÓN A LOS MÉTODOS NO CRIPTOGRÁFICOS PARA LA IMPLANTACIÓN DE LA POLÍTICA DE SEGURIDAD

• Medidas básicas, físicas y lógicas, analizadas ya en el tema 5, que se citan por completitud, pero de las que no se va a volver a hablar en este tema. • Los cortafuegos, que, como se verá en detalle en los temas siguientes, son dispositivos variados (aunque a todos se haga referencia con el mismo nombre) que implementan una serie de funciones de filtrado de mensajes, basándose en una serie de mecanismos diversos. Hoy en día, cuando se habla de cortafuegos se puede estar haciendo referencia a multitud de distintas soluciones: encaminadores, sistemas operativos configurados de forma especial, aplicaciones que implementan un software de cortafuegos, cortafuegos «personales», cortafuegos de tipo «stateful inspection», etc. Todos ellos juegan el papel de filtrar qué tráfico se permite que circule en uno u otro sentido entre dos o más redes. Hay que recordar que la configuración de tales cortafuegos, más o menos compleja, sea cual sea el tipo al que se refiera, dependerá de lo que se haya decidido desarrollar como política de seguridad. Se puede disponer del mejor cortafuegos del mercado y tener a una persona muy experta en su configuración, pero, si no se tiene clara la política de seguridad, no se sabrá nunca cómo hay que configurarlo. Por hacer un paralelismo, sería como disponer de un gran automóvil y de uno de los mejores conductores, pero no saber cuál es el desplazamiento que se quiere realizar. Dentro de la fase de monitorización (la siguiente fase del proceso de seguridad, e imprescindible en cualquier buena política de seguridad) se debe tener en cuenta: • Los procedimientos clásicos de auditoria 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, así como analizar los distintos registros de auditoria de sistemas, buscando algún registro no fácilmente explicable, teniendo en cuenta la actividad normal del sistema tratado. • Los honeypots, equipos o redes falsos, en el sentido de que desde el nombre hasta los procesos del sistema, incluyendo cuentas de usuario, ficheros de datos, aplicaciones, etc. todo está modificado, creando un entorno, que parece real pero no lo es. El objetivo de este

219


entorno «falso» es capturar la información de los atacantes que accedan a todas las «trampas» colocadas, así como despistarlos haciéndoles invertir su tiempo en sistemas sin información real. • Los sistemas de detección de intrusiones, sistemas aún novedosos en el entorno de seguridad en redes. Como se verá en el tema 11, los hay, como en el caso de los cortafuegos, de diversos tipos, aunque casi todos se dedican a analizar el tráfico de una red, en busca de patrones de ataque, comparando el tráfico recogido con muchos, y muy diversos, patrones. Generalmente pueden lanzar alarmas, generar registros de log, y en algunos casos, parar tales ataques. Asimismo, es importante recordar que si detectan determinados tipos de ataques, no tenidos en cuenta en la política de seguridad, esto debe servir para actualizar la política de seguridad, lo que obligará, probablemente, a cambiar la configuración de alguno de los dispositivos citados para la fase de implementación. Al igual que antes, no basta con disponer de buenos sistemas de detección de intrusiones, hay que saber configurarlos, volcando en ellos las directrices que les atañen, en el marco de la política de seguridad. Para la fase de análisis de vulnerabilidades del proceso de seguridad, se debe tener en cuenta: • Los laboratorios de pruebas, cuyo objetivo es, esencialmente, disponer de una red separada 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, tratando de buscar la mejor, la que sea más eficaz, permitiendo, a la vez, seguir haciendo el trabajo habitual. Tales laboratorios son, en realidad, un lujo que raramente se ve, salvo, quizás, en las propias empresas de seguridad. • Los equipos de ataque, grupos de personas, internos o externos a la organización, que se dedican a buscar posibles vulnerabilidades en sistemas, dispositivos de seguridad, procedimientos de seguridad de cuentas, etc., así como en seguridad física y lógica. Dichos equipos pueden, además, actuar como espías en el sentido de que su labor real sea distinta de su labor oficial. Pueden tener, por ejemplo, como labor oficial el desarrollo de una aplicación para la organización, que les permita moverse libremente por edificios, redes y entre el perso-

220


nal de la organización. Además estos equipos suelen ser denominados los auditores de la organización y su objetivo entra, tanto en esta fase como en la fase de monitorización. Son los «vigilantes» de los «vigilantes». • 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. Primero conviene decidir (esto es, también, parte de la política de seguridad) qué equipos hay que analizar primero y en qué orden. Suelen disponer de distintas configuraciones de análisis, más relacionadas con sistemas operativos o con aplicaciones y, al igual que con otras herramientas citadas, hay que decidir qué configuraciones se utilizan, así como cuál va a ser el criterio de selección de la herramienta concreta. Es cada vez más importante, además, el uso de analizadores especializados en la detección de vulnerabilidades en el código fuente de las aplicaciones, o «Static source code analyzers (SSCA)». Esto es así, especialmente, para las empresas en las que parte del software utilizado es de desarrollo propio. También estos procedimientos y herramientas proporcionan información, que se utiliza para renovar la política de seguridad y hacerla más fuerte, más completa, permitiendo una actualización de los elementos configurados en la primera fase de puesta en marcha, completando así una primera vuelta del proceso de seguridad, e iniciando, con la implementación de los cambios de la política de seguridad, que el proceso siga siendo dinámico. Para acabar esta sección, es importante remarcar la diferencia entre los dos niveles de trabajo con todas estas herramientas: • Un nivel de conocimiento de cómo configurar las herramientas, imprescindible para el día a día de su configuración, pero que no es capaz de determinar, por sí mismo, qué se debe configurar y cómo. • Un nivel de conocimiento de la seguridad deseada, es decir, de la política de seguridad que se debe aplicar, que servirá para guiar la configuración de todos los dispositivos.

221


No es necesario que coincidan en las mismas personas, pero debe quedar claramente estipulada la mayor relevancia del segundo nivel sobre el primero. Puede uno saber muy bien cómo configurar un cortafuegos, pero si no conoce la red, qué servicios deben estar funcionando y cómo aplicar la política de seguridad en cada caso, ese conocimiento sirve de poco. 3. OTROS ELEMENTOS A TENER EN CUENTA La enumeración de dispositivos y herramientas no criptográficas utilizadas para hacer cumplir la política de seguridad no sería completa sin hacer referencia a lo que suele denominarse diseño seguro de redes. Esto hace referencia a la seguridad, en un sentido distinto al usado habitualmente en este libro. En realidad, se estaría hablando, más bien, del concepto de fiabilidad del sistema, de alta disponibilidad de la información. Los procedimientos y herramientas utilizadas para mantener tal fiabilidad 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 que serán analizadas en más detalle en el tema 12: • Unidades de disco redundantes. Casi siempre se trata, en este caso, de alguna combinación de elementos RAID (Redundant Array Inexpensive Disks), que permite añadir más fiabilidad en cuanto al acceso a los datos. • Copia de seguridad de los datos. Los datos de una organización son el sustento de la organización, así que cualquier política de seguridad debe mantener unas normas de mantenimiento de copias de seguridad de tales datos, que tengan en cuenta, incluso, distintas ubicaciones físicas de tales copias. • Tolerancia a fallos de los servidores más significativos. Bien sea con un equipo completamente redundante o mediante una solución de tipo cluster, se debe asegurar que el acceso a determinados datos y aplicaciones siga manteniéndose constantemente.

222


• Un plan de recuperación de la situación actual, tras un posible desastre, que, perfectamente, puede ser un desastre físico. • Una organización de gestión de la red cuyo objetivo sea, esencialmente, mantener funcionando la mayor cantidad de tiempo posible los sistemas de una organización en el mejor estado posible. Obviamente, esto conseguirá atenuar lo más posible las pérdidas ocasionadas por paradas de sistemas.

223


4. CONOCIMIENTOS Y COMPETENCIAS ADQUIRIDAS Mediante este tema se han ubicado una serie de herramientas y programas especializados en seguridad de redes, usados en cada una de las fases del proceso de seguridad detallado en el tema 6. Se ha hecho una presentación breve de las herramientas que, no haciendo uso de ningún algoritmo o protocolo criptográfico, resultan esenciales para la puesta en marcha de un proceso de gestión de la seguridad informática de las redes de cualquier organización. En los cinco temas siguientes se aborda, ya con mayor detalle, el uso de las mismas. No obstante, es importante señalar que cualquiera de ellas (cortafuegos, analizadores de vulnerabilidades, sistemas de detección de intrusiones o herramientas y protocolos de diseño seguro de redes) se ha transformado en una pequeña «disciplina» de conocimiento dentro del cada vez más extenso panorama de la seguridad informática y que, en este libro, se hace únicamente una introducción que, aun intentando contemplar todas sus características, no deja de ser una introducción a cada una de esas sub disciplinas. 5. BIBLIOGRAFÍA CHESWICK, W. R.; BELLOVIN, S. M.; RUBIN, A. D. (2003): Firewalls and Internet Security: Repelling the Wily Hacker. 2.ª edición. Ed. Addison-Wesley Professional. GERG, C. y KERRY J. (2004): Managing Security with Snort and IDS Tools. Ed. O’Reilly. GORDON FYODOR LYON (2009): Nmap Network Scanning: The Official Nmap Project Guide to Network Discovery and Security Scanning. Ed. Nmap Project. LIOTINE, M. (2003): Mission-Critical Network Planning, Ed. Artech House Publishers. PURDY, G. N. (2004): Linux iptables Pocket Reference. Ed. O’Reilly Media. 6. PALABRAS CLAVE Cortafuegos, analizador de vulnerabilidades, sistema de detección de intrusiones, diseño seguro, tolerancia a fallos, copia de seguridad.

224


7. EJERCICIOS RESUELTOS 1. Los cortafuegos son herramientas hardware, configurables siempre sin utilizar criptografía asimétrica. a) Falso, algunos si utilizan tal criptografía. b) Verdadero, sólo utilizan criptografía simétrica. c) Falso, algunos son hardware, otros son software, algunos no usan ningún método criptográfico, otros si, y distintas criptografías simétricas y asimétricas. d) Verdadero, no hay cortafuegos por software. Solución: c. 2. Los analizadores de vulnerabilidades son autoconfigurables y no precisan cualificación ninguna para trabajar con ellos. a) Verdadero, de ahí su popularidad. b) Verdadero, además solucionan siempre el problema que encuentran. c) Falso, necesitan personal con formación TCP/IP para poderlos configurar. d) Falso, hay que saber configurarlos, siguiendo las directrices de la política de seguridad de la organización. Solución: d. 3. Los sistemas de detección de intrusiones son herramientas que sirven, únicamente, para reconfigurar las cuentas de usuarios de los sistemas. a) Falso, son analizadores de vulnerabilidades en cortafuegos. b) Falso, pueden ayudar a reconfigurar cuentas, pero sirven para encontrar muchos ataques por la red en tiempo real. c) Verdadero, de ahí su instalación en sistemas operativos. d) Verdadero, colaboran directamente con el administrador de usuarios de cada sistema operativo. Solución: b. 4. Los cortafuegos son herramientas que se colocan, únicamente, en la frontera entre la red de la organización a proteger y la red Internet. a) Verdadero, de ahí su gran mercado actual. b) Falso, algunos están más allá del encaminador del proveedor de acceso a Internet.

225


c) Falso, sirven también para filtrar tráfico entre distintas redes de la misma organización. d) Verdadero, no podrían colocarse, por problemas de direccionamiento IP, en otro lugar de la organización.. Solución: c. 5. RAID es el nombre de: a) Un cortafuegos de gran ancho de banda. b) Un sistema de detección de intrusiones especializado en ataques a discos. c) Un procedimiento de recuperación frente a desastres. d) Redundant Array Inexpensive Disks, técnicas de obtención de mayor redundancia de datos en discos. Solución: d.

8. EJERCICIOS DE AUTOEVALUACIÓN 1. ¿Para qué se implementan técnicas de tolerancia a fallos? a) Para que no sucedan problemas graves de seguridad relacionados con malas prácticas de los usuarios. b) Para que el hardware o el software proporcionen redundancia frente a eventos negativos para la red y/o los sistemas. c) Para que los analizadores de vulnerabilidades puedan buscar también vulnerabilidades físicas. d) Para evitar completamente los ataques de tipo DOS, o de denegación de servicio. 2. ¿Cuál sería una condición indispensable para el uso correcto de analizadores de tipo SSCA sobre una aplicación? a) Disponer de la última actualización de firmas de código RSA para el SSCA. b) No hay ninguna especial. c) Poder usar el SSCA por la red sobre la aplicación a analizar en un servidor de la misma. d) Disponer del código fuente de la aplicación.

226


3. ¿En qué fase del proceso de seguridad se puede ubicar principalmente a los sistemas de detección de intrusiones? a) No puede ubicarse en ninguna en particular, dependerá de la política de seguridad de la organización. b) En la fase de análisis de vulnerabilidades. c) En la fase de monitorización. d) En la fase de implementación. 4. ¿En qué fase del proceso de seguridad se puede ubicar principalmente a los cortafuegos? a) b) c) d)

En la fase de implementación. En la fase de monitorización. En todas las fases. En la fase de análisis de vulnerabilidades.

5. Si se dispone de dinero para adquirir el mejor cortafuegos del mercado y de un experto en la configuración del mismo, ¿qué más es necesario para hacer un buen uso del mismo de cara a la seguridad de la organización?: a) b) c) d)

Un sistema de detección de intrusiones compatible. No es necesario nada más. Disponer de una política de seguridad que marque la configuración. Disponer de un sistema criptográfico de autenticación asociado al mismo.

227

Tema 8

Introducción a los cortafuegos

1. Introducción, orientaciones para el estudio y objetivos 2. Ventajas, inconvenientes y tipos de cortafuegos 3. Los filtros de paquetes 3.1. Ejemplo: las ACL de los encaminadores Cisco 4. Los gateways de aplicación o servidores proxy 5. ¿Qué se puede mejorar? 6. Conocimientos y competencias adquiridas 7. Bibliografía 8. Palabras clave 9. Ejercicios resueltos 10. Ejercicios de autoevaluación

1. INTRODUCCIÓN, ORIENTACIONES PARA EL ESTUDIO Y OBJETIVOS Históricamente, 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. La seguridad que hay que tener en cuenta para cada equipo sigue siendo muy importante, pero no se puede pensar sólo en ella como una situación completa desde el punto de vista de seguridad, por las siguientes razones: • El número (cada vez mayor) de ordenadores en muchas organizaciones. • La cantidad creciente de entornos heterogéneos, con distintos sistemas operativos, distintas versiones de cada sistema operativo y, muchas veces, actualizaciones, difíciles, de las utilidades de seguridad. • El aumento de usuarios con privilegios de administración, que provoca un verdadero problema a la hora de organizarlos. Un cortafuegos implementa una aproximación basada en red, más que basada en un sistema, a la consecución de la seguridad de redes. Desde un punto de vista ideal, un cortafuegos como el de la figura 8.1, debe tener las siguientes características: • Todo tráfico de «dentro a fuera» y de «fuera a dentro» debe pasar a través del cortafuegos. • Solo aquel tráfico autorizado, basándose en la política de seguridad, puede seguir su camino. • El cortafuegos es completamente inatacable. Ninguno de los cortafuegos actuales cumple estos requisitos completamente, pero todos tratan de acercarse a ellos.

231


Figura 8.1. Un cortafuegos genérico.

Además, al pensar en dónde hacen falta, se puede diseñar una aproximación basada en colocar uno sólo para proteger una sola red o varios para proteger diferentes redes, cada una de ellas con diferentes requerimientos de seguridad. Los objetivos de este tema son que el alumno: • Conozca las ventajas e inconvenientes de esta tecnología. • Conozca los tipos de cortafuegos que se pueden encontrar. • Entienda el funcionamiento básico de los filtros de paquetes. • Entienda el funcionamiento básico de los gateways de aplicación o servidores proxy. • Conozca las diferentes topologías de red que se pueden construir con estos cortafuegos.

232

INTRODUCCIÓN A LOS CORTAFUEGOS

Se empieza el tema presentando por tanto los tipos de cortafuegos y las ventajas e inconvenientes de su uso, para pasar a continuación a describir el funcionamiento de dos de los tipos de cortafuegos que podemos encontrar: los filtros de paquetes y los gateways de aplicación. En el siguiente tema se presentará el resto de tipos de firewall que se pueden utilizar. Se finaliza el tema presentando las distintas arquitecturas de red que se pueden construir para tratar de proteger la red por medio de cortafuegos. 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, como las smartcards o las contraseñas de un solo uso, de manera más eficaz, y económica, que si se hiciera equipo a equipo. • 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, en la que se define el tipo de tráfico que se permite pasar suele ser restrictiva: no se deja pasar ningún tipo de tráfico, salvo el que esté explícitamente permitido. Tal política resulta ser muy segura, aunque hay que tener en cuenta que se deberá analizar cada una de las utilidades cuyo tráfico sea necesario según los usuarios. Se debe remarcar también cuáles son los puntos débiles de los cortafuegos. Entre ellos, se puede señalar: • Su uso puede significar el dejar de utilizar una serie de servicios que, como se verá en las siguientes secciones, no se consideren seguros a través de un cortafuegos.

233


• Pueden provocar una sensación de seguridad falsa para los usuarios y administradores de los equipos «protegidos» por el cortafuegos. • Si no se usan conjuntamente con otras medidas de seguridad se produce la centralización de todas las medidas en un único sistema, por lo que si éste es comprometido dejará a toda la red sin protección. • 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, cuyo objetivo de ataque esté en la misma parte. Igualmente, si el tráfico, originado externamente, no llega a la red que se pretende proteger a través del cortafuegos, éste es completamente inútil contra tal tráfico. Los cortafuegos por tanto solo protegen de ataques que procedan de tráfico que pase a través de ellos. Para acabar esta sección es necesario identificar los distintos tipos de cortafuegos que existen. Aunque no hay una tipología oficial, normalmente se habla de 4 tipos de cortafuegos: • Los filtros de paquetes, que suelen ser (aunque no siempre) encaminadores, que filtran el tráfico basándose en combinaciones de diferentes campos de las cabeceras IP, TCP y UDP de cada mensaje. Estos serán el objetivo de la próxima sección del tema. • 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. También se analizan en este tema. • 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, conforme a lo definido en la política de seguridad. Estos serán el objeto de análisis del siguiente tema. • Cortafuegos híbridos, que suelen tener unas propiedades, que son resultado de la combinación de las propiedades de los citados previamente.

234


Suele hablarse, también, de las distintas formas de combinar cortafuegos, creando lo que se conoce como distintas arquitecturas de cortafuegos, objeto de análisis de otra sección de este tema. 3. LOS FILTROS DE PAQUETES Como se puede ver en la figura 8.2, 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, aunque no necesariamente el único posible, suele ser en la conexión final con el proveedor de acceso a Internet, delimitando claramente la red a proteger.

Figura 8.2. Un filtro de paquetes genérico.

Los filtros de paquetes operan en el nivel de red (o nivel IP) y de transporte (mediante TCP y UDP) de la familia de protocolos TCP/IP y filtran paquetes IP, basándose, para ello, en los valores de algunos campos de las

235


cabeceras de IP y TCP o UDP. Algunos filtros de paquetes ofrecen la posibilidad también de filtrar el tráfico en función del enlace de red del que proceda dicho tráfico. El filtro de paquetes más elemental consiste en un simple encaminador trabajando a nivel de red (o nivel IP), aunque muchas veces esta labor la realice una máquina y un software dedicado a ello. 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. Más concretamente, un filtro de paquetes examina cada paquete entrante por la interfaz en la que está aplicado el filtro y: 1. Obtiene los contenidos de las cabeceras citadas del paquete. 2. Contrasta los valores contra los configurados en las reglas del filtro, ordenadamente. 3. Si cumple lo enunciado en una regla, aplica una de las dos únicas condiciones posibles: lo permite, en cuyo caso el paquete se encaminará a su destino o lo descarta. Las máquinas que actúan como filtros de paquetes pueden tener solo dos interfaces, como la del ejemplo de la figura 8.2 o muchas más. Además, 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, pues se puede aplicar, dependiendo del cortafuegos concreto, sólo a los mensajes entrantes en la interfaz, solo a los mensajes salientes de la interfaz o a todos los mensajes entrantes y salientes. En prácticamente cualquier filtro de paquetes, los campos de las cabeceras que se usan como criterios de filtrado son: • Las direcciones IP origen y destino del mensaje, que viajan en la cabecera de IP. • Los números de puerto origen y destino del mensaje, que son parte de la cabecera de TCP o de UDP. • El tipo de protocolo o número de protocolo, parte de la cabecera de IP, que indica, como ya se vio en el tema 3, el tipo de mensaje IP: si es ICMP, OSPF, TCP, UDP, etc.

236


• 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, pues, aunque la mayor parte de los servidores de aplicaciones IP usan números de puerto normalizados (como, por ejemplo, el 23 para Telnet), los clientes usan números de puerto al azar, por encima de 1023. Es decir, se debe poder contar con operadores relacionales que implementen relaciones como «mayor que», «igual a», etc. Un buen filtro puede, también, permitir filtrar los paquetes dependiendo del interface de origen o destino de los mismos. Estos filtros de paquetes son actualmente muy comunes y, aunque se pueden implementar en paquetes software, que además ofrecen otro tipo de funcionalidad más avanzada (como IPTables), sobre sistemas operativos, lo más común es verlos funcionando en prácticamente cualquier encaminador. La tecnología es bastante simple y, además, son muy transparentes a los usuarios. No obstante, 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 de los filtros concretos. • Si se tiene que hacer una excepción ocasional, puede ser que haya que cambiar toda la configuración, haciendo la situación bastante insegura. • No permiten realizar ningún control a nivel de usuario ni a nivel de datos. No se puede filtrar por valores de campos de las cabeceras de aplicación. • No es fácil filtrar protocolos con más de una conexión activa simultáneamente, como ftp, ni protocolos basados en RPC. • No suelen guardar registro de los accesos de los usuarios. De los casos de protocolos con más de una conexión activa, el más sencillo de ver es el del ftp. En la figura 8.3 se ilustra el estado de las dos conexiones activas cuando se está ejecutando un comando de transferencia de ficheros entre cliente y servidor ftp.

237


Figura 8.3. Conexión ftp estándar.

Lo verdaderamente significativo es que cuando se pide la ejecución de tal comando (que puede ser ls, get, put, mget, etc.), se crea una conexión tcp nueva entre el puerto 20 (ftp-data) y un puerto en el cliente y esta conexión la inicia el servidor. Es decir, si desde la red protegida un cliente hace una conexión a un servidor ftp, se tiene una conexión tcp entre un puerto, por ejemplo el 1400, en el cliente y el puerto 21 (ftp-command) en el servidor, pero, al pedir la transferencia de un fichero, la segunda conexión tcp es entre el puerto 20 (ftp-data) en el servidor y otro puerto, por ejemplo el 1410, en el cliente. Hay una conexión tcp en cada sentido de la comunicación, lo que hace más difícil el filtrado, pues debe haber un filtro en cada sentido, que tenga este hecho en cuenta y que sea capaz de unir la primera con la segunda, pues, de no ser así, existiría un agujero en la seguridad. Hay otros cortafuegos que solucionan este problema manteniendo información, incluso temporal, de cada conexión ftp, pero éste no es el caso para un filtro de paquetes. Una solución, si se debe mantener el filtro de paquetes y no se quiere poner otro tipo de cortafuegos, es usar lo que se denomina el ftp pasivo (Figura 8.4). En este caso, la segunda conexión tcp también se crea desde dentro de la red protegida, evitándose así buena parte del problema. Desgraciadamente, no todos los servidores ftp permiten trabajar en el modo pasivo.

238


Figura 8.4. Conexión ftp en modo pasivo.

Otras aplicaciones muy difíciles de filtrar son aquellas basadas en el entorno RPC (Remote Procedure Call), para las que, como se ve en la figura 8.5, cada servidor RPC tiene asociado un número de puerto que no es siempre el mismo.

Figura 8.5. Llamada típica del entorno RPC.

En la práctica, la aplicación cliente envía un mensaje al portmapper (con número de puerto 111), que es el que conoce, en cada momento, el número de puerto del servidor buscado por el cliente. Estas aplicaciones, como el NFS (Network File System) o el NIS (Network Information Services) están compuestas por una serie de servidores que se «registran», al arrancar, con el portmapper, lo que les hace especialmente difíciles de filtrar. En la práctica, una buena política de seguridad no debe permitir el tráfico de

239


tales aplicaciones si el cortafuegos que hay en medio es sólo de tipo filtro de paquetes. Pero, ¿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, es decir, si se permite pasar dicho paquete o si por el contrario debe ser bloqueado. Hay que tener siempre en cuenta el orden en el que se analizará la tabla de reglas para poder implementar la política de seguridad de forma correcta. Cuanto más complejas sean las reglas y su orden de análisis, más difícil será para el administrador gestionarlas para que implementen dicha política de seguridad. 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. Independientemente de implementaciones específicas, el funcionamiento es similar en todos los casos y se puede ilustrar con el siguiente ejemplo. La figura 8.6 nos muestra la topología de una red hipotética que queremos proteger usando un filtro de paquetes. Dicho filtro de paquetes filtrará todo el tráfico proveniente del exterior hacia las dos subredes internas de la organización.

Figura 8.6. Topología de red del ejemplo de filtrado de paquetes.

240


La tabla 8.1 muestra una hipotética tabla de reglas de filtrado para el filtro de paquetes del diagrama. Tabla 8.1. Ejemplo de tabla de reglas de filtrado 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

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. Por el contrario, todo el tráfico que se reciba proveniente de la red 192.168.1.0 a través del puerto 80 (HTTP) será admitido por el cortafuegos independientemente de la red de destino. 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 (HTTP)? Una de las reglas nos indica que dicho paquete puede pasar y en cambio otra regla 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. Si las reglas se comprueban desde el principio de la tabla hacia el final, se permitirá que dicho paquete pase, ya que la primera regla que se encuentra así lo indica. En cambio, si las reglas se analizan de abajo a arriba el paquete se bloquearía ya que se leerá antes la última regla. Continuando con el análisis de la tabla 8.1, se observa que la segunda regla indica que todo el tráfico que proceda de la subred interna 192.168.1.0

241


con destino cualquier máquina de la subred interna 192.168.0.0 será permitido. Por otro lado, la tercera regla indica que todo el tráfico recibido en la subred 192.168.0.0 será rechazado, independientemente de la red de origen. Considerando que las reglas se interpretan del principio de la tabla al final, la combinación de estas dos reglas indican que a la subred 192.168.0.0 solo podrán llegar paquetes provenientes de la otra subred interna. Pero, ¿son suficientes estas dos reglas para afirmar con total seguridad que a la subred 192.168.0.0 no entrarán paquetes del exterior? Consideremos ahora un atacante con dirección IP 155.15.11.1 que quiere atacar a la dirección IP 192.168.0.5, a la vista de las reglas analizadas, cualquier tráfico proveniente del atacante con ese destino será interceptado y detenido por el cortafuegos, pero ¿qué pasa si el atacante utiliza técnicas de suplantación de dirección IP (IP spoofing) que se explicó en el tema 4? 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, a la hora de configurar las reglas de filtrado es necesario también identificar los interfaces de red por los que ha de llegar los paquetes para que dichas reglas sean efectivas. La tabla 8.2 muestra las reglas de la tabla anterior pero modificadas para tener en cuenta también los interfaces de red a la hora de tomar las decisiones sobre que hacer con los paquetes.

Tabla 8.2. Ejemplo de tabla de reglas de filtrado en la que se especifican los interfaces de red involucrados Origen

Destino

Interfaz origen

Interfaz destino

Protocolo

Puerto

Acción

192.168.0.0

*

eth1

*

*

*

Denegar

192.168.1.0

192.168.0.0

eth2

eth1

*

*

Permitir

*

192.168.0.0

*

eth1

*

*

Denegar

*

124.21.0.0

*

eth0

*

*

Denegar

192.168.1.0

*

eth2

*

TCP

80

Permitir

*

155.15.11.0

*

eth0

*

*

Denegar

242


Ahora cuando el firewall reciba un paquete proveniente del atacante con una IP falsa, por ejemplo la 192.168.1.7, al provenir dicho paquete desde el interfaz de red eth0 no se llegará a aplicar la segunda regla, ya que esta solo se aplica al tráfico recibido desde la interfaz eth2, y por tanto se aplicará la tercera, la cual bloquea todo el tráfico con destino e la subred 192.168.0.0 independientemente del interfaz de red por el que llegue el paquete. Estos ejemplos sirven por una lado para entender el funcionamiento de la tabla de reglas de filtrado y por otro para destacar hasta qué punto debe ser cuidadoso un administrador de sistemas a la hora de definir dichas reglas, así como su orden para que estas implementen correctamente la política de seguridad definida. ¿Qué pasaría si el cortafuegos recibe un paquete que no cumple ninguna de las reglas especificadas? En este caso cabe pensar que se debería aplicar una política restrictiva y no permitir el paso de dicho paquete, pero esto no siempre es así; diferentes implementaciones toman decisiones diferentes para este caso. Independientemente de la implementación, y para evitar este problema, el administrador puede una regla por defecto al final de la lista (en caso de que las reglas se analicen de arriba abajo) que bloquee todo el tráfico que no cumpla ninguna otra regla. La tabla 8.3 muestra cómo quedaría la tabla de reglas de filtrado una vez incorporada esta última. Tabla 8.3. Ejemplo de tabla de reglas de filtrado con reglas por defecto Origen

Destino

Interfaz origen

Interfaz destino

Protocolo

Puerto

Acción

192.168.0.0

*

eth1

*

*

*

Denegar

192.168.1.0

192.168.0.0

eth2

eth1

*

*

Permitir

*

192.168.0.0

*

eth1

*

*

Denegar

*

124.21.0.0

*

eth0

*

*

Denegar

192.168.1.0

*

eth2

*

TCP

80

Permitir

*

155.15.11.0

*

eth0

*

*

Denegar

*

*

*

*

*

*

Denegar

243


Este tipo de reglas por defecto no siempre es necesario que las introduzca el administrador, muchas implementaciones de filtros de paquetes las incorporan directamente. Por ejemplo, los encaminadores Cisco incorporan dicho filtrado restrictivo por defecto en sus listas de control de acceso o ACLs (Access Control Lists). Vamos a investigarlas ahora con algo más de detalle. 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, esencialmente, de dos tipos: standard y extended. Las ACLs de tipo standard están compuestas de una serie de reglas ordenadas (ACE o Access control entry), cada una de las cuales solo usan, como criterio, la dirección IP origen del mensaje, y tienen una sintaxis: router(config)# access-list N {permit|deny} dirección-IP-origen [máscara]

El número N es un valor entre 1 y 99 y sirve para relacionar las reglas de la misma ACL, es decir, todas las reglas de la ACL de número 1 empiezan por «access-list 1...». Las llaves ({}) indican que hay que poner una de las dos opciones: o permit, en cuyo caso se indica que el mensaje puede seguir adelante o deny, en cuyo caso el mensaje se descarta. La «máscara» es opcional, lo que es indicado por corchetes ([]) en la sintaxis de Cisco. Cuando se usa, indica qué bits de la dirección IP previa son significativos. Es un número de 32 bits, en el que los unos y ceros tienen el significado contrario al de la máscara de red típica de las subredes IP. Por ejemplo, 0.0.0.255 implica que los tres primeros octetos de la dirección IP previa son significativos. Así, la combinación: 144.21.12.0

0.0.0.255

indica cualquier dirección que tenga los tres primeros octetos a 144.21.12. Hay que recordar, además, dos puntos importantes, tanto para estas reglas (las 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 coincide con alguna de las reglas de la ACL. Es la condición de «todo lo demás negado por defecto».

244


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 144.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 solo sirve para construir la ACL, pero no la aplica a ninguna interfaz. Para ello, existe otro comando diferente. Para aplicar la ACL a una interfaz concreta, en el caso de los encaminadores de Cisco, 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-if)# 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». Para ilustrarlo con un ejemplo real, se puede ver la figura 8.7. Se quiere dejar pasar hacia dentro todo el tráfico de las redes externas (más allá de la interfaz ethernet-1) excepto el que venga de la red 144.21.0.0. La ACL sería: router(config)# access-list 1 deny 144.21.0.0 0.0.255.255 router(config)# access-list 1 permit any

La segunda línea es obligatoria. Si no se tiene en cuenta, funcionará la «por defecto» ya citada, que es, aunque no se vea, es: access-list 1 deny any

Para aplicar la ACL a la interfaz ethernet-1, los comandos serían: router(config)# interface ethernet-1 router(config-if)# ip access-group 1 in

filtrando así, solamente, el tráfico entrante.

245


Figura 8.7. Redes para el ejemplo de comandos de ACLs.

Las ACLs de tipo extended, comparten todas las demás características de las standard, pero tienen una sintaxis más complicada, atendiendo a que permiten filtrar utilizando muchos otros criterios: router(config)# access-list N {permit|deny} protocolo dir.IP-fuente [máscara-fuente] [op puerto-fuente] dir.IP-destino [máscara-destino] [op puerto-destino]

En este caso, N es un número entre 100 y 199, para indicar que es una lista extended, 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. De hecho, op puede ser: • lt, indicando «menor que».

246


• le, indicando «menor o igual que». • gt, indicando «mayor que», • ge, indicando «mayor o igual que». • eq, indicando «igual a». • ne, indicando «distinto a». • range, que permite expresar un rango de números. Si lo que se busca es, por ejemplo, en la misma topología de la figura 8.7, que se cumpla la siguiente política: • No dejar entrar tráfico Telnet externo, salvo de la dirección 155.15.1.1. • Permitir el tráfico, del tipo que sea, 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

e, igual que antes, la condición implícita por defecto, no permite entrar más tráfico. 4. LOS GATEWAYS DE APLICACIÓN O SERVIDORES PROXY En lugar de soportar filtros a nivel de red y de transporte, como los filtros de paquetes, los servidores proxy soportan filtros a nivel de aplicación. La palabra «proxy» significa «abogar» y esto es, como se analiza en esta sección, lo que hace un servidor proxy o gateway de aplicación. Un cortafuegos de esta tecnología lo es para un protocolo de aplicación, es decir, 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 reside entre los clientes y el servidor real (figura 8.8), 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.

247


Figura 8.8. Arquitectura de servidores proxy.

Desde el punto de vista del usuario, la comunicación se realiza con el servidor real, aunque, realmente, la conexión TCP o UDP se realiza entre el cliente y el servidor proxy. Desde el punto de vista del servidor real, el cliente es, realmente, el servidor proxy. Depende del tipo de servidor proxy, puede ser necesario cambiar algo en el cliente, en el servidor o en ambos, que puede ser el software o determinada parte de la configuración. Un servidor proxy suele, también, proporcionar NAT (Network AddressTranslation), algo que, como se verá en el siguiente tema, proporcionan en realidad casi todo tipo de cortafuegos. NAT oculta las direcciones IP reales de los equipos de la red interna, cambiándolas (en el cortafuegos) por otra (u otras) direcciones IP, antes de que los mensaje 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 operaciones concretas de protocolo, por ejemplo en el caso de ftp, por comandos como get o put, por nombre de usuario o por nombre de fichero. Se podría poner una regla de bloqueo de todos los comandos put y nadie podría subir archivos al servidor.

248


• 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. Solo 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. El nombre del proxy será el único que estará disponible hacia el exterior. Entre los posibles problemas de los servidores proxy están los siguientes: • Al funcionar un proceso proxy por servicio, se debe tener multitud de ellos, si se quiere atender al filtrado de muchos protocolos. • Depende qué tecnología concreta se seleccione, puede pasar que se tenga que usar distintos clientes, servidores o ambos. • Pueden llegar a ser un cuello de botella tremendo para el tráfico. Comparando un proxy con un filtro de paquetes, se puede ver que algunos problemas desaparecen. Por ejemplo, si se trata el problema de ftp, relacionado con el esquema de la figura 8.3, con un proxy, en lugar de un filtro de paquetes, se ve que el problema desaparece. En la figura 8.9, se puede observar cómo, con un proxy entre el cliente y el servidor, el proxy pasa por el servidor de cara al cliente y viceversa. Para poder mantener el estado de las dos sesiones, el proxy cambia el número de puerto al azar usado en las sesiones. Entre los distintos tipos de servidores proxy, se pueden destacar: • Un sistema genérico, SOCKS, que requiere clientes distintos a los típicos, por lo que no resulta ser el más popular. • Sistemas, más o menos populares, como el Proxy Server de Microsoft, un paquete de software que permite hacer proxy de protocolos ftp, http y nntp. • TIS FWTK, de Trusted Information Systems, que incluye distintos tipos de servidores proxy. Entre otros incluye proxies para Telnet, FTP, Rlogin, Sendmail, HTTP, etc.

249


Figura 8.9. El servicio ftp estándar con un servidor proxy.

• Quizás los más significativos en el mundo real, los cortafuegos de tipo «stateful inspection», que, como el Firewall-1 de Checkpoint o el CiscoASA (Adaptative Security Appliance), además de su tecnología particular, pueden configurarse como servidores proxy.

5. ¿QUÉ SE PUEDE MEJORAR? Es éste un campo en continuo cambio. En el momento de escribir este libro existen cientos de distintos de productos. Todo es mejorable, pero más allá de lo ya analizado, suele haber varias aproximaciones: • Trabajar con tecnología «stateful inspection», que se analizará en el siguiente tema, donde veremos dos de las soluciones más extendidas, como son IPTables y Cisco ASA. • Reunir varias de las tecnologías citadas, junto con distintos tipos de sistemas de autenticación, AAA, para crear cortafuegos mucho más sofisticados, también analizados en el tema siguiente. • Bien con los citados hasta ahora, bien con los próximos o con todas las tecnologías disponibles, crear distintas arquitecturas o topologías de seguridad, en torno al cortafuegos.

250


Esta última idea consiste en expandir la idea de una única máquina en la intersección de varias redes, sustituir una máquina por varias. En este contexto, hay que introducir el concepto de red DMZ (o zona desmilitarizada), que es una red directamente enlazada con el cortafuegos que se esté utilizando. Ocupa una tercera interfaz en tal dispositivo (Figura 8.10). Se suele trabajar con una DMZ porque se suele colocar en ella aquellos servicios de la red de la organización que se desea que estén disponibles por Internet, pero que, a la vez, no se quiere tener en las mismas redes de la organización por cuestión de seguridad. Si alguno de tales servicios resulta atacado con éxito, esto no significa obligatoriamente que la red completa resulte comprometida. Como puede verse en la figura 8.10, si los servicios citados estuvieran en la red interna, que protege el cortafuegos, en lugar de en la DMZ, cualquier ataque que los alcance, pondría en peligro toda la red.

Figura 8.10. Topología de una DMZ típica.

251


La robustez de esta aproximación dependerá, claramente, de qué cortafuegos se seleccione y de lo bien configurado que esté, pero es, en sí, una buena idea, dado que se están implementando dos principios de seguridad ya citados: • Hay una defensa en profundidad, los ataques deben de ser capaces de atacar con éxito primero el encaminador y, después, el cortafuegos. • Si se elige un cortafuegos, que no sea también un encaminador, se pone en marcha el principio de diversidad de defensa. Todavía se puede ir más allá y crear una arquitectura más «paranoica», consistente en dos DMZs, una con elementos que son menos atacables, o que son menos sensibles desde el punto de vista de la seguridad, la DMZ externa y otra DMZ más interna, la DMZ interna, llegando a una topología como la de la figura 8.11.

Figura 8.11. Topología de doble DMZ.

Igual que antes, habrá que seleccionar muy cuidadosamente qué tecnología (y producto) se elige para el cortafuegos-1 y para el cortafuegos-2, así como decidir qué servicios van a la DMZ externa y cuáles a la interna. No se debe acabar esta pequeña sección sin comentar una posible dificultad en este tipo de topologías, muy a tener en cuenta: la dificultad de administració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

252


distintas máquinas, con distintas tecnologías, de manera que todas cumplan el papel que tengan asignado en la política de seguridad correspondiente. No se puede finalizar este tema sin antes hablar de la dificultad actual para definir el «perímetro» de seguridad del cortafuegos. Hasta hace unos pocos años la delimitación de qué se consideraba el perímetro interno de la organización y qué se consideraban redes externas era clara. Las organizaciones tenían una o varias subredes internas interconectadas entre si, las cuales se conectaban al exterior a través de uno o varios encaminadores. Los cortafuegos se situaban en esos puntos de acceso y controlaban todo el tráfico que viajaba entre la red protegida y el exterior. Con la proliferación de dispositivos móviles (ordenadores portátiles, netPCs, tabletas, smartphones) la distinción ya no es tan clara. Muchos usuarios disponen actualmente de este tipo de dispositivos portátiles. Cuando estos usuarios se encuentran en las instalaciones de la organización conectan sus dispositivos directamente a la red interna de la organización (habitualmente por medio de redes inalámbricas) y por tanto estarán protegidos por el cortafuegos; Pero cuando los usuarios dejan las instalaciones de la organización, los dispositivos se seguirán conectando a Internet, bien a través de redes de datos móviles, redes inalámbricas abiertas, redes inalámbricas en sus hogares, etc. En ese momento los terminales acceden directamente a la red y no están protegidos por el cortafuegos, son por tanto mucho más susceptibles a ser atacados y comprometidos. Como vemos, en el caso de dispositivos móviles la implantación de un cortafuegos no nos asegura que los datos de dichos terminales están protegidos. Es mas, si uno de esos terminales es comprometido fuera de la organización, cuando se vuelva a conectar a la red de la organización, dependiendo del tipo de ataque recibido pueden suponer una puerta de entrada para el atacante, aprovechando la relación de confianza que pueda tener el dispositivo con el cortafuegos de la organización, o bien puede ser una fuente de infección para el resto de dispositivos de la red. Esta reflexión no hace sino resaltar lo que se ha comentado a lo largo de este tema. Los cortafuegos son una pieza fundamental de las defensas de las organizaciones, pero se deben complementar con otro tipo de medidas, ya que por si solos no son capaces de implementar la política de seguridad establecida.

253


6. CONOCIMIENTOS Y COMPETENCIAS ADQUIRIDAS Como conclusiones más importantes se debe señalar que, hoy en día, un cortafuegos es una obligación para cualquier política de seguridad, pero que no es una solución completa, tal y como podría deducirse de la información de muchos productos concretos. Un cortafuegos no soluciona ningún problema interno que se origine en la red que se pretende proteger, ni puede hacer nada contra ataques realizados mediante tráfico que no pueda analizar. El objetivo de este tema ha sido que el lector adquiera conocimiento de los puntos débiles y los puntos fuertes de los cortafuegos, de manera general. Igualmente, se han presentado los distintos tipos de cortafuegos más significativos, entre los que cabe recordar: • Los filtros de paquetes. • Los servidores proxy. • Los que utilizan tecnología «stateful inspection». • Los que resultan de combinar algunas de las tecnologías previas, conformando, además, distintos tipos de topologías o arquitecturas de cortafuegos, que suelen basarse en la creación de una o más DMZs entre la red a proteger y la red (o redes) insegura. Otro de los objetivos era tomar conciencia de las características fundamentales de los filtros de paquetes: • El uso de filtros, compuestos por sentencias de control ordenadas, comparativas de campos de las cabeceras de nivel de red y de transporte de los mensajes IP, aplicados a una o más interfaces del equipo en que cumplen su función, típicamente un encaminador. • Su sencillez para usos simples, que puede convertirse en gran dificultad si se intenta crear filtros muy complicados. • Su incapacidad completa para el filtro por datos de niveles superiores o para ciertas aplicaciones con más de una conexión, como ftp, o que utilizan RPC, como el NFS. • Falta de registros de eventos en algunos de ellos.

254


Durante el tema se ha tratado, así mismo, de caracterizar lo esencial de los servidores proxy o gateways de aplicación, que podría resumirse en: • Soportan filtros a nivel de aplicación. • Debe existir un filtro por protocolo de aplicación. • Depende de la tecnología utilizada se podrá obligar a cambiar el software del cliente, del servidor o ambos. Y se ha presentado el concepto de red DMZ, una red entre el cortafuego y la red interna, donde poder colocar equipos que, por un lado, interese tener cerca de la red externa y, por otro lado, interese no tener en la propia red interna. También se han analizado distintas topologías posibles en las que se puede combinar las DMZs usando, además, distintos cortafuegos de distintas tecnologías. En el siguiente tema se abordan ejemplo más reales de cortafuegos, desde el IPTables ya citado hasta distintos ejemplos de la tecnología conocida como «stateful inspection» o de filtrado dinámico de paquetes. Esta tecnología ha revolucionado, realmente, las técnicas de control y filtrado de los cortafuegos, permitiendo, por ejemplo, poder filtrar (por tipo de contenido) el tráfico de dentro de una aplicación IP. También se van a analizar formas distintas de combinar las tecnologías de cortafuegos citadas para crear algunos productos que se podrían definir como «supercortafuegos». No obstante, se considera muy importante recordar que sea lo buena que sea la tecnología del producto de cortafuegos concreto, esté lo bien hecha que esté la configuración, un cortafuegos no es más que una herramienta al servicio de la política de seguridad de la organización a la que sirve. 7. BIBLIOGRAFÍA ANDREASSON, O. (2006): IPTables Tutorial (Versión 1.2.2). Descargable desde http://www.frozentux.net/documents/iptables-tutorial/ CHESWICK, W. R.; BELLOVIN, S. y RUBIN, A. (2003): Firewalls and Internet Security: Repelling the Wily Hacker. 2.ª edición. Addison-Wesley Professional. VILLALÓN HUERTA, A. (2012): Seguridad en Unix y Redes (Versión 2.1). Julio, 2012. Descargable desde http://www.rediris.es/cert/doc/

255


8. PALABRAS CLAVE ACL, cortafuegos, DMZ, filtro de paquetes, firewall, gateway, IPTables, proxy.

9. EJERCICIOS RESUELTOS 1. Si se dispone solo de filtros de paquetes como cortafuegos, ¿qué se puede hacer para mantener una política segura para el tráfico NFS entre la red que se desea proteger y la red externa a la organización?: a) Nada, sólo con tal tecnología no se puede implementar ninguna política segura para una aplicación que, como el NFS, use RPCs. b) Disponer dos o más redes DMZ entre las dos redes. c) Hacer que NFS no use la tecnología RPC. d) Sacar el servidor FNS a la primera DMZ. Solución: a. 2. El uso de NAT en un cortafuegos asegura completamente las máquinas internas, al permitirles ocultar su dirección IP real: a) Verdadero, al hacerlo así, el atacante externo no puede direccionar correctamente sus mensajes de ataque. b) Verdadero, NAT es una tecnología de cortafuegos diseñada justamente para eso. c) Falso, esto sólo es verdad para aplicaciones que usan TCP. d) Falso, ocultar su verdadera dirección no evita los ataques. Solución: d. 3. Un servidor proxy es siempre mejor que un filtro de paquetes: a) b) c) d)

Verdadero, pues filtra por datos de niveles superiores. Verdadero, es una tecnología más moderna. Falso, depende de qué problemas se desee resolver. Falso, los filtros de paquetes son, además, encaminadores.

Solución: c.

256


4. Analícese con cuidado las siguientes reglas de filtrado de un cortafuegos, aplicada al tráfico entrante por una interfaz:

Origen

Destino

Protocolo

Puerto

Acción

155.23.42.1

*

*

21

Permitir

*

200.1.1.1

TCP

80

Permitir

*

*

*

*

Denegar

¿Qué tráfico NO permite pasar este filtro? a) El tráfico que no venga de las redes externas al host 200.1.1.1 al puerto 80. b) Todo el que no cumpla las condiciones de las dos reglas de filtrado, por la condición final, y última de la lista, de prohibición por defecto del resto de tráfico. c) El citado por las palabras Permitir de las dos primeras filas de la tabla. d) Todo el que no vaya a un servidor http (puerto 80) o a un servidor ftp (puerto 21). Solución: b. 5. ¿Cuál de las siguientes características no es típica de un cortafuegos?: a) Suele ubicarse entre la red que se desea proteger y una red insegura. b) Suele utilizarse como punto esencial (aunque no único) de aplicación de una política de seguridad. c) Necesita de una configuración especial, distinta de la de un sistema operativo de propósito general. d) Permite centralizar toda la gestión administrativa de la red de la organización. Solución: d.

257


10. EJERCICIOS DE AUTOEVALUACIÓN 1. ¿Cuál de las siguientes NO es una ventaja del uso de cortafuegos?: a) b) c) d)

Son un punto esencial de aplicación de la política de seguridad. Centralizan todas las medidas de seguridad en un único sistema. Permiten centralizar alarmas y registros de tráfico. Soportan técnicas avanzadas de autenticación.

2. Los filtros de paquetes operan: a) b) c) d)

A nivel de red. A nivel de transporte. A nivel de red y transporte. Ninguna de las anteriores.

3. Analícese con cuidado las siguientes reglas de filtrado de un cortafuegos, aplicada al tráfico entrante por una interfaz: Origen

Destino

Protocolo

Puerto

Acción

158.42.0.0

*

*

*

Permitir

*

193.22.34.0

*

*

Denegar

Si llega un paquete desde la dirección 158.42.0.5 con destino 193.22.34.1. ¿Qué pasará con dicho paquete? a) Se le permitirá pasar dado que hay una regla que todos los paquetes provenientes de la red 158.42.0.0 pueden pasar. b) Se denegará su paso dado que hay una regla que establece que todos los paquetes con destino a la red 193.22.34.0 no pueden pasar. c) Dependerá de la política por defecto del servidor. d) Dependerá de la implementación concreta de el cortafuegos y el orden en que se analicen las reglas de filtrado definidas. 4. Los Gateway de aplicación permiten: a) b) c) d)

258

Filtrar el tráfico de red a nivel de aplicación. Simplificar las reglas de filtrado implementadas en el encaminador. Restringir el acceso a los distintos servicios. Todas las anteriores.


5. ¿Qué se entiende por DMZ (o zona desmilitarizada)?: a) Zona de la red de la organización que no está protegida por el cortafuegos. b) Una red directamente enlazada con el cortafuegos en la que se colocan aquellos servicios de red de la organización que no se desea que estén disponibles al exterior. c) Una red directamente enlazada con el cortafuegos en la que se colocan aquellos servicios de red de la organización que de desea estén disponibles al exterior. d) Ninguna de las anteriores.

259

Tema 9

Tecnologías de última generación en cortafuegos

1. Introducción, orientaciones para el estudio y objetivos 2. Caso práctico: el modelo IPTables 2.1. 2.2. 2.3. 2.4. 2.5. 2.6.

Procesado de paquetes en IPTables Sintaxis de las reglas de IPTables IPTables como puerta de enlace de la red Redirección de tráfico entrante (DNAT) Guardar y restaurar reglas de filtrado Herramientas gráficas de configuración

3. Caso práctico: el modelo Cisco ASA 3.1. ¿Qué son los niveles ASA? 3.2. Configuración básica 3.3. Otras características avanzadas 4. Conocimientos y competencias adquiridas 5. Bibliografía 6. Palabras clave 7. Ejercicios resueltos 8. Ejercicios de autoevaluación

1. INTRODUCCIÓN, ORIENTACIONES PARA EL ESTUDIO Y OBJETIVOS Hoy en día, tras unos 20 años de la aparición de los primeros cortafuegos, lo que se podría denominar «última generación» de la tecnología de cortafuegos se basa esencialmente 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 súper dispositivos de seguridad. La tecnología de inspección completa del tráfico se basa en que el cortafuegos pueda obtener, almacenar, manipular y, en definitiva, utilizar información que se obtenga de todos los niveles de comunicación, incluyendo las aplicaciones. Con esa información, el cortafuegos debe decidir si deja pasar el tráfico, lo rechaza, lo encripta, guarda registro, etc. La idea subyacente es que no es suficiente examinar cada mensaje IP de manera aislada, y por tanto hay que hacer un seguimiento de la conexión completa para poder tomar una decisión sobre la misma. Se obtiene información de estado, a partir de comunicaciones pasadas, lo que es un factor importante para controlar las decisiones sobre nuevos intentos de comunicación. Esta tecnología guarda información en una serie de tablas de conexión, especificando toda la información que pueda ser necesaria para la toma de decisiones. Para entenderlo mejor, se recuerdan los tres tipos de tráfico IP, ilustrados en la figura 9.1: • Mensajes IP de aplicaciones basadas en sesiones TCP. • Mensajes IP de aplicaciones basadas en el protocolo UDP. • Mensajes IP de protocolos del nivel de red, tal como ICMP, OSPF, etc.

263


Figura 9.1. Tipos de mensaje IP.

Para la mayor parte de las aplicaciones de usuario, el tráfico es del primer tipo, mensajes basados en sesiones TCP. Para estos mensajes, en este tipo de cortafuegos, se manejan dos tipos de tablas: • La tabla de conexiones semi-hechas o «embriónicas», que mantiene la información necesaria para comprobar si una conexión está aún a medio hacer. • La tabla de conexiones activas, que mantiene la información de cada uno de los mensajes en ambos sentidos de estas conexiones. Vendrá bien recordar el establecimiento de una conexión TCP en tres pasos, tal y como se vuelve a ilustrar en la figura 9.2.

Figura 9.2. Creación de una conexión TCP.

264

TECNOLOGÍAS DE ÚLTIMA GENERACIÓN EN CORTAFUEGOS

La tabla de conexiones «embriónicas» mantiene primero la información de por qué interfaz se ha iniciado el intento de conexión TCP (primer mensaje de los tres que intercambian cualquier cliente y servidor TCP para crear una conexión). Además guarda la siguiente información de este mensaje: • Dirección IP origen del mensaje y, si se hace NAT, dirección IP externa. • Dirección IP destino del mensaje. • Número de puerto origen del mensaje. • Número de puerto destino del mensaje. • Número de secuencia TCP inicial. • Número de secuencia ACK igual a 0. • Opciones de TCP: en este caso, sólo el bit SYN. Si el servidor, residente en una red más allá de otra de las interfaces del cortafuegos, contesta, el mensaje de respuesta debe coincidir con estos valores, es decir, debe contener los siguientes valores: • Su dirección IP origen debe coincidir con la dirección IP destino del primer mensaje. • Su dirección IP destino debe ser la origen del primer mensaje y, si hay NAT, debe ser la dirección IP externa. • Los números de puerto deben estar cambiados. • Su número de secuencia ACK debe ser el número de secuencia TCP del mensaje anterior más uno. • En las opciones de TCP debe haber SYN y ACK. Si se cumplen estas características, y, si no hay otro tipo de filtros (listas de control de acceso o políticas de usuario o aplicación particulares), el cortafuegos dejará pasar este mensaje, a la espera del tercer mensaje de creación de conexión TCP del cliente al servidor. Finalmente, cuando esto suceda, habrá una entrada menos en la tabla de conexiones «embriónicas» y una entrada más en la tabla de conexiones activas. En la tabla de conexiones activas se mantendrá, permanentemente, toda la información de direcciones IP, números de puerto, números de secuencia TCP y ACK y opciones TCP, para poder corroborar que cada mensaje en un sentido corresponde a uno anterior en el sentido contrario.

265


Este procedimiento funciona bien, obligando a trabajar mucho más al sistema operativo y al software o hardware que lo implementa, pero no es perfecto para todas las aplicaciones TCP. Para los mensajes de aplicaciones que usan como transporte el protocolo UDP la situación no es tan sencilla, al carecer este protocolo de mucha de la información que usa la tecnología para los mensajes TCP. Lo que suele hacerse es manejar una tabla de «sesiones» UDP, en la que se guarda la información de la interfaz por la que se inició el tráfico UDP de la aplicación que sea y, además, la información siguiente del mensaje: • Direcciones IP de origen y destino del mensaje. • Números de puerto origen y destino del mensaje. Asociado con esta entrada en la tabla, se inicia un contador de tiempo. Si en menos de ese tiempo llega un mensaje, por la interfaz por la que es esperado, con la información de direcciones y números de puerto cambiados, se le deja pasar, siempre que no haya, igual que antes, otro tipo de filtros que aplicar. No es un método perfecto, pero con UDP no puede haberlo, pues no se dispone de más información. Realmente es efectivo, pues obliga al atacante posible a estar muy atento, tan atento que normalmente no hay este tipo de ataques. Para el tercer tipo de tráfico, mensajes de protocolos del nivel de IP, hará falta, para cada protocolo, un procedimiento especial, al carecer estos protocolos de cualquier tipo de información de estado. Se opta, dependiendo de las versiones de algunos de estos cortafuegos, por no dejar pasar el tráfico, por dejarlo pasar todo o, como en el caso de ICMP, de restringirlo dependiendo del tipo de mensajes. Para ICMP, por ejemplo, se podría permitir el tráfico de tipo «Unreachable destination» y no el de tipo «Echo» o «Echo reply». Las distintas implementaciones de esta tecnología utilizan, con pequeñas variantes, este modelo que se ha descrito. Como se verá en las siguientes secciones la denominación puede ser distinta, pero es el mismo modelo, con sus ventajas y sus inconvenientes, que también se analizan en siguientes secciones. Uno de los inconvenientes es el hecho de que no todas las aplicaciones TCP o UDP permiten aplicar el modelo con seguridad. Por ejemplo, hay muchas aplicaciones multimedia que usan dinámicamente distintos números de puerto, que trabajan con varias sesiones TCP, UDP o de ambos tipos, etc. Cada modelo aplicará sus propias correcciones para tenerlas en

266


cuenta pero no es extraño comprobar cómo, dependiendo del cortafuegos y de su versión, algunas de estas aplicaciones aparecen aún como no suficientemente seguras. Esto permite hilar con el segundo punto que se comentó al principio de la sección: la acumulación de características de seguridad. Los cortafuegos que se analizan en este tema son híbridos, es decir, además de usar la tecnología «stateful inspection» pueden usar, entre otras, las siguientes tecnologías: • Pueden hacer de filtro de paquetes. • Pueden estar configurados, además, como servidores proxy. • Pueden disponer de sistema de detección de intrusiones. • Pueden soportar distintos métodos de autenticación, sea ésta de tipo criptográfica de equipos o de tipo AAA, mediante RADIUS o TACACS/+. • Pueden ser puntos de entrada de redes privadas virtuales, que utilicen protocolos como el IPSec, el L2TP, el GRE, etc. • Pueden permitir gestión local o remota, mediante Telnet, SSH ó SSL. • Pueden tener distintos métodos de seguridad aplicados a distintos tipos de tráfico no convencional, como los relacionados con aplicaciones multimedia. Las características criptográficas se tratarán en temas siguientes, pero se va a analizar, en este tema, el resto de tales características, que hacen de estos cortafuegos una especie de punto neurálgico de control de seguridad, lo cual difumina, a veces, su labor típica de cortafuegos. Como conclusión, se puede afirmar que la frontera entre lo que es un cortafuegos de última generación y lo que no lo es se va difuminando cada vez más, empezando ya a hablarse de aplicadores de seguridad (security appliances), dispositivos de base de tipo cortafuegos, pero que hacen muchas más cosas. Finalmente, hay que dar una explicación sobre la elección de los dos tipos de cortafuegos que se analizan con más detalle: IPTables de la organización Netfilter y Cisco ASA. Hay muchos más en el mercado (como el Checkpoint, por ejemplo) no necesariamente peores, pero ambos representan dos de las soluciones más extendidas y utilizadas en la actualidad, razón por la cual se ha decidido su selección, para dar a este tema un enfoque comple-

267


to, pero también práctico. Representan además dos soluciones distintas en cuanto a filosofía, siendo IPTables un producto de software libre mientras que Cisco ASA es una solución comercial de la compañía Cisco Systems. Los objetivos de este tema son por tanto que el lector comprenda las características de las tecnologías de cortafuegos más novedosas. Para ello se presentan dos de las soluciones de cortafuegos más extendidas en este momento, que ilustraran dos implementaciones reales de dichas tecnologías y sirven como primer acercamiento práctica a dichas soluciones. 2. CASO DE ESTUDIO: EL MODELO IPTABLES Originalmente el paquete cortafuegos más utilizado en entornos Linux era IPChains, pero presentaba una serie de carencias que fue necesario resolver. Como solución a esas carencias la organización Netfilter creó un nuevo producto que llamó IPTables el cual incorpora las siguientes mejoras sobre su predecesor: • Mejor integración con el núcleo del sistema operativo, lo que le confiere una mayor velocidad y fiabilidad. • Inspección stateful de paquetes. El cortafuegos mantiene registro de cada conexión que pasa a través de él y en determinados casos incluso controlará el contenido de esos flujos de conexión. • Capacidad para filtrar los paquetes en función de la dirección MAC o de los flags de las cabeceras TCP. • Posibilita llevar registro del tráfico, permitiendo a su vez determinar el grado de detalle de dicho registro. • Mejora las posibilidades de NAT que tenía originalmente IPChains. • Incorpora funcionalidad especial para limitar flujos de conexiones, útil para bloquear algunos ataques de tipo denegación de servicio (DoS). Hoy en día IPTables viene preinstalado en la gran mayoría de las distribuciones de 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, de manera que el lector pueda entender su funcionamiento e iniciarse en el uso y gestión de la misma.

268


La forma concreta de poner en marcha IPTables dependerá de la distribución exacta de Linux que se esté utilizando. Normalmente en todas ellas IPTables se instala con el sistema, el cual activa IPTables en el arranque (realmente está directamente vinculado al kernel de Linux), solo que inicialmente y por defecto deja pasar todo el tráfico. Será necesario añadir las reglas de filtrado necesarias para que IPTables se adapte a la política de seguridad definida en la organización. 2.1. Procesado de paquetes en IPTables Todos los paquetes que son inspeccionados por IPTables pasan por una serie de tablas o cadenas («chains» de ahí el origen del nombre de su antecesor IPChains). Cada una de estas tablas o colas está dedica a un determinado tipo de actividad y está controlada por un conjunto de reglas o cadenas 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 usados para definir los valores de 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 a las que se irán añadiendo las 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 se corresponde a la que gestiona la traducción de direcciones de red (NAT - Network Address Translation). Esta tabla contiene dos cadenas a las que se irán añadiendo las reglas de filtrado correspondientes: • 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.

269


La tabla 9.1 muestra un resumen de las distintas tablas que componen IPTables y sus correspondientes cadenas, indicando a su vez la función de cada una de ellas. Tabla 9.1. Resúmen de tablas y cadenas de IPTables Tabla

FILTER

NAT

MANGLE

Función

Filtrado de paquetes

Cadena FORWARD

Filtra paquetes dirigidos a la red protegida.

INPUT

Filtra paquetes destinados al cortafuegos.

OUTPUT

Filtra paquetes procedentes del cortafuegos.

PREROUTING

Cambia la dirección IP de destino. Destination NAT o DNAT.

POSTROUTING

Cambia la dirección IP de origen. Source NAT o SNAT.

Network AddressTranslation

Modificación cabeceras TCP

Función de la cadena

Modificación del os bits QoS de las cabeceras TCP.

Inicialmente los paquetes son examinados por la cadena PREROUTING de la tabla Mangle y comparados con las reglas que se hayan añadido en dicha cadena. A continuación se examinarán en la cadena PREROUTING de la tabla NAT y comprobará si es necesario modificar la dirección IP de destino (DNAT). Una vez inspeccionado por estas dos cadenas el paquete es encaminado. Si el destino del paquete se encuentra en la red protegida por el cortafuegos será inspeccionado por las cadenas FORWARD de las distintas tablas. En este caso 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 (o red destinataria) final. Si el destinatario del paquete es el propio cortafuegos, el paquete pasará por las cadenas INPUT 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 cortafuegos pasarán por la cadena OUTPUT. La figura 9.3 muestra el diagrama de flujo que siguen los paquetes a través de las distintas tablas y cadenas de IPTables.

270


Figura 9.3. Diagrama de flujo de un paquete en IPTables.

271


2.2. Sintaxis de las reglas de IPTables A continuación se expone la sintaxis básica de las reglas de IPTables. Antes es necesario recordar el funcionamiento básico de un filtro de paquetes. Cuando un paquete llegue al cortafuegos este irá pasando por las distintas tablas y cadenas en el orden en que se ha presentado en el apartado anterior. 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. Es importante recordar que 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 -[tipo_operacion][cadena] -[parámetros] –j

Si no se especifica una tabla a la que añadir la regla IPTables considerará por defecto que se quiere añadir a la tabla Filter. La tabla 9.2 muestra los posibles tipos de operación que se pueden definir, y que irán seguidos del nombre de la cadena que afecta. Tabla 9.2. Tipos de operaciones en IPTables Operación

Descripción

-A

Añadir la regla al final de la cadena indicada.

-F

Borrar todas las reglas de la cadena indicada.

-L

Listar las reglas de la cadena indicada.

-P

Añadir una acción por defecto a la regla indicada.

La opción de añadir reglas por defecto permitirá establecer una acción a realizar para todos los paquetes que no cumplan ninguna otra regla. Si

272


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

Como se ha indicado anteriormente, al no indicar la tabla sobre la que aplicar la regla iptables las reglas del ejemplo se añadirán a las cadenas INPUT, OUTPUT y FORWARD de la tabla filter. Las reglas mostradas establecen por defecto la acción DROP para las tres cadenas de la tabla filter. Esta es solo una de las acciones que se pueden definir para las reglas IPTables. La tabla 9.3 muestra las acciones más comúnmente utilizadas. Tabla 9.3. Acciones más comunes para las reglas IPTables Acció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
[-][:]

MASQUERADE

Para hacer NAT de origen. Por defecto la dirección IP de origen es la que usa el interfaz de red del cortafuegos.

Además de indicar la tabla, cadena y operación a realizar será necesario establecer criterios de filtrado. Estos criterios de filtrado van a permitir definir a qué paquetes se debe aplicar dicha regla. Para ello se podrán

273


utilizar las direcciones de origen y/o destine del paquete, el interfaz de red por el que llega el paquete, el tipo de protocolo, etc. Los distintos filtros permiten además establecer una serie de modificadores que permiten ser más granular a la hora de especificar los paquetes, que son objetivo de una determinada regla. La tabla 9.4 muestra algunos de los filtros que se pueden utilizar con IPTables, mientras que la tabla 9.5 muestra algunos de los modificadores más comunes a utilizar con dichos filtros. Tabla 9.4. Criterios de filtrado habituales Filtro

Descripción

-p

Permite especificar el protocolo de red del paquete (tcp, udp, icmp…).

-s

Permite especificar la dirección IP de origen.

-d

Permite especificar la dirección IP de destino.

-i

Permite especificar el interfaz de red de entrada del paquete.

-o

Permite especificar el interfaz de red de salida del paquete.

Tabla 9.5. Modificadores de filtrado habituales Modificador

Descripción

-p tcp –-sport

Permite especificar el puerto TCP de origen del paquete.

-p tcp –-dport

Permite especificar el puerto TCP de destino del paquete.

-p tcp --syn

Permite especificar paquetes de inicio de conexión TCP (que lleven el flag SYN activado).

-p udp --sport

Permite especificar el puerto UDP de origen del paquete.

-p udp --dport

Permite especificar el puerto UDP de destino del paquete.

--icmp-type

Permite filtrar por el tipo de petición ICMP. Los valores más usados son echo-reply y echo-request.

274


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 si se hubiese especificado –t filter. • Se ha seleccionado la operación –A lo que 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. Si por ejemplo queremos marcar todo el tráfico proveniente de un rango especifico, por ejemplo una clase C podríamos especificar el rango con la opción –s 192.168.1.0/24 (que 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 interfaz de red eth1. • -d 192.168.1.50 indica que se aplicará al tráfico cuyo destino sea la dirección 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 (http). • Por último –j ACCEPT indica que dicho tráfico será permitido. Como se puede apreciar IPTables presenta una gran cantidad de opciones para poder especificar el tipo de tráfico que se desea filtrar. Así, es fácil pensar en otras reglas de ejemplo. La siguiente regla indicaría a IPTables que debe permitir todo el tráfico ICMP entrante, independientemente de la dirección a la que vaya dirigido: #iptables –A INPUT –p ICMP –s 0/0 –j ACCEPT

Si se quiere consultar la lista de reglas de filtrado que se han añadido a IPTables en un determinado momento se puede hacer por medio de la ejecución del siguiente comando, el cual mostrará dicha lista por pantalla: #iptables –L

275


Es necesario recordar, que las acciones DROP o REJECT provocarán que el paquete sea desechado y por tanto no se comprobarán el resto de reglas de la cadena. Esto debe ser tenido en cuenta cuando se quiere registrar esos paquetes desechados por medio de las acciones LOG. Para ello será necesario incluir además de la regla de rechazo una regla LOG par exactamente las mismas condiciones que registre el paquete que se va a rechazar. 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 y por tanto no se incluirá la entrada correspondiente en el log del IPTables. Las siguientes reglas muestran un ejemplo de las reglas que sería necesario incluir para registrar y rechazar todo el tráfico ICMP entrante, así como el orden en que se deben definir para su correcto funcionamiento. #iptables –A INPUT –p ICMP –j LOG #iptables –A INPUT –p ICMP –j DROP

En cualquier momento se pueden eliminar las reglas de la tabla y cadena que se desea por medio de la acción -F. Recordar, que si no se indica ninguna tabla, el borrado se aplicará sobre la cadena correspondiente de la tabla Filter. #iptables –F INPUT #iptables –F FORWARD #iptables –F OUTPUT

2.3. Uso de IPTables como puerta de enlace de la red Las opciones de van a permitir configurar el cortafuegos como puerta de enlace de la red interna que protege. Para ello se podrá configurar IPTables para que por defecto permita el tráfico saliente y en cambio bloquee el tráfico entrante. #iptables –P INPUT DROP #iptables –P FORWARD DROP #iptables –P OUTPUT ACCEPT

Al hacer esto se permitirá el tráfico saliente pero en cambio se estaría bloqueando el tráfico entrante relacionado con dichas conexiones, es decir el tráfico entrante que se origina como respuesta a peticiones de tráfi-

276


co originadas desde la red protegida. Por ejemplo, una maquina interna podría lanzar una petición a una página web alojada en un servidor externo, 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 (de la tabla Filter) para permitir el tráfico relacionado con conexiones salientes: #iptables –A INTPUT –m state --state ESTABLISHED,RELATED –j ACCEPT

Una vez añadida la regla, será necesario permitir la retransmisión de paquetes por el núcleo del sistema operativo. Por defecto esta opción viene desactivada, para activarla será necesario ejecutar el siguiente comando: #echo 1 > /proc/sys/net/ipv4/ip_forward

A continuación habrá que añadir una regla a la tabla NAT de forma que permite hacer NAT de origen, sustituyendo 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 FORMARD –i eth0 –m state --state ESTABLISHED,RELATED –j ACCEPT

2.4. Redirección de tráfico entrante (DNAT) Si dentro de la red protegida (o en una DMZ conectada al cortafuegos a través de un tercer interfaz de red) hay alojados servidores que se desean hacer públicos (servidor web, servidor de correo…) será necesario usar las

277


opciones NAT de destino (DNAT) que presenta IPTables 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 correspondiente a dicho servicio. En el caso de 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 http a la dirección IP del servidor web (en el ejemplo 192.168.1.50). #iptables –t nat –A PREROUTING –p tcp --dport 25 –j DNAT –to 192.168.1.50

Así mismo 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 de origen la dirección IP del cortafuegos, el cliente de correo habrá lanzado la petición a dicha IP y esperará la respuesta de dicha 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

2.5. Guardar y restaurar reglas de filtrado Las reglas que se vayan definiendo se irán añadiendo a las diferentes tablas y cadenas. Debemos tener en cuenta que una vez se reinicie el cortafuegos dichas reglas se perderán y el cortafuegos volverá a su estado original, que en el caso de la mayoría de las distribuciones Linux es permitir todo tipo de tráfico.

278


Para evitar la pérdida de las reglas configuradas en el cortafuegos se podrá usar el comando iptables-save para guardar dicha configuración en un fichero. Para ello se ejecutará el siguiente comando: #iptables-save>cortafuegos.cfg

Así mismo, una vez reiniciado el cortafuegos será necesario usar el comando iptables-restore para volver a cargar las reglas almacenadas en el fichero de configuración guardado en el paso anterior: #iptables-restore cortafuegos.cfg

Hay que tener en cuenta que esto solamente restaurará la configuración de reglas de filtrado. En caso de que el cortafuegos haya sido configurador para funcionar como puerta de enlace de la red interna será necesario volver a activar la retransmisión de paquetes en el kernel del sistema. Por ello será necesario ejecutar el comando: #echo 1 > /proc/sys/net/ipv4/ip_forward

Este proceso de salvaguarda y restauración de las reglas de filtrado presenta dos problemas: • No es capaz de cargar los módulos necesarios (por ejemplo las funciones de retransmisión de paquetes en el kernel). • El proceso de restauración no es automático. Para evitar estos problemas existe la posibilidad de crear un script sh que se podrá configurar para ser ejecutado al iniciar el sistema. El script (que en el ejemplo llamaremos cortafuegos) deberá guardarse en el directorio en el que se alojan los scirpts que se desean ejecutar en el arranque: /etc/network/if-pre-up.d/cortafuegos

Sera necesario cambiar sus permisos (hay que darle permisos de lectura) y cambiar su propietario a root. Para ello se ejecutarán los comandos: #chmod +x /etc/network/if-pre-up.d/cortafuegos #chownroot:root /etc/network/if-pre-up.d/cortafuegos

A partir de ese momento en el arranque del sistema se ejecutará el script y este añadirá las reglas configuradas y pondrá en marcha los módulos necesarios.

279


Dentro del script, tanto las reglas como la activación de módulos se pueden hacer en el orden deseado, pero habitualmente se suele seguir el siguiente esquema: 1. Opciones de configuración: En esta sección se definirán constantes que posteriormente podremos utilizar en las reglas. Podremos definir constantes para los interfaces de red, sus IPs, IPs de servidores, etc. De esta forma si por ejemplo cambia la dirección IP de un servidor, solo será necesario cambiar la definición de su constante, y no todas las reglas que se refieran al mismo. 2. Activación de módulos necesarios: como el módulo de retransmisión de paquetes del kernel. 3. Reglas correspondientes a las políticas por defecto de las diferentes tablas y cadenas. 4. Lisado de reglas IPTables. A continuación se muestra el contenido de un script de ejemplo. #!/bin/sh # # cortafuegos - Script para iniciar el cortafuegos al iniciar el sistema. ################################################################################# # # 1. OPCIONES DE CONFIGURACION # ################################################################################# # 1.1 Configuración internet INET_IP=»192.168.0.50» INET_IFACE=»eth0» INET_BROADCAST=»192.168.0.255» # 1.2 Configuración red local LAN_IP=»192.168.56.50» LAN_IP_RANGE=»192.168.56.0/24» LAN_IFACE=»eth1» # 1.3 Configuración localhost LO_IFACE=»lo» LO_IP=»127.0.0.1»

280


# 1.4 Servidores activos SERV_WEB=»192.168.56.10» SERV_SMTP=»192.168.0.50» ################################################################################# # # 2. CARGA DE MODULOS NECESARIOS Y ACTIVACION IP_FORWARD # ################################################################################# echo 1 > /proc/sys/net/ipv4/ip_forward ################################################################################# # # 3. POLITICAS Y REGLAS DEL CORTAFUEGOS # ################################################################################# # 3.1 Establecemos las políticas por defecto. iptables -P INPUT DROP iptables -P OUTPUT ACCEPT iptables -P FORWARD DROP # 3.2 Regla que permite el trafico entrante de respuesta a trafico saliente iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # 3.3 Permitimos el trafico ICMP entrante iptables –A INPUT –p ICMP –j ACCEPT # 3.4 Reglas para que nuestro cortafuegos sea el gateway de nuestra red interna. iptables -t nat -A POSTROUTING -o $INET_IFACE -s $LAN_IP_RANGE -j MASQUERADE iptables -A FORWARD -o $INET_IFACE -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -i $INET_IFACE -m state --state ESTABLISHED,RELATED -j ACCEPT # 3.5 Permitimos el trafico al servidor web y añadimos las reglas nat necesarias iptables -A INPUT -p tcp --dport 80 -j ACCEPT iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to $SERV_WEB iptables -t nat -A POSTROUTING -p tcp --dport 80 -j SNAT --to $INET_IP iptables -A FORWARD -p tcp --dport 80 -j ACCEPT # 3.6 Permitimos el trafico al servidor SMTP iptables -A INPUT -p tcp --dport 25 -j ACCEPT # 3.7 Bloqueamos los paquete ICMP salientes de tipo «time tolive exceded» iptables -A OUTPUT -p ICMP --icmp-type 11 -j DROP

281


2.6. Herramientas gráficas de configuración Esta guía se ha centrado en la configuración de IPTables por medio de una Shell de comando. Aunque esta es quizás la forma de administración más utilizada por los administradores de sistema, existen herramientas gráficas, como FWBuilder, que tratan de simplificar el proceso de creación de reglas de filtrado, o al menos hacer su generación más intuitivo. Estas herramientas permiten la creación de las reglas por medio de un interfaz gráfico. La figura 9.4 muestra una captura de pantalla del interfaz gráfico presentado por FWBuilder. Este tipo de herramientas permite definir las reglas por medio de su interfaz gráfica. Una vez definidas el programa compilará dichas reglas y generará un script de configuración, similar al visto en el apartado anterior, que se deberá copiar en el directorio de sistema correspondiente para que se ejecute durante el arranque del cortafuegos.

Figura 9.4. Interfaz gráfico de FWBuilder.

282


3. CASO DE ESTUDIO: EL MODELO CISCO ASA ASA (Adaptive Security Appliance) es el nombre genérico de toda una familia de dispositivos de Cisco Systems™ (desde el modelo 5505 al 5580), herederos de los antiguos Cisco PIX. A diferencia de estos, los dispositivos ASA combinan en una sola máquina características avanzadas de cortafuegos de tipo «stateful inspection» y de tipo filtro de paquetes, junto con las características de un sistema detección de intrusiones muy potente y de punto de conexión a una red privada virtual. Algunas de las características más significativas de los ASA son: • Sistema operativo especial (Finesse), único para todos los modelos, de tiempo real y alto rendimiento, sin ninguno de los problemas de seguridad típicos de UNIX o Windows. • El algoritmo ASA (Adaptive Security Algorithm), que es el responsable del control de conexiones basado en el método de «stateful inspection». Podría decirse que es el «cerebro» del dispositivo ASA. Todo el resto de características de seguridad del dispositivo son consistentes con el algoritmo. • Un método de autenticación de usuarios, denominado «cut-through proxy», una especie de servidor proxy de alto rendimiento, tanto para conexiones entrantes como salientes, que soporta autenticación local en el propio ASA o basada en servidores de autenticación AAA. • Soporte completo de los protocolos IPSec y SSL, lo que permite crear redes privadas virtuales de cualquier tipo. • NAT (Network Address Translation) y PAT (Port Address Translation), tanto para conexiones entrantes como salientes. • Soporte de filtros estáticos como las listas de control de acceso de los encaminadores de Cisco Systems. • Gestión de seguridad de múltiples protocolos avanzados. • Filtros de control de contenidos. • Soporte de detección de intrusiones. • Capacidad de redundancia, mediante la topología failover, de dos cortafuegos ASA.

283


• Capacidad de encaminamiento dinámico, mediante múltiples protocolos, incluyendo RIP y OSPF. • Capacidad de administración local, mediante el juego de comandos del sistema operativo, o remota, mediante el ASDM (ASA Device Manager), una aplicación https, basada en html gráfico. Aunque es obvio que abarcar todas y cada una de las características sería imposible, dado el objetivo de este libro, que no es un libro de productos, se van a describir algunas de las capacidades no criptográficas más relevantes del ASA. 3.1. ¿Qué son los niveles ASA? Primero hay que aclarar un poco más el algoritmo ASA que, como ya se ha dicho, es el «cerebro» del dispositivo ASA. Para ello hay que decir primero que cada una de las interfaces del ASA tiene asociado lo que se conoce como nivel de seguridad, un número entre 0 y 100 que determina la seguridad de los mensajes que le llegan al ASA por cada una de ellas. Un ASA puede tener hasta 12 interfaces físicas distintas (muchas más virtuales, pero la explicación detallada de esto va más allá de los objetivos de este libro), pero hay siempre al menos 2, la que recibe el nombre de inside, con nivel de seguridad 100 y la outside, con nivel de seguridad 0. Estos niveles y nombres pueden cambiarse (aunque no suele hacerse) y determinan, claramente, la red considerada más segura y la considerada más insegura. Una topología típica de una red con un ASA podría ser la de la figura 9.5, en la que se ve que, además de las dos interfaces citadas, hay una tercera, llamada dmz, con nivel de seguridad 50. Como ya se ha comentado, los nombres y niveles de las interfaces son completamente configurables por el administrador del ASA. Los niveles de seguridad ASA indican si una interfaz es más fiable (está más protegida) o menos fiable (está menos protegida), desde un punto de vista relativo, una con respecto a otra. Una es más fiable si tiene un nivel de seguridad mayor que la otra, y esto determina cómo funcionan las reglas del ASA, que se pueden resumir en: 1. Como situación por defecto (luego veremos que por supuesto este comportamiento puede cambiarse, mediante listas de control de acceso), desde cualquier interfaz con un nivel de seguridad mayor que

284


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

otra interfaz, se puede enviar tráfico a esta segunda. En la figura 9.5, está permitido el tráfico desde la inside a la dmz o a la outside. 2. A la inversa, desde cualquier interfaz con un nivel de seguridad menor que otra, no se puede acceder, a menos que haya una lista de control de acceso (ACL) que lo permita, lo que, además, se denomina una excepción del ASA. Sin ACL y en la figura, esto significa que desde la outside no se permite tráfico a la dmz ni a la inside; tampoco desde la dmz a la inside. 3. La red que se desee proteger más debe estar conectada a la interfaz inside, al ser ésta la más segura. De esta forma, nadie puede acceder a esta interfaz, salvo que esté específicamente permitido y, por otro lado, cualquier dispositivo en esta interfaz puede tener acceso, salvo otros filtros en contra, hacia fuera de la red de la organización. 4. La red en la que confiemos menos debe estar conectada a la interfaz outside, por ser ésta la de menor seguridad. 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 (aunque puede también cambiarse este comportamiento), entre dos interfaces con idéntico nivel de seguridad, no hay tráfico.

285


3.2. Configuración básica Cisco hace énfasis en que, una vez instalado físicamente el ASA, sólo se necesitan seis comandos de configuración para que esté funcionando, asegurando los equipos internos con respecto a conexiones desde interfaces más externas. 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, manualmente o configurándola como cliente DHCP, 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. Si no se desea NAT, hay que usar una forma especial del comando, que es, en este caso, nat 0. • Definir rutas estáticas o por defecto para cada interfaz, al menos para la interfaz outside, con el comando route. Además, puede hacerse todo esto, también como configuración inicial, desde la interface gráfica del ASDM. Con esta configuración mínima, el ASA protege completamente la red de la interfaz inside, lo cual no suele ser interesante en todas las conexiones. Hace falta crear excepciones al ASA. Para ello, primero se crean asociaciones estáticas de direcciones IP internas con direcciones IP externas (NAT estático) mediante el comando static, lo que va a permitir hacer referencia, en los siguientes comandos, a direcciones IP internas mediante sus referencias externas. Después, se crean los filtros de excepción, lo que se realiza mediante el comando access-list, que crea una lista de acceso igual que si fuera un encaminador de Cisco y el comando access-group, que la aplica en una interfaz. En el caso del ASA, la aplicación de la lista de acceso es sólo al tráfico entrante. Cada asociación NAT (estática o dinámica), que se produce al atravesar el ASA un mensaje, habitualmente desde una interfaz más segura a una menos segura, crea una estructura de gestión interna del ASA, conoci-

286


da como xlate, que se mantiene mientras que exista alguna conexión TCP (o sesión UDP) asociada con ella. Hay que darse cuenta de que asociadas con una xlate puede haber múltiples conexiones, por ejemplo, entre una dirección IP interna y otra externa puede haber, simultáneamente, una conexión http y una conexión ftp. 3.3. Otras características avanzadas del ASA Una de ellas es su capacidad de filtro de lo que Cisco llama «código activo», específicamente applets de Java y controles de ActiveX. Concretamente se puede conseguir que no se descargue ningún applet de Java o control de ActiveX desde una dirección IP (o dirección de red) sospechosa, mediante los comandos filter java y filter activex. También hay que resaltar la capacidad de filtrar peticiones http a direcciones url (Universal Resource Locator) concretas, permitiendo decidir qué sitios web no deben poder visitarse desde una red concreta. Como se ve en la figura 9.6, el ASA así configurado pregunta a un servidor de filtrado (por ejemplo, el Websense server) si la dirección url está permitida o no, antes de permitir el acceso. Esta característica se implementa definiendo el servidor de filtrado con el comando url-server y configurando el filtro con el comando filter url. 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. Algunas de las aplicaciones cubiertas por esta capacidad son: • Domain Name System (DNS). • Hyper Text Transfer Protocol (HTTP). • Distributed Computing Environment Remote Procedure Calls (DCERPC). • Extended Simple Mail Transfer Protocol (ESMTP). • File Transfer Protocol (FTP). • H323. • Internet Control Message Protocol (ICMP).

287


Figura 9.6. Filtrado de direcciones URL con ASA.

• Instant Messenger (IM). • NetBIOS. • Point to Point Tunneling Protocol (PPTP). • Remote Shell (RSH). • Real-Time Streaming Protocol (TSP). • Session Initiation Protocol (SIP). • Simple Network Management Protocol (SNMP). • SQL*NET. • Trivial File Transfer Protocol (TFTP). • X Display Manager Control Protocol (XDMCP). Aunque se vaya a hacer una exposición mucho más completa en el tema 11 de los sistemas de detección de intrusiones en general, ha de citar-

288


se al menos que el ASA dispone también de un IDS, un módulo hardware llamado AIP-SSM (Advanced Inspection and Prevention Security Services Module). Este módulo proporciona servicios de IDS muy avanzados. El ASA soporta también AAA, autenticación, autorización y contabilidad (accounting) 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 (ya sean éstas más externas o más internas), 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, antes de poder seguir adelante. Esta autenticación consiste en demostrar la identidad mediante un nombre de usuario y una contraseña, que no tienen por qué ser (y normalmente no lo serán) los mismos datos que los necesarios para conectarse al servidor al que se desea hacer la conexión. La base de datos de usuarios contra la que se contrasta la información de autenticación puede ser local, configurada en el ASA o remota. En este último caso, mediante protocolo RADIUS o protocolo TACACS/+, el ASA le pide al servidor AAA la validación del usuario, como puede verse en la figura 9.7.

Figura 9.7. La operativa típica del mecanismo cut-through proxy.

289


Es importante remarcar que este mecanismo puede habilitarse para conexiones entrantes (o de interfaces de menor seguridad a interfaces de mayor seguridad), por ejemplo para controlar el acceso remoto de usuarios a servidores web internos de la organización, para conexiones salientes (o de interfaces de mayor seguridad a interfaces de menor seguridad), por ejemplo para controlar el acceso a servidores en zonas perimetrales o en Internet, desde máquinas internas de nuestra organización. Para entender un poco mejor el mecanismo concreto AAA implementado, hay que analizar cómo se hace la configuración, tanto en el ASA como en el servidor AAA concreto. En el ASA, hay comandos para: • Especificación de servidores AAA, sean RADIUS o TACACS/+, indicando su dirección IP, una clave que se utiliza para encriptar los mensajes entre el ASA y el servidor AAA y un temporizador de petición de retransmisión, para cuando el servidor AAA no responde. • Puesta en marcha de la autenticación, indicando qué servicios la van a necesitar, qué direcciones IP origen y destino estarán implicadas, en qué interfaces y qué servidores AAA se usarán como autenticadores. • Puesta en marcha de la autorización, con casi el mismo tipo de necesidades de configuración. • Puesta en marcha de la contabilidad (o accounting) del uso de recursos por parte de los usuarios. • Si hay servidores con los que se desea establecer conexiones que tengan particularidades de autenticación (como el caso del Internet Information Server de Windows), se puede usar lo que se llaman servidores virtuales de autenticación, de los que el ASA dispone de uno para el caso citado del IIS, un servidor virtual de autenticación http, y otro para el resto de las aplicaciones, un servidor virtual de autenticación basado en Telnet. El servidor AAA puede ser, por ejemplo, una aplicación de la propia Cisco Systems, el CSACS (Cisco Secure Access Control Server), que opera sobre Windows, u otras opciones, sobre todo para el caso de que el protocolo AAA utilizado sea RADIUS, como el servidor AAA de Livingston o Merit. Su

290


configuración dependerá de cada caso, pero, desde el punto de vista general, en el servidor AAA se debe tener definidos los siguientes datos: • Configuración de usuarios y de grupos de usuarios, básica para la autenticación. Puede normalmente usarse, además, la definida para Windows o la de un directorio LDAP, si no se quiere crear una propia del servidor AAA. • Configuración de autorización (qué se puede hacer siendo quien se es), muy basada, habitualmente, en los grupos de usuarios, pero que puede llegar a tener en cuenta, en el caso del CSACS, filtros estáticos de tipo ACL para que haya una doble autenticación, basada no sólo en quién se es, sino también en desde dónde se accede. • Configuración de contabilidad, especialmente potente si se usa RADIUS como protocolo AAA entre el ASA y el servidor AAA. Se puede también componer una salvaguarda para el caso de que un ASA falle. Concretamente, con la topología de redundancia de ASA (o failover), como se ve en la figura 9.8, cuando un ASA falla, otro toma inmediatamente su lugar. Para que esto funcione correctamente, los dos cortafuegos ASA deben ser del mismo modelo, tener la misma versión del sistema operativo, la misma cantidad de memoria y el mismo tipo de licencia de uso.

Figura 9.8. Configuración de redundancia de 2 cortafuegos ASA.

En el proceso de redundancia se habla de un ASA primario y uno secundario. El primario funciona como activo, realizando sus funciones normales y el secundario está en standby. Cuando el primario falla, el secundario se vuelve activo y el primario se cambia a standby.

291


Hay, además, 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, las aplicaciones cliente deben reconectarse. • La redundancia «completa» (o stateful), en la que hay que usar una interfaz Ethernet de 100 Mbps en cada ASA sólo para conseguirla. Con ella, las conexiones TCP permanecen activas, los clientes no tienen que volver a conectarse y se dice que se proporciona redundancia y conexión completa. Conviene conocer para hacerse una idea más completa del uso de este tipo de cortafuegos en una organización, la posibilidad de gestión remota del ASA. Puede realizarse de tres formas distintas: • Mediante Telnet. Para ello, hay que configurar en el ASA desde que direcciones IP se permite tal acceso, con qué contraseña y por qué interfaces. Si se desea que el acceso pueda llegar desde la interfaz outside, se debe configurar primero una red privada virtual. • Mediante SSH. En este caso, se evitan los problemas de la transparencia de datos de los mensajes de Telnet, pero, a cambio, hay que configurar un soporte criptográfico de tipo RSA, que será estudiado más adelante. • Mediante el ASDM (ASA Device Manager). El ASDM es una herramienta gráfica (basada en tecnología gráfica típica de html), diseñada para poder hacer remotamente la puesta en marcha, configuración y monitorización del ASA, sin necesidad de tener un conocimiento exhaustivo de los comandos de la interfaz de comandos del sistema operativo del ASA. El ASDM utiliza otro protocolo criptográfico (el SSL o Secure Socket Layer) para hacer más segura la autenticación y la privacidad de los datos que circulan entre el ASA y la máquina desde la cual se está haciendo la configuración gráfica.

292


4. CONOCIMIENTOS Y COMPETENCIAS ADQUIRIDAS Se han expuesto las características típicas de las tecnologías de cortafuegos actualmente más novedosas, que son: • El uso de la inspección completa y dinámica de paquetes, también conocido como «stateful inspection». • La acumulación de características de seguridad no específica de cortafuegos. En el caso de la primera característica, se ha analizado cómo funciona, qué tablas mantiene internamente y cómo las gestiona, para todos los mensajes típicos de IP, tanto los de aplicaciones TCP o UDP, como para los de protocolos de nivel de red. Se han enumerado también todas las características no específicas de cortafuegos que ya aparecen en los de última generación, entre los que cabe resaltar el hecho de ser cortafuegos híbridos, integrando por ejemplo servidores proxy, pudiendo crear y mantener redes privadas virtuales o gestionando sistemas de detección de intrusiones. Se expone, con un cierto nivel de detalle, el caso del cortafuegos IPTables de la organización Netfilter. También, por similitud, se describen las características más relevantes del cortafuegos Cisco ASA, comprobando que, en lo esencial, cubre las mismas necesidades que en el caso anterior.

5. BIBLIOGRAFÍA ANDREASSON, O. (2006): IPTables Tutorial (Versión 1.2.2). Descargable desde http://www.frozentux.net/documents/iptables-tutorial/ FIREWALL BUILDER, sitio web del creador de FWBuilder, herramienta grafica de configuración de cortafuegos IPTables.URL: http://www.fwbuilder.org/ FRAHIM, J. (2010): Cisco ASA. All-in-one firewall, IPS, anti-X and VPN Adaptative Security Appliance. Ed. Cisco Press. NETFILTER, sitio web de la organización Netfilter, creador del proyecto de software libre IPTables. URL: http://www.netfilter.org/projects/iptables/ index.html

293


6. PALABRAS CLAVE Cadena, Cisco ASA, Cortafuegos, DNAT, IPChains, IPTables, SNAT, Stateful Inspection, conexiones embriónicas, niveles ASA, ACL.

7. EJERCICIOS RESUELTOS 1. La tecnología «stateful inspection» utiliza tablas internas de conexiones, con información dinámica de campos de las cabeceras de TCP, UDP y de protocolos de nivel de red. a) Falso, sólo se mantienen para mensajes de aplicaciones TCP. b) Verdadero, debido a que se implementan en el hardware, si no fuera así, sería imposible. c) Verdadero, son estas tablas las que permiten filtrar basándose en información dinámica. d) Falso, eso es un característica sólo normal en cortafuegos de tipo filtro de paquetes. Solución: c. 2. La regla #iptables –A OUTPUT –p ICMP –o eth0 –j ACCEPT a) b) c) d)

Permite el tráfico ICMP saliente de la tabla NAT. Permite el tráfico ICMP saliente de la tabla MANGLE. Permite el tráfico ICMP saliente de la tabla FILTER. Permite el tráfico ICMP saliente de la tabla FILTER que se haya originado en el interfaz de red eth0.

Solución: d. 3. ¿Cuál de las siguientes reglas de IPTables permitirá el tráfico entrante dirigido a un servidor web con dirección IP 192.168.1.100? a) b) c) d)

#iptables –A INPUT –p tcp --sport 80 –j ACCEPT #iptables –t FILTER –A INPUT –p tcp --dport 80 –j ACCEPT #iptables –t NAT INPUT –p tcp --dport 80 –j ACCEPT #iptables –t FILTER –A INPUT –p udp –j ACCEPT

Solución: b.

294


4. ¿Con cuál de los siguientes comandos se pueden crear excepciones a la regla básica de seguridad del Cisco ASA basada en los niveles ASA? a) b) c) d)

Con el comando conduit Con el comando access-list Con el comando filter Con los comandos aaa

Solución: b. 5. ¿Tienen los dispositivos ASA capacidad de encaminamiento IP? a) b) c) d)

No, son cortafuegos y no hacen de encaminadores. Si, pero sólo mediante protocolo IGRP. Si, pueden encaminar mensajes trabajando como un encaminador. No, a diferencia de los antiguos PIX de Cisco.

Solución: c.

8. EJERCICIOS DE AUTOEVALUACIÓN 1. Debido a la abundancia de características diversas de seguridad en estos cortafuegos «de última generación», basta con uno de tales cortafuegos para tener configurada cualquier política de seguridad. a) Verdadero, por eso se les llama «de última generación». b) Verdadero, pero ha de utilizarse más de uno. c) Falso, si la política ha de cumplir las características citadas en este libro siempre se necesitarán otros dispositivos de seguridad. d) Depende de cómo sea la política de seguridad aunque, en general, si la política cumple un serie de principios mínimos de seguridad, si suele ser suficiente. 2. Un cortafuegos IPTables dispone de un interfaz eth0 conectado a Internet y un segundo interfaz eth1 conectado a la red interna. ¿Cuál de las siguientes reglas de filtrado permitirá el acceso a un servidor SMTP con dirección IP 192.168.0.5 desde la red interna? a) #iptables –A INPUT –p TCP –i eth1 --dport 80 –j ACCEPT b) #iptables –A INPUT –p TCP –i eth1 –d 192.168.0.5 --dport 80 –j ACCEPT

295


c) #iptables –A INPUT –p TCP –i eth1 –d 192.168.0.5 –o 0/0 --dport 80 –j ACCEPT d) Cualquiera de las tres reglas lo permitiría. 3. Un cortafuegos IPTables dispone de un interfaz eth0 conectado a Internet y un segundo interfaz eth1 conectado a la red interna. ¿Cuál de las siguientes reglas de filtrado retransmitirá los paquetes recibidos desde la red interna con la IP de origen cambiada por la IP del cortafuegos que es 192.168.0.5? a) #iptables –t NAT –A POSTROUTING –o eth0 –s 192.168.56.0/24 –j MASQUERADE b) #iptables –A POSTROUTING –o eth0 –s 192.168.56.0/24 –j MASQUERADE c) #iptables –t NAT –A POSTROUTING –o eth0 –d 192.168.0.5 –j MASQUERADE d) Ninguna de las anteriores. 4. En los dispositivos Cisco ASA, además de los mecanismos stateful inspection, ¿qué otras tecnologías de cortafuegos están presentes? a) b) c) d)

La de filtro de paquetes. La de servidor proxy. Tanto la a) como la b). Ninguna más.

5. ¿Cuál de los siguientes métodos de gestión remota de un Cisco ASA es el menos seguro? a) b) c) d)

296

El uso de ssh. El uso de Telnet. El uso del ASDM mediante protocolo SSL. Todos son suficientemente seguros.

Tema 10

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

1. Introducción, orientaciones para el estudio y objetivos 2. Caso práctico: la herramienta Nmap 2.1. Instalación y uso de Nmap 3. Caso práctico: la herramienta Nessus 3.1. Instalación y uso de Nessus 4. Herramientas de análisis de vulnerabilidades en código fuente 4.1. Características de las herramientas SSCA 4.2. Tipos de herramientas SSCA 4.3. ¿Qué herramienta seleccionar? 5. Conocimientos y competencias adquiridas 6. Bibliografía 7. Palabras clave 8. Ejercicios resueltos 9. Ejercicios de autoevaluación

1. INTRODUCCIÓN, ORIENTACIONES PARA EL ESTUDIO Y OBJETIVOS Como ya se ha analizado previamente, el gran número de vulnerabilidades (o bugs) de seguridad del software, ya sea éste un sistema operativo, aplicaciones o protocolos, provoca que haya que afrontar el hecho de la aparición de nuevos virus, worms o, en general, ataques que se aprovechan de dichas vulnerabilidades. Por esta razón, y como ya se vio en el tema 6, una política de seguridad integral debe cubrir este punto y tener en cuenta la necesidad de analizar, con cierta frecuencia, las posibles vulnerabilidades, especialmente de los equipos que sean más susceptibles de resultar atacados. No es otra la explicación de que se necesite contemplar el uso de analizadores de vulnerabilidades, para implementar la fase de análisis de problemas de seguridad en software, tal y como se recuerda en la figura 10.1. Se puede definir un analizador de vulnerabilidades como un programa que busca, de manera automatizada, vulnerabilidades de seguridad en una aplicación o en un sistema. Su resultado final es un informe sobre qué debilidades fue capaz de encontrar y, con ese informe, el administrador (o desarrollador, como ya veremos) decide si las subsana y cuándo (y el atacante, si las usa, dónde y cuándo). Estos programas están experimentando un gran auge y en los últimos años han proliferado en entornos muy diferentes. Así, hay diferentes tipos: • Los que buscan vulnerabilidades en aplicaciones y/o sistemas en tiempo real, en situaciones de uso real. Los hay más especializados en tipos de aplicaciones (por ejemplo los que se dedican a aplicaciones web) o en sistemas y software de comunicaciones. Todos ellos usan un cierto «motor de búsqueda» y una lista de vulnerabilidades conocidas. Esta lista, además, crece con el tiempo, de acuerdo con la situación real del momento.

299


Figura 10.1. Las fases de desarrollo del proceso de seguridad.

• Los que buscan vulnerabilidades en el código de las aplicaciones o sistemas (SSCA, Static Source Code Analyzers), independientemente del estado de uso de las mismas. En este caso, relativamente novedoso y en permanente actualización, se trata de programas que, mediante el uso de muy diferentes tipos de algoritmos que están además relacionados con el lenguaje en el que esté escrita la aplicación y del conocimiento sobre las vulnerabilidades más habituales conocidas, detectan tales vulnerabilidades en el código. Las SSCA deberían ser utilizadas cada vez más, para tener en cuenta la variable seguridad dentro del ciclo de diseño y desarrollo del software. Además estos programas de análisis (o búsqueda) de vulnerabilidades pueden ser programas de código abierto o comerciales. En general, los de código abierto se quedan en pruebas piloto de conocimiento o acaban dando lugar a productos comerciales. Aun no resultando completamente fiables, debido a la propia naturaleza del problema que tratan, en los últimos años se ha asistido a un gran crecimiento en la oferta y es fácil que cada año aparezcan nuevas iniciativas.

300

INTRODUCCIÓN A LAS HERRAMIENTAS DE ANÁLISIS DE VULNERABILIDADES DE SEGURIDAD

Como ya se ha comentado, la complejidad implícita de la labor que desarrollan estas aplicaciones hace que sea siempre necesaria la supervisión de un experto en seguridad para comprobar, tras la ejecución del analizador, qué vulnerabilidades lo son realmente y cuáles no. Se hace importante entender determinadas definiciones, muy típicas en este tipo de problemas, 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. Es fácil de comprender que cuando una herramienta de este tipo es usada sobre una aplicación con muchos miles de líneas de código y, como pasa en muchas (tanto comerciales como de código abierto) se obtiene un alto porcentaje de falsos positivos, muchas organizaciones se planteen no usarlas o usarlas sólo a veces. Otra cualidad determinante es si son analizadores de sistemas centrados en el equipo concreto, o analizadores que, aunque instalados en un equipo y pudiendo buscar problemas en tal equipo, puedan buscar vulnerabilidades por la red, simulando muchos de los tipos de ataques que pueden tener lugar. Entre los propios de sistemas hay algunos muy extendidos, como el Tripwire para sistemas Linux y UNIX, que calcula firmas digitales de los ejecutables y ficheros de configuración de un sistema y los compara regularmente, para comprobar si alguno se ha alterado. Para utilizarlos correctamente hay que considerar también los siguientes puntos: • Ejecutarlos frecuentemente. Debido a que los sistemas son constantemente administrados, actualizados, «parcheados», es decir, que cambian frecuentemente, la herramienta hay que ejecutarla con una periodicidad que decidirá la política de seguridad concreta de la organización. Si se trata de SSCA, dependerá de la política de puesta en marcha del ciclo de diseño del software.

301


• Tener en cuenta el impacto en el tráfico de la red. Si los análisis que se utilizan, o alguno de ellos, generan un gran volumen de tráfico, habrá que considerar el momento de la ejecución y hacerlos, por ejemplo, fuera de las horas habituales de trabajo. • Tener en cuenta el impacto de algunos tests. Algunos analizadores de vulnerabilidades trabajan con tests de ataques DOS (denegación de servicio) que podrían provocar, en algunos sistemas más vulnerables, la parada de servicios. • Informar al personal responsable. Los administradores de red de los equipos y redes que se vayan a analizar deben estar al tanto de la situación, para entender mejor los posibles problemas que se deriven de tales análisis. El resto del capítulo está dedicado a describir, con un cierto detalle, algunos casos particulares, como el programa Nmap, una herramienta de código abierto para el escaneo de puertos y auditorias de seguridad, o Nessus, otra herramienta de auditoría de seguridad, cuya funcionalidad es la de ayudar a detectar posibles vulnerabilidades en las máquinas escaneadas. Finalmente se analizarán algunas de las propiedades de las aplicaciones SSCA y su fiabilidad.

2. CASO PRÁCTICO: LA HERRAMIENTA NMAP Nmap (Network Mapper) es una herramienta de código abierto para el escaneo de puertos y auditorias de seguridad. Nmap permite no solo detectar los hosts activos en una red, sino que también determina qué tipos y versiones de sistemas operativos utiliza cada host, qué tipo de cortafuegos o filtros de paquetes se están utilizando, etc. Nmap está disponible, entre otros sistemas, para Linux, Windows y Mac Os X. Originalmente era una herramienta de línea de comandos, pero actualmente incluye también la posibilidad de instalar la herramienta con un interfaz gráfico que facilita su uso (Zenmap). Otras características destacables de Nmap son: • Flexibilidad: Permite utilizar diferentes técnicas para mapear redes, incluso cuando éstas están protegidas por cortafuegos o filtros de paque-

302


tes. Estas técnicas incluyen diferentes mecanismos para el escaneo de puertos, identificación de sistemas operativos, sus versiones, etc. • Potencia: Nmap ha sido utilizada para escanear redes con cientos de miles de hosts conectados a la misma. • Documentación: Nmap está ampliamente documentada en varios idiomas. Se puede acceder a dicha documentación desde http:// nmap.org/docs.html. 2.1. Instalación y uso de Nmap Nmap puede descargarse desde http://nmap.org/download.html, donde se puede encontrar tanto el código fuente, pudiendo así incluso modificarlo antes de compilarlo, como instaladores para las diversas plataformas. Las capturas de pantalla que se presentan a continuación corresponden a la versión para Microsoft Windows. El interfaz de usuario de Zenmap permite de forma muy fácil configurar el tipo de escaneo que se desea realizar. Para lanzar un escaneo simplemente hay que indicar la dirección IP del host que deseamos escanear o su dominio, tal como se ve en la figura 10.2.

Figura 10.2. Interfaz gráfico de Nmap.

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. La figura 10.3 muestra cómo especificar una búsqueda en todas las máquinas de una clase C.

303


Figura 10.3. Ejemplo de selección de target por rango de direcciones IP.

El siguiente paso consiste en elegir el tipo de escaneo que queremos lanzar. Para ello podemos escribir a mano el comando Nmap que queremos lanzar, el cual podemos escribir en la sección «Command», o podemos elegir entre los distintos perfiles de escaneo pre configurados en Zenmap, tal como se ve en la figura 10.4.

Figura 10.4. Perfiles de escaneo pre configurados en Zenmap.

304


A la hora de seleccionar el tipo de escaneo a realizar hay que tener en cuenta que 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. Si por ejemplo se desea conocer todas las máquinas conectadas a un determinado sector de red, no es recomendable lanzar un «Intense Scan», bastaría con lanzar un «Ping Scan» (figura 10.5) o un «Quick Scan» para poder determinar todas ellas. En cambio, cuando lo que se desee es hacer un examen exhaustivo de seguridad de una máquina, se elegirá una de las opciones de escaneo intenso.

Figura 10.5. Ejemplo de «Ping Scan» lanzado para detectar las máquinas activas en un sector de red.

Una vez lanzado el escaneo, Nmap muestra los resultados conforme se van obteniendo. Dependiendo del tipo de escaneo la información será más o menos extensa. La figura 10.6 muestra la pantalla inicial de resultados de un «Ping Scan» en el que se han localizado las máquinas activas en el sector de red 192.168.10.0/24. En dicho escaneo se han detectado dos máquinas. En este

305


caso el escaneo proporciona poca información adicional. Además de la lista de host activos, la pestaña de topología nos muestra precisamente la topología de red detectada.

Figura 10.6. Representación de la topología de red detectada.

En este caso la información obtenida es escasa, pero ha permitido detectar las máquinas activas en la red, paso previo típico en ataques de obtención de información. Se puede después decidir lanzar un escaneo intenso sobre alguna de las máquinas, por ejemplo contra la 192.168.10.100, como se ve en la figura 10.7. Aunque la salida directa del comando Nmap es fácil de interpretar, Zenmap muestra dicha información de forma ordenada. La pestaña «Ports/Hosts» muestra los puertos abiertos que se han detectado. Así mismo para cada puerto indicará el servicio descubierto y la versión de software detectada. La figura 10.8 muestra los puertos y servicios detectados en el escaneo a la máquina 192.168.10.100. Nmap ha identificado tres puertos abiertos así como los servicios y los programas y versiones que atienden cada uno de ellos.

306


Figura 10.7. Resultados de un «Intense Scan» contra la máquina 192.168.10.100.

En la pestaña «Host Details» (figura 10.9), se muestran los detalles obtenidos sobre el host escaneado. Zenmap habrá tratado de detectar el sistema operativo y su versión, el estado del host, sus direcciones IP, su dirección MAC, la secuencia de paquetes TCP, etc. Otra de las funcionalidades

307


Figura 10.8. Servicios detectados en el «Intense Scan» a la máquina 192.168.10.100.

Figura 10.9. Datos obtenidos de192.168.10.100 en el «Intense Scan».

308


de la versión Zenmap es la de guardar los resultados obtenidos. Posteriormente estos resultados podrán ser comparados (figura 10.10) con escaneos posteriores a través de otra herramienta proporcionada por Zenmap.

Figura 10.10. Opción de menú para lanzar la herramienta de comparación de escaneos.

Gracias a dicha herramienta podremos comparar de forma automática las diferencias entre dos escaneos diferentes al mismo host, como se aprecia en la figura 10.11.

Figura 10.11. Resultados obtenidos por la herramienta de comparación de resultados.

309


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. Nessus, un producto comercial de Tenable Network Security, es uno de los analizadores de vulnerabilidades más extendidos hoy en día. Utiliza una tecnología conocida como «Nessus Professional-Feed», que, a su vez, es mantenida por un equipo experto en investigación y búsqueda de vulnerabilidades. Tenable realiza esta búsqueda de vulnerabilidades permanentemente. Cuando se descubre una vulnerabilidad nueva, Tenable crea un plug-in para Nessus, lo prueba y, finalmente, lo hace disponible para su descarga de forma que el analizador Nessus pueda siempre realizar los chequeos de red y de host más actualizados. Los suscriptores de «Nessus Professional-Feed» pueden asimismo usar el contenido desarrollado por Tenable para realizar auditorías de configuración en UNIX, Windows y bases de datos SQL contra políticas a medida, configuraciones extraídas de sistemas activos y políticas basadas en organismos especializados como el NIST, CERT, SANS o vendedores como Microsoft o Red Hat. En el momento de la publicación de este libro las actualizaciones son diarias y la cobertura de más de 50000 vulnerabilidades. La suscripción anual normal cuesta alrededor de 1500 $. Las características más significativas de Nessus son: • Análisis en profundidad. Nessus realiza análisis a alta velocidad sobre los programas analizados. Se puede distribuir diferentes scanners por las diferentes redes de la organización. Además, el rango de direcciones IP es ilimitado y, si se usan direcciones IP dinámicas, es capaz de usar DNS o direcciones MAC. Nessus puede completar una auditoría de redes de hasta 100 hosts en unos pocos minutos usando un portátil. Si la red es más extensa se puede usar el «Tenable Security Center», que permite gestionar muchos scanners Nessus distribuidos. • Auditoría de dispositivos móviles. Puede integrarse con Apple Profile Manager y con Microsoft Exchange vía el directorio activo, para

310


obtener una visión completa de la parte móvil de una organización y del estado de cada dispositivo, en cuanto a vulnerabilidades. • Auditoría antivirus, de botnets y procesos maliciosos. Es capaz de detectar procesos maliciosos en ordenadores con Windows. Mejora la organización del antivirus, estudiando y analizando posibles amenazas relacionadas con las «amenazas persistentes avanzadas» o APTs («Advanced Persistent Threats»). Identifica rápidamente infecciones debidas a botnets y servidores web con contenido malicioso asociado con la propagación de los mismos. Asimismo, audita los agentes anti virus de la organización buscando vulnerabilidades, reglas de firmas desactualizadas y configuraciones erróneas. • Integración de gestión de parches de seguridad. Nessus se integra fácilmente con productos típicos de gestión de parches y actualizaciones como el Tivoli Endpoint Manager (TEM) de IBM, el System Center Configuration Manager (SCCM) o el Windows Server Update Services (WSUS) de Microsoft, el Network Satellite Server de Red Hat o el VMwareGo. Puede así permitir comparaciones y emitir informes de discrepancias.

3.1. Instalación y uso de Nessus Nessus mantiene una estructura cliente-servidor. El primer paso es instalar el programa servidor que se puede descargar desde: http://www.tenable.com/products/nessus/select-your-operating-system Nessus está disponible para Linux, Windows, Mac OS X, Solaris, etc., y también tiene disponibles versiones del programa cliente para terminales móviles (IOS de Apple y Android).Una vez seleccionada la versión que se desea descargar, se puede proceder a su instalación, que es sencilla y completamente automatizada. Una vez instalado Nessus se iniciará como un servicio y estará listo para ser accedido por el programa cliente, cuya interfaz se muestra en la figura 10.12. Desde las últimas versiones de Nessus el cliente es simplemente un cliente Web. Para conectar con el mismo, simplemente hay que acceder a la siguiente URL: https://ip_servidor_nessus:8834

311


Figura 10.12. Pantalla inicial del cliente Nessus.

La primera vez que se accede al servidor Nessus desde el cliente web será necesario proceder a la configuración inicial de la aplicación donde, además de crear la cuenta del administrador del servidor Nessus, hay que registrar un suministrador de plug-ins. Estas plug-ins son las que permiten al servidor Nessus realizar los escaneos de vulnerabilidades. El primer paso es definir la cuenta y contraseña de administración del servidor Nessus, tal como se ve en la figura 10.13.

Figura 10.13. Configuración de la cuenta del administrador.

312


En el siguiente paso se pide suministrar un código de activación para un suministrador de plug-ins. Aunque Nessus es una herramienta comercial, pone a disposición de usuarios individuales, y sin ánimo de lucro, la posibilidad de obtener una «Home Feed» de forma gratuita, la cual se puede obtener en http://www.tenable.com/products/nessus/nessushomefeed. Una vez cumplimentado el formulario de registro se recibirá el código de activación en el correo electrónico facilitado en el formulario de registro. Habrá que introducir dicho código (figura 10.14) en el cliente Nessus para proceder a su activación.

Figura 10.14. Introducción del código de registro.

Tras la activación Nessus procederá a descargar las Plug-ins disponibles para el feed registrado. Una vez descargadas se inicializará el servidor Nessus y la aplicación mostrará ya el interfaz principal, como se ve en la figura 10.15. Dicha pantalla será la que se presentará a partir de este momento cada vez que se arranque el cliente Nessus, ya que la inicialización se hace solo la primera vez que se arranca el cliente.

313


Figura 10.15. Pantalla de login del cliente Nessus.

Una vez abierta la sesión en el cliente Nessus se presentará la pantalla inicial de la aplicación, en la que se podrán ver los resultados de escaneos anteriores o definir nuevos. Para lanzar un nuevo escaneo habrá que pulsar sobre la opción añadir («Add»). En la ventana siguiente (figura 10.16) habrá que definir el objetivo, dirección IP o dominio de la máquina a escanear (se puede definir un rango de direcciones IP a escanear). Dentro de las opciones hay que indicar el tipo de análisis que se desea realizar. Las dos opciones usadas más habitualmente son la de escaneo interno o escaneo externo, dependiendo si la maquina objeto se encuentra en la misma red o si es una máquina a la que se accede a través de Internet. Este tipo de escaneos testeará el host especificado contra todos los plug-ins predeterminados en cada caso. Si se desea se podrán añadir políticas de escaneo personalizadas en la sección «Policies». Para cada nueva política de escaneo habrá que definir una serie de características, siendo las siguientes algunas de las más significativas: • Nombre de la política.

314


Figura 10.16. Creación de un nuevo escaneo.

• Puertos a escanear. • Tipo de escaneo de puertos a realizar. • Número de conexiones paralelas. • Credenciales para un escaneo más en profundidad de determinados servicios. En caso de auditorías internas es posible conocer dicha información, lo cual dará mayor profundidad al análisis realizado. • Definición de las plug-ins que se van a utilizar en el análisis de vulnerabilidades que se está definiendo. Cada plug-in representa una posible vulnerabilidad que se puede comprobar. Las plug-ins están organizadas en grupos en función del tipo de vulnerabilidad que se está tratando de explorar. Se pueden desactivar grupos enteros de plug-ins

315


o ser más granular y llegar a activar/desactivar plug-ins específicas dentro de cada grupo. • En la última pantalla de configuración se podrán definir una serie de preferencias que van a permitir ajustar tanto al forma de realizar el análisis como el detalle del mismo. Independientemente de si se usa una política de escaneo estándar o una personalizada, una vez seleccionado el objetivo y la política, habrá que decidir si el escaneo se va a lanzar inmediatamente o de forma programada, y lanzar el proceso pulsando «Launch Scan».En ese momento el escaneo en curso se mostrará en la lista de escaneos e indicará en el estado en que está. Una vez finalizado al análisis, desaparecerá de la lista de escaneos y aparecerá en la lista de «reports». En dicha lista se mostrarán los resultados de todos los escaneos lanzados hasta el momento. Para analizar los resultados obtenidos, se seleccionará el report que se desea ver y se pulsará sobre el botón «Browse». En la primera pantalla se muestra el resumen de vulnerabilidades descubiertas agrupadas por su riesgo, como se ve en la figura 10.17.

Figura 10.17. Resumen de vulnerabilidades encontradas por nivel de riesgo.

Pulsando sobre una entrada se podrá acceder al detalle del mismo (figura 10.18) en el que, de nuevo, las vulnerabilidades encontradas se agrupan por el nivel de riesgo que suponen, solo que esta vez se agrupan también por el puerto en que se ha encontrado dicha vulnerabilidad.

316


Figura 10.18. Resumen de vulnerabilidades encontradas por nivel de riesgo y puerto.

Y pulsando en un determinado puerto se ve una lista detallada de las plug-in que han detectado vulnerabilidades en dicho puerto, como se puede ver en la figura 10.19.

Figura 10.19. Detalle de las vulnerabilidades encontradas en un puerto.

317


Finalmente, pulsando sobre cada una de las vulnerabilidades se mostrará información detallada (figura 10.20) sobre la misma. En dicha información se da una explicación detallada sobre la vulnerabilidad encontrada e incluso se proporciona información sobre cómo corregirla.

Figura 10.20. Detalle de vulnerabilidad encontrada.

4. HERRAMIENTAS DE ANÁLISIS DE VULNERABILIDADES EN CÓDIGO FUENTE Cada vez más frecuentemente hay que considerar una gran variedad de estrategias y herramientas para que el software que se crea sea suficientemente fiable, antes de hacerlo disponible. Entre las herramientas, los analizadores de vulnerabilidades en código fuente (SSCA) se pueden usar para examinar 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 de análisis estático de seguridad de código fuente van usándose cada vez más, teniéndose en cuenta en muchas estrategias

318


de desarrollo de software, siguiendo un sencillo esquema como el que se muestra en la figura 10.21. Estas herramientas están diseñadas para detectar vulnerabilidades de seguridad que, si no se tienen en cuenta, puede convertirse, una vez el programa disponible y en uso, en agujeros de seguridad explotables.

Figura 10.21. Proceso de revisión del software para desarrollo de código.

Estos analizadores van poco a poco convirtiéndose en parte de la «caja de herramientas» de muchos equipos de desarrollo aunque, como se discute más adelante, es aún necesario una comprensión clara de sus fortalezas y debilidades. 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.

319


En el primer paso el código se transforma mediante una combinación (que varía en extensión y número dependiendo de las herramientas concretas) de técnicas de análisis léxico y semántico y de «parsing». El «modelo» resultante es analizado usando análisis intra-procedimiento (local) para las funciones individuales y también análisis inter-procedimiento (global) para la interacción entre funciones, usando registro del flujo de control y de datos, alias de punteros, etc. Dependiendo de la herramienta que se selecciones, estas reglas son un conjunto único o pueden extenderse. Es importante señalar que mientras que las herramientas de código abierto muestran los algoritmos usados en profundidad, las herramientas comerciales sólo dan información general, lo que hace complicado entender sus fallos. Finalmente los resultados se dan en términos de las posibles vulnerabilidades encontradas y su nivel de severidad.

4.2. Tipos de herramientas SSCA Existen diferentes esquemas que permiten categorizar las herramientas SSCA. Pueden clasificarse teniendo en cuenta los lenguajes que entienden o también las clases de vulnerabilidades que son capaces de buscar. Otro posible criterio es la longitud del código que son capaces de analizar, ya que sólo algunas permiten analizar correctamente piezas de código de cientos de miles, o incluso millones, de líneas de código. La clasificación más usada es la del libro de referencia de Chess y West. Esta taxonomía hace referencia al propósito general de cada herramienta y diferencia entre: • De chequeo de estilos: estas herramientas (por ejemplo lint en sistemas Linux o UNIX) hacen chequeos basados en análisis sintáctico y léxico, que permiten descubrir problemas como inconsistencias en llamadas a funciones, valores de vuelta de funciones, funciones que se invocan con diferente número de argumentos o con diferentes tipos de argumentos. Este análisis es obviamente limitado al compararlo con otras SSCA analizadas después, al no hacer ningún tipo de simulación sobre lo que sucedería en tiempo de ejecución. • De chequeo de propiedades: Usan una especificación de programa y un conjunto de códigos e intentan demostrar que el código es una

320


implementación correcta de la especificación. Un ejemplo es la herramienta CBMC (C Bounded Model Checking), diseñada para ANSI C, que permite verificar vulnerabilidades asociadas con punteros, excepciones, buffer overflows y alguna otra. • De tipo «bug finding»: Con este nombre tan genérico se habla de herramientas SSCA que simplemente avisan de las ubicaciones en el código donde el programa va a comportarse de forma «sospechosa», al menos diferente de la deseada por el programador. Usan un conjunto predefinido de reglas que describen los patrones del código que podrían indicar la presencia de vulnerabilidades. En el caso de las herramientas más sofisticadas, este conjunto de reglas puede extenderse por el propio usuario. 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 y entre las más potentes se pueden citar a Prevent, de Coverity, disponible para C/C++, Java, J2EE y C#, o a Insight, de Klocwork, que además permite una exploración gráfica. • De tipo «securityreview»: Estas herramientas combinan muchas técnicas citadas previamente, pero son mucho más estrictas en la búsqueda únicamente 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. Se caracterizan porque, a pesar de provocar más falsos positivos, buscan no dejar pasar ninguna codificación sospechosa. Dos ejemplos muy significativos son Ounce 6 de IBM y SCA (Source Code Analyzer) de HP, que es capaz de analizar código en C/C++, C#, ASP NET, VB.NET, COBOL, CFML, HTML, Java, JavaScript, AJAX, JSP, PHP, PL/SQL, Python, Visual Basic, VBScript y XML.

4.3. ¿Qué herramienta seleccionar? En el momento de redacción de este libro existen más de 40 herramientas SSCA disponibles, entre las que son de código abierto y las comerciales, pero no puede afirmarse que ninguna haya alcanzado un nivel de seguridad suficiente como para decir que son 100% útiles, desgraciadamente. Este campo está aún abierto y hacen falta, probablemente, unos cuantos

321


años de desarrollo y estandarización para hablar de seguridad de uso. Todos los estudios científicos siguen indicando que incluso las herramientas más caras y sofisticadas no son capaces de detectar el 100% de las vulnerabilidades más habituales y que, además, unas herramientas detectan con facilidad cierto tipo de vulnerabilidades, mientras que otras detectan otros grupos diferentes de vulnerabilidades. Así que la recomendación sería usar varias o, si esto no fuera posible por razones económicas, ser especialmente prudente con los resultados obtenidos mediante su uso.

322


5. CONOCIMIENTOS Y COMPETENCIAS ADQUIRIDAS Se ha analizado el uso de las herramientas de análisis de vulnerabilidades en sistemas y dispositivos de red, que, como ya se ha visto, es una parte importante de la implementación de un proceso de seguridad correcto, señalando cuáles deben ser las condiciones mínimas de uso, configuración y mantenimiento de estas herramientas para poder cumplir su misión con éxito. Si hubiera que decidir cuál es la característica más importante, desde el punto de vista de seguridad, de estas herramientas, ésta sería su capacidad de prevención, de anticipación a posibles problemas. Puede afirmarse que, en general, las herramientas de tiempo real tienen todas: • Una base de datos de vulnerabilidades, cuanto más completa mejor y fácilmente actualizable. • Un mecanismo de búsqueda y descubrimiento de todos los dispositivos de una red. • Un mecanismo de selección del tipo de tests que se pretende hacer y de los dispositivos objetivo de tales chequeos. • Un mecanismo de ejecución de los tests definidos y de obtención de resultados, es decir, de vulnerabilidades y bugs encontrados. • Un mecanismo de generación de informes, habitualmente muy rico en distintas presentaciones. Entre las posibles complicaciones que hay que tener en cuenta la más importante puede ser la resultante de la complejidad modular de las aplicaciones y sistemas que se utilizan hoy en día. Lo habitual es obtener una lista de vulnerabilidades de un sistema en la que, al menos para alguna de ellas, se sepa que si se aplica el «parche» correspondiente, se provoca que otros programas dejen de funcionar correctamente. A veces hay que convivir, durante un tiempo, con vulnerabilidades existentes que no se pueden subsanar. Se ha presentado también el uso de las herramientas de búsqueda de vulnerabilidades en código fuente (SSCA), aplicables en las primeras fases del ciclo de desarrollo de software. Estas aplicaciones deben aún mejorar mucho, aunque su uso actual vale la pena en grandes proyectos de software.

323


Finalmente conviene señalar que todas estas herramientas están en el mercado, pueden ser adquiridas también por alguien con intención de usarlas para un ataque. Y son vulnerables, como ya se ha demostrado en algunos casos. Se debe entender las limitaciones de la tecnología y utilizarlas con precaución, no tomándolas como algo completamente infalible.

6. BIBLIOGRAFÍA CHESS, B. y WEST, J. (2007): Secure Programming with static analysis. Ed. Addison-Wesley Software Security Series. JACKSON, C. (2010): Network Security Auditing». Ed. Cisco Press. LYON, G. F. (2009): Nmap Network Scanning: The Official Nmap Project Guide to Network Discovery and Security Scanning. Ed. Nmap Project. ROGERS, R. (2008): Nessus Network Auditing, Second Edition». Ed. Syngress.

7. PALABRAS CLAVE Vulnerabilidad, Nmap, Nessus, auditoría, SSCA.

8. EJERCICIOS RESUELTOS 1. Una vez encontrada una vulnerabilidad de una aplicación, no se puede, sin más, instalar el parche, pues tal instalación puede tener efectos no deseados en otras aplicaciones del mismo sistema. a) Falso, si fuera así no tendría sentido el uso de las herramientas analizadas en este capítulo. b) Verdadero, por ello es necesario usar varias herramientas a la vez, que «parchean» varias herramientas en combinación, consiguiendo el efecto deseado. c) Falso, no existe tal problema de incompatibilidad de aplicaciones. d) Verdadero, la tecnología modular de creación de aplicaciones provoca, con frecuencia, estos problemas. Solución: d.

324


2. Cite una razón por la que estas herramientas, como cualquiera que se use en el entorno de seguridad, puede crear, a su vez, problemas de seguridad. a) No hay ninguna razón, son completamente seguras. b) Son inseguras, debido a su capacidad de cortafuegos, que las hace competir en la red con los verdaderos cortafuegos. c) Son inseguras, pues pueden ser usadas por posibles atacantes de la red, para buscar agujeros de seguridad de sistemas y redes. d) Son inseguras, pues no usan técnicas criptográficas comprobadas. Solución: c. 3. ¿Cuál de las siguientes es una característica de todas las SCCA?: a) b) c) d)

Son todas de código abierto. Analizan únicamente código fuente. Son todas herramientas comerciales. Pueden hacer un análisis en plena ejecución del código.

Solución: b. 4. ¿Cuál de los siguientes datos no puede obtenerse mediante Nmap? a) b) c) d)

Los equipos activos en la red analizada. Los servicios IP activos en un equipo analizado. Los usuarios permitidos en un equipo analizado. La versión instalada del sistema operativo del equipo analizado.

Solución: c. 5. ¿Cuál de las siguientes NO es una característica de Nessus? a) b) c) d)

Es un producto gratuito. Debe actualizarse con frecuencia. Informa en detalle de cada vulnerabilidad encontrada. Sugiere cómo solucionar cada vulnerabilidad encontrada.

Solución: a. 9. EJERCICIOS DE AUTOEVALUACIÓN 1. ¿Cuál de las siguientes herramientas permite realizar auditorías de configuración en bases de datos SQL? a) SCA, Source Code Analyzer.

325


b) La herramienta Nmap. c) La herramienta nslookup. d) La herramienta Nessus. 2. Al analizar un código fuente extenso, de centenares de miles de líneas de código, con una herramienta SSCA, un número alto de falsos positivos encontrados no es importante. a) Verdadero, las herramientas los descartan automáticamente. b) Falso, puede complicar mucho el análisis de seguridad, pues habrá que analizarlos. c) Verdadero, es algo de lo que aprender. d) Dependerá del número de falsos negativos encontrados. 3. Además de subsanar los problemas asociados con las vulnerabilidades encontradas tras un análisis con una herramienta de las descritas en el tema, ¿qué otras cosas habría que hacer después, desde el punto de vista de la seguridad? a) Nada, una vez subsanadas las vulnerabilidades, el sistema analizado es completamente seguro. b) Dejar el sistema analizado en cuarentena durante una temporada. c) Seguir analizando el sistema, manualmente o con otras herramientas. d) Rehacer completamente el código fuente del sistema analizado. 4. ¿Cuál de las siguientes características lo es de Nessus, pero no de Nmap? a) b) c) d)

Gestión mediante una interface gráfica de usuario. Obtiene información sobre servicios y puertos abiertos. Integración con el Tivoli Endpoint Manager de IBM. Obtiene la dirección MAC de las tarjetas de los equipos analizados.

5. ¿Cuál de las siguientes NO es una característica habitual de las herramientas de análisis de vulnerabilidades en tiempo real? a) Hay que sincronizarlas con los cortafuegos de la organización. b) Deben ejecutarse frecuentemente. c) Si se ejecutan por la red, hay que avisar al personal responsable del tráfico que generarán. d) Hay que tener en cuenta el impacto de algunos tests.

326

Tema 11

Introducción a las herramientas de detección de intrusiones

1. Introducción, orientaciones para el estudio y objetivos 2. Caso práctico: Snort 3. Caso práctico: Sguil 4. Honeypots 4.1. Ejemplos de honeypots reales 5. Conocimientos y competencias adquiridas 6. Bibliografía 7. Palabras clave 8. Ejercicios resueltos 9. Ejercicios de autoevaluación

1. INTRODUCCIÓN, ORIENTACIONES PARA EL ESTUDIO Y OBJETIVOS Si se vuelve a la figura que señala las fases de desarrollo de un proceso de seguridad (figura 11.1), se puede ver que hay otra fase de tal proceso, que hay que tener en cuenta, la denominada fase de monitorización.

Figura 11.1. Fases del desarrollo del proceso de seguridad.

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

329


rrido. 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. Una intrusión se puede definir como un mensaje o serie de mensajes que cumplen varias condiciones: 1. Se aparta de un comportamiento «normal», lo cual ya implica cierto problema: conocer qué es normal en el tráfico de una red. 2. Si es anormal, hay que decidir si esa anormalidad proviene de un uso incorrecto (con probabilidad, un ataque) o si es una situación no peligrosa. En los últimos años han ido apareciendo soluciones que realizan esta labor de manera automática. Los primeros utilizaban lo que se conocía como detección de anomalías. Para este tipo de sistemas se creaban lo que se llamaba perfiles de uso típico. Podía haber perfiles típicos por tipos de usuario, por tipos de red, por tipo de trabajo, etc. No tuvieron mucho éxito pues producían muchos «falsos positivos». Esta expresión (falsos positivos) exige una explicación. Se dice que se ha obtenido un falso positivo cuando el sistema IDS (Intrusión Detection System) utilizado indica que hay un ataque en marcha y, realmente, ese tráfico identificado como ataque no es tal. 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» (signatures). Tales firmas de ataque son mensajes concretos (por ejemplo, un mensaje de tipo ping, con una dirección destino que sea la dirección broadcast de una red) o grupos de mensajes (por ejemplo, muchos mensajes seguidos de intento de conexión TCP con iguales dirección IP, es decir, mensajes de SYN flood) 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. El conjunto de firmas de ataque de cada sistema IDS, es la suma del conjunto de firmas que vienen con el sistema instalado (conjunto de firmas actualizable), que son el resultado de la investigación y operación de

330

INTRODUCCIÓN A LAS HERRAMIENTAS DE DETECCIÓN DE INTRUSIONES

una serie de expertos y de los conocimientos de distintas agencias de ayuda (como el CERT), y de la capacidad de creación de otras firmas, por parte de los administradores de estos sistemas. 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 (figura 11.2), en cuyo caso monitorizan el tráfico que circula por ese tramo de red, independientemente de la dirección IP origen del tráfico y de su dirección IP destino. En este caso, se habla de IDS basados en la red.

Figura 11.2. Detección de intrusiones basada en la red.

• Pueden colocarse como salvaguarda de un solo sistema, para proteger dicho sistema (figura 11.3) y, en este caso, se habla de IDS basados en el sistema. Sólo protegen un sistema, a cambio resultan más baratos. El procedimiento habitual de su funcionamiento es el siguiente: 1. Una vez correctamente configurados, monitorizan todo el tráfico que pasa por la tarjeta de red que usan.

331


Figura 11.3. Detección de intrusiones basada en el sistema.

2. Comparan el tráfico que capturan con cada una de las firmas para las cuales están configurados. 3. Si encuentran una firma que se ajuste a determinado tráfico, ejecutan una combinación de las siguientes tres posibilidades: registrar el ataque (en un log local o en uno remoto), enviar una alarma (por ejemplo, mediante un mensaje de correo electrónico) y parar el ataque. Esto es también, habitualmente, configurable y, en algunos sistemas, extensible. Suele ser normal que su 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, mientras que, con la gestión remota, se hacen a través de una conexión web u otro tipo de herramientas gráficas. Al igual que los analizadores de vulnerabilidades, se ha de conocer las características generales que deben cumplir, sean basados en sistemas o basados en la red, cualquiera de estas herramientas:

332


• Debe tener actualizaciones frecuentes, pues la frecuencia con la que aparecen nuevos tipos de ataques lo hace necesario. Tales actualizaciones deben ser sencillas de realizar. • Debe tener capacidad de adaptación al entorno, es decir, se debe poder crear nuevas firmas y, de forma flexible, poder decidir si se busca más ciertos tipos de firmas que otras, dependiendo del lugar que ocupe el IDS en la topología de la red. • Debe exhibir un buen rendimiento, sobre todo si se habla de redes con un gran volumen de tráfico. Incluso, debería indicar si ha perdido paquetes, que no ha podido analizar. Hay, además, una serie de aspectos a tener en cuenta a la hora de desplegar los IDS en la red: • El primero, y muy importante, es dónde colocarlo. Si no hay problemas económicos, los mejor es disponer varios. Si solo se va a trabajar con uno, suele ser normal ponerlo en la red externa al cortafuegos. De esta manera, se protege, en principio, cualquier máquina interna, de ataques externos, pero 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 donde 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, por lo que, o bien deberá estar conectado a un concentrador (hub) al que estén conectados todos los terminales que se desea monitorizar (recordar que los concentradores emiten todos los paquetes recibidos por todos sus puertos), o bien estará conectado a un conmutador (switch) que habrá que configurar de forma que mande copia de todos los paquetes que pasen a través de él al puerto en que esté conectado el IDS. • Otro aspecto importante es el de los falsos negativos, es decir, los ataques reales no detectados. Aunque el IDS que se utilice esté perfectamente actualizado, esto no garantiza un control de todos los posibles ataques. Habrá una serie de ellos, los más nuevos, para los que no exista aún una firma preparada. Además, dependiendo de múltiples factores, puede que no se esté comprobando todas las firmas de las que se dispone.

333


• Hay que tener cuidado, también, con los falsos positivos, ya comentados antes. El mismo tipo de tráfico, viniendo de alguien que esté lanzando un análisis de vulnerabilidades lícito, por la red, puede provocar muchos resultados falsos. 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. Hay que decidir si se cierra el agujero o se investiga además. Hay que decidir si se quiere conocer uno por uno cada intento de ataque o solamente los que tienen éxito. Todo esto hay que decidirlo, dentro de la política de seguridad, antes de instalar el sistema IDS concreto. En las siguientes secciones, se van a analizar dos modelos parecidos de implementación de sistemas IDS. Uno de ellos, Snort, de Sourcefire, IDS de software libre con una gran penetración en el mercado y muy popular en las redes actuales. Se verá a continuación Sguil, otra herramienta de software libre para la detección de intrusiones. Finalmente se va a analizar, brevemente, qué son los honeypots, un conjunto original de soluciones de búsqueda de patrones en los ataques a redes, que es aún bastante novedoso. 2. CASO PRÁCTICO: SNORT Snort es una herramienta de software libre multiplataforma, disponible tanto para sistemas UNIX/LINUX como para Windows, capaz de funcionar como escuchador 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, ya sea de forma manual o mediante herramientas que faciliten el análisis de la información capturada.

334


• 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. Si se desea ver solamente las cabeceras de los paquetes capturas bastará con ejecutar el siguiente comando (los ejemplos que se muestran a lo largo de este epígrafe corresponden a la versión para distribuciones UNIX/ LINUX): #snort –v

Al ejecutarlo se mostrarán por pantalla las cabeceras de los paquetes capturados como se puede ver en la figura 11.4.

Figura 11.4. Captura de cabecera de paquetes realizada con Snort.

Snort seguirá mostrando paquetes por pantalla hasta que se cancele la acción (pulsando Ctrl+C), momento en el que mostrará información estadística de los paquetes analizados, el porcentaje de paquetes que corres-

335


ponden a los diferentes protocolos de red y las acciones realizadas sobre dichos paquetes. 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

La información que se obtiene en este caso puede analizarse en detalle en la figura 11.5.

Figura 11.5. Captura de paquetes realizada con Snort.

Normalmente, no obstante, rara vez se usa Snort de esta manera. 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 ejecu-

336


tará Snort indicando qué información debe registrar de los paquetes, similar a como se hace cuando se quieren mostrar por pantalla, y a continuación se incluirá el parámetro –l seguido del nombre del directorio en el que se desea almacenar los ficheros de registro. #snort –vde –l /log/snort

Así mismo, se puede indicar a Snort que solo registre la información correspondiente a un rango de direcciones IP. El siguiente ejemplo muestra como indicarle que registre solo aquellos paquetes cuya dirección está dentro del rango 19.168.1.0/24. #snort –vde –l /log/snort -h 19.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 herramienta de análisis compatible con el formato binario de tcpdump. Para conseguir este comportamiento hay que utilizar la opción –b #snort –vde –l/log/snort –b

Vistas las capacidades de Snort como escuchador de paquetes, se va a analizar ahora su funcionalidad principal como sistema detector de intrusiones o IDS. Al iniciar Snort en este modo no será necesario que registre todo el tráfico que pasa por la red, sino solo aquel tráfico relacionado con las alertas que se vayan generando. 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 respecto a los mismos. Si no se especifica un directorio concreto para guardar la salida de Snort, se guarda por defecto en el directorio /var/log/snort. Si Snort se va a utilizar como solución IDS a largo plazo, es recomendable, por motivos de eficiencia, eliminar la opción –v. De esta forma se evitará que se muestre por pantalla la salida de Snort y solo se registraran las alertas en el fichero de registro. Así mismo, puede no ser necesario re-

337


gistrar 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 mediante el comando #snort –d –l /log/snort –c snort.conf

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 disco en sencillos ficheros ASCII que podrán ser luego consultados por el analista de seguridad. La información que se recoja en dichos ficheros dependerá del modo de salida seleccionado, lo cual se puede hacer mediante la opción –A (tabla 11.1) Tabla 11.1. Opciones de salida de Snort 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 de 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 unsok

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.

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 con el siguiente comando: #snort –d –l /log –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

338


La primera línea incluye un campo compuesto por tres números. El primero de ellos indica el número de componente de Snort que ha generado la alerta, el siguiente es el Snort IDo Signature ID (número de identificación de la firma de ataque) y el último es el número de versión de la firma. En la siguiente línea puede aparecer información sobre el tipo de ataque, así como el nivel de prioridad del mismo. 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. La figura 11.6 muestra un ejemplo del registro de alertas de Snort.

Figura 11.6. Ejemplo de registro de alertas de Snort.

Los comandos vistos hasta ahora corresponden a la puesta en marcha de Snort de forma manual y su ejecución hasta la pulsación de Ctrl+C. Si se desea utilizar 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.

339


Para lanzar Snort como servicio hay que utilizar el parámetro –D con cualquiera de las combinaciones de parámetros vistas anteriormente. #/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. Dichos modos 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 de funcionamiento Snort no es solo una herramienta de detección de intrusiones, sino una herramienta de prevención de las mismas o IPS (Intrusion Prevention System) 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 sin afectar al tráfico. Cuando el tráfico corresponda con una regla tipo drop esta se registrara en el log como wdrop (would drop). Como se ha comentado, el fichero snort.conf contiene la configuración particular con la que se desea lanzar Snort como IDS. Este fichero contendrá muchos parámetros que van a permitir adaptar el funcionamiento del IDS a las necesidades concretas de la organización. Entre dicho 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 signature de ataque para detectar las amenazas. El fichero de configuración de Snort puede tener definidas cientos de reglas. Para evitar tener un fichero de configuración enorme y difícil de configurar, snort.conf permite incluir otros ficheros por medio del comando include. De esta forma se podrán generar diferentes ficheros de reglas, en las que se incluirán reglas del mismo tipo, y que posteriormente se podrán incluir o insertar en snort.conf por medio de dicho comando en el fichero de configuración. include /etc/snort/rules/name.rules

340


La instalación estándar de Snort incluye una serie de reglas, agrupadas por el tipo de amenazas que comprueban, en varios ficheros como se puede ver en la figura 11.7. Dichas reglas se podrán activar incluyendo la línea de include correspondiente en el fichero de configuración.

Figura 11.7. Ficheros de reglas por defecto de Snort.

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 para informar o prevenir una intrusión. Las reglas van a definir la acción a realizar, así como el protocolo, la fuente y origen de los paquetes, contenido de dicho paquete, valores en cabeceras, etc., que identifican los paquetes como posibles amenazas. A continuación se muestra una regla que trata de localizar paquetes en cuyo contenido están los datos «00 01 86 a5»: alert tcp any any -> (content:»|00 01 86 a5|»; msg:»mounted access»;)

341


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 acción disponible, algunas de las posibles acciones que se pueden definir 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 respuesta de tipo «reset» para comunicaciones TCP o una respuesta de tipo «port unreachable» si el protocolo utilizado es UDP y así cortar la comunicación. • sdrop: bloquea el paquete pero no lo guarda en el registro. La creación de reglas de Snort se escapa al objetivo de este libro. Para descargar Snort, así como información detallada sobre todas sus opciones de configuración y creación de reglas se puede visitar el sitio web oficial de esta herramienta (http://www.snort.org/). Como se ha indicado, la instalación básica de Snort incorpora un extenso set de reglas con todas las publicadas hasta el momento. Dichas reglas son desarrolladas por el equipo de investigación de vulnerabilidades (VRT Vulnerability Research Team) de Sourcefire, desarrollador de Snort. Pero este conjunto básico de reglas no es suficiente, ya que continuamente el equipo de investigación detecta nuevas amenazas y genera nuevas reglas. Por ello, para que Snort sea un IDS efectivo, será necesario actualizar dichas reglas con las nuevas que vaya publicando tanto Sourcefire como otros equipos de investigación que generan reglas para este IDS (en este último caso la suscripción a dichas reglas puede ser gratuita o bajo pago de una cuota). Aunque la descarga de nuevas reglas se puede hacer de forma manual por parte del administrador del IDS, existen herramientas como Pulled_Pork que permiten realizar dicha actualización de forma automática. Snort es posiblemente en el momento de la escritura de este libro el detector de intrusiones más utilizado y extendido. Esta herramienta no solo

342


se instala de forma individual sino que en muchos casos forma parte de herramientas más complejas y sofisticadas de detección de intrusiones que utilizan a Snort como el componente principal del módulo de detección de intrusiones, como por ejemplo Sguil. 3. CASO PRÁCTICO: SGUIL Sguil es una aplicación de software libre desarrollada «por analistas de seguridad, para analistas de seguridad», cuyo objetivo es proporcionar una integración de diferentes herramientas de seguridad. Sguil almacena las alertas generadas por el IDS en una base de datos de conexiones TCP/IP, 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 11.8 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 de forma regular.

Figura 11.8. Arquitectura de un sistema de monitorización Sguil.

343


El servidor coordinara la información recibida de todos los sensores y la almacenara en su base de datos. Se accede a esta información desde terminales de escritorio por medio del cliente Sguil, el cual es multiplataforma y está disponible tanto para sistemas UNIX/LINUX como para sistemas Windows. Como ya se comentó en el apartado introductorio, para que los sensores Sguil sean capaces de capturar el tráfico de su segmento de red, deberán estar conectados o bien a un concentrador, recibiendo de esta forma automáticamente copia de todos los paquetes que pasen por el mismo, o bien a un conmutador que haya sido configurado para enviar copia de todos los paquetes de datos que pasen por el al puerto en que esté conectado el sensor. Cada sensor por tanto monitorizará el tráfico que pase por el segmento de red al que esté conectado (cabe la posibilidad de instalar más de un sensor Sguil en una máquina física, cada uno de ellos monitorizando un segmento distinto). Cada uno de estos sensores utiliza diferentes herramientas para monitorizar el tráfico y obtener la información que posteriormente enviará al servidor: 1. Sguil hace uso de Snort para obtener alertas de seguridad y/o intrusión. Hay una estrecha relación entre esta nueva herramienta de seguridad y la analizada en el apartado anterior. 2. Sguil integra también SANCP (Security Analyst Network Connection Profiler, una herramienta que permite obtener información estadística del tráfico analizado) para obtener datos de sesiones TCP. 3. Una segunda instancia de Snort se encarga de recolectar copia de todos los paquetes que pasan por el sensor (utiliza las funciones de capturador de paquetes o sniffer que proporciona Snort). 4. Gracias a tcpflow es capaz de reconstruir datos de la capa de aplicación. 5. 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. 6. Una instancia de MySQL guarda toda la información obtenida por Snort.

344


Como se ha indicado, toda la información obtenida será enviada regularmente por el sensor al servidor Sguil, donde será puesta a disposición de los analistas de seguridad de la organización. La aplicación cliente permite conectar con cualquier servidor Sguil por medio de su dirección IP, el puerto en el que está funcionando el servicio, así como un usuario y contraseña habilitado en dicho servidor para poder acceder al mismo, como se puede apreciar en la figura 11.9. Como se ha comentado, Sguil utiliza a 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, mientras que la instalación básica de Snort obliga a revisar los ficheros de log para consultar las alertas detectadas o a instalar software de terceros que proporcionen un interfaz gráfico a las mismas como puede ser ACID (http://acidlab.sourceforge.net).

Figura 11.9. Pantalla de login del cliente Sguil.

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 de la ventana principal de la aplicación (la figura 11.10 muestra el interfaz

345


principal de Sguil) divididas en tres niveles. El primer nivel recoge las alertas más severas, la central recoge alertas que representan un menor riesgo y la última corresponde a las alertas menos severas. Estas ventanas de prioridad se corresponden con los niveles de prioridad de Snort. Así, la ventana superior recoge las alertas correspondientes a los niveles de alerta 1 y 2, la de en medio recoge las alertas correspondientes a los niveles de alertas 3 y 4, y la última ventana las correspondientes al nivel 5. Esta división de ventanas puede ser configurada de forma que solo se muestre uno o dos niveles de alerta asignando en cada uno de ellas la correspondencia con los niveles de alerta de Snort que se desee.

Figura 11.10. Interfaz principal de Sguil.

La parte inferior del interfaz principal de Sguil se divide en dos mitades. En la parte izquierda puede mostrar diferente información sobre la alerta que se haya seleccionado de las mostradas en la parte superior. La información mostrada puede contener información sobre la dirección IP de la que proviene el tráfico que ha generado la alerta, mostrando la in-

346


formación obtenida por medio de la resolución DNS. Esta parte del interfaz también puede mostrar los mensajes del sistema (por ejemplo la cantidad de espacio en disco que queda disponible para la captura de tráfico), y también puede mostrar (como se ve en la figura 11.10) el estado de los distintos agentes que componen el sistema Sguil. La parte inferior derecha de la pantalla principal de Sguil está dedicada a la alerta que se haya seleccionado en la parte superior. Dependiendo del tipo de paquetes capturados que hayan provocado la alerta, la información mostrada será diferente. Cuando la alerta corresponda a un ataque de reconocimiento de puertos abiertos esta sección mostrará el tipo de paquetes originados por dicho escaneo de puertos. En cambio, en el resto de alertas, esta sección mostrará los detalles del paquete, tanto sus datos de cabecera como el contenido de los mismos. En esta misma sección, y justo encima de los detalles del paquete se puede activar la opción para que se muestre la regla Snort que ha provocado la alerta. La figura 11.10 muestra también la información detallada correspondiente a una alerta de nivel intermedio correspondiente a un intento de ataque de tipo desbordamiento (overflow) contra MS-SQL. Dicha alerta tiene el valor RT en la columna ST (status). Eso quiere decir que dicha alerta ha sido obtenida por medio de la captura de tráfico en tiempo real (real time) por el sensor y que está pendiente de ser validada o «intensificada». La columna CNT (count) indica el número de eventos similares que han sido detectados. En la figura 11.10 se puede observar también que una de las alertas de nivel severo muestra 64 alertas correspondientes a un aparente escaneo SSH. La tercera columna muestra el sensor que ha lanzado dicha alerta, y la cuarta muestra la combinación de número de sensor y el número de alerta identificada. A continuación se puede ver la fecha y hora del evento, así como la dirección IP y puerto de origen/destino, así como el protocolo del/los paquetes (columna Pr) y por último el mensaje de alerta generado por Snort. En la parte inferior derecha, donde se muestra la regla Snort que ha generado la alerta, Sguil muestra un botón (marcado como snort.org) que si se pulsa abrirá, en un navegador web, la url correspondiente a la documentación sobre la alerta seleccionada en el sitio web de Snort. Además de la información recogida en la pantalla principal referente a las alertas de seguridad, Sguil recolecta también datos de sesiones TCP así

347


como el contenido completo de los paquetes interceptados, lo cual puede permitir obtener más información sobre cualquier alerta. 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 (EventHistory): Muestra cualquier comentario o estado de validación de la alerta que le haya asignado un analista al revisar las alertas capturadas por Sguil. Las alertas nuevas marcadas como RT no tendrán todavía esta opción. • Transcripción (Transcript): 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. La figura 11.11 muestra un ejemplo de una transcripción correspondiente a un ataque de fuerza bruta contra un servidor FTP.

Figura 11.11. Transcripción de sesion obtenida con Sguil.

• Forzar nueva transcripción (Transcript - Force New): Regenera la transcripción generada anteriormente para esta alerta. Es bastante útil cuando se genera la transcripción de una sesión todavía abierta y se quiere actualizar su contenido en un momento posterior (siga la sesión abierta o haya sido ya terminada).

348


• 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): Al igual que en el caso de la transcripción, permite indicar a Ethereal que debe inspeccionar los nuevos paquetes originados por la sesión que se esté analizando en ese momento. 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, e incluso las herramientas utilizadas para el mismo. Una vez identificada una alerta relevante, Sguil permite obtener mediante la opción «Query Session Table» todas las sesiones originadas desde la dirección del atacante. Para cada sesión mostrará un listado de los paquetes capturados indicando las direcciones IP de origen y destino, el protocolo, la fecha y hora de registro, etc. Como se puede comprobar, Sguil proporciona gran cantidad de información que permite investigar los diferentes eventos de seguridad registrados. Pero el objeto de Sguil no es que el analista pueda obtener toda esta información sobre el ataque, el objetivo final es que este sea capaz de tomar decisiones gracias a dicha información. A la vista de la información relativa a cada alerta registrada el analista deberá ser capaz de analizarla y tomar un decisión sobre la misma. Sguil permite asociar diferentes categorías a las alertas y el analista podrá marcar cada una de ellas dentro de un determinado nivel por medio de las teclas de función. Las categorías disponibles son: • F1: Categoría I: Acceso root/Admin no autorizado. • F2: Categoría II: Acceso de usuario no autorizado. • F3: Categoría III: Intento de acceso no autorizado. • F4: Categoría IV: Ataque de tipo de denegación de servicio efectivo. • F5: Categoría V: Violación de la política de seguridad. • F6: Categoría VI: Reconocimiento o escaneo de puertos abiertos. • F7: Categoría VII: Infección por virus informático. • F8: No es necesario realizar ninguna acción. • F9: Escalar el evento.

349


Si el analista encargado de revisar las alertas considera que una alerta corresponde a actividad real, y por tanto es un falso positivo, seleccionará la alerta y pulsará F8 para descartarla. Si por el contrario considera que la alerta es real y que la actividad registrada corresponde a alguna de las categorías mostradas, en ese caso seleccionará la alerta y pulsará la tecla de función correspondiente. En caso de que no sea capaz de tomar una decisión sobre un determinada alerta «escalará» la alerta pulsando F9 para que sea otro analista más experimentado quien analice la actividad del posible atacante y trate de clasificarla. Se puede descargar Sguil, así como información adicional sobre como instalarlo y configurarlo, en el sitio web oficial de esta herramienta (http:// sguil.sourceforge.net).

4. HONEYPOTS Este término fue utilizado por primera vez en el ya clásico libro de Bellovin y Cheswick sobre cortafuegos (ver bibliografía) y hacía referencia a un equipo «falsificado», en el sentido de que desde el nombre hasta los procesos del sistema, pasando por todas las cuentas de usuario y de todos los ficheros de datos, todo estaba modificado para capturar información de los atacantes que, atraídos por la información que se podía obtener del sitio, se paseaban obteniendo información y accediendo a todas las trampas, previamente preparadas. El acceso es «a un panal de rica miel». Quizás lo más adecuado es decir de estos sistemas que son señuelos usados para obtener datos sobre el comportamiento de intrusos. Normalmente estos señuelos parecen contener vulnerabilidades que los hacen aún más atractivos para los hackers. Realmente está protegiendo el acceso a los datos reales, a los controles de administración y a otros ordenadores de la red donde está ubicado. Mediante este método, los administradores pueden recoger datos sobre la identidad, el acceso usado y los métodos de ataque utilizados. Si funciona como es debido, se puede ver cómo el intruso trata de explotar datos y controles del sistema, sin realizar ningún tipo de detección como las vistas en este capítulo.

350


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. Resumiendo, 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 defienden que se ubique en la red interna, detrás de un encaminador o de un cortafuegos, pues con ello: • Se pueden aprovechar mejor los registros de operación del encaminador o del cortafuegos, en los que suele haber información detallada sobre los puertos y los tipos de pruebas hechas por el atacante. • Se puede configurar el encaminador o cortafuegos para que envíen una alerta al administrador 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 el caso de resultar gravemente afectado el señuelo. El sistema debe tener un nombre atractivo, como correo, fichero, departamento-personal, debe tener varios niveles de log, incluyendo siempre una copia del registro a un sistema servidor de log, al que le sea imposible de acceder al atacante. Otro nivel de log interesante es poner un sniffer (un analizador de tráfico) en el segmento del señuelo, para capturar todo el tráfico que entre y salga de la máquina. Este sniffer puede ser a su vez un

351


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, también, guardarse una imagen de los binarios del sistema, mediante una utilidad como Tripwire y almacenarla en remoto. Una vez el señuelo ha sido realmente comprometido, suele ser interesante pararlo y volver a colocarlo, con la misma configuración y las vulnerabilidades usadas por el atacante arregladas, pero con nuevas vulnerabilidades, para aprender nuevas técnicas de ataque. Un honeypot puede interactuar de diversas maneras con el intruso. Puede ser desde un simple sistema que registra las peticiones hechas a unos determinados servicios, hasta sistemas completos que presentan diferentes servicios explotables al intruso. Obviamente, el nivel de interacción que puede tener el intruso con los del primer tipo es muy limitado, mientas que con el segundo a fin de cuentas está interactuando con un sistema real. Por supuesto, a mayor nivel de interacción, mayor es la cantidad de información que se podrá obtener sobre el intruso y sus métodos de ataque. Por otro lado, hay que tener en cuenta que un sistema completo supone un mayor riesgo que un simple «escuchador» de actividad en determinados puertos. Teniendo en cuenta estas consideraciones, 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. Normalmente 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 para nuestra organización pero también son los que menos información sobre el intruso nos van a permitir obtener. Su objetivo no es representar sistemas operativos completos, sino que simulan algunos servicios, por ello es muy difícil que puedan ser completamente infiltrados. Este tipo de honeypots están orientados a capturar comportamientos de intrusión conocidos, y no son válidos para tratar de descubrir

352


nuevos métodos y técnicas de intrusión. También son útiles con fines estadísticos, ya que nos van a permitir conocer con qué frecuencia es atacado nuestro sistema. • Honeypots de interacción media: Este tipo de soluciones tienen más capacidad de interacción con el intruso. Están diseñados para dar cierta respuesta más allá de las respuestas simples que proporcionan los de baja interacción. Estas soluciones pueden llegar a simular algunas vulnerabilidades conocidas, o el comportamiento de algunos servidores (web, ftp…). Cuanto más realista sea la funcionalidad que simulan, más fácil será que el intruso piense que está interactuando con un servicio real, que tratará de explotar. Por contra, 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 información que las del grupo anterior. Con estos honeypots 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 accede a nuestro sistema y como eleva sus privilegios, se puede llegar incluso a capturar las herramientas que ha utilizado en el proceso (si el atacante descarga dichas herramientas a la máquina comprometida, es decir, al honeypot, este podrá capturar dicha transferencia para posteriormente reconstruir dichas herramientas descargadas). • 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, por el contrario son los sistemas que más nos va a costar mantener y los que implican un mayor nivel de riesgo. Con estas soluciones lo que presentamos al intruso es un sistema real con el que interactuar. En dicho sistema nada es simulado. Gracias a estos sistemas podemos descubrir nuevas herramientas usadas por los intrusos e identificar nuevas vulnerabilidades en los sistemas operativos o aplicaciones. Lo único que diferencia estos sistemas de sistemas reales es que en los honeypots no hay ningún tipo de información relevante, no son sistemas en producción. Dado que en este caso los intrusos interactúan con un sistema real, también suponen 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, esta vez sobre equipos que si que tiene un valor real. Por ello, este tipo de soluciones se suelen implantar en sistemas

353


muy controlados, normalmente se sitúan detrás de un firewall que nos va a permitir controlar el tráfico entre el honeypot y el intruso evitando que el sistema pueda llegar a ser usado para atacar otros sistemas. Desde hace pocos años, un grupo de profesionales de seguridad ha desarrollado el concepto analizado y ha creado un proyecto denominado proyecto Honeynet, dedicado a aprender tácticas, técnicas y herramientas, así como los motivos de los atacantes y, además, compartir tal conocimiento. Su sitio web es especialmente interesante y se puede localizar en http://project.honeynet.org/. Una 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 proporcionan, realmente, servicios reales. Esto hace que sean más difíciles de detectar. 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. Este proyecto 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. Además de la clasificación vista de los honeypots, 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 los honeypots físicos suelen ser soluciones de alta interacción. • Honeypots virtuales: En vez de instalar la solución sobre una máquina física se puede instalar sobre la misma una serie de máquinas virtuales e instalar las soluciones honeypot sobre las mismas. Esto va a permitir tener varios honeypots distintos sobre la misma máquina física, pudiendo tener las distintas máquinas virtuales distintos sistemas operativos. Este tipo de estructuras van a permitir escalabilidad, así como economizar en los recursos disponibles para poner en marcha el sistema.

354


4.1. Ejemplos de honeypots reales Para finalizar esta sección, comentaremos varios ejemplos de este tipo de soluciones de seguridad: Empezaremos analizando Deceptiontoolkit: Fue el primer honeypot de baja interacción de código abierto. Fue desarrollado para sistemas UNIX/ LINUX y aunque en estos momentos ha quedado obsoleto, se cita por ser precisamente uno de los primeros honeypots, y todavía se puede obtener en http://www.all.net/dtk/index.html. 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 y accesibles es Back Office Friendly (BOF). Esta solución es posiblemente el honeypot de baja interacción más sencillo que se puede encontrar. Es una aplicación gratuita para sistemas Windows que puede monitorizar hasta siete servicios «fijos», no pudiendo cambiarse cuales son dichos servicios en ningún caso. Es una solución extremadamente fácil de usar pero a su vez de una funcionalidad muy restringida. 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 esos servicios, el intento de acceso es registrado y se genera una alarma. Aunque dispone de cierta capacidad de simulación de alguno de los servicios, esta capacidad es muy limitada. Con esta solución no se puede conseguir demasiada información sobre los medios por los que el intruso ha accedido. Si se instala este honeypot en la red interna y se detectan intentos de acceso querrá decir que hay algún problema en las defensas perimetrales. El funcionamiento de la aplicación es sencillo, lo que hace es crear «escuchadores» en aquellos puertos que monitoriza. Cuando se realiza una conexión con un puerto, el escuchador establece una conexión completa, registra el intento, genera una alarma y finalmente cierra la conexión. Los servicios que se puede monitorizar con BOF son los siguientes: Back Orifice (UDP 31337), FTP (TCP21), Telnet (TCP23), SMTP (TCP 25), HTTP (TCP 80), POP3 (TCP 110) e IMAP (TCP 143). En la configuración

355


de este honeypot simplemente se puede decidir cuáles de estos servicios se desea monitorizar. Hay una opción que permite activar una muy simple simulación de estos servicios que permitirá obtener algo más de información. Como se ha dicho BOF registra todas las conexiones percibidas en un log. Dicho log contiene información sobre el origen de las conexiones, la fecha y hora, el puerto accedido, y si se ha activado la simulación, guardará las peticiones recibidas del intruso. El log de BOF es local y solo se puede consultar por medio de su consola. Por último, decir que el mayor riesgo de este honeypot no está en el mismo, sino en el sistema sobre el que esté instalado. Si el sistema no es seguro, el intruso no podrá comprometer los servicios que presenta BOF, pero puede ser que llegue a comprometer el ordenador sobre el que se ha instalado este honeypot. Hay que decir también que aunque este honeypot no está disponible en la URL del creador todavía se puede encontrar por la red. Otro honeypot interesante es Tiny Honeypot. Es una solución de código abierto para UNIX/LINUX, que se puede descargar desde http://freecode. com/projects/thp. Es un honeypot 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 continuación procede a registrar toda la información que pueda. Lo que pretende Tiny Honetpoy presentando esa shell es hacer crear al intruso que su ataque ha sido efectivo y que ha conseguido un acceso privilegiado a la máquina. El honeypot registrará toda la actividad del intruso y si hay suerte se capturarán comandos interesantes, como aquellos mediante los cuales el atacante tratará de descargar las herramientas que le permitan escalar el ataque. Si se registra la dirección de donde se descarga dichas herramientas, posteriormente el equipo de seguridad podrá conectarse a dicha dirección y descargas las herramientas para estudiarlas y analizarlas. Tiny Honeypot crea un registro resumen de todas las conexiones. Para cada conexión indica cuándo se inició, cuántos bytes se transfirieron y cuánto duró. Además del registro resumen, realiza un completo log de sesión, en el que se guardan todos los datos recibidos durante la misma. Para ello, se crea un fichero de registro para cada sesión. Otro ejemplo es GHH - Google Hack Honeypot, una herramienta de código abierto disponible tanto para UNIX/LINUX como para Windows

356


(http://ghh.sourceforge.net/). GHH es un nuevo tipo de honeypot orientado a la detección de un nuevo tipo de tráfico malicioso, el del hacking a través de buscadores. Actualmente los buscadores realizan una indexación de todos los sitios web que pueden encontrar, con el fin de proporcionar sus servicios de búsqueda, pero en esa indexación, como un efecto colateral, están recuperando información sensible de algunos servidores web mal configurados, de forma que un hacker habilidoso puede realizar una serie de consultas en dichos buscadores que le van a llevar a localizar dichos servidores web vulnerables. 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 hace GHH es emular un servidor web vulnerable con errores de configuración, permitiendo ser indexado por los buscadores, de forma que pueda ser encontrado por este nuevo tipo de intrusos. Para que este servicio no pueda ser encontrado accidentalmente por visitantes «normales» y provocar por tanto falsos positivos, GHH queda oculto tras un link invisible que solo los rastreadores de los buscadores pueden encontrar. GHH es multiplataforma ya que se instala sobre un servidor Apache, disponible tanto para las distintas distribuciones UNIX/LINUX como para Windows. Además tiene su propio log, diferente del registro del servidor Apache. Gracias al campo Referer de la cabecera HTTP, GHH automáticamente detecta como se ha encontrado el sitio web peticionado y por tanto puede evitar registrar el tráfico de visitantes »normales». Adicionalmente GHH detecta si ha sido encontrado por alguna búsqueda «maliciosa» en los buscadores dejando registro de la misma. Gracias a esta información se puede saber si alguien ha lanzado un reconocimiento contra el servidor web, además de que va a permitir tener más información de cómo se realizan este tipo de ataques. Otro proyecto de software libre bajo licencia GNU para UNIX/LINUX es Honeyd (http://www.honeyd.org/). Es posiblemente el honeypot de baja interacción más versátil que se puede encontrar en el momento de la escritura de este libro. Permite crear una serie de máquinas virtuales en la red, dichas máquinas pueden ser configuradas para simular que están ofreciendo diferentes servicios, así como diferentes sistemas operativos. Además, Honeyd es capaz de asumir hasta miles de direcciones IP no usadas en nuestra red y atender las peticiones realizadas a las mismas.

357


Honeyd es un honeypot 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 simuladas. • Cada máquina virtual puede asumir una «personalidad» diferente. Puede emular cualquier sistema operativo, no solo Windows, Linux…, sino también distintos sistemas operativos de conmutadores, enrutadores…. — La emulación de los sistemas no se realiza solo a nivel de aplicación sino también a nivel de la pila de IP. — Puede escuchar cualquier puerto TCP o UDP. Así mismo es capaz de atender las peticiones ICMP de ping. — Para los puertos TCP se pueden configurar scripts de emulación de servicios tan completos como se desee, cuanto más elaborado sea el script más fácil será engañar al intruso. Otra peculiaridad de Honeyd es que permite redirigir las peticiones hechas a una dirección IP y puerto concreto a un servidor que presente dicho servicio. No hace falta crear un script de emulación, simplemente se puede redirigir la petición a un servidor real. Proporciona también un log de paquetes y de servicios bastante detallado. Si se desea, además, se pueden configurar los scripts de simulación desarrollados para que realicen su propio registro, lo cual permitirá guardar la información que se considere relevante para el posterior análisis del intento de ataque. Uno muy especial, y ya comentado, es Honeynet, un proyecto dedicado al estudio de los distintos ataques a redes (http://www.honeynet.org). Honeynets son honeypots de alta interacción, de hecho son la solución honeypot más compleja que se puede poner en marcha. La idea es sencilla, construir una red con varios servidores funcionando, exactamente igual que los que se pueden encontrar en cualquier organización. En este caso se está hablando de sistemas completos y no de meras emulaciones como las vistas hasta ahora. 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

358


qué intentos de intrusión recibe. Al ser sistemas completos, estos pueden ser reconocidos, atacados y explotados completamente. Los sistemas que pueden constituir una Honeynet pueden ser cualquiera de los sistemas operativos que normalmente se encuentran en los servidores en producción. Honeynet proporciona todas las funcionalidades de los honeypots que se han visto hasta ahora, permite detectar ataques y monitorizar todos los protocolos IP. Pero Honeynet es mucho más, esta solución permiten capturar tanto las amenazas conocidas como las desconocidas, lo que lo convierten un una estupenda herramienta de investigación para determinar quiénes son los atacantes, que herramientas usan para perpetrar el ataque, que tácticas emplean, e incluso cuáles son sus motivaciones. Poner en marcha una Honeynet supone el montar una serie de servidores que simulan un entorno en producción. Al no ser servidores reales, todo tráfico dirigido a cualquiera de las estas máquinas que componen la Honeynet debe ser considerado sospechoso. Así mismo, se ha de asumir que cualquier tráfico saliente de las maquinas que componen la Honeynet supone que el sistema ha sido comprometido y el intruso está lanzando actividad desde el mismo. Hay tres aspectos fundamentales en una arquitectura Honeynet: 1. Control de datos: Este aspecto es el que va a mitigar el riesgo que un honeynet supone. Al ser sistemas reales 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. Dado que una vez que el sistema sea comprometido es susceptible de ser usado para atacar otros sistemas, es necesario automatizar el control de datos y no hacerlo depender de una intervención manual que puede llegar demasiado tarde. Hay varias formas de realizar todo el control de datos, por ejemplo permitiendo todo el tráfico entrante pero nada del tráfico saliente, solo que hacer esto seguramente alertará al intruso de que algo no anda bien y posiblemente corte la conexión antes de que se pueda llegar a obtener información relevante. Por ello, se puede, por ejemplo, limitar el número de conexiones salientes a un cierto número por día, asegurándose así que la maquina comprometida no va a poder ser usada para lanzar ataques de denegación de servicio contra otros sistemas.

359


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. Por ello es importante seguir algunas recomendaciones, como no guardar dicha información localmente en el honeypot, ya que, en este caso, el atacante, si consigue privilegios suficientes, podría darse cuenta de dicho y borrar los datos obtenidos sobre el ataque. 3. Recogida de información: Cuando se despliegan varias Honeynets en diferentes redes, será necesario recopilar dicha información de forma centralizada y agregar dicha información. Las tecnologías de virtualización como VirtualBox, VMWare o User-Mode Linux suponen una herramienta que facilita enormemente su creación y producen una gran reducción de costes. El coste de crear una completa Honeynet mediante el uso de máquinas físicas puede ser realmente elevado, por lo que contar con este tipo de herramientas, que permiten instalar varias máquinas virtuales en una máquina física supone un considerable ahorro económico. Por otro lado, todas estas soluciones permiten el guardar copias de las máquinas virtuales en un estado determinado, por lo que en caso de que sean comprometidas es sencillo devolver dichas máquinas a un estado anterior a dicha intrusión sin la necesidad de tener que reinstalar el sistema desde cero, con el consiguiente ahorro de tiempo que supone. Finalmente citaremos brevemente Argos (http://www.few.vu.nl/argos/). Argos es un nuevo tipo de honeypot virtual, de alta interacción, desarrollado por la Universidad de Vrije (Amsterdam) para sistemas UNIX/LINUX. La novedad que supone es que es capaz de detectar ataques para los que todavía no existe ningún parche. Al igual que las soluciones vistas anteriormente, 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 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, y para ello asume que para que el ataque sea exitoso el intruso debe de alguna manera influir en la aplicación o servicio con la que ha establecido la comunicación. Para ello tratará de re-

360


bosar el buffer (buffer overflow), para lo que suministrará un script que sea capaz de sobrescribir determinadas áreas de la memoria. Para hacer esto, el intruso va a tener que enviar datos «malformados». Cuando un ataque es detectado, Argos realiza una descarga de la información en memoria y es capaz por tanto de registrar la huella del ataque, de ese desbordamiento del buffer. Esta capacidad para detectar nuevos ataques convierte a Argos en un excelente honeypot de investigación. Argos se basa en Qemu, un emulador de software libre para máquinas virtuales. Los sistemas Honeypot vistos en este apartado no son ni mucho menos todos los disponibles en este momento. El documento se ha centrado en honeypots de código abierto, pero también hay gran variedad de soluciones comerciales. En la dirección http://www.honeypots.net/honeypots/products se puede encontrar una relación de muchos de los honeypots de código abierto que se pueden utilizar en el momento de la escritura de este libro.

361


5. CONOCIMIENTOS Y COMPETENCIAS ADQUIRIDAS En este capítulo se ha hecho un análisis de las características y funcionamiento generales de las herramientas conocidas como sistemas de detección de intrusiones, utilizadas dentro de la denominada fase de monitorización del desarrollo del proceso de seguridad de una organización. Empezando por la definición de lo que es y para qué sirve un IDS, se ha hecho una caracterización de los distintos tipos de IDS del mercado, catalogándolas por tecnología de captura de mensajes de ataque y por ubicación de los sistemas de detección de intrusiones en la topología de la red. Con respecto al primer criterio, se habla de sistemas IDS basados en anomalías o basados en firmas. Con respecto al segundo criterio se habla de sistemas ubicados en sistemas, o basados en un sistema o basados en la red. Se ha hecho énfasis en el concepto de firma, como el código interno o caracterización concreta, mediante uno o varios mensajes, de un ataque por la red contra uno o varios dispositivos. Se ha caracterizado el funcionamiento típico de un analizador, desde la captura de los mensajes, hasta la respuesta que puede dar una consola remota de gestión, al recibir la alarma que le envía el sensor. Se ha estudiado el caso de los IDS de red, basados en firmas, Snort y Sguil, analizando su terminología y discutiendo su funcionamiento básico. También se han analizado los honeypots, una herramienta de obtención de información sobre los hábitos y herramientas de trabajo de los posibles atacantes. Finalmente, se ha de volver a una idea esencial: tampoco los sistemas IDS, por sí solos, son suficientes para garantizar la seguridad. Aún cuando están bien configurados, pueden provocar una serie de problemas que hay que tener en cuenta. Uno de los problemas más graves es el de los falsos positivos. Habiendo, como hay aún, muchos falsos positivos esto implica que se puede terminar no haciendo demasiado caso a las alarmas que se recibe, dándose un poco el caso de la célebre fábula de «Pedro y el lobo»: tantas veces se avisa de que la alarma es real, no siéndolo, que cuando realmente se seña-

362


la una alarma real, no se le hace caso, provocando un problema de seguridad cuyo origen es el hastío. Quizás el más grave de los posibles problemas sea el de tener preparada una respuesta para cualquier tipo de alarma. Está muy relacionado con el anterior y se refiere a que no es fácil preparar toda posible respuesta, a poder ser inmediata, para cualquier problema y, además, que no importe si muchas veces la alarma es un falso positivo. Por esta razón, también se está empezando a acudir a la solución de que tales respuestas se lleven a cabo por personal muy especializado y habitualmente externo a la organización. Son las compañías de monitorización gestionada de la seguridad y, entre ellas, puede señalarse, por los éxitos obtenidos en los últimos años, a BT Counterpane Security, dirigida por un famoso experto en criptografía, Bruce Schneier. Otro punto interesante de resaltar es en muchos casos la dificultad técnica de la puesta en marcha de algunas de estas herramientas. Configurar Snort o Sguil puede ser en muchos casos complicado, especialmente para el que se inicia en el mundo de la seguridad informática. Dada esa problemática, hay varios proyectos personales de entusiastas de la seguridad que han creado distribuciones completas de LINUX que incluyen preinstaladas todas estas herramientas, facilitando enormemente la labor a los neófitos a la seguridad informática. Como ejemplo sirva la distribución Security Onion que se puede descargar desde el sitio web del creador de la misma (http://securityonion.blogspot.com.es/). 6. BIBLIOGRAFÍA BEJTLICH, R. (2005): The Tao of Network Security Monitoring. Ed. Addison Wesley. CHESWICK, W. R.; BELLOVIN, S.; RUBINA, A. (2003): Firewalls and Internet Security: Repelling the Wily Hacker. 2.ª edición. Addison-Wesley Professional. PROVOS, N.; THORSTEN, H. (2007): Virtual Honeypots: From Botnet Tracking to Intrusion Detection. Addison Wesley Professional. SNORT, sitio web del proyecto de software libre Snort. URL: http://www. snort.org SGUIL, sitio web del proyecto de software libre Sguil. URL: http://sguil. sourceforge.net/

363


7. PALABRAS CLAVE Honeynet, Honeypot, IDS, IPS, Sguil, Snort.

8. EJERCICIOS RESUELTOS 1. Los sistemas honeypot son completamente invulnerables a ataques. a) Verdadero, por esta razón son los más utilizados como defensa. b) Falso, suelen no permitir, desde ellos, el ataque a sistemas reales, pero ellos mismos si son vulnerables. c) Verdadero, por esta razón los hackers atacan tanto estos sistemas para obtener información de cómo vencer sus defensas. d) Falso, esto solo es verdad si colaboran con un sistema IDS. Solución: b. 2. Indique los tipos de sistemas IDS con respecto a su ubicación en la topología de la red donde se vaya a instalar. a) b) c) d)

Basados en la red y basados en firmas de red. Basados en la red y basados en sistemas concretos de la red. Basados en firmas y basados en anomalías de la red. Basados en anomalías de la red y mixtos de sistemas y red.

Solución: b. 3. Con un único sistema IDS no puede monitorizarse más que el tráfico del segmento de red donde está instalado. a) Verdadero, pues solo dispone de una interfaz de monitorización. b) Verdadero, pues no existen sistemas de suficiente rendimiento como para monitorizar el tráfico de más de una interface. c) Falso, es sólo una cuestión de rendimiento y no de arquitectura. De hecho, Sguil implementa la posibilidad de monitorizar varios segmentos de red simultáneamente. d) Falso, depende de la topología específica de la red. Solución: c.

364


4. ¿Cuál es la definición de un falso positivo en el entorno de los sistemas IDS? a) Un falso positivo es un término, utilizado solo por Cisco Systems, para referenciar los ataques a través de un cortafuegos, detenidos por el cortafuegos y para los que éste genera un mensaje de log que llega al sistema IDS. b) Un falso positivo es un ataque no capturado por el sistema IDS, aún cuando éste estaba configurado para ello. c) Un falso positivo es un ataque falso que, no obstante, genera una alarma de la que se puede obtener información positiva para diferenciar la próxima vez. d) Un falso positivo es una alarma generada por un sistema IDS que resulta no estar asociada con un ataque real. Solución: d. 5. ¿Cuál de las siguientes acciones se puede asignar a las reglas de Snort para que este funcione como IPS (Intrusion Prevention System)?: a) b) c) d)

pass. alert. reject. log.

Solución: c. 9. EJERCICIOS DE AUTOEVALUACIÓN 1. ¿De qué fase del desarrollo del proceso de seguridad forma parta el uso de herramientas de detección de intrusiones? a) b) c) d)

Monitorización. Análisis de vulnerabilidades. Implementación. Este tipo de herramientas se usan en todas las fases de desarrollo del proceso de seguridad.

2. ¿Qué es la firma o signature de un ataque? a) Parte del contenido de un paquete que identifica de forma univoca a un paquete como malicioso.

365


b) La firma la compone un paquete o grupo de paquetes que indican con cierta fiabilidad que se está produciendo un ataque. c) Parque de un paquete interceptado que contiene la firma digital del ataque. d) Es el código de identificación de ataque (Signature ID) que asigna Snort a cada uno de los ataques que tiene categorizados. 3. Snort tiene los siguientes modos de funcionamiento: a) b) c) d)

Sniffer de paquetes y registro de paquetes. Sniffer de paquetes, IDS e IPS. Registro de paquetes e IDS. Sniffer de paquetes, registro de paquetes e IDS/IPS.

4. ¿Cuál de las siguientes herramientas de seguridad forman parte de Sguil?: a) b) c) d)

Snort proporciona datos de alerta y captura de paquetes. SANCP para obtener datos sobre sesiones TCP. tcpflow permite reconstruir datos de la capa de aplicación. Todos los anteriores son componentes de Sguil.

5. ¿Cuál de los siguientes NO es un objetivo perseguido mediante el uso de Honeypots?: a) Detectar intrusiones. b) Crear confusión en el atacante. c) Sustituir el uso de herramientas de detección de intrusiones como Snort o Sguil. d) Investigar las técnicas utilizadas por los atacantes.

366

Tema 12

Diseño seguro de redes: alta disponibilidad y redundancia

1. Introducción, orientaciones para el estudio y objetivos 2. Diseño de soluciones de alta disponibilidad 3. Los problemas de infraestructura y soluciones 4. Los problemas en el nivel 2 de OSI y soluciones 5. Los problemas en el nivel 3 de OSI y soluciones 6. Consideraciones para el resto de los niveles OSI 7. Consideraciones para el almacenamiento en red: SAN (Storage Area Networks) 8. Consideraciones para los dispositivos de seguridad 9. Conocimientos y competencias adquiridas 10. Bibliografía 11. Palabras clave 12. Ejercicios resueltos 13. Ejercicios de autoevaluación

1. INTRODUCCIÓN, ORIENTACIONES PARA EL ESTUDIO Y OBJETIVOS En los entornos de red actuales un factor que hay que tener en cuenta, desde el punto de vista operativo, además de todos los demás de los que se ha hablado hasta aquí, es el de la alta disponibilidad de las redes y, como consecuencia, de los servicios que éstas ofrecen. En el modelo de economía de las redes actuales las operaciones normales de la red han dejado de seguir el modelo de 8×5 (8 horas al día, 5 días a la semana) y se tiende a conseguir el modelo 24×7 (24 horas al día, 7 días a la semana). En este entorno en que las redes y los servicios deben estar permanentemente disponibles, las técnicas de alta disponibilidad van haciéndose un hueco, van imponiéndose, como soluciones necesarias. Especialmente en el caso del acceso a los datos de las compañías, las cuales tratan de conseguir que haya un 100% de disponibilidad del acceso a los propios datos. En la industria hace ya tiempo que está establecida una cierta definición de «alta disponibilidad». Se podría pensar que el 99% del tiempo del año funcionando es suficiente, pero, si se realiza el cálculo, se comprueba que el 1% del tiempo del año no funcionando significa 83 horas al año, tiempo que muchas organizaciones no pueden permitirse. Cuando se habla de alta disponibilidad se habla de «los tres nueves» (99,999% del tiempo del año funcionando correctamente), lo que quiere decir un tiempo de caída permitido de 5 minutos al año. Tan importante es el número, y poder medirlo, que existe una medida estándar del nivel de disponibilidad de un dispositivo cualquiera, que se puede expresar como: Disponibilidad = TMEF/(TMEF + TMR)

369


siendo TMEF el Tiempo Medio Entre Fallos y TMR el Tiempo Medio de Reparación. Tal nivel de disponibilidad (99,999% del tiempo del año, tabla 12.1) requiere tratar de evitar una serie de posibles problemas lógicos, físicos y organizativos. Tabla 12.1. Disponibilidad y tiempo de caída anual Disponibilidad

Tiempo de caída /min./año)

99,999%

5

99,99%

50

99,9%

500

99%

5000

90%

50000

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. En este tema se discutirán los conceptos relacionados con la alta disponibilidad en redes, sus problemas, sus posibles soluciones, los parámetros

370

DISEÑO SEGURO DE REDES: ALTA DISPONIBILIDAD Y REDUNDANCIA

relacionados con ella, la forma en que unos elementos de red tienen un impacto en otros componentes tecnológicos, como servidores y aplicaciones. Se va a utilizar como marco de referencia el modelo de OSI, para poder seguir un método en la discusión, empezando por analizar los problemas del nivel físico de OSI y subiendo en el modelo de capas hasta llegar al nivel de aplicaciones. En muchas organizaciones no hay aún ningún tipo de subsistema especial de almacenamiento de alta disponibilidad en red. Para estas organizaciones habrá que tener en cuenta las características básicas, y clásicas, para obtener una mejor disponibilidad. Entre ellas, se pueden citar las siguientes: • Unidades de disco redundantes. • Sistemas operativos tolerantes a fallos. • Copias de seguridad de los datos. • Plan de recuperación ante posibles desastres. Se hará también un análisis especial de las necesidades de disponibilidad para las redes de almacenamiento de datos o SAN (Storage Area Networks). También, para finalizar, se analizarán las necesidades de alta disponibilidad para los dispositivos específicos de seguridad. Según se va subiendo, en el análisis, por los niveles OSI se puede ver que hay dependencias y posibles mejoras, proporcionadas por la relación entre cada una de los niveles. 2. DISEÑO DE SOLUCIONES DE ALTA DISPONIBILIDAD Hace ya unos años que vivimos en un mundo en el que la red (o las redes) de una organización son una necesidad, no una especie de lujo. Hoy en día, si las redes de una organización no funcionan, se pone en una situación crítica a la propia organización. Las redes, y la tecnología en general, se han convertido en factores críticos de éxito para la organización que se quiera analizar. En muchos casos la red es una diferencia competitiva, que se puede utilizar para obtener una gran ventaja sobre la competencia, consiguiendo reducir todos los ciclos del negocio, incrementar la eficacia e, incluso, atraer y retener a muchos posibles empleados y clientes.

371


Las organizaciones de sistemas y redes de muchas organizaciones se ven envueltas en un ciclo de trabajo permanente, en el que la alta disponibilidad no es un lujo, sino una necesidad. En este ciclo, siguiendo las aproximaciones típicas de organizaciones con gran experiencia como Cisco Systems o Nortel, se pueden diferenciar 4 fases: • En la primera se identifica una tecnología nueva y necesaria y se implementa. Se puede pensar, como ejemplo, en el correo electrónico o en el comercio electrónico. • Una vez identificada la tecnología e implementada, aparece la necesidad de que llegue a todos los rincones de la organización. Puede que se necesiten otros conmutadores, más ancho de banda, otros dispositivos, etc. • La tercera fase es más compleja. Hay que aplicar servicios a esa nueva tecnología. Podría hacer falta servicios de administración, de seguridad, de aplicaciones nuevas. Podría hacer falta tener en cuenta cuestiones de políticas de rendimiento, de calidad de servicio, de contabilidad, etc. • Si se han completado ya las tres fases anteriores, hay que poner la gente que administrará la nueva situación. Para intentar que esta fase no sea muy costosa, hay que tratar de construir una infraestructura de administración robusta e intuitiva, valiéndose de marcos de trabajo y buenas prácticas como las contenidas en los libros de ITIL (Information Technology Infrastructure Library) y de estándares como el ISO/IEC 20000. Tanto en ITIL como en ISO 20000 se muestra cómo poner en marcha, y mantener, sendos procesos de gestión de la capacidad, gestión de la disponibilidad y gestión de la continuidad. Una vez se ha completado el ciclo, se identifica otra tecnología nueva y se vuelve a empezar. Si se quiere seguir siendo competitivo, el ciclo no puede parar y la red debe estar disponible permanentemente. Así pues, las soluciones que proporcionen alta disponibilidad sin hacer mucho mayor la complejidad de la red o el personal de redes, son soluciones interesantes. Cuando se piensa en que una transacción de una organización se complete, hay muchas tecnologías subyacentes que deben estar completamente operativas. Para el personal no técnico, la ejecución con éxito de tal transacción es la parte que le preocupa, es la parte del proceso de negocio. Para el personal técnico, las áreas importantes son el buen funcionamiento de los servidores, de las aplicaciones y de la conectividad de red.

372


Desde el punto de vista de la alta disponibilidad, para enlazar tales criterios aparentemente dispares, se suele introducir el concepto de Administración de Niveles de Servicio. Estos niveles, parte de los servicios de alta disponibilidad, sirven para enlazar, con un cierto punto de vista nuevo, la tecnología con el proceso de negocio. La parte más importante, en la que se concentra este capítulo, de todo este reto, es el mantenimiento de la alta disponibilidad de las redes. Para crear una red de alta disponibilidad, el administrador de red suele tener que utilizar herramientas de prácticamente todos los niveles del modelo OSI (figura 12.1), desde la redundancia del nivel físico a las aplicaciones de gestión de red.

Figura 12.1. El modelo de referencia OSI.

El objetivo concreto de las comunicaciones y redes de alta disponibilidad se puede enunciar muy simplemente: asumiendo cualquiera de los posibles escenarios de problemas, la capacidad de un usuario de acceder a los servicios que necesita para realizar su trabajo debe ser permanente. Si se piensa en la infraestructura de la red como el conjunto de los dispositivos y aplicaciones y se piensa que cualquiera de ellos, en cualquier nivel OSI, puede fallar, se define el camino que se debe analizar para identificar problemas y soluciones de cualquiera de ellos.

373


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 construcción sin el cual, además, no se puede pensar, y ser realista a la vez, en la alta disponibilidad de los niveles superiores. Uno 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 más habituales de conseguirlo es usar fuentes de alimentación duales, que comparten la carga. Si una fuente de alimentación falla, la otra seguirá proporcionando corriente al dispositivo, de manera que no haya ninguna interrupción del servicio y que los usuarios no sean afectados de manera alguna. Otra manera añadida de dar mayor seguridad es usar, asimismo, dos tomas de alimentación distintas, provenientes de empresas eléctricas o líneas distintas. Hay otras soluciones que hay que tener en cuenta, siendo la más típica el uso de sistemas de alimentación ininterrumpida (SAI). Si hay, por ejemplo, una tormenta y se corta la corriente, dejando sin uso las fuentes duales, el SAI permitirá que se mantenga la necesaria integridad del servicio, protegiendo a su vez los equipos conectados al SAI contra fluctuaciones en la tensión, al realizar estos equipos funciones de regulación de la intensidad de corriente, eliminando las sobretensiones o contrarrestando las reducciones de tensión del suministro eléctrico. Actualmente hay una gran oferta, pudiendo elegir desde modelos diminutos hasta dispositivos pensados para grandes organizaciones, habitualmente gestionados en red. Otra característica importante que hay que tener en cuenta es que ningún componente dentro de una «caja», que realiza una función concreta, debe depender de otros componentes dentro de la misma «caja». Esto se denomina inteligencia distribuida, cada elemento, de dentro de un sistema, es independiente de los otros elementos del sistema. Con este diseño, la falta de disponibilidad de uno o más elementos dentro del sistema no afecta al resto de los elementos. Cuando se plantea un escenario de alta disponibilidad en una organización media o grande, se establece un diseño diferente para lo que se denomina el núcleo de la red y los extremos (o bordes) de la red. En el diseño del núcleo, el centro de datos y los dispositivos de red se implementan me-

374


diante el uso de sistemas redundantes (figura 12.2). 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.

Figura 12.2. Acceso redundante al núcleo de la red.

Desde el punto de vista de los métodos de redundancia del hardware se pueden añadir también los siguientes: • Redundancia de dispositivos físicos, por ejemplo, dos o más encaminadores proporcionando servicios a los mismos usuarios, usando protocolos como el VRRP (Virtual Router Redundancy Protocol), analizado más adelante en este capítulo. • Agregación de enlaces, mediante protocolos como el IEEE 802.3ad. Aunque este protocolo sirve para aumentar la disponibilidad del ancho de banda entre dispositivos, también 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, que a menudo se pasa por alto, es el de la trayectoria redundante de los datos. La capacidad de proporcionar va-

375


rios caminos de datos redundantes está distribuida por todos los niveles del modelo OSI. Las consideraciones no cubren solo el entorno típico de LAN, sino el de WAN o MAN. Por ejemplo, enlaces E1 o E3 para las WAN, tecnología de fibra o inalámbrica para las MAN, etc. 4. LOS PROBLEMAS EN EL NIVEL 2 DE OSI Y SOLUCIONES El punto clave en este caso 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. Dentro de un dominio de nivel 2, el problema no es la velocidad de los broadcast, sino que haya un único camino de datos que puedan recorrer tales mensajes. Para resolver este problema el protocolo más implementado, con diferencia, que utiliza caminos «con bucle» (más que redundantes), es el STP (Spanning Tree Protocol), normalizado tanto por la antigua DEC (Digital Equipment Corporation) como por el IEEE 802.1D. Como es bien conocido, el STP permite la existencia de bucles físicos en un área de nivel 2, situación que provocaría normalmente 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) en la red. Cualquiera de los factores citados es, en realidad, un cambio en la topología. Una red STP converge basándose en una serie de temporizadores que son ajustables pero que, en todo caso, pueden resultar demasiado grandes en muchos casos. Por esta razón, el IEEE creó el estándar 802.1w, denominado con propiedad el protocolo de re-convergencia rápida, que tiene como objetivo

376


que las redes puedan reconverger, tras un cambio de topología como los citados, en aproximadamente un segundo. Permite cambiar entre estados de puerto blocking y forwarding, lo que se traduce en tiempos de recuperación mejores. Otra manera de ayudar a reducir el problema es implementando el protocolo IEEE 802.1s, conocido como el de STP múltiples. 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. 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, desarrollados para permitir que los encaminadores «conozcan» dinámicamente su entorno local y compartan esta información con sus vecinos. Para poder determinar el camino óptimo entre estaciones en una red, hay toda una serie de encaminadores que participan en este algoritmo distribuido. Los dos tipos de encaminamiento adaptativo distribuido son bien conocidos: los basados en algoritmos de vector-distancia (mediante protocolos como RIPv1 o IGRP) y los basados en algoritmos de estado de enlace (mediante protocolos como OSPF o IS-IS). Hay una pregunta, bastante ambigua, que está, no obstante, en el centro del problema de la alta disponibilidad. La pregunta es: ¿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 para el resto de los encaminadores. 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 (figura 12.3), típicamente redes de extremo, el hecho de perder el encaminador significa que quedan completamente aisladas. Para tratar de arreglar esta situación, para tratar de eliminar en estas topologías el punto único de fallo, se ha desarrollado el VRRP (Virtual

377


Figura 12.3. Red de extremo, con un único encaminador por defecto.

Router Redundancy Protocol) basado en el RFC 5798. El protocolo VRRP utiliza dos encaminadores físicos, uno en funciones de master y el otro de backup, configurados como un único encaminador virtual, con una única dirección IP «virtual» para los dos, como en el ejemplo de la figura 12.4.

Figura 12.4. Red de extremo configurada mediante VRRP.

378


En el ejemplo, los encaminadores A y B forman dos encaminadores virtuales, EV-1 y EV-2. El encaminador A es el master y el encaminador B es el backup, dentro del EV-1. En el caso del EV-2, los papeles están cambiados, siendo el encaminador B el máster y representando el encaminador A el papel de encaminador de backup. Con esta configuración ambos encaminadores están trabajando y enviando tráfico. Otro protocolo con un objetivo parecido es el HSRP (Hot Standby Router Protocol), desarrollado por Cisco Systems y descrito en detalle en el RFC 2281. En este caso el protocolo establece un encaminador por defecto de alta disponibilidad. Su funcionamiento está muy ligado al uso de los protocolos de encaminamiento OSPF o EIGRP. HSRP envía mensajes multicast de tipo hello a una dirección concreta (224.0.0.2 para la versión 1 del protocolo o 224.0.0.102 para la versión 2), usando el puerto 1985, a todos los otros encaminadores HSRP, para definir la prioridad de los encaminadores. El encaminador con la prioridad configurada más alta actuará como encaminador virtual, teniendo una dirección IP predefinida de encaminador por defecto y responderá a la petición ARP de las máquinas conectadas a la LAN, mediante la dirección MAC 0000.0c07.acXX, siendo XX el identificador de grupo en hexadecimal. Si este encaminador falla, el siguiente de prioridad más alta tomaría el lugar del primero, consiguiendo así un failover transparente del encaminador por defecto. 6. CONSIDERACIONES PARA EL RESTO DE LOS NIVELES OSI Sería muy arriesgado hacer la equivalencia entre el tiempo activo de red y el tiempo activo del servicio o, incluso, de un proceso de negocio. Puede darse perfectamente que los 3 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 de los servicios de red necesarios, no estén funcionando correctamente. Los datos que, en cualquier momento, están atravesando la red pueden sufrir efectos adversos a causa de la latencia, creando una situación en la que las aplicaciones no son capaces de dar el servicio que deben, al no recibir a tiempo información crítica para su funcionamiento. Para que estas situaciones no tengan lugar 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

379


paquete, y, dependiendo de la clasificación de los datos, obligarán a que se realice alguna acción o aplicarán determinado nivel de servicio. Todo esto quiere decir que se deben emplear dispositivos de red que sean capaces de reconocer distintos tipos de tráfico, sean capaces de asignar prioridades dependiendo del tipo de tráfico y sean capaces de tomar acciones basándose en la información de niveles superiores al nivel 3, sin dejar de tener en cuenta la de los niveles inferiores. En el contexto de la 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 —gestión de VLAN, calidad de servicio, gestión del ancho de banda, etc.— antes de enviarlo a la red. Si se entienden las cuestiones de rendimiento de las aplicaciones y su comportamiento, se puede modificar el objetivo desde el típico «la red está operativa» hasta «la red es funcional» 7. CONSIDERACIONES PARA EL ALMACENAMIENTO EN RED: SAN (STORAGE AREA NETWORKS) Una infraestructura de almacenamiento de alta disponibilidad es el punto clave para conseguir la completa disponibilidad de los datos. Para conseguirlo se tienen en cuenta una serie de componentes: • Tecnología de discos RAID (Redundant Array Inexpensive Disks). • 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. De entre todas ellas la arquitectura SAN permite la creación de configuraciones de alta disponibilidad a nivel de toda la organización, que son escalables, capaces de crecer conforme lo haga la organización. Hay tres aspectos claves identificables como críticos para diseñar una solución de alta disponibilidad para el subsistema de almacenamiento:

380


• 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 (caches) redundantes. Mediante estas memorias secundarias, cuando un servidor ejecuta una operación de escritura, los datos no van al disco sino que quedan en esta cache, una operación de mucha menos latencia. La operación se completa, más tarde, «bajando» los datos de la cache al disco. Una técnica muy típica es usar dos memorias cache en espejo, de forma que, si falla una, los datos no se pierden. • 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 a los mismos. Como es bien conocido existen distintos tipos de combinaciones (o niveles) referidos por un número. Normalmente se usa RAID 1 (copia de los mismos datos en 2 o más discos) o RAID 5 (los datos se distribuyen por un conjunto de 3 o más discos, junto con información de paridad para la recuperación de datos) ya que ambos niveles RAID proporcionan disponibilidad añadida en el caso de un fallo de disco. • Replicación de los datos. Esta técnica se utiliza para protegerse contra un fallo del subsistema de almacenamiento completo. Puede realizarse de manera síncrona, dentro de un centro de datos local, con muy poco impacto sobre el rendimiento de las aplicaciones o de manera asíncrona, a largas distancias. La replicación se suele hacer por el propio subsistema o mediante una aplicación basada en un sistema externo al subsistema de almacenamiento. En cualquiera de los dos casos el resultado final es idéntico: 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 para una solución de

381


alta disponibilidad. También en este caso se pueden 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 controladoras. 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 contenidos en el sistema de almacenamiento. • Conveniencia de tener discos preparados para el caso de que un disco físico falle, de manera automática, en «caliente». Hay sistemas RAID que los usan de manera automática en caso de fallo en uno de los discos del sistema RAID (sistemas RAID+ spare). Obviamente la red que proporciona la conectividad entre sistemas y el almacenamiento es un componente importante dentro de la solución completa de alta disponibilidad. A ella se le deben de aplicar todas las consideraciones de las secciones anteriores. 8. CONSIDERACIONES SOBRE DISPOSITIVOS DE SEGURIDAD Aunque es un asunto del que no se habla mucho, debido, entre otras cosas, a su precio elevado, la alta disponibilidad para dispositivos de seguridad de una red es significativamente importante. En muchas situaciones (figura 12.5) 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 (de Internet típicamente) pase por un cortafuegos y éste es un dispositivo físico único, en el momento en que el cortafuego deje de funcionar, la red quedará aislada del resto del mundo. Así pues es cada vez más normal plantearse topologías, como la de la figura 12.6, en las que se dispone de dos cortafuegos, para que, en el caso de fallar uno, el otro tome su lugar en el más breve lapso posible, restableciendo el control de la seguridad y, como se ha comentado antes, muchas

382


Figura 12.5. Red aislada al fallar el cortafuegos

Figura 12.6. Cortafuegos en redundancia.

veces el propio tráfico. Habitualmente ambos cortafuegos deben ser del mismo modelo, tener la misma memoria e instalada idéntica versión del sistema operativo. Además, estas situaciones son especiales de los cortafuegos denominados de stateful inspection, pues para los demás casos, casi todos de tipo filtro de paquetes, las técnicas que se aplican corresponden, más bien, al caso de redundancia de encaminadores ya analizado previamente.

383


Cada uno de los dos cortafuegos tiene un rol diferente en la configuración: se habla del cortafuego primario y del cortafuego secundario. El primario es el cortafuegos activo, que realiza las operaciones normales. El secundario es el cortafuegos de reserva y está preparado para tomar el control en el caso de que falle el primario. Al fallar el primario, el secundario pasa a convertirse en el activo y el primario se queda como reserva. Hay en la industria casi tantos modelos de alta disponibilidad para cortafuegos como fabricantes, pero, incluso así, pueden extraerse una serie de características generales, que son las que se van a analizar en esta sección. 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, propietario, llamado cable de recuperación, que suele ser de longitud corta. • El proceso basado en LAN, que usa una interfaz LAN de cada cortafuego y un conmutador 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 recuperación: • Proceso de recuperación normal. En este caso, las conexiones TCP que hubiera se pierden, debiendo las aplicaciones volver a conectarse, para restablecer las comunicaciones a través del cortafuego. Es indudable que estas soluciones proporcionan redundancia, pero no proporcionan una perdida cero de conectividad. • Proceso de recuperación completa. Al permitir este método el mantenimiento de toda la información de estado de las tablas de conexión de los cortafuegos, en este caso no se pierde ninguna conexión, no hay necesidad de reconexión, se dice que se proporciona redundancia y conectividad completa. Conforme se va imponiendo la idea de disponer de cortafuegos cada vez más seguros, este tipo de soluciones va teniendo más relevancia. No se puede pensar en perder el control de la seguridad si se toman en serio las condiciones de cualquier política de seguridad.

384


9. CONOCIMIENTOS Y COMPETENCIAS ADQUIRIDAS En este tema se han definido los conceptos básicos de alta disponibilidad para redes, analizando los posibles problemas y sus soluciones. Para ello se ha partido de la arquitectura por niveles del modelo OSI, analizando, nivel a nivel, qué problemas plantea la alta disponibilidad y qué soluciones existen actualmente. Igualmente se ha hecho un recordatorio de cómo se puede clasificar, en base a políticas de gestión, el tráfico de una red, para dar la prioridad necesaria a cada tipo de tráfico, utilizando el concepto de red funcional, que hace que no solo la red sino los servicios necesarios para el correcto funcionamiento de la organización estén permanentemente disponibles. Asimismo se han analizado los problemas y soluciones asociadas a los subsistemas de almacenamiento altamente disponible, SAN y RAID, resaltando la necesidad actual de su completa disponibilidad para muchas organizaciones. Finalmente se han analizado las topologías típicas para obtener alta disponibilidad también para los cortafuegos, como punto clave del control de la política de seguridad de una organización.

10. BIBLIOGRAFÍA LIOTINE, M. (2003): Mission critical network planning. Ed. Artech House. WILAMOWSKY, B.; IRWIN J. D. (eds.) (2011): Industrial Communications Systems. Ed. CRC Press.

11. PALABRAS CLAVE Alta disponibilidad, tolerancia a fallos, fiabilidad, resiliencia, STP, RAID, SAN, VRRP, HSRP.

385


12. EJERCICIOS RESUELTOS 1. ¿Para qué se utilizan las memorias secundarias o caches? a) Dentro de los encaminadores, para acelerar el cálculo de una nueva ruta. b) Dentro de un cortafuegos, para implementar la redundancia del servicio de seguridad. c) Dentro de un servidor para salvaguardar los datos de disco. d) Dentro de un servidor para acelerar las operaciones de escritura a disco. Solución: d. 2. ¿Qué problema trata de resolver el STP (Spanning Tree Protocol)? a) El problema de la perdida de rutas de un encaminador, al dejar de funcionar uno de sus encaminadores vecinos. b) El problema de la gestión del tráfico organizada por prioridades. c) El problema de la propagación incontrolada de mensajes broadcast en dominios de nivel 2. d) El problema de la propagación incontrolada de mensajes RIP. Solución: c. 3. ¿Qué problema trata de resolver el VRRP (Virtual Router Redundancy Protocol? a) La pérdida de información de un encaminador en una red compleja. b) La pérdida de conectividad de una red de extremo al dejar de funcionar su encaminador por defecto. c) La gran cantidad de tráfico broadcast de actualizaciones RIP o IGRP. d) El problema de la gestión del tráfico organizada por prioridades. Solución: b. 4. ¿Qué debe incluir un sistema redundante de cortafuegos? a) Al menos, dos dispositivos cortafuegos del mismo modelo, memoria y versión del sistema operativo. b) Al menos dos dispositivos cortafuegos, no importa la versión del sistema operativo, pero debe contar con caches redundantes.

386


c) Fuentes duales de alimentación y sistemas RAID. d) Dos cortafuegos y cables duales de alimentación. Solución: a. 5. Cite dos posibles soluciones a los problemas de lentitud inherentes al STP a) b) c) d)

El protocolo OSPF y los discos RAID. Los protocolos IEEE 802.1d y 802.11b. Los protocolos IEEE 802.1s y 802.1w. En este momento no hay aún una buena solución.

Solución: c.

13. EJERCICIOS DE AUTOEVALUACIÓN 1. Para un tiempo de caída permitido de 5 minutos al año, ¿cuánta debe ser la disponibilidad del sistema? a) b) c) d)

99,99%. 99,9%. 99,999%. 99,9999%.

2. ¿Qué protocolo aumenta la disponibilidad del ancho de banda entre dispositivos y añade además redundancia? a) b) c) d)

IEEE 802.3s. IEEE 802.3ad. OSPF para casos de fibra óptica. IEEE 802.1az.

3. ¿Qué protocolos permiten redundancia de encaminadores para redes de extremo? a) b) c) d)

VRRP. IEEE 802.3w. HSRP. Sólo a) y c).

387


4. En una red compleja, ¿qué sucede cuando falla un encaminador? a) b) c) d)

Que se corrompe la información de encaminamiento en la red. Dependerá de su ubicación en la red. Que se pierden paquetes en toda la red. Dependerá de la gestión remota del mismo.

5. ¿Cuál de los siguientes estándares permite poner en marcha procesos de gestión de la capacidad, gestión de la disponibilidad y gestión de la continuidad? a) b) c) d)

388

ISO/IEC 20000. CSIS-DOC. COBIT. ISO/IEC 27001.

Tema 13

Introducción a la criptografía como herramienta de seguridad en redes

1. Introducción, orientaciones para el estudio y objetivos 2. Elementos básicos de cualquier sistema criptográfico 3. Distintos niveles criptográficos en el software de redes y sistemas 4. Tipos de ataques a sistemas criptográficos 5. Conocimientos y competencias adquiridas 6. Bibliografía 7. Palabras clave 8. Ejercicios resueltos 9. Ejercicios de autoevaluación

1. INTRODUCCIÓN, ORIENTACIONES PARA EL ESTUDIO Y OBJETIVOS El término criptografía es un derivado de la palabra griega kryptos, que significa «escondido». El objetivo de la criptografía no es, sin embargo, ocultar la existencia de un mensaje (para esto se dispone de la estenografía o ciencia de ocultación de mensajes) sino ocultar el significado del mensaje, lo que se realiza mediante el cifrado o encriptación (dos términos prácticamente análogos hoy en día) del mensaje. Tradicionalmente, se han dividido 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, generando un anagrama. • La sustitución, en la que se sustituyen unas por otras. Históricamente, la criptografía se ha usado para guardar secretos. El primer uso documentado de la criptografía es de alrededor del año 1900 antes de Cristo. Se trata de un escriba, que usaba jeroglíficos no estándar en una inscripción. Pueden rastrearse otros ejemplos no menos interesantes: • Una fórmula cifrada, de la antigua Mesopotamia, para hacer cerámica vidriada, de alrededor del 1500 antes de Cristo. • La cifra ATBASH, hebrea, de alrededor del 500 antes de Cristo. • El primer instrumento criptográfico, el escitalo de Esparta, del siglo V antes de Cristo. • La cifra de sustitución simple de Julio Cesar, de alrededor del 50 antes de Cristo. • El número 45 de los escritos del Kamasutra, que habla del «arte de la escritura secreta», del siglo IV, pero basado en manuscritos del siglo IV antes de Cristo.

391


El uso de la criptografía ha sido desde entonces constante hasta hoy en día. Se puede decir lo mismo del criptoanálisis, técnica que consiste en descubrir los mensajes cifrados. Se puede afirmar que, en términos de seguridad, siempre ha habido una batalla permanente entre criptógrafos, que inventan nuevas cifras (o nuevos métodos) para ocultar significados de mensajes y criptoanalistas, que tratan de obtener el significado de los mensajes secretos. El estudio de cuáles han sido, y son, los ataques típicos a los mensajes criptografiados ilustra la fuerza permanente, durante toda nuestra historia, que ha tenido, y tiene, esta disciplina. 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. Esto servirá como introducción a los temas siguientes, en los que se analizarán con mayor detalle el gran conjunto de herramientas criptográficas de las que se dispone hoy en día. Se empezará por describir los elementos básicos de cualquier sistema criptográfico, poniendo énfasis en los conceptos fundamentales involucrados. Después el tema describe las distintas soluciones e implementaciones de la criptografía utilizadas para conseguir una mayor seguridad. Esto se hace atendiendo a criterios de forma de implementación (hardware, software o combinación de ambos) y a criterios de ubicación en la arquitectura de comunicaciones, en cuanto a en qué niveles dentro de la arquitectura se pueden encontrar las distintas soluciones criptográficas. Se ilustra con ejemplos que se desarrollarán más adelante, en los siguientes temas. Finalmente se presentan los distintos tipos de ataques que pueden sufrir los sistemas criptográficos. Esto es importante para poder entender mejor los condicionantes de administración de los sistemas criptográficos que se analizarán en los siguientes temas. La política de seguridad debe tener muy en cuenta tales condiciones a la hora de implantar uno u otro sistema criptográfico, pues, en este caso, puede ser especialmente peligroso pensar que se dispone de una solución casi perfecta cuando, en realidad, por razones de mala administración de las necesidades propias de seguridad de la criptografía, se puede tener un verdadero «coladero» de tráfico no deseado y de ataques a la seguridad de los sistemas y de las redes.

392

INTRODUCCIÓN A LA CRIPTOGRAFÍA COMO HERRAMIENTA DE SEGURIDAD EN REDES

En estas fechas, a principios del siglo XXI, no se puede pensar en ser un buen profesional de la seguridad sin entender cómo funcionan los sistemas criptográficos. Para entender suficientemente bien cómo conseguir una buena seguridad en redes, hay que entender la criptografía. No es necesario entender las matemáticas complejas que lleva implícitas, pero si sus consecuencias. Se debe saber qué permite hacer la criptografía y, lo que es aún más importante, lo que no se puede hacer con la criptografía. Una cosa es ser un matemático especializado en criptografía y otra un ingeniero informático que sabe cómo hacer uso de ella y aplicarla en diferentes entornos de seguridad. Hoy en día, para trabajar con el nivel de seguridad que permite la criptografía, hay que usar protocolos como SSL (Secure Socket Layer), que asegura las conexiones web, IPSec, conjunto de protocolos estándar de Internet, que aseguran el tráfico IP por Internet, responsables, entre otras cosas, de buena parte de la implementaciones de Redes Privadas Virtuales, o como los protocolos WEP (Wired Equivalent Privacy) o WPA (Wi-fi Protected Access), de uso continuo en redes inalámbricas. Hay que conocer asimismo otros protocolos de seguridad como ssh (secure shell), que se utilizan cada vez más para conseguir accesos remotos seguros (autenticados y privados) a varios dispositivos de comunicaciones, que varían desde un simple equipo servidor hasta un cortafuegos, como el Cisco ASA descrito en el tema 9. Tales protocolos están construidos usando algoritmos criptográficos. Estos algoritmos son construcciones matemáticas, más o menos complejas, que transforman, de distintas maneras, los mensajes (o textos) que se desea asegurar. Cumplen una serie de características que se van a desarrollar en los próximos temas. La aproximación que se va a utilizar, para obtener una panorámica amplia de la criptografía aplicada, es «de abajo arriba», desde la parte más puramente matemática a la más informática, en el siguiente sentido: • Análisis de los distintos tipos de algoritmos criptográficos, con ejemplos de algoritmos concretos, de uso cotidiano. • Análisis de los procedimientos criptográficos más destacados para la obtención de autenticación e integridad para grandes redes, incluyendo certificados digitales y firmas digitales.

393


• Análisis de los protocolos criptográficos construidos sobre los métodos y algoritmos citados previamente, tal es el caso de SSL, IPSec, WPA, etc. • Análisis de las estructuras de clave pública más sofisticadas, conocidas como PKI (Public Key Infrastructure) • Análisis de las estructuras, funcionamiento y problemas de administración de las redes privadas virtuales, en las que se utilizan, en la práctica, todos los algoritmos y métodos criptográficos y muchos de los protocolos criptográficos. También se analizarán los problemas de mantenimiento y gestión de estas soluciones.

Figura 13.1. Las fases del proceso de seguridad.

Finalmente es importante resaltar que, dentro del proceso de seguridad, aplicado mediante la política de seguridad (figura 13.1), la criptografía se aplica principalmente en la primera fase, o fase de implementación, cuando se configuran muchos de los dispositivos de seguridad que se han ido analizando y describiendo en los temas anteriores. No obstante, no sería completo el análisis sin recordar que, al menos para la fase de monito-

394


rización, buena parte del tráfico de control (por ejemplo desde un agente de monitorización a su centro director y viceversa) va cifrado mediante algunas de las técnicas que se van a analizar en próximos temas. 2. ELEMENTOS BÁSICOS DE CUALQUIER SISTEMA CRIPTOGRÁFICO Se enumeran, a continuación, los elementos básicos de cualquier sistema criptográfico actual, que se analizarán posteriormente: • 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, conocido sólo por un reducido grupo de personas, es decir secreto, no público, que permitía intercambiar información en un lenguaje secreto, como en el caso citado anteriormente del escriba egipcio. La solución es simple, pero tuvo, desde el principio, un problema grave: la «traición». En el momento en que uno de los participantes abandona el grupo, corre peligro todo el sistema por su culpa, al estar la seguridad basada únicamente en el algoritmo, que se mantenía en secreto mientras nadie lo hiciera público. Si el que abandona el grupo lo hace público, se hunde todo el edificio de seguridad. El siguiente paso de mejora fue drástico y hoy sigue empleándose. Se refina el sistema, mediante dos características clave: 1. Cualquier algoritmo que se utilice debe ser público. Esto garantiza que es realmente seguro. No se empieza a utilizar mientras no quede suficientemente claro que es seguro y difícil de atacar. Cuando se empiece a usar será atacado aún más pero no sólo, ni especialmente, por hackers, sino por científicos y expertos en criptografía. En

395


esto consiste el control de calidad de los algoritmos criptográficos. De los algoritmos que sobreviven, como en el caso de los principales analizados en los temas siguientes, se puede decir que son suficientemente seguros. 2. Todos los algoritmos dependen de (al menos) una clave, que hay que administrar para que sea segura. Esto significa que la propia clave, en sí, debe ser segura y que habrá que cambiarla con cierta periodicidad. Estas dos nuevas características acaban con el problema del «secreto» pero hacen aparecer uno nuevo. ¿Cómo se ha arreglado el problema del secreto? Al ser el algoritmo público, no tiene ninguna importancia que sea más o menos conocido por unos o por otros, al estar al alcance de todo el mundo. ¿Qué nuevo problema aparece? El de la gestión y distribución de claves. Podría suceder que la misma persona de antes (el «traidor») abandone el «grupo» y de a conocer la clave. 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. Como bien establecía en 1883, Auguste Kerckhoffs, el padre de la criptografía moderna, no hay seguridad en el algoritmo, toda la seguridad está en la clave. Actualmente, si se aborda el proceso criptográfico de la manera más general posible, se puede afirmar, siguiendo el esquema de la figura 13.2, que si a un texto legible se le aplica un algoritmo de cifrado, que, en general, depende de una clave, como una función matemática f(x), esto arroja como resultado un texto cifrado que es el que se envía o se guarda.

Figura 13.2. Proceso general de cifrado y descifrado de mensajes.

396


Este proceso recibe el nombre de cifrado o encriptación. Si a ese texto cifrado se le aplica el mismo algoritmo, dependiente de la misma clave o de otra clave, aspecto éste que depende del algoritmo, se obtiene el texto legible original. Este segundo proceso recibe el nombre de descifrado o desencriptación. Las claves han resultado una manera adecuada de salvaguardar los algoritmos criptográficos, reconocidos como potentes, haciendo que muchos grupos distintos puedan usar los mismos algoritmos, pero con diferentes claves, con el mismo nivel de seguridad. De hecho, hoy en día, una gran parte de la seguridad de los procesos criptográficos reside en la elección y gestión de tales claves. Como bien afirma Bruce Schneier en su libro Applied Criptography (véase la bibliografía): La seguridad de un algoritmo criptográfico descansa en su 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 este problema es utilizar generadores de números «más o menos» al azar. La forma en que estos generadores mejoran la seguridad de las claves se puede ver ilustrada en la figura 13.3. En los procedimientos en los que se generan muchas claves, tal generación suele ser un proceso en dos partes. Usando un número elegido lo más al azar posible (por ejemplo, deducido del «ruido» del decaimiento de un elemento radiactivo) 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.

Figura 13.3. Procedimiento de generación de claves criptográficas.

397


Aunque van a ser analizados en detalle en el tema siguiente, se puede ya presentar las 3 clases de algoritmos criptográficos utilizados hoy en día: • Funciones de una sola vía (o funciones hash). Estas funciones permiten mantener la integridad de los datos, tanto en almacenamiento como en cuanto al tráfico de las redes. También se utilizan como parte de los mecanismos de lo que se denomina firma digital, una de las técnicas de autenticación más utilizadas. • Algoritmos de clave secreta o de criptografía simétrica. Son, quizás, los más populares, en el sentido de que la gente los ve como «los únicos procedimientos criptográficos». La razón es sencilla: son los que permiten mantener la privacidad, o confidencialidad, de los mensajes o textos almacenados una vez cifrados por alguno de estos métodos. Se utilizan ampliamente para las redes privadas virtuales y, en general, en todo el comercio electrónico. • Algoritmos de clave pública o de criptografía asimétrica. Son los más novedosos, históricamente hablando. Tienen múltiples usos (permiten obtener también privacidad), aunque se emplean principalmente para la autenticación de documentos, textos o mensajes, mediante certificados digitales y las citadas firmas digitales. Existe un problema general de seguridad que afecta a cualquiera de los procesos criptográficos ya citados, que es el del tamaño del mensaje, la cantidad de datos a cifrar. Si las transmisiones de datos que se van a realizar son de mucho volumen, esto requerirá una capacidad distinta en el dispositivo (hardware o software) de cifrado a si el tráfico cifrado es únicamente de transmisiones cortas. Ésta es una de las razones por las que hay distintos métodos criptográficos y modos de operación, cada uno adecuado a las distintas necesidades. También hay que tener en cuenta que cuanto mayor sea la longitud de la clave, mayor será la seguridad del texto cifrado, pero mayor será, también, la necesidad de recursos (de cálculo matemático y de memoria de almacenamiento) para poder tener suficiente seguridad en el proceso. Sólo a modo de ejemplo pueden verse (tabla 13.1) las recomendaciones de algunos libros de criptografía sobre la longitud de la clave, dependiendo de la cantidad de tiempo que se considere necesario mantener el secreto de los datos.

398


Tabla 13.1. Algunas recomendaciones para la longitud de claves Naturaleza de los datos

Tiempo a mantener en secreto

Longitud recomendada de la clave

Información militar

Minutos o horas

128 bits

Secretos de marca

Años

128 - 256 bits

Armas nucleares

Más de 40 años

256 - 512 bits

Espionaje nacional

Más de 50 años

512 - 1024 bits

La longitud de la clave de un algoritmo, la seguridad del texto cifrado resultante y el tiempo de proceso necesario para generarlo varían, dependiendo de una serie de aspectos asociados con la naturaleza de los datos que se vayan a transmitir. Aunque las preguntas pueden ser más y las respuestas pueden variar, 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 para muchos mensajes, está más expuesta a un ataque, luego debería de 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 de 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, al ir a estar expuesto más tiempo a un posible criptoanálisis. Se puede, pues, afirmar, con todo lo expuesto hasta ahora, 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.

399


También se puede afirmar que 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. 3. DISTINTOS NIVELES CRIPTOGRÁFICOS EN EL SOFTWARE DE REDES Y SISTEMAS En esta sección se van a analizar otros aspectos importantes del uso de la criptografía para la seguridad de las comunicaciones, como son el método informático utilizado para su implementación y los niveles de aplicación dentro de una arquitectura de comunicaciones como la de TCP/IP. 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, de forma que las funciones de cifrado y descifrado se consiguen por la ejecución de tal programa. Esto permite actualizaciones y modificaciones sencillas, pero, dependiendo del procesador y de las funciones concretas, puede hacer lenta la ejecución. • Mecanismos hardware: En este caso, 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. Independientemente de la forma concreta en que resultan procesados los datos, el proceso criptográfico de las comunicaciones de datos tiene lugar siempre en una de las tres siguientes localizaciones: • En una aplicación. En este caso, típicamente, 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.

400


• Por el propio medio de transporte. El proceso es llevado a cabo por el propio medio de transporte, por ejemplo, por un cableado especial. Es frecuente identificar los métodos criptográficos por el nivel de la arquitectura de comunicaciones en la que se implementan. Desde este punto de vista, tal y como se ve en la figura 13.4, se suele hablar, en el caso de protocolos IP, de 4 localizaciones típicas: • Criptografía de nivel de aplicación. En este caso, el cifrado y descifrado se hace por un programa separado del que proporciona el transporte de red o por el mismo programa. Varios ejemplos típicos son el programa PGP (Pretty Good Privacy) o los programas ssh (secure shell). • Criptografía entre procesos. En este caso, la aplicación escribe el mensaje a un proceso intermedio entre ella y el protocolo de transporte, en ingles conocido como IPC (Inter Process Communication). Este método está como «encajado» en la metodología de la aplicación. Un ejemplo típico, que será analizado en el tema 16 es el del protocolo SSL (Secure Socket Layer). • Criptografía de protocolo de transporte. En este caso, una serie de protocolos IP especializados se utilizan para transportar los mensajes,

Figura 13.4. Implementaciones criptográficas por niveles de la arquitectura.

401


tras cifrarlos y viceversa. El ejemplo más conocido, hoy en día, con diferencia, que será analizado en los temas 16 y 17, es el del conjunto de protocolos de IPSec, responsables, entre otras novedades de los últimos años, de las redes privadas virtuales, que también se analizarán en el tema 17. • Criptografía de nivel de enlace. En este caso, la implementación es vía hardware, en el cable, y el mensaje entero se cifra y se descifre. En algunos mecanismos de esta modalidad, como las máquinas rotor o los KG-84 militares, usados por los módems, se basaron versiones primitivas de algoritmos como el DES, analizado en el tema siguiente. Dependiendo del nivel en que tiene lugar el proceso criptográfico dentro de la arquitectura de protocolos, la parte del mensaje afectado será mayor o menor, tal y como puede apreciarse en la figura 13.5. Por ejemplo, si el cifrado se hace en el nivel de aplicación, el cifrado afecta a la cabecera del protocolo de la aplicación únicamente. Sin embargo, en el caso de IPSec, la parte afectada puede llegar a incluir todo el contenido IP del mensaje.

Figura 13.5. Mensajes cifrados en distintos niveles.

402


La selección del método criptográfico dependerá, una vez más, 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 muchas veces económicas. 4. TIPOS DE ATAQUES A SISTEMAS CRIPTOGRÁFICOS Finalmente, se va a hacer una breve descripción de los métodos de ataque típicos a los sistemas criptográficos. Como siempre, no son más que traslaciones de los métodos de ataque criptoanalíticos de la historia de los códigos secretos, pero aplicados al mundo de la informática y comunicaciones de ordenadores. Hay un criterio fundamental para clasificarlos, que es la cantidad disponible de información de la que dispone el atacante. Conforme a este criterio, 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 y dispone de una pequeña cantidad de texto cifrado, el ataque es muy difícil de realizar con éxito. • Ataques con texto legible conocido. Si el atacante tiene parejas de texto legible y su correspondiente texto cifrado, y además conoce el algoritmo, el ataque, no siendo sencillo, empieza a ser accesible, debido a la posibilidad de probar con un número grande de claves, hasta obtener el resultado del texto cifrado. Se puede evaluar, además, paso a paso, la bondad de las claves elegidas, haciendo una comparación con el texto cifrado. No obstante, si se obtiene la clave una vez pasado mucho tiempo y el sistema criptográfico está bien administrado, ésta servirá de poco, pues, seguramente, habrá sido ya cambiada. • Ataques eligiendo el texto legible. En este tipo, se tiene acceso a un dispositivo criptográfico, del que se desconoce el algoritmo usado, 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, por ejemplo, por los aliados, en la se-

403


gunda guerra mundial, para obtener las cifras usadas por la marina y el ejército alemán, una vez obtenidas varias de las máquinas usadas por los alemanes, máquinas Enigma, para cifrar sus mensajes secretos. • Métodos «poco ortodoxos». Cuando el atacante amenaza, extorsiona o chantajea a un individuo, que está en poder de la clave. En realidad, éste es un tipo de ingeniería social y es, frecuentemente, la forma más sencilla de romper un sistema criptográfico. Una variante de este proceso es «torturar» a un dispositivo hardware de cifrado, hasta obtener suficiente información como para obtener la clave, como en el caso de las tarjetas «inteligentes» y sus dispositivos de lectura. Realmente, un buen sistema criptográfico es bastante inmune, se podría decir que matemáticamente inmune, a casi cualquier tipo de ataque. El problema reside, como siempre, en el eslabón más débil en la cadena de seguridad, que sigue siendo el ser humano y, más concretamente, la administración del sistema de seguridad que se hace, en general, en las redes donde se aplican estos sistemas.

404


5. CONOCIMIENTOS Y COMPETENCIAS ADQUIRIDAS En este tema se ha tratado de aclarar toda una serie de términos que, aunque aplicados al asunto que es objetivo del libro, se aplican con frecuencia cuando se trata de hablar de códigos y lenguajes secretos. Así, se ha explicado el significado de la palabra criptografía y el de la palabra criptoanálisis, para después pasar a asociarlos, de una manera aplicada, no en su profundidad matemática, sino en cuanto a sus usos para la seguridad de las redes y los sistemas que las componen. Se han definido toda una serie de términos ligados con la criptografía, de uso habitual en ella como cifrado (o encriptación) y descifrado (o desencriptación), así como las diferencias existentes entre algoritmos dependientes o no de claves, la importancia actual de estos últimos, la necesidad de generación de claves secretas suficientemente bien elegidas y la importancia de una correcta administración de tales claves (asunto al que se volverá en los temas siguientes). Se han descritos los tres principales tipos de algoritmos criptográficos (criptografía simétrica, criptografía asimétrica y funciones de una vía), explicando sucintamente sus usos habituales, algo que será objeto de un estudio más detallado en el tema siguiente. Se han descrito, también, las tres maneras principales de implementación informática de cualquiera de estos algoritmos, que son mediante hardware, mediante software o mediante una combinación de ambos métodos. Asimismo, se han analizado los distintos tipos de mensajes IP criptográficos que se pueden encontrar, con una mayor o menor parte del mensaje hecho ilegible, dependiendo del nivel de la arquitectura IP donde se implementa la función criptográfica, que puede ser en el nivel de aplicación, en el de transporte, en el de enlace de datos o mediante un método entre procesos de distintos niveles, conocido por sus siglas en ingles, IPC. Se ha hecho, también, una sucinta descripción de los posibles métodos de ataques criptoanalíticos, que dependen, esencialmente, de la cantidad de información disponible por el atacante. Se han planteado, pues, los cimientos sobre los que se construyen todos los sistemas criptográficos de uso habitual. Los siguientes temas ex-

405


ploran y analizan la construcción de estos sistemas, en una aproximación «de abajo a arriba»: • Se busca con la criptografía conseguir una o varias de las características típicas de los mensajes seguros, que son autenticación, integridad y privacidad. • Para ello, se usan distintos métodos criptográficos, como los analizados en los temas 14 y 15, que son como las piezas básicas de la «caja de herramientas» del criptógrafo. • Estos algoritmos criptográficos permiten construir protocolos criptográficos, piezas ya más elaboradas, como los analizados en los temas 15 y 16, con las que construir sistemas criptográficos. • Tales sistemas criptográficos pasan a formar (por ellos solos o en conjunción con otros componentes de seguridad) piezas clave en las estructuras de implantación de cualquier política de seguridad, como las PKI, analizadas en el tema 16 o las redes privadas virtuales, analizadas en el tema 17. • Finalmente, en el tema 18, se describen los problemas de seguridad asociados al uso de redes inalámbricas y los protocolos criptográficos más habituales en tales redes.

6. BIBLIOGRAFÍA INTYPEDIA, INFORMATION SECURITY ENCYCLOPEDIA, enciclopedia gratuita en video, con muchas lecciones sobre algoritmos criptográficos, con la garantía de la red CRIPTORED y la Universidad Politécnica de Madrid, descargable desde http://www.intypedia.com/ PASTOR J.; SARASA M. A.; SALAZAR J. L. (2010): Criptografía digital. Fundamentos y aplicaciones. Ed. Prensas de la Universidad de Zaragoza. SCHNEIER, B. (1996): Applied Cryptography. 2.ª edición. Ed. Wiley. SINGH, S. (1999): The Code Book: The Science of Secrecy from Ancient Egypt to Quantum Cryptography. Ed. Doubleday. Existe una versión «ligera» descargable gratuitamente, y en formato interactivo con ejercicios, desde http://simonsingh.net/cryptography/crypto-cd-rom/

406


7. PALABRAS CLAVE Cifrado, descifrado, clave, criptografía, criptoanálisis.

8. EJERCICIOS RESUELTOS 1. ¿Cuál de los siguientes algoritmos criptográficos debe verse como más seguro? a) Un algoritmo secreto, sólo conocido por el fabricante, que no depende de ninguna clave. b) Un algoritmo semi-secreto, conocido sólo por el grupo que debe usarlo, no dependiente de ninguna clave. c) Un algoritmo secreto, sólo conocido por el fabricante, dependiente de 3 claves. d) Un algoritmo completamente público, dependiente de una sola clave secreta. Solución: d. 2. ¿Qué tipo de algoritmos criptográficos permiten conseguir la privacidad de los mensajes cifrados? a) b) c) d)

Las funciones de una sola vía. Los algoritmos de criptografía simétrica. Los algoritmos de clave secreta. Sólo mediante una combinación de los dos últimos.

Solución: b. 3. La longitud de las claves utilizadas en algoritmos criptográficos debe ser independiente del texto a cifrar con ellas: a) Verdadero, esto hace a los algoritmos más portables. b) Falso, sólo es cierto para algoritmos de criptografía simétrica. c) Falso, depende de la longitud del mensaje a cifrar, así como de la importancia del mismo. d) Verdadero, por eso es tan sencillo crear programas que los usen. Solución: c.

407


4. ¿En qué niveles de la familia de protocolos de IP se pueden implantar los procesos criptográficos?: a) De manera completa, solo en el nivel de IP. b) En el nivel de transporte y en el nivel de aplicación. c) En el nivel de aplicación, en el de transporte, en el de enlace de datos y entre procesos, entre el de aplicación y el de transporte. d) Sólo entre los niveles de aplicación y transporte. Solución: c. 5. ¿Cuál es la implementación informática que permite más fácilmente hacer las modificaciones pertinentes a un proceso criptográfico? a) La consistente en procesos software. b) La consistente en lógica especial diseñada para un chip. c) La consistente en aplicaciones descargables por la red hasta un dispositivo hardware. d) Esta operación, por su propia naturaleza matemática, no puede realizarse. Solución: a.

9. EJERCICIOS DE AUTOEVALUACIÓN 1. ¿Cuál de los siguientes NO es el nombre de un protocolo criptográfico? a) b) c) d)

Secure Socket Layer, SSL. IPSec. DES, Data Encryption Standard. Pretty Good Privacy, PGP.

2. ¿En qué fase del proceso de seguridad se aplica principalmente la criptografía? a) b) c) d)

408

En la fase de monitorización. En todas las fases. En la fase de recreación En la fase de implementación.


3. ¿Cuál de los siguientes elementos básicos de un sistema criptográfico debe ser siempre público, si queremos un sistema seguro? a) b) c) d)

Las claves. El algoritmo criptográfico. Los valores al azar. El texto cifrado.

4. ¿Cuál de los siguientes tipos de algoritmos criptográficos no es parte de la firma digital? a) b) c) d)

Algoritmos de clave privada. Algoritmos de clave pública. Funciones de una sola vía. Algoritmos de criptografía asimétrica.

5. ¿Cuál de las siguientes debe ser una característica general de cualquier clave para cualquier algoritmo criptográfico? a) b) c) d)

Debe tener una longitud de al menos 128 bits. Debe tener una longitud acorde con la naturaleza de los datos. Deben ser siempre pactadas. En algunos algoritmos muy usados no hay claves.

409

Tema 14

Métodos criptográficos: sistemas de clave privada, sistemas de clave pública y funciones de una sola vía

1. Introducción, orientaciones para el estudio y objetivos 2. Algoritmos de clave privada o de criptografía simétrica 3. Funciones de una sola vía 4. Algoritmos de clave pública o de criptografía asimétrica 5. Conocimientos y competencias adquiridas 6. Bibliografía 7. Palabras clave 8. Ejercicios resueltos 9. Ejercicios de autoevaluación

1. INTRODUCCIÓN, ORIENTACIONES PARA EL ESTUDIO Y OBJETIVOS El mundo de la criptografía y de los códigos secretos tiene una apariencia muy científica y de alta tecnología. Esto no siempre es así y, para ilustrarlo, se puede rastrear la existencia de algoritmos de cifrado sin clave, sin una estructura matemática, y que, a pesar de ello, han tenido un éxito abrumador y una importancia capital para la historia reciente del mundo. Durante la segunda guerra mundial, los ejércitos norteamericanos del océano Pacífico usaron un algoritmo criptográfico infalible, ¡y sin clave! Tal algoritmo era la lengua de los indios navajos. Los navajos fueron la única tribu de EE.UU. cuya lengua no fue estudiada por estudiantes alemanes en los 20 años anteriores al inicio de la guerra. Éste no fue el caso de hasta otras 33 lenguas y dialectos de otras tribus indias norteamericanas, objeto de estudio filológico y antropológico por parte de decenas de estudiantes alemanes. El dialecto tribal navajo era completamente ininteligible para las demás tribus y, prácticamente, para casi todo el mundo. La imposibilidad de descifrado del navajo proviene de que tal lengua no tiene ninguna conexión con ninguna lengua asiática o europea. Algo menos de 4 meses después de Pearl Harbour ya había 29 navajos, algunos muy jóvenes, haciendo un curso de comunicaciones de ocho semanas de duración con la infantería de marina. Hubo que solucionar un problema típico de las lenguas antiguas, el de la falta de léxico navajo para sustituir palabras inglesas relacionadas con barcos y aviones y para toda la terminología militar. Finalmente se dispuso de un léxico de alrededor de 300 palabras, a las que hubo que añadir un

413


método especial para palabras que no estaban en el léxico. Tales palabras se deletreaban. Así, por ejemplo, Pacific se deletreaba como: pig, ant, cat, ice, fox, ice, cat lo que se traducía al navajo como: bi-sodih, wol-la-chee, moasi, tkin, ma-e, tkin, moasi Tras una serie de pruebas con mensajes reales cifrados de esta manera y entregados a los criptoanalistas de la marina, quedó claro que no había forma de descifrarlos. Finalmente, los mensajeros de código demostraron su valía en el campo de batalla. Salvaron muchas vidas y ayudaron a conseguir muchas victorias, desconcertando a los enemigos japoneses. Un mensaje navajo no podía ser falsificado, siempre se podía confiar en él. En total hubo 420 mensajeros de código navajo y, aunque resultaron fundamentales para el éxito de la guerra, su papel de aseguradores de las comunicaciones se convirtió en información clasificada hasta 1968 y hubo que esperar hasta 1982 para que se les rindiera un homenaje, declarando, además, el 14 de agosto «día nacional de los mensajeros de código navajo». Realmente su mayor triunfo es haber quedado como uno de las pocas cifras (de los pocos algoritmos de cifrado) de toda la Historia en no haber sido descifrada nunca. Como ya se ha explicado en el tema 13, los algoritmos (o métodos) criptográficos son las piezas básicas con los que se construyen primero los protocolos y, después, los sistemas criptográficos completos. Es ésta la razón de que haya que dedicar un tema para hablar de sus tipos y de ejemplos concretos. Es muy importante señalar que este libro no pretende dar una explicación matemática completa de cada uno de ellos, sino describirlos, definirlos, ver sus ventajas y sus inconvenientes y hacer una relación de los protocolos y sistemas típicos donde se utilizan. Si el lector desea una explicación mucho más completa, debe seguir uno de los clásicos de referencia en el mundo de la criptografía, como es el libro de la bibliografía complementaria de esta unidad, de Bruce Schneier, «AppliedCryptography». El tema comienza presentando los algoritmos de criptografía simétrica, llamada también de clave secreta o de clave privada. Es la más antigua,

414

MÉTODOS CRIPTOGRÁFICOS: SISTEMAS DE CLAVE PRIVADA, SISTEMAS DE CLAVE PÚBLICA Y FUNCIONES DE UNA SOLA VÍA

la más extendida y la que más popularidad ha conseguido. Muchas veces, se piensa en ella, simplemente, como el único método criptográfico. Se describen sus ventajas y sus puntos débiles, lo que permitirá entender mejor los sistemas en los que se utilizan. Su uso está, realmente, muy extendido y esa es la razón de que se vaya a tratar con cierto detalle los casos de los algoritmos DES y sus variantes, así como de AES, el más reciente estándar de esta clase de algoritmos. Se analizan después las funciones de una sola vía (o funciones hash). Son relativamente modernas, pero están completamente extendidas en informática, donde se pueden usan 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, que será analizado en el siguiente tema. Son, seguramente, la herramienta simple de cifrado más útil hoy en día. Finalmente el tema presenta los algoritmos de criptografía asimétrica o de clave pública. Claramente, desde una perspectiva histórica, han supuesto una verdadera revolución, que comenzó a finales de la década de los 70 y principios de la década de los 80. Si un criptógrafo muerto hacia 1974 pudiera resucitar seguramente no entendería este tipo de criptografía. Como se verá, la revolución consistió, esencialmente, 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. Nada es perfecto y surgen otras complicaciones, que serán analizadas también, pero es indudable que, hoy en día, para cualquier sistema criptográfico ambicioso, es imposible no utilizar este tipo de métodos. Están en el núcleo de implementación de cualquier red privada virtual, en la implementación de la firma digital, en la seguridad para el comercio electrónico que dan soluciones como el SSL o el SET. Los métodos de criptografía asimétrica están en todas partes y, si se pretende ser un buen profesional del campo de las comunicaciones de ordenadores, se debe conocer para qué sirven, cómo funcionan y, desde luego, que es lo que no permiten conseguir. Entre este tema y el siguiente (que trata de aspectos muy relacionados con éste, como la firma digital o los certificados digitales) se ponen los cimientos para afrontar, en el tema 16, el análisis de los protocolos criptográficos más importantes en la actualidad en el mundo de la seguridad.

415


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 (figura 14.1) 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, pues la misma clave cifra y descifra.

Figura 14.1. Sistema criptográfico de clave privada o secreta.

Este tipo de algoritmos han significado una parcela muy importante de la criptografía desde su invención y siguen contándose hoy entre los algoritmos más utilizados. Entre sus puntos fuertes, se pueden destacar: • Operan (cifran) más rápido que los algoritmos de clave pública, llegando a ser hasta 1000 veces más rápidos. • Han servido (y sirven aun habitualmente) como base para los sistemas criptográficos basados en hardware. Entre sus puntos débiles, se puede destacar: • Requieren un sistema de distribución de la clave muy seguro. Piénsese que si se conoce la clave se puede conocer todos los mensajes cifrados con ella. • En el momento en que la clave cae en manos no autorizadas, todo el sistema deja de funcionar. Asimismo, esto obliga a llevar una admi-

416


nistración compleja, en cuanto a creación de nuevas claves y redistribución. • 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. Una red de n usuarios necesita n(n-1)/2 claves diferentes. Por ejemplo, una red de 11 usuarios necesita 55 claves diferentes y una red de 100 necesitaría 4950 claves. 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, por ejemplo de 64 bits, 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. En este contexto, 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. Todo buen mecanismo de confusión tratará de hacer excesivamente complicado la obtención de relaciones estadísticas entre las tres entidades. Y, también en este contexto, 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. Para conseguir algoritmos criptográficamente fuertes se combinan la confusión (a base de sustituciones simples, con tablas pequeñas) y la difusión (a base de permutaciones). Esta combinación se conoce como cifrado de producto y la mayoría de los 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. Muchos de estos cifrados tienen en común que dividen un bloque de texto en dos mitades, sobre las que 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. Esta estructura tiene, además, una propiedad muy interesante: para invertir la

417


función de cifrado, es decir para descifrar, simplemente hay que aplicar el mismo algoritmo, con los índices intermedios en orden inverso. Además estos algoritmos no suelen tener lo que se conoce como propiedad de grupo, propiedad que no se va a analizar en este texto, pero que al no tener dicha propiedad permite cifrar un texto con una clave K1 y el resultado con otra clave K2, resultando un mensaje cifrado equivalente a haber empleado una clave de longitud doble, aumentando así la seguridad del sistema. Uno de los algoritmos de cifrado simétrico más populares y uno de los más usados aún es el DES (Data Encryption Standard). Está basado en otro algoritmo, el LUCIFER, desarrollado por IBM a principios de la década de los 70. El gobierno de los EE.UU. lo adoptó como estándar en 1976, para comunicaciones no clasificadas. Su nombre oficial según la norma ANSI es el DEA (ANSI X3.92, Data Encryption Algorithm) y según la ISO es conocido como el DEA-1. Tiene una curiosa historia, debido a que la NSA (National Security Agency o «No Such Agency», según algunos expertos de seguridad) lo diseñó en secreto, pensando en una implementación hardware, pero resultó que la NBS (National Bureau of Standards, conocida hoy como NIST, Nacional Institute of Standards and Technologies) publicó su especificación con tal detalle que cualquiera podía implementarlo en software. DES es una algoritmo de cifrado por bloques, que cifra los datos en bloques de 64 bits. Esto significa que la entrada de datos al algoritmo 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. En realidad se expresa como un número de 64 bits, pero cada octavo bit se usa para chequeo de paridad y se ignora. 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. En la actualidad hay una gran cantidad de dispositivos hardware, incluyendo placas de dispositivos como cortafuegos o encaminadores, que lo implementan de manera segura. Igualmente gran cantidad de sistemas operativos y programas de comunicaciones usan protocolos, como SSL o IPSec, que lo usan cotidianamente.

418


Se puede demostrar matemáticamente que existe un conjunto de 64 claves débiles, lo que significa que su uso hace especialmente inseguro el algoritmo. No obstante, hay que comparar tal número con el conjunto total de 2 elevado a 56 posibles claves (expresado en decimal sería ¡72.057.594.037.927.936! posibles) y reconocer que es un número realmente minúsculo de ellas. Además, al conocerse, puede prepararse el sistema para no permitir su uso. 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, cada vez más, un ataque de tipo «fuerza bruta». Se sabe, desde 1998, que un ataque «de fuerza bruta» sobre DES es viable, debido a que la clave es de escasa longitud. La «hazaña» la llevó a cabo una organización norteamericana sin ánimo de lucro, la EFF (Electronic Frontier Foundation), construyendo una máquina, el «DES-cracker», que costó menos de 40 millones de pesetas. Debido a estos problemas, cuando es necesaria una seguridad más fuerte, se usan ya otros algoritmos, como el AES que se analiza más adelante. Debido a estas debilidades, han ido apareciendo distintas variantes del algoritmo. Entre estas variantes la más utilizada con diferencia es la conocida como Triple DES (o 3DES), ilustrada en la figura 14.2. Recuérdese que DES no tiene estructura de grupo, con lo que se pueden aplicar claves sucesivas, obteniendo un resultado mucho más seguro.

Figura 14.2. Sistema TripleDES.

419


En el caso del Triple DES, se puede demostrar matemáticamente que se obtiene una longitud de clave equivalente de 112 bits. La tercera clave, K3, suele ser la primera, K1, por compatibilidad con el DES de una única clave. Otra variante muy conocida de DES es la conocida como CRYPT(3), que se encuentra en algunos sistemas UNIX, usada en realidad como una función de una sola vía. Otra más es DESX, de RSA Data Security, incluida en muchos programas de correo electrónico desde 1986 y en el EFS (Encryption File System) de los sistemas operativos de Microsoft. Otro algoritmo de clave simétrica muy importante, por cómo ilustra la creación de un estándar de cifrado y por ser cada vez más utilizado es el AES (Advanced Encryption Standard). El NIST certificó DES primero en 1987 y después en 1993, pero en 1997 no volvió a certificarlo y abrió un concurso internacional para buscar un nuevo estándar internacional de cifra, el AES. En Octubre de 2000 se eligió el algoritmo RIJNDAEL (de sus autores Vincent Rijmen y Joan Daemen), de origen belga. Es un software de libre distribución, que está disponible desde finales del año 2001. El interés especial de este algoritmo está, como ya se ha comentado, en el proceso de selección, revisión y estudio, que se hizo tanto de este algoritmo como de los otros candidatos que hubo, que fue de carácter completamente público y abierto, con lo que, por primera vez, toda la comunidad criptográfica del mundo participó en el análisis, lo que hace del AES un algoritmo especialmente digno de confianza para todos. 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, pudiéndose elegir entre 128, 192, 256 o un múltiplo de 4 bytes. • 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.

420


• El número de etapas es flexible, dependiendo de los requerimientos del usuario. Se enumeran a continuación otros algoritmos de criptografía simétrica que se pueden encontrar en aplicaciones o protocolos, además de los ya citados: • El algoritmo Twofish, propuesto por Bruce Schneier, que se puede encontrar en algunas versiones del PGP y que fue también un candidato al AES. Tiene un diseño simple, es de tipo Feistel, está diseñado para múltiples plataformas, no exhibe claves débiles, tiene una longitud de bloque de 128 bits y su longitud de clave es variable. • Los algoritmos RC2 y RC4, de tamaño de clave variable, diseñados por Ron Rivest (la «R» de RSA Data Security). • El algoritmo RC5, creado por Ron Rivest, tanto su longitud de bloque como de clave son variables. • El algoritmo IDEA (Internacional Data Encryption Algorithm), de 1992, trabaja con bloques de 64 bits, proceso en 8 iteraciones y claves de 128 bits, utilizado, entre otros sistemas en diferentes versiones de PGP. Como se puede comprobar hay múltiples algoritmos de criptografía simétrica, aunque, hoy por hoy, conviene resaltar el DES, el TripleDES y el AES por ser los más ampliamente utilizados como mecanismos básicos de consecución de privacidad en los sistemas criptográficos habituales. Por otro lado conviene volver a resaltar que la debilidad básica de todos estos mecanismos, debido a su carácter completamente público, es la necesidad de una buena gestión de las claves, problema éste grave por la necesidad de su intercambio seguro y que se agrava cuando el número de participantes en el sistema crece. 3. FUNCIONES DE UNA SOLA VÍA (ONE WAY HASH) El propio concepto de una función de una sola vía es crucial, como se verá en la siguiente sección, para la criptografía hoy en día, especialmente para la criptografía de clave pública o asimétrica. Reciben su nombre (una sola vía) debido a su naturaleza matemática. Dado un mensaje (o texto o bloque de texto) x, es muy fácil calcular el re-

421


sultado f(x). A este f(x) se le denomina el hash de x. Suele traducirse como «resumen de x» o también message digest de x. Lo verdaderamente característico de este tipo de algoritmos es que debe ser prácticamente imposible (figura 14.3) 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, incluso con todos los ordenadores de Internet trabajando en el problema.

Figura 14.3. Mecanismo típico de una función de una sola vía.

Un buen ejemplo, de la vida real, de una de estas funciones es romper un plato. Es sencillo romper un plato en miles de trocitos, pero es bastante más complicado volver a unir todos ellos para conseguir el plato original. Este tipo de funciones deben cumplir, además de la ya citada de unidireccionalidad, una serie de características para poder ser usadas en criptografía con éxito: • Compresión. Dado un mensaje de cualquier longitud, el hash debe tener una longitud fija, siendo ésta, además, normalmente menor que la del mensaje. • 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.

422


• 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 (o resumen) 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. Debido a esta naturaleza, han sido usados en informática desde hace mucho tiempo, con diferentes nombres: función de compresión, message digest, checksum criptográfico, message integrity check (MIC), etc. Estas funciones son además públicas. Su seguridad no reside en el proceso, sino en la naturaleza, de un solo camino, del proceso. Su uso más habitual es el de garantizar la integridad, garantizar que un fichero, por ejemplo, no ha sido modificado. El procedimiento es simple: el hash de un fichero será distinto si se modifica, luego si se tiene almacenado el hash del fichero sin modificar, éste resulta modificado y se vuelve a calcular el hash, se obtendrá un hash distinto al primero. 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. También es importante en las transacciones comerciales por la red. Nadie quiere que un cargo de 100 € se convierta en un cargo de 1000 €. En general, se usan, además, 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. Como se verá más adelante, estas variantes son esenciales en sistemas como las redes privadas virtuales. Se habla entonces de código de autenticación de mensaje o MAC (debido a sus siglas en inglés: 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, salvo que sólo aquel que disponga de la clave puede verificar el valor resumen. Las funciones de una sola vía tienen un amplio abanico de usos en la seguridad informática. Prácticamente cualquier protocolo los utiliza para procesar claves, encadenar una secuencia de eventos o, incluso, autenticar

423


eventos y son esenciales, como se verá más adelante, en la autenticación por firmas digitales. 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 (figura 14.4). La salida de datos, h(i), es el hash de todos los bloques hasta el punto analizado.

Figura 14.4. Función de una sola vía.

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, más frecuentemente en su modalidad con clave o MAC, especialmente en el caso de IPSec, SSL y en prácticamente cualquier versión de autenticación RSA. MD5, además, se ha usado extensivamente para las primeras versiones de PGP. El algoritmo MD5, propuesto en 1992, es una versión mejorada de MD4, ambos algoritmos diseñados por Ron Rivest. Las siglas MD vienen de Message Digest y se trata de algoritmos que producen un hash de 128 bits del mensaje de entrada al algoritmo. 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 por todos los ceros que sean necesarios. Después se añade al resultado una representación de 64 bits de la

424


longitud del mensaje. Con esto se consigue una longitud del mensaje de un múltiplo exacto de 512 bits, a la vez que se asegura que no habrá mensajes diferentes que parezcan iguales después del ajuste. Se inicializan 4 variables: A = 0x01234567 B = 0x89abcdef C = 0xfedcba98 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 vueltas o iteraciones en MD5 (en MD4 sólo había 3 vueltas), todas parecidas. 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. No se entra en detalle de cuáles pueden ser tales funciones, al salirse tal descripción del objetivo de este libro, pero pueden consultarse en cualquiera de los libros de la bibliografía de este tema. En los últimos años se han encontrado una serie de debilidades en MD5, que han provocado pocos problemas prácticos reales, por lo que, en la actualidad, se sigue considerando un algoritmo seguro, si bien su uso tiende a disminuir. Quizás el algoritmo de una sola vía que más confianza ofrece hoy en día, y cada vez más ampliamente utilizado, es el SHA-1 (Secure Hash Algorithm). El algoritmo SHA-1 apareció como desarrollo de la NSA y del NIST, en 1994, para ser incluido en el estándar DSS (Digital Signatura Standard) y se considera seguro y libre de «puertas falsas». Produce un hash de 160 bits, a partir de bloques de 512 bits del mensaje original. El algoritmo es similar al MD5. SHA-1 emplea cinco variables de 32 bits en lugar de cuatro como el MD5. El bucle principal tiene 4 iteraciones de 20 operaciones cada una. Como curiosidad es remarcable que la

425


NSA introdujo el desplazamiento a la izquierda para corregir una posible debilidad del algoritmo, por lo que se modificó su nombre original, SHA, por el actualmente utilizado de SHA-1. Otros algoritmos de una sola vía son: • El algoritmo RIPE-MD, desarrollado para el proyecto RIPE (Race Integrity Primitives Evaluation) de la Unión Europea. Es una variante de MD4, diseñada para resistir ataques criptoanalíticos conocidos, y produce un hash de 128 bits. • El algoritmo Snefru, que debe su nombre a un faraón egipcio, diseñado por Ralph Merkle, con resúmenes de 128 o 256 bits. Ha sido ya criptoanalizado con éxito y es lento. • El algoritmo Tiger, de 1996, diseñado por Ross Anderson y Eli Biham, con resúmenes de hasta 192 bits, optimizado para máquinas Alpha de DEC. • El algoritmo N-hash, desarrollado por la Nippon Telephone and Telegraph, divide el mensaje en bloques de 128 bits, utiliza una función de aleatoriedad complicada y produce un hash de 128 bits. Como ya se ha comentado, las funciones de una sola vía analizadas no se diseñaron pensando en la autenticación, al carecer de clave secreta, pero, por otro lado, son muy interesantes para ello, al ser su velocidad de ejecución alta y sus propiedades bien conocidas. Por ello, no resulta extraño que, en la RFC 2104, se propusiera como mecanismo de autenticación segura, para entornos 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. Es éste el mecanismo habitual que se encuentra en los sistemas citados y en otros parecidos que se analizarán en los siguientes temas. HMAC usa una función de una sola vía (típicamente MD5 o SHA-1 y, en este caso, se habla de MD5-HMAC y SHA-1-HMAC) 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. Como final de esta sección se puede afirmar, una vez más, que los mecanismos de una sola vía son, en la actualidad, esenciales para casi cualquier ámbito de aplicación de la criptografía a la seguridad de las comunicaciones.

426


4. ALGORITMOS DE CLAVE PÚBLICA O DE CRIPTOGRAFÍA ASIMÉTRICA Se puede afirmar, con toda rotundidad que, en 1976, Whitfield Diffie y Martin Hellman cambiaron el paradigma de la criptografía para siempre, hicieron una «revolución criptográfica», describiendo lo que llamaron criptografía de clave pública. En esencia, la criptografía asimétrica consiste en lo siguiente: • Cada participante genera, siguiendo un algoritmo de clave pública, una pareja de claves relacionadas entre sí. Una es la denominada clave pública del participante y la otra es la denominada clave privada del participante. 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, secreta, sólo cada participante conoce su propia clave privada. • Cualquiera que conozca la clave pública del participante A puede cifrar con ella un mensaje, pero sólo el participante A puede descifrar ese mensaje, mediante su clave privada (figura 14.5).

Figura 14.5. Criptografía de clave pública.

427


Matemáticamente el algoritmo se basa en las funciones de una sola vía con puerta falsa. La encriptación es la parte fácil del proceso y la información de cifrado es, sencillamente, la clave pública. El descifrado es la parte más complicada: sin la clave privada (que es la información secreta) 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. Este tipo de funciones involucra el uso de aritmética modular, exponenciación y el uso de grandes números primos (de longitudes de miles de bits). Es especialmente remarcable cómo este tipo de métodos resuelve el problema de administración de claves de la criptografía simétrica. En aquel caso, había que ponerse de acuerdo, en secreto, en una clave. En este caso, cualquiera puede obtener la clave pública, de ahí su apellido de «pública», y sólo un participante debe conocer la clave privada. Una forma típica de uso de estos métodos para una red de usuarios es el siguiente: 1. Ponerse de acuerdo en un sistema de criptografía pública. 2. Creación de parejas de claves por cada usuario. 3. Todas las claves públicas se almacenan en una base de datos accesible a todos los usuarios. 4. Cuando el participante A quiere enviar un mensaje al participante B, obtiene la clave pública de B de la base de datos. 5. El participante A cifra su mensaje mediante la clave pública de B y se lo envía a B. 6. El participante B recibe el mensaje y lo descifra mediante su clave privada. 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.

428


• 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, al no necesitar que haya intercambio de claves seguro. Entre los puntos débiles, se pueden señalar: • Son algoritmos más lentos que los de clave secreta, con lo que no suelen utilizarse para cifrar gran cantidad de datos. • 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. La solución a este problema será abordada en los siguientes temas. Entre los problemas prácticos de los sistemas que usan criptografía asimétrica se pueden añadir otros, como el hecho de que cada participante (usuario, máquina ó proceso informático) debe mantener secreta su clave privada, que suele ser algo así como 1000 dígitos al azar, o el complicadísimo problema, ya citado, de cómo está seguro un participante A de que la clave pública de B es, realmente, la clave pública de B y no, por ejemplo, la clave pública de un atacante del sistema. En los últimos 30 años han aparecido muchos algoritmos asimétricos, pero la mayoría han resultado inseguros. Otros no son prácticos, ya sea porque el resultado cifrado es bastante mayor que el texto original o porque la longitud de la clave es enorme. Los algoritmos asimétricos usan longitudes de claves mayores que los simétricos. Mientras que en estos últimos se considera bastante segura una clave de 128 bits, en los asimétricos, excepto en los basados en curvas elípticas, se recomiendan claves de, al menos, 1024 bits. En muchas aplicaciones criptográficas, se usa esta criptografía para distribuir de manera segura lo que se llama, en tales entornos (como los de SSL o PGP), claves de sesión, llamadas así por utilizarse, en sesiones de comunicación, entre dos participantes, de tráfico cifrado mediante un algoritmo de cifra simétrica. En este caso, el procedimiento suele ser el siguiente:

429


1. El participante B envía su clave pública al participante A o, por el método que sea, el participante A tiene tal clave. 2. El participante A genera una clave de sesión, K, la cifra usando la clave pública del participante B y se la envía a B. 3. El participante B descifra el mensaje recibido, usando su clave privada, y obtiene la clave de sesión. 4. Los participantes A y B pueden, ahora, cifrar sus comunicaciones usando la misma clave de sesión. Otro ejemplo típico de uso de sistemas criptográficos asimétricos es la firma digital. Por su importancia fundamental este asunto será tratado con más detalle en el tema siguiente, pero se va a hacer ahora una primera aproximación, por ser algo directamente ligado con lo comentado en esta sección. Las firmas digitales (digital signatures) proporcionan un nivel de autenticación de mensajes parecido al de los MAC citados en la sección anterior. Además, para muchas necesidades actuales de seguridad de comunicaciones, la autenticación resulta mucho más importante que la privacidad.

Figura 14.6. Firma digital sencilla mediante cifrado asimétrico.

La forma más sencilla de conseguir una «firma digital» mediante cifrado asimétrico es la representada en la figura 14.6, consistente en los siguientes pasos:

430


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 solo 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, incluido el participante B, puede obtenerla y 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 un mensaje y «pegarla» en otro documento. Además es función de la clave privada del participante A, así que es únicamente de A. Esto es sólo una aproximación teórica sencilla, las cosas son más complicadas. No se cifran los mensajes, como ya se ha dicho, mediante estas técnicas y no se «firman» los mensajes así. Como se verá en el siguiente tema, se firma el hash del mensaje, lo que resulta varios órdenes de magnitud más veloz. Además, habitualmente no se cifra nunca el mensaje. Esto, que exige otros métodos matemáticos, dependerá de cómo se implemente la política de seguridad decidida para la organización. De entre todos los algoritmos asimétricos el más popular, y suficientemente probado como seguro, es el algoritmo RSA, que debe su nombre a sus inventores, que son Ron Rivest, Adi Shamir y Leonard Adleman. Ha estado además protegido por una patente de los laboratorios RSA hasta el 20 de septiembre de 2000, lo que lo hizo restringido, desde el punto de vista comercial, hasta esa fecha. Su utilización en las primeras versiones de PGP, como método de cifrado y de firma digital, fue polémico y, de hecho, se abandonó en versiones posteriores a favor de otros algoritmos públicos. 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: 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.

431


4. Esta pareja de números (e, N) juntos constituyen la clave pública K. Además, el número e podría formar parte de la clave pública de cualquier participante; sin embargo 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: ed = 1 /[mod(p-1)(q-1)] Es decir, que d es la inversa de e módulo de (p-1)(q-1) . La clave K’ es la pareja de números (d, N). Como detalle técnico, tal inversa se puede calcular fácilmente mediante el algoritmo extendido de Euclídes. 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 (una vez convertido el texto en dígitos binarios) se hace mediante la expresión: C = Me mod N y el descifrado del mensaje C se hace mediante la expresión: M = Cd mod N Un ejemplo ayudará a entenderlo mejor. Supóngase que Bernardo quiere enviar un mensaje a Alicia siguiendo este método. Para ello debe conocer la clave pública de Alicia, que ésta le enviará. ¿Cómo genera la pareja de claves Alicia? 1. Elige dos números primos enormes, para el ejemplo no tan enormes, por ejemplo 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» (el nombre de un hada legendaria) a Alicia. Primero lo divide en bloques, uno por carácter, X, A, N, A. Se explora lo que hace el método para el primer carácter, X.

432


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. Para cifrar el mensaje Bernardo usa la clave pública de Alicia, K, y cifra el mensaje, mediante la expresión anterior de cálculo de C, y obtiene que C = 11, que es la parte del mensaje cifrado que estamos analizando. 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) y aplica la segunda expresión, para obtener que M = 88, que, como ya se ha visto, representa la X en ASCII. El único problema que le hará difícil de seguir el ejemplo es el cálculo del número d, para el que hay que aplicar el algoritmo extendido de Euclides, que puede encontrarse en varios de los libros de la bibliografía de este tema. Desde el punto de vista técnico no es del todo verdad que RSA tenga todo su poder depositado en la factorización. 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. Por otro lado, se ha demostrado que sólo la recuperación de algunos bits del mensaje original es tan difícil como descifrar el mensaje completo. Hay campos de investigación tan curiosos como la criptografía cuántica (ver libro de Simon Singh, en la bibliografía de este tema), no obstante, que pueden hacer cambiar muchos de estos aspectos en el futuro. RSA es un verdadero estándar mundial, utilizado sobre todo para sistemas de firma digital. Muchas compañías y organizaciones usan PKCS (Public Key Cryptographic Standards), sistema creado por RSA Data Security, que, como se verá en el tema 15, permiten la creación de una infraestructura de clave pública, fundamental para todo tipo de sistemas de autenticación, como los usados en redes privadas virtuales. Otro algoritmo asimétrico fundamental para los sistemas actuales de seguridad, como se verá en los temas 16 y 17, 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 comunicaciones inseguro como, por ejemplo, Internet.

433


Es decir, siguiendo el algoritmo, 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 un clave, sin intercambiarla. El nombre original es «Internet Key Agreement» y, por más que tanto Diffie como Hellman lo han tratado de aclarar varias veces, sigue conociéndose por el nombre erróneo de algoritmo de intercambio (exchange) de claves. Una ventaja muy especial es que no son necesarias claves públicas en sentido estricto, sino una información compartida por los dos interlocutores. La fortaleza del algoritmo deriva de la tremenda dificultad del cálculo de logaritmos discretos. El aparato matemático es simple, está basado en la función de una sola vía Nx mod 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. Se pueden poner de acuerdo por un canal seguro o inseguro, no importa. 2. El participante A elige al azar un número entero grande, x, y envía Z = Nx mod P al participante B. 3. El participante B elige, de igual manera, otro número, y, y envía W = Ny mod P al participante A. 4. El participante A calcula k = Wx mod P. 5. El participante B calcula k’ = Zy mod P. En realidad, lo que sucede es que k = k’ = Nxy mod P. Cualquiera que esté escuchando por el canal inseguro puede conocer, como mucho, N, P, Z e 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. Hay detalles importantes, como que los valores de N y P sean realmente muy grandes, pues la seguridad del sistema está basada en la tremenda dificultad de factorizar números del mismo tamaño que N.

434


Una vez más, un ejemplo podrá aclarar más el mecanismo. Sería una buena idea que el estudiante tratara de repetirlo con distintos números. 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 mod 1 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 mod 1, obteniendo 9. 5. Bernardo calcula 26 mod 1, obteniendo también 9 como resultado. El algoritmo de Diffie-Hellman, como muchos resultados de aplicación de propiedades matemáticas curiosas, es sencillo, elegante y, sobre todo, muy seguro. De ahí que se utilice extensivamente en la criptografía actual. Existen otros algoritmos asimétricos seguros, como los siguientes: • El algoritmo de Rabin, que obtiene su seguridad de la dificultad de encontrar raíces cuadradas módulo un número compuesto. Se puede demostrar que este problema es el mismo que el de factorizar dicho número. • El algoritmo de ElGamal, diseñado en principio sólo para creación de firmas digitales, pero modificado, después, para cifrado en bloques. Se basa en el problema de logaritmos discretos, íntimamente ligado con el de la factorización y el algoritmo de Diffie-Hellman. • El algoritmo DSA, Digital Signature Algorithm, parte del estándar de firma digital DSS (Digital Signature Standard), propuesto por el NIST en 1991. Es una variante del algoritmo anterior. Su objetivo es, solamente, ser un estándar de firma digital, no de cifrado general, por lo que conviene compararlo únicamente con el uso que se hace de RSA para tales fines, como se verá en el tema siguiente. Hay quien dice, además, que al ser diseñado por la NSA, puede tener con mucha facilidad una puerta falsa y que permite el uso de claves pequeñas, de hasta 512 bits.

435


El edificio criptográfico, construido gracias a este tipo de algoritmos, es realmente esplendido y se puede observar en prácticamente cualquier sistema serio de seguridad en comunicaciones. Ha hecho desaparecer, casi del todo, la necesidad de una distribución de claves segura y ha abierto perspectivas a muchas metodologías matemáticas, pero, como todo en la vida, no es perfecto. 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. Mientras que el primero de los problemas parece tener una solución sencilla, debido a que los ordenadores, cada vez más potentes y rápidos, van disminuyendo la lentitud de los cálculos con claves grandes, el segundo es un grave problema. 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. Para remarcar la gravedad del problema hay que darse cuenta de que, en la actualidad, muchos de estos procesos de cifrado se llevan a cabo entre procesos de sistemas operativos entre ordenadores o dispositivos de una red, no entre personas. Una de las aproximaciones a la solución es la de crear certificados digitales, como se verá en el tema siguiente, pero esto obliga, a su vez, a la creación de otras estructuras, que ya no son completamente matemáticas, como las autoridades de certificación, que se discutirán en próximos temas, que, a su vez, implican otro tipo de problemas.

436


5. CONOCIMIENTOS Y COMPETENCIAS ADQUIRIDAS Se han descrito en este tema los algoritmos de criptografía simétrica, algoritmos que, en esencia, usan la misma clave, tanto para cifrar como para descifrar mensajes. Tales algoritmos se utilizan para conseguir la privacidad de los mensajes, haciéndolos especialmente útiles para cuando hay que intercambiar información secreta a través de canales inseguros de comunicación. Entre los más significativos se han analizado DES, TripleDES y AES. Posteriormente se han descrito las funciones de una sola vía, actúalmente una de las herramientas básicas en criptografía por su capacidad única de generación de información relacionada con la integridad de los mensajes que se envían en redes o de los ficheros que almacenamos en los discos de ordenadores. También es importante su uso como componente de los sistemas de autenticación por firma digital más utilizados. Este último punto será analizado con detalle en los siguientes temas. Entre todas las funciones de una sola vía se han destacado, por su seguridad y ubicación en casi todos los sistemas de seguridad y protocolos criptográficos importantes, el MD5 y el SHA-1. Para su uso en autenticación se utilizan sus variantes dependientes de una clave, conocidas como códigos de autenticación de mensajes, HMAC. Finalmente se ha hecho un análisis de los algoritmos de criptografía asimétrica, o de clave pública, conocidos por este nombre debido a que cada participante usa dos claves, una secreta (clave privada) conocida sólo por el mismo y una pública. Aquello que se cifra con la pública, sólo puede descifrarse con la privada, y viceversa. Se ha descrito, con cierto nivel de detalle, el algoritmo RSA, basado en el problema matemático de factorización de grandes números, claramente el más utilizado hoy en día en criptografía asimétrica, proponiendo un ejemplo para entender mejor el procedimiento. Asimismo, se han descrito otros algoritmos de clave pública utilizados, como el algoritmo Diffie-Hellman, de uso generalizado en muchos sistemas criptográficos complejos, como los protocolos IPSec, que serán analizados en el tema 16 y que forman parte esencial de la mayoría de implementaciones de redes privadas virtuales. Este tema ha descrito las herramientas fundamentales, las piezas básicas, de los protocolos y sistemas criptográficos que serán analizados en los

437


temas posteriores y que permitirán al lector entender mejor las construcciones más complejas, como las redes privadas virtuales o los sistemas de comercio electrónico. 6. BIBLIOGRAFÍA INTYPEDIA, INFORMATION SECURITY ENCYCLOPEDIA, enciclopedia gratuita en video, con muchas lecciones sobre algoritmos criptográficos, con la garantía de la red CRIPTORED y la Universidad Politécnica de Madrid, descargable desde http://www.intypedia.com/ PASTOR, J.; SARASA, M. A.; SALAZAR, J. L. (2010): Criptografía digital. Fundamentos y aplicaciones. Ed. Prensas de la Universidad de Zaragoza. SCHNEIER, B. (1996): Applied Cryptography., 2.ª edición. Ed. Wiley. SINGH, S. (1999): The Code Book: The Science of Secrecy from Ancient Egypt to Quantum Cryptography. Ed. Doubleday. Existe una versión «ligera» descargable gratuitamente, y en formato interactivo con ejercicios, desde http://simonsingh.net/cryptography/crypto-cd-rom/ 7. PALABRAS CLAVE Clave pública, RSA, DSA, clave privada, DES, 3DES, AES, hash, MD5, SHA, Diffie-Hellmann. 8. EJERCICIOS RESUELTOS 1. ¿Qué se consigue mediante el algoritmo de Diffie-Hellman? a) Se consigue una clave pública RSA, intercambiando mensajes cifrados con un algoritmo de clave secreta. b) Autenticar todo el proceso de transmisión mediante firma digital. c) Obtener una clave, para su uso en un sistema de clave privada, para dos participantes, sin que se la comuniquen entre ellos. d) Dotar de privacidad a todos los mensajes, que se cifren con la clave DH. Solución: c.

438


2. ¿De qué propiedad dota AES a los mensajes cifrados mediante el? a) b) c) d)

Dota de integridad a los mensajes. Dota de privacidad a los mensajes. Los dota de firma digital. Los mensajes resultan autenticados y privados.

Solución: b. 3. ¿Cuál de los siguientes es un uso habitual de las funciones de una sola vía? a) Garantiza la no modificación de la clave privada de los participantes en un sistema seguro de comunicaciones mediante AES. b) Comprobar si un fichero, del que teníamos un hash previo, ha sido modificado. c) Dotar de privacidad a mensajes cifrados con una de estas funciones. d) Garantiza la autenticación de un mensaje, siempre que el emisor del mismo lo cofre usando un hash pactado previamente. Solución: b. 4. Si se desea usar MD5 de forma que no todo el mundo que quiera pueda conocer el hash de un mensaje, ¿qué mecanismo se debe utilizar? a) b) c) d)

Ninguno adicional, MD5 ya proporciona este comportamiento. Usar la variante MD5-DESX. Usar la versión MD5-HMAC. Autenticar el mensaje con la clave pública de los participantes.

Solución: c. 5. ¿Cuál de las siguientes no es una característica del algoritmo RSA? a) Es un algoritmo rápido, de uso sencillo para un gran volumen de datos. b) Es un algoritmo de clave pública que usa claves de 1024 bits. c) Su complicación matemática se deriva de las propiedades de factorización de grandes números. d) Se usa habitualmente para la firma digital. Solución: a.

439


9. EJERCICIOS DE AUTOEVALUACIÓN 1. ¿Cuál de las siguientes es una característica que debe cumplir cualquier buen algoritmo criptográfico de una sola vía o hash? a) La forma del algoritmo debe ser mantenida permanentemente en secreto. b) Debe ser fácil de calcular. A partir de un mensaje o texto debe ser sencillo calcular su hash. c) Debe ser simétrico. A partir del hash debe ser trivial obtener el texto original. d) Debe utilizar como clave sólo la privada de una pareja de claves RSA previamente certificada por una Autoridad de Certificación. 2. En una red en la que se utiliza un sistema de criptografía simétrica se asume que es necesaria una clave por cada pareja de usuarios. Si se está pensando en 30 usuarios de la red, ¿Cuántas claves distintas serán necesarias? a) b) c) d)

450 claves distintas. 60 claves distintas. 435 claves distintas. 870 claves distintas.

3. ¿Con qué clave se puede descifrar un mensaje cifrado con la clave pública RSA de un dispositivo de red? a) Con la clave privada RSA del dispositivo de red. b) Con la clave privada del emisor del mensaje cuyo destino es el dispositivo de red. c) Con la misma clave pública RSA citada. d) Con la clave pública después de cifrada con el hash correspondiente. 4. ¿Cuál de los siguientes algoritmos no proporciona privacidad a mensajes? a) b) c) d)

440

DESX. AES. TripleDES. RSA.


5. ¿Cuál de los siguientes es un problema asociado con la criptografía asimétrica? a) b) c) d)

La necesidad de un canal seguro para el intercambio de claves. La no polaridad de la distribución Feistel. La necesidad de certificación de las claves públicas. La dificultad de los procedimientos de hash asociados.

441

Tema 15

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

1. Introducción, orientaciones para el estudio y objetivos 2. Autenticación, integridad y no repudio de la información 3. Los sistemas de firma digital 4. La necesidad de certificación. El estándar X.509 y las autoridades de certificación 5. Los modelos de infraestructura de clave pública o PKI 6. Problemas de seguridad de las firmas digitales y de las PKI 7. Conocimientos y competencias adquiridas 8. Bibliografía 9. Palabras clave 10. Ejercicios resueltos 11. Ejercicios de autoevaluación

1. INTRODUCCIÓN, ORIENTACIONES PARA EL ESTUDIO Y OBJETIVOS En el tema anterior se han analizado las herramientas básicas de la criptografía, desde el punto de vista de su aplicación en los sistemas de seguridad de las redes de ordenadores, relacionándolas con las características de seguridad deseadas para el tráfico por dichas redes. Es cierto que hay situaciones concretas en que es perfectamente normal que la política de seguridad de la organización imponga la privacidad para cierto tipo de tráfico de datos, de manera que nadie, que sea capaz de obtener tales mensajes, pueda obtener la información legible. Como ya se ha visto esta propiedad se consigue utilizando algoritmos de criptografía simétrica. Pero, 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. Este tema comienza analizando los problemas típicos que se plantean al intentar conseguir tales propiedades y se analizarán algunas soluciones que no usan el concepto de firma digital, como el modelo de Kerberos. Después se retoma el concepto de firma digital, explicando la importancia que tiene, hoy en día, para casi cualquier sistema de autenticación segura en redes. Se analizarán distintos esquemas de firma digital, haciendo énfasis especial en el más utilizado, que es el basado en el algoritmo de criptografía asimétrica RSA. Este tipo de sistemas de firma digital, basados en la clave pública de cada uno de los participantes (entendiendo por tales no sólo a personas, sino, cada vez más, a sistemas, dispositivos y procesos), necesitan alguna forma

445


segura de certificación de tal clave pública. Esto ha hecho introducir distintos estándares, de los cuales el más significativo e importante es el estándar X.509, que será, también, motivo de análisis en otra sección de este tema. En este modelo, cada participante tiene un certificado X.509, que certifica su identidad, en realidad su clave pública, pero esto hace aparecer otro problema: ¿quién garantiza al resto de los participantes que ese certificado es válido? Aquí aparecen las Autoridades de Certificación (AC). Hay distintos modelos, tanto desde el punto de vista tecnológico, como desde el punto de vista de seguridad, que serán analizados en otra sección del tema. Las AC pueden ser públicas o privadas, gestionadas de manera casi automática o gestionadas de manera manual, unos son más compatibles que otros, etc., pero todos forman parte, hoy en día, de la estructura básica fundamental de muchos sistemas de autenticación en redes. De hecho, son una parte esencial de algo fundamental en la seguridad de muchas redes, de la parte de la seguridad relacionada con la autenticación, que usan casi todos los sistemas de comercio electrónico, conocido como infraestructura de clave pública o PKI, por las siglas en inglés de Public Key Infrastructure. Tales PKI serán, también, objeto de estudio en otra sección del tema, en el que se analizarán los distintos estándares relacionados con ellas. Finalmente se van a describir los problemas actuales de seguridad, relacionados con todas estas estructuras, que pueden ayudar a decidir, en muchos casos, si se usan o no las PKI, qué sistemas de firma digital resultan más adecuados para cada organización y qué factores hay que tener en cuenta para la administración correcta de tales estructuras organizativas. De una u otra forma, las estructuras y algoritmos de este tema, y del anterior, se están usando, y modificándose parcialmente todos los días, en los protocolos criptográficos que se describirán en el tema siguiente. Estos, a su vez, se utilizan en los sistemas criptográficos utilizados en redes de ordenadores, tanto en el caso de seguridad aplicada a redes internas de las organizaciones, como al tráfico comercial por redes inseguras, especialmente Internet. Por estas razones es importante, una vez más, que el lector trate de obtener una visión clara y concisa de los conceptos definidos en el tema, así como de las principales estructuras y procedimientos descritos, lo que le será necesario para seguir con el resto del libro.

446

CERTIFICACIÓN, AUTENTICACIÓN E INTEGRIDAD DE LA INFORMACIÓN. FIRMA DIGITAL Y PKI

2. AUTENTICACIÓN, INTEGRIDAD Y NO REPUDIO Empecemos repasando una serie de conceptos importantes. La autenticación es la propiedad que permite demostrar que uno es quien dice ser. Este concepto tiene diversas acepciones dependiendo de dónde y cómo se aplique. Si se trata de una persona que realiza su declaración de la renta por Internet, la aplicación es clara, pero puede tratarse, también, de otras situaciones igualmente importantes, como: • Un dispositivo de red, por ejemplo un encaminador, demostrando a otro encaminador en Internet, que realmente su identidad es la que dice ser. Este paso es fundamental, como se analizará en temas posteriores, para la creación, por ejemplo, de una red privada virtual. • Un servidor de comercio electrónico, que usa SSL, demostrando a un posible cliente, mediante lo que se conoce como «conexión segura», que realmente es el servidor que dice ser. Esto se aplica, también, en el otro sentido, pues es igual de importante que el cliente demuestre ser quien dice ser. • Un servidor de oficina de banca por Internet, que necesita asegurarse de que un mensaje de cargo a una cuenta corriente es de quien dice ser. El mensaje suele venir cifrado con una contraseña, que puede estar autenticada. La integridad es la propiedad que permite garantizar que una serie de datos no han sido modificados. Tal serie de datos pueden ser un fichero, en cuyo caso es relativamente fácil entender cómo se aplica: • Se obtiene la marca de integridad (típicamente un hash) del fichero en el momento en que se sabe que tiene el contenido correcto. • Cuando se quiere comprobar si el fichero ha sido modificado, se recalcula tal marca y se compara con la original. Si es idéntica, no ha habido modificación. En caso contrario, el fichero ha sido modificado. Pero, al igual que con la autenticación, se puede aplicar en muchas otras situaciones, como por ejemplo: • En una red, en la que los participantes se han puesto de acuerdo en una función de una sola vía, para que el receptor compruebe si el mensaje que le ha llegado ha sido modificado o no.

447


• En sistemas criptográficos, mediante el uso de resúmenes de tipo HMAC, en los que la función depende de una clave, compartida sólo entre un grupo de participantes, lo que permite usar el método sólo al grupo deseado. Se podría hablar aquí de integridad «autenticada», en el sentido de grupo. Hay otra propiedad interesante para la seguridad, especialmente en entornos comerciales. Se trata del no repudio y 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. Esto es necesario tanto para poder culpar de un cierto problema, con seguridad, al causante del problema, como para poder darle el crédito de ser quien dice que es. Si no se puede asociar correctamente un mensaje con su creador, no es raro que se cuestione, tanto al emisor como la validez del contenido del propio mensaje. Esencialmente, el problema se puede resumir en dos cuestiones: • Si el emisor niega haber enviado un mensaje, ¿cómo comprueba el receptor que el mensaje que le ha llegado es realmente del emisor? Se habla aquí del no repudio del emisor. El emisor debe asumir todas las responsabilidades derivadas de la información que ha enviado. Realmente, se está aquí ante un problema no del todo resuelto, como se analiza en la última sección de este tema. • 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 denomina no repudio del receptor. En la vida no digital, y durante años, se han usado toda una variedad de métodos para reducir la capacidad de la gente de negar que hayan sido los creadores de documentos de papel. Tales métodos y los aplicados a sus homólogos digitales son bastante parecidos y están muy unidos, como es lógico, a los problemas de autenticación. En ambos casos, se aplica una firma al mensaje. En el caso de firmas en papel, se trabaja con una autoridad de confianza, por ejemplo un notario, para validar los mensajes. En el campo digital es típico el uso de una Autoridad de Certificación, aunque no es la única solución. En estos casos, como se ve más adelante, tal autoridad de certificación emite un documento denominado certificado digital.

448


Para conseguir todas estas propiedades (o solo parte de ellas) se utilizan varias combinaciones de algoritmos criptográficos asimétricos y funciones de una sola vía y casi todas ellas pasan por la utilización de firmas digitales. Se pueden analizar, no obstante, algunas soluciones de estos problemas que no usan el concepto de firma digital, sino que se basan en criptografía simétrica. 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 participante del sistema. Así, si Alicia y Bernardo son dos de tales participantes, el Fiador mantiene una clave, Ka, para la comunicación segura con Alicia y una clave, Kb, para la comunicación segura con Bernardo.

Figura 15.1. Autenticación y no repudio mediante clave privada.

En el caso en que Alicia desea enviar un mensaje a Bernardo (figura 15.1), los pasos que se siguen con este sistema 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, obteniendo M y, encriptándolo con Kb, envía a Bernardo tanto el mensaje M, la identidad de Alicia y la «firma» C(Ka(M)), C(Kb(M, A, C(Ka(M)))).

449


Como tanto Alicia como Bernardo confían en el Fiador, el procedimiento es seguro y, en caso de dudas, el Fiador puede comprobar la identidad de Alicia, descifrando el mensaje recibido de ella. En este caso, la propia cifra de datos está haciendo el papel de «autenticador». En el caso de que la clave del algoritmo simétrico sea segura, se puede afirmar que, además de la privacidad que se consigue con tal cifra, se obtiene a la vez la integridad y autenticidad del mensaje, ya que es únicamente el usuario 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. No hay que olvidar, no obstante, que se sigue teniendo, con este método, la inseguridad de la transmisión de claves. 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, además, debe compartir una clave, que suele denominarse maestra, con todos los participantes de este sistema. La tarea del KDC es distribuir una clave de sesión, que será utilizada, por sesión, para la conexión entre dos participantes. 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, servicio de autenticación, auditoria y contabilidad, desarrollado en el MIT (Massachussets Institute of Technology) como parte del proyecto Athena. Recibe su nombre por la figura de la mitología griega, el Can Cerbero, un perro de 3 cabezas, que guarda la entrada del templo de Hades. Realmente, en la actualidad, sólo está implementada la función de autenticación. El modelo es simple. 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 algoritmo 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 y todos aquellos clientes y servicios de la red que necesitan autenticación registran su clave secreta con Kerberos. 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

450


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. Siguiendo a Kerberos, 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. Antes de seguir el proceso con más detalle, hay que introducir la 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 credenciales es minimizar el número de veces que un usuario tiene que teclear su contraseña, así como eliminar el problema de tener que enviarla, sin cifrar, por la red. Finalmente 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.

451


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 (haciéndose pasar por el cliente) si no es muy rápidamente. Cuando un cliente quiere conectarse a un servidor en la red tiene que dar los pasos ilustrados en la figura 15.2, y enumerados aquí: 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 quién dice que es. 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, que sirven de clave secreta, 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 a primera hora de la mañana, cuando todo el mundo entra a trabajar. El modelo Kerberos ha sido implementado con éxito por empresas como DEC o IBM en distintas universidades, pero fue cayendo en el olvido por sus dificultades de compatibilidad, hasta hace unos años que resurgió

452


Figura 15.2. Esquema de conexión cliente servidor en una red Kerberos.

gracias a sistemas de Microsoft, en los que apareció como método de autenticación en dominios, pero con un grave problema: la implementación de Microsoft es incompatible con el resto de implementaciones. Es ahora el momento de explorar los estándares de autenticación con cifra asimétrica, es decir la autenticación mediante lo que, en el ámbito de la seguridad criptográfica, se denomina firma digital. 3. LOS SISTEMAS DE FIRMA DIGITAL Desde el punto de vista criptográfico, 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 de ser única, sólo el emisor debería ser capaz de generarla.

453


• Debe ser fácil de reconocer por cualquier receptor de un mensaje. • Debe depender del mensaje y del emisor. En conjunto, se puede afirmar de estas condiciones que hacen al sistema bastante seguro y, a la vez, que son más fuertes que las que se impone a una firma manuscrita. 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. Además, el hecho de estar usando una firma digital no implica que el mensaje esté cifrado. Puede estarlo o no, independientemente de la firma. En esencia, 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 y en las funciones de una sola vía que soporten. Así, el algoritmo DSA (Digital Signature Algorithm), ya citado en el tema anterior es parte del estándar DSS (Digital Signature Standard), que solo acepta SHA-1 como función de una sola vía. Igualmente, hay sistemas de firma digital basados en los algoritmos El Gamal. No obstante, el más popular de los sistemas de firma digital es el basado en el algoritmo RSA. Con él, pueden utilizarse distintas funciones de una sola vía (por ejemplo, MD5 o SHA-1) y la cifra asimétrica que se usa es, por supuesto, la ya analizada de RSA. El método de firma digital más extendido, con diferencia, es el de RSA. En este modelo, el procedimiento de firma de un mensaje (figura 15.3) por parte del emisor es: • Genera un hash del mensaje, H1, mediante una función de una sola vía acordada previamente en el sistema. • 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 (figura 15.4), las siguientes operaciones: • 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.

454


Figura 15.3. Procedimiento de firma digital de un mensaje de A a B.

Figura 15.4. Proceso de comprobación del receptor de un mensaje firmado.

455


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 (autenticación) y que no fue modificado en el transcurso de la comunicación (integridad). Aparentemente es un mecanismo suficientemente seguro para conseguir los objetivos deseados, pero tiene un inconveniente. Nunca hay nada 100% seguro. Todo sistema criptográ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. 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. Esto no es más que una manera de cambiar el problema citado en la sección anterior por otro distinto. Las nuevas preguntas son: ¿cómo se certifica? y ¿quién lo certifica? Para contestarlas, hay que acudir al concepto 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. La entidad, que tenga un certificado emitido por la AC, se autentica ante otra entidad participante, ya que su clave pública está firmada por la AC en la que ambos confían. 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. Pero esto no es más

456


que una primera aproximación. Se va a analizar ahora, en más detalle, cada uno de estos entes. El certificado digital tiene un formato estándar, universalmente aceptado, conocido como X.509. Su primera versión data de 1988, siendo la propuesta más antigua realizada para construir una infraestructura de clave pública a nivel mundial. Su diseño estaba muy relacionado con la intención de proveer de servicios de autenticación a los usuarios del servicio de directorio X.500. Su origen está, además, suficientemente refrendado tanto por la ISO (International Standards Organization) como por la ITU (International Telecommunication Unit), antigua CCITT. En 1993 se creó la versión 2, ampliando el formato en dos campos más, para identificar de forma única el emisor del certificado y el usuario del certificado. La versión 3, X.509v3 amplió, aún más, la funcionalidad del certificado. Un certificado digital X.509 (figura 15.5) tiene los siguientes campos: • Versión del formato del certificado, normalmente la versión X.509v3.

Figura 15.5. Formato X.509 de un certificado digital.

457


• Número de serie del certificado, SN. Es un identificador numérico único dentro del dominio de certificación de la CA. Cuando se revoca un certificado, asunto que se analizará después, es este número el que aparece en la lista de revocación de certificados o CRL, que contiene la lista de los certificados que no sirven para autenticar, al estar marcados como no fiables para la autenticación. • 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, por ejemplo podría ser SHA1-RSA. • Emisor del certificado, que es el nombre de la AC, en formato X.500. • Fechas de inicio y final de validez, que determinan el periodo de validez del certificado. • El nombre del propietario de la clave pública que aparece firmada en el certificado, en formato X.500. • La información de identificación del algoritmo utilizado, la clave pública del usuario y una serie de parámetros opcionales, que luego se analizarán. Estos parámetros, llamados extensiones del certificado permiten definir sus propios datos organizativos, algo que viene muy bien, por ejemplo, para el protocolo SET. • La firma digital de la AC, es decir, el resultado de cifrar, mediante el algoritmo asimétrico (por ejemplo, RSA) y la clave privada del AC, el hash obtenido del documento X.509. En la figura 15.6 se puede ver un ejemplo de un certificado digital, tal y como se puede observar en la aplicación Internet Explorer de Microsoft. Es muy importante señalar que cada navegador (Internet Explorer, Chrome, Mozilla Firefox y otros) lleva ya instalados una serie de ellos, algo que habitualmente ignoran los usuarios y que, como se verá en breve, tiene una gran transcendencia para la seguridad en las redes. Algunos de los parámetros serán muy interesantes cuando se analice más adelante el papel de las autoridades de certificación en una PKI, como los puntos de distribución de las CRLs para este certificado, es decir, las ubicaciones en la red de la lista de los certificados revocados. El proceso habitual (aunque no el único) con que dos participantes, A y B, que confían en una AC, obtienen cada uno sus certificados, para poder,

458


Figura 15.6. Un certificado digital.

más tarde, autenticarse el uno al otro es el descrito en la figura 15.7, que se puede enumerar así: 1. A y B generan, usando el algoritmo asimétrico convenido, una pareja de claves pública y privada. Este debe ser el procedimiento habitual, aunque existen autoridades de certificación que pueden generar la pareja de claves ellas mismas, pero, en este caso, es importante darse cuenta de que tales 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 (en la siguiente sección se hablará de su formato, que es también un estándar) 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 (el de A aA y el de B a B) 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.

459


Figura 15.7. Proceso de obtención de certificados digitales.

Cuando, más adelante, A y B quieren autenticarse, por ejemplo para crear una conexión entre ellos, se intercambian certificados digitales y comprueban 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, analizado en la sección anterior, comprueba que la firma digital es correcta. Para ello necesita descifrar la firma digital del certificado recibido mediante la clave pública de la AC, pero dispone de ella pues tiene también el certificado digital de la AC.

460


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 de certificados, aspecto este último que rara vez se cumple, pero debería de cumplirse. 4. Si la firma es correcta, el periodo también y el certificado no está revocado, se acepta el certificado y se considera a autenticado. El paso 2 debería de provocar otra pregunta más: ¿Cómo puede B fiarse de que el certificado de la AC que tiene es correcto? La respuesta es simple y elegante. 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. Esto deja aún una incógnita, analizada al final del tema, y muy poco controlable mediante la criptografía, pues el emisor del certificado digital de la AC puede no ser realmente el que se piensa y, sin embargo, cumplir exactamente todos los pasos comentados hasta aquí. Se está ante un problema de confianza básica que nada tiene que ver con la criptografía, especialmente cuando la AC reside en Internet o en una red en la que no se pueda confiar. Las autoridades de certificación tienen una serie de responsabilidades importantes: • Crear certificados digitales. • Administrar los certificados digitales. • Revocar certificados digitales inválidos. Además se puede tener la AC dentro de la red de la organización, controlada y gestionada por miembros de la propia organización que son, habitualmente, parte del equipo de seguridad o fuera de la propia red, como un tercero (fiable) con el que se colabora. Incluso puede haber modelos mixtos, que manejen diferentes necesidades con diferentes autoridades de certificación. Hay, además, en el mercado distintas soluciones de construcción y gestión de los programas que implementen estos servicios de autenticación, que forman la pieza clave de lo que se denomina PKI o infraestructura de clave pública.

461


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, gestionar 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. Tales estructuras están hoy en día presentes en todos los sectores de nuestra vida: • Servicios financieros: oficinas «on-line» de bancos, autenticación de pagos, control de acceso, correo electrónico seguro, notaría digital, almacenamiento seguro de documentos. • Seguros: firma digital, autenticación de pago, administración segura de documentos. • Administración pública: DNI electrónico, declaración de la renta, obtención de información de la administración. • Comercio electrónico: todas las aplicaciones de comercio electrónico en general. • Infraestructura de empresas: a través de las redes privadas virtuales, conocidas como Extranet, las empresas agrandan su estructura organizativa colaborando entre sí mediante la comunicación segura por Internet. Las piezas clave de cualquier PKI son las autoridades de certificación, ya analizadas en la sección anterior. Además, en la actualidad, se dispone de dos modelos generales de PKI, dependiendo de cómo se organicen las AC (figura 15.8), 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. Es una solución típica para organizaciones no muy grandes, varios cientos de máquinas. 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

462


Figura 15.8. Modelos generales de PKI.

la AC raíz, que firma certificados de las AC subordinadas. Éstas, a su vez, firman certificados de AC inferiores o, directamente, de participantes en la red. Cuando una gran organización tiene sus distintas sedes geográficamente muy dispersas (por ejemplo, Microsoft o CiscoSystems) suele usar este modelo de PKI. En el caso de Cisco, por ejemplo, el AC raíz está ubicado en San Jose pero, en lugar de hacer que sus 30,000 empleados hagan una petición de certificado a San Jose, se colocaron, estratégicamente, una serie de AC subordinados por todo el mundo, de forma que los empleados locales obtienen su certificado del AC subordinado local. Es importante señalar que, en este último modelo, el receptor final, por ejemplo Alicia, no recibe sólo dos certificados digitales, sino el suyo, el del AC subordinado y, si no hay más niveles de jerarquía, el del AC raíz, siendo ésta la única manera de poder cumplir completamente el proceso, comentado previamente, de autenticación. Existe, además, otra variante organizativa, que deriva del hecho de que se pusiera en duda la fiabilidad general de la figura de la AC, diciendo que una cosa es que emitiera certificados y otra muy distinta que su procedimiento de comprobación de identidad del participante, para el que se emitía el certificado, fuera seguro. La duda es, realmente, muy razonable y sigue siendo una cuestión debatida. La variante consiste en introducir un

463


intermediario entre el participante, que pide un certificado, y la AC. Tal intermediario, que es el responsable de asegurarse de la identidad del primero, se denomina autoridad de registro, AR, y suministra a la AC con la que trabaja los datos verificados del solicitante del certificado, con el fin de que la AC emita el certificado. Esto complica cualquiera de los dos modelos citados, es polémico y no está soportado por todos los programas que implementan la figura de una AC, como se va a analizar en breve. Hay distintos métodos de petición de certificados, distintos protocolos de comunicación entre los peticionarios de certificados y las AC o AR. El más común, el más usado por ejemplo en la implementación de IPSec para redes privadas virtuales es, como se analizará en los temas siguientes, el basado en los PKCS (Public Key Infrastructure Standards) publicados por RSA Data Security, seguidos por la mayor parte de fabricantes. Entre las más relevantes de estas normas están: • PKCS #1 que describe un método de cifrado y descifrado, mediante RSA, empleado en la construcción de las firmas digitales y de los formatos de petición descritos en el PKCS #7. Están aquí las recomendaciones de las funciones de una sola vía a utilizar, típicamente MD5 o SHA-1, y el formato de los mensajes cifrados. • PKCS #3 que describe un método de implementación del algoritmo de Diffie-Hellman citado en el tema anterior. • PKCS #5 que describe un método para cifrar mensajes mediante una clave secreta derivada de una palabra de contraseña. Usa MD2 o MD5 para derivar la clave a partir de la contraseña y usa DES para cifrar los mensajes. Está diseñado, principalmente, para cifrar claves privadas que viajan de un ordenador a otro, pero puede usarse igualmente para cifrar mensajes. • PKCS #7 que define la sintaxis general de los datos que pueden estar cifrados o firmados. Tal sintaxis es recursiva, pudiéndose obtener mensajes dentro de mensajes o pudiéndose firmar datos que, previamente, estaban encriptados. Es compatible con PEM (Privacy Enhanced Mail), de forma que los mensajes en tal sintaxis puedan convertirse en mensajes PEM sin ninguna operación criptográfica intermedia, y viceversa. Ésta y otras compatibilidades hacen a los mensajes PKCS #7 es-

464


pecialmente operativos para la administración de claves basada en certificados digitales. • PKCS #10, que describe las normas sintácticas de creación de las peticiones de certificados. Se pide un nombre del tomador del certificado, que puede utilizar algunos de los parámetros opcionales del certificado, una clave pública y, de manera opcional, otra serie de atributos. Todos estos datos deben ir firmados mediante la clave pública que se envía, siendo ésta la información que usará la AC para validar la petición de certificado. • PKCS #11, que especifica una interface de programación de aplicaciones criptográficas, la Cryptographic Token API, para dispositivos criptográficos de cualquier clase. • PKCS #12 describe la sintaxis para almacenar mediante software las claves públicas y privadas del participante, sus certificados y toda una serie de información criptográfica relacionada. Su objetivo es tratar de normalizar en un único fichero toda la información criptográfica que puedan necesitar diferentes aplicaciones. 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 el propio sistema donde reside el programa de la AC, en un directorio LDAP o en cualquier sitio alcanzable y administrable por la AC. • Cuando un participante no se fía de su clave pública, bien porque sabe que le han robado, bien porque quiere cambiar las claves, o por cualquier otra razón, 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 ubica en varios lugares, hay que distribuirla periódicamente. En teoría, debería ser cada vez que haya un cambio.

465


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, aunque no existe la obligación, por parte de los participantes, de asegurarse de que el CRL está actualizado. En la práctica, muchos de estos procedimientos no se dan, lo que hace que este modelo tenga en la CRL uno de los posibles agujeros de seguridad. Las figuras 15.9 y 15.10 muestran un ejemplo de un certificado revocado. En la primera aparece la información del nombre de la AC que emite la CRL, la fecha de emisión, la fecha de la siguiente emisión y, en la segunda ventana (figura 15.10), cómo la CRL se organiza por número de serie (SN) y la fecha de revocación. En cada certificado, como se recordará, hay una extensión CRL que incluye el punto de distribución de la CRL. En el lado de los participantes, se esté hablando de una persona, de un PC o un servidor, o de un dispositivo de red más sofisticado (como encaminador, cortafuego, concentrador VPN, etc.), hay que seguir siempre el mismo procedimiento de trabajo, hay que almacenar certificados e información relacionada. Esta información, esencialmente, es de tres tipos: • Certificados personales, de identidad del participante. • Certificados de AC y de AR. • Peticiones de certificados PKCS #10. Bastantes autoridades de certificación soportan, en la actualidad, mecanismos automáticos de petición y obtención de certificados. Por ejemplo, se puede citar el SCEP (Simple Certificate Enrollment Protocol), principalmente desarrollado por Cisco, adoptado por Microsoft y soportado, como ya se ha comentado, por muchos fabricantes de software de AC. Es un estándar en proyecto de la IETF, patrocinado por Cisco, Verisign, Entrust, Microsoft y Sun Microsystems. El SCEP es un protocolo que opera entre el cliente y la AC. El proceso de petición de certificado 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 (como se puede configurar, por ejemplo,

466


Figura 15.9. Lista de revocación de certificados, pestaña general.

Figura 15.10. Lista de revocación de certificados, pestaña CRL.

467


en el caso del Certificate Server de Windows Server). Tal proceso depende de las posibilidades de configuración y administración de cada AC. En una red corporativa, que controla internamente la PKI, el proceso de aprobación se podría hacer automático (dependiendo de su política de seguridad), mientras que si se trata de una petición a una AC pública, el proceso debería retrasarse para hacer una aprobación manual más detallada. Mediante SCEP, el proceso (figura 15.11) 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.

Figura 15.11. Proceso de certificación con SCEP.

468


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. Es importante, desde el punto de vista de la seguridad, señalar la diferencia entre dos modelos: • El modelo «clásico» de software, en el que las personas que instalan y administran los productos son los responsables finales de la seguridad de la PKI. • El modelo «de negocio», como el de Verisign, en el que, sin poder verificar los férreos controles que la empresa dice imponer para la administración de los certificados, se está dependiendo de una compañía cuyo objetivo es vender certificados. Resumiendo, se podría afirmar que, además de decidir el sistema de PKI que se va a utilizar, una buena organización de autenticació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, especialmente en la cuestión de distintos modelos de certificación. • Deberá estar clarísimamente definido el procedimiento de aprobación de certificados, en todas sus posibilidades: cuándo puede ser automático, cuándo manual y en qué casos requerirá una seguridad mayor, incluyendo, por ejemplo si es de una persona, la presencia física. • Deberá estar, también, claramente definida la política con respecto a la lista de revocación de certificados. Todas estas cuestiones, y algunas otras citadas previamente, hacen que la administración segura de una PKI sea algo especialmente sofisticado y costoso, dando lugar a muchas interpretaciones y problemas, que hay que tener en cuenta a la hora de la implantación y mantenimiento. Estos problemas son analizados en la siguiente sección.

469


6. PROBLEMAS DE SEGURIDAD DE LAS FIRMAS DIGITALES Y DE LAS PKI A pesar de todas las ventajas evidentes para los problemas de autenticación que ofrecen las PKI y la firma digital, 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 problemas está relacionada con: • No hay una manera estándar de implementarlas. • Hay toda una serie de problemas de incompatibilidad. • Problemas de formación y concienciación de los usuarios. La mayor parte de los usuarios no sabe si está usando o no una PKI y no saben cómo interactuar con tales sistemas que, además, no son muy amigables. Empecemos por qué no todas las aplicaciones aceptan los mismos certificados digitales, hay una falta real de interoperabilidad. El hecho de ceñirse al estándar X.509.v3 no garantiza en absoluto que dos certificados generados por dos sistemas desarrollados por empresas distintas sean mutuamente compatibles. Además, existen problemas de confianza entre AC de distintas organizaciones, que puede imposibilitar la verificación con éxito de cadenas de certificación cuya AC raíz sea desconocida o no confiable, invalidándose todo el esquema de PKI. Al ser algo políticamente obligado, podemos encontrarnos aún aplicaciones que no acepten los certificados digitales, con lo que esto implica de problemas de integración. 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, tal como se ha comentado, 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 certificados emitidos para los usuarios va creciendo, debido a

470


que las listas de revocación deben ser consultadas en cada operación que involucre certificados y firmas digitales, si se desea una implantación seria y robusta. Bien es cierto que el esquema de confianza vertical, promulgado por las estructuras de certificación en árbol, resulta más escalable que los modelos de confianza horizontal, como el adoptado por PGP, cuya problemática es tan seria que no se prevé solución satisfactoria. Otro problema grave es el relacionado con el no repudio. Se asume que, realmente, sólo el participante conoce su clave privada, lo cual no es, ni mucho menos, evidente. Como consecuencia, cuando se descifra un mensaje firmado con tal clave privada NO se puede afirmar, con toda seguridad, que lo firmó el propietario de la clave. Puede haber sido alguien que la robó o, incluso, un troyano que estaba en el ordenador del participante. Una firma digital NO es igual que una manuscrita. En ésta, se puede asumir que, quien firmó, leyó el documento y entendió los términos del mismo. 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, de manera que si una clave usada para firmar digitalmente documentos ha sido certificada por un AC aprobado por la ley, el propietario de la clave puede ser responsable de lo que se haga con tal clave. Es decir, no importa quién estuviera sentado delante del ordenador utilizándola o qué virus la utilizó, el responsable es el propietario de la clave. Otro parámetro de configuración muy importante, desde el punto de vista de los problemas de seguridad, que puede ocasionar problemas es el periodo de validez de los certificados, que debería estar claramente planificado. Piénsese que, por defecto, muchos productos de AC definen un periodo de validez de tres o cinco años. Esto puede ser una buena política para algunas situaciones pero, para otras, es una elección pobre. Quizás el más grave de los problemas está relacionado con eso que se ha denominado, en varios temas, el Peopleware, y seguramente también con la filosofía. 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. 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. Ade-

471


más, más que la máxima autoridad, en el que todo el mundo confía, realmente existe una jerarquía de AC, una especie de panteón de autoridades, debido al uso extensivo del modelo jerárquico de AC. Los certificados de las AC raíces de estas jerarquías suelen estar, muchas veces sin que los usuarios se den cuenta, en el software que utilizan, por ejemplo los navegadores de Internet. 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, si no se determinan claramente suficientes campos de identificación, en el nombre, como para diferenciar todos los «Juan García» posibles. Otros problemas parecidos aparecen si se analiza el modelo de AC y AR. La idea es que la AR (autoridad de registro) sea responsable de validar lo que va a aparecer en el certificado y la AC es responsable de emitirlo. Este modelo puede ser, no obstante, bastante menos seguro que el de gestionar sólo AC, pues permite a una entidad (la AC), que no es autoridad sobre los contenidos, obtener un certificado con esos contenidos. Por supuesto, firmará un contrato comprometiéndose a no hacer tal cosa, pero, obviamente, dispone de la capacidad técnica para hacerlo. Otro problema es el relacionado con los sistemas (casi todos) que no tienen en cuenta correctamente 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? ¿Tendría sentido pensar en una «revocación retroactiva», para que el propietario de un certificado pudiera negar haber firmado algún documento? Los certificados digitales y las PKI no son «el bálsamo de Fierabrás», que se añade al sistema, haciendo a éste seguro. 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.

472


7. CONOCIMIENTOS Y COMPETENCIAS ADQUIRIDAS En este tema hemos repasado las características básicas que se pueden obtener para el tráfico de mensajes en redes gracias a los métodos criptográficos: autenticación, integridad y privacidad, añadiéndose otro muy relacionado con la autenticación, como es el no repudio. Se han explorado distintas metodologías criptográficas, y no asimétricas, de obtención de la autenticación, basadas en métodos de cifra simétricos, especialmente el sistema Kerberos, en el que un servicio en la red, Kerberos, proporciona autenticación segura, mediante DES y el hecho de compartir una clave secreta diferente con cada participante, lo que le permite autenticar al participante A (por ejemplo, un cliente de una aplicación de base de datos) frente al participante B (el servidor de la base de datos). Posteriormente se ha definido lo que es una firma digital de un documento y los requisitos que debería de cumplir. Siguiendo el esquema más utilizado, el de la cifra RSA, se ha descrito la operación de firma digital antes del envío del documento y la operación de recepción del documento firmado, y comprobación de su autenticidad y validez. Se ha definido el concepto de certificado digital, como método de certificación de la clave pública que sirve para la autenticación de una firma digital y el concepto de Autoridad de Certificación, como la entidad, en la que confían todos los participantes, que emite, controla y gestiona tales certificados digitales. Se ha descrito también como los participantes se autentican entre sí mediante el intercambio de sus propios certificados digitales, firmados por la autoridad de certificación, que ejerce, así, el papel de una especie de «notario digital». Se ha analizado la importancia conceptual de la CRL y de su gestión y la dificultad que entraña tal gestión, así como los problemas que pueden aparecer si la CRL no resulta correctamente administrada. Se ha definido el concepto de infraestructura de clave pública, PKI, en el que cada vez más sectores y mercados se basan para obtener métodos de autenticación seguras para todas sus transacciones. Dentro de los modelos de PKI, teniendo en cuenta los posibles usos de las autoridades de

473


certificación, se han explorado los dos modelos en uso: el modelo central, con una única autoridad de certificación, y el modelo jerárquico, con una jerarquía de autoridades, más complejo de gestionar, pero más adecuado, seguramente, para grandes organizaciones. Se han analizado los estándares de petición, gestión y formato de documentos cifrados más utilizados en la actualidad, los PKCS o Public Key Criptography Standards, desarrollados por RSA Data Security y utilizados ampliamente en el mundo de las PKI. Así mismo se ha detallado el funcionamiento del SCEP, o Simple CertificateEnrollmentProtocol, protocolo de comunicación entre clientes y autoridades, para la petición y obtención de certificados digitales.Finalmente se han analizado algunos de los principales problemas relacionados con las PKI y los métodos de autenticación mediante firma digital analizados. A pesar de todos estos problemas analizados, «no hay más cera que la que arde». Estas son, con todos sus problemas, las herramientas con las que se cuenta para asegurar criptográficamente la autenticación en redes. En el tema siguiente se analizan toda una serie de protocolos criptográficos. 8. BIBLIOGRAFÍA ELLISON, C. y SCHNEIER, B. (2000): «Ten risks of PKI: what you’re not being told about Public Key Infrastructure», Computer Security Journal, Volume XVI, Number 1. INTYPEDIA, INFORMATION SECURITY ENCYCLOPEDIA, enciclopedia gratuita en video, con muchas lecciones sobre algoritmos criptográficos, con la garantía de la red CRIPTORED y la Universidad Politécnica de Madrid, descargable desde http://www.intypedia.com/ PASTOR, J.; SARASA, M. A.; SALAZAR, J. L. (2010): Criptografía digital. Fundamentos y aplicaciones. Ed. Prensas de la Universidad de Zaragoza. SCHNEIER, B. (1996): Applied Cryptography. 2.ª edición. Ed. Wiley. SINGH, S. (1999): The Code Book: The Science of Secrecy from Ancient Egypt to Quantum Cryptography. Ed. Doubleday. Existe una versión «ligera» descargable gratuitamente, y en formato interactivo con ejercicios, desde http://simonsingh.net/cryptography/crypto-cd-rom/

474


9. PALABRAS CLAVE Autenticación integridad, no repudio, RSA, X.509, AC, CRL, PKI, PKCS. 10. EJERCICIOS RESUELTOS 1. ¿Qué método criptográfico se usa para comprobar que un certificado X.509, que identifica a una AC, es seguro y ha sido emitido realmente por tal AC? a) Una vez recibido el certificado, se calcula el hash del mismo, se descifra la firma digital mediante la clave pública del AC y se comparan los dos datos. b) Una vez recibido el certificado, se calcula el hash del mismo y se compara con el hash recibido. c) Una vez recibido el certificado, se llama al administrador de la AC, se lee la firma digital y se espera la comprobación. d) Una vez recibido el certificado, se cifra con la clave pública de la AC y se compara con la firma digital adjunta al certificado. Solución: a. 2. La firma digital permite, sin ninguna duda, que se cumpla el no repudio de un mensaje enviado por el usuario A al usuario B : a) b) c) d)

Verdadero, pero sólo si se usa PKCS#2 y SHA-1. Falso, no se puede conseguir nunca. Verdadero, por eso hay seguridad legal en el comercio electrónico. Falso, la firma digital puede garantizar que el menaje se ha enviado desde el ordenador del usuario A, pero no por el usuario A.

Solución: d. 3. ¿Cuál de los siguientes métodos y algoritmos utiliza Kerberos? a) Utiliza una AC de modelo central y el algoritmo RSA. b) Utiliza una KDC y el algoritmo IDEA. c) Utiliza un servicio Kerberos, que comparte una clave secreta con cada participante y el algoritmo DES. d) Utiliza un servicio Kerberos, que comparte una clave secreta con cada participante y el algoritmo RSA con PKCS#5. Solución: c.

475


4. Se puede afirmar siempre que el valor por defecto del periodo de validez de un certificado digital, dado por el emisor AC, es un valor correcto: a) Falso, debe ponerse siempre un 25% aproximadamente, por cuestiones de cálculo de factorizaciones relacionado con RSA. b) Verdadero, es un valor que no se puede negociar. c) Verdadero, por eso son siempre seguros. d) Falso, habitualmente es un valor demasiado grande y, en cualquier caso, dependerá de lo decidido en la política de seguridad de la organización. Solución: d. 5. ¿Qué contiene una CRL asociada con una Autoridad de Certificación? a) La lista, identificada por su número de serie, de los certificados digitales que han caducado. b) La lista, identificada por su número de serie, de los certificados digitales que la AC ha detectado que han sido manipulados ilícitamente. c) La lista, identificada por su número de serie, de los certificados digitales, que han sido puestos en cuestión por cada uno de sus propietarios por problemas de seguridad. d) La lista de los certificados digitales que revocan la autoridad de cada certificado digital de la AC. Solución: c.

11. EJERCICIOS DE AUTOEVALUACIÓN 1. ¿Qué diferencia hay entre identificación y autenticación? a) Ninguna, son sinónimos. b) Identificación es decir uno quién es y autenticación es que sus datos sean privados. c) Identificación es decir uno quién es y autenticación es demostrar uno que es quien dice ser. d) Autenticación es decir uno quién es e identificación es demostrar uno que es quien dice ser.

476


2. En el modelo de Kerberos, ¿qué información contiene un autenticador? a) El nombre del cliente, la información temporal del momento de creación y la dirección IP del cliente. b) La dirección IP del cliente, el número de port del servidor y la clave de cifrado. c) La clave de cifrado Kerberos, el ticket Kerberos y un certificado digital. d) La dirección IP del cliente, el nombre del cliente y su certificado digital en formato X.509. 3. ¿Cuál es el campo de un certificado digital que implementa la autenticación del emisor del certificado? a) El campo de «Nombre del emisor» del certificado. b) La firma digital de la Autoridad de Certificación, del emisor del certificado. c) La clave pública del emisor del certificado. d) El identificador del algoritmo de cifrado. 4. A la hora de crear una firma digital de un documento, ¿Con qué clave se cifra el hash del documento? a) b) c) d)

Con la clave pública del emisor del documento. Con la clave privada del receptor del documento. Con la clave privada del emisor del documento. Con una clave AES especializada en firma digital.

5. ¿Cuál de los siguientes es un problema típico asociado con las PKI? a) b) c) d)

La poca formación de los usuarios de las mismas. La debilidad del protocolo RSA. La debilidad del protocolo AES. La no existencia de un estándar de certificado digital.

477

Tema 16

Protocolos criptográficos más habituales

1. Introducción, orientaciones para el estudio y objetivos 2. Protocolos de comercio electrónico: SSL 3. Protocolos de comercio electrónico: SET 4. Los protocolos IPSec 4.1. 4.2. 4.3. 4.4.

El protocolo AH - Authentication Header El protocolo ESP - Encapsulating Security Payload Las asociaciones de seguridad en IPSec Un ejemplo básico de uso de IPSec

5. El protocolo PGP 6. Conocimientos y competencias adquiridas 7. Bibliografía 8. Palabras clave 9. Ejercicios resueltos 10. Ejercicios de autoevaluación

1. INTRODUCCIÓN, ORIENTACIONES PARA EL ESTUDIO Y OBJETIVOS Un protocolo es simplemente un conjunto de mensajes, intercambiados entre dos o más participantes. Estos mensajes tienen un cierto orden, una secuencialidad concreta, están diseñados para resolver una tarea. Todos los participantes deben conocer el protocolo y los pasos concretos que deben dar en cada fase de ejecución. Cuanto menos ambiguo sea el protocolo más fáciles de conseguir serán los objetivos y menos malentendidos habrá entre los participantes. 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, simplemente, un protocolo que usa métodos criptográficos, independientemente de que su objetivo final vaya más allá de lo que estos permiten conseguir. Realmente, los protocolos criptográficos se crean utilizando métodos tradicionales de programación de protocolos y algoritmos criptográficos, pero sirven (figura 16.1), a su vez, de piezas básicas, y fundamentales, con las que construir sistemas criptográficos más complejos. Desde el tema 13 hemos ido caracterizando las principales propiedades buscadas para asegurar, de distintas maneras, el tráfico de las redes de ordenadores. Tales propiedades pueden conseguirse utilizando distintos algoritmos criptográficos analizados en los temas 14 y 15 y estos algoritmos son los que permiten crear los protocolos criptográficos de los que se trata en este tema. Con estos protocolos se construyen los sistemas citados. Como se verá algo más adelante, los sistemas criptográficos tienen muchas, y diversas, orientaciones y objetivos. Se puede estar hablando de redes privadas virtuales, cuyo objetivo esencial es asegurar todo el tráfico IP

481


Figura 16.1. Niveles de la arquitectura de sistemas criptográficos.

que circula por redes consideradas inseguras, o de sistemas de comercio electrónico, en cuyo caso el objetivo es asegurar todas las transacciones comerciales, o de sistemas seguros de correo electrónico, en cuyo caso se trata de asegurar únicamente los mensajes de correo electrónico. Todos estos sistemas parten, a su vez, de estructuras de gestión y control, más complejas aún, de redes, que utilizan de una u otra forma, unas veces más y otras veces menos, alguno de estos protocolos criptográficos. En este tema, se analizan los protocolos criptográficos más significativos en la actualidad, empezando por los protocolos de comercio electrónico. Quizás el más ampliamente utilizado con este fin es el SSL (Secure Sockets Layer). Este protocolo y el SET (Secure Electronic Transactions), ejemplo de protocolo que no ha terminado de arrancar, serán analizados en las primeras secciones del tema.

482

PROTOCOLOS CRIPTOGRÁFICOS MÁS HABITUALES

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, protocolos analizados también en este tema. Estos protocolos trabajan en equipo para construir un túnel IP seguro, el más seguro de los actuales, entre participantes en una red que los usen. Son, claramente, los protocolos más utilizados para el despliegue de redes privadas virtuales y son, por esta razón, los más ampliamente implementados por los fabricantes de programas relacionados. Tienen, además, un futuro muy claro, por estar desarrollados, inicialmente, para la nueva versión de IP, IPv6, de manera que cuando IPv6 sea una realidad habitual, no habrá que hacer un esfuerzo suplementario para implementar niveles más altos de seguridad. Finalmente se analizará el protocolo PGP (Pretty Good Privacy), un buen ejemplo de un protocolo utilizado, entre otras cosas, para asegurar todo el tráfico de correo electrónico por Internet. Se trata de dar una visión amplia de los protocolos criptográficos más usados hoy en día, relacionándolos con los algoritmos previamente analizados y permitiendo al lector disponer de los conceptos, estructuras, procedimientos e ideas necesarias para afrontar, con éxito, el reto de entender algunos de los sistemas criptográficos típicos de las redes de ordenadores. 2. PROTOCOLOS DE COMERCIO ELECTRÓNICO: SSL Hoy en día, y gracias a redes como Internet y a todo tipo de dispositivos móviles, cada vez más transacciones comerciales, y transacciones realizadas con las administraciones públicas, se realizan desde cualquier lugar y en cualquier momento. A todo lo que rodea esta nueva forma de hacer negocios se le conoce con el nombre de comercio electrónico. Hay muchas modalidades distintas de comercio electrónico y no existe una especie de normalización de tipos, pero, sin embargo, la imagen de alguien comprando desde su ordenador personal, montando una tienda por Internet para ofrecer sus productos o sus servicios, es cada vez más habitual. Igualmente es cada vez más normal que operaciones como obtener una cita para el centro de salud, pedir datos de la vida laboral o hacer la declaración de la renta, se realicen de manera segura y fiable por Internet.

483


Hay una parte de este fenómeno de transacciones seguras por la red que es muy parecida a la de la vida real: • En la vida real, el cliente entra en la tienda, por la red se carga en el navegador la página web de la tienda. • En la vida real, el cliente echa un vistazo a los productos o va directamente al sitio donde sabe que está lo que busca, pero, finalmente, los va almacenando en un carrito; en la red, se navega por la página, se revisan los productos o servicios y se colocan en un «carrito virtual» (que es, simplemente, un fichero de usuario). • Finalmente, en la vida real, se va a la caja, se especifica un sistema de pago y se facturan los productos al cliente. En la tienda virtual, se dirige al cliente a la página de toma de datos y se pide el método de pago, que suele ser una tarjeta de crédito. Hasta aquí llegan los parecidos. En la transacción por Internet los productos llegarán a casa en unas semanas o en unos días, dependiendo del tipo de producto y del método seleccionado. Piénsese que, en muchos casos, este tipo de compra-venta electrónica genera beneficios económicos, casi todos debidos a la gestión tan diferente del tiempo que se puede hacer de esta nueva manera. No obstante, al realizar una operación comercial por una red como Internet se presentan nuevos problemas: • 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á, realmente, 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? Hoy en día la solución a estos problemas, y a otros, se consigue gracias al uso de protocolos criptográficos. Por otro lado, más del 90% de los sitios de comercio electrónico son sitios web, por lo que no debe resultar extraño que los protocolos que se van a analizar estén estrechamente ligados con el WWW.

484


La empresa que desarrolló SSL (Secure Sockets Layer) fue Netscape Communications. Su objetivo de diseño era proporcionar seguridad a nivel de transporte de la suite IP. Su diseño fue ligeramente posterior a la primera versión de un navegador de web llamado Mosaic, desarrollado por la NCSA (Nacional Center for Supercomputing Applications) en 1993. El diseño de SSL se completó a mitad de 1994 y los productos se empezaron a vender a finales de 1994. En estas mismas fechas, Netscape presentó su browser, conocido como Netscape Navigator. A mediados de 1995 Microsoft dio a conocer su propio navegador, el Internet Explorer, con su propio elemento de seguridad, el PCT (Private Communications Technology). Obviamente, el producto de Microsoft resultó ser un poderoso competidor, pero SSL estaba ya muy inmerso en el mercado de los servidores y PCT no sobrevivió. Netscape ha sido el único responsable del desarrollo de las tres primeras versiones de SSL, pero, a finales de 1996, SSL fue a parar al IETF (Internet Engineering Task Force), de forma que el protocolo se convirtió en uno de los estándares más estándares de este mundo, al ser un estándar «de facto», aceptado por la industria y un estándar de la IETF. En la actualidad, los navegadores más habituales (Internet Explorer, Mozilla Firefox, Google Chrome, Safari) y sus correspondientes productos servidores, tienen SSL como herramienta de seguridad. Un dato importante del uso de SSL es su transparencia desde el punto de vista de un usuario, que navega por Internet. Si la página se identifica como «https» (o sea HTTP Seguro) 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, para identificar los participantes y sus mensajes, dentro de un grupo de participantes seleccionado. • Privacidad, para poder cifrar y descifrar solo los mensajes dentro del mismo grupo. • Intercambio de claves, para poder intercambiar entre los participantes el material necesario para asegurar la autenticación y la privacidad de sus mensajes.

485


Tales características se consiguen al implementar el protocolo vía la interacción de los dos únicos componentesnecesarios: • El cliente SSL, que suele ser un navegador web, un proceso que pide un servicio. Es el iniciador de la comunicación segura. Tiene, además, 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, un proceso que proporciona un servicio, requerido por sus clientes, y 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. Hay que remarcar que aunque el servidor tiene la decisión final de las negociaciones de seguridad, solo se puede atener a las opciones propuestas y no puede tomar la iniciativa. Si se observa la figura 16.2, se puede ver la ubicación en la suite IP de los cuatro componentes principales del protocolo SSL: • Registro, un nivel que recibe los datos, en forma de bloques no vacios, del nivel superior y los encapsula.

Figura 16.2. Componentes cliente y servidor del SSL.

486


• 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. Se examinan con más detalle, a continuación, cada uno de los componentes, de manera independiente. El nivel de Registro recibe datos del nivel superior y lo fragmenta en bloques de texto sin cifrar, de bytes o menos. El resto de procesado del nivel consiste en cifrado o compresión, aunque normalmente está soportado solo el cifrado. Todos los fragmentos del mensaje van cifrados y los MAC (Message Authentication Code) se definen dependiendo de la cifra especificada para la conexión. El conjunto de datos de una cifra viene dado por: • Tipo de cifra, que puede ser de tipo bloque o de tipo stream. • Estado de exportación, que puede ser verdadero o falso. • Algoritmo de cifra, que puede ser ninguno, RC4, DES, 3DES, AES, FORTEZZA y otros. • Algoritmo de MAC, que puede ser ninguno, MD5 o SHA. Una vez se ha completado el handshake (se han acabado las negociaciones de seguridad), el cliente y el servidor tiene ya el material necesario para autenticar y proteger los mensajes entre ambos. El proceso de cifrado y autenticación transforma los bloques del mensaje en texto cifrado SSL. Además, el nivel de Registro incluye, en cada transmisión, un número de secuencia para identificar con facilidad cualquier mensaje perdido, modificado o adicional. Hay 13 mensajes definidos en la especificación del protocolo SSL. Tales mensajes tienen lugar en distintos momentos de la sesión SSL o como método de reinicio de una sesión pasada y están relacionados con alguno de los cuatro componentes principales del protocolo SSL, como se ve a conti-

487


nuación.El proceso handshake sirve para proponer y aceptar (al final, para negociar) los parámetros necesarios para que el nivel de Registro procese los fragmentos de mensajes de una sesión SSL. Es la operación fundamental para decidir cómo será la sesión SSL. Al iniciarse una sesión SSL (figura 16.3), 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. En la figura 16.3 se ha supuesto que los parámetros de seguridad solo están pidiendo privacidad. Si el proceso incluyera también autenticación, se reemplazaría el mensaje ServerKeyExchange por un mensaje Certificate y entre los mensajes 4 y 5 y entre los 5 y 6 aparecerían dos mensajes CertificateRequest y CertificateVerify. No se va a analizar el formato de los mensajes del protocolo SSL, pero es importante señalar que todos ellos comparten una estructura común, definida en el proceso de encapsulación del nivel de Registro. En esta estructura común, un campo del mensaje identifica el grupo de mensajes y un campo de tipo especifica el mensaje individual. Tal estructura común consiste en: • Campo de protocolo: longitud de 1 byte, define el protocolo de nivel superior contenido en este mensaje SSL, que puede ser 20 para ChangeCipherSpec, 21 para el protocolo de Alerta, 22 para el protocolo de handshake y 23 para el caso en que lo que va en el mensaje son datos de una aplicación. • Campo de versión: longitud de 2 bytes, define la versión del mensaje SSL. • Campo de longitud: longitud de 2 bytes, define la longitud del mensaje de nivel superior, en formato de número binario de 16 bits. • Campo de tipo de mensaje: longitud variable, contiene el mensaje del protocolo definido en el campo de protocolo. • Campo de MAC: verificación (opcional) de la integridad del mensaje. Normalmente se usa MD5.

488


Figura 16.3. Mensajes de SSL en el proceso de handshake.

Como ya se ha comentado, el SSL pasó al IETF en 1996. Esto provocó, por parte del IETF, el inicio del desarrollo de un protocolo de seguridad llamado TLS (TransportLayer Security) cuya primera especificación llegó en 1999. Realmente hay muy pocos cambios (y ninguno significativo) entre SSL y TLS, siendo esto fácilmente entendible, por razones de compatibilidad. El problema mayor de SSL es el de la autenticación opcional y su control. Si no hay autenticación parece claro, como ya se señaló en el tema anterior, que algunos de los problemas citados al principio de esta sección siguen existiendo, pero incluso con autenticación algunos otros siguen sin

489


resolverse y todo este tipo de indefiniciones pueden dar lugar a otras situaciones peligrosas, como, por ejemplo, las siguientes: • Alguien crea una tienda en Internet para vender un producto, el que sea, pero mucho más barato. Su servidor usa SSL con muy buenas condiciones de seguridad, pero, al no ser obligatoria la autenticación, sin ella. Ante tal oferta, habrá compradores que faciliten, al comprar, su número de tarjeta de crédito sin pedir más referencias. Al poco tiempo, el servidor desaparece de Internet y el creador, por supuesto, también. Posiblemente los productos comprados no existen y, además, no se puede reclamar a nadie. El «timador» puede empezar a usar toda la información recogida de forma fraudulenta en su beneficio. • Otro problema típico es el uso fraudulento de una tarjeta correcta, ya sea por robo o por uso por parte de una persona no autorizada. El vendedor no tiene forma de saber, en el momento de la transacción comercial, nada más que si la tarjeta es correcta o no. Hay que decir, sin entrar en detalles que están más allá de los objetivos de este libro, que lo que si suele funcionar aquí es el modelo de seguridad de las tarjetas de crédito: si alguien detecta el robo de su tarjeta y da el aviso rápidamente, el cargo no se le hace, abonando, normalmente, el banco la compra. • Un problema «clásico» que ha dado ya lugar a grandes problemas en EE.UU. Es el caso de una tienda en Internet, con muchos compradores que confían en ella, por su seriedad. En la tienda hay servidores que usan SSL. Como la tienda utiliza un fichero con los datos de sus clientes (nombre, dirección, teléfono y número de tarjeta de crédito), 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 utilizado no es tan buena como en los servidores SSL y tiene un agujero de seguridad, que permite a un atacante penetrar y llegar al fichero de la base de datos de clientes de la tienda. En pocos días, por Internet circula un fichero con miles de números de tarjeta de crédito de compradores… asombrados. El problema clave es que, en el diseño de SSL, el vendedor debe conocer el número de tarjeta de crédito del cliente, para poder cobrar el importe de la factura.

490


3. PROTOCOLOS DE COMERCIO ELECTRÓNICO: SET Para intentar evitar muchas de las debilidades citadas se creó el protocolo SET (SecureElectronicTransactions), desarrollado en 1995 por Visa y MasterCard, con la ayuda de Microsoft, Netscape, IBM, GTE, RSA, TerisaSystems y VeriSign. Más tarde, se fueron adhiriendo, al estándar, empresas como American Express, Sun y otra serie de fabricantes y usuarios. Es importante señalar que 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. En el momento en que cada participante ha conseguido su certificado digital, el protocolo SET dirige el diálogo entre las tres entidades fundamentales: • El cliente, poseedor de la tarjeta de crédito. • El vendedor. • El equipo, controlado por un banco, que hace de «pasarela» de pago. La necesidad estricta de certificación (en formato X.509) es la base fundamental de la seguridad del protocolo, además de que cada entidad participante conoce únicamente la información que necesita. Lo que se consigue con este modelo es lo siguiente: • Que el vendedor no tenga acceso a la información de pago, no llegará a conocer el número de tarjeta de crédito del comprador. • 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 (como si fuera un cheque) y no puede ver el número de la tarjeta, pero si puede guardarlo y, sobre todo, enviarlo al banco. Éste, cuando lo reciba, lo descifrará y podrá comprobar la veracidad y validez de los datos de la tarjeta. El último paso es la transferencia a la cuenta del vendedor de la cantidad facturada.

491


El proceso completo del protocolo SET (figura 16.4), cuando participan un comprador, un vendedor y los bancos del comprador y del vendedor, es el siguiente: 1. El comprador, una vez seleccionados los productos que desea, llena la orden de compra y selecciona el botón de pagar. Aquí comienza SET. 2. El comprador, mediante SET, 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 (típicamente 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 número de la tarjeta de crédito del comprador y la información del banco emisor de la tarjeta y se cifra mediante la clave pública del banco. 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, descifra la información de pago del cliente y su identidad. Genera, a su vez, 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, despué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.

492


Figura 16.4. Proceso de transacciones del protocolo SET.

8. El vendedor envía un mensaje de compra a su 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. Para ser compatible con los métodos anteriores, SET usa SHA como función de una sola vía, DES como algoritmo simétrico y RSA con tamaño de clave de 1024 bits. A pesar de solucionar en teoría una serie de problemas, la puesta en marcha real de SET nunca llegó, debido sobre todo a una serie de inconvenientes:

493


• SET está controlado por un consorcio que impone sus propias normas, lo que se ha traducido en que mucha gente prefiera decidirse por otro tipo de soluciones. • SET es un protocolo robusto, pero necesita mucho ancho de banda y mucho uso de recursos criptográficos. Ésta puede ser una situación adecuada para transacciones grandes, pero, definitivamente, está mal adaptado a transacciones pequeñas de dinero. • Con SET, tanto los compradores como los vendedores deben almacenar, en sus ordenadores, tanto los certificados como las claves secretas, lo que puede implicar, como ya se ha comentado, una serie de problemas. Esto se podría arreglar con tarjetas inteligentes protegidas por sistemas biométricos, ya comentados en temas anteriores, pero este método dista mucho de aplicarse en la actualidad. 4. LOS PROTOCOLOS IPSEC El diseño original de los protocolos IPSec (IP Security) se puede analizar en los RFC del 1825 al 1829, aunque, posteriormente se ha revisado varias veces, siendo las versiones más actuales las que van del RFC 4301 al RFC 4309, que datan de 2005, y cuyo nombre oficial es: • RFC 4301: Security Architecture for the Internet Protocol. • RFC 4302: IP AuthenticationHeader. • RFC 4303: IP Encapsulating Security Payload. • RFC 4304: Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP). • RFC 4307: Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2). • RFC 4308: Cryptographic Suites forIPsec. • RFC 4309: Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP). Es importante señalar, así mismo que hay unos 10 o 20 documentos RFC más relacionados con ellos. En la actualidad se ha convertido en el

494


grupo de estándares, para implementación de todo tipo de redes privadas virtuales, más ampliamente aceptado por la industria y por los usuarios. Con toda probabilidad, el aspecto más significativo que ha influido en tal soporte entusiasta es su diseño. Se diseñó específicamente para IPv6 y es compatible con la versión aún más utilizada, IPv4, del protocolo, de manera que tiene un gran futuro asegurado en las redes que trabajen en IPv6. 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 poder cifrarse. Esto quiere decir que si fuera necesario que todos los datos fueran cifrados, IPSec debe poder cumplir tal objetivo. No quiere decir que todo el tráfico, obligatoriamente, debe ir cifrado. • 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. Por otro lado, las características de seguridad que ofrece IPSec son las siguientes: • 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. Para ello, IPSec utiliza tres protocolos diferentes e independientes, lo que hace más fácil, también, la modularidad de la implementación, permitiendo la actualización de algoritmos. Por ejemplo, fue sencillo incluir en las implementaciones de IPSec como algoritmo de cifrado simétrico el AES.

495


Tales protocolos independientes son: • El protocolo AH (AuthenticationHeader). • El protocolo ESP (Encapsulating Security Payload). • El protocol ISAKMP (Key Management Protocol). 4.1. El protocolo AH - Authentication Header El protocolo 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. El hecho de que la función de una sola vía HMAC involucra el uso de una clave secreta compartida entre los dos extremos significa que se garantiza la autenticidad de los mensajes. Para ello AH utiliza habitualmente MD5-HMAC o SHA-1-HMAC. AH puede opcionalmente proteger contra ataques de tipo repetición, usando técnicas del protocolo TCP como las sliding Windows (ventanas deslizantes). AH protege el payload de IP y todos los campos de cabecera de un datagrama IP, excepto los campos mutables (aquellos que pueden resultar alterados durante el transito del mensaje). AH es un protocolo que opera directamente por encima de IP, utilizando el número de protocolo IP 51. La figura 16.5 ilustra los detalles de su cabecera.

Figura 16.5. Cabecera del protocolo AH.

En la figura 16.5, el significado de cada campo es: • Next header: Identifica el protocolo de los datos transferidos.

496


• Payload length: Es el tamaño del paquete AH. • RESERVED: Reservado para uso futuro, mientras tanto su contenido es ceros. • Security parameters index (SPI): Indica los parámetros de seguridad que, en combinación con la dirección IP, identifican la asociación de seguridad implementada con este paquete. Se aclara más adelante en esta misma sección. • Sequence number: Un número siempre creciente, utilizado para evitar ataques de repetición. • HMAC: Contiene el valor de verificación de integridad necesario para autenticar el paquete; puede contener relleno. 4.2. El protocolo ESP - Encapsulating Security Payload El protocolo ESP proporciona la privacidad de los datos aunque, opcionalmente, puede proporcionar, también, integridad y autenticación de los datos. Es independiente de AH. Esto quiere decir que se puede usar, como se analiza más adelante, solo AH, solo ESP o ambos a la vez. Para la integridad y la autenticación, los algoritmos son los mismos que para AH. Para la privacidad se usa DES (cada vez menos), 3DES o AES. De forma diferente que con AH, la cabecera del paquete IP no está protegida por ESP (aunque, como se verá en breve, usando ESP en modo túnel, la protección es proporcionada a todo el paquete IP interno, incluyendo la cabecera interna; la cabecera externa permanece sin proteger). ESP opera directamente sobre IP, utilizando el protocolo IP número 50. La figura 16.6 muestra una cabecera ESP. En la figura 16.6, el significado de cada campo es: • Security parametersindex (SPI): Identifica, como antes, los parámetros de seguridad en combinación con la dirección IP. • Sequencenumber: Un número siempre creciente, utilizado para evitar ataques de repetición. • Payload data: Los datos a transferir.

497


Figura 16.6. Cabecera del protocolo ESP

• Padding: Usado por algunos algoritmos criptográficos para rellenar por completo los bloques. • Padlength: Tamaño del relleno en bytes. • Nextheader: Identifica el protocolo de los datos transferidos. • Authentication data: Contiene los datos utilizados para autenticar el paquete. En el caso de ESP se puede operar, además, en 2 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, una «pseudo-cabecera» de IP, que será analizada en breve. 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 (figura 16.7) 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. Tales direcciones origen y destino serán las de los dispositivos intermedios, los extremos del túnel.

498


Figura 16.7. Un túnel IPSEC ESP en una red privada virtual.

4.3. Las asociaciones de seguridad en IPSec Los protocolos IPSec están diseñados para dotar de una serie de propiedades de seguridad al tráfico que viaja entre dos puntos cualesquiera de una red IP, independientemente de la aplicación. Cuando las redes sean sobre todo redes IPv6, esto podrá implementarse más o menos así, pero, mientras tanto, en redes IPv4 (y por mucho tiempo) IPSec se usa para situaciones mucho más concretas. En este sentido, y como se verán en mucho mayor detalle en el tema 17, IPSec se usa 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 compartidos 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 el protocolo Internet Security Association and Key Management Protocol (ISAKMP). El material relacionado con las claves de cifrado lo proporcionará este protocolo, especialmente en su versión IKE, Internet Key Exchange. Desde un punto de vista más práctico, una asociación de seguridad es una conexión, en un solo sentido, que proporciona un determinado con-

499


junto 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 (una en cada sentido) para asegurar el tráfico entre dos puntos de la red. Cada AS está identificada 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, además, dos bases de datos relacionadas con ellas: • La SPD (Security PolicyDatabase), 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 AssociationDatabase), que contiene los parámetros asociados con cada una de las AS individuales activas. Ya esté implementado en un servidor, equipo de sobremesa, encaminador o cualquier otro dispositivo, IPSec pone en marcha la protección requerida conforme a lo estipulado en una SPD. Esta SPD la establece y la mantiene un administrador de seguridad o un usuario. Cada paquete IP que resulta seleccionado para IPSec recibe uno o más de los servicios especificados por la SPD. La selección se hace, básicamente, al estilo de un filtro de paquetes, es decir, basándose en campos de las distintas cabeceras de un mensaje IP y sus concordancias con lo especificado en la política concreta. En el caso de Cisco, por ejemplo, se usa una lista de control de acceso (ver tema 8) para crear lo que se denomina, en el entorno de Cisco, una «cripto-lista de acceso», que es la manera de indicar qué tráfico hay que seleccionar como tráfico a ser procesado por IPSec. En el procesado de una comunicación IPSec extremo a extremo, se crea una 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 asociación de seguridad tiene una entrada única dentro de la base de datos de asociaciones de seguridad o SAD. El índice de parámetros de seguridad (SPI) es necesario para diferenciar entre asociaciones de seguridad distin-

500


tas, que tienen como extremo final la misma dirección IP destino y están usando el mismo juego de protocolos IPSec. Cada una de las entradas de la SAD representa, por tanto, 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 usa 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., y lo mismo del caso anterior si, con ESP, se busca también, integridad. • El tiempo de vida de la AS, expresado como tiempo, como número de bytes cifrados dentro de la misma AS o como ambas cosas a la vez. • El modo de uso del protocolo ESP que, como se ha analizado previamente, 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 (figura 16.8), aparece una nueva cabecera de AH entre la cabecera de IP y el resto del mensaje.

Figura 16.8. Transformación IPSec AH de un mensaje IP.

Un mensaje así hace aparecer en la cabecera IP un número de protocolo 51, el de AH, y la cabecera AH tiene los siguientes campos significativos: • El hash del paquete IP entero, empleando una versión «estandarizada» de la cabecera IP, en la que no aparecen los campos que cambian al

501


atravesar el mensaje un encaminador, por ejemplo el campo de tiempo de vida del mensaje (campo TTL de la cabecera IP). La función mínima exigida por IPSec es la MD5, de longitud de hash de 128 bits. • El SPI de la asociación de seguridad utilizada. • La información del protocolo de la cabecera siguiente, con el mismo significado del número de protocolo de la cabecera IP. • La longitud de la siguiente cabecera. En el caso de elegir ESP para el procesado, el formato es algo más complicado pues debe incluir, como ya se ha dicho, una nueva cabecera IP y, además, información de cifrado simétrico para la confidencialidad y, opcionalmente, de integridad. En cuanto al protocolo KMP y a las necesidades de administración de todo el entorno de claves, vale la pena leer lo estipulado en el RFC 2401: Todas las implementaciones DEBEN soportar la configuración manual de las asociaciones de seguridad. Tales implementaciones deberían soportar un protocolo estándar de Internet de establecimiento de asociación de seguridad (como IKMP, Photuris) una vez tal protocolo se publique como un RFC.

Finalmente se eligió un protocolo, originalmente presentado como un conjunto de protocolos de intercambio de claves, conocido como ISAKMP (Internet Security Association Key Management Protocol)/Oakley (método muy parecido a Diffie-Hellman para creación de claves compartidas), ahora más comúnmente conocido como IKE (Internet Key Exchange). El RFC estándar de IKE, define un protocolo híbrido, cuyo propósito es negociar, y proporcionar, material autenticado de claves necesarias para la negociación de las asociaciones de seguridad, de manera protegida. EL IKE se encarga, además, de la generación de claves, su distribución y su revocación. Pensando en una red privada virtual, dos o más participantes de una sesión segura de comunicaciones necesitan compartir los mismos algoritmos de cifrado, las mismas longitudes de claves y las propias claves. El intercambio de todo este material se realiza, en IPSec, mediante asociaciones de seguridad.

502


Los mensajes de negociación de IKE son mensajes UDP con número de puerto 500. Además, las implementaciones habituales de IKE permiten iniciar la negociación solo cuando los dos equipos participantes en la sesión se han autenticado entre sí, soportando como métodos de autenticación, al menos los siguientes: • El método de los certificados digitales X.509. • El envío de mensajes firmados, mediante HMAC, con una clave compartida secreta entre los dos participantes, que debe ser configurada por el administrador. El mecanismo habitual para la creación de las claves compartidas necesarias para todas las otras funciones de una sola vía, usadas por AH o ESP, se suele realizar mediante el algoritmo de Diffie-Hellman. 4.4. Un ejemplo básico de uso de IPSec Se va a analizar ahora, brevemente, 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 (figura 16.9) se quiere crear una conexión segura con un equipo B en otra parte de la red. Se puede analizar fácilmente dividiendo el trabajo en una serie de pasos: 1. El encaminador X recibe 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 (si no hubiera ya una creada, y activa), para crear un canal de comunicaciones seguro entre ambos. Esta fase suele denominarse fase de creación de una AS de tipo IKE. 3. Mediante esa AS IKE, ambos encaminadores negocian una AS (si no hubiera ya creada, y activa) 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.

503


Figura 16.9. Esquema de la creación de un túnel IPSec entre A y B.

Si se analiza un poco más en detalle cada paso, se podrá entender mejor la naturaleza de las asociaciones de seguridad. En el paso 1, el dispositivo IPSec (en el ejemplo, un encaminador) determina que el tráfico que se analiza es tráfico que debe ir protegido por una AS y determina si ya existe una AS de tipo IKE entre el mismo (el dispositivo IPSec) y el otro dispositivo (su extremo de la red privada virtual). Si no existe, se sigue al paso 2, en el cual, esencialmente, se llevan a cabo tres operaciones muy importantes: 1. Negociación de políticas, en la que se llega a un acuerdo en qué tipo de criptografía se va a utilizar, cómo va a ser la autenticación, tiempo de vida de la AS, etc. 2. Verificación de la identidad, por parte de cada uno de los dispositivos que usan IPSec, es decir, autenticación. 3. Puesta en marcha del algoritmo Diffie-Hellman, para obtención de claves secretas compartidas.

504


Una vez creada la asociación de seguridad IKE, y utilizando su protección, se negocian los parámetros para la asociación de seguridad IPSec, que determina las características de seguridad del tráfico de A a B y viceversa. Finalmente, el tráfico de datos IP viaja asegurado mediante IPSec. Si se quisiera, en este mismo momento, crear otra sesión entre A y B, ya existirían las dos asociaciones de seguridad necesarias y no habría que repetir todos los pasos. 5. EL PROTOCOLO PGP (PRETTY GOOD PRIVACY) Todavía hoy el único tipo de tráfico IP que genera tanto volumen, o más, de datos por las redes de todo el mundo, que el correspondiente a sistemas web, es el tráfico asociado a mensajes de correo electrónico. Es para este propósito para el que se creó PGP (Pretty Good Privacy), aunque realmente es una utilidad, más que un único protocolo, de seguridad. En cualquiera de sus versiones presentes o anteriores se puede usar, también, para proteger ficheros almacenados en disco y hay empresas, como Symantec, que han hecho PGP parte habitual de su cartera de productos. Su desarrollador inicial y creador, Phil Zimmerman, empezó su desarrollo en la mitad de la década de 1980 y la primera versión llegó en 1991. La versión 2.0 apareció en 1992 y en su desarrollo colaboraron ya programadores de todo el mundo. El código se escribió fuera de EE.UU. para poder evitar las leyes restrictivas (que llevaron a Zimmerman a varios años de juicios) existentes para los programas criptográficos, que consideraban, entonces, a este tipo de software al mismo nivel que los secretos militares y evitar, así mismo, otro tipo de problemas relativos a las patentes de RSA. La versión 2.3a aparece en 1993, muy mejorada, válida ya para varias plataformas y sistemas operativos. Con la ayuda del MIT y de RSA se desarrollaron las versiones siguientes hasta llegar a la versión 2.6.3.i, popularizada ya a nivel mundial. A finales de 1993, ViaCrypt, tras negociaciones con Zimmerman, empezó a vender una versión comercial, conocida simplemente como la versión 2.6. En 1994 el propio inventor creó PGP Incorporated, para la distribución comercial, siendo adquirida la empresa después por McAfee que, a su vez, fue absorbida por Network Associates. La historia no acaba aquí pues Network Associates devolvió en 2002 a Zimmerman el producto, que

505


volvió a ser controlado por él mediante otra empresa, PGP Corporation, a la que, además, se han ido sumando otras «personalidades» de esta industria como Bruce Schneier. Hoy en día, además de las versiones típicas, basadas en la 2.6, hay multitud de versiones para sistemas Windows, siendo la mejor idea si se quiera probar el sistema PGP acudir a la web http://www.pgpi.org/, donde se puede obtener todo tipo de información sobre las múltiples versiones. Hay múltiples implementaciones, basadas en el RFC 2440 (OpenPGPmessageformat), que asumen PGP como estándar. Aunque se ha llegado a desarrollar un entorno completo de protección de tráfico basado en PGP, 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, lo cual permite: — Tener certeza de que el documento no ha sido modificado puesto que ha sido firmado. Si se alterara el mensaje la firma no sería válida. — Verificar que el mensaje ha sido firmado por un determinado usuario. • 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. Un mensaje transformado por PGP puede ser, opcionalmente, firmado, encriptado y codificado para la transmisión, tal como se ilustra en la figura 16.10. 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. PGP soporta, también, firmas separadas, que pueden almacenarse o enviarse separadas del mensaje, lo que resulta especialmente útil si se desea que el mensaje vaya firmado por más de un participante.

506


Figura 16.10. Transformación de un mensaje PGP.

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, alcanzando aproximadamente un 50% de reducción del tamaño del fichero. Es importante señalar, asimismo, que PGP comprime los datos después de la firma, pero antes del cifrado, de forma que la firma resulta comprimida. Además, el orden es importante, ya que si se comprimieran datos encriptados, el proceso de compresión elimina parte del original, de forma que sería imposible, después, desencriptar. Obviamente, la compresión hace más fácil usar eficientemente el ancho de banda. Desde el punto de vista práctico, 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.

507


El receptor, para leer el mensaje, tiene primero que descifrar la clave de sesión usando su clave privada. Después, con esa clave de sesión, se puede ya descifrar el mensaje encriptado, para obtener el mensaje legible. Hay muchos sistemas de correo electrónico que no son capaces de hacer frente a mensajes grandes, lo que podría provocar conflictos. Para arreglar este problema, PGP puede dividir tales mensajes grandes en fragmentos o segmentos, que no tienen nada que ver y no influyen en nada a la propia fragmentación de IP. Este límite está, aproximadamente, alrededor de los 50.000 caracteres, de forma que 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. Igualmente, el ensamblaje de los fragmentos se hace, en el receptor, como primer paso de la recepción, para no impactar los procesos de descompresión, descifrado y verificación. Otro punto importante es el que concierne a la distribución de claves públicas, que se puede hacer mediante uno de los tres métodos siguientes: • Método manual. • Enviándola adjunta a un mensaje de correo. • Distribuida mediante un repositorio de claves. El primer método de distribución de claves es un ejemplo de lo que se denomina confianza directa. El hecho de que la clave te llegue en mano, de alguien, define el nivel de confianza que se puede asignar a la autenticidad de la clave. Solo los participantes mismos, o sus conocidos directos, pueden extender el nivel de confianza a un tercero, a través de referencias. Este tipo de confianza es la confianza del modelo de confianza en web. En este modelo, un participante recibe o extiende un nivel de confianza, para uno mismo, o como tercero en el que otros dos participantes confían. Este modelo de confianza en web se parece al de una autoridad de certificación, pero una AC siempre opera dentro de un modelo jerárquico de confianza y la confianza se extiende a los subordinados sólo porque son subordinados. El modelo PGP usa el modelo citado de confianza en web. Una vez se intercambian las claves, éstas se retienen en un anillo de claves (o llave-

508


ro), que, realmente, es un fichero, protegido por una palabra de paso. Hay un campo de legitimidad de clave asociado con cada clave del anillo. Este campo indica hasta qué punto el programa puede confiar en la autenticidad de la clave. Hay, también, cero o más firmas, asociadas con la clave, que, esencialmente, firman la clave y le dan una mayor legitimidad. 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. Para añadir una nueva clave pública al anillo, se debe certificar o verificar que se confía en la clave por la confianza que se tiene en el emisor. 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 con Diffie-Hellman o RSA. • Para la compresión, ZIP. Es muy importante seguir las buenas costumbres de uso para que, realmente, PGP proporcione una buena seguridad: • Es muy importante seleccionar contraseñas adecuadas. • Hay que proteger, convenientemente, los ficheros de los anillos de claves y, también, el fichero que contiene la semilla aleatoria. El tipo de protección es doble: frente a accesos no permitidos y frente a pérdida de los datos. Piénsese que si se pierde la clave privada no se puede descifrar ningún mensaje. • Al generar las claves, crear una revocación y guardarla en lugar seguro. De esa forma, se podrá revocar una clave en caso de pérdida del anillo de claves. • Aplicar bien el modelo de confianza, es decir, hay que firmar únicamente las claves de cuya autenticidad se esté completamente seguros.

509


6. CONOCIMIENTOS Y COMPETENCIAS ADQUIRIDAS En este tema hemos analizado algunos de los principales protocolos criptográficos, tanto desde el punto de vista de su estructura, como desde el punto de vista del uso que reciben. Se ha empezado analizando las características generales, y los problemas asociados, del procedimiento típico de transacciones comerciales o con las administraciones públicas por la red. Como protocolos que permiten asegurar este tipo de procedimientos se han analizado el SSL y el SET. El protocolo SSL, diseñado para conseguir seguridad a nivel de transporte en el grupo de protocolos IP, es, actualmente, un estándar de uso tanto en los clientes como en los servidores habituales. Se ha hecho un análisis de las principales características del trabajo con SSL y se han discutido una serie de problemas que el protocolo no consigue resolver totalmente. Para tratar de evitar varios de estos problemas «conceptuales» en el proceso de comercio electrónico, derivados del uso de SSL, apareció el protocolo SET, que no mejora espectacularmente la seguridad mediante nuevos algoritmos, sino que trata de mejorar el propio proceso de comercio electrónico, haciendo, por ejemplo, que la autenticación de todos los participantes en el proceso SET sea completamente obligatoria. Quizás el aspecto fundamental de SET es que hace intervenir a otras entidades (bancos o entidades financieras con las que trabajan vendedor y comprador), permitiendo que nadie conozca más que lo estrictamente necesario. Posiblemente el problema principal al que se ha enfrentado SET, y que le hace no terminar de convertirse en estándar, es el de la mayor complejidad de gestión, mayor necesidad de certificación y necesidad de uso de tarjetas inteligentes. Este tema ha analizado también IPSec, un grupo de protocolos estándar del IETF, diseñados para IPv6, portados a IPv4 y que permiten asegurar el tráfico de extremo a extremo, a nivel IP, por una red insegura. Permiten la autenticación de los extremos, la privacidad de los mensajes IP y la integridad de los datos, mediante el uso de algoritmos completamente estándar. Los protocolos IPSec (AH, ESP y KMP) son, además, modulares, permitiendo que se incorporen muy fácilmente nuevos algoritmos que hayan

510


demostrado ser suficientemente seguros, como sucedió, para ESP, con el algoritmo AES de cifrado simétrico. Finalmente se ha descrito uno de los protocolos más habituales para el aseguramiento del tráfico generado por mensajes de correo electrónico, el PGP, que utiliza el mismo tipo de algoritmos y procedimientos criptográficos que los anteriores. 7. BIBLIOGRAFÍA INTYPEDIA, INFORMATION SECURITY ENCYCLOPEDIA, enciclopedia gratuita en video, con muchas lecciones sobre algoritmos criptográficos, con la garantía de la red CRIPTORED y la Universidad Politécnica de Madrid, descargable desde http://www.intypedia.com/ PASTOR, J.; SARASA, M. A.; SALAZAR, J. L. (2010): Criptografía digital. Fundamentos y aplicaciones. Ed. Prensas de la Universidad de Zaragoza. SCHNEIER, B. (1996): Applied Cryptography. 2.ª edición. Ed. Wiley. SHARIF, L. Y AHMED, M. (2010): IPSec: A Practical Approach: Network Security. Ed. LAP LAMBERT Academic Publishing, 2010. SINGH, S. (1999): The Code Book: The Science of Secrecy from Ancient Egypt to Quantum Cryptography. Ed. Doubleday. Existe una versión «ligera» descargable gratuitamente, y en formato interactivo con ejercicios, desde http://simonsingh.net/cryptography/crypto-cd-rom/

8. PALABRAS CLAVE SSL, https, SET, IPSec, AH, ESP, KMP, IKE, ISAKMP, SPD, SAD, PGP.

9. EJERCICIOS RESUELTOS 1. ¿Cuáles son las tres características de seguridad que ofrece el protocolo SSL? a) Autenticación, intercambio seguro de claves y privacidad. b) Autenticación, integridad y, opcionalmente, privacidad.

511


c) Privacidad, intercambio seguro de claves y, opcionalmente, autenticación. d) Privacidad, integridad y, opcionalmente, intercambio seguro de claves. Solución: c. 2. ¿Cuál de las siguientes respuestas es una buena definición de una asociación de seguridad entre dos participantes en un túnel IPSec? a) Es un identificador de las direcciones IP de los dos participantes, dentro de la base de datos de seguridad IPSec. b) Es una conexión, en un solo sentido, que proporciona un cierto conjunto de servicios de seguridad a los mensajes IP sobre los que se aplican tales servicios. c) Es una medida de la seguridad de los dos extremos participantes del túnel IPSec. d) Es una entrada de la SPD, que se aplica a cualquier mensaje IP entre los participantes. Solución: b. 3. Un mensaje IPSec, asegurado por el protocolo AH, se puede considerar confidencial, al ir toda la información encriptada: a) Falso, AH no proporciona privacidad, solo integridad y autenticación de los extremos de la comunicación. b) Verdadero, AH es el protocolo IPSec que utiliza AES. c) Verdadero, pero sólo si trabaja junto a KMP. d) Falso, ningún protocolo IPSec permite tales características de seguridad. Solución: a. 4. Un anillo de claves es la herramienta imprescindible de PGP, que reside en el sitio central de autenticación, protegida por el administrador de PGP: a) Verdadero, de ahí la relevancia en el modelo PGP de este puesto de trabajo. b) Verdadero, además debe estar cifrado con la clave privada del administrador. c) Falso, puede estar desprotegido, no alterando esto nada el modelo de confianza de PGP.

512


d) Falso, el modelo básico de confianza PGP se basa en la confianza de tipo web y cada participante tiene su propio anillo de claves. Solución: d. 5. ¿En qué protocolos es obligatorio el uso de certificados digitales X.509? a) b) c) d)

En todos los protocolos de IPSec. En ninguno de los protocolos descritos. En PGP y SSL. En el protocolo SET.

Solución: d.

10. EJERCICIOS DE AUTOEVALUACIÓN 1. ¿Cuál de las siguientes es una característica típica del protocolo SSL? a) Que proporciona, de manera automática, autenticación de extremos. b) Que obliga al uso de certificados X.509 y el uso de una PKI. c) Que, desde el punto de vista de un usuario que navega por Internet, es transparente. d) Que obliga a utilizar los datos bancarios. 2. Cuando se implementa IPSec como en la figura 16.9, ¿qué tráfico asegura IPSec? a) b) c) d)

El que va del equipo A al equipo B y vicerversa. El que va del encaminador X al encaminador Z y viceversa. El que va del equipo A al encaminador Z y viceversa. Depende de la configuración de la SPD en los encaminadores.

3. ¿Cuál de las siguientes NO es una característica básica de IPSec? a) Debe usarse sólo en redes IPv4. b) Las funciones de seguridad no deben afectar a las operaciones ya existentes en la red. c) Sólo se usan algoritmos criptográficos bien establecidos y probados. d) IPSec proporciona autenticación de extremo a extremo del tráfico, en cuanto a los equipos, dejando de lado la autenticación de usuario.

513


4. ¿Mediante qué procedimiento se lleva a cabo la «firma» PGP? a) b) c) d)

Mediante RSA y X.509. Mediante un hash MD5. PGP no tiene firma. Mediante DES o 3DES.

5. ¿A qué procedimiento especial obliga el uso de ESP en modo túnel? a) b) c) d)

514

A pre-cifrar el mensaje mediante AH. Al uso de AES para la cabecera IP. Al cifrado mediante Diffie Hellman de la cabecera IP. Al establecimiento de una nueva cabecera IP del mensaje.

Tema 17

Introducción a las redes privadas virtuales

1. Introducción, orientaciones para el estudio y objetivos 2. Caracterización de las redes privadas virtuales (RPV) 2.1. Ventajas e inconvenientes de las RPV 2.2. Arquitectura y planificación de RPVs 2.3. Rendimiento, mantenimiento y seguridad 3. Configuración típica de una RPV que use IPSec 4. Redes privadas virtuales mediante SSL 5. Redes privadas virtuales mediante redes MPLS 6. Conocimientos y competencias adquiridas 7. Bibliografía 8. Palabras clave 9. Ejercicios resueltos 10. Ejercicios de autoevaluación

1. INTRODUCCIÓN, ORIENTACIONES PARA EL ESTUDIO Y OBJETIVOS Una red privada virtual (RPV), o Virtual Private Network (VPN), es, simplemente, una conexión segura creada a través de una red pública. Durante mucho tiempo si se quería comunicar dos partes separadas de una red había que alquilar una línea privada cara y construir su propia red privada. Hoy en día, la solución más barata a esta situación es que se unan utilizando una red pública como es Internet, el problema es que Internet no es una red segura, por tanto hay que construir una conexión segura si se quiere tener una comunicación segura. Las redes privadas virtuales tienen tres usos principales: • La Intranet de la organización: en este caso, una red privada virtual sirve para conectar piezas disjuntas de la misma red. Si una organización tiene varias oficinas en sitios distintos de un país, o del mundo, y cada oficina tiene su propia red física, todas estas redes físicas pueden estar conectadas a través de una RPV que se ha construido sobre Internet. En este caso, las comunicaciones seguras son, habitualmente, de red a red y, como se analiza en este tema, 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. Simplemente, parte de las redes disjuntas no pertenecen a la misma organización, sino a otras. Si se piensa en empresas, esto permite la colaboración típica, en cuanto a compartición rápida de información, entre diferentes empresas. La dificultad estriba, esencialmente, en la implementación de la política de seguridad referente a tales tipos de conexiones.

517


• 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 a causa de su trabajo, pueden hoy conectarse a su red, mediante una llamada local al proveedor de acceso a Internet local y mediante una RPV. En este caso, como se analiza en este tema, la RPV va desde el propio ordenador del usuario hasta su red. Una manera simple de pensar en una RPV es pensar que permite utilizar una «puerta falsa» de un cortafuegos (controlada correctamente por el administrador de seguridad) para entrar en la red. Con un buen control de la seguridad, las conexiones de una RPV pueden ser autenticadas y antes de entrar en la red. Pero también los atacantes pueden aprovecharse de tales «puertas falsas» para entrar donde no deben. Si se analiza en más detalle la frase «red privada virtual» se podrá remarcar varias características importantes. Es una red, un mecanismo de transmisión de datos. Es privada, lo que quiere decir que la comunicación se realiza de forma que sólo se permite a los participantes designados tomar parte en ella. Y es virtual, no es, realmente, lo que parece ser, se ha construido de forma que replique lo más posible otra cosa distinta. Una RPV (figura 17.1) es una forma de comunicación sobre redes de naturaleza pública (Internet es un gran ejemplo), pero los datos que se transmiten por ella están restringidos a participantes privados, de una manera que replica de una forma fiel a un mecanismo de transmisión privada.

Figura 17.1. Una red privada virtual.

518

INTRODUCCIÓN A LAS REDES PRIVADAS VIRTUALES

En este tema se va a hacer una exposición de cuáles son las características más relevantes de cualquier red privada virtual, atendiendo a una serie de criterios básicos, se analizarán las principales ventajas que se obtienen al introducir las RPV en cualquier configuración de redes de organizaciones, así como los inconvenientes habituales de la implementación. Posteriormente se hará una breve introducción a los componentes básicos de cualquier arquitectura RPV, poniendo énfasis en cuáles de estos componentes realizan las funciones que caracterizan a una RPV. Se expondrán también algunos de los criterios que hay que tener en cuenta a la hora de planificar y diseñar una RPV, para obtener mejor rendimiento y seguridad. A continuación se presentarán tres implementaciones posibles de una RPV. Primero se verá, con algo más de profundidad, la implementación más extendida hoy en día, que se consigue por medio del uso de los protocolos IPSec; para a continuación pasar a presentar las implementaciones correspondientes a RPVs mediante el protocolo SSL, así como RPVs a través de redes MPLS (Multi Protocol Label Switching). 2. CARACTERIZACIÓN DE LAS REDES PRIVADAS VIRTUALES Aunque el énfasis que se ponga en cada una de ellas dependerá de cada implementación, las características buscadas para una RPV son las siguientes: • Integridad de los datos. Se trata de conseguir que los datos permanezcan intactos durante la transmisión. • Privacidad de los mensajes. Se trata de conseguir que sólo los participantes en la comunicación sean capaces de entender los datos. • Autenticación de los participantes. Se trata de asegurar que sólo los participantes adecuados toman parte en la transmisión. • Control de acceso. Se trata de asegurar que los participantes autenticados tienen acceso únicamente a los datos a los que están autorizados. • Auditoria y registro de actividades. Se trata de asegurar el correcto funcionamiento y la capacidad de recuperación.

519


• Calidad del servicio. Se trata de asegurar un buen rendimiento, que no haya una degradación poco aceptable en la velocidad de transmisión. Se han analizado ya métodos, sistemas y soluciones para cada una de estas características, con la excepción de la calidad de servicio. Bastará por ahora recordar que, por ejemplo, entre IPSec o SSL y RADIUS o TACACS/+ se puede implementar, al menos en teoría, una infraestructura con todas esas condiciones. La construcción concreta de tal infraestructura se analizará más adelante en el mismo tema. Sí que hay que explorar más, antes de seguir, el concepto de calidad de servicio. Piénsese que habrá comunicaciones concretas más sensibles (que necesiten mayor seguridad) que otras. La separación de tal tráfico, con respecto al resto del tráfico, es un aspecto muy importante en cualquier implementación de una RPV. Además, podría suceder que algún tráfico necesitara cierto tipo de gestión especial, mayor ancho de banda por ejemplo. Al proceso de proporcionar esta funcionalidad y características especiales a ciertos tipos particulares de tráfico, se le denomina aplicar características de calidad de servicio y se ha estudiado con cierto detalle en el tema 12. Este control del tráfico se hace, normalmente, basándose en algún criterio que permita identificarlo. Entre tales criterios se pueden citar: • Direcciones IP fuente y destino. El criterio es de dónde parte el mensaje y cuál es su destino. • Números de puerto fuente y destino. El criterio es quién es el cliente, quién es el servidor y cuál es el servicio. • Opciones de tipo de servicio (bits TOS de la cabecera IP del mensaje). El criterio sería qué tipo de servicio (retraso, rendimiento, fiabilidad o precio) exige el emisor del mensaje. Hay también métodos alternativos consistentes en modificar la estructura de los mensajes IP, etiquetándolos de tal manera que no haga falta una gestión de nivel 3, lo cual, para redes conmutadas de nivel 2 puede mejorar el rendimiento. Tal es el caso de las redes MPLS (Multi Protocol Label Switching). Otro criterio que sirve, también, para caracterizar una RPV es preguntarse dónde empieza y dónde acaba la RPV. El punto de inicio y de final de

520


una RPV (o, más propiamente, los extremos de una RPV) 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 RPV de extremo a extremo, las funciones típicas de una RPV se implementan en el ordenador emisor y en el receptor. Antes de dejar el emisor, los datos han sido asegurados (figura 17.2) y viajan así hasta llegar al receptor. No es un caso muy extendido en las RPV actuales, pues suele considerarse que, una vez en la red propia de la organización, la transmisión en claro es segura.

Figura 17.2. Red Privada Virtual de extremo a extremo.

En el caso de las RPV intermedias (figura 17.3), que es el más habitual pues con él se implementan casi todas las Intranet y las Extranet analizadas en la introducción, los datos de la sesión dejan el emisor sin ningún tipo de formato especial, sin haber sido pasados por ninguna de las funciones comentadas y así llegan a un dispositivo intermedio (encaminador, cortafuego, etc.) que es el que va a crear el tráfico RPV y lo va a transmitir por la red insegura. Este tráfico RPV llegará a otro dispositivo intermedio en donde será tratado de manera que al aparecer en la red propia del receptor viajará, otra vez, en claro hasta llegar al receptor.

521


Figura 17.3. Red Privada Virtual intermedio-intermedio.

El caso de las RPV origen-intermedio (figura 17.4) es el de la redes usadas por los usuarios móviles. Un usuario de la red está, por ejemplo, en un hotel. A través de la conexión local a Internet va a conectarse con su red, pero no puede pensarse que el proveedor de acceso a Internet le proporcione los servicios de seguridad que necesita y que tiene configurados, siguiendo las funciones que haya pactado con su red. Por esa razón las funciones se van a implementar en su equipo (un extremo de la RPV) y en el dispositivo intermedio de entrada en su red.

Figura 17.4. Red Privada Virtual origen-intermedio.

522


Muchas compañías y organizaciones han ido cambiando durante años sus infraestructuras, de costosas líneas privadas, a redes privadas virtuales, en cualquiera de sus posibles implementaciones, y muchas veces como una combinación de ellas, a través de Internet. Las ventajas, como analiza a continuación, resultan muchas más, y más importantes, que los inconvenientes. 2.1. Ventajas e inconvenientes de las RPV Son muchas las ventajas del uso de redes privadas virtuales, siendo la primera y más evidente la posibilidad de tener acceso a los datos, de manera segura, desde cualquier lugar. Entre las ventajas más significativas se pueden citar: • Reducción de costes. Podría catalogarse ésta como una ventaja «histórica» pues ya nadie se le plantea como no sea para explicar una situación anterior. Permiten reemplazar caras líneas privadas punto a punto por líneas mucho más económicas. No solo se pueden utilizar líneas de conexión más barata, sino que además permite reducir el número de líneas necesarias. Al usar líneas dedicadas punto a punto era necesario tener un enlace dedicado entre todos los puntos de la organización, así, para conectar n sedes entre si se necesitaban n(n-1)/2 líneas dedicadas, mientras que al conectar todas ellas a través de una red pública de forma segura por medio de una RPV solo serán necesarias n líneas, una por cada sede. • Mejora de la seguridad. Recordemos que prácticamente todas las redes hoy en día utilizan la suite de protocolos TCP/IP la cual es inherentemente insegura al transportar todos sus datos en texto ASCII legible. Cualquier implementación de RPV incluirá algún tipo de soporte criptográfico, lo cual incrementará necesariamente la seguridad de las comunicaciones. • 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. Las oficinas separadas físicamente pueden operar, de manera económica, como si compartieran la misma red física.

523


• 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 simplemente cambiando la velocidad de la línea contratada para la misma. Por otro lado, será sencillo el incorporar nuevas sedes en distintas localizaciones geográficas simplemente dando de alta un nuevo nodo dentro de la RPV. • Simplificación de las operaciones. Las operaciones de administración y mantenimiento se verán simplificadas y reducidas, ya que se producirá una normalización tanto de los tipos de conexiones como de las necesidades de seguridad. Aunque son muchas las ventajas que presentan las redes privadas virtuales, estás también conllevan algunos inconvenientes, entre los que se pueden citar: • Aunque se abaratan los costes respecto a las soluciones punto a punto, su puesta en marcha supondrá gastos derivados de la compra de los nuevos equipos de la infraestructura necesaria. • Dado que los datos que viajan por una RPV lo hacen a través de una red pública, esto tiene sus riesgos de seguridad. La mayor parte de estos riesgos pueden evitarse con una buena implementación de una política de seguridad bien planificada. Hay que recordar que no basta con comprar una buena solución criptográfica, ésta debe ser usada, y usada correctamente para garantizar la 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 como es Internet habrá momentos en los que la congestión de la red repercuta negativamente sobre la velocidad o rendimiento de la RPV. Esta pérdida del control de la calidad de servicio puede ser un problema para las organizaciones que necesiten reservar un ancho de banda específico para operaciones o aplicaciones críticas. Hay que recordar también que el proceso de cifrado y descifrado son operaciones matemáticas de uso intensivo de recursos, que pueden reducir claramente el rendimiento, si los dispositivos donde se realizan tales operaciones no están bien dimensionados.

524


2.2. Arquitectura y planificación de RPVs Hay dos componentes esenciales de cualquier red privada virtual, que la hacen posible. Uno es el proceso conocido como tunneling, que hace que tal red sea «virtual» y el otro está compuesto por una serie de servicios de seguridad, que permiten que los datos de la RPV se mantengan privados. En una RPV no se mantienen enlaces permanentes, sino que se crean conexiones entre dos partes de ella, según sea necesario y, cuando ya no lo es, se rompe tal conexión, dejando el ancho de banda, y otros recursos, disponibles a otros usuarios. En tales conexiones, los proveedores de acceso a Internet y la propia infraestructura de Internet resultan ocultos, 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. En el caso de una RPV, como ya se analizó en el tema anterior, la encapsulación puede incluir cifrado y añadir una nueva cabecera IP al mensaje. En el extremo receptor, se quita la nueva cabecera IP, se descifra el mensaje si fuera necesario, y se envía el paquete a su destino. En los extremos del túnel podemos encontrar ordenadores individuales o una LAN con una pasarela de seguridad, que puede ser un encaminador o un cortafuegos. Por otro lado, los servicios de seguridad deben implementar todas las necesidades comentadas en temas anteriores, esto lleva al uso de una serie de posibles protocolos, de los que, como ya se ha analizado, el más usado, con diferencia, es el conjunto de protocolos IPSec. Desde el punto de vista de componentes, tal y como se ve en la figura 17.5, hay cuatro componentes típicos en la arquitectura de una red privada virtual: • La red Internet, o la red no segura. • Las pasarelas de seguridad. • Los servidores de política de seguridad. • Los servidores de certificación. Estos componentes no están presentes en todos los productos RPV, este ejemplo trata describir el caso más general.

525


Figura 17.5. Componentes de una Red Privada Virtual.

Además de Internet, los componentes más significativos de una RPV son lo que se denominan pasarelas de seguridad, dispositivos entre la red privada y la red pública que aseguran que no haya intrusiones no deseadas en la red privada. En este contexto, suelen ser, también, los que proporcionan las capacidades de cifrado y tunneling. En general, suelen ser encaminadores, cortafuegos o dispositivos hardware especiales para RPV. Teniendo en cuenta que los encaminadores examinan y procesan cada paquete IP, parece razonable incluir las propiedades de una RPV en ellos. Habitualmente, los vendedores de servicios RPV en encaminadores ofrecen dos tipos de productos, o bien programas añadidos o bien tarjetas especiales usualmente dedicados a la capacidad criptográfica. Esta última oferta es la mejor en situaciones para las que se necesita un rendimiento criptográfico muy alto. Por otro lado, hay muchos cortafuegos que ofrecen, como parte de sus servicios, la capacidad de RPV, como los Cisco ASA. Al igual que los enca-

526


minadores, los cortafuegos deben procesar todo el tráfico IP. En general, se puede decir que habrá que elegir con cuidado si se desea un cortafuegos como pasarela de seguridad de una RPV, pues suele estar ya muy cargado de procesos de filtrado propios de su trabajo. Otra solución posible como pasarela de seguridad es usar hardware especial diseñado para el tunneling y el cifrado. Tales soluciones permiten, además, implementar la misma solución ya sea la RPV de tipo LAN a LAN o de tipo usuarios móviles. Otros componentes significativos de una red privada virtual son los servidores de políticas de seguridad, que 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, o si va a crecer previsiblemente, 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, como en el caso de la figura 17.5, o pueden ser internas, controladas desde dentro de la propia organización administrativa de la red. El diseño y la planificación de una red privada virtual deben realizarse con mucho cuidado, pues de ello dependerá no solo la conectividad entre las distintas partes de la organización, sino también la seguridad de los datos e, incluso, el tráfico de red en cada parte de ella. Para poder diseñar una RPV hay que conocer las demandas que tendrá la RPV, qué tipo de tráfico se va a transmitir, qué aplicaciones usarán la RPV, con qué frecuencia, con qué necesidades de cifrado, etc. Muchas de estas características aparecerán, además, combinadas, pero habrá que tratar de planificarlas todas de manera unificada y lógica. Las consideraciones de diseño que suelen plantearse son: • Asuntos relacionados con la red de la que dispone la organización. • Asuntos relacionados con la seguridad del tráfico que se generará en la RPV.

527


• Asuntos relacionados con el proveedor de acceso a Internet. En este caso, esencialmente, se debe asegurar que las opciones que se vayan a utilizar están permitidas, tanto por seguridad como por rendimiento. Una de las principales consideraciones con respecto a la red es de qué capacidades disponen los dispositivos de seguridad y encaminamiento. Si están al límite, se puede plantear una de las tres situaciones siguientes: • Actualizar los encaminadores o cortafuegos, para que puedan soportar las funciones típicas de una RPV. • Cambiar los encaminadores o cortafuegos por otros más nuevos, con equipos más potentes. • Usar otro tipo de dispositivo para proporcionar los servicios RPV. Las ubicaciones típicas para colocar dispositivos de 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. Tanto en el caso de los cortafuegos como de los encaminadores se puede afirmar que son utilizables como componentes clave, como pasarelas de seguridad. El problema puede ser el rendimiento, el cual se puede ver afectado tener que realizar nuevas tareas, por ello, han ido apareciendo distintos tipos de soluciones hardware, diseñadas con el único objetivo real de servir de pasarela de seguridad de una RPV. Para poder separar más claramente las funciones, se suele hablar de una pasarela RPV como del dispositivo hardware que sólo (o principalmente) implementa las funciones de una RPV. Tales funciones se pueden resumir diciendo que tal dispositivo es el punto extremo de túneles de clientes remotos. Las pasarelas RPV tienen que hacer tunneling, cifrado, autenticación y administración de claves. Dependiendo de los protocolos que se usen (IPSec, SSL) se hará más énfasis en unas u otras funciones. Si la pasarela RPV 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, como en la figura 17.6, de forma que la pasarela procesa todo el tráfico que entra y sale a la red.

528


Figura 17.6. La pasarela RPV antes del encaminador.

De esta forma se minimiza la necesidad de reconfigurar cualquiera de los dispositivos existentes, ya que la pasarela cifra y descifra antes de entrar a la LAN, viendo los encaminadores o cortafuegos internos simplemente mensajes IP normales. Para esta configuración es importante haber decidido si se quiere que la totalidad del tráfico que entra y sale de la red interna vaya cifrado. Si no fuera así, habría que asegurarse de que la pasarela elegida permite decidir qué tráfico debe ser cifrado y cuál no. Otra opción sería disponer de una topología, como la analizada, para el tráfico que deba ir cifrado y de otra entrada a la red, por ejemplo a través de otro encaminador, para el que no deba ir cifrado. Cuando la pasarela RPV no dispone de un puerto WAN, sino simplemente de 2 o más puertos Ethernet (caso muy habitual) 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. En la primera configuración (figura 17.7) el encaminador no necesita ninguna configuración especial y puede filtrar el tráfico RPV y no RPV con las mismas reglas. Hay que hacer énfasis en la buena administración de seguridad de la pasarela al estar más allá del encaminador y hay que configurar la pasarela para dejar pasar el tráfico no RPV.

529


Figura 17.7. La pasarela RPV entre Internet y el encaminador.

Cuando se coloca la pasarela detrás del dispositivo de acceso (por ejemplo el encaminador) como en la figura 17.8, hay que configurar a éste para que deje pasar el tráfico RPV sin filtrar. Esta configuración es más segura para la pasarela, pero también implica que se tiene menos control sobre el tráfico que entra en la red interna después de ser descifrado por la pasarela. Si se quiere filtrar por dirección destino, por criterios temporales o por tipo de aplicación, por ejemplo, hay que duplicar los encaminadores (poniendo otro más entre la pasarela y la red interna) o tener una pasarela que tenga tales funciones.

Figura 17.8. La pasarela RPV detrás del encaminador.

El tercer tipo de configuración hay que utilizarla sólo cuando se esté seguro de que no importa aumentar el tráfico de la red interna pues, al colocar la pasarela como otro nodo de la red, el tráfico RPV cuenta por dos, primero hasta la propia pasarela, antes de ser descifrado, y desde la pasarela a su destino, después de ser descifrado. No parece una solución muy eficaz. La cuarta configuración, ilustrada en la figura 17.9, permite dividir el tráfico entrante, haciendo que el tráfico cifrado se envíe a la pasarela y el restante pase por el dispositivo de acceso (encaminador o cortafuegos). Es más cara, obligando a introducir nuevos elementos tanto hardware como de configuración interna y externa, pero es la más segura y la más clara desde el punto de vista de política de seguridad.

530


Figura 17.9. Topología en paralelo de la pasarela RPV.

En caso de que la RPV tenga necesidad de conectar a una gran cantidad de dispositivos de extremo y/o móviles, será necesario decidir cómo se implementará la PKI que permita manejar los certificados digitales de cada uno de los extremos de la RPV. Esto garantizará la autenticación de tales dispositivos extremos de la RPV y ha de incluir, también, a los posibles usuarios móviles de la RPV. El punto clave a decidir es si la autoridad de certificación es interna a la organización o si es una autoridad de certificación pública o, incluso, una empresa como Verisign. El último asunto importante en el diseño de toda RPV es el de la autenticación de usuarios, especialmente importante en el caso de RPVs con muchos usuarios móviles. Suele implementarse como una opción más en los extremos de la RPV que sirven de entrada a las redes internas. Sea la pasarela RPV un dispositivo dedicado, un encaminador o un cortafuegos, suele actuar como cliente de un servidor AAA, comunicándose con el (como ya se ha explicado en distintos temas) mediante uno de dos posibles protocolos AAA: RADIUS o TACACS/+. En este servidor AAA residirá la información de autenticación y de autorización, permitiendo, así, el control de acceso a las aplicaciones y datos internos, además de la autenticación mencionada. 2.3. Rendimiento, mantenimiento y seguridad Cuando se habla de redes privadas virtuales es imposible evitar el problema del rendimiento del tráfico de la red. Si los túneles RPV deben parecer transparentes a los usuarios, y a las aplicaciones, de forma que

531


toda la RPV parezca una gran red solamente, tales túneles no pueden convertirse en cuellos de botella para el tráfico de la red. En este sentido, se puede hablar de dos factores fundamentales de una RPV, que afectan a su rendimiento: • La velocidad y fiabilidad del tráfico que atraviesa Internet. • La «fortaleza» del procesado de cifrado de la RPV en los ordenadores y en las pasarelas RPV de seguridad. En Internet no hay posibilidad de garantizar tiempos de respuesta. Los proveedores de acceso que ofrecen latencias garantizadas realmente, muchas veces, cortocircuitan Internet utilizando sus propios backbones. Esto es bueno para las RPV siempre que todos los extremos utilicen el mismo proveedor solamente. Otro punto importante es ver qué proveedores ofrecen servicios diferenciados, es decir, servicios con distinta reserva de ancho de banda para distintos tráficos de aplicaciones diferentes. Hoy en día éste es un servicio ofrecido por pocos. Además, la falta de estándares realmente aceptados por toda la industria para muchos de estos servicios (audio, video, etc.), hace que los proveedores sean remisos a adoptar las técnicas necesarias. En este sentido, la solución conocida como MPLS (Multi Protocol Label Switching), previamente citada, parece ser una de las soluciones más claramente aceptadas por alguno de los principales proveedores del mundo, pero no es, aún, algo claramente establecido. Todos estos aspectos hay que tenerlos muy en cuenta a la hora de negociar el contrato con el proveedor correspondiente, así como disponer (y usarlas) de una serie de herramientas que permitirán verificar si las condiciones de rendimiento del contrato firmado se están dando o no. Entre ellas, se pueden citar: • La utilidad ping, que permite medir el tiempo de respuesta IP. • La utilidad traceroute, que permite determinar el camino que llevan los mensajes IP por la red. • El NTP (Network Time Protocol), que se usa para intercambio de mensajes de sincronización temporal.

532


• Las herramientas de gestión de red, como el OpenView de HP o el CiscoWorks, de Cisco Systems. • Analizadores de protocolos. • Los registros de aplicaciones y de sistemas. • Mensajes de prueba, creados ad-hoc por los administradores de red, para evaluar tiempos de respuesta particulares. Por otro lado, dependiendo de la potencia de cálculo de los dispositivos RPV que se utilicen y el tráfico que haya que procesar es normal tener que considerar la instalación de varias pasarelas en las conexiones que tengan un mayor volumen de tráfico e, incluso, tratar de implementar algún tipo de balanceo de carga entre ellas. En el mismo sentido conviene tener en cuenta lo ya hablado en los temas 13 y 14 con respecto al cifrado en hardware, mucho más rápido que mediante software. Es un punto a tener en cuenta el que los dispositivos RPV 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 RPV son, fundamentalmente, los de cualquier red. Por supuesto el rendimiento es uno de ellos y ya se ha considerado. 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 auditoria y de la contabilidad del uso de recursos. • Gestión de la seguridad. En una red sin RPV muchos de estos asuntos se gestionan mediante aplicaciones de gestión, que usan el protocolo SNMP, como las ya citadas OpenView o CiscoWorks, pero la naturaleza propia de muchos de los mensajes (cifrados) de una RPV hace que no siempre se pueda seguir utilizando tales aplicaciones. 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, ni desde el punto de vista de seguridad ni

533


desde el punto de vista de rendimiento y, además, sería muy caro. En otras palabras, o los datos son legibles o el equipo usado para encontrar el fallo debe ser capaz de hacerlos legibles. Por otro lado, una RPV obliga a tener personal bien formado en los extremos de la RPV, que sea capaz de reunir la información necesaria para tratar de investigar el problema que se esté analizando. Otro reto en el mantenimiento está muy ligado con la configuración y 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 y existen múltiples puntos de entrada móviles a la RPV, este problema de mantenimiento es particularmente evidente. Como ya se conoce, las claves no se generan una vez, se envían y ya está. Hay que regenerarlas y redistribuirlas continuamente. 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. La centralización de la información de claves y certificados puede también crear un problema de mantenimiento, ya que la máquina en la que se centralice dicha información será un objetivo evidente para cualquier posible atacante. Si se decide no tenerlas centralizadas, sino distribuidas, esto mejora la seguridad, al no haber un único punto de ataque, pero hace más difícil la gestión, al tener que salvaguardar la seguridad de varios equipos o varias redes. Por si todo lo anterior fuera poco no se debe olvidar los problemas normales de mantenimiento de cualquier red, que también aparecen en una RPV. Haciendo referencia a los más típicos, de más probable a menos probable, 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, más que probable, necesidad del uso de NAT. • Problemas de aplicaciones que no funcionan, que las actualizaciones tienen problemas, que no tienen el comportamiento deseado y/o el rendimiento esperado, etc. • Problemas de usuarios. Este apartado daría para escribir varios libros…

534


3. CONFIGURACIÓN TÍPICA DE UNA RPV QUE USE IPSEC Una vez analizado qué caracteriza una RPV, sus distintas arquitecturas, sus ventajas e inconvenientes, así como las consideraciones sobre rendimiento de las mismas, es momento de presentar algunas de las implementaciones de RPV que podemos encontrar. En este apartado se va a presentar la implementación de RPV más extendida hoy en día, es el caso de RPV intermedio-intermedio (ver figura 17.3) mediante el uso de protocolos IPSec (analizados en el tema anterior) en modo túnel. Se va a mostrar también un ejemplo de cómo configurar una red privada virtual de este tipo por medio de encaminadores de Cisco Systems los cuales actuarán de pasarela de seguridad entre los extremos del túnel IPSec. La figura 17.10 muestra la arquitectura de la red la de la organización que se va a usar como ejemplo de uso de una RPV IPSec. La organización tiene dos sedes que quiere conectar a través de Internet de forma que el tráfico que viaja entre sedes tenga garantizada su confidencialidad así como la integridad de los datos y la autenticación de los extremos de la RPV. Para ello va a utilizar una RPV configurada mediante IPSec.

Figura 17.10. Topología del ejemplo RPV con IPSec.

En el tema anterior se ha visto cómo se crea un túnel IPSec y se explicó el funcionamiento de los protocolos IPSec. Recordemos sin embargo que cuando se usa IPSec en modo túnel se protegerá todo el paquete IP, incluida su cabecera. El paquete se protegerá por medio del protocolo ESP, como ya se vio en el tema anterior y al mismo se le añadirá una nueva «pseudo-cabecera» con los datos de la capa de red necesarios para que se puedan entregar los paquetes de encaminador a encaminador.

535


Para ilustrar la transformación que sufren los paquetes para su envío de forma segura se puede pensar en un sencillo ejemplo. Supóngase que el PC1 de la figura 17.10 envía una solicitud de ping al PC2 que se encuentra en la otra sede de la organización. La figura 17.11 muestra toda la información de uno de los paquetes capturados antes de llegar al encaminador R1, pasarela de seguridad de esa primera sede y encargado de realizar las funciones IPSec necesarias para garantizar la seguridad de los paquetes. Como se puede apreciar en dicha captura, antes de ser protegido, la cabecera de paquete muestra que la dirección de origen del paquete es la dirección IP 172.16.0.2 y su destinatario la IP 192.168.0.20, se identifica el paquete como un paquete ICMP de solicitud de ping y se puede observar el contenido del mismo sin cifrar.

Figura 17.11. Captura del paquete mediante Wireshark, antes de ser protegido por IPSec.

536


Una vez que el paquete llega al encaminador R1, éste procederá a realizar las operaciones necesarias para enviar dicho paquete a través de Internet de forma segura hasta la otra sede. Según se haya configurado IPSec para que utilice los protocolos AH (Authentication Header) y/o ESP (Encapsulating Security Payload) el encaminador aplicará las transformaciones correspondientes al paquete. La figura 17.12 muestra el paquete transformado por el encaminador R1 una vez ha sido transformado para garantizar la integridad y privacidad del mismo. Se puede comprobar cómo el nuevo paquete tiene una cabecera IP distinta, la cual indica que el origen del paquete es la dirección IP 13.0.0.1 (dirección externa del encaminador R1) y su destino la dirección IP 23.0.0.1 (dirección externa del encaminador R2). Así mismo se puede comprobar que es un paquete ESP, con el contenido del paquete original ya cifrado.

Figura 17.12. Captura del paquete despues de ser protegido por IPSec.

537


Una vez que el paquete llegue al encaminador R2 este revertirá los cambios realizados por R1 y entregará al PC2 el paquete original generado por R1. Este modo de funcionamiento tiene la ventaja de que es totalmente transparente para los usuarios finales de la red, facilitando así la configuración de los mismos al no necesitar realizar ninguna operación adicional para su correcto funcionamiento. Visto este sencillo ejemplo, queda por revisar cómo se han configurado ambos encaminadores para establecer la pasarela IPSec y asegurar así el tráfico entre las sedes de la organización. En este caso se va a mostrar la configuración necesaria para dos encaminadores Cisco al ser los encaminadores de esta compañía posiblemente los más usados para la creación de RPVs. Para configurar el encaminador R1, el primer paso será configurar la asociación de seguridad para el intercambio de claves (protocolo ISAKMP visto en el tema anterior). Cisco usa el protocolo IKE (Internet Key Exchange), derivado de ISAKMP, para establecer la política de seguridad compartida y las claves de autenticación IPSec. Para ello será necesario crear una nueva política de seguridad (que en el ejemplo llamaremos Politica1) y a continuación establecer el tipo de función hash que se va a utilizar para el intercambio de claves (en este caso SHA) así como el algoritmo de cifrado a utilizar. Si no se indica explícitamente un algoritmo de cifrado (caso del ejemplo) se usará DES como algoritmo de cifrado, si se desea se puede modificar a AES o 3DES. Para la autenticación se podría utilizar una autoridad de certificación (CA), en este ejemplo en cambio, se indica de forma manual la clave en cada uno de los encaminadores (cono clave se usa la palabra secreto). Para ello será necesario incluir los siguientes comandos en el fichero de configuración del encaminador R1: crypto isakmp policy 1 hash md5 authentication pre-share crypto isakmp key secreto address 23.0.0.2

A continuación es necesario indicar la configuración correspondiente a los protocolos IPSec. Para ello se creará un transform-set (que en el ejemplo se ha denominado Set1) en el que se indica que se va a usar el protocolo AH (Authentication Header) para garantizar la integridad, mediante el algoritmo SHA. También es necesario especificar los protocolos de autenticación y cifrado para ESP (Encapsulating Security Payload), los cuales no tienen que ser

538


los mismos que los usados para el protocolo IKE, de hecho en el ejemplo ESP se ha configurador para que utilice sólo AES-256 para el cifrado. En este caso los comandos a incluir en el fichero de configuración del encaminador son: crypto ipsec transform-set Set1 ah-sha-hmac esp-aes 256

El siguiente paso será la configuración del crypto map (llamado Mapa con número de secuencia 1 en el ejemplo). Este «criptomapa» contendrá la información sobre la asociación de seguridad (SA - Security Asociation) con el encaminador de la otra sede de la organización. Para indicar que Mapa1 contiene la información sobre una configuración IPSec se le indicará con el argumento ipsec-isakmp dentro del comando crypto map. Dentro del mismo se indicará la dirección IP externa de R2 (mediante set peer), se indicará el tiempo que permanecerá activa la sesión (mediante lifetime), el transformset a aplicar (en el ejemplo el que se creó en el paso anterior) y la lista de acceso (AL - Access List) en la que se indica el tráfico que será cifrado (mediante match address). crypto map Mapa1 ipsec-isakmp

set peer 23.0.0.2 set security-association lifetime seconds 190 set transform-set Set1 match address 101 En el ejemplo se ha indicado un tiempo de vida de la conexión de 190 segundos, una vez pasado este tiempo será necesario «renegociar» el túnel IPSec. El motivo de indicar un tiempo relativamente corto es tratar de evitar ataques contra IPSec. Al ser renovadas las claves de la conexión cada poco tiempo un atacante tendrá menos posibilidades de comprometer la seguridad del a RPV. A continuación será necesario indicar a qué interface de red del encaminador hay que aplicar el «criptomapa» generado en el paso anterior. En este caso corresponderá al interfaz externo (correspondiente a la IP 13.0.0.1). interface Serial1/0.102 point-to-point ip address 13.0.0.1 255.255.255.0 frame-relay interface-dlci 102 crypto map Mapa1

Finalmente será necesario definir en la lista de acceso 101 el tráfico sobre el que queremos aplicar el cifrado. En este caso corresponde

539


a todo el tráfico que salga de la red 172.16.0.0/24 con destino en la red 19.168.0.0/24. access-list 101 permit ip 172.16.0.0 0.0.0.255 192.168.0.0 0.0.0.255

Nótese que esta lista de acceso (similar a las ya vistas en el tema 8) nos permitiría seleccionar con mucho detalle qué tráfico queremos que sea tratado por IPSec y cuál no. Todas las líneas de la lista que aparezcan con «permit» indican tráfico a tratar por IPSec, mientras que el tráfico que aparezca con «deny» será tráfico que circulará por la red, pero sin haber sido tratado mediante IPSec. Añadiendo estas opciones a la configuración del encaminador R1, éste estaría preparado para enviar tráfico de forma segura hasta el encaminador de la otra sede, pero hay que recordar que las asociaciones de seguridad (SA) son unidireccionales, por lo que será necesario configurar la asociación del segundo encaminador de forma similar para que la comunicación pueda tener lugar. La configuración de este segundo encaminador será igual en todos los aspectos, solo será necesario ajustar las direcciones IP indicadas para que se ajusten a las del segundo encaminador. Su configuración quedaría como sigue: crypto isakmp policy 1 hash md5 authentication pre-share crypto isakmp key secreto address 13.0.0.1 crypto ipsec transform-set Set1 ah-sha-hmac esp-aes 256 crypto map Mapa1 ipsec-isakmp set peer 13.0.0.1 set security-association lifetime seconds 190 set transform-set Set1 match address 101 interface Serial1/0.102 point-to-point ip address 23.0.0.2 255.255.255. frame-relay interface-dlci 102 crypto map Mapa1 access-list 101 permit ip 192.168.0.0 0.0.0.255 172.16.0.0 0.0.0.255

540


Como se ha visto en el ejemplo, configurar encaminadores Cisco para que funcionen como pasarelas de seguridad de una RPV no es excesivamente complicado. No obstante, la configuración mediante las herramientas de línea de comando es a veces incómoda y susceptible de errores de sintaxis que pueden llegar a ser difíciles de trazar. Las últimas versiones del sistema operativo de los encaminadores de Cisco Systems incorporan además la posibilidad de configurarlos a través de herramientas gráficas, concretamente a través de navegadores web que facilitan enormemente las labores de configuración, especialmente para los no expertos. Dentro de estas herramientas gráficas se incluyen asistentes para la configuración del encaminador, entre dichos asistentes se pueden encontrar utilidades para configurar las conexiones RVP (VPN en sus siglas en inglés) como se puede apreciar en la figura 17.13.

Figura 17.13. Asistente de los encaminadores Cisco para la creación de una RPV.

541


Gracias a este asistente es realmente sencillo e intuitivo configurar la información sobre la conexión, como se puede apreciar en la figura 17.14 en la que siguiendo los pasos indicados se puede configurar el interfaz sobre el que se va a conectar la RPV, la dirección IP del encaminador de la sede con la que va a conectar dicha RPV así como la clave a utilizar.

Figura 17.14. Asistente para configurar la información de conexión de la RPV.

Así mismo gracias al asistente es muy sencillo configurar la política de intercambio de claves IKE (Internet Key Exchange) como se puede ver en la figura 17.15 o el transform-set como se puede ver en la figura 17.16. Se puede ver un ejemplo completo de cómo usar este asistente para configurar una RPV en la dirección: http://www.cisco.com/en/US/products/ ps9422/products_configuration_example09186a0080ba1d0a.shtml

542


Figura 17.15. Asistente para configurar el intercambio de claves IKE de la RPV.

Figura 17.16. Asistente para configurar del transform-set de la RPV.

4. RPV MEDIANTE SSL Aunque la implementación más común de una RPV es por medio del uso del conjunto de protocolos IPSec para garantizar la seguridad de las comunicaciones, cada día se está extendiendo más el uso de redes privadas virtuales que usan SSL como protocolo para garantizar la integridad y privacidad del tráfico de la RPV.

543


Como se vio en el tema anterior, SSL (Secure Socket Layer) es un protocolo originalmente desarrollado por Netscape Communications para asegurar y cifrar las comunicaciones web de las aplicaciones de comercio electrónico. SSL es un estándar de Internet y se puede utilizar con los navegadores web más habituales. SSL es capaz de proporcionar autenticación, integridad y confidencialidad cliente-servidor por medio de certificados digitales Aunque, como se ha indicado, SSL se creó para asegurar el tráfico web, cada vez se está utilizando más y más para asegurar otro tipo de tráfico como puede ser SMTP, IMAP, Telnet, etc. Al igual que se puede usar SSL para asegurar estos tipos de tráfico, también es posible utilizarlo para construir túneles RPV a través de Internet. En este caso lo que se hace es utilizar SSL en vez de IPSec para cifrar las comunicaciones que, sobre dicho túnel, mantiene un usuario remoto con la red de la organización. Al usar SSL como protocolo de seguridad, el acceso del usuario es a través de un proxy o pasarela de aplicación, por lo que el cliente no se conectara directamente a la red de la organización, sino que lo hará a través de dicha pasarela. Adicionalmente, 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, lo que va a permitir al administrador controlar no solo la dirección IP interna sobre la que se produce la conexión, sino también la aplicación accedida. El uso de RPVs por medio de SSL presenta una serie de ventajas sobre las RPVs que utilizan IPSec, que merece la pena destacar: • No es necesarios usar clientes RPV: Normalmente, cuando se usa IPSec, en el caso de conexiones origen-intermedio (ver figura 17.4), en las que un usuario remoto o móvil trata de acceder a la red de la organización a través de su conexión a Internet, el usuario necesitará tener instalado en su equipo algún tipo de software cliente que le permita conectar y crear un túnel seguro con la red de su organización. Este software tiene que ser instalado y configurado en todas y cada una de las máquinas clientes a las que se quiera dar acceso remoto por este medio. El coste de despliegue de los clientes, añadido a la complejidad de mantenimiento de los mismos hace de las soluciones RPV a través de SSL una opción realmente atractiva, ya que en estos casos no es necesario instalar ningún tipo software cliente.

544


En el caso de RPVs sobre SSL el usuario remoto solo necesitará tener instalado en su terminal un navegador web para poder acceder a la RPV de la organización. Todo el proceso de cifrado y descifrado SSL en el lado del cliente será realizado por el módulo SSL del navegador web, lo cual no requerirá de ningún tipo de configuración por parte de los administradores de la organización. • Reducción de problemas de interoperabilidad: Es raro que se produzcan problemas de interoperabilidad entre el cliente y el servidor SSL. En el caso de IPSec, aun siendo una serie de estándares de Internet, sigue habiendo problemas de interoperabilidad de sistemas. • Desaparición de problemas relacionados con cortafuegos: Uno de los grandes problemas para los clientes RPV-IPSec se produce cuando el tráfico generado debe atravesar algún tipo de cortafuegos. Este tipo de tráfico suele tener problemas cuando deben atravesar dispositivos NAT y además la gran mayoría de cortafuegos incorporan reglas que bloquean el tráfico IPSec. Al usar SSL todos estos problemas desaparecen. El tráfico SSL no tiene ningún tipo de problemas cuando debe atravesar dispositivos NAT y dado que SSL es un protocolo altamente extendido y útil en Internet los cortafuegos normalmente dejan pasar este tipo de tráfico sin ningún tipo de problemas. • Control de acceso más granular: Como ya se ha comentado, el tráfico SSL corresponde con tráfico del nivel de aplicación, lo que va a permitir asegurar que los usuarios remotos solo tengan acceso a aquellas aplicaciones específicas para sus necesidades, algo que es realmente difícil de conseguir cuando se utiliza IPSec. Pero, ¿cómo funciona una red privada virtual por medio de SSL? Los túneles RPV-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. La figura 17.17 muestra la arquitectura estándar en este tipo de soluciones, así como los pasos del proceso de conexión desde el punto de vista del usuario.

545


Figura 17.17. Proceso de conexión RPV-SSL.

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 RPV-SSL (que puede ser también el propio cortafuegos) por medio de una conexión https, para ello solo deberá indicar la dirección del sitio web. En ese punto el portal de acceso pedirá al usuario que introduzca sus credenciales de autenticación (sean estas una combinación de usuario y contraseña, certificados, etc.). • Fase 2 y 3: La pasarela RPV remite las credenciales de autenticación del usuario al servidor de autenticación, el cual le responderá autorizando o negando el acceso. La mayoría de las soluciones RPV-SSL disponibles son capaces de soportar distintos métodos de autenticación, lo que hace sencillo integrar dichas soluciones con los servidores de autenticación de la organización (normalmente un controlador de directorio activo o un directorio LDAP). • Fase 4: Una vez que el usuario ha sido autenticado, la pasarela de la RPV le mostrará la lista de aplicaciones a las que el usuario puede acceder con su cuenta, ya que cada usuario podrá tener acceso a aplicaciones distintas. Otra posibilidad en este punto es que, una vez que el usuario se ha autenticado directamente, se abra la aplicación a la que tenga acceso sin darle ningún tipo de opción. Como se puede ob-

546


servar, la gestión del acceso a los recursos en el caso de redes privadas virtuales por SSL se produce a nivel de aplicación, el usuario tendrá acceso a un determinado número de aplicaciones, mientras que en las implementaciones VPN con IPSec el acceso es a un segmento de red concreto. • 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, lo que implica que el cliente estará conectado con dicha pasarela y ésta redirigirá las peticiones del cliente a los servidores de aplicación. Dependiendo de la naturaleza de la aplicación, la comunicación se establecerá en uno de los tres modos posibles: i.

Pasarela invertida (Reverse Proxy): Cuando la aplicación accedida por el usuario sea algún tipo de aplicación web, el cliente enviará a la pasarela la petición http, la cual será retransmitida (una vez descifrada por la pasarela) al servidor de aplicaciones web correspondiente. La respuesta de este ultimo la recibirá la pasarela de aplicación, la cual la cifrará y la enviará por el túnel SSL al cliente.

ii. Redirección de puertos: Cuando el cliente accede a aplicaciones que no son aplicaciones web, éste no puede utilizar el navegador web, ya que en este caso el tráfico generado no será tráfico web estándar. Cuando el usuario seleccione una aplicación de este tipo automáticamente se descargará un applet que permitirá capturar el tráfico generado por el cliente y reenviarlo por la pasarela SSL. Si por ejemplo el cliente ha seleccionado el uso de Telnet a través de la RPV-SSL, el applet descargado capturará el tráfico dirigido al puerto 23 y lo redirigirá al túnel SSL. Cuando el tráfico llegue a la pasarela de aplicación esta desencapsulará el tráfico original y lo remitirá al servidor de destino. iii. Encapsulación de nivel 3: En este modo de funcionamiento el usuario obtiene acceso completo al nivel 3 (nivel de red) de la red de destino, igual que sucedía en el caso de RPVs por medio de IPSec. Cuando el usuario selecciona esta opción se instalará automáticamente en el equipo del cliente un adaptador de red virtual. Este adaptador tendrá una dirección IP de la red de destino y permitirá acceso completo a la misma. La ventaja en este caso

547


es que el usuario no necesita tener preinstalado el adaptador de la RPV, ya que este se instalará automáticamente cuando sea necesario. El problema asociado es que esto solo será posible si el usuario tiene permisos de administrador sobre la máquina desde la que está tratando de acceder a la RPV. Como se ha visto, este tipo de RPVs son muy adecuadas para permitir el acceso de usuarios remotos a la red de la organización, ya que basta con que estos tengan un navegador web instalado y sus credenciales de acceso. Pero esta misma simplicidad tiene también sus riesgos de seguridad, los que podemos agrupar en tres grandes grupos: • Integridad de los dispositivos remotos: Los equipos usados para acceder de forma remota a la RPV no serán controlados por los administradores de la organización, ya que no necesitan ningún tipo de instalación o configuración por su parte. Aunque esto simplifica el despliegue de la RPV, es a su vez un riesgo, ya que esos terminales podrían no estar protegidos contra virus, troyanos, gusanos y otros tipos de código malicioso, lo cual puede suponer un grave riesgo para la red a la que se conecte de forma remota. • Historial del navegador del equipo remoto: El navegador del equipo remoto que acceda a la RPV-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 (historial de URLs, cookies, applets…) puede ser muy valiosa para un atacante con acceso a dicha máquina. Por esta razón muchas de las pasarelas RPV-SSL incluyen funcionalidad que les permiten borrar la mayor parte de esta información una vez que el usuario termina la sesión remota. • Acceso al portal: Para acceder a este tipo de RPVs solo es necesario conocer la URL de la pasarela de aplicación. Al no necesitar tener instalado ningún tipo de software adicional estos portales de aplicación son susceptibles a ataques de fuerza bruta de contraseñas. Este riesgo no obstante se puede mitigar mediante el uso de métodos de autenticación más fuertes, como puede ser el uso de combinaciones de contraseña y certificados. Hay que resaltar que si bien las soluciones RPV-SSL pueden simplificar enormemente el despliegue para clientes remotos, su uso no puede reem-

548


plazar el uso de IPSec en muchos casos. En ese sentido hay que tener en cuenta las siguientes consideraciones: • RPV-SSL solo es válido para el caso de usuarios remotos, es decir para conexiones tipo origen-intermedio (figura 17.4). Para conexiones intermedio-intermedio (figura 17.3) será necesario utilizar soluciones RPV sobre IPSec. • Aunque es posible proporcionar acceso de nivel 3 (nivel de red) con este tipo de soluciones, este tipo de acceso no es simple pues, como ya hemos comentado, el usuario remoto deberá disponer de privilegios de administrador sobre el termina remoto para instalar el adaptador de red virtual necesario. • Las soluciones RPV-SSL son caras comparadas con el coste de las RPV sobre IPSec. Por tanto, será necesario estudiar cada caso concreto para determinar qué tipo de RPV se adapta mejor a las necesidades de cada caso. Aunque no se va a analizar ninguna solución concreta de este tipo de RPV, hay que decir que hay gran cantidad de soluciones de este tipo, la mayoría de las cuales se comercializan en forma de appliances, como puede ser la serie de appliances SRA de Dell que incorporan la solución Dell SonicWall Secure Remote Access, o la serie de appliances ASA 5500 de Cisco Systems. Estos appliances son equipos que proporcionan gran cantidad de funciones, siendo normalmente su principal función la de encaminamiento, pero proporcionando también funciones adicionales como la de cortafuegos o, en este caso, la de pasarelas de seguridad SSL. 5. RPV A TRAVES DE REDES MPLS (MULTI PROTOCOL LABEL SWITCHING) Las redes MPLS (Multi Protocol Label Switching) son un tipo de redes privadas de comunicación, ofrecidas por las principales empresas de comunicaciones, que tienen la peculiaridad de que utilizan etiquetas de nivel 2 de OSI para tomar las decisiones de encaminamiento. El protocolo MPLS permite encaminar paquetes de cualquier protocolo de red gracias a dichas etiquetas y fue desarrollado a finales de los noventa para permitir a los encaminadores tomar decisiones de encaminamiento rápidas.

549


Las redes IP tradicionales son redes sin conexión, cuando se recibe un paquete el encaminador determina el próximo salto en función de la dirección IP de destino y su propia tabla de encaminamiento. Dichas tablas de encaminamiento contienen información sobre la topología de red y son obtenidas por el encaminador gracias a una serie de protocolos IP como son OSPF, BGP, RIP, etc. o pueden haber sido construidas de forma manual por el administrador. Dado que dichas tablas de encaminamiento son continuamente actualizadas por los encaminadores, puede suceder que dos paquetes de la misma conexión, con la misma dirección de origen y destino, sigan distintas rutas. Las redes MPLS también utilizan las direcciones IP para identificar el destino de los paquetes así como los encaminadores y conmutadores intermedios, haciéndolas compatibles con las redes IP tradicionales. Pero, a diferencia de las redes IP tradicionales, las redes MPLS son orientadas a conexión y los paquetes son transmitidos a través de rutas preconfiguradas, o LSPs (Label Switching Paths), en función de las etiquetas asignadas a los paquetes. El funcionamiento de las redes MPLS se basa en el etiquetado de paquetes. Cuando el conmutador MPLS recibe un paquete, examinará la etiqueta del mismo para determinar 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. Para cada uno de los saltos que da un paquete hasta llegar a destino se usará una etiqueta diferente, dicha etiqueta, como ya se ha comentado, será asignada por el conmutador que realiza la operación de retransmisión. Este modo de funcionamiento permite utilizar sencillas y rápidas decisiones de encaminamiento, las cuales en muchos casos se implementan en el hardware del conmutador. Cuando un paquete debe atravesar una red MPLS y llega a su primer conmutador, éste examinará el paquete para determinar que LSP usar. Una vez dentro de la red los diferentes saltos se determinarán exclusivamente por la etiqueta asignada en el conmutador anterior. El funcionamiento de las redes MPLS presenta una serie de ventajas para las siguientes aplicaciones: • Redes privadas virtuales (RPV).

550


• Calidad de servicio (QoS - Quality of Service). • Transporte sobre MPLS. Como se ve, las redes MPLS son infraestructuras especialmente atractivas para proporcionar redes privadas virtuales. En este caso la RPV se basa no en un protocolo o protocolos de cifrado para encapsular la comunicación, como sucedía en los dos casos anteriores, sino en la estructura propiamente dicha de la red. Hay tres tipos de RPVs sobre MPSL: • RPVs de nivel 3: En este tipo de redes privadas virtuales el proveedor del servicio participa en el encaminamiento de nivel 3 del cliente. Este tipo de RPVs son especialmente atractivas para clientes que deseen que sea el proveedor de servicios quien aporte la experiencia técnica para el funcionamiento eficiente de su red privada virtual y son a las que normalmente nos referimos cuando se habla de RPV-MPLS. En este tipo de redes el encaminador del cliente intercambiará rutas con el encaminador del proveedor del servicio. Los encaminadores del proveedor del servicio constituyen backbone o núcleo de la red de área amplia (WAN) proporcionada. Los encaminadores en cada sede del cliente (CE - Client Edge) intercambiarán rutas, cada uno de ellos, con un solo encaminador del proveedor (PE - Provider Edge). • RPVs de nivel 2: En este caso el proveedor de servicios interconecta las distintas sedes del cliente a través de tecnología de nivel 2 (capa de enlace), como puede ser ATM, Frame Relay o Ethernet. Este tipo de RPVs son especialmente atractivas para aquellos clientes que quieran mantener el control de su propio encaminamiento de nivel 3. • LANs Privadas Virtuales (VPLS - Virtual Private LAN Service): En este tipo de soluciones 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. Los proveedores de servicios utilizan sus redes MPLS para dar servicio a gran cantidad de clientes, por lo que el tráfico de los diferentes clientes viajará físicamente por la misma red aunque a nivel lógico lo haga por diferentes circuitos virtuales. Será responsabilidad del proveedor de servicios asegurar el tráfico de las redes privadas de cada uno de sus clientes de forma que:

551


• Dos clientes que usen RPVs de nivel 3 no deberán poder ver los prefijos o rango de red del otro. De hecho, los rangos de red se podrían solapar (por ejemplo ambos podrían utilizar el rango de direcciones 192.168.0.0) y en cambio el proveedor del servicio deberá mantener sus flujos de paquetes independientes. • En el caso de RPVs de nivel 2 los diferentes clientes no deberán poder ver las direcciones de nivel 2 de los otros clientes. • Por último, en el caso de VPLS, aunque los clientes vean la red del proveedor del servicio como un gran conmutador, cada uno de ellos deberán vera la red como un conmutador virtual distinto, no pudiendo acceder el uno al tráfico del otro. 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. A efectos prácticos, el proveedor del servicio creará un LSP (Label Switching Path) 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. En el encaminado del proveedor (PE) del otro extremo se eliminará la cabecera MPLS y será entregado al encaminador cliente de la otra sede para que éste lo entregue al destinatario final. Las redes privadas virtuales sobre MPLS son mucho más flexibles y con mejor relación coste-rendimiento que otro tipo de tecnologías de área extensa (WAN) como son las líneas T1. No solo son capaces de proporcionar

552


servicios de RPV, sino que son capaces de proporcionar también funcionalidad de calidad de servicio (QoS), permitiendo contratar con el proveedor de servicios los niveles de servicio necesarios en cada caso, permitiendo así asegurar el rendimiento y ancho de banda necesarios para aplicaciones críticas, algo que no se puede realizar con el resto de implementaciones de redes privadas virtuales vistas en este tema. Pero no todo son ventajas. 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 al ser dicho proveedor el que gestiona el núcleo de la red de la organización. Las dos implementaciones de RPV vistas en los apartados anteriores son soluciones que se pueden implementar sobre cualquier tipo de línea de conexión a Internet. Incluso las distintas sedes podrán tener diferentes tipos de líneas o proveedores de acceso a Internet distintos, ya que la RPV se construye por medio de las pasarelas de seguridad a través de esa red global. En cambio, en el caso de RPVs a través de redes MPLS, éstas deberán ser proporcionadas por un único proveedor de servicios, el cual deberá facilitar conexión a su red MPLS a todas las sedes que se quieran interconectar. Como ya hemos comentado anteriormente, este tipo de RPVs no dependen de una serie de protocolos de cifrado para asegurar el tráfico entre los extremos de la RPV sino del propio funcionamiento de la red. La conclusión, tras ver las distintas implementaciones disponibles para la creación de redes privadas virtuales, es que no hay un único tipo de RPV mejor o ideal para todas las situaciones. En cada caso será necesario estudiar las necesidades de la organización para determinar el tipo de RPV a desplegar.

553


6. CONOCIMIENTOS Y COMPETENCIAS ADQUIRIDAS En este tema se ha tratado de mostrar un amplio abanico de características, funcionalidades y problemas en torno a las redes privadas virtuales así como una presentación de algunas de sus implementaciones. Se ha definido una red privada virtual como un enlace seguro a través de una red pública insegura y se han analizado las principales características que son deseables para cualquiera de ellas: integridad, autenticación, privacidad, control de acceso, calidad de servicio, etc. Es el momento de recordar que casi todas ellas se implementan poniendo en marcha sistemas que usan protocolos criptográficos que, a su vez, utilizan algoritmos criptográficos ya analizados a lo largo de este libro. Se han analizado distintos criterios que permiten decidir cuál es el tráfico que se desea cifrar, de una u otra manera, a través de la RPV, como las direcciones IP destino o las aplicaciones cliente servidor que deben cifrar su tráfico. Igualmente se han analizado los tipos de RPV en cuanto a dónde se realiza el cifrado, asociando cada tipo con el uso más habitual que se hace de la RPV correspondiente. Se han expuesto las ventajas que puede obtener una organización al implementar una RPV, entre las que conviene volver a destacar la flexibilidad y escalabilidad de la solución y, sobre todo, la rebaja de costes y la mayor seguridad que se puede obtener con una implantación y configuración correcta de una RPV. Entre los inconvenientes, también analizados, es destacable el hecho de la perdida de la calidad de los servicios, aspecto que puede sufrir un cambio a mejor en breve, por la importancia económica que empiezan a tener las RPV para empresas como las que se dedican a proveer de acceso a Internet a todo tipo de organizaciones. Se han analizado los distintos componentes de una RPV, señalando como puntos clave qué elementos se usan como dispositivos, o pasarelas de seguridad, por ser, habitualmente, los puntos de «implantación» de la política de configuración de la RPV. También es importante señalar el auge cada vez mayor de distintos tipos de «clientes» RPV, programas o disposi-

554


tivos que hacen que cualquiera, con un ordenador, desde cualquier lugar pueda conectarse a su red interna, a través de una RPV. Se han detallado los condicionantes de diseño más habituales, sobresaliendo, entre otros, la ubicación en la topología de la pasarela RPV, en cualquiera de sus posibles variedades (encaminador, cortafuego o dispositivo RPV especializado), y la necesidad de plantearse un control seguro de los certificados a través de su PKI externa o interna. Se han expuesto algunos de los principales problemas de implementación de una RPV, relacionados con el rendimiento, la seguridad y, en general, el mantenimiento de la red que, no por ser una RPV, deja de ser una red y de tener los problemas típicos de cualquier red. A continuación se ha presentado la configuración típica de una RPV que asegura el tráfico entre sedes de la organización por medio del uso de IPSec como protocolos criptográficos. Se ha visto también cómo funcionan las RPVs que usan SSL como protocolo para asegurar dicho tráfico. Finalmente, se ha explicado el funcionamiento de una RPV a través de una red MPLS. Para acabar el tema se puede hacer una reflexión: teniendo en cuenta las ventajas para los usuarios y teniendo en cuenta el crecimiento exponencial de la necesidad de soluciones RPV, se puede concluir que las redes privadas virtuales son la estructura de administración de redes que más hay que conocer para trabajar en el mundo de las redes y de la que más pendiente (en cuanto a sus cambios) hay que estar, por ser de evolución constante y rápida. 7. BIBLIOGRAFÍA CRAWLEY, D. R. (2012): Cisco Router Step-by-Step Configuration Guide (Volume 1). Ed. soundtraining.net. CISCO SYSTEMS (2010): Cisco VPN Aministrator Guide, Release 5.0. Ed. Cisco Systems. http://www.cisco.com/en/US/docs/security/vpn_client/cisco_ vpn_client/vpn_client500_501/administration/5vcA.pdf CISCO SYSTEMS, Sitio web oficial de Cisco Systems. http://www.cisco.com STEINBERG, J. (2005): Understanding SSL VPN. Ed. Packt Publishing.

555


8. PALABRAS CLAVE IPSec, MPLS, RPV, RPV-IPSEC, RPV-MPLS, RPV-SSL, SSL, VPLS, VPN, VPN-IPSEC, VPN-MPLS, VPN-SSL. 9. EJERCICIOS RESUELTOS 1. ¿Cuál de las siguientes es una buena definición de una RPV? a) b) c) d)

Es una conexión privada segura a través de una red pública insegura. Es una conexión segura pública, a través de una red MPLS. Es una conexión privada a través de una red pública segura. Es una red pública segura insertada en una red pública insegura.

Solución: a. 2. Todo el tráfico que circula por la parte pública de una RPV debe ir completamente cifrado. a) Verdadero, es la razón de ser de una RPV. b) Falso, hay que configurar, siguiendo la política de seguridad, los criterios que permitirán decidir que tráfico se cifra y cual no. c) Falso, solo el que va de participante a participante de la RPV. d) Verdadero, por eso es tan costoso de implementar. Solución: b. 3. Un programa cliente RPV cualquiera, instalado en un portátil, permite, en cualquier caso, conectar a través de Internet con la pasarela RPV de la red interna de la organización. a) Verdadero, por eso es un cliente RPV, crea un túnel con la pasarela. b) Verdadero, los clientes RPV son, en realidad, universales. c) Falso, depende de los protocolos que se usen y de su configuración concreta. d) Falso, depende de que haya abierto un túnel en la pasarela. Solución: c. 4. Si se utiliza el grupo de protocolos IPSec como base criptográfica de una RPV, ¿qué características adicionales de seguridad hay que tener en cuenta, no soportadas por IPSec?

556


a) b) c) d)

La calidad de servicio el tráfico de las aplicaciones. La integridad de los mensajes. La autenticación de los dispositivos. La autenticación de los usuarios.

Solución: d. 5. ¿Cuál es la razón para tener que considerar el uso de una PKI en la implementación de una RPV? a) Ninguna en especial, toda RPV debe considerar el uso de PKI. b) El número de equipos en cada red interna conectada a la RPV. c) El número de pasarelas RPV y de ordenadores móviles que se vayan a conectar, que obliga a la administración de gran número de certificados X.509. d) Las obligaciones legales al respecto para el comercio electrónico. Solución: c. 10. EJERCICIOS DE AUTOEVALUACIÓN 1. Las redes privadas virtuales mediante SSL son de especial utilidad cuando se quieren establecer conexiones intermedio-intermedio entre las sedes de la organización. a) Verdadero, ya que al no requerir de instalación ni configuración especial hacen que su instalación sea muy sencilla. b) Verdadero, ya que proporcionan conexión a nivel de la capa de aplicación. c) Falso, ya que para proporcionar acceso de nivel 3 a la red de destino es necesario instalar agentes en los clientes. d) Falso, dado que las RPVs mediante SSL no son capaces de interconectar redes completas, solo son capaces de proporcionar conexiones origen-intermedio. 2. ¿Qué parámetros de configuración definen el transform-set de una pasarela de seguridad de Cisco Systems? a) La configuración necesaria para el protocolo IKE de intercambio de claves. b) La lista de acceso a la que se aplicará el cifrado y encapsulamiento.

557


c) La configuración necesaria para los protocolos AH y ESP que permitirá asegurar la integridad y confidencialidad de las comunicaciones a través del túnel IPSec. d) Ninguna de las anteriores. 3. En el caso de RPVs mediante IPSec. ¿Quién realiza las labores de cifrado y encapsulación? a) El proxy de aplicación. b) Un applet que se instala de forma automática en el cliente. c) Los encaminadores o pasarelas de seguridad situados en cada una de las sedes de la organización. d) No es necesario, la seguridad la proporciona el propio funcionamiento de la red subyacente. 4. Señale la afirmación correcta referente a las RPVs sobre redes MPLS. a) Este tipo de redes privadas virtuales son capaces de proporcionar integridad y confidencialidad sin necesidad de utilizar algoritmos criptográficos. b) Además de las funciones necesarias para construir redes privadas virtuales permiten a su vez ofrecer funciones de calidad de servicio (QoS). c) El tráfico en este tipo de redes se etiqueta al entrar en la red MPLS para identificar el LSP (Label Switching Path) que debe seguir. d) Todas las anteriores son correctas. 5. Señale cuál de las siguientes afirmaciones NO es correcta. a) El uso de redes privadas virtuales mediante SSL permite a los usuarios remotos acceder a las aplicaciones de la organización sin necesidad de instalar ningún software cliente o configuración especial. b) El acceso a las redes privadas virtuales mediante SSL se controla mediante el protocolo ISAKMP. c) Las redes privadas virtuales mediante MPLS permiten al proveedor de servicios ofertar ciertas garantías de rendimiento y ancho de banda en tales redes. d) Las redes privadas virtuales mediante SSL pueden no solo dar acceso a las aplicaciones publicadas por la pasarela de la RPV sino proporcionar también acceso completo de nivel 3 (capa de red) a la red de destino.

558

Tema 18

Introducción a la seguridad de Redes Inalámbricas

1. Introducción, orientaciones para el estudio y objetivos 2. Redes inalámbricas. Conceptos básicos 3. Teoría de ataques a redes inalámbricas 3.1. 3.2. 3.3. 3.4.

Problemas de autenticación, privacidad e integridad Ataques. Fase de reconocimiento Tipos de ataques Ataques a clientes de redes inalámbricas

4. Medidas no criptográficas para proteger redes inalámbricas 4.1. Principios de diseño seguros para redes inalámbricas 4.2. Malas defensas no criptográficas 4.3. Buenas defensas no criptográficas 5. Medidas criptográficas para proteger redes inalámbricas 5.1. WEP (Wired Equivalent Privacy) 5.2. WPA (Wi-Fi Protected Access) 5.3. WPA2-Enterprise con arquitectura de Certificados digitales 6. Conocimientos y competencias adquiridas 7. Bibliografía 8. Palabras clave 9. Ejercicios resueltos 10. Ejercicios de autoevaluación

1. INTRODUCCIÓN, ORIENTACIONES PARA EL ESTUDIO Y OBJETIVOS Desde su introducción las redes inalámbricas han pasado a ser una tecnología ubicua, usada tanto en el ámbito empresarial como el personal. Una simple búsqueda con nuestros dispositivos móviles en cualquier entorno urbano nos mostrará una gran cantidad de redes inalámbricas disponibles, dándonos una clara idea de la penetración y la popularización de dicha tecnología. Uno de los factores que más ha contribuido a la rápida penetración de esta tecnología ha sido la facilidad de uso de la misma respecto a las tradicionales redes cableadas. Pero esa facilidad de uso es a la vez un punto de preocupación respecto a la seguridad, ya que cualquiera pueda usar la tecnología pero solo unos pocos son conscientes de los verdaderos riesgos de seguridad que esta puede llegar a implicar. Un punto de especial preocupación es el hecho de que el uso de redes inalámbricas amplia nuestro perímetro de seguridad enormemente, de hecho, en muchos casos, lleva el perímetro de nuestra red hasta el exterior de las organizaciones, siendo por tanto muy difícil controlar quien está dentro del rango de acción de una red inalámbrica. Durante el presente tema se pretende hacer una pequeña introducción a los problemas de seguridad de presentan las redes inalámbricas, así como las diferentes medidas y protocolos que podemos utilizar para mitigar dichos riesgos. Los objetivos de este tema son que el alumno: • Entienda los riesgos a que son susceptibles las redes inalámbricas. • Conozca la taxonomía de los tipos de ataque que se pueden producir sobre este tipo de redes.

561


• Conozca los protocolos y medidas que puede utilizar para reducir o eliminar dichos riesgos. • Conozca la diferente efectividad de cada uno de esas medidas de seguridad. Para ello, se inicia el tema haciendo un pequeño repaso a algunos conceptos básicos sobre redes inalámbricas para posteriormente explicar los diferentes riesgos de seguridad y los ataques a que son susceptibles y por último se presentan las contramedidas disponibles.

2. REDES INALÁMBRICAS. CONCEPTOS BÁSICOS Antes de entrar a analizar los riesgos de seguridad de las redes inalámbricas y sus soluciones se hace necesario repasar algunos de los conceptos básicos de esta tecnología.

2.1. 802.11 a/b/g/n 802.11 es el nombre del grupo de trabajo del Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) encargado de definir estándares (ver tabla 18.1) para las redes de área local inalámbricas. Tabla 18.1. Estándares 802.11 Estándar

Frecuencia

Velocidad

Compatibilidad PSK

802.11ª

5 GHz

54 Mbps

—

802.11b

2.4 GHz

11 Mbps

—

802.11g

2.4 GHz

54 Mbps

802.11b

802.11n

2.4 GHz/ 5 GHz

100 Mbps

802.11b, 802.11g

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 utilizada, así como la

562

INTRODUCCIÓN A LA SEGURIDAD DE REDES INALÁMBRICAS

compatibilidad o no con versiones anteriores que implica si el nuevo protocolo será compatible con las medidas de seguridad utilizadas por protocolos de versiones anteriores. Hay que tener en cuenta que determinadas herramientas solo funcionarán para un estándar específico. Así, herramientas diseñadas para funcionar con el protocolo 802.11b podrían no funcionar con el 802.11a o incluso con el 802.11g. 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 a directamente entre sí, mientras que en el segundo modo los clientes se conectan a la red a través de un punto de acceso. Los puntos de acceso son un componente vital para la escalabilidad de las redes inalámbricas. La función básica de los puntos de acceso es conectar tecnologías diferentes (redes cableadas y redes inalámbricas) entre sí. Desde su introducción los puntos de acceso han pasado a ofrecer cada vez más funciones así como formas cada vez más sencillas de configuración. Desde el punto de vista de la seguridad, tanto las nuevas funcionalidades como las nuevas formas de configuración son un punto de riesgo inherente. Por un lado los diferentes modos de configuración disponible pueden presentar distintos puntos de vulnerabilidad para un atacante, y por otro lado, la cada vez mayor complejidad del punto de acceso hace que el riesgo de una configuración incorrecta del mismo sea mayor. 2.3. SSID, BSSID, dirección MAC El SSID, BSSID y la dirección MAC son identificadores esenciales en un 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.

563


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 (SSID, tipo de encriptación, etc.). Los puntos de acceso normalmente permiten desactivar la emisión del SSID. De todas formas esta opción no va a evitar que un atacante pueda llegar a obtener el SSID de la red. 2.5. Encriptación Las redes inalámbricas, al igual que otro tipo de redes, usan la encriptación para ocultar el contenido de una comunicación, de forma que solo los usuarios autorizados pueden ver el contenido real de la comunicación. Hay múltiples opciones para encriptar el tráfico de red. Algunas de ellas han sido desarrolladas específicamente para redes inalámbricas mientras que otras se desarrollaron para otras tecnologías aunque pueden ser usadas también por las redes inalámbricas. 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. Hay que tener en cuenta que los datos transmitidos por este medio viajan a través del aire y son susceptibles de ser interceptados por cualquier atacante. Muchas de las técnicas de ataque usadas contra redes inalámbricas se han utilizado durante años para atacar redes cableadas. Estos ataques cobran ahora nueva vida al poder ser realizados desde la distancia y de forma completamente anónima en la mayoría de las ocasiones. 3.1. Problemas de autenticación, privacidad e integridad Al igual que con las comunicaciones realizadas a través de redes cableadas, en las comunicaciones a través de redes inalámbricas debemos

564


preocuparnos por la autenticación de usuarios de la red así como de asegurar la privacidad e integridad de las comunicaciones. Debido a la tecnología inalámbrica, el perímetro de las redes se ha difuminado e incrementado considerablemente, llegando en muchos casos a traspasar las barreras físicas de nuestra organización. En este escenario es más necesario que nunca autenticar a los usuarios que acceden a la misma, ya que cualquiera puede estar en el rango de la red inalámbrica de la organización y acceder a la misma, con el riesgo que esto supone para la información de la organización. Recordemos que autenticar a un usuario es básicamente hacerle probar que es quien dice ser, así como que es un usuario con autorización para conectar a la red. Este proceso normalmente se realiza mediante el conocimiento de «algo» que solo alguien autorizado debería conocer, como por ejemplo una contraseña. Los métodos de autenticación usados más comúnmente en redes inalámbricas son: • Clave WEP. • Clave compartida WPA. • Autenticación contra una base de datos centralizada. Como ya se ha comentado, los datos de las comunicaciones inalámbricas viajan por el aire siendo susceptibles de ser interceptados por cualquier atacante, el cual podrá analizar dichos paquetes capturados y extraer información de los mismos. Dada esta peculiaridad de las comunicaciones inalámbricas es necesario buscar un método para asegurar la privacidad de dicha información. Como se verá más adelante, esto es de especial importancia en aquellos protocolos de comunicación que envían sus datos sin ningún tipo de encriptación. Posteriormente veremos cómo la criptografía se puede usar para tratar de solucionar el problema de la privacidad de las comunicaciones. Relacionado con lo comentado en el punto anterior, aparece el problema de la integridad de la información. Al igual que un atacante puede interceptar los paquetes de una comunicación y extraer información de los mismos, también puede modificar los paquetes interceptados, manipular su contenido y enviarlos a su destino con la información alterada. Por tanto, es necesario encontrar algún método para poder asegurar que la información recibida no ha sido manipulada por el camino. De nuevo, la solución a este problema pasa por el uso de la criptografía.

565


A continuación se van a presentar las distintas técnicas que un atacante puede usar para atacar redes inalámbricas. Hay que entender que dichas técnicas de ataque van a tratar de aprovechar vulnerabilidades o fallos en el proceso de autenticación así como fallos en los procesos que aseguran la integridad y privacidad de las comunicaciones. 3.2. Ataques. Fase de reconocimiento En cualquier ataque la primera fase será la de reconocimiento. En esta fase el atacante tratará de identificar las redes inalámbricas disponibles, así como los clientes conectados a la misma. Este reconocimiento puede ser tanto pasivo como activo. Cuando se realiza un ataque, el atacante interactúa con el sistema atacado de una forma que hace que su actividad pueda ser advertida por dicho sistema. El propósito de los ataques pasivos es evitar que la actividad del atacante sea detectada por el sistema. Como ya se ha comentado, los puntos de acceso emiten paquetes baliza para anunciar su presencia. Los atacantes escucharán dichos paquetes para tratar de identificar las redes disponibles y obtener así los datos de dicha red inalámbrica, como puede ser el SSID, tipo de encriptación, etc. En ocasiones los administradores de redes desactivan la publicación del SSID para tratar de evitar que su red pueda ser detectada. Esta desactivación no evita que los puntos de acceso envíen sus paquetes baliza, sino que los configura para que dejen vacío el campo correspondiente al SSID en dichos paquetes. Pero esto no evita que el atacante llegue a identificar el SSID de la red. Cuando los clientes tratan de conectar con una red inalámbrica deben enviar el SSID en el paquete de solicitud de conexión. Dicha información se envía sin ningún tipo de encriptación, por lo que a un atacante le bastará con interceptar dichos paquetes de solicitud de conexión por medio de un programa de interceptación de paquetes (como puede ser el conocido wireshark) y extraer de los mismos el SSID de la red. El atacante puede llegar incluso a provocar la desconexión del cliente para forzarle a que vuelva a iniciar la conexión y por tanto genere el paquete de solicitud de conexión que contiene la información que el atacante desea obtener. La detección de redes inalámbricas disponibles es realmente sencilla, ya que la mayoría de los sistemas operativos disponen de herramientas

566


para detectarlas. La mayoría de estas herramientas son de tipo activo ya que envían paquetes de solicitud de redes inalámbricas disponibles y dichos paquetes pueden ser detectados por el sistema atacado. 3.3. Tipos de ataques A continuación vamos a analizar los distintos tipos de ataque que se pueden usar contra redes inalámbricas. 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, y mediante el uso de antenas dicho rango se puede ver extendido enormemente. Como ya hemos comentado el tráfico de la red se emite a través del aire y puede ser interceptado por un atacante con la ayuda de un programa de captura de paquetes. Hay que tener en cuenta además, que muchos de los protocolos de red más utilizados son inseguros por naturaleza, ya que no cifran la información que transmiten y esta viaja como texto que el atacante puede ver directamente al capturar dichos paquetes. Simplemente usando un capturador de paquetes el atacantes será capaz de interceptar y reconstruir los datos que se están enviando, el mensajes que está enviando o recibiendo, etc. Tal como se ha visto en el tema 4, algunos de los protocolos que envían su información sin cifrar son: • HTTP (Hypertext Transfer Protocol). Visionado de páginas web. • SMTP (Simple Mail Transfer Protocol). Envío de correos electrónicos. • FTP (File Transfer Protocol). Transferencia de ficheros. • POP3 (Post office Protocol). Recepción de correos electrónicos. • IMAP (Internet Mail Access Protocol). Recepción de correos electrónicos. Y no solo es la información enviada la que puede interceptar el atacante. En muchos casos las credenciales (usuario y contraseña) también pueden ser interceptadas ya que también se envían como texto sin cifrar. La

567


figura 18.1 muestra una captura de paquetes realizada con wireshark en la que se puede observar los datos capturados correspondientes a una sesión POP3 en la que se ve claramente como se ha interceptado el nombre de usuario y contraseña enviada.

Figura 18.1. Captura de paquetes que contienen el usuario y contraseña de una conexión POP3.

Este tipo de ataques hacen patente la necesidad de cifrar las comunicaciones de nuestra red inalámbrica. De esta manera aunque los paquetes sean interceptados el atacante no tendrá acceso a su contenido, ya sea éste información o credenciales. 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 dicho cifrado y extraer la información. Aunque un determinado método de cifrado pueda parecer hoy infranqueable, puede que nuevos avances lo hagan vulnerable. El atacante puede no ser capaz de descifrar la información capturada hasta pasado un buen tiempo, pero según la naturaleza de la información capturada esta puede ser todavía útil y/o valiosa. Esta posibilidad se debe tener en cuenta a la hora de decidir la tecnología de comunicaciones a utilizar. Puede que la tecnología inalámbrica no sea la más adecuada para determinadas organizaciones que trabajan con información altamente sensible, ya que cifrar dicha información no nos asegura que si es capturada no pueda ser descifrada en un momento futuro.

568


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 posibles hasta que da con la correcta. Este tipo de ataque se considera primitivo y en algunos casos imposibles si la longitud de la clave es grande. 3.3.4. Ataques «Man-in-the-Middle» Este tipo de ataques se basa en el hecho de que el atacante puede ver y manipular el flujo de datos entre dos elementos de la red, tradicionalmente un cliente autorizado de la misma y el punto de acceso. De esta manera el atacante puede tanto ver lo que el usuario está haciendo como manipular lo que este ve. La figura 18.2 muestra un ejemplo básico de cómo funcionan este tipo de ataques. Simplemente por situarse en un punto intermedio en el medio de comunicación el atacante puede interceptar los datos transferidos y ver qué es lo que está haciendo el usuario. Esto es por supuesto asumiendo que la comunicación no está cifrada.

Figura 18.2. Ejemplo básico de funcionamiento de ataques «Man-in-the-Middle».

A continuación vamos a ver dos ejemplos de algunos de los ataques de este tipo más utilizados.

569


3.3.4.1. Suplantación ARP Este tipo de ataques es posiblemente el ataque «Man-in-the-Middle» más utilizado. Para entender cómo funciona este tipo de ataques 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 (o la obtendrá por medio de una consulta DNS). 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 paquete de requerimiento ARP. Este paquete se envía por medio de un broadcast a todos los equipos situados en el mismo segmento de red LAN. Dicho paquete contiene la dirección IP para la cual se desea saber la dirección MAC. La máquina destino reconocerá su dirección en el paquete de solicitud ARP y responderá al mismo indicando su dirección MAC. La figura 18.3 muestra como un atacante puede usar este proceso para situarse en el medio de dicha comunicación. Para ello, el atacante responderá

Figura 18.3. Ataque de suplantación ARP.

570


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 el los podrá retransmitir o no al destinatario según le interese. Por este método el atacante no solo ve la actividad del cliente sino que es capaz de manipular los datos que este recibe. Si por ejemplo el usuario quiere descargar un fichero del servidor, el atacante puede retransmitirle dicho fichero pero añadiéndole código que al ser ejecutado le permitirá pasar a controlar la maquina cliente de forma remota e indetectable. 3.3.4.2. Servidor DHCP falso Un servidor DHCP (Dynamic Host Configuration Protocol) permite a los clientes de una red obtener de forma automatizada una dirección IP que utilizar para gestionar sus comunicaciones en dicha red. El servidor DHCP proporciona al solicitante no solo de una dirección IP sino que también le proporciona otros ajustes necesarios como pueden ser la puerta de enlace predeterminada o los servidores DNS a utilizar. Un cliente que desee obtener la configuración necesaria para conectarse a una red inalámbrica enviará una solicitud DHCP que será atendida por el servidor correspondiente.

Figura 18.4. Ataque por medio de una servidor DHCP falso.

Un atacante puede llegar a establecer su propio servidor DHCP, como se ve en la figura 18.4. Este servidor DHCP falso interceptará las solicitudes DHCP realizadas por los usuarios y a todos ellos les indicará que

571


é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. 3.4. Ataques a clientes de redes inalámbricas Muy a menudo los administradores de red centran sus esfuerzos en asegurar su infraestructura de red, en el caso de redes inalámbricas sus esfuerzos normalmente tratan de reforzar la seguridad de sus puntos de acceso. Por supuesto esta actividad es necesaria para reforzar la seguridad de la red, pero en ocasiones deja huecos que los atacantes pueden aprovechar, dichos huecos normalmente se encuentran en los dispositivos usuarios de la red que en muchos casos los administradores olvidan reforzar su seguridad. 3.4.1. Vulnerabilidades de los clientes de redes inalámbricas Podríamos dividir las vulnerabilidades de los clientes de redes inalámbricas en las siguientes categorías: 3.4.1.1. Comunicaciones inseguras Si la comunicación no se ha cifrado, o se ha cifrado usando un algoritmo débil, existe una vulnerabilidad ya que el atacante puede ver la comunicación cuando ésta viaja por el medio. Esto es de aplicación tanto para redes cableadas como para redes inalámbricas, solo que esta vulnerabilidad se ve agravada en el caso de redes inalámbricas. Normalmente si la comunicación no va cifrada o si el atacante consigue romper la clave de cifrado, hay muchas posibilidades de que el cliente pueda ser explotado para atacar el sistema. Recordemos que el atacante solo tiene que usar un capturador de paquetes para ver la comunicación de red, y si ésta no va cifrada o si el atacante es capaz de obtener la clave de cifrado será capaz de ver el contenido de la comunicación, ya sea ésta información o credenciales para iniciar ciertos protocolos como puede ser la descarga o envío de correos electrónicos.

572


3.4.1.2. Configuraciones por defecto Las configuraciones por defecto con fallos de seguridad son una de las mayores plagas de los sistemas de información. Ya sean usuarios y contraseñas por defecto, servicios innecesarios activados, o configuraciones 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. Uno de los ejemplos más claros de los problemas que pueden causar las configuraciones por defecto se encuentra en la forma en que la mayoría de los usuarios tiene configurados sus smartphones a la hora de acceder a sus cuentas de correo electrónico. La mayoría de los usuarios configuran sus teléfonos para que estos comprueben automáticamente y de forma periódica si tienen nuevos correos. Este comportamiento puede suponer un grave problema de seguridad. Cuando un usuario conecta su teléfono a una red inalámbrica abierta, éste usará dicha red para hacer la comprobación automática de si dispone de nuevos mensajes de correo electrónico. Como se ha comentado anteriormente, los protocolos usados para recoger correo electrónico mandan las credenciales en texto plano, por lo que cualquier atacante que este capturando el tráfico que pasa por esa red abierta será capaz de capturar los nombres de usuario y contraseña de todos aquellos usuarios conectados a dicha red. Este mismo patrón de ataque puede ser usado no solo con servicios que usan autenticación sin cifrar. Muchos sistemas usan cookies para probar que un usuario se ha autenticado 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.4.1.3. Confundir al cliente para que se comunique con el atacante En muchos casos un cliente se considera seguro simplemente por el hecho de que las comunicaciones entre dicho cliente y el punto de acceso van cifradas. 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. Dicho punto de acceso tendrá el mismo ESSID que el punto de acceso que

573


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. En ese momento el atacante puede utilizar herramientas 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. La máquina atacante se configurará para retransmitir todo el tráfico recibido, de esta forma podrá monitorizar y alterar si lo considera necesario todas las comunicaciones de dicho cliente con la red. 3.4.2. Factores que agravan las vulnerabilidades de los clientes de redes inalámbricas Hay una serie de 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. Si un atacante desea tratar de comprometer una organización 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. Los clientes inalámbricos son muy fáciles de observar simplemente capturando los paquetes de solicitud de red o de asociación que envían. Un atacante no solo puede ver el paquete de solicitud de asociación, sino que, si un cliente no está asociado a un punto de acceso, éste estará continuamente enviando paquetes sonda con solicitudes para las redes inalámbricas para las que está configurado para que trate de conectar con ellas. Estos paquetes sonda contienen el ESSID de la red inalámbrica a la que está tratando de conectar y por tanto el atacante dispondrá de información muy valiosa para tratar de confundir al cliente y hacer que este se comunique con él. • Los clientes de las redes inalámbricas no son monitorizados de forma tan detallada como lo son los puntos de acceso. Esto hace que un atacante tenga más posibilidades de pasar desapercibido para el sistema si se concentra en atacar los clientes de una red en vez de sus puntos de acceso.

574


4. MEDIDAS NO CRIPTOGRÁFICAS PARA PROTECCIÓN DE REDES INALÁMBRICAS Una vez conocidos los diferentes patrones de ataque que puede usar un atacante se va a pasar a detallar los principios de diseño de redes inalámbricas que nos permitirán hacerlas más seguras, así como a enumerar los distintos tipos de medidas no criptográfica que nos ayudarán a mejorar la seguridad de la misma.

4.1. Principios de diseño seguro para redes inalámbricas Los principios presentados en esta sección son tanto de aplicación a redes inalámbricas como a cualquier sistema de redes cableadas. Si bien es cierto, que dada la facilidad con la que los atacantes pueden entrar en el rango de acción de una red inalámbrica, es de especial importancia seguir estos principios a la hora de diseñar y configurar la misma.

4.1.1. Defensa en profundidad La idea principal consiste en usar diferentes tecnologías para tratar de asegurar la red y no solo una. En muchas ocasiones los administradores de red usan solamente tecnologías de prevención. Es habitual encontrar sistemas en los que la única defensa es el uso de WEP o WPA como método de autenticación y cifrado. Si el atacante es capaz de comprometer la clave usada, el sistema quedará completamente abierto al atacante al no existir otras medidas de seguridad instaladas.

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. Posiblemente este principio de diseño de sistemas seguros sea el más ignorado en la mayoría de sistemas. Una gran cantidad de administradores de sistemas aplican precisamente la regla contraria, inicialmente dan acceso a todos los recursos y

575


posteriormente van eliminando acceso uno a uno a los recursos que consideran que el usuario no debería acceder.

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. Por ejemplo, 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. De esta forma, la organización se estaría asegurando que los invitados a la red inalámbrica no tuviesen acceso directo a su red interna. No es recomendable unir en una única red todos los sistemas conectados a la red de la organización, ya sea a través de tecnología inalámbrica o cableada. En este escenario todos los sistemas de la organización podrían comunicarse tanto a nivel 2 como a nivel 3 del modelo OSI. La forma más básica de segmentar la red en el nivel 2 es a través de LANs virtuales. Una LAN virtual (VLAN) divide los conmutadores de red en múltiples conmutadores virtuales, lo cual supone un gran ahorro ante la opción de tener que adquirir conmutadores individuales para cada uno de los segmentos de red. En este escenario para interconectar distintas VLAN se usará un dispositivo de nivel 3 como puede ser un cortafuegos o un encaminador. Para proceder a segmentar una red en el nivel 3 se hará uso de listas de control de direcciones IP en la que se indicará que direcciones IP pertenecen a cada segmento.

4.1.4. Asegurar la infraestructura de red Como se ha analizado en diferentes temas del libro, no hay que cometer el error de solo asegurar los distintos servidores y sistemas de la red, es de vital importancia asegurar también los distintos componentes de la infraestructura de red, ya que estos también pueden presentar vulnerabilidades que pueden ser explotadas por los atacantes.

576


Así, hay que considerar cada uno de los componentes de la red. Esto incluye: • Cortafuegos. • Encaminadores. • Conmutadores. • Puntos de acceso. 4.1.5. Detección de puntos de acceso no autorizados El que alguien despliegue un punto de acceso no autorizado que de acceso a la red de la organización puede ser un riesgo enorme para la seguridad de la información de la misma, ya sea un punto de acceso creado por un atacante o por un empleado bien intencionado. Este tipo de puntos de acceso debería ser identificado y eliminado lo antes posible. 4.1.6. Cambiar configuraciones por defecto Es de especial importancia cambiar las configuraciones por defecto de todos los componentes de la red inalámbrica. La explotación de las configuraciones por defecto de los elementos de la infraestructura de red es uno de los vectores de ataque más usados. El dejar nombres de usuario y contraseñas por defecto, permisos por defecto o incluso servicios activos por defecto pueden ser puntos de entrada a nuestra red para un atacante conocedor de los mismos. 4.1.7. Privacidad e integridad Como se ha comentado anteriormente, 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 802.11 disponen de opciones que van a permitir métodos de autenticación y encriptación. Los protocolos WEP, WPA y WPA2

577


permiten tanto autenticar a los usuarios como cifrar las comunicaciones. Estos protocolos se estudiarán en la sección dedicada a los métodos criptográficos para implementar la seguridad de redes inalámbricas. 4.2. Malas defensas no criptográficas En este apartado se presenta una serie de medidas no criptográficas, usadas por muchos administradores, y que aunque, aparentemente, proporcionan seguridad a la red inalámbrica en realidad solo proporcionan una falsa ilusión de seguridad ya que son vulnerables. Esa falsa ilusión de seguridad es incluso más peligrosa que no poner ninguna medida, ya que los administradores del sistema dejarán de buscar por posibles brechas o intrusiones al pensar que su red es segura, haciendo que las actividades de un intruso tengan más fácil pasar desapercibidas. 4.2.1. Cajas Faraday Esta medida 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 en dicho perímetro 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 ganancia un atacante puede llegar a recoger hasta la más mínima señal inalámbrica, consiguiendo de esta forma capturar la poca señal que puede llegar a traspasar en un momento dado ese perímetro de seguridad. 4.2.2. Filtros de direcciones MAC El filtrado de direcciones MAC permite a los administradores definir listas con las direcciones MAC de aquellos clientes que tienen permitido el acceso a la red. Cualquier cliente que trate de acceder a la red cuya dirección MAC no esté incluida en dicha lista verá rechazada su conexión. 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

578


producen en su radio de acción. Los paquetes capturados, entre otra información, 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, consiguiendo de esta forma acceder a la red con todos los privilegios del cliente suplantado. Por otro lado, además de ser un método de control de la seguridad altamente vulnerable, es un método de administración muy laboriosa, ya que obliga a los administradores a añadir a esa lista manualmente cada nuevo equipo dado de alta, o modificar la entrada de equipos ya existentes cada vez que se les cambia la tarjeta de red. 4.2.3. Ocultación del SSID Se ha comentado anteriormente que el administrador puede configurar los puntos de acceso de su red para que omitan el SSID de la red en sus paquetes baliza con el objeto de «ocultar» su red a posibles atacantes. Se ha visto también como 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. 4.3. Buenas defensas no criptográficas A continuación se van a explorar una serie de medidas que si aportan mayor seguridad al sistema. Como se verá, la mayor parte de estas tecnologías no son nuevas y se llevan usando mucho tiempo para redes cableadas. 4.3.1. Cortafuegos El uso de cortafuegos (figura 18.5) 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ámbrica. Como ya se ha analizado en temas anteriores, muchas de las soluciones de cortafuegos disponibles hoy en día proporcionan otras funcionalidades más allá del control de acceso de nivel 3. Algunos de ellos incluyen funcionalidad

579


Figura 18.5. Uso de cortafuegos para segmentación.

de detección de intrusiones, antivirus, etc. Al enrutar el tráfico de la red inalámbrica a través de un cortafuegos de este tipo se aporta nuevas capas de seguridad a la red. 4.3.2. Encaminadores En el caso de no poder usar cortafuegos para segmentar la red, es recomendable usar algún tipo de segmentación de nivel 3, y los encaminadores son una plataforma perfecta para llevarla a cabo. 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 de segmentación la podemos obtener usando conmutadores para segmentar la red a nivel 2 por medio de VLANs. Normalmente se asignara un rango de direcciones IP a cada subred, y la única manera de que dos dispositivos situados en segmentos distintos se comuniquen entre si será por medio de alguna puerta de enlace de nivel 3 como puede ser un encaminador o un cortafuegos.

580


Adicionalmente, algunos puntos de acceso modernos permiten crear múltiples SSIDs y asignar cada uno de ellos a una VLAN distinta. Cada SSID podrá tener su propia configuración de autenticación y encriptación. 4.3.4. Sistemas de detección de intrusiones En el tema 11 se presentaron los sistemas de detección de intrusiones o IDS (Intrusion Detection Systems). Este tipo de sistemas detectan posibles intrusiones en los sistemas, monitorizando para ello el tráfico de red, las actividades de los terminales, buscando determinados patrones de acciones, etc. Como ya se comentó en el tema 11, 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, ya que para que estas soluciones puedan realizar su función necesitan situarse en un punto en el que sean capaces de «escuchar» el tráfico de red generado por las posibles amenazas. 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. Actualmente, podemos encontrar en el mercado sistemas de detección de intrusiones especialmente diseñados para la detección en entornos inalámbricos. Estos sistemas además de realizar las labores tradicionales de los IDS incorporan funcionalidad de monitorización de las comunicaciones inalámbricas en busca de patrones que identifican distintos ataques específicos de dichos entornos. 4.3.5. Honeypots También en el tema 11 se presentaron los sistemas 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 proporcionando a la vez información sobre el atacante y sus métodos. En el caso de redes inalámbricas se puede construir un honeypot sencillo simplemente desplegando un punto de acceso totalmente aislado y sin

581


acceso de ningún tipo a la red interna. De esta forma, cualquier equipo que trate de conectar con el mismo corresponderá a un posible atacante que de esta forma será fácilmente identificado. 5. MEDIDAS CRIPTOGRÁFICAS PARA PROTECCIÓN DE REDES INALÁMBRICAS A lo largo del tema se ha comentado la necesidad de proporcionar privacidad e integridad a las comunicaciones inalámbricas. Para ello 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 integridad. En este apartado se van a presentar los distintos métodos disponibles y se va a evaluar en qué medida proporcionan privacidad e integridad a las comunicaciones. 5.1. WEP (Wired Equivalent Privacy) WEP forma parte del estándar 802.11 original para redes inalámbricas que se introdujo en 1999. Proporciona tanto funciones de autenticación como de cifrado. 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 este debe tener acceso a la red inalámbrica, y por tanto procede a enviarle un mensaje de vuela indicando que el cliente ha sido autenticado. 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 para establecer la comunicación:

582


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 comprueba que el valor obtenido coincide por el recibido del cliente. Si ambos valores coinciden el punto de acceso reconoce el intento de autenticación. La realidad es que la autenticación por medio de clave compartida es una vulnerabilidad de seguridad en sí misma. El hecho de que un atacante que este «escuchando» las comunicaciones de la red pueda captura 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 y obtener por tanto la clave compartida. 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. WEP utiliza el algoritmo de cifrado RC4 para el cifrado y usa un sistema de clave compartida. WEP puede usar tanto una clave de 40 bits, como una clave de 104 bits. La decisión sobre la clave a usar corresponde al administrador del sistema. Éste deberá decidir si usar una clave de 40 bits o una clave de 104 bits. Al hablar de claves de cifrado, como ya hemos visto, cuanto más larga sea la clave, mas fuerte será el cifrado conseguido. La única razón para usar claves de 40 bits es que son más fáciles de recordar al ser más cortas. 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. Esta clave servirá por un lado como clave de autenticación y por otro como clave para el proceso de cifrado. En la práctica, el hecho de compartir una clave entre muchos usuarios es un claro punto de vulnerabilidad. Por un lado no permite al administrador autenticar a los usuarios de forma individual y por otro lado si un solo usua-

583


rio compromete la clave, dicha clave habrá quedado comprometida para todos ellos, pudiendo un atacante descifrar las comunicaciones de todos ellos. Como se ha comentado, WEP utiliza el algoritmo de cifrado RC4. Este algoritmo 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. A partir de este vector de inicialización la clave de cifrado de calcula de la siguiente manera: Clave de cifrado = [Vector de Inicialización] [Clave WEP] Para que el destinatario sea capaz de descifrar el paquete recibido necesitará conocer ese vector de inicialización, pero para ello solo tiene que consultar el paquete recibido, ya que el valor del vector de inicialización se incluye en el paquete como texto sin cifrar. En el punto anterior se ha presentado el problema que presenta el sistema de clave compartida para la autenticación, esto añadido al hecho de que los paquetes cifrados incluyen en texto sin cifrar el valor del vector de inicialización, hace que WEP no sea un algoritmo de autenticación y cifrado seguro. De hecho, y pese a que todavía numerosos sistemas inalámbricos confían en WEP como su método de autenticación y cifrado estándar, WEP se considera desde hace tiempo como un algoritmo de cifrado no seguro. 5.1.3. Vulnerabilidades y ataques a redes con cifrado WEP En 2001, el cifrado WEP fue roto por tres investigadores de seguridad: Scott Fluhrer, Itsik Mantin y Adi Shamir. El ataque comúnmente conocido como el ataque FMS ataca la vulnerabilidad que supone el envío en texto sin cifrar del vector de inicializació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. Con una captura de unos cinco millones de paquetes el atacante tendrá un cincuenta por ciento de posibilidades de efectivamente obtener la clave WEP utilizada. Este número de paquetes puede parecer muy elevado, pero en una red activa pueden llegar a enviarse más de 16 millones de paquetes en un corto periodo de tiempo.

584


Posteriormente han salido diferentes revisiones y mejoras de este ataque. En 2007 los investigadores de seguridad Pyshkin Tews y Weinmann desarrollaron el ataque conocido como PTW. Este ataque necesita capturar solamente 40.000 paquetes para tener un cincuenta por ciento de posibilidades de obtener la clave WEP. El proceso de ataque a redes que usan WEP como método de autenticación y cifrado es bien sencillo y no hace falta tener altos conocimientos informáticos para ejecutarlo. En estos momentos existen muchas herramientas que realizan este proceso de forma automática, el atacante solo deberá ejecutar dichas utilidades y esperar los resultados. 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 inútil, que tiene el agravante de proporcionar falsa sensación de seguridad a sus usuarios. Cualquier red inalámbrica que use este método debería considerar actualizar sus sistemas a otros algoritmos de autenticación y cifrado seguros. 5.2. WPA (Wi-Fi Protected Access) El protocolo WPA (Wi-Fi Protected Access) fue desarrollado como sustituto de WEP. Hay dos versiones WPA y WPA2. La primera fue desarrollada como un reemplazo temporal del sistema WEP mientras se desarrollaba el estándar IEEE 802.11i (WPA2). 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. 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 también utiliza el algoritmo RC4 para el cifrado de datos. TKIP cifra cada paquete con una única clave de cifrado, que al igual que en WEP se basa en la clave compartida. Esencialmente TKIP implementa una versión más segura de lo que trataba de hacer el protocolo WEP. WPA se implementa de dos formas básicas: WPA-PSK y WPA-Enterprise.

585


WPA-PSK (Pre-Shared Key) establece una clave que es compartida entre todos los dispositivos que desean conectarse a la red inalámbrica. Funcionalmente esto es exactamente igual que como punciona WEP, solo que en este caso la clave es ahora de 256 bits, lo que hace que el tratar de obtener la clave de cifrado a partir de valores cifrados y sin cifrar sea muchísimo más complejo. 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. Cada usuario tendrá credenciales individuales, lo cual es mucho más seguro que cualquier infraestructura de clave compartida y además permite identificar a los usuarios de forma individual. 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 (Counter Cipher Mode with Block Chaining Message Authentication Code Protocol) o AES (Advanced Encription Standard). Como se ha analizado en temas anteriores, 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. 5.2.3. Vulnerabilidades y ataques a redes con cifrado WPA Aunque WPA es un protocolo de seguridad mucho más seguro que WEP también presenta sus vulnerabilidades que deben ser tenidas en cuenta. 5.2.3.1. Obtención de la clave compartida WPA El proceso de autenticación con WPA es similar al que se producía con WEP. Como respuesta a la solicitud de conexión del cliente el punto de acceso le enviará un paquete que contendrá un número pseudo-aleatorio que el cliente deberá cifrar con la clave compartida y enviar de nuevo ya cifrado al punto de acceso para que este compruebe que el cliente posee la clave correcta.

586


Al ser este proceso similar al que realiza WEP, 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 al clave WPA. Esta vulnerabilidad hace que la longitud y complejidad de la clave WPA compartida sea extremadamente importante para la seguridad de la red. Cuanto más larga y compleja más difícil será para el atacante romper dicha clave. 5.2.3.2. Suplantación de paquetes de de-autenticacion WPA Para que el atacante sea capaz de romper la clave WPA necesita escuchar numerosos paquetes de inicio de conexión de clientes para obtener suficientes combinaciones de números pseudo-aleatorios cifrados y sin cifrar que le permitan llegar a romper dicha clave. Puede que el tráfico de datos normal de una red inalámbrica no le proporcione al atacante los suficientes paquetes de inicio de conexión necesarios y necesite «escuchar» dicha red durante un muy largo periodo de tiempo. 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. De esta forma, el cliente entenderá que su sesión ha sido terminada y tratará de restaurarla enviando de nuevo la solicitud de conexión. 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. 5.2.3.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 vuelven a iniciar la conexión. Pero esta no es la única forma en que un atacante puede inutilizar la red inalámbrica. Hay una función dentro de WPA que establece que si un punto de acceso recibe dos paquetes incorrectos de un cliente, este desconecta-

587


rá al cliente y esperará 60 segundos antes de continuar con este cliente. Un atacante podría suplantar a los distintos clientes y enviar al punto de acceso paquetes erróneos para que este desconectase el mismo a los clientes. A la vista de estas vulnerabilidades, WPA tampoco garantiza la seguridad de una red inalámbrica, si bien es cierto que es mucho más difícil de comprometer que las redes aseguradas mediante WEP. Siempre que sea posible usaremos WPA en nuestras redes, y si es posible se usará WPA2 con CCMP. 5.3. WPA2- Enterprise con arquitectura de certificados digitales La mejor solución para aquellos entornos que demanden la máxima seguridad en sus comunicaciones inalámbricas la encuentran usando WPA2Enterprise 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. • El sistema y la máquina del usuario pueden realizar el proceso de autenticación sin intervención del usuario. Además, el uso de certificados digital va a permitir que se produzca una autenticación mutua. El cliente será autenticará a la red inalámbrica y la red inalámbrica autenticará al cliente. 5.3.1. Autenticación de usuarios Como ya se ha analizado anteriormente, el protocolo RADIUS (Remote Authentication Dial-In User Service) es un protocolo de autenticación extremadamente flexible desarrollado como estándar por el IETF (Internet Engineering Task Force). Aunque originalmente se desarrolló como sistema de autenticación para redes de acceso telefónico, RADIUS permite autenticar usuarios en una gran variedad de escenarios y tecnologías, incluyendo las redes ina-

588


lámbricas. RADIUS proporciona autenticación, autorización y registro de las actividades de los usuarios. Los servidores RADIUS (figuras 18.6 y 18.7) pueden ser sistemas autónomos que autenticarán a los usuarios contra una base de datos de usuarios local, o también pueden ser sistemas que autentiquen a los usuarios contra bases de datos externas como puede ser un servidor de Directorio Activo.

Figura 18.6. Autenticación RADIUS contra base de datos local.

Figura 18.7. Autenticación RADIUS contra servidor de directorio activo.

Las comunicaciones entre los clientes, el autenticador (quien realmente da acceso a la red) y el servidor de autenticación utilizan el protocolo EAP (Extensible Authentication Protocol). El autenticador (en nuestro caso el punto de acceso) simplemente retransmite los paquetes recibidos del cliente al servidor de autenticación y no tiene por que entender el mensaje que se está intercambiando, simplemente esperará a ver un mensaje de autenticación correcta emitido por el servidor de autenticación, en ese momento concederá el acceso a la red inalámbrica al cliente. 5.3.2. Uso de certificados digitales El uso de certificados digitales con WPA-Enterprise es opcional. La arquitectura básica del sistema es la misma, solo que en este caso hay que añadir una autoridad de certificación a la misma.

589


En el tema 15 se explicó el funcionamiento de los certificados digitales y de los sistemas de clave pública (PKI) por lo que no se va a repetir en este apartado. Simplemente es necesario entender que para poder utilizar WPA2-Enterprise con arquitectura de certificados digitales (figura 18.8) 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.

Figura 18.8. WPA-Enterprise con autoridad de certificación.

590


6. CONOCIMIENTOS Y COMPETENCIAS ADQUIRIDAS El objetivo de este tema es que el estudiante haya adquirido los conocimientos necesarios para hacer una valoración del nivel de seguridad que presenta una red inalámbrica e identificar las opciones disponibles para mejorarla. Para ello se ha iniciado el tema presentando los riesgos a los que se enfrentan las comunicaciones que tienen lugar sobre las redes inalámbricas, identificando las diferentes vulnerabilidades que pueden presentar e identificando los patrones de ataque más utilizados sobre este tipo de redes de comunicación. A su vez, el alumno ha adquirido conocimiento de los diferentes métodos que tiene a su disposición para mejorar la seguridad de una red inalámbrica, así como de su diferente efectividad, lo que le proporciona los conocimientos básicos para identificar en cada caso cual es la opción más adecuada para asegurar una determinada infraestructura de red inalámbrica. 7. BIBLIOGRAFÍA IEEE Official site, URL: http://standards.ieee.org/about/get/802/802.11.html INTECO, INSTITUTO NACIONAL DE TECNOLOGÍAS DE LA COMUNICACIÓN, en su página web dedica un artículo a presentar las medidas recomendables para asegurar una red inalámbrica. URL: http://cert.inteco.es/Proteccion/ Configuraciones_seguras/WiFi/ INTYPEDIA, INFORMATION SECURITY ENCYCLOPEDIA, enciclopedia gratuita en video, que dedica la lección 12 a la seguridad en redes inalámbricas, con la garantía de la red CRIPTORED y la Universidad Politécnica de Madrid, descargable desde http://www.intypedia.com/ WRIGHTSON, W. (2012): Wireless Network Security. A Beginner’s Guide. Ed. McGraw Hill. 8. PALABRAS CLAVE Ataque, defensas, Reconocimiento, Red Inalámbrica, WEP, WPA, WPA2.

591


9. EJERCICIOS RESUELTOS 1. El identificador que determina de forma única a un punto de acceso específico es el: a) b) c) d)

SSID. BSSID. Dirección MAC. Dirección IP.

Solución: b. 2. Durante la fase de reconocimiento un atacante: a) Tratará de identificar la ubicación física de los puntos de acceso de la red. b) Tratará de determinar las redes inalámbricas disponibles en un determinado área. c) Tratará de descubrir la clave de acceso a la red por medio de un ataque de fuerza bruta. d) Buscará algún usuario con acceso a la red y tratarán de sonsacarle la clave de la red. Solución: b. 3. Cuál de los siguientes protocolos de comunicación envía las credenciales del usuario sin cifrar: a) b) c) d)

FTP. POP3. SMTP. Todos ellos envían las credenciales sin cifrar.

Solución: d. 4. Cuál de las siguientes medidas se considera una buena defensa para redes inalámbricas: a) Usar firewalls para segmentar el tráfico de red. b) Configurar el punto de acceso para que oculte el SSID de la red inalámbrica.

592


c) Usar el filtrado de direcciones MAC para establecer que clientes tienen acceso a la red inalámbrica. d) Uso de WEP par autenticar a los usuarios y cifrar las comunicaciones. Solución: a. 5. Sobre WPA-PSK: a) Es un sistema de autenticación y cifrado que garantiza completamente la seguridad de las comunicaciones inalámbricas. b) Funcionalmente es igual que WEP solo que con una clave más larga. c) Los paquetes WPA-PSK de respuesta del punto de acceso a la solicitud de autenticación que envía el cliente no incorporan un número pseudo-aleatorio sin cifrar para que el cliente lo devuelva cifrado. d) Permite autenticar a los usuarios de forma individual. Solución: b. 10. EJERCICIOS DE AUTOEVALUACIÓN 1. ¿Cuál de las siguientes características NO es un requisito básico de seguridad en las comunicaciones inalámbricas?: a) b) c) d) 2

Autenticación. Registro de actividad del usuario. Integridad. Privacidad.

La técnica de ocultación de SSID: a) Evita que los clientes de una red inalámbrica envíen el SSID de la red en sus paquetes de petición de solicitud de conexión. b) Consiste en configurar los puntos de acceso para que estos dejen de enviar paquetes baliza. c) No evitan que el atacante llegue a descubrir el SSID de la red. d) Ninguna de las anteriores.

3. Un ataque de suplantación ARP: a) Es un ataque de tipo «Man-in-the-Middle» que aprovecha la forma de funcionar del protocolo de red usado para descubrir la dirección MAC de un equipo para confundir a la máquina atacada.

593


b) Es un ataque de tipo «Man-in-the-Middle» que consiste en configurar un servidor DHCP falso que proporcione al cliente información de conexión a la red falsa que haga que todas las comunicaciones se envíen a través del atacante. c) Consiste en la captura de paquetes ARP que cruzan la red inalámbrica para tratar de extraer información de credenciales que viaja sin cifrar. d) Es ataque de «fuerza bruta». 4. ¿Cuál es la longitud de una clave WEP?: a) b) c) d)

20 bits. 40 bits. 104 bits. El administrador puede utilizar tanto una clave de 40 bits como una clave de 104 bits.

5. Sobre WPA2-Enterprise con estructura de certificados: a) Utiliza el protocolo RADIUS para autenticar a los usuarios. b) Permite autenticar a los usuarios contra un controlador de dominio de directorio activo. c) Necesita de una autoridad de certificación para comprobar la validez de los certificados usados por los clientes de la red inalámbrica. d) Todas las anteriores.

594

Solucionario a los ejercicios de autoevaluación

CAPÍTULO

1

2

3

4

5

1

D

C

A

B

D

2

C

B

D

D

C

3

B

A

C

D

B

4

A

C

D

C

A

5

C

D

B

D

A

6

C

B

C

D

C

7

B

D

C

A

C

8

B

C

D

D

C

9

C

D

A

C

B

10

D

B

C

C

A

11

A

B

D

D

C

12

C

B

D

B

A

13

C

D

B

A

B

14

B

C

A

D

C

15

C

A

B

C

A

16

C

B

A

B

D

17

D

C

C

D

B

18

B

C

A

D

D

597

C

M

Y

CM

MY

CY CMY

K


En un mundo en el que todos utilizamos herramientas que llamamos “sociales” para la comunicación personal y profesional, y en el que buena parte de nuestra información viaja por las redes o se guarda en la “nube”, todos deberíamos conocer los fundamentos mínimos para mantener una actitud prudente en nuestra vida digital. Hoy en día, cuando los currículos se buscan por Internet, los documentos se entregan en dispositivos USB, las conferencias se hacen por la red y, en definitiva, el trabajo profesional y el estudio se apoyan inevitablemente en los ordenadores, teléfonos móviles y redes, se hace más necesario que nunca saber qué se puede y qué se debe hacer en cuanto a seguridad informática. En un mundo en el que se discute sobre si se debe perder privacidad para obtener seguridad, y, se nos pretende convencer de que esto traerá seguridad completa, es interesante recordar que , como dijo Benjamin Franklin, únicamente hay dos cosas seguras al 100%: la muerte y el pago de impuestos. La sociedad necesita profesionales bien cualificados para trabajos especializados en proporcionar seguridad a datos, sistemas y redes de comunicación. Para ellos, muy especialmente los alumnos de los grados de Ingeniería en la Universidad española, este libro pretende ser una introducción práctica a asuntos y conocimientos sobre los que tendrán que profundizar. Pero además, los autores hemos pretendido también hacer un libro que, de manera amena pero estricta, ayude al público en general a entender situaciones que, cada vez más, son rutinarias.

ISBN: 978-84-362-6716-7

Editorial

02307

colección Grado 9 788436 267167

GR

Procesos y herramientas para la seguridad de redes Gabriel Díaz Orueta Ignacio Alzórriz Armendáriz Elio Sancristóbal Ruiz Manuel Alonso Castro Gil

Procesos y Herramientas Para La Seguridad de Redes

Recommend Documents