iptables

Czy linux'owy firewall powinien blokować pakiety not-syn w stanie NEW

Od czasu do czasu w logu systemowym mojego Debiana można zanotować szereg pakietów przychodzących, które są zrzucane przez linux'owy firewall (nftables/iptables ). Po krótkiej analizie okazało się, że są to pakiety protokołu TCP mające stan NEW (czyli są to nowe połączenia) ale niezawierające przy tym flagi SYN . Mój laptop nie ma aktualnie przydzielonego zewnętrznego routowalnego adresu IPv4/IPv6, więc nasunęło się pytanie o przyczynę takiego stanu rzeczy -- przecie będąc za NAT, nikt spoza sieci nie powinien być w stanie nawiązać połączenia z moją maszyną, a ewidentnie co się do jej bram dobija i to nie z adresu lokalnego. Niby mam też odfiltrowane pakiety w stanie INVALID (np. te mające niepoprawny zestaw flag) ale widać te pakiety, o których mowa, nie zaliczają się do tego stanu, więc wygląda na to, że wszystko z nimi jest w porządku. Czy tego typu pakiety TCP w stanie NEW niemające ustawionej flagi SYN stanowią jakieś zagrożenie dla naszego komputera? Czy powinno się je zablokować, a może przepuścić w filtrze pakietów? A jeśli zablokować, to czy zwykły DROP wystarczy czy może powinno się te pakiety potraktować przy pomocy REJECT ?

Migracja z iptables na nftables w Debianie

Zgodnie z informacją, która pojawiła się już ponad pół roku temu, dystrybucje linux'a powoli zaczynają odchodzić od iptables . Prawdopodobnie w niedługim czasie iptables zostanie już całkowicie wyparty i zastąpiony przez nftables , przynajmniej jeśli chodzi o desktopy. Nawet Debian zakomunikował, że następne wydanie stabilne tej dystrybucji (Buster) będzie domyślnie wykorzystywało nftables . Wypadałoby zatem się przenieść na ten nowy framework i przygotować sobie kilka podstawowych reguł firewall'a, które zabezpieczoną naszą maszynę przed nieautoryzowanym dostępem z sieci.

Czy brak wsparcia dla SYNPROXY w nftables jest problemem

Przenosząc swoje reguły z iptables na nftables zauważyłem, że jedna z nich (gdyby tylko jedna) nie została przetłumaczona przez ten dedykowany translator do reguł. Chodzi o mechanizm SYNPROXY, który jest zwykle wykorzystywany do ograniczenia skali ataków DDOS z wykorzystaniem pakietów SYN. Co by nie mówić, to ochrona jaką daje SYNPROXY jest jak najbardziej pożądana z perspektywy serwerów. Dlaczego zatem, gdy się zajrzy na stronę wspieranych rzeczy w nftables, to przy SYNPROXY widnieje bliżej nieokreślone sformułowanie consider native interface ? Po rozmowach z deweloperami udało się ustalić, że ten zapis oznacza brak wsparcia dla SYNPROXY w nftables . Jeśli zatem ktoś wykorzystuje ten mechanizm mając dodane stosowne reguły w iptables , to czy powinien się on obawiać przejścia na nftables ?

Jak ustalić nazwę procesu korzystającego z sieci

Konfigurując filtr pakietów iptables/nftables na Debianie zwykle nie przykładamy większej wagi do procesów, które chcą nawiązać połączenia wychodzące z naszego linux'owego hosta. Mamy przecież "skonfigurowany" firewall w łańcuchach INPUT i FORWARD i wszelkie zagrożenia z sieci nie powinny nas dotyczyć. Problem w tym, że jeśli jakiś złowrogi proces zostanie uruchomiony w naszym systemie, to jest on w stanie komunikować się ze światem zewnętrznym praktycznie bez żadnych ograniczeń za sprawą braku jakichkolwiek reguł w łańcuchu OUTPUT . Można oczywiście temu zaradzić budując zaporę sieciową na bazie cgroups , gdzie każda aplikacja będzie miała oznaczone pakiety, przez co będzie można je rozróżnić i zablokować albo przepuścić przez filter. W tym wpisie jednak nie będziemy się zajmować konstrukcją tego typu FW, tylko spróbujemy sobie odpowiedzieć na pytanie jak namierzyć proces, który komunikuje się z siecią (lub też próbuje), posiadając jedynie log iptables/nftables .

Apache2: Moduł evasive, ipset i iptables (anty DOS/DDOS)

Apache2 ma kilka ciekawych modułów, które mogą uchronić nasz serwer www przed atakami DOS i DDOS. Jednym z nich jest moduł evasive . Nie jest on jednak oficjalnym modułem i brak o nim jakiejkolwiek wzmianki w oficjalnej dokumentacji na stronie Apache2. Niemniej jednak, jest to bardzo prosty moduł składający się dosłownie z kilku dyrektyw, które są w stanie zablokować zapytania o zasoby serwera w przypadku, gdy zostanie przekroczony pewien ustalony przez nas limit. Dodatkowo, ten moduł może współgrać z filtrem iptables oraz ipset , dając nam możliwość wygodnego blokowania uporczywych klientów na poziomie pakietów sieciowych.

nf_conntrack: automatic helper assignment is deprecated

Jeśli ktoś uważnie śledzi logi systemowe, to od czasu do czasu można w nich znaleźć komunikat, którzy brzmi mniej więcej tak: nf_conntrack: automatic helper assignment is deprecated and it will be removed soon. Use the iptables CT target to attach helpers instead . Ta wiadomość odnosi się do jednego z modułów linux'owego filtra pakietów iptables . Moduł, o którym mowa to nf_conntrack , który odpowiada za śledzenie połączeń nawiązywanych przez system. Sam komunikat zaś dotyczy mechanizmów pomocniczych, których sposób aktywacji jest już nieco przestarzały i zostanie wkrótce usunięty. Co to oznacza dla przeciętnego użytkownika linux'a i czym są w istocie te mechanizmy pomocnicze, które znajdują zastosowane na zaporze sieciowej?

Jak wyczyścić tablicę conntrack'a w debianie

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ć.

Równoważenie ruchu łącz kilku ISP (load balancing)

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.

Quality of Service (QoS) w OpenWRT

Wszyscy spotkaliśmy się z sytuacją, w której z bliżej nieokreślonego powodu nie mogliśmy przeglądać stron w internecie. Niby połączenie jest, mamy też dobrej klasy ISP ale net nam muli. W olbrzymiej części przypadków winą można obarczyć sieć Peer to Peer (P2P). Przy nieodpowiedniej konfiguracji klientów tej sieci może dojść do nawiązywania całej masy połączeń w ułamku chwili. W ten sposób nawet jeśli nic aktualnie nie wysyłamy lub nie pobieramy, to i tak te połączenia same w sobie zapychają łącze, no bo przecież nawet puste pakiety w protokołach TCP/UDP zawierają nagłówki, a te już swoje ważą. Gdy sami korzystamy z łącza, to taka sytuacja nie stanowi większego problemu, bo wystarczy odpalić klienta torrent'a w wolnym czasie. Natomiast w przypadku, gdy zachodzi potrzeba wejścia na jakiś serwis www, to możemy zwyczajnie tego klienta wyłączyć. Nie jest to jednak wygodne. Jak zatem wyeliminować problemy związane z siecią P2P? Jeśli na routerze mamy wgrany firmware OpenWRT, to możemy zaimplementować na nim mechanizm QoS (Qality of Service). W ten sposób możemy nadać usługom priorytety. W niniejszym wpisie postaramy się wdrożyć takie rozwiązanie w oparciu o narzędzia iptables oraz tc .

Target MARK w iptables (sumowanie oznaczeń)

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.