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

ZRAM to moduł kernela, który tworzy wirtualne urządzenia w pamięci operacyjnej komputera, a te z kolei można wykorzystać pod system plików lub też i pod przestrzeń wymiany SWAP. Dane w takim urządzeniu są kompresowane, dzięki czemu mamy do dyspozycji więcej miejsca w pamięci. Jeśli mamy niepierwszej jakości dysk twardy, lub też wykorzystujemy szyfrowanie i nie mamy przy tym procka ze wsparciem dla AES, to operacje zapisu/odczytu mogą zająć wieki. Możemy w dość znacznym stopniu odciążyć dysk przenosząc pliki do pamięci RAM, który jest o wiele szybszy, no i dane w nim nie podlegają szyfrowaniu. Jeśli mamy dużo pamięci operacyjnej, to ZRAM raczej będzie zbędny i tylko podniesie nam rachunek za prąd. Natomiast jeśli nasz komputer nie szasta zbytnio pamięcią, możemy rozszerzyć ją 2-3 krotnie.

Prawdopodobnie każdy z nas korzysta, lub też i korzystał, ze skrótu klawiszy Ctrl-Alt-Backspace do resetowania środowiska graficznego na linux'ie. Może i to jest wygodny sposób na szybki restart sesji graficznej Xserver'a ale nie do końca jest on bezpieczny. Nie mówię tutaj o samej utracie danych towarzyszącej takiej akcji ale o możliwości obejścia ekranu logowania o ile ta kombinacja klawiszy nie jest wyłączona. Jest też kilka innych rzeczy, które mogą skompromitować źle zabezpieczony Xserver i tej kwestii będzie poświęcony niniejszy wpis.