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.

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.

Serwisy społecznościowe takie jak Facebook, Twitter czy YouTube coraz bardziej dają się we znaki przedsiębiorcom, który muszą cały czas pilnować, by ich pracownicy nie siedzieli ciągle w internecie, przynajmniej w czasie pracy. Problem nagminnego przebywania w tych w/w portalach można bardzo łatwo rozwiązać przez... porozmawianie z pracownikami. No może nie zawsze ale co nam szkodzi spróbować? W przypadku, gdy upomnienia nie są w stanie zmusić ludzi w naszej firmie do pracy, a nie możemy przy tym ich zwolnić, to możemy pójść o krok dalej i spróbować im założyć blokadę na te powyższe serwisy. Oczywiście blokada szeregu adresów IP nie wchodzi w rachubę. Korporacje typu Facebook czy Google mają wiele adresów IP na których świadczą swoje usługi. Nie wszystkie z nich są uwzględniane na różnego rodzaju listach. Niemniej jednak, tak na dobrą sprawę to nie musimy nawet znać tych adresów. Jedyne czego nam potrzeba to nazwa domeny oraz kilka pakietów standardowo dostępnych w repozytorium OpenWRT. Mowa o iptables , dnsmasq oraz ipset . W OpenWRT, przy pomocy tych narzędzi możemy zaprojektować filtr, który może zablokować ludziom z naszej sieci dostęp do praktycznie każdego serwisu www. W tym artykule zobaczymy jak taki filtr skonstruować.

Router wyposażony w firmware OpenWRT posiada wbudowany firewall, który ma za zadnie stać na straży bezpieczeństwa naszej sieci domowej. Standardowo ta zapora przepuszcza cały ruch sieciowy z obszaru LAN do WAN, czyli z sieci lokalnej do sieci naszego ISP. W ten sposób komputery znajdujące się w naszej sieci mają dostęp do internetu i mogą z niego korzystać bez przeszkód. Niemniej jednak, ten mechanizm nie działa tak samo w drugą stronę, czyli z WAN do LAN. Tutaj są już blokowane wszystkie próby nawiązania nowych połączeń (za wyjątkiem żądań ping) ale nic nie stoi na przeszkodzie, by zastosować przekierowanie portów. Dzięki takiemu rozwiązaniu możemy przekierować ruch, który jest kierowany na dany port w routerze, do określonego hosta w sieci lokalnej. Wszystkie te zadania realizowane są przez iptables i w tym wpisie postaramy się ogarnąć to narzędzie.

Mechanizm NAT Loopback nazywany też NAT Reflection lub NAT Hairpinning często jest pomijany przy omawianiu tematyki firewall'a. Chodzi generalnie o możliwość uzyskiwania dostępu do zasobów w sieci lokalnej po adresie, który jest na zewnętrznym interfejsie sieciowym routera. W taki sposób mając dwa hosty w sieci lokalnej, jeden z nich jest w stanie uzyskać dostęp do usług znajdujących się na drugim hoście przez wykorzystanie zewnętrznego często też publicznego adresu IP. W tym wpisie przybliżymy sobie zasadę działania tego mechanizmu.

Ten standardowy firewall, który oferuje OpenWRT, ma w zamiarze blokować wszystkie nowe próby połączeń od strony WAN. Faktycznie tak jest w istocie. Niemniej jednak, mamy tam jedną regułę, która zezwala na wysyłanie żądań ping . Niby te żądania wydają się być niepozorne ale przy takiej konfiguracji iptables jaką oferuje OpenWRT istnieje ryzyko, że ktoś z zewnątrz może utworzyć sporo sesji bez jakiegokolwiek nadzoru. Każda z tych sesji musi być śledzona przez kernel w tablicy conntrack'a. Nie mając kontroli nad tym ile takich sesji może zostać utworzonych, łatwo może dojść do zapełnienia tej tablicy. Jeśli do tego dojdzie, to router przestanie nawiązywać nowe połączenia. Przydałoby się zatem jakoś ten cały ping ogarnąć i to niekoniecznie blokując go po stronie WAN. W tym wpisie zaimplementujemy sobie mechanizm ochrony przez tego typu zagrożeniem.

Praktycznie każdy router posiada szereg diod LED, które wizualizują stan pracy takiego urządzenia. W taki sposób jesteśmy w stanie stwierdzić czy sieć WiFi jest aktualnie włączona albo czy odbywa się wymiana danych za jej pomocą. Podobnie możemy ocenić aktywność mechanizmu WPS oraz czy połączenie przewodowe zostało ustanowione. Routery TP-LINK'a mają także w standardzie diodę system , która informuje nas czy router działa prawidłowo i nie uległ powieszeniu. W OpenWRT wszystkie te wyżej opisane właściwości można skonfigurować, tak by dioda LED reagowała w określony sposób na pewne zaistniałe zdarzenie. W tym wpisie przyjrzymy się bliżej konfiguracji diod routera.

Ten wpis również będzie poświęcony tematyce kontroli i kształtowania ruchu sieciowego w linux'ie, z tym, że ograniczymy się tutaj do konfiguracji interfejsów IFB. Działają one na podobnej zasadzie co interfejsy IMQ. Niewątpliwą zaletą interfejsów IFB jest fakt, że są one natywnie wspierane przez kernel linux'a, przez co ich obsługa jest dziecinnie prosta. Wadą jest z kolei to, że nie do końca damy radę kształtować ruch przychodzący do naszej maszyny. Tak czy inaczej, postaramy się skonfigurować te interfejsy i zobaczymy co z nich idzie wycisnąć.

Każdy z nas chciałby, aby jego sieć działała możliwie szybko i bezproblemowo. W przypadku, gdy łącze nie jest zbytnio obciążone, a my jesteśmy jedynym użytkownikiem internetu, to nie doświadczymy raczej żadnych problemów z połączeniem. Rzecz w tym, że im więcej użytkowników ma nasza sieć, tym większe prawdopodobieństwo, że zostanie ona przeciążona, tj. będziemy chcieli przesyłać więcej danych niż sieć jest w stanie obsłużyć. W ten sposób zaczną pojawiać się kolejki pakietów na interfejsach, których obsługa zajmuje trochę czasu. Rosą zatem opóźnienia, które są bardzo odczuwalne w momencie, gdy ktoś lubi sobie pograć w różnego rodzaju gry online. Innym problemem może być sieć P2P, gdzie pojedynczy host z naszej sieci może nawiązywać dziesiątki czy nawet setki połączeń i tym samym zapychać łącze nie dając szansy innym użytkownikom na komfortowe korzystanie z internetu. W obu przypadkach może nam pomóc kształtowanie ruchu sieciowego (Traffic Control), która jest w stanie nadać pakietom odpowiedni priorytet, tak by część z nich nie musiała czekać zbyt długo w kolejce. W tym wpisie przyjrzymy się bliżej temu mechanizmowi.

W linux'ie, kształtowanie przychodzącego ruchu sieciowego stwarza dość poważne problemy. Na dobrą sprawę, obecnie w kernelu nie ma żadnego mechanizmu, który byłby w stanie to zadanie realizować. Istnieją, co prawda, interfejsy IFB ale za ich pomocą jesteśmy w stanie z powodzeniem kształtować jedynie ruch wychodzący. W przypadku pakietów napływających, możemy jedynie ograniczyć im przepustowość. W tym powyższym linku jest wzmianka, że te interfejsy IFB są następcą interfejsów IMQ. Niemniej jednak, ten drugi projekt zdaje się działać, choć nie jest obecnie wspierany przez kernel linux'a. W tym wpisie postaramy się skonfigurować działające interfejsy IMQ, tak, by za ich pomocą skutecznie kształtować ruch przychodzący.