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.

Domyślna konfiguracja użytkowników w WordPress'ie nie należy do bezpiecznych. Samą nazwę administratora witryny możemy naturalnie zmienić podczas instalacji tego CMS'a i prawdopodobnie ten zabieg wystarczy większości blogerom. Jednak z punktu widzenia bezpieczeństwa instalacji naszego bloga, nie powinniśmy się ograniczać jedynie do zmiany nazwy konta administracyjnego. Administrator ma za zadanie zarządzać blogiem, natomiast konta autorów wpisów podlegają już pod osobną grupę i o nie również powinniśmy się zatroszczyć.

Prawdopodobnie przyjdzie nam kiedyś zobaczyć komunikat Briefly unavailable for scheduled maintenance. Check back in a minute. podczas przeglądania zawartości naszej strony www czy też bloga opartego na skrypcie WordPressa. Ja początkowo myślałem, że aktualizacja pluginów (lub też i samego WordPressa) zajmuje dłużej niż zwykle ale okazało się jednak, że sam update zakończył się powodzeniem i to z grubsza od razu. Niemniej jednak, ten komunikat widniał na stronie głównej mojego testowego bloga i nie szło wbić nawet do panelu admina by coś w tej sytuacji zaradzić.

W tym artykule zostanie przedstawiony sposób na wykorzystanie kluczy GPG w przypadku przeprowadzanych działań w repozytorium GIT. Będziemy w ten sposób w stanie podpisać swoje commit'y czy tagi, by było wiadomo, że zmiany, które zostały poczynione pochodzą naprawdę od konkretnego użytkownika. Oczywiście to może się wydać przesadą dla wielu ludzi ale skoro mamy udostępnioną możliwość wykorzystania kluczy GPG, to czemu z tej opcji nie skorzystać? Potrzebne będą nam tylko klucze GPG. Sposób ich tworzenia jak i konfiguracja zdefiniowana w pliku gpg.conf nie zostaną tutaj opisane. Zamiast tego skupimy się jedynie na implementacji samych kluczy GPG.

W końcu przyszedł czas na eksperymenty z serwisem GitHub. Jakby nie patrzeć, do tej pory jedyne co potrafiłem zrobić w przypadku samego gita, to wydać jedno polecenie, którym było git clone . Wszelkie inne rzeczy, choć nie było ich wcale tak dużo, robiłem via panel www, co trochę było upierdliwe. Postanowiłem nauczyć się obsługi gita i nieco uprościć sobie życie. Jeśli chodzi o samą naukę, to tutaj jest dostępny dość obszerny pdf (prawie 500 stron). Nie będę tutaj przerabiał wyżej podlinkowanej książki, bo w sumie jeszcze jej nie przeczytałem, tylko zajmę się ciekawym tematem jakim jest implementacja kluczy SSH, tak by operować na gicie bez zbędnych haseł.