search

pavel-odintsov / fastnetmon

FastNetMon - very fast DDoS sensor with sFlow/Netflow/IPFIX/SPAN support
https://fastnetmon.com
GNU General Public License v2.0
3.42k stars 568 forks source link

Possible bug with long file downloads #615

Closed mcflyspb closed 7 years ago

mcflyspb commented 7 years ago

Павел, добрый день!

Нет ли тут бага ?

IP: 82.112.190.49 - наш клиент. IP: 91.231.235.65 - CDN-сервис.

Ответ CDN_сервиса на вопрос: Провели проверку, и выявили, что 82.112.190.49 в течении 22 часов тянул с 91.231.235.65 аудиопоток. Первичная диагностика ничего подозрительного не выявила.

IP: 82.112.190.49 Attack type: unknown Initial attack power: 125995 packets per second Peak attack power: 125995 packets per second Attack direction: incoming Attack protocol: tcp Total incoming traffic: 1262 mbps Total outgoing traffic: 0 mbps Total incoming pps: 125995 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: 1262 mbps Average outgoing traffic: 0 mbps Average incoming pps: 125995 packets per second Average outgoing pps: 0 packets per second Average incoming flows: 0 flows per second Average outgoing flows: 0 flows per second Incoming ip fragmented traffic: 0 mbps Outgoing ip fragmented traffic: 0 mbps Incoming ip fragmented pps: 0 packets per second Outgoing ip fragmented pps: 0 packets per second Incoming tcp traffic: 1262 mbps Outgoing tcp traffic: 0 mbps Incoming tcp pps: 125994 packets per second Outgoing tcp pps: 0 packets per second Incoming syn tcp traffic: 0 mbps Outgoing syn tcp traffic: 0 mbps Incoming syn tcp pps: 0 packets per second Outgoing syn tcp pps: 0 packets per second Incoming udp traffic: 0 mbps Outgoing udp traffic: 0 mbps Incoming udp pps: 0 packets per second Outgoing udp pps: 0 packets per second Incoming icmp traffic: 0 mbps Outgoing icmp traffic: 0 mbps Incoming icmp pps: 0 packets per second Outgoing icmp pps: 0 packets per second

Average packet size for incoming traffic: 1313.3 bytes Average packet size for outgoing traffic: 0.0 bytes Incoming

TCP flows: 3 82.112.190.49:52922 < 217.69.133.145:80 400 bytes 10 packets 82.112.190.49:60690 < 92.122.93.50:443 710 bytes 10 packets 82.112.190.49:62909 < 91.231.235.65:443 1738257470 bytes 1323450 packets

pavel-odintsov commented 7 years ago

Фастнетмон не будет и не должен смотреть на трафик старше чем последние Х секунд указанные в average calculation time.

Если хочется дольше - рекомендую использовать обычные аггрегаторы нетфлоу.

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

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

On Thu, 15 Dec 2016 at 13:38, mcflyspb notifications@github.com wrote:

Павел, добрый день!

Нет ли тут бага ?

IP: 82.112.190.49 - наш клиент.

IP: 91.231.235.65 - CDN-сервис.

Ответ CDN_сервиса на вопрос:

Провели проверку, и выявили, что 82.112.190.49 в течении 22 часов тянул с 91.231.235.65 аудиопоток. Первичная диагностика ничего подозрительного не выявила.

IP: 82.112.190.49

Attack type: unknown

Initial attack power: 125995 packets per second

Peak attack power: 125995 packets per second

Attack direction: incoming

Attack protocol: tcp

Total incoming traffic: 1262 mbps

Total outgoing traffic: 0 mbps

Total incoming pps: 125995 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: 1262 mbps

Average outgoing traffic: 0 mbps

Average incoming pps: 125995 packets per second

Average outgoing pps: 0 packets per second

Average incoming flows: 0 flows per second

Average outgoing flows: 0 flows per second

Incoming ip fragmented traffic: 0 mbps

Outgoing ip fragmented traffic: 0 mbps

Incoming ip fragmented pps: 0 packets per second

Outgoing ip fragmented pps: 0 packets per second

Incoming tcp traffic: 1262 mbps

Outgoing tcp traffic: 0 mbps

Incoming tcp pps: 125994 packets per second

Outgoing tcp pps: 0 packets per second

Incoming syn tcp traffic: 0 mbps

Outgoing syn tcp traffic: 0 mbps

Incoming syn tcp pps: 0 packets per second

Outgoing syn tcp pps: 0 packets per second

Incoming udp traffic: 0 mbps

Outgoing udp traffic: 0 mbps

Incoming udp pps: 0 packets per second

Outgoing udp pps: 0 packets per second

Incoming icmp traffic: 0 mbps

Outgoing icmp traffic: 0 mbps

Incoming icmp pps: 0 packets per second

Outgoing icmp pps: 0 packets per second

Average packet size for incoming traffic: 1313.3 bytes

Average packet size for outgoing traffic: 0.0 bytes

Incoming

TCP flows: 3

82.112.190.49:52922 < 217.69.133.145:80 400 bytes 10 packets

82.112.190.49:60690 < 92.122.93.50:443 710 bytes 10 packets

82.112.190.49:62909 < 91.231.235.65:443 1738257470 bytes 1323450 packets

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/pavel-odintsov/fastnetmon/issues/615, or mute the thread https://github.com/notifications/unsubscribe-auth/ACnfZqMfRmQCc15RH_DWxMu7wVll1qKLks5rIULRgaJpZM4LOGqr .

mcflyspb commented 7 years ago

См. тут указано: Total incoming traffic: 1262 mbps. Но CDN-оператор только что ответил мне: продолжительность коннекта - 79868 секуд объём отданных байт - 2555856778, что соответствует прослушиванию потока 256 kb/s в течении 79868 (~ 22 часа).

Был ли поток 1262 mbps ? Мне кажется, тут не было никакого DDoS.

mcflyspb commented 7 years ago

[root@ddos etc]# grep average fastnetmon.conf We use average values for traffic speed to certain IP and we calculate average over this time slice average_calculation_time = 10 We use average values for traffic speed for subnet and we calculate average over this time slice average_calculation_time_for_subnets = 30

pavel-odintsov commented 7 years ago

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

FNM в данный момент не смотрит на дату начала и конца потока. Так бы поидее он мог убрать этот поток из обсчета.

Sflow/mirror дают на порядки большую точность.

On Thu, 15 Dec 2016 at 14:22, mcflyspb notifications@github.com wrote:

[root@ddos etc]# grep average fastnetmon.conf

We use average values for traffic speed to certain IP and we calculate average over this time slice

average_calculation_time = 10

We use average values for traffic speed for subnet and we calculate average over this time slice

average_calculation_time_for_subnets = 30

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/pavel-odintsov/fastnetmon/issues/615#issuecomment-267338897, or mute the thread https://github.com/notifications/unsubscribe-auth/ACnfZvyGD6sDcCIrZ6CrTgkfd_hpCMgMks5rIU0xgaJpZM4LOGqr .

mcflyspb commented 7 years ago

Понятно. Меня смущает, что программа работала около месяца и ложных срабатываний не было. А сегодня на утро уже получили несколько десятков. Данные собираем по Netflow: show services flow-monitoring version-ipfix { template ipv4 { flow-active-timeout 10; flow-inactive-timeout 10; template-refresh-rate { packets 1000; seconds 10; } option-refresh-rate { packets 1000; seconds 10; } ipv4-template; } }

show configuration forwarding-options sampling instance { bgp-def { input { rate 10; } family inet { output { flow-server 10.255.255.2 { port 2055; version-ipfix { template { ipv4; } } } inline-jflow { source-address 10.255.255.1; } } } } }

Можно ли что-то подкрутить в FNM или на MX чтобы уменьшить такие ложные срабатывания ?

mcflyspb commented 7 years ago

Может эту опцию перевести в on ? netflow_divide_counters_on_interval_length = off

mcflyspb commented 7 years ago

Внутри Netflow-пакетов есть информация о продолжительности соединения. Скрин прилагаю. Вы используете эту информацию при расчетах ?

image

pavel-odintsov commented 7 years ago

Да, эта информация есть и он извлекается для netflow 5 и вы в целом можете реализовать простенький патч, если данный режим захвата устраивает.

Стандартно подобное не поддерживается (см ниже почему).

Для netflow v9/ipfix все намного сложнее, так как нужна специальная структура и обработка шаблонов.

mcflyspb commented 7 years ago

Готов попробовать патч написать. Подскажите, где в коде идет подсчет ? Я бы просто откинул все "всплески". Критерий - пакеты более 100 Mb.

pavel-odintsov commented 7 years ago

Для netflow9 здесь: https://github.com/pavel-odintsov/fastnetmon/blob/master/src/netflow_plugin/netflow_collector.cpp#L588

Такой патч не универсален и может привести к бОльшему числу проблем, так как просто скроет проблему, а не решит её. Но как личный патч без отправки в апстрим - вполне решение.

mcflyspb commented 7 years ago

Я не стал долго мудрить и сделал:

// decode data in network byte order to host byte order
packet.length = fast_ntoh(packet.length);

if (packet.length > 100000000) {
    packet.length = 64;
}

Будем тестировать... Я так понял, что классе simple_packet вообще нет timestamp.

pavel-odintsov commented 7 years ago

Он есть, ts поле, но он не заполняется метриками из потока. Ранее он заполнялся обычным gettimeofdate() но из-за излишне большого потребления cpu я это отключил.

On Sun, 18 Dec 2016 at 18:40, mcflyspb notifications@github.com wrote:

Я не стал долго мудрить и сделал:

// decode data in network byte order to host byte order

packet.length = fast_ntoh(packet.length);

if (packet.length > 100000000) {

packet.length = 64;

}

Будем тестировать... Я так понял, что классе simple_packet вообще нет timestamp.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/pavel-odintsov/fastnetmon/issues/615#issuecomment-267838103, or mute the thread https://github.com/notifications/unsubscribe-auth/ACnfZpQEJ-AEGLtuky0Mp-_zCO99j4o9ks5rJX4DgaJpZM4LOGqr .

mcflyspb commented 7 years ago

Добавил логирование в коде. Пример: 2016-12-19 19:33:17,818 [INFO] Correct packet.length: 13158651195. New packet.length: 64 Т.е. прилетел flow 1.3Gb. Напомню, у меня MX104 (JUNOS 13.3R8.7) + netflow 9. Пробовал эмулировать такую ситуацию большими закачками (> 200Mb), но ни разу не выловил. Вероятно, MX не всегда "копит" большие flow. Критерии пока не понятны.

pavel-odintsov commented 7 years ago

Вопрос в том, что он просто ну обязан их НЕ копить. Если у вас стоит flow timeout active/inactive в 10 секунд (flow-active-timeout 10; / flow-inactive-timeout 10), то безотносительно тому, идет ли поток или нет он должен быть обсчитан.

Но в дампе , который Вы прислали поток длится аж 24 секунды, что вполне может быть багом.

Кроме того, официальная документация утверждает, что минимальный таймаут - это 60 секунд, http://www.juniper.net/techpubs/en_US/junos13.3/topics/reference/configuration-statement/flow-active-timeout-edit-forwarding-options.html

И также там указано, что данные " In active flow monitoring, the cflowd or flow monitoring version 9 records are exported after a time period that is a multiple of 60 seconds and greater than or equal to the configured active timeout value".

А это, честно говоря, вообще немного смахивает на бред :) Получается, Juniper не следует четко указанному таймауту.

Что опять же открывает интересные возможности по фиксу - увеличить average_recalculation_time до 60 либо создать инцидент в TAC и пролить свет на причины подобного поведения.

mcflyspb commented 7 years ago

"Что опять же открывает интересные возможности по фиксу - увеличить average_recalculation_time до 60 либо создать инцидент в TAC и пролить свет на причины подобного поведения." Я присмотрелся... Flow на 13Gb :-) Тут никакой average_recalculation_time не спасет. Меня еще удивляет, что отсечка стоит на 100Mb и под нее попал только один этот flow за 2 суток. Баг MX в чистом виде. TAC у нас нет куплен, дорого... Итоговый вид патча: // decode data in network byte order to host byte order packet.length = fast_ntoh(packet.length);

// Start if (packet.length > 100000000) { logger << log4cpp::Priority::INFO << "Correct packet.length: " << packet.length << ". New packet.length: 64"; packet.length = 64; }

// End packet.number_of_packets = fast_ntoh(packet.number_of_packets);

Не судите строго, этой мой первый код на С++.

pavel-odintsov commented 7 years ago

Сурово. Мне тут @medvedv подсказал, что Juniper и правда не следует этим самым active/inactive flow timeout четко, поэтому логичнее будет собрать поток трафика и посмотреть какой же у вас получается длина сбора трафика.

Кроме этого, есть настройки, сколько пакетов в каждом netflow должно быть.

Есть еще ручка "forwarding-options sampling instance acct family inet output inline-jflow flow-export-rate", попробуйте прочитать про нее.

mcflyspb commented 7 years ago

По default: flow-export-rate = 1 kpps

[root@ddos log]# time tcpdump -i eth6 -n > /dev/null tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth6, link-type EN10MB (Ethernet), capture size 65535 bytes ^C6860 packets captured 6860 packets received by filter 0 packets dropped by kernel

real 0m12.617s user 0m0.090s sys 0m0.026s

И это выливается примерно в 500pps. На коллектор идет только входящий в нашу сеть трафик. Сейчас это около 2 Gbps и 200kpps трафика.

Поставил: root@rtc_jmx_104_m9_1# show | compare [edit forwarding-options sampling instance bgp-def family inet output inline-jflow]

[edit] root@rtc_jmx_104_m9_1# commit commit complete

[root@ddos log]# time tcpdump -i eth6 -n > /dev/null tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth6, link-type EN10MB (Ethernet), capture size 65535 bytes ^C5625 packets captured 5625 packets received by filter 0 packets dropped by kernel

real 0m10.319s user 0m0.057s sys 0m0.012s

В общем особых изменений нет. Ну да ладно, патч есть, будет наблюдать.

pavel-odintsov commented 7 years ago

Для Junios у вас есть крутая фича - sampled mirror (maximum-packet-length 110; для mirror ифейса). Вы можете легко влить десятку в гигабитный порт для анализа и обработать трафик там. Учитывая что трафика у вас не так много - это, имхо, идеальный способ для анализа.

pavel-odintsov commented 7 years ago

Если решите использовать - не забудьте указать флажок "netmap_read_packet_length_from_ip_header".

pavel-odintsov commented 7 years ago

Finally, it was some kind of feature of JunOS telemetry implementation.