Team Fortress 2: skydda TF2-servern mot DDoS-attacker

En Team Fortress 2-community-server som mitt i rundan på kvällen tappar alla spelare samtidigt och därefter försvinner ur serverlistan i flera minuter har sällan ett hårdvaruproblem. I de flesta fall pågår en attack mot 27015/UDP. Den här artikeln visar hur du skyddar en TF2-server mot DDoS-attacker: först det du kan göra själv under de närmaste tio minuterna utan extra kostnad, därefter punkten där de åtgärderna tar slut rent fysiskt, och till sist vad som måste hända i nätet framför servern.

Alla uppgifter gäller en Source-dedikerad server installerad med SteamCMD (srcds_run -game tf) under Debian 12, Debian 13, Ubuntu 22.04 LTS eller Ubuntu 24.04 LTS. Kommandona är skrivna för root, som vanlig användare sätter du sudo framför. Pågår attacken just nu: ändra först ingenting och starta inte om servern, utan säkra mätvärdena ur avsnitt 9. Efter attacken är de borta.

Varför Team Fortress 2-servrar behöver DDoS-skydd

Team Fortress 2 går att spela gratis sedan 2011, och just det förskjuter attackekonomin. En angripare har obegränsat många engångskonton, behöver inte betala för något av dem och riskerar ingenting vid en avstängning. Det som kostar pengar i ett köpspel kostar här en minut.

Till det kommer en egenhet som skiljer TF2 från de flesta andra spel: sedan uppdateringen "Meet Your Match" i juli 2016 finns inget Quickplay längre, som automatiskt fördelade nya spelare på community-servrar. Nya spelare hamnar i Casual-läget på Valves servrar. Community-servrar går uteslutande att hitta via serverlistan. Den som faller ur den listan finns praktiskt taget inte längre för nya spelare, även om serverprocessen körs felfritt. En attack som bara tränger ut din server ur listan har därmed redan nått sitt mål.

Typiska mål är följaktligen: community-servrar som körs dygnet runt med stamspelare (2Fort dygnet runt, Trade, Jailbreak, Surf, Dodgeball, Mann vs. Machine), ligaservrar med fast matchtid i ligadriften hos ETF2L, RGL och ozfortress, samt servrar vars operatörer just har stängt av någon. Utlösaren är nästan aldrig teknisk. Vad en DDoS-attack över huvud taget är förklaras i artikeln Vad är en DDoS-attack?.

Portarna som det faktiskt handlar om hos en TF2-server

En TF2-server behöver exakt en port utåt: 27015/UDP. Allt annat går antingen att stänga av, hör hemma begränsat eller löper ändå bara utgående. Den här tabellen är grunden för varje brandväggsregel längre ned:

Vid flera instanser på en maskin räknar numren uppåt: 27016, 27017 och så vidare för spelet, 27021 och 27022 för SourceTV. Konfigurationsfilen ligger under tf/cfg/server.cfg och läses in på nytt vid varje kartbyte.

Varför den delade porten 27015 är den känsligaste punkten

Speltrafik och serverförfrågan delar samma UDP-port hos TF2, någon separat query-port finns inte. En A2S_INFO-förfrågan är därvid exakt 25 byte lång: fyra byte FF FF FF FF, en byte 0x54 och den 20 byte långa teckensträngen "Source Engine Query" med avslutande noll. Svaret med servernamn, karta, spelarantal och taggar är ett flertal gånger så stort. Den amerikanska myndigheten CISA anger Steam-protokollets förstärkningsfaktor i Alert TA14-017A till 5,5.

Eftersom UDP inte känner till någon uppkoppling och avsändaradresser går att förfalska var det i åratal ett öppet förstärkningshål: en angripare frågade främmande Source-servrar med sitt offers adress som avsändare, och servrarna skickade sina svar till offret. A2S_PLAYER och A2S_RULES krävde alltid en i förväg hämtad challenge, A2S_INFO inte. Först i december 2020 kompletterade Valve även A2S_INFO med en challenge: servern får i stället för svaret skicka tillbaka en S2C_CHALLENGE som frågeställaren måste upprepa, varmed han bevisar att han inte har förfalskat avsändaradressen.

Det tar udden av reflektionen men gör inte slut på besväret. Varje förfrågningspaket kommer fortfarande fram till dig och kostar beräkningstid innan det besvaras eller kasseras. Och en angripare som översvämmar din server direkt behöver ändå ingen förstärkning.

Vad du kan göra själv innan du lägger ut pengar

Det här avsnittet är det längsta, och det är avsiktligt. En rent konfigurerad TF2-server klarar små och medelstora attacker av egen kraft, oavsett hos vem den står.

1. Inventering: vad lyssnar, och med vilken startrad

Innan du skriver en enda regel tittar du efter vad din server erbjuder utåt. Inte gissa, titta efter:

ss -lntup

Allt som är bundet till 127.0.0.1 eller ::1 behöver ingen öppning. Allt på 0.0.0.0 eller [::] är nåbart från internet, även MySQL-databasen som ett statistiktillägg har fört med sig och webbservern där dina FastDL-filer ligger. Jämför resultatet med din startrad:

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

Varje port i den raden är ett medvetet beslut. Hur underlaget installeras står i Installera spelservrar med SteamCMD.

2. Lämna bara de portar öppna som TF2 verkligen behöver

En publik TF2-server behöver exakt en öppning utåt, plus RCON för din egen adress. Med UFW, och då i den här ordningen så att du inte låser ute dig själv:

ufw allow 22/tcp comment 'SSH'
ufw allow 27015/udp comment 'TF2 spel och 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

Ersätt 203.0.113.10 med din egen adress. SourceTV dyker medvetet inte upp här: den som inte sänder startar med -nohltv och upptar aldrig 27020/UDP. Det halverar den utifrån nåbara UDP-ytan hos en TF2-server. Sänder du ligamatcher tillkommer ufw allow 27020/udp, och då hör ett tv_password hemma i konfigurationen.

Den fullständiga anvisningen inklusive räddningsvägen står i Sätta upp UFW-brandväggen utan att låsa ute dig själv. Skulle det ändå hända: KVM-rootservrar och dedikerade servrar från KernelHost når du via VNC-konsolen i kundportalen, som arbetar oberoende av gästsystemets nätverk.

3. Begränsa A2S-förfrågningar utan att åka ur serverlistan

Här ligger det dyraste felet i det här ämnesområdet: att spärra 27015/UDP generellt eller hastighetsbegränsa den grovt kastar ut dina egna spelare och avslutar attacken i angriparens mening. Eftersom speltrafik och förfrågan upptar samma port måste gränsen löpa mellan pakettyperna, inte på porten.

Motorn har tre konsolvariabler för det, och de hör hemma i tf/cfg/server.cfg:

sv_max_queries_sec 3
sv_max_queries_sec_global 60
sv_max_queries_window 30

Den första begränsar de besvarade förfrågningarna per avsändaradress, den andra summan över alla adresser, den tredje fastställer medelvärdesfönstret i sekunder. De skyddar processorn från att meningslöst producera svar. Standardvärdena skiljer sig åt mellan spel och byggen, find sv_max_queries i serverkonsolen visar vilka värden din server känner till.

Det andra värdet är det känsliga hos TF2: det sätter ett tak för svaren över alla adresser. Sätter du det för lågt besvarar din server under en förfrågningsflod inte längre heller listtjänsternas förfrågningar och försvinner ur serverlistan, alltså ur den enda vägen på vilken nya spelare hittar dig. Börja generöst och dra åt först när du kan mäta att legitima förfrågningar kommer fram.

Ett lager längre ned går samma trafik att skilja av rent. Alla anslutningslösa paket i Source-motorn börjar med fyra satta byte (0xffffffff), trafiken från redan anslutna spelare har inte det huvudet. På det går det att lägga en hastighetsbegränsning utan att röra speltrafiken:

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
    }
}

Filen läser du in med nft -f. Prioriteten -10 ser till att regeln griper före UFW:s filterkedja, och @th,64,32 läser de första fyra byten bakom UDP-huvudet.

4. Fånga upp split-paketfloder som dyker upp i loggen som NET_GetLong

Den här attacken är en egenhet hos Source-motorn och träffar TF2 särskilt, eftersom TF2 än i dag körs på den gamla motorgrenen. Vid sidan av de vanliga anslutningslösa paketen känner motorn till uppdelade paket: de börjar med FE FF FF FF i stället för FF FF FF FF och aviserar att ett större meddelande följer i flera delar. Servern måste mellanlagra delarna och vänta på resten.

Just det går att missbruka. En angripare skickar massvis med aviserade men aldrig fullständiga delpaket med förfalskade avsändaradresser. Processorlasten stiger, spelet hackar, och i serverloggen hopar sig rader med NET_GetLong. En enda dator räcker för det, bandbredd behövs knappt. Operatörer rapporterar det regelbundet som en DDoS-attack, trots att ledningen är nästan tom.

Eftersom en vanlig TF2-klient knappast har anledning att skicka uppdelade paket till servern är en snäv begränsning försvarbar här:

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

Raden hör hemma i samma kedja som regeln ur avsnitt 3. En av de få legitima anledningarna till klientuppladdningar tar du dessutom bort med sv_allowupload 0 (se avsnitt 7).

5. Ta RCON ur det öppna nätet

Source-motorns RCON-protokoll överför lösenordet i klartext över TCP. Den som kan läsa med på vägen mellan dig och servern har därefter ditt RCON-lösenord, och den som har RCON kan byta karta, stänga av alla spelare och stoppa servern. Det är inget DDoS-problem utan ett övertagande, men det rapporteras regelbundet som en attack.

Lämna aldrig rcon_password tomt och gör det aldrig gissningsbart, ett värde från openssl rand -base64 32 räcker. Till det hör en broms mot inloggningsförsök:

rcon_password "HÄR_DET_SLUMPMÄSSIGA_VÄRDET"
sv_rcon_maxfailures 3
sv_rcon_minfailures 3
sv_rcon_minfailuretime 30
sv_rcon_banpenalty 1440

Därmed spärrar servern en adress i 24 timmar efter tre misslyckade försök inom 30 sekunder; find sv_rcon visar vilka variabler ditt bygge känner till. Verksammare förblir ändå brandväggsregeln ur avsnitt 2, eftersom den inte ens släpper fram försöket till applikationen. För åtkomst från växlande uppkopplingar sätter du upp en lokal vidarebefordran över SSH och talar sedan med RCON på 127.0.0.1:

ssh -N -L 27015:127.0.0.1:27015 root@DIN.SERVER.IP.ADRESS

6. Sätt tak för raterna och låt viloläget vara påslaget

Team Fortress 2 körs fast med 66,67 tick per sekund. Hur mycket trafik det blir av det avgörs inte av ticken, utan av vad en enskild klient får begära. Utan övre gräns hämtar varje spelare så mycket som hans klient kräver, och det betalar du med din utgående bandbredd:

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

Räkna igenom det en gång: vid sv_maxrate 100000 får varje spelare hämta 100 kilobyte per sekund, på 24 platser blir det 2,4 megabyte per sekund eller runt 19 Mbit/s utgående. Sätter du sv_maxrate 0 finns ingen övre gräns. Ligaservrar gör det medvetet, en publik server med många platser bör inte göra det. Tillägg som låser upp tickfrekvensen mångdubblar paketfrekvensen per spelare och därmed samma uträkning.

Den andra punkten blir ofta fel. TF2 somnar in så snart ingen är ansluten och behöver i det tillståndet nästan ingen processorkraft. Många operatörer stänger av det för att servern ska kännas "vaken". På en maskin med flera instanser betyder det att processorn är belastad redan i tomgång och att en attack träffar ett redan fullt system. Låt standardinställningen stå:

sv_hibernate_when_empty 1
sv_hibernate_postgame_delay 5
tf_allow_server_hibernation 1

7. Separera FastDL och stäng av uppladdningar

Community-servrar lever på egna kartor, och just därur uppstår en andra angreppsyta. Utan sv_downloadurl hämtar varje spelare innehållet över spelets nätkanal, alltså över samma port och samma process som samtidigt räknar matchen. Det är några få kilobyte per sekund och en fil i taget, och vid en 200 megabyte stor kartsamling blockerar det din server i flera minuter per spelare:

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

net_maxfilesize står som standard på 15 och går att höja till högst 64 megabyte. sv_allowupload 0 hindrar klienter från att skicka egna filer (till exempel sprejbilder) till servern och tar därmed bort en av de få legitima anledningarna till uppdelade paket ur avsnitt 4.

Avgörande är var FastDL-värden står. Ligger den på samma IP-adress som spelservern räcker en HTTP-flod mot 443/TCP för att fylla ledningen och därmed kväva även 27015/UDP. Lägg den snabba nedladdningen på en annan värd eller bakom ett innehållsnätverk, då träffar en attack mot filerna inte spelet.

8. Begränsa röstsystem, anslutningsfloder och tillägg

Inte varje avbrott är bandbredd. Eftersom TF2 är gratis kostar en attack mot spellogiken inget annat än konton: anslutningsfloder som upptar varje plats, röst- och chattspam, och missbrukade omröstningar som kastar ut vanliga spelare. TF2:s standardinställningar är redan förnuftiga här, men de luckras ofta upp:

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

Det är standardvärdena: omröstningar är tillåtna, kick-omröstningar inte, åskådare röstar inte med, mellan två omröstningar ligger 150 sekunder, efter en misslyckad 300, och en omröstning behöver 60 procents bifall. Den som sätter sv_vote_issue_kick_allowed 1 bör veta att han därmed öppnar ett verktyg som på en publik server missbrukas tillförlitligt.

Allt därutöver kommer hos TF2 från SourceMod och Metamod:Source. Båda ligger under tf/addons/ och anmäler sig i konsolen med meta version och sm version. Till skillnad från Counter-Strike 2 är underlaget här moget, och tillägg för spärrlistor, anslutningskontroll och chattbegränsning är den vanliga vägen. Två regler till det: varje tillägg är kod i samma process, ett tillägg som kraschar tar servern med sig. Och tillägg som har med sig egna webbtjänster öppnar ytterligare portar och offentliggör ibland precis den adress du vill skydda. sm plugins list visar vad som faktiskt körs.

Hur allvarligt motorsidan är att ta visar april 2020: efter att äldre källkodsversioner av TF2 och CS:GO läckt ut stängde stora community-operatörer som Creators.TF och Red Sun tillfälligt av sina servrar av oro för utnyttjande. Håll serverbinären aktuell och utvidgningarna passande till motorversionen.

9. Mät och logga innan det brinner

Det viktigaste steget är det som nästan ingen gör i förväg: att lägga upp en jämförelsegrund så länge allt går normalt. Utan normalvärde kan du efter en händelse inte säga om 40 000 paket per sekund var mycket eller helt enkelt fredagskväll. Under en händelse räcker fyra kommandon:

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"

Det första kommandot visar paket, fel och kasserat per gränssnitt; kör det två gånger med tio sekunders mellanrum, då har du en frekvens i stället för ett absolutvärde. De båda inspelningarna skiljer förfrågningsfloden från split-paketfloden och besvarar därmed frågan om vilken av de två reglerna ur avsnitt 3 och 4 som över huvud taget måste gripa. Begränsa dem alltid med -c, en inspelning under full last kostar själv beräkningstid.

Inne i servern levererar konsolkommandot stats på en rad processorlasten, den in- och utgående nätlasten i kilobyte per sekund, serverns FPS och spelarantalet. Faller server-FPS tydligt under tickvärdet medan spelarantalet är normalt arbetar servern med något annat än spelet. Hur du tolkar värdena står i Känna igen en DDoS-attack på servern.

Var de här åtgärderna tar slut: bandbredd och paketfrekvens

Nu den del som ingen konfigurationsfil kan lösa. Alla åtgärder hittills körs på din server, alltså i änden av ledningen. En brandväggsregel avgör om ett paket som redan har gått över kabeln. Du kan kassera det, men inte göra det osänt.

Ställ normaldriften på en full TF2-server bredvid en verklig attack, då blir förhållandet tydligt:

En typisk spelserver hänger på 1 Gbit/s, det är 125 megabyte per sekund, och ledningen är full så snart någon skickar mer. Den andra storheten är paketfrekvensen, och den slår oftast till tidigare än bandbredden: varje paket kostar ett varv genom nätverksstacken, även om det kasseras efteråt. En attack som inte ens fyller en tredjedel av din ledning lamslår därför ändå din server. Operatörer upplever det som "belastningen var ju inte ens hög, ändå var allt borta".

Till inordningen av vilka storleksordningar som faktiskt förekommer: på KernelHost-servrar har bland annat en UDP-flod mot en spelserver med över 112,2 Gbit/s vid över 8,7 miljoner paket per sekund och en multivektorattack mot en röstserver med över 473,4 Gbit/s vid över 41,5 miljoner paket per sekund filtrerats i realtid. 473,4 Gbit/s är runt 470 gånger en 1 Gbit/s-anslutning. För det finns ingen lokal inställning.

De två utbredda nödbromsarna hjälper inte vidare. Null-routning tar den angripna IP-adressen ur nätet och avslutar attacken, men också din server. En reaktiv omledning kostar i omkopplingstiden precis de minuter under vilka matchen avgörs. Verksam är bara en filtrering som löper permanent i nätet framför servern.

Vad KernelHost ställer mot attacker på TF2-servrar

Det permanenta skyddet som ingår i varje serverpaket

DDoS-skyddet från KernelHost är uppbyggt i två steg och permanent aktivt från leveransen, utan att du behöver beställa, slå på eller konfigurera något:

• Steg 1: 17 Tbps mitigeringskapacitet i det globala scrubbing-nätverket. Volumetriska attacker rensas nära sin källa, innan de når datacentret.
• Steg 2: Arbor-realtidsfiltrering med 3,2 Tbps i Frankfurt am Main. Direkt framför servern känns protokollspecifika mönster igen och kasseras, paket för paket.

Två egenskaper är avgörande för en TF2-server. Filtreringen löper permanent och måste inte först reagera på en attack, det finns alltså ingen omkopplingstid där dina spelare åker ut och din server faller ur serverlistan. Och ingen null-routning används: din IP-adress stannar i nätet, bara de skadliga paketen kasseras. Vilka spel och protokoll som täcks listas i DDoS-skydd för spelservrar i realtid.

Advanced DDoS Protection för servrar under ständig beskjutning

Vissa projekt angrips inte då och då, utan riktat och under veckor, med växlande mönster och alltid precis till matchtiden. För det finns Advanced DDoS Protection från 50,00 EUR i månaden, PrePaid och utan bindningstid. Skillnaden ligger inte i mer kapacitet utan i kontrollen:

• Dedikerad skydds-IP ur Frankfurt-kärnan, som din server ställs om till i vårt nät. På din sida behövs ingen ombyggnad.
• Egenförvaltade skyddsregler per port och protokoll i kundportalen: du ställer in separat vad som är tillåtet på 27015/UDP, vad på 27020/UDP och vad på 27015/TCP, utan att skriva ett ärende för det.
• Ändringar griper i realtid, du kan alltså justera under en pågående attack i stället för att vänta till matchens slut.
• Skyddsprofil passande till spelet, för Team Fortress 2 och de övriga Source-titlarna lika väl som fria TCP- och UDP-profiler för egna applikationer.

Erbjudandet riktar sig till servrar som körs hos KernelHost. Står din TF2-server för närvarande någon annanstans och beskjuts regelbundet är flytten vägen till det här skyddet.

De två stegen i jämförelse

För de flesta TF2-community-servrar räcker det inkluderade permanenta skyddet tillsammans med en ren serverkonfiguration. Advanced DDoS Protection är svaret på att någon tar det personligt.

Vanliga fel och lösningar

"Servern körs, men den står inte längre i serverlistan": kontrollera först Game Server Login Token. TF2-servrar behöver ett token för den publika posten, satt via sv_setsteamaccount och skapat för app-ID 440. Steam drar tillbaka token som inte har använts på 30 dagar. En server som försvinner efter ett längre uppehåll behöver alltså ofta bara ett nytt token och angrips inte alls. Först därefter kommer ett för lågt satt sv_max_queries_sec_global eller en för grov brandväggsregel på 27015/UDP i fråga.

"Processorn står på 100 procent, ledningen är nästan tom": det är den typiska bilden av en förfrågnings- eller split-paketflod. Se efter i serverloggen efter rader med NET_GetLong och mät med de två tcpdump-raderna ur avsnitt 9 vilken pakettyp som kommer fram.

"Mina nftables- eller iptables-regler griper inte": tre orsaker är vanliga. Regeln står bakom UFW-kedjorna och nås aldrig (därav prioriteten -10), den var borta efter den senaste omstarten, eller så är attacken volumetrisk och regeln arbetar korrekt vid en ledning som redan är full. Kontrollera med nft list ruleset om räknarna stiger. Stannar de på noll nås regeln inte.

"Jag bytte IP-adress och var offline igen nästa dag": angriparen hittar den nya adressen ur samma källa som den gamla. Din server offentliggör den själv så snart den står i serverlistan igen, och gamla DNS-poster samt Discord-statusbotar gör resten. Ett adressbyte ger timmar, ingen lösning.

"Servern kraschar reproducerbart utan att bandbredden märks": oftast ingen DDoS-attack, utan ett tillägg som inte passar till motorversionen, eller en föråldrad serverbinär. sm plugins list och en avstämning av versionsnivåerna är här snabbare än varje filterregel.

"Servern reagerar fördröjt efter tomgången": det är viloläget och inget fel. Det sänker processorlasten till nära noll så länge ingen är ansluten, och det är precis det tillstånd i vilket du vill ha reserver.

"På servern körs främmande administrationskommandon": ingen DDoS-attack, utan en komprometterad RCON-åtkomst. Sätt lösenordet på nytt omedelbart, begränsa porten till den egna adressen, och tänk på att lösenordet går över ledningen i klartext.

"Min tidigare leverantör spärrade min IP-adress": det är null-routning. Leverantören skyddar därmed sitt eget nät, för dig är resultatet identiskt med en lyckad attack, oftast i ytterligare timmar efteråt. Fråga vid tveksamhet efter om det filtreras eller null-routas. Svaret avgör mer om din tillgänglighet än någon hårdvaruuppgift.

Kort sammanfattat

• En TF2-server behöver utåt exakt 27015/UDP. RCON på 27015/TCP hör hemma begränsat till den egna adressen, SourceTV på 27020/UDP stängs av med -nohltv om du inte sänder.
• Speltrafik och A2S-förfrågan delar samma port. Den som spärrar eller hastighetsbegränsar 27015/UDP generellt kastar ut sina egna spelare. Gränsen måste löpa mellan pakettyperna, igenkännlig på de första fyra byten bakom UDP-huvudet.
• Split-paketfloder med huvudet FE FF FF FF skapar processorlast i stället för bandbredd och står i loggen som NET_GetLong. En snäv begränsning av den pakettypen är försvarbar hos TF2.
• Sedan "Meet Your Match" hittar nya spelare community-servrar bara via serverlistan. Varje åtgärd som tränger ut dig ur listan verkar som attacken själv.
• En full server med 24 platser bearbetar runt 1 600 inkommande paket per sekund. Attacker mot community-spelservrar ligger vanligen på 5 till 50 Gbit/s och flera miljoner paket per sekund.
• 1 Gbit/s bär vid minsta paket runt 1,49 miljoner paket per sekund. Över den gränsen avgör uteslutande nätet framför servern, ingen regel på servern.
• Hos KernelHost ingår det permanenta skyddet i två steg i varje serverpaket utan extra kostnad och är aktivt från leveransen, utan null-routning. Advanced DDoS Protection tillkommer från 50,00 EUR i månaden om du vill styra reglerna per port själv.

Körs din server redan hos KernelHost är filtreringen aktiv utan att du behöver göra något. Märker du ändå något avvikande, öppna ett supportärende så att filterreglerna för din IP-adress justeras. Vid en pågående attack når du oss dessutom via WhatsApp-nödchatten på +43 650 8209883. Ange då direkt fyra uppgifter: IP-adress, port, tidsrum i din tidszon och vad du ser. Det besparar en omgång följdfrågor, och den räknas när en match pågår.