Protejarea unui server RedM împotriva atacurilor DDoS

Un server RedM care seara, în mijlocul sesiunii, dispare și reapare zece minute mai târziu are rar o problemă de hardware. De regulă rulează un atac pe portul 30120, și el rulează exact atunci când sunt online cei mai mulți jucători. Acest articol arată cum protejați un server RedM împotriva atacurilor DDoS: mai întâi ceea ce puteți securiza singur, fără costuri suplimentare, apoi limita fizică a acestor măsuri și, la final, ce trebuie să se întâmple în rețeaua din fața serverului atunci când atacul este mai mare decât conexiunea dumneavoastră.

Toate datele se referă la un FXServer cu gamename rdr3 sub 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ță. RedM este modificarea pentru Red Dead Redemption 2 de la Cfx.re și proiectul frate al FiveM. Amândouă rulează pe același program de server, motiv pentru care o parte din tehnica de rețea este într-adevăr identică. Unde este cazul, aici se află într-o singură propoziție, iar partea detaliată în articolul Protejarea unui server FiveM împotriva atacurilor DDoS. Tot restul din acest text este specific pentru RedM.

Dacă atacul este chiar acum în curs: Nu modificați nimic acum în server.cfg și nu reporniți serverul. Salvați mai întâi valorile măsurate (vedeți secțiunea „Adunați valori de măsurare”), după atac ele dispar.

De ce serverele RedM devin atât de des ținta atacurilor DDoS

Un server RedM este o țintă mai profitabilă decât lasă să se presupună numărul lui de jucători. Motivul este chiar dimensiunea mică a scenei. În septembrie 2026, serviciile publice de urmărire a listelor de servere numărau circa 2.000 de servere RedM active cu aproximativ 12.400 de jucători simultani, față de circa 39.000 de servere FiveM cu aproximativ 325.000 de jucători. Cine scoate din funcțiune unul din 2.000 de servere RedM ia astfel din rețea o parte vizibil mai mare din întreaga scenă decât cineva care lovește unul din 39.000 de servere FiveM. Pentru un atacator care vrea să facă rău unui proiect concurent, pârghia este deci incomparabil mai mare.

La asta se adaugă structura comunităților. Roleplay-ul de RedM trăiește din sesiuni fixe la ore fixe, adesea cu înscriere și cu aprobarea personajului. O cădere la ora 20 nu lovește niște jucători oarecare, ci exact pe cei care s-au înscris pentru acea seară. Multe proiecte rulează pe lângă asta ca hobby, cu un buget mic, atârnă de un singur server ieftin și nu au o a doua instanță pe care s-ar putea comuta. Cazuri documentate public din scena RedM descriu serii de atacuri întinse pe luni, în ritm aproape zilnic, care au lovit simultan serverul de joc și serverul de voce separat.

Din punct de vedere tehnic se adaugă faptul că traficul de joc circulă prin UDP. UDP este un protocol de transport fără conexiune: nu există nicio deschidere de conexiune pe care serverul ar putea să o pretindă, iar adresele expeditorului pot fi falsificate. Un atacator nu trebuie deci nici să intre pe serverul dumneavoastră RedM, nici să i se adreseze corect pentru a genera încărcare. Ce este exact un atac DDoS și cum este construit explică articolul Ce este un atac DDoS?.

Porturile despre care este vorba în realitate

Un server RedM se leagă în mod implicit la un singur port, și anume pe ambele protocoale. În server.cfg stă pentru asta:

endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"
set gamename rdr3
sv_enforceGameBuild 1491
sv_licenseKey "cfxk_..."

Linia set gamename rdr3 este singura care deosebește un server RedM de un server FiveM. Dacă lipsește, același FXServer se anunță ca server de GTA V, iar un client RedM nu se conectează. RedM nu are un port de interogare propriu și nici un port RCON propriu: interogarea serverului, deschiderea conexiunii, traficul de joc și RCON circulă toate prin aceleași două intrări pe 30120. Aceasta este situația dură a cifrelor:

Din cele patru porturi numite, exact două au ce căuta în rețeaua deschisă: 30120 TCP și 30120 UDP. Portul 40120 și portul 3306 nu au ce căuta acolo, iar SSH pe portul 22 ar trebui limitat la adresele proprii. Aceasta este cea mai frecventă greșeală evitabilă pe serverele RedM, deoarece multe proiecte pornesc cu o rețetă txAdmin gata făcută și nu verifică niciodată după aceea ce oferă serverul în exterior.

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 RedM configurat curat rezistă cu forțe proprii la atacuri mici și medii, independent de locul unde este găzduit. Ordinea este aleasă în mod conștient: mai întâi măsurați, apoi închideți și abia după aceea limitați.

1. Inventar: ce ascultă în realitate?

Înainte să scrieți o singură regulă, verificați ce oferă serverul dumneavoastră în exterior. Nu ghiciți, verificați:

ss -lntup

Interesantă este coloana cu adresa locală. 0.0.0.0:30120 și [::]:30120 înseamnă „accesibil din întregul internet”, 127.0.0.1:3306 înseamnă „numai local” și nu are nevoie de nicio regulă de firewall. Pe lângă FXServer apar pe un server RedM în mod regulat txAdmin pe 40120, MariaDB pe 3306, un server web pentru pagina proiectului și ocazional un serviciu de voce. Perspectiva atacatorului o oferă o scanare de porturi din exterior:

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

2. Lăsați deschise numai 30120 TCP și UDP

Pentru RedM sunt suficiente două permisiuni către exterior, tot restul este restrâns sau nici nu este publicat. Cu UFW arată așa, și exact în această ordine, ca să nu vă blocați singur accesul:

ufw allow 22/tcp comment 'SSH'
ufw allow 30120/tcp comment 'RedM'
ufw allow 30120/udp comment 'RedM'
ufw allow from 203.0.113.10 to any port 40120 proto tcp comment 'txAdmin'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Înlocuiți 203.0.113.10 cu adresa dumneavoastră proprie. La o conexiune cu adresă schimbătoare asta este nepractic, calea mai bună se află în secțiunea următoare despre txAdmin. Instrucțiunile complete, inclusiv calea de întoarcere, se află în Configurarea firewallului UFW fără să vă blocați singur accesul.

Baza de date nu are ce căuta în niciun caz în rețeaua deschisă. VORP, RSGCore și RedEM:RP au nevoie toate de o MariaDB sau de o MySQL, de regulă prin oxmysql cu un șir de conexiune în server.cfg. Această conexiune rulează local, portul nu trebuie deci să fie accesibil din exterior. Verificați în /etc/mysql/mariadb.conf.d/50-server.cnf că acolo stă:

bind-address = 127.0.0.1

3. Securizați punctele finale HTTP ale FXServer

FXServer răspunde cererilor HTTP pe partea TCP a portului 30120, fără să fie nevoie ca cineva să pornească Red Dead Redemption 2. Uitați-vă la ce livrează acolo serverul dumneavoastră RedM:

curl -s http://127.0.0.1:30120/info.json | head -c 600
curl -s http://127.0.0.1:30120/players.json | head -c 600
curl -s http://127.0.0.1:30120/dynamic.json

/players.json listează jucătorii conectați împreună cu identificatorii lor, /info.json configurația serverului și resursele încărcate, /dynamic.json ocuparea actuală. Exact aceste trei puncte finale sunt calea de atac documentată pe stratul 7 împotriva serverelor FiveM și RedM: sunt accesibile fără autentificare, pot fi interogate de câte ori se vrea, fiecare interogare costă serverul dumneavoastră muncă, iar conținutul îi spune unui atacator când merită un atac. Două contramăsuri nu costă nimic. În primul rând, punctele finale ale jucătorilor nu au ce căuta în răspuns, pentru asta este suficientă o linie în server.cfg:

sv_endpointPrivacy true

Această setare ascunde adresele IP ale jucătorilor dumneavoastră în ieșirile publice ale serverului. În al doilea rând: dacă botul dumneavoastră de Discord sau pagina proiectului afișează numărul de jucători, nu interogați punctul final din partea vizitatorului, ci stocați rezultatul intermediar la intervale fixe. Astfel, o pagină de stare mult vizitată generează o interogare pe interval, în loc de una pe vizitator. La o scenă mică precum RedM asta cântărește dublu, deoarece un singur bot de stare a serverului poate fi integrat simultan în mai multe servere de Discord.

4. Scoateți txAdmin de pe portul 40120 din rețeaua deschisă

txAdmin este interfața de administrare cuprinsă în versiunea de FXServer pentru FiveM și RedM, și ascultă în mod implicit pe 40120 TCP. În spatele ei se află accesul complet la serverul dumneavoastră: reporniri, listă de interdicții, baza de date a jucătorilor, administrarea resurselor. Fără o adresă IP fixă pentru permisiune, lăsați portul închis către exterior și ajungeți la el printr-o redirecționare locală de port prin SSH, după care deschideți în browser http://127.0.0.1:40120:

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

Cine lasă txAdmin public primește două probleme în același timp: o mască de autentificare împotriva căreia se pot conduce flooduri de autentificare, și un serviciu care depune muncă la fiecare cerere, deși nu are nimic de-a face cu jocul. La nevoie legați txAdmin direct local, lăsând serviciul să asculte numai pe 127.0.0.1.

5. Limitați ratele de conexiuni și de pachete pe adresă sursă

Împotriva atacurilor mici și a boților prost făcuți ajută o limită superioară pe adresă sursă. Cele două reguli se aplică pentru 30120, deci pentru ambele protocoale ale jocului:

iptables -I INPUT -p tcp --dport 30120 --syn -m connlimit --connlimit-above 8 --connlimit-mask 32 -j DROP
iptables -I INPUT -p udp --dport 30120 -m hashlimit --hashlimit-name redm_udp --hashlimit-mode srcip --hashlimit-above 500/sec --hashlimit-burst 750 -j DROP

Prima regulă elimină conexiunile TCP noi de îndată ce o adresă are mai mult de opt dintre ele deschise simultan, a doua elimină pachetele UDP de la permanent mai mult de 500 de pachete pe secundă din aceeași sursă. Valorile de pornire sunt aici puțin mai mici decât la un server FiveM, deoarece un server RedM cu 32 de sloturi generează pur și simplu mai puține conexiuni legitime pe adresă. Valorile de pornire nu sunt însă adevăruri absolute: o seară de RP plină generează vizibil mai multe pachete decât un server gol, iar cine setează prea strâns își aruncă afară jucătorii proprii. Măsurați mai întâi o săptămână în regim normal.

Două observații la asta. Regulile pure de iptables dispar după o repornire, sub Debian și Ubuntu se salvează astfel:

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

Iar sub UFW, astfel de reguli trebuie trecute în /etc/ufw/before.rules, deoarece altfel dispar la următorul ufw reload. Un blocaj deseori trecut cu vederea este pe lângă asta urmărirea conexiunilor din kernel: dacă se umple, serverul elimină și pachete legitime, iar în jurnal apare „nf_conntrack: table full”. Starea și limita superioară se văd cu:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

6. Securizați cele 32 de sloturi împotriva floodurilor de conectări

Un server RedM are fără OneSync exact 32 de sloturi. Cu OneSync sunt 48, iar peste asta este nevoie de un abonament Element Club pentru până la 1.024 de locuri. Această cifră este relevantă pentru securitate, deoarece este limita superioară pe care un atacator trebuie să o umple: cine ține deschise simultan 32 de încercări de conectare ocupă complet un server standard, fără ca un singur jucător să ajungă efectiv în joc. La un proiect FiveM cu 128 de locuri, același prag este de patru ori mai mare.

Un avantaj specific pentru RedM compensează asta parțial: RedM presupune o copie autentică de Red Dead Redemption 2, indiferent dacă este cumpărată prin Steam, Epic Games sau Rockstar, la care se adaugă Rockstar Launcher. Un flood de conectări cu mii de conturi de unică folosință, așa cum este obișnuit la jocurile gratuite, costă aici deci bani adevărați. Atacurile se deplasează astfel pe nivelul rețelei și pe punctele finale HTTP, unde nu este nevoie de nicio copie a jocului.

Împotriva a tot ce folosește calea obișnuită de conectare acționează totuși o listă albă. Ea se realizează pe partea serverului în evenimentul playerConnecting, unde opriți conexiunea cu funcțiile Deferrals, verificați identificatorul și abia după aceea dați liber. La asta se adaugă o verificare strictă a contului și o limită superioară realistă de jucători:

sv_authMaxVariance 1
sv_authMinTrust 5
sv_maxclients 32

sv_authMaxVariance este o valoare de la 1 la 5 și arată cât de mult are voie să se schimbe identificatorul unui jucător la un furnizor; 1 este setarea cea mai strictă. sv_authMinTrust merge de asemenea de la 1 la 5 și descrie cât de improbabilă trebuie să fie o identitate falsificată; 5 este aici valoarea cea mai strictă. O parolă de RCON o setați numai dacă aveți nevoie cu adevărat de RCON, deoarece accesul se află pe același port deschis 30120. Și un lucru trebuie să fie clar: o listă albă vă protejează logica jocului, nu conexiunea. Un atacator care vă inundă serverul nu vrea deloc să se conecteze. Pachetele lui sunt respinse, dar au sosit totuși, și exact asta este problema.

7. Evaluați corect intrarea din lista de servere RedM

Aici merită sinceritatea în locul gândirii dorite: adresa dumneavoastră IP nu poate fi ținută secretă. RedM folosește aceeași infrastructură de servere master Cfx.re ca FiveM, iar intrarea din listă conține în câmpul connectEndPoints punctul final de conexiune în clar. Prin interfața publică de la servers-frontend.fivem.net se poate interoga, pentru fiecare cod cfx.re, adresa aferentă, pentru RedM la fel ca pentru FiveM. Cine nu are deloc nevoie de intrarea publică, deoarece proiectul merge exclusiv prin Discord și prin conexiune directă, poate conduce serverul ca privat cu sv_master1 "": la el nu se mai poate conecta nimeni prin lista de servere. Asta costă însă toată vizibilitatea pentru jucătorii noi, iar într-o scenă cu 2.000 de servere, vizibilitatea este adevăratul motor de creștere.

Mai eficiente sunt două obiceiuri. Nu publicați nicăieri singur adresa IP brută, deci nici pe canalul de Discord, nici pe pagina proiectului. Și conectați-vă jucătorii printr-un nume de gazdă, ca să puteți schimba adresa în caz serios fără ca toate referințele să se rupă. Clasicul sunt aici înregistrările DNS vechi: o înregistrare A uitată către adresa anterioară face orice schimbare lipsită de efect.

8. Verificați pe partea serverului evenimentele VORP, RSGCore și RedEM

Multe căderi care sunt raportate ca atac DDoS se datorează unui singur script. Resursele RedM comunică prin evenimente de rețea, iar un eveniment pe care serverul îl execută neverificat este o ușă deschisă: cine trimite din client un TriggerServerEvent cu valori arbitrare poate genera dolari, poate face să apară cai sau poate declanșa în buclă interogări în baza de date, până când serverul se oprește. Asta lovește în egală măsură toate cele trei framework-uri răspândite: VORP Core, care are din 2020 cea mai mare bază de scripturi, RSGCore și mai vechiul RedEM:RP.

Deosebit de vulnerabile sunt resursele de inventar și de personaj, deoarece scriu în baza de date la fiecare apel. O buclă de evenimente care salvează de zece ori pe secundă o stare de inventar apasă un server RedM mai puternic decât multe valuri de pachete, și ea vine din interior, unde nu acționează nicio regulă de firewall.

Trei reguli prind cea mai mare parte din asta. Înregistrați cu RegisterNetEvent exclusiv evenimentele care trebuie să vină cu adevărat de la client. Nu vă bazați niciodată pe valorile pe care le trimite clientul, ci determinați jucătorul pe partea serverului din source. Și limitați de câte ori are voie un jucător să declanșeze același eveniment, mai ales la tot ce are o interogare în baza de date. Dacă serverul se blochează scurt în timp ce conexiunea este liniștită, resmon 1 arată în consola clientului timpul de calcul pe resursă, iar de regulă vinovatul stă chiar în frunte.

9. Adunați valori de măsurare înainte să aveți nevoie de ele

Pasul cel mai important este cel 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 o seară de marți bine vizitată. Cu apt-get install -y vnstat sysstat măsurarea rulează permanent. În timpul unui incident sunt suficiente patru comenzi: ratele de pachete pe secundă, rata de pachete eliminate a interfeței, mesajele kernelului și o probă scurtă a traficului.

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

La tcpdump se aplică o regulă: limitați întotdeauna cu -c, o captură sub încărcare maximă apasă suplimentar un server oricum suprasolicitat. Fiți atent pe lângă asta dacă încărcarea se află pe partea UDP sau pe partea TCP a portului 30120. Încărcarea UDP arată spre un val de pachete împotriva traficului de joc, încărcarea TCP spre un val împotriva punctelor finale HTTP, iar amândouă au nevoie de contramăsuri diferite. Cum evaluați valorile se află în Recunoașterea unui atac DDoS.

Unde se termină aceste măsuri

Acum partea pe care nicio server.cfg 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 game server tipic atârnă de o conexiune de 1 Gbit/s, adică 125 de megaocteți pe secundă, iar conexiunea este plină de îndată ce cineva trimite mai mult. Atacurile împotriva proiectelor de roleplay se situează de obicei între 5 și 50 Gbit/s, adică la de cinci până la cincizeci de ori conexiunea dumneavoastră. Dacă regula dumneavoastră de iptables din spate este bună nu mai joacă atunci niciun rol, deoarece pachetele jucătorilor dumneavoastră nu mai trec nici înainte de ea.

A doua mărime este rata de pachete, iar ea lovește adesea mai devreme decât lățimea de bandă. La pachete mici de 64 de octeți încap într-o conexiune de 1 Gbit/s circa 1,49 milioane de pachete pe secundă. Un kernel obișnuit de server prelucrează, în funcție de procesor și de placa de rețea, câteva sute de mii dintre ele înainte să înceapă să elimine. Un atac care nu vă umple conexiunea nici măcar la o treime poate deci să vă scoată totuși serverul RedM din funcțiune, deoarece timpul de calcul se duce pe eliminarea pachetelor. Operatorii trăiesc asta ca „încărcarea nici nu era mare, și totuși totul era pierdut”. Exact aceste vârfuri de lag fără încărcare vizibilă a serverului sunt imaginea tipică a unui atac pe rata de pachete.

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 asupra unui game server. Pentru asta nu există nicio setare locală. Atacurile volumetrice trebuie să se termine în rețeaua din fața serverului.

Ce este diferit la RedM față de FiveM

Răspunsul scurt: tehnica de rețea este identică, mediul nu. Amândouă rulează pe același FXServer, amândouă folosesc 30120 TCP și UDP, amândouă sunt administrate prin txAdmin pe 40120. Tot ce citiți mai sus despre porturi, rate și puncte finale se aplică pentru amândouă. Diferite sunt condițiile-cadru, și exact ele decid cât de repede acționează un atac:

Trei puncte din acest tabel sunt decisive pentru apărare. În primul rând, scena mai mică face fiecare server RedM în parte mai valoros ca țintă, deoarece o cădere afectează o parte mai mare din jucători. În al doilea rând, limita standard de 32 de sloturi coboară pragul de la care un flood de conectări închide serverul. Și în al treilea rând, pentru RedM se găsesc în rețea mai puține rețete de protecție gata făcute decât pentru FiveM, motiv pentru care multe proiecte rulează cu o configurație standard nemodificată. Apărarea este aceeași, starea de pornire este mai proastă.

Ce pune KernelHost împotrivă

Protecția permanentă, inclusă 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ă în centrul de date.
• Nivelul 2: filtrare Arbor în timp real cu 3,2 Tbps în Frankfurt pe Main. Direct în fața serverului, modelele specifice de protocol 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 RedM este pierdut. Și nu se folosește nullrouting: adresa dumneavoastră IP rămâne în rețea, eliminate sunt numai pachetele dăunătoare. Cine scoate adresa IP din rețea obține pentru dumneavoastră același rezultat ca atacatorul. Locul filtrării este Frankfurt pe Main. Ce jocuri și protocoale sunt acoperite le enumeră Protecție DDoS în timp real pentru game servere.

Advanced DDoS Protection pentru proiectele bombardate permanent

Unele proiecte nu sunt atacate ocazional, ci în mod țintit și săptămâni în șir. 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 proprie. De partea dumneavoastră nu este nevoie de nicio modificare.
• Reguli de protecție administrabile de dumneavoastră, pe port și pe protocol, în panoul clientului: stabiliți separat ce este permis pe 30120 UDP și ce pe 30120 TCP, fără să scrieți pentru asta un tichet. Mai ales la RedM această separare este utilă, deoarece traficul de joc și punctele finale HTTP se află pe același număr de port și au modele complet diferite.
• Modificările au efect în timp real, deci puteți ajusta chiar în timpul unui atac în desfășurare.
• Profil de protecție potrivit aplicației. Pentru serverele Cfx.re pe 30120 există un profil potrivit, la fel și pentru aplicațiile modificate și proprii pe orice porturi TCP sau UDP.

Amândouă se aplică serverelor care stau la KernelHost. Dacă proiectul dumneavoastră RedM rulează în prezent în altă parte și este scos regulat din rețea, recomandarea este mutarea, nu un produs suplimentar.

Cele două niveluri în comparație

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

Greșeli frecvente și soluții

„Serverul meu nu apare în lista de servere RedM, bănuiesc un atac”: Verificați mai întâi configurația. Dacă lipsește set gamename rdr3, FXServer se anunță ca server de GTA V și nu apare în lista RedM. Dacă cheia de licență de la portal.cfx.re lipsește sau nu este corectă, intrarea nu se realizează nici ea. Un atac arată altfel: intrarea rămâne, conexiunea eșuează.

„Sute de jucători primesc o eroare la conectare, asta arată ca un val”: De regulă este o problemă de versiune de joc. Dacă sv_enforceGameBuild nu se potrivește cu ce așteaptă resursele dumneavoastră, clientul raportează „server specified an invalid game enforcement”. Setați valoarea pe care o cere framework-ul dumneavoastră, de obicei 1436 sau 1491, și reporniți complet serverul.

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

„Regulile mele de iptables nu acționează”: Trei cauze sunt frecvente. Regulile stau în spatele lanțurilor UFW și nu sunt atinse niciodată, 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 pe 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 rulează, dar toți jucătorii au efecte de elastic”: Asta este mai des un script decât un atac. Uitați-vă mai întâi cu resmon 1 dacă o resursă înghite timpul de calcul și verificați resursele de inventar și de personaj ale framework-ului dumneavoastră. Dacă sar -n DEV 1 10 rămâne neremarcabil, nu a fost un atac DDoS.

„txAdmin arată sute de încercări de conexiune eșuate”: Acesta este un flood de conectări și lovește logica jocului, nu conexiunea. Împotriva lui acționează lista albă, verificarea contului prin sv_authMinTrust și limita superioară de conexiuni pe adresă sursă.

„Furnizorul meu de până acum 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ă 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 neobișnuit”: Dacă traficul este filtrat deja în rețeaua din față, 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ă, în anumite situații nu mai ajunge la dumneavoastră 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 oaspete.

Pe scurt

• Un server RedM are nevoie de exact două porturi deschise: 30120 TCP și 30120 UDP, setate prin endpoint_add_tcp și endpoint_add_udp. Un port de interogare propriu sau un port RCON propriu nu există.
• txAdmin pe 40120 TCP și baza de date pe 3306 TCP nu au ce căuta în rețeaua deschisă, ci pe adresa proprie, respectiv pe 127.0.0.1.
• sv_endpointPrivacy true scoate adresele IP ale jucătorilor din ieșirile publice, iar o stare a serverului stocată intermediar ia încărcare de pe /players.json, calea de atac documentată pe stratul 7 împotriva serverelor Cfx.re.
• Un server RedM are fără OneSync 32 de sloturi, cu OneSync 48 și cu Element Club până la 1.024. Cu cât numărul de sloturi este mai mic, cu atât mai ieftin este un flood de conectări, și cu atât mai importante sunt lista albă și verificarea contului.
• RedM și FiveM rulează pe același FXServer, deosebite numai prin set gamename rdr3. Apărarea în rețea este de aceea identică, mediul nu: circa 2.000 de servere RedM față de circa 39.000 de servere FiveM fac din fiecare proiect RedM în parte ținta mai valoroasă.
• Regulile locale de firewall se termină acolo unde conexiunea este plină: 1 Gbit/s sunt 125 de megaocteți pe secundă, iar la pachete de 64 de octeți încap acolo circa 1,49 milioane de pachete pe secundă. Tot ce depășește asta trebuie să se termine în rețeaua din fața serverului.
• La KernelHost, protecția permanentă pe două niveluri este cuprinsă în fiecare pachet de server, activă din momentul livrării și fără nullrouting. Cine vrea să conducă singur filtrarea primește cu Advanced DDoS Protection, de la 50,00 EUR pe lună, un IP de protecție dedicat și reguli proprii pe port și pe protocol.

Dacă proiectul dumneavoastră RedM rulează deja la KernelHost, filtrarea este activă fără să trebuiască să faceți ceva. 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 puteți contacta suplimentar prin chatul de urgență WhatsApp la +43 650 8209883.