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
|