Tym razem będzie o zabezpieczaniu, ale spokojnie – nie będę prawić tutaj morałów na temat współżycia : P Mowa będzie o zabezpieczaniu strony na WordPress przed włamaniami, atakami brute force, malware i innymi świństwami, które mogą nam wleźć na stronę. Jak w życiu tak i kwestiach bezpieczeństwa WP nie ma 100% ochrony, ale można zniwelować ryzyko stosując się do kilku zasad, które opiszę poniżej.
Od razu na wstępie mówię, że nie będzie nic na temat wtyczek – no może kilka słów, ale nie w kontekście jakich używać. Jakiś czas temu na jednej z grup zostałam za to nieco zlinczowana, że jak to tak bez wtyczek. Ano tak to. Każda wtyczka to potencjalne zagrożenie – szczególnie jak się instaluje “dla testów” wtyczki z mało legalnych źródeł, albo chociażby nie aktualizuje wtyczek na bieżąco. Dużo osób poleca Wordfence – niby fajna, ale jakiś czas temu miała dziury i zamiast chronić, wpuszczała “szkodniki” na stronę. Tak, więc mam do niej ograniczone zaufanie 😉
No to czas na bezwtyczkowe sposoby na zwiększenie bezpieczeństwa strony postawionej na systemie WordPress. Z pewnością nie wyczerpię tematu, ale liźniecie nieco podstaw, dzięki którym Wasza strona stanie się bezpieczniejsza.
ODPOWIEDNIO DOBIERAMY HOSTING
Poczytajcie opinie o hostingach pod względem ich bezpieczeństwa. Współdzielone hostingi, w których do tego nie ma separacji serwisów, mają to do siebie, że łatwo pomiędzy stronami mogą przechodzić różne świństwa. Warto więc rozważnie wybrać hostingodawcę 🙂
NIE UŻYWAMY LOGINU ADMIN
Jaki jest najczęściej wybierany podczas instalacji WordPressa (zresztą nie tylko WordPressa) login? admin. Jakiego loginu jako pierwszego przy włamaniu na stronę próbuje haker? admin. Jaki z tego morał? Stosować mniej oczywistą nazwę użytkownika, który ma uprawnienia administratora.
STOSUJEMY SKOMPLIKOWANE HASŁA
Bardzo często by łatwo zapamiętać stosujemy banalne hasło jak qwerty123. Głupota. W połączeniu z niemniej ambitnym loginem admin otwieramy drzwi na oścież hakerom. Nie żartuję. Kiedyś obserwowałam sobie (haa w Wordfence) jak jakieś ruskie raz za razem próbowały wleź na stronę wpisują zestawienie admin / qwerty123, admin / aaa123. Tak, więc wybierajcie bardziej skomplikowane hasła, najlepiej by zawierały i wielki i małe litery, a także znaki specjalne i liczby. Jeszcze jednak uwaga – nie dawajcie tego samego hasła do panelu WordPress, do bazy danych, jako hasło do ftp lub innego powiązanego z Waszą witryną miejsca. I ostatnia rada związana z hasłami – do wszystkich miejsca powiązanych ze stroną dawajcie trudne hasła. Aaa i jeszcze jedno – to już ostatnie – nie zapisujcie haseł w przeglądarce 😉
AKTUALIZUJEMY MOTYWY, WTYCZKI I SAMEGO WORDPRESSA
Często o tym zapominamy, choć jak byk po wejściu w panel WP widać komunikaty o nie zaktualizowanych elementach strony. Kliknijcie te aktualizacje. To zajmuje kilka minut, a może Wam uratować tyłek. UWAGA: przed przystąpieniem do aktualizacji warto sobie zrobić backup strony – są sytuacje, że coś może pójść nie tak, szczególnie jak dłuższy czas się czegoś nie aktualizowało i nagle przeskoczyć chce się kilka wersji wyżej.
USUWAMY NIEUŻYWANE I ZBĘDNE WTYCZKI ORAZ MOTYWY
Często testujemy różne motywy i wtyczki, które potem sobie leżą nieaktywne lub aktywne, ale i tak nieużywane. Zróbcie przegląd zbędnych dodatków i usuńcie niepotrzebne. Będzie i bezpieczniej i lżej, a przy okazji zrobi się więcej miejsca na serwerze 🙂
KORZYSTAMY WYŁĄCZNIE Z ZAUFANYCH ŹRÓDEŁ WTYCZEK I MOTYWÓW
Nie instalujcie wtyczek / motywów z przypadkowych źródeł, tym bardziej nielegalnych. Pomijając aspekt prawny, wiele takich dodatków zawiera w bonusie wirusy.
WYŁĄCZAMY MOŻLIWOŚĆ REJESTRACJI PRZYPADKOWYCH OSOBNIKÓW
Jeśli nie jest Ci potrzebna opcja rejestracji użytkowników – wyłącz ją. Można tego dokonać w Ustawienia – Ogólne i podpunkt Członkostwo.
INSTALUJEMY CERTYFIKAT SSL
SSL to nie tylko zielona kłódeczka – on realnie zwiększa bezpieczeństwo danych przesyłanych za pomocą strony www. O tym jak zainstalować certyfikat SSL w WordPress pisałam w artykule https://sylwiastein.pl/wordpress/jak-dodac-certyfikat-ssl-w-wordpress/
—
A teraz wyższa szkoła jazdy…. 😉
USTAWIAMY INNY PREFIX DLA TABEL W BAZIE DANYCH NIŻ TEN STANDARDOWY
Standardowy prefix bazy danych to wp_ – można to zobaczyć w pliku wp-config.php. Podczas instalacji WordPressa (później też się da, ale to już bardziej skomplikowane) warto zamiast wp podać własny zlepek liter, które będą stanowił prefix naszej bazy.
GENERUJEMY WŁASNE KLUCZE ZABEZPIECZAJĄCE DANE PRZECHOWYWANE W CIASTECZKACH
W pliku wp-config.php zawarte są również klucze zabezpieczające dane przechowywane w ciasteczkach. Chodzi o coś takiego:
Własne klucze można wygenerować tutaj: https://api.wordpress.org/secret-key/1.1/salt/
PRZENOSIMY DANE BAZY
Skoro jesteśmy w pliku wp-config.php to szukamy fragmentu:
define('DB_NAME', 'moja_baza');
define('DB_USER', 'moj_user');
define('DB_PASSWORD', 'moje_haslo');
define('DB_HOST', 'moj_host');
define('DB_CHARSET', 'utf8');
define('DB_COLLATE', '');
i kopiujemy je do innego pliku – przykładowo wp-config-data.php a następnie w pliku wp-config.php dodajemy
require_once "wp-config-data.php";
UKRYWAMY BŁĘDY
Nadal zostajemy w pliku wp-config.php. Szukamy teraz
define('WP_DEBUG', false);
i zamieniamy ten fragment na:
define('WP_DEBUG', false);
if ( ! WP_DEBUG ) {
ini_set('display_errors', 0);
}
INNA NAZWA BAZY DANYCH I JEJ UŻYTKOWNIKA
Dobrze jest dla bazy danych i dla użytkownika wybrać różne nazwy o ile jest taka możliwość. Niestety są hostingi, które nam narzucają dwie te same nazwy, wtedy no trzeba to przeboleć i przynajmniej wybrać skomplikowane hasło 😉
WYŁĄCZAMY MOŻLIWOŚĆ EDYCJI PLIKÓW MOTYWU I WTYCZEK PRZEZ PANEL WORDPRESS
Standardowo w WordPressie dostępna jest możliwość edytowania plików motywu oraz wtyczek bezpośrednio z panelu tzw. Edytor. Jako, że do panelu WP łatwiej się zwykle włamać aniżeli na hosting to warto wyłączyć tę opcję. Można tego dokonać w pliku wp-config.php dopisując do niego o taki fragment “krzaczków”:
define('DISALLOW_FILE_EDIT', true);
USUWANY INFORMACJE O WERSJI WORDPRESSA
Żeby ukryć wersję WP, której używamy wystarczy w pliku functions.php dodać taki oto fragment kodu:
function remove_version_info() { return ''; } add_filter('the_generator', 'remove_version_info'); remove_action('wp_head', 'wp_generator');
BLOKUJEMY DOSTĘP DO PLIKU wp-login.php
Najprostsza metoda zabezpieczenia tegoż pliku to dodanie w .htaccess takie cuda:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{HTTP_REFERER} !^http://(.*)?.nasza-domena.pl [NC]
RewriteCond %{REQUEST_URI} ^/wp-login\.php(.*)$
RewriteRule ^(.*)$ - [R=403,L]
</IfModule>
BLOKUJEMY DOSTĘP DO PLIKU xmlrpc.php
Plik ten jest drugim w kolejności, który jest najczęściej atakowany (pierwszy to wp-login.php). Jeśli nie korzysta się z interfejsu XML-RPC to można go całkowicie zablokować dodając w .htaccess:
<files xmlrpc.php>
order deny,allow
deny from all
</files>
BLOKUJEMY DOSTĘP DO KOLEJNYCH PLIKÓW
Są pliki, do których nikt z zewnątrz nie powinien mieć nigdy dostępu. Nie będę ich omawiać, ale podam Wam “krzaczki”, które należy wpisać w pliku .htaccess
<FilesMatch "wp-config.*\.php|\.htaccess|readme\.html">
Order allow,deny
Deny from all
</FilesMatch>
WŁĄCZAMY ZABEZPIECZENIA DLA wp-includes
W katalogu wp-includes tworzymy plik .htaccess i dodajemy do niego
<FilesMatch "\.(?i:php)$">
Order allow,deny
Deny from all
</FilesMatch>
<Files wp-tinymce.php>
Allow from all
</Files>
<Files ms-files.php>
Allow from all
</Files>
WŁĄCZAMY ZABEZPIECZENIA DLA wp-content
W katalogu wp-content tworzymy plik .htaccess i dodajemy do niego
<FilesMatch "\.(?i:php)$">
Order allow,deny
Deny from all
</FilesMatch>
UWAGA: mogą przestać działać niektóre wtyczki, czasem i motywy więc koniecznie przetestujcie jak jest u Was
SPRAWDZAMY UPRAWNIENIA DO KATALOGÓW
Jeśli nic nie grzebaliście w uprawnieniach to nie powinno być tutaj nic do zrobienia. Standardowy schemat uprawnień wygląda mniej więcej tak:
- katalog główny / – 644
- /wp-admin – 644
- /wp-includes – 644
- /wp-content/uploads – 755
DWUSTOPNIOWE LOGOWANIE DO PANELU WORDPRESS
Niektóre hostingi jak np. atthost czy superhost umożliwiają włączenie dodatkowego okienka logowania przed wejściem w panelu WordPressa. Jeśli nie macie takiej możliwości w panelu można to zrobić na piechotę – jeśli będziecie ciekawi jak to dajcie mi znać 🙂
Inną opcją zabezpieczenia panelu WordPress jest zmiana ścieżki do logowania z wp-admin na inną, bardziej zaskakującą. Są osoby to praktykujące, gdzieś jednak wyczytałam, że takie rozwiązanie generuje niepotrzebne przekierowania obciążające serwis.
—
Dodatkowe środki bezpieczeństwa
WYKONUJ CODZIENNIE BACKUPY
Backupy są ważne nie tylko wtedy, gdy coś psujecie. Warto je robić na bieżąco by w razie wstrzyknięcia złośliwego kodu lub innego ustrojstwa mieć z czego przywrócić stronę.
KORZYSTAJ Z ANTYWIRUSA
Logując się przez FTP możesz przenieść “syf” ze swojego komputera na stronę. Warto więc zainstalować sobie antywirusa i systematycznie “przelecieć” nim komputer i usunąć ewentualne wirusy.
To tyle mojego gderania – działajcie 🙂 W razie problemów zapraszam na grupę – Biznes Bliższy Kobiecie 🙂
Sylwio, świetny wpis. Dziękuję. Właśnie miałam jakiegoś wirusa na blogu. Mam nadzieję, że sobie z nim poradziłam. Choć pewna do końca nie jestem. Jutro dodam Twoje zabezpieczenia :).
A nie napisałaś czasem artykułu jak pozbyć się wirusa i być pewną, że go nie ma? Bardzo by mi się taki przydał ?
Super, że wpis się przydał 🙂 Co do usuwaniu wirusa to jeszcze takiego artykułu nie napisałam 🙂 Krótko w tym temacie – warto sprawdzić, jakie pliki zostały zainfekowane. Bardzo często są to pliki index.php, często także sam wp-config.php, nieraz dorzucane są dodatkowe pliki z „wirusami”, nawet w plikach .js może znaleźć się szkodliwy kod. Najprostsza metoda na pozbycie się złośliwego kodu to wgranie backupu sprzed „skażenia”. Jeśli nie ma backupu to wgrywamy świeżą wersję WP i wtyczek oraz motywu, a jak mamy motyw potomny to sprawdzamy czy nie ma tam jakiegoś syfu, następnie sprawdzamy w bazie czy nic niechcianego się nie znajduje. Potem zostaje zabezpieczenie WP – w szczególności zwracając uwagę na te miejsca, gdzie odkryliśmy złośliwy kod 🙂 Koniecznie trzeba wszystko zaktualizować jeśli to nie było zrobione 🙂
ok, pięknie. Podaj tylko zgrabny sopob, jak to wszystko bezpiecznie przechowywać, żeby nie zginąć od własnej broni 😉
ps. oczywiście chodzi o hasła, kody itp
Ja jestem staromodna 😛 Trzymam wszystkie hasła na karteczkach 😀 Choć nieraz do przechowywania haseł mi polecano KeePass – nawet zainstalowałam – jednak i tak magiczne karteczki wygrywają 🙂
Oprócz KeePass może być jeszcze np. LastPass – sama mam ten drugi i sobie chwalę. Przy większości serwisów korzystam teraz z generatora haseł (posiada wbudowany) i swoje indywidualne tworze tylko tam, gdzie naprawdę nie chce ich zapisywać w banku haseł…
Wszystko to pięknie-fajnie, tylko chyba trzeba mieć wordpressa biznesowego, żeby te wszystkie akcje wykonać, prawda?
To metody dla WordPressa .org, którego instalujesz na własnym hostingu 🙂
Wykonałam część zalecanych przez Ciebie czynności, pododawałam wszystko w pliku .htaccess. Niestety po przejściu na inny komputer nie mogłam zalogować się na swojego WordPressa, usunęłam wszystko z pliku .htaccess i nagle wyskakuje mi:
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator at [no address given] to inform them of the time this error occurred, and the actions you performed just before this error.
More information about this error may be available in the server error log.
Mam kopię zapasową itd., więc podejrzewam, że nie będzie problemu, żeby przywrócić stronę, ale mogę to zrobić dopiero za kilka dni i trochę się martwię.
Czasami wystarczy dodać spację nie tam gdzie być powinna, albo usunie się przypadkiem jakiś np. ; i wyrzuci błąd. Jeśli robiłaś zmiany tylko w htaccess to po przywróceniu domyślnego pliku htaccess powinno wszystko wrócić do normy.
Hej Sylwia, mnóstwo przydatnych porad, zabieram się za testowanie, tylko czy te fragmenty kodów można dodać w dowolnym miejscu w plikach, czy gdzieś konkretnie? Druga sprawa, widzę, że mam prefiksy bazy danych ustawione od początku wp_ . Jest na to jakaś „łopatologiczna” instrukcja krok po kroku jak to zmienić na zainstalowanym już WordPressie? Wujek google podaje takie wskazówki, że boję się tykać, by nic nie popsuć :/
Jeśli chodzi o wp-config.php to tam w okolicach, gdzie jest napisy Happy publishing. W functions.php na końcu można wrzucać 🙂 Co do zmiany prefixu zerknij https://pomoc.home.pl/baza-wiedzy/jak-zmienic-prefiks-tabeli-bazy-danych-np-cms-wordpress
Super, baaaardzo dziękuję! 🙂
Proszę 🙂
Bardzo fajne i przydatne zestawienie dotyczące tego jak można zabezpieczyć WordPressa. Wiadomo, najlepiej użyć jak najwięcej zabezpieczeń, ale wiele stron na WP nie ma większości (albo nawet nic) z powyższego zestawienia. Dobrze, że powstają takie wpisy, które uświadamiają ludzi pod tym względem. Można by dodać jeszcze do tego zestawienia ogólne zalecenia dotyczące bezpieczeństwa jak na przykład: zmienianie hasła co jakiś czas i bezpieczne przechowywanie haseł (tu można by się rozpisać w jaki sposób to zrobić). Całość jeszcze można uzupełnić 2 stopniowym logowaniem, które nawet niektóre hostingi oferują w standardzie. Pozdrawiam.
Dzięki serdeczne za komentarz i dodatkowe pomysły na zabezpieczenie WordPress
Dzięki ogromne za ten wpis!Z obawy że napsuję, zapytam najpierw:D
Czy jak zmienię nazwę lub hasło do bazy danych, to muszę jeszcze w jakimś pliku coś zaktualizować? (Gdzieś czytałam żeby nie zmieniać hasła do wp, bo w krzaczkach zostanie stare i będzie problem z logowaniem – no i wiadomo, u mnie już panika :D)
Czy przy stronie zawierającej blog i sklep też blokować pliki xmlrpc.php?
Jeżeli zmienisz nazwę bazy, użytkownika bazy bądź hasło dla niej to później musisz też je podać w pliku wp-config.php 🙂 Jeżeli nie korzystasz z zewnętrznych narzędzi do np. tworzenia wpisów w Twoim WP to możesz go zablokować
Dzięki Sylwia! 🙂
Nie ma za co 🙂
Mam jeszcze pytanie o login – czy jeśli zmienię w bazie danych login, hasło i ID do konta, to wszystko będzie działało czy wymaga jeszcze jakiegoś działania? Czy do tego trzeba się wylogować z WP?
Fajny poradnik, ale po przeniesieniu danych bazy do nowego pliku wyskakuje „błąd łączenia z bazą” 🙁
A na pewno wszystko dobrze podpięte masz? Sprawdź czy nie masz błędu w nazwie, czy haśle
Hej, przy próbie wykonania pozycji: PRZENOSIMY DANE BAZY strona nie działa, a dane konfiguracyjne wyświetlają się czystym tekstem dla wszystkich…
Cześć, najczęściej problemem jest niedomknięcie jakiegoś elementu. Zobacz czy na pewno masz to dobrze wdrożone
Ja z kolei mam problem przy punkcie „przenosimy dane bazy”, z wyskakującym ostrzeżeniem : „Constant DB_NAME already defined in tutaj ścieżka do pliku wp-config-data.php” tak jakby mi chciał powiedzieć, że mam zdublowane pliki. Sylwia, masz może na to rozwiązanie?
Zerknij na to https://stackoverflow.com/questions/5312998/error-notice-constant-db-name-already-defined-in