Jakiś czas temu dokonałem zakupu adaptera WiFi TP-Link TL-WN722n, a to z tego względu, że potrzebowałem zewnętrznej karty sieciowej do mojego laptopa. Chodziło generalnie o to, że ten wbudowany w niego broadcom nie był w stanie robić kilku użytecznych rzeczy, min. testów penetracyjnych mojej bezprzewodowej sieci domowej. Jak się później okazało, ten zakupiony adapter posiada też dodatkowy ficzer, którym jest tryb AP (Access Point). Wprawdzie ta karta nie może się równać z routerami WiFi, bo te zwykle mają więcej anten, z których każda jest lepszej jakości ale jesteśmy w stanie połączyć ze sobą bezprzewodowo kilka stacji roboczych. Trzeba jednak wziąć po uwagę, że zasięg jak i transfer będą w dużej mierze ograniczone. W tym wpisie postaramy się przerobić zwykłą maszynę, na której jest zainstalowany Debian, na punkt dostępowy sieci WiFi.

Każdy system plików opiera się na blokach danych. Standardowo taki blok w systemie plików EXT4 ma 4 KiB (8 x 512 bajtów). Za każdym razem, gdy tworzymy jakiś plik na dysku, alokowana jest pewna część bloków, na których ten plik ma zostać zapisany. Te większe pliki rezerwują więcej bloków, choć nie zawsze są to bloki ciągłe. W taki sposób, plik o rozmiarze 10 GiB okupowałby dokładnie tyle miejsca na dysku ile sam waży. Niemniej jednak są pewne pliki, które może i ważą te 10 GiB ale system plików postrzega je tak jakby miały 100 MiB czy 200 MiB, w zależności od tego ile "faktycznie" taki plik zajmuje miejsca. Jak to możliwe? Pliki, o których mowa, to tzw. "rozrzedzone pliki" (Sparse files). Taki plik składa się z szeregu bloków pustych (mających same zera), których nie trzeba zapisywać na dysk. Zamiast tego, można jedynie zapisać metadane w strykturze systemu plików, które będą opisywać te puste bloki. Poniższy artykuł ma na celu pokazać do czego takie pliki sparse mogą nam się przydać i jak z nich korzystać.

Na każdym kroku można natknąć się na przecieki informacyjne, które zagrażają naszej prywatności. Widzieliśmy to choćby i na przykładzie prywatnego adresu IP widocznego w nagłówku w wiadomości email. Przeglądając ten podlinkowany wpis mogliśmy z grubsza zobaczyć jak wygląda taki nagłówek wiadomości. Bardziej uważni czytelnicy zwrócili uwagę na jego zawartość. Poza polem zawierającym adres IP, można było też zobaczyć pole odpowiadające za user-agent. Ciąg zawarty w tym polu zdradza informacje na temat wykorzystywanego klienta pocztowego oraz systemu operacyjnego. Ten komunikat możemy jednak ukryć i w tym wpisie zostanie to pokazane na przykładzie Thunderbird'a.

Korzystając z różnego rodzaju klientów email udostępniamy serwerom mailowym nieco więcej informacji niż gdybyśmy to robili z panelu webowego serwera pocztowego. Chodzi generalnie o adres IP hosta, który przesłał wiadomość na serwer. Tradycyjnie w nagłówku email'a znajdzie się nasz adres zewnętrzny, ten przypisany przez ISP. Niemniej jednak, w części przypadków będzie załączony również adres IP z przestrzeni prywatnej, np. 10.0.0.0/8 lub 192.168.0.0/16 . O ile nie damy rady zataić publicznego IP naszego ISP, to jesteśmy w stanie ukryć ten prywatny adres i tym samym nieco poprawić naszą prywatność. W tym wpisie zostanie pokazane, to jak ten adres prywatny ukryć w nagłówku wiadomości email w kliencie Thunderbird.

Darmowe hotspoty sieci WiFi są dostępne w każdym mieście. Dzięki nim możemy uzyskać połączenie z internetem praktycznie za free. Niemniej jednak, takie połączenie nie jest do końca bezpieczne i może zagrażać naszej prywatności. Wiele osób stara się temu przeciwdziałać generując losowy adres MAC. No i to jest jakieś wyjście, o ile ten adres jest generowany z głową. Niemniej jednak, w takich sieciach WiFi, host ma przydzielaną adresację za pomocą protokołu DHCP. Ci, którzy wiedza, jak odbywa się konfiguracja za pomocą tego protokołu, wiedzą też, że nasz komputer przesyła pewne dane do serwera DHCP. Jakie dane? To zwykle zależy od konfiguracji klienta DHCP. Na linux'ach domyślnym klientem DHCP jest dhclinet i on standardowo przesyła nazwę hosta (hostname) w zapytaniu o adresację. Co nam zatem po losowym adresie MAC, gdy można nas zidentyfikować po nazwie hosta? W tym artykule postaramy się ukryć lub też losowo wygenerować hostname danej maszyny w sieci.

Ludzkość w dalszym ciągu siedzi na przestarzałym już od prawie 20 lat protokole IPv4. Nie widać, też by w najbliższym czasie coś miało się w tej kwestii zmienić. Można, co prawda, wykupić sobie stały adres IP ale to kosztuje, no i płacimy za coś co powinniśmy mieć w standardzie, gdyby ludzie w końcu zaczęli korzystać z IPv6. Niemniej jednak, by te wszystkie nasze maszyny podłączyć jakoś do sieci, potrzebne nam są prywatne adresy IP + NAT lub też dynamicznie zmieniające się adresy publiczne. Bywają też przypadki, że mamy przydzielane dynamicznie adresy z puli prywatnej, np. w wyniku dbania o prywatność w sieciach WiFi przez generowanie sobie przy każdym połączeniu losowego adresu MAC. Zwykle w takiej sytuacji zmienia nam się adres zewnętrzny (publiczny), który wskazuje na jeden z adresów naszego ISP. Taki zmieniający się adres powoduje problemy przy konfiguracji poszczególnych usług sieciowych, np. gdy w grę wchodzi konfiguracja filtra DNS, który jest zapewniany przez OpenDNS. By tego typu niedogodności rozwiązać, możemy posłużyć się DDNS (dynamic DNS). Za każdym razem, gdy adres IP ulega zmianie, klient DDNS informuje o tym fakcie skonfigurowane usługi. W tym artykule przyjrzymy się nieco bliżej temu mechanizmowi.

Podłączenie pojedynczego komputera do sieci raczej nie stanowi żadnego problemu dla przeciętnego użytkownika linux'a. Wystarczy jedynie skonfigurować kilka parametrów i możemy oglądać swoje ulubione serwisy www. Co jednak w przypadku, gdy mamy do dyspozycji kilka łącz internetowych? Jedną z opcji jest używanie łącza tego ISP, które jest lepsze gabarytowo, a pozostałe łącza trzymać na wypadek awarii tego pierwszego. Nie jest to zbytnio satysfakcjonujące rozwiązanie, zwłaszcza w przypadku, gdy tym providerom płacimy za świadczone nam usługi. W taki sposób płacimy, np. za dwa łącza, a korzystamy z jednego w danej chwili. W linux'ie obsługa wielu łącz różnych ISP jest dość skomplikowana. By taki mechanizm zaimplementować sobie, trzeba stworzyć kilka tablic routingu. Następnie ruch sieciowy musi zostać oznaczony w iptables i przekierowany do tych tablic przez kernel. Przy odrobienie wysiłku jesteśmy jednak w stanie zaprojektować sobie load balancer, który będzie równoważył obciążenie łącza między kilku ISP. Dodatkowo, jeśli jedno z łączy nam nawali, to automatycznie zostaniemy przełączeni na drugie łącze (failover). W tym artykule postaramy się zaprojektować taki właśnie mechanizm.

Pakiety i połączenia można oznaczać w iptables za pomocą target MARK oraz CONNMARK . Ta właściwość tego filtra jest znana chyba większość użytkowników linux'a. Z reguły nie interesujemy się zbytnio szczegółami oznaczania pakietów/połączeń, bo zwykle jest ono przeprowadzane prawidłowo. Niemniej jednak, są przypadki, w których markery nie będą ustawiane poprawnie. Chodzi o sytuacje, gdzie mamy do czynienia z kilkoma mechanizmami oznaczającymi pakiety. Dla przykładu weźmy sobie kształtowanie ruchu za pomocą narzędzia tc oraz failover czy load balancing łącza w oparciu o różne tablice routingu. W obu tych mechanizmach zwykle używa się markowania pakietów w iptables . Co się jednak dzieje z takim pakietem, gdy przechodzi przez reguły zarówno pierwszego jak i drugiego mechanizmu? To właśnie spróbujemy ustalić w tym wpisie.

Ja jestem tym szczęśliwcem, który posiada takie fajne urządzenie zwane drukarką. Bardzo umila ono życie pod warunkiem, że działa jak należy, a z tym różnie bywa, zwłaszcza pod linux'em. W debianie do obsługi drukarek używa się CUPS (Common Unix Printing System) i można powiedzieć, że radzi on sobie z tym zadaniem całkiem nieźle, przynajmniej w przypadku mojej drukarki. Drukarka, o której mowa, to dość stary model, konkretnie jest to EPSON Stylus Color 760. Potrzebne są jej odpowiednie sterowniki, które są dostępne w repozytorium debiana. Jedyne czego potrzeba do szczęścia, to skonfigurowanie demona cupsd , który będzie zarządzał tą drukarką. W tym artykule postaramy się skonfigurować to powyższe urządzenie.

Linux'owy firewall w postaci iptables może czasami mieć zdefiniowanych sporo reguł. W takim gąszczu jest czasem ciężko się odnaleźć. Bywa zwykle tak, że dodając kolejną regułę chcemy przyblokować szereg pakietów, a mimo to przechodzą one przez zaporę jak gdyby nigdy nic. W takim przypadku zaczyna się mozolne przeszukiwanie reguł w iptables i próba ustalenia, którą z nich zaakceptowała interesujący nas pakiet. Nie musimy jednak głowić się aż tak, by w miarę szybko dociec jak te reguły przez filtr przechodzą i jak są przetwarzane. Możemy skorzystać z mechanizmu śledzenia reguł, który jest wbudowany bezpośrednio w iptables . Mowa oczywiście o target TRACE . W tym artykule zobaczymy jak przy pomocy TRACE ustalić, przez które reguły i łańcuchy przechodzi pakiet.