Erkennt iptables bzw. netfilter Antworten auf Broadcasts nicht als RELATED?

31/08/2007 - 21:04 von Hauke Laging | Report spam
Moin,

ich kàmpfe mich gerade durch einen Wust von Netzwerkproblemen und hoffe,
wenigstens eins davon jetzt mal gut isoliert zu haben. Der Hintergrund:
Meine Samba-Rechner werden nicht per Broadcast gefunden. Ich habe das mal
von einer Linuxkiste mit smbclient getestet und bin mal mit tcpdump meinen
Paketen hinterhergelaufen.

Irgendwann zeigt sich: Die kommen an - und auch zurück. Aber mein
anfragender Host (SuSe 10.0) wirft die Antworten weg. Wenn das mal nicht
làssig ist...

Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
2 180 ACCEPT 0 -- * * 192.168.115.43
0.0.0.0/0
25 4442 ACCEPT 0 -- * * 192.168.115.11
0.0.0.0/0
50896 3168K ACCEPT 0 -- lo * 0.0.0.0/0
0.0.0.0/0
723K 387M ACCEPT 0 -- * * 0.0.0.0/0
0.0.0.0/0 state RELATED,ESTABLISHED

So sieht das jetzt aus. Nachdem ich über die ersten beiden Regeln die
fraglichen Rechner "freigeschaltet" habe, findet smbclient sie. Warum
schafft die nun vierte Regel es bitte nicht, die Antworten als RELATED zu
erkennen? Ist das so eine große Herausforderung bei Broadcasts?

Google findet dazu quasi nichts. Das müsste doch ein Allerweltsproblem
sein!?


CU

Hauke
 

Lesen sie die antworten

#1 Juergen P. Meier
01/09/2007 - 05:03 | Warnen spam
Hauke Laging :
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
2 180 ACCEPT 0 -- * * 192.168.115.43
0.0.0.0/0
25 4442 ACCEPT 0 -- * * 192.168.115.11
0.0.0.0/0
50896 3168K ACCEPT 0 -- lo * 0.0.0.0/0
0.0.0.0/0
723K 387M ACCEPT 0 -- * * 0.0.0.0/0
0.0.0.0/0 state RELATED,ESTABLISHED

So sieht das jetzt aus. Nachdem ich über die ersten beiden Regeln die
fraglichen Rechner "freigeschaltet" habe, findet smbclient sie. Warum
schafft die nun vierte Regel es bitte nicht, die Antworten als RELATED zu
erkennen? Ist das so eine große Herausforderung bei Broadcasts?



Weil das fuer netfilter kein RELATED traffic ist.

Google findet dazu quasi nichts. Das müsste doch ein Allerweltsproblem
sein!?



Dein Regelwerk ist falsch bezuglich SMB kommunikation. SMB als
Konzept ist eine Krankheit, und prinzipiell so konzipiert, dass
jeder Kokmmunikationsteilnehmer strenggenommen sowohl als Client als
auch als Server fuer bestimmte Teilaufgaben (insb. Namensaufloesung)
fungiert. Diesem Umstand muss dein Regelwerk Folge tragen:

Du brauchst folgende Regeln (angenommen dein LAN ist 192.168.115.0/24)
-s 192.168.115.0/24 -d udp -m multiport --dports 135,137,138,139 -j ACCEPT
-s 192.168.115.0/24 -d tcp -m multiport --dports 137,139,445 -j ACCEPT

Wenn du sicher bist, dass du ausschliesslich CIFS verwendest in
deinem Wintendo-Netz, kannst du alles bis auf 135 und 445 weglassen.

Ansonsten: immer erst das Protokoll verstehen, bevor man sich an ein
Paketfilterregelwerk dafuer machen kann. Nur wenn die
Paketfiltersoftware einem dieses Verstehen abnehmen kann, reicht idR.
ein "Erlaube $PROTOKOLL eingehend" in der jeweiligen Filtersprache.
Nur bei einfachen Protokollen wie HTTP, telnet, SSH o.ae. ist das
trivial. Und selbst bei anscheinend einfachen Protokollen wie SMTP,
POP3 und imap hat man ausserhalb des Protokollkontextes (im
Applikationskontext genauer) abhaengigkeiten von dritten Protokollen
(hier Ident), die man als Paketfilterkonfigurator nicht uebersehen
darf.

Bei Netfilter "verstehet" die Software nur diejenigen Protokolle, fuer
die eigene conntrack-helpermodule vorhanden sind (z.B.: FTP, h.323)
und das auch immer nur mit Einschraenkungen. Alle anderen Protokolle
musst du "zu Fuss" auf Schichten 3 und 4 abbilden. Bei so einem
eklilgen Konglomarat wie SMB/NetBIOS ist das nicht ganz so einfach.

Juergen
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)

Ähnliche fragen