|
Hallo Leute, da bin ich mal wieder mit meinem
leider immer noch aktuellen Problem (siehe problem.txt).
Es handelt sich tatsächlich um netbios-Anfragen,
gerade wenn man von Win-Rechnern die option Computer suchen einsetzt. Danach
wählt sich der Linux-Rechner automatisch ein...
Ich habe die Vorschläge von Ramin und Andreas
beherzigt und einmal Einträge in device.ippp0 gemacht der Art ifconfig ... -arp
-broadcast ..., doch nach Neustart etc und Eingane von ifconfig zeigte die
Auflistung lediglich NOARP nicht aber NOBRADCAST oder ähnlich. Somit scheiterte
dieser Versuch.
Daraufhin habe ich nochmals unter
/etc/ipmasq/rules/ZZZdenyandlog.rul
ipchains-Einträge ausprobiert der Art:
$IPCHAINS -A output -j
DENY -i ippp0 -p UDP -d 0/0 136:139
$IPCHAINS -A output -j DENY -i ippp0 -p TCP -d 0/0 136:139 $IPCHAINS -A forward -j DENY -i ippp0 -p UDP -d 0/0 136:139 $IPCHAINS -A forward -j DENY -i ippp0 -p TCP -d 0/0 136:139 um den Verkehr auf diesen Ports zu sperren. Nach
restart von ipmasq erhalte ich folgende Meldungen auf ipchains -L:
DENY all
----l- 192.168.1.0/24
anywhere
n/a
DENY all ----l- anywhere anywhere n/a Chain forward (policy DENY): target prot opt source destination ports MASQ all ------ 192.168.1.0/24 anywhere n/a DENY all ----l- anywhere anywhere n/a DENY udp ------ anywhere anywhere any -> 136: netbios-ssn DENY tcp ------ anywhere anywhere any -> 136: netbios-ssn Chain output (policy DENY): target prot opt source destination ports ACCEPT all ------ anywhere anywhere n/a ACCEPT all ------ anywhere 192.168.1.0/24 n/a ACCEPT !tcp ------ anywhere BASE-ADDRESS.MCAST.NET/4 any -> any ACCEPT all ------ 134.147.0.0/16 anywhere n/a DENY all ----l- anywhere 192.168.1.0/24 n/a DENY all ----l- anywhere anywhere n/a DENY udp ------ anywhere anywhere any -> 136: netbios-ssn DENY tcp ------ anywhere anywhere any -> 136: netbios-ssn Scheint so, als wär die Message angekommen. Dch
sobald ich Netzwerkumgebung oder Computer suchen unter Win aufrufe,
kommt es wieder zu Verbindungsaufbauten unter
Anfragen an Port137 (manchmal auch 138).
Warum ist das so? Warum wird dennoch eingewählt?
Einen weiteren Tip, nämlich bind so zu
konfigurieren, das der dns workgroup.domain.de heist (wonach die Win-Rechner
wohl suchen), habe ich noch nicht verfolgt, da es mir nur als allerletztes
Mittel der Not erscheint.
Vielleicht waere es noch sinnvoll, mit dem
route-Befehl herumzuexperimentieren.
Langsam verzweifele ich.
Bitte helft mir und lasst Euch nicht davon
abschrecken, dass ich diesmal etwas ausführlicher schreibe.
Ich habe meine Arbeit protokolliert, für den Fall,
dass jemand sich wirklich die Mühe machen will, um mir zu helfen.
Auch ein par messages unter /var/log/messages habe
ich mal mit angefügt.
Für Ratschläge bin ich sehr dankbar.
Herzlichst,
Holger
|
Siehe auch isdn/udp3 (Nachricht von mir)...
Hallo nochmals,
habe inzwischen die Vermutung, dass mein eben geschildertes Problem irgendwas mit Samba oder netbios zu tun hat, da offensichtlich die Ports 137-139 angesprochen werden, worauf ein Verbindungsaufbau erfolgt.
Mein Problem ist, dass ich durch den Syntax der ipchains nicht so ganz durchblicke trotz howto und manpages. Ich habe deshalb man einen Eintrag in
/etc/ipmasq/rules/ZZZdenyandlog.rul gemacht (schien mir sinnvoll) der Art:
$IPCHAINS -A input -j DENY -i ippp0 -p UDP -d 0.0.0.0 netbios-ns
$IPCHAINS -A input -j DENY -i ippp0 -p UDP -d 0.0.0.0 netbios-dgm
$IPCHAINS -A input -j DENY -i ippp0 -p UDP -d 0.0.0.0 netbios-ssn
$IPCHAINS -A input -j DENY -i ippp0 -p TCP -d 0.0.0.0 netbios-ns
$IPCHAINS -A input -j DENY -i ippp0 -p TCP -d 0.0.0.0 netbios-dgm
$IPCHAINS -A input -j DENY -i ippp0 -p TCP -d 0.0.0.0 netbios-ssn
Ich glaube aber, dass die Syntax falsch ist, denn obwohl nach einem restart ipchains -L genau diese Eintraege zeigt, werden weitere Anfragen an Port 137-139 gemeldet und loesen einen Verbindungsaufbau aus. Es hat vielleicht etwas mit der Verwechslung source/dest. zu tun, doch wie gesagt, ich verstehe die ipchains-Parameter nicht sehr...
Bin ich mit meiner Vermutung total auf dem Holzweg, oder liesse sich mein Problem tatsaechlich mit einem funktionierendem Eintag mittels ipchains loesen.
Wenn ja, koennte mir vielleicht einer verraten, wie der waere?
Vielen Dank
______________________
Erste Nachricht:
Hallo zusammen...
Versuche ein kleines Netz von Fensterblöd-Rechnern über einen Linux-Rechner (Potato, ISDN) mit dem Internet zu verbinden.
Habe mich bereits mit ip-masq etc. auseinandergesetzt. Der Zugang aller Rechner ist auch hergestellt. http etc funktionieren.
Leider kommt es zu unerwuenschten Einwaehlversuchen etwa alle 2 Minuten mit der Meldung unter /var/log/messages:
kernel: OPEN: ip-adresse1 -> ip-adresse2 UDP, port :137,
wonach der Verbindungsaufbau initiiert wird.
Ebenso haeufige Meldungen:
Packet log: input DENY ippp0 PROTO=17 ip-adresse1
26:137 ip-adresse2:137 L=96 S=0x00 I=982 F=0x0000 T=64 (#6)
Es scheint alles daraufhin zu deuten, dass es irgendwelche dns-Anfragen der Fensterblöd-Rechner sind. Verstehe ich aber nicht, da ich auf der Linux-Maschine bind eingerichtet habe und entsprechend meinen eigenen DNS anspreche.
Kann mir irgendeiner helfen?
Vielen Dank fuer die Ratschlaege im voraus
MFG Holger
Attachment:
arbeit.log
Description: Binary data
Mar 3 16:35:41 helios kernel: Packet log: input DENY ippp0 PROTO=17 134.147.5.2 24:137 134.147.255.255:137 L=96 S=0x00 I=1020 F=0x0000 T=64 (#6) Mar 3 16:35:42 helios kernel: Packet log: input DENY ippp0 PROTO=17 134.147.5.2 24:137 134.147.255.255:137 L=96 S=0x00 I=1023 F=0x0000 T=64 (#6) Mar 3 16:35:42 helios kernel: Packet log: input DENY ippp0 PROTO=17 134.147.5.2 24:137 134.147.255.255:137 L=96 S=0x00 I=1024 F=0x0000 T=64 (#6) Mar 3 16:35:42 helios kernel: Packet log: input DENY ippp0 PROTO=17 134.147.5.2 24:137 134.147.255.255:137 L=96 S=0x00 I=1025 F=0x0000 T=64 (#6) Mar 3 16:35:42 helios kernel: Packet log: input DENY ippp0 PROTO=17 134.147.5.2 24:137 134.147.255.255:137 L=96 S=0x00 I=1026 F=0x0000 T=64 (#6) Mar 3 16:35:42 helios kernel: Packet log: input DENY ippp0 PROTO=17 134.147.5.2 24:137 134.147.255.255:137 L=96 S=0x00 I=1027 F=0x0000 T=64 (#6)