PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Squid reverse Proxy - https/SSL



ST
12.02.10, 10:49
Liebes Forum,

ich betreibe zwei Hosts, beide Debian 5.0/Lenny (Host 1 - Mediawiki, Host 2 OTRS Ticketsystem) in einem LAN. Beide sprechen nur https und beide haben jeweils signierte Zertifikate.

Die beiden Maschinen sollen nun per https aus dem Internet erreichbar sein. Die Auflage ist, eine DMZ zu nutzen. Da die beiden bestehenden Hosts nicht in die DMZ sollen, habe ich einen dritten Host mit zwei netzwerkkarten eingerichtet, eine LAN eine DMZ. Debian 5.0 mit Squid Version 3.0.STABLE8 den ich als Debian Paket installiert habe (da ist ssl nicht an soweit ich das sehe - siehe squid3 -v am Ende des Posts).

Mit wurde gesagt (von einem Admin!!1!1!!), das Squid als reverse Proxy einfach https durchreichen kann. Also dumm, ohne etwas zu ver- oder entschlüsseln (hat dann auch keinen Cache oder sonstige Vorteile, außer eben ein Glied mehr in der Sicherheitskette). Leider bin ich nicht in der Lage, dass in der Doku zu finden oder umzusetzen.

1.) stimmt das?
2.) Wie sollte das für zwei Hosts konfiguriert werden
3.) geht das mit dem Debian Paket ohne SSL?

Falls diese Konfiguration nicht funktioniert, was ich stark annehme, muss ich dann die Zertifikate die eigentlich für die beiden Hosts sind auf dem Squid installieren oder muss ich für den Squid neue erstellen?

Funktioniert das generell, also ich habe wiki.domain.de und ticket.domain.de, beide zeigen laut DNS auf den Squid Proxy. Der macht die htps Verbindungen mit den Clients und kommuniziert nach hinten ins LAN per http mit den echten Hosts? Habe ich das richtig verstanden?

Viele liebe Grüße und vielen Dank im Vorraus

Stephan


-------------------------------------
squid3 -v
Squid Cache: Version 3.0.STABLE8
configure options: '--build=i486-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--libexecdir=${prefix}/lib/squid3' '--disable-maintainer-mode' '--disable-dependency-tracking' '--srcdir=.' '--datadir=/usr/share/squid3' '--sysconfdir=/etc/squid3' '--mandir=/usr/share/man' '--with-cppunit-basedir=/usr' '--enable-inline' '--enable-async-io=8' '--enable-storeio=ufs,aufs,coss,diskd,null' '--enable-removal-policies=lru,heap' '--enable-delay-pools' '--enable-cache-digests' '--enable-underscores' '--enable-icap-client' '--enable-follow-x-forwarded-for' '--enable-auth=basic,digest,ntlm' '--enable-basic-auth-helpers=LDAP,MSNT,NCSA,PAM,SASL,SMB,YP,getpwnam,mu lti-domain-NTLM' '--enable-ntlm-auth-helpers=SMB' '--enable-digest-auth-helpers=ldap,password' '--enable-external-acl-helpers=ip_user,ldap_group,session,unix_group,wbin fo_group' '--with-filedescriptors=65536' '--with-default-user=proxy' '--enable-epoll' '--enable-linux-netfilter' 'build_alias=i486-linux-gnu' 'CC=cc' 'CFLAGS=-g -O2 -g -Wall -O2' 'LDFLAGS=' 'CPPFLAGS=' 'CXX=g++' 'CXXFLAGS=-g -O2 -g -Wall -O2' 'FFLAGS=-g -O2'

derRichard
12.02.10, 12:30
hi!

warum leitest du nicht einfach die https-verbindungen am gateway zu den https-webservern im dmz weiter? mit iptables, etc...
den squid brauchst du dafür gar nicht.
der squid könnte im besten fall auch nur die reine tcp-verbindung (nicht http(s)!) umleiten. cachen und loggen kann er nichts.
dazu müsste er ja die ssl-verbindung aufbrechen.

wobei es kommerzielle "ssl-aufbrech-plugins" für squid gibt, dazu muss dann aber auf jedem client-pc das root-zertifikat vom squid als vertrauenswürdiges stammzertifikat installiert werden. was bei großen firmen aber kein problem ist.
damit könntest du dann https cachen und auch loggen.

hth,
//richard

ST
14.02.10, 20:47
Hallo richard,

vielen Dank für Deine Antwort.



warum leitest du nicht einfach die https-verbindungen am gateway zu den https-webservern im dmz weiter?


Weil es keine https-Webserver in der DMZ gibt. Die beiden Server stehen im LAN, in der DMZ steht nur der Rechner der als Proxy fungieren soll.



der squid könnte im besten fall auch nur die reine tcp-verbindung (nicht http(s)!) umleiten. cachen und loggen kann er nichts.


Ja, genau wie das geht möchte ich wissen bzw. ob das mit squid überhaupt geht. Einfach die (https) Verbindungen für den Wikiserver an den Wikiserver leiten und die (https) Verbindungen für den Ticketserver an den Ticketserver. Nichts cachen nichts loggen.

Viele Grüße

Stephan

ST
15.02.10, 09:25
Hallo,

Gibt es niemanden, der mir einen Tipp geben kann?

Viele Grüße

Stephan

derRichard
15.02.10, 11:18
welchen tipp brauchst du noch?

//richard

ST
15.02.10, 15:20
welchen tipp brauchst du noch?


Eine Antwort auf eine meiner drei Fragen im ersten Post, mit der Berücksichtigung auf den Eingangstext.

Oder eine Antwort auf meinen 2. Post. Ob Squid 3.0 Verbindungen umleiten kann. Wenn ja, wie? Einfach die (https) Verbindungen für den Wikiserver an den Wikiserver leiten und die (https) Verbindungen für den Ticketserver an den Ticketserver. Nichts cachen nichts loggen.

Viele Grüße

Stephan

ST
27.04.10, 07:32
Hallo Forum,

nach längerer Recherche, habe ich nun herausgefunden, dass das eingangs beschriebene Szenario nicht machbar ist. Squid kann die eingehenden Verbindungen nicht unterscheiden und dann unterschiedlich verschlüsseln. Wenn Squid die SSL Verschlüsselung übernehmen soll, dann geht das nur für einen Host, die Verbindung hinter Squid ist dann im LAN unverschlüsselt. Das einfache "durchreichen" einer SSL Verbindung (ohne sie "aufzubrechen") soll zwar laut Doku funktionieren habe ich aber praktisch nicht umgesetzt bekommen.

marce
27.04.10, 07:36
wieso "umständlich" per Squid und nicht einfach mit iptables / routing / NAT?

ST
27.04.10, 13:59
Hallo marce,

Was genau möchtest Du ausdrücken? Ich habe nur geschrieben, dass die oben beschriebene Aufgabe mit Squid _nicht_ zu lösen ist. Ich habe nicht einmal geschrieben, das es überhaupt zu lösen ist.

Wenn Du eine Lösung hast, das oben beschriebene Problem mit iptables / routing / NAT zu lösen, bin ich sehr dankbar für eine genaue Beschreibung.

Gruß

ST

Windoofsklicker
27.04.10, 17:46
Wenn du eh' einen extra Rechner in die DMZ stellst, dann kann da doch ein Apache als Proxy fungieren! Das sollte dann auch mit den Zertifikaten passen. Der Apache bekommt sein eigenes Zertifikat und gut is'.

Stichworte ProxyPass und ProxyPassReverse

ST
27.04.10, 20:04
Hi Windoofsklicker,

danke für Deine Antwort. Host 1 und Host 2 haben doch schon ein Zertifikat. Soll der Apache in der DMZ dann ein 3. Zertifikat (neues) bekommen? Wie unterscheidet der Apache, ob er die Anfragen zu Host 1 oder Host 2 weiterleiten soll? So wie ich die Doku verstehe brauch ich pro Host einen Apache in der DMZ oder habe ich das falsch verstanden?

Viele Grüße

ST

HBtux
27.04.10, 20:11
Da die beiden bestehenden Hosts nicht in die DMZ sollen, habe ich einen dritten Host mit zwei netzwerkkarten eingerichtet, eine LAN eine DMZ.
Dann ist die DMZ aber nur noch halb soviel wert.....

Die Schutzfunktion einer DMZ solltest Du nicht mit einem Beinchen des Server im internen Netz aushebeln....
Dann ist es ja keine DMZ mehr.



Internet
|
|
|
Firewall ------ DMZ
|
|
|
internes Netz

Der Traffik vom Internet zur DMZ und von der DMZ zum internen Netz sollte immer über die Firewall laufen.

Windoofsklicker
29.04.10, 20:07
Der Apache bekommt ein eigenes Zertifikat.
Dann sowas:

ProxyPass /mediawiki/ https://192.168.0.5/
ProxyPassReverse /mediawiki/ https://192.168.0.5/

ProxyPass /otrs/ https://192.168.0.1/
ProxyPassReverse /otrs/ https://192.168.0.1/

Bin mir nicht 100%ig sicher, aber einen Versuch dürfte es wert sein.