Расскажем вам прохладную историю о том, как «третьи лица» пытались помешать работе наших клиентов, и как эта проблема была решена.
А началось всё с утра 31 октября, в последний день месяца, когда многим позарез необходимо успеть закрыть срочные и важные вопросы.
Один из партнёров, который держит в нашем облаке несколько виртуальных машин клиентов, которых он обслуживает, сообщил о том, что с 9:10 до 9:20 сразу несколько Windows-серверов, работающих на нашей украинской площадке, не принимали соединения со службой удалённого доступа, пользователи не могли зайти на свои рабочие с��олы, но через несколько минут проблема как будто бы устранилась сама собой.
Мы подняли статистику работы каналов связи, но не обнаружили ни всплесков трафика, ни провалов. Заглянули в статистику нагрузки на вычислительные ресурсы – никаких аномалий. И что это было?
Затем ещё один партнёр, который размещает в нашем облаке ещё под сотню серверов, сообщил о таких же проблемах, которые отметили некоторые их клиенты, при этом выяснилось, что в целом серверы доступны (исправно отвечают на ping-тест и другие запросы), но служба удалённого доступа на этих серверах то принимает новые соединения, то отклоняет их, при этом речь шла о серверах на разных площадках, трафик к которым поступает из разных каналов передачи данных.
А давайте посмотрим на этот трафик. Пакет с запросом на установление соединения приходит на сервер:
Сервер получает этот пакет, но соединение отклоняет:
Это значит, что проблема явно обусловлена вовсе не какими-то неполадками в работе инфраструктуры, а чем-то ещё. Может, у всех пользователей возникли проблемы с лицензированием удалённых рабочих столов? Может, в их системы успело внедриться какое-то вредоносное ПО, а сегодня оно активировалось, как пару лет назад было с 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 внесла какие-то изменения в код службы удалённого доступа (если помните, мы в первый день заподозрили то же самое, но эту версию мы очень скоро отвергли) и обещает сделать всё возможное, чтобы как можно скорее найти решение. Кто-то просто игнорирует проблему и советует клиентам защищаться своими силами (менять порт подключения, прятать сервер в частную сеть и так далее). А мы в первый же день не только решили эту проблему, но и создали некоторый задел для более глобальной системы обнаружения угроз, которую планируем развивать.
Отдельное спасибо клиентам и партнёрам, которые не молчали и не сидели на берегу реки в ожидании, что по ней однажды проплывёт труп врага, а сразу же обратили наше внимание на проблему, что и дало нам возможность устранить её в тот же день.
Как всё началось
А началось всё с утра 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 внесла какие-то изменения в код службы удалённого доступа (если помните, мы в первый день заподозрили то же самое, но эту версию мы очень скоро отвергли) и обещает сделать всё возможное, чтобы как можно скорее найти решение. Кто-то просто игнорирует проблему и советует клиентам защищаться своими силами (менять порт подключения, прятать сервер в частную сеть и так далее). А мы в первый же день не только решили эту проблему, но и создали некоторый задел для более глобальной системы обнаружения угроз, которую планируем развивать.
Отдельное спасибо клиентам и партнёрам, которые не молчали и не сидели на берегу реки в ожидании, что по ней однажды проплывёт труп врага, а сразу же обратили наше внимание на проблему, что и дало нам возможность устранить её в тот же день.
