Co jakiś czas zaglądam sobie do panelu Google Search Console w poszukiwaniu błędów na tym blogu. Do tej pory trafiały mi się pojedyncze przypadki błędnego przekierowania adresu URL. Nic wielkiego, bo wystarczy odszukać dany post i poprawić w nim konkretny link. Niemniej jednak, Google zaczyna mnie drażnić "błędami" odnośnie plików xmlrpc.php oraz wp-includes/wlwmanifest.xml . Oba te pliki są zablokowane na poziomie serwera Apache2 z powodu zagrożeń jakie niesie protokół XML-RPC. Dlaczego zatem mechanizmy Google zwracają błędy? Winna jest tutaj błędna konfiguracja instrukcji dla wyszukiwarek, tj. plik robots.txt . Jakby tego było mało, to w przypadku WordPress'a ten plik jest generowany w locie i fizycznie nie istnieje na serwerze. Jak zatem poddać go edycji? Na to pytanie postaramy się znaleźć odpowiedź w tym wpisie.

Debian to dość stara i rozbudowana dystrybucja linux'a, którą można spotkać praktycznie w każdym zakątku naszego globu. Dziesiątki tysięcy pakietów dostępne w oficjalnych repozytoriach tylko czekają aż je pobierzemy i zainstalujemy w swoim systemie. Problem zaczyna się jednak w momencie, gdy wielu użytkowników w tym samym czasie zaczyna pobierać pakiety i to z tego samego serwera. Wtedy aktualizacja Debiana może trwać dłużej niż zazwyczaj. By zaadresować ten problem, developerzy tej dystrybucji stawiają serwery lustrzane (mirror) w różnych częściach świata i rozładowują w ten sposób ruch, który by powędrował do głównego serwera. Spora część krajów ma kilka własnych mirror'ów ale ich jakość może czasami zostawić wiele do życzenia. Co w przypadku, gdy taki mirror, z którego my korzystamy, ulegnie awarii? Trzeba będzie poddać edycji plik /etc/apt/sources.list i zmienić adres repozytorium przez dostosowanie w nim części odpowiedzialnej za lokalizację, np. ftp.pl czy ftp.us . Istnieje jednak sposób, który dostosuje lokalizację serwera lustrzanego automatycznie, a my już nie będziemy musieli sobie głowy zawracać edycją wspomnianego wyżej pliku.

Projekt, o którym traktuje poniższy wpis, nie jest już rozwijany przez Debiana. Więcej info tutaj.

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?