Zabezpieczenie serwera PrestaShop: fail2ban, Cloudflare i DDoS

Zabezpieczenie serwera PrestaShop to kilka warstw, które działają razem: aktualny system i PHP, firewall z otwartymi tylko niezbędnymi portami, logowanie SSH wyłącznie kluczem, fail2ban blokujący adresy, które łamią hasła i skanują sklep, limity żądań w nginx oraz Cloudflare przed serwerem — z ochroną przed DDoS, zaporą WAF i filtrem botów. Do tego chroniony panel administracyjny, logi, monitoring i kopie zapasowe. Poniżej wyjaśniamy każdą warstwę po kolei, z przykładami konfiguracji i listą kontrolną na koniec.

Dlaczego serwer sklepu jest celem ataków?

Większość ataków na sklepy internetowe nie jest wymierzona w konkretny sklep. To automaty, które przez całą dobę sprawdzają tysiące adresów: szukają zapomnianych kopii bazy (backup.sql), plików konfiguracyjnych (.env, .git), paneli logowania i modułów ze znanymi podatnościami. Rejestr Friends of Presta regularnie publikuje nowe luki w modułach PrestaShop, a część z nich da się wykorzystać bez logowania. Jak rozpoznać, że sklep został już zaatakowany, opisujemy w artykule Bezpieczeństwo PrestaShop: podatności CVE i objawy ataku.

Serwer jest tu pierwszą linią obrony. Dobrze skonfigurowany odrzuca skanery, zanim dotrą do PHP, ogranicza próby logowania i nie pozwala uruchomić wgranego skryptu. Na naszym serwerze reguła fail2ban dla skanerów w pierwszej godzinie po włączeniu sama zablokowała 8 adresów, które szukały plików .env i paneli WordPressa — w sklepie PrestaShop.

Fundament: system, PHP i firewall

Najlepsza konfiguracja nie pomoże, jeśli serwer działa na oprogramowaniu bez poprawek bezpieczeństwa. Zacznij od podstaw:

Wersja PHP to częsty problem sklepów na PrestaShop 8, który działa najwyżej na PHP 8.1. Przejście na nowsze PHP wymaga aktualizacji sklepu — jak to zrobić bez utraty danych, pokazujemy w poradniku Aktualizacja PrestaShop krok po kroku.

W konfiguracji nginx zablokuj też dostęp do katalogów, które nie powinny być publiczne, i uruchamianie PHP w katalogach na pliki. Oficjalny przykład konfiguracji z dokumentacji PrestaShop odrzuca żądania plików .php w img/ i upload/, pliki ukryte oraz katalogi app, config, classes i vendor. Dzięki temu nawet jeśli ktoś wgra skrypt przez formularz, nie uruchomi go.

Bezpieczne logowanie: SSH i panel PrestaShop

SSH tylko kluczem, bez konta root

Hasło do SSH można zgadnąć, klucza praktycznie nie. W pliku /etc/ssh/sshd_config wyłącz logowanie hasłem i konto root, a dostęp zostaw tylko wybranym użytkownikom:

PasswordAuthentication no
PermitRootLogin no
MaxAuthTries 3
AllowUsers admin sklep

Każdy programista, który pracuje na serwerze, powinien mieć własne konto i własny klucz. Gdy współpraca się kończy, usuwasz jeden klucz, zamiast zmieniać wspólne hasło.

Panel administracyjny PrestaShop

• Unikalny katalog panelu — instalator PrestaShop nadaje mu losową nazwę. Nie zmieniaj jej na admin i nie publikuj jej w linkach.
• Osobne konta pracowników w Zaawansowane → Zespół → Pracownicy, bez wspólnych loginów. Konta osób, które już nie pracują przy sklepie, usuwaj od razu.
• Powiązanie sesji z adresem IP: opcja Sprawdź adres IP cookie w Zaawansowane → Administracja utrudnia przejęcie skradzionego ciasteczka.
• Dostęp z wybranych adresów: jeśli zespół pracuje ze stałych adresów IP albo przez VPN, ogranicz do nich katalog panelu w nginx. To najskuteczniejsza ochrona przed łamaniem haseł.
• Drugi składnik logowania: według OWASP uwierzytelnianie wieloskładnikowe to najsilniejsza pojedyncza obrona przed przejęciem konta. Jeśli Twoja wersja sklepu go nie ma, dodaj go modułem albo ogranicz panel adresami IP.

fail2ban: automatyczne blokowanie ataków

fail2ban czyta logi serwera i blokuje w firewallu adresy, które zachowują się jak atakujący: kilka nieudanych logowań, seria żądań do nieistniejących plików, przekroczony limit zapytań. Blokada trwa określony czas, a adres, który wraca, dostaje dłuższą. To prosta i skuteczna ochrona przed łamaniem haseł i skanerami.

Dla serwera ze sklepem PrestaShop przydają się te reguły (jails), dostępne w standardowej instalacji fail2ban:

Przykładowy fragment pliku /etc/fail2ban/jail.local:

[sshd]
enabled  = true
maxretry = 4
findtime = 10m
bantime  = 1h

[recidive]
enabled  = true
bantime  = 1w

Limit żądań ustawiasz w nginx modułem limit_req. Najważniejsze są adresy, które obciążają serwer albo przyjmują hasła: logowanie klienta, panel, wyszukiwarka. Nginx odpowiada wtedy kodem 429, a fail2ban blokuje adres, który robi to nagminnie.

limit_req_zone $binary_remote_addr zone=login:10m rate=10r/m;

location ~ ^/(pl/logowanie|login)$ {
    limit_req zone=login burst=5 nodelay;
    try_files $uri /index.php?$args;
}

Ważne: za Cloudflare wszystkie żądania przychodzą z adresów Cloudflare. Bez przywrócenia prawdziwego IP klienta w nginx (nagłówek CF-Connecting-IP) fail2ban zablokuje Cloudflare zamiast atakującego, a limity żądań obejmą wszystkich klientów naraz. Blokadę ruchu przechodzącego przez Cloudflare trzeba też przenieść do Cloudflare — fail2ban ma do tego gotowe akcje cloudflare i cloudflare-token.

Cloudflare przed sklepem PrestaShop

Cloudflare działa jak pośrednik między klientami a Twoim serwerem. Gdy rekord DNS sklepu jest „proxied” (pomarańczowa chmurka), odwiedzający widzą adres Cloudflare, a ruch przechodzi przez jego filtry. Co dostajesz już w bezpłatnym planie:

• Ochronę przed DDoS na warstwach 3, 4 i 7 — według dokumentacji Cloudflare bez limitu wielkości i czasu ataku, na każdym planie.
• Zaporę WAF z darmowym zestawem reguł zarządzanych (Free Managed Ruleset) i własnymi regułami, np. blokadą krajów, z których nie sprzedajesz, dla panelu administracyjnego.
• Jedną regułę limitu żądań — warto ją przeznaczyć na logowanie albo wyszukiwarkę.
• Bot Fight Mode i opcję blokowania botów AI.
• Cache plików statycznych (obrazy, CSS, JS), który odciąża serwer. Cloudflare domyślnie nie zapisuje stron HTML, i dobrze — koszyk i konto klienta muszą być zawsze aktualne. Nie włączaj „Cache Everything” dla całego sklepu.

Ustaw szyfrowanie Full (strict), żeby połączenie między Cloudflare a serwerem też było szyfrowane i weryfikowane, oraz przywróć w nginx prawdziwe adresy klientów: moduł realip, set_real_ip_from z listą zakresów Cloudflare i real_ip_header CF-Connecting-IP. Bez tego logi, statystyki i blokady pokazują tylko adresy Cloudflare.

Ochrona przed DDoS

Atak DDoS (rozproszona odmowa usługi) to zalanie sklepu ruchem z tysięcy adresów naraz, żeby przestał odpowiadać. Są dwa główne rodzaje:

• Ataki wolumetryczne (warstwy 3 i 4) — miliony pakietów, które zapychają łącze serwera. Żaden firewall na samym serwerze ich nie zatrzyma, bo łącze jest pełne, zanim pakiety do niego dotrą. Pomaga tylko filtrowanie przed serwerem, np. w Cloudflare.
• Ataki na aplikację (warstwa 7, HTTP flood) — pozornie zwykłe żądania do kosztownych stron: wyszukiwarki, filtrów, koszyka. Kilkaset na sekundę wystarczy, żeby PHP i baza przestały nadążać. Tu pomagają limity żądań, cache i reguły WAF.

Cloudflare chroni jednak tylko wtedy, gdy atakujący nie zna prawdziwego adresu serwera. Jeśli go zna, wysyła ruch bezpośrednio i omija całą ochronę. Dlatego:

1. Ukryj adres serwera. Sprawdź wszystkie rekordy DNS: subdomeny typu ftp, mail czy dev bez proxy zdradzają adres. Maile wysyłane z serwera sklepu mają go w nagłówkach — wysyłaj je przez zewnętrzny serwer SMTP.
2. Zmień adres IP po włączeniu Cloudflare. Stary adres mógł zostać zapisany w historycznych bazach DNS.
3. Przyjmuj ruch HTTP tylko od Cloudflare. W firewallu otwórz porty 80 i 443 wyłącznie dla zakresów Cloudflare albo włącz Authenticated Origin Pulls, czyli certyfikat, którym Cloudflare potwierdza swoje połączenia.
4. Odciąż serwer cache. Każdy obrazek i plik CSS podany z Cloudflare to żądanie, które nie trafia do PHP. O cache po stronie sklepu piszemy w poradniku Jak przyspieszyć PrestaShop.
5. Miej plan na atak. Tryb „I'm Under Attack” w Cloudflare na czas ataku pokazuje każdemu odwiedzającemu krótkie sprawdzenie przeglądarki. Włączasz go jednym przyciskiem.

Wskazówka: limit żądań w nginx i Cloudflare ustaw osobno dla wyszukiwarki i filtrów produktów. To najczęstszy cel ataków HTTP flood na sklepy, bo każde takie zapytanie kosztuje bazę danych znacznie więcej niż zwykła strona.

Boty: dobre, złe i AI

Duża część ruchu w sklepie to boty. Nie wszystkie trzeba blokować:

• Dobre boty — Googlebot, Bingbot, Google Merchant Center, porównywarki cen. Bez nich sklep znika z wyników i reklam. Uwaga: każdy może podać się za Googlebota. Google zaleca sprawdzanie adresu odwrotnym zapytaniem DNS (nazwa musi kończyć się na googlebot.com, google.com lub googleusercontent.com) i ponownym zapytaniem o ten adres.
• Złe boty — skanery podatności, boty łamiące hasła, kopiujące ceny i treści, zakładające fałszywe konta. Na nie działają Bot Fight Mode, limity żądań, pułapki na typowe ścieżki skanerów (np. /wp-login.php, /.env) i fail2ban.
• Boty AI — crawlery zbierające treści dla modeli językowych. Część respektuje robots.txt, ale plik ten jest tylko prośbą, nie blokadą. Jeśli nie chcesz udostępniać treści, włącz w Cloudflare blokowanie botów AI.

Formularze kontaktowe i rejestracji chroń przed spamem testem CAPTCHA, a logowania — limitem prób. Dzięki temu nie musisz blokować całych krajów ani sieci, co mogłoby odciąć prawdziwych klientów.

Logi, monitoring i kopie zapasowe

Zabezpieczenia trzeba widzieć w działaniu. Włącz i przeglądaj:

• Logi nginx (ruch i błędy) — pokazują skanowanie, nagłe skoki ruchu i błędy 5xx.
• PHP-FPM slowlog — skrypty, które działają za długo, często pierwszy objaw ataku na wyszukiwarkę albo wadliwego modułu.
• MySQL slow query log — wolne zapytania do bazy, które przy większym ruchu zatrzymują sklep.
• Monitoring z zewnątrz — dostępność sklepu co minutę, zasoby serwera, ważność certyfikatu SSL. Alarm ma trafić do osoby, która zareaguje.
• Kopie zapasowe — codziennie pliki i baza, z kilku dni wstecz, przechowywane także poza samym serwerem. Kopia, której nigdy nie przywrócono, to tylko nadzieja: sprawdź odtworzenie przynajmniej raz.

Jeśli nie wiesz, w jakim stanie jest Twój sklep i serwer, zacznij od audytu bezpieczeństwa sklepu: dostaniesz listę podatności z oceną ryzyka i szacowanym czasem naprawy.

Lista kontrolna zabezpieczenia serwera

Nie chcesz zajmować się tym sam? W usłudze Serwer i opieka administracyjna PrestaShop przygotowujemy serwer według tej listy, przenosimy na niego sklep i dbamy o niego na co dzień.

Źródła

• Cloudflare: About DDoS protection — ochrona warstw 3, 4 i 7 na wszystkich planach.
• Cloudflare: Protect your origin server — ukrycie adresu serwera, ruch tylko od Cloudflare, Authenticated Origin Pulls.
• Cloudflare: Restoring original visitor IPs i zakresy adresów Cloudflare.
• Cloudflare WAF i ochrona przed botami w planie Free.
• fail2ban — oficjalne repozytorium (reguły i akcje, w tym cloudflare-token).
• nginx: moduł ngx_http_limit_req_module.
• PrestaShop: konfiguracja nginx (dokumentacja dla programistów).
• OpenSSH: sshd_config.
• Ubuntu Server: automatyczne aktualizacje.
• PHP: wspierane wersje.
• Google: weryfikacja Googlebota.
• OWASP: Credential Stuffing Prevention Cheat Sheet.
• Friends of Presta: ostrzeżenia bezpieczeństwa PrestaShop.

Najczęściej zadawane pytania

Chcesz, żeby ktoś zabezpieczył serwer Twojego sklepu i pilnował go na co dzień? Napisz do nas — doradzimy, od czego zacząć.

Produkty z tego wpisu

Serwer i opieka administracyjna PrestaShop (1 miesiąc)

119,00 €

Ocena na 5 gwiazdek na podstawie () opinii

Dodaj do koszyka

Wróć do: Blog