Расскажем вам прохладную историю о том, как «третьи лица» пытались помешать работе наших клиентов, и как эта проблема была решена.
Как всё началось
А началось всё с утра 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 секунд.
Список этот доступен вот по такому адресу: https://secure.tucha.ua/global-filter/banned/rdp_ddos, можете строить на базе него свои ACL.
Исходным кодом такой системы мы готовы поделиться, в нём нет ничего сверхсложного (это несколько простеньких скриптов, составленных буквально за пару часов «на коленке»), и при этом его можно адаптировать и использовать не только для защиты от такой атаки, но и для выявления и блокирования любых попыток сканирования сети: переходите по этой ссылке.
Вдобавок мы внесли некоторые изменения в настройки системы мониторинга, которая теперь более пристально следит за реакцией контрольной группы виртуальных серверов в нашем облаке на попытку установить RDP-подключение: если реакция не воспоследовала в течение секунды – это повод обратить внимание.
Решение оказалось достаточно эффективным: жалоб как со стороны клиентов и партнёров, так и со стороны системы мониторинга больше нет. В «чёрный список» регулярно попадают новые адреса и целые сети, что говорит о том, что атака продолжается, но уже не влияет на работу наших клиентов.
Один в поле не воин
Сегодня мы узнали, что с аналогичной проблемой столкнулись и другие операторы. Кто-то всё ещё считает, что это Microsoft внесла какие-то изменения в код службы удалённого доступа (если помните, мы в первый день заподозрили то же самое, но эту версию мы очень скоро отвергли) и обещает сделать всё возможное, чтобы как можно скорее найти решение. Кто-то просто игнорирует проблему и советует клиентам защищаться своими силами (менять порт подключения, прятать сервер в частную сеть и так далее). А мы в первый же день не только решили эту проблему, но и создали некоторый задел для более глобальной системы обнаружения угроз, которую планируем развивать.
Отдельное спасибо клиентам и партнёрам, которые не молчали и не сидели на берегу реки в ожидании, что по ней однажды проплывёт труп врага, а сразу же обратили наше внимание на проблему, что и дало нам возможность устранить её в тот же день.
Автор: Tuchaua
