Dystrybucja linux'a Debian oferuje możliwość pobierania pakietów .deb za pomocą sieci TOR. W ten sposób jesteśmy w stanie ukryć nieco informacji na temat zainstalowanego w naszym systemie oprogramowania. Jakby nie patrzeć, aplikacje mają pełno dziur i nie wszystkie z tych programików są łatane natychmiast po opublikowaniu podatności. Z chwilą dokonywania aktualizacji systemu, potencjalny atakujący może dowiedzieć się zatem z jakich programów korzystamy, wliczając w to ich wersje. Znając te dane, można ocenić czy system posiada jakieś błędy. By zaimplementować w menadżerze pakietów apt/aptitude możliwość korzystania z sieci TOR, musimy posiadać w systemie skonfigurowanego klienta TOR oraz zainstalować pakiet apt-transport-tor . W tym artykule postaramy się skonfigurować ten cały mechanizm TOR'owych aktualizacji.

Serwery udostępniające nam różnego rodzaju strony www na protokole SSL/TLS posiadają certyfikaty, które są ważne przez pewien okres czasu. Z reguły jest to rok albo, jak w przypadku letsencrypt, są to 3 miesiące. Taki certyfikat może zostać unieważniony z różnych przyczyn ale informacja o tym fakcie musi trafić do wszystkich klientów odwiedzających taki serwis www. Do tego celu mogą posłużyć dwa mechanizmy. Pierwszym z nich są listy Certificate Revocation Lists (CRL). Drugim zaś jest Online Certificate Status Protocol (OCSP). W tym wpisie postaramy się zaimplementować to drugie rozwiązanie na serwerze Apache2.

Apache2 ma kilka ciekawych modułów, które mogą uchronić nasz serwer www przed atakami DOS i DDOS. Jednym z nich jest moduł evasive . Nie jest on jednak oficjalnym modułem i brak o nim jakiejkolwiek wzmianki w oficjalnej dokumentacji na stronie Apache2. Niemniej jednak, jest to bardzo prosty moduł składający się dosłownie z kilku dyrektyw, które są w stanie zablokować zapytania o zasoby serwera w przypadku, gdy zostanie przekroczony pewien ustalony przez nas limit. Dodatkowo, ten moduł może współgrać z filtrem iptables oraz ipset , dając nam możliwość wygodnego blokowania uporczywych klientów na poziomie pakietów sieciowych.

W stabilnej dystrybucji linux'a Debian niewiele rzeczy ulega zmianie w przeciągu roku czy dwóch lat. Dlatego też ta gałąź jest wykorzystywana głównie w przypadku serwerów, min. na tym VPS. Na co dzień jednak korzystam z Debiana SID, czyli gałęzi niestabilnej, która jest nieco bardziej aktualna i przystosowana do otaczającej nas tej wirtualnej rzeczywistości. Chodzi generalnie o nowsze oprogramowanie implementujące całą masę ficzerów, których starsze wersje nie posiadają. W tym przypadku problem dotyczy serwera Apache2, który ostatnimi czasy wypracował szereg mechanizmów obronnych adresujących ataki na protokół SSL/TLS. Jedną z podatności jest słaba liczba pierwsza wykorzystywana w protokole Diffie-Hellman'a. Ten problem można stosunkowo łatwo poprawić w nowszej wersji Apache2 wykorzystując dyrektywę SSLOpenSSLConfCmd . W starszych wersjach ona niestety nie działa. Niemniej jednak, w dalszym ciągu możemy użyć własnych parametrów dla protokołu Diffie-Hellman'a, z tym, że trzeba to zrobić nieco inaczej.

Mając serwer www oparty o oprogramowanie Apache2, w pewnym momencie zacznie nas nieco przytłaczać kwestia logowania do pliku /var/log/apache2/access.log wszystkiego co się nawinie. Jak nazwa pliku sugeruje, znajdują się w nim komunikaty, które serwer generuje ilekroć tylko ktoś odwiedzi nasz serwis. Każdy zasób przesłany do klienta, np. style CSS czy obrazki, zostanie zalogowany w powyższym pliku. Generalnie rzecz ujmując, nie musimy logować wszystkich tych informacji, chyba, że ich faktycznie potrzebujemy. Trzeba jednak wziąć pod uwagę fakt, że w przypadku obciążonych serwerów, ilość operacji I/O dysku może być znaczna. Dodatkowo, miejsce na dysku za sprawą takiego obszernego logu może bardzo szybko się wyczerpać. W tym artykule postaramy się nieco ograniczyć apetyt serwera Apache2 na logi i oduczymy go logować większość zbędnych komunikatów za sprawą dyrektywy SetEnvIf/SetEnvIFNoCase .

Operowanie na VPS nie jest jakoś specjalnie trudne, zwłaszcza w przypadku, gdy mamy dostęp root i możemy logować się na serwer z wykorzystaniem protokołu SSH. Dalej to już zwykła linux'owa mechanika, która może być nieco inna, w zależności od tego, jaki dokładnie system operacyjny na tym VPS stoi. Czasami jednak, w pewnym momencie podczas połączenia możemy zostać rozłączeni z niewiadomych nam przyczyn. Niemniej jednak, zawsze, gdy ten problem występuje, w terminalu można zobaczyć komunikat: packet_write_wait: Connection to 1.2.3.4 port 22: Broken pipe . Przydałoby się zatem coś na ten stan rzeczy poradzić.

Każda przeglądarka internetowa potrafi buforować dane w swoim cache w celach optymalizacji przeglądanych stron www. Dzięki temu, szereg elementów odwiedzonych już witryn nie musi być ponownie pobieranych z serwera. Zyskuje na tym nie tylko serwer ale również i sam klient, któremu strona ładuje się parokrotnie szybciej. Pod ten mechanizm podpadają nie tylko pliki graficzne ale również style CSS, skrypty JS, a nawet pliki .html . Generalnie rzecz ujmując, wszystko co serwer www jest w stanie przesłać przeglądarce. Problemem może jednak się okazać zbyt krótki/długi okres ważności cache. Jeśli ten czas jest za krótki, to elementy strony będą niepotrzebnie utylizować łącze, nie tylko nasze ale również i serwera www. Z kolei, jeśli okres ważności będzie za długi, to będziemy odwiedzać nieaktualną stronę. Optymalnym rozwiązaniem byłaby taka konfiguracja serwera www, gdzie dla konkretnych elementów strony sami moglibyśmy ustalić czas ważności cache. Apache2 daje nam taką możliwość przez ustawienie nagłówków HTTP Cache-Control , Expires , ETag oraz Last-Modified .

Od czasu do czasu przeglądam sobie logi Apache2 w poszukiwaniu pewnych nieprawidłowości. Na dobrą sprawę, to nie ma tutaj zbytnio dużo roboty, przynajmniej póki co. Niemniej jednak, w pliku /var/log/apache2/access.log co jakiś czas pojawiają się komunikaty zawierające "internal dummy connection". Za co one odpowiadają i czy można je w zupełności zignorować bez stwarzania zagrożenia bezpieczeństwa dla serwera www?

Gdy odwiedzamy jakiś blog WordPress'a po raz pierwszy, szereg jego elementów jest buforowanych w cache przeglądarki. W ten sposób pewne pliki, np. .css, .js czy też obrazki, nie są pobierane bezpośrednio z serwera www, bo mamy je lokalnie u siebie na dysku. Takie rozwiązanie zapewnia szybsze załadowanie się strony przez minimalizowanie ruchu sieciowego. Niemniej jednak, jako że te pliki siedzą w cache, to muszą mieć ustawiony pewien czas ważności. Może on być różny, a my możemy go sobie dostosować dla poszczególnych elementów ustawiając im nagłówek Cache-Control, Expires, Last-Modified, czy ETag. Gdy w takim nagłówku określimy wysoką wartość max-age , przeglądarka klienta może przez bardzo długi czas nie być świadoma faktu, że któreś elementy strony uległy zmianie. W efekcie może i pojawiła się nowa wersja pliku .css ale klienci odwiedzający nasz serwis i tak nie zaobserwują żadnej różnicy do momentu wygaśnięcia cache lub też odświeżenia strony z przytrzymanym klawiszem Shift . Możemy jednak dodać numer wersji do określonych plików i uzależnić go od czasu modyfikacji danego zasobu na serwerze. Jeśli zmianie ulegnie plik, klient automatycznie pobierze zmodyfikowany zasób.

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