Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.


26.10.2020

Nowa wersja nVision

Można już pobierać nową wersję nVision
26.10.2020

Monitorowanie infrastruktury

Vertiv Environet Alert
23.10.2020

Telefonia w chmurze

NFON Cloudya
23.10.2020

Nowości w EDR

Bitdefender GravityZone
23.10.2020

Wykrywanie anomalii

Flowmon ADS11
23.10.2020

Mobilny monitor

AOC 16T2
22.10.2020

HP Pavilion

HP zaprezentowało nowe laptopy z linii Pavilion.
22.10.2020

Inteligentny monitoring

WD Purple SC QD101
22.10.2020

Przełącznik 2,5GbE

QNAP QSW-1105-5T

Systemy NAC. Opensourcowy PacketFence (cz. 2)

Data publikacji: 09-05-2017 Autor: Jacek Kurek

Jedną z wielu zalet PacketFence’a jest możliwość integracji z urządzeniami sieciowymi wiodących producentów. Sprawdzimy, jak przebiega ta integracja i co z niej wynika w aspekcie ochrony dostępu do zasobów naszej infrastruktury. Czy softwarowy NAC może rzeczywiście konkurować z komercyjnymi rozwiązaniami sprzętowymi?

W poprzednim numerze miesięcznika („IT Professional” 4/2017, s. 37) przedstawiliśmy projekt PacketFence – oprogramowanie pozwalające na zbudowanie rozwiązania typu NAC-a (skrót od Network Access Control). W artykule opisano skrótowo jego możliwości i pokazano, jak wdrożyć kontrolę dostępu do sieci w wypadku, gdy nasza infrastruktura zbudowana jest np. w oparciu o niezarządzalne komponenty sieciowe (często spotykane realia szczególnie w małych organizacjach). Przyjmując takie założenie, uruchomiliśmy PacketFence’a w tzw. trybie egzekwowania liniowego (Inline enforcement), a dzięki funkcjonalności captive portal użytkownicy nawiązujący komunikację z zasobami światowego internetu przekierowywani byli na specjalną stronę autoryzacyjną, gdzie musieli potwierdzić swoją tożsamość. Dopiero po poprawnej autoryzacji możliwość komunikacji z internetem była odblokowywana dla danego źródłowego adresu IP.

PacketFence jest jednak projektem o znacznie większych możliwościach funkcjonalnych i konfiguracyjnych, niż opisano to miesiąc temu we wspomnianym artykule. Dlatego w niniejszym tekście pokażemy bardziej zaawansowaną metodę kontroli zarządzanej sieci i skupimy się na mechanizmie leżącym u podstaw NAC-a, czyli protokole 802.1x. Pokażemy też na wybranym przykładzie urządzenia sieciowego procedurę jego integracji z PacketFence’em.

> KOMPATYBILNOŚĆ

Uruchomienie NAC-a wymaga opracowania takiej konfiguracji, w której urządzenie lub oprogramowanie realizujące funkcjonalność kontrolera dostępu będzie mogło udzielać urządzeniom klienckim dostępu do infrastruktury lub zabraniać go już w warstwie fizycznej – przez odmowę dostępu do portu lub przyporządkowanie go (na podstawie odpowiednio zdefiniowanych polityk) do odpowiedniej wirtualnej sieci lokalnej (VLAN). Aby współpraca ta mogła przebiegać poprawnie, strona kontrolowana i kontrolująca muszą ze sobą współpracować poprzez implementację tych samych mechanizmów związanych z Network Access Control.

Lista sprzętu, który można skonfigurować do współpracy z PacketFence’em, jest godna uwagi i zawiera popularne modele urządzeń sieciowych (konwencjonalnych sieci przewodowych i Wi-Fi) większości renomowanych producentów. Pełny ich wykaz wraz z przykładowymi konfiguracjami znajdziemy w dokumentacji dostępnej na stronie domowej producenta (packetfence.org/doc dokument Network Devices Configuration Guide).

W naszym środowisku testowym wykorzystaliśmy PacketFence’a w wersji 6.5.1 (zainstalowany na maszynie wirtualnej w środowisku najnowszego wydania Debiana Jessie) oraz przełącznik sieciowy Cisco Catalyst 2960G.

> SPOSOBY ZARZĄDZANIA

Opisując projekt PacketFence w poprzedniej części cyklu, pokazaliśmy, jak skorzystać z jednej z trzech opcji konfiguracyjnych nazywanej Inline enforcement. W takim wariancie PacketFence nie wymaga aktywnej współpracy z żadnym urządzeniem sieciowym. Sam jest bramą i punktem kontrolnym dla ruchu generowanego z naszej sieci lokalnej na zewnątrz. Omawiany projekt oferuje jeszcze inny interesujący tryb pracy, określany jako Out of band, który daje zdecydowanie większe możliwości kontroli dostępu do sieci. W wypadku opcji „egzekwowania liniowego” mogliśmy wyłącznie kontrolować komunikację z internetem i to za pomocą metody blokowania lub ograniczania ruchu wyjściowego, generowanego przez poszczególne adresy IP z danego LAN-u. Ponieważ jednak ochrona działała wyłącznie w warstwie trzeciej, nie mieliśmy większego wpływu na to, jakie urządzenia są podłączone do LAN-u i jakiego typu ruch generują. W wypadku braku segmentacji sieci lokalnej Inline enforcement w żaden sposób nie chroni zasobów wewnętrznych naszej infrastruktury. W takim wypadku można więc jedynie mówić o funkcjonalności quasi NAC.

 

[...]

 

Autor jest administratorem systemów Linux i sieci w firmie specjalizującej się w rozwiązaniach IT dla sieci handlowych oraz outsourcingu usług IT m.in. dla dużych sklepów internetowych. Zajmuje się także audytami bezpieczeństwa. Od kilkunastu lat publikuje w prasie informatycznej.

Artykuł pochodzi z miesięcznika: IT Professional

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"