UFW na Ubuntu Server – reguły, kolejność i typowe pułapki

UFW jest prosty do momentu, w którym administrator wpisze ufw enable na zdalnym serwerze i nagle zaczyna się zastanawiać, czy SSH nadal będzie działało. Sama składnia UFW jest wygodna, ale firewall na produkcji wymaga kolejności: najpierw sprawdzenie usług, potem reguły, dopiero na końcu włączenie.

Ubuntu opisuje UFW jako prosty interfejs do zarządzania firewallem opartym o netfilter. W Ubuntu 26.04 dostępna jest wersja 0.36.2-9build1. To nadal narzędzie do host-based firewall, czyli zabezpieczenia konkretnego serwera, a nie pełny zamiennik firewalla brzegowego.

Poniżej praktyczna checklista konfiguracji UFW na Ubuntu Server.

1. Zanim włączysz UFW, sprawdź usługi

Najpierw zobacz, co realnie nasłuchuje na serwerze:

ss -tulpn

Możesz też użyć raportu UFW:

sudo ufw show listening

Nie otwieraj portów „na wszelki wypadek”. Jeżeli na serwerze działa tylko SSH, Nginx i Zabbix Agent, to reguły powinny dotyczyć tylko tych usług i konkretnych źródeł, z których mają być dostępne.

2. Ustaw polityki domyślne

Typowy punkt startowy dla serwera:

sudo ufw default deny incoming
sudo ufw default allow outgoing

To oznacza: ruch przychodzący blokujemy, ruch wychodzący pozwalamy. Dla większości serwerów aplikacyjnych to sensowne minimum. Jeżeli serwer ma pełnić rolę routera albo firewalla między sieciami, temat jest inny i trzeba używać reguł route oraz routingu w systemie.

3. Nie odetnij sobie SSH

Przed ufw enable dodaj regułę dla SSH. Najlepiej ograniczoną do konkretnego adresu albo sieci administracyjnej:

sudo ufw allow from 192.168.10.0/24 to any port 22 proto tcp comment 'SSH z LAN admin'

Jeżeli administrujesz z jednego stałego IP:

sudo ufw allow from 203.0.113.10 to any port 22 proto tcp comment 'SSH admin'

Dopiero potem:

sudo ufw enable
sudo ufw status verbose

Manpage UFW przypomina, że przy włączaniu firewall może przeładować łańcuchy i przerwać istniejące połączenia, na przykład SSH. Dlatego reguła dostępu powinna istnieć przed włączeniem UFW.

4. Limitowanie SSH

UFW ma prostą komendę limit, która pomaga ograniczyć szybkie próby połączeń. Nie zastępuje to MFA, dobrych haseł, kluczy SSH ani Fail2ban, ale jest lepsze niż pełne otwarcie portu.

sudo ufw limit 22/tcp comment 'limit SSH'

W dokumentacji UFW opisano, że limit blokuje adres, który próbuje zainicjować zbyt wiele połączeń w krótkim czasie. To przydatne na publicznym VPS-ie, ale nie traktuj tego jako głównej ochrony SSH. Lepszy układ to: klucze SSH, brak logowania roota, ograniczenie źródła IP i dopiero potem limit.

5. Reguły dla WWW

Dla serwera www:

sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'

Jeżeli panel administracyjny aplikacji działa na innym porcie, nie otwieraj go publicznie bez potrzeby. Lepiej ograniczyć dostęp:

sudo ufw allow from 192.168.10.0/24 to any port 8080 proto tcp comment 'Panel tylko z LAN'

Reguła allow 8080/tcp bez źródła oznacza dostęp z każdego adresu, także z internetu.

6. Kolejność reguł ma znaczenie

UFW upraszcza składnię, ale pod spodem nadal liczy się kolejność. Przy diagnostyce używaj:

sudo ufw status numbered

Usuwanie po numerze:

sudo ufw delete 3

Uwaga: po usunięciu jednej reguły numery się zmieniają. Jeżeli masz usunąć kilka reguł, sprawdzaj listę po każdym usunięciu albo usuwaj od największego numeru do najmniejszego.

Można też usuwać regułę przez podanie jej treści:

sudo ufw delete allow 80/tcp

To jest bezpieczniejsze, gdy nie chcesz pomylić numeru.

7. Wstawianie reguł na konkretną pozycję

Jeżeli potrzebujesz dodać regułę przed innymi, użyj insert:

sudo ufw insert 1 deny from 198.51.100.20 comment 'blokada adresu'

Albo prepend, gdy reguła ma trafić przed inne reguły danego typu:

sudo ufw prepend deny from 198.51.100.20

To ma znaczenie, gdy najpierw masz szerokie pozwolenie, a później chcesz zablokować konkretny adres. W firewallu zwykle wygrywa pierwsze dopasowanie.

8. IPv6 też trzeba sprawdzić

Jeżeli serwer ma IPv6, firewall musi filtrować również IPv6. Sprawdź:

grep IPV6 /etc/default/ufw
ip -6 addr
sudo ufw status verbose

Wiele osób blokuje usługę po IPv4, a zapomina, że ta sama usługa jest dostępna po IPv6. Jeżeli operator daje publiczne IPv6, sprawdź reguły z obu stron.

Test z zewnątrz:

nmap -6 -Pn adres_ipv6_serwera

Jeżeli nie używasz IPv6, nie zakładaj automatycznie, że go nie ma. Najpierw sprawdź adresację.

9. Logowanie UFW

Włączenie logów:

sudo ufw logging on

Poziomy logowania:

sudo ufw logging low
sudo ufw logging medium

Manpage UFW ostrzega, że wyższe poziomy logowania mogą szybko generować dużo danych i zapełniać dysk. Na serwerze produkcyjnym zwykle zaczynam od low, a poziom zwiększam tylko na czas diagnostyki.

Podgląd logów:

journalctl -k | grep UFW

albo, jeśli system zapisuje do pliku:

sudo tail -f /var/log/ufw.log

10. Reguły aplikacji

UFW potrafi korzystać z profili aplikacji:

sudo ufw app list
sudo ufw app info 'Nginx Full'

Przykład:

sudo ufw allow 'Nginx Full'

To wygodne, ale na serwerze produkcyjnym wolę wiedzieć dokładnie, jakie porty otwieram. Profile są dobre na start, ale przed użyciem zawsze sprawdź ufw app info.

11. UFW i Docker

Jeżeli na serwerze działa Docker, UFW może nie zachowywać się tak, jak oczekujesz. Docker manipuluje regułami firewalla i NAT-em, więc port opublikowany przez kontener może być dostępny mimo pozornie zamkniętej konfiguracji UFW.

Sprawdź:

docker ps
sudo ufw status verbose
sudo iptables -S
sudo iptables -t nat -S

Przy Dockerze nie zakładaj, że sama reguła UFW zamyka wszystko. Testuj dostęp z zewnątrz i uważaj na ports: w compose.yaml, szczególnie przy usługach administracyjnych.

12. Prosty scenariusz dla VPS-a

Przykład serwera z SSH tylko z jednego IP oraz www publicznie:

sudo ufw default deny incoming
sudo ufw default allow outgoing

sudo ufw allow from 203.0.113.10 to any port 22 proto tcp comment 'SSH admin'
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'

sudo ufw enable
sudo ufw status numbered

Po włączeniu sprawdź z drugiego terminala:

ssh user@adres_serwera
curl -I http://adres_serwera
curl -I https://adres_serwera

Nie zamykaj starej sesji SSH, dopóki nie potwierdzisz nowego logowania.

13. Typowe pułapki

Najczęstsze błędy:

• ufw enable przed dodaniem reguły dla SSH,
• otwarcie SSH dla całego internetu bez potrzeby,
• brak sprawdzenia IPv6,
• usunięcie złej reguły po numerze,
• zbyt szeroka reguła typu allow 8080/tcp,
• logowanie ustawione za wysoko i rosnące logi,
• przekonanie, że UFW kontroluje wszystkie porty Dockera,
• brak komentarzy przy regułach,
• brak dokumentacji, po co dana reguła istnieje.

Komentarze naprawdę pomagają:

sudo ufw allow from 10.10.20.0/24 to any port 10050 proto tcp comment 'Zabbix Agent z VLAN monitoringu'

Po kilku miesiącach łatwiej zrozumieć, czy reguła jest nadal potrzebna.

Podsumowanie

UFW jest dobrym narzędziem na Ubuntu Server, jeśli traktujesz je jak firewall, a nie magiczny przełącznik bezpieczeństwa. Najważniejsza kolejność to: sprawdź usługi, dodaj regułę dla SSH, ustaw polityki domyślne, włącz UFW, przetestuj dostęp z zewnątrz i dopiero potem porządkuj resztę.

Na produkcji trzymaj się prostych zasad: nie otwieraj portów bez powodu, ograniczaj źródła IP, pilnuj IPv6, opisuj reguły komentarzami i nie zamykaj starej sesji SSH przed przetestowaniem nowej.

Źródła

• Ubuntu Wiki – UncomplicatedFirewall: https://wiki.ubuntu.com/UncomplicatedFirewall
• Ubuntu 26.04 manpage – ufw: https://manpages.ubuntu.com/manpages/resolute/man8/ufw.8.html