Twoja instalacja WordPressa może być tak bezpieczna lub niepewna, jak chcesz. Dowiedz się, które pięć rzeczy jest najważniejsze, jeśli chodzi o bezpieczeństwo.
Obawy i skargi dotyczące bezpieczeństwa WordPressa nie są niczym nowym.
Jeśli potrzebujesz CMS i skonsultujesz się z usługodawcą, który nie korzysta z WordPressa, bezpieczeństwo jest najważniejszym oszustwem, o którym usłyszysz. Czy to oznacza, że każdy powinien zrezygnować z WordPressa i przełączyć się na statyczne generatory witryn lub bezgłowy CMS?
Nie, ponieważ tak jak każda prawda w życiu, ta również ma wiele stron.
Spis treści:
Czy WordPress jest bardzo niepewny?
Rzućmy okiem na kilka ogromnych stron internetowych, które zostały zbudowane na WordPressie:
- TechCrunch
- Nowojorczyk
- BBC Ameryka
- Bloomberg
- Wiadomości MTV
- Blog PlayStation
Więc co sprawia, że te firmy – z absurdalnie głębokimi kieszeniami i oszałamiającą siłą roboczą – nie przechodzą z WordPressa? Jeśli uważasz, że odpowiedzią jest przestarzały kod, pomyśl jeszcze raz: w przypadku tych nazw bezpieczeństwo danych i wizerunek publiczny są nieskończenie ważniejsze niż prosta migracja, która będzie kosztować (szacuję) mniej niż 200 000 USD.
Z pewnością ich inżynierowie wiedzą, co robią i nie widzą podstawowych, nierozwiązywalnych problemów z bezpieczeństwem WordPressa?
Nawet ja mam szczęście zarządzać instalacją WordPressa, która miesięcznie odwiedza 3,5-4 mln odwiedzających. Całkowita liczba naruszeń bezpieczeństwa w ciągu ostatnich ośmiu lat? Zero!
Więc . . . czy WordPress jest bezpieczny?
Przepraszam, jeśli wygląda to na trolling, ale oto moja odpowiedź:
Mówię tak, ponieważ, jak każda prawda w życiu, jest skomplikowana. Aby uzyskać słuszną odpowiedź, musimy najpierw zrozumieć, że WordPress (lub jakikolwiek gotowy CMS) nie jest jak szafka, którą trzymasz gdzieś na stałe i już z tym skończysz.
To złożone oprogramowanie z wieloma zależnościami:
- PHP, czyli język, w którym jest zbudowany
- Publicznie widoczna maszyna, na której znajduje się instalacja
- Serwer WWW używany do obsługi odwiedzających (Apache, Nginx itp.)
- Używana baza danych (MySQL/MariaDB)
- Motywy (pakiety plików PHP, CS i JS)
- Wtyczki (pakiety plików PHP, CS i JS)
- I wiele innych, w zależności od tego, ile ma osiągnąć Twoja instalacja
Innymi słowy, naruszenie bezpieczeństwa w którymkolwiek z tych szwów będzie nazywane naruszeniem WordPress.
Jeśli hasło roota serwera to admin123 i zostało złamane, czy jest to luka w zabezpieczeniach WordPressa?
Czy wersja PHP miała lukę w zabezpieczeniach lub czy nowa wtyczka, którą kupiłeś i zainstalowałeś, zawierała rażącą lukę w zabezpieczeniach; i tak dalej. Podsumowując: podsystem ulega awarii i jest to awaria bezpieczeństwa WordPressa.
Nawiasem mówiąc, nie pozwól, aby sprawiało to wrażenie, że PHP, MySQL i Apache nie są bezpieczne. Każde oprogramowanie ma podatności, których liczba jest oszałamiająca w przypadku oprogramowania typu open source (ponieważ każdy może je zobaczyć i przeanalizować).
Czy ktoś powiedział „bezpieczne”?
To, czego uczymy się z tego całego ćwiczenia, to:
Nic nie jest samo w sobie bezpieczne ani niepewne. To różne użyte elementy tworzą ogniwa w łańcuchu, który oczywiście jest tak silny, jak najsłabszy z nich. Historycznie etykieta „niezabezpieczony” WordPress była kombinacją starych wersji PHP, hostingu współdzielonego i dodawania wtyczek/motywów z niezaufanych źródeł.
Jednocześnie niektóre dość powszechne przeoczenia sprawiają, że instalacja WordPressa jest podatna na ataki tych, którzy wiedzą, jak je wykorzystać i są zdeterminowani. I o tym jest ten post. Więc bez dalszych ceregieli (i cyklicznych argumentów), zacznijmy.
Najważniejsze luki w WordPressie, które mogą wykorzystać hakerzy
Prefiks tabeli WordPress
Słynna 5-minutowa instalacja to najlepsza rzecz, jaka może się przytrafić WordPressowi, ale podobnie jak wszystkie kreatory instalacji, sprawia, że jesteśmy leniwi i pozostawia rzeczy domyślnie.
Oznacza to, że domyślnym prefiksem dla twoich tabel WordPress jest wp_, co skutkuje nazwami tabel, które każdy może odgadnąć:
- wp-users
- wp-opcje
- wp-posty
Rozważmy teraz atak znany jako SQL Injection, w którym złośliwe zapytania do bazy danych są sprytnie wstawiane i uruchamiane w WordPressie (proszę zauważyć — nie jest to atak wyłącznie dla WordPress/PHP).
Chociaż WordPress ma wbudowane mechanizmy do obsługi tego typu ataków, nikt nie może zagwarantować, że tak się nie stanie.
Więc jeśli w jakiś sposób, atakującemu uda się uruchomić zapytanie typu DROP TABLE wp_users; DROP TABLE wp_posts;, wszystkie Twoje konta, profile i posty zostaną usunięte w mgnieniu oka bez szans na odzyskanie (chyba że masz wdrożony schemat tworzenia kopii zapasowych, ale nawet wtedy na pewno utracisz dane od ostatniej kopii zapasowej ).
Po prostu zmiana prefiksu podczas instalacji to wielka sprawa (która nie wymaga żadnego wysiłku).
Coś losowego, takiego jak sdg21g34_ jest zalecane, ponieważ jest bezsensowne i trudne do odgadnięcia (im dłuższy prefiks, tym lepiej). Najlepsze jest to, że ten prefiks nie musi być łatwy do zapamiętania; prefiks to coś, co WordPress zapisze i nigdy więcej nie będziesz się o to martwić (tak jak nie martwisz się domyślnym prefiksem wp_!).
Domyślny adres URL logowania
Skąd wiesz, że strona internetowa działa na WordPressie? Jednym z charakterystycznych znaków jest to, że po dodaniu „/wp-login.php” do adresu witryny zobaczysz stronę logowania do WordPressa.
Jako przykład weźmy moją witrynę (http://ankushthakur.com). Czy to na WordPressie? Cóż, śmiało dodaj część logowania. Jeśli czujesz się zbyt leniwy, oto co się dzieje:
¯_(ツ)_/¯
WordPress, prawda?
Gdy już tyle będzie wiadomo, napastnik może z radości zatrzeć ręce i zacząć stosować nieprzyjemne sztuczki ze swojego Bag-O’-Doom w kolejności alfabetycznej. Biedny ja!
Rozwiązaniem jest zmiana domyślnego adresu URL logowania i podanie go tylko zaufanym osobom.
Na przykład ta witryna jest również na WordPressie, ale jeśli odwiedzisz http://wdzzwdz.com/wp-login.php, dostaniesz tylko głębokie rozczarowanie. URL logowania jest ukryty i znany tylko administratorom?
Zmiana adresu URL logowania również nie jest nauką rakietową. Po prostu weź to podłącz.
Gratulacje, właśnie dodałeś kolejną warstwę frustrującej ochrony przed atakami typu brute force.
Wersja PHP i serwera WWW
Omówiliśmy już, że każde oprogramowanie, jakie kiedykolwiek napisano (i jest napisane) jest pełne błędów, które czekają na wykorzystanie.
To samo dotyczy PHP.
Nawet jeśli korzystasz z najnowszej wersji PHP, nie możesz być pewien, jakie luki istnieją i które mogą zostać wykryte z dnia na dzień. Rozwiązaniem jest ukrycie konkretnego nagłówka wysyłanego przez serwer WWW (nigdy nie słyszałeś o nagłówkach? przeczytaj ten!) gdy przeglądarka się z nim połączy: x-powered-by.
Oto, jak to wygląda, jeśli sprawdzisz narzędzia programistyczne w swojej ulubionej przeglądarce:
Jak widzimy tutaj, strona informuje nas, że działa na Apache 2.4 i używa PHP w wersji 5.4.16.
Teraz jest to już mnóstwo informacji, które przekazujemy bez powodu, pomagając atakującemu zawęzić wybór narzędzi.
Te (i podobne) nagłówki muszą być ukryte.
Na szczęście można to zrobić szybko; niestety, potrzebna jest zaawansowana wiedza techniczna, ponieważ będziesz musiał zagłębić się w trzewia systemu i zadzierać z ważnymi plikami. Dlatego radzę poprosić dostawcę usług hostingowych, aby zrobił to za Ciebie; jeśli nie zobaczą, czy konsultant może to zrobić, chociaż będzie to w dużej mierze zależeć od hosta witryny, czy ich konfiguracja ma takie możliwości, czy nie.
Jeśli to nie zadziała, być może nadszedł czas na zmianę dostawcy hostingu lub przejście na VPS i zatrudnienie konsultanta do spraw bezpieczeństwa i administracji.
Czy warto? Tylko Ty możesz o tym zdecydować.
Aha, a jeśli chcesz wygłupiać się w nagłówkach bezpieczeństwa, oto twoja poprawka!
Liczba prób logowania
Jedną z najstarszych sztuczek w podręczniku hakera jest tzw Atak słownikowy.
Chodzi o to, aby wypróbować absurdalnie dużą liczbę (miliony, jeśli to możliwe) kombinacji hasła, chyba że jedna z nich się powiedzie. Ponieważ komputery są błyskawiczne w tym, co robią, taki głupi schemat jest rozsądny i może przynieść rezultaty w rozsądnym czasie.
Jedną z powszechnych (i niezwykle skuteczną) obroną było dodanie opóźnienia przed pokazaniem błędu. To sprawia, że odbiorca czeka, co oznacza, że jeśli jest to skrypt używany przez hakera, ukończenie zajmie zbyt dużo czasu. To jest powód, dla którego Twój komputer lub ulubiona aplikacja trochę się podskakuje, a następnie mówi „Ups, złe hasło!”.
W każdym razie chodzi o to, że powinieneś ograniczyć liczbę prób logowania do swojej witryny WordPress.
Poza ustaloną liczbą prób (powiedzmy pięć), konto powinno zostać zablokowane i powinno być możliwe do odzyskania tylko za pośrednictwem poczty e-mail właściciela konta.
Na szczęście zrobienie tego to bułka z masłem, jeśli natkniesz się na fajny? podłącz.
HTTP a HTTPS
Certyfikat SSL, którym dokuczał Ci Twój dostawca, jest ważniejszy, niż mogłoby się wydawać.
To nie tylko narzędzie do sprawdzania reputacji, które pokazuje w przeglądarce zieloną ikonę kłódki z napisem „Bezpieczne”; raczej zainstalowanie certyfikatu SSL i wymuszenie działania wszystkich adresów URL na „https” wystarczy, aby Twoja witryna zmieniła się z otwartej książki w tajemniczy zwój.
Jeśli nie rozumiesz, jak to się dzieje, przeczytaj o czymś znanym jako atak typu man-in-the-middle.
Innym sposobem przechwytywania ruchu przepływającego z komputera na serwer jest sniffing pakietów, który jest pasywną formą gromadzenia danych i nie wymaga nawet trudu, aby ustawić się pośrodku.
W przypadku witryn, które działają przez zwykły „HTTP”, osoba przechwytująca ruch sieciowy, hasła i numery kart kredytowych są wyświetlane jako czysty tekst.
Źródło: comparitech.com
Straszny? Bardzo!
Ale gdy zainstalujesz certyfikat SSL i wszystkie adresy URL zostaną przekonwertowane na „https”, te poufne informacje pojawiają się jako bełkot, który może odszyfrować tylko serwer. Innymi słowy, nie przejmuj się tymi kilkoma dolarami rocznie.
Wniosek
Czy będziesz mieć pod kontrolą te pięć rzeczy, które ładnie zabezpieczą Twoją witrynę?
Nie, wcale. Jak mówią niezliczone artykuły dotyczące bezpieczeństwa, nigdy nie jesteś w 100% bezpieczny, ale możliwe jest wyeliminowanie dużej klasy tych problemów przy rozsądnym wysiłku. Możesz rozważyć użycie SUCURI cloud WAF do całościowej ochrony swoich witryn.