simsong/tcpflowمفكك تعدد حزم TCP/IP. تنزيل من:
دليل التحميلات: http://digitalcorpora.org/downloads/tcpflow/
معظم توزيعات GNU/Linux الشائعة تُوفّر tcpflow في مستودعاتها. لذا على دبيان/أوبونتو/إلخ يمكنك القول:
sudo apt-get install tcpflow
وعلى فيدورا/ريد هات/سينت أو إس/إلخ يمكنك القول:
sudo dnf install tcpflow
وهذا كل شيء. إذا لم يكن هذا كافياً لأي سبب، يمكنك البناء من المصدر:
لتجميع لينكس
تأكد من وجود المتطلبات الأساسية اللازمة. هناك ملفات في الدليل الجذر ستقوم بذلك نيابةً عنك، حسب نظام تشغيل المضيف:
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
من مستودع نظيف كمستخدم عادي (ليس الجذر):
./bootstrap.sh # يُنشئ الملف ./configure
./configure # يُنشئ الملف tcpflow.spec
rpmbuild -bb tcpflow.spec --build-in-place
تحقق من ملف المواصفات و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 جميع البيانات الملتقطة في ملفات بأسماء على الشكل:
[timestampT]sourceip.sourceport-destip.destport[--VLAN][cNNNN]
حيث: timestamp هو طابع زمني اختياري لوقت رؤية أول حزمة T هو فاصل يشير إلى وجود طابع زمني sourceip هو عنوان IP المصدر sourceport هو منفذ المصدر destip هو عنوان IP الوجهة destport هو منفذ الوجهة VLAN هو منفذ VLAN c هو فاصل يشير إلى وجود اتصالات متعددة NNNN هو عداد الاتصال، عند وجود اتصالات متعددة بنفس مجموعة [الوقت]/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. يمكنك أيضًا استخراج البرامج الضارة التي تم تسليمها كـ 'تنزيلات قيادة'.
كتب Jeremy Elson هذا البرنامج أصلاً لالتقاط البيانات التي ترسلها برامج مختلفة تستخدم بروتوكولات شبكة غير موثقة في محاولة لعكس هندسة تلك البروتوكولات. RealPlayer (ومعظم مشغلات الوسائط المتدفقة الأخرى)، ICQ، و AOL IM هي أمثلة جيدة على هذا النوع من التطبيقات. تم استخدامه لاحقًا لتحليل بروتوكول HTTP.
أسس Simson Garfinkel شركة Sandstorm Enterprises في عام 1998. أنشأت Sandstorm برنامجًا مشابهًا لـ tcpflow يُسمى TCPDEMUX ونسخة أخرى من البرنامج تُسمى NetIntercept. هذه البرامج تجارية. بعد أن غادر Simson Sandstorm، احتاج إلى برنامج لإعادة تجميع تدفقات TCP. وجد tcpflow وتولى صيانته.
يرجى إدخال الأخطاء في متتبع المشكلات على جيثب
لا يفهم tcpflow حاليًا شظايا IP. لن يتم تسجيل التدفقات التي تحتوي على شظايا IP بشكل صحيح. تجزئة IP أصبحت حدثًا نادرًا بشكل متزايد، لذا لا يبدو أن هذه مشكلة كبيرة.
إذا كنت تكتب مقالًا عن tcpflow، يرجى الاستشهاد بتقريرنا الفني:
Simson L. Garfinkel [email protected]
لا زلت أواصل نقل bulk_extractor و tcpflow و be13_api و dfxml إلى C++ الحديثة. بعد دراسة المعايير، قررت التوجه إلى C++17 وليس C++14، لأن الدعم لـ 17 أصبح واسع الانتشار الآن. (ربما لا أحتاج 20). ألتزم بأدوات autotools، على الرغم من وجود سبب قوي للانتقال إلى CMake. أحافظ على be13_api و dfxml كوحدات مضمنة، على غرار بايثون، بدلاً من جعلها مكتبات مستقلة يتم الربط معها. لست متأكدة 100% من صحة هذا القرار.
يستغرق المشروع وقتًا أطول من المتوقع لأنني أقوم أيضًا بإعادة هيكلة عامة للكود. الشيء الرئيسي الذي يستغرق وقتًا هو معرفة كيفية فك تشابك كل كائنات C++ المتعلقة بخيارات المحلل اللغوي والتكوين.
نظرًا لأن tcpflow و bulk_extractor يستخدمان كليهما be13_api، تحول اهتمامي إلى استخدام tcpflow لجعل be13_api قيد التشغيل، لأنه برنامج أبسط. لقد قطعت حوالي ثلاثة أرباع الطريق الآن. أتوقع أن يكون لدي شيء منتهٍ قبل نهاية عام 2020.
--- Simson Garfinkel، 18 أكتوبر 2020
شكرًا لـ: