DDoS-атака на RDP-служби: розпізнати і подолати. Успішний досвід від Tucha

Розповімо вам прохолодну історію про те, як «треті особи» намагалися перешкодити роботі наших клієнтів і як ця проблема була вирішена.

А почалося все вранці 31 жовтня, в останній день місяця, коли багатьом конче необхідно встигнути вирішити термінові і важливі питання.

Один з партнерів, який тримає у нашій хмарі кілька віртуальних машин клієнтів, яких він обслуговує, повідомив про те, що з 9:10 до 9:20 відразу кілька Windows-серверів, які працюють на нашому українському майданчику, не приймали з'єднання зі службою віддаленого доступу, користувачі не могли зайти на свої робочі столи, але через кілька хвилин проблема начебто б усунулася сама собою.

Ми підняли статистику роботи каналів зв'язку, але не виявили ні сплесків трафіку, ні провалів. Заглянули в статистику навантаження на обчислювальні ресурси — ніяких аномалій. Що це було?

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

Пакет із запитом на встановлення з'єднання приходить на сервер:
xx: xx: xx.xxxxxx IP xxx.xxx.xxx.xxx.58355> 192.168.xxx.xxx.3389: Flags [S], seq 467744439, win 64240, options [mss 1460, nop, wscale 8, nop, nop , sackOK], length 0

Сервер отримує цей пакет, але з'єднання відхиляє:
xx: xx: xx.xxxxxx IP 192.168.xxx.xxx.3389> xxx.xxx.xxx.xxx.58355: Flags [R.], seq 0, ack 467744440, win 0, length 0

Це означає, що проблема явно обумовлена ​​зовсім не якимись несправностями в роботі інфраструктури, а чимось ще. Може, у всіх користувачів виникли проблеми з ліцензуванням віддалених робочих столів? Може, в їх системи встигло потрапити якесь шкідливе ПЗ, а сьогодні воно активізувалося, як пару років назад було з XData і Petya?

Поки розбиралися, отримали аналогічні звернення від ще кількох клієнтів і партнерів.

У журналах реєстрації подій повно повідомлень про спробу підібрати пароль:

Зазвичай такі спроби реєструються на всіх серверах, де для служби віддаленого доступу використовується стандартний порт (3389) і при цьому дозволений доступ звідусіль. В мережі Інтернет повнісінько ботів, які постійно сканують всі доступні точки підключення і намагаються підібрати пароль (саме з цієї причини ми настійно рекомендуємо використовувати складні паролі замість «123»). Проте, інтенсивність цих спроб в той день була аж надто висока.

Рекомендувати клієнтам присвятити купу часу на те, щоб змінити налаштування у величезної кількості кінцевих користувачів, щоб переключитися на інший порт? Не дуже хороша ідея, клієнти раді не будуть. Рекомендувати дозволити доступ тільки через VPN? У поспіху і паніці піднімати IPSec-з'єднання, у кого вони не підняті, — мабуть, клієнтам таке щастя теж не посміхається. Хоча, треба сказати, це в будь-якому випадку справа богоугодна, ми завжди рекомендуємо ховати сервер в приватну мережу і готові допомагати з налаштуваннями, а для охочих розбиратися самостійно, ділимося інструкціями з налаштування IPSec/L2TP у нашій хмарі в режимі site-to-site або road-warrior, а якщо хто бажає підняти VPN-службу на своєму власному Windows-сервері — завжди готові поділитися підказками щодо того, як підняти стандартний RAS або OpenVPN. Але, які б гарненькі ми не були, це був не найкращий час для ведення просвітницької роботи серед клієнтів, так як потрібно було якомога швидше усунути проблему з мінімальним напруженням для користувачів.

Рішення, яке ми впровадили, полягало в наступному. Ми налагодили аналіз вхідного трафіку таким чином, щоб відстежувати всі спроби встановити TCP-підключення до порту 3389 і вибирати з нього адреси, які протягом 150 секунд намагаються встановити з'єднання з більш ніж 16 різними серверами в нашій мережі, — це і є джерела атаки ( зрозуміло, якщо у когось із клієнтів або партнерів є реальна потреба встановлювати з'єднання з такою кількістю серверів з одного і того ж джерела, завжди можна додати такі джерела в «білий список». При цьому, якщо в одній мережі класу C за ці 150 секунд виявлено понад 32 адреси, є сенс блокувати всю мережу. Блокування встановлюється на 3 доби, а якщо за цей час атаки з даного джерела не проводилися, це джерело видаляється з «чорного списку» автоматично. Список заблокованих джерел оновлюється раз в 300 секунд і публікується тут.

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

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

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

Сьогодні ми дізналися, що з аналогічною проблемою зіткнулися і інші оператори. Хтось все ще вважає, що це Microsoft внесла якісь зміни в код служби віддаленого доступу (якщо пам'ятаєте, ми в перший день запідозрили те ж саме, але цю версію ми дуже скоро відкинули) і обіцяє зробити все можливе, щоб якомога швидше знайти рішення.

Хтось просто ігнорує проблему і радить клієнтам захищатися своїми силами (міняти порт підключення, ховати сервер в приватну мережу і так далі).

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

Дорогі клієнти та партнери! Ми щиро вдячні вам за співпрацю та довіру, і завжди раді вашим зверненням до служби технічної підтримки. Більш того: ми просимо вас при виявленні найменших аномалій в роботі ваших серверів не чекати, сидячи на березі, поки труп ворога пропливе по річці, а відразу ж повідомляти про це нас, а ми завжди готові організувати і річку, і берег, і перемогу над ворогом. :-)