Filtrowanie ataków
Blokada znanych technik: SQL injection, cross-site scripting, przechodzenie po katalogach i próby dostępu do ukrytych paneli administracyjnych.
WAF nie zastąpi starannego programowania, ale daje czas: wykrytą lukę zamykamy dziś regułą, a w kodzie poprawiamy przy najbliższym wydaniu.
Blokada znanych technik: SQL injection, cross-site scripting, przechodzenie po katalogach i próby dostępu do ukrytych paneli administracyjnych.
Limit prób logowania do wp-admin, panelu PrestaShop i kont klientów oraz ochrona formularza resetu hasła przed nadużyciami.
Wyszukiwarki i porównywarki, z którymi współpracujesz, przechodzą. Scrapery cen, boty sprawdzające skradzione karty i automaty rezerwujące towar zostają za zaporą.
Podatność we wtyczce zamykamy regułą, zanim autor wyda poprawkę, co przy popularnych wtyczkach WooCommerce zdarza się częściej, niż by się chciało.
Powiadomienia z Przelewy24, PayU czy Tpay, webhooki kurierów i połączenia z systemami sprzedażowymi dostają precyzyjne wyjątki, żeby zamówienia nie utknęły w statusie „oczekuje na płatność”.
Co zostało zablokowane, skąd i według której reguły, w okresowym zestawieniu zrozumiałym także dla właściciela sklepu.
Najwięcej problemów przy WAF powstaje na samym początku, dlatego nigdy nie zaczynamy od trybu blokowania.
Platforma, formularze, konta klientów, metody płatności i integracje. Spisujemy wszystko, co legalnie łączy się ze sklepem.
WAF działa bez blokowania i zbiera obraz prawdziwego ruchu, najlepiej obejmujący także weekend i jedną kampanię promocyjną.
Usuwamy fałszywe alarmy. Na żywym sklepie zawsze jakieś są, najczęściej w wyszukiwarce produktów i w panelu administracyjnym.
Włączamy tryb ochrony, ustawiamy alerty i regularny przegląd zdarzeń, szczególnie przed Black Friday i okresem świątecznym.
Najgorszy moment na pierwsze uruchomienie WAF to tydzień przed dużą promocją. Ruch jest wtedy nietypowy, a każdy fałszywy alarm oznacza porzucony koszyk. Zapora wdrożona z wyprzedzeniem zdąży się nauczyć sklepu i w szczycie sprzedaży zatrzymuje boty, zamiast klientów.
Zwykle nie. Wiele usług WAF w chmurze działa razem z CDN, który serwuje obrazki i skrypty z serwerów bliżej klienta, więc strona może ładować się nawet szybciej. Opóźnienie samej inspekcji ruchu jest dla kupującego zwykle niezauważalne.
Na platformach abonamentowych, takich jak Shoper czy IdoSell, infrastrukturą zarządza dostawca, a zakres jego ochrony opisują warunki usługi. Własny WAF zwykle nie jest wtedy potrzebny. Zajmujemy się wtedy tym, co zostaje po Twojej stronie: kontami administratorów, MFA i dostępami aplikacji zewnętrznych.
Po trybie uczenia i strojeniu reguł, których długość zależy od ruchu w sklepie. Pojedyncze reguły dla oczywistych ataków, na przykład na znaną lukę we wtyczce, możemy włączyć od razu.
Klient widzi stronę z identyfikatorem zdarzenia, a my sprawdzamy w logach, która reguła zadziałała, i ją korygujemy. Po okresie strojenia takie przypadki są rzadkie, a raport pokazuje, czy nie narastają.
Napisz, na jakiej platformie działa sklep lub portal i jakie ma integracje. Zaproponujemy rodzaj WAF i plan wdrożenia.
Zapytanie dotarło do nas
Odpowiedź dostaniesz w ciągu dnia roboczego, a jeśli zgłaszasz awarię, która zatrzymuje pracę, zajmiemy się nią w pierwszej kolejności.
Nie mamy tego miasta na liście. Sprawdź pisownię albo wybierz najbliższe duże miasto - pracujemy zdalnie, więc nie wpływa to na zakres obsługi.