[DE] Zugriff auf Server absichern

[ayla]

Hallo,

angeregt durch diesen Thread und eine schlaflose Nacht hab ich mir auf meinem Pi eine cloud eingerichtet.
Funktioniert auch tadellos über XY.dynamicdns.com:PORT/owncloud und https. Danke an die im obigen Thread Beteiligten für die Links und das Kochrezept, ohne diese säße ich da wohl in drei Wochen noch dran.
 
Habe noch nie einen Web-Server eingerichtet und da kommt auch mein Problem in's Spiel. Ich bekomme, nach Freigabe des entsprechenden Ports in meinem Router, eine Verbindung via Internet und "mein" Zertifikat angeboten und kann nach dem akzeptieren die Verbindung herstellen.
Nu ja... aber das kann doch jeder? Ich meine dieses ssl-Zertifikat sichert doch meinen Server nicht ab, sondern gibt doch nur dem Client die Sicherheit daß er den richtigen Server hat, oder nebelt mir der Schlafmangel gerade die Windungen zu?

Wie bekomme ich denn da jetzt noch eine Authentizierung des Client rein? Oder möchte ich dazu unbedingt was lesen ?

Und ja, selbstverständlich ist der Port seit den Tests wieder dicht.

Gruß
ayla

[xweber]

Korrekt, https und das Zertifikat "garantiert" nur das der Server _der_ Server ist.

Wenn Server und Client sich gegenseitig "garantieren" sollen, ist man bei einem VPN wie bei OpenVPN angekommen.

Man könnte es im Grunde so bauen, das du erst ein VPN starten musst, bevor du auf _den_ Webserver kommst. Dann ist dein Webserver für niemand anders erreichbar, außer für diejenigen, die das VPN starten können.

Jetzt nicht erschrecken: auch für das VPN (quasi die Eingangstür) muss natürlich ein Server von außen erreichbar sein (wie eine Haustür). Nur reinkommen können dann nur die mit dem korrekten Schlüssel.

Stichworte: DMZ, VPN, OpenVPN

Nachtrag:
Der Client muss sich ja dann dem Clouddienst noch anmelden. Ist dann ähnlich wie beim VPN: ohne Schlüssel geht es nicht weiter. Bei einer Cloud ist es ja so gedacht, das mann von "jedem" PC dann Zugang auf seinen Dienst und Daten hat. Daher ist es im Grunde egal, von welchem Client aus man zugreift.

[rolandx1]

wenn ich nicht ganz falsch liege dann sorgt ssl/https auch dafür dass dein pw verschlüsselt übertragen wird und das würde ich als sicherheitsgewinn sehen


ps: ich warte auf den ersten der sich über die sicherheit von ssl beschwert
http://chaosradio.ccc.de/cr172.html sehr informativer beitrag

[hefee]

Du kannst auch den Zugiff so beschränken, dass der Client auch ein Zertifikat haben muss, dass er dem Server anbietet. Vorteil gegenüber VPN, du brauchst keine extra Software und verpackst die Pakete nicht doppelt.

Stichwort hier: Clientzertifikat

Aber auch hier, ist der Web-Port von außen zugänglich, es wird nur jede Anfrage abgelehnt, die kein passendes Clientzertifikat anbieten kann.

[ayla]

Hallo,

so, bin gerade fertig mit dem Anhören des Beitrags von Chaosradio. Interessant, informativ und für mich als Otto NV verständlich erklärt.
Daß die Verschlüsselung der Kommunikation stattfindet und auch Sinn macht ist mir klar.
Nicht klar ist mir ob ich mit der Installation des Apache-Servers da nicht einen Möglichkeit geschaffen habe -sobald ich den Port öffne, was ich ja muß, wenn die Cloud einen Sinn machen soll - "vor" einem Zugriff auf die Cloud irgendwo in mein System "abzubiegen". Das werd ich dann mal versuchen auch selbst zu testen.
An ein VPN hatte ich nicht gedacht, mir schwebte eher eine ssh-Verbindung vor über die ich den Port wie bei meiner Fernwartung absichere, allerdings k.A. wie ich das dem Apache beibringen sollte und außerdem scheint mir das ja irgendwie unnötig, es gibt ja schon eine Verschlüsselung und es ist ja auch schon ein key erstellt...
Hier wird es wohl mit dem "Clientzertifikat" interessant, scheint das Stichwort zu sein das ich brauche.
Vorstellung meinerseits: Zertifikat auf einen USB-Stick und bei Bedarf damit den Zugriff für die gerade benutzte Kiste freigeben... Mal schauen ob ich da was zu finde, erst mal Danke für die Tipps.

Gruß
ayla

[xweber]

ssh mit Portforwarding ist natürlich auch eine Variante. Dann braucht der Apache nur auf dem localhost interface zu lauschen, ssh "verbiegt" dann den Datenstrom von und zum Client.

Zumindest der Webserver ist dann von außen nicht zu erreichen und lediglich der ssh Port (auf welchem das auch immer stattfindet) ist von außen erreichbar.

Beispiel:

Code: [Select]

ssh -L 20080:localhost:80 server -N

server = die IP oder der name von dem Server.

Damit sollte dann im Clientbrowser http://localhost:20080/ der Inhalt vom Server Port 80 zu sehen sein.

[ayla]

Portforwarding -ja klar! Doch nicht genug Schlaf gehabt...

Aber eine andere Idee hatte ich soeben noch:

Der Apache bietet ja das Zertifikat an und damit, wenn ichs verstanden habe, den Publickey.
Kann ich denn dem nicht beibringen zwar das Zertifikat zu verlangen, aber nicht zur Verfügung zu stellen?
So nach dem Motto: ok, Du hast's, Du darfst zugreifen, aber wenn Du's nicht hast kriegst Du's auch nicht und musst leider draußen bleiben?
Wobei ich dann bei dem auf'n Stick kopierten Zertifikat wäre.

Gruß
ayla

EDIT:

Ah, endlich eine Erklärung in deutsch zu ssl gefunden -und dabei festgestellt daß ich die englischen wieder nur halb verstanden hatte .
Dann gehts so nicht, wie ich mir das vorgestellt hatte.

Die ssh-Variante hat zwar den NAchteil daß ich Probleme habe wenn ich mal von 'nem windows Rechner aus zugreifen wollte, aber sicher isse halt.

Aber dies hier sieht ja auch noch nach was verständlichem zu den Client Zertifikaten aus, mal sehen obs auch so funktioniert. Na ja, ausgerechnet auf self-signed geht er nicht weiter ein...

[wannek3]

ssl verschlüsselt, was a) den richtigen Server identifiziert und b) Abhören (auch der einzugebeneden Passworte) sehr erschwert. Gegen unberechtigten Zugang reicht evtl. schon ein Passwort-Zugang per .htaccess?

[Lanzi]

hier och ein paar Tipps von Heise.
http://www.heise.de/security/artikel/SSH-vor-Brute-Force-Angriffen-schuetzen-270140.html

Ein abschließendes HowTo von Dir wäre cool :-)

[xweber]

ich habe es noch nicht probiert, aber mit "mobaxterm" könntest du auch ein Windows Programm haben um den ssh Tunnel aufzubauen, ohne das du erst etwas installieren musst.

http://mobaxterm.mobatek.net/

[ayla]

Hi,

auf Authentizierung mittels Passwort möchte ich nur im Notfall zurückgreifen. Vorzugsweise Public/Privat-key, dann bin ich bei der ssh-Variante. Da hat der Link zu Heise noch mal einiges an Argumenten dafür hergegeben.
Das mobaxterm sieht vielversprechend aus um da auch über windows was machen zu können, meine vbox wird da mal ein paar Versuche machen.
Was ich bei der Planung des Zugangs allerdings auch noch berücksichtigen muß ist daß meine bessere Hälfte den Kauf eines Smartphones plant. Und wie ich das schon kenne wird das nach Design und Farbe gekauft, meine Chancen daß das Betriebsystem ein Android wird sind also eher gering...
Dem Teil dann ssh-Verbindungen beizubringen könnte schwierig werden. Dem verwendeten Browser ein Zertifikat unterzujubeln vielleicht auch, aber wohl trotzdem die einfachere Variante.

Bevor ich meine Cloud so sicher mache daß ich dann Probleme habe darauf zuzugreifen wenn ich möchte, so geheim und für Angreifer interessant werden die Daten nicht sein die dorthin kommen. In erster Linie geht es mir aber ja darum mir keinen Seiteneingang in mein internes Netz zu schaffen.
Im Moment tendiere ich deshalb zwar zu ssh, aber erst schau ich mir doch nochmal die Geschichte mit den Client-Zertifikaten an.

Und: Ja, gerne, wenn ich was vernünftiges zustande bekomme pack ich mal wieder was in's wiki.


EDIT:

hrmpf: Was stimmt'n jetzt?

http://www.noatun.net/docs/ssl_client.html

Zertifikat generieren

Das SSL-Protokoll basiert auf asymmetrischer Kryptographie. Jeder Kommunikationsteilnehmer, insbesondere der SSL-Server, benötigt zunächst ein Schlüsselpaar, bestehend aus privatem und öffentlichen Schlüssel.

http://www.netzwelt.de/news/85067_3-netzwelt-wissen-ssl-verschluesselung.html

Da SSL und TLS stets symmetrische Verschlüsselungsverfahren wie DES oder AES nutzen, erspart es den teilnehmenden Browsern und HTTP-Servern eine ganze Menge Arbeit: Bei einer symmetrischen Verschlüsselung dient ein und derselbe Schlüssel sowohl für Kodierung als auch Decodierung.

Wahrscheinlich letzteres, da AFAIK beim publik/private key nur der Private key zum Entschlüsseln taugt und ja beide Stellen ihre Kommunikation ver- und entschlüsseln.

hmm, hätte wohl gleich den zweiten google Eintrag nehmen sollen, hier wird die Erstellung und der Einsatz der Zertifikate gut erklärt/beschrieben.


Noch'n EDIT:
Das mit den client Zertifikaten hat einfacher und besser geklappt als erwartet. Der Apache akzeptiert nur noch logins mit Zertifikat und meine clients können sich problemlos damit einloggen.
Wenn ich's jetzt noch schaffe den Apache auf einem anderen als auf Port 80 lauschen zu lassen steht dem Wikibeitrag eigentlich nix mehr im Weg. Sicher sollte es jetzt sein und der Import der Certificates dürfte auch auf'm Smartfon kein so großes Problem werden.

EDIT 3:

Arrgghh, wenn man vergisst den Port aufm Router durch zu schleifen kann das mit den geänderten Ports auch nicht funktionieren. Leise rieselt der Kalk...

[ayla]

hmm, wollte soeben beim wiki schreiben owncloud auch auf meiner Kiste installieren, nur zum Nachvollziehen der Schritte für's wiki, aber nach der Installation und dem Aufruf von localhost/owncloud im iceweasel bekommen ich nur dies zu sehen:

. * */ $RUNTIME_NOAPPS = TRUE; //no apps, yet require_once('lib/base.php'); // Setup required : $not_installed = !OC_Config::getValue('installed', false); if($not_installed) { // Check for autosetup: $autosetup_file = OC::$SERVERROOT."/config/autoconfig.php"; if( file_exists( $autosetup_file )){ OC_Log::write('core','Autoconfig file found, setting up owncloud...',OC_Log::INFO); include( $autosetup_file ); $_POST['install'] = 'true'; $_POST = array_merge ($_POST, $AUTOCONFIG); unlink($autosetup_file); } OC_Util::addScript('setup'); require_once('setup.php'); exit(); } // Handle WebDAV if($_SERVER['.....

Hab ich -seit vorgestern Nacht!!- schon wieder irgendwas vergessen oder eine Version erwischt die nicht funktioniert?

Auf dem Pi ist 4.0.4debian2-3.3 in sid gerade 4.0.8debian-1.5

Gruß
ayla

[hefee]

Du musst apache schon anweisen dass er die dateien durch php pipen muss. So siehst du einfach die Datei an sich und nicht die interpretierte Version.

wg. SSL:Zertifikate:
Die Zertifikate selber sind asymetrisch also Private/Public Keypaar. Jedoch wird nachdem die Zertifikate ausgetauscht sind ein symetrischer Schlüssel (Sessionkey) generiert und ausgetauscht über den dann die weitere Kommunikation abgesichtert ist. Und dieser Sessionkey ist symetrisch.

Das hat zwei Vorteile:
1. symetrische Verfahren sind schneller
2. Wenn die Session beendet wird, wird der Sessionkey gelöscht und selbst dein Rechner kann den Traffic nicht mehr lesen. Damit ist auch selbst wenn du exakt das selbe an den Server zweimal schickst, es zweimal unterschiedlich verschlüsselt. Auch währerend einer Session wird immer wieder der Sessionkey gewechselt.

[ayla]

hmm, nu ja...

die letzten beiden Abschnitte hab ich ja verstanden.
Aber wie ich dem Apachen beibringen soll die Dateien "durch php zu pipen" iss mir nich so wirklich klar

Auf dem Pi lief das "von alleine". lokalhost/owncloud im Weasel aufrufen und die Webseite zum Admin einrichten war da.

Auf meinen beiden Kisten mit siduction und der neueren Version von owncloud sehe ich nur das obige, nehm' ich den Konqueror wirds ein wenig übersichtlicher und man kann sehen daß die Datei mit "<?php" beginnt. Dann folgen Kommentarzeilen und die Anweisungen beginnen mit

$RUNTIME_NOAPPS = TRUE; //no apps, yet

Ich nehme mal an "<?php" soll die Anweisung/der Hinweis sein das folgende als php code zu interpretieren, aber warum der weasel oder der Apache, wer auch immer dafür zuständig ist, das nicht tut und was ich dagegen tun könnte... k.A.

Gruß
ayla

[hefee]

also erstmal: der weasel kann nur html verstehen


Die Aufgabe php->html zu wandeln hat der apache. Damit apache weiß was er tun soll muss ein bischen was konfiguriert werden. Es gibt viele verschiedene Varianten, wie apache aus dem php ein html baut. Hier mal die vmtl. einfachste (aber auch unsichererste und langsamste). Erstmal brauchen wir:

Code: [Select]


libapache2-mod-php5


danach müssen wir es auch anschalten und apache neustarten:

Code: [Select]


a2enmod php5
service apache2 restart


Jetzt sollte jede Datei die mit .php endet apache auffordern, dass er diese Datei mit php interpretieren soll und das html was hinten rausfällt an den Browser zurückschickt.