NorbertFe

Da ist was dran. Bitteschön: https://labs.mwrinfosecurity.com/blog/accessing-internal-fileshares-through-exchange-activesync/ Bye Norbert

Naja mehr als raten kann man da jetzt leider nicht. Gibts einen spf Record? Dkim/dmarc? Alles was deine Reputation verbessert wäre sinnvoll. Zusätzlich manchmal noch wichtig wo deine ip herkommt, wer sie vorher besaß. Usw. USF.

Oder das speichern dieser Dateien unterbinden.

Die gleichen wie auch 2013 und 2019.

Entweder Edge oder was anderes. Aber ab Exchange 2016 ist sowieso keine Trennung abseits des Edge Servers mehr möglich. Also ist deine Überlegung maximal für Exchange 2013 auch für die ClientAccess Rolle möglich und selbst dann wird dir niemand mehr dazu raten. Sprich: Deine Überlegungen gehen in die falsche Richtung und bringen _nicht_ mehr Sicherheit. Bye Norbert

Naja das würde ich maximal bezüglich der Anwendungen _mit_ MFA unterschreiben. Für alles andere ist die Gefahr ja trotzdem vorhanden. Bye Norbert

Aber nur bei UserCALs. ;) Aber was anderes macht man sowieso nicht.

Nochmal, wenn keinen physikalische Sicherheit gegeben ist (Zukleben der Anschlüsse oder evtl. Abschließen), gibts wenig Möglichkeiten, außer eine ständige Kontrolle. Wenn also kriminelle Energie unterstellt wird, muß man auch den Aufwand betreiben die physikalische Sicherheit auf dem Level zu halten.

Tja wie du siehst, kann man nicht "einfach mal machen" und dann ist sicher, sondern kommt zur berühmt berüchtigten "umfassenden Sicherheitsstrategie". Evtl. ja mal übers OSI Schichtenmodell nachdenken. ;) Layer 1 = Physik und Layer 7 = Applikation und zusätzlich noch Layer 8 = Nutzer. ;)

Und das kann ein Kunde im Normalfall? Oder kann er das erstmal auch nur behaupten?

Wieso als Dienst? Dazu müßte man normalerweise ja Rechte im System besitzen, die ein normaler Nutzer nicht haben darf. Sprich lokaler Admin sein. Keylogger gibts auch als USB Device und dagegen kannst du nur physikalisch vorgehen. Wenn der Attacker keinen Zugriff auf den Datenbestand des anderen Nutzers hat, was soll er dann kopieren? Wenn der Normale Nutzer natürlich sensitive Daten lokal auf dem PC an frei zugänglichen Bereichen speichert, hilft alles nicht. Wenns also schon am lokalen Adminrecht scheitern sollte, brauchst du über weitere Dinge nicht nachdenken. Physikalischer Zugang erfordert dann meiner Meinung nach auch zwingend Disk-Encryption, um eine Offline Boot Attacke zu verhindern usw. usf. bye Norbert

Du sollst die Mac Adresse auswerten nicht die IP. Und dazu ist die DHCP Reservierung wohl nicht notwendig. ;)

Hat Franz oben ja bereits geschrieben: Loginscript und die Zugreifende Mac Adresse auswerten.

Und am "Default" Das Backend siehst du als User ja nie. ;) Aber unabhängig davon solltest du die Finger vom IIS des Exchange lassen. So gut wie alles konfiguriert man per EAC oder EMS. Und am "Default" Das Backend siehst du als User ja nie. ;) Aber unabhängig davon solltest du die Finger vom IIS des Exchange lassen. So gut wie alles konfiguriert man per EAC oder EMS.

SQL Server hat afair in vl immer auch den key schon drin. Da einen Virus zu vermuten ist eher „abwegig“ :)

Naja und? Du mußt ja sowieso für den Exchange 2016 einen neuen Namen definieren und nimmst dafür ja hoffentlich nicht den Servernamen. ;) Also dann siehe oben.

Ganz bestimmt. Du machst das schon. :|

Bleibt trotzdem die Frage, warum man es abschaltet. :)

Warum konfiguriert man sowas? RDP ist seit Ewigkeiten unsicher, da sollte man ja nicht noch mehr Löcher aufreißen, indem man die NLA abschaltet.

[OT]Ich überlege immer mal wieder, welche Variante die bessere ist. :) So richtig hab ich noch keine zufriedenstellende Antwort gefunden.

Es geht, wenn du dauerhaft an diesem Thema dran bleibst bzw. bleiben kannst. Wenn du projektbezogen dazugeholt wirst und solche Ansichten beim Kunden nicht auf fruchtbaren Boden fallen hast du einfach verloren. Kannst du glauben oder nicht. :) Und ja ich kann bei Kunden zu bestimmten Dingen auch "nein" sagen, aber das kann ich auch nicht jedesmal und bei allem machen.

Ja, das kann man sagen, wenn man "Daueradmin" ist, als Dienstleister kann man zwar anraten es richtig zu machen, aber die Realität sieht leider sehr oft anders aus. :|

MACH sagt immer wieder lustige Dinge. ;) Zum Glück hab ich mit denen nix mehr zu tun.

Die Hoffnung auf Java-freie Netzwerke wächst. ;)

Schema f ist aber vielleicht keine gute Idee, wenn man das Prinzip nicht verstanden hat. Ich bin da eher bei Nils.