Помогите опознать трафик

[alibek]

На одном из серверов вижу такой трафик:

tcpdump -envvvXX ...

11:44:38.866634 00:25:90:34:4e:e6 > 00:25:90:20:c5:6c, ethertype IPv4 (0x0800), length 1514: (tos 0x0, ttl 64, id 7546, offset 1480, flags [+], proto UDP (17), length 1500)
   10.1.128.11 > 10.1.128.13: udp
       0x0000:  0025 9020 c56c 0025 9034 4ee6 0800 4500  .%...l.%.4N...E.
       0x0010:  05dc 1d7a 20b9 4011 22c4 0a01 800b 0a01  ...z..@.".......
       0x0020:  800d 6685 6bf1 6f76 1c44 8e84 57da a76d  ..f.k.ov.D..W..m
       0x0030:  71d5 80f4 8f4f 0bf6 a776 2f0d 1357 5539  q....O...v/..WU9
       0x0040:  5f64 4950 b5e9 40a4 06b7 5785 6131 116c  _dIP..@...W.a1.l
       0x0050:  1d30 b475 e87c d0a7 6426 6719 62d3 86d6  .0.u.|..d&g.b...
11:44:38.866636 00:25:90:34:4e:e6 > 00:25:90:20:c5:6c, ethertype IPv4 (0x0800), length 1153: (tos 0x0, ttl 64, id 7546, offset 2960, flags [none], proto UDP (17), length 1139)
   10.1.128.11 > 10.1.128.13: udp
       0x0000:  0025 9020 c56c 0025 9034 4ee6 0800 4500  .%...l.%.4N...E.
       0x0010:  0473 1d7a 0172 4011 4374 0a01 800b 0a01  .s.z.r@.Ct......
       0x0020:  800d bd69 73ac 4806 6e98 a933 509a 0c6d  ...is.H.n..3P..m
       0x0030:  e6cc eb6d 5c5a f953 3794 4326 8fcc b1ca  ...m\Z.S7.C&....
       0x0040:  bbd3 e8f1 e53c 7f05 9adc 80ea 420d dd6a  .....<......B..j
       0x0050:  a113 0543 f219 8dc2 bc5b d067 e6fe b974  ...C.....[.g...t

Трафика довольно много.

10.1.128.11 - сервер на котором запущен tcpdump, 10.1.128.13 — другой сервер.

Не могу понять, что это такое.

Wireshark тоже не опознает, пишет что это fragmented ip packet.

[Ivan_83]

На 11 сервере делай netstat и смотри кто там юдп большие шлёт.

[alibek]

С помощью netstat видимо не получится — на сервере FreeBSD 8.2, его обновить будет непросто.

А ключа -p в текущей версии netstat нет.

Снял дамп в файлы, попробую в Wireshark поискать. Но Wireshark процесс не покажет.

[stalker86]

А что мешает взять исходнкии собрать под 8.2.

Можно даже на отдельном тазике/виртуалке и потом скопировать?

[Tau]

С помощью netstat видимо не получится — на сервере FreeBSD 8.2, его обновить будет непросто.

А ключа -p в текущей версии netstat нет.

Поставьте lsof из портов, он показывает все дескрипторы, включая сетевые.

В портах sysutils/lsof/.

[alibek]

Под Wireshark в комплексе смотрится более понятно.

Отчего может случаться reassemble?

Линк не перегружен, на интерфейсе в среднем около 10-12 Мбит/с трафика (суммарно, входящий+исходящий), линк гигабитный.

Ошибок на интерфейсе сервер не видит (netstat -i em0).

Ошибок на порту коммутатора (Cisco 3750E) тоже нет.

Причину искать в файрволе (pf) или в чем-то другом?

 

Поставьте lsof из портов

Версия слишком старая, утилиты по работе с портами уже не работают.

[Tau]

Версия слишком старая, утилиты по работе с портами уже не работают.

Какие Вам утилиты? Только make нужен + подложить в дистфайлы нужный архив с сорсами, который нагуглите по названию.

[Ivan_83]

Отчего может случаться reassemble?

Пакет потому что большой относительно mtu интерфейса.

Вон у тебя на ваершарке всё видно: кто то запрашивает у днс defcon.org а ответ приходит большой потому что там много всякой доп инфы.

[alibek]

Ага, вижу. Причем этого defcon в дампе процентов 80.

А разве в этом случае BIND не должен использовать tcp? Я BIND на этом сервере ставил года 4 назад и с тех пор не трогал, но мне казалось, что это стандартное поведение.

[Ivan_83]

С чего вдруг?

udp также прекрасно фрагментируется.

Я бы озаботился поиском источника который так активно этот домен резолвит, как минимум из интереса.

[alibek]

Так, можно себя поздравить. Я зачем-то на сервере 10.1.128.13 оставил включенным dnsmasq с дефолтной конфигурацией и словил DNS Amplification (на 10.1.128.13 есть и другие интерфейсы, в том числе и публичные).

Однако на будущее у меня вопрос - как в подобных случаях можно найти источник трафика (процесс)?

В netstat и в lsof соединений с 10.1.128.11 на порту 53/udp нет вообще. В iftop или iptraf активность видно, но процесс не видно. И в tcpdump тоже видно, что исходящие запросы на 53/udp льются сплошным потоком, но tcpdump процесс показывать не умеет (только в Apple, с ключом -k).

Процесс dnsmasq был просто наиболее вероятной кандидатурой, когда я его остановил, то DNS-флуд прекратился.

А если бы это был какой-нибудь apache или другой хост-сервис?

 

С чего вдруг?

Мне как-то не попадались обычные легитимные DNS-запросы, которым бы не хватило размера одной датаграммы.

Статистику правда я не снимал.

А насколько это распространено?

[GrandPr1de]

если фря то есть sockstat который показывает кто и что слушает какой порт, и удп и тцп

[alibek]

Нет, на 10.1.128.13 как назло Debian.

И мне ведь надо узнать не кто слушает порт (это в netstat есть), а кто отправляет данные в указанный сокет.

[GrandPr1de]

ну фревый нетстат сильно отличается от линуксового, да и фревый сокстат отлично это показал бы

 

_ntp 	ntpd   	783   6  udp4   xxx.xxx.xxx.xxx:58864  62.149.0.30:123

 

вот видно как мой сервер пошел обновлять время

 

но да, dns трафик плохо видно, есть слушающий сокет и не видно сколько клиентов к нему "присосались"

ну в нетстате легко увидить кучу tcp соединений, но с udp всё сильно сложнее

Edited November 22, 2016 by GrandPr1de

[Ivan_83]

Мне как-то не попадались обычные легитимные DNS-запросы, которым бы не хватило размера одной датаграммы.

ёмаё!

UDP дейтаграмма может быть до 6550х байт. Оно автоматом фрагментируется/собирается на уровне IP.

У днс серверов обычно есть настраиваемый параметр, и насколько помню размер более 1500 включается при наличии EDNS - вроде клиент в запросе может указать максимальный размер, а может на сервере крутится, надо уже освежать знания.

[alibek]

Их даже два, edns-udp-size и max-udp-size.

Пока что включу логи для запросов и понаблюдаю.

А вообще думаю выключить EDNS в сторону клиентов, если он не востребован.

[Ivan_83]

Вот для клиентов лучше не выключать а наоборот.

Я тут у себя дома в анбоунде включил минималистичные ответы и прочую херню для противодействия амплификациям и у меня некоторые сайты что на венде что под фрёй перестали открыватся/резолвится, кажется там в ответ приходило только CNAME а уже его клиенты почему то запрашивать ленились, а если включить полные ответы то помимо CNAME приходит ещё и IP адрес его и прочая полезная инфа.