EDOMI von Remote/Internet verfügbar

[jonofe]

Ja genau das wäre meine Antwort. Es ist halt so, dass ja i.d.R. noch weitere Rechner/Geräte im internen Netz sind, also nicht nur der EDOMI Server.
Wenn der Reverse Proxy kompromittiert ist, dann nütz natürlich auch keine FW auf dem Reverse Proxy mehr. Und vom Reverse Proxy wären dann alle internen Geräte sichtbar und potenziell angreifbar. Daher wäre ein separater Router mit FW schon die bessere Variante.

Mit Reverse Proxy ist natürlich schon mal viel besser als den EDOMI Server direkt vom Internet aus erreichbar zu machen. Insbesondere weil du ja auch im DSL Router ggf. den Zugriff ausschließlich für die Amazon-IPs freischalten kannst. Ich weiss nicht, ob dies mit der Fritzbox geht, denn m.W. kann man da nur Ports weiterleiten aber nicht gleichzeitig filtern von welchen Quell-IPs dies erlaubt sein soll. Bin aber auch kein Fritzbox Experte.

[Aktor]

Sorry, war mir nicht 100%ig sicher ob mit "dazwischen" auch wirklich ein anderes Gerät gemeint ist oder ob das nicht doch auch mit einer Software "dazwischen" gelöst werden kann.

Vielen Dank nochmals.

[stonie2oo4]

Würd mir vielleicht auch mal ne Alexa zulegen und das auch über den Reverse-proxy lösen.
Hab jetzt hier noch ne owncloud (+irgendwann vielleicht mal noch nen Mailserver) auf extra Hardware, wenn ich diese auch über den Reverse-Proxy laufen lasse, macht es dann Sinn sie ins interne Netzt zu stellen, oder besser wie gehabt in der DMZ belassen, aber trotzdem zusätzlich über Reverse-Proxy?

[CrashnB]

Hallo Zusammen,

generell baut man ja eine DMZ, um Zugriffe in das "Sichere" interne Netz nicht erlauben zu müssen. Wenn ich nun ein Dienst habe, welchen ich aus dem internen und aus dem Internet erreichen muss, dann kommt der in die DMZ. Verbindungen in das interne Netz werden nur für Sessions erlaub, welche aus dem internen Netz herraus aufgebaut wurden.

Somit sollte ein ReverseProxy in die DMZ. Nach meinem oberen Ansatz müssten dann auch der EDOMI Server in die DMZ.

Im privaten Umfeld sehe ich das jetzt nicht so kritisch, da ist die Gefahr sich einen Trojaner einzufangen höher als aktiv gehacked zu werden.
Ein Trojaner baut ja dann auch eine Verbindung von innen her auf und umgeht somit das komplette sicherheits Konstrukt. Hier hilft dann nur entsprechende Software auf den Rechnern und sicherheits bewuster Umgang mit den Geräten.

Worauf ich allerdings achten würde ist, den nach aussen freigegeben Diensten die Gesprächigkeit ab zu gewöhnen. Also ein auf Apache 2.4 auf gebauter ReverseProxy sollte sich nicht als Apache 2.4 bei einer einfachen Anfrage bekannt geben, das ist alles in den entsprechenden Config-Dateien einzustellen.

Viele Grüße

CrashnB

[stonie2oo4]

Das der Reverse-Proxy in die DMZ muss, ist klar.
Aber nach deiner Erläuterung, wenn EDOMI theoretisch in der DMZ steht, müssten ja auch alle anderen Geräte mit dem Edomi nach intern kommuniziert in die DMZ???
Also z.B. Lüftung, ekey, LMS, Alexa, usw.

Deswegen die Frage wo meine owncloud, usw. am besten aufgehoben ist.
Wie gesagt momentan steht sie in der DMZ, aber diese hat auch schon das eine oder andere Loch ins interne Netz für LDAP und SMB.
Also von owncloud ist ein Port offen für LDAP auf den internen Samba Active Directory Domain Controller, dort werden die Benutzer/Rechte gepflegt.
Und dann hab ich, was mir noch weniger gefallen hat, noch den SMB-Port auf mein Datengrab freigegeben. Eigentlich nur aus Komfort-Gründe. Weil so konnte ich aus der owncloud direkt auf das home-Verzeichnis meines Benutzers zugreifen und hab so keine doppelten Daten rumliegen. Praktisch aber Sicherheitstechnisch wahrscheinlich totaler Krampf.

Jetzt war meine Überlegung eben ob es nicht geschickter wäre, einen Reverse-Proxy in die DMZ, und von diesem bräuchte ich ja nur den Port 443 ins interne Netz freigeben. Und intern können dann die beiden Server ungestört miteinander kommunizieren, oder übersehe ich da was?

[CrashnB]

Genau das wollte ich damit sagen, von der DMZ sollten sowenig löcher wie möglich ins interne Netz gerissen werden, das optimum ist natürlich keines.
Ich hab übrigens mit "pound" als ReverseProxy gute Erfahrungen gemacht.

Viele Grüße

CrashnB

[jonofe]

Ich würde es vom Schutzbedarf des jeweiligen Servers abhängig machen, wo er platziert wird. Der EDOMI Server sollte definitiv nicht in der DMZ stehen, sondern im internen Netz. Wenn dann wirklich eine Kommunikation von außen ins interne Netz notwendig ist, dann über einen Proxy, z.B. Reverseproxy, wenn es Webtraffic ist.
Wenn deine OwnCloud nur Daten enthält, die für das Internet bestimmt sind und es nichts ausmacht, wenn der Server kompromittiert wird, dann ab in die DMZ damit, ansonsten ins interne Netz und den Zugang von außern auf ein Minimum beschränken, z.B. via ReverseProxy.

Wenn du eine eigene E-Mail Domain betreiben willst, dann würde ich in der DMZ ein SMTP-Gateway aufsetzen und den eigentlich Mailserver im internen Netz. Das Gateway nimmt dann nur die E-Mail von außen entgegen und leitet die von intern kommenden E-Mails weiter. Gespeichert werden deine E-Mails dann aber auf dem internen E-Mail Server. Wenn du dann noch aus dem Internet deine E-Mails abrufen können willst, dann kannst du auf dem Mail-Gateway noch einen POP3/IMAP Proxy installieren (z.B. perdition).

[stonie2oo4]

jonofe Danke für die ausführliche Erklärung. Werde ich dann mal so umsetzen, also owncloud ins interne Netz und nur zugänglich über den Reverse-Proxy. So muss ich nur den einen Port öffnen, das fühlt sich nach der besseren Lösung an . Ebenso später mal EDOMI/Alexa.
Danke auch für die Erklärung mit dem Mailserver, jetzt weiß ich mal nach was ich suchen muss. Da werden wieder paar Nächte drauf gehn .

Wenn wir schon beim Thema sind, ich wollt mir eigentlich auch mal noch irgend wann ne Asterisk Telefonanlage einrichten. Hat noch nicht viel Zeit mich intensiv damit zu beschäftigen, aber bei dem was ich gelesen hab, war man sich nicht so ganz einig ob in DMZ oder nicht.
Hast du hier vielleicht auch noch einen Rat für mich?

[jonofe]

Ich habe vor einiger Zeit von purem Asterisk auf FreePBX umgestellt und betreibe diese auf einem Raspberry Pi. Bei mir läuft sie im internen Netz, da ich nicht (mehr) den Bedarf habe aus dem Internet heraus über die Asterisk Anlage zu telefonieren. Insbesondere weil mein Asterisk in der Vergangenheit mal aus Weißrussland gehackt wurde und dann wurde fleißig nach Haiti telefoniert. Ist aber schon ne ganze Weile her. Danach wurde die DMZ aufgesetzt und Asterisk ist seitdem im internen Netz. Da ich alle SIP Logins meines Anschlusses kenne ist dies auch problemlos ohne Umweg über die Telefoniefunktion der Fritzbox möglich. Inzwischen lasse ich mir jeden ausgehenden Anruf per Telegram signalisieren und habe auch ausgehende internationale Anrufe gesperrt.

Da heute Anrufe vom Mobiltelefon entweder durch eine Flatrate abgedeckt sind oder zumindest nicht mehr die Welt kosten, sehe ich keine Notwendigkeit aus dem Internet heraus über meinen Festnetzanschluss zu telefonieren. Und eingehende Anrufe werden bei Bedarf über Asterisk aufs Handy weitergeleitet. Daher klare Empfehlung für's interne Netz.

[stonie2oo4]

Bin ehrlich gesagt noch nicht zur Umsetzung meines Reverse-Proxies gekommen. Irgendwie schleicht sich immer was anderes dazwischen .
Aber hätte mal noch ne Verständnisfrage dazu. Also angenommen Reverse-Proxy in DMZ und Edomi im internen Netz. Zugriff von außen über Reverse-Proxy zu Edomi per Lets-Encrypt Zertifikat verschlüsselt. Von DMZ zu Edomi im Router Portfreigabe für "https" und "websocket".

Somit kann ich ja theoretisch von überall auf der Welt mit nem Browser auf Edomi zugreifen, Richtig?
Sobald ich mich mit Edomi verbinde bekomme ich ein Client-Zertifikat zugeteilt und die Verbindung ist verschlüsselt, Richtig?
Das heißt dass schwächste Glied ist dass Password (Admin/Visu/Remote), Richtig?

Wie verhindert man dann beispielsweiße eine Bruteforce Attacke?
Bei owncloud hab ich früher immer fail2ban bemüht und nach 3 falschen Logins die IP für paar Stunden gesperrt.
Habt ihr sowas auch mal für Edomi umgesetzt?
Oder hab ich an dem ganzen Konzept was übersehen / nicht verstanden?

[jonofe]

Du könntest deinen Reverse Proxy so konfigurieren, dass er Client Certificate Authentication macht, d.h. deinen Request nur an EDOMI weiterleitet, wenn der Client ein Client Certificate auf seinem Device installiert hat. Das sollte dann schon einigermaßen sicher sein, denn es dann eine multi-factor-authentication "Besitz (certificate)" und Wissen (EDOMI Password). Eine Bruteforce attack könnte nur dann überhaupt stattfinden, wenn der Angreifer ein Client Certificate hat.

Diese Beschreibung ist bei mir allerdings nur theoretischer Natur, da ich VPN bevorzuge. Aber vielleicht ist es ja ein möglicher Ansatz mit dem du weiterkommst...

[saegefisch]

Ich stelle mir die selben Fragen und nahm gleichfalls an, dass die Client Certifiacates aus meiner Sicht dabei unerlässlich, aber auch hinreichend sicher sind - mein Ziel war eine VPN-freie Lösung für edomi von überall aus. Ohne diese Zertifikate kommt niemand überhaupt nur an die Tür von edomi. Einziges Einfallstor ist meines Erachtens der ungeschützte Verlust eines Geräts mit Client Certificate. Ein iphone halte ich dafür für okay, da per fingerprint/langer PIN geschützt. Beim Laptop wäre bitlocker sicher eine gute Idee; ohne wäre der geklaute Laptop ein Risiko.

Oder überseh' ich ein Risiko?
Und: Kann ich ein einzelnes Certifikat widerrufen? Vermutlich schon, oder?

[ThorstenGehrig]

Hi,
es ist genau wie es sich seegefisch vorstellt: LetsEnyrpt liefert ein Server-Zertifikat - das Client-Zertifikat (und die zugehörige PKI) erstellt man sich selbst.
Das ganze ist "sicherer" als jedes Passwort - weil das secret (=client zert) viel komplexer als jedes PW ist. "Verliert" man das client-Zert kann man es revoken - oder einfach eine neue PKI und client zert erstellen (im Privatgebrauch).
Das ganze ist hier auch schonmal als howto dokumentiert (von mir und Lapheus) - damit sollte man eigentlich in aktzeptabler Zeit das ganze Umgesetzt bekommen.

Gruß
Thorsten

[saegefisch]

Zum Thema Zertifikate gibt es hier ein Update

[gerdj26]

Wie habt ihr die Probleme mit DS Lite gelöst ? Vorher war das per VPN kein Problem