Skydda Garry's Mod-server mot DDoS-attacker

En Garry's Mod-server som försvinner i tre minuter vid åttatiden på kvällen och sedan kommer tillbaka har sällan ett hårdvaruproblem. I de allra flesta fall pågår en attack, och den pågår precis när flest spelare är anslutna. DDoS-skydd för Garry's Mod betyder därför i första hand: att veta vilka paket som över huvud taget får komma fram till din server. Den här artikeln visar i den ordningen vad du kan säkra själv under de närmaste tio minuterna utan att betala en enda cent, var de åtgärderna tar slut rent fysiskt, och vad som därefter måste hända i nätet framför servern.

Alla uppgifter gäller en srcds-server under Debian 12, Debian 13, Ubuntu 22.04 LTS eller Ubuntu 24.04 LTS. Konfigurationsfilen ligger under garrysmod/cfg/server.cfg, kommandona är skrivna för root, som vanlig användare sätter du sudo framför. Det handlar hela tiden om drift på en egen rootserver eller dedikerad server, inte om en plats hos en spelserverleverantör.

Om attacken pågår just nu: ändra ingenting i server.cfg nu och starta inte om srcds. Säkra först mätvärdena (avsnitt 9), för efter attacken är de borta. En omstart kostar dig räknarna och sätter sedan tillbaka servern i samma flod.

Varför en Garry's Mod-server behöver DDoS-skydd

En Garry's Mod-server publicerar sin IP-adress och sin port helt på egen hand. Det är inget misstag utan en förutsättning: den som inte står i serverlistan får inga nya spelare. Posten uppstår genom att servern registrerar sig hos Steams masterserver och därefter besvarar varje A2S-förfrågan som kommer utifrån. Frågan är alltså aldrig om en angripare hittar din adress, utan bara vad som händer när han skjuter på den.

Till det kommer communityernas karaktär. Garry's Mod spelas till övervägande del inte i rundor utan i bestående världar: en DarkRP-community för spelarkonton, ägodelar, jobb och framsteg i en databas under månader. Ett avbrott på fredagskvällen kostar därmed mer än en förlorad match, det kostar stamspelare. Just därför är konkurrerande communityer, bannlysta spelare och köpta booter-tjänster (tjänster som för några euro i månaden utlöser attacker mot en godtycklig adress) de tre vanligaste utlösarna. Angriparen behöver varken kunskap eller några nämnvärda pengar för det.

Tekniskt sammanfaller tre egenheter. Speltrafiken går över UDP, och UDP känner inte till någon uppkoppling som man skulle kunna kräva: avsändaradresser går att förfalska. Serverförfrågan ligger på samma port som spelet, en grov spärr träffar alltså alltid båda. Och över allt detta ligger Lua: varje Workshop-tillägg för in egen kod i samma process, och en enda oskyddad nätverkshändelse räcker för att en ensam klient ska bromsa servern helt utan bandbredd. Vad en DDoS-attack är i grunden förklaras i artikeln Vad är en DDoS-attack?.

Portarna som det faktiskt handlar om hos Garry's Mod

En Garry's Mod-server startar som standard på port 27015, närmare bestämt på UDP för spelet inklusive serverförfrågan och på TCP för RCON. Numret ändras vid start med -port, vid flera instanser räknar man uppåt (27016, 27017 och så vidare). Ett typiskt startkommando ser ut så här:

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

Därav följer hela angreppsytan. Tabellen nedan är grunden för varje brandväggsregel längre ned:

Av dessa åtta poster hör exakt en hemma i det öppna nätet utan inskränkning: 27015/UDP. Allt annat begränsas antingen till din egen adress, binds till 127.0.0.1 eller startas inte alls. Det dyraste tankefelet på det här området är antagandet att Garry's Mod skulle ha en separat query-port som man enkelt kan stänga. Den finns inte.

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 Garry's Mod-server klarar små och medelstora attacker av egen kraft, oavsett hos vem den står. Ingenting av det kostar pengar, och det mesta är avklarat på en kvart.

1. Inventering: vad lyssnar egentligen

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

ss -lntup

Intressant är kolumnen med den lokala adressen. 0.0.0.0:27015 och [::]:27015 betyder "nåbar från hela internet", 127.0.0.1:3306 betyder "bara lokalt" och behöver ingen brandväggsregel. På en DarkRP-server som vuxit fram finns där nästan alltid fler tjänster än väntat: MySQL, en webbserver för FastDL, en panel, en Discord-bot, en andra testserver på 27016 och en bortglömd rösttjänst. Angriparens vy får du med en portskanning utifrån:

nmap -Pn -sU -sT -p- --min-rate 1000 DIN.SERVER.IP.ADRESS

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

För Garry's Mod räcker en enda öppning utåt, plus SSH och den begränsade RCON-åtkomsten. Med UFW ser det ut så här, och då i exakt den ordningen så att du inte låser ute dig själv:

ufw allow 22/tcp comment 'SSH'
ufw allow 27015/udp comment 'Garrys Mod 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 på 27020/UDP öppnar du bara om du verkligen sänder. 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 har varken IPMI eller iDRAC, du tar dig tillbaka via VNC-konsolen i kundportalen. Den hänger inte på gästsystemets nätverksstack, en brandväggsregel i gästen kan inte blockera den.

Databasen hör under inga omständigheter hemma i det öppna nätet. Kontrollera i /etc/mysql/mariadb.conf.d/50-server.cnf att det står:

bind-address = 127.0.0.1

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

Här ligger felet som kostar de flesta Garry's Mod-servrar. Eftersom speltrafik och serverförfrågan upptar samma port kastar en generell spärr eller en alltför snäv hastighetsbegränsning på 27015/UDP ut dina egna spelare och fullbordar attacken själv. Rätt ansats är att skilja mellan förfrågningspaket och spelpaket.

Motorn har tre konsolvariabler för det, och de står i server.cfg. Deras standardvärden är konservativa, men de är satta:

sv_max_queries_sec 3
sv_max_queries_sec_global 60
sv_max_queries_window 30

sv_max_queries_sec begränsar de besvarade förfrågningarna per avsändaradress (standard 3 per sekund), sv_max_queries_sec_global sätter ett tak för summan över alla adresser (standard 60 per sekund), sv_max_queries_window fastställer medelvärdesfönstret (standard 30 sekunder). De värdena skyddar processorn från att meningslöst producera svar. De hindrar inte paketen från att komma fram, och den som drar det globala värdet mycket snävt försvinner ur serverlistan under attacken, eftersom även listsidornas förfrågningar blir obesvarade.

Ett lager längre ned går förfrågningstrafiken 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. Just på det går det att lägga en hastighetsbegränsning per källadress med nftables:

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

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. Med klassiska iptables gör en u32-jämförelse samma sak:

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

En punkt som nästan varje guide på nätet utelämnar: det är inte bara serverförfrågan som är anslutningslös, det är uppkopplingen också. En spelare som ansluter skickar flera paket med samma huvud innan han är inne i spelet. En alltför snäv gräns spärrar därför ute nya spelare, trots att servern förblir nåbar. Börja generöst (8 till 15 paket per sekund och adress) och dra åt gränsen först när du har mätt en vecka av normal drift.

4. Säkra RCON eller stäng av det helt

RCON är ett omtyckt mål på Source-servrar, och det av tre skäl samtidigt. För det första ligger det på samma portnummer som spelet, bara på TCP, och är därmed hittat utan att någon behöver leta. För det andra överför Source-RCON-protokollet lösenordet i klartext, utan TLS och utan nyckelutbyte: den som läser med i trafiken har det. För det tredje är vinsten maximal, för den som har RCON kan byta karta, bannlysa alla spelare, ändra konfigurationen och stoppa servern. En angripare som tar över RCON behöver ingen bandbredd alls längre.

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

rcon_password "ETT_LÅNGT_SLUMPMÄSSIGT_LÖSENORD"
sv_rcon_minfailures 3
sv_rcon_maxfailures 5
sv_rcon_minfailuretime 30
sv_rcon_banpenalty 1440

Därmed spärras en adress i ett dygn efter tre misslyckade försök inom 30 sekunder. Två varningar till det. För det första spärrar exakt den mekanismen även din egen adminpanel, om ett gammalt lösenord finns sparat där: det operatörer rapporterar som "RCON fungerar plötsligt inte längre" är oftast den egna spärren. För det andra förblir brandväggsbegränsningen från steg 2 mer verksam, eftersom den inte ens släpper fram försöket till applikationen. Den som bara behöver RCON då och då håller porten helt stängd och arbetar via en SSH-portvidarebefordran:

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

5. Begränsa Lua-nätverksmeddelanden, det vanligaste självförvållade avbrottet

En betydande del av de Garry's Mod-avbrott som rapporteras som DDoS är inga sådana. Det är Lua-överbelastningar, utlösta av en enda ansluten klient med några få kilobit per sekund. Orsaken ligger i hur net-biblioteket är byggt: så snart ett tillägg registrerar en nätverkshändelse med util.AddNetworkString och lyssnar på den med net.Receive kan vilken klient som helst utlösa den händelsen i en slinga. Utan egen begränsning utför servern varje enskilt meddelande. Facepunch har dokumenterat det flera gånger i sina egna felrapporter och har inte byggt in någon lösning i motorn, begränsningen är uttryckligen tilläggsförfattarens uppgift.

Kontrollera därför varje eget och varje inköpt tillägg på tre punkter: ett tak per spelare och sekund, en kontroll av meddelandets längd, och att spelaren fastställs på serversidan ur den andra parametern i stället för ur meddelandets innehåll. Ett bärkraftigt mönster ser ut så här:

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)

Till det hör två rader i server.cfg. sv_allowcslua står som standard på 1 i Garry's Mod och tillåter klienter att köra egen kod med lua_run_cl och lua_openscript_cl: på en publik server hör värdet hemma på 0. Och sv_kickerrornum kopplar bort klienter som producerar fler än det angivna antalet klientsidiga fel (standard 0, alltså avstängt):

sv_allowcslua 0
sv_kickerrornum 25

6. Separera Workshop-innehåll och FastDL från spelservern

Workshop-tillägg är inget randfenomen hos Garry's Mod utan normalfallet: en DarkRP-community binder in sin samling med +host_workshop_collection, och klienterna hämtar det innehållet direkt från Steam. Det belastar inte din ledning. Nyckeln bakom -authkey är en Steam Web API-nyckel och ska behandlas som ett lösenord: i startskriptet, inte i ett publikt kodarkiv och inte i en Discord-kanal.

Bandbredden kostar den andra vägen. Allt som inte kommer från Workshop (egna kartor, ljud, material) går via nedladdningskanalen. Utan sv_downloadurl går den kanalen över själva spelporten och konkurrerar direkt med speltrafiken. Med FastDL går den över HTTP. Om den webbservern ligger på samma värd och samma IP-adress delar båda på samma ledning: en anslutningsvåg eller en attack mot 80/TCP träffar därmed även spelet. Rimliga värden är dessa:

sv_downloadurl "https://fastdl.din-doman.se/garrysmod/"
sv_allowdownload 1
sv_allowupload 0
net_maxfilesize 64

sv_allowupload 0 tar ifrån klienterna möjligheten att skicka egna filer till servern och stänger därmed en väg som varken behövs eller kontrolleras. net_maxfilesize begränsar storleken på de filer som överförs via spelkanalen, angiven i megabyte. Lägg om möjligt FastDL på en annan värd eller bakom ett eget namn, då ligger lasten inte på samma adress som spelporten.

7. Fånga upp anslutningsflod och platsutmattning

Platsutmattning är en attack som inte behöver någon bandbredd: angriparen upptar alla lediga platser med automatiserade anslutningar, så att riktiga spelare ser ett fullsatt hus. Hos Garry's Mod tillkommer att varje anslutning kostar servern arbete, eftersom resurslista och spelläge förhandlas långt innan spelaren är inne i spelet.

Mot det verkar fyra saker. För det första ett realistiskt tak: att sätta +maxplayers högre än ditt spelläge tål förstorar bara angreppsytan. För det andra sv_timeout, som fastställer efter hur många sekunder utan meddelande en klient kopplas bort (120 i de utbredda konfigurationerna): den som vill bli av med hängande halvanslutningar snabbare sätter värdet lägre. För det tredje hastighetsbegränsningen av de anslutningslösa paketen från steg 3, för uppkopplingen går just via dem. För det fjärde, för slutna grupper, ett serverlösenord:

sv_password "stamgruppen_2026"
sv_timeout 90
sv_filterban 1
sv_region 3

Någon riktig vitlista har Garry's Mod inte med sig, den kommer via tillägg som ULX eller via en egen kontroll i kroken CheckPassword. Och en sak måste stå klar: en vitlista skyddar din spellogik, inte din ledning. En angripare som översvämmar din server vill inte ansluta alls. Hans paket avvisas, men de har ändå kommit fram, och det är precis poängen.

8. Avlasta kärnan: anslutningsspårning och mottagningsbuffert

Det här steget förklarar avbrott som ser ut som en volymattack men inte är det. Kärnan lägger upp poster i anslutningsspårningen (conntrack) för UDP-trafik, och vid förfalskade avsändaradresser betyder varje adress en ny post. Är tabellen full kasserar kärnan paket utan åtskillnad: attacken och dina spelare åker ut tillsammans, och i systemloggen står "nf_conntrack: table full". Läge och tak visar:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

Det verksammaste steget är att inte låta speltrafiken spåras alls, för motorn förvaltar sina sessioner själv:

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

Med iptables lyder motsvarigheten iptables -t raw -A PREROUTING -p udp --dport 27015 -j NOTRACK och samma rad för OUTPUT med --sport. Porten behöver därefter en uttrycklig öppning, för utan spårning griper ingen regel längre som prövar mot ett befintligt tillstånd. Kommer paketen dessutom fram snabbare än srcds hämtar dem svämmar mottagningsbufferten över, och för spelarna ser det ut som paketförlust på en ledig ledning:

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

Raderna hör hemma i en fil under /etc/sysctl.d/ och blir aktiva med sysctl --system. Om de behövs avslöjar kärnan själv: stiger UdpRcvbufErrors i nstat -az, då griper de. Stannar räknaren på noll ändrar justeringen ingenting. Det är reserv, inte skydd.

9. Säkra mätvärden så länge allt går normalt

Det viktigaste steget är det som nästan ingen gör i förväg: att lägga upp en jämförelsegrund. Utan normalvärde kan du efter en händelse inte säga om 40 000 paket per sekund var mycket eller helt enkelt lördagskväll. Räkna ut normalvärdet för din server en gång: 64 spelare med cl_cmdrate 66 ger runt 4 200 inkommande paket per sekund, allt tydligt däröver kräver en förklaring. Med apt-get install -y vnstat sysstat löper mätningen varaktigt med. Under en händelse räcker fyra kommandon:

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"

Det första visar paket och byte per sekund, det andra gränssnittets räknare för kasserade paket, det tredje kärnans UDP-felräknare. Den fjärde raden visar uteslutande de anslutningslösa paketen, alltså precis den klass som en förfrågningsflod missbrukar: fylls räknaren på några sekunder medan knappt någon är ansluten har du ditt svar. Begränsa alltid tcpdump med -c, en inspelning under full last belastar en redan överbelastad server ytterligare. Hur du tolkar värdena står i Känna igen en DDoS-attack på servern.

Vad är A2S-reflektionshålet och berör det mig fortfarande

A2S-reflektion är en attack där din server inte är målet utan verktyget. Angriparen skickar en liten förfrågan med förfalskad avsändaradress till tusentals spelservrar, och deras betydligt större svar löper alla samman hos det egentliga offret. Historiskt var en A2S_INFO-förfrågan 25 byte stor (4 byte 0xFFFFFFFF, 1 byte 0x54, plus 20 byte för teckensträngen "Source Engine Query"), svaret däremot flera hundra byte. US-CERT för upp Steam-protokollet i sin lista över förstärkningsattacker med en faktor på 5,5, vilket betyder: av en gigabit hos angriparen blir 5,5 gigabit hos offret.

Valve stängde det hålet från november 2020, och det på två sätt. Anslutningslösa förfrågningspaket måste sedan dess fyllas ut av avsändaren till 1 200 byte, varmed förfrågan är större än svaret och förstärkningsfaktorn faller under 1. Under omställningen kunde operatörer framtvinga det strängare beteendet i förväg med miljövariabeln STEAM_GAMESERVER_MIN_CONNECTIONLESS_PACKET_SIZE=1200. Dessutom svarar servern vid A2S_PLAYER och A2S_RULES inte omedelbart med data, utan med en challenge (S2C_CHALLENGE) som frågeställaren måste skicka tillbaka i en andra förfrågan. Den som förfalskar avsändaradressen får aldrig se den challengen.

För dig följer två saker av detta. Håll serverbinären aktuell, för skyddet sitter i Steams spelserverunderlag och inte i din konfiguration. Och förväxla inte reflektion med en förfrågningsflod riktad mot dig själv: mot den andra formen hjälper uteslutande hastighetsbegränsningen från steg 3 och, därutöver, filtrering i nätet framför servern.

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

Nu den del som ingen konfigurationsfil kan lösa. Allt som beskrivits 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.

Räkna med en gång. En typisk spelserver hänger på 1 Gbit/s, det är 125 megabyte per sekund, och ledningen är full så fort någon skickar mer. Den andra storheten slår oftast till tidigare: vid minsta möjliga paket på 64 byte ryms runt 1,49 miljoner paket per sekund i 1 Gbit/s, i 10 Gbit/s runt 14,88 miljoner. En vanlig serverkärna bearbetar beroende på processor och nätverkskort några hundratusen av dem innan den börjar kassera. En attack som inte ens fyller en tredjedel av din ledning kan alltså lamslå din server, eftersom beräkningstiden går åt till att kassera. Operatörer upplever det som "belastningen var ju inte ens hög, ändå hade alla lagg-spikar".

Till inordningen av vilka storleksordningar som faktiskt förekommer: på KernelHost-servrar har bland annat en UDP-flod med över 112,2 Gbit/s och över 8,7 miljoner paket per sekund mot en spelserver filtrerats, liksom en multivektorattack med över 473,4 Gbit/s och över 41,5 miljoner paket per sekund mot en röstserver. 473,4 Gbit/s är runt 470 gånger en 1 Gbit/s-anslutning och fortfarande runt 47 gånger en 10 Gbit/s-anslutning. För det finns ingen lokal inställning. Volymetriska attacker måste ta slut i nätet framför servern.

Vad KernelHost ställer emot

Det permanenta skyddet som ingår i varje serverpaket

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

• Steg 1: 17 Tbps mitigeringskapacitet i det globala scrubbing-nätverket. Volymetriska attacker rensas nära sin källa, innan de över huvud taget 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. Skyddet 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 ingen null-routning används: din IP-adress stannar i nätet, bara de skadliga paketen kasseras. Den som tar bort IP-adressen ur nätet åstadkommer för dig samma resultat som angriparen. Platsen är Frankfurt am Main. Vilka spel och protokoll som täcks listas i DDoS-skydd för spelservrar i realtid.

Advanced DDoS Protection för communityer som beskjuts varaktigt

Vissa projekt angrips inte då och då, utan riktat och under veckor, med växlande mönster och alltid precis under bästa speltid. 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 eget nät. På din sida behövs ingen ombyggnad.
• Skyddsregler per port och protokoll som du förvaltar själv i kundportalen: du ställer in vad som är tillåtet på 27015/UDP och vad som gäller 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 på nästa underhållsfönster.
• Skyddsprofil anpassad till respektive spel, för Garry's Mod och de övriga Source-titlarna lika väl som fria TCP- och UDP-profiler för modifierade servrar och egna applikationer.

Även här gäller PrePaid-modellen: ingen bindningstid, ingen uppsägningstid, inget avtal och ingen uppläggningsavgift. Är attackvågen över förlänger du helt enkelt inte. Den som hittills driver sin Garry's Mod-server någon annanstans får det här skyddet genom en flytt till KernelHost, för filtreringen sker i det egna nätet och inte på främmande infrastruktur.

De två skyddsstegen i jämförelse

För de flesta Garry's Mod-communityer 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 har försvunnit ur serverlistan": oftast har 27015/UDP spärrats generellt eller hastighetsbegränsats för snävt. Eftersom speltrafik och förfrågan delar samma port träffar en grov regel båda. Arbeta i stället med jämförelsen mot de anslutningslösa paketen. Förblir servern osynlig trots nåbar port, kontrollera sv_setsteamaccount: utan giltig Game Server Login Token nedvärderas en Garry's Mod-server kraftigt i listan, och varje server behöver en egen token.

"Min iptables-regel är korrekt och verkar ändå inte": tre orsaker är vanliga. Regeln står bakom UFW-kedjorna och nås aldrig, den var borta efter den senaste omstarten (då hjälper apt-get install -y iptables-persistent och netfilter-persistent save eller en post i /etc/ufw/before.rules), eller så är attacken volymetrisk och regeln arbetar korrekt vid en ledning som redan är full. Kontrollera med iptables -L INPUT -n -v om träffräknarna stiger. Stannar de på noll nås regeln inte.

"Min DarkRP-server hackar för alla, men ledningen är ledig": det är nästan alltid Lua och ingen attack mot ledningen. Se efter i serverloggen vilken nätverkshändelse som kommer in påfallande ofta, och kontrollera om det tillhörande tillägget har en begränsning per spelare. Förblir sar -n DEV 1 10 och räknarna för kasserade paket oanmärkningsvärda var det ingen DDoS-attack.

"RCON fungerar plötsligt inte längre": ingen DDoS, utan oftast den egna spärren. En adminpanel med gammalt lösenord utlöser sv_rcon_minfailures, och sv_rcon_banpenalty spärrar adressen under det inställda antalet minuter. Korrigera lösenordet, häv spärren, begränsa sedan porten till den egna adressen.

"Jag bytte IP-adress och var offline igen två dagar senare": det är normalfallet. Din server publicerar den nya adressen själv så snart den är registrerad hos masterservern igen, och en spelserver utan publik adress har inga spelare. Ett adressbyte ger timmar till dagar, det är ingen lösning.

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

"I tcpdump ser jag inget anmärkningsvärt": om trafiken redan filtreras i nätet framför kommer det som väntat ingenting fram till servern. Det är normalfallet vid fungerande filtrering. Omvänt gäller: är ledningen mättad når under vissa omständigheter inte ens SSH-sessionen fram, den du ville mäta med. Använd då VNC-konsolen i kundportalen.

Kort sammanfattat

• En Garry's Mod-server behöver exakt en öppen port: 27015/UDP. Speltrafik och A2S-förfrågan löper där gemensamt, någon separat query-port finns inte.
• RCON ligger på 27015/TCP, överför lösenordet i klartext och hör uteslutande hemma öppnat för den egna adressen eller nått via en SSH-portvidarebefordran.
• Begränsa inte porten utan de anslutningslösa paketen med huvudet 0xffffffff. En generell spärr på 27015/UDP kastar ut dina egna spelare.
• Det vanligaste Garry's Mod-avbrottet är ingen DDoS-attack utan en nätverkshändelse utan begränsning: varje händelse som registrerats med util.AddNetworkString behöver ett tak per spelare och sekund.
• Vid 64 byte stora paket bär en 1 Gbit/s-ledning runt 1,49 miljoner paket per sekund. Däröver uppstår förlusten i routern framför, och varje lokal regel blir verkningslös.
• Hos KernelHost ingår det permanenta skyddet i två steg i varje serverpaket utan extra kostnad: 17 Tbps mitigeringskapacitet i det globala scrubbing-nätverket och Arbor-realtidsfiltrering med 3,2 Tbps i Frankfurt am Main, utan null-routning.
• Den som beskjuts varaktigt och riktat kompletterar med Advanced DDoS Protection från 50,00 EUR i månaden: dedikerad skydds-IP, egenförvaltade regler per port och protokoll, verksamma i realtid.

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. Ange då direkt fyra uppgifter: IP-adress, port, tidsrum i din tidszon och vad du ser (spelare åker ut, servern inte i listan, lagg-spikar). Vid en pågående attack når du oss dessutom via WhatsApp-nödchatten på +43 650 8209883.

Den som vid sidan av Garry's Mod driver fler Source-titlar hittar de gemensamma grunderna i Skydda CS2- och Source-servrar mot DDoS-attacker, och hur underlaget sätts upp rent står i Installera spelservrar med SteamCMD.