Нюанси реалізації захисту від DDoS-атак

Як кажуть, Істина і Брехня полягають у дрібницях. Точніше Істина — в наявності оних, а Брехня — в їх відсутності. Деяким нюансам реалізації «захисту від ddos-атак» і присвячена ця стаття.
Теорії «ddos-атакам» і «захист від них» в Інеті досить багато, тому на даних аспектах зупинятися не буду. У статті намагався озвучити свої міркування по даній темі.



Отже, в ході впровадження нової послуги «захист від ddos-атак» у своїй компанії зіткнувся з деякими нюансами, які навели на ланцюжок міркувань.

1. Реалізація захисту на своїй інфраструктурі поки що досить дорога, як, власне, і всього нового в цьому житті. Саме з цим зіткнулися в першу чергу, коли почали впроваджувати центр захисту від ddos-атак на своїй інфраструктурі. Мова завжди йде про витрати в десяток мільйонів руб. Або більше. Причому при вивченні питання стає зрозуміло, що найближчим часом ці витрати ніяк не «відіб'ються». Якщо питання нівелювання даних витрат не вирішити, то цей нюанс може зупинити всю діяльність в цьому напрямку, що народжує інші нюанси:

— Раз вже дані витрати можуть собі дозволити не всі, то необхідність надання послуг типу «захист від ddos-атак», а точніше «потрібні характеристики центру захисту», багато великі компанії, особливо з держсектора, використовують при оголошенні тендераяк загороджувальний бар'єр під конкретну компанію. Іноді дивишся на вимоги і розумієш, що цифра якась дивна. Приміром, один раз зіткнулися з вимогою, серед інших: «пропускна здатність центру захисту — 180 Гбіт/сек». Чому саме 180? Не 50, 100, не 500, а саме 180? Як вивели цю цифру, з яких міркувань? Поки колеги не відкрили очі на те, що у певного оператора саме така пропускна здатність ядра мережі. До речі, підтвердити цю можливість потрібно було, надавши довідку у довільній формі, підписану керівником», а канал під фільтрований трафік отримували в 1 Гбіт/сек.

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

— Якщо всі витрати прийняти, то постачальнику даної послуги вигідно працювати тільки з великими обсягами. Стикався з тим, що в одній серйозній компанії при перевірці імітованій dos-атакою в 120Мб/с аномалії в статистиці не фіксувалася. На питання, а чому так, було заявлено, що вони фільтрують всі аномалії, але фіксують в статистиці атаки, починаючи з 1Гб/с. тобто, якщо клієнт має доступ в Інтернет в 20Мб/с, то він ніколи не буде поінформований з атак. З одного боку — добре, лише б працювало. З іншого — не дуже, бо немає розуміння, за що клієнт платить.

2. потенційних клієнтів рідко хто розуміє, що конкретно хоче отримати. Спілкувався якось з керівником ІТ-департаменту одного великого банку з цього питання. Здавалося б, він-то точно повинен знати, що в рамках «захисту від ddos-атак» повинен отримати в кількісному вираженні. Відповідь трохи збив з пантелику: «Ну от я тут погуглив, є ж продукт «Харбор пік флоу» (не пишу реальну назву, бо реклама), зробіть те ж, що він може».
Цікаво наслідок цього нюансу.
Один потенційний клієнт збирався змінити постачальника послуги «захист від ddos», з-за того, що його не влаштовувало те, що він зараз має. На питання, а що конкретно не влаштовує, чіткої відповіді ніхто дати не зміг.

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

4. Фіксуються ddos-аномалії дуже часті, але відносно короткочасні. Статистика показує, що система захисту фіксує аномалії в основному на операторському трафік, тривалістю до 30 хвилин. На корпоративному трафік їх менше. Коли починаєш розбиратися з цими аномаліями зазвичай вимальовується картина «Закон Паретто в дії» — 80% аномалій до атак відношення не мають:

— Причина проблеми криється в мережній інфраструктурі клієнта. Або є відмінною особливістю такої мережі («це не баг — це фіча»). Тобто, у клієнта мережева інфраструктура така, що її активність, або мережеві проблеми, фіксуються центром захисту як аномалії, про що центр і сигналізує. До цієї категорії сміливо можна віднести всі географічно розподілені локальні мережі, особливо якщо користувачі в них працюють через якісь vpn-канали.
— Вихідна активність, ініційована, наприклад, вірусами (клієнта не атакують, а він кого-то). Хоча тут можна припустити, що ресурс клієнта все-одно є учасником ddos-атаки, тільки не як мета.
— Активність гравців мережевих ігор. В першу чергу наш центр записував у аномалії трафік WoW.
— Мультикаст-трафік відеореєстраторів. З цим взагалі окрема тема. Особливо за «публічним» реєстраторам, на які доступ розданий всім. Заблокувати трафік не можна, а зрозуміти, хто обслуговує «цей девайс» — практично неможливо.
Основний тип аномалій у цьому випадку — udp-flood або tcp syn-flood. Коли починаєш розбиратися з даних питань, закінчується це тим, що доводиться налаштовувати роботу центру захисту створенням різного роду «білих» списків і винятків, бо клієнт запевняє, що у нього все нормально, а «ця» аномалія — це наслідок «чогось-там», надалі «це прошу не фіксувати».

Наслідком цього нюансу є, по суті заключний.



5. В процесі впровадження послуги неодноразово виникало питання: «Кому все-таки потрібна ця послуга?». Запитів, чесно кажучи, на неї не багато. Мабуть поки «грім не гряне — мужик не перехреститься». Скоріше за все, мало хто замислюється про таку загрозу, поки не потрапляє під реальну ddоs-атаку. Ось тоді відразу з'являється розуміння, що реальна атака — це дуже серйозно, і не дарма вважається правопорушенням. Атакують завжди з якоюсь метою, в основному, мабуть, з політичних мотивів, або за замовленням конкурентів, або при зломі захисту мережі. Тобто, в будь-якому випадку це логічний наслідок основної діяльності організації. На мій погляд, навряд чи хто-то просто так буде атакувати, наприклад, Інтернет-магазин, який торгує одягом. Можна звичайно говорити про експерименти початківців хакерів, або «помсти злісних покупців», але серйозність даних атак навряд чи значна. Тому, на мій погляд, потенційними цілями ddos-атак можуть бути:

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

Операторам зв'язку «центр захисту від ddos-атак» потрібен, якщо вони збираються продавати дану послугу. В інших випадках у оператора зв'язку спочатку є ресурси для свого захисту. Персонал знає, що робити, магістральних каналів декілька, їх пропускна здатність не мала. Та й атакувати оператора зв'язку особливого сенсу немає. А якщо все-таки атакують якесь туристичне агенство, та так, що оператору зв'язку теж дістається, то завжди можна попросити колег up-link-оператора «заблэкхолить» джерело.

p.s. При написанні статті з'явилася нова стаття. Задумався, а цей випадок під яку категорію можна підвести? Скоріш усього під 2-ю — спроба дезорганізації діяльності. Хоча, звичайно, банки логічніше ddos-ить для злому… Схоже невдала спроба, судячи з відповіді СБ банків.
Джерело: Хабрахабр

0 коментарів

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