Apache2 on Morfitronik

Request body exceeds maximum size (131072) for SSL buffer

Mikhail Morfikov — Wed, 24 Aug 2016 22:52:29 +0000

Dziś chciałem zaktualizować jeden z moich bardziej obszerniejszych wpisów na tym blogu ale oczywiście nie mogło odbyć się bez problemów. Gdy już wszystkie poprawki zostały naniesione i cały artykuł trafił do formularza WordPress'a, przeglądarka zwróciła mi błąd Request Entity Too Large . Z początku nie wiedziałem o co chodzi ale, że ten aktualizowany artykuł był naprawdę długi, to domyśliłem się, że chodzi o ilość bajtów, które chciałem przesłać w zapytaniu. Przeglądając logi serwera Apache2, znalazłem tam jeszcze dodatkowo komunikaty [ssl:error] request body exceeds maximum size (131072) for SSL buffer oraz [ssl:error] could not buffer message body to allow SSL renegotiation to proceed . Może ta cała sytuacja brzmi groźnie ale wybrnięcie z niej jest wręcz banalne. Wystarczy dostosować wartość dyrektywy SSLRenegBufferSize w konfiguracji serwera Apache2.

Chroot Apache2 vs dyrektywa open_basedir w PHP

Mikhail Morfikov — Mon, 22 Aug 2016 22:03:02 +0000

Kilka dni temu wpadł mi w oko artykuł na temat wykonania chroot serwera Apache2. Problem z tamtym tekstem jest taki, że nie uwzględnia on serwera bazy danych MySQL. W efekcie, taki chroot'owany Apache2 będzie miał problemy z połączeniem się do bazy, a nasz serwis bez niej raczej nie będzie działał prawidłowo. Przydałoby się zatem dopracować nieco ten artykuł i wypracować takie rozwiązanie, które nie popsuje przy okazji naszego serwisu www. Dlatego też w tym wpisie wykonamy sobie chroot zarówno serwera Apache2 z obsługą PHP i bazy danych MySQL za sprawą modułu unixd .

Apache2: Konfiguracja OCSP Stapling

Mikhail Morfikov — Sat, 06 Aug 2016 19:16:09 +0000

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: Moduł evasive, ipset i iptables (anty DOS/DDOS)

Mikhail Morfikov — Sat, 06 Aug 2016 09:13:20 +0000

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.

Problemy z dyrektywą SSLOpenSSLConfCmd w Apache2

Mikhail Morfikov — Fri, 05 Aug 2016 15:52:05 +0000

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.

Apache2: Jak odchudzić nieco plik access.log

Mikhail Morfikov — Thu, 04 Aug 2016 11:10:24 +0000

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 .

Cache-Control, Last-Modified, ETag i Expires w Apache2

Mikhail Morfikov — Mon, 01 Aug 2016 18:50:48 +0000

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 .

"Internal dummy connection" w logu Apache2 (mpm_prefork)

Mikhail Morfikov — Sat, 30 Jul 2016 20:00:28 +0000

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?

Certyfikat Let's Encrypt dla bloga WordPress (certbot)

Mikhail Morfikov — Sat, 23 Jul 2016 12:00:28 +0000

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.

Jak zablokować hotlink'i w Apache2

Mikhail Morfikov — Wed, 20 Jul 2016 18:55:21 +0000

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.

HTTP Strict Transport Security (HSTS) w Apache2

Mikhail Morfikov — Tue, 19 Jul 2016 19:08:40 +0000

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.

Certyfikat chroniący wp-login.php i wp-admin/

Mikhail Morfikov — Tue, 19 Jul 2016 14:07:05 +0000

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.

Tworzenie repozytorium przy pomocy reprepro

Mikhail Morfikov — Wed, 07 Oct 2015 17:37:20 +0000

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 .

Moduł ssl w Apache2

Mikhail Morfikov — Sat, 05 Sep 2015 18:10:04 +0000

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.

Migracja certyfikatów OpenSSL z SHA-1

Mikhail Morfikov — Sat, 05 Sep 2015 17:15:12 +0000

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

WordPress: Ukrycie wp-login.php oraz wp-admin/

Mikhail Morfikov — Sun, 31 May 2015 16:19:13 +0000

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.

Problemy wynikające z używania pliku .htaccess

Mikhail Morfikov — Tue, 26 May 2015 13:25:26 +0000

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.

Wymuszenie SSL/TLS przy pomocy vhost'ów w Apache2

Mikhail Morfikov — Tue, 26 May 2015 11:24:13 +0000

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.