Podkast 22T49 IP Phone i 802.1x

WERSJA TEKSTOWA

Cześć. Witam Cię w dzisiejszym odcinku mojego podkastu. Temat to telefony IP i 802.1x. To jest ciekawe połączenie tych dwóch wątków bo jeśli chodzi o 802.1x to wiadomo, cel jest taki aby uwierzytelnić urządzenie końcowe, wiedzieć co to jest za urządzenie, co to jest za użytkownik i podłączyć z odpowiednim profilem. W niektórych jednak instalacjach dzieje się tak, że już jest sieć LAN zbudowana w oparciu o schemat przełącznik -> telefon IP i do tego telefonu podpięty komputer końcowy. Mając taką sytuację i chcąc wdrożyć 802.1x pojawiają się następujące pytania:

a) Jak my podłączamy telefon do naszego przełącznika, skąd ten przełącznik wie jakie są VLANy Voice czyli VLAN Voice i jakie są VLAN Data, który jest tagowany a który nie tagowany, jaką przypisać adresację albo konfigurację dla telefonu. To są takie typowe problemy związane z tą koncepcją podłączania komputera przez telefon. Natomiast jeśli planujemy dodatkowo wdrożyć 802.1x to nakładamy na tą całą procedurę jeszcze nasz proces uwierzytelniania. No i teraz jak to może wyglądać?

Pierwszy krok jest taki, że najczęściej jak się taki telefon podłącza do sieci to najszybciej pojawia się komunikacja z komputerem, czyli ten wewnętrzny przełącznik jest uruchamiany najszybciej i po prostu pakiety nietagowane są przekazywane od komputera do przełącznika. Przełącznik po otrzymaniu takiego pakietu standardowo mówi: ok, jakieś urządzenie w VLANie nie tagowanym czyli sprawdzam uwierzytelnienie i przypisuje go do VLANu w zależności od tego co otrzymam. Jeśli przy 802.1x nie otrzyma żadnej informacji dodatkowej taki przełącznik o numerze VLANu, czy nazwie. To wtedy przypisuje po prostu do VLANu dopisanego do tego portu. Jeżeli ten przełącznik otrzyma informacje, że dla tego urządzenia to VLAN 100, to oznacza to, że na tym porcie VLAN 100 będzie nie tagowany. Jest to sytuacja w pierwszym kroku uwierzytelniania 802.1x.

Co się dzieje w drugim kroku? Później następuje pełne uruchomienie tego telefonu i telefon stara się podłączyć do przełącznika najczęściej tagowanym VLANem. Dla swojej ramki ethernetowej, którą wysyła, już zakłada tagowanie i wysyła tą informację dla przełącznika. Teraz przełącznik powinien być tak skonfigurowany, że akceptuje już przyjmowanie tagowanych ramek, dlatego, że ta komunikacja z suplikantem 802.1x jest po L2, bo tam nie ma żadnego adresu IP jeszcze. Chodzi o to, żeby ten przełącznik w odpowiednim kontekście VLANu przyjął to zapytanie 802.1x. Oczywiście przełącznik powinien też być w trybie uwierzytelniania per MAC adres czy per użytkownik lub per urządzenie a nie per port. Bo taki tryb też jest. Takie wdrożenie też można zrobić.

Wtedy scenariusz wyglądałby tak: jeśli mamy uwierzytelnianie per port to zakładamy, że uwierzytelnia się najpierw komputer, czy pierwsze urządzenie, otwiera się port a ten port już ma skonfigurowane informacje dotyczące VLANu nietagowanego i tagowanego. Więc jak przychodzi pakiet z telefonu to tam już zakładamy, że nie ma już suplikanta, nie ma próby uwierzytelnienia, tylko po prostu przychodzi pakiet tagowany. Tak jakbyśmy nie mieli w ogóle 802.1x. W momencie w którym ktoś odłączy komputer i będzie sam telefon to wtedy telefon próbuje wysłać taki pakiet i ponieważ nie ma suplikanta to się nie uwierzytelnia i port nie działa. Jeżeli nic więcej nie skonfigurujemy to znaczy, że gdy użytkownik nie podepnie komputera do telefonu to telefon też nie działa. To jest taki trochę minus.

Wróćmy teraz do scenariusza, że telefon też ma suplikanta 802.1x. Wtedy próbuje się uwierzytelnić. Jeśli mu się uda to zostaje przypisany odpowiedni tagowany VLAN i wtedy wszystko powinno działać właściwie. Natomiast możemy przypisywać tagowane i nietagowane VLANy dla telefonu i komputera ale przy uwierzytelnianiu, przy tej metodzie wykorzystującej uwierzytelnianie i przypisywanie do Voice VLANu, tu nie mamy informacji o priorytecie. Czyli w przypadku jak byśmy chcieli uwierzytelniać, przypisywać do VLANu i jeszcze do tego nakładać priorytet Voice, to musielibyśmy jeszcze dodatkowo zastosować mechanizm np. wypychania informacji o profilu QS z Radiusa. Tak to zapewne będzie działać.

Alternatywnie można rozważyć czy po LDP ten telefon nie potrafi być wykryty na przełączniku bo jeśli nie używamy 802.1x to bardzo często w dzisiejszych implementacjach używamy po prostu LDP do przekazywania podstawowej informacji do telefonu. Czyli mówimy: no dobrze, to podłączyłeś się, jesteś w sieci ale musimy w jakiś sposób powiedzieć do telefonu jaki ID tagowanego VLANu ma wysyłać. Czyli przełącznik ma zapisaną informację, że Voice VLAN to jest ID VLANu takie i teraz jeśli się podłącza ten telefon, to przełącznik po LLDP wysyła informację do telefonu i tagowanym VLANem dla Ciebie powinien być VLAN np. 200. Wtedy telefon wie jaki ID telefonu powinien przypisywać. Można jeszcze ten temat rozwiązać w ten sposób, że statycznie w konfiguracji telefonu przypisujemy jakie ID VLANu ma wykorzystywać i jaki ma być ten podział pomiędzy VLAN Data i Voice.

Nadal jest jeszcze temat do rozpatrzenia markowania QS. Mamy możliwość markowania tego ruchu na przełączniku. Czyli mówimy: jeśli jest w tym VLANie to przypisuje mu taki znacznik jakości ale oczywiście możemy też to robić na telefonie. Tutaj jest taki dylemat do rozwiązania: czy my ufamy markowaniu urządzenia końcowego. To jest trochę powiązane z 802.1x. Jeśli wiemy, że to urządzenie jest zaufane to wtedy jesteśmy bardziej skłonni ufać markowaniu QS, że te pakiety są Voice i powinny być przeprocesowane z wyższym priorytetem ważności. Więc jeżeli uwierzytelniamy to ja bym był dużo bardziej skłonny do uwierzenia, że ten profil QS z telefonu wychodzący będzie dla nas wiarygodny. Gdy ten telefon nie jest uwierzytelniany to jest z tym problem, że przecież zawsze może być tak, że ktoś odłączy telefon, podłączy laptopa, który będzie się podawał za ten telefon no i w związku z tym uzyska jakiś dodatkowy dostęp. Oczywiście jeśli mówimy już o etapie, że nie mamy uwierzytelnienia i ktoś się podszywa pod telefon i dostaje się do głosowego VLANu i tam próbuje coś atakować to w zasadzie nas ten QS w tym kontekście nie boli jakoś specjalnie mocno bo naszym zmartwieniem jest to, że jest po prostu niebezpiecznie.

Wracając do podstawowego wątku chcielibyśmy jeśli to tylko możliwe uwierzytelniać każde urządzenie: telefon, PC. Najlepiej suplikantem 802.1x i najlepiej jeśli możemy zainstalować certyfikaty. W związku z tym do takiego modelu dążymy, niestety rzeczywistość jest różna. Jeśli mamy urządzenia takie, które nie wspierają suplikanta 802.1x to tego nie przeskoczymy. Pozostaje nam wtedy jedynie Mac authentication, co generalnie mechanizmem bezpieczeństwa nie jest. Jest tylko jakimś rodzajem klasyfikacji danego urządzenia.

Więc jeśli byśmy teraz chcieli wrócić do tego procesu: jak wygląda podłączenie użytkownika komputerowego, telefonu i 802.1x. Najlepiej gdybyśmy mieli suplikanty po obu stronach i certyfikaty na obu urządzeniach. Podłączamy wtedy w poszczególnych VLANach. VLANy te przypisujemy z przełącznika. Z tą uwagą, że trzeba jeszcze uwzględnić proces konfiguracji samego telefonu IP. Jeśli to jest konfiguracja statyczna to nie ma co uwzględniać. Po prostu ten telefon wie w jakiej konfiguracji. W jakiej VLAN tagowany powinien być przypisywany i wszystko jest jasne. Gdy to jest temat bardziej operatorski, na większą skalę, że za każdym uruchomieniem telefonu to urządzenie odpytuje serwer centralny o swój config i dopiero ten config ładuje i się uruchamia, to musimy zaplanować w tym całym naszym procesie uwierzytelniania 802.1x tą możliwość dostępu do tego centralnego serwera.

Tu oczywiście też jest ten wątek poruszony, czy powiązany z tym, jak ma ten certyfikat zostać dostarczony na urządzenie, które czyści sobie konfigurację po każdym restarcie. Wtedy musielibyśmy zaplanować rozróżnianie takich telefonów lub domyślne wrzucanie do jakiegoś VLANu dedykowanego nierozpoznanego urządzenia z możliwością jego łączenia się do tego serwera z konfiguracją i certyfikatem. To już nie jest dla nas super wygodne i atrakcyjne bo jeśli atakujący może się za taki telefon podszyć, nieznane urządzenie wpadnie do tego VLANu, może się odnieść do tego serwera gdzie są konfiguracje i certyfikaty to gdzie tu jest bezpieczeństwo… To samo sobie przeczy. Sam certyfikat to nie jest problem ale chodzi o to gdzie przechowujemy i w jaki sposób klucze prywatne do tego certyfikatu. Więc jeśli ten telefon nie ma żadnej konfiguracji to musielibyśmy dostarczyć z tego centralnego serwera klucze prywatne, certyfikat, który mógłby być pobrany przez każdego. To nie ma większego sensu.

Jeśli chodzi o uwierzytelnianie to zakładamy, że ta konfiguracja powinna być wykonana już wcześniej na urządzeniu. Co nadal oznacza, że jest do rozważenia taka możliwość, że dana osoba zajmująca się administracją i telefonami najpierw musi mieć te telefony albo prekonfigurowane – zanim pojadą do lokalizacji czy zostaną podłączone do takiego przełącznika albo my w tej naszej koncepcji musimy taki VLAN provisioning’u przewidzieć. Czyli możemy go tam wrzucić do pierwszej konfiguracji (wszystkie urządzenia, które nie uwierzytelnią się właściwie możemy tam dorzucić). Do tego VLANu powinien mieć dostęp taki administrator skryptem, mechanizmem, systemem zarządzania obojętnie jakim i stworzyć taką konfigurację na tym urządzeniu zapisaną w pamięci tego urządzenia razem z certyfikatem a następnie ponownie próbować podłączyć to urządzenie, ten telefon do naszego przełącznika. Dzięki temu mamy możliwość wykreowania bezpiecznego scenariusza podłączenia urządzeń końcowych aczkolwiek komplikuje nam się cały proces provisioningu, konfiguracji i podłączania tego naszego całego rozwiązania IP telefonii. Coś za coś. Nie da się mieć bezpiecznie i nie wkładać w to dodatkowej pracy.

Jeśli miałbym super gotowe zintegrowane rozwiązanie telefonii IP z 802.1x z jakimś konkretnym rozwiązaniem NAC to wtedy się da. Jednak ja jeszcze takiego rozwiązania nie widziałem. Zważywszy na to, że telefonia IP jest raczej coraz bardziej niszowa i ona tam pozostanie, czyli będą takie rozwiązania ale nie są one powszechne, to raczej nie ma się co spodziewać, że tu jest jakiś duży potencjał dla producentów oprogramowania, że będą automatyzować ten akurat konkretny proces. Jeśli masz jakieś pytania to pisz w komentarzu, na dzisiaj Ci dziękuję i do usłyszenia już za tydzień.