Hogyan lehet ellenállni DDoS-támadások a nginx és nginx plus

előző ◈ a következő

Hogyan lehet ellenállni DDoS-támadások nginx és nginx Plus 14

  • 14.01.16 11:17 •
  • 1cloud •
  • • # 275107
  • • Habrahabr
  • fordítás •
  • 5 •
  • 15200

- mint a Forbes, csak jobb.

Bevezetés: mi az a DDoS


Distributed Denial of Service támadás - «Distributed Denial of Service támadás azzal a céllal, szolgáltatás megtagadása” - egy kísérlet, hogy nem minden olyan szolgáltatás, amelyet rendszerint egy weboldal elérhetetlenné bombázzák a forgalom több forrásból. Ennek eredményeként, a szerveren, a szolgáltatást, egyszerűen megszűnik normálisan működik, nem birkóznak torlódás.

Normál program ebben az esetben - „kínzás” a rendszert, így sok új kapcsolatokat és kéri, hogy a hálózat már nem megbirkózni a flow, vagy annyira lassú, hogy nem lehet dolgozni.

Műszaki jellemzők DDoS támadások


Az alkalmazási réteg DDoS-támadás végzi speciális programok (botok), amelyek hasznosítják a gyenge pontokat, az adott rendszerben. Például egy olyan rendszert, amely nem földi ellenőrzése alatt nagyszámú párhuzamos kötéseket működésképtelenné válnak, ezáltal jelentős számú ilyen „Connect”. Ha aktív, akkor lehet tartani időről időre zasylaya rajtuk keresztül kis mennyiségű forgalmat. Egy másik lehetőség -, hogy töltse ki a rendszer a kérelmek nagy száma miatt, vagy hogy ezeket a kérelmeket meglehetősen nehéz. Ez a tény nem a tényleges kapcsolat, így a bot nagyon könnyű, hogy küldjön egy nagy kérelmek száma, és gyorsan létrehoz egy csomó új kapcsolatokat.

Az alábbiakban a műszaki jellemzőit DDoS-támadások, amelyek segítségével felismerhető, és tekintettel arra, hogy foglalkozni velük:

Lehetőségek nginx és nginx Plus elleni küzdelemre DDoS támadások


Nginx és nginx Plus számos jellemző felbecsülhetetlen foglalkozik, hogyan kell kezelni a DDoS-támadások ellen. Úgy működik, két módja van: az alapkezelő a bejövő forgalmat, és keresztül ellenőrzése eloszlatását a belső szerverek.

Korlátozása gyakorisága kérelmek


Akkor állítsa be a frekvenciát a beérkező kérések révén nginx és nginx Plus akár a jellemző érték a felhasználók valós. Például, ha úgy vélik, hogy a honlapon a felhasználók megy két másodpercenként. Beállíthatja a készüléket a frekvenciája lekérdezések oldal - 30 percenként.

Korlátozza a kapcsolatok száma
Zárás lassú kapcsolatok


Akkor a kapcsolatot, hogy adatokat küldjön túl ritka, hogy a jele lehet, hogy a fő cél -, hogy nyitott egy hosszú idő, és hogy megakadályozzák az új kapcsolatokat. Ez a program a támadás az úgynevezett Slowloris. client_body_timeout irányelv szabályozza a várakozási idő nginx rekordok között az ügyfél szervezetben. client_header_timeout irányelv ugyanazt a címet. Alapértelmezésben mindkét esetben helyezte 60 másodperc. Az alábbi példában ez az intervallum van beállítva érték 5 másodperc.

Gyorsítótárral, hogy megakadályozzák a forgalom ugrások


Testreszabhatja és nginx nginx Plus, úgy, hogy felszívja a forgalmi rohamokat a támadás során a cache és a recept a paraméterei, akkor figyelmen kívül hagyja loop vissza. Az alábbi lehetőségek közül választhat:

Paraméter frissítések proxy_cache_use_stale nginx számolt, hogy ha szükség van frissíteni az elavult tárgyakat a cache, meg kell küldeni csak egy kérés, és nyitva tartani az ilyen lehetőségek igénybe az ügyfelek, miközben frissít belső szerverek nem érjük el.

Key által meghatározott proxy_cache_key általában egy beépített variációk (alapértelmezett kulcsot. $ Rendszer $ proxy_host $ REQUEST_URI három variáció). Ha az érték tartalmazza a $ QUERY_STRING. A támadás ritka küldő lekérdezés húrok okozhat a túlzott cache-t. Nem ajánlott, hogy ezt a lehetőséget a kulcsot, ha nincs sürgős.

zárolási kérelmeket


Testreszabhatja és nginx nginx Plus blokkolja az ilyen típusú lekérdezéseket:

  • Kéri, hogy egy adott URL-t, amely lehet veszélyben.
  • Lekérdezések, ahol User-Agent fejlécet a fontosak, nem a szokásos ügyfél forgalom.
  • Request amelyben Referer fejlécek lehet azonosítani, mint van társítva támadás.
  • Kéri, hogy a többi fejezetek tűnik gyanúsnak.

Például, ha úgy dönt, hogy a támadás célja URL /foo.php, akkor blokkolja az összes kérés erre az oldalra:


Ha úgy találta, hogy a DDoS-támadások lekérdezések ize vagy bár értéke címe User Agent, és zárd őket:


Ugyanez az elv működik más címek, amelyek amelyek azt jelzik a fenyegető támadás.

Korlátozás kapcsolat a belső szerverek


Nginx és Nginx Plus beadható egyidejűleg nagy számú vegyületek, mint engedik magukat a belső szerverek. Nginx Plusz, akkor korlátozza a kapcsolatok számát az egyes belső szervereket. Tegyük fel, hogy szeretné korlátozni a kapcsolatok számát, hogy a két belső szerver csoport szolgálja a helyszínen, a szám 200:


max_conns paraméter határozza meg a maximális kapcsolatok száma nyílt nginx Plus minden egyes kiszolgálóhoz. queue irányelv korlátozza a sorban állnak, ha az összes szerver csoport túllépte a határt. Ebben ugyanabban a sorban írásbeli kérésére egyelőre viszont - 30 másodperc.

Tartomány alapú támadások
Hogyan lehet megbirkózni a nagy terhelés


DDoS-támadások általában vezet kritikus minél nagyobb a terhelés szintjét. Olvassa el, hogyan kell tanítani és nginx nginx Plus működik, és hogy ezt a problémát, itt.

Detection DDoS-támadás


Eddig már tárgyalt, hogyan tudjuk használni nginx és nginx Plus, hatásainak enyhítése DDoS-támadások ellen. De vajon lehetséges, hogy ezeket a szervereket, hogy észleli a támadás maga? Nginx Plus állapota Module részletes forgalmi teljesítménymutató, amely eloszlik a belső szerver. Ez az eszköz lehetővé teszi, hogy ismeri rendellenes közlekedési feltételek. Nginx Plus funkciója vezérlőpanel weboldal oldal megjelenítésére grafika a jelenlegi állapotában a munkáját a rendszer (egy példa látható itt: demo.nginx.com/status.html). Ugyanez mutatók érhetők az API, akkor beágyaz őket a saját, illetve harmadik fél rendszert, hogy nyomon követhessék idővel változik a forgalom, figyelmeztető szokatlan állapotát.


Nginx és nginx Plus nyújthat felbecsülhetetlen segítséget megoldásában a kérdést, hogy hagyja abba DDoS-támadásokat. Így nginx Plusz további tulajdonságai, hogy megvédje az ilyen támadások ellen, elejét vegye.

Miért nem írok a 444 kódot
hogy alapuló skorigovoy mozhnlo rendszer naplózási és blogirovat keresztül ipset vagy iptables nyers

értéke $ adjunk hozzá 1;
helyen /index.php limit_except GET POST deny all;
>
értéke $ tilalom „”;
if ($ http_referer = "")
if ($ REQUEST_METHOD = POST)
if ($ QUERY_STRING = «action = login»)
if ($ tilalmat = 111) access_log / var / log / [133] Nginx / ban ip;
444 visszatérő;
>
proxy_pass 127.0.0.1: 8000;
>
jól és pontozási mutatók csalni
egy szót sem tuning kernel ... annak ellenére, hogy közvetlenül nginksu, és nem vonatkozik a téma lenne kiemelni.

client_body_timeout irányelv szabályozza a várakozási idő nginx rekordok között az ügyfél szervezetben. client_header_timeout irányelv ugyanazt a címet. Alapértelmezésben mindkét esetben helyezte 60 másodperc. Az alábbi példában ez az intervallum van beállítva érték 5 másodperc.
Óvatosan az ilyen értékeket. Így könnyen fel kés alá a mobil ügyfelek.

előző ◈ a következő