Seguridad en Redes: Fundamentos de Defensa Perimetral y Monitorización

Fundamentos de Seguridad en Redes

La seguridad en redes es la práctica de proteger la infraestructura de comunicaciones de accesos no autorizados, mal uso, modificación o denegación de servicio. Es la primera línea de defensa en cualquier arquitectura de ciberseguridad.

La defensa perimetral cobra especial relevancia en un panorama donde el ransomware y las campañas de phishing avanzado proliferan sin control. Según el informe Verizon DBIR 2025, el 82% de las brechas involucran un factor humano, pero la mayoría de estos ataques podrían haberse mitigado con una correcta segmentación perimetral. Un firewall perimetral bien configurado no solo filtra tráfico entrante y saliente, sino que establece un punto de control centralizado donde se pueden aplicar políticas de seguridad consistentes en toda la organización.

En entornos corporativos, la red perimetral actúa como la primera barrera frente a escaneos automatizados, exploits de día cero y campañas de reconnaissance. Herramientas como Shodan y Censys indexan millones de dispositivos expuestos públicamente, por lo que cualquier servicio mal configurado se convierte en un objetivo inmediato. La defensa perimetral, combinada con buenas prácticas de hardening, reduce drásticamente la superficie de ataque visible desde Internet.

Modelo de Defensa en Profundidad

La estrategia más efectiva es la defensa en capas (Defense in Depth):

Internet
    │
[Firewall Perimetral]
    │
[DMZ — Zona Desmilitarizada]
    │  ├── Servidores Web
    │  ├── Mail Gateway
    │  └── DNS externo
[Firewall Interno]
    │
[Red Corporativa]
    │  ├── VLAN Usuarios
    │  ├── VLAN Servidores
    │  ├── VLAN IoT
    │  └── VLAN Administración
[IDS/IPS]
[SIEM]

Firewalls: Tipos y Configuración

Firewall de Paquetes (Packet Filtering)

Opera en capa 3-4. Examina cabeceras IP/TCP/UDP:

# Ejemplo con iptables (Linux)
# Política por defecto: DROP
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# Permitir tráfico establecido y relacionado
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Permitir SSH solo desde red interna
iptables -A INPUT -p tcp --dport 22 -s 192.168.1.0/24 -j ACCEPT

# Permitir HTTP/HTTPS
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Guardar reglas
iptables-save > /etc/iptables/rules.v4

Firewall de Aplicación (WAF)

Opera en capa 7. Examina el contenido HTTP:

# Ejemplo: ModSecurity con Nginx
modsecurity on;
modsecurity_rules_file /etc/nginx/modsec/main.conf;

DMZ: Diseño y Configuración

La Zona Desmilitarizada (DMZ) es un segmento de red aislado que alberga los servicios expuestos públicamente, actuando como colchón entre la red interna y la Internet pública. Existen dos arquitecturas principales:

DMZ de firewall dual (arquitectura segura): Utiliza dos firewalls independientes. El firewall externo filtra el tráfico entrante de Internet hacia la DMZ, y el firewall interno controla el tráfico entre la DMZ y la red interna. Incluso si un atacante compromete un servidor en la DMZ, el firewall interno le impide acceder directamente a los recursos internos.

DMZ de firewall único con interfaces separadas: Emplea un solo firewall con tres zonas: externa, DMZ e interna. Es más económico pero ofrece un solo punto de fallo. Adecuada para pequeñas empresas con presupuestos ajustados.

# Ejemplo: DMZ con iptables en firewall dual
# Firewall externo — permite solo HTTP/HTTPS/DNS a la DMZ
iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 80 -d 10.0.1.10 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 443 -d 10.0.1.10 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -p udp --dport 53 -d 10.0.1.20 -j ACCEPT

# Denegar todo lo demás desde Internet
iptables -A FORWARD -i eth0 -j DROP

# Firewall interno — DMZ solo puede acceder a bases de datos internas
iptables -A FORWARD -i eth1 -o eth2 -s 10.0.1.0/24 -p tcp --dport 3306 -d 10.0.2.50 -j ACCEPT
iptables -A FORWARD -i eth1 -j DROP

Un error común es colocar servidores de correo o CRM directamente en la red interna. Si el servidor es comprometido, el atacante obtiene acceso lateral inmediato a toda la infraestructura. La DMZ obliga al atacante a superar una segunda barrera de firewall antes de alcanzar datos sensibles.

Segmentación de Red con VLANs

Las VLANs (Virtual LANs) permiten segmentar lógicamente la red para:

• Contener el movimiento lateral en caso de compromiso
• Aplicar políticas de acceso diferenciadas
• Mejorar el rendimiento reduciendo dominios de broadcast

# Configuración básica de VLANs en Cisco
Switch(config)# vlan 10
Switch(config-vlan)# name USUARIOS
Switch(config)# vlan 20
Switch(config-vlan)# name SERVIDORES
Switch(config)# vlan 30
Switch(config-vlan)# name IOT
Switch(config)# vlan 99
Switch(config-vlan)# name ADMINISTRACION

# Asignar puerto a VLAN
Switch(config)# interface fastethernet 0/1
Switch(config-if)# switchport mode access
Switch(config-if)# switchport access vlan 10

IDS/IPS: Detección y Prevención de Intrusiones

Snort — IDS/IPS Open Source

# Instalación en Ubuntu/Debian
apt install snort

# Regla básica: detectar escaneo Nmap
alert tcp any any -> $HOME_NET any (msg:"Possible Nmap Scan"; flags:S; threshold:type both, track by_src, count 20, seconds 60; sid:1000001;)

# Regla: detectar SQL injection básico
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"SQL Injection attempt"; content:"' OR '1'='1"; nocase; sid:1000002;)

# Ejecutar Snort en modo IDS
snort -A console -q -c /etc/snort/snort.conf -i eth0

Afinación de Reglas y Reducción de Falsos Positivos

Una de las mayores dificultades operativas de un IDS/IPS es el volumen de falsos positivos. Las reglas genéricas generan cientos de alertas diarias que desgastan al equipo de seguridad y ocultan incidentes reales. Para afinar el motor de detección:

1. Suprimir reglas obsoletas. Desactiva reglas que generan alertas en tráfico legítimo conocido. Por ejemplo, la regla ET MALWARE puede dispararse por actualizaciones legítimas de software. Usa disabled en Snort o comenta la regla en suricata.yaml.

2. Ajustar umbrales con threshold. Evita alertar por un solo paquete. Usa threshold:type limit, track by_src, count 5, seconds 60 para alertar solo cuando una IP realiza más de 5 intentos en un minuto.

3. Excluir IPs internas conocidas. Si tu scaner de vulnerabilidades (Nessus, OpenVAS) genera falsas alarmas de escaneo, exclúyelo explícitamente:

   # Excluir Nessus del tracking de escaneos
   alert tcp !10.0.2.100 any -> $HOME_NET any (msg:"Nmap Scan"; flags:S; threshold:type both, track by_src, count 20, seconds 60; sid:1000001;)
   

4. Revisar logs de correlación. Suricata con eve.json permite exportar alertas a un SIEM. Revisa periódicamente qué reglas generan más volumen y decide si desactivarlas, reescribirlas o subir su severidad.

Suricata — Alternativa moderna

# suricata.yaml — configuración básica
vars:
  address-groups:
    HOME_NET: "[192.168.0.0/16,10.0.0.0/8]"
    EXTERNAL_NET: "!$HOME_NET"

outputs:
  - eve-log:
      enabled: yes
      filetype: regular
      filename: /var/log/suricata/eve.json
      types:
        - alert:
            metadata: yes
        - http:
            extended: yes
        - dns
        - tls

Monitorización de Red con Zeek (antes Bro)

Zeek es un framework de análisis de tráfico de red que genera logs estructurados:

# Analizar archivo pcap
zeek -r captura.pcap

# Logs generados:
# conn.log — todas las conexiones
# http.log — tráfico HTTP
# dns.log — consultas DNS
# ssl.log — sesiones TLS/SSL
# files.log — archivos transferidos

# Buscar conexiones a IP sospechosa
cat conn.log | zeek-cut id.orig_h id.resp_h duration | grep "192.168.100.5"

Análisis de Tráfico con Wireshark

Filtros útiles para análisis de seguridad:

# Tráfico no cifrado con credenciales
http contains "password"
ftp.request.command == "PASS"

# Escaneos de puertos
tcp.flags.syn==1 && tcp.flags.ack==0

# Comunicaciones C2 posibles
http.request.method == "POST" && http.content_length > 1000

# DNS tunneling (muchas queries, payloads largos)
dns.qry.name.len > 50

# Beaconing (intervalos regulares)
ip.addr == 192.168.1.100 && tcp.dstport == 443

Monitorización y Respuesta a Incidentes

La defensa perimetral sin monitorización continua es como tener un candado sin cámara de seguridad: sabes que cerraste, pero no sabes quién intentó entrar. Un SIEM (Security Information and Event Management) centraliza logs de firewalls, IDS/IPS, servidores y estaciones de trabajo en una sola plataforma para correlacionar eventos y detectar patrones de ataque.

Integración con SIEM

Las herramientas más comunes en entornos open source son Wazuh (basado en ELK Stack) y Security Onion, que integran Suricata, Zeek y Kibana en una distribución unificada.

# wazuh-agent.conf — envío de logs de Suricata al SIEM
<localfile>
  <log_format>json</log_format>
  <location>/var/log/suricata/eve.json</location>
</localfile>

# Envío de logs de firewall
<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/syslog</location>
</localfile>

En Kibana, crea dashboards que muestren en tiempo real:

• Volumen de alertas IDS por severidad (alta, media, baja)
• Top 10 de IPs origen con más alertas — identifica escaneos persistentes
• Flujos anómalos — picos de tráfico fuera del horario laboral
• Tasa de conexiones fallidas — posible fuerza bruta en cours

Flujo de Respuesta a Incidentes

Cuando el SIEM genera una alerta crítica, el equipo debe seguir un flujo estructurado:

1. Detección y clasificación. El SIEM categoriza la alerta según severidad. Una alerta de severity 1 (crítica) activa el protocolo inmediato.
2. Contención. Bloquea la IP origen en el firewall perimetral. Si se sospecha un host comprometido internamente, aíslalo en una VLAN de contención usando NAC o cambios dinámicos de VLAN.
3. Erradicación. Identifica la causa raíz: ¿fue un exploit, credenciales comprometidas, malware? Ejecuta análisis con YARA y Volatility en las máquinas afectadas.
4. Recuperación. Restaura servicios desde backups verificados y monitoriza intensivamente las 72 horas siguientes.
5. Lecciones aprendidas. Documenta el incidente, actualiza reglas del IDS y refuerza políticas de firewall según las vulnerabilidades explotadas.

Escenario real: En 2024, una empresa europea detectó un movimiento lateral mediante DNS tunneling gracias a alertas de Suricata con la regla ET POLICY DNS Query to Suspicious TLD. El atacante había comprometido un servidor web en la DMZ y exfiltraba datos a través de consultas DNS codificadas en base64. La respuesta fue automatizada: el SIEM ejecutó un playbook de SOAR que bloqueó el dominio C2 y aisló el servidor en 4 minutos.

Zero Trust y Defensa Perimetral Moderna

El modelo tradicional de defensa perimetral asume que todo lo que está "dentro" de la red es confiable. Zero Trust rompe esta premisa: asume que la red ya está comprometida y verifica cada acceso de forma continua.

En un entorno Zero Trust, el firewall perimetral sigue siendo relevante pero se complementa con:

• Microsegmentación: En lugar de confiar en VLANs amplias, cada workload tiene su propio perímetro. Un atacante que compromete el servidor web no puede acceder al servidor de bases de datos sin autorización explícita.
• Autenticación continua: No basta con autenticarse una vez al conectarse a VPN. Cada petición de servicio debe validar identidad, dispositivo y contexto (ubicación, hora, comportamiento).
• Least privilege aplicado a red: Las reglas de firewall se aplican a nivel de identidad, no de IP. Un usuario de RRHH no puede acceder a la red de desarrollo, independientemente de su ubicación física.

# Ejemplo: microsegmentación con iptables + certificados
# Solo permite acceso al servidor de DB desde el app server con certificado
iptables -A FORWARD -i eth1 -s 10.0.2.10 -d 10.0.3.50 -p tcp --dport 5432 \
  -m cert --cert-verify --cert-cn "app-server.internal" -j ACCEPT
iptables -A FORWARD -i eth1 -d 10.0.3.50 -p tcp --dport 5432 -j DROP

La combinación de defensa perimetral clásica con principios Zero Trust crea una postura de seguridad resiliente: el firewall filtra el ruido externo, mientras que la microsegmentación y la verificación continua limitan el daño cuando un control falla.

Checklist de Hardening de Red

[ ] Deshabilitar protocolos inseguros (Telnet, FTP, HTTP sin TLS)
[ ] Habilitar NTP con autenticación para sincronización de logs
[ ] Implementar 802.1X para autenticación de dispositivos en red
[ ] Configurar Port Security en switches para evitar MAC flooding
[ ] Habilitar BPDU Guard contra ataques de Spanning Tree
[ ] Implementar DHCP Snooping contra DHCP spoofing
[ ] Configurar Dynamic ARP Inspection (DAI)
[ ] Separar VLAN de administración del tráfico de usuarios
[ ] Monitorizar con NetFlow/sFlow para análisis de flujos
[ ] Centralizar logs en SIEM (ELK Stack, Splunk, Wazuh)

Recursos Adicionales

• SANS Internet Stormcast: alertas diarias de amenazas de red
• Emerging Threats: reglas para Snort/Suricata actualizadas
• Shodan Monitor: alertas cuando tus IPs aparecen en Shodan

Artículos Relacionados

• Nmap: Guía de Escaneo de Redes — Escanea y mapea tu infraestructura de red con Nmap
• Qué es Zero Trust (Confianza Cero) — Arquitectura de confianza cero más allá del firewall perimetral
• Threat Hunting y Blue Team — Caza de amenazas activa en tu red corporativa
• Firewall: Qué es, Tipos y Cómo Configurar uno — Tipos de firewall, iptables, pfSense y WAF

🔧 Herramienta relacionada: Aprende a usar [Wireshark] paso a paso en nuestra guía completa de herramientas.