W jaki sposób zabezpieczyć WordPressa przed atakami i włamaniami?

30 marca 2017
Jak zabezpieczyć WordPressa przed atakami i włamaniami

Dziś podpowiadamy, jak zabezpieczyć WordPressa przed atakami i włamaniami. Niedawno mocno zachęcaliśmy do zadbania o bezpieczeństwo jednego z najpopularniejszych CMS-ów na świecie. Teraz rozwijamy temat, dlatego przygotowaliśmy specjalną listę kontrolną (checklist), którą warto “przejść” i sprawdzić, czy aby na pewno nasza instalacja WordPressa jest w pełni bezpieczna. Na końcu naszego tekstu zamieszczamy także do pobrania skróconą checklistę w wersji PDF do samodzielnego wypełnienia. Taki wydruk, opatrzony datą i podpisem, pozwoli kontrolować podstawowe bezpieczeństwo oraz zapewni poważne podejście do utrzymania samego WordPressa.

 

Jak zabezpieczyć WordPressa przed atakami i włamaniami?

  1. Podstawowym elementem bezpieczeństwa systemu WordPress jest jego bieżąca aktualizacja. To właśnie aktualizacje “łatają” wiele dziur w tym popularnym CMS-ie, ograniczając w ten sposób prawdopodobieństwo wykorzystania danej luki. Pierwszym krokiem jest zatem sprawdzenie, czy zainstalowana wersja WordPressa jest aktualna, ustawienie automatycznych aktualizacji lub powiadomień o nich.
  2. Wraz z aktualizacją samego systemu WordPress należy aktualizować jego wtyczki. To nawet ważniejsze – jest ich znacznie więcej i o wiele łatwiej na dziurę wśród niepopularnych, czy nieaktualizowanych wtyczek.
  3. Należy korzystać jedynie z zaufanych wtyczek, bądź też napisanych samodzielnie przez developera na rzecz strony. Korzystanie z niepewnych wtyczek naraża na nieświadome zainstalowanie złośliwego oprogramowania.
  4. WordPress od wersji 2.6 wspiera szyfrowanie haseł oraz kluczy solą w pliku konfiguracyjnym „wp-config.php”. W przypadku ewentualnego włamania, hasła nie są przechowywane w formie jawnej, co utrudnia odgadnięcie dalszych danych dostępowych. Konfiguruje się to w następującej sekcji (podany link https://api.wordpress.org/secret-key/1.1/salt/ generuje losowe ciągi znaków, które możemy wykorzystać w naszej konfiguracji) :

    /**#@+

    * Authentication Unique Keys and Salts.

    *

    * Change these to different unique phrases!

    * You can generate these using the {@link https://api.wordpress.org/secret-key/1.1/salt/ WordPress.org secret-key service}

    * You can change these at any point in time to invalidate all existing cookies. This will force all users to have to log in again.

    *

    * @since 2.6.0

    */

    define(‚AUTH_KEY’, ‚put your unique phrase here’);

    define(‚SECURE_AUTH_KEY’, ‚put your unique phrase here’);

    define(‚LOGGED_IN_KEY’, ‚put your unique phrase here’);

    define(‚NONCE_KEY’, ‚put your unique phrase here’);

    define(‚AUTH_SALT’, ‚put your unique phrase here’);

    define(‚SECURE_AUTH_SALT’, ‚put your unique phrase here’);

    define(‚LOGGED_IN_SALT’, ‚put your unique phrase here’);

    define(‚NONCE_SALT’, ‚put your unique phrase here’);

    /**#@-*/

  5. Korzystaj z generowanych, losowych haseł. Wykorzystywaniem tego samego hasła w kilku miejscach, bądź też wykorzystanie bardzo prostego hasła naraża na jego odgadnięci
  6. Zmiana lokalizacji panelu logowania administracyjnego – uniemożliwi to próby odgadnięcia hasła. Domyslny panel jest pod adresem „/wp-admin” (przykładowo „example.com/wp-admin”), do zmiany można wykorzystać wtyczki (przykładowo Custom Login URL – https://wordpress.org/plugins/custom-login-url/ oraz HC Custom WP-Admin URL https://wordpress.org/plugins/hc-custom-wp-admin-url/).
  7. Innym sposobem, mogącym mieć mniejszą skuteczność, jest dodatkowe zabezpieczenie panelu administratora poprzez wprowadzenie dodatkowego poziomu autoryzacji, tzw. „BasicAuth” (konfigurowany w pliku ‚.htaccess’).
  8. Blokowanie dostępu do lokalizacji ‚wp-includes’ z zewnątrz zwiększy równiez poziom bezpieczeństwa. Do tej lokalizacji dostęp powinna mieć jedynie sama aplikacja. W celu uruchomienia blokady wystarczy dokleić do pliku ‚.htaccess’ nastepujący wpis (przed linią „# BEGIN WordPress”):

    # Block the include-only files.

    <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>

  9. Ważnym elementem jest też zabezpieczenie pliku z konfiguracją WordPressa. Aby upewnić się, żę nikt nie będzie miał dostępu do podglądu pliku konfiguracyjnego (w którym to są dane do bazy danych) należy dodać do pliku ‚.htaccess’ nastepujący wpis (przed linią „# BEGIN WordPress”):

    <files wp-config.php>

    order allow,deny

    deny from all

    </files>

    Na niektórych nowych serwerach funkcja „order” jest niedostępna – zamiast niej należy skorzystać z nowych funkcji:

    <files wp-config.php>

    Require all denied

    </files>

  10. Wyłączenie możliwości edycji plików aplikacji z poziomu panelu administracyjnego WordPressa. Po pomyślnym zalogowaniu się do panelu jest to zazwyczaj pierwsza rzecz, którą atakujący próbuje wykorzystać w celu infekcji strony. Jeśli opcja nie jest przez nas wykorzystywana, można wyłączyć tą możliwość poprzez dodanie wpisu w pliku ‚wp-config.php’:

    define(‚DISALLOW_FILE_EDIT’, true);

  11. Usuwanie nieużywanych wtyczek, zastąpienie niewspieranych już wtyczek przez nowe. Stare wtyczki mogą nie spełniać już aktualnych standardów bezpieczeństwa.
  12. Należy zweryfikować pobierane style. Style w WordPressie mogą również zawierać złośliwy kod.
  13. Aby utrudnić atakującemu analizę, z jaką aplikacją ma do czynienia, można uniemożliwić przeglądanie katalogu strony następującym wpisem w pliku ‚.htaccess’ (przed linią „# BEGIN WordPress”):

    # directory browsing

    Options All -Indexes

  14. Zabezpieczenie pliku ‚.htaccess’ poprzez wpis w pliku ‚.htaccess’ (przed linią „# BEGIN WordPress”):

    <files ~ „^.*\.([Hh][Tt][Aa])”>

    order allow,deny

    deny from all

    satisfy all

    </files>

  15. Zmiana prefiksu tabeli bazy danych jest również ważnym elementem. Domyślnym prefiksem jest ‚wp_’, zmiana tego np. na ‚wordp_’ czy też losowy ciąg znaków może zabezpieczyć przed wykonaniem ataku typu ‚sql injection’, ze względu na to, iż atakujący będzie musiał próbować odgadnąć prefiks. Najlepiej jest to wykonać w trakcie instalacji. Trudniej nieco można wykonać tą zmianę na zainstalowanym już WordPressie, bo wymaga to chwilowej przerwy w działaniu strony.Dla wykonania operacji na zainstalowanym już systemie w pliku ‚wp-config.php’ należy zmienić prefiks w linii:

    $table_prefix = ‚wp_’;

    Oraz zmienić nazwy tabel w bazie danych mysql, zmieniając prefiks z „wp_” na nowo wybrany.

  16. Wykorzystanie dwuetapowej autoryzacji do panelu administracyjnego jest jednym z ważniejszych elementów bezpieczeństwa. Za pomocą pluginu można przykładowo dodać dwuetapową autoryzację na podstawie Google Authenticator (https://wordpress.org/plugins/google-authenticator/). Przed instalacją należy upewnić się, iż czas serwera oraz smartphona z aplikacją google authenticator są odpowiednio zsynchronizowane. Zła konfiguracja doprowadzi do uniemożliwienia zalogowania się do WordPressa.
  17. Dodatkowym zabezpieczeniem logowania może być też weryfikacja poprzez przepisanie losowego ciągu znaków z obrazka (tzw. ‚reCAPTCHA’), czy też uproszczona dla użytkownika wersja ‚no captcha reCAPTCHA’. Utrudnia to atak prowadzony metodą bruteforce.
  18. Bardzo ważne dla bezpieczeństwa są także odpowiednie uprawnienia na plikach. Zgodnie z zaleceniami twórców WordPressa, uprawnienia powinny być następujące: wszystkie katalogi powinny mieć uprawnienie ‚755’ lub ‚750’; wszystkie pliki powinny mieć ‚644’ lub ‚640’; plik „wp-config.php” powinien mieć uprawnienie ‚600’
  19. Wyłączenie raportowania błędów na ekran również utrudnia atakującemu rozpoznanie systemu oraz wykonanie ataku. W momentach, gdy aplikacja działa produkcyjnie i developer nie prowadzi prac nad nią, czy też nie napotyka problemów, warto wyłączyć następujące opcje w pliku ‚wp-config.php’:

    error_reporting(0);
    @ini_set(‚display_errors’, 0);

  20. Jeśli nie jest przez nas wykorzystywane, to zaleca się wyłączenie ‚xml-rpc’ w WordPressie. Można to zrobić przykładowo wtyczką „https://wordpress.org/plugins/disable-xml-rpc/„. Opcja ta służy do zdalnego łączenia się do bloga poprzez aplikację blogującą. Niestety jest też najczęstszym celem ataków WordPressa (głównie DOS).
  21. Blokowanie próby odgadnięcia hasła użytkownika poprzez ograniczenie błędnych logowań. Bardzo często boty (oprogramowanie wykonujące operacje automatycznie według podanej instrukcji) próbują odgadnąć losowo hasło. Celem ograniczenia możliwości takiego odgadnięcia można zastosować blokadę po np. 10 błędnych logwaniach w ciągu godziny na okres 4 godzin. Można do tego wykorzystać chociażby wtyczkę „Login LockDown” – https://wordpress.org/plugins/login-lockdown/
  22. Silnie wskazana jest także kontrola i okresowe szkolenie dla redaktorów, aby poprzez mechanizm uploadu WP nie wgrywali krytycznych plików. Mimo ich niepodlinkowania w ramach struktury witryny, dostęp do tych plików jest możliwy i mogą być one odczytane przez nieautoryzowane osoby. W szczególności należy zwrócić uwagę na dane wrażliwe, jak np. backupy bazy WP, pliki z ważnymi danymi itp.

 

Jak zabezpieczyć WordPressa przed atakami i włamaniami. Podsumowanie

WordPress to bardzo użyteczne i intuicyjne narzędzie, jednak wymagające bieżących aktualizacji i odpowiedniej konfiguracji (najlepiej na etapie tworzenia strony). Odpowiedzialne podejście do bezpieczeństwa WordPress pozwoli cieszyć się bogatymi funkcjonalnościami tej platformy, a nam zapewni spokojny sen.

➔ Pobierz checklistę i sprawdź, czy Twój WordPress jest bezpieczny

 

Pytania? Skontaktuj się z nami

 

 

 

Zobacz również:

Bezpieczeństwo w WordPress – bezpieczna konfiguracja WordPressa
Dlaczego moja strona wolno się ładuje?
Hosting ecommerce dla sklepu internetowego
Przeniesienie sklepu internetowego do chmury
Infrastruktura serwerowa bez tajemnic. Serwer dedykowany, VPS, czy chmura?
Zarządzenie serwerami i optymalizacja dla Olive.pl
Chmura AWS na czas sprzedaży biletów na koncert Justina Biebera

Case Studies
Referencje

Hostersi wsparli nas na każdym etapie projektowania i budowy infrastruktury. Finansowanie, które pomogli pozyskać nam od AWS, pozwoliło przetestować szereg różnych rozwiązań i wybrać konfigurację, która najlepiej odpowiada potrzebom naszej aplikacji. Hostersi stworzyli dla nas infrastrukturę „szytą na miarę”, którą dzięki programowi wsparcia startupów, pozyskaliśmy niemal bezkosztowo.

Wojciech Mróz
CEO & Co-founder Pagaspot
W skrócie o nas
Specjalizujemy się w dostarczaniu rozwiązań IT w obszarach projektowania infrastruktury serwerowej, wdrażania chmury obliczeniowej, opieki administracyjnej i bezpieczeństwa danych.