Dostęp zdalny oraz prawa użytkownika w routerach CISCO

Zarządzanie dostępem administracyjnym jest procesem krytycznym w każdej sieci to od administratora zależy, kto i do czego ma dostęp oraz jakie czynności na danym urządzeniu może wykonać. Routery CISCO zapewniają wiele sposobów kontroli dostępu do urządzenia oraz posiadają szereg mechanizmów pozwalających na ustalenie uprawnień. Artykuł opisuje jak skonfigurować urządzenie wykorzystując do tego połączenie zdalne oraz jak przypisać prawa do wykonania poszczególnych zadań konkretnym, zdefiniowanym użytkownikom.

W przypadku routerów i przełączników CISCO proces dostępu do urządzenia możemy zrealizować na wiele sposobów.

Wyróżniamy następujące metody:

• password – dostęp do trybu użytkownika oraz do trybu uprzywilejowanego po podaniu wcześniej ustalonego hasła,
• local database – metoda oparta na zdefiniowaniu bazy uprawnionych użytkowników, baza jest zapisana w pamięci urządzenia. W przeciwieństwie do metody poprzedniej oprócz hasła musimy podać nazwę użytkownika. Aby móc logować się przy wykorzystaniu tych samych danych uwierzytelniających, baza danych musi zostać powielona na każdym z urządzeń.
• AAA (Authentication Authorization Accounting) – model ten stanowi spójny system w obrębie, którego działają mechanizmy odpowiedzialne za bezpieczny dostęp do sieci i jej zasobów. Modułowy charakter mechanizmu pozwala wpływać na konfigurację trzech głównych usług: autentykacji (authentication), autoryzacji (authorization) oraz raportowania (accounting). Model ten może opierać się na lokalnej bazie użytkowników – AAA Local Authentication (self-contained AAA) oraz na bazie opartej o serwery uwierzytelniające – AAA Server-based

Celem uproszczenia opisywanych czynności i by pokazać działanie wszystkich mechanizmów na konkretnym przykładzie w całym artykule przyjąłem następującą topologię:

Pierwszym i chyba najprostszym sposobem, który możemy wykorzystać aby skonfigurować urządzenie jest skorzystanie z protokołu Telnet. Dla nie wtajemniczonych standard ten został stworzony aby umożliwić obsługę odległego terminala w architekturze klient-serwer, tak aby po połączeniu z urządzeniem móc je kontrolować .

Naszym celem będzie zdalna konfiguracja routera R3, która będzie wykonana z komputera Windows 10.

Całą procedurę rozpoczniemy od sprawdzenia poprawności połączenia pomiędzy urządzeniami.

Jak widać komunikacja jest zachowana a więc spróbujmy połączyć się z routerem z wykorzystaniem protokołu Telnet. Po wywołaniu polecenia – telnet 172.16.1.1 otrzymujemy następującą informację

Jak widać nie udało się ustanowić połączenia.

Otrzymaliśmy informację o potrzebie wprowadzenia hasła lecz hasło nie zostało do tej pory ustawione. Spróbujmy to zmienić i wprowadźmy stosowne ustawienia na routerze R3. Najprostsza konfiguracja sprowadza się do wydania następujących poleceń.

Polecenie: line vty <numer linii> wydane w trybie konfiguracji globalnej routera nakazuje urządzeniu przejście do konfiguracji linii wirtualnych, które umożliwiają nam zdalne połączenie z routerem (sesja telnet bądź SSH). Liczba dostępnych do wykorzystania wirtualnych linii jest różna i zależy od modelu urządzenia w naszym przykładzie konfigurujemy 5 linii (od 0 do 4). Dzięki temu możliwe będzie nawiązanie pięciu oddzielnych połączeń. Komenda: password <hasło> ustawia hasło niezbędne do zestawienia połączenia natomiast polecenie: login włącza logowanie.

Sprawdźmy więc czy tym razem uda się nawiązać poprawne połączenie. Wydajmy ponownie polecenie: telnet 172.16.1.1 Jak widać poniżej nastąpiła inicjacja połączenia a dostęp do linii poleceń routera możliwy jest po podaniu hasła.

Po poprawnym połączeniu klient znajduje się w trybie użytkownika.

Tryb ten nie pozwala na wprowadzenie jakichkolwiek ustawień a więc spróbujmy przełączyć się do trybu uprzywilejowanego.

Po wprowadzeniu polecenia enable, które pozwala na przejście do trybu uprzywilejowanego otrzymujemy komunikat o braku hasła. Hasło do trybu uprzywilejowanego jest dodatkowym zabezpieczeniem (druga linia obrony), które chroni router przed nieautoryzowanym dostępem.

Dajmy użytkownikowi podłączonemu zdalnie możliwość przejścia w tryb uprzywilejowany. Zadanie wykonamy wydając polecenie: enable password <hasło>

Od tej pory po podaniu poprawnego hasła router pozwoli nam na zmianę trybu. A więc na tą chwilę mamy skonfigurowane dwa hasła:

• pierwsze – pozwalające na nawiązanie sesji Telnet – hasło: tajnehasło,
• drugie – pozwalające na przejście do trybu uprzywilejowanego – hasło: bardzotajnehaslo.

Po nawiązaniu połączenia i wprowadzeniu zdefiniowanych haseł uzyskujemy dostęp do trybu uprzywilejowanego routera.

Profesjonalne usługi informatyczne dla firm. W swojej ofercie posiadamy Outsourcing IT, certyfikaty SSL, szkolenia informatyczne oraz audyty bezpieczeństwa.

Zadzwoń i dowiedz się więcej, tel. 68 411 40 00.

Usługi informatyczne

Użycie protokołu Telnet nie należy do najbezpieczniejszych ponieważ cała komunikacja prowadzona jest otwartym tekstem bez zastosowania jakichkolwiek metod szyfrowania. Jak widać poniżej przechwycona sesja uwidacznia wszystkie wpisane komendy i polecenia.

Kolejną wadą tej metody jest przechowywanie haseł w formie czystego tekstu w pliku konfiguracji routera. Wydanie komendy show running-config uwidacznia skonfigurowane hasła.

Aby zabezpieczyć hasła i przynajmniej trochę utrudnić ich odczytanie możemy użyć usługi, która odpowiada za ich zaszyfrowanie (słaba metoda ale zawsze lepsza niż żadna). Dlatego w trybie konfiguracji globalnej wydaj polecenie: service password-encryption

Włączenie usługi jest odnotowane w pliku konfiguracji routera i jak możesz zauważyć hasło enable oraz hasło linii VTY nie są już zapisane w formie czystego tekstu.

Użyty algorytm szyfrowania (7 za słowem password) nie należy do najbezpieczniejszych gdyż opiera się on na metodzie Vigenère’a i jest łatwy do złamania.

Po wpisaniu ciągu 1311161805090C2B382827 i wysłaniu zapytania dostajemy odpowiedź – rozszyfrowane hasło.

Zdecydowano się mechanizm szyfrowania poprawić tak aby zagwarantować lepszą ochronę danych uwierzytelniających. Zdecydowano się na użycie algorytmu MD5, który jest funkcją nieodwracalną czyli na podstawie przechwyconego ciągu nie da się odwrócić procesu tak by wyznaczyć hasło (co nie jest równoznaczne z tym, że hasła nie da się złamać).

Hasło definiuje się za pomocą polecenia: enable secret <hasło>. Po wyświetleniu konfiguracji routera widać, że za ukrycie hasła odpowiada funkcja MD5 (oznaczenie cyfra 5 po słowie secret).

W ten sposób ustawiliśmy dwa hasła, które pozwalają przejście do trybu uprzywilejowanego.

Aby zwiększyć ochronę decydujemy się na usunięcie hasła zdefiniowanego za pomocą komendy enable password <hasło>. Usunięcie odbywa się za pomocą polecenia: no enable password

Jak widać powyżej hasło podatne na złamanie zostało wycofane.

Zmianę liczby dostępnych linii VTY można wykonać za pomocą polecenia: line vty <zakres_linii>. Linie od 0 do 4 tworzone są automatycznie. Wydanie np. polecenia line vty 0 12, spowoduje utworzenie 13 linii wirtualnych. Niemożliwe jest utworzenie linii bez zachowania kolejności czyli np. utworzenie linii 14 spowoduje dodanie linii od 0 do 14 natomiast usunięci linii do np. 7 będzie wykasuje porty od siódmego włącznie.

Niemożliwe jest wykasowanie pięciu pierwszych linii (od 0 do 4), próba usunięcia linii z tego zakresu powoduje wygenerowanie błędu.

Zmianę dopuszczalnego czasu korzystania z linii terminala można dokonać za pomocą polecenia: exec-timeout <min> <s> wydanego w trybie konfiguracji linii VTY.

Czas ten domyślnie ustawiony jest na 10 minut i po braku aktywności ze strony użytkownika po tym czasie następuje automatyczne rozłączenie. Powyższy przykład ilustruje przestawienie tego czasu na 260 minutowy okres bezczynności.

Wydanie polecenia: exec-timeout 0 0 spowoduje wyłączenie mechanizmu odliczania czasu nieaktywności.

Oprócz czasu nieaktywności możemy również ustawić czas całkowitego trwania ustanowionego połączenia. Przykładowa konfiguracja czasu trwania połączenia może wyglądać tak:

Polecenie absolute-timeout <min> ustawia maksymalny czas trwania połączenia, natomiast logout-warning <s> czas wygenerowania ostrzeżenia (czas po, którym nastąpi zamknięcie sesji). W naszym przykładzie czas połączenia został ustawiony na 10 minut a 60 sekund przed zakończeniem połączenia zostanie wysłane ostrzeżenie.

Innym mechanizmem, który daje nam większe możliwości jest skorzystanie z systemu zarządzania nazwami użytkowników AAA (ang. Authentication Authorization Accounting). Narzędzia AAA wpierają najprostszą metodę uwierzytelnienia opartą na lokalnej bazie użytkowników zapisaną w konfiguracji routera po zaawansowane wsparcie dla protokołów RADIUS (ang. Remote Authentication Dial-In User Service), Kerberos czy TACACS+, dodatkowo skorzystanie z dobrodziejstw tego modelu powoduje, że możliwe jest zastosowanie różnych protokołów autentykacji dla różnych interfejsów routera.

Metoda korzystająca z lokalnego uwierzytelnienia użytkowników jest przeciwieństwem autentykacji opartej na odwołaniach do centralnego serwera (bądź serwerów – redundancja na wypadek niedostępności serwera) na którym to znajduje się wspólna baza użytkowników dostępna dla wszystkich urządzeń. Na podstawie informacji zawartych w tej bazie przeprowadza się uwierzytelnienie i nadanie uprawnień. Korzystanie z zdalnej bazy zwalnia nas z konfiguracji uwierzytelnienia na każdym z urządzeń z osobna.

Metoda lokalna sprawdza się w małych środowiskach natomiast korzystanie z odwołań zdalnych z reguły jest zarezerwowane dla dużych środowisk sieciowych.

Procedura konfiguracji uwierzytelniania bazującego na modelu AAA za pomocą CLI sprowadza się do:

1. Włączenia usługi AAA za pomocą polecenia: aaa new-model, komendę wydajemy w trybie konfiguracji globalnej.
2. Zdefiniowaniu listy metod uwierzytelnienia – polecenie: aaa authentication <rodzaj_uwierzytelnienia> default |<nazwa_listy> <metoda_uwierzytelnienia>

Pierwszą opcją, którą musimy określić jest podanie rodzaju uwierzytelnienia.

Po określeniu rodzaju uwierzytelnienia musimy zdecydować się czy użyjemy listy domyślnej, która jest automatycznie stosowana do wszystkich interfejsów. Jeżeli zdecydujemy się na zdefiniowanie nazwy listy, musimy pamiętać aby tą listę założyć na konkretny interfejs.

Ostatnią decyzją jest wybranie metody uwierzytelnienia. Co ważne, spośród podanych metod możemy wybrać ich kilka, a kolejność ich stosowania jest równoznaczna z kolejnością ich definicji.

3. Przypisanie (jeśli wymagane) zdefiniowanych list metod do konkretnych interfejsów lub linii.

A więc spróbujmy przeprowadzić konfigurację routera, który będzie korzystał z modelu AAA i model ten będzie odwoływał się do lokalnie utworzonej bazy danych o użytkownikach.

1. za pomocą polecenia: username <nazwa_użytkownika> password <hasło> tworzymy konto użytkownika.

Włączenie modelu AAA powoduje, zastąpienie domyślnego mechanizmu uwierzytelnienia i od tej pory router będzie żądał podania nazwy użytkownika i hasła na wszystkich liniach (VTY, AUX i port konsoli). Aby zabezpieczyć się i nie doprowadzić do sytuacji w której zablokujemy sobie dostęp do urządzenia poprzez włączenie modelu AAA i braku zdefiniowanego konta należy w pierwszej kolejności użyć polecenia username.

2. włączenie modelu AAA następuje poprzez wydanie polecenia: aaa new-model,
3. polecenie: aaa authentication login default local informuje router, że do procesu logowania ma użyć lokalnej bazy użytkowników zapisanej w pamięci routera,
4. opcjonalnie za pomocą parametru nopassword można zdefiniować użytkownika do którego nie będzie przypisane żadne hasło.

Po wpisaniu powyższych poleceń można nawiązać sesję Telnet. Użytkownik jankow aby się zalogować musi podać zarówno login i hasło natomiast użytkownik katwal tylko login.

Tak skonfigurowane konta są widoczne w pliku konfiguracji routera, informacja ta przechowywana jest w postaci niezaszyfrowanej.

Zaszyfrować hasła możemy dzięki znanemu nam już poleceniu: service password-encryption.

Aby skorzystać z algorytmu MD5 należy użyć polecenia: username <nazwa_użytkownika> secret <hasło>

Bardzo fajną możliwością jest nadanie konkretnemu użytkownikowi prawa do wykonania jakiegoś polecenia tak aby np. użytkownik uzyskał daną informację ale żeby nie mógł konfigurować urządzenia.

Cała procedura sprowadza się do wykorzystania polecenia autocommand, które to jest parametrem komendy username. Wydanie poniższych poleceń konfigurację usługi pozwoli wykonać.

1. danie użytkownikowi możliwość wykonania polecenia zarezerwowanego dla EXEC,
2. utworzenie użytkownika routing, konto nie ma hasła oraz dodanie parametru noescape spowoduje, że dany użytkownik nie może przerwać wykonania instrukcji,
3. dla użytkownika routing ma być wykonana komenda: show ip route.

Po nawiązaniu połączenia telnet nastąpi automatyczne pokazanie tablicy routingu routera.

Listę aktualnie zalogowanych użytkowników uzyskamy po wydaniu polecenia: show users.

Wcześniej wspomniałem, że można zdefiniować listę nazwaną oraz, że tak utworzoną listę trzeba jawnie przypisać do danego interfejsu. Jak to wykonać? Przedstawia poniższy listening.

1 – włączenie modelu AAA,

2 – stworzenie listy nazwanej Telnet-user, logowanie lokalne,

3 – konfiguracja linii VTY,

4 – przypisanie listy nazwanej Telnet-user do interfejsów wirtualnych,

5 – utworzenie użytkownika.

Podczas ustalania uwierzytelnienia została użyta opcja local-case, która oznacza, że nazwa użytkownika ma uwzględniać wielkość liter. Domyślnie nazwy są insensitive co oznacza, że nazwa użytkownika TadWal czy TADWAL jest tożsama. Jak można zaobserwować poniżej podczas próby nawiązania sesji Telnet z włączonym local-case tak już nie jest. Trzeba dokładnie podać nazwę użytkownika z uwzględnieniem wielkości liter.

Aby uniemożliwić wielokrotne logowanie się można zdefiniować próg po przekroczeniu, którego nastąpi automatyczna blokada konta. Służy do tego celu polecenie: aaa local authentication attempts max-fail <liczba_nieudanych_prób>

Maksymalna liczba błędnych logowań została ustalona na 3 (rysunek powyżej) po trzeciej próbie następuje blokada konta.

By zobaczyć aktualnie zablokowane konta wydaj polecenie: show aaa local user lockout

Aby konto ponownie stało się aktywne należy użyć komendy: clear aaa local user lockout username <nazwa_użytkownika> |all

Użytkownik TadWal może ponownie się zalogować.

Potrzeby wykonywania różnych czynności na routerze ściśle wiążą się z uprawnieniami do przeprowadzania danego typu konfiguracji (dostępu do różnych poleceń). Tak więc osoba odpowiedzialna za zabezpieczenia nie będzie potrzebowała poleceń, które związane są z routingiem i na odwrót. Routery Cisco umożliwiają konfigurację różnych poziomów uprawnień dla różnych grup administratorów. Dodatkowo aby kontrolować dostęp do danego poziomu uprawnień, należy skonfigurować hasło do każdego z poziomów.

Do dyspozycji mamy 16 poziomów uprawnień.

• Level 0:

– wstępnie zdefiniowany do przywilejów na poziomie trybu użytkownika (user-level access privileges),

– ze względu na to, że poziom ten udostępnia tylko pięć poleceń : disable, enable, exit, help, and logout rzadko stosowany.

• Level 1 (user EXEC mode):

– domyślnie ustawiany poziom logowania ze znakiem zachęty Router>,

– użytkownik nie może wykonać żadnych zmian konfiguracji plus brak możliwości podejrzenia pliku konfiguracji bieżącej.

• Levels 2 –14:

– poziomy, które mogą być dostosowane w zależności od potrzeb i wymagań,

– polecenia z niższego poziomu może być przeniesione do wyższego poziomu, a polecenia z wyższego poziomu mogą być przeniesione na niższy poziom,

– poziomy te mogą być skonfigurowane za pomocą poleceń konfiguracji globalnej.

• Level 15 (Privileged EXEC mode):

– najwyższe uprawnienia, możliwość uruchomienia trybu uprzywilejowanego – polecenie enable.

OK no to wykonajmy mały przykład.

• stworzono cztery odrębne konta użytkownika.
• konto user z domyślnym dostępem na poziomie 1.
• technik z dostępem na poziomie 5 i dostępem do polecenia ping.
• starszytechink z dostępem na poziomie konta technik plus dostęp do polecenia clock.
• admin – poziom trybu uprzywilejowanego.
• dodatkowo umożliwiono przejście na level 5 i level 10, przejście następuje po wpisaniu hasła.

Wszystkie wymienione powyżej zadania zostały zrealizowane za pomocą poniższych komend:

1 – konto user, dostęp do poziomu 1, hasło: poziom1, algorytm MD5,

2 – polecenie ping może być uruchomione z uprawnieniami poziomu 5,

3 – przejście na poziom 5 po podaniu hasła: poziom5,

4 – konto technik, dostęp do poziomu 5, hasło: poziom5, algorytm MD5,

5 – polecenie clock może być uruchomione z uprawnieniami poziomu 10,

6 – przejście na poziom 10 po podaniu hasła poziom10,

7 – konto starszytechnik, dostęp do poziomu 10, hasło: poziom10, algorytm MD5,

8 – konto admin, dostęp do poziomu 15, hasło: poziom15, algorytm MD5,

Po wydaniu tych wszystkich poleceń sprawdźmy czy konta zostały utworzone:

Jak widać wszystko wydaje się być OK a więc spróbujmy podłączyć się do routera z wykorzystaniem sesji telnet i sprawdzić czy wprowadzone ustawienia działają jak należy. Wykonujemy serię poleceń.

1 – nawiązanie sesji telnet z poświadczeniami użytkownika user,

2 – sprawdzenie poziomu użytkownika za pomocą polecenia: show privilege, poziom użytkownika user to level 1,

3 – sprawdzenie czy działa polecenie ping – polecenie nie działa,

4 – za pomocą polecenia: enable <poziom>, podwyższamy uprawnienia do level 5,

5 – hasło do level 5,

6 – sprawdzenie poziomu użytkownika,

7 – sprawdzenie czy działa polecenie ping – polecenie działa,

8 – sprawdzenie czy działa polecenie clock – polecenie nie działa,

9 – podwyższamy uprawnienia do level 10,

10 – hasło do level 10,

11 – sprawdzenie poziomu użytkownika,

12 – sprawdzenie czy działa polecenie clock – polecenie działa,

13 – sprawdzenie czy działa polecenie show running-config – polecenie nie działa,

Jak widać po powyższym briefingu wszystko działa jak należy z wyjątkiem ostatniego 13 polecenia. Stało się tak ponieważ polecenie: show running-config zarezerwowane jest dla najwyższego 15 poziomu.

Spróbujmy przejść na najwyższy poziom uprawnień. Jak widać wydanie polecenia: enable 15 kończy się niepowodzeniem. Niepowodzenie spowodowane jest tym, że konfigurując router nie daliśmy możliwości przejścia na ostatni 15 poziom.

A więc przejdźmy do routera i spróbujmy włączyć możliwość podwyższenia uprawnień do poziomu 15. Oczywiście można by było nawiązać kolejną sesję i zalogować się z poświadczeniami użytkownika admin.

Po wprowadzeniu korekty możliwe staje się podwyższenie uprawnień a co za tym idzie wydanie komendy: show running-config.

Mechanizm oparty o poziomy nie daje nam możliwości pełnego kontrolowania dostępu do poszczególnych poleceń a złożona konfiguracja bywa kłopotliwa a dodatkowo podlega on następującym ograniczeniom:

• brak możliwości ustalenia dostępu do określonych interfejsów, portów routera,
• polecenia dostępne na niższych poziomach są zawsze możliwe do wykonania na wyższych poziomach, natomiast te z poleceń, które zostały przypisane do wyższych poziomów uprawnień, nie są dostępne dla niższej uprzywilejowanych użytkowników,
• polecenie zawierające wiele słów kluczowych, które zostaje przeniesione na inny poziom sprawi, że wszystkie polecenia rozpoczynające się od pierwszego słowa również przechodzą na ten sam poziom,
• aby zdefiniować konto, które ma dostęp do większości poleceń, lecz z małymi wyjątkami (bez pewnych komend), wymaga od nas wydanie polecenia privilege exec dla każdego polecenia, które ma być dostępne na tworzonym koncie.

Innym sposobem określenia uprawnień w systemie jest skorzystanie z tzw. Role-Based CLI. Mechanizm ten ma większe możliwości i jest bardziej przyjazny niż poziomy uprawnień trybu enable. Dzieje się tak ponieważ definiowane poziomy i przypisywanie określonych praw dostępnych w ramach levelu nie zapewniają odpowiedniego poziomu szczegółowości, potrzebnego podczas pracy z systemem IOS.

Cała koncepcja Role-Based CLI opiera się na definiowaniu tzw. widoków (ang. views). Celem utworzenia widoku jest danie administratorowi możliwości zdefiniowania grupy poleceń, która będzie obowiązywać w ramach widoku. Czyli widok zapewnia nam selektywny lub częściowy dostęp do poleceń trybu konfiguracji oraz określa jakie informacje konfiguracyjne będą widoczne.

Cały proces konfiguracji Role-Based CLI rozpoczyna się od definicji widoku głównego (ang. Root View). Root view jest niezbędny do definiowania widoków i superwidoków (ang. superview). Jak już zostało wspomniane widok zawiera polecenia system IOS a co najważniejsze dane polecenie nie jest ograniczone do jednego widoku czyli komenda może pojawić się w więcej niż jednym widoku.

Widok główny jest najwyższym widokiem administracyjnym. W widoku tym następuje tworzenie i modyfikowanie pozostałych widoków bądź superwidoków. Porównując prawa dostępne w ramach 15-tego poziomu uprzywilejowania a prawa użytkownika widoku głównego to okażę, się że tylko użytkownik widoku głównego może tworzyć lub zmieniać widoki i superwidoki.

Aby móc skorzystać z Role-Based CLI wymagane jest włączenia modelu AAA (wykorzystanie lokalnego uwierzytelniania nie wystarcza).

Administrator ma do dyspozycji oprócz widoku głównego, dodatkowych 15 widoków.

Tak więc wykonajmy małe ćwiczenie i spróbujmy uruchomić Role-Based CLI.

1 – tworzymy nowego użytkownika,

2 – włączamy nowy model AAA, za pomocą polecenia aaa new-model

3 – następnie, za pomocą polecenia enable z parametrem view wchodzimy do widoku głównego (opcjonalnie enable view root). Jeśli uaktywnione jest uwierzytelnianie, korzystamy z hasła enable secret.

Aby wyświetlić informację o bieżącym widoku użyj polecenia: show parser view

Gdy jesteśmy już w widoku głównym możemy zdefiniować kolejne. A więc zdefiniujmy widok ROUTE w którym będzie dozwolone wykonanie poleceń z rodziny show ip oraz komendy show version.

4 – utworzenie widoku ROUTE i uruchomienie trybu konfiguracji widoku – polecenie: parser view <nazwa_widoku>,

5 – ustawienie hasła zabezpieczającego dostęp do widoku w naszym przypadku hasło to slow7 – polecenie: secret <hasło>.

6 – przypisanie poleceń do widoku – wszystkie polecenia z rodziny show ip oraz polecenie show version.

Od tej pory widok ROUTE jest aktywny spróbujmy więc skorzystać z niego. Przełączenie widoku realizujemy za pomocą polecenia: enable view <nazwa_widoku>.

Oczywiście by uaktywnić widok musimy podać hasło dostępu do widoku. Wydanie komendy show parser view zdradza nazwę aktywnego widoku.

Po uaktywnieniu widoku możemy sprawdzić z jakich poleceń możemy korzystać. Zgodnie z konfiguracją widoku oprócz poleceń zdefiniowanych odgórnie możemy wywołać tylko polecenie show version oraz każde z poleceń z rodziny show ip.

Wywołanie polecenia, które nie zostało zdefiniowane w konfiguracji danego widoku skutkuje informacją o błędzie. Gdy w widoku ROUTE chcemy przeprowadzić konfigurację urządzenia, poleceniem: config terminal, router zgłasza błąd.

Wcześniej do widoku ROUTE włączyliśmy wszystkie polecenia z rodziny show ip, jeśli z jakiegoś powodu chcemy część poleceń wykluczyć musimy użyć polecenie z parametrem exclude – commands exec exclude <nazwa_polecenia> Spróbujmy zablokować polecenie: show ip access-lists

Jak można zaobserwować poniżej ponowne uruchomienie widoku ROUTE i wywołanie wszystkich możliwych poleceń z rodziny show ip jest pozbawione komendy: access-lists.

Dodatkowo został nam udostępniony mechanizm tworzenia tzw. superwidoków (ang. superviews). Przy tworzeniu superwidoków trzeba pamiętać o następujących zasadach:

• Superwidoki zawierają poszczególne widoki, lecz nie zawierają poleceń, ponieważ polecenia są dodawane tylko do widoków,
• Dwa superwidoki mogą korzystać z tego samego Widoku, oznacza to, że zarówno superview #1 jak i superview #2, mogą obejmować widok #5,
• Użytkownicy, którzy zalogują się do danego superwidoku mają dostęp do wszystkich poleceń, skonfigurowanych w widokach tworzących dany superwidok,
• Każdy superwidok jest zabezpieczony hasłem, hasło jest używane do przełączania się między superwidokami oraz widokami,
• Skasowanie superwidoku nie powoduje usunięcia widoków powiązanych z tym superwidokiem.

Tworzenie superwidoku odbywa się poprzez dodanie słowa superview do polecenia parser view. Wydanie polecenia uruchamia tryb konfiguracji superwidoku.

Kolejnym krokiem jest utworzenie hasła, które zabezpieczy nam dostęp do superwidoku. Hasło musi zostać zdefiniowane po utworzeniu widoku, w przeciwnym razie pojawi się komunikat błędu. Hasło tworzymy za pomocą polecenia: secret <hasło>

Ostatnią czynnością jest zdefiniowanie widoków, które będą tworzyć superwidok. Dodanie widoku do superwidoku odbywa się za pomocą komendy: view <nazwa_widoku>

To tyle jeśli chodzi o cześć teoretyczną czas na mały przykład.

1 – tworzymy nowego użytkownika,

2 – włączamy model AAA,

3 – przechodzimy do widoku głównego – root,

4 – tworzymy widok SHOWVERSION,

5 – ustalamy hasło do widoku SHOWVERSION,

6 – przydzielamy polecenie show version do widoku,

7 – tworzymy widok PINGVIEW,

8 – ustalamy hasło do widoku PINGVIEW,

9 – przydzielamy polecenie ping do widoku,

10 – tworzymy widok SHOWROUTE,

11 – ustalamy hasło do widoku SHOWROUTE,

12 – przydzielamy polecenie show ip route do widoku,

13 – przydzielamy polecenie show ip interface brief do widoku.

Po wykonaniu wszystkich poleceń weryfikujemy czy wszystko zostało wykonane prawidłowo. Jak można zaobserwować poniżej wszystkie polecenia zostały przypisane do poszczególnych widoków prawidłowo. Dodatkowo, co również można zauważyć zmiana widoku wymusza na nas podanie hasła widoku.

Po utworzeniu trzech widoków: SHOWVERSION, PINGVIEW oraz SHOWROUTE spróbujmy stworzyć dwa superwidoki: USER oraz TECHNIK do których to przypiszemy widoki według schematu znajdującego się poniżej.

Jak widać naszym celem jest przypisanie widoku SHOWVERSION do superwidoku USER oraz przypisanie widoku SHOWROUTE do superwidoku TECHNIK przy czym widok PINGVIEW ma należeć do obydwu superwidoków.

Polecenia jakie należy wydać by osiągnąć nasz zamierzony cel znajdują się poniżej:

1 – włączenie widoku głównego (root),

2 – utworzenie superwidoku USER – polecenie: parser view <nazwa_superwidoku> superview,

3 – ustalenie hasła do superwidoku USER – polecenie: secret <hasło>,

4 – dodanie widoku SHOWVERSION do superwidoku USER polecenie: view <nazwa_widoku>,

5 – próba dodania widoku SHOWPING do superwidoku USER – jak widać próba zakończona niepowodzeniem z powodu braku zdefiniowania widoku o takiej nazwie,

6 – dodanie widoku PINGVIEW do superwidoku USER,

7 – utworzenie superwidoku TECHNIK,

8 – próba dodanie widoku PINGVIEW do superwidoku TECHNIK, próba zakończona niepowodzenie z powodu braku zdefiniowanego hasła do superwidoku,

9 – ustalenie hasła do superwidoku TECHNIK,

10 – dodanie widoku PINGVIEW do superwidoku TECHNIK,

11 – dodanie widoku SHOWROUTE do superwidoku TECHNIK.

Ostatnią czynnością jaka nam pozostała to przypisanie widoku/superwidoku do konkretnych użytkowników dlatego skonfigurujmy dwa dodatkowe konta.

1 – utworzenie konta agaban z hasłem cisco123 i przypisanie do konta widoku PINGVIEW,

2 – utworzenie konta katwal z hasłem cisco123 i przypisanie do konta superwidoku TECHNIK.

No to przetestujmy konfigurację i spróbujmy się zalogować na nowo utworzone konta. Jak widać poniżej widok PINGVIEW został skojarzony z kontem agaban.

No to pozostaje nam jeszcze sprawdzić konto katwal.

I tu wszystko ustawione jest prawidłowo.

Gdyby przypadkiem okazało się, że logując się na podane konto widok nie jest przypisany do danego konta sprawdź czy zostało wydane polecenie: aaa authorization exec default local Polecenie wymusza dostęp do danych poleceń na podstawie lokalnie zdefiniowanych ustawień.

Bezpieczną komunikację z routerem zapewnia usługa SSH. Zaimplementowanie funkcji pozwoli nawiązać bezpieczne połączenie z routerem – przechwycona sesja jak to miało miejsce w przypadku protokołu Telnet już nie zdradzi haseł, przebiegu przeprowadzonych czynności czy użytych komend. Użycie szyfrowania gwarantuje bezpieczeństwo połączenia a sesja nawet przechwycona jest nieczytelna.

Usługa szyfrowania korzystająca z SSH udostępniana jest w routerach Cisco od wersji 12.1(1)T systemu IOS i w tych urządzeniach, które zawierają moduły IPSec (DES czy 3DES).

Konfiguracja usługi SSH wymusza przeprowadzenie dodatkowych czynności związanych z konfiguracją routera:

• opisane już powyżej dwa warunki czyli sprawdzenie czy system IOS odpowiada wymaganiom usługi SSH – wersja systemu + moduł IPSec (DES czy 3DES),
• skonfigurowanie domeny za pomocą polecenia: ip domain-name,
• nazwa routera musi być inna niż domyślna – Router,
• skorzystanie z mechanizmu wymuszającego podanie nazwy użytkownika i hasła czyli możemy skorzystać z opisanego wyżej modelu AAA i np. lokalnej bazy użytkowników,
• wygenerowanie kluczy RSA, które będą użyte do zestawienia połączenia SSH. Długość kluczy może wahać się od 360 do 2048 bitów. Obowiązuje zasada: im dłuży klucz – większe bezpieczeństwo lecz dłuższy klucz to mniejsza wydajność całego systemu. Wartość, którą uznaje się za optymalną to 1024 bity (złoty środek pomiędzy wydajnością a bezpieczeństwem). Generowanie kluczy odbywa się za pomocą polecenia: crypto key generate rsa (wydanie polecenia automatycznie uaktywnia protokół SSH) natomiast ich usunięcie odbywa się za pomocą komendy: crypto key zeroize rsa.

Po tym krótkim teoretycznym wstępie spróbujmy wykonać konkretny przykład i dać użytkownikowi dostęp do linii poleceń routera lecz z wykorzystaniem połączenia SSH. Konfigurowany będzie router R3 a następnie będziemy próbować połączyć się z routerem z komputera Windows 10.

Konfiguracja routera może być wykonana tak jak poniżej:

1 – konfiguracja domeny,

2 – generowanie kluczy,

3 – utworzenie użytkownika i hasła,

4 – włączenie logowania,

5 – konfiguracja linii VTY do przeniesienia ruchu SSH.

Po konfiguracji przyszedł czas sprawdzić czy uda nam się zestawić połączenie. Do nawiązania połączenia użyjemy darmowej aplikacji PuTTY. Aplikacja jak już wspomniałem będzie uruchamiana na komputerze Windows 10. Konfiguracja programu sprowadza się do podania adresu IP urządzenia, z którym chcemy się połączyć oraz do wybrania rodzaju połączenia (w naszym scenariuszu SSH), wykorzystywany port to port TCP o numerze 22.

Jeżeli istnieje potrzeba ustalenia szczegółowych opcji np. wersja protokołu SSH to można tego dokonać w sekcji SSH.

Po wprowadzeniu danych konfiguracyjnych następuje próba nawiązania połączenia. Pierwsze połączenie wymaga od nas potwierdzenie klucza urządzenia, który zostanie użyty do zaszyfrowania sesji.

Kliknięcie na Tak otwiera sesję. Dostęp do opcji konfiguracji routera uzyskamy po podaniu skonfigurowanych poświadczeń.

Innym programem mogącym posłużyć do ustanowienia sesji SSH jest Tera Term. Aplikacja ta również jest darmowa.

Aby zestawić sesje podajemy te same dane, które użyliśmy w przypadku konfiguracji PuTTy.

I również podobnie jak to miało miejsce wcześniej musimy zaakceptować klucz.

Po akceptacji klucza ostatnią opcją jest podanie danych, które uwierzytelnią użytkownika.

Jeśli wszystko podaliśmy poprawnie następuje dostęp do wiersza poleceń routera.

Czemu warto skonfigurować połączenie SSH? Na to pytanie już na pewno czytelniku sam poprawnie jesteś w stanie odpowiedzieć. Dzięki połączeniu SSH zyskujemy pewność, że osoba która będzie monitorować ruch sieciowy nie będzie w stanie odczytać treści konwersacji jak to było w przypadku sesji Telnet. Poniżej przykład przechwyconej sesji SSH (notabene część informacji jest jawna m.in. użyty klient czy wersja protokołu SSH).

Dodatkowe opcje dotyczące połączenia SSH (rysunek poniżej) jakie możemy skonfigurować to:

1. użyta wersja protokołu SSH – polecenie: ip ssh version <wersja_protokołu>

Cisco IOS Release 12.1(1)T i późniejsze wspierają SSHv1 natomiast IOS Release 12.3(4)T i późniejsze wspierają SSHv1 oraz SSHv2 (tryb zgodności).

2. liczba nieudanych prób uwierzytelniania – polecenie: ip ssh authentication-retries <liczba_prób>

Domyślnie ustawienie to 3 próby logowania.

3. czas ustanowienia połączenia (ang. SSH Timeouts) – polecenie: ip ssh time-out <czas_sekundy>

Domyślny przedział czasu, przez który router będzie czekać na odpowiedź klienta SSH podczas fazy negocjacji wynosi 120 sekund.

Możliwe jest również wykonanie połączenia SSH bezpośrednio z konsoli drugiego routera. Spróbujmy nawiązać połączenie z routera R2.

Polecenie, które możemy użyć do sprawdzenia czy jest nawiązane jakiekolwiek połączenie szyfrowane z urządzeniem to: show ssh. Jak widać poniżej na routerze R3 nie ma żadnych aktywnych połączeń.

Za pomocą polecenia: ssh (wraz z odpowiednimi parametrami) wydanym na routerze R2 ustanowimy bezpieczne połączenie z routerem R3. Parametry polecenia ssh są następujące:

Chcąc połączyć się z hostem zdalnym użyjemy przełącznika –l po którym podajemy nazwę użytkownika oraz przełącznika –v do określenia wersji protokołu SSH no i oczywiście nie możemy zapomnieć o podaniu adresu IP hosta zdalnego.

Ponowne wydanie polecenia: show ssh (router R3), uwidacznia aktywną sesję, ukazane są również podstawowe informacje o zestawionym połączeniu.

Po skonfigurowaniu bezpiecznego połączenia dobrą praktyką jest wyłączenie pozostałych metod. Sens wdrożenia SSH podważa zostawienie możliwości uzyskania komunikacji np. poprzez sesję Telnet. Poniżej zebrano wszystkie dostępne protokoły linii VTY:

• all – obsługa wszystkich protokołów,
• lat – połączenia realizowane za pomocą protokołu LAT (ang. Local Area Terminal),
• mop – obsługa połączeńz wykorzystaniem protokołu MOP (ang. Maintenance Operation Protocol),
• nasi – wykorzystanie interfejsu serwerów dostępowych NetWare (ang. NetWare Access Servers Interface),
• none – brak możliwości skorzystanie z linii VTY, wyłączenie wszystkich protokołów,
• pad – połączenia X.3 PAD (ang. Public Access Defibrillation),
• rlogin – zablokowanie protokołu rlogin wykorzystywanego w systemach z rodziny UNIX,
• ssh – protokół SSH,
• telnet – połączenia typu Telnet,
• v120 – obsługa protokołu V.120.

Wyłączenie wszystkich możliwych opcji następuje za pomocą polecenia: transport input none (komendę wydajemy w trybie konfiguracji linii VTY) kolejny krok to włączenie tylko tych pożądanych.

Jak widać poniżej po wydaniu komendy niemożliwe staje się zestawienia połączenia za pomocą klienta SSH (polecenie wydane na routerze R2).

Dopiero zezwolenie na ruch typu SSH pozwoli nam uzyskać połączenie.

Próba nawiązania połączenia z wykorzystaniem klienta Telnet z komputera Windows 10, kończy się niepowodzeniem.

Sprawdzenie protokołów dopuszczonych do korzystania z liniami VTY odbywa się za pomocą polecenia show terminal.

Dodatkowo zwiększenie bezpieczeństwa połączeń wirtualnych może być zrealizowane za pomocą:

• zmiana opóźnień pomiędzy kolejnymi próbami logowania,
• uaktywnienie trybu Quiet-Mode, który spowoduje włączenie blokady logowania do systemu, jeśli podejrzewany jest atak DoS.
• włączenie logów informujących o wystąpieniu procesu logowania.

Przykładowa konfiguracja (choć można wykonać bardziej złożoną z wykorzystaniem mechanizmu ACL) mogła by wyglądać tak:

1 – utworzenie użytkownika tadwal z hasłem MD5 – tajnehaslo,

2 – konfiguracja linii VTY – logowanie,

3 – włączenie blokowania w naszym przykładzie jeśli w ciągu 30 sekund wystąpi więcej niż 5 nieudanych prób logowania,  logowanie zostanie wyłączone na 90 sekund – polecenie: login block-for <czas_blokady> attempts <liczba_prób> within <czas_logowania>,

4 – minimalne opóźnienie pomiędzy próbami logowań ustawione na 5 sekund – polecenie: login delay <czas>,

5 – log w razie wystąpienia poprawnego zalogowania – polecenie: login on-success log,

6 – log w razie wystąpienia błędnego logowania – polecenie: login on-failure log.

Przetestujmy przeprowadzoną konfigurację. Wydanie polecenia: show login poinformuje, że router jest skonfigurowany do odpierania ataków opartych na zgadywaniu danych logowania, i że aktualnie pracuje normalnie.

Następuje atak na hasło użytkownika jankow, atakujący w czasie mniejszym niż 30 sekund sześciokrotnie wpisuje hasło użytkownika.

Przeprowadzona próba ataku wymusza na routerze R3 przejście w tryb Quiet-Mode

a tym samy przez okres 90 sekund następuje blokowanie wszelkich prób logowania.

Informacja o nieudanej próbie logowania oraz przejściu w tryb Quiet Mode jest wyświetlana w linii interfejsu CLI routera.

Również udane logowanie jest potwierdzone odpowiednim komunikatem.

Wydanie polecenia: show login failures wyświetla informacje o nieudanych próbach logowania, po wydaniu polecenia otrzymujemy informację o:

1 – użytkowniku (informacja ta nie jest pokazywana w przypadku sesji SSH),

2 – adresie źródłowym, z którego próbowano nawiązać połączenie,

3 – użytym porcie,

4 – liczbie nieudanych prób,

5 – czasie wystąpienia błędu.

Opisaliśmy już dostęp do routera za pomocą modelu AAA bazującym na lokalnej bazie użytkowników a więc spróbujmy skonfigurować router w taki sposób aby łączył się z zdalnym serwerem, na którym zapisano dane uwierzytelniające i na podstawie informacji uzyskanych od serwera następowała odmowa bądź udzielenie dostępu.

Do wykonania tego zadania wykorzystamy serwer RADIUS, który będzie uruchomiony na komputerze Windows 10. Serwer RADIUS będzie symulowała aplikacja WinRadius.

Aplikacja nie wymaga instalacji, po uruchomieniu programu musimy skonfigurować bazę w której będą zapisywane informacje o kontach (w przypadku braku uruchomienia klikamy Settings a następnie Database). Najlepiej w tym celu kliknąć Configure ODBC automatically wszystkie opcje odnoszące się do bazy powinny zostać skonfigurowane automatycznie (pamiętaj, że program musi być uruchomiony jako administrator), po ponownym uruchomieniu programu będziemy mogli dodać konta użytkowników.

Jeżeli wystąpią problemy z bazą rozwiążesz je wybierając Narzędzia administracyjne a następnie Źródła danych (ODBC).

Dodawanie użytkowników odbywa się poprzez wybranie Operation a następnie Add user. W nowo otwartym oknie wpisujemy nazwę użytkownika i hasło – w naszym przypadku jankow i hasło: cisco

W spakowanym archiwum znajduje się narzędzie, który pozwoli zweryfikować czy nowo utworzone konto działa. Uruchom aplikację RadiusTest i wprowadź poświadczenia nowo utworzonego użytkownika i kliknij Send. Jeżeli wszystko wykonałeś poprawnie w głównym oknie programu powinien pojawić się log informujący o tym, że konto jest aktywne. W razie wystąpienia problemów zainteresuj się ustawieniami firewalla.

Po skonfigurowaniu serwera RADIUS przyszedł czas aby skonfigurować router. Całość ustawień wykonamy na routerze R3.

Konfiguracja urządzenia sprowadza się do wykonania następujących czynności:

1 – utworzenie konta – ale zaraz, zaraz przecież konta mają się znajdować na serwerze RADIUS a nie na routerze – zwróci uwagę uważny czytający. Po co to dodatkowe konto? Daj mi chwilę czytelniku a zaraz wszystko będzie jasne.

2 – włączenia modelu AAA ,

3 – zdefiniowania sposobu autentykacji, do tego celu wykorzystamy polecenie: aaa authentication login default <metoda_1> <metoda_2> Czyli w naszym scenariuszu polecenie to przyjmie postać: aaa authentication login default group radius local Czyli od tej pory za logowanie będzie odpowiadał serwer RADIUS a w razie wystąpienia problemów (np. niedostępność serwera) logowanie ma odbyć się na podstawie lokalnej bazy użytkowników.

4 – ostatnim krokiem jest podanie adresu IP serwera RADIUS wraz z kluczem, który jest używany do szyfrowania komunikacji pomiędzy klientem a serwerem. Oczywiście klucz musi być tożsamy z kluczem zapisanym na serwerze. Do określenia tych opcji posłuży nam polecenie: radius-server host <adres_ip> key <hasło> – komenda przyjmie postać: radius-server host 172.16.1.10 key WinRadius W celu zapewnienia dostępności usług można podać więcej niż jeden adres IP serwera RADIUS.

Aby zmienić domyślny klucz używany do zabezpieczenia przesyłanych informacji w aplikacji wybierz Settings a następnie System.

Po skonfigurowaniu serwera i routera przyszedł czas by przetestować wprowadzone ustawienia. W tym celu spróbujmy zalogować się do urządzenia. Jak widać poniżej proces logowania nie powiódł się, serwer zwrócił informację Authentication failed (uważny czytelnik już pewnie wie gdzie tkwi błąd – ale po kolei).

I tu dochodzimy do odpowiedzi – Po co nam było te dodatkowe konto? Właśnie na wypadek gdyby coś poszło nie tak. Gdybyśmy nie założyli konta lokalnego admin stracilibyśmy możliwość naprawienia naszej pomyłki a dostęp do urządzenia byłby nie możliwy (dla ścisłości akurat w tej sytuacji dosyć prosto dałoby się jeszcze odkręcić całą sytuację). Wykonujemy logowanie za pomocą poświadczeń, które są zapisane w pamięci routera. Logowanie jest możliwe dzięki zdefiniowaniu drugiego sposobu – gdy serwer RADIUS jest niedostępny zaloguj na podstawie danych zapisanych lokalnie. Jak widać poniżej proces logowania zakończył się sukcesem.

Przyjrzyjmy się konfiguracji routera. Jak można zauważyć prócz adresu serwera RADIUS i klucza zostały zdefiniowane dwa porty a mianowicie: auth-port 1645 i acct port 1646. Przyjęta wartość portów to ustawienia domyślne. Cały problem z komunikacją to wynik ustawień routera – router ma zdefiniowane inne wartości portów niż serwer (trzeci screen powyżej – serwer ma ustawione wartości: auth-port 1812 i acct port 1813). Aby naprawić problem korygujemy ustawienia na routerze bądź serwerze.

Aby wykonać poprawkę musimy usunąć bieżącą konfigurację, wydajemy komendę: no radius-server host 172.16.1.10 auth-port 1645  acct port 1646 key WinRadius

Za pomocą polecenia: radius-server host 172.16.1.10 auth-port 1812 acct port 1813 key WinRadius wprowadzamy nowe ustawienia. Od tej pory do komunikacji z serwerem RADIUS zostaną użyte zdefiniowane przez nas porty.

Drugim sposobem wyjścia z naszego problemu jest zmiana ustawień portów na serwerze RADIUS. By wykonać tą operację korzystamy z karty System settings dostępnej po wybraniu z menu opcji Settings. Porty ustawiamy jak na rysunku poniżej:

Po skorygowaniu ustawień (niezależnie od wybranego sposobu) spróbujmy się zalogować, jak widać w logach WinRadius-a tym razem proces przebiegł prawidłowo.

Aby wyświetlić aktualnie zalogowanych użytkowników możemy posłużyć się poleceniem: show aaa session Poniżej przykład sesji podczas, której musieliśmy się zalogować lokalnie, po nie udanej próbie związanej z błędnym przypisaniem portów. Pole IP Address ustawione na 0.0.0.0 informuje, że jest to logowanie wykonywane bezpośrednio na urządzeniu z wykorzystaniem portu CONSOLE.

W przypadku logowania zdalnego uzyskamy informację o adresie IP urządzenia z którego nastąpiło połączenie.

Aby zobaczyć bardziej szczegółowe informacje możemy posłużyć się poleceniem: show aaa user <unique_id> Numer unique id zdobędziesz wywołując polecenie: show aaa session (rysunek powyżej). W polu Authen mamy informację dotyczącą logowania, jak można było się spodziewać jest to logowanie z wykorzystaniem lokalnej bazy o użytkownikach (method=LOCAL) wykonane po próbie wykorzystania serwera RADIUS (Fallover-from=RADIUS)

I jeszcze jeden przykład – tym razem również logowanie ale dostęp został uzyskany dzięki serwerowi RADIUS.

Oczywiście na serwerze RADIUS może być założonych wiele kont. Każda próba odwołania się do serwera jest rejestrowana w logu serwera.

W przypadku wystąpienia problemów możemy włączyć proces debugowania, który będzie odnosił się do modelu AAA. Służy temu szereg poleceń:

Jednym z bardziej użytecznych poleceń jest debug aaa authentication. Wydanie komendy dostarczy szeregu informacji mających związek z procesem autentykacji. Poniżej przykład, w którym użytkownik tadwal próbuje uzyskać dostęp do urządzenia. Pierwsza próba kończy się nie powodzeniem (błędne hasło) natomiast druga sukcesem.

Użytkownik po zalogowaniu znajduje się w trybie użytkownika. Hasło do trybu uprzywilejowanego może być zapisane w pamięci routera ale również dostęp do tego trybu może być realizowany dzięki serwerowi RADIUS. By kontrolować proces dostępu do tego trybu ale z wykorzystaniem zdalnego serwera wydaj polecenie jak poniżej (komenda uwzględnia sytuacje, w której z powodu niedostępności serwera trzeba by było skorzystać z hasła zapisanego w pamięci urządzenia  – metoda pierwsza wykorzystująca serwer RADIUS: group radius, metoda druga korzysta z standardowego hasła: enable)

Aby serwer RADIUS mógł rozliczać dostęp do trybu uprzywilejowanego trzeba na serwerze założyć konto o nazwie $enab15$ lub $enable$ (nazwa konta zależy od modelu urządzenia oraz wersji systemu IOS).  Poniżej część logu serwera RADIUS – id 21 – dostęp niemożliwy z powodu braku konta; id 22 – założenie konta $enab15$, id 23 – dostęp do trybu enable uzyskany.

Poniżej również zrzut informacji uzyskanych dzięki poleceniu: debug aaa authentication, dostęp do trybu uprzywilejowanego uzyskał użytkownik tadwal łącząc się z routerem z adresu IP 10.0.0.5.

Wykorzystanie serwera RADIUS jest mniej bezpieczną metodą niż skorzystanie z rozwiązania TACAS+. Jest tak ponieważ dane wymieniane pomiędzy serwerem a urządzeniem nie są w pełni szyfrowane. Jak można zaobserwować poniżej login jest przesyłany tekstem otwartym, szyfrowane jest jedynie hasło. Tak więc gdy przechwycimy komunikację mamy połowę roboty z głowy ponieważ pozostaje nam tylko złamanie hasła.

Aby odczytać hasło danego użytkownika musimy w pierwszej kolejności poznać klucz, jaki został użyty do zabezpieczenia połączenia z serwerem RADIUS. Do odczytania hasła użyjemy narzędzia Cain & Abel.

Po wczytaniu przechwyconej transmisji do narzędzia Cain, przechodzimy do sekcji Sniffer i u dołu ekranu wybieramy zakładkę Passwords.  W oknie po lewej stronie w części Radius-Keys oraz Radius-users zostało zaimportowanych 10 kluczy.

Przechwycone klucze z sekcji Radius-Keys po zaznaczeniu wysyłamy do programu łamiącego hasło. W tym celu klikamy PPM i z rozwijanego menu wybieramy Send to Cracker.

By zacząć proces łamania hasła serwera RADIUS klikamy na kartę Cracker i po lewej stronie wybieramy sekcje Radius Shared-Keys. Do wyboru mamy dwa typy ataków: atak brute-force oraz atak z wykorzystaniem słownika – dictionary attack.

W przypadku wybrania ataku słownikowego w pierwszej kolejności musimy wskazać słowniki, które będą użyte do łamania hasła oraz określić dodatkowe opcje związane z podstawianiem kolejnych wyrazów np. użyj duże litery, użyj małe litery, użyj małe i duże litery itd.

W przypadku brute-force attack, określamy minimalną liczbę znaków z których ma się składać hasło oraz maksymalną liczbę znaków. Ostatnią czynnością przed uruchomieniem procesu szukania hasła jest określenie zbioru znaków, które będą użyte do tego procesu.

W naszym scenariuszu wybrałem metodę słownikową z zaznaczonymi opcjami jak poniżej, cały proces szukania hasła trwał 12 minut. Hasło, które użyto do konfiguracji serwera RADIUS to WinRadius (hasło domyślne).

Gdy już znamy hasło zabezpieczające transmisje klient-serwer RADIUS, czas by uzyskać hasło użytkownika. W tym celu przechodzimy do znanej już nam zakładki Passwords (sekcja Sniffer) i z gałęzi po lewej wybieramy Radius-User. Cały proces sprowadza się do kliknięcia na danym użytkowniku i wybraniu opcji Decode w nowo otwartym oknie wpisujemy hasło zdobyte w poprzednim kroku czyli WinRadius. Hasło użytkownika jankow to cisco.

Jak widać możliwe jest uzyskanie hasła użytkownika nawet w konfiguracji z serwerem RADIUS, lecz w prawdziwym środowisku nie jest to takie łatwe, gdyż aby tego dokonać trzeba przechwycić odpowiedni typ transmisji. Znaczniej bezpieczniej do celów autoryzacji zamiast serwera RADIUS użyć TACAS+ ale opis przykładowej konfiguracji to już odrębny temat na kolejny wpis.

Routery CISCO, tak jak urządzenia SOHO można konfigurować poprzez interfejs WWW

Całość ustawień przebiega z wykorzystaniem przeglądarki internetowej. Aby móc połączyć się z routerem wykorzystując protokół HTTP w pierwszej kolejności należy skonfigurować samo urządzenie np. tak jak poniżej:

1 – tworzymy użytkownika z maksymalnym 15 poziomem uprawnień,

2 – uruchamiamy serwer HTTP – ip http server

3 – ustawiamy logowanie na podstawie lokalnej bazy użytkowników – ip http authentication local

Po przeprowadzeniu powyższych operacji możemy uruchomić przeglądarkę w której wpisujemy adres IP routera. Jeżeli wszystko wykonaliśmy prawidłowo zostaniemy poproszeni o dane uwierzytelniające.

Po wpisaniu poprawnego loginu i hasła uzyskamy dostęp do urządzenia i będziemy mogli dzięki interfejsowi www przeprowadzić konfigurację samego urządzenia.

Używanie poszczególnych komend sprowadza się do wybierania ich poprzez klikanie na poszczególne linki oraz czasem musimy wprowadzić odpowiednie dane sami – np. przy konfiguracji interfejsu adres IP.

Jak wiadomo protokół HTTP nie należy do najbezpieczniejszych ponieważ wszystkie dane przesyłane tym protokołem są przekazywane otwartym tekstem. Poniżej zrzut przechwyconego pakietu – jak widać login i hasło można odczytać bez problemu.

Aby zabezpieczyć kanał transmisji należy użyć szyfrowania – rozpoczynamy od wydania polecenia: ip http secure-server po którym to zostaną wygenerowane klucze RSA (podobnie jak to miało miejsce w przypadku konfiguracji połączenia SSH), które posłużą do zabezpieczenia transmisji. Protokołem odpowiedzialny za łączność zostaje HTTPS.

Po skonfigurowaniu urządzenia, aby nawiązać połączenie z routerem w pasku adresu przeglądarki należy odwołać się do protokołu HTTPS. Podczas ustanawiania połączenia musimy zaakceptować certyfikat routera.

Po akceptacji i wprowadzeniu danych uwierzytelniających możemy rozpocząć konfigurację routera.

Przechwycona transmisja nie zdradzi danych, których użyliśmy do nawiązania połączenia, jak widać poniżej dane te zostały zaszyfrowane.

Istnieje jeszcze jedna metoda pozwalająca na szybką i sprawną konfigurację urządzeń CISCO (bez znajomości składni poleceń). A mianowicie można posłużyć się dedykowanym do tego celu programem Cisco Configuration Professional. Narzędzie dzięki użyciu interfejsu graficznego pozwala na zmianę ustawień routera. Warto mieć na uwadze, że nie wszystkie opcje konfiguracji przeprowadzimy z wykorzystaniem aplikacji CCP co bardziej złożone operacje nadal trzeba przeprowadzić z wykorzystaniem CLI. Pomimo wielu zalet wiersza poleceń są mechanizmy, które znacznie łatwiej skonfigurować właśnie przy użyciu programu – ten, kto wykorzystuje listy ACL bądź Zone-based Firewall wie ile z funkcjami tymi jest kłopotu i jak łatwo o błąd. Użycie aplikacji i wbudowanych kreatorów jest sporym ułatwieniem.

Profesjonalne usługi informatyczne dla firm. W swojej ofercie posiadamy Outsourcing IT, certyfikaty SSL, szkolenia informatyczne oraz audyty bezpieczeństwa.

Zadzwoń i dowiedz się więcej, tel. 68 411 40 00.

Usługi informatyczne

Po pobraniu, zainstalowaniu (do działania aplikacji niezbędna jest JAVA) oraz uruchomieniu programu (tryb administratora) program przywita nas oknem Select/Manage Community w którym należy podać: adres IP urządzenia, poświadczenia oraz określić tryb komunikacji (czy korzystamy z szyfrowania). Następnie po wpisaniu powyższych opcji klikamy na OK.

Po zamknięciu okna z listy wybieramy interesujące nas urządzenie i klikamy na Discover.

W przypadku komunikacji odznaczonej jako Secure przed połączniem z urządzeniem będziemy musieli zaakceptować certyfikat.

Po nawiązaniu połączenia (a także jego braku) po kliknięciu na Discovery Details możemy zobaczyć status połączenia.

Po nawiązaniu poprawnego połączenia i po kliknięciu na Configure możemy rozpocząć konfigurację urządzenia. Wszystkie niezbędne wpisy na podstawie, których nowe ustawienia zaczną obowiązywać są generowane na bieżąco a po skończeniu konfiguracji są przekazywane (celem zastosowania) do urządzenia.

W tym miejscu artykuł chciałbym zakończyć; krótkie wprowadzenie do CCP miało pokazać, że oprócz wiersza poleceń istnieją alternatywne metody konfiguracji urządzeń z logo CISCO a opis samego programu to już temat na kolejny (obszerny) wpis.

Nazywam się Rafał Wielgus, jestem informatykiem oraz międzynarodowym audytorem wiodącym ISO 27001. Świadczę kompleksowe usługi z zakresu bezpieczeństwa teleinformatycznego, wdrażam systemy z rodziny „IT security”, skutecznie nadzoruję RODO, prowadzę szkolenia oraz audyty.

Posiadam prawie 20 lat doświadczenia w bezpieczeństwie systemów i sieci komputerowych. Jako jeden z nielicznych w Polsce dysponuję wiedzą praktyczną w zakresie Certified Information Systems Security Professional (CISSP). Szkolony również przez ABW i SKW.

Usługi informatyczne