MTA:SA-server beschermen tegen DDoS-aanvallen

Een server voor Multi Theft Auto: San Andreas gedraagt zich onder een DDoS-aanval anders dan elk ander GTA-multiplayerproject, omdat hij drie gescheiden netwerkdiensten tegelijk aanbiedt: het spelverkeer op 22003 UDP, een volwaardige HTTP-server op 22005 TCP en de ASE-opvraging op 22126 UDP. Elk van die drie diensten valt afzonderlijk aan te vallen, en elk valt anders uit. Dit artikel laat eerst zien wat u zonder extra kosten zelf kunt afschermen, daarna waar die maatregelen op de fysica van de lijn stuklopen, en tot slot wat een werkzame DDoS-bescherming voor MTA:SA in het netwerk vóór de server moet leveren.

Loopt de aanval op dit moment, dan is de belangrijkste vraag welke van de drie diensten wordt geraakt. Blijven spelers verbonden maar laden zij bij het toetreden geen resources meer, dan treft het de HTTP-server op 22005. Verdwijnt de server uit de browser terwijl de verbonden spelers normaal doorspelen, dan treft het de ASE-opvraging op 22126. Breken alle verbindingen tegelijk af, dan is ofwel 22003 het doelwit, ofwel de lijn zit vol. Alle gegevens hebben betrekking op een MTA-server onder Debian 12, Debian 13, Ubuntu 22.04 LTS of Ubuntu 24.04 LTS; de commando's zijn voor root geschreven, als gewone gebruiker zet u er sudo voor.

Waarom MTA:SA-servers zo vaak doelwit van DDoS-aanvallen worden

MTA:SA-projecten zijn gemakkelijke doelwitten, omdat zij hun adres zelf moeten publiceren. Een server verschijnt alleen in de spelbrowser wanneer hij zich bij de masterserverlijst aanmeldt en daarna opvragingen van buitenaf beantwoordt. Die lijst bevat het IP-adres en de poort leesbaar, verkenning vooraf is voor een aanvaller dus overbodig.

Daar komt de scene zelf bij. Duitstalige en Braziliaanse roleplayservers, driftservers en DayZ-omzettingen dingen naar dezelfde spelers, en een uitval op de drukste speeltijd is maximaal zichtbaar. Een verbannen speler, een ruziënd team of een concurrerend project heeft kunde noch noemenswaardig geld nodig om een avond onbruikbaar te maken. Boekbare aanvalsdiensten, in de scene booters of stressers genoemd, verkopen voor een paar euro per maand precies twee resultaten: de MTA-server minutenlang offline halen of hem met lagpieken onspeelbaar maken. Wat een DDoS-aanval technisch is en welke aanvalssoorten er zijn, legt het artikel Wat is een DDoS-aanval? uit.

Technisch maakt MTA:SA het aanvallers op twee punten gemakkelijker dan andere multiplayermodificaties. Ten eerste ligt de opvraging op een eigen UDP-poort, die op één enkele byte een antwoord van meerdere kilobytes terugstuurt. Ten tweede hoort bij elke MTA-server een HTTP-server die de clientzijdige bestanden van alle resources uitlevert, en wel zonder aanmelding aan iedereen die erom vraagt.

De poorten waar het werkelijk om gaat

Een MTA:SA-server heeft precies drie poorten nodig: 22003 UDP voor het spel, 22005 TCP voor de interne HTTP-server en 22126 UDP voor de ASE-opvraging. De derde poort is geen vrij te kiezen instelling, maar volgt vast uit de spelpoort plus 123. Wie serverport op 22010 zet, krijgt de opvraging op 22133.

Twee finesses staan zo in de meegeleverde mtaserver.conf en worden regelmatig over het hoofd gezien. httpport mag dezelfde getalswaarde hebben als serverport, omdat de ene poort TCP is en de andere UDP. En serverip staat op auto en hoort daar te blijven: een vast ingevulde waarde bindt de ASE-socket aan precies dat adres en breekt de vermelding in de lijst zodra het adres verandert.

Het ASE-opvraagprotocol en waarom het een versterker is

ASE (All-Seeing Eye) is een zuiver UDP-opvraagprotocol: de eerste byte van het pakket bepaalt het antwoord, een verbindingsopbouw bestaat niet. De MTA-server kent vijf opvragingen en beantwoordt ze op 22126:

• s is de volledige ASE-opvraging. Het antwoord begint met EYE1 en bevat servernaam, speltype, mapnaam, versie, wachtwoordstatus, spelersaantal, de volledige lijst van alle via setRuleValue gezette regels en daarna elke verbonden speler met naam, score en ping. Dat antwoord kent geen groottebegrenzing.
• b en r zijn de slankere opvragingen voor de spelbrowser. Het antwoord begint met EYE2 en wordt in de broncode bij 1.340 byte afgekapt om fragmentatie te vermijden.
• x levert een verkorte statusmelding, v alleen de ASE-versieaanduiding.

Daaruit volgt het probleem. Een verzoek bestaat uit één enkele byte payload, op de lijn dus uit 29 byte (20 byte IP-header, 8 byte UDP-header, 1 byte payload). Een antwoord van 1.400 byte payload is op de lijn 1.428 byte. De verhouding bedraagt ongeveer het 49-voudige, en omdat UDP geen verbindingsopbouw kent, laat het afzenderadres zich vervalsen. Een aanvaller kan uw server dus als versterker tegen een derde doelwit gebruiken, zonder ooit uw spel te betreden. Bij de volledige opvraging groeit die factor mee met het spelersaantal en met elke regel die uw gamemode zet.

MTA brengt daartegen twee ingebouwde remmen mee die u moet kennen, omdat zij verklaren waarom sommige vloeden werken en andere niet. De server beantwoordt per bronadres hoogstens vijf opvragingen in zes seconden en negeert het adres daarna zeven seconden lang. Bovendien houdt hij de antwoorden tien seconden in de cache in plaats van ze per verzoek opnieuw samen te stellen. De telling per bronadres wordt echter volledig overgeslagen zodra er meer dan 100 verschillende afzenderadressen tegelijk in de lijst staan. Precies dat is bij een verdeelde vloed uit een botnet of met vervalste afzenders het normale geval, en daarom helpt de ingebouwde rem niet tegen een serieuze aanval.

Wat u zelf kunt doen voordat u geld uitgeeft

Dit hoofdstuk is het langste, en dat met opzet. Een netjes geconfigureerde MTA-server houdt kleine en middelgrote aanvallen op eigen kracht uit, ongeacht bij wie hij staat.

1. Inventarisatie: wat luistert er eigenlijk?

Kijk eerst na wat uw server naar buiten aanbiedt. Niet gokken, maar kijken:

ss -lntup

Te verwachten zijn drie regels van het MTA-proces: 0.0.0.0:22003 op UDP, 0.0.0.0:22005 op TCP en 0.0.0.0:22126 op UDP. Duikt daar bovendien een database op 0.0.0.0:3306 op, een webserver of een vergeten voicedienst, dan hoort dat te worden afgesloten. Het beeld van de aanvaller levert een poortscan van buitenaf:

nmap -Pn -sU -p 22003,22126 UW.SERVER.IP.ADRES
nmap -Pn -p 22005 UW.SERVER.IP.ADRES

De server brengt daarvoor ook een eigen consolecommando mee. In de serverconsole controleert openports of alle drie de poorten van buitenaf bereikbaar zijn.

2. Alleen de drie poorten openlaten die MTA werkelijk nodig heeft

Met UFW ziet een houdbare uitgangsconfiguratie er zo uit, en wel precies in deze volgorde, zodat u zichzelf niet buitensluit:

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

De volledige handleiding inclusief reddingsweg staat in het artikel UFW-firewall instellen. Bij KVM-rootservers en dedicated servers van KernelHost komt u in geval van nood via de VNC-console in het klantenpaneel op het systeem, ook wanneer de lijn verzadigd is.

De database hoort niet op het open netwerk. Toont ss -lntp | grep 3306 een 0.0.0.0:3306, zet dan in /etc/mysql/mariadb.conf.d/50-server.cnf de regel bind-address = 127.0.0.1 en start de dienst opnieuw op.

3. De ASE-poort begrenzen zonder uit de serverlijst te vallen

Anders dan bij SA-MP ligt de opvraging bij MTA:SA op een eigen poort, u kunt haar dus onafhankelijk van het spel begrenzen. Dat is het grootste praktische voordeel van deze architectuur: een regel op 22126 gooit geen enkele speler eruit.

Met nftables in een eigen tabel, zodat de regelset UFW niet in de weg zit:

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

De eerste regel begrenst elk afzonderlijk bronadres, de tweede de hele poort. Beide samen zijn belangrijk: een verdeelde vloed glipt door het gat tussen veel losse bronnen wanneer er alleen per adres wordt begrensd. De waarden zijn krap gekozen, en dat is hier verdedigbaar, omdat een echte serverbrowser uw server maar om de paar seconden opvraagt. Met iptables bereikt de hashlimit-module hetzelfde:

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

De poging om de poort helemaal te sluiten is een afweging en geen geheime tip: zonder ASE verdwijnt uw server uit de spelbrowser en daarmee uit de natuurlijke toestroom. Wilt u het toch, dan volstaat <ase>0</ase> niet. In de broncode hangt de vrijgave van de poort aan de of-verknoping van internetmodus en LAN-modus, de socket blijft bij <ase>0</ase> dus gewoon open zolang <donotbroadcastlan>0</donotbroadcastlan> staat. Wie de poort werkelijk wil sluiten, zet beide:

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

De eerlijker weg voor een groeiend project luidt: poort open laten, de snelheid begrenzen, en het versterkingseffect klein houden doordat uw gamemode geen onnodige regels via setRuleValue publiceert. Elke regel staat in de volledige opvraging en vergroot het antwoord.

4. De interne HTTP-server ontlasten

De HTTP-server op 22005 is bij MTA:SA een eigen aanvalsoppervlak, omdat elke toetredende speler daar alle clientzijdige bestanden van alle draaiende resources downloadt. Bij een roleplayproject met eigen modellen zijn dat al snel enkele honderden megabytes, verdeeld over honderden losse bestanden. De ingebouwde server is bewust eenvoudig gehouden: geen compressie, een vast contingent werkthreads. Een paar dozijn gelijktijdige opvragingen zijn genoeg om echte spelers minutenlang in het laadscherm te laten hangen.

De effectiefste maatregel is de downloads helemaal uit de spelserver te halen. MTA legt de uit te leveren bestanden daarvoor zelf klaar, onder mods/deathmatch/resource-cache/http-client-files. Die map geeft u via nginx of lighttpd uit en het adres vult u in de mtaserver.conf in:

<httpdownloadurl>http://cdn.uw-domein.tld/mta</httpdownloadurl>

Dat levert twee dingen tegelijk op. De downloads lopen over een webserver die daarvoor is gebouwd, en ze lopen niet meer over het adres van uw spelserver. Staat de webserver op een andere machine of achter een Content Delivery Network, dan raakt een vloed tegen de downloads het spel niet meer. Belangrijk: is het externe adres verkeerd of onbereikbaar, dan valt MTA stilzwijgend terug op de interne server.

Blijft de interne server in gebruik, benut dan zijn eigen grenzen. In de mtaserver.conf:

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

httpmaxconnectionsperclient begrenst de gelijktijdige verbindingen per client op 5 binnen het toegestane bereik 1 tot 8. httpdosthreshold begrenst hoeveel verbindingen één enkel IP-adres in korte tijd mag opbouwen, standaardwaarde 20. http_dos_exclude zondert afzonderlijke adressen daarvan uit, bijvoorbeeld uw eigen statuspagina. httpthreadcount bepaalt het aantal werkthreads, standaardwaarde 8 binnen het bereik 1 tot 20. Een hogere waarde helpt bij veel kleine bestanden, maar kost rekentijd die het spel dan mist.

Denk bovendien aan wat er op dezelfde poort nog meer wordt uitgeleverd. De resources webadmin en resourcebrowser zijn in de meegeleverde configuratie gestart en via 22005 in de browser bereikbaar. Een beheerinterface hoort niet onbeschermd op het open netwerk: geef in de acl.xml nette rechten uit, maak een eigen account met een lang willekeurig wachtwoord aan, en stop de resource wanneer u haar niet nodig hebt.

5. De ingebouwde grenzen in mtaserver.conf benutten

MTA brengt meer beschermingsgrenzen mee dan de meeste projecten benutten. Sommige staan vast in de broncode, andere in de mtaserver.conf. Deze tabel vat de grenzen samen die bij een aanval een rol spelen:

Drie instellingen verdienen een bewuste beslissing. maxplayers staat op 32 en hoort met de werkelijkheid overeen te komen: elk extra slot vergroot de volledige opvraging en verhoogt het aantal verbindingen dat een aanvaller kan bezetten. bandwidth_reduction staat op medium; de waarde maximum verlaagt de uitgaande belasting merkbaar, maar kost nauwkeurigheid bij de synchronisatie. En <password></password> maakt van uw server zonder moeite een gesloten kring terwijl de vermelding in de lijst blijft staan: de snelste noodrem bij een lopende joinflood.

6. Joinfloods en eventfloods uit elkaar houden

Twee aanvalspatronen mikken niet op de lijn, maar op de spellogica, en zij worden regelmatig verwisseld.

Een joinflood bouwt in snelle opeenvolging echte verbindingen op, tot alle sloten bezet zijn of de server de opbouw niet meer bijhoudt. MTA begrenst dat uit zichzelf op vier verbindingen per bronadres in 30 seconden en negeert het adres daarna 30 seconden lang. Wat de rem op dat moment doet, toont het consolecommando debugjoinflood. De grens werkt per adres, een botnet met duizend adressen loopt daaraan voorbij. Daartegen helpen een serverwachtwoord, een whitelist in de gamemode en een snelheidsbegrenzing op 22003.

Een eventflood komt daarentegen van al verbonden spelers: een gemanipuleerde client vuurt triggerServerEvent in een lus af, tot de server de rekentijd niet meer opbrengt. MTA staat daarvoor af fabriek 100 events per speler en seconde toe en meldt daarboven een eventflood. Gebruikt uw gamemode veel kleine events, controleer die waarde dan voordat u haar verlaagt: te krap gezet, gooit zij uw eigen spelers eruit.

Los daarvan geldt aan serverzijde dezelfde regel als overal: vertrouw nooit op waarden die de client meestuurt, bepaal de speler uit de afzender van het event, en begrens alles wat een databasequery uitlokt. Eén enkel ongecontroleerd event dat een query start, is genoeg om een server zonder enige netwerkaanval tot stilstand te brengen.

7. Serverlijst, IP-adres en wat het verder nog verraadt

Uw IP-adres laat zich niet geheimhouden. Iedere speler die ooit verbonden is geweest, kent het, en de vermelding in de masterserverlijst publiceert het sowieso. Een domein ervoor helpt niet: de client zoekt de naam één keer op en praat daarna rechtstreeks met het adres.

Controleer in plaats daarvan wat uw adres verder nog verraadt. Typische lekken bij MTA-projecten zijn oude A- en AAAA-records in het DNS, de projectpagina op dezelfde machine, een Discord-bot met statusweergave die de ASE-opvraging openbaar uitleest, TLS-certificaten met oude hostnamen en forumberichten uit de begintijd. Daaruit volgt een regel die veel projecten te laat leren: verhuist u naar een beschermd adres, wissel dan tegelijk het oude adres. Blijft het bestaan, dan staat het in elke scannerdatabase en loopt de aanval langs de bescherming heen.

Twee vermeldingen in de mtaserver.conf raken de zichtbaarheid rechtstreeks. <serverip>auto</serverip> blijft op auto staan, tenzij u precies weet waarom niet. En <owner_email_address> hoort ingevuld: ontbreekt die vermelding of is zij verkeerd, dan kan dat de zichtbaarheid in de masterserverlijst schaden.

8. Loggen, zodat u in geval van nood gegevens hebt

De belangrijkste stap is die welke bijna niemand vooraf zet: een vergelijkingsbasis aanleggen zolang alles normaal draait. Zonder normaalwaarde kunt u na een incident niet zeggen of 40.000 pakketten per seconde veel was of gewoon vrijdagavond. Met apt-get install -y vnstat sysstat loopt de meting permanent mee.

Tijdens een incident scheidt u eerst de drie poorten van elkaar. Deze vier commando's volstaan:

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

De uitleg is eenvoudiger dan zij eruitziet. Stijgen de bufferfouten bij een lage CPU-belasting, dan bereikt u meer verkeer dan het proces kan verwerken. Draait één core op volle toeren terwijl het verkeer normaal oogt, dan zit het probleem in de gamemode en niet in het netwerk. Toont de opname op 22126 veel pakketten met één enkele byte payload, dan is het een ASE-vloed. Staat het aantal open verbindingen op 22005 blijvend in het viercijferige bereik, dan treft het de HTTP-server. Voor tcpdump geldt altijd: met -c begrenzen, een opname onder volle belasting belast een toch al overbelaste server nog extra. Hoe u de waarden in detail uitleest, beschrijft het artikel DDoS-aanval op de server herkennen.

Het serverlogboek zelf ligt onder logs/server.log, het scriptlogboek onder logs/scripts.log. Beide paden staan in de mtaserver.conf en zijn te verleggen.

Waar deze maatregelen ophouden

Nu het deel dat geen enkel configuratiebestand kan oplossen. Alle maatregelen tot hier draaien op uw server, dus aan het einde van de lijn. Een firewallregel beslist over een pakket dat al over de kabel is gekomen. U kunt het verwerpen, maar u kunt niet terugdraaien dat het verstuurd is.

Rekent u even mee. Een typische gameserver hangt aan 1 Gbit/s, dat komt overeen met 125 megabyte per seconde en bij pakketten van 64 byte met ongeveer 1,49 miljoen pakketten per seconde. Aanvallen tegen gameserverprojecten van deze omvang liggen doorgaans tussen 5 en 50 Gbit/s, dus op het vijf- tot vijftigvoudige van uw lijn. Of uw nftables-regel daarachter goed is, doet dan niet meer ter zake, want de pakketten van uw spelers komen al eerder niet door.

De pakketsnelheid slaat daarbij vaak eerder toe dan de bandbreedte. Een gewone serverkernel verwerkt, afhankelijk van CPU en netwerkkaart, enkele honderdduizenden pakketten per seconde voordat hij begint te verwerpen. Een aanval die uw lijn nog niet eens voor een derde vult, kan uw server dus platleggen, omdat de rekentijd opgaat aan het verwerpen. Beheerders ervaren dat als "de belasting was helemaal niet hoog en toch was alles weg".

Bij MTA:SA komt er een derde grens bij, en die grijpt het vroegst. De server leest de netwerkpoorten in één enkele uitvoeringsthread. Een queryflood op 22126 houdt die thread zo bezig dat de synchronisatiepakketten van echte spelers in de ontvangstbuffer verlopen, ruim voordat de lijn vol is. Het proces crasht daarbij niet, het wordt alleen traag, en de spelers zien rubberbanding. Hetzelfde geldt voor de HTTP-server: hij deelt de rekentijd met het spel.

Ter oriëntatie, welke ordes van grootte werkelijk voorkomen: op KernelHost-servers zijn onder meer een aanval met meer dan 473,4 Gbit/s bij meer dan 41,5 miljoen pakketten per seconde op een voiceserver en een UDP-flood met meer dan 112,2 Gbit/s bij meer dan 8,7 miljoen pakketten per seconde op een gameserver weggefilterd. Het eerste geval is ongeveer 473 keer de bandbreedte en ongeveer 28 keer de pakketsnelheid die een lijn van 1 Gbit/s überhaupt kan opnemen. Daarvoor bestaat geen lokale instelling. Volumetrische aanvallen moeten in het netwerk vóór de server eindigen.

Wat KernelHost daartegenover zet

De permanente bescherming die bij elke server inbegrepen is

Elke server bij KernelHost staat achter een permanent actieve filtering in twee lagen:

• Laag 1: 17 Tbps mitigatiecapaciteit in het globale scrubbing-netwerk. Volumetrische aanvallen worden dicht bij hun bron geschoond, nog voordat zij het datacenter in Frankfurt am Main überhaupt bereiken.
• Laag 2: Arbor realtime filtering met 3,2 Tbps ter plaatse in Frankfurt am Main. Vlak voor de server worden protocolspecifieke patronen herkend en pakket voor pakket verworpen.

Drie eigenschappen zijn doorslaggevend. De bescherming is permanent actief, er is dus geen detectiefase waarin uw server offline gaat. Er wordt geen null-routing toegepast: het aangevallen adres blijft in het netwerk, alleen de schadelijke pakketten worden verworpen, terwijl de verbindingen van echte spelers doorlopen. En zij kost niets extra, maar zit vanaf de oplevering in elk serverpakket, van de KVM-rootserver via de gameserver tot de dedicated server. Er wordt gefilterd op Layer 3, 4 en 7 op elke TCP- of UDP-poort, dus op 22003 UDP, 22005 TCP en 22126 UDP tegelijk. Dit draait in het datacenter maincubes in Frankfurt am Main, Duitsland. Welke games en protocollen een eigen profiel hebben, toont het artikel Gameserver-DDoS-bescherming in realtime.

Advanced DDoS Protection voor projecten die permanent onder vuur liggen

Sommige projecten worden niet af en toe geraakt, maar wekenlang gericht aangevallen. Voor dat geval is er de Advanced DDoS Protection vanaf 50,00 € per maand, PrePaid en zonder minimale looptijd. Het verschil zit niet in meer capaciteit, maar in de controle:

• Een dedicated beschermd IP-adres uit de Frankfurtse kern. Uw server wordt binnen het netwerk van KernelHost daarop omgezet, aan uw kant verbouwt u niets.
• Zelf beheerbare beschermingsregels per poort en protocol in het klantenpaneel. Precies dat is bij MTA:SA het punt: u stelt voor 22003 UDP, 22005 TCP en 22126 UDP gescheiden regels in, in plaats van drie zeer verschillende diensten over één kam te scheren.
• Wijzigingen gelden in realtime, zonder ticket en zonder wachttijd. U kunt dus midden in een lopende aanval bijsturen.
• Een beschermingsprofiel dat bij het spel past. Multi Theft Auto is als eigen profiel aanwezig, net zo goed als webservers, voiceservers en eigen TCP- of UDP-toepassingen die achter hetzelfde beschermde adres passen.

De twee lagen naast elkaar

Voor de meeste MTA:SA-projecten volstaat de inbegrepen permanente bescherming samen met een nette serverconfiguratie. De Advanced DDoS Protection is het antwoord op iemand die het persoonlijk maakt.

Veelgemaakte fouten en oplossingen

"Ik heb 22126 geblokkeerd, de server staat toch in geen enkele lijst, maar er komen nog steeds opvragingen binnen": dan is de socket nog open. <ase>0</ase> alleen sluit de poort niet zolang <donotbroadcastlan>0</donotbroadcastlan> is gezet. Controleer met ss -lnup | grep 22126 of er werkelijk niets meer luistert.

"Spelers hangen in het laadscherm, het spel zelf loopt normaal": dat is geen aanval op 22003, maar de HTTP-server op 22005 die aan zijn grens zit. Besteed de downloads via httpdownloadurl uit en controleer httpmaxconnectionsperclient en httpthreadcount.

"De server is uit de browser verdwenen, de spelers erop merken niets": dan treft het uitsluitend 22126. Voor de verbonden spelers is dat zonder gevolgen, voor de toestroom van nieuwe spelers niet. Een snelheidsbegrenzing op die ene poort is het juiste antwoord, niet een op de spelpoort.

"Wij hebben het IP-adres gewisseld en waren twee uur later weer offline": de aanvaller haalt het nieuwe adres uit dezelfde bron als het oude, meestal de vermelding in de lijst, een Discord-bot met statusopvraging of een oud DNS-record. Een adreswissel is tijdwinst, geen oplossing.

"Wij hebben een ratelimiet van 20 pakketten per seconde per adres op 22003 gezet": dat is te krap. Alleen al één enkele speler zit bij actieve synchronisatie daarboven, en meerdere spelers achter hetzelfde NAT-adres delen hetzelfde contingent. Zo gooit u uw eigen spelers eruit. Op 22126 zijn krappe waarden daarentegen onproblematisch.

"Wij hebben onszelf met de firewall buitengesloten": een herstart helpt niet, want UFW herstelt zijn regels bij het opstarten. Bij KernelHost opent u de VNC-console in het klantenpaneel en voert u daar ufw disable uit. De VNC-console werkt onafhankelijk van het netwerk van het gastsysteem.

"Mijn vorige aanbieder heeft mijn IP-adres geblokkeerd": dat is null-routing. De aanbieder beschermt daarmee zijn eigen netwerk; voor u is het resultaat identiek aan een geslaagde aanval, meestal nog urenlang daarna. Vraag bij twijfel na of er wordt gefilterd of null-geroutet. Dat antwoord bepaalt meer over uw beschikbaarheid dan welke hardwarespecificatie ook.

"Wij wachten de aanval gewoon af": aanvallen die effect hebben, worden herhaald. Leg tijdstip met tijdzone, duur, piekwaarden en de betrokken poort vast. Precies die gegevens heeft ook een supportticket nodig, zodat de filtering gericht wordt nagetrokken.

Kort samengevat

• Een MTA:SA-server heeft precies drie poorten nodig: 22003 UDP voor het spel, 22005 TCP voor de interne HTTP-server en 22126 UDP voor de ASE-opvraging. De derde volgt vast uit de spelpoort plus 123.
• De ASE-opvraging ligt op een eigen poort en laat zich daarom begrenzen zonder ook maar één speler buiten te sluiten. Dat is het belangrijkste verschil met SA-MP, waar spel en opvraging dezelfde poort delen.
• Eén enkele verzoekbyte op 22126 levert een antwoord van tot meerdere kilobytes op, en het afzenderadres is vervalsbaar. Een ongeremde ASE-poort is daarmee doelwit en versterker tegelijk.
• De ingebouwde remmen van MTA werken per bronadres: vijf opvragingen in zes seconden, vier toetredingen in 30 seconden. Bij meer dan 100 gelijktijdige bronadressen wordt de telling van de opvragingen overgeslagen, een verdeelde vloed loopt er dus doorheen.
• De interne HTTP-server op 22005 is een eigen aanvalsoppervlak. Wie de downloads via httpdownloadurl naar een externe webserver uitbesteedt, haalt ze uit het spel weg.
• Alles wat op de server draait, beslist alleen over kleine aanvallen. Bij 1 Gbit/s houdt het op bij ongeveer 1,49 miljoen pakketten per seconde, ongeacht de kwaliteit van uw regels.
• De permanente bescherming in twee lagen bij KernelHost zit zonder meerprijs in elk serverpakket en werkt zonder null-routing. Wie de regels per poort zelf wil sturen, neemt de Advanced DDoS Protection vanaf 50,00 € per maand erbij.

Draait uw project al bij KernelHost, dan is de filtering permanent actief en hoeft u niets in te schakelen. Merkt u toch afwijkingen, open dan een supportticket met de periode, de poort en het waargenomen gedrag, zodat de regels voor uw adres worden bijgesteld. Bij een lopende aanval bereikt u ons daarnaast via de WhatsApp-noodchat op +43 650 8209883. Host u nog ergens anders en wordt u regelmatig geraakt, dan is de verhuizing naar Frankfurt am Main de kortere oplossing: verdere stappen voor het acute geval staan in het artikel Zware DDoS-aanval: wat nu?.