Garry's Mod-server beschermen tegen DDoS-aanvallen

Een Garry's-Mod-server die 's avonds om acht uur drie minuten lang verdwijnt en daarna weer terugkomt, heeft zelden een hardwareprobleem. In verreweg de meeste gevallen loopt er een aanval, en die loopt precies op het moment dat de meeste spelers verbonden zijn. DDoS-bescherming voor Garry's Mod betekent daarom eerst: weten welke pakketten er eigenlijk op uw server mogen aankomen. Dit artikel laat in die volgorde zien wat u in de komende tien minuten zonder één cent uit te geven zelf kunt afschermen, waar die maatregelen fysiek ophouden, en wat er daarna in het netwerk vóór de server moet gebeuren.

Alle gegevens gaan uit van een srcds-server onder Debian 12, Debian 13, Ubuntu 22.04 LTS of Ubuntu 24.04 LTS. Het configuratiebestand staat onder garrysmod/cfg/server.cfg, de commando's zijn voor root geschreven; als gewone gebruiker zet u er sudo voor. Bedoeld is steeds het draaien op een eigen root- of dedicated server, niet een slot bij een gameserver-aanbieder.

Loopt de aanval op dit moment: verander nu niets aan de server.cfg en start srcds niet opnieuw op. Leg eerst de meetwaarden vast (paragraaf 9), want na de aanval zijn ze weg. Een herstart kost u de tellers en brengt de server daarna in dezelfde vloed terug.

Waarom een Garry's-Mod-server DDoS-bescherming nodig heeft

Een Garry's-Mod-server publiceert zijn IP-adres en zijn poort zelf. Dat is geen vergissing, maar een voorwaarde: wie niet in de serverlijst staat, krijgt geen nieuwe spelers. De vermelding ontstaat doordat de server zich bij de Steam-masterserver aanmeldt en daarna elke A2S-opvraging beantwoordt die van buiten komt. De vraag luidt dus nooit of een aanvaller uw adres vindt, maar alleen wat er gebeurt zodra hij erop schiet.

Daar komt de aard van de communities bij. Garry's Mod wordt overwegend niet in rondes gespeeld, maar in blijvende werelden: een DarkRP-community houdt spelersaccounts, bezit, banen en voortgang maandenlang in een database bij. Een uitval op vrijdagavond kost daarmee meer dan een verloren match, hij kost vaste spelers. Precies daarom zijn concurrerende communities, geblokkeerde spelers en gekochte server-booters (diensten die voor een paar euro per maand aanvallen op een willekeurig adres uitlokken) de drie meest voorkomende aanleidingen. De aanvaller heeft daarvoor kunde noch noemenswaardig geld nodig.

Technisch komen er drie eigenaardigheden samen. Het spelverkeer loopt over UDP, en UDP kent geen verbindingsopbouw die u zou kunnen eisen: afzenderadressen laten zich vervalsen. De serveropvraging ligt op dezelfde poort als het spel, een grove blokkade raakt dus altijd allebei. En over alles heen ligt Lua: elke Workshop-add-on brengt eigen code in hetzelfde proces, en één enkel onbeschermd netwerkevent volstaat om een enkele client de server zonder enige bandbreedte te laten afremmen. Wat een DDoS-aanval in de kern is, legt het artikel Wat is een DDoS-aanval? uit.

De poorten waar het bij Garry's Mod werkelijk om gaat

Een Garry's-Mod-server start standaard op poort 27015, en wel op UDP voor het spel inclusief serveropvraging en op TCP voor RCON. Het nummer wijzigt u bij de start met -port; bij meerdere instanties telt u op (27016, 27017 enzovoort). Een typisch startcommando ziet er zo uit:

./srcds_run -game garrysmod -console \
  -port 27015 \
  +maxplayers 64 \
  +gamemode darkrp \
  +map rp_downtown_v4c_v2 \
  +sv_setsteamaccount UW_GSLT_TOKEN \
  +host_workshop_collection 123456789 \
  -authkey UW_STEAM_WEB_API_SLEUTEL

Daaruit volgt het volledige aanvalsoppervlak. De volgende tabel is de basis voor elke firewallregel verderop:

Van deze acht vermeldingen hoort er precies één zonder beperking op het open internet: 27015/UDP. Al het andere wordt ofwel tot uw eigen adres beperkt, aan 127.0.0.1 gebonden of helemaal niet gestart. De duurste denkfout binnen dit onderwerp is de aanname dat Garry's Mod een aparte query-poort heeft die u gewoon kunt dichtzetten. Die bestaat niet.

Wat u zelf kunt doen voordat u geld uitgeeft

Dit hoofdstuk is het langste, en dat met opzet. Een netjes geconfigureerde Garry's-Mod-server houdt kleine en middelgrote aanvallen op eigen kracht uit, ongeacht bij wie hij staat. Niets daarvan kost geld, en het meeste ervan is in een kwartier gedaan.

1. Inventarisatie: wat luistert er eigenlijk

Voordat u ook maar één regel schrijft, kijkt u na wat uw server naar buiten aanbiedt. Niet gokken, maar kijken:

ss -lntup

Interessant is de kolom met het lokale adres. 0.0.0.0:27015 en [::]:27015 betekenen "vanaf het hele internet bereikbaar", 127.0.0.1:3306 betekent "alleen lokaal" en heeft geen firewallregel nodig. Op een DarkRP-server die in de loop van de tijd is gegroeid, staan daar bijna altijd meer diensten dan verwacht: MySQL, een webserver voor FastDL, een paneel, een Discord-bot, een tweede testserver op 27016 en een vergeten voicedienst. Het beeld van de aanvaller levert een poortscan van buitenaf:

nmap -Pn -sU -sT -p- --min-rate 1000 UW.SERVER.IP.ADRES

2. Alleen de poorten openlaten die srcds werkelijk nodig heeft

Voor Garry's Mod volstaat één enkele vrijgave naar buiten, daarnaast SSH en de beperkte RCON-toegang. Met UFW ziet dat er zo uit, en wel precies in deze volgorde, zodat u uzelf niet buitensluit:

ufw allow 22/tcp comment 'SSH'
ufw allow 27015/udp comment 'Garrys Mod spel en A2S'
ufw allow from 203.0.113.10 to any port 27015 proto tcp comment 'RCON'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Vervang 203.0.113.10 door uw eigen adres. SourceTV op 27020/UDP geeft u alleen vrij als u werkelijk uitzendt. De volledige handleiding inclusief reddingsweg staat in 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 komt terug via de VNC-console in het klantenpaneel. Die hangt niet aan de netwerkstack van het gastsysteem, een firewallregel in de gast kan haar niet blokkeren.

De database hoort in geen geval op het open internet. Controleer in /etc/mysql/mariadb.conf.d/50-server.cnf of daar staat:

bind-address = 127.0.0.1

3. De A2S-opvraging begrenzen zonder uit de serverlijst te vallen

Hier ligt de fout die de meeste Garry's-Mod-servers kost. Omdat spelverkeer en serveropvraging dezelfde poort bezetten, gooit een algehele blokkade of een te krappe ratelimiet op 27015/UDP de eigen spelers eruit en maakt de aanval zelf af. Het juiste aangrijpingspunt is het onderscheid tussen opvraag- en spelpakketten.

De engine brengt daarvoor drie consolevariabelen mee, die in de server.cfg staan. Hun standaardwaarden zijn behoudend, maar ze zijn gezet:

sv_max_queries_sec 3
sv_max_queries_sec_global 60
sv_max_queries_window 30

sv_max_queries_sec begrenst de beantwoorde opvragingen per afzenderadres (standaard 3 per seconde), sv_max_queries_sec_global maximeert de som over alle adressen (standaard 60 per seconde), sv_max_queries_window legt het middelingsvenster vast (standaard 30 seconden). Deze waarden beschermen de CPU tegen het zinloos opstellen van antwoorden. Ze voorkomen niet dat de pakketten binnenkomen, en wie de globale waarde zeer krap zet, verdwijnt tijdens de aanval uit de serverlijst, omdat ook de opvragingen van de lijstsites onbeantwoord blijven.

Een laag dieper laat het opvraagverkeer zich netjes afsplitsen. Alle verbindingsloze pakketten van de Source-engine 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 bronadres:

table inet gmod {
    chain input {
        type filter hook input priority -10; policy accept;
        udp dport 27015 @th,64,32 0xffffffff \
            meter a2sflood { ip saddr limit rate over 8/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. Met klassiek iptables levert een u32-vergelijking hetzelfde op:

iptables -A INPUT -p udp --dport 27015 \
  -m u32 --u32 "0>>22&0x3C@8=0xFFFFFFFF" \
  -m hashlimit --hashlimit-name gmod_a2s --hashlimit-mode srcip \
  --hashlimit-above 8/sec --hashlimit-burst 20 -j DROP

Eén punt dat bijna elke handleiding op het net weglaat: niet alleen de serveropvraging is verbindingsloos, ook de verbindingsopbouw. Een speler die binnenkomt, stuurt meerdere pakketten met dezelfde kop voordat hij in het spel is. Een te krappe grens sluit daarom nieuwe spelers buiten, hoewel de server bereikbaar blijft. Begin ruim (8 tot 15 pakketten per seconde en per adres) en zet de grens pas strakker zodra u een week normaal bedrijf hebt gemeten.

4. RCON beveiligen of helemaal uitschakelen

RCON is bij Source-servers een geliefd doelwit, en wel om drie redenen tegelijk. Ten eerste ligt het op hetzelfde poortnummer als het spel, alleen op TCP, en is het dus zonder zoeken gevonden. Ten tweede draagt het Source-RCON-protocol het wachtwoord in leesbare vorm over, zonder TLS en zonder sleuteluitwisseling: wie het verkeer meeleest, heeft het. Ten derde is de opbrengst maximaal, want wie RCON heeft, kan de map wisselen, alle spelers blokkeren, de configuratie wijzigen en de server stoppen. Een aanvaller die RCON overneemt, heeft helemaal geen bandbreedte meer nodig.

Laat rcon_password nooit leeg en kies nooit iets wat te raden valt, een waarde uit openssl rand -base64 32 volstaat. Tegen inlogpogingen brengt de engine een rem mee:

rcon_password "HIER_EEN_LANG_WILLEKEURIG_WACHTWOORD"
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. Twee waarschuwingen daarbij. Ten eerste sluit precies dit mechanisme ook uw eigen beheerderspaneel buiten zodra daar een oud wachtwoord in is opgeslagen: wat beheerders melden als "RCON werkt ineens niet meer", is meestal de eigen blokkade. Ten tweede blijft de firewallbeperking uit stap 2 effectiever, want die laat de poging niet eens tot aan de applicatie door. Wie RCON maar af en toe nodig heeft, laat de poort helemaal dicht en werkt via een SSH-poortdoorverwijzing:

ssh -N -L 27015:127.0.0.1:27015 root@UW.SERVER.IP.ADRES

5. Lua-netwerkberichten begrenzen, de meest voorkomende zelfgemaakte uitval

Een aanzienlijk deel van de als DDoS gemelde Garry's-Mod-uitval is dat helemaal niet. Het zijn Lua-overbelastingen, uitgelokt door één enkele verbonden client met een paar kilobit per seconde. De reden ligt in de bouw van de net-bibliotheek: zodra een add-on met util.AddNetworkString een netwerkevent registreert en er met net.Receive naar luistert, kan elke client dat event in een lus uitlokken. Zonder eigen begrenzing voert de server elk afzonderlijk bericht uit. Facepunch heeft dat in de eigen foutmeldingen meermaals gedocumenteerd en geen oplossing in de engine voorzien: de begrenzing is uitdrukkelijk de taak van de auteur van de add-on.

Controleer daarom elke eigen en elke gekochte add-on op drie dingen: een bovengrens per speler en per seconde, een controle van de berichtlengte, en dat de speler aan serverzijde uit de tweede parameter wordt bepaald in plaats van uit de inhoud van het bericht. Een houdbaar patroon ziet er zo uit:

util.AddNetworkString("khrp_buy")

local budget = {}

net.Receive("khrp_buy", function(len, ply)
    if not IsValid(ply) then return end
    if len > 256 then return end

    local now = CurTime()
    local b = budget[ply]

    if not b or now - b.start >= 1 then
        b = { start = now, count = 0 }
        budget[ply] = b
    end

    b.count = b.count + 1
    if b.count > 10 then return end

    KHRP.HandleBuy(ply, net.ReadString())
end)

hook.Add("PlayerDisconnected", "khrp_budget_cleanup", function(ply)
    budget[ply] = nil
end)

Daar horen twee regels in de server.cfg bij. sv_allowcslua staat in Garry's Mod standaard op 1 en staat clients toe met lua_run_cl en lua_openscript_cl eigen code uit te voeren: voor een openbare server hoort die waarde op 0. En sv_kickerrornum verbreekt de verbinding met clients die meer dan het opgegeven aantal clientzijdige fouten veroorzaken (standaard 0, dus uitgeschakeld):

sv_allowcslua 0
sv_kickerrornum 25

6. Workshop-inhoud en FastDL van de spelserver scheiden

Workshop-add-ons zijn bij Garry's Mod geen randverschijnsel, maar het normale geval: een DarkRP-community bindt haar collectie in met +host_workshop_collection, en de clients laden die inhoud rechtstreeks bij Steam. Dat belast uw lijn niet. De sleutel uit -authkey is een Steam-Web-API-sleutel en hoort als een wachtwoord te worden behandeld: in het startscript, niet in een openbare repository en niet in een Discord-kanaal.

De bandbreedte kost de tweede weg. Alles wat niet uit de Workshop komt (eigen maps, geluiden, materialen) gaat via het downloadkanaal. Zonder sv_downloadurl loopt dat kanaal over de spelpoort zelf en concurreert het rechtstreeks met het spelverkeer. Met FastDL loopt het over HTTP. Staat die webserver op dezelfde host en hetzelfde IP-adres, dan delen beide dezelfde lijn: een golf van binnenkomende spelers of een aanval op 80/TCP raakt daarmee ook het spel. Deze waarden zijn zinvol:

sv_downloadurl "https://fastdl.uw-domein.nl/garrysmod/"
sv_allowdownload 1
sv_allowupload 0
net_maxfilesize 64

sv_allowupload 0 ontneemt clients de mogelijkheid om eigen bestanden naar de server te sturen en sluit daarmee een weg af die niet wordt gebruikt en niet wordt gecontroleerd. net_maxfilesize begrenst de grootte van de over het spelkanaal overgedragen bestanden in megabyte. Leg FastDL zo mogelijk op een andere host of achter een eigen naam, dan ligt de belasting niet op hetzelfde adres als de spelpoort.

7. Joinflood en slotuitputting opvangen

Slotuitputting is een aanval die geen bandbreedte nodig heeft: de aanvaller bezet met geautomatiseerde verbindingen alle vrije plaatsen, zodat echte spelers een vol huis zien. Bij Garry's Mod komt daar verzwarend bij dat elke toetreding de server werk kost, omdat de bestandslijst en de gamemode worden afgestemd lang voordat de speler in het spel is.

Daartegen werken vier dingen. Ten eerste een realistische bovengrens: +maxplayers hoger zetten dan uw gamemode verdraagt, vergroot alleen het aanvalsoppervlak. Ten tweede sv_timeout, dat vastlegt na hoeveel seconden zonder bericht een client wordt losgekoppeld (in de gangbare configuraties 120): wie hangende halve verbindingen sneller kwijt wil, zet de waarde lager. Ten derde de ratelimiet op de verbindingsloze pakketten uit stap 3, want de verbindingsopbouw loopt precies daarover. Ten vierde, voor gesloten groepen, een serverwachtwoord:

sv_password "vaste_groep_2026"
sv_timeout 90
sv_filterban 1
sv_region 3

Een echte whitelist brengt Garry's Mod niet mee, die komt via uitbreidingen als ULX of via een eigen controle in de hook CheckPassword. En één ding moet duidelijk zijn: een whitelist beschermt uw spellogica, niet uw lijn. Een aanvaller die uw server overspoelt, wil helemaal niet toetreden. Zijn pakketten worden geweigerd, maar ze zijn wel aangekomen, en precies daar gaat het om.

8. De kernel ontlasten: connection tracking en ontvangstbuffer

Deze stap 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, en in het logboek van het systeem staat "nf_conntrack: table full". Stand en bovengrens toont:

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, 27020 } notrack
    }
    chain output {
        type filter hook output priority raw; policy accept;
        udp sport { 27015, 27020 } 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 bovendien sneller binnen dan srcds ze ophaalt, dan loopt de ontvangstbuffer over, en voor de spelers ziet dat eruit als pakketverlies terwijl de lijn vrij is:

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

De regels horen in een bestand onder /etc/sysctl.d/ en worden met sysctl --system actief. Of ze 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.

9. Meetwaarden vastleggen zolang alles normaal draait

De belangrijkste stap is die welke bijna niemand vooraf zet: een vergelijkingsbasis aanleggen. Zonder normaalwaarde kunt u na een incident niet zeggen of 40.000 pakketten per seconde veel was of gewoon zaterdagavond. Reken de normaalwaarde voor uw server één keer uit: 64 spelers met cl_cmdrate 66 leveren ongeveer 4.200 inkomende pakketten per seconde op, alles wat daar duidelijk boven ligt, vraagt om uitleg. Met apt-get install -y vnstat sysstat loopt de meting permanent mee. Tijdens een incident volstaan vier commando's:

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

Het eerste toont pakketten en bytes per seconde, het tweede de verwerptellers van de interface, het derde de UDP-fouttellers van de kernel. De vierde 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. Begrens tcpdump altijd met -c, want een opname onder volle belasting belast een toch al overbelaste server nog extra. Hoe u de waarden uitleest, staat in DDoS-aanval op de server herkennen.

Wat is het A2S-reflectielek en heb ik er nog mee te maken

A2S-reflectie is een aanval waarbij niet uw server het doelwit is, maar het werktuig. De aanvaller stuurt een kleine opvraging met vervalst afzenderadres naar duizenden gameservers, en hun aanzienlijk grotere antwoorden komen allemaal bij het eigenlijke slachtoffer samen. Historisch was een A2S_INFO-verzoek 25 byte groot (4 byte 0xFFFFFFFF, 1 byte 0x54, plus 20 byte voor de tekenreeks "Source Engine Query"), het antwoord daarentegen enkele honderden bytes. Het US-CERT voert het Steam-protocol in zijn lijst van versterkingsaanvallen met een factor van 5,5, wat betekent: uit één gigabit bij de aanvaller worden 5,5 gigabit bij het slachtoffer.

Valve heeft dit lek vanaf november 2020 gedicht, en wel langs twee wegen. Verbindingsloze opvraagpakketten moeten sindsdien door de afzender op 1.200 byte worden aangevuld, waarmee het verzoek groter is dan het antwoord en de versterkingsfactor onder 1 zakt. Tijdens de omschakeling konden beheerders het strengere gedrag vooraf afdwingen met de omgevingsvariabele STEAM_GAMESERVER_MIN_CONNECTIONLESS_PACKET_SIZE=1200. Daarnaast antwoordt de server bij A2S_PLAYER en A2S_RULES niet meteen met gegevens, maar met een challenge (S2C_CHALLENGE), die de vrager in een tweede verzoek moet terugsturen. Wie het afzenderadres vervalst, krijgt die challenge nooit te zien.

Voor u volgen daaruit twee dingen. Houd de serverbinary actueel, want de bescherming zit in de Steam-gameserver-onderbouw en niet in uw configuratie. En verwar reflectie niet met een opvraagvloed tegen uzelf: tegen die tweede vorm helpt uitsluitend de ratelimiet uit stap 3 en, daarboven, filtering in het netwerk vóór de server.

Waar deze maatregelen ophouden: bandbreedte en pakketsnelheid

Nu het deel dat geen enkel configuratiebestand kan oplossen. Alles wat tot hier is beschreven, draait op uw server, dus aan het einde van de lijn. 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 is 125 megabyte per seconde, en de lijn zit vol zodra iemand meer stuurt. De tweede grootheid slaat meestal eerder toe: bij de kleinst mogelijke pakketten van 64 byte passen er in 1 Gbit/s ongeveer 1,49 miljoen pakketten per seconde, in 10 Gbit/s ongeveer 14,88 miljoen. Een gewone serverkernel verwerkt daarvan, afhankelijk van CPU en netwerkkaart, enkele honderdduizenden 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 had iedereen lag-spikes".

Ter oriëntatie, welke ordes van grootte werkelijk voorkomen: op KernelHost-servers zijn onder meer een UDP-flood met meer dan 112,2 Gbit/s en meer dan 8,7 miljoen pakketten per seconde tegen een gameserver gefilterd, en een multivectoraanval met meer dan 473,4 Gbit/s en meer dan 41,5 miljoen pakketten per seconde tegen een voiceserver. 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. Daarvoor bestaat geen lokale instelling. Volumetrische aanvallen moeten in het netwerk vóór de server eindigen.

Wat KernelHost daartegenover zet

De permanente bescherming die in elk serverpakket 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, nog 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 herkend en verworpen, pakket voor pakket.

Twee eigenschappen zijn doorslaggevend. De bescherming loopt permanent en hoeft niet eerst op een aanval te reageren, er is dus geen omschakeltijd waarin uw spelers eruit vliegen. En er wordt geen null-routing toegepast: uw IP-adres blijft in het netwerk, verworpen worden alleen de schadelijke pakketten. Wie het IP-adres uit het netwerk haalt, bereikt voor u hetzelfde resultaat als de aanvaller. De locatie is Frankfurt am Main. Welke games en protocollen gedekt zijn, somt Gameserver-DDoS-bescherming in realtime op.

Advanced DDoS Protection voor communities die permanent onder vuur liggen

Sommige projecten worden niet af en toe, maar gericht en wekenlang aangevallen, met wisselende patronen en altijd precies op het drukste tijdstip. Daarvoor 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 uit de Frankfurtse kern, waarnaar uw server binnen ons eigen netwerk wordt omgezet. Aan uw kant is geen verbouwing nodig.
• Zelf te beheren beschermingsregels per poort en protocol in het klantenpaneel: u stelt in wat op 27015/UDP is toegestaan en wat op 27015/TCP, zonder daarvoor een ticket te schrijven.
• Wijzigingen werken in realtime, u kunt dus tijdens een lopende aanval bijsturen in plaats van op het volgende onderhoudsvenster te wachten.
• Een beschermingsprofiel dat bij het betreffende spel past, voor Garry's Mod en de overige Source-titels net zo goed als vrij in te vullen TCP- en UDP-profielen voor aangepaste servers en eigen applicaties.

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. Wie zijn Garry's-Mod-server tot nu toe elders draait, krijgt deze bescherming via een verhuizing naar KernelHost, want er wordt in het eigen netwerk gefilterd en niet op vreemde infrastructuur.

De twee beschermingsniveaus naast elkaar

Voor de meeste Garry's-Mod-communities 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 draait, maar is uit de serverlijst verdwenen": meestal is 27015/UDP volledig dichtgezet of te krap van een ratelimiet voorzien. Omdat spelverkeer en opvraging dezelfde poort delen, raakt een grove regel allebei. Werk in plaats daarvan met een vergelijking op de verbindingsloze pakketten. Blijft de server onzichtbaar terwijl de poort bereikbaar is, controleer dan sv_setsteamaccount: zonder geldig Game Server Login Token wordt een Garry's-Mod-server in de lijst sterk afgewaardeerd, en elke server heeft een eigen token nodig.

"Mijn iptables-regel klopt en werkt toch niet": drie oorzaken komen vaak voor. De regel staat achter de UFW-ketens en wordt nooit bereikt, ze was na de laatste herstart weg (dan helpen apt-get install -y iptables-persistent en netfilter-persistent save of een regel in /etc/ufw/before.rules), of de aanval is volumetrisch en de regel werkt correct aan een lijn die al vol zit. Controleer met iptables -L INPUT -n -v of de treffertellers oplopen. Blijven ze op nul staan, dan wordt de regel niet bereikt.

"Mijn DarkRP-server hapert voor iedereen, terwijl de lijn vrij is": dat is bijna altijd Lua en geen aanval op de lijn. Kijk in het serverlogboek welk netwerkevent opvallend vaak binnenkomt, en controleer de bijbehorende add-on op een begrenzing per speler. Blijven sar -n DEV 1 10 en de verwerptellers onopvallend, dan was het geen DDoS-aanval.

"RCON werkt ineens niet meer": geen DDoS, maar meestal de eigen blokkade. Een beheerderspaneel met een oud wachtwoord lokt sv_rcon_minfailures uit, en sv_rcon_banpenalty blokkeert het adres voor het ingestelde aantal minuten. Wachtwoord corrigeren, blokkade opheffen, daarna de poort tot het eigen adres beperken.

"Ik heb het IP-adres gewisseld en was twee dagen later weer offline": dat is het normale beeld. Uw server publiceert het nieuwe adres zelf zodra hij weer bij de masterserver is aangemeld, en een gameserver zonder openbaar adres heeft geen spelers. Een adreswissel levert uren tot dagen op, het is geen oplossing.

"Mijn vorige aanbieder heeft mijn IP-adres geblokkeerd": dat is null-routing. De aanbieder beschermt daarmee zijn eigen netwerk; voor u is het resultaat identiek aan een geslaagde aanval, meestal nog urenlang daarna. Vraag bij twijfel na of er wordt gefilterd of null-geroutet. Dat antwoord bepaalt meer over uw beschikbaarheid dan welke hardwarespecificatie ook.

"In de tcpdump zie ik niets opvallends": wordt het verkeer al in het netwerk ervoor gefilterd, dan komt er op de server zoals verwacht niets aan. Dat is het normale beeld bij een werkende filtering. Omgekeerd geldt: zit de lijn vol, dan bereikt u onder omstandigheden zelfs de SSH-sessie niet meer waarmee u wilde meten. Gebruik dan de VNC-console in het klantenpaneel.

Kort samengevat

• Een Garry's-Mod-server heeft precies één open poort nodig: 27015/UDP. Spelverkeer en A2S-opvraging lopen daar samen, een aparte query-poort bestaat niet.
• RCON ligt op 27015/TCP, draagt het wachtwoord in leesbare vorm over en hoort uitsluitend voor het eigen adres te worden vrijgegeven of via een SSH-poortdoorverwijzing te worden bereikt.
• Begrens niet de poort, maar de verbindingsloze pakketten met de kop 0xffffffff. Een algehele blokkade op 27015/UDP gooit de eigen spelers eruit.
• De meest voorkomende Garry's-Mod-uitval is geen DDoS-aanval, maar een netwerkevent zonder begrenzing: elk met util.AddNetworkString geregistreerd event heeft een bovengrens per speler en per seconde nodig.
• Bij pakketten van 64 byte draagt een lijn van 1 Gbit/s ongeveer 1,49 miljoen pakketten per seconde. Daarboven ontstaat het verlies op de router ervoor, en elke lokale regel wordt werkeloos.
• Bij KernelHost zit de permanente bescherming in twee lagen zonder meerprijs in elk serverpakket: 17 Tbps mitigatiecapaciteit in het globale scrubbing-netwerk en Arbor realtime filtering met 3,2 Tbps in Frankfurt am Main, zonder null-routing.
• Wie permanent en gericht onder vuur ligt, vult dat aan met de Advanced DDoS Protection vanaf 50,00 € per maand: een dedicated beschermd IP-adres, zelf te beheren regels per poort en protocol, in realtime werkzaam.

Draait uw server 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 de filterregels voor uw IP-adres worden bijgesteld. Vermeld daarbij meteen vier gegevens: IP-adres, poort, periode in uw eigen tijdzone en wat u ziet (spelers vliegen eruit, server niet in de lijst, lag-spikes). Bij een lopende aanval bereikt u ons daarnaast via de WhatsApp-noodchat op +43 650 8209883.

Wie naast Garry's Mod nog andere Source-titels draait, vindt de gemeenschappelijke grondbeginselen in CS2- en Source-servers beschermen tegen DDoS-aanvallen, en hoe de onderbouw netjes wordt opgezet, staat in Gameserver met SteamCMD installeren.