the Sky is the Limit
Zur zentralen Verwaltung von Sicherheitsprodukten verwendet ESET den ESET-Remote-Administrator (ERA). Steht dieser im Intranet mit NAT-Adressraum, so ist er nicht ganz einfach aus dem Internet erreichbar.
Ich beschreibe hier die notwendigen Schritte, um Remote-Clients dennoch den Kontakt zum ERA-Server zu ermöglichen, ohne eine VPN-Verbindung aufzubauen. „ESET ERA über NAT erreichen“ weiterlesen
Windows Systeme ab Version 7 und Server ab 2008 haben in den Standard Firewall-Einstellungen ICMP aus Sicherheitsgründen deaktiviert. Das hat zur Folge dass diese Systeme auch nicht mehr auf Echo Requests (PING) antworten. Während einige der Debug Methoden von ICMP als kritisch für die Sicherheit einzustufen sind, ist die PING Funktion (ICMP Typ 8) in der Fehleranalyse sehr wertvoll. Man kann diese selektiv an der Firewall freischalten, ohne alle anderen ICMP Funktionen zu aktivieren.
Der herkömmliche netsh firewall Befehl ist veraltet, aber er funktioniert noch. Dennoch sollte man künftig nur noch den neuen advfirewall Befehl anwenden.
PING erlauben:
netsh firewall set icmpsetting 8
PING verbieten:
netsh firewall set icmpsetting 8 disable
netsh advfirewall firewall add rule name="ICMP Allow incoming V4 echo request" protocol=icmpv4:8,any dir=in action=allow
Danach antworten die oben genannten Server- und Desktop Systeme auf Ping Anfragen, ohne alle anderen ICMP Funktionen zu erlauben.
Die Regel kann mit folgendem Befehl wieder deaktiviert werden:
netsh advfirewall firewall delete rule name="ICMP Allow incoming V4 echo request" protocol=icmpv4:8,any dir=in
ESXi Hosts, welche vom Flashmedium booten haben keinen permanenten Logspeicher. Das bedeutet, dass alle Logmeldungen nach einem Host Neustart verloren gehen. Aus diesem Grund gibt es den Syslog Collector Dienst, welcher bei der vCenter Installation (Win) zusätzlich installiert werden kann. Die Konfiguration auf habe ich in einem früheren Blogeintrag geschildert. Dieser empfängt Logeinträge von den ESXi Hosts und speichert sie lokal in rotierenden Logfiles ab.
Der VMware Support bat mich kürzlich, diese Logs für einen ESXi Host bereit zu stellen. Zunächst musste ich das Logverzeichnis auf dem Server mit Syslog Collector finden. Es liegt bei Standard Installationen unter:
%ALLUSERSPROFILE%\VMware\VMware Syslog Collector\Data
Beziehungsweise:
"C:\ProgramData\VMware\VMware Syslog Collector\Data"
Dort hat jeder überwachte ESXi Host ein Verzeichnis mit der jeweiligen IP des Hosts. Das Verzeichnis war schnell gefunden, jedoch staunte ich nicht schlecht, als ich den Zeitstempel der Logs sah.
Seit über zwei Jahen gab es keinen Logeintrag mehr! Wie kann das sein?
Auf dem Syslog Collector sah alles gut aus und der Dienst war aktiv. Danach warf ich einen Blick auf die ESX Firewall (Host > Configuration > Security Profile > Firewall > Settings). Damit wurde die Ursache schnell klar. (Thanks to Ivo Beerens, whose article gave me a hint to the solution)
Die Firewall des ESXi blockierte Verbindungen über UDP 514. Kein Kontakt – keine Logs – so einfach. 🙂
Der Haken bei syslog muss unbedingt gesetzt sein.
Schon wenige Augenblicke nach Übernahme der Regel füllte sich das Logverzeichnis auf dem Syslog Collector mit neuen Einträgen.
Das half zwar nicht bei der Lösung einer anderen Fragestellung mit dem VMware Support, jedoch können in Zukunft die Logs ausgelesen werden.
Ivo Beerens Blog – vSphere Syslog Collector troubleshooting
Eine Windows 7 VM machte Probleme mit einem Agenten, der dort installiert war. Das System hatte LAN Verbindung und konnte nach aussen pingen. Kontakt in die VM war nicht möglich. Im Windows Sicherheitscenter konnten keine Informationen zur Firewall abgerufen werden. Der Windows Firewall Dienst stand auf “automatic”, wurde aber nicht gestartet. Beim Versuch, diesen manuell zu starten erhielt ich folgende Fehlermeldung:
Windows could not start the Windows Firewall on Local Computer. For more information, review the System Event Log. If this is a non-Microsoft service, contact the service vendor, and refer to service-specific error code 5.
Erfreulicherweise hibt es hierzu einen Microsoft KB Artikel. Im selben Artikel der Knowledgebase findet sich auch ein FixIT, welches das Problem automatisch beheben kann.
Nach Ausführung des FixIT war die Firewall aktiv und man konnte Zugriffsregeln anpassen, sodass der Agent in der VM wieder kontaktiert werden konnte.