HS hinter Apache2 Reverse Proxy mit https

[RaK]

@babel: Ich habe auch apache2 und einen reverseproxy am laufen. Nur habe ich es bisher noch nicht geschafft nach aussen https zu haben und intern http.

https://whatever.dyndns.org/vdr/ soll intern auf http/192.168.0.x:vdradminport/ umgeleitet werden.

Hast da da einen Tipp fuer mich?

Danke

[babel]

  <IfModule mod_proxy.c>
    ProxyRequests Off
    <Proxy https://xyz.test.com/vdrlive/*>
      Order deny,allow
      Allow from all
    </Proxy>
    ProxyHTMLURLMap     http://127.0.0.1:8008 /vdrlive/
    ProxyPass           /vdrlive/ http://127.0.0.1:8008/
    <Location /vdradmin/>
      ProxyPassReverse  /
      SetOutputFilter   proxy-html
      ProxyHTMLURLMap   /               /vdrlive/
      ProxyHTMLURLMap   /vdrlive        /vdrlive
    </Location>
  </IfModule>

[gunnar]

1. Linux-Server heißt nicht gleichzeitig "Sicher". Im Gegenteil: wird der Server nicht regelmäßig und damit meine ich wirklich alle paar Tage (zumindest für Kernal-Patches) gewartet, ist er "Unsicher".
2. Die Tatsache, das du "über" Server1 den Server2 ansprichst macht es nicht sicherer, da Server2 dennoch im öffentlichen Netz erreichbar ist und damit zumindest potentiell wieder angreifbar ist.

Ich glaube, hier geht es um relative Sicherheit. Ein Apache ist nunmal kampferprobter als ein HS. Das zweite Thema ist Verschlüsselung also SSL/HTTPS. Ich würde mich auch unwohl fühlen, wenn jeder meine Login-Daten (Nutzername, PIN, Passwörter, etc.) im Klartext mitlesen kann. Sobald er die Daten hat (und das ist nunmal bei HTTP sehr einfach), kann er sich anmelden und den HS bedienen.

Die Firewall alleine reicht nicht aus. Das bringt auch keine absolute Sicherheit. Eine FW macht zwar Paket-Inspektionen, aber sie kennt die Applikation "HS" nicht und weis also nicht, welche gültigen Pakete den HS knacken könnten.

-Gunnar

[AScherff]

Ich glaube, hier geht es um relative Sicherheit.

Klar, in der EDV gibt es keine absolute Sicherheit - maximal 99,99nnn % - der Rest ist technisch/philosophisch

Ich würde mich auch unwohl fühlen, wenn jeder meine Login-Daten (Nutzername, PIN, Passwörter, etc.) im Klartext mitlesen kann. Sobald er die Daten hat (und das ist nunmal bei HTTP sehr einfach), kann er sich anmelden und den HS bedienen.

Ja, ein SSL im HS ware schön - auch User und Paswort nicht als GET sondern als POST...

Eine FW macht zwar Paket-Inspektionen, aber sie kennt die Applikation "HS" nicht und weis also nicht, welche gültigen Pakete den HS knacken könnten.

Naja, "vernünftige" Firewalls und damit meine ich nicht die In Windooof oder in irgendwelchen "DSL-Routern" haben mehr als nur einfache Paketregeln. Intrusion Protection, Content Filtering um nur andere zu nennen. Und wenn schon mal der Paketfilter richtig konfiguriert ist, macht das schon eine Menge aus.

[rjumper]

Hallo nochmal,

eine Diskussion über die Sicherheit wollte ich eigentlich gar nicht anstoßen. Vielmehr geht es mir lediglich darum, dass der HS zwingend über einen Proxy angesprochen werden muß, da ich nur eine (sogar dynamische) externe IP-Adresse habe. Da ich meine Webseiten nicht im HS speichern kann, bleibt doch wohl bei ausschließlicher Verwendung des Standardports 80 (und für SSL 443) nur dieser Weg.

SSL-Verschlüsselung ja oder nein ist überhaupt nicht das Problem, sondern bei Verwendung eines Proxy ein schönes Bonbon. Vielmehr geht es darum, dass sich der HS zwar über /hs oder /shs über den Proxy ansprechen läßt und tadellos funktioniert, aber bei Aufruf der Listen via /hslist oder /shslist keinen richtigen Header sendet und somit der Proxy einen Fehler meldet. Aber auch die Möglichkeit des Listenabrufs "von aussen" wäre für mich wichtig.

Hatte zwischenzeitlich Kontakt zu Dacom. Dort will man für Abhilfe sorgen, einen Zeitplan konnte man mir nicht nennen. Allerdings tritt der Fehler mit der aktuellsten Firmware 2.2 von der Gira-Homepage nach wie vor auf. Lediglich mit RC-Kandidat 2.2 ? von Juni oder Juli hat es wie weiter oben bereits beschrieben teilweise funktioniert (Aufruf mit sofortiger Übergabe aller Listenparameter klappte).

Also nochmal zusammenfassend: Fehler beim HS lokalisiert, aber noch keine Abhilfe vorhanden, da vermutlich Firmwareproblem.

Gruß

Rolf

[dhe]

Ssl Vpn

Hallo Zusammen,

ich habe bereits im März mitgelesen und habe nun für einen Kunden etwas ähnliches realisiert, jedoch mit dem ZyWALL SSL 10 von ZyXEL.

Der Kunde kommt an ein Portal, meldet sich mit Benutzername, Passwort und wenn nötig mit einem One-Time-Token am System an.
Das Gerät stellt mittels Java dem Benutzer entweder auf einer 127.0.0.x (x>1) und dem definierten Port eine "durchschleifung" an das interne Gerät (GIRA Server) oder eine Web-Applikation, also ein Proxy.

Ich habe das selbe Problem, aber nur mit dem Proxy. Ich habe es nun so gelöst, dass ich es über wie Weiterleitung mit 127.0.0.2:80 mache.
Damit kann ich den GIRA Client verwenden, den Expert und mit dem Browser kann ich auf http://127.0.0.2/hslist gehen und komme so an meine Listen.

Das Gerät kann recht viel, kostet rund 450 CHF. Es ist z.B. möglich, je nach Benutzer und der Gruppe in der dieser Benutzer ist, andere Applikationen freizugeben, oder sogar über ein SSL VPN Tunnel interne IP Adressen freizugeben. Der kleine Firewall der integriert ist, kann auf Benutzer-Gruppe-Ebene entscheiden, ob und auf welche internen IP-Adressen und Ports zugegriffen werden darf.

Weiter kann eine einfache und rudimentäre Überprüfung des Clients gemacht werden (z.B. Windows updates aktiv, welche browser version, antivirus vorhanden etc.)

Falls es jemanden interessiert, kann ich einige Screenshots posten, die das Login zeigen und wie dann die Applikation daherkommt. Alternativ via www.studerus.ch das Handbuch zu gemüte fügen :-)

Ich hatte vorher ein Linksys Gerät im Einsatz, wo ich mit mir einem VPN Client eingeloggt habe. Das funktionierte perfekt, leider war der Kunde oft an seinem Verwaltungsstandort (öffentliche Hand) und dort sind die Firewall und Proxy richtlinien zu streng, als das sich hätte ports geöffnet bekommen.
Mit SSL VPN braucht es "nur" den https 443 tcp port und kein Proxy, der explizit SSL over https verbietet.

Bei dieser Lösung resp. Anforderung gieng es darum, dass mit der Visu die Türen geöffnet werden können und wenn wir das einfach per HTTP machen es ein Risiko ist, welches beim eintreten eines Einbruches durch die Versicherung abgelehnt werden könnte, dass die sagen, es gibt kein Geld, weil es fahrlässig ist, per Internet die Türen öffnen zu können.

Nun wirds technisch:
Das Gerät kann auf zwei grundlegend verschiedene Arten eingesetzt werden, als Gateway oder als DMZ Gerät. Als Gateway funktionierte nicht, weil das Gerät leider kein DynDNS update machen kann.
Wir haben nun eine Firewall mit WAN und LAN Port. Am LAN Port, wo auch alle Geräte inkl. GIRA Server hängen, steht nun auch diese ZyWALL SSL 10 und wird mit dem WAN Port verbunden. Am LAN Port der ZyWALL ist nichts angeschlossen. Der Port 443 wird von der Firewall auf das WAN Interface der ZyWALL geleitet. Diese macht eine "interne" Anfrage an den GIRA Server, welche somit nicht über das Gateway antwortet, sondern dem ZyWALL antwort gibt. Dieser setzt die Packete um und leitet diese per SSL VPN an den Benutzer weiter.

Was in den vorherigen Beiträgen schon geschrieben wurde, dass Linux (was ja eigentlich auf diesen Geräten auch drauf ist) unsicher ist resp. keine absolute Sicherheit bietet, bin ich einverstanden. Mit dieser Lösung die ich hier habe, habe ich das Risiko auf den Promille-Bereich reduziert, denn Firewall und dieses SSL Gerät sind von verschiedenen Herstellern. Es wird mit HTTPS verschlüsselt und ich bin der Meinung, dass ein digitaler "Einbruch" nun um welten aufwändiger ist, als vor Ort die Türe aufzubrechen. Ziel erreicht, die Versicherung muss wieder bezahlen, wenn Physikalische Gewalt angewendet wurde.

Grüsse aus der Schweiz
Dominique

[makki]

@dhe: auch wenn ich nicht unbedingt der Zyxel-Fan bin, schöne und auf den ersten Blick saubere Lösung !
Für das wichtigste an dem ganzen halte ich auch die sichere Authentisierung, gehärtete Geräte davor und erst danach die Verschlüsselung.
Nachdem das mit dem mod_proxy wie ich feststellen musste etwas hakelig ist, schwanke ich im Moment zwischen squid und der Cisco-Lösung.

Ich kann wenns jemanden interessiert gerne mal die Cisco-Variante in einfach (Auth-Proxy am IOS Router) zur Abschottung und sep. Authentisierung sowie etwas komplexer (SSL-Proxy) vorstellen..
Ersteres hat den NAchteil dass es dem HS kein SSL aufsetzt, zweiteres hab ich noch nicht komplett getestet..

Makki

[makki]

Nur so nebenbei, ich hab das mittlerweile rein Browserbasiert mit Cisco (IOS) SSL-VPN & Securid-Authentisierung am laufen (was ja nichts anderes als quasi ein SSL-Reverse-Proxy mit URL-rewirting ist), klappt wunderbar..
Bisher keinerlei Probleme sowohl mit der normalen Visu als auch Ajax, letzteres ist allerding bei mir bisher nur ein kleines Testprojekt. Darüber erfolgt auch der sichere Zugriff auf Synology, Mobotix und Dreambox..

Makki

[HartmutB]

Hallo Makki,

Deine Lösung interessiert mich.

<fachchinesich>
Ich würde auch gerne ein SecurID-Token nehmen, ich schleppe schließlich 'eh schon eins den ganzen Tag mit mir rum, aber zuhause einen Authentification Manager installieren wäre mir doch zu heftig. Hast Du das echt gemacht ?? Extra Server(prozess) und -lizenz dafür ?
</fachchinesich>

Abgesehen von der Anmeldung mit einem Hardwarepassworttoken: Ist der Rest Standard SSL-VPN ? Kann das Terminieren jeder Cisco IOS-Router ggf. mit Preshared Key oder Zertifikaten ?


Da es um die Absicherung des HS-Remotezugriffs geht, ist das Thema meiner Meinung nach nicht off-topic, aber falls doch: PN ...

Gruß
Hartmut

[makki]

Also, wenn ich die RSA-Grütze nur dafür betrieben würde wäre ich erheblich irrer als ich dachte die Infrastruktur für das SecurID-Zeugs ist natürlich schon vorhanden..
Wir (Firma) vermieten die Dinger und betreiben ohnehin redundante Server für SecurID, TAC+ & RADIUS, womit sowieso die Anmeldung an allen Ciscos usw. stattfindet; mein täglich Brot, das vereinfacht die Sache ungemein
Das ist im Normalfall für Privatanwender natürlich eigentlich nicht machbar, an dieser Stelle auch gleich meine ausdrückliche Anti-Empfehlung für das Zeug, stünde ich heute vor der Entscheidung würde ich eine andere Lösung nehmen.. Das hat nichts mit der Sicherheit zu tun sondern eher mit dem gebahren gewisser Firmen.. Mehr sag ich jetzt mal nicht

Das geht selbstverständlich auch mit jedem anderen Authentisierungsverfahren, also lokalen Passwörtern auf dem Router oder Radius etc., nur Zertifikate zur Anmeldung geht mit IOS meine ich nicht (letzter Wissenstand vor ein paar Monaten, kann ich aber mal prüfen)
Die verwendeten SSL-Zertifikate sind in meinem Fall von der eigenen CA ausgestellt (s.o.: schon vorhanden), geht aber (Standardmässig sowieso) natürlich auch self-signed Zertifikaten vom Router..
Laufen tut das ganze auf einem 1802W mit IOS 12.4(15)T5, sollte aber ausm Kopf ab 12.4(6)T gehen..
Config kann ich gerne posten, muss aber dazusagen dass diese vermutlich nicht mit dem SDM (die GUI-Java-Grütze) verwendbar ist. (ich sitz aber grad auf der Terasse und der Token um selbige auslesen zu können liegt in der Küche->zu weit)

Makki

[HartmutB]

Danke Makki für die Infos,

bei der Beschreibung ist mir die Idee gekommen, das ganze Thema Security auch bei mir über unsere Firma laufen zu lassen, da gibt es auch die komplette Infrastruktur. Dann muß ich nur einen Tunnel von der Arbeit zu meinem Router machen und fertig. Und gut benehmen muss ich mich, damit ich den Job noch viele Jahre behalten darf, sonst war der Aufwand umsonst .

Das mit der "GUI-Java-Grütze" kann ich nachvollziehen, ich ziehe auch eine Kommandozeile mit weiß auf schwarzem Hintergrund vor. Mit Cisco kenn ich mich nicht weitergehend aus, wenn bei uns ein Router notwendig ist (war), dann war es meistens ein Bintec. Man bleibt halt bei dem, was man kennt. Aber irgendwo im Schrank liegt (glaub' ich) auch noch ein nicht mehr genutzter Cisco rum, mal schauen, was das für ein Ding ist.

Und ohne vorhandene Visu, die man unbedingt aus dem Internet erreichen müsste, ist das Problem auch noch nicht so akut .

Gruß
Hartmut