Hallo Matthias,
Das Firewall log zeigt, daß es NUR Probleme bei den ausgehenden TCP- Paketen gibt.
Aus dem Log müßte man die Regel, die Du benötigst, sofort ableiten können. Mail sie sonst doch mal rüber.
Etwa so: $IPTABLES -A FORWARD -s 192.168.10.61 -o ppp0 -p tcp \ --dport 6699 -j ACCEPT Das würde ja ausgehenden Traffic betreffen. Aber hier geht es um die Antwort-Pakete der eingehenden Verbindung...
Wenn ich das richtig sehe, wird der Client einen anderen Port als 6699 zum Senden benutzen - auf 6699 horcht er nur auf eingehende Verbindungen. Ganz davon abgesehen, hast Du nicht Regeln der folgenden Art? $IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT Damit wird generell jeder Rücktransfer auf einem TCP/IP Link erlaubt - das ist generell nicht gefährlich. Gruß, Thorsten.
At 22:01 01.03.03 +0100, Thorsten D. Marsen wrote:
Hallo Matthias,
Das Firewall log zeigt, daß es NUR Probleme bei den ausgehenden TCP- Paketen gibt.
Aus dem Log müßte man die Regel, die Du benötigst, sofort ableiten können. Mail sie sonst doch mal rüber.
In=eth0 out=ppp0 src=192.168.10.61 DST=123.123.123.123 LEN=48 TOS=0x00 PREC=0x00 ttl=127 id=9058 DF PROTO=TCP SPT=6699 DPT=3777 WINDOW=8472 RES=0x00 ACK SYN URGP=0 (von hand abgetippt, daraus lese ich: .10.61 versucht die Anfrage von .123 zu beantworten (6699 an 3777) ist dann der Rückkanal. Der Effekt tritt übrigens dann auf, wenn der Client hier die Verbindung fr den Upload aktivieren will, also wenn ein externer dann Daten kriegen soll.
Etwa so: $IPTABLES -A FORWARD -s 192.168.10.61 -o ppp0 -p tcp \ --dport 6699 -j ACCEPT Das würde ja ausgehenden Traffic betreffen. Aber hier geht es um die Antwort-Pakete der eingehenden Verbindung...
Wenn ich das richtig sehe, wird der Client einen anderen Port als 6699 zum Senden benutzen - auf 6699 horcht er nur auf eingehende Verbindungen.
Klar, 6699 wird nur gebraucht, wenn ich eine Datei suche
Ganz davon abgesehen, hast Du nicht Regeln der folgenden Art?
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
Damit wird generell jeder Rücktransfer auf einem TCP/IP Link erlaubt - das ist generell nicht gefährlich.
Nein, nicht grundsätzlich, sondern nur auf bestimmten Ports. Die Firewall ist hier ganz fürchterlich dicht gezogen, so daß wirklich nur der Traffic durchgeht der ausdrücklich gewünscht ist. Grundsätzlich wird nichts und niemand getraut. ;-) Gruß Matthias
Hallo Matthias,
In=eth0 out=ppp0 src=192.168.10.61 DST=123.123.123.123 LEN=48 TOS=0x00 PREC=0x00 ttl=127 id=9058 DF PROTO=TCP SPT=6699 DPT=3777 WINDOW=8472 RES=0x00 ACK SYN URGP=0
Etwa so: $IPTABLES -A FORWARD -s 192.168.10.61 -o ppp0 -p tcp \ --dport 6699 -j ACCEPT Wenn ich das richtig sehe, wird der Client einen anderen Port als 6699 zum Senden benutzen - auf 6699 horcht er nur auf eingehende Verbindungen. Klar, 6699 wird nur gebraucht, wenn ich eine Datei suche
Bei der von Dir formulierten Regel gibst Du den Zielport --dport 6699 vor, den mußt Du dann natürlich auch "umdrehen", also $IPTABLES -A FORWARD -s 192.168.10.61 -o ppp0 -p tcp \ --sport 6699 -j ACCEPT
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT durchgeht der ausdrücklich gewünscht ist. Grundsätzlich wird nichts und niemand getraut. ;-)
Die Regeln gelten nur für Folgepakete auf Verbindungen, die bereits zustande gekommen sind - daher kann durch die obigen Regeln keinerlei Gefahr resultieren. Gruß, Thorsten.
At 02:24 02.03.03 +0100, Thorsten D. Marsen wrote:
Hallo Matthias,
In=eth0 out=ppp0 src=192.168.10.61 DST=123.123.123.123 LEN=48 TOS=0x00 PREC=0x00 ttl=127 id=9058 DF PROTO=TCP SPT=6699 DPT=3777 WINDOW=8472 RES=0x00 ACK SYN URGP=0
Etwa so: $IPTABLES -A FORWARD -s 192.168.10.61 -o ppp0 -p tcp \ --dport 6699 -j ACCEPT Wenn ich das richtig sehe, wird der Client einen anderen Port als 6699 zum Senden benutzen - auf 6699 horcht er nur auf eingehende Verbindungen. Klar, 6699 wird nur gebraucht, wenn ich eine Datei suche
Bei der von Dir formulierten Regel gibst Du den Zielport --dport 6699 vor, den mußt Du dann natürlich auch "umdrehen", also
$IPTABLES -A FORWARD -s 192.168.10.61 -o ppp0 -p tcp \ --sport 6699 -j ACCEPT
Das (--sport) war ein Typo, aber diese Regel bezieht sich doch auf den Fall, daß ICH den Verkehr initiere. Noch mal von vorn: Ich betreibe der Server, 123 ist der Client (jedenfalls im Moment). Der Client baut zu meiner Firewall eine Verbindung auf Port 3777 -> 6699. Die Firewall läßt die Anfrage zu, da eine PREROUTING-Regel für ppp0:6699 existiert. Das Paket wird umadressiert an 192.168.10.61:6699 und durch den FORWARD-Eintrag an das interne eth0 weitergeleitet. Damit ist die Verbindung zustande gekommen. Frage: Das Antwortpaket gehört aber zu der gleichen Verbindung und sollte doch automatisch auf dem gleichen Weg wieder zurückgehen. 192.168.10.61:6699 -> 123.123.123.123:3777. Wird diese Automatik denn erst durch
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
in Gang gesetzt?
durchgeht der ausdrücklich gewünscht ist. Grundsätzlich wird nichts und niemand getraut. ;-)
Die Regeln gelten nur für Folgepakete auf Verbindungen, die bereits zustande gekommen sind - daher kann durch die obigen Regeln keinerlei Gefahr resultieren.
Wenn sie ungefährlich sind, warum müssen sie dann extra gesetzt werden? Gibt es Ausnahmen von Deiner Aussage? Was mich wundert ist, daß alle Beispiele, die ich im Google gefunden habe keine solche Umkehrregel haben. Es kommt mir auch so vor, als wenn nur mit
$IPTABLES -A FORWARD -s 192.168.10.61 -o ppp0 -p tcp \ --sport 6699 -j ACCEPT
die Umadressierung fehlt. Entsprechend müßte doch wohl auch eine POSTROUTING-Regel (wie sieht die aus?) her?! Die von Dir vorgeschlagene Umkehrregel betrifft meiner Meinung nach den ausgehend initierten Traffic, d.h. 192.168.10.61:4711 -> 123.123.123.123:6699, d.h. 123 ist der Server. |-? Gruß Matthias
Hallo Matthias, At 02:24 02.03.03 +0100, Thorsten D. Marsen wrote:
$IPTABLES -A FORWARD -s 192.168.10.61 -o ppp0 -p tcp \ --sport 6699 -j ACCEPT
Das (--sport) war ein Typo, aber diese Regel bezieht sich doch auf den Fall, daß ICH den Verkehr initiere. Noch mal von vorn:
Nein. Der Unterschied, ob DU eine initierst, oder ob ein Rückpaket gesendet wird, unterscheitet der Regelsatz in der -m state Eigenschaft: --state ESTABLISHED (Antwort), --state NEW(Neue Verb.)
Ich betreibe der Server, 123 ist der Client (jedenfalls im Moment). Der Client baut zu meiner Firewall eine Verbindung auf Port 3777 -> 6699. Die Firewall läßt die Anfrage zu, da eine PREROUTING-Regel für ppp0:6699 existiert. Das Paket wird umadressiert an 192.168.10.61:6699 und durch den FORWARD-Eintrag an das interne eth0 weitergeleitet. Damit ist die Verbindung zustande gekommen. Frage: Das Antwortpaket gehört aber zu der gleichen Verbindung und sollte doch automatisch auf dem gleichen Weg wieder zurückgehen. 192.168.10.61:6699 -> 123.123.123.123:3777. Wird diese Automatik denn erst durch
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
in Gang gesetzt?
Ja.
durchgeht der ausdrücklich gewünscht ist. Grundsätzlich wird nichts und niemand getraut. ;-)
Die Regeln gelten nur für Folgepakete auf Verbindungen, die bereits zustande gekommen sind - daher kann durch die obigen Regeln keinerlei Gefahr resultieren.
Wenn sie ungefährlich sind, warum müssen sie dann extra gesetzt werden?
Weil Du die Policy "DROP" eingestellt hast und dann einfach alles weggefiltert wird. Mit iptables ist der Paketfilter "stateful" geworden, d.h. er weiß, welche Verbindung aktib ist und in welchem Zustand sie sich gefindet. Bei dem Vorgänger ipchains mußte man die Rückverbindung auch tatsächlich noch explizit freischalten.
Gibt es Ausnahmen von Deiner Aussage? Was mich wundert ist, daß alle Beispiele, die ich im Google gefunden habe keine solche Umkehrregel haben. Es kommt mir auch so vor, als wenn nur mit
$IPTABLES -A FORWARD -s 192.168.10.61 -o ppp0 -p tcp \ --sport 6699 -j ACCEPT die Umadressierung fehlt. Entsprechend müßte doch wohl auch eine POSTROUTING-Regel (wie sieht die aus?) her?!
Nein, Du liegst ja mit Deinem Client hinter der Linux-Firewall, also muß Du ja schon eine POSTROUTING-Regel haben, richtig? (-t nat -o ppp0 -j MASQUERADE) Gruß, Thorsten.
participants (2)
-
Matthias Jänichen -
Thorsten D. Marsen