Hallo,
ich würde gerne einen KIX Member Server mit den folgenden Apps über Portfreigaben öffentlich ins Netz bringen:
Kopano Core, Webapp, WebMeetings, Z-Push, KIX, Nextcloud, OpenVPN4UCS, Self Service, SuiteCRM, OpenProject und ONLYOFFICE Document Server
Natürlich nur über die entsprechenden Ports die für die Dienste erforderlich sind. Spricht irgendwas dagegen? Bedarf es noch einer zusätzlichen Firewall oder wäre eine Proxy oder DMZ Lösung besser?
Kann man machen. Ich persönlich sichere so etwas immer mit einem Reverse-Proxy mit Client-Zertifikaten ab.
Wie sieht so etwas dann aus? Ich habe ein Debian als Beispiel, für dieses gibt es dann die Portfreigaben, welche auf den UCS weitergeleitet werden? Wie richtet man das ein? Hab kaum Erfahrung mit Proxys und gar nicht in dem Bezug mit Client Zertifikaten.
Leider ist das nicht gerade trivial. Die Idee dabei ist, dass man nur ein mal den Port 443 z.B. am Router auf den Reverse-Proxy weiterleiten lässt. Der macht dann die Sache mit dem Cleint-Zertifikat und leitet die Anfragen an den internen Server weiter in dem er die URLs auswertet. Zum Beispiel:
https://mein.heim.server.de/webapp -> https://server.intern/webapp
https://mein.heim.server.de/kix -> https://server.intern/kix
usw. Man könnte das mit einem simplen Debian mit eine Apache oder NginX als Reverse-Proxy machen. Hier mal zwei einigermassen brauchbare Anleitungen für den NginX:
https://arcweb.co/securing-websites-nginx-and-client-side-certificate-authentication-linux/
Die vermittelnt zumindest mal die Grundlagen. Aber wie gesagt, trivial ist das alles nicht. Das hier komplett durchzudiskutieren wenn man gar nicht weiss in welche Richtung das geht wird schwierig. Und noch mal, wie gesagt: Kann man machen, muss man aber nicht.
Du kannst auch einfach den 443 auf deinen Kopano-Server zeigen lassen. Dann kann aber auch jeder versuchen sich am Admininterface einzuloggen. Auch nicht so schön, meine ich. Wenn, dann würde ich das dann aber nur so machen:
Ob 2FA oder Reverse-Proxy mit Client-Zertifikat ist Geschmackssache. Ohne eins von beiden würde ich das aber nicht betreiben wollen.
Erstmal danke!
Kann ein Reverse Proxy auch ActiveSync Anfragen (Z-Push) weiterleiten?
Wie steht es mit den anderen Ports für IMAP und SMTP zum Beispiel? Wie macht man es dort am besten?
Wie sieht es mit Let’s Encrypt Zertifikaten aus? Kann die Ausstellung dieser auch über einen Proxy erfolgen?
Wie mache ich es mit VPN?
Wie schlimm ist es eigendlich einen UCS Member Server teilweise ins Netz zu stellen? Der Autor dieser Anleitung, hat, wenn ich es richtig verstehe, seine ganze UCS Domäne auf einem komplett öffentlich erreichbaren Server eingerichtet.
Das meiste ist Geschmacksfrage.
Ja, mach ich selbst so, mit Client-Zertifikat, halt historisch gewachsen, handgeschmiedet mittels STunnel (auch damit geht das).
Diese Prots müssen natürlich direkt auf den Server geleitet werden. Unten lese ich VPN. IMAP würde ich per VPN machen, wenn es geht, wenn nicht dann halt direkt. Auch das ist wieder Geschmacksfrage.
Let’s Encrypt und Clientzertifikate für HTTPS schliessen sich gegenseitig aus. Für SMTP und IMAP geht das.
VPN (ich nehme an OpenVPN) muss natürlich auch direkt nach innen gereicht werden.
Generell gilt: Alles was HTTPS ist kann durch einen Reverse-Proxy, der Rest muss direkt an den Server weitergeleitet werden. Mit eine Reverse-Proxy hat man halt mehr Kontrolle, dafür ist es komplizierter.
Gar nicht. Wie gesagt: Das ist alles Geschmacksfrage. Der Eine mag es so der Andere so.
Wo läuft denn dein Server? Zuhause oder bei einem Hoster? Ich würde vor so etwas auf jeden Fall eine Firewall setzten die mir so etwas was ich so vorgeschlagen habe alles abnimmt. Kann man aber auch alles basteln.
Das hier ist alles nur meine persönliche Meinung … kann man so machen, muss man aber nicht. Ich bin kein Anhänger der reinen UCS-Lehre und leide an ausgeprägter Paranoia 
… ich lasse am liebsten jeden das machen was er am besten kann. Virtualisierung, Proxmox, Firewall mit VPN etc., Securepoint, und den Rest den UCS.
Verlass dich da mal nicht nur auf das was ich dir erzähle und warte mal ab was z.B. @Moritz_Bunkus dazu sagt. Der hat sicher auch einige wirklich gute Ratschläge für dich parat.
I’ve been summoned? 
Geht mir ähnlich, aber mit moderater Paranoia 
Es gilt wie immer, dass man eine Balance aus Sicherheit auf der einen Seite und Bequemlichkeit & Komplexität auf der anderen Seite finden muss, der für die persönliche Situation passend ist. Natürlich gibt es Dinge, die man objektiv auf keinen Fall machen sollte (Demosystem mit User demo, Passwort demo, und aktiviertem SSH direkt öffentlich erreichbar? Keine gute Idee). Alles andere ist relativ.
Jeder Proxyserver, der verwendet wird, erhöht die Komplexität eines Systems, erfordert aktive Maintenance, und erfordert separate Sicherung. Was bringt es, einen Proxy zu verwenden, den man nie aktualisiert und der z.B. gegen die OpenSSL-Schwachstelle Heartbleed anfällig ist? Richtig, er höhlt die Sicherheit eher aus. Weiterhin muss man sich klarmachen, dass mit jeder weiteren Linux-Distribution, die man einsetzt, weiteres Wissen über Wartung, Sicherheit, Eigenheiten nötig ist.
Bei LINET und bei unseren Kunden stelle ich UCS-Systeme generell nicht direkt ins Internet und verwende für das allermeiste in der Tat Proxyserver, aus Gewohnheit sind das alles Ubuntu-Maschinen. Alle Webdienste hängen entweder hinter Apache oder nginx. Diese Proxysysteme habe ich deutlich stärker abgeschottet und halte sie deutlich aktueller, als unsere internen UCS-Systeme. Zugriff auf gewisse Anwendungen lasse ich von beliebigen IP-Adressen aus zu, auf andere, rein interne Systeme entweder über VPN oder über 2FA mit TOTP (hier greift zuerst ein Check auf Quell-IP-Adressen; wenn LINET intern oder VPN-Adressen, dann wird keine 2FA benutzt; andernfalls greift 2FA mit PrivacyIdea). Daher verwende ich hier explizit keine Client-Zertifikate. Ich habe nichts gegen Client-Zertifikate, die sind ebenfalls eine gute Form von 2FA.
Da diverse Dienste direkt im Internet erreichbar sind, habe ich zusätzlich die allermeisten Dienste so eingeschränkt, dass sie nur von gewissen Benutzern genutzt werden können (sprich über LDAP-Filter, teilweise über Gruppenmitgliedschaften, teilweise über eigene Attribute). Das z.B. schützt davor, dass der nur für kurzes Testen angelegte User test mit Passwort test gleich für die nächste Mail-Spam-Kampagne über das authentifizierende Mail-Relay genutzt wird.
SMTP ist insofern bei uns gerpoxiet, als dass unser MX auf eine Mail-Appliance zeigt, die Anti-Spam/Anti-Virus erledigt. Sie liefert erst anschließend an unseren internen Mailserver.
Der eine Dienst, der gar nicht geproxiet ist, ist IMAP — auch wenn wir hierfür nginx nehmen könnten, so sehe ich an dieser Stelle keinen deutlichen Gewinn an Sicherheit und erspare mir lieber die Komplexität.
Es gibt beim Thema Sicherheit kein absolutes »genau so musst du es machen«. Du als Admin musst allem voran verstehen, was du da machst; wie du deine Systeme absicherst; wie du sie aktuell hälst. Mit wachsendem Wissen solltest du dann regelmäßig überprüfen, ob die vorhandenen Sicherheitsmaßnahmen noch zeitgemäß sind und sie ggf. erweitern.
Gruß
mosu
Bei uns und allen Kunden finden Zugriffe von ausserhalb auf den UCS ebenfalls nur per Reverse Proxy statt. Wir setzen dazu Securepoint UTMs ein. ActiveSync funktioniert auf diese Weise einwandfrei.
Und SMTP landet ebenfalls zuerst mal auf dem Mailrelay/Mailfilter des UTM
Ebenso die VPN-Zugriffe, die jeweils auch auf der UTM landen.
Dafür darf die UCS-Maschine im internen Netz dann ohne weitere Firewall-Einstellungen rennen.
Mache ich genau SO.
Wir wissen aber nicht in welcher Umgebung Uwe das betreiben möchte und für ein privates Setup wird das mit Securepoint recht schnell Overkill …
Huhu,
was ich privat mache, ist eine Sophos SG (ehemals Astaro) zu verwenden. Die SG und XG gibt’s von Sophos als Software-Lösung für Privatanwender kostenlos, mit nahezu vollem Funktionsumfang — vor allem mit Anti-Virus-/Anti-Spam für SMTP und HTTP. Das ist definitiv ein Plus an Sicherheit.
Gruß
mosu
Weitere Alternativen:
pfSense
opnsense
Huhu,
bei welchen Größen wäre welche Art zu empfhelen?
Geht ein hohes Risiko aus, wenn ich ein privates UCS mit Nextcloud öffetnlcih erreichbar mache, um aus dem Urlaub Bilder hochladen zu können?
Reicht für ein Kleinbüro hingegen schon die Lösung mit einer Firewall aus?
Was unterscheidet die SG und XG?
Muss die Firewall physisch sein oder ist auch eine virtualisierte denkbar?
Huhu,
Meiner Meinung nach sind vollkommen unabhängig einer Größe professionell gemanagete Anti-Viren- und Anti-Spam-Lösungen immer sinnvoll. Nein, Amavis & ClamAV zählen nicht dazu; der Open-Source-Gedanke funktioniert bei sich ständig und schnell wandelnden Bedrohungen und Mechanismen schlicht nicht gut.
Eine reine Firewall vor UCS bringt insofern nicht viel, als dass man die Firewall auf dem UCS ebenfalls restriktiv bauen kann. Der Mehrwert einer Maschine davor ist aktives Scanning von Inhalten: zumindest E-Mails, wenn man mehr will auch Intrusion Prevention und Webinhalte scannen (in beide Richtungen, also z.B. auch die Webserver auf der UCS vor versuchten Angriffen von außen zu schützen).
Wenn man eine reine Firewall will, dann kann man nehmen was man will, aber man darf sich davon halt keinen echten Schutz versprechen. Ist so ein wenig wie Personenkontrolle vor dem Vatikan, die nur gewisse Leute reinlässt, dann aber nicht weiter in den Rucksack schaut und die Bomben damit durchlässt.
Zwei unterschiedliche Produkte mit unterschiedlicher Historie. Die SG ist deutlich älter und ausgereifter. Die Zukunft gehört der XG (leider), aber die ist in vielen Bereichen schlicht noch nicht so weit. Für Anfänger ist gerade die Initialeinrichtung bei der SG deutlich einfacher. Die SG wird auch noch Jahre lang supportet, hat die größere Community. Und gerade für Deutschland inzwischen relevant: die IPv6-Unterstützung ist bei der SG um Meilen besser.
Firewalls müssen nie physisch sein. Die Free-Home-Editionen der SG & XG gibt’s eh nur als Software. Ich lass die bei meinen privaten Servern (einmal zu Hause, einmal ein root-Server bei einem deutschen Hoster) jeweils in virtuellen Maschinen laufen (auf einem Server in KVM, auf dem anderen in VMware).
Gruß
mosu