- PVSM.RU - https://www.pvsm.ru -
Приветствую! Я работаю в небольшом интернет провайдере масштаба области. У нас транзитная сеть (это значит, что мы покупаем интернет у богатых провайдеров и продаем его бедным). Несмотря на небольшое количество клиентов и такое же небольшое количество трафика протекающего по нашей сети, довольно часто приходится иметь дело с весьма внушительными 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;
}
}
}
}
}
Здесь:
Затем вешаем его на интерфейсы, где будем собирать статистику (как минимум это должны быть uplink интерфейсы):
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
Добавляем в /etc/rc.conf:
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" #параметры
Здесь:
-z0 – сжатие файлов (0 — выключено)
-n1439 – количество файлов, которое создаст коллектор в сутки. По умолчанию 95 – это один файл в 15 минут. 1439 – максимальное значение — это один файл в минуту. Нам необходимо, чтобы файлики создавались как можно быстрее.
-N3 – это уровень вложенности файлов и папок (YYYY/YYYY-MM/YYYY-MM-DD/flow-file)
-E10G – ограничение на занимаемое пространство на диске. Будет удалять старые файлы таким образом, чтобы общий объем файлов с телеметрией был менее этого числа. Очень полезная штука, жаль не подчищает созданные директории.
-e0 – тоже самое только про количество файлов (0 – не следить)
-S1 – логировать каждую минуту сообщение о полученных/потерянных/обработанных потоках
Из всего набора утилит flow-tools нас будут интересовать три:
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
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
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
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
Результирующий скрипт (Python 3) с установленными порогами для каждого отчета будет анализировать собранную телеметрию и в случае обнаружения атаки (то есть превышения порога для отчета), сбрасывать письмо на почту с расшифровкой трафика на IP жертвы за данную минуту.
Код скрипта я приводить не буду, он с файлами filters.cfg и reports.сfg доступен на GitHub [1]
Для его работы достаточно сконфигурировать некоторые параметры в 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 [1]
Вот собственно и все. Спасибо за внимание!
Автор: Евгений Колосов
Источник [2]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/python/338460
Ссылки в тексте:
[1] GitHub: https://github.com/owenear/ddos-detect
[2] Источник: https://habr.com/ru/post/478238/?utm_source=habrahabr&utm_medium=rss&utm_campaign=478238
Нажмите здесь для печати.