Skydda Left 4 Dead 2-server mot DDoS-attacker

En Left 4 Dead 2-server går sällan ner vid en bekväm tidpunkt. Den går ner i det sista avsnittet av en kampanj, i andra omgången av en Versus-match eller precis när en bannlyst spelare har avvisats för tredje gången. Den som just beskjuts behöver ingen principdiskussion om nätverksteknik, utan en ordningsföljd. Den här artikeln visar först hur du skyddar en Left 4 Dead 2-server mot DDoS-attacker så länge det går med inbyggda medel, därefter var de möjligheterna tar slut rent fysiskt, och till sist vad som måste hända i nätet framför.

Alla uppgifter gäller en dedikerad server (srcds), installerad via SteamCMD under app-ID 222860, 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. En punkt först, eftersom den bestämmer ordningsföljden: ändra ingenting blint under en pågående attack och starta inte om servern innan du har säkrat mätvärdena. Efter attacken är de borta.

Varför Left 4 Dead 2-servrar är ett lönande DDoS-mål

Skillnaden mot en shooter med 64 platser ligger i rundans storlek. En co-op-kampanj har fyra platser för överlevare, en Versus-match åtta platser för båda sidorna tillsammans. Ett avbrott drabbar därför aldrig enskilda spelare utan alltid hela partiet: den som avbryter en kampanj i det tredje av fem avsnitt har avslutat kvällen för alla inblandade. Just det gör en attack attraktiv för den som utlöser den, för den kostar honom varken kunskap eller några nämnvärda pengar, samtidigt som den förstör en timmes speltid på motsatta sidan.

Till det kommer byggsättet. Left 4 Dead 2 körs på Source-motorn, och en Source-server går att hitta publikt med IP-adress och port. Det är en förutsättning, inget misstag: en server som inte besvarar någon förfrågan står i ingen lista och hittas av ingen lobby. Frågan är alltså aldrig om en angripare känner till din adress, utan bara vad som händer när han skjuter på den. Speltrafiken går över UDP, och UDP känner inte till någon uppkoppling som man skulle kunna kräva, dessutom går avsändaradresser att förfalska. Vad som tekniskt pågår förklaras i artikeln Vad är en DDoS-attack?.

En tredje punkt är egen för Left 4 Dead 2 och har ingen motsvarighet hos Counter-Strike, Garry's Mod eller Team Fortress 2: de flesta spelare kommer inte via serverlistan utan via lobbysystemet. En lobby med upp till fyra spelare förmedlas via Steams matchmaking till en dedikerad server, som får en reservation för det. Det förfarandet är samtidigt ditt verksammaste åtkomstfilter och en extra angreppsyta. Båda delarna står längre ned i detalj.

Portarna som det faktiskt handlar om

En Left 4 Dead 2-server upptar exakt en UDP-port för allt som utgör spelet. Standard är 27015, fastställd via -port respektive +hostport i startraden:

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

Tabellens första rad är kärnan i problemet. Speltrafik och serverförfrågan delar på 27015/UDP, någon separat query-port finns inte hos Left 4 Dead 2. Den som spärrar den porten generellt eller hastighetsbegränsar den grovt kastar i samma veva ut sina egna spelare och avslutar attacken i angriparens mening.

En A2S-förfrågan är ett paket på några få dussin byte, svaret ett mångfaldigt av det. Vid UDP går avsändaradressen att förfalska, och därmed blir din server inte bara offer utan förstärkare: en angripare frågar främmande spelservrar med sitt måls adress och styr deras svar dit. Valve kompletterade A2S_INFO i december 2020 med en föregående uppmaning (S2C_CHALLENGE) som frågeställaren måste skicka tillbaka innan han får svaret. Det mildrar reflektionen men avslutar den inte, eftersom äldre frågeprogram fortsatt betjänas.

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

Den följande delen kostar ingenting och lönar sig oavsett var din server står. Den befriar dig inte från en volymetrisk attack, men låter små och medelstora attacker rinna ut i sanden, och den undanröjer de avbrott som felaktigt rapporteras som DDoS-attacker.

1. Inventering: vad lyssnar egentligen

Innan du skriver en regel klargör du vilka tjänster som är nåbara. På en Left 4 Dead 2-server som vuxit fram är det nästan alltid fler än väntat, eftersom det vid sidan av srcds också körs en webbserver för kampanjerna, en statistikdatabas och ibland en andra server för Versus:

ss -lntup

Allt som är bundet till 127.0.0.1 eller ::1 behöver ingen öppning. Allt som lyssnar på 0.0.0.0 eller [::] är nåbart från internet. Angriparens vy får du med en portskanning utifrån, och den avviker erfarenhetsmässigt från den egna förväntan:

nmap -Pn -sU -sT -p 27000-27050,80,443,3306 DIN.SERVER.IP.ADRESS

Är underlaget nyuppsatt eller vill du följa det steg för steg beskriver artikeln Installera spelservrar med SteamCMD vägen från SteamCMD till en körande srcds.

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

En UDP-port utåt, en TCP-port för den egna adressen, inte mer. RCON hör inte hemma på det öppna internet, för den som har RCON byter karta, bannlyser alla spelare och stoppar servern:

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

Ersätt 203.0.113.10 med din egen adress. Växlar den regelbundet går vägen via en SSH-portvidarebefordran i stället för via en permanent öppning. Ordningen när du aktiverar avgör om du låser ute dig själv; den står tillsammans med återvägen i artikeln 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 når servern via VNC-konsolen i kundportalen, och den hänger inte på gästsystemets nätverksstack.

3. Bromsa A2S-förfrågan utan att falla ur lobbysökningen

Här ligger det dyraste felet på det här området. Eftersom speltrafik och serverförfrågan upptar samma port måste bromsen skilja mellan de två paketklasserna, inte mellan portar.

Steams spelserverunderlag har sedan ändringarna i december 2020 en egen begränsning för det, som sätts som miljövariabel före starten. STEAM_GAMESERVER_RATE_LIMIT_200MS=N kasserar anslutningslösa paket (A2S_INFO, A2S_RULES, A2S_PLAYERS) från en avsändaradress så snart fler än N av dem kommer in inom ett fönster på 200 millisekunder. Valve nämner 25 till 75 som ett användbart intervall, som standard är begränsningen av:

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

I en systemd-unit hör samma värde hemma som Environment=STEAM_GAMESERVER_RATE_LIMIT_200MS=50 i avsnittet [Service], annars är det borta efter nästa omstart. Den bromsen griper bara om ditt serverbygge har med det aktuella Steamworks-underlaget, och den skyddar din servers beräkningstid, inte din ledning: paketen har redan kommit fram.

Ett lager längre ned går samma trafik att skilja av i kärnan. Alla anslutningslösa paket i Source-motorn, alltså serverförfrågningar och uppkoppling, 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 per avsändaradress med nftables:

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

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. Börja generöst och dra åt gränsen först när legitima förfrågningar bevisligen kommer fram: din egen post i serverlistan hänger på det.

4. Använda lobbysystemet som åtkomstfilter

Det här är hävstången som bara Left 4 Dead 2 och föregångaren har. Servern avgör själv om den över huvud taget tar emot anslutningar utanför matchmakingen. Fyra direktiv i server.cfg bestämmer det:

sv_allow_lobby_connect_only 1
sv_search_key "din-egen-nyckel"
sv_steamgroup "103582791400000000"
sv_steamgroup_exclusive 2

• sv_allow_lobby_connect_only 1 släpper uteslutande in anslutningar från en matchmaking-lobby. Ett connect 203.0.113.10:27015 i utvecklarkonsolen och en Steam-inbjudan avvisas. Värdet 0 tillåter båda.
• sv_search_key är en fritt valbar söknyckel. Bara en lobby där samma nyckel är satt hittar servern via matchmakingen. Utan nyckeln dyker den inte upp i den publika sökningen.
• sv_steamgroup binder servern till en Steam-grupp och låter den visas bland gruppens servrar.
• sv_steamgroup_exclusive känner till tre steg: 0 släpper in alla, 1 beter sig som 0 men kräver att anslutningen sker via en lobby, och 2 släpper bara igenom gruppmedlemmar och direkt åtkomst via IP-adressen.

För en fast community är kombinationen av söknyckel och sv_steamgroup_exclusive 2 det verksammaste kostnadsfria åtkomstfilter som spelet känner till. En publik server kan inte använda den, för en server som ingen hittar är precis lika tom som en som är offline.

Och nu den del som reklamtexter gärna utelämnar: de direktiven skyddar din spellogik, inte din ledning. En angripare som översvämmar 27015/UDP vill inte ansluta alls. Hans paket avvisas, men de har ändå kommit fram, har förbrukat bandbredd och kostat ett varv genom nätverksstacken. Mot en anslutningsflod från engångskonton verkar sv_allow_lobby_connect_only 1 utmärkt, mot en booter verkar det inte alls.

5. Lobbyreservationen och när sv_force_unreserved är det bättre valet

En lobbyreservation är en tidsbegränsad beläggning av din server genom en matchmaking-lobby. Så länge den består räknas servern som upptagen för andra lobbyer, och den löper ut av sig själv först efter en stund. För en server med fyra platser är det en knapp resurs: till skillnad från en shooter med 32 eller 64 platser krävs mycket lite för att blockera ett parti.

Den som inte driver sin server via matchmakingen tar bort den ytan helt:

sv_force_unreserved 1
sv_allow_lobby_connect_only 0

sv_force_unreserved 1 gör att servern inte längre svarar på reservationsförfrågningar från lobbysystemet och avvisar anslutningar med ett reservationsmärke. Samma inställning behöver du ändå om du kör mer än fyra co-op-platser med L4DToolZ, för annars får lobbyn en reservation så snart de första fyra platserna är upptagna, och de övriga platserna förblir onåbara. Baksidan är entydig: dina spelare kommer då bara in via serverlistan eller via connect.

Välj medvetet en av de två driftsätten. Blandningen av halvöppen matchmaking och halvöppen direktanslutning är den variant som förenar båda nackdelarna.

6. Säkra RCON

En öppen RCON-port med svagt lösenord är inget DDoS-problem utan ett övertagande. Lämna aldrig rcon_password tomt och gör det aldrig gissningsbart, ett värde från openssl rand -base64 32 räcker. Source-titlarna har dessutom med sig en broms mot inloggningsförsök:

rcon_password "ETT_SLUMPMÄSSIGT_VÄRDE_HÄR"
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; find sv_rcon i serverkonsolen visar vilka av de variablerna ditt bygge känner till. Brandväggsbegränsningen från steg 2 förblir ändå mer verksam, eftersom den inte ens släpper fram försöket till applikationen. Om du inte behöver RCON lämnar du lösenordet tomt: då lyssnar inte TCP-delen av 27015.

7. Lägg ut custom-kampanjer i stället för att leverera dem via spelporten

Custom-kampanjer är skälet till att Left 4 Dead 2 fortfarande spelas efter femton år, och samtidigt en lastkälla som Counter-Strike inte har i den formen. En kampanj är ett VPK-paket med kartor, modeller, texturer och ljud, alltså ett mångfaldigt av vad en enskild tävlingskarta väger.

Den bekväma vägen för spelarna är Steam-verkstaden: paketet kommer då från Steam, inte från din server, och kostar dig ingen bandbredd. Levererar du lösa filer själv hör leveransen hemma på en webbserver och inte på spelporten:

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

Filer för sv_downloadurl hör hemma som bzip2-arkiv på webbservern, av minkarta.bsp blir alltså minkarta.bsp.bz2. Utan sv_downloadurl skickar srcds filerna själv över spelanslutningen, och då gäller: varje anslutningsförsök från en ny spelare kostar dig hela nedladdningen, varje avbrott mitt i nedladdningen likaså. Det är ett utpräglat billigt sätt att fylla en ledning, och det ser ut som en attack i ingen statistik.

Tre punkter till det som gör ont i praktiken. sv_allowupload 0 hör satt, för uppladdningar från klienten till servern behöver du inte. Ligger webbservern för sv_downloadurl på samma värd som spelet delar nedladdning och speltrafik på samma ledning och samma IP-adress, och en attack mot 443/TCP träffar då även ditt pågående parti. Och sv_consistency 1 är inget skydd mot attacker utan mot avvikande klientfiler; stäng av det bara om en kampanj bevisligen inte startar annars.

8. SourceMod, Metamod och tilläggen

En betydande del av de avbrott som rapporteras som DDoS är inga sådana. Det är krascher och lasttoppar som en enda klient utlöser, för att ett hål står öppet i serverbinären eller i ett tillägg. Mot det hjälper ingen bandbredd, utan underhåll:

• Håll Metamod:Source och SourceMod i takt med motorversionen. Left 4 Dead 2 får fortfarande uppdateringar, och ett tillägg som inte passar är det vanligaste skälet till krascher direkt efter en uppdatering.
• Left4DHooks i stället för egna ingrepp. De L4D2-typiska händelserna finns samlade i det tillägget. Egna ingrepp i samma funktioner är den snabbaste vägen till en serverbinär som lägger av vid vissa paketföljder.
• Använd L4DToolZ bara medvetet. Tillägget höjer de fast inbyggda platsgränserna. Varje extra plats är en extra spelare som genererar beräkningstid, och i förening med lobbysystemet kräver det sv_force_unreserved 1.
• Färre tillägg. Varje plugin är kod i samma process. Tillägg med egna webbtjänster öppnar ytterligare portar och publicerar ofta precis den adress du vill skydda.

Spärrar hör lagrade varaktigt, annars är de borta efter omstarten. Source-titlarna känner för det till banid med writeid samt addip med writeip, och de skapade filerna läses in igen via exec banned_user.cfg och exec banned_ip.cfg.

9. Avlasta anslutningsspårning och mottagningsbuffert

Den här punkten förbises ofta och 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. Läge och tak visar en blick:

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 notrack
    }
    chain output {
        type filter hook output priority raw; policy accept;
        udp sport 27015 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 fram snabbare än srcds hämtar dem svämmar dessutom mottagningsbufferten över, och det ser för spelarna ut som paketförlust på en ledig ledning:

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

Filen lägger du under /etc/sysctl.d/ och aktiverar den med sysctl -p. Om värdena över huvud taget 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.

10. Mät, så att du inte behöver gissa under attacken

Under attacken är den viktigaste frågan: hur mycket kommer fram, på vilken port, och är det förfrågnings- eller speltrafik. Fyra kommandon räcker:

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

Det första kommandot kör du två gånger med tio sekunders mellanrum, då har du en frekvens i stället för ett absolutvärde. Den sista 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. Håll inspelningen kort, eftersom den själv kostar beräkningstid under last. Hur du tolkar värdena står i artikeln Känna igen en DDoS-attack på servern.

Det viktigaste steget är dock det som nästan ingen gör i förväg: att lägga upp en jämförelsegrund medan 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 med full Versus-server.

Var de här åtgärderna tar slut

Nu den ärliga delen. Allt som beskrivits hittills verkar först när paketen har kommit fram till ditt nätverkskort. 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 motsvarar 125 megabyte per sekund. Vid minsta möjliga paketstorlek bär den ledningen runt 1,49 miljoner paket per sekund, en 10 Gbit/s-ledning runt 14,88 miljoner. Det är det fysiska taket, oberoende av processor, kärna och brandvägg. En vanlig serverkärna bearbetar beroende på processor och nätverkskort några hundratusen paket per sekund 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å var allt borta".

Mot det står verkliga attacker. Två exempel från driften hos KernelHost, båda filtrerade i realtid: en UDP-flod mot en spelserver på 7777/UDP med över 112,2 Gbit/s och över 8,7 miljoner paket per sekund, samt en multivektorattack mot en röstserver på 9987/UDP med över 473,4 Gbit/s och över 41,5 miljoner paket per sekund. Räkna det mot din ledning: 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.

Därför är de två utbredda nödbromsarna otillfredsställande. Null-routning (blackholing) tar bort den angripna IP-adressen ur nätet och avslutar visserligen attacken, men även din server: för dina spelare är resultatet identiskt med en lyckad attack. En reaktiv omdirigering kostar i omkopplingstiden precis de minuter då kampanjen avgörs. Verksam är bara en filtrering som varaktigt körs i nätet framför servern.

Vad KernelHost ställer emot

Det permanenta skyddet som ingår på varje server

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, långt 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 på lager 3 till 7 igen och kasseras, paket för paket.

Två egenskaper är avgörande. För det första löper filtreringen varaktigt, det finns alltså ingen omkopplingstid där dina spelare åker ut. För det andra används ingen null-routning: den angripna IP-adressen stannar i nätet, bara de skadliga paketen kasseras. Skyddet ingår i varje serverpaket utan extra kostnad, utan separat skyddspaket och utan uppsättning, och det är aktivt från leveransen. Servrarna står i maincubes Premium-datacentret i Frankfurt am Main. Vilka spel och protokoll som täcks listas i artikeln DDoS-skydd för spelservrar i realtid.

Advanced DDoS Protection för projekt som beskjuts varaktigt

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

• En dedikerad skydds-IP. Din server ställs om till den adressen i vårt nät, någon ombyggnad på din sida behövs inte.
• Skyddsregler per port och protokoll som du förvaltar själv. Du fastställer i kundportalen vilken port som filtreras med vilken profil, alltså 27015/UDP annorlunda än webbservern som levererar dina kampanjer.
• Ändringar griper i realtid, utan ärende och utan väntetid. Du kan alltså justera under en pågående attack.
• En skyddsprofil anpassad till respektive spel. För Left 4 Dead 2 och de övriga Source-titlarna lika väl som för över 40 andra spel och protokoll, därtill fria TCP- och UDP-profiler för modifierade servrar.

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

De två stegen i jämförelse

För de flesta Left 4 Dead 2-projekt 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 har försvunnit ur lobbysökningen men körs vidare: oftast har 27015/UDP spärrats generellt eller hastighetsbegränsats för snävt, och eftersom speltrafik och förfrågan delar samma port träffar en grov regel båda. Arbeta i stället med en jämförelse mot de anslutningslösa paketen. Är porten nåbar och servern ändå osynlig, kontrollera sv_search_key, sv_steamgroup_exclusive, sv_lan 0 och sv_region 255, samt om starten av misstag skedde med -nomaster.

I serverkonsolen står det löpande "Invalid split packet length": det är ingen volymetrisk attack, utan ett felaktigt sammansatt nätverkspaket som skickas i snabb följd. Trafiken förblir samtidigt mycket liten, servern laggar ändå. Kontrollera först om bandbredden över huvud taget är anmärkningsvärd, och uppdatera serverbinär och tillägg. Bandbredd hjälper inte här.

Alla spelare har hög ping men ledningen är inte full: det tyder på paketfrekvens i stället för volym. Titta på de kasserade paketen i ip -s link show och UDP-räknarna i nstat -az. Står det nf_conntrack: table full i systemloggen, ta ut spelporten med notrack.

Brandväggsregeln är korrekt och verkar ändå inte: kontrollera med iptables -L INPUT -n -v om träffräknarna stiger. Stannar de på noll nås regeln inte, för att den står bakom UFW-kedjorna eller gick förlorad vid den senaste omstarten. Stiger de och ingenting ändras är ledningen framför servern mättad, och därifrån hjälper bara filtrering i nätet.

Servern tar inte emot fler spelare trots att platser är lediga: oftast hänger en lobbyreservation. Antingen driver du servern konsekvent via matchmakingen, eller så sätter du sv_force_unreserved 1 och låter dina spelare ansluta via serverlistan. Vid fler än fyra co-op-platser med L4DToolZ är den inställningen ändå obligatorisk.

Nya spelare laddar i evighet och ledningen är full under tiden: då levererar srcds kampanjfilerna själv över spelporten. Sätt sv_downloadurl till en webbserver och lägg filerna där som bzip2-arkiv, eller hänvisa dina spelare till Steam-verkstaden.

Attacken pausar efter ett IP-byte och kommer tillbaka efter en till två dagar: det är normalfallet, för din server publicerar den nya adressen själv så snart den är registrerad igen, och en bortglömd DNS-post eller en Discord-bot med statusvisning gör resten. Ett IP-byte ger timmar, ingen lösning.

På servern körs främmande administrationskommandon: ingen DDoS-attack, utan en komprometterad RCON-åtkomst. Byt lösenord omedelbart och begränsa TCP-delen av 27015 till den egna adressen.

Kort sammanfattat

• En Left 4 Dead 2-server behöver exakt en öppen port utåt: 27015/UDP. Speltrafik och A2S-förfrågan delar på den, någon separat query-port finns inte.
• 27015/TCP är RCON och hör uteslutande hemma på den egna adressen. Den som inte behöver RCON lämnar rcon_password tomt.
• Lobbysystemet är det verksammaste kostnadsfria åtkomstfilter som spelet känner till: sv_allow_lobby_connect_only 1, en egen sv_search_key och sv_steamgroup_exclusive 2 spärrar ute allt som inte kommer via matchmakingen. Det filtrerar anslutningar, inte paket.
• Custom-kampanjer hör hemma i Steam-verkstaden eller bakom sv_downloadurl, aldrig över spelporten. Annars betalar varje avbrutet anslutningsförsök med din bandbredd.
• Hastighetsbegränsning måste skilja mellan anslutningslösa paket (som börjar med 0xffffffff) och speltrafik. En grov regel på 27015/UDP kastar ut dina egna spelare.
• Vid 64 byte stora paket bär en 1 Gbit/s-ledning runt 1,49 miljoner paket per sekund. Däröver avgör uteslutande nätet framför servern, ingen inställning på servern själv.
• Hos KernelHost filtrerar 17 Tbps globalt scrubbing och en Arbor-realtidsfiltrering med 3,2 Tbps i Frankfurt am Main varaktigt och utan extra kostnad, utan null-routning och utan omkopplingstid.

Körs ditt projekt 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 vårt team justerar filterreglerna för din IP-adress. 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 (spelare åker ut, servern inte i lobbysökningen, hög ping). Det besparar en omgång följdfrågor, och den räknas när en kampanj just pågår.

Är du värd någon annanstans och beskjuts regelbundet är flytten till KernelHost den kortare vägen än ännu en regel på en server vars ledning tar slut dessförinnan. Det permanenta skyddet är en del av varje serverpaket, inte ett tillägg som du bokar först i skarpt läge.