information security
118,15
рейтинг
2 декабря 2013 в 13:00

Разработка → Wireshark — приручение акулы tutorial



Wireshark — это достаточно известный инструмент для захвата и анализа сетевого трафика, фактически стандарт как для образования, так и для траблшутинга.
Wireshark работает с подавляющим большинством известных протоколов, имеет понятный и логичный графический интерфейс на основе GTK+ и мощнейшую систему фильтров.
Кроссплатформенный, работает в таких ОС как Linux, Solaris, FreeBSD, NetBSD, OpenBSD, Mac OS X, и, естественно, Windows. Распространяется под лицензией GNU GPL v2. Доступен бесплатно на сайте wireshark.org.
Установка в системе Windows тривиальна — next, next, next.
Самая свежая на момент написания статьи версия – 1.10.3, она и будет участвовать в обзоре.

Зачем вообще нужны анализаторы пакетов?
Для того чтобы проводить исследования сетевых приложений и протоколов, а также, чтобы находить проблемы в работе сети, и, что важно, выяснять причины этих проблем.
Вполне очевидно, что для того чтобы максимально эффективно использовать снифферы или анализаторы трафика, необходимы хотя бы общие знания и понимания работы сетей и сетевых протоколов.
Так же напомню, что во многих странах использование сниффера без явного на то разрешения приравнивается к преступлению.

Начинаем плаванье


Для начала захвата достаточно выбрать свой сетевой интерфейс и нажать Start.



После чего и начнется процесс захвата, причем прилетевшие пакеты будут появляться в реальном времени.
В процессе рассмотрения и изучения пакетов бывают ситуации, когда нужно вернуться предыдущему пакету. Для этого есть две кнопки (см скриншот).



А следующая за ними кнопка позволяет сделать быстрый переход к пакету, указав его номер.
В случае если колонки перекрываются и наползают друг на друга, можно кликнуть по такой колонке правой кнопкой мыши и выбрать “Resize Column”.
Произойдет автоматическая подгонка размеров под текущую ситуацию.
И кроме того, есть кнопка “Resize all Columns”, которая приведет в порядок все колонки.
Используя меню View – Time Display Format, можно, например, настроить, чтобы отсчет времени шел не с начала захвата, а с момента получения предыдущего пакета (Since Previous Captured Packet).
Самое важное в каждой программе (Help – About Wireshark) покажет не только версию и список авторов, но и содержит закладку Folders, которая покажет пути размещения каталогов с конфигурациями.
Изучая интерфейс, можно выбрать, например, пакет http, и увидеть, что HTTP инкапсулируется в TCP (транспортный уровень), TCP инкапсулируется в IP (сетевой уровень), а IP в свою очередь инкапсулируется в Ethernet (перед этим даже мелькает 802.1Q).



И на самом верху идет нечто вроде небольшого обзора собранной информации о кадре.



Про фильтры мы поговорим дальше, а на данном этапе, если нужно быстро отфильтровать лишние пакеты, достаточно сделать правый клик на пакете, выбрать меню Apply as Filter – Not selected и изменения сразу же вступят в силу.
Если нужно еще что-то убрать, то в следующий раз выбирать “and not Selected”, и новое правило просто добавится к фильтру.

Убираем заусенцы


Довольно часто при работе с Wireshark возникает ошибка IP checksum offload – ошибка контрольной суммы заголовка IP пакета.



Современные сетевые карты насколько умные, что сами считают контрольную сумму, зачем это делать на уровне стека TCP/IP программно, если можно делать хардварно.
А Wireshark натурально перехватывает пакеты, до того как они попадают в сеть.
И до того как эта сумма была просчитана и была добавлена в заголовок пакета.
Соответственно есть два пути решения этой проблемы — выключать функцию offload в настройках сетевой карты или в настройках сниффера указать, чтобы он не обращал внимание на это значение.
Хардваные функции зачастую лучше софтварных, в основном из-за скорости обработки (в железе обычно выше) поэтому лучше изменить настройки самого сниффера.
Для этого нужно зайти в настройки (Edit — Preferences), затем Protocols – IPv4 – и снять флаг с “Validate IPv4 checksum if possible”.



Перед тем как захватывать трафик нужно определиться с тем, что, собственно, нужно захватывать.
Разместить анализатор трафика можно в нескольких местах:
  • Локально на своем хосте;
  • Организовать зеркалирование трафика на коммутаторе;
  • Подключаться непосредственно в интересующие места;
  • или же отравление протокола ARP (еще более незаконно, чем пассивное прослушивание трафика)


Фильтруем поток


Wireshark содержит два вида фильтров – захвата (Capture Filters) и отображения (Display Filters).
Вначале рассмотрим Capture Filters.
Как можно догадаться по названию, они служат для фильтрации еще на этапе захвата трафика.
Но в таком случае, безусловно, можно безвозвратно потерять часть нужного трафика.
Фильтр представляет собой выражение, состоящее из встроенных значений, которые при необходимости могут объединяться логическими функциями (and, or, not).
Для того, чтобы его задействовать, нужно зайти в меню Сapture, затем Options, и в поле Capture Filter набрать, например, host 8.8.8.8 (или, например, net 192.168.0.0./24)



Так же, конечно, можно выбрать и заранее созданный фильтр (за это отвечает кнопка Capture Filter).
В любом из вариантов фильтр появится возле интерфейса, можно жать Start.

Теперь перейдем к Display Filters.
Они фильтруют исключительно уже захваченный трафик.
Что можно фильтровать?
— Практически все — протоколы, адреса, специфические поля в протоколах.
Операции, которые можно использовать при построении фильтров:

Команда Значение Пример использования
== равенство ip.dst == 193.168.3.10
!= Не равно udp.dst != 53
< меньше чем ip.ttl < 24
> больше чем frame.len > 10
<= меньше или равно frame.len <= 0x20
>= больше или равно tcp.analysis.bytes_in_flight >= 1000
matches регулярные выражения frame matches "[Pp][Aa][Ss][Ss]"
contains содержит dns.resp.name contains google


Как вы, наверное, заметили, в таблице в качестве примеров были разнообразные выражения, достаточно понятные и зачастую говорящие сами за себя.
Например, ip.dst – это поле протокола IP.
Чтобы увидеть это поле, можно просто посмотреть на пакет, и в нижней части окна можно увидеть его значение, которое потом можно применять в любом фильтре.
Например, нас интересует, как создать фильтр, где будет проверяться значение TTL.
Для этого раскрываем L3 часть и становимся на соответствующее поле:



И видим, что для построения фильтра, нужно использовать выражение ip.ttl.
Если начать набирать фильтр, то после точки автоматически появится список возможных значений:



Чтобы применить фильтр, достаточно нажать enter или кнопку Apply.
Само поле для ввода фильтра может менять цвет в зависимости от того, что было набрано.
Зеленый цвет означает, что все в порядке. Красный — допущена ошибка, желтый — получен неожиданный результат, потому что существуют другие варианты написания фильтра (например можно написать ip.dst != 8.8.8.8 или же !ip.dst == 8.8.8.8, именно второй вариант более предпочтительный).
Фильтры можно сохранять для дальнейшего использования, нажав кнопку Save, затем ввести произвольное название



и после нажатия на кнопку ОК фильтр появится как кнопка на панели.



А если кликнуть на расположенную неподалеку кнопку «Expression…», то откроется достаточно мощный конструктор выражений, по которому можно чуть ли не изучать сетевые протоколы. Количество поддерживаемых протоколов постоянно увеличивается.



Как уже упоминалось ранее, можно выделить любой пакет и в контекстном меню выбрать Apply as Filter и в подменю выбрать режим — selected или not selected и соответственно сразу же появится фильтр, который будет показывать только выбранное или наоборот уберет выбранное с экрана.
Таким образом можно гибко выбирать, что видеть на экране, а что — нет.
Это может быть определенный ip-адрес, ttl, порт, dns ответ и многое другое.
Кроме того, есть два варианта для таких быстрых фильтров — Prepare as Filter и Apply as Filter.
Как можно догадаться по названию — разница заключается в том, что в первом случае только появится в поле для ввода Display Filter, но не применится (удобно, если например, добавлять таким способом несколько фильтров, а затем сразу применить готовый результат), а во втором — сразу же и применится.

Фильтры можно объединять, используя знакомые по булевой алгебре логические операции:
(dns) && (http) логическое и

(dns) || (http) это логическое или

Таким образом можно строить большие и сложные фильтры вроде:
(tcp.flags.syn==1) && (ip.src == 172.16.10.2) && (ip.dst == 172.16.10.1)
Здесь видим, что выбираются только TCP SYN сегменты, только с определенным адресом отправителя и получателя. При составлении больших фильтров нужно помнить, что фильтр по сути — логическое выражение, и если оно истинно, то пакет отобразится на экране, если ложно — нет.

Ныряем глубже


Достаточно частая ситуация, когда возникают жалобы на медленную работу сети, причин этого может быть множество.
Попробуем разобраться, в чем может быть причина, и рассмотрим два способа.
Первый состоит в добавлении колонки TCP delta.
Открываем пакет, находим поле Time since previous frame in this TCP frame, правый клик и выбираем Apply as Column. Появится новая колонка.
На ней можно кликнуть правой кнопкой мыши и выбрать режим сортировки, например, Sort Descending.



И сразу же рассмотрим второй способ.
Относительно недавно (в версии 1.10.0) появился фильтр tcp.time_delta, который, собственно, учитывает время с момента последнего запроса.



Если клиент делает запрос и получает ответ через 10 миллисекунд, и клиент говорит, что у него все медленно работает, то, возможно, проблема у самого клиента.
Если же клиент делает запрос и получает ответ через 2-3 секунды, тут уже, возможно, проблема кроется в сети.

Еще глубже


Если посмотреть в TCP пакет (или сегмент если быть точным), то можно увидеть там Stream index, который начинается обычно с нуля.
Само поле будет называться tcp.stream.



По нему можно сделать правый клик и создать фильтр.



Таким образом можно фильтровать нужные соединения.

Еще один способ – сделать правый клик на самом пакете, выбрать Conversation Filter и создать фильтр для l2 l3 l4 уровня соответственно.



В итоге мы опять увидим взаимодействие двух хостов.

И третий вариант — это одна из самых интересных фич — Follow TCP Stream.
Для того чтобы его задействовать, нужно опять таки кликнуть правой кнопкой мыши на пакете и выбрать “Follow TCP Stream”. Появится окно, где будет наглядно продемонстрирован весь обмен между двумя узлами.



Если же зайти в меню Statistics – Conversations, то, выбирая закладки, можно увидеть статистику по таким “разговорам” и различные сессии, при этом можно отсортировать их по различным колонкам, например, по количеству переданных данных.



И прямо в этом окне можно правой кнопкой взывать контекстное меню и опять же применить как фильтр.

Со временем приходит опыт


После некоторого времени, проведенного за захватом разнообразного трафика, можно заметить какую-то шарообразную кнопку в нижнем левом углу, которая еще иногда меняет цвет.



Нажатие на эту кнопку приведет к открытию окна Expert Infos.
Того же результата можно добиться, пройдя в меню Analyze – Expert Info.



В этом окне будет содержаться информация по найденным пакетам, разбитая на группы Errors, Warnings, Notes и Chats.
Цветовая раскраска для этих групп выглядит следующим образом:
Ошибки — красный цвет
Предупреждения — желтый
Примечания — сине-зелёный (cyan)
Чат — серый

Wireshark содержит в себе мощный анализатор и умеет автоматически обнаруживать большое количество проблем, возникающих в сети.
Как вы уже могли заметить, буквально везде можно использовать фильтры и Expert Info не является исключением.
Для того чтобы создать такой фильтр, нужно использовать конструкцию expert.severity.
Например, expert.severity==error.

Грабим трафик!


Можно ли с помощью Wireshark узнать, что было скачано?
Да, можно. И сейчас это увидим.
Вначале возьмем HTTP трафик.
Сделаем правый клик по HTTP пакету — Protocol Preferences – и видим тут массу опций, которые непосредственно влияют на извлечение файлов из веб трафика.
Для того чтобы увидеть, что можно извлечь из текущего дампа нужно перейти в меню File – Export Objects – HTTP.
Появится окно, которое покажет все захваченные http объекты — текстовые файлы, картинки и т.д. Для того чтобы вытащить любой файл из этого списка, достаточно просто выделить его и нажать Save As.



Как можно заметить, рисунок был извлечен без каких-либо проблем.



Таким же способом, можно извлекать и потоковое видео/аудио.



Но на этом возможности Wireshark не заканчиваются!
Он умеет вытаскивать файлы и с протокола FTP.
Для этого можно использовать знакомый уже Follow TCP Stream.
В итоге отобразится только обмен по протоколу FTP, в котором нужно будет найти строку RETR, что собственно и будет означать передачу файла.



Затем опускаемся дальше, находим пакеты уже непосредственно с файлом (FTP-DATA) и опять выбираем Follow TCP Stream, видим содержимое файла, жмем Save As и сохраняем.



VoIP


Wireshark имеет несколько встроенных функций для работы с этой технологией.
Он поддерживает массу голосовых протоколов — SIP, SDP, RTSP, H.323, RTCP, SRTP и другие.
И, конечно же, умеет перехватывать и сохранять голосовой трафик для дальнейшего прослушивания.
Этот функционал как нельзя лучше подойдет для траблшутинга в сетях Voice over IP.
Меню Statistics — Flow Graph покажет наглядную картину, как происходил весь обмен пакетами.



А вообще целое меню Telephony отведено для работы с голосовым трафиком.
Например, Telephony – RTP – Show All Streams покажет подробно, что происходило с RTP, в частности jitter (параметр, который, вероятно, самый важный в голосе), что иногда сразу скажет о наличии проблем.



Нажав на кнопку “Analyze”, можно открыть окно RTP stream Analysis – и, выбрав там поток, можно его даже проиграть, используя кнопку player.
Сначала отроется окно проигрывателя, в котором вначале нужно установить подходящее значение jitter и использовать кнопку decode.



Появится нечто похожее на анализатор спектра, в котором можно отметить требуемый разговор, и после этого кнопка Play станет активной.



Так же существует еще один способ прослушивания голосовых звонков — можно зайти в меню Telephony – VoIP Calls.



Откроется окно со списком совершенных звонков, где опять же можно нажать кнопку player, отменить нужные разговоры флажками и нажать play.
Для того чтобы добиться приемлемого качества звучания, потребуется проиграться со значением поля jitter buffer, меняя его значение.

Небольшое отступление


Некоторое время назад появился сайт CloudShark.org.



Это тот самый сниффер Wireshark, но реализованный в виде онлайн-сервиса. Очевидно, что с его помощью не удастся захватывать сетевой трафик, но выполнять анализ дампа трафика – вполне. Загрузив туда через форму PCAP-файл на анализ, можно будет получить четкую последовательность пакетов, в которой всё данные будут разбиты на понятные поля в зависимости от протокола. В общем, тот же Wireshark, но немного облегченный и доступный из любого браузера.

Финальная битва


Напоследок рассмотрим как выглядит сканирование портов.
Смотрим на дамп и видим, что вначале происходит ARP запрос и затем непосредственно начинается сканирование. Адрес нашего маршрутизатора 192.168.10.11, сканирование идет с адреса 192.168.10.101



Это, так называемое, SYN сканирование, когда идут SYN-пакеты на указанный диапазон портов. Так как большинство портов закрыто, маршрутизатор отвечает пакетами RST, ACK.
Пролистав чуть ниже видим, что открыт telnet (tcp 23).



На это указывает то, что маршрутизатор ответил пакетом SYN, ACK.
К слову, для фильтрации портов в сниффере можно использовать конструкции вида: tcp.srcport, tcp.dstport и tcp.port. Для протокола UDP всё аналогично — udp.srcport, udp.dstport, udp.port.

Итоги


Мы пробежались по самым основным частям функционала лучшего анализатора пакетов.
Получилось несколько сумбурно, вероятно, потому что хотелось затронуть как можно больше его возможностей и не упустить ничего важного.
Оказалось, что анализатор пакетов, как отладчик и дизассемблер, демонстрирует мельчайшие подробности работы сети и сетевых протоколов.
Используя Wireshark и обладая необходимыми знаниями (которые можно почерпнуть изучив серию Сетей для Самых Маленьких на сайте linkmeup.ru) можно достаточно эффективно находить и диагностировать разнообразные проблемы, возникающие в сети.

В процессе написания использовались материалы сайта wiki.wireshark.org
Дампы с трафиком брались из разных источников, больше всего с сайта packetlife.net
Автор: @sinist3r
Pentestit
рейтинг 118,15
information security
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Комментарии (60)

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

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

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

    http~GET

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

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

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

      Теперь у вас видны только пакеты запроса\ответа, с «нулём» времени в точке запроса, таймстемпом для каждого следующего пакета, а общее время — это время последнего пакета.
    • 0
      Можно попробовать использовать Fiddler Web Debugger. Там принцип чуть другой — он ставится как прокси, но это более «высокоуровневый» инструмент и для анализа http траффика может оказаться удобнее. Я с его помощью разобрался с проблемой авторизации на TFS сервере, но, помнится, видел там что-то типа «Transfer Timeline» — может это то, что вам надо.
  • +2
    Тема не будет полной без описания распатронивания TLS соединений. В открытом виде сейчас летает все меньше и меньше данных. Особенно после сноуденбума.
    • +2
      Wireshark умеет раскрывать SSL / TLS сессии, но только при наличии сертификата.
      • +3
        При этом надо не забыть настроить сервер не использовать Perfect Forward Secrecy.
  • 0
    Добавлю про RTP. По умолчанию wireshark rtp пакеты не распознает и показывает простой udp траффик. Чтобы распознавал и можно было воспользоваться фичами с VOIP из статьи надо зайти в «Edit->Preferences->Protocols->RTP» и ставим галочку «try to decode rtp outside of conversations».
  • 0
    А не знаете, насколько сложно будет прикрутить к Wireshark свой виртуальный сетевой интерфейс?
    Допустим, есть USB-девайс, который сниффает пакеты, передающиеся по радио-каналу между другими девайсами. Я хочу передавать эти данные в Wireshark. Есть ли для этого механизм плагинов или что-то подобное?
    • 0
      Он умеет изначально слушать виртуальные интерфейсы, вроде тех, которые создают VMware или VirtualBox (не говоря уже про GNS/Dynamips).
      Вероятно многое будет зависеть и от вашего устройства.
      • 0
        Но у меня нет сетевого интерфейса в терминах операционной системы.
        Есть простая программа, получает поток байтов по USB и может их куда-нибудь передать. Я хочу сделать плагин для Wireshark, который будет связываться с этой программой.
        • 0
          Может проще будет сохранять весь поток в pcap файл, а потом уже открывать и анализировать в Wireshark'e?
          • 0
            Да, как вариант. Но тогда Wireshark не будет считывать то что дописывается в файл после открытия?
            • +1
              Есть вариант с использованием каналов (pipe), тут описан пример.
              Тогда можно будет добиться нечто похожего на риалтайм с использованием pcap файла.
    • +1
      Можно переписать packet.dll драйвер от winpcap. Просто все функции, которые должны быть в пакете, заменяются на свои и подсовываются туда нужные данные. Я таким образом декодировал HART протокол через модем подключенный к серийному порту. И все работало. Конечно нужно писать и свой диссектор (плагин), что бы трафик декодировался нормально. Кстати вот об этом было бы не плохо пост написать:
      создание плагина для wireshark.
  • 0
    Спасибо за статью! Было бы ещё интересно почитать о возможностях программирования на Lua под Wireshark с примерами.
  • 0
    Получилось очень похоже на курс от CBTNuggets. Было бы весьма интересно почитать про отчеты, которые можно генерировать… с практическими примерами…
  • 0
    Есть ли возможность как-то захватывать трафик на localhost?
    • +2
      В линуксе и BSD можно, под Windows нет.
      Если интересно, то про причину можно прочитать тут
      • 0
        Да, я под Windows имел ввиду, как-то полдня провозился, но так и не смог увидеть трафика на localhost.
        • +1
          Перехватывайте через RawCap, а анализируйте уже в WireShark.
          • 0
            Спасибо за наводку, при случае попробую.
  • 0
    Отличный инструмент, пользуюсь им каждый день! В комплекте с tshark незаменимая вещь. Сам разрабатывал для него NFSv41 декодер.
  • +1
    Отдельно хочется упомянуть возможность удалённого захвата траффика. К примеру, есть *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.
  • +1
    Хабр, прошу помощи! есть такой вот Девайс. Замечательная игрушка, но как всегда хочется большего. Появилась идея провести реверс-инжиниринг протокола, и попробовать управлять этим делом с компа. Сеть без шифрования, машинка создает точку, сама имеет 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 если добьюсь результатов — все подробно распишу с исходниками! Может кому будет интересно. )
    • 0
      А вы правильный интерфейс выбрали в окне Wireshark?
      • 0
        Да. В принципе я вижу ARP и DNS пакеты, когда планшет или телефон впервые получают IP, иногда что-то еще проскакивает от них, но непосредственно управляющих пакетов, которые могли бы содержать что-то управляющее данные — нет. Я просто не силен на самом деле в организации сетевых взаимодействий, но мне всегда казалось, что даже если данные сильно шифрованные там или используется какой-то свой неведомы протокол, то это все равно выше третьего, но в крайнем случае — второго уровня. Т.е. пакеты-ты то я должен видеть! Может не смогу понять что в них, но сами пакеты… Или нет? Или есть какие-то взаимодействия хитрые, которые шарк не увидит вообще? Ну, я далек от мысли, что программа на планшете может использовать вай-фай на сигнальном уровне…
        • 0
          Если приложение не работает напрямую с сетевой картой (очень-очень маловероятно), то wireshark видит все передаваемые пакеты. Кроме пакетов управления беспроводной сети, но см. п.1, приложение с ними не работает.

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

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

              Или запускайте wireshark на том же устройстве, которое управляет машиной.
              • 0
                вот засада! Программы управления есть под iOS (собственно мой планшет, это ipad) и под андроид (есть один девайс под рукой — еще не пробовал). Под Win|Mac|Lnx такого нету. А Shark наоборот соответственно… Т.е. я правильно понимаю, что я вижу в shark только те пакеты, которые или бродкаст, или предназначены/исходят с/на ту машину, на которой он запущен? Если да, то это все объясняет. commview говорите? ))
                • +1
                  Есть способы запуска андроида на x86 в виртуалке. Это сильно облегчит задачу.
                • 0
                  Поставьте на android tcpdump, сохраните им дамп, скопируйте на ПК и там анализируйте Wireshark'ом.

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

Самое читаемое Разработка