Strona główna
» Jak
»
Otwórz tylko ruch sieciowy, którego potrzebuje Twój serwer SLES 15
Otwórz tylko ruch sieciowy, którego potrzebuje Twój serwer SLES 15
Przykładowy scenariusz: Wyobraź sobie administratora przygotowującego fikcyjny serwer SLES 15 o nazwie web01 do hostowania małej publicznej witryny internetowej. Celem jest umożliwienie ruchu przychodzącego HTTP na porcie TCP 80 przy jednoczesnym zachowaniu dostępności istniejącej ścieżki administracyjnej SSH. Jest to przykład ilustracyjny, a nie raport z testu ani stwierdzenie, że każda instalacja SLES 15 ma te same nazwy interfejsów lub usługi.
W systemie SLES 15 firewalldjest to domyślna struktura zapory sieciowej, która firewall-cmdją kontroluje. Najpierw zidentyfikuj aktywną strefę i zweryfikuj dostęp zdalny; następnie dodaj najmniejszą wymaganą usługę do tej strefy w konfiguracji stałej i przeładuj. W podręczniku SUSE SLES 15 SP7 Security and Hardening Guide udokumentowano ten model strefowy oraz rozróżnienie między regułami środowiska wykonawczego a regułami stałymi. Te kroki zakładają, że zapora sieciowa jest zainstalowana i uruchomiona; starsze, zaktualizowane systemy mogą wymagać osobnego sprawdzenia migracji.
1. Przed zmianą zasad sprawdź usługę i aktywną strefę
Połącz się przez konsolę serwera lub sesję zarządzania, którą możesz odzyskać w przypadku przerwania dostępu do sieci. Jeśli łączysz się przez SSH, utrzymuj tę sesję otwartą podczas wprowadzania zmian w zaporze. Sprawdź, czy zapora firewalld jest uruchomiona i sprawdź, która strefa jest właścicielem interfejsu:
Pierwsze polecenie powinno zgłosić running. Polecenie active-zones wyświetla listę stref z przypisanymi interfejsami lub adresami źródłowymi; może wyświetlać więcej niż jedną. W fikcyjnym przykładzie web01 załóżmy, że raportuje on publicinterfejs ens192. W kolejnych poleceniach należy używać strefy dołączonej do interfejsu sieci przychodzącej. Nie należy zakładać, że interfejs ma nazwę eth0i nie należy zakładać, publicże jest aktywny tylko dlatego, że jest to powszechna wartość domyślna.
Przykładowy widok terminala dla początkowego sprawdzenia: firewalld raportuje działanie, a ens192 pojawia się w strefie publicznej.
Jeśli usługa nie działa, sprawdź jej stan przed uruchomieniem: sudo systemctl status firewalld. W standardowych instalacjach SLES 15 zapora firewalld jest instalowana i włączona domyślnie, ale profile obrazów, aktualizacje lub polityka lokalna mogą się różnić. Jeśli jest zainstalowana, ale zatrzymana, uruchom ją i włącz dopiero po potwierdzeniu, że jej bieżąca polityka zachowa wymagany dostęp: sudo systemctl enable --now firewalld. Na hoście zarządzanym zdalnie, przed aktywacją zapory, której bieżące reguły są nieznane, potwierdź dostęp do konsoli i limit SSH.
2. Potwierdź definicję usługi i zachowaj SSH
Usługa firewalld to nazwany pakiet portów i protokołów. Przed jej otwarciem sprawdź definicję lokalną:
W systemie SLES predefiniowana httpusługa odpowiada portowi TCP 80. Lista stref pozwala na sprawdzenie aktualnie dozwolonych usług i portów. Zastąp ją publicznalezioną aktywną strefą. Jeśli serwerem administrujesz za pomocą protokołu SSH, upewnij się, że sshjest on dozwolony w tej strefie, zanim przejdziesz dalej. Zachowanie instalacji i istniejące zasady mogą się różnić, dlatego sprawdź, czy nie opieraj się na założeniach. Jeśli zainstalowany demon SSH nasłuchuje na niestandardowym porcie, ogólny sshwpis usługi może do niego nie pasować; najpierw sprawdź rzeczywisty port nasłuchu demona i istniejące zasady zapory.
Przykładowa kontrola usługi: definicja usługi HTTP wymienia port TCP 80.
3. Dodaj protokół HTTP na stałe, a następnie załaduj zapisane reguły
Firewalld utrzymuje oddzielne konfiguracje środowiska wykonawczego i trwałe. Zwykłe polecenie zmienia tylko aktywne reguły środowiska wykonawczego; --permanentzapisuje zapisaną konfigurację, ale nie aktywuje jej natychmiast. W przypadku web01 należy dodać usługę HTTP do strefy, która jest właścicielem interfejsu publicznego:
Użyj --zonetego polecenia jawnie, aby reguła nie znalazła się w niezamierzonej strefie domyślnej. Ponowne załadowanie stosuje stałe reguły do środowiska wykonawczego. Niezapisane zmiany tylko w środowisku wykonawczym są odrzucane podczas ponownego ładowania, dlatego przed uruchomieniem sprawdź i zachowaj wszelkie tymczasowe reguły, których celowo potrzebujesz. Aby przetestować usługę przed jej utrwaleniem, możesz najpierw uruchomić ją sudo firewall-cmd --zone=public --add-service=httpbez [brakuje kontekstu --permanent]. Jeśli zadziała, dodaj stałą regułę i ponownie załaduj. Test tylko w środowisku wykonawczym zostanie utracony po ponownym załadowaniu lub restarcie zapory.
Przykładowa sekwencja poleceń: zapisz publicznie limit HTTP, a następnie przeładuj firewalld, aby go zastosować.
Jeśli potrzebujesz pojedynczego portu zamiast predefiniowanej usługi, określ zarówno port, jak i protokół, na przykład --add-port=8080/tcp. Zrób to tylko wtedy, gdy aplikacja faktycznie nasłuchuje na tym porcie. Zezwolenie na zaporę sieciową nie uruchamia serwera WWW, nie tworzy reguły grupy zabezpieczeń w chmurze ani nie konfiguruje routera nadrzędnego; wszystkie warstwy sieciowe muszą zezwalać na ruch.
4. Zweryfikuj dostęp i usuń reguły, których już nie potrzebujesz
Dane wyjściowe powinny znaleźć się httpna obu listach usług, a sprawdzanie konfiguracji powinno zakończyć się bez zgłaszania błędu. Należy również sprawdzić, czy aplikacja nasłuchuje lokalnie, na przykład za pomocą [ sudo ss -lntpusunięto nazwę usługi], i przetestować witrynę z poziomu klienta w docelowej sieci. Lista zapór sieciowych potwierdza regułę, a nie dostępność od początku do końca: DNS, zapora sieciowa w chmurze, routing i sam serwer WWW nadal mogą zablokować lub odrzucić żądanie.
Przykładowy wynik weryfikacji: HTTP pojawia się wśród usług strefy publicznej, natomiast SSH pozostaje na liście.
Jeśli protokół HTTP nie jest już wymagany, usuń zapisaną regułę i przeładuj: sudo firewall-cmd --permanent --zone=public --remove-service=http, a następnie sudo firewall-cmd --reload. Następnie sprawdź ponownie listy wykonawcze i listy stałe. Unikaj usuwania wszystkich reguł lub przełączania się na strefę zaufaną w celu rozwiązania pojedynczego problemu z dostępem; te szersze zmiany mogą ujawnić niepowiązane usługi.