Особливості відображення DDoS атак і історія атаки на один великий банк



Раніше DDoS-атаки могли успішно відбиватися на стороні ЦОДа атакованої компанії. Швидкі розумні дії адміна і хороше фільтруюче залізо гарантували достатній захист від атак. Сьогодні послуги ботнетів стрімко дешевшають, і DDoS стає доступний мало не в малому бізнесі.

Близько половини атак йдуть на інтернет-магазини або комерційні сайти компаній в дусі «завалити " конкурента», майже завжди атакують сайти ЗМІ, особливо після «гарячих» публікацій, набагато частіше, ніж здається, б'ють по госсервисам. У Росії головні цілі — банки, роздріб, ЗМІ та тендерні майданчики. Один з великих російських банків, наприклад, періодично блокує трафік з Китаю — атаки звідти приходять з завидною регулярністю, одна з останніх була більше 100 Гб/с.

Відповідно, коли атака перевалює, скажімо, за 10 Гб/с, відображати її на своїй стороні стає проблематично через банальне забивання каналу. Саме в цей момент потрібно робити переключення на центр очищення даних, щоб весь «поганий» трафік отсеивался ще десь близько магістральних каналів, а не йшов до вас. Зараз розповім, як це працює в одного з наших вендорів захисних засобів — Arbor, мониторящего близько 90 Тбіт/сек (45% світового трафіку Інтернету).

Сценарій атаки

Спочатку зловмисник вибирає цілі всередині інфраструктури. Велика частина «дурних» атак йде на HTTP, дуже багато атак на DNS, але основні «розумні» атаки зазвичай спрямовані на заздалегідь розвідані вузли усередині інфраструктури мети. Нерідко DDoS ставить метою не тільки і не стільки відмова сервісів, скільки можливість пронести «під загальний галас» через DMZ більш серйозну загрозу. Це нерідко досягається з допомогою «перевантаження» систем периметровой захисту, такі як міжмережеві екрани, IPS/IDS і їм подібних, заснованих на відстеженні сесій (stateful inspection). Тому колеги вважають, що якщо у пристрої є таблиця станів (session table) — його слід розглядати як частину інфраструктури, яка потребує захисту.

Основні точки атак:


Схема відбиття атаки реалізується наступним чином:
  1. На стороні захищається компанії коштує пристрій, «закриває» мережу. Як тільки починається атака, пристрій має пізнати її як аномалію, використовуючи одну з механік, наприклад, вбудовані противомеры, ненормальна поведінка джерела трафіка або відповідність відомому профілю атаки (сигнатурі з бази).
  2. Якщо пристрій справляється з атакою, робота триває у відносно штатному режимі: легітимний трафік пропускається, нелегітимний — ріжеться. Є кілька «рівнів тривоги», що відрізняються ступенем складності атаки і можливими втратами легітимного трафіку.
  3. Якщо канал зв'язку починає забиватися, то виконується автоматичне перенаправлення трафіку за допомогою штатного протоколу Cloud Signalling. Спочатку все приходить на майданчик великого провайдера (це може бути Ростелеком, Orange, Транстелеком, Акадо), де дані чистяться обладнанням Peakflow SP. Вже очищений трафік йде на кінцевого клієнта. При цьому клієнт має розуміння всього, що відбувається, може оперативно зайти в особистий кабінет оператора зв'язку і подивитися поточний статус очищення, які працюють противомеры, яка ефективність придушення атак і так далі. Клієнтський пристрій також показує ефективність відбувається в даний момент очищення і список заблокованих хостів. З обох пристроїв при бажанні можна легко зняти дамп трафіку в форматі pcap для подальшого «розбору польотів».




Реальність, про яку не прийнято говорити

1. Втрати легітимного трафіку.
Боротьба з DDOS атакою — це відкидання нелегітимних пакетів і пропуск легітимного трафіку, між якими часом проходить дуже тонка грань. Багато вендори у своїх проспектах люблять писати, що ці втрати близькі до нуля. У моїй практиці вони цілком можуть доходити до 2% — це означає, що теоретично той же директор, який виїхав у відрядження, не зможе потрапити в корпоративну мережу з готелю або з конференції. Тут дуже важливо, щоб система підтримувала можливість вирішити конкретні з'єднання або протоколи «на льоту». У ряду вендорів з моменту початку атаки налаштування, фактично, мало хардкодятся в прошивку заліза, і міняти їх проблематично. У Арбора з цим все виглядає зовсім інакше. По-перше, для управління рівнем false positive є три «режиму тривоги» — від «рубі все, що точно не наше» до «є можливість покопатися детальніше». По-друге, є зручний пошук за заблокованим хостам і можливість скасувати блокування трафіку для конкретного хоста, протоколу або країни в один клік. Зазначимо, що реальність наявності false positive при боротьбі з DDoS визнають всі помітні гравці ринку. Олександр Лямін (Qrator) якось зазначив: «кожен, хто скаже, що false positive у нього нуль, — шарлатан».

2. Можливість використання забитого каналу зв'язку для сигналізації про атаку.
Як же клієнт попросить провайдера про атаку, якщо канал між ними забитий через DDoS? Строго кажучи, навіть при близькій до 100% утилізації каналу зв'язку в напрямку від провайдера до клієнта є дуже великий шанс, що запит на очищення даних дійде до провайдера. Для цього Cloud Signaling працює поверх UDP, а крім того, протокол не вимагає отримання відповіді від провайдера. Таким чином, достатньо мати хоча б трохи ємності в напрямку від клієнта до оператора. Для перестраховки рекомендується організувати окремий канал для обміну повідомленнями Cloud Signaling. Тим не менш, зазвичай створюється резервний канал, плюс тривога йде при порозі близько 70-80% каналу.

3. Час перемикання на центр очищення даних.
Затримка перенаправлення трафіку на центр очищення провайдера послуг захисту від DDoS атак може зайняти одиниці і навіть десятки хвилин. В основному, це пов'язано з механізмом перенаправлення — на основі записів DNS або анонсів BGP, а також з тим фактом, здійснюється прийняття рішення про перенаправлення в ручному або автоматичному режимі. У будь-якому випадку, якщо придушення атаки здійснюється в «хмарі», то уникнути затримки не вдасться. Як мінімум, вона становить кілька хвилин. Тому ми дотримуємося концепції багаторівневого захисту, коли великі атаки на канали зв'язку придушуються оператором, а повільні, малопомітні атаки рівня додатків — обладнанням, встановленим у замовника.

4. Використання SSL-сертифікатів.
Аналізувати трафік SSL/TLS на предмет атак рівня додатків досить проблематично — потрібно розшифровувати кожен пакет. Тут ви опиняєтеся перед непростою дилемою: або ділитися своїми сертифікатами з провайдером послуг, або приймати ризик того, що атака на рівні HTTPS може бути пропущена. Вендори пробують знаходити рішення без розпечатування пакетів (що виходить не завжди добре), або використовують спеціальний модуль дешифрування SSL/TLS трафіку, вбудований в клієнтський пристрій:



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

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

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

У другому випадку працює принцип «спасіння потопаючих — справа рук самих потопаючих», ну або їх партнерів. Тут критично важливим стає функціонал обладнання, що дозволяє швидко визначити, перехопити і проаналізувати шкідливий трафік. А можливість автоматично сформувати сигнатуру на основі отриманої інформації стає порятунком у критичній ситуації. Приміром, можливість зайти до захоплення пакетів, виділити потрібну бітову послідовність (bit pattern), і в пару кліків зробити сигнатуру, яка блокує таку послідовність.

Перевага масштабу

У Arbor є дуже цікава «фішка», яка дозволяє їм дуже ефективно використовувати свою ринкову частку. Справа в тому, що їх обладнання коштує у всіх TIER-I операторів зв'язку і провайдерів і у більшості TIER-II операторів.


Позиція Arbor на ринку обладнання захисту від DDoS в сегментах Carrier, Enterprise, Mobile — 65% всього ринку — перша (Infonetics Research за грудень 2013).

Через систему ATLAS проходить інформація близько 90 Тб/с. Як тільки десь з'являються ознаки атаки, пристрої починають передавати по власній мережі зв'язку дані про те, що відбувається, і інформація швидко поширюється по всьому світу. Приміром, якщо «валять» дрібного провайдера, його залізо сигналить за спеціальним протоколом рівнем вище. Якщо вищестоящий оператор має домовленість з нижчестоящим, то сигнатура приймається і поширюється на всі підмережі великого провайдера.


Сенсори (honeypots) системи ATLAS розташовані на основних вузлах глобальної мережі Інтернет для виявлення і класифікації атак, активності бот мереж і різного шкідливого софту. Інформація відправляється в ЦОД ATLAS, де об'єднується з даними отриманими від інсталяція Arbor Peakflow та іншими даними. Система аналізує в автоматичному режимі сотні тисяч елементів коду, і дозволяє команді інженерів оперативно оновлювати сигнатури для клієнтів компанії по всьому світу.

Особливості підключення

Варто сказати ще пару слів про залізо, яке ставиться безпосередньо до вас в ЦОД або на майданчик. З ним теж пов'язано багато реалій, про які не завжди говорять.

1. Налаштування та конфігурування.
Як правило, пристрою потрібно час на профілювання трафіка і оцінку поведінки мережі. Але деякі пристрої поставляються в «бойовому» режимі для роботи з першої секунди після підключення — там вже є готові шаблони, плюс пристрій отримує дані з «хмари» свого вендора. З одного боку, це добре в плані відображення йде атаки, з іншого — якщо ви звикли тонко налаштовувати все в своєї інфраструктурі, тут доведеться частково покластися на досвід вендора.

2. Саме захисне залізо може стати точкою відмови.
Тому, по-перше, на серйозних об'єктах воно дублюється або кілька пристроїв збираються в кластер (відповідно, потрібні керуючі пристрої). А по-друге, такі пристрої мають апаратні байпассы, що дозволяють переключити інтерфейси на фізичному рівні трафік безпосередньо у випадку різних аварійних ситуацій — відключення харчування, відмови програмного забезпечення і так далі…

3.Защитное залізо може стати і метою атаки.
Особливо, якщо воно є пристроєм з таблицею станів (session table), наприклад об'єднує функціонал захисту від DDOS, IPS, міжмережевий екран, і т.д.). Кожен раз, коли на таких пристроях відкривається нова сесія, пристрій виділяє пам'ять для відстеження сесії, заповнює лог і так далі — і чим розумніша пристрій, тим більше роботи відбувається. Багато сесій — велика утилізація CPU і пам'яті. Тому, вибираючи рішення, варто приділити увагу і цьому аспекту.

4. Зазвичай в мережі досить багато сміттєвого трафіку, а в разі великих організацій — ще й регулярно бувають піки активності, які можуть зійти за «дурний» DDoS.
Зрозуміло, що всі отпрофилируется з географії, по часу використання сервісів і так далі, але на першому етапі важливо отримати розуміння, що включення пристрою в мережу не вб'є сервіси. Для цього використовується дзеркальний режим підключення: пристрій ставитися в мережу на байпасі і отримує дзеркальний трафік, показуючи, що б воно відхилило, а що б пропустило. Це дозволяє робити оцінку до виникнення проблем. Я знаю замовників, де DDoS-захист стоїть саме в такому режимі досить довго. Арбор вважає, що побудова baseline — це тільки один з методів боротьби з DDoS, але набагато краще використання спеціалізованих противомер. Те ж саме колеги говорять і про сигнатурах — наскільки велика не була б мережу сенсорів і скільки б трафіку в ній не аналізувалася, покладатися тільки на сигнатури не можна. Складні загрози вимагають поєднання різних механізмів захисту.

5. На рівні обміну трафіком між провайдерами іноді трапляється досить неприємна ситуація, коли підмережа передає сигнатуру атаки, а вищестоящий провайдер каже: «Дааа, цікаво, але ми у себе чистити не будемо».
Принцип дуже простий — поки канал справляється, весь DDoS-трафік билингуется. Не завжди вищестоящому провайдеру цікаво витрачатися і чистити його, коли можна просто відвантажити нижче, та ще й за гроші потерпілого. Такі ситуації неприємні для сервіс-провайдерів, проте ніяк не позначаються на користувачів послуг захисту від DDoS, оскільки оператори виконують свої зобов'язання в повному обсязі.

Звіти

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

Атака ємністю близько 50 Гбіт/сек

Ця атака почалася з DNS-amplification. Трафік, зафіксований на Arbor Peakflow TMS сервіс провайдера: до 7.15 Гбіт/с., 1.1 Мпакетов/с. З урахуванням фільтрації більшої частини атаки на FlowSpec сумарний трафік атаки оцінений в 50 Гбіт/с. Атака була продовжена HTTP флудом.



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



Система захисту встановлена у оператора, передавала інформацію про ході придушення атаки на Pravail APS в режимі реального часу.



Коли DNS-amplification атака зійшла нанівець, з'явилася велика кількість HTTP флуду.



Крім HTTP флуду також був присутній і TCP SYN флуд.

В результаті, велика частина DNS-amplification атаки була успішно придушено з допомогою Flowspec, інша її частина була пригнічена засобами захисту, HTTP і TCP SYN флуд був скинутий на Pravail APS.

Атака ємністю близько 125 Гбіт/сек





Кілька хвилин на початку — HTTP-флуд. Видно сплеск числа іноземних хостів (червоний графік). Близько 1000 хостів на домен «Великого Російського Банку». Основні країни: США (672), Німеччина (141), Великобританія (82), Італія (30), Нідерланди (24), Франція (14).



Наступний сюрприз — NTP-amplification — до 125 Гбіт/с.



Після невдалого NTP amplification — SYN-флуд з подменными IP — до 300 Мбіт/с

Резюме

Атаки йдуть постійно, і якщо ви з цим не стикалися — це всього лише питання часу. Для ілюстрації, ось кілька подій в РФ:
Якщо у вас є питання — із задоволенням відповім тут або на пошті avrublevsky@croc.ru. Наш підрозділ може запропонувати і різні рішення, якщо вам потрібен інший вендор.

А ще завтра, 21 жовтня, ми проводимо вебінар на тему захисту від DDoS. Приходьте, розповімо, що у нас в Росії зараз відбувається на цьому фронті.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.