Zabezpieczenia WordPress, pomimo tego co sądzi większość użytkowników, nie są takie trudne i zaraz się o tym przekonasz. Zadbanie o podstawowy poziom zabezpieczenia jest proste, jednak przy każdych zmianach należy zachować czujność i zdrowy rozsądek. Jako dostawca szybkiego hostingu dla WordPress czujemy się zobowiązani do stałego podpowiadania Ci, co możesz zrobić dla bezpieczeństwa Twojej strony. Konfigurację zabezpieczeń WordPress ułatwi Ci to niniejszy artykuł.
Zabezpieczenia WordPress. Podstawy i dobre praktyki.
Długo się zastanawiałem, czy w ogóle ten temat poruszyć… jednakże codzienne obserwacje zachęcają do uwzględnienia podstaw. Choć specjaliści ds. bezpieczeństwa kierują uwagę użytkowników na ten problem, wielu wciąż upiera się przy stosowaniu łatwej kombinacji loginów i haseł (np. login: admin, hasło: Kolega12).
Niemal każdy z nas, chociaż raz w życiu posiadał proste hasło: jedno lub dwa słowa, bez znaków specjalnych. To normalne, że staramy się mieć hasło, które łatwo nam zapamiętać, ale… Skoro jest ono łatwe dla nas, z pewnością będzie proste do odgadnięcia także dla potencjalnego hakera. Ktoś inny jest w stanie zapamiętać nasze zabezpieczenia w bardzo prozaiczny sposób, np. podglądając nas zza ramienia, albo przy wykorzystaniu Brute-Force. Dana osoba może próbować odgadnąć hasło i w rezultacie trafi. Zabezpieczenia WordPress, które wprowadzisz, muszą przewidywać taką sytuację.
Chcesz w łatwy sposób stworzyć bezpieczne, silne hasło? Skorzystaj z naszego generatora haseł – kilka chwil i masz hasło nie do złamania!
Hasła i szyfrowanie połączeń jako elementy zabezpieczenia WordPress
Tylko oryginalne nazwy użytkownika i mocne hasła są w stanie podnieść poziom bezpieczeństwa. Nazwy typu: admin, administrator, webmaster, postmaster, <tutaj_nazwa_strony>, czy user powinien zostać wykluczone. Zadbajmy o to, bo inaczej ktoś szybko wykorzysta nasze niedopatrzenie.
Dodatkowo przypominam o szyfrowaniu połączeń. W czasach, gdy koszt certyfikatu to kilkanaście złotych, nie warto oszczędzać na sprawdzonych rozwiązaniach. Certyfikat SSL jest uwiarygodnieniem dla serwisu i zabezpieczeniem strony przed atakiem Man in the middle.
Certyfikat SSL to jedna z fundamentalnych spraw, kiedy myślisz o zabezpieczaniu formularza w WordPress. Nie ochroni wprawdzie przed spamem przez formularz, ale dzięki niemu dane podane w formularzu pozostają poufne „w trasie” między przeglądarką użytkownika a serwerem. Zabezpieczenia WordPress nie mogą być uznane za kompletne bez certyfikatu SSL!
Bogate i jednocześnie słabe wsparcie
Zacznijmy od początku… Jaki jest najczęstszy powód infekcji, które się pojawiają na WordPress’ie i na każdym popularnym systemie CMS (takim jak np.: Joomla)? Brak aktualizacji oraz korzystanie z dodatków (wtyczek), które zostały porzucone przez twórców.
W celu zobrazowania sytuacji, przyjrzyjmy się wtyczce: “Steam Widget”. Jak widać – wtyczka jest aktualna po instalacji. Zabezpieczenie, które WordPress’a rozumiane jako aktualizowanie wtyczek – jest spełnione, niby wszystko ok, trzeba jednak zwrócić uwagę na datę ostatniej aktualizacji:
Wtyczka została ostatni raz zaktualizowana ponad 3 lata temu. Dodatkowo na stronie wtyczki pojawia się wielki banner:
Jak widać – sam WordPress informuje, że wtyczka może być porzucona i nie wspierana. Twórca wtyczki nawet pewnie nie ukrywa faktu, że ta została porzucona. Mimo to nie została ona usunięta z bazy wtyczek, dodatkowo jest instalowana przez właścicieli wielu aplikacji – a to jedna z wielu dróg możliwego zainfekowania. Jak widać na powyższym przykładzie, by zabezpieczyć WordPress, nie wystarczy jedynie bieżąca aktualizacja. Istotny jest również rozważny dobór wtyczek.
Zabezpieczenia WordPress muszą zatem obejmować pilnowanie aktualności wtyczek. Ok, pilnujemy wtyczek – o czym jeszcze musimy pamiętać?
Automatyczne aktualizacje i ich rola w zabezpieczeniach WordPress
Zalecam zautomatyzować wszystko. Na początek może uruchomimy aktualizacje samego WordPress’a? Jest to bardzo proste, gdyż wystarczy w pliku wp-config.php dodać wpis:
define( 'WP_AUTO_UPDATE_CORE’, true );
Można go dodać praktycznie w każdym miejscu, więc nie powinno to sprawiać problemu. Od teraz aktualizacje WordPress będą prowadzone automatycznie. Jedna czynność została już zautomatyzowana. Teraz zajmijmy się aktualizacjami wtyczek, stylów oraz tłumaczeń.
W folderze wp-content/mu-plugins/ tworzymy plik (może się nazywać np.: aktualizacja.php) i wrzucamy tam następujący wpis:
<?php
add_filter(’auto_update_plugin’, '__return_true’ );
add_filter(’auto_update_theme’, '__return_true’ );
add_filter(’auto_update_translation’, '__return_true’ );
MU Plugins pozwala dodać funkcjonalności, które zawsze muszą zostać wywołane i są niezależne od stylu lub wtyczki. Od momentu dodania tego pliku, wszystkie dodatki będą aktualizowane automatycznie i nie trzeba pilnować, by te aktualizacje były wykonywane. Ważnym też jest, by usuwać wtyczki, których nie wykorzystujemy. Pomimo ich “wyłączenia” w panelu strony, w formie kodu są dalej obecne i dalej mogą stanowić niebezpieczeństwo dla naszej strony WWW.
Dodatkowo ukryjmy wersję WordPress’a. Nawet jeśli z jakiegoś powodu aktualizacja nie zostanie wykonana, atakujący nie będzie do końca tego świadom.
Zabezpieczenia WordPress na wypadek awarii na serwerze
Mamy już automatyczne aktualizacje. Czy to oznacza, że nie musimy się już niczym martwić? Nic bardziej mylnego. Jest jeszcze wiele innych miejsc, gdzie może dojść do infekcji lub wycieku danych, np. w trakcie awarii. W sytuacji, gdy pojawi się awaria interpretera PHP, pliki mogą nie być wykonywane, a zwyczajnie wyświetlone. W takiej sytuacji każdy będzie miał dostęp do kodu strony z dowolnej przeglądarki. Zabezpieczenia WordPress powinny to zatem uwzględniać.
Tak się szczęśliwie składa, że hosting dla WordPress z naszej oferty bardzo dobrze odpowiada na tego rodzaju zagrożenia. Kopia zapasowa bazy, a więc tych danych, które zmieniają się najczęściej, jest wykonywana co 6 godzin, a kopia plików i poczty raz na dobę. Zdumiewające są także czasy przechowywania danych w kopii zapasowej – są one dostępne aż do 28 dni wstecz!
Backup WordPress
Istnieją co najmniej 3 powody, dla których warto wykonywać regularnie kopie bezpieczeństwa Twojego WordPress’a.
- Ryzyko uszkodzenia WordPress w wyniku ataku na stronę.
- Możliwość, że Ty popełnisz błąd i np. skasujesz albo nadpiszesz ważny plik.
- Niewielkie prawdopodibieństwo, że w firmie hostingowej dojdzie do awarii.
Dlatego właśnie gorąco zachęcam Cię do zapoznania się ze specjalistycznym artykułem Artura Pajkerta: Backup WordPress – jak robić to dobrze.
Dane logowania do bazy ochronione
To groźna sytuacja, choć jeszcze nie tragiczna. WordPress jak i wtyczki/style w repozytorium są dostępne dla każdego, więc w praktyce kod strony jest powszechnie znany. Jednak cenniejszym od samego kodu strony jest jej baza. Dane logowania do bazy w takiej sytuacji również mogą być dostępne dla każdego. Wtedy może dojść do wycieku, a wtedy… hasła, loginy, e-mail’e, dane klientów, koszyk, listy artykułów – wszystko będzie dostępne dla każdego.
Konieczne jest zabezpieczenie dostęp do pliku, gdzie przechowywane są wrażliwe dane dostępowe. Takim plikiem jest wp-config.php, który zawiera konfigurację WordPress’a. Dobrym rozwiązaniem będzie dodanie do pliku .htaccess wpisu:
<Files .htaccess wp-config.php>
order allow,deny
deny from all
</Files>
Powyższy wpis pozwoli na uniemożliwienie dostępu do pliku, nawet w razie awarii interpretera.
Pomysł ochronę na wp-config.php w WordPress
Wiele automatycznych ataków wymierzonych w WordPress próbuje „dobrać się” do zawartości pliku wp-config, ponieważ z niego bezpośrednio można wyciągnąć dane dostępowe do bazy.
Nic nie stoi jednak na przeszkodzie umieszczenia tych danych w osobnym pliku, który byłby jedynie inkludowany w wp-config. Oczywiście wprawny programista natychmiast się zorientuje, gdzie szukać danych, ale automatyczne ataki w większości nie dadzą atakującym potrzebnych informacji.
Pamiętaj, aby ten plik także chronić przed bezpośrednim odczytem poprzez odpowiedni wpis do .htaccess.
Wyłączanie edytora plików
Pilnowanie wtyczek, automatyczne aktualizacje i powoli nasza strona zaczyna być zabezpieczona, jednak nie warto spoczywać na laurach i zadbać o dodatkowe elementy. Załóżmy hipotetyczną sytuację, że nasze hasło w jakiś sposób wyciekło i aktualnie ktoś ma dostęp do strony. W zakładce Wygląd > Edytor posiadamy interesującą funkcjonalność, która polega na możliwości edytowania stylu strony (łącznie z kodem) z poziomu samego WordPress’a. To bardzo przydatne narzędzie, ale tylko podczas tworzenia strony. Na tzw. produkcji – tej funkcjonalności lepiej nie posiadać. Bezpieczniej zatem usunąć taką funkcję, tak aby ograniczyć możliwość manipulacji. W tym celu ponownie wracamy do pliku wp-config.php i dodajemy kolejny zapis (np.: pod naszym wpisem z aktualizacjami). Jest to prosty wpis: define(’DISALLOW_FILE_EDIT’, true);
Od tego momentu edytor jest wyłączony, bez ingerencji w główny trzon aplikacji. Nawet jeśli w przyszłości trzeba będzie coś zmienić, można za pomocą FTP edytować pliki (tutaj zalecam nie korzystać z samego FTP, ale z sFTP jeśli dostępny lub ewentualnie FTPS – szyfrowaną wersję FTP) bądź przygotować automatyczną aktualizacje stylu.
Zabezpieczanie WordPress – co z plikami?
Warto również pomyśleć o zabezpieczeniu innych plików, które nie są użyteczne dla standardowego użytkownika, a pozostają świetnym źródłem informacji dla ewentualnego włamywacza. Katalogi wp-includes i wp-admin/includes posiadają w sobie pliki, które warto zablokować, a robimy to za pomocą np.: poniższego wpisu w .htaccess:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^wp-admin/includes/ – [F,L]
RewriteRule !^wp-includes/ – [S=3]
RewriteRule ^wp-includes/[^/]+\.php$ – [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php – [F,L]
RewriteRule ^wp-includes/theme-compat/ – [F,L]
</IfModule>
Ochrona przed przesłanymi plikami jako element zabezpieczania WordPress
Kolejnym katalogiem gromadzącym pliki, które będzie można wykorzystać do zainfekowania naszej strony jest katalog, gdzie umieszczane są wszystkie przesłane pliki. Bardzo częstą praktyką jest posiadanie na stronie formularza. Niezależnie, czy jest to formularz zamówień, czy kontaktowy – możemy w nim umieścić możliwość wysyłki pliku. Może to być obrazek, może nawet jakiś dokument. Tylko, co się stanie, gdy ktoś wykorzysta formularz, w celu umieszczenia skryptu na serwerze?
Niestety, źle zabezpieczone formularze dopuszczają do takich sytuacji. Nawet te potencjalnie chronione – potrafią posiadać jakąś podatność. Możemy kombinować z formularzem, dodawać kolejne zabezpieczenia, weryfikację zawartości, typu MIME, skanować jakimś antywirusem, wykonywać naprawdę sporo czynności. Jednak to wymaga czasu, środków i świadomości problemu. Nawet największe firmy z branży IT mają na swoim koncie wpadki, zatem jak się skutecznie chronić?
Blokada wykonywania plików PHP
WordPress jest aplikacją stworzoną w języku PHP i tak samo – po stronie serwera – wykonywany jest kod, który ostatecznie wyświetla nam stronę. Skoro PHP jest uruchamiane, to możemy wysłać plik PHP, który również można uruchomić na serwerze. Może warto zablokować wykonywanie plików PHP po stronie serwera? Przynajmniej dla plików przesłanych przez formularz?
<Files *.php>
deny from all
</Files>
Powyższy kod zablokuje wykonywanie plików o rozszerzeniu *.php na serwerze i taki plik .htaccess należy dodać do katalogu wp-content/uploads/. Teraz nawet w przypadku przesłania pliku PHP na serwer, atakujący nie wykona kodu. Co prawda, samo przesłanie pliku nie jest zbytnio wyrafinowanym atakiem. Łatwo go wykryć i stosunkowo łatwo się przed nim zabezpieczyć. Większym wyzwaniem jest zabezpieczenie przed tzw. Code injection. Tutaj trzeba się bardziej pilnować, ale jest rada, która częściowo pozwala na zabezpieczenie strony. Polecam ponownie udać się do naszego głównego pliku .htaccess w głównym katalogu strony i do niego dodać poniższy wpis:
Options +FollowSymLinks
RewriteEngine On
RewriteCond %{QUERY_STRING} (<|%3C).*script.*(>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|[|%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|[|%[0-9A-Z]{0,2})
RewriteRule ^(.*)$ index.php [F,L]
Zabezpieczenie WordPress – blokada dostępu do panelu administracyjnego
Następne zabezpieczenie, to ochrona naszego panelu administracyjnego. Można sporo namieszać przez panel. Skoro i tak dostępu nie dajemy dla każdego, bo to nasz panel administracyjny – to po co go udostępniać na świat? Jest na to wiele sposobów, jednak dobrym pomysłem będzie zablokowanie dostępu tylko dla adresów IP z których my się łączymy. Jeśli mamy zmienne IP, zawsze możemy też dodać całą pulę adresową naszego dostawcy internetu. Przykładowy zapis:
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_URI} ^(.*)?wp-login\.php(.*)$ [OR]
RewriteCond %{REQUEST_URI} ^(.*)?wp-admin(\/)$ [OR]
RewriteCond %{REQUEST_URI} ^(.*)?wp-admin/$
RewriteCond %{REMOTE_ADDR} !^200\.200\.200\.200$
RewriteRule ^(.*)$ – [R=403,L]
</IfModule>
Oczywiście, trzeba ten zapis dostosować pod siebie, więc zalecam tą opcję jedynie dla doświadczonych webmasterów.
Wtyczki zapewniające bezpieczeństwo WordPress
Na sam koniec zostawiam temat wtyczek “zapewniających” bezpieczeństwo. Popularne wtyczki, takie jak WordFence nie mogą zagwarantować 100% bezpieczeństwa. Przecież same są przykładem miejsca, gdzie można się włamać. W końcu im więcej dodatków, tym więcej możliwych dróg nieautoryzowanego dostania się do strony. Oczywiście – ich celem jest zwiększenie bezpieczeństwa – i często spełniają swoją rolę. Sam mogę polecić wtyczki takie jak Cerber, czy Sucuri. Jednak nie warto na nich polegać w 100%, jako vademecum na wszystkie problemy bezpieczeństwa.
Wtyczka do bezpieczeństwa WordPress
Wtyczka do bezpieczeństwa WordPress to dyskusyjny pomysł. Poczynając od wydajności, a kończąc na tym, że wtyczki te często same w sobie stanowią większy kawałek kodu i tym samym – możliwą podatność. Osoby bez żadnej wiedzy technicznej, mające wybór między nie robieniem niczego, a stosowaniem takiej wtyczki – najczęściej wybiorą wtyczkę. Gorąco zachęcam jednak do samodzielnego konfigurowania zagadnień, związanych z bezpieczeństwem wszędzie, gdzie to możliwe. Żadna z opcji opisanych w tym artykule nie tworzy dodatkowych podatności, ponieważ nie wprowadzają one nowego kodu, który mógłby być źródłem takowej.
Zabezpieczenia WordPress – obsługa formularzy
Zabezpieczenia WordPress pod kątem formularzy częściowo poruszyłem już wcześniej, pod kątem certyfikatu SSL czy ochrony strony logowania. Natomiast pozostaje dość obszerne zagadnienie ochrony formularzy „normalnych”, przeznaczonych dla użytkowników, np. takich związanych z komentowaniem albo rejestracją w serwisie.
Pokrótce można powiedzieć, że tego typu formularze są narażone na wiele różnych czynników ryzyka:
- podanie niepełnych danych
- podanie fałszywych danych
- spamerskie komentarze w celu pozyskania linków
- floodowanie – zapchanie formularza przez boty wieloma zgłoszeniami w krótkim czasie
- spam mailowy, obniżający reputację Twojej domeny (jeśli formularz podłączyłeś pod wysyłkę mailową).
Jeśli interesuje cię zabezpieczenie formularzy WordPress, to polecam wpis Artura Pajkerta o bezpieczeństwie formularza WordPress, ponieważ jest to zagadnienie dość obszerne.
Zabezpieczenia WordPress wdrożone, a jednak udało się włamać, co teraz?
Nie wszystko da się przewidzieć i nie przed każdym zdarzeniem da się uchronić. Kopie bezpieczeństwa to kwestia priorytetowa. Kopia zapasowa ratuje nas, nie tylko przed konsekwencjami ewentualnej infekcji, ale również w przypadku problemów ze stroną.
Popularne powiedzenie mówi, że ludzie dzielą się na 3 grupy:
- tacy, którzy robią kopie zapasowe,
- co myślą, że robią kopie,
- którzy zaczną robić kopie.
W przypadku infekcji, dzięki regularnym backupom łatwo możemy ją przywrócić do stanu sprzed ataku. Usuwamy wszystko i przywracamy z kopii. Kopie można wykonywać także samodzielnie. Własne kopie zapasowe będą dodatkowym wsparciem dla zabezpieczeń oferowanych przez firmy hostingowe. Taka metoda usuwania wirusów ze strony WordPress jest bardzo skuteczna i można zlecić to firmie, która zajmuje się takimi usługami.
Wspominając też o hostingach – większość z nich prowadzi kopie zapasowe, ale nie wszystkie robią to równie dobrze, jak cyber_Folks. Dobry hosting dla WordPress zawsze dba też o bezpieczeństwo swoich klientów, co sporo upraszcza. Pamiętaj, aby stawiać na taki, który kopie wykonuje codziennie lub częściej i przechowuje je możliwie długo. Dobrze, jeśli kilka tygodni. Istotne jest też to, że możesz przywracać je samodzielnie, bez konieczności kontaktu ze wsparciem technicznym.
Mimo wszystko – zalecam tworzyć własne kopie. Tygodniowe, miesięczne, kwartalne i trzymać w domowym zaciszu, a najlepiej na zewnętrznym, szyfrowanym dysku. Może i to czasem na wyrost, ale jednak – przezorny zawsze ubezpieczony.
Dotarliśmy razem do końca wpisu. Mamy nadzieję, że uważasz tę wiedzę za przydatną. Będzie mi miło, jeśli się nią podzielisz w sieciach społecznościowych i zostawisz komentarz poniżej.
Witam,
warto też zaglądać np. na takie strony jak ta: https://perishablepress.com/6g/
czy jeszcze od czasu do czasu sprawdzać swoje zabezpieczenia WP wtyczką: https://pl.wordpress.org/plugins/security-ninja/
Korzystać z kilkuetapowego logowania np.: https://www.miniorange.com/2-factor-authentication-for-wordpress, a przedtem z prostej autoryzacji innym loginem i hasłem na serwerze, itd.
Choć oczywiście pomysłów na zabezpieczenia jest bardzo wiele…
Zastanawiam się jednak dlaczego pomimo istnienia tylu sposobów, deweloperzy WP nie zaimplementowali w samym silniku przynajmniej tych najlepszych/najskuteczniejszych – przecież dla ogromnej większości zwykłych użytkowników byłoby to wybawieniem z potencjalnych problemów z WP?
Czy programiści i projektanci WordPress’a celowo zostawili takie „dziury” w swoim produkcie, aby zarabiać na wtyczkach zabezpieczających?
I jeszcze jedno…
Ten wpis powstał na stronie firmy hostingowej, więc nasuwa się pytanie czy dla tych użytkowników, którzy korzystają tu z WordPress’a zapewniacie jakieś, być może nawet dodatkowo płatne, zabezpieczenia lub czy zobowiązujecie użytkowników do stosowania jakichś minimalnych waszym zdaniem koniecznych zabezpieczeń, tak aby awaria/przeciążenie na jednym blogu u jakiegoś użytkownika nie wpływała na strony innych użytkowników na dzielonych serwerach? Przy WordPressie można by żądać wręcz stosowania pewnych wpisów w .htaccess i dodatkowych metod zabezpieczania blogu uznanych z ogólnie zalecane i sprawdzone.
Problemy z blogiem jednego klienta nie wpływają na działanie innych klientów ze względu na odpowiednią separację użytkowników. Natomiast jako firma hostingowa jak najbardziej dostarczamy dodatkowych możliwości. Stosujemy systemy WAF dla wyłapania popularnych ataków, w pakietach hostingu WordPress znajduje się bezpłatny audyt bezpieczeństwa, a do naszej oferty włączamy stopniowo produkty zwiększające bezpieczeństwo, jak AutoUpdater, pozwalający łatwo zachować aktualność strony.
czy to polecenie nie musi być domknięte?
<?php
add_filter(‚auto_update_plugin’, ‚__return_true’ );
add_filter(‚auto_update_theme’, ‚__return_true’ );
add_filter(‚auto_update_translation’, ‚__return_true’ );
???
wg mnie powinno być tak
pytam dlatego, ze osoby ktore maja pojecie o programowaniu dodadza to, a Ci co nie… no coż
Domykanie jest dyskusyjne. Jeśli domyka się prawidłowo i ma się 100% pewności, że tak się zawsze zrobi, to można domykać, ALE serwer generalnie sam to sobie domknie, natomiast jeśli domykamy ręcznie, a potem omyłkowo jakieś znaki znajdą się po domknięciu – to może się okazać, że one zepsują działanie strony. Przykładowo, jeśli kod wykonywany w dalszej kolejności miałby wykonać przekierowanie funkcją header(’Location… ’) to nie powiedzie się ono, jeśli na ekranie wcześniej zostaną wydrukowane znaki. Może tak się zdarzyć, kiedy po domknięciu poprzez ?> znajdzie się jeszcze jakiś np. biały znak (czyli niewidoczny normalnie na ekranie, ale liczony już jako znak przekazany przeglądarce). Wiele frameworków wręcz zaleca, żeby nie domykać. Ciekawa dyskusja na ten temat jest tutaj: https://stackoverflow.com/questions/4410704/why-would-one-omit-the-close-tag
Tutaj zgodzę się z Arturem, że dodawanie tagu zamykającego to proszenie się o proste, trudne do zauważenia błędy. To samo zachowanie interpretera zauważymy dodając jakikolwiek (nie tylko biały znak) przed otwarciem tagu PHP, a następnie już w logice aplikacji próbując zmienić zawartość nagłówków. Według interpretera, skoro zamieściliśmy treść body – czyli ten znak przed otwarciem – to wysyłamy już treść i nie będziemy przesyłać zmienionych headerów.
Analogicznie jest z zamykającym tagiem, przy tym, że dobrą praktyką jest nie dodawanie tagu i łatwo pozwala uniknąć podstawowych błędów podczas programowania w aplikacjach w języku PHP.
Np.: w Python dobrą praktyką jest pozostawienie ostatniej linii pustej (lub dodanie takiej) i to też chroni przed błędami, gdyż koniec pliku nie jest również końcem linii programu i w bardzo specyficznych warunkach – nie zgłosił błędu lub podania błędnego wyniku. Przypominam, że wcięcia są w Python ważne.
W zasadzie to jedna dobra wtyczka bezpieczeństwa może rozwiązać dużo tych problemów. Choć dobrze jeszcze ręcznie nanieść zmiany. Świat teraz zepsuty i nie można otwierać drzwi bo zaraz okradną dom jakim jest strona. Dobra wtyczka to przykładowo all in one seciurity i firewall do wordpress.
Problem z wtyczkami jest taki, że taka „dobra wtyczka”, która to wszystko robi może mieć luki bezpieczeństwa i dodatkowo narażać na ataki.
’ Warto również pomyśleć o zabezpieczeniu innych plików, które nie są użyteczne dla standardowego użytkownika’ czy po blokadzie dostępu do htaccess, my jako admin będziemy mieli do nich dostęp?
Wszystko jest zależne jak zablokujesz i co chcesz blokować. W przypadku plików w wp-includes nie łączysz się do nich bezpośrednio z poziomu swojej przeglądarki, więc .htaccess na spokojnie może zablokować tam ruch z zewnątrz – ruch w aplikacji jednak będzie przebiegać bez przeszkód.
Ciekawe porady, dzięki! Od siebie dodam, że czasem jednak edycja szablonu z poziomu edytora WP bywa konieczna, np. gdy pojawia się jakaś awaria, a mamy do dyspozycji tylko smartfon.
Nie wspomnieliście o tym żeby plikami wordpressa zarządzac z innegi uzytkownika niż użytkownik serwera www. Nie może dojść do sytuacji że serwer www jest w stanie modyfikować kod aplikacji.
Świetny wpis, dzięki za informacje! W tym tygodniu na pewno wdrożę w życie którąś z porad. Na razie zainstalowałem wtyczkę Dupilikator w ramach backupu danych, ale chcę się też zabezpieczyć przed włamem na stronę
Ludzie dzielą się na tych co robią backupy i tych którzy będą mieli włam/stratę danych i będę robili backupy. Dopiero po włamie na jedną z moich stron zacząłem interesować się bezpieczeństwem. Dzięki za soczysty w wiedzę artykuł.
Warto zaktualizować artkuł – „Sam mogę polecić wtyczki takie jak Cerber (…)” – https://www.wordfence.com/threat-intel/vulnerabilities/wordpress-plugins/wp-cerber. No właśnie, tak to jest z tymi wtyczkami…
Przy okazji tu trafiłem ale artykuł mnie zaciekawił więc dorzucę swoje 3 grosze. Dobry pomysł to użycie GIT do kontroli wersji i analizy co się stało i co zostało podmienione w systemie plików na stronie przez atakującego już po fakcie. Często na hostingach z dostępem do shella mamy możliwość użycia tego narzędzia. Zwykle przełamanie zabezpieczeń nastąpiło dużo wcześniej niż późniejsze działanie i możemy już nie dysponować backupem systemu plików (retencja backupów na hostingu). Oczywiście możemy na nowo poskładać wordpressa i wtyczki albo użyć właśnie gita do cofnięcia zmian nieautoryzowanych przez nas, które nie zostały zatwierdzone (commit).
Zatwierdzamy co jakiś czas jak wykonyjemy update Core WordPress lub przeglądamy czy zmiany to tylko automatyczny update wtyczek/theme. Dobrze też użyć starego dobrego rsynca i regularnie zrzucać jakieś dumpy baz MySQL w inne miejsce by mieć jakieś archiwalne (czyste) bazy do poskładania. W bazie też można umieścić zmiany, które pojawią się na stronie podczas jej renderowania, a dostęp do FS = dostęp do wszystkiego.
Wasz artykuł pomógł mi częściowo uporządkować zabezpieczenia w WordPressie. Będę kontynuował pracę nad nimi inspirując się właśnie tym wpisem!