Ugrás a tartalomhoz
DDoS-védelem · Peeryx · 15 Tbps+
Minden útmutató

L3, L4 és L7 DDoS-védelem: mi szűrhető ténylegesen?

Az Anti-DDoS megnevezés önmagában nem mondja meg, mely támadást szűri egy szolgáltatás. Weboldal, játékszerver és védett transit eltérő ellenőrzést igényel. A valódi forgalmi út és dokumentált funkciók alapján értékelj, ne csak a hálózat nagy összesített kapacitása szerint.

← Összes útmutatóCubixServ

Mielőtt elkezded

Listázd a nyilvános címeket, portokat, protokollokat és eredeti szervereket. Azonosítsd a szűrés és továbbítás helyét. Őrizd a normál méréseket és feltételeket a hibák összevetéséhez. Hozzáférési szabály módosítása előtt tervezz karbantartást, másolatot és visszaállítást.

L3 a hálózati forgalmat kezeli

A hálózati réteg IP-csomagokat és forgalmi mintázatokat vizsgál. Egy folyam az alkalmazás elérése előtt telítheti a kapcsolatot; előtte kell szűrni. Összesített kapacitás nem szerverkapacitás: a CubixServ által közölt 15 Tbps közös védelmi hálózati érték, nem saját port vagy minden támadás elleni garancia. Az egy szolgáltatáshoz kiosztott sávszélességet külön igazold a valódi feltételekből.

Egy támadás megpróbálhat kitölteni egy hivatkozást, kimerítheti a kapcsolat állapotát, vagy alkalmazási munkát vesz igénybe. Többféle hatás is előfordulhat együtt. A felfelé irányuló szűrés, kapcsolatvezérlők vagy alkalmazásszabályok kiválasztása előtt azonosítsa a veszélyeztetett erőforrást és az érintett forgalmat.

L4 különböző TCP és UDP viselkedés

Az átviteli réteg TCP kapcsolatokat és UDP folyamokat kezel, eltérő állapottal és szabályokkal. Port-, állapot- és sebességkorlátok alkalmazhatók. Webes profil nem feltétlenül megfelelő játékhoz. Igazold a kiosztott játékportot, az adminisztrációt külön kezeld. Sikeres TCP teszt nem teljes UDP-ellenőrzés; a játékosok protokollját a forrással és vissziránnyal együtt próbáld. Megosztott gépen ne nyiss idegen vagy szükségtelen portot.

Ellenőrizze az engedélyezett tiszta forgalmat, a lefedett protokollokat, a védett címeket és a beavatkozási feltételeket is. A védelemnek lehetnek lefedettségi korlátai vagy elszigetelési intézkedések. A korlátlan igény nem helyettesíti a műszaki feltételeket és a szerződést.

L7 az alkalmazás ismeretét igényli

Szabályosnak tűnő kérés drága műveletet indíthat. HTTP proxy ellenőrizhet HTTP-t, de ettől nem érti minden játék protokollját. Konkrét endpointokról és funkciókról kérdezz. FiveM fájlletöltés és játékbelépés külön vizsgálandó: egy HTTP-rész védelme nem igazol minden műveletre kiterjedő alkalmazásvédelmet. A dokumentált hatókört a konkrét protokollhoz kösd; az L7 név nem univerzális működési bizonyíték.

A FiveM jól mutatja a megkülönböztetést: a HTTP belépési pontnak, a letöltéseknek és a játékmenetnek koherens architektúrára van szüksége. A védett webhely elérhető marad, amíg a játék meghiúsul. A L7 képességnek le kell írnia a tényleges hatókörét, nem pedig azt, hogy minden alkalmazást lefedjen.

Az eredeti szerver is része a védelemnek

Védett cím kevés, ha a védtelen eredeti szerver közvetlenül elérhető marad. Vizsgáld a DNS-t, fájlokat, adminisztrációt és egyéb portokat. Ne korlátozz forrásokat minden jogos út ismerete előtt. Túl tág bizalom megkerülést engedhet, túl szűk szabály felhasználókat tilthat. A kezelés külön biztonságos hozzáférést igényel. Változtatás után a szükséges kapcsolatok működését és a visszaállítás lehetőségét is ellenőrizd.

A származás korlátozásához a legális források és szolgáltatások megértése szükséges. Érvényesítse az útvonalakat, küldje vissza a forgalmat, hangot, fájlokat és adminisztrációt a szűrés előtt. A túlságosan széles engedélyezési lista felfedi az eredetet; a túl keskeny kiesést okozhat. Ne másoljon általános szabályt az architektúra megértése nélkül.

A hálózatot és alkalmazást együtt mérd

Eseménynél vesd össze a forgalmat, eldobott csomagokat, sikeres kapcsolatokat és terhelést. Terhelt fő szál vagy adatbázis normál hálózat mellett is megállíthatja a játékot. Több szűrés nem javít költséges szkripteket. Timeout nem önmagában támadásbizonyíték: ugyanabban az időben és szolgáltatásban mérj veszteséget, útvonalat, hibákat és eltéréseket. Konkrét ok nélkül ne változtass más ügyfelekre is ható általános védelmet.

Időbélyegzett események és szűrési magyarázat kérése, ha a legitim kapcsolatok meghiúsulnak. Különböztesse meg a hamis pozitívakat, az útválasztási kitérőket és az alkalmazásterhelést. Egy koordinálatlan terhelési teszt magát a szolgáltatást ronthatja; intézkedjen az aktív érvényesítésről a szolgáltatóval és a pontos határértékekről.

Ellenőrizhető feltételeket kérj

Igazold a hatókört, kiosztott sávszélességet, engedélyezett szolgáltatásokat, továbbítást és támogatást. Tisztázd az IP, alagút vagy eredeti cím változtatásának szükségét. Telepítés előtt és után próbáld a teljes utat jogos felhasználókkal. Működő weboldal nem minden játék próbája; terhelés és támadásszimuláció kifejezetten egyeztetett, jogos határokat igényel más ügyfelek védelmében. Dokumentálatlan garanciát ne tekints a csomag részének.

Ezután hasonlítsa össze a kért körhöz rendelkezésre álló terveket és árakat. A hasznos választás egyesíti a hálózati kapacitást, a protokolltudatos kezelést és az incidensek diagnosztizálásának képességét. Egyetlen védelmi rendszer sem szünteti meg a szoftverek, fiókok és biztonsági másolatok karbantartásának szükségességét.

Teendők az adott helyzetben

HelyzetKövetkező lépés
UDP-t használó játékIgazold a portot, protokollt és szűrési profilt. HTTP-válasz nem teljes ellenőrzés.
Drága HTTP-kérésekAz alkalmazást, limiteket és proxyt együtt vizsgáld. Hálózati tartalék nem szünteti meg a kérés munkáját.
Külső eredeti szerverKözvetlen elérés korlátozása előtt dokumentáld a jogos forrásokat és visszirányt.

Hivatalos források

Ezek a források ismertetik a protokollokat és beállításokat. Ellenőrizd a használt verzió dokumentációját.

  1. RFC Editor / IETF/rfc/rfc4732
  2. NGINX/en/docs/stream/ngx_stream_proxy_module.html
  3. Cfx.re/docs/server-manual/proxy-setup/