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:
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ą: http://lists.netfilter.org/mailman/listinfo/netfilter-devel.
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 http://bridge.sourceforge.net/
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
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ł:
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: https://bugzilla.netfilter.org/cgi-bin/bugzilla/showattachment.cgi?attach_id=8! The 2.4.20 kernel did contain a bug resulting in lots of bogus UNREPLIED conntrack entries (see https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=56).
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.