Każdy z nas popełnia błędy. Niektóre z nich są błahe i w sporej części łatwe do poprawienia. Zwykle też nie niosą one ze sobą większych konsekwencji. Natomiast błędy, które popełniamy podczas pracy w systemie operacyjnym wykonując różne prace administracyjne mogą nas czasem słono kosztować. W linux'ach ogromną rolę odgrywają prawa do plików. O ile root ma dostęp do wszystkich plików, to w przypadku zwykłych użytkowników (czy tez usług systemowych) już tak nie jest. Przypadkowa zmiana tych uprawnień może zaowocować problemami związanymi z bezpieczeństwem takiego systemu, a w niektórych przypadkach może nawet uniemożliwić jego start. Na necie kilka razy obił mi się o oczy temat, gdzie ludzie przez przypadek (lub też całkiem świadomie) zmienili masowo uprawnienia w takich katalogach jak /usr/ czy /etc/ . Powiem nawet więcej, mi się raz taka sytuacja kiedyś przytrafiła. Co w takim przypadku można zrobić? Czy jedyną opcją, jaka nam pozostaje, to ponowna instalacja sytemu? Na szczęście nie, bo uprawnienia do plików możemy sobie zwyczajnie spisać i odtworzyć je w późniejszym czasie.

Linux słynie z tego, że nie są wymagane w nim częste restarty całego systemu operacyjnego. Nie ma przy tym znaczenia czy aktualizujemy jakieś oprogramowanie, czy też wgrywamy nową wersję kernela. Jeśli by to przenieść na środowisko windowsa, to tam system jest w stanie się automatycznie zresetować kilka razy tylko podczas samego procesu aktualizacji. Można zatem kwestionować zasadność twierdzenia, że linux nie wymaga restartu. Może nie koniecznie jesteśmy zmuszeni do dokonania restartu w danej chwili, tak jak to ma miejsce w przypadku windowsa, ale czy aby na pewno po instalacji jakichś pakietów w systemie, każdy proces powinien w dalszym ciągu działać bez restartu? Na to pytanie postaramy się odpowiedzieć w tym wpisie.

Ostatnio opisywałem jak zaimplementować na swoim serwerze mechanizm port knocking'u , który oparty był o Single Packet Authorization. Tamten wpis dotyczył głównie wykorzystania szyfrów symetrycznych ale istnieje też możliwość skorzystania z kluczy GPG. W ten sposób uwierzytelnianie oraz szyfrowanie pakietów odbywałoby się przy ich pomocy. W tym wpisie postaramy się tak skonfigurować narzędzie fwknop , tak by było ono w stanie przepuszczać jedynie tych klientów, którzy posługują się kluczami GPG.

Kluczową rolę w filtrze iptables pełnią stany połączeń. Zwykle mamy do czynienia z trzema z nich: NEW, RELATED i ESTABLISHED. Wszystko co nie pasuje do tych stanów, jest traktowane jako INVALID i tak dla przykładu trafiają tam pakiety mające niemożliwe kombinacje flag, przynajmniej jeśli chodzi o punkt widzenia poprawnej komunikacji sieciowej (ustawione flagi SYN i FIN jednocześnie). Jednak istnieje szereg pakietów, które mogą potencjalnie zagrażać bezpieczeństwu maszyny i nie są one uwzględnione w stanie INVALID. Takie pakiety są używane do skanowania portów w celu wykrycia usług znajdujących się na serwerze. Krótko mówiąc, stan INVALID nie złapie skanów UDP, ACK oraz SYN . Czy jesteśmy faktycznie bezbronni i nic nie możemy zrobić? Na szczęście iptables ma do dyspozycji moduł xt_recent, który jest w stanie zablokować wszystkie te powyżej wymienione formy ataków.

Port knocking zezwala na zdalny dostęp do usług, które są chronione za pomocą zapory sieciowej. Generalnie rzecz biorąc, iptables ma blokować jakikolwiek ruch na porcie, na którym nasłuchuje jakaś demon. Oczywiście tym sposobem żaden klient nie mógłby nawiązać połączenia z serwerem i tutaj właśnie znajduje zastosowanie knockd , który jest w stanie dodawać dynamicznie odpowiednie reguły do filtra iptables. Nawiązywanie połączenia trwa z reguły bardzo szybko. Po tym jak klient uzyskał dostęp do serwera, te dodane wcześniej reguły są usuwane blokując tym samym wszelkie nowe próby połączenia ale nie odcinając jednocześnie ustanowionych już połączeń. Ten wpis ma jedynie na celu zaprezentowanie narzędzia knockd . Niemniej jednak, jest ono już przestarzałe i powinno się od niego odchodzić na rzecz Single Packet Authorization, czyli alternatywnego port knocking'u.

Obecnie najpopularniejszym rozwiązaniem pod kątem ograniczania dostępu do usług systemowych jest zapora sieciowa. Reguły iptables są w tym przypadku wręcz niezastąpione. Jednak poleganie na samych regułach iptables nie jest zbyt dobrym pomysłem. A to z tego względu, że jeśli skrypt firewall'a z jakiegoś powodu nie zostanie wywołany przy starcie systemu, to nasza maszyna pozostaje praktycznie bezbronna i będzie akceptować wszelkie próby połączeń do wszystkich nasłuchujących w takim systemie usług. Na szczęście nie jest znowu aż tak źle jak mogłoby się wydawać. Albowiem linux posiada dwa pliki /etc/hosts.allow i /etc/hosts.deny , które są w stanie zarządzać dostępem do usług systemowych. Poniższy wpis będzie poświęcony właśnie tym dwóm plikom.

Poniższy wpis ma na celu zaprezentować jak w prosty sposób dozbroić nieco serwer, tak by znajdujące się na nim usługi były należycie chronione. Zostanie to pokazane na przykładzie SSH, bo chyba każdy serwer posiada zdalny dostęp przez shell'a i za bardzo nie godzi się by zostawić tę usługę otwartą na zewnętrzny świat wirtualny bez jakiegokolwiek nadzoru. Postaramy się tutaj wdrożyć port knocking, z tym, że nie będziemy wykorzystywać do tego celu narzędzia knockd . Skorzystamy za to z fwknop , który eliminuje szereg wad występujących w leciwym już knockd .

Na debianie Xserver domyślnie ma wyłączoną możliwość nasłuchiwania połączeń zdalnych. Chodzi oczywiście o kwestie bezpieczeństwa, bo przecie nie od dziś wiadomo, że akurat to oprogramowanie jest dziurawe jak sito i nikt rozsądny nie chciałby instalować go na swoim serwerze. Należałoby jednak rozgraniczyć wykorzystywanie podatności jakiegoś oprogramowania od możliwości wejścia z nim w interakcję. Jakby nie patrzeć, sam Xserver posiada co najmniej trzy mechanizmy ochrony, a do tego dochodzą jeszcze reguły iptables , czy też pliki /etc/hosts.allow i /etc/hosts.deny . Prawdopodobnie jest ich jeszcze kilka ale te najczęściej wykorzystywane mechanizmy gdy pojawia się słowo Xserver, to -nolisten tcp (domyślnie aktywowany), xhost oraz xauth . Pierwszy z nich wyklucza się z pozostałymi i to tym dwóm ostatnim przyjrzymy bliżej w tym wpisie.

Mechanizmy xhost oraz xauth w żaden sposób nie zabezpieczają informacji przesyłanych do Xserver'a. Wobec czego, całą komunikację można bez problemu podsłuchać. Stwarza to zagrożenie przechwycenia nie tylko obrazu wyświetlanego na monitorze ale także danych dotyczących myszy i przyciskanych klawiszy na klawiaturze.

Kontenery LXC mają za zadanie odizolować poszczególne usługi od pozostałej części systemu. LXC jest podobny nieco do maszyn wirtualnych, np. tych tworzonych przez VirtualBox. Niemniej jednak, oba mechanizmy różnią się trochę. Zasadnicza różnica między nimi polega na tym, że LXC wykorzystuje środowisko chroot , w którym współdzielone jest jądro operacyjne. Nie trzeba także z góry określać zasobów pod działanie takiego kontenera, tak jak to ma w przypadku maszyn wirtualnych. Rzućmy zatem okiem jak wygląda konfiguracja takich kontenerów na linux'ie.

Ogromna większość ludzi korzysta z jednego profilu swojej przeglądarki internetowej. Niesie to ze sobą spore zagrożenie bezpieczeństwa jak i może godzić w naszą prywatność. Jeśli dzielimy z kimś komputer, to raczej wszyscy domownicy posiadają osobne konta w systemie, a co z tym się wiąże, inny profil przeglądarki. I na tym zwykle podział się kończy ale przecie to nie wszystko. Profil, jak sama nazwa wskazuje, jest w stanie dostosować opcje przeglądarki, np. pod kątem pewnych aktywności. W tym wpisie postaramy się utworzyć kilka profili w Firefox'ie i sprawdzimy korzystanie z nich będzie odczuwalne w jakiś sposób dla przeciętnego użytkownika internetu.