Инструмент реконструкции TCP-потоков из PCAP или живого захвата: сохраняет каждый поток в отдельный файл с учётом sequence numbers и ретрансмиссий, поддерживает HTTP-декодирование и вывод DFXML.
# Kali / Debian / Ubuntu sudo apt install tcpflow # Из исходников sudo apt install libpcap-dev libboost-dev git clone https://github.com/simsong/tcpflow cd tcpflow && ./configure && make && sudo make install # Пример: реконструкция TCP-потоков из pcap tcpflow -r capture.pcap -o output_dir/ # Live-захват на интерфейсе sudo tcpflow -c -i eth0 port 80
Каталог загрузок: http://digitalcorpora.org/downloads/tcpflow/
Большинство распространенных дистрибутивов GNU/Linux поставляют tcpflow в своих репозиториях. Поэтому на Debian/Ubuntu и т.д. вы можете сказать
sudo apt-get install tcpflow
а на Fedora/RedHat/CentOS и т.д. вы можете сказать
sudo dnf install tcpflow
И это всё. Если это по какой-то причине недостаточно, вы можете собрать из исходников:
Для компиляции в Linux
Убедитесь, что у вас есть необходимые предварительные пакеты. В корневом директории есть файлы, которые сделают это за вас, в зависимости от вашей операционной системы:
CONFIGURE_ARCH_17_8.sh CONFIGURE_FEDORA_18.sh CONFIGURE_FEDORA_26.sh CONFIGURE_UBUNTU_16_04.sh
В зависимости от вашей ОС, просто:
# sudo bash CONFIGURE_<ВАША_ОС>.sh
После настройки вашей ОС, скомпилируйте и установите с помощью:
./configure
make
sudo make install
Если вы хотите загрузить дерево разработки с помощью git, убедитесь, что делаете полную выгрузку с --recursive, а затем запустите bootstrap.sh, configure и make:
git clone --recursive https://github.com/simsong/tcpflow.git
cd tcpflow
bash bootstrap.sh
./configure
make
sudo make install
Для загрузки и компиляции в Amazon AMI:
ssh ec2-user@<ваш экземпляр ec2>
sudo bash yum -y install git make gcc-c++ automake autoconf boost-devel cairo-devel libpcap-devel openssl-devel zlib-devel
git clone --recursive https://github.com/simsong/tcpflow.git
sh bootstrap.sh
Для компиляции в Windows с помощью mingw в Fedora Core:
yum -y install mingw64-gcc mingw64-gcc-c++ mingw64-boost mingw64-cairo mingw64-zlib
mingw64-configure
make
Для использования CMake, см. подробные инструкции: cmake/README.md
Из чистого репозитория как обычный пользователь (не root):
./bootstrap.sh # Генерирует файл ./configure
./configure # Генерирует файл tcpflow.spec
rpmbint -bb tcpflow.spec --build-in-place
Проверьте spec-файл и полученный RPM:
rpmlint tcpflow.spec
rpmlint ~/rpmbuild/RPMS/x86_64/tcpflow-....rpm
Установка:
sudo dnf install ~/rpmbuild/RPMS/x86_64/tcpflow-....rpm
tcpflow — это программа, которая захватывает данные, передаваемые как часть TCP-соединений (потоков), и сохраняет их способом, удобным для анализа протоколов и отладки. Каждый TCP-поток сохраняется в собственном файле. Таким образом, типичный TCP-поток будет сохранен в двух файлах, по одному для каждого направления. tcpflow также может обрабатывать сохраненные пакетные потоки 'tcpdump'.
tcpflow сохраняет все захваченные данные в файлах, имена которых имеют вид:
[imestampT]sourceip.sourceport-destip.destport[--VLAN][cNNNN]
где:
timestamp - необязательная метка времени того момента, когда был замечен первый пакет
T - разделитель, указывающий, что была предоставлена метка времени
sourceip - исходный IP-адрес
sourceport - исходный порт
destip - IP-адрес назначения
destport - порт назначения
VLAN - порт VLAN
c - разделитель, указывающий, что присутствует несколько соединений
NNNN - счетчик соединений, когда есть несколько соединений с
одинаковой комбинацией [time]/sourceip/sourceport/destip/destport.
Обратите внимание, что подсчет соединений происходит редко, когда выполняется добавление метки времени.
ВОТ некоторые примеры:
128.129.130.131.02345-010.011.012.013.45103
Содержимое вышеуказанного файла будут данные, переданные от хоста 128.129.131.131 порта 2345 к хосту 10.11.12.13 порту 45103.
128.129.130.131.02345-010.011.012.013.45103c0005
Шестое соединение от 128.129.131.131 порта 2345 к хосту 10.11.12.13 порту 45103.
1325542703T128.129.130.131.02345-010.011.012.013.45103
Соединение от 128.129.131.131 порта 2345 к хосту 10.11.12.13 порту 45103, которое началось в 5:19 вечера (-0500) 2 января 2012 года.
128.129.130.131.02345-010.011.012.013.45103--3
Соединение от 128.129.131.131 порта 2345 к хосту 10.11.12.13 порту 45103, которое было замечено на порту VLAN 3.
Вы можете изменить шаблон, используемый для создания имен файлов, с помощью опций -F и -T. Если в шаблоне указан каталог, каталог будет создан автоматически.
Если вы используете опцию -a, tcpflow автоматически будет интерпретировать HTTP-ответы.
Если выходной файл
208.111.153.175.00080-192.168.001.064.37314,
тогда пост-обработка создаст файлы:
208.111.153.175.00080-192.168.001.064.37314-HTTP
208.111.153.175.00080-192.168.001.064.37314-HTTPBODY
Если HTTPBODY был сжат с помощью GZIP, вы можете также получить
третий файл:
208.111.153.175.00080-192.168.001.064.37314-HTTPBODY-GZIP
Дополнительная информация об этих потоках, такая как их хеш MD5,
также записывается в файл DFXML
tcpflow похож на 'tcpdump', тем, что оба обрабатывают пакеты из сети или из сохраненного файла. Но он отличается тем, что восстанавливает фактические потоки данных и сохраняет каждый поток в отдельном файле для последующего анализа.
tcpflow понимает порядковые номера и правильно восстанавливает потоки данных, независимо от повторных передач или доставки в неправильном порядке. Однако в настоящее время tcpflow не понимает IP-фрагменты; потоки, содержащие IP-фрагменты, не будут записаны правильно.
tcpflow может выводить файл сводного отчета в формате DFXML. Этот файл включает информацию о системе, в которой была скомпилирована программа tcpflow, о месте, где она была запущена, и о каждом TCP-потоке, включая IP-адреса и порты источника и назначения, количество байтов, количество пакетов и (опционально) хеш MD5 каждого потока байтов.
tcpflow использует библиотеку захвата пакетов LBL (доступную по адресу ftp://ftp.ee.lbl.gov/libpcap.tar.Z) и поэтому поддерживает те же богатые выражения фильтрации, которые поддерживают такие программы, как 'tcpdump'. Он должен компилироваться в большинстве популярных версий UNIX; подробности см. в файле INSTALL.
tcpflow — полезный инструмент для понимания сетевых пакетных потоков и выполнения сетевой криминалистики. В отличие от таких программ, как WireShark, которые показывают много пакетов или одно TCP-соединение, tcpflow может показать сотни, тысячи или сотни тысяч TCP-соединений в контексте.
Распространенное использование tcpflow — это раскрытие содержимого HTTP-сессий. С помощью tcpflow вы можете восстановить веб-страницы, загруженные по HTTP. Вы даже можете извлечь вредоносное ПО, доставляемое как «загрузки на основе.drive-by».
Джереми Элсон первоначально написал эту программу для захвата данных, передаваемых различными программами, использующими задокументированные сетевые протоколы, в попытке реверс-инжиниринга этих протоколов. RealPlayer (и большинство других проигрывателей потокового мультимедиа), ICQ и AOL IM — хорошие примеры такого типа приложений. Позже она использовалась для анализа протокола HTTP.
Симсон Гарфинкел основал Sandstorm Enterprises в 1998 году. Sandstorm создал программу, похожую на tcpflow, под названием TCPDEMUX и другую версию программы под названием NetIntercept. Эти программы являются коммерческими. После того, как Симсон ушел из Sandstorm, ему понадобилась программа для восстановления TCP-потоков. Он нашел tcpflow и взял на себя его поддержку.
Пожалуйста, вводите ошибки в трекере задач github
В настоящее время tcpflow не понимает IP-фрагменты. Потоки, содержащие IP-фрагменты, не будут записаны правильно. IP-фрагментация становится все более редким событием, поэтому это не кажется серьезной проблемой.
Если вы пишете статью о tcpflow, пожалуйста, процитируйте наш технический отчет: * Пассивное восстановление TCP и криминалистический анализ с помощью tcpflow, Симсон Гарфинкел и Майкл Шик, Технический отчет Военно-морской аспирантской школы NPS-CS-13-003, сентябрь 2013 г. https://calhoun.nps.edu/handle/10945/36026
Симсон Л. Гарфинкел simsong@acm.org ОТЧЕТ О СТАТУСЕ TCPFLOW 1.6 ========================= Я продолжаю портировать bulk_extractor, tcpflow, be13_api и dfxml на современный C++. После изучения стандартов я решил остановиться на C++17, а не на C++14, так как поддержка 17 теперь широко распространена. (Возможно, мне не нужен 20). Я придерживаюсь autotools, хотя, кажется, есть веская причина перейти на CMake. Я сохраняю be13_api и dfxml как модули, которые включаются в стиле Python, а не делаю их автономными библиотеками, с которыми они связываются. Я не уверен на 100%, что это правильное решение.
Проект занимает больше времени, чем ожидалось, потому что я также провожу общую рефакторинг кода. Основная причина задержки — понять, как разделить все объекты C++ связанные с опциями парсера и конфигурацией. Поскольку и tcpflow, и bulk_extractor используют be13_api, я переключил внимание на tcpflow для запуска be13_api, так как это более простая программа. Сейчас я завершил около трёх четвертей работы. Я рассчитываю выпустить готовый продукт до конца 2020 года.
--- Симсон Гарфинкель, 18 октября 2020
Благодарности: * Джеффри Пану за реализацию radiotap * Дагу Мэдори за парсер Wifi * Джереми Элсону за первоначальную идею и начальную реализацию tcp/ip