Slow7 - Slow7 - Sieci komputerowe

Yubico czyli jak chronić dostęp do naszych kont

2017-11-23T21:58:36+00:00

Uwierzytelnianie dwuskładnikowe (ang. two-factor authentication, 2FA) czy wieloskładnikowe są to mechanizmy bezpiecznego logowania łączące w sobie dwie lub więcej metod autoryzacji użytkownika. Aktywacja tego typu zabezpieczeń ochroni nas a już na pewno utrudni nieautoryzowany dostęp do konta w sytuacji gdy hasło zostanie skradzione bądź złamane.

Ogólny sposób działania weryfikacji 2FA opiera się na sprawdzeniu czy jesteś tym za kogo się podajesz. Aby uwierzytelnienie się powiodło sprawdzane elementy muszą wskazywać na Ciebie. Na elementy te mogą składać się: „coś co posiadasz” (karta kredytowa, telefon); „coś co wiesz” (PIN, hasło) oraz „to kim jesteś” (linie papilarne, siatkówka oka, głos, rozpoznawanie twarzy). Spójność i zgodność dwóch (lub więcej) sprawdzanych cech umożliwi uwierzytelnienie.

Yubikey jest kluczem USB a jego zadaniem jest ochrona naszych kont wspierających ten model uwierzytelnienia w myśl zasady „coś co posiadasz”. Urządzenie umożliwia wykorzystanie go w procesie dwuskładnikowego uwierzytelnienia (hasło plus token) w takich serwisach jak: Google, Facebook, GitHub czy Drobbox. Użycie urządzenia nie ogranicza się tylko do sfery online, klucz również może nam posłużyć do logowania się w systemach Windows, MacOs czy Linux.

Cały proces logowania sprowadza się do umieszczenia tokenu w porcie USB i naciśnięciu złotego dysku oczywiście po uprzednim sparowaniu klucza z danym kontem do którego dostęp chcemy chronić.

Całość procesu oparta jest na wykorzystaniu standardu Universal 2nd Factor (U2F). Podczas rejestracji tokenu w danym serwisie, generowany jest klucz prywatny, który następnie szyfrowany jest hasłem głównym urządzenia i tak przygotowany pakiet danych jest przekazywany do danego serwisu. Podczas próby logowania następuje proces odwrotny - rozszyfrowanie. Zapytanie wysłane od serwisu online jest porównywane z wygenerowanym podczas rejestracji kluczem prywatnym. Jeśli wszystko się zgadza uzyskujemy dostęp do usługi.

Obsługa standardu U2F jak na razie dostępna jest tylko przy wykorzystaniu przeglądarki Chrome, Opera oraz Firefox (od wersji 57). Wcześniejsze wersje „liska” tej metody weryfikacji nie wspierają.

Sam token dostępny jest w kilku wersjach, które różnią się pomiędzy sobą możliwościami bądź użytym standardem portu USB. Pełne porównanie dostępne jest tu: https://www.yubico.com/products/yubikey-hardware/compare-yubikeys/

Najciekawszym modelem jest YubiKey NEO, który wspiera komunikację NFC dając nam możliwość wykorzystania klucza w połączeniu z smartfonem.

Ponieważ Yubikey w systemie jest wykrywany jako klawiatura posiada on możliwość zapisania w swojej pamięci dwóch 32 znakowych haseł. Wklejenie hasła odbywa się poprzez przytrzymanie przez określony czas złotego dysku - 1 sekunda powoduje wklejenie hasła zapisanego w slocie pierwszym, po 3 sekundach wpisanie hasła ze slotu drugiego. Funkcja ta pozwala na wykorzystanie klucza w procesie logowania się do systemu operacyjnego bądź np. podania hasła celem odszyfrowania wolumenu (TrueCrypt czy VeraCrypt).

Możliwości urządzenia nie kończą się na przedstawionych do tej pory przykładach gdyż przy jego pomocy i dodatkowemu oprogramowaniu możemy utworzyć swoje własne centrum generowania 6-znakowych haseł, które posłużą nam do uzyskania dostępu do naszych kont - coś na wzór Google Authenticator.

W wpisie tym chciałbym pokazać jak przy współudziale tokenu możemy chronić dostęp do serwisu Facebook oraz usług Google.

Przejdźmy zatem do omówienia wykorzystania klucza w praktyce. W pierwszej kolejności na „tapetę” bierzemy Google.

Rozpoczynamy od zalogowania się do swojego konta Google. Następnie wybieramy odnośnik: Logowanie się w Google

W kroku drugim włączamy: Weryfikację dwuetapową

Informacja o pomyślnym włączeniu mechanizmu zostanie wysłana na nasz adres email.

Google proponuje Nam kilka metod weryfikacji dwuetapowej:

Kody zapasowe - karta z kodami jednorazowymi, do wykorzystania gdy nie mamy przy sobie smartfona,
Potwierdzenia od Google - kody wysyłane w postaci smsa,
Aplikacja authenticator - program instalowany na platformie Android bądź iOS, który generuje kody wykorzystywane w procesie logowania,
Klucz bezpieczeństwa - klucz przypominający pendriva, podłączany do portu USB w pamięci, którego zaszyte są informacje uwierzytelniające.

Ponieważ Yubico jest właśnie takim kluczem wybieramy opcję: Dodaj klucz bezpieczeństwa

Po wybraniu opcji czeka Nas „niespodzianka” w postaci komunikatu o niemożliwości wykonania operacji z powodu użycia nieodpowiedniej przeglądarki. Wszystkie opisywane operacje wykonywałem w przeglądarce Firefox, bez wsparcia dla standardu U2F. Aby móc wykorzystać klucz Yubico musimy przesiąść się na Chrome, Operę bądź wykonać aktualizację przeglądarki Firefox do najnowszej wersji.

Została pobrana i zainstalowana przeglądarka Chrome.

Po uruchomieniu przeglądarki, zalogowaniu się na konto Google ponownie wybieramy opcję: Dodaj klucz bezpieczeństwa Przygotowujemy klucz ale jeszcze go do portu USB nie podłączamy. W nowo otwartym oknie wybieramy Dalej

Podłączamy token i przyciskamy na kluczu złotą tarczę.

Klucz został zarejestrowany.

Informację o używanym kluczu znajdziemy w opcjach weryfikacji dwuetapowej.

Gdy do procesu logowania jest używana przeglądarka nie wspierająca standardu U2F należy wykorzystać jedną z pozostałych metod weryfikacji. W przykładzie poniżej został użyty telefon w połączeniu z kodem dostarczanym w formie SMS-a.

Od tej pory gdy do logowania użyjemy przeglądarkę wspierającą klucz bezpieczeństwa (czyli Chrome, Opera, Firefox od wersji 57 włącznie) zostaniemy poproszeni o użycie klucza, jeśli ta sama operacja zostanie wykonana z poziomu np. przeglądarki Edge na nasz numer zostanie wysłany SMS z kodem weryfikacyjnym.

Jeśli chcemy usunąć zarejestrowany klucz to odpowiednią opcję znajdziemy w ustawieniach: Weryfikacji dwuetapowej

Rejestracja klucza została wykonana czas sprawdzić czy wszystko działa. Wykonujemy ponowne logowanie. Podczas pierwszego etapu wpisujemy hasło.

Po wpisaniu poprawnego hasła zostaniemy poproszeni o włożenie klucza Yubico.

Po podłączeniu klucza i wciśnięciu złotego dysku nastąpi zalogowanie do usług Google.

W razie jakichkolwiek problemów będziemy mogli dokończyć logowanie z wykorzystaniem wiadomości SMS bądź innej zdefiniowanej metody.

Klucz Yubico został poprawnie powiązany z serwisem Google.

Jak już wspomniałem Google nie jest jedynym serwisem, który wspiera ten typ uwierzytelnienia. Klucz Yubico możemy również połączyć z naszym kontem na Facebook-u.

Aby móc skorzystać z klucza podobnie jak w przypadku Google musimy włączyć weryfikację dwuetapową. Stosowne opcje znajdziemy w Ustawieniach na karcie Bezpieczeństwo i logowanie

Odszukujemy opcję: Używaj uwierzytelnienia dwuskładnikowego

Po wyborze opcji mamy możliwość określenia metody uwierzytelnienia.

W pierwszej kolejności włączamy mechanizm uwierzytelnienia dwuskładnikowego. Wybieramy: Skonfiguruj

Jak widać na zrzucie powyżej użyta przeglądarka nie wpiera uwierzytelnienia w postaci klucza bezpieczeństwa.

Dostępne metody uwierzytelnienia to:

wiadomość tekstowa SMS - niezbędny kod celem przeprowadzenia uwierzytelnienia zostanie wysłany w postaci wiadomości SMS,
klucze zabezpieczeń - zewnętrzne urządzenia takie jak opisywany klucz Yubico,
generator kodów - kody wykorzystywane w procesie uwierzytelnienia są generowane przy wykorzystaniu aplikacji Facebook zainstalowanej na smartfonie,
kody resetowania - karta kodów wykorzystywana w przypadku braku dostępu do telefonu.

włączenie procesu uwierzytelnienia dwuskładnikowego ma swoje konsekwencje w sytuacjach w których konta Facebook używamy celem uzyskania dostępu do innych serwisów (w szczególności dotyczy to usług Xbox, Spotify czy Skype). Po włączeniu opcji podwójnej weryfikacji dostęp do wymienionych usług za pomocą konta Facebook będzie niemożliwy. Aby rozwiązać ten problem należy użyć opcji: Hasło do aplikacji za pośrednictwem, której uzyskamy dostęp do wymienionych serwisów za pośrednictwem konta Facebook.

opcja: autoryzowane logowania pozwala nam na przejrzenie urządzeń co do których nie jest wymagane przeprowadzenie wprowadzenia dodatkowego kodu celem dokończenia procesu logowania.

Przejdźmy zatem do konfiguracji uwierzytelnienia dwuetapowego. Wybieramy opcję: Skonfiguruj. W nowo otwartym oknie potwierdzamy wolę włączenia funkcji.

Aby uaktywnić funkcję jeszcze raz musimy podać hasło do serwisu.

Uwierzytelnienie dwuskładnikowe zostało włączone.

Dodatkowo, osobnym emailem zostaniemy poinformowani o włączeniu mechanizmu dwustopniowej weryfikacji dostępu do konta.

Od teraz aby uzyskać dostęp do naszego konta Facebook będziemy musieli wprowadzić dodatkowy kod, który zostanie nam dostarczony za pomocą SMS-a.

Aby uniknąć każdorazowego podawania kodu, po zakończeniu procesu logowania możemy zdecydować czy użyta przeglądarka ma zostać zapisana. Wybranie opcji: Zapisz przeglądarkę spowoduje, że podczas kolejnej próby uzyskania dostępu do konta wymagane będzie jedynie hasło.

Metoda uwierzytelnienia oparta o wiadomość SMS, działa. Sprawdźmy zatem jak spisze się klucz Yubico. Ponownie przechodzimy do opcji uwierzytelnienia dwuskładnikowego. Odszukujemy sekcję Klucze zabezpieczeń i wybieramy opcję Dodaj klucz.

W oknie Dodaj klucz zabezpieczeń klikamy Dodaj klucz.

Po podłączeniu klucza i przytrzymaniu złotego przycisku wybieramy Kontynuuj.

Dodanie nowego klucza wymaga ponownego wprowadzenia hasła.

Po uwierzytelnieniu, opcjonalnie możemy zdefiniować nazwę naszego klucza.

Klucz Yubico został poprawnie powiązany z serwisem Facebook. Od tej pory proces logowania będzie przebiegał z wykorzystaniem klucza.

W przypadku braku klucza dostęp do konta uzyskamy dzięki kodowi SMS.

Sparowaliśmy klucz Yubico z kontami Google oraz Facebook. Czy jest to dobra metoda chroniąca dostęp do naszych kont? Wszystko zależy od naszych preferencji. Na pewno w dzisiejszych czasach ochrona dostępu do ważnych kont tylko przy użyciu hasła jest niewystarczająca a każda z metod podnosząca ochronę jest na plus.

Nie wszystkie serwisy umożliwiają użycie klucza jakim jest Yubico. Na szczęście to się zmienia (powoli) i coraz więcej portali dostrzega potrzebę wprowadzenia tego typu rozwiązań. Potrzeba stosowania dodatkowych zabezpieczeń dostępu do usług jest konieczna a token USB i hasło dość skutecznie bronią dostęp do naszych danych.

Co w sieci siedzi. Protokół DNS.

2017-06-08T21:13:43+00:00

W pierwowzorze wpis ten miał dotyczyć konfiguracji roli serwera DNS w systemie Windows Server 2012 ale ponieważ wcześniej zbyt wiele o protokole DNS nie napisałem postanowiłem w pierwszej kolejności przedstawić sposób działania tego protokołu a następnie skupić się na zagadnieniach związanych z jego konfiguracją. Myślę, że przyjęty schemat postępowania będzie dla Ciebie czytelniku bardziej przystępny gdyż zanim będziemy konfigurować system do pełnienia roli serwera DNS warto poznać sposób działania samego protokołu. Nie przedłużając zapraszam do lektury artykułu.

Zarządzanie przestrzenią nazw domenowych ma ogromne znaczenie w sieci Internet oraz w sieciach korporacyjnych (w sieciach domowych raczej nikt serwera tego typu nie posiada, gdyż jest to zbędne lecz nie oznacza to że z usługi tej nie korzystamy).

W sieciach firmowych działanie mechanizmu DNS ma szczególne znaczenie gdyż zapewnia on:

stabilność komunikacji pomiędzy hostami a serwerami,
odszukanie kontrolera domeny i wykonanie procesu logowania,
dostęp aplikacją biznesowym do przydzielonych im zasobów,
poprawne funkcjonowanie otoczenia sieciowego i widoczność krytycznych zasobów,
użytkownikom sieci VPN na dostęp do świadczonych usług czy możliwość połączenia z siecią Intranet.

Używając ścieżek bezpośrednich w oparciu o adres IP problem nie występuje.

Pewnie nie jest to dla Ciebie Czytelniku tajemnicą, że do komunikowania się między sobą komputery w sieci wykorzystują adresy IP. Ich format oraz wartości dla nas ludzi stanowią pewien problem gdyż są po prostu trudne do zapamiętania. Znacznie lepiej zamiast przykładowego adresu 213.180.141.140 pamiętać www.onet.pl. Jest to tzw. nazwa kanoniczna. Użyty format odzwierciedla hierarchię systemu nazw domen używanych w sieci Internet, czyli DNS (ang. Domain Name Service). Aby tradycyjne adresy IP mogły współistnieć z nazwami komputerów, należało wymyślić i opracować mechanizm, który wykonywałby odwzorowywanie adresów z jednej postaci w drugą. I tym właśnie zajmuje się DNS.

Sposób działania DNS-u został opracowany przez organizację IETF (ang. Internet Engineering Task Force) a jego opis znajdziemy w dokumentach RFC 1034 i 1035.

System DNS jest standardem usługi nazw. Usługa DNS pozwala komputerom znajdującym się w sieci komputerowej rejestrować i rozwiązywać nazwy domen DNS. Za pomocą tych nazw można zidentyfikować i uzyskać dostęp do zasobów oferowanych przez inne komputery w sieci lub innych sieciach, takich jak Internet.

Aby nazwa komputera mogła być odwzorowana na adres IP musi przyjmować zdefiniowany format zgodny z zasadami przyjętymi w modelu systemu DNS. Na samym początku istnienia sieci komputerowych powiązanie nazwy komputera z jego adresem IP odbywało się poprzez zapisanie tych informacji w jednym pliku tekstowym. W miarę jak sieci komputerowe rozwijały się i rosła ich liczba rozwiązanie te przysparzało coraz więcej problemów. Dlatego też jak mówi stare przysłowie - „Potrzeba jest matką wynalazków: zdecydowano się na wprowadzenie systemu opartego o hierarchiczny, rozproszony model definiowania nazw.

Najwyższy poziom w hierarchii jest reprezentowany przez znak „.” nazywany również korzeniem drzewa bądź domeną główną (w obiegu używana jest również nazwa root). Sposób definiowania nazw kolejnych poddomen nie został określony lecz przyjęto pewne zasady nazewnictwa i na następnym poziomie określono nazwy domen oraz zdefiniowano ich przeznaczenie. I tak pojawiły się poddomeny typu:

com - organizacje komercyjne,
int - organizacje międzynarodowe,
edu - instytucje edukacyjne,
net - internetowe,
biz - biznesowe,
info - serwisy o charakterze informacyjnym,
gov - administracja rządowa,
mil - wojsko,
org - inne organizacje,
name – nazewnicze indywidualne,
pro – zawodowe,
arpa - specjalna domena do wiązania adresów IP z nazwami.

Ponieważ na samym początku sieć Internet swym zasięgiem obejmowała tylko USA, przyjęty system nadawania nazw nie odzwierciedlał podziałów terytorialnych państw. Dlatego też gdy Internet stał się na tyle popularny i na tyle dostępny dla reszty świata rozszerzono nazewnictwo domen o dwuliterowe kody krajów (większość z nich odpowiada kodom krajów ze standardu ISO 3166-1). Kody te łączy się z wymienionymi powyżej nazwami domen (np. .com.pl) ale oprócz tego można je używać bezpośrednio po znaku „.” (np. samo .pl).

Tak więc jak już wspomniano w systemie DNS przyjęto hierarchiczny układ domen co oznacza, że przykładowe domeny org czy net są poddomenami domeny głównej, zaś domena firma.com jest poddomeną domeny com. Hierarchię tę najczęściej odnosi się do drzewa w którym to gałęzie są kolejnymi poziomami hierarchii zaś liście to nazwy konkretnych maszyn. Taki sposób podejścia do sprawy ma swoje konsekwencję gdyż, przyjęty system nadawania nazw najczęściej odzwierciedla strukturę podmiotów (firmy komercyjne, uczelnie, jednostki administracji rządowej) i chyba co najważniejsze zapewnia autonomię w zarządzaniu i administrowaniu nazwami dostępnymi w ramach pojedynczej domeny.

Nazwę domeny (czytamy od lewej do prawej strony) tworzą nazwy kolejnych domen, które są wyżej w hierarchii. Wracając do naszej analogii z drzewem idziemy od liścia poprzez kolejne gałęzie aż do korzenia. Nazwy poszczególnych domen są od siebie oddzielone kropką. Pełna nazwa komputera posiada zaś dodatkowo na początku identyfikator komputera. Na przykład, komputer o identyfikatorze komp02 w domenie abc.com ma nazwę komp02.abc.com.

Każda domena posiada swój serwer, który odpowiada za rozwiązywanie nazw w zdefiniowanej przestrzeni nazw przy czym kilka domen może być obsługiwanych przez jeden serwer (oczywiście możliwy jest również scenariusz w którym za obsługę klientów w danej strefie odpowiada kilka serwerów DNS). Każdy serwer DNS jest obsługiwany przez administratora, który najczęściej jest właścicielem danej domeny. Tak więc utworzenie własnej domeny (a mówiąc szczegółowo poddomeny) sprowadza się do zarejestrowania jej u właściciela domeny stojącego w hierarchii wyżej (rejestracja najczęściej wiąże się z uiszczeniem pewnej kwoty). Administrując daną domeną mamy swobodę w tworzeniu domen potomnych czyli subdomen. Serwer obsługujący domenę musi znać adresy serwerów DNS odpowiedzialnych za funkcjonowanie wszystkich jej poddomen.

Przykładowo, chcąc utworzyć nową domenę abc w domenie com, fakt ten należy zgłosić do administratora domeny com. Po rejestracji domeny abc.com adres IP serwera DNS odpowiedzialny za rozwiązywanie nazw w tej strefie zostaje zapisany na serwerze domeny com.

W systemie DNS możemy wyróżnić trzy podstawowe składniki, które odpowiadają za funkcjonowanie całego mechanizmu:

zdefiniowana przestrzeń nazw domen i związane z nią typy rekordów zasobów - rozproszona baza nazw i skojarzonych z nią adresów IP,

strefy nazw DNS - serwery, które odpowiadają za funkcjonowanie domeny a których zadaniem jest kontrolowanie domeny (przechowywanie rekordów i zasobów związanych z obsługiwaną strefą) oraz udzielania odpowiedzi na kwerendy (zapytania) pochodzące od klientów DNS. W systemie DNS wyróżnić możemy dwa główne typy serwerów:

serwery domeny głównej (ang. root servers) - są to serwery obsługujące domeny najwyższego poziomu (TLD – top level domains) - znajdują się one na samym szczycie hierarchii modelu. Aktualnie na świecie funkcjonuje 13 serwerów domeny głównej. Serwery te określane są również jako root-servers, nazwy ich zostały zdefiniowane od a.root-servers.net do m.root-servers.net.

Nazwa hosta	Adres IPv4/IPv6	Zarządca
a.root-servers.net	198.41.0.4, 2001:503:ba3e::2:30	VeriSign, Inc.
b.root-servers.net	192.228.79.201, 2001:500:84::b	University of Southern California (ISI)
c.root-servers.net	192.33.4.12, 2001:500:2::c	Cogent Communications
d.root-servers.net	199.7.91.13, 2001:500:2d::d	University of Maryland
e.root-servers.net	192.203.230.10, 2001:500:a8::e	NASA (Ames Research Center)
f.root-servers.net	192.5.5.241, 2001:500:2f::f	Internet Systems Consortium, Inc.
g.root-servers.net	192.112.36.4, 2001:500:12::d0d	US Department of Defense (NIC)
h.root-servers.net	198.97.190.53, 2001:500:1::53	US Army (Research Lab)
i.root-servers.net	192.36.148.17, 2001:7fe::53	Netnod
j.root-servers.net	192.58.128.30, 2001:503:c27::2:30	VeriSign, Inc.
k.root-servers.net	193.0.14.129, 2001:7fd::1	RIPE NCC
l.root-servers.net	199.7.83.42, 2001:500:9f::42	ICANN
m.root-servers.net	202.12.27.33, 2001:dc3::35	WIDE Project

Ponieważ główne serwery DNS są podstawą działania Internetu i obsługują ogromną ilość zapytań pochodzących od klientów tak więc aby przyspieszyć działanie całego systemu zostały one skopiowane. Kopie głównych serwerów zostały rozmieszczone po całym świecie (posiadają te same adresy IP co serwery główne). Użytkownicy z reguły łączą się z najbliższym im serwerem. Aktualne rozmieszczenie serwerów DNS poznasz odwiedzając tą stronę: http://www.root-servers.org/

serwery autorytatywne (ang. authoritative servers) - są to serwery obsługujące daną domenę/strefę to one przechowują informację na temat rekordów znajdujących się w zarządzanej przez siebie strefie. Ponieważ usługa DNS jest usługą kluczową bez której dostęp do sieci jest znacznie utrudniony (ale nie niemożliwy) dobrą praktyką jest aby za obsługę każdej domeny odpowiadały dwa serwery DNS (zabezpieczenie w przypadku awarii jednego z serwerów).

klienci - aplikacje, które łączą się z serwerem DNS celem uzyskania informacji o przechowywanych zasobach serwera DNS.

Odpytanie serwera DNS ma na celu uzyskanie informacji na temat adresu IP poszukiwanego hosta (w przykładach przedstawionych poniżej szukamy adresu IP komputera komp02.abc.pl).

Serwer DNS aby wykonać odwzorowanie nazwa domenowa = adres IP może do tego celu wykorzystać dwa rodzaje zapytań DNS – iteracyjne oraz rekurencyjne. Zasadę działania zapytania iteracyjnego ilustruje poniższy rysunek:

Jeśli dany klient nie posiada odwzorowania buduje zapytanie, które następnie wysyła do serwera DNS (w jednym komunikacie do serwera może być wiele zapytań) - Jaki jest adres IP komputera o nazwie komp02.abc.com?
Lokalny serwer DNS również nie potrafi odpowiedzieć na pytanie hosta komp01.opole.firma.pl dlatego zapytanie o adres poszukiwanego hosta wysyła w kierunku serwera root - Jaki jest adres IP komputera o nazwie komp02.abc.com?
Serwer root odpowiada - Nie wiem, ale zapytaj serwer DNS odpowiedzialny za obsługę domeny com.
Zapytanie zostaje wysłane w kierunku serwera DNS com - Jaki jest adres IP komputera o nazwie komp02.abc.com?
Serwer com odpowiada - Nie wiem, ale zapytaj serwer domeny abc.com.
Zapytanie zostaje wysłane w kierunku serwera DNS abc.com - Jaki jest adres IP komputera o nazwie komp02.abc.com?
Serwer abc.com odsyła odpowiedź - Adres IP komputera komp02.abc.com to 1.2.3.4
Serwer DNS odsyła odpowiedź klientowi - Adres IP komputera komp02.abc.com to 1.2.3.4

W tym modelu lokalny serwer DNS w imieniu klienta odpytuje wszystkie serwery DNS wysyłając zapytania do innych serwerów DNS tak długo aż uzyska odpowiedź na poszukiwane pytanie. Uzyskana odpowiedź zostaje odesłana klientowi, który pytanie zadał.

Zasada działania zapytania rekurencyjnego została przedstawiona poniżej:

Host chcąc poznać adres komputera komp02.abc.com wysyła zapytanie do lokalnego serwera DNS - Jaki jest adres IP komputera o nazwie komp02.abc.com?
Serwer DNS na tak postawione pytanie nie może udzielić odpowiedzi dlatego zapytanie zostaje powielone i wysłane do kolejnego serwera DNS będącego wyżej w hierarchii.
Serwer DNS do którego trafia zapytanie również nie jest w stanie udzielić odpowiedzi. Komunikat zostaje przesłany do kolejnego serwera DNS.
Powielony komunikat zostaje przekazany do serwera root.
Serwer root nie może udzielić odpowiedzi. Ponieważ poszukiwany adres IP znajduje się w domenie com - w kroku następnym zapytanie zostaje skierowane do niego.
Główny serwer DNS obsługujący przestrzeń nazw domen com nie zna odpowiedzi - pytanie zostaje wysłane w kierunku serwera DNS abc.com
Ponieważ poszukiwany host należy do domeny abc.com serwer DNS obsługujący tę strefę w swojej bazie odnajduje adres IP poszukiwanego hosta. Adres IP komputera komp02.abc.com to 1.2.3.4
Odpowiedź zostaje przekazana do serwera DNS strefy com. - Adres IP komputera komp02.abc.com to 1.2.3.4
Serwer DNS informację przekazuje dalej - Adres IP komputera komp02.abc.com to 1.2.3.4
Serwer DNS informację przekazuje dalej - Adres IP komputera komp02.abc.com to 1.2.3.4
Serwer DNS informację przekazuje dalej - Adres IP komputera komp02.abc.com to 1.2.3.4
Lokalny serwer DNS odsyła odpowiedź do hosta, który wysłał zapytanie - Adres IP komputera komp02.abc.com to 1.2.3.4 Host poznaje adres IP komputera komp02.abc.com - rozpoczyna się wymiana danych pomiędzy nimi.

Przedstawione schematy ukazują jedynie koncepcję zapytań prowadzonych przez serwery DNS, gdyż w rzeczywistości serwery DNS potrafią w celu wykonania odwzorowywania łączyć obydwa rodzaje zapytań.

System DNS oprócz odpytania serwera pod kątem dopasowania nazwy komputera z jego adresem IP umożliwia wykonywanie zapytań odwrotnych, znajdujących nazwę komputera o znanym adresie IP.

Komunikaty DNS używane podczas wymiany informacji (zapytania, odpowiedzi, transfer strefy) mają ściśle ustalony format. Przykład takiego komunikatu został pokazany na rysunku poniżej.

W pakiecie DNS można wyróżnić następujące pola:

Identyfikator DNS - dane zawarte w tym polu są określone przez klienta i zwracane do niego w niezmienionej formie. Pole te umożliwia powiązanie zapytania DNS z odpowiedzią na nie.

Żądanie/odpowiedź (QR) - pole określa rodzaj pakietu: żądanie (wartość 0) lub odpowiedź DNS (wartość 1).

Kod operacji (OpCODE) - pole definiuje typ użytego zapytania zawartego w pakiecie. Wartość pola przyjmuje 0 podczas wysyłania standardowego zapytania bądź odpowiedzi na to zapytanie. Wartości od 1 do 3 są nieużywane natomiast 4 oznacza powiadomienie zaś 5 aktualizacja.

Odpowiedź autorytatywna (AA) - odpowiedź pochodzi z autorytatywnego serwera nazw a nie z bufora.

Obcięcie (TC) - ustawienie bitu tego pola oznacza skrócenie odpowiedzi ze względu na przekroczenie rozmiaru datagramu - informacja zajmuje więcej niż 512 bajtów (dotyczy protokołu UDP).

Żądanie rekurencji (RD) - ustawienie bitu w zapytaniu, wskazuje, że klient DNS żąda wykonania zapytania rekurencyjnego w sytuacji w której serwer DNS nie będzie zawierał żądanych informacji. Brak ustawienia bitu i brak możliwości odesłania odpowiedzi przez serwer powoduje wysłanie listy innych serwerów nazw, które mogą zostać użyte w procesie odwzorowywania. Gdy klient otrzyma taka odpowiedź może wykorzystać otrzymane informację w celu budowania kolejnych zapytań.

Rekurencja jest dostępna (RA) - znacznik ustawiony w odpowiedzi informuje o możliwości wykorzystania przez serwer zapytań rekurencyjnych.

Zarezerwowane (Z) - pole przyjmuje wartość 0, pole przeznaczone do wykorzystania w przyszłości.

Dane autentyczne (AD) - ustawiona wartość 1 oznacza uwierzytelnienie przekazywanych informacji.

Sprawdzanie wyłączone (CD) - wyłączenie mechanizmu weryfikacji zabezpieczeń.

Kod odpowiedzi (RCode) - pole wykorzystywane w celu wskazania istnienia ewentualnych błędów. Najczęstsze wartości jakie może przyjąć to pole zostały przedstawione poniżej:

0 - NoError - brak błędu,

1 - FormErr - interpretacja zapytania zakończona niepowodzeniem,

2 - ServFail - błąd po stronie serwera, niepowodzenie w procesie przetwarzanie zapytania,

3 - NXDomain - wskazana domena nie istnieje,

4 - NotImp - typ żądania nieobsługiwane przez serwer,

5 - Refused - żądanie odrzucone, brak wysłania odpowiedzi,

9 - NotAuth - brak autoryzacji serwera w strefie,

10 - NotZone - nazwa nie należy do strefy.

Liczba zapytań (QDCOUNT) - liczba wpisów w sekcji zapytań.

Liczba odpowiedzi (ANCOUNT) - liczba rekordów w sekcji odpowiedzi.

Liczba rekordów serwera (NSCOUNT) - liczba rekordów zasobów w sekcji autorytatywnej.

Liczba rekordów dodatkowych (ARCOUNT) - liczba rekordów, które pochodzą z innych źródeł.

Dynamiczne aktualizacje DNS (ang. DNS Update) przenoszą pola o nazwach ZOCOUNT, PRCOUNT, UPCOUNT oraz ADCOUNT.

Sekcja zapytań - sekcja zawierająca zapytanie (sekcja o zmiennej wielkości).

Sekcja odpowiedzi - sekcja zawierająca rekordy danych będący odpowiedzią na otrzymane przez serwer zapytania (sekcja o zmiennej wielkości).

Sekcja autorytatywna - informacja o innych autorytatywnych serwerach, które mogą być wykorzystane w procesie określania nazw (sekcja o zmiennej wielkości).

Sekcja informacji dodatkowych - informacje dodatkowe związane z otrzymanymi zapytaniami.

Wymiana pakietów w komunikacji DNS odbywa się z wykorzystaniem protokołu UDP (standardowe zapytania) ale także protokołu TCP (wymiana informacji pomiędzy serwerami DNS tzw. transfer strefy). W obu przypadkach wykorzystywany jest port o numerze 53.

Datagram UDP/IPv4 (ten najczęściej wykorzystywany) został pokazany na rysunku poniżej.

Jeśli w danej strefie obsługa zapytań jest realizowana przez dwa serwery DNS komunikacji pomiędzy nimi odbywa się z wykorzystaniem protokołu TCP raz ze względu na ilość przesyłanych danych a dwa, że konieczne jest zachowanie pewności przesyłu tych danych. Transfer strefy pomiędzy serwerami DNS jest wykonywany w celu synchronizacji danych tak by oba serwery nazw obsługujące strefę posiadały jednolite dane.

Do tematu jeszcze powrócimy gdy zaczniemy analizować przechwycone pakiety.

Rekordy zasobów DNS zawierają informacje związane z domeną i mogą być pobierane oraz wykorzystywane przez klientów DNS. Każdy serwer DNS obsługuje te rekordy przestrzeni nazw DNS, które są dla niego autorytatywne. Każdy administrator systemu DNS odpowiedzialny jest za poprawność informacji zawartych, w strefie którą zarządza.

W wspomnianych dokumentach RFC 1034 i 1035 oraz późniejszych został określone możliwe do przechowywania typy zasobów. Większość typów rekordów praktycznie nie jest wykorzystywana choć nadal w pełni wspierana. Do tych najważniejszych rekordów można zaliczyć następujące:

rekord A lub rekord adresu IPv4 (ang. address record) mapuje nazwę domeny DNS na jej 32-bitowy adres IPv4. Jest rekordem wyszukiwania w przód.

rekord AAAA lub rekord adresu IPv6 (ang. IPv6 address record) mapuje nazwę domeny DNS na jej 128 bitowy adres IPv6. Rekord AAAA podobnie jak rekord A jest rekordem wyszukiwania w przód.

rekord CNAME lub rekord nazwy kanonicznej (ang. canonical name record) ustanawia alias nazwy domeny czyli pozwala na użycie kilku rekordów zasobów odnoszących się do jednego hosta.

rekord MX lub rekord wymiany poczty (ang. mail exchange record) mapuje nazwę domeny DNS na nazwę serwera mailowego, obsługującego pocztę dla danej domeny. Rekordów MX w danej strefie może być kilka, różnią się one priorytetem. W pierwszej kolejności wybierane są te z niższym priorytetem - serwer z wyższym priorytetem jest wybierany w sytuacji w której serwer do którego został przypisany priorytet niższy nie działa.

rekord PTR lub rekord wskaźnika (ang. pointer record) mapuje adres IPv4 na nazwę kanoniczną hosta. Rekord PTR w przeciwieństwie do np. rekordów typu A bądź AAAA jest rekordem wyszukiwania wstecznego, który łączy adres IP z nazwę hosta. Rekordy PTR mogą mieć postać adresów IPv4 lub IPv6.

rekord NS lub rekord serwera nazw (ang. name server record) mapuje oraz identyfikuje serwer DNS autorytatywny dla danej domeny.

rekord SOA (ang. start of authority record) ustala serwer DNS dostarczający autorytatywne informacje o domenie internetowej (adresy serwerów nazw, parametry czasowe transferu stref czy numer konfiguracji).

rekord SRV lub rekord usługi (ang. service record) pozwala na zawarcie dodatkowych informacji dotyczących lokalizacji danej usługi, którą udostępnia serwer wskazywany przez adres DNS.

TXT - rekord ten pozwala dołączyć dowolny tekst do rekordu DNS.

Proces rozpoznawania nazw przez klienta DNS schematycznie został przedstawiony na rysunku poniżej.

Jak można zauważyć w pierwszym kroku klient poszukiwaną informację próbuje zdobyć sam. W tym celu sięga do informacji zapisanych w pliku HOSTS, którego zawartość jest kopiowana do pamięci podręcznej.

Plik HOSTS jest plikiem tekstowym zawierającym w każdej linii adres IP i jedną lub więcej nazw domenowych danego hosta (oddzielone od siebie spacjami lub tabulatorami). W systemie Windows lokalizacja tego pliku jest następująca: %SystemRoot%\system32\drivers\etc\hosts Przykładowy plik HOSTS został pokazany na rysunku poniżej.

W pamięci podręcznej również znajdują się rozwiązane kwerendy DNS uzyskane w odpowiedziach na poprzednie zapytania. Jeśli poszukiwana nazwa hosta zostaje skojarzona z adresem IP cały proces się kończy.

W czasie procesu rekursji lub iteracji serwery DNS przetwarzają kwerendy w imieniu klientów i równocześnie gromadzą zdobyte informacje o przetwarzanym obszarze nazw DNS. Te informacje w kolejnym kroku umieszczane są w pamięci podręcznej celem późniejszego wykorzystania.

Dzięki zapisu informacji o rozwiązanych kwerendach serwer/host w przypadku wystąpienia ponownego zapytania, które miało miejsce wcześniej nie musi wykonywać procesu rozwiązywania nazwy, gdyż potrzebna informacja jest już dla niego dostępna. Głównym zadaniem użycia bufora jest więc zmniejszenie ruchu w sieci związanego z mechanizmem DNS.

Kiedy informacja trafia do bufora jest jej przypisywana wartość czasu wygaśnięcia (TTL). Dopóki nie upłynie czas TTL buforowanych kwerend, dany serwer DNS może ponownie wykorzystywać zapisane rekordy do udzielania odpowiedzi klientom na przysyłane przez klientów zapytania odpowiadające tym rekordom.

W sytuacji kiedy host w sposób lokalny nie potrafi znaleźć nazwy hosta proces rozwiązywania jest kontynuowany przez klienta poprzez wysłanie zapytania do serwera DNS. Po otrzymaniu pytania serwer DNS podobnie jak klient w pierwszej kolejności sprawdza czy może na nie odpowiedzieć na podstawie informacji zawartych w swoim lokalnym buforze jeśli tak do klienta jest odsyłana odpowiedź.

Jeśli nazwa poszukiwanego hosta jest zgodna z rekordem zasobu zarządzanej strefy (bądź stref), serwer odpowiada autorytatywnie, wykorzystując informacje uzyskane z zasobów strefy.

Serwer DNS, który posiada pełną informację o przestrzeni nazw DNS jest określany mianem serwera autoratywnego dla tej części przestrzeni nazw i to on jest podstawowym magazynem strefy. Strefa zaś zawiera rekordy zasobów, które mogą należeć do jednej lub więcej domen DNS.

Jeśli wszystkie przedstawione wyżej sposoby rozwiązania nazwy (brak informacji w buforze hosta, serwera DNS oraz wśród informacji strefy), okażą się nieskuteczne proces wykonywania kwerendy jest kontynuowany z wykorzystaniem zewnętrznych serwerów DNS (użycie zapytań DNS – iteracyjne oraz rekurencyjne).

Wyróżnić możemy cztery typy stref DNS (w niektórych źródłach znajdziesz informację o trzech):

Strefa podstawowa - strefa tego typu jest niezbędna do funkcjonowania mechanizmu DNS oraz do prawidłowego rozpoznania nazw domen. Przechowuje ona główną kopię strefy i informacje w niej zawarte mogą być replikowane do stref pomocniczych. Strefa podstawowa jest zapisana na serwerze DNS, który jest serwerem autorytatywnym dla strefy.

Strefa pomocnicza - zawiera kopię tylko do odczytu informacji o strefie, czyli obejmuje ona wszystkie informacje zawarte w strefie podstawowej. Informacje w niej zapisane są uzyskiwane za pomocą replikacji z wykorzystaniem mechanizmu transferu strefy. Wykorzystanie stref tego typu zwiększa wydajność (zapytania rozkładają się pomiędzy.

Strefa skrótowa (czasem też zwana strefą wejściową) zawiera jedynie informacje o rekordach zasobów (SOA, NS), które są niezbędne do zidentyfikowania autorytatywnych serwerów DNS. Strefy tego typu wskazują, gdzie można znaleźć pełną informację o strefie.

Zintegrowana z Active Directory - ten typ strefy tak naprawdę jest strefą podstawową tylko w przeciwieństwie do tradycyjnej strefy podstawowej, która jest przechowywana w pliku lokalnym jest ona wykorzystywana w środowisku opartym o usługę Active Directory a jej replikacja jest wykonywana przy wykorzystaniu mechanizmów tej usługi.

Część teoretyczną z grubsza mamy omówioną choć celem uzupełnienia do pewnych zagadnień wrócimy.

Topologia naszej ćwiczebnej sieci w oparciu o którą zostaną omówione pakiety DNS została zaprezentowana na schemacie poniżej:

Polecenie poniżej zostało wydane na komputerze XXX i jak widać w cachu znajduje się tylko jeden wpis wiążący nazwę WinServ2012A z adresem IP 10.0.0.10 (bufor pamięci DNS zawierający odwzorowania nazw domenowych i odpowiadających im adresów IP poznamy wydając polecenie: ipconfig /displaydns).

Prześledźmy zatem wymianę pakietów DNS jaka zachodzi w przypadku rozwiązywania nazw. Z hosta XXX wykonamy test ping w kierunku hosta YYY. Komputer nie zna adresu IP hosta YYY tak więc w pierwszej kolejności zostanie przeprowadzona komunikacja z serwerem DNS w celu ustalenia adresu IP komputera YYY.

Jak już wiesz Czytelniku cała funkcjonalność systemu DNS opiera się na modelu zapytania i odpowiedzi. Host, który chce dokonać powiązania danego adresu IP z jego nazwą domenową buduje i wysyła do serwera DNS zapytanie, zaś zadaniem serwera DNS jest znalezienie odpowiedzi na pytanie hosta i jej odesłanie.

Proces powiązania adresu IP z nazwą hosta może wymagać wysłania wielu pakietów lecz w najprostszej postaci wystarczą dwa. Prześledźmy zatem jak wygląda wymiana pakietów pomiędzy komputerami właśnie w tej najprostszej sytuacji.

Na rysunku poniżej przedstawiono przechwycony pakiet z zapytaniem DNS, które zostało wysłane przez hosta XXX o adresie 172.16.10 do serwera o adresie 10.0.0.10 (punkt 1). Przedstawiony pakiet jest zapytaniem DNS a do jego wysłania został użyty protokół UDP w powiązaniu z portem o numerze 53 (domyślny port usługi DNS) - punkt 2.

Pakiet jest pojedynczym zapytaniem wysłanym w celu identyfikacji adresu IP hosta yyy.firma.local (ponieważ komputery są częścią domeny firma.local człon ten został dodany automatycznie). Zapytanie dotyczy adresu internetowego (IN) komputera (A) - punkt 3.

Odpowiedź na pytanie hosta została zaprezentowana na rysunku poniżej. Ponieważ oba komputery są w jednej wspólnej domenie serwer DNS nie musi odpytywać innych serwerów celem ustalenia adresu IP hosta YYY gdyż informację ta znajduje się w jego bazie (rekurencja w tym przypadku nie jest wykorzystywana). Odpowiedź zostaje udzielona hostowi - punkt 1. Rodzi się pytanie - Skąd wiemy, że przedstawiony pakiet jest odpowiedzią na zapytanie klienta? Łatwo to zweryfikować i łatwo powiązać zapytanie z odpowiedzią gdyż pakiet ten ma taki sam identyfikator jak zapytanie (w naszym scenariuszu 0x4c04) - porównując identyfikatory pakietów łatwo powiążemy pakiety zapytań z odpowiedziami na nie - punkt 2. Informacja o tym, że pakiet jest odpowiedzią możemy zweryfikować również po rozwinięciu sekcji Flags - punkt 3. Dodatkowa weryfikacja może nastąpić po analizie danych umieszczonych w sekcji Answers gdyż przedstawiony pakiet budowany jest w ten sposób, że zawiera on informację o otrzymanym zapytaniu jak i udzielonej odpowiedzi. Adres IP komputera YYY to 172.16.0.11 Host XXX uzyskując informację o adresie IP hosta YYY może rozpocząć z nim komunikację.

W kolejnym przykładzie nadal będziemy bazować na pytaniu i odpowiedzi w ramach jednej domeny lecz przyjrzymy się sytuacji w której serwer DNS nie znajduje odpowiedzi na pytanie klienta.

Przesłane zapytanie w budowie nie różni się od pakietu przedstawionego w poprzednim przykładzie. Jest tylko mała różnica - szukamy adresu IP hosta o nazwie AAA. Host taki oczywiście w naszej sieci nie istnieje.

Ponieważ nazwa szukanego hosta jest obsługiwana przez serwer DNS WinServ2012A, to tylko on jest władny by udzielić informację o adresie IP poszukiwanego komputera. Serwer DNS odsyła pakiet o nie odnalezieniu dopasowania.

Wydając na hoście XXX ponownie polecenie: ipconfig /displaydns możemy przejrzeć lokalny cache DNS hosta. Jak widać zostały w nim zapisane oba odwzorowania (jedno mapujące nazwę hosta YYY z adresem IP 172.16.0.11 oraz drugie informujące, że host o nazwie AAA nie istnieje) o które host ten pytał.

Urozmaicamy trochę Naszą sytuację i sprawdźmy jak przebiegnie wymiana komunikatów w sytuacji w której poszukiwany adres IP hosta będzie znajdował się w Internecie. Odpytajmy serwer DNS o adres IP hosta google.pl

Do tej pory hosty mogły prowadzić tylko komunikację w ramach sieci LAN, zmieniamy trochę naszą topologię i hosty uzyskują dostęp do Internetu. Zostaje skonfigurowane łącze pomiędzy routerem a dostawcą Internetu. Konfiguracja routera oczywiście musi ulec modyfikacji (zostaje skonfigurowana zerowa trasa statyczna tak by wszystkie pakiety, które nie znajdują dopasowania mogły zostać nią przesłane oraz NAT) oraz serwer DNS zostaje skonfigurowany w ten sposób by zapytania DNS na które nie znajduje odpowiedzi przesyłał dalej (jak taką konfigurację wykonać opiszę w wpisie, który będzie poświęcony mechanizmowi DNS w kontekście Windows Server 2012). Serwerem DNS do którego będą trafiać zapytania to ogólnodostępny serwer DNS Google czyli host o adresie IP 8.8.8.8 Hostem zadającym pytanie jest komputer YYY.

Od hosta YYY (IP 172.16.0.11) do serwera DNS (IP 10.0.0.10) trafia zapytanie - Jaki jest adres IP hosta google.pl? (punkt 1). Serwer DNS na tak postawione pytanie nie zna odpowiedzi gdyż poszukiwany host nie znajduje się w zarządzanej przez niego domenie. Zapytanie musi być przesłane do zewnętrznego serwera DNS a ponieważ możliwe jest wykonanie rekurencji (punkt 2) pakiet z pytaniem zostaje wysłany do serwera DNS o adresie 8.8.8.8

Identyfikator pakietu przyjmuje wartość 0xa238 (punkt 3).

Zrzut poniżej przedstawia przechwycony pakiet w komunikacji pomiędzy hostami 172.16.0.11 a 10.0.0.10

Tak jak napisałem wyżej celem dokonania mapowania pakiet opuszcza lokalny serwer DNS i zostaje przekazany w kierunku zewnętrznego serwera DNS - punkt 1. Pakiet ten zawiera pytanie zadane przez hosta YYY - punkt 2.

Identyfikatorem pakietu jest wartość: 0x14de - punkt 3.

Zrzut poniżej przedstawia przechwycony pakiet w komunikacji pomiędzy hostami 10.0.0.10 a 8.8.8.8

Ponieważ odpytywany serwer DNS należy do Google (punkt 1) a pytanie dotyczy hosta znajdującego się w tej domenie zostaje udzielona odpowiedź w postaci adresu IP poszukiwanego komputera (punkt 2). Pakiet jest odpowiedzią na wcześniejsze żądanie gdyż pakiet wysłanego zapytania i udzielonej odpowiedzi zawierają ten sam identyfikator (punkt 3).

Lokalny serwer DNS zna już odpowiedź na pytanie hosta YYY tak więc udziela mu odpowiedzi (punkt 1) w postaci poszukiwanego adresu IP (punkt 2). I tak samo jak poprzednio pakiet pytania i odesłanej odpowiedzi powiążemy ze sobą za pomocą identyfikatora transakcji (punkt 3).

Mam nadzieję, że przedstawione powyżej przykłady w dość jasny sposób tłumaczą wymianę pakietów jaka jest prowadzona w ramach mechanizmu DNS.

Strefa DNS to przestrzeń nazw, którą może zarządzać jeden z serwerów DNS jednak w celu zapewnienia redundancji i wyeliminowania sytuacji w której serwer DNS na wskutek awarii jest nieosiągalny stosuje się zapasowy serwer DNS, który zawiera pełną kopię informacji danej strefy (kopia serwera głównego). Zastosowanie drugiego serwera ma jeszcze jedną zaletę gdyż ruch związany z zapytaniami jest rozkładany pomiędzy nimi. Aby kopie na obu serwerach były spójne i synchronizowane pomiędzy serwerami następuje tzw. transfer strefy DNS.

Przyrostowy transfer strefy (IXFR) - pomiędzy serwerami DNS zostaje przesłana tylko część informacji, która uległa zmianie bądź modyfikacji.

Pełny transfer strefy (AXFR) - pomiędzy serwerami DNS następuje przesłanie całej strefy.

Aby przeanalizować jak pełny transfer strefy przebiega w praktyce należy zmodyfikować naszą topologię sieciową - dodajemy do niej dodatkowy serwer DNS WinServ2012B.

Host YYY (IP 172.16.0.11) posłuży Nam w celu zbadania przebiegu przyrostowego transferu strefy.

Przykład przedstawiający pełny transfer strefy pomiędzy komputerami o adresach IP 10.0.0.10 o 10.0.0.11 został przedstawiony poniżej.

Na hoście WinServ2012B została dodana rola serwera DNS (sposób konfiguracji w kontekście Windows Server zostanie opisany w oddzielnym wpisie), po jej instalacji komputer zostaje włączony w strukturę istniejącej sieci. Ponieważ dodany host pełni rolę zapasowego serwera DNS przy podłączaniu następuje proces pełnego transferu strefy z serwera głównego.

Analizując powyższy zrzut pierwsza rzecz, która powinna przykuć Twoją uwagę Czytelniku jest użyty protokół warstwy transportowej - nie jest to jak było do tej pory protokół UDP lecz TCP. Waga przesyłanych informacji jest zbyt ważna by zadanie to powierzyć protokołowi UDP (brak mechanizmów gwarantujących 100% pewność przesłanych danych) dlatego też proces transferu strefy odbywa się z wykorzystaniem protokołu TCP, który pomimo większego narzutu przesyłanych danych gwarantuje Nam pewność i niezawodność ich dostarczenia (punkt 1).

Żądanie pełnego transferu strefy DNS to tak naprawdę standardowe zapytanie kierowane ku serwerowi DNS, ale zamiast prośby o rozwiązanie nazwy pojedynczego rekordu klient żąda otrzymanie wszystkich informacji dotyczących zarządzaną strefą. Serwer DNS otrzymuje rekord typu AXFR - punkt 2.

Główny serwer DNS po otrzymaniu żądania transferu strefy odsyła stosowane informacje w kierunku klienta (punkt 1).

Proces pełnego transferu strefy powoduje przekazanie informacji o wszystkich rekordach w ramach zarządzanej strefy DNS - punkt 2. Zapasowy serwer DNS posiada informację o całej strefie. W razie awarii serwera głównego host może przejąć jego rolę.

Po zakończeniu całej wymiany informacji następuje eleganckie zakończenie sesji TCP (patrz pakiety od 142 do 145) - jeśli sposób działania protokołu TCP jest Ci obcy zapraszam do zapoznania się z wpisem: Co w sieci siedzi. Skanowanie portów.

Przeglądając powyższe dane, które zostały dostarczone zapasowemu serwerowi DNS (nie było ich wiele, gdyż nasza strefa nie jest duża) szybko można dojść do wniosku (a nawet trzeba), że waga przesłanych informacji dla atakującego naszą sieć będzie stanowić prawdziwą kopalnię złota gdyż dzięki ich analizie można utworzyć mapę całej infrastruktury sieci. Dlatego też nie powinny dostać się one w niepowołane ręce. Sposób uzyskiwania wglądu do nich zależy od konfiguracji serwera DNS a nieprawidłowa bądź nierzetelna konfiguracja serwera może doprowadzić do sytuacji w której dostęp do informacji strefy (tak jak to zostało pokazane poniżej) będzie mógł uzyskać każdy.

W przykładzie poniżej dzięki wykorzystaniu wbudowanego w systemie Windows narzędzia nslookup i po wydaniu dwóch poleceń do hosta XXX zostaje wykonany pełny transfer sieci. Po wywołaniu narzędzia domyślnym serwerem DNS jest host 10.0.0.10 (serwer ten został zdefiniowany w ustawieniach karty sieciowej) - punkt 1.

Za pomocą polecenia: set type=any ustalamy zakres interesujących nas rekordów - punkt 2.

Komenda: ls -d <nazwa_domeny> nakazuje przesłanie kopii strefy.

Poniżej zaprezentowano zrzut wymiany pakietów pomiędzy serwerem DNS (IP 10.0.0.10) a hostem XXX (IP 172.16.0.10). Jak widać przedstawiony pakiet odzwierciedla informację uzyskane dzięki narzędziu nslookup.

Przyrostowy transfer stref jest dodatkową funkcją protokołu DNS związaną z replikowaniem stref DNS. Głównym założeniem przyświecającym przy opracowywaniu tego standardu było zmniejszenie obciążeń łączy podczas prowadzonego procesu aktualizacji stref. Przed wprowadzeniem tego mechanizmu każda aktualizacja danych związana z przesłaniem rekordów bazy danej strefy wymagała wykonanie procesu pełnego transferu całej strefy (użycie w pakiecie flagi AXFR). W sytuacji, w której wykorzystywany jest przyrostowy transfer strefy (użycie w pakiecie flagi IXFR) serwer, który żąda przesłania informacji wykonuje kopię tych zmian strefy, które są niezbędne do synchronizacji jego kopii strefy ze źródłem. Przebieg procesu przyrostowego transferu strefy został przedstawiony poniżej (komunikacja pomiędzy dwoma serwerami DNS o adresach IP 10.0.0.11 oraz 10.0.0.10).

Jak już wspomniałem w naszej ćwiczebnej topologii znajduje się host YYY (IP 172.16.0.11), rekord typu A łączący nazwę hosta YYY z adresem IP został utworzony na serwerze 10.0.0.10.

Pomiędzy serwerami DNS (punkt 1) dochodzi do transferu strefy lecz w odróżnieniu od poprzedniej wymiany danych transfer ten jest wykonywany po przesłaniu pakietu z ustawioną flagą IXFR (punkt 2) nakazując tym samym przesłanie nowych rekordów bądź tych, które zostały poddane modyfikacji.

W kolejnym pakiecie serwer DNS 10.0.0.10 (punkt 1) przesyła aktualizację strefy i jak widać poniżej znajduje się w nim informacja tylko o hoście YYY (punkt 2).

W tym wpisie starałem się przedstawić najważniejsze informację związane z działanie mechanizmu DNS. Wiesz już, jak przebiega proces rozpoznawania nazw w sieciach opartych o protokół TCP/IP oraz jak ważnym dla sprawnego funkcjonowania całego Internetu jest spójny mechanizm zarządzania nazwami komputerów i usług. W kolejnym wpisie temat rozwiniemy i zajmiemy się konfiguracją protokołu DNS w systemie Windows Server 2012.

Atak na warstwę 2 modelu ISO/OSI - preludium

2017-02-01T22:23:01+00:00

Switche tak jak i routery podatne są na wiele ataków dlatego też większość technik zabezpieczania routerów ma zastosowanie również do switchy. Przełączniki jednak z natury swego działania i umiejscowienia dodatkowo narażone są na wiele innych ataków, specyficznych dla tej grupy urządzeń.

Sieć komputerowa aby działać musi być w stanie obronić się przed licznymi atakami m.in. takimi jak:

spoofowanie adresów MAC,
ataki na STP,
ataki na CDP,
ataki na DHCP,
przepełnienie tablic adresów MAC,
ataki typu LAN storm,
ataki na VLAN.

W artykule tym oczywiście nie wszystkimi metodami przeprowadzania ataków się zajmiemy lecz postaram opisać te najczęściej wykorzystywane wraz z metodami ich przeciwdziałania. Tak więc w pierwszej części wpisu opis jak dany atak zorganizować i przeprowadzić zaś w drugiej części wpisu obrona przed nimi.

Artykuł ten skoncentruje się na zagrożeniach (i oczywiście sposobach ich zapobiegania) związanych z protokołem ARP, DHCP, atakiem przepełnienia tablicy adresów MAC czy atakami typu LAN storm. Zaś te bardziej wyrafinowane jak atak na sieci VLAN czy STP opiszę w osobnej osłonie.

Rozpoczynamy od opisu ataku ARP poisoning z wykorzystaniem narzędzi dostępnych w systemie Windows.

Topologia sieciowa w której przeprowadzono symulację przedstawia się następująco.

Narzędzie, które pozwoli nam na przeprowadzenie ataku to Cain&Abel. Program standardowo wykorzystywany jest do odzyskiwania haseł (bądź ich łamania) ale ma w sobie zaszyty moduł odpowiedzialny za sniffing oraz za przeprowadzanie ataku zatrucia tablicy ARP. Do działania programu niezbędne jest zainstalowanie oprogramowania WinPcap.

Po pobraniu i instalacji oprogramowania uruchamiamy narzędzie. W głównym oknie aplikacji przechodzimy do karty Sniffer (punkt 1) a następnie wybieramy ikonę interfejsu sieciowego (punkt 2).

W niektórych konfiguracjach zdarza się sytuacja w której wykorzystanie modułu sniffera uzależnione jest od wydania polecenia: netsh int ip set global taskoffload=disabled Jeśli zajdzie taka sytuacja zostaniemy powiadomieni o tym stosownym komunikatem. W razie wystąpienia opisywanego zdarzenia, należy uruchomić konsolę wiersza poleceń (z prawami administratora) i wydać wspomniane polecenie. Po wydaniu komendy ponownie uruchamiamy narzędzie Cain&Abel.

Przy pierwszym uruchomieniu sniffera pierwszą opcję jaką musimy skonfigurować to wybór użytego interfejsu. W nowo otwartym oknie Configuration Dialog na karcie Sniffer definiujemy interfejs, który będzie wykorzystywany w procesie przechwytywania pakietów oraz zatruwania tablicy ARP. Konfigurację zatwierdzamy klikając na OK.

Po zatwierdzeniu interfejsu kolejną czynnością jaką musimy wykonać jest wykonanie skanu sieci celem wykrycia aktywnych hostów. Skan przeprowadzamy wybierając ikonę plusa. Po wybraniu ikony w oknie MAC Address Scaner określamy opcje przeprowadzanego skanowania. Celem wykrycia wszystkich komputerów znajdujących się w podsieci zaznaczamy: All hosts in my subnet Jeśli chcemy zdefiniować obszar adresów IP co do których będzie przeprowadzane skanowanie wybieramy: Range a następnie określamy początkowy i końcowy adres IP.

Aby rozpocząć skan klikamy OK i rozpoczyna się proces odkrywania hostów. Lista aktywnych hostów zostanie wyświetlona w tabeli.

Po wykryciu hostów przechodzimy do zakładki APR (lewy dolny róg programu). Opcje zgromadzone na tej zakładce posłużą nam do zdefiniowania opcji ataku. Aby określić hosta co do którego będzie przeprowadzany atak należy wybrać ikonę Plusa (ikona stanie się aktywna gdy wybierzemy gałąź ARP a następnie klikniemy w obszarze górnej części tabeli). Naszym oczom powinno ukazać się nowe okno New ARP Poison Routing Okno to zostało podzielone na dwie tabele. Lewa tabela służy do wyboru adresu MAC hosta, którego ruch sieciowy chcemy przechwytywać prawa zaś odpowiedzialna jest za wybranie adresu MAC drugiego hosta, który prowadzi komunikację z celem - najczęściej jest to adres bramy (routera).

W scenariuszu założyliśmy przechwytywanie ruchu sieciowego pomiędzy hostem o adresie MAC AA-AA-AA-AA-AA-AA (ofiara) a routerem (adres MAC A0-C5-62-73-9A-50) tak więc w lewy panelu zaznaczamy adres MAC komputera ofiary zaś w prawymadres MAC routera (oczywiście możliwa jest sytuacja w której ruch sieciowy będzie przechwytywany pomiędzy dwoma hostami np. komputer-serwer). Po zdefiniowaniu hostów co do których będzie prowadzony proces przechwytywania pakietów klikamy OK.

Aby uruchomić atak wybieramy ikonę „promieniowania” - punkt 1. Status ataku pojawi się w górnej części tabeli (punkt 2) zaś informację o odbieranych pakietach znajdziemy w tabeli dolnej - punkt 3. Dodatkowo w lewej części okna przechwytywane pakiety są grupowane w zależności od typu wykrytego ruchu sieciowego (użyty protokół np. ruch związany z wykorzystaniem protokołów pocztowych).

Tablica ARP hosta została zatruta, cały ruch generowany na komputerze ofiary zostaje w pierwszej kolejności wysłany w kierunku atakującego a następnie przekazany do miejsca przeznaczenia czyli do routera.

Atak możemy obserwować analizując tablicę ARP hosta ofiary.

Gdy atak ARP poisoning nie jest uaktywniony w tablicy ARP znajdujemy prawidłowe dowiązanie bramy (routera) z jej adresem MAC.

Po uruchomieniu ataku adres MAC bramy zostaje zamieniony na adres MAC komputera przeprowadzającego atak. Atak zatrucia przeprowadzany jest z hosta o adresie MAC CC-CC-CC-CC-CC-CC tak więc w trakcie trwania ataku prawidłowy adres MAC bramy zostaje zastąpiony właśnie tym adresem.

Atak na tablicę ARP dodatkowo możemy obserwować podczas procesu przechwytywania pakietów.

Analizując pole warstwy drugiej przechwyconego pakietu o numerze 67 dochodzimy do wniosku, że wszystko jest w porządku. W pakiecie zawarte są prawidłowe informacje powiązania adresu MAC routera z jego adresem IP - punkt 1

Po przejściu do pakietu 72 można zauważyć zamianę adresu MAC routera na adres MAC komputera wykonującego atak - punkt 2.

Jednym z ciekawych narzędzi, które możemy wykorzystać w systemie Windows jest aplikacja WinArpAttacker. Narzędzie te podobnie jak opisywany powyżej program Cain&Abel umożliwia Nam przeprowadzenie ataku z wykorzystaniem protokołu ARP ale oprócz opcji ataku są również dostępne takie, które przed atakiem Nas uchronią - ale wszystko po kolei.

Aby za pomocą narzędzia przeprowadzić atak po uruchomieniu jej z prawami administratora należy w pierwszej kolejności przeprowadzić skan sieci lecz aby to zadanie wykonać warto sprawdzić czy został wybrany prawidłowy interfejs sieciowy. W przypadku posiadania jednej karty sieciowej problem Nam odpada lecz gdy system korzysta z wielu interfejsów ustawienie te należy skontrolować. Aby wybrać interfejs z menu wybieramy pozycję Options a następnie Adapter. W nowo otwartym oknie w sekcji Select a Network Device z rozwijanego menu wybieramy właściwy interfejs. Wybór oczywiście zatwierdzamy klawiszem OK.

Po ustawieniu interfejsu przechodzimy do wspomnianego skanowania sieci. Scan sieci uruchomimy wybierając z dostępnych ikon pozycję Scan. Po przeprowadzeniu operacji odkrywania hostów dostępnych w atakowanej sieci ich lista pojawi się w oknie poniżej.

Przed uruchomieniem ataku wyłączamy ochronę tablicy ARP poprzez wybranie z dostępnych ikon przycisku Stop (do tematu tego wrócimy w dalszej części wpisu poświęconej obronie przed atakiem z wykorzystaniem protokołu ARP) - punkt 1. Atak uruchomimy poprzez zaznaczenie interesującego nas hosta a następnie wybraniu ikony Attack wraz z opcją Sniff Gateway. Zaznaczenie opcji spowoduje rozpoczęcie ataku zatrucia tablicy ARP pomiędzy wybranym hostem a bramą. Aby prowadzić przechwytywanie pomiędzy dwoma wybranymi hostami z listy dostępnych hostów należy wybrać interesujące nas komputery a następnie z menu Attack wybrać opcję Sniff Hosts. Wybranie Sniff Lan spowoduje uruchomienie ataku w kontekście całej sieci LAN - co oznacza, że cały ruch sieciowy generowany przez wszystkie aktywne hosty będzie przechodził przez nasz komputer.

Atak zostaje uruchomiony a jego efekty możemy sprawdzić przeglądając tablicę ARP hosta 192.168.1.200 Jak widać poniżej (punkt 1) przed uruchomieniem ataku adres MAC bramy jest poprawnie skojarzony z jego adresem IP zaś po uruchomieniu ataku (punkt 2), adres MAC bramy wskazuje na hosta atakującego. Uruchomiony sniffer pakietów na hoście 192.168.1.210, który jest kontrolowany przez atakującego rejestruje test ping pomiędzy hostem ofiary a bramą co dowodzi, że atak zakończył się sukcesem.

Tak jak wspomniałem do programu będziemy wracać a tym czasem idziemy dalej.

O wiele więcej narzędzi do przeprowadzenia ataku opartego o protokół ARP znajdziemy w systemie Linux a gdy chcesz je mieć wszystkie z automatu wybierz dystrybucję Kali bądź Backtrack.

Topologia sieciowa użyta do opisania narzędzi pozostaje bez zmian, zmienia się system operacyjny atakującego oraz jego adres MAC z CC-CC-CC-CC-CC-CC na EE-EE-EE-EE-EE-EE. Po podłączeniu hosta pierwszą czynnością jaką powinniśmy wykonać jest wykonanie testu łączności. Test ping pomiędzy hostem atakującym (IP 192.168.1.200) jak i routerem (IP 192.168.1.1) kończy się sukcesem.

Pierwszym narzędziem (a tak właściwie trzecim) jakie wykorzystamy do przeprowadzenia ataku zatrucia tablicy ARP jest Ettercap. Jeśli go nie posiadamy to jego instalację przeprowadzimy za pomocą polecenia: apt-get install ettercap-graphical

Po instalacji narzędzie w trybie graficznym uruchamiamy poleceniem: ettercap -G (jeśli korzystamy z Linux Kali program odnajdziemy w sekcji: Sniffing @ Spoofing).

Po uruchomieniu programu w górnym menu z sekcji Sniff wybieramy opcję Unified sniffing.

W następnym kroku określamy interfejs, który zostanie użyty do przeprowadzenia ataku. W przypadku komputera posiadającego wiele kart sieciowych właściwy interfejs zidentyfikujesz wydając w konsoli polecenie: ifconfig W naszym scenariuszu został użyty

interfejs: eth0

Po wstępnej konfiguracji narzędzia przechodzimy do skanu sieci. Proces skanowania jest niezbędny gdyż jego głównym celem jest wykrycie w atakowanej sieci aktywnych hostów oraz wykonanie dopasowania adres IP - adres MAC. Aby przeprowadzić skanowanie z menu wybieramy opcję Hosts a następnie Scan for hosts.

Wybranie przedstawionych opcji spowoduje uruchomienie procesu skanowania sieci.

Skan jest przeprowadzany w ekspresowym tempie i już po chwili zostaniesz poinformowany o odnalezionej ilości działających hostów (w naszym przypadku jest ich 6).

Adresy IP oraz powiązane z nimi adresy MAC poznamy wybierając z menu opcję Hosts a następnie Hosts list. Jak można zauważyć przeglądając poniższą listę odnajdziemy na niej komputer ofiary jak i router.

Przechodzimy do ataku i definiujemy nasze cele. Ponieważ dążymy do przechwycenia ruchu sieciowego pomiędzy routerem a hostem ofiary z listy wykrytych hostów zaznaczamy adres IP 192.168.1.1 (router) i wybieramy przycisk Add to Target 1 (punkt 1) a następnie odszukujemy i zaznaczamy adres IP 192.168.1.200 (ofiara) i klikamy przycisk Add to Target 2 (punkt 2). Cele ataku zostały określone.

Aby przejrzeć bądź zmodyfikować listę celów z menu wybieramy Targets a po rozwinięciu listy klikamy na opcję Current Targets.

Aby rozpocząć atak z menu wybieramy Mitm i dalej Arp poisoning. W nowo otwartym oknie zaznaczamy opcję Sniff remote connections, zatwierdzenie ustawień przyciskiem OK rozpocznie atak.

O rozpoczęciu ataku zostaniemy poinformowani stosownymi wpisami w głównym oknie programu.

Aby mieć 100% pewność, że atak powiódł się sprawdźmy tablicę ARP ofiary. Poniżej na zrzucie przedstawione zostało użycie polecenia sprawdzającego wpisy tablicy ARP: arp -a Punkt 1 obrazuje stan tablicy przed atakiem natomiast punkt 2 stan tablicy po ataku. Jak łatwo zauważyć zmianie uległ adres MAC powiązany z adresem IP bramy. Przed uruchomieniem ataku powiązanie jest jak najbardziej prawidłowe zaś w trakcie jego trwania adres MAC bramy zostaje zamieniony na adres MAC komputera atakującego.

Atak zakończył się powodzeniem.

Aby przerwać atak z menu wybierz Mitm a następnie Stop mitm attack(s)

Ettercap oprócz trybu graficznego również oferuje Nam możliwość skorzystania z trybu pracy w konsoli (taki pseudo tryb graficzny). Przeprowadzenie ataku przy użyciu tego interfejsu przebiega w sposób analogiczny jak w środowisku graficznym. Wywołanie tego trybu odbywa się za pomocą polecenia: ettercap -C

Kolejne narzędzie jaki użyjemy do przeprowadzenia ataku zatrucia bufora ARP jest framework Metasploit a mówiąc bardziej szczegółowo wykorzystamy jeden z dostępnych modułów o nazwie arp_poisoning.

Rozpoczynamy od uruchomienia narzędzia poprzez wydanie polecenia: msfconsole (punkt 1). Wydanie komendy spowoduje uruchomienie frameworku, którego zarządzanie odbywa się za pomocą osobnego zestawu poleceń przynależnych narzędziu.

Uruchomienie modułu odpowiedzialnego za przeprowadzenie ataku ARP poisoning przeprowadzimy wydając polecenie: use/auxiliary/spoof/arp/arp_poisoning (punkt 2).

Po uruchomieniu modułu wydajemy polecenie: info aby poznać parametry jakie należy skonfigurować aby narzędzie mogło przeprowadzić skuteczny atak. Wśród obowiązkowych opcji jakie należy zdefiniować znajdują się:

1 - adres IP hosta, którego ruch chcemy przechwytywać - set dhost <adres_IP>,

2 - interfejs, który posłuży do ataku - set interface <identyfikator_interfejsu> - w przedstawianym opisie został użyty interfejs bezprzewodowy tak byś Czytelniku miał świadomość, że i tego typu interfejsy sieciowe można wykorzystać w procesie przechwytywania pakietów. Adres MAC atakującego pomimo wykorzystania innego interfejsu nie ulega zmianie.,

3 - adres IP routera - set shost <adres_IP>.

Dodatkowo aby obserwować działanie modułu został ustawiony parametr: set verbose true (punkt 4).

Wszystkie niezbędne opcje zostały skonfigurowane czas przejść do uruchomienia ataku. Atak rozpoczniemy po wydaniu polecenia: exploit Wydanie polecenia spowoduje zatrucie tablicy ARP hosta 192.168.1.200

Efekt przeprowadzanego ataku możemy zweryfikować sprawdzając tablicę ARP hosta 192.168.1.200 Jak widać poniżej adres MAC routera wskazuje na hosta o adresie MAC EE-EE-EE-EE-EE-EE co jak wiemy nie jest wartością prawidłową. Adres MAC EE-EE-EE-EE-EE-EE należy do atakującego.

W przypadku użycia opisywanych narzędzi dostępnych w systemie Linux została wykonana tylko połowa roboty gdyż możemy przechwytywać wszystkie zapytania generowane przez ofiarę lecz dane te w żaden sposób nie są przesyłane dalej. Mówiąc prościej trafiają one do atakującego i tylko do niego. Konsekwencją takiego stanu rzeczy jest to, że ofiara traci możliwość połączenia np. z Internetem. A nie do końca o to Nam chodziło. Poniżej polecenie ping wysłane przez ofiarę w kierunku witryny wp.pl i jak widać test ten kończy się niepowodzeniem.

Powodem zaistnienia takiej sytuacji jest wyłączona funkcja przekazywanie pakietów IP (IP forwarding). Tak więc naprawmy to i dajmy hostowi ofiary możliwość komunikacji.

W pierwszym etapie za pomocą polecenia: sysctl net.ipv4.ip_forward sprawdzamy bieżący stan funkcji przekazywania pakietów (punkt 1). Zwróconą wartością jest zero, które oznacza wyłączenie mechanizmu. Aby pakiety prawidłowo mogły być przekazywane pomiędzy interfejsami należy wydać komendę: sysctl net.ipv4.ip_forward=1 bądź alternatywnie polecenie: echo 1 > /proc/sys/net/ipv4/ip_forward (punkt 2). Ponowne sprawdzenie stanu przekazywania (punkt 3) zwraca wartość jeden - przekazywanie jest aktywne. Komendy te powodują tymczasowe włącznie funkcji, jeśli zależy nam na uaktywnieniu mechanizmu na stałe należy w pliku /etc/sysctl.conf dopisać linię: net.ipv4.ip_forward=1

Po wprowadzeniu zmian ofiara może prowadzić swobodną komunikację a my mamy możliwość jej rejestrowania. Tym razem test ping kończy się powodzeniem.

Efekt przeprowadzonego ataku możemy obserwować z wykorzystaniem narzędzia Wireshark. Jak można zaobserwować poniżej - pakiet ICMP trafia od ofiary (adres źródłowy MAC AA-AA-AA-AA-AA-AA) do atakującego (adres docelowy MAC EE-EE-EE-EE-EE-EE).

By następnie atakujący (adres źródłowy MAC EE-EE-EE-EE-EE-EE) przekazał go w kierunku routera (adres docelowy MAC A0-C5-62-73-9A-50).

Po ustaniu ataku wszystko wraca do normy w tablicy ARP ofiary widniej prawidłowy adres MAC routera.

W systemie Linux do przeprowadzenia ataku ARP poisoning możemy również użyć narzędzia o nazwie arpspoof. Instalację narzędzia przeprowadzimy wydając polecenie: apt-get install dsniff

Przechodzimy do ataku. Sprawdzenie tablicy ARP ofiary uwidacznia stan w którym adres MAC jest poprawnie powiązany z adresem IP routera.

Aby rozpocząć zatrucie tablicy ARP należy wydać polecenie: arpspoof -i <użyty_interfejs> -t <adres_IP_ofiary> <adres_IP_routera> (ważna jest kolejność zdefiniowanych adresów IP) po zatwierdzeniu Enterem rozpoczyna się atak.

Ponowne sprawdzenie tablicy ARP komputera ofiary ukazuje zmiany - adres MAC routera został zamieniony na adres MAC atakującego.

Aby ofiara mogła prowadzić swobodną komunikację nie zapomnij o włączeniu przekazywania pakietów IP (opis włączenia funkcji omówiony wyżej).

Nasza sieć oprócz opisanego już zagrożenia związanego z protokołem ARP może być również narażona na ataki typu LAN Storm Attacks. Choć warto tu zauważyć, że sam administrator poprzez błędną konfigurację urządzeń (np. redundancja łączy pomiędzy przełącznikami - wykorzystanie protokołu STP) czy błędną implementację protokołów korzystających z pakietów typu broadcast taki atak może wywołać sam. Należy pamiętać, że przełączniki zawsze przekazują ruch typu broadcast (wykorzystywany np. przez takie protokoły jak ARP czy DHCP) na wszystkie porty dlatego też przypadłość ta może zostać wykorzystana do przeprowadzenia ataku DoS (pojawiające się pakiety zalewają całą sieć LAN marnując tym samym dostępne pasmo co w konsekwencji prowadzi do spadku wydajności całej sieci).

Aby zasymulować atak tego typu ponownie wykorzystamy narzędzie WinArpAttacker. Program umożliwia Nam wysłanie spreparowanych pakietów ARP (pakiety typu: Request, Reply, Reverse request, Reverse reply).

Aby wysłać fałszywy pakiet po uruchomieniu narzędzia wybieramy ikonę Send. Do zalania sieci ruchem broadcast wykorzystamy pakiet typu ARP Request. Wybór rodzaju pakietu umożliwia zdefiniowanie ustawień odnoszących się do wybranego typu pakietu. Ponieważ wysyłany pakiet ma być przypisany do ruchu broadcast pole określające docelowy adres MAC zostaje wypełnione wartością FF-FF-FF-FF-FF-FF (adres rozgłoszeniowy warstwy drugiej). Ponieważ mamy wywołać burzę pakietów dodatkowo zostaje zaznaczona opcja: Continuously Po zatwierdzeniu ustawień przyciskiem Send sieć zostaje zalana pakietami ARP Request pochodzącymi od hosta 192.168.1.210

Atak ten możemy obserwować za pomocą narzędzia Wireshark na hoście 192.168.1.200 gdyż pakiety te są rozsyłane przez przełącznik na wszystkich jego portach.

Innym narzędziem, które możemy wykorzystać do wywołania burzy broadcastowej jest program Hyenae i tak jak w przypadku aplikacji WinArpAttacker tak i tu wykorzystamy pakiet ARP Request. Choć warto zaznaczyć iż narzędzie te możemy użyć do wygenerowania pakietów obejmujących szerokie spectrum ataków:

ARP-Request flooding
ARP-Cache poisoning
PPPoE session initiation flooding
Blind PPPoE session termination
ICMP-Echo flooding
ICMP-Smurf attack
ICMP based TCP-Connection reset
TCP-SYN flooding
TCP-Land attack
Blind TCP-Connection reset
UDP flooding
DNS-Query flooding
DHCP-Discover flooding
DHCP starvation attack
DHCP-Release forcing
Cisco HSRP active router hijacking

Narzędziem możemy zarządzać za pomocą interfejsu GUI jak i wiersza poleceń. Po uruchomieniu trybu graficznego by móc rozpocząć atak należy skonfigurować:

1 - określić interfejs, który zostanie wykorzystany do wysłania spreparowanych pakietów,

2 - zdefiniować typ pakietu oraz wersję protokołu IP,

3 - określić dane, które posłużą do wygenerowania pakietów - w polu Destination Pattern został umieszczony adres rozgłoszeniowy warstwy drugiej,

4 - opcjonalnie określić ilość wysyłanych pakietów oraz zdefiniować opcje związane z częstotliwością ich wysyłania.

Na dole okna aplikacji znajdziemy ekran informacyjny, w którym możemy sprawdzić status wykonywanych operacji a także znajdziemy tam wygenerowane polecenie, które możemy wykorzystać gdy z narzędzia korzystamy z wiersza linii poleceń.

Aby rozpocząć atak należy wybrać przycisk Execute.

Sieć zostaje zalana pakietami ARP Request i tak jak poprzednio atak możemy obserwować na hoście zdalnym przy wykorzystaniu narzędzia Wireshark.

Unikatową cechą programu jest możliwość wykonania opisywanych operacji za pośrednictwem hosta zdalnego. Podczas instalacji programu mamy możliwość określenia czy ma zostać zainstalowany daemon narzędzia, który może posłużyć atakującemu do wywołania ataku zdalnie z poziomu innego hosta (i wcale nie musimy ograniczać się tylko do jednej maszyny, skoordynowany atak może prowadzić wiele hostów).

Na hoście zdalny zostaje zainstalowany daemon narzędzia Hyenae. Aby usługa mogła zacząć działać w tle należy w parametrach jej wywołania określić interfejs sieciowy (parametr: -I <nr_interfejsu>) oraz maksymalną dozwoloną liczbę pakietów (parametr: -u <wartość>). Listę dostępnych interfejsów sieciowych poznasz wydając komendę: hyenaed -l

Daemon został uruchomiony i oczekuje na polecenia. Weryfikację działania możemy przeprowadzić wydając polecenie: netstat -ao, które pokaże nam aktywne usługi sieciowe wraz ze stanem portów. Jak można zauważyć poniżej narzędzie hyenaed działa i nasłuchuje na porcie TCP 666.

Dodatkowo stan procesu sprawdzimy również z wykorzystaniem polecenia: tasklist, które odpowiedzialne jest za wyświetlenie wszystkich działających procesów. Na liście tej również odnajdziemy narzędzie: hyenaed

Daemon narzędzia został zainstalowany na hoście 192.168.1.200 a atak zostanie uruchomiony z hosta o adresie IP 192.168.1.210. Po uruchomieniu narzędzia z listy Operation Mode wybieramy opcję Attack from remote Daemon. Po określeniu adresu IP hosta zdalnego, portu (opcjonalnie hasła) i zdefiniowaniu opcji ataku całość zatwierdzamy przyciskiem Execute. Atak zostaje wykonany za pośrednictwem hosta zdalnego.

Wszystkie operacje związane z działaniem narzędzia możemy dodatkowo przejrzeć w logach narzędzia. Plik logu dostępny jest w katalogu instalacyjnym aplikacji.

Co warto zaznaczyć, to to, że przedstawione programy wcale nie muszą być wykorzystane w niecnych celach ale stanowią świetne narzędzia dla administratorów do przeprowadzania symulowanych ataków (zachowanie sieci gdy prawdziwy atak nastąpi) bądź badania wydajności sieci.

Przechodzimy do ataku na protokół DHCP. Protokół ten (tak w wielkim skrócie) odpowiedzialny jest za dostarczenie konfiguracji sieciowej (adres IP, adres IP bramy, adres IP serwera DNS) nowo podłączanemu hostowi tak by mógł on prowadzić swobodną komunikację z innymi komputerami. Jeśli chcesz uzyskać więcej informacji o sposobie działania i konfiguracji tego protokołu zapraszam do zapoznania się z wpisem: Co w sieci siedzi. Protokół DHCP.

W przypadku tego protokołu do czynienia najczęściej będziemy mieli z dwoma rodzajami ataku:

DHCP Spoofing - atak polegający na podstawieniu fałszywego serwera DHCP, którego zadaniem jest dostarczenie konfiguracji sieciowej hostom, która będzie zgodna z intencjami atakującego,
DHCP Consumption Attack - atak polegający na zablokowaniu serwera DHCP poprzez całkowite wykorzystanie jego zasobów (serwer DHCP zostaje zablokowany gdyż wszystkie dostępne adresy IP w ramach przydzielonej puli zostają wykorzystane - serwer DHCP nie ma wolnych adresów IP, które mógłby przydzielić zgłaszającym się klientom).

Pulę dostępnych ataków możemy powiększyć o ataki typu LAN Storm w których to wykorzystywane są pakiety rozgłoszeniowe przynależne protokołowi DHCP.

W opisie obu ataków wykorzystamy topologię sieciową zaprezentowana na poniższym zrzucie. Serwer DHCP jest rolą systemu Windows 2012 natomiast atakującym jest host z zainstalowanym systemem Linux.

Rozpoczniemy od ataku DHCP Consumption Attack. Jak widać poniżej atakujący ma możliwość komunikacji z serwerem DHCP.

Atakującemu został przez serwer DHCP przyznany adres IP 10.0.0.30 (pierwszy z zadeklarowanej puli - od 10.0.0.30 do 10.0.0.254). Sprawdzenie statystyk wykorzystania zasobów serwera DHCP uwidacznia, że atakujący jest jedynym klientem, któremu została przypisana konfiguracja sieciowa tak więc serwer do rozdysponowania ma jeszcze 224 adresy IP. Celem ataku jest zablokowanie serwera DHCP poprzez doprowadzenie do stanu w którym zasoby serwera zostaną wykorzystane w 100%

Atak przeprowadzimy z wykorzystaniem narzędzia Yersinia. Narzędzie te standardowo dostępne jest w dystrybucji Linux Kali gdy korzystamy z innej dystrybucji program zainstalujemy za pomocą polecenia: apt-get install yersinia (w Linux Ubuntu instalacja oprogramowania przebiega bez żadnych problemów).

Narzędzie te w wcześniejszych moich wpisach było już wykorzystywane lecz jest tak uniwersalne iż nie raz będziemy do niego wracać.

Program możemy używać w trybie graficznym jak i interaktywnym, my wykorzystamy oba.

Aby uruchomić program w trybie interaktywnym wywołujemy go poleceniem: yersinia -I Po uruchomieniu narzędzia określamy interfejs sieciowy, który zostanie wykorzystany do przeprowadzenia ataku (interfejs można zmienić za pomocą klawisza: i - został wybrany interfejs: eth0).

Następnym krokiem jest wybór ataku a tak naprawdę protokołu, który w ataku zostanie wykorzystany - aby zdefiniować atak użyj klawisza F2 bądź g Z dostępnej listy wybieramy oczywiście DHCP (tak jak wspomniałem wyżej narzędzie yersinia jest naprawdę wszechstronne a widać to po liście dostępnych protokołów w ramach, których są przeprowadzane ataki).

Po wyborze protokołu za pomocą klawisza: x określamy rodzaj ataku. Ponieważ przeprowadzamy atak na zasoby serwera DHCP z listy wybieramy: sending DISCOVER packet

Zatwierdzenie ataku (poprzez klawisz 1) rozpocznie zalewanie serwera DHCP pakietami DHCPDlSCOVER proszącymi serwer o dostarczenie konfiguracji sieciowej (ruch ten jest typu broadcast).

Aby przerwać atak należy posłużyć się klawiszem: l po naciśnięciu, którego pojawi się lista aktualnie prowadzonych ataków. Z listy wybieramy atak i celem jego anulowania wybieramy Enter.

W trakcie trwania ataku sprawdzamy statystyki serwera DHCP. Jak można zauważyć atak powiódł się wszystkie dostępne adresy w ramach zdefiniowanej puli zostały wyczerpane.

O fakcie wyczerpania puli adresów IP poprzez okno Menedżer serwera jesteśmy informowani stosownymi komunikatami. Komunikaty te są również dostępne w dzienniku zdarzeń.

Jak wspomniałem wyżej narzędziem Yersinia a co za tym idzie prowadzonymi atakami możemy zarządzać z wykorzystaniem graficznego trybu użytkownika. Aby uruchomić aplikację w trybie graficznym wydajemy polecenie: yersinia -G Po uruchomieniu programu należy w pierwszej kolejności dokonać wyboru interfejsu sieciowego za pomocą, którego będzie przeprowadzany tak. Aby zmienić interfejs można również posłużyć się przyciskiem: Edit interfaces.

Kolejnym krokiem jest wybór protokołu, który zdefiniujemy po wybraniu odpowiedniej zakładki dostępnej po kliknięciu na przycisk: Launch attack Wybieramy zakładkę DHCP a następnie sending DISCOVER packet Aby uruchomić atak całość ustawień zatwierdzamy przyciskiem OK.

Atak DHCP Consumption Attack zostaje uruchomiony. Listę aktualnie przeprowadzanych ataków wraz z możliwością ich anulowania przeprowadzimy po wyborze przycisku: List attacks.

Tak jak poprzednio serwer DHCP zostaje zablokowany co dla klientów oznacza iż nie mogą oni uzyskać adresu IP oraz odnowić dzierżawy adresu już istniejącego. Nie ważne jaki sposób komunikacji z programem wybierzemy efekt wykonywanych operacji powinien być identyczny choć z doświadczenia wiem iż tryb interaktywny jest mniej problemowy gdyż w trybie graficznym program potrafi się zawiesić.

Do tej pory wykorzystywaliśmy serwer DHCP dostępny w ramach systemu Windows Server 2012 lecz nic nie stoi na przeszkodzie by rolę tą pełnił router. Więc zanim przejdziemy dalej prześledźmy jeszcze scenariusz w którym rolę serwera DHCP pełni router CISCO.

Serwer DHCP na routerze został uruchomiony (zostały wydane podstawowe polecenia, jeśli chcesz przeczytać więcej o sposobie konfiguracji routera, który będzie pełnić rolę serwera DHCP zapraszam do wpisu: Co w sieci siedzi. Protokół DHCP).

Statystyki serwera sprawdzimy za pomocą poleceń: show ip dhcp pool oraz show ip dhcp binding Jak widać poniżej z zdefiniowanej puli 254 adresów IP (punkt 1) dostępnych w ramach zakresu obejmujących sieć 10.0.0.0/24 został wykorzystany jeden (punkt 2).

Uruchamiamy atak wyczerpania zasobów serwera DHCP i sprawdzamy jego efekt. Wystarczyło kilka sekund by ilość przydzielonych adresów w ramach zdefiniowanej puli wzrosła do 217.

Dokładne sprawdzenie ilości przydzielonych adresów IP uwidacznia ich całą listę.

Dalsze przeprowadzenie ataku doprowadza do wyczerpania zasobów serwera DHCP a tym samym jak zostało pokazane na rysunku poniżej serwer przestaje dostarczać konfigurację sieciową zgłaszającym się klientom.

Opisany wyżej atak na serwer DHCP nie jest jedynym gdyż atakujący bardzo często wykorzystuje atak związany z podstawieniem fałszywego serwera DHCP. Jak już wiemy jak zablokować serwer DHCP nic nie stoi na przeszkodzie by uruchomić własny, którego zadaniem będzie np. dostarczanie takiej konfiguracji sieciowej w której adresy bramy będzie wskazywać na atakującego.

Prześledźmy zatem scenariusz w którym atakujący host o adresie IP 10.0.0.30 unieszkodliwia właściwy serwer DHCP a następnie uruchamia własny. Do wykonania tego zadania wykorzystamy użyte już wcześniej narzędzie Ettercap.

Po uruchomieniu narzędzia (wykorzystujemy tak jak w przypadku ataku ARP tryb Unified sniffing) z górnego menu wybieramy Mitm a następnie DHCP spoofing.

W nowo otwartym oknie określamy adresy jakie mają zostać dostarczone klientom:

IP Pool - zakres adresów IP jakie może przydzielić serwer DHCP,
Netmask - maska podsieci,
DNS Server IP - adres serwera DNS (8.8.8.8 publiczny adres serwera Google),

Po zaakceptowaniu ustawień serwer DHCP zaczyna działać i oczekuje na klientów.

Do sieci podłączamy klienta (pamiętamy, że właściwy serwer DHCP nie działa), jak widać poniżej klientowi zostaje przydzielony pierwszy adres IP 10.0.0.50 z zdefiniowanej puli fałszywego serwera DHCP. Jak można łatwo zauważyć adres IP bramy wskazuje na hosta przeprowadzającego atak (10.0.0.30).

O fakcie przypisania adresu IP klientowi zostaniemy poinformowani w oknie narzędzia Ettercap.

Sprawdzenie tablicy ARP klienta dobitnie przekonuje Nas o powodzeniu ataku - adres IP 10.0.0.30 jest prawidłowo powiązany z adresem MAC atakującego.

Fałszywy serwer DHCP możemy również uruchomić wykorzystując do tego narzędzie Yersinia. Po uruchomieniu programu wybieramy ikonę Launch attack a następnie w oknie Choose attack na zakładce DHCP wybieramy opcje creating DHCP rogue server. W nowo otwartym oknie Parameters list definiujemy adresysieciowe, którymi ma dysponować fałszywy serwer DHCP. Po uzupełnieniu wszystkich pól atak uruchamiamy przyciskiem OK (okno definicji parametrów serwera nie znika). Fałszywy serwer DHCP działa i oczekuje na klientów.

W przypadku wykorzystania narzędzia Yersinia do utworzenia fałszywego serwera DHCP należy zainstalować dodatkowy pakiet: isc-dhcp-server

Podstawowa zasada działania przełącznika sprowadza się do tego, że dzięki ciągłemu uczeniu się adresów MAC podłączających się klientów (pamiętamy, że przełącznik jest urządzeniem warstwy drugiej) wie na który interfejs ma przekazać dane tak by mogły być one prawidłowo dostarczone. Oznacza to, że podczas normalnej pracy urządzenia nie dochodzi do sytuacji w której to dane są przekazywane na niewłaściwe porty. Odmienną zasadę działania oferował hub sieciowy gdyż w przypadku tego urządzenia trafiające pakiety do danego interfejsu były powielane na wszystkie inne a dany host decydował o tym czy otrzymane informacje odrzucić bądź zaakceptować. Jak łatwo się domyślić sieć zbudowana z wykorzystaniem hubów nie była rozwiązaniem zbyt wydajnym gdyż bardzo wiele danych było przesyłanych niepotrzebnie (hub przekazywał pakiety w kierunków hostów, które ich nie oczekiwały a w konsekwencji były one odrzucane). Jednak taki scenariusz dla osoby próbującej przechwycić ruch sieciowy był nader korzystny gdyż znacznie łatwiej było prowadzić sniffing. Pakiety od innych hostów do komputera przechwytującego ruch były przekazywane (ze względu na wykorzystanie huba) wystarczyło tylko zmusić kartę sieciową do ich rejestrowania. Sytuacja ta uległa pogorszeniu (z punktu widzenia atakującego) gdy zamiast hubów zaczęto wykorzystywać przełączniki. Lecz jest sytuacja w której możemy zmusić przełącznik by zachowywał się jak hub. Każdy przełącznik posiada tablicę adresów MAC, której zadaniem jest przechowywanie informacji o nauczonych adresach MAC należących do klientów. Rozmiar tej tablicy w zależności od urządzenia jest różny a co dla Nas najważniejsze jest ograniczony. Oznacza to ni mniej ni więcej, że dany switch jest w stanie nauczyć się i przechowywać określoną ilość adresów MAC. Pewnie zastanawiasz się Czytelniku - Co dzieje się w przypadku zapełnienia tablicy? Otóż w takiej sytuacji przełącznik zaczyna zachowywać się jak hub czyli otrzymane ramki zostają powielone na wszystkie interfejsy przełącznika. Dla hakera bądź osoby przeprowadzającej test penetracyjny przypadłość ta jest kolejnym wektorem ataku. Zatem spróbujmy przeprowadzić atak, którego zadaniem będzie wyczerpanie zasobów tablicy MAC przełącznika a w konsekwencji do zmuszenia switcha by działał jak hub.

Aby sprawdzić pojemność tablicy (ilość możliwych do przechowywania wpisów) wydaj polecenie: show mac-address-table count Po wydaniu komendy uzyskamy informację o ilości aktualnych wpisów w tablicy MAC (w rozbiciu na adresy poznane w sposób dynamiczny jak i te zdefiniowane statycznie przez administratora) oraz ilości dostępnego miejsca.

By poznać bardziej szczegółowe dane wydaj polecenie: show mac-address-table <rodzaj_wpisu> (w nowszych wersjach IOS: show mac address-table <rodzaj_wpisu>). Poniżej przykład wydania komendy dostarczającej nam informację o adresach MAC nauczonych dynamicznie. Oprócz samego adresu MAC zostaniemy poinformowani o interfejsie przez, który dany adres MAC jest osiągalny oraz o przynależności do sieci VLAN.

Do przeprowadzenia ataku użyjemy narzędzia: macof Aby rozpocząć atak zalewania przełącznika adresami MAC należy wydać polecenie: macof -i <interfejs> Po zatwierdzeniu komendy na domyślny adres IP 0.0.0.0 (wszyscy) zostaną wysłane ramki symulujące połączenia pomiędzy hostami.

Atak ten również możemy obserwować z wykorzystaniem narzędzia Wireshark. Jak można zauważyć poniżej program macof generuje pakiety protokołu IPv4 udające łączność pomiędzy losowo zdefiniowanymi adresami IP.

W przypadku programu macof do dyspozycji mamy dodatkowe przełączniki:

-i <interfejs> - określa użyty interfejs,

-s <adres_IP> - określa źródłowy adres IP,

-d <adres_IP> - określa docelowy adres IP,

-e <adres MAC> - określa docelowy adres sprzętowy,

-x <numer_portu> - określa źródłowy port TCP,

-y <numer_portu> - określa docelowy port TCP,

-n <liczba> - definiuje liczbę pakietów do wysłania.

Atak jest w toku. Ponowne sprawdzenie wykorzystania tablicy MAC ukazuje stan w którym to cała dostępna przestrzeń tablicy adresów MAC jest wykorzystana. Przełącznik wypełnił całą tablicę, nie może uczyć się nowy adresów MAC.

Dokładniejsze sprawdzenie wypełnienia tablicy pokaże Nam wszystkie poznane adresy MAC.

Atak zakończył się powodzeniem gdyż po przepełnieniu tablicy MAC przełącznika zaczyna się on zachowywać jak zwykły koncentrator tj. otrzymywane pakiety są rozsyłane na wszystkie interfejsy przełącznika. Poniżej przechwycony ruch sieciowy podczas trwania ataku - host 10.0.0.1 wysyła w kierunku hosta 10.0.0.20 zapytanie ping (udało się zarejestrować odpowiedzi). I na koniec jeszcze jedna mała uwaga - atak tego typu powiedzie się tylko w takiej sytuacji w której w tablicy MAC niema jeszcze wpisów odpowiadającym hostom co do których ruch monitorujemy. Jeśli wpisy istnieją nie uda nam się ruchu sieciowego przechwycić.

Aby wyczyścić tablicę adresów MAC wydaj polecenie: clear mac-address-table dynamic

Opisaliśmy podstawowe metody przeprowadzania ataku z wykorzystaniem założonych na wstępie artykułu protokołów, czas by przejść do opisu obrony przed tego typu atakami (choć do opisu przeprowadzenia jeszcze jednego ataku na chwilę wrócimy - szczegóły w dalszej części wpisu).

Opis obrony rozpoczniemy od protokołu DHCP gdyż opisana poniżej procedura zostanie powtórnie wykorzystana w innej metodzie obrony.

Zabezpieczenie serwera DHCP przed zalaniem go pakietami zawierającymi prośbę o przydzielenie adresu IP (a co za tym idzie wyczerpaniu zasobów serwera) a także ochronę sieci przed nieautoryzowanym serwerem DHCP osiągniemy konfigurując na przełączniku mechanizm DHCP snooping.

Działanie funkcji sprowadza się do określenia interfejsów zaufanych czyli takich przez które ustanowiona jest bezpośrednia łączność z serwerem DHCP oraz interfejsów niezaufanych - na portach tych nie może być prowadzona wymiana pakietów związana z funkcjonowaniem serwera DHCP (mówiąc inaczej serwer DHCP podłączony do portu przełącznika pracującego w trybie untrusted nie będzie działał). Port niezaufany w przypadku wykrycia podejrzanego ruchu sieciowego zostaje automatycznie zamknięty.

Zanim przejdziemy dalej uzupełnimy naszą topologię sieciową wykorzystywaną w atakach na serwer DHCP o niezbędne dane (numery interfejsów przełącznika do których podpięte są stacje).

Jak widać powyżej komunikacja z serwerem DHCP następuje przez interfejs f0/1. Interfejs ten będziemy konfigurowali jako zaufany. Aby na przełączniku skonfigurować mechanizm DHCP snooping należy wydać następujące polecenia:

1 - ip dhcp snooping vlan <numer_sieci_VLAN> - uruchamiamy funkcję w kontekście danej sieci VLAN. Urządzenia w scenariuszu są umiejscowione w domyślnej sieci VLAN tak więc polecenie przyjmuje postać: ip dhcp snooping vlan 1

2 - ip dhcp snooping - włączenie mechanizmu globalnie,

3 - w trybie konfiguracji interfejsu za pomocą polecenia: ip dhcp snooping trust ustawiamy zaufanie portu.

Dla reszty interfejsów sieciowych (aby nie konfigurować każdego portu z osobna wydajemy polecenie: interface range <zakres_portów>) określamy limit wystąpienia pakietów związanych z funkcjonowaniem serwera DHCP - po przekroczeniu ustalonej wartości następuje blokada interfejsu.

Działanie mechanizmu skontrolujemy wydając komendę: show ip dhcp snooping Port f0/1 jest portem zaufanym tak więc działanie mechanizmu DHCP snooping tego portu nie obejmuje, zaś na reszcie interfejsów jest przeprowadzana inspekcja związana z ruchem pakietów DHCP. W tym przypadku wartość progu została ustalona na 10 pakietów na sekundę.

Funkcja ochrony serwera DHCP została skonfigurowana nie pozostaje Nam nic innego jak sprawdzić ją w działaniu. Ponownie uruchamiamy atak zalewając serwer DHCP pakietami DHCP Discover. Chwilę po uruchomieniu ataku zostaje przekroczona graniczna wartość wystąpienia 10 pakietów na sekundę, interfejs przechodzi w stan: err-disable i zostaje wyłączony.

Status interfejsu możemy sprawdzić za pomocą dobrze znanych nam poleceń: show ip interface brief

a także: show interface <numer_interfejsu>

Do odnalezienia interfejsów w stanie err-disable możesz również użyć polecenia: show interface status err-disabled

Aby ponownie uruchomić interfejs przechodzimy do trybu konfiguracji danego portu i wyłączamy go (punkt 1) a następnie włączamy (punkt 2).

Jeśli na danym nie zaufanym porcie pojawi się obcy serwer DHCP mechanizm obrony wygeneruje odpowiednie ostrzeżenie. Podłączający się klient nie uzyska konfiguracji sieciowej.

Dzięki zastosowaniu mechanizmu DHCP snooping ochroniliśmy naszą sieć przed atakami związanymi z protokołem DHCP.

Aby zapobiec atakowi typu MAC Address Table Overflow Attack (przepełnienie tablicy MAC) możemy tak skonfigurować przełącznik by nie uczył się poznanych w sposób dynamiczny adresów MAC a co za tym idzie nie będzie budowana tablica MAC przełącznika. Standardowo jak już pewnie wiesz Czytelniku tablica ta służy switchowi do tego aby powiązać dany adres MAC z interfejsem na którym adres ten jest osiągalny.

Sprawdzenie tablicy MAC wykonujemy za pomocą polecenia: show mac address-table dynamic (już o tym wyżej pisałem i pewnie uważny Czytelnik zauważy, że w poprzednim przypadku użyłem polecenia w którym był zawarty myślnik pomiędzy słowami mac a address - Czemu teraz go nie ma? Otóż w trakcie tworzenia tego wpisu musiałem dokonać aktualizacji wersji oprogramowania przełącznika gdyż polecenia, które za chwilę przedstawię nie były dostępne w starszej wersji systemu a w nowych wersjach oprogramowania zrezygnowano z myślnika pomiędzy tymi słowami - ot i cała tajemnica). Po wydaniu polecenia zostanie wyświetlona tablica adresów MAC przełącznika jak widać poniżej znajdują się w niej tylko 3 wpisy (przyczyną wystąpienia dwóch adresów MAC na interfejsie f0/7 jest zastosowanie maszyny wirtualnej).

Wyłączenie tworzenia tablicy dla adresów poznanych dynamicznie wykonamy za pomocą komendy: no mac address-table learning vlan <numer_sieci> (poznawanie adresów MAC wyłączamy w ramach danej sieci VLAN). Dla uproszczenia opisu wszystkie urządzenia są zgrupowane w ramach domyślnej sieci VLAN 1 tak więc w efekcie polecenie przyjmuje postać: no mac address-table learning vlan 1

Po wyłączeniu możliwości zapamiętywania adresów MAC poznanych dynamicznie ponownie przechodzimy do wykonania ataku mającego na celu przepełnienie tablicy MAC przełącznika. Atak został uruchomiony.

Zweryfikujmy atak. Sprawdzenie stanu tablicy uwidacznia brak jakichkolwiek adresów MAC, które zostały uzyskane w sposób dynamiczny.

Sprawdzenie ogólnego stanu ilości przechowywanych adresów również pokazuje brak jakichkolwiek adresów MAC.

Tym razem atak MAC flooding zakończył się niepowodzeniem. Tablica adresów MAC przełącznika pozostaje pusta.

Brak adresów MAC w połączeniu z numerem portu w tablicy MAC przełącznika nie jest stanem pożądanym gdyż sytuacja ta zaburza normalne funkcjonowanie przełącznika. Dlatego po wyłączeniu automatycznego uczenia się adresów MAC sami musimy zadbać o wpisy informujące switch o powiązaniu: adres MAC urządzenia-numer interfejsu pod którym urządzenie te jest dostępne.

Aby statycznie zdefiniować tablicę MAC przełącznika należy do tego celu wykorzystać polecenie: mac address-table static <adres_MAC> vlan <numer_sieci_VLAN> interface <numer_interfejsu> Tak więc w przyjętym scenariuszu należy wydać polecenia jakie zostały pokazane na zrzucie poniżej.

Weryfikację wprowadzonych ustawień sprawdzimy za pomocą polecenia: show mac address-table static. Adresy MAC w powiązaniu z interfejsem zostały wprowadzone prawidłowo.

Jeśli interesuje Cię sprawdzenie tablicy adresów MAC w kontekście danej sieci VLAN użyj polecenia: show mac address-table static vlan <numer sieci_VLAN>

Opisane rozwiązanie mające uniknąć konsekwencji ataku przepełnienia tablicy MAC przełącznika nie jest metodą komfortową gdyż o wszystkie ustawienia musimy zadbać sami. O ile w małych sieciach, których topologia zbyt często nie ulega zmianie rozwiązanie te jest akceptowalne to w sieciach dużych o zmiennym stanie ilości urządzeń końcowych już nie. Dlatego też istnieją inne rozwiązania, które pozwolą nam zabezpieczyć naszą sieć przed tego typu atakiem a także innymi atakami wykorzystującymi słabości protokołów wykorzystywanych w warstwie 2 modelu ISO/OSI.

Podstawowym i jednym z najbardziej skutecznych sposobów zabezpieczenia sieci jest wykorzystanie mechanizmu Port Security. Przełączniki firmy CISCO zostały wyposażone w ten mechanizm, którego głównym celem jest zapewnienie komunikacji urządzeniom, które mają do tego prawo. Konfigurację tego mechanizmu w tym artykule nie opiszę gdyż jego dokładny opis zamieściłem w wpisie - Co w sieci siedzi. Warstwa 2 czyli podstawowa konfiguracja przełącznika CISCO Jeśli chcesz poznać zasady działania ochrony portu z wykorzystaniem funkcji Port Security zapraszam do lektury wpisu dostępnego pod podanym linkiem.

Zatem idziemy dalej i przechodzimy do protokołu ARP czyli jak obronić się przed atakiem polegającym na manipulacji adresami zapisanymi w tablicy ARP hosta.

Pierwsze zaproponowane rozwiązanie bazuje tak jak w przypadku określenia statycznych wpisów w tablicy MAC przełącznika na ręcznej (statycznej) definicji adresów zawartych w tablicy ARP. Po ręcznym zdefiniowaniu adresu IP w połączniu z adresem MAC unikniemy ataku zatrucia tablicy ARP gdyż system operacyjny zignoruje wszystkie odbierane komunikaty ARP, dotyczące adresów IP-MAC nie pozwalając na zastąpienie wpisów statycznych tymi uzyskanymi w sposób dynamiczny. Aby uzyskać całkowitą ochronę przed atakiem ARP spoofing należy na wszystkich urządzeniach utworzyć wpisy w tablicy ARP definiujące komunikację każdy z każdym. W praktyce z reguły stosuje się podejście w którym na komputerach tworzy się statyczne wpisy dla wszystkich serwerów oraz bram (wychodzimy z założenia, że większość hostów pomimo obecności w jednej sieci ze sobą się nie komunikuje).

Przechodzimy do ręcznej definicji wpisów tablicy ARP. Operację rozpoczniemy od hosta 10.0.0.1 W pierwszej kolejności warto wydać polecenie: netsh interface ip delete arpcache które usunie wszystkie zgromadzone do tej pory powiązania (uchroni nas to przed odmową dodania statycznego wpisu dla adresu, który już w tablicy się znajduje, czasem to nie pomaga wtedy wyłącz i włącz interfejs sieciowy). Wydanie polecenia usuwa również wszystkie zdefiniowane wcześniej wpisy statyczne.

Wpis definiujemy za pomocą komendy: arp -s <adres_IP> <adres_MAC> Na hoście oczywiście należy określić adresy hostów zdalnych. W naszym przypadku podajemy adresy przypisane hostowi 10.0.0.20 Weryfikację dodania wpisu sprawdzimy poleceniem: arp -a

Na komputerze 10.0.0.20 przeprowadzamy analogiczną czynność podając adresy hosta 10.0.0.1.

Po skonfigurowaniu statycznych tablic ARP sprawdźmy komunikację pomiędzy hostami. Test ping przeprowadzony z hosta 10.0.0.20 w kierunku komputera 10.0.0.1 zakończył się powodzeniem.

Po zdefiniowaniu wpisów statycznych sprawdźmy podatność obu systemów na atak ARP spoofing.

W przypadku systemu Windows wszystkie wpisy dodajemy osobnymi polecenia w systemie Linux możliwe jest zebranie wszystkich powiązań (para adresów IP-MAC) w osobnym pliku tekstowym i wprowadzenie wszystkich pozycji w sposób automatyczny (polecenie: arp w połączeniu z parametrem -f).

Ponownie wykorzystujemy narzędzie Ettercap gdzie po przeprowadzonym skanowaniu wraz z ustaleniem celów uruchamiamy atak zatrucia tablicy ARP.

Atak trwa. Sprawdźmy jak wygląda tablica ARP na hoście 10.0.0.20. Polecenie sprawdzenia tablicy zostało wydane dwa razy - przed uruchomieniem ataku (punkt 1) oraz podczas jego trwania (punkt 2). Wpisy w tablicy ARP hosta 10.0.0.20 nie uległy zmianie.

Sprawdzamy tablicę ARP na hoście 10.0.0.1 Tutaj również wpisy przed uruchomieniem ataku (punkt 1) są identyczne z wpisami podczas jego trwania (punkt 2).

Atak zatrucia tablicy ARP w przypadku komputerów na których zostały zdefiniowane wpisy statyczne nie powiódł się - wpisy poznane w sposób dynamiczny nie mogą zastąpić tych zdefiniowanych ręcznie przez administratora. Przechwytywanie pakietów z wykorzystaniem protokołu ARP pomiędzy hostami 10.0.0.1 a 10.0.0.20 zakończyło się niepowodzeniem co nie oznacza, że nie istnieją inne metody pozwalające Nam na przechwycenie komunikacji pomiędzy stacjami.

Miałem już pisać tylko o obronie przed atakami a nie opisywać kolejnych ale tak sobie myślę, że przedstawiony scenariusz pokaże również błędy popełniane przez administratorów, które w konsekwencji doprowadzają do tego, że atak na naszą sieć kończy się powodzeniem. W opisie przedstawionym powyżej udaremniliśmy atakującemu możliwość podsłuchania komunikacji pomiędzy hostami ale jak już wspomniałem wachlarz innych metod nadal pozostaje otwarty. Wektorem dla atakującego jest również sam przełącznik i to na nim skupimy teraz swoją uwagę.

Wykonując skanowanie sieci odkrywamy aktywne hosty (więcej o technikach i metodach skanowania dowiesz się zapoznając się z tym wpisem: Co w sieci siedzi. Skanowanie sieci - aktywne hosty), wśród gąszcza wykrytych adresów IP należy wytypować te które odpowiadają urządzeniom odpowiedzialnym za funkcjonowanie sieci (switche, routery, access pointy). I tu rodzi się pytanie - Jak tego dokonać?

Odpowiedź na to pytanie możemy uzyskać poprzez analizę aktywnych adresów MAC zdobytych podczas procesu skanowania sieci. Adres MAC jest zbudowany w ten sposób, że pierwsze 24 bity (bądź jak ktoś woli pierwsze 3 bajty) są przypisane do producenta urządzenia sieciowego - to tzw. vendor code , reszta adresu (kolejne 24 bity, bądź 3 bajty) są unikalnym identyfikatorem danego egzemplarza karty. Na przykład adres 00-01-42-AB-01-21 oznacza, że karta została wyprodukowana przez CISCO ponieważ vender code 00-01-42 jest przypisany do firmy CISCO zaś producent nadał jej numer AB-01-21.

Aby odnaleźć identyfikatory jakie zostały przypisane do producentów urządzeń sieciowych możesz posłużyć się wyszukiwarką dostępną na stronie - http://www.miniwebtool.com/mac-address-lookup/

Wpisując nazwę firmy bądź vender code uzyskamy informację o producencie.

Tak więc wracając do analizy odkrytych adresów MAC i przypisując im producenta z dość dużym prawdopodobieństwem możemy wytypować adresy, które należą do urządzeń odpowiedzialnych za zarządzanie siecią (popularne firmy to m.in. CISCO, Juniper, HP, MikroTik, TP-link, Ubiquiti Networks, ALANTEC, Jirous). Analizując adresy pierwsze swoje kroki skieruj ku adresom IP rozpoczynającym i kończącym daną podsieć gdyż to najczęściej do tych adresów IP będą przypisane urządzenia - np. adresem bramy bardzo często jest adres IP o ogólnym formacie x.x.x.1 bądź x.x.x.254

W naszym przypadku odkrywamy urządzenie o adresie 10.0.0.254 i po analizie adresu MAC dochodzimy, że jest to urządzenie CISCO (w tym przypadku zostało wykorzystane narzędzie Nmap, które samodzielnie dokonuje identyfikacji producenta urządzenia).

Wykonajmy zatem atak zatrucia bufora ARP dla adresu IP 10.0.0.254 Atak swym działaniem obejmuje całą sieć. Po wykonaniu operacji zatrucia tablicy ARP przełącznika oczekujemy na połączenie oczywiście w tle mamy uruchomiony program przechwytujący ruch sieciowy. Jeśli administrator dokonał konfiguracji przełącznika i wszystko działa to z reguły nie ma potrzeby by sprawdzać konfigurację switcha dlatego też oczekiwanie aż administrator nawiąże połączenie może zająć nam wiele czasu. Dlatego też by zmusić administratora do nawiązania połączenia możemy dodatkowo wykonać atak, którego zadaniem będzie zaburzenie działania sieci. Niedziałająca poprawnie sieć wymusi na osobach dbających o jej działanie podjęcie odpowiednich kroków celem znalezienia usterki. Szukając rozwiązania zaistniałych problemów wzrasta szansa na to, że administrator nawiąże połączenie z urządzeniem, którego ruch sieciowy monitorujemy.

Dodatkową opcją jest wykorzystanie takich narzędzi jak: Cisco Auditing Tool czy Cisco-Torch, które potrafią wykonać atak brute-force bądź atak słownikowy na urządzenie celem złamania danych logowania.

Atak ARP na switch jest uruchomiony i jak widać poniżej powiódł się on - gdyż ruch sieciowy ze stacji 10.0.0.1 z której będzie wykonywane logowanie do switcha jest przekazywany w kierunku hosta atakującego 10.0.0.30 (oczywiście podczas prowadzenia prawdziwego ataku do tych informacji jeszcze nie mamy dostępu - zadaniem zrzutu umieszczonego poniżej jest tylko pokazanie Ci Czytelniku iż atak zatrucia bufora ARP zakończył się powodzeniem).

Administrator wykonuje proces logowania i jak widać poniżej po analizie przechwyconych pakietów udaje Nam się zdobyć hasło - cisco (hasło do nawiązania połączenia oraz do przejścia do trybu enable).

Atak zatrucia tablicy ARP możemy zakończyć gdyż zdobyliśmy potrzebne nam dane.

W naszych rozważaniach wszystko przebiegło po naszej myśli gdyż zostały spełnione określone warunki, które umożliwiły Nam przeprowadzenie ataku z powodzeniem.

Pierwszym błędem jest wykorzystanie protokołu Telnet, który został użyty do nawiązania połączenia z przełącznikiem. Protokół ten nie gwarantuje Nam żadnej ochrony podczas przesyłania danych gdyż wszystkie informacje nie są w żaden sposób szyfrowane - cała komunikacja odbywa się otwartym tekstem. Osoba przeprowadzająca atak uzyska wszystkie niezbędne dane. Zatem by zwiększyć bezpieczeństwo sieci zrezygnuj z Telnetu na rzecz bezpieczniejszego protokołu jakim jest SSH (jak przeprowadzić taką konfigurację dowiesz się po przeczytaniu wpisu - Co w sieci siedzi. Warstwa 2 czyli podstawowa konfiguracja przełącznika CISCO).

Drugim błędem jest umieszczenie adresu IP przełącznika przez który uzyskujemy dostęp do urządzenia w tej samej sieci VLAN w której pracują użytkownicy sieci. Dobrą praktyką jest wydzielenie odrębnej sieci VLAN służącej do administrowania urządzeniami sieciowymi a co do której dostęp mają tylko administratorzy. Wydzielenie osobnej sieci VLAN służącej do zarządzania urządzeniami zagwarantuje Nam, że postronni użytkownicy sieci nie będą mieli dostęp do adresów IP, które urządzeniom zostały przypisane. Jak taką sieć VLAN skonfigurować dowiesz się tu: Co w sieci siedzi. Warstwa 2 - konfiguracja sieci VLAN.

Aby dodatkowo zwiększyć poziom bezpieczeństwa możesz również zdefiniować adresy IP które mają prawo łączyć się z danym urządzeniem.

W sieciach w których bezpieczeństwo jest stawiane na pierwszym miejscu stosuje się jeszcze inny wybieg polegający na stworzeniu całkiem odrębnej fizycznej sieci, która służy tylko do zarządzania oraz monitorowania urządzeń sieciowych (metoda Out of Band). Rozwiązanie te znacząco podnosi poziom bezpieczeństwa, gdyż do sieci takiej mają dostęp tylko administratorzy (normalni użytkownicy z niej nigdy nie korzystają) a dodatkowo mamy redundancję zapewniającą nam dostęp do urządzeń gdy właściwa sieć przestanie działać (dodatkowy kanał komunikacyjny).

Atakujący zdobył dostęp do przełącznika a tym samym uzyskał wgląd w ustawienia urządzenia i na pewno jest bogatszy o wiele cennych informacji dotyczących budowy naszej sieci. Dodatkowo uzyskuje on możliwość manipulowania urządzeniem.

Jedną z ciekawszych rzeczy jakie może wykorzystać atakujący jest wykorzystanie funkcji port mirroring. Działanie tego mechanizmu sprowadza się do wskazania interfejsów przełącznika, z których cały ruch sieciowy (odbierany, wysyłany bądź oba) będzie kopiowany na inny wybrany port. W przypadku CISCO mechanizm ten nazwano SPAN (ang. Switch Port Analyzer).

Spróbujmy zatem wykorzystać tę funkcję przełącznika.

Atakujący dzięki zdobytym danym uwierzytelniającym wykonuje proces logowania do urządzenia i konfiguruje kopiowanie ruchu sieciowego tak by móc przechwytywać komunikacje pomiędzy hostem o adresie IP 10.0.0.1 a 10.0.0.20

Ustawienie sesji sprowadza się do wydania dwóch poleceń:

1 - monitor session <numer_sesji> source interface <id_interfejsu> <rodzaj_ruch_sieciowego> - polecenie określa numer sesji funkcji SPAN oraz definiuje interfejs z którego ruch ma zostać skopiowany wraz z typem ruchu. W naszym przypadku kopiowany będzie ruch sieciowy przychodzący i wychodzący z interfejsu f0/1 (do portu tego podłączony jest host 10.0.0.1 - port f0/7 również jest dobrym wyborem). Użycie parametru: rx definiuje ruch otrzymywany przez przełącznik zaś parametr: tx określa ruch opuszczający dany interfejs.

2- monitor session <numer_sesji> destination interface <id_interfejsu> - polecenie definiuje do którego interfejsu ma zostać przesłany skopiowany ruch sieciowy.

Atakujący kopiowanie ruchu sieciowego ustawił na interfejs f0/3 czyli port do którego sam jest podłączony. To niestety jest błąd gdyż zatwierdzając drugie polecenie pozbawił się łączności z siecią a tym samym stracił możliwość wydawania poleceń urządzeniu.

Normalna łączność z siecią został utracona lecz na interfejs f0/3 przełącznika jest realizowany proces kopiowania otrzymywanych/wysyłanych danych z interfejsu f0/1. Uruchamiając narzędzie do przechwytywania pakietów możemy rejestrować łączność pomiędzy hostami. Na hoście 10.0.0.1 wydano polecenie ping w kierunku hosta 10.0.0.20 jak widać poniżej udało się tą komunikację przechwycić.

Konfigurację SPAN możemy zweryfikować wydając polecenie: show monitor session <numer_sesji>

Gdy atakujący ma dostęp do przełącznika może poprzez jego konfigurację zdobyć wiele cennych informacji w tym przypadku ustawienie interfejsu f0/3 jako tego na który ma być kopiowany ruch oczywiście dla przeprowadzającego atak zakończyło się powodzeniem pomimo tego, że sam fizycznie od sieci się odciął. Aby uniknąć tego typu sytuacji, ruch monitorowany należałoby kopiować na inny np. nie używany interfejs do którego jest podpięta stacja kontrolowana również prze atakującego.

Mechanizm SPAN bardzo często jest wykorzystywany przez samych administratorów do wykrywania anomalii w ruchu sieciowym. Do interfejsu takiego można podpiąć komputer, który w czasie rzeczywistym otrzymywane pakiety będzie analizował i gdy wykryje jakieś nieprawidłowości zostaniemy o nich powiadomieni - systemy IDS/IPS których zadaniem jest wykrywanie (IDS) lub wykrywanie i blokowanie ataków sieciowych (IPS).

W przypadku CISCO istnieje odmiana sesji SPAN, która może być stosowana w odniesieniu do sieci VLAN - tzw. VSPAN – Virtual SPAN.

Przykładowy zapis zamieszczony poniżej oznacza, że na porcie f0/3 pojawią się kopie ramek kierowanych do portów przełącznika, które swoje interfejsy mają przypisane do sieci VLAN o numerach od 10 do 12.

switch(config)# monitor session 1 source vlan 10-12 rx

switch(config)# monitor session 1 destination interface f0/3

Działanie funkcji SPAN dodatkowo możemy rozszerzyć na wiele przełączników, które są ze sobą połączone oraz skonfigurowane tak by przechwytywany ruch sieciowy odbywał się poprzez inne switche do komputera go rejestrującego - RSPAN (Remote SPAN).

Dokładna konfiguracja urządzeń pod kątem monitorowania i przechwytywania ruchu sieciowego i jego dalszej analizie wykracza już poza ramy tego wpisu, co nie oznacza że do tematu tego nie będę chciał w przyszłości wrócić.

Wracając jeszcze chwilkę do metody wykorzystanej przez atakującego to oczywiście możliwy jest również taki scenariusz (pod warunkiem, że atakujący ma dostęp fizycznie do sieci) w którym następuje podpięcie dodatkowego urządzenia na drodze pomiędzy hostem 10.0.0.1 a 10.0.0.20, którego zadaniem będzie kopiowanie otrzymywanego ruchu sieciowego. Do tego zadania posłużyć może nam najzwyklejszy koncentrator (pamiętamy, że w przypadku hubów sieciowych ruch jest wysyłany na wszystkie jego porty) bądź możemy skorzystać z bardziej zaawansowanego urządzenia jakim jest TAP. Zadaniem tego typu urządzeń jest przekazywanie ruchu sieciowego przy jednoczesnym kopiowaniu go. TAP zaopatrzony jest z reguły w trzy porty: port A, port B oraz port monitorujący. Porty A i B służą do połączenia urządzenia z istniejącą strukturą sieciową zaś na port monitorujący przesyłany jest cały ruch sieciowy jaki jest przekazywany pomiędzy portem A i portem B. Dużą zaletą tego typu urządzeń jest fakt iż nie wprowadzają one żadnych dodatkowych opóźnień czy spadków przepustowości łącza (jak to ma w przypadku użycia koncentratora) podczas przesyłania danych. W sprzedaży przez takie firmy jak: NetOptics, Finisar czy Gigamon są modele TAP-ów, które przeznaczone są do sieci tradycyjnych jak i światłowodowych.

Tak więc topologia sieciowa w przypadku użycia dodatkowego urządzenia, którego celem byłoby przechwytywanie pakietów mogłaby wyglądać następująco (cały czas pamiętamy, że tego typu rozwiązanie wymaga fizycznego dostępu do atakowanej sieci):

Wniosek z takiego scenariusz płynie taki - że bezpieczeństwo naszej sieci nie sprowadza się tylko do właściwej konfiguracji urządzeń sieciowych ale również obejmuje ochronę fizycznego dostępu do infrastruktury.

Wracamy do wątku głównego i omawiamy dalej jak ustrzec się przed atakiem zatrucia tablicy ARP.

Aby zapobiec zmianie tablicy ARP na przełączniku tak samo jak na hostach możemy zdefiniować statyczne adresy MAC, które zostaną powiązane z adresem IP i interfejsem przełącznika. Sprawdzenie tablicy ARP w kontekście adresów nauczonych dynamicznie i statycznie wykonamy wydając komendę: show arp dynamic bądź show arp static Jak widać poniżej w tablicy ARP przełącznika istnieją tylko dwa wpisy poznane w sposób dynamiczny i brak jest wpisów statycznych. Naszym celem jest utworzenie dla hostów 10.0.0.1 oraz 10.0.0.20 wpisów statycznych tak by ich zamiana była niemożliwa.

Rozpoczynamy od usunięcia istniejących wpisów. Usunięcie powiązania wykonamy za pomocą komendy: clear ip arp <adres_IP> Ponowne sprawdzenie tablicy uwidacznia brak jakichkolwiek wpisów dynamicznych.

Wpisy statyczne definiujemy za pomocą polecenia: arp <adres_IP> <adres_MAC> arpa <interfejs> Komendę wydajemy w trybie konfiguracji globalnej. Poniżej zostały utworzone wpisy statyczne dla obu hostów.

Poprawność dodania wpisów zweryfikujemy za pomocą znanego Nam już polecenia: show arp static Wpisy zostały dodane prawidłowo.

Dodatkowo wszystkie wpisy zapisane w tablicy możemy sprawdzić poleceniem: show ip arp zaś gdy chcemy uzyskać jeszcze bardziej szczegółowe dane możemy posłużyć się komendą: show arp <static|dynamic> detail

Ustawienie wpisów statycznych na przełączniku tak samo jak w przykładzie poprzednim w którym to tablicę ARP definiowaliśmy na hoście uchroni Nas przed atakiem zatrucia tablicy ARP switcha - wpisy określone statycznie mają pierwszeństwo przed tymi poznanymi w sposób dynamiczny.

Kontrolę nad pakietami ARP możemy sprawować jeszcze przy pomocy jednego mechanizmu jakim jest Dynamic ARP Inspection. Zadaniem funkcji jest kontrolowanie pojawiających się wpisów ARP tak by tylko uprawnione hosty mogły zostać dopuszczone do komunikacji. Działanie tego mechanizmu jest ściśle powiązane z opisywaną już funkcją DHCP snooping gdyż to na podstawie tablicy przydzielonych adresów IP powiązanych wraz z adresami MAC opiera się działanie inspekcji prowadzonej przez przełącznik. Dla poprawnego działania funkcji musi istnieć tablica tworzona dzięki włączonemu mechanizmowi DHCP snooping gdyż to na jej podstawie (badane są dwa pola tablicy tj. IPAddress oraz MACAddress) następuje weryfikacja istnienia hosta, który dane pakiety ARP generuje. Brak hosta w tablicy skutkuje zablokowaniem prowadzenia komunikacji.

Aby bardziej szczegółowo zademonstrować działanie mechanizmu przejdźmy do jego konfiguracji.

Konfigurację rozpoczynamy od włączenia funkcji DHCP snooping (punkt 1 oraz 2) a następnie za pomocą komendy: ip arp inspection vlan <id_sieci_VLAN> uaktywniamy mechanizm Dynamic ARP Inspection (punkt 3). Polecenia wydajemy w trybie konfiguracji globalnej.

Oba potrzebne mechanizmy zostały uruchomione.

Przechodzimy do konfiguracji interfejsu f0/1 gdyż to do tego portu podłączony jest serwer DHCP. W trybie konfiguracji interfejsu definiujemy ten port jako zaufany dla obu włączonych procesów:

ip dhcp snooping trust - mechanizm DHCP snooping,
ip arp inspection trust - mechanizm Dynamic ARP Inspection.

Reszta interfejsów przełącznika otrzymuje status portu niezaufanego - no ip arp inspection trust (punkt 1). Dodatkowo zostaje określony próg możliwych do wystąpienia w czasie jednej sekundy pakietów ARP (punkt 2). Oczywiście możemy dodatkowo określić limit pakietów DHCP, leczy by nie wprowadzać dodatkowego zamieszania z dodatkowymi komendami z tej opcji zrezygnowałem - skupiamy się na Dynamic ARP Inspection.

Aby całość przeprowadzanej konfiguracji była prawidłowa a co za tym idzie by działanie mechanizmu odbywało się prawidłowo w trybie konfiguracji globalnej należy wydać jeszcze jedno polecenie: no ip dhcp snooping information option Zadaniem tej komendy jest przekazanie do serwera DHCP prawidłowego pakietu żądania by przydzielona konfiguracja sieciowa mogła zostać dostarczona do klienta. Temat sensu wydania tej komendy niestety wykracza poza ramy tego wpisu i dokładne wytłumaczenie istoty problemu wymagałoby zbyt obszernych wyjaśnień - co nie oznacza, że do tematu nie powrócę. Jeśli Czytelniku byłbyś szczególnie zainteresowany tym zagadnieniem odsyłam do wpisu - http://blog.ine.com/2009/07/22/understanding-dhcp-option-82/

Host 10.0.0.1 nawiązuje połączenie z serwerem DHCP i zostaje mu przypisany adres IP. Po przypisaniu adresu IP hostowi w tablicy DHCP snooping fakt ten powinien zostać odnotowany. Sprawdzenia tablicy dokonamy za pomocą polecenia: show ip dhcp snooping binding

Host 10.0.0.1 uzyskał dostęp do sieci i może prawidłowo komunikować się z innymi hostami.

A co w przypadku hosta atakującego? Host o adresie IP 10.0.0.30 korzysta z konfiguracji statycznej z pominięciem serwera DHCP. Pomimo prawidłowego skonfigurowania interfejsu sieciowego hosta nie ma on możliwości nawiązania poprawnej komunikacji z innymi komputerami. Test ping w połączeniu z adresem 10.0.0.20 kończy się niepowodzeniem.

Ślady przeprowadzenia testu ping odnajdziemy również w komunikatach przełącznika. Komunikacja hosta 10.0.0.30 z siecią jest niemożliwa gdyż w tablicy mechanizmu DHCP snooping brak jest wpisu odnoszącego się do tego komputera.

Spróbujmy sytuację naprawić i na hoście 10.0.0.30 modyfikujemy konfigurację sieciową poprzez zrezygnowanie z metody opartej o wpisy statyczne. Host został skonfigurowany w ten sposób aby potrzebne ustawienia sieci uzyskać dzięki serwerowi DHCP. Hostowi zostaje przypisany adres IP 10.0.0.31

Fakt przypisania adresu IP przez serwer DHCP odnajdziemy w tablicy DHCP snooping przełącznika.

Ponownie wykonujemy test ping - tym razem komunikacja pomiędzy komputerami 10.0.0.31 a 10.0.0.20 jest możliwa.

Weryfikację działania mechanizmu Dynamic ARP Inspection wraz z statystykami dokonamy dzięki wydaniu polecenia: show ip arp inspection

Konfigurację interfejsów w kontekście działania mechanizmu poznamy wydając komendę: show ip arp inspection interfaces

Lecz co się stanie gdy host 10.0.0.31 zacznie przeprowadzać atak zatrucia bufora ARP? Aby odpowiedzieć na to pytanie należy atak tego typu zasymulować. Na hoście 10.0.0.31 zostaje uruchomione narzędzie Ettercap. Jak zapewne pamiętasz Czytelniku pierwszym etapem przy definicji parametrów ataku jest przeprowadzenie skanowania aktywnych hostów. Proces skanowania zostaje uruchomiony lecz kończy się on niepowodzeniem gdyż ilość wygenerowanych pakietów ARP przekracza ustalony limit ustawiony dla interfejsu. Interfejs f0/3 zostaje wyłączony.

Sprawdzenie statusu portu wskazuje na stan err-disabled a za wyłączenie go odpowiada mechanizm Dynamic ARP Inspection.

Aby interfejs odblokować w trybie jego konfiguracji wydajemy polecenie: shutdown a następnie no shutdown.

Sprawdźmy co stanie się w sytuacji w której proces skanowania uda Nam się przeprowadzić i host 10.0.0.31 uruchomi atak ARP spoofing. Limit pakietów powodujących wyłączenie interfejsu zostaje zwiększony do 100. Proces skanowania tym razem przebiega bez zakłóceń i atakujący uruchamia atak.

Atak zostaje przerwany z powodu błędów w dopasowaniu adresów MAC oraz IP zapisanych w tablicy DHCP snooping.

Mechanizm inspekcji ARP zadziałał prawidłowo nie dopuszczając do przeprowadzenia ataku.

Udało Nam się zapobiec atakom zatrucia tablicy ARP poprzez konfigurację przełącznika lecz metody ochrony możemy również rozszerzyć o hosty (ale to już też Czytelniku wiesz) .

Sprawdźmy zatem jakie mamy możliwości by zapobiec atakowi ARP poprzez wykorzystanie do tego celu odrębnych aplikacji.

Powracamy po raz kolejny do narzędzia WinArpAttacker, do tej pory aplikacja ta służyła nam do przeprowadzania ataków na sieć teraz odwracamy rolę i pokażę jak wykorzystać te narzędzie by sieć ochronić.

Domyślnie po uruchomieniu programu, aplikacja przejmuje kontrolę nad tablicą ARP hosta na którym została uruchomiona i na bieżąco kontroluje czy nie zaszły w niej jakieś zmiany. Jeśli takowe nastąpią użytkownik zostanie o nich powiadomiony stosownym komunikatem.

Przejdźmy zatem do zobrazowania takiej sytuacji. Narzędzie zostało uruchomione na hoście o adresie IP 10.0.0.1 (kontrolą integralności tablicy zarządzamy za pomocą dwóch ikon Detect oraz Stop). W kolejnym kroku atakujący czyli host 10.0.0.30 przeprowadza atak mający na celu zatrucie tablicy ARP tak by możliwe było przechwytywanie ruchu sieciowego pomiędzy hostami 10.0.0.1 a 10.0.0.20.

Jak już wiesz Czytelniku by atak ARP powiódł się oryginalny adres MAC skojarzony z adresem 10.0.0.20 (08-00-27-AB-D3-93) musi zostać zamieniony na adres MAC atakującego (EE-EE-EE-EE-EE-EE) tak by wszystkie ramki były przekazywane przez niego.

Uruchomienie ataku wyzwala komunikat o zmianie domyślnego adresu MAC hosta 10.0.0.20 na adres MAC EE-EE-EE-EE-EE-EE Adres ten ulega zmianie lecz po chwili uruchomiona opcja ochrony tablicy ARP adres MAC atakującego ponownie zmienia na prawidłowy.

Jak można się domyśleć dzięki narzędziu WinArpAttacker atak z wykorzystaniem zatrucia tablicy ARP nie dochodzi do skutku. Wydanie polecenia ping z hosta 10.0.0.1 w kierunku komputera 10.0.0.20 nie jest rejestrowane przez atakującego.

W systemie Linux spójność tablicy ARP możemy kontrolować za pomocą narzędzia: arpwatch Aby zainstalować niezbędne pakiety wydaj polecenie: apt-get install arpwatch Program ten po uruchomieniu kontroluje stan tablicy ARP na komputerze lokalnym i jeśli zajdzie zmiana fakt ten zostanie zarejestrowany w pliku: /var/log/syslog

Aby uruchomić narzędzie wydajemy polecenie: /etc/init.d/arpwatch start (punkt 1) a następnie za pomocą komendy: arpwatch -i <identyfikator_interfejsu_sieciowego> określamy interfejs, który ma podlegać nadzorowi (punkt 2).

W opisie przyjęto iż host o adresie IP 10.0.0.1 to ofiara (na hoście tym zostaje uruchomiony daemon arpwatch) natomiast atakujący to komputer o adresie IP 10.0.0.30 i tak jak w przypadku sytuacji z wykorzystaniem aplikacji WinArpAttacker naszym celem jest przechwycenie ruchu sieciowego pomiędzy komputerami 10.0.0.1 a 10.0.0.20

Narzędzie zostało uruchomione i działa w tle aby mieć podgląd na pojawiające się komunikaty wydaj polecenie: tail -f /var/log/syslog

Atakujący przeprowadza atak zatrucia tablicy ARP. Uruchomiona usługa arpwatch wykrywa zamianę adresu MAC i Nas o fakcie tym informuje. Niestety w tym przypadku nie mamy aktywnej ochrony jak to miało miejsce przy wykorzystaniu programu WinArpAttacker i atak kończy się sukcesem, atakujący może przechwytywać ruch sieciowy (na razie, gdyż administrator wie, że atak nastąpił i może do następnego nie dopuścić - atakujący został wykryty).

Arpwatch oprócz zamiany adresów MAC wykrywa również ataki typu LAN storm, które związane są z protokołem ARP, gdy atak nastąpi stosowne komunikaty pojawią się w pliku /var/log/syslog Poniżej przedstawiono zrzut pliku w którym zarejestrowano przebieg ataku zalewania sieci pakietami ARP Request.

W zarządzanej sieci komputerowej interfejsy sieciowe, które pracują w trybie nasłuchiwania (ang. promiscuous mode) stanowią potencjalne zagrożenie gdyż karta sieciowa pracująca w tym trybie zdolna jest do rejestrowania danych, które nie są dla niej przeznaczone. Wykrycie interfejsów sieciowych pracujących w tym trybie jest sygnałem dla administratora sieci, że dzieje się coś niepokojącego.

Aby wykryć w zarządzanej sieci interfejsy, które korzystają z tego trybu można posłużyć się m.in. narzędziem WinArpAttacker. Po uruchomieniu programu z górnego menu wybieramy pozycję Scan a następnie opcję Advanced, która to uruchomi dodatkowe okno za pomocą którego zdefiniujemy opcję skanowania.

W oknie Scan określamy zakres skanowania oraz jego tryb. Zaznaczenie opcji Antisniff scan spowoduje przeprowadzenie skanowania pod kątem wystąpienia interfejsów pracujących w trybie nasłuchiwania. Operacja skanowania polega na wysłaniu specjalnie spreparowanych pakietów i badaniu uzyskanych odpowiedzi. Szczegółowy opis klasyfikacji interfejsu, który pracuje w trybie domyślnym bądź w trybie promiscuous wykracza poza ramy tego wpisu więc procedurę przyszeregowania interfejsu do danego trybu pracy postaram opisać się w oddzielnym wpisie. Jeśli ten temat Czytelniku szczególnie Cię interesuje odsyłam do wpisów zawartych pod następującymi odnośnikami (wersja angielska) - http://www.securityfriday.com/promiscuous_detection_01.pdf bądź http://hadmernok.hu/132_27_nagyd_1.pdf

Po zatwierdzeniu skanu przyciskiem Scan następuje proces odkrywania urządzeń, których karty sieciowe pracują w trybie promiscuous. Jak widać poniżej skan naszej ćwiczebnej sieci uwidocznił dwa takie interfejsy - pierwszy z nich (10.0.0.1) to interfejs komputera przeprowadzającego skanowanie a drugi (10.0.0.30) należy do atakującego.

W systemie Linux (lecz także Windows) do skanowania możemy użyć narzędzia NMap a mówiąc bardziej szczegółowo jednego ze skryptów napisanych dla tego programu, którego celem jest wykrycie interfejsów pracujących w trybie nasłuchiwania.

Aby uruchomić proces skanowania należy wydać polecenie: nmap --script=sniffer-detect <zakres_skanowania>

Poniżej zaprezentowałem proces skanowania dwóch hostów o adresach IP 10.0.0.30 oraz 10.0.0.20 i jak można zauważyć w przypadku tego pierwszego skan ujawnił iż interfejs tego hosta jest ustawiony do pracy w trybie promiscuous.

Ataki typu LAN storm mogą zostać unieszkodliwione dzięki zastosowaniu funkcji przełącznika nazwanej storm control, której zadaniem jest monitorowanie poziomu ruchu sieciowego.

Mechanizm Storm control do pomiaru aktywności ruchu sieciowego może wykorzystywać jedną z następujących metod:

pomiar szerokości pasma jako procent całkowitego pasma dostępnego na porcie,
pomiar szybkości w jakiej odbierane są pakiety - szybkość tą możemy wyrazić w packets/sec lub bits/sec.

Można ustawić zarówno próg ruchu narastającego, jak i próg ruchu opadającego.

Nieważne z której metody skorzystamy, gdy zostaje osiągnięty zdefiniowany próg, port zostaje zablokowany.

Jeśli zdefiniowano tzw. próg opadający blokowanie portu następuje powyżej ustalonej wartości zaś gdy poziom ruchu sieciowego opadnie poniżej zdeklarowanej wartości port powraca do normalnego funkcjonowania.

Mechanizm ten konfigurujemy w trybie danego interfejsu poprzez ustalenie wartości progowych dla danego typu ruchu.

W przypadku wybrania metody opartej na określeniu procentu dostępnego pasma, dostępne wartości ustalamy z przedziału od 0.00% do 100.00%. Przy czym wartość 100.00% oznacza, że na dany typ ruchu nie nałożono żadnego limitu zaś wartość 0.00% oznacza, że cały ruch danego typu na porcie jest blokowany.

Przejdźmy zatem do części praktycznej i sprawdźmy mechanizm w działaniu. Ponieważ stacja atakującego jest podpięta do interfejsu f0/3 przełącznika tak więc funkcję tą włączymy właśnie na tym porcie.

1 - wydanie polecenia spowoduje ustalenie dozwolonego progu ruchu broadcast na 12,5%,

2 - ustalenie progu ruchu multicast na poziom - próg narastający 3000 pakietów w ciągu sekundy, próg opadający 2000 pakietów na sekundę (po przekroczeniu wartości 3k pps następuje blokada portu zaś gdy ruch opadnie do wartości poniżej 2k pps port zostaje włączony),

3 - ustalenie akcji związanej z przekroczeniem wartości progowych - w tym przypadku wyłączenie portu. Wydanie polecenia: storm-control action trap switch spowoduje wysłanie loga SNMP w momencie pojawienia się burzy pakietów.

Weryfikację ustawień możemy przeprowadzić wydając polecenia: show storm-control bądź show storm-control <określony_typ_ruchu_sieciowego>

Mechanizm został skonfigurowany. Przechodzimy na hosta atakującego i na nim zostaje uruchomiony atak generujący dużą ilość pakietów broadcast (atak typu DHCP consumption attacks). Chwilę po uruchomieniu ataku port zostaje wyłączony - zdefiniowany procent wykorzystania pasma dla tego typu ruchu został przekroczony.

Status interfejsu możemy sprawdzić wydając komendę: show interfaces status err-disabled Jak widzimy poniżej port jest wyłączony z powodu naruszenia zdefiniowanej polityki bezpieczeństwa związanej z mechanizmem storm-control.

Aby interfejs odblokować w trybie jego konfiguracji wydajemy polecenie: shutdown a następnie no shutdown.

Podsumowując wpis aby uniknąć opisywanych ataków zastosuj się do poniższych wskazówek:

pamiętaj, że bezpieczeństwo sieci do również ochrona fizyczna dostępu do urządzeń oraz do komputerów,
protokoły z których nie korzystasz - wyłącz,
nieużywane interfejsy przełącznika - wyłącz a te do których są podpięte urządzenia końcowe ustaw do pracy w trybie access,
skonfiguruj mechanizm Port Security,
odseparuj dostęp zdalny do urządzeń sieciowych od sieci domyślnej, utwórz do tego celu osobny VLAN,
realizując dostęp zdalny nie wykorzystuj protokołu Telnet, zamień go na SSH,
celem analizowania ruch sieciowego wykorzystaj funkcję SPAN,
pamiętaj o takich mechanizmach jak Dynamic ARP Inspection, DHCP Snooping oraz Storm control,
rozważ wprowadzenie ochrony dostępu do sieci w oparciu o wykorzystanie protokołu 802.1X

I tu kończymy. Wyszło tego sporo. Powiem szczerze, że w planach miałem opisanie również bardziej subtelnych ataków związanych z sieciami VLAN, protokołem STP czy połączeniami typu trunk ale postanowiłem to rozbić na odrębne wpisy ze względu na dość obszerny zakres omawianego tematu. Jak mówi stare przysłowie - „Co się odwlecze, to nie uciecze” tak więc do tematu wrócimy już wkrótce (jeden wpis a już obiecałem 4 inne).

I tak już na sam koniec - złota myśl (gdzieś kiedyś to usłyszałem i strasznie mi się spodobało, bo wiele prawdy w tym) - pamiętaj, że BEZPIECZEŃSTWO JEST ZAWSZE KOSZTEM WYGODY

BIBLIOGRAFIA

http://www.thegeekstuff.com/2012/05/ettercap-tutorial

https://pentestmag.com/ettercap-tutorial-for-windows/

www.hacking-tutorial.com/hacking-tutorial/kali-linux-man-middle-attack

https://docs.oseems.com/general/operatingsystem/linux/sniff-network-traffic

http://kalilinuxtutorials.com/macof/

http://www.irongeek.com/i.php?page=backtrack-3-man/ettercap

https://pentestmag.com/ettercap-tutorial-for-windows/

Rejestracja zdarzeń z wykorzystaniem serwera Syslog.

2016-11-18T20:16:24+00:00

Zarządzając daną siecią komputerową najkorzystniejszą dla Nas sytuacją i stanem jak najbardziej pożądanym jest prawidłowo działająca sieć. Nasze wszystkie działania administracyjne sprowadzają się do tego by osiągnąć stan pełnej funkcjonalności sieci. Jeśli wszystko działa - możemy być z siebie dumni lecz nie oznacza to, że możemy spocząć na laurach. Awarie sieci i urządzeń ją tworzących są na porządku dziennym i prędzej czy później każdy administrator z takim problemem będzie musiał się zmierzyć. Z reguły awarie i mogące nastąpić komplikacje w działaniu sieci można z dość dużą dozą prawdopodobieństwa przewidzieć. No chyba, że mamy do czynienia z sytuacją nagłą, taką jak przepięcie w sieci elektrycznej, której efektem jest uszkodzenie urządzenia bądź atakiem hackerskim. Ale jak to już w życiu bywa nie do końca na wszystko mamy wpływ.

Aby móc przewidzieć nadciągającą „katastrofę” musimy oczywiście mieć narzędzia i metody, które zawczasu pozwolą nam na stwierdzenie, że dzieje się coś złego. Rozwiązaniem, które pozwoli nam na zareagowanie w przypadku wystąpienia pierwszych symptomów związanych z nieprawidłowo działającą siecią jest raportowanie i logowanie zaistniałych zdarzeń.

Konfiguracja logowania zdarzeń dla kilku urządzeń nie jest dużym wyzwaniem i jest stosunkowo prosta oraz nie zajmująca wiele czasu. Sytuacja komplikuje się wraz ze wzrostem liczby zarządzanych urządzeń. W obu przypadkach bardzo znaczącym ułatwieniem dla administratora będzie gdy logi zaistniałych zdarzeń będą zapisane w jednym centralnym miejscu.

Aby móc zacząć zapisywać logi przy wykorzystaniu specjalnie do tego celu skonfigurowanej maszyny możemy posłużyć się jednym z dwóch rozwiązań:

zastosować serwer Syslog,
wykorzystać protokół SNMP.

Pierwsze z rozwiązań to tzw. usługa obsługi logów systemowych, potocznie nazywana Sysylog. Usługa do działania wykorzystuje protokół UDP wraz z portem 514. Pełna specyfikacja usługi została opisana w RFC5424

Zaś protokół SNMP (ang. Simple Network Management Protocol) to rodzina protokołów sieciowych odpowiedzialnych za zarządzanie i monitorowanie stanu urządzeń sieciowych (routery, przełączniki, komputery, macierze dyskowe czy sprzętowy firewall). Protokół ten działa w warstwie aplikacji i domyślnie, tak jak jego poprzednik do działania wykorzystuje protokół UDP w połączeniu z portami 161 oraz 162. Szersze informacje na temat działania protokołu znajdziesz w RFC1157 (wersja SNMPv1), RFC1901 (wersja SNMPv2) oraz RFC3414 (wersja SNMPv3).

Temat obsługi protokołu SNMP jest bardzo szeroki tak więc samym tym protokołem i jego zastosowaniem zajmiemy się w osobnym wpisie, zaś w tym skupimy się na wykorzystaniu serwera Syslog.

Przepływ informacji pomiędzy serwerami zbierającymi informacje o stanie urządzeń a zarządzanymi urządzeniami może odbywać się dwoma ścieżkami:

Metoda out-of band (OOB) - do przesyłania informacji o stanie urządzeń wykorzystywana jest dedykowana sieć. Sieć ta jest niezależna od sieci produkcyjnej, co oznacza, że gdy sieć główna przestaje działać nadal możliwe jest zarządzanie i monitorowanie urządzeń.

Metoda in-band do monitorowania wykorzystuje sieć produkcyjną czyli sieć w której domyślnie prowadzona jest cała komunikacja. Dobrą praktyką wykorzystywaną przy wyborze tego rozwiązania jest odseparowanie ruchu sieciowego związanego z monitorowanie bądź zarządzaniem od reszty prowadzonej komunikacji. Separację ruch sieciowego możemy przeprowadzić w warstwie 2 przy wykorzystaniu sieci prywatnych VLAN.

Poniżej na rysunku schematycznie przedstawiono obie metody.

Od razu nasuwa się pytanie – Który model wybrać? Oczywiście lepszym rozwiązaniem będzie wykorzystanie metody out-of band gdyż w przypadku problemów z siecią główną mamy do dyspozycji dodatkowy kanał komunikacyjny, który możemy wykorzystać do rozwiązania zaistniałych problemów. Metoda ta pomimo dużej zalety w postaci zastosowania redundancji połączeń niestety ma zasadniczą wadę – koszt wdrożenia (koszty związane z infrastrukturą oraz wykorzystaniem zasobów sprzętowych urządzeń). Dlatego też znacznie częściej wybierana jest metoda in-band.

Na co zwrócić uwagę przy wykorzystaniu rozwiązań opartych o rejestrowanie zdarzeń:

Jakie protokoły monitorowania wspiera i obsługuje dane urządzenie?
Jaki typ logów powinien być rejestrowany?
Jak oddzielić informacje ważne (krytyczne) od tych rutynowych (informacyjne, diagnostyczne)?
Jak radzić sobie z dużą ilością logów?
Jak śledzić zmiany, gdy wystąpi awaria sieci bądź atak?
Jak zapewnić integralność otrzymywanych danych m.in. znaczniki czasu?
Jak nie dopuścić do manipulacji przy logach?
Które z logowanych danych mogą być potrzebne w śledztwie?

Jak widać powyżej jest szereg pytań na które musimy sobie odpowiedzieć by móc skutecznie prowadzić proces gromadzenia informacji. Mam nadzieję, że po lekturze tego wpisu na tak postawione pytania znajdziesz Czytelniku odpowiedzi.

Urządzenia sieciowe powinny być skonfigurowany do wysyłania komunikatów na jeden lub więcej sposobów. Urządzenia firmy Cisco (routery, przełączniki) obsługują komunikaty dziennika:

Console - router domyślnie wszystkie komunikaty dotyczące pracy urządzenia wysyła do swojego portu konsoli. Dostęp do tych komunikatów mają użytkownicy, którzy mają zestawione połączenie z portem konsoli – tzw. rejestrowanie konsolowe (ang. console logging).

Rejestrowanie terminalowe (ang. terminal logging) - bardzo podobne do rejestrowania przy użyciu portu konsoli z tą różnicą iż komunikaty wysyłane są do linii VTY. Wymaga dodatkowego uaktywnienia.

Rejestrowanie z wykorzystaniem bufora (ang. buffered logging) - komunikaty o stanie dziennika są zapisywane i przechowywane w pamięci RAM urządzenia. Do tego celu rezerwowana jest stała część pamięci RAM. Rozmiar bufora ogranicza przechowywanie dużej ilości logów tak więc w przypadku przepełnienia następuje kasowanie najstarszych wiadomości.

SNMP Server (ang. SNMP trap logging) – komunikaty o stanie urządzenia są wysyłane i zapisywane na zewnętrznym serwerze. Obsługa logów jest realizowana przy wykorzystaniu protokołu SNMP.

Syslog Server – tak jak w metodzie powyżej za odbiór i zapis logów odpowiada zewnętrzny serwer. Rejestrowanie zdarzeń w przypadku tej metody domyślnie jest wyłączone. Przesyłanie odbywa się z pominięciem faktu potwierdzenie przesyłanych raportów.

Przy konfiguracji danej metody zapisu zdarzeń należy mieć na uwadze, że miejsce logowania wpływa na ogólne obciążenie systemu. Poniżej lista użytych metod uszeregowana od stopnia wpływu na obciążenie systemu (góra=duże obciążenie, dół=małe obciążenie).

logowanie do konsoli,
logowanie do VTY,
logowanie do zewnętrznego serwera,
logowanie do bufora.

W przypadku wykorzystania serwera Syslog, serwerem będziemy określać hosta, którego zadaniem jest odbiór i przetwarzanie logów otrzymywanych od klientów. Natomiast klientem będzie host/urządzenie sieciowe, które logi generuje i przekazuje je w kierunku serwera Syslog.

W przypadku urządzeń Cisco komunikaty generowane przez urządzenie możemy podzielić w zależności od poziomu ich ważności. Poziom komunikatów został ustalony od 0 do 7 a im niższy poziom komunikatu, tym z bardziej krytycznym zdarzeniem będziemy mieli do czynienia.

Poniżej w tabeli zostały zebrane możliwe poziomy ważności zdarzeń wraz z przykładowymi zdarzeniami generującymi dany typ komunikatu.

Poziom	Nazwa poziomu	Definicja syslog	Opis	Przykładowe zdarzenie generujące błąd
0	Emergencies	LOG_EMERG	Router/przełącznik ma poważne problemy by poprawnie funkcjonować	Brak możliwości załadowania systemu operacyjnego, uszkodzenie modułu wentylatorów
1	Alerts	LOG_ALERT	Potrzebna natychmiastowa interwencja	Wzrost temperatury pracy
2	Critical	LOG_CRIT	Sytuacja krytyczna	Błędy alokacji pamięci, problem sprzętowy
3	Errors	LOG_ERR	Błędy	Zmiana stanu pracy interfejsu
4	Warnings	LOG_WARNING	Ostrzeżenie	Niepowodzenie wykonania polecenia bądź instrukcji, błędy szyfrowania
5	Notifications	LOG_NOTICE	Powiadomienie	Aktywacja/dezaktywacja protokołu łącza
6	Informational	LOG_INFO	Komunikaty informacyjne	Naruszenie listy dostępu ACL
7	Debugging	LOG_DEBUG	Informacje uzyskane dzięki włączeniu procesu debugowania	Zależy od wybranego procesu debugowania

Poniżej zaprezentowano przykładowy komunikat dziennika routera Cisco.

Jak można zauważyć powyżej komunikat dziennika składa się z dwóch bądź trzech części. Obowiązkowymi elementami komunikatu jest nazwa poziomu wraz z jego identyfikatorem oraz tekst informacyjny. Opcjonalnym elementem jest znacznik czasowy. Włączenie znacznika odbywa się za pomocą polecenia: service timestamp wydanego w trybie konfiguracji globalnej.

Kolejną częścią komunikatu jest jego kod oraz poziom ważności. W przykładzie powyżej kodem jest SYS oraz LINK, natomiast poziom ważności został ustalony w przypadku pierwszego komunikatu na poziom 5 czyli Notifications, drugi komunikat jest poziomu 3 czyli Errors. Jak już wspomniano komunikaty klasyfikuje się według poziomu czyli komunikaty poziomu 7 są najmniej ważne zaś te poziomu 0 mają znaczenie krytyczne. Dodatkowo dołączana jest informacja o zaistniałym zdarzeniu. W przypadku rozważanych komunikatów jest to informacja o przeprowadzonej konfiguracji z wykorzystaniem połączenia linii VTY – CONFIG_I oraz włączeniu interfejsu – UPDOWN.

Ostatnią częścią wpisu jest treść informacyjna poszerzająca komunikat o dodatkowe szczegóły zarejestrowanego zdarzenia.

Zanim rozpoczniemy zbieranie informacji o zaistniałych zdarzeniach, warto na wszystkich urządzeniach, które będą podlegać temu procesowi wykonać konfigurację daty oraz czasu. Jak ustawić czas ręcznie bądź wykorzystać do tego celu protokół NTP przeczytasz w wpisie: Zarządzanie routerem CISCO

Nasze rozważania rozpoczniemy od włączenia rejestrowania lokalnego.

1 - rejestrowanie włączymy z wykorzystaniem polecenia: logging buffered <poziom_komunikatu>,

2 - za pomocą komendy: logging buffered <wartość> określamy maksymalny rozmiar bufora w którym będą przechowywane logi zdarzeń.

Domyślny poziom ważności rejestrowanych komunikatów obejmuje zapisywanie wszystkiego, oznacza to, że wydanie samego polecenia: logging buffered spowoduje ustawienie rejestracji zdarzeń na poziomie 7 (debugowanie). Wybranie poziomu debugowania jest jednoznaczne z zapisywaniem zdarzeń poziomów niższych. Dlatego też by ograniczyć liczbę zbieranych i przechowywanych logów ich ilość możemy kontrolować poprzez definicję poziomu (severity level). Maksymalny poziom ważności rejestrowanych komunikatów określamy za pomocą słów kluczowych (patrz tabela powyżej, kolumna nazwa poziomu) bądź numeru poziomu.

Domyślny rozmiar bufora zarezerwowany na potrzeby przechowywania logów wynosi 4096 bajtów (nie jest to wartość stała obejmująca wszystkie modele routerów). Jest to niewiele i bardzo często rozmiar ten przez administratorów jest modyfikowany tak by pomieścić większą liczbę wpisów. Domyślny rozmiar bufora pozwala na przechowanie około 50 wpisów. Po przekroczeniu rozmiaru dziennika najstarsze wpisy są usuwane tak by zrobić miejsce na nowsze. Wielkość ustalonego bufora ma wpływ na ilość dostępnej pamięci RAM - im więcej zarezerwujemy na potrzeby dziennika tym mniej pamięci router będzie miał do wykorzystanie podczas realizacji swoich podstawowych zadań.

Historie zaistniałych zdarzeń możemy przeglądać za pomocą polecenia: show logging Logi systemowe zostały uszeregowane od najstarszego do najnowszego.

Dodatkowo po wydaniu polecenia poznamy takie informacje jak:

1 - stan oraz ustalony poziom rejestrowania konsolowego. Aby wyłączyć wszystkie komunikaty routera o zaistniałych zdarzeniach wydaj polecenie: no logging console Po wydaniu polecenia zostanie wyłączone wyświetlanie jakichkolwiek komunikatów.

2 - stan oraz ustalony poziom rejestrowania zdalnego (o tym temacie szerzej już za chwilę).

3 - stan oraz ustalony poziom rejestrowania lokalnego z wykorzystaniem bufora.

4 - ustalony rozmiar dziennika.

Aby włączyć licznik wystąpień zdarzeń określonego rodzaju należy posłużyć się poleceniem: logging count Po włączeniu licznika stan zdarzeń przejrzymy po wydaniu komendy: show logging count

Aby wyłączyć zapis zdarzeń do bufora routera należy wydać polecenie: no logging buffered natomiast by wyczyścić zawartość bufora wydaj komendę: clear logging.

Omówienie rejestrowanie z wykorzystaniem zestawionej sesji zdalnej oraz serwera Syslog omówimy na przykładzie topologii sieciowej przedstawionej na rysunku poniżej.

Rejestrowanie zdarzeń jak już wiesz Czytelniku możemy również prowadzić z wykorzystaniem zestawionej sesji wykorzystującej linie VTY.

Aby włączyć wyświetlanie zdarzeń podczas sesji połączenia zdalnego należy wydać polecenia:

1 - logging monitor <poziom_komunikatu> (w trybie konfiguracji globalnej) – wydanie polecenie uruchamia rejestrowanie terminalowe,

2 - dodatkowo proces należy uruchomić oddzielnym poleceniem: terminal monitor (tryb EXEC).

Właściwe polecenia zostały wydane sprawdźmy zatem ich efekt. Poniżej zostało nawiązane połączenie zdalne z routerem R1 z hosta o adresie IP 192.168.0.1, celem sprawdzenia faktu rejestracji został włączony i wyłączony interfejs f0/1 routera R1.

Jak widać powyżej żaden komunikat o zmianie statusu interfejsu f0/1 nie został wyświetlony. Nasuwa się pytanie – Dlaczego wyświetlenie komunikatów o zdarzeniach podczas trwania sesji zdalnej nie działa?

Powodem takiego stanu rzeczy jest błędna lokalizacja wydania polecenia: terminal monitor O ile samo włączenie rejestrowania terminalowego możemy wykonać na routerze (polecenie te jest wydawane w trybie konfiguracji globalnej tak więc obowiązuje niezależnie od miejsca jego wydania) to już włączenie rejestrowanie VTY powinno odbyć się oddzielnie dla każdego nawiązanego połączenia.

Poprawny zatem konfigurację i sprawdźmy efekty.

Zostaje nawiązane połączenie z routerem R1 i po zestawieniu sesji w trybie uprzywilejowanym administrator wydaje polecenie: terminal monitor W kolejnym kroku ponownie zostają wydane polecenia nakazujące włączenie a następnie wyłączenie interfejsu f0/1 routera. Jak widać, tym razem o zaistniałych zmianach w konfiguracji urządzenia jesteśmy informowani stosownymi komunikatami.

Rejestrowanie zdarzeń z wykorzystaniem połączenia zdalnego działa.

Przejdźmy zatem do metody zbierania logów z wykorzystaniem zewnętrznego serwera Syslog.

Do obsługi i zapisu logów zdarzeń wysyłanych przez urządzenia budujące naszą sieć, niezbędne jest posiadanie dodatkowego oprogramowania.

W wpisie tym zajmiemy się oprogramowaniem pracującym pod kontrolą systemu Windows (system Linux będzie omówiony w oddzielnym wpisie). Do zaproponowania mam dla Ciebie Czytelniku trzy programy:

Kiwi Syslog Server - to oprogramowanie do zarządzania logami systemowymi, program oferuje wiele funkcji od pobierania, rejestrowania i przekazywania logów systemowych, SNMP czy dziennika zdarzeń Windows do powiadamiania o zaistniałych zdarzeniach. Program obsługuje routery, switche, hosty z zainstalowanym systemem Windows oraz Linux. Kiwi Syslog Server występuje w dwóch wersjach: płatnej oraz darmowej. Wersja bezpłatna pozwala na rejestrowanie zdarzań przy wykorzystaniu protokołu Syslog oraz SNMP. Ilość obsługiwanych urządzeń została ograniczona do 5, dodatkowo brak jest funkcjonalności archiwizacji logów, powiadomień o zaistniałym zdarzeniu (alarm, email) oraz konfiguracji opartej o www. Wersja płatna oczywiście opisanych ograniczeń nie posiada. Program można pobrać ze strony: http://www.kiwisyslog.com/free-edition.aspx

Drugim programem jest 3CDaemon. Program jest całkowicie darmowy i jedną z jego funkcjonalności jest rejestrowanie zdarzeń przy wykorzystaniu Syslog. Dodatkowo program oferuje funkcjonalność serwera FTP czy TFTP. Oznacza to, że w bardzo prosty sposób możemy np. archiwizować konfigurację routerów czy switchy wykorzystując do tego jeden z dwóch wymienionych protokołów. Narzędzie niestety nie obsługuje protokołu SNMP. Program pobierzesz ze strony: http://www.firewall.cx/downloads/ftp-tftp-servers-a-clients/16-1-3cdaemon-server-a-client.html

Ostatnim zaś programem jest tftpd32/64. Narzędzie te jak pozostałe również pełni rolę serwera Syslog lecz ma bardzo ograniczone możliwości (pewnie niektórym tak minimalistyczne podejście do tematu się spodoba).

Po pobraniu i zapisaniu Kiwi Syslog Server rozpoczynamy instalację programu. Instalacja programu przebiega standardowo z małym wyjątkiem. Podczas instalacji zostaniemy zapytani – Czy program po instalacji ma pracować jako usługa czy aplikacja? Wybranie usługi spowoduje uruchomienie serwera za każdym razem gdy zostanie włączony system. Konsekwencją zainstalowania programu jako usługi będzie niemożność uruchomienia innych narzędzi rejestrujących zdarzenia z wykorzystaniem metody Syslog bądź SNMP, zaś zaletą wybrania tego rozwiązania jest ciągła rejestracja napływających informacji. Wybranie opcji drugiej spowoduje zainstalowanie narzędzia, tak jak standardowej aplikacji.

My decydujemy się na instalację opartą o usługę. Dlatego też w kolejnym kroku musimy zdefiniować poziom uprawnień z których będzie korzystał serwer. Do wyboru mamy dwie opcje: konto systemowe bądź inne zdefiniowane przez nas konto.

W kolejnym kroku definiujemy typ instalacji oraz wybieramy opcjonalne czynności, które zostaną wykonane wraz z instalacją programu.

Po definicji wszystkich ustawień następuje instalacja narzędzia.

W przypadku 3CDaemon pobieramy spakowany plik w formacie ZIP po rozpakowaniu, którego instalujemy program. Instalacja przebiega w sposób standardowy.

Po uruchomieniu narzędzia Kiwi Syslog Server warto zajrzeć do opcji programu aby zapoznać się z jego możliwościami. Do ustawień dostaniemy się po wybraniu z menu File opcji Setup (skrót Ctrl+P).

Warto również zajrzeć do menu Manage gdzie między innymi możemy włączyć/wyłączyć usługę serwera czy przeprowadzić proste testy diagnostyczne sprawdzające czy np. wiadomości nie będą blokowane przez zaporę systemową.

Aby narzędzie Kiwi Syslog Server mogło prawidłowo odbierać logi o zaistniałych zdarzeniach, należy skonfigurować jeszcze jedną opcje. Opcja ta związana jest z ograniczeniem wersji darmowej do pięciu urządzeń. Aby określić urządzenia, których logi będą rejestrowane należy przejść do ustawień programu i na karcie Inputs określić adresy IP urządzeń, które będą podlegały procesowi rejestrowania.

Narzędzie Kiwi Syslog Server jest gotowe do odbierania wiadomości.

Nadszedł czas by skonfigurować router, przechodzimy do linii poleceń routera R1.

Aby router mógł przesyłać logi do zewnętrznego serwera Syslog należy wydać polecenia:

1 - określamy adres IP serwer Syslog z wykorzystaniem polecenia: logging host <adres_IP_serwera_Syslog>,

2- określamy poziom wysyłanych komunikatów - polecenie: logging trap <poziom>,

3 - za pomocą polecenia: logging source-interface <interfejs> możemy określić interfejs wyjściowy,

4 - włączamy proces wysyłania powiadomień - polecenie: logging on

Sprawdźmy zatem efekt przeprowadzonej konfiguracji.

Jak można zauważyć poniżej efekt wydania poleceń włączenia/wyłączenia interfejsu f0/1 routera R1 znajduje odzwierciedlenie w logach serwera Syslog.

Ponieważ program Kiwi Syslog Serwer działa jako usługa nie musi on być fizycznie uruchomiony by móc logi o zaistniałych zdarzeniach odbierać.

Do określenia ważności przesyłanych komunikatów użyto polecenie: logging trap <poziom>, pominięcie polecenia spowoduje włączenie wysyłania komunikatów o poziomie ważności: informational. W przypadku ustawienia większej liczby serwerów logowania definicja poziomu ważności obowiązuje dla wszystkich. Nie ma możliwości określenia poziomów dla każdego z serwera Syslog osobno.

Sprawdzenie ustawionego poziomu ważności komunikatów zweryfikujemy wydając komendę: show logging

Konfigurację rejestrowania zdarzeń przy użyciu serwera Syslog można również przeprowadzić z wykorzystaniem nazw domenowych. Poniżej na zrzucie został zaprezentowany przykład takiej konfiguracji.

1 - router jest wstanie rozwiązywać nazwy hostów przy użyciu serwera DNS, warunkiem oczywiście jest istnienie takiego serwera w naszej sieci, dlatego też gdy w naszej sieci serwer DNS nie istnieje dobrze jest wykonać odwzorowanie typu: adres IP-nazwa hosta. Wykonanie odwzorowywanie uchroni nas przed sytuacją w której serwer DNS uległ awarii, gdyż router w swojej konfiguracji posiada wpis, który pozwoli mu powiązać adres IP z nazwą domenową hosta. Przypisanie adresu IP do odpowiadającej nazwy domenowej hosta wykonamy za pomocą polecenia: ip host <nazwa_domenowa> <adres_IP> W przykładzie poniżej hostowi o adresie IP 192.168.0.1 została przypisana nazwa yyy.firma.local (taka jest nazwa domenowa serwera Syslog). Po dokonaniu przypisania nazwy domenowej hosta możemy używać w poleceniach – np. sprawdzenie dostępności hosta przy wykorzystaniu polecenia: ping (punkt 3).

2 - po utworzeniu dowiązania włączamy logowanie, lecz tym razem zamiast adresu IP podajemy nawę hosta.

Reszta konfiguracji przebiega jak w przykładzie powyżej.

Rejestracja zdarzeń z wykorzystaniem aplikacji Kiwi Syslog Serwer została przeprowadzona prawidłowo czas zatem by przejść do kolejnego narzędzia.

Do przesyłania wiadomości o zdarzeniach skonfigurowaliśmy router R2 a do ich odbioru użyjemy narzędzia 3CDaemon.

Aby móc użyć programu do rejestracji logów musimy w pierwszej kolejności zatrzymać usługę serwera Kiwi Syslog (krok ten jest zbędny w przypadku instalacji serwera Kiwi jako aplikacji, brak zatrzymania usługi spowoduje błąd uruchomienia programu 3CDaemon). Zatrzymanie usługi wykonamy bezpośrednio z programu wybierając z menu Manage opcję Stop the Syslogd service Oczywiście usługę serwera Kiwi możemy również wyłączyć wykorzystując do tego okno: Usługi.

Po uruchomieniu programu 3CDaemon do dyspozycji mamy następujące ustawienia:

1 - Konfiguracja serwer Syslog – opcje konfiguracji programu są bardzo skromne wpływ mamy na: określenie ścieżki zapisu logów; określenie adresów IP urządzeń, których logi mają być zapisywane oraz zdefiniowane sposobu zapisu przychodzących komunikatów (wszystko do jednego pliku, zapis do plików w zależności od poziomu otrzymanego komunikatu, zapis do plików w zależności od kategorii wiadomości czy zapis do plików w zależności od adresu IP).

2 - Włączenie/wyłączenie serwera Syslog,

3 - Wyczyszczenie listy,

4 - Podgląd plików logów.

Sprawdźmy zatem działanie programu. Tak jak w przypadku Kiwi Syslog Serwer zasymulowano włączenie i wyłączenie interfejsu routera. Jak można się przekonać po analizie zrzutu poniżej logi do serwera Syslog zostały przesłane prawidłowo.

Zanim przejdziemy dalej z omawianiem konfiguracji urządzeń Cisco do współpracy z zdalnym rejestrowaniem zdarzeń zatrzymajmy się jeszcze chwilkę przy narzędziu 3CDaemon. Jak napisałem wyżej program pomimo tego, że posiada mało opcji konfiguracji serwera Syslog to rekompensuje nam to innymi funkcjami. Przy pomocy programu wykonamy szereg innych działań administracyjnych a nie potrzebujemy do tego dedykowanych aplikacji gdyż niezbędne funkcje są zaimplementowane już w samym programie.

Do tych podstawowych funkcji należy pełnie roli:

Serwera TFTP (ang. Trivial File Transfer Protocol) – zasada działania serwera opiera się na wykorzystaniu protokołu UDP wraz w połączeniu z numerem portu 69. W przypadku użycia TFTP jedyne co potrzeba by pobrać plik to adres IP serwera i nazwa pliku (nazw pliku jest niezbędna gdyż nie mamy możliwości wylistowania plików na serwerze). Protokół ten jest otwarty dla wszystkich tak więc brak w nim wsparcia dla takich mechanizmów jak: konta użytkowników, pewność dostarczenia przesyłanego pliku czy szyfrowanie. Główną zaletą protokołu jest jego prostota i łatwość wykorzystania. Gdy szybko chcemy z routera/przełącznika przesłać jakiś plik to przy użyciu tego protokołu wykonamy te zadanie bez żadnych problemów.

Konfiguracja narzędzia 3CDaemon sprowadza się do określenia katalogu w którym mają być zapisywane pliki wysyłane przez urządzenia/hosty zdalne.

Inne programy, które pełnią rolę serwera TFTP to: Open TFTP Server (narzędzie wiesza poleceń) oraz TFTPD32/64 (opisany poniżej).

Na większe możliwości pozwala nam wykorzystanie serwera FTP. Protokół FTP działa w oparciu o protokół TCP tak więc mamy pewność iż przesyłany plik dotrze do celu w niezmienionej postaci. O ile TFTP nadaje się świetnie np. do przesłanie kopii konfiguracji urządzenia (running-config) to już do zapisu pliku firmware urządzenia wykorzystanie go może przysporzyć nam problemów. Dlatego też w sytuacjach w których musimy mieć zapewnioną pewność przesyłania danych lepiej jest użyć protokołu FTP (o niezbędne funkcje związane z korekcją ewentualnych błędów zadba protokół TCP).

Konfiguracja narzędzia polega na określeniu konta użytkownika mogącego zestawić połączenie (możliwe jest skorzystanie z konta: anonymous), katalogu zapisu/odczytu plików oraz definicji praw.

Ostatnią funkcjonalnością narzędzia jest wykorzystanie programu w roli klienta TFTP. Skorzystanie z tej funkcjonalności powala nam na wysłanie pliku z hosta w kierunku innego serwer TFTP.

Aby móc skopiować dane należy określić adres IP serwera TFTP oraz wybrać plik, który ma zostać przesłany.

Ostatnim prezentowanym programem mogącym pełnić rolę serwera Syslog jest bezpłatna aplikacja Tftpd32/64, która pomimo swojej prostoty również umożliwi nam zbieranie informacji na temat zaistniałych zdarzeń. Tak naprawdę uruchomienie serwera Syslog sprowadza się tylko do włączenia samej aplikacji. Po włączeniu programu, narzędzie jest gotowe do pracy.

Opcje na którą mamy wpływ to określenie lokalizacji zapisu pliku logu.

Po uruchomieniu narzędzia program zaczyna zbierać logi. Poniżej zasymulowana sytuacja włączenia i wyłączenia interfejsu f0/1 routera R1. Jak widać aplikacja działa, logi są przekazywane prawidłowo.

Program nie tylko pełni role serwera Syslog ale również tak jak 3CDaemon można go wykorzystać jako serwer TFTP ale również narzędzie jest klientem TFTP. Unikatową funkcją Tftpd32/64 jest zaimplementowana rola serwera DHCP.

Przy korzystaniu z rejestrowania zdarzeń istnieje możliwość wyłączenia przesyłania komunikatów dotyczących najczęstszych zajść związanych z działanie interfejsów.

Zajścia te dotyczą wysyłania komunikatów w sytuacji zmiany stanu interfejsu z aktywnego na nieaktywny i z powrotem a także zmiany stanu podinterfejsów (oczywiście jeśli takowe zostały skonfigurowane).

Zasymulujmy więc sytuację w której włączymy i wyłączymy interfejs f0/1 routera R1. Jak można zauważyć po analizie poniższego zrzutu włączenie i wyłączenie interfejsu powoduje wyświetlenie stosownych komunikatów w linii poleceń konsoli oraz wysłanie ich do serwera Syslog (punkt 1).

W kolejnym kroku zostały wydane dwa dodatkowe polecenia (komendy wydajemy w trybie konfiguracji interfejsu):

no logging event link-status - polecenie wyłącza wyświetlenia komunikatów dotyczących zmiany stanu interfejsu f0/1 routera R1 (punkt 2),

no logging event subif-link-status - polecenie wyłącza wyświetlenia komunikatów dotyczących aktywacji bądź dezaktywacji łącza podinterfejsów (punkt 3).

Po dokonanych zmianach ponownie wykonujemy czynność włączenia i wyłączenia interfejsu f0/1. Tym razem brak jest jakichkolwiek komunikatów informujących o zaistniałej zmianie stanu łącza (komunikaty zostają również wyłączone dla linii poleceń konsoli) - punkt 4.

Prócz wyłączenia informowania o zmianie statusu interfejsu możemy również wykonać operację polegającą na ograniczeniu liczby wysyłanych danych do serwera Syslog. Domyślnie router bądź przełącznik wysyła wszystkie pojawiające się komunikaty. Czasem podczas prowadzonych działań może dojść do sytuacji w której bieżące komunikaty będą „zalewały” serwer Syslog (szczególnie gdy włączymy przetwarzanie zdarzeń na poziomie debugowania). Dlatego też by ograniczyć ich ilość możemy posłużyć się poleceniem: logging rate-limit <wartość>

Powyżej na rysunku skonfigurowano:

1 - ograniczenie liczby komunikatów do 20 z wyłączeniem zdarzeń o poziomie warnings (poziom 4) i niższych,

2 - ograniczenie liczby komunikatów do 20 z wyłączeniem zdarzeń o poziomie warnings (poziom 4) i niższych, komenda ta ze względu na użycie parametru: console ma zastosowanie do komunikatów pojawiających się w linii poleceń konsoli.

Zastosowane komendy spowodują włączenie ograniczenia wysyłania komunikatów do 20 na sekundę. Liczba ograniczonych komunikatów może przyjąć wartość z zakresu od 1 do 10000. Aby ograniczenie obowiązywało dla wszystkich poziomów należy użyć parametru: all (bądź ustalić ich poziom na: debugging).

I na tym etapie kończymy, nie wszystkie opcje zostały omówione gdyż zabrakło trochę więcej informacji na temat zmiany domyślnej kategorii wysyłania komunikatów, ale obiecuję to nadrobić w kolejnym wpisie w którym to również zajmiemy się rejestracją zdarzeń lecz tym razem serwer Syslog, będzie pracował pod kontrolą systemu Linux.

BIBLIOGRAFIA:

Configuring a Syslog Agent in Windows Server 2012 :: Windows Server 2012 :: Articles & Tutorials :: WindowsNetworking.com

6 Free Syslog Servers for Windows and Linux/Unix

tftpd32 | protocolSyntax

Listy kontroli dostępu ACL

2016-09-26T18:28:39+00:00

Administratorzy by sprawnie zarządzać swoją siecią muszą dysponować narzędziami, które pozwolą im na kształtowanie ruchu sieciowego według własnych potrzeb i wymagań. Takim narzędziem, które pozwala na filtrację pojawiających się w sieci pakietów jest lista ACL. Mechanizm ACL jest bardzo ważnym elementem konfiguracji routera gdyż pozwala na ustalenie zasad, które niepożądanym użytkownikom zabronią dostępu do sieci a tym zaufanym udostępnią niezbędne usługi.

ACL to lista z zdefiniowanymi instrukcjami zezwoleń bądź zakazów, która jest wykonywana sekwencyjnie (od góry do dołu). Instrukcje zawierają informacje o adresach IP, protokołach, numerach portów co do których ma być podjęta decyzja o odrzuceniu bądź przepuszczeniu danego pakietu.

Zastosowanie list ACL sprowadza się do:

Zapewnienie zabezpieczeń podczas dostępu do sieci - główny cel stosowania list ACL czyli kontrola nad dostępnością obszarów naszej sieci bądź usług, mówiąc prościej – tam gdzie jeden host ma umożliwiony dostęp, to drugiemu ten dostęp jest ograniczany. Dzięki listą ACL administrator ma możliwość definiowania obszarów oraz ich dostępności dla poszczególnych urządzeń budujących sieć.

Możliwość decydowania o typie przenoszonego ruchu sieciowego – w ramach listy ACL mogą zostać zdefiniowane dozwolone protokoły oznacza to możliwość przyznawania i odbierania użytkownikom praw dostępu do określonych usług np. dozwolony jest ruch sieciowy w ramach komunikacji WWW ale już ruch FTP nie.

Kontrola nad aktualizacjami tras routingu – listy ograniczają dostarczanie aktualizacji tras w ramach protokołu dynamicznego odpowiedzialnego za routing w sieci.

Ograniczenie ruchu w sieci i zwiększenie wydajności - np. blokada streamingu video spowoduje zmniejszenie obciążenia sieci przez co zwiększy się jej wydajność.

Decyzja o przepuszczeniu bądź odrzuceniu pakietu może być podejmowana w oparciu o takie informacje jak:

źródłowy adres IP,
docelowy adres IP,
źródłowy numer portu,
docelowy numer portu,
protokół,
inne (np. rodzaj wiadomości ICMP).

Gdy pakiet przechodzi przez dany interfejs routera do którego została przypisana lista ACL, jest ona przeglądana od góry do dołu, linijka po linijce celem wykrycia dopasowania z informacją zawartą w nagłówku pakietu.

Pierwsza linijka ACL, co do której nastąpi dopasowanie jest stosowana – jeśli w warunku listy została zdefiniowana instrukcja typu permit, pakiet jest przepuszczany, jeśli zaś w warunku istnieje instrukcja typu deny, pakiet jest odrzucany.

Kolejne warunki listy ACL nie są sprawdzane !!!!!!

Domyślnie na żadnym interfejsie nie ma założonych list ACL.

Listy ACL najczęściej zakłada się na routerach brzegowych czyli na styku sieci wewnętrznej a Internetem. Listy ACL również często są definiowane na routerach łączących dwa odrębne obszary sieci - np. sieć dla pracowników i sieć dla uczniów czy pomiędzy sieciami VLAN.

Listy ACL są definiowane osobno dla każdego protokołu (choć przy obecnej dominacji IP nie ma to już tak dużego znaczenia), kierunku oraz interfejsu.

per protocol – na protokół,
per direction – na kierunek,
per interface – na interfejs.

Jedna lista ACL kontroluje ruch na interfejsie w jednym kierunku (wejście: in bądź wyjście: out) dla danego protokołu. Jeśli router ma dwa interfejsy skonfigurowane dla protokołów IP, AppleTalk i IPX, potrzebnych będzie 12 oddzielnych list ACL.

2 interfejsy x 3 protokoły x 2 kierunki = 12 list ACL

Listy ACL są definiowane w trybie konfiguracji globalnej routera.

Podczas konfigurowania listy ACL należy jej nadać unikalny identyfikator (nie mogą istnieć dwie listy o tych samych identyfikatorach). Identyfikatorem listy ACL jest liczba.

Tworzenie listy dostępu następuje z wykorzystaniem polecenia: access-list <numer> <parametry>

Numer listy określa jej rodzaj.

Numery list ACL zostały określone następująco:

<1-99> - standardowa lista dostępu IP

<100-199> - rozszerzona lista dostępu IP

<1000-1099> - lista dostępu IPX SAP

<1100-1199> - rozszerzona lista dostępu 48-bitowych adresów MAC

<1200-1299> - lista dostępu adresu skonsolidowanego IPX

<1300-1999> - standardowa lista dostępu IP (rozszerzony zakres)

<200-299> - lista dostępu typu-kodu protokołu

<300-399> - lista dostępu DECnet

<600-699> - lista dostępu Appletalk

<700-799> - lista dostępu 48-bitowych adresów MAC

<800-899> - standardowa lista dostępu IPX

<900-999> - rozszerzona lista dostępu IPX

<2000-2699> - rozszerzona lista dostępu IP (rozszerzony zakres)

Podczas budowy warunków tworzących daną listę ACL należy zdefiniować sposób działania tzn. czy zezwalamy na dostęp (permit) czy go odbieramy (deny):

access-list numer permit ... lub access-list numer deny ...

Po zdefiniowaniu sposobu działania określamy adres IP lub nazwę hosta.

access-list numer permit A.B.C.D ... lub access-list numer deny A.B.C.D ...

Kolejnym krokiem jest definicja tzw. maski blankietowej określającej zakres adresów co do których warunek listy będzie miał zastosowanie. Lecz tu na chwilę zatrzymajmy się gdyż wprowadzanie na tym etapie pojęcia maski blankietowej zbyt by sprawę zagmatwało i przyjmijmy na ten moment, że lista ACL została zdefiniowana. Do tematu oczywiście wrócimy w dalszej części wpisu.

Po utworzeniu listy ACL nie można zapomnieć o przypisaniu jej do interfejsu routera.

Aby „założyć” listę na danym interfejsie routera przechodzimy do trybu konfiguracji interfejsu i za pomocą komendy: ip access-group <lista_ACL> {in|out} dokonujemy powiązania listy ACL z interfejsem (lista ACL będzie działała na wybranym interfejsie).

ip access-group numer_listy_dostępu in lub ip access-group numer_listy_dostępu out

Określenie in lub out określa listę jako wejściową lub wyjściową.

W routerach Cisco stosowane są dwa zasadnicze rodzaje ACL:

listy standardowe (ang. standard ACL),
listy rozszerzone (ang. extended ACL).

Różnica pomiędzy typem użytej listy sprowadza się do:

lista standardowa - jedynym kryterium, na podstawie którego router filtruje pakiety jest źródłowy adres IP,

lista rozszerzona - mają dużo większe możliwości, gdyż budowa warunku listy według, którego będzie prowadzona filtracja pakietów jest możliwa na podstawie: źródłowego adresu IP, docelowego adresu IP, źródłowego bądź docelowego numer portu, protokołu oraz informacji innych jak np. już wyżej wspomniany rodzaj wiadomości ICMP.

Zarówno listy standardowe, jak i rozszerzone mogą być:

numerowane,
nazwane.

Konfigurując numerowaną listę ACL przypisujemy jej numer:

z zakresów 1-99 lub 1300-1999, jeśli chcemy stworzyć listę standardową,
z zakresów 100-199 lub 2000-2699 jeśli chcemy stworzyć listę rozszerzoną.

W przypadku list nazywanych każdej liście przypisujemy unikalną nazwę, która powinna składać się ze znaków alfanumerycznych (przyjęło się używanie zapisu wielkimi literami – choć oczywiście to tylko sugestia). Lista nazywana nie może zawierać znaku spacji oraz zaczynać się od cyfry.

Poniżej na schemacie blokowym przedstawiono schemat działania listy ACL wejściowej (dla tych niewtajemniczonych z algorytmami - prostokąt w schemacie blokowym oznacza wystąpienie czynności zaś romb jest warunkiem, który kończy się podjęciem decyzji - analogią do warunku jest funkcja JEŻELI używana m.in w Excelu). Analizowanie danego pakietu rozpoczyna się gdy pakiet trafia do routera. Porównywane są dane zawarte w pakiecie z instrukcjami zawartymi w liście ACL. Porównywanie danych następuje do pierwszego trafienia. Jeśli takowe dopasowanie następuje to jest dane zawarte w odebranym pakiecie pokrywają się z instrukcjami zawartymi w liście ACL następuje przerwanie przetwarzania listy ACL (reszta warunków tworzących listę ACL jest ignorowana). Co do pakietu następuje decyzja o jego odrzuceniu bądź przekazaniu go dalej - wszystko zależy od treści zdefiniowanej instrukcji. Przetwarzanie listy ACL trwa tak długo aż nastąpi dopasowanie bądź zostanie wyczerpana lista nagłówków. Po sprawdzeniu wszystkich instrukcji i braku wystąpienia dopasowania odebrany pakiet jest odrzucany - pakiet trafia do „kosza” na wskutek działania nie jawnej instrukcji: deny any. Instrukcja ta jest domyślnie dołączana do każdej listy ACL a jej działanie odnosi się do tych pakietów, które nie spełniły żadnego z warunków zdefiniowanych w sprawdzanej liście ACL (brak wystąpienia dopasowania warunku do danych zawartych w nagłówku pakietu).

Oprócz list ACL zdefiniowanych na wejściu są jeszcze te, które mogą być przypisane do interfejsu wyjściowego (lista ACL ma zastosowanie do pakietów opuszczających router). Schemat blokowy działania takiej listy został przedstawiony na schemacie blokowym zamieszczonym poniżej.

Jak można zauważyć schemat podejmowania decyzji w przypadku zastosowania listy ACL na interfejsie wyjściowym przebiega inaczej niż to ma miejsce w przypadku pakietu, który do routera zostaje dostarczony.

Pierwszą decyzją do rozstrzygnięcia pozostaje fakt czy otrzymany pakiet router jest w stanie w ogóle przekazać - czy istnieje droga, którą pakiet mógłby bez przeszkód trafić do adresata. Istnienie drogi router określa na podstawie wpisów zawartych w swojej tablicy routingu. Jeśli otrzymany pakiet nie ma szans dotarcia do odbiorcy z powodu braku wpisu o sposobie jego dotarcia, to po co ma być on analizowany przez listę ACL. Spełnienie warunku routowalności pakietu (czyli istnienia drogi osiągnięcia celu) jest niezbędne by pakiet ten mógł być analizowany przez listę ACL. W przypadku braku wpisu w tablicy routingu o sieci docelowej pakiet zostaje odrzucony. Jeśli na interfejsie wyjściowym została skonfigurowana lista ACL, dane zawarte w nagłówku pakietu są analizowane pod względem ich zgodności z listą instrukcji zdefiniowanych w liście ACL. Przesłanie pakietu dalej jest zależne od spełnienia warunków listy ACL. Tu również ma zastosowanie zasada pierwszego dopasowania a w przypadku jego braku następuje odrzucenie pakietu na wskutek działania nie jawnej instrukcji zabroń.

Ogólny schemat decyzji z uwzględnieniem ewentualnie zdefiniowanych list ACL wejściowych jak i wyjściowych podejmowanych przez router został przedstawiony na schemacie poniżej.

W pierwszej kolejności po odebraniu pakietu sprawdzana jest warstwa druga czyli docelowy adres MAC, jeśli adres MAC nie zgadza się z adresem MAC interfejsu na, którym router odebrał wiadomość pakiet jest odrzucany (no chyba, że mamy do czynienia z ruchem rozgłoszeniowym).

Kolejnym krokiem jest sprawdzenie faktu istnienia listy ACL na interfejsie wejściowym, jeżeli takowa lista ACL została założona następuje sprawdzenie warunków według schematu blokowego opisanego wyżej (patrz schemat dotyczący listy wejściowej). Jeśli zaś listy ACL wejściowej nie ma pakiet danych zostaje przekazany w kierunki interfejsu wyjściowego. I tu podobnie jak w przypadku interfejsu wejściowego jest sprawdzany fakt istnienia listy ACL. W przypadku jej istnienia następuje ciąg czynności i decyzji, które są realizowane według schematu blokowego przynależnego liście wyjściowej. Gdy interfejs wyjściowy pozbawiony jest listy ACL, pakiet jest enkapsulowany do warstw niższych a następnie zostaje wysłany do kolejnego urządzenia (oczywiście pod warunkiem istnienia odpowiednich wpisów w tablicy routingu).

W naszych rozważaniach na temat list ACL posłużymy się topologią sieciową przedstawioną poniżej. Użyte interfejsy wraz z przypisanymi adresami IP oraz adresy sieci zostały przedstawiono również na rysunku poniżej.

Sieć jest zbieżna wszystkie użyte urządzenia mogą ze sobą nawiązać komunikację. Poniżej przedstawiono tablicę routingu wszystkich trzech routerów jak można stwierdzić wszystkie routery są w stanie przekazać pakiety do każdej z sieci. Za aktualizację tablic routingu dba protokół EIGRP.

Rozpoczynamy od pierwszego zadania a naszym celem będzie przy pomocy listy ACL zablokowanie ruchu sieciowego od hosta 10.0.1.10 (WindowsXP_1) do hosta 10.0.3.10 (WindowsXP_3). W przykładzie tym użyjemy standardową listę ACL.

Zanim zaczniemy konfigurować listę ACL sprawdźmy czy hosty mogą ze sobą prowadzić komunikację. Test ping przeprowadzony z hosta o adresie IP 10.0.1.10 w kierunku hosta 10.0.3.10 kończy się sukcesem.

Naszym zadaniem jest uniemożliwienie komunikacji pomiędzy hostami WindowsXP_1 a WindowsXP_3 oczywiście przy założeniu, że możliwość komunikacji pomiędzy pozostałymi urządzeniami sieciowymi nie będzie zakłócona.

Pierwsze pytanie na które musimy sobie odpowiedzieć - To na którym z trzech ruterów lista ACL ma zostać utworzona? Przyjmijmy, że routerem na którym będzie konfigurowana lista ACL będzie router R1 czyli router najbliższy hostowi WindowsXP_1.

Listę ACL tworzymy w trybie konfiguracji globalnej. Lista ACL zostaje utworzona za pomocą polecenia: access-list 5 deny host 10.0.1.10 Wydanie komendy spowoduje utworzenie standardowej listy ACL o numerze 5. Użyta wartość przypisana jest do zakresu list standardowych. Użycie parametru: deny powoduje zabronienie na prowadzenie komunikacji przez hosta o adresie IP 10.0.1.10. Użycie opcji: host powoduje utworzenie reguły dla pojedynczego komputera.

Po zatwierdzeniu polecenia, lista ACL zostaje utworzona. Stan wszystkich list ACL sprawdzimy po wydaniu komendy: show access-list Wydanie polecenia w formacie: show access-list <numer_ACL> spowoduje wyświetlenie ustawień określonej w poleceniu listy.

Lecz fakt utworzenia listy nie spowoduje, że będzie ona od razu stosowana. Aby lista mogła spełnić swoje zadanie należy, ją przypisać do interfejsu routera (w naszym scenariuszu jest to router R1). I tu kolejne pytanie - Który interfejs routera R1 wybrać? Decydujemy się na interfejs najbliższy hostowi czyli interfejs f0/0. Przypisanie listy realizujemy za pomocą komendy: ip access-group 5 in. Komendę tą wydajemy oczywiście w trybie konfiguracji interfejsu f0/0. Wydanie polecenia spowoduje przypisanie standardowej listy ACL o numerze 5 do interfejsu f0/0 routera R1. Lista ACL obowiązuje dla ruchu przychodzącego (użyty parametr: in).

Fakt przypisania danej listy do interfejsu sprawdzimy wykorzystując komendę: show running-config

Dodatkowo fakt użycia danej listy również skontrolujemy przy użyciu polecenia: show ip interface <interfejs> Jak widać poniżej nasza lista standardowa o numerze 5 jest przypisana do interfejsu f0/0 a jej działanie obejmuje ruch przychodzący.

Sprawdźmy zatem efekt przeprowadzonej konfiguracji i przeprowadźmy test komunikacji pomiędzy hostami WindowsXP_1 a WindowsXP_3. Jak widać test ping kończy się niepowodzeniem, uzyskaliśmy zamierzony efekt.

Fakt działania listy ACL możemy skontrolować wydając ponownie polecenie: show access-list Nasza lista została użyta 15 razy.

Zadanie zakładało możliwość prowadzenia komunikacji przez inne urządzenia, tak więc wykonajmy sprawdzenie z wykorzystaniem hosta Windows7. Wykonajmy test ping pomiędzy komputerami Windows7 a WindowsXP_3. Test ten kończy się niepowodzeniem a przecież nie o to nam chodziło.

By odpowiedzieć sobie na pytanie - Dlaczego tak się stało? trzeba uzmysłowić sobie w jaki sposób lista ACL jest zbudowana. Każda z list ACL ma wprowadzone przez administratora warunki określające sposób filtrowania ruchu sieciowego. Warunki te są jawne, gdyż zostały utworzone przez administratora. W naszym przykładzie warunkiem jawnym jest wpis zabraniający ruch z hosta 10.0.1.10. Ale każda lista ACL oprócz warunków jawnych posiada domyślne dołączany warunek niejawny: deny any (warunek ten nie jest uwzględniony podczas kontroli listy za pomocą polecenia: show access-lists). Warunek ten zabrania na ruch sieciowy każdemu. Listy ACL przetwarzanie warunków przeprowadzają od góry do pierwszego dopasowania i dlatego też hostowi Windows7 uniemożliwiono przeprowadzenie komunikacji. Dane zawarte w pakiecie wysłanym z komputera Windows7 nie zostały dopasowane do żadnego wpisu jawnego a więc zastosowany został ostatni nie jawny warunek: zabroń

W przypadku testu ping z hosta WindowsXP_1 komunikacja została zablokowana poprzez warunek jawny: deny host 10.0.1.10 natomiast za brak komunikacji pomiędzy hostami Windows7 a WindowsXP_3 odpowiada warunek niejawny: deny any

Co należy wykonać aby umożliwić komunikację pozostałym urządzeniom przypisanym do sieci 10.0.1.0/24? Poprawienie konfiguracji sprowadza się do wydania jednego, dodatkowego polecenia umożliwiającego na przeprowadzenie komunikacji. Tak więc wprowadźmy poprawkę.

Aby inne hosty mogły nawiązać połączenie do już istniejącej listy ACL wprowadźmy dodatkowy warunek - warunek ten zezwoli na nawiązanie połączenia. Aby komputery uzyskały dostęp do hosta WindowXP_3 należy wydać polecenie: access-list 5 permit any - punkt 1.

Wydanie komendy spowoduje dopisanie warunku: permit any (zezwól wszystkim) do już istniejącej listy ACL 5 - punkt 2.

Sprawdźmy efekt wprowadzonej poprawki.

W pierwszej kolejności test ping przeprowadzony z hosta WindowsXP_1 - test zakończony niepowodzeniem - ruch sieciowy został zablokowany poprzez warunek: deny host 10.0.1.10

Test drugi przeprowadzony z hosta Windows7 - test zakończony powodzeniem - zastosowanie pierwszego wpisu: deny 10.0.1.10 do hosta Windows7 nie ma zastosowania ze względu na brak dopasowania (adres IP hosta Windows7 to 10.0.1.20). Zezwolenie na przeprowadzenie komunikacji zostaje udzielone dzięki warunkowi: permit any. Ponieważ lista ACL swe działanie przerywa po dokonaniu dopasowania dlatego też warunek niejawny: deny any nie jest brany pod uwagę.

Efekt działania listy ACL i budujących ją warunków jak już wiesz Czytelniku sprawdzimy dzięki poleceniu: show access-lists

Wydaje się, że osiągnęliśmy zamierzony cel - Ale czy na pewno? Do tej pory wszystko działa jak należy. Host WindowsXP_1 nie ma możliwości komunikacji z komputerem WindowsXP_3, zaś inni pozostali tak. Ale podsieć 10.0.3.0/24 nie jest jedyną siecią w naszej topologii. Sprawdźmy zatem przebieg komunikacji z hostem WindowsXP_2, który należy do sieci 10.0.2.0/24. Sprawdzenia w pierwszej kolejności dokonamy z hosta Windows7. Test ping kończy się sukcesem. Jak na razie wszystko przebiega po naszej myśli.

Kolejny test przeprowadzimy z wykorzystaniem hosta WindowsXP_1. Próba ta niestety jak widać na poniższym zrzucie kończy się niepowodzeniem a niestety nie o to nam chodziło.

Przeprowadzona konfiguracja nie dała nam rozwiązania postawionego przed nami zadania. Zablokowaliśmy komunikację hosta WindowsXP_1 z hostem WindowsXP_3 ale także z innymi urządzeniami poza siecią 10.0.1.0/24 a nie takie były założenia zadania.

Tu Czytelniku przyznam się że specjalnie dobrałem taki wariant rozwiązania zadania i tak poprowadziłem nasze rozważania by pokazać na jakie błędy jesteśmy narażeni przy wdrażaniu mechanizmu ACL.

Nasze zadanie od początku było skazane na porażkę, gdyż już w pierwszym kroku podjęta decyzja o umiejscowieniu listy ACL była decyzją błędną.

Rozpoczynamy od początku (tym razem już poprawnie) i wracamy do ustawień początkowych. Aby powrócić do ustawień startowych należy usunąć bieżącą konfigurację. Powrót do ustawień początkowych rozpoczynamy od usunięcia listy ACL 5. Usunięcie listy przeprowadzimy za pomocą polecenia: no access-list <numer_listy>

Aby zachować porządek w ustawieniach nie zapominamy o skasowaniu listy ACL na interfejsie f0/0. Przypisaną listę ACL 5 usuniemy za pomocą komendy: no ip access-group <numer_listy> <kierunek>

Powróciliśmy do ustawień startowych.

Zamierzone cele osiągniemy tylko wtedy gdy listę ACL umieścimy na routerze R3. I tu dochodzimy do jednej z ważniejszych zasad, którą musimy przestrzegać: Listy standardowe umieszczamy najbliżej celu, którego lista dotyczy. W naszym przypadku celem jest uniemożliwienie komunikacji hosta 10.0.1.10 z hostem 10.0.3.10. Najbliżej celu czyli komputera WindowsXP_3 znajduje się router R3. Tak więc lista ACL powinna zostać skonfigurowana na tym routerze.

Warunki zapisane wewnątrz listy ACL będą tożsame z tymi zdefiniowanymi na routerze R1. Tym razem konfigurowana standardowa lista ACL przyjmie numer 7 (tak by nam się nie myliło).

Rozpoczynamy od zablokowania komunikacji pomiędzy hostami WindowsXP_1 a WindowsXP_3 – warunek: deny host 10.0.1.10 – punkt 1.

Mając na uwadze istnienie niejawnego warunku: deny any poprzez wydanie polecenia: access-list 7 permit any zezwalamy na łączność pozostałym hostom – punkt 2.

Punkt 3 jest sprawdzeniem poprawności warunków zawartych w tworzonej liście ACL.

Lista ACL o numerze 7 została utworzona. Aby lista mogła pełnić swoją rolę należy ją oczywiście przypisać do interfejsu routera R3. W grę wchodzą dwa interfejsy (gdyż w przyjętej topologii router R3 ma dwa aktywne interfejsy sieciowe) f0/0 oraz s0/1. Przy wyborze interfejsu kierujemy się znaną nam już zasadą – wybieramy ten, który znajduje się najbliżej celu. Tak więc po analizie topologii stwierdzamy, iż najbliżej celu znajduje się interfejs f0/0. Na interfejsie tym zostaje skonfigurowana lista ACL 7.

Polecenie łączące interfejs z listą ACL wymaga od nas zdefiniowanie kierunku działania listy, ponowna analiza topologii sieci przekonuje nas iż kierunek działania listy musi zostać ustawiony na wyjście.

Lista ACL została skonfigurowana i przypisana do interfejsu. Sprawdźmy zatem jak będzie przebiegać komunikacja po zastosowaniu poprawek.

Pierwszy test zostanie przeprowadzony z komputera WindowsXP_1. Test kończy się sukcesem – niemożliwa jest komunikacja z blokowanym przez listę ACL hostem WIndowsXP_3 przy zachowaniu możliwości nawiązania połączenia z innymi urządzeniami w naszej sieci (test ping pomiędzy WindowsXP_1 a WindowsXP_2 kończy się sukcesem).

Test drugi to sprawdzenie komunikacji pomiędzy komputerem Windows7 a hostami WindowsXP_2 oraz WindowsXP_3. Test ten również kończy się powodzeniem.

Założenia zadania zostały spełnione. Komunikacja pomiędzy hostem WindowsXP_1 a WindowsXP_3 została zablokowana, lista ACL działa prawidłowo.

W złożonej topologii sieciowej może istnieć wiele list ACL, które mogą być umiejscowione na różnych urządzeniach. Dlatego warto w sobie wyrobić nawyk opisywania tworzonych list ACL.

Aby dodać komentarz do listy ACL należy skorzystać z polecenia: access-list <numer_listy> remark <komentarz> Poniżej przykład dodania komentarza do utworzonej w poprzednim kroku listy ACL.

Komentarz do listy ACL możemy sprawdzić przeglądając konfigurację bieżącą routera. Opis listy ACL nie jest wyświetlany po wydaniu komendy: show access-list

Dosyć częstą praktyką przy opisywaniu list ACL jest dodanie komentarza, który odsyła nas do pliku zewnętrznego a dopiero w tym pliku zawarty jest dokładny opis i przeznaczenie listy ACL. Metoda ta poniekąd zwiększa bezpieczeństwo naszej sieci gdyż w razie przejęcia przez atakującego kontroli nad routerem, poznanie sposobu działania naszej sieci nie przyjdzie mu tak łatwo. Komentarze do list ACL są bogatym źródłem wiedzy dla hakera.

Podczas definicji list ACL użyteczną opcją może być zastosowanie parametru: log który powoduje wyświetlenie w konsoli komunikatu związanego z dopasowaniem. Oznacza to, że gdy wystąpi spełnienie warunku zdefiniowanego na liście ACL zostaniemy o tym poinformowani stosownym komunikatem.

Logowanie informacji o zdarzeniu może nastąpić w:

linii poleceń konsoli,
wewnętrzny bufor,
serwer syslog.

Informacje, które podlegają rejestrowaniu to:

akcja – zezwól (permit) lub zablokuj (deny),
użyty protokół - TCP, UDP lub ICMP,
adres źródłowy i docelowy,
w przypadku TCP oraz UDP – numer portu źródłowego i docelowego,
w przypadku ICMP – typy wiadomości.

Aby włączyć logowanie informacji o wystąpieniu zdefiniowanego warunku listy ACL po definicji warunku dodajemy flagę: log – pozostajemy przy przykładzie w którym blokujemy ruch z hosta 10.0.1.10

Logowanie warunku zabraniającego na połączenie pomiędzy hostem 10.0.1.10 a siecią 10.0.3.0/24 zostało włączone.

W przypadku wystąpienia zdarzenia zostaniemy o nim powiadomieni. Logi są generowane przy wystąpieniu zdarzenia (pierwszy pakiet, który spełnia warunek) a następnie w pięciominutowych odstępach po wystąpieniu zdarzenia.

Poniżej na wskutek próby nawiązania połączenia z hostem 10.0.3.10 został wygenerowany komunikat o zaistniałym zdarzeniu – nastąpiło dopasowanie informacji zawartych w nagłówku pakietu z warunkiem listy ACL, który podlega logowaniu.

Jeśli sprawdzamy poprawność działania zdefiniowanych list ACL warto posłużyć się komendą: show log Wydanie polecenie uwidoczni nam historię zdarzeń.

Lecz zanim zaczniemy używać wspomnianego wyżej polecenia należy w konfiguracji globalnej urządzenia wydać polecenie: logging console informational Komenda ta spowoduje zapisanie informacji o zdarzeniu jakim jest wystąpienie dopasowania – brak wydania tego polecenia uniemożliwi sprawdzenie historii zdarzeń (informacja o zdarzeniu pojawi się w wierszu poleceń konsoli lecz fakt jej zaistnienia nie zostanie zapisany). Polecenie te związane jest z konfiguracją zapisu zdarzeń i dokładny opis sposobu działania komendy trochę wybiega poza tematykę tego wpisu (logowanie zdarzeń będzie tematem kolejnego artykułu i w nim użycie tego polecenia opiszę szerzej).

W przypadku spodziewania się dużej ilości wpisów warto również pomyśleć o tym by nie zabrakło miejsca na ich zapisanie dlatego dobrze jest zwiększyć rozmiar bufora odpowiedzialnego za zapisywanie tych danych. Ilość dostępnego miejsca na zapis logów zwiększymy za pomocą polecenia: logging buffered <rozmiar_bajty>

Po przeprowadzonej konfiguracji wydanie polecenia: show log spowoduje wypisanie zaistniałych zdarzeń wśród, których znajdziemy informację o zdarzeniach związanych z logowanymi warunkami list ACL.

Aby wykasować liczniki, korzystamy z polecenia: clear ip access-list counter <numer_listy_ACL> a w przypadku listy nazywanej: clear ip access-list counter <nazwa_listy_ACL>

Jest jeszcze jeden parametr którego użycie zapewni nam dostarczenie większej ilości informacji na temat zaistniałych zdarzeń dotyczących list ACL. Aby uzyskane dane były bardziej szczegółowe zamiast flagi: log możemy użyć opcję: log-input

Poniżej przykład listy ACL, która zabrania tak jak poprzednio na komunikację pomiędzy hostem 10.0.1.10 a siecią 10.0.3.0 – w przykładzie tym użyto rozszerzoną listę ACL, która nie została jeszcze omówiona. W ćwiczeniu tym przede wszystkim chodzi o pokazanie możliwości uzyskania informacji o sposobie działania list ACL tak więc wybacz Czytelniku iż wybiegam trochę na przód. Spowodowane to jest faktem iż opcja: log-input została zarezerwowana tylko dla list rozszerzonych. Nie martw się gdy poniższe zapisy będą dla Ciebie niezrozumiałe (na razie) gdyż na tą chwilę nie jest to tematem naszych rozważań (do list rozszerzonych przejdę już za chwilę). Do przykładu tego zachęcam wrócić po dalszej lekturze wpisu.

Po zdefiniowaniu listy ACL, lista oczywiście zostaje przypisana do interfejsu i zostaje ustalony kierunek jej działania (rozważania na tematy interfejsu i routera na którym została utworzona lista ACL zostaw na później - w tym momencie nie ma to znaczenia).

W momencie gdy warunek listy ACL będzie miał zastosowanie zostaniemy o tym poinformowani. Poniżej przykład uzyskania informacji o nie udzieleniu dostępu do sieci 10.0.3.0/24 – host, który inicjował połączenie to komputer o adresie IP 10.0.1.10 Porównując dane uzyskane dzięki zastosowaniu opcji: log-input z tymi otrzymanymi dzięki opcji: log na pierwszy rzut oka widać, iż są to informacje bardziej szczegółowe (w logach m.in. znajdziemy dane o adresie MAC a w przypadku użycia protokołów TCP bądź UDP również będzie zawarta informacja o portach).

Efekty działania listy ACL możemy również sprawdzić za pomocą procesu debugowania. Aby uruchomić proces dotyczący danej listy ACL należy wydać polecenie: debug ip packet <numer_listy_ACL> detail

Po uruchomieniu procesu możemy obserwować efekt podejmowanych decyzji jakie podejmuje router względem otrzymanych pakietów a odnoszących się do wywołanej listy ACL.

Poniżej przykład w którym host o adresie 10.0.1.10 przeprowadza test względem hosta 10.0.3.10. Ponieważ komunikacja dzięki zastosowaniu listy ACL dla hosta 10.0.1.10 została zablokowana tak więc router odsyła informację ICMP typ 3 - Destination Unreachable

Podczas tworzenia wpisów list ACL na pewno nie raz przydarzy nam się sytuacja w której popełnimy błąd – Jak sobie z tym problemem poradzić? Proponuję trzy rozwiązania. Pierwsze z nich opiera się na bezpośredniej edycji listy ACL drugie na skopiowaniu ustawień listy ACL, poprawieniu błędów, wykasowaniu błędnie skonfigurowanej listy ACL i wprowadzeniu nowych ustawień, trzecie zaś na użyciu narzędzia CCP(Cisco Configuration Professional)

Prześledźmy zatem zaproponowane rozwiązania na tym przykładzie, rozpoczniemy od edycji listy ACL.

Poniżej na zrzucie została przedstawiona używana przez nas lista ACL 7, lecz jak można zauważyć w liście tej został błędnie skonfigurowany adres IP hosta – zamiast adresu 10.0.10.10 powinien być 10.0.1.10

Aby móc poprawić błędny wpis należy przejść do trybu konfiguracji globalnej urządzenia i wydać polecenie: ip access-list {standard | extended} <numer_listy> - punkt 1 (w naszym przypadku mamy do czynienia z standardową listą ACL tak więc używamy argumentu: standard w przypadku listy rozszerzonej należy użyć flagi: extended).

Po zatwierdzeniu komendy przejdziemy do trybu konfiguracji listy ACL (zapis: config-std-nacl). Błędny wpis adresu IP został powiązany z numerem sekwencyjnym listy, wartość tego numeru wynosi 10. Aby wpis usunąć należy wydać polecenie: no <numer_sekwencyjny> - punkt 2.

Błędny wpis został usunięty, fakt wykonania operacji możemy sprawdzić wyświetlając ustawienia listy ACL.

Po usunięciu wpisu należy wprowadzić nowy. Polecenie nakazujące dodanie nowego wpisu oczywiście wydajemy w trybie konfiguracji danej listy ACL. A wpis dodamy za pomocą polecenia: <numer_sekwencyjny> <parametry_listy_ACL> w naszym przypadku komenda przyjęła postać: 10 deny host 10.0.1.10

Po wprowadzeniu zmian, sprawdzamy fakt ich wykonania. Jak widać poniżej lista ACL została poprawiona.

Domyślne po zdefiniowaniu warunku listy ACL trafia on na koniec listy. Bez numerów sekwencyjnych, jedyną opcją dodania wpisu pomiędzy dwa już istniejące, było skasowanie ACL i zdefiniowanie jej od nowa. Sytuacja ta powtarzała się również w przypadku gdy chcieliśmy wykasować warunek.

Numery sekwencyjne dają nam możliwość edycji interesującego nas wpisu a także na dodanie nowego w dowolne miejsce listy ACL. Możliwe jest to dzięki przyjętemu numerowaniu kolejnych wpisów tworzących daną listę ACL. Domyślnie, numery sekwencyjne rozpoczynają się od wartości 10 a kolejny wpis powiększa tą wartość o 10.

Do bezpośredniej edycji listy ACL możemy podejść trochę inaczej a mianowicie dodać poprawny wpis. W naszym przypadku użyty numer sekwencyjny musi być niższy od następnego czyli od 20. Dodanie wpisu o numerze sekwencyjnym wyższym niż 20 spowoduje dopisanie warunku powyżej tego numeru a co za tym idzie wpis ten nigdy nie będzie miał zastosowania gdyż znajdzie się on za wpisem zezwalającym na ruch sieciowy wszystkim (20 permit any). Pamiętaj, że listy ACL są przetwarzane od góry do pierwszego dopasowania. W scenariuszu padło na wartość 15 (15 jest mniejsze od 20 tak więc nowo dodany wpis znajdzie się przed warunkiem z numerem sekwencyjnym równym 20) – punkt 1. Po wprowadzeniu nowego warunku pamiętamy o wykasowaniu tego błędnie zdefiniowanego – punkt 2. Po całości wykonanych zmian ostatnią czynnością jest ich sprawdzenie – punkt 3 – Wszystko się zgadza (dla przypomnienia dodanie do polecenia parametru: do nakazuje wykonanie polecenia dostępnego w trybie konfiguracji poziomu wyżej – zauważ, że polecenie zostało wydane w trybie konfiguracji globalnej zaś komenda: show access-list powinna zostać wydana w trybie uprzywilejowanym).

Przechodzimy zatem do drugiego ze sposobów.

W pierwszej kolejności rozpoczynamy od wyświetlenia ustawień listy ACL. Wpisy budujące listę ACL możemy wyświetlić przy wykorzystaniu polecenia zaprezentowanego na zrzucie poniżej (pełna składnia polecenia: show running-config | include access-list 7 – wyświetl ustawienia listy ACL 7 zawarte w konfiguracji bieżącej urządzenia – parametr: include odpowiada za wyświetlenie tylko tych wierszy zawierających zdefiniowaną po nim wartość).

Wyświetloną konfigurację po zaznaczeniu kopiujemy klawiszem Enter (do zestawienia sesji z routerem zostało użyte narzędzie PuTTY) a następnie wklejamy w dowolnym edytorze tekstowym i nanosimy niezbędne poprawki.

Po dokonaniu korekty ustawień i skopiowaniu ich do schowka po wciśnięciu PPM zawartość schowka zostaje wklejona do narzędzia PuTTY. Przy wklejaniu poleceń należy zwrócić uwagę by znajdować się w odpowiednim trybie konfiguracji routera (w przypadku list ACL jest to tryb konfiguracji globalnej). Przed skopiowaniem ustawień należy pamiętać o usunięciu błędnie zdefiniowanej listy ACL.

Taki sposób wprowadzania ustawień można wykorzystać nie tylko przy tworzeniu/edytowaniu list ACL ale również do konfiguracji wszystkich poleceń routera/przełącznika. Przypuśćmy, że mamy skonfigurowany router i dodajemy drugi, którego ustawienia nieznacznie się różnią od pierwszego. Możemy konfigurację oczywiście przeprowadzić ręcznie poprzez wprowadzenie wszystkich poleceń ale również poprzez skopiowanie całej konfiguracji bieżącej routera pierwszego, naniesieniu niezbędnych poprawek i wklejeniu ustawień do routera drugiego.

Ostatni sposób opiera się na użyciu narzędzia CCP. Narzędzie te umożliwia nam przeprowadzenie konfiguracji urządzeń sieciowych firmy CISCO z wykorzystaniem graficznego interfejsu użytkownika. Użycie aplikacji opiera się na przeglądarce Internet Explorer (najlepiej działa z tą przeglądarką) wraz z zainstalowanym oprogramowaniem Flash i Java (bez instalacji tych komponentów nie będzie można uruchomić CCP).

O ile jestem zwolennikiem jednak korzystania z CLI to o tyle w przypadku edycji bądź definicji nowych list ACL narzędzie CCP świetnie się sprawdza gdyż w prosty i szybki sposób umożliwia nam na wykonanie zadań związanych z listami ACL (przebiega to po prostu bardziej sprawnie, szczególnie gdy musimy zarządzać złożonymi listami ACL bądź ich dużym zbiorem).

Po uruchomieniu programu i połączeniu się z routerem (jak skonfigurować router aby współpracował z CCP opisałem tu: Dostęp zdalny oraz prawa użytkownika w urządzeniach CISCO). Przechodzimy do gałęzi: ACL/ACL Editor Po wybraniu jej z prawej strony ukaże się nam zbiór list ACL. Jak widać lista ACL 7 zawiera zdefiniowany przez nas na potrzeby ćwiczenia błąd. Aby rozpocząć edycję listy ACL należy ją zaznaczyć i wybrać przycisk: Edit

Po wybraniu opcji edytowania listy w nowo otwartym oknie Edit a Rule wybieramy wpis, który ma podlegać modyfikacji i ponownie wybieramy Edit (punkt 1).

W kolejnym oknie nanosimy niezbędne poprawki i zatwierdzamy je przyciskiem OK (dwa razy) – punkt 2.

Po zatwierdzeniu zmian zostanie wyświetlone okno: Deliver Configuration to Device odpowiedzialne za wysłanie odpowiednich poleceń do konfigurowanego urządzenia. Na tym etapie możemy podejrzeć jakie polecenia będą na zdalnym urządzeniu wydane. Zaznaczenie „ptaszka” przy opcji Save running config. to device’s startup config. spowoduje automatyczne zapisanie ustawień bieżących urządzenia jako konfigurację startową. Aby zastosować zmiany w konfiguracji wybieramy Deliver

Odpowiednie ustawienia zostały wprowadzone do konfiguracji urządzenia. Stan ustawień listy ACL sprawdzimy wybierając ponownie daną listę ACL.

Myślę, że omówione sposoby edycji list ACL są wystarczające a tylko od Ciebie zależy, którą z nich użyjesz.

Pytanie na koniec tego zadania, jakie możemy sobie zadać brzmi – Czy zastosowana lista ACL pomimo spełnienia założeń ćwiczenia, ze względu na wydajność sieci jest zasadna?

Dociekliwy Czytelnik szybko dojdzie do wniosku, że przy użyciu tak skonfigurowanej standardowej listy ACL marnotrawione jest pasmo oraz użycie procesorów routerów. Spójrzmy jeszcze raz na naszą topologię z zaznaczoną drogą pakietów i spróbujmy uzasadnić powyższe stwierdzenie.

Jak widać stwierdzenie jest zasadne gdyż – pakiet opuszczający hosta WindowsXP_1 a podróżujący w kierunku komputera WindowsXP_3, wędruje przez całą sieć (jest przekazywany przez kolejne routery) by i tak na końcu swojej drogi zostać zablokowany przez skonfigurowaną listę ACL. Tu na tym przykładzie widać jak na dłoni iż stosowanie standardowych list ACL (przy założeniach tego ćwiczenia) jest mało efektywne.

Tak więc jak najbardziej na miejscu jest pytanie – Co z tym fantem możemy zrobić i czy jest jakiś bardziej efektywny sposób osiągnięcia naszego celu? Rozwiązaniem będzie zastosowanie rozszerzonej listy ACL.

Ogólna składnia definicji rozszerzonej listy ACL wygląda następująco: access-list <nr_listy> {permit | deny} <protokół> <definicja_punktu_źródłowego> <definicja_punktu_docelowego>

Rozszerzone listy ACL umożliwiają nam prowadzenie większego zakresu kontroli ponieważ nasz warunek możemy zbudować m.in. w oparciu o źródłowy i docelowy adres IP pakietów a dodatkowo pozwalają również na określenie protokołów i numerów portów co do których lista ACL będzie miała zastosowanie. Tak więc nasze definicje blokujące bądź przepuszczające ruch sieciowy są określane na podstawie adresów nadawcy i odbiorcy pakietu, typu protokołu oraz portu.

Zakres użytych parametrów definiujemy sami według potrzeby i uznania oznacza to, że lista ACL może zawierać instrukcje odwołujące się tylko do adresów IP (wraz z użytym protokołem) a gdy jest potrzeba zawężenia listy możemy dodać dodatkowe parametry odwołujące się do np. numerów portów. Pojedyncza rozszerzona lista ACL może konfigurować wiele instrukcji.

Numery list rozszerzonych ACL są zawarte w zakresie od 100 do 199 a także od 2000 do 2699 (dla protokołu IP).

Prześledźmy zatem sposób konfiguracji takiej listy.

Tak jak w przypadku listy standardowej rozpoczynamy od wydania w trybie konfiguracji globalnej polecenia: access-list po którym to określamy numer listy a także warunek przepuszczający bądź odrzucający pakiet. Nasza lista może więc przyjąć postać:

R1(config)#access-list 111 deny ...

bądź

R1(config)#access-list 111 permit ...

W kolejnym kroku ustalamy rodzaj protokołu, dla którego będzie realizowane dopasowanie:

R1(config)#access-list 111 deny <protokół> ...

R1(config)#access-list 111 permit <protokół> ...

Protokół określamy poprzez definicję jego nazwy lub poprzez podanie numeru. Poniżej na rysunku zostały przedstawione nazwy najczęściej używanych protokołów.

Lista dostępnych numerów wraz z przypisanym do numeru protokołem została zamieszczona w tabeli poniżej (źródło: http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml).

Decimal	Keyword	Protocol
0	HOPOPT	IPv6 Hop-by-Hop Option
1	ICMP	Internet Control Message
2	IGMP	Internet Group Management
3	GGP	Gateway-to-Gateway
4	IPv4	IPv4 encapsulation
5	ST	Stream
6	TCP	Transmission Control
7	CBT	CBT
8	EGP	Exterior Gateway Protocol
9	IGP	any private interior gateway (used by Cisco for their IGRP)
10	BBN-RCC-MON	BBN RCC Monitoring
11	NVP-II	Network Voice Protocol
12	PUP	PUP
13	ARGUS (deprecated)	ARGUS
14	EMCON	EMCON
15	XNET	Cross Net Debugger
16	CHAOS	Chaos
17	UDP	User Datagram
18	MUX	Multiplexing
19	DCN-MEAS	DCN Measurement Subsystems
20	HMP	Host Monitoring
21	PRM	Packet Radio Measurement
22	XNS-IDP	XEROX NS IDP
23	TRUNK-1	Trunk-1
24	TRUNK-2	Trunk-2
25	LEAF-1	Leaf-1
26	LEAF-2	Leaf-2
27	RDP	Reliable Data Protocol
28	IRTP	Internet Reliable Transaction
29	ISO-TP4	ISO Transport Protocol Class 4
30	NETBLT	Bulk Data Transfer Protocol
31	MFE-NSP	MFE Network Services Protocol
32	MERIT-INP	MERIT Internodal Protocol
33	DCCP	Datagram Congestion Control Protocol
34	3PC	Third Party Connect Protocol
35	IDPR	Inter-Domain Policy Routing Protocol
36	XTP	XTP
37	DDP	Datagram Delivery Protocol
38	IDPR-CMTP	IDPR Control Message Transport Proto
39	TP++	TP++ Transport Protocol
40	IL	IL Transport Protocol
41	IPv6	IPv6 encapsulation
42	SDRP	Source Demand Routing Protocol
43	IPv6-Route	Routing Header for IPv6
44	IPv6-Frag	Fragment Header for IPv6
45	IDRP	Inter-Domain Routing Protocol
46	RSVP	Reservation Protocol
47	GRE	Generic Routing Encapsulation
48	DSR	Dynamic Source Routing Protocol
49	BNA	BNA
50	ESP	Encap Security Payload
51	AH	Authentication Header
52	I-NLSP	Integrated Net Layer Security TUBA
53	SWIPE (deprecated)	IP with Encryption
54	NARP	NBMA Address Resolution Protocol
55	MOBILE	IP Mobility
56	TLSP	Transport Layer Security Protocol using Kryptonet key management
57	SKIP	SKIP
58	IPv6-ICMP	ICMP for IPv6
59	IPv6-NoNxt	No Next Header for IPv6
60	IPv6-Opts	Destination Options for IPv6
61		any host internal protocol
62	CFTP	CFTP
63		any local network
64	SAT-EXPAK	SATNET and Backroom EXPAK
65	KRYPTOLAN	Kryptolan
66	RVD	MIT Remote Virtual Disk Protocol
67	IPPC	Internet Pluribus Packet Core
68		any distributed file system
69	SAT-MON	SATNET Monitoring
70	VISA	VISA Protocol
71	IPCV	Internet Packet Core Utility
72	CPNX	Computer Protocol Network Executive
73	CPHB	Computer Protocol Heart Beat
74	WSN	Wang Span Network
75	PVP	Packet Video Protocol
76	BR-SAT-MON	Backroom SATNET Monitoring
77	SUN-ND	SUN ND PROTOCOL-Temporary
78	WB-MON	WIDEBAND Monitoring
79	WB-EXPAK	WIDEBAND EXPAK
80	ISO-IP	ISO Internet Protocol
81	VMTP	VMTP
82	SECURE-VMTP	SECURE-VMTP
83	VINES	VINES
84	TTP	Transaction Transport Protocol
84	IPTM	Internet Protocol Traffic Manager
85	NSFNET-IGP	NSFNET-IGP
86	DGP	Dissimilar Gateway Protocol
87	TCF	TCF
88	EIGRP	EIGRP
89	OSPFIGP	OSPFIGP
90	Sprite-RPC	Sprite RPC Protocol
91	LARP	Locus Address Resolution Protocol
92	MTP	Multicast Transport Protocol
93	AX.25	AX.25 Frames
94	IPIP	IP-within-IP Encapsulation Protocol
95	MICP (deprecated)	Mobile Internetworking Control Pro.
96	SCC-SP	Semaphore Communications Sec. Pro.
97	ETHERIP	Ethernet-within-IP Encapsulation
98	ENCAP	Encapsulation Header
99		any private encryption scheme
100	GMTP	GMTP
101	IFMP	Ipsilon Flow Management Protocol
102	PNNI	PNNI over IP
103	PIM	Protocol Independent Multicast
104	ARIS	ARIS
105	SCPS	SCPS
106	QNX	QNX
107	A/N	Active Networks
108	IPComp	IP Payload Compression Protocol
109	SNP	Sitara Networks Protocol
110	Compaq-Peer	Compaq Peer Protocol
111	IPX-in-IP	IPX in IP
112	VRRP	Virtual Router Redundancy Protocol
113	PGM	PGM Reliable Transport Protocol
114		any 0-hop protocol
115	L2TP	Layer Two Tunneling Protocol
116	DDX	D-II Data Exchange (DDX)
117	IATP	Interactive Agent Transfer Protocol
118	STP	Schedule Transfer Protocol
119	SRP	SpectraLink Radio Protocol
120	UTI	UTI
121	SMP	Simple Message Protocol
122	SM (deprecated)	Simple Multicast Protocol
123	PTP	Performance Transparency Protocol
124	ISIS over IPv4
125	FIRE
126	CRTP	Combat Radio Transport Protocol
127	CRUDP	Combat Radio User Datagram
128	SSCOPMCE
129	IPLT
130	SPS	Secure Packet Shield
131	PIPE	Private IP Encapsulation within IP
132	SCTP	Stream Control Transmission Protocol
133	FC	Fibre Channel
134	RSVP-E2E-IGNORE
135	Mobility Header
136	UDPLite
137	MPLS-in-IP
138	manet	MANET Protocols
139	HIP	Host Identity Protocol
140	Shim6	Shim6 Protocol
141	WESP	Wrapped Encapsulating Security Payload
142	ROHC	Robust Header Compression
143-252		Unassigned
253		Use for experimentation and testing
254		Use for experimentation and testing
255	Reserved

Następnie podawany jest adres nadawcy z maską blankietową, a po nim — adres odbiorcy (również z maską blankietową). Cóż takiego jest ta maska blankietowa? W tym momencie wybacz Czytelniku jeszcze tego tematu nie rozwinę ale powrócimy do niego dosłownie za chwilę – opisu szukaj kilka wierszy poniżej.

R1(config)#access-list 111 deny <protokół> <adres_nadawcy> <adres_odbiorcy>

R1(config)#access-list 111 permit <protokół> <adres_nadawcy> <adres_odbiorcy>

Uzbrojeni w tą wiedzę spróbujmy zatem zdefiniować rozszerzoną listę ACL, która zablokuje nam ruch sieciowy pochodzący od hosta 10.0.1.10 a wysyłany w kierunku hosta 10.0.3.10

Lista ACL przyjmie zatem postać:

Punkt 1 – numer listy został określony jako 111 czyli mamy do czynienia z listą rozszerzoną, chcemy zablokować ruch sieciowy a więc musimy użyć parametru: deny, blokowanym protokołem jest protokół IP, adres nadawcy został określony poprzez definicję: host 10.0.1.10 gdyż to pakiety wysłane od tego hosta mają być blokowane, aby zaś host mógł nawiązać połączenie z innymi komputerami wewnątrz sieci 10.0.3.0/24 oprócz hosta 10.0.3.10 poprzez definicję: host 10.0.3.10 został określony adres docelowy.

Punkt 2 – instrukcja zezwalająca (parametr: permit) na ruch sieciowy pozostałym hostom (parametr: any any – czytaj z dowolnego adresu źródłowego do dowolnego adresu docelowego). Gdyby tej instrukcji zabrakło inne komputery będące przypisane do sieci 10.0.1.0/24 nie mogłyby nawiązać połączenia gdyż zadział by domyślny warunek: deny any

Lista ACL rozszerzona została utworzona, czas ją przypisać do interfejsu routera i tu rodzi się kolejne pytanie – Który router i interfejs wybrać? W przypadku list rozszerzonych zasada ich umiejscowienia brzmi następująco – Listy ACL rozszerzone umieszczamy najbliżej źródła. Mamy tu do czynienia z sytuacją odwrotną niż w przypadku list ACL standardowych. Zasadę tą ilustruje rysunek poniżej – blokowany pakiet nie musi przejść całej drogi do celu by i tak ostatecznie zostać zablokowanym (sytuacja występuje w przypadku list ACL standardowych) lecz jest odrzucany przy pierwszej nadarzającej się okazji.

Tak więc naszą listę ACL należy umieścić najbliżej źródła czyli jest to interfejs f0/0 routera R1. Pakiet trafia do routera tak więc kierunek działania listy musi być ustalony na: in Przypisanie rozszerzonej listy ACL następuje w ten sam sposób jak listy standardowej.

Rozszerzona lista ACL została skonfigurowana. Czas by sprawdzić efekt przeprowadzonej konfiguracji. Pierwszy test zostanie przeprowadzony z hosta 10.0.1.10 – test zakończony powodzeniem, ruch sieciowy został zablokowany.

Test drugi – tym razem pakiet ping zostanie wysłany z hosta 10.0.1.20. Jak widać poniżej próba komunikacji zakończyła się sukcesem. Lista ACL działa poprawnie.

Informacje o zdefiniowanej, rozszerzonej liście ACL uzyskamy dzięki poleceniom:

1 - show access-lists,

2 - show running-config,

3 - show ip interface <interfejs>

Zadanie pierwsze wraz z informacjami dodatkowymi uważam za zakończone, idziemy dalej.

Przykład drugi polega na zablokowaniu ruchu całej sieci 10.0.1.0/24 do sieci 10.0.3.0/24. Zadanie te wykonamy przy pomocy listy ACL standardowej jak i rozszerzonej.

Rozpoczynamy od użycia listy ACL standardowej.

Teoretycznie można by było do tego zadania wykorzystać listę ACL w której zdefiniowalibyśmy wiele warunków z których każdy miałby za zadanie zablokować ruch sieciowy pochodzący od jednego z hosta. W sieci 10.0.1.0/24 do wykorzystania jest 254 unikatowych adresów IP, które mogą zostać przypisane hostom (adresy od 10.0.1.1 do 10.0.1.254 - istnieją jeszcze dwa adresy IP ale jeden z nich 10.0.0.0 jest adresem sieci natomiast 10.0.0.255 obsługuje broadcast). Nasza lista ACL musiałaby by więc zawierać aż 254 wpisów, których zadaniem byłoby zablokowanie całego ruchu pochodzącego od strony sieci 10.0.1.0/24 W przypadku standardowej listy ACL miałaby ona postać:

deny host 10.0.1.1
deny host 10.0.1.2
deny host 10.0.1.3
.
.
.

deny host 10.0.1.254

Jak można wywnioskować lista zbudowana w ten sposób jest nader skomplikowana a przy jej tworzeniu łatwo o błąd a dodatkowo im więcej warunków zawiera lista ACL tym bardziej obciążamy router. Tak więc musi istnieć jakiś inny sposób, który pozwoli nam na definicję listy i wykonanie zadania. Oczywiście i takowy istnieje. Definicja list ACL tego typu sprowadza się do wykorzystania tzw. wildcard mask (w literaturze maska ta definiowana jest jako maska wieloznaczna, maska odwrócona bądź maska blankietowa zaś potocznie administratorzy często określają ją jako „dziką” maskę).

W masce standardowej (masce podsieci) bit 1 wymusza dopasowanie zaś bit 0 oznacza brak dopasowania w przypadku wildcard mask sytuacja zaś ma się odwrotnie:

bit 0 wildcard mask - wykonaj dopasowanie,

bit 1 wildcard mask - zignoruj.

Więc zadajmy pytanie – Jakiej więc wartości wildcard mask użyć? W naszym przykładzie mamy sytuację prostą wystarczy wykonać odejmowanie: od wartości 255.255.255.255 odejmujemy maskę podsieci (w naszym przypadku maska podsieci przyjęła wartość 255.255.255.0 – CIDR /24).

Po wykonaniu działania wartość maski odwróconej przyjmuje wartość: 0.0.0.255

Oczywiście analogicznie postępujemy w przypadku innych sieci np. dla sieci 255.255.255.252 – CIDR /30 (takie podsieci mamy pomiędzy routerami) wartość wildcard mask wyniesie: 0.0.0.3

Wracając do naszego przykładu aby zabronić na ruch sieciowy między siecią 10.0.1.0/24 a 10.0.3.0/24 przy wykorzystaniu listy ACL standardowej należy użyć warunku: deny 10.0.1.0 0.0.0.255 – punkt 1

Po określeniu pierwszego wpisu został zdefiniowany kolejny, który pozwala na ruch sieciowy pochodzący od innej sieci niż: 10.0.1.0/24 (punkt 2).

Ostatnią czynnością (punkt 3) jest sprawdzenie poprawności listy.

Po definicji warunków listy ACL nie można zapomnieć o powiązaniu jej z interfejsem routera, ponieważ jest to lista standardowa zostanie ona umieszczona najbliżej celu czyli na interfejsie f0/0 routera R3.

Zadanie wykonane, czas na testy. Test z wykorzystaniem hosta 10.0.1.10 kończy się sukcesem, ruch sieciowy jest zablokowany.

Również test przeprowadzony z hosta 10.0.1.20 kończy się sukcesem – pakiety ICMP nie docierają do celu.

Ostatnia próba zostanie przeprowadzona z wykorzystaniem komputera WindowsXP_2 i tu również pełny sukces - pakiety osiągają docelową sieć 10.0.3.10 (instrukcja: deny 10.0.1.0 0.0.0.255 dla sieci 10.0.2.0 nie ma zastosowania).

Sprawdzenie listy ACL uwidacznia ilość dokonanych dopasowań do zdefiniowanych warunków. Lista ACL działa poprawnie.

Jak już umiemy definiować rozszerzone listy ACL spróbujmy te same zadanie wykonać z ich wykorzystaniem.

Aby zabronić na ruch sieciowy od sieci 10.0.1.0/24 do sieci 10.0.3.0/24 należy utworzyć warunek, który ruch wychodzący z sieci 10.0.1.0/24 zablokuje. Rozpoczynamy od wydania polecenia access-list wraz z numerem należącym do zakresu przypisanego listom rozszerzonym. Pakiety mają zostać zablokowane tak więc niezbędne będzie dodanie flagi: deny. W kolejnym kroku definiujemy adres źródłowy - blokowane mają być wszystkie adresy IP wchodzące w skład sieci 10.0.1.0/24 tak więc niezbędne będzie dodanie do polecenia adresu sieci 10.0.1.0 wraz z maską blankietową 0.0.0.255 Gdy zostały określone źródłowe adresy IP czas zdefiniować adresy docelowe - blokujemy możliwość komunikacji z siecią docelową 10.0.3.0/24 tak więc definicja obejmująca ten zakres adresów IP przyjmie postać: 10.0.3.0 0.0.0.255 Składnia całego polecenia została pokazana na rysunku poniżej - punkt 1.

Po definicji listy ACL przypisujemy ją do interfejsu f0/0 routera R1. Dlaczego został wybrany ten interfejs i ten router? - to już Czytelniku mam nadzieję, że jest dla Ciebie jasne. Dla przypomnienia (nie zaszkodzi powtórzyć) - rozszerzoną listę ACL przypisujemy najbliżej źródła – punkt 2.

Po wydaniu wszystkich poleceń nie zaszkodzi sprawdzić ich poprawności - punkt 3.

Po określeniu pierwszego wpisu oczywiście musiał zostać zdefiniowany kolejny warunek (punkt 4), który zezwala na ruch sieciowy do innych sieci (w przypadku jego braku hosty z sieci 10.0.1.0/24 nie mogłyby się skomunikować np. z siecią 10.0.2.0/24).

Po dokonanej konfiguracji listy ACL przyszedł czas by sprawdzić efekt jej działania.

Pierwszy test został wykonany z hosta 10.0.1.10, drugi zaś z hosta 10.0.1.20 - oba zakończyły się sukcesem ruch sieciowy z sieci 10.0.1.0/24 został zablokowany.

Aby sprawdzić do końca działanie zdefiniowanej listy sprawdźmy jeszcze łączność z siecią 10.0.2.0/24 Test wykonany z hosta 10.0.1.20 zakończył się sukcesem tak więc nasza lista ACL działa poprawnie.

Zanim przejdziemy dalej i spróbujemy wykonać kolejne zadanie zatrzymajmy się jeszcze chwilkę przy wildcard mask.

Kilka wierszy powyżej napisałem iż bit 0 w wildcard mask oznacza dopasowanie zaś bit 1 zignoruj. Tę zasadę ilustruje rysunek poniżej.

Została przedstawiona przykładowa sieć 192.168.1.0 z zdefiniowaną maską odwrotną 0.0.0.255 (obszar maski zaznaczony na żółto) – czyli w ramach tych bitów adresu ma nastąpić dopasowanie (liczy się pierwsze 24 bity zajęte przez wartości 0) Jeśli 0 oznacza dopasowanie porównując adres sieci z adresem z pierwszego przykładu (adres IP 192.168.1.20) widzimy iż dopasowanie na wszystkich 24 bitach zostało zachowane. Brak dopasowania zachodzi dopiero na 28 bicie ale ponieważ 28 bit został odznaczony przez maskę jako 1 - brak dopasowania nie ma tu znaczenia. Co za tym idzie lista ACL i połączony z nią warunek dla tego adresu IP będzie miał zastosowanie.

W drugim przykładzie (adres 192.168.2.1) dopasowanie jest zachowane do 22 bitu adresu (bit 23 zawiera wartość 1 a powinien 0) oznacza to iż adres ten nie spełnia wymogów zdefiniowanego warunku (przypisana instrukcja do tego adresu IP nie będzie miała zastosowania).

W przykładzie trzecim mamy tą samą sytuację co w drugim z tą różnicą, że w tym przykładzie dopasowanie jest zachowane do bitu 12.

Przy definicji list ACL jak już pewnie zauważyłeś stosowaliśmy dwa specjalne parametry, mowa tu o fladze any oraz fladze host.

Opcja any wymusza zastosowanie maski 255.255.255.255. Użycie takie maski powoduje ignorowanie całego adresu IP bądź inaczej akceptację dowolnego.

Zasadę działania flagi any zobrazowano na rysunku poniżej.

Ponieważ maska odwrotna poprzez użycie any (co równe jest zapisowi 255.255.255.255) została zdefiniowana jako ciąg bitów przyjmujących wartość 1 to połączenie każdego z adresów IP powoduje jego akceptację. W przypadku połączenia z instrukcją: deny (warunek: deny any) tak zdefiniowana lista spowoduje zablokowanie całego ruchu sieciowego zaś w przypadku instrukcji: permit zezwolenie na ruch sieciowy z dowolnego adresu IP.

Opcja host zastępuje maskę 0.0.0.0. Maska ta powoduje sprawdzenie wszystkich bitów adresu i bity te muszą wykazać pełną zgodność. Zastosowanie parametru host spowoduje dopasowanie tylko jednego adresu IP.

I już tradycyjne rysunek poniżej.

Wildcard mask w której pojawia się flaga: host (co równe jest zapisowi: 0.0.0.0) oznacza wykonanie pełnego dopasowania gdyż wszystkie bity maski są zdefiniowane jako 0. Ten warunek zostanie tylko spełniony przez jeden pojedynczy adres IP - w przykładzie powyżej adres IP 192.168.1.1 został połączony z maską odwrotną 0.0.0.0 tak więc tylko taki adres spełni warunek dopasowania.

Pozostając jeszcze przez chwilę przy temacie maski odwrotnej zastanówmy się jaką by należało przyjąć maskę gdybyśmy chcieli wykonać zadanie, które polegałoby na zablokowaniu ruchu sieciowego od adresu IP 192.168.0.1 do 192.168.0.5? W ramach tego krótkiego ćwiczenia dla ułatwienia rozważań przyjmijmy, że mamy do czynienia z topologią przedstawioną na rysunku poniżej:

Zależy nam na tym aby hosty od adresu IP 192.168.0.1 do 192.168.0.5 nie mogły komunikować się z siecią 192.168.1.0/24 zaś hosty począwszy od adresu 192.168.0.6 już tak.

Pierwsze rozwiązanie tego problemu jakie każdemu powinno się nasunąć to zbudowanie listy ACL złożonej z 5 warunków w postaci: deny host 192.168.0.x gdzie x jest liczbą od 1 do 5 i jednego warunku: permit any

Oczywiście jest to wyjście z sytuacji i w tym ćwiczeniu jak najbardziej zdałoby egzamin - Ale czy postąpilibyśmy tak samo gdyby zakres blokowanych adresów IP wynosiłby powiedzmy adresy od 192.168.0.1 do 192.168.0.80? Już nie.

A więc co należy wykonać by podany zakres adresów IP zablokować? Pierwszą czynność jaką musimy przeprowadzić jest wyznaczenie adresu podsieci i maski do której blokowane hosty należą. Potrzebne nam dane odnajdziemy wykonując tzw. sumaryzację bądź podsumowanie (zagadnienie wykorzystywane również w routingu celem zmniejszenia rozmiarów tablic routingu).

Rozpiszmy nasze adresy IP binarnie (w gwoli ścisłości wystarczyłoby by rozpisać pierwszy i ostatni adres IP):

Następnie poruszamy się od lewej strony do prawej szukając dopasowania - miejsca w którym wszystkie adresy są ze sobą zgodne. Gdy dotrzemy do miejsca w którym zgodność nie jest zachowana, mówi się że znaleźliśmy granicę podsumowania. Jak widać nasza granica znajduje się przy 29 bicie gdyż porównując bit 30 dopasowanie nie jest już zachowane. Liczba 29 jest maską podsieci dla sieci sumarycznej. Maska /29 odpowiada adresowi 255.255.255.248. By odnaleźć adres sieci, przepisujemy bity do granicy podsumowania bez zmian natomiast resztę pozostałych bitów dopełniamy zerami. W naszym przykładzie 1100000.10101000.00000000.00000000, co odpowiada adresowi IP 192.168.0.0.

A więc adresem podsumowującym hosty jest podsieć: 192.168.0.0 255.255.255.248.

Mając maskę łatwo możemy przeliczyć ją na maskę odwrotną.

A więc przy budowie listy ACL należy użyć adresu 192.168.0.0 z wildcard mask o wartości 0.0.0.7

Zdobytą wiedzę wykorzystajmy w działaniu i zdefiniujmy standardową listę ACL.

Tak utworzoną listę oczywiście należy przypisać do interfejsu po stronie sieci 192.168.1.0/24

Lista ACL została skonfigurowana sprawdźmy zatem efekt naszych poczynań. W pierwszej kolejności host 192.168.0.1

Wszystko się zgadza host nie może skomunikować się z siecią 192.168.1.0/24

Czas na hosta 192.168.0.6

I w tym przypadku już tak kolorowo nie jest (a miało być tak pięknie). Host 192.168.0.6 również nie może skomunikować się z siecią 192.168.1.0/24 co jest sprzeczne z przyjętymi założeniami ćwiczenia. Cóż takiego się stało, że i temu hostowi została odebrana możliwość komunikacji?

Odpowiedź jest prosta. Host o adresie IP 192.168.0.6 tak jak hosty o adresach od 192.168.0.1 do 192.168.0.5 również należy do podsieci 192.168.0.0 255.255.255.248 (CIDR: /29) a co za tym idzie wykorzystując wyliczoną maskę wieloznaczną 0.0.0.7 również hostowi 192.168.0.6 zostanie odebrana możliwość komunikacji z żądaną siecią. Sytuacja ta dotyczy również hosta o adresie IP 192.168.0.7. Dopiero host z adresem IP 192.168.0.8 poprawnie nawiąże połączenie z siecią 192.168.1.0/24

Mam nadzieję, że zaistniały fakt i powstałe wątpliwości rozjaśni rysunek poniżej.

Jak można zauważyć dwa wspomniane adresy IP tj. 192.168.0.6 i 192.168.0.7 również spełniają warunek zgodności zachodzący do 29 bitu adresu (do granicy podsumowania) a dopiero adres IP 192.168.0.8 warunku dopasowania nie spełnia.

Tak więc co należy wykonać aby nasze ćwiczenie wykonać prawidłowo? Należy poprawić listę ACL poprzez utworzenie osobnych warunków dla dwóch problematycznych adresów IP.

Nasza lista ACL przyjmie postać:

1 - definicja zezwalająca na ruch sieciowy z hostów o adresach IP 192.168.0.6 oraz 192.168.0.7,

2 - definicja zabraniająca na ruch sieciowy hostom od 192.168.0.1 do 192.168.0.7 (wpis ten nie będzie miał zastosowania do hostów 192.168.0.6 oraz 192.168.0.7 gdyż wykluczenie tych adresów zostało zdefiniowane w punkcie 1),

3 - definicja zezwalająca na ruch sieciowy pozostałym hostom (od 192.168.0.8 do 192.168.0.255),

4 - przypisanie listy ACL do interfejsu.

Nie pozostaje nam nic innego jak dokonanie sprawdzenia.

I tak jak poprzednio zaczynamy od hosta 192.168.0.1

Test zakończony pomyślnie.

Czas na hosta 192.168.0.6

Łączność z siecią 192.168.1.0/24 jest możliwa. Test zakończony powodzeniem.

Nasza lista ACL działa poprawnie.

Na koniec rozważań dotyczących wildcard mask chcę cię Czytelniku pozostawić z pytaniem – Czy nasza lista ACL mogłaby zostać zdefiniowana tak jak na rysunku poniżej i czy gwarantuje to poprawność wykonania zadania? (jeśli Ci się nie uda odpowiedzieć na pytanie nie martw się – odpowiedź znajdziesz na końcu wpisu).

Przejdźmy zatem do kolejnego przykładu zastosowania list ACL. Funkcja pełniona przez listę ACL jest bardzo podobna do tej z ćwiczenia pierwszego z tą małą różnicą iż będziemy blokować ruch sieciowy pomiędzy hostem o adresie IP 10.0.1.10 (WindowsXP_1) a hostem 10.0.2.10 (WindowsXP_2). W przykładzie pierwszym do wykonania zadania użyliśmy m.in. standardowej listy ACL w tym przykładzie również takową listę użyjemy lecz tym razem będzie to tzw. standardowa lista ACL nazywana.

W przykładzie tym jak i następnym wracamy do naszej bazowej topologii więc by nie przewijać na sam początek artykułu jeszcze raz dla przypomnienia.

Nazwane listy ACL dla protokołu IP wprowadzono w wersji 11.2 systemu Cisco IOS.

Podczas pracy z listami ACL przekonasz się nie raz, że komentarz, który zawiera opis działania listy ACL znacznie ułatwi Ci zrozumienie sposobu działania danej listy. Jeśli konfigurowana lista ACL znajduje się w środowisku sieciowym w którym pełnisz rolę administratora już od dłuższego czasu zapoznanie się z takim opisem natychmiast przypomni Ci dlaczego została ona skonfigurowana. Jeśli zaś środowisko sieciowe w którym pracujesz jest dla Ciebie „dziewiczym” obszarem to będziesz wdzięczny poprzedniemu administratorowi, że zawarł wskazówki, które obszar ten pozwolą Ci poznać. Aby ułatwić sobie rozeznanie co do zasadności stosowania danych list ACL można je nazywać. Nazwa listy ACL w postaci: blokadaSieciBiuro da Ci więcej informacji o pełnionej przez listę ACL funkcji niż suchy opis w postaci jej numeru. Dlatego też oprócz stosowania standardowych list ACL numerowanych można posłużyć się listą nazywaną.

Po analizie ćwiczenia pierwszego już wiesz że listę standardową umieszczamy najbliżej celu. Zależy nam na blokadzie ruch pomiędzy hostem WindowsXP_1 a WindowsXP_2 tak by host o adresie IP 10.0.1.10 nie mógł skomunikować się z hostem 10.0.2.10 Najbliżej naszego celu (host WindowsXP_2) znajduje się interfejs f0/0 routera R2 tak więc to na tym interfejsie założymy listę ACL.

Aby zdefiniować nazywaną standardową listę ACL przechodzimy do trybu konfiguracji globalnej routera R2 i wydajemy polecenie: ip access-list standard <nazwa_listy> (w przypadku konfiguracji listy rozszerzonej zamiast parametru: standard używamy parametr: extended). A następnie w trybie konfiguracji listy ACL definiujemy jej warunki – punkt 1. Ostatnią czynność jaką musimy wykonać by lista ACL mogła zacząć działać jest jej powiązanie z danym interfejsem. W naszym scenariuszu lista ACL blokadaWinXP1 została przypisana do interfejsu f0/0. Kierunek działania listy oczywiście został określony jako: out

Sprawdźmy zatem działanie listy ACL.

Test ping przeprowadzony z hosta 10.0.1.10 kończy się sukcesem – brak jest połączenia z adresem 10.0.2.10

Zaś test komunikacji wykonany z hosta Windows7 również kończy się sukcesem – połączenie z hostem 10.0.2.10 zostaje nawiązane.

Zdefiniowana lista ACL została skonfigurowana prawidłowo.

W kolejnym ćwiczeniu zajmiemy się dalszą konfiguracją list ACL lecz tym razem filtrowanie ruchu skonfigurujemy w oparciu o numery portów.

Ćwiczenie polega na skonfigurowaniu listy ACL w ten sposób aby tylko host 10.0.1.20 (dla pozostałych adresów IP z podsieci 10.0.1.0/24 łączność ma być blokowana) mógł sesję SSH z routerem R3 nawiązać.

Aby wykonać to zadanie w definiowanych warunkach listy ACL musimy umieścić informację o numerze portu.

Numery portów mogą odnosić się do adresu źródłowego jak i docelowego.

Ponieważ kontrola dostępu będzie prowadzona w oparciu o numery portów należy użyć listy rozszerzonej a konfigurowanym protokołem jest TCP bądź UDP.

Prześledźmy taki o to warunek: access-list 180 permit tcp any any eq 80 Warunek ten zezwala na nawiązanie sesji z dowolnego adresu źródłowego do dowolnego adresu docelowego pod warunkiem iż nawiązywany ruch odnosi się do portu 80. W powyższej instrukcji zapis: eq 80 należy odczytać jako: równa się 80

Warunek definicji portu w powyższej liście ACL odnosi się oczywiście do adresu docelowego. Aby określić adres źródłowy nasza lista przyjęła by postać: access-list 180 permit tcp any eq 80 any Oczywiście dozwolona jest sytuacja w której zostaje zdefiniowany port w adresie źródłowym jak i docelowym. Warunek: access-list 180 permit tcp any eq 1566 any eq 80 pozwala na nawiązanie połączenia z dowolnym hostem na porcie 80 z dowolnego hosta pod warunkiem iż połączenie te inicjowane jest z wykorzystaniem portu 1566.

Nie jest tajemnicą iż port 80 odnosi się do ruchu WWW tak więc zamiast określać numer portu możemy użyć nazwę usługi. Zapis: access-list 180 permit tcp any any eq 80 będzie tożsamy z access-list 180 permit tcp any any eq www

Dostępnych jest wiele nazw usług, których zamiennie możemy użyć zamiast numeru portu, poniżej została przedstawiona lista tych najczęściej używanych (nazwy dotyczą protokołu TCP).

W przypadku protokołu UDP do dyspozycji mamy następujące zmienne:

Oprócz warunku równości portu do dyspozycji mamy jeszcze następujące zmienne:

gt - dopasowywanie tylko pakietów z większym numerem portu, warunek: access-list 180 permit tcp any any gt 80 oznacza możliwość nawiązania połączenia z hostem docelowym pod warunkiem iż połączenie nawiązywane jest z portem o numerze wyższym niż 80,

lt - dopasowywanie tylko pakietów z mniejszym numerem portu, warunek: access-list 180 permit tcp any any lt 80 oznacza możliwość nawiązania połączenia z hostem docelowym pod warunkiem iż połączenie nawiązywane jest z portem o numerze niższym niż 80,

neq - dopasowywanie tylko pakietów, których port nierówna się, warunek: access-list 180 permit tcp any any neq 80 oznacza możliwość nawiązania połączenia z hostem docelowym pod warunkiem iż połączenie nie jest nawiązywane z portem o numerze 80 (wszystkie numery portów są dozwolone tylko nie port 80),

range - dopasowywanie tylko pakietów, których numer znajduje się w zdefiniowanym zakresieportu z mniejszym numerem portu, warunek: access-list 180 permit tcp any any range 80 100 oznacza możliwość nawiązania połączenia z hostem docelowym pod warunkiem iż połączenie nawiązywane jest z portem o numerze, który mieści się w zakresie od 80 do 100 (do zakresu port 80 oraz 100 również się wlicza).

Wszystko już wiemy zatem przechodzimy do przykładu.

Usługa dostępu dla protokołu zdalnego z wykorzystaniem SSH została skonfigurowana na routerze R3 – jak wykonać taką konfigurację odsyłam do wpisu: Dostęp zdalny oraz prawa użytkownika w urządzeniach CISCO

Wykonajmy sprawdzenie dostępności portu dla usługi SSH z wykorzystaniem narzędzia NMap. Użyta komenda wykona skanowanie TCP portu 22 (jeśli chcesz poznać bardziej zaawansowane techniki skanowania zapraszam tym razem do zapoznania się z tym artykułem: Co w sieci siedzi. Skanowanie portów).Jak widać poniżej test kończy się sukcesem – port jest otwarty i czeka na nawiązanie połączenia.

Połączenie z routerem następuje przy wykorzystaniu programu OpenSSH, po wywołaniu polecenia oraz podaniu danych uwierzytelniających połączenie zostaje zestawione (przy pierwszym połączeniu trzeba zaakceptować tzw. „odcisk palca”). Łączność z routerem została ustanowiona z hosta 10.0.1.20 (Windows7).

W tym momencie, jeszcze żadna lista ACL ograniczająca możliwość nawiązania połączenia nie została zdefiniowana tak więc połączenie może być zestawione z dowolnego komputera. Jak widać poniżej test połączenia z hosta 10.0.1.10 (WindowsXP_1) również kończy się sukcesem.

Celem ćwiczenia jest skonfigurowanie takiej listy ACL, która pozwoli na nawiązanie sesji SSH tylko z hosta 10.0.1.20 (reszcie komputerów z podsieci 10.0.1.0/24 prawo to ma być odebrane). Lista ACL wykonująca to zadanie została przedstawiona na zrzucie poniżej (zadanie wykonamy przy wykorzystaniu listy ACL rozszerzonej, nazywanej):

punkt 1 - rozpoczynamy od utworzenia listy ACL o nazwie ruchSSH,

punkt 2 - utworzony warunek zezwala na ruch TCP (zapis: permit tcp) z hosta o adresie IP 10.0.1.20 (zapis: host 10.0.1.20) do hosta o adresie IP 10.0.3.1 (zapis: host 10.0.3.1) pod warunkiem iż ruch ten dotyczy portu 22 (zapis: eq 22),

punkt 3 - ponieważ router R3 posiada w naszej sieci dwa aktywne interfejsy sieciowe tak więc połączenie SSH może zostać nawiązane z dowolnym z nich, aby host 10.0.1.20 mógł sesje SSH zestawić z interfejsem po stronie sieci 192.168.2.0/30 trzeba mu na to pozwolić. Warunek zezwalający na połączenie SSH przyjmie tę samą postać co w punkcie 2 z drobną różnicą dotyczącą hosta docelowego – zapis: host 192.168.2.1

punkt 4 - w założeniu ćwiczenia reszcie hostów, prawo nawiązania połączenia SSH ma zostać odebrane tak więc dzięki definicji warunku: deny tcp any any eq 22 łączność z routerem R3 zostaje zablokowana. A gwoli ścisłości żaden host z sieci 10.0.1.0/24 nie będzie mógł nawiązać sesji SSH z żadnym z hostów zdalnych (bardziej zasadne byłyby warunki ograniczające ten zakaz do sieci 10.0.3.0/24 oraz 192.168.2.0/30 – deny tcp any 10.0.3.0 0.0.0.255 eq 22 oraz deny tcp any 192.168.2.0 0.0.0.3 eq 22),

punkt 5 - ostatnią czynnością jest przypisanie listy do interfejsu, ponieważ listę rozszerzoną nieważne czy jest to lista numerowana czy nazywana zakładamy najbliżej celu to łączem do którego będziemy listę przypisywać jest interfejs f0/0 routera R1. O tym jeszcze nie wspominałem ale przy nazywanej liście ACL wielkość liter ma znaczenie oznacza to, ni mniej ni więcej iż nazwa listy ruchSSH nie jest tożsama z nazwą ruchssh.

Po skonfigurowaniu listy ACL przechodzimy do jej przetestowania, test rozpoczynamy od hosta 10.0.1.20. Jak widać poniżej hostowi udało się połączenie SSH z routerem nawiązać.

Pora na komputer o adresie IP 10.0.1.10. W tym przypadku dostęp do routera okazał się niemożliwy.

Aby faktycznie potwierdzić możliwość zestawienia poprawnego połączenia SSH został wykonany skan portu 22 interfejsu routera R1. Skan pierwszy odbył się z hosta 10.0.1.20 i jak widać port został zidentyfikowany jako: open Oznacza to możliwość nawiązania połączenia. Drugi skan przeprowadził komputer 10.0.1.10, tym razem status portu został określony jako: filtered co oznacza iż port jest filtrowany. Status taki najczęściej pojawi się w przypadku hosta znajdującego się za zaporą sieciową bądź innym mechanizmem kontrolującym ruch sieciowy. W naszym przypadku jest to lista ACL.

Aby faktycznie sprawdzić działanie listy ACL sprawdźmy jej stan. Wywołanie polecenia: show access-lists uwidoczni ilość dopasowań. Lista ACL działa jak należy.

Listy ACL standardowe oraz rozszerzone nie są jedynym dostępnym arsenałem, który pozwoli nam na kontrolowanie ruchu w naszej sieci. Opisane wyżej typy list ACL nie są w stanie zapewnić nam rozwiązania wszystkich problemów na jakie możemy natknąć się podczas sprawowania kontroli nad zarządzaną siecią. Dlatego też powstały dodatkowe rozwiązania, które pozwalają nam na wprowadzenie mechanizmów odpowiedzialnych za usprawnienie przepływu pakietów generowanych przez zarządzaną sieć.

Nie jest tajemnicą i stwierdzenie tym „Ameryki nie odkryję” że we współczesnych sieciach komputerowych dąży się do rozwiązań w których niepożądany ruch sieciowy pochodzący z zewnątrz (czytaj - ruch sieciowy pochodzący z obszarów nad którymi nie sprawujemy kontroli - najczęściej Internet) powinien zostać odfiltrowany (zablokowany) zanim zostanie przekazany do wnętrza sieci.

Oczywiście istnieją odstępstwa od tej reguły gdyż nie wszystkie pakiety, które pochodzą z zewnątrz są niepożądane i co ważne nie mogą podlegać blokowaniu. Jak więc sprawować kontrolę nad tym co trafia do naszej sieci tak by jej użytkownicy mogli realizować swoje zadania a jednocześnie nie narażać się na atak.

Jeśli znamy charakterystykę ruchu, który nie zagraża naszej sieci poprzez odpowiednią definicję list ACL możemy jawnie zezwolić na pożądany ruch. Sytuacja trochę się gmatwa gdy do końca nie jesteśmy w stanie określić charakterystyki pakietów, które do sieci mogą trafić a które powinny być blokowane.

Bardzo często spotykamy się z sytuacją w której użytkownik sieci chce nawiązać połączenie z hostem znajdującym się np. w Internecie ale okazuje się to niemożliwe gdyż lista ACL założona na routerze brzegowym na takie połączenie zabrania.

Aby rozwiązać ten problem wdrożono mechanizmy, które umożliwią nam na poprawne zestawienie połączenia (niezbędne pakiety przez listę ACL zostaną przepuszczone) ale tylko pod warunkiem iż jest to ruch powrotny, który zainicjowany został wewnątrz sieci.

Istnieją następujące rozwiązania filtrowania ruchu:

TCP Established
Zwrotne (reflexive) ACL

Rozpocznijmy zatem od TCP Established. Mechanizm ten zaimplementowano w urządzeniach CISCO w roku 1995 a dał on możliwość filtracji pakietów w oparciu o definicję listy rozszerzonej w połączeniu z protokołem TCP. Użycie tego mechanizmu sprowadza się do dodania w definicji warunku listy ACL parametru: established.

Dodanie flagi: established do warunku spowoduje blokadę ruchu sieciowego pochodzącego z niezaufanej sieci z wyjątkiem odpowiedzi TCP związanych z zestawionymi połączeniami, zainicjowanymi wewnątrz sieci.

Działanie tego mechanizmu opiera się o proces nawiązywania połączenia TCP, gdyż użycie parametru: established wymusza na routerze sprawdzanie faktu ustawienia w nagłówku pakietu flag kontrolnych ACK lub RST. Jeśli jest ustawiona flaga ACK ruch TCP jest przepuszczany. W przeciwnym przypadku router zakłada, że ruch jest inicjowany na zewnątrz sieci i następuje jego blokada. Aby dokładnie zrozumieć sposób działania tej funkcji i dlaczego tak naprawdę router zezwoli bądź zabroni na przepuszczenie danego pakietu trzeba mieć wiedzę na temat etapów nawiązywania połączenia z wykorzystaniem protokołu TCP wtedy powyższy opis stanie się jasny. Aby ponownie nie opisywać tych samych zagadnień odsyłam do wpisu: Co w sieci siedzi. Skanowanie portów w którym to zawarłem dokładny opis ustanawiania sesji TCP.

Aby dokładnie zrozumieć sposób działania tego mechanizmu przyjmijmy w naszym ćwiczeniu topologię, która została przedstawiona na rysunku poniżej. Przy czym zakładamy (dla ułatwienia naszych rozważań) iż host Serwer WWW jest komputerem znajdującym się w sieci Internet zaś host WindowsXP_1 jest komputerem w sieci wewnętrznej.

Po skonfigurowaniu wszystkich funkcji wraz z adresami IP wykonujemy próbę połączenia z hosta WindowsXP_1 z serwerem www. Jak widać poniżej wprowadzenie adresu IP 192.168.1.1 w pasku adresu przeglądarki powoduje wyświetlenie domyślnej strony WWW serwera IIS. Połączenie WWW pomiędzy hostami zostało ustanowione.

Przyjęliśmy założenie iż serwer WWW znajduje się w sieci Internet tak więc aby odseparować nasza sieć wewnętrzną 192.168.0.0/24 od sieci zewnętrznej na routerze R1 została zdefiniowana lista ACL zabraniająca na wszelki kontakt z siecią lokalną 192.168.0.0/24 Założona na routerze lista ACL 100 zabrania na połączenia wykonywane w ramach protokołu IP (access-list 100 deny ip any any) – lista na interfejsie została skonfigurowana w ten sposób iż blokowany jest ruch wejściowy (ip access-group 100 in).

Po tak skonfigurowanej liście ACL żadne połączenie z sieci Internet z naszą wewnętrzną siecią nie może być ustanowione (oczywiście warunek ten dotyczy protokołu IP).

Próba ponownego połączenia z serwerem WWW kończy się niepowodzeniem. Pakiety wysłane z hosta WindowsXP_1 do serwera WWW docierają bez problemu lecz pakiety pochodzące od serwera są blokowane prze listę ACL czego konsekwencją jest brak możliwości zestawienia połączenia. Serwer WWW w tej konfiguracji jest nieosiągalny.

Oczywiście sytuacja taka jest nie do zaakceptowania gdyż uniemożliwienie użytkownikom na korzystanie z sieci WWW na pewno jako administratorowi przysporzy Ci wielu problemów. Jak więc pogodzić funkcjonalność z bezpieczeństwem naszej sieci? Należy zdefiniować nową listę ACL w której to pozwolimy na ruch WWW lecz tylko pod warunkiem iż to użytkownik go zainicjuje.

Aby wywołane przez użytkownika sieci wewnętrznej połączenie z serwerem WWW mogło dojść do skutku należy pozwolić na ruch powrotny przesyłany od strony serwera. Bądź mówiąc krócej - ruch ten nie może być blokowany przez listę ACL.

Aby wykonać zadanie należy poprawić zdefiniowaną w poprzednim kroku listę ACL. W nowej liście ACL został zdefiniowany warunek (access-list 100 permit tcp any eq 80 192.168.0.0 0.0.0.0 established), który pozwala na nawiązanie połączenia TCP z dowolnym hostem pod warunkiem iż połączenie jest nawiązywane z docelowym portem 80 a ruch ten pochodzi z sieci o prefiksie 192.168.0.0/24. Dodanie parametru: established zezwala na ruch powrotny. Gdyż ruchem dozwolonym jest tylko ruch WWW, kolejny warunek (access-list 100 deny ip any any) zabrania na nawiązanie jakichkolwiek innych połączeń. Lista tak jak poprzednia jest założona w kierunku wejściowym na interfejsie od strony Internetu.

Po skorygowaniu listy ACL połączenie z serwerem WWW zostało przywrócone.

Sprawdzenie listy ACL przy wykorzystaniu polecenia: show access-lists przekonuje nas o tym iż lista działa.

Mechanizm ten nie jest doskonały gdyż należy mieć świadomość iż użycie parametru: established pozwoli na ruch sieciowy każdemu segmentowi TCP, który będzie miał ustawioną odpowiednią flagę kontrolną a wykorzystanie go ogranicza się tylko do protokołu TCP.

Niestety nie przewidziano przechowywania informacji o stanie pakietów, które w wyniku działania mechanizmu trafiły do naszej sieci tak by stwierdzić, czy przepuszczony ruch był związany z nawiązanym połączeniem czy też nie.

Rok później po wprowadzeniu list TCP Established wprowadzono kolejny wariant list ACL, których zadaniem jest oczywiście filtrowanie pakietów – są to tzw. listy zwrotne (reflexive). Tak jak w przypadku rozwiązania opisanego wyżej administratorzy sieci wykorzystują zwrotne ACL, aby zezwolić na ruch IP (nie tylko TCP) pochodzący z ich sieci i zabronić na ruch IP zainicjowany z zewnątrz.

Wadą mechanizmu ACL established jest brak wsparcia dla innych protokołów niż TCP co jest dość poważnym ograniczeniem . W rozwiązaniu reflexive ACL filtrowanie ruchu odbywa się w oparciu o adresy źródłowe i docelowe oraz numery portów. Takie podejście do sprawy umożliwia wykorzystanie tego rozwiązania do filtrowania ruchu sieciowego w oparciu o protokół UDP czy ICMP.

W zwrotnych listach ACL dodatkowo zaimplementowano tzw. filtry tymczasowe, których zadaniem jest zezwolenie na ruch powrotny. Tworzenie filtrów tymczasowych odbywa się poprzez analizę ruchu wyjściowego (podczas rozpoczęcia nowej sesji IP) a wpisy są usuwane po zakończeniu sesji.

Aby pokazać sposób działania list zwrotnych ACL i ich konfigurację wykonajmy ćwiczenie w którym pozwolimy na łączność WWW i DNS - ruch musi być zainicjowany po stronie sieci lokalnej. Ruch sieciowy pochodzący z zewnątrz ma zostać zablokowany.

Etapy konfiguracji list zwrotnych przedstawiają się następująco (do omówienia tego typu list ACL została użyta ta sama topologia sieciowa co w przykładzie wyżej):

Krok 1.

Rozpoczynamy od utworzenia wewnętrznej listy ACL (jest to lista rozszerzona), której zadaniem jest sprawdzanie połączeń wyjściowych - punkt 1 (lista ta przyjęła nazwę WEW_ACL). W scenariuszu szukanymi połączeniami będę te, które odpowiadają za ruch związany z przeglądaniem stron internetowych i rozwiązywaniem nazw domenowych (DNS) - punkt 2 (korzystanie z usługi DNS zostało ustalone na 5 sekundowy timeout).

Stworzenie wewnętrznej ACL, która szuka nowych połączeń wyjściowych i tworzy tymczasowe zwrotne ACE (wpisy do ACL)

Krok 2.

Aby połączenie doszło do skutku musimy pozwolić na ruch powrotny dlatego w tym celu została utworzona zewnętrzna lista ACL (lista ta przyjęła nazwę ZEW_ACL) - punkt 3. Podczas definicji warunków określających dozwolony ruch sieciowy został użyty parametr: reflect Zadaniem tej opcji jest przekazanie informacji o ruchu wyjściowym tak by poprzez utworzenie odpowiednich wpisów tymczasowych ruch powrotny nie był blokowany. Ruch związany z WWW zostaje przekazany do zmiennej WWW zaś informacja o ruchu domenowym do zmiennej DNS (punkt 2). W zewnętrznej liście ACL dzięki użyciu flagi: evaluate następuje definicja zmiennych WWW oraz DNS - punkt 4.

Dzięki takiej konfiguracji będą mogły zostać utworzone wpisy tymczasowe, które router utworzy automatycznie dzięki analizie połączeń (informacji zawartych w nagłówkach pakietów) a których zadaniem jest zezwolenie na ruch pakietów od strony Internetu do naszej sieci wewnętrznej. Inny ruch sieciowy od strony Internetu do sieci wewnętrznej nie będzie przepuszczony gdyż nie jest on częścią połączenia, które zostało zainicjowane po stronie sieci lokalnej. Warunek: deny ip any any jawnie zabrania na jakąkolwiek komunikację z wykorzystaniem protokołu IP.

Krok 3.

Ostatnią czynnością jest umieszczenie utworzonych list ACL na odpowiednich interfejsach. Ponieważ lista ACL WEW_ACL zezwala na połączenia WWW oraz DNS zostaje ona umieszczona na interfejsie po stronie Internetu w kierunku wyjściowym (punkt 5) zaś w liście ACL ZEW_ACL będą tworzone wpisy tymczasowe zezwalające na ruch powrotny to kierunek działania tej listy został zdefiniowany na: in (wejście) - punkt 6.

Listy zwrotne ACL zostały skonfigurowane, sprawdźmy zatem efekt przeprowadzonej konfiguracji. Host 192.168.0.1 znajduje się w sieci lokalnej i powinien mieć możliwość komunikacji z serwerem www. Jak widać poniżej po wprowadzeniu adresu serwera w oknie przeglądarki połączenie WWW zostaje nawiązane. Test ping pomiędzy hostem a serwerem kończy się niepowodzeniem gdyż ruch ICMP nie pasuje do zdefiniowanych reguł i dlatego jest blokowany.

Wydanie polecenia: show access-lists ukaże nam ilość zastosowania warunków. Jak można stwierdzić poniżej ruch WWW i DNS opuszczający naszą sieć lokalną jest prawidłowo przesyłany dalej.

Zwrotne listy ACL dla początkujących mogą stanowić pewne wyzwanie tak więc spróbujmy prześledzić jeszcze jeden przykład. Bazujemy na tej samej topologii i spróbujmy wykonać przykład w którym będzie można wykonać test przy użyciu polecenia: ping Założenie ćwiczenia jest takie, że wykorzystujemy zwrotną listę ACL; test ping następuje z sieci 192.168.0.0/24 do sieci 192.168.1.0/24 Sieć 192.168.1.0/24 oczywiście nie może bezpośrednio skomunikować się z siecią 192.168.0.0/24 przy użyciu protokołu ICMP; inny ruch jest dozwolony.

Tak jak w poprzednim przykładzie rozpoczynamy od definicji warunków listy ACL, która będzie sprawdzać ruch wyjściowy – lista ACL została nazwana: PING_OUT W warunkach listy została zdefiniowana reguła ICMP_POWROT odpowiedzialna za utworzenie wpisów pozwalających na powrót pakietów ICMP. Wpis: permit ip any any zezwala na ruch związany z protokołem IP (punkt 1).

W drugiej liście ACL za pomocą słowa evaluate określono regułę zwrotną ICMP_POWROT odpowiedzialną za przepuszczenie ruchu sieciowego ICMP pochodzącego z zewnątrz a będący odpowiedzią na ruch zainicjowany z sieci lokalnej. Jeśli router poprzez analizę danych zawartych w nagłówku pakietu nie dopasuje go do reguły ICMP_POWROT nastąpi próba dopasowania do warunków zdefiniowanych dalej. Warunek: deny icmp ip any any jawnie zabrania na ruch ICMP, który nie spełnia wymogów ruchu zwrotnego (punkt 2).

Ostatnią czynnością jest przypisanie utworzonych list do interfejsu oraz określenie kierunku ich działania. Ponieważ lista PING_OUT odpowiada za ruch wychodzący jej kierunek działania został zdefiniowany na wyjście. Natomiast lista ACL jest listą analizującą ruch powrotny tak więc kierunek działania został ustalony na wejście (punkt 3).

Nie pozostaje nam nic innego jak sprawdzić efekt działania zdefiniowanych list ACL.

Przeprowadźmy test z ping z hosta 192.168.0.1 w kierunku hosta 192.168.1.1 Jak można stwierdzić po analizie zrzutu poniżej test kończy się sukcesem. Powrotny ruch ICMP został przepuszczony gdyż był on częścią sesji króra została zapoczątkowywana po stronie sieci 192.168.0.0/24

Ruch ICMP w drugim kierunku (od hosta 192.168.1.1 w kierunku hosta 192.168.0.1) jest blokowany gdyż router wie iż ruch ten nie stanowi części komunikacji.

Przy definicji warunku: deny icmp ip any any użyliśmy parametru log, który pozwoli nam na uzyskanie więcej szczegółów na temat zablokowanych pakietów. Jak widać zablokowane pakiety zostały wysłane z hosta 192.168.1.1 a zgodnie z zdefiniowanymi listami ACL pakiety te mają być blokowane.

Dzięki zaś zezwoleniu na dowolny ruch IP (warunki: permit ip any any) komunikacja z hostami zostaje zachowana – próba skopiowania pliku pomiędzy hostami kończy się sukcesem.

Aby użytkownicy mogli uzyskać dostęp do chronionych przez listę ACL obszarów sieci administrator może wykorzystać do tego celu tzw. listy dynamiczne (ang. dynamic ACL). Ten typ list nazywany jest również listami lock-and-key (zamek i klucz). Zadaniem tego typu list jest uwierzytelnienie użytkownika i po prawidłowym przeprowadzeniu tego procesu użytkownik uzyskuje dostęp do chronionego obszaru sieci (możliwość nawiązania połączenia z hostem lub całą podsiecią. Dostęp jest przyznawany przez ograniczony czas.

Sposób działania list dynamicznych opiera się o takie mechanizmy jak:

łączność telnet bądź SSH,
uwierzytelnianie lokalne lub zdalne,
rozszerzone ACL.

Sposób działania oraz konfiguracja dynamicznej listy ACL można opisać w następujących krokach:

rozpoczynamy od zdefiniowania rozszerzonej listy ACL, której zadaniem jest blokada ruchu sieciowego z wyjątkiem połączeń Telnet bądź SSH,
użytkownicy, którzy chcą połączyć się z siecią, która jest chroniona przez listę ACL są tak długo blokowani, dopóki nie wykonają połączenia Telnet. Nawiązanie połączenia oczywiście musi zakończyć się sukcesem tzn. by połączenie doszło do skutku należy poprawnie się uwierzytelnić,
po nawiązaniu połączenia Telnet (bądź SSH). Połączenie zostaje zakończone automatycznie,
poprawne uwierzytelnienie spowoduje dodanie jednego dynamicznego warunku do już istniejącej listy ACL,
dodany wpis umożliwia nawiązanie połączenia z siecią, która w normalnych warunkach jest niedostępna. Dodatkowo możliwe jest określenie czasu bezczynności oraz timeout.

Dynamiczne listy ACL stosujemy w celu:

aby zapewnić użytkownikowi bądź grupie użytkowników zdalnych dostęp do sieci wewnętrznej,
aby hosty w sieci lokalnej miały dostęp do hostów w sieci zdalnej, chronionej przez firewall.

Konfigurację listy dynamicznej rozważymy na już znanej nam topologii sieciowej, która dla przypomnienia została przedstawiona poniżej. Celem naszego ćwiczenia jest umożliwienie hostowi 192.168.0.1 nawiązanie połączenia z komputerem 192.168.1.1. Zadanie ma być wykonane oczywiście przy wykorzystaniu listy dynamicznej ACL.

Kolejną czynnością jest definicja listy ACL. W pierwszym kroku zezwalamy na nawiązanie połączenia Telnet z interfejsem routera – punkt 2. Interfejs routera z którym będzie nawiązywane połączenie Telnet oczywiście dla hosta 192.168.0.1 musi być osiągalne. Dlatego też interfejs routera został ustalony na 192.168.0.254 gdyż oba adresy IP leżą w wspólnej przestrzeni adresowej IP.

Kolejny warunek listy ACL jest wpisem dynamicznym o nazwie DOSTEP Wpis ten zawiera warunek zezwalający na łączność pomiędzy sieciami 192.168.0.0/24 a 192.168.1.0/24 Wpis ten zostanie dodany po nawiązaniu połączenia Telnet i poprawnym uwierzytelnieniu – punkt 3.

Po definicji listy ACL następuje jej powiązanie z interfejsem f0/0 routera R1.

Aby lista ACL zadziałała musimy oczywiście zezwolić na nawiązanie połączenia Telnet. Tak więc kolejny krok (punkt 4) odpowiada za konfigurację linii VTY tak by sesja Telnet mogła zostać z routerem prawidłowo nawiązana. Zostaje ustawione uwierzytelnienie, które ma być przeprowadzone przy wykorzystaniu lokalnej bazy użytkowników.

Ponieważ na zrzucie powyżej nie wszystkie polecenia zostały uwidocznione poniżej jeszcze raz została przedstawiona konfiguracja dynamicznej listy ACL.

Sprawdźmy zatem dostępność sieci 192.168.1.1/24 z poziomu hosta 192.168.0.1 i wykonajmy test ping. Jak widać brak jest możliwości nawiązania połączenia pomiędzy obiema sieciami – host 192.168.0.1 nie może skomunikować się z hostem 192.168.1.1

Aby hosty mogły swobodnie między sobą prowadzić wymianę danych należy dodać warunek do listy ACL, który na taką komunikację pozwoli. Warunek ten zostanie dodany dynamicznie po poprawnym uwierzytelnieniu się za pomocą usługi Telnet. Nawiążmy więc połączenie Telnet z routerem R1.

Jak widać po kolejnym zrzucie połączenie zostało nawiązane i po podaniu prawidłowych danych użytkownika automatycznie zamknięte.

Sprawdźmy stan listy ACL. Rysunek poniżej przedstawia listę ACL przed nawiązaniem połączenia Telnet (punkt 1) i po nawiązaniu połączenia – punkt 2. Różnica pomiędzy oboma stanami listy ACL tkwi w dodaniu jednego warunku do listy ACL po nawiązaniu połączenia Telnet. Warunek ten zezwala na komunikację pomiędzy sieciami.

Ponowne wykonanie testu ping zostaje zakończone sukcesem, hosty nawiązały między sobą komunikację.

Sprawdzenie listy ACL da nam informację o ilości dopasowań oraz czasie aktywności dynamicznego wpisu.

Dynamiczna lista ACL została skonfigurowana prawidłowo.

Istnieje jeszcze jeden typ list ACL są to tzw. listy ACL czasowe (ang. time-based). Listy te pozwalają nam prowadzić kontrolę dostępu w oparciu o czas. Czasowe listy ACL są wygodnym mechanizmem gdyż z ich wykorzystaniem możemy dostęp do sieci przyznawać bądź odbierać w zależności od dnia tygodnia czy godziny.

Standardowo aby wytłumaczyć implementację czasowej listy ACL wykonajmy ćwiczenie, którego założenie jest następujące – Zabrońmy na komunikację pomiędzy sieciami 192.168.0.0/24 a 192.168.1.0/24 w każdy czwartek pomiędzy godziną 21:40 a 21:50. Oczywiście bazujemy nadal na tej samej topologii sieciowej co w poprzednich ćwiczeniach.

Aby zaimplementować time-based ACL rozpoczynamy od utworzenia zakresu czasu (time-range), który definiuje czas w którym lista ACL będzie aktywna. Stworzony zakres czasu ma przypisaną nazwę, do której będziemy odwoływać się podczas tworzenia warunków listy ACL. Ograniczenia zaś są definiowane przez samą listę ACL.

Rozpoczynamy od zdefiniowania zakresu. Time-range definiujemy w trybie konfiguracji globalnej po wydaniu polecenia: time-range <nazwa_zakresu> Po wydaniu polecenia określamy ramy czasowe. Interesujący nas okres obejmuje czwartek pomiędzy godziną 21:40 a 21:50 tak więc w trybie definicji zakresu wydajemy polecenie: Thursday 21:40 to 21:50 a że zdefiniowany interwał czasowy ma obejmować każdy czwartek zostaje dodany parametr: periodic Zdefiniowanemu zakresowi została przypisana nazwa: DOSTEP

Po zdefiniowaniu czasu obowiązywania listy ACL przystępujemy do określenia warunków samej listy ACL. Celem zadania jest uniemożliwienie komunikacji pomiędzy sieciami tak więc warunek listy ACL przyjmuje postać: deny ip any any a dodatkowo dzięki parametrowi: time-range do warunku zostaje przypisany zakres czasowy obowiązywania tego wpisu.

Stworzona lista ACL zostaje przypisana do interfejsu f0/0 routera R1. Kierunek działania listy został ustalony na wejście.

Sprawdzenie listy uwidacznia jej stan – lista ACL jest nieaktywna.

Lista ACL jest nieaktywna tak więc określone warunki listy nie są włączone. Sprawdźmy zatem czy uda nam się nawiązać komunikację pomiędzy hostami 192.168.0.1 a 192.168.1.1. Test ping kończy się niepowodzeniem. Czas wykonania testu to 21:35 czyli poza ustalonymi ramami zakresu – warunek zabraniający na komunikację ma być aktywny od 21:40

Lista ACL nie obowiązuje a my nie mamy dostępu do sieci 192.168.1.0/24 a według założeń scenariusza dostęp ma być odebrany tylko na 10 minut pomiędzy 21:40 a 21:50 Lista ACL zabrania na komunikację ponieważ nie wolno zapomnieć iż pomimo tego, że jest to czasowa lista ACL to nadal jest to lista ACL na końcu, której jest umieszczony niejawny warunek: deny any any Tak więc by komunikacja pomiędzy ustalonym zakresem była możliwa trzeba za pomocą warunku: permit ip any any jawnie na ruch sieciowy zezwolić.

Sprawdzenie listy ACL uwidacznia dodany warunek. Lista odbierająca dostęp do sieci 192.168.1.0/24 jest nieaktywna.

Sprawdźmy zatem jeszcze raz czy uda się nawiązać połączenie pomiędzy hostami. Połączenie doszło do skutku, wprowadzona korekta zdała egzamin. Połączenie jest możliwe gdyż czas obowiązywania zakazu jeszcze nie nadszedł.

Po 21:40 w czwartek wpis zabraniający na komunikację z stanu nieaktywny przechodzi do stanu aktywny. Ponieważ reguła ma niższy numer sekwencyjny jest stosowana jako pierwsza.

Komunikacja pomiędzy obiema podsieciami jest niemożliwa.

Ponowne sprawdzenie listy ACL uwidacznia liczbę dokonanych dopasowań.

Po godzinie 21:50 (oczywiście w czwartek) reguła kończy swe działanie.

Komunikacja pomiędzy sieciami zostaje przywrócona.

Z mechanizmem ACL związana jest jeszcze jedna funkcja a mianowicie grupy obiektów w listach ACL.

Grupy obiektów pozwalają nam na dokonanie klasyfikacji użytkowników, urządzeń oraz protokołów w grupy. Po dokonaniu przypisania do określonych grup możliwe jest utworzenie reguł kontroli dostępu obejmujących całą grupę.

Grupy obiektów można tworzyć zarówno dla IPv4, jak i dla IPv6.

Aby omówić ten mechanizm przyjmijmy, że mamy do czynienia z topologią sieciową przedstawioną na rysunku poniżej.

W przedstawionej powyżej topologii mamy do czynienia z trzema serwerami, z których każdy wymaga zezwolenia na ruch z zewnątrz dla trzech protokołów. Protokoły te to: SMTP (port 25), HTTP (port 80) oraz HTTPS (port 443).

Podczas definicji warunków listy ACL musielibyśmy utworzyć wpisy typu permit dla każdego serwera i dla każdego protokołu z osobna. Przykładowa konfiguracja routera wyglądałaby następująco:

W przypadku dodania kolejnego serwera jak również i dodatkowych protokołów musielibyśmy edytować listę ACL tak aby uwzględnić nowe wymagania.

Aby zaoszczędzić sobie czasu i problemów z bezpośrednią edycją listy ACL możemy wykorzystać mechanizm grup obiektów.

Konfiguracja rozpoczyna się od utworzenia grupy usług (ang. service group). Poniżej na listingu została utworzona grupa usług o nazwie: USŁUGI

Następnym etapem jest, utworzenie grupy urządzeń (ang. network group). Podczas definicji członków grupy możemy skorzystać ze słowa kluczowego range lub host a także zdefiniować podsieć. Poniżej została utworzona grupa urządzeń o nazwie SERWERY

Ostatnim zaś krokiem jest utworzenie samej listy ACL.

Aby lista mogła zacząć działać trzeba ją jeszcze powiązać z danym interfejsem. W naszym scenariuszu oczywiście będzie to interfejs routera znajdujący się od strony Internetu a kierunek działania musi przyjąć stan: in

Odtąd gdy zostanie dodany nowy serwer bądź usługa należy jedynie zmodyfikować grupę obiektów.

Powoli zbliżamy się do końca wpisu więc jako ostatni punkt naszych rozważań przed podsumowaniem proponuję kilka przykładów najczęściej stosowanych list ACL.

Lista ACL przedstawiona poniżej odpowiada za zablokowanie pakietów TCP z ustawionymi niedozwolonymi flagami tj. pakietów, które w normalnym funkcjonowaniu sieci nigdy nie powinny zostać utworzone. Więcej na ten temat znajdziesz w wpisie: Co w sieci siedzi. Skanowanie portów. Zastosowanie poniższych warunków zablokuje metody skanowania, które mogłyby być wykorzystane przez atakującego naszą sieć.

access-list 111 deny tcp any any ack fin psh rst syn urg

access-list 111 deny tcp any any fin

access-list 111 deny tcp any any urg psh fin

access-list 111 deny tcp any any rst syn

access-list 111 deny tcp any any rst syn fin

access-list 111 deny tcp any any syn fin

access-list 111 deny tcp any any rst syn fin ack

access-list 111 deny tcp any any syn fin ack

Ze względów bezpieczeństwa i dobrą praktyką jest na routerze brzegowym zablokowanie wszystkich pakietów, które mają następujące adresy źródłowe IP:

Adresy typu: local host (127.0.0.0/8)
Adresy przypisane siecią prywatnym (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16),
Adresy z grupy multikastowej (224.0.0.0/4).

Przykładowa lista ACL mogłaby mieć postać:

access-list 180 deny ip 0.0.0.0 0.255.255.255 any

access-list 180 deny ip 127.0.0.0 0.255.255.255 any

access-list 180 deny ip 10.0.0.0 0.255.255.255 any

access-list 180 deny ip 172.16.0.0 0.15.255.255 any

access-list 180 deny ip 192.168.0.0 0.0.255.255 any

access-list 180 deny ip 224.0.0.0 15.255.255.255 any

access-list 180 deny ip host 255.255.255.255 any

Kolejny przykład zabrania na ruch sieciowy (wyjściowy) pakietom z adresem źródłowym IP innym, niż ten, który obowiązuje w sieci wewnętrznej (czyli zakres adresów IP, który sam ustaliłeś).

access-list 180 deny ip <ustalony_adres_sieci> any

Ograniczenie dostępu do routera przy połączeniach zdalnych

Połączenie z routerem może ustanowić host o zdefiniowanym adresie IP.

access-list 90 permit host <adres_IP>

access-list 90 deny any

W trybie konfiguracji linii VTY

access-class 90 in

Zabronienie na ruch Telnet (TCP, Port 23)

access-list 102 deny tcp any any eq 23

access-list 102 permit ip any any

Zabronienie na ruch FTP (TCP, Port 21)

access-list 102 deny tcp any any eq ftp

access-list 102 deny tcp any any eq ftp-data

access-list 102 permit ip any any

Zezwolenie na ruch FTP

access-list 102 permit tcp any any eq ftp

access-list 102 permit tcp any any eq ftp-data established

Zezwolenie na ruch DNS

access-list 112 permit udp any any eq domain

access-list 112 permit udp any eq domain any

access-list 112 permit tcp any any eq domain

access-list 112 permit tcp any eq domain any

Zezwolenie na aktualizacje związane z routingiem

Protokół RIP - access-list 102 permit udp any any eq rip

Protokół IGRP - access-list 102 permit igrp any any

Protokół EIGRP - access-list 102 permit eigrp any any

Protokół OSPF - access-list 102 permit ospf any any

Protokół BGP - access-list 102 permit tcp any any eq 179 oraz access-list 102 permit tcp any eq 179 any

Podsumowanie (czyli to co warto powtórzyć bądź to o czym zapomniałem a co warto wiedzieć):

Osobna lista ACL powinna istnieć dla każdego protokołu i kierunku.
Standardowe listy ACL umiejscawiamy jak najbliżej miejsca docelowego, którego dotyczą.
Rozszerzone listy ACL umieszczamy jak najbliżej źródła, którego dotyczą.
Warunki budujące listę ACL są analizowane po kolei od góry do dołu aż do odnalezienia dopasowania o położeniu danego wpisu decyduje numer sekwencyjny.
Jeśli po analizie listy ACL nie wykryto dopasowania do żadnego z zdefiniowanych warunków pakiet jest odrzucany na wskutek działania nie jawnej instrukcji: deny any. Warunek ten nie jest uwzględniany na listingach konfiguracji.
Warunki budujące daną listę ACL powinny zostać zdefiniowane w kolejności od szczegółowych do ogólnych. Oznacza to iż na początku listy ACL znajdują się instrukcje dotyczące pojedynczych hostów zaś po nich instrukcje odnoszące się do grup i ogółu.
W przypadku wildcard mask bit 0 oznacza - wykonaj dopasowanie, zaś bit 1 - zignoruj.
Tworzone wpisy listy ACL zawsze są dodawane na końcu listy.
Zanim zostanie zastosowana instrukcja permit bądź deny musi nastąpić zgodność dopasowania informacji zawartych w nagłówku pakietu do warunku listy ACL.
Komentarze o sposobie działania listy ACL umieszczamy w osobnym pliku, zaś w opisie listy ACL definiujemy nazwę pliku zawierającego opis.
Lista ACL dla ruchu wychodzącego nie jest stosowana dla pakietów, których źródłem jest router lokalny.
Jeśli potrzeba jest ograniczenia ruchu sieciowego w oparciu o czas zastosuj listy ACL czasowe (ang. time-based).
Aby użytkownicy mogli uzyskać dostęp do chronionych przez listę ACL obszarów sieci wykorzystaj do tego celu listy dynamiczne.
Listy typu reflexive ACL umożliwiają filtrowanie ruchu w oparciu o adresy źródłowe i docelowe oraz numery portów. Ich użycie nie ogranicza się tylko do protokołu TCP jak to ma miejsce w przypadku list ACL Established.

Rozwiązanie

Możliwa jest taka definicja listy ACL gdyż zapis: permit 192.168.0.6 0.0.0.1 zezwala na ruch sieciowy pochodzący od hostów z zdefiniowanymi adresami IP 192.168.0.6 oraz 192.168.0.7 Dzieje się tak ponieważ maska wieloznaczna 0.0.0.1 tożsama jest z podsiecią 255.255.255.254 a sieć ta wraz w połączeniu z adresem IP 192.168.0.6 definiuje tylko dwa adresy IP - 192.168.0.6 oraz 192.168.0.7

Po dokonaniu korekty jak widać poniżej z hosta 192.168.0.1 nie udaje nam się spingować komputer 192.168.1.1

Zaś przy użyciu hosta 192.168.0.6 test ping kończy się sukcesem.

Sprawdzenie listy ACL tylko utwierdza nas w przekonaniu iż przyjęte rozwiązanie jest jak najbardziej prawidłowe.

Autoryzacja, uwierzytelnienie i rejestracja z wykorzystaniem serwera TACACS.

2016-07-05T10:14:43+00:00

W tym artykule kontynuujemy zapoczątkowany w poprzednim wpisie temat uwierzytelnienia użytkowników na urządzeniach CISCO lecz tym razem do wykonania tego zadania wykorzystamy serwer TACACS.

Protokół TACACS (ang. Terminal Access Controller Access-Control System) został opracowany w 1980 roku przez firmę BBN. Firma ta została przejęta przez organizację Verizion by w następstwie stać się własnością firmy CISCO.

Pierwotnie protokół TACACS zakładał obsługę podstawowych operacji związanych z przekazywaniem informacji uwierzytelniających oraz definiował sposób ich weryfikacji. W roku 1990 firma Cisco rozbudowała protokół TACACS o nowe możliwości i nadała mu nazwę XTACACS (ang. Extended TACACS). Kolejne usprawnienia protokołu i dodanie do nich nowych funkcji przeobraziło protokół to formy w jakiej znamy go dziś. Nowa implementacja protokołu przyjęła nazwę TACACS+. Wszystkie trzy wymienione wersje protokołu nie są kompatybilne ze sobą lecz ich obsługa i wsparcie jest uwzględnione w systemach lOS.

TACACS jest rozwiązaniem konkurencyjnym do już omawianego protokołu RADIUS więc myślę, że czas na małe porównanie. Porównanie obu rozwiązań zostało zawarte w tabeli poniżej.

RADIUS	TACACS+
RADIUS działa na protokole UDP	TACACS+ działa na protokole TCP
RADIUS używa portu 1645 lub 1812 do uwierzytelniania i portu 1646 lub 1813 do rozliczania	TACACS+ używa portu 49
Protokół RADIUS ukrywa hasła podczas transmisji, ale reszta pakietu jest wysyłana w postaci zwykłego tekstu.	TACACS+ szyfruje całą komunikację
RADIUS łączy uwierzytelnianie i autoryzacja	TACACS+ oddzielnie traktuje uwierzytelnianie, autoryzacje i rozliczanie
RADIUS jest otwartym protokołem obsługiwanym przez wielu dostawców. RADIUS jest zdefiniowany w RFC 2865, 2866, 2867, and 2868.	TACACS+ jest własnością CISCO.
RADIUS wprowadza mniejszy narzut podczas działania	TACACS+ zużywa więcej zasobów
RADIUS jest ograniczony do trybu uprawnień privilege mode	TACACS+ wspiera 15 privilege levels
Odpowiadający głównie za dostęp do sieci	Wykorzystywany do Device Administration

Sposób komunikacji pomiędzy klientem, routerem a serwerem w obu przypadkach przebiega odmiennie więc na dwóch poniższych schematach zaprezentowano wymianę danych jak zachodzi podczas próby wykonania logowania.

Wymiana danych z wykorzystaniem serwera TACACS.

Wymiana danych z wykorzystaniem serwera RADIUS.

Jak można zaobserwować proces uwierzytelnienia wykorzystujący TACACS przebiega etapami. Pierwszym etapem jest nawiązanie przez klienta połączenia z routerem, następnie urządzenie te w kierunku serwera wysyła zapytanie wskazujące na podanie nazwy użytkownika. Jeśli serwer TACACS takie żądanie zaakceptuje w drugim kroku następuje podanie przez klienta nazwy użytkownika, która to z kolei zostaje przez router przesłana do serwera. Proces ten powtarza się również w przypadku hasła. Jeśli podane przez klienta dane są prawidłowe, serwer przyznaje dostęp.

W rozwiązaniu opartym o serwer RADIUS urządzeniem odpytującym jest również router. W tym rozwiązaniu router pyta klienta o login i hasło i jeśli te dane uzyska przesyła je w kierunku serwera RADIUS. Serwer po analizie otrzymanych danych udziela bądź odmawia dostępu.

Topologia naszej ćwiczebnej sieci tak samo jak w przypadku serwera RADIUS nie jest skomplikowana i została przedstawiona na rysunku poniżej.

Jako serwer TACACS posłuży nam oprogramowanie ACS czyli Cisco Secure. Rozwiązanie te dostarczane jest jako osobny system operacyjny oparty o Linux bądź dedykowane urządzenie. Wcześniejsze wersje ACS działały również w oparciu o system Windows jako osobna aplikacja lecz te rozwiązanie nie jest już ani wspierane ani rozwijane.

Niestety ACS nie jest oprogramowaniem darmowym by z niego korzystać należy je zakupić. Na nasze szczęście CISCO umożliwia uzyskanie licencji próbnej, której czas został ograniczony do 90 dni. Licencja ta w zupełności nam wystarczy do nauki wystarczy.

Aby uzyskać licencję należy przejść do strony: https://tools.cisco.com/SWIFT/LicensingUI/Quickstart By móc uzyskać licencję w pierwszej kolejności należy założyć konto.

Po uzyskaniu dostępu wybieramy Get Other Licenses a następnie z rozwijanego menu klikamy Demo and Evaluation.

W nowo otwartym oknie w sekcji Product Family wybieramy Network Mgmt Products a następnie Cisco Secure Access Control System Evaluation. Klikamy Next

Po uzyskaniu licencji na podany podczas rejestracji adres email zostanie wysłany stosowny plik (plik z rozszerzeniem *.lic), plik licencji możemy również pobrać bezpośrednio ze strony.

Posiadamy licencję a więc czas by uzyskać obraz systemu. Tu już niestety tak łatwo nie jest, gdyż bezpośrednio ze strony CISCO obrazu w formie pliku ISO nie pobierzemy. Trzeba poszukać i pobrać odpowiedni plik z innego źródła, tu już odsyłam do wyszukiwarki.

Przechodzimy do instalacji oprogramowania, instalacja zostanie przeprowadzona z wykorzystaniem maszyny wirtualnej.

Rozpoczynamy od pobrania i od zainstalowania oprogramowania VMware Player. Dlaczego VMware a nie VirtualBox? Anoż dlatego, że pomimo podjętych prób (kilka przerobionych tutoriali) nie udało mi się zainstalować serwera ACS z wykorzystaniem VirtualBox. Program instalacyjny odpalał się prawidłowo lecz po chwili uzyskiwałem komunikat o niezgodności sprzętowej i niemożności kontynuowania instalacji. Jeśli Czytelniku znasz rozwiązanie tego problemu to Ja go chętnie poznam. W przypadku wspomnianego VMware instalacja przebiegła bez żadnych zakłóceń.

Po zainstalowaniu oprogramowania przechodzimy do konfiguracji nowej maszyny wirtualnej, parametry maszyny zostały ustalone tak jak na poniższych screenach. Na początek pamięć RAM - ustawienie 2GB.

Kolejną czynnością było ustalenie parametrów dysku twardego. Dysk został zdefiniowany jako SCSI z domyślną wartością LSI Logic a jego rozmiar to 70 GB (ACS wymaga co najmniej 60GB miejsca).

Aby serwer był dostępny z poziomu sieci LAN, karta sieciowa została ustawiona do pracy w trybie Bridged: Connected directly to the physical network

Typ wirtualnej maszyny został ustalony na obsługę systemu Red Hat Enterprise Linux 6.

Opcje związane z obsługą USB oraz dźwięku zostały usunięte.

Maszyna wirtualna została skonfigurowana, przechodzimy do instalacji serwera ACS. Po uruchomieniu wirtualnego hosta i wskazaniu pliku obrazu systemu (plik ISO) powinien pojawić się nam ekran na którym możemy zdecydować o typie przeprowadzanej instalacji (obraz umożliwia również wykonanie operacji resetowania zapomnianego hasła). Z menu wybieramy: Cisco Secure ACS 5.4 Instalation (Keyboard/Monitor) - opcja 1.

Po wybraniu typu instalacji następuje proces formatowania dysku.

Po wykonaniu formatowania rozpoczyna się proces kopiowania plików systemu ACS.

Po zakończonym kopiowaniu powinien nastąpić restart maszyny po którym powinien ukazać się nam ekran jak na zrzucie poniżej. Przechodzimy do konfiguracji podstawowych parametrów serwera ACS. Aby rozpocząć konfigurację po ciągu localhost login: wpisujemy setup i zatwierdzamy klawiszem Enter.

Przechodzimy do konfiguracji podstawowych parametrów:

1 - adres IP serwera,

2 - maska sieci,

3 - adres IP bramy,

4 - nazwa domeny,

5 - adres IP serwera DNS,

6 - adres serwera czasu NTP,

7 - strefa czasowa,

8 - dane uwierzytelniające tj. login oraz hasło.

Jeśli któryś danych nie znasz to pozostaw puste miejsce i zatwierdź klawiszem Enter.

Po określeniu wszystkich parametrów nastąpi proces konfiguracji serwera ACS. Efektem końcowym procesu powinien być ekran logowania. Aby się zalogować wykorzystaj dane podane w poprzednim kroku.

Serwer ACS powinien się uruchomić. Jest to dobry moment aby wykonać kilka testów sprawdzających poprawność działania serwera. Rozpoczynamy od sprawdzenia dostępności serwera ACS. Zostaje wykonana próba sprawdzenia osiągalności serwera z poziomu sieci LAN. Jak można zauważyć poniżej test ping kończy się sukcesem. Możliwa jest komunikacja z serwerem ACS.

Kolejne testy wykonamy w linii CLI serwera ACS. Pierwszym testem jest sprawdzenie wersji serwera. Wersję systemu poznamy po wydaniu polecenia: show version

Drugi test to sprawdzenie poprawności uruchomionych procesów. Sprawdzenia dokonamy za pomocą polecenia: show application status acs Lista uruchomionych procesów została przedstawiona poniżej.

Ostatni test dotyczy sprawdzenia poprawności konfiguracji serwera. Konfigurację serwera poznamy po wydaniu komendy: show running-config

Serwer ACS działa tak więc przechodzimy do jego konfiguracji. Konfiguracja odbywa się za pomocą przeglądarki internetowej (w ten sam sposób w jaki konfigurujemy np. router). Otwieramy przeglądarkę i w polu adresu wpisujemy: https://<adres_IP_serwera> (ważne jest byś dodał https samo wpisanie adresu IP nie wystarczy).

Po wysłaniu żądania otwarcia strony zostaniemy poinformowaniu o problemie z certyfikatem strony - nie martw się jest to jak najbardziej pożądany komunikat. Aby móc przejść dalej zaznaczamy Kontynuuj przeglądanie tej witryny sieci Web (to w przypadku Internet Explorera) natomiast jeśli korzystamy np. z Firefoxa wybieramy Zaawansowane a następnie Dodaj wyjątek.

W nowo otwartym oknie Dodanie wyjątku bezpieczeństwa zaznaczamy opcję Zachowaj wyjątek na stałe (przy ponownym połączeniu problem z certyfikatem już nie wystąpi) a następnie Potwierdź wyjątek bezpieczeństwa.

Po zatwierdzeniu ukarze się nam okno logowania serwera ACS. Ponieważ jest to nasze pierwsze logowanie w polu Username wpisujemy acsadmin zaś hasłem jest słowo default.

Po wpisaniu danych uwierzytelniających zostaniemy poinformowani o potrzebie zmiany hasła. Hasło ustalamy sami. Po ustaleniu wartości hasła klikamy Zaloguj się.

Następny krok to wczytanie licencji. Po wyborze przycisku Przeglądaj wskazujemy na plik licencji otrzymany od CISCO.

Wybieramy Install.

Po wykonaniu wszystkich opisanych czynności uzyskamy dostęp do panelu konfiguracyjnego serwera ACS. W lewym górnym rogu ukazana jest informacja o liczbie pozostałych dni po upływie których musimy odnowić licencję.

Konfigurację serwera rozpoczniemy od utworzenia nowej grupy urządzeń. Ponieważ w naszym scenariuszu konfigurowanym urządzeniem jest router tak więc tworzoną grupę nazwiemy Routery.

Aby skonfigurować nową grupę urządzeń przechodzimy do gałęzi: Network Resources/Network Device Group/Device Type Po przejściu do gałęzi klikamy Create.

Aby utworzyć nową grupę wypełniamy pola obowiązkowe, które są oznaczone pomarańczową gwiazdką. Nazwa grupy została zdefiniowana jako Routery zaś pole Parent pozostawiamy bez zmian. Opcjonalnie możemy wprowadzić opis tworzonej grupy (pole Description) Po zdefiniowaniu wszystkich danych klikamy Submit.

Grupa Routery została utworzona. Aby edytować informacje o grupie bądź sprawdzić fakt jej utworzenia w gałęzi Network Resources/Network Device Group/Device Type klikamy na strzałkę przy nazwie rodzica (w naszym przypadku All Device Types).

Po utworzeniu grupy musimy zdefiniować konto urządzenia. Aby utworzyć konto przechodzimy do gałęzi Network Resources/Network Devices and AAA Clients. Po otwarciu okna podobnie jak w przypadku tworzenia grupy w pierwszej kolejności klikamy na przycisk Create.

Po otwarciu nowego okna definiujemy:

1 - nazwę urządzenia oraz jego opis,

2 - adres IP urządzenia,

3 - sposób uwierzytelnienia, odhaczamy opcję TACACS+ oraz definiujemy hasło klucza (hasło będzie potrzebne przy konfiguracji routera).

Ostatnim krokiem jest dodanie konta tworzonego urządzenia do wcześniej utworzonej grupy. Aby przypisać urządzenia R1 do grupy Routery wybieramy przycisk Select (w obrębie opcji Device Type) a następnie po otwarciu nowego okna przeglądarki zaznaczamy grupę.

Po wybraniu kolejno OK oraz Submit konto urządzenia R1 zostaje przypisane do grupy Routery.

Po utworzeniu konta urządzenia kolejnym krokiem jest zdefiniowanie konta użytkownika, który do urządzenia będzie miał przyznane prawo logowania. Tak jak poprzednio rozpoczynamy od utworzenia grupy użytkowników.

Aby utworzyć grupę użytkowników przechodzimy do gałęzi Users and Identity Stores/Identity Groups a następnie wybieramy Create.

Uzupełniamy pola: nazwa tworzonej grupy, opis grupy (opcjonalnie), pole Parent pozostawiamy bez zmian.

Jak widać na zrzucie poniżej nazwa grupy została zdefiniowana jako Konfiguracja zaś opis grupy to pełny dostęp. Po definicji wszystkich wymaganych opcji klikamy Submit.

Poprawność utworzenia grupy (bądź modyfikację opcji) możemy dokonać po wybraniu strzałki obok nazwy rodzica (All Groups).

Grupa Konfiguracja została utworzona. Czas by przypisać do grupy użytkowników. Konto użytkownika utworzymy po wybraniu gałęzi Users and Identity Stores/Internal Identity Stores/Users wybieramy Create.

Na kolejnym ekranie:

1 - ustalamy nazwę użytkownika,

2 - pole opis,

3 - za pomocą przycisku Select przypisujemy użytkownika do wcześniej utworzonej grupy Konfiguracja,

4 - ustalamy hasło.

Konto użytkownika jankow zostało utworzone i przypisane do grupy Konfiguracja.

Zanim przejdziemy do kolejnego etapu czyli do konfiguracji routera jeszcze jedna mała uwaga. Gdybyśmy chcieli utworzyć więcej grup użytkowników i każdej z grup przypisać różne uprawnienia należy stworzyć odpowiednie polisy. W naszym scenariuszu możemy ten krok pominąć gdyż domyślna polisa (a raczej brak zdefiniowania innych) powoduje uzyskanie pełnego dostępu.

Aby przypisać dane uprawnienia grupie i utworzyć nową polisę należy przejść do gałęzi Access Policies/Access Services/Default Device Admin/Authorization (utworzymy regułę dla grupy użytkowników Konfiguracja oraz grupy urządzeń Routery). W nowo otwartym oknie w polu Name wpisujemy nazwę reguły. Po zaznaczeniu opcji Identity Group i kliknięciu na Select wybieramy grupę Konfiguracja. Następnie zaznaczamy opcję NDG:Device Type i tak jak poprzednio po kliknięciu na Select wybieramy grupę Routery.

Adresaci reguły zostali ustaleni przechodzimy do określenia uprawnień. Aby określić uprawnienia wybieramy przycisk Select przy opcji Shell Profile. Domyślne utworzone są dwa profile - profil zezwalający na dostęp czyli PermitAccess oraz profil zabraniający dostępu - jak łatwo się domyślić - DenyAccess. My na tym etapie skorzystamy z własnego. Aby utworzyć nowy profil wybieramy Create.

Otworzy się kolejne okno. W zakładce General określamy nazwę tworzonego profilu. Zakładka Common Tasks odpowiedzialna jest za ustalenie uprawnień. Aby zdefiniowanym grupom przypisać maksymalne uprawnienia opcje Devault Privilege oraz Maximum Privilege zmieniamy na Static i przypisujemy opcji Value wartość 15. Zakładka ta pozwala na zdefiniowanie jeszcze kilku innych parametrów.

Po wprowadzeniu wszystkich danych wybieramy Submit.

Gdybyś czytelniku z jakiś powodów popełnił błędy podczas konfiguracji serwera ACS zawsze za pomocą polecenia: acs reset-config przywrócisz jego ustawienia początkowe (fabryczne).

Konfiguracja serwera ACS dobiegła końca czas by przetestować wprowadzone ustawienia, przechodzimy do konfiguracji routera.

Na samym wstępie wykonujemy konfigurację interfejsu routera - przypisujemy adres IP, maskę oraz włączamy interfejs.

Po konfiguracji interfejsu przeprowadzamy test łączności z serwerem ACS. Jak widać poniżej komunikacja obu urządzeń jest możliwa.

Kolejnym krokiem jest konfiguracja opcji związanych z serwerem TACACS. Konfiguracja ta jest bardzo podobna do tej opisanej w poprzednim wpisie dotyczącym konfiguracji serwera RADIUS.

1 - tworzymy konto użytkownika admin - konto jest zakładane lokalnie - na wypadek błędnie przeprowadzonej konfiguracji lub niedostępności serwera TACACS tak byśmy nie stracili możliwości zalogowania się,

2 - hasło do trybu uprzywilejowanego,

3 - włączenie modelu AAA,

4 - określenie adresu IP serwera TACACS,

5 - określenie wartości klucza,

6 - określenie domyślnej metody uwierzytelnienia, dodanie parametru: local-case powoduje rozróżnienie wielkości liter,

7 - określenie metody autoryzacji - pierwszeństwo ma serwer TACACS zaś w drugiej kolejności jest wykorzystywana baza lokalna.

Router został skonfigurowany. Czas by przeprowadzoną konfigurację przetestować - wykonujemy próbę logowania. Jak widać poniżej próba logowania użytkownika jankow przebiegła prawidłowo. Użytkownik jankow uzyskał dostęp do routera.

Dużą zaletą serwera ACS jest mnogość opcji monitoringu. Kontrolę poprawności logowania użytkownika jankow możemy również sprawdzić od strony serwera. Informacje stanu logów możesz przeglądać po wybraniu gałęzi Monitoring and Reports.

W przypadku konfiguracji serwera TACACS tak zresztą jak i RADIUS możliwe jest przypisanie kilku serwerów realizujących proces uwierzytelnienia.

Podczas definicji serwerów ważna jest kolejność ich wprowadzania, gdyż będzie to odzwierciedlać stan nawiązywanych połączeń. Jeśli pierwszy serwer o adresie IP 192.168.1.20 będzie niedostępny nastąpi próba komunikacji z serwerem o adresie IP 192.168.1.21 Tak więc kolejność definicji dostępnych serwerów możemy wykorzystać do kształtowania ruchu sieciowego tak by jeden z nich nie był nadmiernie obciążony.

CISCO przewidziało jeszcze jedną metodę definicji serwerów TACACS a mianowicie serwery te możemy łączyć w grupy. Poniżej przykład utworzenia takiej grupy serwerów.

Definicję grupy serwerów rozpoczynamy od utworzenia samej grupy. Grupę utworzymy za pomocą polecenia: aaa group server tacacs+ <nazwa_grupy> Kolejnym krokiem jest podanie adresów IP serwerów. Adresy definiujemy za pomocą komendy: server <adres_IP> W naszym przykładzie do grupy o nazwie GRUPA1 zostały dodane adresy trzech IP serwerów przy czym dodanie serwera o adresie 192.168.1.22 wygenerowało błąd. Stało się tak, gdyż adres IP tego serwera wcześniej nie został zdefiniowany za pomocą polecenia: tacacs-server host <adres_IP> key <hasło_klucza> Ostatnim krokiem jest zdefiniowanie metody uwierzytelnienia, która będzie odnosić się do utworzonej grupy - polecenie: aaa authentication login default group <nazwa_grupy>

Jeśli chcemy aby poszczególni użytkownicy mieli dostęp tylko do określonych komend należy skonfigurować autoryzacje poleceń. Autoryzację taką włączymy za pomocą komendy: aaa authorization commands 15 default group tacacs+ (cyfra 15 oznacza możliwość przeprowadzenia autoryzacji poleceń poziomu 15). Po wydaniu komendy każdorazowe wprowadzenie polecenia spowoduje przesłanie do serwera TACACS żądania, którego celem jest sprawdzenie czy dany użytkownik daną komendę może wykonać.

Poniżej przykład w którym użytkownikowi tadnow zostało odmówione wykonanie polecenia: configure terminal

Jeśli chcemy określić interfejs, który może komunikować się z serwerem TACACS należy użyć polecenia: ip tacacs source-inteface <nazwa interfejsu> Poniżej przykład w którym interfejs f0/0 routera R1 został wyznaczony jako ten, przez który będą wysyłane pakiety w kierunku serwera TACACS.

Domyślne ustawienia serwera pozwala na wykonanie 3 prób logowania aby zmienić wartość liczby prób logowania należy użyć polecenia: tacacs-server attempts <liczba_prób> Polecenie wydajemy w trybie konfiguracji globalnej.

Serwer TACACS umożliwia nam gromadzenie informacji o wprowadzanych komendach i poleceniach, które następnie są zapisywane w logach serwera. Możliwość ta jest bardzo przydatna gdyż pozwala nam na monitorowanie pracy osób odpowiedzialnych za konfigurację urządzeń sieciowych. Analiza logów da nam wiedzę kto i o jakiej porze wprowadził zmiany w konfiguracji urządzenia.

Aby uruchomić przechwytywanie wprowadzonych przez użytkownika poleceń należy wydać komendę: aaa accounting commands <poziom_poleceń> default stop-only group tacacs+ Poniżej na zrzucie zaprezentowano włączenie przechwytywania poleceń poziomu pierwszego i piętnastego.

Po wydaniu komend wszystkie polecenia wprowadzane przez użytkownika znajdą swoje odzwierciedlenie w dzienniku pracy serwera TACACS. Poniżej przedstawiono zrzut z dziennika serwera na którym widać iż użytkownik tadnow dokonał konfiguracji interfejsu f1/0 routera (zostały zapisane polecenia poziomu 15).

Ponieważ również skonfigurowaliśmy rejestrowanie wydania komend poziomu pierwszego to w logach pracy serwera te polecenia również odnajdziemy. Poniżej kolejny zrzut na którym widać iż użytkownik tadnow sprawdzał konfigurację interfejsów routera (polecenie: show ip interface brief).

Oprócz zapisu poleceń w dzienniku pracy serwera możemy gromadzić informacj o występujących zdarzeniach systemowych. Na rysunku poniżej została pokazana konfiguracja tej funkcji.

Rejestrację zdarzeń systemowych określamy za pomocą słów kluczowych: exec, connection oraz system.

exec - zapis informacji o zainicjowaniu i zakończeniu sesji,

connection - zapis informacji dotyczących wykonanych połączeń z urządzeniem z wykorzystaniem taklich protokołów jak Telnet czy SSH,

system - zapis informacji odnoszących się do zdarzeń związanych z pracą urządzenia np. restart.

Poniżej na zrzucie przykład rejestracji zdarzeń wskazujący na uzyskanie połączenia z urządzeniem.

Korzystanie z dedykowanych rozwiązań CISCO jest bardzo wygodne lecz niestety wiąże się to z dodatkowymi kosztami - A co zrobić w przypadku w którym nas na to np. nie stać a chcemy by w naszej sieci działał serwer TACACS? W takim przypadku musimy sięgnąć do oprogramowania firm trzecich a i najlepiej by oprogramowanie te było darmowe. Warunki te spełnia serwer TACACS.net TACACS+ Server. Narzędzie te dostępne jest pod adresem: http://tacacs.net/download.asp Tak naprawdę oprogramowanie te występuje w dwóch wersjach Basic oraz Advanced. Pierwszą z nich można pobrać po wypełnieniu formularza, druga zaś dostępna jest za opłatą.

Po pobraniu instalatora rozpoczynamy instalację serwera. Oprogramowanie działa pod kontrolą systemu Windows i wspierane są wersje od Windows XP do Windows 8 wraz z wersjami serwerowymi od Windows 2000 Workstation do Windows Server 2012.

Podczas instalacji przy wyborze komponentów zaznaczamy obie dostępne opcje: TACTTest test tool (narzędzia testujące działanie serwera) oraz TACACS+ Server (przeznaczenie tego komponentu chyba nie należy tłumaczyć).

Kolejną ważną decyzję jaką musimy podjąć to ustalenie hasła klucza, klucz oczywiście należy zapamiętać gdyż będzie potrzebny na dalszym etapie konfiguracji. Wartość klucza: tajnehaslo

Po zdefiniowaniu klucza następuje instalacja serwera TACACS.

Oprogramowanie zostało zainstalowane. Serwer po instalacji powinien oczekiwać na połączenia od klientów na porcie TCP 49. Aby sprawdzić stan usług sieciowych wykorzystamy wbudowane narzędzie netstat. Otwarte porty wraz z stanem i numerem PID usługi poznamy po wydaniu polecenia: netstat -afo | find "49" (wyniki polecenia netstat zostają przekazane do polecenia find celem wyświetlenia tylko tych usług w który występuje wartość 49).

Po wyświetleniu wyników wydanego polecenia odszukujemy w trybie NASŁUCHIWANIE usługę działającą na porcie TCP 49. PID odnalezionej usługi wynosi 2248. Aby poznać nazwę usługi należy wydać polecenie: tasklist /fi "pid eq 2248" Jak można się przekonać poniżej program działający na porcie TCP 49 to tacplus.exe Serwer TACACS działa i czeka na nawiązanie połączenia z klientem.

Po analizie danych otrzymanych w poprzednim kroku widać, że adres IP serwera został ustalony na 127.0.0.1 (localhost). Docelowy adres IP serwera TACACS powinien wynosić 192.168.1.20. Aby zmienić ten stan rzeczy musimy dokonać konfiguracji ustawień serwera. Ustawienie serwera zmieniamy poprzez edycję plików XML zawartych w folderze config dostępnych w lokalizacji %ALLUSERSPROFILE%\TACACS.net Aby zmienić adres IP serwera edytujemy plik tacplus.xml (edycja dostępna po odznaczeniu atrybutu tylko do odczytu).

Po otwarciu pliku odszukujemy zmienną LocalIP i domyślny adres IP 127.0.0.1 zamieniamy na 192.168.1.20

Aby serwer mógł zacząć pracować z nowymi ustawieniami należy go zatrzymać i ponownie uruchomić. Ponowny rozruch serwera TACACS dokonamy po wydaniu poleceń: net stop TACACS.net oraz net start TACACS.net

Rozruch serwera możemy również dokonać z poziomu okna Usługi.

Weryfikację zmiany ustawień serwera sprawdzimy za pomocą znanych już nam poleceń netstat oraz tasklist. Nastąpiła zmiana adresu IP z 127.0.0.1 na 192.168.1.20

Kolejnym krokiem jest utworzenie kont użytkowników mających prawo wykonie operacji logowania. Konfigurację kont przeprowadzamy poprzez edycję pliku authentication.xml Ustalenie danych uwierzytelniających dokonujemy za pomocą zmiennych Name oraz LoginPassword Na zrzucie poniżej zostały ustalone dwa konta użytkowników:

1 - użytkownik: tadnow hasło: Qwerty1!

2 - użytkownik: beatry hasło: P@ssw0rd

Jeżeli chcemy określić docelową grupę urządzeń, która ma prawo zestawiania połączeń z serwerem TACACS należy odpowiednie ustawienia określić w pliku clients.xml W pliku tym również możemy zmienić ustalone na etapie instalacji serwera hasło klucza.

Wprowadzanie zmian niesie ze sobą możliwość popełnienia pomyłki dlatego warto po dokonanych modyfikacjach dokonać testu składni edytowanych plików. Wraz z serwerem dostarczane jest narzędzie tacverify, które pozwoli nam na sprawdzenie składni plików. Sprawdzenie sprowadza się do wydania polecenia tacverify. Jak widać poniżej wszystko jest w porządku.

Kolejnym z narzędzi testujących jest tactest, program umożliwia nam przeprowadzenie próby połączenia. Po utworzeniu konta warto sprawdzić czy za pomocą skonfigurowanych poświadczeń uda się nam zestawić poprawne połączenie. Próba zakończona sukcesem oznacza, że serwer TACACS został poprawnie skonfigurowany i co najważniejsze, że działa. Testu połączenia dokonujemy za pomocą polecenia: tactest -s <sdres_IP_serwera> -u <nazwa_użytkownika> -k <hasło_klucza> -p <hasło_użytkownika> Poniżej wydanie polecenia: tactest -s 192.168.1.20 -u tadnow -k tajnehaslo -p Qwerty1! kończy się pełnym sukcesem. Przechodzimy do próby przeprowadzenia logowania na routerze.

Konfiguracja routera sprowadza się do wydania tych samych poleceń co w przypadku serwera ACS. Router został skonfigurowany spróbujmy zalogować się z poświadczeniami użytkownika tadnow. Jak można zaobserwować poniżej próba ta przebiegła poprawnie.

W przypadku wystąpienia problemów w katalogu Logs zapisane są logi serwera, ich analiza pozwoli na odpowiedzenie na pytanie - Co nie działa?

I to by było na tyle tematu konfiguracji uwierzytelnienia z wykorzystaniem serwera TACACS.

BIBLIOGRAFIA:

Co w sieci siedzi. Skanowanie portów.

2016-06-15T10:26:27+00:00

Wiemy już jak wykryć aktywnego hosta a więc przyszła pora by nabytą wiedzę poszerzyć. W artykule tym zajmiemy się skanowaniem lecz pójdziemy trochę dalej, naszym zadaniem będzie wykrycie i zidentyfikowanie usług sieciowych jakie na zdalnym hoście działają. Tak więc na tapetę bierzemy skanowanie portów.

Pozwól Czytelniku, że posłużę się o to taką analogią: W pierwszym kroku by móc przejść do skanowania portów należy wykryć czy dany host jest aktywny (czytaj włączony). Wykrycie takiego komputera jest jak znalezienie adresu domu. Gdy posiadamy adres domu możemy pójść dalej i poszukać sposobu dostania się do tego domu. Aby wejść do środka można skorzystać z drzwi frontowych ale również poszukać wejścia od tyłu czy przez garaż. Co bardziej kreatywni stwierdzą, że do środka można dostać się przez okno czy otwór przeznaczony dla zwierząt. Tak więc sam Czytelniku widzisz, że jest kilka dróg by osiągnąć zamierzony cel. W przypadku komputerów potencjalnymi sposobami uzyskania dostępu jest skorzystanie z otwartych portów a w znalezieniu wejścia pomoże nam skanowanie portów. Wyniki uzyskane dzięki przeprowadzonemu skanowaniu są potencjalnymi drzwiami przy wykorzystaniu, których wrota „domu” staną przed nami otworem. Tak więc port jest rodzajem „drzwi” przy pomocy, którego możemy uzyskać dostęp do komputera.

Tak więc proces skanowania sprowadza się do odnalezienia działających systemów a dodatkowo usług oferowanych przez te systemy.

Proces skanowania możemy podzielić na trzy odrębne fazy tj.:

określenie czy dany system zdalny działa,
skanowanie i wykrycie używanych portów,
skanowanie systemu pod kątem wykrycia luk, które to w późniejszej fazie można wykorzystać jako cel ataku.

Proces wykrycia działającego systemu jak już wspomniałem został omówiony więc tak by treści nie powtarzać odsyłam do wpisu - http://slow7.pl/item/110-co-w-sieci-siedzi-skanowanie-sieci-aktywne-hosty

Skanowanie i wykrycie otwartych portów sprowadza się do odnalezienie portu oraz identyfikacji usługi korzystającej z danego portu. Można to ująć w ten sposób: port to nic innego jak otwarte okno bądź furtka dzięki, której inny komputer bądź program może ustanowić połączenie, tak by mogła nastąpić wymiana danych. Porty posiadają swoje unikalne numery a dodatkowo dzięki zastosowaniu idei portów komputer może prowadzić wiele równoległych kanałów wymiany danych tak aby jeden proces nie musiał czekać na zakończenie innego. Dlatego równocześnie możemy wysyłać/odbierać pocztę, pobierać pliki czy słuchać ulubionego radia internetowego.

Niektóre z portów przyjęte są jako znane, oznacz to, że na portach tych działają określone usługi. Przykładem takiej usługi, która do swego działania wykorzystuje port o numerze 22 jest SSH. Usługa odpowiedzialna jest za nawiązanie bezpiecznych połączeń z hostem zdalnym. Każdy klient próbujący nawiązać ten typ połączenia wie, że aby móc skomunikować się z innym komputerem należy użyć docelowego portu 22, gdyż na tym porcie nasłuchuje serwer SSH. Kolejnym przykładem jest użycie przeglądarki internetowej. Nawiązując połączenie z daną stroną internetową, po podaniu adresu, przeglądarka próbuje ustanowić połączenie z serwerem WWW wykorzystując do tego zdalny port o numerze 80 gdyż na porcie tym serwer domyślnie oczekuje przychodzących połączeń. Na komputerze lokalnym zostaje otwarty losowy port, tak aby mógł być zestawiony pełny kanał komunikacyjny. Oczywiście można zmienić domyślny port pracy serwera WWW lecz wtedy celem nawiązania połączenia trzeba się do niego odwołać.

Numery portów reprezentowane są przez liczby naturalne z zakresu od 0 do 65535.

wartości od 0 do 1023 przyjęto jako ogólnie znane, (ang. well known ports),
zarejestrowane porty (ang. registered ports) to porty o numerach od 1024 do 49151 Porty te są przewidziane dla usług, które zwyczajowo korzystają z określonych portów,
porty przydzielane dynamicznie (ang. dynamically allocated ports, również ephemeral ports) to porty o numerach od 49152 do 65535.

Dodatkowo porty mogą być typu TCP bądź UDP (w zależności od użytego protokołu transportowego).

Przykładami innych usług, które korzystają ze standardowych numerów portów są te przedstawione poniżej:

DNS – 53 (TCP, UDP),
FTP – 20, przesyłanie danych (TCP),
FTP – 21, przesyłanie poleceń (TCP),
HTTP – 80, (TCP),
HTTPS – 443 (HTTP na SSL) (TCP),
IMAP – 143 (TCP),
POP3 – 110 (TCP),
SMTP – 25 (TCP),
Telnet – 23 (TCP).

Oczywiście nie jest to pełna lista lecz jej niewielki wycinek. Listę portów i wykorzystujące je usługi, znajdziesz tu: http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml

Skanowanie systemu pod kątem wykrycia luk ma za zadanie wykrycie i zidentyfikowanie wszelkich słabych punktów w usługach udostępnianych na określonych portach tak by mogły być one celem skutecznego ataku. Zagadnienie te w tym wpisie tylko „liźniemy” gdyż temat ten jest materiałem na kolejny artykuł.

Aby móc skutecznie wykorzystać skanowanie portów należy dokładnie zrozumieć działanie protokołów TCP oraz UDP (często niedocenianego) dlatego też zanim przejdziemy dalej winien jestem parę słów wprowadzenia.

Zaczniemy od protokołu TCP.

Głównymi zadaniami protokołu TCP jest stwierdzenie czy transmitowane dane są:

uszkodzone,
zagubione,
powielone,
dostarczone w nieodpowiedniej kolejności do odbiorcy.

Protokół TCP używany jest wszędzie tam gdzie musi być zachowana integralność przesyłanych danych, należy do tzw. protokołów niezawodnych. Aby została zapewniona niezawodność transmisji i by dane dotarły w nie zmienionej formie stosuje się następujące mechanizmy:

każdy wysłany pakiet danych TCP jest numerowany,
każdy pakiet TCP potwierdzający odbiór jest numerowany,
protokół wykorzystuje mechanizm pozytywnego potwierdzenia odbioru danych z retransmisją tzn. potwierdzany jest poprawny odbiór danych,
stosowany jest zegar mierzący czas oczekiwania na potwierdzenie odbioru.

Nagłówek protokołu TCP został przedstawiony poniżej.

Budowa nagłówka TCP rozpoczyna się od pól w których przechowywane są wartości portu źródłowego oraz portu docelowego. Wartości te w połączeniu z danymi zawartymi w nagłówku IP (adres IP źródłowy oraz adres docelowy) są podstawą identyfikacji połączenia.

Pola numer sekwencyjny oraz numer potwierdzenia zawierają wartości, które są niezbędne aby prowadzić skuteczną wymianę danych gdyż tylko w oparciu o numerowanie pakietów hosty prowadzące ze sobą komunikację wiedzą jakich pakietów mają się spodziewać, czy nadchodzą one w prawidłowej kolejności i czy przypadkiem, któryś z pakietów nie zaginął. Więcej informacji i użyciu tych pól już za chwilę.

Wartość w polu długość nagłówka zawiera informację o długości nagłówka.

W polu bity kodu znajduje się osiem jednobitowych pól (zwanych również flagmi), których włączenie bądź wyłączenie sygnalizuje z jakim typem nagłówka TCP mamy do czynienia. Co ważne włączenie jednego z pól nie wyklucza włączenia innych. Zastosowanie poszczególnych pól zaprezentowano poniżej (opis ten jest skrótowy, gdyż do tematu flag będziemy wracać nie raz):

CWR (ang. Congestion Window Reduced) - ustawienie flagi informuje o zmniejszeniu szybkości transmisji,
ECE (ang. ECN Echo) - informacja o przeciążeniu,
URG (ang. Urgent) - pilne dane (rzadko używane),
ACK (ang. Acknowledgement) - numer potwierdzenia,
PSH (ang. Push) - otrzymane dane maja być przekazane tak szybko jak to możliwe (nieużywane, gdyż sposób implementacji tej funkcji nie do końca spełnia niezawodność),
RST (ang. Reset) - zresetowanie połączenia na wskutek błędu,
SYN (ang. Synchronize) - flaga używana celem synchronizacji numerów ISN,
FIN (ang. Finished) - flaga używana przy kończeniu połączenia sygnalizująca koniec wysyłania danych.

W protokole TCP celem zapewnienia ciągłości komunikacji oraz optymalnej dla danego typu połączenia szybkości przesyłania danych zastosowano tzw. mechanizm przesuwnego okna pakietów (działanie tej funkcji wykracza poza ramy tego artykułu więc wybacz Czytelniku iż tematu nie rozwijam). Pole okno jest odpowiedzialne za ustawienie rozmiaru okna pakietów.

Pole suma kontrolna jest odpowiedzialne za wyliczenie wartości bazującej na danych zawartych w nagłówku TCP (acz nie tylko) a celem jest sprawdzenie czy dane podczas przesyłu nie uległy modyfikacji. Pole te jest wyliczane przez nadawcę a weryfikowane przez odbiorcę.

Pole wskaźnik ważności ma znaczenie tylko przy ustawionej fladze URG i odznacza dane, które mają być pilnie przekazane.

W nagłówku TCP mogą być definiowane różne parametry, których ustawienie ma wpływ na działanie protokołu TCP i tu również opis ich wszystkich stanowiłby zbyt dalekie zboczenie z tematu wpisu aczkolwiek opiszemy jedną. Najczęściej umieszczanym parametrem w polu opcje jest maksymalny rozmiar segmentu (tzw. MSS, ang. maximum segment size). Opcja ta odpowiedzialna jest za ustalenie rozmiaru największego segmentu jaki może zostać przesłany. Rozmiar segmentu ustalany jest podczas procesu nawiązywania połączenia.

Ostatnie pole zawiera dane, choć zdarzają się pakiety, które tych danych są pozbawione

Po omówieniu podstawowych parametrów protokołu TCP czas przejść do pokazania ich zastosowania.

Podczas nawiązywania połączenia pomiędzy dwoma urządzeniami i przy wykorzystaniu protokołu TCP w pierwszej kolejności musi nastąpić proces zestawienia połączenia (ang. Three-Way Handshake). Dopiero po dokonanym uzgodnieniu można przejść do właściwej wymiany informacji.

Cały proces negocjacji rozpoczyna się od wysłania na zdefiniowany adres IP i do określonego portu pakietu z ustawioną flagą SYN. Pakiet ten wysyła host nawiązujący połączenie. Jeśli host docelowy jest uruchomiony i usługa korzystająca z danego portu nasłuchuje na tym porcie w kierunku hosta ustanawiającego połączenie zostaje odesłany pakiet z ustawioną flagą SYN/ACK. Po otrzymaniu takiego pakietu w kierunku hosta z którym nawiązujemy połączenie zostaje wysłane potwierdzenie w postaci pakietu z włączoną flagą ACK.

Proces nawiązywania połączenia TCP przedstawia poniższy rysunek, komputer Host jest inicjującym połączenie z Serwerem.

Dociekliwy Czytelnik mógłby zadać pytanie - Ale jak to się dzieje, że komputer rozróżnia poszczególne sesje TCP, przecież w danej chwili może być nawiązanych kilka sesji? Rozróżnienie sesji TCP opiera się na wykorzystaniu numerów sekwencyjnych oraz numerów potwierdzenia. Numer sekwencyjny często jest określany jako ISN zaś numer potwierdzenia jako ACK.

Jak już wiesz Czytelniku aby sesja TCP mogła zostać nawiązana w pierwszej kolejności zostaje wysłany pakiet z ustawioną flagą SYN. Pakiet ten został pokazany na rysunku poniżej. Prześledzimy sesję nawiązaną pomiędzy hostem o adresie IP 192.168.1.140 a komputerem o adresie IP 192.168.1.205 na przykładzie ruchu przechwyconego za pomocą Wireshark-a.

Pakiet SYN (punkt 1) z hosta 192.168.1.140 (port 1074) zostaje wysłany w kierunku komputera 192.168.1.205 na port 80 (sesja WWW). Numer sekwencyjny został ustalony na 2831575758 (punkt 2). Numer sekwencyjny ISN jest losową liczbą z przedziału od 0 do 2^32-1.

Host 192.168.1.205 na otrzymany pakiet SYN odpowiada pakietem z ustawioną flagą SYN/ACK (punkt 4). Pakiet ten zostaje odesłany z źródłowego portu 80 na docelowy port 1074 w kierunku hosta 192.168.1.140 (punkt 1). Host w pakiecie SYN/ACK umieszcza swój własny numer sekwencyjny: 1854235621 (punkt 2) ale dodatkowo zostaje jeszcze umieszczony tzw. numer potwierdzenia Numer ten ma wartość o jeden większą niż numer sekwencyjny otrzymany w pakiecie SYN - 2831575759 (punkt 3).

Ostatnim pakietem jest pakiet ACK (punkt 4), który jest odpowiedzią hosta 192.168.1.140 na otrzymany pakiet SYN/ACK (punkt 1). W pakiecie tym numer sekwencyjny zostaje ustalony na wartość o jeden większą w stosunku do pierwszego pakietu, którym był pakiet SYN - 2831575759 (punkt 2) zaś numer potwierdzenia stanowi wartość o jeden większą niż wartość numeru sekwencyjnego otrzymanego od hosta192.168.1.205 w pakiecie SYN/ACT - 1854235622 (punkt 3).

Proces ustanowienia sesji TCP zakończył się sukcesem. Nasz schemat ustanawiania sesji TCP możemy wzbogacić o dodatkowe informacje.

Po tym etapie następuje transmisja danych, która również opiera się na przekazywaniu pomiędzy hostami pakietów z odpowiednimi wartościami numerów sekwencyjnych i numerów potwierdzenia.

Po przesłaniu wszystkich danych komunikacja musi się zakończyć. Zakończenie sesji może odbyć się na dwa sposoby. Jeden należy do sposobów „eleganckich” i polega na wykorzystaniu czterech pakietów wraz z ustawioną flagą FIN. Drugi zaś np. na skutek nieoczekiwanego błędu (wyłączenie hosta, błędna konfiguracja) wykorzystuje pakiety TCP z ustawioną flagą RST.

Użycie pierwszego ze sposobów rozpoczyna się od wysłania pakietu z ustawionymi flagami FIN i ACK (pakiet wysyła host chcący zakończyć sesję). Komputer do którego trafia pakiet odpowiada pakietem ACK a dodatkowo wysyła własny pakiet w którym ustawione są flagi FIN i ACK. Host inicjujący zamknięcie odpowiada pakietem ACK.

Poniżej na zrzucie pokazano zamknięcie sesji TCP przy wykorzystaniu pakietu FIN.

Host 192.168.1 .140 inicjuje zamknięcie w tym celu do komputera o adresie 192.168.1.205 zostaje wysłany pakiet FIN/ACK. Host 192.168.1.205 odpowiada dwoma pakietami – pakietem ACK oraz własnym pakietem FIN/ACK. Po otrzymaniu od hosta 192.168.1.205 pakietu FIN/ACK komputer 192.168.1 .140 potwierdza fakt zamknięcia sesji pakietem ACK.

Zwróć uwagę Czytelniku na wartości numerów sekwencyjnych i potwierdzenia. Jak można stwierdzić schemat numeracji opiera się na tej samej zasadzie jaka została wykorzystana w przypadku nawiązywania połączenia. Schematycznie proces został przedstawiony na rysunku poniżej.

Drugi ze sposobów jak zostało wspomniane wykorzystuje pakiet TCP z ustawioną flagą RST. Wysłanie takiego pakietu informuje hosta o zerwaniu połączenia bądź odmowie jego nawiązania.

Poniżej przedstawiono pakiet wysłany od hosta 192.168.1.140 kończącego sesję TCP na wskutek wystąpienia błędu. Pakiet ma ustawione flagi RST oraz ACK. Wysłanie pakietu kończy komunikację pomiędzy komputerami 192.168.1.140 a 192.168.1.205.

Podczas skanowania będziemy mieli do czynienia z jeszcze jednym protokołem a mianowicie z protokołem UDP (ang. User Datagram Protocol). Informacje o tym protokole znajdziesz w dalszej części wpisu gdy przejdziemy do przykładów użycia go podczas skanowania.

Wykrywanie systemu

Naszą przygodę ze skanowaniem portów rozpoczniemy od zaprezentowania sposobów wykrycia skanowanego systemu. Tak zwany fingerprinting systemu jest metodą, która pozwoli nam poznać wersję skanowanego systemu. Można by zapytać – Jakie korzyści z posiadania takiej informacji będziemy mieli? Otóż poznanie wersji systemu pomoże nam w doborze skutecznych technik skanowania. Dobór odpowiedniej metody skanowania w zależności od naszego celu (skanowanego systemu) będzie łatwiejszy i da bardziej wymierny efekt w zdobyciu poszukiwanych informacji. Mówiąc inaczej wybór danej metody skanowania zależny jest od wykrytego systemu operacyjnego, gdyż po co wykorzystać dany rodzaj skanu gdy z góry wiadomo, że w danym systemie on nie zadziała. Tak więc system operacyjny wymusza na nas zastosowanie określnych rozwiązań.

Identyfikacja systemu operacyjnego możliwa jest dzięki różnej interpretacji wytycznych zawartych w dokumentach RFC. Oznacza to, że dani producenci inaczej w swoich systemach operacyjnych implementują rozwiązania związane z obsługą protokołów IP, TCP czy UDP. Wychwycenie tych różnic (często bardzo subtelnych) umożliwia narzędziom wykorzystywanym do skanu zidentyfikowanie skanowanego systemu.

Poniżej przykład różnej implementacji początkowej wartości pola TTL w nagłówku IP oraz rozmiaru zastosowanego okna TCP. Porównanie tych informacji z dużym prawdopodobieństwem da nam odpowiedź o typie systemu operacyjnego.

System operacyjny	Początkowa wartość pola TTL	Rozmiar okna nagłówka TCP
Linux (kernel 2.4 and 2.6)	64	5840
FreeBSD	64	65535
Windows XP	128	65535
Windows 7, Vista and Server 2008	128	8192
Cisco Router (IOS 12.4)	255	4128

Inne typy analizowanych danych opierają się m.in. o:

Porównanie numerów ISN (ang. Initial Sequence Number) – wartość ISN jest wykorzystywana przy zestawianiu sesji TCP. Numer ten z reguły jest losowy lecz niektóre z systemów preferują bardziej lub mniej pewne wartości. Analiza wzorca numeru pozwala na określenie typu systemu.
Wykorzystanie pakietów TCP – celem weryfikacji systemu można wysłać w kierunku celu specjalnie spreparowane pakiety TCP. Pakiety te mają ustawione nietypowe flagi protokołu TCP, które nie są przewidziane w specyfikacji dokumentów RFC. Analizując otrzymaną odpowiedź można wykonać pewne założenia odnośnie systemu z którego zostały wysłane. Np. pakiet TCP z ustawioną flagą FIN jest wysyłany do otwartego portu, zgodnie z dokumentacją RFC odpowiedzią na tak otrzymaną informację powinien być brak odpowiedzi lecz systemy z rodziny Windows na odebrany pakiet odpowiadają pakietem z ustawioną flagą FIN/ACK.
Wykorzystanie komunikatów ICMP – podczas wystąpienia błędów protokołu ICMP, dane systemy w odpowiedziach odsyłają różną liczbę danych, analiza otrzymanych danych definiuje system z którego zostały wysłane.
Zastosowanie bitu „nie dziel na fragmenty” – bit ten jest wykorzystywany w komunikacji TCP celem zwiększenia wydajności, lecz nie jest on stosowany przez wszystkie systemy operacyjne, weryfikacja bitu pozwala zawęzić liczbę systemów operacyjnych,
Zaawansowane opcje protokołu TCP – protokół TCP w różnych odstępach czasu podlegał modyfikacjom i usprawnieniom, implementacja i ocena przyjętych rozwiązań (np. maksymalna wielkość segmentu, blok niewykonywalny czy współczynnik skalowania okna) pozwala na wytypowanie systemu zdalnego.

Przedstawione i opisane mechanizmy oczywiście nie wyczerpują tematu identyfikacji używanego systemu operacyjnego lecz mają za zadanie ukazanie jak wiele metod może zostać użytych aby mieć pewność iż cel ataku zostanie poprawnie rozpoznany.

Pierwszym z narzędzi jakie chciałbym zaprezentować jest już wcześniej opisywany Nmap. Ten wszechstronny program nie tylko pozwala nam na odkrycie aktywnych hostów ale również przy wykorzystaniu pełni jego możliwości możemy wykonać proces identyfikacji systemu operacyjnego oraz proces skanowania portów (w wpisie tym często a nawet bardzo często będziemy z tego narzędzia korzystać).

Aby zidentyfikować system zdalny należy posłużyć się poleceniem: nmap -O <adres_hosta> Po wydaniu komendy uzyskamy informację o systemie operacyjnym – polecenie przyjmie postać: nmap -O 192.168.1.140. Jak widać poniżej system zdalny został określony jako Windows 2000 bądź Windows XP. Oprócz identyfikacji systemu uzyskamy również informację o otwartych portach – 139, 445, 3389

Otrzymane wyniki potwierdzają, że mamy do czynienia z systemem Windows ponieważ oprócz występujących sprzeczności w implementacji protokołów, identyfikację systemu możemy także oprzeć o analizę aktywnych numerów portów. Gdyż w systemach operacyjnych wykorzystywane porty stale się powtarzają. Wykryte porty 139, 445 a w szczególności 3389 są przynależne systemowi Windows. W przypadku systemu Linux będziemy mieli do czynienia z innym zestawem charakterystycznych dla tego systemu wartości numerów portów.

Spróbujmy wykonać skan na innym systemie operacyjnym.

Tym razem po wydaniu polecenia uzyskujemy informację, że mamy do czynienia z systemem Windows 7, Windows 8, Windows Vista bądź Windows 2008.

No to kolejny przykład, tym razem system został określony jednoznacznie jako Windows 10.

I ostatni przykład. Tym razem skanowany system zdalny został określony jako Linux w wersji 2.6.X (gdzie X od 9 do 33).

Dokładniejsze wyniki uzyskamy jeśli skorzystamy z funkcji włączenia detekcji OS i wersji usług. Aby wykonać tę operację należy wydać polecenie: nmap -A <adres_hosta> Poniżej przykład w którym względem hosta 192.168.1.140 ponownie zostaje wydane polecenie celem identyfikacji systemu operacyjnego. Przy wykorzystaniu opcji -O system został określony jako Windows 2000 bądź Windows XP zaś przy wykorzystaniu flagi -A system został zawężony do Windows XP z zainstalowanym SP3 (co w 100% jest prawdą).

Wydanie komendy detekcji systemu i usług względem komputera 192.168.1.205 (informacje uzyskane dzięki wcześniejszemu skanowaniu to: Windows 7, Windows 8, Windows Vista bądź Windows 2008) również zawęża dane – wykryty system to Windows 7 (poznajemy również dokładną wersję systemu). Dodatkowo oprócz poznania wersji systemu Windows nasza wiedza o skanowanym hoście zostaje poszerzona m.in. o: nazwę komputera, tryb pracy sieciowej (domena, grupa robocza) czy informację o sposobie logowania. Zaprezentowane poniżej wyniki zostały zawężone do informacji dotyczących wersji systemu.

Użycie detekcji systemu odnośnie hosta 192.168.1.200 dostarcza nam szeregu informacji o typie usług działających na określonych portach (wyniki zostały zawężone).

Mechanizm wykrywania systemu zdalnego wykorzystywany przez narzędzie Nmap opiera się na wysyłaniu do badanego systemu odpowiednio przygotowanych żądań i analizie uzyskanych odpowiedzi. Do analizy uzyskanych odpowiedzi jest wykorzystywana baza sygnatur. Baza sygnatur programu Nmap jest przechowywana w pliku nmap-os-db bądź nmap-os-fingerprints.

Na podobnej zasadzie analizę systemu operacyjnego będą przeprowadzały narzędzia omówione w dalszej części wpisu. Pierwszym (oprócz Nmap-a) narzędziem, które chciałbym przedstawić jest xProbe2.

Aby za pomocą tego programu określić system zdalny należy posłużyć się poleceniem: xprobe2 <adres_hosta>

Narzędzie wykorzystamy odnośnie znanego nam już hosta 192.168.1.140 Sprawdźmy zatem czy wyniki uzyskane dzięki xProbe2 pokrywają się z wynikami uzyskanymi dzięki użyciu Nmap-a.

Wydanie komendy identyfikującej system określa, że mamy do czynienia z systemem Mac OS bądź z produktami firmy HP.

Uzyskany wynik całkowicie nie pokrywa się z danymi jakie uzyskaliśmy po uruchomieniu Nmap-a. Taki stan rzeczy jest spowodowany faktem iż narzędzie te już od dość dłuższego czasu nie jest rozwijane.

By uściślić wyniki otrzymane w poprzednim kroku spróbujmy użyć narzędzia xProbe2 w odniesieniu do zdefiniowanego portu. Aby narzędzie xProbe2 wykryło system zdalny poprzez analizę danych otrzymanych z określonego portu należy w definicji polecenia użyć przełącznika -T <numer_portu>.

Przypuśćmy, że podejrzewamy iż skanowany system będzie należał do systemów z rodziny Windows. Dlatego też doskonałym wyborem sprawdzanego numeru portu będzie port o numerze 3389 (port odpowiedzialny za realizację połączeń Pulpitu zdalnego - rozwiązanie stosowane tylko w systemie Windows). Zatem polecenie przyjmie postać: xprobe2 192.168.1.140 -T3389

Jak widać poniżej analizowany system zdalny zostaje określony jako Windows.

Wyniki uzyskane dzięki narzędziu xProbe2 względem hosta o adresie IP 192.168.1.200 identyfikują system jako Linux w wersji 2.6.X (podobnie jak Nmap).

Oba zaprezentowane do tej pory narzędzia opierały się na tzw. aktywnym fingerprintigu stosu czyli wersja systemu zdalnego została ustalona dzięki przesłaniu w kierunku celu specjalnie przygotowanych pakietów. Analiza otrzymanych odpowiedzi wraz z ich porównaniem z bazą sygnatur pozwala odpowiedzieć na pytanie z jakim systemem mamy do czynienia.

Przeciwieństwem metody aktywnej jest pasywne zdobycie informacji o typie zainstalowanego systemu. Metoda ta charakteryzuje się brakiem jakiejkolwiek interakcji z badanym hostem. Określenie systemu zdalnego odbywa się tylko na podstawie analizy pakietów pojawiających się w sieci. Metoda ta nie jest tak precyzyjna jak aktywna lecz zastosowanie jej eliminuje szanse wykrycia wykonywanego skanu.

Jednym z narzędzi jakie możemy wykorzystać przy pasywnym określaniu systemu jest program p0f.

Użycie narzędzia sprowadza się tylko do wydania polecenia: p0f Po uruchomieniu programu, narzędzie rozpoczyna analizę otrzymywanych pakietów. Aby metoda pasywna zdała egzamin należy zadbać o odpowiednią ilość danych do analizy. Dane te możemy dostarczyć np. poprzez wykonanie ataku MITM (ang. Man in the middle – atak polegający na podsłuchu a czasem modyfikacji wiadomości przesyłanych pomiędzy dwiema stronami bez ich wiedzy), fizycznym zainstalowaniu TAP-a sieciowego (urządzenie odpowiedzialne za klonowanie sygnału sieciowego i przesłanie go do atakującego, możliwe jest użycie zwykłego HUB-a lecz wtedy obniżymy przepustowość łącza do 10Mb/s i dodatkowo dochodzi problem z kolizją pakietów) czy wykorzystaniem portu lustrzanego (opcja kopiowania pakietów odbieranych/wysyłanych przez określony port przełącznika do innego portu).

Poniżej na zrzucie efekt użycia narzędzia p0f (aplikacja dostępna w systemie Linux). Po uruchomieniu programu zostały wykryte dwa systemy zdalne – host o adresie 192.168.1.30 korzysta z systemu Linux 3.11 lub nowszego natomiast host 192.168.1.140 to system Windows.

Podobnym programem potrafiącym określić system zdalny poprzez pasywną analizę pakietów jest NetworkMiner. NetworkMiner to tzw. sniffer czyli narzędzie służące do przechwytywania pakietów pojawiających się w sieci. Aplikacja potrafi je analizować i na tej podstawie definiować typ systemu (program ma więcej możliwości m.in. potrafi określić otwarte porty, przechwycić pojawiające się pliki czy dane uwierzytelniające - nazwy użytkowników oraz hasła). Aplikacja do działania wykorzystuje graficzny interfejs użytkownika i dla odmiany jest dostępna w systemie Windows.

Poniżej na rysunku zaprezentowano efekt pracy programu. Po krótkiej chwili od uruchomienia, narzędzie identyfikuje host 192.168.1.140 jako Windows (co jak wiemy po efektach pracy innych narzędzi jest wynikiem prawidłowym).

Aplikację NetworkMiner prócz systemu Windows możemy również uruchomić w systemach Linux, MacOS czy FreeBSD - strona programu: http://www.netresec.com/?page=NetworkMiner

Skanowanie portów

Teraz jak już wiemy jak zidentyfikować system operacyjny zdalnego hosta możemy przejść do omówienia metod wykorzystywanych w procesie skanowania portów.

Rozpoczniemy od podstawowej operacji jaką jest skanowanie TCP. Ten rodzaj skanu należy do najczęściej wykorzystywanych metod. Skanowanie te w pierwszej kolejności wykonamy przy użyciu Nmap-a. Nmap przeprowadza proces pełnego nawiązania połączenia a następnie zamyka połączenie. Proces ten wykonywany jest odnośnie każdego portu.

Skanowanie inicjujemy poprzez wydanie polecenia: nmap -sT <adres_IP> Wydanie komendy spowoduje wykonanie skanowania TCP (opcja -sT – opcja -s wskazuje na typ skanowania natomiast -T oznacza skanowanie TCP) hosta o zdefiniowanym adresie IP. Skan wielu hostów przeprowadzamy poprzez definicję początkowego i ostatniego adresu IP np. nmap -sT 192.168.0.1-254 bądź opcjonalnie gdy skanowana jest cała podsieć korzystamy z notacji CIDR (definicja adresu sieci i długości maski) - nmap -sT 192.168.0.1/24 Podczas definicji adresów IP hostów, które będą podlegać skanowaniu możemy za pomocą opcji: --exclude <adres_IP> wykluczyć komputery - hosty zdalne o zdefiniowanych adresach IP nie będą skanowane. Użycie np. takiej komendy: nmap 192.168.0.0/24 --exclude 192.168.0.10,192.168.0.24 spowoduje przeskanowanie wszystkich hostów należących do podsieci 192.168.0.0/24 za wyjątkiem adresów IP: 192.168.0.10 oraz 192.168.0.24

Jak widać powyżej udało nam się przeskanować hosta o adresie IP 192.168.1.110 i wykryć na tym hoście otwarte porty. Czas skanowania wyniósł niecałe 5 sekund. Niestety nie jest to komplet informacji gdyż zostało przeskanowanych tylko tysiąc najczęściej używanych portów.

Aby wykonać pełne skanowanie wszystkich portów należy do polecenia dodać parametr: -p-

Możliwe jest przeprowadzenie skanowania wybranego portu bądź zakresu portów. Aby wykonać skanowanie jednego portu po fladze -p należy zdefiniować docelowy port bądź grupę portów. Jeżeli zaś chcemy wykonać skan określonych, niekolejnych portów to ich numery oddzielone przecinkami podajemy również po opcji -p. Zakres portów definiujemy za pomocą znaku: - podając pierwszy i ostatni numer portu.

Na zrzucie poniżej ukazano kilka przykładów użycia flagi -p.

1 - skanowanie TCP pojedynczego portu 3389,

2 - skanowanie TCP portu 3389 oraz 139,

3 - skanowanie TCP zakresu portów - od 100 do 200.

Do tej pory skanowaniu podlegały tylko porty korzystające z protokołu TCP, a jak już Czytelniku wiesz (lecz temat nie został jeszcze dokładnie omówiony) prócz protokołu TCP istnieje również UDP. Trochę może wyprzedzam temat lecz to co chciałbym pokazać to to, iż przy wykorzystaniu flagi -p (z dodatkowymi opcjami) można definiować różne metody skanu, które będą stosowane względem określonych portów.

Na zrzucie poniżej za pomocą komendy: nmap -sU -sT -p U:53,11,137,T:3389 192.168.1.205 zostało uruchomione skanowanie określonych numerów portów lecz co ważne w procesie tym do skanowania wykorzystywany jest zarówno protokół UDP jaki i TCP.

Wytłumaczmy zatem wydane polecenie:

opcja -sU - włącza skanowanie UDP,
opcja -sT - włącza skanowanie TCP,
flaga -p wraz z opcjami U:53,11,137,T:3389 definiuje skanowane porty, przy czym port 53, 11 oraz 137 skanowany jest przy wykorzystaniu protokołu UDP (wykorzystanie parametru U) zaś port 3389 podlega skanowaniu z wykorzystaniem TCP (wykorzystanie parametru T).

Opcją, którą bardzo często wykorzystuje się przy skanowaniu jest flaga -PN. Należy mieć na uwadze, że w procesie odkrywania aktywnych hostów może zdarzyć się sytuacja w której host zdalny będzie włączony lecz nasze skanowanie faktu tego nie potwierdzi. Użycie opcji -PN nakazuje Nmap-owi wykonanie skanowania portów tak jakby host był włączony i aktywny. Np wydanie polecenia: nmap -sT -p- -PN 192.168.1.1-10 spowoduje wykonanie skanowania TCP hostów od adresu IP 192.168.1.1 do 192.168.1.10 tak jakby hosty te były aktywne a dodatkowo proces skanowania obejmie wszystkie porty. Pominięty jest proces wykrywania aktywnych hostów.

A co w sytuacji w której musimy wykonać proces wykrywania aktywnych portów dla hostów, których adres IP nie są ułożone kolejno? Dobrym rozwiązaniem tego problemu jest umieszczenie adresów IP w osobnym pliku tekstowym (jeden adres IP na wiersz pliku) i zaimportowanie tak przygotowanej listy do narzędzi Nmap. Import dokonujemy przy wykorzystaniu opcji: -iL <ścieżka_do_pliku>.

Poniżej pokazano przykład wykonania skanu wszystkich portów dwóch komputerów, których adresy IP zostały zapisane w pliku tekstowym: nmapscan.txt. Skanowanie zostało wywołane za pomocą komendy: nmap -sT -p- -iL nmapscan.txt

Pliku tekstowego z zdefiniowanymi adresami IP możemy także użyć do określenia adresów IP hostów, które nie będą podlegały skanowaniu. Wydanie komendy: nmap -iL nmapscan.txt --excludefile nieskanuj.txt spowoduje wykonie skanowania hostów których adresy IP zostały zapisane w pliku nmapscan.txt za wyjątkiem tych określonych w pliku nieskanuj.txt

Zatrzymajmy się jeszcze chwilę nad powyższym zrzutem. Analizując listę otwartych portów na hoście 192.168.1.205 można zauważyć iż część działających usług nie została rozpoznana (porty z zakresu od 49152 do 49157 oraz 49166). Nmap oprócz skanowania portów potrafi również przeprowadzić operację skanowania wersji usług. Skanowanie te polega na wysłaniu w kierunku badanego hosta próbek, których zadaniem jest bardziej dokładne zidentyfikowanie usługi działającej na określonym porcie. Wywołanie skanowania wersji wywołujemy za pomocą flagi: -sV

Poniżej przedstawiono użycie opcji -sV odnośnie niezidentyfikowanych portów hosta 192.168.1.205 a ponieważ skan ujawnił otwarty port 80 dodatkowo został przeprowadzony skan tego portu w celu uzyskania bardziej szczegółowych informacji na temat działającego serwera www. Komenda uruchamiająca proces skanowania wersji przybierze postać: nmap -sV -p49152-49157,80,49166 192.168.1.205

Analizując informacje uzyskane po wydaniu polecenia dochodzimy do wniosku iż na portach tych działają usługi systemu Windows. Zaś serwer WWW został zidentyfikowany jako IIS w wersji 7.5. Co odpowiada stanu faktycznemu. Poniżej zrzut z skanowanego hosta.

Jak widać Nmap potrafi być naprawdę skuteczny.

Dodatkowo za pomocą parametru --version-intensity <level> możemy zdefiniować stopień - nazwijmy to agresywności przeprowadzanego testu. Poziom testu ustalamy w zakresie od 0 do 9 (0 - test łagodny, 9 - test brutalny). Aby wykonać test z ustalonym poziomem na 9 można opcjonalnie posłużyć się parametrem: --version-all

Zdefiniowanie parametru --version-trace spowoduje uruchomienie procesu debugowania przeprowadzanego skanu a tym samym uzyskamy wgląd w wykonywane operacje i trwające etapy uruchomionego procesu.

Prócz tradycyjnego skanowania TCP Nmap umożliwi nam przeprowadzenia tak zwanego skanowania SYN. Czym ta metoda różni się od poprzedniej? Otóż jak już wiesz skanowanie TCP nawiązuje pełną sesję z badanym hostem. Proces skanowania obejmuje pełne ustanowienie połączenia. Do przeprowadzenia skanowania SYN wykorzystywane są tylko dwa pierwsze etapy nawiązywania połączenia TCP. Oznacza to, że komputer atakujący wysyła standardowy pakiet SYN, na który uzyskuje odpowiedź w postaci pakietu SYN/ACK. Kolejnym krokiem powinno być odesłanie przez komputer wykonujący skanowanie pakietu ACK. Tak się jednak nie dzieje. Zamiast pakietu ACK zostaje wysłany pakiet RST (tzw. pakiet zerowania). Pakiet ten nakazuje zignorowanie wcześniej przesłanych informacji i zamknięcie połączenia.

Ten typ skanowania w literaturze bardzo często określany jest skanowaniem typu stealth. Skojarzenie z niewykrywalnymi samolotami jest jak najbardziej na miejscu. Gdyż tak jak samolot dla radarów pozostaje niewykrywalny tak ten typ skanowania może pozostać niezauważony dla narzędzi, których zadaniem jest monitorowanie ruchu sieciowego. Niewykrywalność tej metody bazuje na fakcie iż połączenie pomiędzy hostem atakującym a celem ataku nigdy w 100% nie zostaje nawiązane.

Tak więc aby zilustrować ten proces spójrz na poniższy rysunek przedstawiający schematycznie przebieg skanowania SYN.

Już po opisie tej metody można wysunąć wniosek, iż ten rodzaj skanowania przebiega szybciej niż tradycyjne wyliczanie portów TCP. Szybkość skanowania wynika z mniejszej liczby przesłanych pakietów.

Aby przeprowadzić skanowanie SYN w definicji polecenia należy użyć flagi: -sS Tak naprawdę dodanie w linii poleceń flagi -sS jest zbędne gdyż domyślnie wykonywanym przez Nmap-a skanowaniem jest skanowanie TCP stealth.

Poniżej przykład wykonania skanu SYN wszystkich portów hosta o adresie IP 192.168.1.205, polecenie przybrało postać: nmap -sS -p- 192.168.1.205

Czas skanowania wyniósł 24,23s Aby nie być gołosłownym odnośnie czasu wykonywania skanu poniżej przedstawiam zrzut z wykonanego wyliczania portów tego samego hosta lecz z wykorzystaniem metody TCP.

Porównując czas obu skanów wyraźnie widać iż skanowanie SYN przebiega znacznie szybciej (o ponad 20 sekund) a różnic w uzyskanych wynikach nie widać. Może Ci się to Czytelniku wydać mało istotne ale wykonując skan całej podsieci o masce /24 różnica w czasie skanowania będzie już znaczna.

Innym narzędziem jakie możemy użyć do przeprowadzenia skanowania SYN jest aplikacja hping3. W poprzednim wpisie narzędzia tego używaliśmy do wykrycia aktywnych hostów zaś w tym pokarzę jak program wykorzystać do skanowania portów.

Aby za pomocą hping3 wykonać proces skanowania należy posłużyć się poleceniem: hping3 <adres_IP_celu> --scan <skanowane_porty> -S Poniżej przedstawiono proces skanowania hosta o adresie IP 192.168.1.200, skanowaniu podlegają wszystkie porty.

Po wydaniu polecenia uzyskujemy listę otwartych portów. Działanie programu polega na wysłaniu na wskazane porty pakietu TCP z ustawioną flagą SYN (za wysłanie tego typu pakietu odpowiada flaga: -S). Zgodnie z zasadą ustanawiania sesji TCP otwarty i aktywny port na otrzymany pakiet SYN odpowiada pakietem SYN/ACK (na zrzucie powyżej lista wszystkich portów, które na otrzymane żądanie odpowiedziały - jak widać odpowiedzią są pakiety SYN/ACK - kolumna flags).

Aby zdefiniować listę określonych portów ich numery wymieniamy w linii poleceń oddzielając je od siebie przecinkami. Zakres portów definiujemy za pomocą myślnika (np. --scan 200-300).

Narzędzie hping3 czasem nie wyświetla wszystkich informacji dlatego warto w linii poleceń użyć dodatkowej opcji: -v

Skanowanie UDP

Warstwa czwarta modelu ISO/OSI to nie tylko protokół TCP ale również protokół UDP. Często protokół ten w procesie wykrywania aktywnych portów jest pomijany i lekceważony. A nie wolno zapomnieć iż otwarte porty UDP i usługi działające na tych portach w późniejszej fazie np. przeprowadzanego testu penetracyjnego mogą stanowić wektor ataku.

Aby za pomocą narzędzia Nmap przeprowadzić proces skanowania portów UDP w składni polecenia należy użyć flagi: -sU

Połączenie realizowane poprzez protokół UDP należy do tzw. połączeń bezpołączeniowych oznacza to, że pomiędzy nadawcą a odbiorcą w żaden sposób nie jest zestawiany kanał komunikacyjny, który umożliwiłby w jakikolwiek weryfikację czy pakiety wysłane od adresata trafią do nadawcy. Brak jest również jakiegokolwiek mechanizmu zapewniającego ponowną retransmisje uszkodzonych bądź zagubionych pakietów. Komunikacje poprzez protokół UDP możemy porównać do sytuacji w której wrzucamy zaadresowany list do skrzynki pocztowej z nadzieją, że szczęśliwie dotrze do odbiorcy. W większości przypadków tak się oczywiście dzieje ale są sytuacje w których na skutek nieprzewidzianych okoliczności nasz list zaginie.

Protokół UDP nie ma zaimplementowanych funkcji: kontroli kolejności wiadomości, eliminowania duplikatów, korekcji błędów czy sterowania przepływem. Jedynym z ważnych mechanizmów wspieranych przez ten protokół jest detekcja błędów. Detekcja ta opiera się na wyliczaniu sum kontrolnych, które są dodawane i analizowane przez nadawcę i adresata (suma jest obliczana po stronie nadawcy a weryfikuje ją adresat). Brak wielu ważnych i wymienionych funkcji sugerowałby iż stosowanie tego protokołu jest bezzasadne. Nie do końca stwierdzenie te jest prawdą, gdyż wielką zaletą protokołu UDP jest jego prostota a co za tym idzie niewielki narzut danych generowanych przez sam protokół. Dodatkowo łatwiej przy pomocy protokołu UDP zrealizować proces transmisji danych opartych o multiemisję.

Skanowanie przy wykorzystaniu protokołu UDP jest utrudnione gdyż należy mieć na uwadze fakt iż ze względu na naturę działania protokołu, nadawcy rzadko są udzielane odpowiedzi. Nmap tak samo jak w przypadku skanowania z użyciem protokołu TCP wysyła pakiety UDP do wybranych portów, zawartość pakietu zmienia się w zależności od numeru skanowanego portu. Po wysłaniu pakietu Nmap czeka na odpowiedź, jeśli taka odpowiedź nadejdzie port przyjmie status: open. Port zamknięty jest określany na podstawie komunikatu ICMP Port Unreachable. W przypadku skanowania UDP może wystąpić jeszcze trzecia sytuacja a mianowicie stan portu może zostać zdefiniowany jako: open|filtered Dlatego też w wynikach skanu UDP port często będzie przyjmować ten stan. Status open|filtered przyjmie port, który nie udzieli żadnej odpowiedzi. Brak odpowiedzi może być spowodowany filtrowaniem pakietów przez zaporę sieciową bądź winne może być oprogramowanie, które na zapytania wysłane przez Nmap-a nie odpowiada.

To co jeszcze należy dopowiedzieć odnośnie wykonywania wyliczania portów przy wykorzystaniu protokołu UDP to to iż skanowanie to jest czasochłonne. Przeprowadzenie skanu domyślnych tysiąca portów potrafi zająć około 15 minut i więcej. W przykładzie powyżej, czas skanu wyniósł 15 minut.

Aby uzyskać dokładniejsze wyniki można nakazać narzędziu zastosowanie wspomnianej już funkcji wykrywania wersji. Uaktywnienie funkcji spowoduje wysłanie do wszystkich skanowanych portów dodatkowych pakietów (próbek), których celem jest dokładniejsza identyfikacja działających usług. Jak pewnie pamiętasz nakazanie Nmap-owi włączenie funkcji wykrywania wersji odbywa się poprzez zastosowanie przełącznika:-sV a skanowanie UDP wymaga użycia flagi: -sU dlatego też całość opcji możemy połączyć w jeden ciąg i użyć parametru: -sUV

Kolejnym narzędziem za pomocą, którego przeprowadzimy skanowanie UDP jest Metasploit a tak naprawdę należy użyć jeden z modułów zawarty w tym narzędziu - udp_sweep.

Aby móc uruchomić moduł w pierwszej kolejności za pomocą polecenia: msfconsole uruchamiamy linie poleceń narzędzia Metasploit.

Aby móc uruchomić moduł skanujący w linii poleceń wydajemy polecenie: use wraz z ścieżką do modułu. Aby uruchomić moduł udp_sweep wydaj komendę: use auxiliary/scanner/discovery/udp_sweep (punkt 1).

Po uruchomieniu modułu za pomocą komendy: set RHOSTS <adres_IP> ustalamy adres zdalnego hosta - cel ataku (punkt 2). Aby zdefiniować większą liczbę celów należy określić pierwszy i ostatni adres IP, adresy oddzielone są od siebie myślnikiem (np. set RHOSTS 192.168.1.200-210), skanowanie podsieci definiujemy z wykorzystaniem notacji CIDR (np. set RHOSTS 192.168.1.200/24),

Kolejne polecenie: set THREADS <wartość> odpowiedzialne jest za ustalenie liczby uruchomionych wątków modułu. Im wyższa wartość skanowanie będzie przebiegało szybciej - bardziej agresywnie. Gdy naszym priorytetem jest pozostanie nie zauważonym ustalenie niskiej wartości parametru THREADS spowoduje przeprowadzenie skanowania z mniejszą szybkością co zwiększa nasze szanse na pozostanie niezauważonym (punkt 3).

Aby sprawdzić konfigurowane opcje należy posłużyć się poleceniem: show options (punkt 4). Jak widać poniżej definiowane parametry zostały wprowadzone.

Uruchomienie skanowania UDP rozpoczynamy po wydaniu komendy: run (punkt 5).

Wyniki skanowania zostaną zaprezentowane po zakończeniu procesu.

Skanowanie Xmas

Ten rodzaj skanowania swoją nazwę Xmas przyjął od analogi związanej z świecącą choinką gdyż do jego przeprowadzenia jest używany pakiet TCP, który ma włączone flagi URG, PSH i FIN natomiast brak jest włączenia flagi SYN lub ACK. Jest to nietypowy rodzaj pakietu, którego specyfikacja zawarta w dokumentach RFC nie obejmuje. Zastosowanie tak spreparowanego pakietu TCP odnośnie skanowanego systemu spowoduje wymuszenie nietypowych odpowiedzi. Ponieważ odpowiedzi te w różnych systemach przyjmą inny kształt to analiza ich może dać informację o stanie aktywnych portów. Producenci oprogramowania z powodu braku dokładnych wytycznych w dokumentach RFC wdrożyli swoje własne autorskie rozwiązania.

Poniżej przedstawiono pakiet Xmas przechwycony podczas wykonywania skanu. Jak można zauważyć i tak jak to zostało opisane powyżej pakiet ten ma ustawione flagi URG, PSH i FIN.

Aby przeprowadzić skanowanie Xmas należy w linii poleceń narzędzia Nmap użyć flagi: -sX Jak można zaobserwować poniżej użycie tego typu skanu względem systemu Windows (a dokładniej Windows 7) nie przyniosło nam żadnych wymiernych efektów. Skanowanie Xmas odnośnie systemu Windows jest nieskuteczne (dlatego warto przed zastosowaniem danego typu skanu znać wersję systemu odnośnie którego będzie przeprowadzane badanie).

Sprawdźmy zatem jaki efekt uzyskamy gdy celem będzie system Linux. Po przeprowadzeniu skanu jedyną informację jaką uzyskujemy to to iż w badanym systemie dostępnych jest 30 portów o statusie open|filtered.

Aby uzyskać bardziej dokładne informacje o wykrytych portach należy użyć znanej nam opcji -sV. Po wydaniu komendy uzyskamy bardziej szczegółowe informacje.

Skanowanie NULL

Ten typ skanu podobnie jak Xmas wykorzystuje pakiet TCP, który jest niezgodny z specyfikacją zawartą w dokumentach RFC. W przypadku tej metody używany jest pakiet, który ma wyłączone wszystkie flagi (stąd nazwa skanowania).

Poniżej tak jak w przypadku metody Xmas został przedstawiony przechwycony pakiet Null. Wszystkie flagi pakietu TCP zostały wyłączone.

Aby użyć tej metody należy w linii poleceń zdefiniować opcję -sV. Podobnie jak w poprzednim przypadku w pierwszej kolejności skanowanie zostało użyte wobec systemu Windows 7. Zastosowana metoda nie wykryła żadnych otwartych portów. Tak jak w przypadku metody Xmas, skan przy wykorzystaniu pakietów Null gdy celem jest system Windows jest nieskuteczny.

Sprawdźmy zatem co osiągniemy w przypadku systemu Linux. Skan Null systemu Linux o adresie IP 192.168.1.200 wykazał szereg portów o statusie: open|filtered.

I tak jak poprzednio aby uzyskać dodatkowe informacje o działających usługach wykorzystamy flagę: -sV. Użyta opcja pozwala na zidentyfikowanie usług wykorzystujących dane porty.

Wykorzystanie obu metod odnośnie systemu Windows nie dało żadnych efektów zaś w przypadku systemu Linux pozwoliło nam na określenie otwartych portów. W przypadku obu metod należy mieć na uwadze fakt, iż ich zadaniem nie jest ustanowienie kanału komunikacji przez który moglibyśmy przesłać dane ale wykrycie w badanym systemie potencjalnych luk. Opisane metody ze względu na swój nietypowy charakter działania mogą pozostać niezauważone przez administratora odpowiedzialnego za ochronę skanowanych systemów a dodatkowo pozwalają na ominięcie list kontroli dostępu (ACL), których zadaniem jest uniemożliwienie przeprowadzania skanowania TCP czy skanowania SYN.

Skanowanie ACK

Skanowanie ACK polega na wysłaniu pakietu TCP, który ma ustawiony aktywny bit ACK. Proces skanowania sprowadza się do wysłania w kierunku celu pakietu z aktywna flagą ACK, jeśli system zdalny odpowie pakietem RST oznacza to, że port jest niefiltrowany w przypadku otrzymania odpowiedzi w postaci komunikatu ICMP lub braku jakiejkolwiek odpowiedzi Nmap uzna port za filtrowany.

Trochę to zagmatwane ale już spieszę z wytłumaczeniem. Ten typ skanowania w szczególności przydatny jest w sytuacjach w których mamy do czynienia z zaporą sieciową. W przypadku zapór sieciowych ich klasyfikację możemy przeprowadzić ze względu na charakter działania. Tak więc zapory sieciowe czy bardziej popularnie - firewalle możemy podzielić na bezstanowe i stanowe.

Zapory bezstanowe są odpowiedzialne za filtrowanie ruchu sieciowego (ruch wychodzący jaki i przychodzący) przy czym analiza tego ruchu obejmuje warstwę trzecią i warstwę czwartą modelu ISO/OSI. Tak więc analizowanymi protokołami są IP, TCP i UDP a mówiąc bardziej szczegółowo informacje zawarte w przenoszonych pakietach - źródłowy adres IP, docelowy adres IP, port źródłowy i port docelowy. Największą wadą tego typu zapór jest fakt iż zapory tego typu decyzję o zablokowaniu bądź przepuszczeniu danego ruch sieciowego podejmują w oparciu o analizę pojedynczego pakietu. Działanie tego typu zapór nie obejmuje sprawdzenia czy dany pakiet jest fragmentem całości czyli już nawiązanego połączenia, czy jest pakietem przypadkowym bądź pakietem wygenerowanym przez atakującego. Stąd podatność tego typu zapór na ataki typu ACK czy FIN.

Poniżej przedstawiono przykład w którym host o adresie 192.168.1.50 przeprowadza skanowanie ACK hosta 192.168.1.205 (skanowany port 139) - punkt 1. W wyniku skanowania cel ataku odsyła pakiet TCP z ustawioną flagą RST - punkt 2. Oznacza to, że port jest niefiltrowany. Odpowiedź RST została odesłana ponieważ host znajdował się za bezstanową zaporą.

Zapory stanowe jeśli można tak powiedzieć są „bardziej mądre” od swoich braci. Cały ruch sieciowy przez zaporę jest traktowany jako całość co oznacza, że decyzja o przepuszczeniu bądź zablokowaniu danego datagramu jest podejmowana w oparciu o analizę pakietów tworzących połączenie. Mówiąc trochę inaczej, firewall „wie”, czy otrzymany pakiet jest częścią aktualnie realizowanego połączenia czy może jest całkowicie odrębnym i nieoczekiwanym pakietem.

Poniżej przedstawiono ten sam scenariusz jaki miał miejsce wyżej z tą tylko różnicą iż aktualnie host 192.168.1.205 znajduje się za zaporą stanową. W kierunku hosta zostaje wysłany pakiet TCP z ustawioną flagą ACK - punkt 1. Tym razem odpowiedź nie nadchodzi. Port przyjmuje status filtrowany.

Odpowiedź od hosta została zablokowana przez zaporę gdyż nie stanowiła większej całości połączenia.

Skanowanie FIN

Skanowanie te jest podobne do omówionego powyżej skanowania ACK lecz z tą różnicą, że zamiast pakietu z ustawioną flagą ACK zostaje wysłany pakiet z aktywną flagą FIN. W tej metodzie skanowania sprawdzamy powracający pakiet - domyślnie brak odpowiedzi oznacza, że port jest otwarty, a odpowiedź w postaci datagramu z ustawioną flagą RST/ACK, oznacza zamknięty port. Przy użyciu tej metody skanowania ważne jest rozpoznanie systemu, który będzie stanowił nasz cel ponieważ część systemów wysyła odpowiedzi RST niezależnie od tego czy port jest otwarty czy nie. Brak rozróżnienia powoduje, że w wynikach skanowania wszystkie porty przyjmą status zamknięty. Systemy, które zachowują się w ten sposób to systemy z rodziny Windows lecz też wiele urządzeń Cisco. Skanowanie tego typu przeprowadzamy wobec systemów Linux. Dodatkowo skanowanie te pomoże nam wykryć typ używanej zapory sieciowej.

Rozważmy analogiczną sytuację jaka miała miejsce przy skanowaniu ACK i sprawdźmy zachowanie hosta o adresie IP 192.168.1.205 w zależności od typu użytej zapory.

W pierwszej kolejności host za zaporą bezstanową. Po wykonaniu skanowania FIN (port 3986) - punkt 1 zostaje udzielona odpowiedź w postaci pakietu RST/ACK - punkt 2. Status portu w wyniku skanowania zostaje zakwalifikowany jako closed. Można zastanawiać się - Czemu port jest zamknięty skoro została udzielona odpowiedź? Otóż skanowanym hostem jest Windows 7 a system ten udzieli odpowiedzi RST/ACK niezależnie od statusu portu - pakiet RST/ACK jest wysyłany dla portu otwartego ale również zamkniętego.

Umieśćmy hosta za zaporą stanową i wykonajmy skanowanie tego samego portu. Tym razem w wynikach skanowania status portu zostaje ustawiony jako: open|filtered Status portu przyjął taki stan gdyż nie został odesłany pakiet RST/ACK. Brak pakietu oznacza iż został on zablokowany przez zaporę.

Po wykonaniu skanowania FIN jesteśmy w stanie stwierdzić jaka zapora chroni dostęp do hosta.

W systemie Linux mamy do czynienia z sytuacją odwrotną. Przeprowadzono skanowanie FIN wobec hosta 192.168.1.200, skanowany port 22 (SSH). Status portu został ustawiony na open|filtered gdyż otwarty port nie wysyła flagi RST/ACK.

W przypadku wykonania skanu FIN zamkniętego portu 29, status portu przyjmie stan closed. Status portu przyjął taki stan gdyż został odesłany datagram RST/ACK.

Opisana wyżej sytuacja odnosi się do hosta, który znajduje się za zaporą bezstanową.

To sprawdźmy jak przebiegnie skanowanie gdy hosta będzie chroniła zapora stanowa.

W przypadku portu otwartego status portu zostaje określony jako open|filterd.

Port zamknięty zgłasza ten sam status.

W przypadku zapory stanowej nie jest możliwe dokładne określenie statusu portu gdyż stan portu zostaje zdefiniowany na podstawie odpowiedzi w postaci pakietu RST/ACK. Zapora stanowa blokuje te pakiety tak więc wszystkie skanowane porty zostaną wykryte jako open|filterd.

Wszystkie przedstawione do tej pory metody, angażowały do skanowania host na którym zostało wydane polecenie wykonania skanu. Oznacza to, że przeprowadzanie wielu skanów naraża nas na wykrycie. Różne systemy w swoich logach rejestrują informacje przeprowadzanych operacji a dodatkowo w sieciach funkcjonują systemy IDS/IPS (ang. Intrusion Detection System, Intrusion Prevention System), których zadaniem jest wykrywanie (IDS) lub wykrywanie i blokowanie ataków (IPS) w czasie rzeczywistym. Zabezpieczenia te są więc odpowiedzialne za rejestrowanie zdarzeń, które mogą wpłynąć na bezpieczeństwo chronionej sieci. Wykorzystanie metod opisanych powyżej może wywołać alarm, który doprowadzi do wykrycia przeprowadzanych operacji.

Aby uniemożliwić wykrycie adresu IP hosta przeprowadzającego skanowanie można skorzystać z tzw. skanowania jałowego (ang. Idle Scanning). Przy użyciu tej techniki skanowania w całości procesu uczestniczy dodatkowy host tzw. zombie. Najlepsze kryterium wyboru hosta zombie stanowi komputer, który w sieci generuje mało ruchu. Hostem zombie może również zostać maszyna wirtualna.

Znalezienie i wykorzystanie hosta, który w naszym imieniu przeprowadziłby skanowanie jest największym problemem gdyż większość nowych systemów na pełnienie tej (zaszczytnej) funkcji jest już uodporniona ale nic nie stoi na przeszkodzie by użyć odpowiednio przygotowany system wykorzystując do tego oprogramowanie VirtualBox czy VMware (Windows XP SP2 świetnie się w tej roli sprawdzi).

Skanowanie przy użyciu hosta zombie bazuje na trzech założeniach:

Skanowany otwarty port po odebraniu pakietu TCP z ustawioną flagą SYN odpowiada pakietem SYN/ACK, natomiast port zamknięty odpowie pakietem RST,
Komputer zombie na skutek odebrania nieoczekiwanego datagramu SYN/ACK odpowiada wiadomością RST (sytuacja w przypadku portu otwartego), natomiast odebranie przez komputer zombie nieoczekiwanego komunikatu RST jest przez niego ignorowane (sytuacja w przypadku portu zamkniętego),
Host zombie a raczej system operacyjny musi spełnić warunek tzw. sekwencyjnej inkrementacji numerów identyfikacyjnych (tzw. identyfikator IPID). By móc wykorzystać dany system jako hosta zombie identyfikator IPID musi być przydzielany w sposób przewidywalny tj. wartości IPID muszą przyjmować kolejne wartości zwiększane o 1. W przypadku nowych systemów wartość numeru IPID jest wartością losową zaś starsze systemy działają według zasady przypisywania kolejnej wartości numerowi IPID.

Aby skanowanie jałowe mogło zostać przeprowadzone, napastnik wysyła w kierunku hosta zombie pakiet z ustawioną flagą SYN/ACK. W odebranym pakiecie RST sprawdzana jest wartość identyfikatora IPID.

Kolejnym krokiem jest wysłanie specjalnie przygotowanego pakietu SYN lecz tym razem celem jest dany port skanowanego hosta. Wysłany pakiet zawiera ustawiony adres źródłowy IP hosta zombie. Jeśli badany port jest otwarty zgodnie z zasadą ustalania sesji TCP system skanowany po otrzymaniu pakietu SYN w kierunku hosta zombie odsyła pakiet SYN/ACK. Dla hosta zombie otrzymany pakiet jest nieoczekiwany (pamiętamy, że pakiet SYN wysłał napastnik) dlatego też odsyła on w kierunku celu skanowania datagram RST, wysłanie pakietu powoduje zwiększenie wartości identyfikatora IPID o 1.

Ostatnim krokiem w tym procesie jest ponowne wysłanie w kierunku hosta zombie pakietu z aktywnymi flagami SYN/ACK (pakiet ten wysyła napastnik). Dla hosta zombie otrzymany pakiet znów jest pakietem nieoczekiwanym więc odsyła on pakiet RST, tym samym powiększając wartość identyfikatora IPID znów o 1.

Podsumowując wszystkie czynności, wartość identyfikatora IPID wzrosła o 2 od sprawdzonej wartości początkowej. Oznacza to, że na skanowanym hoście, badany port jest portem otwartym.

A co w przypadku portu zamkniętego? Sytuacja przebiega podobnie lecz z jednym małym wyjątkiem. Ale wszystko po kolei. Tak jak poprzednio w kierunku hosta zombie zostaje wysłany pakiet SYN/ACK, celem pakietu jest sprawdzenie wartości identyfikatora IPID.

Kolejny krok przebiega identycznie jak w przypadku sytuacji z portem otwartym - zostaje wysłany pakiet SYN w którym źródłowy adres IP wskazuje na hosta zombie (celem jest skanowany host). Ponieważ badany port jest portem zamkniętym w kierunku hosta zombie zostaje odesłany datagram RST (wartość IPID nie ulega zmianie).

Ostatnim krokiem jest wysłanie w kierunku hosta zombie kolejnego pakietu SYN/ACK, celem pakietu jest zbadanie o ile wzrosła wartość identyfikatora IPID. Ponieważ pakiet ten jest pakietem nieoczekiwanym host zombie odsyła pakiet RST, wysłanie pakietu wymusza na hoście zwiększenie wartości IPID o 1.

Reasumując w scenariuszu z portem zamkniętym sprawdzana wartość IPID wzrasta tylko o 1. Taki wzrost wartości IPID jest sygnałem dla napastnika iż skanowany port jest portem zamkniętym.

Aby sprawdzić czy dany host wspiera sekwencyjną inkrementację numerów identyfikacyjnych IPID można posłużyć się narzędziem hping3. Po wydaniu polecenia: hping3 -c 6 <adres_IP_hosta> zostanie wysłana seria pakietów TCP Null (brak aktywnych flag), analiza otrzymanych wyników pozwala nam stwierdzić czy host wspiera sekwencyjną inkrementację. Jak widać poniżej wartości IPID są powiększane o 1 co oznacza, że komputer ten może zostać hostem zombie (system Windows XP SP2).

Poniżej przedstawiono wykorzystanie tego samego polecenia ale względem systemu Ubuntu 14.04 jak można zaobserwować wartości IPID są wartościami losowymi. Host ten nie spełnia warunku sekwencyjności wartości IPID czego skutkiem jest brak możliwości wykorzystania go do skanowania w trybie Idle.

Innym sposobem wykrycia systemów, które mogły by posłużyć do pełnienia roli hostów zombie jest wykorzystanie skanerów IPIDSeq.

Pierwszym z skanerów jest skaner wbudowany w framework Metasploit. Zaletą użycia skanerów jest fakt iż możemy ich użyć w poszukiwaniu potencjalnych systemów zombie przeczesując całą podsieć.

Aby wykorzystać skaner należy w pierwszej kolejności za pomocą polecenia: msfconsole uruchomić framework. Po wydaniu polecenia (Metasploit korzysta z własnej linii poleceń) musimy wykonać czynności:

1 - za pomocą polecenia: use auxiliary/scanner/ip/ipidseq (polecenia możemy dopełniać za pomocą użycia klawisza TAB) uruchamiamy skaner,

2 - komenda: set RHOSTS <adres_IP/zakres> ustawia zakres przeprowadzanego skanu,

3 - komenda: set THREADS <wartość> ustala liczbę uruchamianych wątków, niższa wartość wolniejsze skanowanie zaś wartość wyższa spowoduje szybsze wykonanie skanu,

4 - komenda: show options pozwala na sprawdzenie wprowadzonych ustawień.

Po zdefiniowaniu wszystkich ustawień możemy uruchomić skaner. Uruchomienie skanu rozpoczynamy po wydaniu polecenia: run Skan wykrył jednego hosta o adresie IP 192.168.1.230, który spełnia warunki do użycia go w roli zombie.

Tą samą czynność wykrycia hostów spełniających warunek sekwencyjnej inkrementacji wykonamy za pomocą narzędzia Nmap i dołączonych skryptów. Aby uruchomić skan należy wydać polecenie: nmap <adres_IP/zakres> --script ipidseq Po wydaniu polecenia (w tym scenariuszu przeszukujemy sieć 192.168.1.0/24) Nmap rozpoczyna skanowanie. Jak widać poniżej efektem przeprowadzanego skanu jest wykrycie tego samego hosta co w przypadku użycia frameworku Metasploit.

Po odnalezieniu hosta możemy przejść do przeprowadzenia skanu portów. Nie zmieniamy scenariusza - wykonujemy skanowania portów z komputera o adresie IP 192.168.1.50, celem będzie host o adresie IP 192.168.1.205 zaś hostem zombie komputer 192.168.1.230.

Wykonanie skanowania portów z wykorzystaniem trybu jałowego uruchamiamy za pomocą polecenia: nmap <host_skanowany> -sI <host_zombie> Użycie dodatkowego parametru -Pn spowoduje brak pingowania systemu docelowego.

Host 192.168.1.205 został przeskanowany a skan ujawnił otwarte porty.

Dodatkowo na hoście 192.168.1.205 podczas prowadzonego skanowania został uruchomiony Wireshark tak by przekonać się czy rzeczywiście cały proces jest wykonywany przez hosta zombie. Jak widać poniżej całość przechwyconej komunikacji odbyła się tylko pomiędzy hostem zombie a skanowanym systemem, brak jest śladu obecności adresu IP komputera, który faktycznie skan przeprowadzał (host 192.168.1.50).

Opisany proces skanowania pozwala nam na wykonanie skanu bez pozostawienia w badanym systemie, śladów wskazujących na faktycznego sprawcę ataku.

Wiemy już jak przeprowadzać skanowanie w sposób całkowicie anonimowy. A co jeśli nie mamy możliwość przeprowadzenia skanu z wykorzystaniem metody opisanej powyżej i musimy narazić się na ewentualne wykrycie? Nieumiejętnie przeprowadzony proces skanowania lub przeprowadzony bez dodatkowych środków bezpieczeństwa może wzbudzić alarm a informacja o atakującym (adres IP) zostanie zapisana w dziennikach firewalli i systemów IDS. Aby utrudnić administratorom analizę logów po wykryciu skanu możemy wykorzystać opcję, nazywaną wabikiem (użycie parametru -D ang. decoy). Co ważne użycie tej opcji nie chroni Twojego adresu IP przed rejestracją ale sprawia, że wynik skanowania jest „zaciemniony”. Proces ten polega na stworzeniu iluzji, która ma przekonać, że w tym samym czasie nastąpił jednoczesny skan z różnych hostów.

Składnia polecenia wykorzystująca opcję wabika przedstawia się następująco: nmap <tryb_skanowania> <cel> -D <pozorne_adresy_IP> Możliwe jest użycie więcej niż jednego pozornego adresu IP, adresy te oddzielamy od siebie przecinkiem.

Poniżej został przedstawiony przykład skanowania stealth z wykorzystaniem parametru -D. Adresy IP podane po fladze -D są fałszywymi adresami, które również pojawią się w logach. Skanowanym hostem jest komputer o adresie IP 192.168.1.205 natomiast adresy 10.0.0.2 oraz 172.16.45.67 są adresami fikcyjnych hostów.

Aby fałsze adresy IP mogły być zarejestrowane w logach, fizycznie muszą zostać odebrane przez cel skanowania. Przechwytując ruch sieciowy na hoście docelowym można zaobserwować pakiety od nieistniejących hostów.

Użycie flagi -D utrudnia stwierdzenie, kto faktycznie skan przeprowadził.

Skanowanie - DNmap

Przeprowadzenie skanu portów pojedynczych hostów nie stanowi problemu - A co w sytuacji w której musimy przeprowadzić odkrywanie aktywnych portów na kilkunastu bądź kilkudziesięciu maszynach? Wykonanie tego zadania z wykorzystaniem pojedynczego hosta będzie utrudnione i czasochłonne. Dlatego w takiej sytuacji można użyć narzędzia DNmap. Narzędzie te zostało stworzone przez Sebastiana Garcię i jest odpowiedzią na postawione pytanie. Działanie narzędzia oparte jest o model klient-serwer. Oznacza to, że z wykorzystaniem aplikacji możemy stworzyć sieć komputerów, która przy pomocy narzędzia Nmap będzie prowadzić proces skanowania a wyniki skanowania zostaną zapisane na serwerze.

Myślę, że poniższa ilustracja w dość wymowny sposób przedstawia zasadę prowadzenia procesu skanowania z wykorzystaniem narzędzia DNmap.

Narzędzie DNmap tak naprawdę jest skryptem napisanym z wykorzystaniem języka Python i aby działać w systemie musi być zainstalowany interpreter tego języka wraz z bibliotekami: python-twisted oraz python-openssl. DNmap do działania wymaga również zainstalowanego Nmap-a. Narzędzie pobierzemy ze strony: https://sourceforge.net/projects/dnmap/

Aby móc utworzyć sieć komputerów, które będą realizować proces skanowania musimy wykonać trzy kroki:

1 - utworzyć listę poleceń narzędzia Nmap, listę poleceń zapisujemy w pliku tekstowym,

2 - uruchomić serwer DNmap, utworzony w poprzednim kroku plik posłuży nam do uruchomienia serwera,

3 - podłączyć klientów do serwera.

Rozpoczynamy od punktu pierwszego. Polecenia narzędzia Nmap zapisujemy w pliku tekstowym o nazwie: dnmapscan.txt. Plik zostaje zapisany w katalogu domowym. Serwer uruchamiamy w systemie Linux.

Po utworzeniu pliku zawierającego zapisane komendy Nmap-a przechodzimy do uruchomienia serwera DNmap. Serwer aktywujemy za pomocą polecenia: dnmap_server -f <plik_poleceń> W naszym przykładzie komenda przyjmie postać: dnmap_server -f dnmapscan.txt

Serwer został uruchomiony.

Ostatnim krokiem jest podłączenie klientów. W ramach ćwiczenia do serwera zostanie podłączonych dwóch klientów. Oba komputery klienckie pracują pod kontrolą systemu Linux.

Podłączenie klientów realizujemy po uprzednim pobraniu DNmap-a i niezbędnych bibliotek. Aby klient mógł skomunikować się z serwerem należy wydać polecenie: dnmap_client -s <adres_IP_serwera> -a <nazwa_klienta> (w niektórych wersjach systemu Linux polecenie należy poprzedzić komendą: python)

W scenariuszu do serwera o adresie IP 192.168.1.50 zostaje podłączony host o nazwie komp1 (IP 192.168.1.245).

Klient uzyskuje połączenie i zaczyna realizować proces skanowania.

Po podłączeniu pierwszego klienta przystępujemy do klienta drugiego. Do serwerem DNmap zostaje podłączony host komp02 (IP 192.168.1.246). Tak jak poprzednik, po zestawieniu połączenia klient realizuje proces skanowania.

Status podłączających się klientów możemy obserwować w oknie terminala w którym zostało wydane polecenie uruchamiające serwer. Jak widać poniżej oba hosty komp1 i komp02 zostały prawidłowo podłączone a status hostów został ustalony na Executing.

Proces skanowania trwa, oba podłączone hosty wykonują polecenia otrzymywane od serwera DNmap. Proces trwa tak długo, aż zostaną wykonane wszystkie polecenia zawarte w wcześniej utworzonym pliku tekstowym.

Poniżej host komp1 zakończył wykonywanie pierwszego zadania a że na serwerze zostały zdefiniowane trzy polecenia tak więc host zaczął realizować kolejne zadanie.

Host komp02 po wykonaniu swojej części pracy zakończył zadanie - serwer nie ma zdefiniowanych więcej poleceń.

Po przeprowadzeniu skanu wszystkie wyniki są umieszczone na serwerze w katalogu: nmap_results.

Obszar skanowania obejmował sieć 192.168.1.0/24 oraz hosta 192.168.1.205. Na hoście tym podczas wykonywania skanowania zostało włączone przechwytywanie pakietów zaś wynik tego procesu został zaprezentowany poniżej. Jak można zaobserwować brak jest śladu w wynikach adresu IP serwera DNmap (IP 192.168.1.50) jako faktycznie tego hosta, który koordynował cały proces, natomiast wyniki jednoznacznie wskazują, że hostami przeprowadzającymi skanowanie były komputery o adresach IP 192.168.1.245 oraz 192.168.1.246. Wnioski Czytelniku mam nadzieję, że nasunęły Ci się same - użycie serwera DNmap, również w pewien sposób maskuje faktycznego sprawcę ataku.

Na koniec jeszcze dwie krótkie uwagi odnośnie omawianego narzędzia.

Jeśli będziesz chciał przeprowadzić ponowne skanowanie z wykorzystaniem wcześniej utworzonego pliku z poleceniami koniecznie skasuj plik: nazwa_pliku.dnmaptrace gdyż w przeciwnym wypadku nie uruchomisz serwera. W omawianym scenariuszu polecenia zostały zapisane w pliku dnmapscan.txt tak więc przed ponownym uruchomieniem serwera skasuj plik: dnmapscan.txt.dnmaptrace Ewentualnie utwórz plik o innej nazwie.

Podane przeze mnie narzędzia oraz przykłady ich zastosowania oczywiście omawianego tematu skanowania portów do końca nie wyczerpują lecz do pokazanych metod wykonania odkrywania aktywnych portów jeszcze wrócimy. Gdy już mamy wiedzę na temat wykrywania aktywnych hostów oraz skanowania ich portów w kolejnym wpisie pójdziemy o krok dalej czyli zajmiemy się przechwytywaniem banerów oraz skanowaniem systemu pod kątem wykrycia luk.

BIBLIOGRAFIA:

What You Must Know About OS Fingerprinting - InfoSec Resources

7 Nmap NSE Scripts for Recon | HackerTarget.com

Nmap Scripting Engine – Basic Usage | Penetration Testing Lab

Scanning Windows Deeper With the Nmap Scanning Engine - scanning-windows-deeper-nmap-scanning-engine-33138

Passive OS Fingerprinting - NETRESEC Blog

Top 30 Nmap Command Examples For Sys/Network Admins

Zapisz

Co w sieci siedzi. Zrozumieć i "pokochać" protokół STP.

2016-05-09T07:03:27+00:00

W tym wpisie zajmiemy się protokołem STP, który przynależny jest do urządzeń warstwy drugiej, czyli switchy, a jego głównym zadaniem jest wykrywanie i zapobieganie wystąpieniu w sieci pętli. To co należy wiedzieć na temat tego protokołu to to, że ściśle wiąże się on z nadmiarowością łączy, tak aby w przypadku wystąpienia awarii nie nastąpił przestój sieci i by pakiety, pomimo zaistniałych problemów, mogły szczęśliwie dotrzeć do celu.

Aby zrozumieć sens stosowania tego typu rozwiązań prześledźmy prosty przykład przedstawiony na poniższym rysunku.

Host1 próbuje skomunikować się ze stacją Host2 lecz niestety komputerowi Host1 nie jest znany adres MAC komputera Host2. W tym celu w kierunku switcha S1 zostaje wysłane rozgłoszenie. Ramka broadcast poprze interfejs f0/4 trafia do przełącznika. Przełącznik ruch ten kopiuje na wszystkie aktywne interfejsy z wyjątkiem tego z którego rozgłoszenie zostało otrzymane. Tak więc ruch brodcastowy zostaje wysłany z interfejsu f0/1 w kierunku switcha S2 oraz z interfejsu f0/3 w kierunku przełącznika S3. Rozgłoszenie zostaje odebrane przez przełącznik S2 i przekazane dalej w kierunku switcha S3, w tym samym czasie ten sam ruch zostaje odebrany przez przełącznik S3 (rozgłoszenie otrzymane od S1) i również skopiowane i przesłane dalej lecz tym razem w kierunku switcha S2. Tak więc przełączniki otrzymują kolejne kopie tej samej ramki, które są przesyłane w nieskończoność - powstaje pętla. Jeśli Czytelniku czytałeś moje wcześniejsze wpisy bądź Masz wiedzę na temat warstwy 3 modelu ISO/OSI to pewnie wiesz o istnieniu parametru TTL (ang. Time to Live). Mechanizm ten odpowiada za zmniejszenie wartości pola o 1 za każdym razem gdy pakiet na swej drodze napotka router, tak więc w momencie osiągnięcia przez TTL wartości zero, router nie przekaże pakietu do kolejnego urządzenia sieciowego. W warstwie 2 niestety tego typu zabezpieczeń NIE MA. Jedynym sposobem na przerwanie powstałej burzy rozgłoszeniowej (ang. broadcast storm) jest wyłączenie dowolnego z aktywnych interfejsów.

Aby zademonstrować sposób działania i skutki powstania burzy rozgłoszeniowej prześledźmy o to taki przykład w którym to w sieci zbudowanej ze switchy występują nadmiarowe linki a na przełącznikach został wyłączony protokół STP. Przyjęta topologia sieci odpowiada rysunkowi powyżej.

Aby wykryć i zdiagnozować burzę wykorzystamy polecenie: show processes cpu history. Po wydaniu polecenia zostanie wyświetlony histogram (a tak naprawdę trzy) przedstawiający użycie procesora. Zakres wyświetlonych danych obejmuje ostatnie 72 godziny.

Pierwszy wykres obejmuje wykorzystanie procesora w procentach na sekundę w ciągu ostatnich 60 sekund (CPU percent per second - last 60 seconds), drugi wykorzystanie procesora w procentach na minutę w ciągu ostatnich 60 minut (CPU percent per minute - last 60 minutes), trzeci zaś wykorzystanie procesora w procentach na godzinę w ciągu ostatnich 72 godzin (CPU percent per hour - last 72 hours).

Na osi x został przedstawiony czas (0 oznacza moment wydania polecenia), zaś na osi y został umiejscowiony poziom wykorzystania procesora.

Jak można zaobserwować poniżej w momencie wydania polecenia użycie procesora było na poziomie 4% by w 20 sekundzie skoczyć do 7% i następnie w 50 sekundzie spaść znów do 4% Gwiazdki poniżej budują wykres.

Na każdym z przełączników zostało wydane polecenie: no spanning-tree vlan 1 nakazujące wyłączenie protokołu STP w domyślnej sieci VLAN1.

Wydanie polecenia wyłączającego STP na dwóch pierwszych przełącznikach S1 i S2 jeszcze nie powoduje żadnych konsekwencji gdyż by burza broadcastowa mogła wystąpić musi powstać pętla.

Wyłączenie protokołu STP na przełączniku S3 inicjuje burzę - mamy do czynienia z pętlą. Nie trzeba długo czekać (wystarczyło 5 sekund) by zauważyć opóźnienie podczas wprowadzania poleceń systemu IOS. Wydanie polecenia pokazującego wykorzystanie procesora ukazuje nam zużycie CPU na poziomie 99-100% (ostatnia minuta).

Dodatkowo już po minucie zaistnienia burzy dochodzi kolejny problem związany z niestabilnością tablicy adresów MAC. Trwająca burza rozgłoszeniowa powoduje nieustanne aktualizowanie tablic adresów MAC. Każda z aktualizacji oznacza zmianę drogi wysyłania ramek - pamiętaj, że przełącznik celem określenia interfejsu przez który ma wysłać daną ramkę tak by dotarła do miejsca przeznaczenia analizuje wszystkie otrzymane ramki (przypisanie: interfejs przełącznika - adres MAC).

W naszym przykładzie oznacza to, że dla przełącznika S1 dany host jest raz dostępny poprzez interfejs f0/1 a raz f0/3. O zmianach tych, które następują bardzo szybko jesteśmy informowani na bieżąco w postaci komunikatów w linii CLI przełącznika.

Aby burza mogła zostać przerwana należy wyłączyć jeden z interfejsów tak by przerwać powielanie jednych i tych samych ramek. Oczywiście problem burzy rozwiąże ponowne włączenie protokołu STP. I te rozwiązanie zostało wybrane. Po obserwacji zużycia CPU dochodzimy do wniosku - problem z burzą został rozwiązany.

Można by zadać pytanie - Gdzie w tym wszystkim protokół STP i w jaki sposób nie dopuszcza on do powstania pętli? Otóż protokół ten domyślnie jest włączony na każdym porcie switcha i jego głównym zadaniem jest zapobieganie sytuacji opisanej powyżej. Realizacja tego zadania odbywa się poprzez czasowe wyłączenie (blokowanie) połączeń pomiędzy przełącznikami, które potencjalnie mogły by być źródłem powstania pętli. Tak więc dzięki zastosowaniu protokołu STP nasza topologia sieciowa mogłaby przybrać o to taką postać.

Efektem działania protokołu STP jest zablokowanie łącza pomiędzy switchem S1 a S3. Łącze te jest zablokowane czasowo, co oznacza, że w przypadku wystąpienia problemów z innymi łączami zostanie ono przywrócone by zapewnić ciągłość komunikacji. Zablokowanie ruchu sieciowego pomiędzy przełącznikami uniemożliwia powstanie pętli, której następstwem mogłaby być burza rozgłoszeniowa powodująca problemy z komunikacją.

Po tym wprowadzeniu na pewno Czytelniku w głowie masz szereg pytań - Jak działa protokół?, Jakie kryteria decydują o zablokowaniu danego łącza? czy Jak dokonać jego prawidłowej konfiguracji?

Zanim przejdziemy z opisem dalej by na tak postawione pytania udzielić odpowiedzi, winien jestem jeszcze parę słów wyjaśnienia. Zacznijmy może tak - na uwadze należy mieć fakt, iż protokół STP od dawna już nie jest obowiązującym standardem (z powodu swoich wad) i że w nowoczesnych sieciach po prostu się go NIE STOSUJE. Co nie znaczy, że na swej drodze administratora się z nim nie spotkasz. Tworzenie artykułu dość obszernego i co tu mówiąc tematycznie nie łatwego nie miało by sensu gdyby opierać się tylko na założeniu, że przypadkiem nasze drogi z tym protokołem się nie skrzyżują. Protokół STP i sposób jego działania po prostu warto poznać gdyż stanowi on bazę do poznania bardziej zaawansowanych rozwiązań - takich jak PVST czy RSTP.

W wpisie tym przyjąłem założenie w którym to będę odnosić się do protokołu STP a tak naprawdę przełączniki będą działać pod kontrolą PVST czyli STP z obsługą sieci VLAN.

Tak więc już wiesz że głównym zadaniem protokołu STP jest wykrycie fizycznych pętli i wyeliminowanie ich poprzez wynegocjowanie wolnej od pętli topologii logicznej.

Krótko mówiąc

STP wykrywa pętle i blokuje nadmiarowe linki,
Zapewnia, że między dwoma dowolnymi urządzeniami jest tylko jedna aktywna ścieżka.

Działanie protokołu STP opiera się o algorytm drzewa rozpinającego (ang. Spanning Tree Algorithm), to właśnie on jest odpowiedzialny za wyznaczenie drogi wolnej od pętli. Pierwszym z ważnych zadań algorytmu STA jest określenie puntu odniesienia, tzw. root bridge (korzeń drzewa). Korzeniem drzewa zostaje jeden z przełączników, który w dalszych operacjach wyznaczania drogi jest punktem odniesienia dla kolejnych obliczeń. W kolejnym kroku STA określa wszystkie możliwe ścieżki do korzenia jeśli istnieją drogi alternatywne czyli więcej niż jedna ścieżka, wybierana jest najkorzystniejsza, zaś pozostałe drogi są blokowane. Blokowanie odbywa się poprzez wyłączenie ruchu sieciowego na danym porcie przełącznika. Przy czym co należy dodać blokowanie nie dotyczy ramek BPDU (ang. bridge protocol data unit), których zadaniem jest zapewnienie poprawnego działania protokołu poprzez komunikację z innymi przełącznikami (o ramkach BPDU więcej za chwilę).

Najważniejsze pojęcia związane z działaniem protokołu STP to:

Bridge ID (identyfikator switcha, identyfikator mostu),
Path Cost (koszt ścieżki).

Identyfikator BID (Bridge ID) jest 8 bajtową liczbą, w skład identyfikatora wchodzi tzw. priorytet oraz adres MAC. BID jednoznacznie identyfikuje każdy przełącznik i jest jedynym kryterium przy wyborze root-a (korzenia). Informacja o wartości BID jest przekazywana podczas wymiany ramek BPDU. Switch o najmniejszej wartości BID staje się root bridge.

Jak już wspomniałem BID składa się z dwóch części:

priorytet (2 bajty) na urządzeniach Cisco domyślnie 32768
adresu MAC

Priorytet najczęściej podaje się dziesiętnie, a MAC w postaci szesnastkowej.

W protokole STP punkt odniesienia czyli przełącznik root względem, którego będą przeprowadzane obliczenia wybierany jest dla wszystkich VLAN-ów naraz (jeden korzeń w całej sieci). Po dokonanych usprawnieniach i poprawkach np. PVST, należało zmodyfikować BID, tak aby przenosił informację o numerze VLAN gdyż protokół ten wymaga osobnej instancji STP dla każdej sieci VLAN. Dlatego też z dwóch bajtów pozostawiono 4 bity na priorytet, zaś pozostałe 12 bitów przydzielono na identyfikator VID (VLAN ID).

W domyślnej konfiguracji priorytet przełącznika jest ustawiony na wartość 32768 ustawienie to powoduje, że w procesie elekcji rootem zostanie przełącznik o najniższym adresie MAC. Wyboru tego nie powinno się pozostawić przypadkowi bo może się okazać, że funkcję tą będzie pełnił najmniej wydajny przełącznik - należy więc ręcznie zdefiniować priorytet na wybranym switchu, który ma zostać rootem (opis w dalszej części wpisu).

Koszt ścieżki jest ściśle powiązany z prędkością łącza, została zastosowana zasada, że im wyższa prędkość, tym niższy koszt. Na tej podstawie przełączniki określają, jak daleko mają do korzenia (roota).

W pierwotnej wersji protokołu STP (802.1D) koszt był wyliczany jako: 1000/pasmo ścieżki w Mbps. Jak widać poniżej rozwiązanie te okazało się nie wystarczające gdyż po wprowadzeniu nowych standardów przesyłu danych koszt ścieżki zawsze wynosił 1. Taki sam koszt był przypisany łączu o prędkości 1 Gbps jak i łączu dziesięciokrotnie szybszemu. Aby uwzględnić tę zmianę IEEE dokonało poprawki zmieniając skalę na nieliniową, tak by koszt uwzględniał faktyczną prędkość łącza.

Prędkość łącza	Koszt ścieżki	Koszt ścieżki
10 Gbps	2	1
1 Gbps	4	1
100 Mbps	19	10
10 Mbps	100	100

Możemy ręcznie dokonać modyfikacji kosztu ścieżki poprzez zmianę kosztu portu. Zmianę tą jednak wykonujemy jeśli mamy ku temu dobry powód. Zmiana kosztu ścieżki została opisana w dalszej części wpisu.

Aby protokół STP mógł działać i pełnić swoją rolę musi mieć możliwość komunikacji z innymi przełącznikami. Komunikacja ta odbywa się dzięki ramkom BPDU.

Switch dla każdego swojego portu zapisuje kopię najlepszej ramki BPDU, którą „zobaczył” na danym porcie. Przez „zobaczyć” należy rozumieć ramkę którą przełącznik otrzymał bądź zamierza wysłać.

Ramka BPDU obejmuje 12 pól i w jej budowie możemy wyróżnić trzy główne części tj.:

Cztery pierwsze pola: Identyfikator protokołu, Wersja, Typ komunikatu oraz Flagi odpowiedzialne są za identyfikację ramki BPDU,
Kolejne cztery pola (Identyfikator mostu głównego, Koszt ścieżki, Identyfikator mostu, Identyfikator portu) odpowiedzialne są za przesłanie informacji pozwalających ustalić roota oraz wybranie najlepszych ścieżek,
Ostanie cztery pola (Wiek komunikatu, Wiek maksymalny, Czas powitania, Opóźnienie przekazania) są polami timerów (zegarów protokołu STP).

Ramka BPDU została schematycznie przedstawiona na rysunku poniżej:

I poniżej ramka BPDU, która została przechwycona z wykorzystaniem aplikacji Wireshark

Ramka BPDU jest enkapsulowana w ramce ethernetowej a następnie wysyłana na adres grupowy MAC: 01:80:C2:00:00:00 Adres ten jest odpowiedzialny za obsługę protokołu STP i informacje przesłane za jego pośrednictwem trafią do wszystkich przełączników w obrębie danej domeny rozgłoszeniowej.

Zbieżność protokołu STP jest osiągana w trzech krokach:

wybór Root Bridge,
wybór Root Portów,
wybór Portów desygnowanych.

Po uruchomieniu wszystkich urządzeń w sieci, wszystkie przełączniki rozgłaszają kompletnie niespójne informacje. Dzieje się tak gdyż każdy z switchy uznaje siebie za root-a.

W przykładzie poniżej zastosowałem pewne uproszczenie gdyż przyjęto jeden adres MAC na switch a w rzeczywistości scenariusz powinien być rozpatrywany w odniesieniu do każdego z użytych interfejsów. Uproszczenie zastosowałem by na samym początku uczenia się działania protokołu STP nie zostać przytłoczonym zbyt dużą ilością informacji. W dalszej części wpisu będzie rozważana topologia trochę bardziej złożona.

Proces elekcji root-a rozpoczyna się od wysłania ramek BPDU w których każdy z przełączników siebie samego wybiera do pełnienia tej roli. Jak widać po poniższym rysunku i analizie przesłanych danych rootem zostanie przełącznik S1 gdyż ten switch ma przypisany najmniejszy priorytet. A jak już wiesz wartość priorytetu ma większą wagę niż adres MAC. Ale wszystko po kolei.

Przełącznik S3 po otrzymaniu ramki BPDU od switcha S2 sprawdza zawarte dane w otrzymanej ramce BPDU. W kolejnym kroku następuje porównanie swoich danych z danymi otrzymanymi. Wartości priorytetu (32769) są jednakowe więc kryterium, które będzie rozstrzygać o pierwszeństwie będzie adres MAC. Porównując adresy MAC przełącznik S3 uzna switch S2 jako root gdyż otrzymany adres MAC od S2 ma mniejszą wartość niż własny. Informacje zawarte w ramce BPDU zostają prze przełącznik zapisane (zostaną wykorzystane w kolejnym etapie elekcji).

Przełącznik S2 ramkę BPDU wysyła w kierunku S1. Porównanie wartości prowadzi do odrzucenia przez przełącznik S1 otrzymanej ramki gdyż wartość priorytetu w ramce BPDU jest wyższa od tej która jest przypisana switchowi S1.

Przełącznik S3 na tym etapie uznaje za roota switcha S2. Dlatego w kolejnych ramkach BPDU rozgłasza dane przełącznika S2. Ramki BPDU zostają wysłane w kierunku przełącznika S2 i S1.

Przełącznik S1 po raz kolejny otrzymaną ramkę BPDU odrzuca gdyż wartość priorytetu otrzymanego jest większa od własnego priorytetu.

Przełącznik S2 otrzymaną ramkę również odrzuca gdyż otrzymane dane pokrywają się z danymi własnymi.

Ramki BPDU zostają wysłane z przełącznika S1 do przełączników S2 i S3.

Switch S2 po otrzymaniu informacji od S1 uznaje go za roota gdyż dane priorytetu otrzymanego są niższe od własnych.

Switch S3 również uaktualnia swoje informacje i za roota przyjmuje przełącznik S1, tak jak w przypadku switcha S2 decyzja ta zostaje podjęta po analizie otrzymanych informacji a konkretnie wartości otrzymanego priorytetu.

Rootem zostaje przełącznik S1.

Sprawdźmy zatem jak przedstawia się konfiguracja przełączników.

Podstawowym poleceniem, które pozwoli nam na uzyskanie informacji na temat protokołu STP jest komenda: show spannig-tree

Na pierwszy rzut przejrzyjmy konfigurację przełącznika S1.

Po wydaniu polecenia: show spannig-tree uzyskujemy dane na podstawie, których możemy stwierdzić, który przełącznik pełni funkcję roota.

Dane przełącznika S1, które posłużyły do zbudowania ramki BPDU wysłanej do innych switchy zawarte są w sekcji Bridge ID (punkt 1). Tak więc znajdziemy w nich wartość ustalonego priorytetu (Priority) oraz adres MAC interfejsu biorącego udział w procesie STP.

Gdy podczas przeglądania informacji zawartych po wydaniu polecenia: show spannig-tree odnajdziemy komunikat: This bridge is the root oznacza to, że przełącznik ten w procesie STP jest punktem odniesienia dla wszystkich pozostałych przełączników jest przełącznikiem głównym. (punkt 2).

Przyjrzyjmy się kolejnemu przełącznikowi i sprawdźmy konfigurację ustawień STP na switchu S2.

Jak widać poniżej w sekcji Root ID znajdują się dane wskazujące na przełącznik S1 jako ten który pełni rolę root-a. W sekcji Bridge ID znajdują się dane przełącznika S2. Porównując te dane ze sobą dochodzimy do wniosku iż switch ten nie może pełnić rolę root-a gdyż jego wartość priorytetu jest wyższa od priorytetu przełącznika S1.

Uważnego Czytelnika pewnie zainteresuje wartość priorytetu przełącznika ustalona na 32769. Jeszcze chwilę temu wspomniałem, że domyślną wartością dla switchy jest wartość 32768. Więc skąd ta różnica wynosząca aż 1? Dodam, że przełącznik S2 oczywiście korzysta z ustawień domyślnych - nic w konfiguracji nie zostało zmienione. Wartość domyślna jest powiększona o 1, ponieważ na przełączniku istnieje domyślna sieć VLAN o przypisanym identyfikatorze 1 (sieć VLAN0001 jest skonfigurowana na każdym z przełączników). Oznacza to, że istnienie sieci VLAN ma wpływ na wartość priorytetu. Gdyby na przełączniku został skonfigurowany dodatkowy VLAN o identyfikatorze 20 wartość priorytetu wzrosłaby o tą wartość.

Sposób wyliczenia wartości priorytetu przedstawia poniższy rysunek.

Poniżej został jeszcze przedstawiony przykład w którym interfejs przełącznika S2 został przeniesiony do sieci VLAN o identyfikatorze 10. Jak widać zmiana położenia interfejsu względem VLANu zmieniła wartość priorytetu. Wartość ta wynosi 32778 (wartość domyślna 32768 + identyfikator sieci VLAN 10).

Sprawdzenie konfiguracji STP przełącznika S3 utwierdza nas w przekonaniu iż to switch S1 pełni rolę root-a.

W naszej testowej sieci zaszczytną rolę root-a pełni przełącznik S1. Można by było zapytać - Co się stanie w przypadku gdy go wyłączymy? i Jak w takiej sytuacji zareaguje protokół STP?

Aby odpowiedzieć sobie na tak postawione pytania interfejsy f0/1 oraz f0/3 przełącznika S1 zostały wyłączone - co pokazuje poniższy zrzut.

Aby sprawdzić konfigurację STP na przełączniku S2 ponownie wydajemy polecenie: show spanning-tree. Wydanie polecenia informuje nas iż ten switch pełni rolę root-a.

Wydanie tego samego polecenia na przełączniku S3 potwierdza informacje uzyskane w poprzednim kroku - rola root-a została przypisana switchowi S2.

I znów można by było zapytać - Czemu funkcja ta została przypisana przełącznikowi S2? Pewnie część z Was już zna odpowiedź. Analiza danych z obu przełączników (sekcja Bridge ID) przekonuje nas iż wartość priorytetu dla obu przełączników jest jednakowa i wynosi 32769. W takim przypadku gdy nie można rozstrzygnąć elekcji przy wykorzystaniu wartości priorytetu decyduje najmniejsza wartość interfejsu adresu MAC. Porównując wartości adresów:

przełącznik S2 - 0817.35e3.b500,
przełącznik S3 - 8cb6.4fd8.fa00.

dochodzimy do wniosku iż wartość interfejsu MAC przełącznika S2 jest niższa. Przełącznik ten zaczyna pełnić rolę root bridge.

Blokowanie ruchu sieciowego odbywa się poprzez czasowe wyłączenie interfejsu przełącznika, który z punktu widzenia protokołu STP spowodowałby powstanie pętli. Informacje o stanie portów uzyskamy również dzięki poleceniu: show spanning-tree

Przyjrzyjmy się jeszcze raz konfiguracji STP na przełączniku S1.

Na rysunku znajduje się tabela w której pierwszą kolumną jest Interface W kolumnie tej zostały ukazane wszystkie porty przełącznika biorące udział w procesie STP.

Druga kolumna przedstawia rolę jaką pełni dany interfejs.

W procesie STP jedną z ról jaką może pełnić interfejs jest rola: portu głównego.

Root port (port główny) - port ten zawsze znajduje się najbliżej przełącznika pełniącego rolę root-a. Oznacza to, że przełącznik interfejsów w tym stanie nie będzie posiadał lecz rolę tę będą pełniły porty leżące najbliżej niego czyli interfejsy sąsiadów. W naszym scenariuszu będzie to interfejs f0/1 przełącznika S2 oraz interfejs f0/3 przełącznika S3. Sprawdzenie konfiguracji stanu portów na przełącznikach S2 oraz S3 potwierdza nasze rozważania.

Nasza testowa topologia przyjmie więc postać:

Drugą rolą jaką może pełnić port przełącznika jest rola: portu desygnowanego.

Designated port jest portem, którego zadaniem jest przekazanie ruch sieciowego w kierunku innych przełączników. Ponieważ rootem został przełącznik S1 tak więc wszystkie jego porty będą znajdować się w tym stanie. Co należy jeszcze wiedzieć o porcie desygnowanym? - to to że w połączeniach point-to-point port pracujący w tym trybie może być tylko jeden. Oznacza to, że nie zajdzie sytuacja w której po obu stronach połączonych ze sobą przełączników, oba porty będą ustawione do pracy w trybie designated.

Portem desygnowanym został również interfejs f0/3 przełącznika S2.

Uzupełnijmy więc nasz diagram sieci o nowe informacje.

Przy porcie f0/1 przełącznika S3 w kolumnie Role widnieje skrót Altn (rysunek powyżej) oznacza to, że port pełni rolę portu alternatywnego (ang. alternate port). Port alternatywny jest to port, który może przekazywać ramki ale w tym momencie jest wyłączony (zablokowany) tak by nie powstała pętla. Nazwa alternate port jest używana w protokołach PVST oraz RSTP zaś w przypadku zwykłego STP port ten przyjmuje nazwę non-designated port.

Tak więc dodajmy kolejne dane do naszego diagramu sieci a dodatkowo uzupełnijmy go o koszt ścieżek (koszt wszystkich ścieżek wynosi 19, gdyż połączenia pomiędzy przełącznikami wynoszą 100 Mbps – standard FastEthernet).

Po uzupełnieniu wszystkich danych mogą nasunąć się pewne pytania. Pierwsze z nich to - Czy root portem w przypadku przełącznika S2 mógłby zostać interfejs f0/3? Tu w udzieleniu odpowiedzi pomogą nam koszty ścieżek. Odpowiedź brzmi - NIE. Koszt dotarcia do root-a w przypadku użycia interfejsu f0/1 wynosi 19 natomiast koszt dotarcia do S1 przy użyciu portu f0/3 równa się 38 (19 - ścieżka S2-S3 +19 – ścieżka S3-S1 ).

Drugie pytanie - Dlaczego portem blokowanym (alternate port) jest interfejs f0/1 przełącznika S3 a nie interfejs f0/3 switcha S2. Tu by udzielić poprawnej odpowiedzi należy porównać adresy MAC obu użytych interfejsów. Niższy adres MAC posiada przełącznik S2 dlatego interfejs f0/3 został wybrany jak designated port.

Trzecie pytanko - A co w przypadku w którym koszt dotarcia do root-a dla obu interfejsów wyniósłby tyle samo? W takim przypadku brany jest pod uwagę tzw. priorytet portu. Dla przełączników Cisco wartość priorytetu domyślnie została ustalona na wartość 128. Wartość priorytetu może wahać się od 0 do 240 lecz musi spełnić jeden warunek – wartość priorytetu musi być wielokrotnością liczby 16. Pierwszeństwo oczywiście mają mniejsze wartości.

I tu również może dojść do sytuacji w której priorytetu portu będą miały przypisane te same wartości - wybór interfejsu dalej nie będzie rozstrzygnięty. W takim przypadku o wyborze interfejsu decyduje numer portu. Priorytet portu w połączeniu z numerem portu nazywany jest identyfikatorem portu.

Poniżej przedstawiono zrzut przedstawiający konfigurację STP przełącznika S2. Po wydaniu polecenia: show spanning-tree uzyskamy informację o koszcie (kolumna Cost) i dodatkowo poznamy identyfikator portu (kolumna Prio.Nbr). Np. interfejs f0/1 posiada przypisany priorytet 128 i numer portu wynosi 1 zaś koszt trasy został ustalony na 19.

Aby port przełącznika mógł pełnić powierzoną mu rolę musi przejść przez wszystkie stany procesu STP. Stany te ściśle związane są z zegarami STP (został określony czas po jakim port może zmienić swój stan) a głównym ich zadaniem jest uzyskanie topologii wolnej od pętli.

Możliwe stany portu zostały przedstawione i opisane poniżej:

Disabled (stan wyłączenia) - port jest wyłączony administracyjnie (shutdown), dlatego też odrzuca odbierane na nim ramki a co za tym idzie przełącznik z wykorzystaniem tego interfejsu nie uczy się adresów MAC ani nie odbiera ramek BPDU (brak uczestnictwa w procesie STP)

Blocking (stan blokowania) - port jest zablokowany (niedesygnowany) co oznacza, że nie przekazuje ramek zawierających dane oraz odrzuca wszystkie ramki z danymi przekazane z innych interfejsów. Proces uczenia się adresów MAC jest wyłączony lecz interfejs odbiera i przetwarza ramki BPDU co oznacza, że stan interfejsu w zależności od zaistniałych warunków może ulec zmianie

Listening (stan nasłuchiwania) - w tym stanie port odrzuca wszystkie ramki z danymi oraz nie uczy się adresów MAC. Port w tym stanie jest potencjalnym kandydatem do osiągnięcia funkcji root port bądź designated port dlatego też interfejs odbiera i przetwarza ramki BPDU a dodatkowo transmituje własne. Port przejdzie w stan blokowania gdy nie zostanie spełniony warunek dotarcia do root-a z wykorzystaniem ścieżki o niższym koszcie. Oznacza to, iż przez interfejs ten musi prowadzić droga do mostu głównego o niższym koszcie niż z interfejsów pozostałych.

Learning (uczenie się) - port nie przekazuje żadnych ramek z danymi, następuje przygotowanie do tego procesu dlatego też tablica adresów MAC przełącznika wypełnia się adresami MAC. Ramki BPDU są odbierane, przekazywane i transmitowane.

Forwarding (stan przekazywania) - port przełącznika stał się częścią topologii oznacza to że przekazuje i odbiera ramki zawierające dane, ramki BPDU są oczywiście odbierane, przekazywane i transmitowane.

Przejdźmy zatem do trochę trudniejszego przykładu. Nasza testowa topologia sieciowa została przedstawiona na rysunku poniżej. Tworzą ją trzy przełącznik, które zostały połączone ze sobą tak, że każdy z każdym jest spięty dwoma niezależnymi interfejsami.

Adresy MAC portów został sprawdzone na każdym ze switchy (rysunek poniżej) i ich wartości zamieszczono na schemacie powyżej.

Przełączniki zostały uruchomione. Protokół STP rozpoczyna działanie by wyznaczyć trasę, która będzie wolna od pętli.

Poniżej na rysunku przedstawiono efekt działania protokołu STP na każdym z przełączników.

Przeglądając powyższą konfigurację procesu STP możemy dojść do następujących wniosków:

1 - przełącznikiem root został wybrany switch S2,

2 - wszystkie interesy przełącznika S2 pełnią rolę portów desygnowanych,

3 - funkcję root port pełnią interfejsy: f0/1 przełącznika S1 oraz f0/1 przełącznika S3,

4 - portami blokowanymi (alternate port) są interfejsy: f0/2 przełącznika S1 oraz f0/2, f0/3, f0/4 przełącznika S3.

Celem lepszego zobrazowania wytyczonej ścieżki wszystkie powyższe informacje zostały zebrane na diagramie sieci poniżej.

Odpowiedzmy więc sobie na pytanie - Czemu została wytyczono taką drogę przesyłu pakietów?

Rozpoczniemy od analizy adresów MAC biorących udział w procesie STP.

Najniższy adres MAC posiada interfejs f0/1 przełącznika S2 (0817.35E3.B501). Wszystkie przełączniki mają domyślnie ustaloną wartość priorytetu (32768) i domyślnie istnieje skonfigurowany jeden VLAN o identyfikatorze 1. Tak więc wartość priorytetu wyniesie 32769.

Przy pomocy wartości priorytetu nie możemy określić, który z przełączników będzie pełnić funkcję root-a.

Gdy priorytet na wszystkich przełącznikach wynosi tyle samo, kryterium rozstrzygającym jest adres MAC. Najniższy adres MAC należy do interfejsu f0/1 przełącznika S2 tak więc ten przełącznik zaczyna pełnić funkcję root bridge.

Ponieważ przełącznik S2 został root-em wszystkie jego interfejsy pełnią rolę portów desygnowanych.

Portem pełniącym rolę root port na przełączniku S1 został interfejs f0/1 gdyż posiada on najniższy adres MAC – priorytet portów ma przypisaną domyślną wartość 128 (wszystkie interfejsy, wszystkich przełączników). Interfejsy f0/3 i f0/4 nie mogą pełnić roli root port gdyż koszt dotarcia do przełącznika S2 z poziomu tych portów wyniósłby 38. Koszt dla interfejsu f0/1 wynosi 19. Interfejsy f0/3 i f0/4 pełnią rolę portów desygnowanych. Rola została im przypisana ponieważ ich adresy MAC mają niższa wartość w porównaniu do adresów MAC sąsiada (przełącznik S3).

W przypadku przełącznika S3 jako root port został wybrany interfejs f0/1 gdyż adres MAC tego interfejsu jest najniższy a koszt dotarcia do root bridge wynosi 19. Tak jak w przypadku przełącznika S1 dwa jego interfejsy f0/3 oraz f0/4 nie mogły zostać root portami ponieważ koszt dotarcia do mostu z ich wykorzystaniem wynosi 38. Ponieważ interfejsy te są połączone z interfejsami pełniącymi już rolę portów desygnowanych ich stan został określony jako alternate port. Interfejsy te przez protokół STP zostały wyłączone jako te które by powodowały powstanie pętli.

Interfejsy, które przez protokół STP zostały również zablokowane to: interfejs f0/2 przełącznika S1 oraz interfejs f0/2 przełącznika S3. Przełączniki S1 i S3 mają już łączność z rootem tak więc każde kolejne fizyczne połączenie z przełącznikiem głównym zostanie zablokowane by uniemożliwić powstanie pętli.

Trasa pomiędzy przełącznikami został ustalona.

W tym scenariuszu nie ingerowaliśmy w wybór przełącznika głównego wszystkie ustalenia protokołu STP odbyły się z wykorzystaniem domyślnych wartości. Zadajmy pytanie – Jakie czynności należy wykonać aby root-em został przełącznik, który sam wybierzemy ?

Zadanie te możemy wykonać na dwa sposoby:

pierwszy sposób: wykorzystanie polecenia - spanning-tree vlan <id_VLAN> root primary
drugi sposób: wykorzystanie polecenia - spanning-tree <id_VLAN> priority <wartość>

Oba polecenia wydajemy w trybie konfiguracji globalnej. Załóżmy, że zależy nam aby to przełącznik S1 został rootem. Wydajmy więc pierwsze z poleceń.

Po wydaniu komendy sprawdźmy efekt jej wykonania. Jak można zauważyć switch S1 został przełącznikiem głównym.

Wykorzystajmy drugi z sposobów i sprawmy aby teraz switch S3 uzyskał status root-a. Zostało wydane polecenie: spanning-tree vlan 1 priority 20000 Jak można stwierdzić komenda nie została wykonana gdyż wartość priorytetu musi być wielokrotnością 4096. Poprawmy naszą komendę i spróbujmy wydać polecenie: spanning-tree vlan 1 priority 20480 Tym razem wydanie komendy kończy się sukcesem.

Sprawdzenie efektów przeprowadzonej konfiguracji przekonuje nas, że przełącznik S3 pełni teraz rolę roota.

Jak jest różnica pomiędzy poleceniami? Zacznijmy od końca – wykorzystanie polecenia: spanning-tree <id_VLAN> priority <wartość> wymusza na nas dobranie takiej wartości priorytetu by ta okazała się najniższa a tym samym pozwoliła switchowi na pełnienie roli przełącznika głównego (wartość priorytetu w przypadku PVST jest ustalana w obrębie VLAN-u). W przykładzie z wykorzystaniem komendy: spanning-tree vlan <id_VLAN> root primaryswitch sam zadba o takie dobranie wartości priorytetu by stać się przełącznikiem głównym.

Powróćmy do naszej początkowej konfiguracji w której to S2 pełni rolę roota i załóżmy, że z jakiś powodów nie odpowiada nam wybór trasy ustalonej pomiędzy switchem S3 i S2. Chcemy aby nowa trasa przesyłu pakietów uwzględniła interfejs f0/3 bądź f0/4 przełącznika S3 a tym samym by podróż pakietów odbywała się poprzez przełącznik S1.

Mówiąc może trochę prościej doprowadźmy do sytuacji w której to porty f0/1 oraz f0/2 przełącznika S3 zostaną zablokowane. Jak widać na zrzucie poniżej na razie mamy do czynienia z sytuacją odwrotną.

Aby zmienić drogę, podróży ramek musimy dokonać takiej modyfikacji kosztu ścieżki aby ta obecnie ustalona okazała się z punktu widzenia protokołu STP mniej korzystna. Dokonamy zmiany kosztu ścieżki dla interfejsów f0/1 oraz f0/2 przełącznika S3.

Zmianę kosztu ścieżki dokonujemy za pomocą polecenia: spanning-tree cost <wartość>. Polecenie wydajemy w trybie konfiguracji interfejsu. Wartość kosztu ścieżki z domyślnej 19 została zmieniona na 50. Aby powrócić do wartości domyślnej skorzystaj z polecenia: no spanning-tree cost

Po dokonanej zmianie konfiguracji porty f0/1 oraz f0/2 przełącznika zostają zablokowane. Koszt dotarcia za ich pośrednictwem do S2 wynosi 50 i jest wartością wyższą (mniej korzystną – pamiętamy, że w przypadku kosztu ścieżki preferowane są wartości niższe) niż w przypadku skorzystania z drogi poprzez przełącznik S1 – koszt trasy 19+19=38

Nasza topologia po tej zmianie przybiera następujący kształt.

Przy protokole STP w przypadku wykorzystania wielu łączy fizycznych możemy dokonać również zmiany aktualnie aktywnego kanału przesyłu danych (czytaj interfejsu, który będzie odpowiedzialny za przekazywanie ruchu sieciowego). Zmianę tą dokonujemy za pomocą zmiany priorytetu portu.

Powróćmy z powrotem do sytuacji w której to przełącznik S2 został wybrany przez protokół STP do pełnienia roli przełącznika głównego a komunikacja pomiędzy S2 i S3 odbywa się za pomocą interfejsów f0/1 oraz f0/2 przełącznika S3.

Konfiguracja zmiany priorytetów przełącznika zostanie wykonana na switchu S3.

Jak można zaobserwować poniżej aktywnym interfejsem przełącznika S3, który jest odpowiedzialny za przesyłanie ramek jest port f0/1 (jeszcze w stanie nasłuchiwania) natomiast blokowanym portem jest f0/2. Spróbujmy ten stan rzeczy zmienić i doprowadzić do sytuacji w której interfejsy zamienią się rolami tj. f0/1 będzie portem blokowanym natomiast f0/2 będzie interfejsem obsługującym ruch sieciowy.

Aby porty zamieniły się swoimi rolami musimy doprowadzić do sytuacji w której protokół STP stwierdzi, że korzystniejszą opcją będzie powierzenie roli root port interfejsowi f0/2. Aby scenariusz taki mógł mieć miejsce musimy zmodyfikować wartość priorytetu portu f0/2 na niższą niż ta która została przypisana interfejsowi f0/1 - oba interfejsy mają ustawioną domyślną wartość priorytetu portu na 128 (oczywiście sytuacja w której zwiększamy wartość priorytetu interfejsu f0/1 na większą niż ta posiadana przez interfejs f0/2 jest również jak najbardziej dozwolona). Wartość priorytetu portu obejmuje zakres od 0 do 255 a niższa wartość przez algorytm STP jest bardziej preferowana.

Aby dokonać zmiany wartości priorytetu należy posłużyć się poleceniem: spanning-tree port-priority <wartość_priorytetu>. Polecenie wydajemy w trybie konfiguracji interfejsu, nam zależy aby to interfejs f0/2 stał się portem komunikacyjnym tak więc komenda została wydana w linii poleceń tegoż interfejsu.

Po zmianie wartości priorytetu portu f0/2 z 128 na 112 możemy sprawdzić jakie zmiany zaszły w naszej topologii.

Zmiana priorytetu doprowadziła do zamiany ról portów. Interfejs f0/1 przełącznika S3 (wyższy priorytet) został zablokowany natomiast interfejs f0/2 (niższy priorytet) stał się root portem.

Modyfikację priorytetu portu można dokonać dla jednej lub większej liczby sieci VLAN. Modyfikacji tej dokonujemy poprzez dodanie opcjonalnego parametru vlan. Identyfikatory sieci VLAN są definiowane jako lista, której elementy oddzielamy przecinkami. Pominięcie parametru vlan spowoduje ustawienie wartości priorytetu dla wszystkich aktywnych sieci VLAN. Przykładowe polecenie: spanning-tree vlan 1, 10 port-priority 32 spowoduje zmianę priorytetu na 32, wartość ta będzie obowiązywać w sieciach VLAN o identyfikatorze 1 oraz 10 (pamiętamy o warunku: wartość priorytetu portu musi być wielokrotnością liczby 16).

Zanim przejdziemy dalej chciałbym przedstawić kilka poleceń systemu IOS, które bezpośrednio odnoszą się do protokołu STP a pozwolą nam one na uzyskanie informacji potrzebnych do zrozumienia omówionych zagadnień a dodatkowo przydadzą w dalszej części wpisu.

Za pomocą polecenia: show spanning-tree blockedports poznamy listę interfejsów, które w wyniku działania algorytmu drzewa rozpinającego zostały zablokowane.

Komendy: show spanning-tree bridge lub show spanning-tree root są odpowiedzialne za udzielenie informacji na temat przełącznika głównego. Za pomocą komend poznamy wartości zegarów STP.

Polecenie: show spanning-tree detail dostarcza bardzo szczegółowych informacji o interfejsach w kontekście działania protokołu STP.

Wydanie polecenia: show spanning-tree interface <id_interfejsu> dostarczy skróconych informacji na temat portu uczestniczącego w procesie STP. Informacje te dostarczają podstawowych informacji o protokole STP tj. informują o: bieżącym statucie portu, pełnionej roli, koszcie ścieżki czy priorytecie portu.

Wydanie komendy: show spanning-tree summary poinformuje nas o włączeniu takich funkcji jak PortFast, BPDU Guard, filtrowanie BPDU, UplinkFast czy BackboneFast (opis w dalszej części artykułu). A co najważniejsze uzyskamy dane o aktywnej wersji protokołu STP (na zrzucie poniżej przełącznik obsługuje tryb PVST – czyli STP z wsparciem dla sieci VLAN).

Zaś polecenie: show spanning-tree vlan 1 dostarczy nam informacji o parametrach protokołu STP obowiązujących w danej sieci VLAN.

W protokole STP mamy do czynienia z trzema zegarami (timerami) kontrolującymi przejście portu z jednego stanu do kolejnego. Przyjęte wartości zegarów zostały dobrane na wzorcowym rozmiarze sieci co oznacza, że dla małych sieci wartości te możemy zmienić na krótsze tak by zbieżność sieci została osiągnięta szybciej. Wzorcowy rozmiar sieci został przyjęty na 7 (ramka danych musi przejść drogę przez 7 przełączników) i dla takiej sieci wartości domyślne zegarów zostały przyjęte.

Modyfikację zegarów protokołu STP dokonujemy na przełączniku głównym gdyż tylko on jest odpowiedzialny za rozpowszechnienie tych informacji. Propagacja danych odbywa się poprzez wysłanie ramek BPDU (wartości zegarów swoje odzwierciedlenie znajdują w odpowiednich polach ramki BPDU).

Do czynienia mamy z następującymi zegarami:

Zegar Hello - odpowiedzialny za wyzwalanie okresowych komunikatów powitań. Domyślnie zegar został ustawiony na wartość 2 sekund a jego modyfikacja zawiera się w zakresie od 1 do 10 sekund. Zmiana wartości zegara powoduje wymuszenie na sąsiadach wysyłanie powitań w ustalonym odstępie czasu, oznacza to, że przełącznik główny będzie oczekiwał nadejścia ramek w zdefiniowanym interwale czasu. Modyfikację zegara hello dokonujemy za pomocą polecenia: spanning-tree hello-time <sekundy>

Zegar opóźnienia przesyłania (ang. forward delay) odpowiedzialny za czas potrzebny z przejścia z stanu nasłuchiwania do stanu uczenia się a także określa czas potrzebny by ze stanu uczenia się przejść do stanu przesyłania. Domyślna wartość zegara została ustawiona na 15 sekund a jego modyfikacja zawiera się w zakresie od 4 do 30 sekund. Wartość tego zegara powinna być starannie dobrana gdyż zależy ona od fizycznych rozmiarów naszej sieci, zbyt szybkie przejście portu z jednego stanu do drugiego może spowodować powstanie pętli. Zmianę wartości zegara dokonujemy za pomocą polecenia: spanning-tree forward-time <sekundy>

Zegar maksymalnego wieku (ang. max age) definiuje czas przechowywania jednostki BPDU, która została otrzymana od sąsiada. Po wygaśnięciu tego czasu port przełącznika zaczyna generować ramki BPDU konfiguracji. Wartość domyślna zegara to 20 sekund a zmiana zegara jest możliwa w zakresie od 6 do 40 sekund. Zmianę wartości zegara maksymalnego wieku dokonamy za pomocą polecenia: spanning-tree max-age <sekundy>

Wszystkie polecenia dotyczące zmiany domyślnych wartości zegarów protokołu STP dokonujemy w trybie konfiguracji globalnej.

W poleceniach tych należy dołączyć dodatkowy parametr vlan odpowiedzialny za definicję zegarów STP w określonych sieciach VLAN. Np. polecenie: spanning-tree vlan 1,10 hello-time <sekundy> spowoduje zmianę częstotliwości wysyłania komunikatów powitań w odniesieniu do sieci VLAN o identyfikatorze 1 oraz 10. Pominięcie parametru vlan (nie zawsze jest dozwolone, zależy od wersji systemu IOS) spowoduje ustawienie wartości zegarów dla wszystkich sieci VLAN bądź wygenerowanie błędu składni polecenia. Jeśli taka sytuacja nastąpi należy użyć i zdefiniować parametr vlan.

Zmianę zegarów STP przetestujemy na topologii zamieszczonej poniżej.

Przełączniki został włączone, algorytm STP wybrał root-a (przełącznik S2), wartości zegarów protokołu STP przyjęły domyślne wartości. Wartość przyjętych czasów poznamy po wydaniu polecenia: show spanning-tree

Spróbujmy dokonać modyfikacji wartości zegarów. Modyfikowane interwały czasu zostały ustalone na następujące wartości:

hello-time - 3 sekundy,
forward-time - 8 sekund,
max-age - 12 sekund.

Aby dostosować zegary do przyjętych wartości zostały wydane polecenia (komendy wydajemy oczywiście na przełączniku głównym a odnoszą się one do domyślnej sieci VLAN 1):

Po dokonanej zmianie wartości czasu poszczególnych zegarów, efekt zmian sprawdzimy wydając ponownie polecenie: show spanning-tree Wartości timerów zostały zmodyfikowane.

Zmianę zegarów dodatkowo możemy sprawdzić na innym z przełączników (poniżej zrzut konfiguracji protokołu STP przełącznika S1).

Jest jeszcze jeden ze sposobów aby dostosować zegary protokołu STP. Zastosowanie go nie wymaga od nas ręcznego określania wartości każdego z zegarów. Wcześniej wspomniałem, że wartości zegarów zostały ustanowione na wzorcowej sieci, której średnica odniesienia wynosi 7 przełączników. Załóżmy, że w naszej sieci pracują trzy przełączniki podłączone w trójkąt. Tak więc najdłuższą dostępną drogą jaką może zostać przesłana ramka danych jest ścieżka obejmująca wszystkie trzy przełączniki. Jest to mniej niż przyjęta wartość odniesienia. W naszym scenariuszu możemy przyjąć iż średnica naszej sieci wynosi 3 a dodatkowo by przełączniki jak najszybciej mogły wykryć brak sąsiada czas Hello Time zostaje skrócony do 1 sekundy. Aby wykonać przyjęte założenia należy wydać polecenie: spanning-tree vlan <id_VLAN> root primary diameter <średnica_sieci> hello-time 1

Wydanie polecenia spowoduje zmianę domyślnych zegarów protokołu STP na te odpowiadające przyjętej średnicy sieci a dodatkowo ustawi zegar Hello Time na 1 sekundę. Po wydaniu tej komendy switch na którym przeprowadzamy konfigurację zostaje rootem. Zmienione wartości zegarów zostały pokazana na zrzucie poniżej.

Funkcja ta odpowiada za pominięcie kliku stanów protokołu STP tak by jak najszybciej przejść do trybu w którym będzie można przekazywać ruch sieciowy. Funkcja PortFast stosowana jest w sytuacji w której do portu przełącznika podpięta jest stacja końcowa (komputer, drukarka sieciowa). Oznacza to, że funkcja ta powinna być stosowana tylko w warstwie dostępu. Funkcja ta w żadnym przypadku nie może być wykorzystana na interfejsie do którego podpięty jest inny przełącznik.

Wyobraźmy sobie sytuację w której host końcowy zostaje wyłączony (interfejs sieciowy hosta jest nie aktywny) port przełącznika za pomocą którego jest ustanowiona komunikacja z hostem przechodzi w stan nieaktywny. Powtórne włączenie hosta spowoduje uaktywnienie portu przełącznika lecz by mógł on pełnić swoją rolę i poprawnie przesyłać otrzymane ramki musi przejść przez wszystkie stany protokołu STP. Oznacza to, że za nim port zacznie przekazywać ramki (przy domyślnych zegarach STP) minie przynajmniej 30 sekund (15 sekund na nasłuchiwanie i uczenie się kolejne 15 sekund zostanie wykorzystane by przejść z stanu nasłuchiwania do transmitowania). Aby skrócić ten czas i by port przełącznika mógł natychmiast przesyłać dane należy na interfejsie przełącznika do którego host jest podłączony uaktywnić funkcję PortFast. Włączenie tego mechanizmu spowoduje skrócenie stanów nasłuchiwania i uczenia się tak by możliwe było natychmiastowe przesyłanie danych.

Po włączeniu mechanizmu PortFast wykrywanie pętli nadal działa, a interfejs przełącznika zostanie zablokowany w sytuacji w której pętla takowa zostanie wykryta. Pojedynczy host w większości przypadków takiej pętli nie utworzy (lecz jest wyjątek). Wyjątkiem tym może być sytuacja w której np. w systemie Windows poprzez dodatkowy interfejs jest zapewniona inna droga połączenia z siecią a dodatkowo na hoście jest uruchomiona funkcja: Połączenia mostkowe. Opisana sytuacja jest dość specyficznym wariantem konfiguracji systemu i spotykana jest niezmiernie rzadko lecz warto o takim wariancie pamiętać.

Domyślnie na wszystkich portach przełącznika mechanizm PortFast jest wyłączony. Aby go uaktywnić można skorzystać z dwóch rozwiązań.

Rozwiązanie pierwsze uaktywnia funkcję PortFast na wszystkich portach pracujących w trybie dostępu (access). Oznacza to, że polecenie pominie interfejsy na których został ustanowiony tryb trunk (łącze magistrali). Aby włączyć PortFast należy w trybie konfiguracji globalnej wydać polecenie: spanning-tree portfast default

Drugie rozwiązanie sprowadza się do włączenia funkcji PortFast na każdym z interfejsów z osobna. Polecenie nakazujące włączenie PortFast wydajemy w trybie konfiguracji interfejsu - spanning-tree portfast

Jest i trzeci sposób - opis w tekście poniżej.

Wyłączenie mechanizmu PortFast odbywa się za pomocą polecenia: no spanning-tree portfast wydanego w trybie konfiguracji interfejsu.

Topologia dla scenariusza PortFast przedstawia się następująco:

Jak widać powyżej pomiędzy wszystkimi przełącznikami zostało zestawione łącze trunk natomiast do dwóch interfejsów - przełącznik S1 port f0/6 oraz przełącznik S3 port f0/18 zostały podłączone hosty. Łącza te pracują w trybie dostępu. Hosty (a raczej interfejsy przełącznika do których są podłączone) zostały przypisane do sieci VLAN o identyfikatorze 10.

Polecenie: show interfeces trunk wydane na przełączniku S1 przedstawia wszystkie interfejsy pracujące w trybie magistrali (trunk).

Dla przypomnienia, również komenda: show interfaces <id_portu> switchport pokaże nam bieżący status portu. Poniżej został ukazany stan interfejsu f0/1 przełącznika S1. Interfejs ten pracuje w trybie trunk (zresztą jak również interfejs f0/3).

Wydanie tej samej komendy w odniesieniu do interfejsu f0/6 ukaże nam iż interfejs ten został skonfigurowany w trybie dostępu (do portu zostało podłączone urządzenie końcowe).

Sprawdźmy stan skonfigurowany portów pod kątem mechanizmu PortFast. Wydanie polecenia: show spanning-tree interface <id_portu> portfast uwidoczni status funkcji.

Poniżej dla przełącznika S1 i jego interfejsów f0/1 oraz f0/6, mechanizm PortFast jest nieaktywny. Host podłączony do interfejsu f0/6 i należący do sieci VLAN 10 z funkcji PortFast nie korzysta.

Uaktywnijmy PortFast korzystając z pierwszego rozwiązania a mianowicie uruchamiając go z wykorzystaniem polecenia: spanning-tree portfast default PortFast powinien zostać uruchomiony na wszystkich interfejsach dostępowych.

Po wydaniu polecenia jesteśmy ostrzeżeni o konsekwencjach podłączenia do interfejsu na którym została uaktywniona funkcja PortFast przełącznika bądź huba - podłączenie takowego urządzenia spowoduje powstanie pętli.

Po uaktywnieniu PortFast sprawdźmy stan mechanizmu. Ponowne wydanie polecenia: show spanning-tree interface <id_portu> portfast ukaże nam włączony interfejs f0/6 przełącznika S1, na którym działa funkcja PortFast.

Ten sam efekt zostałby by uzyskany gdybyśmy w trybie konfiguracji interfejsu f0/6 wydali polecenie: spanning-tree portfast

Jest jeszcze jeden sposób, który pozwoli nam włączyć PortFast na porcie a mianowicie wykorzystanie polecenia: switchport host Komendę wydajemy w trybie konfiguracji interfejsu. Tak naprawdę wydanie polecenia spowoduje wykonanie trzech osobnych instrukcji (dość wygodne gdyż nie musimy wykonywać tego osobnymi komendami):

Uaktywniona zostanie funkcja PortFast,
Interfejs przełącznika ustawiany jest w trybie dostępu,
Wyłączany jest protokół PAgP odpowiedzialny za zestawienie kanału EtcherChannel (o EtcherChannel możesz przeczytać w moimi wcześniejszym wpisie: http://slow7.pl/sieci-komputerowe/item/112-co-w-sieci-siedzi-agregacja-laczy-przelacznika).

Poniżej na rysunku za pomocą polecenia: switchport host został skonfigurowany interfejs f0/18 przełącznika S3.

Sprawdzenie stanu mechanizmu PortFast uwidacznia, że interfejs został skonfigurowany poprawnie.

Dodatkową weryfikację stanu włączenia bądź wyłączenia funkcji PortFast możemy dokonać za pomocą polecenia: show spanning-tree vlan <id_VLAN> Na rysunku poniżej w tabeli w kolumnie Type przy interfejsie f0/18 pojawił się wpis Edge oznaczający aktywność PortFast na danym interfejsie.

Poleceniem, które również pozwoli nam na zweryfikowanie stanu PortFast jest polecenie: show spanning-tree detail Po wydaniu polecenia zostanie przedstawiona konfiguracji protokołu STP w odniesieniu do konkretnych interfejsów przełącznika i ich przynależności do konkretnych sieci VLAN.

Aby uzyskać informacje w kontekście jednego konkretnego interfejsu można posłużyć się poleceniem: show spanning-tree interface <id_portu> detail

Poniżej na zrzucie został ukazany stan interfejsu f0/18. Analiza informacji uzyskanych po wydaniu polecenia przekonuje nas iż na porcie tym aktywna jest funkcja PortFast. Dodatkowo można zauważyć, że pomimo uaktywnienia mechanizmu port nadal odbiera i wysyła ramki BPDU. Spowodowane to jest nadal aktywnym wykrywanie ewentualnych pętli.

Z mechanizmem PortFast związana jest jeszcze jedna funkcja a mianowicie BPDU Guard. BPDU Guard jest funkcją, która chroni interfejs przełącznika przed otrzymywaniem ramek BPDU na portach, na których nie powinny się takowe ramki pojawić. Funkcja ta stanowi jeden z elementów podwyższających bezpieczeństwo naszego przełącznika, gdyż można wyobrazić sobie atak w warstwie drugiej przeprowadzony z wykorzystaniem protokołu STP. Atakujący mógłby wykorzystać zestawione do hosta połączenie aby w miejsce hosta podłączyć przełącznik bądź użyć oprogramowania potrafiącego wygenerować fałszywe ramki BPDU (np. stp-packet, brconfig, scapy czy yersinia)

Atak na STP zwykle wiąże się ze zmianą przełącznika głównego na ten kontrolowany przez atakującego. Wspomniane programy mogą zostać wykorzystane do wysłania fałszywych komunikatów STP. Atakujący host poprzez rozgłoszenie komunikatów BPDU stara się wymusić ponowne przeliczenie algorytmu spanning-tree. BPDU generowane przez fałszywego hosta ogłaszają niższe wartości priorytetu tak, aby atakujący host został wybrany jako root. W przypadku powodzenia ataku i wybrania fałszywego przełącznika root-em uzyskujemy dostęp do informacji, które by były nie osiągalne w inny sposób.

Jeśli port skonfigurowany jako PortFast i z włączoną opcją BPDU Guard zacznie otrzymywać ramki BPDU, switch automatycznie zablokuje ten port (przełączy go w stan errdisable). Po przejściu portu w ten stan administrator ręcznie musi go uaktywnić (możliwe jest również skonfigurowanie tzw. errdisable timeout czyli czasu, po minięciu którego, port powraca do stanu normalnego funkcjonowania).

Aby włączyć BPDU guard na wszystkich portach z włączoną opcją PortFast, korzystamy z polecenia: spanning-tree portfast bpduguard default Polecenie wydajemy w trybie konfiguracji globalnej.

BPDU Guard możemy również włączyć na interesującym nas interfejsie z wykorzystaniem polecenia: spanning-tree bpduguard enable Komendę oczywiście wydajemy w trybie konfiguracji interfejsu.

Przeprowadźmy więc mały test zbudujmy bardzo prostą konfigurację opartą na schemacie zamieszczonym poniżej.

Interfejs f0/3 przełącznika pracuje w trybie dostępu a dodatkowo na porcie została włączona funkcja PortFast oraz BPDU Guard.

Jak widać poniżej na zrzucie po wydaniu polecenia: show spanning-tree interface f0/3 detail obie funkcje są włączone.

W scenariuszu do interfejsu f0/3 jest podłączony host. Aby mieć możliwość wysłania komunikatów BPDU, host zostaje zamieniony na przełącznik. Po dokonanej zmianie nowo podłączony przełącznik zaczyna wysyłać ramki BPDU. Na skutek włączonej funkcji BPDU Guard interfejs f0/3 przełącznika S1 przechodzi do stanu errdisable.

Informacje o interfejsach wyłączonych na skutek włączonych mechanizmów zabezpieczeń uzyskamy po wydaniu polecenia: show interfaces status err-disabled

Funkcja BPDU Guard zablokowała port.

Jak wcześniej wspominałem funkcję PortFast oraz BPDU Guard można aktywować globalnie tak by domyślnie oba mechanizmy były włączone.

Poniżej na rysunku włączenie obu funkcji na przełączniku S1.

Status funkcji poznamy po wydaniu polecenia: show spanning-tree summary totals

Z mechanizmem PortFast związana jest także funkcja filtrowania BPDU. Opcja ta zabezpiecza interfejsy w trybie PortFast przed odbieraniem i wysyłanie komunikatów BPDU. Tak więc filtrowanie uniemożliwia wysyłanie i przetwarzanie ramek BPDU na portach przełącznika.

Opcja ta, może być skonfigurowana globalnie lub na poziomie interfejsu.

Filtrowanie domyślnie jest wyłączone na wszystkich interfejsach przełącznika. Aby automatycznie włączyć BPDU filtering na wszystkich interfejsach z aktywnym PortFast korzystamy z polecenia: spanning-tree portfast bpdufilter default Polecenie wydajemy w trybie konfiguracji globalnej. W przypadku interfejsów, które nie korzystają z PortFast filtrowanie nie zostanie włączone. Uruchomienie filtrowania w ten sposób spowoduje wyłączenie wysyłania ramek BPDU w kierunku hostów. W przypadku pojawienia się ramek BPDU interfejs traci status PortFast i filtrowanie BPDU zostaje wyłączone.

Włączenie filtrowania BPDU w trybie konfiguracji interfejsu odbywa się za pomocą polecenia: spanning-tree bpdufilter enable Uaktywnienie opcji spowoduje wyłączenie na interfejsie protokołu spanning-tree co może doprowadzić do powstania pętli.

Weryfikację filtrowania BPDU przeprowadzimy za pomocą poleceń: show spanning-tree summary oraz show spanning-tree interface <id_interfejsu> detail.

Aby jeszcze podwyższyć ochronę protokołu STP można skorzystać z dodatkowej funkcji jaką jest Root guard. Mechanizm ten umożliwia nam kontrolę nad wyborem przełącznika głównego. Kontrola ta realizowana jest poprzez ograniczenie portów przełącznika, na których będzie realizowany proces negocjacji. Na interfejsie przełącznika z skonfigurowaną funkcją Root guard otrzymane komunikaty BPDU z wartościami lepszymi będą ignorowane. Po otrzymaniu takich ramek port switcha przełączy się do stanu root-inconsistent. Oznacza to, że interfejs nie bierze udziału w przekazywaniu ruchu sieciowego. Port zostanie przywrócony do normalnego stanu tylko wtedy gdy na interfejsie przestaną pojawiać się komunikaty BPDU wymuszające na przełączniku zmianę roota.

Podsumowując, mechanizm Root guard powinien być włączany na interfejsach przełącznika, do których podłączone są inne switche, które nigdy nie powinny zostać rootami.

Root guard uaktywniamy za pomocą polecenia: spanning-tree guard root wydanego w trybie konfiguracji interfejsu.

To tradycyjnie już mały przykład. Załóżmy, że mamy o to taką prostą topologię złożoną z dwóch przełączników.

Przełącznik S1 jest rootem.

Oba przełącznik są ze sobą połączone za pomocą interfejsu f0/3. Na przełączniku S1 zostaje uaktywniona funkcja Root guard. Włączenie funkcji zabroni przełącznikowi S2 zostanie przełącznikiem głównym. O włączeniu Root guard dodatkowo jesteśmy poinformowani stosownym komunikatem w linii CLI przełącznika.

Dodatkowo weryfikację włączenia funkcji możemy przeprowadzić za pomocą polecenia: show spanning-tree interface <id_interfejsu> detail Na porcie f0/3 przełącznika S1 została uaktywniona funkcja Root guard.

Wymuśmy sytuację w której to przełącznik S2 będzie chciał zostać root-em. Na przełączniku S2 zostaje wydane polecenie: spanning-tree vlan 1 root primary Efekt wydania polecenia powinien być taki iż przełącznik S2 powinien zacząć pełnić rolę przełącznika głównego.

Tak się nie dzieje gdyż mechanizm Root guard uaktywniony na switchu S1 wykrywa ramki BPDU nakazujące zmienić status pełnionej roli i zaczyna blokować interfejs f0/3. Informacja o zablokowaniu portu f0/3 zostaje nam przekazana poprzez komunikat w linii CLI przełącznika.

Sprawdzenie statusu portu f0/3 dostarcza nam informacji iż port f0/3 nie działa - status portu został ustanowiony na tzw. stan root inconsistent

Port f0/3 w stanie root inconsistent będzie tak długo pozostawał aż przestaną napływać ramki BPDU o parametrach STP lepszych niż te które zostały przypisane przełącznikowi S1.

Aby zaprzestać wymuszenie zmiany root-a na przełączniku S2 zostaje wydane polecenie: no spanning-tree vlan 1 root primary

Po wydaniu polecenia port f0/3 przełącznika S1 przechodzi z stanu blokowania do stanu normalnego funkcjonowania. O fakcie tym jesteśmy poinformowani komunikatem.

Ponowne sprawdzenie stanu interfejsu potwierdza otrzymaną informację. Port f0/3 uczestniczy w procesie przekazywania danych. Zostało przywrócone normalne funkcjonowanie portu.

Tak więc by zakończyć temat ochrony protokołu STP na koniec krótkie porównanie BPDU guard i Root guard.

BPDU guard spowoduje wyłączenie interfejsu przełącznika (stan errdisable) po otrzymaniu komunikatu BPDU jeśli na porcie uaktywniono PortFast. Ponowne włączenie portu musi zostać wykonane przez administratora.

Root guard pozwala innym przełącznikom uczestniczyć w STP, uczestnictwo trwa tak długo, póki dane urządzenie nie stara się zostać rootem. Normalne funkcjonowanie portu jest przywracane automatycznie po zaprzestaniu otrzymywania ramek BPDU wymuszających zmianę roota a które to mogą być np. efektem przeprowadzanego ataku.

Z protokołem STP związana jest jeszcze jedna funkcja - UplinkFast. Mechanizm ten został zaprojektowany z myślą o przełącznikach pracujących w warstwie dostępowej. Przełączniki pracujące w tej warstwie celem redundancji łącz z reguły są połączone wieloma łączami pomiędzy sobą a dodatkowo mają zestawione łącza pozwalające dotrzeć do przełączników pracujących w warstwie dystrybucji. W domyślnej konfiguracji awaria łącza powoduje przejęcie zadań przez inny interfejs przełącznika. Aby port mógł uczestniczyć w przekazywaniu ruchu sieciowego musi przejść wszystkie stany algorytmu STP. Cały proces uzyskania zbieżności może potrwać około 45 sekund bądź dłużej (wszystko zależy od konfiguracji naszej sieci). Mechanizm UplinkFast pozwala interfejsowi będącemu w trybie alternate port pominąć stany listening (stan nasłuchiwania) oraz learning (uczenie się) tak by od razu przejść do przekazywania danych. Z czasu 45 sekund przy ustawieniach domyślnych możemy zejść do 5 sekund przy aktywnym UplinkFast.

Aby włączyć UplinkFast na przełączniku należy w trybie konfiguracji globalnej wydać polecenie: spanning-tree uplinkfast

Funkcja ta powinna być aktywowana tylko na przełącznikach pracujących w warstwie dostępowej a w żadnym przypadku na switchach pracujących w warstwie dystrybucji bądź rdzenia ponieważ uruchomienie mechanizmu uniemożliwi przełącznikowi zostanie rootem. Włączenie UplinkFast spowoduje ustawienie priorytetu na wartość wynoszącą 49152 (zmiana dotyczy wszystkich sieci VLAN), zmianie również ulegną koszty łączy (koszt zostanie zmieniony na wartość 3019). Dokonane zmiany możemy zaobserwować po wydaniu polecenia: show spanning-tree

Weryfikację UplinkFast dokonujemy za pomocą polecenia: show spanning-tree summary totals Jak widać poniżej funkcja jest włączona.

Wyłączenie UplinkFast następuje po wydaniu polecenia: no spanning-tree uplinkfast Komenda cofa wszystkie modyfikacje priorytetów i kosztów łącza.

Tak więc na tym etapie rozważania na temat protokołu STP chciałbym zakończyć tak by w którymś z kolejnych wpisów zająć się protokołami PVST czy RSTP.

Konfiguracja połączenia VPN w środowisku Windows lecz nie tylko.

2016-03-26T19:57:25+00:00

W dobie coraz większej inwigilacji i ochrony swojej prywatności wielu użytkowników decyduje się na korzystanie z sieci Internet za pośrednictwem połączenia VPN. Lecz czym tak naprawdę ten VPN jest? Wikipedia definicję VPN-u określa jako:

„VPN (ang. Virtual Private Network, Wirtualna Sieć Prywatna) – tunel, przez który płynie ruch w ramach sieci prywatnej pomiędzy klientami końcowymi za pośrednictwem publicznej sieci (takiej jak Internet) w taki sposób, że węzły tej sieci są przezroczyste dla przesyłanych w ten sposób pakietów. Można opcjonalnie kompresować lub szyfrować przesyłane dane w celu zapewnienia lepszej jakości lub większego poziomu bezpieczeństwa. Określenie „wirtualna” oznacza, że sieć ta istnieje jedynie jako struktura logiczna działająca w rzeczywistości w ramach sieci publicznej, w odróżnieniu od sieci prywatnej, która powstaje na bazie specjalnie dzierżawionych w tym celu łącz. Pomimo takiego mechanizmu działania stacje końcowe mogą korzystać z VPN dokładnie tak, jak gdyby istniało pomiędzy nimi fizyczne łącze prywatne.”

I tak naprawdę definicja ta w sposób dokładny opisuje mechanizm i sens wdrożenia tej technologii. Lecz nie wspomniano w niej o jeszcze jednej kwestii szczególnie ważnej z punktu działania firm.

Zdalny dostęp do sieci firmowej i jej zasobów stał się elementem kluczowym dla wielu firm bez którego wielu pracowników nie mogłoby realizować swoich podstawowych zadań. Odeszliśmy już od modelu w którym pracownik by uzyskać np. dostęp do swoich plików musiał znajdować się fizycznie w oddziale firmy teraz za pośrednictwem odpowiednio skonfigurowanej infrastruktury sieciowej może tego dokonać z dowolnego miejsca na świecie pod warunkiem, że ma się dostęp do Internetu. Tak więc z punktu widzenia firmy, pracowników i wykonywanych obowiązków największą zaletą tworzenia połączeń VPN jest możliwość zdalnej pracy tak jak by się znajdowało przy własnym biurku.

A dodatkowo dzięki zastosowaniu szyfrowania uzyskujemy bezpieczne połączenie z Internetem korzystając z niezabezpieczonej sieci bezprzewodowej w miejscach użyteczności publicznej.

Dla niektórych osób argumentem, który ma niebanalne znaczenie jest możliwość uzyskania adresu IP zgodnego z wybraną lokalizacją geograficzną. Oznacza to możliwość uzyskania adresu IP przynależnego np. USA. Takie podejście do sprawy sprawi, że otrzymamy dostęp do usług przynależnych danemu regionowi. Przykład proszę bardzo – od niedawna Polacy otrzymali dostęp do usługi VOD Netflix (dla niewtajemniczonych wypożyczalnia filmów online) a jeszcze do niedawna było to niemożliwe gdyż Netflix oficjalnie na naszym terenie usług tego typu nie prowadził. Oznaczało to brak możliwości rejestracji w serwisie dla osób nie będących obywatelami USA. Część użytkowników by ominąć te ograniczenie za pośrednictwem łącza VPN łączyło się z serwerem amerykańskim, dzięki temu komputer otrzymywał adres IP zgodny z lokalizacją geograficzną a otrzymanie takiego adresu IP gwarantowało dostęp do usług serwisu video (serwery Netflixa odnotowywały rejestrację z obszaru USA).

Aby rozwiać jeszcze wątpliwości co do sposobu działania mechanizmu VPN przeanalizujmy przykład, który został zaprezentowany na rysunku poniżej.

Z połączenia z Internetem korzysta dwóch użytkowników: Beata i Jan.

Beata dostęp do sieci realizuje w sposób tradycyjny tj. ma wykupione łącze u lokalnego dostawcy ISP (dostawca usług internetowych) i dzięki połączeniu z nim może przeglądać zasoby sieci. Nie wykorzystuje mechanizmu VPN. Oznacz to, że cały ruch sieciowy dla dostawcy jest przezroczysty tak więc indeks odwiedzanych miejsc, pobranych plików znajduje swoje odzwierciedlenie w logach ISP. Dodatkowo informacja ta jest odnotowana na serwerach docelowych z którymi użytkownik Beata nawiązała połączenie.

Drugi użytkownik Jan pomimo wykupienia łącza u swojego provaidera dodatkowo zdecydował się na realizację połączenia z siecią za pośrednictwem bramy VPN. Dzięki wykorzystaniu tunelu VPN, ISP Jana wie jedynie, że Jan uzyskał połączenie z bramą VPN lecz nie widzi jaki konkretnie ruch sieciowy jest prowadzony. Komunikacja pomiędzy Janem a serwerem VPN jest zaszyfrowana.

Dodatkowo serwery docelowe odnotowują aktywność w postaci przeglądanych stron i pobranych plików lecz administrator serwera nie jest w stanie określić iż to właśnie Robert dane treści przegląda, gdyż wszystkie działania w imieniu Roberta podejmuje serwer VPN i to informacje o jego adresie IP znajdą się w logach serwerów końcowych.

Tak więc myślę, że ten praktyczny przykład w sposób dość obrazowy ilustruje mechanizm działania połączeń VPN oraz sens ich stosowania.

Rozróżniamy dwa podstawowe rodzaje sieci VPN:

Site - to - Site - połączenie VPN jest tworzone pomiędzy dwiema odległymi sieciami LAN. Urządzeniami realizującymi połączenie może być router z obsługą połączeń VPN bądź firmowy serwer. Przykładem połączenia Site - to - Site jest połączenie oddziałów firmy z centralą.

Client - Site - tunel VPN zestawiany jest np. pomiędzy komputerem zdalnego użytkownika a siecią LAN. Przykładem takiego połączenia jest sytuacja w której pracownik firmy będąc poza jej siedzibą musi mieć dostęp do zasobów znajdujących się w sieci firmowej (pliki, oprogramowanie, bazy danych itp.).

W artykule w głównej mierze będziemy zajmować się połączeniami typu Client - Site lecz na samym końcu pokarzę przykład połączenia Site - to - Site.

Przy konfiguracji połączenia VPN będziemy mieli do czynienia z różnymi protokołami odpowiedzialnymi za zestawienie łącza więc poniżej krótka ich charakterystyka.

Protokół SSTP (ang. Secure Socket Tunneling Protocol) Protokół SSTP został wprowadzony wraz z systemem Windows Vista SP1 oraz Windows Server 2008 umożliwiając przekazywanie ruchu poprzez zapory blokujące ruch PPTP i L2TP/IPsec. Protokół ten umieszcza ramki protokołu PPP w ramkach protokołu HTTP umożliwiając realizowanie połączeń VPN w sytuacjach gdy klient znajduje się poza firewallem, urządzeniem z obsługą translacji adresów sieciowych (NAT) lub serwerem proxy. Użycie protokołu umożliwia obsługę metod silnego uwierzytelniania, takich jak EAP-TLS. Korzystanie z HTTPS oznacza, że ruch przekazywany jest przez port 443 protokołu TCP, czyli powszechnie używany port dostępu do sieci Web. Protokół SSL (Secure Sockets Layer) zapewnia bezpieczeństwo na poziomie transportu wraz z rozszerzonymi metodami negocjacji klucza, szyfrowania i sprawdzania integralności.

Zalety:

- bardzo bezpieczny,

- pełna integracja z środowiskiem Windows (Windows Vista z dodatkiem SP1, Windows 7, Windows 8, Windows 10),

- ruch sieciowy protokołów odpowiedzialnych za działanie kanału VPN nie jest blokowany przez zapory sieciowe.

Wady:

- brak wsparcia dla innych systemów.

OpenVPN jest pakietem oprogramowania, które umożliwia nam utworzenie połączeń VPN. Biblioteki odpowiedzialne za działanie programu umożliwiają utworzenie zaszyfrowanych połączeń z wykorzystaniem protokołów SSLv3/TLSv1. Co ważne oprogramowania tego możemy użyć w trybie serwera umożliwiając klientom podłączenie się i korzystanie z tunelu VPN bądź trybie klienta. Jak to fajnie opisano (źródło: http://sekurak.pl/praktyczna-implementacja-sieci-vpn-na-przykladzie-openvpn/) „OpenVPN zapewnia nam komplet mechanizmów, który pozwala nam zbudować bezpieczną sieć VPN – autoryzuje, uwierzytelnia, szyfruje i zapewnia integralność przesłanych danych. Ponadto chroni serwer (koncentrator) przed atakami DoS oraz sieć wirtualną przed wstrzykiwaniem obcych danych. Wszystkie te rzeczy powodują, że OpenVPN jest doskonałym wyborem do większości zastosowań.”

Oprogramowanie OpenVPN to tak naprawdę temat sam w sobie i zasługuje na osobny wpis (jest w planach) co warto zaznaczyć, że warto korzystać z tego rozwiązania gdy tylko mamy taką możliwość. W wpisie tym o technologię tą ocierać się będziemy często lecz wykorzystamy tylko jedną funkcjonalność oprogramowania a mianowicie tworzenie połączenia VPN od strony klienta (serwerowymi aspektami w tym artykule zajmować się nie będziemy).

Zalety:

- wysoka elastyczność konfiguracji,

- bardzo bezpieczny,

- brak problemów z konfiguracją reguł firewalla,

- szeroki wybór algorytmów szyfrowania,

- Open Source - łatwość weryfikacji kodu i działania narzędzia,

- oprogramowanie jest dostępne dla systemów mobilnych co do nie dawna stanowiło problem.

Wady:

- Do poprawnego działania wymagana jest instalacja oprogramowania firm trzecich, brak wsparcia od strony systemów,

Protokół L2TP (ang. Layer Two Tunneling Protocol) Protokół ten jest powszechnym standardem pozwalającym na ustanowienie kanału VPN. Protokół L2TP jest połączeniem protokołów PPTP oraz L2F (ang. Layer 2 Forwarding), powstał w wyniku współpracy firm Cisco i Microsoft. Z protokołem L2TP bardzo często skojarzany jest protokół IPSec, taki połączenie znane jest jako L2TP over IPSec. Połączenie protokołów przyniosło same zalety gdyż sam protokół L2PT zyskał możliwość uwierzytelnienia zaś protokół IPSec rozszerzył swoją funkcjonalność o obsługę nie tylko pakietów IP. Protokół L2TP/IPsec został opisany w dokumencie RFC 2661.

Zalety:

- bezpieczniejszy niż PPTP,

- łatwa konfiguracja,

- klient dostępny na wszystkich nowoczesnych platformach,

- szybszy niż OpenVPN.

Wady:

- może być zagrożony przez NSA (niesprawdzone).

Protokół PPTP (ang. Point-to-Point Tunneling Protocol) jest jednym z najstarszych sposobów pozwalających nam na tworzenie wirtualnych sieci prywatnych. Protokół został opracowany przez firmę Microsoft.

Zalety:

- klient obecny na wszystkich platformach systemowych,

- bardzo łatwa konfiguracja połączenia,

- szybkość działania.

Wady:

- nie gwarantuje odpowiedniego stopnia zabezpieczeń.

I jeszcze jako podsumowanie wstępu, krótkie zebranie najważniejszych cech protokołów (źródło: http://vpnonline.pl/protokoly-vpn-porownanie oraz http://b1s.eu/pl/bez-kategorii/945-porownanie-protokolow-vpn.html).

	STANDARD VPN PPTP	STANDARD VPN IPsec	STANDARD VPN L2TP	SECURE VPN OpenVPN	SECURE VPN SSTP
Poziom szyfrowania	128 BIT	128 BIT	128 BIT	256 BIT	256 BIT
Wspierany system	WindowsLinux iOS Android Windows Phone Mac OS X	Windows Linux iOS Android Windows Phone Mac OS X	Windows Linux iOS Android Windows Phone Mac OS X	Windows Linux iOS Android Mac OS X	Windows Linux BSD
Kompatybilność	Komputery, smartfony, tablety	Komputery, smartfony, tablety	Komputery, smartfony, tablety	Komputery, smartfony, tablety	Komputery
Bezpieczeństwo	Podstawowe szyfrowanie do 128bit.	Mocne szyfrowanie. Dodatkowo opakowuje dane przez protokół IPsec do 128bit.	Mocne szyfrowanie. Dodatkowo opakowuje dane przez protokół IPsec do 128bit.	Bardzo mocne szyfrowanie za pomocą certyfikatów do 256bit	Bardzo mocne szyfrowanie za pomocą certyfikatów do 256bit
Szybkość	Bardzo szybki ze względu na podstawowe szyfrowanie	Wymaga więcej procesora do szyfrowania danych	Wymaga więcej procesora do szyfrowania danych	Najlepsza wydajność. Bardzo szybki nawet na połączeniach z dużym opóźnieniem	Najlepsza wydajność. Bardzo szybki nawet na połączeniach z dużym opóźnieniem
Konfiguracja	Bardzo prosta. Nie wymaga dodatkowego oprogramowania.	Prosta, wymaga dodatkowych ustawień. Nie wymaga dodatkowego oprogramowania	Prosta, wymaga dodatkowych ustawień. Nie wymaga dodatkowego oprogramowania	Wymagane dodatkowe oprogramowanie. Wymagana instalacja certyfikatów	Protokół wbudowany w Windows Vista, Windows 7. Wymagana instalacja certyfikatów
Używane porty	TCP 1723 - inicjalizacja GRE	UDP 1701 UDP 500 - kanał wymiany klucza UDP 4500 ESP (protokół numer 50) dokument RFC 2406	UDP 1701 UDP 500 - kanał wymiany klucza UDP 4500 ESP (protokół numer 50) dokument RFC 2406	TCP 993 TCP 443	TCP 443
Podsumowanie	PPTP - Point to Point Tunneling Protocol. Najbardziej rozpowszechniony protokół najbardziej podatny na błędy. PPTP jest szybki i bardzo prosty w konfiguracji. Jest to dobry wybór jeżeli twoje urządzenie nie wspiera OpenVPN lub SSTP VPN. Rekomendowany dla urządzeń mobilnych.	IPsec IP Security. Istotną cechą tego protokołu jest jednokierunkowość. Pełna łączność wykorzystuje dwa kanały jeden od A do B drugi od B do A. L2TP/IPsec jest to dobry wybór jeżeli twoje urządzenie nie wspiera OpenVPN lub SSTP VPN i zależy ci na dużym bezpieczeństwie. Rekomendowany dla urządzeń mobilnych.	IPsec IP Security. Istotną cechą tego protokołu jest jednokierunkowość. Pełna łączność wykorzystuje dwa kanały jeden od A do B drugi od B do A. L2TP/IPsec jest to dobry wybór jeżeli twoje urządzenie nie wspiera OpenVPN lub SSTP VPN i zależy ci na dużym bezpieczeństwie. Rekomendowany dla urządzeń mobilnych.	OpenVPN jest bardzo szybkim, bezpieczny, bardzo stabilnym i rekomendowanym protokołem dla systemów Windows , Linux i Android. Zapewnia najwyższa wydajność, bezpieczeństwo i niezawodność. Używanie OpenVPN przez UDP jest szybsze niż przez TCP.	SSTP (Secure Socket Tunneling Protocol) VPN jest rekomendowanym protokołem dla systemów Windows. Najwyższa wydajność, bezpieczeństwo i niezawodność. Korzysta z protokołu SSL na porcie TCP 443 pozwala SSTP przejść przez praktycznie wszystkie firewalle i serwery proxy. PPTP nie wymaga użycia infrastruktury klucza publicznego (PKI).

Wprowadzenie uważam za zakończone przejdźmy zatem dalej i już na konkretnych przykładach omówmy sposób konfiguracji i zestawiania połączenia VPN. Rozpoczniemy od systemu Windows 10 by w kolejnych krokach omówić i opisać systemy: Windows Phone, IOS oraz Android. System Linux został przeze mnie celowo pominięty gdyż chciałbym temat opisać w osobnym wpisie i skupić się na OpenVPN z naciskiem na funkcję bramy (komputer realizuje połączenia w imieniu klienta).

Przedstawione w tym wpisie przykłady konfiguracji połączeń VPN opierać się będą o usługi oferowane przez Private Internet Access (nie jest to żadna reklama lecz akurat z usług tej firm korzystam).

System Windows 10

Aby w systemie Windows 10 skonfigurować połączenie VPN należy kliknąć na ikonę Centrum Akcji i z dostępnych ikon wybrać VPN.

Opcjonalnie do opcji odpowiedzialnych za zestawienie kanału VPN możemy dostać się po wybraniu ikony Sieć i Internet dostępnej w oknie Ustawienia (skrót Win+I)

Po otwarciu nowego okna z dostępnych zakładek odszukujemy kartę VPN i z dostępnych opcji wybieramy Dodaj połączenie VPN.

Dodatkowo na karcie tej możemy zdefiniować opcje użycia połączenia VPN:

Zezwalaj na połączenia VPN w sieciach taryfowych – dostęp do Internetu może być świadczony przez ISP, który nalicza opłaty za ilość wykorzystanych danych (tj. za ilość danych wysłanych i odebranych). Takie połączenie jest wówczas traktowane jako połączenie taryfowe (najczęściej tego typu połączenie jest realizowane dzięki wykorzystaniu sieci komórkowych). Łącza tego typu po przekroczeniu ustalonego limitu bardzo często są ograniczane tj. nadal można cieszyć się z połączenia z Internetem lecz już nie z pełną prędkością bądź zostanie nam naliczona dodatkowa opłata za ilość danych wykorzystanych poza ustalonym limitem. Opcja ta pozwala nam ustawić czy połączenie VPN może być zestawione w przypadku wykrycia korzystania z tego typu sieci.

Zezwalaj na połączenia VPN podczas korzystania z roamingu – wyłączenie opcji spowoduje zabronienie ustanowienie połączenia VPN w sieciach komórkowych innych niż sieć macierzysta.

Po wyborze opcji dodania połączenia VPN w nowym oknie Dodawanie połączenia sieci VPN przechodzimy do konfiguracji parametrów połączenia.

Co należy zaznaczyć opcje definiowane w tym oknie zależne są od naszego operatora. Dokładny sposób konfiguracji znajdziemy na stronach usługodawcy. W przypadku PIA konfiguracja sprowadza się do wybrania w polu Dostawca sieci VPN opcji Windows (wbudowane) Kolejny krokiem jest ustalenie nazwy połączenia. By móc zestawić działające połączenie niezbędne opcje jakie musimy zdefiniować to Nazwa lub adres IP serwera oraz Typ sieci VPN. PIA umożliwia między innymi utworzenie łącza VPN z wykorzystaniem protokołów L2TP/IPsec z kluczem wstępnym, dlatego też opcje takowe zostały wybrane.

Nazwę użytkownika oraz hasło uzyskamy od operatora (jeśli jest taka potrzeba).

Po zdefiniowaniu wszystkich opcji wybieramy Zapisz. Połączenie pojawi się na liście dostępnych. Aby ustanowić połączenie wybieramy Połącz.

Jeśli wszystkie opcje zostały poprawnie zdefiniowane połączenie powinno zostać zestawione. Jak widać poniżej połączenie zostało ustanowione - status połączenia: Połączono

Status połączenia VPN można również sprawdzić klikając w tray-u na ikonę połączenia sieciowego.

Na rysunku poniżej zaprezentowano wpływ wykorzystania skonfigurowanego i działającego połączenia VPN na przyznany adres IP (widoczność hosta od strony Internetu). Po lewej połączenie tradycyjne jak można zauważyć lokalizacja adresu IP wskazuje na Kraków. Po prawej zaś adres IP po ustanowieniu połączenia z serwerem VPN, tym razem lokalizacja została ustalona na Frankfurt.

Przyjrzyjmy się jeszcze jak wygląda przechwycony ruch sieciowy bez połączenia VPN i przy aktywnym połączeniu z serwerem VPN.

Na rysunku poniżej przedstawiono zrzut z okna programu Wireshark, którego zadaniem jest przechwytywanie ruch sieciowego tj. danych wysyłanych i odbieranych przez kartę sieciową. Na rysunku poniżej możemy wyodrębnić szereg odrębnych transmisji prowadzonych równolegle z różnymi hostami - np. 185.42.204.114 czy 62.179.1 62 Ruch ten w żaden sposób nie jest chroniony tj. możemy ustalić cel i źródło wysłanej/odebranej informacji oraz najczęściej określić jej zawartość (najczęściej choć nie zawsze gdyż szyfrowanie może być prowadzone na warstwach wyższych). Przechwycony ruch sieciowy obrazuje normalne działanie karty sieciowej.

Zaś ilustracja poniżej przedstawia ten sam ruch sieciowy lecz przy aktywnym połączeniu VPN. W tym przypadku nie możemy już wyodrębnić pojedynczych transmisji/sesji, cały ruch sieciowy odbywa się pomiędzy komputerem na którym zainicjowano połączenie VPN (adres IP 192.168.1.10) a bramą VPN (adres IP 178.162.199.91) Całość ruchu jest zaszyfrowana z wykorzystaniem protokołu ESP.

Tak więc myślę, że teraz jak na dłoni widać w jaki sposób dzięki połączeniu VPN jest chroniona nasza komunikacja.

Definicję połączenia VPN możemy również przeprowadzić za pomocą opcji dostępnych w oknie Centrum sieci i udostępniania Po wywołaniu okna (możesz skorzystać z pola Szukaj dostępnego w Panelu Sterowania) klikamy na Skonfiguruj nowe połączenie lub nową sieć. Przedstawiona konfiguracja jest analogiczna z tą którą należy przeprowadzić w systemie Windows 7.

W nowo otwartym oknie z typów dostępnych połączeń wybieramy Połącz z miejscem pracy.

W kolejnym kroku należy wybrać typ połączenia. Do dyspozycji mamy opcję pozwalającą na wykorzystaniu połączenia internetowego (połączenie przewodowe, sieć WiFi) bądź metody opartej na bezpośrednim wybraniu numeru (tzw. wdzwanianie) - do ustanowienia połączenia niezbędny jest modem. Decydujemy się na pierwszą opcję: Użyj mojego połączenia internetowego

Po wybraniu sposobu łączenia należy określić adres serwera za pomocą, którego będzie realizowane połączenie VPN oraz należy określić nazwę profilu. Tym razem decydujemy się na serwer VPN umiejscowiony w Rumuni – adres: ro.privateinternetaccess.com. Jeśli chcesz zezwolić innym użytkownikom komputera na korzystanie z tego połączenia zaznacz: Zezwalaj innym osobom na korzystanie z tego połączenia.

Po określeniu wszystkich opcji wybieramy Utwórz.

Dostęp do połączenia będzie możliwy poprzez okno: Połączenia sieciowe

Utworzone połączenie można spróbować użyć lecz po wydaniu opcji Połącz łączność z serwerem nie zostanie ustanowiona gdyż nie wszystkie opcje zostały jeszcze zdefiniowane.

Aby przejść do edycji ustawień połączenia VPN należy z menu kontekstowego połączenia wybrać Właściwości.

Aby połączenie doszło do skutku należy na karcie Zaawansowane w sekcji Typ wirtualnej sieci prywatnej (VPN) wybrać: Protokół L2TP/IPSec oraz w sekcji Uwierzytelnienie po zaznaczeniu Zezwalaj na użycie tych protokołów wybrać Microsoft CHAP wersja 2 (MS-CHAP v2)

Serwery PIA wymagają zdefiniowania klucza wstępnego tak więc by określić klucz należy po wybraniu protokołu L2TP/IPSec kliknąć na Ustawienia zaawansowane

W nowo otwartym oknie po wybraniu opcji: Użyj klucza wstępnego do uwierzytelnienia zdefiniować klucz – wartość klucza: mysafety.

Wprowadzone ustawienia należy zatwierdzić przyciskiem OK.

Podczas wykonania pierwszego połączenia zostaniemy poproszeni o podanie danych umożliwiających przeprowadzenie procesu logowania.

Po weryfikacji danych (login i hasło) połączenie VPN zostaje ustanowione.

Sprawdzenie adresu IP przekonuje nas o poprawności wykonania czynności konfiguracyjnych – uzyskany adres IP wskazuje, że łączymy się z obszaru Rumuni.

Połączenie VPN wykorzystujące zestaw protokołów L2PT/IPsec jak już wież Czytelniku nie jest jedynym sposobem na ustalenie bezpiecznego kanału komunikacyjnego. Do zestawienia połączenia VPN może zostać wykorzystany pakiet oprogramowania OpenVPN. OpenVPN jest projektem zapoczątkowanym przez Jamesa Yonana a obecnie rozwijanym przez grupę ludzi z całego świata. Oprogramowanie to jest multiplatformowe, co oznacza dostępność narzędzia w systemach takich jak Solaris, Linux, OpenBSD, FreeBSD, NetBSD, QNX, Mac OS X, Android czy Windows XP/Vista/7/8/10. Pakiet jest publikowany na licencji GNU GPL. Dzięki tak dużej popularności oprogramowania wiele firm oferujących usługi połączeń VPN umożliwia zestawienie połączenia właśnie przy wykorzystaniu OpenVPN.

Oprogramowanie pobierzemy ze strony projektu: https://openvpn.net/index.php/open-source/downloads.html

Po pobraniu pakietu zależnego od wersji posiadanego systemu przystępujemy do jego instalacji.

Na pierwszym ekranie tradycyjnie należy zaakceptować licencję. Klikamy I Agree.

Drugi krok to wybór komponentów. Możemy pozostawić te zaproponowane domyślnie. Klikamy Next.

Następuje instalacja oprogramowania. Aby OpenVPN mógł poprawnie działać należy wyrazić zgodę na instalację sterowników dodatkowego interfejsu TAP-Win32 Adapter V9 Wybieramy: Zainstaluj

Po poprawnej instalacji by móc korzystać z aplikacji należy pobrać pliki konfiguracyjne przygotowane przez usługodawcę - każda z firm, która wspiera te rozwiązanie ma przygotowane potrzebne pliki. Informacji szukaj na stronach operatora.

Po pobraniu paczki konfiguracyjnej pliki należy wypakować do katalogu C:\Program Files\OpenVPN\config bądź C:\Program Files (x86)\OpenVPN\config (w zależności od wersji posiadanego systemu).

Po wykonaniu wszystkich czynności instalacyjnych na Pulpicie zostanie utworzony nowy skrót OpenVPN GUI. Uruchamiamy narzędzie (domyślnie warto, ustawić uruchamianie narzędzia z uprawnieniami administratora). Dla niewtajemniczonych zmianę uprawnień dokonamy po wyborze z menu kontekstowego opcji Właściwości i zaznaczeniu na karcie Zgodność opcji Uruchom ten program jako administrator

Po uruchomieniu narzędzia w prawym dolnym rogu obok zegarka (patrz tray) powinniśmy zobaczyć ikonkę programu. Aby uzyskać połączenie klikamy na ikonę PPM i z rozwijanej listy wybieramy interesujący nas serwer VPN. Aby zestawić połączenie z serwerem wybieramy przycisk Połącz

W trakcie ustanawiania połączenia z serwerem VPN, zostaniemy poproszeni o wpisanie loginu i hasła. Wprowadzone dane zatwierdzamy OK

Po podaniu danych uwierzytelniających połączenie powinno zostać ustalone.

Dodatkowo po nawiązaniu połączenia został przechwycony ruch sieciowy. Jak widać cała komunikacja przebiega pomiędzy hostem lokalnym (IP - 192.168.1.155) a bramą VPN (IP - 185.3.135.34), przesyłane informacje są zaszyfrowane

W dzisiejszym świecie komputer już dawno przestał być jedynym urządzeniem przez, które realizujemy dostęp do sieci Internet. Zasoby sieci bardzo często przeglądamy na smartfonach czy tabletach i również na tych urządzeniach możemy zestawić połączenie z serwerem VPN.

Windows Phone 8 oraz 10

Konfigurację połączenia VPN rozpoczniemy od systemu Windows Phone. Środowisko te oferuje nam możliwość skonfigurowania połączenia VPN m.in. z wykorzystaniem protokołów L2TP/IPSec

Rozpoczynamy od wybrania Ustawienia by następnie przejść do sekcji VPN (w systemie Windows Phone 8 - rysunek z lewej) w przypadku systemu Windows Phone 10 opcję VPN odnajdziemy po wybraniu Sieć i połączenia bezprzewodowe.

W przypadku gdy usługa jest nieaktywna należy ją włączyć. W kolejnym kroku poprzez wybranie przycisku Opcje możemy określić zasady ustalania połączenia z serwerem VPN (Windows Phone 8).

Do dyspozycji mamy dwie opcje:

Zezwalaj na VPN przez sieć komórkową - połączenie z serwerem VPN zostanie ustanowione za pośrednictwem sieci komórkowej,

Zezwalaj na VPN w roamingu przez sieć komórkową - roaming czyli zmiana operatora sieci komórkowej najczęściej realizowana w przypadku gdy abonent znajduje się poza zasięgiem sieci operatora lub dostawcy Internetu, z którym podpisał umowę o świadczenie usług telekomunikacyjnych. Zaznaczenie tej opcji spowoduje zestawienie połączenia VPN w sieciach nie będących naszą siecią macierzystą czyli np. gdy przebywamy za granicą.

W przypadku Windows Phone 10 opcje te są dostępne od razu po otwarciu okna VPN.

Aby dodać profil VPN klikamy na znak plusa. W nowym oknie musimy określić następujące opcje:

1 - nazwa lub adres IP serwera VPN,

2 - typ połączenia VPN - wybieramy protokół L2TP/IPSec,

3 - określamy typ uwierzytelnienia - login + hasło + klucz wstępny,

4 - definiujemy nazwę użytkownika,

5 - wpisujemy hasło,

6 - określamy klucz wstępny,

7 - opcjonalnie zezwalamy na automatyczne tworzenie tunelu VPN,

8 - opcjonalnie określamy włączenie przesyłania całego ruchu,

9 - określamy nazwę profilu.

Włączenie opcji Wysyłaj cały ruch spowoduje, że cała komunikacja opierająca się o transmisję danych będzie przekazywana poprzez serwer VPN. Po wyłączeniu opcji będziemy mogli zdecydować kiedy tunel VPN ma być stosowany a kiedy nie. Sposób kształtowaniu ruchu definiujemy poprzez określenie adresów IP bądź domen. Ruch sieciowy z tymi adresami będzie przesyłany przez bramę VPN.

Po wyborze przycisku zaawansowane uzyskujemy dostęp do dodatkowych ustawień. Ustawienia te dotyczą serwera proxy a także wyłączenia sieci VPN dla sieci firmowej i domowej czyli tych sieci co do których mamy pewność, że są bezpieczne.

W przypadku systemu Windows Phone 10 ustawienia zaawansowane odnajdziemy po kliknięciu na Właściwości utworzonego profilu.

Po zdefiniowaniu wszystkich opcji nie pozostaje nam nic innego jak próba nawiązania połączenia. Jak widać poniżej próba ta kończy się sukcesem. O fakcie ustanowienia poprawnego połączenia VPN dodatkowo jesteśmy informowani ikoną kłódki – ikona ta pojawia się przy ikonie mocy nawiązanego połączenia.

Tak więc po przeprowadzonej konfiguracji możemy na swoim smartfonie z zasobów Internetu korzystać w sposób całkowicie bezpieczy.

Apple - iOS

W środowisku urządzeń Apple czyli tych pracujących pod kontrolą systemu iOS ustanowienie połączenia VPN możemy zrealizować m.in. za pomocą protokołu L2TP oraz oprogramowania OpenVPN i na wykorzystaniu tych protokołów skupimy naszą uwagę.

Zacznijmy od skonfigurowania łącza wykorzystując do tego protokół L2TP. Opis konfiguracji został przedstawiony na urządzeniu IPAD.

Konfigurację rozpoczynamy od przejścia do Ustawień po czym odszukujemy opcję VPN.

Po przejściu do ustawień karty VPN wybieramy Dodaj konfigurację VPN

Po otwarciu okna Typ wybieramy L2PT

Aby skonfigurować połączenie VPN musimy określić następujące opcje:

1 - Opis – nazwa połączenia,

2 - Serwer – nazwa serwera VPN,

3 - Konto - login VPN,

4 - Hasło - hasło VPN,

5 - Hasło wspólne - klucz współdzielony,

6 - Opcja Wysyłaj wszystko – cały ruch sieciowy jest przesyłany przez bramę VPN.

Zapisanie zdefiniowanych ustawień odbywa się klikając na Gotowe

Po skonfigurowaniu wszystkich opcji połączenie jest gotowe do użycia. W przypadku zdefiniowania większej ilości połączeń VPN przed połączeniem wybieramy te z którego chcemy skorzystać. Nawiązanie połączenia odbywa się za pomocą przełącznika Status. Jak widać poniżej udało się zestawić działający kanał VPN.

Łącze VPN zostało utworzone.

System iOS domyślnie nie ma zainstalowanego klienta sieci OpenVPN ale nic nie stoi na przeszkodzie aby stosowane oprogramowanie samemu zainstalować.

Instalacja odbywa się poprzez sklep AppStore. Po uruchomieniu sklepu odszukujemy aplikację OpenVPN Connect i instalujemy ją. Warto przy okazji nadmienić, że wiele firm oferujących usługę połączeń VPN dostarcza dedykowane aplikacje do łączności z swoją infrastrukturą. Tak więc gdy chcemy skorzystać z takiej aplikacji należy się upewnić czy nasz usługodawca przewidział taką możliwość.

Aby dokonać konfiguracji połączenia z wykorzystaniem aplikacji OpenVPN Connect, w pierwszej kolejności musisz zaimportować profil czyli plik z rozszerzeniem .ovpn. Import pliku można dokonać ręcznie podłączając iPhone lub iPad do komputera i za pośrednictwem iTunes w sekcji Aplikacje, będzie można skopiować plik .ovpn wraz z ewentualnymi certyfikatami. Pliki .ovpn należy pobrać ze strony usługodawcy. Pliki te stanowią profil w którym są zapisane informacje pozwalające nam skorzystać z danego serwera VPN (najczęściej nazwa pliku określa umiejscowienie geograficzne serwera).

Alternatywnym sposobem jest skopiowanie pliku .ovpn za pośrednictwem strony internetowej przygotowanej przez usługodawcę.

Po wyborze interesującej nas lokalizacji pobrany plik otwieramy za pomocą programu OpenVPN Connect (po instalacji oprogramowania pliki z rozszerzeniem .ovpn będą skojarzone z aplikacją).

Po otwarciu aplikacji powinniśmy ujrzeć zaimportowany profil.

Aby można było skorzystać z profilu jego dane należy uzupełnić o dane uwierzytelniające. Dane te uzupełnimy klikając na ikonę plusa.

Po wprowadzeniu danych, celem ich zapisania przesuwamy przełącznik Save i dokonujemy próby połączenia z bramą VPN. Jeśli wszystko skonfigurowaliśmy poprawnie status połączenia powinien przełączyć się do stanu Connected

Po uzyskaniu połączenia dodatkowo będziemy mogli przeglądać statystyki zestawionego połączenia.

Otwarcie okna przeglądarki i sprawdzenie przypisanego adresu IP informuje nas, że połączenie jest wykonywane z terenu Niemiec.

Android

Omówiliśmy już Windowsa, IOSa tak więc przyszła pora na Androida. I tu tak samo jak w przypadku pozostałych systemów bardzo często zdarza się że nasz usługodawca umożliwia nam połączenie się ze swoją infrastrukturą z wykorzystaniem specjalnie do tego celu przygotowanej aplikacji (dostępność sprawdź na strona usługodawcy). My jednak zdecydujemy się na samodzielne skonfigurowanie połączenia VPN. Połączenie skonfigurujemy z wykorzystaniem protokołu L2PT/IPSec który jest wspierany przez system Android oraz z wykorzystaniem narzędzia OpenVPN.

Aby rozpocząć konfigurację połączenia VPN w systemie Android przechodzimy do sekcji Połączenia a następnie z dostępnych opcji wybieramy Więcej sieci i dalej VPN.

Połączenie VPN uda nam się skonfigurować tylko w przypadku ustawienia blokady ekranu na poświadczenie typu kod PIN bądź hasło. Jak widać poniżej opcje odpowiedzialne za konfigurację połączenia VPN są nie aktywne gdyż blokada ekranu jest realizowana za pomocą symbolu.

Po kliknięciu na OK zostaniemy przekierowani do ekranu opcji Ustawienia odblokowania ekranu. Na ekranie tym ustalamy jeden ze sposobów ochrony urządzenia.

Decydujemy się na ustawienie kodu PIN.

Po ustaleniu PINu bądź hasła dostęp do opcji tworzenia kanału VPN będzie możliwy.

Konfiguracja połączenia VPN sprowadza się do określenia:

1 – nazwy połączenia,

2 – typu użytych protokołów,

3 – adresu bramy VPN,

4 – klucza współdzielonego.

Po zdefiniowaniu wszystkich opcji wybieramy Zapisz.

Na uwadze należy mieć fakt, że u różnych dostawców konfiguracja połączenia może się nieznacznie różnić od tej przedstawionej. Wszystkie niezbędne informacje znajdziemy na pewno na stronach usługodawcy.

Po zapisaniu konfiguracji tunelu VPN możemy wykonać próbę połączenia. Po wybraniu połączenia określamy nazwę użytkownika oraz hasło.

Jeśli wszystko wykonaliśmy poprawnie powinno nam udać się ustanowić połączenie VPN. O stanie połączenia zostaniemy poinformowani osobnym powiadomieniem, na belce opcji powinna pojawić się ikona klucza.

W systemie Android możemy również skorzystać z połączeń typu OpenVPN. Aby wykorzystać ten typ połączenia musimy zainstalować aplikację OpenVPN Connect, którą znajdziemy w sklepie. Po odnalezieniu aplikacji wybieramy Zainstaluj.

Po instalacji oprogramowania należy tak jak w przypadku systemu IOS zaimportować odpowiedni profil połączenia. Przechodzimy na stronę udostępnioną przez operatora i wybieramy serwer przez który chcemy realizować połączenie. Po pobraniu pliku wybieramy Otwórz.

Akceptujemy ustawienia profilu wybierając Accept.

Po zaimportowaniu profilu aby ukończyć konfigurację tunelu VPN zostaniemy poproszeni o podanie nazwy użytkownika i hasła. Po poprawnym zdefiniowaniu danych wybieramy Connect.

Przed utworzeniem połączenia z serwerem VPN zostaniemy ostrzeżeni o przechwyceniu wszystkich aktywnych połączeń sieciowych przez aplikację OpenVPN Connect aby sfinalizować połączenie należy zaznaczyć Ufam tej aplikacji i całą operację potwierdzić klawiszem OK

Po wykonaniu tych wszystkich operacji powinno Nam udać się zestawić połączenie VPN. Aktywne połączenie VPN jest sygnalizowane ikoną klucza na belce zadań.

Trochę wcześniej obiecałem zaprezentować połączenie VPN typu site - to - site a więc aby nie rzucać słów na wiatr, jeszcze kilka słów na ten temat. Do tej pory zajmowaliśmy się konfigurowaniem połączeń VPN na każdym z urządzeń z osobna. Do problemu można podejść trochę z innej strony. A mianowicie w domu bądź firmie wszystkie urządzenia tworzące sieć lokalną aby uzyskać dostęp do Internetu muszą mieć łączność z bramą czyli routerem. Tak więc można zlecić routerowi utworzenie połączenia VPN w ten sposób naszą sieć lokalną połączymy z siecią usługodawcy VPN. W ten o to prosty sposób każde urządzenie pracujące w naszej sieci uzyska bezpieczny dostęp do Internetu poprzez bramę VPN. Niestety routerów, które mają wbudowaną obsługę protokołów VPN na rynku tak wiele nie znajdziemy. Prym w tym temacie wiedzie firma Asus, która np. w routerach Asus RT-N16, Asus RT-N18U, Asus RT-N66U, Asus RT-AC66U, Asus RT-AC68U, Asus RT-AC87U, Asus RT-AC3200 czy Asus RT-AC5300 zaimplementowała obsługę protokołu OpenVPN (w niektórych routerach opcja utworzenia kanału VPN będzie dostępna po wgraniu najnowszego softu). Poniżej przykład dostępnych opcji odpowiedzialnych za zestawienie połączenia VPN na routerze Asus RT-AC5300.

Jeśli domyślny firmware routera nie ma opcji zaimplementowania połączeń VPN można zdecydować się na zainstalowanie oprogramowania typu DD-WRT czy Tomato będącego alternatywą dla oryginalnego oprogramowania. Lecz tu na stronach projektów musimy sprawdzić kompatybilność oprogramowania z posiadanym sprzętem. Poniżej na zrzucie panel opcji VPN dostępnych po instalacji DD-WRT.

Szczegółowy przebieg konfiguracji nie został przeze mnie przedstawiony gdyż konfiguracja różni się w zależności od dostawcy (tu odsyłam do stron internetowych już konkretnych usług). Bardziej zależało mi na wskazaniu „drogi” niż przedstawieniu opisu dla tego konkretnego dostawcy.

Jeśli nie czujemy się na siłach w przeprowadzeniu flashowania routera i całej konfiguracji możemy zdecydować się na zakup już wstępnie przygotowanego routera - niektórzy dostawcy VPN w swojej ofercie mają przygotowaną taką opcję.

I dobrnęliśmy do końca mam nadzieję Czytelniku, że utworzenie połączenia VPN po lekturze tego wpisu nie będzie stanowić żadnego problemu.

BIBLIOGRAFIA:

https://msdn.microsoft.com/en-us/library/cc247338.aspx

https://technet.microsoft.com/pl-pl/library/poradnik-krok-po-kroku-instalowanie-i-konfiguracja-sstp-cz-i.aspx#1

https://www.bestvpn.com/blog/4147/pptp-vs-l2tp-vs-openvpn-vs-sstp-vs-ikev2/

https://thebestvpn.com/pptp-l2tp-openvpn-sstp-ikev2/

https://vpntips.com/vpn-router-install/

Co w sieci siedzi. Agregacja interfejsów przełącznika.

2016-01-23T11:21:30+00:00

Agregacja łączy (ang. link aggregation) polega na połączeniu ze sobą wielu portów fizycznych przełącznika w jedną logiczną całość. Dzięki takiemu połączeniu otrzymujemy grupę portów przez, które będą przesyłane dane przy czym od strony systemu IOS tak utworzona grupa będzie widoczna jako jeden port. Maksymalna liczba jednocześnie wykorzystywanych połączeń fizycznych, które mogą uczestniczyć w agregacji wynosi 8.

Dzięki połączeniu ze sobą portów uzyskujemy:

zwiększona przepustowość łącza - wiele fizycznych łączy zagregowane w ramach jednej grupy poszerza dostępne pasmo. Oznacza to, że tworząc kanał EtherChannel prędkość utworzonego łącza jest sumą prędkości interfejsów fizycznych tworzących ten kanał. Jeśli do konfiguracji kanału zostało użytych 6 interfejsów FastEthernet łączna prędkość wyniesie 600 Mb/s. Założenie w swej koncepcji słuszne choć jak dowiesz się za chwilę nie oznacza to, że uzyskana rzeczywista prędkość przesyłu danych odpowiada zawsze przepustowość łącza.

rozłożenie obciążenia - prowadzona komunikacja jest rozkładana na szereg łączy. Przy czym na uwadze należy mieć fakt iż pojedyncza sesja jest prowadzona z wykorzystaniem tylko jednego łącza. Rozłożenie obciążenia w przypadku agregacji łącza nie można traktować jako sposób przesłania pakietów tworzących jedną sesje poprzez różne fizyczne zagregowane łącza przełącznika. Wyobraź sobie Czytelniku autostradę, droga ta posiada szereg pasów prowadzących w jedną stronę. Autostrada pomieści większą liczbę samochodów lecz każdy z pojazdów porusza się jednym pasem. Wracając do przykładu z agregacją 6 interfejsów FastEthernet oznacza to, że pojedyncza sesja pomimo wykorzystania łącza o przepustowości 600 Mb/s będzie ograniczona do prędkości 100 Mb/s

większa dostępność oraz redundancja - awaria łącza przypisanego do grupy nie powoduje wyłączenia grupy, ruch sieciowy nadal będzie przekazywany.

Opis agregacji łącza przedstawię na urządzeniach firmy Cisco. Agregacja w terminologii Cisco jest określana jako EtherChannel i jest sposobem budowania grupy łączy pomiędzy przełącznikami Cisco.

EtherChannel bazuje na standardzie 802.3ad, który później został przemianowany na standard 802.1ax opisujący agregację łączy. Według tego standardu agregacja łączy jest opisywana jako (źródło: https://standards.ieee.org/findstds/standard/802.1AX-2014.html):

„Agregacja łączy umożliwia zagregowanie jednego łącza lub większej liczby łączy w celu utworzenia grupy agregacji łączy LAG (ang. link aggregation group) w taki sposób, że klient MAC może traktować tę grupę, jakby była pojedynczym łączem.”

W przypadku urządzeń CISCO grupę LAG możemy utworzyć jednym z trzech sposobów:

statyczny EtherChannel zwany też również jako mode on Sposób ten bazuje na ręcznej konfiguracji grupy LAG,

dynamiczny EtherChannel - sposób ten polega na wykorzystaniu jednego z dwóch dostępnych protokołów pozwalających w sposób całkowicie automatyczny na utworzenie grupy LAG. Protokoły odpowiedzialne za konsolidację portów to LACP (ang. Link Aggregation Control Protocol) i PAgP (ang. Port Aggregation Protocol). Protokół PAgP jest autorskim rozwiązaniem firmy Cisco.

Stosując metodę statyczną wymuszamy utworzenie kanału EtherChannel bez negocjacji (administrator konfigurację wykonuje samodzielnie) oznacza to, że żaden z protokołów nie jest wykorzystywany tak więc żadne pakiety nie są pomiędzy przełącznikami wymieniane. Wybranie tej metody spowoduje natychmiastowe utworzenie kanału nawet gdy w sąsiednim przełączniku interfejsy są skonfigurowane nieprawidłowo.

W przypadku drugiego rozwiązania czyli dynamicznego tworzenia kanału jak już zostało wspomniane można wykorzystać jeden z protokołów - PAgP bądź LACP. Protokoły te dbają o prawidłową konfigurację tworzonego łącza. Użycie protokołów definiujemy w trybie konfiguracji interfejsu a do dyspozycji mamy następujące opcje:

Protokół PAgP
auto	Port pracujący w tym trybie samodzielnie nie inicjuje łącza, kanał zostaje utworzony pasywnie na zainicjowaną konfigurację.
desirable	Port pracujący w trybie desirable aktywnie negocjuje utworzenie kanału.
Protokół LACP
passive	Port w sposób pasywny uczestniczy w procesie tworzenia łącza, negocjacja w tym trybie nie jest inicjonowana.
active	Port pracujący w trybie active aktywnie negocjuje utworzenie kanału.

Dociekliwy Czytelnik za pewnie zapyta - Który protokół wybrać? Jeśli masz do dyspozycji urządzenia firmy CISCO możesz postawić na protokół PAgP choć warto mieć na uwadze, że co nowsze urządzenia sieciowe tej firmy wsparcia dla tego rozwiązania są już pozbawione a zaś te starsze protokołu LACP nie obsługują. Jeśli korzystasz z urządzeń różnych producentów to wyboru nie masz i musisz zdecydować się na LACP.

Na koniec jeszcze ogólna uwaga odnosząca się do konfiguracji interfejsów fizycznych, które będą wchodzić w skład łącza EtherChannel. Interfejsy mogą być skonfigurowane w trybie trunk lub jako access. Dodatkowo trzeba zadbać aby interfejsy fizyczne tworzące łącze miały konfigurację zgodną co do szybkości interfejsu oraz duplexu.

Połączenie logiczne działa tak długo jak długo aktywne jest przynajmniej jedno połączenie fizyczne.

W trakcie opisu często będą pojawiać się terminy EtherChannel oraz Port Channel. W niektórej literaturze zdarza się, że terminy te są używane zamiennie choć tak naprawdę określają dwa różne pojęcia. Tak więc mianem EtherChannel będziemy określać logiczny kanał utworzony pomiędzy przełącznikami zaś Port Chanel jest to interfejs powstały na obu końcach przełączników tworzących kanał EtherChanel w skład którego wchodzą interfejsy fizyczne wykorzystane do utworzenia skonsolidowanego łącza.

Nasze rozważania na temat konfiguracji EtherChannel przeprowadzimy z wykorzystaniem topologii zaprezentowanej na rysunku poniżej. Jak widać omówimy każdą z metod utworzenia kanału EtherChannel.

Lecz zanim przejdziemy dalej jeszcze taka krótka dygresja na temat całego mechanizmu.

Wykonanie połączeń pomiędzy przełącznikami jak w zaprezentowanej topologii powyżej nie pozostanie bez konsekwencji gdyż takie połączenie może doprowadzić do powstania pętli czego skutkiem będzie przesyłanie ramek w nieskończoność. Ramki te skutecznie spowodują zablokowanie normalnego ruchu sieciowego (należy pamiętać, że w przypadku warstwy drugiej nie ma zabezpieczeń takich jak występują w warstwie trzeciej - pole TTL). Brak zabezpieczeń wymusiło wprowadzenie innych mechanizmów, których zadaniem jest dbanie o prawidłowość funkcjonowania sieci. Takim mechanizmem jest m.in. protokół STP. Aby nie wchodzić zbytnio w szczegóły i sposób działania (protokół ten opisze wkrótce) to dodam tylko, iż zadaniem protokołu jest takie zarządzanie łączami poprzez ich włączanie i wyłączanie aby nie doprowadzić do powstania pętli. Oczywiście topologie podobne do tej zaprezentowanej powyżej stosuje się aby zapewnić redundancję tak by zabezpieczyć się przed ewentualną awarią łącza a wspomniany protokół STP dba o prawidłowe działanie sieci.

Aby sprawdzić konfigurację sieci z punktu widzenia protokołu STP należy wydać polecenie: show spanning-tree Po wydaniu polecenia na switchu SW2 i analizie uzyskanych wyników dochodzimy do wniosku iż przełącznik ten pełni funkcję root bridge (zarządza działaniem mechanizmu STP) i dlatego wszystkie interfejsy przełącznika mogą przekazywać dane.

Wydanie tego samego polecenia np. na przełączniku SW1 dostarcza nam już inne informacje. Między innymi dowiadujemy się, że interfejs Fa0/2 jest w stanie blokowania. Interfejs ten tworzy połączenie z przełącznikiem SW2. Z przełącznikiem tym komunikacja odbywa się z wykorzystaniem interfejsu Fa0/1. Interfejs Fa0/2 przejdzie w stan przekazywania pakietów w momencie awarii łącza korzystającego z interfejsu Fa0/1

Całe te odejście od tematu wpisu doprowadza nas do następującego wniosku - a mianowicie - pomimo zastosowania dodatkowych połączeń pomiędzy przełącznikami to i tak na wskutek działania protokołu STP do komunikacji jest wykorzystywane pojedyncze łącze. Drugie łącze wchodzi do gry tylko w przypadku awarii łącza podstawowego. Stwierdzenie te pozwala nam wysnuć drugi wniosek: czemu by nie wykorzystać zestawione połączenie w bardziej efektywny sposób skoro i tak jest nie użytkowane. I w tym momencie do gry wchodzi mechanizm Etherchannel - skoro mamy zapewniona komunikację z danym przełącznikiem poprzez różne interfejsy połączmy je w wspólny kanał transmisji. Fakt poszerzenia dostępnego pasma na pewno lepiej wpłynie na działanie naszej sieci niż utrzymywanie nieczynnego łącza.

Dygresje tą pozostawiam do przemyśleń własnych a tym czasem przejdźmy dalej.

Przełącznik SW1-SW3 – EtherChannel – protokół PAgP

Rozpoczynamy od agregacji łącz pomiędzy przełącznikami SW1 a SW3. Zestawienie połączenia będzie realizowane z wykorzystaniem interfejsów f0/3 oraz f0/4 przełącznika SW1 oraz tych samych portów f0/3 oraz f0/4 przełącznika SW3. Agregacje łączy wykonamy z wykorzystaniem protokołu PAgP.

Aby utworzyć kanał EtherChannel w pierwszej kolejności przechodzimy do trybu konfiguracji portów. Aby wydawane polecenia dotyczyły zarówno portu f0/3 oraz f0/4 została wykorzystana opcja range. Aby utworzyć zagregowane łącze z wykorzystaniem protokołu PAgP należy wydać polecenie: channel-group <numer_grupy> mode desirable Numer grupy określamy indywidualnie ważne by numer ten był unikatowy w obrębie przełącznika. Oznacza to, że numer utworzonej grupy nie może zostać powtórzony (wykorzystany dwukrotnie). Zakres wartości do wykorzystania od 1 do 64. Zgodność numeru grupy na przełącznikach tworzących skonsolidowane łącze nie jest wymagane, choć oczywiście zaleca się aby wartość przyznana grupie była taka sama na obu przełącznikach – takie podejście sprzyja przejrzystości konfiguracji. Wybranie trybu desirable spowoduje aktywne negocjowanie utworzenia kanału.

Po wydaniu polecenia łącza wchodzą w skład nowego interfejsu logicznego: Port-channel 1 (Po1)

Fakt utworzenia kanału EtherChannel możemy sprawdzić za pomocą komendy: show etherchannel Jak widać poniżej kanał LAG o identyfikatorze 1 korzystający z protokołu PAgP został utworzony.

Fakt utworzenia kanału nie gwarantuje nam, że zbudowane w ten sposób łącze jest w stanie przekazywać ruch sieciowy. Aby sprawdzić w jakim stanie jest łącze EtherChannel można wykorzystać polecenie: show etherchannel summary Po wydaniu komendy w formie tabeli zostaną wyświetlone wszystkie interfejsy Port-Channel wraz z informacją o stanie interfejsu, sposobie utworzenia oraz interfejsach fizycznych tworzących grupę LAG.

Analiza uzyskanych danych wskazuje, że interfejs Po1 jest wyłączony (symbol D – down).

Jeszcze więcej informacji na temat utworzonego kanału oraz portów wchodzących w jego skład poznamy dzięki poleceniu: show etherchannel detail (polecenie omówimy trochę szerzej za chwilę, gdy uda nam się utworzyć działający kanał EtherChannel).

Status interfejsu Po1 możemy również sprawdzić za pomocą polecenia: show ip interfeces brief Jak można stwierdzić interfejs jest w stanie down (kanał nie został jeszcze skonfigurowany po drugiej stronie – switch SW3).

Aby łącze EtherChannel mogło przekazywać ruch sieciowy należy je również skonfigurować na przełączniku SW3. Podobnie jak to było w przypadku switcha SW1 do konfiguracji łącza wykorzystamy przełącznik range. Po określeniu interfejsów, które wejdą w skład grupy LAG (interfejs f0/3 oraz f0/4) wydajemy polecenie: channel-group 1 mode auto Po wydaniu komendy interfejs łącza Port-channel 1 osiągnął status up. Oznacza to, że łącze LAG zostało włączone.

Aby sprawdzić status kanału skorzystamy z znanego nam już polecenia: show etherchannel summary Po analizie uzyskanych wyników stwierdzamy, że interfejs Po1 działa (flaga U – łącze w użyciu).

Jak już wiesz czytelniku jeszcze dokładniejsze wyniki stanu łącza oraz interfejsów fizycznych uzyskamy po wydaniu komendy: show etherchannel detail Gdy łącze działa prawidłowo i interfejs jest aktywny w wynikach polecenia pojawi się informacja o interfejsie sąsiada. Jak widać poniżej lokalny port f0/3 przełącznika SW1 (sekcja Local information) jest połączony z portem f0/3 sąsiada czyli przełącznika SW3 (sekcja Partner’s information).

Dodatkowo fakt włączenia interfejsu Po1 można zweryfikować po wydaniu polecenia: show ip interface brief

Interfejs Po1 będzie również uwzględniany przez protokół STP. Po sprawdzeniu stanu działania protokołu widać, że interfejsy fizyczne Fa0/3 oraz Fa0/4 zostały zastąpione interfejsem logicznym Po1.

Konfigurację interfejsu fizycznego możemy dodatkowo zweryfikować za pomocą polecenia: show running-config interface <nazwa_interfejsu> - interfejs do utworzenia zagregowanego łącza wykorzystał protokół PAgP, tryb pracy portu desirable

a także za pomocą komendy: show interfaces f0/3 switchport – interfejs f0/3 pracuje w trybie access i jest częścią puli interfejsów fizycznych przynależnych do grupy LAG – Port-Channel Po1.

Oprócz sprawdzenia informacji na temat interfejsów przypisanych do kanału Etherchannel możemy dokonać również sprawdzenia ustawień utworzonego interfejsu logicznego Port-Channel 1. Sprawdzenia dokonujemy za pomocą polecenia: show interfaces port-channel <numer_interfejsu>

Przeglądając konfigurację portu warto zwrócić uwagę na parametr BW (bandwidth – pasmo) – wartość ta odpowiada: ilość połączonych interfejsów x pasmo każdego z nich. W przykładzie zostały użyte dwa łącza FastEthernet tak więc maksymalne pasmo dostępne dla interfejsu Po1 wynosi 200000 kb/s (2 interfejsy x 100000 kb/s) Dodatkowo w sekcji Members in this channel poznamy interfejsy tworzące dany kanał LAG.

Łącze EtherChannel z wykorzystaniem protokołu PAgP pomiędzy przełącznikami zostało zestawione, tak więc do weryfikacji stanu łącza możemy również wykorzystać polecenia systemu IOS, które są przynależne temu protokołowi.

Jednym z poleceń jest: show pagp neighbor Po wydaniu komendy poznamy informacje o interfejsach sąsiada. Jak widać poniżej łącze LAG jest zestawione z interfejsami f0/3 oraz f0/4 przełącznika SW3 a interfejsy te pracują w trybie auto. Dodatkowo poznamy czas pracy interfejsów.

Aby poznać interfejsy lokalne przełącznika wykorzystujące protokół PAgP należy wykorzystać polecenie: show pagp internal

Informacje o stanie wymienianych informacji PAGP poznamy po wydaniu polecenia: show pagp counters

Ewentualne problemy z kanałem EtherChannel, który jest budowany za pomocą protokołu PAGP możemy rozwiązać włączając proces debugowania tego protokołu. Debugowanie uruchomimy za pomocą komendy: debug pagp <opcja> Poniżej na zrzucie włączony proces debugowania zdarzeń (przełącznik SW1) protokołu PAGP oraz wynik informacji uzyskanych na skutek wyłączenia interfejsów sąsiada tworzących łącze LAG.

Przełącznik SW1-SW2 – EtherChannel – protokół LACP

Po ustaleniu łącza EtherChannel pomiędzy przełącznikiem SW1 a SW3 przechodzimy do zestawienia kanału pomiędzy switchem SW1 a SW2. Lecz tym razem skorzystamy z protokołu LACP.

Konfigurację rozpoczynamy od konfiguracji przełącznika SW1. Kanał zostanie utworzony z wykorzystaniem interfejsów f0/1 oraz f0/2 (interfejsy są tożsame z tymi użytymi na przełączniku SW2). Tak samo jak w przypadku PAgP konfigurację przeprowadzamy w trybie konfiguracji interfejsu. Interfejsy przełącznika SW1 ustawiamy do pracy w trybie active (aktywne negocjowanie utworzenia kanału). Numerowi tworzonej grupy została przypisana wartość 2.

Po wydaniu polecenia: channel-group 2 mode active został utworzony interfejs Port Channel Po2, w skład którego weszły interfejsy fizyczne f0/1 oraz f0/2. Stan interfejsu Po2 możemy sprawdzić wydając komendę: show etherchannel summary. Interfejs jest w stanie down (flaga D).

Dokładniejsze informacje o stanie łącza uzyskamy wydając polecenie: show etherchannel detail

Aby kanał EtherChannel został utworzony musimy skonfigurować przełącznik SW2. Na przełączniku tym w trybie konfiguracji interfejsów wydajemy polecenie: channel-group 2 mode passive. Wydanie komendy powoduje ustawienie portów fizycznych w tryb pasywnej negocjacji. Oznacz to, że zagregowane łącze powstanie gdy poprosi o to sąsiad. Porty przełącznika SW1 zostały skonfigurowane tak aby inicjować utworzenie kanału tak więc łącze EtherChannel pomiędzy przełącznikami zostaje utworzone – interfejs Port-channel 2 zmienia stan na up.

Łącze LAG zostało skonfigurowane za pomocą protokołu LACP a ogólny proces tworzenia łącza przebiegał następująco:

interfejsy skonfigurowane za pomocą flagi active wygenerowały na swoich łączach ramki LACPDU (ang. LACP Data Unit) - przełącznik SW1
sąsiad po odebraniu ramki LACPDU (gdy jest skonfigurowany do korzystania z protokołu LACP) odpowiedział na zapytanie wysyłając odpowiedź – przełącznik SW2,
przełączniki utworzyły dynamiczną grupę LAG – interfejs Port-Channel Po2

Stan łącza możemy sprawdzić za pomocą znanego nam polecenia: show etherchannel summary. Interfejs Po2 działa prawidłowo (flaga U).

Dokładny stan portów możemy skontrolować za pomocą już również wykorzystywanego polecenia: show etherchannel detail

Dokładniejszy opis uzyskanych informacji

1 - informacja o grupie LAG,

2 - użyty protokół,

3 - stan portu,

4 - numer grupy, oraz identyfikator interfejsu Port-channel,

5 - informacja o interfejsie lokalnym tworzącym kanał EtherChannel m.in. stan portu, priorytet

6 - informacja o interfejsie sąsiada tworzącym kanał EtherChannel m.in. stan portu, priorytet, czas przyłączenia oraz ID.

Na przełączniku SW2 wydano dodatkowo dwa polecenia tak aby doprecyzować konfigurację związaną z protokołem LACP.

Polecenie: lacp system-priority <priorytet> (punkt 1) jest odpowiedzialne za zdefiniowanie numeru priorytetu systemu LACP. Polecenie wydane w trybie konfiguracji globalnej odpowiada za ustalenie, który z przełączników ma pierwszeństwo w podjęciu decyzji o utworzeniu kanału EtherChannel. Zasada jaka obowiązuje - niższy priorytet ma pierwszeństwo. W przypadku pozostawienia domyślnych wartości, decyduje adres MAC - niższy adres ma pierwszeństwo. Wartość priorytetu może być ustalona od 1 do 65535 (domyślnie 32768).

Komenda: lacp port-priority <priorytet> (punkt 2) jest wydawana w trybie konfiguracji interfejsu a odpowiada za przydzielenie priorytetu interfejsom. Kanał LAG może maksymalnie wykorzystywać 8 interfejsów fizycznych lecz przydzielonych łączy do kanału może być więcej. Poprzez manipulację parametrem lacp port-priority definiujemy, które interfejsy mają być aktywne a które mają być użyte w przypadku awarii. Wartość priorytetu może być ustalona od 1 do 65535 (domyślnie 32768).

Wartości ustalonych priorytetów możemy odnaleźć w wynikach już zaprezentowanych poleceń (lub tych, które będą przedstawione za chwilę). Na przykład wartość lacp port-priority poznamy po wydaniu komendy: show etherchannel detail zaś wartość lacp system-priority po wydaniu komendy: show lacp sys-id

Aby poznać protokoły, które zostały wykorzystane do utworzenia zagregowanych łączy wraz z informacją o grupie wydaj polecenie: show etherchannel protocol (na switchu SW1 są uruchomione dwa protokoły PAgP oraz LACP przy czym pierwszy z nich obsługuje grupę 1 a drugi grupę 2).

Tak jak to miało miejsce w przypadku protokołu PAgP tak i w przypadku korzystania z protokołu LACP stan utworzonego łącza można skontrolować za pomocą poleceń przynależnych temu protokołowi.

Pierwsze polecenie: show lacp neighbor pokarze status portów sąsiada. Jak widać poniżej porty f0/1 oraz f0/2 przełącznika SW2 (sąsiad przełącznika SW1) działają prawidłowo. Porty te zostały skonfigurowane do pracy w trybie pasive (flaga P).

Stan interfejsów lokalnych poznasz za pomocą komendy: show lacp internal (grupę LAG o identyfikatorze 2 tworzą łącza f0/1 oraz f0/2, interfejsy są skonfigurowane do pracy w trybie active - flaga A)

Stan wymiany ramek pomiędzy przełącznikami poznasz wydając komendę: show lacp counters

I tak jak w przypadku protokołu PAgP problemy z działaniem kanału LAG zestawionego za pomocą LACP można próbować rozwiązać włączając proces debugowania protokołu. Poniżej na listeningu za pomocą polecenia: debug lacp event zostało włączone monitorowanie zdarzeń, które dotyczą działania protokołu LACP - interfejs Port-Channel2 przestał działać (powód - wyłączenie interfejsów sąsiada) by ponownie wróć do normalnego stanu pracy.

Oczywiście tak jak w przypadku protokołu PAgP stan konfiguracji protokołu LACP w kontekście działania mechanizmu STP poznamy wydając polecenie: show spanning-tree Interfejsy F0/1 i F0/2 zostały zastąpione interfejsem logicznym Po2

Przełącznik SW2-SW3 – EtherChannel – „mode on”

Kanały EtherChannel na łączach pomiędzy przełącznikami SW1-SW3 oraz SW1-SW2 zostały utworzone dynamicznie z wykorzystaniem protokołów PAgP oraz LACP. Do omówienia został nam sposób trzeci a mianowicie utworzenie łącza LAG w sposób całkowicie statyczny. Zagregowane łącze utworzymy pomiędzy przełącznikami SW2 (interfejs f0/3 oraz f0/4) oraz SW3 (interfejs f0/1 oraz f0/2).

Rozpoczynamy od konfiguracji switcha SW2.

Aby zestawić kanał za pomocą flagi range określamy grupę interfejsów co do których będzie przeprowadzana konfiguracja a następnie za pomocą komendy: channel-group 3 mode on zostaje utworzone zagregowane łącze. Jak widać poniżej w przeciwieństwie do dwóch poprzednich metod interfejs logiczny Port-channel 3 od razu jest w stanie up.

Informację o działającym kanale EtherChannel potwierdzimy po wydaniu polecenia: show etherchannel summary (interfejs Po3 działa – flaga U, został utworzony ręcznie – brak informacji o użyciu protokołu).

Dodatkowo potwierdzenie utworzenia kanału LAG w trybie mode on możemy zweryfikować za pomocą polecenia: show etherchannel <nr_interfejsu> protocol Jak można stwierdzić po poniższym zrzucie interfejs został skonfigurowany z wykorzystaniem trybu ręcznego – mode on.

Jeszcze jednym poleceniem, które również pomoże nam w zebraniu informacji o utworzonych łączach EtherChannel jest komenda: show etherchannel <id_portu> port-channel Oprócz podstawowych danych o interfejsie uzyskamy również informację o interfejsach fizycznych budujących dany kanał.

Oczywiście polecenia te również można używać w kontekście łączy zestawionych w sposób dynamiczny.

Interfejs Po3 pomimo tego, że jest w stanie up (przełącznik SW2) nie działa jeszcze prawidłowo gdyż nie został skonfigurowany jego sąsiad. Aby kanał EtherChannel mógł zacząć przekazywać ruch sieciowy należy przeprowadzić konfigurację na przełączniku SW3. Konfiguracja przebiega analogicznie jak w przypadku switcha SW2.

Łącze EtherChannel w trybie ręcznym zostało utworzone.

O dodatkowych sposobach weryfikacji utworzonych kanałów jeszcze parę słów za chwilkę.

Użycie agregacji łączy może dać wrażenie, że jest to dobry sposób na zwiększenie ogólnej przepustowości łącza w sytuacjach w których jest to konieczne. W pewnych sytuacjach rozumowanie takie będzie jak najbardziej prawidłowe i rzeczywiście uzyskamy zwiększenie dostępnego pasma łącza lecz może również zdarzyć się tak, że pomimo prawidłowej konfiguracji kanału EtherChannel i zwiększenia dostępnego pasma łącza nadal będziemy mieć problem z uzyskaniem pożądanej prędkości przesyłania pakietów gwarantującej prawidłowe funkcjonowanie naszej sieci.

Więc rodzi się pytanie – Od czego stan taki zależy? I dlaczego tak się dzieje, że w jednym przypadku decyzja o konfiguracji kanału LAG będzie strzałem w dziesiątke zaś w drugim strzałem w płot? Odpowiedź na to pytanie nie jest sprawą prostą a już na pewno pomimo poznania odpowiedzi nie rozwiążemy problemów we wszystkich sytuacjach.

Aby móc w sposób efektywny wykorzystać mechanizm agregacji kanałów trzeba uzmysłowić sobie w jaki sposób jest realizowana funkcja rozłożenia obciążenia w kanale EtherChannel na poszczególne interfejsy fizyczne.

Działanie algorytmu, który podejmuje decyzję o przesłaniu danych poprzez poszczególny interfejs fizyczny polega na przyporządkowaniu interfejsowi liczby z zakresu od 0 do 7. Oznacza to, że w zależności od liczby łączy fizycznych budujących kanał LAG, interfejsowi będzie przyporządkowana jedna wartość bądź więcej. Poniżej na rysunku zaprezentowano rozłożenie przydzielania liczby wartości w zależności od liczby interfejsów w kanale EtherChannel.

lub może w bardziej obrazowy sposób w przeliczeniu na procenty

Jak widać najkorzystniej równoważenie obciążenia przebiega w przypadku wyboru kanału EtherChannel składającego się z 8, 4 i 2 łączy fizycznych gdyż w tych przypadkach łącza są obciążone równomiernie. W pozostałych zaś przypadkach ruch sieciowy nie rozkłada się w równy sposób na wszystkie interfejsy fizyczne. Jak już wspomniano jest to spowodowane tym, że niektórym interfejsom zostaje przypisana większa liczba wartości niż pozostałym a co za tym idzie jest wyższe prawdopodobieństwo, że na skutek działania algorytmu decydującego o trasie przesyłu danych, łącze te zostanie wybrane chętniej. Na przykład w sytuacji w której kanał EtherChannel tworzy pięć łączy, trzem zostaną przypisane dwie wartości zaś dwóm pozostałym tylko jedna wartość. Oznacza to, że trzy interfejsy będą wykorzystywane w większym stopniu niż dwa pozostałe.

Domyślna metoda wyboru ścieżki transmisji dla pakietów opiera się przeważnie na docelowym adresie MAC choć w zależności od modelu przełącznika i wersji oprogramowania IOS będzie można zdecydować się na:

źródłowy adres IP (src_ip_addr),
docelowy adres IP (dest_ip_addr)
źródłowy i docelowy adres IP (src-dst-ip)
źródłowy adres MAC (src_mac_addr)
docelowy adres MAC (dest_mac_addr)
źródłowy i docelowy adres MAC (src-dst-mac)
port źródłowy (src_port)
port docelowy (dest_port)
port źródłowy i docelowy (src-dst-port)

Aby bardziej zrozumieć mechanizm rozłożenia obciążenia w kanale EtherChannel przeanalizujmy sytuacje zaprezentowaną na rysunku poniżej. Grupa użytkowników (po lewej) aby uzyskać dostęp do usług musi skontaktować się z grupą serwerów (po prawej). Załóżmy w naszym przykładzie, że najbardziej obciążonym serwerem jest serwer plików, który pochłania 60% przepustowości łącza. Ruch sieciowy jest przekazywany poprzez dwa przełączniki pomiędzy, którymi zestawiono łącze EtherChannel zbudowane z 4 interfejsów FastEthernet. Mogłoby by się wydawać, że nie powinno być problemu z przepustowością łącza gdyż zestawiony kanał pozwala nam w jedną stronę wysłać dane z prędkością 400 Mb/s co w przeliczeniu na serwer plików daje nam 240 Mb/s. Niestety zastosowanie domyślnej konfiguracji (algorytm oparty na docelowym adresie MAC) spowoduje, że pomimo zestawienia łącza LAG wymagana przepustowość łącza nie zostanie osiągnięta. Stanie się tak ponieważ w kanale EtherChannel ruch do serwera plików w przypadku wyboru metody opartej na docelowym adresie MAC będzie przekazywany tylko poprzez jedno wybrane łącze. Zaś ruch sieciowy do innych serwerów będzie przekazywany przez odrębne łącza w skonfigurowanej wiązce EtherChannel. Tak więc na przełączniku SW1 bardziej trafioną metodą wyboru ścieżki przesyłu danych będzie metoda bazująca np. na źródłowym adresie MAC – ruch od hostów będzie rozkładany na poszczególne interfejsy. Na switchu SW2 pozostawienie domyślnej konfiguracji da pożądany efekt rozłożenia ruchu sieciowego na wszystkie łącza fizyczne gdyż przełącznik SW2 ruch pakietów od strony serwerów w kierunku hostów będzie rozkładał na poszczególne interfejsy wchodzące w skład zbudowanego łącza LAG. Zmiana na metodę bazującą na źródłowym adresie MAC spowoduje, że pakiety od serwera plików zostaną przesłane jednym i tym samym łączem czyli nasz problem nie zostaje rozwiązany.

Aby na przełączniku sprawdzić dostępne metody działania algorytmu wyboru ścieżki należy wydać polecenie: port-channel load-balance ?

Zmiany dokonujemy poprzez wybranie odpowiedniej flagi z dostępnych. Np. zmiana ustawień na metodę bazującą na źródłowych adresach MAC dokonamy za pomocą polecenia: port-channel load-balance src-mac Polecenie wydajemy w trybie konfiguracji globalnej co oznacza, że wybrana metoda będzie stosowana do wszystkich portów przełącznika skonfigurowanych w ramach kanału EtherChannel.

Weryfikację ustawień dokonamy za pomocą komendy: show etherchannel load-balance

Podczas pracy skonfigurowanego łącza EtherChannel warto kontrolować, które z łączy są wykorzystywane najintensywniej. Ogólne pojęcie o użyciu łącza poznamy odszukując w wynikach wydawanych poleceń wartości Load. Parametr ten jest uwzględniany np. w poleceniach: show etherchannel <interfejs> port-channel czy show etherchannel detail

Aby poznać jaką decyzję podejmie przełącznik w wyborze interfejsu przez, który zostanie przekazany ruch sieciowy można posiłkować się poleceniem: test etherchannel load-balance interface port-channel <numer_interfejsu> mac <adres_MAC_źródłowy> <adres_MAC_docelowy>

Wydanie przykładowego polecenia na przełączniku SW2: test etherchannel load-balance interface port-channel 2 mac 00d0.c0d7.2dd4 0002.fc26.2494 spowoduje wykonie testu, którego efektem będzie informacja o wyborze danego interfejsu - ramka zostanie wysłana z wykorzystaniem interfejsu Fa0/1

I tak już na zakończenie jeszcze jedna uwaga na konfigurację kanału EtherChannel w środowiskach w których korzysta się z sieci VLAN.

Aby pokazać problem na przykładzie przyjęto następującą topologię sieciową. Pomiędzy dwoma przełącznikami SW1 oraz SW3 skonfigurowano kanał EtherChannel za pomocą protokołu LACP. Kanałowi LAG został przypisany identyfikator 2 (interfejs Port-Channel 2) Do każdego z przełączników został podłączony host, który należy do sieci VLAN 10.

W tak zbudowanej sieci sprawdźmy czy Host1 potrafi nawiązać poprawną komunikację z Hostem2. Jak widać poniżej test ping kończy się niepowodzeniem.

Tak więc rodzi się pytanie - Co jest powodem braku komunikacji pomiędzy komputerami? Aby odpowiedzieć na postawione pytanie należy sprawdzić ustawienia interfejsu logicznego Po2. Ustawienia zweryfikujemy za pomocą komendy: show interfaces Po2 switchport Czytelnik mający styczność z sieciami VLAN pewnie już wie w którym kierunku należy pójść by problem rozwiązać dla tych zaś którzy z tematyką nie do końca są obeznani już śpieszę z odpowiedzią. Winą braku łączności pomiędzy hostami jest sposób konfiguracji interfejsów wchodzących w skład kanału LAG. Interfejsy te pracują w trybie access co oznacza, że ruch sieciowy będzie przekazywany tylko pomiędzy urządzeniami przypisanymi do domyślnej sieci VLAN1. Skoro interfejsy fizyczne pracują w trybie access interfejs logiczny Po2 odziedziczy to ustawienie i również w tym trybie będzie pracował.

Aby móc przesłać ruch sieciowy należący do różnych VLAN-ów kanał EtherChannel pomiędzy przełącznikami musi pracować w trybie magistrali bądź mówiąc inaczej w trybie trunk.

Aby poprawić konfigurację musimy zmienić tryb pracy interfejsów fizycznych. Konfigurację rozpoczniemy od przełącznika SW1. W tym celu wydajmy polecenie: interface range f0/3-4 (punkt 1) tak by przeprowadzić za jednym zamachem konfigurację wszystkich interfejsów fizycznych budujących łącze LAG. Aby zmienić tryb pracy interfejsu na trunk należy wydać polecenie: switchport mode trunk (punkt 2) Niestety wydanie polecenia kończy się niepowodzeniem gdyż domyślnie jest ustawiona opcja Auto - przełącznik ma możliwość prowadzenia komunikacji poprzez łącze trunk z wykorzystaniem enkapsulacji bazującej na protokole 802.1Q bądź ISL. Tak wiec by wydanie komendy zakończyło się sukcesem należy zdecydować się na jeden z protokołów. Protokół ISL jest rozwiązaniem starszym więc nie pozostaje nam nic innego jak zdecydowanie się na protokół 802.1Q. Aby łącze trunk mogło prowadzić enkapsulację pakietów z wykorzystaniem protokołu 802.1Q należy wydać polecenie: switchport trunk encapsulation dot1q (punkt 3). Po wydaniu polecenia, ponowna próba ustawienia pracy łącza na trunk kończy się sukcesem (punkt 4). Wydanie wszystkich tych poleceń spowoduje wyłączenie i ponowne włączenie interfejsów fizycznych oraz powiązanego z tymi interfejsami łącza Po2.

Proces konfiguracji możemy również obserwować na switchu SW3.

Uważnego czytelnika analizującego powyższe listeningi może zastanowić komunikat: Interface Port-channel2, changed state to up Bo czemu interfejs pracuje skoro zmiana trybu pracy interfejsów została przeprowadzona tylko na przełączniku SW1? Odpowiedź jest dość prosta - O zmianę konfiguracji pozostałych interfejsów (również przełącznika sąsiedniego) zadbał protokół LACP.

Przeglądając stan konfiguracji portu Po2 na przełączniku SW1 dochodzimy do wniosku, iż pracuje on w trybie magistrali tak więc kanał ma możliwość przenoszenia ramek należących do różnych sieci VLAN.

Podobne spostrzeżenia poczynimy po stronie przełącznika SW3. Różnica w konfiguracji pomiędzy przełącznikami jest taka iż na przełączniku SW1 ustawienia zostały zdefiniowane przez administratora a na switchu SW3 na wskutek negocjacji.

Ostatnim etapem jest sprawdzenie efektów przeprowadzonej konfiguracji. Tak więc sprawdźmy ponownie czy Host1 uzyskał możliwość komunikacji z Hostem2. Przeprowadzona próba ping kończy się sukcesem.

I to by było na tyle. Mam nadzieję, że po tej dawce informacji samodzielna konfiguracja kanału EtherChannel nie będzie żadnym problemem.

BIBLOGRAFIA:

https://www.freeccnaworkbook.com/workbooks/ccna/configuring-a-port-channel-interface

http://ciscoiseasy.blogspot.com/2010/11/lesson-24-layer-2-etherchannel.html

http://www.dummies.com/how-to/content/etherchannel-configuration.html

http://www.cisco.com/c/en/us/support/docs/lan-switching/etherchannel/12023-4.html

http://packetpushers.net/understand-etherchannel-load-balancing-catalyst-switches/

http://www.firstdigest.com/2010/08/cisco-port-channel-load-balancing-explanation/

http://www.cisco.com/c/en/us/support/docs/lan-switching/etherchannel/12023-4.html