Bezpieczny hosting to izolacja kont, WAF, blokada ataków na hasła, skaner malware, szyfrowanie i kopie z historią. Co chroni serwer, a o co dbasz sam.
Autor: McProdukt · Opublikowano: · Aktualizacja:
Bezpieczny hosting oddziela Twoje konto od kont innych klientów, filtruje złośliwe żądania zaporą WAF, blokuje zgadywanie haseł, skanuje pliki w poszukiwaniu złośliwego kodu, daje wspierane wersje PHP, szyfruje połączenia i sam robi kopie zapasowe z historią. Nawet najlepiej zabezpieczony serwer nie ochroni jednak strony z nieaktualnymi wtyczkami i słabym hasłem - to już Twoja część pracy. Poniżej lista zabezpieczeń i podział obowiązków między Tobą a dostawcą.
Podstawą jest osiem warstw: izolacja kont, WAF, blokada ataków na hasła, skaner złośliwego oprogramowania, wspierane wersje PHP, certyfikat SSL, szyfrowany dostęp do plików i kopie zapasowe.
| Zabezpieczenie | Przed czym chroni | Co musisz zrobić sam |
|---|---|---|
| Izolacja kont | zainfekowane konto innego klienta nie dostanie się do Twoich plików | ważne serwisy trzymać na osobnych kontach |
| WAF (zapora aplikacji WWW) | typowe ataki na stronę: SQL injection, XSS, dołączanie plików | aktualizować CMS, wtyczki i motywy |
| Firewall z blokadą ataków na hasła | masowe zgadywanie haseł do panelu, poczty i FTP | używać długich, unikalnych haseł i 2FA |
| Skaner złośliwego oprogramowania | backdoory i skrypty rozsyłające spam, które zostały na koncie | reagować na alerty i łatać przyczynę infekcji |
| Wspierane wersje PHP | znane luki w starym PHP | przełączyć stronę na wspieraną wersję |
| Certyfikat SSL | podsłuch i podmiana danych w drodze | przekierować całą stronę na HTTPS |
| FTP z TLS, SSH na klucze | przechwycenie i zgadnięcie haseł dostępu do plików | wybierać szyfrowane połączenie, chronić klucz prywatny |
| Kopie zapasowe z historią | utrata danych po włamaniu, awarii albo pomyłce | sprawdzić przywracanie, trzymać własną kopię |
Izolacja kont sprawia, że na serwerze współdzielonym każdy klient działa we własnym, zamkniętym środowisku i nie widzi plików ani procesów innych klientów. Dokumentacja WordPressa ostrzega, że na serwerze współdzielonym włamanie na sąsiednią stronę może zagrozić także Twojej - nawet gdy stosujesz wszystkie zalecenia.
Jednym z rozwiązań jest CageFS z systemu CloudLinux. Według dokumentacji zamyka on każdego użytkownika w osobnej „klatce": użytkownik nie widzi plików ani procesów innych użytkowników, nie zna nawet ich nazw i nie ma dostępu do plików konfiguracyjnych serwera.
Izolacja działa jednak między kontami, a nie między stronami na Twoim własnym koncie. Jeśli na jednym koncie trzymasz sklep i zapomniany blog na starym WordPressie, włamanie na blog może dać dostęp także do plików sklepu. Kiedy warto rozdzielić strony, wyjaśniamy w tekście o kilku stronach na jednym hostingu.
WAF (Web Application Firewall) to zapora, która sprawdza żądania wysyłane do strony i odrzuca te, które wyglądają jak atak, zanim dotrą do WordPressa czy sklepu. Na serwerach hostingowych może to być np. silnik ModSecurity z regułami OWASP CRS. CRS to zestaw ogólnych reguł wykrywania ataków, który rozpoznaje m.in. SQL injection (wstrzykiwanie zapytań do bazy danych), XSS (wstrzykiwanie skryptów), dołączanie plików lokalnych i zdalnych, wstrzykiwanie kodu PHP i poleceń systemowych oraz ruch skanerów szukających dziur.
WAF ma jednak dwie granice:
Firewall serwera śledzi nieudane logowania do panelu, poczty, FTP i SSH, a adresy IP, z których ktoś uporczywie zgaduje hasła, blokuje. To odcina proste boty, które atakują z jednego adresu.
Blokada adresów ma jednak granice. OWASP podaje przykład: atakujący z listą 1 000 serwerów proxy może sprawdzić 2-3 tysiące haseł, zanim zostanie zablokowany. Dlatego drugą warstwę ochrony budujesz sam:
Dobry hosting regularnie skanuje pliki na kontach i wykrywa złośliwy kod: backdoory, skrypty rozsyłające spam czy podmienione pliki CMS. Skaner pokazuje jednak skutek, a nie przyczynę - złośliwy plik oznacza, że ktoś wszedł przez jakąś lukę. Według dokumentacji WordPressa włamania rzadko wynikają z infrastruktury serwera, a najczęściej z samej aplikacji, czyli z części, za którą odpowiada właściciel strony.
Samo usunięcie pliku wskazanego przez skaner to za mało - dopóki luka jest otwarta, infekcja może wrócić. Jak posprzątać stronę krok po kroku, opisujemy w poradniku jak usunąć wirusa z WordPressa.
Każda wersja PHP dostaje poprawki bezpieczeństwa tylko przez określony czas - później wykryte luki nie są już łatane. Według php.net każda gałąź PHP ma 2 lata pełnego wsparcia i 2 kolejne lata wyłącznie poprawek bezpieczeństwa, a potem wsparcie się kończy.
| Wersja PHP | Poprawki bezpieczeństwa |
|---|---|
| 7.4 | zakończone 28 listopada 2022 r. |
| 8.1 | zakończone 31 grudnia 2025 r. |
| 8.2 | do 31 grudnia 2026 r. |
| 8.3 | do 31 grudnia 2027 r. |
| 8.4 | do 31 grudnia 2028 r. |
| 8.5 | do 31 grudnia 2029 r. |
Starsze wersje przydają się tylko po to, żeby stara strona działała do czasu jej aktualizacji. Jak bezpiecznie przejść na nowszą wersję, opisujemy w poradniku jak zmienić wersję PHP na hostingu.
Wszystkie, którymi przesyłasz hasła albo dane: strona, poczta, przesyłanie plików i praca na serwerze przez SSH.
Kopia zapasowa to ostatnia linia obrony, ale tylko wtedy, gdy sięga wystarczająco daleko wstecz. Włamania nie zawsze widać od razu. Jeśli hosting trzyma tylko najnowszą kopię, możesz przywrócić stronę razem ze złośliwym kodem.
Sprawdź, jak często powstają kopie, ile dni są przechowywane i czy obejmują bazy danych. U nas kopie plików i baz powstają automatycznie co 24 godziny i są przechowywane przez 30 dni, a w pakietach Hosting 250 GB i Hosting Email 250 GB - co 6 godzin i przez 40 dni. Niezależnie od tego trzymaj własną kopię poza serwerem. Jak ją zrobić, piszemy w tekście kopie zapasowe strony WWW.
Hosting odpowiada za serwer: system, oprogramowanie serwera, sieć, izolację kont i kopie. Ty odpowiadasz za wszystko, co instalujesz na koncie. Dokumentacja WordPressa mówi to wprost: firmy hostingowe zwykle odpowiadają za infrastrukturę, na której stoi strona, ale nie za aplikację, którą na niej instalujesz. Twoja lista:
Zapytaj dostawcę o każdy punkt z tabeli na początku tekstu - dokumentacja WordPressa radzi dokładnie to samo. Rzetelny dostawca odpowie konkretnie: jak izoluje konta, jakie ma reguły WAF, co robi po wykryciu infekcji, jakie wersje PHP udostępnia, jak długo trzyma kopie i jak je przywrócić.
W hostingu McProdukt konta są od siebie odizolowane (CageFS), ruch filtruje WAF ModSecurity z regułami OWASP CRS, firewall blokuje ataki na hasła, a pliki są skanowane w poszukiwaniu złośliwego oprogramowania. SSH działa tylko na klucze (port 32154), FTP - z szyfrowaniem TLS, a każda domena dostaje darmowy certyfikat SSL odnawiany automatycznie. Więcej przeczytasz na stronie o bezpieczeństwie naszych serwerów, a pakiety porównasz w ofercie hostingu WWW.
Chroni serwer i ogranicza skutki ataków: izoluje konta, filtruje złośliwe żądania, blokuje zgadywanie haseł i robi kopie. Przed włamaniem przez nieaktualną wtyczkę albo wykradzione hasło nie ochroni Cię jednak w pełni - to część, za którą odpowiadasz sam.
Na serwerze współdzielonym jest to możliwe - ostrzega przed tym dokumentacja WordPressa. Izolacja kont, np. CageFS, sprawia, że inne konta nie widzą Twoich plików. Strony na Twoim własnym koncie nie są jednak od siebie odizolowane.
Zanotuj godzinę i adres, pod którym pojawił się błąd 403, i przekaż je obsłudze hostingu. Regułę, która dała fałszywy alarm, można wyłączyć punktowo, bez wyłączania całej ochrony.
Stronie firmowej, której treść rzadko się zmienia, zwykle wystarczy kopia raz na dobę, a sklep z wieloma zamówieniami dziennie potrzebuje częstszych. Równie ważne jest to, jak długo kopie są przechowywane.
Wszystkie poradniki z kategorii: Hosting od podstaw