Pull to refresh

Comments 60

Напишу и тут: хотелось бы увидеть сравнение с Microsoft Message Analyzer (бывший Network Monitor), на Винде кроссплатформенность не нужна и там хватает своих фишек (нативный драйвер, захват NVGRE, командлеты PowerShell и т.д.).
Не совсем понял про нативный драйвер.
Если я не ошибаюсь, winsock умеет работать только с tcp и udp, а для того чтобы захватывать канальный уровень нужно ставить winpcap.
Думаю имелось ввиду, что у них свой winpcap, то есть свой драйвер, который выполняет захват пакетов.
Если мне память не изменяет, то Network Monitor умел цепляться и к loopback интерфейсу, что часто не хватает.
Интересно, что winpcap может не ловить трафик от некоторых программ работающих на уровне ядра. А вот Network Monitor может. Приходилось сталкиваться.
Спасибо за поправку, плохо выразился. А под «захватом NVGRE» имелась ввиду расшифровка и парсинг трафика внутри тоннеля.
С первого взгляда, MMA показался жутко тормознутым по сравнению с WireShark'ом. Хотя, возможностей, явно побольше.
Самый полезный фильтр.
Тупо по протоколу.
Пример
tcpip.dest == 1.2.4.4 and http
И еще заметка автору: используйте «and» и «or» вместо "&&" и "||". Читается лучше.
Тут уж на вкус и цвет.
Мне кажется что без хотя бы на среднем уровне понимания сетевых протоколов эта программа как очки мартышке, а человек, неплохо понимающий как всё это работает, разберётся и так.
В некоторых местах присутствует неочевидная логика, поэтому во всех нюансах разобраться поначалу сложно.
Ну как сказать. Я неплохо разбираюсь в протоколах, но до такого функционала допёр только на 3-м году. В своё время статья бы мне была чертовски полезна.
Вам кажется.

Wireshark расчехляют, когда что-то работает не так, как ожидалось. Инструмент бесценный.
Некоторое время назад довольно активно пользовался этой программой…
Чего не хватало, так это возможности задания комментария к каждому конкретному пакету, так чтобы эти комментарии отображались в отдельном столбце, и сохранялись в файле вместе с данными (чтобы впоследствии можно было загрузить и быстро вспомнить смысл/найти нужное место в протоколе обмена и т.д.)
с приходом pcap-ng это стало возможным.
Не хватает описания, как сделать так, чтобы показывалось нумерация пакетов не локальная, а реальная.
Пример: два компьютера, вайршарк запущен на обоих, сравнивать номера пакетах сразу с двух мест.
Например для протокола TCP.

Мой любимый фильтр

http~GET

а вообще несколько бесит, что tcpdump и wireshark используют совершенно разные фильтры.
В том числе и поэтому вместо tcpdump я использую tshark ;)
tshark не пробовал но как-то это странно.

Собственно перехват трафика wireshark осуществляет с помощью libpcap, так? Значит если нужно фильтровать пакеты при перехвате, то придётся использовать tcpdump фильтры.
оба используют pcap, но tshark умеет оба синтаксиса фильтров
У wireshark такие же capture filters такие же, как у tcpdump. Т. к. и те, и другие используют libpcap.

Вот то, что разный синтаксис capture и display filters — выносит мозг.
tcpdump использует базовые фильтры libpcap, у шарка совершенно иной, свой механизм.
Программа из разряда must have при работе с сетью.
Еще одним большим плюсов является наличие парсера популярных сетевых протоколов разного уровня. Если бы не они, не уверен, что осилил бы портирование и отладку AMQP клиента.
Статья отличная, одно замечание — пример с граббингом видео с ютюба — неудачный. Всё, что таким образом можно получить — набор 10-секундных кусочков потока (причём отдельно аудио и отдельно видео), без заголовков и метаданных. Ютюб оптимизирует передачу видео массой хитрых способов. Хотя да, есть сервисы где тупо грузится один файл.
Согласен, с ютубом такой способ не сработает.
Пример просто демонстрирует, что существует возможность захвата и медиа контента.
Для меня актуальна задача, когда нужно определить начало и конец конкретного http-запроса. При этом понятно, что ответ обычно бьется на несколько пакетов. Как можно увидеть суммированное значение времени ответа?
Первое, что приходит в голову — это отфильтровать по значению tcp.stream, тогда останется только нужная сессия.
А про суммирование времени для фрагментированных пакетов даже не подскажу…
Возможно нужно смотреть в сторону механизма reassembly.
1. Ставим фильтр «http» — и видим только http-запросы.
2. Находим нужный запрос
3. Правый клик по нему и «Set time reference (toggle)» — это сдвигает «0» временной шкалы к этому пакету
4. Правый клик по тому же запросу и «Folow TCP stream», Close в открывшемся окне.

Теперь у вас видны только пакеты запроса\ответа, с «нулём» времени в точке запроса, таймстемпом для каждого следующего пакета, а общее время — это время последнего пакета.
Можно попробовать использовать Fiddler Web Debugger. Там принцип чуть другой — он ставится как прокси, но это более «высокоуровневый» инструмент и для анализа http траффика может оказаться удобнее. Я с его помощью разобрался с проблемой авторизации на TFS сервере, но, помнится, видел там что-то типа «Transfer Timeline» — может это то, что вам надо.
Тема не будет полной без описания распатронивания TLS соединений. В открытом виде сейчас летает все меньше и меньше данных. Особенно после сноуденбума.
Wireshark умеет раскрывать SSL / TLS сессии, но только при наличии сертификата.
При этом надо не забыть настроить сервер не использовать Perfect Forward Secrecy.
Добавлю про RTP. По умолчанию wireshark rtp пакеты не распознает и показывает простой udp траффик. Чтобы распознавал и можно было воспользоваться фичами с VOIP из статьи надо зайти в «Edit->Preferences->Protocols->RTP» и ставим галочку «try to decode rtp outside of conversations».
А не знаете, насколько сложно будет прикрутить к Wireshark свой виртуальный сетевой интерфейс?
Допустим, есть USB-девайс, который сниффает пакеты, передающиеся по радио-каналу между другими девайсами. Я хочу передавать эти данные в Wireshark. Есть ли для этого механизм плагинов или что-то подобное?
Он умеет изначально слушать виртуальные интерфейсы, вроде тех, которые создают VMware или VirtualBox (не говоря уже про GNS/Dynamips).
Вероятно многое будет зависеть и от вашего устройства.
Но у меня нет сетевого интерфейса в терминах операционной системы.
Есть простая программа, получает поток байтов по USB и может их куда-нибудь передать. Я хочу сделать плагин для Wireshark, который будет связываться с этой программой.
Может проще будет сохранять весь поток в pcap файл, а потом уже открывать и анализировать в Wireshark'e?
Да, как вариант. Но тогда Wireshark не будет считывать то что дописывается в файл после открытия?
Есть вариант с использованием каналов (pipe), тут описан пример.
Тогда можно будет добиться нечто похожего на риалтайм с использованием pcap файла.
Можно переписать packet.dll драйвер от winpcap. Просто все функции, которые должны быть в пакете, заменяются на свои и подсовываются туда нужные данные. Я таким образом декодировал HART протокол через модем подключенный к серийному порту. И все работало. Конечно нужно писать и свой диссектор (плагин), что бы трафик декодировался нормально. Кстати вот об этом было бы не плохо пост написать:
создание плагина для wireshark.
Спасибо за статью! Было бы ещё интересно почитать о возможностях программирования на Lua под Wireshark с примерами.
Получилось очень похоже на курс от CBTNuggets. Было бы весьма интересно почитать про отчеты, которые можно генерировать… с практическими примерами…
Есть ли возможность как-то захватывать трафик на localhost?
В линуксе и BSD можно, под Windows нет.
Если интересно, то про причину можно прочитать тут
Да, я под Windows имел ввиду, как-то полдня провозился, но так и не смог увидеть трафика на localhost.
Перехватывайте через RawCap, а анализируйте уже в WireShark.
Спасибо за наводку, при случае попробую.
Отличный инструмент, пользуюсь им каждый день! В комплекте с tshark незаменимая вещь. Сам разрабатывал для него NFSv41 декодер.
Отдельно хочется упомянуть возможность удалённого захвата траффика. К примеру, есть *nix-машина в нужном месте с установленным tcpdump. Берём plink (из набора putty), делаем на Windows-машине админа plink -ssh user@nix «tcpdump -s 0 -w — 'not port 22'» | «c:\program files\wireshark\wireshark.exe» -k -i -, радуемся. Ещё неплоха возможность захвата траффика с устройств Mikrotik — они умеют пересылать данные с встроенной утилиты packet sniffer.
Хабр, прошу помощи! есть такой вот Девайс. Замечательная игрушка, но как всегда хочется большего. Появилась идея провести реверс-инжиниринг протокола, и попробовать управлять этим делом с компа. Сеть без шифрования, машинка создает точку, сама имеет IP 192.168.1.100, устройствам выдает IP по порядку, начиная с 192.168.1.1. Два устройства, к ней подключенные могут управлять по очереди (при попытке запустить управляющее приложение, когда оно уже запущено на другом устройстве — ругается, что не может установить связь, однако если на первом устройстве управлялку закрыть — второе без проблем подключается. Соответственно комп к этой сети тоже нормально конектится. Поискал, что есть в сети, нашел вот это: isgroupblog.blogspot.ru/2013/09/how-i-hacked-brookstone-rover-20.html. Это предыдущая модель, однако порядок действий по идее тот же. Начал я с того, что поставил Wireshark, посмотреть, что ходит по wifi. И вот тут все кончилось — не смотря на то, что нет никаких фильтров на сам поток, в момент, когда управлялка шлет любые сигналы, а машина на них реагирует (так же постоянно присутствует видеопоток с камеры) — я не вижу никаких пакетов управления! т.е. вообще! Как такое может быть? Конечно я собираюсь последовать примеру автора статьи про rover 2.0 и попробовать декомпилировать управлялку для андроида, но он-то пишет, что еще на этапе перехвата пакетов в wifi смог осуществлять простенькие действия типа вперед-назад-лево-право!

PS если добьюсь результатов — все подробно распишу с исходниками! Может кому будет интересно. )
А вы правильный интерфейс выбрали в окне Wireshark?
Да. В принципе я вижу ARP и DNS пакеты, когда планшет или телефон впервые получают IP, иногда что-то еще проскакивает от них, но непосредственно управляющих пакетов, которые могли бы содержать что-то управляющее данные — нет. Я просто не силен на самом деле в организации сетевых взаимодействий, но мне всегда казалось, что даже если данные сильно шифрованные там или используется какой-то свой неведомы протокол, то это все равно выше третьего, но в крайнем случае — второго уровня. Т.е. пакеты-ты то я должен видеть! Может не смогу понять что в них, но сами пакеты… Или нет? Или есть какие-то взаимодействия хитрые, которые шарк не увидит вообще? Ну, я далек от мысли, что программа на планшете может использовать вай-фай на сигнальном уровне…
Если приложение не работает напрямую с сетевой картой (очень-очень маловероятно), то wireshark видит все передаваемые пакеты. Кроме пакетов управления беспроводной сети, но см. п.1, приложение с ними не работает.

А покажите дамп. Скорее всего там всё есть, вы просто пропускаете нужное.

Опять же — видеопоток есть?
в том-то и дело, что картинка с камеры на планшете есть, а ничего похожего на пакеты с этим содержимым я не вижу! Доберусь до дома — сниму дамп, выложу, сообщу. )) Сегодня не знаю как получится — но на выходных точно!
Если вы управляете с планшета, а ловите трафик на компьютере — дело усложняется. Для снижения количества геморроя при анализе придется отключить шифрование wi-fi, и вместо wireshark'а использовать полноценный wireless sniffer (под виндой например есть commview), иначе вы наловите много шифрованных WPA пакетов, и вам нужно будет искать инструменты для снятия защиты при известном PSK.

Или запускайте wireshark на том же устройстве, которое управляет машиной.
вот засада! Программы управления есть под iOS (собственно мой планшет, это ipad) и под андроид (есть один девайс под рукой — еще не пробовал). Под Win|Mac|Lnx такого нету. А Shark наоборот соответственно… Т.е. я правильно понимаю, что я вижу в shark только те пакеты, которые или бродкаст, или предназначены/исходят с/на ту машину, на которой он запущен? Если да, то это все объясняет. commview говорите? ))
Есть способы запуска андроида на x86 в виртуалке. Это сильно облегчит задачу.
Поставьте на android tcpdump, сохраните им дамп, скопируйте на ПК и там анализируйте Wireshark'ом.
Only those users with full accounts are able to leave comments. Log in, please.