DDoS Protection for IRC: Lessons from Two Decades of Attacks

DALnet lost 80% of its user base to DDoS attacks between 2002 and 2004. The attacks were sustained, massive, and targeted — botnet operators who used IRC for command and control didn't appreciate DALnet's aggressive abuse policies. The network never fully recovered. This is the extreme case, but every IRC network has a DDoS story. Most are less dramatic. Some are worse.

A History of IRC Under Fire

IRC and DDoS have been intertwined since the late 1990s. The reasons are structural. IRC was one of the first widely-used real-time communication platforms, which made it a target for anyone who wanted to disrupt online communities. IRC also served as a command-and-control channel for botnets — compromised machines would connect to an IRC channel and wait for instructions. Network operators who cracked down on botnet C&C channels became targets themselves.

The timeline reads like a casualty report:

• 1998-2000: Early SYN flood attacks against individual servers. Mostly script kiddies targeting rival channels or operators.
• 2001-2003: Organized DDoS campaigns against DALnet, using botnets with thousands of compromised machines. Attacks sustained for weeks.
• 2004-2006: Reflection and amplification attacks emerge. DNS amplification turns small botnets into massive traffic generators. Multiple mid-sized networks go offline permanently.
• 2010-2015: Booter/stresser services make DDoS available to anyone with $10. IRC operators are targeted individually — their home IP addresses obtained through DCC or unprotected connections.
• 2016-present: IoT botnets (Mirai and descendants) generate traffic volumes that overwhelm even well-protected infrastructure. Networks increasingly rely on CDN and anycast solutions.

Attack Types Targeting IRC

Connection flooding: The simplest attack. Open thousands of TCP connections to the IRC port. Each connection consumes server resources (file descriptors, memory for connection state). The server hits its connection limit and legitimate users can't connect.

Bandwidth saturation: Flood the server's network link with traffic. Doesn't matter what the traffic is — UDP garbage, ICMP, TCP SYN packets. If the pipe is full, legitimate traffic can't get through. A server with a 1 Gbps link goes down to a 2 Gbps attack.

Application-layer flooding: Connect to IRC normally, then send malformed or resource-intensive commands. Repeated WHO queries on large channels, rapid JOIN/PART cycles, or nickname changes that trigger expensive operations on the server.

Targeting users directly: If an attacker knows a user's IP address (visible in the default WHOIS response on many networks), they can DDoS the user directly. This was particularly common in gaming communities where DDoS-ing opponents was considered a viable strategy.

IP Cloaking: The First Line of Defense

IP cloaking replaces users' visible hostnames with obfuscated versions. Instead of seeing user@203.0.113.55, other users see something like user@F7A3B2.1C8D4E.IP or user@user.registered.network.org.

UnrealIRCd cloaking configuration:

set {
    cloak-method ip;
    cloak-keys {
        "aoAr1HnR6gl3sJ7hVz4Zb7x4YwpW";
        "and target 2yAaZp7rNFc8";
        "and key 3JfKm4xBv9nQ";
    };
};

InspIRCd uses a module-based approach:

<module name="cloaking">
<cloak mode="full"
      key="random-secret-key-here"
      prefix="irc"
      suffix=".users.example.net">

Cloaking doesn't prevent DDoS attacks against the server itself, but it prevents attackers from obtaining individual users' IP addresses through IRC. This is critical — a user whose IP is exposed can be targeted directly, bypassing any server-side protection.

Connection Throttling and Limits

IRC servers defend against connection flooding through several mechanisms:

# UnrealIRCd throttling configuration
set {
    throttle {
        connections 3;     # max connections
        period 60;         # per this many seconds
    };
    max-connections-per-ip 3;  # simultaneous connections per IP
};

# iptables rate limiting (Linux)
iptables -A INPUT -p tcp --dport 6667 -m state --state NEW   -m recent --set --name IRC
iptables -A INPUT -p tcp --dport 6667 -m state --state NEW   -m recent --update --seconds 60 --hitcount 4 --name IRC -j DROP

The iptables rules above allow 3 new connections per IP per minute. The fourth attempt within 60 seconds is dropped at the kernel level, before it reaches the ircd process. This is significantly more efficient than letting the ircd handle the rejection.

Connection class limits provide another layer. Different connection classes can have different limits:

allow {
    ip *;
    class "default";
    maxperip 2;
};

allow {
    ip 198.51.100.0/24;  # trusted network
    class "trusted";
    maxperip 10;
};

Open Proxy Detection and DNSBL

Many DDoS attacks and abuse incidents on IRC originate from open proxies, VPNs, and compromised hosts. IRC networks use DNS-based blacklists (DNSBLs) to reject connections from known-bad IP addresses before they complete the registration handshake.

# UnrealIRCd DNSBL configuration
blacklist dronebl {
    dns {
        name dnsbl.dronebl.org;
        type record;
        reply { 3; 5; 6; 7; 8; 9; 10; 11; 12; 13; 14; 15; };
    };
    action kill;
    reason "Your IP is listed in DroneBL. Visit https://dronebl.org/lookup?ip=$ip";
};

blacklist efnetrbl {
    dns {
        name rbl.efnetrbl.org;
        type record;
        reply { 1; 4; 5; };
    };
    action kill;
    reason "Your IP is listed in EFnet RBL.";
};

DroneBL and EFnet RBL are the two most commonly used DNSBLs in the IRC community. They maintain lists of open proxies, SOCKS proxies, HTTP proxies, and known botnet nodes. The lookup is fast — a DNS query for each connecting IP — and blocks a significant portion of automated abuse.

Network-Level Mitigation

When application-level defenses aren't enough, IRC networks need network-level protection. Options include:

Upstream filtering: Ask your hosting provider or transit provider to filter attack traffic before it reaches your server. Most providers offer basic null-routing (blocking all traffic to an attacked IP) and some offer more granular filtering. The limitation: null-routing takes your server offline for everyone, not just the attacker.

Dedicated DDoS protection services: Companies like OVH, Path.net, and Voxility offer DDoS-protected hosting or tunnel services. The IRC server sits behind a scrubbing center that filters attack traffic and passes only legitimate connections through. Cost varies from free (OVH's basic protection) to hundreds per month for dedicated scrubbing.

GRE/IP tunnels: Route IRC traffic through a DDoS-protected endpoint via GRE or IPIP tunnels. The protected endpoint's IP is what users see; the actual server's IP is hidden. If the protected IP gets attacked, the scrubbing center handles it. If the server's real IP leaks, the tunnel provides no protection.

The Modern Approach: Anycast and Filtering

Large networks like Libera.Chat use anycast IP addresses. The same IP is announced from multiple locations worldwide. DDoS traffic gets distributed across all announcement points, reducing the impact at any single location. Combined with per-site scrubbing, this provides robust protection against even large-scale attacks.

The smaller networks that make up most of the IRC ecosystem can't afford anycast infrastructure. For them, the practical advice is layered defense:

1. Cloak all user IPs. No exceptions.
2. Use DNSBLs to block known-bad sources.
3. Rate-limit connections at the firewall level.
4. Hide server IPs behind DDoS-protected proxies or tunnels.
5. Have a plan for when the attack exceeds your protection capacity: null-route, wait it out, or migrate.

IRC survived decades of DDoS attacks not through superior technology, but through stubbornness. Volunteer operators rebuilt servers, migrated infrastructure, and kept networks running through attacks that would have shut down commercial services. The servers went down. They came back up. They went down again. They came back up again. That's the IRC way.