Preparación de Redes – Un modelo de análisis (página 3)

Partes: 1, 2, 3

31
Zona Controlada
Aplicando R.E.D.A.R – Algunas Estrategias

RE 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?