Prevención, detección y contención de ataques de denegación de servicio

1

´ ´ ´
Prevencion, deteccion y contencion para
´
ataques de denegacion de servicio

´
DAVID C EREZO S A NCHEZ

http://david.cerezo.name

2

´
Introduccion

´
¿Que es realmente Internet?

Elementos constitutivos fundamentales: routers, ordenadores finales,
conexiones
´
Analogás con objetos del mundo real: la red distribucion de agua
ı
´
Breve historia de la evolucion de Internet
´
Topologá de Internet, su representacion en forma de grafo y los sis-
ı
´
temas autonomos (AS).
El principio del mńimo esfuerzo
ı
Problemas derivados del principio del mńimo esfuerzo
ı
Los protocolos de Intenet y el modelo OSI
◦ Nivel subred: ARP, Ethernet
◦ Nivel Internet o red: IP
◦ Nivel de transporte: TCP, UDP

3

Grafo AS de Internet[ASCORE]

4

Tomograf´a ISPs[CheswickBurch]
ı

5

Relaciones entre AS[RltAS]

6

Numero ASs medio por path[ASpathlength]
´

7

Resistencia ataques globales [resilience]

8

Resistencia ataques globales (2)

9

Resistencia ataques globales (3)

10

´
Reparticion AS en el mundo [ASworld]

11

´
Introduccion DDoS

Primeras referencias a DoS en 1983 [Gilgor1983], y otros fallos en TCP/IP
[Bellovin1989].

Los costes: segun el economista Frank Bernhard, de la Universidad de
´
´
California en Davis, los fallos de conexion a Internet han costado a las
corporaciones americanas el 5.7 % de sus ingresos anuales. [DeLong2001]

´
Caracterizaciones matematicas utiles, teor´a anterior, para estudiar el
´ ı
´
fenomeno de los DDoS:

Cambios repentinos [Basseville]

´ ´
Teor´a de la catastrofe de Rene Thom.[Sanns2000, Okada1993,
ı
Zeeman, Afrajmovich1999, Yaes1993, Okninski, Gilmore, PostonStewart,
ArnoldEtAl, Saunders]

12

Estad´stica [Brodsky1993, HBStatistics]
ı

´
Teorá de juegos[Yau2002, HBGameTheory] y econometrica[Granger1969,
ı
HBEconometrics].

´
Complejidad de la comunicacion[KN1997, Hromkovic1997].

´
Analisis de series temporales [Hamilton1994]

´
Teorá del caos[BakerEtAl]: el trafico de Internet es self-similar.
ı

Teorá de las redes sociales[Wasserman1994]: power-laws en Internet[KParkLee200
ı

´
Siempre teniendo en cuenta que no existe un modelo teorico que capture el
´
funcionamiento dinamico de Internet [PaxsonFloyd].

´
En esta conferencia se expondra el state of art actual.

13

Taxonom´a DoS [Kumar1995, Richardson2001, MirkovicEtAl2001]
ı

14

´
DDoS y los sistemas autonomos

15

´
Arboles de ataques (1)

16

´

17

´

18

´

19

L´nea temporal ataques DDoS
ı

20

Herramientas DDoS

Trinoo: simple ataque UDP distribuido.

Tribe Flood Network: incopora ICMP, UDP, SYN-Flood y Smurf.

´
Stacheldracht y TFN2K : encriptacion entre zombies y master, modiﬁ-
´
cacion de los algoritmos de ataque con ligeras mejoras en eﬁciencia.

21

L´nea temporal ataques DrDoS
ı

22

Reflectores en DrDoS
Dificultan tracear el ataque hasta el Master .

´ ´
Crean difusion, hacen mas difćil de tracear el ataque.
ı

´
Lo ideal es buscar maximizar la siguiente relacion en ataques tipo flood:

I.reflector I.zombie
, donde I es la cantidad de bytes enviados
I.zombie I.reflector
´
aunque se podrá sacrificar por las ventajas que reporta la difusion.
ı

´
Fuentes potenciales de reflectores, con gran amplificacion y/o difćiles de
ı
filtrar:
Si los numeros de secuencia de los paquetes TCP son predecibles, se
´
puede conducir la pila del reflector por todos los estados TCP, enviando
´
grandes segmentos con tecnicas de ACK Splitting[SCWA99].

23

Peticiones DNS recursivas: si se ataca a un servidor DNS, los zom-
bies del atacante pueden utilizar otros servidores DNS como reflectores
´
que hagan peticiones masivas de resolucion recursivas. Si se puede
´ ´
spoofear la direccion de origen y colocar la direccion del servidor DNS
´
vćtima, se aumenta aun mas si cabe la congestion.
ı ´ ´
´
La opcion push del protocolo de Gnutella indica al servidor que intente
conectarse a un puerto e IP determinadas para transmitir informacion:´
´
parecida a la directiva port de FTP, pero en este caso el comando push
´
puede propagarse en la red Gnutella, perdiendose el origen. Es decir,
no hace falta spoofear paquetes TCP para conseguir anonimato.

´
Otras fuentes de reflectores, pero faciles de trazar o filtrar:

´
Fragmentos IP: d´ficiles de filtrar y faciles de crear en reflectores sin Path
ı
MTU discovery o cuando hay paths hasta la vćtima por tuneles GRE.
ı ´
Filtrar fragmentos no es recomendable, puesto que protocolos leg´timos
ı
como NFS y AFS los producen con mucha frecuencia.
Ping ICMP (echo, router solicitation, timestamp, information re-
´
quest/reply, address mask, timestamp). La forma mas conocida son los

24

ataques smurf , ICMP echo spoofeados a direcciones broadcast.
´
Trafico que genere mensajes ICMP (source quench, time exceeded,
redirect, unreacheable). No se deben filtrar, porque tanto traceroute co-
mo Path MTU discovery necesitan de ellos.
FTP-Bounce: permite enviar segmentos SYN.
SMTP relays
´ ´
Peticiones de conexion T/TCP: los numeros de secuencia solo incre-
´
mentan.
´
Peticiones SNMP spoofeadas: facil de filtrar.
Servidores proxy-cache: realizan peticiones de cualquier URL. Las
´
conexiones no pueden ser spoofeadas, es facil de trazar.

25

Estad´stica de Ataques DoS
ı

´
Analisis BackScatter [MooreEtAl2001]. Presupuestos:

Todos los paquetes de un ataque se entregan correctamente
La direcciones IP de origen por cada paquete son aleatorias
Cada paquete genera una unica respuesta, por lo que los paquetes no
´
solicitados observados son considerados backscatter .

Resultado: vigilando n direcciones IP diferentes durante un ataque de m
paquetes, la probabilidad de recibir un paquete ser´a
ı

nm
E (X) = 32
2

La tasa del ataque dirigido a la v´ctima en paquetes por segundo, R , se
ı
calcula a partir de la tasa media de respuestas no solicitadas dirigida al

26

rango monitorizado, R ,
232
R ≥R
n

Posibles violaciones de los presupuestos:

´
Seleccion aleatoria de IPs spoofeadas: ingress filtering, DrDoS o dis-
´
tribucion no aleatoria de las direcciones spoofeadas. Todas conllevan a
estimaciones por debajo de las reales.
´
Entrega perfecta: tambien conlleva a estimaciones por debajo de las
reales.
´
Respuestas no solicitadas validas, vg, en el protocolo NETBIOS. El por-
centaje es tan bajo que puede ser despreciado.

En [MooreEtAl2001], se monitoriza un rango /8 de bajo uso de Internet, se
´
filtran los paquetes y se clasifican segun los ataques y otros parametros.
´

Resultados (Febrero 2001):

27

Un total de 200 millones de paquetes en 3 semanas, provenientes
12805 ataques diferentes a 5000 direcciones IP vćtima diferentes en
ı
2000 dominios DNS.
´ ´
Mas del 50 % del trafico de respuesta era TCP, seguido de un 38 % de
´
trafico ICMP.
´
El 92 % del trafico de ataque era TCP, seguido por el UDP y el ICMP.
El 38 % de los ataques uniformemente distribuidos y el 46 % de todos
los ataques tenán una tasa de 500 paquetes por segundo o superior.
ı
´ ´
El mas rapido era de 679.000 paquetes por segundo.
El 50 % de los ataques duran menos de 10 minutos, 80 % menos de
30 minutos y el 90 % menos de una hora. El 2 % de los ataques duran
´ ´
mas de 5 horas, el 1 % mas de 10 horas, con una docena que persisten
durante varios dás.
ı
Un 27.5 % tienen un TLD desconocido, seguido del 15 % para .net, .com
y .ro. Brasil acumula el 5 %, los dominios .org un 4 % y los .edu un 2.5 %.
´
Al 65 % de las vćtimas se las ataco una sola vez y al 18 % dos veces.
ı
´
Al 95 % se las ataco menos de 5 o menos veces. A 5 vćtimas se las
ı
´
ataco entre 60 y 70 veces y a otra, 102 veces en una semana.

28

´
Deteccion: monitorizar IP origen

La regla general es que segun nos alejamos de la vćtima, los ataques se
´ ı
´
hacen mas difćiles de detectar.
ı

Durante un ataque, la mayorá de las IPs son nuevas para la vćtima, pero
ı ı
en un flash crowd, la mayorá de las IPs ya eran conocidas de antemano.
ı

´
Es mas fiable para detectar DoS por flood, que monitorizar el aumento del
´
volumen de trafico.

29

´
Deteccion: algoritmo CUSUM

´ ´ ´ ´
Algoritmo en su version no-parametrica asintoticamente optimo para de-
tectar cambios en el valor medio de un proceso estad´stico, mirando la
ı
´
distribucion de probabilidad de la secuencia aleatoria, todo en tiempo real.

Para la secuencia aleatoria {Xn}, en la que ocurre un cambio del valor
medio en m de α a α + h, CUSUM (Cumulative Sum) detecta cambios de
al menos h, es decir, h es el incremento m´nimo del valor, y estima m de
ı
manera secuencial, reduciendo la tasa de falsos positivos. Def´nase {Xn}
ı
como
Xn = α + ξnI (n < m) + (h + ηn) I (n ≥ m) , (1)
donde las secuencias aleatoria

ξ = {ξn}∞ ,
n=1 η = {ηn}∞ ,
n=1

cumplen que E (ξn) = E (ηn) ≡ 0, h = 0.

30

´
Una de las condiciones para el CUSUM no parametrico es que el valor
medio de {Xn}debe ser negativo en condiciones normales, positivo cuando
´
ocurren cambios, por lo que lo transformaremos sin perdida de generalidad
en otra secuencia aletoria {Zn} tal que

Zn = Xn − β, a = α − β,

para una β constante. Cuando hay un ataque, {Zn} crecera positivamente
´
´
rapidamente.

Buscamos cambios bruscos en el cambio de la secuencia aleatoria {Zn},
tales que, con las condiciones de 1,

Zn = a + ξnI (n < m) + (h + ηn) I (n ≥ m) , (a < 0) , (−a < h < 1)

31

El algoritmo será calcular los valores positivos acumulados de Zn, es decir,
ı

k
yn = Sn − mń Sk ,
ı Sk = ∑ Zi ,
1≤k≤n
i=1

con S0 = 0 al principio de los calculos. La version recursiva será calcular
´ ´ ı

yn = (yn−1 + Zn)+ ,
y0 = 0.

La funcion de decision asociada para detectar el ataque en un momento n
´ ´
será
ı
0 si yn ≤ N
dN (yn) =
1 si yn > N
con N el valor l´mite para la deteccion del ataque.
ı ´

32

Backtracking al atacante
´
El metodo tradicional consiste en seguir el flujo de router a router hasta
llegar al origen.

Problemas:

´ ´
Un ISP solo tiene acceso a reducida porcion de los routers de Internet,
incluso menor que un AS.

Es un proceso muy lento, que requiere de personal cualificado y de routers
con opciones especiales disponibles.

´
El ataque debe continuar mientras se esta traceando al atacante: aunque
´
la mayorá no suelen durar mas de 10 minutos.
ı

´
La difusion, si se utilizan reflectores, y la variedad, en el caso de usar
varios ataques al mismo tiempo, dificultan la tarea.

33

Backtracking: DoSTracker

´
En 1996, primer intento de automatizar la localizacion de los or´genes de
ı
los paquetes.

Conjunto de scripts Perl para routers Cisco desarrollados por MCI.

Colocaba ACLs en modo debug en cada router para recoger aquellos pa-
quetes dirigidos a la vćtima.
ı

ı ´
Abrá una conexion al router de donde procedán, reiniciando el proceso
ı
de ACL/debug.

Problemas:

Necesita de las claves de acceso a todos los routers.
´ ´
Solo funcionará con routers Cisco, no es generico.
ı

34

Backtracking: CenterTrack

Propuesto por Robert Stone[Stone2000].

Usa una red virtual de tuneles IP sobre la red normal para selectivamente
´
rerutar los paquetes sospechosos desde los routers arista de la red a
routers especialmente dedicados a la tarea.

El sistema puede detectar el punto de acceso de los paquetes prob-
´ ´
lematicos en los routers arista de la red facilmente.

´
Metodo muy elaborado: la red puede dejar de funcionar si no se hace cor-
´ ´
rectamente, ademas de que hay que tener en cuenta parametros como el
tiempo en el que tardan en extenderse la nuevas rutas, el paso de estados
de las conexiones de router a router, etc...

35

Backtracking: PPM

PPM (Probabilistic Packet Marking)
[Song2001, SavageEtAl2000, ParkLee2001, DeanAl2001, SnoerenEtAl2001]

Se marca aleatoriamente, vg: en el IP ID mediante hashing[Song2001],
un reducido conjunto de paquetes con un identiﬁcador de arista, bajo la
´
hipotesis de tener gran numero de paquetes en un ataque DDoS: con suﬁ-
´
´
cientes paquetes, se podra reconstruir el camino seguido por los paquetes
del ataque.

Concretamente, cuando un router decida marcar un paquete, escribe su
IP en el campo arista y 0 en el campo distancia: cuando no lo marca y el
campo distancia ya es 0, escribe su IP conjunto a la ya disponible en el
campo arista y luego incrementa el campo distancia en 1. Finalmente, si
no marca el paquete, incrementa el campo distancia en 1 siempre.

36

´
Un paquete marcado por un router tendra un campo distancia menor que
la longitud del camino que pasa por ese router.

´
Requiere de la modificacion de los routers: Cisco ya lo implementa.

Limitacion del PPM: con d routers entre atacante y vćtima y p siendo la
´ ı
probabilidad de marcar un paquete, la probabilidad de paquetes enviados
´
por un atacante a la vćtima que esten sin marcar es:
ı

P (paquete sin marcar recibido por la vćtima) = (1 − p)d
ı

´ ´
En ataques altamente distribuidos, es decir, con mucha difusion, el trafico
´ ´
de ataque desde una misma direccion IP no tiene porque ser mayor que el
´
trafico de conexiones normales.

´
Los zombies del atacante podrán crear paquetes marcados erroneos, de-
ı
jando inutil todo el esquema. En [Song2001] se ofrece un esquema para
´
autenticarlos, pero consume demasiada CPU.

37

Backtracking: ICMP traceback

Proyecto del IETF[BellovinIETF, WuEtAl2001].

Los routers inyectan un ICMP traceback de un paquete cada cierto numero
´
´ ´
de paquetes, y lo env´a al destino del paquete. Contendra informacion au-
ı
´ ´
tenticada sobre el paquete, como de donde vino, pudiendose reconstruir
´
el camino de los paquetes despues de un elevado numero de paquetes
´
recibidos.

38

Backtracking: DECIDUOUS

Basado en IPSEC, concretamente en los asociaciones de seguridad pro-
tegidas con AH (Authentication Headers).

Iterativamente se construyen asociaciones de seguridad con los routers a
distancias incrementales desde la v´ctima, permitiendo un traceroute se-
ı
´
guro hasta el router mas cercano del zombie o reﬂector atacante.

Provoca una gran sobrecarga de las CPUs.

39

Backtracking: Active Networks

´ ´
En los routers de una Active Network , no solo circulan datos, sino tambien
´ ˜
programas para los propios routers, que ejecutaran para anadir
funcionalidad o modificar el comportamiento de los routers. En
[Van1997, Halbig1999] se utilizan para trazar el origen de los ataques.

´ ı ´
Cuando una vćtima sospecha que esta siendo atacada, mandará codigo a
ı
los routers adyacentes para buscar el flujo del ataque: una vez encontrado,
ı ı ´
el router que lo reenvá mandará codigo a sus routers adyacente, as´ hasta
ı
´
llegar al punto de origen en la red activa, bloqueando el trafico del ataque si
se considera necesario.

40

´
Prevencion

Filtrado Ingress: ﬁltrado de paquetes en el ISP con direcciones fuentes
ı ´ ´
ileg´timas, segun la conexion de ingreso por la que los paquetes entran en la
red.

Filtrado Egress: ﬁltrado de paquetes en el ISP en el punto de salida del
´
dominio del cliente, mirando si el router busca la direccion de origen de los
paquetes que pertenecen al dominio del cliente.

41

´
Contencion: Pushback

´
Mismo objetivo que en las propuestas de redes activas: filtrar la direccion
por todos los routers desde la vćtima hasta el reflector/zombie. Descrito
ı
en [IB2001, ImplPush].

´ ´
Antes hay que detectar y trazar el ataque, para identificar cual y por donde
´
viaja el trafico del ataque.

42

´ ´
Comparacion entre metodos

43

´
Mas comparaciones[HabibEtAlb]

Consideraremos una red R con A routers arista y C routers centrales. En
cada router A hay F ﬂujos o conexiones por termino medio: a cada F se le
´
asocia una media P de paquetes y un porcentaje γ de conexiones que
causan DoS.

Examinaremos el aumento/sobrecarga en las necesidades de proceso,
Sproceso, y el aumento/sobrecarga en las necesidades de comunicacion,
´
Scomunicaci´ n, con λ1 unidades de proceso para el ﬁltrado, λ2unidades de
o
proceso para marcado y λ3unidades de proceso para monitorizacion.´

Filtrado Ingress,

Sproceso Ingress = A × F × P × λ1

´
y sin necesidad de comunicacion.

44

Filtrado basado en rutas, no requiere que en todos los dominios se instalen
ﬁltros,
Sproceso = 0,2 × SIngress
segun [ParkLee2001c].
´

PPM (Probabilistic Packet Marking)

Sproceso = A × F × P × p × h × λ1

con p la probabilidad de marcar un paquete y h el numero de saltos en
´
cada dominio.

´
Monitorizacion por router central,

F ×γ×d
Scomunicaci´ n = (2A + C ) × m´ x 1,
o a × tama˜ o paquete,
n
tama˜ o paquete
n
F ×γ×d
Sproceso = (2A + C ) × m´ x 1,
a × h × λ3
tama˜ o paquete
n

45

con d siendo el numero de bytes necesarios para almacenar la informacion
´ ´
rechazados y h el numero de saltos en cada dominio.
´

´
Monitorizacion por stripes,

Scomunicaci´ n = s × (A − 1) × (A − 2) × fs × (tama˜ o paquete)
o n
Sproceso = s × (A − 1) × (A − 2) × × fs × h × λ3

con fs siendo la frecuencia a la que se mandan stripes por unidad de
tiempo y h el numero de saltos en cada dominio.
´

´
Monitorizacion distribuida, en la que cada router A prueba a sus A dere-
cho y izquierdo adyacentes,

Scomunicaci´ n = 2 × A × fd × (tama˜ o paquete)
o n
Sproceso = 2 × A × fd × h × λ2

46

con fd siendo la frecuencia a la que mandan pruebas por unidad de tiempo
y h el numero de saltos en cada dominio.
´

PPM Ingress Filtrado Monito. Monito. Monito.

rutas central stripe distribuida

S volumen ataque numero
´ numero
´ no conex- routers, routers,

depende paquetes paquetes iones topologá,
ı topologá,
ı

entrada entrada violando ´
trafico ´
trafico

SLA ataque ataque

S imple- todos los routers A con routers de en A y C A A

´
mentacion Ingress dominios

selectivos

47

Sincroni. - - - {A , C } {A } {A }

reloj

Respuesta reactivo proactivo proactivo reactivo reactivo reactivo

´
Deteccion no no no s´
ı s´
ı s´
ı

´
violacion

SLA

Detecta cualquier IP IP IP cualquier cualquier cualquier

ataques spoofeadas spoofeadas IP IP IP

usando de otros de otros

dominios dominios

48

´
Configuracion routers CISCO

´ ´
No toda la configuracion funcionara en routers de gama baja; prtopeferi-
´
blemente solo para aquellos a partir de 7000.

´
Se debe prestar especial atencion a TCP Intercept:

Gran consumo de recursos.
´ ´
No funcionara en redes que no tengan un flujo de datos simetrico, vg:
ISPs con multiples proveedores y routers primarios.
´
´
El firewall debera responder con RST a servicios denegados y no se
´
deberan usar la rutas a null0.

L´mite en el ancho de banda para ciertos protocolos.
ı

El siguiente ejemplo se puede encontrar en una gran cantidad de ISPs:
˜ı ´ ´
una gran companá telefonica provee de conexion al ISP (A.A.A.1/24),

49

´
que va al puerto de entrada del router del ISP (X.X.X.254/24); este router
tiene una salida (Y.Y.Y.254/24) hasta la entrada de un firewall (Z.Z.Z.1).
La salida del firewall (F.F.F.1/24) estará en el mismo rango que los orde-
ı
´
nadores de la Intranet (I.I.I.0/24). Ademas, en el ISP hay una variedad de
ordenadores disponibles para las siguientes funcionalidades del router: un
servidor FTP para almacenar coredumps de la IOS (I.I.I.2), un servidor
NTP para sincronizar el tiempo de los logs (I.I.I.3), un servidor TACACS
(I.I.I.4), un servidor para almacenar logs del router (I.I.I.5) y un servidor
´ ´
para NetFlow, para visualizar informacion util durante el ataque (I.I.I.6).

Combinando peticiones a NetFlow (sh ip cache flow | include <IP>)
junto con CEF (sh ip cef <interface>) en cada uno de los routers se po-
´
dra reconstruir manualmente el flujo de datos por la red hasta el ordenador
´
atacante, incluso si esta spoofeando los paquetes.

´ ´
Solo se podra realizar mientras dura el ataque.
Lo ideal es que se vaya activando NetFlow segun se vaya necesitando
´
en cada router, y no tenerlo activado siempre.

50

´
Otros metodos utilizan ACLs [CisACLs].

! A.A.A.1/24 - Conexi´n a Internet
o
! X.X.X.254/24 - Puerto de entrada del router
! Y.Y.Y.254/24 - Puerto de salida del router
! Z.Z.Z.1/24 - Puerto de entrada del firewall
! F.F.F.1/24 - Puerto de salida del firewall
! I.I.I.0/24 - Intranet
! I.I.I.2 - Servidor FTP para almacenar coredumps
! I.I.I.3 - Servidor NTP
! I.I.I.4 - Servidor TACACS
! I.I.I.5 - Servidor de logging
! I.I.I.6 - Servidor NetFlow
!
hostname antidos
!
service password-encryption
!
no service dhcp
no service pad

51

service tcp-keepalives-in
service tcp-keepalives-out
service nagle
service timestamps log datetime show-timezone localtime
service timestamps debug datetime show-timezone localtime
!
! SNMPKEY debe ser un clave complicada (vg:hash de alguna palabra)
!
snmp-server community SNMPCOMKEY RO 20
!
no ip http server
no ip source-route
no ip finger
no ip bootp server
no ip domain-lookup
no cdp run
!
banner motd %
Router protected against DoS attacks.
%
!

52

! S´lo se podr´ entrar desde el firewall
o a
access-list 500 remark VTY Access
access-list 500 permit tcp host Z.Z.Z.1 host 0.0.0.0
range 22 23 log-input
access-list 500 deny ip any any log-input
!
line con 0
exec-timeout 30 0
line vty 0 10
access-class 500 in
exec-timeout 30 0
transport input telnet ssh
line aux 0
exec-timeout 30 0
!
interface null0
no ip unreachables
!
interface loopback 0
ip address 10.10.10.10 255.255.255.255
no ip proxy-arp

53

no ip redirects
no ip unreachables
! IPs comunmente spoofeadas
access-list 1 remark Spoofed
access-list 1 deny ip 0.0.0.0 0.255.255.255 any log-input

54


55


56


57

access-list 1 deny icmp any any fragments log-input
access-list 1 permit ip any I.I.I.0 0.0.0.255
access-list 1 permit ip any 224.0.0.0 15.255.255.255

58

!
access-list 2 remark Multicast
access-list 2 deny 224.0.0.0 0.0.0.255 log
access-list 2 deny 239.0.0.0 0.255.255.255 log
access-list 2 deny host 224.0.1.2 log
access-list 2 permit 224.0.0.0 15.255.255.255 log
!
access-list 10 remark CAR Multicast
access-list 10 permit ip any 224.0.0.0 15.255.255.255
access-list 20 remark CAR UDP
access-list 20 permit udp any any
access-list 30 remark CAR ICMP
access-list 30 permit icmp any any
!
interface Ethernet2/0
ip address X.X.X.254 255.255.255.0

59

ip access-group 1 in
no ip proxy-arp
no ip redirects
no ip unreachables
no ip mask-reply
no ip directed-broadcast
ip accounting access-violations
ip route-cache flow
! Utilizar s´lo si el path es sim´trico
o e
ip verify unicast reverse-path
! Limita el tr´fico multicast a 50 kbytes/s
a
rate-limit input access-group 10 400000 25000 25000
conform-action transmit exceed-action drop
! Limita el tr´fico UDP a 100 kbytes/s
a
! Limita el tr´fico ICMP a 50 kbytes/s
a
! Multicast seguro
ip multicast boundary 2

60

!
! A˜adir todas las redes adicionales tras I.I.I.0
n
!
access-list 40 remark antispoofing ACL
access-list 40 permit ip I.I.I.0 0.0.0.255 any
!
interface Ethernet2/1
ip address Y.Y.Y.254 255.255.255.0
ip access-group 40 in
no ip proxy-arp
no ip redirects
no ip unreachables
no ip mask-reply
no ip directed-broadcast
ip accounting access-violations
ip route-cache flow
! Utilizar s´lo si el path es sim´trico
o e
ip verify unicast reverse-path
! Multicast seguro
ip multicast boundary 2

61

!
boot system flash slot0:slot0:c7200-is-mz.121-5.T4.bin
logging buffered 16384 debugging
no logging console
! Cambiar CLAVE
enable secret CLAVE
no enable password
! Cambiar USUARIOFTP, CLAVEFTP
ip ftp username USUARIOFTP
ip ftp password CLAVEFTP
exception core-file antidos-CORE
exception protocol ftp
exception dump I.I.I.2
! Cambiar NTPKEY
ntp authentication-key 6767 md5 NTPKEY
ntp authenticate
ntp update-calendar
ntp server I.I.I.3
! Cambiar TACACSKEY
aaa new-model
aaa authentication login default group tacacs+ local-case

62

aaa authentication enable default group tacacs+ enable
aaa authorization commands 15 default group tacacs+ local
aaa accounting exec default stop-only group tacacs+
aaa accounting commands 15 default stop-only group tacacs+
aaa accounting network default stop-only group tacacs+
tacacs-server host I.I.I.4
tacacs-server key TACACSKEY
! Cambiar TACACSUSERNAME y TACACSPASSWORD
username TACACSUSERNAME password TACACSPASSWORD
!
logging trap debugging
logging facility local5
logging source-interface loopback
logging I.I.I.5
!
ip flow-export source loopback
ip flow-export destination I.I.I.6 2055
ip flow-export version 5 origin-as
!
! Protecci´n de la Intranet
o
access-list 50 remark TCP Intercept

63

access-list 50 permit tcp any I.I.I.0 0.0.0.255
!
ip tcp intercept list 50
ip tcp intercept connection-timeout 120
! Half-open de 10 segundos
ip tcp intercept watch-timeout 10
ip tcp intercept one-minute low 1000
ip tcp intercept one-minute high 5000
! Cisco Express Forwarding
ip cef
!
ip classless
!
! Ruta por defecto a Internet
ip route 0.0.0.0 0.0.0.0 A.A.A.1
ip route I.I.I.0 255.255.255.0 Z.Z.Z.1
! Blackhole
ip route 1.0.0.0 255.0.0.0 null0
ip route 2.0.0.0 255.0.0.0 null0
ip route 5.0.0.0 255.0.0.0 null0
ip route 7.0.0.0 255.0.0.0 null0

64

ip route 10.0.0.0 255.0.0.0 null0
ip route 23.0.0.0 255.0.0.0 null0
ip route 27.0.0.0 255.0.0.0 null0
ip route 31.0.0.0 255.0.0.0 null0
ip route 36.0.0.0 255.0.0.0 null0
ip route 37.0.0.0 255.0.0.0 null0
ip route 39.0.0.0 255.0.0.0 null0
ip route 41.0.0.0 255.0.0.0 null0
ip route 42.0.0.0 255.0.0.0 null0
ip route 49.0.0.0 255.0.0.0 null0
ip route 50.0.0.0 255.0.0.0 null0
ip route 58.0.0.0 255.0.0.0 null0
ip route 59.0.0.0 255.0.0.0 null0
ip route 70.0.0.0 255.0.0.0 null0
ip route 71.0.0.0 255.0.0.0 null0
ip route 72.0.0.0 255.0.0.0 null0
ip route 73.0.0.0 255.0.0.0 null0
ip route 74.0.0.0 255.0.0.0 null0
ip route 75.0.0.0 255.0.0.0 null0
ip route 76.0.0.0 255.0.0.0 null0
ip route 77.0.0.0 255.0.0.0 null0

65

ip route 78.0.0.0 255.0.0.0 null0
ip route 79.0.0.0 255.0.0.0 null0
ip route 83.0.0.0 255.0.0.0 null0
ip route 84.0.0.0 255.0.0.0 null0
ip route 85.0.0.0 255.0.0.0 null0
ip route 86.0.0.0 255.0.0.0 null0
ip route 87.0.0.0 255.0.0.0 null0
ip route 88.0.0.0 255.0.0.0 null0
ip route 89.0.0.0 255.0.0.0 null0
ip route 90.0.0.0 255.0.0.0 null0
ip route 91.0.0.0 255.0.0.0 null0
ip route 92.0.0.0 255.0.0.0 null0
ip route 93.0.0.0 255.0.0.0 null0
ip route 94.0.0.0 255.0.0.0 null0
ip route 95.0.0.0 255.0.0.0 null0
ip route 96.0.0.0 255.0.0.0 null0
ip route 97.0.0.0 255.0.0.0 null0
ip route 98.0.0.0 255.0.0.0 null0
ip route 99.0.0.0 255.0.0.0 null0
ip route 100.0.0.0 255.0.0.0 null0
ip route 101.0.0.0 255.0.0.0 null0

66

ip route 102.0.0.0 255.0.0.0 null0
ip route 103.0.0.0 255.0.0.0 null0
ip route 104.0.0.0 255.0.0.0 null0
ip route 105.0.0.0 255.0.0.0 null0
ip route 106.0.0.0 255.0.0.0 null0
ip route 107.0.0.0 255.0.0.0 null0
ip route 108.0.0.0 255.0.0.0 null0
ip route 109.0.0.0 255.0.0.0 null0
ip route 110.0.0.0 255.0.0.0 null0
ip route 111.0.0.0 255.0.0.0 null0
ip route 112.0.0.0 255.0.0.0 null0
ip route 113.0.0.0 255.0.0.0 null0
ip route 114.0.0.0 255.0.0.0 null0
ip route 115.0.0.0 255.0.0.0 null0
ip route 116.0.0.0 255.0.0.0 null0
ip route 117.0.0.0 255.0.0.0 null0
ip route 118.0.0.0 255.0.0.0 null0
ip route 119.0.0.0 255.0.0.0 null0
ip route 120.0.0.0 255.0.0.0 null0
ip route 121.0.0.0 255.0.0.0 null0
ip route 122.0.0.0 255.0.0.0 null0

67

ip route 123.0.0.0 255.0.0.0 null0
ip route 124.0.0.0 255.0.0.0 null0
ip route 125.0.0.0 255.0.0.0 null0
ip route 126.0.0.0 255.0.0.0 null0
ip route 127.0.0.0 255.0.0.0 null0
ip route 169.254.0.0 255.255.0.0 null0
ip route 172.16.0.0 255.240.0.0 null0
ip route 173.0.0.0 255.0.0.0 null0
ip route 174.0.0.0 255.0.0.0 null0
ip route 175.0.0.0 255.0.0.0 null0
ip route 176.0.0.0 255.0.0.0 null0
ip route 177.0.0.0 255.0.0.0 null0
ip route 178.0.0.0 255.0.0.0 null0
ip route 179.0.0.0 255.0.0.0 null0
ip route 180.0.0.0 255.0.0.0 null0
ip route 181.0.0.0 255.0.0.0 null0
ip route 182.0.0.0 255.0.0.0 null0
ip route 183.0.0.0 255.0.0.0 null0
ip route 184.0.0.0 255.0.0.0 null0
ip route 185.0.0.0 255.0.0.0 null0
ip route 186.0.0.0 255.0.0.0 null0

68

ip route 187.0.0.0 255.0.0.0 null0
ip route 189.0.0.0 255.0.0.0 null0
ip route 190.0.0.0 255.0.0.0 null0
ip route 192.0.2.0 255.255.255.0 null0
ip route 192.168.0.0 255.255.0.0 null0
ip route 197.0.0.0 255.0.0.0 null0
ip route 223.0.0.0 255.0.0.0 null0

69

CISCO: IP Source Tracker

Alternativa en routers de gama alta (12000 y 7500) para sustituir el tracea-
´
do del atacante usando ACLs por algo mas efectivo. Para ello, escribimos
“ip source-track <ip>”, con la IP del host que esta siendo atacado:
´

´
Se crearan entradas CEF en cada tarjeta y/o adaptador de puerto.
´ ´
Se obtendran estad´sticas del trafico de red a la IP, que se exportaran
ı ´
´
al router y se podran consultar con “show ip source-track”.
´ ´
Con las estad´sticas, el administrador determinara cual es el siguiente
ı
´ ´
router en el que tendra que repetir estos pasos; entonces, se parara la
´ ´
funcion con el comando “no ip source-track”, y entrara en el router para
repetir el proceso.

´
La funcionalidad podrá generar demasiado trafico y colapsar los routers.
ı

70

Futuro

´ ´ ´
De la simulacion teorica[BreslauEtAl2000] a la simulacion en entornos
reales, o de NS2[NS2] a Planet Lab[PlanetLab]

´
Modulos de kernel en routers Cisco, en las versiones futuras del IOS, para
´
el desarrollo rapido de contramedidas.

´
Los ataques comenzaran a coordinarse entre s´, para mejorar su distribu-
ı
´
cion.

´ ´ ´ ´
La introduccion de IPv6 hara que la distribucion automatico de gusanos y
´ ´
codigo malicioso sea practicamente imposible.

´
Se eliminaran los Single-Points of Failure: DNS basados en frame-
works para estructuras de datos distribuidas resistentes a fallos como

71

OceanStore[KubiatowiczEtAl2000] y otros: Plaxton[Plaxton1997] y el sis-
tema operativo Scout[Spatscheck1999].

Referencias
[BellovinIETF] S. Bellovin. The ICMP traceback message.
Internet Draft, IETF, Marzo 2000

[DeanAl2001] Drew Dean, Matt Franklin, Adam Stubble-
ﬁeld. An algebraic approach to IP trace-
back. Proceedings of Network and Dis-
tributed Systems Security Symposium, San
Diego, CA, Febrero 2001

[SavageEtAl2000] Stefan Savage, David Wetherall, Anna Kar-
lin, y Tom yerson. Practical network sup-

72

port for IP traceback. Proceedings of the
ACM SIGCOMM Conference, pages 295-
305, Stockholm, Sweeden, August 2000.
ACM.

[SnoerenEtAl2001] Akec C. Snoeren, Craig Partridge, Luis
A. Sanchez, Christine E. Jones, Fabrice
Tchakountio, Stephen T. Kent, y W. Timo-
thy Strayer. Hash-based IP traceback. Pro-
ceedings of the ACM SIGCOMM, paginas´
3-14, San Diego CA, Agosto 2001, ACM.

[Song2001] Dawn X. Song y Adrian Perrig. Advanced
and authenticated marking schemes for IP
traceback. Proceedings IEEE Infocomm,
Anchorage, Alaska, April 2001.

[WuEtAl2001] S. F. Wu, L. Zhang, D. Massey, y A. Mankin.

73

Intention-driven ICMP traceback, Internet-
Draft: draft-wu-itrace-intention-00.txt,
Febrero 2001.

[DittrichURL] David Dittrich. Distritibuted Denial
of Service (DDos) attacks tools
http://staff.washington.edu/dittrich/misc/ddos

[PacketStorm] PacketStormSecurity, De-
nial of Service Attack Tools.
http://www.packetstormsecurity.org

[GilPolet2001] Thomer M. Gil y Massimiliano Poletto. MUL-
TOPS: A Data-Structure for bywith attack
detection. Proceedings of the USENIX Se-
curity Symposium, 23-28, Washington, DC,
USA, Julio 2001. USENIX

74

[CERT2001] Trends in denial of service technology.
CERT Coordination Center at Carnegie-
Mellon University, Octubre 2001.

[CERT2000] CERT Advisory CA-2000.01. Denial
of Service development, Enero 2000.
http://www.cert.org/advisories/CA-2000-
01.html

[CERT2000a] CERT Advisory CA-96.21. TCP SYN
ﬂooding and IP spooﬁng. Noviembre 2000.
21.html

[CERT1998] CERT Advisory CA-98.01. Smurf IP
Denial-Of-Service attacks, Enero 1998.
01.html

75

[CERT1997] CERT Advisory CA-1997-27. FTP-Bounce.
27.html, Diciembre 1997.

[IB2001] John Ioannidis, y Steven M. Bellovin. Push-
back: router-based defense against DDoS
attacks. AT&T Labs Research, Febrero
2001.

[ImplPush] J. Ioannidis y S.M. Bellovin. Implement-
ing pushback: Router-based defense againt
DDoS attacks. Proceedings of Network and
Distributed System Security Symposium,
San Diego, CA, Febrero 2002. The Internet
Society.

[RiceDavis] Greg Rice y James Davis. A Genealogical
Approach to Analyzing Post-Mortem Denial

76

of Service Attacks. Department of Electrical
and Computer Engineering, Iowa State Uni-
versity. VER

[HussainEtAL] Aleﬁya Hussain, John Heidemann, y Chris-
tos Papadopoulos. A Framework for Clas-
sifying Denial of Service Attacks. ISI-TR-
2003-569.

[ReiherEtAl2002] Peter Reiher, Jelena Mirkovic, Greg Prier.
Attacking DDoS at the source. Proceed-
ings of the IEEE International Conference
on Network Protocols 10, Paris, France,
November 2002.

[CAIDA] CAIDA website http://www.caida.org

[MooreEtAl2001] David Moore, Geoffrey Voelker, y Stefan
Savage. Inferring Internet Denial of Service

77

activity. Proceedings of the USENIX Securi-
ty Sumposium, Washington, DC, USA, Au-
gust 2001. USENIX.

[PapadoEtAl] Christos Papadopoulos, Robert Lindell,
John Mehringer, Alefiya Hussain, y Ramesh
Govindan. COSSACK: Coordinated Sup-
presion of Simultaneous Attacks. Proceed-
ings of Discex III.

[Paxson2001] Vern Paxson. An analysis of using reflec-
tors for distributed denial of service at-
tacks. ACM Computer Communications Re-
view (CCR), 31(3), Julio 2001.

[Stone2000] Robert Stone. CenterTrack: An IP overlay
network for tracking DoS floods. Proceed-
ings of the USENIX Security Symposium,

78

pages 199-212, Denver, CO, USA, Julio
2000. USENIX.

[CiscoNetflow] Cisco Systems. Netflow
services and applications.
http://www.cisco.com/warp/public/732/netflow

[CiscoRMON] Cisco Systems. RMON.
http://www.cisco.com/warp/public/614/4.html

[CiscoCAR] Cisco Systems. Committed Access Rate.
Cisco CAR

[CiscoIntercept] Cisco Systems. Configuring TCP Intercept
(Prevent Denial-Of-Service Attacks). Cisco
IOS Documentation, Diciembre 1997.

79

[CiscoURPF] Cisco Systems. Unicast Reverse Path For-
warding. Cisco IOS Documentation, Mayo
1999.

[WangEtAl2002] Haining Wang, Damlu Zhang, y Kang Shin.
Detecting SYN ﬂooding attacks. Proceed-
´
ings of the IEEE Infocom, paginas 0-1, New
York, NY, Junio 2002. IEEE.

[WangEtAl] Haining Wang, Danlu Zhang, y Kang G.
Shin. SYN-DOG: Snifﬁng SYN Flooding
Sources. Real-Time Computing Laborato-
ry, Department of Electrical Engineering y
Computer Science, The University of Michi-
gan, Ann Arbor, MI 48109-2122.

[JinEtAl] Cheng Jin, Haining Wang, Kang G. Shin.
Hop-Count Filtering: An Effective Defense

80

Against Spoofed Traffic.

[Dietrich2000] S. Dietrich, N. Long, y D. Dittrich. Analyz-
ing distributed denial of service tools: the
shaft case. Proceedings of the USENIX
LISA’2000, New Orleans, LA, Diciembre
2000.

[RFC2267] P. Ferguson y D. Senie. Network ingress fil-
tering: defeating denial of service attacks
which employ IP source address spoofing.
RFC 2267 , Enero 1998.

[RFC2827] P. Ferguson y D. Senie. Network Ingress Fil-
tering: Defeating Denial of Service Attacks
which employ IP Source Address Spoofing.
RFC 2827, Mayo 2000.

81

[RFCDraft] S. Floyd, S. Bellovin, J. Ionnidis, K. Kompel-
la, R. Mahajan, y V. Paxson. Pushback mes-
sages for Controlling Aggregates in the Net-
work. Internet Draft, WIP.

[MahajanEtAl] R. Mahajan, S. M. Bellovin, S. Floyd,
J. Ioaniidis, V. Paxson, y S. Shenker.
Controlling High Bandwith Aggregates
in the Network - Extended Version.
http://www.aciri.org/pushback

[Poletto2001] M. Poletto. Practical approaches to deal-
ing with DDoS attacks. NANOG 22 Agen-
da, Mayo 2001. http://www.nanog.org/mtg-
0105/poletto.html

[Spatscheck1999] O. Spatscheck y L. Peterson. Defending
against denial of service attacks in Scout.

82

Proceedings of USENIX OSDI’99, New Or-
leans, LA, Febrero 1999.

[Burch2000] H. Burch y B. Cheswick. Tracing Anony-
mous Packets to Their Approximate Source.
Usenix LISA, Diciembre 2000.

[Van1997] V. C. Van. A Defense Against Address
Spooﬁng Using Active Networks. Bachelor’s
Thesis, MIT, 1997.

[CSIFBI2000] Computer Security Institute and Federal Bu-
reau of Investigation. 2000 CSI/FBI Com-
puter Crime y Security Survey. Computer
Security Institute publication, Marzo 2000.

[Gilgor1983] Virgil Gilgor. A Note on the Denial-of-
Service Problem. Proceedings of the 1983

83

IEEE Symposium on Security y Privacy ,
Oakly, CA, 1983.

[Howard1998] John D. Howard. An Analysis of Security
Incidents on the Internet. PhD thesis, Car-
nagie Mellon University, Agosto 1998.

[Anderson2001] D. yerson, H. Balakrishan, F. Kaashoek, y
R. Morris. Resilient overlay network. Pro-
ceedings of the 18th ACM Symposium on
Operating System Principles (SOSP), Banff
Canada, Octubre 2001.

[NS2] S. McCanne y S. Floyd. Network Simulator
NS-2. 1997 http://www.isi.edu/nsnam/ns

[PlanetLab] Planet Lab http://www.planet-lab.org

84

[DeLong2001] D. F. DeLong. “Hackers said to cost US. bil-
lions” E-Commerce Times Online, Febrero
8, 2001.

[Basseville] M. Basseville y I. V. Nikiforov, Detection of
Abrupt Changes: Theory and Application,
Prentice Hall, 1993

[BernsteinSchenk] D.J. Bernstein y Eric Schenk, “Linux
Kernel SYN Cookies Firewall Project”,
http://www.bronzesoft.org/projects/scfw

[Brodsky1993] B.E. Brodsky y B.S. Darkhovsky, Non-
parametric Methods in Change-point Prob-
lems, Kluwer Academic Publishers, 1993.

[SynDefender] CheckPoint Software Tech-
nologies Ltd. SynDefender:

85

http://www.checkpoint.com/products/ﬁrewall-
1

[Malan2001] G.R. Malan et al. Observations and Expe-
riences Tracking Denial-Of-Service Attacks
across a Large Regional ISP, Technical Re-
port, Arbor Networks, 2001.

[ParkLee2001] Kihong Park y Heejo Lee. On the Effective-
ness of Probabilistic Packet Marking for IP
Traceback under Denial of Service Attack.
Proceedings of the IEEE INFOCOM 2001,
Marzo 2001.

[KParkLee2001] Kihong Park y Heejo Lee. On the effec-
tiveness on router-based packet ﬁltering for
distributed DoS attack prevention in Power-
Law Internets. Proceedings of the 2001

86

ACM SIGCOMM Conference, San Diego,
California, USA, Agosto 2001.

[ParkLee2001c] Kihong Park y Heeko Lee. A proactive ap-
proach to distributed DoS attack prevention
using route-based packet ﬁltering. Proceed-
ings ACM SIGCOMM, San Diego, Califor-
nia, USA, Agosto 2001.

[PaxsonFloyd] V. Paxson y S. Floyd. Wide-Area Trafﬁc: the
failure of the Poisson Modeling. IEEE/ACM
Transactions on Networking, Vol. 3, No. 3,
Junio 1995.

[SchubEtAl1997] C.L. Schuba, I.V. Krsul, M. G. Kuhn, E.H.
Spafford, A. Sundaram y D. Zamboni. Anal-
ysis of a Denial of Service Attack on TCP,

87

Proceedings of IEEE Symposium on Secu-
rity and Privacy, Mayo 1997.

[BreslauEtAl2000] Lee Breslau, Deborah Estrin, Kevin Fall,
Sally Floyd, John Heidemann, Ahmed
Helmy, Polly Huang, Steven McCanne, Kan-
nan Varadhan, Ya Xu, y Haobo Yu. Ad-
vances in network simulation. IEEE Com-
puter, 33(5):59-67, May 2000.

[KubiatowiczEtAl2000] John Kubiatowicz et al. Oceanstore: an ar-
chitecture for global-scale persitent storage.
Proceedings of the Ninth International Con-
ference on Architectural Support for Pro-
gramming Languages and Operating Sys-
tems (ASPLOS 2000), Noviembre 2000.

[Plaxton1997] Greg Plaxton, Rajmohan Rajaraman, y An-

88

drea W. Richa. Accesing nearby copies of
replicated objets in a distributed environ-
ment. Proceedings of the 9th Annual SCP
Symposium on Parallel Algorithms and Ar-
chitectures, Junio 1997.

[Meadows2000] C. Meadows. A formal framework and eval-
uation method for network denial of service.
Proceedings of the IEEE Computer Security
Foundations Workshop, Junio 1999.

[Millen1995] J. Millen. DoS: a perspective. Dependable
Computing for Critical Applications 4, 1995.

[Millen1992] J. Millen. A resource allocation model for
DoS. Proceedings of the 1992 IEEE Sym-
posium on Security y Privacy, 1992.

89

[Hamilton1994] J. Hamilton. Time Series Analysis. Prince-
ton University Press, 1994.

[Granger1969] C.W.Granger. Investigating causal relations
by econometric models and cross-spectral
methods. Econometrica, 34:424-438, 1969.

[Yau2002] David K. Y. Yau, John C. S. Lui y Feng
Liang. Defending against distributed denial-
of-service attacks with max-min fair server-
centric router throttles. Proceedings of
IEEE International Workshop on Quality of
Service (IWQoS), Miami Beach, Florida,
Mayo 2002.

[Kumar1995] S. Kumar. Classiﬁcation and Detection of
Computer Intrusions, Ph.D. Thesis, Purdue
University.

90

[Richardson2001] T.W. Richardson. The development of a
Database Taxonomy of Vulnerabilities to
Support the Study of Denial of Service At-
tacks, Ph.D. Thesis. Iowa State University.

[MirkovicEtAl2001] J. Mirkovic, J. Martin, y P. Reiher. A Taxon-
omy of DDoS Attacks and DDoS Defense
Mechanisms. Los Angeles, California, Uni-
versity of California Computer Science De-
partment.

[TupakulaEtAl] Udaya Kiran Tupakula, VIjay Varadharajan.
A Practical Method to Counteract Denial of
Service Attacks. Information and Networked
System Security Research, Division of Infor-
mation and Communication Sciences, Mac-
quarie University, Sydney, Australia.

91

[Bellovin1989] S.M. Bellovin: Security Problems in the
TCP/IP Protocol Suite. ACM Computer
Communications Review, 19(2):32-48, Abril
1989.

[Bellovin2000] S. Bellovin. Security aspects of Napster and
Gnutella.

[Dunigan2001] Tom Dunigan. Backtracking Spoofed Pack-
ets. Computer Science and Mathematics
Division, Network Research Group, Oak
Ridge National Laboratory, Junio 2001.

[PengEtAl] Tao Peng, Christopher Leckie, y Kotoga-
ri Ramamohanarao, Defending Against Dis-
tributed Denial of Service Attacks Using Se-
lective Pushback, Department of Electrical
and Electronic Engineering and Department

92

of Computer Science and Software Engi-
neering, The University of Melbourne, Vic-
toria 3010, Australia.

[PengEtAlb] Tao Peng, Christopher Leckie, y Kotagiri Ro-
mamohanarao, Detecting Distributed Denial
of Service Attacks by Sharing Distributed
Beliefs, Department of Electrical and Elec-
tronic Engineering and Department of Com-
puter Science and Software Engineering,
The University of Melbourne, Victoria 3010,
Australia.

[PengEtAlC] Tao Peng, Christopher Leckie, y Kotagiri Ro-
mamohanarao, Detecting distributed denial
of service attacks using source IP address
monitoring, draft, Noviembre 2002.

93

[PengEtAld] Tao Peng, Chistropher Leckie y Kotagiri Ro-
mamohanarao, Protection from Distributed
Denial of Service Using History-based IP ﬁl-
tering, Department of Electrical and Elec-
tronic Engineering and Department of Com-
puter Science and Software Engineering,
The University of Melbourne, Victoria 3010,
Australia.

[HabibEtAl] Ahsan Habib, Sonia Fahmy, Srinivas R.
Avasarala, Venkatesh Prabhakar, Bharat
Bhargava, On Detecting Service Violations
and Bandwith Theft in QoS Network Do-
mains, CERIAS and Department of Com-
puter Sciences, Purdue University, West
Lafayette, IN 47907-1398, USA.

[HabibEtAlb] Ahsan Habib, Mohamed M. Fefeeda, y

94

Bharat K. Bhargava, Detecting Service Vi-
olations and DoS Attacks, CERIAS and
Department of Computer Sciences, Purdue
University, West Lafayette, IN 47907, USA.

[HuangPullen2001] Yih-Huang, y J. Mark Pullen. Countering
denial-of-service attacks using congestion
triggered packet sampling and ﬁltering. Pro-
ceedings of 10th International Conference
on Computer Communications and Net-
works, 2001.

[Oliver2001] Ross Oliver. Countering SYN ﬂood denial-
of-service attacks, 29 Agosto 2001 Oliver
USENIX

[JungEtAl2002] Jaeyon Jung, Balachander Krishnamurthy, y
Michael Rabinovich. Flash crowds and de-

95

nial of service attacks: characterization and
implications for CDNs and web sites. Pro-
ceedings of 11th World Wide Web confer-
ence, 2002, Mayo 7-11, 2002, Honolulu,
Hawai, USA.

[BargteilEtAl2000] Adam Bargteil, David Bindel, y Yan Chen.
Quantitative Characterization of Denial Ser-
vice: A Location Service Case Study, Di-
ciembre 15, 2000.

[CabreraEtAl2001] Joao B.D. Cabrera, Lundy Lewis, Xinzhou
Qin, Wenke Lee, Ravi K. Prasanth, Ravi
K. Prasanth, B. Ravichandran, y Raman K.
Mehra, Proactive Detection of Distributed
Denial of Service Attacks using MIB Trafﬁc
Variables - A Feasibility Study, Proceedings
of the 7th IFIP/IEEE International Sympo-

96

sium on Integrated Network Management,
Seattle, WA, Mayo 14-18, 2001.

[Sanns2000] Sanns, W. Catastrophe Theory with Math-
ematica: A Geometric Approach. Germany:
DAV, 2000.

[Okada1993] Kenchiki Okada, Catastrophe Theory and
Phase Transitions: Topological Aspects of
Phase Transitions and Critical Phenom-
ena, Hardcover, December 1993, ISBN
3908450012, Trans Tech Publications, Lim-
ited.

[Zeeman] E.C. Zeeman, Catastrophe Theory. Se-
lected Papers, 1972-1977. , Publisher:
Addison-Wesley, ISBN: 0201090147.

97

[Afrajmovich1999] V. S. Afrajmovich, Yu S. Il’yashenko, Yu.
S. Il’Yashenko, L. P. Shilnikov, Leonid
P. Shilnikov, Bifurcation Theory and
Catastrophe Theory , June 1999, ISBN:
3540653791, Publisher: Springer-Verlag
New York, Incorporated.

[Yaes1993] Sandra Hayes, Catastrophe Theory ,
Domenico Castrigiano, April 1993, ISBN:
0201555905, Publisher: Addison-Wesley.

[Okninski] A. Okninski, Catastrophe Theory, ISBN:
0444987428, Publisher: Elsevier Science.

[Gilmore] Robert Gilmore, Catastrophe Theo-
ry for Scientists and Engineers, ISBN:
0486675394, Publisher: Dover Publications,
Incorporated.

98

[PostonStewart] Tim Poston, Ian Stewart, Catastrophe
Theory and Its Applications, ISBN:
048669271X, Publisher: Dover Publica-
tions, Incorporated.

[ArnoldEtAl] Vladimir I. Arnol’d, G.S. Wassermann
(Translator), R. K. Thomas (Translator),
G. S. Wassermann (Translator), Catastro-
phe Theory, ISBN: 0387548114, Publisher:
Springer-Verlag New York, Incorporated.

[Saunders] P.T. Saunders, Introduction to Catastro-
phe Theory , ISBN: 052123042X, Publisher:
Cambridge University Press.

[HBStatistics] Handbook of Statistics, Series, de North-
Holland.

99

[HBGameTheory] Handbook of Game Theory with Econom-
ic Applications, Editors: Robert J. Aumann
and Sergiu Hart, Publisher: Elsevier Sci-
ence Publishers (North-Holland), Volume I,
II y III.

[HBEconometrics] Handbook of Econometrics Vols. 1-5,
North-Holland.

[KN1997] Eyal Kushilevitz, Noam Nisan, Commu-
nication Complexity , Cambridge University
Press, Enero 1997, ISBN: 0521560675.

[Hromkovic1997] Juraj Hromkovic, Communication Complex-
ity and Parallel Computing, Springer Verlag,
Enero 15, 1997, ISBN: 354057459X.

[BakerEtAl] Gregory L. Baker, Jerry P. Gollub, Chaotic

100

Dynamics: An Introduction, Cambridge Uni-
versity Press, ISBN: 0521476852.

[Wasserman1994] Stanley Wasserman, Katherine Faust,
Dawn Iacobucci, Social Network Analysis:
Methods and Applications, Cambridge
Univ Press, Noviembre 1994, ISBN:
0521387078.

[SCWA99] S. Savage, N. Cardwell, D. Wetherall, and T.
Anderson, TCP Congestion Control with a
Misbehaving Receiver, Computer Commu-
´
nication Review, 29(5), paginas 71-78, Oc-
tubre 1999.

[Sargor1999] Chandru Sargor, Decentralized Source
Identiﬁcation for Network-based intrusions,
1999. Deciduous

101

[Halbig1999] Gregory Halbig. An Active Network
approach to defending and track-
ing denial-of-service attacks. UoF
Master’s Thesis, 1999. http://www-
pub.cise.ufl.edu/ghalbig/proposal.html

[ASCORE] AS Core Network as a graph, CAIDA AS
Core Network

[CheswickBurch] Prototype two-dimensional image depicting
global connectivy among ISPs as viewed
from skitter host. figure1

[RltAS] Interconnection relationships among key
Autonomous System networks on 3 Decem-
ber, 1998. figure2

[ASpathlength] AS path lengths. ASPathLengths

102

[ASworld] ´
Comparacion AS en el mundo. CAIDA.
bgp2country CAIDA

[resilience] Internet topology resilience. CAIDA. re-
silience

[CisACLs] Cisco - Characterizing and Tracing Packet

Floods Using Cisco Routers. Characterizing

and Tracing Packet Floods

Prevención, detección y contención de ataques de denegación de servicio

Recommended

Recommended

More Related Content

What's hot

What's hot (8)

Viewers also liked

Viewers also liked (20)

Similar to Prevención, detección y contención de ataques de denegación de servicio

Similar to Prevención, detección y contención de ataques de denegación de servicio (20)

Recently uploaded

Recently uploaded (20)

Prevención, detección y contención de ataques de denegación de servicio