Protejarea unui server Palworld împotriva atacurilor DDoS

Un server Palworld care seara, în mijlocul jocului, aruncă afară toți jucătorii în același timp, rămâne offline câteva minute și apoi redevine accesibil de la sine are rar o problemă de hardware. De regulă este vorba de un atac. Acest articol arată cum protejați un server Palworld împotriva atacurilor DDoS: mai întâi ceea ce puteți configura singur, fără costuri suplimentare, apoi punctul în care aceste măsuri se termină din motive tehnice și, la final, ce trebuie să se întâmple în rețeaua din fața serverului, pentru ca serverul să rămână accesibil.

Toate datele se referă la serverul dedicat oficial de la Pocketpair (Steam App ID 2394010) 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ță. Dacă atacul este în curs, se aplică o ordine clară: mai întâi măsurați, abia apoi modificați. O repornire forțată sub încărcare aruncă tot ce s-a întâmplat în lume după ultimul punct de salvare automat, iar valorile măsurate ale incidentului dispar și ele.

De ce serverele Palworld sunt scoase din funcțiune în mod țintit cu atacuri DDoS

Un server Palworld este un public mic și stabil la o adresă fixă. Serverul dedicat este limitat la 32 de jucători, valoare controlată prin ServerPlayerMaxNum, cu intervalul valid de la 1 la 32. Cine găzduiește în schimb din meniul jocului ajunge la patru jucători și doar atât timp cât gazda însăși este online. Din aceste 32 de locuri decurge tot restul: grupul joacă la ore fixe de seară, oamenii se cunosc între ei, iar o cădere la ora 20 nu afectează o fracțiune din jucători, ci pe toți.

Adresa serverului nu este în niciun caz un secret. Palworld nu cunoaște nicio intermediere printr-un serviciu al producătorului: jucătorii introduc adresa IP și portul în câmpul pentru conexiune directă, iar cine vrea să își treacă serverul și în lista de servere a comunității îl pornește cu -publiclobby și lasă portul de interogare să răspundă. Oricine a fost conectat o singură dată cunoaște astfel ținta. Un serviciu de booter care bombardează această adresă pentru câțiva euro pe lună nu cere celui care îl comandă nici pricepere, nici efort.

Din punct de vedere tehnic se adaugă faptul că tot traficul de joc circulă prin UDP. UDP nu cunoaște nicio deschidere de conexiune care ar putea fi pretinsă, iar adresa expeditorului unui pachet UDP poate fi falsificată. Un atacator nu trebuie deci nici să intre pe server, nici să i se adreseze corect pentru a genera încărcare. Ce se întâmplă tehnic într-un astfel de atac explică articolul Ce este un atac DDoS?.

Porturile despre care este vorba în realitate la un server Palworld

Un server Palworld are nevoie de exact un port deschis: 8211 UDP. Tot restul este opțional și, în funcție de sarcină, chiar dăunător atunci când stă pe internet. Din asta decurge o distincție utilă: un atac DDoS pe portul 8211 lovește întotdeauna traficul de joc în sine, în timp ce un atac pe portul 27015 UDP lovește doar intrarea din lista de servere.

Toate comutatoarele pentru asta se află într-un singur fișier: Pal/Saved/Config/LinuxServer/PalWorldSettings.ini, sub Windows corespunzător Pal\Saved\Config\WindowsServer\PalWorldSettings.ini. Fișierul începe cu linia de secțiune [/Script/Pal.PalGameWorldSettings], după care urmează o singură linie OptionSettings=(...), care conține toate setările ca listă. O întrerupere de linie în interiorul parantezei face întreaga configurație nevalidă, iar serverul revine fără niciun comentariu la valorile implicite. Șablonul DefaultPalWorldSettings.ini din directorul serverului nu îl modificați, deoarece este suprascris la fiecare actualizare.

Serverul Palworld în cifre

Valorile următoare sunt baza pentru orice decizie privind regulile de filtrare și valorile limită.

De ce portul de interogare 27015 este punctul cel mai sensibil

Portul de interogare răspunde cererilor de stare în formatul Steam A2S, adică exact interogarea pe care o servesc și serverele de Counter-Strike și de ARK. O cerere A2S_INFO este un pachet UDP fără conexiune, de câteva zeci de octeți, iar răspunsul cu numele serverului, lumea, numărul de jucători și stadiul jocului este un multiplu al acestei dimensiuni. Deoarece la UDP adresa expeditorului poate fi falsificată, un atacator poate adresa porturi de interogare străine și poate dirija răspunsurile mai mari către ținta sa reală. Serverul dumneavoastră nu este în acest caz victima, ci amplificatorul, iar conexiunea lui plătește nota.

Tocmai de aceea, Valve a completat A2S_INFO pe 8 decembrie 2020 cu o provocare prealabilă: serverul răspunde mai întâi cu S2C_CHALLENGE, cel care întreabă trebuie să trimită tokenul înapoi și dovedește astfel că nu își falsifică adresa expeditorului. Asta atenuează amplificarea, dar nu o încheie, iar împotriva unui simplu val de interogări identice venite din adrese reale nu are absolut niciun efect.

Pentru Palworld decurge din asta un avantaj important față de motorul Source: traficul de joc și interogarea serverului se află pe porturi separate. La Counter-Strike 2 amândouă împart portul 27015, iar o limitare grosieră a ratei aruncă acolo afară și jucătorii proprii. La Palworld puteți limita dur portul 27015 UDP sau îl puteți închide complet, fără să atingeți un singur trafic de joc în desfășurare pe 8211 UDP. Cine nu are nevoie de intrarea în listă șterge -publiclobby și portul de interogare fără înlocuitor și scoate astfel din rețea o suprafață de atac completă.

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

Pașii următori nu opresc niciun atac volumetric, asta nu o poate realiza niciun software de pe server. Ei curăță însă tot ce se află sub acest nivel: scanări de porturi, valuri de interogări, încercări de preluare prin porturile de administrare și ocuparea tuturor celor 32 de locuri de către străini. Aceasta este cea mai mare parte din ceea ce deranjează un server Palworld în viața de zi cu zi și costă o jumătate de oră.

1. Inventar: ce ascultă pe server?

Î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:8211 înseamnă „accesibil din întregul internet”, 127.0.0.1:8212 înseamnă „numai local” și nu are nevoie de nicio regulă de firewall. Pe lângă procesul jocului apar acolo, pe un server crescut cu timpul, adesea și un panou de administrare, un server web pentru afișarea hărții și o bază de date. Perspectiva atacatorului o oferă o scanare de porturi din exterior:

nmap -Pn -sU -p 8211,27015 ADRESA.IP.A.SERVERULUI
nmap -Pn -p- --min-rate 1000 ADRESA.IP.A.SERVERULUI

2. Deschideți numai ce are Palworld nevoie cu adevărat

Două permisiuni sunt suficiente, iar a doua este opțională. 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 8211/udp comment 'Palworld trafic de joc'
ufw allow 27015/udp comment 'Palworld interogare Steam'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Linia a treia o lăsați deoparte dacă serverul dumneavoastră nu trebuie să apară în lista de servere a comunității. Jucătorii dumneavoastră se conectează atunci în continuare prin adresa IP și portul 8211, serverul dispare doar din lista publică. Instrucțiunile complete, inclusiv calea de salvare, se află în Configurarea firewallului UFW fără să vă blocați singur accesul.

3. Scoateți RCON pe 25575 și REST API pe 8212 de pe internet

Ambele porturi sunt accesuri de administrare cu control complet asupra serverului, și ambele sunt dezactivate din fabrică: RCONEnabled=False și RESTAPIEnabled=False. Cine le activează ar trebui să știe ce publică astfel.

REST API pe 8212 TCP se autentifică prin HTTP Basic Auth cu numele de utilizator fix admin și valoarea din AdminPassword, și asta prin HTTP necriptat. Parola de administrare circulă astfel pe conexiune, la fiecare cerere în parte, în formă reversibilă. RCON pe 25575 TCP este un protocol text la fel de necriptat, iar Pocketpair l-a marcat ca învechit în favoarea REST API. Pentru instalările noi, REST API este alegerea corectă, iar pentru amândouă se aplică aceeași regulă: nu în rețeaua deschisă.

RESTAPIEnabled=True
RESTAPIPort=8212
AdminPassword="o valoare lungă și aleatorie"

Interfața o faceți accesibilă printr-o redirecționare de port prin SSH, după care lucrați local cu 127.0.0.1:8212:

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

Nu lăsați niciodată AdminPassword gol, pentru că gol este valoarea implicită. O valoare din openssl rand -base64 32 este suficientă. Același lucru se aplică și pentru ServerPassword, despre care vorbim imediat.

4. Limitați portul de interogare 27015 fără să pierdeți intrarea în listă

Pachetele Steam fără conexiune încep cu patru octeți setați (0xffffffff), traficul de joc obișnuit nu are acest cap. Pe asta se poate așeza o limitare de rată pe adresă sursă, care frânează interogările și păstrează intrarea în listă. Cu nftables, încărcat prin nft -f:

table inet palworld {
    chain input {
        type filter hook input priority -10; policy accept;
        udp dport 27015 @th,64,32 0xffffffff \
            meter a2sflood { ip saddr limit rate over 10/second burst 20 packets } drop
    }
}

Prioritatea -10 face ca regula să acționeze înaintea lanțului de filtrare al UFW, iar @th,64,32 citește primii patru octeți de după capul UDP. Cu iptables clasic, aceeași separare se obține prin potrivirea pe semnătura A2S_INFO:

iptables -A INPUT -p udp --dport 27015 \
  -m string --algo bm --hex-string "|ffffffff54536f7572636520456e67696e6520517565727900|" \
  -m hashlimit --hashlimit-name a2sflood --hashlimit-mode srcip \
  --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP

Zece interogări pe secundă și pe adresă sunt măsurate generos: un serviciu de listare întreabă de obicei la câteva minute, nu de mai multe ori pe secundă. Important este doar ca această regulă să stea pe 27015 și nu pe 8211, altfel loviți jucătorii proprii.

5. Limitați ratele de pachete pe 8211 UDP

Pe portul de joc în sine, o limită superioară pe adresă sursă ajută împotriva valurilor mici venite din puține surse. La Palworld această limită se poate seta relativ fără pericol, deoarece sunt conectați cel mult 32 de jucători în același timp și fiecare dintre ei ocupă exact o adresă sursă:

iptables -I INPUT -p udp --dport 8211 \
  -m hashlimit --hashlimit-name palworld_udp --hashlimit-mode srcip \
  --hashlimit-above 400/sec --hashlimit-burst 600 -j DROP

Cifra este o valoare de pornire, nu un adevăr absolut. Un server plin, cu 32 de jucători și multe baze, generează vizibil mai multe pachete decât o rundă în patru, 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, apoi puneți limita la dublul valorii de vârf măsurate.

Regulile pure de iptables dispar după o repornire. Sub Debian și Ubuntu le salvați astfel:

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

Sub UFW, astfel de reguli trebuie trecute suplimentar în /etc/ufw/before.rules, deoarece altfel dispar la următorul ufw reload. Dacă o regulă este atinsă efectiv se vede cu iptables -L INPUT -n -v: dacă contoarele de potriviri rămân la zero, regula nu acționează.

6. Parola serverului, lista de interdicții și cele 32 de locuri împotriva epuizării sloturilor

Epuizarea sloturilor este cel mai ieftin atac împotriva unui server Palworld și nu are nevoie de lățime de bandă. Un server dedicat are cel mult 32 de locuri, deci 32 de conexiuni simultane sunt suficiente pentru a bloca accesul întregii comunități. Un atac volumetric costă bani pe cel care îl comandă, 32 de sesiuni nu îl costă nimic. Asta face această cale mai atractivă pentru serverele mici decât orice val de pachete.

Palworld nu are o listă albă încorporată. Instrumentele de moderare sunt kick, interdicția și o parolă de server, și tocmai parola serverului este cea mai eficientă măsură singulară împotriva epuizării sloturilor:

ServerPassword="o valoare pe care o cunoaște doar grupul dumneavoastră"
ServerPlayerMaxNum=32
bShowPlayerList=True
BanListURL="https://api.palworldgame.com/api/banlist.txt"

ServerPassword este gol din fabrică, deci oricine are adresa IP și portul intră. BanListURL indică implicit lista întreținută de Pocketpair și poate fi redirecționat către un fișier text propriu, dacă doriți să țineți interdicții proprii ale proiectului. ServerPlayerMaxNum nu îl setați peste 32: valorile mai mari nu sunt susținute și se întorc împotriva dumneavoastră cel târziu la următoarea actualizare. Și un lucru trebuie să fie clar: o parolă de server vă protejează locurile, nu conexiunea. Un atacator care vă inundă serverul nu vrea deloc să intre.

7. Degrevați urmărirea conexiunilor și măriți bufferele

Acest punct explică întreruperi care arată ca un atac de volum, dar nu sunt. Kernelul creează pentru traficul UDP intrări în urmărirea conexiunilor (conntrack), iar la adrese de expeditor falsificate fiecare adresă înseamnă o intrare nouă. Dacă tabelul este plin, kernelul elimină pachete fără deosebire, atacul și jucătorii dumneavoastră zboară afară împreună, 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

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

table inet raw {
    chain prerouting {
        type filter hook prerouting priority raw; policy accept;
        udp dport { 8211, 27015 } notrack
    }
    chain output {
        type filter hook output priority raw; policy accept;
        udp sport { 8211, 27015 } notrack
    }
}

Cu iptables, echivalentul este iptables -t raw -A PREROUTING -p udp --dport 8211 -j NOTRACK și aceeași linie pentru OUTPUT cu --sport. Porturile au nevoie după aceea de o permisiune explicită, deoarece fără urmărire nu mai acționează nicio regulă care verifică o stare existentă. Dacă pachetele sosesc mai repede decât le preia procesul serverului, se umple suplimentar bufferul de recepție. Pentru jucători asta arată ca pierdere de pachete, deși conexiunea este liberă. Un fișier suplimentar sub /etc/sysctl.d/, activat cu sysctl -p:

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

Dacă valorile sunt necesare vă spune kernelul însuși: dacă UdpRcvbufErrors crește în nstat -az, atunci ele au efect. Dacă contorul rămâne la zero, ajustarea nu schimbă nimic.

8. Adunați valori de măsurare înainte să devină serios

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 sâmbătă seara. 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
dmesg -T | tail -50
tcpdump -ni eth0 -c 200 "udp port 8211 or udp port 27015"

La tcpdump se aplică o regulă: limitați întotdeauna cu -c, o captură sub încărcare maximă apasă suplimentar un server oricum suprasolicitat. Palworld oferă în plus o mărime de măsurare pe care nu o are niciun alt instrument. Dacă REST API este activat, punctul final pentru metrici returnează, printre altele, rata de cadre a serverului, numărul actual de jucători și timpul de funcționare:

curl -s -u admin:PAROLA_DVS_DE_ADMIN http://127.0.0.1:8212/v1/api/metrics

Această singură cifră separă curat cele două cauze cele mai frecvente. Dacă rata de cadre a serverului se prăbușește în timp ce ratele de pachete rămân neremarcabile, nu este un atac, ci încărcare sau creșterea cunoscută de memorie a procesului de server. Dacă rata de cadre rămâne stabilă în timp ce pachetele de intrare urcă mult peste valoarea normală, atunci este un atac. Cum evaluați în detaliu valorile de rețea se află în Recunoașterea unui atac DDoS pe server.

Unde se termină aceste măsuri: lățimea de bandă și rata de pachete

Acum partea pe care niciun fișier de 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 game server tipic atârnă de o conexiune de 1 Gbit/s, ceea ce corespunde cu 125 de megaocteți pe secundă, iar conexiunea este plină de îndată ce cineva trimite mai mult. Atacurile împotriva proiectelor de game server se situează de obicei între 5 și 50 Gbit/s, adică la de cinci până la cincizeci de ori conexiunea dumneavoastră. Cât de bună este regula dumneavoastră de iptables din spate 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 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”, iar la Palworld se manifestă mai întâi ca vârfuri de lag și abia apoi ca întrerupere a conexiunii.

La un server Palworld se adaugă un raport nefavorabil. Un server ocupat complet, cu 32 de jucători, folosește doar o fracțiune dintr-o conexiune de 1 Gbit/s. Atacul nu trebuie deci să fie mare pentru a atinge un multiplu al regimului normal, și exact de aceea sunt suficiente aici deja atacuri care pe o platformă mare nu ar atrage atenția.

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 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 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 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. Palworld face parte dintre jocurile cu profil de protecție propriu, iar ce alte titluri și protocoale sunt acoperite le enumeră Protecție DDoS în timp real pentru game servere.

Advanced DDoS Protection pentru proiectele Palworld 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, fără durată minimă și fără taxă de instalare. 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 8211 UDP și ce pe 27015 UDP, fără să scrieți pentru asta un tichet.
• Modificările au efect în timp real, deci puteți ajusta chiar în timpul unui atac în desfășurare, de exemplu limitând temporar mai dur portul de interogare și lăsând portul de joc neatins.
• Profil de protecție potrivit jocului, pentru Palworld la fel ca pentru aplicații proprii pe orice porturi TCP sau UDP.

Advanced DDoS Protection se adresează serverelor care stau la KernelHost. Cine își operează în prezent proiectul Palworld în altă parte și este atacat permanent îl mută pentru asta la KernelHost, iar atunci ambele niveluri acționează din momentul livrării.

Cele două niveluri în comparație

Pentru majoritatea serverelor Palworld, 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 la serverele Palworld și soluția lor

„Am blocat 27015 și acum serverul a dispărut din lista comunității”: Acesta este comportamentul așteptat, deoarece portul de interogare susține intrarea în listă. Nu îl blocați global, ci limitați pachetele fără conexiune pe adresă sursă, ca la pasul 4. Dacă oricum nu aveți nevoie de intrarea în listă, lăsați portul închis, ștergeți -publiclobby și dați jucătorilor dumneavoastră adresa IP și portul 8211 pentru conexiunea directă.

„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. La Palworld este aproape întotdeauna una din trei căi: un jucător care are oricum adresa trecută în câmpul pentru conexiune directă, un bot de Discord cu afișare de stare, care o publică din nou, sau o veche înregistrare A în DNS, care indică adresa anterioară. O schimbare de adresă este câștig de timp, nu o soluție.

„Serverul are vârfuri de lag, dar conexiunea este liniștită”: La Palworld asta este mai des încărcare decât atac. Procesul serverului ocupă, pe durata funcționării, tot mai multă memorie RAM, motiv pentru care o repornire planificată face parte din regimul normal și nu trebuie înțeleasă ca soluție de avarie. Verificați rata de cadre a serverului prin punctul final pentru metrici și consumul de memorie al procesului. Dacă sar -n DEV 1 10 rămâne neremarcabil, nu a fost un atac DDoS.

„Toate cele 32 de locuri sunt ocupate, dar în joc nu se vede nimeni”: Aceasta este epuizarea sloturilor și lovește logica jocului, nu conexiunea. Setați un ServerPassword, blocați conturile suspecte prin lista de interdicții și limitați pachetele pe adresă sursă pe 8211 UDP.

„REST API a fost accesibil deschis câteva zile”: Atunci parola dumneavoastră de administrare este compromisă, deoarece HTTP Basic Auth prin HTTP necriptat o transmite la fiecare cerere în formă reversibilă. Schimbați AdminPassword, închideți 8212 TCP către exterior și ajungeți la interfață numai printr-o redirecționare de port prin SSH.

„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.

„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 Palworld are nevoie de exact un port deschis: 8211 UDP. Portul de interogare 27015 UDP este necesar numai pentru intrarea în lista de servere a comunității.
• RCON pe 25575 TCP și REST API pe 8212 TCP nu au ce căuta niciodată în rețeaua deschisă, deoarece ambele transmit datele de acces necriptat. RCON este marcat suplimentar de Pocketpair ca învechit.
• Deoarece la Palworld traficul de joc și interogarea serverului se află pe porturi separate, 27015 UDP poate fi limitat dur fără să atingeți traficul de joc în desfășurare pe 8211 UDP.
• Serverul dedicat este limitat la 32 de locuri, de aceea epuizarea sloturilor este cel mai ieftin atac. O ServerPassword setată este împotriva ei cea mai eficientă măsură singulară, deoarece Palworld nu are o listă albă încorporată.
• Măsurile locale se termină la conexiune: 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 inclusă în fiecare pachet de server fără cost suplimentar și este activă din momentul livrării, fără nullrouting. Advanced DDoS Protection, cu IP de protecție dedicat și reguli administrabile de dumneavoastră pe port, începe de la 50,00 EUR pe lună.

Dacă serverul dumneavoastră Palworld 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.