Najczęściej sklep trafia do nas z hostingu współdzielonego. Dopóki zamówień jest mało, da się żyć. Potem przychodzi wyprzedaż, kampania reklamowa albo zwykły scraper cen konkurencji — strony ładują się po dziesięć sekund, koszyk się zawiesza, a hosting przysyła maila o „przekroczeniu zasobów".

Druga typowa historia to bezpieczeństwo. PrestaShop, WooCommerce i OpenCart stoją na modułach od różnych autorów, a stary moduł z dziurą to codzienność. Boty bez przerwy odpytują /admin, szukają znanych podatności i zgadują hasła. Jeśli na tym samym serwerze leży jeszcze setka cudzych stron, nie macie wpływu ani na wersję PHP, ani na sąsiadów.

Przenosimy sklep na osobny serwer w OVH lub Hetznerze i budujemy wokół niego kilka warstw ochrony. Opisujemy to na przykładzie PrestaShop, ale WooCommerce i OpenCart robimy według tego samego schematu — różnią się tylko szczegóły konfiguracji.

Co robimy

Na serwerze fizycznym instalujemy Proxmox VE i rozdzielamy sklep na osobne kontenery lub maszyny wirtualne:

  • Węzeł brzegowy — reverse proxy (Nginx lub Traefik), certyfikaty Let’s Encrypt z automatycznym odnawianiem, rate limiting i WAF. Tylko on jest widoczny z internetu.
  • Warstwa web — Nginx + PHP-FPM w wymaganej wersji, OPcache dla kodu PHP, Redis na sesje i cache sklepu.
  • Baza danych — MariaDB lub MySQL w osobnym kontenerze, bez dostępu z zewnątrz, z buforami dobranymi do wielkości katalogu.
  • Staging — kopia sklepu z zanonimizowaną bazą. Tu aktualizujemy PrestaShop, moduły i szablon, zanim dotkniemy produkcji.
  • Monitoring — Prometheus i Grafana: obciążenie, błędy 5xx, czas odpowiedzi, miejsce na dyskach, ważność certyfikatów. Alerty trafiają na Telegram albo e-mail.
  • Kopie zapasowe — codzienne zrzuty bazy i katalogu z mediami na osobny magazyn, do tego snapshoty kontenerów przez Proxmox Backup Server.

Panel administracyjny zamykamy osobno: zmieniona nazwa katalogu, dostęp tylko z Waszych adresów IP lub przez VPN, 2FA tam, gdzie pozwala na to moduł.

Warstwy ochrony: od operatora do PHP

Ochrona przed DDoS działa na kilku poziomach i każdy łapie co innego.

Operator. OVH i Hetzner filtrują ataki wolumetryczne (UDP flood, SYN flood) we własnej sieci, zanim ruch dotrze do serwera. Jest to w cenie serwera i dla większości sklepów wystarcza na „ciężką artylerię".

Cloudflare — jeśli trzeba. Ukrywa prawdziwy adres serwera, cache’uje statykę bliżej klienta i dobrze radzi sobie z atakami na warstwie HTTP. Nie zawsze jest jednak potrzebny: jeśli klienci są w jednym kraju, a ataków nie było, dodatkowy pośrednik tylko utrudni diagnostykę i doda kolejny punkt awarii. Jeśli już stawiamy Cloudflare, zamykamy bezpośredni dostęp do serwera — inaczej ktoś go po prostu obejdzie. Wygodna opcja to Cloudflare Tunnel: serwer sam łączy się na zewnątrz i port 443 w ogóle nie jest wystawiony do internetu.

Rate limiting. Ataki na warstwie aplikacji celują zwykle w ciężkie strony: wyszukiwarkę, filtry katalogu, koszyk, logowanie. W Nginx ustawiamy dla nich osobne limity:

limit_req_zone $binary_remote_addr zone=search:10m rate=2r/s;
limit_req_zone $binary_remote_addr zone=login:10m  rate=5r/m;

location ^~ /admin-xxxxxx/ {         # katalog panelu
    allow 198.51.100.0/24;           # biuro lub VPN
    deny  all;
}
location ~* /(search|module/.+/search) {
    limit_req zone=search burst=10 nodelay;
}

WAF. ModSecurity z regułami OWASP CRS albo Coraza — blokuje SQL injection, XSS, próby odczytu plików konfiguracyjnych. To właśnie łata dziury w modułach, których jeszcze nie zdążyliście zaktualizować.

CrowdSec. Czyta logi proxy i SSH i rozpoznaje zachowania: skanowanie, zgadywanie haseł, znane CVE, agresywne crawlery. Blokadę nakłada bouncer na wejściu. Dodatkowo CrowdSec korzysta ze wspólnej listy atakujących adresów: IP, które skanowało już tysiące innych serwerów, dostaje bana przed pierwszym zapytaniem do Was.

Gdzie WAF przeszkadza i jak sobie z tym radzimy

Uczciwie: WAF „z pudełka" w sklepie coś zepsuje. Najczęściej cierpią moduły płatności i dostaw. Callback z bramki płatniczej przychodzi z JSON-em albo podpisem, który wygląda „podejrzanie" — i zamówienie wisi w statusie „oczekuje na płatność". Import produktów z CSV, edytor opisów z HTML, API marketplace’ów — to też kandydaci do fałszywych alarmów.

Dlatego nie włączamy blokowania od razu. Przez pierwszy tydzień WAF tylko loguje. Patrzymy, co łapie na prawdziwym ruchu, i dopisujemy wyjątki punktowo: dla konkretnego URL callbacku i konkretnej reguły, a nie „wyłącz WAF dla /module/". Dopiero potem włączamy blokowanie. Po każdej aktualizacji modułu płatności robimy testową transakcję na stagingu.

Kiedy to przesada: jeśli macie kilkadziesiąt zamówień miesięcznie i sklep na platformie SaaS w rodzaju Shopify, własny serwer da Wam głównie dodatkowe zmartwienia. Własna infrastruktura opłaca się, gdy sklep ma już skalę, własne moduły albo wymagania co do tego, gdzie leżą dane.

Co dostajecie

  • Sklep na serwerze dedykowanym z osobnymi kontenerami na web, bazę i staging.
  • Dostęp root i wszystkie hasła — u Was, nie tylko u nas.
  • Skonfigurowany WAF i CrowdSec z wyjątkami pod Wasze moduły płatności i dostaw.
  • TLS z automatycznym odnawianiem certyfikatów.
  • Codzienne kopie bazy i mediów na osobny magazyn oraz sprawdzone odtwarzanie.
  • Staging, na którym bezpiecznie testujecie aktualizacje.
  • Dashboardy Grafany i alerty o problemach.
  • Dokumentację: co gdzie stoi, jak aktualizować, jak odtworzyć sklep z kopii.

Jeśli Wasz sklep już nie mieści się w hostingu albo macie dość botów w panelu — napiszcie do nas. Opiszcie, na czym działa sklep teraz i jaki ma ruch, a zaproponujemy, jak go przenieść.