Захист nginx від DDoS атак. Захист від DDOS за допомогою Nginx Створення дозволеного списку IP-адрес

Боротьба з DDoS-атаками - робота не тільки складна, але і захоплююча. Не дивно, що кожен системний адміністратор насамперед намагається організувати оборону своїми силами - тим більше що поки що це можливо.

Ми вирішили допомогти вам в цій нелегкій справі і опублікувати кілька коротких, тривіальних і не універсальних порад щодо захисту вашого сайту від атак. Наведені рецепти не допоможуть вам справитися з будь-атакою, але від більшості небезпек вони вас вбережуть.

правильні інгредієнти

Сувора правда така, що багато сайтів може покласти будь-який бажаючий, скориставшись атакою Slowloris, наглухо вбиває Apache, або влаштувавши так званий SYN-флуд за допомогою ферми віртуальних серверів, піднятих за хвилину в хмарі Amazon EC2. Всі наші подальші поради щодо захисту від DDoS своїми силами грунтуються на наступних важливих умов.

1. Відмовитися від Windows Server

Практика підказує, що сайт, який працює на винде (2003 або випуску 2008 - неважливо), в разі DDoS приречений. Причина невдачі криється в віндового мережевому стеку: коли з'єднань стає дуже багато, то сервер неодмінно починає погано відповідати. Ми не знаємо, чому Windows Serverв таких ситуаціях працює настільки огидно, але стикалися з цим не раз і не два. З цієї причини мова в даній статті буде йти про засоби захисту від DDoS-атак в разі, коли сервер крутиться на Linux. Якщо ви щасливий володар щодо сучасного ядра (починаючи з 2.6), то в якості первинного інструментарію виступатимуть утиліти iptables і ipset (для швидкого додавання IP-адрес), з допомогою яких можна оперативно забанити спамерських пошукових роботів. Ще один ключ до успіху - правильно приготований мережевий стек, про що ми також будемо говорити далі.

2. Розлучитися з Apache

Друга важлива умова - відмова від Apache. Якщо у вас, боронь Боже, варто Apache, то як мінімум поставте перед ним кешируєтся проксі - nginx або lighttpd. Apache "у вкрай важко віддавати файли, і, що ще гірше, він на фундаментальному рівні (тобто невиправно) вразливий для найнебезпечнішої атаки Slowloris, що дозволяє завалити сервер мало не з мобільного телефона. Для боротьби з різними видами Slowloris користувачі Apache придумали спочатку патч Anti-slowloris.diff, потім mod_noloris, потім mod_antiloris, mod_limitipconn, mod_reqtimeout ... Але якщо ви хочете спокійно спати по ночах, простіше взяти HTTP-сервер, невразливий для Slowloris на рівні архітектури коду. Тому всі наші подальші рецепти грунтуються на припущенні, що на фронтенді використовується nginx.

Відбиваємося від DDoS

Що робити, якщо прийшов DDoS? Традиційна техніка самооборони - почитати лог-файл HTTP-сервера, написати патерн для grep (відловлювати запити ботів) і забанити всіх, хто під нього потрапить. Ця методика спрацює ... якщо пощастить. Ботнети бувають двох типів, обидва небезпечні, але по-різному. Один цілком приходить на сайт моментально, інший - поступово. Перший вбиває все і відразу, зате в балках з'являється весь повністю, і якщо ви їх проgrepаете і забанили все IP-адреси, то ви - переможець. Другий ботнет укладає сайт ніжно і обережно, але банити вам його доведеться, можливо, протягом доби. Будь-якому адміністратору важливо розуміти: якщо планується боротися grep'ом, то треба бути готовим присвятити боротьбі з атакою пару днів. Нижче наведені поради про те, куди можна заздалегідь підкласти соломки, щоб не так боляче було падати.

3. Використовувати модуль testcookie

Мабуть, найголовніший, дієвий та оперативний рецепт цієї статті. Якщо на ваш сайт приходить DDoS, то найбільш ефективним способом дати відсіч може стати модуль testcookie-nginx, розроблений хабрапользователем @kyprizel. Ідея проста. Найчастіше боти, які реалізують HTTP-флуд, досить тупі і не мають механізмів HTTP cookie і редиректу. Іноді трапляються більш просунуті - такі можуть використовувати cookies та обробляти редіректи, але майже ніколи DoS-бот не несе в собі повноцінного JavaScript-движка (хоча це зустрічається все частіше і частіше). Testcookie-nginx працює як швидкий фільтр між ботами і бекенд під час L7 DDoS-атаки, що дозволяє відсівати сміттєві запити. Що входить в ці перевірки? Чи вміє клієнт виконувати HTTP Redirect, чи підтримує JavaScript, той чи він браузер, за який себе видає (оскільки JavaScript скрізь різний і якщо клієнт говорить, що він, скажімо, Firefox, то ми можемо це перевірити). Перевірка реалізована за допомогою кукисов з використанням різних методів:

«Set-Cookie» + редирект за допомогою 301 HTTP Location;
«Set-Cookie» + редирект за допомогою HTML meta refresh;
довільним шаблоном, причому можна використовувати JavaScript.

Щоб уникнути автоматичного парсинга, що перевіряє кукис може бути зашифрована за допомогою AES-128 і пізніше розшифрована на клієнтській стороні JavaScript. В нової версіїмодуля з'явилася можливість встановлювати кукис через Flash, що також дозволяє ефективно відсіяти ботів (які Flash, як правило, не підтримують), але, правда, і блокує доступ для багатьох легітимних користувачів (фактично всіх мобільних пристроїв). Примітно, що почати використовувати testcookie-nginx вкрай просто. Розробник, зокрема, наводить кілька зрозумілих прикладів використання (на різні випадки атаки) з семплами конфігов для nginx.

Крім достоїнств, у testcookie є і недоліки:

ріже всіх ботів, в тому числі Googlebot. Якщо ви плануєте залишити testcookie на постійній основі, Переконайтеся, що ви при цьому не пропадете з пошукової видачі;
створює проблеми користувачам з браузерами Links, w3m і їм подібними;
не рятує від ботів, оснащених повноцінним браузерні движком з JavaScript.

Словом, testcookie_module не універсальний. Але від ряду речей, таких як, наприклад, примітивні інструментарії на Java і C #, він допомагає. Таким чином ви відсікаєте частина загрози.

4. Код 444

Метою DDoS'еров часто стає найбільш ресурсномістка частина сайту. Типовий приклад - пошук, який виконує складні запити до бази. Природно, цим можуть скористатися зловмисники, зарядивши відразу кілька десятків тисяч запитів до пошукового движку. Що ми можемо зробити? Тимчасово відключити пошук. Нехай клієнти не зможуть шукати потрібну інформаціювбудованими засобами, але зате весь основний сайт буде залишатися в працездатному станідо тих пір, поки ви не знайдете корінь всіх проблем. Nginx підтримує нестандартний код 444, який дозволяє просто закрити з'єднання і нічого не віддавати у відповідь:

Location / search (return 444;)

Таким чином можна, наприклад, оперативно реалізувати фільтрацію по URL. Якщо ви впевнені, що запити до location / search приходять тільки від ботів (наприклад, ваша впевненість заснована на тому, що на вашому сайті взагалі немає розділу / search), ви можете встановити на сервер пакет ipset і забанити ботів простим shell-скриптом:

Ipset -N ban iphash tail -f access.log | while read LINE; do echo "$ LINE" | \ Cut -d "" "-f3 | cut -d" "-f2 | grep -q 444 && ipset -A ban" $ (L %% *) "; done

Якщо формат лог-файлів нестандартний (НЕ combined) або потрібно банити за іншими ознаками, ніж статус відповіді, - може знадобитися замінити cut на регулярний вираз.

5. Банимо по геопрізнаку

Нестандартний код відповіді 444 може стати в нагоді ще й для оперативного бана клієнтів по геопрізнаку. Ви можете жорстко обмежити окремі країни, від яких відчуваєте незручність. Скажімо, навряд чи у інтернет-магазину фотоапаратів з Ростова-на-Дону багато користувачів в Єгипті. Це не дуже гарний спосіб(Прямо скажемо - огидний), оскільки дані GeoIP неточні, а ростовці іноді літають в Єгипет на відпочинок. Але якщо вам втрачати нічого, то дотримуйтесь інструкцій:

Підключіть до nginx GeoIP-модуль (wiki.nginx.org/HttpGeoipModule).
Виведіть інформацію про геопривязку в access log.
Далі, модифікувавши Наведений вище шелл-скрипт, проgrepайте accesslog nginx'а і додайте відфутболених за географічною ознакою клієнтів в бан.

Якщо, наприклад, боти здебільшого були з Китаю, то це може допомогти.

6. Нейронна мережа (PoC)

Нарешті, ви можете повторити досвід хабрапользователя @SaveTheRbtz, який взяв нейронну мережу PyBrain, запхав у неї лог і проаналізував запити (habrahabr.ru/post/136237). Метод робочий, хоча і не універсальний :). Але якщо ви дійсно знаєте нутрощі свого сайту - а ви, як системний адміністратор, повинні, - то у вас є шанси, що в найбільш трагічних ситуаціях такий інструментарій на основі нейронних мереж, навчання та зібраної заздалегідь інформації вам допоможе. В цьому випадку дуже корисно мати access.log до початку DDoS "а, так як він описує практично 100% легітимних клієнтів, а отже, відмінний dataset для тренування нейронної мережі. Тим більше очима в балці боти видно не завжди.

діагностика проблеми

Сайт не працює - чому? Його DDoS'ят або це баг движка, не помічений програмістом? Неважливо. Не шукайте відповіді на це питання. Якщо ви вважаєте, що ваш сайт можуть атакувати, зверніться до компаній, які надають захист від атак, - у ряду анти-DDoS-сервісів першу добу після підключення безкоштовні - і не витрачайте більше час на пошук симптомів. Зосередьтеся на проблемі. Якщо сайт працює повільно або не відкривається взагалі, значить, у нього щось не в порядку з продуктивністю, і - незалежно від того, чи йде DDoS-атака чи ні, - ви, як професіонал, повинні заважати зрозуміти, чим це викликано. Ми неодноразово були свідками того, як компанія, яка має труднощі з роботою свого сайту через DDoS-атаки, замість пошуку слабких місць в движку сайту намагалася спрямовувати заяви в МВС, щоб знайти і покарати зловмисників. Не допускайте таких помилок. Пошук кіберзлочинців - це важкий і тривалий процес, ускладнений самою структурою і принципами роботи мережі Інтернет, а проблему з роботою сайту потрібно вирішувати оперативно. Примусьте технічних фахівців знайти, в чому криється причина падіння продуктивності сайту, а заяву зможуть написати юристи.

7. Юзайте профайлер і відладчик

Для найбільш поширеною платформи створення веб-сайтів - PHP + MySQL - вузьке місце можна шукати за допомогою таких інструментів:

профайлер Xdebug покаже, на які виклики додаток витрачає найбільше часу;
вбудований відладчик APD і зневаджувальної в лог помилок допоможуть з'ясувати, який саме код виконує ці виклики;
в більшості випадків собака зарита в складності і ваговитості запитів до бази даних. Тут допоможе вбудована в движок бази даних SQL-директива explain.

Якщо сайт лежить горілиць і ви нічого не втрачаєте, відключіться від мережі, подивіться логи, спробуйте їх програти. Якщо не лежить, то походіть по сторінках, подивіться на базу.

Приклад наведено для PHP, але думка має рацію для будь-якої платформи. Розробник, пише програмні продуктина якому б то ні було мовою програмування, повинен вміти оперативно застосовувати і відладчик, і профілювальник. Потренуйтеся заздалегідь!

8. Аналізуйте помилки

Проаналізуйте обсяг трафіку, час відповіді сервера, кількість помилок. Для цього дивіться логи. У nginx час відповіді сервера фіксується в балці двома змінними: request_time і upstream_response_time. Перша - це повне час виконання запиту, включаючи затримки в мережі між користувачем і сервером; друга повідомляє, скільки бекенд (Apache, php_fpm, uwsgi ...) виконував запит. Значення upstream_response_time надзвичайно важливо для сайтів з великою кількістю динамічного контенту і активним спілкуванням фронтенда з базою даних, їм не можна нехтувати. Як формат балки можна використовувати такий конфіг:

Log_format xakep_log "$ remote_addr - $ remote_user [$ time_local]" "" $ request "$ status $ body_bytes_sent" "" $ http_referer "" $ http_user_agent "$ request_time \ $ upstream_response_time";

Це combined-формат з доданими полями таймінгу.

9. Відстежуйте кількість запитів в секунду

Також подивіться на число запитів в секунду. У разі nginx ви можете приблизно оцінити цю величину наступної shell-командою (змінна ACCESS_LOG містить шлях до журналу запитів nginx в combined-форматі):

Echo $ (($ (fgrep -c "$ (env LC_ALL = C date [Email protected]$ (($ (Date \ +% s) -60)) +% d /% b /% Y:% H:% M) "" $ ACCESS_LOG ") / 60))

У порівнянні з нормальним для цього часу дня рівнем кількість запитів в секунду може як падати, так і рости. Ростуть вони в разі, якщо прийшов великий ботнет, а падають, якщо прийшов ботнет обрушив сайт, зробивши його повністю недоступним для легітимних користувачів, і при цьому ботнет статику не запитує, а легітимні користувачі запитують. Падіння кількості запитів спостерігається якраз за рахунок статики. Але, так чи інакше, ми ведемо мову про серйозні зміни показників. Коли це відбувається раптово - поки ви намагаєтеся вирішити проблему своїми силами і якщо не бачите її відразу в балці, краще швидко перевірте движок і паралельно зверніться до фахівців.

10. Не забувайте про tcpdump

Багато хто забуває, що tcpdump - це шалене засіб діагностики. Я приведу кілька прикладів. У грудні 2011-го був виявлений баг в ядрі Linux, коли воно відкривало TCP-з'єднання при виставлених прапорах TCP-сегмента SYN і RST. Першим багрепорт відправив саме системний адміністратор з Росії, чий ресурс був атакований цим методом, - атакуючі дізналися про уразливість раніше, ніж весь світ. Йому, очевидно, така діагностика допомогла. Інший приклад: у nginx є одне не дуже приємне властивість - він пише в лог тільки після повного відпрацювання запиту. Бувають ситуації, коли сайт лежить, нічого не працює і в балках нічого немає. Все тому, що всі запити, які в даний моментзавантажують сервер, ще не виконалися. Tcpdump допоможе і тут.

Він настільки гарний, що я радив людям не використовувати бінарні протоколи до того, як вони переконаються, що все в порядку, - адже текстові протоколи налагоджувати tcpdump "ом легко, а бінарні - немає. Однак сниффер хороший як засіб діагностики - як засіб підтримки production "а він страшний. Він легко може втратити відразу кілька пакетів і зіпсувати вам історію користувача. Дивитися його висновок зручно, і він стане в нагоді для ручної діагностикиі бана, але намагайтеся нічого критичного на ньому не засновувати. Інша улюблене багатьма засіб «погрепать запити» - ngrep - взагалі за замовчуванням намагається запросити в районі двох гігабайт несвопіруемой пам'яті і тільки потім починає зменшувати свої вимоги.

11. Атака чи ні?

Як відрізнити DDoS-атаку, наприклад, від ефекту рекламної кампанії? Це питання може здатися смішним, але ця тема не менш складна. Бувають досить курйозні випадки. У одних хороших хлопців, коли вони напружилися і грунтовно прикрутили кешування, сайт зліг на пару днів. З'ясувалося, що протягом кількох місяців цей сайт непомітно датамайнілі якісь німці і до оптимізації кешування сторінки сайту у цих німців з усіма картинками вантажилися досить довго. Коли сторінка початку видаватися з кеша моментально, бот, у якого не було ніяких тайм-аутів, теж почав збирати їх моментально. Важко довелося. Випадок особливо складний з тієї причини, що якщо ви самі змінили налаштування (включили кешування) і сайт після цього перестав працювати, то хто, на вашу і начальницького думку, винен? Ось ось. Якщо ви спостерігаєте різке зростання числа запитів, то подивіться, наприклад, в Google Analytics, хто приходив на які сторінки.

Тюнінг веб-сервера

Які ще є ключові моменти? Звичайно, ви можете поставити «умолчальне» nginx і сподіватися, що у вас все буде добре. Однак добре завжди не буває. Тому адміністратор будь-якого сервера повинен присвятити чимало часу тонкій настройці і тюнінгу nginx.

12. лімітіруя ресурси (розміри буферів) в nginx

Про що потрібно пам'ятати в першу чергу? Кожен ресурс має ліміт. Перш за все це стосується оперативної пам'яті. Тому розміри заголовків і всіх використовуваних буферів потрібно обмежити адекватними значеннями на клієнта і на сервер цілком. Їх обов'язково потрібно прописати в конфігу nginx.

client_header_buffer_size_ _ Задає розмір буфера для читання заголовка запиту клієнта. Якщо рядок запиту або поле заголовка запиту не поміщаються повністю в цей буфер, то виділяються буфери більшого розміру, що задаються директивою large_client_header_buffers.
large_client_header_buffersЗадає максимальне число і розмір буферів для читання великого заголовка запиту клієнта.
client_body_buffer_sizeЗадає розмір буфера для читання тіла запиту клієнта. Якщо тіло запиту більше заданого буфера, то все тіло запиту або тільки його частина записується в тимчасовий файл.
client_max_body_sizeзадає максимально допустимий розміртіла запиту клієнта, що вказується в полі «Content-Length» заголовка запиту. Якщо розмір більше заданого, то клієнту повертається помилка 413 (Request Entity Too Large).

13. Налаштовуємо тайм-аути в nginx

Ресурсом є і час. Тому наступним важливим кроком повинна стати установка всіх тайм-аутів, які знову ж таки дуже важливо акуратно прописати в настройках nginx.

reset_timedout_connection on;Допомагає боротися з сокетами, завислими в фазі FIN-WAIT.
client_header_timeoutЗадає тайм-аут при читанні заголовка запиту клієнта.
client_body_timeoutЗадає тайм-аут при читанні тіла запиту клієнта.
keepalive_timeoutЗадає тайм-аут, протягом якого keep-alive з'єднання з клієнтом не буде закрито з боку сервера. Багато хто боїться ставити тут великі значення, але ми не впевнені, що цей страх виправданий. Опціонально можна виставити значення тайм-ауту в HTTP-заголовку Keep-Alive, але Internet Explorerзнаменитий тим, що ігнорує це значення
send_timeoutЗадає тайм-аут при передачі відповіді клієнту. Якщо після закінчення цього часу клієнт нічого не прийме, буде закрито.

Відразу питання: які параметри буферів і тайм-аутів правильні? Універсального рецепту тут немає, в кожній ситуації вони свої. Але є перевірений підхід. Потрібно виставити мінімальні значення, при яких сайт залишається в працездатному стані (в мирний час), тобто сторінки віддаються і запити обробляються. Це визначається тільки тестуванням - як з десктопів, так і з мобільних пристроїв. Алгоритм пошуку значень кожного параметра (розміру буфера або тайм-ауту):

Виставляємо математично мінімальне значення параметра.
Запускаємо прогін тестів сайту.
Якщо весь функціонал сайту працює без проблем - параметр визначений. Якщо немає - збільшуємо значення параметра і переходимо до п. 2.
Якщо значення параметра перевищило навіть значення за замовчуванням - це привід для обговорення в команді розробників.

У ряді випадків ревізія даних параметрів повинна приводити до рефакторингу / редизайну сайту. Наприклад, якщо сайт не працює без трихвилинних AJAX long polling запитів, то потрібно не тайм-аут підвищувати, а long polling замінювати на щось інше - ботнет в 20 тисяч машин, що висить на запитах по три хвилини, легко вб'є середньостатистичний дешевий сервер.

14. лімітіруя з'єднати в nginx (limit_conn і limit_req)

У nginx також є можливість лімітувати з'єднання, запити і так далі. Якщо ви не впевнені в тому, як поведе себе певна частина вашого сайту, то в ідеалі вам потрібно протестувати її, зрозуміти, скільки запитів вона витримає, і прописати це в конфігурації nginx. Одна справа, коли сайт лежить і ви здатні прийти і підняти його. І зовсім інша справа - коли він ліг до такої міри, що сервер пішов в swap. У цьому випадку найчастіше простіше перезавантажитися, ніж дочекатися його тріумфального повернення.

Припустимо, що на сайті є розділи з промовистими назвами / download і / search. При цьому ми:

не хочемо, щоб боти (або люди з надто запопадливим рекурсивними download-менеджерами) забили нам таблицю TCP-з'єднань своїми завантаженнями;
не хочемо, щоб боти (або зальотні краулери пошукових систем) Вичерпали обчислювальні ресурси СУБД безліччю пошукових запитів.

Для цих цілей згодиться конфігурація такого вигляду:

Http (limit_conn_zone $ binary_remote_addr zone = download_c: 10m; limit_req_zone $ binary_remote_addr zone = search_r: 10m \ rate = 1r / s; server (location / download / (limit_conn download_c 1; # Інша конфігурація location) location / search / (limit_req zone = search_r burst = 5; # Інша конфігурація location)))

Зазвичай має прямий сенс встановити обмеження limit_conn і limit_req для locations, в яких знаходяться дорогі до виконання скрипти (в прикладі вказано пошук, і це неспроста). Обмеження необхідно вибирати, керуючись результатами навантажувального і регресійного тестування, а також здоровим глуздом.

Зверніть увагу на параметр 10m в прикладі. Він означає, що на розрахунок даного ліміту буде виділено словник з буфером в 10 мегабайт і ні мегабайтом більше. У даній конфігурації це дозволить відстежувати 320 000 TCP-сесій. Для оптимізації займаної пам'яті в якості ключа в словнику використовується змінна $ binary_remote_addr, яка містить IP-адресу користувача в бінарному вигляді і займає менше пам'яті, ніж звичайна строкова змінна $ remote_addr. Потрібно зауважити, що другим параметром до директиви limit_req_zone може бути не тільки IP, але і будь-яка інша змінна nginx, доступна в даному контексті, - наприклад, у разі, коли ви не хочете забезпечити більш щадний режим для проксі, можна використовувати $ binary_remote_addr $ http_user_agent або $ binary_remote_addr $ http_cookie_myc00kiez - але використовувати такі конструкції потрібно з обережністю, оскільки, на відміну від 32-бітного $ binary_remote_addr, ці змінні можуть бути істотно більшої довжини і декларовані вами «10m» можуть раптово закінчитися.

Тренди в DDoS

Безперервно зростає потужність атак мережевого і транспортного рівня. Потенціал середньостатистичної атаки типу SYN-флуд досяг вже 10 мільйонів пакетів в секунду.
Особливим попитом останнім часом користуються атаки на DNS. UDP-флуд валідними DNS-запитів з spoof'леннимі IP-адресами джерела - це одна з найбільш простих в реалізації і складних в плані протидії атак. Багато великі російські компанії (в тому числі хостинги) відчували останнім часом проблеми в результаті атак на їх DNS-сервери. Чим далі, тим таких атак буде більше, а їх потужність буде зростати.
Судячи за зовнішніми ознаками, більшість ботнетів управляти не централізовано, а за допомогою пиринговой мережі. Це дає зловмисникам можливість синхронізувати дії ботнету в часі - якщо раніше керуючі команди поширювалися по ботнету в 5 тисяч машин за десятки хвилин, то тепер рахунок йде на секунди, а ваш сайт може несподівано випробувати миттєвий стократний зростання числа запитів.
Частка ботів, оснащених повноцінним браузерні движком з JavaScript, все ще невелика, але невпинно зростає. Таку атаку складніше відбити вбудованими підручними засобами, тому Самодєлкіна повинні з побоюванням стежити за цим трендом.

готуємо ОС

Крім тонкої настройки nginx, потрібно подбати про налаштування мережевого стека системи. Щонайменше - відразу включити net.ipv4.tcp_syncookies в sysctl, щоб разом захистити себе від атаки SYN-floodневеликого розміру.

15. Тюнім ядро

Зверніть увагу на більш просунуті налаштування мережевої частини (ядра) знову ж по тайм-аутам і пам'яті. Є більш важливі і менш важливі. В першу чергу треба звернути увагу на:

net.ipv4.tcp_fin_timeoutЧас, який сокет проведе в TCP-фазі FIN-WAIT-2 (очікування FIN / ACK-сегмента).
net.ipv4.tcp _ (, r, w) memРозмір приймального буфера сокетов TCP. Три значення: мінімум, значення за замовчуванням і максимум.
net.core. (r, w) mem_maxТе ж саме для НЕ TCP буферів.

При каналі в 100 Мбіт / с значення за замовчуванням ще якось годяться; але якщо у вас в наявності хоча б гігабіт на cекунд, то краще використовувати щось на зразок:

Sysctl -w net.core.rmem_max = 8388608 sysctl -w net.core.wmem_max = 8388608 sysctl -w net.ipv4.tcp_rmem = "4096 87380 8388608" sysctl -w net.ipv4.tcp_wmem = "4096 65536 8388608" sysctl - w net.ipv4.tcp_fin_timeout = 10

16. Ревізія / proc / sys / net / **

Ідеально вивчити всі параметри / proc / sys / net / **. Треба подивитися, наскільки вони відрізняються від дефолтних, і зрозуміти, наскільки вони адекватно виставлені. Linux-розробник (або системний адміністратор), що розбирається в роботі підвладного йому інтернет-сервісу і бажаючий його оптимізувати, повинен з інтересом прочитати документацію всіх параметрів мережевого стека ядра. Можливо, він знайде там специфічні для свого сайту змінні, які допоможуть не тільки захистити сайт від зловмисників, але і прискорити його роботу.

Не боятися!

Успішні DDoS-атаки день у день гасять e-commerce, стрясають ЗМІ, c одного удару відправляють в нокаут найбільші платіжні системи. Мільйони інтернет-користувачів втрачають доступ до критичної інформації. Загроза насущна, тому потрібно зустрічати її у всеозброєнні. Виконайте домашню роботу, не бійтеся і тримайте голову холодною. Ви не перший і не останній, хто зіткнеться з DDoS-атакою на свій сайт, і в ваших силах, керуючись своїми знаннями і здоровим глуздом, звести наслідки атаки до мінімуму.

Деякий час назад я написав докладну статтю про встановлення та налаштування web сервера на базі останніх версій. Там я згадав, що це перша стаття з циклу нотаток про веб сервері. Сьогодні я розповім як простими і підручними засобами захиститися від простих ddosатак.

Відразу зроблю застереження з приводу слова ddos, яке тут не зовсім доречно, але я не придумав, як ще популярно пояснити про що йдеться. Від повноцінної ddos атаки ви не зможете захиститися в рамках настройки веб сервера. У вас просто буде забитий весь канал і сервер перестане відповідати. Якщо потужності сервера мало для обробки і фільтрації вхідних запитів, то він ляже, щоб ви там не робили. Для повноцінного захисту від ddos потрібні повноцінні засоби, Які стоять відчутних фінансових витрат. Більш детально з теорією по читайте в окремій статті.

Потрібно розуміти, що захист від ddos повинна бути адекватна значущості ресурсу. Якщо у вас персональний блог, який не приносить істотного прибутку, то платити за захист від ddos безглуздо. Досить просто полежати якийсь час або зробити захист своїми силами. Загалом, завжди потрібно узгоджувати вартість простою з вартістю захисту і на основі цього приймати рішення про доцільність того чи іншого методу.

Я приведу поради щодо захисту від простих атак ботів або якихось дрібних шкідників і капосників, які без належних дій з вашого боку можуть покласти ваш сайт або сервер без особливих проблем. Ось простий приклад. Є не дуже слабкий, на борту якого 2 ярда, 8 гигов оператіви і ssd диск.

Сервер налаштований по моїй попередній статті, посилання на яку привів на початку. На сервері розгорнуть wordpress сайт з деяким вмістом. І є у нас шкідник, який на своєму сервері запускає простий тест від apache на продуктивність веб сервера:

# Ab -c 50 -n 30000 "https://hl.zeroxzed.ru/"

Всього лише 50 паралельних потоків. Що ми бачимо на своєму веб сервері:

Не дуже приємна картина. Сервер завантажений на 100%. І хоча він нормально обробляє запити і в цілому коректно працює. Навіть не дуже гальмує, але все одно це погано. А якщо буде 3 сервера і по 100 потоків на кожному? Немає ніяких проблем навіть на тест взяти у різних хостерів по віртуальній машиніі запускати на них подібні штуки, імітуючи ддос атаку.

Загалом, якщо ви зовсім не зробили ніякого захисту на своєму сервері, то будь-яка людина зможе вам без особливих проблем доставити деякі незручності. Захиститися від такої «атаки» не складно. Далі я розповім як це зробити.

Захист від ddos за допомогою iptables

Для захисту від найпростішої атаки ми будемо використовувати firewall - iptables, Модуль ядра ipsetдля зберігання великих списків ip і самописние скрипти. За фаєрвол дивіться мою статтю -. Тут я не буду на цьому зупинятися.

Питання настройки ipset я докладно розглядав у своїй статті по. Раджу подивитися матеріал, так як він безпосередньо пов'язаний з цією статтею і доповнює її.

Отже, приступимо до створення нашої простий захисту від dos атаки з великою кількістю підключень з одного ip адреси. Для початку перевіримо команду, яка покаже нам кількість підключень з кожного ip адреси:

Ось він, порушник нашого спокою, намагається організувати дос атаку на наш сервер. Тепер намалюємо скрипт, який буде блокувати всіх хто встановлює більш 50-ти одночасних з'єднань з сайтом.

В принципі, коментувати тут особливо нічого. Беремо список підключень, який тільки що вивели, в ньому порівнюємо першу колонку, якщо вона більше 50, то результат другої колонки, де записаний ip адресу, передаємо в файл.

Далі читаємо цей файл і додаємо всі ip адреси з нього в ipset список під назвою much_conn. Попередньо його треба створити. Детально про це я розповідав в статті, на яку привів посилання вище, але повторю ще раз тут:

# Ipset -N much_conn iphash

Подивитися вміст списку можна командою:

# Ipset -L much_conn

Тепер потрібно додати в iptables правило, за яким будуть блокуватися всі підключення із зазначеного списку ipset.

# Iptables -A INPUT -m set --match-set much_conn src -j DROP

Про всяк випадок попереджаю, щоб ви перевірили свій доступ до консолі сервера, перш ніж налаштовувати правила iptables. Всяке буває, можна просто помилитися, скопіювати і вставити не те, що потрібно.

Все, ми заблокували всіх, хто створює масовий спам підключень до сервера. Обмеження в 50 підключень можете виправляти за місцем, можливо його потрібно буде зменшити, якщо хтось буде відкривати менше підключень з одного ip.

Єдиний момент, про який хочу сказати. Сам я не перевіряв, скільки підключень відкривають пошукові боти, коли приходять на сайт. Я підозрюю, що явно не 50 і навіть не 30, але напевно я не перевіряв. Загалом, будьте обережні, коли використовуєте це засіб.

Даний скрипт можна засунути в крон і запускати кожну хвилину. Але особисто я б так не став робити. Я рекомендую моніторити ресурси сервера і запускати подібні засоби, тільки якщо сервер працює на межі своїх можливостей і ви вручну зайшли і переконалися, що вас хтось спамить підключеннями. Після цього врубать на якийсь час даний скрипт по крону. Коли ddos припиниться, відключайте.

Було б непогано якось автоматично очищати список заблокованих, видаляючи звідти тих, хто вже добу до вас не підключається, але це сильно ускладнює завдання. Потрібно як мінімум вести лог по блокуючого списку, зберігати час останнього звернення. Обробляти все це, вираховувати. Загалом, завдання хоч і не сильно складна, але вже не тривіальна. Мені не захотілося цим займатися.

Є хоч і не дуже витончене, але просте рішення цієї проблеми. Створити список ipset до заданого часу життя запису за допомогою timeout. Наприклад ось так:

Ipset -N much_conn iphash timeout 3600

В даному випадку запис з забаненим ip в списку ipset буде зберігатися протягом 3600 секунд або 60 хвилин.

Потрібно розуміти, що в даному прикладіз 1 ip адресою використовувати ipset немає ніякого сенсу, можна відразу банити засобами самого iptables. Ipset потрібен тільки тоді, коли цей список хоча б в сотні рядків. Якщо там кілька десяткою адрес, вистачить і одного iptables.

Аналіз лог файлу web сервера для захисту від ddos

Розглянемо ще один простий, але все ж більш складний тип ддос атаки, коли йдуть типові запити з різних IP. Тобто простий ботнет, може бути навіть зібраний руками з декількох дешевих vds серверів. Одночасних підключень буде не багато, але якщо у вас важкий сайт і зловмисник знайде його слабке місце (наприклад пошук), то цього може бути достатньо, щоб покласти сайт.

Банити будемо теж через iptables, а список адрес для бана будемо отримувати з логів веб сервера. Для цього у вас має бути включено логирование запитів до веб сервера. Наприклад, в nginx за це відповідає така настройка віртуального хоста:

Access_log /web/sites/hl.zeroxzed.ru/log/access.log main;

Ми не будемо кожен раз аналізувати весь лог файл. Ця операція сама по собі буде сильно навантажувати веб сервер. Візьмемо останні 1000 рядків з лог файлу та порахуємо кількість підключень з одного ip до типового вмістом, наприклад запит головної сторінки по протоколу http 1.0, «GET / HTTP / 1.0». Якщо ви помітите інший постійний ознака ботнету, який вас атакує, використовуйте його. Це може бути один і той же user agent або щось ще. Припустимо, якщо атакуючий буде довбати в уразливе місце, то це буде адреса цієї сторінки.

# Tail -1000 /web/sites/hl.zeroxzed.ru/log/ssl-access.log | egrep "GET / HTTP / 1.0" | awk "(print $ 1)" | sort -n | uniq -c

Результатом цієї команди буде приблизно такий список.

В даному випадку я використав трохи іншу умову і просто вивів список всіх тих, хто стукав на головну сторінку. Але вже тут видно порушника, якого можна забанити.

Малюємо схожий на попередній скрипт для автоматичного блокуваннятих, хто відправляє занадто багато запитів на наш сайт і створює проблеми з продуктивністю. Повторюся ще раз, якщо проблем з продуктивністю немає, я не рекомендую робити зайвих рухів.

Тут робимо те ж саме, що і раніше. Ті, хто зробили більше 50-ти однакових запитів по нашій масці на останні 1000 рядків в лог файлі, відправляються в бан.

Звертаю увагу на рядок, по якій ви будете фільтрувати запити. В даному випадку я показав лише приклад. Не треба брати і застосовувати в тому вигляді, як я показую. Я демонструю технічні можливості і підхід. Налаштовувати і калібрувати систему вам потрібно у себе за місцем. Важливо це розуміти і не застосовувати рішення бездумно. Буде тільки шкоду.

Не забудьте створити окремий список в ipset і додати окреме правило в ipables. Можна використовувати вже існуючий список і доданий правило з попереднього прикладу, але я рекомендую все розділяти. Так зручніше для подальшого аналізу.

Під час ddos атаки додаєте це правило в cron і виконуєте кожну хвилину. Після завершення атаки скрипт можна відключити. В принципі, можна і на постоянку залишати, але тут потрібно гарненько подумати і прикинути, як воно має виглядати. Головний принцип - не нашкодити.

Банимо ботів з неправильним referer

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

Коректне поле referer повинно містити або http, або https, або бути порожнім. Все, що інакше, можна сміливо блокувати або повертати статус помилки. Додаємо приблизно таку конструкцію в конфігурацію віртуального хоста, в розділ server ().

If ($ http_referer! ~ * ^ ($ | Http: // | https: //)) (return 403;)

Після цього перевірте конфігурацію nginx і перечитайте її.

# Nginxt -t # nginx -s reload

Якщо вас дістає якийсь бот з конкретним referer, можна забанити саме його. Для цього можна доповнити умова, або змінити. Наприклад, ось так:

If ($ http_referer = "https://bots.ru/dostanim_tebya.html") (return 403;)

На додаток, можна всіх цих ботів за допомогою простого скрипта банити на iptables, як в прикладах вище. До слова сказати, їх можна банити відразу, розбираючи http запити ще до того, як вони будуть потрапляти до nginx, наприклад, за допомогою ngrep, але це більш складне завдання. Не всі це вміють робити, там є нюанси, а з nginx знайомі всі. Чи не складе великих труднощів реалізувати даний метод.

Захист від ддос за допомогою модулів nginx - limit_conn і limit_req

Поділюся ще одним простим способом знизити навантаження на сервер і частково захиститися від ддос за допомогою модулів nginx - limit_connі limit_req. Налаштувати їх не складно, частково результат роботи першого модуля буде перетинатися з першими двома способами ddos захисту, описаними в початку. Він простіший для настройки, так що якщо не впоралися з тими способами, можна спробувати цей.

Сенс даних модулів в тому, що один може обмежити одночасне кількість дозволених з'єднань з сайтом, а інший кількість з'єднань в одиницю часу.

Я обмежу в своєму прикладі кількість одночасних підключень до сайту з одного ip числом 50, а кількість одночасних запитів до динамічного контенту не більше 2-х в секунду. При цьому буде дозволений сплеск ( burst) Запитів до 5-ти. Поясню, як розуміти цей сплеск, так як сам не відразу зрозумів, що конкретно він означає.

Якщо у нас йде перевищення кількості встановлених запитів в секунду, то їх виконання затримується, і вони шикуються в чергу на виконання із зазначеною швидкістю. Розмір цієї черги і дорівнює значенню сплеску. Всі запити, яким не вистачить місця в черзі, будуть завершені з помилкою. Тобто, якщо запитів буде 4 в секунду, то 2 виконуватися відразу і ще 2 встануть в чергу. А якщо буде 10, то 2 виконуватися відразу, 5 встануть в чергу на виконання по 2 штуки в секунду, а решта будуть завершені з помилкою.

Виходячи з цих умов, обмеження на підключення потрібно встановити в контексті server, А на доступ до динамічного контенту в відповідному location. При цьому опис зон, які будуть використовувати директиви, потрібно розташувати в http.

Ось приклад конфіга nginx для реалізації встановлених обмеженьз метою захисту від ддос атак.

Http (... limit_conn_zone $ binary_remote_addr zone = perip: 10m; limit_req_zone $ binary_remote_addr zone = dynamic: 10m rate = 2r / s; ... server (... limit_conn perip 50; ... location ~ \ .php $ ( ... limit_req zone = dynamic burst = 5 nodelay; ...)))

Після цього перезапустіть nginx і перевірте як працюють ліміти. Обмеження на кількість виконуваних динамічних запитів можна побачити, просто натискаючи дуже швидко F5 в браузері. Якщо будете досить спритні, то скоро побачите картинку

і запис в балці з помилками:

2017/11/30 15:25:26 9773 # 9773: * 51482 limiting requests, excess: 5.664 by zone "dynamic", client: 195.91.248.43, server: hl.zeroxzed.ru, request: "GET / HTTP / 2.0 ", host:" hl.zeroxzed.ru ", referrer:" https://hl.zeroxzed.ru/2013/03/15/featured-image-vertical/ "

Ліміт на кількість підключень можете перевірити тієї ж утилітою ab, Про яку я розповів у вступі.

017/11/30 15:38:56 9773 # 9773: * 53938 limiting connections by zone "perip", client: 94.142.141.246, server: hl.zeroxzed.ru, request: "GET / wp-content / uploads / 2013 /03/the-dark-knight-rises.jpg HTTP / 1.0 ", host:" hl.zeroxzed.ru "

Тільки не забувайте, що тест потрібно запускати нема на конкретну сторінку, тоді ви потрапите на обмеження виконання динамічного контенту, а на щось інше. Наприклад, як в моєму прикладі, на картинку.

При виставленні обмежень, не забудьте проконтролювати, чи не потрапляють в ці обмеження пошукові боти. За замовчуванням, вони намагаються не створювати підвищене навантаження на сайт. При бажанні, роботу яндекса можна вказати через robots.txt, з якою швидкістю сканувати ваш сайт. А роботу гугла те ж саме можна зробити через webmaster.

висновок

Я розглянув найбільш прості способидля захисту webсервера від не менш простих ddos атак, які більше схожі на пустощі. Серйозна атака, яка просто заллє весь вхідний канал сервера, навіть не помітить наших захистів. Але тим не менше, мені доводилося переконуватися в ефективності цих способів в відображенні деяких атак.

Існує до сих пір величезну кількість веб-серверів, які взагалі ніяк не захищені навіть від утиліти ab:) Я знаю про що кажу, так як мені трапляються в роботу такі сервери. І є так само багато всяких ботів і простих програм, які можна знайти на просторах інтернету і побалуватися, завалюючи сайти, які не готові до навантажень взагалі.

Є ще один спосіб, такий же простий, як я описав, і ефективний від ботів, які не розуміють редиректів і кукисов. Не став його описувати, так як ні на чому перевірити, та й просто втомився писати статтю, вона вийшла дуже велика. Писав і редагував її довго, збираючи скрипти і настройки по різних серверіві згадуючи, що я колись робив. Потім перевіряв все це окремо.

Суть захисту в тому, що за допомогою nginx видаємо користувачеві певну cookies, а потім редирект на запитувану сторінку. Якщо бот не розуміє кукисов або редиректів, то він відвалюється. Нормальні користувачі нічого не помічають. Можливо пізніше я окремо розповім про цей спосіб і доповню статтю. А поки все. Буду радий зауважень по суті в статтях.

Онлайн курс по Linux

Якщо у вас є бажання навчитися будувати і підтримувати високодоступних і надійні системи, рекомендую познайомитися з онлайн-курсом «Адміністратор Linux»в OTUS. Курс не для новачків, для надходження потрібні базові знання з мереж і установці Linux на виртуалку. Навчання триває 5 місяців, після чого успішні випускники курсу зможуть пройти співбесіди у партнерів. Що дасть вам цей курс:

Знання архітектури Linux.
Освоєння сучасних методів та інструментів аналізу і обробки даних.
Уміння підбирати конфігурацію під необхідні завдання, управляти процесами і забезпечувати безпеку системи.
Володіння основними робочими інструментами системного адміністратора.
Розуміння особливостей розгортання, налаштування і обслуговування мереж, побудованих на базі Linux.
Здатність швидко вирішувати виникаючі проблеми і забезпечувати стабільну і безперебійну роботу системи.

Перевірте себе на вступний тест і дивіться докладніше програму по.

Веб-проекти дуже часто стикаються з DDOS атаками. Сьогодні ми розглянемо один з базових спосіб захисту від HTTP-Flood.

Вступ:

Нещодавно на один з проектів мого знайомого сталася атака, швидше за все, атакував недосвідчений хакер, так як атака велася з одного ip адреси.

В ході аналізу логів було встановлено, що зловмисник намагається завантажити багато разів головну сторінку, а сервер намагається обробити ці запити і не може.

Для захисту від атак подібного роду ми будемо використовувати проксі сервер nginx і стандартний модуль ngx_http_limit_conn_module

Модуль ngx_http_limit_conn_module дозволяє обмежити число з'єднань по заданому ключу, зокрема, число з'єднань з однієї IP-адреси.

Враховуються не всі з'єднання, а лише ті, в яких є запити, що обробляються сервером, і заголовок запиту вже прочитаний.

Інакше кажучи, ми можемо поставити обмеження на кількість запитів і підключень з одного ip адреси. Цього вистачить для захисту від слабких і середніх HTTP-Flood атак.

Для установки обмеження ми будемо використовувати директиву limit_conn

Налаштування nginx для захисту від DDoS:

limit_conn:

limit_conn задає максимально припустиме число з'єднань з одного ip. При перевищенні цього числа у відповідь на запит сервер поверне помилку 503 (Service Temporarily Unavailable).

Після отримання помилки 503, атакуючий перестане створювати корисну-навантаження на сервер бази даних, наприклад MySQL, тим самим розвантаживши його.

Але перед тим як використовувати limit_conn для захисту від DDOS атак за допомогою nginx, ми повинні розібратися і встановити директиву limit_conn_zone

limit_conn_zone:

синтаксис: limit_conn_zoneключ zone = назва: розмір;
Задає параметри зони розділяється пам'яті, яка зберігає стан для різних значеньключа. Стан зокрема містить поточне число з'єднань. Як ключ можна використовувати текст, змінні і їх комбінації. Запити з порожнім значенням ключа не враховуються.
Приклад використання:

приклад використання

limit_conn_zone $ binary_remote_addr zone = addr: 10m;

Ця директива потрібна, щоб зберігати стан для кожного ip адреси. Це важливо!Дана директива повинна йти в nginx.conf відразу після http (.

Приклад конфігурації nginx.conf для limit_conn_zone:

приклад конфігурації

http (limit_conn_zone $ binary_remote_addr zone = addr: 10m; ...

http (

limit_conn _ zone $ binary_remote_addr zone = addr: 10m;

. . .

Після установки директиви limit_conn_zone ми перейдемо до установки limit_conn

синтаксис: limit_connзона число;

Зверніть увагу, що зону необхідно брати із зони, встановленої в limit_conn_zone, в нашому випадку addr.

3-й параметр «число» позначає число одночасно відкритих з'єднань з одного ip адреси.

Для того, щоб обмежити 3-ма одночасними підключеннямидля зони addr, необхідно написати такі:

limit_conn addr 3;

Приклад конфігурації для захисту від DDoS атак за допомогою nginx і limit_conn:

http (limit_conn_zone $ binary_remote_addr zone = addr: 10m; ... server (listen 80; ... location / (limit_conn addr 3; ...)))

http (

limit_conn _ zone $ binary_remote_addr zone = addr: 10m;

Власне навіщо взагалі забороняти доступ до сайту за географічною ознакою? Так просто 80% IP адрес беруть участь в ddos атаці, як правило належать країнам, жителі яких ніколи не зайдуть на даний сайт, природно це суто індивідуально для кожного ресурсу і якщо ви знаєте що частина ваших відвідувачів приходить з Ефіопії або Чилі, блокувати їх, ви навряд-чи захочете. У більшості-же моїх клієнтів, географічне розташування відвідувачів, як правило обмежується Європою і колишнім СРСР, інших можна сміливо ігнорувати.

Описуваний спосіб блокування неугодних країн за допомогою веб сервера nginxі geoipмодуля, в поодинці, і тим більше цілком, проблему ніяк не вирішить, це лише одна, з цілого ряду всіляких заходів (настройка ядра, фаєрвола, штатних сервісів, додаткового софта), по мінімізації шкоди, що завдається даним видом атаки сервера і сайтам, на ньому розташованим.

Проекти, часто потребують подібного роду захист, я по можливості намагаюся спочатку піднімати без участі веб сервера apache, тобто на зв'язці nginx - fastcgi.

Отже, ставити і налаштовувати все це господарство будемо на сервері під керуванням операційної системи FreeBSD 8.2 and64.

Що-б модуль geoipзаробив, буде потрібна додаткова бібліотека, ставимо:

Freebsd82 / usr / ports # make -C net / GeoIP install clean

Freebsd82 / usr / ports # make -C www / nginx install clean

в опціях збірки потрібно включити geoipмодуль nginx, Поставивши галочку навпроти пункту Enable http_geoip module.

Далі йдемо на сторінку http://www.maxmind.com/app/geolitecountry і викачуємо latest GeoLite Country Binary Format, Це безкоштовний варіант бази країн і відповідних їм блоків IP адрес. Розпаковуємо архів і кидаємо файл GeIP.datв папку / Usr / local / etc / nginx / conf / geo. Залишилося відредагувати конфіги nginx.

відкриваємо nginx.conf, Дописуємо в секцію httpнаступний блок директив:

Geoip_country /usr/local/etc/nginx/conf/geo/GeoIP.dat; # Підключаємо GeIP базу map $ geoip_country_code $ bad_country ( # Модуль map створює змінні, значення яких залежать від інших змінних, дуже корисна штука default 1; # значення за замовчуванням include geo / good_countries; # Інклуд файл, до нього повернемося трохи пізніше }

цей блок map, Означає, що всі країни знаходяться в базі даних, є забороненими за замовчуванням, а в файлі good_countries, Будуть перераховані дозволені країни. Якщо у вас наприклад ситуація, коли дозволених країн більше ніж заборонених, можна легко инвертировать дану логіку і створити файл bad_countriesзі списком заборонених країн, дозволивши всі інші.

Тепер налаштування хоста. Я вважаю за краще тримати хости в окремій папці, наприклад hosts, Кожен в своєму файлі.

Server (listen IP: 80; server_name testhost.com; if ($ bad_country) ( # Якщо дана змінна встановлена, то є якщо країна не перерахована в файлі good_countries return 444; # Видаємо клієнту порожній відповідь (нема чого віддавати 403 помилку або ще яку-небудь) } ................. ................. }

Тепер повернемося до файлу good_countries. Тут все гранично просто, країни, яким дозволений доступ на сайт, перераховані в наступному форматі:

TM 0; UA 0; UZ 0; RU 0; ....... ....... і т.д.

Тобто, що-б дозволити будь-яку країну, досить додати її двобуквений код і 0, після чого перезавантажити конфиг nginx:

Freebsd82 / # nginx -s reload

Самі коди країн, на раз два, знаходяться через гугл.

Перевірити, працює geoipмодуль чи ні, можна, видаливши зі списку дозволених країн свою, і спробувавши зайти на сайт.

Власне така загальна схема використання geoip модуля nginx для захисту від ddos атак.

Природно можна придумати масу інших варіантів застосування даного модулядля вирішення різних завдань пов'язаних з географічним розташуванням користувача сайту.

Буває сидиш такий, нікого не чіпаєш, а тут тобі дзвонять і кажуть що сервіси працюють повільно, сайти відкриваються по 2-3 хвилини примудряються видавати 504 помилку.
Засмученим лізеш в cacti, а там таке:

Нижче будуть приведені команди, які допоможуть зрозуміти вам, що сталося, і чи точно це DDos.

Для початку я рекомендую прочитати статтю в ній докладно описано які логи нам цікаві, як читати висновок команди top і як користуватися командою ps. Всі вони нам стануть в нагоді для того щоб зрозуміти які хости у нас були атаковані і які вузькі місця є на сервері.

Якими командами, і що ми можемо визначити?

Для початку можна подивитися число запущених процесів Apache. Якщо їх більше 20-30 то явно вже щось не так.

Дивимося число процесів Apache в Debian:

Ps aux | grep apache | wc -l

Дивимося число процесів Apache в CentOS:

Ps aux | grep httpd | wc -l

Даною командою ми можемо подивитися кількість з'єднань з сервером:

Cat / proc / net / ip_conntrack | wc -l

Так само показником того, що на сервер йде DDos може служити числі коннектов на 80 або 443 порт. Ось команди здатні показати це число:

Netstat -na | grep: 80 | wc -l netstat -na | grep: 443 | wc -l

Існує ще такий різновид DDod, як SYN. Нижче приведена команда дозволяє визначити число SYN запитів на ті ж 80 і 443 порти:

А ця команда показує кількість SYN запитів:

Netstat -n -t | grep SYN_RECV | wc -l

Наступна команда дозволить зрозуміти нам, на який домен йде найбільше запитів:

Tcpdump -npi eth0 port domain

Тепер подивимося скільки запитів приходить з кожного IP. Ця команда показує по всіх портах:

аналогічні команди:

Ця команда показує кількість запитів тільки по 80 порту:

Ця команда показує всі запити на 80 порт, крім них, тобто «Спрощений» та «найбільш повний» варіант виведення:

Обчисливши найбільш активний IP можна так само подивитися на які порти йдуть з нього запити. Тут для прикладу підставлений IP 127.0.0.1:

Netstat -na | grep 127.0.0.1

До речі, якщо у вас не налаштований server-status на Apache, то статус цього сервера можна подивитися в CLI:

Apachectl status

лог Файли

Глобальні логи Apache, в Debian, зазвичай знаходяться там:

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

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

Глобальні логи Nginx знаходяться там:

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

Так само не забувайте переглядати логи віртуальних хостів, якщо хости у вас налаштовані. Нас буде цікавити найбільший лог, який «росте» на очах.

Шукати в цих балках потрібно аномалії, а саме однотипні запити без юзер агентів (або з одним і тим же), велика кількість запитів з одного і того ж IP, запити без вказівки віртуального хоста і т.д.

Виявити конкретні IP з числом запитів до сайту можна даною командою:

Cat access.log | awk "(print $ 1)" | sort | uniq -c

Так само можна отримати статистика за запитами з угрупованням по IP за допомогою утиліти logtop.

Для початку встановимо цю утиліту:

Apt-get install git libncurses5-dev uthash-dev gcc # на випадок, якщо у вас не стоять пакети для коректної роботи GIT git clone https://github.com/JulienPalard/logtop.git

І тепер отримаємо статистику:

Tail -f access.log | awk ( "print $ 1; fflush ();") | logtop

Наступна команда допоможе нам виявити популярні user-агенти:

Cat access.log | awk -F \ "" (print $ 6) "| sort | uniq -c | sort -n

Як блокувати?

Так чи інакше у вас повинен стояти iptables. Швидше за все він може бути не налаштований, особливо якщо ви не знаєте що це таке. Раніше я вже писав статтю про те як ним користуватися: «», тому тут я приведу тільки необхідні команди, щоб вирішити проблему тут і зараз.

Ось як можна заблокувати tcp запити на 80 порт з певного IP:

Iptables -A INPUT -p tcp --dport 80 -s 12.34.56.78 -j DROP

так ми блокуємо запити на всі порти з певного IP:

Iptables -A INPUT -s 12.34.56.78 -j DROP

Подивитися список вже заблокованихми можемо даними командами:

Iptables -L -n

Iptables -L -n --line-numbers

Якщо нам потрібно видалити з блокування певний IP, Можна скористатися цією командою

Iptables -D INPUT -s 1.2.3.4 -j DROP

або можна видалити правило по його номеру, Попередньо подивившись його номер командою iptables -L -n -line-numbers:

Iptables -D INPUT 6

Щоб видалити всі правила, Можна скористатися командою:

Iptables -F

Трохи профілактики, з метою захисту від DDos ...

Є ще деякі правила, які зможуть захистити нас від бездумних ботів, створюють навантаження на сервер.

Наступною командою ми встановимо максимальну кількість підключень з однієї IP на 80 порт:

Iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 128 -j DROP iptables -A INPUT -p tcp --dport 80 -j ACCEPT

Теж самеможна зробити і для DNS:

Iptables -A INPUT -p udp --dport 53 -m connlimit --connlimit-above 16 -j DROP iptables -A INPUT -p udp --dport 53 -j ACCEPT

Наступне правило в iptables буде перешкоджати Спуфінга від нашого імені. Як правило, під час ddos ми отримуємо пакет з встановленими прапорами SYN і ACK по ще не відкритого з'єднанню (цією комбінацією прапорів має тільки відповідь на SYN-пакет). Це говорить про те, що хтось послав іншому хосту SYN-пакет від нашого імені, і відповідь прийшла до нас.
за даному правилу, Наш хост відповість RST-пакетом, після отримання якої атакований хост закриє з'єднання.

Iptables -I INPUT -m conntrack --ctstate NEW, INVALID -p tcp --tcp-flags SYN, ACK SYN, ACK -j REJECT --reject-with tcp-reset

Iptables-save> /etc/iptables.rules

Що ще можна зробити?

Ще не завадить трохи «оттюнінговать» ядро, зробити тонке налаштування Apache і Nginx (якщо такий стоїть), поставити додаткові модулі і пакети для захисту від атак, такі як Fail2Ban, mod_evasive, ModSecurity ..

Але все це теми інших статей, які скоро будуть написані ...