В одной из статей я рассказывал о том, как скрипт кидди мешает жить нашим клиентам. В этой статье я хотел бы рассказать про решения: как мы будем пытаться с этим бороться.
Пока что без целых исходников, они будут в следующих статьях. Ну а пока, скорее, о стратегии и тактике защиты.
Стандартные «решения»
Рассылать жалобы
Очень распространенный подход. При обнаружении вторжения в свою ИС занести атакующего в фаерволл (или не занести) и отправить автоматическую жалобу по почте, которую нашли во whois.
Мы получаем жалобы на наших клиентов от системы обнаружения вторжений разных банков, офисов, сайтов. Даже, вроде как, крупные организации просто накатывают fail2ban и на этом все.
Работать это все будет через раз, что, если атакующего не забанят? Да и неправильно это, давать возможность постучаться к себе в дверь, что, если кто-то установит пароль уровня solarwinds123 и его взломают с первой попытки?
Заставлять пользователей «делать правильно».
Можно сделать свою службу, почти малварь, как это сделали Godaddy, добавить еще одного пользователя под логином nydys и забыть отключить администратора cloud-init, как это сделали Godaddy, установить в систему 8 лишних сертификатов, как это сделали Godaddy.
Еще можно блокировать AD и другие «небезопасные порты», как это делали некоторые другие хостинги и вот это вот все.
Можно запустить своих кравлеров и сканировать свои собственные сети. Просматривать порты, находить уязвимые службы или даже пытаться ворваться к своим собственным клиентам под самыми часто взламываемыми паролями.
Это действительно в чем-то поможет, но что и как должно быть устроено на серверах пользователя должен решать пользователь. Плюс, если делать все это, что называется, on a scale, то наткнемся на разброс в технической подкованности пользователей и на недопонимание, «Ну что такого я сделал?!» и «Я не программист!», а в безопасности должны быть все.
Заняться безопасностью
Все что выше – очень круто и может быть полезно. Но пользователей нужно защищать. Особенно новичков. Виртуальные сервера часто используются как поле для экспериментов, платформа для ознакомления с серверными системами и, иногда, пользователи ошибаются.
Мы общались с владельцами взломанных машин, просили честно сказать, какой пароль был установлен и к сожалению, логины и пароли уровня test:test или 111:111, это все еще частая практика.
С пользователями Linux все несколько хуже, они идут на контакт не так охотно, как пользователи Windows, хотя, судя по количеству жалоб на серверы с Linux, они чаще взламываются или используются злоумышленниками.
Понятно, что не все ослабляют политики и устанавливают пароли уровня «12345678» на рута, но такое встречается регулярно, поэтому, надо попробовать.
Архитектура
Простая как шпала. Вот картинка:
- Сервер-ловушка собирает статистику за 1 час и отправляет собранные данные в базу данных.
- Сервер судья собирает данные из базы и выносит решения по банам. Баны тоже записываются, для истории болезни каждого конкретного IP адреса.
- Сервер BGP парсит сгенерированный лист с банами и передает этот лист в качестве BGP фида дальше, на роутеры.
C серверов-ловушек, данные отправляются в том же формате этим же “Get-Bruteforce”, что мы предлагали ранее, а именно:
- Количество попыток взлома
- Использованные логины
- IP адрес
- PTR запись
Как проходит взвешивание решений
Речь идет о потенциально боевом решении, поэтому, банить всех подряд нельзя. Нужно вводить дискретные, понятные критерии чтобы было ясно, как, что и почему.
На текущий момент учитывается 6 факторов:
- Сколько раз атакующий попытался ворваться
- В какое количество разных приманок он попал
- Статический ли IP адрес
- Принадлежит ли IP адрес хостингу или домашнему провайдеру
- Использовал ли атакующий «плохие» логины
- Мнение других хороших парней
Количественные выражения
Тут все ясно. Чем интенсивнее перебор и чем больше его площадь, и чем больше словарь, тем выше угроза исходящая от атакующего. Этот пункт разворачивать нет смысла.
PTR и всё что с ним связано
Когда мы публиковали первичный анализ по брутфорсу, стало заметно, что PTR запись говорит о многом.
Количество китайских хостингов, атакующих наши серверы было просто зашкаливающим, но это и не исключение, клиенты Azure и AWS тоже очень бодро участвовали и занимали не последние места.
Наибольшее количество атак поступало именно со статических IP адресов хостинг провайдеров, поэтому, если наибольшую угрозу безопасности представляют серверы, зачем банить обычных юзеров?
Плохие логины
Есть и такие. К примеру, из легко гуглящихся «k8h3d» — первый кандидат на бан. Это логин от очень тупого червя криптодобытчика, который оставлял бэкдор в RDP под этим именем пользователя. То же самое касается и логинов, набранных на хинди, китайском и прочих других раскладках, не характерных для наших клиентов.
Можно себе представить ситуацию, где человек ошибется в одной цифре IP адреса, не войдет и начнет перебирать все пароли что были в его жизни. А вот ожидать от нашего клиента, что он начнет набирать что-то кроме стандартного Administrator’a сложно себе представить. Мы предоставляем ОС только под английскими логинами, поэтому, бан по раскладке клавиатуры, пожалуй, наиболее эффективен и безопасен.
Другие хорошие парни
Spamhaus как пример хороших парней, спасибо им за открытые листы блокировки. Скажем, атакующий хитанул всего один ханипот, но его адрес уже давно лежит в SBL, то зачем же тянуть?
Тоже самое с открытыми листами fail2ban, мнение других хороших парней позволяет более уверено выносить решения.
Тестирование
Как в медицине. Рандомизированное двойное слепое исследование. Наблюдаемые серверы (кроме ловушек) поделены на две группы.
- Контрольная группа
- Пациенты
Первые две недели применяем правила фильтрации только для пациентов. Контрольная группа получает весь трафик без фильтрации. После этого, ровно половина серверов из обеих групп меняются местами.
Дополнительные контрольные группы будут расположены и в других ДЦ, чтобы учитывать «сезонность» и исключить влияние других факторов, например, как закрытие контроллеров и т.п.
Таким образом можно будет наиболее достоверно установить, насколько ханипоттинг эффективен как метод защиты чего угодно, кроме самих ханипотов.
Что дальше?
После сбора первичных данных, около-боевое тестирование будет проводиться всего на паре дата-центров и если это значительно сократит количество атак, то мы опубликуем:
- Открытый лист блокировки развернутыми комментариями в формате txt, xml и json
- Скрипт для RouterOS и отдельный лист блокировки для RouterOS
- Открытый фид для роутеров с поддержкой BGP.
- Исходные коды.
Ну а если атак не станет меньше или будет больше проблем, то опубликуем только исходный код и отчет, почему прогорело.
Надеюсь, что тема вам так же интересна, как и ему и ждет ваших мыслей по поводу предложенной системы, любые мысли будут полезены.
