Mi az a DDoS-támadás? Technika, szintek és védelem

A DDoS-támadás az a kísérlet, hogy egy szolgáltatást mesterségesen előállított túlterheléssel elérhetetlenné tegyenek, mégpedig nagyon sok különböző feladó egyidejű közreműködésével. A rövidítés a Distributed Denial of Service kifejezést takarja, vagyis az elosztott módon kikényszerített szolgáltatásmegtagadást. A támadás nem a szerver tartalma és nem a szoftverének biztonsági hibája ellen irányul, hanem egy olyan erőforrás ellen, amely véges: a vonal sávszélessége, a hálózati kártya csomagsebessége, egy hely a kernel valamelyik állapottáblájában, vagy az a processzoridő, amelyet az alkalmazás egyetlen kérésre fordít. Ha ez a négy erőforrás közül bármelyik betelik, a valódi felhasználók már nem jutnak át, méghozzá anélkül, hogy bárki betört volna a rendszerbe.

Ez a cikk a téma belépőpontja. Elmagyarázza azt a három szintet, amelyen a támadások zajlanak, azt, milyen erősítési tényezőkkel lesz egy bájt kérésből 51 000 bájt válasz, azt, honnan jön a támadási kapacitás és mennyibe kerül a piacon, azt, miről ismeri fel a támadást a saját mérési értékeiből, azt, mi segít még magán a szerveren, és azt, hol fut pontosan ez a határ. Minden szám forrásmegjelöléssel szerepel, hogy Ön utána tudjon nézni. Ha a szolgáltatása éppen áll, először a „Mit kell tenni támadás esetén” szakaszt olvassa el, és mérjen, ne csavarozzon.

Mi technikailag a DDoS-támadás

Minden DDoS-támadás egy aszimmetriából él: egy csomag elküldése kevesebbe kerüljön a támadónak, mint amennyibe a célnak kerül ennek a csomagnak a feldolgozása. Minden más csak az a kérdés, hol a legnagyobb ez az aszimmetria. Pontosan négy ilyen hely van, és mindegyiknek megvan a maga kemény felső határa, amely kiszámítható.

A vonal sávszélessége. Egy 1 Gbit/s-os csatlakozás másodpercenként 125 megabájtot szállít, többet nem. Aki ennél többet küld, veszteséget okoz, és a veszteség ugyanúgy éri a felhasználói csomagjait, mint a támadóéit, mert egy tele vonal nem válogat.

A csomagsebesség. A legkisebb megengedett Ethernet-csomag 64 bájt hosszú, és a preambulummal és a csomagközi réssel együtt 84 bájtot foglal a vonalon. Ebből 1 Gbit/s-ba nagyjából 1,49 millió fér másodpercenként. Egy szokásos szerverkernel processzortól és hálózati kártyától függően néhány százezret dolgoz fel, mielőtt eldobni kezd. A csomagsebesség ezért szinte mindig az a határ, amelyet a sávszélesség előtt érünk el.

Az állapottáblák. A kernel megjegyzi a félig nyitott TCP-kapcsolatokat és a csomagfolyamokat. Ezek a táblák számszerűen korlátozottak, nem bit per másodpercben. Nagyon kevés sávszélességgel is megtölthetők, ha minden csomag új feladócímet hordoz.

Az alkalmazás processzorideje. Egy keresés, egy jelszóellenőrzéssel járó bejelentkezési kísérlet vagy egy olyan szerverlekérdezés, amely egy teljes modlistát ad vissza, ezerszer többe kerül a célnak, mint a feladónak. Itt egy hatásos támadásnak gyakran még 10 Mbit/s sem kell.

DoS és DDoS: a különbség, amely mérhető

A fogalmi alapot az RFC 4732 adja, a „Internet Denial-of-Service Considerations” című, 2006 novemberéből származó tájékoztató jellegű IETF-kiadvány. Ott szó szerint ez áll: „A Denial-of-Service (DoS) attack is an attack in which one or more machines target a victim and attempt to prevent the victim from doing useful work.” A DoS-támadás tehát a hatásán keresztül van meghatározva, nem a források számán keresztül. Elosztott, vagyis DDoS akkor, ha ezek a források nagy számban és egymástól függetlenül vannak jelen.

A gyakorlatban a különbség pontosan egy helyen számít: a tiltólistája hosszánál. Az egyetlen forrásból érkező DoS-támadást egy szabállyal lezárja. A Cloudflare 2025 májusában dokumentált egy támadást, amely 122 145 különböző forráscímről érkezett 161 országból és 5433 autonóm rendszerből, átlagosan másodpercenként 26 855 új címmel, csúcson 45 097-tel. Ilyen ellen nincs olyan tiltólista, amely elég gyorsan nő, és minden bejegyzése ráadásul memóriát és keresési időt kér attól az eszköztől, amely már úgyis túl van terhelve.

A CISA, az FBI és az MS-ISAC közös útmutatója, az „Understanding and Responding to Distributed Denial-of-Service Attacks” pontosan három technikára osztja a támadásokat: volumetrikus, protokollra irányuló és alkalmazásra irányuló. Ez a hármas felosztás a leghasznosabb, ami létezik, mert egyszerre leírja azt is, hogy az Ön négy erőforrása közül melyiket támadják, és azt is, hol kell ülnie a védelemnek.

Egy DDoS-támadás három szintje

Volumetrikus támadások a 3. és a 4. rétegen

Egy volumetrikus támadás semmi mást nem akar, mint megtölteni a cél előtti vonalat. A mérés bit per másodpercben történik. Az eszköz többnyire egy UDP-flood, mert az UDP nem ismer kapcsolatfelépítést, amelyet meg lehetne követelni, és mert a feladócímek hamisíthatók.

A jelenleg legnagyobb, nyilvánosan dokumentált példa: a Cloudflare a 2025 végéig tartó időszakra egy automatikusan elhárított, 31,4 Tbit/s-os támadást jelent, amely 35 másodpercig tartott. Ez nagyjából 31 400 darab 1 Gbit/s-os szervercsatlakozás kapacitása, egyszerre, egy jó félpercre. Ugyanabban a jelentésben szerepel egy második érték, amely a nagyságrendet jobban megfoghatóvá teszi, mint a csúcsérték: 2025-ben ugyanez az üzemeltető 47,1 millió DDoS-támadást hárított el, ami 121 százalékos növekedés az előző évhez képest, átlagosan óránként 5376 támadás.

A 2025 májusából származó, jobban dokumentált eset megmutatja, hogyan néz ki egy ilyen támadás, ha szétszedjük: csúcson 7,3 Tbit/s, 37,4 terabájt adat 45 másodperc alatt, ez átlagosan nagyjából 830 gigabájt másodpercenként. Egy 1 Gbit/s-os vonalnak ugyanehhez az adatmennyiséghez jó három napra lett volna szüksége. A forgalom 99,996 százaléka tiszta UDP-flood volt, átlagosan 21 925 célport között elosztva egyidejűleg, csúcson 34 517 között. Ez a portokra való szétterülés jellemző: a támadó nem tudja, melyik port a fontos, tehát mindet elviszi.

Protokolltámadások: a táblák, nem a vonal

Egy protokolltámadás azt használja ki, hogy a kernelnek állapotokat kell megjegyeznie. A tankönyvi példa a SYN-flood: a támadó beállított SYN-bittel és hamisított feladócímmel küld TCP-csomagokat, a szerver mindegyikhez bejegyzést hoz létre a félig nyitott kapcsolatok várólistájában, SYN-ACK-kal válaszol egy olyan címre, amely soha nem szólt, és vár. A mérés itt csomag per másodpercben történik, nem gigabitben.

Ennek a várólistának a hossza a net.ipv4.tcp_max_syn_backlog értékben áll, és egy szokásos szerveren négyjegyű tartományban van. Egy 1024 helyet kínáló várólista másodpercenként 1,49 millió SYN-csomag mellett kevesebb mint egy milliszekundum alatt tele van. Ehhez puszta számítás szerint 1 Gbit/s elég, és ha csak a tábla a cél, akkor ennek egy törtrésze is.

Ugyanebbe a családba tartozik egy eljárás, amelyet csak 2021-ben írtak le: a TCP-reflexió állapotkövető közbenső eszközökön keresztül. A „Weaponizing Middleboxes for TCP Reflected Amplification” című munka megmutatja, hogy azok a tűzfalak és cenzúrainfrastruktúrák, amelyek a TCP-állapotot csak félig követik, egyetlen hamisított csomagra teljes oldalakkal válaszolnak. Ezzel először a TCP is visszaélésre használható erősítésre, amit addig gyakorlatilag lehetetlennek tartottak.

Alkalmazástámadások a 7. rétegen

Egy alkalmazástámadás úgy néz ki, mint a szokásos forgalom, mert szokásos forgalom, csak rossz mennyiségben. A mérés kérés per másodpercben történik. Teljesen felépített kapcsolaton érkezik, tehát túlél minden olyan ellenőrzést, amely csak a kapcsolatfelépítést értékeli, és kevés sávszélességet kér: másodpercenként 10 000 HTTP-kérés a kérésmérettől függően kevesebb mint 50 Mbit/s, és mégis elég ahhoz, hogy egy adatbázist térdre kényszerítsen.

Ennek a mérőléce a HTTP/2 Rapid Reset, amelyet 2023. október 10-én hoztak nyilvánosságra CVE-2023-44487 néven. A sebezhetőség a HTTP/2 multiplex képességében rejlik: a támadó megnyit egy adatfolyamot, elküldi a kérést, és a folyamot azonnal meg is szakítja. A szerver a munkát már elkezdte, a támadónak viszont azonnal újra szabad helye van az ablakban. Az így elért értékek másodpercenként 201 millió kérésnél (Cloudflare), 398 milliónál (Google) és 155 milliónál (Amazon) álltak. Összehasonlításképpen: a Cloudflare addigi legnagyobb mért 7. rétegbeli támadása másodpercenként 71 millió kérésnél állt.

Játékszerverek esetében a 7. réteg maga a kapcsolatfelépítés. A Minecraft-hálózatok ellen irányuló nullping, QuietException és hamis kézfogásos áradatok szinte semmilyen sávszélességet nem kérnek, és teljes proxy-együtteseket fektetnek le, mert minden csomag drága állapotdöntésre kényszeríti a proxyt. Hogy ezek a minták pontosan hogyan néznek ki, az a Minecraft-DDoS-védelem és nullping-védelem című cikkben áll.

A három szint összehasonlítása

A valódi támadások nem tartják magukat ehhez a felosztáshoz. A gyakorlatban a legkellemetlenebb eset a többrétegű támadás: egy volumetrikus rész, amely a vonalat foglalja, és mellé egy 7. rétegbeli rész, amely éppen akkor jut át, amikor a figyelem a sávszélességen van. A lentebb bemutatott, a KernelHostnál kiszűrt támadások egyike egyidejűleg több mint tizenkét különböző fő mintából állt.

Erősítéses támadások: hogyan lesz egy bájtból 51 000

Az erősítéses támadás olyan támadás, amelynél a támadó nem saját maga lő a célra, hanem idegen, nyilvánosan elérhető szolgáltatásokat vesz rá arra, hogy megtegyék ezt helyette. Egy kis kérést küld egy nyitott szolgáltatásnak, és feladóként az áldozat IP-címét írja be. A szolgáltatás kötelességtudóan válaszol, csak éppen az áldozatnak, a válasz pedig a kérésnek a többszöröse.

A válaszméret és a kérésméret közötti arányt Bandwidth Amplification Factornak, röviden BAF-nak nevezik. Az 50-es BAF azt jelenti, hogy egy 1 Gbit/s-os saját csatlakozással rendelkező támadó 50 Gbit/s-ot irányít a célra. Két dolognak kell találkoznia, hogy ez működjön: egy UDP fölötti protokollnak, amely többet válaszol, mint amennyit kérdeznek tőle, és annak a lehetőségnek, hogy a feladócím hamisítható legyen. Az IP-spoofing ezért minden erősítéses támadás előfeltétele, és nem csupán elrejtőzési taktika.

A védőnek ebből egy kellemetlen tulajdonság következik: a forgalom valódi, jogszerű szerverekről érkezik. Valódi DNS-feloldók, valódi időszerverek, valódi játékszerverek ezek. A forráscím szerinti tiltólista tehát vagy fél országokat zár ki, vagy nem hat.

A visszaélésre használt protokollok erősítési tényezői

A következő tényezők az US-CERT, illetve a CISA TA14-017A jelű riasztásából származnak, amelynek címe „UDP-Based Amplification Attacks”, és amelyet 2014 óta folyamatosan bővítenek. Ez az a hivatkozási alap, amelyre az egész szakma hivatkozik.

A táblázat megmagyarázza, miért néz ki minden jól gondozott tűzfalban hasonlóan a lezárt portok listája. Amit Ön maga tehet, az áttekinthető, de fontos: ellenőrizze az ss -lnup paranccsal, hogy nem áll-e a szerverén nyitva a hálózat felé valamelyik szolgáltatás ebből a táblázatból. Egy memcached, amely nincs a 127.0.0.1 címre kötve, fegyverré teszi a szerverét harmadik felek ellen, elviszi a saját kimenő sávszélességét, és olyan tiltólistákra kerül tőle az IP-címe, amelyekről nehéz visszakerülni.

Miért tartoznak ide a játéklekérdező protokollok

A játékszerverek két szereppel állnak ebben a táblázatban. Erősítők, mert a lekérdezőportjuk egy kis csomagra névvel, térképpel, játékosszámmal és a teljes modlistával válaszol. És áldozatok, mert ugyanez a lekérdezés processzoridőt kér, gyakran pontosan azon a magon, amely a játékszimulációt viszi.

A Steam-protokoll erősítési tényezője 5,5-tel alacsonyan, a régebbi Quake-protokollé 63,9-cel magasan áll. A hatás azonban nem a tényezőn múlik egyedül, hanem az egyes esetek válaszméretén: egy 200 moddal futó szerver lényegesen nagyobb választ ad, mint egy mod nélküli. A Bohemia Interactive 2015 óta dokumentálja az Arma 3-hoz a T83469 jegy alatt, hogy már 4 Mbit/s hamisított lekérdezés a Steam-query-portra elegendő volt egy szerver befagyasztásához. Négy megabit per másodperc kevesebb, mint amennyit egyetlen háztartási csatlakozás előállít.

Ebből következik a szabály, amely minden játékra érvényes: a lekérdezőportot korlátozni kell, nem lezárni. Aki lezárja, eltűnik a szerverlistából, és az új játékosok nem találják meg többé. Hogy melyik port ez játékonként, és mennyire szorosan fogható, az a lentebbi, játékspecifikus cikkekben áll, például az Arma 3, a CS2 és a Source-címek vagy a Rust esetében.

A memcached esete: 1,35 Tbit/s a GitHub ellen

2018. február 28-án a GitHub 17:21-től 17:26 UTC-ig nem volt elérhető, és 17:30 UTC-ig is csak időszakosan. A támadás 1,35 Tbit/s-ot ért el másodpercenként 126,9 millió csomag mellett, és több mint 1000 különböző autonóm rendszerből, valamint több tízezer egyedi végpontról érkezett. Az erősítés memcacheden keresztül történt, akár 51 000-es tényezővel: a támadó egy bájtja akár 51 kilobájtot állított elő a cél irányában.

Ez az eset a mai napig a legjobb tanulópénz, mert három dolgot mutat meg egyszerre. Először: az erősítés legyőzi a botnetméretet. A támadónak nem kellett százezer eszköz, nyitott memcached-példányok kellettek, amelyekből akkor világszerte több mint 90 000 állt a hálózatban. Másodszor: másodpercenként 126,9 millió csomag nagyjából 85-szöröse annak, amennyit egy 1 Gbit/s-os vonal egyáltalán szállítani képes. Ezen a szerveren semmilyen beállítás nem változtat. Harmadszor: a védelem azért működött, mert a forgalmat egy szűrőhálózatba térítették el, és a kiesés így kilenc perccel ért véget, nem kilenc órával.

Honnan jön egy DDoS-támadás kapacitása

Botnetek átvett eszközökből

A botnet idegen, kártékony szoftverrel átvett eszközök együttese, amelyet a támadó központilag távvezérel. A tulajdonosok ebből többnyire semmit nem észlelnek, mert az eszköz továbbra is azt teszi, amiért megvásárolták. Elsősorban azokat az eszközöket támadják, amelyek tartósan a hálózaton vannak, ritkán kapnak frissítést és gyári jelszót hordoznak: routerek, megfigyelőkamerák, hálózati rögzítők, tévéboxok.

A mérőléc a Mirai, amelynek forráskódját 2016 szeptemberének végén hozták nyilvánosságra. Az „Understanding the Mirai Botnet” című munka (USENIX Security 2017) hét hónapon át követte a hálózatot, és a csúcsértéket több mint 600 000 fertőzött eszközre teszi. A Brian Krebs oldala ellen 2016 szeptemberében indított támadás 620 Gbit/s-ot ért el, és több mint 175 000 eszközről érkezett. A Dyn nevű DNS-üzemeltető ellen 2016. október 21-én indított támadásnál, amely a Twittert, a Spotifyt és a Redditet egyszerre tette elérhetetlenné, nagyjából 107 000 támadó IP-címet számoltak össze.

Kilenc évvel később más a nagyságrend. A Cloudflare a 31,4 Tbit/s-os csúcstámadást egy olyan botnetre vezeti vissza, amelynek becsült nagysága egy és négy millió fertőzött eszköz között van, túlnyomórészt Android-tévéboxok. A 2025 decemberi támadási hullámban 902 hipervolumetrikus támadást számoltak össze, naponta átlagosan 53-at, csúcsértékekkel másodpercenként 9 milliárd csomagnál, 24 Tbit/s-nál és másodpercenként 205 millió kérésnél. A botnetméret ezzel egy évtized alatt ötszörösére, az elért sávszélesség pedig ötvenszeresére nőtt.

Booter- és stresser-szolgáltatások, és mennyibe kerül egy támadás

A botnet és a megbízó között egy szolgáltatás ül, amely előfizetésben adja el a támadási kapacitást. Ezek a szolgáltatások „booter”, „stresser” vagy „IP-stresser” néven jelennek meg, és a felhasználási feltételeikben azt állítják, hogy saját rendszerek terheléses tesztelésére szolgálnak. Soha nem ellenőrzik közben, hogy a beírt cél a felhasználóé-e, és pontosan ez a különbség egy szerszám és egy ajánlat között.

A kezelés egy háromfeldolgozó webes felület: cél, port, időtartam. Van hozzá fizetési folyamat, ügyfélszolgálat és viszonteladói program. A belépő csomagok havonta nagyjából 10 és 20 euró között állnak, a több sávszélességet és hosszabb támadási időt kínáló nagyobb csomagok havonta néhány száz eurónál. Ezzel megválaszoltuk azt a kérdést is, miért érinti ez a kis projekteket is: az a támadás, amely egy játékszervernek a szombat estébe kerül, a kiváltójának kevesebbe kerül két mozijegynél, és semmilyen technikai tudást nem kér.

A másik oldalon tartós üldözési nyomás áll. A nemzetközi PowerOFF művelet 2026 áprilisi akcióhetén 21 ország hatóságai 53 domaint vettek át ilyen szolgáltatásoktól, négy személyt tartóztattak le, és 25 házkutatást tartottak. A nyomozók ennek során több mint hárommillió felhasználói fiók adataihoz szereztek hozzáférést, és több mint 75 000 azonosított felhasználót írtak meg. 2024 decemberében ugyanebben a műveletben 27 platformot kapcsoltak le. Aki egy ilyen szolgáltatást kifizet, az tehát fizetési nyomot hagy egy adatbázisban, amelyet előbb vagy utóbb lefoglalnak.

Miről ismeri fel a DDoS-támadást

Amit a felhasználók jelentenek, és amit az már elárul

Az első információ szinte mindig a felhasználóktól jön, és hasznosíthatóbb, mint amilyennek hangzik. Négy jelentésnek világos jelentése van:

• „Mindenki egyszerre esett ki.” Az egyidejű megszakadás minden felhasználónál a vonalra vagy a szolgáltatásfolyamatra utal, nem egyes kapcsolatokra. A terhelési probléma egymás után éri a felhasználókat.
• „A ping 20-ról 400-ra ugrik és vissza.” Az ingadozó futási idő fennálló kapcsolat mellett a cél előtti túltelt várólista mintája, nem egy túlterhelt folyamat mintája.
• „A szerverlista offline-ként mutat minket, én mégis be tudok kapcsolódni.” Ez a lekérdezési áradatra mutató ujj: a lekérdezőport már nem válaszol, a játékport még igen.
• „Mobilhálózaton bejutok, a saját csatlakozásomon nem.” A hozzáférési hálózat szerint eltérő viselkedés arra utal, hogy nem a szervere, hanem egy odavezető út telített.

A négy mérési érték a szerveren

Utána mérünk, mégpedig ebben a sorrendben: csomagsebesség, sávszélesség, kapcsolatállapotok, eldobási számlálók. A processzor kihasználtsági kijelzése jön utolsóként, mert hálózati támadás esetén gyakran feltűnésmentes marad.

sar -n DEV 1 10
ip -s link show eth0
ss -s
ss -tn state syn-recv | wc -l
nstat -az TcpExtListenDrops TcpExtListenOverflows TcpExtTCPReqQFullDrop UdpRcvbufErrors UdpInErrors UdpNoPorts
cat /proc/sys/net/netfilter/nf_conntrack_count /proc/sys/net/netfilter/nf_conntrack_max

A sar -n DEV 1 10 tíz másodpercen keresztül adja meg a csomagokat és a bájtokat másodpercenként, interfészenként. A döntő az arány: sok csomag kevés bájt mellett kis csomagokat jelent, tehát protokolltámadást. Kevés csomag nagyon sok bájt mellett nagy csomagokat jelent, tehát erősítéses támadást. Az ip -s link show a dropped és az overrun oszlopban mutatja, hogy a kernel már eldob-e. Az ss -tn state syn-recv a félig nyitott kapcsolatokat számolja: a háromjegyű érték normális, az ötjegyű SYN-flood. Az nstat pedig azokat a számlálókat adja, amelyek a támadás elmúltával is megmaradnak.

A legfontosabb lépés az, amelyet előre szinte senki nem tesz meg: összehasonlítási alapot felvenni, amíg minden normálisan fut. Normálérték nélkül nem tudja megmondani, hogy a másodpercenkénti 40 000 csomag sok-e, vagy egyszerűen szombat este. Az apt-get install -y vnstat sysstat paranccsal a mérés tartósan fut. A kiértékelés részletes útmutatója a DDoS-támadás felismerése című cikkben áll.

A naplósorok, amelyek egyértelműek

Négy üzenet a kernelnaplóban és a webszerver naplójában gyakorlatilag bizonyító erejű. A dmesg -T | tail -50 az első hármat mutatja:

kernel: TCP: request_sock_TCP: Possible SYN flooding on port 443. Sending cookies.  Check SNMP counters.
kernel: nf_conntrack: nf_conntrack: table full, dropping packet
kernel: net_ratelimit: 2247 callbacks suppressed
nginx: [alert] 1123#1123: 768 worker_connections are not enough

Az első sor azt jelenti, hogy a félig nyitott kapcsolatok várólistája túlcsordult, és a kernel átváltott SYN-cookie-kra. Ha ott ehelyett Dropping request áll, akkor a net.ipv4.tcp_syncookies 0-ra van állítva, és a szerver eldobja a kéréseket, a valódiakat is beleértve. A második sor azt jelenti, hogy a kapcsolatkövetés tele van, és ettől a pillanattól a szerver a jogszerű forgalmat is eldobja. A harmadik sor melléktermék: a kernel elnyomja az üzeneteket, mert különben naplózással lenne elfoglalva. A negyedik sor az alkalmazásba tolja a problémát.

A webszerver hozzáférési naplójában két dolog árulkodó. A 499-es státuszkód hirtelen megjelenő aránya azt jelenti, hogy a kliens lezárja a kapcsolatot, mielőtt a válasz elkészülne, és pontosan ezt teszi az a 7. rétegbeli támadás, amely csak munkát akar kiváltani, olvasni nem. A szinte minden kérésnél üres referer-mező pedig megkülönbözteti a támadást a valódi látogatórohamtól, amely keresőmotoroktól és közösségi hálózatokról hoz magával referert.

Az ellenpróba: támadás, roham vagy saját hiba

Mi segít magán a szerveren

A szerveren többet lehet elérni, mint amit gyakran állítanak, mégpedig mindaz ellen, ami kicsi marad: rendetlen botok, egyes források, lekérdezési áradatok és alkalmazástámadások. Az ehhez tartozó szerszámok az nftables, a kapcsolatkövetés, a SYN-cookie-k és a forráscímenkénti sebességkorlátozás. Az összes következő adat Debian 12, Debian 13, Ubuntu 22.04 LTS és Ubuntu 24.04 LTS alatt érvényes, és root felhasználóhoz készült.

nftables: korán eldobni, keveset számolni

Az alapelv így hangzik: azt a csomagot, amelyet eldobunk, olyan korán és olyan olcsón kell eldobni, amennyire csak lehet. Minden szabály, amely előtte fut, processzoridőbe kerül, a csomagsebességgel felmultiplikálva. A következő, az /etc/nftables.conf fájlba való szabályrendszer egy webszervert és egy játékszolgáltatást átenged, a többit eldobja, forráscímenkénti sebességkorlátozással az új TCP-kapcsolatokra:

#!/usr/sbin/nft -f

flush ruleset

table inet filter {
    set adminips {
        type ipv4_addr
        flags interval
        elements = { 203.0.113.10 }
    }

    set newconn {
        type ipv4_addr
        size 131072
        flags dynamic,timeout
        timeout 1m
    }

    chain input {
        type filter hook input priority filter; policy drop;

        iif lo accept
        ct state established,related accept
        ct state invalid counter drop

        ip saddr @adminips tcp dport 22 accept

        tcp dport { 80, 443 } ct state new add @newconn { ip saddr limit rate over 30/second burst 60 packets } counter drop
        tcp dport { 80, 443 } accept

        udp dport 25565 accept

        icmp type echo-request limit rate 5/second accept
        icmpv6 type { echo-request, nd-neighbor-solicit, nd-neighbor-advert, nd-router-solicit, nd-router-advert } accept

        counter drop
    }

    chain forward { type filter hook forward priority filter; policy drop; }
    chain output  { type filter hook output  priority filter; policy accept; }
}

Az adminips alá írja be a saját fix címét, mielőtt betölti, különben kizárja magát az SSH-ból. Az ellenőrzés és az aktiválás így történik:

nft -c -f /etc/nftables.conf
systemctl enable --now nftables
nft list ruleset
nft list set inet filter newconn

Három pont dönt a hatásról. A ct state established,related accept szándékosan második szabályként áll, hogy a fennálló kapcsolatok ne fussanak végig a teljes szabálykészleten. A ct state invalid counter drop eltávolítja a hibás flag-kombinációkat és a késve érkező töredékeket, anélkül hogy ezeket egyenként le kellene írnia. A counter pedig minden drop előtt az oka annak, hogy utólag tudja, melyik szabály fogott: ha a számlálók nullán maradnak, a szabályt nem éri el a forgalom, és ez egészen más diagnózis, mint egy hatástalan szabálykészlet.

SYN-cookie-k és a backlog határa

A SYN-cookie olyan eljárás, amelynél a szerver nem jegyzi meg a félig nyitott kapcsolatot, hanem a szükséges adatokat titkosítva a saját válaszsorszámába írja. Amikor a kapcsolatfelépítés harmadik csomagja visszaér, ebből számolja ki újra az állapotot. Ezzel a várólista nem csordul túl többé, mert ezeknek a kapcsolatoknak nincs várólistája.

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_max_syn_backlog = 8192
net.core.somaxconn = 8192
net.core.netdev_max_backlog = 16384
net.core.rmem_max = 16777216

Ezek az értékek egy /etc/sysctl.d/ alatti fájlba valók, és a sysctl --system paranccsal lépnek érvénybe, különben a következő újraindítás után eltűnnek. Debianon és Ubuntun a tcp_syncookies gyárilag 1-en áll, ami helyes. Az 1-es érték nem azt jelenti, hogy „mindig cookie”, hanem azt, hogy „cookie, amint a várólista túlcsordul”.

Ennek az ára valós, és ritkán mondják ki. Egy cookie-ban nincs hely a másik oldal TCP-opcióinak. A Linux az ablaknagyítást és a szelektív visszaigazolást csak akkor menti meg, ha a net.ipv4.tcp_timestamps 1-en áll, mert az adatok ekkor az időbélyegben utaznak. Időbélyeg nélkül elesnek, és a kapcsolat élettartamának hátralévő részében lassabban fut. Ezenfelül a maximális csomagmérethez csak három bit áll rendelkezésre, tehát nyolc nyers fokozat az egzakt érték helyett. A SYN-cookie vészüzemmód, amely kapcsolatokat ment, nem a normál esetre szóló beállítás.

conntrack: a tábla, amely elsőként telik meg

A kernel kapcsolatkövetése minden csomagfolyamhoz bejegyzést hoz létre, az UDP-hez is, pedig az UDP nem ismer kapcsolatokat. Elosztott támadás esetén pontosan ez a tábla az az erőforrás, amely elsőként fogy el, és nagyon gyorsan fogy el: másodpercenként 1,49 millió, mindig új feladócímet hordozó csomag mellett egy 262 144 helyet kínáló tábla kevesebb mint egy ötöd másodperc alatt telik meg.

net.netfilter.nf_conntrack_max = 524288
net.netfilter.nf_conntrack_udp_timeout = 10
net.netfilter.nf_conntrack_udp_timeout_stream = 60
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 20

Egy bejegyzés nagyjából 300 bájtot foglal, 524 288 bejegyzés tehát körülbelül 150 megabájt kernelmemóriát. A hashtábla nagyságát nem sysctl útján, hanem modulparaméterként állítjuk be, szokásosan a felső határ egynegyedére, az /etc/modprobe.d/nf_conntrack.conf fájlban:

options nf_conntrack hashsize=131072

Egy tisztán játék- vagy hangszerver esetében az elegánsabb megoldás az, hogy a játékforgalmat egyáltalán nem követjük. Ez teljesen megkíméli a táblát:

nft add table ip raw
nft add chain ip raw prerouting '{ type filter hook prerouting priority raw; }'
nft add rule ip raw prerouting udp dport 25565 notrack

Figyelem: a notrack és az állapotkövető szabályok kizárják egymást. Aki egy portot kivesz a követés alól, annál a portnál nem használhat többé ct state szabályt, különben a szabad átjárás nem hat, és a szolgáltatás zárva van.

Sebességkorlátozás forráscímenként

A forráscímenkénti sebességkorlátozás a leghatásosabb egyedi intézkedés a szerveren, mert pontosan azt találja el, amit a támadó tesz, és pontosan azt engedi át, amit a felhasználó tesz. A különbség nagy: egy valódi szerverböngésző percenként néhányszor kérdez le, egy támadó másodpercenként több százszor. Az nftables ehhez dinamikus halmazokkal dolgozik, mint a fenti szabályrendszerben, a klasszikus iptables pedig hashlimit segítségével:

iptables -I INPUT -p udp --dport 27015 -m hashlimit --hashlimit-name query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p udp --dport 27015 -m length --length 0:27 -j DROP

Az ilyen szabályokban minden szám kezdőérték, nem igazság. Mérjen először egy hetet normál üzemben, különben a saját felhasználóit dobja ki, és éppen a legrosszabb pillanatban. Vegye figyelembe ezenfelül, hogy a tisztán iptables-alapú szabályok újraindítás után eltűnnek (apt-get install -y iptables-persistent, majd netfilter-persistent save), és hogy UFW alatt az /etc/ufw/before.rules fájlba valók, mert különben a következő ufw reload alkalmával eltűnnek. A folyó üzemre szóló teljes szabálykészlet a Szerver védelme DDoS-támadások ellen című cikkben áll.

Hol ér véget minden szűrés a szerveren

Most jön az a rész, amelyet egyetlen konfigurációs fájl sem old meg. Az összes eddigi intézkedés az Ön szerverén fut, tehát a vonal végén. Egy tűzfalszabály olyan csomagról dönt, amely már végigment a kábelen. Eldobhatja, de nem tudja elküldetlenné tenni. Ha az előtte lévő vonal tele van, a felhasználói csomagjai már korábban sem érkeznek meg, mégpedig függetlenül attól, milyen jó a szabálykészlete.

Ez a táblázat minden egyes esetre megválaszolja azt a kérdést, hogy elég-e a saját védelem. A GitHub ellen irányuló, másodpercenként 126,9 millió csomagot kitevő támadás csomagsebességben szűken befér egy 100 Gbit/s-os csatlakozásra, 1,35 Tbit/s volumen mellett viszont tizennégy ilyenre lenne szükség egyidejűleg. A 31,4 Tbit/s-os csúcstámadás 314 teljesen telített 100 Gbit/s-os csatlakozásnak felel meg. Egy játékszerver jellemzően 1 Gbit/s-on vagy kétszer 1 Gbit/s-on lóg: a saját védelem határa ezzel másodpercenként nagyjából 1,5 és 3 millió csomag között van, a gyakorlatban pedig lényegesen az alatt, mert a kernel előbb feladja.

Van még egy második, kellemetlenebb határ. Amint a vonal telített, adott esetben már az az SSH-munkamenet sem ér el Önhöz, amellyel mérni szeretett volna. Akinek ilyenkor nincs hálózattól független hozzáférése, például egy VNC-konzol az ügyfélportálon, már utánanézni sem tud, mi történik.

Ami csak a szerver előtt segít: szűrés a hálózatban és scrubbing

Hatásosan csak az tud szűrni, akinek több kapacitása van, mint a támadásnak. Ez olyan helyet feltételez, ahol sok vonal fut össze, tehát egy hálózatot, nem egy gépet. Ott két eljárás létezik, amelyek kiegészítik egymást.

Valós idejű szűrés a hálózatban. A teljes forgalom tartósan átfut egy szűrőfokozaton, amely minden csomagot értékel, mielőtt továbbadja a szervernek. Az előny az, hogy nincs átkapcsolás: a védelemnek nem kell előbb felismernie egy támadást ahhoz, hogy hasson. Pontosan ez dönt a játékoknál, mert a kétperces átkapcsolási idő egy elveszített kör, a kétperces átkapcsolási idő pedig egy 35 másodpercig tartó támadás esetén egyáltalán nem védelem.

Scrubbing. Ha a hálózat nagy volumetrikus támadást ismer fel, az érintett forgalmat szűrőközpontokba téríti, ott megtisztítja a káros részektől, majd a cél irányában szállítja ki. Ennek az eltérítésnek a közelség az értelme: a támadási forgalom ott ér véget, ahol belép, nem csak az adatközpontnál. A szűrőszabályokat ehhez a hálózatban osztják szét, ezt az RFC 8955 írja le technikailag Flow Specification néven.

A hamisított feladócímek elleni strukturális ellenintézkedés egyébként 2000 óta ismert, és az RFC 2827-ben, a BCP 38-ban áll: aki egy ügyfelet csatlakoztat, ezen a határon eldobja minden olyan csomagot, amelynek a feladócíme nem ehhez az ügyfélhez tartozik. Az RFC 3704 ezt a több csatlakozással rendelkező hálózatokra terjeszti ki. Ha minden hálózatüzemeltető megvalósítaná, az erősítéses támadások teljes osztálya megszűnne. Nem szűnt meg, mert elég az is, ha néhányan nem teszik meg.

És van egy harmadik módszer, amelyet ismerni kell, mert gyakran védelemként adják el: a null-routing, technikailag Remote Triggered Black Hole Filtering az RFC 5635 szerint. Ennél a megtámadott IP-címet elérhetetlenként hirdetik meg a hálózatban, és a hozzá tartó teljes forgalmat eldobják, a támadási forgalmat és a felhasználóit egyaránt. Ez a szolgáltató hálózatát védi, az Ön számára az eredmény azonos egy sikeres támadással, többnyire még órákkal utána is. Kétség esetén kérdezze meg, hogy szűrnek vagy null-routingot alkalmaznak. A válasz többet dönt el az elérhetőségéről, mint bármilyen hardveradat.

Mit állít ezzel szembe a KernelHost

A folyamatos védelem, amely minden szervercsomagban benne van

A KernelHost DDoS-védelme kétrétegű felépítésű és tartósan aktív, anélkül hogy Önnek bármit be kellene kapcsolnia, meg kellene rendelnie vagy konfigurálnia:

• 1. réteg: 17 Tbps mitigációs kapacitás a globális scrubbing-hálózatban. A volumetrikus támadásokat a forrásuk közelében tisztítja meg, mielőtt elérnék az adatközpontot.
• 2. réteg: Arbor valós idejű szűrés 3,2 Tbps kapacitással Frankfurt am Mainban. Közvetlenül a szerver előtt ismeri fel és dobja el a protokollspecifikus mintákat, csomagról csomagra.

Két tulajdonság döntő. A védelem folyamatosan fut, és a szerver kiszállításától aktív, tehát nincsenek a támadás elején olyan percek, amikor a szolgáltatás elérhetetlen. És nincs null-routing: az IP-címe a hálózatban marad, csak a káros csomagokat dobja el a rendszer. Hogy mely játékok és protokollok kapnak saját szűrőprofilt, azt a Játékszerver-DDoS-védelem valós időben sorolja fel.

Advanced DDoS Protection a tartósan lőtt projektekhez

Egyes projekteket nem alkalmanként, hanem célzottan és heteken át támadnak, minden este ugyanabban az időben és változó mintákkal. Erre való az Advanced DDoS Protection havi 50,00 EUR-tól, PrePaid alapon, minimális futamidő és beállítási díj nélkül. A különbség nem a nagyobb kapacitásban, hanem a kontrollban áll:

• Dedikált védett IP a frankfurti központi hálózatból, amelyre a szerverét a saját hálózatunkon belül átállítjuk. Az Ön oldalán semmilyen átalakítás nem szükséges.
• Önállóan kezelhető védelmi szabályok portonként és protokollonként az ügyfélportálon: külön állítja be, mi engedélyezett a játékporton és mi a lekérdezőporton, és ezzel pontosan azt az aszimmetriát tudja kihasználni, amelyről a lekérdező protokollokról szóló szakasz szól.
• A módosítások valós időben lépnek érvénybe, tehát egy futó támadás közben is utánaigazíthat, ahelyett hogy karbantartási ablakra várna.
• Az adott szolgáltatáshoz illő védelmi profil, ugyanígy a módosított és saját írású alkalmazásokhoz tetszőleges TCP- vagy UDP-portokon.

Az Advanced DDoS Protection a KernelHost ügyfeleinek szól, és KernelHostnál üzemelő szervert feltételez. Ha a projektje jelenleg máshol fut, és ott rendszeresen támadás alatt áll, akkor az ideköltözés a járható út, nem a korábbi címének távoli felügyelete.

A két szint összehasonlítása

Négy valós, üzemből kiszűrt támadás

A következő négy támadás KernelHost-ügyfelek szervereit érte, és mindegyiket teljesen valós időben szűrte ki a rendszer, kiesés nélkül. Az ábrák a védelem élő monitorozásából származnak.

TeamSpeak 3 hangszerver, 9987-es UDP-port. Összetett támadás több egyidejű mintával, több mint 473,4 Gbit/s és másodpercenként több mint 41,5 millió csomag. Ez nagyjából egy 1 Gbit/s-os csatlakozás csomagsebességének 28-szorosa.

ARK-játékszerver, 7777-es UDP-port. Egyszerű UDP-flood összetett szerkezet nélkül, ellenben több mint 112,2 Gbit/s és másodpercenként több mint 8,7 millió csomag. Hogy egy ARK-fürtöt emellett saját erőből hogyan biztosítunk, az az ARK-szerver védelme DDoS ellen című cikkben áll.

Minden portot érő támadás, 0-65535 TCP és UDP. Több mint tizenkét különböző fő támadási minta az összes port ellen egyidejűleg, összesen több mint 21,3 Gbit/s és másodpercenként több mint 3,9 millió csomag. Ez az eset azt a portokra való szétterülést mutatja, amely a Cloudflare 2025 májusi esetében is megjelenik, átlagosan 21 925 célporttal.

Minecraft és OpenVPN, 25565 TCP és 1194 UDP. Kombinált támadás több mint tizenhat különböző fő támadási mintával, másodpercenként több mint 4 millió csomaggal és több mint 8,6 Gbit/s-mal. Mindkét szolgáltatás folyamatosan elérhető maradt, pedig különböző protokollt beszélnek.

Mit kell tenni támadás esetén, ebben a sorrendben

A sorrend fontosabb az egyes lépéseknél, mert a leggyakoribb hibák az első öt percben történnek.

1. Mérni, nem csavarozni. Mentse ki először egy fájlba a sar -n DEV 1 10, az ip -s link show, az ss -s és a dmesg -T értékeit. A támadás után már nem lesznek meg, és nélkülük senki nem tud segíteni Önnek.
2. Ne indítsa újra. Az újraindítás törli az összes számlálót, az összes kapcsolatállapotot és minden bizonyítékot, a terhelés pedig néhány másodperc múlva újra ott van.
3. Állapítsa meg, melyik szintről van szó. A bájtok csomagokkal osztva adják az átlagos csomagméretet. A 100 bájt alatti érték protokolltámadásra, az 1000 bájt fölötti erősítéses támadásra, a normális méret magas processzorterhelés mellett a 7. rétegre utal.
4. Zárja le az adminisztrációs portokat. A panel, az adatbázis, az RCON és mindaz, aminek nem kell nyilvánosnak lennie, a saját címére korlátozva való. Ez azonnal és a felhasználókra való kockázat nélkül csökkenti a támadási felületet.
5. Állítson be sebességkorlátozást, szorosan a lekérdezőportra, tágabban a használati portra. A lekérdezőportot ne zárja le, különben eltűnik minden szerverlistából.
6. A saját címét ne váltsa meggondolatlanul. A címváltás csak addig hat, amíg az új cím nem áll megint nyilvánosan, egy elfelejtett régi DNS-bejegyzés pedig hatástalanná teszi a váltást.
7. Vonja be a szolgáltatót számokkal. Nyisson egy ticketet az időponttal, a célporttal, a csomagsebességgel, a sávszélességgel és az átlagos csomagmérettel. Ez az öt adat dönti el, milyen gyorsan igazítjuk utána a szűrőszabályokat az Ön címéhez.
8. Utána dokumentálja. Jegyezze fel, mikor kezdődött, mennyi ideig tartott és milyen minta volt. Az ugyanabban az időpontban visszatérő támadások adják azt a mérőszámot, amely szerint egy projektnek szüksége van-e dedikált védett IP-re.

A súlyos, hosszabban futó támadás részletes menete a Súlyos DDoS-támadás: mit tegyünk című cikkben áll.

Jogi helyzet: a DDoS-támadás bűncselekmény

Ausztriában a DDoS-támadás az osztrák büntető törvénykönyv (StGB) 126b. §-a, a „számítógépes rendszer működőképességének megzavarása” alá esik. Az alaptényállás hat hónapig terjedő szabadságvesztést vagy 360 napi tételig terjedő pénzbüntetést ír elő. Ha a zavar hosszabb ideig tart, két évig terjed. Ha sok rendszert támadnak egy olyan programmal, amelyet felismerhetően erre a célra hoztak létre, három évig. Ha pedig a kár meghaladja a 300 000 eurót, a támadás kritikus infrastruktúrát ér, vagy bűnszervezet tagjaként történik, a büntetési keret hat hónaptól öt évig tart. Ezt kiegészítve a StGB 126c. §-a már az erre a célra szánt programok előállítását, terjesztését és hozzáférhetővé tételét is büntetni rendeli.

Németországban a német büntető törvénykönyv (StGB) 303b. §-a, a „számítógépes szabotázs” alkalmazandó: három évig terjedő szabadságvesztés vagy pénzbüntetés, öt évig terjedő, ha az adatfeldolgozás egy üzemet, egy vállalkozást vagy egy hatóságot szolgál, és különösen súlyos esetekben hat hónaptól tíz évig, például üzletszerű elkövetésnél vagy kritikus infrastruktúra érintettségénél. A kísérlet büntetendő, az előkészületi cselekmények tekintetében pedig a 303b. § (5) bekezdése a StGB 202c. §-ára utal.

A booter- és stresser-szolgáltatások ezért nem szürke zóna, hanem egy bűncselekmény kifizetett része. Három pont ennél rendszeresen félreértett. Először: a „csak saját rendszerek terheléses tesztelésére” szóló megjegyzés semmit nem tesz jogszerűvé, mert a szolgáltatások nem ellenőrzik, kié a beírt cél. Másodszor: a megbízó is büntetendő, nem csak az üzemeltető; az Europol a 2026 áprilisi akcióhét után kifejezetten több mint 75 000 azonosított felhasználót írt meg, pontosan ennek tisztázása érdekében. Harmadszor: a saját szerverre irányuló terheléses teszt egy ilyen szolgáltatáson keresztül szintén nem megoldás, mert a támadási forgalom a szolgáltató hálózatán és ezzel más ügyfelek vonalain fut, amit minden hosztingszerződés tilt. Aki a szolgáltatása terhelhetőségét valóban mérni akarja, azt bejelentetten és a szolgáltatóval egyeztetve teszi. Ez a szakasz a törvényi állapotot adja vissza, és nem jogi tanácsadás.

A szolgáltatásához illő útmutató

Ez a cikk az elvet magyarázza el. Melyik portnak kell nyitva lennie, melyik konfigurációs direktíva melyik lekérdezést korlátozza, és hol van a határ az adott játéknál: ez az egyes szolgáltatásokról szóló cikkekben áll, mindegyikben a portok tényszerű táblázatával.

• Alapok és menet: DDoS-támadás felismerése, Szerver védelme DDoS-támadások ellen, Súlyos DDoS-támadás: mit tegyünk, Játék-DDoS-védelem valós idejű szűréssel
• Minecraft és hang: Minecraft és nullping, Minecraft Bedrock, TeamSpeak 3, Hytale
• GTA-alapú szerepjáték: FiveM, RedM, RAGE MP és alt:V, SA-MP és open.mp, MTA:SA
• Túlélés és építés: Rust, ARK, DayZ, Palworld, Conan Exiles, Project Zomboid, Terraria, Unturned
• Taktika és lövöldözés: CS2 és Source, Arma 3, Call of Duty, Team Fortress 2, Left 4 Dead 2, Garry's Mod, Mordhau, Lineage 2

Röviden összefoglalva

• A DDoS-támadás négy véges erőforrás közül foglal le egyet: a sávszélességet, a csomagsebességet, a kernel valamelyik állapottábláját vagy az alkalmazás processzoridejét. Nem használ biztonsági hibát, ezért a frissítés egyedül nem védelem.
• Az RFC 4732 a DoS-támadást a hatásán keresztül határozza meg, nem a források számán keresztül. Elosztottnak akkor nevezzük, ha a források nagy számban vannak: a Cloudflare 2025 májusi esetében 122 145 cím 161 országból.
• A CISA, az FBI és az MS-ISAC három technikát különít el: volumetrikus Gbit/s-ban, protokollra irányuló csomag per másodpercben, alkalmazásra irányuló kérés per másodpercben. Mindegyik más védelmet kér.
• Az erősítéses támadások nyitott UDP-szolgáltatásokkal élnek vissza. A tényezők a Steam-protokoll 5,5-ös értékétől az SSDP 30,8-as és az NTP 556,9-es értékén át a memcached 51 000-es értékéig terjednek, ahogy az US-CERT TA14-017A riasztásában olvasható.
• A kapacitás átvett eszközökből álló botnetekből jön, a Mirai 2016-os 600 000 eszközétől a 31,4 Tbit/s-os csúcstámadás mögött álló, becsült egy és négy millió közötti eszközig, és havi nagyjából 10 eurótól továbbadják.
• A szerveren az nftables, a SYN-cookie-k, a kiigazított conntrack-határok és a forráscímenkénti sebességkorlátozás hat. Másodpercenként nagyjából 1,5 millió csomagnál véget érnek, mert egy 1 Gbit/s-os csatlakozás nem szállít többet.
• E határ fölött kizárólag a szerver előtti hálózatban végzett szűrés dönt. A null-routing nem védelem, hanem az az eredmény, amelyet a támadó akart.
• A KernelHostnál a kétrétegű folyamatos védelem minden szervercsomagban felár nélkül benne van és a kiszállítástól aktív, null-routing nélkül: 17 Tbps mitigációs kapacitás a globális scrubbing-hálózatban plusz Arbor valós idejű szűrés 3,2 Tbps kapacitással Frankfurt am Mainban. Az Advanced DDoS Protection ezt havi 50,00 EUR-tól dedikált védett IP-vel és önállóan kezelhető, portonkénti szabályokkal egészíti ki.
• A DDoS-támadás Ausztriában a StGB 126b. §-a, Németországban a StGB 303b. §-a szerint büntetendő, a megbízóra ugyanúgy, mint a szolgáltatások üzemeltetőjére.

Ha a projektje már a KernelHostnál fut, a szűrés aktív, anélkül hogy bármit tennie kellene. Ha mégis rendellenességet észlel, nyisson egy support-ticketet a 7. lépés öt adatával, hogy az IP-címéhez tartozó szűrőszabályokat utánaigazítsuk. Futó támadás esetén ezen felül a WhatsApp-vészhelyzeti chaten is elér minket a +43 650 8209883 számon.