Jak skonfigurować zaporę za pomocą FirewallD na CentOS 7

wprowadzenie

Firewalld To rozwiązanie do zarządzania zaporą sieciową dostępne dla wielu dystrybucji Linuksa, które działa jako nakładka dla systemu filtrowania pakietów iptables dostarczanego przez jądro Linuksa. W tym przewodniku omówimy, jak skonfigurować zaporę dla serwera i pokażemy Podstawy zarządzania zaporą za pomocą narzędzia administracyjnego firewall-cmd (jeśli wolisz używać iptables z CentOS, postępuj zgodnie z tym przewodnikiem).

Uwaga: Istnieje szansa, że pracujesz z nowszą wersją firewalld niż była dostępna w momencie pisania tego tekstu, lub że twój serwer został skonfigurowany nieco inaczej niż przykładowy serwer używany w tym przewodniku. Tak więc zachowanie niektórych poleceń wyjaśnionych w tym przewodniku może się różnić w zależności od konkretnej konfiguracji.

podstawowe pojęcia w Firewalld

zanim zaczniemy mówić o tym, jak faktycznie używać narzędzia firewall-cmd do zarządzania konfiguracją zapory, powinniśmy zapoznać się z kilkoma podstawowymi pojęciami wprowadzonymi przez to narzędzie.

strefy

Demon firewalld zarządza grupami reguł za pomocą encji zwanych „strefami”. Strefy to zasadniczo zestawy reguł dyktujących, jaki ruch powinien być dozwolony w zależności od poziomu zaufania do sieci, do których podłączony jest komputer. Interfejsy sieciowe mają przypisaną strefę, która dyktuje zachowanie, na które powinna zezwalać zapora sieciowa.

w przypadku komputerów, które mogą często poruszać się między sieciami (takich jak laptopy), ten rodzaj elastyczności zapewnia dobrą metodę zmiany reguł w zależności od środowiska. Możesz mieć surowe zasady zakazujące większości ruchu podczas pracy w publicznej sieci Wi-Fi, a jednocześnie zezwalające na bardziej swobodne ograniczenia po podłączeniu do sieci domowej. Dla serwera strefy te nie są tak ważne od razu, ponieważ środowisko sieciowe rzadko, jeśli w ogóle, zmienia się.

niezależnie od tego, jak dynamiczne może być środowisko sieciowe, nadal warto zapoznać się z ogólną ideą każdej z predefiniowanych stref dla firewalld. W kolejności od najmniej zaufanego do najbardziej zaufanego, predefiniowane strefy w firewalld są:

• drop: Najniższy poziom zaufania. Wszystkie połączenia przychodzące są odrzucane bez odpowiedzi i możliwe są tylko połączenia wychodzące.
• blok: podobny do powyższego, ale zamiast po prostu porzucać połączenia, przychodzące żądania są odrzucane za pomocą wiadomości icmp-host-prohibited lub icmp6-adm-prohibited.
• public: reprezentuje publiczne, niezaufane sieci. Nie ufasz innym komputerom, ale możesz zezwalać na wybrane połączenia przychodzące indywidualnie.
• external: sieci zewnętrzne w przypadku, gdy używasz zapory jako bramy. Jest on skonfigurowany do maskowania NAT tak, że Twoja sieć wewnętrzna pozostaje prywatna, ale osiągalna.
• wewnętrzny: druga strona strefy zewnętrznej, używana do wewnętrznej części bramy. Komputery są dość godne zaufania i niektóre dodatkowe usługi są dostępne.
• dmz: używany dla komputerów znajdujących się w DMZ (izolowanych komputerach, które nie mają dostępu do reszty sieci). Dozwolone są tylko niektóre połączenia przychodzące.
• praca: używany do maszyn roboczych. Zaufaj większości komputerów w sieci. Kilka dodatkowych usług może być dozwolonych.
• Dom: środowisko domowe. Ogólnie oznacza to, że ufasz większości innych komputerów i że kilka innych usług zostanie zaakceptowanych.
• trusted: zaufaj wszystkim maszynom w sieci. Najbardziej otwarty z dostępnych opcji i powinien być używany oszczędnie.

aby korzystać z zapory sieciowej, możemy tworzyć reguły i zmieniać właściwości naszych stref, a następnie przypisywać Nasze interfejsy sieciowe do stref, które są najbardziej odpowiednie.

trwałość reguły

w firewalld reguły mogą być oznaczone jako stałe lub natychmiastowe. Jeśli reguła zostanie dodana lub zmodyfikowana, domyślnie zostanie zmodyfikowane zachowanie aktualnie działającej zapory. Przy następnym uruchomieniu stare zasady zostaną przywrócone.

większość operacji firewall-cmd może przyjmować znacznik --permanent, aby wskazać, że nie-efemeryczna zapora sieciowa powinna być ukierunkowana. Wpłynie to na zestaw reguł, który jest przeładowywany po uruchomieniu. Ta separacja oznacza, że możesz przetestować reguły w aktywnej instancji zapory, a następnie ponownie załadować, jeśli wystąpią problemy. Możesz także użyć znacznika --permanentdo zbudowania całego zestawu reguł w czasie, które będą stosowane jednocześnie po wydaniu polecenia reload.

Zainstaluj i włącz zaporę, aby uruchomić się podczas rozruchu

firewalld jest domyślnie instalowany w niektórych dystrybucjach Linuksa, w tym w wielu obrazach CentOS 7. Jednak może być konieczne samodzielne zainstalowanie firewalld:

sudo yum install firewalld

po zainstalowaniu firewalld możesz włączyć usługę i ponownie uruchomić serwer. Należy pamiętać, że włączenie firewalld spowoduje uruchomienie usługi przy starcie systemu. Najlepiej jest utworzyć reguły zapory sieciowej i przetestować je przed skonfigurowaniem tego zachowania, aby uniknąć potencjalnych problemów.

 
sudo systemctl enable firewalld
 
sudo reboot
 

po ponownym uruchomieniu serwera należy uruchomić zaporę sieciową, interfejsy sieciowe należy umieścić w skonfigurowanych strefach (lub powrócić do skonfigurowanej strefy domyślnej), a wszelkie reguły związane ze strefami zostaną zastosowane do powiązanych interfejsów.

możemy sprawdzić, czy usługa jest uruchomiona i osiągalna, wpisując:

sudo firewall-cmd --state

output
running

oznacza to, że nasza zapora jest uruchomiona i działa z domyślną konfiguracją.

zapoznanie się z aktualnymi regułami zapory

zanim zaczniemy wprowadzać modyfikacje, powinniśmy zapoznać się z domyślnym środowiskiem i regułami dostarczanymi przez demona.

przeglądając domyślne

możemy zobaczyć, która strefa jest obecnie wybrana jako domyślna, wpisując:

firewall-cmd --get-default-zone

output
public

ponieważ nie daliśmy firewalld żadnych poleceń odbiegających od domyślnej strefy, a żaden z naszych interfejsów nie jest skonfigurowany do wiązania z inną strefą, strefa ta będzie również jedyną „aktywną” strefą (strefą kontrolującą ruch dla naszych interfejsów). Możemy to sprawdzić wpisując:

firewall-cmd --get-active-zones

output
public interfaces: eth0 eth1

tutaj widzimy, że nasz przykładowy serwer ma dwa interfejsy sieciowe kontrolowane przez zaporę sieciową (eth0 i eth1). Obie są obecnie zarządzane zgodnie z zasadami określonymi dla strefy publicznej.

skąd jednak wiemy, jakie zasady są związane ze strefą publiczną? Możemy wydrukować domyślną konfigurację strefy wpisując:

sudo firewall-cmd --list-all

output
public (default, active) target: default icmp-block-inversion: no interfaces: eth0 eth1 sources: services: ssh dhcpv6-client ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: 

na wyjściu możemy stwierdzić, że ta strefa jest zarówno domyślna, jak i aktywna oraz że interfejsy eth0 i eth1 są powiązane z tą strefą (wszystko to już wiedzieliśmy z naszych poprzednich zapytań). Jednak widzimy również, że ta strefa pozwala na normalne operacje związane z klientem DHCP (do przypisywania adresów IP) i SSH (do zdalnej administracji).

odkrywanie alternatywnych stref

teraz mamy dobry pomysł na konfigurację dla strefy domyślnej i aktywnej. Możemy również dowiedzieć się o innych strefach.

aby uzyskać listę dostępnych stref, wpisz:

firewall-cmd --get-zones

output
block dmz drop external home internal public trusted work

możemy zobaczyć konkretną konfigurację związaną ze strefą, włączając parametr --zone= w nasze polecenie --list-all :

sudo firewall-cmd --zone=home --list-all

output
home interfaces: sources: services: dhcpv6-client ipp-client mdns samba-client ssh ports: masquerade: no forward-ports: icmp-blocks: rich rules:

możesz wypisać wszystkie definicje stref, korzystając z opcji --list-all-zones. Prawdopodobnie będziesz chciał podłączyć wyjście do pagera w celu łatwiejszego oglądania:

sudo firewall-cmd --list-all-zones | less

Wybieranie stref dla interfejsów

o ile nie skonfigurowano inaczej interfejsów sieciowych, każdy interfejs zostanie umieszczony w strefie domyślnej po uruchomieniu zapory.

zmiana strefy interfejsu

podczas sesji można zmieniać interfejs między strefami za pomocą parametru --zone= w połączeniu z parametrem --change-interface=. Podobnie jak w przypadku wszystkich poleceń modyfikujących zaporę, musisz użyć sudo.

na przykład możemy przenieść nasz interfejs eth0 do strefy” home ” wpisując ten:

sudo firewall-cmd --zone=home --change-interface=eth0

output
success

za każdym razem, gdy przenosisz interfejs do nowej strefy, pamiętaj, że prawdopodobnie modyfikujesz usługi, które będą działać. Na przykład tutaj przenosimy się do strefy” home”, w której dostępny jest SSH. Oznacza to, że nasze połączenie nie powinno upaść. Niektóre inne strefy nie mają domyślnie włączonego SSH, a jeśli połączenie zostanie przerwane podczas korzystania z jednej z tych stref, możesz nie być w stanie zalogować się ponownie.

możemy sprawdzić, czy to się udało, ponownie prosząc o aktywne strefy:

firewall-cmd --get-active-zones

output
home interfaces: eth0public interfaces: eth1

dostosowywanie strefy domyślnej

jeśli wszystkie interfejsy mogą być najlepiej obsługiwane przez jedną strefę, prawdopodobnie łatwiej jest po prostu wybrać najlepszą strefę domyślną, a następnie użyć jej do konfiguracji.

możesz zmienić domyślną strefę za pomocą parametru --set-default-zone=. Spowoduje to natychmiastową zmianę dowolnego interfejsu, który powrócił do domyślnej nowej strefy:

sudo firewall-cmd --set-default-zone=home 

output
success

Ustawianie reguł dla aplikacji

podstawowy sposób definiowania wyjątków zapory dla usług, które chcesz udostępnić, jest łatwy. Przejdziemy przez podstawowy pomysł.

dodawanie usługi do stref

najprostszą metodą jest dodanie usług lub portów potrzebnych do stref, których używasz. Ponownie możesz uzyskać listę dostępnych usług za pomocą opcji --get-services :

firewall-cmd --get-services

output
RH-Satellite-6 amanda-client amanda-k5-client bacula bacula-client bitcoin bitcoin-rpc bitcoin-testnet bitcoin-testnet-rpc ceph ceph-mon cfengine condor-collector ctdb dhcp dhcpv6 dhcpv6-client dns docker-registry dropbox-lansync elasticsearch freeipa-ldap freeipa-ldaps freeipa-replication freeipa-trust ftp ganglia-client ganglia-master high-availability http https imap imaps ipp ipp-client ipsec iscsi-target kadmin kerberos kibana klogin kpasswd kshell ldap ldaps libvirt libvirt-tls managesieve mdns mosh mountd ms-wbt mssql mysql nfs nrpe ntp openvpn ovirt-imageio ovirt-storageconsole ovirt-vmconsole pmcd pmproxy pmwebapi pmwebapis pop3 pop3s postgresql privoxy proxy-dhcp ptp pulseaudio puppetmaster quassel radius rpc-bind rsh rsyncd samba samba-client sane sip sips smtp smtp-submission smtps snmp snmptrap spideroak-lansync squid ssh synergy syslog syslog-tls telnet tftp tftp-client tinc tor-socks transmission-client vdsm vnc-server wbem-https xmpp-bosh xmpp-client xmpp-local xmpp-server

więcej szczegółów na temat każdej z tych usług można uzyskać, przeglądając powiązany z nimi plik .xml w katalogu /usr/lib/firewalld/services. Na przykład usługa SSH jest zdefiniowana w następujący sposób:

<?xml version="1.0" encoding="utf-8"?><service> <short>SSH</short> <description>Secure Shell (SSH) is a protocol for logging into and executing commands on remote machines. It provides secure encrypted communications. If you plan on accessing your machine remotely via SSH over a firewalled interface, enable this option. You need the openssh-server package installed for this option to be useful.</description> <port protocol="tcp" port="22"/></service>

możesz włączyć usługę dla strefy za pomocą parametru --add-service=. Operacja będzie ukierunkowana na strefę domyślną lub dowolną strefę określoną przez parametr --zone=. Domyślnie spowoduje to dostosowanie tylko bieżącej sesji zapory sieciowej. Możesz dostosować konfigurację stałej zapory, włączając flagę --permanent.

na przykład, jeśli uruchamiamy serwer WWW obsługujący konwencjonalny ruch HTTP, możemy zezwolić na ten ruch dla interfejsów w naszej strefie „publicznej” dla tej sesji, wpisując:

sudo firewall-cmd --zone=public --add-service=http

możesz pominąć --zone=, jeśli chcesz zmodyfikować domyślną strefę. Możemy sprawdzić, czy operacja się powiodła, używając operacji --list-all lub --list-services :

sudo firewall-cmd --zone=public --list-services

output
dhcpv6-client http ssh

po przetestowaniu, że wszystko działa tak, jak powinno, prawdopodobnie będziesz chciał zmodyfikować stałe reguły zapory tak, że usługa będzie nadal dostępna po ponownym uruchomieniu. Możemy uczynić naszą” publiczną ” zmianę strefy trwałą wpisując:

sudo firewall-cmd --zone=public --permanent --add-service=http

output
success

możesz sprawdzić, czy to się powiodło, dodając znacznik --permanent do operacji --list-services. Musisz użyć sudo dla dowolnych operacji --permanent :

sudo firewall-cmd --zone=public --permanent --list-services

output
dhcpv6-client http ssh

Twoja strefa „publiczna” pozwoli teraz na ruch sieciowy HTTP na porcie 80. Jeśli twój serwer WWW jest skonfigurowany do korzystania z protokołu SSL / TLS, będziesz także chciał dodać usługę https. Możemy dodać to do bieżącej sesji i stałego zestawu reguł wpisując:

 
sudo firewall-cmd --zone=public --add-service=https
 
sudo firewall-cmd --zone=public --permanent --add-service=https
 

Co Zrobić, jeśli nie jest dostępna odpowiednia usługa?

usługi zapory sieciowej zawarte w instalacji firewalld stanowią wiele najczęstszych wymagań dla aplikacji, do których można zezwolić na dostęp. Jednak prawdopodobnie wystąpią scenariusze, w których te usługi nie będą pasować do Twoich wymagań.

w tej sytuacji masz dwie opcje.

otwieranie portu dla stref

najprostszym sposobem na dodanie wsparcia dla konkretnej aplikacji jest otwarcie portów, których używa w odpowiednich strefach. Jest to tak proste, jak określenie portu lub zakresu portów oraz powiązanego protokołu dla portów, które chcesz otworzyć.

na przykład, jeśli nasza aplikacja działa na porcie 5000 i używa TCP, możemy dodać to do strefy „publicznej” dla tej sesji za pomocą parametru --add-port=. Protokoły mogą być tcp lub udp:

sudo firewall-cmd --zone=public --add-port=5000/tcp

output
success

możemy sprawdzić, czy udało się to za pomocą operacji --list-ports :

sudo firewall-cmd --zone=public --list-ports

output
5000/tcp

możliwe jest również określenie sekwencyjnego zakresu portów poprzez oddzielenie portu początkowego i końcowego w zakresie myślnikiem. Na przykład, jeśli nasza aplikacja używa portów UDP od 4990 do 4999, możemy otworzyć je na „publiczne”, wpisując:

sudo firewall-cmd --zone=public --add-port=4990-4999/udp

po przetestowaniu prawdopodobnie chcielibyśmy dodać je do stałej zapory sieciowej. Możesz to zrobić wpisując:

 
sudo firewall-cmd --zone=public --permanent --add-port=5000/tcp
 
sudo firewall-cmd --zone=public --permanent --add-port=4990-4999/udp
 
sudo firewall-cmd --zone=public --permanent --list-ports
 

output
successsuccess5000/tcp 4990-4999/udp

zdefiniowanie usługi

otwieranie portów dla stref jest łatwe, ale może być trudne do śledzenia, do czego są one przeznaczone. Jeśli kiedykolwiek anulujesz usługę na swoim serwerze, możesz mieć trudności z zapamiętaniem, które porty zostały otwarte, są nadal wymagane. Aby uniknąć takiej sytuacji, możliwe jest zdefiniowanie usługi.

usługi to po prostu Kolekcje portów z powiązaną nazwą i opisem. Korzystanie z usług jest łatwiejsze do administrowania niż z portów, ale wymaga trochę pracy z góry. Najprostszym sposobem na rozpoczęcie jest skopiowanie istniejącego skryptu (znalezionego w /usr/lib/firewalld/services) do katalogu /etc/firewalld/services, w którym firewall szuka niestandardowych definicji.

na przykład, możemy skopiować definicję usługi SSH, aby użyć jej dla naszej „przykładowej” definicji usługi w ten sposób. Nazwa pliku minus przyrostek .xml określi nazwę usługi na liście usług zapory sieciowej:

sudo cp /usr/lib/firewalld/services/ssh.xml /etc/firewalld/services/example.xml

teraz możesz dostosować definicję znalezioną w skopiowanym pliku:

sudo vi /etc/firewalld/services/example.xml

na początek plik będzie zawierał skopiowaną definicję SSH:

<?xml version="1.0" encoding="utf-8"?><service> <short>SSH</short> <description>Secure Shell (SSH) is a protocol for logging into and executing commands on remote machines. It provides secure encrypted communications. If you plan on accessing your machine remotely via SSH over a firewalled interface, enable this option. You need the openssh-server package installed for this option to be useful.</description> <port protocol="tcp" port="22"/></service>

większość tej definicji to w rzeczywistości metadane. Będziesz chciał zmienić skróconą nazwę usługi w tagach <short>. Jest to nazwa czytelna dla człowieka dla Twojej usługi. Powinieneś również dodać opis, aby uzyskać więcej informacji, jeśli kiedykolwiek będziesz musiał przeprowadzić audyt Usługi. Jedyną konfiguracją, która faktycznie wpływa na funkcjonalność usługi, będzie prawdopodobnie definicja portu, w której identyfikujesz numer portu i protokół, który chcesz otworzyć. Można to określić wielokrotnie.

dla naszej „przykładowej” usługi, wyobraź sobie, że musimy otworzyć port 7777 dla TCP i 8888 dla UDP. Wchodząc w tryb INSERT naciskając i, możemy zmodyfikować istniejącą definicję o coś takiego:

<?xml version="1.0" encoding="utf-8"?><service> <short>Example Service</short> <description>This is just an example service. It probably shouldn't be used on a real system.</description> <port protocol="tcp" port="7777"/> <port protocol="udp" port="8888"/></service>

naciśnij ESC, a następnie wprowadź :x, aby zapisać i zamknąć plik.

Przeładuj zaporę, aby uzyskać dostęp do nowej usługi:

sudo firewall-cmd --reload

widać, że obecnie znajduje się na liście dostępnych usług:

firewall-cmd --get-services

output
RH-Satellite-6 amanda-client amanda-k5-client bacula bacula-client bitcoin bitcoin-rpc bitcoin-testnet bitcoin-testnet-rpc ceph ceph-mon cfengine condor-collector ctdb dhcp dhcpv6 dhcpv6-client dns docker-registry dropbox-lansync elasticsearch example freeipa-ldap freeipa-ldaps freeipa-replication freeipa-trust ftp ganglia-client ganglia-master high-availability http https imap imaps ipp ipp-client ipsec iscsi-target kadmin kerberos kibana klogin kpasswd kshell ldap ldaps libvirt libvirt-tls managesieve mdns mosh mountd ms-wbt mssql mysql nfs nrpe ntp openvpn ovirt-imageio ovirt-storageconsole ovirt-vmconsole pmcd pmproxy pmwebapi pmwebapis pop3 pop3s postgresql privoxy proxy-dhcp ptp pulseaudio puppetmaster quassel radius rpc-bind rsh rsyncd samba samba-client sane sip sips smtp smtp-submission smtps snmp snmptrap spideroak-lansync squid ssh synergy syslog syslog-tls telnet tftp tftp-client tinc tor-socks transmission-client vdsm vnc-server wbem-https xmpp-bosh xmpp-client xmpp-local xmpp-server

możesz teraz korzystać z tej usługi w swoich strefach, tak jak zwykle.

tworzenie własnych stref

chociaż wstępnie zdefiniowane strefy będą prawdopodobnie wystarczające dla większości użytkowników, pomocne może być zdefiniowanie własnych stref, które są bardziej opisowe dla ich funkcji.

na przykład możesz utworzyć strefę dla swojego serwera www o nazwie „publicweb”. Możesz jednak chcieć skonfigurować inną strefę dla usługi DNS świadczonej w sieci prywatnej. Możesz chcieć do tego strefy o nazwie „privateDNS”.

podczas dodawania strefy należy dodać ją do stałej konfiguracji zapory. Następnie możesz przeładować, aby wprowadzić konfigurację do uruchomionej sesji. Na przykład, możemy utworzyć dwie strefy, które omówiliśmy powyżej, wpisując:

 
sudo firewall-cmd --permanent --new-zone=publicweb
 
sudo firewall-cmd --permanent --new-zone=privateDNS
 

możesz sprawdzić, czy są one obecne w Twojej stałej konfiguracji, wpisując:

sudo firewall-cmd --permanent --get-zones

output
block dmz drop external home internal privateDNS public publicweb trusted work

jak wspomniano wcześniej, nie będą one jeszcze dostępne w bieżącej instancji zapory sieciowej:

firewall-cmd --get-zones

output
block dmz drop external home internal public trusted work

Przeładuj zaporę, aby wprowadzić te nowe strefy do aktywnej konfiguracji:

 
sudo firewall-cmd --reload
 
firewall-cmd --get-zones
 

output
block dmz drop external home internal privateDNS public publicweb trusted work

teraz możesz rozpocząć przypisywanie odpowiednich usług i portów do swoich stref. Zwykle dobrym pomysłem jest dostosowanie aktywnej instancji, a następnie przeniesienie tych zmian do stałej konfiguracji po przetestowaniu. Na przykład dla strefy „publicweb” możesz dodać usługi SSH, HTTP i HTTPS:

 
sudo firewall-cmd --zone=publicweb --add-service=ssh
 
sudo firewall-cmd --zone=publicweb --add-service=http
 
sudo firewall-cmd --zone=publicweb --add-service=https
 
sudo firewall-cmd --zone=publicweb --list-all
 

output
publicweb target: default icmp-block-inversion: no interfaces: sources: services: ssh http https ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:

Podobnie możemy dodać usługę DNS do naszej strefy” privateDNS”:

 
sudo firewall-cmd --zone=privateDNS --add-service=dns
 
sudo firewall-cmd --zone=privateDNS --list-all
 

output
privateDNS interfaces: sources: services: dns ports: masquerade: no forward-ports: icmp-blocks: rich rules:

następnie możemy zmienić nasze interfejsy na te nowe strefy, aby je przetestować:

 
sudo firewall-cmd --zone=publicweb --change-interface=eth0
 
sudo firewall-cmd --zone=privateDNS --change-interface=eth1
 

w tym momencie masz możliwość przetestowania swojej konfiguracji. Jeśli te wartości działają dla ciebie, będziesz chciał dodać te same reguły do stałej konfiguracji. Możesz to zrobić, ponownie stosując reguły z flagą --permanent :

 
sudo firewall-cmd --zone=publicweb --permanent --add-service=ssh
 
sudo firewall-cmd --zone=publicweb --permanent --add-service=http
 
sudo firewall-cmd --zone=publicweb --permanent --add-service=https
 
sudo firewall-cmd --zone=privateDNS --permanent --add-service=dns
 

po trwałym zastosowaniu tych reguł możesz ponownie uruchomić sieć i ponownie załadować usługę zapory:

 
sudo systemctl restart network
 
sudo systemctl reload firewalld
 

sprawdź, czy zostały przypisane odpowiednie strefy:

firewall-cmd --get-active-zones

output
privateDNS interfaces: eth1publicweb interfaces: eth0

i potwierdzić, że odpowiednie usługi są dostępne dla obu stref:

sudo firewall-cmd --zone=publicweb --list-services

output
http https ssh

sudo firewall-cmd --zone=privateDNS --list-services

output
dns

udało Ci się skonfigurować własne strefy! Jeśli chcesz ustawić jedną z tych stref jako domyślną dla innych interfejsów, pamiętaj, aby skonfigurować to zachowanie za pomocą parametru --set-default-zone= :

sudo firewall-cmd --set-default-zone=publicweb

wniosek

powinieneś teraz mieć dość dobre zrozumienie, jak administrować usługą firewalld w systemie CentOS do codziennego użytku.

usługa firewalld umożliwia konfigurację reguł i zestawów reguł, które uwzględniają środowisko sieciowe. Umożliwia bezproblemowe przechodzenie między różnymi zasadami zapory sieciowej za pomocą stref i daje administratorom możliwość abstrakcji zarządzania portami w bardziej przyjazne definicje usług. Zdobycie praktycznej wiedzy na temat tego systemu pozwoli Ci skorzystać z elastyczności i mocy, które zapewnia to narzędzie.