DDoS атака в обхід Qrator. Як захиститися?

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



Вихідна пошта

Давайте зареєструємося в такому сервісі і отримаємо від нього лист про реєстрацію в пошту. Відкриємо ісходник листи і побачимо:
Received: from mxfront8j.mail.yandex.net ([127.0.0.1])
by mxfront8j.mail.yandex.net with LMTP id c0MIOzBI
for <mymail@yandex.ru>; Sun, 10 May 2015 15:58:47 +0300
Received: from srv1.example.com (srv1.example.com [xxx.xx.xx.xxx])
by mxfront8j.mail.yandex.net (nwsmtp/Yandex) with ESMTPS id FpRuMcFeJH-wksakWfe;
Sun, 10 May 2015 15:58:46 +0300
(using TLSv1 with cipher AES128-SHA (128/128 bits))
(Client certificate not present)
Received: from srv1.example.com (localhost [127.0.0.1])
by srv1.example.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id t4ACvd6T026304
for <mymail@yandex.ru>; Sun, 10 May 2015 15:57:39 +0300
Received: (from www-data@localhost)
by srv1.example.com (8.14.3/8.14.3/Submit) id t4ACvdQX026302;
Sun, 10 May 2015 15:57:39 +0300


Ну ось ми і знайшли машину в підмережі цього сервера в цьому ДЦ, а не проксі. Ось вона: srv1.example.com, xxx.xx.xx.xxx. З великою ймовірністю ця машина знаходиться в тому ж ДЦ і в тій же підмережі, що і www сервер. Зазвичай такі проекти не мають великих мереж, не більше /24 — давайте просканим сітку і знайдемо всі машини з відкритим 80/tcp порт. Ну відмінно, є список машин — зайдемо на кожну браузером. На машині з адресою xxx.xx.xx.xxy з нами трапився редирект на www.example.com — це та сама машина, вони отредиректила нас на проксі-захисника.

Тепер ми можемо сміливо атакувати цю машину. Канал на машині навряд чи буде більш 1GB, але є материнки де вбудовані мережеві карти відразу з 4ма інтерфейсами — значить атака буде з запасом — 4GB. Ми не будемо влаштовувати атаку на додаток, або атаку на nginx — можна просто залити канал трафіком. При тому, що ми заллємо тільки входить напрям до сервера — не страшно — запити від користувачів, теж входить напрям. Багато це 4 GB для DDoS атаки? Давайте порахуємо! У Москві у багатьох людей вдома хороший інтернет — 40Мб мінімум. 4 GB / 40 МБ = 100 машин. Це всього лише 100 машин з ботом — такий ботнет можна організувати досить швидко (якщо є відповідний навик), а для людини постійно займається DDoS — це взагалі не проблема, сучасні ботнети — це тисячі заражених машин.

Як же захиститися?
Просте рішення — мати поштову машину поза ДЦ і поза бойової підмережі, яка буде працювати поштовим релеем і відрізати весь «Received» що у неї є. Зробити це не складно, в тому ж postfix є опція content_filter, де можна вказати SMTP-проксі для фільтрації вмісту. На будь-якій мові можна легко і просто написати smtp-проксі, який відріже все зайве в листі. Я готових інструментів не знаю якщо чесно, але для мене завдання написати smtp-проксі на python або ruby — завдання на кілька годин.

Вкрасти DNS зону

Менш доступний, але теж реальний спосіб. Потягнувши DNS-зону ми знайдемо в ній імена машин і IP-адреси — зазвичай технічні імена машин тримають прямо в цій же зоні. Що начебто
srv1.example.com IN A xxx.xx.xx.xxx

Захиститься досить просто — усі технічні DNS-и, виносяться в окремий піддомен і захищаються більш ретельно. srv1.servers.example.com — як то так.

Непряма атака

Не складно зробити висновок, що сайт без статики — не працює. Зазвичай сервіси для захисту від DDoS беруть гроші за трафік, з цього статику з основного домену переносять на CDN. Завалити трафіком CDN — задача дуже складна, за його роздрібненості. Але можна подивитися, що за статика є ще на сайті. Про! З лівого сервісу показуються банери і він не сидить за проксі-захисником — це просто удача. Можна залити канал до банерній системі: не завантажиться js, не трапиться DOM Ready — якщо на сайті купа js — користуватися ним майже неможливо.

Це не універсальний спосіб, але він може прокатати, там де сайті без js не працює впринципі. Захист від цього теж максимально тупа — асинхронний js до банерів. Не зміг — ну й гаразд.

Фінансова атака

Ось ми знайшли на CDN цікавий файлик: cdn-1.example.com/static/video/hardporn.flv і важить він аж 140 MB. Ми пам'ятаємо, що проксі-захисники беруть гроші за трафік. А звідки CDN візьме цей файл? У простому випадку з www.example.com/static/video/hardporn.flv, перевіримо і переконаємося, що він віддається. Ну й чудово. У простому випадку нам потрібен дуже маленький ботнет, який просто буде пару днів завантажувати цей файл — без особливого навантаження, не привертаючи до себе уваги проксі-захисника. Звичайно це буде перевищення передплаченого трафіку і фірмі-власнику сайту доведеться дуже сумно.

Можна трохи докрутити таку атаку — знайти XSS і увіткнути туди html5 video з autoplay і display: none. Зовні нічого не змінюється, але зате кожен користувач тягне до себе великий трафік. Кожного користувача, на відміну від ботнету не отфильтруешь.

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

Захист від такого проста до дурості — повертайте 403 зі статики всім, крім CDN-ки.

Атака на мобільний API

Якщо сайт має ще й мобільний додаток — це зараз модно, він означає сучасний сайт. Маючи мобільний додаток, зазвичай сайт ще має і мобільний API. Встановивши собі додаток і зібравши tcpdump-му трафік (ну не складно підняти wifi точка-точка на своєму PC), можна знайти api-mobile.example.com. Можливо, через бажання економити він теж буде не через проксі-захисником, а прямо дивитися на сервер. Ну ось і спалився потрібний нам IP.

Захист, як Ви вже зрозуміли проста — трафік API повинен йти через проксі-захисника.

Висновок

Усі наведені способи — прості. Вони не вимагають глибокого дослідження сайту — просто потыкатся в нього, не вимагають навіть отримати на ньому shell. Не всі способи реальні на всіх сайтах, але на більшості сайтів, хоча б один спосіб та буде працювати.
Захист від DDoS атак через сервіси-захисники — хороша, вона виправдовує себе матеріально і технічно. Залишилася завдання для адмінів сайту — так не спали свій IP!

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

0 коментарів

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