NirSoft – RegFromApp

Nir Sofer bietet auf seiner Website verschiedene nützliche Tools an die den Admin-Alltag um einiges erleichtern können.

Das erste davon, welches ich empfehlen kann heißt „RegfromApp“.

http://www.nirsoft.net/utils/reg_file_from_application.html

Mit diesem Tool ist es möglich, neue Prozesse zu starten oder einen laufenden Prozess auszuwählen und jegliche Registrierungsaktivitäten dieses Prozesses mitprotokollieren zu lassen und diese anschließend in eine *.reg Datei zu speichern um diese (zum Beispiel zur weiteren Verteilung) später zu verwenden.

Für 32-Bit Prozesse benötigt man die 32-Bit Variante, für native 64-Bit Prozesse die entsprechende 64-Bit Variante.

Beides sind „portable“ Apps die weder eine bestimtme Laufzeitumgebung noch eine Installation voraussetzen.

Über den obigen Link findet man die Downloads der beiden *.exe – Dateien sowie kurze englischsprachige Erklärungen. Auch passenden Kommandozeilenparameter für die Programme finden sich dort.

Installationscheckliste Microsoft SQL Server

Vor der SQL Server Installation

1.) BIOS / Firmware / Treiberupdates

2.) Festplattenkonfiguration

Bei Hardware-Systemen

RAID 1 Verbund von SSDs / HDDs für Betriebssystem / Logs / Backups (logische Trennung durch Ablage in separaten Volumes)

RAID 10 Verbund von SSDs / HDDs für Datendateien (logische Trennung Datenbankdateien und TempDBs)

Bei virtuellen Systemen

separate virtuelle Festplatten für

  • Betriebssystem
  • Datenbankdateien (inklusive TempDB)
  • Logfiles
  • Backups

3.) Betriebssystem installieren und alle aktuellen Updates installieren

4.) Partitionierung

64K Blockgröße für die Partitionen der Datenbankdateien, Logfiles und Backup beim Initialisieren verwenden (Vollständige Formatierung nicht Schnellformatierung verwenden) und diesen Laufwerken Laufwerksbuchstaben zuordnen

5.) Ausnahmen für Antivirensoftware konfigurieren

In der Antivirensoftware Ausnahmen für die Dateiendungen der SQL-Server relevanten Dateien (*.mdf, *.ndf, *.ldf, *.bak und *.trn) konfigurieren

6.) Benötigte SQL Server Features definieren

Vorüberlegung anstellen, welche SQL Server Features installiert werden sollen (Sparsamkeit walten lassen – nur installieren was auch benötigt wird). Diese Entscheidung  hat direkten Einfluss auf die nächst Vorbereitung

7.) Anlage Benutzeraccounts für SQL Server Dienste

Für jeden SQL Server Dienst einen Active Directory Benutzeraccount erstellen

  • SQL Server Dienst
  • SQL Agent Dienst
  • SQL Reporting Dienst (optional)
  • SQL Analysis Dienst (optional)
  • SQL Integrations Dienst

Benutzen Sie gpedit.msc um dem Benutzeraccount des SQL Server Service Benutzers die benötigen Rechte einzuräumen (Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Management)

Perform volume maintenance tasks

INFO: Die entsprechende Einstellung kann bei der Installation des SQL Server 2016 über das Setzen eines Hakens während der Installation automatisch von der Installationsroutine vorgenommen werden

8.) Windows Energieoptionen auf „Höchstleistung“ stellen

Dies sollte idealerweise für alle Server-Computerobjekte über eine Windows Gruppenrichtlinie gelöst werden

Während der SQL Server Installation

9.) SQL Server Produkt Updates installieren

Haken setzen bei „Include SQL Server Product Updates“ um aktuelle Updates für den SQL Server direkt mit zu installieren (Internetzugriff bzw. zumindest Zugriff auf „Windows Updates“ vom Server aus ist hierfür Voraussetzung)

10.) SQL Server Features auswählen

Nur die SQL Server Features installieren, welche auch wirklich benötigt werden (siehe Punkt 6.)

11.) Dienste-Benutzer / Starttyp konfigurieren

Für die entsprechenden Dienste den korrekten Benutzeraccount verwenden, welcher unter Punkt 7. definiert und erstellt wurden.

Den Starttyp des Dienst „SQL Server Agent“ auf „Automatisch“ stellen

12.) Installationspfade anpassen

Anpassen der Installations- und Ablagepfade für die Datenbankdateien, Logfiles und Backups.

13.) Einstellungen für TempDB konfigurieren

Auf dem Reiter „TempDB“ sollten so viele Dateien konfiguriert werden, wie dem Server an CPU-Kernen zugewiesen bzw. eingebaut sind. MAXIMAL jedoch 8.

Die Initialgröße für die Dateien der TempDB sollte auf 1024 MB eingestellt werden, der Wert für die automatische Größenanpassung auf 512 MB. Diese Werte sollten ebenso für das Logfile der TempDB konfiguriert werden.

Zudem die Dateipfade auf die separate Datenbankdatei-Partition lenken.

 

Nach der SQL Server Installation

14.) SQL Server Updates prüfen / installieren

Auf aktuelle Updates der entsprechenden SQL Server Version prüfen und diese installieren Übersicht SQL Server Builds (Blogspot)

ALLGEMEINER HINWEIS

Zum Konfigurieren der SQL Server Dienste IMMER die Konsole „SQL Server Configuration Manager“ verwenden, nicht die „normale“ Diensteverwlatung (services.msc)

15.) Unbenötigte Dienste deaktivieren

Sollten bestimmte Dienste nicht mehr benötigt werden ODER aufgrund einer zentralen Installation nur „für den Fall das“ installiert worden sein, sollten diese im „SQL Server Konfigurations Manager“ –> SQL Server-Dienste“deaktiviert werden.

16.) TCP/IP aktivieren / Port definieren

Ebenfalls im „SQL Server Konfigurations Manager“ sollte unter „SQL Server Netzwerkkonfiguration“ der Protokollstapel TCP/IP aktiviert werden und der Instanz des SQL Servers ein fester Port (Standard: 1433) zugeordnet werden.

17.) Starttyp der Dienste prüfen / konfigurieren

Zudem sollte hier geprüft werden, dass für die benötigten Dienste der Starttyp auf „Automatisch“ steht.

18.) Wiederherstellungsoption der Dienste konfigurieren

Die „Wiederherstellungsoptionen“ sind nicht im SQL Server Konfigurations Manager zu konfigurieren, hierfür muss (abweichend von der vorherigen alglemeinen Empfehlung) die Dienstekonfiguration von Windows (services.msc) verwendet werden. Hier sollte für ersten und zweiten Fehler „Dienst neustarten“ konfiguriert werden.

19.) Eigenschaften der SQL Server Instanz konfigurieren

Im „SQL Server Management Studio“ die Eigenschaften der SQL Server Instanz aufrufen

ARBEITSSPEICHER –> Minimalen und Maximalen Arbeitsspeicher konfigurieren (Maximal = installierter bzw. zugewiesener Arbeitsspeicher – 4GB Betriebssystem – benötigte GB Arbeitsspeicher anderer SQL Server Instanzen auf gleichem Server)

DATENBANKEINSTELLUNGEN –> Haken setzen bei „Sicherungen komprimieren“

ERWEITERT –> Für ad-hoc Arbeitsauslastung optimieren –> True

INFO: Dieser Wert ist bei SQL Server 2016 standardmäßig aktiviert

 

20.) TempDB Eigenschaften prüfen / konfigurieren

Im „SQL Server Management Studio“ die Eigenschaften der TempDB Datenkbank anpassen

Weitere Datendateien für Log bzw. Datenbank hinzufügen (Anzahl der zugewiesenen / installierten CPUs, jedoch maximal 8) alle mit gleicher Initialgröße (1024MB) und gleicher automatische Größenanpassung (512 MB)

21.) Datenbank-E-Mail konfigurieren

Im „SQL Server Management Studio“ –> Verwaltung –> Datenbank-E-Mail konfigurieren

22.) Datebanksicherungen konfigurieren

Im „SQL Server Management Studio“ –> Verwaltung –> Wartung Sicherungen planen (Vollsicherung, 1x täglich, je nach vorhandenem Speicherplatz und anderen Sicherungsverfahren für 1 Woche oder länger vorhalten)

23.) SQL Server Best Practices Analyzer

Den SQL Server Best Practices Analyzer verwenden, um weitere notwendige Konfigurationen zu erkennen und einrichten zu können.

SQL Server BPA Download (Microsoft)

Notwendige Konfiguration zur Nutzung unter Windows Server 2012 R2 (Purestorage Blog)

Sysinternals – Process Monitor

Jeder Windows-Administrator sollte von der Sysinternals Suite (und dem „Mastermind“ Mark Russinovich dahinter) gehört haben und sich die Sammlung an nützlichen Tools einmal etwas genauer anschauen.

Eines der wichtigsten und vielseitigsten Tools ist der Process Monitor. Dieser protokolliert jegliche Prozessaktivitäten auf einem System mit (Datei-, Netzwerk-, Registry- und Threadaktivitäten). Diese kann man anschließend filtern um dem Ursprung eines Problems auf die Schliche zu kommen.

Man muss sich zwar anfangs ein wenig mit dem Tool auseinander setzen, aber es lohnt sich.

Website mit der jeweils aktuellsten Version: https://technet.microsoft.com/de-de/sysinternals/bb896645.aspx

Als weiteres gutes „Feature“ empfinde ich vorallem die Zusammenfassungen zu Prozessaktivitäten, aus denen man leicht herauslesen kann auf welche Datei am meisten zugegriffen wurde oder welcher Prozess am meisten die CPU oder das Netzwerk beanspruchte während des „Tracing“.

Diese erreicht man im Process Monitor unter „Tools“

procmon_01

Zudem gibt es auch die Option den Bootvorgang mitzuprotokollieren um hier zum Beispiel der Ursache von „langsamen“ Startvorgängen des PC auf die Schliche zu kommen.

procmon_02

 

HINWEIS: Unter Windows 10 (vermutlich auch Windows 8 oder 8.1) erscheint gegebenenfalls hierbei eine Meldung, dass die Datei „Procmon32.sys“ nicht geschrieben werden konnte.

procmon_03

Hierzu gibt es einen Beitrag im Sysinternals Forum:

http://forum.sysinternals.com/cannot-enable-boot-logging-in-win10x64-build-10240_topic31494.html

Falls die Datei ProcMon23.sys bereits im Verzeichnis %Windir%\System32\Drivers vorhanden ist, soll man die Datei entfernen bzw. umbenennen (ist die Datei in Benutzung gelingt dies erst nach einem Neustart).

Anschließend den Process Monitor über eine Administrative (WICHTIG!) Eingabeaufforderung mit folgendem Parameter starten:

[Pfad zu Procmonverzeichnis]\procmon.exe /noconnect

Nun gelingt auch das Aktivieren der Bootvorgangsprotokollierung.

Hier gibt es einige Anleitungen bzw. „Hands-on-Beispiele“ in englischer Sprache die einen ersten Eindruck vermitteln:
https://blogs.technet.microsoft.com/appv/2008/01/24/process-monitor-hands-on-labs-and-examples/

Sehr zu empfehlen sind auch die Videopodcasts von „Defrag Tools“ zu dem Thema (und auch anderen).

Process Monitor – Optionen etc.

Process Monitor – Beispiele zur Benutzung

Sicherungsmaßnahmen für das WLAN zu Hause

In diesem Artikel möchte ich Schutzmaßnahmen um das eigene WLAN abzusichern in aller Kürze darlegen und vor vermeintlichen Schutzmaßnahmen warnen.

Wer sich eingehender mit der Thematik außeinander setzen möchte, dem sei unter anderem das Buch „Network Hacking“ von Dr. Peter Kraft und Andreas Weyert ans Herz gelegt.

SSID verbergen wirkungslos

Bietet keinerlei Schutz. Unter anderem mit dem Tool Kismet-Newcore (oder anderen passiven Netzwerk-Sniffern) ist es ein leichtes auch versteckte WLANs zu entdecken.

SSID anpassen / individualisieren

Auf jeden Fall sollte man jedoch die Standard-SSID des WLAN Netzes ändern. Somit umgeht man, dass ein Angreifer auf den ersten Blick zum Beispiel das Router-Modell oder ähnliches erkennen kann. Zudem können gleichlautende WLANs (Fritzbox, oder WLAN oder ähnliches) zu Konnektivitätsproblemen führen.

Der WLAN Name sollte im besten Fall keine Rückschlüsse auf den Besitzer, die verwendete Hard- oder Software oder gar das verwendete Kennwort zulassen.

TIPP: Um zu verhindern, dass das eigene WLAN in in Googles Standort-Datenbank aufgenommen wird, muss an die SSID die Zeichenfolge _nomap angehangen werden.

Aus der SSID „Hier“ wird somit „Hier_nomap“.

MAC-Adress Filterung kein wirkliches Hindernis

Bietet nur wenig Schutz. Das bereits genannten Kismet-Newcore zeigt nach einer Analyse des Datenverkehrs im Funknetzwerk nicht nur die (versteckte) SSID des Netzwerkes an sondern auch die MAC-Adressen / IP-Adressen des Access Point sowie der verbundenen Clients, das verwendete Verschlüsselungsverfahren und mehr.

Ein Angreifer mit etwas technischem Verständnis kann mit Hilfe von Online-Tutorials die MAC-Adresse seiner Netzwerkkarte „fälschen“ (MAC-Adress Spoofing) und Verbindungsversuche bzw. Angriffe starten, wenn das eigentliche autorisierte Gerät nicht mehr funkt.

WEP Verschlüsselung nicht einsetzen

Der Verschlüsselungsalgorithmus WEP ist seit spätestens 2004 als „gebrochen“ anzusehen. Das „Erraten“ des verwendeten geheimen Schlüssel kann inzwischen innerhalb weniger Sekunden bis Minuten mit Tools wie (Aircrack-ng) erfolgen.

WPS unbedingt deaktivieren

WPS wurde durch die „WiFi-Alliance“ als einfache Alternative zum Pre-Shared-Key Verfahren für den Aufbau einer verschlüsselten Verbindung im Heimnetzwerk entwickelt.

Aufgrund von schwachen oder fehlerhaften Implementierungen in den meisten Router-Firmware der unterschiedlichsten Hersteller, ist es jedoch ein leichtes die konfigurierte PIN mit Hilfe von entsprechenden Tools innerhalb weniger Minuten bis Stunden durch sogenannten Brute-Force-Angriffe zu erraten.

Da in den meisten Routern WPS standardmäßig aktiviert ist, sollte man dringend im eigenen Router diese Optionen bewusst prüfen bzw. deaktivieren.

Einsatz von WPA2 mit starker Passphrase

Auch wenn immer leistungsfähigere Tools und Hardware zum Brechen von Verschlüsselungsverfahren entwickelt werden, gilt der Verschlüsselungsstandard WPA2 als sicher, WENN das Kennwort für die Verschlüsselung lang und komplex genug ist.

Da das Verschlüsselungskennwort nur einmalig am Endgerät eingegeben werden muss, sollte man hierbei mindestens eine 24 (beser 48 oder 64) Zeichen lange und durch Nutzung von willkürlichen Zahlen, Groß- und Kleinbuchstaben und Sonderzeichen möglichst komplexe Zeichenkette verwenden.

Zum Beispiel: /7fzG9)äIlf4$3hgldmf,Hlgodk3!“93″3kdo/%kgOks‘;5§#flshjg

Selbst WPA2 ist nur so sicher, wie die gewählte Passphrase.

Firmware des WLAN Routers aktualsieren

Wie bei jeder anderen Software auch, gilt: Immer wieder prüfen ob Aktualisierungen für die Firmware (das Betriebssystem des Routers) vom Hersteller angeboten werden und falls ja, diese installieren.

Komplexes Kennwort für den WLAN Router

Ebenso wichtig wie das Kennwort für die Verschlüsselung ist das Kennwort für den Router. Auch hier ist es Angreifern durchaus möglich, durch Schwachstellen in der Firmware, Zugriff auf den Router zu erhalten ohne die Verschlüsselung brechen zu müssen (schlimmstenfalls sogar aus dem Internet).

Auch hier gilt, je länger und komplexer desto besser.

Duale IT-Berufsausbildung auf dem Prüfstand

Das Bundesinstitut für Berufsbildung führt noch bis zum 25.05.2016 eine Umfrage im Bezug auf eine eventuelle Neugestaltung / Neuausrichtung der dualen IT-Ausbildungen für die Ausbildungsberufe

  • Fachinformatiker/-in (Systemintegration bzw. Anwendungsentwicklung)
  • IT-System-Elektroniker/-in
  • IT-System-Kaufmann/-frau
  • Informatikkaufmann/-frau

durch. Angesprochen sind alle Auszubildenden, Ausbilder, IT-Fachkräfte, Personalverantwortliche, Leitungspersonal aber auch Lehrkräfte an einer Berufsschule für IT-Berufe.

Hier geht es zur Umfrage: IT Berufe Aktuell

Systemweiten Java Zertifikatsspeicher (trusted.certs) verwalten

Ich wollte meinen Ansatz zur Konfiguration einer zentralen Zertifikatsspeicherdatei als Ergänzung zu meinem BeitragSystemweite Java Runtime Konfiguration“ veröffentlichen.

Ich importierte alle notwendigen Zertifikate in eine Zertifikatspeicherdatei, in welche ich immer wieder neue, notwendige Zertifikate hinzufüge und nicht mehr benötigte bzw. abgelaufene entferne.

Diese Datei verteile ich automatisiert auf die Endgeräte bzw. Server. Hierzu gibt es verschiedene Variante (Startup-Skripte, Gruppenrichtlinienvoreinstellungen, SCCM, etc).

Um die Datei zu bearbeiten, lege ich Sie in folgendem Unterverzeichnis des Benutzerprofils ab:

C:\Users\[USERNAME]Appdata\LocalLow\Sun\Java\Deployment\Security\trusted.certs

Öffnet man nun das Java Control Panel –> Reiter „Sicherheit“ –> „Zertifikate verwalten“ kann man den aktuellen Inhalt der trusted.certs Datei aus dem obigen Verzeichnis einsehen.

java_control_panel_security_certificates_before

Liegen einem die Zertifikate in Dateiform vor, kann man diese über den Button „Importieren“ einfach in die Zertifikatspeicherdatei hinzufügen. Genau kann man enthaltene Zertifikate auch exportieren oder vollständig entfernen.

Liegt einem das Zertifikat nicht vor, startet man die Java Applikation deren Zertifikat man hinzufügen möchte.

Wenn nun der Hinweis erscheint, ob man dieser Anwendung aus dieser Quelle vertrauen möchte, setzt man den Haken bei „Für Anwendung dieses Anbieters aus diesem Speicherort nicht mehr anzeigen“ und klickt auf „Ausführen“.

Java Applet Warning Accept

Wenn schließlich die Anwendung erfolgreich gestartet wurde, kann man erneut im Java Control Panel prüfen ob nun das Zertifikat enthalten ist.

Java Control Panel Security Certificates After

Nach den getätigten Änderungen verschiebt man die Datei trusted.certs wieder an den zentralen Verteilungspunkt, so dass sie auf allen System ausgetauscht bzw. auf diese verteilt werden kann.

User Truststore to System Truststore

Wenn die Datei nun auf dem Endgerät / Server ersetzt ist, muss das zusätzliche Zertifkat unter „System“ im Java Control Panel auftauchen.

Java Control Panel Security Certificates System

Systemweite Java Runtime Konfiguration

Im privaten Umfeld ist eine systemweite Konfiguration von Java nicht unbedingt notwendig, in Unternehmensumgebungen ist es wiederum durchaus ratsam eine solche Konfiguration der Java Runtime vorzunehmen.

Hierfür sind einige Konfigurationsschritte notwendig, welche ich nachfolgend beschreiben möchte.

Auch im Hinblick auf die Nutzung dieser Konfiguration in einer Citrix Umgebung mit PVS, liegt die Datei mit den zentralen Einstellungen nicht auf der Systempartiton (beispielhaft mit dem Laufwerksbuchstaben D: bezeichnet unter dem zum Beispiel die Write-Cache Partition verbunden ist).

Standardmäßig prüft Java ob folgende Datei auf einem Windows System vorhanden ist:

%WINDIR%\Sun\Java\Deployment\deployment.config

Und falls ja, wird diese ausgewertet.

Ansonsten wird immer die automatisch erstellte deployment.properties Datei (Standardpfad: <User Application Data Folder>\LocalLow\Sun\Java\Deployment\deployment.properties) verwendet.

Die Datei deployment.config beinhaltet lediglich zwei konfigurierbare Einträge.

1.) deployment.system.config=[Pfad zur Datei deployment.properties]

Die URL zu der system (bzw. unternehmens)-weiten Konfigurationsdatei.

Bei lokalen Dateien muss das Protokoll: file:// mit angegeben werden:

2.) deployment.system.config.mandatory=[TRUE oder FALSE]

Dieser Wert gibt an, ob die systemweite Konfigurationsdatei gefunden werden MUSS (TRUE) da sonst alle Java Funktionen blockiert werden oder ob Java im Falle, dass sie nicht gefunden wird, mit Standardwerten starten darf (FALSE). Standardwert ist FALSE.

Beispiel 1:

deployment.system.config=file:///D:/JavaConfig/Deployment/deployment.properties
deployment.system.config.mandatory=FALSE

Beispiel 2:

deployment.system.config=\\[Dateiserver]\[Freigabe]\deployment.properties
deployment.system.config.mandatory=TRUE

Kann die Datei nicht gefunden werden aber der Wert deployment.system.config.mandatory ist auf TRUE gesetzt, erscheint folgende Meldung beim Aufruf einer Java Applikation:

Java Warnung Konfigurationsdatei nicht gefunden

Deshalb sollte die Option nur auf TRUE gesetzt werden, wenn man 100% sicherstellen kann, dass die Konfigurationsdatei IMMER verfügbar ist bzw. lokal auf dem System abgelegt ist.

Es gibt eine ganze Reihe Optionen die man in der Datei deployment.properties konfigurieren kann.

Es gibt jeweils den Optionsparameter, zum Beispiel:

deployment.cache.max.size=150

Java Setting

Dieser enthält den Optionsnamen und den zugehörigen Wert.

Zudem ist es möglich die jeweilige Option zu sperren, indem man als zusätzlichen Eintrag ein locked an den Parameter anhängt.

deployment.cache.max.size.locked

Hierdurch wird die entsprechende Einstellung im Java Control Panel vollständig vor dem Benutzerzugriff geschützt, so dass der Benutzer diesen Wert (unabhängig davon ob er konfiguriert ist oder nicht) anpassen kann oder nicht.

Mit folgenden Einträgen in der deployment.properties erhält man das im folgenden Screenshot gezeigte Ergebnis:

...
deployment.cache.max.size=150
deployment.cache.max.size.locked
deployment.cache.enabled=true
deployment.cache.enabled.locked
deployment.user.cachedir=D\:\\JavaConfig\\UserCache\\
deployment.user.cachedir.locked
...

Java Settings locked

Eine vollständige Liste der verfügbaren Optionen findet sich unter: 

Alle Eigenschaften (docs.oracle.com)

Nachfolgend ein paar der meiner Meinung nach sinnvollsten, wobei die Liste in jedem Anwendungsfall unterschiedlich ist.

deployment.security.mixcode=HIDE_RUN
Führt gemischten Code ohne Nachfrage in einer Sandbox aus.

deployment.cache.max.size=150
In Java Version 8 ist die maximale Standardgröße auf unlimitiert (verbleibender freier Speicherplatz der entsprechenden Partition) eingestellt. Wie bei jeder „Cache-Größe“ ist eine allgemeingültige Größe schwer zu definieren und sollte abhängig vom Anwendungsfall definiert werden. 150 MB sind für die normalen Anwendungen sicherlich ausreichend.

deployment.expiration.check.enabled=false
Durch diesen Wert für den genannten Paramter findet keine Prüfung beim Starten der Java Laufzeitumgebung statt, ob diese veraltet ist. In einer Unternehmensumgebung sollten die Benutzer keine entsprechenden „verwirrenden“ Hinweise erhalten. Der Administrator sollte dafür Sorge tragen, dass aktuelle Java Versionen im Einsatz sind.

deployment.user.security.exception.sites=D\:\\JavaConfig\\Deployment\\exception.sites

In dieser Datei kann die zentrale Ausnahmeliste für Websites, welche die erhöhten Sicherheitseinstellungen umgehen müssen, geführt werden.

Manuelles Hinzufügen ist über das Java Control Panel über den Reiter „Sicherheit“ → „Siteliste bearbeiten“ möglich.

deployment.system.security.trusted.certs=D\:\\JavaConfig\\Deployment\\trusted.certs

Pfad zu einer Zertifikatsstore-Datei mit vertrauenswürdigen Applet-Zertifikaten von zum Beispiel netzinternen Webservern, denen automatisch vertraut werden soll.

Unter folgendem Link findet sich ein Beitrag von mir wie man diese Datei bearbeiten kann:

Systemweiten Java Zertifikatsspeicher (trusted.certs) verwalten

Webbrowser absichern Teil 3: Mozilla Firefox

Der dritte und abschließende kleine „Leitfaden“ um den Webbrowser etwas sicherer zu machen.

1.  Vorbemerkungen
2.  Einleitung
3.  Browser- und Plugin-Updates
4.  Automatische Updates
5.  Datenschutz
5.1  Verfolgung von Nutzeraktivitäten
5.2  Chronik (Browserverlauf) deaktivieren / löschen
5.3  Cookies deaktivieren
6.  Popups deaktivieren
7.  Sicherheit
8.  Erweiterte Einstellungen
8.1  Allgemein
8.2  Datenübermittlung
9.  Verschlüsselungseinstellungen
10.  Nützliche Erweiterungen
10.1  HTTPS Everywhere
10.2  uMatrix

Hier geht es zum Dokument: Mozilla_Firefox_absichern

Webbrowser absichern Teil 2: Google Chrome

Der zweite Teil widmet sich voll und ganz dem Goolge Chrome Browser. Auch diesmal wieder die Anleitung in einem PDF – Dokument zusammengefasst.

1. Vorbemerkungen
2. Einleitung
3. Browser- und Plugin-Updates
4. Automatische Updates
5. Browserverlauf löschen
5.1 Manuelles Löschen
5.2 Alternative 1: Inkognitomodus
5.3 Alternative 2: Erweiterung „Click&Clean““
6. Webdienste einschränken
7. Inhaltseinstellungen
7.1 Cookies blockieren
7.2 Plugins blockieren
7.3 Popups blockieren
7.4 Standortzugriff blockieren
7.5 Bei Benachrichtigungen nachfragen
7.6 Websitezugriff auf Mikrofon / Kamera verhindern
7.7 Pluginzugriff ohne Sandbox verweigern
7.8 Automatische Downloads verhindern
8. Verschlüsselungseinstellungen
9. Nützliche Erweiterungen
9.1 Click&Clean
9.2 HTTPS Everywhere
9.3 uMatrix

Hier geht es zum Dokument: Google_Chrome_absichern

Webbrowser absichern Teil 1: Internet Explorer

Aufgrund der umfangreichen Einstellungsmöglichkeiten habe ich mich entschlossen, die Anleitung in einem PDF – Dokument zusammen zu fassen.

1. Vorbemerkungen
2. Einleitung
3. Browser- und Plugin-Updates
4. Automatische Updates aktivieren
5. Browserverlauf beim Beenden löschen
6. Popups blockieren
7. Verwenden der Sicherheitszonen
8. Cookies blockieren und Zugriff auf Standort verhindern
9. Browsererweiterungen von Drittherstellern deaktivieren
10. Verschlüsselungseinstellungen
11. Do Not Track – Einstellungen
12. Erweiterter geschützter Modus
13. SmartScreen Filter aktivieren
14. Diverse Optionen

Hier geht es zum Dokument: Anleitung: Internet Explorer absichern