Webinterface nur lokal erreichbar machen

MofoMooh

Sers zusammen,

wie bekomme ich es zuverlässig hin, dass das Webinterface nur lokal erreichbar ist und nicht per Internet?

DocFraggle

Da musst Du die Firewall entsprechend konfigurieren

MofoMooh

DocFraggle Danke dir für deine Antwort. Das Problem was ich hierbei habe ist, dass Port 80 für ACME weiterhin offen sein muss für alle.

esackbauer

Nur zur Info, wenn du das “Webinterface” nicht zugänglich machst, wird auch CalDAV und CardDAV nicht mehr übers Internet funktionieren.
Warum willst du das überhaupt deaktivieren fürs Internet? SMTP z.b. muss übers Internet erreichbar sein, mailcow wurde ja mit der fail2ban/netfilter Integration ja gerade deswegen so gebaut, dass man es ins Internet hängen kann.

MofoMooh

esackbauer Es geht nur um das Admininterface, welches aus meiner Sicht nicht unbedingt für jedermann zugänglich sein muss, trotz 2FA. CalDAV und CardDAV wird nicht benötigt. Hier benötige ich nur Zugriff aus dem lokalen Netz. SMTP ist ja weiterhin offen.

esackbauer

Security by obscurity ist nicht verlässlich. Die Mailcow UI ist ja nicht nur für Admins, sondern auch für die normalen User da.
Und wenn du CalDAV, CardDAV etc nicht brauchst, stellt sich die Frage ob du überhaupt SOGo brauchtst, und damit stellt sich die Frage ob du nicht mit Mailu oder Docker Mailserver besser beraten wärest, weil die weniger komplex sind und damit weniger Angriffsfläche bieten.

Was du machen könntest ist ein vorgeschalteter nginx reverse proxy, der die Zertifikate für mailcow erstellt und dorthin kopiert, und deaktivierst den ACME im Mailcow:
https://docs.mailcow.email/de/post_installation/firststeps-ssl/#ein-eigenes-zertifikat-verwenden
Dann kannst du 443 und 80 am reverse proxy gegen eine Dummy-Seite oder überhaupt ins Leere laufen lassen.

MofoMooh

esackbauer Naja, ‘Security by obscurity’ ist hier nicht korrekt. Ich versuche nichts zu ‘geheim zu halten’, sondern ich will verhindern, dass das UI aus dem Internet erreichbar ist und somit entferne ich eine potentielle Angriffsfläche. Nur weil ich CalDAV, CardDAV oder ggf. SOGo nicht benötigt, wird mailcow nicht unbedingt obsolet für mich.
Die Lösung mit dem Reverseproxy schaue ich mir einmal an, ich hätte mir erhofft dies einfach wie beim Apache durch ‘rules’ lösen zu können.

Beispiel:
<Directory /var/www/html/webaccess> Order allow,deny Allow from 127.0.0.1 </Directory>

DocFraggle

oder irgendwie die Nginx Config anpassen damit /debug (bei Admin-Login) nur intern erreichbar ist. Die User werden auf /user umgeleitet.
Aber schön ist anders…

esackbauer

MofoMooh Ich versuche nichts zu ‘geheim zu halten’, sondern ich will verhindern, dass das UI aus dem Internet erreichbar ist

Genau das ist die Definition von Security by Obscurity…

Du hältst die UI vor dem Internet geheim (die man evtl. mit der Firewall auf einzelne Länder oder Provider begrenzen könnte), aber dein SMTP server und ggf. auch IMAP und POP ist offen für das ganze Internet…
Ich erlebe in meiner 35 Jährigen IT-Karriere immer wieder das Risiken falsch eingeschätzt werden, da wird oft durch Umbiegen einer Standardlösung oder Workarounds das ganze sogar unsicherer, weil man die Konsequenzen, Abhängigkeiten oder die Angriffsvektoren falsch einschätzt.

Für das sichere Publishen von Webanwendungen gibt es Web Application Firewalls, ich verwende z.B. die Sophos Firewall (kostenlos für Homeuser), die können Reverse Proxy sein und man kann sehr granular einstellen was genau für wen sichtbar sein soll, und es gibt Alarme wenn z.b. bekannte Lücken ausgenutzt werden, bzw. werden diese gleich geblockt.
Also wenn man das Thema Sicherheit ernst nimmt, dann sollte man sich eher sowas mal ansehen anstatt an einer bestehenden sicheren Lösung herumzudoktoren, die dann ziemlich sicher Probleme beim nächsten Upgrade verursacht.

MofoMooh

esackbauer Danke dir erneut für deine Antwort. Es lässt sich natürlich trefflich darüber streiten ob mein Vorhaben ein ‘Geheim halten’ darstellt oder einfach nur die entsprechende Funktion beschränkt. Jedoch finde ich es verwegen zu sagen ‘Es ist wenig sinnvoll, da dein SMTP/IMAP/Server offen sind’ - Korrigier mich gerne wenn ich dich da falsch verstanden habe. Nicht benötigte Komponenten ‘abschalten’ trägt sehr wohl zur Sicherheit des Gesamtsystems bei, denn es ist nicht auszuschließen das Lücken diese Komponente betreffend zur Kompromittierung des gesamten Servers führen können. Siehst du dies weiterhin als falsche Risikoeinschätzung? Ich sehe nicht wie dies eine falsche Einschätzung der Konsequenzen (Bitte zähle mir diese gerne auf), Abhängigkeiten oder Angriffsvektoren sein kann.

Nichtsdestotrotz back to the topic:
Ist es möglich die Datei ‘sites.active’ permanent mit eigenen Werten zu versehen?

DocFraggle

Ich denke Du kannst es damit versuchen:

https://docs.mailcow.email/manual-guides/Nginx/u_e-nginx_custom/#config-expansion-in-mailcows-nginx

esackbauer

Das Problem ist mailcow ist so designed wie es eben designed ist, das hat seine Gründe und das finde ich nicht schlecht. Ich sehe nur Vorteile darin die Mailcow UI, SOGo und Card/CalDAV von überall aus sicher zugreifen zu können, so sehen das auch meine User. Bzw. kann ich das ja über eine vorgeschaltete Firewall einschränken wenn ich glaube damit sicherer zu sein.
Tatsächlich waren die meisten Sicherheitslücken der Vergangenheit im Bereich postfix/dovecot zu verorten…

Solche Dateien zu verändern, die nicht dafür vorgesehen sind, ist eben ein Risiko, bestenfalls verstolpert sich das nächste Update daran, schlimmstenfalls geht etwas kaputt weil es einen breaking change gab, und man muss wieder Hilfe suchen oder aufwendig reparieren. Das will ich meinen Usern nicht zumuten.
Da wäre man mit einer anderen Lösung wie ich weiter oben geschrieben habe vielleicht besser beraten.
Ich verwende die Produkte so wie sie designed wurden, eben weil mailcow out of the box super funktioniert und keine Bedrohung darstellt, verändere ich nur das nötigste.