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?

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

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.

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.

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.