Protejarea serverului MTA:SA împotriva atacurilor DDoS

Un server pentru Multi Theft Auto: San Andreas se comportă sub un atac DDoS altfel decât orice alt proiect GTA multiplayer, pentru că oferă simultan trei servicii de rețea separate: traficul de joc pe 22003 UDP, un server HTTP complet pe 22005 TCP și interogarea ASE pe 22126 UDP. Fiecare dintre aceste trei servicii poate fi atacat separat, și fiecare cade altfel. Acest articol arată mai întâi ce puteți securiza singur, fără costuri suplimentare, apoi unde se termină aceste măsuri la fizica conexiunii și, la final, ce trebuie să realizeze o protecție DDoS eficientă pentru MTA:SA în rețeaua din fața serverului.

Dacă atacul este în curs, cea mai importantă întrebare este care dintre cele trei servicii este lovit. Dacă jucătorii rămân conectați, dar nu mai încarcă resurse la intrare, este lovit serverul HTTP pe 22005. Dacă serverul dispare din browserul de servere în timp ce jucătorii conectați joacă normal mai departe, este lovită interogarea ASE pe 22126. Dacă toate conexiunile se rup simultan, ori 22003 este ținta, ori conexiunea este plină. Toate datele se referă la un server MTA pe Debian 12, Debian 13, Ubuntu 22.04 LTS sau Ubuntu 24.04 LTS, comenzile sunt scrise pentru root, ca utilizator obișnuit puneți sudo în față.

De ce serverele MTA:SA devin atât de des ținta atacurilor DDoS

Proiectele MTA:SA sunt ținte comode, pentru că trebuie să își publice singure adresa. Un server apare în browserul de servere doar dacă se anunță la lista de servere master și răspunde apoi la interogări din exterior. Lista conține adresa IP și portul în clar, o recunoaștere prealabilă este deci de prisos pentru un atacator.

La asta se adaugă scena însăși. Serverele de rol din spațiul german și cele braziliene, serverele de drift și adaptările DayZ concurează pentru aceiași jucători, iar o cădere la ora de vârf este maxim vizibilă. Un jucător banat, o echipă certată sau un proiect concurent nu are nevoie nici de pricepere, nici de bani demni de menționat ca să facă o seară de neutilizat. Serviciile de atac care se pot cumpăra, numite în scenă booter sau stresser, vând pentru câțiva euro pe lună exact două rezultate: să scoată serverul MTA offline pentru câteva minute sau să îl facă nejucabil prin vârfuri de lag. Ce este tehnic un atac DDoS și ce tipuri de atac există explică articolul Ce este un atac DDoS?.

Tehnic, MTA:SA le ușurează atacatorilor munca în două puncte, mai mult decât alte modificări multiplayer. În primul rând, interogarea se află pe un port UDP propriu, care la un singur byte trimite un răspuns de mai mulți kilobytes. În al doilea rând, fiecărui server MTA îi aparține un server HTTP, care livrează fișierele din partea clientului ale tuturor resurselor, și anume fără autentificare, oricui le cere.

Porturile despre care este vorba de fapt

Un server MTA:SA are nevoie de exact trei porturi: 22003 UDP pentru joc, 22005 TCP pentru serverul HTTP interior și 22126 UDP pentru interogarea ASE. Al treilea port nu este o setare la libera alegere, ci rezultă fix din portul de joc plus 123. Cine setează serverport pe 22010 primește interogarea pe 22133.

Două subtilități stau chiar așa în fișierul mtaserver.conf livrat și sunt trecute cu vederea în mod regulat. httpport poate avea aceeași valoare numerică ca serverport, pentru că un port este TCP și celălalt UDP. Iar serverip stă pe auto și ar trebui să rămână acolo: o valoare fixă leagă socketul ASE exact pe acea adresă și rupe intrarea din listă de îndată ce adresa se schimbă.

Protocolul de interogare ASE și de ce este un amplificator

ASE (All-Seeing Eye) este un protocol de interogare pur UDP: primul byte al pachetului determină răspunsul, o stabilire de conexiune nu există. Serverul MTA cunoaște cinci interogări și le răspunde pe 22126:

• s este interogarea ASE completă. Răspunsul începe cu EYE1 și conține numele serverului, tipul de joc, numele hărții, versiunea, starea parolei, numărul de jucători, lista completă a tuturor regulilor setate prin setRuleValue și apoi fiecare jucător conectat cu nume, punctaj și ping. Acest răspuns nu are nicio limită de dimensiune.
• b și r sunt interogările mai slabe pentru browserul de servere. Răspunsul începe cu EYE2 și este tăiat în codul sursă la 1.340 de bytes, ca să se evite fragmentarea.
• x livrează un mesaj de stare scurtat, v doar identificatorul de versiune ASE.

De aici rezultă problema. O cerere constă dintr-un singur byte de date utile, pe fir deci din 29 de bytes (20 de bytes antet IP, 8 bytes antet UDP, 1 byte date utile). Un răspuns de 1.400 de bytes date utile are pe fir 1.428 de bytes. Raportul este de circa 49 de ori, iar pentru că UDP nu cunoaște o stabilire de conexiune, adresa expeditorului se poate falsifica. Un atacator poate deci folosi serverul dumneavoastră ca amplificator împotriva unei a treia ținte, fără să intre vreodată în jocul dumneavoastră. La interogarea completă, factorul crește cu numărul de jucători și cu fiecare regulă pe care o setează gamemode-ul dumneavoastră.

MTA aduce împotriva acestui lucru două frâne integrate, pe care merită să le cunoașteți, pentru că explică de ce unele flooduri funcționează și altele nu. Serverul răspunde per adresă sursă la cel mult cinci interogări în șase secunde și ignoră adresa după aceea șapte secunde. În plus, păstrează răspunsurile zece secunde în memoria intermediară, în loc să le reasambleze la fiecare cerere. Numărătoarea per adresă sursă este însă complet sărită de îndată ce în listă stau simultan mai mult de 100 de adrese de expeditor diferite. Exact asta este cazul normal la un flood distribuit dintr-o rețea de boți sau cu expeditori falsificați, și de aceea frâna integrată nu ajută împotriva unui atac serios.

Ce puteți face singur înainte de a cheltui bani

Această secțiune este cea mai lungă, și asta în mod intenționat. Un server MTA configurat curat rezistă cu forțe proprii la atacuri mici și medii, indiferent la cine este găzduit.

1. Inventar: ce ascultă de fapt?

Uitați-vă mai întâi ce oferă serverul dumneavoastră spre exterior. Nu ghiciți, verificați:

ss -lntup

De așteptat sunt trei linii ale procesului MTA: 0.0.0.0:22003 pe UDP, 0.0.0.0:22005 pe TCP și 0.0.0.0:22126 pe UDP. Dacă apare acolo în plus o bază de date pe 0.0.0.0:3306, un server web sau un serviciu de voce uitat, acestea trebuie oprite. Perspectiva atacatorului o oferă o scanare de porturi din exterior:

nmap -Pn -sU -p 22003,22126 ADRESA.IP.A.SERVERULUI
nmap -Pn -p 22005 ADRESA.IP.A.SERVERULUI

Serverul aduce pentru asta și o comandă de consolă proprie. În consola serverului, openports verifică dacă toate cele trei porturi sunt accesibile din exterior.

2. Lăsați deschise doar cele trei porturi de care MTA are nevoie cu adevărat

Cu UFW, o configurație de bază solidă arată așa, și anume exact în această ordine, ca să nu vă blocați singur accesul:

ufw allow 22/tcp comment 'SSH'
ufw allow 22003/udp comment 'MTA joc'
ufw allow 22005/tcp comment 'MTA HTTP'
ufw allow 22126/udp comment 'MTA ASE'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Instrucțiunile complete, inclusiv calea de salvare, stau în articolul Configurarea firewallului UFW. La serverele root KVM și la serverele dedicate de la KernelHost ajungeți la sistem în caz de urgență prin consola VNC din panoul clientului, chiar și când conexiunea este saturată.

Baza de date nu are ce căuta în rețeaua deschisă. Dacă ss -lntp | grep 3306 arată un 0.0.0.0:3306, setați în /etc/mysql/mariadb.conf.d/50-server.cnf linia bind-address = 127.0.0.1 și reporniți serviciul.

3. Limitați portul ASE fără să ieșiți din lista de servere

Spre deosebire de SA-MP, la MTA:SA interogarea se află pe un port propriu, o puteți deci limita independent de funcționarea jocului. Acesta este cel mai mare avantaj practic al acestei arhitecturi: o regulă pe 22126 nu dă afară niciun jucător.

Cu nftables într-un tabel propriu, ca setul de reguli să nu intre în conflict cu UFW:

nft add table inet mtaguard
nft add chain inet mtaguard input '{ type filter hook input priority -150 ; policy accept ; }'
nft add rule inet mtaguard input udp dport 22126 meter aseperip '{ ip saddr limit rate over 3/second burst 6 packets }' drop
nft add rule inet mtaguard input udp dport 22126 limit rate over 2000/second burst 500 packets drop
nft list table inet mtaguard

Prima regulă limitează fiecare adresă sursă în mod individual, a doua întregul port. Amândouă împreună sunt importante: un flood distribuit trece prin golul dintre multe surse individuale dacă se limitează doar per adresă. Valorile sunt alese strâmt, iar aici asta este acceptabil, pentru că un browser de servere real interoghează serverul dumneavoastră doar la câteva secunde. Cu iptables, modulul hashlimit obține același lucru:

iptables -A INPUT -p udp --dport 22126 -m hashlimit --hashlimit-name mta_ase \
  --hashlimit-mode srcip --hashlimit-above 3/sec --hashlimit-burst 6 \
  --hashlimit-htable-expire 30000 -j DROP

Încercarea de a închide portul complet este o cântărire de argumente și nu un pont secret: fără ASE, serverul dumneavoastră dispare din browserul de servere și deci din afluxul organic de jucători. Dacă vreți totuși asta, <ase>0</ase> nu este suficient. În codul sursă, deschiderea portului atârnă de legătura sau dintre modul internet și modul LAN, socketul rămâne deci deschis la <ase>0</ase>, atât timp cât stă <donotbroadcastlan>0</donotbroadcastlan>. Cine vrea chiar să închidă portul setează ambele:

<ase>0</ase>
<donotbroadcastlan>1</donotbroadcastlan>

Calea mai cinstită pentru un proiect în creștere este: lăsați portul deschis, limitați rata și țineți efectul de amplificare mic prin faptul că gamemode-ul dumneavoastră nu publică reguli inutile prin setRuleValue. Fiecare regulă apare în interogarea completă și mărește răspunsul.

4. Degrevați serverul HTTP interior

Serverul HTTP pe 22005 este la MTA:SA o suprafață de atac proprie, pentru că fiecare jucător care se conectează descarcă de acolo toate fișierele din partea clientului ale tuturor resurselor care rulează. La un proiect de rol cu modele proprii, asta ajunge repede la câteva sute de megabytes, împărțite pe sute de fișiere individuale. Serverul integrat este construit intenționat simplu: fără compresie, cu un contingent fix de fire de execuție. Câteva zeci de accesări simultane sunt suficiente ca jucătorii reali să atârne minute întregi în ecranul de încărcare.

Cea mai eficientă măsură este să scoateți descărcările complet din serverul de joc. MTA pregătește singur fișierele care trebuie livrate, sub mods/deathmatch/resource-cache/http-client-files. Acest folder îl publicați prin nginx sau lighttpd și treceți adresa în mtaserver.conf:

<httpdownloadurl>http://cdn.domeniul-dvs.tld/mta</httpdownloadurl>

Asta aduce două lucruri deodată. Descărcările merg printr-un server web construit pentru asta și nu mai merg prin adresa serverului dumneavoastră de joc. Dacă serverul web se află pe altă mașină sau în spatele unei rețele de distribuție de conținut, un flood împotriva descărcărilor nu mai lovește funcționarea jocului. Important: dacă adresa externă este greșită sau inaccesibilă, MTA comută în silențiu înapoi pe serverul interior.

Dacă serverul interior rămâne în funcțiune, folosiți-i limitele proprii. În mtaserver.conf:

<httpmaxconnectionsperclient>5</httpmaxconnectionsperclient>
<httpdosthreshold>20</httpdosthreshold>
<http_dos_exclude></http_dos_exclude>
<httpthreadcount>8</httpthreadcount>

httpmaxconnectionsperclient limitează conexiunile simultane per client la 5, în intervalul permis de la 1 la 8. httpdosthreshold limitează câte conexiuni poate stabili o singură adresă IP într-un timp scurt, valoare implicită 20. http_dos_exclude exceptează adrese individuale, de exemplu propria pagină de stare. httpthreadcount stabilește numărul firelor de execuție, valoare implicită 8 în intervalul de la 1 la 20. O valoare mai mare ajută la multe fișiere mici, dar costă timp de calcul care lipsește funcționării jocului.

Gândiți-vă în plus la ce se mai livrează pe același port. Resursele webadmin și resourcebrowser sunt pornite în configurația livrată și accesibile în browser prin 22005. O interfață de administrare nu are ce căuta neprotejată în rețeaua deschisă: atribuiți în acl.xml drepturi curate, creați un cont propriu cu o parolă lungă și aleatoare și opriți resursa atunci când nu aveți nevoie de ea.

5. Folosiți limitele integrate din mtaserver.conf

MTA aduce mai multe limite de protecție decât folosesc majoritatea proiectelor. Unele stau fix în codul sursă, altele în mtaserver.conf. Acest tabel le adună pe cele care joacă un rol la un atac:

Trei setări merită o decizie conștientă. maxplayers stă pe 32 și ar trebui să corespundă realității: fiecare slot suplimentar mărește interogarea completă și crește numărul de conexiuni pe care le poate ocupa un atacator. bandwidth_reduction stă pe medium, valoarea maximum scade sensibil încărcarea de ieșire, dar costă precizie de sincronizare. Iar <password></password> face din serverul dumneavoastră, fără efort, un cerc închis, în timp ce intrarea din listă se păstrează: cea mai rapidă frână de urgență la un flood de conectări în curs.

6. Distingeți floodurile de conectări de floodurile de evenimente

Două tipare de atac nu țintesc conexiunea, ci logica jocului, și sunt confundate în mod regulat.

Un flood de conectări stabilește în succesiune rapidă conexiuni reale, până când toate sloturile sunt ocupate sau serverul nu mai face față stabilirii lor. MTA limitează asta din proprie inițiativă la patru conexiuni per adresă sursă în 30 de secunde și ignoră adresa după aceea 30 de secunde. Ce face frâna în acel moment arată comanda de consolă debugjoinflood. Limita se aplică per adresă, o rețea de boți cu o mie de adrese trece pe lângă ea. Împotriva acestui lucru ajută o parolă de server, o listă albă în gamemode și o limitare de rată pe 22003.

Un flood de evenimente vine în schimb de la jucători deja conectați: un client manipulat trimite triggerServerEvent într-o buclă, până când serverul nu mai poate furniza timpul de calcul. MTA permite pentru asta din fabrică 100 de evenimente per jucător și secundă și dă afară peste această limită, cu un mesaj despre flooduri de evenimente. Dacă gamemode-ul dumneavoastră folosește multe evenimente mici, verificați valoarea înainte să o coborâți: setată prea strâmt, dă afară proprii jucători.

Independent de asta, pe partea de server este valabilă aceeași regulă ca oriunde: nu vă bazați niciodată pe valori pe care le trimite clientul, determinați jucătorul din expeditorul evenimentului și limitați tot ce declanșează o interogare de bază de date. Un singur eveniment neverificat, care pornește o interogare, este suficient ca să oprească un server fără niciun atac de rețea.

7. Lista de servere, adresa IP și ce mai dezvăluie ea

Adresa dumneavoastră IP nu poate fi ținută secretă. O cunoaște fiecare jucător care a fost conectat măcar o dată, iar intrarea din lista de servere master o publică oricum. Un domeniu în față nu ajută: clientul rezolvă numele o singură dată și vorbește după aceea direct cu adresa.

Verificați în schimb ce mai dezvăluie adresa dumneavoastră. Scurgeri tipice la proiectele MTA sunt înregistrările A și AAAA vechi din DNS, pagina proiectului pe aceeași mașină, un bot Discord cu afișaj de stare, care citește public interogarea ASE, certificatele TLS cu nume de gazdă vechi și postările din forum din perioada de început. De aici rezultă o regulă pe care multe proiecte o învață prea târziu: dacă vă mutați pe o adresă protejată, schimbați în același timp adresa veche. Dacă ea rămâne, stă în fiecare bază de date de scanare, iar atacul trece pe lângă protecție.

Două intrări din mtaserver.conf privesc direct vizibilitatea. <serverip>auto</serverip> rămâne pe auto, în afară de cazul în care știți exact de ce nu. Iar <owner_email_address> trebuie completat: dacă intrarea lipsește sau este greșită, asta poate afecta vizibilitatea în lista de servere master.

8. Jurnalizați, ca să aveți date în caz de urgență

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 merge 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 vineri seara. Cu apt-get install -y vnstat sysstat măsurarea rulează permanent.

În timpul unui incident separați mai întâi cele trei porturi unul de altul. Aceste patru comenzi sunt suficiente:

sar -n DEV 1 10
nstat -az | grep -E 'Udp(InDatagrams|InErrors|NoPorts|RcvbufErrors)'
tcpdump -ni eth0 -c 200 -q 'udp port 22126'
ss -tn state established '( dport = :22005 or sport = :22005 )' | wc -l

Evaluarea este mai simplă decât pare. Dacă erorile de buffer cresc la o încărcare mică a procesorului, vă ajunge mai mult trafic decât poate procesa procesul. Dacă un nucleu de procesor merge la maxim în timp ce traficul pare normal, problema stă în gamemode și nu în rețea. Dacă captura pe 22126 arată multe pachete cu un singur byte de date utile, este un val de interogări ASE. Dacă numărul conexiunilor deschise pe 22005 stă permanent în zona a patru cifre, este lovit serverul HTTP. La tcpdump este valabil întotdeauna: limitați cu -c, o captură la încărcare maximă solicită suplimentar un server deja suprasolicitat. Cum evaluați valorile în detaliu descrie articolul Recunoașterea unui atac DDoS pe server.

Jurnalul serverului însuși se află sub logs/server.log, jurnalul scripturilor sub logs/scripts.log. Ambele căi stau în mtaserver.conf și se pot muta.

Unde se opresc aceste măsuri

Acum urmează partea pe care nicio configurație nu o poate rezolva. 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.

Faceți o dată socoteala. Un server de joc obișnuit este legat la 1 Gbit/s, ceea ce corespunde la 125 de megabytes pe secundă și, la pachete de 64 de bytes, la circa 1,49 milioane de pachete pe secundă. Atacurile împotriva proiectelor de servere de joc de această dimensiune se află de obicei între 5 și 50 Gbit/s, deci la de cinci până la cincizeci de ori conexiunea dumneavoastră. Dacă regula dumneavoastră nftables din spate este bună nu mai joacă atunci niciun rol, pentru că pachetele jucătorilor dumneavoastră nu mai trec nici înainte de ea.

Rata de pachete lovește deseori mai devreme decât lățimea de bandă. Un kernel obișnuit de server prelucrează, în funcție de procesor și placă de rețea, câteva sute de mii de pachete pe secundă înainte de a începe să elimine. Un atac care nu vă umple conexiunea nici la o treime vă poate deci 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 totul dispăruse”.

La MTA:SA se adaugă o a treia limită, iar ea intervine cel mai timpuriu. Serverul citește porturile de rețea într-un singur flux de execuție. Un val de interogări pe 22126 ocupă acest flux astfel încât pachetele de sincronizare ale jucătorilor reali expiră în bufferul de recepție, cu mult înainte ca conexiunea să fie plină. Procesul nu se prăbușește, devine doar lent, iar jucătorii văd efecte de elastic. Același lucru este valabil pentru serverul HTTP: își împarte timpul de calcul cu funcționarea jocului.

Pentru încadrare, ce ordine de mărime apar în realitate: pe serverele KernelHost au fost filtrate, printre altele, un atac de peste 473,4 Gbit/s cu peste 41,5 milioane de pachete pe secundă asupra unui server de voce și un flood UDP de peste 112,2 Gbit/s cu peste 8,7 milioane de pachete pe secundă asupra unui server de joc. Primul caz este de circa 473 de ori lățimea de bandă și de circa 28 de ori rata de pachete pe care o poate primi în general o conexiune de 1 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 în față

Protecția permanentă inclusă pe fiecare server

Fiecare server de la KernelHost stă în spatele unei filtrări pe două niveluri, activă permanent:

• 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ă măcar la centrul de date din Frankfurt pe Main.
• Nivelul 2: filtrare Arbor în timp real cu 3,2 Tbps direct la fața locului, în Frankfurt pe Main. Nemijlocit în fața serverului sunt recunoscute tiparele specifice fiecărui protocol și eliminate pachet cu pachet.

Trei proprietăți sunt decisive. Protecția este activă permanent, nu există deci o fază de detecție în care serverul dumneavoastră iese offline. Nu se folosește niciun nullrouting: adresa atacată rămâne în rețea, eliminate sunt doar pachetele dăunătoare, în timp ce conexiunile jucătorilor reali merg mai departe. Și nu costă nimic în plus, ci este inclusă din momentul livrării în fiecare pachet de server, de la serverul root KVM, prin serverul de joc, până la serverul dedicat. Se filtrează pe nivelurile 3, 4 și 7, pe fiecare port TCP sau UDP, deci pe 22003 UDP, 22005 TCP și 22126 UDP simultan. Totul este operat în centrul de date maincubes din Frankfurt pe Main, Germania. Ce jocuri și protocoale au profiluri proprii arată articolul Protecție DDoS în timp real pentru servere de joc.

Advanced DDoS Protection pentru proiecte atacate permanent

Unele proiecte nu sunt lovite ocazional, ci țintit, săptămâni la rând. Pentru acest caz 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:

• Un IP de protecție dedicat din nucleul de la Frankfurt. Serverul dumneavoastră este comutat pe el în interiorul rețelei KernelHost, de partea dumneavoastră nu modificați nimic.
• Reguli de protecție administrabile de dumneavoastră per port și protocol în panoul clientului. Exact asta este esențial la MTA:SA: setați reguli separate pentru 22003 UDP, 22005 TCP și 22126 UDP, în loc să tratați trei servicii foarte diferite după același calapod.
• Modificările se aplică în timp real, fără tichet și fără timp de așteptare. Puteți deci ajusta chiar în mijlocul unui atac în curs.
• Un profil de protecție potrivit jocului. Multi Theft Auto este disponibil ca profil propriu, la fel și servere web, servere de voce și aplicații TCP sau UDP proprii, care se potrivesc în spatele aceleiași adrese de protecție.

Cele două niveluri în comparație

Pentru majoritatea proiectelor MTA:SA este suficientă protecția permanentă inclusă împreună cu o configurație curată a serverului. Advanced DDoS Protection este răspunsul la faptul că cineva o ia personal.

Erori frecvente și soluții

„Am blocat 22126, serverul nu apare oricum în nicio listă, dar continuă să primească interogări”: Atunci socketul este încă deschis. <ase>0</ase> singur nu închide portul, atât timp cât este setat <donotbroadcastlan>0</donotbroadcastlan>. Verificați cu ss -lnup | grep 22126 dacă chiar nu mai ascultă nimic.

„Jucătorii atârnă în ecranul de încărcare, jocul în sine merge normal”: Acesta nu este un atac pe 22003, ci serverul HTTP pe 22005 la limită. Externalizați descărcările prin httpdownloadurl și verificați httpmaxconnectionsperclient și httpthreadcount.

„Serverul a dispărut din browser, jucătorii de pe el nu observă nimic”: Atunci este lovit exclusiv 22126. Pentru jucătorii conectați asta nu are consecințe, pentru afluxul de jucători noi are. O limitare de rată pe acest singur port este răspunsul corect, nu una pe portul de joc.

„Am schimbat adresa IP și două ore mai târziu eram iar offline”: Atacatorul are noua adresă din aceeași sursă ca pe cea veche, de obicei intrarea din listă, un bot Discord cu interogare de stare sau o înregistrare DNS veche. O schimbare de adresă este un câștig de timp, nu o soluție.

„Am setat o limită de 20 de pachete pe secundă per adresă pe 22003”: Asta este prea strâmt. Deja un singur jucător trece peste ea la sincronizare activă, iar mai mulți jucători în spatele aceleiași adrese NAT împart același contingent. Vă dați astfel afară proprii jucători. Pe 22126, în schimb, valorile strâmte sunt fără probleme.

„Ne-am blocat singuri accesul prin firewall”: O repornire nu ajută, pentru că UFW își restaurează regulile la pornire. La KernelHost deschideți consola VNC din panoul clientului și executați acolo ufw disable. Consola VNC lucrează independent de rețeaua sistemului oaspete.

„Furnizorul meu de până acum mi-a blocat adresa IP”: Acesta este nullrouting. Furnizorul își protejează astfel propria rețea, iar pentru dumneavoastră rezultatul este identic cu un atac reușit, de obicei încă 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.

„Așteptăm pur și simplu să treacă atacul”: Atacurile care funcționează sunt repetate. Documentați momentul cu fus orar, durata, valorile de vârf și portul afectat. Exact aceste date îi trebuie și unui tichet de suport, pentru ca filtrarea să fie ajustată țintit.

Pe scurt

• Un server MTA:SA are nevoie de exact trei porturi: 22003 UDP pentru joc, 22005 TCP pentru serverul HTTP interior și 22126 UDP pentru interogarea ASE. Al treilea rezultă fix din portul de joc plus 123.
• Interogarea ASE se află pe un port propriu și se poate deci limita fără să dați afară niciun jucător. Aceasta este cea mai importantă diferență față de SA-MP, unde jocul și interogarea împart același port.
• Un singur byte de cerere pe 22126 produce un răspuns de până la mai mulți kilobytes, iar adresa expeditorului se poate falsifica. Un port ASE nelimitat este deci în același timp țintă și amplificator.
• Frânele integrate ale MTA se aplică per adresă sursă: cinci interogări în șase secunde, patru conectări în 30 de secunde. La mai mult de 100 de adrese sursă simultane, numărătoarea interogărilor este sărită, un flood distribuit trece deci prin ea.
• Serverul HTTP interior pe 22005 este o suprafață de atac proprie. Cine externalizează descărcările prin httpdownloadurl către un server web extern le scoate din funcționarea jocului.
• Tot ce rulează pe server decide numai asupra atacurilor mici. La 1 Gbit/s se termină la circa 1,49 milioane de pachete pe secundă, independent de calitatea regulilor dumneavoastră.
• Protecția permanentă pe două niveluri de la KernelHost este inclusă fără cost suplimentar în fiecare pachet de server și lucrează fără nullrouting. Cine vrea să controleze singur regulile per port ia în plus Advanced DDoS Protection de la 50,00 € pe lună.

Dacă proiectul dumneavoastră rulează deja la KernelHost, filtrarea este activă permanent, nu trebuie să activați nimic. Dacă observați totuși nereguli, deschideți un tichet de suport cu perioada, portul și comportamentul observat, pentru ca regulile pentru adresa dumneavoastră să fie ajustate. În cazul unui atac în curs ne găsiți suplimentar prin chatul de urgență WhatsApp la +43 650 8209883. Dacă găzduiți încă în altă parte și sunteți lovit regulat, mutarea la Frankfurt pe Main este soluția mai scurtă: pașii următori pentru cazul acut stau în articolul Atac DDoS grav: ce este de făcut?.