Jakie są najczęstsze luki w zabezpieczeniach stron i serwerów?

Jeśli korzystasz z hostingu współdzielonego, nie odpowiadasz za bezpieczeństwo całego serwera. Za bezpieczeństwo infrastruktury i warstwy serwerowej odpowiada dostawca hostingu, Ty natomiast odpowiadasz przede wszystkim za to, co dzieje się wewnątrz Twojej usługi. Na chronionym środowisku hostingowym SEOHOST działa Monarx Security, który rozszerza stosowane przez nas zabezpieczenia o kilka współpracujących ze sobą mechanizmów: SmartWAF, ThreatShield oraz Antivirus z Active Protection (więcej o nich przeczytasz w dalszej części artykułu). System zwiększa zakres ochrony zapewnianej po stronie hostingu, ale nie zaktualizuje za Ciebie wtyczki, której producent właśnie opublikował poprawkę, ani nie usunie konta administratora pozostawionego po poprzedniej agencji czy freelancerze.

Bezpieczeństwo strony to więc dwie współpracujące warstwy: zabezpieczenie środowiska, w którym działa strona, oraz bezpieczeństwo samej aplikacji i sposób, w jaki z niej korzystasz. W tym artykule wyjaśnimy, gdzie przebiega ta granica, za jakie elementy odpowiada usługodawca hostingowy, a na które Ty masz bezpośredni wpływ jako użytkownik. Zapraszamy.

• Bezpieczeństwo strony i hostingu – kto za co odpowiada?
• Za jakie zabezpieczenia odpowiada dostawca hostingu?
• Monarx Security jako jedna z warstw ochrony hostingu SEOHOST
• Z jakimi zagrożeniami możesz spotkać się po swojej stronie?
• Dwie warstwy bezpieczeństwa – ochrona hostingu i usunięcie źródła podatności
• Checklista bezpieczeństwa strony i hostingu
• A co z bezpieczeństwem serwera VPS?

Monarx Security działa bezpośrednio w środowisku hostingowym SEOHOST. Nie musisz instalować dodatkowego programu ani kolejnej wtyczki w WordPressie. System analizuje kilka obszarów środowiska i może reagować na zagrożenie na różnych etapach jego działania. Szczegóły opisaliśmy w poradniku Monarx w SEOHOST – jak działa ochrona przed malware?

Bezpieczeństwo strony i hostingu – kto za co odpowiada?

Zacznijmy od najważniejszej rzeczy, bo w dyskusjach o bezpieczeństwie łatwo wrzucić wszystko do jednego worka i oczekiwać od usługi hostingowej funkcji, które standardowo wcale nie należą do jej zakresu.

Strona internetowa nie jest tym samym co usługa hostingowa, a hosting współdzielony nie jest tym samym co fizyczny serwer stojący w centrum danych. Na hostingu współdzielonym usługodawca zarządza warstwą infrastruktury, systemem, usługami serwerowymi i mechanizmami ochrony, natomiast Ty otrzymujesz wydzieloną przestrzeń, w której uruchamiasz np. WordPressa.

Właśnie tutaj przebiega jedna z najważniejszych granic odpowiedzialności. Świadcząc usługę hostingową, odpowiadamy za utrzymanie infrastruktury i samej usługi, jej dostępność, stabilność oraz ochronę przed możliwie szerokim zakresem zagrożeń oddziałujących na środowisko serwerowe. Standardowa usługa hostingowa nie jest jednak usługą stałej administracji Twoją stroną internetową ani obsługą IT Twojej firmy. Nie zarządzamy za Ciebie treścią WordPressa, nie decydujemy, których wtyczek potrzebujesz, nie usuwamy samodzielnie kont byłych pracowników i nie wybieramy za Ciebie haseł do firmowych skrzynek e-mail.

Masz oczywiście dostęp do narzędzi pozwalających zarządzać tymi elementami, a w naszej bazie wiedzy znajdziesz instrukcje prowadzące krok po kroku przez najczęstsze operacje. W określonych przypadkach możesz także skorzystać ze wsparcia naszego zespołu oraz dodatkowych usług konfiguracyjnych. 

W poniższej tabeli przedstawiliśmy najważniejsze obszary , które pomogą Ci odróżnić utrzymanie i zabezpieczenie hostingu od stałej administracji zawartością strony:

Powyższy podział nie jest „tabelą SEOHOST” stworzoną po to, aby przerzucić określone obowiązki na klienta. Tak funkcjonuje model hostingu współdzielonego. Podobny sposób rozdzielania warstw bezpieczeństwa zobaczysz u wielu dostawców hostingu w różnych krajach: infrastruktura i jej zabezpieczenia pozostają po stronie operatora, natomiast właściciel aplikacji kontroluje jej wersję, dodatki, konta użytkowników i konfigurację.

Hosting daje Ci bezpieczne środowisko i narzędzia do zarządzania usługą. Jeżeli potrzebujesz pomocy z określoną konfiguracją, nie musisz zgadywać. Skorzystaj z naszego Centrum Pomocy albo skontaktuj się z supportem – nawet jeśli dana czynność leży po Twojej stronie, często jesteśmy w stanie wskazać miejsce, od którego warto zacząć diagnostykę.

Dobry hosting ogranicza powierzchnię ataku i przejmuje obszary, do których jako zwykły użytkownik nie powinieneś nawet potrzebować dostępu. Nie podejmie jednak za Ciebie wszystkich decyzji dotyczących zawartości konta. I właśnie dlatego oba obszary muszą działać równolegle.

Za jakie zabezpieczenia odpowiada dostawca hostingu?

Zacznijmy od tego, za co odpowiadamy my, świadcząc dla Ciebie usługę hostingową. Część z tych mechanizmów działa całkowicie poza panelem użytkownika. Nie musisz więc codziennie sprawdzać wersji systemu operacyjnego hosta, analizować ruchu wszystkich użytkowników serwera ani reagować, gdy ten sam automatyczny skaner zaczyna odpytywać tysiące stron jednocześnie.

Izolacja kont i procesów

Na jednym środowisku hostingowym mogą działać strony wielu klientów. Samo współdzielenie infrastruktury nie jest problemem – pod warunkiem że poszczególne konta i procesy są od siebie odpowiednio odseparowane. Jeżeli strona innego klienta zostanie zainfekowana, atakujący nie powinien z tego powodu otrzymać dostępu do Twoich plików ani zasobów.

W SEOHOST wykorzystujemy w tym celu m.in. CloudLinux, który pozwala izolować środowiska użytkowników oraz kontrolować zasoby wykorzystywane przez poszczególne konta. Takie rozwiązanie ogranicza również sytuacje, w których jeden intensywnie działający serwis wpływa na pozostałych klientów tego samego środowiska.

Zwróć jednak uwagę na jedną rzecz. Izolacja pomiędzy klientami nie rozdziela automatycznie wszystkich stron znajdujących się wewnątrz Twojego własnego konta. Jeśli trzymasz obok siebie aktualny sklep, starego WordPressa w katalogu /old/ oraz instalację testową sprzed kilku lat, właśnie te elementy powinieneś kontrolować samodzielnie.

Monitoring infrastruktury i reagowanie na anomalie

Nie każdy problem wygląda jak klasyczny atak zakończony przejęciem strony. Wcześniej często pojawia się nagły wzrost liczby żądań, duże obciążenie procesu, nietypowa liczba błędów czy określony wzorzec ruchu powtarzający się równocześnie na wielu usługach. Zespół administratorów widzi takie zdarzenia z perspektywy całej infrastruktury, a nie jednej domeny.

Dzięki temu możemy reagować na sytuacje, których właściciel pojedynczej strony nawet nie zauważy w Google Analytics czy panelu WordPress. Jeżeli określony automat zaczyna masowo skanować konkretne adresy, endpointy lub podatne wersje oprogramowania, działania ochronne można zastosować szerzej niż na jednej witrynie.

• Przeczytaj również: jakie zagrożenia czyhają na stronę internetową i skąd bierze się automatyczny ruch.

Filtrowanie ruchu i ochrona infrastruktury

Strona dostępna publicznie w sieci przez całą dobę otrzymuje żądania nie tylko od klientów i wyszukiwarek. Docierają do niej również automaty skanujące Internet, boty brute force, narzędzia szukające znanych podatności i ruch, którego jedynym zadaniem jest znalezienie punktu wejścia albo wygenerowanie obciążenia.

Po stronie infrastruktury stosujemy więc więcej niż jeden mechanizm: ochronę Anti-DDoS, filtrowanie ruchu, reguły WAF/ModSecurity, izolację oraz monitoring. Bezpieczeństwo hostingu nie opiera się na jednym programie, który ma „zrobić wszystko”. Poszczególne narzędzia odpowiadają za inne warstwy i wzajemnie się uzupełniają.

Kopie zapasowe i podstawowe mechanizmy bezpieczeństwa

Do zadań dostawcy należy również zapewnienie właściwych mechanizmów związanych z ciągłością działania usługi. W SEOHOST dostępne są m.in. kopie zapasowe, SSL, obsługa aktualnych wersji PHP i narzędzia pozwalające zarządzać aplikacjami z poziomu DirectAdmin.

To ważne również wtedy, gdy błąd nie ma nic wspólnego z atakiem. Nieudana aktualizacja, przypadkowe usunięcie pliku czy źle wykonana zmiana w konfiguracji potrafią być dla działającej strony równie problematyczne jak zagrożenie z zewnątrz.

• Dlaczego warto regularnie wykonywać backup danych hostingu?
• Softaculous – automatyczne aktualizacje, staging i kopie zapasowe aplikacji

Monarx Security jako jedna z kluczowych warstw ochrony hostingu SEOHOST

Do opisanych wyżej zabezpieczeń dołączyliśmy Monarx Security – system projektowany specjalnie z myślą o ochronie środowisk hostingowych i działających w nich aplikacji webowych. Według naszej wiedzy SEOHOST jako pierwszy polski dostawca hostingu wdrożył Monarx w swoim środowisku hostingowym.

Dlaczego zdecydowaliśmy się właśnie na takie rozwiązanie? Ponieważ klasyczne wykrywanie malware na podstawie plików i znanych sygnatur jest tylko jednym etapem ochrony. Współczesny atak może rozpocząć się od szkodliwego żądania, następnie wykorzystać znaną podatność w kodzie PHP, wykonać określoną operację, a dopiero później pozostawić złośliwy plik. Monarx pozwala obserwować i zabezpieczać kilka z tych etapów.

Poniżej możesz zobaczyć główne mechanizmy wykorzystywane w naszym środowisku:

Wspomniany virtual patching można więc potraktować jak tymczasową osłonę konkretnej, znanej podatności. Załóżmy, że producent popularnej wtyczki WordPressa publikuje informację o luce bezpieczeństwa. Zanim wszyscy właściciele stron zdążą zainstalować poprawioną wersję, automaty skanujące Internet już szukają instalacji podatnych na atak. Reguła virtual patching pozwala zablokować konkretny sposób wykorzystania takiej luki na poziomie ochrony runtime.

Nie zmienia jednak kodu wtyczki. Do tego potrzebna jest później normalna aktualizacja – i do tej kwestii jeszcze wrócimy.

Monarx działa automatycznie po stronie hostingu SEOHOST. Nie instalujesz go w WordPressie i nie musisz ręcznie uruchamiać kolejnych skanów. Szczegółowy zakres poszczególnych mechanizmów opisaliśmy w artykule Co obejmuje ochrona Monarx i co jest objęte skanowaniem?

Chcielibyśmy w tym miejscu podkreślić jeszcze jeden element. Standardowa ochrona Monarx nie wykonuje cyklicznego skanowania rekordów działającej bazy MySQL/MariaDB i nie pełni funkcji filtra poczty obsługującego ruch SMTP, IMAP czy POP3. Wynika to z przeznaczenia i architektury samego rozwiązania – Monarx koncentruje się na ochronie plików, aplikacji PHP i określonych elementów ruchu kierowanego do środowiska webowego.

Nie sprawia to, że cała usługa hostingowa zostaje bez ochrony w pozostałych obszarach. Monarx jest jedną z warstw większego systemu bezpieczeństwa, obok mechanizmów pocztowych, ochrony sieciowej, kopii zapasowych, SSL, CloudLinux, WAF/ModSecurity czy Anti-DDoS. Szczegóły dotyczące zakresu analizowanych informacji i prywatności opisaliśmy osobno w materiale Monarx a dane i prywatność.

Z jakimi zagrożeniami możesz spotkać się po swojej stronie i jak je ograniczyć?

Spójrzmy teraz na bezpieczeństwo z drugiej strony. Wiesz już, że środowisko hostingowe jest monitorowane, konta są od siebie izolowane, część niebezpiecznego ruchu zostaje odrzucona, a dodatkową ochronę aplikacyjną zapewnia Monarx. Jeżeli jednak Twój WordPress od dwóch lat korzysta z podatnej wtyczki albo były wykonawca nadal posiada konto administratora, źródło zagrożenia znajduje się już wewnątrz samej aplikacji lub wynika z tego, jak zarządzasz zawartością usługi. I właśnie te problemy są bardzo powtarzalne. Nie potrzeba hakera, który specjalnie wybrał Twoją firmę jako cel – wystarczy automat sprawdzający tysiące witryn i jedna podatność pozostawiona w wyniku braku aktualizacji, błędnej konfiguracji czy niepotrzebnie aktywnego dostępu.

W ramach hostingu SEOHOST masz również dostęp do Softaculous. Narzędzie pozwala zarządzać instalacjami popularnych CMS-ów, ustawiać automatyczne aktualizacje, tworzyć własne kopie bezpieczeństwa, klonować strony i przygotowywać środowiska stagingowe. Nie wszystkie czynności musisz więc wykonywać ręcznie.

• Zobacz, jak Softaculous pomaga zarządzać aktualizacjami, backupem i stagingiem.
• Jak skonfigurować własną kopię zapasową WordPressa w Softaculous?

Przyjrzyjmy się teraz najczęstszym problemom, na które masz bezpośredni wpływ.

Nieaktualny CMS, wtyczki i motywy

WordPress, PrestaShop, Joomla, Drupal i inne systemy CMS są stale rozwijane. Tak samo wyglądają wtyczki, szablony, biblioteki oraz dodatkowe komponenty. Aktualizacja nie zawsze wprowadza nową funkcję, którą zobaczysz w panelu. Bardzo często po prostu zamyka znalezioną wcześniej podatność.

Wyobraź sobie, że producent wtyczki wydaje wersję 5.2.4, ponieważ poprzednia pozwalała bez autoryzacji przesłać plik na serwer. Informacja szybko trafia do baz podatności. Od tej chwili wiedzą o niej nie tylko administratorzy stron, ale również autorzy automatów szukających właśnie tej konkretnej wersji dodatku.

Rozwiązanie jest proste: zaloguj się do swojego CMS-a, sprawdź dostępne aktualizacje rdzenia, wtyczek i motywów oraz usuń komponenty, które nie są już rozwijane. Przed większą aktualizacją wykonaj kopię zapasową, a jeśli strona jest istotnym elementem biznesu, sprawdź zmianę najpierw na stagingu.

• Dlaczego należy aktualizować WordPressa, wtyczki i motywy?
• Co to jest staging i dlaczego warto testować aktualizacje przed wdrożeniem?

Nieużywane i porzucone rozszerzenia

Nie korzystasz z wtyczki? Usuń ją. Samo dezaktywowanie komponentu sprawia, że WordPress nie uruchamia go standardowo podczas działania strony, ale jego pliki nadal znajdują się na koncie. Jeżeli dodatek zawiera niezależnie dostępny podatny skrypt albo jego rozwój został zakończony kilka lat temu, przechowywanie go „na wszelki wypadek” niczego Ci nie daje.

To samo dotyczy motywów. Nie potrzebujesz kilkunastu starych szablonów, które kiedyś testowałeś. Zostaw aktualnie wykorzystywany motyw i ewentualnie świadomie wybrany motyw zapasowy.

Zwróć też uwagę na datę ostatniej aktualizacji rozszerzenia. „Mam najnowszą wersję” nie zawsze oznacza „mam bezpieczną wersję”, jeżeli projekt został porzucony i nikt nie wydaje już poprawek.

Wtyczki i motywy z niezaufanych źródeł

Płatna wtyczka pobrana za darmo z przypadkowego serwisu, wersja „nulled”, zmodyfikowany motyw premium albo paczka przesłana na forum to nie oszczędność, którą warto testować na produkcyjnej stronie.

Nie masz pewności, co ktoś zmienił w takim archiwum. Złośliwy kod nie musi od razu uszkodzić witryny. Bardziej użyteczny dla atakującego jest niewidoczny backdoor, dzięki któremu może wrócić później, wysłać spam, zmodyfikować zawartość strony albo wykorzystać konto hostingowe do kolejnych działań.

Korzystaj z oficjalnego repozytorium, strony producenta lub innego źródła, którego pochodzenie jesteś w stanie zweryfikować. Jeżeli wtyczka jest płatna, aktywna licencja daje Ci nie tylko prawo do korzystania z programu, ale przede wszystkim dostęp do kolejnych aktualizacji.

Słabe hasła, brak 2FA i stare konta

Zastanów się przez chwilę, kto ma obecnie uprawnienia administratora Twojej strony. Ty, pracownik, obecna agencja – to oczywiste. A freelancer, który poprawiał formularz dwa lata temu? Poprzednia agencja? Były pracownik? Konto testowe utworzone przy wdrożeniu?

Każde dodatkowe konto z wysokimi uprawnieniami jest kolejnym sposobem uzyskania dostępu do aplikacji. Jeżeli nie jest potrzebne, usuń je lub ogranicz jego rolę. Włącz również 2FA wszędzie tam, gdzie jest dostępne, oraz korzystaj z unikalnych haseł zamiast jednego hasła powtarzanego pomiędzy kilkoma usługami.

• Czym jest 2FA i dlaczego warto korzystać z dodatkowej warstwy logowania?

Stare instalacje, katalogi /old/, /test/, archiwa ZIP i kopie baz

Aktualna strona może być zabezpieczona wzorowo, a obok niej na tym samym koncie od czterech lat działać zapomniana kopia w katalogu /old/. Do tego instalacja testowa w /test/, stary backup.zip po migracji i eksport bazy baza.sql, który miał zostać skasowany „za chwilę”.

Dla automatycznego skanera to kolejne pliki i adresy do sprawdzenia. Stara instalacja CMS-a nadal jest instalacją CMS-a, tylko bez aktualizacji.

Nie przechowuj ręcznych kopii zapasowych w publicznie dostępnych katalogach strony. Paczka ZIP lub plik SQL może zawierać kod strony, dane klientów, adresy e-mail, konfigurację aplikacji albo inne informacje, których nie chcesz udostępniać osobie przeszukującej serwer.

Jeżeli kopia jest Ci potrzebna, przechowuj ją w miejscu przeznaczonym do backupu. W SEOHOST możesz korzystać zarówno z kopii wykonywanych w ramach usługi, jak i samodzielnie konfigurować backup aplikacji, wysyłać go do zewnętrznej lokalizacji czy tworzyć staging przed większymi zmianami.

Chcesz mieć hosting z automatycznymi kopiami zapasowymi oraz narzędziami do tworzenia własnych backupów i stagingu? Wybierz hosting SEOHOST. Jeśli Twoja strona działa już u innego operatora, możemy również pomóc Ci ją przenieść w ramach bezpłatnej migracji hostingu.

Formularze, API i integracje

Strona coraz rzadziej działa całkowicie samodzielnie. Sklep łączy się z systemem płatności i kurierem, formularz wysyła dane do CRM-u, aplikacja korzysta z zewnętrznego API, a system marketingowy pobiera informacje o klientach.

Sprawdzaj więc nie tylko, czy dana integracja działa, ale również jakie posiada uprawnienia i czy nadal jest potrzebna. Klucz API wykorzystywany wyłącznie do pobierania produktów nie potrzebuje prawa do ich usuwania. Konto integracji, z której przestałeś korzystać rok temu, również nie powinno pozostawać aktywne bez powodu.

• Jak bezpiecznie przechowywać klucze API i dane dostępowe?
• Czym jest XML-RPC w WordPressie i kiedy warto go wyłączyć?

Uprawnienia plików i katalogów

Każdy plik i katalog ma określone uprawnienia. Aplikacja potrzebuje dostępu do odczytu swoich plików, a w wybranych miejscach również możliwości zapisu. Problem pojawia się wtedy, gdy uprawnienia są znacznie szersze, niż wymaga tego działanie strony.

Jeżeli przejęty skrypt może zapisywać dane praktycznie wszędzie, skutki podatności będą większe niż wtedy, gdy działa wyłącznie w ograniczonej przestrzeni. Dlatego warto stosować zasadę najmniejszych niezbędnych uprawnień – zarówno do plików, jak i baz danych czy integracji.

• Jak zmienić uprawnienia CHMOD plików i katalogów?

Dwie warstwy bezpieczeństwa – ochrona hostingu i usunięcie źródła podatności

W tym miejscu możemy połączyć obie części artykułu. Po stronie hostingu działają mechanizmy, które mają wykrywać, filtrować i zatrzymywać zagrożenia. Po stronie aplikacji nadal istnieje kod, konfiguracja i dostęp użytkowników, które trzeba utrzymywać w prawidłowym stanie. Najlepszy efekt otrzymujesz wtedy, gdy obie warstwy działają jednocześnie.

Dobrym przykładem jest wspomniany wcześniej virtual patching (wirtualne łatanie podatności). To element ThreatShield w Monarx, który pozwala przygotować ochronę przed wykorzystaniem konkretnej, znanej luki bez modyfikowania kodu samej aplikacji. Jeżeli np. zostanie wykryta krytyczna podatność popularnej wtyczki, reguła może blokować sposób jej wykorzystania również wtedy, gdy właściciel strony nie zdążył jeszcze przeprowadzić aktualizacji.

To bardzo cenna warstwa ochronna, bo pomiędzy opublikowaniem informacji o podatności a aktualizacją wszystkich stron zawsze istnieje pewien okres przejściowy. Docelowo nadal należy jednak zainstalować poprawkę producenta. Virtual patch ogranicza możliwość wykorzystania określonej podatności, ale nie zamienia starej wersji programu w nową.

Podobnie działa logika ochrony malware. Wspomniany wcześniej Active Protection pozwala Monarx automatycznie reagować na potwierdzone zagrożenie – np. złośliwy plik lub kod znajdujący się w chronionym środowisku. Jeśli jednak plik pojawił się dlatego, że atakujący cały czas posiada hasło administratora albo strona korzysta z podatnego dodatku, trzeba usunąć również samą przyczynę.

Blokada zagrożenia nie jest sygnałem, że podatność można pozostawić bez zmian. Jeżeli Monarx pokazuje zdarzenie związane z konkretnym komponentem, sprawdź, czy dostępna jest jego aktualizacja i czy dana funkcja jest Ci nadal potrzebna. Jeżeli nie wiesz, jak interpretować status, przeczytaj co oznaczają zdarzenia i blokady widoczne w Monarx.

Checklista bezpieczeństwa strony i hostingu – co możesz sprawdzić już teraz?

Cieszymy się, że dotarłeś do tego miejsca. Liczymy też, że podział pomiędzy bezpieczeństwem samej usługi hostingowej a bezpieczeństwem aplikacji jest teraz znacznie czytelniejszy. Jeżeli nadal masz pytania albo nie jesteś pewien, po której stronie znajduje się konkretny problem, zawsze możesz skontaktować się z naszym supportem. Poniżej zostawiamy ostatni praktyczny element – krótką listę rzeczy, które możesz zaplanować na najbliższy wolny wieczór czy weekend i sprawdzić na swoim koncie.

Jeżeli korzystasz z WordPressa, nie musisz wszystkiego konfigurować od początku własnymi metodami. W naszej bazie wiedzy znajdziesz również osobne zestawienie narzędzi zwiększających bezpieczeństwo WordPressa.

A co z bezpieczeństwem serwera VPS?

Przy VPS-ie zakres odpowiedzialności zależy od modelu usługi. Na hostingu współdzielonym to dostawca administruje systemem operacyjnym, konfiguracją głównych usług, częścią sieciową i zabezpieczeniami całej infrastruktury. Na samodzielnie administrowanym VPS-ie znaczna część tych zadań przechodzi na właściciela serwera.

Dochodzą wtedy aktualizacje systemu, konfiguracja SSH i firewalla, kontrola działających usług, kont systemowych, logów, serwera WWW, PHP oraz baz danych. To osobny zakres, dlatego nie próbujemy wciskać go do checklisty przeznaczonej dla zwykłego użytkownika hostingu współdzielonego.

• Dowiedz się więcej o monitorowaniu i zabezpieczeniu serwera VPS.

Hosting zabezpiecza środowisko. Ty zabezpieczasz swoją aplikację

Jak widzisz, istnieje wyraźna granica pomiędzy bezpieczeństwem samej usługi hostingowej a bezpieczeństwem jej zawartości. My jako usługodawca zajmujemy się infrastrukturą, jej stabilnością, monitoringiem oraz wdrażaniem kolejnych mechanizmów, które ograniczają ryzyko dla stron działających na naszych serwerach. Ty masz największy wpływ na aplikację, którą instalujesz: jej aktualność, konta użytkowników, dodatki, integracje i sposób zarządzania dostępem.

Nie zostawiamy Cię z tym jednak samego. Jeżeli nie wiesz, czy problem wynika z hostingu, konfiguracji WordPressa, wtyczki czy innego elementu, zawsze możesz skontaktować się z naszym zespołem. Nawet jeżeli dana czynność wymaga działania po Twojej stronie, możemy pomóc wskazać miejsce, od którego warto rozpocząć diagnostykę.

Cały czas rozwijamy również warstwę, za którą odpowiadamy my. Internet się zmienia, pojawiają się nowe automaty, nowe podatności, kolejne sposoby wykorzystywania zainfekowanych stron i coraz większa liczba masowych skanów wykonywanych bez wyboru konkretnego celu. Większość takich zdarzeń jest zwyczajnym tłem funkcjonowania publicznej sieci, a nie osobistym atakiem na Twoją firmę czy konkretną firmę hostingową. Automat nie musi wiedzieć, kim jesteś. Wystarczy, że znajdzie adres, aplikację i podatność, której potrafi użyć.

Od tego są administratorzy, monitoring i kolejne warstwy ochrony: żeby infrastruktura była przygotowana również na problemy, które dopiero zaczynają przybierać na skali. Niezależnie od tego, czy utrzymujesz rozbudowany sklep, firmową stronę, mały blog czy kilka skrzynek pocztowych, sama usługa powinna być chroniona w ten sam sposób.

Szukasz hostingu z wielowarstwową ochroną i Monarx Security? Wszystkie plany hostingu SEOHOST korzystają z naszej infrastruktury bezpieczeństwa, a usługę możesz sprawdzić w ramach okresu testowego. Jeśli obecnie korzystasz z innego operatora, nie musisz samodzielnie przenosić stron, baz danych i poczty – sprawdź również bezpłatną migrację hostingu do SEOHOST.