Bezpieczeństwo stron: praktyczny przewodnik
Większość stron nie jest atakowana celowo. Są znajdowane przez automatyczne skanery przeczesujące internet w poszukiwaniu znanych podatności i słabych haseł. To dobra wiadomość, bo znaczy, że podstawowe środki zatrzymują większość ataków.
Ten przewodnik omawia te środki, mniej więcej w kolejności usuwanego ryzyka na włożony wysiłek.
Dostępy: gdzie zaczyna się większość włamań#
Skradzione albo odgadnięte dane logowania to najczęstszy sposób, w jaki padają małe strony — częstszy niż jakakolwiek podatność techniczna.
- Dwuskładnikowe uwierzytelnianie na każdym koncie administratora, bez wyjątku.
- Unikalne hasła z menedżera haseł; powtórzone hasła wyciekają gdzie indziej i są tu testowane.
- Usuwaj konta osób, które odeszły, i dawnych agencji — o tym prawie zawsze się zapomina.
- Dawaj minimalne potrzebne uprawnienia; redaktor nie musi być administratorem.
- Ogranicz próby logowania i blokuj po powtórzonych niepowodzeniach.
- Zabezpiecz też otoczenie: hosting, DNS, rejestratora domeny i pocztę. Utrata DNS jest gorsza niż utrata strony.
- Używaj SFTP albo kluczy SSH, nigdy zwykłego FTP z hasłem.
Rejestrator domeny to konto najczęściej pozostawiane bez drugiego składnika i powodujące największe szkody, gdy padnie.
Aktualizacje i powierzchnia ataku#
Każdy zainstalowany element to element, który trzeba aktualizować. Najtańsza praca nad bezpieczeństwem to usuwanie tego, czego nie używasz.
| Środek | Dlaczego się liczy |
|---|---|
| Aktualny rdzeń CMS | Znane podatności są skanowane w ciągu dni |
| Aktualne wtyczki | Najczęstsza droga wejścia na stronach WordPress |
| Usunięcie nieużywanych wtyczek | Wyłączona nie znaczy bezpieczna; kod nadal tam jest |
| Usunięcie nieużywanych motywów | Ten sam powód, jeszcze częściej zapominane |
| Wspierana wersja PHP | Stare wersje nie dostają poprawek bezpieczeństwa |
| Aktualne pakiety serwera | Przy hostingu zarządzanym robi to dostawca — sprawdź |
| Zależności w kodzie na zamówienie | Biblioteki też się starzeją |
Wykonuj aktualizacje na środowisku testowym, a potem przetestuj formularze i, w sklepie, ścieżkę zakupową. Aktualizacja po cichu psująca formularz to osobny rodzaj awarii.
Ochrona aplikacji i serwera#
Środki pokrywające podatności techniczne, a nie dostępy.
- Waliduj i oczyszczaj wszystkie dane wejściowe po stronie serwera. Kontrola w przeglądarce to wygoda, nie bezpieczeństwo.
- Używaj zapytań przygotowanych przy każdym dostępie do bazy — to zamyka wstrzykiwanie SQL.
- Escapuj wyjście przy wyświetlaniu, żeby zapobiec skryptom międzywitrynowym.
- HTTPS wszędzie, z HSTS i automatycznie odnawianym certyfikatem.
- Ustaw nagłówki bezpieczeństwa: Content-Security-Policy, X-Content-Type-Options, Referrer-Policy.
- Ogranicz przesyłanie plików co do typu i rozmiaru, i przechowuj je poza katalogiem publicznym.
- Wyłącz wyświetlanie błędów na produkcji; komunikaty mówią atakującemu, co działa.
- Rozważ zaporę aplikacji webowej przy CMS z wieloma rozszerzeniami.
Kopie i wyjście z włamania#
Bezpieczeństwo czasem zawodzi. Co się wtedy dzieje, zależy całkowicie od tego, co przygotowałeś wcześniej.
- Trzymaj kopie poza serwerem. Kopia na tej samej maszynie zostaje zaszyfrowana albo usunięta razem z resztą.
- Trzymaj kilka pokoleń. Jeśli włamanie wykryto po dwóch tygodniach, wczorajsza kopia też jest zainfekowana.
- Testuj odtworzenie kwartalnie. To krok, którego najczęściej brakuje.
- Przy włamaniu: zdejmij stronę albo włącz tryb konserwacji, zanim zrobisz cokolwiek innego.
- Zmień wszystkie hasła — CMS, hosting, baza, FTP, DNS — przed odtworzeniem.
- Odtwórz z kopii sprzed włamania i zaktualizuj wszystko przed powrotem online.
- Ustal, jak weszli. Odtworzenie bez znalezienia przyczyny oznacza powtórkę.
Przy naruszeniu danych osobowych obowiązują terminy zgłoszenia. Wiedz z góry, kto to ocenia, a nie w trakcie incydentu.
Najczęstsze pytania
Czy WordPress jest niebezpieczny?
Rdzeń jest rozsądnie utrzymywany; ryzyko leży niemal zawsze we wtyczkach, motywach i słabych hasłach administratorów. Strona na WordPressie z drugim składnikiem, kilkoma wtyczkami i aktualnymi wersjami jest w porządku. Strona z czterdziestoma wtyczkami, z których połowa nie była aktualizowana od dwóch lat, to kwestia czasu.
Czy potrzebuję wtyczki bezpieczeństwa?
Są przydatne do ograniczania logowań, nadzoru plików i alertów, ale nie zastępują niczego z powyższej listy. Wtyczka bezpieczeństwa na stronie z przestarzałymi wtyczkami i współdzielonym hasłem nie rozwiązuje prawdziwego problemu. Traktuj ją jak czujnik dymu, a nie jak konstrukcję ognioodporną.
Co zrobić, gdy strona zostanie zhakowana?
Zdejmij ją, zmień wszystkie hasła łącznie z hostingiem i DNS, a potem odtwórz z czystej kopii sprzed włamania. Zaktualizuj wszystko przed powrotem online i ustal, jak weszli — inaczej powtórzy się w tygodniach. Jeśli w grę wchodzą dane osobowe, obowiązują terminy zgłoszenia.
Czy HTTPS chroni stronę przed hakerami?
Nie, i to częste nieporozumienie. HTTPS szyfruje ruch między odwiedzającym a serwerem, co zapobiega podsłuchowi i manipulacji po drodze. Nie robi nic wobec słabych haseł, przestarzałych wtyczek czy wstrzykiwania SQL. Jest konieczne i zupełnie niewystarczające.
bezpieczeństwo stronyzabezpieczenie przed włamaniembezpieczeństwo wordpresscertyfikat sslnagłówki bezpieczeństwastrona zhakowana
