company_banner

Как мы в RUVDS спасаем наших пользователей от брутфорса



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

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

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


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


    Очень распространенный подход. При обнаружении вторжения в свою ИС занести атакующего в фаерволл (или не занести) и отправить автоматическую жалобу по почте, которую нашли во 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 адреса, не войдет и начнет перебирать все пароли что были в его жизни. А вот ожидать от нашего клиента, что он начнет набирать что-то кроме стандартного Administrator’a сложно себе представить. Мы предоставляем ОС только под английскими логинами, поэтому, бан по раскладке клавиатуры, пожалуй, наиболее эффективен и безопасен.

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


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

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


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

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

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

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

    Что дальше?


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

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

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

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

    RUVDS.com
    VDS/VPS-хостинг. Скидка 10% по коду HABR

    Comments 13

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

      Откуда столько нелюбви к Godaddy?
        0
        Попользовался Godaddy на винде.
          0

          А можно чуток в деталях? Есть 2 VPS у них. Что эти службы делают? Стоит убрать админа от cloud-init? Прочее...

        +2
        а в безопасности должны быть все

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


        Я уже пару раз с таким навязчивым "сервисом" сталкивался — но тогда мне нужны были все эти левые брутфорсы для самостоятельного изучения (да, ханипот), посему хостеры которые сделали безопасность принудительной пошли лесом.


        Были и другие случаи — когда навороченная система блокировала попытки вполне законных пентестов, но проблема в том что это мешало сканированию на уязвимости (PCI DSS).

          –1
          Если клиент возражает, отключим фильтрацию для его сервера. Но если попадется в ханипот с поличным, то какие возражения могут быть?
            +3
            Если ваш ханипот выдаст «взломщик/спамер/в бан» на конструкцию вида «Пара неудачных попыток логина + IP в спамхаусе», то пардоньте, это больше зло, чем добро будет.
              0
              Все ткущие попытки бана по IP — профанация.
              Они все идут (и автор в их числе) по стопам лажи движка DLE.
              Я неделями не мог войти в админку DLE из-за банов IP, потому, что в моей стране на 5 миллионов пользователей в сети — 50 NAT IP, всего на всю страну.

              И сайты то мои на DLE не слишком и популярны были, но постоянно кто-то из моей страны пробовал войти в акк админа и IP улетал в бан, а я не мог потом войти из-за этого.

              У автора сейчас будет та же проблема — я не смогу войти в свой акк, потому, что мой IP всегда будет в бане. Всегда найдется пару из 500 000 человек на моем IP, кто ломанется в мой акк и забанит этот IP.
                0
                И судя по соотношению юзеров на адрес — купить себе IP без NATа у вас нереально. Вообще я считаю, что обязательно должен быть whitelist на адреса, которые могут творить что угодно, куда собственно и заносить свои.
          +4
          Spamhaus друг сисадминов (упрощает им жизнь) и главный враг бизнесов из-за множества ложных попаданий в список и срабатываний. Например, но одном ip адресе хостинг провайдера может быть большое кол-во сайтов, но страдают все.
            +4
            Полностью согласен. Спамхаус не лучше террористов. Времена McColo прошли, но судя по поисковой выдаче оные продолжают политику уровня «пара хостов спамит — /24 подсетку с ними в чёрный список». Если хостер использует спамхаусные списки для защиты и её нельзя настроить на неиспользование этого самого террориста или отключить(в крайнем случае), то его услуги для меня интереса не представляют.
            +2
            Очень «рваный» стиль изложения, сложно читать.

            отправить автоматическую жалобу по почте, которую нашли во whois.
            Мы получаем жалобы на наших клиентов от системы обнаружения вторжений разных банков, офисов, сайтов. Даже, вроде как, крупные организации просто накатывают fail2ban и на этом все.
            Работать это все будет через раз

            Я верно понимаю, что автор статьи выступает от имени хостинга? Интересен вопрос заявок по abuse (когда ваш хостинг используют в злонамеренных целях): как часто автоматические обращения оказываются ложными срабатываниями? как вы обрабатываете abuse'ы? какие сроки, публикуете ли результаты?
              0
              Ну, то есть, абузы, как и вопрос о них, уходят в /dev/null.
              Я так и думал. Спасибо.
              0
              Даже, вроде как, крупные организации просто накатывают fail2ban и на этом все.
              Работать это все будет через раз, что, если атакующего не забанят?

              Неужели так плохо? Я когда на сервак с nextcloud настроил fail2ban вроде даже неплохо он себя зарекомендовал и если по логам судить, то банилось исправно, а усреднённый аптайм сервера у меня где-то дней 150. Понятно, что у меня это больше поиграться, а не энтерпрайз, но тем не менее. Когда через годика полтора я на новом компе три раза ввёл старый пароль, то потом долго разбирался почему из своей домашней сети доступ к сервису пропал начисто) В моих глазах защита сработала идеально. Надо только отправку посты настроить уже наконец-то ;)

              Only users with full accounts can post comments. Log in, please.