Jak zabezpieczyć stronę na hostingu — IP, FTP, hotlink, PHP i WAF

Większość włamań na strony firmowe nie wymaga od napastnika wyjątkowych umiejętności. Wystarczy otwarte FTP ze starym hasłem, panel administracyjny dostępny dla całego świata albo katalog na obrazki, w którym serwer posłusznie uruchomi wgrany skrypt PHP. Dobra wiadomość: zabezpieczenie strony na hostingu to w dużej mierze kilka prostych ustawień, które robi się raz i które działają latami.

Od czego zacząć zabezpieczenie strony

Bezpieczeństwo strony to warstwy. Żadna pojedyncza blokada nie chroni przed wszystkim, ale każda kolejna zamyka jedną z typowych dróg włamania. W tym tekście przechodzimy przez te, które mają największy wpływ przy najmniejszym wysiłku:

• bezpieczny dostęp do plików (SFTP zamiast FTP),
• ograniczenie panelu administracyjnego do znanych adresów IP,
• zakaz uruchamiania PHP w katalogach z plikami użytkowników,
• ochrona przed hotlinkiem,
• poprawne uprawnienia plików,
• WAF, logowanie dwuetapowe, osobne konta, aktualizacje i kopie.

Ważne zastrzeżenie: część przykładów dotyczy pliku .htaccess, czyli pliku konfiguracyjnego serwera Apache (oraz zgodnego z nim LiteSpeed), umieszczanego w katalogu strony. Błędna reguła w tym pliku kończy się zwykle błędem 500 — strona przestaje się wyświetlać. Każdą zmianę testuj od razu po zapisaniu, a przed edycją zrób kopię pliku. Jeśli hosting używa serwera Nginx, .htaccess nie działa i podobne ustawienia robi się w konfiguracji serwera.

SFTP zamiast FTP, a nieużywane FTP — wyłączone

Klasyczne FTP przesyła login i hasło otwartym tekstem. Każdy, kto ma wgląd w ruch sieciowy (np. w publicznej sieci Wi-Fi), może je przechwycić. SFTP robi to samo — pozwala wgrywać i pobierać pliki — ale przez szyfrowane połączenie.

• Jeśli hosting oferuje SFTP, korzystaj tylko z niego, a konta FTP usuń lub zablokuj.
• Usuń stare konta FTP zakładane „na chwilę” dla dawnych wykonawców.
• Nie zapisuj haseł w programie do FTP na komputerze współdzielonym z innymi osobami.

Panel administracyjny tylko z Twoich adresów IP

Panel logowania WordPressa (wp-login.php, wp-admin) czy Joomli (/administrator) jest codziennie atakowany przez automaty próbujące odgadnąć hasło. Jeśli Twoja firma ma stały adres IP lub korzysta z VPN, możesz pozwolić na logowanie tylko z tych adresów.

Przykład dla Joomli — plik .htaccess umieszczony w katalogu administrator (Apache 2.4; adresy zastąp własnymi):

Require ip 203.0.113.10
Require ip 198.51.100.0/24

Przykład dla WordPressa — fragment w głównym pliku .htaccess:

<Files "wp-login.php">
    Require ip 203.0.113.10
</Files>

Zanim to wdrożysz, sprawdź, czy Twój adres IP się nie zmienia (u wielu dostawców internetu domowego zmienia się regularnie). Inaczej zablokujesz sam siebie. Jeśli adres jest zmienny, lepszym wyborem bywa ochrona panelu dodatkowym hasłem na poziomie serwera lub logowanie przez VPN.

Zakaz uruchamiania PHP w katalogach z plikami

To jedno z najskuteczniejszych zabezpieczeń, a wciąż rzadko stosowane. Katalogi na obrazki i załączniki (w Joomli images, w WordPressie wp-content/uploads) powinny przechowywać zdjęcia i dokumenty, a nie programy. Tymczasem gdy napastnik przez dziurawy formularz lub rozszerzenie wgra tam plik PHP, serwer go wykona — i włamywacz ma zdalny dostęp do strony.

Wystarczy w takim katalogu utworzyć plik .htaccess o treści:

<FilesMatch ".(phpd?|phtml|phar)$">
    Require all denied
</FilesMatch>

Reguła blokuje wywołanie z przeglądarki plików z rozszerzeniami .php, .php5, .php7, .phtml i .phar. Po wdrożeniu wgraj testowy plik test.php do tego katalogu i otwórz go w przeglądarce — powinieneś zobaczyć błąd 403 (brak dostępu). Sprawdź też, czy obrazki na stronie nadal się wyświetlają. Na koniec usuń plik testowy.

W ostatnich tygodniach porządkowaliśmy strony Joomla po włamaniach, w których webshelle — złośliwe pliki PHP dające dostęp do serwera — leżały właśnie w katalogach na obrazki. Taka blokada nie usuwa już wgranych plików, ale sprawia, że nie da się ich uruchomić. Jeśli podejrzewasz, że coś już zostało wgrane, zacznij od tekstu jak sprawdzić, czy strona jest zawirusowana.

Ochrona przed hotlinkiem

Hotlink to sytuacja, w której inna strona wyświetla Twoje obrazki, pobierając je bezpośrednio z Twojego serwera. Płacisz za transfer, a ktoś korzysta z Twoich zdjęć produktów. Blokadę ustawisz w głównym pliku .htaccess:

RewriteEngine On
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https?://(www.)?twojadomena.pl/ [NC]
RewriteRule .(jpe?g|png|gif|webp)$ - [F,NC]

Pierwszy warunek przepuszcza żądania bez nagłówka „skąd przyszedł” (np. wpisanie adresu obrazka ręcznie), drugi — żądania z Twojej domeny. Pozostałe dostają błąd 403. Jeśli Twoje obrazki mają się pokazywać np. w wynikach grafiki Google lub na Twoich profilach w mediach społecznościowych, dopisz dla nich kolejne wyjątki albo zrezygnuj z tej blokady.

Uwaga z naszej praktyki: reguły w .htaccess nie powinny blokować katalogu /.well-known/. Korzysta z niego m.in. automatyczne odnawianie certyfikatu Let’s Encrypt. Gdy zostanie zablokowany, certyfikat w pewnym momencie się nie odnowi.

Uprawnienia plików i plików konfiguracyjnych

Uprawnienia decydują, kto może czytać i zmieniać pliki na serwerze. Typowe, bezpieczne ustawienia na hostingu współdzielonym to:

Element	Zalecane uprawnienia
Katalogi	755
Pliki	644
wp-config.php (WordPress)	400 lub 440
configuration.php (Joomla)	tylko do odczytu, np. 444 lub 440

Uprawnienia 400 lub 440 dla wp-config.php rekomenduje dokumentacja WordPressa (stan na październik 2026). Dla configuration.php w Joomli najważniejsze, żeby plik nie był zapisywalny dla wszystkich — konkretna wartość zależy od tego, jak hosting uruchamia PHP. Po zmianie sprawdź, czy strona działa. Pamiętaj też, że zapis konfiguracji globalnej w panelu Joomli może wymagać chwilowego przywrócenia prawa zapisu.

Nigdy nie ustawiaj uprawnień 777 „żeby zadziałało”. To otwiera plik lub katalog do zapisu dla każdego procesu na serwerze.

WAF, logowanie dwuetapowe i osobne konta

WAF (Web Application Firewall — zapora aplikacji internetowych) filtruje ruch do strony i odrzuca typowe ataki, zanim dotrą do CMS-a. Wiele firm hostingowych ma go wbudowanego, np. w postaci ModSecurity — warto sprawdzić w panelu, czy jest włączony. Drugą opcją są usługi działające przed serwerem, takie jak Cloudflare, które dodatkowo chronią przed nadmiernym ruchem. WAF nie zastępuje aktualizacji, ale kupuje czas, gdy w rozszerzeniu pojawi się nowa luka.

Logowanie dwuetapowe (2FA) wymaga oprócz hasła kodu z aplikacji w telefonie. Włącz je dla panelu hostingu, konta u rejestratora domeny i kont administratorów w CMS. Joomla ma tę funkcję wbudowaną od wersji 4.2, a w WordPressie włączysz ją przez wtyczkę.

Osobne konta i najmniejsze uprawnienia. Każda osoba ma własny login. Redaktor, który dodaje aktualności, nie potrzebuje uprawnień administratora. Gdy ktoś odchodzi z firmy lub kończy współpracę, jego konto usuwasz od razu.

Aktualizacje i kopie — fundament, bez którego reszta nie wystarczy

Nawet najlepsze reguły w .htaccess nie pomogą, jeśli strona działa na rozszerzeniu z publicznie znaną luką. Regularnie aktualizuj CMS, szablon i rozszerzenia, a nieużywane usuwaj. Jak robić to bezpiecznie, opisujemy w tekście o aktualizacji strony internetowej.

Równie ważna jest wersja PHP na serwerze. Wersje bez wsparcia nie dostają poprawek bezpieczeństwa — sprawdź, jaką wersję PHP masz i jak ją bezpiecznie zmienić.

Na koniec: kopia zapasowa przechowywana poza serwerem. Jeśli wszystkie zabezpieczenia zawiodą, to ona pozwoli wrócić do działającej strony.

Jeśli wolisz, żeby ktoś zrobił to za Ciebie i pilnował na bieżąco, zobacz nasz serwis i bezpieczeństwo stron.

Najczęstsze pytania

Jakie zabezpieczenia w htaccess warto mieć na każdej stronie?

Najbardziej uniwersalne to zakaz uruchamiania PHP w katalogach z obrazkami i załącznikami oraz ochrona plików konfiguracyjnych przed odczytem z przeglądarki. Ograniczenie panelu administracyjnego do adresów IP i ochrona przed hotlinkiem zależą już od tego, jak pracuje Twoja firma.

Co zrobić, gdy po zmianie .htaccess strona pokazuje błąd 500?

Przywróć poprzednią wersję pliku z kopii — przez menedżer plików w panelu hostingu lub SFTP. Błąd 500 po edycji .htaccess niemal zawsze oznacza literówkę lub dyrektywę, której serwer nie obsługuje. Szczegóły zwykle znajdziesz w dzienniku błędów w panelu hostingu.

Czy WAF wystarczy jako zabezpieczenie strony?

Nie. WAF zatrzymuje wiele typowych ataków, ale nie zamknie luki w nieaktualnym rozszerzeniu ani nie ochroni przed przejęciem słabego hasła. To jedna z warstw, która działa najlepiej razem z aktualizacjami, 2FA i kopiami zapasowymi.

Czy te ustawienia zadziałają na każdym hostingu?

Przykłady z .htaccess działają na serwerach Apache 2.4 i zgodnych (np. LiteSpeed), o ile hosting pozwala na nadpisywanie ustawień w tym pliku. Na serwerach Nginx podobne reguły ustawia się w konfiguracji serwera — wtedy najlepiej poprosić o to hosting lub osobę, która opiekuje się stroną.