Team Fortress 2: TF2-server beschermen tegen DDoS-aanvallen

Een Team Fortress 2-communityserver die 's avonds midden in de ronde al zijn spelers tegelijk verliest en daarna minutenlang uit de serverbrowser verdwijnt, heeft zelden een hardwareprobleem. Meestal loopt er een aanval op 27015/UDP. Dit artikel laat zien hoe u een TF2-server tegen DDoS-aanvallen beschermt: eerst wat u in de komende tien minuten zonder extra kosten zelf kunt doen, daarna het punt waarop die maatregelen fysiek ophouden, en tot slot wat er ervoor in het netwerk moet gebeuren.

Alle gegevens gaan uit van een met SteamCMD geïnstalleerde Source-dedicated-server (srcds_run -game tf) 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. Loopt de aanval op dit moment: verander eerst niets en start de server niet opnieuw op, maar leg de meetwaarden uit paragraaf 9 vast. Na de aanval zijn ze verdwenen.

Waarom Team Fortress 2-servers DDoS-bescherming nodig hebben

Team Fortress 2 is sinds 2011 gratis te spelen, en precies dat verschuift de economie van een aanval. Een aanvaller heeft onbeperkt veel wegwerpaccounts, betaalt voor geen enkel daarvan en riskeert bij een blokkade niets. Wat bij een betaald spel geld kost, kost hier een minuut.

Daar komt een eigenaardigheid bij die TF2 van de meeste andere spellen onderscheidt: sinds de update "Meet Your Match" van juli 2016 bestaat Quickplay niet meer, dat nieuwe spelers automatisch over communityservers verdeelde. Nieuwe spelers komen in de casualmodus op servers van Valve terecht. Communityservers zijn uitsluitend via de serverbrowser vindbaar. Wie uit die lijst valt, bestaat voor nieuwe spelers praktisch niet meer, zelfs als het serverproces foutloos draait. Een aanval die uw server alleen maar uit de lijst drukt, heeft zijn doel daarmee al bereikt.

Typische doelwitten zijn navenant: permanent draaiende communityservers met vaste spelers (2Fort rond de klok, Trade, Jailbreak, Surf, Dodgeball, Mann vs. Machine), competitieservers met een vast wedstrijdtijdstip in de competities van ETF2L, RGL en ozfortress, en servers waarvan de beheerder net iemand heeft geblokkeerd. De aanleiding is vrijwel nooit technisch. Wat een DDoS-aanval eigenlijk is, legt het artikel Wat is een DDoS-aanval? uit.

De poorten waar het bij een TF2-server werkelijk om gaat

Een TF2-server heeft naar buiten precies één poort nodig: 27015/UDP. Al het andere is uitschakelbaar, hoort beperkt te worden of loopt sowieso alleen uitgaand. Deze tabel is de basis voor elke firewallregel verderop:

Bij meerdere instanties op één machine lopen de nummers op: 27016, 27017 enzovoort voor het spel, 27021 en 27022 voor SourceTV. Het configuratiebestand staat in tf/cfg/server.cfg en wordt bij elke mapwissel opnieuw ingelezen.

Waarom de gedeelde poort 27015 het gevoeligste punt is

Spelverkeer en serveropvraging delen bij TF2 dezelfde UDP-poort, een aparte query-poort bestaat niet. Een A2S_INFO-verzoek is daarbij precies 25 byte lang: vier byte FF FF FF FF, één byte 0x54 en de 20 byte lange tekenreeks "Source Engine Query" met afsluitende nul. Het antwoord met servernaam, map, spelersaantal en tags is daar een veelvoud van. De Amerikaanse instantie CISA becijfert de versterkingsfactor van het Steam-protocol in Alert TA14-017A op 5,5.

Omdat UDP geen verbindingsopbouw kent en afzenderadressen te vervalsen zijn, was dat jarenlang een open versterkingsgat: een aanvaller bevroeg vreemde Source-servers met het adres van zijn slachtoffer als afzender, en die servers stuurden hun antwoorden naar het slachtoffer. A2S_PLAYER en A2S_RULES verlangden altijd al een vooraf opgehaalde challenge, A2S_INFO niet. Pas in december 2020 heeft Valve ook voor A2S_INFO een challenge toegevoegd: de server mag in plaats van het antwoord een S2C_CHALLENGE terugsturen, die de opvrager moet herhalen, waarmee hij bewijst dat hij het afzenderadres niet heeft vervalst.

Dat verzacht de reflectie, maar maakt geen eind aan het probleem. Elk opvraagpakket komt nog steeds bij u aan en kost rekentijd voordat het wordt beantwoord of verworpen. En een aanvaller die uw server rechtstreeks overspoelt, heeft sowieso geen versterking nodig.

Wat u zelf kunt doen voordat u geld uitgeeft

Dit hoofdstuk is het langste, en dat met opzet. Een netjes geconfigureerde TF2-server houdt kleine en middelgrote aanvallen op eigen kracht uit, ongeacht bij wie hij staat.

1. Inventarisatie: wat luistert er, en met welke startregel

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

ss -lntup

Alles wat aan 127.0.0.1 of ::1 gebonden is, hoeft niet te worden vrijgegeven. Alles op 0.0.0.0 of [::] is vanaf het internet bereikbaar, ook de MySQL-database die een statistiekplugin heeft meegebracht en de webserver waarop uw FastDL-bestanden staan. Vergelijk het resultaat met uw startregel:

./srcds_run -game tf -console \
  -port 27015 -steamport 26901 -nohltv \
  +maxplayers 24 +map ctf_2fort +sv_pure 1 \
  +sv_setsteamaccount UW_GSLT_TOKEN

Elke poort in deze regel is een bewuste keuze. Hoe de onderbouw wordt geïnstalleerd, staat in Gameserver met SteamCMD installeren.

2. Alleen de poorten openlaten die TF2 werkelijk nodig heeft

Een openbare TF2-server heeft naar buiten precies één vrijgave nodig, plus RCON voor uw eigen adres. Met UFW, en wel precies in deze volgorde, zodat u uzelf niet buitensluit:

ufw allow 22/tcp comment 'SSH'
ufw allow 27015/udp comment 'TF2 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 ontbreekt hier met opzet: wie niet uitzendt, start met -nohltv en bezet 27020/UDP helemaal niet. Dat halveert het van buitenaf bereikbare UDP-oppervlak van een TF2-server. Zendt u competitiewedstrijden uit, dan komt ufw allow 27020/udp erbij, en dan hoort er een tv_password ingesteld te worden.

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 bereikt u via de VNC-console in het klantenpaneel, die losstaat van het netwerk van het gastsysteem.

3. A2S-opvragingen begrenzen zonder uit de serverbrowser te vallen

Hier zit de duurste fout binnen dit onderwerp: 27015/UDP volledig dichtzetten of er grof een ratelimiet overheen leggen gooit de eigen spelers eruit en maakt de aanval af in het voordeel van de aanvaller. Omdat spelverkeer en opvraging dezelfde poort bezetten, moet de grens tussen de pakketsoorten lopen, niet op de poort.

De engine heeft daarvoor drie consolevariabelen die in de tf/cfg/server.cfg horen:

sv_max_queries_sec 3
sv_max_queries_sec_global 60
sv_max_queries_window 30

De eerste begrenst het aantal beantwoorde opvragingen per afzenderadres, de tweede de som over alle adressen, de derde legt het middelingsvenster in seconden vast. Ze beschermen de CPU tegen het zinloos opstellen van antwoorden. De standaardwaarden verschillen per spel en per build; met find sv_max_queries in de serverconsole ziet u welke waarden uw server kent.

De tweede waarde is bij TF2 de lastige: hij maximeert de antwoorden over alle adressen heen. Zet u hem te laag, dan beantwoordt uw server tijdens een opvraagvloed ook de verzoeken van de lijstdiensten niet meer en verdwijnt hij uit de serverbrowser, dus uit de enige weg waarlangs nieuwe spelers u vinden. Begin ruim en zet de grens pas strakker zodra u kunt meten dat legitieme opvragingen doorkomen.

Een laag dieper is hetzelfde verkeer netjes af te splitsen. Alle verbindingsloze pakketten van de Source-engine beginnen met vier gezette bytes (0xffffffff), het verkeer van al verbonden spelers heeft die kop niet. Daarop legt u een ratelimiet zonder het spelverkeer aan te raken:

table inet tf2 {
    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.

4. Split-pakketvloeden opvangen die in het logboek als NET_GetLong opduiken

Deze aanval is een eigenaardigheid van de Source-engine en treft TF2 in het bijzonder, omdat TF2 tot op heden op de oude enginetak draait. Naast de gewone verbindingsloze pakketten kent de engine opgesplitste pakketten: ze beginnen met FE FF FF FF in plaats van FF FF FF FF en kondigen aan dat een groter bericht in meerdere delen volgt. De server moet die delen tussentijds opslaan en op de rest wachten.

Precies dat laat zich misbruiken. Een aanvaller stuurt massaal aangekondigde, maar nooit volledige deelpakketten met vervalste afzenderadressen. De CPU-belasting stijgt, het spel hapert, en in het serverlogboek stapelen de regels met NET_GetLong zich op. Eén enkele computer volstaat daarvoor, bandbreedte is er nauwelijks voor nodig. Beheerders melden dit geregeld als DDoS-aanval, hoewel de lijn bijna leeg is.

Omdat een reguliere TF2-client nauwelijks aanleiding heeft om de server opgesplitste pakketten te sturen, is een strakke begrenzing hier verdedigbaar:

udp dport 27015 @th,64,32 0xfffffffe \
    meter tf2split { ip saddr limit rate over 5/second burst 10 packets } drop

De regel hoort in dezelfde keten als de regel uit paragraaf 3. Een van de weinige legitieme redenen voor uploads door clients haalt u daarnaast met sv_allowupload 0 uit het spel (zie paragraaf 7).

5. RCON uit het open internet halen

Het RCON-protocol van de Source-engine verstuurt het wachtwoord in leesbare vorm over TCP. Wie de weg tussen u en de server kan meelezen, heeft daarna uw RCON-wachtwoord, en wie RCON heeft, kan de map wisselen, alle spelers blokkeren en de server stoppen. Dat is geen DDoS-probleem maar een overname, en toch wordt het geregeld als aanval gemeld.

Laat rcon_password nooit leeg en kies nooit iets wat te raden valt, een waarde uit openssl rand -base64 32 volstaat. Daar hoort een rem tegen inlogpogingen bij:

rcon_password "HIER_DE_WILLEKEURIGE_WAARDE"
sv_rcon_maxfailures 3
sv_rcon_minfailures 3
sv_rcon_minfailuretime 30
sv_rcon_banpenalty 1440

Daarmee blokkeert de server een adres na drie mislukte pogingen binnen 30 seconden een etmaal lang; met find sv_rcon ziet u welke variabelen uw build kent. Toch blijft de firewallregel uit paragraaf 2 effectiever, want die laat de poging niet eens tot aan de applicatie door. Voor toegang vanaf wisselende aansluitingen richt u een lokale doorverwijzing via SSH in en spreekt u RCON daarna op 127.0.0.1 aan:

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

6. Snelheden begrenzen en de hibernation ingeschakeld laten

Team Fortress 2 draait vast op 66,67 ticks per seconde. Hoeveel verkeer daaruit ontstaat, bepaalt niet de tick, maar wat een enkele client mag opvragen. Zonder bovengrens haalt elke speler zoveel als zijn client verlangt, en dat betaalt u met uw uitgaande bandbreedte:

sv_minrate 50000
sv_maxrate 100000
sv_mincmdrate 40
sv_maxcmdrate 66
sv_minupdaterate 40
sv_maxupdaterate 66

Reken dat eens door: bij sv_maxrate 100000 mag elke speler 100 kilobyte per seconde afnemen, op 24 plaatsen is dat 2,4 megabyte per seconde of ongeveer 19 Mbit/s uitgaand. Zet u sv_maxrate 0, dan is er geen bovengrens. Competitieservers doen dat bewust, een openbare server met veel plaatsen zou het niet moeten doen. Plugins die de tickrate ontgrendelen, vermenigvuldigen de pakketsnelheid per speler en daarmee dezelfde rekensom.

Het tweede punt gaat vaak mis. TF2 valt in slaap zodra er niemand verbonden is en heeft in die toestand vrijwel geen CPU nodig. Veel beheerders schakelen dat uit, zodat de server "wakker" aanvoelt. Op een machine met meerdere instanties betekent dat een CPU die al in rust bezet is, waardoor een aanval een toch al vol systeem treft. Laat de standaardinstelling staan:

sv_hibernate_when_empty 1
sv_hibernate_postgame_delay 5
tf_allow_server_hibernation 1

7. FastDL scheiden en uploads uitschakelen

Communityservers leven van eigen maps, en precies daaruit ontstaat een tweede aanvalsoppervlak. Zonder sv_downloadurl haalt elke speler de inhoud via het netwerkkanaal van het spel binnen, dus via dezelfde poort en hetzelfde proces dat tegelijk de match berekent. Dat zijn enkele kilobytes per seconde en één bestand tegelijk, en bij een mapverzameling van 200 megabyte blokkeert dat uw server minutenlang per speler:

sv_allowdownload 1
sv_allowupload 0
net_maxfilesize 64
sv_downloadurl "https://fastdl.example.org/tf/"

net_maxfilesize staat standaard op 15 en laat zich tot maximaal 64 megabyte verhogen. sv_allowupload 0 voorkomt dat clients eigen bestanden (bijvoorbeeld sprays) naar de server sturen en neemt daarmee een van de weinige legitieme redenen voor opgesplitste pakketten uit paragraaf 4 weg.

Doorslaggevend is waar de FastDL-host staat. Staat die op hetzelfde IP-adres als de spelserver, dan volstaat een HTTP-vloed tegen 443/TCP om de lijn te vullen en daarmee ook 27015/UDP te verstikken. Zet de snelle download op een andere host of achter een contentnetwerk, dan raakt een aanval op de bestanden het spel niet.

8. Stemsysteem, joinfloods en plugins begrenzen

Niet elke uitval is bandbreedte. Omdat TF2 gratis is, kost een aanval op de spellogica niets dan accounts: joinfloods die elke plaats bezetten, spraak- en chatspam, en misbruikte stemmingen die reguliere spelers eruit gooien. De standaardinstellingen van TF2 zijn hier al verstandig, maar worden vaak opgerekt:

sv_allow_votes 1
sv_vote_issue_kick_allowed 0
sv_vote_allow_spectators 0
sv_vote_creation_timer 150
sv_vote_failure_timer 300
sv_vote_quorum_ratio 0.6

Dit zijn de standaardwaarden: stemmingen zijn toegestaan, kickstemmingen niet, toeschouwers stemmen niet mee, tussen twee stemmingen zitten 150 seconden, na een mislukte 300, en een stemming heeft 60 procent instemming nodig. Wie sv_vote_issue_kick_allowed 1 zet, moet weten dat hij daarmee een werktuig opent dat op een openbare server gegarandeerd wordt misbruikt.

Alles wat daarboven uitgaat, komt bij TF2 uit SourceMod en Metamod:Source. Beide staan onder tf/addons/ en melden zich in de console met meta version en sm version. Anders dan bij Counter-Strike 2 is de onderbouw hier uitgerijpt, en plugins voor blokkeerlijsten, toetredingscontrole en chatbegrenzing zijn de gebruikelijke weg. Twee regels daarbij: elke plugin is code in hetzelfde proces, een crashende plugin neemt de server mee. En plugins die eigen webdiensten meebrengen, openen extra poorten en publiceren soms precies het adres dat u wilde beschermen. sm plugins list toont wat er werkelijk draait.

Hoe serieus de enginekant te nemen is, laat april 2020 zien: nadat oudere broncodeversies van TF2 en CS:GO waren uitgelekt, hebben grote communitybeheerders zoals Creators.TF en Red Sun hun servers uit vrees voor misbruik tijdelijk uitgeschakeld. Houd de serverbinary actueel en de uitbreidingen passend bij de engineversie.

9. Meten en vastleggen voordat het misgaat

De belangrijkste stap is 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. Tijdens een incident volstaan vier commando's:

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

Het eerste commando toont pakketten, fouten en verworpen verkeer per interface; voer het twee keer uit met tien seconden ertussen, dan hebt u een snelheid in plaats van een absolute waarde. De twee opnames scheiden de opvraagvloed van de split-pakketvloed en beantwoorden daarmee de vraag welke van de twee regels uit de paragrafen 3 en 4 daadwerkelijk moet aanslaan. Begrens ze altijd met -c, een opname onder volle belasting kost zelf rekentijd.

Binnen de server levert het consolecommando stats in één regel de CPU-belasting, de in- en uitgaande netwerkbelasting in kilobyte per seconde, de server-FPS en het spelersaantal. Zakken de server-FPS duidelijk onder de tickwaarde terwijl het spelersaantal normaal is, dan werkt de server aan iets anders dan aan het spel. Hoe u de waarden inschat, staat in DDoS-aanval op de server herkennen.

Waar deze maatregelen ophouden: bandbreedte en pakketsnelheid

Nu het deel dat geen enkel configuratiebestand kan oplossen. Alle maatregelen tot hier draaien 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.

Zet het normale bedrijf van een volle TF2-server naast een echte aanval, dan wordt de verhouding duidelijk:

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 is de pakketsnelheid, en die slaat meestal eerder toe dan de bandbreedte: elk pakket kost een gang door de netwerkstack, ook als het daarna wordt weggegooid. Een aanval die uw lijn niet eens voor een derde vult, legt uw server daarom toch plat. Beheerders ervaren dat als "de belasting was helemaal niet hoog en toch was alles weg".

Ter oriëntatie, welke ordes van grootte werkelijk voorkomen: op KernelHost-servers zijn onder meer een UDP-flood tegen een gameserver met meer dan 112,2 Gbit/s bij meer dan 8,7 miljoen pakketten per seconde en een multivectoraanval tegen een voiceserver met meer dan 473,4 Gbit/s bij meer dan 41,5 miljoen pakketten per seconde in realtime gefilterd. 473,4 Gbit/s is ongeveer 470 keer zoveel als een aansluiting van 1 Gbit/s. Daarvoor bestaat geen lokale instelling.

De twee gangbare noodremmen helpen niet verder. Null-routing haalt het aangevallen IP-adres uit het netwerk en beëindigt de aanval, maar ook uw server. Een reactieve omleiding kost in de omschakeltijd precies de minuten waarin de match wordt beslist. Effectief is alleen een filtering die permanent in het netwerk vóór de server draait.

Wat KernelHost tegenover aanvallen op TF2-servers zet

De permanente bescherming die in elk serverpakket inbegrepen is

De DDoS-bescherming van KernelHost is in twee lagen opgebouwd en vanaf de oplevering permanent actief, zonder dat u iets hoeft te bestellen, in te schakelen 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 voor een TF2-server doorslaggevend. De filtering loopt permanent en hoeft niet eerst op een aanval te reageren, er is dus geen omschakeltijd waarin uw spelers eruit vliegen en uw server uit de serverbrowser valt. En er wordt geen null-routing toegepast: uw IP-adres blijft in het netwerk, alleen de kwaadaardige pakketten worden verworpen. Welke games en protocollen gedekt zijn, somt Gameserver-DDoS-bescherming in realtime op.

Advanced DDoS Protection voor servers die permanent onder vuur liggen

Sommige projecten worden niet af en toe, maar gericht en wekenlang aangevallen, met wisselende patronen en steeds precies op het tijdstip van de match. 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 het Frankfurtse kernnetwerk, waarnaar uw server binnen ons netwerk wordt omgezet. Aan uw kant is geen enkele verbouwing nodig.
• Zelf te beheren beschermingsregels per poort en protocol in het klantenpaneel: u stelt apart in wat op 27015/UDP is toegestaan, wat op 27020/UDP en wat op 27015/TCP, zonder daarvoor een ticket te schrijven.
• Wijzigingen gelden in realtime, u kunt dus tijdens een lopende aanval bijsturen in plaats van tot het einde van de match te wachten.
• Een beschermingsprofiel dat bij het spel past, voor Team Fortress 2 en de overige Source-titels net zo goed als vrije TCP- en UDP-profielen voor eigen applicaties.

Het aanbod richt zich op servers die bij KernelHost draaien. Staat uw TF2-server op dit moment ergens anders en wordt hij geregeld beschoten, dan is de verhuizing de weg naar deze bescherming.

De twee niveaus in vergelijking

Voor de meeste TF2-communityservers 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 staat niet meer in de serverbrowser": controleer eerst het Game Server Login Token. TF2-servers hebben voor de openbare vermelding een token nodig, ingesteld via sv_setsteamaccount en aangemaakt voor app-id 440. Steam trekt tokens in die 30 dagen niet zijn gebruikt. Een server die na een langere pauze verdwijnt, heeft dus vaak alleen een nieuw token nodig en wordt helemaal niet aangevallen. Pas daarna komen een te lage sv_max_queries_sec_global of een te grove firewallregel op 27015/UDP in aanmerking.

"De CPU staat op 100 procent, de lijn is bijna leeg": dat is het typische beeld van een opvraagvloed of een split-pakketvloed. Kijk in het serverlogboek naar regels met NET_GetLong en meet met de twee tcpdump-regels uit paragraaf 9 welke pakketsoort binnenkomt.

"Mijn nftables- of iptables-regels grijpen niet": drie oorzaken komen vaak voor. De regel staat achter de UFW-ketens en wordt nooit bereikt (vandaar de prioriteit -10), ze was na de laatste herstart verdwenen, of de aanval is volumetrisch en de regel werkt correct aan een lijn die al vol zit. Controleer met nft list ruleset of de tellers oplopen. Blijven ze op nul staan, dan wordt de regel niet bereikt.

"Ik heb het IP-adres gewisseld en was de volgende dag weer offline": de aanvaller vindt het nieuwe adres in dezelfde bron als het oude. Uw server publiceert het zelf zodra hij weer in de serverbrowser staat, en oude DNS-records en Discord-statusbots doen de rest. Een adreswissel levert uren op, geen oplossing.

"De server crasht reproduceerbaar, terwijl de bandbreedte niet opvalt": meestal geen DDoS-aanval, maar een plugin die niet bij de engineversie past, of een verouderde serverbinary. sm plugins list en een vergelijking van de versies helpen hier sneller dan welke filterregel ook.

"De server reageert na stilstand vertraagd": dat is de hibernation en geen fout. Ze drukt de CPU-belasting tot vrijwel nul zolang er niemand verbonden is, en dat is precies de toestand waarin u reserves wilt hebben.

"Er lopen vreemde beheerderscommando's op de server": geen DDoS-aanval, maar een gecompromitteerde RCON-toegang. Wachtwoord direct opnieuw instellen, poort tot het eigen adres beperken, en eraan denken dat het wachtwoord in leesbare vorm over de lijn gaat.

"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.

Kort samengevat

• Een TF2-server heeft naar buiten precies 27015/UDP nodig. RCON op 27015/TCP hoort tot het eigen adres beperkt te blijven, SourceTV op 27020/UDP wordt met -nohltv uitgeschakeld als u niet uitzendt.
• Spelverkeer en A2S-opvraging delen dezelfde poort. Wie 27015/UDP volledig dichtzet of zonder onderscheid begrenst, gooit de eigen spelers eruit. De grens moet tussen de pakketsoorten lopen, herkenbaar aan de eerste vier bytes achter de UDP-kop.
• Split-pakketvloeden met de kop FE FF FF FF veroorzaken CPU-belasting in plaats van bandbreedte en staan in het logboek als NET_GetLong. Een strakke begrenzing van die pakketsoort is bij TF2 verdedigbaar.
• Sinds "Meet Your Match" vinden nieuwe spelers communityservers alleen nog via de serverbrowser. Elke maatregel die u uit die lijst drukt, werkt als de aanval zelf.
• Een volle server met 24 plaatsen verwerkt ongeveer 1.600 inkomende pakketten per seconde. Aanvallen op communitygameservers liggen gebruikelijk tussen 5 en 50 Gbit/s en bij meerdere miljoenen pakketten per seconde.
• 1 Gbit/s draagt bij kleinst mogelijke pakketten ongeveer 1,49 miljoen pakketten per seconde. Boven die grens beslist uitsluitend het netwerk vóór de server, geen enkele regel op de server.
• Bij KernelHost is de permanente bescherming in twee lagen bij elk serverpakket zonder meerprijs inbegrepen en vanaf de oplevering actief, zonder null-routing. De Advanced DDoS Protection komt er vanaf 50,00 € per maand bij als u de regels per poort zelf wilt sturen.

Draait uw server al bij KernelHost, dan is de filtering actief zonder dat u iets hoeft te doen. Merkt u toch iets ongewoons, open dan een supportticket, zodat de filterregels voor uw IP-adres worden bijgesteld. 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. Dat scheelt een ronde extra vragen, en die telt zodra er een match loopt.