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



  • Здравствуйте.
    Зародилась идея предотвращения утечки путем отслеживания трафика по 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=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 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
    

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



  • @borg

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

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



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



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

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

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

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



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


Log in to reply