Jeżeli administrujesz serwerami wystawionymi do Internetu dłużej niż kilka dni, to wiesz jedno:
ruch przychodzący w 90% przypadków nie pochodzi od realnych użytkowników.
Skanery portów, boty SIP, brute-force na SSH, losowe zapytania HTTP – wszystko to przychodzi z całego świata, często z regionów, z których nigdy nie spodziewamy się legalnego ruchu.
Dlatego zamiast:
„otwórz port 5060 i zobacz co się stanie”
lepiej zadać sobie pytanie:
„z jakich krajów ten serwer w ogóle powinien być osiągalny?”
W tym artykule pokazuję praktyczne, produkcyjne podejście:
UFW jako prosty i czytelny firewall
ipset jako szybki mechanizm filtrowania
GeoIP jako pierwsza linia obrony
zero magii, zero automatu, pełna kontrola
To rozwiązanie stosuję na serwerach PBX, VoIP, aplikacyjnych i webowych działających 24/7.
W tym poście skupimy się na instalacji ufw, które zastąpi domyślnie zainstalowaną na Debianie 13 zaporę nftables.
Oczywiście wychodzę z założenia, że Debiana masz już zainstalowanego.
Spis treści
1) Wstępne wymagania i założenia
Chyba pierwsze pytanie, które się pojawia w tym momencie to dlaczego UFW, a nie nftables?
Debian 13 startuje dziś z nowoczesnym, wydajnym i bardzo elastycznym firewallem opartym o nftables. I nie ma w tym nic złego — wręcz przeciwnie. Z punktu widzenia jądra to najlepsze, co mamy. Problem pojawia się jednak nie na poziomie technologii, a na poziomie codziennej pracy administratora.
Goły nftables jest jak surowa stal. Można z niej zbudować cokolwiek, ale trzeba dokładnie wiedzieć co się robi, pamiętać o każdym detalu i liczyć się z tym, że po kilku miesiącach nawet autor konfiguracji będzie musiał ją czytać od nowa.
UFW podchodzi do tematu inaczej. Nie próbuje zastąpić nftables ani go „uprościć na siłę”. On po prostu daje czytelną warstwę zarządzającą, która pozwala skupić się na tym, co chcemy osiągnąć, a nie jak dokładnie kernel ma to zrobić.
Kiedy konfigurujesz UFW, myślisz w kategoriach:
„pozwól na SSH”,
„zablokuj wszystko inne”,
„ta sieć jest zaufana”.
A nie:
„stwórz chain, ustaw priorytet, zadbaj o order, pamiętaj o hookach”.
I to robi ogromną różnicę, zwłaszcza na serwerach, które mają działać latami, być przekazywane innym administratorom albo audytowane po czasie.
W praktyce bardzo rzadko spotykam sytuacje, w których „goły” nftables daje realną przewagę funkcjonalną nad UFW. Zdecydowana większość serwerów:
nie potrzebuje skomplikowanego NAT-u,
nie wymaga kilkunastu chainów i setek reguł,
nie jest platformą firewallową samą w sobie.
Za to czytelność i przewidywalność są potrzebne zawsze.
UFW ma jeszcze jedną, często niedocenianą zaletę:
jest stanowy, uporządkowany i trudny do przypadkowego zepsucia. Jedno polecenie ufw status mówi więcej niż kilkadziesiąt linijek reguł nftables. A przy pracy zdalnej to nie jest detal — to różnica między spokojną administracją a nerwowym sprawdzaniem, czy po restarcie nadal mamy dostęp po SSH.
Co ważne: wybierając UFW, nie rezygnujemy z mocy nftables. UFW w Debianie 13 i tak korzysta z backendu nftables, więc wydajność i bezpieczeństwo pozostają na najwyższym poziomie. My po prostu dokładamy warstwę, która ułatwia życie człowiekowi.
Dopiero w momencie, gdy firewall:
ma dynamicznie reagować na routing,
obsługiwać bardzo złożony NAT,
być centralnym elementem infrastruktury sieciowej,
wtedy czysty nftables zaczyna mieć sens jako narzędzie pierwszego wyboru.
Na typowym serwerze aplikacyjnym, PBX czy webowym UFW wygrywa czymś znacznie ważniejszym niż „elastyczność”:
przejrzystością, powtarzalnością i odpornością na błędy ludzkie.
I właśnie dlatego w tym artykule bazujemy na UFW, a nie na surowym nftables.
Sama instalacja jest bardzo prosta. Wystarczy wykonać:
apt update
apt install -y ufw ipset curl jq
W kilku słowach wyjaśnienia:
ufw– warstwa zarządzająca firewallemipset– silnik GeoIPcurlijq– do pobierania i parsowania list IP
Jeśli to ma u Ciebie zastosowanie to dodawaj sudo do poszczególnych poleceń, czyli np.
sudo apt update
zamiast
apt update
2) Podstawowa konfiguracja UFW (bez GeoIP)
Zanim dodamy obsługę GeoIP należy dodać do autostartu naszą zaporę.
systemctl enable --now ufw
Gdybyśmy w tym momencie ją włączyli, zobaczymy, że system domyślnie blokuje ruch przychodzący, a zezwala na ruch wychodzący.
ufw enable
Zanim dodamy reguły możemy zresetować reguły, żeby wiedzieć, na czym stoimy i pięknie poukładać wszystko od zera.
ufw disable
ufw --force reset
Struktura zapytań UFW jest bardzo prosta. Każdym momencie możesz podejrzeć dostępnie opcje za pomocą:
ufw --help
W pierwszej kolejności proponuję dodać minimalną konieczną konfigurację. Może ona zawierać dostęp do SSH oraz dodanie wybranych adresów lokalnych i/lub do białej listy.
ufw allow 22/tcp
ufw allow from 192.168.0.0/24
ufw allow from 10.8.0.0/24
Następnie warto zdefiniować domyślne polityki dla ruchu przychodzącego oraz wychodzącego. Zależnie od potrzeb najczęściej będzie to blokada ruchu przychodzącego oraz zezwolenie na ruch wychodzący.
ufw default deny incoming
ufw default allow outgoing
Po wszystkich uruchamiamy naszą usługę.
ufw enable
W efekcie:
nic nie wchodzi bez pozwolenia
serwer może normalnie wychodzić do świata
Na tym etapie serwer jest bezpieczniejszy, ale jeszcze „ślepy” na dane geolokalizacyjne adresów, z których przychodzi ruch.
ufw status verbose
Polecenia związane z portami automatycznie dodają reguły IPv4 oraz IPv6. Możesz to wyłączyć w pliku /etc/default/ufw.
3) Budowa bazy adresów 'ipset’
W tym momencie mamy już skonfigurowany UFW, który pilnuje podstawowych zasad bezpieczeństwa: wiadomo, co jest otwarte, co zamknięte i kto ma dostęp administracyjny. To dobry fundament, ale nadal jest to ochrona dość „płaska”. Firewall wie na jakie porty można się łączyć, ale nie wie skąd ten ruch pochodzi i czy w ogóle ma sens, żeby z danego miejsca świata ktoś próbował się z nami komunikować.
Właśnie tutaj pojawia się GeoIP.
Zamiast reagować na ataki, skanowania i losowy ruch z Internetu, robimy krok wstecz i zadajemy prostsze pytanie: z jakich krajów ten serwer powinien być osiągalny? Jeśli odpowiedź brzmi „z trzech albo czterech”, to cała reszta świata przestaje nas interesować.
Do realizacji tego pomysłu idealnie nadaje się ipset. Jest to mechanizm działający bezpośrednio w jądrze systemu, zaprojektowany do bardzo szybkiego sprawdzania, czy dany adres IP należy do określonego zbioru. W przeciwieństwie do klasycznych reguł firewalla nie interesuje go kolejność ani liczba wpisów – tysiąc czy pięćdziesiąt tysięcy prefiksów działa tak samo szybko.
Tworzymy więc jeden logiczny zbiór o nazwie geoip_cc. Jego znaczenie jest jednoznaczne: wszystkie adresy IP należące do krajów, z których dopuszczamy (lub blokujemy) ruch do serwera. Nie przechowujemy tu informacji o użytkownikach, operatorach czy konkretnych usługach. To celowe uproszczenie – im mniej logiki na tym etapie, tym mniej problemów później. Nikt przy zdrowych zmysłach nie będzie przecież codzienne aktualizował list za pomocą allow from x.x.x.x/yy.
Oczywiście moglibyśmy w tym momencie ręcznie stworzyć odpowiednie listy. W tym celu najpierw należy stworzyć nowy zbiór. Nazwa może być praktycznie dowolna. Jak nadam nazwę 'geoip_cc’ (z angielskiego country code).
ipset create geoip_cc hash:net
Jest wiele źródeł, z których można pobrać aktualne listy. Ja wykorzystam bazę od ipdeny.com. Pobranie bazy i dodanie do naszego zbioru ipset można dodać za pomocą np. prostej pętli:
curl -s https://www.ipdeny.com/ipblocks/data/countries/pl.zone | \
while read net; do
ipset add geoip_cc "$net"
done
Oczywiście w powyższym kodzie warto pamiętać, żeby wybrać odpowiedni kraj. W tym przypadku dodałem Polskę, czyli pl.zone. Oczywiście do jednej listy można dodać więcej adresów IP.
Żeby sprawdzić czy lista się załadowała wykonaj:
ipset list geoip_cc # kompletna lista
ipset list geoip_cc | head -c 500 # pierwsze 500 znaków
W powyższym przykładzie do naszej listy załadowało 4263 podsieci.
W razie potrzeby możesz też wyczyścić listę i ponownie załadować zaktualizowaną listą adresów IP. Żeby wyczyścić zbiór wykonaj:
ipset flush geoip_cc
4) Automatyczna aktualizacja zbiorów 'ipset’
Żeby taki zbiór miał sens, musi być aktualny. Zakresy IP przypisane do krajów zmieniają się, są przenoszone pomiędzy operatorami i regionami. Dlatego nie tworzymy tego zbioru ręcznie, tylko generujemy go automatycznie na podstawie publicznie dostępnych danych GeoIP.
Skrypt odpowiedzialny za to zadanie jest elementem bezpieczeństwa systemowego, a nie częścią aplikacji. Z tego powodu umieszczamy go w /usr/local/sbin/update-ipset-geoip.sh. To klasyczne miejsce na lokalne narzędzia administracyjne, które nie są zarządzane przez system pakietów i jasno komunikują swoją rolę przy audycie systemu.
Cała konfiguracja skryptu sprowadza się do jednego miejsca – listy dozwolonych krajów zapisanej jako kody ISO. To świadoma decyzja. Zmiana polityki bezpieczeństwa powinna polegać na edycji jednej linijki, a nie na grzebaniu w logice skryptu czy regułach firewalla.
Sam mechanizm działania jest prosty i przewidywalny. Przy uruchomieniu skrypt sprawdza, czy zbiór geoip_cc już istnieje. Jeśli tak, czyści go i buduje od nowa. Jeżeli nie – tworzy go od zera. Następnie pobiera aktualną listę prefiksów IP przypisanych do krajów i dodaje do zbioru tylko te, które odpowiadają krajom zdefiniowanym w konfiguracji. Nie próbujemy aktualizować zbioru „częściowo”, ani inteligentnie porównywać zmian. W bezpieczeństwie systemowym prostota wygrywa z nadmierną optymalizacją.
Poniżej znajduje się kompletny skrypt, z komentarzami tłumaczącymi, co dokładnie dzieje się na każdym etapie:
#!/bin/bash
# ==========================================================
# update-ipset-geoip.sh – build unified ipset from country codes
# ==========================================================
# 🧩 CONFIGURATION
# Comma-separated list of allowed countries (ISO 3166-1 alpha-2 codes)
allow="PL" # Example: "PL" or "PL,DE,CZ"
setname="geoip_cc" # Unified ipset name
datadir="/etc/ufw/geoip" # Storage for downloaded .zone files
source_url="https://www.ipdeny.com/ipblocks/data/countries"
# ==========================================================
# Script logic
# ==========================================================
mkdir -p "$datadir"
# Create or flush ipset
if ipset list "$setname" &>/dev/null; then
echo "→ Flushing existing ipset: $setname"
ipset flush "$setname"
else
echo "→ Creating ipset: $setname"
ipset create "$setname" hash:net
fi
# Normalize list (remove spaces)
countries=$(echo "$allow" | tr -d ' ')
IFS=',' read -ra cc_array <<< "$countries"
total=0
for cc in "${cc_array[@]}"; do
code=$(echo "$cc" | tr '[:upper:]' '[:lower:]')
file="$datadir/${code}.zone"
echo "→ Downloading $code zone..."
if curl -fsS "$source_url/${code}.zone" -o "$file"; then
count=$(wc -l < "$file")
total=$((total + count))
echo " Adding $count IP ranges from $cc ..."
while read -r ip; do
[[ -n "$ip" ]] && ipset add "$setname" "$ip" 2>/dev/null
done < "$file"
else
echo "Failed to download $code"
fi
done
echo "$total total IP ranges loaded into $setname"
# Save for persistence
ipset save > /etc/ipset.conf
echo "Saved to /etc/ipset.conf"
Po zapisaniu skryptu nadajemy mu prawa wykonywania i uruchamiamy ręcznie.
nano /usr/local/sbin/update-ipset-geoip.sh # tutaj wkleić nasz skrypt
chmod +x /usr/local/sbin/update-ipset-geoip.sh
/usr/local/sbin/update-ipset-geoip.sh
W naszym przypadku dodałem do listy trzy kraje: PL, US oraz DE, oddzielone przecinkami.
W efekcie nasz skrypt pobrał łącznie kilkadziesiąt tysięcy podsieci!
Na tym etapie system jest w stanie odpowiedzieć na jedno bardzo ważne pytanie: czy adres IP pochodzi z kraju, który uznajemy za zaufany? Firewall jeszcze z tej wiedzy nie korzysta, ale fundament został przygotowany poprawnie.
W kolejnym kroku ten zbiór zostanie podpięty pod UFW i wtedy GeoIP zacznie realnie wpływać na ruch przychodzący do serwera.
6) Przywracanie bazy 'ipset’ po restarcie systemu (z wykorzystaniem systemd)
Na tym etapie mamy już przygotowany zbiór geoip_cc, który zawiera aktualną bazę adresów IP przypisanych do dozwolonych krajów. Wszystko działa poprawnie… do pierwszego restartu serwera. I to jest moment, w którym wiele konfiguracji GeoIP się „rozsypuje”.
ipset działa w jądrze systemu, ale nie zapisuje swojego stanu na dysku automatycznie. Po restarcie systemu wszystkie zbiory znikają, a firewall – nawet jeśli jest poprawnie skonfigurowany – nie ma już do czego się odwołać. W najlepszym przypadku ruch zostanie zablokowany, w najgorszym firewall wystartuje bez filtrów GeoIP.
Dlatego potrzebujemy mechanizmu, który:
odtworzy zbiór ipset przy starcie systemu
zrobi to zanim uruchomi się UFW
zadziała niezależnie od tego, czy administrator jest zalogowany
Najczystszym rozwiązaniem w Debianie 13 jest użycie systemd.
Zamiast kombinować z cronem @reboot albo skryptami w /etc/rc.local, tworzymy dedykowaną usługę systemową, której jedynym zadaniem jest przywrócenie zapisanej konfiguracji ipset.
Zakładamy, że po ręcznym uruchomieniu skryptu GeoIP zapisaliśmy aktualny stan zbioru do pliku /etc/ipset.conf.
Ten plik jest naszym „snapshotem” bazy GeoIP, który będziemy odtwarzać przy każdym starcie systemu.
Tworzymy teraz plik jednostki systemd:
tee /etc/systemd/system/ipset-restore.service <<'EOF'
[Unit]
Description=Restore ipset rules
Before=ufw.service
DefaultDependencies=no
[Service]
Type=oneshot
ExecStart=/sbin/ipset restore -f /etc/ipset.conf
[Install]
WantedBy=multi-user.target
EOF
Warto zatrzymać się na chwilę przy tej konfiguracji, bo kilka linijek ma tu kluczowe znaczenie.
Sekcja [Unit] definiuje zależności. Najważniejsza jest dyrektywa Before=ufw.service. Dzięki niej mamy gwarancję, że zbiór ipset zostanie odtworzony zanim UFW zacznie ładować swoje reguły. To krytyczne – firewall, który odwołuje się do nieistniejącego zbioru, nie zachowa się w sposób przewidywalny.
DefaultDependencies=no celowo wyłącza domyślne zależności systemd. Chcemy, żeby ta usługa uruchamiała się bardzo wcześnie, bez czekania na sieć, logowanie użytkowników czy inne usługi, które nie mają tu żadnego znaczenia.
Sekcja [Service] jest prosta i czytelna. Typ oneshot oznacza, że usługa wykonuje jedno polecenie i kończy działanie. To dokładnie to, czego potrzebujemy. Polecenie ipset restore wczytuje zapisany wcześniej stan zbiorów z pliku /etc/ipset.conf i przywraca je bezpośrednio do jądra.
W sekcji [Install] wskazujemy multi-user.target, czyli standardowy tryb pracy serwera. Oznacza to, że zbiór ipset będzie dostępny zarówno po normalnym starcie systemu, jak i po restarcie w trybie produkcyjnym.
Na koniec aktywujemy usługę:
systemctl enable ipset-restore
Od tego momentu mechanizm działa automatycznie. Po każdym restarcie systemu:
zbiór
geoip_cczostaje przywrócony z dyskuUFW startuje już z gotową bazą GeoIP
reguły firewalla zachowują się identycznie jak przed rebootem
To rozwiązanie jest stabilne, przewidywalne i łatwe do debugowania. W razie problemów wystarczy sprawdzić status usługi ipset-restore, bez zgadywania, czy skrypt zadziałał i w którym momencie systemu.
Dopiero mając ten element na miejscu, możemy bezpiecznie przejść do kolejnego kroku – podpięcia zbioru GeoIP pod reguły UFW.
7) Podpięcie GeoIP pod UFW
Zasadnicza część pracy jest już za nami:
mamy działający firewall, mamy zbudowaną bazę GeoIP w ipset, mamy mechanizm, który przywraca ją po restarcie systemu. Teraz dochodzimy do momentu, w którym te elementy zaczynają ze sobą realnie współpracować.
Kluczowym miejscem całej integracji jest plik:
/etc/ufw/before.rules
I warto poświęcić mu chwilę uwagi, bo to jeden z tych plików, które robią ogromną różnicę, a jednocześnie są często edytowane bez pełnego zrozumienia.
Czym jest /etc/ufw/before.rules?
UFW nie jest osobnym firewallem. To warstwa zarządzająca nad iptables (w Debianie 13 – nad nftables w trybie kompatybilnym). Wszystkie reguły, które definiujemy poleceniami ufw allow czy ufw deny, ostatecznie trafiają do zestawu reguł jądra.
Plik before.rules jest specjalny, bo zawiera reguły wykonywane przed tymi, które generuje UFW.
Można to sobie wyobrazić tak:
Najpierw kernel sprawdza reguły z
before.rulesDopiero później przechodzi do standardowych reguł UFW
Na końcu stosowane są polityki domyślne (
deny,allow)
Dzięki temu before.rules jest idealnym miejscem na:
integrację z ipset
niestandardowe matchery
logikę, której UFW nie potrafi opisać poleceniami CLI
I dokładnie to robimy z GeoIP.
UFW sam w sobie:
nie zna pojęcia ipset
nie wie, czym jest GeoIP
operuje na prostych regułach typu port/protokół/IP
Natomiast iptables (a więc i nftables) potrafią sprawdzić czy adres źródłowy należy do określonego zbioru ipset.
Podpinając się w before.rules, uzyskujemy bardzo czyste zachowanie:
jeśli ruch pochodzi z dozwolonego kraju → akceptujemy go od razu
jeśli nie → trafia dalej i zostaje zablokowany przez domyślną politykę UFW
Nie musimy dodawać żadnych reguł deny.
Nie musimy utrzymywać blacklist.
Po prostu nie wpuszczamy ruchu, który nie spełnia kryterium GeoIP.
Warto też pamiętać, że kolejność ma znaczenie. W pliku before.rules znajduje się linia:
# don't delete the 'COMMIT' line
To bardzo ważny punkt odniesienia.
Wszystkie reguły muszą znaleźć się przed COMMIT, inaczej nie zostaną załadowane.
Zamiast edytować plik ręcznie (co łatwo zepsuć), używamy prostego mechanizmu, który:
wstrzykuje nasze reguły dokładnie w odpowiednie miejsce
zachowuje całą resztę pliku bez zmian
jest powtarzalny i bezpieczny
Poniżej znajduje się gotowy fragment, który:
pozwala na HTTP i HTTPS
dopuszcza SIP (UDP 5060, TLS 5061)
otwiera zakres RTP
ale tylko wtedy, gdy adres źródłowy znajduje się w zbiorze ipset
awk '
/^# don.t delete the .COMMIT. line/ {
print "# Allow HTTP/HTTPS/SIP/RTP only from selected countries (ipset: geoip_cc)"
print "-A ufw-before-input -p tcp --dport 80 -m set --match-set geoip_cc src -j ACCEPT"
print "-A ufw-before-input -p tcp --dport 443 -m set --match-set geoip_cc src -j ACCEPT"
print "-A ufw-before-input -p udp --dport 5060 -m set --match-set geoip_cc src -j ACCEPT"
print "-A ufw-before-input -p tcp --dport 5061 -m set --match-set geoip_cc src -j ACCEPT"
print "-A ufw-before-input -p udp --dport 10000:11000 -m set --match-set geoip_cc src -j ACCEPT"
print ""
}
{print}
' /etc/ufw/before.rules > /etc/ufw/before.rules.new && mv /etc/ufw/before.rules.new /etc/ufw/before.rules
Warto zwrócić uwagę na kilka rzeczy.
Po pierwsze, wszystkie reguły trafiają do chaina ufw-before-input. To oznacza, że są sprawdzane zanim UFW zacznie stosować swoje standardowe reguły.
Po drugie, każda reguła zawiera matcher:
-m set --match-set geoip_cc src
To właśnie tutaj następuje połączenie firewalla z GeoIP. Kernel sprawdza, czy adres źródłowy pakietu znajduje się w zbiorze pbx_cc. Jeżeli tak – pakiet zostaje zaakceptowany. Jeżeli nie – reguła nie pasuje i ruch idzie dalej.
Po trzecie, brak reguł DROP jest celowy.
Nie blokujemy niczego explicite. Cała reszta ruchu zostanie odrzucona przez domyślną politykę deny incoming, którą skonfigurowaliśmy na samym początku.
Po modyfikacji pliku wystarczy przeładować UFW:
ufw reload
Warto jednak pamiętać, że reguły before.rules są wczytywane przed UFW, więc nie będą widoczne w poleceniu ’ufw status’.
Od tego momentu:
usługi są dostępne tylko z dozwolonych krajów
ruch spoza GeoIP nawet nie dociera do aplikacji
firewall zachowuje się identycznie po restarcie systemu
To rozwiązanie nie jest efektowne.
Jest przewidywalne i skuteczne – a dokładnie takie powinno być bezpieczeństwo serwera produkcyjnego.
Jeżeli chciałbyś monitorować wszystko, co dzieje się na Twojej centrali, wypróbuj nasze autorskie oprogramowanie VoiperoManager.
Instalacja i konfiguracja zajmuje kilka minut, a system możesz mieć całkowicie za darmo.
Przeczytaj, co potrafi nasz system VoiperoManager w zakresie monitorowania na żywo i raportowania systemów VoIP opartych na Asterisku.
