Dell EMC Networking — tworzenie i stosowanie listy ACL zarządzania w serii X
Summary: Dell EMC Networking — tworzenie i stosowanie listy ACL zarządzania w serii X
Symptoms
Tworzenie i stosowanie listy ACL zarządzania w serii X: Blokowanie dostępu hosta do zarządzania przełącznikami
Przykładowy scenariusz i wymagania
Implementują przełącznik z serii X i chcą uniemożliwić użytkownikom z określonej podsieci dostęp do funkcji zarządzania przełącznikami. Aby to osiągnąć, utworzymy listę kontroli dostępu (ACL), wypełnimy ją odpowiednimi wpisami kontroli dostępu (ACE) i zastosujemy listę ACL do interfejsu.
W tym scenariuszu celem jest zablokowanie wszystkim klientom w podsieci 172.31.200.0/24 dostępu do adresu IP przełącznika. Przełącznik ma wiele adresów IP, zarówno w podsieci lokalnej klienta (172.31.200.3), jak i w oddzielnej podsieci bezprzewodowej.
Jeśli routing jest włączony w serii X, utworzona lista ACL musi blokować dostęp zarówno do adresu IP przełącznika w podsieci lokalnej, jak i do ruchu pochodzącego z podsieci klienta kierowanego do innych adresów IP podsieci na przełączniku (np. od 172.31.200.0/24 do 172.30.200.3).
Środowisko
Sieć klienta: 172.31.200.0/24
Połączenie sieciowe klienta: Nieoznaczona sieć VLAN 50, port Gi 1/0/1
Adresy IP przełącznika:
VLAN 10 – bezprzewodowe – 172.30.200.3/24
VLAN 50 – klienci 172.31.200.3/24
Etapy tworzenia
Administracja siecią -> zabezpieczenia -> ACL
Fig. 1 – Dostęp do strony konfiguracji ACL/ACE w WebGUI
UWAGA: Seria X nie obsługuje konfiguracji list ACL/ACE za pośrednictwem interfejsu wiersza poleceń. Konfiguracja wykonana za pośrednictwem WebGUI będzie nadal wyświetlana w wyjściach CLI pokazujących konfigurację, patrz rys. 1a.
Rys. 1a – Ostateczna lista ACL utworzona przy użyciu tego artykułu. Zwróć uwagę, jak przełącznik zastępuje niektóre numery portów ich dobrze znanym użyciem (23 staje się 'telnet', a 80 staje się 'www')
Tworzenie listy ACL
Lista ACL oparta na protokole IPV4 -> Edycja -> Dodaj -> Utwórz nazwę (bez spacji) -> OK -> Zamknij wyskakujące okienko
Dodawanie wpisów (ACE) do listy ACL
ACE oparte na protokole IPv4 -> (Nazwy list ACL znajdują się na liście rozwijanej, wybierz tę, którą właśnie utworzyłeś) -> Edytuj -> Dodaj -> Wypełnij reguły wpisu -> Ok
Każdy wpis ACE będzie ukierunkowany na jeden protokół zarządzania, który chcemy zablokować, a także na unikatowe miejsce docelowe, które chcemy zablokować. Musimy utworzyć oddzielną grupę ACE dla drugiego możliwego adresu IP zarządzania, ponieważ alternatywą jest blokowanie protokołów bez względu na ich miejsce docelowe – co zablokowałoby każdy z tych protokołów próbujących przejść przez przełącznik, co znacznie wykracza poza to, co próbujemy zrobić – lub blokowanie bez względu na protokół i tylko w oparciu o miejsce docelowe, co uniemożliwiłoby wszelki ruch kierowany!
Figa. 3 – Dodanie ACE do blokowania klientów 172.31.200.0/24 z Telneting do 172.31.200.3. Opcje w kolorze czerwonym są wymagane do naszych celów; logowanie - zakreślone na pomarańczowo - jest opcjonalne.
UWAGA: Format określania maski w ACL/ACE jest odwrotny do metody używanej do maskowania podsieci. Aby określić podsieć 172.31.200.0/24 (255.255.255.0), maska z symbolami wieloznacznymi to 0.0.0.255. Podobnie, aby określić pojedynczy host (/32 lub 255.255.255.255 w notacji maski podsieci), należy użyć maski wieloznacznej 0.0.0.0.
Powtórz dla każdego protokołu (1 dla telnet(23), 1 dla http(80), 1 dla https(443), 1 dla ssh(22) [jeśli skonfigurowano – dostęp ssh do serii X jest domyślnie wyłączony] i docelowego, a na koniec instrukcję 'allow all' na końcu, aby zezwolić na wszystko, co nie jest wyraźnie zablokowane – patrz Rys. 4) -> Ok
Fig. 4 – Stworzenie oświadczenia "permit all". Niedodanie tego spowoduje niejawną odmowę na końcu listy ACL, co oznacza, że jeśli przełącznik osiągnie koniec listy ACL (reguły są stosowane w kolejności priorytetów) i żadna z reguł nie jest zgodna, odrzuci ruch. Dodajemy zezwolenie, aby uniknąć odrzucania całego specjalnie ukierunkowanego ruchu i całego ruchu, do którego w ogóle się nie odnosimy.
Po zakończeniu wpisy ACE dla ACL powinny wyglądać podobnie do Rys. 5 poniżej. Na rysunku pominięto zmienne, których nie skonfigurowaliśmy, aby zapewnić lepsze wyświetlanie.
Figa. 5 – Zredagowane dla jasności. Spowoduje to wyświetlenie wszystkich ACE (reguł), które składają się na daną listę ACL. Zobacz tutaj, blokujemy 4 różne protokoły - 22, 23, 80 i 443 - do dwóch różnych miejsc docelowych - 172.31.200.3/32 i 172.30.200.3/32.
Stosowanie listy ACL do interfejsu
Powiązanie ACL -> Edytuj -> Kliknij ikonę Edytuj według portu -> Pozostaw zaznaczoną opcję "Ingress" -> Zaznacz opcję "Wybierz listę ACL opartą na protokole Ipv4 (wybierz listę ACL z listy rozwijanej, jeśli nie jest jeszcze wypełniona") -> OK
Fig. 6 – Zastosowanie ACL do interfejsu. Wybieramy ruch przychodzący, aby cały ruch przychodzący w Gi1/0/1 był sprawdzany pod kątem listy ACL przed dopuszczeniem do dalszego przełącznika.
W przypadku list ACL kontrolujących dostęp do przełącznika należy sprawdzić ruch przychodzący. Listy ACL ruchu wychodzącego mają swoje miejsce, ale należy pamiętać, że ruch blokowany przez listę ACL ruchu wychodzącego przeszedł już przez wewnętrzną strukturę przełącznika. Jeśli ruch ma zostać porzucony, najlepiej jest to zrobić, zanim zasoby zostaną dopuszczone do sieci szkieletowej przełącznika i w poprzek niej. Odmawiaj jak najbliżej źródła!
UWAGA: W przypadku serii X listy ACL mogą być powiązane tylko z interfejsami fizycznymi lub logicznymi, które agregują interfejsy fizyczne. Oznacza to, że listy ACL mogą być powiązane z portami fizycznymi i lagami (kanałami portów), ale nie mogą być powiązane z sieciami VLAN.