TTL propagation və PE hardening

Nəzəri əsaslar və memarlıq

Laboratoriya işi: NSA və Cisco SAFE təcrübələrinə uyğun PE sərhəd marşrutlaşdırıcılarının və MPLS nüvəsinin kompleks auditi və sərtləşdirilməsi (Hardening). 1. TTL yayılmasının idarəsi (RFC 3443): uniform rejimdə (Cisco-da susmaya görə) IP TTL label-ə kopyalanır və müştərinin traceroute-u bütün tranzit P marşrutlaşdırıcılarını görür. no mpls ip propagate-ttl pipe rejimini aktivləşdirir: label TTL-i 255 ilə başlanır, IP TTL nüvədə azalmır və müştəri nüvəni PE-lər arasında tək keçid kimi görür; forwarded variantı nüvəni yalnız müştərilərin tranzit trafiki üçün gizlədir, mühəndisə isə PE-nin özündən traceroute saxlayır. Bu yalnız kəşfiyyatı çətinləşdirir və P marşrutlaşdırıcılarının qorunması deyil: həqiqi qoruma müştərinin infrastruktur ünvanlarına marşrutunun olmaması (VRF) və CoPP ilə ACL-lərin ona cavab verməməsidir. 2. İdarəetmə portlarının filtrasiyası: Telnet və HTTP söndürülür, açarlar və taymautlarla SSHv2, VTY ACL-ləri, OOB interfeys və ya ayrıca MGMT VRF vasitəsilə idarəetmə. 3. BGP sessiyalarının qorunması: TCP MD5 və ya TCP-AO (RFC 5925) autentifikasiyası və GTSM (Generalized TTL Security Mechanism, RFC 5082): hər iki tərəf TTL 255 göndərir, birbaşa qoşulmuş peer üçün ttl-security hops 1 yalnız TTL 254-255 qəbul edir. GTSM uzaqdan hücumlardan qoruyur, lakin eyni seqmentdəki təcavüzkardan yox, ebgp-multihop ilə uyğun gəlmir və hər iki tərəfdə eyni anda aktivləşdirilməlidir. Müştəri interfeyslərində uRPF (RFC 3704) onları tamamlayır.

MPLS-də TTL: uniform və pipe (RFC 3443)

Etiket qoyularkən ingress PE IP başlığının TTL-i ilə etiketin TTL-i arasında əlaqəni necə quracağını seçir. Uniform rejimdə IP TTL etiketə kopyalanır, hər LSR etiketin TTL-ini azaldır, çıxışda isə dəyər geri kopyalanır (minimum nəzərə alınmaqla): müştərinin traceroute-u hər P marşrutlaşdırıcısını görür. Pipe (və short pipe) rejimində etiketin TTL-i sabit qiymətlə (255) başladılır, paketin daxilindəki IP TTL nüvədə azalmır, buna görə müştəri nüvəni PE-lər arasında tək addım kimi görür. Cisco defolt olaraq uniform rejimdə işləyir; no mpls ip propagate-ttl hər şey üçün pipe-ı aktiv edir, forwarded rejimi müştərilərin tranzit trafiki ilə məhdudlaşdırır, local isə PE-nin özünün yaratdığı trafik üçün propagate-i saxlayır. Praktik seçim forwarded-dır: müştəri nüvəni görmür, PE-dəki mühəndis isə yenə də onun üzərindən trace apara bilir. Junos protocols mpls səviyyəsində no-propagate-ttl istifadə edir; VRP-də rejimi mpls görünüşündə ttl propagate əmrləri idarə edir.

Yan təsirlər: nüvənin daxilində yaranan ICMP xətalarını (məsələn, PMTUD üçün) P marşrutlaşdırıcısı müştəriyə birbaşa göndərə bilmir, ona görə onlar LSP boyunca egress PE-yə qədər tunelləşdirilir (RFC 3032, bölmə 2.3.2), nüvənin diaqnostikası isə ping mpls/traceroute mpls-ə keçir. P ünvanlarının gizlədilməsi yalnız kəşfiyyata mane olmaqdır, qoruma deyil: əsl qoruma müştərinin infrastruktur ünvanlarına marşrutunun olmamasıdır (VRF) və CoPP ilə ACL-lərin ona cavab verməməsidir.

GTSM (RFC 5082): eBGP-nin TTL ilə qorunması

Birbaşa qoşulmamış paket generatoru TTL 255 olan paketi elə göndərə bilməz ki, o, TTL 255 ilə çatsın: hər marşrutlaşdırıcı TTL-i azaldır. GTSM bundan istifadə edir: hər iki qonşu BGP seqmentlərini TTL 255 ilə göndərir, qəbul edən isə yalnız TTL-i həddən aşağı olmayan paketləri qəbul edir. Birbaşa qoşulmuş pir üçün düzgün qiymət 255-dir; Cisco ttl-security hops N TTL-i 255 - N-dən qəbul edir, yəni hops 1 254-255-i buraxır (bir tranzit marşrutlaşdırıcılıq ehtiyat). Mexanizm ebgp-multihop ilə uyğun gəlmir və yalnız uzaqdan hücumlardan qoruyur: eyni seqmentdəki hücumçu onu keçir, ona görə GTSM autentifikasiya ilə birləşdirilir. GTSM hər iki tərəfdə aktiv edilməlidir: GTSM-siz tərəf TTL 1 göndərir, GTSM-li tərəf belə seqmentləri atır və sessiya qalxmır.

Sessiya autentifikasiyası: MD5 və TCP-AO

TCP MD5 opsiyası (RFC 2385) seqment və ortaq sirr üzərində MD5 hash dəyəridir: zəif hash funksiyası, sessiyanı sıfırlamadan açarın dəyişdirilməsi yoxdur, alqoritm seçimi yoxdur. TCP-AO (RFC 5925; RFC 5926-ya görə HMAC-SHA-1-96 və AES-128-CMAC-96 alqoritmləri) opsiya 29-dan, hamar dəyişmə üçün açar identifikatorlarından (KeyID və RNextKeyID), hər əlaqə üçün master açardan alınan trafik açarlarından istifadə edir və TCP opsiyalarını qoruyur. Heç bir mexanizm məlumatı şifrələmir. Dəstək platformadan asılıdır: IOS-XE və Junos müasir relizlərdə TCP-AO-ya malikdir, RouterOS yalnız MD5-i bacarır, Huawei isə öz variantlarını (keychain daxil olmaqla) təklif edir. Sirr təsadüfi və uzun olmalı, hər iki tərəfdə eyni olmalıdır; uyğunsuzluq olduqda seqmentlər səssizcə atılır, Cisco-da isə jurnalda %TCP-6-BADAUTH görünür (bu, eyni zamanda seçmə cəhdinin faydalı əlamətidir).

uRPF (RFC 3704, BCP 84)

Unicast Reverse Path Forwarding paketin mənbəyinin paketin gəldiyi interfeys vasitəsilə əlçatan olduğunu yoxlayır. Strict rejim (Cisco ip verify unicast source reachable-via rx, Junos rpf-check, Huawei ip urpf strict, RouterOS rp-filter=strict) müştərinin yeganə PE-CE kanalı üçün uyğundur. Loose rejim yalnız marşrutun varlığını yoxlayır və peering və multihoming üçün uyğundur; cədvəldə mövcud olan ünvanların saxtalaşdırılmasından qorumur. Asimmetrik trafik strict rejimi pozur, ona görə multihoming zamanı feasible rejimi və ya loose istifadə olunur. Yoxlama VRF-in FIB-inə görə aparılır, buna görə müştəri A üçün öz VRF-indən 10.255.0.2 ünvanının saxtalaşdırılması bu interfeys vasitəsilə ona marşrut olmadıqda atılacaq.

Lazımsızın söndürülməsi

Hücum səthi istifadə olunmayan xidmətlərin söndürülməsi ilə azaldılır: lazım olmayan yerdə HTTP/HTTPS, Telnet, müştəri interfeyslərində CDP/LLDP, proxy-ARP, ICMP redirects, IP source-routing, small servers və xarici interfeyslərdə ip unreachables. İdarəetmə ayrıca VRF-ə və ya out-of-band şəbəkəyə keçirilir, SSH açarlar və timeout-larla işləyir, login block-for brute force-a qarşıdır, vaxt autentifikasiyalı NTP ilə sinxronlaşdırılır və jurnal aparılır. Müştəri interfeyslərində MPLS ümumiyyətlə yoxdur (VPN izolyasiyası dərsinə baxın).

Hücumlar və yoxlamalar

Təhlükəsiz tətbiq

Hardening tərəflərdən birində səhv edildikdə sessiyaları pozur. Ona görə dəyişikliklər geri qaytarma ilə edilir: Cisco reload in 10, Junos commit confirmed 5, RouterOS Safe Mode; GTSM və parol iş pəncərəsində hər iki tərəfdə eyni anda dəyişdirilir, no mpls ip propagate-ttl isə müştəridən və PE-nin özündən traceroute ilə yoxlanılır. Hər tədbir yalnız show running-config ilə yox, hücumla yoxlanılır: əks-tədbir sayğac və ya jurnal buraxmırsa, çox güman ki, işləmir.

Memarlıq sxemi və topologiya

+-----------+        Customer Traceroute Packet (TTL=1)         +-----------+
|   CE-1    | ------------------------------------------------> |   PE-1    |
| (Customer |   Hidden Core: mpls ip propagate-ttl = disabled   | (Ingress  |
|  Network) | <================================================ |  Hardening|
+-----------+        Core P-routers invisible in traceroute     +-----------+

Trafik axını və etiket steki sxemi

MPLS TTL Propagation vs Pipe Hardening:
1. Uniform model (Cisco default): the IP TTL is copied into the MPLS TTL
   and every core hop decrements it.
   Result: a customer traceroute shows all internal P router addresses
   (reconnaissance help for an attacker).
2. Pipe model ('no mpls ip propagate-ttl'; 'forwarded' limits it to
   customer transit traffic):
   - The MPLS TTL is initialized to 255 at the ingress PE.
   - Core P routers decrement only the MPLS TTL; the IP TTL is not
     decremented in the core.
   - A customer traceroute shows the ingress and egress PE only, so the core
     addresses are hidden.
3. This only makes reconnaissance harder. Real protection: no customer
   route to infrastructure addresses (VRF), CoPP and ACLs that do not
   answer, uRPF on customer links.
4. Verify with traceroute from the CE and from the PE itself.

Vəziyyətlər və parametrlər cədvəli