Gdy wprowadzamy sporo zmian na swoim blogu i nie mam tutaj na myśli dodawania/edytowania/usuwania postów, a jedynie przeróbki dotyczące zmiany wyglądu motywu czy też instalowanie i konfigurowanie nowych wtyczek, to istnieje spore prawdopodobieństwo, że gdzieś wystąpi jakiś błąd, który może zagrażać bezpieczeństwu całej witryny. Dlatego też warto wiedzieć, że WordPress posiada obsługę trybu debug, który może nam te wszystkie problemy z działaniem serwisu uwidocznić. Nie jest on jednak standardowo włączony, z oczywistych względów ale jeśli zajdzie taka potrzeba, to możemy sobie ten tryb debugowania aktywować i sprawdzić czy są jakieś błędy, ostrzeżenia czy też inne dodatkowe informacje, które mogą nam w jakiś sposób pomóc.

WordPress dysponuje bardzo rozbudowanym edytorem, przy pomocy którego można tworzyć dość zaawansowane posty. Ten edytor potrafi nawet automatycznie zapisywać stan artykułu przesyłając w ten sposób zmiany do bazy danych, co zapobiega utracie treści. Oczywiście, że potrzebna będzie dodatkowa przestrzeń w samej bazie by kolejną kopię postu przechować ale wydaje się to niebyt wygórowaną ceną za minimalizowanie ryzyka utraty części albo i całego wpisu.

System rewizji postów to nic innego jak wersjowanie kolejnych zmian tworzonych artykułów za pomocą WordPress'owego edytora. Domyślnie ten ficzer jest włączony i powoduje nadmierne rozrastanie się bazy danych, a to z tego powodu, że każda drobna poprawka, to kolejna wersja artykułu, która wędruje do bazy. Nie ma przy tym żadnego ograniczenia co do ilości przechowywanych rewizji. Tego typu mechanizm jest w wielu przypadkach bardzo użyteczny, no bo przecie mamy podgląd wszelkich zmian wprowadzanych do postów i dodatkowo możemy te zmiany śledzić na przestrzeni tygodni, miesięcy czy nawet i lat.

Na stronie Apache jest kawałek ciekawego artykułu na temat zagrożeń jakie niesie ze sobą stosowanie pliku .htaccess w katalogach stron trzymanych na serwerze wwww. Oczywiście, w pewnych sytuacjach, takich jak np. hostingi, nie będziemy mieć innego wyboru jak zdać się na ten plik ale jeśli mamy bezpośredni dostęp do konfiguracji Apache, możemy przenieść wszystkie te wpisy z pliku .htaccess i poprawić tym bezpieczeństwo witryny jak i po części wydajność samego serwera www.

Mając na stronie www formularze logowania czy rejestracji (ewentualnie panele administracyjne), rozmyślnym krokiem jest implementacja protokołu SSL/TLS. Jeśli mamy potrzebę, możemy także pokusić się o zaszyfrowanie całego ruchu w obrębie naszej witryny. Problem w tym, że odwiedzający naszą stronę użytkownicy mogą korzystać z linków, czy wpisywać adresy, które nie rozpoczynają się od https:// , a jedynie od http:// . W takim przypadku, nawet jeśli szyfrujemy ruch w serwisie, to odwiedzenie tego typu adresu zwróci nam stronę kanałem nieszyfrowanym, co może godzić w bezpieczeństwo samej strony jak i również w naszą/czyjąś prywatność. W tym krótki artykule spróbujemy tak skonfigurować serwer Apache2, by przekierował tego typu zapytania i słał je szyfrowanym tunelem.

Każda instalacja tych popularniejszych (i wszystkich pozostałych) CMS'ów powinna być w miarę niepowtarzalna, by utrudnić automatyzację ataków. Blog WordPress'a opiera się o bazę danych. Mamy tam kilka tabel, z których każda jest poprzedzona pewnym prefiksem. Czy zmiana tego prefiksu wp_ na jakiś losowo wybrany przez nas ma jakiś sens? Czy ochroni nas to przed jakimiś formami ataku? W tym wpisie postaramy się prześledzić proces zmiany prefiksu do tabel w bazie danych.

Internet to bardzo niebezpieczne miejsce i do tego pełne różnego rodzaju botów szukających ujawnionych już podatności i niekoniecznie rozchodzi się o kod WordPressa. Tak czy inaczej, WodrPress to bardzo popularny CMS, którego instalacja przebiega (i wygląda) praktycznie tak samo i to bez znaczenia gdzie nie zostałby on zainstalowany. Chodzi o to, że zawsze mamy do czynienia z tymi samymi skryptami czy nazwami katalogów. Nie zmieniają się także ścieżki to plików, no i oczywiście pluginy, których większa ilość może zagrozić bezpieczeństwu naszej strony. Nie chodzi mi tutaj o pilnowanie instalacji i ciągłe aktualizowanie kodu, bo to rozumie się samo przez się. Chodzi mi generalnie o zmodyfikowanie nieco samej instalacji WordPress'a, tak by nie przypominała wszystkich pozostałych. W ten sposób możemy się uchronić przed zautomatyzowanymi robotami (i innym syfem), które są w stanie podrzucić coś nam na stronę o ile ta ma domyślne ścieżki. Im wcześniej zabierzemy się za zmianę domyślnych nazw katalogów, tym lepiej, bo jeśli w przyszłości będziemy zmieniać te nazwy i to na blogu czy w serwisie gdzie mamy sporo kontentu w postaci grafiki czy innej załączonej treści, wtedy trzeba będzie te linki przepisać, bo przestaną zwyczajnie działać.

Jak donoszą ostatnio media, mamy kolejną dziurę (logjam) dotyczącą szyfrowania SSL/TLS, a konkretnie rozchodzi się o powszechnie stosowany na całym świecie protokół Diffiego-Hellmana . I znów jest podobny scenariusz, bo ten problem nie powinien mieć miejsca ale z powodu wstecznej kompatybilności, tj. zapewnienie wsparcia dla wszystkich tych przestarzałych szyfrów tak by te przedwieczne systemy/maszyny mogły działać, można doprowadzić do osłabienie mechanizmów, które powinny być wykorzystywane obecnie. OK, może nie tyle osłabić, co wykorzystać te słabsze odpowiedniki zamiast tych mocniejszych.

W dzisiejszych czasach bez szyfrowania ani rusz i na dobrą sprawę by prowadzić jakikolwiek serwis www, trzeba wliczyć w koszty overhead jaki niesie ze sobą zaszyfrowanie zawartości takiej witryny. Oczywiście, niektórzy minimalizują straty ograniczając się jedynie do zaszyfrowania formularza rejestracji/logowania lub też i ewentualnego panelu administracyjnego. Tak czy inaczej, WordPress domyślnie nie szyfruje niczego i przydałoby się zmienić nieco jego konfigurację.

Poniższe instrukcje zadziałają jedynie w przypadku gdy pod serwer mamy już podpięty certyfikat. Nie będę tutaj opisywał jak poprawnie skonfigurować serwer Apache by włączyć w nim obsługę szyfrowania SSL/TLS. Jak znajdę trochę czasu, to na pewno wstawię tutaj link do przystępnego opisu.

Permalinks, czyli odnośniki bezpośrednie, stosowane są głównie w celach estetycznych oraz by poprawić nieco SEO danego artykułu czy postu. Jeśli chodzi o efekty wizualne, to raczej wszyscy się zgodzimy, że link w postaci morfitronik.pl/wordpress-administrator-bloga/ jest o wiele prostszy do odszyfrowania dla człowieka niż link typu morfitronik.pl/?p=1 . Natomiast w przypadku SEO mamy kluczowe słowa czy fazy bezpośrednio w linku, który jest indeksowany i wyświetlany przez wyszukiwarki, np. google. W tym wpisie postaramy skonfigurować sobie właśnie te odnośniki.