Hallo,
angeregt durch diesen Thread (http://forum.siduction.org/index.php?msg=28146#28146) 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
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.
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
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.
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
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:
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.
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 (http://www.netzwelt.de/news/85067_3-netzwelt-wissen-ssl-verschluesselung.html) 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 (http://blog.benny-baumann.de/?p=606) 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...
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?
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 :-)
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/
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
QuoteZertifikat 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
QuoteDa 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 (http://www.phpgangsta.de/client-zertifikate-als-sicherer-login-ersatz) 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...
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:
Quote. * */ $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
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.
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
Quote$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
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:
libapache2-mod-php5
danach müssen wir es auch anschalten und apache neustarten:
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.
Hallo,
Quote...Die folgenden zusätzlichen Pakete werden installiert:
apache2-mpm-prefork
Die folgenden Pakete werden ENTFERNT:
apache2-mpm-worker
Die folgenden NEUEN Pakete werden installiert:
apache2-mpm-prefork libapache2-mod-php5...
Nach erfolgreichem Durchlauf:
root@nescaya:/home/cal #root: a2enmod php5
Module php5 already enabledNach wie vor zeigt mir der weasel aber nur den Text.
Irgendwas läuft hier anders als bei meiner Pi Installation...
Hab mir mal gerade eine info.php angelegt die phpinfo() aufruft -Thread im owncloud-Forum- und diese nach /var/www kopiert. Die phpinfo wird im weasel angezeigt, also funktioniert dieser Teil anscheinend. Werd mal diese Ausgabe und die des Pi vergleichen.
Plan B ist, die Version die auf dem Pi läuft hier zu installieren und auszuprobieren, wenn ich sie für amd64 finde, stable oder testing haben anscheinend keine owncloud drinne, wenigstens zeigt "policy" mir keine an.
Gruß
ayla
EDIT:
hm. Gleiche php-Version, gleiche Einstellungen -außer aktiviertem ssl beim Pi und verlegten Ports, das war hier noch nicht an der Reihe.
Unterschiede, hier:
Mysql-Abschnitt vorhanden
Quoteextension_dir /usr/lib/php5/20100525
PCRE Library Version 8.31
SQlite library 3.7.15.2
beim Pi:
Quoteextension_dir /usr/lib/php5/20100525+lfs
PCRE Library Version 8.30
SQlite library 3.7.13
Da muß dann wohl Plan B dran.
Bug-Report (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698343) mit dem Problem bei debian gesehen, war zwar von Version 4.0.4debian2-3.2, ist aber noch offen.
heute wurde owncloud getriggert, dass es wieder aus testing fliegt. Es fand sich kein maintainer finden wollte, der OC4 noch drei bis vier Jahre backporten will.
Hast du die Benutzerechte angeschaut? was sagt /var/log/apache2/error.log ?
btw. ich habe owncloud auf einem debian stable ohne Probleme am laufen. Es MUSS gehen :)
Hatte in meinem EDIT oben gerade noch'n Debian Bug Report angehängt.
Quote[Sun Mar 17 17:15:54 2013] [notice] Apache/2.2.22 (Debian) configured -- resuming normal operations
[Sun Mar 17 17:24:36 2013] [error] [client 127.0.0.1] File does not exist: /var/www/favicon.ico
[Sun Mar 17 17:24:36 2013] [error] [client 127.0.0.1] File does not exist: /var/www/favicon.ico
[Sun Mar 17 17:39:06 2013] [error] [client 127.0.0.1] File does not exist: /var/www/favicon.ico
[Sun Mar 17 23:01:00 2013] [notice] caught SIGTERM, shutting down
[Mon Mar 18 07:22:21 2013] [notice] Apache/2.2.22 (Debian) configured -- resuming normal operations
[Mon Mar 18 07:27:27 2013] [notice] SIGUSR1 received. Doing graceful restart
apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1 for ServerName
[Mon Mar 18 07:27:27 2013] [notice] Apache/2.2.22 (Debian) configured -- resuming normal operations
[Mon Mar 18 07:42:58 2013] [notice] caught SIGTERM, shutting down
[Mon Mar 18 07:43:03 2013] [notice] Apache/2.2.22 (Debian) configured -- resuming normal operations
[Mon Mar 18 07:43:05 2013] [notice] caught SIGTERM, shutting down
[Mon Mar 18 07:43:06 2013] [notice] Apache/2.2.22 (Debian) PHP/5.4.4-14 configured -- resuming normal operations
[Mon Mar 18 07:45:13 2013] [notice] caught SIGTERM, shutting down
[Mon Mar 18 07:45:14 2013] [notice] Apache/2.2.22 (Debian) PHP/5.4.4-14 configured -- resuming normal operations
[Mon Mar 18 07:49:34 2013] [notice] caught SIGTERM, shutting down
[Mon Mar 18 07:50:28 2013] [notice] Apache/2.2.22 (Debian) PHP/5.4.4-14 configured -- resuming normal operations
Neuere Einträge gibt's nicht obwohl ich gerade dreimal die Openbox versucht habe zu starten.
Und ja, auf meinem Pi läufts ja auch :). Benutzerrechte... hmm, mal schauen, da war auch was beim Pi, aber erst heut abend, muß weg.
Danke und Gruß
ayla
ich probier ja auch schon laenger mit mit owncloud rum und wenn ich eins sicher sagen kann: entpacken, kopieren laeuft immer besser als aus $paketverwaltung. ansonsten muss ich unter lighttpd immer das cgi/fastcgi-modul laden, php allein reicht ggf. nicht :)
owncloud hat mit cgi aber eigentlich nichts am Hut. Erkennt man schon daran, dass nichts von owncloud in /usr/lib/cgi-bin liegt.
Überprüfe mal ob diese Pakete installiert sind:
apache2 apache2-utils apache2-mpm-prefork php5 php5-common mysql mysql-server mysql-common libapache2-mod-php5 php5-mysql phpmyadmin sqlite php5-sqlite
Die Liste ist aus meiner Installationshistory unmittelbar vor Installation von owncloud.
Die letzten Befehle für apache waren 'a2ensite default' und 'a2enmod rewrite'.
Quote from: "michaaa62"phpmyadmin
Ich weiss, allmählich verkomme ich hier zum Miesmacher, aber auch mit phpmyadmin sollte man mehr als vorsichtig sein. Das Ding brauchts nicht nur nicht zum Betrieb von Owncloud (oder anderen php-basierten Anwendungen), sondern es klafft auch in ernstzunehmender Regelmäßigkeit voller wunderschöner Sicherheitslücken, die einem fix mal einen Spammer oder (wie mir schon selbst passiert) ein paar schicke Counterstrike-Server auf den Host spülen.
Ich kann daher nur empfehlen, phpmyadmin über die eingebaute Authentifizierung hinaus abzusichern.
Hallo,
@michaaa62
Alles installiert außer phpmyadmin. Der wollte nach der Installation dann die Konfiguration des apache übernehmen, aber nach cryptosteves Warnung hab ich das lieber bleiben lassen und ihn wieder deinstalliert.
Ich müsste mich mangels Ahnung auf die default Konfiguration verlassen können und "Sicherheitslücken mit ernstzunehmender Regelmäßigkeit" klingt nicht so vertrauenerweckend :).
@all
Ich schmeiß die 4.0.8... jetzt runter und hol mir die 4.5 oder 5, von owncloud direkt und schau mal wie's damit klappt.
Gruß
ayla
@cryptosteve: Danke für die Erneuerung der Warnung!
QuoteAction 'configtest' failed.
The Apache error log may have more information.
Your Apache 2 configuration is broken, so we're not restarting it for you.
grmbl. Ich geb auf.
:evil:
Wenigstens für heute. :)
Gruß
ayla
Ich werd bekloppt. Reine Verzweiflungstat:
apt-get purge apache2 apache2-mpm-prefork apache2-utils apache2.2-common
apt-get install owncloud owncloud-sqlite
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
owncloud-sqlite ist schon die neueste Version.
Die folgenden zusätzlichen Pakete werden installiert:
apache2 apache2-mpm-worker apache2-utils apache2.2-common
Vorgeschlagene Pakete:
apache2-doc apache2-suexec apache2-suexec-custom
Empfohlene Pakete:
exim4 mail-transport-agent
Die folgenden NEUEN Pakete werden installiert:
apache2 apache2-mpm-worker apache2-utils apache2.2-common owncloud
0 aktualisiert, 5 neu installiert, 0 zu entfernen und 10 nicht aktualisiert.
Es müssen noch 0 B von 2.669 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 12,0 MB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren [J/n]?
Danach -der Text im iceweasel.
Cache des weasel geflusht.
apt-get install libapache2-mod-php5
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
Die folgenden zusätzlichen Pakete werden installiert:
apache2-mpm-prefork
Die folgenden Pakete werden ENTFERNT:
apache2-mpm-worker
Die folgenden NEUEN Pakete werden installiert:
apache2-mpm-prefork libapache2-mod-php5
0 aktualisiert, 2 neu installiert, 1 zu entfernen und 10 nicht aktualisiert.
Es müssen noch 0 B von 2.667 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 8.837 kB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren [J/n]?
....
libapache2-mod-php5 (5.4.4-14) wird eingerichtet ...
Creating config file /etc/php5/apache2/php.ini with new version
[....] Restarting web server: apache2apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1 for ServerName ... waiting apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1 for ServerName
. ok
Iceweasel ruft localhost/owncloud auf...
und die Seite zum Anlegen des admin-Kontos erscheint. Das Einzige was ich anders gemacht habe gegenüber heute morgen, nachdem heefe mich auf das php-Modul hingewiesen hatte, war den Cache zu flushen.
Das glaub ich einfach nicht.
Gruß
ayla
Hi,
nach stundenlangem rumprobieren, Benutzerrechte, kopieren der owncloud-Dateien hin und her und immer des gleiche Ergebnis:
Zwar erschien inzwischen die Seite "Admin-Konto erstellen" bei der Version 4.0.8... aus den Sid-Repos, aber das wars auch schon.
Ein Konto erstellen ging nicht. Heißt: Nach dem Klick auf "erstellen" machte sofort wieder die Seite "Admin-Konto erstellen" auf mit wieder leeren Eingabefeldern. Egal ob Sqlite oder mysql ausgewählt war oder was auch immer. Es ging nix. :evil:
Versuch die 5.0 zu installieren scheiterte erst mal daran daß sich die admin-Dokumentation derselben für Debian/Ubuntu auf den Hinweis beschränkt diese vom openSuSe Buildserver zu installieren, wo aber auch keine Info zur Einrichtung zu finden war. ootb?? nee, iss nich.
Der Verzweiflung letzter Schritt:
1. Die 4.0.8 aus Sid installieren,
2. Ordner "owncloud" lokalisieren, in /usr/share finden und löschen!!
3. das "owncloud_5.0.0-0_all.deb" vom Suse-Server holen und entpacken
4. Auch das darin enthaltene "data.tar.gz" entpacken
5. Dort im erscheinenden Ordner var/www den Ordner "owncloud" nach /usr/share kopieren/verschieben
6. chown -R www-data /usr/share/owncloud
chgrp -R www-data /usr/share/owncloud
7. Hoffen daß die so noch vorhandene Konfiguration des vorher installierten 4.0.8 auch noch auf das 5.0 passt.
8. Wundern daß ich jetzt auf der Oberfläche des 5.0 ganz simpel meinen admin anlegen kann und das Teil tatsächlich auch funktioniert
Das werd ich aber wohl so nicht in ein wiki packen...
Gruß
ayla
Da fällt mir gerade mal ein .. hast Du ein Plugin im Browser, das Deinen Referer blockt bzw. ändert? Ich hatte genau so ein Verhalten mal, als ich RefControl als Firefox-Addon aktiviert hatte (ist hier standardmäßig aktiviert).
Owncloud liess einfach keine Registrierung des Adminkontos zu (kommentarlos). Nach Deaktivieren des AddOns für diese Seite ging es dann problemlos.
hmm, ich hab' nur das Flashplugin und adblock-plus drinne.
k.A. ob adblock sowas macht.
Aber jetzt wo ich weiß wie ichs im Notfall wieder hinkriege kann ich ja mal noch ein wenig probieren. Zumal das eh nur 'ne Testinstallation ist. Immerhin hat sie einiges an mehr Wissen gebracht :)
Nein, Adblock lässt den Referer eigentlich unangetastet ... fiel mir auch nur ganz spontan ein, weil ich damals selbst stundenlang geknobelt habe.
Viel Erfolg.
Quote from: "rolandx1"ich probier ja auch schon laenger mit mit owncloud rum und wenn ich eins sicher sagen kann: entpacken, kopieren laeuft immer besser als aus $paketverwaltung. ansonsten muss ich unter lighttpd immer das cgi/fastcgi-modul laden, php allein reicht ggf. nicht :)
lighttpd hat auch keinen eingebauten php support, deswegen brauchst du natürlich noch cgi/fastcgi. Apache ist in diessem speziell, weil es direkt ein mod_php für apache gibt, so das der php direktverarbeiten kann.
So, wiki (http://wiki.siduction.de/index.php?title=Owncloud_mit_durch_self_signed_Cientcerts_gesch%C3%BCtztem_Serverzugriff) ist fertig.
Korrekturen von versierteren Leuten sind natürlich gerne gesehen.
Gruß
ayla
Hi,
ich gehe mal davon aus daß ich mit der Authentizierung durch die Client-Certs bereits ein für den (vorerst) angestrebten Zweck -familieninternes Zwischenlager für die unbedingt notwendige schnelle Verbreitung von Enkelfotos etc- relativ hohes Maß an Sicherheit erreicht habe.
Was ich jetzt aber doch noch gerne hätte -vorwiegend interessehalber-, wäre, wenn in einem bestimmten Zeitraum von der gleichen IP eine bestimmte Anzahl von nicht berechtigten Zugriffsversuchen erfolgt, von dieser IP aus dann für einen definierten Zeitraum alle Zugriffsversuche vom Apache ignoriert werden -o.ä..
Ich meine ich hätte während meiner Suche nach dem Umgang mit Client-Zertifikaten auch irgenwo was zu dem Thema überflogen, irgendwas mit Auswertung der errorlogs oder so, aber ich find's einfach nicht mehr, google ist manchmal wirklich....
Hat jemand einen Tipp wo ich da -möglichst konkreten- Lesestoff zu finde?
Gruß
ayla
apt-cache search fail2ban
fail2ban - Sperrt Rechner, die mehrfach Authentifikationsfehler verursacht haben
Der Tipp stammt aus diesem Artikel von heise
http://www.heise.de/security/artikel/SSH-vor-Brute-Force-Angriffen-schuetzen-270140.html
Jupp, danke michaaa62, genau der war's.
hrmpf: Beim Ansehen des auth.log stelle ich fest daß ich wohl auch meinen ssh-port verlegen muß. Nah, hätt' ich gleich machen sollen....
Nee, fail2ban kriegt das auch super für ssh hin. Bei ssh empfielt es sich im übrigen genauso auf Zertifikate umzusteigen und Passwortlogins gar nicht mehr zuzulassen. Dann können sich die externen "Angreifer" da auch ohne fail2ban locker die Zähne dran ausbeißen.
Und Du musst nicht für jeden Login ein Passwort eingeben :)
Hi cryptosteve
Ja, hab' ich auch von Anfang an so angelegt. Allerdings muß ich jetzt für das Zertifikat ein Passwort angeben o.s.ä.
QuoteEnter passphrase for key '/home/cal/.ssh/id_rsa':
Aber
irgendwo hatte ich auch gelesen wie man das ändert.... :)
Das Verlegen des Ports und Begrenzen der login-Versuche soll mir eigentlich einfach diese gefühlten 150000 login Versuche von irgendeiner IP aus China aus den logs raushalten. Sicher fühl ich mich da eigentlich schon.
Gruß
ayla
Ändern der Passphrase ist nicht sonderlich kompliziert, obwohl ich das auch nur sehr selten mache - viel zu selten, wo ich so drüber nachdenke.
http://inhalt.serviert.de/wissen/security/ssh/aendern-einer-ssh-passphrase-change-ssh-key-openssh
Wenn Du Dir richtig sicher bist, dass keine Heimkiste nicht kompromitiert wird, kannst Du das Passwort auch ganz weg lassen. Dann fragt er dich halt überhaupt nicht mehr und connected sofort.
Das ist zwar sehr bequem, aber falls Dir einer Deinen Key abnimmt, steht ihm natürlich alles offen. Überschaubar, wenn man nur auf den Heim-PI zugreift, aber durchaus brisant, wenn man mehrere Netzkisten betreut.
Ansonsten dürfte auch keychain interessant für Dich sein. Damit brauchst Du den Key nur einmal per Passphrase aufschließen und er bleibt dann offen und wird von keychain verwaltet. Unter Ubuntu gehts sogar irgendwie per Anmeldepasswort (pam), aber das hab ich nie versucht unter anderen Systemen nachzubilden.
Und ja, Dein ssh-Log kannst Du sicher durch Änderung des Ports bereinigen.
Ayla: Nur ein Vorschlag zur Güte - nimm nginx für deinen pi, der Indianer ist eventuell leicht überdimensioniert für den armen Kleinen. Da wäre nur noch das Problem mit der Konfiguration und dem Kompilieren. :) Die Konfiguration kannst Du gerne haben, das kompilieren müsste der Pi tun.
Mal böse ausgedrückt: Da Du eh nicht so tief in Webservern drinsteckst, ist es eigentlich egal, wovon Du anfangs nichts verstehst. Ich persönlich finde aber die Konfiguration von nginx grade für Einsteiger, die nicht von Apache umdenken und umlernen müssen, sehr viel eingängiger und verständlicher.
BTW: Die php-Konfiguration auch.
Hi agaida,
normalerweise folge ich ja gern Deinen Anregungen -sofern ich sie ansatzweise verstehe...
Und böse ist das nicht, eher sehr freundlich :)
QuoteMal böse ausgedrückt: Da Du eh nicht so tief in Webservern drinsteckst, ist es eigentlich egal, wovon Du anfangs nichts verstehst.
Was mich davon abhält Deiner Anregung in diesem Fall zu folgen:
Quoteapt-cache show owncloud
....
Depends: apache2 | httpd, php5, php5-gd, php-pear, php-xml-parser, php-crypt-blowfish, php-sabredav, php-mdb2, php-mdb2-schema, libphp-phpmailer, php-getid3 (>= 1.9.3-1), php5-curl, owncloud-mysql (= 4.0.8debian-1.5) | owncloud-sqlite (= 4.0.8debian-1.5), libjs-jquery (>= 1.7.2-1), libjs-jquery-ui, libjs-jquery-jplayer
....
Ich würde zwar mal vermuten daß man Owncloud auch mit einem anderen Webserver nutzen kann aber ich bin im Moment einfach heilfroh daß es erst mal so läuft.
Taktik: Erst mal überhaupt zum Laufen bringen, dann für einigermaßen Sicherheit sorgen und jetzt kommt: Loch für Loch in den Käse fressen bis ich durch bin...
Allerdings, was das Kompilieren betrifft, das hätte mir schon jemand abgenommen:
Quoteroot@raspberrypi:~# apt-cache policy nginx
nginx:
Installiert: (keine)
Installationskandidat: 1.2.1-2.2
Versionstabelle:
1.2.1-2.2 0
500 http://mirrordirector.raspbian.org/raspbian/ wheezy/main armhf Packages
Gruß
ayla
ich brech ne lanze für lighttpd für alle die sich nicht mit der config von nginx ärgern wollen
Wenn ich das Ganze mal soweit habe und etwas besser dabei durchblicke werde ich mir auch mal die weniger massiven Web-Server anschauen um meinen Pi zu entlasten -dann kommt auch KDE wieder runter :)
Aber im Moment versuche ich mal dort weiter zu kommen wo ich bereits was zum Laufen bekommen habe sonst verzettel ich mich.
Für das Abwehren lästiger Zeitgenossen bin ich gerade dabei mir recent (http://snowman.net/projects/ipt_recent/) an zu schauen. Klingt nicht schlecht.
Gruß
ayla
ayla: kein Problem - dann hör wenigstens auf RolandX1 und nimm lighty. Und lass diese dösigen debian-Pakete weg. Die sind
a) total veraltet
b) mistig konfiguriert und wild im System verteilt
c) kurz gesagt - einfach über.
Das gilt nicht für den Client, der von hefee betreut wird. Da ist wieder Verstand bei.
Lad Dir den Tarball runter, entpack den in deinem Zielverzeichnis und gut ists gewesen. Apache, Owncloud, mod-php und Pi passen einfach nicht zueinander. Und eine Lösung mit lighty|nginx, php5-fpm|php5-fcgi, und owncloud aus Tarball ist wenigstens logisch nachzuvollziehen und wird der Power eines Pi gerecht.
ok, ich will ja nicht vollkommen beratungsresistent erscheinen... :)
Ich schmeiß das jetzt alles runter und probiers einfach mal von vorne mit lighttpd aus....
apt-get purge apache2 apache2-mpm-prefork apache2-utils apache2.2-common owncloud
apt-get autoremove
apt-get install lighttpd
...[ok] Starting web server: lighttpd
apt-get install php5-fpm
Jetzt hoff ich nur das Teil lässt sich wenigstens ähnlich wie der Apache einrichten.
Quote from: "ayla"Jetzt hoff ich nur das Teil lässt sich wenigstens ähnlich wie der Apache einrichten.
Ja, man muss auch Textdateien editieren. :D
Quote from: "cryptosteve"
Ja, man muss auch Textdateien editieren. :D
und eine (lighttpd.conf) hab' ich sogar schon gefunden... :)
Sogar gerade noch zwei mit denen ich wohl zu tun bekomme: 05-auth.conf und 10-ssl.conf
lighty-enable-mod ist auch ein sehr sinnvoller befehl (ssl/cgi) usw :)
Den hab ich schon entdeckt, trotzdem danke.
Schlag mich gerade mit dieser Seite (http://www.gambaru.de/blog/2012/05/01/lighttpd-webserver-konfiguration-mit-ssl-und-authentifizierung/) herum, aber lighty meldet einen error im configfile.c.943 -> parser failed. (auth.conf) Meine Adaption ist wohl (noch :)) nicht optimal.
Oder anders ausgedrückt: Ich blick noch nicht so wirklich durch.
Wird wohl heut abend auch nix mehr, erst mal drüber schlafen.
So,
ich bekomme via dnsdynamic und dem vorgegebenen Port auf dem Pi die index.lighttpd.html, allerdings noch nicht mit ssl obwohl ich das eigentlich dachte konfiguriert zu haben. Aber immerhin.
Wenn ich meine test.php aufrufen will bekomme ich ein "403" :evil:
Aber mal 'ne ganz andere Frage:
Ich hab' noch nichts gefunden was auf eine Authentizierung mit Client-Zertifikaten o.ä. hinweist. Geht das mit lighttpd? (oder mit nginx?)
Dann merke Dir mal gut, was genau Du da machst, damit Du das nachher auch aufschreiben kannst. An so einer Client-certificate-Authentifizierung hätte ich nämlich auch noch gesteigertes Interesse, habe mich da aber bislang irgendwie noch nicht rangetraut. :)
Hi ayla, Du kannst ja mal versuchen, ob Du auf dem PI auch SNORT zum Laufen bekommst. Vielleicht etwas überdimensioniert aber nun mal nicht umsonst (inkl. Abkömmlinge) DER Standard für IDS. Und man lernt bei der Beschäftigung damit unglaublich viel über Netzwerkprotokolle und alles was damit zusammenhängt.
Quote from: "cryptosteve"Dann merke Dir mal gut, was genau Du da machst, damit Du das nachher auch aufschreiben kannst.
Ich führ 'ne Datei in der ich (z.T.) mit protokolliere :)
ssl funktioniert erst mal auch.
Wenn ich dies hier (//http//redmine.lighttpd.net/projects/lighttpd/wiki/Docs_SSL) richtig interpretiere scheint die Geschichte mit Client-Zertifikaten wohl zu gehen.
ssl.verifyclient.activate enable/disable client verification
ssl.verifyclient.enforce enable/disable enforcing client verification
ssl.verifyclient.depth certificate depth for client verification
ssl.verifyclient.exportcert enable/disable client certificate export to env:SSL_CLIENT_CERT
ssl.verifyclient.username client certificate entity to export as env:REMOTE_USER (eg. SSL_CLIENT_S_DN_emailAddress, SSL_CLIENT_S_DN_UID, etc.)
Jetzt mal rausfinden wie... Sieht erst mal ziemlich kompliziert aus :(
@ralfi: Schau ich mir später mal an. Im Moment würde ich das gerne "einfach" mit recent hinkriegen.
Gruß
ayla
Hi,
EDIT
Ich glaub ich habs :D
Mein Client Zertifikat wird abgefragt und akzeptiert, wenigstens mal von einer Kiste! Ich muß es aber erst noch ausgiebiger testen -morgen, nach ausschlafen.
# /usr/share/doc/lighttpd/ssl.txt
ssl.engine = "enable"
ssl.pemfile = "/etc/lighttpd/server.pem"
ssl.ca-file = "/etc/lighttpd/server.cert.crt"
ssl.cipher-list = "ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH:!AESGCM"
ssl.honor-cipher-order = "enable"
ssl.verifyclient.activate = "enable"
ssl.verifyclient.enforce = "enable"
ssl.verifyclient.exportcert = "enable"
-urspünglicher Beitrag, weil jetzt irrelevant, gelöscht-1:00 Ortszeit, 25.3.
Edit: 26.03. 14:00
Owncloud 5.0 auf dem PI:
apt-get install ark
Aus dem admin-guide von owncloud:
apt-get install php5 php5-gd php-xml-parser php5-intl php5-sqlite curl libcurl3 php5-curl
Owncloud5.0.0 aus dem bz2 entpackt
kopiert nach /var/www
Versuch zu verbinden führt zu 403-error
Von http://redmine.lighttpd.net/projects/lighttpd/wiki/TutorialLighttpdAndPHP#Configuration :
/etc/php5/cli/php.ini editiert und cgi.fix_pathinfo = 1 freigeschaltet
fastcgi.server = ( ".php" => ((
"bin-path" => "/usr/bin/php-cgi",
"socket" => "/tmp/php.socket"
)))zu der lighttpd.conf hinzugefügt.
Verbindung erfolgreich-> Anlegen des admin-Kontos -> Fehlermeldung zu WebDAV -> nach Durchlesen diverser Bugreports, wie dort teilweise vorgeschlagen, ignoriert.
Neu verbunden -klappt und funktioniert.
Wiki folgt.
Gruß
ayla
Soweit geschafft: Wiki (http://wiki.siduction.de/index.php?title=Lighttpd,_client_certificates_und_owncloud_5.0_auf_dem_PI).
Jetzt nochmal zu recent :)
Danke an alle und Gruß
ayla
Mhmm ... dat iss aber mal respektabel!
Vielen Dank!
Quote from: "ayla"Soweit geschafft: Wiki (http://wiki.siduction.de/index.php?title=Lighttpd,_client_certificates_und_owncloud_5.0_auf_dem_PI).
Jetzt nochmal zu recent :)
Danke an alle und Gruß
ayla
hui! das nenn ich mal nenn guten wiki-eintrag.
danke ayla
Danke :)
Hab das wiki (http://wiki.siduction.de/index.php?title=Apache,_selbst_signierte_Client_Certificates_und_owncloud) für'n Apache und siduction auch nochmal überarbeitet, sollte jetzt auch brauchbar sein.
Gruß
ayla
@ayla
Danke für den wiki-Eintrag.
Anhand deines wiki-Eintrags habe ich eine frische wheezy Installation durchgeführt. dabei sind mir ein paar Kleinigkeiten aufgefallen, die man korrigieren bzw. ergänzen könnte.
Aktuell (27.03.2013 21:44) ist aber das wiki für mich nicht erreichbar (Error 502)
Jupp, krieg auch keine Verbindung, vielleicht ist ja gerade jemand am schrauben.. :)
Gibt es eine Lösung für die Nutzung des Desktop-Clients und der Android-App bei der Verwendung von Client-Zertifikaten?
Quote from: "whistler_mb"Gibt es eine Lösung für die Nutzung des Desktop-Clients und der Android-App bei der Verwendung von Client-Zertifikaten?
Das sieht nicht so aus als gäbe es da bereits eine Möglichkeit für den Desktop-Client -offener (Enhancement)Bug.
https://github.com/owncloud/mirall/issues/69
oder für Android:
https://github.com/bartoszprzybylski/owncloud-android/issues/23
Aber vielleicht kann jemand der da wirklich drin steckt mehr zu sagen.
Gruß
ayla
@ayla Ich habe jetzt ein paar Änderungen am Wiki-Eintrag gemacht und ein paar Sachen zu Diskussion gestellt.
Bin bereits beim Beantworten. Daumen hoch.
:)
Gruß
ayla