[Из песочницы] Обнаружение DDoS-атак «на коленке»01.12.2019 18:33

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

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

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

forwarding-options {
    sampling {
        input {
            rate 2000;
            run-length 0;
        }
        family inet {
            output {
                flow-inactive-timeout 15;
                flow-active-timeout 60; 
                flow-server 10.0.0.10 {
                    port 9999;
                    autonomous-system-type origin;
                    source-address 10.0.0.1;
                    version 5;
                }
            }
        }
    }
}

interfaces {
    ae1 {
            vlan-id ...;
            family inet {
                sampling {
                    input;
                    output;
                }
                address ...
            }
    }
}

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

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

# cd /usr/ports/net-mgmt/flow-tools
# make install clean

flow_capture_enable="YES"
flow_capture_localip="10.0.0.10"  #локальный ip на который принимается поток
flow_capture_remoteip="10.0.0.1" #ip с которого льется поток
flow_capture_port="9999" #порт на который льется поток
flow_capture_datadir="/var/db/flows" #директория с файлами собранной телеметрии
flow_capture_flags="-z0 -n1439 -N3 -E10G -e0 -S1" #параметры

Из всего набора утилит 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 доступен на GitHub

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

[REPORTS]
sdport_flows
dport_packets
flows
packets

# Reports(rules) options 
# threshold - threshold value
# key_field - report field index number to which the threshold applies 
# filter - name of a filter described in FiltersFileName
[sdport_flows]
threshold = 300
key_field = 4
filter = white-list

[dport_packets]
threshold = 3000
key_field = 3
filter = white-list

[flows]
threshold = 2000
key_field = 2
filter = white-list

[packets]
threshold = 5000
key_field = 2
filter = white-list

[FILES]
# Dir with flow-tools binary files
FlowToolsBinDir = /usr/local/bin/
# Dir with Whois, AWK binary files
SysBinDir = /usr/bin/
FlowsDir = /var/db/flows/
ReportsFileName = reports.cfg
FiltersFileName = filters.cfg

[EMAIL]
SMTPServer = localhost
# 0-default port
SMTPPort = 0 
MailFrom = mail@example.com
MailTo = mail@example.com
Subject = [DDoS Detect]
# Amount of flow-print records in an email
FlowPrintTail = 50
# Use TLS (if True, Auth must be the same)
Secure = False
# Use Login and Password
Auth = False
# Notification Frequency about current DDoS attack - every value minutes
# if 0 - don't send email, print victims ip to stdout 
NotifyFreq = 5

# Act if Auth = True
[EMAIL-AUTH]
Login = ...
Password = ...

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

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

Еще раз ссылка на GitHub

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

© Habrahabr.ru