Filtrowanie ruchu w Enterprise Linux 8 – firewalld

Zapora sieciowa zapewnia ochronę systemom szerokiej dostępności. Umożliwia precyzyjne ustalenie zaufania, a co za tym idzie kontroli dostępu w kontekście sieci, w obrębie domen. Dziś omówimy koncepty i działanie filtra ruchu sieciowego w Enterprise Linux 8 – firewalld.

Zapora sieciowa (firewall) zapewnia ochronę systemom szerokiej dostępności. Umożliwia precyzyjne ustalenie zaufania, a co za tym idzie kontroli dostępu w kontekście sieci, w obrębie domen. Dziś omówimy koncepty i działanie filtra ruchu sieciowego w Enterprise Linux 8 – firewalld.

W erze globalnej komunikacji praktycznie każda osoba czy instytucja łączy się dziś z siecią w ramach wymiany informacji, pracy czy po prostu rozrywki. Jednak wiąże się z tym także odpowiedzialność. Łączność jest powiązana z szerszą perspektywą ryzyk, takich jak próby ataku przez niepowołane podmioty. Rozsądnym podejściem jest wykorzystanie oprogramowania do filtrowania ruchu sieciowego w celu ograniczenia powyższego niebezpieczeństwa. Jest to szczególnie istotne w środowiskach krytycznych, gdzie spowolnienie lub kompletne zatrzymanie systemu wpłynęłoby negatywnie na operacyjność firmy.

Warto zaznaczyć, iż zapora ogniowa to w kontekście sieciowym pierwsza linia obrony infrastruktury przed atakami z zewnątrz. Dlatego należy podejść do tej kwestii poważnie. Enterprise Linux, zapewniając najwyższy poziom bezpieczeństwa klasy biznesowej, dostarcza gotową do użytku zaporę, której cechy i przypadki praktycznego użycia opiszemy poniżej.

firewalld w Enterprise Linux 8

Enterprise Linux 8 (Rocky Linux, AlmaLinux, RHEL) dostarcza firewalld w wersji 0.8.2. Płynie z tego słuszny wniosek, iż wykorzystuje ono nftables jako element backendowy zapory. Jest to zamiennik dotychczasowych silników, takich jak iptables i pokrewnych. Następstwem jest usprawnione działanie, m.in. poprzez szybsze aktualizacje reguł czy architektura pozwalająca na wspieranie nowych protokołów niezależnie od systemowego jądra.

W tym momencie należy wytłumaczyć terminologię w firewalld. Jako że jest to system bezpieczeństwa sieciowego opierający się na zestawie reguł aplikowanych wobec pakietów, zacznijmy od konceptu zon.

Zona (strefa, sfera, realm) to uogólnienie zbioru reguł zapory sieciowej – zestawu stosowanego do konkretnej sytuacji. Możemy sobie wyobrazić pracownika z laptopem roboczym, który łączy się z siecią zarówno przez połączenie kablowe w biurze, jak i zdalnie przez WiFi. Może przydzielić sobie każde z połączeń do innej zony, dzięki czemu podczas pracy zdalnej nie musi się obawiać potencjalnych ataków od postronnych, natomiast w pracy panuje zaufanie do maszyn wykorzystywanych w biurze.

Firewalld dostarcza kilka domyślnych zon, a tym samym kilka predefiniowanych poziomów bezpieczeństwa i zaufania. Co więcej, zainstalowane oprogramowanie integrujące się z firewalld może dodać swoją własną zonę, co możemy zaobserwować na poniższym listingu:

$ firewall-cmd --get-zones
block dmz drop external home internal libvirt nm-shared public trusted work

Jak widać, na naszym stanowisku roboczym istnieje 11 zon. Jest to związane między innymi z używaniem NetworkManagera i libvirta, które dodały swoje dodatkowe zony. Jako że nie sposób omówić każdej możliwej konfiguracji, którą może stworzyć dodatkowe oprogramowanie, opiszemy tylko tę większość, która znajdzie się na minimalnym, świeżo zainstalowanym systemie Enterprise Linux 8. Oto one wraz z krótkim wyjaśnieniem i konkretnym zastosowaniem:

  • drop – bezwzględne odrzucanie połączeń przychodzących
  • block – bezwzględne odrzucanie połączeń przychodzących z informacją zwrotną ICMP o odrzuceniu
  • public – brak zaufania dla otaczających urządzeń z możliwością akceptowania wybranych połączeń. Używana jako domyślna, jeżeli nie sprecyzowano innej
  • external – typowe ustawienia dla bramy domyślnej od strony zewnętrznej – ograniczone zaufanie, włączona maskarada pakietów i zezwolenie tylko dla usługi SSH
  • internal – typowe ustawienia dla bramy domyślnej od strony wewnętrznej – znaczne zaufanie dla urządzeń będących w sieci wewnętrznej. W związku z tym zezwala się na więcej usług, takich jak Cockpit, Samba czy mDNS
  • dmz – typowe ustawienia dla tzw. strefy zdemilitaryzowanej – ustawienia niemalże identyczne jak dla zony external, z wyjątkiem wyłączonej maskarady
  • work – jako że jest to preset dla maszyn w pracy, naturalnie ufa się maszynom w sieci w dużym stopniu. Zezwolenie dla typowych administracyjnych usług jak Cockpit i SSH
  • home – ustawienia dla sieci domowej – zaufanie dla urządzeń jest jeszcze większe. Dostępne usługi identyczne jak dla zony internal
  • trusted – zaufanie dla wszystkich otaczających urządzeń bez żadnych ograniczeń.

Oczywiście może zaistnieć potrzeba sprawdzenia pełnej konfiguracji dla danej zony, zwłaszcza w przypadku zdefiniowania własnych, które omówimy w dalszej części tego artykułu. Jako że nasza testowa stacja robocza służy jako laboratorium, gdzie wykorzystuje się wirtualizację, popatrzmy na detale zony libvirt:

$ sudo firewall-cmd --list-all --zone=libvirt
libvirt (active)
  target: ACCEPT
  icmp-block-inversion: no
  interfaces: virbr0 virbr1 virbr2
  sources:
  services: dhcp dhcpv6 dns ssh tftp
  ports:
  protocols: icmp ipv6-icmp
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:
        rule priority="32767" reject

Jak można zauważyć, mamy 3 interfejsy sieciowe przydzielone do tej zony, co zgadza się z faktem używania na tej stacji:

  • typowych maszyn wirtualnych libvirt tworzonych z poziomu virt-managera
  • Vagranta z obrazami od EuroLinux
  • dedykowanej sieci dla pewnego firmowego projektu.

W związku z tym, że maszyny te są traktowane jako zaufane i używane w ramach laboratorium, zezwalamy im na pingowanie (protokół ICMP) i m.in. łączenie się przez SSH.

Bardziej zaawansowane przykłady

Ponieważ ten artykuł dotyczy praktycznych lub laboratoryjnych przypadków aplikowania zapory sieciowej, nie będziemy omawiać podstaw obsługi firewalld. Pokażemy jednak jej praktyczne zastosowanie. Jako przykład weźmy osobę korzystającą z mobilnej stacji roboczej, pracującego zarówno zdalnie, jak i w biurze.

1. Chcemy zredukować zwiększone ryzyko podczas pracy zdalnej, w związku z czym zmieniamy wspomnianą wcześniej domyślną zonę public na drop w następujący sposób:

# firewall-cmd --set-default-zone=drop

Zmiana ta odbywa się natychmiast – zarówno tymczasowo, jak i zachowawczo – zgodnie z dokumentacją firewalld w RHEL 8.

2. Następnie łącząc się w biurze z siecią przez kabel, chcemy stworzyć nową zonę w ramach laboratorium do R&D. Warto pamiętać, że stacja robocza używa NetworkManagera, który kontroluje sieć. W związku z tym przełączenie interfejsu sieciowego do innej zony odbędzie się na warstwie samego NetworkManagera poprzez użycie programu nmcli, nie firewall-cmd :

# firewall-cmd --permanent --new-zone=lab
# firewall-cmd --reload
# nmcli conn modify Wired\ connection\ 1 connection.zone lab

Jeżeli używamy systemu Enterprise Linux 8.X, warto mieć na uwadze, że wielkimi krokami nadchodzi Enterprise Linux 9. Wydanie nr 9 nie zawiera pakietu network-scripts, a co za tym idzie dotychczasowych skryptów sieciowych. W związku z tym zamiast dopisywać ZONE=lab w pliku konfiguracyjnym w katalogu /etc/sysconfig/network-scripts/, warto wdrożyć wizję długoterminową i zastosować ujednolicony wobec oprogramowania w Enterprise Linux 8 oraz 9 interfejs zarządzania siecią.

3. Na koniec chcemy włączyć tymczasowo (nie zachowawczo) możliwość łączenia się przez SSH do swojej stacji roboczej tylko dla konkretnego innego komputera współpracownika.

W związku z tym możemy wywołać poniższą komendę:

# firewall-cmd --zone=lab --add-rich-rule='rule family="ipv4" source address="10.0.0.101" service name="ssh" accept'

W ten sposób stacja robocza została skonfigurowana do pracy zdalnej w warunkach ograniczonego zaufania oraz do dedykowanego projektu firmowego.

Podsumowanie

Przedstawiliśmy koncepty i działanie naszego filtra ruchu sieciowego oraz prosty, ale praktyczny poradnik konfiguracji stacji roboczej. Proces ten jest intuicyjny i będzie mógł być analogicznie zastosowany w nowszych wydaniach Enterprise Linux ze względu na zgodność między wersją 8 i 9. W przyszłości zostanie zaprezentowana dodatkowa, bardziej zaawansowana konfiguracja zapory w kontekście projektowania rozległych infrastruktur sieciowych.

blank Autorzy

Artykuły na blogu są pisane przez osoby z zespołu EuroLinux. 80% treści zawdzięczamy naszym developerom, pozostałą część przygotowuje dział sprzedaży lub marketingu. Dokładamy starań, żeby treści były jak najlepsze merytorycznie i językowo, ale nie jesteśmy nieomylni. Jeśli zauważysz coś wartego poprawienia lub wyjaśnienia, będziemy wdzięczni za wiadomość.