PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Wget Problem



I-Master
24.03.04, 11:44
Hi,

ich wollte ein PHP Skript zeitgesteuert per CronJob und Wget ausführen. Das Skript liegt auf meiner eigenen Domain die von Giweb gehostet wird.

Wenn ich mit wget versuche das Skript aufzurufen kommt immer nen Timeout. Offensichtlich blockt die Firewall da irgendwas, aber ich verstehs nicht:

Mar 24 13:08:39 RedHat-Linux-PB kernel: IN=ppp0 OUT= MAC= SRC=82.96.87.152 DST=217.83.201.94 LEN=44 TOS=0x00 PREC=0x00 TTL=57 ID=0 DF PROTO=TCP SPT=80 DPT=1651 WINDOW=5840 RES=0x00 ACK SYN URGP=0

der DPT variert. Der is auch mal 133 und andere.

Also der Server darf bei mir ausgehend alles und Port 80 ist auch offen. Ich versteh nicht so ganz, was er da jetzt blockt. Andere Webseiten bereiten da keine Probleme.

Terran Marine
24.03.04, 11:47
Original geschrieben von I-Master

Mar 24 13:08:39 RedHat-Linux-PB kernel: IN=ppp0 OUT= MAC= SRC=82.96.87.152 DST=217.83.201.94 LEN=44 TOS=0x00 PREC=0x00 TTL=57 ID=0 DF PROTO=TCP SPT=80 DPT=1651 WINDOW=5840 RES=0x00 ACK SYN URGP=0


Afaik blockt die Firewall das Antwortpaket von dem Server auf deine wget anfrage (deswegen Source Port 80)
Interface : ppp0 (DSL?)

Der DPT muss varieren, da er zufällig beim Verbindungsaufbau ausgewählt wird.

Gruß
Terran

I-Master
24.03.04, 11:49
Mmmh. Wie kann ich das denn abstellen dass das Antwortpacket geblockt wird?

Terran Marine
24.03.04, 11:53
Original geschrieben von I-Master
Mmmh. Wie kann ich das denn abstellen dass das Antwortpacket geblockt wird?

Source Port 80 erlauben, oder die sichere Lösung, Pakete die zu einer bestehenden Verbindung erlauben durchlassen (heisst das dann eigentlich schon stateful inspection?)

das 2. geht afaik so :

iptables -A INPUT -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT

Eventuell noch das Interface angeben.

Gruß
Terran

I-Master
24.03.04, 12:56
So ganz scheint es das noch nicht zu sein:

Mar 24 14:20:06 RedHat-Linux-PB kernel: IN=ppp0 OUT= MAC= SRC=82.96.87.152 DST=217.83.201.94 LEN=44 TOS=0x00 PREC=0x00 TTL=57 ID=0 DF PROTO=TCP SPT=80 DPT=4970 WINDOW=5840 RES=0x00 ACK SYN URGP=0

aber jetzt kommt nur noch die Meldung. Der DPT variert nicht mehr.

Also 80 ist als Port ja offen weil ich auf dem Server ja auch nen Apache laufen haben. Kann es sein, dass es daran liegt?

I-Master
24.03.04, 13:12
So, hab jetzt folgendes probiert:

$IPT -A INPUT -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A INPUT -p TCP -m state --state NEW -i ppp0 -j ACCEPT
$IPT -A INPUT -p tcp -s 82.96.87.152 -d $NET --dport 80 -j ACCEPT


leider alles erfolglos.

Terran Marine
24.03.04, 13:15
Original geschrieben von I-Master
.

Also 80 ist als Port ja offen weil ich auf dem Server ja auch nen Apache laufen haben. Kann es sein, dass es daran liegt?

Das Paket kommt von aussen und will auf den Zielport 4970, dein Apache läuft auf ZielPort 80, die Dinge stören sich also nicht.

Gruß
Terran

I-Master
24.03.04, 13:44
So gehts:

$IPT -A INPUT -p TCP -i $IF --sport 80 --dport 1024:65535 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
$IPT -A INPUT -p TCP -i $IF --sport 443 --dport 1024:65535 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

Die Frage ist: Kann man das so lassen oder ist das ggf. ne Sicherheitslücke? Wenn ich das jetzt richtig übersetze:

Wenn nen Webserver (Port 80) meinem Server anfragt, so aktzeptiere alle High-Ports. Und die Anfrage muss vorher von mir gewollt worden sein.

Richtig?

Terran Marine
24.03.04, 13:49
Original geschrieben von I-Master
So gehts:

$IPT -A INPUT -p TCP -i $IF --sport 80 --dport 1024:65535 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
$IPT -A INPUT -p TCP -i $IF --sport 443 --dport 1024:65535 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

Die Frage ist: Kann man das so lassen oder ist das ggf. ne Sicherheitslücke? Wenn ich das jetzt richtig übersetze:

Wenn nen Webserver (Port 80) meinem Server anfragt, so aktzeptiere alle High-Ports. Und die Anfrage muss vorher von mir gewollt worden sein.

Richtig?

Ich glaube das new im state besagt, das die Verbindung von dir NICHT vorher initiert sein muss, was natürlich eine Sicherheitslücke ist.

Gruß
Terran

I-Master
24.03.04, 13:53
Da es auch ohne NEW geht kann ichs ja dann so lassen oder? :D

Iptables....... guckt man sich jahrelang nicht mehr an, bis irgendwas nicht mehr geht.

Terran Marine
24.03.04, 13:59
Original geschrieben von I-Master
Da es auch ohne NEW geht kann ichs ja dann so lassen oder? :D


Ja,

aber seltsam das es dann vorhin nicht geklappt hat,

die Zeile :

$IPT -A INPUT -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT

Ist identisch mit der jetzigen, es fehlen nur die Parameter, interface, dports und sports,

fehlen diese, wird ALL dafür angenommen, und damit hätte es auch gehen müssen.

Aber egal, es funktioniert, man sollte sich freuen.

Gruß
Terran

I-Master
24.03.04, 14:28
Also ich hab in meinem Skript ja auch schon dafür was drinstehen:

$IPT -N STATE 2> /dev/null
$IPT -F STATE
$IPT -I STATE -m state --state NEW -i ! lo -j $STOP
$IPT -A STATE -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A STATE -j $STOP

Aber die Regel

$IPT -A INPUT -p TCP -i $IF --sport 80 --dport 1024:65535 -m state --state ESTABLISHED,RELATED -j ACCEPT

ist ja noch nen bisschen restriktiver, weil sie nur auf 80 und 443 reagiert.