Захват сетевого трафика в Kali Linux +2


Привет, Хабр! На связи Рустем, IBM Senior DevOps Engineer & Integration Architect. Сегодня я хотел бы поговорить о сетевой безопасности. DevOps инженеру необходимо разбираться в сетях не хуже специализированного нетворк инженера. В этом же нам поможет Kali Linux и его инструментарий.

Kali Linux уже давно является дистрибутивом Linux для профессионалов в области безопасности. Kali Linux имеет большую коллекцию ориентированных на безопасность инструментов для пентестеров, специалистов по цифровой криминалистике, реверс-инженеров и других специалистов, которые хотят выполнять задачи, связанные с безопасностью, в среде Linux. В любое время, когда вы хотите выполнить тестирование безопасности, вы должны иметь возможность контролировать то, что вы делаете. Один из хороших способов сделать это — просмотреть сетевой трафик. У вас должна быть возможность перехватывать сетевые сообщения, чтобы вы могли анализировать происходящее и узнавать “the truth of communication”. Это может помочь вам решить множество проблем, с которыми вы можете столкнуться.

Источником правды, когда дело доходит до связи с одного компьютера на другой, является сеть. “Applications can lie” — Приложения могут лгать (или просто не сообщать вам, что было бы ложью по упущению). Когда один компьютер отправляет сообщение другому, единственным местом, где вы можете гарантировать получение правды, является сеть. Есть пара вещей, которые нужно знать, прежде чем мы начнем. Сетевые интерфейсы созданы для фильтрации, чтобы не перегружать принимающую операционную систему. Они делают это, проверяя адрес управления доступом к среде (MAC) в пункте назначения фрейма. Фрейм представляет собой набор заголовков уровня 2 для связи в локальной физической сети. Если MAC-адрес назначения совпадает с адресом, связанным с сетевым интерфейсом (физическим адресом), соответствующий пакет перенаправляется в операционную систему. Однако не весь трафик является одноадресным. Иногда по сети отправляются широковещательные(broadcast) сообщения, в том числе когда другой системе необходимо знать, какой MAC-адрес принадлежит указанному адресу интернет-протокола (IP). Эти бродкастовые сообщения также пересылаются в операционную систему для обработки операционной системой. Все остальное отбрасывается сетевым интерфейсом, потому что оно не имеет значения.

Мы, безусловно, можем выполнять захват пакетов в сообщениях, отправленных нам, чтобы мы могли видеть информацию, которая удаляется интерфейсом и операционной системой. Однако полезнее просматривать все сообщения, которые могут пройти через интерфейс. В те времена, когда для передачи сообщений из одной системы в другую использовались концентраторы, все сообщения в сети проходили через все системы. Сегодня мы используем коммутаторы (или беспроводные средства связи, выполняющие аналогичную функцию). Это означает, что на наш сетевой интерфейс отправляются только сообщения, предназначенные для нашей системы, и бродкастовые сообщения. Тем не менее, есть способы получить больше сообщений, которые можно сделать в сети, поэтому нам нужно перевести наш интерфейс в беспорядочный режим(promiscuous mode). Это говорит интерфейсу прекратить фильтровать проходящие сообщения и отправить все в операционную систему для обработки.

К счастью, tcpdump, программа, которую мы собираемся использовать для перехвата трафика, переведет интерфейс в правильный для нас режим. Как только это будет сделано, он начнет вытягивать все фреймы и отображать их. Хотя tcpdump часто называют программой захвата пакетов, технически то, что мы видим, является фреймом. Фрейм включает в себя заголовки уровня 2. Пакет — это имя блока данных протокола для уровня 3, на котором живет IP. Поскольку мы можем видеть заголовки уровня 2, это фрейм, но для простоты термин «пакет» часто используется для всего пакета.

К счастью, перехватить трафик на сетевом интерфейсе несложно. Мы просто запускаем tcpdump

Когда мы захватим достаточно трафика (или только что закончили захват трафика), нам нужно остановить tcpdump, нажав Ctrl-C.

Проблема с tcpdump заключается в том, что для его выполнения требуются права администратора. Он должен возиться с сетевым интерфейсом, а затем извлечь все содержимое фрейма/пакета из операционной системы, чтобы отобразить его вам. В большинстве систем Linux вы можете получить временные административные разрешения с помощью sudo. Это позволяет программе, которую вы указываете sudo для запуска, выполняться с повышенными разрешениями на время выполнения программы. Вот как вы получите необходимые разрешения в Kali Linux, если они понадобятся.

Некоторые системы имеют несколько сетевых интерфейсов. tcpdump использует интерфейс по умолчанию. Это означает, что существует единственный интерфейс, через который отправляются все сообщения, если не указан другой интерфейс. Если нам нужно захватить другой интерфейс, мы просто сообщаем tcpdump, какой интерфейс мы хотим захватить, используя -i <имя_интерфейса>. Например, мы можем использовать эту команду для захвата интерфейса eth0, который является обычным интерфейсом в моих системах:

Возможно, нам потребуется определить интерфейсы. Мы можем сделать это, запустив либо ifconfig, либо, в некоторых более современных системах, ip a. Результаты сообщат нам IP-адрес, связанный с каждым интерфейсом, что должно помочь нам определить интерфейс, который мы хотим захватить.

Умение перехватывать пакеты является важным навыком. В дополнение к возможности видеть, что происходит во время любого тестирования безопасности, сеть является источником правды, когда речь идет о взаимодействии с любым удаленным приложением. Мы будем точно видеть, что отправлено или получено, независимо от того, что может показывать вам приложение. Также важно выполнять любые действия по устранению неполадок на уровне сети. Когда нам нужно захватить пакеты, tcpdump — хороший инструмент в вашем арсенале.

Хотя tcpdump отлично подходит как утилита для захвата пакетов общего назначения, вы также можете использовать программу tshark. Это программа командной строки, которая устанавливается вместе с Wireshark. Он делает то же самое, что и Wireshark, но с некоторыми дополнительными преимуществами. Однако сначала давайте посмотрим, как просто использовать tshark для захвата пакетов в стандартный вывод, чтобы вы могли увидеть, как это выглядит. Как и в случае с tcpdump, вам потребуются права администратора для захвата пакетов. Это можно сделать с помощью службы, которую можно установить в системе, чтобы позволить обычным пользователям перехватывать пакеты, или вы можете использовать команду sudo для получения повышенных привилегий во время запуска tshark. В нашем случае мы уже являемся пользователем root, поэтому нам не нужно повышать какие-либо привилегии. Мы можем просто запустить tshark, как вы видите здесь:

Как и в случае с tcpdump, если вам нужно указать интерфейс, вы можете использовать свич — i:

То, что мы увидели — это то, что мы увидим в том же выводе tcpdump. Могут быть небольшие отличия, но основная информация имеется. У нас есть информация об источнике и получателе, но с tshark мы получаем небольшую заметку о том, что содержит пакет, точно так же, как мы видим в информационном поле в Wireshark. Например, если бы мы собирали трафик для порта 443 (что, как мы увидим, будет выполняться в следующей команде), мы бы увидели информацию о хэндшейке, когда оно происходит во время настройки шифрования с использованием TLS. Как только соединение будет установлено, tshark сообщит вам, что каждый перехваченный пакет содержит данные приложения, потому что это все, что ему может быть известно. Он не может прочитать информацию внутри пакета, потому что он зашифрован. Это позволяет вам видеть, как происходит хэндшейк и когда зашифрованные данные передаются между клиентом и сервером. Мы не можем точно видеть, что происходит, но мы будем знать, что шифрование успешно установлено.

Как и в случае с tcpdump, tshark позволяет использовать фильтры пакетов Berkeley, поэтому язык, используемый для фильтрации перехвата, такой же, как мы использовали ранее. Это позволяет нам контролировать то, что мы захватываем. В контексте того, что мы только что сделали, это фильтр отображения, потому что ничего не сохраняется; все отображается на терминале. Вы можете заметить, что мы не получаем много подробностей... только основную информацию о заголовке и немного информации о том, что, по мнению tshark, содержит пакет. Мы можем увеличить уровень детализации, хотя это отличается от того, как это делается с помощью tcpdump. Если мы попытаться использовать ту же технику с tshark, но мы получим уже другой тип вывода, как вы можете видеть из результатов этой команды:

Вместо данных перехвата пакетов он просто содержит информацию о версии. Поэтому мы должны использовать заглавную букву V, чтобы получить детали, как вы можете видеть с помощью этой команды:

Это позволяет нам увидеть весь дамп пакета, включая шестнадцатеричный дамп полезной нагрузки. Мы также можем записывать пакеты в файл с помощью tshark с ключом -w (так же, как мы бы делали с tcpdump). Как и раньше, нам нужно указать имя файла, который мы хотим сохранить:

Расширение файла здесь .pcap, хотя это просто для удобства операционных систем, которые используют расширения файлов для прикрепления файлов данных к программам. Вы можете использовать любое расширение файла, а затем открыть файл, выполнив поиск в такой программе, как например Wireshark.

Поскольку tshark поставляется с Wireshark, он просматривает пакет таким же образом. Отличительной особенностью Wireshark является модульность пакетов. Мы начинаем с чего-то вроде IP-пакета или TCP-сегмента и можем детализировать отдельные элементы данных. Например, если мы хотим посмотреть исходный адрес IP-пакета, то мы должны использовать ip.src в своем языке фильтрации в Wireshark. Например, можно сказать, что ip.src == 4.2.2.1, и Wireshark будет сопоставлять все пакеты, исходный IPv4-адрес которых равен 4.2.2.1.

Мы можем использовать этот набор полей и в tshark. Существует большое количество полей, поэтому, если вы хотите увидеть, что можно использовать,то  вы можете посетить https://www.wireshark.org/docs/dfref/, где вы найдете всю доступную информацию в списке.

Чтобы отображать только определенные поля в tshark, мы сообщаем программе, что собираемся установить собственный вывод на экран. Мы будем использовать свич -Tfields. Однако затем нам нужно указать поля, которые мы хотим отобразить на выходе. Мы могли бы сделать что-то простое, например просто показать исходный IP-адрес, как вы можете видеть здесь:

Однако это не особенно полезно. Просто просмотр исходного адреса мало что нам говорит, хотя он может дать вам возможность захватывать IP-адреса, которые вы можете использовать другими способами. Там, где синтаксический анализ вывода tcpdump может быть сложным, когда мы используем tshark, у нас есть контроль над тем, что мы видим. Если мы хотим увидеть немного больше, мы просто продолжаем добавлять -e в командную строку с дополнительными полями, которые мы хотим показать. Мы можем отобразить как исходный, так и конечный адреса с помощью этой команды:

Это немного лучше, хотя это все еще не намного. Вы, вероятно, хотите посмотреть на дополнительные детали. Это могут быть как IP-адреса, так и порты TCP, если они являются сегментами TCP. Возможно, лучший способ отобразить это — сохранить вместе адреса и порты, то есть адрес источника и порт, затем адрес назначения и порт. Поскольку мы указываем все поле от протокола вниз, это легко сделать:

По умолчанию мы получаем разделитель табуляции между полями, но это можно изменить. Мы можем указать выходные функции, используя -E, а затем символ, который мы хотим использовать. В случае с например запятой мы будем использовать следующую команду:

Умение перехватывать пакеты является важным навыком. В дополнение к возможности видеть, что происходит во время любого тестирования безопасности, сеть является источником правды, когда речь идет о взаимодействии с любым удаленным приложением. Вы будете точно видеть, что отправлено или получено, независимо от того, что может показывать вам приложение. Программа Wireshark — отличный инструмент для захвата и анализа пакетов. Пакет Wireshark включает утилиту командной строки tshark, которую можно использовать для захвата пакетов (которые затем можно сохранить и открыть позже в Wireshark для более глубокого анализа). tshark использует ту же философию и дизайн вывода, что и Wireshark, поэтому, если вы выполняете подробный захват, вывод будет выглядеть как простой текстовый дамп того, что вы видите в Wireshark. Кроме того, он делает много того же, что и tcpdump.

В заключение рекомендую обратить внимание на открытый урок, на котором разберем swap в Linux: что такое и зачем нужен, как он работает, какие данные в него уходят, за что отвечает параметр swappiness. В результате занятия у участников появится понимание структуры кеша в Lnux. Зарегистрироваться можно по ссылке.




Комментарии (10):

  1. Lev3250
    /#24964790 / +3

    Возможно я упускаю что-то фундаментальное, но...

    Если я подключен компьютером к порту свитча/роутера и свитч/роутер в своей таблице mac адресов сопоставляет меня с конкретным своим портом, то как переключение режима работы интерфейса на компьютере (на компьютере же, не на роутере, как я понял из статьи) поможет, если на этот тот физический порт, куда я подключен, свитч/роутер будет отправлять только мои пакеты и бродкасты?

    Или тут рассматривается подключение к hub (OSI L1), а не к switch (OSI L2/L3)?

    • Lev3250
      /#24971192

      Так как от автора статьи ответа, скорее всего, не будет, то отвечаю сам себе. Скорее всего в статье подразумевается беспроводное подключение и режим "monitor mode" в Kali Linux. В таком случае да, wifi адаптер будет слышать все пакеты в этом broadcast домене.

    • RedPandaHere
      /#24971818

      Ну может автор предполагает еще и arp спуфинг применить )

  2. micbal
    /#24965270

    Поражает ширина умений некоего мифичкеского "devops инженера". Теперь: "DevOps инженеру необходимо разбираться в сетях не хуже специализированного нетворк инженера". Остается добавить умение играть на скрипке, приуспеть в паурлифтинге, да и в боксе было бы неплохо. Что еще придумают авторы курсов? :)

    • grossws
      /#24965650 / +2

      На мой взгляд базовое уменение пользоваться wireshark/tcpdump необходимо как senior dev, так и линуксовому ops'y общего профиля. Мне в роли разработчика далеко не раз приходилось втыкаться wireshark'ом чтобы отловить проблемы с кодировками, компрессией, несброшенными буфферами, некорректным проксированием и т. п.

      Иногда бывает полезно воткнуться удаленно, но это уже обычно не для dev'а: wireshark -k -i <(ssh $REMOTE "tcpdump -s 0 -U -n -w - -i $INTERFACE [filters..]")

      • micbal
        /#24966238

        Умение смотреть трафик в wireshark, это не совсем то чем занимается сетевой инженер. Вот там всякие железки L2-L3, всякие маршрутизации, vlanы и т.д. (кучи протоколов, особенностей, облачных реализаций и т.п.) врятли снились даже синьору dev, да и зачем? Что для devops, так это сетевое взаимодействие, сетевые распределенные fs, и т.п. Синьор dev много знает про работу например Ceph, и почему из нее плохо читать чанками? В том то и дело...

        • grossws
          /#24966634 / +1

          Да это понятно, что dev иметь представление о сети полезно, но большая часть того чем занимается сетевой инженер -- совсем не его песочница. Здесь же статья была уровня недотуториал по шарку..

          Что же до ceph, если senior dev с ней взаимодействует (даже просто читает/пишет с/на смонтированный iscsi), то знать ограничения крайне желательно. Иначе будут fsync'ать после каждого байта (или 512) или выжрут все iops'ы когда в этом не было необходимости. Также как представлять что у разных хранилищ бывает сильно разный размер блока, знать характерные задержки для того io с которыми взаимодействует (и когда это знание станет важным). Как, в общем, с любой смежной областью с которой он имеет дело. Иначе разве это senior, если он живёт в парадигме monkey see -- monkey do?

    • rionnagel
      /#24965706 / +2

      Запустить tcpdump это не что-то узкоспециализированное. Это один из базовых инструментов диагностики. Банально посмотреть как/куда приходит/уходит трафик. Условный devops/build/sre/etc инженер если не будет знать базовые вещи про сети может словить гигансткое количество проблем в своей работе, при этом быть источником этих самых проблем.

      • micbal
        /#24966222

        Серьезно думаете что умения сетевого инженера со знанием сетевой безопасности, это запуск tcpdump-tshark?

        • rionnagel
          /#24966976

          Перечитайте своё сообщение, на которое которое я отвечал, а потом моё.