بصمة — منصة عربية لتعليم البرمجة والشبكات والإلكترونيات

Network security design: ‏MACsec وTrustSec (SGT وSXP وSGACL)

بنجهّز الشبكة…
01 / ملخص التجربة

Network security design: ‏MACsec وTrustSec (SGT وSXP وSGACL)

الـ uplink المشفّر واقف، والسيرفر مش عارف مين موظف ومين contractor. هتصلّح جلسة MACsec ‏(MKA)، وتنقل الـ security group tags بـ SXP، وتكتب سياسة بالأدوار بدل الـ IPs (SGACL) — نفس فكرة الـ segmentation اللي بيبني عليها SD-Access والـ NAC وNGFW.

مدة التجربة 35 دقيقة · 3 مهام

الأجهزة في بداية التجربة

  • PC1 — كمبيوتر
  • PC2 — كمبيوتر
  • DSW1 — سويتش L3
  • DSW2 — سويتش L3
  • SRV — سيرفر

التوصيلات

  • PC1 eth0 ↔ DSW1 Gi1/0/3
  • PC2 eth0 ↔ DSW1 Gi1/0/4
  • DSW1 Gi1/0/1 ↔ DSW2 Gi1/0/1
  • DSW2 Gi1/0/5 ↔ SRV eth0

العناوين المضبوطة مسبقًا

  • DSW1 vlan: 10.1.10.1/24
  • DSW1 vlan: 10.1.20.1/24
  • DSW1 gi1/0/1: 10.0.12.1/24
  • DSW2 gi1/0/1: 10.0.12.2/24
  • DSW2 gi1/0/5: 10.9.9.1/24
02 / المهام التي ستطبقها
  1. 01
    الـ uplink بين DSW1 وDSW2 مشفّر بـ MACsec بس مفيش ولا باكت بتعدّي — خلّي جلسة الـ MKA تبقى Secured

    يتحقق المعمل من على DSW1: الأمر show mka sessions يظهر فيه «»، PC1 يصل إلى 10.9.9.10 (ping)، على DSW2: الأمر show macsec summary يظهر فيه «»

    تلميح / الحل المقترح
    show mka sessions على DSW1 ← Status: Pending مش Secured، وshow mka sessions detail ← ICV mismatch: CAK differs. الـ MKA ‏(MACsec Key Agreement) بيستخدم الـ pre-shared key: الـ CKN ‏(رقم الـ key، هنا 01) لازم يتطابق عشان الطرفين يشوفوا بعض، والـ CAK ‏(الـ key-string) لازم يتطابق عشان الـ ICV يطلع صح. ‏macsec network-link بيمنع أي data لحد ما الجلسة تبقى Secured. قارن show running-config | section key chain على الاتنين، والحل على DSW2: key chain MKA-KC macsec ← key 01 ← key-string 12345678901234567890123456789012. ‏MACsec ‏(802.1AE) بيشفّر hop-by-hop على الـ link (Layer 2) عكس IPsec اللي end-to-end
  2. 02
    DSW2 مش عارف مين Employee ومين Contractor — خلّي الـ SXP ينقل الـ IP-SGT bindings من DSW1

    يتحقق المعمل من على DSW2: الأمر show cts sxp connections يظهر فيه «»، على DSW2: الأمر show cts role-based sgt-map all يظهر فيه «»

    تلميح / الحل المقترح
    الـ classification حصل على DSW1 ‏(cts role-based sgt-map: موظفين 10، contractors 20) لكن الـ enforcement هيكون على DSW2 جنب السيرفر، فلازم DSW2 يعرف الـ SGT بتاع الـ source. ‏show cts sxp connections على DSW2 ← Off (TCP MD5 password mismatch). الـ SXP ‏(TCP 64999) فيه speaker بيبعت الـ bindings وlistener بيستقبلها، والباسورد لازم يتطابق (case-sensitive). على DSW2: cts sxp default password Basma-SXP. بعدها show cts role-based sgt-map all على DSW2 ← 10.1.10.0/24 ‏10 SXP و10.1.20.0/24 ‏20 SXP. البديل: inline tagging ‏(cts manual على الـ link من الناحيتين) والـ SGT بيتنقل جوه الـ frame في Cisco Meta Data header
  3. 03
    الـ Contractors ‏(SGT 20) يوصلوا للسيرفرات ‏(SGT 100) على HTTP بس — والموظفين ‏(SGT 10) من غير قيود

    يتحقق المعمل من على PC2: الأمر curl http://10.9.9.10 يظهر فيه «200 OK»، PC2 لا يصل إلى 10.9.9.10، PC1 يصل إلى 10.9.9.10 (ping)، على DSW2: الأمر show cts role-based permissions يظهر فيه «»

    تلميح / الحل المقترح
    على DSW2 (الـ egress اللي عارف الـ destination SGT): ip access-list role-based WEB-ONLY ← permit tcp dst eq 80 ← deny ip ← exit ← cts role-based permissions from 20 to 100 WEB-ONLY ← cts role-based enforcement. الـ SGACL مش فيه IP addresses خالص: السياسة مكتوبة بالأدوار (مصفوفة source group × destination group)، فلو الـ contractor غيّر مكانه أو الـ IP بتاعه السياسة بتمشي معاه. اللي مش ليه entry بياخد الـ default ‏(permit). جرّب من PC2: curl http://10.9.9.10 ينجح وping يفشل، وshow cts role-based counters على DSW2
03 / تجارب مرتبطة