Podstawy sieci z Cisco IOS. Moduł 1: Dostęp do urządzenia
Cisco IOS CLI posiada domyślnie aktywny tak zwany transport powłoki, którym jest domyślnie Telnet. Jego działanie widać na zrzucie poleceń. Kiedy wpisujemy nazwę, która nie jest poleceniem system próbuje nawiązać do niej połączenie z użyciem protokołu Telnet. Robi to też, gdy wpiszemy w CLI sam adres IP czy też użyjemy do tego celu polecenia "telnet" z parametrem, którym jest nazwa lub adres IP. Wszystkie 4 scenariusze są widoczne na slajdzie i dają ten sam efekt.
Za każdym razem połączenie nawiązuje się, ale jesteśmy od razu rozłączani z komunikatem "Password required, but none set". Hasło jest wymagane w tego typu dostępie, ale żadne nie zostało skonfigurowane. Na tym etapie to poprawny komunikat, bo nie konfigurowaliśmy jeszcze zdalnego dostępu do urządzenia. Rozłącza nas węzeł docelowy - "closed by foreign host".
Domyślny transport powłoki bywa czasem irytujący. Szczególnie, gdy wpisując polecenie zrobimy literówkę i powstała nazwa nie jest ani rozpoznawalną w strukturze DNS nazwą, ani poleceniem. System Cisco IOS próbuje nawiązać do niej połączenie z użyciem domyślnego transportu powłoki. Widać to na zielonawym tle zrzutu poleceń. Jest to o tyle irytujące, że te wszystkie próby ponowienia widoczne na zielonawym tle mogą potrwać nawet kilka minut, zanim znowu dostaniemy dostęp do CLI.
Jednym ze sposobów radzenia sobie z tą niedogodnością jest możliwość przerwania wyszukiwania z użyciem sekwencji przerywającej "Ctrl+Shift+6", po której w niektórych klienta trzeba nacisnąć jeszcze dowolny klawisz (np. x).
Innym sposobem, jest omówione wcześniej polecenie "no ip domain lookup". Efekt wpisania błędnego polecenia po jego wydaniu widać na żółtawym tle zrzutu poleceń. Trwa to znacznie krócej, bo zwykle poniżej 2-sekund. Niemniej używanie tego polecenia nie jest zalecane. Dezaktywuje ono obsługę serwerów DNS na urządzeniu, co czasem bywa jednak potrzebne. Ponadto, domyślny transport powłoki nadal działa, co widać nieco niżej, na błękitnawym tle, po wpisaniu adresu IP.
Do zalecanego sposobu radzenia sobie z tym wrócimy niebawem.
Korzystać możemy z zarządzania typu OOB - "out of band management", IB - "in band management" lub obu jednocześnie.
W przypadku scentralizowanej infrastruktury, jaką zwykle posiada centrum danych, dość popularne jest OOB. Stosowana jest tam oddzielna sieć, która spina interfejsy zarządzania urządzeń sieciowych. Jest to wygodne przy automatyzacji, jako że bez względu na to jak konfigurujemy połączenia przetwarzające ruch, zawsze zachowujemy pewne połączenie do zarządzania urządzeniem.
IB stosowane jest częściej w sieciach rozproszonych, gdzie trudniejsze czy mniej możliwe jest stworzenie oddzielnej sieci tylko do zarządzania. Jest to też opcja bardziej ekonomiczna, gdyż nie wymaga dodatkowej infrastruktury do zarządzania. Jej minusem jest możliwość odcięcia się od zarządzanego urządzenia. Stąd ta metoda zarządzania wymaga większej ostrożności.
Do tej pory zarządzaliśmy urządzeniami tylko poprzez port konsoli. Jest to zarządzanie typu OOB. Teraz zajmiemy się zdalnym dostępem do urządzenia. W zależności od tego, czy będziemy mieli dedykowany interfejs sieciowy do zarządzania czy też nie, będziemy mieli do czynienia z zarządzaniem OOB lub IB. W obu przypadkach, dostęp ten będzie docierał do wirtualnych terminali po stronie urządzenia sieciowego. Urządzenie może obsługiwać wiele wirtualnych terminali (VTY - Virtual TeletYpe).
Ich ilość zależy od platformy. Niemniej ze względu na to, że trzeba je najpierw aktywować, a to alokuje dla nich pamięć operacyjną urządzenia, nie zaleca się aktywowania więcej niż 16 wirtualnych terminali ("vty 0 15"). Zwykle nie będziemy nawiązywać do urządzenia sieciowego więcej niż 5 zdalnych sesji, stąd jest to wartość bezpieczna.
Wirtualne terminale przydzielane są kolejno, zaczynając od zera. Aby został przydzielony terminal z numerem 4, to wcześniej muszą istnieć nawiązane już sesje do terminali 0, 1, 2 i 3. Jest to o tyle istotne, że każdy z tych wirtualnych terminali może mieć inne ustawienia, w tym inne hasło. Dla przykładu na ostatnim terminalu możemy ustawić inne hasło, by zabezpieczyć się przed zajęciem wszystkich sesji. Natomiast najczęściej wszystkie te wirtualne terminale ustawia się tak samo.
Aby skonfigurować port konsoli, należy użyć polecenia "line console 0". Zmieni się wtedy kontekst i od tego momentu wszystkie wydawane przez nas polecenia będą dotyczyły tylko portu konsoli urządzenia. Domyślnie port ten nie ma ustawionego hasła i nie ma też włączonej usługi logowania, która go wymaga. Dzięki temu możemy się podłączyć do urządzenia i dokonać konfiguracji inicjalizacyjnej. Zatem, aby zabezpieczyć port konsoli, trzeba ustawić na nim hasło i włączyć usługę logowania.
Konfiguracja wirtualnych terminali odbywa się poprzez wejście do konfiguracji specyficznego terminala - "line vty 4" lub zakresu wirtualnych terminali - "line vty 0 15". Po słownie "vty" podajemy zakres łączny. Korzystamy z tych samych poleceń, co w przypadku portu konsoli. Różnicą jest to, że domyślnie usługa logowania jest już włączona. Dlatego po nawiązaniu połączenia Telnet dostajemy komunikat "Password required, but none set", po czym zostajemy rozłączeni. Zatem, aby zabezpieczyć logowanie do wirtualnych terminali wystarczy ustawić samo hasło. Gdybyśmy wpisali w konfiguracji wirtualnych terminali polecenie "no login", to zachowywałyby się one jak port konsoli. Dawałby dostęp każdemu bez żadnego uwierzytelnienia.
Na błękitnawym tle widać, że po ustawieniu hasła do wirtualnych terminali nie jesteśmy już rozłączani ze wspomnianym wcześniej komunikatem. Po podaniu hasła dostajemy dostęp do trybu User EXEC. Kiedy wpiszemy "enable", jesteśmy ponownie pytani o hasło. Jest to hasło do trybu uprzywilejowanego, którym zajmiemy się dalej. Jeżeli hasło do trybu Privileged EXEC nie zostało jeszcze zdefiniowane, to należy na tym etapie wprowadzić hasło, jakie zostało ustawione na porcie konsoli.
Obserwowaliśmy wcześniej efekt działania domyślnego transportu powłoki. W szczególności ten negatywny, kiedy wpisaliśmy błędne polecenie. Powiedzieliśmy też, że wrócimy do zalecanego sposóbu radzenia sobie z nim.
Zalecanym sposobem zmiany tego zachowania jest po prostu wyłączenie domyślnego transportu powłoki. Dokonać tego można niezależnie dla portu konsoli i portów wirtualnych terminali. Służy do tego polecenie "transport preferred none".
Logowanie do wirtualnych terminali domyślnie wymaga podania hasła. Domyślnie włączona jest na nich usługa logowania. Na zrzucie możemy zobaczyć, jak wygląda logowanie do wirtualnych terminali po jej wyłączeniu z użyciem "no login".
Na zielonkawym tle widać, że zostaliśmy wpuszczeni poprzez Telnet bez podawania żadnego hasła. Następnie wpisujemy "enable" i jako, że hasło do trybu Privileged EXEC nie zostało jeszcze ustawione, podajemy hasło ustawione na porcie konsoli.
Kiedy usuniemy hasło z portu konsoli, nie będzie możliwe wejście do trybu Privileged EXEC, co widać na błękitnawym tle.
Zatem, jeżeli nie ma ustawionego hasła do trybu uprzywilejowanego, ani hasła do trybu konsoli, wtedy po wpisaniu "enable" otrzymamy komunikat "% No password set". Dobrą praktyką jest określenie, z którego interfejsu mają być nawiązywane wszystkie połączenia Telnet z urządzenia. Najlepiej wybrać do tego celu interfejs loopback. O powodach tego już pisaliśmy przy okazji omawiania tego interfejsu. Służy do tego polecenie "ip telnet source-interface".
Istnieje możliwość ustawienia zarówno portu konsoli, jak i wirtualnych terminali w taki sposób, by zaraz po zalogowaniu się dawały one dostęp bezpośrednio do trybu Privileged EXEC (z pominięciem User EXEC). Do tego celu służy polecenie "privilege level 15". Wydać je można bezpośrednio w porcie konsoli i portach terminali wirtualnych.
Wyrażenia porty i linie są używane przez nas często zamiennie w przypadku odnoszenia się do trybów konfiguracji szczegółowej "line console 0" i "line vty 0 15". Sposób ich konfiguracji z użyciem "privilege level 15" widać na zrzucie poleceń. Efekt tego polecenia widoczny jest po zalogowaniu, na niebieskawym tle zrzutu poleceń.
Dostęp do trybu uprzywilejowanego, czyli tak zwanego Privileged EXEC może zostać zabezpieczony z użyciem hasła. Służy do tego polecenie "enable secret". Dawniej do tego celu stosowane było polecenie "enable password". Nie powinno być ono już stosowane. Jest ono nadal dostępne w CLI tylko w celu zachowania zgodność wstecznej systemu.
- "enable password" przechowuje hasło w konfiguracji w formie otwartego tekstu, co nie jest bezpieczne.
- "enable secret" przetrzymuje je w formie hasha, domyślnie z użyciem funkcji skrótu MD5.
Różnicę widać na zielonawym i czerwonawym tle zrzutu poleceń.
Jeżeli zostało ustawione "enable password" i realizowana jest próba konfiguracji "enable secret" z tą samą wartością, otrzymamy ostrzeżenie widoczne na żółtawym tle zrzutu poleceń. Nie jest to rekomendowane, stąd system zaleca wybranie innej wartości.
Jeżeli ustawione jest i "enable password" i "enable secret", wtedy to drugie jest ważniejsze i ono obowiązuje. Pierwsze nie działa.
Hasło do trybu uprzywilejowanego może być tylko jedno. Niemniej do utworzenia hasha możemy użyć jednego z kilku algorytmów czy funkcji hashujących. Domyślnym jest wspomniany wcześniej MD5. Oprócz niego możemy też użyć PBKDF2 lub SCRYPT.
Na zrzucie poleceń widać tworzenie hasła kolejno z użyciem innych algorytmów. Warto zwrócić uwagę na cyfrę, jaka poprzedza utworzony hash. Cyfra ta oznacza użyty do tego celu algorytm, gdzie 5 zostało przedziane dla MD5, 8 dla PBKDF2, 9 dla SCRYPT (RFC 7914), a 0 dla hasła zapisanego otwartym tekstem.
Kiedy popatrzymy na wartość hash, to składa się ona z 3 wartości odseparowanych znakami dolara "$". Pierwsza wartość określa typ hasha (1 to MD5). Drugą wartością jest użyta sól czy inaczej ciąg zaburzający, który utrudnia złamania hasła z użyciem metod opartych na tak zwanych tęczowych tablicach. Dopiero ostatnią wartością jest właściwy hash.
Warto pamiętać, że proces uwierzytelnienia odbywa się tylko na początku logowania, stąd wybrana metoda czy algorytm wcale nie musi być szybki. Za to dobrze, aby był trudny do zrównoleglenia i co za tym idzie złamania, w przypadku wycieku hashy.
Zdarza się, że niektóre osoby wklejają konfigurację na różnych forach, szukając pomocy. Bardzo ważne jest, aby nie zapomnieć o usunięciu z niej wszelkich haseł, zarówno tych zapisanych otwartym tekstem, jak i w formie hashy.
Haseł typu 4 nie należy nigdy stosować. Ze względu na błąd w implementacji stosują one pojedynczą iterację SHA-256 bez żadnej soli, sprawiając iż są one łatwiejsze do złamania od haseł typu 5. W nowych systemach Cisco IOS metoda ta nie jest dostępna, niemniej w niektórych starszych wersjach można na nią napotkać.
W systemie Cisco IOS dostępna jest usługa szyfrowania niezaszyfrowanych haseł. Usługa ta stosuje szyfr Vigenère’a, choć niektórzy nazywają to algorytmem "Cisco-defined". Jest to odwracalna metoda, która zabezpiecza jedynie przed podglądnięciem hasła. Przekształca ona je w trudniejszy do zapamiętania ciąg znaków. Niemniej, bardzo łatwo wykonać operację odwrotną.
Hasła do portu konsoli i wirtualnych terminali są hasłami typu 0 - składowane są w formie otwartego tekstu. Widać to na żółtawym tle zrzutu poleceń. Widać też na zielonawym tle, jak po aktywacji usługi szyfrowania niezaszyfrowanych zostały przekształcone.
Wyłączenie usługi szyfrowania niezaszyfrowanych haseł nie wywołuje operacji odwrotnej. Hasła pozostaną nadal w przekształconej formie, czyli będą hasłami typu 7. Widać to na niebieskawym tle zrzutu poleceń. Natomiast wszystkie nowo wprowadzane hasła staną się hasłami typu 0 i będą składowane w formie otwartego tekstu. Widać to na czerwonawym tle zrzutu poleceń.
Niektóre hasła i klucze muszą być przetrzymywane w konfiguracji w formie otwartego tekstu. Wynika to z tego, że z takiego hasła czy klucza w połączeniu z jakimiś danymi dopiero tworzony jest hash, który służy do uwierzytelnienia czegoś. W takich przypadkach warto rozważyć włączenie usługi szyfrowania niezaszyfrowanych haseł "service password-encryption".
Dodatkowo, dla kluczy ISAKMP (wykorzystywane do zestawiania tuneli IPsec VPN) istnieje też możliwość stosowania haseł typu 6, które to nie są składowane w postaci jednokierunkowego hasha, a w postaci zaszyfrowanej, którą można przed użyciem zdeszyfrować. W przypadku typu 6 do szyfrowania stosowany jest AES (Advanced Encryption Standard).
Proces przekształcenia hasła typu 7 w ciąg znaków będący otwartym tekstem można przeprowadzić nawet z użyciem Cisco IOS.
Na zrzucie widać sposób odwrócenia szyfru Vigenère’a dla hasła typu 7 z użyciem mechanizmów wbudowanych w samym Cisco IOS CLI. Wykorzystać do tego celu można polecenie "show key chain", które służy do wyświetlania składowanych kluczy.
W trakcie ćwiczeń warto dezaktywować automatyczne wylogowywanie z konsoli i wirtualnych terminali. Domyślnie następuje ono po 10-minutach nieaktywności. Sposób konfiguracji i działania tego mechanizmu został zaprezentowany na zrzucie poleceń.
Warto dla przypomnienia zwrócić uwagę na dezaktywowanie usługi logowania w konfiguracji wirtualnego terminala z użyciem polecenia "no login". Skutkiem tego dostaliśmy od razu dostęp do CLI, bez jakiegokolwiek uwierzytelnienia.
W trakcie pracy na urządzeniach możemy sprawdzić kto i do jakiej linii jest zalogowany. Służy do tego polecenie "show users" lub "who". Widać to na błękitnawym tle zrzutu. Warto zwrócić uwagę na pustą kolumnę "User", jako że obecnie logujemy się tylko do bezimiennego, współdzielonego konta. Nie jest to oczywiście zalecane w środowisku produkcyjnym.
Istnieje również możliwość rozłączenia wskazanej linii lub portu konsoli i co za tym wylogowania innego użytkownika. Sesja oznaczoną gwiazdką "*" oznacza naszą sesję. Służy do tego polecenie: "clear line". Sposób jego użycia został zaprezentowany na zrzucie poleceń. Polecenie to należy do trybu Privileged EXEC.
W systemie Cisco IOS da się wysyłać wiadomości innych użytkowników. Służy do tego polecenie "send". W górnym zrzucie poleceń widać sposób wysłania takiej wiadomości, a w dolnym, jak są one widoczne po stronie odbiorcy.
Zgodnie z tym co wyświetla Cisco IOS, kiedy skończymy tworzyć wiadomość, należy użyć "Ctrl+Z" by ją wysłać. Jeżeli jednak tego nie chcemy, możemy użyć "Ctrl+C" by anulować wysyłanie. Warto zwórić uwagę, że polecenie "send" należy do trybu Privileged EXEC.
Do tej pory omawialiśmy głównie zdalny dostęp z użyciem współdzielonego hasła oraz dostęp bez uwierzytelnienia. W obu przypadkach nie są to zalecane sposoby dostępu do urządzenia. Każda logująca się osoba powinna mieć własne konto za które odpowiada. W ten sposób da się jednoznacznie wskazać, kto i kiedy wydał dokładnie jakie polecenie.
Dodatkowo, kiedy zdarzenia powiązane z wydaniem polecenia będą wysyłane do serwera Syslog, razem z nimi pojawi się nazwa odpowiedniego użytkownika. Dzięki indywidualnym kontom istnieje także możliwość różnicowania czy dostosowania uprawnień do tylko tych, jakie niezbędne są danej osobie do pracy czy też są dostosowane do jej kompetencji i wiedzy.
Lokalne konta użytkowników tworzymy z użyciem polecenia "username". Hasło do konta może być różnego typu, analogicznie jak to miało miejsce z hasłami do trybu Privileged EXEC.
Na zrzucie poleceń widać sposób zakładania konta z użyciem różnych funkcji hashujących, sposób weryfikacji dostępnych w systemie kont oraz usunięcie użytkownika. Jak widać na czerwonawym tle, operacja usunięcia użytkownika wymaga zatwierdzenia.
Kiedy już założone są konta użytkowników, należy skonfigurować port konsoli oraz porty wirtualnych terminali do korzystania z lokalnej bazy użytkowników. Do tego celu służy polecenie "login local".
Po wpisaniu "login local" polecenie "password" przestaje mieć zastosowanie i można je usunąć z konfiguracji.
Użytkownicy otrzymują uprawnienia skonfigurowane w ramach danego portu (konsoli lub wirtualnego terminala). Domyślnie są to uprawnienia poziomu 1, ale można je zwiększyć, stosując poznane wcześniej polecenie "privilege level 15".
Użytkownikom można też indywidualnie zwiększyć uprawnienia z użyciem parametru "privilege 15" polecenia "username".
Warto zwrócić uwagę na wydruk zrzutu poleceń. Na zielonawym tle widać, że kiedy mam indywidualne konta użytkowników, to ich nazwy się wyświetlają w kolumnie "User" poleceń "who" i "show users".
Widać też, że użytkownicy mogą mieć różne uprawnienia. W naszym przykładzie, na niebieskawym tle widać, że "user2" dostał dostęp do User EXEC, podczas gdy na zielonawym tle widać, jak "user4" dostał dostęp od razu do Privileged EXEC.
Do podstawowej konfiguracji nalezy również ustawienie dodatkowych informacji o urządzeniu oraz ostrzeżeń.
Ze zdalnym dostępem powiązane są tak zwane banery. Są one komunikatami ostrzegawczymi. Dostępne są m.in.:
- "banner motd", który wyświetlany jest po poprawny uwierzytelnieniu się do urządzenia. Jego przeznaczeniem jest wyświetlanie informacji istotnych w danym okresie czasu. Zatem jest on często modyfikowany. Przykładem może być prośba o zapisanie ustawień w związku z planowanym we wskazanym dniu wyłączeniem urządzeń lub prądu.
- "banner exec", który wyświetlany jest po poprawny uwierzytelnieniu się do urządzenia. Stosowany jest zwykle do bardziej stałych informacji, jak dla przykładu informacja o lokalizacji urządzenia czy osobie odpowiedzialnej za dane urządzenie.
- "banner login", który wyświetla się przed uwierzytelnieniem do urządzenia. Pełnić może funkcje ostrzegawcze, które informują o tym, że dozwolony jest tylko dostęp autoryzowany, a każda aktywność użytkownika podlega monitorowaniu.
Do tworzenia tych komunikatów można stosować również zmienne. Kilka przykładowych znajduje się w lewym dolnym rogu slajdu. Warto na tym etapie dokładnie przeanalizować zrzut poleceń, gdzie widać na odpowiednich tłach zarówno tworzenie, jak i weryfikację każdego z omówionych tutaj banerów.
Przed kolejną porcją wiedzy zachęcamy do przećwiczenia i utrwalenia tej poznanej tutaj. Skorzystaj z naszych ćwiczeń!
Zachęcamy do śledzenia nas w mediach społecznościowych Facebook i LinkedIn.
Zapraszamy do kontaktu drogą mailową
