WinFuture-Forum.de: Eure vorgenommene Sicherheitskonfiguration - WinFuture-Forum.de

Zum Inhalt wechseln

Windows 10: Alle News, der Download sowie zahlreiche Screenshots und Videos zum neuen Betriebssystem von Microsoft. Jetzt im WinFuture Windows 10 - Special informieren!
Seite 1 von 1

Eure vorgenommene Sicherheitskonfiguration SRP und Co


#1 Mitglied ist offline   d4rkn3ss4ev3r 

  • Gruppe: aktive Mitglieder
  • Beiträge: 4.321
  • Beigetreten: 03. Januar 09
  • Reputation: 588

  geschrieben 29. Dezember 2018 - 19:35

Mich würden gerne eure gesetzten Sicherheitsregeln wie SRP, Dienste, Policies, Registryeinträge, etc. interessieren.

Nutzt eventuell sogar einer die "Security baseline" aus dem "Microsoft Security Compliance Toolkit"? (https://blogs.techne...ws-server-2019/)
"Jene, die grundlegende Freiheit aufgeben würden, um eine geringe vorübergehende Sicherheit zu erwerben,
verdienen weder Freiheit noch Sicherheit." (Benjamin Franklin)


ACTA] | IPRED | SOPA | PIPA | CISPA | INDECT | TPP | TAFTA | Stop CETA + Stop TTIP + Stop TiSA
> Mein Hells Toolbox CMD Script <
0

Anzeige



#2 Mitglied ist offline   Holger_N 

  • Gruppe: aktive Mitglieder
  • Beiträge: 4.504
  • Beigetreten: 11. September 10
  • Reputation: 311

geschrieben 29. Dezember 2018 - 20:31

Ich habe für meinen Arbeitsrechner eine Regel in der Fritzbox.

Angehängtes Bild: Regel_Nr_1.png
Ich bin ein sehr ordentlicher, fleißiger und reinlicher Mensch, nur leider gefangen im Körper eines schmuddeligen Faulpelzes … tja, kann man nix machen …
0

#3 Mitglied ist offline   d4rkn3ss4ev3r 

  • Gruppe: aktive Mitglieder
  • Beiträge: 4.321
  • Beigetreten: 03. Januar 09
  • Reputation: 588

geschrieben 29. Dezember 2018 - 20:45

Beitrag anzeigenZitat (Holger_N: 29. Dezember 2018 - 20:31)

Ich habe für meinen Arbeitsrechner eine Regel in der Fritzbox.

Anhang Regel_Nr_1.png

Kann man natürlich so machen, nun aber bitte ernste Konfigurationen
"Jene, die grundlegende Freiheit aufgeben würden, um eine geringe vorübergehende Sicherheit zu erwerben,
verdienen weder Freiheit noch Sicherheit." (Benjamin Franklin)


ACTA] | IPRED | SOPA | PIPA | CISPA | INDECT | TPP | TAFTA | Stop CETA + Stop TTIP + Stop TiSA
> Mein Hells Toolbox CMD Script <
0

#4 Mitglied ist offline   RalphS 

  • Gruppe: VIP Mitglieder
  • Beiträge: 8.526
  • Beigetreten: 20. Juli 07
  • Reputation: 1.026

geschrieben 29. Dezember 2018 - 21:24

Und was versprichst Du Dir davon? Sicherheitskonfigurationen ohne Konzept sind wertlos und funktionieren in Mischung vermutlich auch nicht so, wie sie sollen.

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.
"If you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."-- Anne Isabella Thackeray Ritchie

Eingefügtes Bild
Eingefügtes Bild
0

#5 Mitglied ist offline   d4rkn3ss4ev3r 

  • Gruppe: aktive Mitglieder
  • Beiträge: 4.321
  • Beigetreten: 03. Januar 09
  • Reputation: 588

geschrieben 29. Dezember 2018 - 22:12

Nun das Konzept ist natürlich das absichern von Desktop Clients für Nicht-Firmen-PCs.

Ich wollte einfach wissen wer was für Einstellungen betreibt, um die eigenen zu erweitern.
"Jene, die grundlegende Freiheit aufgeben würden, um eine geringe vorübergehende Sicherheit zu erwerben,
verdienen weder Freiheit noch Sicherheit." (Benjamin Franklin)


ACTA] | IPRED | SOPA | PIPA | CISPA | INDECT | TPP | TAFTA | Stop CETA + Stop TTIP + Stop TiSA
> Mein Hells Toolbox CMD Script <
0

#6 Mitglied ist offline   IXS 

  • Gruppe: aktive Mitglieder
  • Beiträge: 2.024
  • Beigetreten: 04. Dezember 12
  • Reputation: 191

geschrieben 29. Dezember 2018 - 22:41

Beitrag anzeigenZitat (Holger_N: 29. Dezember 2018 - 20:31)

Ich habe für meinen Arbeitsrechner eine Regel in der Fritzbox.

Anhang Regel_Nr_1.png



Kann gut gehen, muss es aber nicht.
Wenn Windows 10 Internet riecht, geht es gelegentlich auch andere Wege.
0

#7 Mitglied ist offline   RalphS 

  • Gruppe: VIP Mitglieder
  • Beiträge: 8.526
  • Beigetreten: 20. Juli 07
  • Reputation: 1.026

geschrieben 30. Dezember 2018 - 00:30

Wenn es nur darum geht, "Internet" loszuwerden, reicht es, am Client den Gateway rauszunehmen.

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

"If you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."-- Anne Isabella Thackeray Ritchie

Eingefügtes Bild
Eingefügtes Bild
0

#8 Mitglied ist offline   d4rkn3ss4ev3r 

  • Gruppe: aktive Mitglieder
  • Beiträge: 4.321
  • Beigetreten: 03. Januar 09
  • Reputation: 588

geschrieben 02. Januar 2019 - 14:44

Dann eben anders:

Welche SRP / SAFER Richtlinien benutzt ihr?
"Jene, die grundlegende Freiheit aufgeben würden, um eine geringe vorübergehende Sicherheit zu erwerben,
verdienen weder Freiheit noch Sicherheit." (Benjamin Franklin)


ACTA] | IPRED | SOPA | PIPA | CISPA | INDECT | TPP | TAFTA | Stop CETA + Stop TTIP + Stop TiSA
> Mein Hells Toolbox CMD Script <
0

#9 Mitglied ist offline   RalphS 

  • Gruppe: VIP Mitglieder
  • Beiträge: 8.526
  • Beigetreten: 20. Juli 07
  • Reputation: 1.026

geschrieben 04. Januar 2019 - 01:55

Einfach pauschal übernommen? Keine. Man kann sich das auch nur angucken und sich fragen, ob und ggf. welche Richtlinien für einen in Frage kommen.

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.
"If you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."-- Anne Isabella Thackeray Ritchie

Eingefügtes Bild
Eingefügtes Bild
0

#10 Mitglied ist offline   d4rkn3ss4ev3r 

  • Gruppe: aktive Mitglieder
  • Beiträge: 4.321
  • Beigetreten: 03. Januar 09
  • Reputation: 588

geschrieben 04. Januar 2019 - 10:24

Ähm ich sagte doch:
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
"Jene, die grundlegende Freiheit aufgeben würden, um eine geringe vorübergehende Sicherheit zu erwerben,
verdienen weder Freiheit noch Sicherheit." (Benjamin Franklin)


ACTA] | IPRED | SOPA | PIPA | CISPA | INDECT | TPP | TAFTA | Stop CETA + Stop TTIP + Stop TiSA
> Mein Hells Toolbox CMD Script <
0

#11 Mitglied ist offline   MirkoKR 

  • Gruppe: Mitglieder
  • Beiträge: 11
  • Beigetreten: 19. Dezember 18
  • Reputation: 4

geschrieben 04. Januar 2019 - 11:33

Beitrag anzeigenZitat (d4rkn3ss4ev3r: 04. Januar 2019 - 10:24)

Ähm ich sagte doch:
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

0

#12 Mitglied ist offline   RalphS 

  • Gruppe: VIP Mitglieder
  • Beiträge: 8.526
  • Beigetreten: 20. Juli 07
  • Reputation: 1.026

geschrieben 04. Januar 2019 - 17:46

*seufz* Okay, ich versuch es noch einmal.

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.
"If you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."-- Anne Isabella Thackeray Ritchie

Eingefügtes Bild
Eingefügtes Bild
0

#13 Mitglied ist offline   d4rkn3ss4ev3r 

  • Gruppe: aktive Mitglieder
  • Beiträge: 4.321
  • Beigetreten: 03. Januar 09
  • Reputation: 588

geschrieben 05. Januar 2019 - 00:13

Das Konzept lautet einfach den privaten PC gegenüber Malware abzuschotten.

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?
"Jene, die grundlegende Freiheit aufgeben würden, um eine geringe vorübergehende Sicherheit zu erwerben,
verdienen weder Freiheit noch Sicherheit." (Benjamin Franklin)


ACTA] | IPRED | SOPA | PIPA | CISPA | INDECT | TPP | TAFTA | Stop CETA + Stop TTIP + Stop TiSA
> Mein Hells Toolbox CMD Script <
0

#14 Mitglied ist offline   MirkoKR 

  • Gruppe: Mitglieder
  • Beiträge: 11
  • Beigetreten: 19. Dezember 18
  • Reputation: 4

geschrieben 06. Januar 2019 - 17:23

Also ich sehe in der SAFER.inf schon ein Grundkonzept:

Ein Zitat von meiner verlinkten Seite:

Zitat

_SAFER.INF konfiguriert Windows so, daß Benutzer (also Nicht-Administratoren) Programme nur dort ausführen dürfen, wo sie keine Schreibrechte haben. Ein Benutzer kann somit ein Schadprogramm nicht zur Ausführung bringen, selbst wenn er wollte – wo er es ablegen kann, darf er es nicht ausführen, und wo er es ausführen dürfte, darf er es nicht ablegen.

0

Thema verteilen:


Seite 1 von 1

1 Besucher lesen dieses Thema
Mitglieder: 0, Gäste: 1, unsichtbare Mitglieder: 0