Wczoraj hekko.pl się pochwaliło nowym wpisem na blogu „10 sposobów na ochronę strony opartej na WordPress„. Przejrzałem i zdrętwiałem. Głupota goni głupotę :( założenia słuszne ale proponowane rozwiązania do bani.
Odpowiedziałem im na fejsie i pod postem na blogu. Niewiedzieć czemu na blogu mój komentarz się nie pojawił za to inne wytykające te same błędy (choć nie wszystkie które wymieniłem) widać.
Ale żeby nie być gołosłownym:
ad 1 „Wykorzystaj email jako login”
Autor tekstu Tomasz Niezgoda proponuje użycie wtyczki żeby jako nazwę logowania używać adresu email. Nie wiem jak jego blog działa, ale te wordpressy z którymi ja mam do czynienia akceptują adres email natywnie. Najprościej idźcie na waszego bloga i dodajcie się jako user o nazwie jak swój email.
ad 2 „Używaj 2-stopniowej autoryzacji”
to doby punkt jestem fanem dwustopniowej autoryzacji
ad 3 „Ukryj stronę logowania”
Mimo że pomysł dobry to chyba jedna z najgorszych porad jak to zrealizować w tym zestawieniu! W ekstremalnych warunkach zmiana domyślnego wp-login.php na /duda/dlugopis.php zaowocuje zdołowaniem serwera z powodu niewydolności maszyny.
Jeżeli bot uderza do wp-login.php (np. z listą 100 userów i 1000 haseł do każdego) a taka strona nie istnieje (bo wtyczka zmieniła jej adres) to serwer musi wykonać całą robotę (100 000 odpowiedzi) jak przy normalnym wyświetleniu strony 404. A co jak userów, haseł jest więcej? a co jak botów jest 100 w jednym czasie? serwer wtedy zdycha.
Stronę logowania się ukrywa za pomocą poprawnego .htaccess które zwracając 401 działa na dużo niższym poziomie i nie obciąża tak serwera jak wywołanie strony 404 bo nie angażuje php nie łączy się z bazą danych itd.
Użytkownik i hasło mogą być podane w sposób jawny (jak wyżej) w okienku systemowym. Bot się zatrzyma na tym, człowiek przepisze nazwę usera oraz hasło z komunikatu i przejdzie spokojnie dalej do ekranu logowania.
Z rozmów na ten temat większość tych wtyczek i tak robi to tylko połowicznie. Podając np. testowanadomena.tld/wp-login/ czy /wp-admin/ i tak wordpress automatycznie przekierowuje na aktualnie działający adres logowania.
ad 4 „Skonfiguruj blokadę witryny”
Skoro mamy blokadę postawioną na .htaccess proponowana wtyczka iThemes Security jest nam do tego nie potrzebna.
Problemem wtyczek od bezpieczeństwa jest to że nabywamy dzięki nim poczucia bezpieczeństwa. O ich skuteczności Krzysztof Dróżdż pokazywał swoją prezentację setki razy. Ja tylko informacyjnie daję linka do polecanej iThemes Security w bazie publikującej podatności wtyczek
Trochę śmiesznie wygląda wtyczka od bezpieczeństwa z podatnosciami, ale to kod i żaden nie jest doskonały wiec nad instalacją wtyczek zawsze trzeba się zastanowić.
ad 5 „Usuń numer wersji WordPress”
W tym punkcie radosny autor proponuje kawałek kodu realizujący po części jego założenie że jak atakujący nie pozna wersji wordpressa to będzie on bezpieczniejszy.
To założenie IMHO nie ma sensu. Z logów wynika że boty walą w znane podatności. Przykładowo jak była dziura w edytorze tekstu to w logach było widać że linki prowadzą do lokalizacji edytora tekstu we wszystkich wersjach wordpressa (i joomla też).
Bot ma być efektywny łatwiej zadać mu 100 prostych pytań niż dokonywać analizy systemu i podawać pytania pod konkretną wersję wordpressa.
Z kolei jeśli ataku ma dokonywać człowiek to się do niego przygotuje i np. sprawdzi wersję w pliku testowanadomena.tld/readme.html albo odpali jakieś narzędzie typu wpscan.
Podsumowując proponowany w poście kod na boty nie pomoże a przed człowiekiem nie zabezpieczy :( czyli #hała
ad 6 „Użyj SSL do szyfrowania danych”
To jest drugi sensownie zaproponowany punkt w tym zestawieniu od hekko.pl
ad 7 „Obserwuj swoje pliki”
Obserwacja zmian w plikach jest dobra! z tym że znów jest propozycja robienia tego wtyczką.
Nie sorry, ale jak oszukać wtyczkę (dokładnie tę wtyczkę) możesz zobaczyć na którejś z prezentacji wspomnianego już Krzyśka. Robienie takich porównań zawartości plików powyżej systemu operacyjnego jest proste do zablokowania przez atakującego a właściciel wyhaczonej strony śpi spokojnie bo wtyczka nie melduje problemów.
IMHO nie ma to wielkiego sensu bo nawet jeśli Wordfence nie ma podatności od kilku lat to i tak idzie go oszukać :( tylko narzędzia na poziomie systemu operacyjnego mają sens przy porównywaniu zmian w plikach.
ad 8 „Twórz back up. Regularnie”
Tu się nie będę rozpisywał, backup to podstawa ale żeby działał musi być zrobiony dobrze.
Żadna wtyczka nie zrobi tego dobrze (z powodu poziomu dostępu do danych). Owszem coś tam robią i nawet niektórym działa przywracanie z nich backupów ale ponieważ to KLUCZOWA dla bezpieczeństwa operacja więc robienie tego wtyczką jest głupie. Lepsze niż nie robienie wcale, ale głupie.
Moja prezentacja o robieniu backupów
i film z WordCampa
ad 9 „Chroń plik wp-config.php”
Trzeci i ostatni dobry tekst z oryginalnego posta. wp-config.php warto wynieść ponad katalog z wordpressem. Jako bonus dodam że zamiast danych do logowania warto zamieścić w nim link (include) do pliku gdzie podajesz dane typu adres serwera nazwa usera i hasło do bazy.
ad 10 „Aktualizuj stronę regularnie”
To truizm. To podstawowa operacja. Ten punkt powinien się pojawić jako pierwszy nawet jeśli autor pisze androny o cotygodniowych aktualizacjach.
BTW Pomniejsze aktualizacje wordpressa wykonują się same, jeżeli nie to masz coś zepsute lub źle ustawione.
Podsumowując
Nie jestem przeciw wtyczkom, ale używanie ich bez sensu jest gorsze niż brak używania.
Tomasz Niezgoda popełnił tekst bez sprawdzenia nawet takiej podstawowej głupoty jak pkt.1 a hekko.pl potraktowało tekst jako prawdę objawioną i promuje złe praktyki.
