Перейти к содержимому
Калькуляторы

FastNetMon - программа для выявления входящих/исходящих атак

Неа, но этого можно добиться, если проанализировать дамп трафика и сделать этот анализ скриптом.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Неа, но этого можно добиться, если проанализировать дамп трафика и сделать этот анализ скриптом.

 

Проблема заключается в том что инициацию вызова скрипта производит сам FastNetMon, соответственно если fastnetmon среагировал на атаку то повторного вызова banscript для этой атаки уже не будет. Соответственно даже если мы запустим анализатор на дамп, это ничего не даст.

Уровни срабатывания и информация об атакуемом очень нужны.

 

предлагаемый конфиг:

 

threshold_pps = 25000, 250000, 1000000,

threshold_mbps = 150, 1500, 8000,

threshold_flows = 20000, 250000, 2500000,

 

 

Алгоритм:

Зафиксировав атаку Fastnetmon продолжает отслеживать атаку, и в случае если атака переходит указанную в threshold границу - повторно вызывает скрипт с те ми же параметрами. В случае если атака снижается то происходит то же самое но в обратном порядке.

При этом:

В пятом параметре передается IP:PORT:PROTO,

В 6м параметре в бан скрипт передается достигнутый threshold.

 

К примеру pps=25000 или mbps=8000.

./ban_script 120.12.22.166 incoming 25000 ban 120.12.22.166:27125:udp 1

или

 

./ban_script 120.12.22.166 incoming 250000 ban 120.12.22.166:27125:udp 2

 

как то так... :)

 

P/S Это нужно для того чтобы срастить детектор FastNetMon с аппаратными пакетными фильтрами.

Изменено пользователем Rolex

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Очень часто получаем:

# fastnetmon
^CAssertion failed: (!posix::pthread_mutex_destroy(&m)), function ~mutex, file /usr/local/include/boost/thread/pthread/mutex.hpp, line 108.
Abort (core dumped)
root@netmon01:~ # 

после длительной работы

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Неа, но этого можно добиться, если проанализировать дамп трафика и сделать этот анализ скриптом.

велосипеды изобретаете?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ichthyandr тут люди не глупые, вроде бы с первого раза уже поняли, что велосипеды строим - http://forum.nag.ru/forum/index.php?showtopic=89703&view=findpost&p=1298319 Зачем повторяться? :)

 

Megas, специально для вас написал https://github.com/pavel-odintsov/fastnetmon/blob/master/docs/SEGFAULT_INVESTIGATION.md :) Сама по себе ошибка отладить баг не позволит точно, а вот кернел дамп с бэктрейсом - сильно больше информации :)

Изменено пользователем pavel.odintsov

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Подскажите как выключить логирование этого события

2016-08-26 15:27:12,899 [iNFO] We don't have a template for flowset_id: 512 but it's not an error if this message disappears in 5-10 seconds. We need some time to learn it!

2016-08-26 15:27:15,761 [iNFO] Received ipfix options flowset id, which is not supported

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

netflow 9 или ipfix который вы шлете - это шаблонизированный протокол, если FNM такое пишет, то значит стоит большой template timeout, поставьте раз в 30 секунд.

 

По поводу второй ошибки - я исправил ее в девелопмент ветке, https://github.com/pavel-odintsov/fastnetmon/commit/6987dc6ea62c0083ad60045018d60c37cade436d

 

Это можно сделать вот так:

wget https://raw.githubusercontent.com/pavel-odintsov/fastnetmon/master/src/fastnetmon_install.pl -Ofastnetmon_install.pl 
sudo perl fastnetmon_install.pl --use-git-master

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Спасибо за исправления.

Остро стоит с торрент клиентами, фиксирует их как атаки, уже все голову сломал что делать.

Attack type: unknown

Initial attack power: 153492 packets per second

Peak attack power: 153492 packets per second

Attack direction: incoming

Attack protocol: tcp

Total incoming traffic: 1672 mbps

Total outgoing traffic: 0 mbps

Total incoming pps: 153492 packets per second

Total outgoing pps: 0 packets per second

Total incoming flows: 0 flows per second

Total outgoing flows: 0 flows per second

Average incoming traffic: 1672 mbps

Average outgoing traffic: 0 mbps

Average incoming pps: 153492 packets per second

Безумная скорость.. у абонента 100мбит

По дампу атаки четко видно что там в основном UDP а определяет как TCP атаку.

 

Тех.данные ipfix

set services flow-monitoring version-ipfix template ipv4 flow-active-timeout 10

set services flow-monitoring version-ipfix template ipv4 flow-inactive-timeout 10

set services flow-monitoring version-ipfix template ipv4 template-refresh-rate packets 1000

set services flow-monitoring version-ipfix template ipv4 template-refresh-rate seconds 10

set services flow-monitoring version-ipfix template ipv4 option-refresh-rate packets 1000

set services flow-monitoring version-ipfix template ipv4 option-refresh-rate seconds 10

set services flow-monitoring version-ipfix template ipv4 ipv4-template

set forwarding-options sampling input rate 1

set forwarding-options sampling instance netflow input rate 1

set forwarding-options sampling instance netflow input run-length 0

 

в fastnetmon соответственно

netflow_sampling_ratio = 1

average_calculation_time = 31

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Добрый день!

 

Дублирую ответ с тикета.

 

С IPFIX сложно, потому что в нем нет никакой информации о типе пакетов. Если сможете переключиться на sflow/mirror, можно что-либо придумать. Но вот с IPFIX, не угадать, что там за трафик. Нужны слишком сложные алгоритмы для этого.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

разобрался с вашей системой, есть сработки , логи отличные. СПС за СОФТ !!!!

обновился и добавил последние плюшки

 

threshold_tcp_mbps = 100
threshold_udp_mbps = 100
threshold_icmp_mbps = 100

threshold_tcp_pps = 1000
threshold_udp_pps = 1000
threshold_icmp_pps = 1000

ban_for_tcp_bandwidth = on
ban_for_udp_bandwidth = on
ban_for_icmp_bandwidth = on

ban_for_tcp_pps = on
ban_for_udp_pps = on
ban_for_icmp_pps = on

cli_stats_file_path = /tmp/fastnetmon.dat

 

попробую прикрутить к bgp .

Изменено пользователем yazero

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

FlowSpec 2.0 - все прекрасно прикручивается и работает начиная с детектирования атак по sFlow и заканчивая финальным анонсом BGP AF flowspec провайдеру (у нас as20764/РАСКОМ) = полностью автоматическое уничтожение трафика атаки.

За 14 секунд с момента атаки уже нашему контроллеру FlowSpec уходит правило для блокировки.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Приветствую Павел. Как с предложением http://forum.nag.ru/forum/index.php?showtopic=89703&view=findpost&p=1301221 , есть сдвиги? Появилось ли время?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

FlowSpec 2.0 - все прекрасно прикручивается и работает начиная с детектирования атак по sFlow и заканчивая финальным анонсом BGP AF flowspec провайдеру (у нас as20764/РАСКОМ) = полностью автоматическое уничтожение трафика атаки.

За 14 секунд с момента атаки уже нашему контроллеру FlowSpec уходит правило для блокировки.

 

 

Спасибо за положительный фидбэк! :) Рад слышать!

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Приветствую Павел. Как с предложением http://forum.nag.ru/forum/index.php?showtopic=89703&view=findpost&p=1301221 , есть сдвиги? Появилось ли время?

 

Задача интересная, но очень сложная в логики реализации. Если точнее - она ломает подход к порогам и блок-хукам полностью. А чего-то кардинально хорошего от этого не особо ожидается. Я бы решал эту задачу специальным демоном и просто сокращал время бана до 10 секунд.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

FlowSpec 2.0 - все прекрасно прикручивается и работает начиная с детектирования атак по sFlow и заканчивая финальным анонсом BGP AF flowspec провайдеру (у нас as20764/РАСКОМ) = полностью автоматическое уничтожение трафика атаки.

За 14 секунд с момента атаки уже нашему контроллеру FlowSpec уходит правило для блокировки.

sFlow разве детектирует данные достаточные для FlowSpec?

Вроде работает решение только в связке с dpi?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

FlowSpec 2.0 - все прекрасно прикручивается и работает начиная с детектирования атак по sFlow и заканчивая финальным анонсом BGP AF flowspec провайдеру (у нас as20764/РАСКОМ) = полностью автоматическое уничтожение трафика атаки.

За 14 секунд с момента атаки уже нашему контроллеру FlowSpec уходит правило для блокировки.

sFlow разве детектирует данные достаточные для FlowSpec?

Вроде работает решение только в связке с dpi?

 

В sflow есьб все необходимое - первые 80-100 байт пакета, этого вполне достаточно для генерации качественного узко специализированного flow spec.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Т.е. я могу пробовать уходить с блэкхола на фловспек? И все взлетит из коробки или что-то надо подкрутить?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Не совсем так, но ожидать выброса флоу спека на известные амлификации явно стоит :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А тем временем Bird заявил http://trubka.network.cz/pipermail/bird-users/2016-December/010776.html о поддержке flow spec и планирует стать самым отличным решение для включения FastNetMon с поддержкой flow spec в магистрала ;)

Изменено пользователем pavel.odintsov

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Добрый день всем!

 

Поставил fastnetmon, сначала в режиме netflow, все завелось, без вопросов.

Нашел карточку Intel 29855ES, решил на ней организвать в режиме mirror (PF_RING)

Собрал PF_RING. брал с githuba,конкретно этот: https://github.com/ntop/PF_RING.git

 

Вылез странные "глюк" , а именно:

 

 

Internal traffic 0 pps 0 mbps

 

Other traffic 0 pps 0 mbps

 

Screen updated in: 0 sec 33007 microseconds

Traffic calculated in: 0 sec 2746 microseconds

Total amount of not processed packets: 110222

Packets received: 110227

Packets dropped: 0

Packets dropped: 0.0 %

 

При этом, как видно выше, пакеты в целом видет.

 

Файл /networks_list не менял, тот же что и с netflow был.

 

ниже fastnetmon.log:

2017-01-12 13:39:01,236 [iNFO] Logger initialized!

2017-01-12 13:39:01,237 [iNFO] Read configuration file

2017-01-12 13:39:01,237 [iNFO] We loaded 2 networks from networks file

2017-01-12 13:39:01,237 [iNFO] I will allocate 4096 records for subnet 3173966 cidr mask: 20

2017-01-12 13:39:01,240 [iNFO] I will allocate 256 records for subnet 11951292 cidr mask: 24

2017-01-12 13:39:01,240 [iNFO] We start total zerofication of counters

2017-01-12 13:39:01,240 [iNFO] We finished zerofication

2017-01-12 13:39:01,240 [iNFO] We loaded 2 subnets to our in-memory list of networks

2017-01-12 13:39:01,240 [iNFO] Total number of monitored hosts (total size of all networks): 4352

2017-01-12 13:39:01,241 [iNFO] PF_RING plugin started

2017-01-12 13:39:01,241 [iNFO] We selected interface:eth2

2017-01-12 13:39:01,241 [iNFO] Run banlist cleanup thread

2017-01-12 13:39:01,246 [iNFO] Successully binded to: eth2

2017-01-12 13:39:01,246 [iNFO] Device RX channels number:

2017-01-12 13:39:01,246 [iNFO] Using PF_RING v.6.5.0

 

Голову сломал, не понимаю, откуда ноги могут расти.

Буду благодарен за любой пинок :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Добрый день

 

Не рекомендую менять версию PF_RING, автоматический инсталлер ставит версию младше и с ней никаких проблем. Что-то поменяли в новой - но я не вижу особенного смысла мигрировать на нее.

 

А вообще - если ядро не 2/6/32, а что поновее - лучше используйте режим af_packet, оно на базе стандартного Linux и не требует никаких кастомных модулей а-ля PF_RING вообще :)

 

А в целом лучше спрашивать в официальной рассылке: https://groups.google.com/forum/#!forum/fastnetmon На офсайте тоже куча инфы: https://fastnetmon.com

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

А в целом лучше спрашивать в официальной рассылке: https://groups.google.com/forum/#!forum/fastnetmon На офсайте тоже куча инфы: https://fastnetmon.com

 

Спасибо, Павел, все поднял, все работает!

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Добрый день

 

Не рекомендую менять версию PF_RING, автоматический инсталлер ставит версию младше и с ней никаких проблем. Что-то поменяли в новой - но я не вижу особенного смысла мигрировать на нее.

 

А вообще - если ядро не 2/6/32, а что поновее - лучше используйте режим af_packet, оно на базе стандартного Linux и не требует никаких кастомных модулей а-ля PF_RING вообще :)

 

А в целом лучше спрашивать в официальной рассылке: https://groups.google.com/forum/#!forum/fastnetmon На офсайте тоже куча инфы: https://fastnetmon.com

Эх, Павел, выложил бы ты образ диска виртуальной машины - проблем бы не было :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.