Mitigation DDoS pour reseaux IRC

Le premier DDoS que j'ai subi sur un serveur IRC, c'etait un SYN flood de 200 Mbps en 2006. Le serveur avait une connexion de 100 Mbps. Il n'y avait rien a faire cote serveur — le lien reseau etait sature avant que les paquets n'atteignent l'IRCd. J'ai appele l'hebergeur, qui a null-route l'IP. Le serveur est reste hors-ligne 6 heures. Depuis, j'ai appris que la defense DDoS pour IRC ne se fait pas au niveau de l'application — elle se fait au niveau de l'infrastructure.

Types d'attaques

Les attaques contre les reseaux IRC se categorisent en trois niveaux :

• Application layer (L7) : Connection floods, channel floods, message floods. L'attaquant se connecte legitimement et abuse le protocole. Ces attaques sont gerees par l'IRCd.
• Transport layer (L4) : SYN floods, TCP RST attacks. L'attaquant envoie du trafic TCP malformé pour saturer la pile reseau du serveur. Gerees par le firewall et l'OS.
• Volumetrique (L3) : UDP floods, amplification DNS/NTP/memcached. L'attaquant sature le lien reseau avec un volume brut de trafic. Gerees par l'hebergeur ou un service de scrubbing.

La plupart des administrateurs IRC se concentrent sur L7 (parce que c'est ce qu'ils controlent) et ignorent L3/L4 (parce que c'est "le probleme de l'hebergeur"). C'est une erreur. Une strategie de defense complete couvre les trois couches.

Connection flood

L'attaque la plus commune contre un serveur IRC : ouvrir des centaines de connexions par seconde pour epuiser les ressources du serveur.

# Defense cote IRCd (UnrealIRCd) :
set {
  anti-flood {
    # Limiter les connexions par IP :
    connect-flood 3:60;  # Max 3 connexions en 60 secondes
    # Delai de handshake :
    handshake-timeout 30;  # 30 sec max pour s'enregistrer
    # Throttle global :
    unknown-flood-amount 4096;
    unknown-flood-bantime 120;
  };

  # Connexions max par IP :
  max-unknown-connections-per-ip 3;
};

# Defense cote IRCd (InspIRCd) :




# Defense cote firewall (iptables) :
# Limiter les nouvelles connexions TCP :
iptables -A INPUT -p tcp --dport 6697 \
  -m conntrack --ctstate NEW \
  -m recent --set --name IRC
iptables -A INPUT -p tcp --dport 6697 \
  -m conntrack --ctstate NEW \
  -m recent --update --seconds 60 --hitcount 5 --name IRC \
  -j DROP

# Limiter les SYN par IP :
iptables -A INPUT -p tcp --dport 6697 --syn \
  -m hashlimit --hashlimit-above 3/min \
  --hashlimit-burst 5 \
  --hashlimit-mode srcip \
  --hashlimit-name irc_syn \
  -j DROP

# fail2ban pour les echecs d'authentification :
# /etc/fail2ban/jail.d/ircd.conf
[ircd]
enabled = true
port = 6667,6697
filter = ircd
logpath = /home/ircd/unrealircd/logs/ircd.log
maxretry = 5
bantime = 3600

Channel flood

L'attaquant est connecte legitimement et envoie un volume massif de messages dans un canal pour le rendre inutilisable.

# Defense : modes de canal
/MODE #canal +f [5t#b]:10
# UnrealIRCd : 5 messages en 10 secondes -> ban auto

/MODE #canal +j 3:30
# InspIRCd : max 3 joins en 30 secondes

/MODE #canal +m
# Mode modere : seuls les +v et +o peuvent parler
# Solution d'urgence pendant un flood actif

# Bots de moderation :
# Les bots anti-flood reagissent plus vite qu'un humain.
# Ils detectent le pattern et bannissent automatiquement.

# Configuration type pour un bot anti-flood :
# - Seuil : 5 messages en 3 secondes = kick + ban 10min
# - Repetition : 3 messages identiques en 60 sec = warn
# - Mass highlight : message avec 5+ nicks = kick
# - Majuscules : message 100% caps > 10 chars = warn

# Mode +R (enregistres seulement) :
/MODE #canal +R
# Seuls les utilisateurs enregistres NickServ peuvent parler.
# Efficace car les bots de flood n'ont generalement pas
# de comptes enregistres. Inconvenient : bloque les visiteurs.

Attaques volumetriques

Quand l'attaque depasse la capacite de votre lien reseau, aucune solution logicielle ne suffit. Le trafic sature le lien avant d'atteindre votre serveur.

• Null route : L'hebergeur "trou noir" l'IP attaquee. Le trafic malveillant est absorbe, mais votre serveur est aussi inaccessible. C'est la solution la plus simple mais la moins utile — l'attaquant gagne.
• Scrubbing : Le trafic passe par un centre de nettoyage qui filtre le trafic malveillant et laisse passer le trafic legitime. OVH Anti-DDoS, Cloudflare Spectrum, Akamai Prolexic. C'est la solution moderne.
• Anycast : L'IP du serveur est annoncee depuis plusieurs points de presence. Le trafic se distribue geographiquement, diluant l'attaque. Efficace mais complexe a mettre en place pour IRC.

# Cloudflare Spectrum pour IRC :
# Cloudflare Spectrum peut proxifier du trafic TCP
# (pas seulement HTTP). Il filtre le DDoS et relaie
# le trafic propre vers votre serveur.

# Configuration (via l'API Cloudflare) :
# POST /zones/{zone_id}/spectrum/apps
# {
#   "protocol": "tcp/6697",
#   "dns": {"type": "CNAME", "name": "irc.votredomaine.com"},
#   "origin_direct": ["tcp://ip.reelle.du.serveur:6697"],
#   "tls": "full",
#   "ip_firewall": true,
#   "proxy_protocol": "v1"
# }

# Inconvenient : les utilisateurs voient l'IP de Cloudflare,
# pas leur vraie IP. Proxy Protocol (v1 ou v2) resout ce
# probleme si votre IRCd le supporte.

# UnrealIRCd supporte Proxy Protocol :
# listen { options { proxy-protocol; }; };

# OVH Anti-DDoS (automatique si vous etes chez OVH) :
# Filtre volumetrique actif en permanence.
# Pas de configuration cote serveur.
# Efficace contre la majorite des attaques < 1 Tbps.

Pour les organisations qui gerent une infrastructure IRC en production, la mise en place d'une protection DDoS multi-couche est un investissement necessaire. Des prestataires specialises en infrastructure IT comme PowerITi peuvent auditer votre architecture et deployer les protections adaptees a votre profil de risque.

DNSBL et filtrage

# DNSBL (DNS-based Blackhole List) :
# Le serveur verifie l'IP de chaque connexion
# entrante dans des listes noires.

# UnrealIRCd :
blacklist dronebl {
  dns {
    name dnsbl.dronebl.org;
    type record;
    reply { 3; 5; 6; 7; 8; 9; 10; 11; 12; 13; 14; 15; };
  };
  action zline;
  ban-time 1h;
  reason "Votre IP est listee dans DroneBL";
};

blacklist efnetrbl {
  dns {
    name rbl.efnetrbl.org;
    type record;
    reply { 1; 4; 5; };
  };
  action zline;
  ban-time 1h;
  reason "Votre IP est listee dans EFnet RBL";
};

# InspIRCd :



# Listes recommandees :
# dnsbl.dronebl.org — Proxys ouverts, botnets
# rbl.efnetrbl.org — Specifique IRC
# tor.dnsbl.sectoor.de — Noeuds de sortie Tor

# Note sur Tor :
# Bloquer Tor est un choix politique, pas technique.
# Les utilisateurs legitimes de Tor seront bloques
# avec les abuseurs. Si vous decidez de bloquer Tor,
# proposez un .onion comme alternative.

Architecture resiliente

• Pas de DNS pointant vers un seul serveur : Utilisez le DNS round-robin ou un service GeoDNS pour distribuer les connexions entre plusieurs serveurs. Si un serveur est attaque, retirez-le du DNS.
• Hebergement diversifie : Mettez vos serveurs chez des hebergeurs differents. Un DDoS qui sature un hebergeur ne touche pas les autres.
• Hub cache : Le hub (serveur central qui linke les leafs) ne devrait pas accepter de connexions clients. Son IP n'est pas dans le DNS. Les attaquants ne peuvent pas cibler ce qu'ils ne connaissent pas.
• Plans de basculement : Documentez la procedure exacte pour retirer un serveur attaque du DNS, rediriger les utilisateurs vers un autre serveur, et restaurer le service. Testez cette procedure avant d'en avoir besoin.

# Architecture IRC resiliente :
#
#                    [DNS Round-Robin]
#                   irc.votredomaine.com
#                  /         |         \\
#              [Leaf1]    [Leaf2]    [Leaf3]
#              OVH FR     Hetzner DE  Vultr US
#                \\          |          /
#                 [Hub cache - IP non publique]
#                        |
#                   [Services]
#
# Le Hub et les Services ont des IPs non publiques
# (accessible seulement via le reseau interne
# ou un tunnel VPN entre les serveurs).
# Les Leafs sont chez des hebergeurs differents
# avec protection DDoS integree.
# Le DNS pointe vers les Leafs uniquement.