Wykrywanie pętli na przełącznikach EXTREME z exos

Do wykrywania pętli może służyć stp ale ze względów oczywistych ja przeważnie używam mechanizmu ELRP.

Aby skorzystać z ELRP potrzebne jest kilka prerekwizytów:

• wszystkie porty powinny być w vlanie chronionym przez elrp, ja zwykle tworzę nowy vlan np z tagiem 3000 i przypinam jako nietagowane do niego wszystkie porty
• włączamy klienta elrp – enable elrp-client
• dodajemy wszystkie porty i wykluczamy uplinki. Prz dodawaniu możemy wskazać co ma się stać w przypadku wykrycia pętli – czy port ma być wyłaczony, na jak długo czy np. ma być tylko alarm i trap
  • Switch.19 #configure elrp-client periodic elrp_test ports all log disable-port duration 15
  • Switch.20 #configure elrp-client disable-ports exclude 24   (This is optional but vital so that uplink ports do not get disabled)
• [za https://extremeportal.force.com/ExtrArticleDetail?an=000083207%5D

Oczywiście to najprostsza konfiguracja, możliwe jest zapewnienie ochrony między vlanowej [np configure elrp-client inter-vlan-loop-detection [on | off]
This command was first available in ExtremeXOS 30.1.], czy portów z włączoną autentykacją.

Gdy mamy już skonfigurowany przełącznik, warto pzretestować czy zapięcie pętli między portami wygeneruje wpis w logach:

06/30/2022 09:10:48.55 Disabling port 5. Permanent
06/30/2022 09:10:48.55 [CLI:Default:6] LOOP DETECTED : 107 transmitted, 2 received, ingress slot:port (5) egress slot:port (11)

jeśli tak to warto go wysłać do XMC/Site Engine [oczywiście warto aby był skonigurowany syslog kierujący do XMC/SE]

Gdy mamy już event syslog w SE możemy na jego podstawie wygenerować alarm a co za tym idzie wykonać inne akcje np. wysłać email do administratorów.

W tym celu tworzymy custom criteria alarm, wybieramy jako kryterium Information Criteria edytujemy listę kryteriów i dodajemy frazę [Phrase] jako zawierającą ciąg znaków ‚Disabling port’ zaznaczając przy niej od razu checkbox.

Pozostało nam wskazać w akcjach co ma się wydażyć po spełnieniu kryterium – ja preferuje email [oczywiście musi być skonfigurowany server SMTP tutaj czasem trzeba pogrzebać w plikach konfiguracyjnych z poziomu powłoki]

W opcjach wysyłki można zmienić zawartość wysyłanego maila obudowując o odpowiednie zmienne, ja zwykle ustawiam mu w temacie LOOP: $message

I to cała filozofia.

Extreme Control – EAP-TLS authentication 802.1x

Szybkie howto dla dodania autentykacji po certyfikatach dla Extreme Control

Przede wszystkim nasz NAC gateway czyli appliance extreme control musi być dodany do domeny AD. W tym celu w profilu LDAP musi być konto z uprawnieniami do:

Reset password 
Read and write account restrictions 
Read and write DNS host name attributes 
Validated write to DNS host name 
Validated write to service principal name 
Write servicePrincipalName

oraz do odczytu profili LDAP:

https://extremeportal.force.com/ExtrArticleDetail?an=000090980

po restarcie NAC należy zweryfikować czy dodał się do domeny.

Następnie wrzucamy certyfikaty trusted root [najlepiej bundle z SubCA] oraz jeśli ma to być EAP-TLS generujemy CSR do podpisu w domenie:

certyfikat dla nac z poziomu konsoli ssh nac:

generujemy klucz prywatny i za jego pomocą csr

openssl req -new -key nac01-server.key -out nac1.csr -reqexts SAN -config <(cat /etc/ssl/openssl.cnf <(printf „\n[SAN]\nsubjectAltName=DNS:ena-k3s01.bp-itaka.net”))

certyfikat podpisujemy w domenowym w CA za pomocą kopi szablonu RAS-IAS – ITAKA RAS IAS template z pozomu powershell

certreq -submit -attrib „CertificateTemplate:KopiaRAS-IAS” nac.csr

UWAGA – nazwa template jest bez spacji – inaczej niż to wygląda z poziomu GUI !

Template pownien zostać zmodyfikowany aby uwzględniał nazwę dns z żądania oraz aby cert był wystawiany na 5 lat

Podpisany csr łączymy z kluczem prywatnym server.key

openssl pkcs12 -export -out nac1.pfx -inkey nac01-server.key -in nac1.cer

i wgrywamy do NAC.

Palo Alto – migracja konfiguracji z Cisco ASA

Dziś krótko, o migracji Cisco ASA do Palo Alto z użyciem narzędzia se stajni Palo – Expedition [migration tool].

Od razu co cię nie zapewne nie uda automatycznie –

• Zony – prawdopodobnie wszystkie interfacey będą przy migracji w osobnych strefach więc może ich być zdecydowanie za dużo – stąd ręczna robota – konsolidacja stref i wszystkie zależności – security, naty.. Ja tutaj dodatkowo z cli zmieniałem nazwy wszystkim strefom dodając ‚-zone’ na końcu. Polecam Notepad++ i ręczną automatyzację. rename zone … to …
• NAT’y – o ile source naty przejdą pewnie poprawnie o tyle destination, ze względu na specyfikę Palo Alto będą wszystkie do poprawki, wiadomo obie zony zewnętrzne na zewn. IP i translacja do środka. Komplementarnie trzeba wszystkie polityki security poprawić – zony WAN do LAN, z zewn IP 🙂 Dodatkowo ważne aby zwrócić uwagę na kolejność reguł NAT !
• Obiekty – pewnie będzie tutaj zabawa bo serwisów będzie mnóstwo zaciągniętych z ASY. Co więcej może wystąpić sytuacja gdzie nie był wskazany typ UDP czy TCP – do poprawki w Expedition na etapie migracji. Mogą się pojawić sytuacje gdzie dany serwis będzie źle zampowany do portu np ‚domain’ mi zamapowało do portu 6500 🙂
• Duplikaty nazw – pewnie będzie tego sporo, na Palo sprawdzana jest unikalnosć nazw wielu obiektów.
• Interface’y – na etapie migracji w Expedition dobrze od razu zmienić. Warto pamiętać aby wrzucić ‚czysty’ konfig z Palo aby potem nie było duplikatów.

Co da się automatem ?

• obiekty
• reguły security [weryfikacja i poprawki]
• naty j.w
• interface’y
• tunele ipsec s2s

Do uzupełnienia miałem tagi, które pojawiały się w expedition ale nie aplikowały się do polityk. Zrobiłem ręcznie przez CLI z udziałem excel i notepad++

Finalnie dostajemy spory bałagan – za dużo stref, za dużo obiektów, brak reguł aplikacyjnych, duplikaty. Przy mniejszych migracjach na pewno warto rozważyć migrację ręczną bez użycia Expedition tylko wyklikanie wszystkiego ‚ręcznie’

Na koniec – samo przepięcie, jak w każdym przypadku przy zmianie urządzenia stojącego na brzegu i mającego po drugiej stronie sprzęt nad którym nie mamy kontroli, warto zapewnić sobie na czas przepięcia udział administratorów providera aby mogli poczyścić tablice arp i ewentualne statyczne przypisania mac i/lub port security.

Ze swojej strony na palo oczywiście dobrze jest pamiętać o odpowiednio długim oknie serwisowym [w 5 min raczej to nie zadziała] oraz o kilku fajnych poleceniach jak:

• test arp [wysyłanie GARP z palo aby inne urządzenia odświeżyły wpisy]
• test vpn [aby zainicjować tunele IPSEC]

Tyle na szybko 🙂