[RH7] Konfiguracja i edycja reguł lokalnego firewalla [PT.2 - port rules, masquerading, direct rules, lockdown]

Red Hat 7.x / CentOS 7.x

W pierwszej części było kilka słów teoretycznych i podstawowa konfiguracja firewalld - zony i serwisy. Czas brnąć dalej.

Konfiguracja otwarcia portów

Poza definiowalnymi serwisami pozostaje nam oczywiście możliwość dodawania customowych reguł filtrowania opartych o zwyczajowe numery portów, z jakich chcemy ruch do naszego systemu wpuszczać.
Jak można się domyślać po dwóch poprzednich zagadnieniach, definicja będzie opierać się na podaniu strefy, w której regułe chcemy umieścić, oraz numeru portu - wrażenie jest jak najbardziej prawidłowe, ponieważ wszystkie definicje zostały w firewalld zunifikowane.
Rozpocznijmy od listowania definicji portów, jakie mamy już zdefiniowane w naszych strefach:

[root@server ~]# firewall-cmd --list-ports

Listowanie takie dotyczy, tak jak wcześniej domyślnej strefy (listowanie innej wymaga użycia przełącznika --zone=nazwa_strefy).
Nie uzyskaliśmy żadnej odpowiedzi, co oznacza, że strefa nie zawiera definicji dla portów - ale samo przejście komendy bez echa może być nieco dezorientujące.
I tutaj muszę przypomnieć wcześniejsze Post Scriptum, mianowicie przełącznik --list-ports, tak jak wspominany tam --list-services pokazuje nam jedno, konkretne zagadnienie konfiguracyjne, bez wglądu w inne parametry. Moim zdaniem zapytanie idealnie nadaje się do skryptowania opartego o te reguły, ale w codziennej administracji bardziej przejrzyste jest --list-all.
Krótki rzut oka na pełną konfigurację - dla sprawdzenia reguł portów usunąłem wszystkie serwisy z poprzedniej konfiguracji:

[root@server ~]# firewall-cmd --list-all
dmz (default, active)
  interfaces: enp0s3 enp0s9
  sources:
  services:
  ports:
  masquerade: no
  forward-ports:
  icmp-blocks:
  rich rules:

Tutaj widać wyraźnie - nie ma żadnych definicji portów. Brak serwisu ssh oznacza, że nie mamy otwartego portu 22, i próba połączenia potwierdza to. Zdefiniujmy zatem, dla porównania, otwarcie ruchu do ssh nie używając serwisów:

[root@server ~]# firewall-cmd --add-port=22/tcp
success
[root@server ~]# firewall-cmd --list-all
dmz (default, active)
  interfaces: enp0s3 enp0s8
  sources:
  services:
  ports: 22/tcp
  masquerade: no
  forward-ports:
  icmp-blocks:
  rich rules:

Tak jak w poprzednich elementach konfiguracji, usunięcie portu zrealizujemy poprzez przełącznik --remove-port.
Przydatna również może okazać się możliwość otwarcia zakresu portów, np:

[root@server ~]# firewall-cmd --add-port=20-23/tcp
success
[root@server ~]# firewall-cmd --list-all
dmz (default, active)
  interfaces: enp0s3 enp0s8 enp0s9
  sources:
  services:
  ports: 20-23/tcp
  masquerade: no
  forward-ports:
  icmp-blocks:
  rich rules:

Tym sposobem możemy otwierać ruch na dowolnym porcie i protokole, zależnie od potrzeby.

Masquerade - port forwarding

Konfiguracja forwardowania portów ma analogiczną składnię, przy czym ilość parametrów, z oczywistych względów jest większa.
Aby forwardowanie miało szansę zadziałać, w pierwszej kolejności wymagane jest uruchomienie usługi masqueradingu:

[root@server ~]# firewall-cmd --add-masquerade
success

Obecny status jest doskonale widoczny w widoku generowanym przez przełącznik --list-all.
Samo przekierowanie portu możemy realizować zarówno na określony port jak i adres ip, lub uwzględniając oba elementy jednocześnie. Składnia przełącznika nie wygląda może zbyt przyjaźnie, ale jest bardzo logicznie uporządkowana - zawiera sekcje port (port na który przychodzi ruch), proto (protokół komunikacji), topotr (docelowy port przekierowania) oraz toaddr (docelowy adres przekierowania):

[root@server ~]# firewall-cmd --add-forward-port=port=50:proto=tcp:toport=22
success
[root@server ~]# firewall-cmd --list-all
dmz (default, active)
  interfaces: enp0s3 enp0s8
  sources:
  services:
  ports:
  masquerade: yes
  forward-ports: port=50:proto=tcp:toport=22:toaddr=
  icmp-blocks:
  rich rules:

W ramach testu działania zamknąłem na maszynie wszystkie porty, otwierając jedynie port 50/TCP - zdefiniowane przekierowanie umożliwiło zalogowanie się ssh na maszynę poprzez port 50 - a odrzuciło połączenie po standardowym 22, więc rezultat jest zgodny z oczekiwaniami.

Dodawanie reguł direct i chain-ów

firewall-cmd pozostawia nam możliwość operowania ra regułach analogicznych do tych, które pamiętamy z iptables. Reguły te są wpisywane bezpośrednio do tablic iptables, a korzystanie z nich wymaga  zrozumienia konstrukcji łańcuchów iptables.
Składnia tego typu definicji wygląda następująco:

[root@server ~]# firewall-cmd [--permanent] --direct --add-rule {ipv4|ipv6|eb} table chain priority args

Przełącznik --permanent odpowiada oczywiście za trwałe zapisanie reguły w systemie. --add-rule jak sugeruje nazwa odpowiada za dodanie reguły. Reguła taka musi mieć określony protokół (ipv4, ipv6 lub ethernet bridges). Kolejnymi elementami wymaganymi są tablica iptables do której reguła ma być dodana oraz odpowiedni chain.
Priorytet wykorzystywany jest do zarządzania kolejnością reguł - 0 oznacza dodanie reguły na początku tablicy, a kolejne numery powodują dodanie jej odpowiednio dalej. Dodanie kilku reguł z jednakowym priorytetem może spowodować przypadkową kolejność ich stosowania (w ramach priorytetu), dlatego, jeśli zależy nam na wymuszeniu kolejności warto zastosować różne priorytety.
Argumentami komendy będą przełączniki stosowane w iptables.
Przykładowe polecenie może wyglądać następująco:

[root@server ~]# firewall-cmd --direct --add-rule ipv4 filter IN_dmz_allow 0 -m tcp -p tcp --dport 2345 -j ACCEPT

Zdefiniowane wcześniej reguły możemy przeglądać poleceniem:

[root@server firewalld]# firewall-cmd --direct --get-all-rules
ipv4 filter IN_dmz_allow 0 -m tcp -p tcp --dport 2345 -j ACCEPT

lub dla konkretnej tablicy:

[root@server firewalld]# firewall-cmd --direct --get-rules ipv4 filter IN_dmz_allow
0 -m tcp -p tcp --dport 2345 -j ACCEPT

Przełącznik --direct umozliwia nam również definiowanie własnych chain-ów w odpowiednich tablicach.

[root@server firewalld]# firewall-cmd --direct --add-chain ipv4 filter test_chain
success

A zdefiniowane przez nas chain-y możemy podejrzeć przez:

[root@server firewalld]# firewall-cmd --direct --get-all-chains
ipv4 filter test_chain

Usuwanie, zarówno reguł jak i chain-ów realizujemy analogicznie, używając odpowiednio przełączników --remove-rule i --remove-chain.

Cały czas pozostaje nam możliwość weryfikowania zdefiniowanych reguł poprzez klasyczne iptables -nL, ale ilość tablic powoduje, że nie są one zbyt czytelne.

Lockdown - blokowanie możliwości zmian reguł przez aplikacje

Aplikacje oraz serwisy, jeśli są uruchomione z uprawnieniami root, mają możliwość zmiany konfiguracji firewalla (np. libvirt). Opcja lockdown daje nam możliwość kontrolowania tych możliwości.
Lockdown konfiguracji wykonujemy poprzez ustawienie wartości yes w pliku /etc/firewalld/firewalld.conf

[root@server firewalld]# vi /etc/firewalld/firewalld.conf
[...]
Lockdown=yes
[...]
[root@server firewalld]# firewall-cmd --reload
success
[root@server firewalld]# firewall-cmd --query-lockdown
yes

Po przeładowaniu, zmian w konfiguracji będą mogły dokonywać jedynie aplikacje zdefiniowane na białej liście, w pliku /etc/firewalld/lockdown-whitelist.xml
Plik posiada predefiniowane reguły, które umożliwiają edycję reguł np. root-owi - do przetestowania działania usunąłem je z pliku - efekt jest zgodny ze spodziewanym:

[root@server firewalld]# firewall-cmd --add-service ftp
Error: ACCESS_DENIED: lockdown is enabled

Lockdown, a w zasadzie reguły whitelist mogą być zdefiniowane w oparciu o kilka elementów:
- context - konteksty selinuxowe danej aplikacji (ps -e --context)
- uid - id użytkownika
- user - nazwa użytkownika
- commands - polecenia
i w takiej też kolejności są przez lockdown sprawdzane.

Zarządzanie odbywa się przez przełączniki:

[root@server firewalld]# firewall-cmd --add-lockdown-whitelist-command='/usr/bin/python -Es /usr/bin/firewall-cmd'
success
[root@server firewalld]# firewall-cmd --add-lockdown-whitelist-context='system_u:system_r:kernel_t:s0'
success
[root@server firewalld]# firewall-cmd --add-lockdown-whitelist-uid=500
success
[root@server firewalld]# firewall-cmd --add-lockdown-whitelist-user=test
success

Usuwać reguły będziemy identycznie, zastępując --add-lockdown-... przez --remove-lockdown...

Weryfikacja odbywać się może poprzez:

[root@server firewalld]# firewall-cmd --list-lockdown-whitelist-user
test
[root@server firewalld]# firewall-cmd --list-lockdown-whitelist-uid
500
[root@server firewalld]# firewall-cmd --list-lockdown-whitelist-context
system_u:system_r:kernel_t:s0
[root@server firewalld]# firewall-cmd --list-lockdown-whitelist-command
/usr/bin/python -Es /usr/bin/firewall-cmd

Konfiguracja i edycja reguł lokalnego firewalla - firewalld i firewall-cmd [PT.1 - zones & services]