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



26.05.2020

Cloud Native Universe

Jako patron medialny zapraszamy programistów wdrażających lub integrujących się z dowolną...
26.03.2020

Koniec certyfikatów...

MCSA, MCSD i MCSA
26.03.2020

Odświeżony OS

FortiOS 6.4
26.03.2020

Bezpieczeństwo w chmurze

Cisco SecureX
26.03.2020

Modernizacja IT

Nowości w VMware Tanzu
26.03.2020

Krytyczne zagrożenie dla...

Nowa groźna podatność
26.03.2020

Laptopy dla wymagających

Nowe ThinkPady T, X i L
26.03.2020

Serwerowe ARM-y

Ampere Altra
26.03.2020

Energooszczędny monitor

Philips 243B1

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.

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

prenumerata Numer niedostępny Spis treści

.

Transmisje online zapewnia: StreamOnline

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