Protejarea serverului DayZ împotriva atacurilor DDoS

Un server DayZ care seara, în mijlocul jocului, dă afară toți jucătorii și dispare după aceea minute întregi din browserul de servere are rar o problemă de hardware. De cele mai multe ori este în desfășurare un atac, și anume exact atunci când cei mai mulți jucători sunt online sau când urmează repornirea programată. Cine vrea să își protejeze serverul DayZ împotriva atacurilor DDoS are nevoie de aceea de amândouă: o deschidere curată a porturilor pe server și o filtrare în rețeaua din fața lui. Acest articol arată mai întâi ce puteți asigura singur fără costuri suplimentare, după aceea unde se termină tehnic aceste măsuri și la final ce trebuie să se întâmple atunci în fața serverului.

Toate datele se referă la un server DayZ dedicat propriu, cu serverDZ.cfg, indiferent dacă rulează pe Windows Server sau pe Debian și Ubuntu printr-un strat de compatibilitate. Un program de server nativ pentru Linux, pregătit pentru producție, pentru ramura stable nu este livrat de Bohemia Interactive, iar build-ul experimental pentru Linux acceptă exclusiv clienți experimentali. Comenzile pentru Linux sunt scrise pentru root, ca utilizator normal puneți sudo în față.

Dacă atacul este în desfășurare chiar acum: nu modificați acum nimic în serverDZ.cfg și nu reporniți serverul. O repornire de DayZ încarcă din nou modurile și economia centrală și vă costă câteva minute în care serverul este garantat offline. Salvați mai întâi valorile măsurate (vedeți secțiunea „Jurnalizare”), după atac nu mai există.

De ce serverele DayZ sunt atât de des ținta atacurilor DDoS

DayZ reunește mai multe proprietăți care fac dintr-un server o țintă comodă. În primul rând, un server de comunitate își publică adresa din proprie inițiativă: pentru ca el să apară în browserul de servere al jocului și în DZSA Launcher, trebuie să răspundă la interogările Steam, iar acest răspuns conține adresa IP și portul în clar. Un atacator nu trebuie deci să afle nimic, trebuie doar să citească o listă.

În al doilea rând, programul zilnic al unui server DayZ este public. Practic toate proiectele repornesc automat la fiecare trei sau patru ore, anunță asta printr-un mesaj în chat și scriu planul pe Discord. Un atac care cade exact în această fereastră de timp acționează dublu: serverul oricum nu este accesibil chiar atunci, iar jucătorii care atârnă în zona de așteptare se duc în altă parte.

În al treilea rând, miza pentru jucători este mare. O cădere în minutul nepotrivit înseamnă în DayZ nu doar frustrare, ci echipament pierdut, raiduri întrerupte și o bază care rămâne neprotejată în lume. Exact de aceea jucătorii banați, grupurile rivale și proiectele concurente sunt cei mai frecvenți comanditari. Un atac printr-unul dintre serviciile booter obișnuite nu îl costă pe cel care îl declanșează nici pricepere, nici bani demni de menționat.

În al patrulea rând, tot traficul DayZ circulă prin UDP. UDP nu cunoaște o inițiere de conexiune care ar putea fi pretinsă, iar adresa expeditorului poate fi falsificată. Un atacator nu trebuie deci nici să intre pe serverul dumneavoastră, nici să îl adreseze corect pentru a produce încărcare. Că nici producătorul nu este scutit de asta a arătat februarie 2025: serviciile online ale Bohemia Interactive pentru DayZ și Arma Reforger au stat sub atac DDoS mai bine de o săptămână, confirmat pe 3 februarie 2025 și încă neîncheiat pe 6 februarie 2025, iar serverele de comunitate au fost afectate împreună cu ele. Ce este în detaliu un atac DDoS explică articolul Ce este un atac DDoS?.

Porturile unui server DayZ: tabelul cu datele concrete

Un server DayZ vorbește exclusiv UDP. Nu există un port de joc TCP. Singura valoare care este realmente fixă la DayZ este 2302/UDP ca port de joc, tot restul este configurabil și diferă de la un hoster la altul. Uitați-vă de aceea în propria linie de pornire și în propriul serverDZ.cfg, în loc să vă bazați pe o valoare implicită.

Două valori provoacă în mod regulat confuzie, de aceea aici lămurirea. Portul de interogare Steam: configurația de exemplu livrată de Bohemia setează steamQueryPort = 2305;, în timp ce o mare parte a hosterilor folosește 27016/UDP. Ambele valori sunt valabile, decisivă este numai valoarea din fișierul dumneavoastră. Portul BattlEye RCon: aici nu există absolut niciun standard obligatoriu. Regula empirică răspândită este portul de joc plus trei, deci 2305, alți hosteri setează 2310. De la DayZ 1.13, BattlEye evaluează parametrul RConPort din BEServer_x64.cfg în mod fiabil, înainte portul era greu de prevăzut.

Din asta rezultă o capcană care îi lovește pe mulți operatori: nu setați niciodată steamQueryPort și RConPort pe aceeași valoare. Dacă configurația dumneavoastră prevede 2305 pentru interogarea Steam, RCon aparține pe un alt port, de exemplu 2310.

De ce portul de interogare Steam este portul cel mai sensibil

Portul de interogare Steam răspunde la cele trei interogări A2S_INFO, A2S_PLAYERS și A2S_RULES. A2S_INFO livrează numele serverului, harta, numărul de jucători și versiunea, A2S_PLAYERS numele jucătorilor conectați, A2S_RULES variabilele de server setate. Fiecare dintre aceste răspunsuri este vizibil mai mare decât cererea care l-a declanșat, și exact asta face portul periculos în două feluri.

Pentru dumneavoastră, ca țintă, înseamnă: un atacator poate ocupa portul dumneavoastră de interogare cu câțiva byte pe cerere, în timp ce serverul dumneavoastră compune și trimite de fiecare dată un răspuns complet. Pentru terți înseamnă: un atacator poate interoga serverul dumneavoastră cu adresa expeditorului falsificată și poate dirija răspunsurile către ținta lui reală. Serverul dumneavoastră nu este atunci doar victimă, ci și amplificator. Valve a completat de aceea A2S_INFO în decembrie 2020 cu o interogare de tip challenge: serverul răspunde mai întâi cu un număr aleatoriu, pe care cel care întreabă trebuie să îl trimită înapoi. Asta atenuează amplificarea, dar nu o încheie, pentru că nu orice interogare merge pe acest drum.

DayZ are aici o particularitate pe care alte jocuri nu o au: la dumneavoastră întreabă două liste de servere separate, browserul de servere de comunitate integrat și DZSA Launcher, foarte răspândit. Închiderea pur și simplu a portului de interogare nu este de aceea o opțiune, pentru că atunci proiectul dumneavoastră a dispărut din ambele liste, deși conexiunea directă funcționează în continuare. Limitarea în loc de închidere este răspunsul corect.

Ce puteți face singur înainte să dați bani

Această secțiune este cea mai lungă, și asta în mod intenționat. Un server DayZ configurat curat rezistă din propriile forțe la atacuri mici și medii, independent de locul în care se află.

1. Inventar: ce porturi deschide în realitate serverul dumneavoastră DayZ

Înainte să scrieți o singură regulă de firewall, uitați-vă ce oferă serverul dumneavoastră spre exterior. Nu ghiciți, verificați. În Linux:

ss -lnup
ss -lntup

În Windows Server, linia de comandă livrează aceeași imagine:

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

Interesantă este coloana cu adresa locală. 0.0.0.0:2302 înseamnă „accesibil din tot internetul”, 127.0.0.1:2310 înseamnă „numai local” și nu are nevoie de nicio deschidere. După aceea citiți valorile reale direct din fișierele dumneavoastră de configurare, în loc să vă bazați pe un ghid:

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

Perspectiva atacatorului o oferă o scanare de porturi UDP din exterior, executată de pe un alt calculator:

nmap -Pn -sU -p 2302-2310,27015-27020 ADRESA.IP.A.SERVERULUI

2. Deschideți numai ce au nevoie în realitate linia de pornire și serverDZ.cfg

Pentru DayZ sunt suficiente două deschideri spre exterior: blocul portului de joc și portul de interogare. Tot restul este restrâns la adresa dumneavoastră sau nu este publicat deloc. Cu UFW asta arată astfel, și anume exact în această ordine, ca să nu vă blocați singur accesul:

ufw allow 22/tcp comment 'SSH'
ufw allow 2302:2305/udp comment 'DayZ port de joc'
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

Înlocuiți 203.0.113.10 cu adresa dumneavoastră și 27016 cu valoarea care se află realmente în linia dumneavoastră steamQueryPort. Ghidul complet, inclusiv calea de salvare, îl găsiți la Configurarea firewallului UFW fără să vă blocați singur accesul. Pe un server Windows se aplică același principiu: o regulă de intrare pentru fiecare grup de porturi, desktopul la distanță limitat la adresa proprie, tot restul blocat.

3. Limitați portul de interogare Steam în loc să îl închideți

O limită superioară per adresă sursă separă listele de servere reale de floodurile de interogări. Un browser de servere vă întreabă din secundă în secundă, un atacator din milisecundă în milisecundă:

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

Prima regulă elimină interogările Steam de la mai mult de zece pe secundă în mod durabil din aceeași sursă, a doua pachetele de joc de la mai mult de 600 pe secundă. Ambele cifre sunt valori de start, nu adevăruri. Un server plin cu 60 de jucători produce vizibil mai multe pachete decât unul gol, iar cine setează prea strâns își dă afară propriii jucători sau zboară din lista de servere. Măsurați mai întâi o săptămână în funcționare normală.

Regulile pure de iptables dispar după o repornire. În Debian și Ubuntu ele se salvează astfel:

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

Sub UFW, locul unor astfel de reguli este în /etc/ufw/before.rules, deoarece altfel ele dispar la următorul ufw reload. În plus, biblioteca de server Steam cunoaște o frână proprie pentru pachetele fără conexiune: variabila de mediu STEAM_GAMESERVER_RATE_LIMIT_200MS elimină toate pachetele A2S ale unei adrese imediat ce într-o fereastră de 200 de milisecunde sosesc mai multe decât valoarea setată.

Al treilea punct nu costă absolut nimic: dacă botul dumneavoastră de Discord sau pagina proiectului afișează numărul de jucători, nu interogați serverul de la fiecare vizitator, ci stocați rezultatul temporar, la intervale fixe. Astfel, o pagină de stare mult vizitată produce o interogare pe interval în loc de una pe vizitator.

4. Scoateți BattlEye RCon din internetul deschis

BattlEye este componenta anti-cheat a DayZ și se activează în serverDZ.cfg cu BattlEye = 1;. Administrarea la distanță se află însă într-un fișier propriu, BEServer_x64.cfg din directorul BattlEye, lângă BEServer_x64.dll, director pe care linia de pornire îl setează cu -BEpath=:

RConPassword O-PAROLA-LUNGA-ALEATORIE
RConPort 2310
RestrictRCon 0

Trei reguli legate de asta. În primul rând: portul RCon este UDP, nu TCP. O regulă de firewall care spune din greșeală proto tcp nu filtrează nimic și lasă în același timp instrumentele de administrare să lucreze în gol. În al doilea rând: limitați portul la adresele administratorilor dumneavoastră. Cine nu are o adresă fixă lasă portul complet închis din exterior și pornește instrumentul de administrare direct pe server, accesibil prin SSH sau desktop la distanță. În al treilea rând: RestrictRCon 1 limitează comenzile care pot fi executate prin RCon și este setarea corectă imediat ce mai mult de o persoană are acces.

Un port RCon deschis este două lucruri în același timp: o invitație la încercarea de parole și încă un port UDP care poate fi inundat. Amândouă dispar imediat ce deschiderea este valabilă doar pentru o mână de adrese.

5. Coada de conectare, lista albă și epuizarea sloturilor

DayZ nu procesează conexiunile toate în același timp, ci printr-o coadă de așteptare. Cinci valori din serverDZ.cfg o controlează:

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

loginQueueConcurrentPlayers stabilește câți jucători sunt invitați în același timp (valoare implicită 5), loginQueueMaxPlayers limitează coada însăși (valori uzuale între 100 și 500). Exact aici intervine epuizarea sloturilor: un atacator nu are nevoie de lățime de bandă, are nevoie doar de suficiente conturi sau încercări de conectare pentru a ocupa coada. Jucătorii reali nu mai trec atunci, deși serverul funcționează tehnic ireproșabil. guaranteedSlots rezervă locuri pentru echipa dumneavoastră, ca să puteți intra chiar dumneavoastră pe server exact în această situație.

Împotriva acestui lucru ajută lista albă integrată. Ea se activează cu enableWhitelist = 1; și citește după aceea fișierul profiles/whitelist.txt, cu un Steam64-ID pe linie. Orice ID nelistat este respins la conectare. Fișierul este citit la pornirea serverului, deci modificările au nevoie de o repornire. O password suplimentară în serverDZ.cfg acționează asemănător, dar este mai slabă, pentru că o parolă se dă mai departe, iar un Steam64-ID nu.

Un lucru trebuie să fie clar: o listă albă protejează locurile jucătorilor dumneavoastră, nu conexiunea dumneavoastră. Un atacator care vă inundă serverul nu vrea deloc să intre. Pachetele lui sunt respinse, dar au ajuns totuși, și exact acesta este punctul esențial.

6. Modurile, verificarea semnăturilor și fereastra de timp de după repornire

La DayZ, modurile nu sunt doar o chestiune de confort, ele sunt o parte a suprafeței de atac. Patru setări din serverDZ.cfg trebuie în orice caz stabilite:

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

verifySignatures = 2 verifică fiecare fișier PBO față de semnătura .bisign corespunzătoare și are nevoie pentru asta de fișierele .bikey potrivite în folderul keys. forceSameBuild = 1 pretinde exact aceeași versiune de joc ca pe server. allowFilePatching = 0 respinge clienții care pornesc cu fișiere de joc modificate. Niciuna dintre aceste setări nu oprește un atac volumetric, dar toate trei închid calea pe care un client manipulat vă scoate serverul din ritm.

Al doilea punct este cel mai important și este aproape întotdeauna trecut cu vederea: faza de pornire. Un server DayZ încarcă la pornire mai întâi lista lui de moduri din linia de pornire și după aceea economia centrală cu toate tabelele de loot. La un server puternic modificat asta înseamnă cu ușurință mai multe minute în care serverul nu răspunde la nicio interogare Steam:

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

Deoarece practic fiecare proiect repornește la fiecare trei sau patru ore și își anunță pe deasupra acest plan, fereastra de timp este trivial de nimerit pentru un atacator. Trei contramăsuri sunt eficiente și nu costă nimic. Țineți lista de moduri cât se poate de scurtă, fiecare mod suplimentar prelungește exact această fereastră. Puneți orele de repornire pe valori neregulate în loc de ora fixă. Și măsurați o dată cât durează în realitate pornirea dumneavoastră, în loc să estimați: cu timeStampFormat = "Full"; și un logFile setat, durata apare după aceea în jurnal.

7. Urmărirea conexiunilor, bufferele de recepție și parametrii de kernel

Un blocaj adesea trecut cu vederea este urmărirea conexiunilor din kernel. UDP nu cunoaște, ce e drept, conexiuni, dar kernelul creează totuși o intrare pentru fiecare pereche de adresă sursă și adresă destinație. Dacă tabela se umple, serverul elimină și pachete legitime, iar în jurnal apare „nf_conntrack: table full”. Starea și limita superioară le arată:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

Pentru un server de joc pur, soluția curată este să nu lăsați deloc traficul de joc să fie urmărit și, în plus, să măriți bufferele de recepție și coada plăcii de rețea:

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

Atenție: NOTRACK și regulile cu stare se exclud reciproc. Cine scoate portul de joc din urmărire nu mai are voie să folosească pentru acest port nicio regulă cu -m conntrack --ctstate, altfel deschiderea nu mai funcționează. Pentru a rămâne permanente, valorile sysctl aparțin în /etc/sysctl.d/, altfel dispar după următoarea repornire.

8. Adresa dumneavoastră IP se află în browserul de servere

Aici merită sinceritatea în locul iluziilor: adresa IP a unui server DayZ public nu poate fi ținută secretă. O cunoaște fiecare jucător care s-a conectat o dată, browserul de servere o publică, iar DZSA Launcher o stochează temporar. O schimbare de adresă vă câștigă ore, rar zile.

Mai eficiente sunt două obiceiuri. Nu publicați nicăieri suplimentar adresa IP brută, deci nici în postarea fixată de pe Discord, nici pe pagina proiectului. Și faceți ordine în înregistrările dumneavoastră DNS: o înregistrare A uitată, care indică adresa anterioară, face orice schimbare inutilă, și exact din cauza asta eșuează majoritatea schimbărilor. Cine lasă pe vechiul server un serviciu de stare care rulează în continuare dezvăluie noua adresă împreună cu el.

9. Jurnalizare, ca să nu fiți nevoit să ghiciți în timpul atacului

Cel mai important pas este acela pe care aproape nimeni nu îl face dinainte: să creați o bază de comparație cât timp totul funcționează normal. Fără o valoare normală nu puteți spune după un incident dacă 40.000 de pachete pe secundă au fost mult sau pur și simplu sâmbătă seara. Pe partea serverului activați pentru asta jurnalele integrate:

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

logAverageFps este la asta valoarea cea mai cinstită pe care o livrează DayZ. Dacă rata de cadre a serverului scade în timp ce numărul de jucători rămâne același, este o problemă de mod sau de economie. Dacă rata de cadre rămâne stabilă în timp ce jucătorii zboară afară, este din cauza rețelei. Pe partea sistemului, măsurătorile rulează permanent cu apt-get install -y vnstat sysstat, iar în timpul unui incident sunt suficiente patru comenzi:

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

La tcpdump se aplică regula: limitați întotdeauna cu -c, o captură la încărcare maximă apasă suplimentar un server care oricum este suprasolicitat. Cum evaluați valorile este descris în Recunoașterea unui atac DDoS pe server.

Unde se termină protecția proprie: lățimea de bandă și rata de pachete

Acum partea pe care nu o poate rezolva niciun fișier de configurare. Toate măsurile de până acum rulează pe serverul dumneavoastră, deci la capătul conexiunii. O regulă de firewall decide asupra unui pachet care a trecut deja prin cablu. Îl puteți elimina, dar nu îl puteți face netrimis.

La DayZ, rata de pachete lovește adesea mai devreme decât lățimea de bandă, iar asta are un motiv simplu: traficul de joc este format din multe pachete UDP mici, nu din puține pachete mari. Un atac care nu vă umple conexiunea nici măcar la o treime vă poate deci totuși paraliza serverul, pentru că timpul de calcul se duce pe eliminarea pachetelor. Operatorii trăiesc asta ca „încărcarea nici nu era mare, și totuși toți aveau vârfuri de lag și zburau afară unul după altul”.

Atacurile volumetrice trebuie să se termine în rețeaua din fața serverului. Asta nu este o afirmație despre produs, ci fizică.

Protecție DDoS pentru DayZ: ce opune KernelHost

Protecția permanentă, care rulează pe fiecare server

Protecția DDoS de la KernelHost este construită pe două niveluri și este activă permanent, fără să fie nevoie să activați, să comandați sau să configurați ceva:

• Nivelul 1: 17 Tbps capacitate de mitigare în rețeaua globală de scrubbing. Atacurile volumetrice sunt curățate aproape de sursa lor, înainte să ajungă la centrul de date.
• Nivelul 2: filtrare Arbor în timp real de 3,2 Tbps în Frankfurt pe Main. Direct în fața serverului, modelele specifice protocoalelor sunt recunoscute și eliminate, pachet cu pachet.

Două proprietăți sunt decisive. Protecția rulează permanent și nu trebuie să reacționeze abia la un atac, deci nu există minute la început în care serverul lipsește. Și nu se folosește nullrouting: adresa dumneavoastră IP rămâne în rețea, sunt eliminate doar pachetele dăunătoare. Cine scoate adresa IP din rețea obține pentru dumneavoastră același rezultat ca atacatorul. Ce jocuri și protocoale sunt acoperite listează Protecție DDoS în timp real pentru servere de joc.

Advanced DDoS Protection pentru proiectele atacate permanent

Unele proiecte nu sunt atacate ocazional, ci țintit și pe parcursul mai multor săptămâni. Pentru asta există Advanced DDoS Protection de la 50,00 € pe lună, PrePaid și fără durată minimă. Diferența nu stă în mai multă capacitate, ci în control:

• IP de protecție dedicat din nucleul de la Frankfurt, pe care serverul dumneavoastră este comutat în rețeaua proprie. De partea dumneavoastră nu este nevoie de nicio modificare.
• Reguli de protecție administrabile de dumneavoastră pe fiecare port și protocol în panoul clientului: setați separat ce este permis pe 2302/UDP, ce pe portul de interogare și ce pe portul RCon. Exact această separare este la DayZ pârghia, deoarece traficul de joc și traficul de interogare arată complet diferit.
• Modificările se aplică în timp real, deci puteți ajusta în timpul unui atac în curs, în loc să așteptați un tichet.
• Profil de protecție potrivit jocului, și pentru servere puternic modificate și aplicații proprii pe orice porturi TCP ori UDP.

Cele două niveluri în comparație

Pentru majoritatea proiectelor DayZ, protecția permanentă inclusă împreună cu o configurație curată de server este suficientă. Advanced DDoS Protection este răspunsul la situația în care cineva o ia personal. Cine își operează în prezent serverul DayZ în altă parte nu poate adăuga protecția ulterior: ea este parte a rețelei și este valabilă pentru serverele care se află la KernelHost. Calea spre ea este o mutare, nu un produs suplimentar.

Greșeli frecvente și soluții

„Serverul meu a dispărut din DZSA Launcher și din browserul de servere, dar prin conexiune directă intru pe el”: în majoritatea cazurilor acesta nu este un atac, ci portul de interogare. Fie în steamQueryPort se află o altă valoare decât în firewall, fie o limitare de rată prea strânsă elimină interogările listei de servere. Verificați ambele valori una față de alta înainte să bănuiți un atac.

„RCon nu se mai conectează de când am filtrat porturile”: BattlEye RCon funcționează prin UDP. O deschidere cu proto tcp pe același port nu produce nimic. Verificați în plus dacă RConPort și steamQueryPort se află din greșeală pe aceeași valoare.

„Am schimbat adresa IP și două ore mai târziu eram iar offline”: atacatorul a luat noua adresă din aceeași sursă ca pe cea veche, de obicei din browserul de servere, dintr-un bot de stare de pe Discord sau dintr-o înregistrare DNS veche. O schimbare de adresă este un câștig de timp, nu o soluție.

„Atacul vine în fiecare zi exact la repornire”: asta nu este o coincidență. Planul de repornire se află pe Discord și este anunțat în joc, iar în timp ce modurile și economia se încarcă, serverul oricum nu răspunde. O listă de moduri mai scurtă, ore de repornire neregulate și o filtrare care rulează permanent în loc să reacționeze abia la un atac iau acestui model efectul.

„Toți jucătorii au vârfuri de lag, dar rețeaua este liniștită”: atunci nu a fost un atac DDoS. Uitați-vă mai întâi în logAverageFps dacă rata de cadre a serverului a scăzut, iar după aceea în economia centrală și în lista de moduri. Dacă sar -n DEV 1 10 nu arată nimic ieșit din comun, nu este din cauza rețelei.

„Regulile mele de iptables nu se aplică”: trei cauze sunt frecvente. Regulile stau în spatele lanțurilor UFW și nu sunt niciodată atinse, ele au dispărut după ultima repornire (atunci ajută netfilter-persistent save sau o intrare în /etc/ufw/before.rules), sau atacul este volumetric și regula lucrează corect la o conexiune care este deja plină. Verificați cu iptables -L INPUT -n -v dacă contoarele de potriviri cresc. Dacă rămân la zero, regula nu este atinsă.

„Furnizorul meu anterior mi-a blocat adresa IP”: acesta este nullrouting. Furnizorul își protejează astfel propria rețea, pentru dumneavoastră rezultatul este identic cu un atac reușit, de obicei încă pentru ore după el. La nevoie întrebați dacă se filtrează sau se face nullrouting. Răspunsul decide mai mult despre disponibilitatea dumneavoastră decât orice specificație de hardware.

„În tcpdump nu văd nimic ieșit din comun”: dacă traficul este filtrat deja în rețeaua din față, pe server nu ajunge, cum era de așteptat, nimic. Acesta este cazul normal al unei filtrări care funcționează. Invers este valabil: dacă conexiunea este saturată, în anumite situații nu vă mai ajunge nici măcar sesiunea SSH cu care voiați să măsurați. Folosiți atunci consola VNC din panoul clientului, care funcționează independent de rețeaua sistemului invitat.

Pe scurt

• Un server DayZ are nevoie spre exterior de exact două lucruri: blocul portului de joc de la 2302/UDP și portul de interogare Steam din linia dumneavoastră steamQueryPort. Tot restul trebuie restrâns sau închis.
• Portul BattlEye RCon nu are un standard obligatoriu, funcționează prin UDP și se setează în BEServer_x64.cfg cu RConPort. El nu are niciodată ce căuta în internetul deschis și niciodată pe aceeași valoare ca portul de interogare.
• Portul de interogare se limitează în loc să fie închis: cine îl închide dispare din browserul de servere și din DZSA Launcher, deși conexiunea directă funcționează în continuare.
• Lista albă, guaranteedSlots și coada de conectare protejează locurile jucătorilor dumneavoastră împotriva epuizării sloturilor, dar nu conexiunea dumneavoastră împotriva lățimii de bandă.
• Cea mai periculoasă fereastră de timp a unui server DayZ este repornirea programată la fiecare trei sau patru ore, deoarece modurile și economia centrală se încarcă minute întregi și momentul este cunoscut public.
• De la circa 1 Gbit/s volum de atac sau câteva sute de mii de pachete pe secundă decide exclusiv rețeaua din fața serverului, nu mai firewallul dumneavoastră.
• La KernelHost, protecția permanentă pe două niveluri este inclusă în fiecare pachet de server, fără cost suplimentar și fără nullrouting. Advanced DDoS Protection de la 50,00 € pe lună se adaugă atunci când vreți să controlați singur regulile pe fiecare port.

Dacă proiectul dumneavoastră rulează deja la KernelHost, filtrarea este activă fără să trebuiască să faceți nimic. Dacă observați totuși nereguli, deschideți un tichet de suport, pentru ca regulile de filtrare pentru adresa dumneavoastră IP să fie ajustate. În timpul unui atac în desfășurare ne găsiți suplimentar prin chatul de urgență WhatsApp la +43 650 8209883.