Co GridXGate robi z żądaniem
Od nagłówka HTTP do decyzji o przepuszczeniu — bez wychodzenia poza serwer, na którym stoi witryna.
Pięć kontroli, jedna decyzja
Żądanie przechodzi przez kolejne warstwy. Każda może je odrzucić albo dołożyć punkty do oceny anomalii — blokada zapada dopiero na końcu, na podstawie sumy.
Kontrola protokołu
Zniekształcone żądania HTTP, przemycone nagłówki, sprzeczne długości treści, metody, których aplikacja nigdy nie używa. Kontrola jest tania, a odsiewa spory ruch automatów.
Tempo i powtarzalność
Limity na próby logowania i wywołania API liczone per adres IP i per vhost. Tu wypada większość brute-force na wp-login.php i xmlrpc.php, zanim dotrze do PHP.
Reguły OWASP Core Rule Set
Rozpoznawanie SQL injection, XSS, wstrzyknięcia poleceń i przejścia katalogu. Reguły pracują w modelu punktacji anomalii, więc pojedyncze podejrzane dopasowanie nie odrzuca żądania.
Reguły gridX pod hosting współdzielony
Warstwa pisana pod to, co realnie stoi na Waszych serwerach: WordPress, Joomla, PrestaShop i ich wtyczki. Obejmuje ścieżki uploadu, typowe backdoory i żądania sięgające po pliki konfiguracyjne.
Decyzja i zapis
Przepuszczenie albo odpowiedź 403. Każde odrzucenie trafia do dziennika zdarzeń z identyfikatorem reguły, adresem IP, vhostem i pełnym żądaniem — tak, żeby dało się je ocenić po fakcie.
Trzy tryby, ustawiane niezależnie dla każdego vhosta
Zmiana trybu nie wymaga restartu serwera WWW ani przerwy w działaniu witryn.
| Tryb | Co robi z ruchem | Kiedy go używać |
|---|---|---|
| Wykrywanie | Nic nie blokuje. Zapisuje, co odrzuciłby, gdyby był włączony. | Pierwsze dni po instalacji i po każdej większej zmianie zestawu reguł. |
| Blokowanie | Odrzuca żądania przekraczające próg anomalii i zapisuje zdarzenie. | Docelowy tryb pracy, włączany po przeglądzie fałszywych alarmów. |
| Wyłączony | Żądania omijają moduł. Zero narzutu. | Vhosty, na których ochrona świadomie nie jest potrzebna. |
Fałszywe alarmy to największy koszt WAF-a
Nie to, czego WAF nie zablokuje, tylko to, co zablokuje niepotrzebnie. Zablokowany checkout w sklepie klienta jest droższy niż przepuszczony skaner.
- Najpierw obserwacja, potem egzekwowanie Tryb wykrywania pokazuje pełną listę tego, co zostałoby odrzucone, zanim cokolwiek zostanie odrzucone naprawdę.
- Wyjątek zawsze jest wąski Wyłączacie konkretną regułę na konkretnym vhoście, a nie całą kategorię na całym serwerze.
- Zdarzenie zawiera całe żądanie Widzicie, co dokładnie dopasowało regułę, więc ocena „atak czy nietypowy formularz” zajmuje sekundy, nie godzinę.
- Powrót jest jedną komendą Jeśli po włączeniu blokowania coś pójdzie nie tak, vhost wraca do trybu wykrywania natychmiast.
Na czym działa
| Serwer WWW | Sposób instalacji | Restart usługi |
|---|---|---|
| nginx | moduł dynamiczny | niepotrzebny — wystarczy reload |
| Apache | moduł | niepotrzebny — wystarczy graceful |
| LiteSpeed / OpenLiteSpeed | moduł | niepotrzebny — wystarczy reload |
Integrację z panelem hostingowym — włączanie ochrony per domena z poziomu DirectAdmin, cPanel czy Plesk — ustalamy przy wdrożeniu, bo zależy ona od tego, jak wygląda Wasz panel i proces zakładania kont. Napiszcie, czego używacie, a odpowiemy konkretnie.
Porozmawiajmy o Waszej infrastrukturze
Napiszcie, na czym stoją Wasze serwery i ile witryn obsługują. Odpowiemy, co GridXGate zmieni u Was konkretnie — i ile to kosztuje.