| Nazwa wtyczki | N/D |
|---|---|
| Rodzaj podatności | Kontrola dostępu |
| Numer CVE | Żadne |
| Pilność | Informacyjny |
| Data publikacji CVE | 2026-03-14 |
| Adres URL źródła | Żadne |
Kiedy brakuje strony raportu o podatności: jak weryfikować, chronić i odzyskiwać witryny WordPress
Ostatnio mogłeś kliknąć link do raportu o podatności WordPress i zostać powitanym prostą stroną “404 Nie znaleziono” zamiast oczekiwanego komunikatu. Ta brakująca strona nie sprawia, że zagrożenie znika. Jako zespół ds. bezpieczeństwa WordPress pracujący nad zarządzanym zaporą aplikacji internetowej i usługą ochrony, widzimy dwa powszechne scenariusze, gdy adres URL raportu o podatności zwraca 404:
- Komunikat został usunięty, przeniesiony lub umieszczony za autoryzacją (celowo lub przypadkowo).
- Komunikat nigdy nie istniał publicznie — prywatne ujawnienie lub usunięta strona — a nadal musisz traktować ryzyko proaktywnie.
Ten artykuł jest praktycznym, opartym na doświadczeniu przewodnikiem po tym, co robić dalej: jak zweryfikować, czy twoje witryny są dotknięte, natychmiastowe kroki w celu ograniczenia, dokładne dochodzenie i usuwanie, oraz długoterminowe strategie zmniejszania narażenia. Wyjaśnię również, jak warstwy ochrony WP-Firewall odpowiadają każdemu etapowi obsługi incydentów.
Notatka: Podany przez Ciebie adres URL zwrócił błąd “404 Nie znaleziono”. Ponieważ raport nie jest dostępny, przeprowadzimy przez to, jak postępować, gdy komunikat jest niedostępny i jak upewnić się, że twoje instalacje WordPress pozostają chronione.
Streszczenie wykonawcze (szybka lista kontrolna)
Jeśli odkryjesz, że adres URL komunikatu o podatności jest brakujący, ale może dotyczyć twojej witryny:
- Traktuj to poważnie — zakładaj, że wiarygodny raport istnieje, dopóki nie udowodniono inaczej.
- Sporządź inwentaryzację swoich witryn WordPress i wersji (rdzeń, motywy, wtyczki).
- Sprawdź notatki o wydaniach i dzienniki zmian w poszukiwaniu ostatnich poprawek.
- Przeprowadź ukierunkowane skanowanie i audyt integralności plików i bazy danych.
- Zastosuj natychmiastowe wirtualne/tymczasowe środki zaradcze (zasady WAF, blokowanie ścieżek, limity szybkości).
- Jeśli dostępna jest poprawka, zaplanuj natychmiastowe aktualizacje; jeśli nie, użyj wirtualnego łatania + izolacji.
- Monitoruj dzienniki, źródła reputacyjne i wskaźniki aktywnych exploitów przez 72–96 godzin.
- Przeprowadź przegląd po incydencie i wzmocnij procesy łatania.
Czytaj dalej, aby poznać pełny, praktyczny proces oraz zalecane zasady i polecenia.
Dlaczego brakujący komunikat nadal ma znaczenie
404 na stronie komunikatu nie oznacza, że podatność nie jest rzeczywista. Możliwe powody brakującej strony to:
- Autor komunikatu lub platforma usunęli stronę, aby skoordynować działania z dostawcą lub aby uniknąć publicznego wykorzystania przed wydaniem poprawki.
- Raport został przeniesiony za logowanie dla treści tylko dla subskrybentów.
- Ostrzeżenie nigdy nie zostało opublikowane publicznie (ujawnienie prywatne).
- Błąd przejściowy, problem z pamięcią podręczną lub nieaktualny link.
Biorąc pod uwagę te możliwości, musisz założyć pewne ryzyko, dopóki nie potwierdzisz, że wersje twojego oprogramowania nie są dotknięte lub że istnieje łatka i została zastosowana.
Krok 1 — Szybka inwentaryzacja: wiedz, co masz
Zanim ocenisz narażenie, stwórz jasną inwentaryzację.
- Wypisz wszystkie witryny WordPress, którymi zarządzasz, oraz ich publiczne/wewnętrzne adresy URL
- Dla każdej witryny zanotuj:
- Wersja rdzenia WordPress: wp core version (lub odczytaj z /wp-includes/version.php).
- Wtyczki i wersje: wp plugin list –format=json
- Motywy i wersje: wp theme list –format=json
- Wersja PHP i typ serwera WWW (Apache, Nginx, LiteSpeed).
- Jakikolwiek kod niestandardowy (mu-wtyczki, niestandardowe motywy, dostosowane punkty końcowe).
Przydatne polecenia WP-CLI:
# Informacje o rdzeniu WordPress, wtyczkach, motywach
Eksportuj te dane do pliku CSV lub arkusza inwentaryzacyjnego. Jeśli używasz narzędzia do zarządzania, pobierz dane z niego. Znajomość dokładnych wersji jest niezbędna do porównania z opublikowanymi lukami.
Krok 2 — Potwierdź, czy istnieje oficjalna łatka
Nawet jeśli ostrzeżenie nie jest dostępne, sprawdź autorytatywne kanały w poszukiwaniu łatek:
- Sprawdź powiadomienia o aktualizacjach na pulpicie WordPress dla każdej witryny.
- Przejrzyj strony deweloperów wtyczek i motywów oraz dzienniki zmian.
- Przeszukaj oficjalne publiczne bazy danych o podatnościach (CVE) oraz notatki wydawców.
- Jeśli utrzymujesz kontakty z wydawcami, zapytaj ich bezpośrednio.
Jeśli istnieje łatka, priorytetowo traktuj testowanie i wdrażanie. Jeśli nie ma publicznej łatki, przejdź do ograniczenia i wirtualnego łatania.
Krok 3 — Szybkie ograniczenie: zapobiegaj eksploatacji teraz
Jeśli podejrzewasz eksploatację lub czekasz na łatkę, działaj szybko z tymczasowymi środkami zaradczymi.
- Włącz lub wzmocnij swoje zabezpieczenia WAF
- Wprowadź surowe blokowanie dla podejrzanych wzorców URI i parametrów.
- Zablokuj lub ogranicz znane nadużywane punkty końcowe: xmlrpc.php, wp-login.php, admin-ajax.php (dla nadużywanych parametrów).
- Wymagaj CAPTCHA dla prób logowania i ogranicz liczbę nieudanych logowań.
- Ogranicz dostęp do obszarów administracyjnych
- Dodaj adresy IP do białej listy w obszarze /wp-admin, jeśli masz statycznych administratorów.
- Użyj uwierzytelniania HTTP (podstawowe uwierzytelnianie) przed wp-admin jako dodatkowej bramy.
- Przenieś adresy URL logowania, jeśli masz narzędzia, które to robią — ale pamiętaj, że to bezpieczeństwo przez nieprzezroczystość i musi być połączone z silniejszymi kontrolami.
- Tymczasowo wyłącz ryzykowne funkcje
- Wyłącz edytowanie plików za pomocą konfiguracji WP: dodaj
define('DISALLOW_FILE_EDIT', true); - Wyłącz edytor motywów/wtyczek w panelu.
- Wyłącz edytowanie plików za pomocą konfiguracji WP: dodaj
- Umieść krytyczne strony w trybie konserwacji/ograniczonej dostępności, jeśli to konieczne, aby zatrzymać automatyczną eksploatację.
Przykład fragmentu Nginx do blokowania xmlrpc (szybkie ograniczenie):
location = /xmlrpc.php {
Jeśli potrzebujesz xmlrpc do legalnych usług (takich jak Jetpack lub niektóre aplikacje mobilne), zamiast tego ogranicz liczbę żądań i wymagaj uwierzytelnienia.
- Izolacja skompromitowanych stron
- Jeśli podejrzewasz kompromitację, usuń stronę z aktywnego DNS lub umieść ją za domeną stagingową, podczas gdy prowadzisz dochodzenie.
To są środki tymczasowe. Powinny być stosowane podczas badania i stosowania trwałych poprawek.
Krok 4 — Wykrywanie: skanowanie i audyt dokładnie
Uruchom wiele warstw wykrywania. Połącz automatyczne skany z ręczną inspekcją.
Automatyczne skany:
- Uruchom pełne skanowanie złośliwego oprogramowania i sprawdzenie integralności plików.
- Skanuj pod kątem znanych wzorców podatności (sygnatury exploitów).
- Sprawdź zmodyfikowane pliki: wyszukaj ostatnio zmienione pliki w wp-content, uploads, mu-plugins.
# znajdź pliki PHP zmodyfikowane w ciągu ostatnich 7 dni
Kontrole bazy danych:
- Szukaj nieautoryzowanych użytkowników administratora:
WYBIERZ ID, user_login, user_email, user_registered Z wp_users GDZIE ID > 1 PORZĄDEK PO ID;
- Wyszukaj podejrzane treści w postach/stronach/meta:
SELECT * FROM wp_postmeta WHERE meta_value LIKE '%base64%' OR meta_value LIKE '%eval(%';
Analiza logów:
- Sprawdź logi dostępu pod kątem nietypowych skoków ruchu, nietypowych agentów użytkowników lub żądań z danymi przypominającymi ładunki w ciągach zapytań.
- Szukaj powtarzających się POSTów do punktów końcowych takich jak /wp-admin/admin-ajax.php, POSTów z długimi zakodowanymi ładunkami lub żądań zawierających podejrzane parametry.
Ręczna weryfikacja:
- Sprawdź oczekujące zadania cron i zaplanowane zadania w bazie danych (wp_options cron).
- Przejrzyj niedawno zainstalowane wtyczki i nieznane mu-wtyczki.
- Sprawdź uploads pod kątem plików PHP w katalogu uploads (nie powinny być wykonywalne).
Wskaźniki kompromitacji (IoCs), na które należy zwrócić uwagę:
- Nowi użytkownicy administratora lub nieznane zaplanowane zadania.
- Połączenia wychodzące do podejrzanych adresów IP/domen z serwera.
- Zmodyfikowane pliki rdzenia (index.php, wp-config.php).
- Zakodowane ładunki w plikach motywów lub w bazie danych (eval(base64_decode(…))).
Krok 5 — Naprawa i wzmocnienie
Jeśli znajdziesz kompromitację lub lukę, wykonaj te kroki.
- Łatka lub aktualizacja: Jeśli dostępna jest oficjalna aktualizacja, wdroż ją na wszystkich dotkniętych stronach po przetestowaniu na etapie.
- Wyczyść zainfekowane pliki:
- Zastąp pliki rdzenia, motywu i wtyczek z zaufanego źródła.
- Usuń nieznane pliki (szczególnie wykonywalne PHP w /wp-content/uploads).
- Zrób kopie forensyczne podejrzanych plików przed usunięciem do analizy.
- Zresetuj sekrety:
- Wymuś reset haseł dla wszystkich użytkowników administracyjnych.
- Zmień klucze API i tokeny używane przez stronę.
- Rotuj dane uwierzytelniające bazy danych i zaktualizuj wp-config.php odpowiednio.
- Sprawdź dane uwierzytelniające do zdalnego przechowywania, CDN i usługi zewnętrzne.
- Unieważnij nieaktywne konta:
- Usuń wszelkie nieużywane lub domyślne konta administratorów.
- Wprowadź zasadę najmniejszych uprawnień; utwórz oddzielne konta z odpowiednimi rolami.
- Przywróć z czystych kopii zapasowych:
- Jeśli naprawa jest skomplikowana, przywróć czysty zrzut wykonany przed datą kompromitacji.
- Upewnij się, że kopie zapasowe są skanowane przed przywróceniem.
- Zastosuj długoterminowe wzmocnienie:
- Użyj uwierzytelniania dwuskładnikowego dla wszystkich administratorów.
- Stosuj zasady silnych haseł.
- Wyłącz XML-RPC, jeśli nie jest potrzebny.
- Wymuszaj HTTPS wszędzie i HSTS.
- Wyłącz listy katalogów i wykonywanie PHP w katalogach przesyłania.
Przykład .htaccess, aby zapobiec wykonywaniu PHP w przesyłkach (Apache):
# Chroń przesyłki przed wykonaniem
Krok 6 — Wirtualne łatanie i zasady WAF (gdy wdrożenie poprawki jest opóźnione)
Jeśli wdrożenie poprawki jest opóźnione lub nie ma poprawki, wirtualne łatanie za pomocą WAF jest skuteczną warstwą łagodzenia. Wirtualne łatanie blokuje próby wykorzystania na poziomie żądania bez zmiany kodu.
Ogólne strategie wirtualnego łatania:
- Blokuj konkretne ścieżki URL lub parametry używane w exploicie.
- Blokuj szczególne metody HTTP lub typy treści dla punktów końcowych, które nie powinny ich akceptować.
- Sprawdzaj ciała żądań pod kątem znanych sygnatur ładunków exploita (wzorce takie jak base64, eval, typowe wzorce tokenów SQLi/XSS).
- Wprowadź ścisłe ograniczenia szybkości dla punktów końcowych z nadużywającymi wzorcami (logowanie, xmlrpc, admin-ajax).
- Geo-blokuj lub ograniczaj ruch z podejrzanych zakresów IP.
- Dodaj do czarnej listy znane złośliwe user-agenty lub nagłówki żądań używane przez zestawy exploitów.
Przykładowy wzorzec do blokowania podejrzanych prób przesyłania base64 (pseudokod):
- Jeśli żądanie POST zawiera wartość parametru pasującą do regex
/(eval\(|base64_decode\(|gzinflate\()/ito zablokuj i powiadom.
Szkic zasady mod_security (koncepcyjny):
SecRule REQUEST_BODY "@rx (base64_decode|eval\(|gzinflate\()" \"
Notatka: Dostosuj zasady ostrożnie, aby zminimalizować fałszywe alarmy. Rejestruj i monitoruj zasady w trybie “obserwacji” przed przełączeniem na “odmów”.
Przykład ograniczenia szybkości (Nginx):
limit_req_zone $binary_remote_addr zone=one:10m rate=10r/m;
Krok 7 — Reakcja na incydent: ograniczenie → eliminacja → odzyskiwanie → wyciągnięte wnioski
Podążaj za jasnym cyklem reakcji na incydent:
- Powstrzymanie: Ogranicz szkody i zatrzymaj aktywną eksploatację. Tymczasowe czarne dziury, blokady WAF, blokowanie IP.
- Likwidacja: Usuń wszystkie ślady atakującego (tylne drzwi, powłoki webowe, złośliwe zadania cron).
- Powrót do zdrowia: Przywróć zdrową, zaktualizowaną stronę i monitoruj ją uważnie.
- Wyciągnięte wnioski: Udokumentuj przyczynę incydentu, harmonogram, luki i usprawnienia.
W swoim raporcie po incydencie uwzględnij:
- Harmonogram wykrycia i podjętych działań.
- Analiza przyczyny źródłowej (np. niezałatana wtyczka X umożliwiła RCE).
- Lista skompromitowanych zasobów, IP i kont użytkowników.
- Zakończone kroki naprawcze i dowody weryfikacji (logi, sumy kontrolne plików).
- Rekomendacje i zmiany wprowadzone w celu zmniejszenia ryzyka.
Praktyczne przykłady: zapytania i polecenia, które pomogą w twoim śledztwie
Szukaj podejrzanego base64 w plikach:
grep -R --include=*.php -n "base64_decode" /var/www/example.com | tee /tmp/suspect_base64.txt
Znajdź pliki PHP w uploads (częsty znak powłoki webowej):
find /var/www/example.com/wp-content/uploads -type f -name "*.php" -print
Sprawdź listę zmodyfikowanych plików i posortuj według daty:
find /var/www/example.com -type f -not -path "*/.git/*" -printf '%TY-%Tm-%Td %TT %p
Lista zaplanowanych wydarzeń WP cron:
wp cron event list --fields=hook,next_run,recurrence --format=table
Przeszukaj DB w poszukiwaniu podejrzanej zawartości meta:
SELECT post_id, meta_key, meta_value FROM wp_postmeta WHERE meta_value LIKE '%eval(%' OR meta_value LIKE '%base64%';
Testowanie swoich środków zaradczych
Po zastosowaniu zasad WAF lub wzmocnieniu, zweryfikuj, że Twoja strona działa:
- Przetestuj logowanie, zakupy i wszelkie niestandardowe formularze.
- Zweryfikuj punkty końcowe API używane przez aplikacje i osoby trzecie.
- Przeprowadź testy funkcjonalne na etapie przed włączeniem zasad deny-mode na produkcji.
- Monitoruj dzienniki błędów w poszukiwaniu zwiększonych szczytów 403/404, które mogą wskazywać na fałszywe pozytywy.
Zacznij od okresu obserwacji, w którym Twój WAF rejestruje i powiadamia, ale nie blokuje, a następnie przejdź do polityki blokowania, gdy będziesz pewny, że zasady są bezpieczne.
Monitorowanie: na co zwracać uwagę po zastosowaniu środków zaradczych
Przez pierwsze 7–14 dni, ściśle monitoruj:
- Dzienniki dostępu serwera WWW: szczyty lub powtarzające się trafienia na zablokowanych punktach końcowych.
- Dzienniki uwierzytelniania: powtarzające się wzorce nieudanych logowań.
- Dzienniki błędów: nowe nieznane 500 lub nietypowe 403 od legalnych użytkowników (wskazuje na fałszywe pozytywy).
- Połączenia wychodzące z serwera: nietypowe połączenia z adresami IP/domenami mogą wskazywać na tylne drzwi.
- Źródła reputacji i platformy podatności w celu uzyskania aktualizacji związanych z dotkniętym komponentem.
Ustaw automatyczne powiadomienia dla:
- Nowego użytkownika administracyjnego.
- Zmiany w krytycznych plikach (wp-config, pliki rdzeniowe).
- Wykonanie plików PHP w katalogu uploads.
Lista kontrolna hartowania (długoterminowa)
- Regularnie aktualizuj rdzeń WordPressa, wtyczki i motywy.
- Wdrożenie środowiska stagingowego i testowanie aktualizacji przed produkcją.
- Wprowadzenie zasady najmniejszych uprawnień dla ról użytkowników i dostępu do serwera.
- Użyj uwierzytelniania dwuskładnikowego i egzekwowania silnych haseł.
- Wyłącz edytowanie plików za pomocą panelu WP.
- Ogranicz wykonywanie PHP w przesyłanych plikach.
- Wdroż WAF z niestandardowymi regułami i możliwością wirtualnego łatania.
- Utrzymuj kopie zapasowe w trybie offline, niezmienne, przechowywane dla kilku punktów przywracania.
- Monitoruj porady dotyczące bezpieczeństwa i źródła informacji o lukach w zabezpieczeniach związane z twoim stosem.
- Okresowe testy penetracyjne i audyty bezpieczeństwa.
Jak WP-Firewall pomaga (praktyczne powiązanie z powyższymi krokami)
Jako zarządzany zapora WordPress i usługa bezpieczeństwa, WP-Firewall jest zaprojektowany, aby wspierać każdy etap reakcji i zapobiegania:
- Szybkie wirtualne łatanie: blokuje wzorce exploitów na krawędzi, więc niezałatane strony są chronione, aż do wdrożenia poprawki kodu.
- Zarządzane reguły WAF: wstępnie zbudowane zestawy reguł, które łagodzą ryzyka OWASP Top 10 i blokują powszechne wektory exploitów WordPress.
- Skanowanie złośliwego oprogramowania: regularnie skanuje systemy plików i oznacza nieoczekiwane zmiany oraz złośliwe ładunki.
- Automatyzacja łagodzenia: ograniczenie szybkości, ochrona logowania i blokowanie powszechnych punktów nadużyć, takich jak xmlrpc i admin-ajax.
- Raportowanie bezpieczeństwa (Pro): miesięczne raporty bezpieczeństwa i kontekst incydentów pomagają zespołom podejmować świadome decyzje.
- Opcje usług zarządzanych (dodatki Pro): dedykowane wsparcie, optymalizacja bezpieczeństwa i usługi zarządzane, aby złagodzić obciążenia operacyjne podczas incydentów.
Niezależnie od tego, czy jesteś na darmowym planie, czy na planie zarządzanym, warstwowe zabezpieczenia i możliwości skanowania pomagają szybciej wykrywać i reagować, minimalizując przestoje.
Chroń swoją stronę teraz z darmowym planem WP-Firewall
Zarejestruj się w planie WP-Firewall Basic (Darmowy), aby dodać silną warstwę ochrony do swojej strony WordPress już dziś: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
Co otrzymujesz w Basic (Darmowy):
- Podstawowa ochrona: zarządzana zapora chroniąca twoją stronę na krawędzi.
- Nielimitowana przepustowość przez zaporę ogniową, aby zapewnić stabilność pod obciążeniem.
- Ochrony WAF dostosowane do WordPressa.
- Skaner złośliwego oprogramowania do wykrywania podejrzanych plików i wzorców.
- Łagodzenie ryzyk OWASP Top 10 (SQLi, XSS, CSRF itp.), które obejmują najczęstsze i najniebezpieczniejsze zagrożenia dla aplikacji internetowych.
Jeśli potrzebujesz bardziej aktywnej naprawy, plany Standard i Pro dodają automatyczne usuwanie złośliwego oprogramowania, kontrolę białej/czarnej listy IP, miesięczne raporty bezpieczeństwa oraz zaawansowane usługi zarządzane — wszystko zaprojektowane, aby pomóc Ci utrzymać bezpieczeństwo witryn przy mniejszym obciążeniu operacyjnym.
Przykłady z życia i wyciągnięte wnioski (anekdoty z obsługi incydentów)
- Pośpieszne łatanie prowadzi do regresji. Widzieliśmy zespoły, które natychmiast wdrażały aktualizacje od dewelopera wtyczek bez etapu testowania, a później odkrywały, że zmiana wersji spowodowała awarię pamięci podręcznej i przestoje. Zawsze testuj najpierw na etapie testowym i używaj WAF, aby zapewnić ochronę podczas testowania.
- Tylnie drzwi często przetrwają “szybkie” czyszczenie. Napastnicy zostawiają wiele mechanizmów utrzymania — nieautoryzowanych użytkowników administratora, opcje bazy danych, mu-wtyczki lub zaplanowane zadania. Pełne, metodyczne przeszukanie (w tym DB i cron) jest niezbędne.
- Wirtualne łatanie uratowało witrynę pod aktywną eksploatacją. W jednym przypadku, zalecenie zniknęło z publicznego widoku, ponieważ autor i dostawca skoordynowali prywatne ujawnienie. Właściciel witryny użył reguł WAF, aby złagodzić eksploatację, aż dostawca wydał poprawkę, unikając przestoju lub utraty danych.
- Widoczność przewyższa założenia. Odkryliśmy, że wielu właścicieli zakładało “brak ruchu z kraju X” i blokowało całe obszary geograficzne, tylko po to, aby zablokować legalnych klientów. Zawsze monitoruj i wprowadzaj blokowanie geograficzne stopniowo, aby uniknąć wpływu na biznes.
Ostateczne zalecenia — praktyczne następne kroki
- Jeśli kliknąłeś w zalecenie dotyczące podatności, które zwraca 404, nie ignoruj tego. Traktuj to jako informacje do działania i postępuj zgodnie z przepływem inwentaryzacji → ograniczenia → skanowania → łatania powyżej.
- Włącz lub wzmocnij ochrony WAF i wdrażaj wirtualne łaty, podczas gdy weryfikujesz oficjalne poprawki.
- Utrzymuj aktualną inwentaryzację wtyczek, motywów i wersji rdzenia każdej witryny — przyspiesza to reakcję.
- Ustaw automatyczne skanowania i powiadomienia o podejrzanej aktywności i zmianach plików.
- Rozważ skorzystanie z zarządzanej usługi bezpieczeństwa do monitorowania 24/7 i wirtualnego łatania, jeśli zarządzasz wieloma witrynami lub krytycznymi zasobami.
Proaktywność to różnica między bliskim incydentem a naruszeniem. Jeśli potrzebujesz pomocy w ocenie narażenia lub włączeniu warstw ochronnych w wielu witrynach WordPress, nasz zespół w WP-Firewall jest tutaj, aby pomóc.
Jeśli chcesz zwięzły plan działania, który możesz wydrukować i natychmiast wdrożyć, oto on:
- Inwentaryzuj wszystkie witryny i wersje. (10–30 minut na witrynę, w zależności od rozmiaru)
- Włącz/wzmocnij zasady WAF i limity przepustowości. (5–15 minut)
- Skanuj pliki i bazę danych w poszukiwaniu IoC. (30–120 minut)
- Zastosuj poprawki lub wirtualne poprawki. (15–60 minut)
- Zmień dane uwierzytelniające i wymuś MFA. (30–90 minut)
- Monitoruj dzienniki i alerty przez 7–14 dni. (ciągłe)
Bądź bezpieczny i utrzymuj swoje procesy bezpieczeństwa proste, powtarzalne i mierzalne.
— Zespół bezpieczeństwa WP-Firewall
