Мониторинг трафика и реагирование на утечку

pigbrother

@borg Пусть меня поправят, но не справятся ли с этим Snort\Suricata? Не совсем то, что вы описываете, но на подозрительную активность реагируют.
Есть в стандартных пакетах.

borg

Знаем, настроена, ловит по стандартным правилам+свои. Но смысл чтобы разбирать трафик, желательно потоково с возможностью безграничной аналитики, а не той что зашита в функционал пакетов
Что то мне подсказывает что softflowd, то что я ищу, но не могу сростить мозгами

Konstanti

@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

borg

@Konstanti Спасибо за подсказки. Я правильно понимаю что нужно использовать например вот такую схему https://github.com/hoprocker/pfsense-nfsen и описаные здесь шаги https://forums.freebsd.org/threads/howto-monitor-network-traffic-with-netflow-nfdump-nfsen-on-freebsd.49724/ ?

borg

Практически реализовал то что требовалось при помощи 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=1

REST 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

@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

Так вроде правильней

werter

@borg

Зародилась идея предотвращения утечки путем отслеживания трафика по ip и при резком скачке трафика до определенного порога оповещать/блокировать интерфейс/машину (скрипты наше все) для предотвращения дальнейшей предполагаемой утечки.

А в чем проблема злодею разбить передаваемую инфу на части? Тем самым никакого всплеска не будет.

borg

@werter будет всплеск по отдаванию с сервера, по крайней мере если это файловый сервер, то как говорится, какого хрена пошел поток наружу)

werter

В смысле "файловый"? Это фтп, smb или что в вашем понимании?
Доступ к серверу извне как-то регулируется (логин-пароль)? Если да, то в логах самого сервера видно кто, что и когда сливал. Плюс, настройки кому, куда и что можно сливать\заливать. И фтп и smb это позволяют гибко настраивать. Просто не размещать все в одной папке, а разложить по папкам. И можно-нельзя настроить по группам\пол-лям.

Как я понимаю, ваше ТЗ подходит для контроля доступа из ЛАН вовне. Если наоборот, то мониторить логи сервера на что-то необычное.

какого хрена пошел поток наружу)

С чего бы вообще такому важному серверу доступ наружу разрешать? ) Опять же, есть возможность ВПНить доступ к нему.

borg

@werter вообще, конечно, это не обязательно фтп/смб/нфс. Вы правы по поводу разграничения доступов.
Именно в этом и смысл, чтобы видеть, когда данные покидают лан. И доступа наружу может и не быть, ведь взломав пк/другой сервер в сети и заимев доступ к шаре, можно все слить через взломанную машину, для этого я хочу настроить мониторинг цепочек потоков, так сказать, смотреть откуда ноги растут) и да, баш хистори и прочие логи заливаются на тот же спланк сразу, после выполнения команд :)