Расскажем классную историю о том, как «третьи лица» попытались помешать работе наших клиентов, и как эта проблема была решена.
Как все началось
Все началось утром 31 октября, в последний день месяца, когда многим крайне необходимо успеть решить насущные и важные вопросы.Один из партнеров, который держит в нашем облаке несколько виртуальных машин клиентов, которых он обслуживает, сообщил, что с 9:10 до 9:20 несколько Windows-серверов, работающих на нашем украинском сайте, не принимали подключения к сервису удаленного доступа, пользователи не могли войти в свои рабочие столы, но через несколько минут проблема, похоже, разрешилась сама собой.
Мы собрали статистику работы каналов связи, но скачков или сбоев трафика не обнаружили.
Посмотрели статистику по загрузке вычислительных ресурсов – аномалий нет. И что это было? Затем другой партнер, у которого в нашем облаке размещено еще около сотни серверов, сообщил о тех же проблемах, которые отмечали некоторые их клиенты, и оказалось, что в целом серверы были доступны (корректно отвечали на пинг-тест и другие запросы), но служба удаленного доступа на этих серверах либо принимает новые соединения, либо отклоняет их, причем речь шла о серверах на разных сайтах, трафик на которые поступает с разных каналов передачи данных.
Давайте посмотрим на этот трафик.
На сервер приходит пакет с запросом на соединение:
Сервер получает этот пакет, но отклоняет соединение: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 - воин, а если кто-то захочет настроить VPN-сервис на собственном Windows-сервере, мы всегда готовы поделиться советами по настройке стандартный RAS или OpenVPN. Но, как бы мы ни были круты, это было не лучшее время для проведения просветительской работы среди клиентов, поскольку нам нужно было максимально быстро устранить проблему с минимальным стрессом для пользователей.
Решение, которое мы реализовали, заключалось в следующем.
Мы настроили анализ проходящего трафика таким образом, чтобы отслеживать все попытки установить TCP-соединение на порт 3389 и выбирать из него адреса, которые в течение 150 секунд пытаются установить соединения с более чем 16 различными серверами нашей сети.
- это источники атаки (Конечно, если у кого-то из клиентов или партнеров есть реальная необходимость установить соединения с таким количеством серверов из одного источника, вы всегда можете добавить такие источники в «белый список».
Причём, если в одной сети класса С за эти 150 секунд выявлено более 32 адресов, имеет смысл заблокировать всю сеть.
Блокировка устанавливается на 3 дня, и если за это время не было осуществлено ни одной атаки из данного источника.
этот источник автоматически удаляется из «черного списка».
Список заблокированных источников обновляется каждые 300 секунд. 
Этот список доступен по этому адресу: https://secure.tucha.ua/global-filter/banned/rdp_ddos , вы можете построить на его основе свои ACL.
Мы готовы поделиться исходным кодом такой системы; в нем нет ничего сверхсложного (это несколько простых скриптов, скомпилированных буквально за пару часов на коленке), и в то же время его можно адаптировать и использовать не только для защиты от такой атаки, но и для обнаружения и блокировка любых попыток сканирования сети: перейдите по этой ссылке.
Кроме того, мы внесли некоторые изменения в настройки системы мониторинга, которая теперь более внимательно отслеживает реакцию контрольной группы виртуальных серверов в нашем облаке на попытку установить RDP-соединение: если реакция не последует в течение во-вторых, это повод обратить внимание.
Решение оказалось достаточно эффективным: жалоб больше нет как со стороны клиентов и партнеров, так и со стороны системы мониторинга.
В черный список регулярно добавляются новые адреса и целые сети, что свидетельствует о том, что атака продолжается, но уже не влияет на работу наших клиентов.
Безопаснее действовать сообща
Сегодня мы узнали, что с подобной проблемой столкнулись и другие операторы.Кто-то до сих пор считает, что Microsoft внесла какие-то изменения в код службы удаленного доступа (если вы помните, мы в первый день подозревали то же самое, но очень быстро отвергли эту версию) и обещают сделать все возможное, чтобы быстро найти решение .
Некоторые просто игнорируют проблему и советуют клиентам обезопасить себя самостоятельно (сменить порт подключения, спрятать сервер в приватную сеть и так далее).
И в первый же день мы не только решили эту проблему, но и создали некую основу для более глобальной системы обнаружения угроз, которую планируем развивать.
Особая благодарность клиентам и партнерам, которые не молчали и не сидели на берегу реки в ожидании, пока однажды по ней проплывет труп врага, а сразу обратили наше внимание на проблему, что дало нам возможность ее устранить.
это в тот же день.
Теги: #ddos-атака #Системное администрирование #облачные сервисы #Администрирование серверов #безопасность #облако #эффективность #техническая поддержка #удаленный доступ #инструкции #rdp-клиент #доступность данных #надежность данных #надежность дата-центра #безопасность данных
-
Печать А0 И Печать А1
19 Oct, 24 -
Curiosity Обнаружил Вулканическую Породу
19 Oct, 24 -
Как Правильно Писать Код?
19 Oct, 24
