Strefa zdemilitaryzowana (DMZ, demilitarized zone) to taki mechanizm, który ma na celu poprawę bezpieczeństwa usług w sieci lokalnej. Generalnie chodzi o podział sieci na kilka mniejszych podsieci i oddzielenie ich od siebie fizycznie lub logicznie. W OpenWRT możemy wydzielić taką strefę DMZ przy pomocy VLAN'ów. Z kolei odpowiednio skonfigurowany firewall odseparuje nam tę strefę od pozostałych maszyn pracujących w sieci LAN. W taki sposób nawet w przypadku włamania mającego miejsce w strefie DMZ, maszyny w pozostałych segmentach sieci będą bezpieczne. W tym wpisie postaramy się skonfigurować strefę zdemilitaryzowaną na routerze wyposażonym w firmware OpenWRT.

Sporo użytkowników lunux'a, zwłaszcza dystrybucji debian, korzysta z własnych skryptów firewall'a aplikujących reguły iptables . Tego typu rozwiązanie ma jednak swoje wady i zalety. Niewątpliwie do zalet można zaliczyć brak dodatkowego oprogramowania obsługującego zaporę sieciową. Jeśli chodzi zaś o wady, to niestety cały skrypt trzeba sobie dobrze przemyśleć przed zaaplikowaniem. Ludzie często zapominają tutaj o śledzeniu połączeń przez kernel. To właśnie na podstawie wpisów w /proc/net/ip_conntrack lub /proc/net/nf_conntrack system wie, które pakiety należy na zaporze przepuścić, a które zablokować. Jeśli teraz dodajemy reguły do filtra iptables , to nowa polityka zapory nie będzie odnosić się do tych nawiązanych już połączeń, które są określone w tablicy conntrack'a. By się upewnić, że tego typu scenariusz nigdy nas nie spotka, musimy tę tablicę opróżnić.

Rootkit to takie ustrojstwo, które jest w stanie przebywać niepostrzeżenie w naszym systemie przez bardzo długi czas. Dzieje się tak ze względu na uśpioną czujność administratora. Teoretycznie wszystko jest w należytym porządku, nie widać żadnych złowrogich procesów, a szereg narzędzi, które mają przeciwdziałać rootkit'om, nie zwraca żadnych ostrzeżeń o ewentualnych próbach naruszenia bezpieczeństwa systemu operacyjnego. Taki rootkit jest w stanie całkowicie przejąc kontrolę nad linux'em i np. może decydować o tym jakie procesy zostaną nam pokazane, a jakie ukryte. W świetle takiego zagrożenia, linux'y wypracowały sobie pewne mechanizmy obronne. W tym wpisie przebadamy sobie jeden z projektów, tj. rkhunter.

Jak możemy wyczytać na wikipedii, steganografia to nauka, która ma na celu ukrycie faktu prowadzenia komunikacji. Odróżnia ją to nieco od kryptografii, gdzie wiadomość jest wprawdzie nieczytelna ale wiadome jest, że dokonywana jest wymiana informacji między dwoma punktami. W przypadku steganografii możemy ukryć pewną informację, np. w pliku graficznym maskując tym samym cały proces przekazywania danych. W taki sposób osoba, która nie ma pojęcia o fakcie ukrycia informacji, zobaczymy jedynie zwykły obrazek. Poniższy wpis ma na celu sprawdzenie jak skuteczna jest ta metoda i czy nadaje się do zastosowania dla przeciętnego zjadacza chleba.

Jeśli kiedyś rozważaliśmy umieszczenie pliku klucza (keyfile) do zaszyfrowanego kontenera LUKS na pendrive, to ciekawszą alternatywą może okazać się umieszczenie całego nagłówka takiego kontenera na zewnętrznym nośniku. Ma to tę przewagę nad keyfile, że wszystkie informacje zapewniające dostęp do kontenera, wliczając w to klucz główny, są oddzielone od zaszyfrowanych danych. W ten sposób nawet jeśli kontener wpadnie w niepowołane ręce, to nie ma żadnego sposobu na to, by ten ktoś te dane odzyskał, no bo przecie nie ma klucza szyfrującego. Przechwycenie hasła również nic to nie zmieni, no chyba, że ten ktoś zdobędzie również pendrive z nagłówkiem kontenera. Z ludzkiego punktu widzenia, to na takim dysku będą znajdować się jedynie losowe dane i do tego w formie kompletnie nieczytelnej dla człowieka (brak systemu plików). Niemniej jednak, jest kilka rzeczy, o których warto pamiętać, gdy w grę wchodzi nagłówek LUKS i to o nich porozmawiamy sobie w tym wpisie.

Osoby, które wykorzystują pełne szyfrowanie dysku, wiedzą, że nie zawsze da radę tak skonfigurować swój system, by upchnąć go na jednej partycji. Nawet jeśli korzystamy z LVM wewnątrz kontenera LUKS, to i tak zwykle możemy posiadać inne zaszyfrowane partycje, które są odrębną całością i montowane osobno przy starcie systemu. W takim przypadku zwykle jesteśmy zmuszeni do podawania hasła do każdego z tych dysków z osobna, co zajmuje czas. Ten problem opisałem po części przy okazji implementacji kontenera LUKS na potrzeby Dropbox'a, jak i we wpisie poświęconym przejściu z kontenerów TrueCrypt'a na te linux'owe, które są wspierane natywnie przez sam kernel. Niemniej jednak, tamto rozwiązanie było oparte głównie o starszy init (sysvinit), co wymagało dodatkowej konfiguracji, tak by system otworzył się po podaniu tylko jednego hasła. W tym wpisie postaramy się wdrożyć mechanizm, który jest oferowany przez systemd.

Budowanie samych profili dla AppArmor'a nie jest jakoś szczególnie trudne, zwłaszcza, gdy do tego celu wykorzystujemy narzędzia dostępne w pakiecie apparmor-utils . Dobrze jest jednak prześledzić sobie manual AppArmor'a oraz to, co twórcy piszą na swojej stronie w oficjalnej dokumentacji projektu. Poniższy wpis powstał w celu zrozumienia składni profili AppArmor'a, tak by jeszcze bardziej uprościć proces ich budowania.

Opis składni znajdujący się poniżej został zaczerpnięty z wiki AppArmor'a. Część z poniższych informacji może nie mieć zastosowania w przypadku starszych wersji samego AppArmor'a.

Zerowanie dysku twardego ma na celu usunięcie wszystkich znajdujących się na nim danych. Generalnie chodzi o zapisanie całej powierzchni danego nośnika samymi zerami. Ten proces różni się znacząco of formatowania dysku, czyli utworzenia nowego systemu plików, gdzie praktycznie wszystkie dane można bez większego problemu odzyskać. Zerowanie dysku (czy też pendrive) może w pewnych przypadkach naprawić logiczne błędy sektorów na dysku. Niemniej jednak, nie usuniemy za jego pomocą fizycznych bad'ów. Generalnie rzecz biorąc, mamy do wyboru dwie techniki zerowania. Jedna jest dokonywana na poziomie programowym, np. przy pomocy dd , druga zaś na poziomie sprzętowym, np. w hdparm . W tym wpisie postaramy się wyzerować przykładowy dysk.

W pliku /etc/passwd jest przechowywana baza danych kont użytkowników w systemie linux. Z kolei w /etc/group mamy wypisane wszystkie grupy oraz powiązanych z nimi użytkowników. Generalnie rzecz biorąc, to te dwa pliki odpowiadają za konfigurację kont. Problem jednak zaczyna się w momencie gdy w grę wchodzą hasła, zarówno do kont jak i do grup. Gdyby były one trzymane w tych plikach, nie byłyby one w żaden sposób szyfrowane. Dlatego też powstał inny mechanizm, który ma na celu przeniesienie zahashowanych haseł do plików /etc/shadow i /etc/gshadow . W debianie użytkownikami i grupami możemy zarządzać przy pomocy odpowiednich narzędzi, które automatycznie dostosują wszystkie powyższe pliki. Nic jednak nie stoi na przeszkodzie aby edytować każdy z nich ręcznie. Problemy mogą się pojawić w momencie, gdy te pliki będą zawierać różne wpisy, np. w pliku passwd będzie określony użytkownik, który jednocześnie nie będzie istniał w pliku shadow , podobnie z grupami. W tym wpisie postaramy się sprawdzić te pliki i upewnimy się czy aby na pewno jest z nimi wszystko w porządku.

Wielu ludzi potrafi się rozpisywać na temat bezpieczeństwa systemu linux jednocześnie nie zauważając jednego bardzo poważnego problemu. Wszyscy wiemy, że linux'y są bezpieczne min. przez fakt rozgraniczenia konta administratora od konta zwykłego użytkownika i nadaniu im różnych praw dostępu do poszczególnych części systemu operacyjnego. O ile konta użytkowników mają różne nazwy, o tyle administrator w praktycznie każdym linux'ie kryje się pod nazwą root . Znając nazwę konta, można próbować złamać hasło. To trochę dziwne, że nie można sobie arbitralnie ustalić nazwy dla tego konta tak by uniknąć wszelkich ataków, które związane są z logowaniem się na określonego użytkownika w systemie. W tym wpisie postaramy się prześledzić całą procedurę zmiany nazwy konta root na jakąś dowolną i zobaczymy czy wpłynie to w jakimś stopniu na pracę naszego systemu.