XML-Abfrage Ereignisanzeige
Die Filter für die Windows Ereignisanzeige (Eventlog) sind sehr mächtig geworden. Mit den standard Optionen in der grafischen Oberfläche kann man schon viel machen, aber leider nicht im Nachrichtentext filtern. Das geht auch mit XML Abfragen. Klicken Sie dazu zunächst einmal auf ein ähnliches Ereignis und klicken Sie dort die Detailansicht an. Dort wählen Sie XML View:
Dann erstellen Sie einen benutzerdefinierten Filter und wählen dort den Reiter XML. Setzen Sie das Häkchen bei Abfrage manuell bearbeiten. Wenn Sie bereits bei Filter Reiter Einstellungen gemacht haben, sind diese auch schon im XML hier vordefiniert. Haben Sie z.B. das Anwendungslog ausgewählt steht dort:
<QueryList>
<Query Id=“0″ Path=“Application“>
<Select Path=“Application“>*</Select>
</Query>
</QueryList>
Oben habe ich Sie den XML-View auswählen lassen. Warum? Dort sehen Sie, wie die jeweiligen Felder nach denen Sie suchen können benannt sind. Um nun also z.B. nach dem Benutzernamen zu suchen ergänzen Sie die XML Zeilen wie folgt:
<QueryList>
Id=“0″ Path=“Security“>
<Select Path=“Security“>*</Select>
*[EventData[Data[@Name=‘TargetUserName‚] and (Data=‘s‚)]]
</Select>
</Query>
</QueryList>
Selbstverständlich dürfen Sie das gerne weiter verkomplizieren:
*[EventData[Data[@Name=’SubjectUserName‘] and (Data=’abc‘ or Data=’123’)]]
Dies würde alle mit der Angabe abc oder 123 finden bei UserName finden.
Möchten Sie in mehreren Logs suchen:
<Select Path=“Security“>*[System[(EventID=’1234′)]]</Select>
<Select Path=“Application“>*[System[(EventID=’4321′)]]</Select>
Würde alle Ereignisse aus dem Eventlog Security mit der ID 1234 und alle Ereignisse aus dem Applicationlog mit der ID 4321 anzeigen.
Um die Filter in der PowerShell zu nutzen können Sie die XML-Abfrage genauso in einen String schreiben und mit Get-WinEvent abfragen:
$Query=@“
<QueryList>
Id=“0″ Path=“Security“>
<Select Path=“Security“>
*[EventData[Data[@Name=’TargetUserName‘] and (Data=’s‘)]]
</Select>
</Query>
</QueryList>
„@
$Evts=Get-WinEvent -log Security -FilterXPath $Query -maxevents 1000
Bei Firefox auf neuen Tabs die Auswahl besuchter Websites abstellen
Firefox zeigt in aktuellen Versionen auf neuen Tabs zuvor besuchte Websites an. Die können u. U. sicherheitsrelevante Informationen ausplaudern. Um diese Funktion abzustellen geben Sie in die Adresszeile:
about:config
ein.Setzen Sie die folgenden beiden Einträge auf false:
browser.newtabpage.enabled services.sync.prefs.sync.browser.newtabpage.enabled
und:
browser.newtab.url
auf:
about:blank
Statt blank können Sie natürlich auch gerne eine Website Ihrer Wahl eintragen.
Informationen zu SSL und TLS
Oft spricht man von SSL (Secure Socket Layer) oder SSL-Verschlüsselung. Häufig meint man damit jedoch TLS (Transport Layer Security). Die meist gestellt Frage dürfte wohl sein, was denn nun der Unterschied zwischen SSL und TLS ist. SSL wurde von der Firma Netscape entwickelt um Daten verschlüsselt und sicher über das Internet zu übertragen. Es fand aber nie den Einzug in RFCs und ist somit ein proprietärer Standard. Häufig wird behauptet, dass SSL Version 3.0 dasselbe ist wie TLS Version 1.0. Nun, die beiden liegen ziemlich nah beieinander, sind aber doch so verschieden, dass Sie nicht miteinander kompatibel sind. D.h. ein Client der SSL 3.0 spricht kann nicht auf einen Server zugreifen, der nut TLS 1.0 kann und genauso umgekehrt. TLS ist in RFC 2246 als Internetstandard fixiert. Als Vorlage dafür diente SSL 3.0. Daher auch die häufige Verwechslung der beiden.
SSL 3.1 / TLS 1.0 galten bislang als sicher und werden daher noch vielfach eingesetzt. Im September 2011 wurde allerdings offiziell BEAST (Browser Exploit Against SSL TLS)vorgestellt. Eine länger bekannte Sicherheitslücke, die speziell auf AES (Advanced Encryption Standard) Verschlüsselung abzielt wurde in den nachfolgenden Protokollen TLS 1.1 (RFC 4346) und 1.2 (aktuell – RFC 5246) behoben. Bei RC4 unter TLS 1.0 (obwohl es eine schwächere Verschlüsselung als AES nutzt) funktioniert BEAST ebenfalls nicht.
Microsoft hat das Problem erkannt und daher dieses Security-Bulletin veröffentlicht. Als Administrator eines IIS sollten Sie das auf jeden Fall lesen und anwenden!!!
Für den Apache empfiehlt sich mod_gnutls statt mod_ssl, oder wenn mod_ssl, dann die Verwendung von RC4 statt AES (Beschreibungen dazu finden Sie an jeder Ecke im Internet).
Das Hauptproblem dürften aber die Browser sein. Wenn die Browser nicht schleunigst aktualisiert und vor allem richtig konfiguriert werden, dann nutzt die gesamte Server seitige Sicherheit nichts! Um Ihren Browser sicher zu machen, sorgen Sie in der jeweiligen (IE, Firefox, Chrome, Opera, etc…) Konfiguration dafür, dass nur noch TLS 1.1 oder 1.2 zum verschlüsselten Verbindungsaufbau akzeptiert werden. Sollten Sie keine Option dafür finden, sondern nur TLS 1.0/SSL 3.0, aktualisieren Sie Ihren Browser und wenn das auch nicht hilft, wechseln Sie den Webbrowser! Sollten Sie alles erledigt haben, aber z. B. Probleme beim Onlinebanking bekommen, weil die Webserver der Bank immer noch nur TLS 1.0 können, denken Sie über einen Wechsel Ihrer Bank nach! Das ist dann in meinen Augen schon fahrlässig und somit kein vertrauenswürdiger Geschäftspartner in einem so sensiblen Bereich!
Was Webserver so alles beim Besuch über Sie in Erfahrung bringen können
Wenn Sie die Website http://www.maxa-tools.com/cookie-privacy.php besuchen, wird Ihnen angezeigt, was Ihr Browser alles über Sie verrät. Jeder andere Webserver bzw. jede andere Website die Sie besuchen, kann diese Daten über Sie ebenfalls erfassen, um nicht zu schreiben ausspionieren.
Vertrauenswürdigkeit einer Website überprüfen
Unter http://www.trustedsource.org/ kann man seine eigene, aber natürlich auch jede andere Website überprüfen lassen und danach entscheiden, ob man den Besuch dort fortsetzt, oder lieber nicht. Man erfährt natürlich auch warum man keine Besucher hat, wenn man schlecht eingestuft wurde. Einige Firewallhersteller, wie z. B. Astaro blocken den Verkehr, wenn die Site nicht als sicher genug eingestuft ist (vergleichen Sie dort doch einmal serials.ws mit www.martinlehmann.de ;-)).
Linux Firewall Tipp gegen SYN-Flood Attacken
Bei SYN-Flood Attacken werden von einem bösen Client mehrere Verbindungsanfragen an einen Server geschickt und einfach offen stehen gelassen. Irgendwann schafft der Server es nicht mehr so viele Verbindungen zu erhalten. Um solcher Attacken Herr zu werden tragen Sie in Ihre Linux-Firewall die folgenden beiden Regeln ein:
iptables -I INPUT -m state --state NEW -m recent --set iptables -I INPUT -m state --state NEW -m recent --update --seconds 60 --hitcount 11 -j DROP
Damit können nur noch 10 Verbindungsversuche von einer einzelnen IP-Adresse innerhalb einer Minute durchgeführt werden. Alle Weiteren werden verworfen, wodurch dem Server viel Arbeit erspart wird.
Identity Management bei IIS 7.5 unter Windows Server 2008 auf einen Blick
Bei IIS 7.5 unter Windows Server 2008 R2 und auch bei IIS 7 ist es gar nicht so leicht zu durchblicken wann welcher Benutzer zur Authentifizierung und Autorisierung zum Einsatz kommt. Daher habe ich einmal ein Schaubild gezeichnet auf dem die Zusammenhänge der verschiedenen Einstellungen deutlich werden (wenn das Bild fehlt bitte auf die Artikel-Überschrift klicken):
Weitere Informationen zur Application Pool Identity bei IIS 7.5 finden Sie hier. Wie man den Zugriff auf UNC-Freigaben weiterleitet wird hier erklärt.
IIS 7.5 Webserverkennung ändern
Im Internet gibt es unzählige Beiträge wie man den HTTP-Responseheader beim IIS verändert, oder abschaltet. Diese Tipps funktionieren aber nur bei ältern IIS Webservern. Die Beispiele die ich für IIS 7.5 unter Windows Server 2008 R2 gefunden habe sind entweder wirkungslos oder produzieren nur Fehler. Hier die Lösung!
Installieren Sie, falls noch nicht vorhanden, den Rollendienst ASP.NET mit dem Servermanager. Legen Sie in Ihrem Webverzeichnis einen Ordner namens App_Code an ( keine Verhandlungen – das Verzeichnis muss so heißen!). In diesem Verzeichnis erstellen Sie eine Datei Namens Martins.ServerModules.RemoveServerHeaderModule.cs. In die Datei schreiben Sie mit Notepad folgenden Text:
using System; using System.Text; using System.Web;
namespace Martins.ServerModules
{
public class RemoveServerHeaderModule : IHttpModule
{
public void Init(HttpApplication context)
{
context.PreSendRequestHeaders += OnPreSendRequestHeaders;
}
public void Dispose()
{ }
private void OnPreSendRequestHeaders(object sender, EventArgs e)
{
HttpContext.Current.Response.Headers.Set("Server", "Apache");
}
}
}
Dann fügen Sie in der IIS-Verwaltungskonsole für die Website in der Sie vorhin den Ordner App_Code erstellt haben ein verwaltetes Modul hinzu. Unter Name schreiben Sie etwas was Sie wiedererkennen also z. B. MartinsModul und unter Typ schreiben Sie den Dateinamen ohne die Dateinamenerweiterung, also: Martins.ServerModules.RemoveServerHeaderModule. Dämliche Rückfragen mit Ja beantworten und schon ist Ihr IIS angeblich ein Apache. Das was er da anmotzt behebt er automatisch.
Mit einem Netzwerksniffer sehen Sie nun in der Rückantwort vom Server statt:
Server: Microsoft-IIS/7.0\r\n
Server: Apache\r\n
Den Eintrag: X-Powered-By: ASP.NET\r\n werden Sie ganz einfach über HTTP-Antwortheader in der IIS-Verwaltungskonsole los. Das kann ja jeder ;-), aber etwas löschen was nicht da steht ist gar nicht so einfach!
Kostenloser offline Virenscanner von Microsoft
Basierend auf den guten Microsoft Security Essentials bietet Microsoft einen kostenlosen offline Virenscanner zum download an. Microsoft System Sweeper kann entweder von einem USB-Stick gestartet werden oder von CD. Als Betriebssystembasis wird Windows PE eingesetzt. Der Scanner aktualisiert seine Virenmuster automatisch über das Internet um auf dem neuesten Stand zu bleiben.
Powershell Richtlinie für Skriptausführung manipulieren
Mit der Powershell können aus Sicherheitsgründen erste einmal keine PS1 Scripte ausgeführt werden. Um Scripte ausführen zu können muss man mittels set-executionpolicy unrestricted oder per Gruppenrichtlinie im Active-Directory die Scriptausführung explizit erlauben. Andere mögliche Werte (z. B. dass nur digital signierte Scripte ausgeführt werden können) die man übergeben kann findet man mit help set-executionpolicy schnell heraus.
Aber was soll der ganze Aufwand? Hier einige Möglichkeiten die Standardausführungsrichtlinie außer Kraft zu setzen:
Von der Eingabeaufforderung aus
type NamedesPowershellscripts.ps1 | powershell -
Als Desktopverknüpfung
Legen Sie eine Standardverknüpfung auf dem Desktop über das Kontextmenü an. Als Ziel tragen Sie ein:
powershell -executionpolicy unrestricted -file C:\PfadzumScript\NamedesPowershellscripts.ps1
Registry-Hack
Wer mag kann auch einfach im CurrentUser-Key das Gegenteil vom LokalMachine-Key behaupten (bei 2008 R2 klappt dies leider nicht immer, dafür funktionieren die ersten beiden Varianten sogar bei einer anders lautenden Gruppenrichtlinie des Active Directory!!!):
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Powershell\1\ShellIds\Microsoft.PowerShell] "ExecutionPolicy"="Unrestricted"
Speichern Sie einfach den kursiv geschriebenen Text in einer Datei mit der Endung .reg und machen Sie anschließend einen Doppelklick darauf. Fertig!