Брутфорс

Мы разместили 5 ханипотов, в дальнейшем просто серверов, чтобы собрать статистику по брутфорсу RDP в наших сетях.

Один сервер находился в Лондоне, другой в Цюрихе, один в защищенной сети в M9, два других в дата-центре Rucloud в защищенной и незащищенной сетях. IP адреса каждого из серверов находятся в разных подсетях, каждый IP адрес отличается первым октетом. Если попытаться измерить расстояние скана между IP адресами по формуле:

((Первый октет подсети 1) (Первый октет подсети 2)) * (2^24),

Если сканировать 0.0.0.0/0, атакующему придется пролистать как минимум 771751936 IP адресов, чтобы найти два самых ближайших друг к другу сервера. Вдобавок, каждый из серверов не отвечал на ICMP и каждый IP адрес не использовался никем в течение 3 месяцев, все 5 серверов открыли порты в одно и то же время. Все серверы были подключены к AD.

Разноцветные графики

Начинаем с интересного и заканчиваем значительным.



Начало было хорошим. Первый брутфорсер сел на сервер в Rucloud в первый же час, как порт был открыт. На всех остальных дата-центрах сервер был обнаружен только на второй час.

Как видно на графиках, сила перебора не сильно менялась изо дня в день. А если посмотреть по времени суток? Вот графики. Разные цвета это разные сутки.


График по времени суток дц ZUR1.


График по времени суток в защищенной подсети M9.


График по времени суток в дц LD8.


График по времени суток в защищенной подсети Rucloud.


График по времени суток в Rucloud.

Достаточно скучная картина, можно сказать, что картина не меняется в зависимости от времени суток.

Посмотрим на эти же графики по времени суток, но уже суммарно по всем дата-центрам.


График по времени суток с накоплением.


График по времени суток.

Картина с перебором паролей не меняется в зависимости от времени суток. То есть, устройства, которые участвовали в переборе паролей, скорее всего, всегда включены.


Статистика неудачных попыток входа по каждому адресу по одной незащищенной подсети Rucloud.

Всего, в переборе за целую неделю на одной из незащищенных подсетей Rucloud поучаствовали 89 IP адресов. 10 IP адресов набили 50% из 114809 попыток.


Статистика неудачных попыток входа по каждому адресу по всем дата-центрам.

Этот же самый блин, но только со статистикой по всем дата-центрам. 50% всей статистики набили 15 IP адресов. Попыток по всем пяти серверам было более полумиллиона. А насколько разными были атакующие?



По всем сетям было замечено 143 IP адресов и лишь 29 IP адресов было замечено на всех 5 серверах. Меньше половины из всех атакующих брутили 2 или более сервера. Значит, расстояние сканирования между IP адресами имеет значение. Значит, данные об открытых портах атакующие получали с помощью nmap, сканируя IP адреса один за другим.

Считаем ботнеты

Посмотрев на отчеты и юзернеймы, которые использовались для перебора, мне бросились в глаза словари, которые использовали разные IP адреса, количество логинов в словарях.

Предположим, что это все разные ботнеты с разными словарями, тогда, я насчитал N ботнетов. Вот словари каждого из них:

admin, administrator, administrador, administrateur, admin, administrator, administrador, administrateur, ADMIN, USER, USER1, TEST, TEST1, ADMINISTRATOR, USER1, USER2, USER3, USER4, USER5, USER6, USER7, USER8, USER9, HP, ADMIN, USER, PC, DENTAL

Этот ботнет был самым большим и использовал самый большой словарь. Там встречались много логинов на разных языках, в т.ч. русский, французский и английский:

1, 12, 123, 1234, 12345, 13, 14, 15, 19, 1C, CAMERA, СAMERA, ADMIN, USERL8, GVC, ADMINISTRATEUR, IPAD3, USR_TERMINAL, JEREMY, ADMINISTRATOR, ADM, ALYSSA, ADMINISTRATOR, ATELIER, CAMERA, СAMERA, ADMIN, USERL8, GVC, ADMINISTRATEUR, USR_TERMINAL, JEREMY, IPAD3, USR_TERMINAL, JEREMY, ADMINISTRATOR, ADMIN, ADM, SERGEY, OLEG, IRINA, NATASHA, SYSTEM, SERVICE, GVC, ADMINISTRATEUR, IPAD3, USR_TERMINAL, JEREMY, ADMINISTRATOR, ADMIN, ADM, SERGEY, OLEG, IRINA, NATASHA и так далее, включая даже китайские логины.

Были словари, которые использовали только китайские и английские слова. Вынуть китайские символы из базы с помощью Powershell мне не удалось. Вот только часть словаря китайских товарищей:

SHENZHEN, TIANJIN, MANDARIN, CHONGQING, SHENYANG, XIAN, CONS, CHINA, TECHNOLOGY, ISPADMIN, BEIJING, SHANGHAI

Так же были единичные IP адреса пытающиеся перебирать эти логины. Вероятно, просто дети играются:

USR1CV8, ADMINISTRATOR
ADMI, NIMDA, ADMS, ADMINS

Бывает просто тупой перебор паролей, перебор паролей по словарю, а есть более-менее интересный перебор. У атакующих есть возможность получить имена пользователей, SMB шар, иногда даже хэши паролей, имена компьютеров, имя домена AD или WorkGroup.

Специалисты по ИБ знают о BloodHound, о ней знаю и хакеры. Если мы оставим AD в дефолтном её состоянии, то можно похитить имя домена, имя компьютера, даже хэши паролей юзеров. На хабре уже писали о векторах атаки на AD и об этой тулзе. Я рекоменду к прочтению этот блестящий материал.

Кстати, первая атака с применением имени сервера и домена началась через 13 часов после открытия портов, но взломщик быстро отстал, попытавшись ворваться всего 138 раз. Вторая такая атака с этим же словарем повторилась через 3 дня, но тоже долго не продлилась.

Итого 5 ботнетов с разными словарями. Надо будет собирать более подробную статистику по используемым логинам, чтобы понять, какие чаще всего используются и в каких пропорциях. Весьма вероятно, что первый взгляд замылен не слишком точным сбором всей статистики и реальная картина немного интереснее.

А это проблема?

Сначала самоизоляции мы начали фиксировать очень странную недоступность серверов. Сначала мы списали все это на перегрузку сети провайдеров домашнего интернета, на Netflix и торренты, бывает, инфраструктура была не готова.

Подозрения на инфраструктуру быстро исчезли, когда наши немногочисленные клиенты на Windows Server 2008, те не могли зайти на RDP в принципе. Посмотрев в журнал безопасности, мы фиксировали рекордные показатели атак, более 36 тысяч попыток за 24 часа.

Как оказалось, брутфорс достаточной интенсивности способен либо целиком положить RDP, либо вызывать постоянные разрывы.

Генез проблемы до конца неясен. Либо RDP кладется всей сворой, либо каким-то одним атакующим. Воспроизвести дисконнекты и зависание картинки с помощью скрипта и mstsc.exe не удалось.

То ли брутфорс превращается в DDoS, толи у какого-то из атакующих как-то по-особому реализована брутилка, что вызывает и проблемы. Единственное что ясно, что время разрыва соединение совпадает с неудачными попытками входа в систему.

Самые зверские атаки проходили этим летом в июне, тогда наша поддержка фиксировала наибольшее количество лагов и разрывов RDP. К сожалению, мы тогда еще не собирали статистику.


Источник: Kaspersky

Решение?

Да.
Все что нужно сделать чтобы защититься, это закрыться брандмауэром. Но я ощущаю ту же самую лень, что и вы, поэтому сделал эти модули.

Модули работают на Windows Powershell 5.1 и Powershell Core 7. Ссылка на гитхаб проекта находится тут. Теперь взглянем на функции.

Protect-Bruteforce

Пока что модуль называется так. Изменяет правило брандмауэра, добавляя все успешно залогиненые IP адреса в правило. Удобно для использования вместе со статическим IP адресом, упрощает деплой серверов удаленных рабочих столов в связке с VPN шлюзом.

Unprotect-Bruteforce

Сбрасывает RemoteAddress для дефолтных правил брандмауэра.

Stop-Bruteforce

Просматривает журнал событий на предмет неудачных входов и блокирует IP адреса из списка отдельным правилом Stop-Bruteforce.

Get-Bruteforce

Возвращает массив объектов статистики по каждому IP адресу. Именно этой функцией собиралась статистика для графиков выше.

Опрос

Мы в RUVDS считаем, что операционная система должна доставляться пользователю в предельно неизмененном состоянии. Мы думаем, что в идеальном мире, операционная система должна предоставляться так, какой она была в своем стоковом состоянии при первом запуске. Но ведь функции, такие как генерация паролей из ЛК, не только упрощают жизнь, просто необходимы многим нашим клиентам. Хотим знать ваше мнение о подобного рода quality of life штуках. Голосуйте и комментируйте.

В одной из статей я рассказывал о том, как скрипт кидди мешает жить нашим клиентам. В этой статье я хотел бы рассказать про решения: как мы будем пытаться с этим бороться.

Пока что без целиковых исходников, они будут в следующих статьях. Ну а пока, скорее, о стратегии и тактике защиты.

Стандартные решения

Рассылать жалобы

Очень распространенный подход. При обнаружении вторжения в свою ИС занести атакующего в фаерволл (или не занести) и отправить автоматическую жалобу по почте, которую нашли во whois.
Мы получаем жалобы на наших клиентов от системы обнаружения вторжений разных банков, офисов, сайтов. Даже, вроде как, крупные организации просто накатывают fail2ban и на этом все.
Работать это все будет через раз, что, если атакующего не забанят? Да и неправильно это, давать возможность постучаться к себе в дверь, что, если кто-то установит пароль уровня solarwinds123 и его взломают с первой попытки?

Заставлять пользователей делать правильно.

Можно сделать свою службу, почти малварь, как это сделали Godaddy, добавить еще одного пользователя под логином nydys и забыть отключить адимнистратора cloud-init, как это сделали Godaddy, установить в систему 8 лишних сертификатов, как это сделали Godaddy.
Еще можно блокировать AD и другие небезопасные порты, как это делали некоторые другие хостинги и вот это вот все.

Можно запустить своих кравлеров и сканировать свои собственные сети. Просматривать порты, находить уязвимые службы или даже пытаться ворваться к своим собственным клиентам под самыми часто взламываемыми паролями.

Это действительно в чем-то поможет, но что и как должно быть устроено на серверах пользователя должен решать пользователь. Плюс, если делать все это, что называется, on a scale, то наткнемся на разброс в технической подкованности пользователей и на недопонимание, Ну что такого я сделал?! и Я не программист!, а в безопасности должны быть все.

Заняться безопасностью

Все что выше очень круто и может быть полезно. Но пользователей нужно защищать. Особенно новичков. Виртуальные сервера часто используются как поле для экспериментов, платформа для ознакомления с серверными системами и, иногда, пользователи ошибаются.

Мы общались с владельцами взломанных машин, просили честно сказать, какой пароль был установлен и к сожалению, логины и пароли уровня test:test или 111:111, это все еще частая практика.

С пользователями Linux все несколько хуже, они идут на контакт не так охотно, как пользователи Windows, хотя, судя по количеству жалоб на серверы с Linux, они чаще взламываются или используются злоумышленниками.

Понятно, что не все ослабляют политики и устанавливают пароли уровня 12345678 на рута, но такое встречается регулярно, поэтому, надо попробовать.

Архитектура

Простая как шпала. Вот картинка:

1. Сервер-ловушка собирает статистику за 1 час и отправляет собранные данные в базу данных.
2. Сервер судья собирает данные из базы и выносит решения по банам. Баны тоже записываются, для истории болезни каждого конкретного IP адреса.
3. Сервер BGP парсит сгенерированный лист с банами и передает этот лист в качестве BGP фида дальше, на роутеры.

C серверов-ловушек, данные отправляются в том же формате этим же Get-Bruteforce, что мы предлагали ранее, а именно:

1. Количество попыток взлома
2. Использованные логины
3. IP адрес
4. PTR запись

Как проходит взвешивание решений

Речь идет о потенциально боевом решении, поэтому, банить всех под ряд нельзя. Нужно вводить дискретные, понятные критерии чтобы было ясно, как, что и почему.
На текущий момент учитывается 6 факторов:

1. Сколько раз атакующий попытался ворваться
2. В какое количество разных приманок он попал
3. Статический ли IP адрес
4. Принадлежит ли IP адрес хостингу или домашнему провайдеру
5. Использовал ли атакующий плохие логины
6. Мнение других хороших парней

Количественные выражения

Тут все ясно. Чем интенсивнее перебор и чем больше его площадь, и чем больше словарь, тем выше угроза исходящая от атакующего. Этот пункт разворачивать нет смысла.

PTR и всё что с ним связано

Когда мы публиковали первичный анализ по брутфорсу, стало заметно, что PTR запись говорит о многом.

Количество китайских хостингов, атакующих наши серверы было просто зашкаливающим, но это и не исключение, клиенты Azure и AWS тоже очень бодро участвовали и занимали не последние места.

Наибольшее количество атак поступало именно со статических IP адресов хостинг провайдеров, поэтому, если наибольшую угрозу безопасности представляют серверы, зачем банить обычных юзеров?

Плохие логины

Есть и такие. К примеру, из легко гуглящихся k8h3d первый кандидат на бан. Это логин от очень тупого червя криптодобытчика, который оставлял бэкдор в RDP под этим именем пользователя.Тоже самое, касается и логинов, набранных на хинди, китайском и прочих других раскладках, не характерных для наших клиентов.

Можно себе представить ситуацию, где человек ошибется в одной цифре IP адреса, не войдет и начнет перебирать все пароли что были в его жизни. А вот ожидать от нашего клиента, что он начнет набирать что-то кроме стандартного Administratora сложно себе представить. Мы предоставляем ОС только под английскими логинами, поэтому, бан по раскладке клавиатуры, пожалуй, наиболее эффективен и безопасен.

Другие хорошие парни

Spamhaus как пример хороших парней, спасибо им за открытые листы блокировки. Скажем, атакующий хитанул всего один ханипот, но его адрес уже давно лежит в SBL, то зачем же тянуть?
Тоже самое с открытыми листами fail2ban, мнение других хороших парней позволяет более уверено выносить решения.

Тестирование

Как в медицине. Рандомизированное двойное слепое исследование. Наблюдаемые серверы (кроме ловушек) поделены на две группы.

• Контрольная группа
• Пациенты

Первые две недели применяем правила фильтрации только для пациентов. Контрольная группа получает весь трафик без фильтрации. После этого, ровно половина серверов из обеих групп меняются местами.

Дополнительные контрольные группы будут расположены и в других ДЦ, чтобы учитывать сезонность и исключить влияние других факторов, например, как закрытие контроллеров и т.п.
Таким образом можно будет наиболее достоверно установить, насколько ханипоттинг эффективен как метод защиты чего угодно, кроме самих ханипотов.

Что дальше?

После сбора первичных данных, около-боевое тестирование будет проводиться всего на паре дата-центров и если это значительно сократит количество атак, то мы опубликуем:

1. Открытый лист блокировки развернутыми комментариями в формате txt, xml и json
2. Скрипт для RouterOS и отдельный лист блокировки для RouterOS
3. Открытый фид для роутеров с поддержкой BGP.
4. Исходные коды.

Ну а если атак не станет меньше или будет больше проблем, то опубликуем только исходный код и отчет, почему прогорело.

Надеюсь, что тема вам так же интересна, как и ему и ждет ваших мыслей по поводу предложенной системы, любые мысли будут полезены.