Skydda MTA:SA-servern mot DDoS-attacker

En server för Multi Theft Auto: San Andreas beter sig under en DDoS-attack annorlunda än varje annat GTA-flerspelarprojekt, eftersom den erbjuder tre separata nätverkstjänster samtidigt: speltrafiken på 22003 UDP, en fullvärdig HTTP-server på 22005 TCP och ASE-förfrågan på 22126 UDP. Var och en av dessa tre tjänster går att attackera för sig, och var och en faller på sitt eget sätt. Den här artikeln visar först vad du själv kan säkra utan extra kostnad, därefter var dessa åtgärder tar slut vid ledningens fysik, och till sist vad ett verkningsfullt DDoS-skydd för MTA:SA måste klara i nätet framför servern.

Pågår attacken just nu är den viktigaste frågan vilken av de tre tjänsterna som träffas. Förblir spelare anslutna men laddar inga resurser längre vid anslutning, träffas HTTP-servern på 22005. Försvinner servern ur serverlistan medan de anslutna spelarna spelar vidare som vanligt, träffas ASE-förfrågan på 22126. Bryts alla anslutningar samtidigt är antingen 22003 målet eller så är ledningen full. Alla uppgifter gäller en MTA-server under Debian 12, Debian 13, Ubuntu 22.04 LTS eller Ubuntu 24.04 LTS, kommandona är skrivna för root, som vanlig användare sätter du sudo framför.

Varför MTA:SA-servrar så ofta blir mål för DDoS-attacker

MTA:SA-projekt är bekväma mål, eftersom de själva måste publicera sin adress. En server syns bara i serverlistan om den anmäler sig till masterserverlistan och därefter besvarar förfrågningar utifrån. Listan innehåller IP-adress och port i klartext, någon förberedande spaning är alltså överflödig för en angripare.

Till det kommer scenen själv. Tyskspråkiga och brasilianska rollspelsservrar, servrar för drifting och DayZ-varianter konkurrerar om samma spelarkrets, och ett avbrott under bästa speltid är maximalt synligt. En bannad spelare, ett osams team eller ett konkurrerande projekt behöver varken kunnande eller nämnvärda pengar för att göra en kväll oanvändbar. Bokningsbara attacktjänster, i scenen kallade booter eller stresser, säljer för några euro i månaden exakt två resultat: att ta MTA-servern offline i några minuter eller att göra den ospelbar med laggtoppar. Vad en DDoS-attack är rent tekniskt och vilka attacktyper som finns förklarar artikeln Vad är en DDoS-attack?.

Tekniskt gör MTA:SA det enklare för angripare på två ställen än andra flerspelarmodifikationer. För det första ligger förfrågan på en egen UDP-port som på ett enda byte skickar tillbaka ett svar på flera kilobyte. För det andra hör till varje MTA-server en HTTP-server som levererar de klientsidiga filerna för alla resurser, och det utan inloggning till alla som frågar efter dem.

Portarna som det faktiskt handlar om

En MTA:SA-server behöver exakt tre portar: 22003 UDP för spelet, 22005 TCP för den interna HTTP-servern och 22126 UDP för ASE-förfrågan. Den tredje porten är ingen fritt valbar inställning, utan följer fast av spelporten plus 123. Den som sätter serverport till 22010 får förfrågan på 22133.

Två finesser står så i den medföljande mtaserver.conf och förbises regelbundet. httpport får ha samma talvärde som serverport, eftersom den ena porten är TCP och den andra UDP. Och serverip står på auto och ska stanna där: ett fast inskrivet värde binder ASE-socketen till exakt den adressen och bryter posten i listan så snart adressen ändras.

ASE-förfrågningsprotokollet och varför det är en förstärkare

ASE (All-Seeing Eye) är ett rent UDP-baserat förfrågningsprotokoll: paketets första byte bestämmer svaret, någon uppkoppling finns inte. MTA-servern känner till fem förfrågningar och besvarar dem på 22126:

• s är den fullständiga ASE-förfrågan. Svaret börjar med EYE1 och innehåller servernamn, speltyp, kartnamn, version, lösenordsstatus, spelarantal, den fullständiga listan över alla regler satta via setRuleValue och därefter varje ansluten spelare med namn, poäng och ping. Det här svaret har ingen storleksbegränsning.
• b och r är de smalare förfrågningarna för serverlistan i spelet. Svaret börjar med EYE2 och kapas i källkoden vid 1 340 byte för att undvika fragmentering.
• x levererar ett förkortat statusmeddelande, v bara ASE-versionsbeteckningen.

Därav följer problemet. En förfrågan består av en enda nyttolastbyte, på tråden alltså av 29 byte (20 byte IP-huvud, 8 byte UDP-huvud, 1 byte nyttolast). Ett svar på 1 400 byte nyttolast är på tråden 1 428 byte. Förhållandet är cirka 49 gånger, och eftersom UDP inte känner till någon uppkoppling går avsändaradressen att förfalska. En angripare kan alltså använda din server som förstärkare mot ett tredje mål utan att någonsin gå in i ditt spel. Vid den fullständiga förfrågan växer faktorn med spelarantalet och med varje regel som din gamemode sätter.

MTA har däremot två inbyggda bromsar som man bör känna till, eftersom de förklarar varför vissa floder verkar och andra inte. Servern besvarar högst fem förfrågningar per källadress på sex sekunder och ignorerar adressen därefter i sju sekunder. Dessutom håller den svaren cachade i tio sekunder i stället för att bygga ihop dem på nytt för varje förfrågan. Räkningen per källadress hoppas dock över helt så snart fler än 100 olika avsändaradresser står i listan samtidigt. Precis det är normalfallet vid en distribuerad flod från ett botnät eller med förfalskade avsändare, och därför hjälper den inbyggda bromsen inte mot en allvarlig attack.

Vad du själv kan göra innan du lägger ut pengar

Det här avsnittet är det längsta, och det med avsikt. En rent konfigurerad MTA-server klarar små och medelstora attacker av egen kraft, oavsett var den står.

1. Inventering: vad lyssnar överhuvudtaget?

Se först efter vad din server erbjuder utåt. Inte gissa, titta efter:

ss -lntup

Väntat är tre rader från MTA-processen: 0.0.0.0:22003 på UDP, 0.0.0.0:22005 på TCP och 0.0.0.0:22126 på UDP. Dyker där dessutom upp en databas på 0.0.0.0:3306, en webbserver eller en bortglömd rösttjänst, hör det stängas av. Angriparens vy ger en portskanning utifrån:

nmap -Pn -sU -p 22003,22126 DIN.SERVER.IP.ADRESS
nmap -Pn -p 22005 DIN.SERVER.IP.ADRESS

Servern har också ett eget konsolkommando för detta. I serverkonsolen kontrollerar openports om alla tre portarna är nåbara utifrån.

2. Håll bara de tre portar öppna som MTA verkligen behöver

Med UFW ser en hållbar utgångskonfiguration ut så här, och i exakt den här ordningen, så att du inte låser ute dig själv:

ufw allow 22/tcp comment 'SSH'
ufw allow 22003/udp comment 'MTA spel'
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

Den fullständiga anvisningen inklusive räddningsvägen står i artikeln Sätt upp UFW-brandväggen. På KVM-rootservrar och dedikerade servrar från KernelHost kommer du i nödfall in i systemet via VNC-konsolen i kundportalen, även när ledningen är mättad.

Databasen hör inte hemma på det öppna nätet. Visar ss -lntp | grep 3306 ett 0.0.0.0:3306, sätter du i /etc/mysql/mariadb.conf.d/50-server.cnf raden bind-address = 127.0.0.1 och startar om tjänsten.

3. Begränsa ASE-porten utan att åka ur serverlistan

Till skillnad från SA-MP ligger förfrågan hos MTA:SA på en egen port, du kan alltså begränsa den oberoende av spelet. Det är den här arkitekturens största praktiska fördel: en regel på 22126 kastar inte ut en enda spelare.

Med nftables i en egen tabell, så att regelsatsen inte kommer i vägen för 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

Den första regeln begränsar varje enskild källadress, den andra hela porten. Båda tillsammans är viktiga: en distribuerad flod löper genom luckan mellan många enskilda källor om bara varje adress begränsas. Värdena är snävt valda, och det är försvarbart här eftersom en riktig serverlista bara frågar din server med några sekunders mellanrum. Med iptables uppnår hashlimit-modulen detsamma:

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

Försöket att stänga porten helt är en avvägning och inget hemligt tips: utan ASE försvinner din server ur serverlistan i spelet och därmed ur det organiska tillflödet. Vill du det ändå räcker inte <ase>0</ase>. I källkoden hänger portöppningen på en eller-koppling mellan internetläge och LAN-läge, socketen förblir vid <ase>0</ase> alltså fortsatt öppen så länge <donotbroadcastlan>0</donotbroadcastlan> står kvar. Den som verkligen vill stänga porten sätter båda:

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

Den ärligare vägen för ett växande projekt är: låt porten vara öppen, begränsa hastigheten, och håll förstärkningseffekten liten genom att din gamemode inte publicerar onödiga regler via setRuleValue. Varje regel står i den fullständiga förfrågan och förstorar svaret.

4. Avlasta den interna HTTP-servern

HTTP-servern på 22005 är hos MTA:SA en egen angreppsyta, eftersom varje anslutande spelare där laddar ner samtliga klientsidiga filer för alla igångvarande resurser. Hos ett rollspelsprojekt med egna modeller är det snabbt flera hundra megabyte, fördelat på hundratals enskilda filer. Den inbyggda servern är medvetet enkelt hållen: ingen komprimering, ett fast antal trådar. Ett par dussin samtidiga hämtningar räcker för att riktiga spelare ska hänga i laddningsskärmen i flera minuter.

Den mest verkningsfulla åtgärden är att ta bort nedladdningarna helt från spelservern. MTA lägger själv fram de filer som ska levereras, under mods/deathmatch/resource-cache/http-client-files. Den mappen publicerar du via nginx eller lighttpd och skriver in adressen i mtaserver.conf:

<httpdownloadurl>http://cdn.din-webbplats.tld/mta</httpdownloadurl>

Det ger två saker på en gång. Nedladdningarna går via en webbserver som är byggd för det, och de går inte längre via din spelservers adress. Ligger webbservern på en annan maskin eller bakom ett Content Delivery Network träffar en flod mot nedladdningarna inte längre spelet. Viktigt: är den externa adressen fel eller inte nåbar växlar MTA tyst tillbaka till den interna servern.

Förblir den interna servern i bruk: använd dess egna gränser. I mtaserver.conf:

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

httpmaxconnectionsperclient begränsar de samtidiga anslutningarna per klient till 5 inom det tillåtna intervallet 1 till 8. httpdosthreshold begränsar hur många anslutningar en enskild IP-adress får bygga upp på kort tid, förval 20. http_dos_exclude undantar enskilda adresser från detta, till exempel din egen statussida. httpthreadcount bestämmer antalet trådar, förval 8 inom intervallet 1 till 20. Ett högre värde hjälper vid många små filer, men kostar beräkningstid som spelet saknar.

Tänk dessutom på vad som levereras på samma port. Resurserna webadmin och resourcebrowser är startade i den medföljande konfigurationen och nåbara i webbläsaren via 22005. Ett administrationsgränssnitt hör inte oskyddat hemma på det öppna nätet: ge rena rättigheter i acl.xml, sätt upp ett eget konto med långt slumpmässigt lösenord, och stoppa resursen när du inte behöver den.

5. Använd de inbyggda gränserna i mtaserver.conf

MTA har med sig fler skyddsgränser än de flesta projekt använder. Några står fast i källkoden, andra i mtaserver.conf. Den här tabellen sammanfattar dem som spelar roll vid en attack:

Tre inställningar förtjänar ett medvetet beslut. maxplayers står på 32 och bör motsvara verkligheten: varje ytterligare plats förstorar den fullständiga förfrågan och ökar antalet anslutningar som en angripare kan lägga beslag på. bandwidth_reduction står på medium, värdet maximum sänker den utgående lasten märkbart men kostar synkroniseringsnoggrannhet. Och <password></password> gör din server utan besvär till en sluten krets medan posten i listan finns kvar: den snabbaste nödbromsen vid en pågående anslutningsflod.

6. Håll isär anslutningsfloder och händelsefloder

Två attackmönster siktar inte på ledningen, utan på spellogiken, och de förväxlas regelbundet.

En anslutningsflod bygger i snabb följd upp riktiga anslutningar tills alla platser är upptagna eller servern inte hinner med uppbyggnaden längre. MTA begränsar det av sig självt till fyra anslutningar per källadress på 30 sekunder och ignorerar adressen därefter i 30 sekunder. Vad bromsen just gör visar konsolkommandot debugjoinflood. Gränsen verkar per adress, ett botnät med tusen adresser löper förbi den. Mot det hjälper ett serverlösenord, en vitlista i gamemode och en hastighetsbegränsning på 22003.

En händelseflod kommer däremot från redan anslutna spelare: en manipulerad klient skickar triggerServerEvent i en slinga tills servern inte längre orkar med beräkningstiden. MTA tillåter för det från fabrik 100 händelser per spelare och sekund och slår därutöver larm med ett meddelande om händelsefloder. Om din gamemode använder många små händelser: kontrollera värdet innan du sänker det, för snävt satt kastar det ut dina egna spelare.

Oberoende av det gäller serversidigt samma regel som överallt: lita aldrig på värden som klienten skickar med, härled spelaren ur händelsens avsändare, och begränsa allt som utlöser en databasfråga. En enda okontrollerad händelse som startar en fråga räcker för att få en server att stanna helt utan nätverksattack.

7. Serverlistan, IP-adressen och vad den annars avslöjar

Din IP-adress går inte att hålla hemlig. Varje spelare som en gång varit ansluten känner till den, och posten i masterserverlistan publicerar den ändå. En domän framför hjälper inte: klienten slår upp namnet en gång och talar därefter direkt med adressen.

Kontrollera i stället vad din adress annars avslöjar. Typiska läckor hos MTA-projekt är gamla A- och AAAA-poster i DNS, projektsidan på samma maskin, en Discord-bot med statusvisning som offentligt läser ut ASE-förfrågan, TLS-certifikat med gamla värdnamn och foruminlägg från starttiden. Av det följer en regel som många projekt lär sig för sent: när du flyttar till en skyddad adress byter du samtidigt ut den gamla adressen. Blir den kvar står den i varje skannerdatabas, och attacken löper förbi skyddet.

Två poster i mtaserver.conf berör synligheten direkt. <serverip>auto</serverip> förblir på auto, om du inte vet exakt varför inte. Och <owner_email_address> hör att fyllas i: saknas posten eller är den fel kan det försämra synligheten i masterserverlistan.

8. Logga, så att du har data i skarpt läge

Det viktigaste steget är det som nästan ingen tar i förväg: att lägga upp en jämförelsegrund medan allt går normalt. Utan ett normalvärde kan du efter en incident inte säga om 40 000 paket per sekund var mycket eller helt enkelt fredagskväll. Med apt-get install -y vnstat sysstat löper mätningen varaktigt med.

Under en incident skiljer du först de tre portarna från varandra. De här fyra kommandona räcker:

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

Tolkningen är enklare än den ser ut. Stiger buffertfelen vid låg CPU-last når dig mer trafik än processen hinner arbeta av. Går en kärna för fullt medan trafiken ser normal ut ligger problemet i din gamemode och inte i nätet. Visar inspelningen på 22126 många paket med en enda byte nyttolast är det en ASE-flod. Står antalet öppna anslutningar på 22005 varaktigt i fyrsiffriga tal träffas HTTP-servern. För tcpdump gäller alltid: begränsa med -c, en inspelning under full last belastar en redan överbelastad server ytterligare. Hur du tolkar värdena i detalj beskriver artikeln Känn igen en DDoS-attack på servern.

Serverloggen själv ligger under logs/server.log, skriptloggen under logs/scripts.log. Båda sökvägarna står i mtaserver.conf och går att flytta.

Var dessa åtgärder tar slut

Nu den del som ingen konfigurationsfil kan lösa. Alla åtgärder hittills körs på din server, alltså i änden av ledningen. En brandväggsregel avgör om ett paket som redan har färdats genom kabeln. Du kan förkasta det, men inte göra det osänt.

Räkna med en gång. En typisk spelserver hänger på 1 Gbit/s, det motsvarar 125 megabyte per sekund, och vid 64 byte stora paket cirka 1,49 miljoner paket per sekund. Attacker mot spelserverprojekt av den här storleksordningen ligger vanligtvis mellan 5 och 50 Gbit/s, alltså på fem till femtio gånger din ledning. Om din nftables-regel bakom den är bra spelar då ingen roll längre, för dina spelares paket kommer redan innan dess inte fram.

Paketfrekvensen slår därvid ofta till tidigare än bandbredden. En vanlig serverkärna bearbetar beroende på CPU och nätverkskort några hundratusen paket per sekund innan den börjar förkasta. En attack som inte ens fyller en tredjedel av din ledning kan alltså lamslå din server, eftersom beräkningstiden går åt till att förkasta. Operatörer upplever det som "belastningen var ju inte ens hög, ändå var allt borta".

Hos MTA:SA tillkommer en tredje gräns, och den slår till tidigast. Servern läser nätverksportarna i ett enda arbetsflöde. En förfrågningsflod på 22126 upptar det flödet så att synkroniseringspaketen från riktiga spelare förfaller i mottagningsbufferten, långt innan ledningen är full. Processen kraschar inte, den blir bara långsam, och spelarna ser gummibandseffekter. Detsamma gäller HTTP-servern: den delar beräkningstid med spelet.

För att sätta storleksordningarna i perspektiv, sådant som verkligen förekommer: på KernelHost-servrar har bland annat en attack med över 473,4 Gbit/s vid över 41,5 miljoner paket per sekund mot en röstserver och en UDP-flod med över 112,2 Gbit/s vid över 8,7 miljoner paket per sekund mot en spelserver filtrerats bort. Det första fallet är cirka 473 gånger bandbredden och ungefär 28 gånger den paketfrekvens som en ledning med 1 Gbit/s överhuvudtaget kan ta emot. För det finns ingen lokal inställning. Volymetriska attacker måste sluta i nätet framför servern.

Vad KernelHost ställer mot detta

Det permanenta skyddet som ingår på varje server

Varje server hos KernelHost står bakom en permanent aktiv filtrering i två steg:

• Steg 1: 17 Tbps mitigeringskapacitet i det globala scrubbing-nätverket. Volymetriska attacker rensas nära sin källa, innan de överhuvudtaget når datacentret i Frankfurt am Main.
• Steg 2: Arbor-realtidsfiltrering med 3,2 Tbps direkt på plats i Frankfurt am Main. Omedelbart framför servern känns protokollspecifika mönster igen och förkastas paket för paket.

Tre egenskaper är avgörande. Skyddet är permanent aktivt, det finns alltså ingen upptäcktsfas där din server går ner. Ingen nullrouting används: den angripna adressen förblir i nätet, förkastade blir bara de skadliga paketen, medan de riktiga spelarnas anslutningar löper vidare. Och det kostar inget extra, utan ingår från leverans i varje serverpaket, från KVM-rootservern över spelservern till den dedikerade servern. Filtrering sker på lager 3, 4 och 7 på varje TCP- eller UDP-port, alltså på 22003 UDP, 22005 TCP och 22126 UDP samtidigt. Driften sker i datacentret maincubes i Frankfurt am Main, Tyskland. Vilka spel och protokoll som har egna profiler visar artikeln DDoS-skydd för spelservrar i realtid.

Advanced DDoS Protection för varaktigt beskjutna projekt

Vissa projekt träffas inte tillfälligt, utan riktat över flera veckor. För det fallet finns Advanced DDoS Protection från 50,00 € i månaden, PrePaid och utan bindningstid. Skillnaden ligger inte i mer kapacitet, utan i kontrollen:

• En dedikerad skydds-IP ur Frankfurt-kärnan. Din server ställs om till den inom KernelHosts nät, du bygger inte om något på din sida.
• Egenadministrerade skyddsregler per port och protokoll i kundportalen. Precis det är poängen hos MTA:SA: du ställer in separata regler för 22003 UDP, 22005 TCP och 22126 UDP i stället för att dra tre mycket olika tjänster över en kam.
• Ändringar slår igenom i realtid, utan ärende och utan väntetid. Du kan alltså justera efterhand mitt under en pågående attack.
• En skyddsprofil som passar spelet. Multi Theft Auto finns som egen profil, likaså webbservrar, röstservrar och egna TCP- eller UDP-applikationer som får plats bakom samma skyddsadress.

De två stegen i jämförelse

För de flesta MTA:SA-projekt räcker det inkluderade permanenta skyddet tillsammans med en ren serverkonfiguration. Advanced DDoS Protection är svaret på att någon tar det personligt.

Vanliga fel och lösningar

"Jag spärrade 22126, servern står ändå inte i någon lista, men det kommer fortfarande in förfrågningar": Då är socketen fortfarande öppen. <ase>0</ase> ensamt stänger inte porten så länge <donotbroadcastlan>0</donotbroadcastlan> är satt. Kontrollera med ss -lnup | grep 22126 om det verkligen inte lyssnar något längre.

"Spelare hänger i laddningsskärmen, spelet självt går normalt": Det är ingen attack mot 22003, utan HTTP-servern på 22005 vid sin gräns. Lägg ut nedladdningarna via httpdownloadurl och kontrollera httpmaxconnectionsperclient och httpthreadcount.

"Servern har försvunnit ur listan, spelarna på den märker ingenting": Då träffas uteslutande 22126. För de anslutna spelarna är det utan följder, för tillflödet av nya spelare inte. En hastighetsbegränsning på just den porten är rätt svar, inte en på spelporten.

"Vi bytte IP-adress och var offline igen två timmar senare": Angriparen har den nya adressen från samma källa som den gamla, oftast posten i listan, en Discord-bot med statusförfrågan eller en gammal DNS-post. Ett adressbyte är tidsvinst, ingen lösning.

"Vi satte en hastighetsgräns på 20 paket per sekund och adress på 22003": Det är för snävt. Redan en enskild spelare ligger över det vid aktiv synkronisering, och flera spelare bakom samma NAT-adress delar på samma kvot. Du kastar därmed ut dina egna spelare. På 22126 är snäva värden däremot oproblematiska.

"Vi har låst ute oss själva med brandväggen": En omstart hjälper inte, eftersom UFW återställer sina regler vid uppstart. Hos KernelHost öppnar du VNC-konsolen i kundportalen och kör ufw disable där. VNC-konsolen arbetar oberoende av gästsystemets nätverk.

"Min tidigare leverantör har spärrat min IP-adress": Det är nullrouting. Leverantören skyddar därmed sitt eget nät, för dig är resultatet identiskt med en lyckad attack, oftast i timmar därefter. Fråga vid tveksamhet om det filtreras eller nullroutas. Svaret avgör mer om din tillgänglighet än varje hårdvaruuppgift.

"Vi väntar helt enkelt ut attacken": Attacker som verkar blir upprepade. Dokumentera tidpunkt med tidszon, varaktighet, toppvärden och den drabbade porten. Precis de uppgifterna behöver också ett supportärende för att filtreringen ska dras efter riktat.

Kort sammanfattat

• En MTA:SA-server behöver exakt tre portar: 22003 UDP för spelet, 22005 TCP för den interna HTTP-servern och 22126 UDP för ASE-förfrågan. Den tredje följer fast av spelporten plus 123.
• ASE-förfrågan ligger på en egen port och går därför att begränsa utan att låsa ute en enda spelare. Det är den viktigaste skillnaden mot SA-MP, där spel och förfrågan delar på samma port.
• En enda förfrågningsbyte på 22126 skapar ett svar på upp till flera kilobyte, och avsändaradressen går att förfalska. En obromsad ASE-port är därmed mål och förstärkare på samma gång.
• MTA:s inbyggda bromsar verkar per källadress: fem förfrågningar på sex sekunder, fyra anslutningar på 30 sekunder. Vid fler än 100 samtidiga källadresser hoppas räkningen av förfrågningar över, en distribuerad flod löper alltså igenom.
• Den interna HTTP-servern på 22005 är en egen angreppsyta. Den som lägger ut nedladdningarna via httpdownloadurl på en extern webbserver tar bort dem från spelet.
• Allt som körs på servern avgör bara små attacker. Vid 1 Gbit/s är det slut vid cirka 1,49 miljoner paket per sekund, oberoende av kvaliteten på dina regler.
• Det permanenta skyddet i två steg hos KernelHost ingår i varje serverpaket utan pristillägg och arbetar utan nullrouting. Den som vill styra reglerna per port själv tar till Advanced DDoS Protection från 50,00 € i månaden.

Kör ditt projekt redan hos KernelHost är filtreringen permanent aktiv, du behöver inte slå på något. Märker du ändå avvikelser: öppna ett supportärende med tidsrymd, port och observerat beteende, så att reglerna för din adress justeras efterhand. Vid en pågående attack når du oss dessutom via WhatsApp-nödchatten på +43 650 8209883. Hostar du fortfarande någon annanstans och träffas regelbundet, är flytten till Frankfurt am Main den kortare lösningen: fler steg för det akuta läget står i artikeln Svår DDoS-attack: vad gör man?.