Sync from R2 skynet v8: manuales, operación, glosario v3
Añadido: - MANUAL_USUARIO_ARCHITECT.md - MANUAL_USUARIO_CORP.md - MANUAL_USUARIO_DECK.md - MANUAL_USUARIO_HST.md - 07_OPERACION/ (monitoring, runbooks, incident_response) - glosario_she_enterprise_v3.md Eliminado: - glosario_she_enterprise_v2.md (reemplazado por v3) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
ARCHITECT
424
07_OPERACION/incident_response.md
Normal file
424
07_OPERACION/incident_response.md
Normal file
@@ -0,0 +1,424 @@
|
||||
# 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
|
||||
|
||||
Reference in New Issue
Block a user