DDoS-атака в обход балансировщика: защищайте свои cookie!

    В процессе анализа защищенности IT-инфраструктур нам приходится работать с разным сетевым оборудованием. Бывают хорошо известные устройства и относительно редкие. Среди нечасто встречающихся можно выделить балансировщики нагрузки. Сегодня мы познакомим вас с механизмом поддержания сессий балансировщика F5 BIG-IP методом cookie. Особенность этого механизма в том, что он позволяет злоумышленнику атаковать систему, обходя заданный алгоритм балансировки нагрузки.

    image

    Что такое балансировщик нагрузки? Это сетевое устройство, распределяющее трафик приложений между серверами, а также позволяющее контролировать и изменять его характеристики в соответствии с заданными правилами. При использовании веб-приложений необходимо, чтобы сессию клиента обслуживал один и тот же сервер. Для этого балансировщик BIG-IP отслеживает и сохраняет сессионную информацию, которая включает адрес конкретного веб-сервера, обслуживающего клиента. Эта информация используется для того, чтобы направлять запросы клиента к одному и тому же веб-серверу в течение одной сессии.

    BIG-IP предлагает несколько методов поддержки сессий, среди которых: cookie persistence, hash persistence, destination/source address persistence, SSL persistence. Для HTTP-трафика в подавляющем большинстве случаев используется метод cookie persistence. Он включает в себя четыре типа: HTTP cookie insert, HTTP cookie rewrite, HTTP cookie passive и cookie hash. Тип HTTP cookie insert наиболее распространен, так как в отличие от прочих не требует настройки каждого веб-сервера на отправку определенных cookies, и они автоматически генерируются на балансировщике.

    Давайте посмотрим, какую информацию содержат в себе cookies, отправляемые клиенту.

    image

    Имя cookie формируется как BIGipServer<имя пула>. Клиент сразу же получает информацию об использовании балансировщика BIG-IP и имени пула серверов.

    Теперь посмотрим на cookie. В ней содержится обратное десятичное представление IP-адреса сервера (4225695754) и его порта (20480).
    Для восстановления IP-адреса и порта в привычный формат существует два способа:

    1. Берем десятичное значение cookie, отвечающее за IP-адрес, и переводим в шестнадцатеричный формат: FBDF000A.

    Делим на байты и располагаем их в обратном порядке: 0A00DFFB.

    Конвертируем байты в десятичный формат, каждый байт открывает октет IP-адреса: 10.0.223.251.

    По такому же принципу декодируем порт (там содержится двухбайтовое значение):

    20480→5000→0050→80

    2. Вводим в командной строке “ping 4225695754”. На выходе имеем IP: 251.223.0.10.

    Записываем значения октетов от последнего к первому, получаем: 10.0.223.251.

    Аналогичную операцию можно проделать и для значения порта: ping 20480.

    Получаем значение: 0.0.80.0.

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

    Таким образом мы получили адрес обслуживающего нас сервиса: 10.0.223.251:80.

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

    image

    Содержание:

    • rd524 — route domain 524, обозначает идентификатор домена маршрутов,
    • ac174810 — шестнадцатеричное представление IP-адреса веб-сервера – 172.23.72.16,
    • 5080 — реальный порт веб-сервера.

    Завершая сессии (по умолчанию они истекают при закрытии браузера) и заходя на сайт снова, мы сможем получить информацию о всех серверах пула. Это совершенно ненужное раскрытие информации о внутренней структуре дата-центра.

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

    Посмотрим, как это выглядит на практике:

    1. Меняем значение cookie на соответствующее нужному нам серверу:

    image

    2. Обращаемся к серверу и убеждаемся, что балансировщик перенаправляет нас на сервис, соответствующий значению, установленному нами в cookie на предыдущем шаге:

    image

    Возникает резонный вопрос: как защититься?

    BIG-IP поддерживает функцию шифрования cookies. Шифрование осуществляется 192-битным шифром AES, а затем cookie кодируется по алгоритму Base64.

    Пример шифрованной cookie:

    image

    При использовании шифрования cookies злоумышленник уже не сможет получить информацию об IP-адресах веб-серверов. Однако это не защищает от возможности DoS-атаки на определенный сервер. Дело в том, что шифрованные cookies не имеют привязки к клиенту, и, как следствие, cookies могут быть использованы для проведения атак на сервер с множества источников (например, из бот-сети).

    На диаграмме в начале этой статьи приведена статистика, собранная на основе 100 случайных веб-сайтов, иcпользующих балансировщик BIG-IP и поддержку сессий методом cookie. Согласно этой статистике, владельцы большинства таких сайтов не утруждают себя дополнительной настройкой безопасности для сокрытия данных о внутренней инфраструктуре.

    Автор: Кирилл Пузанков, исследовательский центр Positive Research
    • +20
    • 15,2k
    • 7
    Positive Technologies
    167,99
    Компания
    Поделиться публикацией

    Комментарии 7

      0
      Вначале много вводной теоретической информации. А как доходит до, собственно, информации, связанной с названием статьи — всего одно предложение, без конкретики

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


      Можете более подробно описать как может произойити DoS и DDoS-атаки? И как в итоге защищаться, если, как пишете:
      Однако это не защищает от возможности DoS-атаки на определенный сервер

        +2
        Да я бы сказал наоборот, сликом много воды. Можно было в приципе статью до пары предложений ужать. Название железки, формат куки, алгоритм шифрования и отсутствие привязки к клиенту описаны. Чего ещё вам не хватает? Готового скрипта для атаки?
          0
          Ну банально жи, ну. Мастер ботнета тыкает сервис, получает куку, раздаёт по сетке команду ддосить с этой кукой. Одной на всех.
          +1
          В чем проблема атаки на конкретный узел? Если атакующий сосредоточит свои усилия на одном узле — он его, конечно положит. Только вот балансировщик, ежели это хороший балансировщик, перенаправит всех остальных пользователей на другие узлы — и получится красота: пользователи с атакующим вообще не пересекаются :)

          PS повеселило еще и вот это:
          Завершая сессии (по умолчанию они истекают при закрытии браузера) и заходя на сайт снова, мы сможем получить информацию о всех серверах пула.
          Очевидно же, что злоумышленник будет собирать информацию не браузером. В том же wget, если не предпринимать никаких мер, каждый запрос на сервер выглядит как новая сессия.
            +2
            Выносим один сервер. Балансировщик его отключает. Выносим следующий.
            Пока он выключает-включает будут простои, которые могут стоить бешеных репутационных потерь. И это еще если он их таки будет включать. А то мало ли…
            Плюс за фронтом может быть единая точка отказа. Пусть и для некоторых конкретных задач. Пусть у нас бизнес-логика такова, что фронт забирает на себя всю нагрузку, и если атакующий пытается ложить весь пул серверов, то это не страшно, а если падает один сервер, к примеру с открытой транзакцией (не обязательно средствами СУБД, может быть какой-то свой бизнес-процесс который нельзя прервать, а надо «ручками» разруливать в случае падения сервера — будет очень больно.

            Но даже просто понимание размера пула фронтов это уже подсказка атакующему — сколько стоит брать ботов в битву :)
              0
              Ну, если сервер именно что падает — тут не поможет ничего. А вот если он просто перестает отвечать на запросы (но те, которые набрал, заканчивает) — то атака будет выглядеть как периодические задержки или логауты. Оно, конечно, неприятно — но порой качество кода такое, что подобной «атаки» пользователь просто не заметит на фоне других проблем…

              Впрочем, для общедоступных сервисов ситуация резко меняется и такой вектор надо закрывать.
            +2
            итого — кука не должна быть привязана к клиенту и (что в статье упустили) к серверу.
            Т.е. для одной и той же железки куки двух разных пользователей — отличаются (hash with salt?) Это не позволяет зловреду вычислить пул серверов, а увеличение обращений по одной куке одного пользователя можно уже отследить.

            Поскольку вся статья сжалась до размера одного абзаца — требую продолжения банкета, слюна то уже выделилась. Не, реально, дайте статьи с реальными кейсами, реальными ляпами, все что бы взаправду было, а не эти рафинированные how to, коих вагон в этих ваших…

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

            Самое читаемое