UFW i Nftables w praktyce e-commerce: Bezpieczna konfiguracja serwera pod PrestaShop i WooCommerce

01 Dlaczego warstwa sieciowa w e-commerce wymaga podejścia zero-trust

Bezpieczeństwo infrastruktury serwerowej sklepu internetowego opiera się na zasadzie minimalnego zaufania (zero-trust). Każdy otwarty port i niechroniony panel administracyjny to potencjalny wektor ataku – od prób brute-force na SSH, przez skanowanie podatności CMS, po zautomatyzowane exploity wymierzone w ścieżki /admin czy /wp-admin.

W systemach Linux (Ubuntu Server 24.04 LTS, Debian 12) standardem zarządzania ruchem sieciowym są dwa narzędzia: UFW (Uncomplicated Firewall) – nakładka idealna do szybkiego wdrożenia podstawowych reguł – oraz Nftables, nowoczesny podsystem filtrowania pakietów w kernelu, który całkowicie zastąpił wysłużone Iptables. Poniższy przewodnik pokazuje, jak krok po kroku skonfigurować zaporę sieciową dla serwera e-commerce, łącząc filtrowanie warstwy L4 (porty) z restrykcjami L7 (ścieżki URL).

02 UFW – szybka i skuteczna konfiguracja dla mniejszych i średnich wdrożeń

UFW to przyjazna nakładka na Netfilter, doskonała do szybkiego wdrożenia podstawowych reguł na pojedynczym VPS-ie. Domyślną polityką firewalla powinno być blokowanie całego ruchu wejściowego i zezwalanie na wychodzący.

Krok 1: Polityka domyślna i otwieranie portów HTTP/HTTPS

Sklep internetowy musi przyjmować ruch publiczny na portach 80/tcp (HTTP) oraz 443/tcp (HTTPS). Wszystkie pozostałe porty pozostają domyślnie zamknięte:

bash

# Ustawienie domyślnej polityki – blokada ruchu wchodzącego
ufw default deny incoming
ufw default allow outgoing

# Otwarcie portów dla ruchu WWW – niezbędne dla klientów sklepu
ufw allow 80/tcp
ufw allow 443/tcp

Krok 2: Ograniczenie dostępu do SSH – kluczowy element ochrony

Port SSH (22) nigdy nie powinien być otwarty dla całego Internetu. Jeśli administrujesz serwerem ze stałego adresu IP (np. biuro, VPN), zezwól na połączenia wyłącznie z tego źródła:

bash

ufw allow from 192.0.2.50 to any port 22 proto tcp

Jeśli korzystasz ze zmiennego adresu IP i nie możesz zastosować whitelisty, użyj mechanizmu rate limiting, który tymczasowo blokuje adresy wykonujące zbyt wiele prób logowania w krótkim czasie – skuteczna ochrona przed atakami brute-force na SSH:

bash

ufw limit 22/tcp

Krok 3: Blokowanie uciążliwych adresów IP na podstawie logów

Analizując logi dostępu serwera WWW (/var/log/nginx/access.log), możesz zidentyfikować agresywne boty, skanery podatności lub IP generujące sztuczny ruch. Blokada następuje natychmiastowo:

bash

ufw deny from 203.0.113.100 to any

Na koniec aktywujesz zaporę i weryfikujesz stan reguł:

bash

ufw enable
ufw status verbose

03 Nftables – zaawansowane filtrowanie i wydajność dla platform high-traffic

Dla większych sklepów e-commerce (Magento, rozbudowany WooCommerce z tysiącami SKU), gdzie liczy się każda milisekunda przetwarzania pakietu, lepszym wyborem jest Nftables. W przeciwieństwie do UFW, który generuje reguły dla Iptables (legacy), Nftables operuje bezpośrednio w przestrzeni kernela przez maszynę wirtualną nf_tables, oferując szybsze przetwarzanie reguł i atomowe ich przeładowywanie bez przerywania ruchu.

Poniżej znajduje się kompletna, produkcyjna konfiguracja pliku /etc/nftables.conf dla serwera e-commerce:

bash

#!/usr/sbin/nft -f

flush ruleset

table inet filter {

    # Set dla zaufanych adresów IP – administratorzy, VPN firmowy, IP stagingu
    set trusted_ips {
        type ipv4_addr
        flags interval
        elements = { 192.0.2.50, 198.51.100.12 }
    }

    chain input {
        type filter hook input priority filter; policy drop;

        # Akceptacja całego ruchu na interfejsie loopback – niezbędne dla baz danych i Redis
        iif "lo" accept

        # Stateful firewall: utrzymanie nawiązanych połączeń, odrzucanie nieprawidłowych
        ct state established,related accept
        ct state invalid drop

        # SSH – dostęp wyłącznie dla administratorów z setu trusted_ips
        tcp dport 22 ip saddr @trusted_ips accept

        # HTTP i HTTPS – ruch publiczny dla klientów sklepu
        tcp dport { 80, 443 } accept

        # Opcjonalnie: ICMP echo-request (ping) z ograniczeniem częstotliwości
        ip protocol icmp icmp type echo-request limit rate 5/second accept
    }

    chain forward {
        type filter hook forward priority filter; policy drop;
    }

    chain output {
        type filter hook output priority filter; policy accept;
    }
}

Wdrożenie konfiguracji:

bash

# Walidacja składni przed przeładowaniem – kluczowy krok, by nie odciąć się od serwera
nft -c -f /etc/nftables.conf
systemctl enable nftables
systemctl restart nftables

04 Restrykcje dostępu do paneli administracyjnych: Ochrona L7, której firewall nie zapewni

Samo ograniczenie portów na poziomie warstwy sieciowej (L4) to za mało. Panele administracyjne sklepów – /admin w PrestaShop, /wp-admin w WooCommerce, /backend w Magento – działają na portach 80/443, które muszą być otwarte dla wszystkich klientów. Ograniczenie dostępu do tych ścieżek należy wdrożyć na poziomie serwera WWW (warstwa L7). To krytyczny element ochrony przed zautomatyzowanymi atakami typu credential stuffing, brute-force na formularze logowania oraz exploitami dnia zerowego wymierzonymi w panele administracyjne.

Konfiguracja dla Nginx

W pliku konfiguracyjnym vhosta (/etc/nginx/sites-available/sklep.conf) dopisz blok location ograniczający dostęp do katalogu administracyjnego wyłącznie do wskazanych adresów IP:

nginx

# Ochrona panelu administracyjnego PrestaShop
location /admin {
    # Whitelista adresów IP administratorów
    allow 192.0.2.50;
    allow 198.51.100.12;
    # Jawna blokada dla całej reszty świata
    deny all;
    
    # Przekazywanie żądań do PHP-FPM
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}

Wskazówka bezpieczeństwa dla WooCommerce: Ścieżka /wp-admin jest domyślnie znana każdemu botowi. Rozważ dodatkowe zabezpieczenie przez HTTP Basic Auth nałożone na tę lokację – tworzy to drugą warstwę uwierzytelnienia przed samym formularzem logowania WordPressa.

Konfiguracja dla Apache (.htaccess)

Jeśli serwer korzysta z Apache, analogiczne zabezpieczenie wdrażasz w pliku .htaccess umieszczonym bezpośrednio w katalogu panelu administracyjnego:

apache

<RequireAll>
    # Domyślna odmowa dostępu dla wszystkich
    Require all denied
    # Jawne zezwolenie tylko dla zaufanych IP
    Require ip 192.0.2.50
    Require ip 198.51.100.12
</RequireAll>

05 Podsumowanie i rekomendacja architektoniczna

Mechanizm	Zastosowanie	Poziom ochrony
UFW	Proste konfiguracje, pojedyncze VPS-y, szybkie blokady IP	L4 – porty i adresy źródłowe
Nftables	Wysoka wydajność, atomowe przeładowania reguł, złożone sety IP	L4 – zaawansowane filtrowanie stanowe
Restrykcje Nginx/Apache	Ochrona paneli /admin, /wp-admin, API wewnętrznych	L7 – filtrowanie po ścieżce URL

Kluczowe wnioski dla bezpieczeństwa platformy e-commerce:

• UFW sprawdza się przy prostych konfiguracjach i mniejszym natężeniu ruchu – idealny na start i dla zespołów, które nie specjalizują się w administracji sieciową.
• Nftables to wybór nadrzędny pod kątem wydajności przetwarzania reguł i bezpieczeństwa dużych platform – operuje bezpośrednio w kernelu, bez narzutu legacy Iptables.
• Blokada IP na poziomie serwera WWW dla ścieżek /admin lub /wp-admin to krytyczny, często pomijany element ochrony. Firewall sieciowy nie widzi URL-i – tylko serwer WWW może odróżnić żądanie klienta przeglądającego produkty od ataku na panel logowania.
• Nigdy nie otwieraj SSH na świat – whitelista IP lub rate limiting to absolutne minimum. Rozważ zmianę domyślnego portu 22 na niestandardowy jako dodatkową warstwę security through obscurity.