Hallo, habe hier im internen Netzwerk einen Indianer fürs Intranet am laufen. Die Nutzer im Netz gehen über Squid ins Internet. Leider muss ich bisher bei jedem Nutzer im Browser die Adresse des Apachen unter "Für Adressen die wie folgt beginnen, keinen Proxyserver verwenden" eingeben. Ohne dem geht der Zugriff auf den Indianer nicht. Frage: Wo kann und muss man in Squid? die Einstellung vornehmen, so dass dieser bei Aufruf des Indianers diesen nicht cachen will??? Gerald
Hallo, * Am 18.Jul.2002 postete "Schäfer, Gerald":
habe hier im internen Netzwerk einen Indianer fürs Intranet am laufen. Die Nutzer im Netz gehen über Squid ins Internet. Leider muss ich bisher bei jedem Nutzer im Browser die Adresse des Apachen unter "Für Adressen die wie folgt beginnen, keinen Proxyserver verwenden" eingeben. Ohne dem geht der Zugriff auf den Indianer nicht. Frage: Wo kann und muss man in Squid? die Einstellung vornehmen, so dass dieser bei Aufruf des Indianers diesen nicht cachen will???
Die Einträge sind IMHO eh lästig. Schon die Angabe des Proxies ist nicht schön. Ich hab deshalb vor kurzem auf einen transparenten Proxy umgestellt: Regeln für iptables: ############## transparenter Proxy ################### $FW_BIN_IPT -t nat -A PREROUTING -i eth0 -p tcp --dport http -j DNAT --to 192.168.0.20:3128 #$FW_BIN_IPT -t nat -A PREROUTING -i eth0 -p tcp --dport https -j DNAT --to 192.168.0.20:3128 # Wenn deine default Regeln auf DROP stehen solltest Du die noch die folgenden rules setzten $FW_BIN_IPT -A OUTPUT -j ACCEPT -o ippp+ -p tcp --dport http --sport 1024:65535 -m state --state NEW,ESTABLISHED $FW_BIN_IPT -A INPUT -j ACCEPT -i ippp+ -p tcp --sport http --dport 1024:65535 -m state --state ESTABLISHED $FW_BIN_IPT -A OUTPUT -j ACCEPT -o ippp+ -p tcp --dport https --sport 1024:65535 -m state --state NEW,ESTABLISHED $FW_BIN_IPT -A INPUT -j ACCEPT -i ippp+ -p tcp --sport https --dport 1024:65535 -m state --state ESTABLISHED Den https hab ich bei mir rausgeschmissen, weil was nicht funktioniert hat. In der squidkonf muß das drinstehen: #Transparenter Proxy httpd_accel_host virtual httpd_accel_port 80 httpd_accel_with_proxy on httpd_accel_uses_host_header on Mit einer anderen Regel kannst Du dann den Proxie umgehen. Ich denke da an sowas wie: $FW_BIN_IPT -t nat -A PREROUTING -i eth0 -p tcp -s ! 192.168.0.0/24 --dport http -j DNAT --to 192.168.0.20:3128 Ist aber nur aus dem Kopf. Daher keine Ahnung, ob das geht. Beste Grüße Alex -- Begin Nimm Revolver. Lade eine Kugel. Drehe die Trommel und klappe sie in den Rahmen. Spanne den Hahn und drücke ab. If Result =! Bumm go Begin End Polzer [Rainer Behrendt zu Rudolf Polzer in dag°]
* On Thu, 18 Jul 2002 at 11:27 +0200, Alex Klein wrote: [Transparenter Proxy]
$FW_BIN_IPT -A OUTPUT -j ACCEPT -o ippp+ -p tcp --dport https --sport 1024:65535 -m state --state NEW,ESTABLISHED $FW_BIN_IPT -A INPUT -j ACCEPT -i ippp+ -p tcp --sport https --dport 1024:65535 -m state --state ESTABLISHED
Den https hab ich bei mir rausgeschmissen, weil was nicht funktioniert hat.
HTTPS kannst Du nicht durch einen transparanten Proxy jagen (Stichwort man-in-the-middle-attack). -- Adalbert PGP welcome, request public key: mailto:adalbert+key@lopez.at
Hallo, * Am 18.Jul.2002 postete Adalbert Michelic:
* On Thu, 18 Jul 2002 at 11:27 +0200, Alex Klein wrote: [Transparenter Proxy]
$FW_BIN_IPT -A OUTPUT -j ACCEPT -o ippp+ -p tcp --dport https --sport 1024:65535 -m state --state NEW,ESTABLISHED $FW_BIN_IPT -A INPUT -j ACCEPT -i ippp+ -p tcp --sport https --dport 1024:65535 -m state --state ESTABLISHED
Den https hab ich bei mir rausgeschmissen, weil was nicht funktioniert hat.
HTTPS kannst Du nicht durch einen transparanten Proxy jagen (Stichwort man-in-the-middle-attack).
Hat bei ner Bankseite nicht funktioniert. Sollte ich mir wohl nochmal ansehen, oder? ;) Wo liegt die Gefährlichkeit bei dem man-in-the-middle-attack? Client --eth--> Router mit Firewall --isdn--> Internet Beste Grüße Alex -- 'Where a calculator on the ENIAC is equipped with 18,000 vacuum tubes and weights 30 tones, computers in the future by the year 2000 may have only 1,000 vacuum tubes and weigh only 1.5 tons' [Popular Mechanics, March 1949]
* On Thu, 18 Jul 2002 at 12:31 +0200, Alex Klein wrote:
* Am 18.Jul.2002 postete Adalbert Michelic:
* On Thu, 18 Jul 2002 at 11:27 +0200, Alex Klein wrote: [Transparenter Proxy]
$FW_BIN_IPT -A OUTPUT -j ACCEPT -o ippp+ -p tcp --dport https --sport 1024:65535 -m state --state NEW,ESTABLISHED $FW_BIN_IPT -A INPUT -j ACCEPT -i ippp+ -p tcp --sport https --dport 1024:65535 -m state --state ESTABLISHED
Den https hab ich bei mir rausgeschmissen, weil was nicht funktioniert hat.
HTTPS kannst Du nicht durch einen transparanten Proxy jagen (Stichwort man-in-the-middle-attack).
Hat bei ner Bankseite nicht funktioniert. Sollte ich mir wohl nochmal ansehen, oder? ;)
Das wird transparent _niemals_ funktionieren.
Wo liegt die Gefährlichkeit bei dem man-in-the-middle-attack?
Client --eth--> Router mit Firewall --isdn--> Internet
HTTPS über Proxy besteht im wesentlichen darin, daß Dein Browser den Proxy ersucht, eine Verbindung zum Rechner $FOO aufzubauen. Anschließend reicht der Proxy nur mehr den verschlüsselten Verkehr vom Browser zum Server weiter, er kann ihn ja nicht lesen. Mit dieser Methode kannst Du übrigens auch SMTP, POP3, SSH, ... - d.h. alles was ein TCP-Protokoll ist und nur eine Verbindung vom Client zum Server aufbaut - durch den Proxy schleusen, vorausgesetzt, der Proxy lässt Zugriffe auf diesen Port zu. Wenn Du das nun transparent durch den Proxy zwicken willst, dann kann der Proxy gar nicht wissen, zu welchen Rechner Du jetzt willst, weil das maximal im verschlüsselten Datenstrom drinnen steht, und den kann nur der Server entschlüsseln. Und das ist gut so. Sonst könnte ja jeder, der Deinen Verkehr abfängt, das entschüsseln, und das wirst Du ja, besonders bei Verbindungen zu Deiner Bank, nicht gerade wollen, oder? Abgesehen davon - aus genau dem gleichen Grund (nämlich, daß der proxy nicht weiß, wohin damit) - kriegst Du eine HTTP/1.0 Verbindung auch nicht transparent über einen Proxy. IIRC. -- Adalbert PGP welcome, request public key: mailto:adalbert+key@lopez.at
participants (3)
-
"Schäfer, Gerald" -
Adalbert Michelic -
Alex Klein