Sicherheitsbedenken und Verbesserungsvorschläge für UCS

Apps & App Center
#1

Durch die Nutzung von Let’s Encrypt müssen ja bekanntlich Port 80 und 443 geöffnet sein, damit das Zertifikat automatisch erneuert werden kann. Damit sind aber auch die UCS-Console und alle weiteren Apps von aussen, z.B. über DynDNS erreichbar.

Beholfen habe ich mir derzeit durch eine .htaccess in /usr/share/univention-management-console-login. Damit wenigstens der Consolen-Login geschützt ist.

Bei bestimmten Apps, wie Nextcloud ist es nicht so schlimm, da Nextcloud auf Sicherheit getrimmt ist und 2FA aktivierbar ist. Das bieten aber nicht alle Apps.

Nun wollte ich aber BlueSpice verwenden. Jetzt müsste ich schon wieder irgendwo im Dateisystem eine .htaccess platzieren, damit das Wiki “nicht ins Netz geht”. Das ist für mich eigentlich keine Option mehr, hier händisch immer nacharbeiten zu müssen. Ausserdem besteht ja die Gefahr dass nach irgendeinem Upgrade die .htaccess entfernt wird, ohne dass man etwas mitbekommt. Weiss man’s?

Und die 2FA-Lösung von privacyIDEA ist bei kleinen privaten Installationen wie meiner preislich überhaupt keine Option. Irgendwie mit Kanonen auf Spatzen schiessen.

Irgendwie werde ich das Gefühl nicht los, dass es sich hier um einen groben Designfehler bei UCS handelt. Ich kenne z.B. Nethserver, wo die Managmentconsole von Haus aus nur von intern erreichbar ist. So sollte es eigentlich auch bei UCS sein …

Es sollte möglich sein, durch einfaches Anhaken einer Checkbox den Zugriff auf bestimmte Web-Apps von ausserhalb sperren zu können. Der Zugriff auf die Management-Console sollte aber aus Sicherheitsgründen überhaupt nur von intern möglich sein. Wer da was unterwegs zu ändern hat, nutzt doch das sichere VPN!

Was mir noch aufgefallen ist: Bei einigen Apps (z.B. BlueSpice) wird vor der Installation nicht geprüft, ob ausreichend RAM vorhanden ist. Die Installation läuft dann zwar mit Ach und Krach irgendwie durch - am Ende läuft das ganze aber doch nicht, weil Teile fehlen. Eine Deinstallation gelingt zwar scheinbar, es bleiben im Dateisystem aber Reste der alten Installation, die eine Neuinstallation verhindern, woraufhin man genötigt ist, mit locate händisch das Dateisystem nervenaufreibend durchzuforsten, oder das Forum zu bemühen …

Die Deinstallationsroutinen sind also in manchen Fällen noch nicht ausgereift, ebenso die Vorprüfungen.

UCS gefällt mir bisher von allen Opensource-Lösungen am besten, auch weil Debian-basiert. Die Sicherheitsmängel und Stabilitätsprobleme bei Installation/Deinstallation lassen mir aber derzeit keine andere Wahl, als derzeit nur Nextcloud mit UCS zu verwenden.

Schade.

#2

Hallo,

wenn ich mich richtig erinnere, wird das Portal mit UCS 4.4 so konfigurierbar, dass man nur noch nach Anmeldung die Applikationen sieht, auf die man Zugriff hat. Das könnte zumindest die diskutierte UMC-Problematik entschärfen.

Es wäre dann die Frage, wie sich die Drittanbieter-Apps in dieses Konzept einfügen. Da wird man vermutlich noch eine Weile mit den erwähnten Workarounds arbeiten müssen.

Ihre Anmerkungen zum (De-)Installationverhalten kann ich nachvollziehen. Allerdings sind die besser bei den App-Anbietern selbst aufgehoben. Es gibt zum Beispiel für die Apps einen von Univention bereitgestellten Parameter MinPhysicalRAM. Der App-Anbieter muss ihn nur benutzen.

Viele Grüße,
Dirk Ahrnke

#3

Vielen Dank für die Anmerkungen. Gut zu wissen, dass mit UCS 4.4 in absehbarer Zeit eine Verbesserung ins Haus steht. Damit kann ich dann schon mal leben. Ich hatte das insgeheim auch schon so gehofft :wink: Wusste aber nicht, dass die Drittanbieter für die Installationsroutinen verantwortlich sind. Wieder etwas schlauer. Dann werde ich dort mal nachhaken. In der Zwischenzeit nutze ich lieber die Snapshot-Funktion von Proxmox.

#4

Huhu,

in diesem Post habe ich eine Variante beschrieben, wie man mit einer einfachen, neuen Konfigurationsdatei für den Apache den Zugriff auf die UMC auf das lokale Netz beschränken kann. Das kann man auch recht einfach auf andere Anwendungen ausdehnen, ohne überall im Dateissytem .htaccess-Dateien hinterlassen zu müssen.

Man kann das sogar von der Erlaubnis her komplett umdrehen: für alles nur das interne Netz erlauben und einzelne URLs allgemein zugänglich machen. Ungetestet:

# Allow access for everyone to the Let's Encrypt locations:
<Location /.well-known/>
  Require all granted
</Location>

# Also allow NextCloud from everywhere:
<Location /nextcloud/>
  Require all granted
</Location>

# Only allow the local network to everything else:
<Location />
  Require ip 192.168.0.0/24 # put your local network address range here
  Require ip 2001:db8::/64 # you can have more than one allowed network range, and IPv6 works, too
  Require all denied
</Location>
#5

Ich mag mich irren, aber ist Nethserver nicht primär/ursprünglich eine Firewalldistribution? Hier macht es ja durchaus Sinn über unterschiedliche Interfaces zu arbeiten.

Edit: kein eigenes Interface, aber deren Management Oberfläche ist schlichtweg nicht über Port 80/443 zu erreichen.

#6

Hallo, danke das werde ich auch mal testen.

#7

Hallo für mich spielt das keine Rolle, da so oder so zu viel auf dem Spiel steht. Bei mir läuft alles eh nur noch über 2FA. Weniger ist nicht mehr zeitgemäss. Bei mir ist das nicht so wichtig, aber was ist, wenn ein Unternehmen UCS einsetzt? Heute mit dem ganzen DSGVO-Wahnsinn etc. Wenn da wichtige Daten abgegriffen werden und in die falschen Hände gelangen, ist das nicht so gut. Da heisst es dann entweder nur lokal betreiben oder selber irgendwie absichern. Nethserver muss gar nicht als Firewall genutzt werden, auch Nextcloud oder Mattermost ist direkt aus dem Softwarecenter installierbar. Allerdings basiert es auf CentOS und mir liegt Debian/Ubuntu mehr. UCS bietet auch mehr Bandbreite. Und wenn im Q2 sowieso UCS 4.4 erscheint, ist ja alles gut.

#8

Wenn man UCS-Dienste nach außen hin zugänglich machen will, sollte man IMO darüber nachdenken einen Reverse-Proxy einzusetzen. Das reduziert die Angriffsfläche IMO doch deutlich besser.

Just my two cents

#9

Ja das ist wohl wahr. Mit der Technik habe ich mich persönlich überhaupt noch nicht befasst … Das werde ich wohl jetzt mal nachholen müssen. Da mir maximale Sicherheit schon sehr wichtig wäre. Hier geht man auf dieses Thema ein. Der Aufwand scheint aber doch ziemlich gross zu sein: Reverse-Proxy

#10

Ich setze hier gerne eine Firewall wie OPNsense mit dem HAproxy Modul als Reverse Proxy ein.

Besonders mag ich, dass ich damit Dienste zusätzlich Clients per SSL Client Zertifikat authentifizieren kann. Somit können nur Nutzer, denen ich ein Zertifikat ausgestellt habe auch meine Dienste zugreifen.
Das kann z.B. dann pro Dienst festgelegt werden.

#11

Die Möglichkeit mit der Apache Konfigurationsdatei konnte ich testen, die Beschränkung auf das IP-Subnetz scheint zu greifen, allerdings bleibt auch der Nextcloud-Webordner gesperrt. (Die Kommmentarzeile hinter der IP-Adresse musste weg, Apache hat das als Fehler interpretiert) Bin zu wenig Experte um herauszufinden, wie Nextcloud oder andere Apps die Freigabe bekommen.

# Allow access for everyone to the Let's Encrypt locations:
<Location /.well-known/>
  Require all granted
</Location>

# Also allow NextCloud from everywhere:
<Location /nextcloud/>
  Require all granted
</Location>

# Only allow the local network to everything else:
<Location />
  Require ip 192.168.x.0/24
  Require all denied
</Location>
#12

OPNSense kenne ich. War mir aber dann wegen der zwingenden Kaskade (Fritzbox-IP-Telefonie wird gebraucht) zu aufgeblasen. (Innerhalb von Proxmox) Werde mir das aber trotzdem nochmal ansehen, wegen HAProxy .

Mastodon