# 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)
```bash
# 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)
```bash
# 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
```bash
# 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
```bash
# 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)
```bash
# 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**
   ```bash
   # 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
```bash
# 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
```bash
# 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
```bash
# 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
```bash
# 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
```bash
# 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)
```bash
# 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
   ```bash
   # 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)
```bash
# 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
```bash
# 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
```bash
# 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