5.1 Intermediario [13]

TECNICA DE HACKING SMURF
OSCAR LOPEZ [email protected]
ALEXANDER NAVARRETE [email protected]
LUIS JOSE PULIDO [email protected]
SANDRA GARCES [email protected]
UNIVERSIDAD DE LOS ANDES
RESUMEN
En el diseño y desarrollo de un proyecto en el área informática, es importante tener en
cuenta la seguridad de éste como una propiedad básica. Para llegar a cumplir este objetivo
es necesario conocer los aspectos vulnerables del sistema en cuestión, para saber como
protegerlo de posibles ataques tanto internos como externos a la organización que requiere
implantarlo. Un mecanismo para lograrlo es situarse desde el propio punto de vista del
potencial atacante, con el fin de entender y predecir sus motivos, sus intenciones, conocer
sus herramientas de agresión, tomando así, las medidas necesarias de defensa. Existen
diversas formas de ataques que pueden atentar contra los principios básicos de la
información como lo son la integridad, la confidencialidad y la disponibilidad; en el
presente artículo se mostrará un tipo de ataque que atenta contra ésta ultima característica,
el “Smurf”.
PALABRAS CLAVES:
Smurf , ICMP, DoS.
1. INTRODUCCION
En este paper hablaremos específicamente de “Smurf”, que es un tipo de ataque
ampliamente difundido y para el cual ya existen mecanismos de defensa establecidos. Para
exponer este ataque, plantearemos su definición, estructura del paquete ICMP, que es el
paquete que se manipula para realizar el ataque, mecanismos de ataque y mecanismos de
defensa.
La información expuesta fue obtenida de papers y artículos publicados en Internet,
principalmente de CERT.
2.DEFINICIÓN [1]
El ataque "Smurf" pertenece a la familia de ataques conocidos como Denial of Services
(DoS), los cuales tienen como objetivo principal dejar fuera de servicio a la máquina que se
ataca.
1
3. ICMP [2], [3]
La operación de Internet está constantemente vigilada por los enrutadores, cuando en
Internet ocurre algo inesperado, como por ejemplo el error en el proceso de datagramas, el
ICMP (Internet Control Message Protocol, protocolo de mensajes en Internet) informa el
suceso.
ICMP es una parte integral del protocolo IP (Internet Protocol) y debe ser implementado
por cada módulo IP. Los mensajes ICMP pueden ser utilizados en diferentes situaciones:
cuando un datagrama no puede llegar a su destino, cuando el gateway no tiene la capacidad
para manejar un datagrama específico o cuando el gateway puede informarle al host que es
posible enviar tráfico por una ruta más corta.
El IP no está diseñado en absoluto para ser confiable. El propósito de estos mensajes de
control es proveer ayuda sobre problemas en la comunicación, y no es hacer a IP confiable.
Aún no hay garantías de que un datagrama será entregado o que un mensaje de control será
respondido. Algunos datagramas pueden no ser entregados sin el reporte de su pérdida a la
fuente.
Los mensajes ICMP típicamente reportan errores en el proceso de datagramas. Para evitar
la regresión infinita de mensajes sobre mensajes, ningún mensaje ICMP es enviado para
informar sobre otro mensaje ICMP.
3.1 Formato de un mensaje ICMP. [2]
Los mensajes ICMP son enviados usando el encabezado básico IP. El primer byte de la
porción de datos del datagrama es un campo de tipo ICMP, el valor de este campo
determina el formato de los datos restantes. Cualquier campo etiquetado como "no usado"
es reservado para extensiones en el futuro y deben ser 0 cuando es enviado, los receptores
no deben usar estos campos (excepto para incluirlos en la suma de comprobación o
checksum). El formato del encabezado IP para ICMP es:
12345678123456781234567812345678
·-------+-------+-----------------+----------------------------------·
| Vers. | IHL | Tipo de Serv. |
Longitud Total
|
|-------+-------+-----------------+-+-+-+--------------------------|
|
Identificación
|0 |d |m| Desplazamiento |
|----------------+-----------------+-+-+-+------------------------- |
| T.de Vida | Protocolo | Suma de Comprobación. |
|----------------+-----------------+--------------------------------- |
|
Dirección de Origen
|
|----------------------------------------------------------------------|
|
Dirección de Destino
|
·----------------------------------------------------------------------·
2
Versión: lleva el registro de la versión del protocolo al que pertenece el mensaje en nuestro
caso es 4.
IHL (Internet Header Length): ya que la longitud de la cabecera no es constante, se
incluye este campo para indicar la longitud en palabras de 32 bits. El valor mínimo es de 5,
cifra que aplica cuando no hay opciones en el encabezado.
Tipo de Servicio: permite al host indicar a la subred el tipo de servicio que quiere, en
nuestro caso el tipo es 0.
Longitud Total: incluye la longitud total del mensaje, tanto en la cabecera como en los
datos.
Identificación: Usado en la fragmentación del mensaje, todos los fragmentos de un
mensaje tienen el mismo identificador
A continuación viene un bit sin uso y luego dos campos de 1 bit.
DF (d): (Don´t Fragment) es una orden para los enrutadores de que no fragmenten el
mensaje porque el destino es incapaz de juntar las piezas de nuevo.
MF (m): (More Fragments) significa más fragmentos. Todos los fragmentos excepto el
último tienen establecido este bit, que es necesario para saber cuando han llegado todos los
fragmentos de un mensaje.
Desplazamiento de Fragmento: indica en que parte del mensaje va este fragmento.
Tiempo de Vida: es un contador que sirve para limitar la vida de un mensaje. Se supone
que este contador cuenta el tiempo en segundo, permitiendo una vida máxima de 255
segundos; debe disminuirse en cada salto y se supone que se disminuye muchas veces al
encolarse durante un tiempo grande en un enrutador. En la práctica, simplemente cuenta los
saltos. Cuando el contador llega acero, el paquete se descarta y se envía de regreso un
paquete de aviso al host de origen.
Protocolo: ICMP = 1 (Definido en el RFC 1700)
Suma de Comprobación de la Cabecera: verifica solamente la cabecera y debe
recalcularse en cada salto.
Dirección de Origen: La dirección del gateway o host que compuso el mensaje ICMP.
Dirección Destino: La dirección del gateway o host a quien el mensaje va dirigido.
3
3.2 Formato del Mensaje Echo (Reply y Request)
A continuación mostraremos el formato del mensaje ICMP Echo Reply Message (ping),
que es el tipo de mensaje de control utilizado más frecuentemente para crear un ataque
smurf:
12345678123456781234567812345678
·---------------+---------------+------------------------------------·
| Tipo
| Código | Suma de Comprobación |
|---------------+---------------+------------------------------------|
|
Identificación
| Número de Secuencia
|
|--------------------------------+------------------------------------|
| Datos...
·---------
3.2.1 Campos IP. [2]
Direcciones: La dirección de la fuente en un mensaje echo será el destino de la respuesta
echo (echo reply). Para formar una respuesta echo, la dirección de la fuente y destinatario
están invertidos, el tipo de código cambia a 0, y la suma de comprobación recalculada.
3.2.2 Campos ICMP. [2]
Tipo: 8 = mensaje echo
0 = mensaje echo de respuesta (echo reply)
Código:
0
Checksum: La suma de comprobación es complemento a uno de 16 bits del mensaje ICMP
empezando con el Tipo. Para computar la suma, el campo suma de comprobación debe ser
0. Si el tamaño total es impar, los datos recibidos son completados con 0 para ejecutar la
suma de comprobación.
Identificador: Si el código es 0, el identificador ayuda a encajar mensajes echo con
respuestas.
Número de Secuencia: Si el código es 0, el número de secuencia ayuda a encajar mensajes
echo con respuestas.
Descripción: Los datos recibidos en un Echo, deben ser retornados en el mensaje echo de
respuesta. El identificador y el número de secuencia pueden ser usados por la máquina que
envía el echo request para ayudar a encuadrar las respuestas con las peticiones. Por
ejemplo, el identificador podría ser usado como un puerto en TCP o UDP para identificar
una sesión, y el número de secuencia debe incrementar en cada petición de echo enviado.
4
La máquina que recibe el echo debe enviar esos mismos valores de regreso. El código 0
puede ser recibido de un gateway o un servidor.
4. ATAQUE SMURF [1], [3]
"Smurf" es el nombre de un programa automático que ataca una red explotando el
direccionamiento broadcast del protocolo IP. El ataque Smurf puede causar que la parte
atacada de la red se vuelva inoperable, tomando características del protocolo IP y el
protocolo de Control de Mensajes en Internet (ICMP). Un programa "Smurf" emplea otra
técnica de hacking conocida con el nombre de “IP Spoofing” la cual tiene por objetivo
suplantar la dirección IP de otra máquina, en particular “Smurf” construye un paquete de
red en el cual cambia el encabezado del mismo colocando como dirección origen la de la
máquina a atacar. El paquete contiene un mensaje ICMP (ping) que es enviado a una
dirección broadcast, o sea, a todas las direcciones IP de una red dada. Dichas máquinas
generan las respuestas del ping (echo reply) que son enviadas a la dirección de la víctima.
Suficientes pings y un buen número de respuestas de diferentes máquinas pueden inundar la
red haciéndola inoperable.
Resumiendo, tenemos que “Smurf” maneja tres elementos diferentes que trabajando entre si
generan el ataque, estos son:
1. Uso de ICMP (Internet Control Messaging Protocol), normalmente de la misma manera
que el ping. El propósito original de este protocolo es el de enviar y retornar mensajes de
error, en particular "ping" chequea que una máquina específica este viva.
2. IP (Internet Protocol), el cual es usado por los usuarios para enviar cualquier
paquete/mensaje en Internet. Por ejemplo se pueden enviar paquetes a una "dirección
broadcast".
3. Cambio de dirección origen, como ya lo dijimos anteriormente, se manipula el
encabezado del paquete ICMP cambiando la dirección origen del mismo para que de esta
manera las respuestas se generen hacia dicha dirección.
Si por ejemplo, una persona logra ejecutar un ataque "smurf" por intermedio de una red
(con su IP broadcast habilitado) que tiene 40 computadores, un solo mensaje ping creará 40
de respuesta. Es decir, que un usuario con un modem de 28.8 kbps, podría generar un
tráfico de (28.8 * 40)kbps o 1552 kbps, cerca de 2/3 de una línea T1.
5
4.1 Componentes
El ataque "smurf" tiene tres componentes principales:
4.1.1 El Atacante: es la persona que crea los paquetes ICMP con la IP fuente falsa y lanza
el ataque.
4.1.2 El Intermediario: la red amplificadora del paquete ICMP con su direccionamiento
broadcast habilitado.
4.1.3 La Víctima: su dirección IP ha sido suplantada para que las respuestas ICMP sean
enviadas a ella. Se debe anotar que el intermediario también puede convertirse en víctima.
4.2 Estructura de un Ataque SMURF en el Tráfico de Red [16] [17]
Desde el punto de vista del atacante, smurf genera un tráfico de red del siguiente estilo:
00:00:05
00:00:05
00:00:05
00:00:05
00:00:05
00:00:05
00:00:05
spoofed.net
spoofed.net
spoofed.net
spoofed.net
spoofed.net
spoofed.net
spoofed.net
>
>
>
>
>
>
>
192.168.15.255:
192.168.1.255:
192.168.14.255:
192.168.14.0:
192.168.15.255:
192.168.15.0:
192.168.16.255:
icmp:
icmp:
icmp:
icmp:
icmp:
icmp:
icmp:
echo
echo
echo
echo
echo
echo
echo
request
request
request
request
request
request
request
Acá se puede observar que se realizan varios icmp echo request a diferentes direcciones
broadcast que en este caso particular se encuentran en una misma red, dichos paquetes
llevan como dirección origen spoofed.net que será la máquina víctima.
Ejecutando el comando show access-list, para el enrutador de la máquina víctima se puede
ver una salida similar a esta:
interface serial 0
no ip access-group 169 in
6
no access-list 169
access-list 169 permit
access-list 169 permit
access-list 169 permit
access-list 169 permit
access-list 169 permit
access-list 169 permit
access-list 169 permit
icmp any any echo
icmp any any echo-reply log-input
udp any any eq echo
udp any eq echo any
tcp any any established
tcp any any
ip any any
interface serial 0
ip access-group 169 in
En la cual es posible apreciar que en el enrutador se están aceptando la entrada y salida de
los paquetes ICMP, UDP, TCP, IP y adicionalmente que sobre la entrada de los ICMP se
pide la generación de logs, lo que finalmente permitirá ver la estructura del tráfico generado
por un ataque smurf en la víctima. Dichos logs tienen una estructura similar a la siguiente:
%SEC-6-IPACCESSLOGDP: list
*HDLC*) -> 10.2.3.7 (0/0), 1
%SEC-6-IPACCESSLOGDP: list
*HDLC*) -> 10.2.3.7 (0/0), 1
%SEC-6-IPACCESSLOGDP: list
*HDLC*) -> 10.2.3.7 (0/0), 1
%SEC-6-IPACCESSLOGDP: list
*HDLC*) -> 10.2.3.7 (0/0), 1
%SEC-6-IPACCESSLOGDP:
list
*HDLC*) -> 10.2.3.7 (0/0), 1
%SEC-6-IPACCESSLOGDP: list
*HDLC*) -> 10.2.3.7 (0/0), 1
%SEC-6-IPACCESSLOGDP:
list
*HDLC*) -> 10.2.3.7 (0/0), 1
%SEC-6-IPACCESSLOGDP: list
*HDLC*) -> 10.2.3.7 (0/0), 1
%SEC-6-IPACCESSLOGDP: list
*HDLC*) -> 10.2.3.7 (0/0), 1
%SEC-6-IPACCESSLOGDP:
list
*HDLC*) -> 10.2.3.7 (0/0), 1
%SEC-6-IPACCESSLOGDP:
list
*HDLC*) -> 10.2.3.7 (0/0), 1
%SEC-6-IPACCESSLOGDP:
list
*HDLC*) -> 10.2.3.7 (0/0), 1
%SEC-6-IPACCESSLOGDP:
list
*HDLC*) -> 10.2.3.7 (0/0), 1
%SEC-6-IPACCESSLOGDP: list
*HDLC*) -> 10.2.3.7 (0/0), 1
%SEC-6-IPACCESSLOGDP:
list
*HDLC*) -> 10.2.3.7 (0/0), 1
%SEC-6-IPACCESSLOGDP: list
*HDLC*) -> 10.2.3.7 (0/0), 1
%SEC-6-IPACCESSLOGDP:
list
*HDLC*) -> 10.2.3.7 (0/0), 1
169 permit icmp
packet
169 permit icmp
packet
169 permit icmp
packet
169 permit icmp
packet
169 permit icmp
packet
169 permit icmp
packet
169 permit icmp
packet
169 permit icmp
packet
169 permit icmp
packet
169 permit icmp
packet
169 permit icmp
packet
169 permit icmp
packet
169 permit icmp
packet
169 permit icmp
packet
169 permit icmp
packet
169 permit icmp
packet
169 permit icmp
packet
192.168.45.142
(Serial0
192.168.45.113
(Serial0
192.168.212.72
(Serial0
192.168.132.154
(Serial0
192.168.45.15
(Serial0
192.168.45.142
(Serial0
192.168.132.47
(Serial0
192.168.212.35
(Serial0
192.168.45.113
(Serial0
192.168.132.59
(Serial0
192.168.45.82
(Serial0
192.168.212.56
(Serial0
192.168.132.84
(Serial0
192.168.212.47
(Serial0
192.168.45.35
(Serial0
192.168.212.15
(Serial0
192.168.132.33
(Serial0
7
Acá podemos ver la manera como el enrutador registra la llegada de los paquetes icmp
echo reply desde el (los) intermediario(s) hacia la víctima.
Cada uno de estos paquetes icmp echo reply tienen una estructura particular, los cuales
vistos a través de TCPDUMP nos permite dar el siguiente ejemplo:
04:19:31.800000
1.2.3.4
>
192.168.5.5:
icmp:
echo
4500
0028
b5cb
4000
fe01
b229
c0a8
0505
0000
bc9c
bf3c
f001
000d d5f0 000d 63e8 0000 0000 0000
reply
0102
0018
(DF)
0304
f81b
4.3 Casos [4] [5]
Algunos casos documentados de sistemas que han caído bajo un ataque de smurf, son el
caso de la Universidad de Minnesota, en marzo de 1998, cuando aun este tipo de ataque era
novedoso, la red de computadores de la universidad presento bajo rendimiento por más de
tres horas, porque no solo un objetivo del smurf es hacer caer una red sino también
disminuir su “performance”. En este caso se reporto que también fue afectado el MRNet
que compartía el ancho de banda de la universidad gracias a un acuerdo con el ISP de ésta.
Dicho sitio fue afectado de manera más severa, con la negación total del servicio y por más
de 8 horas; y otro caso reciente, fue el ataque que recibió el conocido Web site Yahoo en
febrero de 2000, el cual dejó el sito abajo por más de tres horas, negando el servicio a
miles de usuarios del popular motor de búsqueda.
5.DEFENSA
Al analizar la forma de ataque de smurf, podemos ver que todo depende de la reflexión y
multiplicación de los paquetes ping y como estos son enviados a una maquina víctima, la
cual es copada totalmente, así es que la víctima aunque no se quiera es atacada por
muchísimas maquinas al estas responder el paquete ICMP, es por esto que podemos dividir
la defensa en el intermediario, para evitar que lo replique, en víctima, para evitar que lo
reciba, y en origen, para evitar que salga.
5.1 Intermediario [13]
Una de las formas para evitar un ataque smurf es a través del intermediario el cual tiene dos
opciones:
Deshabilitar dirección IP broadcast
Configurar el sistema operativo para que no responda los ICMP
La primera trata de bloquear la dirección broadcast, con el fin de que en momento en que
llegue un paquete ICMP con un requerimiento broadcast este no responda y así no se
despliegue.
8
Configuraciones mínimas en los intermediarios según su constructor:
5.1.1. Cisco [13]
Deshabilitar todas las direcciones broadcast en los enrutadores de la red, sin importar que
los enrutadores no estén en los lugares de salida.
no ip directed-broadcast
Otra forma de protección es en el caso en que la red sea muy pequeña, lo cual haga que se
conozca perfectamente él trafico y cuales son las posibilidades de ataque a través de otras
redes, entonces se pueden bloquear las posibles IP de llegada de paquetes.
access-list 101 deny ip 0.0.0.0 255.255.255.255 172.16.0.255 0.0.255.0
access-list 101 deny ip 0.0.0.0 255.255.255.255 172.16.0.0 0.0.255.0
5.1.2. Data General Corporation [13]
El DG/UX, tiene una opción de eneable/disable, el cual habilita o deshabilita la recepción
de paquetes ICMP, por defecto viene en disable, en el DG/UX B2, viene con una opción de
netctrl, que ayuda a habilitar la recepción de mensajes ping.
5.1.2.DIGITAL EQUIPMENT CORPORATION [13]
Estos no tienen disponibles la opción de negar la llegada de paquetes ICMP, así es que es
necesario el manejo de firewalls con reglas para poder proteger la red.
5.1.3.FreeBSD Inc. [13]
En este viene por defecto el que no conteste a paquetes ICMP, y los multicast los
direcciona, esto puede ser cambiado por el comando sysctl.
5.1.4.IBM Corporation [13]
Dentro de la AIX4 existe un comando bcastping, el cual controla la llegada de paquetes
ICMP, en el momento en que el atributo este en cero no responde a los paquetes, si esta en
uno, si responde (por defecto viene en 0).
El siguiente comando coloca el atributo en cero
# no -o bcastping=0
Con el siguiente comando se averigua en que esta el atributo
$ no -o bcastping
En la AIX3 no existe este comando
5.1.5.Livingston Enterprises, Inc. [13]
Esta no responde a los paquetes ICMP que son enviados a una dirección diferente de la de
ella, pero si los remite.
9
5.1.6.NetBSD [13]
Se puede deshabilitar el que remita los mensajes con el siguiente comando:
# sysctl -w net.inet.ip.directed-broadcast=0
NetBSD siempre responde a los paquetes ICMP, pero más adelante se podrá evitar esto.
5.1.7.Sun Microsystems [13]
Para los Solaris 2.6, 2.5.1, 2.5, 2.4, y 2.3:se utiliza el siguiente comando para deshabilitar la
recepción de mensajes ICMP
ndd -set /dev/ip ip_forward_directed_broadcasts 0
Para los SunOS 4.1.3_U1 y 4.1.4, se coloca lo siguiente en el archivo de configuración y
reconstruye el kernel
“options DIRECTED_BROADCAST=0”
Para prevenir que responda a mensajes ICMP, se coloca el siguiente comando:
Solaris 2.6, 2.5.1, 2.5, 2.4, and 2.3:
ndd -set /dev/ip ip_respond_to_echo_broadcast 0
Para los SunOS 4.1.x, no existe ningún comando que cumpla esta función.
5.1.8.Proteon [14]
Configure "disable directed-broadcast"
5.1.9.Nortel/Bay [14]
Configura una dirección estática ARP incorrecta para la dirección broadcast
5.1.10.WinNT [14]
Configura una dirección estática ARP incorrecta para la dirección broadcast por ejemplo:
arp -s 192.0.2.255 00-00-00-00-00-00
5.1.11.Linux [14]
Configura una dirección estática ARP incorrecta para la dirección broadcast ejemplo: arp -s
192.0.2.255 00:00:00:00:00:00
Estos últimos hacen que los paquetes que van dirigidos a una dirección broadcast, vayan a
una dirección inexistente.
La segunda es para evitar que los paquetes hagan daño al ser enviados desde la misma red,
ya que existe la posibilidad que el perpetrador suplante una maquina de adentro y por lo
tanto no pase por los enrutadores, así que es necesario que el sistema operativo se encargue
de bloquear estos paquetes con el fin de que no hagan daño en la red.
10
5.2.Víctima[15]
Una forma de defensa para la víctima es muy difícil de encontrar, en especial para cuando
empieza a ser atacada es muy complicado lograr parar el ataque, por lo tanto la única
solución que existe es que el enrutador de la víctima se encargue de bloquear todos los
paquetes ICMP, lo cual no evitara del todo la congestión, así es que en el caso de un ataque
tiene que comunicarse con el intermediario para poder bloquear desde allá, la línea de
ataque que crean los paquetes.
5.3.Origen del Ataque[15]
Una de las mejores formas de bloqueo de este tipo de ataque es el que se hace desde la red
en la que se inicia. La forma de realizar esto es colocando un filtro en el enrutador dentro
de la red, el cual bloquee todos los paquetes que van a salir de la red con una dirección de
origen que no le pertenece, así es que si en una red con dirección IP 157.253.x.x, un
paquete intenta salir con dirección de origen 198.162.1.12, el enrutador lo detecta y no lo
deja salir.
Un ejemplo de cómo hacer esto, se puede ver en una Cisco: [13]
access-list 101 permit ip 172.16.0.0 0.0.255.255 0.0.0.0 255.255.255.255
access-list 101 deny ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
6.CONCLUSIONES
El Smurf es un tipo de ataque bastante poderoso, y a la vez no muy difícil de llevar a cabo
gracias a que el paquete ICMP que modifica, no tiene políticas de seguridad.
Cuando se presenta un ataque de Smurf no solo la víctima puede sufrir de DoS, también el
intermediario se puede ver seriamente afectado.
En este tipo de ataque es difícil detectar al agresor, dado que este suplanta la dirección de
origen del paquete por la de la víctima.
Es importante establecer mecanismos de seguridad para contrarrestar el ataque y son
particulares dependiendo la tecnología que utilice la organización.
Las decisiones que se tomen para implantar seguridad en la red, pueden privar de ciertas
ventajas al administrador y/o usuarios de ésta , pero es más alto el costo si la red cae bajo
un ataque de Smurf.
11
7.REFERENCIAS
1.http://www.whatis.com
2.Computer networks / Andrew S. Tanenbaum.
3.RFC 0792, Internet Control Message Protocol
4.http://www.time.com/time/digital/daily/0,2822,38899,00.html - 12-02-2001
5.http://canada.cnet.com/news/0-1003-200-327506.html - 06-02-2001
6.http://security-archive.merton.ox.ac.uk/CERT/007.htm
7.http://www.nordu.net/articles/smurf.html
8.http://www.ln.net/assoc/policies/smurf.html
9.http://moskva-gw.cccpnet.gov.ussr.net/~illodius/html/smurf.html
10.http://www.inet-one.com/cypherpunks/dir.1999.06.28-1999.07.04/msg00076.html
11.http://www.ee.siue.edu/~rwalden/networking/icmpmess.html
12.http://www.freesoft.org/CIE/RFC/792/index.htm
13.http://www.cert.org/advisories/CA-1998-01.html - 10-02-2001
14.http://download.networkice.com/Advice/Exploits/IP/smurf/Amplifier_Defense/defau
lt.htm -10-02-2001
15.http://www.iops.org/Documents/smurf-faq.html - 10-02-2001
16.http://www.kbeta.com/SecurityTips/Checklists/Cisco%20Packet%20Floods.htm#2d
– 05-06-2001
17.http://www.sans.org/newlook/resources/IDFAQ/traffic.htm – 08-06-2001
12