[vz-users] Login/Absicherung von VZ Installationen

Fri Oct 20 01:03:18 CEST 2017

Hi Markus,

so, dann wollen wir mal!
Ich gehe davon aus, du betreibst eine Standardinstallation mit dem vz-Image?

cd /var/www
sudo git clone https://github.com/andig/volkszaehler.org
volkszaehler.org-next
cd volkszaehler.org-next
sudo git checkout jwt
sudo composer self-update
sudo composer install --no-dev
cd etc
sudo cp volkszaehler.conf.template.php volkszaehler.conf.php

in der volkszaehler.conf.php musst du dann:
* deine DB-Passwörter wieder eintragen, falls du eigene vergeben hast
* den auskommentierten DB-Admin-Zugang aktivieren (gibt sonst Ärger mit der
Aggregation)
* die zuvor schon beschriebenen Einstellungen für die Firewall eintragen
(Regeln, secretkey, user/password)

Danach kannst du in:
/etc/apache2/sites-enabled/000-default.conf

die Zeile:
DocumentRoot /var/www/volkszaehler.org/htdocs/

ändern zu:
DocumentRoot /var/www/volkszaehler.org-next/htdocs/

dann noch:
sudo systemctl restart apache2

Ab dann verwendest du die neue MW und das Frontend.

Hoffe das hilft dir weiter.

Viele Grüße
Frank

Am 19. Oktober 2017 um 15:06 schrieb "Markus Reiß" <reiss.ma at web.de>:

> OK Danke
> was meinst du damit??
>
> Da ich absoluter Linux laie bin und außer copy and paste nicht viel davon
> verstehe
> köntest du mich da mal schrit für schritt an die Hand nehmen.
> So wie du es unten schon mal gemacht hast .
>
> danke
>
>
> *Gesendet:* Donnerstag, 19. Oktober 2017 um 13:51 Uhr
> *Von:* "Frank Richter" <frank.richter83 at gmail.com>
>
> *An:* "volkszaehler.org - users" <volkszaehler-users at demo.volkszaehler.org
> >
> *Betreff:* Re: [vz-users] Login/Absicherung von VZ Installationen
> Hallo Markus,
>
> der Pull Request ist ja schon ziemlich alt, deshalb könnte ich mir
> vorstellen dass da die Abhängigkeiten nicht mehr passen.
> Alternativ kannst du die branches jwt oder auch next aus dem fork von
> Andreas verwenden, die sollten auf einem neueren Stand sein. Am besten in
> separates Verzeichnis clonen, dann bleibt deine master-Installation wie sie
> ist.
>
> Gruß
> Frank
>
> Am 19.10.2017 13:27 schrieb Markus Reiß <reiss.ma at web.de>:
>>
>> Hallo,
>> muss das mal wieder hoch holen :-(
>> hab das heute mal probiert zu installieren bzw zum laufen zu bringen
>> aber irgendiw schaff ich das nicht.
>> hab dieses so  gemacht wie Frank es geschrieben hat:
>>
>> cd /var/www/volkszaehler.org
>> sudo git pull
>> sudo git fetch origin pull/551/head:auth
>> sudo git checkout auth
>> sudo composer update
>> cd etc
>> sudo mv volkszaehler.conf.php volkszaehler.conf.backup.php
>> sudo cp volkszaehler.conf.template.php volkszaehler.conf.php
>> sudo nano volkszaehler.conf.php
>> 1) falls erforderlich, DB-Einstellungen und -Passwort wieder anpassen
>> 2) Firewallregeln checken (im Lieferzustand ist im lokalen Netz alles
>> erlaubt, von Remote geht lesender Zugriff (GET) ohne, alles andere nur mit
>> Login)
>> 3) bei 'secretkey' ein paar zufällige Zeichen einsetzen
>> 4) bei 'user' => 'pass' eigene Zugangsdaten eintragen (oder nur mal kurz
>> testen und dann die Zeile löschen/auskommentieren, falls kein HTTPS
>> vorhanden ist!)
>> sudo systemctl restart apache2
>>
>>
>> Als erste kam das ich kein Token habe.
>> also einen generiert und abgespeichert unter /home/pi/.composer/auth.json
>> danach schien die git  durch zu laufen (binn mir aber nicht sicher.
>>
>> Nun läuft er lockal wie gewohnt
>> aber von extern nicht mehr:
>> kommt EXTENSION: Invalid proxy access .
>>
>> was ist da nun schief gelaufen
>>
>> Danke für euere hilfe.
>> Gruß Markus
>>
>> *Gesendet:* Freitag, 13. Januar 2017 um 19:31 Uhr
>> *Von:* "Andreas Goetz" <cpuidle at gmail.com>
>> *An:* "volkszaehler.org - users" <volkszaehler-users at demo.
>> volkszaehler.org>
>> *Betreff:* Re: [vz-users] Login/Absicherung von VZ Installationen
>> Hallo Frank,
>>
>> s.u.- ist alles gefixt und der PR aktualisiert.
>>
>> Viele Grüße, Andreas
>>
>>
>> On 12 Jan 2017, at 17:59, Andreas Goetz <cpuidle at gmail.com> wrote:
>>
>>
>>
>> On 12 Jan 2017, at 00:04, Frank Richter <frank.richter83 at gmail.com>
>> wrote:
>>
>> Hallo Andreas,
>>
>> ich antworte mir mal selbst, jetzt hab ich das ganze nämlich doch
>> getestet (auf einem Pi mit VZ-Image, auf dem normalerweise nur vzlogger
>> läuft, weil meine DB woanders liegt).
>> Ich bin dafür, das bald zu mergen, läuft schon recht gut und
>> Einrichtungsaufwand hält sich ja sehr in Grenzen. Mein Test war jetzt ohne
>> HTTPS, aber so lang das users-Array leer ist und die voreingestellten
>> Firewallregeln verwendet werden, sollte da ja nix passieren.
>>
>>
>> Sehe ich auch so. Vielleicht hat @Justin noch einen Kommentar dazu?
>>
>>
>> Wer schreibenden Zugriff von Remote möchte, muss sich dann eben mit mit
>> HTTPS befassen. Den default user würde ich dann allerdings wirklich aus der
>> Konfiguration werfen.
>>
>>
>> Check.
>>
>>
>>
>> 2 Sachen, die mir beim Testen aufgefallen sind:
>> * 'action' => 'deny' sollte besser kein Login-Fenster bringen
>>
>>
>> Good catch. Die Weiche baue ich ein.
>>
>>
>> * wenn 'methods' => 'GET', action' => 'allow' gesetzt ist, wird das
>> Frontend ja normal geladen. Dann kann ich Kanaleigenschaften bearbeiten,
>> beim Speichern erscheint Login. Wenn ich mich dann einlogge, wird die ganze
>> Seite neu geladen, gemachte Änderungen gehen aber verloren
>>
>>
>> Mhm, das stimmt und wäre ein Issue wert. Nie getestet weil “das geht ja
>> nicht”. Außerdem dachte ich immer der Fehler kommt beim laden der Seite-
>> jetzt allerdings passiert er beim speichern.
>>
>> Man müsste also etwas einbauen dass quasi den Request aufhält,
>> Credentials abholt und dann erneut ausführt. Bestimmt möglich aber tricky.
>> Könnten wir fürs erste mit dem Istzustand leben? Gerade wenn man die
>> Haltbarkeit der Token auf z.b. 1 Woche konfiguriert würde es aus dem
>> Internet- wo heute gar nichts geht- ja ziemlich selten passieren???
>>
>>
>>
>> Grüße
>> Frank
>>
>>
>> Viele Grüße, Andreas
>>
>>
>>
>>
>> Am 11. Januar 2017 um 18:27 schrieb Frank Richter <
>> frank.richter83 at gmail.com>:
>>>
>>> Hallo Andreas,
>>>
>>> aus meiner Sicht ist die Absicherung per Login absolut wichtig und
>>> sollte rein, denn private Kanäle sind auf Dauer/bei diversen verwendeten
>>> Geräten einfach unbequem, und jedesmal eine VPN-Verbindung aufzumachen, um
>>> kurz nach dem VZ zu schauen, finde auch eher unpraktisch.
>>> Jetzt ging es im ganzen Thread fast ausschließlich um die High
>>> Performance Middleware und nicht um das Login-Feature. Kannst du vielleicht
>>> nochmal kurz darauf eingehen, wie sich ein Merge des Features auf neue (per
>>> install.sh oder mit einem neuen Image erstellte) und bestehende (durch git
>>> pull akualisierte) Installationen auswirken würde?
>>> Laufen die dann noch out of the box oder sind zwingend zusätzliche
>>> Schritte notwendig? Wenn ich das richtig sehe, muss für bestehende
>>> Installationen auf jeden Fall die volkszaehler.conf.php angepasst werden.
>>> Wie ist es mit HTTPS, ist das dann unbedingt erforderlich, oder geht es
>>> mit der letzten Änderung ((=lesender public Zugriff auf VZ)) auch ohne?
>>> Laut meiner Recherche klappt Let's Encrypt zusammen mit einer DDNS-Adresse
>>> nicht immer reibungslos, weil Let's Encrypt die Zahl der Registrierungen
>>> pro Domain beschränkt.
>>> Ich bin leider noch nicht dazu gekommen, den PR selbst zu testen, weil
>>> ich grad keine Installation auf aktuellem Stand habe - da bin ich aber
>>> dran...
>>>
>>> Grüße
>>> Frank
>>>
>>> Am 11.01.2017 09:21 schrieb "Andreas Goetz" <cpuidle at gmail.com>:
>>>>
>>>> Hallo Zusammen,
>>>>
>>>> 2017-01-03 20:33 GMT+01:00 Andreas Goetz <cpuidle at gmail.com>:
>>>>>
>>>>> Hallo,
>>>>>
>>>>> Frohes Neues Jahr Zusammen!
>>>>>
>>>>> Ihr wisst ja dass ich hartnäckig sein kann. In den letzten Tagen haben
>>>>> ich nach dem mißglückten Merge daher massiv Arbeit darein gesteckt alle VZ
>>>>> Komponenten wieder 100%ig funktionsfähig zu machen.
>>>>>
>>>>> Dazu gehören auch die High Performance Middleware (siehe
>>>>> https://github.com/volkszaehler/volkszaehler.org/
>>>>> tree/master/misc/tools) und der zuletzt nicht mehr korrekt
>>>>> funktionierende push-server (gleicher Link).
>>>>>
>>>>> Apropos High Performance Middleware: ich muss nochmal Werbung dafür
>>>>> machen dass die MW damit in der Lage ist Requests in wenigen (<10!)
>>>>> Millisekunden zu beantworten. Wäre Klasse wenn wir das in das Image
>>>>> einbauen könnten (@Udo: einmalig kann ich das gerne einrichten, ist im Link
>>>>> aber auch recht gut dokumentiert).
>>>>>
>>>>> Auf der Basis habe ich dann auch gleiche die Testskripte renoviert und
>>>>> User Authorization neu aufgesetzt (https://github.com/
>>>>> volkszaehler/volkszaehler.org/pull/551). Aus meiner Sicht wäre das
>>>>> Feature damit reif standardmäßig in VZ einzuziehen. Bei Bedarf könnte ich
>>>>> noch eine Option einbauen es ggf. auch komplett abzuschalten falls sich die
>>>>> individuelle Konfiguration der Firewall Regeln dafür als zu aufwändig
>>>>> erweist.
>>>>>
>>>>
>>>> Mittlerweile sind auchd ie Anforderungen von Klaus (=lesender public
>>>> Zugriff auf VZ) in den PR 551 mit eingebaut. Wäre es nicht lagsam Zeit die
>>>> Funktion zu mergen oder gibt es wirklich keinen Bedarf?
>>>>
>>>> Wenn wirs mergen wollen gäbe es zwei abschließede Punkte:
>>>> - Default user (user/pass) aus der Konfiguration entfernen?
>>>> - Gäbe es noch notwedige Anpassungen an den Firewall Regeln vor Release?
>>>>
>>>>
>>>>>
>>>>> Viele Grüße, Andreas
>>>>>
>>>>>
>>>>>
>>>>> On 27 Aug 2016, at 12:33, Andreas Goetz <cpuidle at gmail.com> wrote:
>>>>>
>>>>> Hallo Zusammen,
>>>>>
>>>>> das prinzipielle Feedback war zwar “brauche ich nicht”, ich habe mir
>>>>> aber trotzdem mal den Spass gemacht, Firewall und User Authorization
>>>>> prototypisch zu implementieren.
>>>>>
>>>>> Wer damit spielen möchte findet hier den Code: https://github.com/
>>>>> volkszaehler/volkszaehler.org/pull/458
>>>>>
>>>>> Das Ganze basiert auf JSON Web Tokens für Bearer Authentication und
>>>>> sollte tunlichst- da Username/ Passwort übertragen werden- _nur_ über HTTPS
>>>>> Anwendung finden.
>>>>>
>>>>> Die Änderungen an der vz.conf Datei sollten eigentlich hinreichen
>>>>> erklären was es zu konfigurieren gibt. Freue mich über Feedback im PR.
>>>>>
>>>>> Viele Grüße,
>>>>> Andreas
>>>>>
>>>>>
>>>>>
>>>>> On 15.08.2016, at 11:36, Andreas Goetz <cpuidle at gmail.com> wrote:
>>>>>
>>>>> Ich mache Jacobs Mail mal als neues Thema auf:
>>>>>
>>>>>>
>>>>>> Bei der Durchsicht der URL-Befehle habe ich gesehen, dass anscheinend
>>>>>> auch schreibend auf die Datenbank zugreifen kann. Ist das nicht
>>>>>> gefährlich, so einen Webserver ins öffentliche Netz zu stellen, wenn
>>>>>> jeder daran herum fummeln kann?
>>>>>
>>>>>
>>>>> Äh, ja, das ist das Prinzip von vz. Allerdings muß man ja die UUID
>>>>> kennen, um Kanäle und deren Daten manipulieren zu können, deswegen sollte
>>>>> man die UUID auch geheim halten (und Kanäle nicht einfach public machen,
>>>>> sonst kann man sie einfach so auflisten). Neue Kanäle anlegen und nutzen
>>>>> geht aber natürlich schon.
>>>>> M.W. hatte Justin das so konzipiert, damit z.B. demo.volkszaehler.org
>>>>> ohne Anmeldung (und Passwort-Recevory, Email etc. pp.) genutzt werden kann.
>>>>> Faktisch ist es aber heute wohl so, daß die meisten ihren eigenen VZ-Server
>>>>> laufen haben, da finde ich das eher ungeschickt (zumal die UUIDs auch etwas
>>>>> unhandlich sind).
>>>>>
>>>>> -- snip --
>>>>>
>>>>> Ich sehe- wenn wir es einfach halten wollen- 2 Anwendungsfälle:
>>>>>
>>>>> a) Absicherung einer privaten Installation
>>>>> b) Usermanagement für eine öffentliche Installation wie demo
>>>>>
>>>>> Letzteres klammere ich mal aus da es grundlegende Änderungen an VZ
>>>>> erfordern würde. Für a) gibt es verschiedene Möglichkeiten von furchtbar
>>>>> einfach bis etwas umfangreicher:
>>>>>
>>>>> 1) Basic Authentication, also Username + Password. Für ein Mindestmaß
>>>>> an Sicherheit ist SSL erforderlich- das gilt ebenso aber auch für alle
>>>>> weiteren Varianten. Das muss zusätzlich so konfiguriert werden dass
>>>>> vzlogger (aus dem internen Netz) ohne Basic Auth weiterhin seine Daten
>>>>> abliefern kann.
>>>>>
>>>>> 2) Token Authentication: initiales Login per U/P, ab da Token der
>>>>> expired. Dabei hätten wir sogar die Möglichkeit einzelne User zu
>>>>> definieren- imeinfachsten Falle per Konfigurationsdatei, sonst als
>>>>> Datenbankerweiterung. Wenn Datenbankerweiterung dann können wir auch Rechte
>>>>> vergeben (schreiben, löschen, lesen) und Kanäle zu Usern "gehören" zu
>>>>> lassen.
>>>>> Weiterhin wäre es ggf. sinnvoll authentifizierten Nutzern auch
>>>>> "private" Kanäle ohne Kenntnis der UUID anzubieten.
>>>>>
>>>>> Gibts Bedarf?
>>>>>
>>>>> Viele Grüße,
>>>>> Andreas
>>>>>
>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20171020/d9cc2222/attachment-0001.html>