Protejarea serverului Garry's Mod împotriva atacurilor DDoS

Un server Garry's Mod care dispare seara la ora opt pentru trei minute și apoi revine are rareori o problemă de hardware. În marea majoritate a cazurilor rulează un atac, și rulează exact atunci când sunt conectați cei mai mulți jucători. Protecția DDoS pentru Garry's Mod înseamnă de aceea în primul rând: să știți ce pachete au voie să ajungă pe serverul dumneavoastră. Acest articol arată, în această ordine, ce puteți securiza singur în următoarele zece minute fără să cheltuiți un ban, unde se opresc fizic aceste măsuri și ce trebuie să se întâmple după aceea în rețeaua din fața serverului.

Toate informațiile se referă la un server srcds pe Debian 12, Debian 13, Ubuntu 22.04 LTS sau Ubuntu 24.04 LTS. Fișierul de configurare se află la garrysmod/cfg/server.cfg, comenzile sunt scrise pentru root, ca utilizator obișnuit puneți sudo în fața lor. Se are în vedere întotdeauna operarea pe un server root sau dedicat propriu, nu un slot la un furnizor de servere de joc.

Dacă atacul este chiar în curs: nu modificați acum nimic în server.cfg și nu reporniți srcds. Salvați mai întâi valorile măsurate (secțiunea 9), deoarece după atac nu mai există. O repornire vă costă contoarele și readuce serverul în același val.

De ce un server Garry's Mod are nevoie de protecție DDoS

Un server Garry's Mod își publică singur adresa IP și portul. Nu este o neglijență, ci o condiție: cine nu apare în browserul de servere nu primește jucători noi. Intrarea apare pentru că serverul se înregistrează la serverul master Steam și răspunde apoi la fiecare interogare A2S care vine din exterior. Întrebarea nu este deci niciodată dacă un atacator găsește adresa dumneavoastră, ci doar ce se întâmplă atunci când trage în ea.

La asta se adaugă felul comunităților. Garry's Mod nu se joacă în general pe runde, ci în lumi permanente: o comunitate DarkRP ține conturi de jucători, proprietăți, joburi și progres luni de zile într-o bază de date. O cădere vineri seara costă deci mai mult decât un meci pierdut, costă jucători fideli. Exact de aceea comunitățile concurente, jucătorii banați și booterele cumpărate (servicii care, pentru câțiva euro pe lună, declanșează atacuri împotriva oricărei adrese) sunt cele trei cauze cele mai frecvente. Atacatorul nu are nevoie nici de pricepere, nici de bani demni de menționat.

Din punct de vedere tehnic se adună trei particularități. Traficul de joc merge prin UDP, iar UDP nu cunoaște o stabilire a conexiunii care s-ar putea pretinde: adresele expeditorului se pot falsifica. Interogarea serverului se află pe același port cu jocul, o blocare grosieră le lovește deci întotdeauna pe amândouă. Și peste toate stă Lua: fiecare addon din Workshop aduce cod propriu în același proces, iar un singur eveniment de rețea neprotejat este suficient pentru ca un singur client să încetinească serverul fără nicio lățime de bandă. Ce este în principiu un atac DDoS explică articolul Ce este un atac DDoS?.

Porturile despre care este vorba de fapt la Garry's Mod

Un server Garry's Mod pornește implicit pe portul 27015, și anume pe UDP pentru joc împreună cu interogarea serverului și pe TCP pentru RCON. Numărul se schimbă la pornire cu -port, la mai multe instanțe se numără în sus (27016, 27017 și așa mai departe). O comandă de pornire tipică arată astfel:

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

Din asta rezultă întreaga suprafață de atac. Tabelul următor este baza pentru fiecare regulă de firewall de mai jos:

Din aceste opt intrări, exact una are ce căuta fără restricții în rețeaua deschisă: 27015/UDP. Tot restul se limitează la adresa dumneavoastră, se leagă la 127.0.0.1 sau nici nu se pornește. Cea mai costisitoare eroare de gândire în acest domeniu este presupunerea că la Garry's Mod ar exista un port de interogare separat, pe care l-ați putea închide pur și simplu. Acesta nu există.

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

Această secțiune este cea mai lungă, și asta în mod intenționat. Un server Garry's Mod configurat curat rezistă cu forțe proprii la atacuri mici și medii, indiferent la cine se află. Nimic din toate acestea nu costă bani, iar cea mai mare parte se rezolvă în un sfert de oră.

1. Inventar: ce ascultă de fapt

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

ss -lntup

Interesantă este coloana cu adresa locală. 0.0.0.0:27015 și [::]:27015 înseamnă „accesibil din tot internetul”, 127.0.0.1:3306 înseamnă „doar local” și nu are nevoie de nicio regulă de firewall. Pe un server DarkRP crescut în timp se găsesc acolo aproape întotdeauna mai multe servicii decât se aștepta: MySQL, un server web pentru FastDL, un panel, un bot de Discord, un al doilea server de test pe 27016 și un serviciu de voce uitat. Perspectiva atacatorului o oferă o scanare de porturi din exterior:

nmap -Pn -sU -sT -p- --min-rate 1000 ADRESA.IP.A.SERVERULUI

2. Lăsați deschise doar porturile de care srcds are într-adevăr nevoie

Pentru Garry's Mod este suficientă o singură deschidere spre exterior, la care se adaugă SSH și accesul RCON restricționat. Cu UFW arată astfel, și anume exact în această ordine, ca să nu vă blocați singur afară:

ufw allow 22/tcp comment 'SSH'
ufw allow 27015/udp comment 'Joc Garrys Mod și 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

Înlocuiți 203.0.113.10 cu adresa dumneavoastră. SourceTV pe 27020/UDP îl deschideți doar dacă transmiteți efectiv. Instrucțiunile complete, împreună cu calea de salvare, se află în Configurarea firewall-ului UFW fără să vă blocați singur afară. Dacă totuși se întâmplă: serverele root KVM și serverele dedicate de la KernelHost nu au IPMI și nici iDRAC, reveniți prin consola VNC din panoul clientului. Aceasta nu depinde de stiva de rețea a sistemului oaspete, o regulă de firewall din interior nu o poate bloca.

Baza de date nu are ce căuta în niciun caz în rețeaua deschisă. Verificați în /etc/mysql/mariadb.conf.d/50-server.cnf că acolo scrie:

bind-address = 127.0.0.1

3. Limitați interogarea A2S fără să ieșiți din lista de servere

Aici se află greșeala care costă cele mai multe servere Garry's Mod. Deoarece traficul de joc și interogarea serverului ocupă același port, o blocare generală sau o limitare de rată prea strânsă pe 27015/UDP își aruncă afară proprii jucători și duce atacul la bun sfârșit. Punctul corect de atac este distincția între pachetele de interogare și pachetele de joc.

Motorul aduce pentru asta trei variabile de consolă, care se scriu în server.cfg. Valorile lor implicite sunt conservatoare, dar sunt setate:

sv_max_queries_sec 3
sv_max_queries_sec_global 60
sv_max_queries_window 30

sv_max_queries_sec limitează interogările la care se răspunde pentru fiecare adresă a expeditorului (implicit 3 pe secundă), sv_max_queries_sec_global plafonează suma peste toate adresele (implicit 60 pe secundă), sv_max_queries_window stabilește fereastra de mediere (implicit 30 de secunde). Aceste valori protejează procesorul de a genera răspunsuri inutile. Nu împiedică pachetele să ajungă, iar cine strânge foarte mult valoarea globală dispare în timpul atacului din browserul de servere, deoarece și interogările paginilor cu liste rămân fără răspuns.

Cu un nivel mai jos, traficul de interogare se poate separa curat. Toate pachetele fără conexiune ale motorului Source încep cu patru octeți setați (0xffffffff), traficul jucătorilor deja conectați nu are acest antet. Exact pe asta se poate pune cu nftables o limitare de rată pe fiecare adresă sursă:

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

Fișierul îl încărcați cu nft -f. Prioritatea -10 face ca regula să se aplice înaintea lanțului de filtrare al UFW, iar @th,64,32 citește primii patru octeți de după antetul UDP. Cu iptables clasic, o comparație u32 face același lucru:

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

Un punct pe care aproape orice ghid din rețea îl trece cu vederea: nu doar interogarea serverului este fără conexiune, ci și stabilirea conexiunii. Un jucător care se alătură trimite mai multe pachete cu același antet înainte de a fi în joc. O limită prea strânsă blochează de aceea jucătorii noi, chiar dacă serverul rămâne accesibil. Începeți generos (8 până la 15 pachete pe secundă și adresă) și strângeți limita abia după ce ați măsurat o săptămână de funcționare normală.

4. Securizați RCON sau opriți-l complet

RCON este la serverele Source o țintă preferată, și anume din trei motive în același timp. În primul rând, se află pe același număr de port ca jocul, doar pe TCP, și este astfel găsit fără căutare. În al doilea rând, protocolul Source RCON transmite parola în clar, fără TLS și fără schimb de chei: cine citește traficul o are. În al treilea rând, câștigul este maxim, deoarece cine are RCON poate schimba harta, poate bloca toți jucătorii, poate modifica configurația și poate opri serverul. Un atacator care preia RCON nu mai are nevoie de nicio lățime de bandă.

Nu lăsați niciodată rcon_password gol și nu îl alegeți niciodată ghicibil, o valoare din openssl rand -base64 32 este suficientă. Împotriva încercărilor de autentificare, motorul aduce o frână:

rcon_password "O_PAROLA_LUNGA_ALEATORIE"
sv_rcon_minfailures 3
sv_rcon_maxfailures 5
sv_rcon_minfailuretime 30
sv_rcon_banpenalty 1440

Astfel, o adresă este blocată pentru o zi după trei încercări eșuate în 30 de secunde. Două avertismente în legătură cu asta. În primul rând, exact acest mecanism blochează și panoul dumneavoastră de administrare, dacă acolo este salvată o parolă veche: ceea ce operatorii raportează ca „RCON nu mai funcționează dintr-odată” este de obicei propria blocare. În al doilea rând, restricția de firewall din pasul 2 rămâne mai eficientă, deoarece nici nu lasă încercarea să ajungă până la aplicație. Cine are nevoie de RCON doar ocazional lasă portul complet închis și lucrează prin redirecționare de port SSH:

ssh -N -L 27015:127.0.0.1:27015 root@ADRESA.IP.A.SERVERULUI

5. Limitați mesajele de rețea Lua, cea mai frecventă cădere produsă în casă

O parte considerabilă a căderilor de Garry's Mod raportate ca DDoS nu sunt căderi de acest fel. Sunt supraîncărcări Lua, declanșate de un singur client conectat cu câțiva kilobiți pe secundă. Motivul se află în construcția bibliotecii net: imediat ce un addon înregistrează un eveniment de rețea cu util.AddNetworkString și ascultă la el cu net.Receive, orice client poate declanșa acest eveniment în buclă. Fără o limitare proprie, serverul execută fiecare mesaj în parte. Facepunch a documentat asta în mai multe rânduri în propriile rapoarte de erori și nu a prevăzut nicio soluție în motor, limitarea este în mod explicit sarcina autorului addonului.

Verificați de aceea fiecare addon propriu și fiecare addon cumpărat pentru trei lucruri: o limită superioară pe jucător și secundă, o verificare a lungimii mesajului și faptul că jucătorul este determinat pe partea serverului din al doilea parametru, nu din conținutul mesajului. Un model solid arată astfel:

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)

La asta se adaugă două linii în server.cfg. sv_allowcslua este implicit 1 în Garry's Mod și permite clienților să execute cod propriu cu lua_run_cl și lua_openscript_cl: pentru un server public, valoarea trebuie să fie 0. Iar sv_kickerrornum deconectează clienții care generează mai mult decât numărul indicat de erori pe partea clientului (implicit 0, deci dezactivat):

sv_allowcslua 0
sv_kickerrornum 25

6. Separați conținutul din Workshop și FastDL de serverul de joc

Addonurile din Workshop nu sunt la Garry's Mod un subiect marginal, ci cazul normal: o comunitate DarkRP își include colecția cu +host_workshop_collection, iar clienții descarcă acest conținut direct de la Steam. Asta nu vă încarcă conexiunea. Cheia din -authkey este o cheie Steam Web API și trebuie tratată ca o parolă: în scriptul de pornire, nu într-un depozit public și nu într-un canal de Discord.

Lățimea de bandă o costă a doua cale. Tot ce nu vine din Workshop (hărți proprii, sunete, materiale) merge prin canalul de descărcare. Fără sv_downloadurl, acest canal trece prin portul de joc însuși și concurează direct cu traficul de joc. Cu FastDL trece prin HTTP. Dacă acest server web se află pe aceeași gazdă și pe aceeași adresă IP, amândouă împart aceeași conexiune: un val de conectări sau un atac pe 80/TCP lovește astfel și jocul. Aceste valori sunt utile:

sv_downloadurl "https://fastdl.domeniul-dumneavoastra.ro/garrysmod/"
sv_allowdownload 1
sv_allowupload 0
net_maxfilesize 64

sv_allowupload 0 ia clienților posibilitatea de a trimite fișiere proprii către server și închide astfel o cale care nici nu este necesară, nici controlată. net_maxfilesize limitează, în megaocteți, dimensiunea fișierelor transmise prin canalul de joc. Puneți FastDL, dacă se poate, pe altă gazdă sau în spatele unui nume propriu, atunci sarcina nu se află pe aceeași adresă ca portul de joc.

7. Opriți floodul de conectări și epuizarea sloturilor

Epuizarea sloturilor este un atac care nu are nevoie de lățime de bandă: atacatorul ocupă cu conexiuni automatizate toate locurile libere, astfel încât jucătorii reali văd o casă plină. La Garry's Mod se adaugă agravant faptul că fiecare conectare costă serverul muncă, deoarece lista de resurse și modul de joc se negociază cu mult înainte ca jucătorul să fie în joc.

Împotriva acestui lucru acționează patru elemente. În primul rând, o limită superioară realistă: a seta +maxplayers mai sus decât suportă modul dumneavoastră de joc doar mărește suprafața de atac. În al doilea rând sv_timeout, care stabilește după câte secunde fără mesaj un client este deconectat (în configurațiile răspândite 120): cine vrea să scape mai repede de semiconexiunile blocate setează valoarea mai jos. În al treilea rând, limitarea de rată a pachetelor fără conexiune din pasul 3, deoarece stabilirea conexiunii trece exact pe acolo. În al patrulea rând, pentru grupuri închise, o parolă de server:

sv_password "grup_permanent_2026"
sv_timeout 90
sv_filterban 1
sv_region 3

O listă albă adevărată Garry's Mod nu aduce, ea vine prin extensii precum ULX sau printr-o verificare proprie în hookul CheckPassword. Și un lucru trebuie să fie clar: o listă albă protejează logica jocului dumneavoastră, nu conexiunea dumneavoastră. Un atacator care inundă serverul dumneavoastră nici nu vrea să se alăture. Pachetele lui sunt respinse, dar au ajuns totuși, și exact asta este ideea.

8. Descărcați kernelul: urmărirea conexiunilor și bufferul de recepție

Acest pas explică defecțiuni care arată ca un atac volumetric, dar nu sunt. Kernelul creează pentru traficul UDP intrări în urmărirea conexiunilor (conntrack), iar la adrese falsificate ale expeditorului fiecare adresă înseamnă o intrare nouă. Dacă tabelul este plin, kernelul elimină pachetele fără deosebire: atacul și jucătorii dumneavoastră zboară afară împreună, iar în jurnalul de sistem scrie „nf_conntrack: table full”. Starea și limita superioară le arată:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

Pasul cel mai eficient este să nu lăsați traficul de joc să fie urmărit deloc, deoarece motorul își administrează singur sesiunile:

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

Cu iptables, echivalentul este iptables -t raw -A PREROUTING -p udp --dport 27015 -j NOTRACK și aceeași linie pentru OUTPUT cu --sport. Portul are nevoie după aceea de o deschidere explicită, deoarece fără urmărire nu se mai aplică nicio regulă care verifică o stare existentă. Dacă, în plus, pachetele ajung mai repede decât srcds le preia, bufferul de recepție se revarsă, iar pentru jucători asta arată ca pierdere de pachete pe o conexiune liberă:

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

Liniile au ce căuta într-un fișier din /etc/sysctl.d/ și devin active cu sysctl --system. Dacă sunt necesare, o spune kernelul însuși: dacă UdpRcvbufErrors crește în nstat -az, atunci ele își fac treaba. Dacă contorul rămâne la zero, ajustarea nu schimbă nimic. Asta este rezervă, nu protecție.

9. Salvați valorile măsurate cât timp totul este normal

Pasul cel mai important este cel pe care aproape nimeni nu îl face în avans: crearea unei baze de comparație. 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. Calculați o singură dată valoarea normală pentru serverul dumneavoastră: 64 de jucători cu cl_cmdrate 66 generează în jur de 4.200 de pachete de intrare pe secundă, orice lucru clar peste asta are nevoie de explicație. Cu apt-get install -y vnstat sysstat, măsurarea rulează permanent. În timpul unui incident sunt suficiente patru comenzi:

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"

Prima arată pachete și octeți pe secundă, a doua contoarele de pachete eliminate ale interfeței, a treia contoarele de erori UDP ale kernelului. A patra linie arată exclusiv pachetele fără conexiune, deci exact clasa de care abuzează un val de interogări: dacă contorul se umple în câteva secunde în timp ce aproape nimeni nu este conectat, aveți răspunsul. Limitați tcpdump întotdeauna cu -c, o captură la încărcare maximă apasă suplimentar un server oricum supraîncărcat. Cum evaluați valorile scrie în Recunoașterea unui atac DDoS pe server.

Ce este breșa de reflexie A2S și mă mai privește

Reflexia A2S este un atac în care nu serverul dumneavoastră este ținta, ci unealta. Atacatorul trimite o interogare mică cu adresă falsificată a expeditorului către mii de servere de joc, iar răspunsurile lor, considerabil mai mari, se adună toate la victima propriu-zisă. Din punct de vedere istoric, o cerere A2S_INFO avea 25 de octeți (4 octeți 0xFFFFFFFF, 1 octet 0x54, plus 20 de octeți pentru șirul de caractere „Source Engine Query”), iar răspunsul în schimb câteva sute de octeți. US-CERT include protocolul Steam în lista atacurilor de amplificare cu un factor de 5,5, ceea ce înseamnă: dintr-un gigabit la atacator devin 5,5 gigabiți la victimă.

Valve a închis această breșă începând din noiembrie 2020, și anume pe două căi. Pachetele de interogare fără conexiune trebuie de atunci completate de expeditor până la 1.200 de octeți, prin care cererea este mai mare decât răspunsul și factorul de amplificare scade sub 1. În timpul tranziției, operatorii puteau impune în avans comportamentul mai strict cu variabila de mediu STEAM_GAMESERVER_MIN_CONNECTIONLESS_PACKET_SIZE=1200. În plus, serverul nu mai răspunde la A2S_PLAYER și A2S_RULES imediat cu date, ci cu o provocare (S2C_CHALLENGE), pe care cel care întreabă trebuie să o trimită înapoi într-o a doua cerere. Cine falsifică adresa expeditorului nu vede niciodată această provocare.

Pentru dumneavoastră rezultă din asta două lucruri. Țineți binarul serverului la zi, deoarece protecția se află în infrastructura Steam pentru servere de joc și nu în configurația dumneavoastră. Și nu confundați reflexia cu un val de interogări împotriva dumneavoastră: împotriva celei de a doua forme ajută exclusiv limitarea de rată din pasul 3 și, dincolo de asta, filtrarea în rețeaua din fața serverului.

Unde se opresc aceste măsuri: lățime de bandă și rata de pachete

Acum partea pe care niciun fișier de configurare nu o poate rezolva. Tot ce a fost descris până aici 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.

Calculați o dată împreună cu noi. Un server de joc tipic atârnă la 1 Gbit/s, adică 125 de megaocteți pe secundă, iar conexiunea este plină imediat ce cineva trimite mai mult. A doua mărime lovește de obicei mai devreme: la pachete cât se poate de mici, de 64 de octeți, în 1 Gbit/s încap în jur de 1,49 milioane de pachete pe secundă, în 10 Gbit/s în jur de 14,88 milioane. Un kernel de server normal procesează, în funcție de procesor și placă de rețea, câteva sute de mii dintre ele înainte să înceapă să elimine. Un atac care nu umple nici măcar o treime din conexiunea dumneavoastră poate deci să vă paralizeze serverul, deoarece timpul de calcul se duce pe eliminarea pachetelor. Operatorii trăiesc asta ca „încărcarea nici nu era mare, totuși toți aveau vârfuri de lag”.

Pentru a încadra ordinele de mărime care apar în realitate: pe servere KernelHost au fost filtrate, între altele, un flood UDP cu peste 112,2 Gbit/s și peste 8,7 milioane de pachete pe secundă împotriva unui server de joc, precum și un atac cu mai mulți vectori, cu peste 473,4 Gbit/s și peste 41,5 milioane de pachete pe secundă, împotriva unui server de voce. 473,4 Gbit/s sunt în jur de 470 de ori o conexiune de 1 Gbit/s și tot în jur de 47 de ori o conexiune de 10 Gbit/s. Pentru asta nu există nicio setare locală. Atacurile volumetrice trebuie să se termine în rețeaua din fața serverului.

Ce pune KernelHost împotrivă

Protecția permanentă, inclusă în fiecare pachet de server

Protecția DDoS de la KernelHost este construită pe două niveluri și este permanent activă, fără să trebuiască 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 ca ele să ajungă măcar la centrul de date.
• Nivelul 2: filtrare Arbor în timp real de 3,2 Tbps în Frankfurt pe Main. Direct în fața serverului sunt recunoscute și eliminate șabloanele specifice fiecărui protocol, pachet cu pachet.

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

Advanced DDoS Protection pentru comunități atacate permanent

Unele proiecte nu sunt atacate ocazional, ci țintit și pe parcursul mai multor săptămâni, cu șabloane care se schimbă și mereu exact la ora de vârf. Pentru asta există Advanced DDoS Protection de la 50,00 EUR 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 noastră proprie. De partea dumneavoastră nu este nevoie de nicio modificare.
• Reguli de protecție administrabile de dumneavoastră pentru fiecare port și protocol în panoul clientului: stabiliți ce este permis pe 27015/UDP și ce pe 27015/TCP, fără să scrieți un tichet pentru asta.
• Modificările se aplică în timp real, puteți deci ajusta în timpul unui atac în curs, în loc să așteptați următoarea fereastră de mentenanță.
• Profil de protecție potrivit fiecărui joc, pentru Garry's Mod și celelalte titluri Source, la fel ca profilurile libere TCP și UDP pentru servere modificate și aplicații proprii.

Și aici se aplică modelul PrePaid: fără durată minimă, fără termen de preaviz, fără contract și fără taxă de instalare. Dacă valul de atacuri a trecut, pur și simplu nu prelungiți. Cine își operează până acum serverul Garry's Mod în altă parte primește această protecție printr-o mutare la KernelHost, deoarece filtrarea se face în rețeaua proprie și nu pe infrastructură străină.

Cele două niveluri de protecție în comparație

Pentru majoritatea comunităților Garry's Mod, protecția permanentă inclusă împreună cu o configurație curată a serverului este suficientă. Advanced DDoS Protection este răspunsul la faptul că cineva o ia personal.

Erori frecvente și soluții

„Serverul rulează, dar a dispărut din browserul de servere”: de obicei 27015/UDP a fost blocat în bloc sau limitat prea strâns. Deoarece traficul de joc și interogarea împart același port, o regulă grosieră le lovește pe amândouă. Lucrați în schimb cu comparația pe pachetele fără conexiune. Dacă serverul rămâne invizibil deși portul este accesibil, verificați sv_setsteamaccount: fără un Game Server Login Token valid, un server Garry's Mod este puternic depunctat în listă, iar fiecare server are nevoie de un token propriu.

„Regula mea de iptables este corectă și totuși nu are efect”: trei cauze sunt frecvente. Regula stă în urma lanțurilor UFW și nu este atinsă niciodată, ea a dispărut după ultima repornire (atunci ajută apt-get install -y iptables-persistent și 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ă.

„Serverul meu DarkRP se blochează pentru toți, dar conexiunea este liberă”: asta este aproape întotdeauna Lua și nu un atac pe conexiune. Uitați-vă în jurnalul serverului ce eveniment de rețea sosește suspect de des și verificați addonul corespunzător pentru o limitare pe jucător. Dacă sar -n DEV 1 10 și contoarele de pachete eliminate rămân fără nimic deosebit, nu a fost un atac DDoS.

„RCON nu mai funcționează dintr-odată”: nu este DDoS, ci de obicei propria blocare. Un panou de administrare cu parolă veche declanșează sv_rcon_minfailures, iar sv_rcon_banpenalty blochează adresa pentru numărul de minute setat. Corectați parola, ridicați blocarea, apoi restricționați portul la adresa proprie.

„Am schimbat adresa IP și două zile mai târziu eram iar offline”: acesta este cazul normal. Serverul dumneavoastră publică singur noua adresă imediat ce este din nou înregistrat la serverul master, iar un server de joc fără adresă publică nu are jucători. O schimbare de adresă vă aduce ore sau zile, nu este o soluție.

„Furnizorul meu anterior mi-a blocat adresa IP”: asta 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ă aceea. Întrebați la nevoie dacă se filtrează sau se face nullrouting. Răspunsul decide mai mult asupra disponibilității dumneavoastră decât orice specificație de hardware.

„În tcpdump nu văd nimic deosebit”: dacă traficul este deja filtrat în rețeaua din fața serverului, pe server nu ajunge nimic, așa cum era de așteptat. Acesta este cazul normal la o filtrare care funcționează. Invers se aplică: dacă conexiunea este saturată, poate să nu vă mai ajungă nici măcar sesiunea SSH cu care voiați să măsurați. Folosiți atunci consola VNC din panoul clientului.

Pe scurt

• Un server Garry's Mod are nevoie de exact un port deschis: 27015/UDP. Traficul de joc și interogarea A2S trec pe acolo împreună, un port de interogare separat nu există.
• RCON se află pe 27015/TCP, transmite parola în clar și trebuie deschis exclusiv pentru adresa proprie sau atins printr-o redirecționare de port SSH.
• Nu limitați portul, ci pachetele fără conexiune cu antetul 0xffffffff. O blocare în bloc pe 27015/UDP își aruncă afară proprii jucători.
• Cea mai frecventă cădere de Garry's Mod nu este un atac DDoS, ci un eveniment de rețea fără limitare: fiecare eveniment înregistrat cu util.AddNetworkString are nevoie de o limită superioară pe jucător și secundă.
• La pachete de 64 de octeți, o conexiune de 1 Gbit/s duce în jur de 1,49 milioane de pachete pe secundă. Peste asta, pierderea apare la routerul din față, iar orice regulă locală devine fără efect.
• La KernelHost, protecția permanentă pe două niveluri este inclusă în fiecare pachet de server fără cost suplimentar: 17 Tbps capacitate de mitigare în rețeaua globală de scrubbing și filtrare Arbor în timp real de 3,2 Tbps în Frankfurt pe Main, fără nullrouting.
• Cine este atacat țintit și permanent completează cu Advanced DDoS Protection de la 50,00 EUR pe lună: IP de protecție dedicat, reguli administrabile de dumneavoastră pentru fiecare port și protocol, active în timp real.

Dacă serverul dumneavoastră rulează deja la KernelHost, filtrarea este activă fără să trebuiască să faceți ceva. Dacă observați totuși lucruri neobișnuite, deschideți un tichet de suport, pentru ca regulile de filtrare pentru adresa dumneavoastră IP să fie ajustate. Menționați imediat patru informații: adresa IP, portul, intervalul de timp în fusul dumneavoastră orar și ce vedeți (jucătorii zboară afară, serverul nu apare în browser, vârfuri de lag). În timpul unui atac în curs ne găsiți suplimentar prin chatul de urgență WhatsApp la +43 650 8209883.

Cine operează pe lângă Garry's Mod și alte titluri Source găsește bazele comune în Protejarea serverelor CS2 și Source împotriva atacurilor DDoS, iar cum se configurează curat infrastructura de bază scrie în Instalarea unui server de joc cu SteamCMD.