spoofing

1. CARRERA: Licenciatura en Ciencias de la Computación. Universidad Nacional del
Comahue
MATERIA: Seguridad Informática.
ASUNTO: Trabajo Final.
FECHA DE CURSADO: primer cuatrimestre, 1.999.
TEMA: Address Spoofing/Forging.
ALUMNO: Mario Antonio Gómez. LEGAJO: 39.760. D.N.I.: 24.123.997.
PROFESOR: Jorge Sznek
ABSTRACT:
El presente informe es una introducción a una clase de ataques a
sistemas a través de una red conocido en la bibliografía como
"Address Spoofing" o "Address Forgery". Se presentan algunos
conceptos introductorios, una descripción genérica de las
distintas formas que puede tomar el ataque, un comentario acerca
de un incidente notorio que ocurrió en la Internet relacionado al
tema, medidas de prevención aplicables, y conclusiones.
1

2. Address Spoofing/Forging (Falsificación de direcciones).
1) Introducción.
Muchos de los servicios de red de la actualidad usan nombres de máquinas
(hosts) o direcciones tanto para identificación como para autenticación. Un
sistema que utiliza un servicio de ese tipo compone un mensaje de solicitud y lo
envía al sistema remoto que provee el servicio. El sistema remoto acepta o no la
solicitud basándose sólamente en la dirección del emisor, incluída en el
mensaje. Por ejemplo, un 'login' remoto puede ser aceptado sin autenticación
formal si proviniera de una máquina "confiable". Otros servicios que utilizan la
dirección de los emisores para autenticación pueden ser: comandos remotos (r*
commands), montajes de sistemas de archivos, empaquetadores TCP/UDP (wrappers),
paredes de fuego (firewalls, usadas para restrigir el acceso a ciertos servicios
y/o direcciones IP dentro de una red), entre otros. Muchos servicios de red de
más alto nivel son construídos sobre estos servicios vulnerables, heredando y/o
extendiendo así sus riesgos.
Desafortunadamente, las direcciones no fueron diseñadas para proveer
autenticación, y un adversario puede tomar ventaja de este hecho "falsificando"
solicitudes.
2) Algunos conceptos fundamentales.
Antes de definir qué es un "mensaje" debemos recordar que la comunicación a
través de redes se puede realizar de dos maneras: sin conexión, u orientada a
conexión. En la comunicación sin conexión, no se mantiene ningún estado acerca
de la información intercambiada previamente. Si un proceso desea enviar un
mensaje a otro proceso que ya se encuentra esperando, el primer proceso
simplemente construye el mensaje y se lo entrega a la capa de protocolo sin
conexión (por ejemplo UDP (User Datagram Protocol)) para que lo despache. Debido
a que ninguna información de estado es mantenida, el protocolo subyacente no
garantiza que los mensajes arribarán a destino o si lo harán en el orden en que
fueron enviados. Sin embargo, esta carencia de estado hace que los protocolos
sin conexión sean muy eficientes y deseables para muchos servicios de red. En la
comunicación orientada a conexión, se garantiza que la información arribará en
orden al proceso destinatario, o al menos se notificará al proceso remitente en
caso de que la entrega no se haya podido realizar. La comunicación orientada a
conexión atraviesa tres fases: establecimiento de la conexión, intercambio de
datos, y desconexión. Dado que el protocolo de comunicación orientado a conexión
más usado en la actualidad es TCP (Transmission Control Protocol), todos los
ejemplos harán referencia a este protocolo. Sin embargo, conviene aclarar que la
falsificación (spoofing o forging) de direcciones es factible en cualquier
protocolo de comunicación orientado a conexión.
Bajo TCP/IP, el establecimiento de la conexión y la desconexión se llevan a
cabo mediante "saludos de tres vías" (three way handshakes). Durante el
establecimiento de la conexión, cada máquina le dice a la otra su número de
secuencia inicial, y reconoce el número de secuencia inicial de la otra máquina.
Figura 1:
2

3. Establecimiento de una conexión.
+------+ +------+
|HOST A| |HOST B|
+------+ +------+
| SYN(#SEQ=X; #ACK=0)
+--------------------------->> |
|
SYN_ACK(#SEQ=Y; #ACK=X+1) |
| <<---------------------------+
|
| ACK(#SEQ=X+1; #ACK=Y+1)
+--------------------------->> |
|
...
donde:
'#SEQ' es el número de secuencia. Indica el número del próximo byte a ser
enviado, o que es enviado en el paquete.
'#ACK' es el número de secuencia que una máquina espera de la otra máquina con
la que se está comunicando.
'SYN' es el primer mensaje de sincronización. La máquina 'A' envía su número de
secuencia actual ('X') a la máquina 'B'. '#ACK' en este caso vale cero porque no
hay nada que reconocer.
'SYN_ACK' es el segundo mensaje de sincronización. La máquina 'B' reconoce el
número de secuencia de la máquina 'A' (le informa a 'A' que "esperará" por el
mensaje con número de secuencia 'X+1'), y le envía el número de secuencia propio
('Y').
'ACK' es el último mensaje del "saludo". La máquina 'A' reconoce el número de
secuencia de 'B' (le informa a 'B' que "esperará" por el mensaje con número de
secuencia 'Y+1'), e incrementa su propio número de secuencia en 1.
La conexión no se considera establecida hasta que una y otra máquina haya
reconocido el número de secuencia de la otra. Una vez que la conexión ha sido
establecida, los números de secuencia serán utilizados para garantizar la
entrega ordenada de los datos.
Bajo el conjunto de protocolos de internet, cuando una máquina desea enviar
un paquete a una máquina remota sólo necesita colocar el paquete en la red, y el
paquete será automáticamente ruteado a través de la red hasta que alcance su
destino. Ni la máquina emisora, ni la máquina receptora necesitan conocer la
arquitectura de la interred. Además, la mayor parte del tiempo, durante el viaje
del paquete a través de la interred, sólo la dirección destino del paquete es
examinada. Por lo tanto, la dirección fuente puede ser cualquier cosa, incluso
la dirección de una máquina inexistente, y la interred entregará el mensaje sin
ningún cuestionamiento.
3) Desarrollo.
3

4. Sean tres máquinas 'A', 'B', y 'X'. La máquina 'A' tiene algunos privilegios
en la máquina 'B', por lo cual puede solicitarle a 'B' la realización de ciertas
acciones, que no haría para cualquier otra máquina 'Q'. En la máquina 'X' está
"trabajando" un intruso. Su objetivo es, sabiendo que 'A' tiene privilegios en
'B', hacer que 'B' realice alguna de las acciones que realizaría para 'A' pero
no para cualquier otra máquina. En otras palabras, 'X' intenta enmascararse como
'A'.
La localización en la interred de las máquinas intervinientes, y la
naturaleza de la comunicación usada para que 'B' realice las acciones deseadas,
determinarán la estrategia utilizada por el intruso, así como también las
estrategias de detección y/o defensa en las máquinas 'A' y 'B'.
Suponiendo que las máquinas 'A' y 'B' se encuentran en redes diferentes, la
localización de 'X', respecto de 'A' y 'B' puede ser:
(X1) En la misma red que 'A'.
(X2) En la misma red que 'B'.
(X3) En algún lugar del camino entre 'A' y 'B'.
(X4) En algún otro lugar que no sea (1), (2), ni (3).
Figura 2:
Posibles posiciones del intruso 'X' respecto de 'A' y 'B'.
+------+ +------+
|HOST A|-------------------------| X1 |
+------+ | +------+
( )
interred ( )
( )
| +------+
|----| X3 |
| +------+
( )
interred ( )-------+
( ) | +------+
| |-| X4 |
| | +------+
+------+ | +------+
|HOST B|-------------------------| X2 |
+------+ +------+
Dado que 'X' desea hacer que 'B' realice alguna acción pretendiendo ser 'A',
la comunicación de 'X' con 'B' debe ser indistinguible de la comunicación de 'A'
con 'B' (al menos desde el punto de vista de B). Las comunicaciones se pueden
dividir en dos categorías: órdenes y diálogos. En las primeras, una máquina
cliente envía un mensaje de solicitud de servicio a una máquina servidora, quien
lleva a cabo alguna acción, y luego retorna (o no) alguna respuesta a la máquina
solicitante. Las llamadas a procedimientos remotos (RPCs) sobre el protocolo UDP
son ejemplos de este tipo de comunicación. En las segundas, se produce un
intercambio de mensajes entre la máquina cliente y la máquina servidora, antes
de que la máquina servidora realice la acción solicitada. La máquina servidora
no ejecutará acción alguna si ve que el diálogo no tiene sentido. Cualquier
comunicación sobre el protocolo TCP se considera un diálogo. Para muestra, basta
mirar el "saludo de tres vías": se intercambian al menos tres mensajes entre la
4

5. máquina cliente y la máquina servidora antes de que se envíe la solicitud de
servicio.
Para que la máquina 'X', pretendiendo ser la máquina 'A', logre el objetivo
de hacer que la máquina 'B' lleve a cabo alguna acción, debe enviar un mensaje
falso hacia 'B', establecer un diálogo con 'B' de ser necesario, y prevenir que
la máquina 'A' interfiera en la comunicación.
Para que 'X' pueda transmitir un paquete falso, sólo tiene que armarlo y
colocarlo en la red. El software de ruteo en la red lo entregará en destino. Si
la comunicación está basada en órdenes, con enviar un sólo paquete, la máquina
'X' habrá cumplido su primer objetivo. Sin embargo, si la comunicación está
basada en diálogos, la máquina 'X' deberá enviar a la máquina 'B' varios
paquetes, y el contenido de los mismos dependerá de las respuestas que dé 'B'
(en el caso del protocolo TCP, necesitará el número de secuencia de cada paquete
enviado por 'B'). Si la máquina 'X' se encuentra en el camino entre 'A' y 'B'
(posición X3 en la figura 2), en la red de 'A' (posición X1), o en la red de 'B'
(posición X2), podrá observar las respuestas que 'B' envía hacia 'A', pudiendo
así armar nuevos paquetes falsos que sean significativos para 'B'. Si la máquina
'X' no está en ninguna de las posiciones antes mencionadas (posición X4 en la
figura 2), podrá aún observar las respuestas de 'B' si es capaz de redirigir el
tráfico de paquetes desde 'B' hacia 'A' para que pase a través de la propia red
de 'X' (esto se conoce como ruteo fuente (source routing)). Otra alternativa
para 'X' sería predecir las respuestas de 'B' (por ejemplo, en el caso del
protocolo TCP, predecir cuál será el próximo número de secuencia de 'B').
Para prevenir que la máquina 'A' interfiera en el ataque, la máquina 'X'
puede: prevenir que los paquetes de 'B' alcancen a 'A' (o que los paquetes de
'A' alcancen 'B'), anular de alguna manera a 'A' para que no pueda responder, o
completar la comunicación antes de que las advertencias de 'A' alcancen 'B'. La
primera estrategia requiere que 'X' modifique el comportamiento de ruteo de la
red, o bien que 'X' espere a que la interred entre 'A' y 'B' falle, y atacar
después. La segunda estrategia requiere que 'X' haga que 'A' se cuegue, esperar
a que 'A' caiga por alguna otra razón (por ejemplo, mantenimiento), o
bloquear/modificar la porción de software de red en el sistema operativo de 'A'
para que no pueda procesar los paquetes de 'B' (por ejemplo, utilizando un
programa troyano). La tercera estrategia es trivial en el caso de que la
comunicación esté basada en órdenes: la máquina 'B' completará la operación
solicitada por 'X' antes de enviar cualquier respuesta a 'A'. Cuando 'A' se
entere, ya será demasiado tarde para alertar a 'B'. Si la comunicación está
basada en diálogos, la solución es más difícil ya que 'B' enviará mensajes a 'A'
antes realizar la operación requerida. Sin embargo, si la comunicación entre 'X'
y 'B' es más rápida que entre 'A' y 'B', 'X' podría completar el ataque a
tiempo.
4) Un ejemplo de ataque.
El ataque que se describirá a continuación fue lanzado el 25 de Diciembre de
1.994 contra la máquina de Tsutomu Shimomura, y alcanzó gran notoriedad en la
prensa popular, la Usenet, y el CERT (Computer Emergency Response Team).
En este ataque en particular, los involucrados fueron: una Sparcstation sin
disco corriendo el sistema operativo Solaris 1 que actuaba como terminal-x, y
una Sparcstation corriendo el mismo sistema operativo que actuaba como servidor
de la terminal-x. Estas máquinas jugaban los papeles de 'B' y 'A',
5

6. respectivamente, según el modelo general descripto en la sección anterior. La
posición del intruso era X4, según la figura 2.
Primero, el instruso 'X' debía evitar que 'A' pudiera procesar las respuestas
de 'B'. Logró este objetivo enviando múltiples solicitudes de conexión al puerto
rlogin de 'A' (puerto 513) con la dirección de una máquina inexistente como
dirección fuente. 'A' respondió a cada solicitud, pero la tercera parte del
saludo de tres vías no se completó por un cierto tiempo. 'A' quedó entonces con
varias conexiones semiabiertas. Como 'A' sólo podía soportar ocho de esas
conexiones semiabiertas antes de que sus tablas internas se llenaran, 'A' dejó
de responder a nuevas solicitudes de conexión dirigidos al puerto 513. En
particular, no generaría comandos reset (RST) de TCP en respuesta a
reconocimientos (ACK) no esperados de solicitudes de conexión inicial (SYN). Se
presume que el intruso usó una dirección ficticia como dirección fuente de la
solicitud rlogin porque si no el software TCP/IP de su propia máquina hubiese
enviado comandos reset al recibir la respuesta de 'A', y 'A' al recibir dichos
RST hubiese "cortado" las conexiones semiabiertas, liberando el espacio de sus
tablas.
Luego, dado que su posición respecto de 'A' y 'B' no le permitía ver los
mensajes que 'B' le enviaría a 'A', el intruso debía predecir cuáles eran los
números de secuencia de esos mensajes para poder sostener un diálogo coherente
con 'B' (la terminal-x). Necesitaba observar el comportamiento del generador de
números de secuencia TCP de 'B'. Para ello, el intruso le envió veinte
solicitudes de conexión. Al hacer esto, observó que el número de secuencia
inicial de 'B' para el reconocimiento de cada solicitud de conexión se
incrementaba en 128000. El intruso usó la dirección de una máquina legítima como
dirección fuente para las solicitudes de conexión, pero las solicitudes mismas
no fueron generadas por la implementación TCP de esa máquina, sino
artificialmente por el intruso. Así cuando 'B' respondió a la segunda parte del
saludo directamente a esa máquina, el sistema operativo de esta última, que no
hizo realmente la solicitud inicial, generó el mensaje de reset respectivo. Esto
previno que el sistema operativo de 'B' llenara sus tablas internas con
conexiones semiabiertas en la misma forma en que lo hizo 'A'. La dirección de
las solicitudes falsas pudo haber sido la de la propia máquina del intruso, o
bien la de otra máquina. Si hubiese sido la de otra máquina, el intruso debía
poder observar el camino entre 'B' y la otra máquina, para poder inspeccionar
los números de secuencia.
A continuación, el intruso sostuvo un diálogo TCP/IP con 'B' pretendiendo ser
'A'. A pesar de que el intruso no podía ver las respuestas de 'B' (que iban
dirigidas a 'A', quien a su vez no podía responder) ya sabía como predecir los
números de secuencia de 'B'. Por lo tanto, el intruso podía falsificar los
reconocimientos a cualquier mensaje proveniente de 'B' con el número de
secuencia que 'B' esperaba. La solicitud de acción del intruso a 'B' fue una
cierta modificación al archivo /.rhosts en 'B'. Éste, creyendo que la conexión
provenía de 'A' llevó a cabo la solicitud. Como consecuencia de la acción, a
partir de ese momento, cualquier usuario desde cualquier lugar podía acceder a
la máquina 'B' vía rlogin con privilegios de root. El tiempo total transcurrido
desde el primer paquete falsificado (para poner a 'A' fuera de juego) hasta ese
momento había sido menor a 16 segundos.
Después de lograr que 'B' modifique el archivo para el intruso, éste cerró la
conexión falsa, y envió los mensajes de reset necesarios a 'A' para que cierre
las ocho conexiones que habían quedado semiabiertas. El intruso ya tenía
privilegios de root en la terminal-x. Hizo login, y luego compiló e instaló un
cierto módulo de kernel en la terminal-x, con el objetivo final de "secuestrar"
6

7. una sesión login ya autenticada en la terminal-x (ataque conocido en la
bibliografía como "session hijacking").
5) Sugerencias para prevención.
La infraestructura de la Internet puede descomponerse en tres:
(1) Proveedores de backbone: proveen servicios de transporte de paquetes en
áreas extensas.
(2) Redes privadas: propiedades de compañías, instituciones, agencias
gubernamentales, y otras partes, para propósitos personales.
(3) Proveedores de servicios de Internet: proveen conexiones entre elementos del
backbone y redes privadas, algunas veces incluyendo otros proveedores de
Internet.
Si todas las partes de la infraestructura actúan en conjunto, es posible
ELIMINAR TODAS las falsificaciones de direcciones IP. Esto se logra haciendo que
los ruteadores (routers) y compuertas (gateways) fuercen la estructura física de
la red, rehusándose a rutear paquetes "ridículos". Ejemplos sencillos son:
* La dirección IP 127.0.0.1 sólo es usada para ruteo interno de paquetes desde
una máquina a sí misma. Ningún paquete con esta dirección fuente debería
atravezar un ruteador o compuerta. Rutear estos paquetes es peligroso porque
pueden ser usados para falsificar paquetes del localhost, el cual suele tener
privilegios especiales.
* La dirección IP 0.0.0.0 no es legítima, ni como dirección fuente ni como
dirección destino. Desafortunadamente, muchos ruteadores usan la convención del
'.0.' en sus tablas de filtrado para indicar cualquier dirección entre 0 y 255.
Por lo tanto, bloquear estos paquetes puede ser no trivial en algunas partes de
la infraestructura. Lo mismo ocurre con las direcciones IP que contienen 255
como el número de máquina o como cualquier elemento en la dirección IP.
* La especificación de IP incluye provisiones para subredes privadas que son
designadas para uso interno sólamente. No existe razón legítima para rutear
paquetes con esa dirección fuente o destino a ningún lugar en la infraestructura
general de Internet.
El próximo paso es que cada una de las partes de la infraestructura se
comprometa a:
(a) Redes privadas:
(a1) Prevenir que todos los paquetes "malos" conocidos entren o
salgan de su infraestructura.
(a2) Prevenir que paquetes con direcciones fuente internas entren
desde el exterior. Justificación: "sólo máquinas de NUESTRA red
pueden generar paquetes con direcciones fuente internas".
(a3) Prevenir que paquetes con direcciones fuente externas salgan al
exterior. Justificación: "alguno de nuestros usuarios está
intentando atacar una máquina en el exterior usando address
spoofing".
(a4) Prevenir que paquetes con direcciones destino externas entren
7

8. desde el exterior. Justificación: "nosotros somos una red
privada. No es nuestra labor rutear paquetes ajenos".
(a5) Prevenir que paquetes con direcciones destino internas salgan al
exterior. Justificación: "un paquete generado en nuestra red,
destinado a otra máquina en nuestra red no tiene por qué salir
de la red y volver después".
(b) Proveedores de servicios de Internet:
(b1) Prevenir que todos los paquetes "malos" conocidos entren o
salgan de su infraestructura.
(b2) Prevenir que cualquier paquete de entrada de cualquiera de sus
clientes con una dirección fuente que no pertenece al rango de
direcciones asignadas para el cliente pase desde la red del
cliente. Justificación: "alguno de nuestros clientes quiere
atacar a otra máquina en la Internet usando address spoofing".
(b3) Prevenir que cualquier paquete con dirección destino que no
pertenece al rango de direcciones del cliente pase a la red del
cliente. Justificación: "ese paquete no va dirigido a ese
cliente".
(b4) Prevenir que cualquier paquete con dirección fuente no
perteneciente al rango de direcciones del proveedor de Internet
entre en el backbone. Justificación: "todos los paquetes que
generen nuestras máquinas deben ser auténticos".
(b5) Prevenir que cualquier paquete proviniente del backbone y no
destinado a una de sus direcciones IP legítimas entre en su red.
Justificación: "ese paquete no está destinado a nosotros, ni a
ninguno de nuestros clientes".
(b6) Prevenir tráfico de entrada del cliente con la dirección del
cliente como destino. Justificación: "el paquete jamás debió
salir de la propia red de nuestro cliente".
(b7) Prevenir tráfico de salida al cliente con la dirección del
cliente como supuesta dirección fuente. Justificación: "alguien
en la Internet está intentando atacar a uno de nuestros clientes
usando address spoofing".
(c) Proveedores de backbone.
(c1) Prevenir que todos los paquetes "malos" conocidos entren o
salgan de su infraestructura.
(c2) Prevenir que cualquier paquete que se origine en algún proveedor
de Internet con dirección fuente no perteneciente a su rango
legítimo de direcciones fuentes entre en el backbone.
Justificación: "el proveedor de Internet dejó escapar algún
paquete falso".
(c3) Prevenir que cualquier paquete no destinado para el rango de
direcciones de un proveedor de Internet entre en la
infraestructura de ese proveedor de Internet. Justificación:
8

9. "ese paquete no está destinado a ese proveedor de Internet".
(c4) Prevenir que cualquier paquete de otro proveedor de backbone que
no pudiera ser ruteado apropiadamente a través de ese proveedor
entre en el backbone propio. Justificación: "recibimos un
paquete con dirección fuente 'Cutral Có' proveniente del
backbone 'General Roca'. Nosotros estamos en Neuquén. ¡Algo
huele mal! (ese paquete sólo podría haber llegado desde el
backbone 'Senillosa', por ejemplo)".
(c5) Prevenir que cualquier paquete vaya a otro proveedor de backbone
a menos que pueda ser legítimamente ruteado a través de ese
proveedor para alcanzar su destino. Justificación: "debemos
enviar un paquete a 'Cutral-Có'. El backbone 'Senillosa' es la
dirección a sequir, no así el backbone 'General Roca'".
Los proveedores de backbone son los que tienen el trabajo más difícil dado el
inmenso volumen de información que transportan, pero el esfuerzo requerido está
justificado por la misma razón.
Las sugerencias arriba planteadas son:
* Fáciles de implementar, y a un bajo costo: no requiere cambios en protocolos
existentes de patrones de tráfico. La tecnología para hacerlo ya está en su
lugar (de hecho siempre estuvo). Virtualmente, cualquier ruteador y compuerta
existente hoy en día permite filtrado de paquetes basándose en su interfaz de
entrada y en direcciones IP fuentes y destino. Esta capacidad es indispensable
para su operación, y es la base para la manera en que rutean todos los paquetes.
El costo de implementación es de apenas unos minutos de esfuerzo por parte de
los administradores de sistema para configurar ruteadores y compuertas, ya sea
durante el proceso de instalación o mantenimiento, o incluso si toda la red ya
está en funcionamiento. A diferencia de muchos problemas en la Internet que son
muy difíciles de resolver, y que requerirán años de evolución, este problema
puede ser resuelto ahora.
* Tiene sentido desde el punto de vista del tráfico, y de la seguridad de cada
una de las partes que participan: en una red que ya está en pleno
funcionamiento, los paquetes "malos" conocidos, en el mejor de los casos, son
inútiles; en el peor de los casos, forman parte de alguna acción maliciosa. No
existe razón valedera para redirigirlos.
* Permite todas las actividades legítimas sin restricciones: las restricciones
propuestas sólo aseguran que la Internet trabaje correctamente. Además, no
existe ningún filtrado de contenidos y/o violación de la privacidad, porque la
información que viaja en el paquete no es inspeccionada, sino sólo aquella
información necesaria para el ruteo del paquete. El flujo de
información/contenidos sigue siendo libre.
* Funciona aunque no todas las partes participen (excepto si NADIE participa):
si todas las redes privadas ignoraran las reglas, las reglas de los proveedores
de Internet prevendrían que falsificaciones de direcciones IP se extiendan a
toda la infraestructura de la Internet. Si los proveedores de Internet ignoraran
las reglas, los proveedores de backbone pueden proteger al resto de la Internet,
al menos al punto en que los paquetes falsos dentro del dominio de un proveedor
de Internet se mantengan dentro, o sean rastreables a ese dominio (por supuesto,
clientes de ese proveedor de Internet podrán ser víctimas de otros clientes de
ese proveedor). Si todos los proveedores de backbone ignoraran las reglas, a
9

10. menos que todo el mundo las siga, seguirán las falsificaciones IP a través de
los proveedores de Internet que no sigan las reglas. A medida que más usuarios
de Internet y proveedores prevengan la falsificación de direcciones IP, el
trabajo del atacante se volverá más y más difícil.
6) Conclusiones.
La razón por la cual existe este tipo de ataques yace en el hecho de que los
desarrolladores de aplicaciones han elegido usar como medio de autenticación una
característica de los protocolos de comunicación que no fue diseñada para
proveer seguridad, a saber, la dirección de red del emisor.
La solución no consiste en "parchar" los protocolos de comunicación. Después
de todo, los protocolos funcionan, y no hace falta reparar algo que no está
roto. Lo que si no se debe hacer es construir rascacielos sobre arenas
movedizas: los sistemas y los desarrolladores de aplicaciones deben construir su
seguridad sobre características de los protocolos que hayan sido desarrolladas
desde un principio para proveer seguridad. En su defecto, la porción de
seguridad de las aplicaciones debe desligarse totalmente del protocolo de
comunicación, por ejemplo, bajo la forma de una subcapa de la capa de
Aplicación, con interfaz directa a la capa de Transporte, según el modelo de
referencia de arquitectura de red descripto por Andrew S. Tanenbaum en su libro
"Computer Networks", tercera edición.
Figura 3:
Modelo de referencia de arquitectura de red descripto por A. S. Tanenbaum.
+-----------------------+
5 | Capa de aplicación |
+-----------------------+
4 | Capa de transporte |
+-----------------------+
3 | Capa de red |
+-----------------------+
2 |Capa de enlace de datos|
+-----------------------+
1 | Capa de física |
+-----------------------+
Las medidas de prevención descriptas anteriormente pueden eliminar el
problema de raíz, sin tener que reescribir ninguna de las aplicaciones ya
existentes. Pero hace falta que proveedores de backbone, de servicios de
Internet y propietarios de redes privadas se comprometan a hacer su parte. La
concientización sobre la seguridad informática crece día a día. Las redes
actuales crecen, nuevas redes surgen, se desarrollan cada vez más aplicaciones
distribuídas, y se implementan nuevos servicios: hace falta proveer una
infraestructura de seguridad mínima para que estos "rascacielos" no se
desmoronen. Aún así, no es raro encontrar todavía a proveedores de backbone o de
servicios de Internet que se niegan responsabilizarse por el contenido de
mensajes en la Internet, alegando ser sólo "proveedores de servicios de
distribución". Se puede estar a favor o en contra, pero lo cierto es que si cada
uno hiciera sus deberes, este tipo de ataques quedaría erradicado, la Internet
operaría más eficientemente (pues menos paquetes "malos" ocuparían ancho de
banda), y todos saldría beneficiados.
10

11. Bibliografía:
* "Attack class: Address Spoofing" (Paper)
Autores:
L. Todd Heberlein
(de la empresa Net Squared)
Matt Bishop
(Departamento de Ciencias de la Computación de la
Universidad de California)
* "Internet Holes: Eliminating IP Address Forgery" (paper)
Autor:
Fred Cohen
- Presidente de Management Analytics (grupo de consultoría de
seguridad informática).
- Miembro del consejo editorial de Network Security, y
Computers and Security.
- Miembro del consejo de Australian Netmail y Allthings
Incorporated.
- Autor de muchos libros y artículos (quien acuñó el término
"virus de computadora").
Dirección web:
www.all.net
* "How Mitnick hacked Tsutomu Shimomura with an IP secuence attack"
Autor:
Tsutomu Shimomura
Fecha de publicación:
25/01/1.995
Lugar de publicación:
grupo de usenet 'comp.security.misc'
* "Computer Networks" (tercera edición).
Autor:
Andrew S. Tanenbaum
Año de publicación:
1.996
Editorial:
Prentice Hall
11