تسعى مجموعة الوثائق لهذا المنتج جاهدة لاستخدام لغة خالية من التحيز. لأغراض مجموعة الوثائق هذه، يتم تعريف "خالية من التحيز" على أنها لغة لا تعني التمييز على أساس العمر، والإعاقة، والجنس، والهوية العرقية، والهوية الإثنية، والتوجه الجنسي، والحالة الاجتماعية والاقتصادية، والتمييز متعدد الجوانب. قد تكون الاستثناءات موجودة في الوثائق بسبب اللغة التي يتم تشفيرها بشكل ثابت في واجهات المستخدم الخاصة ببرنامج المنتج، أو اللغة المستخدمة بناءً على وثائق RFP، أو اللغة التي يستخدمها منتج الجهة الخارجية المُشار إليه. تعرّف على المزيد حول كيفية استخدام Cisco للغة الشاملة.
ترجمت Cisco هذا المستند باستخدام مجموعة من التقنيات الآلية والبشرية لتقديم محتوى دعم للمستخدمين في جميع أنحاء العالم بلغتهم الخاصة. يُرجى ملاحظة أن أفضل ترجمة آلية لن تكون دقيقة كما هو الحال مع الترجمة الاحترافية التي يقدمها مترجم محترف. تخلي Cisco Systems مسئوليتها عن دقة هذه الترجمات وتُوصي بالرجوع دائمًا إلى المستند الإنجليزي الأصلي (الرابط متوفر).
يصف هذا المستند تقنيات تحليل مختلفة لالتقاط الحزم تهدف إلى استكشاف مشكلات الشبكة وإصلاحها بفاعلية.
توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:
بالإضافة إلى ذلك، قبل البدء في تحليل التقاط الحزم، من المستحسن بشدة تلبية هذه المتطلبات:
تستند المعلومات الواردة في هذا المستند إلى إصدارات البرامج والمكونات المادية التالية:
تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.
التقاط الحزمة هو أحد أدوات أستكشاف الأخطاء وإصلاحها الأكثر إهمالا المتوفرة اليوم. يوميا، يحل TAC من Cisco العديد من المشاكل مع تحليل البيانات الملتقطة.
الهدف من هذا المستند هو مساعدة مهندسي الشبكة والأمان في تحديد مشاكل الشبكة الشائعة واستكشاف أخطائها وإصلاحها استنادا إلى تحليل التقاط الحزم أساسا.
تستند جميع السيناريوهات المقدمة في هذا المستند إلى حالات مستخدم حقيقي شوهدت في مركز المساعدة التقنية (TAC) من Cisco.
يغطي المستند عمليات التقاط الحزمة من وجهة نظر جدار حماية الجيل التالي (NGFW) من Cisco، ولكن يتم تطبيق نفس المفاهيم على أنواع الأجهزة الأخرى أيضا.
في حالة جهاز أمان FirePOWER (1xxx، 21xx، 41xx، 93xx) وتطبيق Firepower Threat Defense (FTD)، يمكن عرض معالجة الحزمة كما هو موضح في الصورة.
استنادا إلى البنية الموضحة، يمكن التقاط "برنامج الإرسال فائق السرعة (FTD)" في ثلاثة (3) أماكن مختلفة:
يتم وصف العملية في هذا المستند:
يمكن التقاط FXOS فقط أن تؤخذ في إتجاه المدخل من نقطة عرض المحول الداخلي تظهر في الصورة هنا.
كما هو موضح هنا، هاتان نقطتا التقاط لكل إتجاه (بسبب بنية المحول الداخلي).
تتضمن الحزم الملتقطة في النقاط 2، 3، و 4 علامة شبكة ظاهرية (VNTag).
ملاحظة: لا تتوفر التقاط على مستوى الهيكل بنظام FXOS إلا على نظامي FP41xx و FP93xx الأساسيين. لا توفر FP1xxx و FP21xx هذه الإمكانية.
نقاط الالتقاط الرئيسية:
يمكنك إستخدام واجهة المستخدم الخاصة ب Firepower Management Center (واجهة مستخدم FMC) أو واجهة سطر الأوامر (CLI) الخاصة ب FTD لتمكين وتجميع عمليات الالتقاط الخاصة ب FTD Lina.
تمكين الالتقاط من CLI على الواجهة الداخلية:
firepower# capture CAPI interface INSIDE match icmp host 192.168.103.1 host 192.168.101.1
يتطابق هذا الالتقاط مع حركة المرور بين IPs 192.168.103.1 و 192.168.101.1 في كلا الاتجاهين.
تمكين التقاط ASP لرؤية جميع الحزم التي تم إسقاطها بواسطة محرك FTD Lina:
firepower# capture ASP type asp-drop all
تصدير التقاط خط FTD إلى خادم FTP:
firepower# copy /pcap capture:CAPI ftp://ftp_username:ftp_password@192.168.78.73/CAPI.pcap
تصدير التقاط خط FTD إلى خادم TFTP:
firepower# copy /pcap capture:CAPI tftp://192.168.78.73
بدءا من إصدار FMC 6.2.x، يمكنك تمكين وتجميع مجموعات FTD Lina من واجهة مستخدم FMC.
هناك طريقة أخرى لتجميع لقطات FTD من جدار حماية تتم إدارته من قبل FMC، وهي:
الخطوة 1
في حالة LINA أو ASP الالتقاط انسخ الالتقاط إلى قرص FTD.
firepower# copy /pcap capture:capin disk0:capin.pcap Source capture name [capin]? Destination filename [capin.pcap]? !!!!
الخطوة 2
انتقل إلى وضع الخبير، وحدد مكان الالتقاط المحفوظ، ثم انسخه إلى موقع /ngfw/var/shared:
firepower# Console connection detached. > expert admin@firepower:~$ sudo su Password: root@firepower:/home/admin# cd /mnt/disk0 root@firepower:/mnt/disk0# ls -al | grep pcap -rwxr-xr-x 1 root root 24 Apr 26 18:19 CAPI.pcap -rwxr-xr-x 1 root root 30110 Apr 8 14:10 capin.pcap -rwxr-xr-x 1 root root 6123 Apr 8 14:11 capin2.pcap root@firepower:/mnt/disk0# cp capin.pcap /ngfw/var/common
الخطوة 3
قم بتسجيل الدخول إلى وحدة التحكم في الإدارة (FMC) التي تدير بروتوكول FTD وتنقل إلى الأجهزة > إدارة الأجهزة. حدد موقع جهاز FTD وحدد أيقونة أستكشاف الأخطاء وإصلاحها:
الخطوة 4
تحديد أستكشاف الأخطاء وإصلاحها المتقدم:
حدد اسم ملف الالتقاط وحدد تنزيل:
للحصول على مزيد من الأمثلة حول كيفية تمكين/تجميع الالتقاط من واجهة مستخدم FMC، تحقق من هذا المستند:
تظهر نقطة الالتقاط في الصورة هنا.
تمكين التقاط مستوى Snort:
> capture-traffic Please choose domain to capture traffic from: 0 - br1 1 - Router Selection? 1 Please specify tcpdump options desired. (or enter '?' for a list of supported options) Options: -n host 192.168.101.1
لكتابة الالتقاط إلى ملف باسم capture.pcap ونسخه من خلال FTP إلى خادم بعيد:
> capture-traffic Please choose domain to capture traffic from: 0 - br1 1 - Router Selection? 1 Please specify tcpdump options desired. (or enter '?' for a list of supported options) Options: -w capture.pcap host 192.168.101.1 CTRL + C <- to stop the capture
> file copy 10.229.22.136 ftp / capture.pcap Enter password for ftp@10.229.22.136: Copying capture.pcap Copy successful. >
لمزيد من أمثلة الالتقاط على مستوى الشخير التي تتضمن عوامل تصفية التقاط مختلفة تحقق من هذا المستند:
المخطط موضح في الصورة هنا:
وصف المشكلة: HTTP لا يعمل
التدفق المتأثر:
SRC IP: 192.168.0.100
DST IP: 10.10.1.100
البروتوكول: TCP 80
تمكين الالتقاط على محرك FTD LINA:
firepower# capture CAPI int INSIDE match ip host 192.168.0.100 host 10.10.1.100 firepower# capture CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100
التقاط - السيناريو الوظيفي:
كخط أساس، من المفيد جدا دائما أن تحصل على لقطات من سيناريو وظيفي.
يتم التقاط واجهة NGFW Inside على النحو الموضح في الصورة:
النقاط الرئيسية:
يتم عرض التقاط الواجهة الخارجية ل NGFW، في الصورة هنا:
النقاط الرئيسية:
التقاط - سيناريو لا يعمل
من خلال واجهة سطر الأوامر (CLI) الخاصة بالجهاز، تبدو الصور بهذا الشكل:
firepower# show capture capture CAPI type raw-data interface INSIDE [Capturing - 484 bytes] match ip host 192.168.0.100 host 10.10.1.100 capture CAPO type raw-data interface OUTSIDE [Capturing - 0 bytes] match ip host 192.168.0.100 host 10.10.1.100
محتويات CAPI:
firepower# show capture CAPI 6 packets captured 1: 11:47:46.911482 192.168.0.100.3171 > 10.10.1.100.80: S 1089825363:1089825363(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 2: 11:47:47.161902 192.168.0.100.3172 > 10.10.1.100.80: S 3981048763:3981048763(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 3: 11:47:49.907683 192.168.0.100.3171 > 10.10.1.100.80: S 1089825363:1089825363(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 4: 11:47:50.162757 192.168.0.100.3172 > 10.10.1.100.80: S 3981048763:3981048763(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 5: 11:47:55.914640 192.168.0.100.3171 > 10.10.1.100.80: S 1089825363:1089825363(0) win 8192 <mss 1460,nop,nop,sackOK> 6: 11:47:56.164710 192.168.0.100.3172 > 10.10.1.100.80: S 3981048763:3981048763(0) win 8192 <mss 1460,nop,nop,sackOK>
firepower# show capture CAPO 0 packet captured 0 packet shown
هذه صورة لالتقاط CAPI في Wireshark:
النقاط الرئيسية:
واستنادا إلى الفصلين، يمكن إستنتاج ما يلي:
والغرض من الإجراءات الواردة في هذا الفرع هو زيادة تضييق نطاق هذه المسألة.
الإجراء 1. تحقق من تتبع حزمة محاكية.
أستخدم أداة packet-tracer لمعرفة كيفية معالجة حزمة بواسطة جدار الحماية. في حالة إسقاط الحزمة بواسطة نهج الوصول إلى جدار الحماية، يبدو تتبع الحزمة المحاكية مماثلا لهذا الإخراج:
firepower# packet-tracer input INSIDE tcp 192.168.0.100 11111 10.10.1.100 80 Phase: 1 Type: CAPTURE Subtype: Result: ALLOW Config: Additional Information: MAC Access list Phase: 2 Type: ACCESS-LIST Subtype: Result: ALLOW Config: Implicit Rule Additional Information: MAC Access list Phase: 3 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 192.168.2.72 using egress ifc OUTSIDE Phase: 4 Type: ACCESS-LIST Subtype: log Result: DROP Config: access-group CSM_FW_ACL_ global access-list CSM_FW_ACL_ advanced deny ip any any rule-id 268439946 event-log flow-start access-list CSM_FW_ACL_ remark rule-id 268439946: ACCESS POLICY: FTD_Policy - Default access-list CSM_FW_ACL_ remark rule-id 268439946: L4 RULE: DEFAULT ACTION RULE Additional Information: Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: OUTSIDE output-status: up output-line-status: up Action: drop Drop-reason: (acl-drop) Flow is denied by configured rule, Drop-location: frame 0x00005647a4f4b120 flow (NA)/NA
الإجراء 2. تحقق من آثار الحزم المباشرة.
قم بتمكين تتبع الحزمة للتحقق من كيفية معالجة حزم TCP syn الحقيقية بواسطة جدار الحماية. بشكل افتراضي، يتم تتبع أول 50 حزمة مدخل فقط:
firepower# capture CAPI trace
مسح مخزن الالتقاط المؤقت:
firepower# clear capture /all
في حالة إسقاط الحزمة بواسطة نهج الوصول إلى جدار الحماية، يبدو التتبع مشابها لهذا الإخراج:
firepower# show capture CAPI packet-number 1 trace 6 packets captured 1: 12:45:36.279740 192.168.0.100.3630 > 10.10.1.100.80: S 2322685377:2322685377(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> Phase: 1 Type: CAPTURE Subtype: Result: ALLOW Config: Additional Information: MAC Access list Phase: 2 Type: ACCESS-LIST Subtype: Result: ALLOW Config: Implicit Rule Additional Information: MAC Access list Phase: 3 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 192.168.2.72 using egress ifc OUTSIDE Phase: 4 Type: ACCESS-LIST Subtype: log Result: DROP Config: access-group CSM_FW_ACL_ global access-list CSM_FW_ACL_ advanced deny ip any any rule-id 268439946 event-log flow-start access-list CSM_FW_ACL_ remark rule-id 268439946: ACCESS POLICY: FTD_Policy - Default access-list CSM_FW_ACL_ remark rule-id 268439946: L4 RULE: DEFAULT ACTION RULE Additional Information: Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: OUTSIDE output-status: up output-line-status: up Action: drop Drop-reason: (acl-drop) Flow is denied by configured rule, Drop-location: frame 0x00005647a4f4b120 flow (NA)/NA 1 packet shown
الإجراء 3. تحقق من سجلات FTD Lina.
لتكوين Syslog على FTD عبر FMC، تحقق من هذا المستند:
من المستحسن بشدة أن يتم تكوين خادم syslog خارجي لسجلات FTD Lina. في حالة عدم تكوين خادم syslog عن بعد، قم بتمكين سجلات المخزن المؤقت المحلية على جدار الحماية أثناء أستكشاف الأخطاء وإصلاحها. تكوين السجل الظاهر في هذا المثال هو نقطة بداية جيدة:
firepower# show run logging … logging enable logging timestamp logging buffer-size 1000000 logging buffered informational
اضبط جهاز النداء الطرفي على 24 سطرا للتحكم في جهاز النداء الطرفي:
firepower# terminal pager 24
مسح مخزن الالتقاط المؤقت:
firepower# clear logging buffer
اختبر الاتصال وفحص السجلات باستخدام عامل تصفية المحلل. في هذا المثال، يتم إسقاط الحزم بواسطة نهج الوصول إلى جدار الحماية:
firepower# show logging | include 10.10.1.100 Oct 09 2019 12:55:51: %FTD-4-106023: Deny tcp src INSIDE:192.168.0.100/3696 dst OUTSIDE:10.10.1.100/80 by access-group "CSM_FW_ACL_" [0x97aa021a, 0x0] Oct 09 2019 12:55:51: %FTD-4-106023: Deny tcp src INSIDE:192.168.0.100/3697 dst OUTSIDE:10.10.1.100/80 by access-group "CSM_FW_ACL_" [0x97aa021a, 0x0] Oct 09 2019 12:55:54: %FTD-4-106023: Deny tcp src INSIDE:192.168.0.100/3696 dst OUTSIDE:10.10.1.100/80 by access-group "CSM_FW_ACL_" [0x97aa021a, 0x0] Oct 09 2019 12:55:54: %FTD-4-106023: Deny tcp src INSIDE:192.168.0.100/3697 dst OUTSIDE:10.10.1.100/80 by access-group "CSM_FW_ACL_" [0x97aa021a, 0x0]
الإجراء 4. تحقق من عمليات إسقاط ASP لجدار الحماية.
إذا كنت تشك في أن الحزمة سقطت من جدار الحماية، فيمكنك رؤية عدادات جميع الحزم التي أسقطتها جدار الحماية على مستوى البرنامج:
firepower# show asp drop Frame drop: No route to host (no-route) 234 Flow is denied by configured rule (acl-drop) 71 Last clearing: 07:51:52 UTC Oct 10 2019 by enable_15 Flow drop: Last clearing: 07:51:52 UTC Oct 10 2019 by enable_15
يمكنك تمكين عمليات الالتقاط لعرض جميع عمليات إسقاط مستوى برنامج ASP:
firepower# capture ASP type asp-drop all buffer 33554432 headers-only
تلميح: إذا لم تكن مهتما بمحتويات الحزمة يمكنك التقاط رؤوس الحزمة فقط (خيار الرؤوس فقط). وهذا يتيح لك التقاط المزيد من الحزم في مخزن الالتقاط المؤقت. بالإضافة إلى ذلك، يمكنك زيادة حجم مخزن الالتقاط المؤقت (بشكل افتراضي هو 500 كيلوبايت) إلى قيمة تصل إلى 32 ميجابت (خيار المخزن المؤقت). أخيرا، بدءا من الإصدار 6.3 من بروتوكول FTD، يتيح لك خيار حجم الملف تكوين ملف التقاط حتى 10 جيجابايت. في تلك الحالة يمكنك فقط رؤية محتويات الالتقاط بتنسيق PCAP.
للتحقق من محتويات الالتقاط، يمكنك إستخدام مرشح لتضييق نطاق البحث:
firepower# show capture ASP | include 10.10.1.100 18: 07:51:57.823672 192.168.0.100.12410 > 10.10.1.100.80: S 1870382552:1870382552(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 19: 07:51:58.074291 192.168.0.100.12411 > 10.10.1.100.80: S 2006489005:2006489005(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 26: 07:52:00.830370 192.168.0.100.12410 > 10.10.1.100.80: S 1870382552:1870382552(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 29: 07:52:01.080394 192.168.0.100.12411 > 10.10.1.100.80: S 2006489005:2006489005(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 45: 07:52:06.824282 192.168.0.100.12410 > 10.10.1.100.80: S 1870382552:1870382552(0) win 8192 <mss 1460,nop,nop,sackOK> 46: 07:52:07.074230 192.168.0.100.12411 > 10.10.1.100.80: S 2006489005:2006489005(0) win 8192 <mss 1460,nop,nop,sackOK>
في هذه الحالة، بما أن الحزم يتم تعقبها بالفعل على مستوى الواجهة، فلا يتم ذكر سبب الإسقاط في التقاط ASP. تذكر أنه يمكن تعقب الحزمة فقط في مكان واحد (واجهة الدخول أو إسقاط ASP). في هذه الحالة، يوصى بأخذ عمليات إسقاط ASP متعددة وتعيين سبب إسقاط ASP محدد. وفي ما يلي النهج الموصى به:
1. قم بمسح عدادات إسقاط ASP الحالية:
firepower# clear asp drop
2. إرسال التدفق الذي تقوم باستكشاف أخطائه وإصلاحها من خلال جدار الحماية (تشغيل إختبار).
3. تحقق مرة أخرى من عدادات إسقاط ASP ولاحظ أنها قد تمت زيادتها.
firepower# show asp drop Frame drop: No route to host (no-route) 234 Flow is denied by configured rule (acl-drop) 71
4. تمكين التقاط (التقاط) ASP لعمليات الإسقاط المحددة التي يتم رؤيتها:
firepower# capture ASP_NO_ROUTE type asp-drop no-route firepower# capture ASP_ACL_DROP type asp-drop acl-drop
5. إرسال التدفق الذي تقوم باستكشاف الأخطاء وإصلاحها من خلال جدار الحماية (تشغيل إختبار).
6. تحقق من مجموعات ASP. في هذه الحالة، تم إسقاط الحزم بسبب مسار غير موجود:
firepower# show capture ASP_NO_ROUTE | include 192.168.0.100.*10.10.1.100 93: 07:53:52.381663 192.168.0.100.12417 > 10.10.1.100.80: S 3451917925:3451917925(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 95: 07:53:52.632337 192.168.0.100.12418 > 10.10.1.100.80: S 1691844448:1691844448(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 101: 07:53:55.375392 192.168.0.100.12417 > 10.10.1.100.80: S 3451917925:3451917925(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 102: 07:53:55.626386 192.168.0.100.12418 > 10.10.1.100.80: S 1691844448:1691844448(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 116: 07:54:01.376231 192.168.0.100.12417 > 10.10.1.100.80: S 3451917925:3451917925(0) win 8192 <mss 1460,nop,nop,sackOK> 117: 07:54:01.626310 192.168.0.100.12418 > 10.10.1.100.80: S 1691844448:1691844448(0) win 8192 <mss 1460,nop,nop,sackOK>
الإجراء 5. تحقق من جدول اتصال FTD Lina.
يمكن أن يكون هناك حالات تتوقع فيها أن تخرج الحزمة واجهة 'X'، ولكن لأي سبب كان فإنها تعرض الواجهة 'Y'. يستند تحديد واجهة مخرج جدار الحماية إلى ترتيب التشغيل هذا:
للتحقق من جدول اتصال FTD:
firepower# show conn 2 in use, 4 most used Inspect Snort: preserve-connection: 2 enabled, 0 in effect, 4 most enabled, 0 most in effect TCP DMZ 10.10.1.100:80 INSIDE 192.168.0.100:11694, idle 0:00:01, bytes 0, flags aA N1 TCP DMZ 10.10.1.100:80 INSIDE 192.168.0.100:11693, idle 0:00:01, bytes 0, flags aA N1
النقاط الرئيسية:
يمكن تصور هذا في الصورة هنا:
ملاحظة: بما أن جميع واجهات FTD تحتوي على مستوى أمان مقداره 0 أمر الواجهة في إخراج show conn استنادا إلى رقم الواجهة. وعلى وجه الخصوص، يتم تحديد الواجهة ذات رقم واجهة النظام الأساسي الظاهري (VPIF-num) الأعلى على أنها داخلية بينما يتم تحديد الواجهة ذات رقم واجهة النظام الأساسي الظاهري (VPIF-num الأقل) على أنها خارجية. أنت يستطيع رأيت القارن vpif قيمة مع العرض قارن تفصيل أمر. التحسينات ذات الصلة، معرف تصحيح الأخطاء من Cisco CSCvi15290 ENH: يعرض FTD إتجاه الاتصال في إخراج "show conn" من FTD
firepower# show interface detail | i Interface number is|Interface [P|E].*is up ... Interface Ethernet1/2 "INSIDE", is up, line protocol is up Interface number is 19 Interface Ethernet1/3.202 "OUTSIDE", is up, line protocol is up Interface number is 20 Interface Ethernet1/3.203 "DMZ", is up, line protocol is up Interface number is 22
ملاحظة: كما هو الحال من إصدار برنامج FirePOWER الإصدار 6.5، ASA الإصدار 9.13.x يوفر إخراج الأمر show conn long و show conn detail معلومات حول بادئ الاتصال والمستجيب
الناتج 1:
firepower# show conn long ... TCP OUTSIDE: 192.168.2.200/80 (192.168.2.200/80) INSIDE: 192.168.1.100/46050 (192.168.1.100/46050), flags aA N1, idle 3s, uptime 6s, timeout 30s, bytes 0 Initiator: 192.168.1.100, Responder: 192.168.2.200 Connection lookup keyid: 228982375
الناتج 2:
firepower# show conn detail ... TCP OUTSIDE: 192.168.2.200/80 INSIDE: 192.168.1.100/46050, flags aA N1, idle 4s, uptime 11s, timeout 30s, bytes 0 Initiator: 192.168.1.100, Responder: 192.168.2.200 Connection lookup keyid: 228982375
وبالإضافة إلى ذلك، يعرض العرض طويل NATed IPs داخل أقواس في حالة ترجمة عنوان الشبكة:
firepower# show conn long ... TCP OUTSIDE: 192.168.2.222/80 (192.168.2.222/80) INSIDE: 192.168.1.100/34792 (192.168.2.150/34792), flags aA N1, idle 0s, uptime 0s, timeout 30s, bytes 0, xlate id 0x2b5a8a4314c0 Initiator: 192.168.1.100, Responder: 192.168.2.222 Connection lookup keyid: 262895
الإجراء 6. تحقق من ذاكرة التخزين المؤقت لبروتوكول تحليل عنوان جدار الحماية (ARP).
إذا تعذر على جدار الحماية حل المرحلة التالية، يقوم جدار الحماية بإسقاط الحزمة الأصلية (TCP SYN في هذه الحالة) بشكل صامت وإرسال طلبات ARP باستمرار حتى يقوم بحل المرحلة التالية.
لعرض ذاكرة التخزين المؤقت ل ARP لجدار الحماية، أستخدم الأمر:
firepower# show arp
بالإضافة إلى ذلك، للتحقق من وجود مضيفين غير محالين، يمكنك إستخدام الأمر:
firepower# show arp statistics Number of ARP entries in ASA: 0 Dropped blocks in ARP: 84 Maximum Queued blocks: 3 Queued blocks: 0 Interface collision ARPs Received: 0 ARP-defense Gratuitous ARPS sent: 0 Total ARP retries: 182 < indicates a possible issue for some hosts Unresolved hosts: 1 < this is the current status Maximum Unresolved hosts: 2
إذا كنت تريد إجراء مزيد من الفحص لعملية ARP، فيمكنك تمكين التقاط خاص ب ARP:
firepower# capture ARP ethernet-type arp interface OUTSIDE firepower# show capture ARP ... 4: 07:15:16.877914 802.1Q vlan#202 P0 arp who-has 192.168.2.72 tell 192.168.2.50 5: 07:15:18.020033 802.1Q vlan#202 P0 arp who-has 192.168.2.72 tell 192.168.2.50
في هذا الإخراج، يحاول جدار الحماية (192.168.2.50) حل المرحلة التالية (192.168.2.72)، ولكن لا يوجد رد ARP
تعرض المخرجات هنا سيناريو وظيفي بدقة ARP المناسبة:
firepower# show capture ARP 2 packets captured 1: 07:17:19.495595 802.1Q vlan#202 P0 arp who-has 192.168.2.72 tell 192.168.2.50 2: 07:17:19.495946 802.1Q vlan#202 P0 arp reply 192.168.2.72 is-at 4c:4e:35:fc:fc:d8 2 packets shown
firepower# show arp INSIDE 192.168.1.71 4c4e.35fc.fcd8 9 OUTSIDE 192.168.2.72 4c4e.35fc.fcd8 9
في حالة عدم وجود إدخال ARP في المكان يظهر تتبع لحزمة TCP SYN المباشرة:
firepower# show capture CAPI packet-number 1 trace 6 packets captured 1: 07:03:43.270585 192.168.0.100.11997 > 10.10.1.100.80: S 4023707145:4023707145(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> Phase: 1 Type: CAPTURE Subtype: Result: ALLOW Config: Additional Information: MAC Access list Phase: 2 Type: ACCESS-LIST Subtype: Result: ALLOW Config: Implicit Rule Additional Information: MAC Access list Phase: 3 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 192.168.2.72 using egress ifc OUTSIDE … Phase: 14 Type: FLOW-CREATION Subtype: Result: ALLOW Config: Additional Information: New flow created with id 4814, packet dispatched to next module … Phase: 17 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 192.168.2.72 using egress ifc OUTSIDE Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: OUTSIDE output-status: up output-line-status: up Action: allow
كما يمكن رؤيته في الإخراج، يظهر التتبع الإجراء: السماح حتى عندما لا تكون الخطوة التالية قابلة للوصول ويتم إسقاط الحزمة بصمت بواسطة جدار الحماية! في هذه الحالة، الربط-tracer أداة ينبغي أيضا فحصت بما أن هو يوفر أكثر دقة إنتاج:
firepower# packet-tracer input INSIDE tcp 192.168.0.100 1111 10.10.1.100 80 Phase: 1 Type: CAPTURE Subtype: Result: ALLOW Config: Additional Information: MAC Access list Phase: 2 Type: ACCESS-LIST Subtype: Result: ALLOW Config: Implicit Rule Additional Information: MAC Access list Phase: 3 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 192.168.2.72 using egress ifc OUTSIDE … Phase: 14 Type: FLOW-CREATION Subtype: Result: ALLOW Config: Additional Information: New flow created with id 4816, packet dispatched to next module … Phase: 17 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 192.168.2.72 using egress ifc OUTSIDE Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: OUTSIDE output-status: up output-line-status: up Action: drop Drop-reason: (no-v4-adjacency) No valid V4 adjacency, Drop-location: frame 0x00005647a4e86109 flow (NA)/NA
في إصدارات ASA/FirePOWER الأخيرة، تم تحسين الرسالة السابقة ل:
Drop-reason: (no-v4-adjacency) No valid V4 adjacency. Check ARP table (show arp) has entry for nexthop., Drop-location: f
إن يرى أنت فقط TCP syn ربط على المدخل قارن، غير أن ما من TCP syn ربط يرسل من ال يتوقع مخرج قارن بعض يمكن سبب:
السبب المحتمل |
الإجراءات الموصى بها |
يتم إسقاط الحزمة بواسطة نهج الوصول إلى جدار الحماية. |
|
عامل تصفية الالتقاط غير صحيح. |
|
أرسلت الربط إلى قارن مخرج مختلف. |
إذا تم إرسال الحزمة إلى واجهة خاطئة لأنها تطابق اتصال حالي، فاستخدم الأمر clear conn address وحدد الحزمة 5- من الاتصال الذي تريد مسحه. |
لا يوجد طريق إلى الوجهة. |
|
لا يوجد إدخال ARP على واجهة المخرج. |
|
قارن المخرج معطل. |
تحقق من إخراج الأمر show interface ip brief على جدار الحماية وتحقق من حالة الواجهة. |
تعرض هذه الصورة المخطط:
وصف المشكلة: HTTP لا يعمل
التدفق المتأثر:
SRC IP: 192.168.0.100
DST IP: 10.10.1.100
البروتوكول: TCP 80
قم بتمكين عمليات الالتقاط على محرك FTD LINA.
firepower# capture CAPI int INSIDE match ip host 192.168.0.100 host 10.10.1.100 firepower# capture CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100
التقاط - سيناريو لا يعمل:
هذه هي الطريقة التي تبدو بها عمليات الالتقاط من واجهة سطر الأوامر الخاصة بالجهاز:
firepower# show capture capture CAPI type raw-data trace interface INSIDE [Capturing - 834 bytes] match ip host 192.168.0.100 host 10.10.1.100 capture CAPO type raw-data interface OUTSIDE [Capturing - 878 bytes] match ip host 192.168.0.100 host 10.10.1.100
محتويات CAPI:
firepower# show capture CAPI 1: 05:20:36.654217 192.168.0.100.22195 > 10.10.1.100.80: S 1397289928:1397289928(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 2: 05:20:36.904311 192.168.0.100.22196 > 10.10.1.100.80: S 2171673258:2171673258(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 3: 05:20:36.905043 10.10.1.100.80 > 192.168.0.100.22196: R 1850052503:1850052503(0) ack 2171673259 win 0 4: 05:20:37.414132 192.168.0.100.22196 > 10.10.1.100.80: S 2171673258:2171673258(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 5: 05:20:37.414803 10.10.1.100.80 > 192.168.0.100.22196: R 31997177:31997177(0) ack 2171673259 win 0 6: 05:20:37.914183 192.168.0.100.22196 > 10.10.1.100.80: S 2171673258:2171673258(0) win 8192 <mss 1460,nop,nop,sackOK> ...
محتويات CAPO:
firepower# show capture CAPO 1: 05:20:36.654507 802.1Q vlan#202 P0 192.168.0.100.22195 > 10.10.1.100.80: S 2866789268:2866789268(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK> 2: 05:20:36.904478 802.1Q vlan#202 P0 192.168.0.100.22196 > 10.10.1.100.80: S 4785344:4785344(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK> 3: 05:20:36.904997 802.1Q vlan#202 P0 10.10.1.100.80 > 192.168.0.100.22196: R 0:0(0) ack 4785345 win 0 4: 05:20:37.414269 802.1Q vlan#202 P0 192.168.0.100.22196 > 10.10.1.100.80: S 4235354730:4235354730(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK> 5: 05:20:37.414758 802.1Q vlan#202 P0 10.10.1.100.80 > 192.168.0.100.22196: R 0:0(0) ack 4235354731 win 0 6: 05:20:37.914305 802.1Q vlan#202 P0 192.168.0.100.22196 > 10.10.1.100.80: S 4118617832:4118617832(0) win 8192 <mss 1380,nop,nop,sackOK>
تظهر هذه الصورة التقاط CAPI في Wireshark.
النقاط الرئيسية:
تظهر هذه الصورة التقاط CAPO في Wireshark:
النقاط الرئيسية:
واستنادا إلى الفصلين، يمكن إستنتاج ما يلي:
والغرض من الإجراءات الواردة في هذا الفرع هو زيادة تضييق نطاق هذه المسألة.
الإجراء 1. تحقق من مصدر عنوان MAC الذي يرسل TCP RST.
دققت أن الغاية {upper}mac يرى في ال TCP syn ربط ال نفسه بما أن المصدر {upper}mac قد رأى في ال TCP rst ربط.
يهدف هذا الفحص إلى تأكيد أمرين:
الإجراء 2. قارن حزم الدخول والخروج.
قارن الربط 2 على Wireshark بصريا للتحقق من أن جدار الحماية لا يعدل/يفسد الربط. يتم إبراز بعض الفروق المتوقعة.
النقاط الرئيسية:
الإجراء 3. قم بالتقاط عند الوجهة.
إن أمكن، إلتقط صورة في الوجهة نفسها. إذا لم يكن هذا ممكنا فخذ التقاط أقرب ما يمكن إلى الوجهة. الهدف هنا هو التحقق من من الذي يرسل TCP RST (هل خادم الوجهة أو من أحد الأجهزة الأخرى في المسار؟).
تعرض هذه الصورة المخطط:
وصف المشكلة: HTTP لا يعمل
التدفق المتأثر:
SRC IP: 192.168.0.100
DST IP: 10.10.1.100
البروتوكول: TCP 80
قم بتمكين عمليات الالتقاط على محرك FTD LINA.
firepower# capture CAPI int INSIDE match ip host 192.168.0.100 host 10.10.1.100 firepower# capture CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100
التقاط - سيناريو لا يعمل:
هناك طريقتان مختلفتان يمكن لهذه المشكلة أن تظهر في عمليات التقاط.
يحتوي كل من جدار الحماية على CAPI و CAPO على الحزم نفسها، كما هو موضح في الصورة.
النقاط الرئيسية:
والغرض من الإجراءات الواردة في هذا الفرع هو زيادة تضييق نطاق هذه المسألة.
الإجراء 1. التقط صورا أقرب ما يمكن إلى نقطتي النهاية.
تشير لقطات جدار الحماية إلى أن الخادم لم يعالج ACK الخاص بالعميل. وهذا مبني على هذه الحقائق:
يظهر الالتقاط على الخادم المشكلة. لم يصل أبدا ACK العميل من تأكيد اتصال TCP الثلاثي:
يحتوي كل من جدار الحماية على CAPI و CAPO على الحزم نفسها، كما هو موضح في الصورة.
النقاط الرئيسية:
بناء على هذا الالتقاط، يمكن الاستنتاج بأنه على الرغم من وجود مصافحة TCP ثلاثية الإتجاه عبر جدار الحماية، يبدو أنه لا يتم إتمامها في الواقع على نقطة نهاية واحدة (تشير عمليات إعادة الإرسال إلى ذلك).
نفس الشيء في الحالة 3.1
يحتوي كل من جدار الحماية على CAPI و CAPO على الحزم نفسها، كما هو موضح في الصورة.
النقاط الرئيسية:
واستنادا إلى هذه الصور، يمكن إستنتاج ما يلي:
نفس الشيء في الحالة 3.1
يحتوي كل من جدار الحماية على CAPI و CAPO على هذه الحزم، كما هو موضح في الصورة.
النقاط الرئيسية:
الإجراء: التقاط الصور بالقرب من الخادم قدر الإمكان.
يمكن أن يشير TCP RST الفوري من الخادم إلى وجود خادم أو جهاز في المسار الذي يرسل TCP RST. قم بالتقاط على الخادم نفسه وحدد مصدر TCP RST.
تعرض هذه الصورة المخطط:
وصف المشكلة: لا يعمل HTTP.
التدفق المتأثر:
SRC IP: 192.168.0.100
DST IP: 10.10.1.100
البروتوكول: TCP 80
قم بتمكين عمليات الالتقاط على محرك FTD LINA.
firepower# capture CAPI int INSIDE match ip host 192.168.0.100 host 10.10.1.100 firepower# capture CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100
التقاط - سيناريو لا يعمل:
هذه هي محتويات CAPI.
firepower# show capture CAPI 14 packets captured 1: 12:32:22.860627 192.168.0.100.47078 > 10.10.1.100.80: S 4098574664:4098574664(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 2: 12:32:23.111307 192.168.0.100.47079 > 10.10.1.100.80: S 2486945841:2486945841(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 3: 12:32:23.112390 192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0 4: 12:32:25.858109 192.168.0.100.47078 > 10.10.1.100.80: S 4098574664:4098574664(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 5: 12:32:25.868698 192.168.0.100.47078 > 10.10.1.100.80: R 1386249853:1386249853(0) win 0 6: 12:32:26.108118 192.168.0.100.47079 > 10.10.1.100.80: S 2486945841:2486945841(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 7: 12:32:26.109079 192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0 8: 12:32:26.118295 192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0 9: 12:32:31.859925 192.168.0.100.47078 > 10.10.1.100.80: S 4098574664:4098574664(0) win 8192 <mss 1460,nop,nop,sackOK> 10: 12:32:31.860902 192.168.0.100.47078 > 10.10.1.100.80: R 1386249853:1386249853(0) win 0 11: 12:32:31.875229 192.168.0.100.47078 > 10.10.1.100.80: R 1386249853:1386249853(0) win 0 12: 12:32:32.140632 192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0 13: 12:32:32.159995 192.168.0.100.47079 > 10.10.1.100.80: S 2486945841:2486945841(0) win 8192 <mss 1460,nop,nop,sackOK> 14: 12:32:32.160956 192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0 14 packets shown
هذه هي محتويات CAPO:
firepower# show capture CAPO 11 packets captured 1: 12:32:22.860780 802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: S 1386249852:1386249852(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK> 2: 12:32:23.111429 802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: S 3000518857:3000518857(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK> 3: 12:32:23.112405 802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: R 3514091874:3514091874(0) win 0 4: 12:32:25.858125 802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: S 1386249852:1386249852(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK> 5: 12:32:25.868729 802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: R 2968892337:2968892337(0) win 0 6: 12:32:26.108240 802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: S 3822259745:3822259745(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK> 7: 12:32:26.109094 802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: R 40865466:40865466(0) win 0 8: 12:32:31.860062 802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: S 4294058752:4294058752(0) win 8192 <mss 1380,nop,nop,sackOK> 9: 12:32:31.860917 802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: R 1581733941:1581733941(0) win 0 10: 12:32:32.160102 802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: S 4284301197:4284301197(0) win 8192 <mss 1380,nop,nop,sackOK> 11: 12:32:32.160971 802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: R 502906918:502906918(0) win 0 11 packets shown
تظهر سجلات جدار الحماية:
firepower# show log | i 47741 Oct 13 2019 13:57:36: %FTD-6-302013: Built inbound TCP connection 4869 for INSIDE:192.168.0.100/47741 (192.168.0.100/47741) to OUTSIDE:10.10.1.100/80 (10.10.1.100/80) Oct 13 2019 13:57:36: %FTD-6-302014: Teardown TCP connection 4869 for INSIDE:192.168.0.100/47741 to OUTSIDE:10.10.1.100/80 duration 0:00:00 bytes 0 TCP Reset-O from INSIDE Oct 13 2019 13:57:39: %FTD-6-302013: Built inbound TCP connection 4870 for INSIDE:192.168.0.100/47741 (192.168.0.100/47741) to OUTSIDE:10.10.1.100/80 (10.10.1.100/80) Oct 13 2019 13:57:39: %FTD-6-302014: Teardown TCP connection 4870 for INSIDE:192.168.0.100/47741 to OUTSIDE:10.10.1.100/80 duration 0:00:00 bytes 0 TCP Reset-O from INSIDE Oct 13 2019 13:57:45: %FTD-6-302013: Built inbound TCP connection 4871 for INSIDE:192.168.0.100/47741 (192.168.0.100/47741) to OUTSIDE:10.10.1.100/80 (10.10.1.100/80) Oct 13 2019 13:57:45: %FTD-6-302014: Teardown TCP connection 4871 for INSIDE:192.168.0.100/47741 to OUTSIDE:10.10.1.100/80 duration 0:00:00 bytes 0 TCP Reset-O from INSIDE
تشير هذه السجلات إلى وجود TCP RST يصل إلى واجهة جدار الحماية الداخلية
أسر CAPI في Wireshark:
اتبع تدفق TCP الأول، كما هو موضح في الصورة.
تحت Wireshark، انتقل إلى تحرير > تفضيلات > بروتوكولات > TCP وألغي تحديد خيار أرقام التسلسل النسبية كما هو موضح في الصورة.
تظهر هذه الصورة محتويات التدفق الأول في التقاط CAPI:
النقاط الرئيسية:
يحتوي نفس التدفق في التقاط CAPO على:
النقاط الرئيسية:
واستنادا إلى اللمحتين، يمكن إستنتاج ما يلي:
والغرض من الإجراءات الواردة في هذا الفرع هو زيادة تضييق نطاق هذه المسألة.
الإجراء 1. تمتع بالتقاط ما للعميل.
استنادا إلى عمليات الالتقاط التي تم جمعها على جدار الحماية، هناك مؤشر قوي على وجود تدفق غير متماثل. يستند هذا إلى حقيقة أن العميل يرسل TCP RST بقيمة 1386249853 (IS العشوائي):
النقاط الرئيسية:
ويمكن تمثيل ذلك على النحو التالي:
الإجراء 2. تحقق من التوجيه بين العميل وجدار الحماية.
تأكيد ما يلي:
هناك سيناريوهات حيث يأتي RST من جهاز يقع بين جدار الحماية والعميل أثناء وجود توجيه غير متماثل في الشبكة الداخلية. تظهر حالة نموذجية في الصورة:
في هذه الحالة، فإن الالتقاط يحتوي على هذا المحتوى. لاحظ الفرق بين عنوان MAC المصدر لحزمة TCP syn مقابل عنوان MAC المصدر الخاص ب TCP RST وعنوان MAC الوجهة لحزمة TCP syn/ACK:
firepower# show capture CAPI detail 1: 13:57:36.730217 4c4e.35fc.fcd8 00be.75f6.1dae 0x0800 Length: 66 192.168.0.100.47740 > 10.10.1.100.80: S [tcp sum ok] 3045001876:3045001876(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> (DF) (ttl 127, id 25661) 2: 13:57:36.981104 4c4e.35fc.fcd8 00be.75f6.1dae 0x0800 Length: 66 192.168.0.100.47741 > 10.10.1.100.80: S [tcp sum ok] 3809380540:3809380540(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> (DF) (ttl 127, id 25662) 3: 13:57:36.981776 00be.75f6.1dae a023.9f92.2a4d 0x0800 Length: 66 10.10.1.100.80 > 192.168.0.100.47741: S [tcp sum ok] 1304153587:1304153587(0) ack 3809380541 win 8192 <mss 1380,nop,wscale 8,nop,nop,sackOK> (DF) (ttl 127, id 23339) 4: 13:57:36.982126 a023.9f92.2a4d 00be.75f6.1dae 0x0800 Length: 54 192.168.0.100.47741 > 10.10.1.100.80: R [tcp sum ok] 3809380541:3809380541(0) ack 1304153588 win 8192 (ttl 255, id 48501) ...
وصف المشكلة:
نقل SFTP بين الأجهزة المضيفة 10.11.4.171 و 10.77.19.11 بطيء. على الرغم من أن الحد الأدنى لعرض النطاق الترددي (BW) بين المضيفين هو 100 ميجابت في الثانية، إلا أن سرعة النقل لا تتجاوز 5 ميجابت في الثانية.
وفي الوقت نفسه، فإن سرعة النقل بين الأجهزة المضيفة 10.11.2.124 و 172.25.18.134 أعلى من ذلك بكثير.
النظرية الأساسية:
يتم تحديد سرعة النقل القصوى لتدفق TCP واحد بواسطة منتج تأخير النطاق الترددي (BDP). يتم عرض الصيغة المستخدمة في الصورة:
لمزيد من التفاصيل حول BDP تحقق من الموارد هنا:
تعرض هذه الصورة المخطط:
التدفق المتأثر:
SRC IP: 10.11.4.171
بروتوكول DST IP: 10.77.19.11
البروتوكول: SFTP (FTP عبر SSH)
تمكين الالتقاط على محرك FTD LINA:
firepower# capture CAPI int INSIDE buffer 33554432 match ip host 10.11.4.171 host 10.77.19.11 firepower# capture CAPO int OUTSIDE buffer 33554432 match ip host 10.11.4.171 host 10.77.19.11
تحذير: تؤثر التقاط LINA على التقاط FP1xxx و FP21xx على معدل نقل حركة المرور التي تمر عبر FTD. لا تقم بتمكين التقاط LINA على الأنظمة الأساسية FP1xxx و FP21xxx عند أستكشاف أخطاء الأداء وإصلاحها (النقل البطيء عبر FTD). بدلا من ذلك استعملت فسحة بين دعامتين أو HW Tap أداة بالإضافة إلى أن على قبض على المصدر وغاية مضيف. وثقت الإصدار في cisco بق id CSCvo30697.
firepower# capture CAPI type raw-data trace interface inside match icmp any any WARNING: Running packet capture can have an adverse impact on performance.
والغرض من الإجراءات الواردة في هذا الفرع هو زيادة تضييق نطاق هذه المسألة.
حساب وقت الذهاب والعودة (RTT)
أولا، حدد تدفق النقل واتبعه:
قم بتغيير طريقة عرض Wireshark لإظهار الثواني منذ الحزمة المعروضة السابقة. وهذا من شأنه تسهيل حساب RTT:
يمكن حساب RTT من خلال إضافة قيم الوقت بين عمليتي تبادل حزم (أحدهما نحو المصدر والآخر نحو الوجهة). في هذه الحالة، تعرض الحزمة #2 RTT بين جدار الحماية والجهاز الذي أرسل حزمة SYN/ACK (الخادم). تعرض الحزمة #3 RTT بين جدار الحماية والجهاز الذي أرسل حزمة ACK (العميل). توفر إضافة الرقمين تقديرا جيدا حول RTT الشامل:
RTT ≈ 80 ثانية
حساب حجم نافذة TCP
قم بتوسيع حزمة TCP، وتوسيع رأس TCP، وتحديد حجم النافذة المحسوب وحدد تطبيق كعمود:
تحقق من عمود قيمة حجم النافذة المحسوب لمعرفة ما هي قيمة الحد الأقصى لحجم النافذة أثناء جلسة عمل TCP. يمكنك أيضا تحديد اسم العمود وترتيب القيم.
إذا قمت باختبار تنزيل ملف (خادم > عميل)، فيجب عليك التحقق من القيم المعلن عنها بواسطة الخادم. تحدد القيمة القصوى لحجم النافذة المعلن عنها من قبل الخادم أقصى سرعة نقل يتم تحقيقها.
في هذه الحالة، يبلغ حجم نافذة TCP ≈ 50000 بايت
استنادا إلى هذه القيم ومع إستخدام صيغة منتج تأخير النطاق الترددي ستحصل على أقصى عرض نطاق ترددي نظري يمكن تحقيقه في ظل هذه الظروف: 50000*8/0.08 = 5 ميجابت في الثانية كحد أقصى لعرض النطاق الترددي النظري.
وهذا يطابق ما يختبره العميل في هذه الحالة.
تحقق عن كثب من تأكيد اتصال TCP الثلاثي. يقوم كلا الجانبين، والأهم من ذلك الخادم، بالإعلان عن قيمة قياس نافذة 0 والتي تعني 2^0 = 1 (لا يوجد قياس في النوافذ). ويؤثر هذا سلبا على معدل التحويل:
عند هذه النقطة، هناك حاجة لالتقاط صورة على الخادم، وتأكد من أنه الشخص الذي أعلن عن مقياس النافذة = 0 وأعد تكوينه (راجع وثائق الخادم لمعرفة كيفية القيام بذلك).
الآن دعنا نفحص السيناريو الجيد (النقل السريع عبر الشبكة نفسها):
المخطط:
تدفق الاهتمام:
SRC IP: 10.11.2.124
DST IP: 172.25.18.134
البروتوكول: SFTP (FTP عبر SSH)
تمكين التقاط على محرك FTD LINA
firepower# capture CAPI int INSIDE buffer 33554432 match ip host 10.11.2.124 host 172.25.18.134 firepower# capture CAPO int OUTSIDE buffer 33554432 match ip host 10.11.2.124 host 172.25.18.134
حساب وقت الذهاب والعودة (RTT): في هذه الحالة، يكون RTT ≈ 300 ثانية.
حساب حجم نافذة TCP: أعلن الخادم عن عامل مقياس نافذة TCP رقم 7.
حجم نافذة TCP للخادم ≈ 1600000 بايت:
استنادا إلى هذه القيم، توفر صيغة منتجات تأخير النطاق الترددي ما يلي:
160000*8/0.3 = 43 ميجابت في الثانية الحد الأقصى لسرعة النقل النظرية
وصف المشكلة: يكون نقل ملف FTP (التنزيل) عبر جدار الحماية بطيئا.
تعرض هذه الصورة المخطط:
التدفق المتأثر:
SRC IP: 192.168.2.220
DST IP: 192.168.1.220
البروتوكول: FTP
قم بتمكين عمليات الالتقاط على محرك FTD LINA.
firepower# capture CAPI type raw-data buffer 33554432 interface INSIDE match tcp host 192.168.2.220 host 192.168.1.220 firepower# cap CAPO type raw-data buffer 33554432 interface OUTSIDE match tcp host 192.168.2.220 host 192.168.1.220
حدد حزمة FTP-Data واتبع قناة بيانات FTP على التقاط FTD Inside (CAPI):
محتوى تدفق بيانات FTP:
محتوى التقاط CAPO:
النقاط الرئيسية:
تلميح: احفظ الصور أثناء تنقلك إلى ملف > تصدير الحزم المحددة. ثم احفظ فقط نطاق الحزمة المعروضة
والغرض من الإجراءات الواردة في هذا الفرع هو زيادة تضييق نطاق هذه المسألة.
الإجراء 1. تحديد موقع فقدان الحزمة.
في حالات مثل هذه، يجب عليك التقاط عمليات التقاط متزامنة واستخدام منهجية فرق الاتصال والتغلب لتحديد مقطع (مقاطع) الشبكة التي تتسبب في فقدان الحزمة. ومن وجهة نظر جدار الحماية هناك ثلاثة سيناريوهات رئيسية:
فقد الحزمة الناجم عن جدار الحماية: لتحديد ما إذا كان فقد الحزمة بسبب جدار الحماية أم لا، هناك حاجة لمقارنة التقاط المدخل بالتقاط المخرج. هناك طرق كثيرة لمقارنة طريقتين مختلفتين. يوضح هذا القسم طريقة واحدة للقيام بهذه المهمة.
إجراء مقارنة صورتين لتحديد فقدان الحزمة
الخطوة 1. ضمنت أن ال 2 إحتواء ربط من ال نفسه وقت نافذة. هذا يعني أنه يجب ألا تكون هناك حزم في التقاط واحد تم التقاطه قبل أو بعد الالتقاط الآخر. وهناك عدد قليل من الطرق لتحقيق هذه الغاية:
في هذا المثال، يمكنك أن ترى أن الحزم الأولى من كل التقاط لها نفس قيم معرف IP:
في حالة ما إذا كانوا غير متشابهين:
(frame.time >= "16 أكتوبر 2019 16:13:43.244692000") &(frame.time <= "16 أكتوبر 2019 16:20:21.78513000")
3. تصدير الحزم المحددة إلى التقاط جديد، حدد ملف > تصدير الحزم المحددة ثم احفظ الحزم المعروضة. عند هذه النقطة، يجب أن يحتوي كلا الالتقاط على حزم تغطي الإطار الزمني نفسه. يمكنك الآن بدء مقارنة اللقطتين.
الخطوة 2. حدد حقل الحزمة الذي يتم إستخدامه للمقارنة بين الملتقطين 2. مثال الحقول التي يمكن إستخدامها:
قم بإنشاء إصدار نصي من كل التقاط يحتوي على الحقل لكل حزمة قمت بتحديدها في الخطوة 1. للقيام بذلك، أترك فقط عمود الاهتمام، على سبيل المثال، إذا كنت تريد مقارنة الحزم بناء على تعريف IP ثم قم بتعديل الالتقاط كما هو موضح في الصورة.
النتيجة:
الخطوة 3. قم بإنشاء إصدار نص من الالتقاط (ملف > تصدير تقسيمات الحزم > كنص عادي...)، كما هو موضح في الصورة:
قم بإلغاء تحديد خيارات تضمين رؤوس الأعمدة وتفاصيل الحزمة لتصدير قيم الحقل المعروض فقط، كما هو موضح في الصورة:
الخطوة 4. ترتيب الحزم في الملفات. يمكنك إستخدام أمر فرز لينوكس للقيام بذلك:
# sort CAPI_IDs > file1.sorted # sort CAPO_IDs > file2.sorted
الخطوة 5. أستخدم أداة مقارنة نصوص (على سبيل المثال، WinMerge) أو أمر Linux diff للعثور على الفروق بين الصور 2.
في هذه الحالة، يكون التقاط CAPI و CAPO لحركة مرور بيانات FTP متطابقين. هذا يثبت أن فقدان الحزمة لم يكن بسبب جدار الحماية.
التعرف على فقدان حزم تدفق/تدفق البيانات.
النقاط الرئيسية:
1. هذه الحزمة هي إعادة إرسال TCP. وعلى وجه الخصوص، فإنها حزمة TCP syn يتم إرسالها من العميل إلى الخادم لبيانات FTP في الوضع الخامل. بما أن العميل يعيد الربط وأنت يستطيع رأيت ال syn أولي (ربط #1) الربط فقدت نحو الخادم إلى جدار الحماية.
في هذه الحالة، هناك احتمال أن تكون حزمة SYN قد وصلت إلى الخادم، ولكن حزمة SYN/ACK قد فقدت في طريق الرجوع:
2. هناك حزمة من الخادم وتعرف Wireshark على أن المقطع السابق لم يتم عرضه/التقاطه. نظرا لأنه تم إرسال الحزمة غير الملتقطة من الخادم إلى العميل ولم يتم رؤيتها في التقاط جدار الحماية، فهذا يعني أن الحزمة قد فقدت بين الخادم وجدار الحماية.
وهذا يشير إلى وجود فقدان حزم بين خادم FTP وجدار الحماية.
الإجراء 2. التقاط صور إضافية.
قم بأخذ لقطات إضافية مع لقطات عند نقاط النهاية. حاول تطبيق طريقة التقسيم والتغلب لعزل المزيد من المقطع المثير للمشاكل الذي يسبب فقدان الحزمة.
النقاط الرئيسية:
ما الذي تعنيه الوجبات المكررة؟
الإجراء 3. حساب وقت معالجة جدار الحماية لحزم النقل.
تطبيق نفس الالتقاط على واجهتين مختلفتين:
firepower# capture CAPI buffer 33554432 interface INSIDE match tcp host 192.168.2.220 host 192.168.1.220 firepower# capture CAPI interface OUTSIDE
وصف المشكلة:
يحاول العميل اللاسلكي (192.168.21.193) الاتصال بخادم وجهة (192.168.14.250 - HTTP) وهناك سيناريوهان مختلفان:
تعرض هذه الصورة المخطط:
التدفق المتأثر:
SRC IP: 192.168.21.193
DST IP: 192.168.14.250
البروتوكول: TCP 80
تمكين الالتقاط على محرك FTD LINA:
firepower# capture CAPI int INSIDE match ip host 192.168.21.193 host 192.168.14.250 firepower# capture CAPO int OUTSIDE match ip host 192.168.21.193 host 192.168.14.250
التقاط - السيناريو الوظيفي:
كخط أساس، من المفيد جدا دائما الحصول على لقطات من سيناريو معروف جيدا.
تظهر هذه الصورة التقاط واجهة NGFW Inside
تعرض هذه الصورة الالتقاط الذي تم على الواجهة الخارجية ل NGFW.
النقاط الرئيسية:
التقاط - السيناريو المعروف بالخطأ:
محتويات التقاط المدخل (CAPI).
النقاط الرئيسية:
تظهر هذه الصورة محتويات التقاط المخرج (CAPO).
النقاط الرئيسية:
التقطتان متطابقتان تقريبا (تأملوا في عملية IS العشوائية):
تحقق من الحزمة ذات التكوين غير الصحيح:
النقاط الرئيسية:
والغرض من الإجراءات الواردة في هذا الفرع هو زيادة تضييق نطاق هذه المسألة.
الإجراء 1. التقاط صور إضافية. تضمنت على قبض في نقاط النهاية وإن أمكن، حاولت أن يطبق الإنقسامات وطريقطقة أن يعزل المصدر من الربط فساد، مثلا:
في هذه الحالة، ال 2 بايت إضافي كان أضفت بالمفتاح 'A' قارن برنامج تشغيل والحل كان أن استبدلت المفتاح أن يسبب الفساد.
وصف المشكلة: لا يرى Syslog (UDP 514) رسالة على الغاية syslog نادل.
تعرض هذه الصورة المخطط:
التدفق المتأثر:
SRC IP: 192.168.1.81
DST IP: 10.10.1.73
البروتوكول: UDP 514
تمكين الالتقاط على محرك FTD LINA:
firepower# capture CAPI int INSIDE trace match udp host 192.168.1.81 host 10.10.1.73 eq 514 firepower# capture CAPO int OUTSIDE match udp host 192.168.1.81 host 10.10.1.73 eq 514
لا تظهر صور FTD أي حزم:
firepower# show capture capture CAPI type raw-data trace interface INSIDE [Capturing - 0 bytes] match udp host 192.168.1.81 host 10.10.1.73 eq syslog capture CAPO type raw-data interface OUTSIDE [Capturing - 0 bytes] match udp host 192.168.1.81 host 10.10.1.73 eq syslog
والغرض من الإجراءات الواردة في هذا الفرع هو زيادة تضييق نطاق هذه المسألة.
الإجراء 1. تحقق من جدول اتصال FTD.
للتحقق من اتصال محدد، يمكنك إستخدام هذه الصياغة:
firepower# show conn address 192.168.1.81 port 514 10 in use, 3627189 most used Inspect Snort: preserve-connection: 6 enabled, 0 in effect, 74 most enabled, 0 most in effect UDP INSIDE 10.10.1.73:514 INSIDE 192.168.1.81:514, idle 0:00:00, bytes 480379697, flags -oN1
النقاط الرئيسية:
الإجراء 2. تمتع بالتقاط الصور على مستوى الهيكل.
قم بالاتصال بمدير هيكل FirePOWER وتمكين الالتقاط على واجهة الدخول (E1/2 في هذه الحالة) وواجهات اللوحة الخلفية (E1/9 و E1/10)، كما هو موضح في الصورة:
بعد بضع ثوان:
طرف: في Wireshark استثنيت ال VN-tagged ربط أن يزيل الربط مزدوج على القارن طبيعي
قبل:
بعد:
النقاط الرئيسية:
الإجراء 3. إستخدام تطبيق Packet-tracer.
بما أن الحزم لا تجتاز جدار الحماية LINA محرك أنت يستطيع لا يتم تتبع نشط (على قبض w/trace)، غير أن أنت يستطيع تتبعت ربط محاكي مع ربط-tracer:
firepower# packet-tracer input INSIDE udp 10.10.1.73 514 192.168.1.81 514 Phase: 1 Type: CAPTURE Subtype: Result: ALLOW Config: Additional Information: MAC Access list Phase: 2 Type: ACCESS-LIST Subtype: Result: ALLOW Config: Implicit Rule Additional Information: MAC Access list Phase: 3 Type: FLOW-LOOKUP Subtype: Result: ALLOW Config: Additional Information: Found flow with id 25350892, using existing flow Phase: 4 Type: SNORT Subtype: Result: ALLOW Config: Additional Information: Snort Verdict: (fast-forward) fast forward this flow Phase: 5 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 192.168.1.81 using egress ifc INSIDE Phase: 6 Type: ADJACENCY-LOOKUP Subtype: next-hop and adjacency Result: ALLOW Config: Additional Information: adjacency Active next-hop mac address a023.9f92.2a4d hits 1 reference 1 Phase: 7 Type: CAPTURE Subtype: Result: ALLOW Config: Additional Information: MAC Access list Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: INSIDE output-status: up output-line-status: up Action: allow
الإجراء 4. تأكيد توجيه "برنامج الإرسال فائق السرعة (FTD)".
تحقق من جدول توجيه جدار الحماية لمعرفة ما إذا كانت هناك أي مشاكل في التوجيه:
firepower# show route 10.10.1.73 Routing entry for 10.10.1.0 255.255.255.0 Known via "eigrp 1", distance 90, metric 3072, type internal Redistributing via eigrp 1 Last update from 192.168.2.72 on OUTSIDE, 0:03:37 ago Routing Descriptor Blocks: * 192.168.2.72, from 192.168.2.72, 0:02:37 ago, via OUTSIDE Route metric is 3072, traffic share count is 1 Total delay is 20 microseconds, minimum bandwidth is 1000000 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 29/255, Hops 1
النقاط الرئيسية:
الإجراء 5. تأكيد وقت تشغيل الاتصال.
تحقق من وقت تشغيل الاتصال لمعرفة وقت تأسيس هذا الاتصال:
firepower# show conn address 192.168.1.81 port 514 detail 21 in use, 3627189 most used Inspect Snort: preserve-connection: 19 enabled, 0 in effect, 74 most enabled, 0 most in effect Flags: A - awaiting responder ACK to SYN, a - awaiting initiator ACK to SYN, b - TCP state-bypass or nailed, C - CTIQBE media, c - cluster centralized, D - DNS, d - dump, E - outside back connection, e - semi-distributed, F - initiator FIN, f - responder FIN, G - group, g - MGCP, H - H.323, h - H.225.0, I - initiator data, i - incomplete, J - GTP, j - GTP data, K - GTP t3-response k - Skinny media, L - decap tunnel, M - SMTP data, m - SIP media N - inspected by Snort (1 - preserve-connection enabled, 2 - preserve-connection in effect) n - GUP, O - responder data, o - offloaded, P - inside back connection, p - passenger flow q - SQL*Net data, R - initiator acknowledged FIN, R - UDP SUNRPC, r - responder acknowledged FIN, T - SIP, t - SIP transient, U - up, V - VPN orphan, v - M3UA W - WAAS, w - secondary domain backup, X - inspected by service module, x - per session, Y - director stub flow, y - backup stub flow, Z - Scansafe redirection, z - forwarding stub flow UDP INSIDE: 10.10.1.73/514 INSIDE: 192.168.1.81/514, flags -oN1, idle 0s, uptime 3m49s, timeout 2m0s, bytes 4801148711
النقطة الرئيسية:
الإجراء 6. قم بمسح الاتصال الثابت.
في هذه الحالة، تتطابق الحزم مع اتصال مؤسس ويتم توجيهها إلى واجهة مخرج خاطئة؛ وهذا يتسبب في حدوث تكرار حلقي. يرجع السبب في ذلك إلى ترتيب عمليات جدار الحماية:
بما أن الاتصال لا ينتهي أبدا (يرسل عميل syslog الحزم باستمرار بينما تكون مهلة خمول UDP هي 2 دقيقة) هناك حاجة إلى مسح الاتصال يدويا:
firepower# clear conn address 10.10.1.73 address 192.168.1.81 protocol udp port 514 1 connection(s) deleted.
تحقق من إنشاء اتصال جديد:
firepower# show conn address 192.168.1.81 port 514 detail | b 10.10.1.73.*192.168.1.81 UDP OUTSIDE: 10.10.1.73/514 INSIDE: 192.168.1.81/514, flags -oN1, idle 1m15s, uptime 1m15s, timeout 2m0s, bytes 408
الإجراء 7. تكوين مهلة التداخل العائم.
هذا هو الحل المناسب لمعالجة المشكلة وتجنب التوجيه دون الأمثل، وخاصة لتدفقات UDP. انتقل إلى الأجهزة > إعدادات النظام الأساسي > مهلات وضبط القيمة:
أنت يستطيع وجدت المزيد من التفاصيل حول التعويم conn مهلة في الأمر مرجع:
الحالة 9. مشكلة اتصال HTTPS (السيناريو 1)
وصف المشكلة: لا يمكن إنشاء اتصال HTTPS بين العميل 192.168.201.105 والخادم 192.168.202.101
تعرض هذه الصورة المخطط:
التدفق المتأثر:
SRC IP: 192.168.201.111
DST IP: 192.168.202.111
البروتوكول: بروتوكول TCP 443 (HTTPS)
تمكين الالتقاط على محرك FTD LINA:
ال ip يستعمل في الالتقاط الخارجي مختلف واجب إلى العنوان ترجمة تشكيل.
firepower# capture CAPI int INSIDE match ip host 192.168.201.111 host 192.168.202.111 firepower# capture CAPO int OUTSIDE match ip host 192.168.202.11 host 192.168.202.111
تظهر هذه الصورة الالتقاط الذي تم على واجهة NGFW Inside:
النقاط الرئيسية:
تعرض هذه الصورة الالتقاط الذي تم على الواجهة الخارجية ل NGFW.
النقاط الرئيسية:
والغرض من الإجراءات الواردة في هذا الفرع هو زيادة تضييق نطاق هذه المسألة.
الإجراء 1. التقاط صور إضافية.
يظهر التقاط تم الالتقاط على الخادم أن الخادم استلم رمز عميل TLS مع المجموع الاختباري TCP تالف ويقوم بإسقاطه بصمت (لا يوجد TCP RST أو أي حزمة رد أخرى تجاه العميل):
عندما تضع كل شيء معا:
في هذه الحالة، للفهم، هناك حاجة لتمكين التحقق من المجموع الاختباري ل TCP إذا كان خيار ذلك ممكنا على Wireshark. انتقل إلى تحرير > تفضيلات > بروتوكولات > TCP، كما هو موضح في الصورة.
في هذه الحالة، من المفيد أن نضع إلتقاطات جنبا إلى جنب للحصول على الصورة الكاملة:
النقاط الرئيسية:
للرجوع إليه:
معالجة تأكيد الاتصال Firepower TLS/SSL
وصف المشكلة: فشل تسجيل الترخيص الذكي ل FMC.
تعرض هذه الصورة المخطط:
التدفق المتأثر:
SRC IP: 192.168.0.100
DST: tools.cisco.com
البروتوكول: بروتوكول TCP 443 (HTTPS)
تمكين الالتقاط على واجهة إدارة FMC:
حاول التسجيل مرة أخرى. بمجرد ظهور رسالة الخطأ، اضغط على CTRL-C لإيقاف الالتقاط:
root@firepower:/Volume/home/admin# tcpdump -i eth0 port 443 -s 0 -w CAP.pcap HS_PACKET_BUFFER_SIZE is set to 4. tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes ^C264 packets captured <- CTRL-C 264 packets received by filter 0 packets dropped by kernel root@firepower:/Volume/home/admin#
قم بجمع الالتقاط من وحدة التحكم في إدارة الهيكل (System > Health > Monitor، وحدد الجهاز وحدد أستكشاف الأخطاء وإصلاحها المتقدم)، كما هو موضح في الصورة:
تظهر الصورة التقاط FMC على Wireshark:
تلميح: للتحقق من جميع جلسات عمل TCP الجديدة التي تم التقاطها، أستخدم عامل تصفية عرض tcp.flags=0x2 على Wireshark. يقوم هذا بتصفية جميع حزم نظام TCP التي تم التقاطها.
تلميح: تطبيق حقل اسم الخادم من SSL Client Hello كعمود.
تلميح: تطبيق عامل تصفية العرض هذا لرؤية رسائل Client Hello ssl.handshake.type == 1 فقط
ملاحظة: في وقت كتابة هذا التقرير، تستخدم بوابة الترخيص الذكي (tools.cisco.com) عناوين IP هذه: 72.163.4.38 و 173.37.145.8
اتبع أحد تدفقات TCP (اتبع > تدفق TCP)، كما هو موضح في الصورة.
النقاط الرئيسية:
حدد شهادة الخادم ووسع حقل المصدر لرؤية الاسم الشائع. في هذه الحالة يكشف الاسم الشائع عن جهاز يقوم بتعريف الدخيل (MITM).
وهذا موضح في هذه الصورة:
والغرض من الإجراءات الواردة في هذا الفرع هو زيادة تضييق نطاق هذه المسألة.
الإجراء 1. التقاط صور إضافية.
التقاط على جهاز جدار حماية النقل:
تظهر CAPI:
تظهر CAPO:
تثبت هذه الالتقاط أن جدار حماية النقل يعدل شهادة الخادم (MITM)
الإجراء 2. تحقق من سجلات الجهاز.
يمكنك تجميع حزمة FMC TS كما هو موضح في هذا المستند:
في هذه الحالة، يعرض الملف /dir-archives/var-log/process_stdout.log رسائل مثل:
SOUT: 10-23 05:45:14 2019-10-23 05:45:36 sla[10068]: *Wed .967 UTC: CH-LIB-ERROR: ch_pf_curl_send_msg[494],
failed to perform, err code 60, err string "SSL peer certificate or SSH remote key was not OK" ...
SOUT: 10-23 05:45:14 2019-10-23 05:45:36 sla[10068]: *Wed .967 UTC: CH-LIB-TRACE: ch_pf_curl_is_cert_issue[514],
cert issue checking, ret 60, url "https://tools.cisco.com/its/
حل موصى به
قم بتعطيل MITM للتدفق المحدد حتى يمكن ل FMC التسجيل بنجاح إلى سحابة الترخيص الذكي.
الحالة 11. مشكلة اتصال IPv6
وصف المشكلة: لا يمكن للمضيفين الداخليين (الموجودين خلف واجهة جدار الحماية الداخلية) الاتصال بالمضيفين الخارجيين (البيئات المضيفة الموجودة خلف واجهة جدار الحماية الخارجية).
تعرض هذه الصورة المخطط:
التدفق المتأثر:
SRC IP: fc00:1:1:1::100
DST IP: القنوات الليفية 00:1:1:2:2
البروتوكول: أي
قم بتمكين عمليات الالتقاط على محرك FTD LINA.
firepower# capture CAPI int INSIDE match ip any6 any6 firepower# capture CAPO int OUTSIDE match ip any6 any6
التقاط - سيناريو لا يعمل
تم أخذ هذه الالتقاط بالتوازي مع إختبار اتصال ICMP من IP FC00:1:1:1::100 (داخل الموجه) إلى IP FC00:1:1:2::2 (موجه من الخادم).
يحتوي واجهة Capture on Firewall INSIDE على:
النقاط الرئيسية:
يحتوي الالتقاط على جدار الحماية الموجود خارج الواجهة على:
النقاط الرئيسية:
النقطة 4 مثيرة جدا للاهتمام. عادة ما يطلب موجه البث من أجل MAC الخاص بجدار الحماية الخارجي (FC00:1:1:2::2)، ولكن بدلا من ذلك، فإنه يطلب من FC00:1:1:1::100. هذا مؤشر على تكوين غير صحيح.
والغرض من الإجراءات الواردة في هذا الفرع هو زيادة تضييق نطاق هذه المسألة.
الإجراء 1. تحقق من الجدول المجاور ل IPv6.
الجدول المجاور لجدار الحماية IPv6 معبأ بشكل صحيح.
firepower# show ipv6 neighbor | i fc00 fc00:1:1:2::2 58 4c4e.35fc.fcd8 STALE OUTSIDE fc00:1:1:1::100 58 4c4e.35fc.fcd8 STALE INSIDE
الإجراء 2. تحقق من تكوين IPv6.
هذا هو تكوين جدار الحماية.
firewall# show run int e1/2 ! interface Ethernet1/2 nameif INSIDE cts manual propagate sgt preserve-untag policy static sgt disabled trusted security-level 0 ip address 192.168.0.1 255.255.255.0 ipv6 address fc00:1:1:1::1/64 ipv6 enable firewall# show run int e1/3.202 ! interface Ethernet1/3.202 vlan 202 nameif OUTSIDE cts manual propagate sgt preserve-untag policy static sgt disabled trusted security-level 0 ip address 192.168.103.96 255.255.255.0 ipv6 address fc00:1:1:2::1/64 ipv6 enable
يكشف ال up أداة تشكيل ال misconfiguration:
Router# show run interface g0/0.202 ! interface GigabitEthernet0/0.202 encapsulation dot1Q 202 vrf forwarding VRF202 ip address 192.168.2.72 255.255.255.0 ipv6 address FC00:1:1:2::2/48
التقاط - سيناريو وظيفي
أصلح تغيير قناع الشبكة الفرعية (من /48 إلى /64) المشكلة. هذا هو التقاط CAPI في السيناريو الوظيفي.
النقطة الرئيسية:
محتويات CAPO:
النقاط الرئيسية:
وصف المشكلة: تواجه الأجهزة المضيفة الداخلية (192.168.0.x/24) مشاكل اتصال متقطعة مع الأجهزة المضيفة في الشبكة الفرعية نفسها
تعرض هذه الصورة المخطط:
التدفق المتأثر:
SRC IP: 192.168.0.x/24
بروتوكول DST IP: الإصدار 192.168.0.x/24
البروتوكول: أي
يبدو أن ذاكرة تخزين ARP المؤقت لمضيف داخلي قد تم تسميمها:
تمكين التقاط على محرك FTD LINA
على قبض هذا التقاط حزم ARP فقط على الواجهة الداخلية:
firepower# capture CAPI_ARP interface INSIDE ethernet-type arp
التقاط - سيناريو لا يعمل:
يحتوي الالتقاط على واجهة جدار الحماية INSIDE.
النقاط الرئيسية:
والغرض من الإجراءات الواردة في هذا الفرع هو زيادة تضييق نطاق هذه المسألة.
الإجراء 1. فحصت ال nat تشكيل.
فيما يتعلق بتكوين NAT، هناك حالات يمكن فيها للكلمة الأساسية no-proxy-arp منع السلوك السابق:
firepower# show run nat nat (INSIDE,OUTSIDE) source static NET_1.1.1.0 NET_2.2.2.0 destination static NET_192.168.0.0 NET_4.4.4.0 no-proxy-arp
الإجراء 2. قم بتعطيل وظيفة ARP للوكيل على واجهة جدار الحماية.
إذا لم تحل الكلمة الأساسية "no-proxy-arp" المشكلة، فحاول تعطيل ARP للوكيل على الواجهة نفسها. في حالة وجود FTD، يجب عليك في وقت هذه الكتابة إستخدام FlexConfig ونشر الأمر (تحديد اسم الواجهة المناسب).
sysopt noproxyarp INSIDE
توضح هذه الحالة كيفية تحديد بعض معرفات SNMP لعملية التحقق من الذاكرة على أنها السبب الرئيسي لأخطاء وحدة المعالجة المركزية (إصدار الأداء) استنادا إلى تحليل مجموعات حزم SNMP الإصدار 3 (SNMPv3).
وصف المشكلة: تتزايد التجاوزات على واجهات البيانات بشكل مستمر. كما كشفت أبحاث أخرى عن وجود أيضا أخطاء وحدة المعالجة المركزية (الناجمة عن عملية SNMP) التي تعد السبب الرئيسي لتجاوزات الواجهة.
كانت الخطوة التالية في عملية أستكشاف الأخطاء وإصلاحها هي تحديد السبب الجذري لأخطاء وحدة المعالجة المركزية (CPU) التي تتسبب فيها عملية SNMP، وعلى وجه الخصوص، تضييق نطاق المشكلة لتحديد معرفات كائن SNMP (OID) التي يمكن أن ينتج عنها، عندما يتم استقطابها، أخطاء وحدة المعالجة المركزية.
حاليا، لا يوفر محرك FTD LINA أمر "show" لمعرف SNMP OIDs الذي يتم تلقيحه في الوقت الفعلي.
يمكن إسترداد قائمة SNMP OIDs الخاصة بالاقتراع من أداة مراقبة SNMP، ومع ذلك، في هذه الحالة، كانت هناك هذه العوامل الوقائية:
بما أن مسؤول FTD كان لديه بيانات اعتماد لمصادقة SNMP الإصدار 3 وتشفير البيانات، تم اقتراح خطة العمل هذه:
تكوين التقاط حزم SNMP على الواجهة التي يتم إستخدامها في تكوين مضيف خادم snmp:
firepower# show run snmp-server | include host snmp-server host management 192.168.10.10 version 3 netmonv3 firepower# show ip address management System IP Address: Interface Name IP address Subnet mask Method Management0/0 management 192.168.5.254 255.255.255.0 CONFIG Current IP Address: Interface Name IP address Subnet mask Method Management0/0 management 192.168.5.254 255.255.255.0 CONFIG firepower# capture capsnmp interface management buffer 10000000 match udp host 192.168.10.10 host 192.168.5.254 eq snmp firepower# show capture capsnmp capture capsnmp type raw-data buffer 10000000 interface outside [Capturing - 9512 bytes] match udp host 192.168.10.10 host 192.168.5.254 eq snmp
النقاط الرئيسية:
والغرض من الإجراءات الواردة في هذا الفرع هو زيادة تضييق نطاق هذه المسألة.
الإجراء 1. قم بفك تشفير التقاط SNMP.
احفظ الالتقاط وحرر تفضيلات بروتوكول SNMP الخاص ب Wireshark لتحديد بيانات اعتماد الإصدار 3 من SNMP لفك تشفير الحزم.
firepower# copy /pcap capture: tftp: Source capture name [capsnmp]? Address or name of remote host []? 192.168.10.253 Destination filename [capsnmp]? capsnmp.pcap !!!!!! 64 packets copied in 0.40 secs
افتح ملف الالتقاط على Wireshark، حدد حزمة SNMP وتصفح إلى تفضيلات البروتوكول > جدول المستخدمين، كما هو موضح في الصورة:
في جدول مستخدمي SNMP، تم تحديد اسم مستخدم الإصدار 3 من SNMP ونموذج المصادقة وكلمة مرور المصادقة وبروتوكول الخصوصية وكلمة مرور الخصوصية (لا يتم عرض بيانات الاعتماد الفعلية أدناه):
بمجرد تطبيق إعدادات مستخدمي SNMP، قام Wireshark بعرض وحدات بيانات بروتوكول SNMP (PDU) التي تم فك تشفيرها:
النقاط الرئيسية:
الإجراء 2. التعرف على معرفات SNMP المادية.
أظهر متصفح كائن SNMP أن OID 1.3.6.1.4.1.9.221.1 ينتمي إلى قاعدة معلومات الإدارة (MIB) المسماة Cisco-Enhanced-MEMPOOL-MIB، كما هو موضح في الصورة:
لعرض OIDs بتنسيق يمكن قراءته من قبل الإنسان في Wireshark:
2. في Wireshark في Edit (تحرير) > Preferences > Name Resolution (تحليل الاسم) نافذة تمكين دقة OID يتم تحديدها. في SMI (مسارات MIB و PIB) يحدد الإطار المجلد باستخدام قواعد معلومات الإدارة (MIB) التي تم تنزيلها وفي SMI (وحدات MIB و PIB). تتم إضافة Cisco-Enhanced-Mempool-MIB تلقائيا إلى قائمة الوحدات النمطية:
3. بمجرد إعادة تشغيل Wireshark، يتم تنشيط دقة OID:
استنادا إلى الإخراج الذي تم فك تشفيره لملف الالتقاط، كانت أداة مراقبة SNMP تقوم بشكل دوري (فاصل 10 ثوان) بفحص بيانات إستخدام تجمعات الذاكرة على FTD. كما هو موضح في مقالة TechNote فإن اقتراع ASA SNMP للإحصائيات المتعلقة بالذاكرة، ومسح إستخدام التجمع المشترك العالمي (GSP) باستخدام SNMP ينتج عنه إستخدام وحدة المعالجة المركزية (CPU) بشكل كبير. في هذه الحالة من Capture (التقاط)، كان من الواضح أنه قد تم فحص إستخدام "التجمع المشترك العالمي" بشكل دوري كجزء من GetBulkRequest الأولي ل SNMP.
من أجل تقليل أخطاء وحدة المعالجة المركزية (CPU) التي تتسبب فيها عملية SNMP، تمت التوصية باتباع خطوات التخفيف لأخطاء وحدة المعالجة المركزية لبروتوكول SNMP المشار إليها في المقالة وتجنب إستطلاع معرفات العملاء المرتبطة بنظام GSP. بدون إستطلاع عبر بروتوكول SNMP لمعرف فئة المورد (OIDs) المرتبط بمعيار GSP، لم يتم ملاحظة أية أخطاء لوحدة المعالجة المركزية الناتجة عن عملية بروتوكول SNMP، كما انخفض معدل التجاوز بشكل ملحوظ.
المراجعة | تاريخ النشر | التعليقات |
---|---|---|
3.0 |
31-Jul-2024 |
إعادة الاعتماد، النص البديل، الرؤوس الثابتة، الترقيم، وتحسين HTML SEO. |
2.0 |
02-Jun-2023 |
تقويم |
1.0 |
21-Nov-2019 |
الإصدار الأولي |