Harald Welte <laforge@netfilter.org> , Tłumaczenie: Maciej Sołtysiak Version $Revision: 566 $, $Date: 2003-12-23 20:18:45 +0100 (mar, 23 dic 2003) $, Tłumaczenie: Środa 15 Października 2003 $ Ten dokument zawiera najczęściej zadawane pytania (Frequently Asked Questions) występujące na liście dyskusyjnej netfilter. Komentarze / dodatki / objaśnienia są mile widziane i powinny być kierowane do utrzymującego FAQ. Ten rozdział zawiera ogólne pytania dotyczące netfiltra (i nie tylko) jakie napotkaliśmy na liście dyskusyjnej. Netfilter i IPtables są zintegrowane z jądrami serii 2.4.x. Pobierz ostatnie jądro z � lub z jednego z mirrorów. Narzędzie przestrzeni użytkownika (userspace) 'iptables' jest dostępne na stronach domowych i mirrorach : �, �. Nie, nie ma. Ale jeśli ktoś chce zacząć, nie powinno to być zbyt trudne z uwagi na przejrzysty interface do stosu sieci. Proszę informujcie nas o pracy w tej dziedzinie. Jeśli jesteś przyzwyczajony do maskarady na Linuksach 2.2, zawsze używałeś modułu ip_masq_icq by działaly bezpośrednie połączenia ICQ klient-klient. Nikt nie zaimplementował ponownie tego modułu do netfiltra, ponieważ protokół ICQ jest ohydny :) Ale myślę, że to kwestia czasu zanim będzie dostępny. Rusty kiedyś wskazał na to, że tylko moduły dla protokołów z przynajmniej jednym wolnym klientem i jednym wolnym serwerem będą integrowane do głównej dystrybucji netfiltra. Co do ICQ, darmowi są tylko klienci, więc kryteria odrzucają ten moduł. (wolnym w sensie swobody, nie jak wolny żółw czy darmowy, tj. definicja RMS - Richarda M. Stallmana) Niektóre z nich nie są wymagane, a niektóre nie zostały jeszcze przeniesione do netfiltra. Netfilter wykonuje pełne śledzenie połączeń (connection tracking) nawet dla UDP i ma zasadę by nie przeszkadzać pakietom w miarę możliwości, więc czasami to 'po prostu działa'. Jądra 2.4.x są stabilną wersją, więc nie możemy ot tak wysyłać aktualnego kodu do głównego jądra. Cały kod jest rozwijany i testowany najpierw w netfilter patch-o-matic. Jeśli chcesz używać którejś z nowych funkcji netfiltra, będziesz musiał zastosować jedną lub kilka łat z patch-o-matic. Możesz znaleźć patch-o-matic w najnowszym pakiecie netfiltra (lub oczywiście w CVS) i ściągnąć ze strony domowej netfiltra. patch-o-matic ma teraz trzy różne opcje: make pending-patches make most-of-pom make patch-o-matic Pierwszy jest po ty by upewnić się czy wszystkie ważne poprawki (które zostały wysłane do utrzymujących jądro) są w jądrze. Drugi `most-of-pom` dodatkowo pyta o nowe łaty, które można zastosować bez konfliktów. Trzecia opcja `patch-o-matic` jest dla prawdziwych ekspertów którzy chcą widzieć wszystkie łatki - ale miej świadomość, mogą powodować konflikty. patch-o-matic ma fajny interfejs użytkownika. Po prostu wpisz make most-of-pom (lub pending-patches lub patch-o-matic, spójrz wyżej) lub, jeśli źródła jądra nie są w /usr/src/linux to użyj make KERNEL_DIR={ścieżka-do-jądra} most-of-pom w najwyższym katalogu pakietu netfilter. patch-o-matic sprawdza czy każda łatka zaaplikowałaby się w źródle jądra jakie masz zainstalowane. Jeśli tak, zobaczysz opcje: możesz przeczytać więcej o łacie, zastosować go lub przejść do następnego ... Więcej informacji na temat patch-o-matic jest w netfilter extensions HOWTO. � ipnatctl był używany by postawić regułki NAT z przestrzeni użytkownika (userspace) w początkowych wersjach rozwojowych netfiltra podczas jąder 2.3.x. Nie jest już potrzebny, zatem nie jest dostępny. Cała jego funkcjonalność jest w iptables. Zerknij w NAT HOWTO na stronach domowych netfiltra. Nie, rdzeń NAT nie obsługuje transjacji IPv6 lub IPv6/IPv4 jakiegokolwiek rodzaju. SIP (Session Initiation Protocol) jest dość złożony, szczególnie w transmisji poprzez firewalle i urządzenia NAT. Wstępną propozycją była komunikacja pośrednika (proxy) poprzez FCP (Firewall Control Protocol) przy użyciu filtra pakietów. Została założona grupa robocza IETF MIDCOM, a tymczasem ludzie chcą używać SIP. Zespół netfilter/iptables nie ma zasobów by zaimplementować obsługę SIP dla conntrack/NAT, jednak zawsze jesteśmy otwarci dla sponsorów :) Odpowiedź jest prosta 'tak' i 'nie'. Jeśli masz na myśli pełny failover, podczas którego cała informacja o stanie jest zachowana: Nie bardzo. Synchronizacja stanu między węzłami jest trudnym procesem. Harald (z netfilter core team) opublikowal dokument na ten temat, ale nie znalazł sponsora by ufundować rozwój. Tymczasem, mozesz użyć naszego 'connection pickup', która [po failoverze] próbuje podchwycić już ustanowione połączenia: Może być wystarczające w zależności od wymagań. Jeśli chcesz przechować połączenia NAT: Nie. Jeśli filtrujesz bez przechowywania stanu (stateless): Tak To znany problem. Mechanizm wykrywania które łaty zastosować jest zepsuty. Spróbuj "make build" zamiast "make". Lepsze rozwiązanie: zaktualizuj do iptables-1.1.2 lub późniejszych. Wewnętrzne struktury w iptables zmieniły się. Uaktualnij iptables do >= 1.1.1 Proszę użyj iptables-1.2.2 lub netfilter CVS. Najprawdopodobniej doświadczasz problemów z funkcją zwaną ip_nat_setup_info. Jeśli używasz iptables <= 1.2.2, MUSISZ zastosować łaty 'dropped-table' i 'ftp-fixes'. Jeśli używasz iptables > 1.2.2 lub świeży CVS, proszę nie stosuj `dropped-table', gdyż jest niekompatybilny z BALANCE, NETMAP, irc-nat, SAME i talk-nat. Główny zespół netfiltra opiera rozwój na jądrach Linusa, więc serii -ac używaj na własne ryzyko. Założę się, że usiłujesz uruchomić coś podobnego do : # ./runme pending KERNEL_DIR=/usr/src/linux-2.4.19 Ale bash/sh nie jest jak make a zmienna nie moze byc podana jako parametr. Musisz ustawic zmienna przed uruchomieniem skryptu runme : # KERNEL_DIR=/usr/src/linux-2.4.19 ./runme pending Ta wiadomość jest drukowana przez kod NAT, ponieważ pakiety multicastowe trafiają do tabeli NAT, a connection tracking nie obsługuje teraz multicastów. Jeśli nie masz pojęcia co to jest multicast lub zupełnie nie potrzebujesz tego, używaj: iptables -t mangle -I PREROUTING -j DROP -d 224.0.0.0/8 Mój syslog lub konsola pokazuje wiadomość: NAT: X dropping untracked packet Y Z aaa.aaa.aaa.aaa -> bbb.bbb.bbb.bbb Ta wiadomość jest drukowana przez kod NAT. Zrzuca pakiety, ponieważ by NATować potrzebuje mieć poprawne informacje o stanie połączenia. Ta wiadomość jest drukowana dla wszystkich pakietów, dla których connection tracking nie mógł uzyskać informacji o stanie połączenia. Prawdopodobne powody to: osiągnięto maksymalną liczbę wpisów w bazie śledzonych połączeń nie można określić pakietu odpowiadającego na połączenie (multicast, broadcast) kmem_cache_alloc zawodzi (brak pamięci) odpowiedź na niepotwierdzone połączenie pakiet multicastowy (zobacz poprzednie pytanie) pakiet icmp jest za krótki pakiet icmp jest sfragmentowany pakiet icmp ma złą sumę kontrolną Jeśli chcesz bardziej szczegółowo logować te pakiety (tj. jeśli podejrzewasz, że to zdalna sonda (remote probe) / pakiety skanujące), użyj następującej regułki: iptables -t mangle -A PREROUTING -j LOG -m state --state INVALID Tak, musisz wstawić regułkę w tabeli mangle, ponieważ pakiety są zrzucane przez kod NAT zanim dotrą do tabeli filter. Mój syslog lub konsola regularnie pokazuje mi napis w stylu: ip_conntrack: max number of expected connections N of M reached for aaa.aaa.aaa.aaa -> bbb.bbb.bbb.bbb Zasadniczo nie ma się czym przejmować, szczególnie gdy N i M sa 1, a po tej wiadomości jest , reusing. W szczególności wersje jądra (2.4.19<=x<=2.4.21-pre3), ten komunikat był drukowany dla FTP - I faktycznie może się zdarzyć podczas normalnego działania FTP. Z nadchodzącymi wersjami jądra (>=2.4.21-pre4) ta wiadomość nie jest drukowana by nie mylić użytkownika. Jeśli nadal otrzymujesz takie wiadomości, skontaktuj się z listą: �. Więc chcesz zbudować całkowicie przezroczysty firewall? Świetny pomysł! Niestety bridging code pomija normalny stos sieci włącznie z netfilterem. Ale ktoś pisze nowy bridging code, zerknij na � Zauważ, że wsparcie dla bridge'ującego firewalla jest uważane za skrajnie eksperymentalne. Jest to połowiczna prawda. Tylko moduł NAT nie jest w stanie obsłużyć ich. Jeśli jest to firewall bez NAT, powinno działać. Łatki mile widziane. Netfilter stara się jak najmniej zmieniać pakiety. Więc jeśli mamy świeżo-przeładowaną maszynę i ktoś za SNAT'em otwiera połączenie z loklanym portem 1234, netfilter tylko zmienia adres IP a port zostaje ten sam. Jak tylko ktoś inny otworzy inne połączenie z tym samym źródłowym portem, netfilter musiałby zmienić IP i port jeśli ma tylko jeden IP dla SNAT. Ale jeśli jest dostępny więcej niż jeden, ponownie tylko musi zmieniać część IP. Jeśli zauważysz następujące wpisy w syslogu, wygląda na to, że baza danych conntrack nie ma wystarczającego miejsca na twoje środowisko. Connection tracking domyślnie obsługuje do pewnego poziomu liczbę współbieżnych połączeń. Ta liczba zależy od rozmiaru pamięci (przy 64MB: 4096, 128MB: 8192, ...). Możesz z łatwością zwiększyć maksymalną liczbę rejestrowanych połączeń, ale miej na uwadze, że każde połączenie zjada około 350 bajtów nieswappowalnej pamięci jądra. By zwiększyć ten limit do np 8192, wpisz: echo "8192" > /proc/sys/net/ipv4/ip_conntrack_max By zoptymalizować wydajność, zwiększ też ilość koszyków funkcji hashującej używając parametru hashsize podczas ładowania modułu ip_conntrack.o. Zwróć uwagę na fakt, iż przez cechy obecnego algorytmu haszującego, parzysta liczba koszyków funkcji haszującej (i w szczególności potęgi liczby 2) są złym rozwiązaniem. Przykład (z 1023 koszykami): modprobe ip_conntrack hashsize=1023 Jest plik w filesystemie proc, zwany /proc/net/ip_conntrack. Możesz wyświetlić jego zawartość pisząc: cat /proc/net/ip_conntrack Wszystkie dostępne tabele IP są w: cat /proc/net/ip_tables_names Znany błąd. Uaktualnij do najświeższego CVS lub użyj iptables >= 1.2.1 jak tylko będzie dostępne. To dlatego, że iptables robi DNS lookup dla każdego adresu. Jako że każda regułka składa się z dwu adresów, w najgorszym przypadku wychodzi na 2 DNS lookupy na regułkę. Problem jest, jeśli używasz prywatnych adresów IP (10.x.x.x lub 192.168.x.x), DNS nie jest w stanie rozwiązać nazwy hosta i czekamy na timeout. Suma wszystkich timeoutów może być bardzo duża, w zależności od zestawu regułek. Używaj opcji -n (numeric) w iptables by pominąć reverse DNS lookups. Musisz skonfigurować syslogd odpowiednio: Target LOG loguje do facility kern przy priorytecie warning (4). Zobacz strony man od syslogd.conf by przeczytać więcej o facilities i priorytetach. Domyślnie, wszystkie wiadomości na priorytecie bardziej poważnym niż debug (7) są wysyłane na konsole. Jeśli zwiększysz to do 4, zamiast 7, sprawisz, że logi nie będą się pojawiały na konsoli. Miej na uwadze, że to także pociąga za sobą inne ważne logi i nie pojawią się na konsoli (to nie wpływa na syslog). Na początku, oczywiście, potrzebujesz odpowiedniej regułki DNAT lub REDIRECT. Użyj REDIRECT tylko gdy squid chodzi na tej samej maszynie co NAT. Przykład: iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to 192.168.22.33:3128 Potem, musisz skonfigurować odpowiednio squida. Możemy tylko dać krótkie wskazówki, odsyłam do dokumentacji squida po szczegóły. squid.conf dla Squid 2.3 powinien wyglądać podobnie do tego: http_port 3128 httpd_accel_host virtual httpd_accel_port 80 httpd_accel_with_proxy on httpd_accel_uses_host_header on Squid 2.4 potrzebuje dodatkowej linii: httpd_accel_single_host off Target LOG jest czymś co nazywamy "niekończący target", tj. nie kończy podróży pakietu. Jeśli użyjesz target LOG, pakiet będzie zalogowany i podróż będzie kontynuowana od następnej regułki. Więc jak mam logować i zrzucać pakiet jednocześnie? Nic prostszego, możesz stworzyć własny łańcuch, zawierający te dwie regułki: iptables -N logdrop iptables -A logdrop -j LOG iptables -A logdrop -j DROP Teraz za każdym razem jak będziesz chciał logować i zrzucić pakiet, możesz po prostu użyć "-j logdrop". Krótka odpowiedz brzmi: nie da się tego zrobić prawidłowo używając netfiltra. Większość robaków używa prawidłowych protokołów wyższej warstwy (tj. HTTP, SMTP (np. VB script w załączniku listu), lub wykorzystuje jakąkolwiek inną znaną dziurę w demonie obsługującym protokół). Mówiąc protokół wyższych wartsw, mamy na myśli ponad TCP/IP. Jako że iptables nie rozumie protokołów wyższych wartsw, jest prawie nie możliwe filtrowanie ich prawidłowo. Do tego potrzeba proxy filtrujących na poziomie aplikacji. Proszę nie używaj matchu string z patch-o-matic zamiast takiej aplikacji. Nie da rady sobie z fragmentowanymi pakietami (tj. zapytanie HTTP rozbite na dwa pakiety TCP), z technikami unikania systemów IDS, itd... zostałeś ostrzeżony! Match string jest przydatny ale w innych celach. Używasz łaty tcp-window-tracking z patch-o-matic, którego kod śledzi czy pakiety dopuszczonych strumieni TCP mają zgodne numery sekwencji/potwierdzenia (sequence/acknowledgement), rozmiary segmentów, itd. pakietów. Kiedy wykryje, że pakiet jest nieakceptowalny (out of the window), zaznacza go jako INVALID i drukuje komunikat. Nowsze wersje logują pakiet i dokładny warunek, którego nie spełnił: ACK is under the lower bound (prawdopodobnie zbyt opóźniony ACK) ACK is over the upper bound (potwierdzane dane jeszcze nie dotarły) SEQ is under the lower bound (retransmitowano dane już potwierdzone) SEQ is over the upper bound (ponad oknem odbiorczym) Także, w nowszych wersjach logowanie można całkowicie wyłączyć poprzez sysctl echo 0 > /proc/sys/net/ipv4/netfilter/ip_ct_tcp_log_out_of_window Wpierw, sprawdzy czy nie używasz jądra 2.4.20. Jeśli tak, zaplikuj natychmiast patch spod adresu: �! The 2.4.20 kernel did contain a bug resulting in lots of bogus UNREPLIED conntrack entries (see �). Sprawdziłeś /proc/net/ip_conntrack i znalazłeś wpisy połączeń w stanie UNREPLIED o bardzo wysokim czasie (aż do pięciu dni) i zastanawiasz się dlaczego marnujemy wpisy conntrack (które oczywiście nie są połączeniami)? Odpowiedź jest prosta: wpisy UNREPLIED są tymczasowe, tj. jak tylko zabraknie miejsca (osiągniemy /proc/sys/net/ipv4/ip_conntrack_max), kasujemy stare wpisy UNREPLIED. Innymi słowy zamiast trzymać puste wpisy, wolimy trzymać prawdopodobnie cenne informacje dopóki wolne wpisy są naprawdę potrzebne. Po pierwsze dlatego, że jesteśmy leniwi ;). A szczerze mówiąc, implementacja opcji check jest prawie niemożliwa jak tylko zaczynamy stateful firewalling. Tradycyjne firewalle nie przetrzymujące informacji o stanie połączenia (są stateless) opierają swoje decyzje tylko w oparciu o informacje zawarte w nagłówkach pakietów. A że śledzeniem połączeń (i regułami opartymi o '-m state'), decyzja o filtrowaniu zależy od nagłówka+dane, a także od nagłówka+dane poprzednich pakietów danego połączenia. REJECT stosuje się do filtrowania. Tabela filter ma łańcuchy INPUT/OUTPUT/FORWARD, zatem REJECT może być użyty tylko w tych łańcuchach (i pod-łańcuchach, rzecz jasna). Użytkownicy Netfiltra nie filtrują pakietów w tabelach nat lub mangle. Własnie zaktualizowałeś jądro i nagle niektóre komendy (szczególnie w tabeli 'nat'), powodują ten komunikat, np: # iptables -A POSTROUTING -t nat -o ppp0 -j MASQUERADE iptables: Invalid argument To się zdarza gdy rozmiary struktur między przestrzenia jądra a użtykownika się zmieniają. Będziesz musiał ponownie skompilować program przestrzeni użtykownika używając plików nagłowkowych swojego nowego jądra. To się zdarza tylko gdy zaaplikowałes (ty, lub dostawca twojego jądra) niektóre łaty do starego lub tylko do nowego jądra. Nie powinno to się zdarzać z waniliowymi jądrami z kernel.org. Jeśli jednak, poinformuj proszę o tym listę netfilter-devel. Target REJECT służy do filtrowania. Tabela filter ma łańcuchy INPUT/OUTPUT/FORWARD, zatem REJECT może być tylko używany w tych łańcuchach (i podłańcuchach, naturalnie). Użytkownicy netfiltra nie filtrują pakietów w tabeli nat czy mangle. Biblioteka zwana libipq jest dostarczona do obsługi pakietów z przestrzeni użytkownika. (userspace). Jest dokumentacja do tego w postaci stron w manualu. Musisz skompilować i zainstalować komponenty rozwojowe iptables: make install-devel potem zobacz libipq(3). Może także będziesz zainteresowany implementacją libipq dla Perla, Perlipq w: �. Sama implementacja jest przykładem użycia biblioteki. Inne przykłady kodu: testsuite/tools/intercept.c z CVS netfiltra ipqmpd (zobacz �) nfqtest, część netfilter-tools (zobacz �) Jerome Etienne's WAN simulator (zobacz �) Oznacza to, że bufor gniazda (socket) Netlink po stronie jądra wyczerpał pamięć; aplikacja przestrzeni użytkownika nie jest w stanie obsłużyć ilości danych dostarczonych z jądra. Czy jest możliwe by zwiększyć bufory jądra bym nie wpadał na ten problem? Tak, są to standardowe gniazda (sockety) Netlink i możesz dostroić rozmiary buforów wejściowych (receive buffer) poprzez /proc/sys/net/core, sysctl lub używać opcji gniazda (socketa) SO_RCVBUF na deskryptorze pliku. Możesz także spróbować zapewnić by aplikacja czytała dane najszybciej jak to jest możliwe. Jeśli nie potrzebujesz całego pakiety, spróbuj kopiować mniej danych do przestrzeni użytkownika (zobacz ipq_set_mode(3)). Główny zespół netfiltra utrzymuje listę TODO, która zawiera porządane zmiany / nowe cechy. Możesz pobrać tę listę poprzez anonimowy CVS, instrukcje są na stronie głównej netfiltra. Ewentualnie możesz także pobrać przez CVSweb � Jeśli chcesz to opublikować, wyślij to listy dyskusyjnej netfilter-devel. Instrukcja jak zostać subskrybentem jest w �. Prawidłowy sposób wysyłania łat: Temat zaczynający się od [PATCH] Załączone prosto w ciele wiadomości, bez MIME. wpis cvs-checkin/Changelog poza diffem. forma `diff -u old new', spoza katalogu root pakietu (tj. może być stosowany z -p1 będąc pod odtarowanym katalogiem. Jeśli napisałeś nowe rozszerzenie, lub dodałeś nowe opcje do starego rozszerzenia, zwykle dobrze jest zaktualizować także netfilter-extension-HOWTO by włączyć opis nowej funkcjonalności. Dodatkowo, przyciągnie to więcej użytkowników do rozszerzenia i pozwoli na uzyskanie więcej informacji od użytkowników.