Мониторинг трафика и реагирование на утечку
-
Здравствуйте.
Зародилась идея предотвращения утечки путем отслеживания трафика по ip и при резком скачке трафика до определенного порога оповещать/блокировать интерфейс/машину (скрипты наше все) для предотвращения дальнейшей предполагаемой утечки.
На ум приходит ntopng, только не понятно, надо толи как то в лог все писать то ли слать поток (для этого есть спланк, собственно через него и планирую мониторить/выполнять скрипты).
У кого есть какие идеи?
Заранее спасибо! Надеюсь тема очень актуальная и решение где-то на поверхности. -
@borg Пусть меня поправят, но не справятся ли с этим Snort\Suricata? Не совсем то, что вы описываете, но на подозрительную активность реагируют.
Есть в стандартных пакетах. -
Знаем, настроена, ловит по стандартным правилам+свои. Но смысл чтобы разбирать трафик, желательно потоково с возможностью безграничной аналитики, а не той что зашита в функционал пакетов
Что то мне подсказывает что softflowd, то что я ищу, но не могу сростить мозгами -
@borg Доброе утро
Если есть дружба со скриптами , то можно рассмотреть вариант связки
netgraph модуля ng_netflow ( https://www.freebsd.org/cgi/man.cgi?query=ng_netflow) , который будет выступать в качестве сенсора + ,например, nfdump ( http://nfdump.sourceforge.net/ ) , который будет выступать в качестве коллектора и анализатора
А дальше можно парсить файлы коллектора и получать нужную Вам аналитикуили , как вариант, использовать в качестве коллектора flow-tools
Небольшая ложка дегтя
Модуль ng_netflow не встроен в ядро PF , поэтому его надо компилировать самому ( Если надо , напишите в личку куда прислать , я его Вам пришлю)В инете можно найти много информации , как реализовать такую схему
https://yandex.ru/search/?text=ng_netflow&lr=213
https://habr.com/ru/post/127613/
https://yandex.ru/search/?text=nfdump&lr=213
https://www.info-x.org/freebsd/nastroika/podschet_trafika_s_pomoshchyu_ng_netflow.html
http://www.asmodeus.com.ua/library/os/freebsd/netgraph_ng_netflow/netgraph_ng_netflow.html
-
@Konstanti Спасибо за подсказки. Я правильно понимаю что нужно использовать например вот такую схему https://github.com/hoprocker/pfsense-nfsen и описаные здесь шаги https://forums.freebsd.org/threads/howto-monitor-network-traffic-with-netflow-nfdump-nfsen-on-freebsd.49724/ ?
-
Практически реализовал то что требовалось при помощи ntopng)
Для этого для каждого интерфейса, модифицировал get_flows_data.lua
В скрипте есть фильтр на количество переданного в flow трафика:local find_bytes = round(value["bytes"]/1024/1024, 2) -- перевод в мегабайты if find_bytes < 1 then -- если меньше 1 МБ break return false end
Далее уже разбираю в спланке:
https://splunk:8000/en-US/manager/search/adddatamethods/selectsource?input_type=rest&modinput=1&input_mode=1REST API Input Name - ntopng_flows_igb1 (произвольное имя) Endpoint URL - https://pfsense_ip:3000/lua/get_flows_data_igb1.lua HTTP Method - GET Authentication Type - Basic Authentication User - ntop_user Authentication Password - ntop_user_password Response Type - _json Response Handler - ExampleHandler Polling Interval - 10 (интервал опроса) Set sourcetype - Manual Source type - _json Host field value - pfsense (как угодно, для идентификации, откуда приходят логи) Index - flow (ваш заранее созданный индекс)
Для того чтобы данные не обрезались, добавляем в /opt/splunk/etc/system/local/props.conf
[source::rest://ntopng_flows_igb1]TRUNCATE = 0
Внимание! Для того чтобы правила разбора подействовали после изменения props.conf, необходимо перезагрузить спланк (можно через Server controls)
Запрос в спланке:
index="flow" | dedup key | eval fields=split(bytes," ") | eval num=mvindex(fields,0) | eval str=mvindex(fields,1) | eval bytes_new = round(bytes_new/1024/1024,2) | eval cli2srv_bytes_full = round(cli2srv_bytes_full/1024/1024,2) | eval srv2cli_bytes_full = round(srv2cli_bytes_full/1024/1024,2) | eval new_time=strftime(_time, "%d/%m/%Y %H:%M:%S") | eval subtotal_bytes = 0 | eval subtotal_cli2srv_bytes = 0 | eval subtotal_srv2cli_bytes = 0 | foreach server_name [ | eval subtotal_bytes = subtotal_bytes + bytes_new] | foreach server_name [ | eval subtotal_cli2srv_bytes = subtotal_cli2srv_bytes + cli2srv_bytes_full] | foreach server_name [ | eval subtotal_srv2cli_bytes = subtotal_srv2cli_bytes + srv2cli_bytes_full] | eventstats sum(subtotal_bytes) as TOTAL_bytes sum(subtotal_cli2srv_bytes) as TOTAL_cli2srv_bytes sum(subtotal_srv2cli_bytes) as TOTAL_srv2cli_bytes by client_name | table new_time secondsToTime_seen_last client_name client_port server_name server_port cli2srv_bytes_full TOTAL_cli2srv_bytes srv2cli_bytes_full TOTAL_srv2cli_bytes bytes_new TOTAL_bytes thpt throughput_trend_bps duration flow_status_string ndpi_name key thpt
В данном запросе выводятся все актуальные flow (| dedup key), для каждого flow подсчитываются сколько передано*(subtotal_cli2srv_bytes)/принято(subtotal_srv2cli_bytes)/трафика всего(subtotal_bytes)* по имени клиента (by client_name)
В процессе get_flows_data_igb1.lua еще будет пересматриваться на предмет обогащения/удаления мусора. Думаю прийти к виду без полей, с голыми данными и разборщиком полей непосредственно в спланке.
Критика приветствуется!) -
@borg said in Мониторинг трафика и реагирование на утечку:
| eventstats sum(subtotal_bytes) as TOTAL_bytes sum(subtotal_cli2srv_bytes) as TOTAL_cli2srv_bytes sum(subtotal_srv2cli_bytes) as TOTAL_srv2cli_bytes by client_name
| eventstats sum(subtotal_bytes) as TOTAL_bytes sum(subtotal_cli2srv_bytes) as TOTAL_cli2srv_bytes sum(subtotal_srv2cli_bytes) as TOTAL_srv2cli_bytes by client_name, server_name
Так вроде правильней
-
Зародилась идея предотвращения утечки путем отслеживания трафика по ip и при резком скачке трафика до определенного порога оповещать/блокировать интерфейс/машину (скрипты наше все) для предотвращения дальнейшей предполагаемой утечки.
А в чем проблема злодею разбить передаваемую инфу на части? Тем самым никакого всплеска не будет.
-
@werter будет всплеск по отдаванию с сервера, по крайней мере если это файловый сервер, то как говорится, какого хрена пошел поток наружу)
-
В смысле "файловый"? Это фтп, smb или что в вашем понимании?
Доступ к серверу извне как-то регулируется (логин-пароль)? Если да, то в логах самого сервера видно кто, что и когда сливал. Плюс, настройки кому, куда и что можно сливать\заливать. И фтп и smb это позволяют гибко настраивать. Просто не размещать все в одной папке, а разложить по папкам. И можно-нельзя настроить по группам\пол-лям.Как я понимаю, ваше ТЗ подходит для контроля доступа из ЛАН вовне. Если наоборот, то мониторить логи сервера на что-то необычное.
какого хрена пошел поток наружу)
С чего бы вообще такому важному серверу доступ наружу разрешать? ) Опять же, есть возможность ВПНить доступ к нему.
-
@werter вообще, конечно, это не обязательно фтп/смб/нфс. Вы правы по поводу разграничения доступов.
Именно в этом и смысл, чтобы видеть, когда данные покидают лан. И доступа наружу может и не быть, ведь взломав пк/другой сервер в сети и заимев доступ к шаре, можно все слить через взломанную машину, для этого я хочу настроить мониторинг цепочек потоков, так сказать, смотреть откуда ноги растут) и да, баш хистори и прочие логи заливаются на тот же спланк сразу, после выполнения команд :)