SA-MP- en open.mp-servers beschermen tegen DDoS-aanvallen

Een SA-MP- of open.mp-project groeit meestal volgens hetzelfde patroon: het aantal spelers stijgt, de server klimt in de serverlijst, en een paar dagen later vallen de verbindingen bij bosjes weg. Het langste deel van deze handleiding beschrijft wat u zonder extra kosten zelf op uw server kunt aanpassen. Daarna leest u waar die maatregelen technisch ophouden, en pas dan wat KernelHost daartegenover zet.

Waarom juist SA-MP en open.mp zo vaak worden geraakt

De scene is klein en competitief. Veel roleplay- en freeroamservers dingen naar dezelfde spelers, en de drempel om een concurrent voor een paar uur uit de lijst te schieten ligt laag. Daar komen verbannen spelers bij, en afpersingspogingen tegen projecten met een eigen shop.

Technisch maakt het spel het aanvallers gemakkelijk. Al het spelverkeer loopt over UDP, en UDP kent geen verbindingsopbouw die de aanvaller iets kost; bovendien zijn afzenderadressen eenvoudig te vervalsen. De vermelding in de serverlijst publiceert adres en poort, dus verkennen vooraf is overbodig. En omdat de meeste projecten op één enkele server draaien, staan de gameserver, de database, het gebruikerspaneel en vaak ook de voiceserver op hetzelfde adres: één treffer legt alles tegelijk plat.

Om welke poorten en protocollen het gaat

• SA-MP-server: UDP 7777 in de standaardinstelling, in te stellen via port in de server.cfg.
• open.mp-server: eveneens UDP 7777 in de standaardinstelling, in te stellen via network.port in de config.json.
• Query: dezelfde UDP-poort. Er is geen aparte poort voor opvragingen. Serverbrowsers, statuspagina's en Discord-bots spreken precies de poort aan waarop ook gespeeld wordt.
• RCON: eveneens dezelfde UDP-poort, als eigen opcode binnen het queryprotocol, onversleuteld.
• De vermelding in de serverlijst gaat uitgaand naar de betreffende serverlijst, inkomend hoeft daarvoor niets open te staan.
• Al het overige op dezelfde machine: SSH op TCP 22, MariaDB of MySQL op TCP 3306, het gebruikerspaneel op TCP 80 en 443.

Het gevolg: u kunt de querytoegang niet met een firewall van het spel scheiden, want beide liggen op dezelfde poort. Wie UDP 7777 blokkeert, sluit zijn eigen spelers buiten.

Een queryverzoek begint met elf byte: vier byte kenmerk, vier byte serveradres, twee byte poort, één byte opcode. De opcode bepaalt het antwoord: i levert de serverinformatie, r de regels, c een korte spelerslijst, d een uitgebreide spelerslijst met naam, score en ping per speler, p kaatst vier byte terug voor de pingmeting, x is RCON. Op een goed bezochte server levert elf byte verzoek meerdere kilobytes antwoord op. Daarmee is een open querytoegang dubbel interessant: als doelwit en als versterker tegen derden. Wat er achter dat aanvalspatroon zit, legt het artikel Wat is een DDoS-aanval? uit.

Wat u zelf kunt doen voordat u geld uitgeeft

De volgende stappen kosten niets en werken tegen de aanvallen die de dagelijkse praktijk vormen: joinfloods, queryfloods en losse bronnen met een hoge pakketsnelheid. Alle commando's gaan uit van root, werkt u als gewone gebruiker, zet dan sudo ervoor.

1. Inventarisatie: wat luistert er eigenlijk?

ss -lnup
ss -lntp

Wat op 127.0.0.1 of ::1 luistert, heeft geen firewallregel nodig. Wat op 0.0.0.0 of [::] staat, is van buitenaf bereikbaar en moet een goede reden hebben.

2. Alles sluiten wat het spel niet nodig heeft

Een pakketfilter maakt geen einde aan een volumeaanval, maar verkleint wel het aanvalsoppervlak. Een bruikbare basisconfiguratie met UFW:

ufw allow 22/tcp comment 'SSH'
ufw allow 7777/udp comment 'SA-MP / open.mp'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

De volgorde is geen toeval: de toestemmingsregels staan vóór het inschakelen, anders sluit u uzelf buiten. De details, inclusief de weg terug, staan 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.

De database hoort niet op het open netwerk. Toont ss -lntp | grep 3306 een 0.0.0.0:3306, zet dan bind-address = 127.0.0.1 en start de dienst opnieuw op. Ook de gameserver bindt u aan een vast adres, in SA-MP via bind, in open.mp via network.bind.

3. De querytoegang afzwakken zonder de spelers buiten te sluiten

SA-MP kent in de server.cfg de schakelaar query 0, waarmee de server op geen enkele opvraging meer antwoordt. Dat werkt, maar de prijs is hoog: de server verdwijnt uit de browser, het spelersaantal en de regels zijn niet meer af te lezen, en statuspagina's en Discord-bots tonen hem als offline. Voor een besloten groep is dat een optie, voor een groeiend project niet. In open.mp zit die schakelaar in het onderdeel network van de config.json; controleer de exacte sleutelnaam in uw versie in plaats van ernaar te raden.

De realistische weg is dus begrenzen in plaats van uitschakelen. Deze filterregel toont live alleen de pakketten met het querykenmerk:

tcpdump -ni any -c 100 'udp port 7777 and udp[8:4] = 0x53414d50'

Welke afzenderadressen het meeste verkeer naar de spelpoort sturen:

tcpdump -nn -q -c 2000 'udp dst port 7777' 2>/dev/null \
  | awk '{print $3}' | cut -d. -f1-4 | sort | uniq -c | sort -rn | head -20

4. Rate limiting instellen in de netwerkstack

Met nftables begrenst u de pakketsnelheid per afzenderadres. De volgende set regels maakt een eigen tabel aan, zodat UFW er geen last van heeft:

nft add table inet gameguard
nft add chain inet gameguard input '{ type filter hook input priority -150 ; policy accept ; }'
nft add rule inet gameguard input udp dport 7777 meter perip '{ ip saddr limit rate over 60/second burst 120 packets }' drop
nft list table inet gameguard

Daarnaast is een bovengrens voor de hele poort verstandig, zodat een breed verdeelde flood niet door het gat tussen veel losse bronnen glipt:

nft add rule inet gameguard input udp dport 7777 limit rate over 20000/second burst 5000 packets drop

Met iptables bereikt de hashlimit-module hetzelfde:

iptables -N SAMPGUARD
iptables -A INPUT -p udp --dport 7777 -j SAMPGUARD
iptables -A SAMPGUARD -m hashlimit --hashlimit-name samp --hashlimit-mode srcip \
  --hashlimit-above 60/sec --hashlimit-burst 120 --hashlimit-htable-expire 30000 -j DROP

Deze getallen zijn startwaarden, geen advies voor uw server. Eén enkele speler produceert alleen al door de positiesynchronisatie enkele tientallen pakketten per seconde; die frequentie regelt u in SA-MP via onfoot_rate, incar_rate en weapon_rate. Het wordt kritiek zodra meerdere spelers achter hetzelfde adres zitten, bijvoorbeeld in hetzelfde huishouden of achter de carrier-NAT van een mobiele aanbieder. Een te krappe grens gooit juist die spelers eruit, en dat ziet eruit als een aanval. Eerst meten, dan instellen, dan de verbroken verbindingen in de gaten houden.

5. Grenswaarden in server.cfg en config.json

Beide implementaties brengen eigen beschermingsgrenzen mee, die vaak op de standaardwaarden blijven staan. Voor SA-MP in de server.cfg:

lanmode 0
query 1
announce 1
rcon 0
conncookies 1
connseedtime 300000
minconnectiontime 1000
messageslimit 500
messageholelimit 3000
ackslimit 3000
playertimeout 10000

Voor open.mp staan dezelfde grootheden in de config.json:

{
  "network": {
    "port": 7777,
    "bind": "",
    "use_lan_mode": false,
    "cookie_reseed_time": 300000,
    "minimum_connection_time": 1000,
    "messages_limit": 500,
    "message_hole_limit": 3000,
    "acks_limit": 3000,
    "player_timeout": 10000,
    "limits_ban_time": 60000
  },
  "rcon": {
    "enable": false
  }
}

Wat deze waarden doen:

• Verbindingscookies (conncookies respectievelijk cookie_reseed_time) vragen de client om antwoord op een controlevraag voordat er een slot bezet raakt. Een vervalst afzenderadres krijgt die controlevraag nooit te zien en kan hem dus ook niet beantwoorden. Dat is de effectiefste ingebouwde rem tegen verbindingsfloods, laat hem ingeschakeld staan.
• Minimale tussentijd tussen verbindingspogingen (minconnectiontime respectievelijk minimum_connection_time, in milliseconden) voorkomt dat hetzelfde adres elke seconde opnieuw een verbinding opbouwt. Tegen botjoins is dat de tweede belangrijke knop.
• Grenzen voor berichten, gaten en bevestigingen (messageslimit, messageholelimit, ackslimit) bepalen hoeveel een bestaande verbinding mag versturen. Zij beschermen tegen gemanipuleerde clients, niet tegen volume.
• Time-out (playertimeout, player_timeout) bepaalt hoe lang een stille verbinding een slot bezet houdt. Een lage waarde maakt plaatsen bij een joinflood sneller vrij, maar gooit spelers met een slechte verbinding ook eerder eruit. De blokkeerduur (limits_ban_time in open.mp) legt vast hoe lang een verdacht adres buitengesloten blijft.

Twee aandachtspunten: de config.json moet geldige JSON blijven, één komma te veel verhindert de start. En open.mp vult ontbrekende instellingen bij de start zelf aan, bewerk het bestand daarom terwijl de server gestopt is.

Nog een woord over RCON: het wachtwoord gaat onversleuteld over UDP en is over de hele route mee te lezen. Hebt u RCON niet nodig, schakel het dan uit met rcon 0 respectievelijk "enable": false. Zo niet, dan geldt: een lang willekeurig wachtwoord en toegang uitsluitend via een VPN.

6. Afweer in de gamemode en in de plugins

SA-MP roept OnIncomingConnection aan voordat er een spelersslot bezet raakt. Daar kunt u meetellen en verdachte adressen tijdelijk blokkeren:

public OnIncomingConnection(playerid, ip_address[], port)
{
    if (ConnectAttemptsTooHigh(ip_address))
    {
        BlockIpAddress(ip_address, 60000);
    }
    return 1;
}

ConnectAttemptsTooHigh is met opzet uw eigen telfunctie: zinvolle drempels hangen af van uw spelersaantal. BlockIpAddress verwacht de blokkeerduur in milliseconden, UnBlockIpAddress heft de blokkade voortijdig op. De blokkeerlijst staat in het werkgeheugen en is na een herstart leeg.

Daarnaast horen twee hulpmiddelen in elk project thuis. De plugin crashdetect toont bij een crash de betrokken functie en de regel in de gamemode; zonder die plugin ziet een runtimefout in uw eigen code er van buitenaf uit als een aanval. Een goed onderhouden anticheat zoals Nex-AC dekt manipulatie aan de clientkant af, maar werkt uitsluitend met verbonden spelers binnen de spellogica. Een vloed vervalste pakketten wordt nooit een speler en glipt daar dus langs. Dat zijn twee verschillende problemen.

Houd bovendien includes en plugins actueel: verschillende bekende crashmethoden in SA-MP berusten op waarden buiten het geldige bereik die aan native functies worden doorgegeven. En geef ongecontroleerde spelersinvoer nooit door aan SendRconCommand of aan een databasequery.

7. De vermelding in de serverlijst en uw echte adres

De vermelding in de lijst maakt u vindbaar, voor spelers én voor aanvallers. Met announce 0 verdwijnt u uit beide lijsten, en daarmee ook uit de natuurlijke toestroom. Dat is een afweging, geen geheime tip.

Een domein ervoor zetten helpt niet: de client zoekt de naam één keer op en praat daarna rechtstreeks met het adres, en die naam kan iedereen opzoeken. Controleer in plaats daarvan wat uw adres verder verraadt: oude A- en AAAA-records in het DNS, het gebruikerspaneel op dezelfde machine, de statusweergave van een Discord-bot, een open webinterface van de database, 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 oorspronkelijke adres. Anders staat het oude adres in elke scannerdatabase en loopt de aanval langs de bescherming heen.

8. Whitelist en besloten gebruik

Voor de spelpoort is een whitelist zelden werkbaar, omdat spelers van wisselende adressen komen. Een serverwachtwoord (password in beide implementaties) maakt van de server zonder moeite een besloten club, terwijl de vermelding in de lijst gewoon blijft staan. Voor de beheertoegangen is een whitelist juist verplicht, dus voor SSH, database, paneel en, als u het houdt, RCON:

ufw allow from 203.0.113.10 to any port 22 proto tcp comment 'Admin'
ufw delete allow 22/tcp
ufw status numbered

Wisselt uw eigen aansluitadres regelmatig, dan is een VPN netter dan een steeds langere uitzonderingslijst.

9. Loggen: eerst meten, dan handelen

SA-MP schrijft zijn logboek naar server_log.txt in de servermap, open.mp naar het bestand dat in het onderdeel logging is ingesteld. Welke adressen het vaakst aankloppen:

grep "Incoming connection" server_log.txt \
  | grep -oE '([0-9]{1,3}\.){3}[0-9]{1,3}' \
  | sort | uniq -c | sort -rn | head -20

Een hoog aantal opgevraagde verbindingscookies wijst op een joinflood:

grep -c "requests connection cookie" server_log.txt

De meest zeggende waarde staat echter niet in het spellogboek, maar in de kernel. Haalt het serverproces de pakketten niet snel genoeg uit de ontvangstbuffer, dan telt de kernel het verlies mee:

nstat -az | grep -E 'Udp(InDatagrams|InErrors|NoPorts|RcvbufErrors)'
ip -s -s link show

Daaruit volgt het belangrijkste onderscheid van allemaal: stijgen de bufferfouten bij een lage CPU-belasting, dan komt er meer verkeer binnen dan het proces kan verwerken. Draait daarentegen één core op volle toeren terwijl het verkeer normaal oogt, dan zit het probleem in de gamemode en niet in het netwerk. Hoe u die twee gevallen uit elkaar houdt, beschrijft het artikel DDoS-aanval op de server herkennen.

Waar deze maatregelen ophouden

Alle voorgaande stappen grijpen pas in wanneer de pakketten al over uw lijn zijn gekomen: de kernel verwerpt ze na aankomst. Daarmee ligt er een harde bovengrens vast die niets te maken heeft met de kwaliteit van uw regels.

Een aansluiting van 1 Gbit/s neemt bij de kleinst mogelijke pakketgrootte ongeveer 1,49 miljoen pakketten per seconde aan, meer past er fysiek niet doorheen. Ter vergelijking twee aanvallen die op servers van KernelHost zijn gemeten en gefilterd: ruim 473,4 Gbit/s bij ruim 41,5 miljoen pakketten per seconde tegen een voiceserver op UDP 9987, en ruim 112,2 Gbit/s bij ruim 8,7 miljoen pakketten per seconde tegen een gameserver op UDP 7777. Het eerste geval is ongeveer 473 keer de bandbreedte en ongeveer 28 keer de pakketsnelheid die een lijn van 1 Gbit/s maximaal kan opnemen. Zelfs een perfect filter op de server verandert daar niets aan, want de pakketten bereiken dat filter helemaal niet: de aansluiting ervoor zit vol, en daarmee vallen ook de pakketten van uw spelers weg.

Twee andere grenzen treden nog eerder in werking. Ten eerste leest de gameserver de poort in één enkele uitvoeringsthread. Een queryflood kan die thread zo bezighouden dat de synchronisatiepakketten van echte spelers in de ontvangstbuffer verlopen, ruim voordat de lijn verzadigd is. Het proces crasht daarbij niet, het wordt alleen traag, en de spelers zien rubberbanding. Ten tweede zijn afzenderadressen bij UDP vervalsbaar; blokkades op adres treffen dan onbetrokkenen en de aanvaller helemaal niet.

Nuchter samengevat: uw werk op de server bepaalt of een kleine aanval doorkomt. Of een grote aanval doorkomt, bepaalt het netwerk vóór de server.

Wat KernelHost daartegenover zet

Bij elke server inbegrepen: de permanente bescherming in twee lagen

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

• Laag 1: wereldwijd scrubbing-netwerk met 17 Tbps mitigatiecapaciteit. Volumetrische aanvallen worden dicht bij hun bron onderschept en opgeschoond, nog voordat zij het datacenter in Frankfurt am Main 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 daarbij doorslaggevend. De bescherming is permanent actief, er is dus geen detectiefase waarin uw server offline gaat. Er wordt geen null-routing ingezet: het aangevallen adres blijft in het netwerk, alleen de schadelijke pakketten vallen weg, terwijl de verbindingen van echte spelers gewoon doorlopen. En zij kost niets extra, maar zit 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 ook op UDP 7777. Dit draait in het datacenter maincubes in Frankfurt am Main, Duitsland, beheerd door KernelHost GmbH met vestiging in Wenen, Oostenrijk. Welke games en protocollen een eigen profiel hebben, laat het artikel Gameserver-DDoS-bescherming in realtime zien.

Voor projecten die permanent onder vuur liggen: Advanced DDoS Protection

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. Zij vult de permanente bescherming aan met drie dingen:

• Een dedicated beschermd IP-adres uit de Frankfurtse kern. Uw server wordt binnen het netwerk van KernelHost daarop omgezet, aan uw kant hoeft u niets te verbouwen.
• Zelf beheerbare beschermingsregels per poort en protocol in het klantenpaneel. Wijzigingen gelden in realtime, zonder ticket en zonder wachttijd, dus u kunt midden in een aanval bijstellen.
• Een beschermingsprofiel dat bij het spel past. Kant-en-klare profielen voor meer dan 40 games, diensten en protocollen, waaronder SA-MP en open.mp, plus eigen TCP- en UDP-toepassingen. Ook het gebruikerspaneel, de voiceserver en een VPN passen achter hetzelfde beschermde adres.

De twee lagen naast elkaar

Veelgemaakte fouten en oplossingen

"De server is weg, dus het is een aanval." Controleer eerst of het proces nog draait. Een runtimefout in de gamemode ziet er van buitenaf precies zo uit. Met crashdetect staat de oorzaak in het logboek, zonder die plugin gokt u.

"Wij hebben de querypoort geblokkeerd." Er is geen aparte querypoort. Wie UDP 7777 blokkeert, blokkeert het spel zelf. Bedoeld wordt ofwel query 0 (de server verdwijnt uit de lijst), ofwel rate limiting op diezelfde poort.

"Wij hebben het IP-adres gewisseld en zijn weer online." Zolang het lek open blijft, is het nieuwe adres binnen enkele uren opnieuw openbaar. Oude DNS-records, het paneel op dezelfde machine en de statusweergave van een Discord-bot verraden het feilloos.

"Wij hebben een limiet van 20 pakketten per seconde per adres ingesteld." Dat is te krap. Alleen al één enkele speler zit daarboven, en meerdere spelers achter één NAT-adres delen hetzelfde contingent. Zo gooit u uw eigen spelers eruit.

"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. Een IPMI of iDRAC is er bij KVM-rootservers en dedicated servers niet, de weg loopt via de VNC-console.

"Het RCON-wachtwoord staat in de teamchat." RCON gaat onversleuteld over UDP en is over de hele route mee te lezen. Hebt u het niet nodig, schakel het dan uit. Zo niet, dan geldt: een lang willekeurig wachtwoord en toegang uitsluitend via een VPN.

"Wij wachten de aanval gewoon af." Aanvallen die effect hebben, worden herhaald. Leg tijdstip, duur, piekwaarden en betrokken poorten vast. Precies die gegevens heeft ook een supportticket nodig, zodat de filtering gericht kan worden bijgesteld.

Als u op dit moment wordt aangevallen

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.