Mój VPS, jako że jest dość tani, nie zawiera całej masy wynalazków. Jedną z tych bardziej użytecznych rzeczy jest backup danych na dysku VPS'a. OVH liczy sobie trochę grosza za usługę snapshot'ów. Dlatego też byłem zmuszony poszukać innego rozwiązania, które sprawiłoby, że kopia wszystkich ważnych plików byłaby zawsze poza granicami tego VPS. Najlepiej, gdyby te pliki były umieszczany na moim własnym komputerze, czy jakiejś stacji roboczej, która ma robić za taki backup'owy serwer. Problem w tym, że ciężko jest zsynchronizować sobie poprawnie katalogi na odległość, choć jest to możliwe przy pomocy ssh , rsync oraz sudo . Z tym, że mamy tutaj szereg problemów związanych z uprawnieniami do plików. No i oczywiście trzeba także uwzględnić inny port SSH. Trochę było z tym zamieszania ale ostatecznie udało się to zadanie rozwiązać.

WordPress został przetłumaczony na dość sporo języków, w tym też i na język polski. Niemniej jednak, pliki bazowe to nie to samo co pliki różnych dodatków. Dlatego też czasem po zmianie języka na polski, nie wszystkie elementy naszego bloga są przetłumaczone. Nie ma przy tym znaczenia czy ustawialiśmy język podczas instalacji WordPress'a, czy też później z poziomu panela administracyjnego. Taki stan rzeczy nie wygląda zbyt estetycznie i przydałoby się coś z tym zrobić. Jeśli zajrzymy do katalogu wtyczek czy motywów, to zwykle znajdziemy tam pliki .mo oraz .po , które są używane przy tłumaczeniu tekstu z wykorzystaniem gettext. Jako, że motyw, który jest wykorzystywany na tym blogu nie jest przetłumaczony, to postanowiłem go przetłumaczyć i przy okazji opisać ten niezbyt skomplikowany proces.

Jeszcze nie tak dawno temu, rzadko który serwis internetowy wykorzystywał certyfikaty SSL/TLS do zabezpieczenia komunikacji między serwerem, a łączącymi się do niego klientami. W dalszym ciągu jednak notuje się strony bez "zielonej kłódki" ale na szczęście jest ich coraz mniej w naszym otoczeniu. Liczbę tych stron można by z powodzeniem ograniczyć jeszcze bardziej, gdyby takie certyfikaty były za free, łatwe do zaimplementowania i dostępne praktycznie dla każdego od tak. No i na dobrą sprawę są, tylko ludzie jeszcze nie zdają sobie z tego sprawy. Istnieje bowiem projekt Let's Encrypt, który umożliwia stosunkowo bardzo proste wdrożenie certyfikatu na serwerze www opartym, np. o oprogramowanie Apache2. W tym wpisie zobaczymy jak ta cała procedura implementacji certyfikatu SSL/TLS przebiega.

Za wysokie uprawnienia zawsze prowadzą do problemów, zwłaszcza, gdy w grę wchodzą komputery i serwisy www. Wszyscy wiemy, że WordPress nie należy do bezpiecznych rozwiązań, mimo, że cała masa stron na necie opiera się właśnie o tego CMS'a. Można jednak wypracować sobie bezpieczny setup, pod warunkiem, że będziemy się zawsze kierować jedna prostą zasadą. Mianowicie chodzi o ograniczenie uprawnień. Standardowo WordPress ma zdefiniowanego jednego użytkownika w pliku wp-config.php , którym skrypt się posługuje. Zwykle też ten użytkownik ma wszystkie możliwe prawa do wszystkich tabel w bazie danych naszego bloga czy serwisu. Nie musi tak być, a my możemy wykorzystać kilku użytkowników i nadać im inne uprawnienia w zależności od tego jakie operacje na bazie danych będą oni przeprowadzać. W tym wpisie zobaczymy jak zaprzęgnąć wielu użytkowników do pracy z bazą danych Wordpress'a.

Hotlink lub hotlinking to proceder wykorzystywania zasobów (plików) jednej strony www przez inny serwis internetowy. Chodzi generalnie o to, że materiały, które pojawiają się w obcych serwisach, fizycznie w dalszym ciągu są hostowane, np. na naszym serwerze. W taki sposób osoba, która linkuje do naszych plików .jpg , .png , .mp3 czy nawet .css i tworzy swój serwis w oparciu o nie, nie ponosi przy tym praktycznie żadnego obciążenia ze swojej strony. Cały ten ciężar jest spychany na nasz serwer, co zjada nam transfer i zapychając łącze. W tym krótkim wpisie postaramy się zablokować możliwość hotlink'owania przez inne serwisy www w Apache2.

Ostatnio na niebezpieczniku czytałem taki oto post. Historia jak historia, nieco długa ale mniej więcej w połowie pojawiła się informacja na temat nagłówków HSTS (HTTP Strict Transport Security), który jest przesyłany w zapytaniach HTTP/HTTPS. Postanowiłem nieco się zainteresować tym tematem i zbadać czym są te nagłówki HSTS i w jaki sposób są one w stanie poprawić bezpieczeństwo protokołów SSL/TLS wykorzystywanych podczas szyfrowania zawartości stron internetowych.

Jednym z bardziej wyrafinowanych sposobów ochrony zasobów (katalogów) na serwerze www opartym o oprogramowanie Apache2 jest wykorzystanie certyfikatów klienckich. Tego typu zabezpieczenie można jednak zastosować tylko i wyłącznie w przypadku stron, które korzystają z szyfrowania SSL/TLS. Dla przykładu weźmy sobie blog WordPress'a, gdzie mamy katalog wp-admin/ i plik wp-login.php . Formularz logowania oraz panel admina zwykle są szyfrowane. Zatem każdy taki blog powinien robić już użytek z tunelu SSL/TLS w mniejszym lub większym stopniu. Jeśli teraz mamy dość niestandardową instalację WordPress'a, to przy pomocy certyfikatów możemy weryfikować użytkowników, którzy chcą uzyskać dostęp do tych w/w lokalizacji. Jest to nieco inne podejście w stosunku do tego, które zostało opisane w artykule o ukrywaniu wp-login.php oraz wp-admin, gdzie był wykorzystywany moduł mod_rewrite oraz dyrektywy Files i MatchFiles . Takie certyfikaty klienckie dają nam jednak większe pole manewru, bo identyfikują konkretnego użytkownika chcącego uzyskać dostęp do zasobów serwera. Ten wpis ma na celu pokazanie w jaki sposób zaimplementować obsługę certyfikatów klienckich w Apache2.

Praktycznie każda przeglądarka, w tym też i Firefox, oferuje możliwość nadania określonym domenom praw dostępu do zasobów systemowych. Chodzi generalnie o wykorzystywanie wtyczek, np. flash, które są aktywowane na danej stronie internetowej jeśli ta ich potrzebuje. Po części też sprawa dotyczy korzystania z urządzeń takich jak wbudowane w laptop kamera i mikrofon oraz szeregu dodatkowych rzeczy, np. ciasteczka, pop-up'y i inne takie. Obecnie Firefox standardowo blokuje dostęp do pluginów, a gdy zachodzi potrzeba skorzystania z któregoś z nich, to zostaje nam zaprezentowane okienko, w którym możemy zdecydować co zrobić. Gdy często odwiedzamy daną witrynę, to naturalnie prosimy naszą przeglądarkę, by ta zapisała ustawienia dla tej strony. Firefox robi to przez dodanie wyjątku w pliku permissions.sqlite . W sporej części przypadków będziemy mogli cofnąć pozwolenia w dość prosty sposób. Niemniej jednak, nie we wszystkich z nich da się to tak łatwo zrobić.

Jeśli ktoś uważnie śledzi logi systemowe, to od czasu do czasu można w nich znaleźć komunikat, którzy brzmi mniej więcej tak: nf_conntrack: automatic helper assignment is deprecated and it will be removed soon. Use the iptables CT target to attach helpers instead . Ta wiadomość odnosi się do jednego z modułów linux'owego filtra pakietów iptables . Moduł, o którym mowa to nf_conntrack , który odpowiada za śledzenie połączeń nawiązywanych przez system. Sam komunikat zaś dotyczy mechanizmów pomocniczych, których sposób aktywacji jest już nieco przestarzały i zostanie wkrótce usunięty. Co to oznacza dla przeciętnego użytkownika linux'a i czym są w istocie te mechanizmy pomocnicze, które znajdują zastosowane na zaporze sieciowej?

Ja zbytnio się nie nadaję na programistę ale czasem jakieś trzeciorzędne skrypty nawet potrafię napisać. Problem ze skryptami jest taki, że mogą one nie do końca działać jak należy. Zwykle w takich przypadkach, skrypt zwraca jakiś kod wyjścia. Z reguły też jest on inny od 0, który z kolei oznacza, że skrypt został wykonany prawidłowo. Załóżmy teraz, że wywołujemy szereg poleceń. Każde z nich przekierowuje swoje wyjście na wejście innego polecenia przy pomocy znaku | (pipe) . Jak w takim przypadku ustalić czy wszystkie z tych poleceń w łańcuchu wykonały się poprawnie? W tym wpisie postaramy się odpowiedzieć na to pytanie.