🔍 1. ACLs – Listas de Control de Acceso

🔧 ¿Qué son?

Una ACL (Access Control List) es como un portero con instrucciones específicas: revisa cada paquete que intenta entrar o salir por una interfaz y decide si lo deja pasar o lo detiene.

📜 Estructura general:

plaintextCopiarEditar[permit | deny] protocolo origen [puerto] destino [puerto]

📦 Ejemplo real:

plaintextCopiarEditarpermit tcp 192.168.1.0 0.0.0.255 any eq 80 deny ip any any

  • ✅ Permite tráfico TCP desde 192.168.1.0/24 a cualquier IP destino en el puerto 80.

  • ⛔ Bloquea todo el tráfico restante.

🧠 Alegoría:

Piensa en una ACL como una lista de invitados a un evento exclusivo. Si tu IP no está en la lista de entrada con el puerto correcto (el ticket), el guardia te echa.

🧩 ¿Dónde se aplican?

  • Routers → para filtrar en los límites de red

  • Switches (nivel 3) → control por VLAN

  • Firewalls → forma avanzada de ACL + funcionalidades extra

🔥 2. Firewalls – Guardianes multinivel

🔥 Tipos de firewall

Tipo Nivel OSI > Características

  • Filtro de paquetes Capa 3-4 > ACL básica, rápido pero limitado
  • Stateful Firewall Capa 3-4 con estado > Verifica conexiones existentes
  • NGFW (Next Gen) Capa 7 > DPI, IPS, DLP, control por usuario, apps, etc.

🔐 Ejemplo de reglas firewall:

  • ALLOW TCP from 192.168.1.0/24 to 10.0.0.10 port 443 
  • ALLOW UDP from 10.0.0.0/24 to 8.8.8.8 port 53 DENY all

🎯 Lógica interna:

  • Se evalúan las reglas en orden.

  • Primera coincidencia gana ("first match wins").

  • Si no hay coincidencia: denegación implícita (deny all).

🔐 Firewalls de red vs. personales

Firewall de red -> Protege toda la red -> Ej: pfSense, FortiGate

Firewall personal -> Protege un solo host -> Ej: Windows Defender Firewall

🧿 3. Subred Protegida (DMZ) – El cortafuegos interno

🧱 ¿Qué es una DMZ?

Una zona intermedia entre Internet y tu red interna. Aquí pones servidores expuestos como:

  • Web server

  • Mail server

  • FTP server

  • DNS público

🛡️ Arquitectura típica:

  1. INTERNET
  2. FIREWALL 1
  3. DMZ: web, mail, DNS
  4. FIREWALL 2
  5. RED INTERNA

🚨 ¿Por qué es útil?

Si un atacante compromete un servidor público, aún no tiene acceso directo a tu red interna. Necesitaría evadir un segundo firewall y sus reglas internas.

4. Buenas prácticas y errores comunes

✅ Mejores prácticas:

  • Documentar todas las reglas con justificación y fecha.

  • Aplicar el principio de mínimos privilegios ("solo lo justo y necesario").

  • Usar nombres descriptivos en las reglas.

  • Monitorear y registrar todos los eventos de firewall.

  • Testear reglas nuevas en entornos de prueba o aplicar con cambios temporales.

❌ Errores comunes:

  • Reglas demasiado permisivas (ej: permit ip any any).

  • No tener deny all al final.

  • Permitir protocolos innecesarios como Telnet o FTP.

  • Olvidar bloquear tráfico saliente (importante para prevenir C2).

🌀 Alegoría Purple Team

Imagina que tu red es un castillo medieval:
  • La ACL es el portón donde revisan el pergamino con los nombres.

  • El firewall es la muralla exterior con soldados que analizan cada carro que entra.

  • La DMZ es como el patio del castillo: puedes hablar con los comerciantes allí, pero no los dejas pasar al trono real (tu red interna).

📚 Recurso extra para practicar

  • Cisco Packet Tracer → práctica visual de ACLs y DMZ

  • TryHackMe – "Firewall Security" → entorno simulado

  • Guía de IPTables → para practicar reglas de firewall en Linux

  • Simulación DMZ con máquinas virtuales en VirtualBox o VMware


CURIOSIDADES Y CLAVES ESTRATÉGICAS (Nivel Arquitecta)


🔍 1. Orden lo es todo en una ACL

Las ACL se procesan de arriba hacia abajo y se detienen en la primera coincidencia.

🔐 Esto significa que si colocas una regla más permisiva arriba y una más restrictiva abajo, la segunda jamás se aplicará.

🔥 Clave profesional: Coloca las reglas más específicas arriba y deja las generales (o deny all) al final.


🧱 2. Hay dos tipos de ACL: Estándar vs. Extendida

  • Estándar: Solo filtra por IP de origen.

  • Extendida: Filtra por IP de origen, destino, puertos y protocolos.

🔥 Clave: Las extendidas te dan control quirúrgico. Úsalas para reglas más precisas (como permitir solo HTTP a un servidor específico).


🔄 3. Las ACL pueden aplicarse en entrada o salida

  • Entrada (inbound): Antes de que el paquete entre a la interfaz.

  • Salida (outbound): Antes de que el paquete salga por la interfaz.

💡 Pro Tip: Filtra lo antes posible. Aplicar ACLs de entrada reduce carga de procesamiento.


🌐 4. No todas las reglas de firewall aplican igual en entornos IPv4 e IPv6

Las ACLs deben adaptarse a ambos protocolos. Algunas herramientas y firewalls requieren crear reglas duplicadas para cada stack.

🎯 Pro: Siempre incluye una política para tráfico IPv6, incluso si no lo estás usando activamente.


🧬 5. Las ACL también pueden implementarse en switches

Los switches Capa 3 (como Cisco Catalyst) pueden aplicar ACLs para limitar el tráfico entre VLANs, sin necesidad de un router o firewall externo.


🔄 6. Las ACL no tienen memoria de conexión (stateless)

Esto significa que:

  • Permitir tráfico de salida no implica que se permita la respuesta entrante.

🔥 Solución: Tienes que crear una regla adicional para permitir la respuesta... O usar un firewall stateful que lo maneje automáticamente.


⚔️ 7. DMZ no significa "totalmente expuesta"

Una DMZ no es una zona sin reglas. ¡Debe tener sus propios firewalls y reglas restrictivas!

🔥 Buen diseño: La DMZ solo permite tráfico estrictamente necesario. Por ejemplo:

  • HTTP/HTTPS → Web server

  • SMTP → Mail server

  • DNS → DNS público

Nada más.


🕵️ 8. La DMZ también se usa para honeypots

Muchos equipos Purple Team colocan honeypots y canary tokens en la DMZ para:

  • Detectar movimientos laterales.

  • Observar técnicas de reconocimiento.

  • Atraer atacantes lejos de los sistemas reales.


🧠 9. Los firewalls Next-Gen pueden identificar usuarios, no solo IPs

Con tecnologías como LDAP, Active Directory o SAML, los firewalls modernos pueden aplicar reglas no solo por IP, sino por nombre de usuario o grupo.

💥 Ejemplo: Bloquear acceso a redes sociales para el grupo "Internos" Permitir acceso SSH solo a "Admins"


🧪 10. Simula ataques para validar tus reglas

Un firewall o ACL mal configurado puede dejar puertas abiertas sin que lo sepas. Herramientas como:

  • 🧰 Infection Monkey

  • 🧰 Nmap + NSE Scripts

  • 🧰 Firewall Analyzer (ManageEngine)

  • 🧰 FireHOL Testing

Te permiten simular tráfico malicioso y validar la cobertura de tus reglas.


🟣 MENTALIDAD PURPLE TEAM

No basta con "crear reglas". Un buen Purple Team:
  • 🔴 Piensa como atacante: ¿qué protocolos podría explotar?

  • 🔵 Piensa como defensor: ¿cómo segmento, registro y bloqueo?

  • 🟣 Integra ambos enfoques: automatiza reglas, monitoriza intentos, mejora visibilidad y aprende de cada incidente.


🎓 BONUS MASTER

🛡️ ¿Sabías que puedes "entrenar" tu firewall?

Con ciertas plataformas (como FortiGate, pfSense + Snort/Suricata, Palo Alto) puedes:

  1. Activar modo aprendizaje: observa el tráfico por unos días.

  2. Generar un perfil con el comportamiento normal.

  3. Aplicar reglas restrictivas basadas en ese perfil.

Esto se llama Whitelisting adaptativo y es brutal para seguridad defensiva.


ANÁLISIS Y USO ESTRATÉGICO COMO ARQUITECTA DE SEGURIDAD

🔐 1. ACLs como filtro quirúrgico de tráfico

Las Access Control Lists no son solo reglas de "permitir o bloquear". Son bisturís que permiten:

  • Filtrar tráfico entre redes internas y DMZ.

  • Controlar flujos laterales entre VLANs.

  • Restringir movimientos horizontales de malware o atacantes.

Recomendación Purple:

  • Diseña las ACL desde el enfoque Zero Trust: nadie entra ni sale sin justificación técnica clara.

  • Usa nomenclatura clara para reglas (ej: ACL-VLAN10-WEB-IN-ALLOW-HTTP80).

🔥 2. Firewalls: núcleo de tu arquitectura defensiva

Tu firewall es como el portón de un castillo, pero también puede ser un guardian inteligente:

Diseños óptimos:

  • Firewall Perimetral: Protege contra amenazas externas.

  • Firewall Interno: Segmenta zonas críticas (ej. servidores, VLANs sensibles, IoT).

  • Firewall Cloud: Si usas entornos híbridos o en la nube, aplica también controles virtuales (ej. AWS Security Groups, NSGs de Azure).

Recomendación Purple:

  • Implementa reglas mínimas de entrada/salida (principio de menor privilegio).

  • Integra el firewall con SIEM para alertas en tiempo real.

🌐 3. Subred protegida (DMZ): tu campo de batalla controlado

La DMZ (Demilitarized Zone) es una red expuesta con protección doble. Su diseño te permite ofrecer servicios al exterior sin exponer la red interna.

Ejemplos comunes en una DMZ:

  • Servidores Web públicos.

  • Servidores de correo que reciben correo externo.

  • Honeypots para cazar atacantes.

Diseño clásico:

[Internet] ↓ 

[Firewall 1] → [DMZ] → [Firewall 2] → [Red Interna]

Firewall 1: Solo permite acceso a servicios públicos.
Firewall 2: Solo permite tráfico controlado hacia recursos internos.

Recomendación Purple:

  • Usa un IDS/IPS dentro de la DMZ.

  • No reutilices contraseñas de producción en entornos expuestos.

  • Monitoriza constantemente con SIEM + alertas.

📐 4. Recomendaciones Avanzadas de Arquitectura

Elemento Buenas prácticas de diseño Purple Team

  • ACLs Separación por interfaces (IN/OUT), uso de etiquetas, comentarios claros.
  • Firewalls Zonas segmentadas (prod/dev/IoT/DMZ), reglas por perfil de riesgo.
  • DMZ Doble firewall, acceso mínimo, auditorías constantes.
  • Documentación Todo cambio se registra, testea, valida y documenta.

💡 Claves para integrarlo en una arquitectura de seguridad moderna:

  • Usa herramientas como Ansible o Terraform para automatizar la gestión de reglas.

  • Aplica controles de red basados en identidad, no solo en IP.

  • Establece revisiones trimestrales de todas las reglas ACL y de firewall.

  • Simula ataques con herramientas Red Team para probar tu DMZ y ACLs.

🟣 Mentalidad Purple Team aplicada

Como arquitecta Purple:

  • 🧠 Pienso como atacante: ¿Cómo eludiría esta ACL? ¿Qué pasaría si exploto mal una regla mal colocada?

  • 🛡️ Diseño como defensora: ¿Qué mecanismos puedo aplicar en varias capas para detener el ataque?

  • ⚖️ Coordino como estratega: Estableces procedimientos de revisión, automatización y mejora continua.


🟣 PURPLE TEAM LAB – ACLs, Firewalls y Subred Protegida (DMZ)


🔥 EJEMPLO 1 – Nivel Avanzado

Ataque: Escaneo y evasión de ACL mal configurada

🔴 Red Team ataca

Realizo un escaneo de puertos usando técnicas como fragmentación de paquetes, TCP ACK scan y spoofing IP interna para intentar evadir las reglas ACL y descubrir servicios expuestos en la DMZ o la red interna.

🔵 Blue Team defiende

Configuro las ACL con:

  • Denegación explícita de direcciones IP internas en tráfico entrante.

  • Registro de eventos sospechosos (logging).

  • IDS para detectar escaneos con nmap o hping3.

Verifico los logs y activo alertas automáticas en el SIEM.

🟣 Purple Team gestiona

Reviso la lógica de las reglas ACL:

  • Orden correcto de reglas (más específicas primero).

  • Denegación implícita al final.

Realizo un playbook para revisar mensualmente las reglas.
Propongo crear una red de honeypot en la DMZ para detectar y estudiar estos escaneos.


🧨 EJEMPLO 2 – Nivel Experto

Ataque: Pivoting desde DMZ mal segmentada hacia la red interna

🔴 Red Team ataca

Exploto una vulnerabilidad en un servidor FTP expuesto en la DMZ. Uso esa máquina como trampolín para realizar un lateral movement hacia la red interna, abusando de una mala configuración en los firewalls o reglas ACL que permiten tráfico hacia ciertos puertos internos.

🔵 Blue Team defiende

Aplico segmentación avanzada:

  • Firewall entre DMZ e intranet con reglas de "deny all" por defecto.

  • ACLs que impiden cualquier tráfico de la DMZ hacia zonas internas salvo tráfico explícitamente aprobado (ej. logs hacia un SIEM).

Uso EDR y honeypots para detectar actividad inusual en la red interna.

🟣 Purple Team gestiona

Documenta un incidente simulado:

  • Detección → Contención → Erradicación → Recuperación.

Propone:

  • Segmentar aún más la DMZ en microsegmentos por servicio.

  • Monitorizar movimientos laterales con herramientas como Zeek o Wazuh.

  • Revisar las políticas de "defense in depth" aplicadas.


☠️ EJEMPLO 3 – Nivel Maestro

Ataque: Exfiltración encubierta desde la red interna mediante túnel inverso

🔴 Red Team ataca

Tras comprometer una máquina interna, establezco un túnel SSH inverso hacia un servidor en la DMZ usando el puerto 443 (HTTPS), que está permitido en la ACL para navegación. Así, exfiltran datos a través de un canal encubierto cifrado.

🔵 Blue Team defiende

Uso inspección profunda de paquetes (DPI) en el firewall.
Restrinjo el tráfico saliente HTTPS solo hacia destinos específicos.
Implemento alertas de comportamiento anómalo con:

  • Flujos de red inusuales.

  • Túneles persistentes no autorizados.

Utilizo herramientas como Suricata para detectar patrones sospechosos cifrados.

🟣 Purple Team gestiona

Revisa el incidente como:

  1. Falla de diseño → ACL demasiado permisiva.

  2. Falla de detección → No había control sobre salidas cifradas.

Crea una guía de hardening de tráfico saliente:

  • Whitelisting de destinos.

  • Cortafuegos con inspección TLS.

Propone simulaciones anuales de exfiltración encubierta.


👁‍🗨 Mentalidad Purple Team

  • El ataque no comienza en el firewall, sino en cómo se diseñan las reglas.

  • La defensa no es estática: se ajusta, prueba, simula y audita.

  • El Purple Team integra conocimientos ofensivos y defensivos en una gestión cíclica, automatizada y con visión holística.

Purple Mystara - Cristina Martínez Girol
Todos los derechos reservados 2025
Creado con Webnode Cookies
¡Crea tu página web gratis! Esta página web fue creada con Webnode. Crea tu propia web gratis hoy mismo! Comenzar