Introducción

Las Tecnologías de Información y Comunicación (TIC) han dado paso a importantes mejoras en las organizaciones, pues automatizan los procesos operativos, suministran una plataforma de información necesaria para la toma de decisiones y lo más importante, su implantación logra ventajas competitivas o reducen las de los rivales; está claro que el amplio desarrollo de las nuevas tecnologías informáticas y la dependencia de sus redes de datos, han dado paso a nuevos retos, siendo uno de los más importantes el de mantener la seguridad de sus sistemas, debido a que los mismos son un punto crítico para el servicio que prestan (Berenguela y Cortes, 2006).

Anteriormente, cuando las redes estaban diseñadas para cubrir solamente una oficina local (redes de área local) el tener simplemente un software antivirus y ciertas medidas físicas de seguridad ayudaba de gran manera a proteger la información de ser destruida o robada por personas que perseguían dichos fines. En los tiempos actuales dicho modelo no sería efectivo ni práctico debido a que las empresas tienen ya por lo menos una puerta abierta hacia Internet, puesto que utilizan dicho servicio o utilizan un sistema de mensajería electrónica que a su vez deberá intercambiar mensajes con el mundo externo a la empresa.

 Ahora bien, para proteger la información en una empresa donde exista una conexión con la red pública se utilizan estrategias de firewalls, routers, NAT, software de firewall, antispyware, detección de intrusos, entre otros. Estos métodos de protección (por experiencia de los investigadores) no ofrecen un 100% de efectividad, por lo cual, siempre existe la posibilidad de que se produzcan fallas en la seguridad, lo que podría degenerar en vulnerabilidades en la red o en los equipos de la misma. McNab (2008), considera la vulnerabilidad como la incapacidad de resistencia cuando se produce un fenómeno amenazante. En materia informática vulnerabilidad hace referencia a una debilidad en un sistema permitiendo a un atacante violar la confidencialidad, integridad, disponibilidad, control de acceso y consistencia del sistema o de sus datos y aplicaciones. Estas vulnerabilidades son el resultado de bugs o de fallos en el diseño del sistema.

Esta investigación contempla las vías en las que se pueden medir la seguridad de una red de datos, detectar las vulnerabilidades que puedan existir; así como el tipo de tráfico que viaja en la red a fin de analizar las tramas que circulan en la misma y de esta manera, detectar si transitan contraseñas o algún tipo de información importante sin encriptar, que pueda atentar contra la confidencialidad de los usuarios de la misma.

Antecedentes

Siendo Openvass y Wireshark aplicaciones opensource podemos mencionar algunos trabajos:  Vakharia (2003), en su artículo “Nessus scanning on Windows Domain” donde utilizó el software Nessus para escanear redes Windows considerando varios escenarios que pudiesen suceder y mostrando las diferentes vulnerabilidades encontradas. Por otra parte, Sánchez y Fermín (2009), en su investigación “Vulnerabilidad del protocolo mysql en redes Lan bajo plataforma Linux” proponen estudiar el nivel de vulnerabilidad del protocolo MySQL en una red LAN bajo plataforma LINUX; para esto se utilizó la técnica de medición de tráfico mediante un software analizador de redes denominado Wireshark en su versión 1.0.3.

Materiales y métodos

Para realizar la captura de tráfico en la red y posteriormente examinarlas se utilizó el analizador de protocolo Wireshark 1.2.9, y para verificar las vulnerabilidades presentes en los dispositivos y equipos de la red se usó el framework de escaneo de vulnerabilidades OpenVas 4. Con esto se procedió a hacer un prototipo de una estructura de red (véase figura 1), donde los investigadores contaron con cinco (5) Switch Cisco Catalyst 2900, un (1) Router Cisco, dos (2) equipos servidores, seis (6) computadores de escritorio, un (1) equipo portátil, además una  (1) conexión frame relay y dos (2) modems ADSL (ver Figura 1).

Con los cinco (5) Switch Cisco Catalyst 2900 se emplearon cuatro (4) para montar la configuración necesaria de las cuatro (04) Vlans funcionando en una red tipo estrella, se utilizó la técnica PortMirroning en el quinto Switch (considerado como el Switch Principal) para lograr enviar todas las tramas de la red hacia el analizador de protocolo, así como también se realizó la configuración de un firewall y un balanceador de carga, para tener una protección básica y un aprovechamiento del ancho de banda.

Figura 1. Diagrama de red del laboratorio TelRed

Resultados

Análisis de captura de tráfico

Para la captura de tráfico se hizo uso del analizador de protocolos o sniffer Wireshark 1.2.9, alojado en la computadora portátil de los investigadores en un laboratorio docente de investigación adscrito al área Telred, configurando la aplicación Wireshark  para analizar las tramas de las cuatro (04) Vlans por separado así como las enviadas y recibidas hacia y desde Internet.

Se conectó el equipo portátil por medio de su interfaz Ethernet al puerto GigaEthernet (g23) del Switch Principal; se procedió a configurarlo con PortMirroring del puerto troncal (g24) al puerto g23. De este modo se logró establecer la conexión a un puerto donde fluyera una copia de todo el tráfico de datos de la red del laboratorio que simulaba el campus Guatamare de la universidad. Para ello se realizó la programación del equipo fabricante (Dell) en línea de comando, de la siguiente forma:

Figura 2. Configuración del Port Monitor en Switch Principal

El comando show running-configarrojó el resultado que se observa en la figura 3, donde podemos constatar que la interfaz g23 tiene configurado el port monitor del puerto 24.

Figura 3. Verificación de cambios aplicados en running-config

Luego y para cerciorar el buen funcionamiento del port mirroring se ejecutó el comando “sh ports monitor” mostrándose en la figura 4 que el status está activo, lo que quiere decir que el puerto destino g23 está siendo un “espejo” del tráfico fu

Figura 4. Verificación de Puertos Monitor en Switch Principal

Una vez realizada la programación del Switch Principal se configuró el Wireshark para que realizara las capturas. En primera instancia se identificó la tarjeta de red donde debería escuchar el Wireshark (ver Figura 5), para luego activar la tarjeta previamente identificada (ver Figura 6), siendo para este caso solo de una ya que la portátil contaba con una sola interfaz Ethernet.

Figura 5. Wireshark, menú principal.

Figura 6. Wireshark, interfaces de captura.

Seguidamente se iniciaron las capturas de cada VLan ingresando la dirección deseada en el campo “Capture Filter”, tal como se refleja en la figura 7; estas capturas fueron realizadas en intervalos de tiempo de treinta (30) minutos por VLan, teniendo así ciento veinte (120) minutos de captura en toda la red. Para poder analizar cada una de las VLans, en el campo “Capture Filter” en la opción Wireshark Capture se  transcribieron las siguientes direcciones:

• 172.16.8.0/22: los cuatro (04) octetos indican la dirección de red VLan1 y el /22 la máscara de subred de dicha dirección.
• 172.16.12.0/22: los cuatro (04) octetos indican la dirección de red VLan2 y el /22 la máscara de subred de dicha dirección.
• 172.16.16.0/22: los cuatro (04) octetos indican la dirección de red VLan3 y el /22 la máscara de subred de dicha dirección.
• 172.16.20.0/22: los cuatro (04) octetos indican la dirección de red VLan4 y el /22 la máscara de subred de dicha dirección.  

Figura 7. Wireshark, opciones de captura.

Luego de realizadas todas las capturas se encontró tráfico relevante en algunas VLans. En la VLan1 se consiguió tráfico en texto plano ejecutándose sobre HTTP, tal como se puede apreciar en el figura 8 donde el campo sombreado es el paquete analizado. Se capturó el tráfico proveniente del chat de la red social Facebook.com, evidenciándose las tramas en la figuras 9 donde se observa la captura de tráfico en texto plano, lo que pone de manifiesto que en la red interna existe una representable vulnerabilidad en cuanto a los datos que navegan sobre la misma red, siendo esto un riesgo para los usuarios que hacen uso de la misma ya que cualquier intruso podría tomar datos de la red y convertirlos en un bien para sí mismo, como por ejemplo datos sobre cuentas electrónicas, contraseñas, entre otros.

Figura 8. Captura de tramas de datos en texto plano

Figura 9. Tramas de datos, captura facebook.com.

Las figuras  10, 11, 12 y 13 muestran el tráfico capturado en la VLan2, mostrando en las dos primeras tramas de datos del sitio oficial Hotmail.com y las dos últimas con conexión a través de un Iphone.

Figura 10. Captura de Tramas de datos, hotmail.com

Figura 11. Tramas de datos, hotmail.com.

Figura 12. Captura de Tramas de datos.

Figura 13. Tramas de datos, desde teléfono iphone.

En la VLan3 se encontró solamente una excesiva retransmisión de tramas TCP desde 172.16.32.1 lo que puede representar la actividad de gusanos en la red, tal como puede verse en la figura 14.

Figura 14. Capturas de Tramas de datos, retransmisión TCP.

En la VLan4 se encontró texto de correo Hotmail el cual puede visualizarse en la figura 15.

Figura 15. Tramas de datos, hotmail.com VLan4.

Se pudo asegurar entonces que la red posee una gran estabilidad defensiva, pero a su vez esta red proporciona demasiada información en todos sus servidores lo cual puede conllevar a un futuro ataque por hackers experimentados.

4.1.2. Vulnerabilidades encontradas

El próximo paso en el análisis de riesgos fue realizar un chequeo de vulnerabilidades de los equipos  (balanceador de carga, router/firewall) con direcciones públicas asignadas, para de esta forma evidenciar de una manera oportuna la realidad en materia de seguridad informática. Para esto se hizo uso de la herramienta OpenVas que nos permitió realizar un escaneo de todas las vulnerabilidades existentes en nuestros equipos de cómputo y se procedió a conectar la laptop en el puerto g23 de la misma forma que se realizó la captura de tráfico con la técnica PortMirroring. De esta forma y luego de observar los resultados obtenidos del escaneo a través del análisis de todos los equipos conectados, dos (02) equipos presentaron vulnerabilidades a tomar en cuenta, siendo estos: el Router Externo (150.186.88.1) y el balanceador (150.186.88.20).

En las figura 16 se puede observar uno de los resultados más relevantes del análisis de vulnerabilidades del router externo, donde se consiguieron doce (12) notas de seguridad las cuales proveen información de las vulnerabilidades encontradas. Luego de revisadas estas notas destacó una (01) asociada al servicio telnet donde se puede observar el banner mostrado cuando se realiza una conexión por medio de este protocolo al router externo; el riesgo que esto presenta es un riesgo bajo, pero igual no debe menospreciarse, puesto que se puede detectar la versión y tipo de servidor telnet conectándose al servidor y procesando los datos de buffer recibidos; esta información le ofrece a los hackers potenciales más información sobre el sistema a atacar.

Figura 16. Resultados específicos análisis router externo, OpenVas

Para solucionar esta problemática se recomienda cambiar el banner de inicio de sesión a algo más genérico, como por ejemplo: “Enrutador Primario”, “Router Principal”.

A su vez, se conoce de otra vulnerabilidad con factor de riesgo medio, la cual está asociada al uso del servicio telnet para conexiones remotas, puesto que telnet no encripta ningún tipo de datos en sus conexiones, lo que es un grave riesgo ya que si se tiene un Sniffer escuchando en la red y se realiza una conexión telnet contra el Router Externo, el atacante podría obtener la contraseña y acceder luego como un usuario autenticado al dispositivo, pudiendo tomar control total y dejarlo fuera de servicio a la red. Además, la mayoría de las implementaciones de telnet no poseen autenticación que asegure que la comunicación se está llevando entre dos host y no que está siendo interceptada en la mitad. Por último, existe una cantidad de vulnerabilidades descubiertas con el pasar de los años sobre el demonio telnet, las cuales están al alcance de cualquier atacante. Es por esto que se recomienda evitar el uso de telnet para las conexiones remotas con los servidores. Por otra parte y como se puede observar en la figura 17 se encontraron ciertas vulnerabilidades en el servidor balanceador de carga, de las cuales destacan dos (02): un problema de dominio y otro grave en el puerto 3128.

Este servidor permite que se le realicen repetidas peticiones de conexión, lo que ofrece una gran vulnerabilidad (ver Figura 18), lo que ocasiona que cualquier usuario sature el CPU, memoria o descriptores de archivo del servidor. En este sentido, se recomienda que se reconfigure el servidor para que rechace repetidas peticiones de un mismo usuario.

Figura 17. Resultados análisis del balanceador, OpenVas

Figura 18. Resultados específicos del balanceador, OpenVas.

Por último, en la figura 19 se observa la vulnerabilidad de dominio encontrada en el puerto 53, que indica que la versión de BIND que se está usando como DNS está vulnerable, puesto que logrando ejecutar un exploit con éxito en ese servidor, permitiría a hackers remotos saltar la autenticación y realizar ataques MITM “man in the middle”. Como solución a esta situación se recomienda actualizar la versión de BIND a BIND 9.3.6.

Figura 19. Resultados DNS (puerto 53), análisis del balanceador, OpenVas.

Conclusiones

Se evidenció que la plataforma de la red de datos en estudio proporciona un nivel medio/alto de seguridad en los datos manejados en la misma al ponerse a prueba el tráfico que transitaba por la ella; se logró obtener cadenas de texto plano lo que supone un grado de vulnerabilidad para los datos de los usuarios de la red, pero al momento de medir los fallos en los servidores principales, desde dentro y fuera de la red, no se encontraron vulnerabilidades significativas, mas sí una cierta cantidad de información que en manos equivocadas puede convertirse en una vulnerabilidad.

Referencias bibliográficas

Berenguela, A. y Cortes, J. (2006). Metodología de medición de vulnerabilidades en redes de datos de organizaciones. Instituto profesional INACAP La Serena. [Documento en línea] Disponible en: http://www.formacionalimentaria.com/ documentos/medicion-vulnerabilidades.pdf [consulta: 2011, Enero 12].

Cerini, M. y Prá, P. (2002). Plan de Seguridad Informática. Universidad Católica de Córdoba. Facultad de Ingeniería. Escuela de Ingeniería de Sistemas. Argentina. [Tesis de grado en línea] Disponible en: www.segu-info.com.ar/tesis/ [consulta: 2011, enero 10].

McNab, C. (2008). Seguridad en Redes. Ediciones Anaya multimedia. España.

Murillo, S. (2001). ASIS: Diseño y Aplicación de un Sistema Integral de Seguridad Informática para la UDLA. Universidad de las Américas. Escuela de Ingeniería. Departamento de Ingeniería en Sistemas Computacionales. México. [Tesis de grado en línea] Disponible en: http://catarina.udlap.mx/u_dl_a/tales/ documentos/msp/murillo_c_sr/ [consulta: 2011, Enero 15].

Sánchez,C. y Fermín, J. (2009). Vulnerabilidad del protocolo mysql en redes lan bajo plataforma linux. [Documento en línea] Disponible en: http://www.urbe.edu/publicaciones/telematica/indice/pdf-vol8-1/5-vulnerabilidad-del-protocolo-mysql.pdf  [consulta: 2011, Enero 15].

Vakharia, S. (2003). Nessus Scanning on Windows Domain. Instituto profesional INACAP La Serena. [Documento en línea] Disponible en: http://www.infosecwriters.com/text_resources/ pdf/nessus_windows_domain.pdf  [consulta: 2011, Enero 15].