Статья Обнаружение DDoS-атак «на коленке»

  • Автор темы Firewoll
  • Дата начала
  • Ответы 1
  • Просмотры 246

Firewoll

Просто, ваш повелитель😈
Местный

Firewoll

Просто, ваш повелитель😈
Местный

Я работаю в небольшом интернет провайдере масштаба области. У нас транзитная сеть (это значит, что мы покупаем интернет у богатых провайдеров и продаем его бедным). Несмотря на небольшое количество клиентов и такое же небольшое количество трафика протекающего по нашей сети, довольно часто приходится иметь дело с весьма внушительными DDoS-атаками по 10-20Гбит/с. (чаще всего конечно это атаки гораздо меньшего калибра). И хотя некоторые из наших клиентов обзавелись уже системами обнаружения таких атак и могут самостоятельно отправить жертву в блек-холл, гораздо чаще обнаружение атаки и бан конкретного IP жертвы ложится на наши плечи (тем более, если атака способна забить наши внешние каналы).



О решении, которое помогает обнаруживать эти самые атаки и которое принято у нас в сети, я и хотел бы рассказать. Оно бесплатно, основывается на анализе данных NetFlow, поэтому просто и весьма эффективно.
На самом деле систем для обнаружения Ddos-атак основанных на анализе данных протоколов NetFlow/SFlow/IPFIX существует довольно много (вероятно почти все?). В первом приближении, суть всех таких систем сводится к установлению порогов по количеству пакетов/потоков/октетов на определенный тип трафика к конкретному IP, при превышении которого система сигнализирует о возможной атаке. И наше решение ничем от них в этом плане не отличается. Однако, основная проблема – большинство из них платные. А бесплатные версии предлагают довольно грубый анализ, который часто неэффективен (к примеру, позволяет устанавливать порог только на весь трафик к конкретному IP, без его предварительной фильтрации, что в случае анализа транзитного трафика почти всегда бесполезно).

Итак, сперва необходимо настроить протокол NetFlow на сетевом оборудовании с минимально возможным active timeout (интервал с котором экспортируются данные с оборудования на коллектор) — это 60с для Cisco и Juniper.

Настраиваем Netflow на маршрутизаторе

Далее, нам необходимо настроить NetFlow коллектор, который будет собирать данные статистики с оборудования.

В качестве коллектора решено было использовать многим знакомый flow-capture из набора утилит flow-tools. Именно набор утилит, который позволяет строить разнообразные и подробные отчеты на основе собранной статистики является главным достоинством этого пакета. (К слову в наборе утилит также есть и flow-dscan для обнаружения сканирования хостов/портов и другой нежелательной активности). В недостатки можно записать отсутствие веб-оболочки и отсутствие поддержки 9й версии NetFlow. Однако, повторюсь, гибкость таких утилит как flow-nfilter, flow-report и, конечно же, свободное распространение с легкостью все перекрывают.

Настраиваем flow-tools на сервере

Из всего набора утилит flow-tools нас будут интересовать три:

  1. Flow-nfilter – позволяет фильтровать статистику по таким параметрам как ip адрес/протокол/порт. Нам она нужна будет для своеобразного белого списка IP, которые нужно исключить из проверки. Например, ip-адреса гугл-кэш серверов в вашей сети (или любых других кэшей), где достаточно высокий поток трафика может ложно сигнализировать о ддос-атаке. Создадим файл filters.cfg с фильтром (ip-адреса для примера):

    filter-primitive white-list-ip
    type ip-address-prefix
    deny 8.8.8.8
    deny 64.233.160.0/19
    default permit

    filter-definition white-list
    match ip-destination-address white-list-ip
    match ip-source-address white-list-ip


  2. Flow-report – утилита позволяющая строить отчеты, группируя трафик и сортируя данные по заданным параметрам. Чем-то похожа на функцию Groups By в SQL. Типов отчетов, которые она может сгенерировать множество (многие из них могут быть полезны для Traffic Engineering). Нас интересуют следующие:
    • ip-destination-address/ip-source/destination-port – группировка потоков, как не сложно догадаться, по ip-destination адресу, source/dest порту. Это значит, что будут объединены все потоки с одинаковыми ip-destination-address & ip-source & destination-port и представлены в отчете в отсортированном порядке, например, по потокам или пакетам (если конечно эту сортировку задать). Такого рода отчет позволит выявить так называемые DDoS-атаки с отражением на какой-нибудь сервис. К примеру, если зафиксировано аномально большое количество потоков с порта 53 на порт 80 какого-нибудь хоста, можно говорить о возможной атаке. Это удобно, так как в большинстве случаев такого рода потоков немного, и при правильно настроенном пороге можно выявить атаку даже с минимальным результирующим трафиком. Для того что бы задать отчет, нужно создать файл с его описанием. Создадим файл reports.cfg:

      stat-report sdport_flows
      type ip-destination-address/ip-source/destination-port
      output
      format ascii
      options -header,-xheader,-totals,-names
      fields +flows,-octets,-packets,-duration
      sort +flows

      stat-definition sdport_flows
      report sdport_flows


    • ip-destination-address/ip-destination-port – более грубая группировка, учитывающая только два параметра. Но работать она будет по пакетам. Добавим в созданный файл reports.cfg:
      stat-report dport_packets
      type ip-destination-address/ip-destination-port
      output
      format ascii
      options -header,-xheader,-totals,-names
      fields -flows,-octets,+packets,-duration
      sort +packets

      stat-definition dport_packets
      report dport_packets


    • ip-destination-address – и самая грубая группировка по результирующему трафику на конкретный ip. Здесь мы создадим два отчета по потокам и по пакетам.
      stat-report flows
      type ip-destination-address
      output
      format ascii
      options -header,-xheader,-totals,-names
      fields +flows,-octets,-packets,-duration
      sort +flows

      stat-definition flows
      report flows

      stat-report packets
      type ip-destination-address
      output
      format ascii
      options -header,-xheader,-totals,-names
      fields -flows,-octets,+packets,-duration
      sort +packets

      stat-definition packets
      report packets

  3. Flow-print – позволяет отобразить собранную телеметрию.

Результирующий скрипт (Python 3) с установленными порогами для каждого отчета будет анализировать собранную телеметрию и в случае обнаружения атаки (то есть превышения порога для отчета), сбрасывать письмо на почту с расшифровкой трафика на IP жертвы за данную минуту.

Код скрипта я приводить не буду, он с файлами filters.cfg и reports.сfg доступен на
Пожалуйста , Вход или Регистрация чтобы увидеть ссылку!


Для его работы достаточно сконфигурировать некоторые параметры в config.ini. И добавить его в крон на исполнение в каждую минуту.

Настраиваем config.ini

Письмо с уведомлением об атаке выглядит так:



Скрипт позволяет добавлять/убирать свои отчеты по которым будет происходить анализ трафика, задавать для каждого отчета свой фильтр из файла filters.cfg, менять частоту уведомлений для текущей DDoS-атаки. Позволяет также вывести список атакуемых IP на stdout, не отправляя письмо.

Еще раз ссылка на
Пожалуйста , Вход или Регистрация чтобы увидеть ссылку!


Вот собственно и все. Спасибо за внимание!
 
Сверху Снизу