Za wysokie uprawnienia zawsze prowadzą do problemów, zwłaszcza, gdy w grę wchodzą komputery i serwisy www. Wszyscy wiemy, że WordPress nie należy do bezpiecznych rozwiązań, mimo, że cała masa stron na necie opiera się właśnie o tego CMS'a. Można jednak wypracować sobie bezpieczny setup, pod warunkiem, że będziemy się zawsze kierować jedna prostą zasadą. Mianowicie chodzi o ograniczenie uprawnień. Standardowo WordPress ma zdefiniowanego jednego użytkownika w pliku wp-config.php , którym skrypt się posługuje. Zwykle też ten użytkownik ma wszystkie możliwe prawa do wszystkich tabel w bazie danych naszego bloga czy serwisu. Nie musi tak być, a my możemy wykorzystać kilku użytkowników i nadać im inne uprawnienia w zależności od tego jakie operacje na bazie danych będą oni przeprowadzać. W tym wpisie zobaczymy jak zaprzęgnąć wielu użytkowników do pracy z bazą danych Wordpress'a.

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.

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.

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.

Każdy bardziej zaawansowany administrator sieci prędzej czy później będzie chciał wdrożyć na swoim routerze wyposażonym w firmware OpenWRT pewien mechanizm QoS umożliwiający kształtowanie ruchu sieciowego. Ci, którzy się za ten temat zabierali, wiedzą, że nie jest on prosty w realizacji. Zwłaszcza, gdy chce się cały ten system zarządzania pakietami skonfigurować od podstaw przy pomocy narzędzi takich jak iptables , tc oraz ip . Z tego też względu OpenWRT umożliwia nam nieco prostszą w konfiguracji alternatywę polegającą na zainstalowaniu narzędzi zawartych w pakietach wshaper , qos-scripts lub sqm-scripts . Trzeba przy tym pamiętać, że mechanizm, który zostanie stworzony z wykorzystaniem jednego z tych w/w pakietów nie będzie tak elastyczny jak przy ręcznej konfiguracji od podstaw. Niemniej jednak, w tym artykule postaramy się ogarnąć kształtowanie ruchu przy pomocy tych pakietów.

W standardowej konfiguracji OpenWRT, hosty łączące się za pomocą sieci bezprzewodowej jak i tej przewodowej są spięte razem za pomocą mostka (bridge) i tworzą jedną sieć lokalną. Nie ma w tym nic dziwnego, bo przecie chcemy, aby komunikacja między wszystkimi hostami w sieci LAN odbywała się bez większych przeszkód. Przynajmniej takie jest standardowe podejście przy konfiguracji sieci domowej. Niemniej jednak, w pewnych przypadkach istnieje potrzeba oddzielenia maszyn, które nawiązują połączenie za pomocą sieci WiFi od tych, które łączą się przewodowo. Generalnie chodzi o różne adresy, które zostaną przypisane sieciom LAN i WLAN. Rozwiązanie, które zostanie opisane w tym artykule jest podobne do tworzenia bezprzewodowej sieci gościnnej (guest WLAN), z tą różnicą, że w tym przypadku będziemy mieli do czynienia tylko z jedną siecią WiFi (tzw. Routed AP).

Routery WiFi zwykle oferują jedną sieć bezprzewodową, do której użytkownicy mogą się łączyć po podaniu nazwy ESSID oraz hasła. W przypadku znanych nam osób chcących korzystać z udostępnianego przez nas AP, taka sieć powinna nam w pełni wystarczyć. Problem jednak zaczyna się w przypadku tych użytkowników, którym chcemy zezwolić na dostęp do naszej sieci WiFi ale nie darzymy ich zbytnio wysokim kredytem zaufania. By ten problem rozwiązać, w OpenWRT możemy skonfigurować mechanizm zwany "guest WLAN", czyli bezprzewodowa sieć gościnna. W tym artykule zobaczymy jak odseparować od siebie hosty w sieci LAN od tych w sieci gościnnej.