[tururu]

Сорри, все запустилось.

Падало из-за пустой строки в конце /etc/networks_list

Cоберу не на виртуалке, а на сервере, на который собираю трафик и проверю MPLS

[pavel.odintsov]

А вы сети свои в CIDR формате прописали в файлик /etc/networks_list - каждая сеть на отдельной строке ?

 

Update: прочитал сообщение выше :)

Изменено 2 октября, 2014 пользователем pavel.odintsov

[tururu]

А вы сети свои в CIDR формате прописали в файлик /etc/networks_list - каждая сеть на отдельной строке ?

 

Update: прочитал сообщение выше :)

 

сорри, вчера мне форум не дал отписаться (лимит три сообщения в день)

поставил все на сервер, заработало :)

 

Павел, еще раз спасибо за софт и отличный мануал по его установке.

мплс трафик нормально раскрывается.

[pavel.odintsov]

Вам спасибо, что пользуетесь! :)

[pavel.odintsov]

Кстати, в процессе небольшого исследования написал простенький анализатор числа запросов каждого домена с DNS сервера, работает на базе pcap и написан на Go, на потоке около 1000 rps справился на ура. Нужно кому? :)

[pavel.odintsov]

Всем привет!

 

По просьбам трудящихся добавил поддержку возможности блокировки трафика посредством Intel 82599 hardware filters: https://github.com/FastVPSEestiOu/fastnetmon/commit/9ba0d43e6610c68354a2abbacce4d7a054498f48

 

То есть, если нету аплинка с BGP blackhole, то можно без проблем отсечь до 9+ гигабит трафика на почти любом pps силами сетевой карты.

 

Чтобы собрать нужно похачить Makefile:

fastnetmon.o: fastnetmon.cpp
-       $(COMPILER) $(STATIC) $(DEFINES) $(HEADERS) -c fastnetmon.cpp -o fastnetmon.o $(BUILD_FLAGS)
+       $(COMPILER) $(STATIC) $(DEFINES) $(HEADERS) -c fastnetmon.cpp -o fastnetmon.o $(BUILD_FLAGS) -DHWFILTER_LOCKING

[pavel.odintsov]

Всем привет!

 

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

[pavel.odintsov]

Сорри, все запустилось.

Падало из-за пустой строки в конце /etc/networks_list

Cоберу не на виртуалке, а на сервере, на который собираю трафик и проверю MPLS

 

Бажку с пустой строкой починил: https://github.com/FastVPSEestiOu/fastnetmon/commit/d7a13420675dd92e377b74bcd1b5d7a17ef2f5d8 теперь падать не будет :)

[pavel.odintsov]

Всем привет!

 

В Git лежит версия с расчетом числа flow для каждого IP в сети:

 

Также можно сортировать по flow, а также фиксом одной строки можно банить по flow.

 

В чем профит flow режима? Очень хорошо видно всякие флудеры, сканеры сети и прочее - нормальный трафик (кроме торрента) всплесков не генерирует. Ну и атаки постфактум анализировать решительно проще - сразу вижно аггрегированые потоки куда-откуда и можно легко фильтровать, например, просто высокскоростные загрузки файлов внутри сети.

[Rolex]

Павел, благодаю за проделанную работу. Сейчас тестируем у себя Вашу разработку.

Есть несколько пожеланий в конфиг:

1) Направление потока трафика при использовании утилиты методом зеркалирования порта. Есть случаи применения когда входящий трафик в реальности исходящий и наоборот (снятие статистики с коммутатора уровня распределения);

2) Опция бана. Банить только в случае входящей атаки или только в случае исходящей атаки или в обе стороны (default). Применимо в случае использования системы на высоконагруженных сетях;

3) Время реакции на атаку в секундах. 0- default. Как быстро реагировать на атаку. В некоторых случаях, реакция системы фильтрации может быть замедленной. Соответственно кратковременная атака уже закончится к моменту реакции и смысл выставления бана уже будет утерян;

4) Трафик с учетом семплирования. Один к одному или один к ста к примеру. На некоторых устройствах (Juniper Ex4550) есть возможность зеркалировать не весь трафик а только его часть в значениях 1 к 10 или 1 к 1000 или больше, что позволяет значительно экономить на производительности сервера где запущена утилита.

 

Ну и соответственно для разработки интерфейса мониторинга, требуется что то типа вывода данных в виде некоего API. Как вариант на http запрос по 7767 tcp порту отдать некий json.

 

 

P/S Чем помочь в разработке?

Изменено 25 ноября, 2014 пользователем Rolex

[pavel.odintsov]

Павел, благодаю за проделанную работу. Сейчас тестируем у себя Вашу разработку.

Есть несколько пожеланий в конфиг:

1) Направление потока трафика при использовании утилиты методом зеркалирования порта. Есть случаи применения когда входящий трафик в реальности исходящий и наоборот (снятие статистики с коммутатора уровня распределения);

2) Опция бана. Банить только в случае входящей атаки или только в случае исходящей атаки или в обе стороны (default). Применимо в случае использования системы на высоконагруженных сетях;

3) Время реакции на атаку в секундах. 0- default. Как быстро реагировать на атаку. В некоторых случаях, реакция системы фильтрации может быть замедленной. Соответственно кратковременная атака уже закончится к моменту реакции и смысл выставления бана уже будет утерян;

4) Трафик с учетом семплирования. Один к одному или один к ста к примеру. На некоторых устройствах (Juniper Ex4550) есть возможность зеркалировать не весь трафик а только его часть в значениях 1 к 10 или 1 к 1000 или больше, что позволяет значительно экономить на производительности сервера где запущена утилита.

 

Ну и соответственно для разработки интерфейса мониторинга, требуется что то типа вывода данных в виде некоего API. Как вариант на http запрос по 7767 tcp порту отдать некий json.

 

 

P/S Чем помочь в разработке?

Вечер добрый!

 

Спасибо за интерес! Отвечаю по пунктам:

 

1) Так как постоянно работал с mirror портами я полностью убрал определение направления трафика стандартными средствами и определяю направления делая проверку принадлежности блоку сетей, который прошу вбивать в конфиг. Это довольно быстро, так как используется Patricia Trie.

2) Была такая мысль, но вот с отраженными атаками (когда на _каждый_ пакет извне машина внутри сети отвечает ровно таким же числом пакетов, а трафик в направлении вовне - выходит даже больше) почти невозможно понять откуда атака шла - снаружи или изнутри. Хоть у меня и стоит определитель направления атаки в виде "от кого больше пакетов, тот и виноват", но это далеко не всегда срабатывает. Есть вариант сделать эвристику, скажем, если трафика в одном направлении в 10 раз больше, то это точно входящая/исходящая, но тогда будет еще вариант "incoming возможно" / "outgoing возможно" / "не понятно вообще".

3) Больной и сложный вопрос, у меня поддерживается точное число пакетов лишь за последнюю секунду, хранить вектор хотя бы за последнюю минуту - очень большой объем данных. Потенциально, можно хранить еще за последние 1 секунды / 10 секунд / 60 секунд и поправлять их каждые . По аналогии с load average в Linux.

4) В принципе коэффициент сэмплирования я могу ввести, но он будет для всех одинаковый в случае варианта с mirro'ингом. А вот если цеплять sFLOW, то можно будет с каждой цели брать разный sampling rate и с учетом этого строить графики

5) API. Давно-давно хочу, заодно и вынести его отдельным демоном, а не позориться с запуском в скрине. А что хочется от API? В принципе можно дергать top10/100 грузящих узлов с указанием pps/бандвича/flow, потенциально можно вообще весь трафик выгружать + банлисты.

 

Помочь можно в первую очередь тестами :) Железа у меня не так много и нагрузки не особо большие.

[Megas]

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

изменение кол пакетов взависимости от времени суток.

можно еще подумать.

Изменено 25 ноября, 2014 пользователем Megas

[pavel.odintsov]

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

изменение кол пакетов взависимости от времени суток.

можно еще подумать.

 

Определять атаку по неожиданному всплеску трафика или что? Не совсем понял суть :(

[Rolex]

<CUT> и определяю направления делая проверку принадлежности блоку сетей, который прошу вбивать в конфиг.

В таком случае, в последней версии наблюдаю инверсию (Входящий есть в реальности Исходящий). Прошу проверить. (У меня вылечилось простой заменой слов Incoming на Outgoing и наоборот с последующим его make clean && make).

 

2) Остаются только варианты с исключениями определенных IP адресов из банлиста (белый список) или индивидуальным указанием tresholds для некоторых IP адресов (что скорее всего прилично увеличит время анализа). Просто в сети может быть некий ресурс генератор, у которого трафик в 5 гбит и 250кpps является нормой.

 

3) Попробую описать алгоритм. В случае обнаружения (по порогам) атаки на определенный IP выставляем таймер с истечением через 5 (время отсрочки бана) секунд. (можно еще выставить статус warning для этого IP для отображения) В случае если за этот период значения трафика всегда превышают значения порогов, выставляем бан. В случае если значения вернулись в норму (ниже порогов) обнуляем таймер. Городить огород с накоплением данных и прочего, имхо действительно не имеет смысла. Кстати эта же функция сгладит вероятность ошибочных срабатываний для ресурсов находящихся на грани порогов. (получится некая пародия на гистерезис)

 

4) несколько не уловил суть Вашего ответа. Я имел ввиду лишь простейшее умножение полученных счетчиков на коэффициент семплирования при расчетах и отображении. Если коммутатор отправляет в зеркало каждый десятый пакет, то мы можем приблизительно получить общий объем трафика простым умножением счетчиков на 10. Да, точность конечно теряется, но и увеличивается производительность анализа в реальном времени аж в 10 раз. Ну а в случае больших атак +- 1 гбит учтенного или не учтенного трафа погоды особо не делает, ибо атака в любом случае будет видна.

 

5) Вижу несколько вариантов. Какой уж предпочтительней даже и не знаю. Первый вариант это городить велосипед с собственным веб сервером и причитающимися ему в таком случае дырками и прочими радостями компиляции сборки и прочего. Второй вариант это использование какого либо промежуточного буфера, например Redis или memcache и использование стандартных уже разработанных ранее средств. Иначе говоря, вся информация которую имеет смысл отобразить пользователю на экран сбрасывается в memcached с временем жизни 30 сек и периодичностью заданной в настройках. (структуру данных можно продумать включая top10/100 , банлист и т.д.). Далее, уже с этими данными можно работать стандартными методами. К примеру пишем перловый скрипт который лазает в мемкеш и дергает оттуда все что ему надо раз в секунду и кажет на экран. Захотелось прикрутить вебморду - не проблема, другой скриптик выводит данные из мемкеша через CGI в веб. Захотелось собрать несколько серверов детекторов в одну сеть - не проблема, просто опрашиваем мемкеши этих детекторов. Захотелось вывести банлист в нагиос - тоже не проблема. Аддон для нагиоса дело 10 минут. Это же позволит в будущем разделить роли сборщика данных и их анализатора.

 

Управление же демоном можно выполнить посредством приема какого либо сигнала, к примеру $SIG{HUP}, обработав который можно обнулить все счетчики, таймеры, переменные, файловые дескрипторы и пр. ну и перечитать конфиг файл на предмет новых инструкций/параметров. Этот же HUP можно выполнять по крону например 1 раз в сутки для полной автономии.

 

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

Изменено 25 ноября, 2014 пользователем Rolex

[Megas]

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

изменение кол пакетов взависимости от времени суток.

можно еще подумать.

 

Определять атаку по неожиданному всплеску трафика или что? Не совсем понял суть :(

 

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

Также вот еще пример: идет веб скачивание трафика, приходит отчет, но смысл его смотреть и присылать если исходящий порт 80й, размер пакета 1500байт, порт назначения рандом, ip назначения одинаковый.

Для таких моментов нужно иметь возможность добавлять определенное описание правил при котором утилита не будет срабатывать...

 

А теперь дальше:

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

 

Основная задумка API нужна как раз:

1. получение статистики, чтобы можно было направить все это в систему мониторинга.

2. Добавление, удаление сетей для мониторинга.

3. Добавление и удаление белых ip

4. Добавление и удаление IP к которым применяется отдельный набор правил.

5. Возможность динамических добавлений и удалений правил (как описал выше пример с 80м портом).

6. Вот аномальный трафик: с 53го udp на 123й udp, такого трафика быть не должно, но при атаках он бывает (зависит от типа атаки), я бы вывел такие моменты опять же в отельный набор правил и применял их к мониторящим групам.

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

 

Надеюсь вы найдете для себя что-то из этого списка что будет интересно для реализации.

 

Rolex, использование сигналов весело, но от сигналов нет обратного ответа, вы не можете проверить его успешность (на сколько помню про сигналы), по этой причине, проще работать с другими методами.

 

Было бы не плохо, если для загрузки или выгрузки подсетей применять json, тогда можно унифицировать платформу для общения системы.

[Rolex]

<CUT>по этой причине, проще работать с другими методами.

.

Ну HUP нужен в любом случае, если утилита сама по себе требует периодического рестарта для очистки буферов.

 

К вопросу об API. Со сбором консолидированных данных о трафике понятно. Его вид, и структура - дело уже реализации. Вы уверены что есть необходимость управлять утилитой динамически? Это ведь значительно усложнит утилиту и снизит скорость ее работы. Иначе говоря, как часто вы собираетесь добавлять или удалять сети, белые списки, наборы правил и прочего? Опять таки, систему эвристического анализа структуры трафика трафика от этой утилиты имхо требовать смысла нет. Ее задача обнаружение атаки и блокировка, причем не источников а адресата. Для глубокого анализа трафика и прочего прочего, есть сложные коммерческие реализации типа этого (http://www.andrisoft...ard/web-console)

 

 

P/S Фиксирую баг:

При обнаружении атаки приходят 2 письма. Одно с уведомлением об атаке и статистикой в 500 строк (настройка в конфиге). А второе же письмо с более масштабными данными аж на несколько тысяч строк. Оба письма обрабатываются внешним sh скриптом который вызывается с action=ban. В почтовом клиенте такое письмо открывать получается накладно.

 

Варианты решения:

1) распространить влияние параметра ban_details_records_count на второе письмо тоже.

2) вызывать внешний скрипт при отправке второго письма со значением в параметре 4 = 'stat' (итого получится ban, unban, stat). Что позволит отключить отправку полной статистики при необходимости.

3) складывать подробные данные статистики атаки в текстовичок отдельную папку вида /папка архива/атакованный IP.txt (путь к папке вынести в конфиг)

4) дефолтный скрипт отправщик сделать ну примерно таким:

 

--------------------------------------------------------

 

#!/bin/bash

 

# $1 client_ip_as_string

# $2 data_direction

# $3 pps_as_string

# $4 action (ban, unban, stat)

 

emails=" email_for_recieve@info.com"

 

 

 

# Unban actions if used

if [ "$4" = "unban" ]; then....

echo "FastNetMon Guard: IP $1 unblocked." | mail -s "IP $1 unblocked by timeout 30 mins." $emails;

exit 0

fi

 

 

# ban actions if used

if [ "$4" = "ban" ]; then

cat | mail -s "FastNetMon Guard: IP $1 blocked because $2 attack with power $3 pps" $emails;

exit 0

fi

 

# stat actions if used

if [ "$4" = "stat" ]; then

cat | mail -s "FastNetMon Guard: Detail packet stat of attack for IP $1" $emails;

exit 0

fi

#--------------------------------------------------------------

 

 

PP/S Уведомление по почте об выемке из бана следует выполнять без cat | так как утилита при этом не выдает ничего на stdout и процесс cat подвисает до завершения работы устилиты. (см выше.)

Изменено 26 ноября, 2014 пользователем Rolex

[pavel.odintsov]

Приветствую!

 

Реалищовал то, что многие давно хотели! наконец-то интегрировал возможность указать время, которое должна держаться заданная сила атаки, чтобы сработал бан. То есть теперь можно задать, например, 15 секунд, чтобы держался пороговый pps и лишь при этом сработает бан.

 

Чтобы не убить машину и память вычислениями воспользовался вот этим алгоритмом moving average: http://en.wikipedia.org/wiki/Moving_average#Application_to_measuring_computer_performance он работает без хранения всех отсчетов и всегда поддерживает значение "средняя скорость за XX секунд".

 

Пока сделал лишь отображение средней скорости в мониторе, активируется следующей переменной: bool print_average_traffic_counts = true; (стандартно оно false)

 

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

 

По поводу остальных фич отпишусь скоро, мне нужно некоторое время все обдумать.

 

ОГРОМНОЕ спасибо за фидбэк :)

Изменено 28 ноября, 2014 пользователем pavel.odintsov

[Rolex]

Собрали, включили. Работает. Ошибка с направлениями исчезла. Я так понимаю double average_calculation_amount = 15; - это по сути время интеграции в секундах. Верно ?

 

По результатам наблюдений дам знать.

 

P/S для упрощения себе расчетов установил в 5 сек.

 

 

 

[pavel.odintsov]

Да, это интервал за который выполняется расчет средней скорости. Единственное, он себя может не адекватно повести, если программу запустить когда атака уже идет или был всплеск трафика, он довольно быстро взлетит до максимума и усреднение будет не особо хорошее. В принципе это можно решить блокировкой бана первые 15 секунд работы программы, чтобы накопились даннные. Но это так, не баг, просто не стоит злоупотреблять с рестартами)

[Rolex]

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

Это не баг, это фича. Чем мощнее атака, тем быстрее будет блокировка. ;)

 

Работает точно. Пока вопросов к счетчикам не возникает. Продолжаем наблюдение.

 

 

 

[pavel.odintsov]

Супер! Жду тестов :)

 

Попутно перетащил систему на cmake и теперь не должно быть траблов из-за постоянно разных путей до библиотек на разных дистрибутивах.

 

Кому не сложно, можно попробовать собирать вот так:

apt-get install cmake
yum install cmake
cd /usr/src
git clone https://github.com/FastVPSEestiOu/fastnetmon.git
cd fastnetmon
mkdir build
cd build
cmake ..
make

[pavel.odintsov]

Также сделал фикс, чтобы в случае син флуда и прочей радости на десятки тысяч flow не приходили огромные дампы. Теперь они также лимитируются 500 строчками. В будущем сделаю сортировку от самого активного потока до менее активных.

[Rolex]

Также сделал фикс, чтобы в случае син флуда и прочей радости на десятки тысяч flow не приходили огромные дампы. Теперь они также лимитируются 500 строчками. В будущем сделаю сортировку от самого активного потока до менее активных.

Супер. То что нужно. Спасибо огромное. Собрали, запустили, ждем'с...

 

Пожелания (хотелки):

1) В строку вызова скрипта бана помимо pps передавать bps и fps разными переменными, чтобы можно было настроить различные реакции на разные атаки. К примеру на атаки малой мощности - обычная фильтрация. На большие атаки - выставлять blackhole BGP community.

2) Функция повторного вызова банлиста. Может быть полезно в случае если в силу каких то причин блокировка не произошла. Иначе говоря, если в течении некоего периода ( задается в конфиг. файле ) атака не прекратилась (или сработал бан) повторно вызвать скрипт бан и т.д. в цикле. Конечно вызывать его с новыми параметрами атаки.

 

 

PP/S По моим наблюдением алгоритм среднего работает четко, во всяком случае в рамках допустимых погрешностей (10 сек). Имхо можно выкладывать в основу. Но правда только с выносом параметров настройки времени в конфиг.

Изменено 1 декабря, 2014 пользователем Rolex

[pavel.odintsov]

Хай!

 

• 
   
  
• Добавил возможность включать/выключать бан по каждому из критериев - мегабиты, pps, flows.
  
• Добавил поддержку sFLOW, теперь можно фиксировать атаки хоть в 100 гигабит без особой нагрузки на железо.
  
• Внедрил модульный интерфейс, на базе которого работает sFLOW, в принципе в скором времени все станет плагинами.
  
• Время усреднения полосы вынес в конфиг, но бан пока как и прежде осуществляется по мгновенной скорости, хочу еще тестов провести.
  

 

Все фиксы в fastnetmon.conf в репо.

 

По поводу передачи fps/pps/bps в скрипт - я подумаю. По поводу повторного вызова... В принципе оно так и сработает, достаточно настроить бан таймаут.

 

Сделайте вот это число поменьше, тогда оно сможет забанить заново и это даст нужный эффект.

// Standard ban time in seconds for all attacks but you can tune this value
int standard_ban_time = 1800;

[Rolex]

Собрал через cmake. Действительно удобно.

Повторный вызов нужен не зависимо от unban. Иначе говоря если зададим время бана - то система сначала вытащит из бана и только затем засунет обратно в бан. Что не есть гуд.

пример: Атака 1mpps.

Можем зафильтровать своими силами. Дергаем бан скрипт которому передаем параметр атаки. Тот, видя что атака в пределах возможностей самостоятельной фильтрации, отдает команду на рероутинг этого IP на фильтр. Атака идет, однако ущерба хосту не наносит.

Через сколько то секунд атака увеличивается до 15mpps:

Такое предположим обработать сами уже не получается. Соответственно повторно вызываем бан скрипт где опять передаем объем атаки: Тот, видя что атака уже вне пределов самостоятельной фильтрации, отдает команду на блекхол этого IP выставляя BGP комьюнити.

Завершение атаки: по таймауту (standard_ban_time = 1800) вызываем скрипт с параметром unban, Который в свою очередь снимает рероутинг и комьюнити с этого IP.

 

 

Вот как то так.

 

P/S Фиксирую баг.

 

При использовании следующих параметров настройки:

 

ban_for_pps = on

ban_for_bandwidth = on

ban_for_flows = on

threshold_pps = 20000

threshold_mbps = 1000

ban_threshold_flows = 5000

 

Получил в бане всех и вся по flows.

При изменении параметра ban_threshold_flows = 5000 на threshold_flows = 5000 получил дефолтное значение в 3500, работает корректно.

Полагаю ошибка в указании параметра в конфиге или обработке конфига.

 

 

Изменено 3 декабря, 2014 пользователем Rolex