Wpadł mi w łapki smartfon Neffos C5 od TP-LINK, który ma na pokładzie Androida. Chciałem nim zrobić parę fotek, tylko pojawił się problem uzyskania dostępu do zasobów tego telefonu. Samo urządzenie pod linux'em identyfikowane jest jako idVendor=2357 oraz idProduct=0314 ale po jego podłączeniu do portu USB komputera nie pojawiły się żadne nowe dyski, które można by przejrzeć w celu zgania ich zawartości. Problem tkwił w konfiguracji mojego Debiana, w którym to brakowało obsługi protokołu MTP. Po chwili rozgryzłem tę zagadkę instalując w systemie pakiet jmtpfs , co umożliwiło interakcję z systemem plików telefonu i zgranie zrobionych zdjęć.

Kilka dni temu na forum dug.net.pl pojawił się ciekawy wątek dotyczący problemu skonfigurowania profilowanych sieci. Chodzi o to, że praktycznie każdy z nas jest po części w jakiś sposób mobilny i zabiera laptopa ze sobą w dziwne miejsca. Sieci w tych lokalizacjach mogą cechować się różnym poziomem bezpieczeństwa. Dlatego też zamiast korzystać z jednej konfiguracji sieci na linux'ie, można stworzyć szereg profili i w oparciu o nie dostosować sobie połączenie sieciowe. W tym artykule spróbujemy zaimplementować takie rozwiązanie na Debianie wyposażonym w menadżer okien Openbox. W skrócie stworzymy automat, który będzie nam działał w oparciu o pakiety guessnet, ifplugd oraz wpasupplicant. Cała konfiguracja zaś sprowadzać się będzie jedynie do edycji plików /etc/network/interfaces oraz /etc/wpa_supplicant/wpa_supplicant.conf .

Niniejszy artykuł został nieco przerobiony po fazach eksperymentów. Przede wszystkim, zrezygnowałem z zaprzęgania guessnet do rozpoznawania sieci WiFi i aplikowania roamingu. Zamiast tego zostały wykorzystane natywne rozwiązania roamingowe oferowane przez wpa_supplicant . Zaowocowało to uproszczeniem całej konfiguracji, co przełożyło się na wyeliminowanie pewnych błędów.

W obecnych czasach posiadanie komputera, który dysponuje kilkoma interfejsami sieciowymi nie jest niczym niezwykłym. Praktycznie każdy laptop posiada już na pokładzie co najmniej jedną kartę WiFi i minimum jeden port ethernet. W efekcie czego jesteśmy w stanie podłączyć się do sieci zarówno przewodowo jak i bezprzewodowo. Problem jednak pojawia się w momencie, gdy chcemy wykorzystywać oba te interfejsy, z tym, że dysponujemy jedynie niezbyt zaawansowanym menadżerem okien Openbox. Takie środowiska zwykle nie mają na pokładzie automatów pokroju Network Manager, przez co bardziej zaawansowana konfiguracja sieci może być dość skomplikowana. Do tej pory wykorzystywałem interfejs bond0, by mieć możliwość łatwego przełączania się miedzy sieciami. Istnieje inny sposób konfiguracji interfejsów eth0 i wlan0 w pliku /etc/network/interfaces tak, by działały one nam równolegle i nie powodowały problemów z połączeniem, a wszystko za sprawą opcji metric .

Sporo użytkowników różnego rodzaju linux'ów, zwłaszcza dystrybucji Debian, niezbyt chwali sobie automaty konfigurujące połączenie sieciowe typu Network Manager. W sumie nigdy się jemu bliżej nie przyglądałem ale na necie nie cieszy się on najlepszą opinią. Niemniej jednak, Network Manager potrafi automatyzować pewne aspekty pracy w sieci. Weźmy przykład korzystania z dwóch różnych pod względem parametrów sieci przewodowych. Jak się zachowa nasz OS w chwili przełączania się między tymi sieciami w przypadku, gdy nie będziemy mieli zainstalowanego jakiegoś automatu dynamicznie konfigurującego połączenie? W przypadku jednej sieci, połączenie będzie nam działać, w przypadku drugiej zaś napotkamy problemy. W lekkich środowiskach opartych o menadżery okien, np. Openbox, nie musimy instalować Network Manager'a, by ogarnąć tę kwestię konfiguracyjną. Możemy posiłkować się demonem ifplugd i to tym narzędziu będzie ten wpis.

Narzędzie dnscrypt-proxy począwszy od wersji 1.7.0 ma domyślnie włączoną obsługę wtyczek. W standardzie nie ma ich dużo, bo jedynie trzy ale mogą one się okazać dla pewnych osób bardzo użyteczne. Dzięki tym pluginom możemy, np. zablokować rozwiązywanie nazw w protokole IPv6 na wypadek, gdyby ten protokół nie był wspierany w naszej sieci domowej czy też u naszego ISP. Możemy także zdefiniować sobie adresy/domeny, które powinny zostać zablokowane i w efekcie użytkownicy nie będą w stanie odwiedzić tych miejsc w internecie. Jest także wtyczka, która może nam pomóc zalogować zapytania DNS. Jak widać, całkiem przyzwoite są te dodatki. W tym wpisie przyjrzymy się nieco bliżej konfiguracji poszczególnych wtyczek dla dnscrypt-proxy .

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 .

Posiadanie aktualnego systemu za sprawą regularnych aktualizacji może znacząco przyczynić się do poprawy bezpieczeństwa naszego linux'a. Niemniej jednak, niezabezpieczony proces aktualizacji może zdradzić pewne informacje, które mogą się okazać przydatne dla potencjalnego atakującego. Dlatego też menadżer pakietów apt/aptitude w Debianie wyposażony jest w dodatkowe transporty umożliwiające komunikację z serwerem repozytorium w oparciu o różne protokoły. Standardowy protokół, którym posługują się maszyny mające na pokładzie dystrybucję Debian, to HTTP (ewentualnie FTP). Oba z nich ślą wszelkie informacje w postaci czystego tekstu, który nadaje się do analizy przez człowieka. Możemy jednak skorzystać z protokołu SSL/TLS i zaszyfrować proces pobierania aktualizacji za sprawą pakietu apt-transport-https .

Debian to dość stara i rozbudowana dystrybucja linux'a, którą można spotkać praktycznie w każdym zakątku naszego globu. Dziesiątki tysięcy pakietów dostępne w oficjalnych repozytoriach tylko czekają aż je pobierzemy i zainstalujemy w swoim systemie. Problem zaczyna się jednak w momencie, gdy wielu użytkowników w tym samym czasie zaczyna pobierać pakiety i to z tego samego serwera. Wtedy aktualizacja Debiana może trwać dłużej niż zazwyczaj. By zaadresować ten problem, developerzy tej dystrybucji stawiają serwery lustrzane (mirror) w różnych częściach świata i rozładowują w ten sposób ruch, który by powędrował do głównego serwera. Spora część krajów ma kilka własnych mirror'ów ale ich jakość może czasami zostawić wiele do życzenia. Co w przypadku, gdy taki mirror, z którego my korzystamy, ulegnie awarii? Trzeba będzie poddać edycji plik /etc/apt/sources.list i zmienić adres repozytorium przez dostosowanie w nim części odpowiedzialnej za lokalizację, np. ftp.pl czy ftp.us . Istnieje jednak sposób, który dostosuje lokalizację serwera lustrzanego automatycznie, a my już nie będziemy musieli sobie głowy zawracać edycją wspomnianego wyżej pliku.

Projekt, o którym traktuje poniższy wpis, nie jest już rozwijany przez Debiana. Więcej info tutaj.

Dystrybucja linux'a Debian oferuje możliwość pobierania pakietów .deb za pomocą sieci TOR. W ten sposób jesteśmy w stanie ukryć nieco informacji na temat zainstalowanego w naszym systemie oprogramowania. Jakby nie patrzeć, aplikacje mają pełno dziur i nie wszystkie z tych programików są łatane natychmiast po opublikowaniu podatności. Z chwilą dokonywania aktualizacji systemu, potencjalny atakujący może dowiedzieć się zatem z jakich programów korzystamy, wliczając w to ich wersje. Znając te dane, można ocenić czy system posiada jakieś błędy. By zaimplementować w menadżerze pakietów apt/aptitude możliwość korzystania z sieci TOR, musimy posiadać w systemie skonfigurowanego klienta TOR oraz zainstalować pakiet apt-transport-tor . W tym artykule postaramy się skonfigurować ten cały mechanizm TOR'owych aktualizacji.

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.