1
´ ´ ´
Prevencion, deteccion y contencion para
´
ataques de denegaci...
2
´
Introduccion
´
¿Que es realmente Internet?
Elementos c...
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 [Gilgor...
12
Estad´stica [Brodsky1993, HBStatistics]
ı
´
Teor´a...
13
Taxonom´a DoS [Kumar1995, Richardson2001, MirkovicEtAl2001]
ı
14
´
DDoS y los sistemas autonomos
15
´
Arboles de ataques (1)
16
´
Arboles de ataques (2)
17
´
Arboles de ataques (3)
18
´
Arboles de ataques (4)
19
L´nea temporal ataques DDoS
ı
20
Herramientas DDoS
Trinoo: simple ataque UDP distribuido.
Tribe Flood Network: incopora ICMP, UDP,...
21
L´nea temporal ataques DrDoS
ı
22
Reflectores en DrDoS
Dificultan tracear el ataque hasta el Master .
´ ´
Crean ...
23
Peticiones DNS recursivas: si se ataca a un servidor DNS, los zom-
bies del atacante pueden utilizar otros servi...
24
ataques smurf , ICMP echo spoofeados a direcciones broadcast.
´
Trafico que genere mensajes ICMP (source quench, ti...
25
Estad´stica de Ataques DoS
ı
´
Analisis BackScatter [MooreEtAl2001]. Presupuestos:
Tod...
26
rango monitorizado, R ,
232
R ≥R
...
27
Un total de 200 millones de paquetes en 3 semanas, provenientes
12805 ataques diferentes a 5000 direcciones IP v´cti...
28
´
Deteccion: monitorizar IP origen
La regla general es que segun nos alejamos de la v´ctima, los ...
29
´
Deteccion: algoritmo CUSUM
´ ´ ´ ´
...
30
´
Una de las condiciones para el CUSUM no parametrico es que el ...
31
El algoritmo ser´a calcular los valores positivos acumulados de Zn, es decir,
ı
...
32
Backtracking al atacante
´
El metodo tradicional consiste en seguir el flujo de router a router...
33
Backtracking: DoSTracker
´
En 1996, primer intento ...
34
Backtracking: CenterTrack
Propuesto por Robert Stone[Stone2000].
Usa una red virtual de tuneles IP sobr...
35
Backtracking: PPM
PPM (Probabilistic Packet Marking)
[Song2001, SavageEtAl2000, ParkLee2001, De...
36
´
Un paquete marcado por un router tendra un campo distancia menor que
la l...
37
Backtracking: ICMP traceback
Proyecto del IETF[BellovinIETF, WuEtAl2001].
Los routers inyectan un ICMP tr...
38
Backtracking: DECIDUOUS
Basado en IPSEC, concretamente en los asociaciones de seguridad pro-
tegidas con...
39
Backtracking: Active Networks
´ ´...
40
´
Prevencion
Filtrado Ingress: filtrado de paquetes...
41
´
Contencion: Pushback
...
42
´ ´
Comparacion entre metodos
43
´
Mas comparaciones[HabibEtAlb]
Consideraremos una red R con A routers arista y C route...
44
Filtrado basado en rutas, no requiere que en todos los dominios se instalen
filtros,
Sproceso...
45
con d siendo el numero de bytes necesarios para almacenar la informacion
´ ...
46
con fd siendo la frecuencia a la que mandan pruebas por unidad de tiempo
y h el numero de saltos en cada dom...
47
Sincroni. - - - {A , C } {A } {A }
reloj
Respuesta reactivo ...
48
´
Configuracion routers CISCO
´ ´
No toda la configuracio...
49
´
que va al puerto de entrada del router del ISP ...
50
´
Otros metodos utilizan ACLs [CisACLs].
! A.A.A.1/24 - Conexi´n a Internet
o
! X.X.X....
51
service tcp-keepalives-in
service tcp-keepalives-out
service nagle
service timestamps log datetime show-timezone loc...
52
! S´lo se podr´ entrar desde el firewall
o a
access-list 500 remark VTY Access
access-list 500 permit tc...
53
no ip redirects
no ip unreachables
! IPs comunmente spoofeadas
access-list 1 remark Spoofed
access-list 1 deny i...
54
access-list 1 deny ip 59.0.0.0 0.255.255.255 any log-input
access-list 1 deny ip 70.0.0.0 0....
55
access-list 1 deny ip 93.0.0.0 0.255.255.255 any log-input
access-list 1 deny ip 94.0.0.0 0.255.255....
56
access-list 1 deny ip 114.0.0.0 0.255.255.255 any log-input
access-list 1 deny ip 115.0.0.0 0.25...
57
access-list 1 deny ip 178.0.0.0 0.255.255.255 any log-input
access-list 1 deny ip 179.0.0.0 0.255.255.255 an...
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.2...
59
ip access-group 1 in
no ip proxy-arp
no ip redirects
no ip unreachables
no ip mask-reply
no ...
60
!
! A˜adir todas las redes adicionales tras I.I.I.0
n
!
access-list 40 remark antispoofing ACL
access-list 40 per...
61
!
boot system flash slot0:slot0:c7200-is-mz.121-5.T4.bin
logging buffered 16384 debugging
no logging console
! Cambi...
62
aaa authentication enable default group tacacs+ enable
aaa authorization commands 15 default group tacacs+ local
aaa...
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
!...
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....
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...
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...
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...
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...
69
CISCO: IP Source Tracker
Alternativa en routers de gama alta (12000 y 7500) para sustituir el tracea-
...
70
Futuro
´ ´ ´
De la simulacion teor...
71
OceanStore[KubiatowiczEtAl2000] y otros: Plaxton[Plaxton1997] y el sis-
tema operativo Scout[Spatscheck1999].
...
72
port for IP traceback. Proceedings of the
ACM SIGCOMM Conference, pages 295-...
73
Intention-driven ICMP traceback, Internet-
Draft: draft-wu-itrace-intention...
74
[CERT2001] Trends in denial of service technology.
CERT Coordination Center at Carnegie-
...
75
[CERT1997] CERT Advisory CA-1997-27. FTP-Bounce.
http://www.cert.org/advisories/CA-1997-
...
76
of Service Attacks. Department of Electrical
and Computer Engineering, Iowa St...
77
activity. Proceedings of the USENIX Securi-
ty Sumposium, Washington, DC, USA, Au-
...
78
pages 199-212, Denver, CO, USA, Julio
2000. USENIX.
[CiscoNetflow] Cisco...
79
[CiscoURPF] Cisco Systems. Unicast Reverse Path For-
warding. Cisco IOS Documentation, Mayo
...
80
Against Spoofed Traffic.
[Dietrich2000] S. Dietrich, N. Long, y D. Dittrich. Analyz-
...
81
[RFCDraft] S. Floyd, S. Bellovin, J. Ionnidis, K. Kompel-
la, R. Mahajan, y V. Paxson. Pu...
82
Proceedings of USENIX OSDI’99, New Or-
leans, LA, Febrero 1999.
[Burch2000] H. Bur...
83
IEEE Symposium on Security y Privacy ,
Oakly, CA, 1983.
[Howard1998] John D....
84
[DeLong2001] D. F. DeLong. “Hackers said to cost US. bil-
lions” E-Commerce Times Online,...
85
http://www.checkpoint.com/products/firewall-
1
[Malan2001] G.R. Malan et al. ...
86
ACM SIGCOMM Conference, San Diego,
California, USA, Agosto 2001.
[ParkLee2001c...
87
Proceedings of IEEE Symposium on Secu-
rity and Privacy, Mayo 1997.
...
88
drea W. Richa. Accesing nearby copies of
replicated objets in a distributed environ-...
89
[Hamilton1994] J. Hamilton. Time Series Analysis. Prince-
ton University Press, 1994.
[Granger19...
90
[Richardson2001] T.W. Richardson. The development of a
Database Taxonomy of Vulnerabilities...
91
[Bellovin1989] S.M. Bellovin: Security Problems in the
TCP/IP Protocol Suite. ACM Computer
...
92
of Computer Science and Software Engi-
neering, The University of Melbourne, Vic-
...
93
[PengEtAld] Tao Peng, Chistropher Leckie y Kotagiri Ro-
mamohanarao, Protection from Distributed
...
94
Bharat K. Bhargava, Detecting Service Vi-
olations and DoS Attacks, CERIAS a...
95
nial of service attacks: characterization and
implications for CDNs and we...
96
sium on Integrated Network Management,
Seattle, WA, Mayo 14-18, 2001.
[Sanns2000] Sa...
97
[Afrajmovich1999] V. S. Afrajmovich, Yu S. Il’yashenko, Yu.
S. Il’Yashenko, L. P. Shilnikov, L...
98
[PostonStewart] Tim Poston, Ian Stewart, Catastrophe
Theory and Its Applications, ISBN:
...
99
[HBGameTheory] Handbook of Game Theory with Econom-
ic Applications, Editors: Robert J. Auman...
100
Dynamics: An Introduction, Cambridge Uni-
versity Press, ISBN: 0521476852.
[Wa...
101
[Halbig1999] Gregory Halbig. An Active Network
approach to defending and track-
...
102
[ASworld] ´
Comparacion AS en el mundo. CAIDA.
bgp2country CAIDA
[res...
of 102

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

Introducción y estado del arte a la prevención, detección y contención de ataques de denegación de servicio
Published on: Mar 4, 2016
Published in: Technology      
Source: www.slideshare.net


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

  • 1. 1 ´ ´ ´ Prevencion, deteccion y contencion para ´ ataques de denegacion de servicio ´ DAVID C EREZO S A NCHEZ http://david.cerezo.name
  • 2. 2 ´ Introduccion ´ ¿Que es realmente Internet? Elementos constitutivos fundamentales: routers, ordenadores finales, conexiones ´ Analog´as con objetos del mundo real: la red distribucion de agua ı ´ Breve historia de la evolucion de Internet ´ Topolog´a de Internet, su representacion en forma de grafo y los sis- ı ´ temas autonomos (AS). El principio del m´nimo esfuerzo ı Problemas derivados del principio del m´nimo esfuerzo ı Los protocolos de Intenet y el modelo OSI ◦ Nivel subred: ARP, Ethernet ◦ Nivel Internet o red: IP ◦ Nivel de transporte: TCP, UDP
  • 3. 3 Grafo AS de Internet[ASCORE]
  • 4. 4 Tomograf´a ISPs[CheswickBurch] ı
  • 5. 5 Relaciones entre AS[RltAS]
  • 6. 6 Numero ASs medio por path[ASpathlength] ´
  • 7. 7 Resistencia ataques globales [resilience]
  • 8. 8 Resistencia ataques globales (2)
  • 9. 9 Resistencia ataques globales (3)
  • 10. 10 ´ Reparticion AS en el mundo [ASworld]
  • 11. 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. 12 Estad´stica [Brodsky1993, HBStatistics] ı ´ Teor´a de juegos[Yau2002, HBGameTheory] y econometrica[Granger1969, ı HBEconometrics]. ´ Complejidad de la comunicacion[KN1997, Hromkovic1997]. ´ Analisis de series temporales [Hamilton1994] ´ Teor´a del caos[BakerEtAl]: el trafico de Internet es self-similar. ı Teor´a 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. 13 Taxonom´a DoS [Kumar1995, Richardson2001, MirkovicEtAl2001] ı
  • 14. 14 ´ DDoS y los sistemas autonomos
  • 15. 15 ´ Arboles de ataques (1)
  • 16. 16 ´ Arboles de ataques (2)
  • 17. 17 ´ Arboles de ataques (3)
  • 18. 18 ´ Arboles de ataques (4)
  • 19. 19 L´nea temporal ataques DDoS ı
  • 20. 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, modifi- ´ cacion de los algoritmos de ataque con ligeras mejoras en eficiencia.
  • 21. 21 L´nea temporal ataques DrDoS ı
  • 22. 22 Reflectores en DrDoS Dificultan tracear el ataque hasta el Master . ´ ´ Crean difusion, hacen mas dif´cil 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´a sacrificar por las ventajas que reporta la difusion. ı ´ Fuentes potenciales de reflectores, con gran amplificacion y/o dif´ciles 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. 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´ctima, 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´ctima 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. 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. 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. 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. 27 Un total de 200 millones de paquetes en 3 semanas, provenientes 12805 ataques diferentes a 5000 direcciones IP v´ctima 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´an 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´as. ı 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´ctimas 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´ctimas se las ı ´ ataco entre 60 y 70 veces y a otra, 102 veces en una semana.
  • 28. 28 ´ Deteccion: monitorizar IP origen La regla general es que segun nos alejamos de la v´ctima, los ataques se ´ ı ´ hacen mas dif´ciles de detectar. ı Durante un ataque, la mayor´a de las IPs son nuevas para la v´ctima, pero ı ı en un flash crowd, la mayor´a 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. 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. 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. 31 El algoritmo ser´a calcular los valores positivos acumulados de Zn, es decir, ı k yn = Sn − m´n Sk , ı Sk = ∑ Zi , 1≤k≤n i=1 con S0 = 0 al principio de los calculos. La version recursiva ser´a calcular ´ ´ ı yn = (yn−1 + Zn)+ , y0 = 0. La funcion de decision asociada para detectar el ataque en un momento n ´ ´ ser´a ı 0 si yn ≤ N dN (yn) = 1 si yn > N con N el valor l´mite para la deteccion del ataque. ı ´
  • 32. 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´a 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. 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´ctima. ı ı ´ Abr´a una conexion al router de donde proced´an, reiniciando el proceso ı de ACL/debug. Problemas: Necesita de las claves de acceso a todos los routers. ´ ´ Solo funcionar´a con routers Cisco, no es generico. ı
  • 34. 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. 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 identificador de arista, bajo la ´ hipotesis de tener gran numero de paquetes en un ataque DDoS: con sufi- ´ ´ 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. 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´ctima y p siendo la ´ ı probabilidad de marcar un paquete, la probabilidad de paquetes enviados ´ por un atacante a la v´ctima que esten sin marcar es: ı P (paquete sin marcar recibido por la v´ctima) = (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´an crear paquetes marcados erroneos, de- ı jando inutil todo el esquema. En [Song2001] se ofrece un esquema para ´ autenticarlos, pero consume demasiada CPU.
  • 37. 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. 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 reflector atacante. Provoca una gran sobrecarga de las CPUs.
  • 39. 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´ctima sospecha que esta siendo atacada, mandar´a codigo a ı los routers adyacentes para buscar el flujo del ataque: una vez encontrado, ı ı ´ el router que lo reenv´a mandar´a 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. 40 ´ Prevencion Filtrado Ingress: filtrado 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: filtrado 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. 41 ´ Contencion: Pushback ´ Mismo objetivo que en las propuestas de redes activas: filtrar la direccion por todos los routers desde la v´ctima 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. 42 ´ ´ Comparacion entre metodos
  • 43. 43 ´ Mas comparaciones[HabibEtAlb] Consideraremos una red R con A routers arista y C routers centrales. En cada router A hay F flujos 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 filtrado, λ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. 44 Filtrado basado en rutas, no requiere que en todos los dominios se instalen filtros, 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. 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. 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´a, ı topolog´a, ı 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. 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. 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´a telefonica provee de conexion al ISP (A.A.A.1/24),
  • 49. 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´a 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. 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. 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. 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. 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 access-list 1 deny ip 1.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 2.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 5.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 7.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 10.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 23.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 27.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 31.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 36.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 37.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 39.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 41.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 42.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 49.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 50.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 58.0.0.0 0.255.255.255 any log-input
  • 54. 54 access-list 1 deny ip 59.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 70.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 71.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 72.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 73.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 74.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 75.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 76.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 77.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 78.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 79.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 83.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 84.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 85.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 86.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 87.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 88.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 89.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 90.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 91.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 92.0.0.0 0.255.255.255 any log-input
  • 55. 55 access-list 1 deny ip 93.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 94.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 95.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 96.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 97.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 98.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 99.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 100.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 101.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 102.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 103.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 104.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 105.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 106.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 107.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 108.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 109.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 110.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 111.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 112.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 113.0.0.0 0.255.255.255 any log-input
  • 56. 56 access-list 1 deny ip 114.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 115.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 116.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 117.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 118.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 119.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 120.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 121.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 122.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 123.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 124.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 125.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 126.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 127.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 169.254.0.0 0.0.255.255 any log-input access-list 1 deny ip 172.16.0.0 0.15.255.255 any log-input access-list 1 deny ip 173.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 174.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 175.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 176.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 177.0.0.0 0.255.255.255 any log-input
  • 57. 57 access-list 1 deny ip 178.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 179.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 180.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 181.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 182.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 183.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 184.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 185.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 186.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 187.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 189.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 190.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 192.0.2.0 0.0.0.255 any log-input access-list 1 deny ip 192.168.0.0 0.0.255.255 any log-input access-list 1 deny ip 197.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 223.0.0.0 0.255.255.255 any log-input access-list 1 deny ip 224.0.0.0 31.255.255.255 any log-input 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 access-list 1 deny ip any any log-input
  • 58. 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 deny host 224.0.1.3 log access-list 2 deny host 224.0.1.22 log access-list 2 deny host 224.0.1.24 log access-list 2 deny host 224.0.1.35 log access-list 2 deny host 224.0.1.60 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. 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 rate-limit input access-group 20 800000 50000 50000 conform-action transmit exceed-action drop ! Limita el tr´fico ICMP a 50 kbytes/s a rate-limit input access-group 30 400000 25000 25000 conform-action transmit exceed-action drop ! Multicast seguro ip multicast boundary 2
  • 60. 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 access-list 40 deny ip any any log-input ! 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. 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. 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. 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. 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. 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. 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. 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. 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. 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´a generar demasiado trafico y colapsar los routers. ı
  • 70. 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. 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- field. 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. 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. 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. 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 flooding and IP spoofing. Noviembre 2000. http://www.cert.org/advisories/CA-96- 21.html [CERT1998] CERT Advisory CA-98.01. Smurf IP Denial-Of-Service attacks, Enero 1998. http://www.cert.org/advisories/CA-98- 01.html
  • 75. 75 [CERT1997] CERT Advisory CA-1997-27. FTP-Bounce. http://www.cert.org/advisories/CA-1997- 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. 76 of Service Attacks. Department of Electrical and Computer Engineering, Iowa State Uni- versity. VER [HussainEtAL] Alefiya 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. 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. 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. 79 [CiscoURPF] Cisco Systems. Unicast Reverse Path For- warding. Cisco IOS Documentation, Mayo 1999. [WangEtAl2002] Haining Wang, Damlu Zhang, y Kang Shin. Detecting SYN flooding 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: Sniffing 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. 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. 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. 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 Spoofing 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. 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. 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. 85 http://www.checkpoint.com/products/firewall- 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 filtering for distributed DoS attack prevention in Power- Law Internets. Proceedings of the 2001
  • 86. 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 filtering. Proceed- ings ACM SIGCOMM, San Diego, Califor- nia, USA, Agosto 2001. [PaxsonFloyd] V. Paxson y S. Floyd. Wide-Area Traffic: 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. 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. 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. 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. Classification and Detection of Computer Intrusions, Ph.D. Thesis, Purdue University.
  • 90. 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. 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. 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. 93 [PengEtAld] Tao Peng, Chistropher Leckie y Kotagiri Ro- mamohanarao, Protection from Distributed Denial of Service Using History-based IP fil- 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. 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 filtering. Pro- ceedings of 10th International Conference on Computer Communications and Net- works, 2001. [Oliver2001] Ross Oliver. Countering SYN flood denial- of-service attacks, 29 Agosto 2001 Oliver USENIX [JungEtAl2002] Jaeyon Jung, Balachander Krishnamurthy, y Michael Rabinovich. Flash crowds and de-
  • 95. 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 Traffic Variables - A Feasibility Study, Proceedings of the 7th IFIP/IEEE International Sympo-
  • 96. 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. 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. 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. 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. 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 Identification for Network-based intrusions, 1999. Deciduous
  • 101. 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. 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

Related Documents