Jump to content

Horstenberg

Members
  • Gesamte Inhalte

    139
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von Horstenberg

  1. vor 11 Stunden schrieb daabm:

    Ich bin voll bei den beiden Norberts :-) Makros gehören deaktiviert (nur signierte zulassen), und Applocker sollte dringend aktiviert sein. Notfalls SRP - die c't stellt da was halbwegs brauchbares bereit...

    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?

  2. vor 22 Stunden schrieb NorbertFe:

    Ich bezog mich auf "müßte gehen". Denn das ist ja eben das Problem mit den nicht VL Lizenzen seit O2013, dass wie oben geschrieben die Policies Zweige nicht ausgewertet werden und ein Import per Reg dann eben nicht zum Verbot führt, sondern zu einer Einstellung, die der Nutzer ggf. auch einfach wieder ändern kann. Der Rest bzgl. deiner Aussage und diversen Softwareherstellern ist mir auch schon begegnet und man fragt sich, ob die in den letzten 10-15 Jahren irgendwo unterm Stein gewohnt haben bzgl. Sicherheit und moderner Software.

    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?

  3. vor 3 Stunden schrieb NorbertFe:

    Nein eben nicht, weil diese Office Versionen eben die /policies Zweige nicht auswerten in denen ein User nicht schreiben darf. Also bleibt bei Office nur die registry im User hive und rate mal, wer da schreiben darf. Aber muss ja immer alles billig sein. ;)

    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. 

    vor 4 Stunden schrieb Sunny61:

    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?

  4. vor 9 Stunden schrieb Nobbyaushb:

    Wenn du nur via VPN Zugang zulassen willst, warum dann nach extern veröffentlichen?

     

    Dicht und gut.

    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?

    vor 10 Stunden schrieb xrated2:

    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.

  5. 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?

  6. vor 14 Stunden schrieb Kompl3xX:

    Ja, warum denn nicht?

    Hallo Horstenberg, besten Dank. Die Idee mit Workfolders finde ich klasse, kannte ich noch nicht. Die App für Android scheint ganz gut bewertet, allerdings nur knapp 10.000 x heruntergeladen. Ich werde mich einlesen und es ausprobieren.

     

    Warum würdest Du einen web application proxy verwenden? Soll vermieden werden, dass mehrere Server direkt veröffentlicht werden?

    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).

  7. Am 31.1.2019 um 18:14 schrieb Kompl3xX:

    Hallo mwiederkehr, Dankeschön für die Antwort. Dann würde ich eher Nextcloud in Erwägung ziehen, da eine Synchronisierung gewünscht ist.

     

    Nun habe ich gelesen, dass es bei Nextcloud auf einer VM Probleme mit dem Dateisystem geben kann, wenn die Dateien auf dem Host liegen.

    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. 

     

     

  8. vor 11 Stunden schrieb lefg:

     

    Moin

     

    Natürlich, zum Betreten eines anderen Sicherheitsbereiches -andere Domäne, andere Domänen-SID-, also eine Anmeldung nötig. Könnte es denn anders sein?

     

    Langsamer Zugriff? Da denke ich gleich an DNS.

    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?

  9. Hallo allerseits!

     

    Welche Erfahrungen habt Ihr bisher mit dem Windows Admin Center (Project Honolulu) gemacht? Ich habe bislang immer den Server Manager und die Remote-Server-Administration-Tools (rsat) zur Verwaltung von Servern genommen. Windows Admin Center habe ich jetzt zwar installiert, scheint mir aber bislang eine große Enttäuschung zu sein: Sehr langsamer Zugriff, umständliche Bedienung, gerade wenn man in mehreren Domänen verwaltet (immer wieder Neuanmeldung erforderlich)?

     

    Nutzt hier schon jemand das Windows Admin Center und ist zufrieden?

     

    Herzliche Grüße, Horstenberg.

  10. vor 25 Minuten schrieb magheinz:

    Wir hatten einen Fall da lies sich die Verschlüsselung nachvollziehen.der atrojaner war seit etwas mehr als zwei Wochen aktiv bis er bemerkt wurde. Kommt dann noch Urlaub dazu sind schon 6Wochem rum.

     

    Musst du gesetzliche Auflagen erfüllen und z. B. Dateien 10Jahre fürs Finanzamt aufheben? 

    Die Unterlagen fürs Finanzamt kann man ja auch noch in Papierform aufbewahren. 

     

    Mails sichern wie mittlerweile über Mailstore. Das Programm ist wirklich gut mit einer guten Suchfunktion.

  11. Am 14.11.2018 um 06:42 schrieb MarcoW75:

    Anhand der Position der verschlüsselten Dateien war zu erkennen,dass sich der Trojaner wohl von einer Netzwerkfreigabe zur anderen "vorgehangelt" hat...was nicht freigegeben war, wurde auch nicht verschlüsselt.
     

    Über welchen Zeitraum kann sich so ein "Vorhangeln" eines Verschlüsselungstrojaners hinziehen? Das heißt wie alt sollte das älteste Backup sein im Zeitalter der Verschlüsselungstrojaner?

     

    Das älteste Backup, das ich je gebraucht hatte, war auf einen Zugriffs- und Benutzerfehler zurückzuführen. Ein Mitarbeiter hatte versehentlich einen Ordner mit wichtigen Archivdaten gelöscht. Dies fiel über Monaten niemand auf. Der Ordner wäre weg gewesen, wenn nicht irgendwo eine uralte Sicherung noch rumgelegen hätte, in der der Ordner noch bestand.

     

    Ist dies bei Trojanern auch schon passiert, dass diese über einen langen Zeitraum unbemerkt ihr Unwesen getrieben haben, so dass man sehr alte Sicherungen hervorholen muss?

  12. Am 20.11.2018 um 08:52 schrieb ASR:

    Ich kenne sehr viele Freiberufler, insbesondere die, die keinen eigenen Mailserver betreiben. Die haben Ihre Mailbox wo auch immer in der Cloud, sei es 1&1/GMX, Gmail, Microsoft etc. 

    Wenn ich so drüber nachdenke, kenne ich eigentlich überhaupt keinen Freiberufler der für sich einen Server in den eigenen vier Wänden mit einer einzigen Mailbox betreibt. Wie also kommst Du zu der Einschätzung?

     

    Der Freiberufler mit Einmann-Büro hat natürlich regelmäßig keinen Exchange. Ich meine allerdings die große Kolonne der früheren SBS-Kunden: Das Rechtsanwaltsbüro mit drei Anwälten und vier Mitarbeitern; der Notar mit sechs Mitarbeitern; die ärztliche Gemeinschaftspraxis mit drei Ärzten und 8 Mitarbeitern; die Steuerberaterpraxis mit 8 Mitarbeitern usw. Die hatten (früher) alle einen SBS mit Exchange, dazu noch die eigene Spezialsoftware auf dem on-premises Server. Nach dem Sterben des SBS haben viele auch einen eigenen Exchange. 

     

    Die Cloud kommt für diese Berufsgruppen nur in Betracht, wenn die eigenen Standesorganisationen die ausdrücklich abgesegnet haben (etwa DATEV bei den Steuerberatern). Viele wollen aber on Premises bleiben. 

     

    • Danke 1
  13. Was ist nun die richtige Strategie für kleinere Unternehmen, die aus berufs- oder datenschutzrechtlichen Gründen nicht in die Cloud wechseln können? Hierzu dürften insbesondere viele Freiberufler gehören (etwa Ärzte, Notare), die oft nicht mehr als 10 Arbeitsplätze zu versorgen haben. Offensichtlich ist es für Microsoft nicht mehr attraktiv, für diese den Exchange als on-Premises-Version bereitzustellen. Exchange ist ein weltweit angebotenes Produkt. Die Sorgen von im Verhältnis dazu recht kleinen Berufsgruppen dürften wirtschaftlich für Microsoft keine ausreichenden Anreize setzen, um umzusteuern. 

     

    Wenn man von Jahr zu Jahr denkt (was bleibt einem in der IT anderes übrig), beginnen spätestens mit Veröffentlichung von Outlook 2022 Probleme. Exchange 2013 wird voraussichtlich mit dieser Outlook-Version nicht mehr zusammenarbeiten. Büros können dann noch auf Exchange 2016 wechseln (wenn ein Exchange 2016 nicht bereits läuft), gewinnen damit aber auch nur 2,5 Jahre. Eine kaum mehr lohnenswerte Investition. 

     

    Was dann? Aus meiner Sicht ist Exchange vielleicht das beste überhaupt von Microsoft entwickelte Produkt. Keine andere Groupware kann da mithalten. Alles was hier bislang so vorgeschlagen wird, führt bei mir nur zu Unwohlsein. 

  14. Am 23.10.2018 um 14:03 schrieb NorbertFe:

    https://support.microsoft.com/de-de/lifecycle/search/730

    Interessant, dass Exchange 2019 "nur" eine 8 Jahre Lifecycle zu besitzen scheint. 

    Tatsächlich erstaunlich:

     

    Exchange 2013: erweiterter Support bis 11.04.2023

     

    Exchange 2016: erweiterter Support bis 14.10.2025

     

    Exchange 2019: erweiterter Support bis 14.10.2025

     

    Lifecycle-technisch bringt das Upgrade von 2016 auf 2019 also nichts. Gegenüber 2013 gewinnt man weiterhin nur 2,5 Jahre. Ein Anreiz für einen Wechsel von 2013 sehe ich daher frühestens, wenn (voraussichtlich die nächste) Outlook-Version nicht mehr mit Exchange 2013 zusammenarbeitet.

  15. vor 2 Stunden schrieb magicpeter:

    Ein Rätsel .... :D

    Danke dir für die Listen....

    Würdest du denn den Defender auf einen HyperV oder DC einsetzen?

     

     

    Auf diese Frage könntest Du hier so viele Antworten kriegen, wie es Nutzer gibt. 

     

    Eine rationale Herangehensweise könnte sein: Eine neutrale Instanz, die AV-Programme bewertet, ist www.av-test.org. Der Windows Defender schneidet dort immer besser ab, mittlerweile ist er fast auf Augenhöhe mit den guten kommerziellen Programmen. 

     

    Windows Server 2016 hat allerdings noch nicht die Advanced Threat Protection des Defenders, das kommt erst mit Server 2019.

     

    Meine derzeitige Lösung: Auf Fileservern habe ich ein anderes Antiviren-Programm (meine Wahl fällt auf Bitdefender), Exchange ist dann wieder ein ganz eigenes Ding (hier nutze ich auch Bitdefender, habe aber auch noch einen vorgeschalteten Viren/Junk-Filter. Auf Servern wie dem HyperV oder dem DC halte ich den Windows Defender für ausreichend.

     

    Die derzeitigen Ankündigungen zu Windows Server 2019 verstehe ich so, dass man uU noch weitgehender auf den internen Defender setzen kann. 

     

    • Like 1
  16. Am 25.5.2018 um 11:34 schrieb Assassin:
     

    Servus...gibt es für Windows Server ein Programm was wie OneDrive agiert, nur dass eben die Daten nicht in eine Cloud Synchronisiert werden sollen, sondern auf dem Heimischen Server Synchronisiert werden sollen?

     

    Anforderungen sind eben wie bei OneDrive:

    - muss funktionieren ohne dass man vorher einen VPN Tunnel aufbauen muss

    - Soll automatisch erkennen ob es eine aktive Internetverbindung gibt - wenn es eine gibt soll es im Hintergrund die gewählten Daten mit den Daten auf dem Server abgleichen.

    - Es sollte auch für Android oder IPhone Handys auf die Daten zugegriffen werden können - da sollen die daten naürlich nicht mit aufs Handy Kopiert/Synchronisiert werden. Das soll nur bei den Windows-Notebooks der fall sein.

     

     

    Aber gibt es soetwas? Ich habe das bisher meist mit robocopy /mir skripten gelöst, aber ich denke mal das ist nicht mehr so ganz zeitgemäß...

     

    Das in Windows Server (ab Version 2012R2) enthaltene WorkFolders dürfte Deine Ansprüche ziemlich genau erfüllen. 

     

  17. vor 2 Stunden schrieb NilsK:

    Moin,

     

    eine CA ist kein Mysterium. Die Frage, ob man sie noch braucht, kann man mit einem Blick auf die ausgestellten Zertifikate beantworten. Sind welche darunter ,die noch benötigt werden und die man nicht mit geringem Aufwand durch andere austauschen kann (selbstsigniert, Let's Encyrpt, neue CA ...)? Dann wären das Gründe, die CA weiter zu betreiben bzw. auf einen neuen Server zu migrieren.

     

    Sind hingegen alle Zertifikate ersetzbar, dann sollte man das tun und die CA dann außer Betrieb nehmen. Dabei ist die Reihenfolge wichtig: Erst die Zertifikate ersetzen (sofern es denn noch welche gibt, die von der CA ausgestellt wurden und gültig sind) und dann die CA abschalten. Sonst könnten Clients u.U. die Sperrliste nicht abfragen und die alten Zertifikate würden nicht mehr funktionieren.

     

    Gruß, Nils

     

    Vielen Dank für Eure sehr hilfreichen Antworten. Das Bestehen der CA lässt sich eigentlich nur "historisch" erklären. Sowohl SBS als auch Essentials-Server installieren diese Rolle ja einfach ungefragt mit. Als ich noch keine gekauften Zertifikate hatte, brauchte ich die CA auch für Exchange und RDP. 

     

    Nach "Umzug" der CA vom Essentials-Server auf den neuen DC findet sich unter "Ausgestellte Zertifikate" nur noch ein einziges Zertifikat, das für den DC selbst ausgestellt wurde (Screenshot siehe Anlage). Für mich spricht jetzt eigentlich alles dafür, dass ich keine eigene Zertifizierungsstelle mehr benötige. 

     

     

     ca.thumb.PNG.65cd3334d15df9b06a8810e737110ad2.PNG

     

×
×
  • Neu erstellen...