Nintox 0 Geschrieben 23. Mai 2016 Melden Teilen Geschrieben 23. Mai 2016 (bearbeitet) Hallo zusammen, für ein Deployment-Prozess soll ein sicherer Zugriff auf ein Netzlaufwerk stattfinden. Der Prozess soll sich mit dem gesicherten Netzlaufwerk verbinden und bestimmte Daten davon auf den Host herunterladen. Ein einfacher net use Zugriff im Powershell Script ist mir zu unsicher. Was schlagt ihr vor, bzw. bevorzugt ihr? Danke für eure Tipps. Gruß Nintox bearbeitet 23. Mai 2016 von Nintox Zitieren Link zu diesem Kommentar
blub 115 Geschrieben 23. Mai 2016 Melden Teilen Geschrieben 23. Mai 2016 "net use" ist weder sicher noch unsicher. Welches Protokoll hast du? SMB1.0/ 2.0/ 3.0/3.1 . Wenn du das weisst, kann man dir etwas zur Sicherheit sagen. get-smbconnection liefert die Antwort smb1.0 ist vollkommen unsicher smb2.0 bietet Signatur smb3.0 bietet Signatur und Verschlüsselung smb3.1 ist glaub ich nur noch effizienter generell_1: IPSec (Kerberos oder Zertifikatsbasiert) würde deine Netzwerksicherheit deutlich erhöhen. generell_2: see: https://technet.microsoft.com/en-us/library/jj635700%28v=wps.630%29.aspx blub Zitieren Link zu diesem Kommentar
testperson 1.677 Geschrieben 23. Mai 2016 Melden Teilen Geschrieben 23. Mai 2016 Hi, läuft das PowerShell Script im Deployment Prozess vor oder nach der Benutzeranmeldung? Und was soll genau deplyoed werden? Gruß Jan Zitieren Link zu diesem Kommentar
PowerShellAdmin 169 Geschrieben 23. Mai 2016 Melden Teilen Geschrieben 23. Mai 2016 für ein Deployment-Prozess soll ein sicherer Zugriff auf ein Netzlaufwerk stattfinden. sicher Du meinst wie die Logindaten hinterlegt werden? Falls ja - wieso erhält der Benutzer nicht einfach zugriff auf die Ressource und man löst es über die integrierte Authentifzierung - unabhängig davon, dass man den Login z.B. verschlüsseln kann. Zitieren Link zu diesem Kommentar
blub 115 Geschrieben 23. Mai 2016 Melden Teilen Geschrieben 23. Mai 2016 Mir ist noch was dazu eingefallen: Per GPO könntest du UNC - Verbindungen weiter härten: Administrative Templates -> Network -> Network Provider -> Hardened UNC Paths Auch Platzhalter werden, soweit ich weiß, akzeptiert: \\ServerName\* \\*\Software1 weitere Infos findest du hier bzw. in der Erklärung in der GPO: KB3004375 KB3000483 https://technet.microsoft.com/en-us/library/jj635700%28v=wps.630%29.aspx Zitieren Link zu diesem Kommentar
daabm 1.354 Geschrieben 25. Mai 2016 Melden Teilen Geschrieben 25. Mai 2016 blub, bei W10 1511 klappt das derzeit net - und Sysvol so abzusichern kann ein Schuß ins Knie werden :) Zitieren Link zu diesem Kommentar
blub 115 Geschrieben 25. Mai 2016 Melden Teilen Geschrieben 25. Mai 2016 Zugegeben, produktiv habe ich UNC Hardening nicht im Einsatz. We recommend that all NETLOGON and SYSVOL shares be configured to require both mutual authentication and integrity in order to help secure Group Policy against spoofing and tampering attacks that can be leveraged to achieve remote code execution. see: https://support.microsoft.com/en-us/kb/3000483 Wenn es Microsoft schon ausdrücklich empfiehlt, dann habe ich kein schlechtes Gewissen, das hier auch so zu posten. Selbstverfreilich muss man sowas sorgfältig testen. Wenn du andere Quellen hast, die davon abraten, interessieren mich diese sehr! Zitieren Link zu diesem Kommentar
daabm 1.354 Geschrieben 29. Mai 2016 Melden Teilen Geschrieben 29. Mai 2016 Nee "abraten" trifft es net ganz... Wir haben ca. 700 Forests, und auf den WAN-Verbindungen sitzen Steelheads. Einer zentral für alle, 700 dezentral. Der zentrale hat das Problem, dass Kerberos net funktioniert, da der 700 Delegation User bräuchte - das braucht wohl dann zu viel Memory. Und wenn Kerberos net funktioniert, ist nach dem Sysvol-Hardening kein Sysvol-Zugriff mehr möglich. Inzwischen hat Riverbed ein neues rios rausgebracht, das so ne Art "RODC" simuliert, damit geht's dann. (Soweit ich das erklären kann - bin nicht der Netzwerk-Spezi, sondern nur AD :) ) Ist also eher ein "persönliches Problem" :) Zitieren Link zu diesem Kommentar
blub 115 Geschrieben 29. Mai 2016 Melden Teilen Geschrieben 29. Mai 2016 Das wäre natürlich schlecht. Eine kritische Schwachstelle, die seit Feb. 2015 bekannt ist, sollte aber trotzdem alsbald geschlossen werden. Besonders bei dieser Größenordnung! https://support.microsoft.com/en-us/kb/3000483 A remote code execution vulnerability exists in how Group Policy receives and applies connection data when a domain-joined system connects to a domain controller. An attacker who successfully exploited this vulnerability could take complete control of an affected system. blub Zitieren Link zu diesem Kommentar
lefg 276 Geschrieben 29. Mai 2016 Melden Teilen Geschrieben 29. Mai 2016 (bearbeitet) für ein Deployment-Prozess soll ein sicherer Zugriff auf ein Netzlaufwerk stattfinden. Wirklich auf ein Netzlaufwerk? Oder ist eine Freigabe gemeint? Der Prozess soll sich mit dem gesicherten Netzlaufwerk verbinden Was soll denn ein gesichertes Netzlaufwerk sein? bearbeitet 29. Mai 2016 von lefg Zitieren Link zu diesem Kommentar
NorbertFe 2.034 Geschrieben 29. Mai 2016 Melden Teilen Geschrieben 29. Mai 2016 Ist also eher ein "persönliches Problem" :) Würd ich aber auch so sehen. ;) Bye Norbert Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.