Monitoring Magento — co dokładnie sprawdzamy

Sklep na Magento może odpowiadać kodem 200 i wyglądać normalnie, a jednocześnie wysyłać dane kart klientów na obcy serwer. Dlatego dla Magento 1 i 2 MonitorWWW.com robi więcej niż test dostępności: rozpoznaje platformę automatycznie i sprawdza to, co w tych sklepach psuje się i bywa atakowane najczęściej.

Skimmery kart i strona koszyka

• Podejrzany kod w koszyku — szukamy wzorców typowych dla skimmerów (Magecart): skryptów aktywowanych tylko na stronie płatności, wykonywania zakodowanego kodu, odczytu pól karty połączonego z wysyłką danych, połączeń WebSocket do obcych domen i skryptów udających obrazy.
• Zewnętrzne domeny skryptów — zapamiętujemy listę domen, z których koszyk ładuje JavaScript, i alarmujemy, gdy pojawi się nowa.
• Działanie koszyka i logowania — czy /checkout/cart/ i /customer/account/login/ odpowiadają i nie pokazują strony błędu Magento.

Skan obejmuje kod HTML strony koszyka. To wykrywanie heurystyczne: wychwytuje typowe wstrzyknięcia, ale nie zastąpi audytu plików i bazy po włamaniu.

Bezpieczeństwo instalacji

• Pliki konfiguracyjne — publicznie dostępny app/etc/env.php (Magento 2) lub app/etc/local.xml (Magento 1).
• Zrzuty bazy — dump.sql i backup.sql w katalogu głównym.
• Instalator i Magento Connect — dostępne /setup/ i /downloader/.
• Logi — pobieralne var/log/system.log i exception.log.
• Listowanie katalogów — var/backups, var/report, var/export i media.
• phpinfo — pozostawione pliki phpinfo.php / info.php.
• composer.json — publiczny plik zdradza dokładną wersję i listę modułów.
• Document root — czy serwer wskazuje na katalog /pub, czy na katalog główny Magento.
• Panel administratora — czy działa pod domyślnym adresem /admin.
• REST i GraphQL — dostęp do katalogu produktów bez tokenu i otwarta introspekcja schematu.

Wersja i koniec wsparcia

• Wersja i edycja — odczytywane z /magento_version lub composer.json, jeśli sklep je udostępnia.
• Koniec wsparcia — ostrzeżenie dla Magento 1 i gałęzi 2.0–2.3, które nie dostają już poprawek bezpieczeństwa.
• Nowsze wydanie — gdy znamy dokładną wersję, porównujemy ją z najnowszym wydaniem Magento Open Source.

Jak często i dlaczego nie wszystko naraz

Dostępność sklepu sprawdzamy co kilka minut. Sondy bezpieczeństwa są rozłożone na całą dobę: 22 zapytania dziennie, najwyżej dwa naraz, mniej więcej co 100 minut i w nieregularnych odstępach. Seria zapytań o nietypowe pliki w jednej sekundzie wygląda dla WAF-a jak skan i kończy się blokadą adresu IP. Na nowej stronie pierwszy pełny cykl przebiega szybciej, w około cztery godziny.

Wszystko sprawdzamy z zewnątrz — bez modułu w sklepie, bez dostępu do panelu i serwera.

Alerty

Poza alertem o awarii wysyłamy osobny alert bezpieczeństwa (e-mail, Telegram, webhook), gdy wykryjemy podejrzany kod w koszyku, nową domenę skryptów, publiczny plik konfiguracyjny albo zrzut bazy. Pozostałe znaleziska są w panelu razem z instrukcją naprawy.

Co sprawdzamy na każdej stronie, niezależnie od platformy

• Dostępność i czas odpowiedzi — kod HTTP, czas ładowania, przekierowania, tryb konserwacji.
• Certyfikat SSL i domena — ważność certyfikatu i termin wygaśnięcia domeny, z alertem przed terminem.
• DNS — rekordy SPF, DMARC, MX i CAA.
• Nagłówki bezpieczeństwa — HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy oraz flagi ciasteczek.
• Pliki, których nie powinno być widać — .env, .git, phpMyAdmin, kopie zapasowe, listowanie katalogów.
• Malware i błędy PHP — podejrzany kod i komunikaty błędów w treści strony.
• Czarne listy — czy domena trafiła na listę stron niebezpiecznych.
• Zmiany treści — opcjonalne słowo kluczowe, które musi być na stronie.