ICMP Redirect und SSH
Jan-Benedict Glaw
jbglaw at lug-owl.de
Wed Nov 20 12:39:02 CET 2002
On Wed, 2002-11-20 12:06:00 +0100, Markus Wigge <markus at cultcom.de>
wrote in message <3DDB6C98.1040206 at cultcom.de>:
> Der Fehler scheint dabei aber durch den Router verursacht zu werden, da
> die Anfrage für das NFS-Laufwerk laut Log-File vom Router kommt und der
> nicht die Berechtigung hat. Evtl. muß ich wohl doch nochmal die
> Filterregeln kontrollieren ob da nicht doch noch maskiert wird ?!
Allerdings...
> Bei ipchains wird doch immer die 1. zutreffende Regeln benutzt oder habe
> ich das falsch in Erinnerung?
So ist's.
> >...und ich wette, solange Du da immer brav tippst und nicht allzuviel
> >andere Rechner am Arbeiten sind (-> mit Netznutzung) bleibst Du auch
> >"drin". Nur, wenn Du längere Zeit aussetzt, ist bei dem nächsten
> >Tastendruck die Wahrscheinlichkeit, abgeschossen zu werden, wieder
> >fifty/fifty...
>
> Nein, wenn ich drin bin bleibe ich auch drin, egal was sonst noch so im
> Netz los ist. Ich fliege erst wieder wenn die Routen im Cache expiren.
...oder anders ausgedrückt: wenn Du die IP-Adresse die Ziels (bzw. des
Routers) neu ausfindig machen mußt.
> Wenn ich die restlichen Ausführungen so lese komme ich allerdings auch
> zu der Überzeugung das es nicht nur an den Redirects liegen kann,
> sondern diese nur durch einen Nebeneffekt Probleme machen.
Jupp..
> Ich vermute mehr und mehr das Problem auf dem Router, zur Sicherheit
> schicke ich mal kurz die Config in Auszügen mit.
>
> bye
> Markus
> Versuch 1:
> ------------------------------
> zhadum:~ # ssh markus at gandalf
> write: Connection reset by peer
>
> tcpdum auf gandalf (jeweils "tcpdump port 22 -n")
Schlecht. Dadurch dieht man die ICPM redirects udn die arp
requests/responses nicht. Gerade um die geht's aber...
> tcpdump: listening on eth0
> 11:34:54.089005 192.168.2.1.61975 > 192.168.2.42.22: S 3520298361:3520298361(0) win 5840 <mss 1460,sackOK,timestamp 541819[|tcp]> (DF)
> 11:34:54.089064 192.168.2.42.22 > 192.168.2.1.61975: S 3581339452:3581339452(0) ack 3520298362 win 32120 <mss 1460,sackOK,timestamp 129676458[|tcp]> (DF)
> 11:34:54.161250 192.168.2.1.61975 > 192.168.2.42.22: . ack 1 win 5840 <nop,nop,timestamp 541819 129676458> (DF)
> 11:34:54.162745 192.168.2.42.22 > 192.168.2.1.61975: P 1:23(22) ack 1 win 32120 <nop,nop,timestamp 129676465 541819> (DF)
> 11:34:54.180782 192.168.3.16.1030 > 192.168.2.42.22: . ack 3581339475 win 5840 <nop,nop,timestamp 541819 129676465> (DF)
> 11:34:54.180838 192.168.2.42.22 > 192.168.3.16.1030: R 3581339475:3581339475(0) win 0
> 11:34:57.157707 192.168.2.42.22 > 192.168.2.1.61975: P 1:23(22) ack 1 win 32120 <nop,nop,timestamp 129676765 541819> (DF)
> 11:34:57.158259 192.168.3.16.1030 > 192.168.2.42.22: R 3520298362:3520298362(0) win 0 (DF)
> 11:35:03.157990 192.168.2.42.22 > 192.168.2.1.61975: P 1:23(22) ack 1 win 32120 <nop,nop,timestamp 129677365 541819> (DF)
> 11:35:03.158508 192.168.3.16.1030 > 192.168.2.42.22: R 3520298362:3520298362(0) win 0 (DF)
Jo. so sehen typische, doppelt vergebene IP-Adressen aus...
Bitte mach' nochmal 'nen tcpdump, und dann mit den ICMPs und den
ARP-Geschichten.
Dabei vorher:
arp -d <IP vom Router>
Sollte die MAC-Adresse vom Ziel auch bei 'arp -an' aufgelistet sein,
diese ebenfalls mit
arp -d <Ziel-IP>
löschen.
...und dann während des einloggens folgende Zeilen laufen lassen:
#!/bin/sh
#
# This is script #1
#
while arp -an >> /tmp/mac-adressen; do
:
done
# End if script #1
Nach dem 'Connection reset by peer' den Output von
cat /tmp/mac-adressen | uniq -c
hierher schicken.
> router> ifconfig
> eth0 Link encap:Ethernet HWaddr 00:50:DA:44:F9:9E
> inet addr:192.168.2.1 Bcast:192.168.2.255 Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:195084981 errors:0 dropped:0 overruns:0 frame:0
> TX packets:301631186 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:100
> Interrupt:15 Base address:0xe000
>
> eth0:1 Link encap:Ethernet HWaddr 00:50:DA:44:F9:9E
> inet addr:192.168.3.1 Bcast:192.168.3.255 Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> Interrupt:15 Base address:0xe000
>
> eth1 -> nur das Interface nach au?en
>
> lo -> Wie ?berall halt ...
>
> router> route -n
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use Iface
> 192.168.42.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
> 192.168.8.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
> 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
...und wo sind die Routen für 192.168.3.0/24 und 192.168.2.0/24? Das
sind doch immerhin lokale interfaces, und zudem ist das der eigentliche
Teil der Routing-Aufgaben!
> # Die Routen nach au?en habe ich der ?bersichtlichkeit wegen mal entfernt,
> # darunter ist auch die default-route...
>
> router> ipchains -L -n
> Chain input (policy ACCEPT):
> target prot opt source destination ports
> # Hier gab es noch Beschr?nkungen f?r den Zugriff von au?en (destination war
> # nur die eth1-IP)
> Chain forward (policy DENY):
> target prot opt source destination ports
> ACCEPT all ------ 192.168.3.0/24 194.168.2.0/24 n/a
> ACCEPT all ------ 194.168.2.0/24 192.168.3.0/24 n/a
> MASQ all ------ 192.168.8.0/24 0.0.0.0/0 n/a
> MASQ all ------ 192.168.42.0/24 0.0.0.0/0 n/a
> Chain output (policy ACCEPT):
Sieht nicht falsch aus. Aber ich hab' da so lange nichts mehr gemacht,
das da vielleicht noch ein anderer seinen Senf zugeben sollte.
MfG, JBG
--
Jan-Benedict Glaw jbglaw at lug-owl.de . +49-172-7608481
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur
fuer einen Freien Staat voll Freier Bürger" | im Internet!
Shell Script APT-Proxy: http://lug-owl.de/~jbglaw/software/ap2/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lug-owl.de/pipermail/linux/attachments/20021120/5cc555cf/attachment.sig>
More information about the Linux
mailing list