Mitigacion DDoS en redes IRC

La primera vez que una red IRC que administraba fue atacada con DDoS fue en 2005. Un miercoles a las dos de la tarde. 300 conexiones por segundo desde IPs aleatorias, todas haciendo handshake TCP pero sin completar el registro IRC. El servidor se quedo sin file descriptors en cuatro minutos. Los 400 usuarios legitimos perdieron conexion. No teniamos plan. No teniamos defensa. Teniamos un servidor y un deseo sincero de que parara. No paro solo. Aprendimos.

Tipos de ataque contra redes IRC

Los ataques contra redes IRC se dividen en tres categorias por objetivo:

• Ataques a la conexion: Saturar la capacidad del IRCd de aceptar nuevas conexiones. Connection floods, bot floods, clone attacks. El objetivo es agotar los recursos del servidor (file descriptors, memoria) para que los usuarios legitimos no puedan conectar.
• Ataques al canal: Inundar canales con mensajes, joins/parts rapidos, o cambios de nick masivos. No buscan tumbar el servidor sino hacer inutilizable un canal especifico.
• Ataques volumetricos: Saturar el ancho de banda o la capacidad de red del servidor. Amplificacion DNS, SYN floods, UDP floods. El servidor IRC es irrelevante — el ataque va contra la infraestructura de red.

Cada tipo requiere defensas diferentes. Los primeros dos se mitigan en la configuracion del IRCd. El tercero requiere infraestructura de red externa — tu IRCd no puede defenderse de algo que satura la tuberia antes de llegar a el.

Connection flooding

El connection flood es el ataque mas comun contra servidores IRC. Un atacante abre cientos o miles de conexiones TCP al puerto del IRC. Cada conexion consume un file descriptor y algo de memoria en el IRCd. Cuando el servidor alcanza el limite de file descriptors del sistema operativo, deja de aceptar conexiones — incluyendo las legitimas.

# Defensas a nivel de sistema operativo:

# Aumentar limites de file descriptors:
ulimit -n 65536
# O en /etc/security/limits.conf:
# ircd  soft  nofile  65536
# ircd  hard  nofile  65536

# Limitar conexiones nuevas por segundo con iptables:
iptables -A INPUT -p tcp --dport 6697 -m state --state NEW \
  -m recent --set --name IRC
iptables -A INPUT -p tcp --dport 6697 -m state --state NEW \
  -m recent --update --seconds 60 --hitcount 3 --name IRC \
  -j DROP
# Maximo 3 conexiones nuevas por IP por minuto

# Limitar conexiones simultaneas por IP:
iptables -A INPUT -p tcp --dport 6697 \
  -m connlimit --connlimit-above 5 -j REJECT
# Maximo 5 conexiones simultaneas por IP

# SYN cookies (contra SYN flood):
sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_max_syn_backlog=4096

A nivel del IRCd, las defensas incluyen:

# UnrealIRCd — set::anti-flood:
set {
  anti-flood {
    connect-flood 3:60;      /* 3 conexiones por 60s desde misma IP */
    unknown-flood-amount 4096; /* Bytes max de un cliente no registrado */
    unknown-flood-bantime 60; /* Ban temporal 60s si excede */
  };
  max-unknown-connections-per-ip 3;
  handshake-timeout 30;      /* 30s para completar registro */
};

# InspIRCd:


# Envia PING al conectar. Si no responde PONG correctamente, desconecta.
# Esto elimina bots simples que no implementan PING/PONG.

La combinacion de iptables (capa red) + IRCd (capa aplicacion) es efectiva contra la mayoria de connection floods simples. Los floods sofisticados usan botnets con miles de IPs diferentes, lo que anula los limites por-IP. Contra eso, necesitas DNSBL.

Channel flooding

El channel flood busca hacer inutilizable un canal especifico. Variantes:

• Message flood: Enviar cientos de mensajes por segundo al canal.
• Join/part flood: Entrar y salir del canal repetidamente, generando lineas de aviso que ahogan las conversaciones.
• Nick flood: Cambiar de nick continuamente, generando lineas de aviso.
• CTCP flood: Enviar peticiones CTCP (VERSION, PING) masivas que disparan respuestas de todos los clientes.

# Defensas por modo de canal:
MODE #canal +m       # Moderado: solo voice y ops hablan
MODE #canal +R       # Solo usuarios registrados (NickServ)
MODE #canal +f [5t]:10  # UnrealIRCd: anti-flood
  # [5t]:10 = max 5 lineas por 10 segundos, exceso -> ban temporal
  # Variantes: [5j]:15 = max 5 joins por 15s
  #            [10c]:30 = max 10 cambios de nick por 30s

# InspIRCd equivalente:

MODE #canal +f 5:10  # 5 mensajes por 10 segundos

# Protecciones de ChanServ (Anope):
/msg ChanServ SET #canal FLOOD KICKS 5:10
/msg ChanServ SET #canal FLOOD BANS 10:20

El modo +R (solo registrados) es la defensa mas efectiva contra bots de canal. La mayoria de bots de flood no registran nick con NickServ. Si requieres registro para hablar o entrar, eliminas el 90% de los ataques de canal sin afectar a usuarios legitimos (que deberian tener el nick registrado de todas formas).

Ataques volumetricos

Los ataques volumetricos no atacan tu IRCd — atacan tu conexion de red. Un SYN flood de 10 Gbps satura un enlace de 1 Gbps antes de que ningun paquete llegue a tu servidor. Tu IRCd es irrelevante. Tu firewall es irrelevante. La tuberia esta llena.

Las defensas contra volumetricos son externas:

• Cloudflare Spectrum: Proxy TCP que filtra trafico malicioso. Tu servidor IRC esta detras de Cloudflare, los usuarios se conectan a la IP de Cloudflare, y Cloudflare reenvia el trafico limpio. Soporta puertos TCP arbitrarios (6667, 6697). Es la solucion mas accesible pero tiene coste.
• OVH Game DDoS Protection: OVH ofrece proteccion anti-DDoS incluida en sus servidores dedicados. Filtra ataques volumetricos a nivel de red antes de que lleguen a tu servidor. Funciona bien para IRC.
• Null-routing del atacante: Si el ataque viene de un rango de IPs identificable, tu proveedor de hosting puede null-routear esas IPs a nivel de backbone. Eficaz contra ataques dirigidos, inutil contra botnets distribuidas.

La realidad para la mayoria de redes IRC medianas y pequenas: un ataque volumetrico serio es indefendible sin infraestructura de mitigacion de pago. Si tu red es el objetivo de un DDoS volumetrico sostenido, necesitas mover tus servidores detras de un servicio de mitigacion o aceptar el downtime hasta que el atacante se aburra.

Para organizaciones que gestionan infraestructura critica — no solo IRC sino servicios web, email, y aplicaciones — contar con un equipo como PowerITi que pueda evaluar y planificar la arquitectura de mitigacion es una inversion que se justifica al primer ataque que se para.

DNSBL y listas negras

Las DNSBL (DNS-based Blackhole Lists) son listas de IPs conocidas como fuentes de abuso: proxies abiertos, VPNs baratas, nodos de salida de botnets, rangos de hosting usados para ataques. El IRCd consulta estas listas cuando un usuario se conecta y rechaza la conexion si la IP esta listada.

# UnrealIRCd — DNSBL:
set {
  blacklist {
    dronebl {
      dns {
        name dnsbl.dronebl.org;
        type record;
        reply { 2; 3; 5; 6; 7; 8; 9; 10; 11; 12; 13; 14; 15; };
      };
      action zline;
      ban-time 1h;
      reason "Tu IP esta listada en DroneBL. Visita https://dronebl.org/lookup";
    };
    efnetrbl {
      dns {
        name rbl.efnetrbl.org;
        type record;
        reply { 1; 2; 3; 4; 5; };
      };
      action zline;
      ban-time 1h;
      reason "Tu IP esta listada en EFnet RBL.";
    };
  };
};

# InspIRCd:

Las DNSBL mas usadas para IRC:

• DroneBL: La mas completa para IRC. Cubre proxies abiertos, VPNs, botnets, y hosts comprometidos. Actualizada frecuentemente.
• EFnet RBL: Mantenida por la comunidad de EFnet. Orientada especificamente a abuso en IRC.
• Tor exit nodes: tor.dan.me.uk lista nodos de salida de Tor. Util si quieres bloquear acceso desde Tor (controversial pero comun en IRC).

Arquitectura defensiva

Mas alla de la configuracion puntual, la arquitectura de tu red determina su resiliencia:

• Separar hubs de user-facing: Los servidores hub que enlazan la red no deberian aceptar conexiones de usuarios. Solo trafico server-to-server. Esto protege el backbone de ataques dirigidos a puertos de clientes.
• Multiples puntos de entrada: Si tienes un solo servidor que acepta usuarios, un DDoS contra esa IP tumba tu red. Con tres servidores en tres ISPs diferentes, el atacante necesita atacar tres objetivos simultaneamente.
• DNS round-robin o anycast: Publica multiples IPs para tu dominio IRC. Los clientes se distribuyen entre servidores. Si un servidor es atacado, los demas siguen funcionando.
• Fail2ban para IRC: Configura fail2ban para monitorizar los logs del IRCd y banear IPs que generen errores repetidos (passwords incorrectos, intentos de flood).

# fail2ban para UnrealIRCd:
# /etc/fail2ban/filter.d/unrealircd.conf
[Definition]
failregex = .* Client connecting: .* \(\) .*
            .* \(connect\): Invalid password .* \(\)
ignoreregex =

# /etc/fail2ban/jail.d/unrealircd.conf
[unrealircd]
enabled = true
filter = unrealircd
logpath = /home/ircd/unrealircd/logs/ircd.log
maxretry = 5
findtime = 300
bantime = 3600
action = iptables-multiport[name=IRC, port="6667,6697"]