Nginx ochrana pred útokmi DDOS. Ochrana DDO s ngginxom vytváraním povoleného zoznamu adries IP

Boj s útokmi DDOS - práca je nielen zložitá, ale aj fascinujúca. Nie je prekvapujúce, že každý SYSADMIN sa najprv snaží organizovať obranu na vlastné - najmä preto, že je to stále možné.

Rozhodli sme sa vám pomôcť s týmto ťažkým a publikovať krátke, triviálne a univerzálne rady o ochrane vašich stránok pred útokmi. Znížené recepty vám nepomôžu vyrovnať sa s akoukoľvek útokom, ale z väčšiny nebezpečenstiev budú spasení.

Správne prísady

Krytá pravda je, že mnohé stránky môžu dať každého, kto chce používať pomalý útok, pevne zabíjať Apache, alebo usadzovanie tzv Všetky naše budúce tipy na ochranu DDO sú založené na nasledujúcich dôležitých podmienkach.

1. Odpojte systém Windows Server

Prax navrhuje, aby stránka, ktorá funguje na Windows (2003 alebo 2008, nie je bez ohľadu na to), v prípade DDoS je odsúdený na. Dôvod zlyhania spočíva v Windows Network Stack: Keď sa pripojenie stanú veľa, server určite začne reagovať zle. Nevieme, prečo Windows Server funguje v takýchto situáciách tak renomovaných, ale narazili na to viac ako raz a nie dva. Z tohto dôvodu tento článok pôjde o prostriedky ochrany proti útokom DDO v prípade, keď sa server točí na Linuxe. Ak ste šťastný majiteľ s moderným jadrom (počnúc od 2.6), potom bude iptables a nástroje iPset použijú ako primárny nástroj Toolkit (rýchlo pridať IP adresy), s ktorým môžete rýchlo zakázať roboty. Ďalším kľúčom k úspechu je správne varená sieťová zásoba, ktorú budeme tiež hovoriť.

2. Časť s Apache

Druhou dôležitou podmienkou je odmietnutie Apache. Ak ešte nie ste hodinu, stojí za to Apache, potom aspoň vložte do pamäte caching proxy pred ňou - Nginx alebo LightTPD. Apache "Je mimoriadne ťažké dať súbory, a ešte horšie, je to na základnej úrovni (to znamená, že nie je ohrozený pre nebezpečný spomalený útok, ktorý vám umožní ukončiť server takmer z mobilného telefónu. Bojovať proti rôznym Typy Shulloris, Apache Používatelia prišli s patch prvým anti-Slowlorisdiff, potom mod_noloris, potom mod_antiloris, mod_limitipconn, mod_reqtimeout ... ale ak chcete dobre spať v noci, je ľahšie vziať http server, nezraniteľný spomalenie na úrovni kódu architektúry. Preto sú všetky naše ďalšie recepty založené na predpoklade, že na prednej strane sa používa nginx.

Bojovať z DDOs.

Čo ak ddos \u200b\u200bprišiel? Tradičnou technikou sebaobrany je čítať súbor protokolu HTTP Server, napíšte vzor pre Grep (robotovanie robotov) a zakázať každého, kto spadne pod ňou. Táto technika bude fungovať ... ak máte šťastie. Batnets sú dva typy, obe sú nebezpečné, ale rôznymi spôsobmi. Jeden úplne prichádza na stránku okamžite, druhý je postupne. Prvý prvé zabíja všetko a hneď, ale logy sa objavujú v protokoloch úplne, a ak im zakazujete a ohnite všetky IP adresy, potom ste víťaz. Druhý botnet položí lokalitu jemne a starostlivo, ale bude musieť zakázať, možno počas dňa. Je dôležité pochopiť akúkoľvek správcovi: Ak sa plánuje bojovať proti grep, potom musíte byť pripravení venovať boj proti útoku na pár dní. Nižšie sú uvedené rady, kde môžete dať slamky vopred, aby to nebolo tak bolestivé pádu.

3. Použite modul testcookie

Možno najdôležitejší, účinný a prevádzkový recept tohto článku. Ak DDOS príde na vaše stránky, potom sa môže stať najúčinnejším spôsobom, ktorý sa môže stať modul @KYPRIZEL COEXLER. Myšlienka je jednoduchá. Najčastejšie sú roboty, ktoré implementujú povodne HTTP, skôr hlúpy a nemajú http cookies a presmerovanie mechanizmov. Niekedy pokročilejší - taký môže používať cookies a presmerovanie procesov, ale takmer nikdy nedosadzujte s plnohodnotným javascriptovým motorom (aj keď je stále častejšie a častejšie). Testcokie-Nginx funguje ako rýchly filter medzi robotmi a backend počas L7 DDOS útoku, čo vám umožní odrezať dotazy na odpadky. Čo je súčasťou týchto kontrol? Či je Klient schopný vykonať presmerovanie HTTP, či JavaScript podporuje, či je prehliadač, pre ktorý sa vydáva (pretože JavaScript je iný, a ak klient hovorí, že on, povedzme Firefox, potom môžeme skontrolovať). Kontrola je implementovaná s cookies pomocou rôznych metód:

"Set-cookie" + presmerovanie s 301 http umiestnením;
"SET-COOKIE" + presmerovanie s obnovením HTML Meta;
Ľubovoľná šablóna a môžete použiť JavaScript.

Aby sa zabránilo automatickému analyzácii, testovanie cookies môžu byť šifrované pomocou AES-128 a neskôr sa dešifruje na strane klienta JavaScript. V novej verzii modulu bolo možné nainštalovať kuchári cez blesk, ktorý vám tiež umožňuje efektívne rezané roboty (ktoré blesk zvyčajne nie je podporovaný), ale tiež tiež blokuje prístup pre mnoho legitímnych užívateľov (vlastne všetky mobilné zariadenia ). Je pozoruhodné, že začnite používať testccookie-nginx extrémne jednoduchý. Najmä vývojár vedie niekoľko zrozumiteľných príkladov použitia (pre rôzne prípady útoku) so vzorkami konfigurácií pre NGINX.

Okrem výhod, testccookie má nevýhody:

znižuje všetky roboty, vrátane GoogleBot. Ak plánujete opustiť testccookie na priebežnom základe, uistite sa, že z výsledkov vyhľadávania nezmiznete;
vytvára problémy s užívateľmi s odkazmi na prehliadače, W3M a ich radi;
nespokojuje sa z robotov vybavených plnohodnotným prehliadačom s Javascriptom.

Stručne povedané, testcookie_module nie je univerzálny. Ale z množstva vecí, ako napríklad primitívne nástroje pre Java a C #, pomáha. Takže ste znížili časť hrozby.

4. Kód 444.

Účelom DDOS'ERS sa často stáva najznámejšou časťou siete. Typickým príkladom je vyhľadávanie, ktoré vykonáva komplexné dotazy do databázy. Samozrejme, útočníci môžu využiť to, pričom narazili niekoľko desiatok tisícov požiadaviek na vyhľadávač naraz. Čo môžeme urobiť? Dočasne vypnite vyhľadávanie. Nechajte zákazníci schopní vyhľadávať potrebné informácie zabudovanými prostriedkami, ale celá hlavná stránka zostane v pracovnom stave, kým nenájdete koreň všetkých problémov. NGINX podporuje neštandardný kód 444, ktorý vám umožní jednoducho zatvoriť pripojenie a nie dať nič v reakcii:

Umiestnenie / vyhľadávanie (návrat 444;)

Je teda možné, napríklad rýchlo implementovať filtrovanie na adrese URL. Ak ste presvedčení, že požiadavky na umiestnenie / vyhľadávanie prichádzajú len z robotov (napríklad vaša dôvera je založená na tom, že nie je žiadny oddiel / vyhľadávanie na vašich stránkach), môžete nainštalovať balík iPset a zákaz botov s jednoduchým plášťom Skript:

IPset -n Ban Iphash chvost -f Access.log | Kým READ LINE; Do echo "$ line" | cut -d "" "-F3 | CUT -D -D" "-F2 | Grep -Q 444 && IPset -A zákaz" $ (L %% *) ";

Ak je formát protokolového súboru neštandardný (nie combo), alebo je potrebné zakázať iné príznaky ako stav odpovede, môže byť potrebné nahradiť rezu, aby pravidelne expresné.

5. Banya od geoda

Non-štandardný kód odpovede 444 môže tiež prichádzať pre operačný zákaz klientov na geo-akvizícii. Sotva môžete obmedziť jednotlivé krajiny, ktoré sú nepohodlné. Povedzme, sotva v online obchode kamery z Rostov-on-Don existuje mnoho používateľov v Egypte. To nie je veľmi dobrý spôsob (len povedzte - nechutné), pretože údaje GeOIP sú nepresné, a Rostovs niekedy lietajú do Egypta na odpočinok. Ale ak nemáte čo stratiť, potom postupujte podľa pokynov:

Pripojte sa k modulu NGINX GEOIP (wiki.nginx.org/httpgeoipmodule).
Zobrazte informácie Geotherov v Access log.
Ďalej, modifikovať vyššie uvedený skript Shell, Progrep AccessLog Nginx a pridajte scatelované geografické znaky zákazníkov do zákazu.

Ak sú napríklad roboty z väčšej časti z Číny, môže pomôcť.

6. Neurálna sieť (POC)

Nakoniec môžete opakovať skúsenosť hry @SaveTeterbtz, ktorá vzala neurónové siete Pybrain, plnené prihlásenie do neho a analyzovali požiadavky (Habrahabr.ru/post/136237). Metóda, ktorá nie je univerzálna :). Ale ak naozaj poznáte interiéry vašich stránok - a vy, ako správca systému, by mal - potom máte šancu, že vo väčšine tragických situáciách takýto súbor nástrojov založený na neurónových sieťach, učenie a zhromaždení vopred vám pomôžu . V tomto prípade je mimoriadne užitočné mať prístup.Log pred začiatkom DDOs "A, ako to opisuje takmer 100% legitímnych zákazníkov, a preto je veľký súbor údajov pre odbornú prípravu neurónovej siete. Okrem toho oči v bare nie sú vždy viditeľné.

Diagnostika problému

Stránka nefunguje - prečo? Jeho ddosaim alebo je to Jag chyba, ktorú si všimol programátor? Nevadí. Nehľadajte odpoveď na túto otázku. Ak si myslíte, že vaše stránky môžu zaútočiť, kontaktné spoločnosti, ktoré poskytujú ochranu pred útokmi - niekoľko služieb anti-DDOS na prvý deň po pripojení voľné - a nestrácajú viac času na hľadaní príznakov. Zamerajte sa na problém. Ak stránka pracuje pomaly alebo sa vôbec neotvorí, to znamená, že nemá niečo v poradí s výkonom, a - bez ohľadu na to, či útok DDOS idú alebo nie, - vy, ako profesionál, sú povinní pochopiť, čo spôsobilo to. Opakovane sme boli svedkami toho, ako spoločnosť, ktorá zažíva ťažkosti s prácou vašich stránok, pretože DDOS útoku, namiesto toho, aby hľadelo slabé miesta v mieste motore, snažil sa posielať vyhlásenia ministerstvu vnútorných záležitostí nájsť a potrestať útočníkov. Nedovoľte, aby takéto chyby. Hľadanie cybercriminálov je ťažké a dlhodobý proces komplikovaný štruktúrou a princípmi internetu, a problém s prácou stránky je potrebné rýchlo vyriešiť. Urobte technických špecialistov, aby zistili, aká príčina padnutia na padnutie stránky lži a aplikácia bude schopná písať právnikov.

7. Použite profilovač a debugger

Pre najbežnejšiu tvorbu webovej stránky - PHP + MySQL - Bottlenck je možné podpísať pomocou nasledujúcich nástrojov:

xdebug Profiler ukáže, ktorý volá aplikáciu najviac času;
vstavaný debugger APD a ladiaci výstup v protokole chýb pomôže zistiť, ktorý kód vykonáva tieto výzvy;
vo väčšine prípadov je pes pochovaný v zložitosti a hmotnosti žiadostí do databázy. Tu pomôže vysvetliť SQL databázu vloženú do motora.

Ak je stránka klamaná náhodou a nestratíte nič, vypnite sieť, pozrite sa na protokoly, skúste ich stratiť. Ak nie leží, prejdite cez stránky, pozrite sa na základňu.

Príklad je poskytovaný pre PHP, ale myšlienka je platná pre akúkoľvek platformu. Softvérové \u200b\u200bprodukty pre vývojárov na akomkoľvek programovacom jazyku by mali byť schopné rýchlo aplikovať debugger a profiler. Prax vopred!

8. Analyzujte chyby

Analyzujte objem premávky, čas odozvy servera, počet chýb. Na tento účel nájdete v protokoloch. V NGINX je čas odozvy servera fixovaný v protokole s dvoma premennými: požiadavka_time a upstream_response_time. Prvým je plný úväzok vykonania dotazu, vrátane oneskorenia siete medzi užívateľom a serverom; Druhé správy, koľko backend (Apache, PHP_FPM, UWSGI ...) slúžil ako žiadosť. Upstream_response_time hodnota je mimoriadne dôležitá pre stránky s veľkým počtom dynamického obsahu a aktívnej komunikácie s databázou, nemôžu byť zanedbané. Takáto konfigurácia môžete použiť ako formát denníka:

Log_format xaddr - $ remote_user [$ time_local] "" "$ questing" $ status $ bod_bytes_sent "" $ http_referer "" $ http_user_agent "$ http_ser_ser_agen_response_time" $ \u200b\u200bupstream_response_time ";

Toto je kombinovaný formát s pridanými časovacími poliami.

9. Sledujte počet žiadostí za sekundu

Pozrite sa aj na počet žiadostí za sekundu. V prípade NGINX môžete túto hodnotu nasledujúceho príkazu shellu zhruba odhadnúť (premenná ACCESS_LOG obsahuje cestu k prihlásiu do dotazu NGINX v kombinovanom formáte):

ECHO $ \u200b\u200b(($ (FGGEP -C "$ (env lc_all \u003d c dátum [Chránené e-mail]$ (($ (DATE +% S) -60)) +% D /% B /% Y:% H:% M) "" $ ACCESS_LOG ") / 60))

V porovnaní s normálnym pre tento čas sa počet žiadostí za sekundu môže pád a rast. Rastú v prípade, že prišiel veľký botnet, a jeseň, ak by víťazný botnet zabalila na stránke, čím bola úplne nedostupná pre legitímnych používateľov, a zároveň nepožiada o statiku a žiadajú o legitímne používatelia. Drop v otázkach je pozorovaný len kvôli statike. Ale jedným alebo iným hovoríme o vážnych zmenách indikátorov. Keď sa to stane náhle - kým sa snažíte vyriešiť problém na vlastnú päsť a ak ho nevideme okamžite v protokole, je lepšie rýchlo skontrolovať motor a obrátiť sa na špecialistov paralelne.

10. Nezabudnite na TCPDUMP

Mnoho ľudí zabudne, že Tcpdump je úžasný diagnostický nástroj. Dám pár príkladov. V decembri 2011 bola objavená chyba v Linuxovom jadre, keď otvorila pripojenie TCP, keď sa zobrazili vlajky SYN a RST TCP segmentové segmenty. Prvý BAGEPORT poslal správcu systému z Ruska, ktorej zdroj bol napadnutý touto metódou, - útočníci sa dozvedeli o zraniteľnostiach skôr ako celý svet. Je zrejmé, že takáto diagnóza pomohla. Ďalší príklad: Nginx má jeden, nie je veľmi pekný majetok - zapíše v protokole až po úplnom požiadavke je plne pochopený. Existujú situácie, keď sa stránka leží, nič nefunguje a nie je nič v protokoloch. Všetko, pretože všetky požiadavky, ktoré práve preberajú server, ešte nie sú splnené. Tcpdump tu pomôže.

Je tak dobré, že som odporučil ľuďom, aby som nepoužívali binárne protokoly predtým, ako sa dobylieva, že všetko je v poriadku, - pretože textové protokoly budú dlhovať Tcpdump "OM je ľahké a binárne - nie. Avšak, sniffer je dobrý ako prostriedok Diagnóza - ako prostriedok na udržanie výroby "a je hrozný. To môže ľahko stratiť niekoľko paketov naraz a pokaziť vám históriu používateľa. Je vhodné sledovať jeho záver, a to bude v poriadku pre manuálnu diagnostiku a zákaz, ale snažte sa na ňom založiť nič kritické. Ďalším obľúbeným prostriedkom na "žiadosti o upevnenie" - NGREP - Vo všeobecnosti sa v predvolenom nastavení snaží požiadať v oblasti dvoch gigabajtov nepovažovanej pamäte a potom sa začne znižovať svoje požiadavky.

11. Útok alebo nie?

Ako rozlišovať útok DDOS, napríklad z efekt reklamnej kampane? Táto otázka sa môže zdať zábavná, ale táto téma nie je menej komplikovaná. Existujú dosť zvláštne prípady. V niektorých dobrých chlapci, keď napäté a dôkladne priskrutkované cache, stránka beží na pár dní. Ukázalo sa, že v priebehu niekoľkých mesiacov je táto stránka bez povšimnutia údajmi niektorých Nemcov a pred optimalizáciou cache stránky stránky, títo Nemci boli načítaní všetkými obrázkami na dlhú dobu. Keď sa stránka začala vydávať z Kesha okamžite, topánok, ktorý nemal čas bdelý, začal ich okamžite zbierať. Bolo to ťažké. Prípad je obzvlášť ťažké z dôvodu, že ak sami zmenilo nastavenie (zapnuté do pamäte cache) a stránky po tom, kto prestal pracovať, potom kto je podľa vášho názoru viniť? Presne. Ak sledujete prudký nárast počtu požiadaviek, potom sa pozrite napríklad v službe Google Analytics, ktorý prišiel na ktoré strany.

Tuning webového servera

Aké ďalšie sú kľúčové body? Samozrejme, môžete dať "predvolené" ngginx a dúfam, že budete v poriadku. Vždy sa však nestane dobre. Preto správca akéhokoľvek servera musí venovať veľa času na jemné ladenie a ladenie nginx.

12. Limitné zdroje (veľkosti vyrovnávacej pamäte) v NGINX

Čo potrebujete najprv zapamätať? Každý zdroj má limit. V prvom rade sa týka RAM. Veľkosti hlavičiek a všetkých použitých pufrov je preto potrebné obmedziť na primerané hodnoty na klientovi a serveri úplne. Musia byť predpísané v NGINX CONFIGU.

client_header_buffer_size__ Určuje veľkosť vyrovnávacej pamäte na čítanie hlavičky žiadosti o klienta. Ak v tomto pufri nie je úplne umiestnená dotazová čiara alebo pole dotazov, sa prideľujú väčšie nárazníky špecifikované smernicou o veľkom jazyku.
veľký_client_header_buffers. Nastaví maximálnu veľkosť čísla a vyrovnávacej pamäte na čítanie veľkej hlavičky požiadavky na klienta.
client_body_buffer_size Určuje veľkosť vyrovnávacej pamäte na čítanie karosérie požiadaviek klienta. Ak je telo dotazu väčšie ako požadovaný pufor, potom celé telo dotazu alebo len časť je zapísaná do dočasného súboru.
client_max_body_size Určuje maximálnu povolenú veľkosť tela požiadavky klienta, zadaná v poli "Dĺžka obsahu" hlavičky dotazu. Ak je veľkosť špecifikovaná, potom klient vráti 413 chybu (žiadosť o subjekt príliš veľký).

13. Prispôsobte časové limity v NGINX

Zdroj je čas. Nasledujúcim dôležitým krokom by preto malo byť inštalácia všetkých časových limitov, ktoré opäť je veľmi dôležité, aby sa pohyboval v nastaveniach NGINX.

reset_timedout_connection; Pomáha bojovať s zásuvkami visiacimi v fáze čakania.
client_header_Timeout. Určuje časový limit pri čítaní hlavičky požiadavky klienta.
client_body_Timeout. Určuje časový limit pri čítaní karosérie požiadaviek klienta.
keepalive_timeout. Nastaví časový limit, počas ktorého nebude držané spojenie s klientom zatvorené zo strany servera. Mnohí sa bojí pýtať veľký význam tu, ale nie sme si istí, že tento strach je oprávnený. Voliteľne môžete nastaviť hodnotu časového limitu v hlavičke HTTP-ALIVE HTTP, ale Internet Explorer je známy pre ignorovanie tejto hodnoty.
send_timeout. Určuje časový limit pri prechode na odpoveď na klienta. Ak po tomto čase klient nič neakceptuje, pripojenie bude zatvorené.

Ihneď otázka: Aké parametre vyrovnávacích pamätí a časových čias sú správne? Nie je tu žiadny univerzálny recept, v každej situácii sú ich vlastné. Existuje však osvedčený prístup. Musíte nastaviť minimálne hodnoty, na ktoré si stránka zostane v pracovnom stave (v mieroch), to znamená, že stránky sú uvedené a požiadavky sa spracúvajú. Toto je určené len testovaním - z desktopov a z mobilných zariadení. Algoritmus pre vyhľadávanie hodnôt každého parametra (veľkosť vyrovnávacej pamäte alebo časový limit):

Vykazujem matematicky minimálnu hodnotu parametra.
Spustite testovací beh stránky.
Ak celá funkcia lokality funguje bez problémov - je definovaný parameter. Ak nie, zvýšime hodnotu parametra a prejdite na článok 2.
Ak hodnota parametra presiahne aj predvolenú hodnotu, je dôvodom diskusie v tíme Developer.

V niektorých prípadoch by audit týchto parametrov mal viesť k refaktoritu / redesign používateľa. Napríklad, ak stránka nefunguje bez troch minút ajax dlhých žiadostí o hlasovanie, potom nemusíte zvýšiť časový limit, ale dlhé hlasovanie nahradiť niečo iné - botnety v 20 tisíc automobiloch visí na požiadanie o tri minúty, ľahko Zabite priemerný lacný server.

14. Obmedzte zlúčeniny v NGINX (limit_conn a limit_req)

NIGHINX má tiež schopnosť obmedziť pripojenia, požiadavky a tak ďalej. Ak si nie ste istí, ako sa určitá časť vašej stránky správa, ideálne, musíte ho otestovať, pochopiť, koľko požiadaviek bude vydržať a zaregistrovať ho v konfigurácii NGINX. Je to jedna vec, keď sa stránka leží a môžete prísť a zdvihnúť. A ďalšia vec je - keď pôjde do takej miery, že server šiel swap. V tomto prípade je často ľahšie reštartovať, než čakať na jeho triumfálne návrat.

Predpokladajme, že stránka má sekcie s rozprávanými menami / sťahovaním a / vyhľadávaním. Zároveň sme:

nechceme roboty (alebo ľudí s ohromenými rekurzívnymi manažérmi na stiahnutie), aby nám priniesol tabuľku pripojení TCP s ich sťahovaním;
nechceme roboty (alebo lietajúce žeriavy vo vyhľadávačoch) vyčerpané výpočtové zdroje DBMS viacerými vyhľadávacími dopytami.

Na tieto účely sa použije konfigurácia nasledujúceho typu:

Http (limit_conn_zone $ binary_REMOTE_ADDR ZONE \u003d Download_c: 10m; limit_req_zone $ BINING_REMOTE_ADDR ZONE \u003d SEARCH_R: 10m Hľadanie \u003d 1r / s; server (umiestnenie / download / (limit_conn sťahovanie) search_r burst \u003d 5; iná konfigurácia umiestnenia)))

Zvyčajne má priamy význam na vytvorenie obmedzení limit_conn a obmedzenia_req pre miesta, v ktorých sú drahé skripty (v príklade je určené vyhľadávanie, a to nie je ziskové). Obmedzenia musia byť zvolené, vedené výsledkami zaťaženia a regresného testovania, ako aj zdravým rozumom.

V príklade dávajte pozor na parameter 10m. Znamená to, že výpočet tohto limitu zvýrazní slovník s pufrom 10 megabajtov a megabajtom viac. V tejto konfigurácii vám to umožní sledovať 320 000 TCP relácie. Ak chcete optimalizovať pamäť obsadenú ako kľúč v slovníku, $ binary_Remote_addr premenná, ktorá obsahuje IP adresu používateľa v binárnom formulári a berie menej pamäte ako obvyklá premenná reťazca $ Remote_addr. Treba poznamenať, že druhý parameter smernice LIMNT_REQ_ZONE môže byť nielen IP, ale aj akákoľvek iná premenná nginx, ktorá je k dispozícii v tomto kontexte, je napríklad v prípade, keď nechcete poskytnúť viac šetriaceho režimu proxy, môžete Použite $ BINARY_REMOTE_ADDR $ HTTP_USER_AGENT alebo $ BINING_COOKIE_MOTE_ADDR $ http_cookie_myc00kiez - ale je potrebné použiť takéto návrhy s opatrnosťou, pretože na rozdiel od 32-bitové $ binary_Remote_addr, tieto premenné môžu byť výrazne dlhšie a "10m" deklarované môže byť udržiavané.

Trendy v DDO.

Neustále rastie silu útokov siete a dopravných úrovní. Potenciál priemerného záchvatu syn-povodňového útoku už dosiahol 10 miliónov balíkov za sekundu.
Špeciálny dopyt Nedávno sa teší útoky na DNS. UDP povodne platné DNS požiadavky s spoof'led zdrojovými IP adresy je jednou z najbežnejších implementácií a komplikovaných, pokiaľ ide o boj proti útokom. Mnohé veľké ruské spoločnosti (vrátane hostingu) zažili v nedávnych problémoch v dôsledku útokov na svojich serveroch DNS. Ďalej, tie takéto útoky budú viac, a ich moc pôjde.
Súdiac podľa externých funkcií, väčšina botnetov nie je spravovaná centrálne, ale cez sieť peer-to-peer. To dáva útočníkom možnosť synchronizovať akcie botnetu v čase - ak už skôr manažérske tímy rozšírili na botnet 5 tisíc áut pre desiatky minút, teraz účet sa chystá na sekundy, a vaše stránky môžu neočakávane zažiť okamžité fotografické zvýšenie počtu požiadaviek.
Podiel robotov, vybavený plnohodnotným prehliadačom s Javascriptom, je stále malý, ale neustále rastie. Takýto útok je ťažšie klepal z vstavaných remesiel, takže sebahodnotenie musí nasledovať tento trend so strachom.

príprava OS.

Okrem jemného nastavenia NGINX sa musíte starať o nastavenia stohu siete systému. Aspoň - okamžite zapnite net.ipv4.tcp_syncookies v Systl, aby ste sa chránili pred útokom syn-potravy malej veľkosti.

15. TYI YARD

Dávajte pozor na ďalšie pokročilejšie nastavenia sieťovej časti (jadro) opäť časom a pamäťou. Existuje dôležitejšie a menej dôležité. Po prvé, musíte venovať pozornosť:

net.ipv4.tcp_fin_timeout. Čas, ktorý zásuvka strávi v fáze TCP-2-2 TCP (čaká na segment FIN / ACK).
net.ipv4.tcp _ (, R, W) MEM TCP Zásuvky, ktoré dostávajú veľkosť vyrovnávacej pamäte. Tri hodnoty: Minimálna, predvolená hodnota a maximum.
net.core. (R, W) MEM_MAX Rovnako ako TCP pufre.

S kanálom 100 Mbps sú predvolené hodnoty vhodné; Ale ak máte aspoň gigabit v candide, potom je lepšie použiť niečo ako:

Systl -w -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 -W NET.IPV4.TCP_WMEM \u003d "4096 65536 8388608" Systl - w nt.ipv4.tcp_fin_timeout \u003d 10

16. Revízia / Proc / SYS / NET / **

Ideálne naučiť sa všetky parametre / proc / sys / net / **. Je potrebné vidieť, ako sa líšia od predvoleného nastavenia a pochopia, ako primerane vystavené. Developer Linux (alebo správca systému), ktorý demontuje internetový servis, ktorý je predmetom, a chce ho optimalizovať, by si mali prečítať dokumentáciu všetkých parametrov zásobníka jadrovej energie so záujmom. Možno, že nájde premenné špecifické pre jeho stránku, čo pomôže nielen chrániť miesto pred votrelcami, ale tiež urýchliť svoju prácu.

Neboj sa!

Úspešné DDOS-útoky Deň Po dni, E-Commerce uhasí médiá, médiá, ktoré sú poslané najväčšie platobné systémy. Milióny užívateľov internetu strácajú prístup k kritickým informáciám. Hrozba je naliehavá, takže sa ho musíte stretnúť v plnení. Vykonajte svoje domáce úlohy, nebojte sa a udržujte svoju hlavu. Nie ste prvý a nie posledný, kto sa stretne s útokom DDOS na ich webovej stránke, a vo vašej silu, vedenej ich vedomostiam a zdravým rozumom, znížiť následky útoku na minimum.

Pred niekoľkými časom som napísal podrobný článok o inštalácii a konfigurácii webového servera na základe najnovších verzií. Uviedol som, že toto je prvý článok z cyklu zóny webového servera. Dnes vám poviem ako jednoduché a pichľavé prostriedky na ochranu pred jednoduchým dDOS. útokov.

Ihneď urobím rezerváciu o Slovo DDO, ktorá tu nie je vhodný, ale neprišiel som s tým, o čom viac populárne vysvetľujeme, o čom hovoríme. Z celého útoku DDOS nebudete môcť chrániť ako súčasť nastavenia webového servera. Stačí byť upchatý celým kanálom a server prestane reagovať. Ak napájanie servera nestačí na spracovanie a filtrovanie prichádzajúcich požiadaviek, spadne tam. Pre plnohodnotnú ochranu proti DDOS budete potrebovať plnohodnotné finančné prostriedky, ktoré sú hmatateľné finančné náklady. Viac informácií s teóriou podľa samostatného článku.

Malo by sa zrejmé, že ochrana proti DDO by mala byť primeraná významnosti zdroja. Ak máte osobný blog, ktorý neprináša značné zisky, potom zaplatíte za ochranu pred DDOS bezvýznamnými. Stačí len na chvíľu si ľahnúť alebo urobiť ochranu na vlastnú päsť. Vo všeobecnosti je vždy potrebné merať náklady na prestoje s nákladmi na ochranu a na základe toho rozhodovať o uskutočniteľnosti jednej alebo inej metódy.

Dám vám radu chrániť pred jednoduchými útokmi robotov alebo niektorých malých škodcov a balíčkov, ktoré bez riadnych akcií na vašej strane môžete dať svoje webové stránky alebo server bez akýchkoľvek problémov. Tu je jednoduchý príklad. Na palube nie je veľmi slabá, na palube, ktorá 2 yardov, 8 Gigs prevádzkovateľov a SSD disk.

Server je nakonfigurovaný podľa môjho predchádzajúceho článku, odkaz, na ktorý viedol na začiatku. Na serveri bude nasadená stránka WordPress s určitým obsahom. A máme škodcov, ktorý na vašom serveri spustí jednoduchý test z Apache na výkon webového servera:

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

Iba 50 paralelných prúdov. Čo vidíme na vašom webovom serveri:

Nie je to veľmi príjemný obraz. Server je načítaný 100%. A hoci normálne spracováva požiadavky a vo všeobecnosti funguje správne. Ani spomalí, ale stále je to zlé. A ak existujú 3 servery a 100 prúdov? Neexistujú žiadne problémy ani pre test odnímajú od rôznych hostiteľov na virtuálnom stroji a spúšťať také veci na nich imitáciou útoku DDOS.

Všeobecne platí, že ak ste vôbec neurobili žiadnu ochranu na vašom serveri, potom niekto bude môcť doručiť nejaké nepríjemnosti bez špeciálnych problémov. Z takéhoto "útoku" nie je ťažké. Potom vám poviem, ako to urobiť.

DDOS Ochrana pomocou iptables

Na ochranu pred najjednoduchším útokom budeme používať firewall - iptables., Modul jadra ip. Uloženie veľkého zoznamu IP a samoobslužných skriptov. Pre bránu firewall nájdete v mojom článku -. Tu sa nezastavím.

IPSET Nastavenie otázky som uvažoval podrobne v mojom článku. Odporúčam vám, aby ste videli materiál, pretože priamo súvisí s týmto článkom a dopĺňa ho.

Takže, budeme pokračovať, aby sme vytvorili našu jednoduchú ochranu proti útokom DOS s veľkým počtom pripojení z jednej adresy IP. Ak chcete začať, skontrolujte príkaz, ktorý nám zobrazí počet pripojení z každej IP adresy:

Tu je porušovateľom nášho pokoja, snaží sa organizovať šéf na našom serveri. Teraz nakreslite skript, ktorý zablokuje všetkých, ktorý nastavuje viac ako 50 simultánnych pripojení s miestom.

V zásade tu nie je nič komentovať. Urobíme zoznam pripojení, ktoré sa práve ukázali, porovnávame prvý stĺpec v ňom, ak je väčší ako 50, potom výsledok druhého stĺpca, kde je adresa IP zaznamenaná, prejde do súboru.

Ďalej prečítajte si tento súbor a pridajte všetky IP adresy z neho do zoznamu IPset s názvom MUCH_CONN. Predtým ho potrebujete vytvoriť. Hovoril som o tom podrobne v článku, na ktorom Link LED vyššie, ale opäť opakujem tu:

# ipset -n youth_conn iphash

Zobraziť obsah zoznamu môže byť príkaz:

# ipset -l youth_conn

Teraz musíte pridať pravidlo na iptables, ktorými budú zablokované všetky pripojenia zo zadaného zoznamu ipset.

# iptables -a Input -m set -Match-set MUCH_CONN SRC -J

Len v prípade, že vás upozorním, aby ste skontrolovali váš prístup k konzole servera pred konfiguráciou pravidiel iptables. Všetko sa stane, môžete sa jednoducho mýliť, skopírovať a prilepiť, čo potrebujete.

Všetko, zablokovali sme každého, kto vytvorí masové spamové pripojenia na server. Limit v 50 spojeniach je možné opraviť na mieste, môže byť potrebné znížiť, ak niekto otvorí menej pripojení z jednej IP.

Jediný moment, ktorý chcem povedať. Ja sám som nekontroloval, koľko pripojení otvárajú vyhľadávacie roboty, keď prídu na stránku. Mám podozrenie, že to nie je jasne 50 a ani 30, ale pravdepodobne som nekontroloval. Všeobecne platí, že budete opatrní, keď používate tento nástroj.

Tento skript môže byť strčený do koruny a behať každú minútu. Ale osobne by som to neurobil. Odporúčam monitorovať zdroje servera a spustiť podobné nástroje len vtedy, ak server pracuje na hranici svojich schopností a vy ste manuálne zadali a uistite sa, že niekto bude spal s pripojením. Potom išiel nejaký čas tento korunný skript. Keď sa DDO zastaví, odpojte.

Bolo by pekné nejako automaticky čistiť zoznam zakázaných, odstraňovaní z nich, ktorí nie sú k tebe spojení na jeden deň, ale to značne komplikuje úlohu. Potrebujete aspoň protokol o zozname blokovania, uložte posledný čas príťažlivosti. Spracovanie všetkého, výpočet. Všeobecne platí, že úloha je však veľmi ťažké, ale nie triviálne. Nechcel som to urobiť.

Tam je, aj keď nie je veľmi elegantný, ale jednoduché riešenie tohto problému. Vytvorte zoznam ipset so zadaným zaznamenaním životnosti Čas vypršal.. Napríklad, takto:

IPset -n MUnty_conn Iphash Timeout 3600

V tomto prípade sa IP uložená IP záznam v zozname IPset uloží na 3600 sekúnd alebo 60 minút.

Malo by sa zrejmé, že v tomto príklade s 1 IP adresou na použitie IPset neexistuje žiadny bod, môžete okamžite zakázať prostriedky samotného IPTAbles. IPset je potrebný len vtedy, keď je tento zoznam aspoň stovky riadkov. Ak existuje niekoľko desiatok adries, dostatok jednej iptables.

Analýza protokolového servera webového servera na ochranu pred DDO

Zvážte ďalší jednoduchý, ale stále zložitejší typ útoku DDOP, keď typové dotazy pochádzajú z rôznych IP. To znamená, že jednoduchý botnet, možno dokonca zostavený s rukami z niekoľkých lacných VDS serverov. Simultánne spojenia nebudú veľa, ale ak máte ťažké miesto a útočník nájde svoje slabé miesto (napríklad vyhľadávanie), môže to stačiť na to, aby miesto.

Budeme zakázané prostredníctvom iptables a zoznam adries pre zákaz sa extrahuje z protokolov webových serverov. Aby ste to urobili, musíte byť zapnutá protokolovať požiadavky na webový server. Napríklad v NGINX je to zodpovedné za toto nastavenie virtuálneho hostiteľa:

Access_log /web/Sites/hl.zerOxzed.ru/log/access.log Main;

Celý denník nebudeme analyzovať zakaždým. Táto operácia bude ohrieva webový server. Urobte posledných 1000 riadkov z protokolového denníka a zvážte počet pripojení z jednej IP s obsahom typu, ako je napríklad hlavná požiadavka stránky HTTP 1.0, "Get / HTTP / 1.0". Ak si všimnete ďalší trvalý rys botnetu, ktorý vás zaútočíte, použite ho. Môže to byť ten istý užívateľský agent alebo niečo iné. Predpokladajme, že ak útočník klesne na zraniteľné miesto, bude adresa tejto stránky.

# Chvost -1000 /web/sites/hl.zeroxzed.ru/log/ssla-access.log | EGREP "GET / HTTP / 1.0" | AWK "(print $ 1)" | Triediť -N | UNIQ-C.

Výsledok tohto príkazu bude približne takýto zoznam.

V tomto prípade som použil trochu iný stav a jednoducho priniesol zoznam všetkých tých, ktorí poujali na hlavnú stránku. Ale tu môžete vidieť porušovateľa, ktorý môžete zákaz.

Kreslíme podobné k predchádzajúcemu skriptu pre automatické uzamknutie tých, ktorí posielajú príliš veľa požiadaviek na naše stránky a vytvára problémy s výkonom. Opäť opakujem, ak nie sú žiadne problémy s produktivitou, neodporúčam robiť ďalšie pohyby.

#! / Bin / sh chvost -1000 /web/Sites/hl.zerOxzed.ru/log/ssla-access.log | EGREP "GET / HTTP / 1.0" | AWK "(print $ 1)" | Triediť -N | UNIQ-C | Triediť -N | Chvost -N100 | AWK "(ak ($ \u200b\u200b1\u003e 50) Vytlačiť $ 2)" /Root/ddos/much_gets.txt/DDDOS/much_gets.txts SLEEP 3 LIST \u003d $ (CAT /ROOT/DDDOS/MUCH_GETS.TXT) pre IPNet v $ Zoznam Do IPset -A MUCH_GETY $ ipnet hotový

Tu robíme to isté ako predtým. Tí, ktorí urobili viac ako 50 rovnakých požiadaviek na našej maske pre posledných 1000 riadkov v protokolovom súbore, sú zaslané zákazu.

Upozorňujem na reťazec, na ktorom budete filtrovať požiadavky. V tomto prípade som ukázal len príklad. Neužívajte a aplikujte vo forme, ako sa ukážem. Preukazujem technické schopnosti a prístup. Musíte nakonfigurovať a kalibrovať systém na mojom mieste. Je dôležité pochopiť to a bezohľadné rozhodnutie. Bude len škoda.

Nezabudnite vytvoriť samostatný zoznam v iPset a pridajte samostatné pravidlo na iPAbles. Už existujúci zoznam a pridané pravidlo môžete použiť z predchádzajúceho príkladu, ale odporúčam vyriešiť všetko. Tak pohodlnejšie pre následnú analýzu.

Počas útoku DDOS pridajte toto pravidlo na cron a vykonajte každú minútu. Po dokončení útoku môže byť skript vypnutý. V zásade môžete neustále odísť, ale tu musíte starostlivo premýšľať a odhadnúť, ako by sa to malo pozrieť. Hlavná zásada nie je škodlivá.

BAYA BOTY S Nesprávnym odkazom

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

Správne pole referencie musí obsahovať buď http alebo https, alebo byť prázdne. V opačnom prípade môžete bezpečne blokovať alebo vrátiť chybový stav. Pridajte približne tento návrh do konfigurácie virtuálnej hostiteľa v sekcii server ().

Ak ($ http_referer! ~ * ^ ($ | Http: // | https: //)) (návrat 403;)

Potom skontrolujte konfiguráciu nginx a znova ju znova načítajte.

# Nginxt -t # nginx -s znovu načítať

Ak si vyberiete nejaký druh topánok s konkrétnym odkazom, môžete ho zakázať. Ak to chcete urobiť, môžete pridať stav alebo zmeniť. Napríklad, takto:

Ak ($ http_referer \u003d "https://bots.ru/dostanim_tebya.html") (návrat 403;)

Okrem toho, môžete všetky tieto roboty pomocou jednoduchého skriptu zakázať IPTAbles, ako v príkladoch vyššie. Mimochodom, môžu byť okamžite zakázané, prezeranie požiadaviek HTTP ešte predtým, ako spadnú do Nginx, napríklad pomocou NGREP, ale je to ťažšia úloha. Nie všetci vedieť, ako to urobiť, tam sú nuansy a všetko je oboznámené s nginxom. Nebude to veľmi ťažkosti s implementáciou tejto metódy.

Ochrana DDO s modulmi Nginx - Limit_conn a Limit_req

Budem zdieľať ďalší jednoduchý spôsob, ako znížiť zaťaženie na serveri a čiastočne chrániť pred DDO pomocou modulov NGINX - limit_conn. a limit_req. Nie je ťažké ich konfigurovať, čiastočne výsledok prvého modulu sa pretína s prvými dvoma metódami ochrany DDO opísaných na začiatku. Je jednoduchšie prispôsobiť, takže ak sa nezaujímate s týmito metódami, môžete si to vyskúšať.

Význam týchto modulov je, že človek môže obmedziť simultánne množstvo povolených spojení s miestom a iným počtom pripojení na jednotku času.

Budem obmedziť v mojom príklade počet simultánnych pripojení na miesto z jedného IP číslo 50 a počet simultánnych požiadaviek na dynamický obsah nie viac ako 2 za sekundu. Toto bude vyriešené splash ( výbuch.) Dotazy do 5 rokov. Vysvetlím, ako pochopiť tento splash, pretože som okamžite pochopil, čo presne to znamená.

Ak by sme prekročili počet požiadaviek na stanovené za sekundu, ich vykonanie je oneskorené, a sú zabudované do frontu zadanou rýchlosťou. Veľkosť tohto frontu sa rovná hodnote výbuchu. Všetky požiadavky, ktoré nie sú dostatočné miesto vo fronte, budú dokončené s chybou. To znamená, že ak sú požiadavky 4 za sekundu, potom bude vykonaná 2 a ďalšia 2 bude vo fronte. A ak je 10, potom sa okamžite vykoná 2, 5 bude v fronte na vykonanie 2 kusov za sekundu, a zvyšok bude dokončená chyba.

Na základe týchto podmienok musí byť obmedzenie pripojenia inštalované v kontexte servera prístup k dynamickým obsahom v príslušnom miesto. V rovnakej dobe, opis zón, ktoré sa používajú smernice, by mali byť umiestnené http..

Tu je príklad NGINX CONFIGN na implementáciu zavedených obmedzení, aby sa ochránili proti útokom DDOS.

Http (... limit_conn_zone $ binary_Remote_addr ZONE \u003d PERIP: 10M; limit_req_zone $ BININY_REMEMOTE_ADDR ZONE \u003d DYNAMICKÉ: 10M Rate \u003d 2r / s; ... Server (... Limit_conn perip 50; ... Limit_req Zóna \u003d Dynamic Burst \u003d 5 Nodeley; ...))

Po tomto reštarte nginx a skontrolujte, ako fungujú limity. Limit na počet vykonaných dynamických požiadaviek možno vidieť jednoduchým stlačením veľmi rýchlo F5 v prehliadači. Ak ste dosť Deft, potom čoskoro uvidíte obrázok

a vstup do denníka s chybami:

2017/11/30 15:25:26 9773 # 9773: * 51482 Limitné požiadavky, Prebytok: 5.664 podľa zóny "Dynamic", Klient: 195.91.248.43, Server: HL.ZEROXZED.RU, požiadavka: "GET / HTTP / 2.0 ", Hostiteľ:" HL.ZEROXZED.RU ", referer:" https://hl.zeroxzed.ru/2013/03/15/Featured-Image-vertical/ "

Obmedzenie počtu pripojení môže skontrolovať rovnaký nástroj absPovedal som o úvode.

017/11/30 15:38:56 9773 # 9773: * 53938 Obmedzenie pripojení podľa zóny "Perip", Klient: 94.142.141.246, Server: HL.ZEROXZED.RU, požiadavka: "Get / WP-Content / Uploads / 2013 /03/---Dark-knight-rises.jpg http / 1,0, hostiteľ: "HL.ZEROXZED.RU"

Nezabudnite, že test musí byť spustený na konkrétnu stránku, potom budete mať na obmedzenie výkonu dynamického obsahu, ale pre niečo iné. Napríklad, ako v mojom príklade, na obrázku.

Pri vydávaní obmedzení nezabudnite ovládať, či vyhľadávacie roboty nespadajú do týchto obmedzení. Štandardne sa snažia vytvoriť zvýšenú záťaž na stránke. Ak je to žiaduce, Robot Yandex môže byť zadaný prostredníctvom Robots.txt, ako rýchlo skenovať vaše stránky. A Robot Google dokáže urobiť to isté prostredníctvom webmasterov.

Záver

Preskúmal som najjednoduchšie spôsoby, ako chrániť webový server z ničoho menej jednoduchých útokov DDOS, ktoré sú viac ako hybivo. Vážny útok, ktorý jednoducho vyplní celý kanál prichádzajúceho kanála, si ani nevšimne našu ochranu. Musel som však uistiť, že účinnosť týchto metód v odraze niektorých útokov.

Stále existuje obrovské množstvo webových serverov, ktoré nie sú ani chránené ani z užitočnosti. abs :) Viem, o čom hovorím, pretože takéto servery nachádzajú do práce. A je tu tiež veľa všetkých druhov robotov a jednoduchých programov, ktoré možno nájsť na internete a srsti, tučné lokality, ktoré nie sú pripravené na zaťaženie vôbec.

Existuje iný spôsob, rovnaký jednoduchý, ako som opísal a účinné z robotov, ktoré nerozumejú presmerovaním a cookies. Nepočul som to, pretože nič na kontrolu, a to bolo len unavené, aby napísal článok, ukázalo sa, že veľmi veľké. Napísal som a upravil ho na dlhú dobu, zbieranie skriptov a nastavení na rôznych serveroch a pamätajte si, že som raz urobil. Potom to všetko skontrolovalo samostatne.

Podstatou ochrany je, že s pomocou NGINX vydáme pre používateľa konkrétne cookies a potom presmerovať požadovanú stránku. Ak topánok nerozumie cookies alebo presmerovaniu, potom spadne. Normálny užívatelia si nič nevšimnú. Možno neskôr vám poviem o tejto metóde a pridajte článok. Medzitým. Budem rád pripomienkou k zásluhom v článkoch.

Online Linux kurz

Ak máte túžbu dozvedieť sa, ako budovať a udržiavať vysoko prístupné a spoľahlivé systémy, odporúčam sa zoznámiť online kurz "Administrator Linux" v OTU. Kurz nie je pre začiatočníkov, pre prijatie potrebujete základné vedomosti o sieťach a inštaláciu Linuxu na virtuálne. Tréning trvá 5 mesiacov, po ktorých úspešní absolventi kurzu budú môcť prejsť pohovorom od partnerov. Čo vám tento kurz dá:

Znalosť architektúry Linuxu.
Zvládnutie moderných metód a analýzy dát a nástroje na spracovanie údajov.
Schopnosť vybrať konfiguráciu potrebných úloh, spravovať procesy a zabezpečiť bezpečnosť systému.
Hlavné pracovné nástroje správcu systému.
Pochopenie funkcií nasadenia, nastavení a údržby sietí postavených na základe Linuxu.
Schopnosť rýchlo vyriešiť vznikajúce problémy a zabezpečiť stabilnú a neprerušovanú prevádzku systému.

Skontrolujte si na úvodnej skúške a pozrite si viac softvérového programu.

Webové projekty sa veľmi často stretávajú s útokmi DDOS. Dnes považujeme jeden zo základných spôsobov, ako chrániť pred http-povodňou.

Úvod:

Nedávno, útok sa stal jedným z mojich priateľských projektov, s najväčšou pravdepodobnosťou napadol neskúsený hacker, pretože útok bol vykonaný z jednej IP adresy.

Počas analýzy protokolov sa zistilo, že útočník sa snaží nahrať mnohokrát hlavná stránka a server sa snaží spracovať tieto požiadavky a nemôže.

Na ochranu proti útokom tohto druhu budeme používať proxy server nginx a štandardný modul NGX_HTTP_LIMIT_CONN_MODULE

Modul NGX_HTTP_LIMIMIT_CONN_MODULE Umožňuje obmedziť počet pripojení na daný kľúč, najmä počet pripojení z jednej adresy IP.

Do úvahy nie všetky spojenia, ale iba tie, v ktorých server sú spracované požiadavky, a hlavička požiadaviek sa už číta.

Inými slovami, môžeme obmedziť počet požiadaviek a pripojení z jednej adresy IP. To stačí na ochranu pred slabými a strednými http-povodňovými útokmi.

Ak chcete nastaviť obmedzenie, použijeme limit_conn smernice

Nastavenie NGINX na ochranu pred DDOS:

limit_conn:

limit_conn Určuje maximálny prípustný počet pripojení z jednej IP. Ak je toto číslo prekročené, v reakcii na žiadosť, server vráti chybu 503 (Služba dočasne nedostupná).

Po prijatí chyby 503, útočník prestane vytvoriť užitočné zaťaženie na databázovom serveri, ako napríklad MySQL, čím sa vykladajte.

Ale pred použitím limit_conn na ochranu pred útokmi DDOS s NGINX, musíme zistiť a nainštalovať limit_conn_zone smernice

limit_conn_zone:

Syntax: limit_conn_zone Kľúč zóny \u003d. názov: Veľkosť;
Nastavuje parametre zdieľanej pamäťovej zóny, ktorá ukladá stav pre rôzne hodnoty kľúčov. Najmä štát obsahuje aktuálny počet pripojení. Ako kľúč môžete použiť text, premenné a ich kombinácie. Žiadosti s prázdnou kľúčovou hodnotou sa neberú do úvahy.
Príklad použitia:

Príklad použitia

limit_conn_zone $ binary_Remote_addrón \u003d addr: 10m;

Táto smernica je potrebná na uloženie stavu pre každú adresu IP. To je dôležité! Táto smernica by mala ísť do ngginx.conf ihneď po http (.

Nginx.conf konfiguračný príklad pre limit_conn_zone:

Príklad konfigurácie

http (limit_conn_zone $ binary_Remote_addrón \u003d addr: 10m;

http (

limit_conn _ zóna $ binary_Remote_addr ZONE \u003d EDR: 10m;

. . .

Po inštalácii smernice Limit_conn_Zone sa obrátime na inštaláciu LIMNTH_CONN.

Syntax: limit_conn.číslo zóny;

Upozorňujeme, že zóna musí byť prevzatá z zóny nainštalovanej v Limit_conn_Zone, v našom prípade addr.

3. parameter "číslo" označuje číslo súčasne otvorené pripojenia z jednej adresy IP.

Aby ste mohli obmedziť 3 simultánne pripojenia pre EDR ZONE, musíte napísať nasledovné:

limit_conn.addr 3;

Príklad konfigurácie ochrany proti útokom DDOS pomocou nginx a limit_conn:

http (limit_conn_zone $ binary_Remote_addrón \u003d addr: 10m; ... server (počúvať 80, ... LOKUMENT / (LIMIT_CONN ADDR 3; ...))

http (

limit_conn _ zóna $ binary_Remote_addr ZONE \u003d EDR: 10m;

V skutočnosti, prečo zakázať prístup k geografickej báze? Áno, len 80% IP adries, ktoré sa zúčastňujú na útok DDOS, spravidla patrí do krajín, ktorých obyvatelia nikdy nevstúpia na túto stránku, prirodzene je to čisto individuálne pre každý zdroj a ak viete, že časť vašich návštevníkov pochádza z Etiópie alebo Čile , Blokujte ich, sotva chcete. Pre väčšinu svojich klientov je geografická poloha návštevníkov zvyčajne obmedzená na Európu a bývalého ZSSR, zvyšok je možné bezpečne ignorovať.

Opísaný spôsob blokovania prepúšťacích krajín pomocou webového servera ngginx a geoip. Modul, sám, a ešte viac, problém nebude problém vyriešiť problém, je to len jeden, z množstva všetkých druhov opatrení (nastavenie jadra, firewallu, služby na plný úväzok, ďalší softvér), na minimalizáciu UPOZORNENIE APLIKA TÝKAJÚCE TÝKAJÚCE SA TÝMTO TYPOM TYPOM ATTACKOM SERVER A STRÁNKU.

Projekty, ktoré často potrebujú tento druh ochrany, snažím sa najprv zvýšiť bez účasti webového servera Apache, to znamená na zväzku nginx - fastcgi..

Tak, dajte a nakonfigurujte celú túto domácnosť na serveri, ktorý prevádzkuje operačný systém FreeBSD 8.2 a64..

To by modul geoip. Vyžaduje sa dodatočná knižnica, nastavujeme:

FreeBSD82 / USR / Porty # Make-C NET / GEOIP Install Clean

FreeBSD82 / USR / Porty # Make-C www / nginx inštalácia

v možnostiach montáže musíte povoliť geoip. modul ngginx, uvedenie nádrže oproti položky Povoliť modul http_geoip.

Ďalej ideme na stránku http://www.maxminmind.com/app/geoliteCountry a na stiahnutie najnovší binárny formát Geolite CountryIde o voľnú možnosť základne krajín a ich zodpovedajúce bloky IP adries. Rozbaľte archív a hádajte súbor Geip.dat. v priečinku USR / LOCAL / ETC / NIGHTX / CONF / GEO. Zostáva upraviť konfiguráciu ngginx.

Otvorené nginx.conf., Pridajte do časti http. Nasledujúca bloková smernica:

Geoip_country /usr/local/etc/nginx/conf/geo/geoip.dat; # Connect Geip Base Mapa $ geoip_country_code $ bad_country ( # Map Modul vytvára premenné, ktorých hodnoty závisia od iných premenných, veľmi užitočnou vecou Predvolené hodnoty 1; V predvolenom nastavení zahŕňajú geo / good_countries; # Zahrňte súbor, neskôr }

Tento blok mapovať, znamená, že všetky krajiny sú v databáze, sú predvolené zakázané av súbore good_countries.Uvádzajú sa povolené krajiny. Ak máte napríklad situáciu, keď sú povolené krajiny viac, než je zakázané, môžete túto logiku ľahko invertovať a vytvoriť súbor bad_countries. So zoznamom zakázaných krajín, čo umožňuje všetkým ostatným.

Teraz nastavenia hostiteľa. Dávam prednosť napríklad hostiteľovi v samostatnom priečinku, napríklad hostiteľov., Každý vo vašom súbore.

Server (Počúvajte IP: 80; Server_name Testhost.com; ak ($ \u200b\u200bbad_country) ( # Ak je táto premenná nainštalovaná, to znamená, že ak krajina nie je uvedená v súbore Good_countries Návrat 444; # Vydávanie klienta prázdna odpoveď (nie je potrebné poskytnúť 403 chyby alebo iné) } ................. ................. }

Teraz späť do súboru good_countries.. Všetko je mimoriadne jednoduché, krajiny, ktoré majú prístup k stránke, sú uvedené v nasledujúcom formáte:

Tm 0; Ua 0; Uz 0; Ru 0; ....... ....... atď.

To by bolo dosť pre každú krajinu, stačí pridať svoj dvojpísmenový kód a 0, potom, čo chcete reštartovať nginx config:

FreeBSD82 / # nginx -s znovu načítať

Kódy krajín, dvakrát, sú prostredníctvom Google.

Kontrola, beh geoip. Modul alebo nie, je možné, odstrániť zo zoznamu povolených krajín a snaží sa vstúpiť na stránku.

Vlastne taká je všeobecná schéma používania modulu GeOIP NGINX na ochranu proti útokom DDOS.

Samozrejme, môžete prísť s množstvom ďalších možností na používanie tohto modulu na riešenie rôznych úloh spojených so zemepisnou polohou návštevníka stránok.

Môžete sadnúť takto, nedotýka sa nikoho, a potom zavoláte a hovoríte, že služby pracujú pomaly, stránky otvorené 2-3 minúty podarilo produkovať 504 chýb.
Naštvaný stúpanie v kaktusoch a existuje:

Nižšie sú príkazy, ktoré vám pomôžu pochopiť, čo sa stalo, a je to presne DDO.

Po prvé, odporúčam čítať článok v ňom podrobne popísaný, ktorý protokoly sú pre nás zaujímavé, ako si prečítať vrchný príkazový výstup a ako používať tím PS. Všetci budú pre nás užitočné, aby sme pochopili, aké hostitelia sme podstúpili útok a aké úzke miesta sú na serveri.

Aké tímy a čo môžeme určiť?

Ak chcete spustiť, môžete zobraziť počet spracovaných procesov Apache. Ak je viac ako 20-30 viac ako 20-30, potom niečo nie je.

Pozeráme sa na počet procesov Apache v Debian:

Ps aux Grep Apache | Wc -l.

Pozeráme sa na počet procesov Apache v Centose:

Ps aux Grep httpd | Wc -l.

Tento príkaz môže uvidíme počet pripojení na server:

CAT / PROCT / NET / IP_CONNTRACK | Wc -l.

Tiež indikátor, ktorý server prichádza na server, môže slúžiť ako počet pripojení na porte 80 alebo 443. Tu sú tímy schopní zobraziť toto číslo:

Netstat -na | GREP: 80 | Wc -l netstat -na | GREP: 443 | Wc -l.

Stále je tu taká škála DDOD as syn. Nižšie je príkaz, ktorý vám umožňuje určiť počet požiadaviek na rovnaký 80 a 443 portov:

A tento príkaz zobrazuje počet žiadostí o inštaláciu:

Netstat -n -t | Grep SYN_RECV | Wc -l.

Nasledujúci príkaz nám umožní pochopiť, akú doménu je väčšina všetkých požiadaviek:

TCPDUMP -NPI Eth0 Port Domain

Pozrime sa teraz, koľko požiadaviek pochádza z každej IP. Tento príkaz zobrazuje všetky porty:

podobné príkazy:

Tento príkaz zobrazuje počet požiadaviek len na 80 portov:

Tento príkaz zobrazuje všetky požiadavky na 80 portov, nepočítajte ich, t.j. "Zjednodušená", ale "Väčšina kompletná" výstupná možnosť:

Výpočet najaktívnejších IP sa môže tiež pozrieť na to, aké porty idú z požiadaviek IT. Tu je napríklad substituovaný IP 127.0.0.1:

Netstat -na | Grep 127.0.0.1

Mimochodom, ak nie ste nakonfigurovaný štatútom servera na Apache, stav tohto servera je možné zobraziť v CLI:

Status Apachectl.

Protokolové súbory

Globálne protokoly Apache, Debian, sú zvyčajne:

/var/log/apache2/error.log.
/var/log/apache2/ACESS.LOG.

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

Globálne nožené protokoly sú:

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

Aj nezabudnite zobraziť protokoly virtuálnych hostiteľov, ak sú hostitelia nakonfigurované. Budeme mať záujem o najväčší log, ktorý "rastie" pred.

Je potrebné vyhľadávať v týchto protokoloch anomáliou, a to rovnaký typ požiadaviek bez užívateľských agentov (alebo s rovnakým), veľký počet požiadaviek z toho istého IP, požiadavky bez špecifikovania virtuálneho hostiteľa atď.

Ak chcete identifikovať konkrétnu IP s počtom požiadaviek na stránku, môžete tento príkaz:

CAT ACCESS.LOG | AWK "(print $ 1)" | Zoradiť | UNIQ-C.

Môžete tiež získať štatistiky o požiadavkách s IP zoskupením pomocou pomôcky Logtop.

Ak chcete začať, nainštalujte túto pomôcku:

Apt-get nainštalovať git libncurses5-dev uthash-dev gcc # v prípade, že nemáte balíky pre správnu operáciu git git klon https://github.com/julienpalard/logtop.git

A teraz dostaneme štatistiky:

Access.log | AWK ("Tlač $ 1; fffush ();") Logt.

Nasledujúci príkaz nám pomôže identifikovať populárne užívateľské agenti:

CAT ACCESS.LOG | AWK -f "" (print $ 6) "| triediť | uniq -c | triediť -n

Ako blokovať?

Mimochodom, musíte stlačiť iptables. S najväčšou pravdepodobnosťou to nemusí byť nakonfigurované, najmä ak neviete, čo to je. Skôr som už napísal článok o tom, ako ho používať: "", takže budem dať len potrebné príkazy na vyriešenie problému tu a teraz.

Takto je to možné blokovať požiadavky TCP pre 80 portov zo špecifickej IP:

IpTables -a vstup -p tcp --dport 80 -s 12.34.56.78 -J

Tak sme my blokovanie dotazov pre všetky porty zo špecifickej IP:

Iptables -a vstup -s 12.34.56.78 -J

Zobraziť zoznam už zablokovaný Týmto tímom môžeme poskytnúť:

Iptables -l -n.

Iptables -l -n -Lline-čísla

Ak potrebujeme odstráňte z blokovania špecifickej IP, môžete použiť tento príkaz

Iptables -d vstup -s 1.2.3.4 -J

alebo je to možné odstráňte pravidlo podľa jej číslaPo skontrolovaní iptables -l -n -n -n -Line-Number Command:

Iptables -d vstup 6

Odstránenie všetkých pravidiel, Môžete použiť tím:

Iptables -f.

Niektoré prevencie, aby sa chránili pred DDOS ...

Existuje niekoľko ďalších pravidiel, ktoré nás budú môcť chrániť pred nýrými robotmi, ktoré vytvárajú zaťaženie servera.

Nainštalujeme nasledujúci príkaz maximálny počet pripojení z jednej IP na 80 porte:

IPTAbles -a Input -p TCP --DPort 80 -M Connlimit --connLimimit-nad 128 -J Drop iptables -A vstup -p TCP --Dport 80 -J

Rovnaký Môžete urobiť I. pre DNS.:

IPTAbles -a vstup -p UDP --DPort 53 -m Connlimit --connPonlimit-Nad 16 -J Drop Iptables -a Input -p UDP --DPort 53 -J prijatie

Nasledujúce pravidlo v Iptables zabráni špičke z nášho mena. Spravidla, počas DDO, dostaneme balík s nainštalovanými zvukovými a ACK vlajkami v otvorenom pripojení (táto kombinácia vlajok má len odpoveď na balík SYN). To naznačuje, že niekto poslal inú syn hostiteľa hostiteľa z nášho mena a odpoveď prišla k nám.
Podľa tohto pravidla bude náš hostiteľ odpovie balíček RST, po prijatí útočného hostiteľa zatvorí pripojenie.

IpTables -i Input -M ConnTrack - CCTSTATE NOVÉHO, INPLADOVANÉ -P TCP -TCP-FLAGS SYN, AKK SYN, ACK -J -J -J -Jection-s TCP-reset

Iptables-uložiť\u003e /etc/ipTables.rules

Čo ešte môžete urobiť?

Nebráni trochu "outstuning" jadra, vytvorte jemné nastavenie Apache a nginx (ak stojí za to), dajte ďalšie moduly a balíčky na ochranu pred útokmi, ako napríklad Fault2ban, mod_evasive, modsEcurity.

Ale všetky tieto sú témy iných článkov, ktoré budú čoskoro napísané ...