Hallo Liste, habe hier ein ganz seltsames Problem: Ein Masquerading-Router (Kernel 2.2.19 - SuSEfirewall 4.6) soll den Zugriff auf einen im lokalen Netz vorhandenen FTP-Server ermöglichen, dazu ist in firewall.rc.config folgendes gesetzt: FW_FORWARD_MASQ_TCP="0/0,192.168.1.5,21" Wenn ich nun von aussen versuche zuzugreifen, funktioniert der login, der Verzeichnisinhalt wird angezeigt, beim Versuch eine Datei zu kopieren fängt er allerdings mit 4.x k/s an, dann scheint die Verbindung zu "verhungern". Um dem auf den Grund zu gehen, hab ich mal den Parameter LOG_ACCEPT_ALL="yes" gesetzt, und auf einmal läuft das wie geschmiert mit 7.5 k/s konstanter Geschwindigkeit, wie sich´s gehört. Ich seh da den Zusammenhang nicht, hab es aber mehrfach ausprobiert. Es hängt definitiv mit diesem Eintrag zusammen.. Hier weiss ich nun wirklich nicht mehr, wo ich suchen soll, hat vielleicht jemand einen Tip für mich? Danke! Matthias
Hallo nochmal, :) Matthias Rahn schrieb:
Hallo Liste,
habe hier ein ganz seltsames Problem:
Ein Masquerading-Router (Kernel 2.2.19 - SuSEfirewall 4.6) soll den Zugriff auf einen im lokalen Netz vorhandenen FTP-Server ermöglichen,
[...bla-blubb...] Hm, es kommt noch besser. Hab jetzt mal den Verkehr bei der Daten- übertragung in beiden Fällen per tcpdump mitgeloggt, das Ergebnis ist jetzt erst recht verwirrend.... :) Hier erst mal mein (derzeitiges) Setup, ergänzend zum ersten Posting: INTERNET | --------------- | Masq-Router | --------------- | ------------- --------- |-----| FTP-Server | | Sniffer |--| | 192.168.1.5 | --------- | ------------- -------- | Router | -------- | ------------------ | FTP + NFS-Server | | 192.168.2.3 | ------------------ Das FTP Verzeichnis des inneren FTP-Servers wird ro exportiert und vom äusseren FTP als public FTP-Verzeichnis gemountet: Auf dem NFS: #/etc/exports /usr/local/ftp/pub 192.168.1.5(ro,insecure,all_squash) Auf dem FTP: # mount -t nfs 192.168.2.3:/usr/local/ftp/pub /usr/local/ftp/pub Auf dem Masq-Router (SuSEfirewall 4.6): #/etc/rc.config.d/firewall.rc.config FW_FORWARD_MASQ_TCP="0/0,192.168.1.5,21" Im ersten Posting hab ich ja schon geschildert, wie sich das ganze verhält, jetzt habe ich allerdings mal für beide Fälle den Verkehr auf- gezeichnet und es zeigt sich, dass das Problem nicht beim FTP-Transfer liegt, sondern beim NFS-Transfer vom inneren zum äusseren Router. Der definitiv einzige Unterschied - das habe ich mittlerweile *zig* mal ausprobiert - ist, dass auf dem Masquerading Router (!) die Regel FW_LOG_ACCEPT_ALL verändert wird. Die beiden Logs hab ich mal angehängt, sie wurden per # tcpdump -l -n -v > logfile erstellt, auffällig könnte dabei sein, dass Portnummern teilweise nach Namen aufgelöst werden, obwohl der Parameter -n gesetzt ist. :o\ 213.7.25.39 ist in allen Fällen die IP des Internet-Clients. Beim ersten Log, ist auf dem Masq-Router FW_LOG_ACCEPT_ALL="yes" gesetzt, die Übertragung funktioniert reibungslos. Während des gesamten Übertragungsvorgangs scheinen NFS und FTP nur zwei mal kurz Pakete auszutauschen, nämlich folgender Art: 192.168.1.5.2344796719 > 192.168.2.3.2049: 108 getattr fh Unknown/1 (DF) (ttl 64, id 0) 192.168.2.3.2049 > 192.168.1.5.2344796719: reply ok 96 getattr REG 100644 ids 0/0 sz 1232295 (ttl 63, id 31871) 192.168.1.5.2361573935 > 192.168.2.3.2049: 108 getattr fh Unknown/1 (DF) (ttl 64, id 0) 192.168.2.3.2049 > 192.168.1.5.2361573935: reply ok 96 getattr REG 100644 ids 0/0 sz 1232295 (ttl 63, id 31873) Was soll ich denn in dem Fall von den Portnummern halten? Sieht nicht so nach 16 Bit aus und in /etc/services sind sie auch nicht als Name zu finden. Davon mal abgesehen kommt das File allerdings einwandfrei an!? :) Beim zweiten Log ist auf dem Masq-Router FW_LOG_ACCEPT_ALL="no" ge- setzt, hier passiert seltsames. Zuerst ein paar Pakete dieser Art: 192.168.1.5.851624495 > 192.168.2.3.2049: 120 lookup fh Unknown/1 [|nfs] (DF) (ttl 64, id 0) 192.168.2.3.2049 > 192.168.1.5.851624495: reply ok 128 lookup fh Unknown/1 DIR 40755 ids 0/0 sz 4096 (ttl 63, id 31777) Oops, das ging wohl schief. Und der FTP-Transfer scheint in der Folge mächtig durcheinanderzukommen, bis irgendwann garnix mehr geht. Werde mich übers Wochenende wohl mal dran machen müssen, die tcpdump Ausgabe im Detail zu verstehen, aber nichtsdestotrotz frage ich mich doch, wie eine Einstellung auf dem Masq-Router - auch noch das Logging betreffend - die Übertragung zwischen FTP und NFS dergestalt beeinflussen kann. Spontan käme mir vielleicht ein LKM/Rootkit in den Sinn, das an SuSE angepasst ist und in Code-Red-Manier über mein gesamtes Netzwerk hergefallen ist. Zugegebenermassen bin ich mit Patchen etwas nach- lässig und leiste mir auch sonst den ein oder anderen Spaß, der aus sicherheitstechnischer Sicht bedenklich ist, aber ist ja auch mein privates Netz hier. Oder wäre der Gedanke übertrieben paranoid? Vielleicht kommt ja jemandem diese ganze Mimik bekannt vor, ich wäre jedenfalls für jeden Tip dankbar, der - wie auch immer - etwas Licht ins Dunkel bringt. :) Schönes Wochenende, Matthias
Hallo nochmal, Ups, da hatte ich falsch eingefügt, sorry... :) Matthias Rahn schrieb: [...]
Beim zweiten Log ist auf dem Masq-Router FW_LOG_ACCEPT_ALL="no" ge- setzt, hier passiert seltsames. Zuerst ein paar Pakete dieser Art:
192.168.1.5.851624495 > 192.168.2.3.2049: 120 lookup fh Unknown/1 [|nfs] (DF) (ttl 64, id 0)
192.168.2.3.2049 > 192.168.1.5.851624495: reply ok 128 lookup fh Unknown/1 DIR 40755 ids 0/0 sz 4096 (ttl 63, id 31777)
Die ersten paar sehen ja noch ganz gut aus, die Bösen sehen - wie auch aus den Logs ersichtlich - dann eher so aus: 192.168.1.5.918733359 > 192.168.2.3.2049: 124 lookup fh Unknown/1 [|nfs] (DF) (ttl 64, id 0) 192.168.2.3.2049 > 192.168.1.5.918733359: reply ok 28 lookup ERROR: No such file or directory (ttl 63, id 31781) <humor> Tscha, wenn niemand antworten kann/will, mach ich mir meinen Thread halt alleine. </humor> Sorry nochmal für die Umstände ;) Grüsse, Matthias
Hallo Matthias,
From the keyboard of Matthias,
Hallo nochmal,
Ups, da hatte ich falsch eingefügt, sorry... :)
Matthias Rahn schrieb: [...]
Beim zweiten Log ist auf dem Masq-Router FW_LOG_ACCEPT_ALL="no" ge- setzt, hier passiert seltsames. Zuerst ein paar Pakete dieser Art:
192.168.1.5.851624495 > 192.168.2.3.2049: 120 lookup fh Unknown/1 [|nfs] (DF) (ttl 64, id 0)
192.168.2.3.2049 > 192.168.1.5.851624495: reply ok 128 lookup fh Unknown/1 DIR 40755 ids 0/0 sz 4096 (ttl 63, id 31777)
Die ersten paar sehen ja noch ganz gut aus, die Bösen sehen - wie auch aus den Logs ersichtlich - dann eher so aus:
192.168.1.5.918733359 > 192.168.2.3.2049: 124 lookup fh Unknown/1 [|nfs] (DF) (ttl 64, id 0)
192.168.2.3.2049 > 192.168.1.5.918733359: reply ok 28 lookup ERROR: No such file or directory (ttl 63, id 31781)
Wirklich strange. Ich kann dein Problem nicht lösen, aber ich versuche dir mal zwei sinnvolle Ratschläge zu geben. 1.) Nachdem du das Paketfilterskript gestartet hast, speichere das Regelwerk in eine Datei. man ipchains Danach wiederhole das gleiche mit dem anderen Parameter. Und zuletzt machst du ein diff regelnmitlog regelnohnelog Damit gehst du eine Ebene tiefer und kannst Bugs im Skript ausschließen, könnte ja sein das diese Option noch irgendwelche Seiteneffekte bewirkt, die du garnicht bemerkst. 2.) Mach einen tcpdump von dem Netzwerkverkehr, den du mit ethereal lesen kannst. Das ist für die Analyse wesentlich besser geeignet. Deine vorhandenen Logs lassen sich nicht öffnen. man tcpdump / Hilfe von Ethereal
<humor> Tscha, wenn niemand antworten kann/will, mach ich mir meinen Thread halt alleine. </humor>
Ne, da muß ich einschreiten ;)
Sorry nochmal für die Umstände ;)
Kleiner Hinweis, beim nächsten mal am besten keine Logs mitschicken und lieber warten, ob sie einer explizit anfordert. Bandbreitenverschwendung. Und zusätzlich besser komprimieren $ ls -s logs.tar.bz2 16 logs.tar.bz2 $ ls -s logs.zip 24 logs.zip Das sind 50%! ;) bye Waldemar
Hallo, Waldemar Brodkorb schrieb:
Hallo Matthias,
From the keyboard of Matthias,
Hallo nochmal,
Ups, da hatte ich falsch eingefügt, sorry... :)
Matthias Rahn schrieb: [...]
Beim zweiten Log ist auf dem Masq-Router FW_LOG_ACCEPT_ALL="no" ge- setzt, hier passiert seltsames. Zuerst ein paar Pakete dieser Art:
[...]
Wirklich strange.
Das beruhigt mich zumindest einigermassen, dass nicht nur ich das strange finde. :)
1.) Nachdem du das Paketfilterskript gestartet hast, speichere das Regelwerk in eine Datei. man ipchains Danach wiederhole das gleiche mit dem anderen Parameter. Und zuletzt machst du ein diff regelnmitlog regelnohnelog
Das hab ich sogar schon mal gemacht (als allererstes, per ipchains -L -n > log), die einzigen Unterschiede bestanden aber tat- sächlich im gesetzen Log-Flag, ansonsten waren die Regeln absolut gleich. Habe das dann auf dieser Ebene erst mal nicht weiterverfolgt da sich mir natürlich die Frage stellt, ob ich meinem ipchains auf dieser Kiste überhaupt noch trauen kann. Müsste wohl irgendwie erst mal dafür sorgen, dass ich mit einwandfreien binaries zu Werke gehe. Außerdem hab ich auch schon mal ins SuSEfirewall-Skript reingeschaut, ob da vielleicht irgendwas schief gehen könnte, mit den Variablen $LAA oder $LAC (vergessener Zeilenumbruch, Anführungszeichen, irgendwas in der Art) sieht aber eigentlich alles korrekt aus.
2.) Mach einen tcpdump von dem Netzwerkverkehr, den du mit ethereal lesen kannst. Das ist für die Analyse wesentlich besser geeignet. Deine vorhandenen Logs lassen sich nicht öffnen.
Komisch, habs extra zwei mal ausprobiert (unter Lin und Win).. :( Das mit dem ethereal werd ich nochmal probieren, danke.
Kleiner Hinweis, beim nächsten mal am besten keine Logs mitschicken
Oki, werd ich beherzigen :)
Bandbreitenverschwendung. Und zusätzlich besser komprimieren
Dachte mir, das .zip kompatibler ist, denn die meisten Linux-Distis können wohl mit beidem was anfangen, währenddessen der gemeine Win-Shareware-Entzipper vielleicht bei .bz2 die Ohren an- legt. Hätt ich allerdings auch mal einen Grössenvergleich gemacht, hätt ich wahrscheinlich doch auch .bz2 genommen. Jedenfalls vielen Dank für Deine Antwort, immerhin beruhigt sie mich schon mal ein wenig. :) Nächste Woche krieg ich die 7.3, da werd ich im Notfall dann einfach alles platt machen und von vorne anfangen, dann aber richtig und ein wenig vorsichtiger :) Aus Schaden wird man eben klug. Grüsse, Matthias
Hallo Matthias,
From the keyboard of Matthias,
Hallo,
Waldemar Brodkorb schrieb:
Hallo Matthias,
From the keyboard of Matthias,
Hallo nochmal,
Ups, da hatte ich falsch eingefügt, sorry... :)
Matthias Rahn schrieb: [...]
Beim zweiten Log ist auf dem Masq-Router FW_LOG_ACCEPT_ALL="no" ge- setzt, hier passiert seltsames. Zuerst ein paar Pakete dieser Art:
[...]
Wirklich strange.
Das beruhigt mich zumindest einigermassen, dass nicht nur ich das strange finde. :)
;)
1.) Nachdem du das Paketfilterskript gestartet hast, speichere das Regelwerk in eine Datei. man ipchains Danach wiederhole das gleiche mit dem anderen Parameter. Und zuletzt machst du ein diff regelnmitlog regelnohnelog
Das hab ich sogar schon mal gemacht (als allererstes, per ipchains -L -n > log), die einzigen Unterschiede bestanden aber tat- sächlich im gesetzen Log-Flag, ansonsten waren die Regeln absolut gleich. Habe das dann auf dieser Ebene erst mal nicht weiterverfolgt da sich mir natürlich die Frage stellt, ob ich meinem ipchains auf dieser Kiste überhaupt noch trauen kann. Müsste wohl irgendwie erst mal dafür sorgen, dass ich mit einwandfreien binaries zu Werke gehe.
Außerdem hab ich auch schon mal ins SuSEfirewall-Skript reingeschaut, ob da vielleicht irgendwas schief gehen könnte, mit den Variablen $LAA oder $LAC (vergessener Zeilenumbruch, Anführungszeichen, irgendwas in der Art) sieht aber eigentlich alles korrekt aus.
Dann würde ich echt mal Kernel 2.2.20 und aktuelle ipchains-Sourcen probieren, vielleicht ein Bug der schon gefixt wurde, kann man nie genau sagen, wenn man nicht aktuell ist.
2.) Mach einen tcpdump von dem Netzwerkverkehr, den du mit ethereal lesen kannst. Das ist für die Analyse wesentlich besser geeignet. Deine vorhandenen Logs lassen sich nicht öffnen.
Komisch, habs extra zwei mal ausprobiert (unter Lin und Win).. :(
Ich meinte mit Ethereal nicht analysierbar.
Das mit dem ethereal werd ich nochmal probieren, danke.
Gibts auch für Win.
Kleiner Hinweis, beim nächsten mal am besten keine Logs mitschicken
Oki, werd ich beherzigen :)
Bandbreitenverschwendung. Und zusätzlich besser komprimieren
Dachte mir, das .zip kompatibler ist, denn die meisten Linux-Distis können wohl mit beidem was anfangen, währenddessen der gemeine Win-Shareware-Entzipper vielleicht bei .bz2 die Ohren an- legt. Hätt ich allerdings auch mal einen Grössenvergleich gemacht, hätt ich wahrscheinlich doch auch .bz2 genommen.
Jedenfalls vielen Dank für Deine Antwort, immerhin beruhigt sie mich schon mal ein wenig. :)
Nächste Woche krieg ich die 7.3, da werd ich im Notfall dann einfach alles platt machen und von vorne anfangen, dann aber richtig und ein wenig vorsichtiger :) Aus Schaden wird man eben klug.
Bis dahin hast du ja noch Zeit der Sache auf die Spur zu kommen, die Lösung zu einem Problem zu finden ist doch schöner als im aus dem Weg zu gehen. Bei SuSE 7.3 und Kernel 2.4 wirst du wohl nicht mehr mit ipchains arbeiten, denke ich. bye Waldemar
participants (2)
-
Matthias Rahn
-
Waldemar Brodkorb