Configuración Segura de IPtables para Asterisk PBX 20 en AlmaLinux 9

La seguridad de un servidor Asterisk PBX es crítica, ya que representa un objetivo frecuente para atacantes que buscan realizar fraude telefónico, ataques de denegación de servicio o comprometer la infraestructura de comunicaciones. En este artículo configuraremos IPtables en AlmaLinux 9 para proteger un servidor Asterisk mientras mantenemos la funcionalidad completa del sistema.

Puertos Necesarios para Asterisk

Antes de comenzar, es fundamental comprender qué puertos utiliza Asterisk y por qué:

  • Puerto 5060/UDP: Señalización SIP sin cifrar
  • Puerto 5061/TCP: Señalización SIP con TLS (cifrado)
  • Puertos 20000-30000/UDP: RTP (Real-time Transport Protocol) para el flujo de audio/vídeo

Arquitectura de Seguridad

Nuestra configuración implementará defensa en profundidad con múltiples capas:

  1. Política por defecto restrictiva (DROP)
  2. Protección contra ataques de fuerza bruta
  3. Mitigación de ataques DDoS/DoS
  4. Rate limiting específico para tráfico VoIP
  5. Logging de actividad sospechosa

Configuración Paso a Paso

1. Limpieza y Políticas Iniciales

Primero, limpiamos cualquier regla existente y establecemos políticas restrictivas:

#!/bin/bash
# Script de configuración IPtables para Asterisk PBX
# AlmaLinux 9

# Limpiar reglas existentes
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X

# Política por defecto: denegar todo
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

¿Por qué política DROP? Al denegar todo el tráfico por defecto, solo permitimos explícitamente lo necesario. Esto reduce drásticamente la superficie de ataque.

2. Tráfico Loopback y Establecido

# Permitir tráfico loopback (necesario para procesos locales de Asterisk)
iptables -A INPUT -i lo -j ACCEPT

# Permitir conexiones ya establecidas y relacionadas
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

El tráfico loopback es esencial porque Asterisk utiliza conexiones locales entre sus módulos internos. Las conexiones establecidas permiten que las respuestas a nuestras peticiones salientes regresen al servidor.

3. Protección contra Ataques Comunes

# Protección contra escaneo de puertos
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP

# Protección contra fragmentación de paquetes
iptables -A INPUT -f -j DROP

# Protección contra IP spoofing
iptables -A INPUT -s 127.0.0.0/8 ! -i lo -j DROP
iptables -A INPUT -s 224.0.0.0/4 -j DROP
iptables -A INPUT -s 240.0.0.0/5 -j DROP

Estas reglas detectan y bloquean paquetes malformados típicos de escaneos automatizados. Los atacantes utilizan estas técnicas para identificar servicios vulnerables sin ser detectados.

4. Protección contra SYN Flood

# Limitar nuevas conexiones TCP para prevenir SYN flood
iptables -A INPUT -p tcp --syn -m conntrack --ctstate NEW -m limit \
    --limit 60/s --limit-burst 100 -j ACCEPT
iptables -A INPUT -p tcp --syn -m conntrack --ctstate NEW -j LOG \
    --log-prefix "SYN flood detected: " --log-level 4
iptables -A INPUT -p tcp --syn -m conntrack --ctstate NEW -j DROP

¿Por qué es importante? Los ataques SYN flood intentan saturar la tabla de conexiones del servidor enviando miles de solicitudes SYN sin completar el handshake TCP. Esto puede dejar fuera de servicio nuestro sistema de telefonía.

5. Protección SSH (Gestión del Servidor)

# Crear cadena para SSH con rate limiting
iptables -N SSH_BRUTEFORCE

# Permitir hasta 3 intentos de conexión por minuto por IP
iptables -A SSH_BRUTEFORCE -m recent --name ssh --set
iptables -A SSH_BRUTEFORCE -m recent --name ssh --update --seconds 60 \
    --hitcount 4 -j LOG --log-prefix "SSH brute force: "
iptables -A SSH_BRUTEFORCE -m recent --name ssh --update --seconds 60 \
    --hitcount 4 -j DROP
iptables -A SSH_BRUTEFORCE -j ACCEPT

# Aplicar protección a puerto SSH (cambiar 22 si usas otro puerto)
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j SSH_BRUTEFORCE

Esta protección es vital porque el acceso SSH comprometido permite al atacante reconfigurar Asterisk, robar credenciales SIP o utilizar el servidor para otros fines maliciosos.

6. Señalización SIP - Puerto 5060/UDP

# Crear cadena personalizada para SIP
iptables -N SIP_TRAFFIC

# Rate limiting agresivo para SIP - previene registration floods
iptables -A SIP_TRAFFIC -m recent --name sip_attempts --set
iptables -A SIP_TRAFFIC -m recent --name sip_attempts --update \
    --seconds 60 --hitcount 30 -j LOG --log-prefix "SIP flood 5060: "
iptables -A SIP_TRAFFIC -m recent --name sip_attempts --update \
    --seconds 60 --hitcount 30 -j DROP

# Limitar paquetes SIP por segundo (ajustar según capacidad del servidor)
iptables -A SIP_TRAFFIC -m limit --limit 100/s --limit-burst 200 -j ACCEPT
iptables -A SIP_TRAFFIC -j DROP

# Aplicar reglas al puerto SIP
iptables -A INPUT -p udp --dport 5060 -j SIP_TRAFFIC

¿Por qué rate limiting tan estricto? Los atacantes realizan "registration floods" intentando miles de registros SIP por segundo para saturar Asterisk o realizar ataques de fuerza bruta contra extensiones. Un servidor típico no necesita más de 100 paquetes SIP legítimos por segundo.

7. Señalización SIP Cifrada - Puerto 5061/TCP

# Crear cadena para SIP-TLS
iptables -N SIPS_TRAFFIC

# Rate limiting para SIP-TLS (más permisivo que UDP por naturaleza de TCP)
iptables -A SIPS_TRAFFIC -m recent --name sips_attempts --set
iptables -A SIPS_TRAFFIC -m recent --name sips_attempts --update \
    --seconds 60 --hitcount 50 -j LOG --log-prefix "SIP-TLS flood: "
iptables -A SIPS_TRAFFIC -m recent --name sips_attempts --update \
    --seconds 60 --hitcount 50 -j DROP

# Protección contra SYN flood específica para SIP-TLS
iptables -A SIPS_TRAFFIC -p tcp --syn -m limit --limit 30/s -j ACCEPT
iptables -A SIPS_TRAFFIC -p tcp --syn -j DROP

iptables -A SIPS_TRAFFIC -m limit --limit 100/s --limit-burst 150 -j ACCEPT
iptables -A SIPS_TRAFFIC -j DROP

# Aplicar al puerto 5061
iptables -A INPUT -p tcp --dport 5061 -j SIPS_TRAFFIC

El tráfico cifrado requiere protección adicional contra SYN floods ya que el establecimiento de la conexión TLS consume más recursos del servidor que SIP sin cifrar.

8. Puertos RTP para Media - 20000-30000/UDP

# Crear cadena para tráfico RTP
iptables -N RTP_TRAFFIC

# Rate limiting para RTP (más permisivo - es tráfico de audio/vídeo continuo)
iptables -A RTP_TRAFFIC -m recent --name rtp_flood --set
iptables -A RTP_TRAFFIC -m recent --name rtp_flood --update \
    --seconds 10 --hitcount 1000 -j LOG --log-prefix "RTP flood detected: "
iptables -A RTP_TRAFFIC -m recent --name rtp_flood --update \
    --seconds 10 --hitcount 1000 -j DROP

# Limitar nuevas "conexiones" RTP por segundo
iptables -A RTP_TRAFFIC -m conntrack --ctstate NEW -m limit \
    --limit 100/s --limit-burst 200 -j ACCEPT

# Permitir RTP establecido sin límite (es tráfico de voz activo)
iptables -A RTP_TRAFFIC -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Aplicar al rango de puertos RTP
iptables -A INPUT -p udp --dport 20000:30000 -j RTP_TRAFFIC

¿Por qué límites más altos para RTP? El tráfico RTP es continuo durante una llamada activa. Un codec G.711 genera aproximadamente 50 paquetes por segundo por llamada. Con 50 llamadas simultáneas necesitamos permitir 2,500 paquetes/segundo legítimamente.

9. ICMP - Ping Controlado

# Permitir ICMP echo request (ping) con rate limiting
iptables -A INPUT -p icmp --icmp-type echo-request -m limit \
    --limit 5/s --limit-burst 10 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -j DROP

# Permitir otros mensajes ICMP necesarios
iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT
iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT

Limitamos ping para prevenir flood mientras mantenemos la capacidad de diagnóstico de red. Los mensajes ICMP de error son necesarios para el correcto funcionamiento de TCP/IP.

10. Logging de Tráfico Bloqueado

# Log de paquetes bloqueados (últimas reglas antes del DROP final)
iptables -A INPUT -m limit --limit 5/min -j LOG \
    --log-prefix "IPtables INPUT dropped: " --log-level 4

# La política DROP ya está establecida, pero podemos hacerla explícita
iptables -A INPUT -j DROP

El logging nos permite detectar patrones de ataque y ajustar nuestras reglas. Limitamos la frecuencia de logs para evitar saturar /var/log/messages.

Hardening Adicional del Kernel

Complementamos IPtables con configuraciones del kernel Linux:

# Editar /etc/sysctl.conf o crear /etc/sysctl.d/99-asterisk-security.conf

# SYN cookies - protección contra SYN flood
net.ipv4.tcp_syncookies = 1

# Reducir el tiempo de espera de conexiones medio-abiertas
net.ipv4.tcp_max_syn_backlog = 2048
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 3

# Protección contra IP spoofing
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# No aceptar source routing
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0

# No aceptar ICMP redirects
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.default.secure_redirects = 0

# No enviar ICMP redirects
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0

# Log de paquetes sospechosos
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.default.log_martians = 1

# Ignorar broadcasts ICMP
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Protección contra bad ICMP error messages
net.ipv4.icmp_ignore_bogus_error_responses = 1

Aplicar cambios:

sysctl -p

¿Por qué necesitamos esto además de IPtables? Estas configuraciones operan a nivel de kernel, antes de que IPtables procese los paquetes. Proporcionan una capa adicional de defensa y optimizan el rendimiento al descartar tráfico malicioso más temprano en la pila de red.

Persistencia de Reglas

En AlmaLinux 9, las reglas IPtables no persisten automáticamente después de un reinicio:

# Guardar configuración actual
iptables-save > /etc/sysconfig/iptables

# Habilitar servicio iptables para que cargue al iniciar
systemctl enable iptables
systemctl start iptables

Si prefieres usar firewalld (el firewall por defecto en AlmaLinux 9), puedes convertir estas reglas, pero personalmente recomiendo IPtables para servidores VoIP por su control granular y menor overhead.

Script Completo de Configuración

He consolidado todas las reglas en un script ejecutable:

#!/bin/bash
# iptables-asterisk-secure.sh
# Configuración segura de IPtables para Asterisk PBX
# AlmaLinux 9

# Verificar que se ejecuta como root
if [ "$EUID" -ne 0 ]; then
    echo "Este script debe ejecutarse como root"
    exit 1
fi

echo "[*] Limpiando reglas existentes..."
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X

echo "[*] Estableciendo políticas por defecto..."
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

echo "[*] Configurando reglas básicas..."
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

echo "[*] Aplicando protección contra ataques comunes..."
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
iptables -A INPUT -f -j DROP
iptables -A INPUT -s 127.0.0.0/8 ! -i lo -j DROP
iptables -A INPUT -s 224.0.0.0/4 -j DROP
iptables -A INPUT -s 240.0.0.0/5 -j DROP

echo "[*] Configurando protección SYN flood..."
iptables -A INPUT -p tcp --syn -m conntrack --ctstate NEW -m limit \
    --limit 60/s --limit-burst 100 -j ACCEPT
iptables -A INPUT -p tcp --syn -m conntrack --ctstate NEW -j LOG \
    --log-prefix "SYN flood detected: " --log-level 4
iptables -A INPUT -p tcp --syn -m conntrack --ctstate NEW -j DROP

echo "[*] Configurando protección SSH..."
iptables -N SSH_BRUTEFORCE
iptables -A SSH_BRUTEFORCE -m recent --name ssh --set
iptables -A SSH_BRUTEFORCE -m recent --name ssh --update --seconds 60 \
    --hitcount 4 -j LOG --log-prefix "SSH brute force: "
iptables -A SSH_BRUTEFORCE -m recent --name ssh --update --seconds 60 \
    --hitcount 4 -j DROP
iptables -A SSH_BRUTEFORCE -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j SSH_BRUTEFORCE

echo "[*] Configurando SIP (5060/UDP)..."
iptables -N SIP_TRAFFIC
iptables -A SIP_TRAFFIC -m recent --name sip_attempts --set
iptables -A SIP_TRAFFIC -m recent --name sip_attempts --update \
    --seconds 60 --hitcount 30 -j LOG --log-prefix "SIP flood 5060: "
iptables -A SIP_TRAFFIC -m recent --name sip_attempts --update \
    --seconds 60 --hitcount 30 -j DROP
iptables -A SIP_TRAFFIC -m limit --limit 100/s --limit-burst 200 -j ACCEPT
iptables -A SIP_TRAFFIC -j DROP
iptables -A INPUT -p udp --dport 5060 -j SIP_TRAFFIC

echo "[*] Configurando SIP-TLS (5061/TCP)..."
iptables -N SIPS_TRAFFIC
iptables -A SIPS_TRAFFIC -m recent --name sips_attempts --set
iptables -A SIPS_TRAFFIC -m recent --name sips_attempts --update \
    --seconds 60 --hitcount 50 -j LOG --log-prefix "SIP-TLS flood: "
iptables -A SIPS_TRAFFIC -m recent --name sips_attempts --update \
    --seconds 60 --hitcount 50 -j DROP
iptables -A SIPS_TRAFFIC -p tcp --syn -m limit --limit 30/s -j ACCEPT
iptables -A SIPS_TRAFFIC -p tcp --syn -j DROP
iptables -A SIPS_TRAFFIC -m limit --limit 100/s --limit-burst 150 -j ACCEPT
iptables -A SIPS_TRAFFIC -j DROP
iptables -A INPUT -p tcp --dport 5061 -j SIPS_TRAFFIC

echo "[*] Configurando RTP (20000-30000/UDP)..."
iptables -N RTP_TRAFFIC
iptables -A RTP_TRAFFIC -m recent --name rtp_flood --set
iptables -A RTP_TRAFFIC -m recent --name rtp_flood --update \
    --seconds 10 --hitcount 1000 -j LOG --log-prefix "RTP flood detected: "
iptables -A RTP_TRAFFIC -m recent --name rtp_flood --update \
    --seconds 10 --hitcount 1000 -j DROP
iptables -A RTP_TRAFFIC -m conntrack --ctstate NEW -m limit \
    --limit 100/s --limit-burst 200 -j ACCEPT
iptables -A RTP_TRAFFIC -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p udp --dport 20000:30000 -j RTP_TRAFFIC

echo "[*] Configurando ICMP..."
iptables -A INPUT -p icmp --icmp-type echo-request -m limit \
    --limit 5/s --limit-burst 10 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -j DROP
iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT
iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT

echo "[*] Configurando logging de tráfico bloqueado..."
iptables -A INPUT -m limit --limit 5/min -j LOG \
    --log-prefix "IPtables INPUT dropped: " --log-level 4
iptables -A INPUT -j DROP

echo "[*] Guardando configuración..."
iptables-save > /etc/sysconfig/iptables

echo "[*] Habilitando servicio iptables..."
systemctl enable iptables 2>/dev/null || echo "Servicio iptables ya habilitado"

echo ""
echo "======================================"
echo "Configuración completada exitosamente"
echo "======================================"
echo ""
echo "Reglas activas:"
iptables -L -n -v --line-numbers
echo ""
echo "Para ver logs en tiempo real:"
echo "  tail -f /var/log/messages | grep -E 'SIP|RTP|SSH|SYN'"

Guarda el script y hazlo ejecutable:

chmod +x iptables-asterisk-secure.sh
./iptables-asterisk-secure.sh

Monitoreo y Ajuste

Después de implementar estas reglas, es fundamental monitorear su efectividad:

Verificar Reglas Activas

# Ver todas las reglas con contadores
iptables -L -n -v --line-numbers

# Ver reglas de cadenas personalizadas
iptables -L SIP_TRAFFIC -n -v
iptables -L RTP_TRAFFIC -n -v

Monitorear Logs en Tiempo Real

# Ver intentos de ataque bloqueados
tail -f /var/log/messages | grep -E 'SIP flood|RTP flood|SSH brute|SYN flood'

# Estadísticas de eventos de seguridad
grep -E 'SIP flood|RTP flood|SSH brute' /var/log/messages | \
    awk '{print $5}' | sort | uniq -c | sort -rn

Ajustar Límites según Carga Real

Monitorea el uso real durante 1-2 semanas y ajusta los límites:

# Ver conexiones activas por puerto
netstat -an | grep -E '5060|5061|:2[0-9]{4}' | wc -l

# Ver paquetes por segundo aproximados
iptables -L SIP_TRAFFIC -n -v -x | grep 'pkts'

Si observas muchos paquetes legítimos siendo bloqueados, incrementa los límites gradualmente.

Consideraciones de Seguridad Adicionales

Esta configuración de IPtables es solo una capa de tu estrategia de seguridad. También debes:

  1. Fail2ban: Implementar fail2ban específicamente configurado para Asterisk
  2. Listas blancas: Si conoces las IPs de tus proveedores SIP, permítelas explícitamente
  3. Autenticación fuerte: Contraseñas complejas para extensiones SIP
  4. Actualización: Mantén Asterisk y AlmaLinux actualizados
  5. Monitoreo CDR: Revisa regularmente los Call Detail Records buscando patrones anómalos
  6. Segmentación: Coloca Asterisk en una VLAN separada si es posible

Troubleshooting Común

Problema: Llamadas se cortan después de 30-60 segundos

# Verificar que conntrack no está descartando sesiones RTP
cat /proc/sys/net/netfilter/nf_conntrack_udp_timeout
# Aumentar si es necesario
echo 180 > /proc/sys/net/netfilter/nf_conntrack_udp_timeout

Problema: No se pueden registrar teléfonos

# Verificar que SIP_TRAFFIC está aceptando paquetes
iptables -L SIP_TRAFFIC -n -v

# Ver en logs qué se está bloqueando
tail -50 /var/log/messages | grep SIP

Problema: Tabla de conexiones llena

# Aumentar tamaño de tabla conntrack
echo 65536 > /proc/sys/net/netfilter/nf_conntrack_max

# Hacer permanente en sysctl.conf
echo "net.netfilter.nf_conntrack_max = 65536" >> /etc/sysctl.conf

Conclusión

Esta configuración proporciona protección robusta contra los ataques más comunes dirigidos a servidores Asterisk PBX, incluyendo:

  • Floods de registro SIP
  • Ataques de fuerza bruta contra extensiones
  • DDoS/DoS a nivel de red y aplicación
  • Escaneo de puertos y fingerprinting
  • Explotación de vulnerabilidades del stack TCP/IP

Los límites configurados son conservadores y adecuados para la mayoría de implementaciones pequeñas a medianas (hasta 100 llamadas simultáneas). Para instalaciones más grandes, ajusta los valores de rate limiting proporcionalmente a tu capacidad y carga esperada.

Recuerda que la seguridad es un proceso continuo: monitorea logs regularmente, mantén el sistema actualizado y ajusta las reglas según evolucionen las amenazas y tu infraestructura.


Nota importante: Antes de aplicar estas reglas en producción, pruébalas en un entorno de desarrollo o durante una ventana de mantenimiento. Un error en la configuración podría bloquear todo el tráfico legítimo.

 

Vota el Articulo: 

Sin votos (todavía)
Evalúa la calidad del articulo
Suscribirse a Comentarios de "Configuración Segura de IPtables para Asterisk PBX 20 en AlmaLinux 9" Suscribirse a VozToVoice - Todos los comentarios