Left-4-Dead-2-server beschermen tegen DDoS-aanvallen

Een Left-4-Dead-2-server valt zelden op een gelegen moment uit. Hij valt uit in het laatste deel van een campagne, in de tweede ronde van een versus-match of precies op het moment dat een geblokkeerde speler voor de derde keer is geweigerd. Wie op dat moment onder vuur ligt, heeft geen principiële discussie over netwerktechniek nodig, maar een volgorde. Dit artikel laat eerst zien hoe u een Left-4-Dead-2-server beschermt tegen DDoS-aanvallen zolang dat met eigen middelen nog gaat, daarna waar die mogelijkheden fysiek ophouden, en tot slot wat er ervoor in het netwerk moet gebeuren.

Alle gegevens gaan uit van een dedicated server (srcds), geïnstalleerd via SteamCMD onder app-ID 222860, onder Debian 12, Debian 13, Ubuntu 22.04 LTS of Ubuntu 24.04 LTS. De commando's zijn voor root geschreven; als gewone gebruiker zet u er sudo voor. Eén punt vooraf, omdat het de volgorde bepaalt: verander tijdens een lopende aanval niets op de gok en start de server niet opnieuw op voordat u de meetwaarden hebt vastgelegd. Na de aanval zijn ze weg.

Waarom Left-4-Dead-2-servers een lonend DDoS-doelwit zijn

Het verschil met een shooter met 64 plaatsen zit in de omvang van de ronde. Een coöp-campagne heeft vier plaatsen voor overlevenden, een versus-match acht plaatsen voor beide kanten samen. Een uitval treft daarom nooit losse spelers, maar altijd de hele partij: wie een campagne in het derde van vijf delen afbreekt, heeft de avond voor alle betrokkenen beëindigd. Precies dat maakt een aanval aantrekkelijk voor de veroorzaker, want hij kost hem kunde noch noemenswaardig geld, terwijl hij aan de andere kant een uur speeltijd vernietigt.

Daar komt de bouwwijze bij. Left 4 Dead 2 draait op de Source-engine, en een Source-server is met IP-adres en poort openbaar vindbaar. Dat is een voorwaarde, geen ongelukje: een server die geen opvraging beantwoordt, staat in geen enkele lijst en wordt door geen enkele lobby gevonden. De vraag luidt dus nooit of een aanvaller uw adres kent, maar alleen wat er gebeurt zodra hij erop schiet. Het spelverkeer loopt over UDP, en UDP kent geen verbindingsopbouw die u zou kunnen eisen, daarbij laten afzenderadressen zich vervalsen. Wat daarbij technisch gebeurt, legt het artikel Wat is een DDoS-aanval? uit.

Een derde punt is Left 4 Dead 2 eigen en heeft geen tegenhanger bij Counter-Strike, Garry's Mod of Team Fortress 2: de meeste spelers komen niet via de serverlijst binnen, maar via het lobbysysteem. Een lobby van maximaal vier spelers wordt via de Steam-matchmaking aan een dedicated server toegewezen, die daarvoor een reservering krijgt. Die werkwijze is tegelijk uw effectiefste toegangsfilter en een extra aanvalsoppervlak. Beide staan verderop in detail.

De poorten waar het werkelijk om gaat

Een Left-4-Dead-2-server bezet precies één UDP-poort voor alles wat het spel uitmaakt. Standaard is dat 27015, vastgelegd via -port dan wel +hostport in de startregel:

./srcds_run -game left4dead2 -console -nohltv \
  -port 27015 \
  +ip 203.0.113.10 \
  +maxplayers 4 \
  +exec server.cfg \
  +map c1m1_hotel

De eerste regel van deze tabel is de kern van het probleem. Spelverkeer en serveropvraging delen 27015/UDP, bij Left 4 Dead 2 bestaat er geen aparte query-poort. Wie die poort zonder onderscheid dichtzet of er grof een ratelimiet overheen legt, gooit in dezelfde beweging zijn eigen spelers eruit en maakt de aanval af in het belang van de aanvaller.

Een A2S-verzoek is een pakket van een paar tientallen bytes, het antwoord een veelvoud daarvan. Bij UDP laat het afzenderadres zich vervalsen, en daarmee wordt uw server niet alleen slachtoffer, maar ook versterker: een aanvaller bevraagt vreemde spelservers met het adres van zijn doelwit en stuurt hun antwoorden daarheen. Valve heeft A2S_INFO in december 2020 uitgebreid met een voorgeschakelde uitdaging (S2C_CHALLENGE), die de vrager moet terugsturen voordat hij het antwoord krijgt. Dat verzacht de reflectie, maar beëindigt haar niet, omdat oudere opvraagprogramma's nog steeds worden bediend.

Wat u zelf kunt doen voordat u geld uitgeeft

Het volgende deel kost niets en loont ongeacht waar uw server staat. Het neemt u geen volumetrische aanval uit handen, maar laat kleine en middelgrote aanvallen zonder effect blijven, en het verhelpt de uitval die ten onrechte als DDoS-aanval wordt gemeld.

1. Inventarisatie: wat luistert er werkelijk

Voordat u een regel schrijft, brengt u in kaart welke diensten bereikbaar zijn. Op een Left-4-Dead-2-server die in de loop van de tijd is gegroeid, zijn dat er bijna altijd meer dan verwacht, want naast srcds draaien er vaak nog een webserver voor de campagnes, een statistiekdatabase en soms een tweede server voor versus:

ss -lntup

Alles wat aan 127.0.0.1 of ::1 gebonden is, heeft geen vrijgave nodig. Alles wat op 0.0.0.0 of [::] luistert, is vanaf het internet bereikbaar. Het beeld van de aanvaller levert een poortscan van buitenaf, en dat wijkt ervaringsgewijs af van de eigen verwachting:

nmap -Pn -sU -sT -p 27000-27050,80,443,3306 UW.SERVER.IP.ADRES

Is de onderbouw net opgezet of wilt u hem kunnen narekenen, dan beschrijft het artikel Gameserver met SteamCMD installeren de weg van SteamCMD tot een draaiende srcds.

2. Alleen de poorten openlaten die srcds werkelijk nodig heeft

Eén UDP-poort naar buiten, één TCP-poort voor het eigen adres, meer niet. RCON hoort niet op het open internet, want wie RCON heeft, wisselt de map, blokkeert alle spelers en stopt de server:

ufw allow 27015/udp comment "L4D2 spelpoort en A2S"
ufw allow from 203.0.113.10 to any port 27015 proto tcp comment "RCON"
ufw allow from 203.0.113.10 to any port 22 proto tcp comment "SSH"
ufw default deny incoming
ufw default allow outgoing
ufw --force enable

Vervang 203.0.113.10 door uw eigen adres. Wisselt dat regelmatig, dan loopt de weg via een SSH-poortdoorverwijzing in plaats van via een permanente vrijgave. De volgorde bij het scherp zetten bepaalt of u uzelf buitensluit; die staat, inclusief de weg terug, in het artikel UFW-firewall instellen zonder uzelf buiten te sluiten. Gebeurt het toch: KVM-rootservers en dedicated servers van KernelHost hebben geen IPMI en geen iDRAC, u bereikt de server via de VNC-console in het klantenpaneel, en die hangt niet aan de netwerkstack van het gastsysteem.

3. De A2S-opvraging remmen zonder uit de lobbyzoekopdracht te vallen

Hier ligt de duurste fout binnen dit onderwerp. Omdat spelverkeer en serveropvraging dezelfde poort bezetten, moet de rem onderscheid maken tussen beide pakketklassen, niet tussen poorten.

De Steam-gameserver-onderbouw brengt daarvoor sinds de wijzigingen van december 2020 een eigen begrenzing mee, die vóór de start als omgevingsvariabele wordt gezet. STEAM_GAMESERVER_RATE_LIMIT_200MS=N verwerpt verbindingsloze pakketten (A2S_INFO, A2S_RULES, A2S_PLAYERS) van één afzenderadres zodra er in een venster van 200 milliseconden meer dan N van binnenkomen. Valve noemt 25 tot 75 als bruikbaar bereik, standaard staat de begrenzing uit:

export STEAM_GAMESERVER_RATE_LIMIT_200MS=50
./srcds_run -game left4dead2 -console -port 27015 +exec server.cfg +map c1m1_hotel

In een systemd-unit hoort dezelfde waarde als Environment=STEAM_GAMESERVER_RATE_LIMIT_200MS=50 in het onderdeel [Service], anders is hij na de volgende herstart weg. Deze rem werkt alleen als uw serverbuild de actuele Steamworks-onderbouw meebrengt, en ze beschermt de rekentijd van uw server, niet uw lijn: de pakketten zijn al aangekomen.

Een laag dieper laat hetzelfde verkeer zich in de kernel afsplitsen. Alle verbindingsloze pakketten van de Source-engine, dus serveropvragingen en verbindingsopbouw, beginnen met vier gezette bytes (0xffffffff), het verkeer van al verbonden spelers heeft die kop niet. Precies daarop legt u met nftables een ratelimiet per afzenderadres:

table inet l4d2 {
    chain input {
        type filter hook input priority -10; policy accept;
        udp dport 27015 @th,64,32 0xffffffff \
            meter a2sflood { ip saddr limit rate over 10/second burst 20 packets } drop
    }
}

Het bestand laadt u met nft -f. De prioriteit -10 zorgt ervoor dat de regel eerder werkt dan de filterketen van UFW, en @th,64,32 leest de eerste vier bytes achter de UDP-kop. Begin ruim en zet de grens pas strakker zodra aantoonbaar is dat legitieme opvragingen doorkomen: uw eigen vermelding in de serverlijst hangt daarvan af.

4. Het lobbysysteem als toegangsfilter gebruiken

Dat is de hefboom die alleen Left 4 Dead 2 en zijn voorganger hebben. De server beslist zelf of hij verbindingen van buiten de matchmaking wel of niet aanneemt. Vier directieven in de server.cfg bepalen dat:

sv_allow_lobby_connect_only 1
sv_search_key "uw-eigen-sleutel"
sv_steamgroup "103582791400000000"
sv_steamgroup_exclusive 2

• sv_allow_lobby_connect_only 1 laat uitsluitend toetredingen vanuit een matchmaking-lobby toe. Een connect 203.0.113.10:27015 in de ontwikkelaarsconsole en een Steam-uitnodiging worden geweigerd. De waarde 0 staat beide toe.
• sv_search_key is een vrij te kiezen zoeksleutel. Alleen een lobby waarin dezelfde sleutel is gezet, vindt de server via de matchmaking. Zonder die sleutel duikt hij in de openbare zoekopdracht niet op.
• sv_steamgroup bindt de server aan een Steam-groep en laat hem onder de groepsservers daarvan verschijnen.
• sv_steamgroup_exclusive kent drie standen: 0 laat iedereen toe, 1 gedraagt zich als 0 maar verlangt toetreding via een lobby, en 2 laat alleen nog groepsleden en de rechtstreekse toegang via het IP-adres door.

Voor een vaste community is de combinatie van zoeksleutel en sv_steamgroup_exclusive 2 het effectiefste gratis toegangsfilter dat het spel kent. Een openbare server kan haar niet gebruiken, want een server die niemand vindt, is net zo leeg als een server die offline staat.

En nu het deel dat reclameteksten graag weglaten: deze directieven beschermen uw spellogica, niet uw lijn. Een aanvaller die 27015/UDP overspoelt, wil helemaal niet toetreden. Zijn pakketten worden geweigerd, maar ze zijn wel aangekomen, hebben bandbreedte verbruikt en een gang door de netwerkstack gekost. Tegen een joinflood van wegwerpaccounts werkt sv_allow_lobby_connect_only 1 uitstekend, tegen een booter werkt het helemaal niet.

5. De lobbyreservering en wanneer sv_force_unreserved de betere keuze is

Een lobbyreservering is een in de tijd begrensde bezetting van uw server door een matchmaking-lobby. Zolang zij bestaat, geldt de server voor andere lobby's als vergeven, en zij loopt pas na een tijdje vanzelf af. Voor een server met vier plaatsen is dat een schaarse hulpbron: anders dan bij een shooter met 32 of 64 plaatsen is er heel weinig nodig om een partij te blokkeren.

Wie zijn server niet via de matchmaking draait, haalt dat oppervlak er helemaal uit:

sv_force_unreserved 1
sv_allow_lobby_connect_only 0

sv_force_unreserved 1 zorgt ervoor dat de server niet meer op reserveringsverzoeken uit het lobbysysteem antwoordt en toetredingen met een reserveringskenmerk afwijst. Dezelfde instelling hebt u sowieso nodig als u met L4DToolZ meer dan vier coöp-plaatsen draait, want anders krijgt de lobby een reservering zodra de eerste vier plaatsen bezet zijn, en blijven de overige plaatsen onbereikbaar. De keerzijde is eenduidig: uw spelers komen dan alleen nog via de serverlijst of via connect binnen.

Kies bewust voor een van beide bedrijfsvormen. De mengvorm van half open matchmaking en half open directe toetreding is de variant die beide nadelen verenigt.

6. RCON beveiligen

Een open RCON-poort met een zwak wachtwoord is geen DDoS-probleem, maar een overname. Laat rcon_password nooit leeg en kies nooit iets wat te raden valt, een waarde uit openssl rand -base64 32 volstaat. De Source-titels brengen daarnaast een rem tegen inlogpogingen mee:

rcon_password "HIER_EEN_WILLEKEURIGE_WAARDE"
sv_rcon_minfailures 3
sv_rcon_maxfailures 5
sv_rcon_minfailuretime 30
sv_rcon_banpenalty 1440

Daarmee raakt een adres na drie mislukte pogingen binnen 30 seconden een dag lang geblokkeerd; met find sv_rcon in de serverconsole ziet u welke van deze variabelen uw build kent. De firewallbeperking uit stap 2 blijft toch effectiever, want die laat de poging niet eens tot aan de applicatie door. Hebt u RCON niet nodig, laat het wachtwoord dan leeg: dan luistert het TCP-deel van 27015 niet.

7. Custom-campagnes uitbesteden in plaats van via de spelpoort uitleveren

Custom-campagnes zijn de reden waarom Left 4 Dead 2 na vijftien jaar nog wordt gespeeld, en tegelijk een belastingbron die er bij Counter-Strike in deze vorm niet is. Een campagne is een VPK-pakket met maps, modellen, texturen en geluiden, dus een veelvoud van wat een enkele wedstrijdmap weegt.

De makkelijke weg voor de spelers is de Steam-Workshop: het pakket komt dan van Steam en niet van uw server, en kost u geen bandbreedte. Levert u losse bestanden zelf uit, dan hoort die uitlevering op een webserver en niet op de spelpoort:

sv_allowdownload 1
sv_allowupload 0
sv_downloadurl "https://cdn.example.org/l4d2/"
sv_consistency 1

Bestanden voor sv_downloadurl horen als bzip2-archief op de webserver, uit mijnmap.bsp wordt dus mijnmap.bsp.bz2. Zonder sv_downloadurl stuurt srcds de bestanden zelf over de spelverbinding, en dan geldt: elke verbindingspoging van een nieuwe speler kost u de volledige download, elke afbreking midden in de download eveneens. Dat is een uitgesproken goedkope manier om een lijn te vullen, en ze ziet er in geen enkele statistiek uit als een aanval.

Drie punten daarbij die in de praktijk pijn doen. sv_allowupload 0 hoort gezet te zijn, want uploads van de client naar de server hebt u niet nodig. Staat de webserver voor sv_downloadurl op dezelfde host als het spel, dan delen download en spelverkeer dezelfde lijn en hetzelfde IP-adres, en een aanval op 443/TCP raakt dan ook uw lopende partij. En sv_consistency 1 is geen bescherming tegen aanvallen, maar tegen afwijkende clientbestanden; uitschakelen zou u het alleen moeten als een campagne anders aantoonbaar niet start.

8. SourceMod, Metamod en de uitbreidingen

Een aanzienlijk deel van de als DDoS gemelde uitval is dat helemaal niet. Het zijn crashes en belastingpieken die één enkele client uitlokt, omdat er in de serverbinary of in een uitbreiding een gat openstaat. Daartegen helpt geen bandbreedte, maar onderhoud:

• Houd Metamod:Source en SourceMod passend bij de engineversie. Left 4 Dead 2 krijgt nog steeds updates, en een uitbreiding die niet past, is de meest voorkomende oorzaak van crashes vlak na een update.
• Left4DHooks in plaats van eigen ingrepen. De voor L4D2 typische events liggen in die uitbreiding gebundeld klaar. Eigen ingrepen in dezelfde functies zijn de snelste weg naar een serverbinary die bij bepaalde pakketreeksen uitstapt.
• L4DToolZ alleen bewust inzetten. Die uitbreiding tilt de vast ingebouwde plaatsgrenzen op. Elke extra plaats is een extra speler die rekentijd veroorzaakt, en in combinatie met het lobbysysteem vraagt zij om sv_force_unreserved 1.
• Minder uitbreidingen. Elke plug-in is code in hetzelfde proces. Uitbreidingen met eigen webdiensten openen extra poorten en publiceren vaak precies het adres dat u wilde beschermen.

Blokkades horen permanent te worden weggeschreven, anders zijn ze na de herstart weg. De Source-titels kennen daarvoor banid met writeid plus addip met writeip, en de aangemaakte bestanden worden via exec banned_user.cfg en exec banned_ip.cfg weer ingelezen.

9. Connection tracking en ontvangstbuffer ontlasten

Dit punt wordt vaak over het hoofd gezien en verklaart uitval die op een volume-aanval lijkt, maar het niet is. De kernel maakt voor UDP-verkeer vermeldingen aan in de connection tracking (conntrack), en bij vervalste afzenderadressen levert elk adres een nieuwe vermelding op. Zit de tabel vol, dan verwerpt de kernel pakketten zonder onderscheid: de aanval en uw spelers vliegen er samen uit. Stand en bovengrens toont één blik:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

De meest effectieve stap is om het spelverkeer helemaal niet te laten volgen, want de engine beheert zijn sessies zelf:

table inet raw {
    chain prerouting {
        type filter hook prerouting priority raw; policy accept;
        udp dport 27015 notrack
    }
    chain output {
        type filter hook output priority raw; policy accept;
        udp sport 27015 notrack
    }
}

Met iptables luidt het equivalent iptables -t raw -A PREROUTING -p udp --dport 27015 -j NOTRACK en dezelfde regel voor OUTPUT met --sport. De poort heeft daarna een uitdrukkelijke vrijgave nodig, want zonder tracking werkt geen enkele regel meer die op een bestaande status controleert. Komen pakketten sneller binnen dan srcds ze ophaalt, dan loopt daarnaast de ontvangstbuffer over, en dat ziet er voor de spelers uit als pakketverlies op een vrije lijn:

net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.core.netdev_max_backlog = 16384

Het bestand legt u onder /etc/sysctl.d/ neer en activeert het met sysctl -p. Of de waarden werkelijk nodig zijn, verklapt de kernel zelf: stijgt UdpRcvbufErrors in nstat -az, dan hebben ze zin. Blijft de teller op nul, dan verandert de aanpassing niets. Dit is reserve, geen bescherming.

10. Meten, zodat u tijdens de aanval niet hoeft te gokken

Tijdens een aanval telt vooral deze vraag: hoeveel komt er binnen, op welke poort, en is het opvraag- of spelverkeer. Vier commando's volstaan:

ip -s link show eth0
nstat -az | grep -i udp
sar -n DEV 1 10
tcpdump -ni eth0 -c 200 "udp port 27015 and udp[8:4] = 0xffffffff"

Het eerste commando voert u twee keer uit met tien seconden ertussen, dan hebt u een snelheid in plaats van een absolute waarde. De laatste regel toont uitsluitend de verbindingsloze pakketten, dus precies de soort die een opvraagvloed misbruikt; loopt de teller in enkele seconden vol terwijl er nauwelijks iemand verbonden is, dan hebt u uw antwoord. Houd de opname kort, want ze kost onder belasting zelf rekentijd. Hoe u de waarden inschat, staat in het artikel DDoS-aanval op de server herkennen.

De belangrijkste stap is echter die welke bijna niemand vooraf zet: een vergelijkingsbasis aanleggen zolang alles normaal draait. Zonder normaalwaarde kunt u na een incident niet zeggen of 40.000 pakketten per seconde veel was of gewoon vrijdagavond met een volle versus-server.

Waar deze maatregelen ophouden

Nu het eerlijke deel. Alles wat tot hier is beschreven, werkt pas als de pakketten op uw netwerkkaart zijn aangekomen. Een firewallregel beslist over een pakket dat al over de kabel is gekomen. U kunt het verwerpen, maar u kunt niet terugdraaien dat het verstuurd is.

Rekent u even mee. Een typische gameserver hangt aan 1 Gbit/s, dat komt overeen met 125 megabyte per seconde. Bij de kleinst mogelijke pakketgrootte draagt die lijn ongeveer 1,49 miljoen pakketten per seconde, een lijn van 10 Gbit/s ongeveer 14,88 miljoen. Dat is de fysieke bovengrens, onafhankelijk van CPU, kernel en firewall. Een gewone serverkernel verwerkt, afhankelijk van processor en netwerkkaart, enkele honderdduizenden pakketten per seconde voordat hij begint te verwerpen. Een aanval die uw lijn niet eens voor een derde vult, kan uw server dus toch platleggen, omdat de rekentijd opgaat aan het verwerpen. Beheerders ervaren dat als "de belasting was helemaal niet hoog en toch was alles weg".

Daartegenover staan echte aanvallen. Twee voorbeelden uit de praktijk bij KernelHost, beide in realtime gefilterd: een UDP-flood tegen een gameserver op 7777/UDP met meer dan 112,2 Gbit/s en meer dan 8,7 miljoen pakketten per seconde, en een multivectoraanval tegen een voiceserver op 9987/UDP met meer dan 473,4 Gbit/s en meer dan 41,5 miljoen pakketten per seconde. Zet dat af tegen uw eigen lijn: 473,4 Gbit/s is ongeveer 470 keer zoveel als een aansluiting van 1 Gbit/s en nog altijd ongeveer 47 keer zoveel als een aansluiting van 10 Gbit/s.

Daarom voldoen de twee gangbare noodremmen geen van beide. Null-routing (blackholing) haalt het aangevallen IP-adres uit het netwerk en beëindigt weliswaar de aanval, maar ook uw server: voor uw spelers is het resultaat identiek aan een geslaagde aanval. Een reactieve omleiding kost in de omschakeltijd precies de minuten waarin de campagne wordt beslist. Effectief is alleen een filtering die permanent in het netwerk vóór de server draait.

Wat KernelHost daartegenover zet

De permanente bescherming die op elke server inbegrepen is

De DDoS-bescherming van KernelHost is in twee lagen opgebouwd en permanent actief, zonder dat u iets hoeft in te schakelen, te bestellen of te configureren:

• Laag 1: 17 Tbps mitigatiecapaciteit in het globale scrubbing-netwerk. Volumetrische aanvallen worden dicht bij hun bron geschoond, ruim voordat ze het datacenter bereiken.
• Laag 2: Arbor realtime filtering met 3,2 Tbps in Frankfurt am Main. Direct vóór de server worden protocolspecifieke patronen op laag 3 tot en met 7 herkend en verworpen, pakket voor pakket.

Twee eigenschappen zijn doorslaggevend. Ten eerste draait de filtering permanent, er is dus geen omschakeltijd waarin uw spelers eruit vliegen. Ten tweede wordt er geen null-routing toegepast: het aangevallen IP-adres blijft in het netwerk, verworpen worden alleen de schadelijke pakketten. De bescherming zit zonder meerprijs in elk serverpakket, zonder apart beschermingspakket en zonder installatie, en ze is vanaf de oplevering actief. De servers staan in het maincubes Premium Datacenter in Frankfurt am Main. Welke games en protocollen gedekt zijn, somt het artikel Gameserver-DDoS-bescherming in realtime op.

Advanced DDoS Protection voor projecten die permanent onder vuur liggen

Sommige projecten worden niet af en toe, maar gericht en wekenlang aangevallen, met wisselende patronen en altijd precies op de afgesproken campagneavond. Voor die gevallen is er de Advanced DDoS Protection vanaf 50,00 € per maand, PrePaid en zonder minimale looptijd. Het verschil zit niet in meer capaciteit, maar in de controle:

• Een dedicated beschermd IP-adres. Uw server wordt binnen ons netwerk op dat adres omgezet, een verbouwing aan uw kant is niet nodig.
• Zelf te beheren beschermingsregels per poort en protocol. U legt in het klantenpaneel vast welke poort met welk profiel wordt gefilterd, dus 27015/UDP anders dan de webserver die uw campagnes uitlevert.
• Wijzigingen werken in realtime, zonder ticket en zonder wachttijd. U kunt dus tijdens een lopende aanval bijsturen.
• Een beschermingsprofiel dat bij het betreffende spel past. Voor Left 4 Dead 2 en de overige Source-titels net zo goed als voor meer dan 40 andere games en protocollen, plus vrij in te vullen TCP- en UDP-profielen voor aangepaste servers.

Ook hier geldt het PrePaid-model: geen minimale looptijd, geen opzegtermijn, geen contract en geen installatiekosten. Is de aanvalsgolf voorbij, dan verlengt u gewoon niet.

De twee niveaus naast elkaar

Voor de meeste Left-4-Dead-2-projecten volstaat de inbegrepen permanente bescherming samen met een nette serverconfiguratie. De Advanced DDoS Protection is het antwoord op iemand die het persoonlijk maakt.

Veelvoorkomende fouten en oplossingen

De server is uit de lobbyzoekopdracht verdwenen, maar draait gewoon door: meestal is 27015/UDP zonder onderscheid dichtgezet of te krap van een ratelimiet voorzien, en omdat spelverkeer en opvraging dezelfde poort delen, raakt een grove regel allebei. Werk in plaats daarvan met een vergelijking op de verbindingsloze pakketten. Is de poort bereikbaar en blijft de server toch onzichtbaar, controleer dan sv_search_key, sv_steamgroup_exclusive, sv_lan 0 en sv_region 255, en of de start per ongeluk met -nomaster is gebeurd.

In de serverconsole staat doorlopend "Invalid split packet length": dat is geen volumetrische aanval, maar een foutief samengesteld netwerkpakket dat in snelle opeenvolging wordt gestuurd. Het verkeer blijft daarbij minuscuul, de server hapert toch. Controleer eerst of de bandbreedte werkelijk opvalt, en breng serverbinary en uitbreidingen op peil. Bandbreedte helpt hier niets.

Alle spelers hebben een hoge ping, terwijl de lijn niet vol zit: dat wijst op de pakketsnelheid en niet op volume. Bekijk de verworpen pakketten in ip -s link show en de UDP-tellers in nstat -az. Staat er in het logboek van het systeem nf_conntrack: table full, haal de spelpoort er dan met notrack uit.

De firewallregel klopt en werkt toch niet: controleer met iptables -L INPUT -n -v of de treffertellers oplopen. Blijven ze op nul staan, dan wordt de regel niet bereikt, omdat ze achter de UFW-ketens staat of na de laatste herstart verloren is gegaan. Lopen ze op en verandert er niets, dan zit de lijn vóór de server vol, en vanaf dat punt helpt alleen filtering in het netwerk.

De server neemt geen spelers meer aan, hoewel er plaatsen vrij zijn: meestal hangt er een lobbyreservering. Ofwel u draait de server consequent via de matchmaking, ofwel u zet sv_force_unreserved 1 en laat uw spelers via de serverlijst toetreden. Bij meer dan vier coöp-plaatsen met L4DToolZ is die instelling sowieso verplicht.

Nieuwe spelers laden eindeloos en de lijn zit daarbij vol: dan levert srcds de campagnebestanden zelf over de spelpoort uit. Zet sv_downloadurl op een webserver en leg de bestanden daar als bzip2-archief neer, of verwijs uw spelers naar de Steam-Workshop.

De aanval pauzeert na een IP-wissel en komt na een tot twee dagen terug: dat is het normale beeld, want uw server publiceert het nieuwe adres zelf zodra hij weer geregistreerd is, en een vergeten DNS-record of een Discord-bot met statusweergave doet de rest. Een IP-wissel levert uren op, geen oplossing.

Op de server lopen vreemde beheerderscommando's: geen DDoS-aanval, maar een gecompromitteerde RCON-toegang. Wijzig direct het wachtwoord en beperk het TCP-deel van 27015 tot het eigen adres.

Kort samengevat

• Een Left-4-Dead-2-server heeft precies één open poort naar buiten nodig: 27015/UDP. Spelverkeer en A2S-opvraging delen die, een aparte query-poort bestaat niet.
• 27015/TCP is RCON en hoort uitsluitend op het eigen adres. Wie RCON niet nodig heeft, laat rcon_password leeg.
• Het lobbysysteem is het effectiefste gratis toegangsfilter dat het spel kent: sv_allow_lobby_connect_only 1, een eigen sv_search_key en sv_steamgroup_exclusive 2 sluiten alles buiten wat niet via de matchmaking komt. Het filtert toetredingen, geen pakketten.
• Custom-campagnes horen in de Steam-Workshop of achter sv_downloadurl, nooit over de spelpoort. Anders betaalt elke afgebroken verbindingspoging met uw bandbreedte.
• Een ratelimiet moet onderscheid maken tussen verbindingsloze pakketten (beginnend met 0xffffffff) en spelverkeer. Een grove regel op 27015/UDP gooit uw eigen spelers eruit.
• Bij pakketten van 64 byte draagt een lijn van 1 Gbit/s ongeveer 1,49 miljoen pakketten per seconde. Daarboven beslist uitsluitend het netwerk vóór de server, geen enkele instelling op de server zelf.
• Bij KernelHost filteren 17 Tbps globale scrubbing en een Arbor realtime filtering met 3,2 Tbps in Frankfurt am Main permanent en zonder meerprijs, zonder null-routing en zonder omschakeltijd.

Draait uw project al bij KernelHost, dan is de filtering actief zonder dat u iets hoeft te doen. Merkt u toch iets afwijkends, open dan een supportticket, zodat ons team de filterregels voor uw IP-adres bijstelt. Bij een lopende aanval bereikt u ons daarnaast via de WhatsApp-noodchat op +43 650 8209883. Vermeld daarbij meteen vier gegevens: IP-adres, poort, periode in uw eigen tijdzone en wat u ziet (spelers vliegen eruit, server niet in de lobbyzoekopdracht, hoge ping). Dat scheelt een ronde extra vragen, en die telt zodra er een campagne loopt.

Host u elders en wordt u regelmatig beschoten, dan is de verhuizing naar KernelHost de kortere weg dan elke verdere regel op een server waarvan de lijn eerder ophoudt. De permanente bescherming is onderdeel van elk serverpakket, niet een extra dat u pas in geval van nood boekt.