Jak bezpiecznie skonfigurować reguły zapory sieciowej VPS
Opublikowano 4 września 2026
Zapora sieciowa powinna przepuszczać ruch, którego potrzebuje serwer, i po cichu odrzucać całą resztę. Aby bezpiecznie skonfigurować reguły zapory sieciowej VPS, zacznij od usług, które muszą pozostać osiągalne, zwłaszcza SSH, a następnie dodawaj porty webowe i aplikacyjne po jednym naraz. Nie zaczynaj od blokowania wszystkiego z jedynej otwartej sesji terminala, jaką masz. W ten sposób spokojne zadanie konserwacyjne zamienia się w zadanie odzyskiwania dostępu przez konsolę.
W przypadku większości wdrożeń Linux VPS praktyczny cel jest prosty: domyślnie blokować niezamówiony ruch przychodzący, zezwalać na wymagany ruch wychodzący i tworzyć wąskie reguły przychodzące dla zaufanych użytkowników oraz usług. To zmniejsza powierzchnię ataku bez utrudniania rutynowej administracji.
Zacznij od mapy ruchu
Zanim zmienisz jakąkolwiek regułę, zapisz, co VPS faktycznie robi. Na przykład publiczna strona WordPress zwykle potrzebuje SSH do administracji oraz portów 80 i 443 dla ruchu webowego. Prywatne API może potrzebować tylko HTTPS, podczas gdy serwer bazy danych zwykle powinien akceptować połączenia wyłącznie z serwera aplikacyjnego w sieci prywatnej.
Najpierw sprawdź usługi nasłuchujące. W większości dystrybucji Linux to polecenie daje przydatny wgląd:
```bash sudo ss -tulpn ```
Nie otwieraj automatycznie każdego wyświetlonego portu. Niektóre usługi nasłuchują tylko na localhost lub na prywatnym interfejsie i nie potrzebują publicznego dostępu przez zaporę sieciową. Inne mogą być starymi usługami testowymi, agentami monitoringu lub oprogramowaniem, które w ogóle nie powinno być osiągalne z internetu.
Dla każdego portu wystawionego publicznie odpowiedz na trzy pytania: kto go potrzebuje, skąd i przez jaki protokół? Reguła zezwalająca na HTTPS z dowolnego miejsca jest normalna dla publicznej strony internetowej. Reguła zezwalająca na port bazy danych z dowolnego miejsca to zwykle problem, który grzecznie czeka w logach.
Zachowaj ścieżkę odzyskiwania dostępu, zanim skonfigurujesz reguły zapory sieciowej VPS
Utrzymuj dwie aktywne sesje SSH podczas wprowadzania zmian w zaporze sieciowej. Użyj jednej sesji do stosowania reguł, a drugą pozostaw bez zmian. Po zastosowaniu zmiany przetestuj nowe połączenie z innego terminala, zanim cokolwiek zamkniesz. Pozwala to wychwycić błędy w rzeczywistej ścieżce połączenia zamiast polegać na optymizmie.
Potwierdź również, że konsola dostawcy VPS jest dostępna. Konsola w przeglądarce lub środowisko ratunkowe to plan awaryjny, jeśli SSH zostanie zablokowane. To nie zastępuje ostrożnej pracy, ale jest dobrym zabezpieczeniem operacyjnym.
Jeśli SSH działa na niestandardowym porcie, zweryfikuj to przed utworzeniem reguł:
```bash sudo ss -tulpn | grep ssh ```
Niestandardowy port SSH może zmniejszyć tło szumów z automatycznych skanów, ale sam w sobie nie stanowi znaczącego zabezpieczenia. Prawdziwą pracę wykonują silne uwierzytelnianie, ograniczony dostęp źródłowy i terminowe aktualizacje poprawek.
Użyj domyślnej polityki blokowania ruchu przychodzącego z UFW
UFW to praktyczny interfejs zapory sieciowej dla serwerów VPS z Ubuntu i systemami opartymi na Debianie. Łatwo się go później czyta, co ma znaczenie, gdy inny administrator musi diagnozować awarię o 2 w nocy.
Najpierw ustaw rozsądne wartości domyślne:
```bash sudo ufw default deny incoming sudo ufw default allow outgoing ```
Następnie zezwól na SSH przed włączeniem zapory sieciowej. Jeśli serwer używa domyślnego portu SSH, użyj:
```bash sudo ufw allow OpenSSH ```
Jeśli SSH nasłuchuje na porcie niestandardowym, określ go jawnie. Ten przykład używa portu 2222:
```bash sudo ufw allow 2222/tcp ```
Dla zwykłej publicznej strony internetowej zezwól na HTTP i HTTPS:
```bash sudo ufw allow 80/tcp sudo ufw allow 443/tcp ```
Następnie włącz zaporę sieciową i sprawdź wynikową politykę:
```bash sudo ufw enable sudo ufw status numbered ```
Numerowany status jest przydatny, ponieważ później można precyzyjnie usuwać reguły. Unikaj pozostawiania po diagnozowaniu problemów tymczasowych, zbyt szerokich reguł. Tymczasowe reguły mają zabawną skłonność do stawania się stałym elementem wyposażenia.
Jeśli VPS hostuje aplikację webową za reverse proxy, port aplikacji może nie wymagać publicznego dostępu. Na przykład Nginx może przyjmować ruch na portach 80 i 443, podczas gdy aplikacja nasłuchuje na `127.0.0.1:3000`. W takim projekcie reguła zapory sieciowej dla portu 3000 nie jest potrzebna.
Ogranicz dostęp administracyjny według źródłowego adresu IP
SSH nie powinno być otwarte dla każdego adresu, chyba że Twój zespół rzeczywiście potrzebuje takiej elastyczności. Jeśli Twoje biuro, VPN lub jump host ma stały publiczny adres IP, ogranicz do niego SSH:
```bash sudo ufw allow from 203.0.113.25 to any port 22 proto tcp ```
W przypadku rozproszonego zespołu ze zmieniającymi się domowymi adresami IP VPN lub host bastionowy są często lepszym rozwiązaniem niż globalne otwarcie SSH. Wymaga to nieco pracy konfiguracyjnej, ale daje jedną kontrolowaną ścieżkę administracyjną i czytelniejszy ślad audytowy.
Ograniczanie szybkości może również zmniejszyć liczbę podstawowych prób odgadywania haseł SSH:
```bash sudo ufw limit 22/tcp ```
To nie zastępuje kluczy SSH, wyłączonego uwierzytelniania hasłem tam, gdzie to właściwe, ani dostępu wieloskładnikowego przez ścieżkę zarządzania. Pomyśl o tym jak o jednym panelu ogrodzenia, a nie całym ogrodzeniu.
Traktuj bazy danych, panele i monitoring oddzielnie
Porty baz danych, takie jak MySQL na 3306, PostgreSQL na 5432, Redis na 6379 i MongoDB na 27017, prawie nigdy nie powinny być publicznie dostępne. Zezwalaj na nie tylko z prywatnego adresu IP lub podsieci serwera aplikacyjnego.
Na przykład, aby zezwolić na połączenia MySQL tylko z aplikacyjnego VPS pod adresem `10.10.0.12`:
```bash sudo ufw allow from 10.10.0.12 to any port 3306 proto tcp ```
Sama usługa bazy danych powinna również, tam gdzie to możliwe, wiązać się z zamierzonym prywatnym interfejsem. Reguły zapory sieciowej i wiązanie usługi to odrębne warstwy. Użycie obu oznacza, że błędna zmiana w zaporze sieciowej z mniejszym prawdopodobieństwem wystawi usługę na zewnątrz.
Panele hostingowe, dashboardy Grafana i endpointy monitoringu zasługują na taką samą uwagę. Jeśli są przeznaczone tylko dla personelu, ogranicz je do VPN, biurowego zakresu IP lub dedykowanej sieci zarządzającej. Publiczne strony monitoringu mogą ujawniać więcej szczegółów o infrastrukturze, niż się spodziewasz, nawet jeśli nie pokazują sekretów.
Uwzględnij zaporę sieciową dostawcy i IPv6
Twój VPS może mieć więcej niż jedną warstwę zapory sieciowej. Zapora sieciowa chmury lub na poziomie dostawcy filtruje ruch, zanim dotrze on do serwera, podczas gdy UFW, firewalld, nftables lub iptables filtrują ruch na samym VPS. Używanie obu ma sens, ale reguły muszą być zgodne.
Jeśli port 443 jest otwarty na VPS, ale zablokowany na warstwie dostawcy, odwiedzający nadal nie będą mogli się połączyć. Jeśli dostawca zezwala na port, ale VPS go blokuje, VPS pozostaje chroniony. Podczas diagnozowania sprawdzaj obie warstwy po kolei: politykę dostawcy, zaporę sieciową VPS, adres nasłuchiwania usługi i konfigurację aplikacji. Logi zwykle opowiadają tę samą historię, gdy to wszystko zostanie sprawdzone.
Nie zapomnij o IPv6. Jeśli Twój VPS ma publiczny adres IPv6, wymagane są równoważne reguły IPv6. UFW może zarządzać IPv6, gdy jest ono włączone w jego konfiguracji, ale zweryfikuj to poleceniem:
```bash sudo ufw status verbose ```
Prawidłowo zabezpieczony adres IPv4 nie pomaga, jeśli ta sama usługa jest szeroko otwarta przez IPv6.
Testuj z zewnątrz, a potem monitoruj wynik
Po każdej istotnej zmianie testuj z sieci spoza VPS. Potwierdź, że zamierzone usługi działają, a następnie potwierdź, że porty, które mają pozostać prywatne, nie są osiągalne. Testy w przeglądarce są przydatne dla stron internetowych, ale testy w wierszu poleceń dają jaśniejsze odpowiedzi dla konkretnych portów:
```bash nc -vz your-server-ip 443 ```
W przypadku zablokowanych portów limit czasu lub odmowa mogą oznaczać różne rzeczy w zależności od reguły i stanu usługi. Przejrzyj stan zapory sieciowej, stan usługi i logi systemowe, zamiast zmieniać kilka ustawień naraz.
Włączaj logowanie ostrożnie podczas diagnozowania problemu:
```bash sudo ufw logging low ```
Niski poziom logowania zwykle wystarcza, aby zauważyć nieoczekiwany odrzucony ruch bez generowania niepotrzebnej aktywności dysku. Na obciążonych serwerach logi zapory sieciowej o dużym wolumenie mogą stać się osobną drobną uciążliwością operacyjną.
Przeglądaj reguły zapory sieciowej za każdym razem, gdy wdrażasz nową usługę, wycofujesz starą aplikację, zmieniasz biurowe adresy IP lub modyfikujesz architekturę sieci. Najlepsze reguły nie są najdłuższym zestawem reguł. To najmniejszy zestaw, który dokładnie opisuje, jak serwer powinien się komunikować.
Jeśli wolisz nie wykonywać tej pracy samodzielnie, zespół managed VPS może przejrzeć wymagania dostępu, wdrożyć zmiany z planem odzyskiwania i monitorować serwer później. W kodu.cloud naturalnie wpisuje się to w managed operations oraz ongoing monitoring, szczególnie dla zespołów, które muszą skupić się na klientach i produkcie zamiast na filtrowaniu pakietów.
Zapora sieciowa wykonuje swoją pracę wtedy, gdy nikt jej nie zauważa. Utrzymuj wąską politykę, dokumentuj, dlaczego istnieje każdy wyjątek, i testuj dostęp, zanim uznasz, że usługa znów działa spokojnie.
Andres Saar Inżynier ds. obsługi klienta