Customer Extra Info i blokady IP: jak chronić sklep przed problematycznymi odwiedzającymi

Większość odwiedzających jest dokładnie tym, za kogo się podaje. Ale każdy sklep prędzej czy później trafia na wyjątek: „klienta”, który składa dziesięć zamówień i nigdy za nie nie płaci, osobę kwestionującą płatność w banku już po doręczeniu paczki, użytkownika rejestrującego się za każdym razem na nowy jednorazowy e-mail, gdy poprzednie konto zostało anulowane, albo konkurenta, który po cichu loguje się z tego samego biura, żeby śledzić Twoje ceny. Back office PrestaShop pokazuje z tego prawie nic. Widzisz zamówienie, imię i nazwisko, adres e-mail — ale nie widzisz urządzenia, sieci ani historii stojącej za tym ruchem. Ten poradnik pokazuje, jak zamknąć tę lukę na dwa sposoby: zbierać wystarczająco dużo dodatkowych informacji o odwiedzającym, aby rozpoznać problematycznego użytkownika, oraz mieć pod ręką blokadę IP, żeby po jego rozpoznaniu móc zamknąć mu drzwi bez programisty i bez wyłączania całego sklepu.

Ostatnia aktualizacja: czerwiec 2026.

Co PrestaShop mówi Ci o odwiedzającym — i co ukrywa

Domyślnie PrestaShop zapisuje imię i nazwisko klienta, adres e-mail, opcjonalną datę urodzenia oraz adresy podane podczas finalizacji zakupu. Rejestruje połączenia w sekcji Statystyki → Odwiedzający online i w tabeli connections, a także zapisuje adres IP przy sesjach gości. Nie robi natomiast jednej rzeczy: nie łączy tych kropek za Ciebie. Nie ma ekranu, który powie: „to konto logowało się w tym tygodniu z sześciu różnych adresów IP w trzech krajach” albo „te cztery konta mają ten sam adres IP i ten sam odcisk przeglądarki”. Surowe dane istnieją we fragmentach; wzorzec, który pozwoliłby wcześnie wykryć oszustwo, nie pojawia się nigdzie tam, gdzie faktycznie byś go szukał.

Ta luka ma znaczenie, bo nadużycie prawie zawsze jest wzorcem, a nie pojedynczym zdarzeniem. Jeden zwrócony produkt to klient. Dwadzieścia zwrotów z kont, które wszystkie prowadzą do jednego adresu IP, to problem, który chcesz zobaczyć trzeciego dnia, a nie po trzecim piśmie o chargebacku od operatora płatności. Pierwszym zadaniem jest więc widoczność — wzbogacenie wiedzy o każdym odwiedzającym tak, aby wzorzec stał się czytelny.

„Dodatkowe informacje”, które naprawdę wskazują problematycznego odwiedzającego

„Dodatkowe informacje o kliencie” nie muszą oznaczać dłuższego formularza rejestracji (dłuższe formularze konwertują gorzej — to realny koszt). Informacje, które pomagają wyłapywać nadużycia, to techniczne metadane już przenoszone przez żądanie, których po prostu nie zapisujesz. Nasz moduł Customer Extra Info & IP Ban zbiera je pasywnie, przy każdej wizycie, i przypina do rekordu klienta, aby można je było odczytać na stronie klienta w panelu administracyjnym:

• Adres IP i kraj — prawdziwe, a nie adres Twojego proxy. Za Cloudflare albo load balancerem proste sprawdzanie IP w PrestaShop często zapisuje adres IP CDN. Moduł odczytuje CF-Connecting-IP, X-Real-IP i X-Forwarded-For (walidując każdy z nich), więc blokowany adres należy do odwiedzającego, a nie do Twojej warstwy brzegowej.
• Kraj — ustalany z nagłówka Cloudflare CF-IPCOUNTRY, jeśli jest dostępny, albo z bazy GeoIP PrestaShop jako rozwiązanie zapasowe. Nagła seria rejestracji z kraju, do którego nie wysyłasz zamówień, sama w sobie jest sygnałem.
• Przeglądarka, system operacyjny i typ urządzenia — odczytywane z user agenta. Pięciu „różnych klientów” korzystających z tej samej nietypowej wersji przeglądarki to niekoniecznie pięciu klientów.
• Unikalne adresy IP na klienta, z pierwszym i ostatnim wystąpieniem oraz liczbą wizyt — to wykrywacz oszustw na wielu kontach. Jedno konto przeskakujące między tuzinem adresów IP albo jeden adres IP występujący pod tuzinem nazw kont od razu rzucają się w oczy w tym widoku.

Zbieranie danych jest celowo dyskretne: moduł deduplikuje wpisy, więc zapisuje tylko jeden rekord na kombinację IP i klienta na godzinę, zamiast obciążać bazę danych przy każdym wczytaniu strony. Każdy punkt danych (user agent, system operacyjny, przeglądarka, rozdzielczość ekranu) ma niezależny przełącznik włącz/wyłącz, dzięki czemu zbierasz dokładnie to, czego potrzebujesz, i nic, czego wolisz nie przechowywać. Co to daje w praktyce? Gdy pojawia się spór, otwierasz profil klienta i widzisz cały jego ślad — każdy adres IP, każdy kraj, każdą sesję — zamiast zgadywać. To różnica między działaniem na podstawie dowodów a nerwową reakcją w kryzysie.

Lista klientów pokazuje każdego klienta wraz z imieniem, e-mailem, statusem oraz datą rejestracji i ostatniej wizyty.

Jeśli podczas dochodzenia musisz przejrzeć surowy ślad, moduł zapisuje go w ps_mprceiipban_info. Zmień prefiks, jeśli Twój sklep nie używa ps_:

SELECT id_customer, ip_address, country_code, browser_name, device_type, date_add
FROM ps_mprceiipban_info
WHERE id_customer = 123
ORDER BY date_add DESC
LIMIT 50;

Blokowanie IP w PrestaShop: precyzyjniej niż „zablokuj adres”

Rdzeń PrestaShop nie ma prawdziwego narzędzia do blokowania odwiedzających — lista dozwolonych adresów IP w trybie konserwacji pod Parametry sklepu → Ogólne → Przerwa techniczna odcina wszystkich poza wskazanymi adresami IP, czyli robi odwrotność tego, czego potrzebujesz przy jednym złym aktorze. Dlatego blokowanie to dokładnie ten typ funkcji, którą dodaje moduł. Naiwna wersja blokady IP — jeden adres, zablokowany wszędzie — jest też najmniej użyteczna, bo jest jednocześnie zbyt toporna i zbyt łatwa do obejścia. Blokada, która naprawdę zasługuje na swoje miejsce, daje kontrolę nad tym, który adres blokujesz, gdzie blokada działa i jak długo.

Dopasuj więcej niż pojedynczy adres

Nieuczciwi użytkownicy rzadko siedzą na jednym statycznym IP. Moduł dopasowuje blokadę do:

• Dokładnego adresu IP — najprostszy przypadek.
• Symbolu wieloznacznego, np. 203.0.113.* — gdy ktoś wraca z sąsiednich adresów w tym samym bloku.
• Zakresu CIDR, np. 203.0.113.0/24 — precyzyjny sposób objęcia całej podsieci.
• Zakresu adresów, np. 203.0.113.10-203.0.113.40 — dla dowolnego przedziału.
• Kodu kraju — aby zablokować całe źródło ruchu, którego nie obsługujesz, oceniane według kraju GeoIP opisanego wyżej.
• Wzorca user agenta — zwykłe dopasowanie tekstowe typu „zawiera” albo pełne wyrażenie regularne, gdy nadużywającego można rozpoznać po ciągu klienta, a nie po adresie.

Wybierz, gdzie obowiązuje blokada

To jest moment, w którym młot zamienia się w skalpel. Każda blokada ma swój zakres:

Ten podział ma znaczenie ze względu na realia dynamicznych i współdzielonych adresów IP: biura, uczelnie i operatorzy komórkowi ukrywają wielu prawdziwych ludzi za jednym publicznym adresem. Pełna blokada współdzielonego IP może po cichu kosztować Cię prawdziwe zamówienia. Wąska blokada finalizacji zakupu albo uwierzytelniania ogranicza szkodę dokładnie do działania, które jest nadużywane. A ponieważ prawdziwy adres IP odwiedzającego jest poprawnie ustalany za CDN, blokujesz właściwą osobę, a nie przypadkowego sąsiada.

Ustaw wygaśnięcie blokady — i nigdy nie odetnij samego siebie

Dwie dodatkowe kontrolki pilnują, żeby blokady same nie stały się problemem. Każda blokada może być tymczasowa, z datą wygaśnięcia, po której zostaje automatycznie dezaktywowana — przydatne przy blokadzie „na ostudzenie”, gdy stały ban byłby przesadą, i wygodne z perspektywy retencji danych (więcej o RODO niżej). A biała lista zawsze wygrywa: każdy adres IP lub CIDR wpisany na tę listę nigdy nie może zostać zablokowany, także przez regułę automatyczną. Najpierw dodaj tam własne biuro, połączenie swojego programisty i usługi monitorujące, aby szeroka blokada ustawiona w złości o 2:00 w nocy nie mogła przypadkiem odciąć Ciebie.

Każdy wiersz blokady pokazuje obok siebie zakres, adres IP i aktywny status.

Zaufane adresy znajdują się na białej liście, a oznaczone zamówienia pokazują wynik ryzyka i powód.

Zatrzymanie automatycznych nadużyć, zanim potrzebna będzie blokada

Duża część ruchu od „problematycznych odwiedzających” to skrypt, nie człowiek — a najczystszą obroną jest automatyczne podniesienie kosztu ataku. Moduł śledzi nieudane próby logowania według adresu IP i może automatycznie zablokować adres, który przekroczy ustawiony próg (określoną liczbę niepowodzeń w wybranym oknie czasowym), stosując tymczasową blokadę o zakresie uwierzytelniania, a nie blokadę stałą. To celowana odpowiedź na credential stuffing: atakujący metodą brute force traci możliwość logowania na godzinę po, powiedzmy, dziesięciu błędnych próbach, a klient, który dwa razy źle wpisał hasło, pozostaje nietknięty.

Automatyczne blokowanie po nieudanych logowaniach to jedna warstwa. Szersze zadanie odróżniania dobrych botów od złych — scraperów, skanerów podatności, kliknięć wyłudzających budżet reklamowy — to osobna dyscyplina; omawiamy ją w artykule Visitor Control: blokowanie złych botów i niechcianego ruchu. A pojedynczym krokiem o największej wartości w zatrzymywaniu fałszywych rejestracji i spamu z formularzy u źródła jest wyzwanie w samym formularzu — zobacz reCAPTCHA dla PrestaShop. Gdy zły aktor zalewa adresy URL wyszukiwania fasetowego ruchem prowadzącym do odmowy usługi, pierwszą linią obrony jest CDN, a nie lista blokad w PrestaShop: jak przetrwać flood ?q=.

Gdzie blokowanie IP pasuje do szerszego utwardzania sklepu

Bądź ze sobą szczery co do tego, co blokada IP może zrobić, a czego nie. Świetnie działa na przypadkowych i niedbałych sprawców — większość nadużywających, którzy nie są na tyle zaawansowani, żeby bawić się w VPN. Nie jest natomiast perymetrem chroniącym przed zdeterminowanym atakującym, który może zmieniać adresy szybciej, niż zdążysz je blokować. Traktuj ją jako jedno dobrze wymierzone narzędzie, nie jako całą strategię bezpieczeństwa. Strategia powstaje z zestawu działań:

• Pełny przegląd — uprawnienia plików, folder administracyjny, nagłówki, aktualizacje — znajdziesz w checkliście utwardzania bezpieczeństwa PrestaShop, a łagodniejsze wprowadzenie w prostym przewodniku dla właścicieli sklepów.
• Zabezpieczenie samego back office — konta administratorów są dla atakującego prawdziwą nagrodą — opisujemy w artykule o uwierzytelnianiu dwuskładnikowym, politykach haseł i bezpieczeństwie administratorów.
• Jeśli utknąłeś na wersji, której nie możesz zaktualizować, zaawansowane utwardzanie z wirtualnym łataniem jest realistyczną ścieżką.
• A jeśli najgorsze już się stało, nie improwizuj — postępuj według poradnika reakcja na naruszenie danych: co zrobić, gdy Twój sklep zostanie zhakowany.

Strona prawna i ewidencyjna

Blokowanie klienta w UE jest Twoim prawem — możesz odmówić świadczenia usługi — ale dane, które przechowujesz, aby to uzasadnić, podlegają RODO. Wynikają z tego dwie praktyczne konsekwencje. Po pierwsze, zbieraj dane proporcjonalnie: właśnie dlatego każde pole metadanych w module ma osobny przełącznik i dlatego stare rekordy mogą być czyszczone według harmonogramu, żeby nie gromadzić odcisków urządzeń, których nigdy nie używasz. Po drugie, zapisuj jasny powód każdej blokady (moduł przechowuje powód i pracownika, który ją ustawił), aby w razie eskalacji przez zablokowanego klienta do banku albo organu ochrony konsumentów pokazać dlaczego ograniczenie zostało zastosowane, a nie tylko że zostało zastosowane. Jeśli taki klient później złoży wniosek o usunięcie danych na podstawie art. 17, zasadniczo go realizujesz — choć możesz zachować to, co jest rzeczywiście niezbędne do dochodzenia roszczeń lub spełnienia obowiązków prawnych. Twój regulamin powinien już jasno mówić, że konta mogą być zamykane za naruszenia zasad; to właśnie ten zapis daje blokadzie oparcie.

Najczęściej zadawane pytania

Czy blokada IP może przypadkiem zablokować prawdziwych klientów za Cloudflare?

Może, jeśli zablokujesz niewłaściwy adres — i na tym właśnie polega pułapka za CDN. Proste wykrywanie IP w PrestaShop często zapisuje adres IP Cloudflare albo load balancera zamiast adresu odwiedzającego, więc „blokada” może trafić w Twoją własną warstwę brzegową i odciąć wszystkich. Moduł odczytuje CF-Connecting-IP, X-Real-IP i X-Forwarded-For (walidując każdy z nich), więc blokowany adres należy do rzeczywistego odwiedzającego, a nie do Twojego CDN. Najpierw ustal prawdziwy adres IP; dopiero wtedy blokada jest bezpieczna.

Dlaczego miałbym używać blokady „finalizacji zakupu” albo „uwierzytelniania” zamiast pełnej blokady?

Bo biura, uczelnie i operatorzy komórkowi umieszczają wielu prawdziwych ludzi za jednym publicznym adresem IP, więc pełna blokada współdzielonego adresu może po cichu kosztować Cię prawdziwe zamówienia. Blokada o zakresie finalizacji zakupu pozwala notorycznemu niepłacącemu klientowi przeglądać sklep, ale nie składać zamówień; blokada o zakresie uwierzytelniania zatrzymuje tworzenie fałszywych kont i credential stuffing z jednego źródła bez blokowania uczciwych gości korzystających z tego samego IP. Dopasuj zakres do nadużywanego działania — pełne blokady są dla jawnych nadużyć, których chcesz całkowicie się pozbyć.

Jak zatrzymać skrypty credential stuffing bez blokowania prawdziwych klientów, którzy pomylą się przy wpisywaniu hasła?

Użyj automatycznej blokady po nieudanych logowaniach z rozsądnym progiem. Moduł liczy nieudane próby logowania według adresu IP i może automatycznie nałożyć tymczasową blokadę o zakresie uwierzytelniania, gdy adres przekroczy, na przykład, dziesięć błędnych prób w określonym oknie czasowym — dzięki temu atakujący metodą brute force traci możliwość logowania na godzinę, a klient, który dwa razy źle wpisał hasło, pozostaje nietknięty. To celowana odpowiedź na skrypty, a nie ogólna blokada. Spam z formularzy i fałszywe rejestracje lepiej zatrzymywać bezpośrednio w formularzu za pomocą reCAPTCHA.

Jak uniknąć odcięcia samego siebie szeroką blokadą?

Najpierw zbuduj białą listę. Biała lista zawsze wygrywa — każdy adres IP lub CIDR, który tam wpiszesz, nigdy nie może zostać zablokowany, także przez regułę automatyczną — więc dodaj własne biuro, połączenie swojego programisty i usługi monitorujące, zanim utworzysz jakąkolwiek szeroką blokadę kraju albo zakresu CIDR. Dzięki temu szeroka blokada ustawiona w złości o 2:00 w nocy nie odetnie Cię przypadkiem od sklepu. Połącz to z tymczasowymi blokadami (znacznik czasu wygaśnięcia automatycznie je dezaktywuje) przy blokadach „na ostudzenie”, gdy stały ban byłby przesadą.

Czy blokowanie klienta i przechowywanie jego adresów IP jest problemem w świetle RODO?

Odmowa świadczenia usługi jest Twoim prawem, ale dane, które przechowujesz, aby ją uzasadnić, podlegają RODO, więc zbieraj je proporcjonalnie. Każde pole metadanych ma osobny przełącznik, a stare rekordy mogą być czyszczone według harmonogramu, żeby nie gromadzić odcisków urządzeń, których nigdy nie używasz. Zapisuj jasny powód każdej blokady (moduł przechowuje powód i pracownika, który ją ustawił), aby móc pokazać dlaczego ograniczenie zostało zastosowane, jeśli klient eskaluje sprawę do banku albo organu ochrony konsumentów. Realizuj wnioski o usunięcie danych z art. 17, zachowując tylko to, co jest rzeczywiście niezbędne do roszczeń prawnych — i upewnij się, że regulamin jasno mówi o możliwości zamknięcia konta za naruszenie zasad.

Wyważone drzwi, nie forteca

Sens tego wszystkiego nie polega na witaniu kupujących podejrzliwością — chodzi o prowadzenie przyjaznego sklepu, który po cichu zachowuje dowody. Większość sklepów rzadko musi kogokolwiek blokować. Ale czas na zbudowanie tej możliwości jest przed momentem, w którym jej potrzebujesz, a nie w środku kryzysu, gdy grupa oszustów jest w trakcie działania, a Ty pod presją uczysz się back office. Włącz zbieranie metadanych odwiedzających, żeby wzorce były widoczne. Najpierw dodaj własne połączenia do białej listy. Trzymaj zakresowe, wygasające blokady IP jako narzędzie, po które możesz sięgnąć w kilka sekund — blokadę finalizacji zakupu dla niepłacącego, blokadę uwierzytelniania dla osoby masowo zakładającej konta, pełną blokadę dla naprawdę agresywnego użytkownika — i pozwól automatycznej blokadzie samodzielnie obsługiwać skrypty brute force. Właśnie po to powstał Customer Extra Info & IP Ban: daje widoczność potrzebną do rozpoznania problematycznego odwiedzającego oraz precyzyjny, odwracalny sposób na jego zatrzymanie — wszystko z poziomu back office, bez udziału programisty.