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

Juniper jako firewall

Data publikacji: 20-12-2019 Autor: Piotr Wojciechowski

Na rynku urządzeń bezpieczeństwa jest obecnie wielu graczy walczących o względy klienta szeroką gamą produktów czy nowatorskimi funkcjami. Jednym z nich jest firma Juniper, której seria SRX cieszy się niesłabnącą popularnością. Jednak nie tylko na urządzeniach tej serii wdrożymy funkcje bezpieczeństwa, takie jak listy kontrolne ACL czy translację adresów NAT. Wspólną cechą urządzeń tego producenta jest system operacyjny JunOS.

 

Filtrowanie ruchu to zadanie realizowane głównie przez firewalle. To one są pozycjonowane jako specjalne mechanizmy bezpieczeństwa. W dzisiejszych czasach samo filtrowanie to jednak za mało i firewalle są wyposażane w zaawansowane mechanizmy inspekcji pracujące całkowicie lokalnie oraz takie, które współpracują ze scentralizowanymi rozwiązaniami chmurowymi. Wszystkie te rozwiązania mają jeden wspólny mianownik w postaci mechanizmów klasyfikujących i filtrujących ruch. Zazwyczaj nazywa się je listami kontrolnymi ACL lub politykami.


Większość urządzeń z logo Junipera działa pod kontrolą systemu operacyjnego JunOS. Jedynie najstarsze modele dawno wycofanych serii mają zainstalowany system ScreenOS. Tymi urządzeniami w tym artykule nie będziemy się zajmować. JunOS jest uniwersalnym systemem operacyjnym, który spotkamy zarówno na firewallach serii SRX, przełącznikach z rodziny EX, jak i na routerach serii MX.


Na każdym urządzeniu działającym pod kontrolą JunOS skonfigurujemy polityki bezpieczeństwa w identyczny sposób, co na pewno każdemu administratorowi ułatwi pracę. Jedynym ograniczeniem są możliwości funkcjonalne fizycznego urządzenia. Sama konfiguracja jest prosta i intuicyjna. W wielu firmach urządzenia Junipera znalazły zastosowanie i są wykorzystywane zarówno w szkielecie sieci, jak i jako urządzenia dostępowe. Przyjrzyjmy się zatem, w jaki sposób konfigurujemy podstawowe mechanizmy bezpieczeństwa.

 

> DWA MODELE KONFIGURACJI FIREWALLA

 

Osoby, które dużo pracowały z routerami czy firewallami firmy Cisco, są prawdopodobnie przyzwyczajone do tego, że chcąc zablokować lub odblokować ruch pomiędzy dwoma urządzeniami, muszą utworzyć listę ACL, a następnie przypisać ją w kierunku in lub out do interfejsu fizycznego lub logicznego urządzenia. Taki model konfiguracji nazywa się Context-Based Access Control (CBAC). Jest on uznawany za przestarzały, a przede wszystkim mało elastyczny, mimo to nadal bardzo często spotykany, nawet gdy są konfigurowane nowe urządzenia. Jego miejsce powoli zaczyna zastępować bardziej nowoczesny i elastyczny model o nazwie Zone-Based Firewall (ZBF). Na urządzeniach z logo Junipera, takich jak routery serii MX czy wielofunkcyjne firewalle serii SRX, ruch kontrolujemy jedynie przy użyciu trybu ZBF.


Zanim przejdziemy do omówienia sposobu konfiguracji, musimy dobrze zrozumieć, czym różnią się od siebie te dwa tryby konfiguracji i pracy. Jak już wspomnieliśmy, jeżeli na urządzeniu firmy Cisco chcieliśmy zablokować ruch z komputera o adresie 172.16.10.10 do jakiegokolwiek urządzenia w innej podsieci, to konfigurowaliśmy listę kontrolną ACL z odpowiednimi wpisami, a następnie przypisywaliśmy ją do odpowiedniego interfejsu. Jeżeli podsieć z komputerem o tym adresie była przyłączona bezpośrednio do routera, to wiadomo było, że musimy wpis dodać do ACL przypisanej do lokalnego interfejsu urządzenia. W większych sieciach taka sytuacja nie jest jednak tak oczywista. Podsieć ta może być skonfigurowana na innym rou­terze, a informację o niej nasze urządzenie może otrzymywać za pomocą dynamicznych protokołów routingu. W przypadku gdy połączenia w sieci są redundantne, to ruch pochodzący z komputera o wskazanym adresie może zostać odebrany za pośrednictwem więcej niż jednego portu.

 

Ogólna zasada mówi, że ruch powinniśmy filtrować najbliżej źródła, lecz nie zawsze jest to możliwe. W opisywanym przypadku wpisy blokujące ruch musimy dodać do list ACL przypisanych do każdego interfejsu, przez który zostanie wyznaczony routing do wskazanego adresu źródłowego. Inna typowa sytuacja to taka, w której na naszym routerze mamy wiele podsieci, ale do każdej z nich stosujemy te same polityki filtrowania ruchu. Jeżeli dopisze nam szczęście, wystarczy jedna lista ACL, którą przypiszemy do każdego z interfejsów. Zazwyczaj jednak będą występowały różnice w politykach między podsieciami, zatem musimy stworzyć oddzielną listę ACL dla każdego z nich i zarządzać nią. W każdym opisanym przypadku dodajemy sobie pracy i łatwo o pomyłkę.

 

> ZONE-BASED FIREWALL


Producenci sprzętu tacy jak Cisco dostrzegli te problemy i odpowiedzią na nie jest tryb ZBF. Jak już wspomnieliśmy, na urządzeniach Junipera jest to jedyny możliwy do konfiguracji tryb pracy. Opiera się on na koncepcji stref bezpieczeństwa, pomiędzy którymi administrator konfiguruje, jaki ruch będzie dozwolony lub zablokowany. Do poszczególnych stref możemy przypisać więcej niż jeden interfejs. Rozwiązanie takie pozwoli nam zachować separację ruchu z zastosowaniem oddzielnych interfejsów fizycznych lub subinterfejsów logicznych przy utrzymywaniu jedynie pojedynczej polityki bezpieczeństwa blokującej ruch pomiędzy dwoma strefami.


Konfigurując ZBF, o ruchu, który chcemy filtrować lub zezwolić, myślimy nieco inaczej. W tradycyjnym podejściu ważne są następujące atrybuty:

 

  • adres źródłowy,
  • adres docelowy,
  • port źródłowy,
  • port docelowy,
  • interfejs, do którego podłączona jest lista ACL,
  • kierunek działania ACL (ruch wchodzący lub wychodzący).

 

W ZBF pierwsze cztery z nich nadal są niezmiernie ważne i stanowią podstawę konfiguracji filtrowania. Przestają mieć znaczenie sam interfejs i kierunek ruchu na nim. W zamian skupiamy się na parze stref bezpieczeństwa oraz w jakim kierunku pomiędzy nimi ruch ma być filtrowany. Zmiana jest niby niewielka, lecz fundamentalna dla efektywności i elastyczności działania mechanizmu.

 

[...]

 

Autor specjalizuje się w rozwiązaniach routing & switching, data center oraz service providers. Promuje automatyzację w środowiskach sieciowych i udziela się jako deweloper w projektach open source. Pracuje jako niezależny konsultant IT. Posiada certyfikat CCIE.

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"