SEGURIDAD EN REDES COMPLEJAS: EL CASO DE INTERNET

El fenómeno de la extensión de la Internet ha adquirido una velocidad tan rápida y unas proporciones, que el panorama actual y muchos de los efectos que se dan en su seno resultan sorprendentes y difícilmente imaginables hace sólo una década.
Inicialmente Internet nace como una serie de redes que promueven el intercambio de información entre investigadores que colaboran en proyectos conjuntos o comparten resultados usando los recursos de la red. En esta etapa inicial, la información circulaba libremente y no existía una preocupación por la privacidad de los datos ni por ninguna otra problemática de seguridad. Estaba totalmente desaconsejado usarla para el envío de documentos sensibles o clasificados que pudieran manejar los usuarios. situación esta muy comùn, pues hay que recordar que la Internet nace como un contrato del Departamento de Defensa Americano -año 1968- para conectar entre sí tanto las Universidades como los centros de investigación que colaboran de una manera u otra con las Fuerzas Armadas Norteamericanas.

Los protocolos de Internet fueron diseñados de una forma deliberada para que fueran simples yu sencillos. El poco esfuerzo necesario para su desarrollo y verificación jugó eficazmente a favor de su implantación generalizada, pero tanto las aplicaciones como los niveles de transporte carecían de mecanismos de seguridad que no tardaron en ser echados en falta.

Más recientemente, la conexión a Internet del mundo empresarial se ha producido a un ritmo vertiginoso muy superior a la difusión de ninguna otra tecnología anteriormente ideada. Ello ha significado que esta red de redes se haya convertido en "la red" por excelencia. Esto es, el medio más popular de interconexión de recursos informáticos y embrión de las anunciadas autopistas de la información.

Se ha incrementado la variedad y cantidad de usuarios que usan la red para fines tan diversos como el aprendizaje, la docencia, la investigación, la búsqueda de socios o mercados, la cooperación altruista, la práctica política o, simplemente, el juego. En medio de esta variedad han ido aumentando las acciones poco respetuosas con la privacidad y con la propiedad de recursos y sistemas. Hackers, frackers, crakers ... y demás familias han hecho aparición en el vocabulario ordinario de los usuarios y de los administradores de las redes.

La propia complejidad de la red es una dificultad para la detección y corrección de los múltiples y variados problemas de seguridad que van apareciendo. Además de las técnicas y herramientas criptográficas antes citadas, es importante recalcar que una componente muy importante para la protección de los sistemas consiste en la atención y vigilancia continua y sistemática por parte de los gestores de la red. Como ejemplo, en la tabla 1 se recoge una lista exhaustiva de problemas detectados, extraída del libro: "Firewalls and Internet Security. (...)".

LISTA DE PELIGROS MÁS COMUNES EN SISTEMAS CONECTADOS A INTERNET

Fuente: "Firewalls and Internet Security. Repelling the Wily Hacker"
1.- De todos los problemas, el mayor son los fallos en el sistema de passwords.
2.- Los sistemas basados en la autenticación de las direcciones se pueden atacar
usando números consecutivos.
3.- Es fácil interceptar paquetes UDP.
4.- Los paquetes ICMP pueden interrumpir todas las comunicaciones entre dos nodos.
5.- Los mensajes ICMP Redirect pueden corromper la tabla de rutas.
6.- El encaminamiento estático de IP puede comprometer la autenticación basada en las direcciones.
7.- Es fácil generar mensajes RIP falsos.
8.- El árbol inverso del DNS se puede usar para conocer nombres de máquinas.
9.- Un atacante puede corromper voluntariamente la caché de su DNS para evitar responder
peticiones inversas.
10.- Las direcciones de vuelta de un correo electrónico no son fiables.
11.- El programa sendmail es un peligro en sí mismo.
12.- No se deben ejecutar a ciegas mensajes MIME.
13.- Es fácil interceptar sesiones telnet.
14.- Se pueden atacar protocolos de autenticación modificando el NTP.
15.- Finger da habitualmente demasiada información sobre los usuarios.
16.- No debe confiarse en el nombre de la máquina que aparece en un RPC.
17.- Se puede conseguir que el encargado de asignar puertos IP ejecute RPC en beneficio de quien le llama.
18.- Se puede conseguir, en muchísimos casos, que NIS entregue el fichero de passwords al exterior.
19.- A veces es fácil conectar máquinas no autorizadas a un servidor NIS.
20.- Es difícil revocar derrechos de acceso en NFS.
21.- Si está mal configurado, el TFTP puede revelar el /etc/passwd.
22.- No debe permitirse al ftp escribir en su directorio raíz.
23.- No debe ponerse un fichero de passwords en el área de ftp.
24.- A veces se abusa de FSP, y se acaba dando acceso a ficheros a quien no se debe dar.
25.- El formato de información de WWW debe interpretarse cuidadosamente.
26.- Los servidores WWW deben tener cuidado con los punteros de ficheros.
27.- Se puede usar ftp para crear información de control del gopher.
28.- Un servidor WWW puede verse comprometido por un script interrogativo pobremente escrito.
29.- El MBone se puede usar para atravesar algunos tipos de cortafuego.
30.- Desde cualquier sitio de la Internet se puede intentar la conexión a una estación X11 (X-Server).
31.- No se debe confiar en los números de puerto facilitados remotamente.
32.- Es casi imposible hacer un filtro seguro que deje pasar la mayoría del UDP.
33.- Se puede construir un túnel encima de cualquier transporte.
34.- Un cortafuego no previene contra niveles superiores de aquellos en los que actúa.
35.- Las X11 son muy peligrosas incluso a través de una pasarela.
36.- Las herramientas de monitorización de red son muy peligrosas si alguien accede
ilegítimamente a la máquina en que residen.
37.- Es peligroso hacer peticiones de finger a máquinas no fiables.
38.- Se debe de tener cuidado con ficheros en áreas públicas cuyos nombres
contengan caracteres especiales.
39.- Los caza-passwords actúan silenciosamente.
40.- Hay muchas maneras de conseguir copiar el /etc/password
41.- Registrando completamente los intentos fallidos de conexión, se capturan passwords.
42.- Un administrador puede ser considerado responsable -si se demuestra conocimiento
o negligencia- de las actividades de quien se introduce en sus máquinas.
A la hora de plantearse en que elementos del sistema se deben de ubicar los servicios de seguridad podrían distinguirse dos tendencias principales:

Protección de los sistemas de transferencia o transporte. En este caso, el administrador de un servicio, asume la responsabilidad de garantizar la transferencia segura de la información de forma bastante transparente al usuario final. Ejemplos de este tipo de planteamientos serían el establecimiento de un nivel de transporte seguro, de un servicio de mensajería con MTAs seguras, o la instalación de un cortafuego, (firewall), que defiende el acceso a una parte protegida de una red.
Aplicaciones seguras extremo a extremo. Si pensamos por ejemplo en correo electrónico consistiría en construir un mensaje en el cual en contenido ha sido asegurado mediante un procedimiento de encapsulado previo al envío, de forma que este mensaje puede atravesar sistemas heterogéneos y poco fiables sin por ello perder la validez de los servicios de seguridad provistos. Aunque el acto de securizar el mensaje cae bajo la responsabilidad del usuario final, es razonable pensar que dicho usuario deberá usar una herramienta amigable proporcionada por el responsable de seguridad de su organización. Este mismo planteamiento, se puede usar para abordar el problema de la seguridad en otras aplicaciones tales como videoconferencia, acceso a bases de datos, etc.
En ambos casos, un problema de capital importancia es la gestión de claves. Este problema es inherente al uso de la criptografía y debe estar resuelto antes de que el usuario esté en condiciones de enviar un solo bit seguro. En el caso de las claves secretas el problema mayor consiste en mantener su privacidad durante su distribución, en caso de que sea inevitable su envío de un punto a otro. En el caso de clave pública, los problemas tienen que ver con la garantía de que pertenecen a su titular y la confianza en su vigencia (que no haya caducado o sido revocada).
Una manera de abordar esta gestión de claves está basada en el uso de los ya citados Certificados de Clave Pública y Autoridades de Certificación. El problema de la vigencia de la clave seresuelve con la generación de Listas de Certifados Revocados (CRLs) por parte de las CAs.

Volver a Seguridad

Miguel A. Ruz
miguelruz@delitosinformaticos.com