Seguridad en Redes de Mediana y Pequeña Empresa.

Universidad Central “Marta Abreu” de Las Villas

Facultad de Ingeniería Eléctrica Departamento de Telecomunicaciones y Electrónica

Seguridad en Redes de Mediana y Pequeña Empresa.

TRABAJO DE DIPLOMA

Autor: Ramón Torres Rojas.

Tutor: Dr. Félix Álvarez Paliza.

Lic. Alcides Morales Guedes. Msc. José Raúl Barreras.

Santa Clara

2004 "Año del 45 aniversario del triunfo de la revolución"

Hago constar que el presente trabajo fue realizado en la Universidad Central “Marta Abreu” de las Villas como parte de la culminación de los estudios de la especialidad de Telecomunicaciones y Electrónica autorizando a que el mismo sea utilizado por la Institución, para los fines que estime conveniente, tanto de forma parcial como total y que además no podrá ser presentado en eventos, ni publicados sin autorización de la Universidad.

________________ Firma del Autor

Los abajo firmantes, certificamos que el presente trabajo ha sido realizado según acuerdo de la dirección de nuestro centro y el mismo cumple con los requisitos que debe tener un trabajo de esta envergadura referido a la temática señalada. ________________ _______________________ Firma del Tutor Firma del Jefe de Dpto. Donde se defiende el trabajo

____________________ Firma del Responsable de

Información Científico-Técnica

Pensamiento

Ahora o nunca. Mañana es la mentira piadosa con que se engañan las voluntades moribundas.

José Ingenieros.

Agradecimientos

A mis padres, por su amor y comprensión, por guiarme siempre, por confiar en

mí y por ser las personas que más quiero en el mundo.

A mi querido hermano, por lo mucho que lo quiero.

A mis abuelos, por quererme tanto y por mi devoción hacia ellos.

A mi familia toda.

A mi tutor Paliza, por haberme iniciado en este mundo y por su apoyo y dedicación.

A Manuel, por haberme dado la oportunidad de trabajar a su lado y por

confiar en mí.

A mis amigos Jose y Yunior, por tantos y tantos momentos.

A todos mis amigos, por su cariño y comprensión.

A todos mis profesores, por contribuir con mi formación.

A todas aquellas personas que de una forma u otra tuvieron que ver con mi vida durante estos cinco años.

A todos, Gracias.

Dedicatoria

A mis padres, con todo el cariño del mundo

Resumen El presente trabajo trata sobre la seguridad en redes de mediana y pequeña empresa, el cual

se desdobla en la seguridad de los principales servicios ofrecidos. Analiza los aspectos

teóricos más importantes relacionados con la Seguridad Informática a nivel mundial.

Muestra los principales elementos que atentan contra la seguridad de los sistemas

informáticos así como los ataques más comunes. Especifica en cada caso donde encontrar

información adicional con el fin de profundizar más en estos temas.

Estudia los principales protocolos de seguridad, y mecanismos de autentificación. Se

describen sus ventajas, desventajas y niveles de seguridad ofrecidos. Se especifica los

principales entornos donde son aplicables y las soluciones más importantes aportadas por

cada uno.

Como caso concreto se centra en la seguridad de la Intranet de la Universidad Central

“Marta Abreu” de Las Villas, donde se muestran los principales servicios ofrecidos así

como sus vulnerabilidades. Dando soluciones concretas en cada caso. Estos servicios

pueden ser considerados como genéricos en la mayoría de las redes de mediana y pequeña

empresa, por lo que las soluciones brindadas en este trabajo pueden servir de referencia en

estos entornos.

Índice

Introducción ........................................................................................................................... 1 Capitulo1: Seguridad en Redes. ............................................................................................. 4

1.1 Seguridad Informática............................................................................................ 4 1.2 Elementos que atentan contra la seguridad. ........................................................... 4

1.2.1 Amenazas Lógicas. ........................................................................................ 5 1.2.2 Amenazas Naturales....................................................................................... 7

3.1 Protecciones al Sistema.......................................................................................... 8 1.3 Seguridad Física..................................................................................................... 8 1.4 Ataques Genéricos. ................................................................................................ 9 1.5 Importancia de la Criptografía. ........................................................................... 12

1.5.1 Sistemas de cifrado simétrico. ..................................................................... 12 1.5.2 Sistemas de cifrado asimétrico..................................................................... 13 1.5.3 Sistemas de cifrado híbridos. ....................................................................... 14

Capitulo 2: Protocolos y mecanismos de seguridad............................................................. 15 2.1 Kerberos ............................................................................................................... 15

2.1.1 Arquitectura de Kerberos ............................................................................. 15 2.1.2 Autenticación ............................................................................................... 16 2.1.3 Inicio de Sesión............................................................................................ 17 2.1.4 Obtención de Ticket ..................................................................................... 18 2.1.5 Petición del servicio. ................................................................................... 19 2.1.6 Problemas de Kerberos ................................................................................ 19

2.2 Certificados Digitales........................................................................................... 20 2.2.1 Validez de los Certificados Digitales........................................................... 22 2.2.2 Emisión de Certificados Digitales................................................................ 22 2.2.3 Tipos de Certificados ................................................................................... 23

2.3 SSL (Secure Socket Layer). ................................................................................. 24 2.3.1 Protocolos de SSL........................................................................................ 25 2.3.2 Ventajas de SSL........................................................................................... 27 2.3.3 Limitaciones y problemas de SSL ............................................................... 28

2.4 SSH ...................................................................................................................... 28 2.4.1 Manejo básico de SSH ................................................................................. 29

2.5 IPSec .................................................................................................................... 30 2.5.1 El Protocolo AH........................................................................................... 30 2.5.2 El Protocolo ESP.......................................................................................... 32 2.5.3 Modos transporte y túnel............................................................................. 33 2.5.4 IKE: El Protocolo de Control....................................................................... 35 2.5.5 Integración de IPSec con una PKI ............................................................... 36

2.6 VPN Redes Privadas Virtuales ........................................................................... 38 2.6.1 Tipos de Redes Privadas Virtuales............................................................... 39 2.6.2 Ventajas de las Redes Privadas Virtuales .................................................... 39 2.6.3 Inconvenientes de las Redes Privadas Virtuales .......................................... 40

2.7 Otros Protocolos de Seguridad............................................................................. 41 2.7.1 PPTP............................................................................................................. 41

2.7.2 L2TP............................................................................................................. 41 2.7.3 SOCKS......................................................................................................... 41 2.7.4 S/MIME ....................................................................................................... 42 2.7.5 SET............................................................................................................... 42

Capitulo3 Propuestas de Seguridad de la Intranet UCLV.................................................... 44 3.2 Intranet UCLV. .................................................................................................... 44 3.3 Disponibilidad de Conexión de la Intranet. ......................................................... 47 3.4 Consideraciones de Seguridad en la Intranet UCLV. .......................................... 49 3.5 Seguridad de la Gestión del Backbone. ............................................................... 50 3.6 Auditorías de Seguridad y Actualizaciones de los Sistemas Operativos. ............ 50 3.7 Copias de Seguridad............................................................................................. 51 3.8 Sistemas de Autentificación en la Intranet UCLV............................................... 51 3.9 Modelo de comunicación seguro entre Servidores y Clientes-Servidores........... 52 3.10 Seguridad del cliente de Web para Correo Electrónico. ...................................... 53 3.11 Seguridad en la Administración y Actualización del sitio Intranet UCLV......... 54 3.12 Seguridad del Sistema de Control Docente.......................................................... 55 3.13 Autentificación del RAS usando Radius.............................................................. 56 3.14 Seguridad del Servicio de RAS para usuarios móviles........................................ 57 3.15 Seguridad del sistema de mensajería instantánea Jabber. .................................... 57

Conclusiones ........................................................................................................................ 59 Recomendaciones................................................................................................................. 62 Referencias Bibliográficas ................................................................................................... 63 Glosario................................................................................................................................ 68 Anexos ................................................................................................................................. 70

Introducción

Seguridad en Redes de Mediana y Pequeña Empresa 1

Introducción

La seguridad en redes de computadoras ha pasado de ser una simple preocupación de unos

pocos a una difícil realidad en nuestros días. A cada momento crece el número de empresas

que informatiza su trabajo de oficina y se va haciendo más dependiente de las nuevas

tecnologías. Las redes de computadoras ganan terreno y su seguridad se convierte en una

tarea de todos los profesionales del mundo de la informática.

En los sistemas informáticos es muy importante el volumen de información confidencial

que se maneja, las pérdidas por concepto de la revelación de esta información confidencial

pueden ser numerosas y a partir de esta consideración, las empresas dedicarán más o menos

recursos a implementar una red segura.

Existe una gran variedad de estándares de protocolos que implementan en alguna medida

seguridad en redes, también se cuenta con numerosas herramientas y aplicaciones para

estos fines. Diseñar una intranet segura solo puede ser posible a través de un análisis

detallado entre los distintos protocolos, herramientas y aplicaciones, además del

funcionamiento de los principales servicios y sus vulnerabilidades.

El principal problema encontrado es precisamente la carencia de una arquitectura de red

segura que sea capaz de cifrar las comunicaciones de manera que la información en el canal

no pueda ser alterada o accedida por personal no autorizado. Para la solución de este

problema surgen las siguientes interrogantes:

¿Qué servicios queremos proteger?

¿Cuáles son las principales vulnerabilidades de estos servicios?

¿Qué protocolos nos brindan esta seguridad?

¿Qué aplicaciones ayudarían a complementar la seguridad de estos servicios?

¿Cuál sería la arquitectura de red segura a implementar?

Por ello, el objetivo general es proponer una arquitectura de red segura para la Intranet

UCLV. Para lo cual se han propuesto las siguientes tareas específicas:

Introducción


Analizar los principales protocolos de seguridad y mecanismos de autentificación.

Caracterizar las soluciones de seguridad ofrecidas por estos protocolos.

Analizar las principales vulnerabilidades de los servicios ofrecidos en las redes.

Elaborar una propuesta de intranet segura para la red UCLV.

Este trabajo se ha estructurado en: introducción, desarrollo, compuesto de tres capítulos,

conclusiones, recomendaciones, referencias bibliográficas, glosario de términos y anexos.

A continuación se describe brevemente el contenido de los diferentes capítulos.

Capítulo1: Seguridad en Redes.

Este capítulo aborda el estado del arte de la seguridad informática. Los elementos que

atentan contra la seguridad de los sistemas informáticos. Protecciones y principales ataques

e importancia de la criptografía simétrica y asimétrica en el cifrado de las comunicaciones.

Capitulo2: Protocolos y mecanismos de seguridad.

El capitulo 2 trata sobre los protocolos y herramientas que brindan determinado nivel de

seguridad a los sistemas informáticos. Se describen las soluciones ofrecidas por Kerberos,

Certificados Digitales, SSL, SSH, IPSec, VPN y otros. En cada caso se describe su

funcionamiento, ventajas ofrecidas e inconvenientes de implementación.

Capitulo3: Aseguramiento de la Intranet UCLV.

El tercer y último capítulo hace una sencilla descripción de la intranet objeto de estudio. Su

estructura física y lógica y sus principales servicios ofrecidos. Consecuentemente brinda

una caracterización de las vulnerabilidades de estos servicios, así como la solución

planteada en cada uno de los casos. También se dan importantes recomendaciones que

ayudan a proteger la integridad de los servidores Reales y el Backbone Gigabit, que

constituye la infraestructura de comunicaciones sobre la cual se soportan todas las

aplicaciones.

En este informe de tesis se han utilizado un conjunto de términos en inglés, sin traducirlos

debido al amplio uso que tienen en el ámbito donde se desarrolla este trabajo. Al final del

Introducción


cuerpo del trabajo se anexa un glosario de términos que contiene una descripción más

detallada de los mismos.

Capitulo 1 – Seguridad en Redes


Capitulo1: Seguridad en Redes.

1.1 Seguridad Informática

El crecimiento de Internet unido al auge de la informática ha traído consigo un aumento

considerable de piratas informáticos y un incremento extraordinario de los incidentes de

seguridad [CERT, (2004)]. En la actualidad mantener un sistema seguro resulta una tarea

difícil para cualquier profesional de la informática.

La seguridad es un proceso continuo de reducción de riesgos donde sus problemas

esenciales se dividen en las siguientes áreas: confidencialidad, validación de identificación,

no repudio e integridad. La confidencialidad se traduce en mantener la información fuera

del alcance de usuarios no autorizados. La validación de identificación se encarga de

determinar con quien se esta hablando antes de revelar información confidencial. El no

repudio se encarga de garantizar la identidad del usuario de manera que no pueda negar la

participación en una transacción económica y la integridad implica que los mensajes sólo

sean modificados por usuarios autorizados. [Andrew S Tanenbaum, 2002]

En la redes de cómputo se protege todo lo relativo al hardware, el software y los datos. El

hardware formado por los elementos físicos del sistema, cableado, gabinetes, cajas de

conexión, elementos secundarios de almacenamiento como cintas, disquetes, CD y otros. El

software compuesto por los programas lógicos, sistema operativo y aplicaciones. Y los

datos que representan la información manejada por el software.

1.2 Elementos que atentan contra la seguridad.

Entre los elementos que atentan contra la seguridad de las redes de cómputo encontramos:

programas malignos, catástrofes naturales, acciones humanas, y otras.

En ocasiones no se tienen en cuenta las amenazas de seguridad provenientes de empleados

de la empresa; se deposita demasiada confianza en el buen comportamiento de los usuarios

internos y de ellos viene un porcentaje grande de las amenazas. Recordemos que nadie

mejor que ellos conoce la infraestructura informática y sus debilidades. Un empleado de



mantenimiento puede cortar un cable de la red de datos o puede dejar sin electricidad al

nodo de comunicaciones de la red sin muchas dificultades.

Los curiosos son los atacantes más habituales del sistema; son usuarios muy interesados en

la tecnología y con muchas ganas de aprender y probar cosas. Aunque por lo general estos

ataques no dañan el sistema, más bien, su objetivo principal es el orgullo de ganar

determinados privilegios y los fines son sencillos: acceder a recursos y elevar su ego.

Los terroristas, son las personas que atacan los sistemas informáticos con el objetivo de

causar daños: destruir sistemas de ficheros, borrar bases de datos y modificar o destruir

sitios Web.

El grupo de atacantes más peligrosos son los intrusos remunerados. Suelen afectar a

empresas muy grandes, y son movidos por enormes sumas de dinero. Son piratas

informáticos de gran experiencia en cuestiones de seguridad y el objetivo siempre son datos

muy valiosos, acceso a bases de datos militares, proyectos secretos e información altamente

clasificada.

1.2.1 Amenazas Lógicas.

Las amenazas lógicas son todos los programas que de una forma u otra pueden dañar

nuestro sistema. Se les conoce con el nombre de malware, bugs o agujeros. Errores de

programación del software que pueden comprometer el sistema operativo. A estos errores

se les conoce como bugs y los programas que aprovechan estas vulnerabilidades exploits,

estos últimos son muy peligrosos ya que no se necesita de mucho conocimiento para

utilizarlos y comprometer un servidor. [Ludwin, Mark (1996)]

Las herramientas de seguridad también se incluyen dentro del grupo de amenazas lógicas

ya que son un arma de doble filo. De la misma manera en que un administrador las usa para

detectar y corregir los errores del sistema, un intruso las usa para detectar vulnerabilidades

y atacar. Está demostrado que la seguridad de un sistema no puede basarse en el



desconocimientos de los problemas por parte de los atacantes, esta política se denomina

seguridad mediante oscuridad (Security through obscurity).

Durante el desarrollo de aplicaciones los programadores suelen dejar puertas traseras, para

depurar fallas con mayor facilidad o simplemente para tener un control permanente sobre el

sistema que están desarrollando. Esto puede ser muy importante ya que el sistema siempre

sería vulnerable al creador y podría adquirir grandes sumas de dinero por conceptos de

mantenimiento. Aunque en la mayoría de los casos las puertas traseras son causadas por

errores de programación. Si dicha vulnerabilidad se descubriera o la existencia de la puerta

trasera se llegara a filtrar, cualquier intruso puede hacer uso de ella para violar la integridad

de su sistema. Empresas de seguridad a nivel mundial reportan que los ataques a datos

confidenciales mediante el uso de puertas traseras durante el primer semestre de 2003,

aumentó en un 50%. [Symantec Corporation, (2003)]

Otros programas que atentan contra la seguridad son los programas conejo o bacterias, los

cuales simplemente se dedican a reproducirse hasta que el número de copias acaba con los

recursos del sistema: disco duro, memoria y procesador, produciendo una negación de

servicio. Aplicaciones mal programadas pueden convertirse en un programa de este tipo, si

se descuidan los recursos del sistema. En la actualidad no son muy comunes.

Las bombas lógicas son partes del código de algún programa que permanecen pasivas hasta

que son activadas en determinado momento y ejecutan su tarea destructiva, los detonadores

suelen ser presencia o ausencia de un fichero específico, una fecha concreta, una

combinación de teclas, y otras variantes.

Los gusanos son otro de los códigos maliciosos, los cuales son capaces de propagarse y

ejecutarse a sí mismos a través de redes aprovechando bugs de los sistemas a los que se

conecta y en ocasiones portando virus. A estos se le unen los caballos de Troya, los cuales

son instrucciones escondidas en programas de manera que este parezca realizar las tareas

que el usuario espera de él, pero en realidad ejecuta funciones ocultas que atentan contra la

seguridad. Los caballos de Troya ocultan su intención real bajo la apariencia de un



programa inofensivo que a primera vista funciona correctamente. [Villalón Huerta, Antonio

(2002)]

Los virus son también secuencias de códigos, estas se insertan en un fichero ejecutable

denominado huésped, de manera que cuando se active el fichero el virus también lo hará,

insertándose a sí mismo en otros programas para asegurar su procreación y diseminación.

Los virus, son más comunes en sistemas Windows que en Linux. Estos inician cada vez

que inicia la computadora, para lo cual se copian en el registro de Windows, se propagan

por la red, por correo electrónico, usando vulnerabilidades de los sistemas operativos y

puede venir como combinación de gusano, caballo de Troya y otras variantes aprovechando

las ventajas de cada uno de ellos, su finalidad puede ser múltiple, desde el robo y

destrucción de información, implantación de una puerta trasera o caballo de Troya,

negación de servicio distribuido a una página específica en Internet, entre otras variantes.

Durante el primer semestre de 2003, las amenazas combinadas aumentaron el 20%

comparado con las de la primera mitad de 2002. [Symantec Corporation, (2003)]

Las técnicas salami son el robo automatizado de pequeñas cantidades de dinero, lo que la

hace difícil de detectar. Este tipo de técnicas se usa normalmente en sistemas bancarios que

sustraen céntimos, de miles de cuentas, lo que da en total, miles de dólares. Esta técnica

puede ser usada también en sistemas de contabilidad de empresas grandes y medianas

asociadas a las nóminas de los trabajadores o a sus movimientos económicos.

1.2.2 Amenazas Naturales

Otra de las amenazas de nuestros sistemas informáticos son precisamente las catástrofes

como: terremotos, maremotos, inundaciones por crecidas de ríos cercanos, penetraciones

del mar o desbordes de presa, ciclones, descargas eléctricas, incendios y otras. Las medidas

de protección contra estas catástrofes dependen de la probabilidad de ocurrencia, por lo

general las empresas no invierten en este tipo de eventos a menos que su ocurrencia sea

inminente. En los nodos de comunicaciones se deben tener equipos de protección contra

incendios. Aterramiento físico para asegurar el equipamiento de las descargas eléctricas.

Copias de seguridad de todo el sistema en medios ópticos y magnéticos que deben estar

guardados en otro local donde el peligro a este tipo de eventos sea mínimo. Todos estos



aspectos deben estar incluidos en el plan de contingencia, que son las acciones a tomar en

caso de un evento de este tipo.

3.1 Protecciones al Sistema Para proteger nuestro sistema debemos realizar el análisis de las amenazas potenciales que

puede sufrir, pérdidas que se podrían generar y probabilidad de ocurrencia. A partir de este

análisis hemos de diseñar una política de seguridad que defina reglas y responsabilidades

para evitar amenazas y minimizar sus efectos. Los mecanismos de seguridad son los usados

para implementar la política, y estos se dividen en tres grandes grupos, prevención,

detección y recuperación.

Los mecanismos de prevención prevén la ocurrencia de violaciones a la seguridad. Como

es el uso de cifrado en las transmisiones lo cual evita que las comunicaciones sean

escuchadas. Los mecanismos de detección son usados para detectar violaciones en la

seguridad o intentos de violación, en este grupo se encuentran los sistemas de auditoría,

sistemas de detección de intrusos. Los mecanismos de recuperación, que son aplicables

cuando ocurre algún evento que haya generado la pérdida de información sensible,

ejemplos de estos mecanismos son las copias de seguridad o hardware redundante. En este

punto, las técnicas de análisis forense, nos ayudan a averiguar la forma y el alcance de la

violación, lo que nos permite prevenir ataques posteriores. Los mecanismos de prevención

y detección son los más importantes, ya que si están bien concebidos, será menos probable

que necesitemos usar el tercero. [Lucena López, Manuel José (2002)]

1.3 Seguridad Física

La seguridad física es un aspecto que no debemos descuidar; de nada vale tener medidas de

seguridad muy bien definidas si cualquiera puede acceder físicamente a nuestros

servidores, estaciones, impresoras, cintas de backup, y otros medios de cómputo. Sin

importar la robustez de un cortafuego, si un intruso puede acceder físicamente a una

máquina, se puede llevar el disco duro y acceder a la información confidencial, no tendrá

que devanarse los sesos en burlar las políticas de seguridad.



En una sala de cómputo no es muy complicado para un intruso levantar una máquina con

un disco de inicio y acceder a la información del disco duro que le está vedada por

permisos del sistema.

1.4 Ataques Genéricos.

Las vulnerabilidades pretenden describir las debilidades y los métodos más comunes que se

usan para llevar a cabo ataques a la seguridad. Estos pueden estar motivados por diversos

objetivos, incluyendo fraude, extorsión, robo de información confidencial, venganza,

acceso no autorizado a un sistema o anulación de un servicio.

Ingeniería Social

La ingeniería social es una manipulación verbal que en la mayoría de los casos se lleva a

cabo bajo identidad encubierta, ya sea por teléfono o a través de terceras personas y su

alcance depende de la creatividad del atacante y de la ingenuidad de la víctima. Para ello el

intruso se hacen pasar por el administrador o alguien importante, falseando la dirección de

origen de un correo electrónico o mediante el teléfono para que el usuario le facilite su

clave o le revele algún tipo de información que pueda necesitar. [Mclure, Stuar (2001)]

Shoulder Surfing

Es un ataque relacionado con la ingenuidad de los usuarios y consiste en espiarlos

físicamente. Esta técnica es muy eficiente con aquellos que escriben sus contraseñas en una

pegatina que luego ponen en el monitor, o la escriben en una agenda que olvidan en

cualquier lugar. Esta irresponsabilidad es comparable con tener en casa un sistema de

seguridad excepcional y al salir dejar la llave bajo la alfombra.

Basureo (Trashing):

Descuidar el paradero de nuestros borradores de papel donde escribimos contraseñas,

recados del teléfono y todo tipo de información, puede resultar peligroso. Una factura

arrojada a la basura, donde se encuentren nombres de empleados, direcciones particulares,

números de teléfono, puede convertirse en información valiosa para ser usada en técnicas

de ingeniería social. Por estas mismas razones las cintas magnéticas o discos duros no



deben ser tirados sin antes destruirlos. También se recomienda cortar o incinerar todos los

papeles que no necesiten ser almacenados.

Huella de Identificación (Footprinting):

El intruso que desea atacar nuestro sistema necesita toda la información posible. Desde el

tipo de empresa, el área en que se desarrolla, su solvencia económica, sus clientes, cantidad

de empleados, tipos y características de los sistemas implementados (tecnologías de red,

sistemas telefónicos), niveles de seguridad física por solo mencionar algunos. Muchos de

estos los puede averiguar sencillamente preguntándole a algún trabajador con una excusa

justificable o consultando servicios de DNS, páginas Web de la empresa y anuncios

publicitarios. Las demás a través de herramientas propias de los sistemas operativos (ping,

whois, finger, rusers, nslookup, rcpinfor, telnet, dig, nmap). [Mclure, Stuar (2001)]

Envenenamiento IP o ARP (Spoofing).

Las relaciones de confianza basada en direcciones IP pueden ser burladas por el spoofing,

mediante el cual es suplantada la identidad de la máquina en la que se confía. Los

cortafuegos implementan sus reglas basadas en los sockets (número IP y puerto). Si alguien

llega a suplantar alguna de las máquinas que nuestro sistema considera confiables, estamos

perdidos. El spoofing puede ser IP o ARP, los sistemas operativos de Windows detectan la

suplantación de IP, pero las versiones de Linux (Red Hat) no. Cuando el envenenamiento

es ARP es más difícil de detectar porque la máquina del intruso funciona de puente entre

las estaciones y no se interrumpe la comunicación [Villalón Huerta, Antonio (2002)]. Para

este tipo de ataque se recomienda la herramienta ARPWatch de Linux que es capaz de

detectar cualquier cambio de ARP ocurrido en la subred y emite alarmas en la consola o las

envía por correo electrónico.

Escaneo de puertos:

A partir de las respuestas de los protocolos (TCP o UDP), como resultado de intentos de

conexión por determinados puertos, podemos obtener información acerca de los servicios

ofrecidos, los sistemas operativos y la versión de la aplicación que brinda el servicio. Una

vez conocida la versión de la aplicación, investigamos sus vulnerabilidades. Casi la



totalidad de los sistemas de detección de intrusos son capaces de detectar los escaneo de

puertos, el cual no llega a ser un ataque pero es sin dudas la antesala [Asaka, Midori

(1999)]. Como Sistema de Detección de Intrusos basado en Red (en adelante NIDS) se

recomienda el SNORT, en su versión para Linux. El NIDS debe ser implementado en un

punto donde sea capaz de analizar todo el tráfico relativo a las máquinas que desee

proteger.

Negación de Servicio (DoS):

Los ataques de negación de servicio DoS (Denial of Service) [Kashiwa, Dai (2002)]

dirigidos contra recursos informáticos, cuyo objetivo es degradar parcial o totalmente los

servicios. Pueden estar orientados a una máquina, una red o cualquier aplicación, como un

servidor Web, FTP, mail, DNS o cualquier otro.

Con el desarrollo de los DoS han aparecido los DDoS o negaciones de servicio distribuido

(Distributed Denial of Service), donde el atacante compromete un determinado número de

máquinas que en un momento dado hacen un ataque simultáneo a un objetivo determinado

[Hazeyama, Hiroaki (2003)]. En la actualidad encontramos muchos virus cuya finalidad es

provocar un ataque de negación de servicio distribuido sobre una página específica de

Internet. Ejemplo de ello lo constituye el Blaster, el cual causo grandes estragos en el 2004.

[Vsantivirus, (2004)].

Intercepción:

El sniffing es una de las técnicas de intercepción más usadas, en la cual el atacante captura

en tiempo real los paquetes que viajan por la red a partir de los cuales puede obtener

información de servicios, arquitectura de la red, contraseñas, mensajes de correo

electrónico y todo tipo de información privada. Otra variante de interceptación la

constituyen los keyloggers que son programas capaces de captar las pulsaciones del

teclado. Estos son muy usados para el robo de contraseñas, aunque para hacerlo funcionar

el atacante tiene que acceder físicamente a la máquina o tener privilegios administrativos.



1.5 Importancia de la Criptografía.

Según Jorge Ramiró Aguirre profesor titular en el Departamento de Lenguajes, Proyectos

y Sistemas Informáticos de la Universidad Politécnica de Madrid “Criptografía es la Rama

inicial de las Matemáticas y en la actualidad, de la Informática y la Telemática, que hace

uso de métodos y técnicas con el objetivo principal de cifrar un mensaje o archivo por

medio de un algoritmo, usando una o más claves. Esto da lugar a diferentes tipos de

criptosistemas que permiten asegurar cuatro aspectos fundamentales de la seguridad

informática: confidencialidad, integridad, disponibilidad y no repudio.” [Ramiró, Aguirre

Jorge (2003)]

La criptografía ha posibilitado la solución de la mayoría de los problemas de seguridad de

nuestras redes y representa la base de los protocolos y mecanismos de seguridad que

existen en estos momentos.

1.5.1 Sistemas de cifrado simétrico.

Los sistemas de cifrado simétrico utilizan la misma clave para cifrar y descifrar un

documento. El principal problema de seguridad reside en el intercambio de llaves entre el

emisor y el receptor ya que ambos deben usar la misma, Figura 1. Por lo tanto se tiene que

buscar también un canal de comunicación que sea seguro para dicho intercambio. Es

importante que dicha llave sea muy difícil de adivinar ya que hoy día los ordenadores

pueden adivinar claves en cortos periodos de tiempo. Por ejemplo el algoritmo de cifrado

DES usa una clave de 56 bits, con 72 mil billones de claves posibles; ordenadores

especializados son capaces de probar todas ellas en cuestión de horas. En la actualidad se

están utilizando claves de 128 bits que aumentan el "espectro" de claves posibles (2

elevado a 128) de forma que aunque se uniesen todos los ordenadores existentes en estos

momentos no lo conseguirían en miles de millones de años. [Horng, Gwoboa (2002)]



Figura 1 Sistema de Cifrado Simétrico.

1.5.2 Sistemas de cifrado asimétrico.

También son llamados sistemas de cifrado de clave pública y usan dos claves diferentes.

Una es la clave pública y se puede enviar a cualquier persona y la clave privada, que debe

guardarse para que nadie tenga acceso a ella. Para enviar un mensaje, el remitente usa la

clave pública del destinatario para cifrar el mensaje. Una vez que lo ha cifrado, solamente

con la clave privada del destinatario se puede descifrar, ni siquiera el que ha cifrado el

mensaje puede volver a descifrarlo, Figura 2.

Figura 2 Sistema de Cifrado Asimétrico.

En un sistema de cifrado asimétrico la clave pública contiene un número compuesto de dos

números primos muy grandes. Para cifrar un mensaje, el algoritmo de cifrado usa ese

compuesto. Para descifrar el mensaje, el algoritmo de descifrado requiere conocer los

factores primos, y la clave privada tiene uno de esos factores, con lo que puede fácilmente

descifrar el mensaje [Hanaoka, Goichiro (2004)]. Es fácil, con los ordenadores de hoy día,

multiplicar dos números grandes para conseguir un número compuesto, pero es muy difícil

la operación inversa. Dado ese número compuesto, factorizarlo para conocer cada uno de

los dos factores. Mientras que 128 bits se considera suficiente en las claves de cifrado

simétrico, y dado que la tecnología de hoy día se encuentra muy avanzada, se recomienda



en este caso que la clave pública tenga un mínimo de 2048 bits. Para un ataque de fuerza

bruta, sobre una clave publica de 512 bits, se debe factorizar un número compuesto de

hasta 155 cifras decimales.

1.5.3 Sistemas de cifrado híbridos.

El sistema de cifrado híbrido usa tanto los sistemas de clave simétrica como el de clave

asimétrica. Mediante el cifrado de clave pública se comparte una clave para el cifrado

simétrico. En cada mensaje, la clave simétrica utilizada es diferente por lo que si un

atacante pudiera descubrir la clave simétrica, solo le valdría para ese mensaje y no para los

restantes. Tanto PGP como GnuPG usan sistemas de cifrado híbridos. La clave simétrica es

cifrada con la clave pública, y el mensaje saliente es cifrado con la clave simétrica, todo

combinado automáticamente en un sólo paquete. El destinatario usa su clave privada para

descifrar la clave simétrica y acto seguido usa la clave simétrica para descifrar el mensaje.

[Lee, Narn-Yih (2002)]

Capitulo 2 – Protocolos y Mecanismos de Seguridad


Capitulo 2: Protocolos y mecanismos de seguridad

La seguridad informática es un tema muy amplio, por lo que nos vamos a centrar en

algunos protocolos y mecanismos de seguridad. Los demás que se consideren importantes y

por cuestiones de tiempo no hayan sido tratados en este capítulo quedarán para futuras

investigaciones o continuación de este mismo trabajo. Entre los protocolos no tratados se

encuentran IPv6, TLS, y SASL por solo mencionar algunos.

2.1 Kerberos

Uno de los sistemas de autentificación más importante lo constituye Kerberos, el cual fue

creado en el MIT (Massachussetts Institute of Technology) en 1983 con el proyecto Athena.

Su nombre se debe al perro de tres cabezas que en la mitología griega vigila la puerta de la

entrada al reino de Hades. [J. Kohl (1993)]. RFC 1510.

El uso de kerberos se produce principalmente en el inicio de sesión y en el acceso a otros

servidores de aplicación. Una vez que un cliente está autenticado o bien se asume que todos

sus mensajes son confiables, o si se desea mayor seguridad se puede elegir trabajar con

mensajes seguros (autenticados) o privados (autenticados y cifrados). Kerberos se puede

implementar en un servidor que se ejecute en una máquina segura, mediante un conjunto

de bibliotecas que se utilizan tanto en los clientes como en las aplicaciones; se trata de un

sistema de autentificación altamente seguro que puede ser usado en sistemas de alta

disponibilidad. [Kim, Cheolhyun (2002)]

2.1.1 Arquitectura de Kerberos

Un servidor Kerberos se denomina KDC (Kerberos Distribution Center), y provee de dos

servicios fundamentales: el de autenticación (AS, Autentication Service) y el de ticket

(TGS, Ticket Granting Service). El AS tiene como función autenticar inicialmente a los

clientes y proporcionarles un ticket para comunicarse con el TGS. El Servidor de Ticket,

proporciona a los clientes las credenciales necesarias para comunicarse con un servidor

final que es quien realmente ofrece el servicio. El servidor Kerberos posee una base de



datos de sus clientes (usuarios o programas) con sus respectivas claves privadas, conocidas

únicamente por dicho servidor y por el cliente al que pertenece.

La arquitectura Kerberos se basa en tres objetos de seguridad: Clave de Sesión, Ticket y

Autenticador.

• La Clave de Sesión es una clave secreta generada por Kerberos y entregada a un

cliente para uso con un servidor durante una sesión; no es obligatorio utilizarla en

toda la comunicación con el servidor, solo si el servidor lo requiere (porque los

datos son confidenciales) o si el servidor es un servidor de autenticación. Se suele

denominar a esta clave CSK , para la comunicación entre un cliente C y un servidor

S. Las claves de sesión se utilizan para minimizar el uso de las claves secretas de

los diferentes agentes: estas últimas son válidas durante mucho tiempo, por lo que

es conveniente para minimizar ataques utilizarlas lo menos posible.

• El Ticket es un testigo entregado a un cliente para solicitar los servicios de un

servidor; garantiza que el cliente ha sido autenticado recientemente. Un ticket de un

cliente C para acceder a un servicio S se le denomina

skKttSCkSCticketCSS },,,,{)},({

21= . Este incluye el nombre del

cliente C, para evitar su posible uso por impostores, un periodo de validez [ 21 , tt ] y

una clave de sesión CSK asociada para uso de cliente y servidor. Kerberos siempre

proporciona el ticket ya cifrado con la clave secreta del servidor al que se le entrega.

• El autenticador es un testigo construido por el cliente y enviado a un servidor para

probar su identidad y la actualidad de la comunicación; solo puede ser utilizado una

vez. Un autenticador de un cliente C ante un servidor S se denota por

CSCS KtCkCauth },{)}({ = . Este autenticador contiene, cifrado con la clave de la

sesión, el nombre del cliente y un sello de tiempo (timestamp).

2.1.2 Autenticación

El protocolo de autenticación de Kerberos es un proceso en el que diferentes elementos

colaboran para conseguir identificar a un cliente que solicita un servicio ante un servidor



que lo ofrece; este proceso se realiza en tres grandes etapas, las cuales se describen a

continuación. En la siguiente tabla aparecen las abreviaturas usadas en esta sección.

C Cliente que solicita un servicio.

S Servidor que ofrece dicho servicio.

A Servidor de autenticación.

T Servidor de ticket.

CK Clave secreta del cliente.

SK Clave secreta del servidor que ofrece el servicio.

TK Clave secreta del servidor de ticket.

CTK Clave de sesión entre el cliente y el servidor de ticket.

CSK Clave de sesión entre cliente y servidor que ofrece el servicio.

2.1.3 Inicio de Sesión.

Inicialmente el cliente C necesita obtener las credenciales necesarias para acceder a otros

servicios. Para ello cuando un usuario se conecta a un sistema Unix o Windows

“Kerberizado” y teclea nombre de usuario y contraseña; el programa login envía el nombre

de usuario al servidor de autenticación de Kerberos para solicitar un ticket que le permita

comunicarse posteriormente con el Servidor de Ticket o TGS. (Mensaje 1 figura 1, Modelo

de autentificación Kerberos.)

C → A: C, T, N



Figura 3 Modelo de Autentificación Kerberos.

Si el usuario es conocido el servidor de autentificación Kerberos retorna un mensaje que

contiene: una clave para la comunicación con TGS y un sello de tiempo, cifrado con la

clave secreta del cliente; junto con un ticket para la comunicación con el TGS, cifrado con

la clave secreta de este servidor (mensaje 2).

TCCT kTCticketKNKCA )},({,},{:→

El programa login intentará descifrar CCT kNK },{ , con la clave que el usuario

proporciona, y si esta es correcta podrá obtener CTK y N: un cliente solo podrá descifrar

esta parte del mensaje a partir de su clave secreta, Kc (en este caso el password del

usuario). Una vez obtenida CTK , la clave para comunicar al cliente con el servidor de

ticket, el programa login la guarda para una posterior comunicación con el TGS y borra la

clave del usuario de memoria, ya que el ticket será suficiente para autenticar al cliente; este

modelo consigue que la contraseña nunca viaje por la red.

2.1.4 Obtención de Ticket

El cliente ya posee una clave de sesión para comunicarse con el servidor de ticket y el ticket

necesario para hacerlo, cifrado con la clave secreta de este servidor (el cliente no puede

descifrar este ticket). Cuando el cliente necesita acceder a un determinado servicio es

necesario que disponga de un ticket para hacerlo, por lo que lo solicita al TGS enviándole

un autenticador que el propio cliente genera, el ticket para comunicarse con el TGS, el



nombre del servicio al que desea acceder, el servidor que presta el servicio, y un indicador

de tiempo (mensaje 3):

NSkTCticketkCauthTC TCT ,,)},({,)}({:→

Cuando TGS recibe el ticket comprueba su validez y si todo es correcto retorna un mensaje

que contiene una clave para comunicación con S y un sello de tiempo cifrado con la clave

de sesión del par CT, junto a un ticket para que el cliente C y el servicio S se puedan

comunicar, cifrados con la clave secreta del servidor S (mensaje 4):

SCTCS kSCticketkNKCT )},({,},{:→

C solo podrá obtener CSK si conoce la clave secreta, CTK

2.1.5 Petición del servicio.

Tras obtener el ticket para comunicarse con S el cliente ya está preparado para solicitar el

servicio; para ello presenta la credencial autenticada ante el servidor final, que es quien va a

prestar el servicio. C se comporta de la misma forma que cuando solicitó un ticket a T:

envía a S el autenticador recién generado, el ticket y una petición que puede ir cifrada si el

servidor lo requiere, aunque no es necesario (mensaje 5):

} }{{ NpeticiónkTCticketkCauthSC SCS ,,),(,)(:→

El servidor envía entonces al cliente la prueba de actualidad cifrada con la clave secreta de

la sesión (mensaje 6):

CSkNCS }{:→

Sólo S pudo obtener CSK y por lo tanto enviar este mensaje.

2.1.6 Problemas de Kerberos

Uno de los principales problemas de Kerberos es que cualquier programa que lo utilice ha

de ser modificado siguiendo un proceso denominado kerberización. Esto implica

obviamente que se ha de disponer del código fuente de cada aplicación que se desee

kerberizar, y también supone una inversión de tiempo considerable para algunas

aplicaciones más o menos complejas que no todas las organizaciones se pueden permitir.



Otro problema y esta vez relacionado con la seguridad es la gran centralización del sistema.

Para un correcto funcionamiento se ha de disponer en todo momento del servidor Kerberos,

de forma que si la máquina que lo alberga falla, la red se torna inutilizable. Otro aspecto

importante es que casi toda la seguridad reside en el servidor que mantiene la base de datos

de claves, de forma que si este se ve comprometido, la red entera se verá amenazada.

Otro problema de seguridad es el uso de sellos de tiempo como prueba de frescura en

Kerberos. Esto obliga a que todas las máquinas que ejecutan servicios autenticados

mantengan sus relojes sincronizados. Además ese tiempo global ha de ser accesible a todas

las estaciones; aunque no se asuman que todas mantengan la hora exacta, si se les obliga a

mantenerse dentro de los márgenes si desean solicitar ticket, para lo que se necesitan

servidores de tiempo con los que los clientes puedan sincronizar periódicamente sus

relojes.

Todos estos problemas han propiciado que el uso de Kerberos no esté muy extendido. En la

mayoría de las redes es suficiente con un protocolo de comunicación cifrado para mantener

una mínima seguridad, de forma que el complejo modelo de Kerberos se ve sustituido a ese

efecto por programas tan simples y trasparentes como SSL.

2.2 Certificados Digitales

Los Certificados Digitales, documentos electrónicos basados en la criptografía de clave

pública y en el sistema de firmas digitales, garantizan con toda confianza el vínculo

existente entre una persona, entidad o Servidor Web con una pareja de claves

correspondientes a un sistema criptográfico de clave pública. [Liska, Allan (2002)]

El certificado digital contiene datos identificativos de una persona o entidad y la llave

pública de la misma; haciéndose responsable de la autenticidad de los datos que figuran en

el certificado de otra persona o entidad de confianza, denominada Autoridad Certificadora

(AC). Las principales Autoridades Certificadoras actuales son Verisign (filial de RSA Data

Security Inc.) y Thawte. Estas entidades atestiguan que la persona portadora de ese

documento es quien dice ser. El formato de los certificados digitales es estándar, siendo



X.509 v3 el recomendado por la Unión Internacional de Comunicaciones y el que está en

vigor en la actualidad.

Los datos que figuran en un certificado son:

1. Versión: versión del estándar X.509, generalmente la 3, que es la más actual.

2. Número de serie: número identificador del certificado, único para cada certificado

expedido por una AC determinada.

3. Algoritmo de firma: algoritmo criptográfico usado para la firma digital.

4. Autoridad Certificadora: datos sobre la autoridad que expide el certificado.

5. Fechas de inicio y de fin de validez del Certificado: define el periodo de validez del

mismo, que es generalmente un año.

6. Propietario: persona o entidad vinculada al certificado. Dentro de este apartado se

usan una serie de abreviaturas para establecer datos e identidad.

7. Llave pública: la llave pública vinculada a la persona o entidad, junto con el

algoritmo criptográfico para el que es aplicable.

8. Firma de la autoridad Certificadora: que asegura la autenticidad del mismo.

9. Información adicional: como tipo de certificado, etc.

El Certificado Digital mediante el sistema de firmas digitales se asegura que el certificado

que recibimos es realmente de la persona que consta en el mismo. En el procedimiento de

firma digital se obtiene un resumen de un documento y se cifra con la llave privada del

propietario del certificado. Cuando nos llega el certificado y su firma digital asociada, tan

solo debemos obtener nosotros el resumen, descifrar la firma con la llave pública del

remitente y comprobar que ambos resúmenes coinciden, lo que nos hace estar seguros de

la autenticidad del certificado.

Para obtener el resumen del documento se utilizan las funciones Hash, algoritmos

criptográficos muy rápidos, de uso irreversible. Los procesos de validación de certificados,

obtención de resúmenes, descifrados y comprobación de coincidencia se realizan por el

software adecuado del navegador Web o programa de seguridad particular de forma



transparente al usuario, por lo que este será informado sólo en el caso de que el certificado

no sea válido.

2.2.1 Validez de los Certificados Digitales

Los certificados digitales, no son documentos imperecederos. Al estar basados en el uso de

claves no conviene que sean válidos por períodos de tiempo largos. Además de que con el

tiempo los equipos informáticos van aumentando su poder de cálculo, facilitando así la

labor de los criptoanalistas. Razón por la cual con el tiempo se deben ir aumentando el

tamaño de las claves criptográficas. Como regla general los certificados digitales tienen un

período de vida aproximadamente de un año.

En ocasiones es necesario anular un certificado porque se cree que las claves estén

comprometidas. Esta revocación puede llevarla a cabo el propietario del mismo, la

Autoridad Certificadora o las autoridades judiciales. Las Autoridades de Certificación han

implementado unos servidores especiales que contienen los certificados anulados, que se

conocen con el nombre de Lista de Certificados Revocados, CRL. Un CRL es un archivo,

firmado por la AC que contiene la fecha de emisión del mismo y una lista de Certificados

revocados. Cuando nuestro navegador recibe un Certificado Digital, comprueba antes de

darlo por bueno, que no se encuentre en la lista más actualizada de certificados revocados;

si aparece será rechazado.

2.2.2 Emisión de Certificados Digitales

Para solicitar un certificado a una AC la entidad interesada debe cumplir procedimientos

previos, confeccionando un documento, denominado Requerimiento de Certificación, en el

que deben figurar los datos representativos del solicitante y su llave pública. También debe

manifestar su voluntad de aceptar dicha llave pública y demostrar que es el propietario real

de la llave privada asociada, mediante el firmado digital de un mensaje.

Para verificar la veracidad de estos datos se han creado entidades intermedias, conocidas

como Autoridades Registradoras (AR), autorizadas por las AC, y cuya misión es

comprobar la validez de los datos presentados en el Requerimiento de Certificación. Las

AC disponen de servidores de acceso público que realizan la función de depósito de



certificados, en los que se puede buscar el deseado y descargarlo a nuestro ordenador.

Existen otras entidades que pueden expedir certificados que son las entidades

gubernamentales y otras entidades que compran un servicio de certificación a un vendedor

que haya sido a su vez certificado por una AC.

2.2.3 Tipos de Certificados

Dependiendo del uso que se vaya a dar al certificado y de qué persona o entidad lo

solicita, las Autoridades Certificadoras han dividido los certificados en varios tipos. Desde

el punto de vista de la finalidad, los certificados electrónicos se dividen en:

1. Certificados SSL para cliente: usados para identificar y autenticar a clientes ante

servidores en comunicaciones mediante el protocolo Secure Socket Layer (SSL), y se

expiden normalmente a una persona física.

2. Certificados SSL para servidor: usados para identificar a un servidor ante un cliente en

comunicaciones mediante el protocolo Secure Socket Layer, y se expiden generalmente a

nombre de la empresa propietaria del servidor seguro o del servicio que éste va a ofrecer,

vinculando también el dominio por el que se debe acceder al servidor. La presencia de éste

certificado es condición imprescindible para establecer comunicaciones seguras SSL.

3. Certificados S/MIME: usados para servicios de correo electrónico firmado y cifrado,

que se expiden generalmente a una persona física. El mensaje lo firma digitalmente el

remitente, lo que proporciona Autenticación, Integridad y No Rechazo. También se puede

cifrar el mensaje con la llave pública del destinatario, lo que proporciona confidencialidad

al envío.

4. Certificados de firma de objetos: usados para identificar al autor de ficheros o

porciones de código en cualquier lenguaje de programación que se deba ejecutar en red

(Java, JavaScript, CGI, etc.). Cuando un código de éste tipo pueda resultar peligroso para el

sistema del usuario, el navegador lanza un aviso de alerta, en el que figurará si existe

certificado que avale al código, con lo que el usuario puede elegir si confía en el autor,

dejando que se ejecute el código, o si por el contrario no confía en él, con lo que el código

será rechazado.

5. Certificados para AC: identifican a las propias Autoridades Certificadoras, y es usado

por el software cliente para determinar si pueden confiar en un certificado cualquiera,



accediendo al certificado de la AC y comprobando que esta es de confianza. Toda persona

o entidad que desee obtener un certificado debe pagar una cuota a las Autoridades de

Certificación, cuota que irá en función de la clase del certificado y del uso que se le vaya a

dar al mismo.

2.3 SSL (Secure Socket Layer).

Secure Socket Layer, es un protocolo basado en la aplicación conjunta de Criptografía

Simétrica, Criptografía Asimétrica, Certificados Digitales y Firmas Digitales. SSL

aprovecha de los sistemas simétricos la rapidez de la operación, y de los sistemas

asimétricos la seguridad para el intercambio de claves simétricas, consiguiendo con ello

resolver el problema de la confidencialidad en la transmisión de datos. [Thomas, Stephen

A. (2000)]

SSL implementa un protocolo de negociación para establecer una comunicación segura a

nivel de socket, de forma transparente al usuario y a las aplicaciones que lo usan. Es el

estándar de comunicación seguro en los navegadores Web. Garantiza la identidad del

servidor Web mediante el Certificado Digital correspondiente, del que se comprueba su

validez antes de iniciar el intercambio de datos sensibles (Autenticación), mientras que de

la seguridad de la integridad de los datos intercambiados se ocupa la Firma Digital

mediante funciones hash y la comprobación de resúmenes de todos los datos enviados y

recibidos.

Desde el punto de vista de su implementación en los modelos de referencia OSI y TCP/IP,

SSL se encuentra situado entre la capa de Aplicación y la capa de Transporte, sustituyendo

los socket del sistema operativo, lo que hace que sea independiente de la aplicación que lo

utilice y generalmente se implementa en el puerto 443. Su versión más actual es la 3.0. que

usa los algoritmos simétricos de encriptación DES, TRIPLE DES, RC2, RC4 e IDEA, el

asimétrico RSA, la función hash MD5 y el algoritmo de firma SHA-1. Los algoritmos,

longitudes de clave y funciones hash de resumen usados en SSL dependen del nivel de

seguridad que se busque y se soporte.



2.3.1 Protocolos de SSL.

Para establecer una comunicación SSL es necesario que previamente el cliente y el servidor

realicen un proceso de reconocimiento mutuo y de petición de conexión que, al igual que

en otros tipos de comunicaciones, recibe el nombre de apretón de manos o handshake, que

en este caso está controlado por el Protocolo SSL Handshake, que se encarga de

establecer, mantener y finalizar las conexiones SSL.

El protocolo comienza con el saludo del cliente al servidor, conocido como ClientHello,

por el que se informa al servidor de que se desea establecer una comunicación segura con

él. Junto con este saludo inicial, el cliente envía al servidor información de la versión de

SSL que tiene implementada, de los algoritmos de encriptación que soporta, las longitudes

de clave máximas que admite para cada uno de ellos y las funciones hash que puede

utilizar. También se le solicita al servidor el envío de su Certificado Digital X.509 v3, con

objeto de verificar el cliente la identidad del mismo y recoger su clave pública. En este

momento se asigna un identificador a la sesión y se hace constar la hora y fecha de la

misma.

A continuación, el servidor SSL responde al cliente en el proceso que se conoce con el

nombre de ServerHello, que al igual que el anterior se envía su Certificado Digital y demás

datos. Generalmente se obtiene el conjunto de algoritmos, longitudes de clave y funciones

hash soportados por ambos, eligiéndose entonces los más fuertes. A veces, y si la

comunicación posterior así lo exige, el servidor solicita al cliente su Certificado Digital, en

el mensaje llamado CertificateRequest. Esto sólo suele ocurrir en SSL cuando los datos a

transferir sean especialmente sensibles y precisen la previa autenticación del cliente. Si es

el caso, el cliente debe contestar al servidor mediante el mensaje CertificateVerify,

enviándole entonces su certificado.

En este momento el cliente verifica la validez del Certificado Digital del servidor,

desencriptando el resumen del mismo y comprobando su corrección, verificando que ha

sido emitido por una Autoridad Certificadora de confianza, que esté correctamente firmado

por ella y que el certificado no esté revocado. También se comprueba que la fecha actual



está dentro del rango de fechas válidas para el certificado y que el dominio (URL) que

aparece en el certificado se corresponde con el que se está intentando establecer la

comunicación segura. Si alguna de estas validaciones falla, el navegador del cliente

rechazará la comunicación, dándola por finalizada e informando al usuario el motivo del

rechazo.

En caso de que el servidor no tenga un Certificado X.509 v3 se puede utilizar un mensaje

ServerKeyExchange para enviar la clave pública sin certificado, en cuyo caso queda en

manos del cliente la elección de si acepta la llave o no, lo que finalizaría el proceso. Como

medida adicional de seguridad, el cliente genera una clave aleatoria temporal y se la envía

al servidor, que debe devolvérsela cifrada con su clave privada. El cliente la descifra con la

llave pública y comprueba la coincidencia, con lo que está totalmente seguro de que el

servidor es quién dice ser.

Y un proceso análogo a éste, pero en sentido inverso, se requiere si es necesaria la

autenticación del usuario ante el servidor. Si todo está correcto el cliente genera un número

aleatorio que va a servir para calcular una clave de sesión correspondiente al algoritmo de

encriptación simétrico negociado antes, conocida con el nombre de clave maestra, que es

enviada al servidor de forma segura encriptándola asimétricamente con la llave pública del

mismo que aparece en el Certificado Digital. Esta clave maestra se usará para generar todas

las claves y números secretos utilizados en SSL.

Con esto, servidor y cliente se han identificado y tienen en su poder todos los componentes

necesarios para empezar a transmitir información cifrada simétricamente. Se pasa entonces

el control al subprotocolo Change Cipher Spec, iniciándose la conexión segura. Así y todo,

para que empiecen las transmisiones de datos protegidos se requiere otra verificación

previa, denominada Finished, consistente en que cliente y servidor se envían uno al otro

una copia de todas las transacciones llevadas a cabo hasta el momento, encriptándola con la

llave simétrica común. Al recibir esta copia, cada máquina la desencripta y la compara con

el registro propio de las transacciones. Si las transacciones de las dos computadoras



coinciden significa que los datos enviados y recibidos durante todo el proceso no han sido

modificados por un tercero. Se termina entonces la fase Handshake.

Para empezar a transmitir datos cifrados es necesario que cliente y servidor se pongan de

acuerdo respecto a la forma común de encapsular los datos que se van a intercambiar, es

decir, qué formato de datos se va a usar en la transmisión cifrada. Esto se realiza mediante

el protocolo SSL Record (Protocolo de Registro SSL). Este se encarga de la seguridad en el

intercambio los datos que le llegan desde las aplicaciones superiores, usando para ello los

parámetros de encriptación y resumen negociados previamente mediante el protocolo SSL

Handshake.

Por último, cuando la transferencia de mensajes ha finalizado y se desea cerrar la

comunicación segura, la aplicación cliente (el navegador Web) lanza una ventana de aviso

de que se va a cerrar la comunicación SSL, y si es aceptada por el usuario, se sale de la

misma y se regresa a una comunicación normal, finalizando el proceso SSL.

SSL Handshake posee además otro subprotocolo específico, denominado Alerta, que se

encarga de avisar de los problemas que ocurren durante la conexión, y que pueden llevar a

la finalización brusca de la sesión.

2.3.2 Ventajas de SSL

Es una tecnología rápida, fácil de implementar, barata y cómoda para el usuario, que no

tiene que conocer cómo funciona, tan sólo usarla. Proporciona un canal de comunicaciones

seguro entre los servidores Web y los clientes, pero su uso no se limita a este tipo de

aplicaciones. Al encontrarse entre los niveles de transporte y de aplicación, potencialmente

SSL puede servir para asegurar otros servicios, como FTP, correo, telnet, etc. El usuario no

necesita realizar ninguna acción especial para invocar el protocolo SSL, basta con seguir un

enlace o abrir una página cuya dirección empieza por https://. El navegador se encarga del

resto.



2.3.3 Limitaciones y problemas de SSL

Sólo garantiza la confidencialidad e integridad de los datos en transito, pero nunca ates ni

después. Por lo tanto, si se envían datos personales al servidor, solamente asegura que no

serán modificados ni espiados mientras viajan desde el navegador hasta el servidor. Lo que

el servidor haga con ellos esta más allá de la competencia de este protocolo. Tampoco

garantiza la identidad del servidor al que se conecta el usuario. Podría suceder que el

servidor seguro contase con un certificado perfectamente válido y que estuviera

suplantando la identidad de algún otro servidor seguro bien conocido. Por consiguiente, es

de extrema importancia que se compruebe siempre el certificado del sitio Web para

cerciorarse de que no se esta conectando a un Web falsificado.

El servidor identifica al navegador incluso aunque este no se autentique mediante

certificados. Cuando un usuario se conecta a un servidor, rutinariamente le comunica

ciertos datos como su dirección IP, tipo y versión de su navegador, sistema operativo, y

otros.

2.4 SSH

El protocolo SSH es usado para acceder a máquinas a través de una red, de forma similar a

como se hacía con telnet. La diferencia principal es que SSH usa técnicas de cifrado para

que ningún atacante pueda descubrir las contraseñas ni espiar el desarrollo de la sesión.

Además de la conexión a otras máquinas, SSH nos permite copiar datos de forma segura y

gestionar claves RSA. Este protocolo es muy usado para la administración de servidores

Unix y para el intercambio seguro de ficheros entre Unix y Windows. [Stanger, James

(2001)]

La primera versión del protocolo y el programa eran libres, pero su licencia fue cambiando

hasta que finalmente surgió una versión que se convertiría en la implementación libre por

excelencia, OpenSSH de OpenBSD.



2.4.1 Manejo básico de SSH

El protocolo SSH cuenta con dos versiones, la primera de ellas se mantiene por motivos de

compatibilidad, pero se recomienda generalmente el uso de la segunda, por su mayor

seguridad. OpenSSH es una implementación usada en sistemas Linux como cliente y

servidor para el uso de sesiones remotas seguras que ofrecen autenticación,

confidencialidad e integridad. Consta de tres componentes:

1. Nivel de trasporte: En este nivel se procede a la autenticación del servidor, el

establecimiento de un canal cifrado (confidencialidad), chequeo de integridad de los

mensajes, y un identificador único de sesión. Típicamente esta conexión se realiza

mediante TCP/IP.

2. Nivel de autentificación del Usuario: En este nivel se supone establecida la

encriptación e integridad del canal y la autentificación del servidor. Para la

autentificación del usuario el SSH ofrece varias posibilidades:

• Autentificación del usuario basada en claves Publica-Privada: la

autenticación del usuario se establece en base a la posesión de la clave

privada. El servidor SSH conoce la clave pública del usuario. Este es el

modo recomendado por los fabricantes que implementan SSH.

• Autentificación del usuario basada en contraseña. Hay que señalar que la

contraseña no viaja cifrada, sino en el canal por el que viaja es el que se

mantiene cifrado (el nivel de Transporte es un túnel).

• Autentificación del usuario basada en procedencia de la máquina: en esta

situación hay que proteger las claves privadas de la estación de trabajo

por parte del usuario. Es una autentificación parecida a la ofrecida por

otros sistemas de inicio de sesión por lo que es completamente

desaconsejable.

3. Nivel de conexión: Es el protocolo encargado de multiplexar el “Túnel encriptado”

en varios canales lógicos, para obtener múltiples sesiones en la ejecución de canales

remotos.

Este protocolo requiere que los servidores tengan "llaves", las cuales son usadas por los



clientes cada vez que se conectan a un servidor para verificar que no fue suplantado. Una

llave es un número codificado y cifrado en un archivo. Para la encriptación de llaves,

OpenSSH ofrece los algoritmos RSA y DSA.

2.5 IPSec

IPSec es un conjunto de estándares para integrar en IP funciones de seguridad basadas en

criptografía. Proporciona confidencialidad, integridad y autenticidad de datagramas IP,

combinando tecnologías de clave pública, algoritmos de cifrado, algoritmos de hash y

certificados digitales. [Tsukamoto, Katsuji (2002)]

El protocolo IPSec ha sido diseñado de manera modular, de forma que se pueda seleccionar

el conjunto de algoritmos deseados sin afectar a otras partes de la implementación. Está

compuesto por dos protocolos de seguridad: IP Authentication Header (AH) e IP

Encapsulating Security Payload (ESP) que proporcionan mecanismos de seguridad para

proteger el tráfico IP. Un protocolo de gestión de claves Internet Key Exchange (IKE) que

permite a dos nodos negociar las claves y los parámetros necesarios para establecer una

conexión. [Doraswamy, Naraganand (2003)]

2.5.1 El Protocolo AH

El protocolo AH garantiza la integridad y autenticación de los datagramas IP. Sin embargo

no proporciona ninguna garantía de confidencialidad, es decir, los datos transmitidos

pueden ser vistos por terceros. AH es una cabecera de autenticación que se inserta entre la

cabecera IP estándar y los datos transportados.



Figura 4Estructura de un datagrama AH.

El funcionamiento de AH se basa en aplicar una función hash a la combinación de unos

datos de entrada y una clave, siendo la salida una pequeña cadena de caracteres que

denominamos extracto. Dicho extracto tiene la propiedad de ser como una huella personal

asociada a los datos y a la persona que lo ha generado, puesto que es la única que conoce la

clave.

En la figura 5 se muestra el modo en que funciona el protocolo AH. El emisor calcula un

extracto del mensaje original, el cual se copia en uno de los campos de la cabecera AH. El

paquete se envía a través de la red, repitiéndose en el extremo receptor el cálculo del



extracto y comparándolo con el recibido en el paquete, si coinciden es que no ha sido

modificado.

Figura 5 Funcionamiento del Protocolo AH.

2.5.2 El Protocolo ESP

El protocolo ESP se encarga de proporcionar confidencialidad, para ello especifica el modo

de cifrar los datos que se desea enviar y como este contenido cifrado se incluye en un

datagrama IP. Dado que proporciona más funciones que AH el formato de la cabecera es

más complejo; este formato consta de una cabecera y una cola que rodea los datos

transportados. Dichos datos pueden ser cualquier protocolo IP (TCP, UDP o ICMP). En la

figura 6 se muestra la estructura de un datagrama ESP, en la que se observa como el

contenido o carga útil viaja cifrada. La función de cifrado dentro del protocolo ESP es

desempeñada por un algoritmo de cifrado de clave simétrica. Típicamente se usan

algoritmos de cifrado en bloques, por lo que existe un campo de relleno, el cual tiene como

función adicional ocultar su longitud real.



Figura 6 Estructura de un datagrama ESP.

2.5.3 Modos transporte y túnel

Los dos modos de funcionamiento que permite IPSec son:

1. El modo transporte. En este modo el contenido transportado dentro del datagrama

AH o ESP son datos de la capa de transporte (por ejemplo, datos TCP o UDP). Por

tanto, la cabecera IPSec se inserta a continuación de la cabecera IP y antes de los

datos de los niveles superiores que se desean proteger. El modo transporte tiene la

ventaja de que asegura la comunicación extremo a extremo, pero requiere que

ambos extremos entiendan el protocolo IPSec.

2. El modo túnel. En éste el contenido del datagrama AH o ESP es un datagrama IP

completo, incluida la cabecera IP original. Así, se toma un datagrama IP al cual se

añade inicialmente una cabecera AH o ESP, posteriormente se añade una nueva



cabecera IP que es la que se utiliza para encaminar los paquetes a través de la red.

El modo túnel se usa normalmente cuando el destino final de los datos no coincide

con el dispositivo que realiza las funciones IPSec.

El modo túnel es empleado principalmente por los gateways (puertas de enlace) IPSec, con

objeto de identificar la red que protegen bajo una misma dirección IP y centralizar de este

modo el procesado del tráfico IPSec en un equipo. El modo túnel también es útil, cuando se

utiliza junto con ESP, para ocultar la identidad de los nodos que se están comunicando.

Otra aplicación del modo túnel es poder establecer Redes Privadas Virtuales (VPN) a

través de redes públicas, es decir, interconectar de forma segura redes de área local, incluso

en el caso de que estas usen direccionamiento privado o no legal en Internet.

IPSec puede ser implementado bien en una máquina o bien en un equipo dedicado, tal

como un router o un firewall, que cuando realiza estas funciones se denomina gateway

IPSec. La Figura 7 muestra los dos modos de funcionamiento del protocolo IPSec, donde:

1. En la Figura 7a se representan dos estaciones que entienden IPSec y que se

comunican de forma segura. Esta comunicación se realiza en modo transporte, por

tanto la información que se protege es únicamente el protocolo TCP o UDP, así

como los datos de aplicación.

2. En la Figura 7b se muestran dos redes que utilizan para conectarse dos gateways

IPSec y, por tanto, emplean una implementación en modo túnel. Se puede ver que

la comunicación se realiza a través de una red de datos pública, entre una estación

situada en una red local con otra estación situada en una red remota, de modo que

entre los gateways IPSec se establece un túnel a través del cual viajan protegidas

las comunicaciones entre ambas redes locales.

Sin embargo ambas máquinas envían y reciben el tráfico en claro, como si

estuviesen situadas en la misma red local. Este esquema tiene la ventaja de que los

nodos situados en redes separadas pueden comunicarse de forma segura y



transparente, concentrándose, al mismo tiempo, las funciones de seguridad en un

único punto, facilitando así las labores de administración.

Figura 7 Los modos de funcionamiento transporte y túnel de IPSec.

2.5.4 IKE: El Protocolo de Control

Un concepto esencial en IPSec es el de asociación de seguridad (SA): es un canal de

comunicación unidireccional que conecta dos nodos, a través del cual fluyen los

datagramas protegidos mediante mecanismos criptográficos acordados previamente. Al

identificar únicamente un canal unidireccional, una conexión IPSec se compone de dos

SAs, una por cada sentido de la comunicación. El IETF ha definido el protocolo IKE para

realizar tanto esta función de gestión automática de claves como el establecimiento de las

SAs correspondientes.

En los estándares IPSec está previsto el uso de un método de autenticación que se basa en

utilizar certificados digitales X.509v3. El uso de certificados permite distribuir de forma

segura la clave pública de cada nodo, de modo que éste puede probar su identidad mediante

la posesión de la clave privada y ciertas operaciones de criptografía pública. La utilización

de certificados requiere de la aparición de un elemento más en la arquitectura IPSec, la PKI

(Infraestructura de Clave Pública).



2.5.5 Integración de IPSec con una PKI

El uso de una PKI aparece en IPSec como respuesta a la necesidad de un procedimiento

para autenticar de forma confiable a un conjunto de nodos que desean comunicarse

mediante IPSec, siendo dicho conjunto de nodos muy numeroso.

Bajo el nombre de PKI (Infraestructura de Clave Pública) se engloban todos los elementos

y procedimientos administrativos que permiten emitir, revocar y, eventualmente, renovar

los certificados digitales para una comunidad de usuarios. En el caso de IPSec los sujetos

de los certificados son los nodos IPSec, mientras que la función de los certificados es

proporcionar un medio confiable para autenticar la identidad de los dispositivos IPSec.

Cada uno de los dispositivos IPSec dispondrá de un certificado digital que contendrá su

clave pública y la información suficiente para identificar de forma unívoca al dispositivo

(tal como su nombre DNS, su dirección IP o su número de serie).

Esta asociación entre clave pública e identidad está avalada por la firma de la Autoridad de

Certificación (en adelante CA) integrada en la PKI, que da validez al certificado. Se supone

que todos los dispositivos IPSec reconocerán como válida la misma CA, para lo cual

deberán disponer de una copia del certificado de la propia CA.

Los protocolos para la interacción de los dispositivos IPSec con una PKI no están

especificados en ninguno de los protocolos de IPSec. Todos los fabricantes utilizan

X.509v3 como formato común de los certificados. Sin embargo, el protocolo de

comunicaciones, mediante el cual los dispositivos IPSec dialogan con la PKI, no está

totalmente estandarizado. En general los nodos IPSec necesitan realizar ciertas operaciones

básicas con una PKI: acceder al certificado de la CA, solicitar y descargar un certificado,

así como comprobar la validez de un certificado recibido.

En la actualidad, la mayoría de los nodos IPSec realizan la validación de los certificados

mediante consultas de la Lista de Certificados Revocados (CRL), que se almacena en el



directorio de la PKI. Para ello, cada uno de los nodos mantendrá una copia de la CRL, que

actualizará periódicamente mediante una consulta LDAP al directorio de la PKI.

Típicamente, los periodos de actualización de la CRL serán del orden de horas, de modo

que existirá cierto retardo desde que la PKI revoca un certificado hasta que todos los

dispositivos tengan constancia de dicha revocación.

Para la solicitud y descarga de certificados existe un protocolo denominado SCEP, que se

ha convertido en un estándar de facto en las operaciones de registro y descarga de

certificados para aplicaciones IPSec. SCEP es un protocolo desarrollado originalmente por

Cisco y Verisign, que se basa en el intercambio de mensajes PKCS, mediante protocolo

HTTP, para automatizar los procesos de solicitud y descarga de certificados.

En la Figura 8 se representan los flujos de comunicación entre una PKI y un nodo IPSec.

Inicialmente, cada uno de los nodos genera un par de claves (pública y privada) y envía una

petición de certificado a la CA, en la que incluye información de su identidad y su clave

pública. Al mismo tiempo, el nodo descarga el certificado raíz de la CA; a continuación, la

CA genera un certificado para el dispositivo IPSec y éste lo recibe. A partir de ese

momento el nodo IPSec podrá usar su certificado en una negociación IKE para autenticarse

frente a otros dispositivos. Periódicamente los dispositivos IPSec accederán al directorio de

la PKI para actualizar la CRL.



Figura 8 Integración de una PKI con IPSec

2.6 VPN Redes Privadas Virtuales

Con VPN se permite crear una red privada y segura sobre una red pública como Internet.

Puede ser creada utilizando software, hardware o una combinación de ambos que permita

crear un vínculo seguro entre pares sobre una red pública. Esto se consigue mediante

encriptación, autenticación, tunneling de paquetes y firewalls. [Doraswamy, Naraganand

(2003)]

En el caso de acceso remoto, la VPN permite al usuario acceder a su red corporativa,

asignándole a su ordenador remoto las direcciones y privilegios de la misma, aunque la

conexión la haya realizado por medio de un acceso a Internet público.

VPN consiste en dos máquinas (una en cada "extremo" de la conexión) y una ruta o "túnel"

que se crea dinámicamente en una red pública o privada. Para asegurar la privacidad de esta

conexión los datos transmitidos entre ambos ordenadores son encriptados y posteriormente

encaminados sobre una conexión previa (también remota, LAN o WAN) por un dispositivo

PPTP.



2.6.1 Tipos de Redes Privadas Virtuales

• Enlaces Cliente-Red:

Este tipo se usa fundamentalmente para:

o Acceso seguro de un cliente a la red.

o Clientes móviles (para independizarlos de la topología física).

o Puntos de acceso remoto.

• Enlaces Red-Red:

Este tipo se usa para:

o Unir dos redes locales a través de Internet, como si fueran una sola.

o Establecer canales con privacidad, autenticidad y control de integridad,

entre dos redes independientes.

2.6.2 Ventajas de las Redes Privadas Virtuales

La principal ventaja de usar una VPN es que permite disfrutar de una conexión a red con

todas las características de la red privada a la que se quiere acceder. El cliente VPN

adquiere totalmente la condición de miembro de esa red, con lo cual se le aplican todas las

directivas de seguridad y permisos de un ordenador en esa red privada, pudiendo acceder a

la información publicada para esa red privada: bases de datos, documentos internos, etc. a

través de un acceso público. Al mismo tiempo, todas las conexiones de acceso a Internet

desde el ordenador cliente VPN se realizarán usando los recursos y conexiones que tenga la

red privada.

Las aplicaciones VPN reducen los costos frente a otras soluciones de conectividad como

arriendo de líneas dedicadas u otros. Las VPN tienen un funcionamiento similar al de las

redes tipo WAN pero su costo es muchísimo inferior ya que utiliza la red de Internet para

comunicarse entre sí, permitiendo de esta manera tener comunicaciones rápidas y seguras.

No requiere de grandes inversiones en infraestructura. Los enlaces punto a punto implican

que la organización debe realizar una cuantiosa inversión inicial en equipamiento para

conectar cada una de las sucursales u oficina que posea. Sin embargo, con las VPN tanto la



inversión inicial como las tareas de instalación, operación y mantenimiento son mucho más

pequeñas.

Las diferencias reales entre las VPN y las WAN aparecen cuando se considera la

escalabilidad de ambas. Una gran WAN requiere una gran inversión en equipamiento

especialmente cuando se añaden múltiples redes a lo largo de la zona de actuación de la

organización. Con VPN, inicialmente solo se necesita una red central que solo necesitaría

una actualización del ancho de banda aunque se aceptaran conexiones desde múltiples

redes.

2.6.3 Inconvenientes de las Redes Privadas Virtuales

Mayor carga en el cliente VPN puesto que debe realizar la tarea adicional de encapsular los

paquetes de datos, situación que se agrava cuando además se realiza encriptación de los

datos lo que atenta contra la velocidad de la transmisión.

También se produce una mayor complejidad en el tráfico de datos que puede producir

efectos no deseados al cambiar la numeración asignada al cliente VPN y que puede requerir

cambios en las configuraciones de aplicaciones o programas (Proxy, Servidor de Correo,

permisos basados en nombre o número IP).

El objetivo fundamental de una VPN es proteger los datos durante la transmisión a través

de la red, permitiendo el uso de redes públicas como si fueran privadas (virtualmente

privadas). Esta protección previene el mal uso, modificación, uso no autorizado e

interrupciones de acceso a la información mientras atraviesa los distintos segmentos de la

red.

Una VPN no protege la información mientras esta alojada en el origen, o cuando llega y se

aloja en su destino. También puede dejar expuesto los datos durante algunos de los

procesos de encriptación en la red (redes internas antes de la encriptación o redes externas

después de la desencriptación). Una VPN solo protege la información en tránsito, no

protege la información alojada en el disco, en pantalla, o impresoras.



2.7 Otros Protocolos de Seguridad

2.7.1 PPTP

Point to Point Tunneling Protocol (antecesor de L2TP) fue diseñado para proporcionar

comunicaciones autenticadas y cifradas entre un cliente y un Gateway o entre dos Gateway

(sin necesidad de una infraestructura de clave pública) utilizando un ID de usuario y una

contraseña. Su objetivo era la simplicidad de su diseño, la compatibilidad multiprotocolo y

la capacidad de cruzar una amplia gama de redes IP.

2.7.2 L2TP

Layer To Tunneling Protocol es un protocolo estándar que encapsula las tramas del

protocolo punto a punto (PPP) que van a enviarse a través de las redes. L2TP se puede usar

como protocolo de túnel VPN en Internet. Las tramas PPP encapsuladas se pueden cifrar o

comprimir. Cuando los túneles L2TP aparecen como paquetes IP, aprovechan la seguridad

IPSec estándar para obtener una fuerte protección de integridad, autenticidad y privacidad.

L2TP se diseñó específicamente para conexiones Cliente-Servidor de acceso a redes y para

conexiones Gateway a Gateway.

2.7.3 SOCKS

Inicialmente fue aprobado para la autentificación ante firewall, aunque en la actualidad

combinado con SSL provee las bases para construir VPN altamente seguras. Permite la

conexión de equipos situados tras un firewall. Inicialmente fue pensado para permitir el

acceso desde una red interna a servicios disponibles en el exterior, sin embargo puede

emplearse en sentido contrario, para el acceso desde el exterior de la organización

(protegida por firewall).

La conexión es validada por el sistema de autentificación y después el servidor Socks actúa

de intermediario con la aplicación situada en el servidor destino. Socks actúa de “envoltura”

sobre el protocolo UDP-TCP permitiendo que los equipos protegidos por el firewall puedan



conectarse a una red insegura, utilizando su propia dirección y devolviendo los resultados

al cliente.

Debe notarse que Socks solo autentifica las conexiones, pero no produce ningún tipo de

cifrado de los datos, por lo que se hace necesario combinarlo con algún algoritmo que si lo

haga (SSH, SSL, PPTP, IPSec, etc.)

2.7.4 S/MIME

El protocolo MIME seguro fue propuesto por la empresa RSA y después de su aparición

fue propuesto como estándar por la IETF pero por problemas de derechos y restricciones de

patentes no pudo ser posible. S/MIME utiliza técnicas similares a PGP e incorpora

certificados X.509; aunque no cuente con el apoyo necesario para ser considerado un

estándar, está implementado en muchos programas de correo electrónico. Tiene la ventaja

sobre PGP, que al utilizar Autoridades de Certificación, es ideal par ser utilizado por

empresas y para el comercio electrónico.

2.7.5 SET

El Protocolo SET (Secure Electronic Tansaction) fue definido por las empresas VISA,

MasterCard, Microsoft, IBM, Netscape, Verisign, y otras; exclusivamente para realizar

comercio electrónico con tarjetas de crédito. Es un conjunto de protocolos, normas y

especificaciones de seguridad, que constituyen una forma estándar para la realización de

transacciones, reproduciendo en un entorno electrónico el pago con tarjeta de crédito física.

Establece diferentes entidades (Cliente, Vendedor, Banco) y un protocolo de

comunicaciones entre el Vendedor y el Banco. Cada una de estas entidades debe

certificarse antes de realizar cualquier transacción y cada mensaje queda firmado para

evitar modificaciones y repudio posteriores. [Villalon Huerta, Antonio (2002)]

2.7.5.1 Ventajas del protocolo SET

• Autentifica los titulares de las tarjetas de crédito, los comerciantes y los bancos que

intervienen en la operación. La autenticación asegura que los participantes en la

operación comercial sean quienes dicen ser: el consumidor sabe en qué comercio



está comprando y; el comercio está seguro de quién esta comprando realmente el

titular del instrumento de pago. La autenticación se realiza a través de certificados

digitales que tanto el comerciante como el comprador poseen.

• Garantiza la máxima confidencialidad de la información de pago. Toda la

información que viaja por la red, durante el intercambio de identidades y datos está

protegida contra cualquier intromisión o captura con métodos criptográficos.

• Asegura que los mensajes financieros no sean manipulados dentro del circuito del

proceso de pago. La integridad y la autenticidad se basan en la generación de firmas

digitales.

SET utiliza algoritmos de encriptación como SHA-1, DES y RSA ya que estos son

compatibles con los certificados existentes, aunque en próximas versiones se piensa dar

soporte a algoritmos de curvas elípticas.

Capitulo 3 – Aseguramiento de la Intranet UCLV


Capitulo3 Propuestas de Seguridad de la Intranet UCLV.

3.2 Intranet UCLV.

La Universidad Central “Martha Abreu” de las Villas cuenta con una intranet de alrededor

de 1120 computadoras repartidas en 14 áreas entre las que se encuentran facultades, centros

de investigación y administrativos. Como aspecto general cuenta con una intranet de tipo

Ethernet 10BASET o 100BASET y la interconexión física de las distintas dependencias

universitarias es a través de una Fast Ethernet 100BASEFX, un backbone de fibra óptica

multimodo 62.5/125 con topología estrella. En la figura 9 se aprecian las distancias de fibra

óptica y la ubicación física de las áreas.

Figura 9 Cableado de Fibra Óptica.

La Universidad asumió la dirección de clase B para redes de tipo privadas 172.20.0.0 con

mascara de subred 255.255.0.0 para lo cual se hizo la división del tercer byte en subredes,

quedando disponibles 255 subredes de 255 capacidades cada una. Estas subredes se fueron



asignando consecutivamente entre las áreas, y las que contaban con mas de 254 maquinas o

que por sus condiciones de estructura física no le era suficiente una subred, se le asignaron

dos. En estos momentos se encuentran disponible un número considerable de subredes para

uso posterior y futuras ampliaciones.

El centro tiene asignado el espacio de nombres UCLV.EDU.CU, del cual se derivan varios

espacios de nombre relativos a los diferentes dominios de Windows 2000 que existen en su

interior. Estos están asignados a las distintas áreas de la siguiente forma:

FIE.UCLV.EDU.CU Facultad de Ingeniería Eléctrica.

MFC.UCLV.EDU.CU Facultad Matemática-Física-Computación.

CEI.UCLV.EDU.CU Centro de Cálculo.

RECTORADO.UCLV.EDU.CU Rectorado.

AGRONET.UCLV.EDU.CU Facultad de Ciencias Agropecuarias.

FIM.UCLV.EDU.CU Facultad de Ingeniería Mecánica.

QF.UCLV.EDU.CU Facultad de Química – Farmacia.

CDICT.UCLV.EDU.CU Biblioteca Central.

CBQ.UCLV.EDU.CU Centro de Bioactivos Químicos.

FC.UCLV.EDU.CU Facultad de Construcción.

FCE.UCLV.EDU.CU Facultad de Ciencias Empresariales.

SOCIALES.UCLV.EDU.CU Facultad de Ciencias Sociales.

En un principio cada área era totalmente responsable de su sistema informático, se daban

de manera distribuida los servicios de correo electrónico, ficheros, FTP, WEB, bases de

datos, y demás aplicaciones en dependencia de las necesidades. De la misma forma se

manejaban los usuarios, los grupos de distribución, computadoras, impresoras y políticas de

seguridad. En ese momento no existía ningún tipo de relación de confianza entre las

facultades y no existían políticas de integración. Esta estructura tenía sobradas deficiencias

de manera que fue necesaria una reestructuración desde el punto de vista lógico. Para lo

cual fue necesario coordinar ideas para la estrategia de unificación.



Con este objetivo fue creado un dominio de Windows 2000 bajo el espacio de nombre

UCLV.EDU.CU el cual agrupó como dominio padre a los dominios ya existentes,

estableciéndose entre ellos relaciones de confianza con el objetivo de comenzar la

integración y homogenización de los sistemas informáticos.

Figura 10 Estructura de dominios de la UCLV.

Bajo esta nueva estructura la filosofía ha sido centralizar las aplicaciones en el dominio

UCLV.EDU.CU y en un nodo de comunicaciones (La Puerta) que cuenta con respaldo

eléctrico y condiciones excepcionales de hardware. En estos momentos tenemos

centralizadas las aplicaciones de Correo Electrónico, Acceso a Internet, Servidor de

ficheros (Librería de Software), Servidor de Media (Videos Educativos, Música, Películas,

Series), Servidor de Bases de Datos (Sistema de Control Docente), Servidor de Mensajería

Instantánea (Jabber) y Servidor de Monitoreo y Control (Nagios).



Las cuentas de usuarios aún se encuentran en las áreas pero serán movidas hacia el dominio

UCLV.EDU.CU con el objetivo de lograr una mayor estabilidad. El resto de los dominios

no van a desaparecer; ahí seguirán las cuentas de las maquinas, impresoras, y demás

objetos, con el objetivo de que cada dependencia, aplique su propia políticas de seguridad.

Con el desarrollo y la centralización de las aplicaciones en la Red UCLV el tráfico ha ido

aumentando en el backbone de fibra, para lo cual será aumentada la velocidad hasta 1

Gbps. Basándose en una infraestructura de switch Allied Telesync como se muestra en la

figura 11. Los cuales son capa3, gestionables por telnet, ssh y web, tienen soporte para

SNMP, IPSEC, VPN, FIREWALL, RIP, OSPF por solo mencionar algunos.

Figura 11 Esquema del Backbone Gigabit con tecnología Allied Telesync.

3.3 Disponibilidad de Conexión de la Intranet.

Nuestra Intranet se conecta a la red pública de Internet a través de dos servidores Red Hat

Linux, modo consola. En estos están montados los servicios de DNS primario y secundario



(Named); Servicio de Proxy (Squid), para el acceso a Internet; Proxy Inverso (Squid).

Transporte de correo entrante y saliente (Sendmail) y servicio de mensajería instantánea

(Jabber). Estos servidores se les conocen con el nombre de servidores reales ya que

cuentan con una numeración de IP real para Internet.

Como estos son los que llevan todo el peso de la comunicación de la Intranet con el

mundo; se propone para asegurar su disponibilidad un esquema de servicios redundantes;

con un total de cuatro máquinas, todos los servicios estarían duplicados como se observa en

la figura 12. Esta solución se brinda con el objetivo de reducir al mínimo el tiempo de

recuperación en caso de que falle algún servicio o sea necesario que cualquiera de estos

servidores salga de operación por actualización del sistema o para análisis forense porque

se vio comprometida su seguridad. Los servicios redundantes solamente estarían

configurados, pero no activados, entrarían en operación solamente si es necesario por las

razones antes expuestas y se realizaría de forma manual. Para automatizar este proceso se

necesita programar un módulo para el Nagios. Al ser servidores dedicados son

administrados por SSH desde las máquinas de administración del nodo central. El servicio

de SSH esta filtrado por el firewall de los servidores (Iptables).

Proxy-01 Correo-01 Proxy-02 Correo-02Servicios:ProxyDNS

Servicios:Proxy InversoDNSNagiosJabber

Servicios:ProxyDNS

Servicios:Proxy InversoDNSNagiosJabber

Servidores Reales Servidores RealesRedundantes

Figura 12 Servicios Redundantes.



Para facilitar labores de administración y mejorar los tiempos de recuperación de una falla

o avería se propone el sistema de monitoreo y control Nagios, el cual es código abierto y se

encuentra libre en Internet [Nagios, (2004)]. Este sistema es capaz de verificar la

disponibilidad de los principales servicios y emitir reportes de su estado. La vía

recomendada para los reportes son mensajes e-pager enviados a un beeper, de manera que

el administrador sea alertado instantáneamente, cuando ha fallado algún servicio de forma

que pueda corregirlo a tiempo y los usuarios ni siquiera lo notarán.

3.4 Consideraciones de Seguridad en la Intranet UCLV.

Las estaciones del nodo central integradas por los servidores del dominio UCLV.EDU.CU,

los servidores reales y las máquinas de administración, pudieran estar en una subred

independiente con el objetivo de limitar el dominio de colisiones y brindarles un nivel de

seguridad superior. Esta solución aunque parezca sensata no es práctica, el tráfico que viaja

hacia estos servidores es originado en casi la totalidad de las estaciones de la Intranet, por

lo que se crearía un cuello de botella y un detrimento considerable del servicio, que nunca

va a ser justificado con los niveles de seguridad brindados. Esta solución se recomienda

para redes más pequeñas, ya que con ella se logra tener un control estricto del tráfico que

viaja hacia los servidores.

El tráfico generado en el área de los servidores es muy elevado por lo que un sistema de

detección de intrusos (IDS) no sería aplicable. Existen IDS basados en hardware que tienen

una alta rapidez de procesamiento, pero resultan costosos. En redes más pequeñas se

recomienda el Snort, para Linux, que es código abierto y existen muchas herramientas

desarrolladas que lo hacen muy flexible.

Los niveles de seguridad en esta situación serán dados en el switch capa3 el cual tiene

firewall integrado y puede hacer filtro de paquetes por puertos, esta variante es mucho más

eficiente puesto que no se afecta para nada el ancho de banda. Este dispositivo tiene

además la facilidad de puerto en espejo, mediante el cual el tráfico proveniente de puertos

concretos puede ir a parar a un puerto específico en el cual se analizaría el comportamiento



del flujo de paquetes con un sistema de detección de intrusos. Este IDS no tendría que

analizar todos los paquetes de la subred, sino de los servidores más importantes.

3.5 Seguridad de la Gestión del Backbone.

El backbone Gigabit, será administrado por SSH ya que las otras variantes no son seguras,

y su gestión la llevarán a cabo solamente los administradores del nodo central, ya que estos

equipos de conmutación representan la base de la infraestructura de comunicaciones de

toda la Intranet. Si en algún momento la gestión del backbone se ve comprometida, se

perdería el control de toda la comunicación. El dueño de la infraestructura de

comunicaciones será el dueño de la información que viaja por ella. Estos switches no

cuentan con herramientas para el procesamiento de logs, para lo cual se recomienda que

sean configurados para que envíen sus eventos hacia un servidor syslog de Linux e

implementar una herramienta para su procesamiento, con lo cual se pueden encontrar

problemas que son muy difíciles de detectar por revisión a simple vista.

3.6 Auditorías de Seguridad y Actualizaciones de los Sistemas

Operativos.

Para la seguridad de los Servidores de la Intranet se propone un sistema de auditorías

semanal con el objetivo de que el administrador detecte las vulnerabilidades de su red, y

las corrija. De acuerdo con el “Manual de la Metodología Abierta de Testeo de Seguridad”,

del ISECOM [Peter Herzog, (2003)]. Para llevarlo a efecto se recomiendan los escáneres de

vulnerabilidades nessus y retina en sus versiones para Linux y Windows respectivamente.

[Nessus, (2004)], [Retina, (2004)]

Para las actualizaciones de los sistemas operativos de Windows se recomienda el Software

Update Service (SUS) de Microsoft. Para lo cual uno de nuestros controladores se

conectará a Internet, pendiente de las nuevas actualizaciones de seguridad de los productos

de Microsoft. El administrador aprueba los que considera aplicables y luego se distribuyen

por políticas a todos los servidores y clientes Windows. [SUS, (2004)]

El sitio de Red Hat presenta un servicio similar pero no cuenta con el mismo nivel de

disponibilidad, por lo que no es factible automatizar el proceso, en este caso



recomendamos hacerlo manual. Para lo cual es necesario mantenerse atentos a los

principales sitios y listas de seguridad como SecurityFocus, Hispasec donde se publican las

vulnerabilidades de las aplicaciones. [SecurityFocus, (2004)], [Hispasec, (2004)]. Las

actualizaciones de los Linux se propone hacerlas a partir de RPM (paquetes de Red Hat) ó

códigos fuentes, dependiendo de la disponibilidad de uno u otro en el momento que se

publica la vulnerabilidad.

3.7 Copias de Seguridad.

Como parte de los mecanismos de recuperación, se propone un sistema de copias de

seguridad a partir de discos duros. Para guardar los backups de los sistemas operativos de

los servidores Windows y la configuración de todos los servicios ofrecidos en los

servidores Linux. También se recomienda un sistema de respaldo de hardware, los discos

duros que almacenan la parte de la información sensible sean duplicados en RAID de IDE

o de SATA. Además de hacerle copias a los buzones de correo electrónico.

3.8 Sistemas de Autentificación en la Intranet UCLV.

Los sistemas operativos Windows 9x, incluido ME (milenium), usan como sistema de

autentificación LM (LanManager) mientras que los Windows NT soportan LM y NTLM

(NT LanManager); y los Windows 2000, XP y superior soportan LM, NTLM y Kerberos.

En nuestra subred todos los controladores de dominio son Windows 2000 o superior y los

clientes van desde Windows 9x hasta Windows 2003, pasando por todas sus variantes. De

esta forma y conociendo que el cliente y servidor negocian el protocolo de autentificación,

escogiendo, de todos los que soportan el más fuerte, podremos concluir que los clientes de

Windows 2000 o superior se autentificarán usando Kerberos, pero los clientes inferiores a

Windows 2000 usarán LM o NTLM. Para estas dos últimas variantes existen herramientas

que son capaces de descifrar las contraseñas en cuestiones de segundos, como por ejemplo

el LC5, disponible en http://www.atstake.com/products/lc/ .

Una de las soluciones aplicables a los clientes inferiores a NT4 para mejorar la seguridad

de la autentificación son las Extensiones de Active Directory. Estas extensiones brindan a

sistemas inferiores algunas de las características de Windows 2000 y no son más que una

actualización al sistema (parche o upgrade). Entre otras mejoras le da la posibilidad de usar



NTLM v2.0, que aunque no constituye la solución definitiva del problema, sería una

mejora considerable.

Como resultado de la estrategia de asimilación del software libre en nuestra Intranet existe

un pequeño número de estaciones de trabajo con sistemas operativos Linux. Los cuales

tienen un sistema de autentificación a partir de los usuarios locales. Esto resulta

inconveniente para la administración y para la unificación. Por lo que se propone que sean

kerberizados de forma que usen como sistema de autentificación Kerberos contra un

controlador de dominio de Windows 2000 y los mismos usuarios de la red puedan iniciar

sesión en estas estaciones de trabajo.

3.9 Modelo de comunicación seguro entre Servidores y Clientes-

Servidores.

A cada una de las dependencias universitarias esta asignado un Sitio de Microsoft

Windows 2000, en el cual un mínimo de dos servidores comparten los roles de Windows

2000. [AD – Active Directory (2001)]. Los controladores de un mismo dominio replican

entre ellos el directorio activo y con los controladores de los restantes dominios replican su

partición del esquema a partir del esquema de replicación diseñado en el “Site and

Service”.

Con este nivel de integración permitimos que un usuario de un dominio específico pueda

iniciar sesión en cualquiera de los dominios restantes y que una vez autentificado, pueda

hacer uso de cualquiera servicio ofrecido en la Intranet. Bajo estas condiciones el tráfico de

paquetes de autentificación crecerá entre los dominios. Que como ya habíamos visto, gran

parte de él es proveniente de Kerberos, pero no debemos descuidar las autenticaciones LM

y NTLM.

En muchos lugares de nuestra intranet todavía existen como parte de la topología física el

HUB de 10/100 Mbps, estructura que permite el uso de técnicas de snifing, aunque no es la

única ya que a través de envenenamiento ARP se puede hacer snifing en un switch. De esta

forma queda a merced de cualquier intruso la información que viaja por nuestras redes.



Para la solución de estos problemas se propone el aseguramiento de la comunicación

mediante el protocolo IPSec, entre la red de servidores del bosque y todos los clientes que

lo soporten, llámense estos, los que tengan Windows 2000 o superior y sus condiciones de

hardware le permitan asumir esta configuración sin un detrimento considerable de la

prestación de los servicios. La configuración de IPSec será por políticas de dominio usando

como método de autenticación a Kerberos, aunque puede usarse también los certificados

digitales. Para la longitud de clave se recomienda 2048 bytes para una mayor seguridad.

En la configuración se adoptará el método de gestionar la comunicación por IPSec, si el

cliente no lo soporta, entonces proceder a una comunicación estándar, de manera que prime

la comunicación cifrada, no se generalizará el uso de IPSec, ya que existen clientes que no

soportan este protocolo como los Windows 95, 98, NT4. De cualquier manera los clientes

más importantes sí la usarán.

3.10 Seguridad del cliente de Web para Correo Electrónico.

Uno de los servicios más usados en la Intranet UCLV es el de correo electrónico, el cual se

brinda de manera centralizada en dos servidores del dominio UCLV.EDU.CU. Para hacer

uso de este servicio los usuarios utilizan los clientes de Microsoft Outlook y el cliente de

Web que viene con el servidor de Microsoft Exchange Server. Este último es el más

difundido ya que no es necesario configurarlo y no consume recursos adicionales de

hardware.

Uno de los principales problemas de seguridad que tiene este cliente es que la información

viaja en texto claro, de manera que pueden ser violados en el trayecto los principios básicos

de confidencialidad e integridad. Con un analizador de paquetes de red, cualquier intruso

puede interceptar los mensajes de correo electrónico que enviamos o recibimos, incluido

nuestra clave de sesión. Para resolver este problema se asegurará el servicio usando SSL,

para lo cual se instalará un certificado en la maquina que hospeda la pagina web, de forma

que todo el tráfico de correo electrónico relativo a este cliente será cifrado y estará libre de

espías informáticos.



3.11 Seguridad en la Administración y Actualización del sitio Intranet

UCLV.

Una de las aplicaciones que se ha incorporado a nuestros servicios es precisamente la Web

Intranet del centro, la cual es totalmente funcional, pero está todavía en fases de desarrollo.

En estos momentos esta usando un total de cuatro servidores, entre los que se encuentran

dos Windows 2003 Server, un Windows 2000 Advanced Server y un Debian 3.2. Y corre

aplicaciones en los siguientes servidores:

o Apache 1.3.28 (php 4.3.4)

o Zope 2.7.0 (python 2.3.3)

o Plone 2.0 (python 2.3.3)

o Como servidor de bases de datos un MySQL 4.0.14

En estas aplicaciones se brindan servicios de noticias, correo electrónico, multimedia,

opciones gastronómicas ofertadas en el comedor e hipervínculos al resto de las páginas

Web de la Intranet. Aunque existen otros en fase de desarrollo, como reportes del consumo

de Internet y servicio de descargas de ficheros por solo mencionar algunos.

La seguridad de la administración y actualización de los sitios Web y servicios de la

Intranet estará dado por el servicio de login. El cual será una página de autentificación,

escrita en PHP la cual autentificará al usuario a través de ADSI contra un controlador de

dominio. Una vez que el usuario se haya identificado correctamente el sistema verificará

que nivel de privilegios posee y en consecuencia de ello podrá actualizar o administrar. De

esta forma los permisos de administración estarán vinculados a los usuarios de Windows

2000, como el resto de las aplicaciones en la Intranet.

La página del servicio login de la UCLV, será asegurada con SSL, a partir de certificados

digitales, su dirección https://login.uclv.edu.cu será usada como servicio de autentificación

para cualquier aplicación de la intranet que así lo requiera.



3.12 Seguridad del Sistema de Control Docente.

Como parte de la centralización de las aplicaciones, se encuentra el sistema de bases de

datos de las Secretarías Docentes, en las cuales se lleva el control de los estudiantes. Estas

bases de datos en principio se encontraban en servidores distribuidos por las distintas

facultades y ahora van a estar de manera centralizada.

El Sistema de Control Docente lleva toda la información de los estudiantes, hoja de

matrícula de la cual se derivan datos como los listados por provincias y municipios,

actualización de la Defensa, carné de identidad, militancia, vías de ingresos, sexos, raza,

año, especialidad que cursa, registros de altas y bajas. En el sistema existen opciones para

la modificación de cualquier campo relativo a los usuarios. Todavía está en proceso de

instalación todo lo referido al control de notas (certificaciones de notas por años e índices

académicos en los distintos momentos del curso). Razón por la cual se convierte en la

aplicación que mayor nivel de seguridad requiere.

La base de datos del Sistema de Secretaría Docente va a estar hospedada en un servidor de

Microsoft Windows 2003, y será accedida y modificada solamente por los Secretarios

Docentes. Para asegurar su protección, la seguridad del sistema se diseñará por niveles.

• En el nivel de aplicaciones se va a garantizar que sólo se puedan conectar a la base

de datos de SQL Server los usuarios de Windows de los secretarios docentes, a

partir de la autentificación integrada del servidor de SQL con los dominios de

Windows 2000.

• A nivel de transporte, se va a garantizar con un firewall que solo puedan conectarse

al servicio de bases de datos, los números IP de las estaciones involucradas.

Cualquier tráfico de una máquina no permitida al puerto del servicio de SQL será

bloqueado.

• A nivel de red, el tráfico relativo del servidor y los clientes autorizados del sistema

se va a codificar usando IPSec. Esta directiva estará orientada al tráfico generado

en los clientes y cuyo destino sea el puerto SQL del servidor y estará asignada por

políticas locales a todas las máquinas implicadas. para impedir que la información

sea leída o falseada en el trayecto.



• Otra variante a nivel de red, sería comunicar los clientes y el servidor a través de

una subred de túneles VPN las cuales tendrían como numeración IP el

192.168.0.0/255.255.255.0. Esto se implementaría con un servidor de VPN en el

servidor de base de datos. De forma que el tráfico entre clientes y servidor del

sistema de secretarías docentes viajaría por túneles VPN.

De las dos variantes a nivel de red se recomienda usar la de IPSec, ya que si mantenemos la

VPN permanente todo el tráfico se iría por esta interfaz de comunicación por la que solo

pueden acceder al servidor de bases de datos y no al resto de las aplicaciones. Otra solución

sería crear la VPN en el momento en que se vaya a trabajar con la Base de Datos. Mientras

que con IPSec podrán hacer uso de cualquier otra aplicación en cualquier momento.

3.13 Autentificación del RAS usando Radius.

El Acceso Remoto (RAS), usado por trabajadores de la universidad para acceder desde sus

casas a los servicios de correo electrónico y páginas Web de la intranet, se encuentra

montado sobre un switch capa3 del propietario Allied Telesync, específicamente un

Rapier24i, al cual se le pueden conectar bahías de expansión para módulos de acceso

remoto. En estos momentos cuenta con un total de 6 módems analógicos a velocidades de

56 kbps.

Este servicio se administra en el propio Rapier, a partir de la línea de comandos de su

sistema operativo. Por cada usuario de acceso remoto se necesita crear una nueva cuenta

local en el Rapier. Lo cual tiene dos inconvenientes, a medida que aumentan los usuarios

del RAS, aumentan los usuarios locales del Rapier consumiendo memoria del sistema y

segundo los usuarios tienen que memorizar una nueva cuenta, que en ocasiones da lugar a

confusión.

Para la solución de este problema se propone la aplicación de un servidor externo Radius

que permita autentificar los usuarios del servicio de acceso remoto contra un controlador de

dominio de Windows 2000. Este servidor externo se montaría en un Linux y la versión

sería FreeRadius, que es código abierto y se encuentra disponible en Internet. De esta



forma los usuarios del RAS usarían para conectarse la misma cuenta de usuario que poseen

en la red y no tendrían necesidad de memorizar otras cuentas. También mejoraría la

disponibilidad del Rapier ya que se liberaría de las cuentas locales. De esta forma

mejoraría la administración del RAS, ya que este servicio se ofrecería a partir de los

usuarios de la red y estos son responsabilidad de los administradores de las dependencias.

El Rapier no cuenta con herramientas para el procesamiento de eventos de seguridad por lo

que es muy difícil depurar errores y realizar análisis estadísticos en el propio sistema

operativo del switch, por lo que se recomienda enviar estos eventos hacia un servidor

Syslog de Linux, que los va a almacenar para su posterior procesamiento. Esta decisión es

muy práctica para realizar análisis forenses en caso de que logren comprometer el sistema,

ya que los eventos de seguridad estarían intactos en otra máquina. El puerto de syslog

(UDP 514) sería filtrado en el servidor para mayor seguridad.

3.14 Seguridad del Servicio de RAS para usuarios móviles.

Una de las mejores formas de brindar el servicio de Acceso Remoto es a través de túneles

VPN por redes públicas como Internet, esta variante es muy usada en el mundo para los

usuarios móviles, empresarios que viajan y necesitan estar conectados a los servicios que

les brinda su intranet. En nuestro caso nuestros usuarios remotos no cuentan con

conexiones hacia redes públicas desde sus casas, por lo que no es viable esta variante,

aunque sí pudiéramos usarlos para los administradores cuando viajan al extranjero o

simplemente salen a un evento dentro del país, con el objetivo que puedan seguir

realizando labores de administración desde cualquier lugar y puedan solucionar los

problemas que se presenten. Con esta solución, los administradores que por cuestiones de

trabajo se encuentren fuera de la universidad y cuenten con una conexión a Internet pueden

conectarse a nuestro servidor de VPN, el cual le dará un IP de la subred interna, de forma

que puedan administrar los servidores y resolver los problemas que se presenten en sus

áreas.

3.15 Seguridad del sistema de mensajería instantánea Jabber.

Jabber es uno de los sistemas de mensajería instantánea que mejor se acomoda a las

necesidades de las redes corporativas. Es código abierto y sus fuentes se encuentran



públicas en Internet. Es compatible con los sistemas de mensajería instantánea más

difundidos. Aunque la integración con estos depende de las intenciones de la empresa.

En la Universidad se decide usar este sistema porque brinda la posibilidad de implementar

una red de servidores de mensajería instantánea para los centros de educación superior del

país. A cuya red se pueden ir incorporando centros de investigación y otras entidades de

reconocido prestigio, con el objetivo de intercambiar información y realizar proyectos de

colaboración.

En la UCLV la gran mayoría de los servicios se encuentran relacionados con el usuario de

Windows 2000 del Directorio Activo de Windows, de manera que se desarrollaron

aplicaciones con el objetivo de integrar el sistema de mensajería instantánea con los

dominios de Windows. Concretamente se realizó una página Web escrita en PHP, que le

permite al usuario autentificarse contra un controlador de Windows 2000, si el usuario es

válido, entonces revisa en un fichero de permisos, donde se encuentran los que pueden

registrarse, como un mecanismo de control. Este fichero de permisos se actualiza por una

lista de seguridad de Windows, a través del sitio Web http://adsi.fie.uclv.edu.cu. Si el

usuario tiene permiso para crearse una cuenta en el servidor Jabber la cuenta será creada, y

se generará un registro del usuario del Jabber relacionado con el usuario del dominio con el

objetivo de tener un control de este sistema. Esta aplicación estará instalada en la máquina

que hospeda el servidor de mensajería instantánea Jabber, un Red Hat Linux.

La autentificación con los controladores de Windows se realiza a través del sitio

http://adsi.fie.uclv.edu.cu , y para la seguridad usamos SSL. La seguridad de la

comunicación entre el cliente y el servidor también esta garantizada con SSL, al igual que

la comunicación entre la red de servidores Jabber. Esta misma interfase permite realizar

además labores de administración mucho más cómodas como habilitar y deshabilitar

cuentas, ver los usuarios online, y otra serie de facilidades que no trae el sistema original

que es distribuido en Internet. Algunas fotos de la aplicación se pueden ver en los anexos.

59

Conclusiones

Como conclusiones del trabajo se tienen:

• La Universidad cuenta con la infraestructura tecnológica que garantiza el empleo de

una gestión de seguridad eficiente por la presencia de buen equipamiento, medios

de comunicación, servicios y personal calificado.

• En estos momentos existen una serie de servicios que no se están protegiendo

adecuadamente; por lo que lograr una adecuada seguridad lograría llevar a índices

de confiabilidad, no repudiación, e integridad adecuados para una institución con

requerimientos de seguridad medios.

• Dado que la prestación de servicios de una Intranet condiciona la efectividad del

trabajo de una organización informatizada; debe prestarse especial atención a lograr

tiempos de recuperación lo más cortos posibles ante la presencia de fallos. Un

elemento importante para satisfacer este requerimiento es la presencia de

redundancia en los servicios. La Intranet de la UCLV debe disponer entonces de

redundancia en los servicios de Transporte de Correo, Acceso a Internet, y

Servidores de Nombre, dado que son los más significativos para la comunicación.

Para ello se debe adquirir dos computadoras de altas prestaciones.

• Los sistemas de respaldo mejoran considerablemente los tiempos de respuesta ante

fallas ocasionadas, mantener copias de seguridad de todos los sistemas de la

empresa reducirá considerablemente los costos producidos por ataques de seguridad

o catástrofes naturales.

• Para minimizar las vulnerabilidades de la Intranet de la UCLV se propone que todos

los dominios tengan debidamente configurado por políticas el Software Update

Service de Microsoft. Aquellas máquinas con otros SO (por ejemplo Linux) se

auditarán y actualizarán a partir de los patches disponibles. En este sentido es

importante dar seguimiento, por parte del personal de administración, a las listas de

seguridad que publican las vulnerabilidades de estos sistemas.

60

• Los sistemas de autentificación son los responsables de las claves de sesión por lo

que en empresas con redes sobre Windows se propone el uso de Kerberos v5.0 para

lo cual sus clientes deben ser Windows 2000 o superior y los controladores de

dominio instalados sin compatibilidad de los pre-windows 2000. Debe prohibirse

terminantemente el uso de LM o NTLM.

• Las estaciones con Unix, deben unirse al sistema de autentificación de los

controladores de Windows a partir del proceso de kerberización lo que mejorará la

seguridad de la autentificación de estos clientes.

• El cifrado del canal de comunicaciones resuelve los problemas de integridad y

confidencialidad de la información, por lo que bajo las condiciones propuestas debe

ser usado IPSec, aplicado por políticas de dominio a todos los servidores y clientes

de Windows, y configurado de forma manual en los Unix.

• Por ningún concepto se debe permitir que viajen claves de sesión en texto claro por

el canal de comunicaciones. Las aplicaciones que requieran autentificación deben

proteger las contraseñas usando SSL, IPSec o Kerberos.

• Los sitios web son la expresión grafica de la empresa. La actualización y

administración de estos debe ser protegida por un sistema de autentificación cuyas

claves de sesión sean cifradas usando SSL.

• El servicio de Acceso Remoto es una puerta de entrada a la institución, que debe ser

debidamente protegida. Para usuarios móviles se propone el uso de redes privadas

virtuales y para usuarios normales conexión por línea conmutada. De este servicio

se debe tener un control estricto de eventos de seguridad.

• Los sistemas de mensajería son usualmente usados para el intercambio de

información confidencial relativo a la empresa o personal. Por lo que la violación de

la confidencialidad puede llevar a la extorsión o robo de información. Dentro de

estos sistemas encontramos el correo electrónico y los sistemas de mensajería

61

instantánea. Los clientes de Web para correo electrónico pueden asegurarse con

SSL. Los servicios de mensajería instantánea como ICQ, MSN, YAHOO, no cifran

la comunicación; en este caso se recomienda el Jabber, que usa SSL para la

comunicación entre cliente servidor.

62

Recomendaciones

Como recomendaciones se propone:

• Continuar el estudio de los protocolos de seguridad haciendo énfasis en los que no

fueron referenciados en este trabajo, muestra de ellos son IPv6, TLS, SASL.

• Análisis constante de vulnerabilidades de los servicios ofrecidos a partir de

auditorías de seguridad siguiendo las recomendaciones del OSSTMM.

• Usar la menor cantidad de protocolos posibles, si un servicio puede ser asegurado

de dos formas, usar la misma normativa en todas las áreas, bajo las

recomendaciones de un órgano rector.

• Desarrollar un sistema para el análisis de eventos del Rapier (equipo de

conmutación que atiende el servicio de RAS), con el objetivo de tener un control de

seguridad de este servicio.

• Poner a punto un sistema de detección de intrusos a partir de la facilidad de puerto

en espejo del Rapier para analizar el tráfico relativo a los servidores más

importantes.

63

Referencias Bibliográficas

AD – Active Directory (2001) [En línea] Disponible en:

http://www.microsoft.com/windows/technologies/directory/ad/default.asp [Consultado

20/03/2004]

Asaka, Midori (1999). Local Attack Detection and Intrusion Route Tracing. IEICE

Transactions on Communications .E82-B(11): 1826-1833

Canavan, John E. (2000). Fundamentals of Network Security. Boston, Artech House

CERT - Computer Emergency Response Team (2004) [En Línea] Disponible en: http://www.cert.org [Consultado 12/02/2004] Chandra, Pravir; Messier, Matt; Viega, John (2002) Network Security with OpenSSL.

Sebastopol, CA, O'Reilly

Cisco System Inc (2000) Designing Network Security. USA, Cisco Press publication

Doraswamy, Naraganand (2003). IPSec: The new Security Standard for the Internet,

Intranets and Virtual Private Networks. 2da ed. Upper Saddle River, NJ, Prentice-Hall

PTR.

Govanus, Gary; King, Robert (2000) MCSE: Windows 2000 Network Security Design.

Alameda, CA, SYBEX Inc.

Hada, Satoshi (2004) A Formal Treatment of Non-repudiation Protocols. IEICE

Transactions on Communications E87-A(2): 461-470

Hanaoka, Goichiro (2004). Efficient Unconditionally Secure Digital Signaturas. IEICE

Transactions on Communications E87-A (1): 120-130

64

Hazeyama, Hiroaki; OE, Masafumi; Kadobayashi, Youki (2003) A Layer-2 Extension to

Hash-Based IP Traceback. IEICE Transactions on Communications E86-D(11): 2325-

2333

Horng, Gwoboa (2002) Cryptanalysis of a Key Management Scheme for Secure Multicast

Communications. IEICE Transactions on Communications E85-B(5): 1050-1051

Hispasec (2004) [En línea] Disponible en http://www.hispasec.com/ [Consultado

10/02/2004]

IANA – Internet Assigned Numbers Authority (2004) [En línea] Disponible en

http://www.iana.org [Consultado 20/03/2004]

IETF- Internet Engineering Task Force, The. (2004) [En línea] Disponible en

http://www.ietf.org [Consultado 20/03/2004]

Iguchi, Makoto; GOTO, Shigeki (1999) Detecting Malicious Activities through Port

Profiling. IEICE Transactions on Communications E82-D(4): 784-792

Imai, Hideki (2001) Development of Cryptology in the Nineties. IEICE Transactions on

Communications E84-A(1): 61-67

J. Kohl (1993) The Kerberos Network Authentication Service (V5), RFC. [en línea]

Dispinible en http://www.faqs.org/rfcs/rfc1510.html [Consultado 08/03/2004]

Kashiwa, Dai (2002) Active Countermeasure Platform against DDoS Attacks. IEICE

Transactions on Communications E85-D(12): 1918-1928

Kato, Nei [et al.] (1999) Real-Time Intrusion Detection System (IDS) for Large Scale

Networks and Its Evaluations. IEICE Transactions on Communications E82-B(11): 1817-

1825

65

Kim, Cheolhyun; CHUNG, Ilyong (2002) An Efficient Kerberos Authentication

Mechanism Associated with X.509 and DNS (Domain Name System). IEICE

Transactions on Communications E85-D(9): 1384-1389

Lucena López, Manuel José (2002) Criptografía y Seguridad en Computadores. 3ra ed.

Universidad de Jaén

Ludwin, Mark (1996) The Little Black Book of Computer Virus. Arizona, American

Eagle publications, Inc.

Lee, Narn-Yih (2002) Cryptanalysis and Improvement of Two Access Control Schemes

with User Authentication in a Distributed Computer Network. IEICE Transactions on

Communications E85-D (2): 386-391

Lin, Chun-Li; Sun, Hung-Min; Hwang, Tzonelih (2001) Attacks and Solutions on Strong-

Password Authentication. IEICE Transactions on Communications E84-B(9): 2622-2627

Liska, Allan (2002) The Practice of Network Security: Deployment Strategies for

Production Environments. Upper Saddle River, N J, Prentice Hall PTR.

Mclure, Stuar (2001) Hackers: secretos y soluciones para seguridad de redes. España,

McGrau – Hill.

Nagios (2004) [En línea] Disponible en http://www.nagios.org [Consultado 20/03/2004]

Nessus (2004) [En línea] Disponible en http://www.nessus.org [Consultado 20/03/2004]

Peláez, Raúl Siles (2002) Análisis de Seguridad de la familia de protocolos TCP/IP.

Sebastopol, CA, O'Reilly

Peter Herzog (2003) Manual de la Metodología Abierta de Testeo de Seguridad. [en línea]

[Consultado 18/03/2004]

Retina (2004) [En línea] Disponible en http://www.eeye.com/html/Products/Retina/index.html [Consultado 15/02/2004]

66

Ramiró, Aguirre Jorge (2003). Curso de Seguridad Informática y Criptografía. 3ra ed.

Universidad Politécnica de Madrid España.

SecurityFocus (2004) [En línea] Disponible en http://www.securityfocus.org/ [Consultado

18/02/2004]

Seifried, Kurt (1999) Guía de Seguridad del administrador de Linux. [en línea]

Disponible en http://www.securityportal.com/lasg [Consultado 20/03/2004]

Shinder, Thomas W.; White, Lynn (1999) Configuring Windows 2000 Server Security.

Syngress Publishing, Inc.

Stanger, James; Lane, Patrick T. (2001) Hack Profing Linux. Rockland, MA, Syngress

Publishing, Inc.

Symantec Corporation (2003) Symantec Internet Security Threat Report [en línea] Disponible en: http://enterprisesecurity.symantec.com/ [Consultado 10/04/2004] SUS (2004) [En línea] Disponible en

http://www.microsoft.com/windowsserversystem/sus/default.mspx

[Consultado18/03/2004]

Tanenbaum, Andrew S. (2002) Computer Networks. 4ta ed. Upper Saddle River, Prentice

Hall PTR.

Thomas, Stephen A. (2000) SSL & TLS Essentials: Securing the Web. New York, Wiley

Computer Publishing

Tsukamoto, Katsuji [et al] (2002) An Experimental Study on IPSec. IEICE Transactions

on Communications E85-A(1): 175-180

Villalon Huerta, Antonio (2002) Seguridad en Unix y Redes. Valencia, Universidad

Politécnica de Valencia.

67

Vsantivirus (2004) [en línea] Disponible en: http://www.vsantivirus.com [Consultado en: 10/04/2004] Yeh, Yi-Shiung; WANG, Chan-Chi (1999) Construct Message Authentication Code with

One-Way Hash Functions and Block Ciphers. IEICE Transactions on Communications

E82-A(2): 390-393

68

Glosario

AES Advanced Encryption Standard

AH Authentication Header

ARP Address Resolution Protocol

CA Certificate Authority (Autoridad de Certificación)

CRL Lista de Certificados Revocados

DES Data Encription Standard

ESP Encapsulating Security Payload

GNU General Public License

GnuPG GNU Privacy Guard

IDEA International Data Encryption Algorithm

IANA Internet Assigned Number Authority.

IETF Internet Engineering Task Force

IKE Internet Key Exchange

IP Internet Protocol

IPv6 Internet Protocol versión 6

ISECOM Institute For Security And Open Methodologies

LDAP Lightweight Directory Access Protocol

MAC Message Authentication Code

MD5 Message Digest 5

OSSTMM Open Source Security Testing Methodology Manual

PKCS Public Key Common Standards

PKI Public Key Infraestructure

PGP Pretty Good Privacy

RSA Rivest Shamir y Adleman, algoritmo criptografico.

RPV Red Privada Virtual

SA Security Association

SASL Simple Autentication and Security Layer

69

SCEP Simple Certificate Enrollment Protocol

SHA-1 Secure Hash Algorithm

TDES 3DES

TLS Transport Layer Security.

70

Anexos

Anexo # 1 Página de Inicio del Jabber.

Anexo # 2 Página de Autentificación del Jabber.

Seguridad en Redes de Mediana y Pequeña Empresa.

Documents

Transcript of Seguridad en Redes de Mediana y Pequeña Empresa.