Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Твій ранок починається з читання багрепортів і аналізу логів. Ти щодня оновлюєш ПЗ і щогодини допрацьовуєш правила брандмаузера. Snort твій кращий друг, а Zabbix - невидимий помічник. Ти побудував справжній бастіон, до якого не підібратися ні з одного боку. Але! Ти абсолютно беззахисний проти найпідступнішої і підлої атаки на світі – DDoS.
Важко сказати, коли вперше з'явився термін DoS-атака. Фахівці говорять про 1996 рік, попутно натякаючи, що до широких мас цей тип атак "дійшов" лише в 1999 році, коли один за іншим попадали web-сайти Amazon, Yahoo, CNN і eBay. Ще раніше DoS-ефект використовували для тестування стійкості систем і каналів зв'язку. А якщо копнути глибше і скористатися терміном DOS для позначення явища, то стає ясно, що він існував завжди, з часів перших мейнфреймів. Ось тільки замислюватися про нього як про засіб залякування почали набагато пізніше.
Кажучи звичною мовою, DoS-атаки - це деякий вид зловмисної діяльності, що ставить своєю за мету довести комп'ютерну систему до такого стану, коли вона не зможе обслуговувати правомірних користувачів або правильно виконувати покладені на неї функції. До стану "відмова в обслуговуванні" зазвичай приводять помилки в ПЗ або надмірне навантаження на мережевий канал або систему в цілому. Внаслідок чого ПЗ, або вся операційна система машини, "падає" або ж опиняється в "зацикленому" стані. А це загрожує простоями, втратою відвідувачів/клієнтів і збитками.
DoS-атаки поділяються на локальні і віддаленні. До локальних відносяться різні експлойти, форк-бомби і програми, що відкривають по мільйону файлів або запускають якийсь циклічний алгоритм, який зжирає пам'ять і процесорні ресурси. На всьому цьому ми зупинятися не будемо. А ось віддалені DoS-атаки розглянемо детальніше. Вони діляться на два види:
У традиційного виконання (один атакуючий - одна жертва) зараз залишається ефективним лише перший вигляд атак. Класичний флуд даремний. Просто тому що при сьогоднішній ширині каналу серверів, рівні обчислювальних потужностей і повсюдному використанні різних анті-DoS прийомів в ПЗ (наприклад, затримки при багатократному виконанні одних і тих же дій одним клієнтом), що атакує перетворюється на докучливого комара, не здатного завдати якого б то не було збитку. Але якщо цих комарів наберуться сотні, тисячі або навіть сотні тисяч, вони легко покладуть сервер на лопатки. Натовп - страшна сила не лише в житті, але і на комп'ютерному світі. Розподілена атака типа "відмова в обслуговуванні" (DDoS), зазвичай здійснювана за допомогою безлічі зомбіфіціруваних хостів, може відрізувати від зовнішнього світу навіть найстійкіший сервер, і єдиний ефективний захист - організація розподіленої системи серверів (але це по кишені далеко не всім).
Небезпека більшості DDoS-атак – в їх абсолютній прозорості і "нормальності". Адже якщо помилка в ПЗ завжди може бути виправлена, то повне зжирання ресурсів - явище майже буденне. З ними стикаються багато адміністраторів, коли ресурсів машини (ширина каналу) стає недостатньо, або web-сайт піддається слешдот-ефекту. І якщо різати трафік і ресурси для всіх підряд, то врятуєшся від DDoS, но втратиш велику половину клієнтів.
Виходу з цієї ситуації фактично немає, проте наслідки DDoS-атак і їх ефективність можна істотно понизити за рахунок правильного налаштування маршрутизатора, брандмаузера і постійного аналізу аномалій в мережевому трафіку. У наступній частині статті ми послідовно розглянемо:
В самому кінці буде дана відповідь на питання: що робити, коли почалася DDoS-атака.
Отже, існує два типи DoS/DDoS-атак, і найбільш поширена з них заснована на ідеї флуда, тобто завалення жертви величезною кількістю пакетів. Флуд буває різним: Icmp-флуд, Syn-флуд, Udp-флуд і Http-флуд. Сучасні DoS-боти можуть використовувати всі ці види атак одночасно, тому слід заздалегідь поклопотатися про адекватний захист від кожної з них.
Дуже примітивний метод забивання смуги пропускання і створення навантажень на мережевий стек через монотонну посилку запитів ICMP ECHO (пінг). Легко виявляється за допомогою аналізу потоків трафіку в обидві сторони: під час атаки типа Icmp-флуд вони практично ідентичні. Майже безболісний спосіб абсолютного захисту заснований на відключенні відповідей на запити ICMP ECHO:
# sysctl net.ipv4.icmp_echo_ignore_all=1
Або за допомогою брандмаузера:
# iptables -A INPUT -p icmp -j DROP --icmp-type 8
2. SYN-флуд.
Один з поширених способів не лише забити канал зв'язку, але і ввести мережевий стек операційної системи в такий стан, коли він вже не зможе приймати нові запити на підключення. Заснований на спробі ініціалізації великого числа одночасних TCP-з'єднань через посилку SYN-пакету з неіснуючою зворотньою адресою. Після декількох спроб відіслати у відповідь ack-пакет на недоступну адресу більшість операційок ставлять невстановлене з'єднання в чергу. І лише після n-ої спроби закривають з'єднання. Оскільки потік ack-пакетів дуже великий, незабаром черга виявляється заповненою, і ядро дає відмову на спроби відкрити нове з'єднання. Найбільш розумні DoS-боти ще і аналізують систему перед початком атаки, щоб слати запити лише на відкриті життєво важливі порти. Ідентифікувати таку атаку просто: досить спробувати підключитися до одного з сервісів. Оборонні заходи зазвичай включають:
Збільшення черги "напіввідкритих" tcp-з'єднань:
# sysctl -w net.ipv4.tcp_max_syn_backlog=1024
Зменшення часу утримання "напіввідкритих" з'єднань:
# sysctl -w net.ipv4.tcp_synack_retries=1
Включення механізму TCP syncookies:
# sysctl -w net.ipv4.tcp_syncookies=1
Обмеження максимального числа "напіввідкритих" з'єднань з одного IP до конкретного порту:
# iptables -i INPUT -p tcp --syn --dport 80 -m iplimit --iplimit-above 10 -j DROP
Типовий метод захаращення смуги пропускання. Заснований на безконечній посилці udp-пакетів на порти різних udp-сервісів. Легко усувається за рахунок відрізання таких сервісів від зовнішнього світу і установки ліміту на кількість з'єднань в одиницю часу до dns-сервера на стороні шлюзу:
# iptables -i INPUT -p udp --dport 53 -j DROP -m iplimit --iplimit-above 1
Один з найпоширеніших на сьогоднішній день способів флуда. Заснований на безконечній посилці http-повідомлень GET на 80-й порт з метою завантажити web-сервер настільки, щоб він виявився не в змозі обробляти всі останні запити. Часто метою флуда стає не корінь web-сервера, а один із скриптів, що виконують ресурсоємні завдання або що працює з базою даних. У будь-якому випадку, індикатором атаки, що почалася, служитиме аномально швидке зростання лігв web-сервера.
Методи боротьби з Http-флудом включають тюнинг web-сервера і бази даних з метою понизити ефект від атаки, а також відсіювання DoS-ботів за допомогою різних прийомів. По-перше, слід збільшити максимальне число з’єднань до бази даних одночасно. По-друге, встановити перед web-сервером Apache легкий і продуктивний nginx – він кешуватиме запити і видавати статику. Це рішення із списку "Must have", яке не лише понизить ефект DoS-атак, але і дозволить серверу витримати величезні нагрузки. Невеликий приклад:
# vi /etc/nginx/nginx.conf
# Збільшує максимальну кількість використовуваних файлів worker_rlimit_nofile 80000;
events {
# Збільшує максимальну кількість з’єднань
worker_connections 65536;
# Використовувати ефективний метод метод epoll для обробки з’єднань
use epoll;
}
http {
gzip off;
# Відключаеєм таймаут на закриття keep-alive з’єднань
keepalive_timeout 0;
# Не віддавати версію nginx в заголовку відповіді
server_tokens off;
# Зкидати з’єднання по таймауту
reset_timedout_connection on;
}
# Стандартні настройки для роботи в якості проксі
server {
listen 111.111.111.111 default deferred;
server_name host.com www.host.com;
log_format IP $remote_addr;
location / {
proxy_pass http://127.0.0.1/;
}
location ~* \.(jpeg|jpg|gif|png|css|js|pdf|txt|tar)$ {
root /home/www/host.com/httpdocs;
}
}
У разі потреби можна задіювати nginx-модуль ngx_http_limit_req_module, що обмежує кількість одночасних підключень з однієї адреси (http://sysoev.ru/nginx/docs/http/ngx_http_limit_req_module.html). Ресурсоємні скрипти можна захистити від ботів за допомогою затримок, кнопок "Натискуй мене", виставляння кукисів і інших прийомів, направлених на перевірку "людяності".
Застосування кластера для вирішення проблеми атак
на відмову
Рішення прийшло само-собою - у нас в том-же ДЦ що і веб-сервер-сервер коштують ще і файлові сервера, в яких дуже навантажені гвинти, але проц і пам'ять практично гуляє. Серед таких серверів знайшовся двохядерний оптерон з 4Гб оператіви, вирішили сайт перенести туди. Щоб не міняти запису в ДНС, не юзати забиті канали, які служать для роздачі файлів і т.д. ми зробили наступне: оптерон був налагоджений для праці backend сервером, на основному сервері в конфіге nginx прописали для домена fileshare.in.ua цей backend, а останні сайти (їх на тому сервері всього біля десятка, окрім файлшари, сумарною відвідуваністю порядку 15К хостів і 70К хітів в добу) залишити як є.
Рішення допомогло на якийсь час, сайт став нормально працювати і інші сайти теж пожвавіше стали відгукуватися. Десь через годин 6 після такого ось нововведення атака посилилася у декілька разів. Оптерон не витримав, файлшара знову просіла, проте останні сайти, які працювали не на оптероне, а на основному веб-сервері-сервері відмінно відгукувалися.
Цього разу я вирішив що файлшара важливіше і зробив кластер: файлшара працювала на обох серверах, балансування робив nginx, а останні сайти крутилися на основному. При чому для файлшари веб-сервер-сервер був прописаний як резервний (тобто на основному сервері скрипти файлшари виконувалися лише якщо оптерон помер), і, щоб довго не чекати, я встановив параметр чекання відповіді від backend 2 секунди. Все налагодилося, отперон не завжди витримував, був постійно завантажений на 100%, але другий сервер підхоплював сайт якщо оптерон падав і все більш-менш працювало.
Мабуть зловмисники стежили за розвитком подій тому, що буквально за годину, після того, як я розвів навантаження з файлшари на 2 сервери на атаку були кинута велика частина ресурсів. Вхідний трафік підріс в 3 рази в порівнянні із звичайним (далі йому просто вже нікуди зростати із-за обмежень провайдера), сайт впав і не піднімався, завантаження сервера (будь-якого) було на 100% вже відразу після рестарту апача, a на основному сервері підскочив до 60%, все було в ступорі небуло жодних шансів піднятися. Атака йшла не лише на файлшару але і останні сайти, навіть по ssh зайти було проблемою (не дивлячись на підвищений пріоритет) і я загасив nginx, щоб мати можливість щось зробити. Мабуть по маштабам атака була порівнянна з тими, від яких лежав 0day і progs не так давно. Не знаю вже кому ми так жити заважаємо, але думати про цей небуло часу, через 20 хвилин атака була повністю відбита;). Насамперед я додав в кластер ще 3 машини. По-друге залив на всі машини по nfs ісходники сайтів, подрехтовал конфіги апача і php і перевів сесію на mysql. Тепер всі сервера могли працювати як backend’и. Після цього я поставив на все сервера APC (php-акселератор), перевірив працездатність сайтів на кожному з серверів, прописав їх в конфіге nginx і знову його запустив. Атака, яка легко посадила 2 сервери, цього разу спасувала. Вхідний трафік не зменшився, атака йшла до ранку, але всім сайтам на хостингу це вже було по барабану. Навіть ab в 200 потоків, який я запустив паралельно з атакою нічого не змінив. Я боявся за базу - вона хоч і на потужній машині, але на одній, проте, мабуть за рахунок агресивного кешированія, база впоралася. А на веб-сервері-сервері опустився до 3, на сервері з'явився idle і тут-же взявся за справу антидос-скрипт. Запити валили шквалом, проте антидос знаходила час їх аналізувати і забанити найактивніших, тим самим понизивши навантаження десь на 40%. Підсумок: під час атаки сервера були завантажені не більше ніж на 60% (багато ресурсів віджирала роздача файлів), всі сайти (навіть на Вордпресі) відгукувалися швидко, атака йшла лісом. Сьогодні півдня довелося витратити на пошук багов, які з'явилися у зв'язку з такою зміною архітектури, проте в цілому результат хороший. Сподіватимемося, що сайт тепер захищений від ДДОС повністю. Чому повністю? тому що в ua-ix не буде достатньої кількості комп'ютерів, щоб його покласти, а ширина вхідного світу така, що сама стримає великий наплив ботів. Максимум, чого можна буде добитися, так це того, що сайт не буде доступний зі світу, проте і для цього треба буде сильно постаратися.
Принаймні це мій оптимістичний прогноз, думаю, що організатори атак не зупиняться на досягнутому і сайт ще не раз перевірять на міцність (та в і нас є ще гуляючі сервера+можно зібрати mysql кластер), проте те що якась кількість грошей вони вже спустили в унітаз (10 годин безрезультатної досить масованої атаки), це радує.
UDP та торенти
Очима фахівця, суть того, що відбувається така: з кінця січня (стабільна µTorrent версія 2.0 з µTP вийшла якраз 25 січня, офіційно доступна з 3 лютого) в статистичних звітах операторів зв'язку виявлено безперервне зростання UDP-трафіку і одночасне зменшення середньої величини пакетів, які істотно збільшували навантаження на мережеве устаткування. Спостереження показали, що чим сильніше завантажений канал клієнта, тим дрібніші пакети, довша черга і вище навантаження на роутерах.
У всіх випадках причиною що відбувається був названий МікроТоррент (µTorrent), з версії 1.8.1 що почав освоювати протокол обміну µTP (Micro Transport Protocol, до речі, що так не дістав схвалення IETF). І провайдерам просто повезло, що через низку обставин клієнти до версії µTorrent v2.0 не оновилися одномоментно. (У ній, за умовчанням, udp-завантаження стартує першим, а якщо не вийде, то лише тоді – по TCP). Інакше наростання проблем в мережі замість плавного носило б миттєвий характер і, можливо, відразу «повалило» до третини вітчизняних провайдерів. Останні могли б трактувати поведінку як ddos-атаки на провайдерське устаткування з відповідним недемократичним «закручуванням гайок» в аварійному порядку.
Остаточний аналіз ситуації був ускладнений тим, що у відкритому доступі повного опису протоколу, який став займати значну долю UDP трафіку, немає: цей опис застарілий і не дає повної картини, а стаття у Вікіпедії досить поверхневий описує характер проблем.
Реінженеринг дозволив не лише переконатися, що згідно з алгоритмами µTP в процесі обміну зменшується довжина пакету із зростанням завантаження каналу, але і передбачити, що для підтвердження використовуються udp-пакети квитування (з функцією, типа ACK) розміром в 2 десятки байт.
Логіка розробників протоколу і алгоритмів µTorrent може виправдовуватися тим, що вони не вважають розумними чекати TCP-ACK від доставки пакету. Адже tcp-потік формується послідовно, і якщо в стеку, наприклад, вже знаходиться 50 пакетів, але немає два, то передачу вони не здійснюватимуть, поки втрачені не прийдуть. А ось пірінгове застосування за своєю суттю якраз і не критично до строгої послідовності у вступі інформації, адже воно запрошує і збирає файли по шматочках.
І що виходить насправді? Додаток, відповідно, зменшує розмір пакету, тому що у нього зростає час між відсиланням пакету і приходом квитанції. Але зростає-то воно тому, що пакети стоять в переповненій черзі на «шейпері». І замість того що б спочатку зменшити кількість посланих, алгоритм . .. далі зменшує їх розмір. В результаті, при даному агресивному алгоритмі використання udp-протоколу МікроТоррентом результуючий трафік (ємкість каналу) на клієнтові практично не міняється. Тобто вихідна мрія творців даного ПЗ – завантажити канал «під зав'язку» від цього ближче не стає. Міняється лише структура трафіку – з'являється більше дрібних пакетів, що для провайдера насправді небезпечніше чим зростання трафіку.
Давайте порахуємо: якщо в ходу пакети по 150 байт, то при швидкості 100 мегабіт операторові потрібно буде обробити в секунду ... 87 тисяч пакетів! Не всякий провайдер зможе оперативно відреагувати на виниклу проблему: замінити ті ж сервери доступа/роутери на високопродуктивних не всім по кишені. В результаті, багато провайдерів вимушено було для своїх клієнтів ввести на додаток до обмежень по Mbps, ще і по pps.
Але, навіть якщо провайдерське устаткування зможе впоратися з цим алогічним алгоритмом обміну, замість вичавлених з провайдера декількох зайвих відсотків смуги, клієнт ризикує втратити значно більше завдяки збільшеному пакетному навантаженню . на свій домашній шлюз і, можливо навіть – на свій не дуже сучасний ПК! А що він зробить, побачивши, що швидкість закачування знизилася? Правильно, без тіні сумніву звернеться в технічну підтримку і звалить свої проблеми на провайдера.
Оскільки локальна ситуація моделюється досить нескладно, я провів невеликий експеримент з наявним adsl-wifi-шлюзом, який можу запропонувати просунутим користувачам µTorrenta. Особливо вражаючим тест виглядатиме на древніх роутерах з Wifi. У моєму циклі випробувань пристрій почав «притормажувати» приблизно вже при 30-40 активних сесіях «звичайного» закачування, але при агресивній роботі по UDP (всього 5 роздач) втратило відразу майже третина смуги. Поза сумнівом, причина – в перевищення можливої кількості коректно оброблюваних пакетів за одиницю часу.
Щоб не попасти в безвихідь під час обвалення DDoS-штурму на системи, необхідно ретельно підготувати їх до такої ситуації:
Додай в /etc/sysctl.conf наступні рядки:
# vi /etc/sysctl.conf
# Захист від спуфінга
net.ipv4.conf.default.rp_filter = 1
# Перевіряти TCP-з’єднання кожну хвилину. Якщо на іншій стороні - легальна машина, вона зразу відповість. Значення по замовчуванні - 2 години.
net.ipv4.tcp_keepalive_time = 60
# Повторити попитку через десять секунд
net.ipv4.tcp_keepalive_intvl = 10
# Кількість повірок перед закриттям з’єднання
net.ipv4.tcp_keepalive_probes = 5
Слід зазначити, що всі прийоми, приведені у минулому і цьому розділах, направлені на зниження ефективності DDoS-атак, що ставлять своєю метою витратити ресурси машини. Від флуда, що забиває канал сміттям, захиститися практично неможливо, і єдино правильний, але не завжди здійсненний спосіб боротьби полягає в тому, щоб "позбавити атаку сенсу". Якщо ти отримаєш в своє розпорядження дійсно широкий канал, який легко пропустить трафік невеликого ботнета, вважай, що від 90% атак твій сервер захищений. Є витонченіший спосіб захисту. Він заснований на організації розподіленої обчислювальної мережі, що включає безліч дублюючих серверів, які підключені до різних магістральних каналів. Коли обчислювальні потужності або пропускна спроможність каналу закінчуються, все нові клієнти перенаправляються на інший сервер (або ж поступово "розмазуються" по серверах за принципом round-robin). Це неймовірно дорога, але дуже стійка структура, завалити яку практично нереально.
Інше більш-менш ефективне рішення полягає в покупці дорогих хардварних систем Cisco Traffic Anomaly Detector і Cisco Guard. Працюючи у в'язці, вони можуть подавити атаку, що починається, але, як і більшість інших рішень, заснованих на вченні і аналізі станів, дають збої. Тому слід гарненько подумати перед тим, як вибивати з начальства десятки тисячі доларів на такий захист.
Перед безпосереднім початком атаки боти "розігріваються", поступово нарощуючи потік пакетів на машину, що атакується. Важливо зловити момент і почати активні дії. Допоможе в цьому постійне спостереження за маршрутизатором, підключеним до зовнішньої мережі (аналіз графіків Netflow). На сервері-жертві визначити початок атаки можна підручними засобами.
Наявність Syn-флуда встановлюється легко - через підрахунок числа "напіввідкритих" tcp-з'єднань:
# netstat -na | grep ":80\ " | grep Syn_rcvd
У звичайній ситуації їх не повинно бути зовсім (або дуже невелика кількість: максимум 1-3). Якщо це не так - ти атакований, терміново переходь.
З Http-флудом дещо складніше. Спершу потрібний підрахувати кількість процесів Apache і кількість з’єднань на 80-й порт (Http-флуд):
# ps aux | grep httpd | wc -l
# netstat -na | grep ":80\ " | wc –l
Значення, у декілька разів вищі за середньостатистичні, дають підстави задуматися. Далі слід проглянути список ip-адрес, з яких йдуть запити на підключення:
# netstat -na | grep ":80\ " | sort | uniq -c | sort -nr | less
Однозначно ідентифікувати DoS-атаку не можна, можна лише підтвердити свої припущення про наявність такої, якщо одна адреса повторюється в списку надто багато разів. Додатковим підтвердженням буде аналіз пакетів за допомогою tcpdump:
# tcpdump -n -i eth0 -s 0 -w output.txt dst port 80 and host ip-сервера
Показником служить великий потік одноманітних (і що не містять корисної інформації) пакетів від різних IP, направлених на один порт/сервіс (наприклад, корінь web-сервера або певний cgi-скріпт). Остаточно визначившись, починаємо банити по ip-адресах (буде значно більше ефекту, якщо ти зробиш це на маршрутизаторі):
# iptables -A INPUT -s xxx.xxx.xxx.xxx -p tcp --destination-port http -j DROP
Або відразу по підмережах:
# iptables -a INPUT -s xxx.xxx.0.0/16 -p tcp --destination-port http -j DROP
Це дасть тобі деяку фору, яку ти повинен використовувати для того, щоб звернутися до провайдеру/хостеру (з прикладеними до повідомлення балками web-сервера, ядра, брандмаузера і списком виявлених тобою ip-адрес). Більшість з них, звичайно, проігнорують це повідомлення (а хостинги з оплатою трафіку ще і порадіють - DoS-атака принесе їм прибуток) або просто відключать твій сервер. Але у будь-якому випадку це слід зробити обов'язково, – ефективний захист від DDoS можливий лише на магістральних каналах. Поодинці ти впораєшся з дрібними нападками, направленими на виснаження ресурсів сервера, але виявишся беззахисним перед більш-менш серйозним DDoS’ом.
Зменшуємо час чекання у відповідь пакету на запит SYN-ACK (захист від Syn-флуда):
# sysctl net.inet.tcp.msl=7500
Перетворюємо сервер на чорну діру. Так ядро не слатиме у відповідь пакети при спробі підключитися до незайнятих портів (знижує навантаження на машину під час DDoS’а на випадкові порти):
# sysctl net.inet.tcp.blackhole=2
# sysctl net.inet.udp.blackhole=1
Обмежуємо число відповідей на icmp-повідомлення 50 в секунду (захист від Icmp-флуда):
# sysctl net.inet.icmp.icmplim=50
Збільшуємо максимальну кількість підключень до сервера (захист від всіх видів DDoS):
# sysctl kern.ipc.somaxconn=32768
Включаємо Device_polling - самостійний опит мережевого драйвера ядром на високих навантаженнях (істотно знижує навантаження на систему під час DDoS'а):
За часів свого розквіту DoS-атаки були справжньою катастрофою для серверів і звичайних робочих станцій. Web-сайт можна було легко завалити за допомогою одного-єдиного хоста, що реалізовує атаку типа Smurf. Робочі станції зі встановленою ОС Windows падали, як доміношки, від атак типа Ping of Death, Land, Winnuke. Сьогодні всього цього не варто опасатися.
1997 рік - dDoS-атака на web-сайт Microsoft. Один день мовчання.
1999 рік – "поза зоною дії" виявилися web-сайти Yahoo, CNN, ebay і ін.
Жовтень 2002 - атака на кореневі dns-сервері інтернету. На деякий час були виведені з буд 7 з 13 серверів.
21 лютого 2003 року - dDoS-напад на Livejournal.com. Два дні сервіс знаходився в паралізованому стані, лише інколи подаючи ознаки життя.
Цікаву альтернативу вирішенням Cisco випускає компанія Reactive Networks (www.reactivenetworks.com). Їх продукт під назвою Floodguard є апаратним комплексом, що складається з детекторів і виконавчих модулів. Детектори, встановлені на брандмаузерах, маршрутизаторах і світчах, постійно моніторят трафік і створюють його профіль на основі таких параметрів, як об'єм пакетів, джерело, напрям, тип і так далі. В разі виникнення аномалій детектор посилає всі подробиці про подію виконавчим модулям, розташованим на маршрутизаторах в різних сегментах мережі. Отримавши повідомлення від детектора, виконавчі модулі починають діяти: вони відшукують паразитний трафік в проходящих пакетах і, в разі успіху, оповіщають про це попередні по ходу трафіку модулі і посилають їм інструкції по активації фільтрів на маршрутизаторах. В результаті, перед потоком флуд-трафіку повинен утворитися заслін, який буде швидко переміщати його в сторону істотника.
Список використаних джерел:
Контрольні питання до теми: