31 Zona Controlada Aplicando R.E.D.A.R – Algunas EstrategiasRE gistro
Algunos aspectos a considerar en la Defensa Registrar y analizar acciones de autenticación Estadísticas de tráfico en función protocolos y servicios
D ectección de Intrusos
Alertas de Cambios Reglas de monitoreo de puertos y servicios en el IDS Control de permisos en las máquinas – Integridad del software y reglas
AuditoRía
Pruebas de penetración Reglas y tráfico de red malicioso Simulación de ataques e incidentes.
32 LOG IDS – SNORT
[**] BETA – Anon FTP [**] 12/14-12:02:25.335000 209.88.62.192:63307 -> 161.69.2.23:21 TCP TTL:127 TOS:0x0 ID:1203 DF *****PA* Seq: 0xE4A4E8 Ack: 0xFB8D3B8F Win: 0x2206
[**] IDS3 – MISC-Traceroute TCP [**] 12/14-12:03:53.817805 209.185.131.251:80 -> 209.88.62.192:63295 TCP TTL:1 TOS:0x0 ID:29731 DF ****R*** Seq: 0x8E81AA48 Ack: 0x8E81AA48 Win: 0x2238
[**] PING-ICMP Time Exceeded [**] 12/14-12:03:53.817846 209.88.62.192 -> 209.185.131.251 ICMP TTL:255 TOS:0xC0 ID:10334 TTL EXCEEDED
R.E.D.A.R enZona controlada
33 Ejercicios 4. Si usted encuentra dentro de su LOG de WEBServer el siguiente registro, cuál sería su diagnóstico?
. 157.253.4.13 – – [14/Sep/2001:19:50:56 -0500] "GET /default.ida?XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a HTTP/1.0" 404 283.
CODE RED!!!
34 R.E.D.A.R en Contexto Internet EXTERIOR ZONA CONTROLADA LÍNEA DE DEFENSA RED PERÍMETRO Listas de Control de Acceso Filtro de paquetes Reglas de Control de Acceso Reglas de Monitoreo Reglas de Monitoreo Registro de Acceso S I N C R O N I Z A C I Ó N C O R R E L A C I Ó N A F I N A M I E N T O S I M U L A C I Ó N Y P R U E B A S C O N T R O L D E E V I D E N C I A
35 R.E.D.A.R. En resumen Es requisito para la preparación forense de redes: Establecer mecanismos de sincronización de tiempo entre la zona de perímetro, la línea de defensa y la zona controlada.
Desarrollar guías de análisis y control de evidencia, para cada uno de los segmentos: zona de perímetro, la línea de defensa y la zona controlada, que permitan correlacionar la evidencia identificada.
Capacitar y entrenar a los administradores y encargados de la arquitectura para adelantar acciones de recuperación y control de evidencia.
Son actividades que alimentan y cuestionan la preparación forense de redes Simulación y Pruebas Pruebas de penetración Ataques basados en manipulación de tráfico Atentados contra la integridad de máquinas y configuraciones de sistemas de seguridad Afinamiento de la arquitectura
36 R.E.D.A.R. Hacia el futuro… Algunas directrices de investigación hacia el futuro
Especificar guías prácticas de preparación forense para cada uno de los segmentos en una arquitectura
Preparación forense redes de perímetro Preparación forense líneas de defensa Preparación forense de zonas controladas
Afinamiento y balanceo del registro remoto
Análisis de vulnerabilidades y performance Criterios para establecer qué registro es necesario Extensiones y aporte de HONEYNETS
Análisis Forenses detallados
Desarrollo de estrategias de correlación de evidencia Registro de tráfico normal de aplicaciones y servicios Incorporación de experiencias y alianzas con proyectos como el HONEYNET PROJECT.
37 R.E.D.A.R. Conclusiones La preparación forense de redes, no es una opción para los administradores de redes y responsables de arquitecturas computacionales.
Las estrategias de análisis forenses deben ser actividades conjuntas que se realicen entre las funciones de seguridad y los expertos técnicos del área de telecomunicaciones.
No es opcional recoger evidencia, el ordenamiento legal está detrás de nuevas formas de perseguir la delincuencia electrónica
Ante un incidente de seguridad, la respuesta y el aseguramiento de la eviencia son factores críticos para su control.
Los procedimientos forense deben ajustarse con los cambios y simular su efectividad a través de las pruebas de penetración de la arquitectura.
38 R.E.D.A.R. Breve Checklist ante Incidente Sincronización de tiempo La hora de los enrutadores coincide con la hora del FW? Existen diferencias de tiempo entre la hora reportada del ataque y las máquinas involucradas? Los registros de actividad y violaciones de las listas de control de acceso y filtros exportadas están alineadas con la hora del incidente? El protocolo NTP – Network Time Protocol estaba en su última versión? Realmente confiable? Cuando fue la última sincronización de tiempo que se efectuó en la arquitectura?
Control de Evidencia Los registros identificados, se encuentran completos y asegurados? Existen vacíos o saltos en los registros identificados en la arquitectura atacada? Se cuenta con guías de recolección y control de evidencia? Se tiene identificada la evidencia a recoger en cada uno de los segmentos de la arquitectura: zona de perímetro, la línea de defensa y la zona controlada Existe personal entrenado en análisis de evidencia digital? Correlación de eventos?
| Página siguiente |