Monitoring WHMCS — co dokładnie sprawdzamy

WHMCS to system, przez który przechodzą zamówienia, faktury i dane klientów firmy hostingowej. Gdy koszyk przestaje działać albo w katalogu publicznym zostaje kopia pliku konfiguracyjnego, zwykły monitoring „czy strona odpowiada" tego nie zauważy. MonitorWWW.com rozpoznaje WHMCS automatycznie po adresie strefy klienta i uruchamia zestaw sprawdzeń przygotowany dla tego systemu.

Działanie kluczowych stron

• Koszyk (cart.php), strefa klienta (clientarea.php) i zgłoszenia (submitticket.php) — sprawdzamy nie tylko kod odpowiedzi, ale też to, czy zamiast strony nie pojawia się komunikat błędu WHMCS.
• Stan aplikacji — tryb konserwacji („Down for Maintenance"), błąd krytyczny i problem z licencją.

Bezpieczeństwo instalacji

• Folder instalatora — czy /install/ został usunięty po instalacji lub aktualizacji.
• Kopie configuration.php — pliki .bak, .old, .save i ~, które serwer oddałby jako zwykły tekst razem z hasłem do bazy.
• Archiwa i zrzuty bazy — whmcs.zip, whmcs.sql, backup.zip, backup.sql w katalogu głównym.
• Skrypty cron — czy /crons/cron.php można wywołać z przeglądarki.
• Katalog /vendor/ — czy biblioteki są dostępne z zewnątrz.
• Pliki klientów — listowanie katalogów attachments, downloads, templates_c i modules/gateways/callback.
• Logi aplikacji — czy plik z /storage/logs/ jest pobieralny.
• Panel administratora — czy działa pod domyślnym adresem /admin/.
• CAPTCHA — czy formularz rejestracji jest chroniony przed botami.

Każde znalezisko ma w panelu gotową instrukcję naprawy — konkretne polecenia i ustawienia WHMCS, nie ogólne porady.

Jak często i dlaczego nie wszystko naraz

Dostępność strony sprawdzamy co kilka minut. Sondy bezpieczeństwa są natomiast rozłożone na całą dobę: 22 zapytania dziennie, najwyżej dwa naraz, mniej więcej co 100 minut i w nieregularnych odstępach. Kilkanaście zapytań o nietypowe pliki w jednej sekundzie wygląda dla firewalla jak skan i kończy się blokadą adresu IP — a wtedy monitoring pokazuje awarię, której nie ma. Na nowej stronie pierwszy pełny cykl przebiega szybciej, w około cztery godziny.

Wszystkie sprawdzenia robimy z zewnątrz, tak jak widzi stronę odwiedzający. Nie instalujemy modułu, nie logujemy się do panelu i nie potrzebujemy dostępu do serwera.

Alerty

O awarii dowiesz się e-mailem, SMS-em lub przez Telegram. Osobny alert bezpieczeństwa wysyłamy, gdy pojawi się dostępny publicznie instalator, kopia configuration.php albo zrzut bazy danych. Pozostałe znaleziska są widoczne w panelu i wliczają się do oceny bezpieczeństwa strony.

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.