Sie sind nicht angemeldet.
03.05.2009, 00:20
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »JumpinJackFlash« (03.05.2009, 01:12)
04.05.2009, 16:27
Genau das war mir halt nicht ganz klar, obs denn wirklich ein lokaler Prozess wird (squid ist auf dem gleichen rechner transparent). Oder ob es halt in die FORWARD Kette kommt (natürlich nur wenn das Paket von nem client-rechner kommt). Bin irgendwie anfangs davon ausgegangen, dass es in die forward kette kommt weil es ja halt "durchgeht". Aber, dass es zum lokalen Prozess wird, da ja Squid nun mal lokal läuft erscheint mir ja auch irgendwie logisch
Zitat
Zu 1. Ja alle Pakete deren Ziel der lokale Rechner ist folgen dieser Kette (Pre,Input,Output,Post).
Siehe dazu auch http://de.wikibooks.org/wiki/Linux-Kompe…ise_unter_Linux
in der PREROUTING hab ich momentan nur eine umleitung an den (lokalen) Proxy für Port 80. SSL und andere Verbindungen wollen irgendwie noch net so recht... Irgendwas hab ich da wohl noch nicht so ganz mit dem Accelerator-modus da verstanden.
Zu 2. Entscheidend für die Beantwortung dieser Frage ist wa in der
Postrouting Chain steht. Dort können Anfragen natürlich umgeleitet
werden . z.B.
IPTABLES -t nat -A PREROUTING -p tcp --dport 8080 -i eth1 -j DNAT --to 192.168.0.1:3128
um alle Pakete die an eth0 ankommen und deren Zielport 8080 ist werden
an die Adresse 192.168.0.1 mit dem Squid Port 3128 weitergeleitet.
Diese Adresse kann also z.B. lokal (INPUT Chain) oder Remote
(Forwarding Chain) ausgewertet werden, je nach dem ob der Rechner
selber die IP besitzt.
Hehe genau das meine ich ja. Ich meine es macht doch auch überhaupt kein Sinn irgendwas an das loopback von aussen zu schicken es sei denn es hat "feindliche" Absichten?!
Zu 3. Diese Regel sollte folgendes bewirken.
In der FORWARDING Chain (also alle eingehenden Pakete , die nicht für
diesen Rechner bestimmt sind und somit weitergeleitet werden ) sollen
alle diese Pakete erlaubt werden, die als Ziel das lokale Loopback
Interface haben. Dies ist natürlich ein wiederspruch, da alle Pakete
die das Loopback interface ansprechen natürlich über die INPUT Chain
verarbeitet werden.
05.05.2009, 10:45
Der Proxy verschickt seine Pakete natürlich nur an den Client über seinen TCP-Port 3128 ... alle Verbindungen die der Proxy nach außen ins www werden über beliebige Source Ports getätigt. Die Zielports dieser www Anfragen von Squid sollte in aller Regel immer 80 sein. Also ...
in der PREROUTING hab ich momentan nur eine umleitung an den (lokalen) Proxy für Port 80. SSL und andere Verbindungen wollen irgendwie noch net so recht... Irgendwas hab ich da wohl noch nicht so ganz mit dem Accelerator-modus da verstanden.
Naja auf jeden Fall könnte ich das Paket was "aus dem" Proxy kommt in der Output Kette per --sport 3128 "identifizieren" ?!
Die gesammte Regel macht keinen Sinn, da die Pakete die über die FORWARD Chain geschickt werden NIEMALS im lokalen Loopback ankommen, und somit auch als Ziel NIEMALS lo in der FORWARDING Chain stehen kann. Also auch kein Angriffsversuch sondern der Author der Regel kannte sich anscheiend nicht mit iptables aus.
Hehe genau das meine ich ja. Ich meine es macht doch auch überhaupt kein Sinn irgendwas an das loopback von aussen zu schicken es sei denn es hat "feindliche" Absichten?!
05.05.2009, 19:24
Jo wo du es so sagst
Der Proxy verschickt seine Pakete natürlich nur an den Client über
seinen TCP-Port 3128 ... alle Verbindungen die der Proxy nach außen ins
www werden über beliebige Source Ports getätigt. Die Zielports dieser
www Anfragen von Squid sollte in aller Regel immer 80 sein. Also ...
[...]
Mit anderen Worten deine --sport 3128 Regel könnte nur im Letzten Schritt Server-->Client das Paket identifizieren.
thnx!!!Dann sollte das wohl mal auf http://www.gentoo.de/doc/de/security/sec…?part=1&chap=12 korrigiert werden
Die gesammte Regel macht keinen Sinn, da die Pakete die über die
FORWARD Chain geschickt werden NIEMALS im lokalen Loopback ankommen,
und somit auch als Ziel NIEMALS lo in der FORWARDING Chain stehen kann.
Also auch kein Angriffsversuch sondern der Author der Regel kannte sich
anscheiend nicht mit iptables aus.
