Eure vorgenommene Sicherheitskonfiguration SRP und Co
#1 _d4rkn3ss4ev3r_
geschrieben 29. Dezember 2018 - 19:35
Nutzt eventuell sogar einer die "Security baseline" aus dem "Microsoft Security Compliance Toolkit"? (https://blogs.techne...ws-server-2019/)
Anzeige
#2
geschrieben 29. Dezember 2018 - 20:31
#3 _d4rkn3ss4ev3r_
geschrieben 29. Dezember 2018 - 20:45
#4
geschrieben 29. Dezember 2018 - 21:24
Ich hab zum Bleistift eine GPO für die Verteilung von Zertifikaten:
Die schreibt:
- Mein eigenes CA-Zertifikat in die Vertrauenswürdigen CA des Computerkontos
- Die veröffentlichten Let's Encrypt-Zertifikate sowie deren signierende Authorities in den nicht-vertrauenswürdigen Speicher des Computerkontos
Dann gibt's da noch eine Enterprise CA, die mir auf Abruf für den Client die für ihn relevanten Zertifikate erstellt und zuweist.
Damit hab ich mit einem Handgriff die Möglichkeit, mein eigenes Vertrauen über GPO und CA auf die Domain abzubilden, nämlich erstmal pauschal: vertraue meinem eigenen Krams, überlasse LE-Zertifikate individueller Kontrolle (via SSL-Proxy) und akzeptiere den Rest bis auf weiteres.
Das ist natürlich nur ein minimales Fleckerl. Ich hab WSUS konfiguriert, um eíne halbe Hand auf Updates zu haben; ich hab ein Paket für den IE geschnürt, um den in einem halbwegs akzeptablen Maß standardisiert auf allen Clients mehr oder weniger identisch "sicher" zu haben und ich hab ein paar Pakete per Windows' Softwareverteilung zugewiesen, um eine Baseline und damit eine gewisse Grundannahme erfüllen zu können. So hat jeder Client spätestens nach der Anmeldung ein aktuelles Keepass drauf.
Aber, unmöglich, eine allgemeingültige Konfiguration zu empfehlen, geschweige denn zu posten. Das geht ja schon bei der Firewall los. Eine gute FW ist händisch konfiguriert (und dann ggf. per GPO ausgerollt) und mehr oder weniger exakt auf die Umgebung angepaßt: Auf den Clients läuft kein Webserver und wenn, soll es da keinen Zugriff geben? Firewall-GPO für Client(s) und dann Ports 80/tcp und/oder 443/tcp eingehend ZU. DNS-Spoofing vorbeugen? Port 53/tcp und 53/udp generell ZU, außer auf dem Domaincontroller, der muß natürlich DNS-Anfragen beantworten. Sonst aber niemand. Und der DC selber bekommt zwecks Assertion die Richtlinie, im Sinne von DNS außer auf sich selbst nur(!) auf den/die designierten Forwarder zuzugreifen.
Und so weiter und so weiter und so weiter.
Klar, eine Baseline ist immer eine gute Idee, aber ohne da jetzt extensiv reingeschaut zu haben in die Doku von Microsoft würd ich mal behaupten wollen, daß man das buchstäblich NUR in einer Testumgebung so einrichten kann, dann feststellen wird: scheiße, geht alles nicht mehr so wie soll, und dann mühsam einzelne Optionen raussuchen und die Änderung(en) wieder rückgängig machen oder abschwächen.
Mehr aber nicht.
Und für den Otto Normalo ist es sowieso uninteressant. Der kann mit GPO nichts anfangen und schießt sich schlimmstenfalls sein System genauso erfolgreich kaputt wie mit TuneUp.
#5 _d4rkn3ss4ev3r_
geschrieben 29. Dezember 2018 - 22:12
Ich wollte einfach wissen wer was für Einstellungen betreibt, um die eigenen zu erweitern.
#6
geschrieben 29. Dezember 2018 - 22:41
#7
geschrieben 30. Dezember 2018 - 00:30
Naja, oder entsprechend die DHCP-Konfiguration zu ändern. Falls das Fritzboxen überhaupt zulassen.
PS. "Absichern" ist kein Konzept. Das wäre dasselbe wie "Haus bauen ist mein Konzept" und das dann dem Architekten vorzulegen.
Dieser Beitrag wurde von RalphS bearbeitet: 30. Dezember 2018 - 00:31
#8 _d4rkn3ss4ev3r_
geschrieben 02. Januar 2019 - 14:44
Welche SRP / SAFER Richtlinien benutzt ihr?
#9
geschrieben 04. Januar 2019 - 01:55
Und natürlich mit einem halben Auge die Empfehlungen mit der eigenen Konfiguration abgleichen, wenn es bereits eine gibt. Immerhin ändert sich ja auch ab und zu was und niemand ist immer 100% überall hinterher - dafür reicht die Zeit ja gar nicht -- und vielleicht hat man ja wirklich nicht mitgekriegt, daß SHA1 nicht mehr sicher ist (als Beispiel).
Anderseits finden sich in den Guidelines von Microsoft auch solche schicken Einträge:
Regel Client Member DC ======================================================================== Password Policy Enforce password history 24 24 24 Password Policy Maximum password age 60 60 60 Password Policy Minimum password age 1 1 1 Password Policy Minimum password length 14 14 14 Password must meet complexity requirements Enabled Enabled Enabled
Wenn man das so konfiguriert wie von Microsoft empfohlen, dann hat das zum praktischen Ergebnis,
daß Benutzer binnen zweier Monate ein neues Paßwort vergeben müssen, welches mindestens 14 Zeichen lang ist, ausreichend komplex ist und sich von den 24 bisher verwendeten Paßwörtern unterscheidet (gemäß Richtlinie ein Zeitfenster von ca. 4 Wochen (absolutes Minimum) bis etwa 4 Jahre (absolutes Maximum) gemäß min und max password age.
Der Anwender muß sich also spätestens zum nächsten Paßwortwechsel die letzten 24 verwendeten Paßwörter ins Gedächtnis holen, die alle mindestens 14 Zeichen lang sind und alle "ausreichend" komplex sind, und das über einen zu erwartenden Zeitraum von zwei Jahren, wobei natürlich spätestens jeden zweiten Monat eines der 24 Paßwörter (das älteste) aus der Liste rausfällt.
Merkt sich das einer? Ich jedenfalls nicht. Das kann man sich nur noch irgendwo festhalten....
... und Paßwörter aufschreiben ist per definitionem unsicher. Dann kann man's auch gleich sein lassen. Schlimmer: Kein Anwender wird sich ernsthaft jeden zweiten Monat ein Paßwort *ausdenken*, welches allen gestellten Anforderungen genügt UND sich von 24 anderen gleich komplexen Paßwörtern *unterscheidet*.
Nope, da wird einfach hochgezählt. Das ist noch viel unsicherer, vor allem, wenn wirklich das Paßwort aufgeschrieben wird -- der "Zettelfinder" sieht dann sofort, wie er Paßwörter ausprobieren muß.
So wird die angepeilte Sicherheit zur Farce.
Deshalb: Ja, die Richtlinien sind sicher als Baseline geeignet, damit man mal sieht, was möglich ist (nicht jeder hat alle konfigurierbaren und relevanten Richtlinien im Kopf) und was Microsoft meint, wie man das konfigurieren könnte, um seine Umgebung sicher(er) zu kriegen.
Aber blindlings importieren und einfach so verwenden ist nicht, vor allem dann nicht, wenn man gar nicht weiß, was die konfigurierten Richtlinien tatsächlich machen.
Und da sind wir wieder beim Ursprungsproblem: keine Sicherheit ohne Konzept.
#10 _d4rkn3ss4ev3r_
geschrieben 04. Januar 2019 - 10:24
Dann reden wir halt nur noch über SRP / SAFER.
Du redest aber weiterhin über gpedit Policys.
Naja, scheinbar will hier keiner wirklich mit machen.
Schade
#11
geschrieben 04. Januar 2019 - 11:33
Zitat (d4rkn3ss4ev3r: 04. Januar 2019 - 10:24)
Dann reden wir halt nur noch über SRP / SAFER.
Kein tägliches Thema, deshalb musste ich mich in "SRP" - "Software Restriction Policies" und "SAFER" - naja, wohl einfach nur 'Safer' SRPs einlesen. (über http://schneegans.de/computer/safer/)
Das ist ein sehr interessantes Thema, und die Lösungen dort gut nachvollziehbar, privat z.B. auch gegen Ransomware (Für DAUs im wesentlichen ) - habe ich aber bisher zwar Kenntnis von gehabt, das da einiges geht, aber bisher nicht angewandt, weil für mich bisher nicht nötig.
In einer Firmenumgebung mit höheren Sicherheitsanforderungen kann ich mir den EInsatz aber sehr gut vorstellen, wobei es da wohl in erster Linie drauf ankommt, das die User nichts einschleppen können, z.-B. per Mailanhang oder USB-Stick.
Sicher sollten sich einige (Krankenhäuser ) mit dem Thema intensiv beschäftigen.
Ich werde den Thread weiter verfolgen.
Viel Erfolg.
Dieser Beitrag wurde von MirkoKR bearbeitet: 04. Januar 2019 - 11:34
#12
geschrieben 04. Januar 2019 - 17:46
Wenn ich jetzt Software Restriction Policies konfiguriere -- die übrigens ebenfalls Teil der GPO sind! --- dann muß ich auch wissen, was das tut und was ich damit erreichen kann und was nicht.
Und ich brauch ein Konzept. SRP ist kein Konzept, sondern es ist eine Möglichkeit, ein Konzept zu implementieren.
Und wenn ich jetzt sage, Anwendung C:/Program Files/anwendung.exe darf nicht ausgeführt werden, dann verschiebt der Benutzer das oder benennt es um und dann kann ers doch wieder ausführen => also muß ich dafür sorgen, daß das nicht geht.
Oder ich nehm den Hash und sag dann, daß das nicht gehen soll, aber dafür hab ich dann die Rennerei, weil in der heutigen Zeit alle paar Momente ein Update reinkommt und dann greift der Hash natürlich nicht mehr; ergo kann ich mit den Dingern nur sagen, daß eine ganz konkrete Anwendung in einer ganz konkreten Version nicht ausführbar sein soll (sagen wir wegen bekannter Sicherheitslücken) aber mehr geht nicht.
Richtig viel geht mit Zertifikaten abzufackeln, aber dann hab ich zu tun mit der Verwaltung derselben und sollte mich auch gleich noch drum kümmern, daß alle notwendigen Anwendungen *von mir* signiert werden, damit ich das dann freigeben kann. Aber Zertifikate sind nochmal ein ganz anderer Maloch, den ich mir da in dem Zusammenhang ins Haus hole, und abgesehen davon warnt sogar Microsoft davor, daß das Auswirkungen auf die Performance hat.
Natürlich kann man das auch ganz anders angehen und kann gucken, ob es nicht vielleicht doch besser ist, einfach über Dateisystemberechtigungen zu gehen. Immerhin gibt es insbesondere Privat kaum Gründe für Dinge, auf die man "normal" Zugriff haben *würde* und aber nicht haben *sollte*. Im selben Kontext fällt zB auch Dynamic Access unter den Tisch: Was nützt es mir, wenn ich damit Zugriffe dynamisch beschränken kann, wenn ich gar keine passenden Kriterien dafür habe außer "Benutzer B"? Da hätte ich auch eine simple ACL schreiben können, wo dasselbe drinsteht.
Die eigene Kiste genügt völlig mit NICHT-Adminrechten, und damit meine ich auch nicht "den Firefox 'als Administrator' ausführen", sondern tatsächlich ein Benutzerkonto zu haben, welches Mitglied der Benutzer, aber NICHT der Administratoren ist.
Seit Vista, also seit etwa 2006, ist es unter Windows ohnehin nicht mehr zulässig, ins Programmverzeichnis zu schreiben und entsprechend schreiben Anwendungen nach %APPLICATIONDATA%. Das heißt entsprechend, daß keine Anwendung Schreibrechte auf das eigene Installationsverzeichnis benötigt, wo dann weitergehend auch andere rumschreiben könnten.
Entsprechend installier ich mir den Firefox im Kontext eines Admins A und führe ihn im Kontext eines Benutzers B aus.
Und schon sind die SRP für diesen Anwendungsfall uninteressant geworden, denn die Integrität, die damit sichergestellt werden soll, wird bereits dadurch gewährleistet, daß meine firefox.exe eh nicht umgeschrieben werden kann mangels Schreibrechten im Dateisystem.
Ein bißchen anders sieht es nochmal aus, wenn Dinge im Benutzerprofil installiert werden. Da hat man immer Schreibrechte - kann man auch nicht verbieten. Das bleibt als Anwendungsfall für SRP bestehen. Da muß ich mich dann fragen, was ich denn in solchen Situationen erreichen will.
Nur wird das erst interessant, wenn es mehr als nur den einen Benutzer gibt, damit ich ein gemeinsames Auge auf alle behalten kann. Ich kann nicht einfach sagen, unter \Users\* darf pauschal nichts ausgeführt werden - damit schieße ich übers Ziel hinaus. Gleichzeitig sind aber Blacklists an dieser Stelle eher nutzlos, weil ja nur das unterdrückt wird, was ich selber gesagt hab, daß das unterdrückt werden soll. Also hab ich irgendwann ewig lange Sperrlisten und das 1000-und-erste Zeuch geht aber trotzdem durch, weil ich es nicht kannte.
Und damit sind wir schon wieder beim Konzept. Zuallererstmal muß ich wissen, was ich überhaupt erreichen will. Dann werden sich notwendigerweise für jedes einzelne Teilproblem, was sich ergibt, mindestens zwei passable Teillösungen finden lassen, von denen die eine manchmal besser ist und manchmal die andere. Da kann ich nicht einfach sagen: X und fertig.
Und wenn man DANN hergehen würde und sagen würde, okay da gibt es eine fertige Liste, dann passiert damit alles, nur nicht das, was ich nachvollziehen könnte.
Nur so als ganz blödes Beispiel für SRP:
- Erlaube alles was mit Microsoft-Zertifikaten signiert wurde
- Blocke den Rest
und ich garantiere, daß noch nicht mal ein frisch aufgesetztes Windows danach noch richtig funktioniert.
#13 _d4rkn3ss4ev3r_
geschrieben 05. Januar 2019 - 00:13
Ich nannte SRP weil es für Heimanwender das mit wirkungsvollste ist. Und hier ein Beispiel: http://www.mechbgon.com/srp/
Das es Whitelist, Blacklist, Hash- und Zertifikatsregeln gibt weiß ich. Ich selbst nutze Whitelist + einige Hashregeln. Somit ist auch kein Schadcode aus dem eigenen Benutzerprofil möglich, was du erwähnt hast.
Seit Windows 7 Eingewöhnung nutze ich kein eingeschränktes Benutzerkonto mehr. Dafür gibt es die UAC (maximalste Stufe).
Dein Beispiel mit Firefox ist völlig richtig.
Mein Gedanke in diesem Thread war keine Konzeptumfrage sondern einfache Konfigurationen wie abschalten von Netbios usw.
Scheinbar kam es falsch rüber oder ist nicht möglich. Oder eventuell macht das heutzutage auch einfach kein privater User mehr?
#14
geschrieben 06. Januar 2019 - 17:23
Ein Zitat von meiner verlinkten Seite:
Zitat