baza wiedzy Network Expert

Po co nam firewall?

Pytanie z jednej strony banalne, jednak nie zawsze oczywiste. Firewall umożliwia filtrowanie ruchu nie tylko na podstawie danych zawartych w danym pakiecie, ale również na podstawie zapisanego stanu połączenia. Inaczej mówiąc firewall nie patrzy tylko na pakiet, ale buduje całą historię połączeń sieciowych i pilnuje poprawności “konwersacji”. Takie stanowe podejście pozwala na obronę przez dużą ilością ataków, które wykorzystywały brak pamiętania stanów (np. wystarczy ustawić odpowiednio flagi w pakiecie tcp aby został przepuszczony przez access-listę choć nie powinien).

Access-lista albo NAT wystarczy?

Nie… nie. Access-listy są bez stanowe, można je łatwo obejść i oszukać. Co więcej jak wystawiamy jakieś usługi w Internecie (np. email) to skuteczne filtrowanie jest wręcz nie możliwe. NAT jest jakimś zabezpieczeniem – jednak jest to funkcjonalność translacji adresów, której wprowadzenie miało skutek uboczny w postaci właśnie głównie jednostronnej łączności. To trochę mówi o poziomie zabezpieczenia.

IOS firewall i ZBF

W routerach ISR mamy do wyboru dwa firewalle:

  • klasyczny IOS firewall nazywany czasem inspektem… (z powodu konfiguracji ip inspect)
  • Zone Based Firewall, czyli firewall w oparciu o strefy

Każdy z nich wymaga odpowiedniej licencji IOS – dla oprogramowania 15.x jest to wersja Security. Dla wcześniejszych wersji najlepiej jest to sprawdzić w Feature Navigator.

IOS firewall

Jest bardzo dobrym rozwiązaniem gdy mamy jedno wyjście “na świat” lub do niezabezpieczonej sieci. Konfigurujemy go na interfejsie wyjściowym razem z access-listą, która przepuszcza ruch nie podlegający filtrowaniu, np:

interface Fa0/0
description Internet
ip addr x.x.x.x 255.255.255.252
ip access-group INTERNET_IN in
no ip redirects
no ip unreachables
no ip proxy-arp
ip inspect INTERNET out

ip access-list extended INTERNET_IN
permit icmp any any
permit tcp any host adres_ip_serwera eq www
permit udp any host adres_ip_serwera eq smtp
permit udp any host adres_ip_serwera eq pop3

ip inspect log drop-pkt
ip inspect name INTERNET icmp router-traffic
ip inspect name INTERNET tcp router-traffic
ip inspect name INTERNET udp router-traffic
ip inspect name INTERNET dns

Taka konfiguracja przepuszcza do wnętrza sieci pakiety ICMP oraz ruch do serwisów www i email (ip serwera to adres publiczny, nawet jak zaraz zrobimy nat na adres lokalny). Reszta ruchu jest nie dopuszczona przez access-listę i to firewall zajmuje się budowaniem dynamicznych wpisów “obok acl”, które przepuszczą ruch do środka. Firewall analizuje pakiety wychodzące i dynamicznie przepuszcza ruch powrotny, które związany jest z zainicjowanych ruchem.

Zone Based Firewall

ZBF jest nowszym i bardziej elastycznym mechanizmem. Pozwala zdefiniować strefy zabezpieczeń oraz filtrować ruch pomiędzy strefami (w szczególnym przypadku strefa to może być jeden interfejs – lub kilka)

Zone Based Firewall

 

Takie podejście pozwala w łatwy sposób realizować polityki bezpieczeństwa oparte o źródło i cel ruchu, bez rozbudowywania access-list

Konfiguracja niestety nie należy do najłatwiejszych, ale najlepiej przyjrzeć się temu na przykładzie. Założenia przykładu: Mamy trzy strefy w sieci: Lan, Internet i DMz udostępniający publiczne usługi – w tym przypadku jedną usługę email. Chcemy zrealizować taką politykę bezpieczeństwa kiedy to DMZ udostępnia tylko usługę email dla połączeń internetowych, natomiast zarówno Lan jak i DMZ mają swobodny, bezpieczny dostęp do Internetu.

 

//definicja stref
zone security DMZ
zone security INT
zone security EXT

class-map type inspect match-any MAIL
match protocol smtp
match protocol imap
match protocol http
match protocol icmp

class-map type inspect match-all PUBLIC_DMZ_MAIL
match class-map MAIL
match access-group name MAIL

ip access-list ext MAIL
permit ip any host 191.1.1.1

class PUBLIC_DMZ_MAIL
inspect

//ruch do DMZ do serwera email
policy-map type inspect DMZ
class PUBLIC_DMZ_MAIL
inspect
class class-default
drop

//klasa która klasyfikuje praktycznie cały ruch
class-map type inspect match-any IPTRAFFIC
match proto tcp
match proto udp
match proto icmp

//podpięcie polityki do stref
zone-pair security EXT-DMZ source EXT destination DMZ
service-policy type inspect DMZ

//polityka dla ruchu inicjowanego z DMZ – DMZ ma pełen dostęp do Internetu
policy-map type inspect DMZ-EXT
class type inspect IPTRAFFIC
inspect
class class-default
drop
zone-pair security DMZ-EXT source DMZ destination EXT
service-policy type inspect DMZ-EXT

//policy map, która puszcza wszystko
policy-map type inspect PASS
class class-default
pass

//z wnętrza sieci do DMZ i z powrotem nic nie ograniczamy
//przy pass należy ZAWSZE zwrócić uwagę na ruch powrotony – musimy go sami dopuścić, kiedy inspect zrobi to dynamicznie za nas
zone-pair security INT-DMZ source INT destination DMZ
service-policy type inspect PASS
zone-pair security DMZ-INT source DMZ destination INT
service-policy type inspect PASS

//z Lanu do internetu puszczamy wszystko
zone-pair security INT-EXT source INT destination EXT
service-policy type inspect IPTRAFFIC

 

Który sposób filtrowania wybrać?

Z naszego doświadczenia wynika, że dla oprogramowania IOS < 15.x, czyli z serii 12.4t, zdecydowanie lepiej jest używać klasycznego IOS firewalla. Wynika to z faktu, że w 12.4T nie ma w konfiguracji ZBF kilku bardzo przydatnych narzędzi – najważniejszym jest możliwość wydłużenia okna dla pakietów TCP przychodzących nie w kolejności. Domyślna wartość okna sprawdzenia = 2 jest w polskich warunkach często nie wystarczająca (czyli wystarczy że jeden pakiet zostanie “wyprzedzony” w sieci przez dwa inne). Wtedy możemy zaobserwować drastyczny spadek wydajności oraz logi

Nov 23 17:06:23.669: %FW-6-DROP_PKT: Dropping tcp session 89.250.201.12:54371 91.1.1.1:25 due to Out-Of-Order Segment with ip ident 0

Oczywiście sytuacja “unordered packets” nie powinna mieć miejsca, jednak dość często zdarza się u rodzimych operatorów.

Dla IOS 15 wybór jest już mniej oczywisty i powinien wynikać z projektu zabezpieczeń sieci.

Od samego początku naszej działalności stawialiśmy na profesjonalne podejście do naszych Klientów

Network w liczbach

0
lat na rynku
0
realizacji
0
Klientów
0
projektów powyżej 100,000zł

Od samego początku naszej działalności stawialiśmy na profesjonalne podejście do naszych Klientów

Network w liczbach

0
lat na rynku
0
realizacji
0
Klientów