Skydda Palworld-server mot DDoS-attacker

En Palworld-server som på kvällen kastar ut alla spelare samtidigt mitt i spelet, går offline i några minuter och därefter blir nåbar igen av sig själv har sällan ett hårdvaruproblem. I de allra flesta fall pågår en attack. Den här artikeln visar hur du skyddar en Palworld-server mot DDoS-attacker: först det du kan konfigurera själv utan extra kostnad, därefter stället där de åtgärderna tar slut rent tekniskt, och till sist vad som måste hända i nätet framför servern för att servern ska förbli nåbar.

Alla uppgifter gäller den officiella dedikerade servern från Pocketpair (Steam-app-ID 2394010) 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. Pågår attacken just nu gäller en ordning: mät först, ändra sedan. En hård omstart under last kasserar allt som har hänt i världen sedan den senaste automatiska sparpunkten, och mätvärdena från händelsen är därefter också borta.

Varför Palworld-servrar slås ut riktat med DDoS-attacker

En Palworld-server är en liten, fast publik på en fast adress. Den dedikerade servern är begränsad till 32 spelare, styrt via ServerPlayerMaxNum med det giltiga intervallet 1 till 32. Den som i stället är värd via spelets meny kommer upp i fyra spelare, och bara så länge värden själv är online. Ur de här 32 platserna följer allt annat: gruppen spelar på fasta kvällstider, känner varandra, och ett avbrott klockan 20 träffar inte en bråkdel av spelarna utan alla.

Serverns adress är samtidigt ingen hemlighet. Palworld har ingen förmedling via en leverantörstjänst: spelarna skriver in IP-adress och port i fältet för direktanslutning, och den som dessutom vill ha servern i community-serverlistan startar den med -publiclobby och låter query-porten besvara förfrågningarna. Alla som någon gång har varit anslutna känner därmed till målet. En booter-tjänst som beskjuter den adressen för några euro i månaden kräver varken kunskap eller möda av uppdragsgivaren.

Tekniskt kommer därtill att hela speltrafiken går över UDP. UDP känner inte till någon uppkoppling som man skulle kunna kräva, och avsändaradressen i ett UDP-paket går att förfalska. En angripare måste alltså varken gå in på servern eller tilltala den korrekt för att skapa last. Vad som tekniskt sker vid en sådan attack förklaras i artikeln Vad är en DDoS-attack?.

Portarna som det faktiskt handlar om hos en Palworld-server

En Palworld-server behöver exakt en öppen port: 8211 UDP. Allt annat är valfritt och beroende på uppgift till och med skadligt när det står i det öppna nätet. Därav följer en användbar åtskillnad: en DDoS-attack mot port 8211 träffar alltid själva speltrafiken, en attack mot port 27015 UDP däremot bara posten i serverlistan.

Alla reglage för detta står i en enda fil: Pal/Saved/Config/LinuxServer/PalWorldSettings.ini, under Windows motsvarande Pal\Saved\Config\WindowsServer\PalWorldSettings.ini. Den börjar med avsnittsraden [/Script/Pal.PalGameWorldSettings], därefter följer en enda rad OptionSettings=(...) som innehåller samtliga inställningar som en lista. En radbrytning inuti parentesen gör hela konfigurationen ogiltig, och servern faller utan kommentar tillbaka på standardvärdena. Mallen DefaultPalWorldSettings.ini i serverkatalogen redigerar du inte, för den skrivs över vid varje uppdatering.

Palworld-servern i siffror

Följande värden är grunden för varje beslut om filterregler och gränsvärden.

Varför query-porten 27015 är den känsligaste punkten

Query-porten besvarar statusförfrågningar i Steam-formatet A2S, alltså samma förfrågan som Counter-Strike- och ARK-servrar betjänar. En A2S_INFO-förfrågan är ett anslutningslöst UDP-paket på några tiotal byte, svaret med servernamn, värld, spelarantal och speltillstånd är mångdubbelt större. Eftersom avsändaradressen går att förfalska vid UDP kan en angripare tilltala främmande query-portar och styra de större svaren till sitt egentliga mål. Din server är i det fallet inte offret utan förstärkaren, och det är dess anslutning som betalar räkningen.

Valve kompletterade därför A2S_INFO den 8 december 2020 med en förkopplad challenge: servern svarar först med S2C_CHALLENGE, frågeställaren måste skicka tillbaka token och bevisar därmed att han inte förfalskar sin avsändaradress. Det tar udden av förstärkningen men avslutar den inte, och mot en enkel flod av likadana förfrågningar från äkta adresser verkar den inte alls.

För Palworld följer en viktig fördel av det jämfört med Source-motorn: speltrafik och serverförfrågan ligger på skilda portar. Hos Counter-Strike 2 delar båda på port 27015, en grov hastighetsbegränsning kastar där ut de egna spelarna på köpet. Hos Palworld kan du begränsa 27015 UDP hårt eller stänga den helt utan att röra en enda löpande speltrafik på 8211 UDP. Den som inte behöver posten i listan stryker -publiclobby och query-porten utan ersättning och tar därmed bort en hel angreppsyta ur nätet.

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

Följande steg stoppar ingen volymetrisk attack, det klarar ingen programvara på servern. Men de röjer undan allt som ligger under den nivån: portskanningar, förfrågningsfloder, övertagandeförsök via administrationsportarna och att alla 32 platser upptas av främmande. Det är merparten av det som stör en Palworld-server i vardagen, och det kostar en halvtimme.

1. Inventering: vad lyssnar på servern?

Innan du skriver en enda regel tittar du efter vad din server erbjuder utåt. Inte gissa, titta efter:

ss -lntup

Intressant är kolumnen med den lokala adressen. 0.0.0.0:8211 betyder "nåbar från hela internet", 127.0.0.1:8212 betyder "bara lokalt" och behöver ingen brandväggsregel. Vid sidan av spelprocessen dyker det på en server som vuxit fram ofta upp en förvaltningspanel, en webbserver för kartvisningen och en databas. Angriparens vy får du med en portskanning utifrån:

nmap -Pn -sU -p 8211,27015 DIN.SERVER.IP.ADRESS
nmap -Pn -p- --min-rate 1000 DIN.SERVER.IP.ADRESS

2. Öppna bara det som Palworld verkligen behöver

Två öppningar räcker, och den andra är valfri. Med UFW ser det ut så här, och då i exakt den ordningen så att du inte låser ute dig själv:

ufw allow 22/tcp comment 'SSH'
ufw allow 8211/udp comment 'Palworld speltrafik'
ufw allow 27015/udp comment 'Palworld Steam-query'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Den tredje raden utelämnar du om din server inte ska stå i community-serverlistan. Dina spelare ansluter då fortfarande via IP-adress och port 8211, servern försvinner bara ur den publika listan. Den fullständiga anvisningen inklusive räddningsvägen står i Sätta upp UFW-brandväggen utan att låsa ute dig själv.

3. Ta RCON på 25575 och REST-API:t på 8212 ur det öppna nätet

Båda portarna är administrationsingångar med full kontroll över servern, och båda är avstängda som standard: RCONEnabled=False och RESTAPIEnabled=False. Den som slår på dem bör veta vad han därmed publicerar.

REST-API:t på 8212 TCP autentiserar via HTTP Basic Auth med det fasta användarnamnet admin och värdet ur AdminPassword, och det över okrypterad HTTP. Administrationslösenordet löper därmed vid varje enskild förfrågan i vändbar form över ledningen. RCON på 25575 TCP är ett lika okrypterat textprotokoll, och Pocketpair har markerat det som föråldrat till förmån för REST-API:t. För nya installationer är REST-API:t det rätta valet, för båda gäller samma regel: inte ut i det öppna nätet.

RESTAPIEnabled=True
RESTAPIPort=8212
AdminPassword="ett långt slumpmässigt värde"

Nåbart gör du gränssnittet via en SSH-portvidarebefordran, därefter arbetar du lokalt mot 127.0.0.1:8212:

ssh -N -L 8212:127.0.0.1:8212 root@DIN.SERVER.IP.ADRESS

Lämna aldrig AdminPassword tomt, för tomt är standardvärdet. Ett värde från openssl rand -base64 32 räcker. Samma sak gäller ServerPassword, mer om det strax.

4. Begränsa query-porten 27015 utan att förlora posten i listan

Anslutningslösa Steam-paket börjar med fyra satta byte (0xffffffff), reguljär speltrafik har inte det huvudet. På det går det att lägga en hastighetsbegränsning per källadress som bromsar förfrågningarna och bevarar posten i listan. Med nftables, inläst via 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
    }
}

Prioriteten -10 ser till att regeln griper före UFW:s filterkedja, och @th,64,32 läser de första fyra byten bakom UDP-huvudet. Med klassiska iptables uppnår en jämförelse mot kännetecknet för A2S_INFO samma åtskillnad:

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

Tio förfrågningar per sekund och adress är generöst tilltaget: en listtjänst frågar vanligtvis med några minuters mellanrum, inte flera gånger per sekund. Viktigt är bara att den här regeln står på 27015 och inte på 8211, annars träffar du dina egna spelare.

5. Begränsa paketfrekvensen på 8211 UDP

På själva spelporten hjälper ett tak per källadress mot små floder från få källor. Hos Palworld är den gränsen jämförelsevis ofarlig att sätta, eftersom högst 32 spelare är anslutna samtidigt och var och en av dem upptar exakt en källadress:

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

Siffran är ett startvärde, ingen sanning. En full server med 32 spelare och många baser skapar betydligt fler paket än en omgång med fyra, och den som ställer in för snävt kastar ut sina egna spelare. Mät först en vecka i normal drift, sätt sedan gränsen till det dubbla av det uppmätta toppvärdet.

Rena iptables-regler är borta efter en omstart. Under Debian och Ubuntu säkrar du dem så här:

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

Under UFW hör sådana regler dessutom hemma i /etc/ufw/before.rules, eftersom de annars försvinner vid nästa ufw reload. Om en regel över huvud taget nås visar iptables -L INPUT -n -v: stannar träffräknarna på noll griper den inte.

6. Serverlösenord, bannlista och de 32 platserna mot platsutmattning

Platsutmattning är den billigaste attacken mot en Palworld-server och behöver ingen bandbredd. En dedikerad server har högst 32 platser, alltså räcker 32 samtidiga anslutningar för att stänga ute hela gemenskapen. En volymetrisk attack kostar uppdragsgivaren pengar, 32 sessioner kostar honom ingenting. Det gör den vägen mer attraktiv för små servrar än någon flod.

Palworld har ingen inbyggd vitlista. Moderationsverktygen är kick, bannlysning och ett serverlösenord, och just serverlösenordet är den verksammaste enskilda åtgärden mot platsutmattning:

ServerPassword="ett värde som bara din grupp känner till"
ServerPlayerMaxNum=32
bShowPlayerList=True
BanListURL="https://api.palworldgame.com/api/banlist.txt"

ServerPassword är tomt som standard, alla med IP-adress och port kommer alltså in. BanListURL pekar som standard på den lista som Pocketpair underhåller och går att peka om till en egen textfil om du vill föra projektegna spärrar. ServerPlayerMaxNum sätter du inte över 32: högre värden stöds inte och hämnar sig senast vid nästa uppdatering. Och en sak måste stå klar: ett serverlösenord skyddar dina platser, inte din uppkoppling. En angripare som översvämmar din server vill inte ansluta alls.

7. Avlasta anslutningsspårningen och förstora buffertarna

Den här punkten förklarar avbrott som ser ut som en volymattack men inte är det. Kärnan lägger upp poster i anslutningsspårningen (conntrack) för UDP-trafik, och vid förfalskade avsändaradresser betyder varje adress en ny post. Är tabellen full kasserar kärnan paket utan åtskillnad, attacken och dina spelare åker ut tillsammans, och i systemloggen står "nf_conntrack: table full". Läge och tak visar:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

Det verksammaste steget är att inte låta speltrafiken spåras alls, för Palworld förvaltar sina sessioner själv:

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
    }
}

Med iptables lyder motsvarigheten iptables -t raw -A PREROUTING -p udp --dport 8211 -j NOTRACK och samma rad för OUTPUT med --sport. Portarna behöver därefter en uttrycklig öppning, för utan spårning griper ingen regel längre som prövar mot ett befintligt tillstånd. Kommer paketen fram snabbare än serverprocessen hämtar dem svämmar dessutom mottagningsbufferten över. För spelarna ser det ut som paketförlust trots att uppkopplingen är ledig. Ett tillägg under /etc/sysctl.d/, aktiverat med sysctl -p:

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

Om värdena behövs avslöjar kärnan själv: stiger UdpRcvbufErrors i nstat -az, då griper de. Stannar räknaren på noll ändrar justeringen ingenting.

8. Samla mätvärden innan det blir allvar

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

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"

För tcpdump gäller: begränsa alltid med -c, en inspelning under full last belastar en redan överbelastad server ytterligare. Palworld levererar dessutom ett mätvärde som inget annat verktyg har. Är REST-API:t aktiverat returnerar mätvärdesslutpunkten bland annat serverns bildfrekvens, det aktuella spelarantalet och drifttiden:

curl -s -u admin:DITT_ADMINLÖSENORD http://127.0.0.1:8212/v1/api/metrics

Den enda siffran skiljer de två vanligaste orsakerna rent från varandra. Faller serverns bildfrekvens medan paketfrekvenserna förblir oanmärkningsvärda är det ingen attack utan last, eller den kända minnesökningen i serverprocessen. Håller sig bildfrekvensen stabil medan de inkommande paketen stiger långt över normalvärdet är det en attack. Hur du tolkar nätverksvärdena i detalj står i Känna igen en DDoS-attack på servern.

Var de här åtgärderna tar slut: bandbredd och paketfrekvens

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 gått över kabeln. Du kan kassera 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 uppkopplingen är full så fort någon skickar mer. Attacker mot spelserverprojekt ligger vanligtvis mellan 5 och 50 Gbit/s, alltså på fem till femtio gånger din uppkoppling. Om din iptables-regel bakom den är bra spelar då ingen roll längre, för dina spelares paket kommer inte fram redan innan dess.

Den andra storheten är paketfrekvensen, och den slår ofta till tidigare än bandbredden. Vid små paket på 64 byte ryms runt 1,49 miljoner paket per sekund i en uppkoppling på 1 Gbit/s. En vanlig serverkärna bearbetar beroende på processor och nätverkskort några hundratusen av dem innan den börjar kassera. En attack som inte ens fyller en tredjedel av din uppkoppling kan alltså ändå lamslå din server, eftersom beräkningstiden går åt till att kassera. Operatörer upplever det som "belastningen var ju inte ens hög, ändå var allt borta", och hos Palworld yttrar det sig först som lagg-spikar och först därefter som avbrutna anslutningar.

Hos en Palworld-server kommer ett ogynnsamt förhållande till. En fullsatt server med 32 spelare belastar bara en bråkdel av en uppkoppling på 1 Gbit/s. Attacken måste alltså inte vara stor för att nå ett mångdubbelt av den normala driften, och just därför räcker här redan attacker som inte skulle märkas på en stor plattform.

Till inordningen av vilka storleksordningar som faktiskt 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 mot en spelserver filtrerats. För det finns ingen lokal inställning. Volymetriska attacker måste ta slut i nätet framför servern.

Vad KernelHost ställer emot

Det permanenta skyddet som ingår i varje serverpaket

DDoS-skyddet från KernelHost är uppbyggt i två steg och permanent aktivt, utan att du behöver slå på, beställa eller konfigurera något:

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

Två egenskaper är avgörande. Skyddet löper permanent och måste inte först reagera på en attack, det finns alltså inga minuter i början där servern är borta. Och ingen null-routning används: din IP-adress stannar i nätet, bara de skadliga paketen kasseras. Den som tar bort IP-adressen ur nätet åstadkommer för dig samma resultat som angriparen. Palworld hör till de spel som har en egen skyddsprofil, vilka ytterligare titlar och protokoll som täcks listas i DDoS-skydd för spelservrar i realtid.

Advanced DDoS Protection för Palworld-projekt under ständig beskjutning

Vissa projekt angrips inte då och då, utan riktat och under veckor. För det finns Advanced DDoS Protection från 50,00 EUR i månaden, PrePaid, utan bindningstid och utan uppläggningsavgift. Skillnaden ligger inte i mer kapacitet utan i kontrollen:

• Dedikerad skydds-IP ur Frankfurt-kärnan, som din server ställs om till i vårt eget nät. På din sida behövs ingen ombyggnad.
• Skyddsregler per port och protokoll som du förvaltar själv i kundportalen: du fastställer separat vad som är tillåtet på 8211 UDP och vad som gäller på 27015 UDP, utan att skriva ett ärende för det.
• Ändringar griper i realtid, du kan alltså justera under en pågående attack, till exempel begränsa query-porten hårdare en tid och lämna spelporten orörd.
• Skyddsprofil anpassad till spelet, för Palworld lika väl som för egna applikationer på godtyckliga TCP- eller UDP-portar.

Advanced DDoS Protection riktar sig till servrar som står hos KernelHost. Den som för närvarande driver sitt Palworld-projekt någon annanstans och angrips varaktigt flyttar det till KernelHost, då griper båda stegen från leveransen.

De båda stegen i jämförelse

För de flesta Palworld-servrar 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 hos Palworld-servrar och deras lösning

"Jag spärrade 27015 och nu har servern försvunnit ur community-listan": det är det förväntade beteendet, för query-porten bär posten i listan. Spärra den inte generellt, utan begränsa de anslutningslösa paketen per källadress som i steg 4. Behöver du ändå inte posten i listan lämnar du porten stängd, stryker -publiclobby och ger dina spelare IP-adress och port 8211 för direktanslutningen.

"Jag bytte IP-adress och var offline igen två timmar senare": angriparen har den nya adressen ur samma källa som den gamla. Hos Palworld är det nästan alltid en av tre vägar: en spelare som ändå har adressen stående i fältet för direktanslutning, en Discord-bot med statusvisning som publicerar den på nytt, eller en gammal A-post i DNS som pekar på den tidigare adressen. Ett adressbyte är tidsvinst, ingen lösning.

"Servern har lagg-spikar, men uppkopplingen är lugn": hos Palworld är det oftare last än attack. Serverprocessen tar över drifttiden stadigt mer arbetsminne i anspråk, varför en planerad omstart hör till den normala driften och inte ska förstås som en nödlösning. Kontrollera serverns bildfrekvens via mätvärdesslutpunkten och processens minnesförbrukning. Förblir sar -n DEV 1 10 oanmärkningsvärd var det ingen DDoS-attack.

"Alla 32 platser är upptagna, men i spelet syns ingen": det är platsutmattning och träffar spellogiken, inte uppkopplingen. Sätt ett ServerPassword, spärra de påfallande kontona via bannlistan och begränsa paketen per källadress på 8211 UDP.

"REST-API:t var nåbart utifrån i några dagar": då är ditt administrationslösenord komprometterat, för HTTP Basic Auth över okrypterad HTTP överför det vid varje förfrågan i vändbar form. Ändra AdminPassword, stäng 8212 TCP utåt och nå gränssnittet enbart via en SSH-portvidarebefordran.

"Mina iptables-regler griper inte": tre orsaker är vanliga. Reglerna står bakom UFW-kedjorna och nås aldrig, de var borta efter den senaste omstarten (då hjälper netfilter-persistent save eller en post i /etc/ufw/before.rules), eller så är attacken volymetrisk och regeln arbetar korrekt vid en uppkoppling som redan är full. Kontrollera med iptables -L INPUT -n -v om träffräknarna stiger.

"Min tidigare leverantör spärrade min IP-adress": det är null-routning. Leverantören skyddar därmed sitt eget nät, för dig är resultatet identiskt med en lyckad attack, oftast i ytterligare timmar efteråt. Fråga vid tveksamhet efter om det filtreras eller null-routas. Svaret avgör mer om din tillgänglighet än någon hårdvaruuppgift.

"I tcpdump ser jag inget anmärkningsvärt": om trafiken redan filtreras i nätet framför kommer det som väntat ingenting fram till servern. Det är normalfallet vid fungerande filtrering. Omvänt gäller: är uppkopplingen mättad når under vissa omständigheter inte ens SSH-sessionen fram, den du ville mäta med. Använd då VNC-konsolen i kundportalen, som fungerar oberoende av gästsystemets nätverk.

Kort sammanfattat

• En Palworld-server behöver exakt en öppen port: 8211 UDP. Query-porten 27015 UDP behövs bara för posten i community-serverlistan.
• RCON på 25575 TCP och REST-API:t på 8212 TCP hör aldrig hemma i det öppna nätet, för båda överför sina inloggningsuppgifter okrypterat. RCON är dessutom markerat som föråldrat av Pocketpair.
• Eftersom speltrafik och serverförfrågan ligger på skilda portar hos Palworld går 27015 UDP att begränsa hårt utan att röra den löpande speltrafiken på 8211 UDP.
• Den dedikerade servern är begränsad till 32 platser, därför är platsutmattning den billigaste attacken. Ett satt ServerPassword är den verksammaste enskilda åtgärden mot den, för Palworld har ingen inbyggd vitlista.
• Lokala åtgärder tar slut vid uppkopplingen: 1 Gbit/s är 125 megabyte per sekund, och vid 64 byte stora paket ryms där runt 1,49 miljoner paket per sekund. Allt däröver måste ta slut i nätet framför servern.
• Hos KernelHost ingår det permanenta skyddet i två steg i varje serverpaket utan extra kostnad och är aktivt från leveransen, utan null-routning. Advanced DDoS Protection med dedikerad skydds-IP och egenförvaltade regler per port börjar på 50,00 EUR i månaden.

Körs din Palworld-server redan hos KernelHost är filtreringen aktiv utan att du behöver göra något. Märker du ändå något avvikande, öppna ett supportärende så att filterreglerna för din IP-adress justeras. Vid en pågående attack når du oss dessutom via WhatsApp-nödchatten på +43 650 8209883.