Internet Explorer - sichere und empfohlene Konfiguration

Autor: Mark Heitbrink - vom 13.10.2014 - Kategorie(n): Anleitungen

 

Internet Explorer sicher konfigurieren: 

Was ist sicher? Was muss konfiguriert werden? Wer definiert was sicher ist und wer hält am Ende den Kopf dafür hin?

Direkt am Anfang des Artikels ein Fazit:
Es macht keinen Sinn(!), den Internet Explorer mit Restriktionen bis oben hin zuzunageln um dann, weil man nicht mehr Arbeiten kann, den Firefox oder Chrome zu verwenden.

Das Schwert ist wie immer zweischneidig und die Sicherheit steht der Produktivität mal wieder im Wege. Die berühmten Buzzwords, die jetzt fallen, lauten: Risikobewertung, Risk Acceptance und viele andere aus der Kategorie ;-)

Als Basis einer sicheren Internet Explorer Konfiguration verwendet man zur Zeit den
Microsoft Security Compliance Manager
http://technet.microsoft.com/de-de/library/cc677002.aspx

Alternativ: Die Checkliste des BSI - Bundesamt für Sicherheit in der Informationstechnologie
Internet Explorer 10 - BSI - Bund.de
... noch nicht auf 11 aktualisiert

Vielleicht ist euer Unternehmen auch unter amerikanischer Flagge, dann wird CIS wohl eher eure Messlatte sein: Center for Internet Security
Zitat von Microsoft: [Aaron Margosis]  Our guidance for Windows 8 / Server 2012 / IE10 aligns with CIS' guidance, as we collaborated closely.  We also collaborated with CIS during the development of these new baselines.  Although I haven't yet seen what CIS is publishing for 8.1/2012R2/IE11, I've been told they are largely the same.

Bleiben wir beim Security Compliance Manager:
Der SCM stellt uns sogenannte Baselines zur Verfügung. Diese sind getrennt nach Operatingsystem, Einsatzweck, Benutzer und Computer, Office Versionen, Internet Explorer Versionen und Servertypen sortiert.
Der SCM wird regelmässig aktualisiert und liefert immer die aktuellen Vorschläge (Baselines) zur Konfiguration eines Produkts.


(klick-vergrößern)

Die Baselines von Microsoft sind schreibgeschützt, damit sie nicht geändert werden können. Möchte man sie im SCM bearbeiten, dann muss man zuerst eine Kopie (Duplicate) der Baseline erzeugen und danach exportieren. Oder man exportiert direkt eine Baseline als GPO Backup. Anschliessend importiert ihr dann die Kopie oder die Baseline in eine neue leere Gruppenrichtlinie in der GPMC.

Der SCM arbeitet komplett über die MMC 3.0 Funktionen, er ignoriert konsequent jede Aktion auf der rechten Maustaste. Alles was man machen möchte findet über das Aktions-Memü der MMC 3.0 am rechten Rand statt. Schön, daß der Entwickler verstanden hat, wie Microsoft Produkte generell funktionieren ... :-S *grrrr*

Davon abgesehen, gibt es im SCM noch eine Bewertung der Werte nach Critical, Important und Optional. Das ist die Messlatte, die jeder Auditor anlegen wird, wenn es bei euch zu einer Prüfung kommt. Der will sehen, das die wichtigen Werte (Critical und Important) konfiguriert wurden. 
Der Prüfer hat auch keine Ahnung, ob es das Ganze sicherer gestaltet, da er den IE nicht programmiert hat, aber er nutzt den SCM und glaubt der Einschätzung des Herstellers, in unserem Fall Microsoft.

Mein Vorgehen sieht zur Zeit so aus:

 

  • Ich übernehme und verwende die Baseline des Produkts 1zu1 in die Gruppenrichtlinie.
    Damit sind alle Critical und Important Werte enthalten. Optional ist eben optional ... ;-)
  • Das Ergebnis ist: die Anwender können nicht mehr arbeiten, weil u.A. Java im INTERNET ausgeschaltet ist. ;-)
    Aus sicherheitssicht absolut vertretbar, aus produktiver Sicht wohl eher kaum einzuhalten.
  • Ich erstelle eine 2te Richtlinie, in der ich der Konfiguration der Baseline widerspreche und die Funktionen wieder explizit aktiviere/deaktiviere, je nach Baseline Vorgabe,  wenn sie zu restriktiv gestaltet ist und eine Funktion in der Produktion nicht mehr gegeben ist. 
    Das ist das Risiko, das ich akzeptiere, weil ich arbeiten können muss.
  • Ganz wichtig: Der Widerspruch muss nicht für alle gelten! Bei einigen Einstellungen kann das Risiko zu groß sein, wenn es allen erlaubt wird. Den Widerspruch oder mehrere Widersprüche können wir mit Filter belegen, sodass er je nach Sicherheitsanspruch und Bedarf der Produktion nur dort übernommen wird, wo er hingehört.
    Filtern von Gruppenrichtlinien anhand von Benutzergruppen, WMI und Zielgruppenadressierung


Verabschiedet euch von der Idee, daß die Internet Explorer Richtlinien / Policies / Restriktionen benutzerspezifisch sind. Microsoft definiert die Baselines hauptsächlich PRO COMPUTER.

Der IE ist so programmiert, daß er dieselben Werte sowohl in HKCU als auch HKLM akzeptiert, wobei die in HKLM (pro Computer) gewinnen.
Warum? Administratoren haben die Angewohnheit gerne mal OHNE Richtlinien am System zu surfen. Das Sicherheitsrisiko als Benutzer im Internet zu agieren ist wesentlich geringer, als wenn das als Administrator geschieht. Deswegen die Regeln pro Computer, damit es auch für die Administratoren gilt.
Es kann Workstations/Enwickler PCs etc. geben, die andere oder auch gar keine Richtlinien haben. Aber generell sollten Administratoren mit einem restriktivem Browser unterwegs sein. Das gilt natürlich auch für jeden alternativen Browser!

Welche Funktionen wieder zu aktivieren sind, ist von Kunde zu Kunde ganz unterschiedlich. Es ist immer eine längerfristige Aktion, die ca. 1-2 Tage für die Grundkonfiguration benötigt und sich dann vielleicht noch ein halbes Jahr immer wieder als Baustelle entpuppt, weil erst jetzt diverse Reportings auf die Nase fallen, da sie nur einmal im Jahr benötigt werden.

Eine Hilfe, die ihr gerade beim IE benötigen werdet ist diese:
Troubleshooting mit der Brechstange - wenn Logik nicht weiterhilft

Todo:

1.) Ihr exportiert die "IE11 Computer Security Compliance 1.0" Richtlinie als GPO Backup

2.) Ihr erstellt eine neue leere Gruppenrichtlinie in der GPMC, nennt sie z.B.: "C_IE11_Security_Compliance_Manager" und importiert das soeben erstellte GPO Backup

3.) Ihr erstelle eine neue Richtlinie und nennt sie z.B.: "AUSN_C_IE11_Security_Compliance_Manager". Mit dem Label AUSN definiere ich eine Ausnahme zur normalen Konfiguraton. Anhand dieses Namensbestandteils erkenne ich auch ganz schnell, wo die Richtlinie im nächsten Schritt verlinkt werden muss.

4.) Beide Richtlinien werden an die OU der Computer verlinkt und die "AUSN_C_IE11_Security_Compliance_Manager" muss NACH OBEN gesetzt werden, auf Platz 1, damit sie später läuft und damit am Ende gewinnt. AUSNAHMEN müssen immer nach oben, das ist in meiner Namenskonvention leicht zu erkennen.


(klick-vergrößern)

Beispiel, Inhalt: C_IE11_Security_Compliance_Manager

(klick-vergrößern)

Die Konfiguration ist sehr amerikanisch und mit dem deutschen Datenschutz kaum vereinbar. In Deutschland dürfen Benutzer ihren IE Cache löschen und es Bedarf schon eine Sondergenehmigung, wenn ich 40 Tage lang als Administrator im Protokoll (cache) nachlesen darf, wo der Anwender sich rum getrieben hat.
Das ist jetzt ein Spiel rund um eure Betriebsvereinbarungen. Darf der Benutzer das Gerät privat nutzen, ja oder nein, wenn ja muss er zustimmen, wenn er protokolliert werden kann etc.

Beispiel, Widerspruch: AUSN_C_IE11_Security_Compliance_Manager

(klick-vergrößern)

Warum der Aufwand mit einer Widerspruchs-Richtlinie?
... weil es auch für den IE11 eine Nachfolger Version geben wird. Habe ich die Widersprüche ein einer einzigen Richtlinien integriert oder ich habe Differenzen zur Baseline, dann muss ich sie dokumentieren/kommentieren oder in irgendeiner Form kenntlich machen, damit ich bei einer neuen Version die Widersprüche wieder einbauen kann, die ich aus Gründen der Produktion benötige.
Das ist doppelte Arbeit und kann zu Fehlern führen, wenn nicht alles dokumentiert ist.
Mit der zusätzlichen Richtlinie habe ich im ersten Moment mehr Arbeit, da ich Werte doppelt definiere, aber bei jeder neuen Version der Baseline muss ich nur die neue Baseline integrieren. Mein Widerspruch mit allen Einstellungen bleibt erhalten. Die Widerspruchsrichtlinie ist gleichzeitig meine Dokumentation, welche Werte zum Orginal verändert wurden.
Ich empfehle euch: Nutzt die Kommentar Felder und schreibt rein, warum ihr bestimmten Einstellungen widersprecht. Nennt die Produkte, Reports, Webanwendungen etc. die Verursacher sind. Vielleicht hat man irgendwann mal diese Produkte nicht mehr und dann kann der Wert wieder der Baseline angepasst werden. Aber vor Allem ist das ein Feld für den Auditor. Wenn der liest, es gab einen Incident oder ein Produkt das es verlangt, dann fragt der nicht mehr weiter nach.

Noch ein Fazit:
Das bedeutet, daß ihr egal bei welchem Browser ihr am Ende landet eine Möglichkeit finden müsst, diesen sicherer zu gestalten als er im Auslieferzustand ist. Firefox und Chrome sind nicht frei von Fehlern. Sie müssen ebenfalls regelmässig aktualisiert werden. Dummerweise weiss der Admin oftmals garnicht, daß eine Portable Version verwendet wird und dann wird sie auch nicht gepflegt.

Sowohl für Chrome, als auch für Firefox gibt es Möglichkeiten diese per Gruppenrichtlinien zu konfigurieren:

Chrome: Chrome-Richtlinien für Geräte festlegen
https://support.google.com/chrome/a/answer/187202?hl=de
http://dl.google.com/dl/edgedl/chrome/policy/policy_templates.zip

Firefox: Ihr benötigt die Version von Frontmotion
http://www.frontmotion.com/FMFirefoxCE/download_fmfirefoxce.htm
http://www.frontmotion.com/FMFirefoxCE/mozilla.admx
http://www.frontmotion.com/FMFirefoxCE/mozilla.adml