system-docs/07_OPERACION/incident_response.md

Procedimientos de Respuesta ante Incidentes - Skynet v8

Procedimiento General ante Incidentes

Fases de respuesta

1. Detección: Sistema de alertas detecta anomalía
2. Confirmación: Validar que es incidente real
3. Escalación: Notificar al equipo
4. Investigación: Determinar causa
5. Mitigación: Aplicar solución temporal
6. Resolución: Fix permanente
7. Post-mortem: Análisis y mejora

---

Incidente: Caída de Servidor

Severidad

CRÍTICA - Impacto: 100% del servicio indisponible

Detección

• Sistema de monitoreo no recibe heartbeat
• Usuarios reportan servicio inaccesible
• Alertas en Grafana: node_up == 0

Confirmación (2 minutos máximo)

# Verificar conectividad básica
ping 69.62.126.110

# Intentar conexión SSH
ssh -i ~/.ssh/tzzr architect@69.62.126.110

# Si SSH no responde, es caída real

Escalación INMEDIATA

1. Notificar a:

   • On-call engineer (5 min de respuesta)
   • Engineering lead
   • Operations manager

2. Crear incident

   • Abrir INC ticket
   • Timestamp inicio
   • Severidad: P1-CRITICAL

3. Canales de comunicación

   • Slack #incidents-critical
   • Email a escalation-list@skynet.tzzr
   • SMS a on-call (si disponible)

Investigación inicial (5 minutos)

# Desde backup server
ssh -i ~/.ssh/tzzr root@72.62.1.113  # deck

# Verificar recursos
ping -c 3 69.62.126.110
ssh -o ConnectTimeout=5 root@69.62.126.110 "uptime"

# Verificar logs en firewall/router
ssh monitoring "tail -f /var/log/firewall.log | grep 69.62.126.110"

# Contactar proveedor datacenter
# Verificar alertas de potencia/red

Mitigación Temporal (Si fallo de hardware)

Opción 1: Reinicio remoto

# Si acceso IPMI disponible
ipmitool -I lanplus -H ipmi.datacenter.com -U admin -P pass power reset

# Esperar 3 minutos
sleep 180

# Verificar si responde
ping -c 3 69.62.126.110

Opción 2: Failover a servidor backup

# Redirigir tráfico a deck (72.62.1.113)
# Actualizar DNS
# change A record: skynet.ttzr 300 IN A 72.62.1.113

# Sincronizar estado si posible
rsync -avz --delete /var/lib/postgresql/ deck:/var/lib/postgresql/

# Iniciar servicios en backup
ssh deck "systemctl start skynet-database skynet-api skynet-core"

Resolución

• Si hardware: Contactar con datacenter para reemplazo
• Si red: Contactar ISP para restaurar conectividad
• Si aplicación: Debugging post-restauración

Post-mortem (24 horas)

• Documentar timeline
• Identificar root cause
• Implementar prevención
• Actualizar runbooks

---

Incidente: Ataque DDoS

Severidad

ALTA - Impacto: Servicio degradado o inaccesible

Detección

• Spike repentino de tráfico (>10x normal)
• Alertas: request_rate > 50k/sec
• Origen: Múltiples IPs no reconocidas
• Network utilization > 80% inbound

Confirmación (1 minuto)

# Verificar tráfico
iftop -n -s 10

# Análisis de IPs origen
tcpdump -i eth0 -nnn 'tcp.port == 80 or tcp.port == 443' | \
  awk '{print $3}' | cut -d. -f1-4 | sort | uniq -c | sort -rn | head -20

# Patrones de ataque
# - SYN flood: conexiones incompletas
ss -antp | grep SYN_RECV | wc -l
# - HTTP flood: requests normales pero masivos
# - DNS amplification: puerto 53

# Verificar logs de aplicación
tail -f /var/log/skynet/access.log | head -100

Escalación INMEDIATA

1. Notificar:

   • Security team
   • Network operations
   • Incident commander

2. Crear incident

   • INC ticket con "DDoS" en título
   • Severidad: P2-HIGH (puede ser P1 si impacto crítico)

3. Activar plan DDoS

   # Alertas automáticas envían:
   # - Notificación a CDN provider
   # - Activación de rate limiting
   # - Análisis automático de patrones
   

Mitigación Temporal (Primeros 5-10 minutos)

Paso 1: Rate limiting automático

# Activar rate limiting por IP
iptables -A INPUT -p tcp --dport 80 -m limit --limit 25/minute --limit-burst 100 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j DROP

# Alternativa: WAF rules
# modsecurity rule: SecAction phase:1,nolog,pass,setvar:ip.suspicious=1

Paso 2: Blacklist de IPs ofensoras

# Script para extraer top atacantes
tcpdump -i eth0 -nnn -c 10000 'tcp.port == 80 or tcp.port == 443' | \
  awk '{print $3}' | cut -d. -f1-4 | \
  sort | uniq -c | sort -rn | head -100 | \
  awk '{print "iptables -A INPUT -s " $3 " -j DROP"}'

# O usar geo-blocking
geoiplookup <IP> | grep -E "CN|RU|KP" && echo "DROP"

Paso 3: Activar protección DNS

# Cambiar nameservers a proveedor con DDoS mitigation
# (e.g., CloudFlare, Akamai)

# Actualizar DNS:
# skynet.ttzr NS dns1.cloudflare.com
# skynet.ttzr NS dns2.cloudflare.com

# O activar Cloudflare proxy:
# change A record a IP de Cloudflare
# Cloudflare mitiga el ataque antes de llegar a nuestro servidor

Escalación a DDoS Mitigation Service

# Si ataque persiste > 30 minutos
# Activar contrato con DDoS mitigation provider

# Ejemplo: Cloudflare
# 1. Cambiar nameservers
# 2. Enable "I'm under attack mode"
# 3. Cloudflare absorbe el tráfico malicioso

# Ejemplo: AWS Shield Advanced
# 1. Redirigir tráfico a AWS CloudFront
# 2. AWS absorbe y filtra ataque
# 3. Tráfico legítimo llega a servidor

Investigación paralela

# Mientras se mitiga:
# 1. Analizar patrones de ataque
# 2. Identificar botnet o atacante
# 3. Reportar a ISP del atacante
# 4. Notificar law enforcement si necesario

# Comando: detectar patrón de User-Agent
tail -f /var/log/skynet/access.log | grep -o 'User-Agent: [^"]*' | sort | uniq -c | sort -rn | head -5

Resolución

• Dejar mitigación activa mientras persista ataque
• Bloqueo permanente de IPs confirmadas maliciosas
• Mantener WAF rules
• Monitoreo intensivo por 24 horas

Post-mortem

• Análisis de logs del ataque
• Identificación de patrones para prevención futura
• Actualización de WAF rules
• Prueba de carga para validar capacidad

---

Incidente: Breach de Seguridad

Severidad

CRÍTICA - Impacto: Acceso no autorizado a datos sensibles

Detección

• Alertas de IDS/IPS
• Comportamiento anómalo de usuario
• Cambios no autorizados en archivos críticos
• Alertas de WAF: SQLi, RFI, etc.

Confirmación (Inmediato)

# Verificar logs de seguridad
grep "ALERT\|ERROR\|FAILED" /var/log/auth.log | tail -50

# Revisar cambios recientes
find /var/www /etc /root -mtime -1 -ls

# Búsqueda de shells web
find / -name "*.php" -o -name "*.jsp" -o -name "*.asp" | \
  xargs grep -l "exec\|system\|shell_exec" 2>/dev/null

# Revisar procesos anómalos
ps auxf | grep -E "bash|nc|perl|python" | grep -v grep

Escalación CRÍTICA + Aislamiento (1 minuto)

1. AISLAR SERVIDOR INMEDIATAMENTE

   • Desconectar del firewall si es posible
   • O bloquear tráfico no autorizado

   # Bloquear acceso excepto admin
   iptables -F INPUT
   iptables -A INPUT -i lo -j ACCEPT
   iptables -A INPUT -s <ADMIN_IP> -j ACCEPT
   iptables -A INPUT -j DROP
   

2. Notificar a:

   • CTO / Security lead (inmediato)
   • Incident commander
   • Legal team
   • HR (si credenciales de empleado usadas)

3. Crear incident

   • INC ticket: "SECURITY BREACH"
   • Severidad: P1-CRITICAL
   • Activar crisis management

4. Notificar stakeholders

   • CEO
   • Directores de área afectada
   • Equipo legal

Investigación (En paralelo con aislamiento)

# NO modificar nada en el servidor comprometido aún
# Preservar evidencia

# 1. Identificar punto de entrada
grep "FAILED\|UNAUTHORIZED" /var/log/auth.log | tail -100

# 2. Buscar malware/backdoors
find /tmp /home /var/tmp -mtime -1 -type f | xargs file
strings /var/log/syslog | grep -E "curl|wget|chmod" | tail -20

# 3. Revisar cambios en usuarios/permisos
grep "sudo\|usermod\|chmod 777" /var/log/auth.log

# 4. Revisar conexiones de red
netstat -pantu | grep ESTABLISHED | head -20
lsof -i -P -n | grep -v LISTEN

# 5. Examinar sistema de archivos en disco
# (hacer copia forense primero)
ddrescue /dev/sda /mnt/forensic/sda.img
mount -o ro /mnt/forensic/sda.img /mnt/forensic_mount

# 6. Buscar cambios en archivos críticos
find /etc /root /var/www -mtime -3 ! -path "*/.*" -type f -ls

Contención

# 1. Si credenciales comprometidas
# - Resetear contraseñas de todos los usuarios
# - Cambiar API keys
# - Revocar OAuth tokens

# 2. Si datos expuestos
# - Inventariar datos expuestos
# - Notificar a usuarios afectados (según GDPR/CCPA)
# - Contactar a asegurador

# 3. Parches de seguridad
# Aplicar patches a vulnerabilidad explotada
# Actualizar software vulnerable

Recovery

# Opción 1: Restore desde backup limpio pre-breach
systemctl stop skynet-*
pg_restore -d postgres /backups/skynet_2025-12-25.sql  # Anterior al breach
systemctl start skynet-*

# Opción 2: Rebuild desde source control
git clone https://gitea.ttzr/skynet/core.git
cd core && git checkout commit_seguro
./install.sh

Post-mortem (CRÍTICO)

• Análisis forense completo
• Publicar breach disclosure si requerido por ley
• Auditoría de seguridad completa
• Implementar controles preventivos
• Revisión de políticas de seguridad

---

Contactos de Emergencia

Equipo de On-Call

Rol	Nombre	Teléfono	Email	Backup
Principal	[ON-CALL]	+X XXXXXXXXX	oncall@skynet.ttzr	[BACKUP]
Security	CISO	+X XXXXXXXXX	ciso@skynet.ttzr	Security Lead
Operations	Ops Manager	+X XXXXXXXXX	ops@skynet.ttzr	DevOps Lead
Database	DBA Lead	+X XXXXXXXXX	dba@skynet.ttzr	DBA Senior

Escalación Automática

Incidente detectado
    ↓
Alertas a Slack #incidents
    ↓
Si no confirmado en 5 min → Email a on-call
    ↓
Si no responde en 10 min → SMS + teléfono
    ↓
Si no responde en 15 min → Escalar a manager
    ↓
Si Severidad P1 → Activar crisis team

Proveedores Externos

Datacenter

• Proveedor: [DATACENTER_NAME]
• Contacto NOC: +X XXXXXXXXX
• Tickets: https://support.datacenter.com
• Emergencia 24/7: [NÚMERO]

ISP

• Proveedor: [ISP_NAME]
• Contacto: +X XXXXXXXXX
• Status page: https://status.isp.com
• Emergencia: [NÚMERO]

Banco de datos

• Proveedor: [DB_PROVIDER]
• Support: [EMAIL/TELÉFONO]
• Documentation: [URL]

Escaleras de escalación según severidad

P1-CRITICAL (Todos afectados)

1. On-call engineer (inmediato)
2. Tech lead (1 min)
3. Engineering manager (2 min)
4. CTO (3 min)
5. CEO (5 min si no resolviendo)

P2-HIGH (Servicio degradado)

1. On-call engineer
2. Tech lead (si no resolviendo en 10 min)
3. Engineering manager (si no resolviendo en 30 min)

P3-MEDIUM (Funcionalidad limitada)

1. On-call engineer
2. Tech lead (próximo turno si no urgente)

P4-LOW (Feature requests, problemas menores)

1. Queue para próximo sprint
2. No escalación urgente