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.

Ten kto tworzył kiedyś paczki .deb wie, że cały proces może w końcu człowieka nieco przytłoczyć. Paczka, jak to paczka, budowana jest ze źródeł i konfigurowana przez jej opiekuna. Z reguły ludzie instalują kompilowane programy via make install . Niektórzy idą o krok dalej i używają do tego celu narzędzi typu checkinstall . I wszystko jest w miarę w porządku, przynajmniej jeśli chodzi o utrzymywanie jednej paczki. Przeprowadzamy kompilację tylko raz, po czym instalujemy dany pakiet i zapominamy o nim. Niemniej jednak, tego typu postępowanie może doprowadzić nasz system na skraj niestabilności. W tym poście nie będziemy zajmować się zbytnio sposobem w jaki powinno się tworzyć paczki .deb , a jedynie tym jak je przechowywać. Do tego celu potrzebne jest nam repozytorium, które zbudujemy w oparciu o oprogramowanie reprepro .

Przy okazji uszczelniania serwera Apache2, przypomniał mi się atak logjam , przez który to było niemałe zamieszanie. Pamiętam, że w tamtym czasie próbowałem zabezpieczyć swój serwer testowy, by był na tę formę ataku odporny. Niemniej jednak, wersja Apache2, która w tamtym czasie była u mnie zainstalowana, nie do końca dawała taką możliwość. Dziś podszedłem do tej kwestii jeszcze raz i w oparciu o ten link udało mi się poprawnie skonfigurować mój serwer www.

Szukając co by tutaj jeszcze poprawić w moim środowisku testowym, w którym działa między innymi apache, natrafiłem na komunikat w firefoxie, który oznajmił mi, że certyfikat mojego serwera korzysta z przestarzałego już algorytmu mieszającego (hash). W tym przypadku jest to SHA-1. Jak można przeczytać na blogu mozilli, algorytm SHA-1 wypadł z łask jakiś czas temu i obecnie nie zaleca się jego używania ze względów bezpieczeństwa. Postanowiłem zatem poprawić tę lukę.

By dokonywać jakichkolwiek zmian w WordPressie (i mowa tu nie tylko o dodawaniu treści ale także zmianie jego plików źródłowych), to musimy uzyskać dostęp do panelu administracyjnego, a tu z kolei możemy się dostać tylko za pośrednictwem formularza logowania. Panel admina możemy wywołać przez dopisanie do adresu strony wp-admin/ , z tym, że jeśli nie jesteśmy zalogowani, to automatycznie zostaniemy przekierowani na wp-login.php . Nie oznacza to bynajmniej, że nie możemy wykonać zapytania do plików znajdujących się w katalogu wp-admin/ . Obie te powyższe lokalizacje muszą być traktowane ze szczególną ostrożnością, a dostęp do nich limitowany i bardzo restrykcyjny.

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.