Arquitectura de sistemas: Redes, infraestructura y superficies de ataque

Objetivos: Al terminar este tema, podrás…

Analizar arquitecturas de sistemas identificando componentes y sus roles de seguridad

Mapear superficies de ataque en infraestructuras típicas

Aplicar principios de seguridad a cada capa del stack tecnológico

Diseñar controles apropiados para diferentes tipos de infraestructura

La arquitectura como base del análisis de seguridad

Para proteger un sistema, primero debes entender cómo funciona. Cada componente tiene:

Función: Qué hace en la arquitectura
Superficie de ataque: Puntos donde puede ser atacado
Controles aplicables: Medidas de protección específicas

Como ingeniero de seguridad, tu primer paso en cualquier proyecto es mapear la arquitectura y sus flujos de datos.

Modelo de capas de una aplicación moderna

┌─────────────────────────────────────────────────────────────────┐
│                         USUARIOS                                │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│   CAPA DE PRESENTACIÓN (Clientes)                               │
│   • Navegadores web      • Apps móviles      • Apps desktop     │
│   Riesgos: XSS, clickjacking, código malicioso en cliente       │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│   CAPA DE RED (Transporte)                                      │
│   • CDN/WAF      • Load Balancer      • API Gateway             │
│   Riesgos: MitM, DDoS, certificate issues                       │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│   CAPA DE APLICACIÓN (Lógica de negocio)                        │
│   • Servidores web       • Microservicios    • APIs             │
│   Riesgos: Injection, broken auth, SSRF, business logic flaws   │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│   CAPA DE DATOS (Persistencia)                                  │
│   • Bases de datos       • Object storage    • Caches           │
│   Riesgos: Data exposure, insufficient encryption, access issues│
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│   CAPA DE INFRAESTRUCTURA (Compute)                             │
│   • Servidores/VMs       • Containers        • Serverless       │
│   Riesgos: Misconfiguration, unpatched systems, container escape│
└─────────────────────────────────────────────────────────────────┘

Componentes de red y su rol de seguridad

Routers y firewalls

Componente	Función	Control de seguridad
Router	Dirige tráfico entre redes	ACLs, filtrado básico
Firewall L3/L4	Filtra por IP/puerto	Políticas de entrada/salida
Firewall L7 (WAF)	Inspecciona contenido de aplicación	Reglas para SQL injection, XSS
IDS/IPS	Detecta/previene intrusiones	Firmas y anomalías

Topología de red segura

[Internet]
     ↓
[Firewall perimetral] ─── DMZ ─── [WAF] ─── [Reverse Proxy]
     │                                            ↓
     │                                    [Servers públicos]
     │
[Firewall interno]
     │
[Red interna] ─── [Segmentos VLAN]
     │
     ├── [Servidores de aplicación]
     ├── [Servidores de base de datos]
     └── [Gestión/Administración]

Principio de segmentación: Separar redes según nivel de confianza y función. Un compromiso en una zona no compromete las demás.

Direccionamiento y DNS

Concepto	Rol de seguridad
IP privada	No accesible desde Internet directamente
NAT	Oculta estructura interna
DNS	Punto crítico; DNS spoofing puede redirigir tráfico
DNSSEC	Firma criptográfica de registros DNS

Sistemas operativos y seguridad

Capas de seguridad del SO

Capa	Función	Controles
Kernel	Acceso a hardware, procesos	Parches, hardening, secure boot
Control de acceso	Permisos de archivos	DAC, MAC (SELinux/AppArmor)
Procesos	Aislamiento de aplicaciones	Sandboxing, containers
Usuarios	Identidad y privilegios	Autenticación, sudo, least privilege

Hardening de sistemas

Sistema	Medidas básicas de hardening
Linux	Deshabilitar servicios innecesarios, firewall (iptables/nftables), fail2ban, actualizaciones automáticas
Windows	Group policies, Windows Defender, BitLocker, deshabilitar SMBv1
Containers	Non-root user, read-only filesystem, recursos limitados, imágenes base mínimas

Arquitecturas cloud y sus implicaciones

Modelo de responsabilidad compartida

Modelo	Tú controlas	El provider controla
IaaS	SO, apps, datos, identidad	Hardware, virtualización, red física
PaaS	Apps, datos, identidad	SO, runtime, middleware
SaaS	Datos, identidad de usuarios	Todo lo demás

Servicios cloud y seguridad

Servicio	Riesgos principales	Controles
Compute (EC2, VMs)	Misconfiguration, unpatched	Hardening, patch management, security groups
Storage (S3, Blob)	Public buckets, no encryption	Bucket policies, encryption at rest
Databases (RDS)	Public access, weak auth	VPC isolation, IAM auth, encryption
Serverless (Lambda)	Injection, over-permissive roles	Input validation, minimal IAM
Kubernetes	Misconfig, exposed APIs	RBAC, network policies, secrets management

Configuraciones críticas en cloud

# Ejemplo: S3 bucket seguro
resource "aws_s3_bucket" "secure_bucket" {
  bucket = "my-secure-bucket"
 
  # Bloquear acceso público
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
 
  # Cifrado por defecto
  server_side_encryption_configuration {
    rule {
      apply_server_side_encryption_by_default {
        sse_algorithm = "AES256"
      }
    }
  }
 
  # Versionado para recuperación
  versioning {
    enabled = true
  }
}

Internet of Things (IoT)

Características de seguridad

Aspecto	Desafío	Mitigación
Recursos limitados	No soportan cifrado fuerte	Protocolos ligeros (DTLS), gateway seguro
Actualizaciones	Difícil aplicar parches	OTA updates seguras, firmware firmado
Credenciales	Defaults, hardcoded	Provisioning seguro, rotación
Comunicación	Protocolos inseguros	Segmentación de red, monitoreo

Arquitectura IoT segura

[Dispositivos IoT]
      ↓ (segmento aislado)
[Gateway IoT] ─── [Broker MQTT/TLS]
      ↓
[Firewall/NAC]
      ↓
[Backend/Cloud] ─── [Dashboard]

Principios:

Dispositivos IoT NUNCA en la red principal
Gateway como punto de control y traducción
Monitoreo de comportamiento anómalo
Inventario actualizado de dispositivos

Flujo de una petición web (análisis de seguridad)

Cuando un usuario accede a una aplicación:

1. [Browser] ──HTTPS──> [CDN/WAF]
   Controles: HSTS, certificate validation
   Riesgos: Certificate spoofing, downgrade attacks

2. [CDN/WAF] ──────────> [Load Balancer]
   Controles: DDoS mitigation, WAF rules
   Riesgos: Bypass de WAF, rate limiting evasion

3. [Load Balancer] ────> [Web Server]
   Controles: Health checks, session persistence
   Riesgos: Server exhaustion, session hijacking

4. [Web Server] ───────> [Application]
   Controles: Input validation, auth/authz
   Riesgos: Injection, broken access control

5. [Application] ──────> [Database]
   Controles: Parameterized queries, encryption
   Riesgos: SQL injection, data exposure

6. [Database] ─────────> [Storage]
   Controles: Encryption at rest, backups
   Riesgos: Unauthorized access, data loss

Mapeo de superficie de ataque

Proceso de identificación

Enumerar componentes: Servidores, servicios, endpoints
Identificar entradas: APIs, formularios, archivos, protocolos
Mapear flujos de datos: Dónde se almacenan, transmiten, procesan
Clasificar por exposición: Internet, intranet, solo backend
Priorizar por riesgo: Criticidad de datos × probabilidad de ataque

Matriz de superficie de ataque

Componente	Exposición	Entradas	Datos manejados	Prioridad
API pública	Internet	JSON, headers	PII, credenciales	Alta
Admin panel	VPN only	Formularios	Config, usuarios	Alta
Base de datos	Solo app servers	SQL	Todos los datos	Crítica
S3 bucket	Configuración	Archivos	Documentos	Media

Caso de estudio: Facebook outage (2021)

Incidente: Facebook, Instagram y WhatsApp caídos 6 horas.

Causa técnica:

Cambio de configuración BGP retiró rutas de Facebook de Internet
Sistemas internos dependían de DNS interno
DNS interno dependía de la red que falló
Ingenieros no podían acceder remotamente (VPN dependía de la red)
Acceso físico a data centers requería badges que… dependían de la red

Fallas de diseño:

Dependencia circular (circular dependency)
Sin mecanismo de acceso out-of-band
Cambio de configuración sin rollback automático
Testing insuficiente del cambio

Lecciones para ingenieros:

Identificar dependencias circulares en arquitectura
Mantener acceso out-of-band para emergencias
Probar cambios en entornos aislados
Tener mecanismos de rollback automático

Conceptos clave

Término	Definición
Superficie de ataque	Todos los puntos donde un atacante puede interactuar con el sistema
Segmentación	Dividir la red en zonas con diferentes niveles de confianza
DMZ	Segmento de red que expone servicios a Internet aislado de la red interna
Defensa en profundidad	Múltiples capas de controles para proteger activos
Hardening	Proceso de reducir superficie de ataque en un sistema
IaC	Gestión de infraestructura mediante código versionado

Ponte a prueba

Mapeo de arquitectura: Dibuja el diagrama de arquitectura de una aplicación de e-commerce típica (frontend, API, base de datos, pagos). Identifica al menos 5 superficies de ataque y un control para cada una.
Análisis de dependencias: En el caso de Facebook, identifica las dependencias circulares. ¿Cómo rediseñarías la arquitectura para evitar este tipo de falla?
Segmentación: Un hospital tiene: sistemas de historiales médicos, equipos de diagnóstico (IoT), estaciones de trabajo, y acceso WiFi para visitantes. Diseña una arquitectura de red segmentada que limite el impacto de un compromiso en cualquier zona.
Cloud security: Una startup migra su aplicación monolítica a AWS usando EC2, RDS y S3. Crea una lista de verificación de seguridad con al menos 10 controles específicos que deben implementar.

Laboratorio práctico: Análisis de tráfico y seguridad de infraestructura

Tiempo estimado: 150 minutos Requisitos: Wireshark, Docker, nmap, terminal con acceso root/sudo Ética: Solo analizar tráfico de tu propia red y sistemas autorizados

Objetivo

Desarrollar habilidades prácticas de análisis de infraestructura: capturar y analizar tráfico de red, identificar servicios expuestos, y configurar controles de seguridad.

Parte 1: Captura y análisis de tráfico con Wireshark (40 min)

Wireshark permite inspeccionar tráfico de red en detalle.

Preparación

# Instalar Wireshark (si no está instalado)
# Debian/Ubuntu:
sudo apt install wireshark
# Fedora:
sudo dnf install wireshark
 
# Permitir captura sin root
sudo usermod -aG wireshark $USER
# Cerrar sesión y volver a iniciar

Ejercicio 1.1: Capturar tráfico HTTP vs HTTPS

Abre Wireshark y selecciona tu interfaz de red
Inicia captura
En un navegador, visita http://neverssl.com (HTTP inseguro)
Luego visita https://www.google.com (HTTPS)
Detén la captura

Análisis:

# Filtro para ver solo HTTP
http

# Filtro para ver handshake TLS
tls.handshake

# Filtro para seguir una conversación TCP
tcp.stream eq 0

Preguntas:

En el tráfico HTTP, ¿puedes ver el contenido de la página?
En el tráfico HTTPS, ¿qué información puedes ver?
¿Por qué HTTPS no oculta el dominio de destino?

Ejercicio 1.2: Analizar autenticación insegura

Ejecuta un servidor vulnerable para pruebas:

# Crear servidor HTTP básico con login
docker run -d --name insecure-login -p 8080:80 httpd:alpine
 
# O usar Python para un servidor simple
mkdir /tmp/webtest && cd /tmp/webtest
echo '<form method="POST" action="/login">
  <input name="user" placeholder="Usuario">
  <input name="pass" type="password" placeholder="Contraseña">
  <button>Login</button>
</form>' > index.html
python3 -m http.server 8080

Captura tráfico en Wireshark (filtro: tcp.port == 8080)
En el navegador, ve a http://localhost:8080
Ingresa credenciales ficticias
Busca las credenciales en la captura

Filtro Wireshark:

http.request.method == "POST"

Documenta: ¿Cómo aparecen las credenciales en el tráfico HTTP sin cifrar?

Ejercicio 1.3: Detectar escaneo de puertos

En una terminal, ejecuta un escaneo nmap mientras capturas:

# En terminal 1: Captura de Wireshark activa
 
# En terminal 2: Escaneo de tu localhost
nmap -sS -p 1-1000 localhost

Análisis en Wireshark:

# Filtrar SYN scan
tcp.flags.syn == 1 && tcp.flags.ack == 0

# Ver resumen de conexiones
Statistics → Conversations → TCP

Documenta:

¿Cuántas conexiones se iniciaron?
¿Cómo se ve un escaneo SYN en el tráfico?
¿Cómo detectarías esto en un IDS?

Parte 2: Reconocimiento de servicios con Nmap (30 min)

Nmap es la herramienta estándar para descubrimiento de red.

Ejercicio 2.1: Escaneo de servicios locales

# Ver servicios en tu máquina local
nmap -sV localhost
 
# Escaneo detallado con scripts
nmap -sC -sV -p- localhost
 
# Guardar resultados en formato XML
nmap -sV -oX scan_results.xml localhost

Interpreta la salida:

¿Qué puertos están abiertos?
¿Qué servicios y versiones se detectan?
¿Algún servicio no debería estar expuesto?

Ejercicio 2.2: Crear entorno vulnerable

Despliega una aplicación multi-contenedor para analizar:

# docker-compose.yml para entorno de práctica
cat > docker-compose.yml << 'EOF'
version: '3'
services:
  web:
    image: nginx:alpine
    ports:
      - "80:80"
    networks:
      - frontend
 
  api:
    image: python:3.9-alpine
    command: python -m http.server 5000
    ports:
      - "5000:5000"
    networks:
      - frontend
      - backend
 
  db:
    image: mysql:8
    environment:
      MYSQL_ROOT_PASSWORD: password123
    ports:
      - "3306:3306"  # ¡INSEGURO! Solo para práctica
    networks:
      - backend
 
  redis:
    image: redis:alpine
    ports:
      - "6379:6379"  # ¡INSEGURO! Solo para práctica
    networks:
      - backend
 
networks:
  frontend:
  backend:
EOF
 
docker-compose up -d

Escaneo del entorno:

# Escanear todos los servicios
nmap -sV -p 80,5000,3306,6379 localhost

Análisis de seguridad:

¿Cuáles de estos servicios deberían ser públicos?
¿Qué riesgos presenta exponer MySQL y Redis?
¿Cómo modificarías el docker-compose para mejorar la seguridad?

Ejercicio 2.3: Detección de vulnerabilidades

# Usar scripts NSE de vulnerabilidades
nmap --script vuln localhost
 
# Scripts específicos
nmap --script mysql-info -p 3306 localhost
nmap --script redis-info -p 6379 localhost

Parte 3: Configuración de firewall (35 min)

Ejercicio 3.1: Reglas básicas con iptables/nftables

# Ver reglas actuales
sudo iptables -L -n -v
 
# Crear reglas básicas (ejecutar con cuidado)
# Permitir loopback
sudo iptables -A INPUT -i lo -j ACCEPT
 
# Permitir conexiones establecidas
sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
 
# Permitir SSH (puerto 22)
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
 
# Permitir HTTP/HTTPS
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT
 
# Denegar el resto (¡CUIDADO! Puede bloquearte)
# sudo iptables -A INPUT -j DROP
 
# Ver reglas
sudo iptables -L -n --line-numbers

Alternativa con UFW (más simple):

# Instalar UFW si no está
sudo apt install ufw  # Debian/Ubuntu
sudo dnf install ufw  # Fedora
 
# Configurar reglas básicas
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh
sudo ufw allow http
sudo ufw allow https
 
# Ver status
sudo ufw status verbose
 
# NO habilitar durante el lab a menos que sepas lo que haces
# sudo ufw enable

Ejercicio 3.2: Crear política de firewall

Diseña reglas de firewall para el entorno Docker anterior:

# Objetivo: Solo web (80) debe ser público
# API (5000) solo accesible desde web
# DB (3306) y Redis (6379) solo accesibles desde API
 
# Ejemplo de reglas (conceptual)
# -A INPUT -p tcp --dport 80 -j ACCEPT
# -A INPUT -p tcp --dport 5000 -s 172.18.0.0/16 -j ACCEPT  # Solo red Docker
# -A INPUT -p tcp --dport 3306 -s 172.18.0.0/16 -j ACCEPT
# -A INPUT -p tcp --dport 6379 -s 172.18.0.0/16 -j ACCEPT
# -A INPUT -p tcp --dport 5000 -j DROP  # Denegar desde otros
# -A INPUT -p tcp --dport 3306 -j DROP
# -A INPUT -p tcp --dport 6379 -j DROP

Documenta:

Lista de reglas propuestas
Justificación de cada regla
Orden de las reglas (importante en iptables)

Parte 4: Análisis de logs de seguridad (25 min)

Ejercicio 4.1: Parsear logs de acceso

# Generar tráfico al servidor web
for i in {1..20}; do curl -s http://localhost/ > /dev/null; done
curl http://localhost/admin  # 404
curl http://localhost/../../../etc/passwd  # Intento de path traversal
 
# Ver logs del contenedor nginx
docker logs insecure-web 2>&1 | tail -20

Script de análisis de logs:

# log_analyzer.py
import re
from collections import Counter
 
def parse_nginx_log(log_file):
    """Analiza logs de nginx buscando patrones sospechosos."""
 
    suspicious_patterns = [
        r'\.\./',                    # Path traversal
        r'/etc/passwd',              # File access attempt
        r'union.*select',            # SQL injection
        r'<script',                  # XSS attempt
        r'/admin',                   # Admin access
        r'/wp-admin|/phpmyadmin',    # Known admin paths
    ]
 
    status_codes = Counter()
    suspicious_requests = []
 
    with open(log_file, 'r') as f:
        for line in f:
            # Extraer código de status
            match = re.search(r'" (\d{3}) ', line)
            if match:
                status_codes[match.group(1)] += 1
 
            # Buscar patrones sospechosos
            for pattern in suspicious_patterns:
                if re.search(pattern, line, re.IGNORECASE):
                    suspicious_requests.append(line.strip())
                    break
 
    return status_codes, suspicious_requests
 
# Uso
if __name__ == "__main__":
    # Guardar logs a archivo primero
    # docker logs insecure-web > /tmp/nginx.log 2>&1
 
    codes, suspicious = parse_nginx_log('/tmp/nginx.log')
 
    print("=== Códigos de status ===")
    for code, count in codes.most_common():
        print(f"  {code}: {count}")
 
    print("\n=== Requests sospechosos ===")
    for req in suspicious[:10]:  # Primeros 10
        print(f"  {req[:100]}...")

Ejercicio 4.2: Detección de fuerza bruta

# Simular intentos de login fallidos (contra tu servidor de prueba)
for i in {1..50}; do
    curl -s -X POST http://localhost:8080/login \
         -d "user=admin&pass=wrong$i" > /dev/null
done
 
# Analizar patrón en logs
docker logs [container] 2>&1 | grep POST | wc -l

Criterios de detección:

Más de N intentos fallidos desde misma IP en M minutos
Acceso a rutas administrativas sin autenticación
Patrones de user-agent automatizados

Parte 5: Reto integrador - Auditoría de seguridad (20 min)

Realiza una auditoría completa del entorno Docker desplegado:

Checklist de auditoría:

Área	Verificación	Estado	Hallazgo
Puertos	¿Solo los necesarios están expuestos?
Credenciales	¿Hay credenciales por defecto?
Cifrado	¿El tráfico está cifrado?
Versiones	¿Hay software desactualizado?
Logs	¿Se registran eventos de seguridad?
Acceso	¿Hay servicios sin autenticación?

Ejecuta:

# 1. Escaneo de puertos
nmap -sV -p- localhost
 
# 2. Verificar credenciales por defecto
mysql -h localhost -u root -ppassword123 -e "SELECT 1"  # ¿Funciona?
redis-cli -h localhost ping  # ¿Sin auth?
 
# 3. Captura de tráfico
# Wireshark mientras haces requests
 
# 4. Revisar configuraciones
docker inspect [container]
 
# 5. Analizar logs
docker logs [container]

Entregable

Crea un reporte de auditoría de infraestructura que incluya:

Resumen ejecutivo (1 página)
- Alcance de la auditoría
- Principales hallazgos
- Nivel de riesgo general
Análisis de tráfico
- Capturas de Wireshark relevantes (screenshots)
- Credenciales o datos sensibles encontrados
- Tráfico sin cifrar identificado
Escaneo de servicios
- Tabla de puertos y servicios descubiertos
- Servicios innecesariamente expuestos
- Versiones vulnerables detectadas
Configuración de firewall propuesta
- Lista de reglas recomendadas
- Diagrama de segmentación de red
- Justificación de cada regla
Hallazgos y recomendaciones
- Clasificación por severidad (Crítico/Alto/Medio/Bajo)
- Recomendación específica para cada hallazgo
- Priorización de remediación

Criterios de evaluación

Criterio	Puntos
Análisis de tráfico completo	20
Escaneo de servicios documentado	20
Política de firewall propuesta	20
Análisis de logs	15
Calidad del reporte de auditoría	15
Recomendaciones técnicamente correctas	10

Limpieza

# Detener y eliminar contenedores de prueba
docker-compose down
docker rm -f insecure-login 2>/dev/null
 
# Limpiar reglas de iptables (si las agregaste)
sudo iptables -F

Reflexión

Después de completar el laboratorio:

¿Qué tan fácil fue encontrar información sensible en tráfico sin cifrar?
¿Cómo cambiaría tu perspectiva sobre redes WiFi públicas después de este laboratorio?
¿Por qué es crítico tener visibilidad del tráfico de red para detectar intrusiones?

Navegación: ← Anterior | Inicio | Siguiente: Evaluación final →

Quartz 4

Explorer

10 - Panorama tecnológico