UniFi Zone Matrix: stany reguł dla sieci serwerowej, CCTV i IoT

Zarządzanie regułami zapory sieciowej (firewalla) za pomocą tradycyjnych list LAN IN / LAN OUT bywa koszmarem, zwłaszcza gdy sieć rozrasta się o urządzenia IoT, kamery i prywatne serwery. Ubiquiti zrewolucjonizowało ten proces w ekosystemie UniFi dzięki Zone Matrix – wizualnej reprezentacji polityk bezpieczeństwa.

Jak widać na powyższym print screenie, Zone Matrix to siatka, w której oś Y to Źródło (Source) ruchu, a oś X to Cel (Destination).
Zrozumienie Stanów Polityk
Matryca używa bloków oznaczonych kolorami do określania zachowania sieci:
- Allow All (Zielony): Źródło może swobodnie nawiązywać nowe połączenia z Celem.
- Allow Return (Niebieski): Źródło nie może inicjować nowych połączeń z Celem. Może jedynie odpowiadać na ruch, który został najpierw zainicjowany przez Cel (tzw. pakiety powrotne).
- Block All (Czerwony): Całkowita izolacja. Żaden ruch nie przejdzie od Źródła do Celu.
Scenariusz 1: Zabezpieczenie Sieci Serwerowej (Server Network)
Dobrą praktyką bezpieczeństwa jest zezwolenie zaufanym urządzeniom wewnętrznym na dostęp do lokalnego serwera (np. NAS lub Home Assistant), przy jednoczesnym zablokowaniu serwerowi możliwości aktywnego skanowania lub łączenia się z prywatnymi urządzeniami (na wypadek jego zhakowania).
Print-Screen na górze pokazuje, jak to osiągnąć:
- Ustawić politykę ze Źródła: Internal do Celu: Server Network na Allow All (Zielony). To pozwala laptopowi połączyć się z serwerem.
- Ustawić politykę ze Źródła: Server Network do Celu: Internal na Allow Return (Niebieski). Taka konfiguracja sprawia, że serwer „widzi” zapytania z laptopa i może na nie odpowiedzieć, ale fizycznie nie jest w stanie samemu zainicjować nowego połączenia do sieci wewnętrznej.
Scenariusz 2: Izolacja CCTV i Smart Home (IoT)
Urządzenia Smart Home i kamery IP są notorycznie podatne na ataki. Nigdy nie powinny mieć swobodnego dostępu do głównej, zaufanej sieci. Zone Matrix pozwala stworzyć kuloodporną izolację:
- Przypisać kamery i urządzenia smart do dedykowanego VLANu, a ten do konkretnej Strefy (nadaje się strefa DMZ, Hotspot albo własna strefa „IoT”).
- Ustawić Źródło: Internal do Celu: IoT na Allow All. Pozwala to smartfonowi w głównej sieci Wi-Fi na lokalne podglądanie kamer czy sterowanie światłem.
- Ustawić Źródło: IoT do Celu: Internal na Allow Return (lub Block All, jeśli sterowanie odbywa się wyłącznie przez chmurę).
- Aby zablokować kamerom dostęp do internetu, ustawić Źródło: IoT do Celu: External na Block All.
Komentarze: 2
Macierz czytana jako źródło w pionie i cel w poziomie jest znacznie bardziej zrozumiała niż listy reguł, do których trzeba wracać co pół roku.
Pytanie o ziarnistość: czy pojedyncze urządzenie może trafić do innej strefy niż reszta jego VLAN-u? U nas jeden serwer w sieci IoT powinien mieć szersze uprawnienia niż pozostałe urządzenia obok niego.
Nie może — strefy grupują sieci, nie pojedyncze urządzenia. Przypisanie odbywa się na poziomie VLAN-u i to jest świadome uproszczenie tego modelu.
Zostają dwie drogi. Pierwsza to własny VLAN dla tego serwera: więcej pracy przy wdrożeniu, ale reguła pozostaje czytelna, a za rok nikt nie zgaduje, dlaczego jedno urządzenie zachowuje się inaczej. Druga to zawężenie polityki wewnątrz komórki macierzy do konkretnego adresu — działa od razu, natomiast reguła zaczyna zależeć od tego, czy adres pozostanie ten sam.
Przy drugiej drodze rezerwacja DHCP jest częścią zabezpieczenia, nie wygodą: adres przydzielony dynamicznie zmieni się przy najbliższym dłuższym wyłączeniu, a reguła nadal będzie wskazywać poprzedni. Wtedy albo serwer traci dostęp, albo — gorzej — dostaje go inne urządzenie, które właśnie przejęło ten adres.