1 ´ ´ ´Prevencion, deteccion y contencion para ´ataques de denegacion de se...
2 ´ Introduccion ´¿Que es realmente Internet? Elementos constitutivo...
3Grafo AS de Internet[ASCORE]
4Tomograf´a ISPs[CheswickBurch] ı
5Relaciones entre AS[RltAS]
6Numero ASs medio por path[ASpathlength] ´
7Resistencia ataques globales [resilience]
8Resistencia ataques globales (2)
9Resistencia ataques globales (3)
10 ´Reparticion AS en el mundo [ASworld]
11 ´ Introduccion DDoSPrimeras referencias a DoS en 1983 [Gilgor1983], y...
12 Estad´stica [Brodsky1993, HBStatistics] ı ´ Teor´a de jueg...
13Taxonom´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)
19L´nea temporal ataques DDoS ı
20 Herramientas DDoSTrinoo: simple ataque UDP distribuido.Tribe Flood Network: incopora ICMP, UDP, SYN-Floo...
21L´nea temporal ataques DrDoS ı
22 Reflectores en DrDoSDificultan tracear el ataque hasta el Master . ´ ´Crean difusion,...
23 Peticiones DNS recursivas: si se ataca a un servidor DNS, los zom- bies del atacante pueden utilizar otros servidores...
24ataques smurf , ICMP echo spoofeados a direcciones broadcast. ´Trafico que genere mensajes ICMP (source quench, time exc...
25 Estad´stica de Ataques DoS ı ´Analisis BackScatter [MooreEtAl2001]. Presupuestos: Todos los paqu...
26rango monitorizado, R , 232 R ≥R ...
27Un total de 200 millones de paquetes en 3 semanas, provenientes12805 ataques diferentes a 5000 direcciones IP v´ctima di...
28 ´ Deteccion: monitorizar IP origenLa regla general es que segun nos alejamos de la v´ctima, los ataques ...
29 ´ Deteccion: algoritmo CUSUM ´ ´ ´ ´Algoritmo...
30 ´Una de las condiciones para el CUSUM no parametrico es que el valor...
31El 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 hastal...
33 Backtracking: DoSTracker ´En 1996, primer intento de autom...
34 Backtracking: CenterTrackPropuesto por Robert Stone[Stone2000].Usa una red virtual de tuneles IP sobre la red ...
35 Backtracking: PPMPPM (Probabilistic Packet Marking)[Song2001, SavageEtAl2000, ParkLee2001, DeanAl2001...
36 ´Un paquete marcado por un router tendra un campo distancia menor quela longitu...
37 Backtracking: ICMP tracebackProyecto del IETF[BellovinIETF, WuEtAl2001].Los routers inyectan un ICMP traceback de...
38 Backtracking: DECIDUOUSBasado en IPSEC, concretamente en los asociaciones de seguridad pro-tegidas con AH (Aut...
39 Backtracking: Active Networks ´ ´En los ...
40 ´ PrevencionFiltrado Ingress: filtrado de paquetes en el I...
41 ´ Contencion: Pushback ...
42 ´ ´Comparacion entre metodos
43 ´ Mas comparaciones[HabibEtAlb]Consideraremos una red R con A routers arista y C routers centr...
44Filtrado basado en rutas, no requiere que en todos los dominios se instalenfiltros, Sproceso = 0,2...
45con 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 dominio....
47Sincroni. - - - {A , C } {A } {A }relojRespuesta reactivo proacti...
48 ´ Configuracion routers CISCO ´ ´No toda la configuracion funcion...
49 ´que va al puerto de entrada del router del ISP (X.X....
50 ´Otros metodos utilizan ACLs [CisACLs].! A.A.A.1/24 - Conexi´n a Internet o! X.X.X.254/24 - P...
51service tcp-keepalives-inservice tcp-keepalives-outservice nagleservice timestamps log datetime show-timezone localtimes...
52! S´lo se podr´ entrar desde el firewall o aaccess-list 500 remark VTY Accessaccess-list 500 permit tcp host ...
53 no ip redirects no ip unreachables! IPs comunmente spoofeadasaccess-list 1 remark Spoofedaccess-list 1 deny ip 0.0.0....
54access-list 1 deny ip 59.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 70.0.0.0 0.255.2...
55access-list 1 deny ip 93.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 94.0.0.0 0.255.255.255 a...
56access-list 1 deny ip 114.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 115.0.0.0 0.255.255...
57access-list 1 deny ip 178.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 179.0.0.0 0.255.255.255 any log...
58!access-list 2 remark Multicastaccess-list 2 deny 224.0.0.0 0.0.0.255 logaccess-list 2 deny 239.0.0.0 0.255.255.255 loga...
59 ip access-group 1 in no ip proxy-arp no ip redirects no ip unreachables no ip mask-reply no ip direct...
60!! A˜adir todas las redes adicionales tras I.I.I.0 n!access-list 40 remark antispoofing ACLaccess-list 40 permit ip I....
61!boot system flash slot0:slot0:c7200-is-mz.121-5.T4.binlogging buffered 16384 debuggingno logging console! Cambiar CLAVE...
62aaa authentication enable default group tacacs+ enableaaa authorization commands 15 default group tacacs+ localaaa accou...
63access-list 50 permit tcp any I.I.I.0 0.0.0.255!ip tcp intercept list 50ip tcp intercept connection-timeout 120! Half-op...
64ip route 10.0.0.0 255.0.0.0 null0ip route 23.0.0.0 255.0.0.0 null0ip route 27.0.0.0 255.0.0.0 nu...
65ip route 78.0.0.0 255.0.0.0 null0ip route 79.0.0.0 255.0.0.0 null0ip route 83.0.0.0 255.0.0.0 null0ip rout...
66ip route 102.0.0.0 255.0.0.0 null0ip route 103.0.0.0 255.0.0.0 null0ip route 104.0.0.0 255.0.0.0 ...
67ip route 123.0.0.0 255.0.0.0 null0ip route 124.0.0.0 255.0.0.0 null0ip route 125.0.0.0 255.0.0.0 null0ip r...
68ip route 187.0.0.0 255.0.0.0 null0ip route 189.0.0.0 255.0.0.0 null0ip route 190.0.0.0 255.0.0.0 null0ip r...
69 CISCO: IP Source TrackerAlternativa en routers de gama alta (12000 y 7500) para sustituir el tracea- ...
70 Futuro ´ ´ ´De la simulacion teorica[Bres...
71 OceanStore[KubiatowiczEtAl2000] y otros: Plaxton[Plaxton1997] y el sis- tema operativo Scout[Spatscheck1999].Referenc...
72 port for IP traceback. Proceedings of the ACM SIGCOMM Conference, pages 295- ...
73 Intention-driven ICMP traceback, Internet- Draft: draft-wu-itrace-intention-00.t...
74[CERT2001] Trends in denial of service technology. CERT Coordination Center at Carnegie- Me...
75[CERT1997] CERT Advisory CA-1997-27. FTP-Bounce. http://www.cert.org/advisories/CA-1997- 27...
76 of Service Attacks. Department of Electrical and Computer Engineering, Iowa State U...
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- in...
81[RFCDraft] S. Floyd, S. Bellovin, J. Ionnidis, K. Kompel- la, R. Mahajan, y V. Paxson. Pushbac...
82 Proceedings of USENIX OSDI’99, New Or- leans, LA, Febrero 1999.[Burch2000] H. Burch y B....
83 IEEE Symposium on Security y Privacy , Oakly, CA, 1983.[Howard1998] John D. Howard....
84[DeLong2001] D. F. DeLong. “Hackers said to cost US. bil- lions” E-Commerce Times Online, Febr...
85 http://www.checkpoint.com/products/firewall- 1[Malan2001] G.R. Malan et al. Observa...
86 ACM SIGCOMM Conference, San Diego, California, USA, Agosto 2001.[ParkLee2001c] Kih...
87 Proceedings of IEEE Symposium on Secu- rity and Privacy, Mayo 1997.[Bresl...
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.[Granger1969] ...
90[Richardson2001] T.W. Richardson. The development of a Database Taxonomy of Vulnerabilities to ...
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 and ...
95 nial of service attacks: characterization and implications for CDNs and web sit...
96 sium on Integrated Network Management, Seattle, WA, Mayo 14-18, 2001.[Sanns2000] Sanns, W. ...
97[Afrajmovich1999] V. S. Afrajmovich, Yu S. Il’yashenko, Yu. S. Il’Yashenko, L. P. Shilnikov, Leonid...
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. Aumann ...
100 Dynamics: An Introduction, Cambridge Uni- versity Press, ISBN: 0521476852.[Wasserman...
101[Halbig1999] Gregory Halbig. An Active Network approach to defending and track- ...
102[ASworld] ´ Comparacion AS en el mundo. CAIDA. bgp2country CAIDA[resilience]...
of 102

Prevencion Deteccion Contencion DOS

Published on: Mar 4, 2016
Published in: Technology      
Source: www.slideshare.net


Transcripts - Prevencion Deteccion Contencion DOS

  • 1. 1 ´ ´ ´Prevencion, deteccion y contencion para ´ataques de denegacion de servicio ´DAVID C EREZO S A NCHEZhttp://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. 3Grafo AS de Internet[ASCORE]
  • 4. 4Tomograf´a ISPs[CheswickBurch] ı
  • 5. 5Relaciones entre AS[RltAS]
  • 6. 6Numero ASs medio por path[ASpathlength] ´
  • 7. 7Resistencia ataques globales [resilience]
  • 8. 8Resistencia ataques globales (2)
  • 9. 9Resistencia ataques globales (3)
  • 10. 10 ´Reparticion AS en el mundo [ASworld]
  • 11. 11 ´ Introduccion DDoSPrimeras 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 lascorporaciones 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. 13Taxonom´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. 19L´nea temporal ataques DDoS ı
  • 20. 20 Herramientas DDoSTrinoo: 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. 21L´nea temporal ataques DrDoS ı
  • 22. 22 Reflectores en DrDoSDificultan 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. 24ataques 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 mpaquetes, la probabilidad de recibir un paquete ser´a ı nm E (X) = 32 2La 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. 26rango monitorizado, R , 232 R ≥R nPosibles 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. 27Un total de 200 millones de paquetes en 3 semanas, provenientes12805 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 todoslos 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 de30 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 persistendurante varios d´as. ıUn 27.5 % tienen un TLD desconocido, seguido del 15 % para .net, .comy .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 origenLa 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 valormedio en m de α a α + h, CUSUM (Cumulative Sum) detecta cambios deal 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=1cumplen que E (ξn) = E (ηn) ≡ 0, h = 0.
  • 30. 30 ´Una de las condiciones para el CUSUM no parametrico es que el valormedio de {Xn}debe ser negativo en condiciones normales, positivo cuando ´ocurren cambios, por lo que lo transformaremos sin perdida de generalidaden 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. 31El algoritmo ser´a calcular los valores positivos acumulados de Zn, es decir, ı k yn = Sn − m´n Sk , ı Sk = ∑ Zi , 1≤k≤n i=1con 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 > Ncon 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 hastallegar 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: CenterTrackPropuesto 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 arouters 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 eltiempo en el que tardan en extenderse la nuevas rutas, el paso de estadosde las conexiones de router a router, etc...
  • 35. 35 Backtracking: PPMPPM (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 quela 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 tracebackProyecto 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: DECIDUOUSBasado en IPSEC, concretamente en los asociaciones de seguridad pro-tegidas con AH (Authentication Headers).Iterativamente se construyen asociaciones de seguridad con los routers adistancias 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 anadirfuncionalidad 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 sise considera necesario.
  • 40. 40 ´ PrevencionFiltrado Ingress: filtrado de paquetes en el ISP con direcciones fuentes ı ´ ´ileg´timas, segun la conexion de ingreso por la que los paquetes entran en lared.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 lospaquetes que pertenecen al dominio del cliente.
  • 41. 41 ´ Contencion: Pushback ´Mismo objetivo que en las propuestas de redes activas: filtrar la direccionpor 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. Encada 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 quecausan 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 oproceso para marcado y λ3unidades de proceso para monitorizacion.´ Filtrado Ingress, Sproceso Ingress = A × F × P × λ1 ´ y sin necesidad de comunicacion.
  • 44. 44Filtrado basado en rutas, no requiere que en todos los dominios se instalenfiltros, Sproceso = 0,2 × SIngresssegun [ParkLee2001c]. ´PPM (Probabilistic Packet Marking) Sproceso = A × F × P × p × h × λ1con p la probabilidad de marcar un paquete y h el numero de saltos en ´cada dominio. ´Monitorizacion por router central, F ×γ×dScomunicaci´ 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. 45con 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 × λ3con fs siendo la frecuencia a la que se mandan stripes por unidad detiempo 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 distribuidaS volumen ataque numero ´ numero ´ no conex- routers, routers,depende paquetes paquetes iones topolog´a, ı topolog´a, ı entrada entrada violando ´ trafico ´ trafico SLA ataque ataqueS imple- todos los routers A con routers de en A y C A A ´mentacion Ingress dominios selectivos
  • 47. 47Sincroni. - - - {A , C } {A } {A }relojRespuesta reactivo proactivo proactivo reactivo reactivo reactivo ´Deteccion no no no s´ ı s´ ı s´ ı ´violacionSLADetecta cualquier IP IP IP cualquier cualquier cualquierataques spoofeadas spoofeadas IP IP IPusando 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 routertiene 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 deordenadores disponibles para las siguientes funcionalidades del router: unservidor FTP para almacenar coredumps de la IOS (I.I.I.2), un servidorNTP 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 dhcpno service pad
  • 51. 51service tcp-keepalives-inservice tcp-keepalives-outservice nagleservice timestamps log datetime show-timezone localtimeservice 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 serverno ip source-routeno ip fingerno ip bootp serverno ip domain-lookupno cdp run!banner motd %Router protected against DoS attacks.%!
  • 52. 52! S´lo se podr´ entrar desde el firewall o aaccess-list 500 remark VTY Accessaccess-list 500 permit tcp host Z.Z.Z.1 host 0.0.0.0 range 22 23 log-inputaccess-list 500 deny ip any any log-input!line con 0 exec-timeout 30 0line vty 0 10 access-class 500 in exec-timeout 30 0 transport input telnet sshline 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 spoofeadasaccess-list 1 remark Spoofedaccess-list 1 deny ip 0.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 1.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 2.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 5.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 7.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 10.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 23.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 27.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 31.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 36.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 37.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 39.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 41.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 42.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 49.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 50.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 58.0.0.0 0.255.255.255 any log-input
  • 54. 54access-list 1 deny ip 59.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 70.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 71.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 72.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 73.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 74.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 75.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 76.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 77.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 78.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 79.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 83.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 84.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 85.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 86.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 87.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 88.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 89.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 90.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 91.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 92.0.0.0 0.255.255.255 any log-input
  • 55. 55access-list 1 deny ip 93.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 94.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 95.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 96.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 97.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 98.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 99.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 100.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 101.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 102.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 103.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 104.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 105.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 106.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 107.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 108.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 109.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 110.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 111.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 112.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 113.0.0.0 0.255.255.255 any log-input
  • 56. 56access-list 1 deny ip 114.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 115.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 116.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 117.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 118.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 119.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 120.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 121.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 122.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 123.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 124.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 125.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 126.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 127.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 169.254.0.0 0.0.255.255 any log-inputaccess-list 1 deny ip 172.16.0.0 0.15.255.255 any log-inputaccess-list 1 deny ip 173.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 174.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 175.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 176.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 177.0.0.0 0.255.255.255 any log-input
  • 57. 57access-list 1 deny ip 178.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 179.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 180.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 181.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 182.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 183.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 184.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 185.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 186.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 187.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 189.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 190.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 192.0.2.0 0.0.0.255 any log-inputaccess-list 1 deny ip 192.168.0.0 0.0.255.255 any log-inputaccess-list 1 deny ip 197.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 223.0.0.0 0.255.255.255 any log-inputaccess-list 1 deny ip 224.0.0.0 31.255.255.255 any log-inputaccess-list 1 deny icmp any any fragments log-inputaccess-list 1 permit ip any I.I.I.0 0.0.0.255access-list 1 permit ip any 224.0.0.0 15.255.255.255access-list 1 deny ip any any log-input
  • 58. 58!access-list 2 remark Multicastaccess-list 2 deny 224.0.0.0 0.0.0.255 logaccess-list 2 deny 239.0.0.0 0.255.255.255 logaccess-list 2 deny host 224.0.1.2 logaccess-list 2 deny host 224.0.1.3 logaccess-list 2 deny host 224.0.1.22 logaccess-list 2 deny host 224.0.1.24 logaccess-list 2 deny host 224.0.1.35 logaccess-list 2 deny host 224.0.1.60 logaccess-list 2 permit 224.0.0.0 15.255.255.255 log!access-list 10 remark CAR Multicastaccess-list 10 permit ip any 224.0.0.0 15.255.255.255access-list 20 remark CAR UDPaccess-list 20 permit udp any anyaccess-list 30 remark CAR ICMPaccess-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 ACLaccess-list 40 permit ip I.I.I.0 0.0.0.255 anyaccess-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.binlogging buffered 16384 debuggingno logging console! Cambiar CLAVEenable secret CLAVEno enable password! Cambiar USUARIOFTP, CLAVEFTPip ftp username USUARIOFTPip ftp password CLAVEFTPexception core-file antidos-COREexception protocol ftpexception dump I.I.I.2! Cambiar NTPKEYntp authentication-key 6767 md5 NTPKEYntp authenticatentp update-calendarntp server I.I.I.3! Cambiar TACACSKEYaaa new-modelaaa authentication login default group tacacs+ local-case
  • 62. 62aaa authentication enable default group tacacs+ enableaaa authorization commands 15 default group tacacs+ localaaa 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.4tacacs-server key TACACSKEY! Cambiar TACACSUSERNAME y TACACSPASSWORDusername TACACSUSERNAME password TACACSPASSWORD!logging trap debugginglogging facility local5logging source-interface loopbacklogging I.I.I.5!ip flow-export source loopbackip flow-export destination I.I.I.6 2055ip flow-export version 5 origin-as!! Protecci´n de la Intranet oaccess-list 50 remark TCP Intercept
  • 63. 63access-list 50 permit tcp any I.I.I.0 0.0.0.255!ip tcp intercept list 50ip tcp intercept connection-timeout 120! Half-open de 10 segundosip tcp intercept watch-timeout 10ip tcp intercept one-minute low 1000ip tcp intercept one-minute high 5000! Cisco Express Forwardingip cef!ip classless!! Ruta por defecto a Internetip route 0.0.0.0 0.0.0.0 A.A.A.1ip route I.I.I.0 255.255.255.0 Z.Z.Z.1! Blackholeip route 1.0.0.0 255.0.0.0 null0ip route 2.0.0.0 255.0.0.0 null0ip route 5.0.0.0 255.0.0.0 null0ip route 7.0.0.0 255.0.0.0 null0
  • 64. 64ip route 10.0.0.0 255.0.0.0 null0ip route 23.0.0.0 255.0.0.0 null0ip route 27.0.0.0 255.0.0.0 null0ip route 31.0.0.0 255.0.0.0 null0ip route 36.0.0.0 255.0.0.0 null0ip route 37.0.0.0 255.0.0.0 null0ip route 39.0.0.0 255.0.0.0 null0ip route 41.0.0.0 255.0.0.0 null0ip route 42.0.0.0 255.0.0.0 null0ip route 49.0.0.0 255.0.0.0 null0ip route 50.0.0.0 255.0.0.0 null0ip route 58.0.0.0 255.0.0.0 null0ip route 59.0.0.0 255.0.0.0 null0ip route 70.0.0.0 255.0.0.0 null0ip route 71.0.0.0 255.0.0.0 null0ip route 72.0.0.0 255.0.0.0 null0ip route 73.0.0.0 255.0.0.0 null0ip route 74.0.0.0 255.0.0.0 null0ip route 75.0.0.0 255.0.0.0 null0ip route 76.0.0.0 255.0.0.0 null0ip route 77.0.0.0 255.0.0.0 null0
  • 65. 65ip route 78.0.0.0 255.0.0.0 null0ip route 79.0.0.0 255.0.0.0 null0ip route 83.0.0.0 255.0.0.0 null0ip route 84.0.0.0 255.0.0.0 null0ip route 85.0.0.0 255.0.0.0 null0ip route 86.0.0.0 255.0.0.0 null0ip route 87.0.0.0 255.0.0.0 null0ip route 88.0.0.0 255.0.0.0 null0ip route 89.0.0.0 255.0.0.0 null0ip route 90.0.0.0 255.0.0.0 null0ip route 91.0.0.0 255.0.0.0 null0ip route 92.0.0.0 255.0.0.0 null0ip route 93.0.0.0 255.0.0.0 null0ip route 94.0.0.0 255.0.0.0 null0ip route 95.0.0.0 255.0.0.0 null0ip route 96.0.0.0 255.0.0.0 null0ip route 97.0.0.0 255.0.0.0 null0ip route 98.0.0.0 255.0.0.0 null0ip route 99.0.0.0 255.0.0.0 null0ip route 100.0.0.0 255.0.0.0 null0ip route 101.0.0.0 255.0.0.0 null0
  • 66. 66ip route 102.0.0.0 255.0.0.0 null0ip route 103.0.0.0 255.0.0.0 null0ip route 104.0.0.0 255.0.0.0 null0ip route 105.0.0.0 255.0.0.0 null0ip route 106.0.0.0 255.0.0.0 null0ip route 107.0.0.0 255.0.0.0 null0ip route 108.0.0.0 255.0.0.0 null0ip route 109.0.0.0 255.0.0.0 null0ip route 110.0.0.0 255.0.0.0 null0ip route 111.0.0.0 255.0.0.0 null0ip route 112.0.0.0 255.0.0.0 null0ip route 113.0.0.0 255.0.0.0 null0ip route 114.0.0.0 255.0.0.0 null0ip route 115.0.0.0 255.0.0.0 null0ip route 116.0.0.0 255.0.0.0 null0ip route 117.0.0.0 255.0.0.0 null0ip route 118.0.0.0 255.0.0.0 null0ip route 119.0.0.0 255.0.0.0 null0ip route 120.0.0.0 255.0.0.0 null0ip route 121.0.0.0 255.0.0.0 null0ip route 122.0.0.0 255.0.0.0 null0
  • 67. 67ip route 123.0.0.0 255.0.0.0 null0ip route 124.0.0.0 255.0.0.0 null0ip route 125.0.0.0 255.0.0.0 null0ip route 126.0.0.0 255.0.0.0 null0ip route 127.0.0.0 255.0.0.0 null0ip route 169.254.0.0 255.255.0.0 null0ip route 172.16.0.0 255.240.0.0 null0ip route 173.0.0.0 255.0.0.0 null0ip route 174.0.0.0 255.0.0.0 null0ip route 175.0.0.0 255.0.0.0 null0ip route 176.0.0.0 255.0.0.0 null0ip route 177.0.0.0 255.0.0.0 null0ip route 178.0.0.0 255.0.0.0 null0ip route 179.0.0.0 255.0.0.0 null0ip route 180.0.0.0 255.0.0.0 null0ip route 181.0.0.0 255.0.0.0 null0ip route 182.0.0.0 255.0.0.0 null0ip route 183.0.0.0 255.0.0.0 null0ip route 184.0.0.0 255.0.0.0 null0ip route 185.0.0.0 255.0.0.0 null0ip route 186.0.0.0 255.0.0.0 null0
  • 68. 68ip route 187.0.0.0 255.0.0.0 null0ip route 189.0.0.0 255.0.0.0 null0ip route 190.0.0.0 255.0.0.0 null0ip route 192.0.2.0 255.255.255.0 null0ip route 192.168.0.0 255.255.0.0 null0ip route 197.0.0.0 255.0.0.0 null0ip route 223.0.0.0 255.0.0.0 null0
  • 69. 69 CISCO: IP Source TrackerAlternativa 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 entornosreales, 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