W przypadku routerów i przełączników Cisco proces dostępu do urządzenia możemy zrealizować na wiele sposobów. Możemy wyróżnić następujące metody:

• • • password – metoda oparta na podaniu tylko hasła, dostęp do trybu użytkownika oraz do trybu uprzywilejowanego oparty jest na haśle,
    • local database – metoda oparta na zdefiniowaniu bazy uprawnionych użytkowników, baza jest zapisana w pamięci urządzenia. W przeciwieństwie do metody opartej na haśle tu musimy podać nazwę użytkownika i hasło. Wadą tego sposobu jest to, że lokalna baza danych zawierająca loginy i hasła musi być powielona na wielu urządzeniach.
    • 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ć by 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 by 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 WindowsXP. 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. Dostajemy informację o potrzebie wprowadzenia hasła lecz hasło nie zostało 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 nam się nawiązać połączenie. Wydajmy ponownie polecenie: telnet 172.16.1.1 Jak widać poniżej udało nam się nawiązać sesje telnet z urządzeniem. Sesja zostaje nawiązana 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 jak zapewne wiesz czytelniku pozwala nam na zmianę trybu na tryb uprzywilejowany otrzymujemy komunikat o braku hasła. Hasło do trybu uprzywilejowanego jest dodatkowym zabezpieczeniem (druga linia obrony), które chroni router przed wprowadzeniem niepożądanych zmian w konfiguracji urządzenia.

Dajmy użytkownikowi podłączonemu zdalnie możliwość przejścia w tryb uprzywilejowany. Poleceniem umożliwiającym poprawne wywołanie komendy enable jest: 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.

Jak już nie raz wspominałem sesja 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.

Dodatkowym osłabieniem tak wykonanej konfiguracji jest przechowywanie haseł w formie czystego tekstu w pliku konfiguracji routera. Wydanie komendy show running-config uwidacznia skonfigurowane hasła.

By zabezpieczyć hasła i przynajmniej trochę utrudnić ich odczytanie możemy użyć usługi, która jest odpowiedzialna 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 (oznaczenie siódemka – 7 za słowem password) nie należy do najbezpieczniejszych bo tak naprawdę szyfrowanie te opiera się na metodzie Vigenere i jest łatwe do odwrócenia.

Można np. skorzystać z tej strony: http://www.ibeast.com/content/tools/CiscoPassword/index.asp

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

Tak prosta metoda uzyskania hasła spowodowała, wprowadzenie mechanizmu, gwarantującego lepszą ochronę przechowywanych 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 celem ukrycia hasła zastosowano funkcję MD5 (oznaczenie cyfra 5 po słowie secret).

Aktualnie mamy zdefiniowane dwa hasła które pozwalają nam przejście do trybu uprzywilejowanego.

Celem zwiększenia ochrony decydujemy się na usunięcie hasła zdefiniowanego za pomocą komendy enable password <hasło>. Usunięcie hasła 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 dokonujemy 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 poza kolejnością czyli np. utworzenie linii 14 spowoduje dodanie linii od 0 do 14 natomiast usunięci linii do np. 7 będzie powodowało wykasowaniem portów 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 natomiast 60 sekund przed zakończeniem połączenia zostanie wysłane ostrzeżenie.

Zanim przejdziemy do modelu AAA należałoby wspomnieć o jeszcze jednej metodzie zresztą też używanej przy wspomnianym już modelu AAA a mianowicie weryfikacji użytkownika na podstawie informacji zapisanej w lokalnej bazie urządzenia. Metoda jest bardzo prosta wystarczy skorzystać z polecenia: username <użytkownik> secret <hasło>.

Po utworzeniu konta użytkownika by móc połączyć się z routerem np. z wykorzystaniem linii wirtualnych VTY trzeba linie te skonfigurować by dostęp za ich pośrednictwem do urządzenia opierał się na weryfikacji użytkownika na podstawie danych zawartych w bazie urządzenia. W tym celu przechodzimy do konfiguracji linii VTY i wydajemy polecenie: login local

 Po skonfigurowaniu dostępu zostaje przeprowadzona próba połączenia się z routerem R3, klientem jest router R2.

Jak widaćpróba kończy się sukcesem.

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 przeprowadzane jest uwierzytelnienie i nadanie uprawnień. Korzystanie z zdalnej bazy zwalnia nas z konfiguracji bazy 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 możemy wybrać kilka metod spośród podanych, metody będą przeprowadzona w takiej kolejności, w jakiej je zdefiniujemy.

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. dodatkowo 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 otworzyć sesję telnet jak widać poniżej w przypadku użytkownika jankow trzeba było podać login i hasło natomiast w przypadku użytkownika 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 skorzystać z polecenia: username <nazwa_użytkownika> secret <hasło>

Bardzo fajną możliwością jest nadanie konkretnemu użytkownikowi prawa do wykonania jakiegoś polecenia tak by 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. Cała konfiguracja sprowadza się do wydania poniższych poleceń.

1. 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 powoduje, ż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 to 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 zabezpieczyć się przed atakiem poprzez próbę wielokrotnego logowania się można określić blokowanie konta w przypadku zbyt dużej liczby nieudanych prób. Aby zablokować konto należy użyć polecenia: 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 trzeba użyć komendy: clear aaa local user lockout username <nazwa_użytkownika> | all

Użytkownik TadWal może ponownie się zalogować. Użycie parametru all spowoduje odblokowanie wszystkich kont.

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.
    • konto technik z dostępem na poziomie 5 i dostępem do polecenia ping.
    • konto starszytechink z dostępem na poziomie konta technik plus dostęp do polecenia clock.
    • konto 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.

Omówione poziomy nie dają nam możliwości pełnego kontrolowania dostępu do poszczególnych poleceń a złożona konfiguracja bywa kłopotliwa a dodatkowo nałożone są następujące ograniczenia:

• • • 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 skutkuje tym, ż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.

Inny sposobem określenia uprawnień w systemie czyli kto co może wykonać 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 widoki. 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ć jakie mamy dostępne polecenia. 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, polecenie: 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 zwią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.

Jakby 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ń.

Aby zapewnić bezpieczną komunikację z routerem można skorzystać z usługi SSH. Zaimplementowanie tej funkcji zapewnia nam kanał dzięki któremu będziemy mogli połączyć się z urządzeniem jak to ma miejsce w przypadku skorzystania z usługi Telnet czy Rlogin, lecz co dla nas najważniejsze przechwycona sesja nie zdradzi już atakującemu haseł czy przebiegu przeprowadzonych czynności i użytych komend. Dzieje się tak ponieważ połączenie klient-router jest szyfrowane protokołem SSH a jak zapewne wiesz protokół ten korzysta z silnych algorytmów gwarantujących nam bezpieczeństwo a sesja nawet przechwycona staje się 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 nakłada na nas przeprowadzenie dodatkowe czynności związanych z konfiguracją routera. Czynności te to:

• • • 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, która jest obsługiwana przez router obejmuje wartości od 360 do 2048 bitów. Zasada, która obowiązuje przy ustalania wartości klucza brzmi: 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 wstępie teoretycznym 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 WindowsXP.

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 uzyskania połączenia użyjemy darmowej aplikacji PuTTY. Aplikacja jak już wspomniałem będzie uruchamiana na komputerze WindowsXP. 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ć sesję 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 urządzenia.

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 i 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 z routera na router. 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:

Czyli 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 zdecydowania 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.

Jak już skonfigurowaliśmy bezpieczne połączenie to następnym krokiem jest wyłączenie wszystkich innych możliwości uzyskania połączenia. 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.

Dobrym krokiem jest wyłączenie wszystkich możliwych opcji za pomocą polecenia: transport input none (komendę wydajemy w trybie konfiguracji linii VTY) a następnie włączenie tylko pożądanych protokołów.

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 WindowsXP, kończy się niepowodzeniem.

Sprawdzenie protokołów dopuszczonych do komunikacji 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.

A więc po wprowadzeniu konfiguracji przetestujmy ją. Wydanie polecenia: show login informuje nas o tym, że router jest skonfigurowany do odpierania ataków opartych na zgadywaniu danych potrzebnych do uwierzytelnienia 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 zalogowania, po wydaniu polecenia otrzymujemy informację o:

1 – użytkowniku (informacja o użytkowniku 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 są zapisane 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 WindowsXP. Jako serwer RADIUS posłuży nam 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 skonfigurować się 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ę dodatkowy program, który pozwoli nam sprawdzić 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 działa. W razie wystąpienia problemów zainteresuj się ustawieniami firewalla.

Po skonfigurowaniu serwera RADIUS czas na wprowadzenie stosownych ustawień w routerze. Routerem, który będziemy konfigurować jest tradycyjne router 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> czyli polecenie będzie wyglądało następująco: radius-server host 172.16.1.10 key WinRadius W celu zapewnienia dostępności usług można zdefiniować 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 (co bardziej doświadczony 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ś wyszł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 udało nam się zalogować.

Zajrzyjmy do konfiguracji routera. Jak widać oprócz adresu serwera RADIUS i klucza zostały zdefiniowane dwa porty a mianowicie: auth-port 1645 i acct port 1646. Porty te zostały wprowadzone jako domyślne ustawienie. Cały problem z komunikacją wynikł z tego, że 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). A więc by naprawić problem korygujemy ustawienia na routerze bądź serwerze.

Aby wykonać poprawkę musimy usunąć bieżącą konfigurację odpowiadającą za zdefiniowanie serwera RADIUS, tak więc 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 wspomnianym 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ń 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 nas, ż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ę zawartą na temat 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 dostarcza nam szereg 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 korzystająca z standardowego hasła: enable)

By 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+. Dzieje się 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 natomiast jedynie hasło jest szyfrowane. Tak więc gdy przechwycimy komunikację mamy połowę roboty z głowy ponieważ pozostaje nam tylko złamanie hasła.

By 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 zostało użyte 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 bo by cały proces mógł być możliwy trzeba najpierw przechwycić odpowiedni typ transmisji. Znaczniej bezpieczniej jest użyć serwera TACAS+ niż RADIUS ale opis takiej konfiguracji to już temat na następny wpis.

Możliwa jest również konfiguracja routera poprzez interfejs WWW czyli do połączenia z routerem możemy użyć przeglądarkę internetową. 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 przebiegnie prawidłowo zostaniemy poproszeni o dane uwierzytelniające.

Po wpisaniu poprawnego loginu i hasła uzyskujemy 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ą wysyłane tekstem otwartym. Poniżej zrzut przechwyconego pakietu jak widać login i hasło można odczytać bez problemu.

By zabezpieczyć kanał transmisji klient-router i by móc skorzystać z szyfrowania należy wydać polecenie: ip http secure-server. Po wydaniu polecenia zostaną wygenerowane klucze RSA (podobnie jak to miało miejsce w przypadku połączenia SSH), które będą użyte do zabezpieczenia transmisji. Od tej pory protokołem, który będzie odpowiedzialny za łączność będzie protokół HTTPS.

Po skonfigurowaniu urządzenia, by nawiązać połączenie z routerem w pasku adresu przeglądarki odwołujemy się do protokołu HTTPS. Podczas zestawiania połączenia musimy zaakceptować certyfikat routera.

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

Przechwycona transmisja klient-router nie zdradzi nam już danych, których użyliśmy do nawiązania połączenia, ponieważ jak widać poniżej dane te są 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ę programem Cisco Configuration Professional. Program poprzez interfejs graficzny GUI pozwala nam na dokonanie ustawień routera. Na jakie ustawienia program pozwala oraz jakie platformy wspiera dowiesz się klikając tu: http://www.cisco.com/c/en/us/products/collateral/cloud-systems-management/configuration-professional/data_sheet_c78_462210.html 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. Lecz nie umniejsza to programowi bo ten kto np. konfigurował listy ACL bądź Zone-based Firewall wie ile z tym jest kłopotu i jak łatwo popełnić błąd a za sprawą aplikacji i wbudowanych kreatorów konfiguracja jest znacznie ułatwiona.

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 to musimy podać: adres IP urządzenia, poświadczenia oraz określić tryb komunikacji (czy korzystamy z szyfrowania). 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 zaznaczenia typu komunikacji 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łącznia.

Po nawiązaniu poprawnego połączenia i po kliknięciu na Configure możemy przeprowadzać konfigurację urządzenia. Wszystkie niezbędne wpisy konfiguracyjne są generowane na bieżąco i po skończeniu wprowadzania stosownych ustawień są dostarczane do urządzenia.

Moim założeniem w przypadku CCP było pokazanie jedynie możliwości konfiguracji routera w ten sposób bo opis samego programu to już temat na kolejny wpis.

I tym ostatnim sposobem chciałbym zakończyć rozważania na temat praw użytkownika w systemie IOS oraz dostępu zdalnego do urządzeń CISCO.

Tak sobie myślę, że następnym wpisem dotyczącym konfiguracji routerów Cisco będzie wpis w którym powrócę do routingu dynamicznego a konkretniej na tapetę wziąłbym protokół EIGRP. No chyba, że czytelniku masz inny pomysł tak więc w komentarzach czekam na ewentualne sugestie.

Bibliografia:

http://www.techexams.net/forums/ccna-ccent/77086-ccp-supported-hardware.html

http://www.cisco.com/c/en/us/products/collateral/cloud-systems-management/configuration-professional/data_sheet_c78_462210.html

http://www.dslreports.com/faq/9815