Jump to content

wznutzer

Members
  • Gesamte Inhalte

    497
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von wznutzer

  1. Ja, scheint so. Die Informationen von MS sind komplett durcheinander. Im deutschen KB-Artikel steht das Problem unter "Verbesserungen" und im englischen unter "known issues". Gleichzeitig steht im KB-Artikel vom Juli (seit da gibt es das Problem) dass es mit dem September-Patch behoben ist. Prima Informationsfluss .
  2. Hallo und guten Tag, seit dem Patchday 07/2024 gibt es ein von Microsoft bestätigtes Problem mit dem RDP-Gateway. Wenn RPC over HTTP verwendet wird crasht der Dienst sporadisch mehrfach am Tag. Lt. den Releasenotes von Microsoft sollte das Problem mit dem September-Patch behoben sein, ist es aber nicht. Hat da evtl. jemand nähere Informationen oder kann bestätigen, dass das Problem noch vorhanden ist? https://support.microsoft.com/en-us/topic/september-10-2024-kb5042881-os-build-20348-2700-5b548143-9613-4e5a-9454-8ed9be8b2bd2 (Improvements) Was ist der schnellste Weg an Informationen von Microsoft zu kommen? Eine Anfrage über https://support.serviceshub.microsoft.com/supportforbusiness? Vielen Dank
  3. Wie seht Ihr die Vertrauenswürdigkeit? Bei OPSI oder ähnlichen Systemen sorge ich selber dafür. Aber bei WinGet, Chocolatey usw. habe ich ja vor der Installation nicht die Chance Herkunft, Signatur, Hash oder ähnliches zu prüfen. Man vertraut einfach dem Repository. Während beim MS, Apple oder Google noch jemand die Hand drauf hat, ist das bei den genannten nicht so. Oder ist das ein Hängen an alten Zöpfen?
  4. Damit hat es nichts zu tun. Einzig die Option (bzw. ich kenne keine andere) media.peerconnection.enabled auf false zu setzen, hält Firefox davon ab. Naja, ein richtiges Problem scheint es nicht zu sein, aber wenigstens etwas gelernt.
  5. Das werde ich versuchen und berichten...
  6. Guten Tag zusammen, vor kurzem ist mir aufgefallen, dass Firefox beim Besuch von Webseiten (auch seriöse) eine Firewall-Regel für eingehende Verbindungen anlegen will. Standardmäßig macht das die Installation für den Bereich"privat". Wenn man nun aber im Profil "öffentlich" oder "Domäne" surft, will Firefox je nach Webseite das auch für dieses Profil anlegen. Ich bin mir sicher, dass es keine Malware/Plugin oder ähnliches ist, weil sich das Verhalten auch auf frischen AWS-VMs nachvollziehen lässt. Im konkreten Fall ging es um die Webseite von MediaMarkt. Die Abfrage kommt auch schon bevor man den Cookie-Banner bestätigt hat. Ich glaube es liegt an WebRTC, jedenfalls kann man mit about:webrtc ein Protokoll aktivieren und anzeigen und da werden dann Verbindungen protokolliert. 1) Hat das auch schon mal jemand beobachtet? Ich bin mir nicht sicher, ob sich dadurch eine Aufgabenstellung für Unternehmensnetzwerke ergibt, standardmäßig haben die User gar keine Berechtigung solche Regeln anzulegen. Alternativ könnte man das auch pauschal deaktivieren. Im Firefox z. B. mit media.peerconnection.enabled=false 2) Ich weiß gar nicht, ob ich will, dass solche Verbindungen zustande kommen. Mithilfe von STUN- oder TURN-Server geht das ja auch an den Firewalls vorbei. Grüße und einen schönen Tag
  7. Falls Deine Umgebung nicht so riesig ist, spiele das doch einfach in einer Kopie, z. B. in einem VLAN durch. Du kannst auch das Blech in eine VM packen. Nur aufpassen, dass die Kopien nicht versehentlich in das Originalnetz sprechen. Ich habe nicht nur ein Lab das ähnlich ist, sondern exakt identisch, weil ich hin und wieder das Original kopiere bzw. vom Backup wiederherstelle. Führt nebenbei zu Routine im Wiederherstellungsprozess, prüft Deine Backups und lässt Dich Tag X entspannter entgegensehen.
  8. Das ist, finde ich, eine schöne Zusammenfassung wie so ein Prozess ablaufen kann .
  9. Bei den eigenen Leuten ist das so und jetzt steht die große Welt mit BYOD vor der Tür. Leider ist das so .
  10. Leider noch eine bekannte Schwachstelle. Zur Klarstellung: Du meintest damit die Authentifizierung der zugreifenden Geräte?
  11. Ja, gut zusammengefasst . Darum geht es mir. Deswegen bekommen die BYOD-Leute einen Bereich der sich von den anderen unterscheidet. Der Gedanke was da an Trennung notwendig ist, musste reifen und die Diskussion hat dazu beigetragen. Der Begriff BYOD ist mir nur nicht eingefallen, weil es so gesehen gar nicht um intern/extern geht. Interne BYOD-Leute würde ich auch so sehen.
  12. Ich glaube, wir ticken hier einfach anders. Für mich spielt es eine Rolle wie wahrscheinlich es ist, dass Zugangsdaten abgegriffen werden können. Im einen Fall wird bereits auf den zugreifenden Geräten versucht das Abgreifen von Zugangsdaten zu verhindern. Im zweiten Fall gibt es diese Hürde nicht und ich rechne mit einem höheren Risiko von kompromittierten Zugangsdaten.
  13. Windows-Forms-Anwendung (*.exe, *.dll). Grundsätzlich würde das gehen, z. B. VPN mit MFA und dann die Anwendung auf MS SQL und ein paar Verzeichnisse. Habe ich schon getestet. Die Performance ist allerdings schlecht und die Anwedung kommt nicht mit Verbindungsabbrüchen zurecht (z. B. Mobilfunk im Zug). Der RDS HTML5 Client kommt ziemlich gut mit Verbindungsabbrüchen zurecht. Ich mache das so: separater RDS im eigenen Netzwerksegment RDS mit Applocker, kein Internet, Verhaltensüberwachung usw. RDS darf nur mit DB und AD sprechen AD mal mit Purple Knight oder Forest Druid, PingCastle checken (win-win sozusagen) HTML5-Client hinter Azure App-Proxy. Das streichelt etwas die Paranoia, weil die MFA des RDS-Gateway "nur" eine Nachricht zur Bestätigung ist und nicht wie der MS-Login mit einer individuellen Zahl . Grüße an alle
  14. Ich sehe das nur als technisches Problem. Externe Vertriebler, Marketingleute arbeiten täglich mehrere Stunden im ERP. Die Aufgabe ist nun: Stelle einen Bereich für das ERP zur Verfügung in dem möglichst nichts passieren kann, auch wenn die Zugangsdaten in die Hände einer Ransomware-Group fallen. Die externen Vertriebler sind anständige Leute und machen nichts böses, die sind nur vielleicht mal unachtsam. Warum der Unterschied zu eigenen Leuten? Eigene Leute arbeiten auf zugenagelten und überwachten Geräten. Die Externen arbeiten auf irgendwas, weil die das wollen und sonst nicht für uns arbeiten. Und wir alle wissen, dass die Geschwister "Ich habe doch nur..." und "Ich wollte nur kurz..." der Anfang vom Übel sein können. Vielen Dank nochmals für die Tipps und die rege Teilnahme
  15. Kleines Missverständnis, alles gut . Ja, genau Ich denke über so Sachen nach, dass z. B. über die ERP-Anwendung ein FileDialog geöffnet werden kann und darin dann ein fast vollwertiger Explorer zur Verfügung steht, was irgendwie dann auch Zugriff auf die Umgebung ist. Ich weiß ja nicht, was die bösen Buben alles können, aber einige von denen können wohl viel.
  16. Ob mir das hilft muss ich noch überlegen. Die ERP-Software hat keine Webschnittstelle (Windows-Forms-Anwendung). Die Webschnittstelle wäre der HTML5-Client der auf einem RDS-Gateway installiert werden kann, aber auch der macht ja dann "nur" RDP in "mein" Netz. Der HTML5-Client wäre in diesem Fall nur ein Gimmick. Sicherheitstechnisch bringt mir das nur was, wenn ich den Zugang hinter einen Azure-App-Proxy packe. Dann gibt es einen regulären Microsoft-Login mit ein einzutippenden Zahl, während die RDS-MFA "nur" eine Pushnachricht ist.
  17. evtl. Denkfehler meinerseits? Ich dachte so an: "Hilfe, ich komme nicht mehr an meine Daten!" Und dann gibt es Support um wieder an die Daten zu kommen. Aber Du hast Recht. Dell würde ja auch nur dafür sorgen, dass die Kiste bei einem Hardwaredefekt wieder läuft und den Rest muss ich selber machen. Muss ich mir nochmals überlegen.
  18. Guten Tag, ich hoffe ich habe das richtige Forum erwischt. Man sagt ja, dass die Frage nicht "ob" sondern "wann" lautet, bis es einem mit Ransomware erwischt. Diese Sache mit einem Immutable Storage würde mir sehr gut gefallen. Mit Veeam ist das auch schick nutzbar. Es gibt von Veeam auch prima Anleitungen wie das ohne viel Geld mit einem Linux-Blech umgesetzt werden kann. Die haben das sogar in einem Installationsscript zusammengefasst. Funktioniert prima, alles gut. Da es mich aber vor dem schlimmsten aller Unfälle bewahren soll, wäre eine Lösung mit Support schön. Qnap mit Veeam soll lt. den Veeam-Foren eher schlecht als recht funktionieren. Ich finde leider keinen Anbieter (On-prem) bei dem es nicht schnell sechsstellig (Dell ECS) wird. Scheint eine Enterprise-Sache zu sein. Mein derzeitiges Immutable-Backup ist old school mit LTO7 und wechselnden HDDs im Tresor. Ist auch OK, aber halt nicht automatisch. Hat jemand zufällig eine Lösung in Betrieb die so 50 TB umfasst und < 20.000€ kostet? Grüße und noch einen schönen Tag.
  19. Guten Morgen, herzlichen Dank für den regen Austausch. Die kaufmännische Seite hat da Verträge, aber ein Vertrag ist für meine Bedenken nur dazu da um einen Schuldigen zu finden. Er verhindert ja nichts. Nein. Das wäre mein Traum . Nochmals Danke für die ausführliche Antwort. Vom Rest habe ich tatsächlich schon einiges umgesetzt (Tier-Konzept, MFA, Clients teilweise separiert usw.). Um zwei Dinge werde ich mich unabhängig davon kümmern. Evtl. mag mich jemand noch in die richtige Richtung schubsen. AD-Objekte per LDAP auslesen verhindern: Hätte mir da jemand einen Link über weitere Informationen? Druckspooler: Ist das (Printnightmare mal außen vor) ein generelles Sicherheitsproblem? Meine Eingangs erwähnte Variante, ein komplettes AD neu aufzubauen habe ich nach dieser Diskussion verworfen. Das halte ich dann doch für übertrieben. Ich werde wohl einen separaten RDS in einem eigenen VLAN dafür richten und den möglichst so zunageln, dass dieser zwar alles nötige nutzen kann, aber auch nicht mehr. Weiterer Aufwand ist dann wohl besser in Dinge investiert, die generell nicht nur für den Fall "extern" was bringen. Kennt hier jemand das Tool Purple Knight oder Forest Druid? Empfehlenswert für die AD-Sicherheit? Es wird in einem Blog erwähnt: https://www.semperis.com/de/category/ad-security-101/ Die Lizenzen sind safe. Die Leute machen unsere Arbeit. Das wollte ich jetzt nicht hören . Vielen Dank nochmals an alle.
  20. Vielen dank für den regen Austausch. Ich glaube, ich habe einen etwas anderen Bedarf. Bei mir geht es um Vertrieb und Marketing. Die arbeiten dauerhaft, geben Leads ein, erstellen Angebote, Aufträge, aber sind halt externe Agenturen / Fachhändler. Wenn ich das richtig verstehe, gibt es bei den vorgeschlagenen Vorgehensweisen keinen Schutz vor Böswilligkeit, es gibt einen Vertrauensvorschuss. Bisher lassen wir grundsätzlich keine Dritten ins Netz. Klappt ganz gut, außer Veeam besteht bei manchen Case auf eine Webex-Sitzung. Selbst das machen wir dann nur im Ansichtsmodus und hinterher wird die VM zurückgesetzt. Die Idee war möglichst eine Konfiguration zu haben, die im schlimmsten Fall kompromittiert ist und sich nicht auf den Rest auswirkt. Also es soll selbst dann sicher sein, wenn jemand absichtlich versucht etwas anzustellen. Das scheint eher unüblich zu sein. Auch die Dienstleister sagen, bei allen anderen gibt es einen Zugang wie für jeden regulären Mitarbeiter (VPN, RDP auf RDS fertig). Darf ich die Diskussion nochmals in eine Richtung lenken. Ich tendiere noch immer dazu den RDS in einem VLAN zu separieren. Um den SQL-Port mache ich mir weniger sorgen, aber ich brauche halt auch Ports zum AD: TCP 135 Microsoft RPC TCP/UDP 49152 – 65535 RPC Dynamic Ports TCP 88 Kerberos TCP 389 LDAP UDP 53 DNS TCP 445 SMB Gibt es da etwas besonderes zu beachten (aktuelle Systeme, komplexe und lange Passwörter)? Danke und ein schönes Restwochenende
  21. Es benötigt einen Client, eine ganz normale Windows-Forms Anwendung. Deswegen der RDS. Für das was getan werden muss, ist jedoch ein Browser ausreichend. Ich dachte, ich mache das über den HTML5-Client, gebe aber nicht den kompletten Desktop frei, sondern nur die Anwendung (Remote-App). Im Prinzip will ich mich vor dem Szenario schützen, dass im schlimmsten Fall der Anwender böswillig handelt oder seine Zugangsdaten unvorsichtig weitergibt. Auch dann soll möglichst nichts passieren können. Aber vielleicht übertreibe ich auch.
  22. Tatsächlich nur ERP (Vertrieb, Marketing) keine Dienstleister die irgendwas an der Infrastruktur mitarbeiten müssen.
  23. D. h. die Überlegung, dass ein evtl. kompromittierter RDS "nur" mit einem RODC und nicht mit den anderen RWDC kommunizieren darf ist praktisch wertlos? Würde der RODC kompromittiert, ist es dann nicht egal ob dieser physikalisch oder virtuell an einem "unsicheren Ort" steht?
  24. Eine weitere Erkenntnis: Es betrifft tatsächlich nur HDDs, also Magnetfestplatten. Wir machen das jetzt organisatorisch. Die User behalten das jetzt einfach im Blick und entsperren die HDD erneut.
  25. Habe ich irgendwie einen Knoten im Kopf, ob das reicht. Applocker, hoffentlich korrekt konfiguriert keine Ordner auf C:\ anlegen keine cmd.exe kein Internet eigenes VLAN und nur zulassen was für das AD, Virenscanner, den Remote-Zugriff und die ERP-Software nötig ist. Zugriff nur auf die ERP-Anwendung (Remote-App) Ich überlege, ob ich in das VLAN einen schreibgeschützten DC packen kann. Dann darf der RDS nur mit dem RODC kommunizieren. Bringt ein schreibgeschützter DC im separaten "extern VLAN" in solch einem Szenario einen Sicherheitsvorteil?
×
×
  • Neu erstellen...