Bezpieczeństwo w sieciach komputerowych ma wiele obliczy. Jednym z podstawowych wyzwań jakie przed nami stoją jest stworzenie sieci, w której mamy kontrolę nad tym kto do niej uzyskuje dostęp. Potrzeba tego typu nadzoru rośnie wraz z rozmiarem organizacji, w której przyszło nam pracować. Z pomocą przychodzi nam framework AAA oraz dwa protokoły w naturalny sposób z nim powiązane – RADIUS oraz TACACS+. Przyjrzyjmy im się bliżej.
Czym jest AAA?
Zacznijmy od zdefiniowania czym jest AAA na przykładzie małej firmy, w której chcemy mieć nadzór nad dostępem do przestrzeni biurowej. Rozłóżmy skrót „AAA” na czynniki pierwsze:
Authentication
Autentykacja słu… wróć! Po polsku mówimy uwierzytelnianie! Mój wykładowca od Technologii Sieciowych był bardzo skuteczny w wybijaniu nam z głów angielskich słówek i zastępowaniu ich polskimi. W tym miejscu chciałbym gorąco pozdrowić doktora Bilskiego z Politechniki Poznańskiej 🙂 To tyle tytułem dygresji. Wróćmy do tematu…
Uwierzytelnianie służy nam do określania czy dana osoba jest faktycznie osobą za jaką się podaje. Jest to więc operacja weryfikowania tożsamości. W naszym przykładzie pan Jan Kowalski chce otworzyć drzwi do biura. Jak jednak sprawdzić, że faktycznie mamy do czynienia z Janem Kowalskim?
Sposobów jest wiele. W tej sytuacji moglibyśmy się posłużyć odciskiem palca w celu weryfikacji tożsamości, ponieważ odcisk każdego z nas jest unikalny. Poza odciskiem możemy wykorzystać inne metody biometryczne, takie jak skanowanie siatkówki oka, rozpoznawanie twarzy czy też głosu. Wymienione sposoby uwierzytelniania klasyfikujemy jako metody oparte o coś czym jesteś (something you are).
Do uwierzytelniania można również używać coś co wiesz (something you know) – czyli np. hasło lub PIN. Ostatnią kategorią jest coś co masz (something you have) – przykładowo identyfikator, fizyczny klucz do zamka czy też token. Wykorzystanie do uwierzytelniania więcej niż jednej metody nazywamy uwierzytelnianiem wieloskładnikowym (MFA – Multi Factor Authentication). W scenariuszu z drzwiami byłoby to np. „odbicie się” identyfikatorem na czytniku przy drzwiach i wpisanie PINu na pin-padzie.
Authorization
Gdy wiemy już z kim mamy do czynienia to możemy wykorzystać tę informację do stwierdzenia czy dany delikwent ma prawo dostępu do danego zasobu. Przykładowo pan Jan Kowalski może mieć prawo otwierania tylko niektórych drzwi w firmie – może wejść do kantyny ale nie może do serwerowni. Proces sprawdzania uprawnień do dostępu nazywamy autoryzacją. W świecie sieci komputerowych autoryzujemy komendy wydawane na urządzeniach sieciowych. Przykładowo pracownik NOC-a może mieć uprawnienia do wydawania jedynie komend show, podczas gdy druga linia wsparcia może wchodzić również w tryb konfiguracji urządzenia.
Accounting
Ostatnią składową framework’u AAA jest accounting. W tym przypadku nigdy nie słyszałem żeby dr Bilski nazwał to księgowaniem, ani jakimkolwiek innym polskim słowem. Jeśli masz pomysł na polski odpowiednik słowa accounting to daj znać w komentarzu.
Accounting jest procesem zbierania informacji i logów dotyczących poprzednich dwóch etapów – czyli kto uzyskał dostęp, do czego i kiedy. Dane te są zbierane przede wszystkim w celu przeprowadzania audytów bezpieczeństwa.
Podstawy działania RADIUS
RADIUS jako protokół jest prawie moim rówieśnikiem – powstał w roku 1991. O ile ja się nie czuję staro, to w świecie technologii jest to mnóstwo czasu. Pomimo to RADIUS nadal dobrze się trzyma i jest powszechnie używany. Skrót RADIUS rozwijamy na Remote Access Dial-In User Service i dobrze to określa pierwotne zastosowanie tego protokołu – oryginalnie powstał on po to aby zapewniać funkcje AAA dla użytkowników wdzwaniających się do sieci za pomocą modemów. Protokół ten realizuje wszystkie trzy komponenty framework’u AAA, przy czym uwierzytelnianie i autoryzacja są ze sobą bardzo ściśle powiązane – do tego stopnia, że te funkcje są realizowane za pomocą tych samych pakietów. Accounting jest natomiast wydzielony jako osobny proces.
Starsze implementacje RADIUS-a używają portów UDP 1645 (uwierzytelnianie) oraz UDP 1646 (accounting), podczas gdy nowe wdrożenia bazują już na portach UDP 1812 (uwierzytelnianie) oraz UDP 1813 (accounting).
RADIUS jest protokołem działającym w modelu klient – serwer. W znacznej części przypadków to urządzenie końcowe (np. laptop) pełni funkcję klienta. RADIUS jako protokół transportuje zatem pakiety związane z uwierzytelnianiem, autoryzacją i accountingiem między klientem a serwerem AAA. Przykładowa wymiana pakietów może wyglądać następująco:
W kwestii zastosowań z pewnością zetkniesz się z RADIUS-em podczas połączeń w sieciach bezprzewodowych, gdzie protokół ten jest powszechnie wykorzystywany do transportowania m.in. znacznie bardziej zaawansowanego protokołu uwierzytelniania – EAP (Extensible Authentication Protocol). EAP jest między innymi odpowiedzialny za DOT1X – ale to już osobna historia.
Istotne z punktu widzenia bezpieczeństwa jest to, że RADIUS szyfruje jedynie informacje dotyczące uwierzytelniania (hasła), podczas gdy pozostała część wymiany pakietowej przesyłana jest clear-text’em.
Największą zaletą RADIUS-a jest fakt, że jest to otwarty standard, powszechnie wspierany przez prawie wszystkich producentów sprzętu sieciowego.
Podstawy działania TACACS+
TACACS+ jest protokołem stworzonym przez Cisco w 1996 roku. Skrót ten rozwijamy na Terminal Access Controller Access-Control System. Była to swego rodzaju odpowiedź na coraz to bardziej powszechny w użyciu RADIUS i w pewnym sensie okazała się ona celna. TACACS+ jako protokół oferuje wiele funkcji, których brakuje w RADIUS-ie.
Przede wszystkim TACACS+ operuje na porcie TCP 49, co powoduje, że cała komunikacja jest o wiele pewniejsza (co wynika bezpośrednio z charakterystyki TCP vs UDP). Ponadto, cała zawartość pakietów TACACS+ jest szyfrowana, co przekłada się na o wiele wyższy poziom bezpieczeństwa tego protokołu (w RADIUS możemy np podejrzeć komendy, które podlegały autoryzacji!).
Kolejną różnicą jest fakt, że TACACS+ oddziela funkcje uwierzytelniania i autoryzacji – są one realizowane osobnymi pakietami. Wynika to z zastosowania tego protokołu. RADIUS został zaprojektowany z myślą o całym framework’u AAA i jest wykorzystywany przede wszystkim do uwierzytelniania i autoryzacji dostępu do sieci. Cisco natomiast stworzyło TACACS+ głównie z myślą o zapewnieniu AAA podczas zarządzania urządzeniami sieciowymi i to właśnie w takich przypadkach jest powszechnie używany. Powoduje to, że zazwyczaj mamy do czynienia z pojedynczą wymianą pakietów uwierzytelniających, a następnie z wieloma autoryzacjami poszczególnych komend wydawanych na urządzeniu. Przykładowa wymiana pakietów TACACS+ wygląda następująco:
Sam proces autoryzacji może zachodzić na podstawie privilege level przypisanemu użytkownikowi, bądź bardziej granularnie na zasadzie weryfikacji każdej wydawanej komendy. W pierwszym przypadku określamy na przykład, że dany administrator ma uprawnienia do wydawania poleceń do privilege level = 5. Dalszą autoryzację komend wydawanych w takiej sytuacji przeprowadza już urządzenie sieciowe. Natomiast w drugim przypadku każda wydawana komenda jest wysyłana do serwera AAA, który określa czy użytkownik jest autoryzowany do jej wydania. Druga metoda jest bardziej granularna, ale z oczywistych względów mniej skalowalna i trudniejsza w zarządzaniu.
Oddzielenie funkcji uwierzytelniania i autoryzacji w TACACS+ jest dużą zaletą, ponieważ umożliwia nam używanie różnych protokołów w ramach framework’u AAA. Możemy przykładowo używać protokołu Kerberos do uwierzytelniania, a autoryzację i accounting realizować za pomocą TACACS+.
Charakterystyka działania TACACS+ powoduje, że jest to o wiele bardziej zasobożerny protokół niż RADIUS. Ponadto nie jest on tak powszechny w użyciu jak RADIUS, co wynika bezpośrednio z faktu, że nie jest to otwarty standard. Pomimo to niektórzy producenci sprzętu sieciowego (np. Dell) wspierają go i umożliwiają korzystanie z TACACS+ na ich urządzeniach.
Tak jak wspomniałem w samym tytule artykułu – są to jedynie podstawy AAA, RADIUS-a i TACACS+. Za tymi protokołami kryje się jednak o wiele więcej. Oba protokoły są dziś powszechnie używane, z dużą przewagą RADIUS-a. Warto je znać nie tylko od teoretycznej, ale również od praktycznej strony.
Porównanie RADIUS i TACACS
Znając już szczegóły dotyczące działania każdego z dwóch protokołów może zastanawiasz się jak wyglądało by ich porównanie. Przeczytasz o tym w naszym darmowym NSSletterze – mailingu dla sieciowców głodnych wiedzy.
Dołączając uzyskasz dostęp również do archiwum – tematykę tego artykułu rozszerzyliśmy w NSSletterze 054. Rozwiń swoją wiedzę już teraz i zapisz się używając formularza poniżej.
Tak jak kolega napisał Rozliczanie ew Księgowanie 😉 , z lepszym polskim zamiennikiem się nie spotkałem. Co do TACACS+ to wspiera go też miedzy innymi PALO ALTO , BIG-IP F5 (w sumie większość urządzeń ocierających się o klasę ENT ), no i przez możliwość nadawania privilege oraz wybranych komend w autoryzacji można dedykowanymi kontami serwisowymi zrobić np. backup konfiguracji urządzenia czy odczytywać stan / liczniki interfejsu itp , rzeczy które średnio wyciąga się za pomocą SNMP .
Dokładnie, dzięki za dopowiedzenie!
Proste! Accounting – rozliczanie 🙂
Dobre! Ale nadal mi coś nie leży to słowo na języku… czy w takim razie zamiast \”audytu\” powinniśmy mieć \”dzień rozliczenia\”? 😀
Serwus,
Jakiś czas miałem zaimplementowany tacacs+, zainstalowany na debianie do autoryzacji na przełacznikach, ale radius wydał mi się ciekawszy bo spiąłem go do pracy z dwoma kontrolerami domeny, w sposób następujący: Primary radius + primary AD, secondary radius + secondary AD. Pomimo braku \”encrypt entire packet\”, radius daje radę 🙂
A pewnie, RADIUS nadal oferuje sporo możliwości i też można się nim nieźle bawić ^^
Dobry artykuł!
Dzięki Bruno 🙂
Miśki i to mi się podoba 🙂 Super, że opisujecie od podstawowych informacji a nie co jak niektórzy od razu walą szczegółami a potem nic z tego nie wiadomo. Bardzo mi się podoba 🙂
Fajnie, że się spodobało 🙂 Niektórym to nie przypada do gustu, ale staramy się, żeby artykuły były zrozumiałe dla wszystkich, a nie tylko dla tych bardziej doświadczonych 🙂
super poradnik dowiedziałem sie wszystkiego. pozdrawiam z rodzinka.
Dziękujemy i również pozdrawiamy 🙂
Accounting – ewidencja
Bezsensowne i szkodliwe jest naciskanie by używać polskich odpwiedników. Realnie nie używa się ich w codziennym życiu i pracy. Niestety też Wasze teksty pełne wiedzy i madrości sa dużo mniej czytelne i zrozumiałe </3
Dzięki za komentarz Anna. Cóż… ile ludzi, tyle opinii. Jedni wolą używanie angielskich terminów bo są one bardziej „naturalne” (co wynika głównie z tego, że się posługują nimi na co dzień w pracy). Ja należę do tej grupy. Ale są też ludzie, którzy nie mają takiej styczności z angielskimi terminami i są one dla nich niezrozumiałe. Ba, takie osoby często argumentują, że skoro dany termin ma polski odpowiednik, to czemu go nie stosować w imię krzewienia naszej pięknej, polskiej mowy 🙂 I poniekąd mają w tym rację.
Wszystkim się nie dogodzi – natomiast my staramy się iść mniej więcej pośrodku.
Co do zasady gdzie tylko się da używamy dobrze brzmiące polskie terminy (na przykład „uwierzytelnianie” zamiast zapożyczonego „autentykacja”, „przełącznik” zamiast „switch” itp.). W sytuacji gdzie nie ma dobrego polskiego tłumaczenia lub brzmi ono nienaturalnie (na przykład „trasownik” lub „ruter” zamiast angielskiego „router”, lub próby tłumaczenia słów takich jak „framework”, „workflow”) to pozostajemy przy oryginalnym, angielskim terminie.
Ktoś kiedyś uparł się, że w dokumentacji muszę używać polskich określeń. Po tym jak napisałem że „w celu sprawdzenia poprawności ustawień należy wysłać świst do maszyny usługowej” ten ktoś zmienił zdanie… stwierdzenie że „w celu weryfikacji należy wykonać ping do serwera” jest jakoś bardziej zrozumiałe 🙂
Accounting w kontekście IT tłumaczy się jako rozliczalność.
Ja bym użył słowa „Akwizycja” (danych) 🙂 Co myślicie?