Skydda din DayZ-server mot DDoS-attacker

En DayZ-server som på kvällen kastar ut alla spelare mitt i spelet och sedan försvinner ur serverlistan i flera minuter har sällan ett hårdvaruproblem. Oftast pågår en attack, och just då när flest spelare är online eller när den planerade omstarten står för dörren. Den som vill skydda sin DayZ-server mot DDoS-attacker behöver därför båda delarna: en ren portöppning på servern och en filtrering i nätet framför den. Den här artikeln visar först vad du själv kan säkra utan extra kostnad, sedan var dessa åtgärder tar slut rent tekniskt, och till sist vad som då måste hända framför servern.

Alla uppgifter gäller en egen dedikerad DayZ-server med serverDZ.cfg, oavsett om den körs under Windows Server eller under Debian och Ubuntu via ett kompatibilitetslager. Något produktionsfärdigt inbyggt Linux-serverprogram för stable-grenen levererar Bohemia Interactive inte, och det experimentella Linux-bygget tar uteslutande emot experimentella klienter. Linux-kommandona är skrivna för root, som vanlig användare sätter du sudo framför.

Om attacken pågår just nu: Ändra ingenting i serverDZ.cfg nu och starta inte om servern. En DayZ-omstart laddar om mods och den centrala ekonomin och kostar dig flera minuter där servern garanterat är offline. Säkra först mätvärdena (se avsnittet "Logga"), efter attacken är de borta.

Varför DayZ-servrar så ofta är mål för DDoS-attacker

DayZ förenar flera egenskaper som gör en server till ett bekvämt mål. För det första offentliggör en community-server sin adress av sig själv: för att den ska dyka upp i spelets serverlista och i DZSA-launchern måste den svara på Steam-förfrågningar, och det svaret innehåller IP-adress och port i klartext. En angripare behöver alltså inte ta reda på något, han behöver bara läsa en lista.

För det andra är en DayZ-servers dagsrytm offentlig. Praktiskt taget alla projekt startar om automatiskt var tredje till fjärde timme, meddelar det via chattmeddelande och skriver planen i sin Discord. En attack som faller exakt i det tidsfönstret verkar dubbelt: servern är ändå just då inte nåbar, och spelarna som hänger kvar i väntläget går någon annanstans.

För det tredje är insatsen hög för spelarna. Ett avbrott på fel minut betyder i DayZ inte bara frustration, utan förlorad utrustning, avbrutna raider och en bas som står oskyddad i världen. Just därför är bannade spelare, fientliga grupper och konkurrerande projekt de vanligaste uppdragsgivarna. En attack via någon av de gängse bootertjänsterna kostar den som utlöser den varken kunnande eller nämnvärda pengar.

För det fjärde går all DayZ-trafik över UDP. UDP har ingen uppkopplingsfas som går att kräva, och avsändaradressen går att förfalska. En angripare behöver alltså varken gå in på din server eller tilltala den korrekt för att skapa belastning. Att till och med tillverkaren drabbas visade februari 2025: Bohemia Interactives onlinetjänster för DayZ och Arma Reforger låg under DDoS-beskjutning i över en vecka, bekräftat den 3 februari 2025 och den 6 februari 2025 fortfarande inte över, och community-servrar var drabbade med. Vad en DDoS-attack är i detalj förklarar artikeln Vad är en DDoS-attack?.

Portarna på en DayZ-server: faktatabell

En DayZ-server talar uteslutande UDP. Det finns ingen TCP-spelport. Det enda värde som verkligen ligger fast hos DayZ är 2302/UDP som spelport, allt annat går att konfigurera och skiljer sig åt mellan olika leverantörer. Se därför efter i din egen startrad och din egen serverDZ.cfg i stället för att lita på ett standardvärde.

Två värden skapar regelbundet förvirring, därför uppklarningen här. Steam-query-porten: exempelkonfigurationen som Bohemia levererar med sätter steamQueryPort = 2305;, medan en stor del av leverantörerna använder 27016/UDP. Båda värdena är giltiga, avgörande är enbart värdet i din egen fil. BattlEye-RCon-porten: här finns över huvud taget ingen bindande standard. Den utbredda tumregeln är spelport plus tre, alltså 2305, andra leverantörer sätter 2310. Sedan DayZ 1.13 tolkar BattlEye parametern RConPort i BEServer_x64.cfg tillförlitligt, dessförinnan var porten svår att förutsäga.

Därav följer en fälla som drabbar många serverägare: sätt aldrig steamQueryPort och RConPort på samma värde. Om din konfiguration anger 2305 för Steam-förfrågan hör RCon hemma på en annan port, till exempel 2310.

Varför Steam-query-porten är den känsligaste porten

Steam-query-porten besvarar de tre förfrågningarna A2S_INFO, A2S_PLAYERS och A2S_RULES. A2S_INFO levererar servernamn, karta, spelarantal och version, A2S_PLAYERS namnen på de anslutna spelarna, A2S_RULES de satta servervariablerna. Varje sådant svar är betydligt större än förfrågan som utlöste det, och just det gör porten dubbelt farlig.

För dig som mål betyder det: en angripare kan sysselsätta din query-port med några få byte per förfrågan, medan din server varje gång sätter ihop ett fullständigt svar och skickar det. För tredje part betyder det: en angripare kan fråga din server med förfalskad avsändaradress och styra svaren till sitt egentliga mål. Din server är då inte bara offer, utan förstärkare. Valve kompletterade därför A2S_INFO i december 2020 med en utmaningsförfrågan: servern svarar först med ett slumptal som den frågande måste skicka tillbaka. Det avväpnar förstärkningen, men avslutar den inte, eftersom långtifrån varje förfrågan går den vägen.

DayZ har här en egenhet som andra spel inte har: två skilda serverlistor frågar hos dig, spelets inbyggda community-serverlista och den vida spridda DZSA-launchern. Att helt enkelt stänga query-porten är därför inget alternativ, för då är ditt projekt försvunnet ur båda listorna trots att direktanslutningen fortsätter att fungera. Begränsa i stället för att stänga är det rätta svaret.

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

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

1. Inventering: vilka portar din DayZ-server verkligen öppnar

Innan du skriver en enda brandväggsregel ser du efter vad din server erbjuder utåt. Inte gissa, se efter. Under Linux:

ss -lnup
ss -lntup

Under Windows Server ger kommandotolken samma bild:

netstat -ano -p UDP | findstr "2302 2303 2304 2305 27016"

Intressant är kolumnen med den lokala adressen. 0.0.0.0:2302 betyder "nåbar från hela internet", 127.0.0.1:2310 betyder "bara lokalt" och behöver ingen öppning. Därefter läser du de faktiska värdena direkt ur dina konfigurationsfiler i stället för att lita på en guide:

grep -iE "steamQueryPort|maxPlayers|password|enableWhitelist|verifySignatures" serverDZ.cfg
grep -iE "RConPort|RestrictRCon" battleye/BEServer_x64.cfg

Angriparens vy får du genom en UDP-portskanning utifrån, utförd från en annan dator:

nmap -Pn -sU -p 2302-2310,27015-27020 DIN.SERVER.IP.ADRESS

2. Öppna bara det som startraden och serverDZ.cfg verkligen behöver

För DayZ räcker två öppningar utåt: spelportblocket och query-porten. Allt annat begränsas till din egen adress eller publiceras inte alls. Med UFW ser det ut så här, och exakt i den här ordningen så att du inte låser ute dig själv:

ufw allow 22/tcp comment 'SSH'
ufw allow 2302:2305/udp comment 'DayZ spelport'
ufw allow 27016/udp comment 'DayZ Steam Query'
ufw allow from 203.0.113.10 to any port 2310 proto udp comment 'BattlEye 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 och 27016 med värdet som verkligen står i din steamQueryPort-rad. Den fullständiga guiden inklusive räddningsväg hittar du under Sätt upp UFW-brandväggen utan att låsa ute dig själv. På en Windows-server gäller samma princip: en inkommande regel per portgrupp, Fjärrskrivbord begränsat till den egna adressen, allt övrigt blockerat.

3. Begränsa Steam-query-porten i stället för att stänga den

En övre gräns per källadress skiljer riktiga serverlistor från förfrågningsfloder. En serverlista frågar dig i sekundtakt, en angripare i millisekundtakt:

iptables -I INPUT -p udp --dport 27016 -m hashlimit --hashlimit-name dayz_query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p udp --dport 2302 -m hashlimit --hashlimit-name dayz_game --hashlimit-mode srcip --hashlimit-above 600/sec --hashlimit-burst 900 -j DROP

Den första regeln förkastar Steam-förfrågningar från och med varaktigt mer än tio per sekund från samma källa, den andra spelpaket från och med mer än 600 per sekund. Båda talen är startvärden, inga sanningar. En full server med 60 spelare skapar betydligt fler paket än en tom, och den som ställer in för snävt kastar ut sina egna spelare eller åker ur serverlistan. Mät först en vecka under normal drift.

Rena iptables-regler är borta efter en omstart. Under Debian och Ubuntu säkrar man dem så här:

apt-get install -y iptables-persistent
netfilter-persistent save

Under UFW hör sådana regler hemma i /etc/ufw/before.rules, eftersom de annars försvinner vid nästa ufw reload. Dessutom har Steams serverbibliotek en egen broms för anslutningslösa paket: miljövariabeln STEAM_GAMESERVER_RATE_LIMIT_200MS förkastar alla A2S-paket från en adress så snart det kommer in mer än det satta värdet inom ett fönster på 200 millisekunder.

Den tredje punkten kostar ingenting alls: om din Discord-bot eller din projektsida visar spelarantalet, fråga då inte servern från besökaren, utan mellanlagra resultatet med fasta intervall. Därmed skapar en välbesökt statussida en förfrågan per intervall i stället för en per besökare.

4. Ta bort BattlEye-RCon från det öppna nätet

BattlEye är anti-cheat-komponenten i DayZ och slås på i serverDZ.cfg med BattlEye = 1;. Fjärrförvaltningen ligger däremot i en egen fil, BEServer_x64.cfg i BattlEye-katalogen bredvid BEServer_x64.dll, som startraden anger med -BEpath=:

RConPassword EttLangtSlumpmassigtLosenord
RConPort 2310
RestrictRCon 0

Tre regler till det. För det första: RCon-porten är UDP, inte TCP. En brandväggsregel som av misstag säger proto tcp filtrerar ingenting och låter samtidigt förvaltningsverktygen gå i tomgång. För det andra: begränsa porten till dina administratörers adresser. Den som inte har en fast adress lämnar porten helt stängd utifrån och startar förvaltningsverktyget direkt på servern, nåbart via SSH eller Fjärrskrivbord. För det tredje: RestrictRCon 1 begränsar de kommandon som går att köra via RCon och är den rätta inställningen så snart fler än en person har åtkomst.

En öppen RCon-port är två saker på en gång: en inbjudan till att prova sig igenom lösenord och ytterligare en UDP-port som går att översvämma. Bådadera faller bort så snart öppningen bara gäller för en handfull adresser.

5. Inloggningskö, vitlista och slotutmattning

DayZ betar inte av alla anslutningar samtidigt, utan via en kö. Fem värden i serverDZ.cfg styr den:

maxPlayers = 60;
loginQueueConcurrentPlayers = 5;
loginQueueMaxPlayers = 100;
guaranteedSlots = 10;
maxPing = 200;

loginQueueConcurrentPlayers fastställer hur många spelare som släpps in samtidigt (förval 5), loginQueueMaxPlayers begränsar själva kön (vanliga värden mellan 100 och 500). Exakt här sätter slotutmattningen in: en angripare behöver ingen bandbredd, han behöver bara tillräckligt många konton eller anslutningsförsök för att belägga kön. Riktiga spelare kommer då inte längre fram, trots att servern tekniskt fungerar felfritt. guaranteedSlots reserverar platser för ditt team, så att du i exakt det läget fortfarande kommer in på servern själv.

Mot det hjälper den inbyggda vitlistan. Den aktiveras med enableWhitelist = 1; och läser därefter filen profiles/whitelist.txt, ett Steam64-ID per rad. Varje ID som inte står i listan avvisas vid anslutningen. Filen läses in när servern startar, ändringar kräver alltså en omstart. Ett password därutöver i serverDZ.cfg verkar på liknande sätt, men är svagare, eftersom ett lösenord förs vidare och ett Steam64-ID inte gör det.

En sak måste vara klar: en vitlista skyddar dina spelarplatser, 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 det som är poängen.

6. Mods, signaturkontroll och tidsfönstret efter omstarten

Mods är i DayZ inte bara en bekvämlighetsfråga, de är en del av angreppsytan. Fyra inställningar i serverDZ.cfg ska under alla omständigheter vara satta:

verifySignatures = 2;
forceSameBuild = 1;
allowFilePatching = 0;
BattlEye = 1;

verifySignatures = 2 kontrollerar varje PBO-fil mot den tillhörande .bisign-signaturen och behöver för det de passande .bikey-filerna i mappen keys. forceSameBuild = 1 kräver exakt samma spelversion som på servern. allowFilePatching = 0 avvisar klienter som startar med förändrade spelfiler. Ingen av dessa inställningar stoppar en volymetrisk attack, men alla tre stänger vägen som en manipulerad klient får din server ur balans på.

Den andra punkten är den viktigare och förbises nästan alltid: startfasen. En DayZ-server laddar vid start först sin modlista ur startraden och därefter den centrala ekonomin med alla loot-tabeller. På en kraftigt moddad server blir det lätt flera minuter där servern inte svarar på en enda Steam-förfrågan:

./DayZServer -config=serverDZ.cfg -port=2302 -profiles=./profiles -BEpath=./battleye -mod=@CF;@DinMod;@EnModTill -cpuCount=4 -dologs -adminlog -netlog -freezecheck

Eftersom praktiskt taget varje projekt startar om var tredje till fjärde timme och dessutom annonserar den planen är tidsfönstret trivialt att träffa för en angripare. Tre motåtgärder är verksamma och kostar ingenting. Håll modlistan så kort som möjligt, varje ytterligare mod förlänger exakt det fönstret. Lägg omstartstiderna på skeva tider i stället för på hel timme. Och mät en gång efter hur lång tid din start verkligen tar i stället för att uppskatta: med timeStampFormat = "Full"; och ett satt logFile står längden därefter i loggen.

7. Anslutningsspårning, mottagningsbuffertar och kernelparametrar

En ofta förbisedd flaskhals är kernelns anslutningsspårning. UDP har visserligen inga anslutningar, men kernel lägger ändå upp en post för varje par av käll- och måladress. Blir tabellen full förkastar servern även legitima paket, och i loggen står det "nf_conntrack: table full". Läge och övre gräns visar:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

För en ren spelserver är den rena lösningen att inte låta speltrafiken spåras alls, och dessutom förstora nätverkskortets mottagningsbuffert och kö:

iptables -t raw -A PREROUTING -p udp --dport 2302 -j NOTRACK
iptables -t raw -A OUTPUT -p udp --sport 2302 -j NOTRACK
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.rmem_default=1048576
sysctl -w net.core.netdev_max_backlog=5000
sysctl -w net.netfilter.nf_conntrack_max=524288

Observera: NOTRACK och tillståndsbaserade regler utesluter varandra. Den som undantar spelporten från spårningen får inte längre använda någon regel med -m conntrack --ctstate för den porten, annars slår öppningen inte igenom längre. Permanent hör sysctl-värdena hemma i /etc/sysctl.d/, annars är de borta efter nästa omstart.

8. Din IP-adress står i serverlistan

Här lönar sig ärlighet i stället för önsketänkande: IP-adressen till en offentlig DayZ-server går inte att hålla hemlig. Varje spelare som en gång har varit ansluten känner till den, serverlistan offentliggör den, och DZSA-launchern mellanlagrar den. Ett adressbyte ger dig timmar, sällan dagar.

Verksammare är två vanor. Publicera inte den råa IP-adressen någonstans därutöver, alltså varken i det fastnålade Discord-inlägget eller på projektsidan. Och städa dina DNS-poster: en bortglömd A-post mot den tidigare adressen gör varje byte verkningslöst, och det är precis där de flesta byten går i stöpet. Den som låter en statustjänst fortsätta köra på den gamla servern avslöjar den nya adressen på köpet.

9. Logga, så att du inte behöver gissa under attacken

Det viktigaste steget är det som nästan ingen tar i förväg: lägg upp en jämförelsebas medan allt är normalt. Utan ett normalvärde kan du efter en incident inte säga om 40 000 paket per sekund var mycket eller helt enkelt lördagskväll. På serversidan slår du på de inbyggda loggarna för det:

timeStampFormat = "Short";
logAverageFps = 300;
logPlayers = 300;
logFile = "server_console.log";

logAverageFps är därvid det ärligaste värdet som DayZ levererar. Faller serverns bildfrekvens medan spelarantalet förblir detsamma är det ett mod- eller ekonomiproblem. Förblir bildfrekvensen stabil medan spelare kastas ut ligger det på nätet. På systemsidan körs mätningarna permanent med apt-get install -y vnstat sysstat, och under en incident räcker fyra kommandon:

sar -n DEV 1 10
ip -s link show eth0
dmesg -T | tail -50
tcpdump -ni eth0 udp port 2302 -c 200 -q

För tcpdump gäller: begränsa alltid 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.

Var självskyddet tar slut: bandbredd och paketfrekvens

Nu till 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 beslutar om ett paket som redan har färdats över kabeln. Du kan förkasta det, men inte göra det osänt.

Paketfrekvensen slår hos DayZ ofta till tidigare än bandbredden, och det har ett enkelt skäl: speltrafiken består av många små UDP-paket, inte av några få stora. En attack som inte ens fyller en tredjedel av din ledning kan därför ändå slå ut din server, eftersom beräkningstiden går åt till att förkasta. Serverägare upplever det som "belastningen var ju inte ens hög, ändå hade alla laggspikar och åkte ut på löpande band".

Volymetriska attacker måste ta slut i nätet framför servern. Det är inget produktpåstående, utan fysik.

DDoS-skydd för DayZ: vad KernelHost sätter emot

Det permanenta skyddet som körs på varje server

KernelHosts DDoS-skydd ä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 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 förkastas, paket för paket.

Två egenskaper är avgörande. Skyddet körs permanent och måste inte först reagera på en attack, det finns alltså inga minuter i början där servern är borta. Och ingen nollrouting används: din IP-adress stannar i nätet, bara de skadliga paketen förkastas. Den som tar bort IP-adressen ur nätet uppnår samma resultat för dig som angriparen. Vilka spel och protokoll som täcks listar DDoS-skydd för spelservrar i realtid.

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

Vissa projekt angrips inte då och då, utan riktat och i veckor. För det finns Advanced DDoS Protection från 50,00 € per månad, PrePaid och utan bindningstid. Skillnaden ligger inte i mer kapacitet, utan i kontrollen:

• Dedikerad skydds-IP ur Frankfurtkärnan, som din server ställs om till inne i det egna nätet. På din sida behövs ingen ombyggnad.
• Skyddsregler per port och protokoll som du förvaltar själv i kundportalen: du ställer in separat vad som är tillåtet på 2302/UDP, vad som gäller på query-porten och vad som gäller på RCon-porten. Exakt den uppdelningen är hävstången hos DayZ, eftersom speltrafik och förfrågningstrafik ser helt olika ut.
• Ändringar slår igenom i realtid, du kan alltså justera under en pågående attack i stället för att vänta på ett supportärende.
• Skyddsprofil anpassad till spelet, även för kraftigt moddade servrar och egna applikationer på valfria TCP- eller UDP-portar.

De båda stegen i jämförelse

För de flesta DayZ-projekt räcker det inkluderade permanenta skyddet tillsammans med en ren serverkonfiguration. Advanced DDoS Protection är svaret på att någon tar det personligt. Den som just nu driver sin DayZ-server någon annanstans kan inte eftermontera skyddet: det är en del av nätet och gäller för servrar som står hos KernelHost. Vägen dit är en flytt, ingen tilläggsprodukt.

Vanliga fel och lösningar

"Min server har försvunnit ur DZSA-launchern och ur serverlistan, men via direktanslutning kommer jag in": Det är i de flesta fall ingen attack, utan query-porten. Antingen står ett annat värde i steamQueryPort än i brandväggen, eller så förkastar en för snäv hastighetsbegränsning serverlistornas förfrågningar. Kontrollera de båda värdena mot varandra innan du misstänker en attack.

"RCon ansluter inte längre sedan jag filtrerade portarna": BattlEye-RCon går över UDP. En öppning med proto tcp på samma port gör ingenting. Kontrollera dessutom om RConPort och steamQueryPort av misstag står på samma värde.

"Jag bytte IP-adress och var offline igen två timmar senare": Angriparen har den nya adressen ur samma källa som den gamla, oftast serverlistan, en Discord-statusbot eller en gammal DNS-post. Ett adressbyte är tidsvinst, ingen lösning.

"Attacken kommer varje dag exakt vid omstarten": Det är ingen slump. Omstartsplanen står i Discord och annonseras i spelet, och medan mods och ekonomi laddar svarar servern ändå inte. Kortare modlista, skeva omstartstider och en filtrering som körs permanent i stället för att först reagera på en attack tar verkan ur det mönstret.

"Alla spelare har laggspikar, men nätet är lugnt": Då var det ingen DDoS-attack. Se först efter i logAverageFps om serverns bildfrekvens har fallit, och därefter i den centrala ekonomin och i modlistan. Förblir sar -n DEV 1 10 oansenligt ligger det inte på nätet.

"Mina iptables-regler slår inte igenom": Tre orsaker är vanliga. Reglerna står bakom UFW-kedjorna och nås aldrig, de var borta efter den senaste omstarten (då hjälper 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. Står de kvar på noll nås regeln inte.

"Min tidigare leverantör har spärrat min IP-adress": Det är nollrouting. Leverantören skyddar därmed sitt eget nät, för dig är resultatet identiskt med en lyckad attack, oftast i timmar därefter. Fråga i tveksamma fall om det filtreras eller nollroutas. Svaret avgör mer om din tillgänglighet än varje hårdvaruuppgift.

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

Kort sammanfattat

• En DayZ-server behöver exakt två saker utåt: spelportblocket från 2302/UDP och Steam-query-porten ur din steamQueryPort-rad. Allt annat hör hemma begränsat eller stängt.
• BattlEye-RCon-porten har ingen bindande standard, går över UDP och sätts i BEServer_x64.cfg med RConPort. Den hör aldrig hemma i det öppna nätet och aldrig på samma värde som query-porten.
• Begränsa query-porten i stället för att stänga den: den som stänger den försvinner ur serverlistan och ur DZSA-launchern, trots att direktanslutningen fortsätter att fungera.
• Vitlista, guaranteedSlots och inloggningskön skyddar dina spelarplatser mot slotutmattning, men inte din ledning mot bandbredd.
• Det farligaste tidsfönstret på en DayZ-server är den planerade omstarten var tredje till fjärde timme, eftersom mods och den centrala ekonomin laddar i flera minuter och tidpunkten är offentligt känd.
• Från omkring 1 Gbit/s attackvolym eller några hundratusen paket per sekund avgör uteslutande nätet framför servern, inte längre din brandvägg.
• Hos KernelHost ingår det permanenta skyddet i två steg i varje serverpaket, utan extra kostnad och utan nollrouting. Advanced DDoS Protection från 50,00 € per månad tillkommer när du vill styra reglerna per port själv.

Kör ditt projekt redan hos KernelHost är filtreringen aktiv utan att du behöver göra något. Märker du ändå avvikelser öppnar du 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.