Розкажемо вам прохолодну історію про те, як «треті особи» намагалися перешкодити роботі наших клієнтів, і як цю проблему вирішили.
Як усе почалося
А почалося все з ранку 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 и Петька?
Поки розбиралися, отримали аналогічні звернення від кількох клієнтів і партнерів.
А що взагалі відбувається на цих машинах?
У журналах реєстрації подій повно повідомлень про спробу підібрати пароль:
Зазвичай такі спроби реєструються на всіх серверах, де для служби віддаленого доступу використовується стандартний порт (3389) і дозволений доступ звідусіль. У мережі Інтернет повним-повнісінько ботів, які постійно сканують всі доступні точки підключення і намагаються підібрати пароль (саме з цієї причини ми рекомендуємо використовувати складні паролі замість «123»). Тим не менш, інтенсивність цих спроб у той день була аж надто висока.
Як вчинити?
Рекомендувати клієнтам присвятити купу часу на те, щоб змінити налаштування у величезної кількості кінцевих користувачів, щоб перейти на інший порт? Не дуже хороша ідея клієнти не будуть раді. Рекомендувати дозволити доступ лише через VPN? У поспіху та паніці піднімати IPSec-з'єднання, у кого вони не підняті, – мабуть, клієнтам таке щастя теж не посміхається. Хоча, треба сказати, це в будь-якому випадку справа богоугодна, ми завжди рекомендуємо ховати сервер у приватну мережу і готові допомагати з налаштуваннями, а для любителів розбиратися самостійно ділимося інструкціями для налаштування IPSec/L2TP у нашій хмарі в site-to-site або road -warrior, а якщо хтось хоче підняти VPN-службу на своєму власному Windows-сервері – завжди готові поділитися підказками щодо того, як підняти стандартний RAS або OpenVPN. Але, які б кльові ми не були, це був не найкращий час для ведення просвітницької роботи серед клієнтів, так як потрібно було якнайшвидше усунути проблему з мінімальним напруженням для користувачів.
Рішення, яке ми запровадили, полягало в наступному. Ми налагодили аналіз трафіку, що проходить таким чином, щоб відстежувати всі спроби встановити TCP-підключення до порту 3389 і вибирати з нього адреси, які протягом 150 секунд намагаються встановити з'єднання з більш ніж 16 різними серверами в нашій мережі, - це і є джерела атаки ( Вочевидь, якщо в когось із клієнтів чи партнерів є реальна потреба встановлювати з'єднання з такою кількістю серверів з однієї й тієї джерела, завжди можна додати такі джерела в «білий список». секунд виявлено більше 150 адрес, є сенс блокувати всю мережу.Блокування встановлюється на 32 доби, а якщо за цей час атаки з цього джерела не проводилися, це джерело видаляється з «чорного списку» автоматично.Список заблокованих джерел оновлюється раз на 3 секунд.
Список цей доступний ось за такою адресою: , можете будувати з урахуванням його ACL.
Вихідним кодом такої системи ми готові поділитися, в ньому немає нічого надскладного (це кілька простеньких скриптів, складених буквально за пару годин «на коліні»), і при цьому його можна адаптувати та використовувати не лише для захисту від такої атаки, але й для виявлення та блокування будь-яких спроб сканування мережі:
До того ж, ми внесли деякі зміни в налаштування системи моніторингу, яка тепер уважніше стежить за реакцією контрольної групи віртуальних серверів у нашій хмарі на спробу встановити RDP-підключення: якщо реакція не з'явилася протягом секунди – це привід звернути увагу.
Рішення виявилося досить ефективним: скарг як з боку клієнтів та партнерів, так і системи моніторингу більше немає. До «чорного списку» регулярно потрапляють нові адреси та цілі мережі, що говорить про те, що атака продовжується, але вже не впливає на роботу наших клієнтів.
Один в полі не воїн
Сьогодні ми дізналися, що з аналогічною проблемою зіткнулися інші оператори. Хтось все ще вважає, що це Microsoft внесла якісь зміни до коду служби віддаленого доступу (якщо пам'ятаєте, ми в перший день запідозрили те саме, але цю версію ми дуже скоро відкинули) і обіцяє зробити все можливе, щоб як можна швидше знайти рішення. Хтось просто ігнорує проблему і радить клієнтам захищатися самотужки (міняти порт підключення, ховати сервер у приватну мережу тощо). А ми в перший же день не лише вирішили цю проблему, а й створили певний заділ для глобальнішої системи виявлення загроз, яку плануємо розвивати.
Окреме спасибі клієнтам та партнерам, які не мовчали і не сиділи на березі річки в очікуванні, що по ній одного разу пропливе труп ворога, а одразу ж звернули нашу увагу на проблему, що й дало нам можливість усунути її того ж дня.
Джерело: habr.com