EDOMI von Remote/Internet verfügbar

[eriche]

Ich habe gelesen, dass das CentOS unter Version 7 viele Sicherheitslücken hat.
Da kann Edomi sicher sein, wenn aber das Betriebssystem veraltert ist und Lücken hat.

[wintermute]

Ich habe gelesen, dass das CentOS unter Version 7 viele Sicherheitslücken hat.

Aha, mal was ganz neues.. gibts dafuer auch Quellenangaben?

[BadSmiley]

Aha, mal was ganz neues.. gibts dafuer auch Quellenangaben?

"hat mir ein Kollege erzählt! Der ist absolut seriös, kennt sich aus und macht schon ewig IT für den BND! "

[heckmannju]

Als Kabel BW/Unitymedia geplagter habe ich einen IPV6 Anschluss und einen IPv4 DS-Lite Stack. Somit habe ich keine Chance für einen "einfachen" Zugriff mittels VPN.

Wie kann ich dennoch meine Visu von "außerhalb" sicher erreichen?
Danke!

Gugst du hier. Läuft bei mir auf einem Raspi sehr zuferlässig.
http://www.feste-ip.net/dslite-ipv6-...informationen/

[baumhaus123]

Hi
Ich halte von VPN und VPNonDemand nicht viel... da muss man zum einen auf den Verbindungsaufbau warten - zum anderen das VPN wieder schließen...

Kann ich beides nicht bestätigen. Habe bei mir vor Kurzem VPNonDemand fürs iPhone i.V.m. ner Fritzbox eingerichtet und finde es genial schnell und simpel. Sobald ich von unterwegs meine Edomi Visu aufrufe habe ich (bei 4G) in weniger als einer Sekunde eine aufgebaute VPN-Verbindung. Diese wird nach ein paar Minuten Inaktivität auch selbständig wieder geschlossen. Ich will nichts anderes mehr.

[ThorstenGehrig]

... in weniger als einer Sekunde eine aufgebaute VPN-Verbindung. Diese wird nach ein paar Minuten Inaktivität auch selbständig wieder geschlossen. Ich will nichts anderes mehr.

Schonmal was anderes ausprobiert?
0-Sekunden für den zusätzlichen verbindungsaufbau? Und dazu keine Beeinträchtigung für andere Apps (die über sich über eine neue IP-Adresse wundern, neue sessions aufbauen, ... z.B. Email)?.
Oder ist der VPN-Tunnel so aufgebaut das nur die Visu durch den Tunnel geht und der rest nicht? (Split tunnel / per App VPN?).
Will aber keinem was einreden - wenn es funktioniert - ist es ja gut.

Leider hat mir noch keiner auf die Frage nach Ports geantwortet... dann muss ich wohl nachher mit FIDDLER mal selbst schauen :-(

Gruß
Thorsten

[NurMa]

Kann ich beides nicht bestätigen. Habe bei mir vor Kurzem VPNonDemand fürs iPhone i.V.m. ner Fritzbox eingerichtet und finde es genial schnell und simpel. Sobald ich von unterwegs meine Edomi Visu aufrufe habe ich (bei 4G) in weniger als einer Sekunde eine aufgebaute VPN-Verbindung. Diese wird nach ein paar Minuten Inaktivität auch selbständig wieder geschlossen. Ich will nichts anderes mehr.

Hast Du Dich da an irgendeine bestehende Anleitung gehalten? Ich habe das letztens mal mit meiner Synology versucht, war aber wenig erfolgreich.

[wintermute]

Irgendwelche Tipps ob zusätzliche Ports etc. gebraucht werden?

Die Visu laeuft normal auf Port 80, das ist alles was Du brauchst. Wenn Du eh nen Reverse-Proxy davor baust, wuerde ich den aber auch gleich von HTTPS auf HTTP uebersetzen lassen.

[DerSeppel]

Schonmal was anderes ausprobiert?
0-Sekunden für den zusätzlichen verbindungsaufbau? Und dazu keine Beeinträchtigung für andere Apps (die über sich über eine neue IP-Adresse wundern, neue sessions aufbauen, ... z.B. Email)?.
Oder ist der VPN-Tunnel so aufgebaut das nur die Visu durch den Tunnel geht und der rest nicht? (Split tunnel / per App VPN?).
Will aber keinem was einreden - wenn es funktioniert - ist es ja gut.

Leider hat mir noch keiner auf die Frage nach Ports geantwortet... dann muss ich wohl nachher mit FIDDLER mal selbst schauen :-(

Gruß
Thorsten

Die Beeinträchtigungen für andere Apps kommen ja normal davon, dass der VPN Client allen Traffic über den VPN routet.
Das sollte sich aber einstellen lassen. Entweder direkt auf dem VPN Server (ich meine die Fritzbox macht es nicht) oder im Client.
Dem musst du dann sagen, dass er den Gateway-Push vom VPN Server ignorieren soll.
Ich verwende mittlerweile den Fritzbox-internen VPN Server (IPSEC) mit VPNCilla auf dem Android Handy. Schnell, transparent, problemlos.
Sowohl mit Edomi als auch vorher mit dem HS.

[ThorstenGehrig]

Hi
@wintermute: scheinbar habe ich beim reverse-proxy ein problem mit dem PHP.
Wenn ich die PHP-Sachen aus dem Proxy ausschließe
ProxyPassMatch ^/(.*\.php)$ !
Dann passiert schonmal "etwas" - die Verbindungsanimation läuft... aber verbinden tut er sich nicht.
Vermutlich muss ich mich da nochmal einlesen... irgendeine Idee von euch?

@DerSeppel: einstellen lässt sich alles - aber nicht so einfach ... und daher mach ich es gleich "kompliziert" und nutze reverse-Proxy mit Zertifikats-basierter authorisierung.... Läuft auch für die Webcams (zusätzlich umgesetzt als HTTPS). Jetzt muss es nur noch laufen für Edomi...

Gruß
Thorsten

[DerSeppel]

ThorstenGehrig Welchen VPN Server und welchen Client nutzt du denn?

[ThorstenGehrig]

Hi
DerSeppel : ich verwende keinen VPN Client.
Der aufbau ist folgenddermaßen:
Der Client baut eine Verbindung zu meinem Reverse-Proxy auf
Der Reverse-Proxy fragt den Client nach einem Client-Zertifikat.
Wenn das Client-Zertifikat vorhanden wird die Verbindung zum Server weitergeleitet.

Bonus: durch die Analyse der Subdomain kann der reverse-Proxy die Verbindung an den jeweiligen Server weiterleiten.

Beispiel:
https://edomi.meinedomain.dyndns.org => weiterleitung an den Edomi-Server bei gleichzeitiger Umsetzung der HTTPS auf HTTP Verbindung
https://hs.meinedomain.dyndns.org => weiterleitung an den HS bei gleichzeitiger Umsetzung der HTTPS auf HTTP Verbindung
https://doorcam.meinedomain.dyndns.org => weiterleitung an die Doorcam bei gleichzeitiger Umsetzung der HTTPS auf HTTP Verbindung
usw.
Nichts davon erfordert ein VPN - dafür miss der reverse proxy aufgesezt werden.
Und man braucht eine PKI um seine eigenen client-zertifikat zu erstellen...

Gruß
Thorsten

[ThorstenGehrig]

Okay - jetzt funktioniert meine Konfig... keine Ahnung was ich vorher falsch gemacht hatte.
Für den fall das es jemand interessiert (kurzfassung - CA erstellung & co erspare ich mir hier).
Voraussetzung: aktueller Apache 2.4

edomi-ssl.config

<VirtualHost *:443>
    ServerAdmin thorsten@gehrig.info
    ServerName edomi.meinserver.dyndns.org

    ErrorLog /var/log/apache2/edomi.error.log
    CustomLog /var/log/apache2/edomi.access.log combined

    ProxyRequests off
    ProxyPass /  http://192.168.0.100:80/


    # SSL
    SSLEngine On
    SSLCipherSuite HIGH:MEDIUM
    SSLCertificateFile    /etc/letsencrypt/live/edomi.meinserver.dyndns.org/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/edomi.meinserver.dyndns.org/privkey.pem

    # activate the client certificate authentication
    SSLCACertificateFile /etc/ssl/keys/ca.crt
    SSLVerifyClient require
    SSLVerifyDepth 2

</VirtualHost>

In kurz: der Reverse-Proxy hört auf 443 - verbinded aber zu 80.
Die Server-Zertifikate habe ich per Letsencrypt automatisch erstellt. Die CA wird danach referenziert - und der client muss ein Zertifikat genau DIESER ca zur authentifizierung vorzeigen.

Gruß
Thorsten

[saegefisch]

Hallo Thorsten,
das hört sich ziemlich cool an (ich fand bis vorgestern eigentlich das VPN schon ziemlich cool). Der VPN-Lösung mit einer Fritzbox vertraue ich hinsichtlich der Sicherheit dabei hinreichend bei einem hinreichenden Passwort. Von außen kommt bei mir derzeit schlicht gar nichts rein - außer eben per VPN. Ich habe keine offenen Ports (hoffe ich zumindest).
Aber wie sähe das mit einem reverse proxy aus? Müsste man dann - in Deinem Beispiel - Port 443 als portforward durch die Fritzbox ein Loch bohren und der reverse proxy würde sich um die Sicherheit hinter dem Port kümmern? Und der reverse proxy liegt mit seiner eigenen IP bereits im LAN auf einem Server, richtig? Wie sicher ist das, denn ein Angreifer auf dem Port wäre zumindest mal schon durch die FW der Fritzbox. Oder stünde der vor einer Fritzbox? Oder gibt es in Deinem Konstrukt derlei Frage gar nicht, denn der reverse proxy ist Teil einer UTM-Lösung bei Dir, die FW, NAT,... abdeckt?

Bitte sieh' mir ggf. laienhafte Fragen nach, in dem Bereich habe ich nur knappes Wissen und ein wenig Ahnung (im Sinne: ich ahne etwas dazu). Daher habe ich mich bisher stets vom Löcher-reißen fern gehalten, da man mit Halbwissen sich viel Unheil fangen kann.

[Lapheus]

Okay - jetzt funktioniert meine Konfig... keine Ahnung was ich vorher falsch gemacht hatte.
Für den fall das es jemand interessiert (kurzfassung - CA erstellung & co erspare ich mir hier).
Voraussetzung: aktueller Apache 2.4

...

In kurz: der Reverse-Proxy hört auf 443 - verbinded aber zu 80.
Die Server-Zertifikate habe ich per Letsencrypt automatisch erstellt. Die CA wird danach referenziert - und der client muss ein Zertifikat genau DIESER ca zur authentifizierung vorzeigen.

Gruß
Thorsten

Hallo Thorsten,

Muss noch mal nachfragen:
Das Letsencrypt Zertifikat und die Client Authentifizierung funktioniert so?
War bisher davon ausgegangen das beides gleichzeitig nicht möglich ist.

saegefisch

Ich nutze das wie Thorsten...
Ja, Port 443 ist dann auf den Reverse-Proxy durchgeschaltet. Der Apache der da läuft sollte also aktuell sein.

Du kannst auf sslguru ein Zertifikats Test machen und schauen ob du ein A+ bekommst.
Da gibt es z.B. auch den Hinweis bestimmte Protokolle zu verweigern.

Macht man in obiger Datei mit:

 # SSL
    SSLEngine On
    SSLHonorCipherOrder On
    # SSL - Protokoll/Chipher
    SSLProtocol ALL -SSLv2 -SSLv3
    SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH EDH+aRSA !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4"