Nginx védelem a DDOS támadásoktól. DDOS védelem a Nginx-el az IP-címek megengedett listájának létrehozása

A DDOS támadásokkal való küzdelem - a munka nemcsak nehéz, hanem lenyűgöző. Nem meglepő, hogy minden sysadmin először megpróbálja megszervezni a védelmet saját - különösen azért, mert még mindig lehetséges.

Úgy döntöttünk, hogy segítünk Önnek ezzel a nehéz, és közzétenni néhány rövid, triviális és univerzális tanácsot a webhely védelmére a támadásoktól. A csökkentett receptek nem segítenek abban, hogy megbirkózzanak a támadással, de a legtöbb veszélytől mentesek.

Megfelelő összetevők

A durva igazság az, hogy sok webhely olyan bárkinek, aki a lassú támadást akarja használni, szorosan megöli az Apache-t, vagy az úgynevezett Syn árvizet rendezheti az úgynevezett SYN árvíz használatával egy percenként emelt virtuális kiszolgálókkal az Amazon EC2 felhőben. Minden jövőbeni DDOS védelmi tippje a következő fontos feltételeken alapul.

1. A Windows Server elutasítása

A gyakorlat azt sugallja, hogy az ablakokon működő webhely (2003 vagy 2008 nem számít), a DDO-k esetében elítélték. A kudarc oka a Windows hálózati veremben rejlik: amikor a kapcsolatok sokat válnak, a szerver minden bizonnyal rosszul reagál. Nem tudjuk, miért működik a Windows Server olyan helyzetekben, hogy olyan jó hírű helyzetekben dolgozik, de több mint egyszer találkoznak, és nem kettő. Emiatt ez a cikk a DDOS-támadások elleni védelmi eszközökről szól, amikor a kiszolgáló Linuxon forog. Ha boldog tulajdonosa egy kortárs kernel (kezdve 2.6), majd az iptables és IPSet közművek fogják használni, mint az elsődleges eszközkészlet (hogy gyorsan hozzá IP-címek), melynek segítségével gyorsan tiltani védjük. A sikerhez egy másik kulcsa egy megfelelően főtt hálózati verem, amelyet tovább fogunk beszélni.

2. Rész Apache-val

A második fontos feltétel az Apache elutasítása. Ha még egy óra, akkor érdemes Apache, akkor legalább egy gyorsítótárazási proxyot helyez el - Nginx vagy Lightpd. Az Apache "Nagyon nehéz fájlokat adni, és még rosszabb, az alapszintű (vagyis visszafoghatatlanul kiszolgáltatott egy veszélyes lassú támadásra, amely lehetővé teszi, hogy a szerver szinte egy mobiltelefonról. A lassuló típusai, az Apache felhasználók jöttek fel a patch első anti-slowloris.FInd, majd a mod_noloris, majd a mod_antiloris, a mod_limitipconn, a mod_reqtimitipconn, a mod_reqtimeout ... De ha éjszaka jól aludni szeretne, könnyebben szedni egy HTTP-kiszolgálót, sebezhetetlen a kódszerkezet szintjén lassítva. Ezért minden további receptünk a feltételezésen alapul, hogy a Nginx-et az elején használják.

Küzdelem a DDO-ről.

Mi van, ha DDOS jött? A hagyományos önvédelmi technika olvasni a HTTP szerver log fájlban, írj egy mintát Grep (ami bot botok) és a tilalom mindenkinek, aki alá azt. Ez a technika fog működni ... ha szerencsés vagy. A Batnets két típus, mindkettő veszélyes, de különböző módon. Az egyik teljesen jön a webhelyre, a másik fokozatosan. Az első megöli mindent, és azonnal megöli, de a naplók teljesen megjelennek a naplókban, és ha megtiltják őket, és megragadják az összes IP-címet, akkor győztes vagy. A második botnet óvatosan és óvatosan alapul, de tiltani kell, talán a nap folyamán. Fontos megérteni minden adminisztrátort: \u200b\u200bHa megtervezik a GREP-t, akkor készen kell állnia arra, hogy pár napig készen kell állnia a támadás elleni küzdelemre. Az alábbiakban azok a tanácsok, ahol előzetesen fel lehet tenni a szalmákat, hogy ne legyen olyan fájdalmas esni.

3. Használja a Testcookie modult

Talán a cikk legfontosabb, hatékony és operatív receptje. Ha a DDO-k a webhelyére kerül, akkor a @Kyprizel Coexler által kifejlesztett Testcookie-Nginx modul a leghatékonyabbá válhat. Egy ötlet egyszerű. Leggyakrabban a http árvizeket végrehajtó botok meglehetősen hülye, és nincs HTTP cookie-k és átirányítási mechanizmusok. Néha fejlettebb - ilyen használhatja a cookie-kat és a folyamat átirányítását, de szinte SOHA SODE-BOT hordozza a teljes fledged JavaScript-motort (bár gyakran gyakrabban és gyakrabban). A Testcookie-Nginx gyors szűrőjeként működik a botok és a backend között az L7 DDOS támadás során, amely lehetővé teszi, hogy levágja a szemétkockáit. Mit tartalmaz ezek az ellenőrzések? Függetlenül attól, hogy az ügyfél képes-e végrehajtani a HTTP átirányítást, függetlenül attól, hogy a JavaScript támogatja-e annak a böngészőjét, amelyre kimondja (mivel a JavaScript mindenütt másol, és ha az ügyfél azt mondja, hogy ő, mondjuk Firefox, akkor ellenőrizhetjük). A csekket különböző módszerekkel alkalmazzuk cookie-kkal:

"SET-Cookie" + átirányítás 301 HTTP-vel;
"Set-Cookie" + átirányítás a HTML metafrissítéssel;
tetszőleges sablon, és használhatja a JavaScriptet.

Az automatikus elemzés elkerülése érdekében a cookie-k vizsgálata az AES-128 alkalmazásával titkosítható, és később a JavaScript kliens oldalán visszafejthető. A modul új verziójában lehetett telepíteni a főzőket a Flash-en keresztül, amely lehetővé teszi, hogy hatékonyan csökkentse a botokat (amelyek flash általában nem támogatottak), de azonban számos törvényes felhasználó hozzáférését is blokkolja (valójában minden mobil eszköz) ). Érdemes megjegyezni, hogy a Testcookie-Nginx rendkívül egyszerű. A fejlesztő különösen számos érthető példát eredményez (különböző támadási esetekre) a Nginx konfigurációinak mintáival.

Az előnyök mellett a testcookie hátrányai vannak:

vágja az összes botot, beleértve a Googlebotot is. Ha folyamatban van a testcookie-t, győződjön meg róla, hogy nem tűnik el a keresési eredményekből;
problémákat okoz a böngészőkkel rendelkező felhasználókkal, W3M és azok hasonlóan;
nem mentheti el a teljes fledged böngészőmotorral felszerelt botokat a JavaScript segítségével.

Röviden, a testcookie_module nem univerzális. De számos dologból, mint például, például a Java és a C # primitív szerszámok, segít. Tehát csökkenti a fenyegetés részét.

4. KÓD 444.

A DDos'ers célja gyakran a webhely legforrásszerűbb része lesz. Egy tipikus példa olyan keresés, amely komplex lekérdezéseket végez az adatbázishoz. Természetesen a támadók kihasználhatják ezt, és egyszerre több tízezer kéréseket töltöttek be a keresőmotorra. Amit tehetünk? Ideiglenesen letiltja a keresést. Hagyja, hogy az ügyfelek beépített eszközökkel ne kereshessék a szükséges információkat, de a teljes fő webhely a munkakörben marad, amíg meg nem találja az összes probléma gyökerét. A Nginx támogatja a nem szabványos 444 kódot, amely lehetővé teszi, hogy egyszerűen bezárja a kapcsolatot, és ne adjon semmit a válaszadásban:

Hely / keresés (visszatérés 444;)

Így például lehetséges, hogy gyorsan megvalósítsa az URL-ek szűrését. Ha biztos abban, hogy a helyszínre / keresésre vonatkozó kérelmek csak a botokból származnak (például a bizalom azon a tényen alapul, hogy nincs partíció / keresés a webhelyén), telepítheti az Ipset csomagot és tilthatja a botokat egy egyszerű héjjal forgatókönyv:

Ipset -n Ban Iphash Tail -f Access.Log | Olvasási vonal közben; Echo "$ sort" | \\ cut -d "" "-F3 | Cut -D" "-F2 | GREP -Q 444 && Ipset -a tilalom" $ (l %% *) ";

Ha a naplófájl formátuma nem szabványos (nem kombináció), vagy más jeleket kell tiltani, mint a válasz állapota, szükség lehet a vágás cseréjére.

5. Banya by geod

A 444 nem szabványos válaszkód is hasznos lehet az ügyfelek működési tilalmára a geo-akvizícióban. Alig korlátozhatja az egyes országokat, amelyek kényelmetlenek. Tegyük fel, hogy a Rostov-On-Don kamerák online áruházánál sok felhasználó van Egyiptomban. Ez nem nagyon jó út (csak azt mondja - undorító), mivel a geoip adatok pontatlanok, és Rostovs néha egyiptomba repülnek pihenésre. De ha nincs mit veszíteni, kövesse az utasításokat:

Csatlakozzon a Nginx GeoIP modulhoz (wiki.nginx.org/httpgeoipmodule).
A Geother információinak megjelenítése a hozzáférési naplóban.
Továbbá, a fenti shell parancsfájl módosítása, a progresszív hozzáféréslog Nginx, és az ügyfelek tárolása tilalmakba adagolják az SFateled földrajzi jeleit.

Ha például a legtöbb esetben a botok Kínából származnak, ez segíthet.

6. Neurális hálózat (POC)

Végül megismételheti a @Savetherbtz játék tapasztalatait, amely a Neural Network Pybrain-t vette, töltötte be a bejelentkezést, és elemezte a kéréseket (habrahabr.ru/post/136237). Módszer működik, bár nem univerzális :). De ha tényleg ismered a webhelyed belsejét - és Önnek, rendszergazdaként, akkor - akkor esélye van arra, hogy a legtöbb tragikus helyzetben olyan tragikus helyzetekben, hogy az ideghálózatokon alapuló ilyen eszköztár, a tanulás és az előzetes információk gyűjtése . Ebben az esetben rendkívül hasznos ahhoz, hogy a DDO-k kezdete előtt hozzáférjenek. "A, a legitim ügyfelek közel 100% -ának leírása, ezért egy nagy adatkészlet a neurális hálózat képzéséhez. Ráadásul a szeme a bárban van nem mindig láthatóak.

A probléma diagnosztikája

A webhely nem működik - miért? Ddosam, vagy ez egy jag hiba, amelyet egy programozó nem észlel? Nem fontos. Ne keressen választ erre a kérdésre. Ha úgy gondolja, hogy webhelye támadhat, kapcsolatba léphet a támadásoktól, amelyek védelmet nyújtanak a támadásoktól - számos anti-DDOS szolgáltatás az első nap után a kapcsolat ingyenes -, és ne pazaroljon több időt a tünetek keresésére. Összpontosítson a problémára. Ha a webhely lassan működik, vagy egyáltalán nem nyílik meg, akkor azt jelenti, hogy nincs valami a teljesítményhez, és - függetlenül attól, hogy a DDOS támadás megy-e vagy sem, - te, mint szakmai, köteles megérteni, mi okozott azt. Ismételten tanúskodtunk, hogy a vállalat milyen nehézségeket tapasztal a webhely munkájával a DDOS támadás miatt, ahelyett, hogy gyenge pontokat találna a helyszínen, megpróbálta nyilatkozatot küldeni a Belügyminisztériumnak, hogy megtalálja és büntesse a támadókat. Ne engedje meg az ilyen hibákat. A Cybercriminals keresése nehéz és hosszú távú folyamat, amelyet az internet szerkezete és elvei bonyolítanak, és a webhely munkájával kapcsolatos problémát gyorsan meg kell oldani. Tegye meg a technikai szakembereket, hogy megtalálják, hogy mi az oka a webhely teljesítményének csökken, és az alkalmazás képes lesz ügyvédek írni.

7. Használja a Profiler és a hibakeresést

A leggyakoribb webhely-létrehozó platformhoz - PHP + MYSQL - A szűk keresztmetszet a következő eszközök segítségével lehet aláírni:

az XDEBUG Profiler megmutatja, hogy melynek hívja az alkalmazás a legtöbb időt;
a beépített hibakereső APD és a hibakeresési kimenet a hibajelentésben segít abban, hogy megtudja, melyik kód végrehajtja ezeket a kihívásokat;
a legtöbb esetben a kutyát az adatbázis iránti kérelmek összetettségére és súlyára temették el. Itt segít a motort beágyazott SQL adatbázisban.

Ha a webhely véletlenül hazudik, és nem fogsz elveszíteni semmit, kapcsolja ki a hálózatot, nézze meg a naplókat, próbálja meg elveszíteni őket. Ha nem hazugság, menj át az oldalakon, nézd meg az alapot.

Például PHP-t biztosítanak, de az ötlet minden platformra érvényes. A fejlesztői szoftverek írása bármely programozási nyelven, képesnek kell lennie gyorsan alkalmazni a hibakeresőt, és a profilert. Gyakorlat előre!

8. Elemezze a hibákat

Elemezze a forgalmi hangerőt, a kiszolgáló válaszidejét, a hibák számát. Ehhez lásd: Naplók. A Nginx-ben a kiszolgáló válaszideje a naplóban van rögzítve két változóval: kérés_time és upstream_response_time. Az első a lekérdezés végrehajtásának teljes ideje, beleértve a felhasználó és a szerver közötti hálózati késleltetést; A második jelentések mennyi backend (apache, php_fpm, uwsgi ...) kérésre szolgált. Upstream_Response_time érték rendkívül fontos a sok dinamikus tartalommal és az aktív kommunikációval rendelkező webhelyeknél az adatbázissal, nem lehet elhanyagolni. Használhat ilyen konfigurálást log formátumként:

Log_format xakep_log "$ remote_addr - $ remote_user [$ time_local]" "$ skation" $ status $ body_bytes_sent "$ http_referer" $ http_user_agent "$ http_user_agent" $ sweer_time \\ $ upstream_response_time

Ez egy kombinált formátum a hozzáadott időzítési mezőkkel.

9. Nyomon követheti a másodpercenkénti kérések számát

Nézze meg a másodpercenkénti kérelmek számát is. Abban az esetben, nginx, akkor becsülni ezt az értéket a következő shell parancs (a access_log változó tartalmazza az elérési utat a nginx lekérdezés log Kombinált formátumban):

Echo $ (($ (fgrep -c "$ (ENV LC_ALL \u003d C dátum) [E-mail védett]$ (($ (Dátum \\ +% s) -60)) +% d /% b /% y:% h:% m) "$ \u200b\u200baccess_log") / 60)))

A normálhoz képest ezúttal a másodpercenkénti kérelmek száma csökkenhet és nő. Abban az esetben, ha egy nagy botnet jött, és esik, ha a győztes botnet csomagolta a webhelyet, így teljesen hozzáférhetővé tette a jogos felhasználókat, ugyanakkor nem kéri a statikákat, és a törvényes felhasználókat kérik. A lekérdezések csökkenése a statika miatt. De egy vagy más módon, a mutatók komoly változásairól beszélünk. Amikor ez hirtelen megtörténik - miközben megpróbálja megoldani a problémát saját, és ha nem látja azonnal a naplóban, akkor jobb, ha gyorsan ellenőrizheti a motort, és párhuzamosan lépjen kapcsolatba a szakemberekkel.

10. Ne felejtsük el a tcpdump-t

Sokan elfelejtik, hogy a TCPdump egy fantasztikus diagnosztikai eszköz. Néhány példát adok. 2011 decemberében egy hiba a Linux kernel fedezték fel, amikor megnyitotta a TCP kapcsolat, ha a SYN és RST TCP szegmens zászlókat jelenik meg. Az első Bagptort az Oroszország rendszergazdáját elküldte, akinek erőforrását megtámadta e módszerrel, - a támadók megtudták a sérülékenységeket, mint az egész világot. Nyilvánvaló, hogy ilyen diagnózis segített. Egy másik példa: A Nginx nem egy nagyon szép tulajdonság - írja a naplóban csak akkor, ha a teljes kérés teljes mértékben megértette. Vannak olyan helyzetek, amikor az oldal hazudik, semmi sem működik, és nincs semmi a naplókban. Mindent, mert a kiszolgáló jelenleg letöltött összes kérés még nem teljesült. A TCPdump segít itt.

Annyira jó, hogy azt tanácsoltam, hogy az emberek ne használjanak bináris protokollokat, mielőtt meghódítanak, hogy minden rendben van, - mert a szöveges protokollok adósságot adnak a tcpdump "OM könnyű és bináris - nem. Azonban a sniffer jó, mint eszköz diagnózis - a termelés fenntartásának eszközeként ", és szörnyű. Könnyen elveszíthet több csomagot egyszerre, és elronthatja a felhasználó történetét. Kényelmes arra, hogy megnézze a következtetését, és hasznos lesz a kézi diagnosztika és a tilalom, de próbálja meg semmit bonyolítani. Egy másik kedvenc eszköz a "Requen Requen" - Ngrep - Általánosságban, az alapértelmezés szerint, próbálja meg kérni a két gigabájt területén, amely nem tudom, és csak akkor kezdődik, amikor csökkenti a követelményeit.

11. Támadás vagy nem?

Hogyan lehet megkülönböztetni a DDOS támadást, például egy hirdetési kampány hatásától? Ez a kérdés viccesnek tűnhet, de ez a téma nem kevésbé bonyolult. Nagyon kíváncsi esetek vannak. Néhány jó srácban, amikor feszítették és alaposan csavarják a gyorsítótárazást, a helyszín néhány napig fut. Kiderült, hogy néhány hónapon belül ezt az oldalt észrevétlenek néhány németek adatait, és optimalizálják a webhely oldalának gyorsítótárazását, ezek a németek sokáig töltötték az összes képet. Amikor az oldalt azonnal Keshában kezdték kiadni, a bot, amelynek nincs ideje ébren, szintén azonnal összegyűjti őket. Nehéz volt. Az ügy különösen nehéz az az oka, hogy ha te magad megváltoztatta a beállításokat (bekapcsolva caching), és a helyszínen után leállt, akkor ki az Ön véleménye, a hibás? Pontosan. Ha éles növekedést figyel a kérések számában, akkor nézze meg például a Google Analytics-ben, akik az oldalakhoz jöttek.

Webkiszolgáló hangolás

Milyen más kulcspontok? Természetesen az "alapértelmezett" nginx és remélem, hogy rendben lesz. Mindazonáltal mindig nem történik jól. Ezért a szerver adminisztrátorának sok időt kell fordítania a finomhangolásra és a nginx hangolására.

12. Határozza meg az erőforrások (pufferméretek) a nginx-ben

Mit kell emlékezni először? Minden erőforrásnak van korlátozása. Először is, a RAM-ra vonatkozik. Ezért a fejlécek és az összes használt puffer méretei az ügyfél és a kiszolgáló megfelelő értékeire kell korlátozódniuk. Azokat a Nginx konfigurációban kell előírni.

cLIENT_HEADER_BUFFER_SIZE__ Megadja a puffer méretét, hogy elolvassa az ügyfélkérés fejlécét. Ha a lekérdezési vonalat vagy a lekérdezési fejléc mezőt nem helyezi el teljesen a pufferben, a nagyobb pufferek, amelyeket a nagy_client_header_buffers irányelv elosztottak.
nagy_client_header_buffers Beállítja a maximális számot és puffer méretet, hogy elolvassa a nagy ügyfélkérés fejlécét.
client_body_buffer_size Megadja a puffer méretét az ügyfélkérés testületének olvasásához. Ha a lekérdezési test nagyobb, mint a kívánt puffer, akkor a teljes lekérdezési test vagy csak az ideiglenes fájlba írt.
ügyfél_max_body_size Meghatározza a lekérdezési fejléc "Tartalomhossz" mezőjében megadott ügyfélkérelem maximális megengedett testméretét. Ha a méret nagyobb, akkor az ügyfél 413 hibát ad vissza (kérjen entitás túl nagy).

13. Testreszabhatja az időtúllépéseket a nginx-ben

Az erőforrás az idő. Ezért a következő fontos lépésnek kell lennie az összes időtúllépés telepítéséhez, ami ismét nagyon fontos, hogy a Nginx beállításaiban elsőként regisztráljon.

reset_timedout_connection on; Segít harcolni az aljzatok lógása a fin-wait fázisban.
cLIENT_HEADER_TIMEOUT. Meghatározza az időtúllépést az ügyfélkérés fejlécének olvasása során.
ügyfél_body_timeout. Megadja az időtúllépést az ügyfélkérő testület olvasása során.
keepalive_Timeout. Beállítja az időtúllépést, amely alatt az ügyféllel való tartós kapcsolat nem záródik le a kiszolgáló oldaláról. Sokan félnek nagy jelentőséget kérnek itt, de nem vagyunk biztosak abban, hogy ez a félelem indokolt. Opcionálisan beállíthatja az időtúllépés értékét a tartandó HTTP fejlécben, de az Internet Explorer híres az érték figyelmen kívül hagyásáról.
sEND_TIMEOUT. Megadja az időtúllépést, ha válaszol az ügyfélre. Ha ezután az ügyfél nem fog elfogadni semmit, a kapcsolat zárva lesz.

Közvetlenül a kérdés: milyen pufferek és időtúllépések paraméterei helyesek? Itt nincs univerzális recept, minden helyzetben, hogy sajátuk van. De van egy bizonyított megközelítés. Be kell állítania azokat a minimális értékeket, amelyeknél a webhely működőképes állapotban marad (békeidőben), azaz az oldalak megadása és a kérések feldolgozása. Ezt csak teszteléssel határozzák meg - mind az asztali számítógépektől, mind a mobileszközöktől. Algoritmus az egyes paraméterek (puffer méretének vagy időtúllépésének) értékeinek megtalálásához:

Matematikailag minimális paraméterértéket mutatom.
Futtassa a webhely tesztelését.
Ha a webhely teljes funkcionalitása problémamentesen működik - a paramétert definiálják. Ha nem, növeljük a paraméter értékét, és elérjük a 2. pontot.
Ha a paraméter értéke meghaladja az alapértelmezett értéket is, a Fejlesztői csapat megbeszélése oka.

Egyes esetekben az ellenőrzés ezen paraméterek kell vezetnie újraírás / felhasználó átalakítása. Például, ha a webhely nem működik háromperces AJAX hosszú szavazási kérelmek nélkül, akkor ne emelje fel időtúllépés, de hosszú szavazás, hogy cserélje ki valami más - Botnets 20 ezer autót 3 percenként lóg, könnyen Öld meg az átlagos olcsó kiszolgálót.

14. Korlátvegyületek a Nginx-ben (Limit_Conn és Limit_req)

A Nginx is képes korlátozni a kapcsolatokat, a kérelmeket és így tovább. Ha nem biztos benne, hogy a webhelyének bizonyos része hogyan viselkedik, ideális esetben meg kell vizsgálnia, meg kell értened, hogy hány kérés lesz elviselni, és regisztrálja azt a Nginx konfigurációban. Ez egy dolog, amikor az oldal hazudik, és eljöhet és felemelheted. És egy másik dolog - amikor olyan mértékben fog menni, hogy a szerver csere. Ebben az esetben gyakran könnyebb újraindítani, mint várni a diadalmas visszatérését.

Tegyük fel, hogy az oldal szekciók vannak a beszédnevekkel / letöltéssel és / kereséssel. Ugyanakkor:

nem akarunk botokat (vagy az emberek túlterhelt rekurzív letöltési menedzserekkel), hogy hozza nekünk egy táblázatot TCP kapcsolatok letöltéseikkel;
nem akarunk botokat (vagy repülő daruk a keresőmotorok) kimerítette a DBMS számítástechnikai erőforrásokat több keresési lekérdezéssel.

E célból az alábbi típusok konfigurációját használják:

Http (limit_conn_zone $ binary_remote_addr zóna \u003d Download_c: 10m, limit_req_zone $ binary_remote_addron zóna \u003d Search_R: 10m \\ rate \u003d 1R / s; kiszolgáló (Location / Letöltés / (Limit_Conn Download_C 1; # Egyéb konfigurációs hely) Hely / keresés / (limit_req zóna \u003d search_r burst \u003d 5; Egyéb helykonfiguráció))))))

Általában közvetlen jelentéssel bír, hogy korlátozza a limit_connot és a limit_req helyeket, amelyekben drága parancsfájlok vannak (a példában a keresés meg van adva, és ez nem nyereséges). Korlátozásokat kell választani, a terhelés és a regressziós tesztelés eredményei, valamint a józan ész.

Figyeljen a példa 10 mm-es paraméterére. Ez azt jelenti, hogy a határérték kiszámítása 10 megabájt és egy megabájtos pufferrel kiemeli a szótárat. Ebben a konfigurációban ez lehetővé teszi, hogy nyomon kövesse a 320.000 TCP-üléseket. Hogy optimalizálja a memória elfoglalt kulcsfontosságú a szótárban, a $ binary_remote_addr változó, amely tartalmazza a felhasználó IP-címét bináris formában, és kevesebb memóriát igényel, mint a szokásos stringváltozó $ REMOTE_ADDR. Meg kell jegyezni, hogy a második paraméter a limit_req_zone irányelv nem csak az IP, hanem bármely más, a Nginx változó ebben az összefüggésben például abban az esetben, ha nem akarsz nagyobb proxy módot biztosítani, akkor használja $ binary_remote_addr $ HTTP_USER_AGENT vagy $ binary_remote_addr $ http_cookie_myc00kiez - de szükséges, hogy az ilyen tervek óvatosan, hiszen ellentétben a 32 bites $ binary_remote_addr, ezeket a változókat lehet lényegesen hosszabb és a „10m” bejelentett tudnak fenntartani.

DDO-k trendjei.

Folyamatosan növeli a hálózati és a szállítási szint támadások erejét. Az átlagos syn-árvíz támadások potenciálja már 10 millió csomagot ért el másodpercenként.
Különleges igény a közelmúltban élvezi a támadásokat a DNS-en. UDP árvíz érvényes DNS-kérések spoof'led forrás IP-címeket az egyik leggyakoribb megvalósítások és bonyolult szempontjából elleni támadásokat. Sok nagy orosz vállalat (beleértve a tárhelyet) tapasztalt a közelmúltbeli problémákban a DNS-kiszolgálók támadásainak eredményeként. Minél távolabb vannak az ilyen támadások, és hatalmuk növekedni fog.
A külső funkciók alapján a botnetek többségét nem kezeli központilag, hanem a peer-to-peer hálózaton keresztül. Ez a támadók lehetőséget adnak arra, hogy szinkronizálják a Botnet akcióinak időben történő szinkronizálását - ha korábban a menedzsment csapatok 5 ezer gépkocsi botnet terjednek több tucatnyi percben, most a számla másodpercekig megy, és webhelye váratlanul megtapasztalhatja a pillanatnyi fotográfiát a kérelmek számának növekedése.
A botok részesedése, amelyek teljes körű böngésző motorral vannak felszerelve, még mindig kicsi, de folyamatosan növekszik. Az ilyen támadást nehezebb leütni a beépített kézművesek, így az önfelhasználóknak a félelemmel kell követniük ezt a tendenciát.

az operációs rendszer előkészítése.

A Nginx finom beállításán túl kell vigyáznia a rendszer hálózati veremének beállításairól. Legalább - azonnal bekapcsolja a net.ipv4.tcp_syncookies-t a Systl-ben, hogy megvédje magát egy kis méretű szin-élelmiszer támadásból.

15. Tyi udvar

Figyeljen a hálózati rész (kernel) fejlettebb beállításaira az idők és a memória. Fontosabb és kevésbé fontos. Először is, figyelmet kell fordítanod:

net.ipv4.tcp_fin_timeout. Az idő, amikor az aljzat a FIN-WAIT-2 TCP fázisban tölti (várja a fin / ACK szegmenst).
net.ipv4.tcp _ (, R, W) MEM TCP aljzatok fogadó puffer méretét. Három érték: minimális, alapértelmezett érték és maximum.
net.core. (R, W) mem_max Ugyanaz a TCP pufferek esetében.

100 Mbps csatornával az alapértelmezett értékek valahogy alkalmasak; De ha legalább Gigabit van a Candide-ben, akkor jobb, ha valami ilyesmit használ:

Systl -w net.core.rmem_max \u003d 8388608 systl -w net.core.wmem_max \u003d 8388608 systl -w net.ipv4.tcp_rmem \u003d "4096 87380 8388608" systl -w net.ipv4.tcp_wmem \u003d "4096 65536 8388608" Systl - w net.ipv4.tcp_fin_timeout \u003d 10

16. VÁLTOZÁS / PROC / SYS / NET / **

Ideális az összes paraméter / proc / sys / net / ** megtekintéséhez. Látni kell, hogy milyen eltérőek különböznek az alapértelmezetttől, és megértik, hogyan kell megfelelően kiállítani. Linux fejlesztő (vagy rendszergazda), amely szétszereli az internetes szolgáltatást, és optimalizálja azt, olvassa el az atomerőmű minden paraméterének dokumentációját. Talán megtalálja a webhelyére specifikus változókat, amely segíti a helyszínt a behatolóktól, de felgyorsítja a munkáját is.

Ne félj!

Sikeres DDos-támadások napi nap után az e-kereskedelem leállítja a médiát, a média rázza, a legnagyobb fizetési rendszereket a knockoutba küldi. Az internetezők milliói elveszítik a kritikus információkhoz való hozzáférést. A fenyegetés sürgős, ezért teljesíteni kell. Végezze el a házi feladatot, ne félj, és tartsa a fejét. Te nem az első, és nem az utolsó, aki találkozik egy DDOS támadással a honlapjukon, és a hatalma, a tudásuk és a józan ész, hogy csökkentse a támadás következményeit a minimálisra.

Néhány évvel ezelőtt részletes cikket írtam a webszerver telepítéséről és konfigurálásáról a legújabb verziók alapján. Megemlítettem, hogy ez az első cikk a webszerver zóna ciklusából. Ma azt mondom, hogy egyszerű és tüskéssé teszik, hogy megvédje magát az egyszerű dDOS. támadások.

Közvetlenül foglalhatok fenntartást a DDOS szóról, ami itt nem megfelelő, de nem jöttem fel, hogy mennyire népszerűbb magyarázza meg, mit beszélünk. A teljes DDOS támadástól nem tudod megvédeni magát a webszerver beállítása részeként. Csak eltömődik az egész csatornával, és a szerver abbahagyja a válaszolást. Ha a kiszolgáló teljesítménye nem elegendő a bejövő kérések feldolgozásához és szűréséhez, akkor ott lesz. A DDO elleni teljes körű védelem érdekében teljes körű pénzeszközökre van szükség, amelyek kézzelfogható pénzügyi költségek. Az elméletben további információkat külön cikkben olvashat.

Nyilvánvaló, hogy a DDO-k elleni védelemnek megfelelőnek kell lennie az erőforrás jelentőségére. Ha van egy személyes blogod, amely nem hoz jelentős nyereséget, akkor fizessen a DDO-k elleni védelemért. Elég, ha egy ideig lefeküdjön, vagy saját védelmet nyújt. Általánosságban elmondható, hogy mindig meg kell mérni a leállási költségeket a védelemköltséggel és ennek alapján, hogy eldöntsék egy vagy egy másik módszer megvalósíthatóságát.

Tanácsot adok, hogy megvédjem a botok vagy néhány apró kártevők és csomagok egyszerű támadásait, amelyek anélkül, hogy megfelelő cselekvések vannak az Ön részéről, bármilyen probléma nélkül helyezkedhet el webhelyére vagy szerverére. Itt van egy egyszerű példa. Nincs nagyon gyenge, a fedélzeten, amely 2 yard, 8 Gigs operatív és SSD lemez.

A kiszolgálót az előző cikkem konfigurálja, amelynek hivatkozása az elején. A szerveren a WordPress webhely néhány tartalommal kerül telepítésre. És van egy kártevőnk, amely a szerveren az Apache egyszerű tesztjei a webszerver teljesítményéhez:

# AB -C 50 -N 30000 "https://hl.zeroxzed.ru/"

Csak 50 párhuzamos patak. Mit látunk a webszerverén:

Nem nagyon kellemes kép. A szerver 100% -kal van betöltve. És bár általában a kéréseket feldolgozza, és általában megfelelően működik. Nem is lelassul, de még mindig rossz. És ha 3 szerver és 100 áram van? A virtuális gépen még egy tesztet sem veszítenek el, és virtuális gépen végeznek el a különböző férfit, és ilyen dolgokat futtatnak a DDOS támadás utánzásával.

Általában, ha nem tesz semmilyen védelmet a szerver egyáltalán, akkor bárki képes lesz teljesíteni némi kényelmetlenséget nélkül speciális problémákat. Az ilyen "támadás" nem nehéz. Aztán elmondom, hogyan kell csinálni.

DDOS védelem iptables alkalmazásával

A legegyszerűbb támadás elleni védelem érdekében tűzfalat fogunk használni - iptables., Modul kernel ipset. Az IP és az önírású szkriptek nagy listájának tárolása. A tűzfalért lásd a cikkemet -. Itt nem fogom megállítani.

Ipset Setup kérdés, amelyet részletesen figyelembe vettem a cikkemben. Azt tanácsolom, hogy lássa az anyagot, mivel közvetlenül kapcsolódik ehhez a cikkhez és kiegészíti azt.

Tehát folytatjuk, hogy létrehozzuk az egyszerű védelmet a DOS támadásokkal szemben számos IP-címmel. A kezdethez ellenőrizze a parancsot, amely megmutatja nekünk az egyes IP-címek közötti kapcsolatok számát:

Itt van a nyugalomunk sértője, megpróbálja megszervezni a főnökünket a szerverünkön. Most rajzoljon egy olyan szkriptet, amely blokkolja az összes, aki több mint 50 egyidejű kapcsolatot állítja be a webhelyen.

Elvileg semmi sem kommentálni. Veszünk egy listát az olyan kapcsolatokról, amelyek éppen kiderült, hasonlítsa össze az első oszlopot, ha nagyobb, mint 50, akkor a második oszlop eredménye, ahol az IP-cím rögzítésre kerül, adja át a fájlt.

Ezután olvassa el ezt a fájlt, és adja hozzá az összes IP-címet az Ipset listához, amelyet sok_conn. Korábban meg kell teremteni. Erről részletesen beszéltem a cikkben, amelyen a link fent látott, de ismét megismételtem itt:

# ipset -n much_conn iphash

A lista tartalmának megtekintése parancs lehet:

# Ipset -l such_conn

Most meg kell adni egy olyan szabályt, amely szerint minden iptables kapcsolatot a megadott IPSet lista blokkolva lesz.

# iptables -a input -m set --match-set much_conn src -j csepp

Csak abban az esetben, ha figyelmeztetek arra, hogy az iptables szabályok konfigurálása előtt ellenőrizze a kiszolgáló konzolhoz való hozzáférését. Minden történik, egyszerűen csak tévedhet, másolhat és beilleszthetsz, amire szüksége van.

Mindent, blokkoltuk mindenkit, aki tömeges spam-kapcsolatokat hoz létre a szerverhez. Az 50 csatlakozáskor korlátozható a helyszínen, lehet, hogy csökkenteni kell, ha valaki kevesebb kapcsolatot fog nyitni egy IP-ről.

Az egyetlen pillanat, amit mondani akarok. Én magam nem ellenőriztem, hogy hány kapcsolat van nyitva a keresési botok, amikor megérkeznek az oldalra. Gyanítom, hogy nyilvánvalóan nem 50, és még 30, de valószínűleg nem ellenőriztem. Általában legyen óvatos, ha ezt az eszközt használja.

Ez a szkript a koronában, és minden percben futtatható. De személyesen nem tenném ezt. Azt javasoljuk, nyomon szerver erőforrások és fuss hasonló eszközöket csak akkor, ha a kiszolgáló működik a határ képességeit, és kézzel írt, és gondoskodott arról, hogy valaki fog rendesen csatlakozásokkal. Ezt követően vezette a korona szkript idejét. Amikor a DDOS leáll, húzza ki.

Jó lenne, ha valahogy automatikusan megtisztítja a tiltott, eltávolítását, azok, akik nem kapcsolódnak hozzá egy napig, de ez nagyban bonyolítja a feladatot. Legalább egy naplóra van szüksége a blokkoló listán, mentse az utolsó fellebbezési időt. Mindez feldolgozása, számítása. Általában a feladat azonban nem túl nehéz, de nem triviális. Nem akartam ezt megtenni.

Van, bár nem nagyon elegáns, de egy egyszerű megoldás erre a problémára. Hozzon létre egy listát az IPSET-ról egy meghatározott életidővel időtúllépés.. Például, mint ez:

Ipset -n much_conn iphash timeout 3600

Ebben az esetben az Ipset listában az IP-tárolt IP-rekord 3600 másodpercig vagy 60 percen keresztül kerül tárolásra.

Meg kell érteni, hogy ebben a példában 1 IP-címmel az IpSet használatához nincs értelme, azonnal megtilthatja az iptables eszközeit. Az Ipset csak akkor szükséges, ha ez a lista legalább több száz sor. Ha több tucat cím van, elég egy iptables.

A webszerver napló szerverének elemzése a DDO-k elleni védelem érdekében

Tekintsünk egy másik egyszerű, de még mindig összetettebb DDOS támadást, ha a típusai lekérdezések különböző IP-ből érkeznek. Ez az, egyszerű botnet, talán még néhány olcsó vds szerverrel is összeállt. Egyidejű kapcsolatok nem sokat, de ha nehéz helyszínek van, és a támadó megtalálja a gyenge helyet (például egy keresés), akkor elegendő lehet a webhely elhelyezéséhez.

Az iptables-en keresztül fogjuk betiltani, és a tilalom címeinek listáját a webszerver naplókból kivonják. Ehhez engedélyezni kell a naplózási kérelmeket a webszerverre. Például a Nginxben ez felelős a virtuális állomás e beállításáért:

Access_log /web/sites/hl.zeroxzed.ru/log/access.log fő;

Minden alkalommal nem fogjuk elemezni a teljes naplófájlt. Ez a művelet maga melegíti a webszervert. Vegyük az utolsó 1000 sort a napló naplóból, és fontolja meg az egyik IP-ben lévő kapcsolatok számát a Type Tartalommal, például a HTTP 1.0 főoldali kéréssel, "GET / HTTP / 1.0". Ha észreveszi a Botnet másik állandó funkcióját, akkor használja, használja. Lehet, hogy ugyanaz a felhasználói ügynök vagy valami más. Tegyük fel, hogy a támadó sebezhető helyre csökken, ez lesz az oldal címe.

# Farok -1000 /web/sites/hl.zeroxzed.ru/log/ssla-access.log | EGREP "GET / HTTP / 1.0" | Awk "(Nyomtatás $ 1)" | Rendezés -n | Uniq -c.

Ennek a parancsnak az eredménye megközelítőleg egy ilyen lista lesz.

Ebben az esetben egy kicsit másképp használtam, és egyszerűen hoztam egy listát mindazokról, akik a főoldalra kerültek. De itt láthatod a tiltó jogsértőt.

Hasonlóan rajzolunk az előző szkripthez az automatikus reteszeléshez, akik túl sok kérelmet küldenek webhelyünkre, és teljesítményproblémákat hoznak létre. Ismét ismételtem ismételten, ha nincs probléma a termelékenységgel, nem javaslom extra mozgásokat.

#! / Bin / sh fars -1000 /web/sites/hl.zeroxzed.ru/log/sla-access.log | EGREP "GET / HTTP / 1.0" | Awk "(Nyomtatás $ 1)" | Rendezés -n | Uniq -c | Rendezés -n | Farok -n100 | Awk "(ha ($ 1\u003e 50) nyomtatás $ 2)"\u003e /root/ddos/mch_gets.txt Sleep 3 lista \u003d $ (macska /root/ddos/mch_gets.txt) az IPNET-hez a $ list in $ listában $ IPNET kész

Itt ugyanúgy csináljuk, mint korábban. Azok, akik több mint 50 azonos kérést tettek a maszkunkra a naplófájl utolsó 1000 sorában a tilalomra.

Felhívom a figyelmet arra a stringre, amelyen szűrődik a kéréseket. Ebben az esetben csak példát mutatott. Ne vegye be és alkalmazza az űrlapot, ahogy azt mutatom. Megadom a technikai képességeket és a megközelítést. Be kell állítania és kalibrálnia kell a rendszert a helyemben. Fontos megérteni ezt, és nem alkalmazzák a döntést elgondolatlanul. Csak kár lesz.

Ne felejtse el létrehozni egy külön lista létrehozását az IpSet-ben, és adjon hozzá egy külön szabályt az iPples. Használhatja a már meglévő listát és a hozzáadott szabályt az előző példában, de javaslom mindent megoldani. Olyan kényelmesebb a későbbi elemzéshez.

A DDOS-támadás során add hozzá ezt a szabályt Cronnak, és végezzen percenként. A támadás befejezése után a parancsfájl kikapcsolható. Elvileg folyamatosan távozhatsz, de itt gondosan kell gondolkodnod és becsüld meg, hogyan kell nézni. A fő elv nem káros.

Banya botok helytelen hivatkozással

194.67.215.242 - - "Post /index.php http / 1.1" 200 913 " g0dfw4p1.ru."" Mozilla / 5.0 (Windows NT 6.0, RV: 34.0) GECKO / 20100101 Firefox / 34.0 "" - "

A helyes hivatkozási mezőnek tartalmaznia kell a http vagy a https-t, vagy üres. Mind egyébként biztonságosan blokkolhatja vagy visszaküldheti a hiba állapotát. A szekcióban hozzá kell adni a virtuális gazda konfigurációját szerver ().

Ha ($ http_referer! ~ * ^ ($ | Http: // | https: //)) (Visszatérés 403;)

Ezt követően ellenőrizze a Nginx konfigurációt és újra.

# Nginxt -t # nginx -s újratöltése

Ha egyfajta botot veszel egy adott hivatkozással, akkor megtilthatja. Ehhez hozzáadhat egy állapotot, vagy módosíthatja. Például, mint ez:

Ha ($ http_referer \u003d "https://bots.ru/dostanim_tebya.html") (Visszatérés 403;)

Ezenkívül mindezeket a botokat egyszerű szkript segítségével lehet tiltani az iptables-en, mint a fenti példákban. By the way, azokat azonnal betilthatják, a HTTP-kérések megtekintését még mielőtt Nginxba esnek, például a Ngrep használatával, de ez egy nehezebb feladat. Nem mindannyian tudják, hogyan kell csinálni, vannak árnyalatok, és minden ismeri a Nginx-et. Ez nem lesz sok nehéz megvalósítani ezt a módszert.

DDOS védelem a Nginx modulokkal - Limit_Conn és Limit_req

Megosztom egy másik egyszerű módját a kiszolgáló terhelésének csökkentése érdekében, és részben védi a DDO-kat a Nginx modulokkal - limit_conn. és limit_req. Nem nehéz konfigurálni őket, részben az első modul eredménye az elején leírt első két DDOS védelmi módszerrel metszik. Egyszerűbb testreszabás, így ha nem tudsz megbirkózni ezekkel a módszerekkel, kipróbálhatod ezt.

Ezeknek a moduloknak az a jelentése, hogy korlátozhatjuk a megengedett kapcsolatok egyidejű mennyiségét a webhelyen, és egy másik időegységenkénti kapcsolatok számát.

A példa szerint korlátozom az egyidejű kapcsolatok számát egy IP-számból az 50 IP-számból, és az egyidejű kérések száma legfeljebb 2 másodpercenkénti dinamikus tartalmára. Ez megoldódik egy splash ( robbanás.) Legfeljebb 5-ig terjedő lekérdezések. Megmagyarázom, hogyan kell megérteni ezt a fröccsenést, mivel nem értettem azonnal, hogy pontosan mit jelent.

Ha a másodpercenkénti beállított kérelmek számát meghaladjuk, akkor a végrehajtásuk késik, és a megadott sebességgel beépülnek a sorba. Ennek a sornak a mérete megegyezik a burst értékével. Minden olyan kérés, amely nem elegendő hely a sorban, hibás lesz. Azaz, ha a kérelmek másodpercenként 4, majd a 2 végeznek azonnal és a másik 2 lesz a sorban. És ha 10, akkor a 2 azonnal elvégezhető, 5 lesz egy sorban 2 db másodpercenkénti végrehajtás, és a többi hiba lesz.

Ezen feltételek alapján a kapcsolat korlátozását a kontextusban kell telepíteni szerverés a megfelelő dinamikus tartalomhoz való hozzáférés a megfelelő elhelyezkedés. Ugyanakkor az irányelvek által használt zónák leírása a http..

Íme egy példa a nginx config végrehajtására megállapított korlátozásokat annak érdekében, hogy megvédje DDOS támadások.

Http (... limit_conn_zone $ binary_remote_addr zóna \u003d perip: 10m; limit_req_zone $ binary_remote_addron zóna \u003d dinamikus: 10m sebesség \u003d 2R / s; ... kiszolgáló (... limit_conn perip 50, ... helye ~ \\. ... limit_req zóna \u003d dinamikus burst \u003d 5 nodeley; ...))))))))

Miután újraindítja a Nginxot, és ellenőrizze, hogyan működik a korlátok. Az elvégzett dinamikus kérések számának korlátozása egyszerűen a böngészőben nagyon gyorsan megnyomható. Ha elég hamis vagy, akkor hamarosan látsz egy képet

és a naplóba való belépés a hibákkal:

2017/11/30 15:25:26 9773 # 9773 * 51482 korlátozása kéri, Excess: 5,664 Zone "Dynamic", Ügyfél: 195.91.248.43, Kiszolgáló: HL.zeroxzed.ru, kérés: „GET / HTTP / 2.0 ", Host:" hl.zeroxzed.ru ", referrer:" https://hl.zeroxzed.ru/2013/03/15/feated-image-vertical/ "

A kapcsolatok számának korlátozása ugyanazt a segédprogramot ellenőrizheti abszolútMondtam a bevezetésben.

017/11/30 15:38:56 9773 # 9773 * 53938 korlátozása Connections Zone "Perip" Ügyfél: 94.142.141.246, Kiszolgáló: HL.zeroxzed.ru, kérés: „Get / wp-content / UPLOADS / 2013 /03/the-dark-night-rises.jpg http / 1.0, host: "hl.zeroxzed.ru"

Ne felejtsük el, hogy a tesztet nem egy adott oldalon el kell indítani, akkor a dinamikus tartalom teljesítményének korlátozására kerül sor, de valami másra. Például, mint a példáján, a képen.

A korlátozások kibocsátásakor ne felejtsd el ellenőrizni, hogy a keresési botok ne esnek-e e korlátozásokba. Alapértelmezés szerint nem próbálnak megnövekedett terhet a webhelyen. Kívánt esetben a Yandex robotot a robots.txt segítségével lehet megadni, milyen gyorsan vizsgálhatja webhelyét. És a robot Google ugyanezt a webmester segítségével.

Következtetés

Átnéztem a legegyszerűbb módja, hogy megvédje a webszerver nem kevésbé egyszerű DDOS támadások, amelyek több, mint egy kényeztetést. Egy komoly támadás, amely egyszerűen kitölti a teljes bejövő csatorna csatornát, nem fogja észrevenni a védelmet. Mindazonáltal meg kellett győződnöm meg, hogy ezeknek a módszereknek a hatékonysága bizonyos támadások tükrében.

Még mindig van egy hatalmas számú webszerver, amely még a segédprogramból sem védett. abszolút :) Tudom, hogy miről beszélek, mivel az ilyen szerverek találkoznak. És van egy csomó mindenféle bot és egyszerű program, amely megtalálható az interneten és a kabáton, olyan merész helyeken, amelyek egyáltalán nem állnak készen a terhelésekre.

Van még egy egyszerű, ugyanolyan egyszerű, mint amennyit leírtam, és hatékony a botoktól, amelyek nem értik átirányításokat és cookie-kat. Nem írtam le, mert semmi sem ellenőrizni, és csak fáradt volt, hogy írjon egy cikket, nagyon nagy volt. Hosszú ideig írtam és szerkesztettem, szkripteket és beállításokat gyűjtem különböző szervereken, és emlékszem arra, hogy egyszer megtettem. Aztán mindezeket külön ellenőrizte.

A védelem lényege az, hogy a Nginx segítségével konkrét cookie-kat adunk ki a felhasználónak, majd átirányítja a kért oldalt. Ha a bot nem érti a cookie-kat, vagy átirányítja, akkor leesik. A normál felhasználók nem észlel semmit. Talán később elmondom neked ezt a módszert, és hozzáadhatok egy cikket. Eközben. Örülök, hogy megjegyezem a cikkek érdemeit.

Online Linux tanfolyam

Ha vágya van arra, hogy megtanulják, hogyan építsenek és tartsák fenn a rendkívül hozzáférhető és megbízható rendszereket, azt javaslom, hogy megismerjem online tanfolyam "Adminisztrátor Linux" Otusban. A kurzus nem kezdőknek, a felvételre szükséged van az alapvető ismeretekre a hálózatokon és a Linux virtuális telepítésére. A képzés 5 hónapig tart, miután a tanfolyam sikeres diplomásai képesek lesznek átadni az interjúkat a partnerekről. Mi ad neked ezt a kurzust:

Linux architektúra ismerete.
A modern módszerek és adatelemzés és adatfeldolgozó eszközök elsajátítása.
A szükséges feladatok konfigurációjának kiválasztása, a folyamatok kezelése és a rendszer biztonságának biztosítása.
A rendszergazda fő működési eszközeinek birtoklása.
A telepítés, a Linux alapján épített hálózatok beállításainak és karbantartásainak megértése.
A felmerülő problémák gyors megoldásának képessége és stabil és megszakítás nélküli rendszerműködés biztosítása.

Ellenőrizze magát a bevezető teszten, és nézze meg többet a szoftverprogramból.

A webes projektek gyakran találkoznak a DDOS támadásokkal. Ma az egyik alapvető módja annak, hogy megvédje a http-árvízből.

Bevezetés:

A közelmúltban egy támadás történt az egyik barátom projektjével, valószínűleg megtámadta a tapasztalatlan hackert, mivel a támadást egy IP-címből végezték.

A rönkök elemzése során azt találták, hogy a támadó többször is feltölti a főoldalt, és a kiszolgáló megpróbálja feldolgozni ezeket a kéréseket, és nem tudja.

Az ilyen jellegű támadások elleni védelem érdekében a Proxy Server Nginx és a Standard NGX_HTTP_LIMIT_CONN_MODULE modul használata

NGX_HTTP_LIMIT_CONN_MODULE modul Lehetővé teszi, hogy korlátozza az adott kulcs, különösen az egyik IP-című kapcsolatok számát.

Nem veszik figyelembe az összes kapcsolatot, de csak azok, amelyekben a szerver által feldolgozott kérelmek vannak, és a kérés fejléc már elolvasta.

Más szóval, korlátozhatunk egy IP-címre vonatkozó kérelmek és kapcsolatok számát. Ez elég ahhoz, hogy megvédje a gyenge és közepes http-árvíz támadást.

A korlátozás beállításához a limit_conn irányelvet használjuk

Nginx beállítása a DDOS elleni védelem érdekében:

limit_Conn:

limit_Conn Megadja az egyik IP-ről szóló maximális megengedhető számát. Ha ezt a számot meghaladja, a kérelemre válaszul a kiszolgáló hibát ad vissza 503 (A szolgáltatás átmenetileg szünetel).

Miután megkapta az 503-as hiba, a támadó abbahagyja az adatbázis-kiszolgáló, például a MySQL hasznos terhelését, ezáltal kirakodva.

De mielőtt a limit_connot használná, hogy megvédje a DDOS támadások Nginx-el, meg kell találnunk és telepítjük a limit_conn_zone-irányelvet

limit_conn_zone:

Szintaxis: limit_conn_zone Zóna gomb \u003d. név: Méret;
Beállítja a megosztott memória zóna paramétereit, amely az állapotot különböző kulcsértékekhez tárolja. Az állam különösen tartalmazza a csatlakozások jelenlegi számát. Kulcsként használhat szöveget, változókat és ezek kombinációit. Az üres kulcsértékű kérelmeket nem veszik figyelembe.
Példa a használatra:

Példa a használatra

limit_conn_zone $ binary_remote_addr zóna \u003d addr: 10m;

Ez az irányelv szükséges az egyes IP-címek állapotának tárolásához. Fontos! Ez az irányelvnek közvetlenül a http után kell mennie a Nginx.conf-hez (.

Nginx.conf konfigurációs példa a limit_conn_zone esetében:

Konfigurációs példa

http (limit_conn_zone $ binary_remote_addr zóna \u003d addr: 10m; ...

http (

limit_Conn _ Zóna $ bináris_remote_addr zóna \u003d addr: 10m;

. . .

A limit_conn_zone irányelv telepítése után a limit_conn telepítéshez fordulunk.

Szintaxis: limit_conn.zóna száma;

Kérjük, vegye figyelembe, hogy a zónát a Limit_Conn_Zone-ben telepített zónából kell bevenni, az ADDR-ben.

A 3. paraméter "szám" jelöli az egyik IP-címről nyitott kapcsolatok számát.

Az ADDR zónához tartozó 3 egyidejű kapcsolat korlátozása érdekében írja be a következőket:

limit_conn.aDDR 3;

Példa egy konfigurációra a DDOS támadások elleni védelemhez a Nginx és Limit_Conn használatával:

http (limit_conn_zone $ binary_remote_addr zóna \u003d addr: 10m, ... szerver (hallgassa 80, ... hely / (limit_conn addr 3; ...))))

http (

limit_Conn _ Zóna $ bináris_remote_addr zóna \u003d addr: 10m;

Valójában, miért tiltja meg a földrajzi alapterülethez való hozzáférést? Igen, a DDOS támadásban részt vevő IP-címek 80% -a, mivel általában olyan országokba tartozik, amelyek lakói soha nem lépnek be ezen az oldalon, természetesen kizárólag egyénileg minden erőforráshoz, és ha tudod, hogy a látogatók egy része Etiópiából vagy Chileből származik , blokkolja őket, alig akarod. Ügyfeleim többségében a látogatók földrajzi elhelyezkedése általában Európára és a korábbi USSR-re korlátozódik, a többi biztonságosan figyelmen kívül hagyható.

Leírt módszer az elbocsátás országok blokkolására webszerver segítségével nginx és geoip. A modul egyedül, és még inkább a probléma megoldja a problémát, csak egy, többféle intézkedésből (a rendszermag, a tűzfal, a teljes munkaidős szolgáltatások, további szoftverek beállítása), hogy minimalizálja a Az ilyen típusú támadókiszolgáló és webhelyek által alkalmazott kár, található.

Olyan projektek, amelyek gyakran szükségük van erre a fajta védelemre, megpróbálok kezdetben emelni anélkül, hogy az Apache Web Server részvétele lenne, azaz egy kötegen nginx - FastCGI..

Tehát helyezze el és állítsa be ezt a háztartást az operációs rendszert futtató kiszolgálón FreeBSD 8.2 és64..

Ez modul lenne geoip. Szerzett, további könyvtár szükséges, beállítva:

FreeBSD82 / usr / ports # make -c net / geoip Telepítés Tiszta

FreeBSD82 / usr / ports # make -c www / nginx Telepítse a tiszta

az összeszerelési opciókban engedélyeznie kell geoip. modul nginx, egy tartályt elhelyezve az elemtől Engedélyezze a http_geoip modulot.

Ezután megyünk az oldalra http://www.maxmind.com/app/geoliteountry és letöltés legfrissebb Geolite Country bináris formátumEz az országok alapja és az IP-címek megfelelő blokkjainak szabad lehetősége. Csomagolja ki az archívumot, és dobja a fájlt Geip.dat. A mappában USR / LOCAL / ETCH / NGINX / CONF / GEO. A konfigurációk szerkesztése nginx.

Nyisd ki nginx.conf., Adja hozzá a részt http. Következő blokk-irányelv:

Geoip_country /usr/local/etc/nginx/conf/geo/geoip.dat; # Connect Geip Base Térkép $ geoip_country_code $ bad_country ( # A térképmodul olyan változókat hoz létre, amelyek értékei más változóktól függenek, nagyon hasznos dolog Alapértelmezett 1; # Érték alapértelmezés szerint tartalmazza a geo / good_countries; # Tartalmazza a fájlt, később később }

Ez a blokk térkép, azt jelenti, hogy minden ország az adatbázisban van, alapértelmezett tiltott, és a fájlban good_countries.Az engedélyezett országok szerepelnek. Ha például a megengedett országok, ha tilos, akkor könnyedén megfordíthatja ezt a logikát, és létrehozhat egy fájlt bad_countries. A tiltott országok listájával, amelyek lehetővé teszik mindenki számára.

Most a fogadó beállításai. Például egy külön mappában tartom a gazdagépeket otthont ad., Mindegyik a fájlban.

Szerver (Hallgat IP: 80, Server_Name TestHost.com, ha ($ bad_country) ( # Ha ez a változó telepítve van, akkor ha az ország nem szerepel a Good_Countries fájlban Visszatérés 444; # Ügyfél kiadása üres válasz (nincs szükség 403 hiba vagy más) } ................. ................. }

Most vissza a fájlba good_countries.. Minden nagyon egyszerű itt, azoknak az országoknak, amelyek hozzáférhetnek a webhelyhez, a következő formátumban szerepelnek:

Tm 0; UA 0; UZ 0; Ru 0; ....... ....... stb.

Vagyis minden ország számára elegendő lenne, elegendő ahhoz, hogy hozzáadja a kétbetűs kódot és 0-at, majd újraindítja a Nginx konfigurációt:

FreeBSD82 / # nginx -s újratöltése

Az országok kódjai, kétszer, a Google.

Ellenőrizze, fut geoip. A modul vagy sem, lehetséges, eltávolítja az engedélyezett országok listájából, és megpróbálja belépni a webhelyre.

Valójában ez a GeoIP modul Nginx használata általános rendszere, hogy megvédje a DDO-t.

Természetesen sok más lehetőséggel állhat rendelkezésre a modul használatához a webhely látogató földrajzi elhelyezkedéséhez kapcsolódó különböző feladatok megoldásához.

Ezt úgy lehet ülni, hogy nem érintsz senkit, és aztán hívja, és azt mondja, hogy a szolgáltatások lassan működnek, 2-3 percig nyitott helyek sikerült 504 hibát termelni.
Ideges mászás kaktuszokban, és van:

Az alábbiakban lesz az a parancsok, amelyek segítenek megérteni, mi történt, és pontosan DDO-k.

Először azt javaslom, hogy olvassa el a cikket abban, hogy részletesen leírja, hogy mely naplók érdekesek számunkra, hogyan lehet olvasni a felső parancs kimenetét és a PS-csapat használatát. Mindegyikük hasznos lesz számunkra, hogy megértsük, milyen házigazdák vannak a támadáson, és milyen szűk keresztmetszetek vannak a szerveren.

Milyen csapatok, és mit tudunk meghatározni?

Elkezdeni, láthatja az Apache folyamatok futtatási számát. Ha több mint 20-30 több mint 20-30, akkor valami nem így van.

Megnézzük az Apache folyamatok számát a Debianban:

PS AUX | Grep Apache | WC -L.

Megnézzük az Apache folyamatok számát a Centos-ban:

PS AUX | GREP httpd | WC -L.

Ez a parancs láthatjuk a szerverhez való kapcsolatok számát:

Cat / ProC / Net / IP_Conntrack | WC -L.

Szintén a mutató, hogy a szerver jön a szerver szolgálhat a kapcsolatok száma 80 vagy 443 port. Itt vannak a számok megmutathatják ezt a számot:

Netstat -na | Grep: 80 | WC -L Netstat -na | GREP: 443 | WC -L.

Még mindig ilyen sokféle DDOD van, mint syn. Az alábbi parancs, amely lehetővé teszi, hogy meghatározza a 80 és 443 portok syn kéréseinek számát:

És ez a parancs megmutatja a SyN Kérelmek számát:

Netstat -n -t | GREP SYN_RECV | WC -L.

A következő parancs lehetővé teszi számunkra, hogy megértsük, hogy milyen tartományban van a legtöbb kérés:

Tcpdump -npi eth0 port domain

Most nézzük meg, hogy hány kérés érkezik minden egyes IP-ről. Ez a parancs az összes portot mutatja:

hasonló parancsok:

Ez a parancs csak a 80 portra vonatkozó kérelmek számát mutatja:

Ez a parancs a 80 portra vonatkozó kérelmeket jeleníti meg, nem számolva őket, azaz "Egyszerűsített", de a "legteljesebb" kimeneti opció:

A legaktívabb IP kiszámítása is megnézheti, hogy a kikötők milyen portokból indulnak. Itt például az IP 127.0.0.1 helyettesített:

Netstat -na | Grep 127.0.0.1

By the way, ha nem konfigurálja a szerverállapot az Apache-on, akkor a kiszolgáló állapota megtekinthető a CLI-ben:

Apachectl állapot.

Naplófájlok

A globális Apache naplók, a Debian, általában ott vannak:

/var/log/apache2/error.log.
/var/log/apache2/access.log.

/var/log/httpd/error.log.
/var/log/httpd/access.log.

A globális Nginx naplók ott vannak:

/var/log/nginx/error.log.
/var/log/nginx/access.log.

Továbbá ne felejtse el megtekinteni a virtuális gazdagépek naplóit, ha a gazdagépek konfigurálva vannak. Mi érdekli a legnagyobb napló, hogy "növekszik" előtt.

Szükséges meg kell keresni ezeket a naplókat anomáliát, nevezetesen ugyanolyan típusú kérelmeket, amelyek felhasználói ügynökök (vagy ugyanazokkal) rendelkeznek, számos kérés ugyanabból az IP-ről, a virtuális gazdagép megadása nélkül, stb.

Ahhoz, hogy azonosítsa az adott IP-t a webhelyre vonatkozó kérések számával, ez a parancs:

Macska hozzáférés.log | Awk "(Nyomtatás $ 1)" | Rendezés | Uniq -c.

A Logtop segédprogram segítségével statisztikákat is kaphat IP-csoportosítással.

Kezdje, telepítse ezt a segédprogramot:

Apt-get install Git Libncurses5-dev Uthash-Dev GCC # az esetre, ha nincs csomag helyes működését Git Git Clone https://github.com/julienpalard/logtop.git

És most statisztikát kapunk:

Fars -f access.log | Awk ("Nyomtatás $ 1, fflush ();") | Logtop.

A következő parancs segít nekünk azonosítani a népszerű felhasználói ügynökök azonosítását:

Macska hozzáférés.log | Awk -f \\ "" (PRINT 6 $) "Rendezés | Uniq -c | sort -n

Hogyan kell blokkolni?

Mindenesetre az iptables-t kell állnia. Valószínűleg nem konfigurálható, különösen ha nem tudja, mi az. Korábban már írtam egy cikket arról, hogyan kell használni: "", így csak a szükséges parancsokat adom meg a probléma megoldásához és most.

Így lehetséges blokkolja a TCP kéréseit 80 portra egy adott IP-ről:

Iptables -a input -p tcp --dport 80 -s 12.34.56.78 -j csepp

Így vagyunk blokk lekérdezések minden portra egy adott IP-ről:

Iptables -a input -s 12.34.56.78 -j csepp

A már blokkolt lista megtekintése Ezeknek a csapatoknak adhatjuk:

Iptables -n -n.

Iptables -l -n -N -line-számok

Ha szükségünk van távolítsa el a konkrét IP blokkolását, használhatja ezt a parancsot

Iptables -d bemenet -s 1.2.3.4 -j csepp

vagy lehetséges törölje a szabályt a számmalAz iptables -l -N -N -N -N-Numbers parancs áttekintése után:

Iptables -d bemenet 6

Az összes szabály törlése, Használhatja a csapatot:

Iptables -f.

Néhány megelőzés, a DDO-k elleni védelem érdekében ...

Vannak további szabályok, amelyek képesek lesznek megvédeni minket a gondolat nélküli botokból, amely terhelést hoz létre a szerveren.

Telepítjük a következő parancsot maximális számú kapcsolatok száma egy IP-ről 80 porton:

Iptables -a input -p tcp --dport 80 -m conlimit --connlimit felett 128 -j csepp Iplables -a bemenet -p tcp --dport 80 -j Elfogadva

Azonos Lehet, hogy I. a DNS-hez.:

Iptables -a input -p UDP --dport 53 -m conlimit --Connlimit felett 16 -j drop iptables -a bemenet -p UDP --dport 53 -j Elfogad

Az iptables következő szabálya megakadályozza a tippünk nevét. A DDO-k folyamán általában nem nyitott kapcsolattal rendelkező csomagot kapunk a telepített szin- és ACK zászlókkal (ez a zászlók kombinációja csak a SYN csomagra adott válasz). Ez azt sugallja, hogy valaki küldött egy másik Syn Host hostot a nevünkből, és a válasz jött hozzánk.
E szabály szerint a fogadónk RST csomaggal válaszol, miután megkapta a támadott gazda bezárását.

IPTABLES -I INPUT -M CONTTRACK - CCTSTATE ÚJ, INVALIC -P TCP --TCP-zászlók Syn, Ack Syn, ACK -j elutasítás - TCP-reset

Iptables-Save\u003e /etc/Iptables.Rules

Mi mást tudnál tenni?

Ez nem gátolja meg egy kicsit „outstuning” a kernel, hogy egy finom beállítását az Apache és nginx (ha megéri), \u200b\u200btegye a kiegészítő modulok és csomagok elleni támadások, például fail2ban, mod_evasive, modsecurity ..

De mindezek a más cikkek témái, amelyek hamarosan meg kell írni ...