Jump to content

Horstenberg

Members
  • Content Count

    114
  • Joined

  • Last visited

Community Reputation

13 Neutral

About Horstenberg

  • Rank
    Newbie

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Nach den vielen Tipps hier habe ich mich auch auf die Suche nach guten Artikeln zu SRPs gemacht. Mir hat - neben den Artikeln in der c't zu Restric'tor - bei der Einrichtung von GPOs dieser Artikel gut geholfen: https://trustedwindows.wordpress.com/2016/12/21/software-restriction-policies/
  2. Übrigens mal einen herzlichen Dank an Euch alle. Die Diskussion hier hat mich sehr weitergebracht und wird unser Netzwerk sicherer machen. Danke!
  3. Was heißt das? Wenn ich auf Windows Server 2016 eine entsprechende GPO kreiere, dann wird Applocker auf dem Win 10 Pro Client aktiviert?
  4. Applocker ist ein attraktives Tool, das stimmt. Nach meinen Recherchen muss auf dem Client aber Windows 10 Enterprise installiert sein. Oder stimmt das nicht mehr?
  5. Ok, dann habe ich es jetzt verstanden. Ich habe jetzt noch einmal mit dem Softwarehersteller Kontakt aufgenommen, dass er die Makro- und VBA-Sicherheit in Angriff nehmen soll. Mal sehen, ob es was bringt. Ich fasse mal zusammen, was ich aus dem Thread gelernt habe: 1. Es ist sinnvoll, das Remote Desktop Gateway hinter einer Firewall zu verstecken, insbesondere keine Portweiterleitung auf dieses zu machen. Die Nutzer müssen sich dann vorab per VPN einloggen, um an das Gateway zu gelangen. 2. Das VPN gehört eher auf die Firewall als das man es über eine Windows-Server-Maschine bereitstellt. Grund: Auch im Falle eines erfolgreichen Angriffs kann der Intruder dieses nur schwerer manipulieren, weil er die Firewall-Credentials nicht hat. 3. Bei Office im Unternehmensbereich empfehlen sich unbedingt Volumenlizenzen oder solche O365-Versionen, die über GPOs steuerbar sind. Dies kann im Einzelfall die Ausführung schädlichen Codes verhindern, wenn man über GPOs Makros und VBA entsprechend deaktiviert. Oder ist was falsch daran?
  6. Dennoch würde ich vermuten, dass es professioneller betreut sein dürfte als manch anderes, das von Emotet heimgesucht wurde.
  7. Wenn sich der Computer, von dem ich RDP mache, in einer anderen Domäne befindet (und an einem anderen Standort), und ich verbinde mich mit VPN, brauche ich dann kein Gateway?
  8. Ich glaube, ich verstehe Dich nicht vollständig. Wir sind auf einen Softwareanbieter angewiesen, der die gesamte Infrastruktur für die Texterstellung usw. bereitstellt und uns so auch zu bestimmten Einstellungen im Office zwingt. Einer von zwei oder drei Softwareanbietern in unserem Berufszweig, das hat nichts mit Kosten zu tun. Die anderen Anbieter sind jedenfalls meiner Meinung nach schlechter. Beispiel, was vor ein paar Tagen passiert ist: Ein Update dieses Herstellers erforderte auch, dass ein lokales Update im Office eines jeden Mitarbeiters eingespielt wurde. Dafür musste "temporär" dem VBA-Projekt vertraut und die Makro-Sicherheit heruntergestellt werden. Gestern habe ich mal wieder alle Maschinen durchgeguckt: An nur einem Arbeitsplatz war dann wirklich alles wieder zurückgestellt (nur signierte Makros und VBA-Häkchen weg). Bei allen anderen Arbeitsplätzen waren die Sicherheitseinstellungen im Office katastrophal. Der Kampf um Office-Sicherheit ist in solchen Umgebungen ein Kampf gegen Windmühlen. Wenn ich das mit Geld lösen könnte, ich würde es tun. Deswegen werde ich zB beim nächsten Mal Office über eine Volumenlizenz kaufen, wegen der GPOs. Ich kaufe auch zB immer mehr Windows-Server-Lizenzen, um die einzelnen Prozesse zu isolieren, auch wenn wir nur 10 Mitarbeiter haben. Ok. Dann habe ich jetzt folgende Idee: Bislang ist bei uns der Web Application Proxy zusammen mit dem Remote Desktop Gateway auf einer (virtuellen) Maschine. Das ist die Maschine, auf die der Port 443 geworwarded wird. Idee jetzt: Ich nehme das Remote Desktop Gateway von dieser Maschine runter. Das installiere ich dann auf einer neuen virtuellen Maschine, die dann ohne geforwardeten (?!) Port im Netz ist. Dann wäre das Remote Desktop Gateway von Außen gar nicht mehr erreichbar, sondern nur nach VPN-Login. Klingt gut?
  9. ja, das müsste gehen. In vielen Unternehmen kannst Du das aber nicht machen, weil die auf unsignierte Makros usw. zwingend angewiesen sind.
  10. Mit den GPOs, die vor ca. einem Jahr online waren, hatte ich es probiert. Die GPOs wurden von den bei uns installierten Home&Business-Office-Versionen nicht verarbeitet. Also habe ich alle Einstellungen von Hand machen müssen.
  11. Ich will nach dem Motto vorgehen: Never change a running system. Wenn ich im RDP gateway nur den "Haken" bei der Veröffentlichung über Port 443 wegnehme, scheint mir alles getan zu sein. Jeder andere Zugriff von extern scheitert ja schon an der Firewall. Oder mache ich da einen Denkfehler? Verstehe ich das richtig und sollen die in dem Artikel verlinkten GPO-Templates auch für Office-Versionen gelten, die nicht über Volume Licensing erworben wurden? Das wäre in der Tat ein Fortschritt.
  12. Der Bericht über den Emotet-Einbruch in das Heise-Netzwerk hat mich nachdenklich gemacht. Bislang sind wir zwar von Emotet ua. verschont geblieben, aber wenn es selbst das Netzwerk eines Computer-Nerd-Verlages derart hart treffen kann, dann ist jeder irgendwann dran. Auf heise.de wurde berichtet, dass es den Emotet-Gaunern auch gelungen ist, auf noch nicht ganz geklärtem Wege an die Credentials eines Domain-Admins zu gelangen. In der Folge sind die Gauner dann manuell über Remote-Desktop-Gateway auf die Server des Unternehmens gegangen um dort gezielt Daten und Backups zu kompromitieren und zu verschlüsseln. Wir haben hier nun ein Netzwerk, das wie so viele ein RemoteDesktop-Gateway bereitstellt, das über Port 443 im Netz steht. Über den Web Application Proxy auf Windows Server werden zudem der Exchange und WorkFolders veröffentlicht, auch das über Port 443. Andere Ports werden von der Firewall nicht geforwarded. Weiterhin hat das Unternehmen einen VPN-Zugang, der allerdings auf der Hardware-Firewall eingerichtet ist. Den VPN-Zugang halte ich für nahezu sicher, da er nur über direkten Zugang zur Hardware-Firewall geändert werden kann. Meine Überlegung ist nun die folgende: Ich beende die Veröffentlichung des RDP-Gateways über Port 443. Das RDP-Gateway wird nur noch veröffentlicht über Port 3391. Effekt: RDP funktioniert nur noch von außerhalb, wenn man sich vorher über das VPN ins Netzwerk einloggt. So will ich erreichen, dass das RDP über Windows-Credentials plus VPN-Erfordernis faktisch eine sehr effektive Zwei-Faktor-Authentifizierung erhält. Damit habe ich natürlich nicht die Emotet-Gefahr besiegt, aber wenigstens den Alptraum beseitigt, dass Emotet-Gauner über RDP unsere Server komplett "erobern." Was haltet ihr davon?
  13. So ist es. Der Web Application Proxy ist sehr gut dafür, um alle Dienste, die nach Außen weitergeleitet werden sollen, über eine zentrale Stelle weiterzugeben. Router/Firewall müssen dann nur für den web application proxy Ports öffnen bzw. weiterleiten. Die Veröffentlichung etwa des Exchange mit anderen Mitteln (etwa mittels anderem Server als reverse proxy) war bei mir nie besonders stabil. Der Web Application Proxy läuft bei mir seit langer Zeit total stabil. Wie gut die Workfolder-Apps für Android und IOS sind, weiß ich nicht genau. Die Installation unter Windows ist aber sehr einfach (jedenfalls ab Windows 8, bei Windows 7 bin ich mir nicht sicher).
  14. Da Du eine W16-Datacenter-Linzenz hast, würde ich an Deiner Stelle alles mit Windows-Mitteln machen: a) 1 w16 DC b) 1 w16 Fileserver, auf dem auch work folders läuft (work folders nutze ich seit Jahren, läuft bestens), c) 1 Exchange Server d) 1 w16-Server mit web application proxy und vpn, über den Du den Exchange und den work folders server veröffentlichst e) 1. w16-server mit adfs (leider läuft der web application proxy nur mit active directory federation services) Server d) muss dann mit der Außenwelt verbunden werden, statt dyndns würde ich zu einer festen ip raten. Du brauchst ein Zertifikat (am besten ein wildcard-Zertifikat), das sollte mittlerweile auch über let's encrypt gehen. Server b) kannst du auch in zwei Server trennen. Zur Veröffentlichung von work folders und exchange über wap und adfs gibt es gute Anleitung im Internet.
  15. DNS Kann eigentlich nicht das Problem sein. Der gleichzeitig laufende Server Manager hat alle Server innerhalb von 10 Sekunden. Das Admin Center braucht dagegen eine gefühlte Ewigkeit. Dazu speichert das Admin Center nicht die "verwalten als" Informationen beständig, wie es der Server Manager tut und damit das Verwalten mehrerer Domänen komfortabel erlaubt. Oder geht das bei den anderen schneller im Windows Admin Center?
×
×
  • Create New...