Як дізнатися, що на сайт йде DDoS-атака?

DDoS-атака (розподілена атака типу “відмова в обслуговуванні”) – це загроза, яка може завдати серйозної шкоди вашому сайту та бізнесу. Важливо знати ознаки DDoS-атаки, щоб швидко реагувати та мінімізувати втрати. У цій статті ми розглянемо, як дізнатися, що на сайт йде DDoS-атака, які симптоми можуть вказувати на це, а також які дії можна зробити для виявлення та запобігання атакі.

Ознаки DDoS-атаки

Різке збільшення трафіку на сайті

Одна з перших ознак DDoS-атаки – це різке та незрозуміле збільшення трафіку на сайті. Якщо ви помітили підозріле підвищення відвідуваності, можливо, ваш сайт зазнає атаки.

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

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

Тимчасові проблеми з доступом до сайту

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

Як виявити DDoS-атаку

Моніторинг сервера

Систематичне спостереження станом сервера та аналіз логів дозволяє своєчасно виявити підозрілу активність. Можна використовувати спеціалізовані інструменти, такі як Nagios або Zabbix, які повідомляють про проблеми із сервером.

Аналіз трафіку

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

Використання спеціалізованих інструментів

Існують спеціальні інструменти для виявлення та блокування DDoS-атак, такі як Cloudflare, Incapsula або Arbor Networks. Вони можуть виявляти аномальні патерни трафіку та запобігати атакам на ранній стадії.

Як запобігти DDoS-атаці

Створення резервних копій

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

Обмеження кількості з'єднань

Обмежте кількість одночасних з'єднань із сервером для зниження навантаження на нього.

Використання CDN (Content Delivery Network)

CDN дозволяє розподілити навантаження на сайт по кількох серверах у різних географічних точках, що ускладнює проведення DDoS-атаки.

Оновлення програмного забезпечення

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

Впровадження WAF (Web Application Firewall)

WAF є захистом, який блокує підозрілі запити та атаки на рівні додатків, що знижує ризик DDoS-атак.

DDoS-атаки можуть завдати серйозної шкоди вашому сайту та бізнесу, тому важливо знати ознаки та вміти своєчасно реагувати.

Обов'язково моніторуйте стан сервера, аналізуйте трафік та використовуйте спеціалізовані інструменти для виявлення та запобігання атакам.

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

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

Виявлення DDoS-атак «на коліні»

Вітаю, Хабре! Я працюю в невеликому інтернет-провайдері масштабу області. У нас транзитна мережа (це означає, що ми купуємо інтернет у багатих провайдерів та продаємо його бідним).Незважаючи на невелику кількість клієнтів і таку ж невелику кількість трафіку, що протікає по нашій мережі, досить часто доводиться мати справу з вельми значними DDoS-атаками по 10-20Гбіт/с. (найчастіше звичайно це атаки набагато меншого калібру). І хоча деякі з наших клієнтів обзавелися вже системами виявлення таких атак і можуть самостійно відправити жертву в блек-хол, набагато частіше виявлення атаки і бан конкретної IP жертви лягає на наші плечі (тим більше якщо атака здатна забити наші зовнішні канали).

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

Насправді систем для виявлення Ddos-атак заснованих на аналізі даних протоколів NetFlow/SFlow/IPFIX існує досить багато (мабуть майже всі?). У першому наближенні суть усіх таких систем зводиться до встановлення порогів за кількістю пакетів/потоків/октетів на певний тип трафіку до конкретного IP, при перевищенні якого система сигналізує про можливу атаку. І наше рішення нічим від них у цьому плані не відрізняється. Проте, основна проблема – більшість із них платні. А безкоштовні версії пропонують досить грубий аналіз, який часто неефективний (наприклад, дозволяє встановлювати поріг тільки весь трафік до конкретного IP, без його попередньої фільтрації, що у разі аналізу транзитного трафіку майже завжди марно).

Отже, спочатку необхідно налаштувати протокол NetFlow на мережному обладнанні з мінімально можливим active timeout (інтервал з яким експортуються дані з обладнання на колектор) - це 60с для Cisco та Juniper.

Як core-маршрутизатор у нас виступає Juniper MX480, він і буде займатися відправкою телеметрії. Спочатку налаштовуємо семплінг:

forwarding-options < sampling < input < rate 2000; run-length 0; >family inet <output<flow-inactive-timeout 15; flow-active-timeout 60; flow-server 10.0.0.10 < port 9999; autonomous-system-type origin; source-address 10.0.0.1; version 5; >> > > >

• rate та run-length відповідають за семплювання статистики. Для аналізу трафіку береться один із 2000 пакетів. Дані взяті із рекомендацій Juniper для 10G інтерфейсів. (На подив виявив, що зараз не можу знайти цих рекомендацій)
• flow-active-timeout 60; - Вищезазначений інтервал з яким експортуються дні на колектор
• flow-inactive-timeout 15; - інтервал неактивності, після якого потік вважається завершеним.
• autonomous-system-type origin; - Експортувати номер AS джерела (Для нашого завдання не потрібно, але для Traffic Engineering потрібна річ)
• version 5 – тут треба зробити невеликий відступ. Вибір 5-ї версії, а не 9-ї зумовлений двома причинами. По-перше, для роботи 9й версії потрібна додаткова плата в Juniper. По-друге, обраний колектор повинен розуміти 9 версію (спойлер: він не розуміє). Однак для нашого завдання цілком підійде і п'ята версія.

interfaces < ae1 < vlan-id . ; family inet < sampling < input; output; > address . > > >

Далі нам необхідно налаштувати NetFlow колектор, який буде збирати дані статистики з обладнання.

Як колектор вирішено було використовувати багатьом знайомий flow-capture з набору утиліт flow-tools. Саме набір утиліт, який дозволяє будувати різноманітні та докладні звіти на основі зібраної статистики, є головною перевагою цього пакету. (До речі в наборі утиліт також є і flow-dscan для виявлення сканування хостів/портів та іншої небажаної активності). У недоліки можна записати відсутність веб-оболонки та відсутність підтримки 9-ї версії NetFlow. Однак, повторюся, гнучкість таких утиліт як flow-nfilter, flow-report і, звичайно ж, вільне поширення легко все перекривають.

Сервер, на якому працює колектор, у нашому випадку під FreeBSD (звісно, ​​flow-tools доступний і для linux).

# cd /usr/ports/net-mgmt/flow-tools # make install clean

Додаємо в /etc/rc.conf:

flow_capture_enable="YES" flow_capture_localip="10.0.0.10" #локальний ip на який приймається потік flow_capture_remoteip="10.0.0.1" #ip з якого ллється потік flow_capture_port="9999" #порт на який ллється потік flow_cap /flows" #директорія з файлами зібраної телеметрії flow_capture_flags="-z0 -n1439 -N3 -E10G -e0 -S1" #параметри

-z0 - стиснення файлів (0 - вимкнено)
-n1439 – кількість файлів, які створить колектор на добу. За промовчанням 95 – це один файл у 15 хвилин. 1439 – максимальне значення – це один файл на хвилину. Нам необхідно, щоб файли створювалися якнайшвидше.
-N3 – це рівень вкладеності файлів та папок (YYYY/YYYY-MM/YYYY-MM-DD/flow-file)
-E10G – обмеження на простір на диску. Видалятиме старі файли таким чином, щоб загальний обсяг файлів з телеметрією був меншим від цього числа. Дуже корисна штука, шкода не підчищає створені директорії.
-e0 - теж тільки про кількість файлів (0 - не стежити)
-S1 – логувати щохвилини повідомлення про отримані/втрачені/оброблені потоки

З усього набору утиліт flow-tools нас цікавитимуть три:

Flow-nfilter – дозволяє фільтрувати статистику за такими параметрами як ip адреса/протокол/порт. Нам вона потрібна для своєрідного білого списку IP, які потрібно виключити з перевірки. Наприклад, ip-адреси гугл-кеш серверів у вашій мережі (або будь-яких інших кешів), де досить високий потік трафіку може помилково сигналізувати про ддос-атаку. Створимо файл filters.cfg з фільтром (ip-адреси для прикладу):

filtr-primitive white-list-ip type ip-address-prefix deny 8.8.8.8 deny 64.233.160.0/19 default permit filtr-definition white-list match ip-destination-address white-list-ip match ip-source-address white -list-ip

ip-destination-address/ip-source/destination-port - Угруповання потоків, як не складно здогадатися, за ip-destination адресою, source/dest порту. Це означає, що будуть об'єднані всі потоки з однаковими ip-destination-address & ip-source & destination-port і представлені у звіті у відсортованому порядку, наприклад, по потоках або пакетах (якщо звичайно це сортування задати). Такі звіт дозволить виявити так звані DDoS-атаки з відображенням на який-небудь сервіс. Наприклад, якщо зафіксовано аномально велику кількість потоків з порту 53 на порт 80 якого-небудь хоста, можна говорити про можливу атаку. Це зручно, тому що в більшості випадків такого роду потоків небагато, і при правильно налаштованому порозі можна виявити атаку навіть із мінімальним результуючим трафіком. Для того, щоб задати звіт, потрібно створити файл з його описом. Створимо файл reports.cfg:

stat-report sdport_flows type ip-destination-address/ip-source/destination-port output формат ascii options -header,-xheader,-totals,-names fields +flows,-octets,-packets,-duration sort +flows stat- definition sdport_flows report sdport_flows

stat-report dport_packets тип ip-destination-address/ip-destination-port output формат ascii options -header,-xheader,-totals,-names fields -flows,-octets,+packets,-duration sort +packets stat-definition dport_packets report dport_packets

stat-report flows type ip-destination-address output format ascii options -header,-xheader,-totals,-names fields +flows,-octets,-packets,-duration sort +flows stat-definition flows report flows stat-report packets type ip-destination-address output format ascii options -header,-xheader,-totals,-names fields -flows,-octets,+packets,-duration sort +packets stat-definition packets report packets

Код скрипту я наводити не буду, він з файлами filters.cfg та reports.сfg доступний на GitHub

Для його роботи достатньо налаштувати деякі параметри у config.ini. І додати його в крон на виконання кожної хвилини.

Зокрема, встановити пороги для звітів залежно від інтенсивності трафіку у вашій мережі, а також від налаштувань семплінгу NetFlow на мережному обладнанні.

[REPORTS] sdport_flows dport_packets flows packets # Reports(rules) options # threshold - threshold value # key_field - report field index number to which the threshold applies # filter - name of filter described in FiltersFileName [ key_field = 4 filter = white-list [dport_packets] threshold = 3000 key_field = 3 filter = white-list [flows] threshold = 2000 key_field = 2 filter = white-list [packets] threshold = 5000 key_field = 2 filter

• threshold — граничне значення, IP адреси у звіті з кількістю потоків/пакетів, що перевищують це значення, вважаються атакованими.
• key_field - індекс поля у виведенні звіту (починаючи з 1), до якого застосовується поріг.
• filter — ім'я фільтра, що застосовується до даних статистики, до групування даних звітом flow-report.

[FILES] # Dir with flow-tools binary files FlowToolsBinDir = /usr/local/bin/ # Dir with Whois, AWK binary files SysBinDir = /usr/bin/ FlowsDir = /var/db/flows/ ReportsFileName = reports.cfg = filters.cfg [EMAIL] SMTPServer = localhost # 0-default port SMTPPort = 0 MailFrom = [email protected] MailTo = [email protected] Subject = [DDoS Detect] # Amount flow-print records in email FlowPrintTail = 50 # Use TLS (if True , Auth must be the same) Secure = False # Use Login and Password Auth = False # Notification Frequency about current DDoS attack - every value minutes # if 0 - don't send email, print victims ip to stdout NotifyFreq = 5 # Act if Auth = True [EMAIL-AUTH] Login = . Password = .

Лист із повідомленням про атаку виглядає так:

Скрипт дозволяє додавати/прибирати свої звіти, за якими буде відбуватися аналіз трафіку, задавати для кожного звіту свій фільтр із файлу filters.cfg, змінювати частоту повідомлень для поточної DDoS-атаки.Дозволяє також вивести список атакованих IP на stdout, не надсилаючи листа.

Ось, власне, і все. Дякую за увагу!