Server Firewall deaktiviert - aktivieren?

[Saugguat]

Im Rahmen meiner eigenen Bemühungen unser System sicherer zu machen habe ich gesehen, dass bei unserem Server in der CGM Erstinstallation vor 3 Jahren die Windows Firewall deaktiviert belassen wurde. Es läuft Windows Server 2012 R2, eine Firewall ist softwareseits also durchaus möglich.
Läuft TM oder das Netzwerk nicht gut mit einer aktivierten Windows-Serverfirewall? Der Server ist hinter einem Lancom Router ans Internet angeschlossen um Windows Updates und Updates der Antivirussoftware zu beziehen, sonst wird hier natürlich das Internet nicht benutzt. Wie ist das bei Ihnen eingestellt? Wenn Firewall - muss man bestimmte Dinge freischalten?

[Nobbie]

Wir haben auch Server2012. Die Windows Firewall ist an allen PC´s (Win10) und am Server aktiviert, macht keine Probleme.

[hofeBY]

Auf Unserem Server2012 R2 habe ich Norton Internetsecurity installiert und der übernimmt die Windowsfirewall und funktionierte dann auch mit meinen Standardeinstellungen

[mono22]

Microsoft Security Essentials In Windows Server 2012 R2 vor Jahren nachträglich aktiviert. Zusammen mit der MS Firewall keine Probleme.

[scottsdalegirl]

Windows Firewall am Server aktiv, keine Probleme. Windows SB Server 2011, nur Windows Defender. Wird nur als Server benutzt, IE Zugang deaktiviert.

[nmndoc]

Im Domänen-Netzwerk i.d.Regel deaktiviert (dh für andere Netze aktiv, aber der Server wechselt das Netz ja nicht so häufig )

TM trägt sich bei der Installation ja ohnehin (ungefragt) als Ausnahme ein - ebenso sämtliche andere CGM-Komponenten. Insofern sollte alles funktionieren. Umgekehrt gehe ich davon aus, dass ein Trojaner o.ä. sich auch als Ausnahme einträgt.
Bleibt noch ein gewisser Schutz innerhalb des LAN/Netzes, dass nicht ein infizierter Rechner via Netzwerk einen anderen infiziert - das "kann" in einem konkreten Fall helfen - wobei da zB keine Admin-Rechte evtl. schon genau so viel bringen (und evtl. sogar den Rechner etwas besser schützen, auf dem das "Problem" zuerst auftritt). Blieben dann noch die - meist recht weitreichenden - Freigaben des TM-Ordners, sowie ggf EKG, Sono etc etc etc - die natürlich trotzdem erreichbar sind.
Daher: s.o. - ist i.d. Regel aus.

[c-it]

Im Domänen-Netzwerk i.d.Regel deaktiviert

MMhh , also einzig für die Antwort auf die Frage ob meine FW die Datenkommunikation behindert sollte die FW
kurzfristig deaktiviert werden. Wenn nicht, liegt das Problem woanders, wenn doch, muss ein Loch gebohrt werden (Port öffnen).
Wenn natürlich der Hersteller die benutzten Ports nicht rausgibt oder der Admin diese nicht kennt, ist eine deaktivierte FW
ein Notbehelf, keine Dauerlösung.
PS: Ein Trojaner (wie schon die Historie zeigt) öffnet die Kommunikation von innen, da muss die FW schon die ausgehende
Kontaktaufnahme unterbinden. Und wenn der Trojaner dann gemeinerweise per https(443) seinen Master kontaktiert, stehen
die Chancen bei der FW nicht zum Besten ...

Guten Morgen
c-it

[nmndoc]

Im Domänen-Netzwerk i.d.Regel deaktiviert

MMhh , also einzig für die Antwort auf die Frage ob meine FW die Datenkommunikation behindert sollte die FW
kurzfristig deaktiviert werden. Wenn nicht, liegt das Problem woanders, wenn doch, muss ein Loch gebohrt werden (Port öffnen).
Wenn natürlich der Hersteller die benutzten Ports nicht rausgibt oder der Admin diese nicht kennt, ist eine deaktivierte FW
ein Notbehelf, keine Dauerlösung.
PS: Ein Trojaner (wie schon die Historie zeigt) öffnet die Kommunikation von innen, da muss die FW schon die ausgehende
Kontaktaufnahme unterbinden. Und wenn der Trojaner dann gemeinerweise per https(443) seinen Master kontaktiert, stehen
die Chancen bei der FW nicht zum Besten ...

Guten Morgen
c-it

WIr sprechen hier m.E. über die Client-Firewall - also die Windows-Firewall auf dem PC/Server - nicht über die Netzwerk-Firewall auf dem/den Gateway(s).
Genau deshalb hatte ich ja gefragt ob/welchen Schutz es bietet und man dich ggf. über das Szenario/Zielsetzung im Klaren sein muß.
Und ja, selbstverständlich öffnet ein Trojaner die Verbindung von innen - wie denn sonst? Und genau deshalb würde ich mich auf die Software-Firewall, die auf dem infizierten System läuft nicht zu sehr verlassen. Mal ganz abgesehen davon, dass man ja eigentlich protokollieren + regelmässig kontrollieren sollte, was so eine Firewall blockiert oder durchlässt - sonst werde ich nie merken, dass ich ggf. ein Problem habe. Einmal einschalten und vergessen funktioniert im Security-Bereich nicht.

Und eine Verbindung über 443 o.ä. muß für eine korrekt eingerichtete FW kein Problem darstellen. Vorausgesetzt ich setze ein etwas besseres Produkt ein, das mehr kann und "versteht" als ein besserer Portfilter.
(tatsächlich hat mit neulich ein Kunde gefragt "kann ich das dann auch selbst einrichten/verwalten"? Antwort kurz: nein. Antwort lang: theoretisch geht alles, praktisch wo soll der Sinn sein? Ohne entsprechende Erfahrung oder ausreichend Zeit+Lust+Geld mir diese anzueignen).

[bofh]

Vorausgesetzt ich setze ein etwas besseres Produkt ein,

Es wäre schon interessant zu erfahren, mit welchen Techniken die aktuellen Produkte derzeit aufwarten.

Um auf Port 443 nur HTTPS zuzulassen braucht man schon DPI. Das reicht aber nicht, da man über HTTPS auch einen Tunnel betreiben kann. Ein nachgeschalteter Proxy (so er überhaupt akzeptiert wird, da man ihm schon sehr vertrauen müsste) erschwert dies, könnte aber ein böswilliges Datenleck letztlich auch nicht verhindern. Das Wettrüsten geht weiter ...

Am effektivsten erscheint mir noch das Whitelisten der ausgehenden Adressen (in der Hoffnung, dass die vertrauenwürdige Gegenseite nicht verseucht ist und die Router dazwischen nicht verbogen wurden). DNS verbietet sich dabei eigentlich.

Wenn jetzt wenigstens noch CGM sinnvolle Informationen über die Kommunikationsschnittstellen ihrer Produkte bereitstellen würde. Im Benutzerhandbuch für die Doofen steht nur ein sehr vetrauensweckendes

Freigeschalteter Port 443 (regulär ist dieser freigeschaltet - falls erforderlich, unterstützt Ihr CGM TURBOMED-Vertriebs- und Servicepartner Sie jedoch gerne)

Auf die Antwort des Servicepartners warte ich noch immer.

[nmndoc]

Vorausgesetzt ich setze ein etwas besseres Produkt ein,

Es wäre schon interessant zu erfahren, mit welchen Techniken die aktuellen Produkte derzeit aufwarten.

Um auf Port 443 nur HTTPS zuzulassen braucht man schon DPI. Das reicht aber nicht, da man über HTTPS auch einen Tunnel betreiben kann. Ein nachgeschalteter Proxy (so er überhaupt akzeptiert wird, da man ihm schon sehr vertrauen müsste) erschwert dies, könnte aber ein böswilliges Datenleck letztlich auch nicht verhindern. Das Wettrüsten geht weiter ...

Am effektivsten erscheint mir noch das Whitelisten der ausgehenden Adressen (in der Hoffnung, dass die vertrauenwürdige Gegenseite nicht verseucht ist und die Router dazwischen nicht verbogen wurden). DNS verbietet sich dabei eigentlich.

Wenn jetzt wenigstens noch CGM sinnvolle Informationen über die Kommunikationsschnittstellen ihrer Produkte bereitstellen würde. Im Benutzerhandbuch für die Doofen steht nur ein sehr vetrauensweckendes

Freigeschalteter Port 443 (regulär ist dieser freigeschaltet - falls erforderlich, unterstützt Ihr CGM TURBOMED-Vertriebs- und Servicepartner Sie jedoch gerne)

Auf die Antwort des Servicepartners warte ich noch immer.

Guten Morgen,

grundsätzlich geht es ja schon darum, die Hürde möglichst hoch zu hängen und gleichzeitig einen Kompromiss aus Budget und dem technisch möglichen zu finden. Dann ist die Priorität natürlich unverändert Vorsorge zu betreiben / eine Infektion zu verhindern, als darauf zu vertrauen, in jedem Fall jegliche Kommunikation/Datenabfluss verhindern zu können (und Datenabfluss wäre ja nur ein mögliches Szenario).

Und ja, eine vernünftige Dokumentation des Herstellers bzgl. Ports/Kommunikation wäre in der freien Wirtschaft eine Grundvoraussetzung, ein Produkt überhaupt einzusetzen. Aber wir bewegen uns ja im (e)Healthcare-Umfeld

Zu den angesprochenen Maßnahmen um eine Infektion zu verhindern und/oder ggf. den Schaden/Kommunikation zu begrenzen (in loser Reihenfolge: SSL Interception, Advanced Threat Protection, Stateful Deep Packet Inspection, Application Control (zB ist das „https“ jetzt Youtube Video, Facebook Filetransfer, Windows Update, Bot-Tunnel, Websurfen, etc.), Deep Application Context, DNS Sinkholing, Reputation (IPs/Netze, Websites/ URLs, etc.), Dateityp-Erkennung, usw.
Wichtig ist hier, dass alles Maßnahmen ineinander greifen und – s.o. – man natürlich au weiß, was man (nicht) will.
Geräte wie TI/Konnektor, Labor-VPN-Box, etc. etc. sollte man am besten in ein eigenes getrenntes Netz packen, von dem aus keine Zugriffe ins z.B. Praxis-LAN möglich sind (nur umgekehrt). I.d. Regel haben Firewalls ja mind. 4 oder mehr Interfaces, so dass man hier gut trennen kann (und wenn’s eng wird kommen eben alle „Bösen“ in ein Netz – ggf kann man sie ja wenn man unbedingt will noch zumindest über VLANs trennen).