Wir empfehlen, aus Sicherheitsgründen bei der ersten Konfiguration das Root- und das Administrator-Passwort zu ändern (siehe „Authentifizierung >> Administrative Benutzer“ auf Seite 163). Solange dies noch nicht geschehen ist, erhalten Sie oben auf der Seite ei­nen Hinweis darauf.

System

Zustand der Stromver­sorgung 1/2

Zustand der beiden Netzteile (modellabhängig mit redundan­ter Stromversorgung)

Systemtemperatur (°C)

Wenn der angegebene Temperaturbereich unter- bzw. über­schritten wird, wird ein SNMP-Trap ausgelöst.

Systembenachrichti­gung

Frei wählbarer Text für eine Systembenachrichtigung, die vor einer Anmeldung am mGuard-Gerät angezeigt wird (maximal 1024 Zeichen). Wird angezeigt bei:

–Anmeldung per SSH-Login

–Anmeldung über die Web-Oberfläche (Web-UI).

Mithilfe eines geeigneten SSH-Clients kann das (wiederholte) Anzeigen der Benachrichtigung durch den Benutzer unter­bunden werden.

Werkseitige Voreinstellung:

The usage of this mGuard security appliance is reserved to authorized staff only. Any intrusion and its attempt without per­mission is illegal and strictly prohibited.

System DNS-Hostname

Hostnamen-Modus

Mit Hostnamen Modus und Hostname können Sie dem mGuard einen Namen geben. Dieser wird dann z. B. beim Einlog­gen per SSH angezeigt (siehe „Verwaltung >> Systemeinstel­lungen“ auf Seite 37, „Shell-Zugang“ auf Seite 46). Eine Namensgebung erleichtert die Administration mehrerer mGuards.

Benutzerdefiniert (siehe unten)

(Standard) Der im Feld Hostname eingetragene Name wird als Name für den mGuard gesetzt.

Arbeitet der mGuard im Stealth-Modus, muss als „Hostname-Modus“ die Option „Benutzer definiert“ gewählt werden.

Provider definiert (z. B. via DHCP)

Sofern der Netzwerk-Modus ein externes Setzen des Hostna­mens erlaubt wie z. B. bei DHCP, dann wird der vom Provider übermittelte Name für den mGuard gesetzt.

Hostname

Ist unter Hostnamen-Modus die Option „Benutzer definiert“ ausgewählt, dann tragen Sie hier den Namen ein, den der mGuard erhalten soll.

Domain-Suchpfad

Erleichtert dem Benutzer die Eingabe eines Domain-Namens: Gibt der Benutzer den Domain-Name gekürzt ein, ergänzt der mGuard seine Eingabe um den angegebenen Domain-Suffix, der hier unter „Domain-Suchpfad“ festgelegt wird.

SNMP-Information

Systemname

Ein für Verwaltungszwecke frei vergebbarer Name für den mGuard, z. B. „Hermes“, „Pluto“. (Unter SNMP: sysName)

Standort

Frei vergebbare Bezeichnung des Installationsortes, z. B. „Halle IV, Flur 3“, „Schaltschrank“. (Unter SNMP: sysLocation)

Kontakt

Angabe einer für den mGuard zuständigen Kontaktperson, am besten mit Telefonnummer. (Unter SNMP: sysContact)

Stellen Sie Zeit und Datum korrekt ein, da sonst der mGuard bestimmte zeitabhängige Aktivitäten nicht starten kann (siehe „Zeitabhängige Aktivitäten“ auf Seite 40).

Zeit und Datum

Sie können die Systemzeit des mGuards manuell einstellen und einer beliebigen Zeit­zone zuordnen oder die Synchronisation der Systemzeit mittels frei wählbarer NTP-Ser­ver vornehmen.

Verbundene Geräte können den mGuard ihrerseits als NTP-Server verwenden.

Bitte beachten Sie, dass aus Sicherheitsgründen die NTP-Version NTP v1 vom mGuard nicht unterstützt wird.

Zustand der System­zeit

Zeigt an, ob die Systemzeit des mGuards zur Laufzeit des mGuards einmal mit einer gültigen Zeit synchronisiert wurde.

Geräte ohne eingebaute Uhr starten immer „Nicht synchroni­siert“. Geräte, die eine eingebaute Uhr haben, starten in der Regel mit „Synchronisiert per eingebauter Uhr“.

Der Zustand der Uhr wechselt nur wieder auf „nicht synchroni­siert“, wenn die Firmware neu auf das Gerät aufgebracht wird oder die eingebaute Uhr zu lange vom Strom getrennt war.

Die Stromversorgung der eingebauten Uhr wird durch einen Akku sichergestellt. Der Akku hält mindestens fünf Tage.

Zeitabhängige Aktivitäten

–Zeitgesteuertes Holen der Konfiguration von einem Konfigurations-Server:

Dies ist der Fall, wenn unter dem Menüpunkt   „Verwaltung >> Zentrale Verwaltung“  , Konfiguration holen für die Einstellung Zeitplan die Einstellung Zeitgesteuert ausge­wählt ist (siehe „Verwaltung >> Konfigurationsprofile“ auf Seite 84, „Konfiguration ho­len“ auf Seite 102).

–Anerkennung von Zertifikaten, solange die Systemzeit noch nicht synchroni­siert ist:

Dies ist der Fall, wenn unter dem Menüpunkt „Authentifizierung >> Zertifikate“, „Zertifikatseinstellungen“ für die Option Beachte den Gültigkeitszeitraum von Zer­tifikaten und CRLs die Einstellung Warte auf Synchronisation der Systemzeit aus­gewählt ist (siehe „Authentifizierung >> Zertifikate“  und „Zertifikatseinstellungen“ auf Seite 179).

Die Systemzeit kann durch verschiedene Ereignisse gestellt oder synchronisiert werden:

–Synchronisiert per eingebauter Uhr: Der mGuard besitzt eine eingebaute Uhr, die mindestens einmal mit der aktuellen Zeit synchronisiert wurde. An der dortigen An­zeige lässt sich ablesen, ob sie synchronisiert ist. Eine synchronisierte eingebaute Uhr sorgt dafür, dass der mGuard auch nach einem Neustart eine synchronisierte Systemzeit hat.

–Manuell synchronisiert: Der Administrator hat zur Laufzeit dem mGuard die aktu­elle Zeit mitgeteilt, indem er im Feld   „Lokale Systemzeit einstellen“  eine entspre­chende Eingabe gemacht hat.

–Synchronisiert per Zeitmarke im Dateisystem: Der Administrator hat die Einstel­lung   „Zeitmarke im Dateisystem“   auf Ja gestellt und dem mGuard entweder per NTP (siehe unten unter NTP-Server) die aktuelle Systemzeit erfahren lassen oder per Eingabe in   „Lokale Systemzeit einstellen“   selbst eingestellt. Dann wird der mGuard auch ohne eingebaute Uhr nach einem Neustart sofort seine Systemzeit mit Hilfe des Zeitstempels synchronisieren. Eventuell wird die Zeit später per NTP ge­nauer eingestellt.

–Synchronisiert durch das Network Time Protocol NTP: Der Administrator hat un­ten unter   „NTP-Server“   die NTP-Zeitsynchronisation aktiviert und die Adressen von mindestens einem NTP-Server angegeben, und der mGuard hat erfolgreich Verbin­dung zu mindestens einem der festgelegten NTP-Server aufgenommen. Bei funktio­nierendem Netzwerk geschieht dies in wenigen Sekunden nach dem Neustart. Die Anzeige im Feld   „Status der NTP-Zeitsynchronisation“   wechselt eventuell erheb­lich später erst auf „synchronisiert“ (siehe dazu die Erklärung weiter unten zu   „Status der NTP-Zeitsynchronisation“ ).

Lokale Systemzeit ein­stellen

Hier können Sie die Zeit des mGuards setzen, falls kein NTP-Server eingestellt wurde oder aber der NTP-Server nicht erreichbar ist.

Das Datum und die Zeit werden in dem Format JJJJ.MM.TT-HH:MM:SS angegeben:

Zeitzone in POSIX.1-Notation

Soll die aktuelle Systemzeit nicht die mittlere Greenwich-Zeit anzeigen, sondern Ihre aktuelle Ortszeit (abweichend von der mittleren Greenwich-Zeit), dann tragen Sie hier ein, um wie viel Stunden bei Ihnen die Zeit voraus bzw. zurück ist.

Sie können Ihren Standort aus der Drop-Down-Liste auswäh­len (Sommer- und Winterzeit werden in der Regel automa­tisch berücksichtigt).

Alternativ können Sie die Einstellung manuell wie folgt vorneh­men:

Beispiele: In Berlin ist die Uhrzeit der mittleren Greenwich-Zeit um 1 Stunde voraus. Also tragen Sie ein: MEZ-1.

In New York geht die Uhr bezogen auf die mittlere Greenwich-Zeit um 5 Stunden nach. Also tragen Sie ein: MEZ+5.

Wichtig ist allein die Angabe -1, -2 oder +1 usw., weil nur sie ausgewertet wird; die davor stehenden Buchstaben nicht. Sie können „MEZ“ oder beliebig anders lauten, z. B. auch „UTC“.

Wünschen Sie die Anzeige der MEZ-Uhrzeit (= gültig für Deutschland) mit automatischer Umschaltung auf Sommer- bzw. Winterzeit geben Sie ein: MEZ-1MESZ,M3.5.0,M10.5.0/3

Zeitmarke im Datei­system

Ist diese Funktion aktiviert, schreibt der mGuard alle zwei Stunden die aktuelle Systemzeit in seinen Speicher.

Wird der mGuard aus- und wieder eingeschaltet, wird nach dem Einschalten eine Uhrzeit in diesem 2-Stunden-Zeitfens­ter angezeigt und nicht eine Uhrzeit am 1. Januar 2000.

NTP-Server

Der mGuard kann für externe Rechner als NTP-Server fungieren (NTP = Network Time Protocol). In diesem Fall sind die Rechner so zu konfigurieren, dass als Adresse des NTP-Servers die Adresse des mGuards angegeben ist.

In den Werkseinstellungen ist der NTP-Server des mGuard-Geräts deaktiviert. Nach dem Starten des NTP-Servers ist der Zugriff über das interne Interface (LAN-Interface) mög­lich. Über Firewall-Regeln kann der Zugriff über alle verfügbaren Interfaces freigegeben oder beschränkt werden.

Wenn der mGuard im Stealth-Modus betrieben wird, muss bei den Rechnern die Management IP-Adresse des mGuards verwendet werden (sofern diese konfiguriert ist), oder es muss die IP-Adresse 1.1.1.1 als lokale Adresse des mGuards angegeben wer­den.

Damit der mGuard als NTP-Server fungieren kann, muss er selber das aktuelle Datum und die aktuelle Uhrzeit von einem NTP-Server (= Zeit-Server) beziehen. Dazu muss die Adresse von mindestens einem NTP-Server angegeben werden. Zusätzlich muss dieses Feature aktiviert sein.

Aktiviere NTP-Zeit­synchronisation

Ist diese Funktion aktiviert, bezieht der mGuard Datum und Uhrzeit von einem oder mehreren Zeit-Server(n) und synchro­nisiert sich mit ihm bzw. ihnen.

Die initiale Zeitsynchronisation kann bis zu 15 Minuten dau­ern. Während dieser Zeitspanne vollzieht der mGuard immer wieder Vergleiche zwischen der Zeitangabe des externen Zeit-Servers und der eigenen Uhrzeit, um diese so präzise wie möglich abzustimmen. Erst dann kann der mGuard als NTP-Server für die an seiner LAN-Schnittstelle angeschlossenen Rechner fungieren und ihnen die Systemzeit liefern.

Nach der initialen Zeitsynchronisation vergleicht der mGuard regelmäßig die batteriegepufferte Systemzeit mit den Zeit-Servern. In der Regel erfolgen Nachjustierungen nur noch im Sekundenbereich.

Status der NTP-Zeit­synchronisation

Anzeige des aktuellen NTP-Status.

Gibt an, ob sich der auf dem mGuard selbst laufende NTP-Server mit hinreichender Genauigkeit mit den konfigurierten NTP-Servern synchronisiert hat.

Wenn die Systemuhr des mGuards vor der Aktivierung der NTP-Zeitsynchronisation noch nie synchronisiert war, kann die Synchronisierung bis zu 15 Minuten dauern. Dennoch stellt der NTP-Server die Systemuhr des mGuards nach weni­gen Sekunden auf die aktuelle Zeit um, sobald er erfolgreich einen der konfigurierten NTP-Server kontaktiert hat. Dann be­trachtet der mGuard seine Systemzeit auch bereits als syn­chronisiert. Nachjustierungen erfolgen in der Regel nur noch im Sekundenbereich.

‘discard minimum 1‘

Die Aktivierung dieser Option kann die Zeitsynchronisation mit einigen NTP-Clients, insbesondere von SPS-Systemen, verbessern.

Zusätzlich sollte das Aktualisierungsintervall auf dem SPS-System auf den maximal möglichen Wert erhöht werden (z. B. 86400 Sekunden).

NTP-Server

Geben Sie hier einen oder mehrere Zeit-Server an, von denen der mGuard die aktuelle Zeitangabe beziehen soll. Falls Sie mehrere Zeit-Server angeben, verbindet sich der mGuard au­tomatisch mit allen, um die aktuelle Zeit zu ermitteln.

Über VPN

Die Anfrage des NTP-Servers wird, wenn möglich, über einen VPN-Tunnel durchgeführt.

Bei aktivierter Funktion wird die Kommunikation mit dem Ser­ver immer dann über einen verschlüsselten VPN-Tunnel ge­führt, wenn ein passender VPN-Tunnel verfügbar ist.

Erlaubte Netzwerke für NTP-Zugriff

(Bei aktivierter Funktion „Aktiviere NTP-Zeitsynchronisation“)

Wenn die Funktion Aktiviere NTP-Zeitsynchronisation aktiviert ist, können externe Ge­räte auf den NTP-Server des mGuards zugreifen. Der Zugriff ist standardmäßig nur über das interne LAN-Interface (Intern) möglich.

Sind keine Regeln gesetzt oder greift keine Regel, gelten folgende Standardeinstellun­gen:

–NTP-Zugriffe über Intern sind erlaubt.

–NTP-Zugriffe über Extern, DMZ und VPN werden verwehrt.

Legen Sie die Überwachungsmöglichkeiten nach Bedarf fest.

Die Tabelle listet eingerichtete Firewall-Regeln auf. Sie gelten für eingehende Datenpa­kete eines NTP-Zugriffs. Sind mehrere Firewall-Regeln gesetzt, werden diese in der Rei­henfolge der Einträge von oben nach unten abgefragt, bis eine passende Regel gefunden wird. Diese wird dann angewandt. Sollten nachfolgend in der Regelliste weitere Regeln vorhanden sein, die auch passen würden, werden diese ignoriert.

Von IP

Geben Sie hier die Adresse des Rechners oder Netzes an, von dem der Zugriff erlaubt beziehungsweise verboten ist.

Bei den Angaben haben Sie folgende Möglichkeiten:

–Eine IP-Adresse.

–Um einen Bereich anzugeben, benutzen Sie die CIDR-Schreibweise (siehe „CIDR (Classless Inter-Domain Rou­ting)“ auf Seite 34).

–0.0.0.0/0 bedeutet alle Adressen.

Interface

Intern / Extern / DMZ / VPN

Gibt an, für welches Interface die Regel gelten soll.

Sind keine Regeln gesetzt oder greift keine Regel, gelten fol­gende Standardeinstellungen:

–NTP-Zugriffe über Intern sind erlaubt.

–NTP-Zugriffe über Extern, DMZ und VPN werden ver­wehrt.

Legen Sie die Überwachungsmöglichkeiten nach Bedarf fest.

Aktion

Annehmen bedeutet, dass die Datenpakete passieren dür­fen.

Abweisen bedeutet, dass die Datenpakete zurückgewiesen werden, so dass der Absender eine Information über die Zu­rückweisung erhält. (Im Stealth-Modus hat Abweisen dieselbe Wirkung wie Verwerfen.)

Verwerfen bedeutet, dass die Datenpakete nicht passieren dürfen. Sie werden verschluckt, so dass der Absender keine Information über deren Verbleib erhält.

Kommentar

Ein frei wählbarer Kommentar für diese Regel.

Log

Für jede einzelne Firewall-Regel können Sie festlegen, ob bei Greifen der Regel

–das Ereignis protokolliert werden soll – Funktion Log akti­vieren oder

–das Ereignis nicht protokolliert werden soll – Funktion Log deaktivieren (werkseitige Voreinstellung).

Die Konfiguration des mGuards darf nicht gleichzeitig über den Web-Zugriff, den Shell-Zugang oder SNMP erfolgen. Eine zeitgleiche Konfiguration über die verschiedenen Zu­gangsmethoden führt möglicherweise zu unerwarteten Ergebnissen.

Shell-Zugang

Sie können den mGuard über die Web-Oberfläche oder über die Kommandozeile (Shell) konfigurieren. Der Zugriff auf die Kommandozeile erfolgt über SSH.

Bei aktiviertem SSH-Fernzugang kann der mGuard von entfernten Rechnern aus über die Kommandozeile konfiguriert werden. Der SSH-Fernzugang ist standardmäßig deaktiviert. Er kann aktiviert und auf ausgewählte Netzwerke beschränkt werden.

Aktiviere SSH-Fernzu­gang

Aktivieren Sie die Funktion, um SSH-Fernzugriff zu ermögli­chen.

Um Zugriffsmöglichkeiten auf den mGuard differenziert fest­zulegen, müssen Sie die Firewall-Regeln für die verfügbaren Interfaces entsprechend definieren (siehe „Erlaubte Netz­werke“ auf Seite 51).

Erlaube SSH-Zugang als Benutzer root

Standard: aktiviert

Bei aktivierter Funktion kann sich der Benutzer „root“ via SSH-Zugang auf dem Gerät anmelden.

Port für eingehende SSH-Verbindungen (nur Fernzugang)

(Nur wenn SSH-Fernzugang aktiviert ist)

Standard: 22

Wird diese Port-Nummer geändert, gilt die geänderte Port-Nummer nur für Zugriffe über das Interface Extern, DMZ und VPN.

Für internen Zugriff gilt weiterhin Port 22.

Die entfernte Gegenstelle, die den Fernzugriff ausübt, muss beim Login gegebenenfalls die Port-Nummer angeben, die hier festgelegt ist.

Beispiel:

Ist dieser mGuard über die Adresse 123.124.125.21 über das Internet zu erreichen, und ist für den Fernzugang gemäß Stan­dard die Port-Nummer 22 festgelegt, dann muss bei der ent­fernten Gegenstelle im SSH-Client (z. B. PuTTY oder OpenSSH) diese Port-Nummer evtl. nicht angegeben wer­den.

Bei einer anderen Port-Nummer (z. B. 2222) ist diese anzuge­ben, z. B.: ssh -p 2222 123.124.125.21

Ablauf der Sitzung

Gibt an, nach wie viel Zeit (in hh:mm:ss) der Inaktivität die Sit­zung automatisch beendet wird, d. h. ein automatisches Aus­loggen stattfindet. Bei Einstellung von 0 (= Werkseinstellung) findet kein automatisches Beenden der Sitzung statt.

Die Wirkung der Einstellung des Feldes „Ablauf der Sitzung“ wird vorübergehend ausgesetzt, wenn die Bearbeitung eines Shell-Kommandos die eingestellte Anzahl von Sekunden überschreitet.

Im Unterschied hierzu kann die Verbindung auch abgebro­chen werden, wenn die Funktionsfähigkeit der Verbindung nicht mehr gegeben ist, siehe „Verzögerung bis zur nächsten Anfrage nach einem Lebenszeichen“ auf Seite 49.

Verzögerung bis zur nächsten Anfrage nach einem Lebens­zeichen

Standard: 120 Sekunden (0:02:00)

Einstellbar sind Werte von 0 Sekunden bis 1 Stunde. Positive Werte bedeuten, dass der mGuard innerhalb der verschlüs­selten SSH-Verbindung eine Anfrage an die Gegenstelle sen­det, ob sie noch erreichbar ist. Die Anfrage wird gesendet, wenn für die angegebene Anzahl von Sekunden keine Aktivi­tät von der Gegenstelle bemerkt wurde (zum Beispiel durch Netzwerkverkehr innerhalb der verschlüsselten Verbindung).

Der Wert 0 bedeutet, dass keine Anfragen nach einem Le­benszeichen gesendet werden.

Der hier eingetragene Wert bezieht sich auf die Funktionsfä­higkeit der verschlüsselten SSH-Verbindung. Solange diese gegeben ist, wird die SSH-Verbindung vom mGuard wegen dieser Einstellungen nicht beendet, selbst wenn der Benutzer während dieser Zeit keine Aktion ausführt.

Da die Anzahl der gleichzeitig geöffneten Sitzungen begrenzt ist, ist es wichtig, abgelaufene Sitzungen zu beenden (siehe   „Maximale Anzahl gleichzeitiger Sitzungen pro Rolle“ auf Seite 50  ).

Deshalb wird die Anfrage nach einem Lebenszeichen auf 120 Sekunden voreingestellt. Bei maximal drei Anfragen nach einem Lebenszeichen, wird eine abgelaufene Sitzung nach sechs Minuten entdeckt und entfernt. In vorherigen Versionen war die Voreinstellung „0“.

Wenn es wichtig ist, dass kein zusätzlicher Traffic erzeugt wird, können Sie den Wert anpassen. Bei der Einstellung „0“ in Kombination mit der Begrenzung gleichzeitiger Sitzungen kann es geschehen, dass ein weiterer Zugriff blockiert wird, wenn zu viele Sitzungen durch Netzwerkfehler unterbrochen aber nicht geschlossen wurden.

Die Eingabe kann aus Sekunden [ss], Minuten und Sekunden [mm:ss] oder Stunden, Minuten und Sekunden [hh:mm:ss] bestehen.

Maximale Anzahl aus­bleibender Lebenszei­chen

Gibt an, wie oft Antworten auf Anfragen nach Lebenszeichen der Gegenstelle ausbleiben dürfen.

Wenn z. B. alle 15 Sekunden nach einem Lebenszeichen ge­fragt werden soll und dieser Wert auf 3 eingestellt ist, dann wird die SSH-Verbindung gelöscht, wenn nach circa 45 Se­kunden immer noch kein Lebenszeichen gegeben wurde.

SSH und HTTPS Schlüssel erneuern

Generiere neue 2048 bit Schlüssel

Schlüssel, die mit einer älteren Firmware erstellt worden sind, sind möglicherweise schwach und sollten erneuert werden.

•Klicken Sie auf diese Schaltfläche, um neue Schlüssel zu er­zeugen.

•Beachten Sie die Fingerprints der neu generierten Schlüssel.

•Loggen Sie sich über HTTPS ein und vergleichen Sie die Zer­tifikat-Informationen, die vom Web-Browser zur Verfügung gestellt werden.

Maximale Anzahl gleichzei­tiger Sitzungen pro Rolle

Sie können die Anzahl der Benutzer begrenzen, die gleichzeitig auf die Kommandozeile des mGuards zugreifen dürfen. Der Benutzer „root“ hat immer uneingeschränkten Zu­gang. Die Anzahl der Zugänge für administrative Benutzerrollen (admin, netadmin, audit) können jeweils einzeln begrenzt werden.

Die Berechtigungsstufen netadmin und audit beziehen sich auf Zugriffsrechte bei Zugrif­fen mit dem mGuard device manager (FL MGUARD DM UNLIMITED) . Die Einschrän­kung hat keine Auswirkung auf bereits bestehende Sitzungen, sondern nur auf neu auf­gebaute Zugriffe.

Pro Sitzung werden ca. 0,5 MB Speicherplatz benötigt.

Admin

2 bis 2147483647

Für die Rolle „admin“ sind mindestens 2 gleichzeitig erlaubte Sitzungen erforderlich, damit sich „admin“ nicht selbst aus­sperrt.

Netadmin

0 bis 2147483647

Bei „0“ ist keine Sitzung erlaubt. Es kann sein, dass der Benut­zer „netadmin“ nicht verwendet wird.

Audit

0 bis 2147483647

Bei „0“ ist keine Sitzung erlaubt. Es kann sein, dass der Benut­zer „audit“ nicht verwendet wird.

Erlaubte Netzwerke

Sie können den SSH-Zugriff auf die Kommandozeile des mGuards mittels Firewall-Re­geln auf ausgewählte Interfaces und Netzwerke beschränken.

Die Regeln gelten für eingehende Datenpakete und können geräteabhängig für alle Inter­faces konfiguriert werden.

Sind mehrere Firewall-Regeln gesetzt, werden diese in der Reihenfolge der Einträge von oben nach unten abgefragt, bis eine passende Regel gefunden wird. Diese wird dann an­gewandt. Sollten nachfolgend in der Regelliste weitere Regeln vorhanden sein, die auch passen würden, werden diese ignoriert.

Bei den Angaben haben Sie folgende Möglichkeiten:

Von IP

Geben Sie hier die Adresse des Rechners oder Netzes an, von dem der Zugang erlaubt beziehungsweise verboten ist.

Bei den Angaben haben Sie folgende Möglichkeiten:

IP-Adresse: 0.0.0.0/0 bedeutet alle Adressen. Um einen Be­reich anzugeben, benutzen Sie die CIDR-Schreibweise, siehe „CIDR (Classless Inter-Domain Routing)“ auf Seite 34.

Interface

Intern / Extern / DMZ / VPN

Gibt an, für welches Interface die Regel gelten soll.

Sind keine Regeln gesetzt oder greift keine Regel, gelten fol­gende Standardeinstellungen: 

–SSH-Zugriffe über Intern und VPN sind erlaubt.

–SSH-Zugriffe über Extern und DMZ werden verwehrt.

Legen Sie die Zugriffsmöglichkeiten nach Bedarf fest.

Aktion

Möglichkeiten:

–Annehmen bedeutet, die Datenpakete dürfen passieren.

–Abweisen bedeutet, die Datenpakete werden zurückge­wiesen, so dass der Absender eine Information über die Zurückweisung erhält. (Im Stealth-Modus hat Abweisen dieselbe Wirkung wie Verwerfen.)

–Verwerfen bedeutet, die Datenpakete dürfen nicht pas­sieren. Sie werden verschluckt, so dass der Absender keine Information über deren Verbleib erhält.

Kommentar

Ein frei wählbarer Kommentar für diese Regel.

Log

Für jede einzelne Firewall-Regel können Sie festlegen, ob bei Greifen der Regel

–das Ereignis protokolliert werden soll – Funktion Log akti­vieren

–oder das Ereignis nicht protokolliert werden soll – Funkti­on Log deaktivieren (werkseitige Voreinstellung).

RADIUS-Authentifizierung

Benutzer können bei ihrer Anmeldung über einen RADIUS-Server authentifiziert werden. Dies gilt für Anwender, die über den Shell-Zugang mit Hilfe von SSH auf den mGuard zu­greifen wollen. Bei den vordefinierten Benutzern (root, admin, netadmin und audit) wird das Passwort lokal geprüft.

Nutze RADIUS-Authentifizierung für den Shell-Zugang

Ja / Nein / Als einzige Methode zur Passwortprüfung

Bei Nein wird das Passwort der Benutzer, die sich über den Shell-Zugang einloggen, über die lokale Datenbank auf dem mGuard geprüft.

Wählen Sie Ja, damit Benutzer über einen RADIUS-Server authentifiziert werden. Dies gilt für Anwender, die über den Shell-Zugang mit Hilfe von SSH auf den mGuard zugreifen wollen. Nur bei den vordefinierten Benutzern (root, admin, netadmin, audit) wird das Passwort lokal geprüft.

Die Berechtigungsstufen netadmin und audit beziehen sich auf Zugriffsrechte bei Zugriffen mit dem mGuard device manager (FL MGUARD DM UNLIMITED) .

Wenn Sie unter   „X.509-Authentifizierung“   den Punkt   „Un­terstütze X.509-Zertifikate für den SSH-Zugang“   auf Ja stellen, kann alternativ das X.509-Authentifizierungsverfahren verwendet werden. Welches Verfahren von einem Benutzer tatsächlich verwendet wird, hängt davon ab, wie er seinen SSH-Client verwendet.

Wenn Sie eine RADIUS-Authentifizierung das erste Mal ein­richten, wählen Sie Ja.

Wenn Sie planen, die RADIUS-Authentifizierung als einzige Methode zur Passwortprüfung einzurichten, empfehlen wir Ihnen, ein „Customized Default Profile“ anzulegen, das die Authentifizierungsmethode zurücksetzt.

Die vordefinierten Benutzer (root, admin, netadmin und audit) können sich dann nicht mehr per SSH beim mGuard anmel­den.

X.509-Authentifizierung

X.509-Zertifikate für den SSH-Clienten

Der mGuard unterstützt die Authentifizierung von SSH-Clienten mit Hilfe von X.509-Zer­tifikaten. Es reicht aus, CA-Zertifikate zu konfigurieren, die für einen Aufbau und die Gül­tigkeitsprüfung einer Zertifikatskette notwendig sind. Diese Zertifikatskette muss dazu zwischen dem CA-Zertifikat beim mGuard und dem X.509.Zertifikat, das beim SSH-Clienten vorgezeigt wird, bestehen (siehe „Shell-Zugang“ auf Seite 46).

Wenn der Gültigkeitszeitraum des Client-Zertifikats vom mGuard geprüft wird (siehe „Zertifikatseinstellungen“ auf Seite 179), dann müssen irgendwann neue CA-Zertifikate am mGuard konfiguriert werden. Dies muss geschehen, bevor die SSH-Clienten ihre neuen Client-Zertifikate nutzen.

Wenn die CRL-Prüfung eingeschaltet ist (unter „Authentifizierung >> Zertifikate >> Zerti­fikatseinstellungen“), dann muss eine URL pro CA-Zertifikat vorgehalten werden, an der die entsprechende CRL verfügbar ist. Die URL und CRL müssen veröffentlicht werden, bevor der mGuard die CA-Zertifikate nutzt, um die Gültigkeit der von den VPN-Partnern vorgezeigten Zertifikate zu bestätigen.

Unterstütze X.509-Zer­tifikate für den SSH-Zugang

Ist die Funktion deaktiviert, werden zur Authentifizierung nur die herkömmlichen Authentifizierungsverfahren (Benut­zername und Passwort bzw. privater und öffentlicher Schlüs­sel) erlaubt, nicht das X.509-Authentifizierungsverfahren.

Ist die Funktion aktiviert, kann zur Authentifizierung zusätz­lich zum herkömmlichen Authentifizierungsverfahren (wie es auch bei deaktivierter Funktion verwendet wird) das X.509-Authentifizierungsverfahren verwendet werden.

Bei aktivierter Funktion ist festzulegen,

–wie sich der mGuard gemäß X.509 beim SSH-Client au­thentisiert, siehe SSH Server-Zertifikat (1)

–wie der mGuard den entfernten SSH-Client gemäß X.509 authentifiziert, siehe SSH Server-Zertifikat (2)

SSH-Server-Zertifikat (1)

Legt fest, wie sich der mGuard beim SSH-Client aus­weist.

In der Auswahlliste eines der Maschinenzertifikate auswählen oder den Eintrag Keines.

Keines

Bei Auswahl von Keines authentisiert sich der SSH-Server des mGuards nicht per X.509-Zertifikat gegenüber dem SSH-Client, sondern er benutzt einen Server-Schlüssel und verhält sich damit so wie ältere Versionen des mGuards.

Wird eines der Maschinenzertifikate ausgewählt, wird dem SSH-Client das zusätzlich angeboten, so dass dieser es sich aussuchen kann, ob er das herkömmliche Authentifizierungs­verfahren oder das gemäß X.509 anwenden will.

Die Auswahlliste stellt die Maschinenzertifikate zur Wahl, die in den mGuard unter Menüpunkt   „Authentifizierung >> Zertifi­kate“   geladen worden sind (siehe Seite 174).

SSH-Server-Zertifikat (2)

Legt fest wie der mGuard den SSH-Client authentifiziert

Nachfolgend wird festgelegt, wie der mGuard die Authentizität des SSH-Clients prüft.

Die Tabelle unten zeigt, welche Zertifikate dem mGuard zur Authentifizierung des SSH-Clients zur Verfügung stehen müs­sen, wenn der SSH-Client bei Verbindungsaufnahme eines der folgenden Zertifikatstypen vorzeigt:

–ein von einer CA signiertes Zertifikat

–ein selbst signiertes Zertifikat

Zum Verständnis der nachfolgenden Tabelle siehe Kapi­tel „Authentifizierung >> Zertifikate“ .

Die Gegenstelle zeigt vor:

Zertifikat (personenbezogen) von CA signiert

Zertifikat (personenbezo­gen) selbst signiert

Der mGuard authentifi­ziert die Gegenstelle anhand von...

...allen CA-Zertifikaten, die mit dem von der Gegenstelle vorgezeigten Zertifikat die Kette bis zum Root-CA-Zerti­fikat bilden

ggf. PLUS

Client-Zertifikaten (Gegen­stellen-Zertifikaten), wenn sie als Filter verwendet wer­den

Client-Zertifikat (Gegen­stellen-Zertifikat)

Ist unter Menüpunkt   „Authentifizierung >> Zertifikate“   , Zertifikatseinstellungen die Ver­wendung von Sperrlisten (= CRL-Prüfung) aktiviert, wird jedes von einer CA signierte Zer­tifikat, das SSH-Clients „vorzeigen“, auf Sperrung geprüft.

Authentifizierung mit­tels CA-Zertifikat

Die Konfiguration ist nur dann erforderlich, wenn der SSH-Cli­ent ein von einer CA signiertes Zertifikat vorzeigt.

Es sind alle CA-Zertifikate zu konfigurieren, die der mGuard benötigt, um mit den von SSH-Clients vorgezeigten Zertifika­ten jeweils die Kette bis zum jeweiligen Root-CA-Zertifikat zu bilden.

Die Auswahlliste stellt die CA-Zertifikate zur Wahl, die in den mGuard unter Menüpunkt   „Authentifizierung >> Zertifikate“   geladen worden sind.

Zugriffsberechtigung mittels X.509-Subject

Ermöglicht die Filtersetzung in Bezug auf den Inhalt des Fel­des Subject im Zertifikat, das vom SSH-Client vorgezeigt wird. Dadurch ist es möglich, den Zugriff von SSH-Clients, die der mGuard auf Grundlage von Zertifikatsprüfungen im Prinzip ak­zeptieren würde, zu beschränken bzw. freizugeben:

–Beschränkung auf bestimmte Subjects (d. h. Personen) und/oder auf Subjects, die bestimmte Merkmale (Attribu­te) haben, oder

–Freigabe für alle Subjects (siehe Glossar unter   „Subject, Zertifikat“ auf Seite 337 ).

Freigabe für alle Subjects (d. h. Personen):

Mit * (Sternchen) im Feld X.509-Subject legen Sie fest, dass im vom SSH-Client vorge­zeigten Zertifikat beliebige Subject-Einträge erlaubt sind. Dann ist es überflüssig, das im Zertifikat jeweils angegebene Subject zu kennen oder festzulegen.

Beschränkung auf bestimmte Subjects (d. h. Personen) oder auf Subjects, die be­stimmte Merkmale (Attribute) haben:

Im Zertifikat wird der Zertifikatsinhaber im Feld Subject angegeben, dessen Eintrag sich aus mehreren Attributen zusammensetzt. Diese Attribute werden entweder als Object Identifier ausgedrückt (z. B.: 132.3.7.32.1) oder, geläufiger, als Buchstabenkürzel mit einem entsprechenden Wert.

Beispiel: CN=Max Muster, O=Fernwartung GmbH, C=DE

Sollen bestimmte Attribute des Subjects ganz bestimmte Werte haben, damit der mGuard den SSH-Client akzeptiert, muss das entsprechend spezifiziert werden. Die Werte der anderen Attribute, die beliebig sein können, werden dann durch das Wildcard * (Sternchen) angegeben.

Beispiel: CN=*, O=*, C=DE    (mit oder ohne Leerzeichen zwischen Attributen)

Bei diesem Beispiel müsste im Zertifikat im Subject das Attribut „C=DE“ stehen. Nur dann würde der mGuard den Zertifikatsinhaber (= Subject) als Kommunikationspartner akzep­tieren. Die anderen Attribute könnten in den zu filternden Zertifikaten beliebige Werte ha­ben.

Für den Zugriff autori­siert als

Alle Benutzer / root / admin / netadmin / audit

Zusätzlicher Filter, der festlegt, dass der SSH-Client für eine bestimmte Verwaltungsebene autorisiert sein muss, um Zu­griff zu erhalten.

Der SSH-Client zeigt bei Verbindungsaufnahme nicht nur sein Zertifikat vor, sondern gibt auch den Systembenutzer an, für den die SSH-Sitzung eröffnet werden soll (root, admin, netadmin, audit). Nur wenn diese Angabe mit der überein­stimmt, die hier festgelegt wird, erhält er Zugriff.

Mit der Einstellung Alle Benutzer ist der Zugriff für jeden der vorgenannten Systembenutzer möglich.

Authentifizierung mit­tels Client-Zertifikat

Die Konfiguration ist in den folgenden Fällen erforderlich:

–SSH-Clients zeigen jeweils ein selbst signiertes Zertifikat vor.

–SSH-Clients zeigen jeweils ein von einer CA signiertes Zertifikat vor. Es soll eine Filterung erfolgen: Zugang er­hält nur der, dessen Zertifikats-Kopie im mGuard als Ge­genstellen-Zertifikat installiert ist und in dieser Tabelle dem mGuard als Client-Zertifikat zur Verfügung gestellt wird.

Dieser Filter ist dem Subject-Filter darüber nicht nachge­ordnet, sondern ist auf gleicher Ebene angesiedelt, ist also dem Subject-Filter mit einem logischen ODER beige­ordnet.

Der Eintrag in diesem Feld legt fest, welches Client-Zertifikat (Gegenstellen-Zertifikat) der mGuard heranziehen soll, um die Gegenstelle, den SSH-Client, zu authentifizieren.

Dazu in der Auswahlliste eines der Client-Zertifikate auswäh­len. Die Auswahlliste stellt die Client-Zertifikate zur Wahl, die in den mGuard unter Menüpunkt   „Authentifizierung >> Zertifi­kate“   geladen worden sind.

Für den Zugriff autori­siert als

Alle Benutzer / root / admin / netadmin / audit

Filter, der festlegt, dass der SSH-Client für eine bestimmte Verwaltungsebene autorisiert sein muss, um Zugriff zu erhal­ten.

Der SSH-Client zeigt bei Verbindungsaufnahme nicht nur sein Zertifikat vor, sondern gibt auch den Systembenutzer an, für den die SSH-Sitzung eröffnet werden soll (root, admin, netadmin, audit). Nur wenn diese Angabe mit der überein­stimmt, die hier festgelegt wird, erhält er Zugriff.

Mit der Einstellung Alle Benutzer ist der Zugriff für jeden der vorgenannten Systembenutzer möglich.

E-Mail

(Achten Sie auf die korrekte Konfigura­tion der E-Mail-Einstellungen des mGuards)

Sie können den mGuard für die Versendung von E-Mails über einen E-Mail-Server konfi­gurieren. Bestimmte Ereignisse können damit im Falle ihres Eintretens an frei wählbare Empfänger im Klartext oder in maschinenlesbarer Form versendet werden.

Absenderadresse von E-Mail-Benachrichti­gungen

E-Mail-Adresse, die als Absender vom mGuard angezeigt wird.

Adresse des E-Mail-Servers

Adresse des E-Mail-Servers

Port-Nummer des E-Mail-Servers

Port-Nummer des E-Mail-Servers

Verschlüsselungs­modus für den E-Mail-Server

Keine Verschlüsselung / TLS-Verschlüsselung / TLS-Ver­schlüsselung mit StartTLS

Verschlüsselungsmodus für den E-Mail-Server

SMTP-Benutzerken­nung

Benutzerkennung (Login)

SMTP-Passwort

Passwort für den E-Mail-Server

E-Mail-Benachrichtigungen

Es können beliebige E-Mail-Empfänger mit vordefinierten Ereignissen und einer frei defi­nierbaren Nachricht verknüpft werden. Die Liste wird von oben nach unten abgearbeitet.

E-Mail-Empfänger

Legt eine E-Mail-Adresse an.

Ereignis

Wenn das ausgewählte Ereignis eintritt oder das Ereignis das erste Mal konfiguriert wird, wird die damit verknüpfte Empfän­geradresse angewählt und an diese wird das Ereignis als E-Mail geschickt.

Zusätzlich kann eine E-Mail-Nachricht hinterlegt und gesen­det werden. Manche der aufgelisteten Ereignisse sind abhän­gig von der verwendeten Hardware.

Eine vollständige Liste aller Ereignisse finden Sie unter „Ereig­nistabelle“ auf Seite 62.

Selektor

Hier kann eine konfigurierte VPN-Verbindung ausgewählt werden, die per E-Mail überwacht wird.

E-Mail-Betreff

Text erscheint in der Betreff-Zeile der E-Mail

Der Text ist frei definierbar. Sie können Bausteine aus der Er­eignistabelle verwenden, die als Platzhalter in Klartext (\A und \V) oder in maschinenlesbarer Form (\a und \v) eingefügt wer­den können. Zeitstempel in Form eines Platzhalters (\T bzw. \t (maschinenlesbar)) können ebenfalls eingefügt werden.

E-Mail-Nachricht

Sie können hier den Text eingeben, der als E-Mail verschickt wird.

Der Text ist frei definierbar. Sie können Bausteine aus der Er­eignistabelle verwenden, die als Platzhalter in Klartext (\A und \V) oder in maschinenlesbarer Form (\a und \v) eingefügt wer­den können. Zeitstempel in Form eines Platzhalters in Klartext (\T) oder maschinenlesbar (\t) können ebenfalls eingefügt werden.

Montag, April 22 2016 13:22:36

2016-04-22T11:22:36+0200

Zustand des ECS

Nicht vorhanden

/ecs/status 

1

Entfernt

2

Vorhanden und synchronisiert

3

Nicht synchronisiert

4

Allgemeiner Fehler

8

Ergebnis der Konnektivi­tätsprüfung des internen Interface

Konnektivitätsprüfung erfolgreich

/redun­dancy/cc/int/ok

yes

Konnektivitätsprüfung fehlgeschlagen

no

Ergebnis der Konnektivi­tätsprüfung des externen Interface

Konnektivitätsprüfung erfolgreich

/redun­dancy/cc/ext/ok

yes

Konnektivitätsprüfung fehlgeschlagen

no

Zustand des Alarmaus­gangs

Alarmausgang geschlossen / high [OK]

/ihal/contact 

close

Alarmausgang ist offen / low [FEHLER]

open

Aktivierungsgrund des Alarmausgangs

Kein Alarm

/ihal/contactreason

Keine Verbindung am externen Interface

link_ext

Keine Verbindung am internen Interface

link_int

Stromversorgung 1 defekt

psu1

Stromversorgung 2 defekt

psu2

Boardtemperatur außerhalb des konfigurier­ten Bereichs

temp

Redundanz-Konnektivitätsprüfung fehlge­schlagen

ccheck

Keine Verbindung am XF2-Interface

link_swp0

Keine Verbindung am XF3-Interface

link_swp1

Keine Verbindung am XF4-Interface

link_swp2

Keine Verbindung am XF5-Interface

link_swp3

Keine Verbindung am DMZ-Interface

link_dmz

Passwörter nicht konfiguriert

password

Zustand der Stromversor­gung 1

Stromversorgung 1 bereit

/ihal/power/psu1

ok

Stromversorgung 1 defekt

fail

Zustand der Stromversor­gung 2

Stromversorgung 2 bereit

/ihal/power/psu2

ok

Stromversorgung 2 defekt

fail

Zustand des Eingangs/ CMD 1 (I1)

Service Eingang/CMD1 (I1) aktiviert

/ihal/service/cmd1

on

Service Eingang/CMD1 (I1) deaktiviert

off

Zustand des Eingangs/ CMD 2 (I2)

Service Eingang/CMD2 (I2) aktiviert

/ihal/service/cmd2

on

Service Eingang/CMD2 (I2) deaktiviert

off

Zustand des Eingangs/ CMD 3 (I3)

Service Eingang/CMD3 (I3) aktiviert

/ihal/service/cmd3

on

Service Eingang/CMD3 (I3) deaktiviert

off

Temperaturzustand des Gerätes

Temperatur OK

/ihal/tempera­ture/board_alarm

ok

Temperatur zu heiß

hot

Temperatur zu kalt

cold

Zustand der Redundanz

Die Redundanzsteuerung startet

/redundancy/status

booting

Keine hinreichende Netzwerkanbindung

faulty

Keine hinreichende Netzwerkanbindung und wartet auf eine Komponente

faulty_waiting

Synchronisiert sich mit aktivem Gerät

outdated

Synchronisiert sich mit aktivem Gerät und war­tet auf eine Komponente

outdated_waiting

In Bereitschaft

on_standby

In Bereitschaft und wartet auf eine Kompo­nente

on_standby_waiting

Wird aktiv

becomes_active

Leitet Netzwerkverkehr weiter

active

Leitet Netzwerkverkehr weiter und wartet auf eine Komponente

active_waiting

Aktivierungszustand der IPsec VPN-Verbindung

Gestoppt

/vpn/con/*/armed

no

Gestartet

yes

IPsec-SA-Status der VPN-Verbindung

Keine IPsec-SAs aufgebaut

/vpn/con/*/ipsec

down

Nicht alle IPsec-SAs aufgebaut

some

Alle IPsec-SAs aufgebaut

up

Aktivierungszustand des Firewall-Regelsatzes

Der Zustand der Firewall-Regelsätze hat sich geändert.

/fwrules/*/state

inactive

active

Aktivierungszustand der OpenVPN-Verbindung

Gestoppt

/openvpn/con/*/ar­med

no

Gestartet

yes

Status der OpenVPN-Ver­bindung

Getrennt

/openvpn/con/*/state

down

Aufgebaut

up

Allgemein

Sprache

Ist in der Sprachauswahlliste Automatisch ausgewählt, über­nimmt das Gerät die Spracheinstellung aus dem Web-Browser des Rechners.

Ablauf der Sitzung

Zeit der Inaktivität, nach denen der Benutzer von der Web-Schnittstelle des mGuards automatisch abgemeldet wird. Mögliche Werte: 15 bis 86400 Sekunden (= 24 Stunden)

Die Eingabe kann aus Sekunden [ss], Minuten und Sekunden [mm:ss] oder Stunden, Minuten und Sekunden [hh:mm:ss] bestehen.

Die Konfiguration des mGuards darf nicht gleichzeitig über den Web-Zugriff, den Shell-Zugang oder SNMP erfolgen. Eine zeitgleiche Konfiguration über die verschiedenen Zu­gangsmethoden führt möglicherweise zu unerwarteten Ergebnissen.

Web-Zugriff über HTTPS

Bei aktiviertem HTTPS-Fernzugang kann der mGuard über seine Web-Oberfläche von entfernten Rechnern aus konfiguriert werden. Der Zugang erfolgt mittels Webbrowser (z. B. Mozilla Firefox, Google Chrome, Microsoft Edge).

Der HTTPS-Fernzugang ist standardmäßig deaktiviert. Nach einer Aktivierung kann er auf ausgewählte Interfaces und Netzwerke beschränkt werden.

Aktiviere HTTPS-Fern­zugang

Aktivieren Sie die Funktion, um den HTTPS-Fernzugriff zu er­möglichen.

Um Zugriffsmöglichkeiten auf den mGuard differenziert fest­zulegen, müssen Sie die Firewall-Regeln für die verfügbaren Interfaces entsprechend definieren (siehe „Erlaubte Netz­werke“ auf Seite 68).

Zusätzlich müssen gegebenenfalls unter Benutzerauthenti­fizierung die Authentifizierungsregeln gesetzt werden.

Port für HTTPS-Ver­bindungen (nur Fern­zugang)

Standard: 443

Wird diese Port-Nummer geändert, gilt die geänderte Port-Nummer nur für Zugriffe über das Interface Extern, DMZ und VPN. Für internen Zugriff gilt weiterhin 443.

Die entfernte Gegenstelle, die den Fernzugriff ausübt, muss bei der Adressenangabe hinter der IP-Adresse gegebenen­falls die Port-Nummer angeben, die hier festgelegt ist.

Beispiel: Wenn dieser mGuard über die Adresse 123.124.125.21 über das Internet zu erreichen ist und für den Fernzugang die Port-Nummer 443 festgelegt ist, dann muss bei der entfernten Gegenstelle im Web-Browser diese Port-Nummer nicht hinter der Adresse angegeben werden.

Bei einer anderen Port-Nummer ist diese hinter der IP-Ad­resse anzugeben, z. B.: https://123.124.125.21:442/

SSH- und HTTPS-Schlüssel erneuern

Generiere neue 2048 bit Schlüssel

Schlüssel, die mit einer älteren Firmware erstellt worden sind, sind möglicherweise schwach und sollten erneuert werden.

•Klicken Sie auf diese Schaltfläche, um neue Schlüssel zu erzeugen.

•Beachten Sie die Fingerprints der neu generierten Schlüssel.

•Loggen Sie sich über HTTPS ein und vergleichen Sie die Zertifikat-Informationen, die vom Web-Browser zur Verfü­gung gestellt werden.

Erlaubte Netzwerke

Sie können den HTTPS-Zugriff auf den mGuard mittels Firewall-Regeln auf ausgewählte Interfaces und Netzwerke beschränken.

Sind mehrere Firewall-Regeln gesetzt, werden diese in der Reihenfolge der Einträge von oben nach unten abgefragt, bis eine passende Regel gefunden wird. Diese wird dann an­gewandt. Sollten nachfolgend in der Regelliste weitere Regeln vorhanden sein, die auch passen würden, werden diese ignoriert.

Bei den Angaben haben Sie folgende Möglichkeiten:

Von IP

Geben Sie hier die Adresse des Rechners oder Netzes an, von dem der Zugang erlaubt beziehungsweise verboten ist.

IP-Adresse: 0.0.0.0/0 bedeutet alle Adressen. Um einen Be­reich anzugeben, benutzen Sie die CIDR-Schreibweise – siehe „CIDR (Classless Inter-Domain Routing)“ auf Seite 34.

Interface

Intern / Extern / DMZ / VPN

Gibt an, für welches Interface die Regel gelten soll.

Sind keine Regeln gesetzt oder greift keine Regel, gelten fol­gende Standardeinstellungen:

–HTTPS-Zugriffe über Intern und VPN sind erlaubt.

–HTTPS-Zugriffe über Extern und DMZ werden verwehrt.

Legen Sie die Zugriffsmöglichkeiten nach Bedarf fest.

Aktion

–Annehmen bedeutet, die Datenpakete dürfen passieren.

–Abweisen bedeutet, die Datenpakete werden zurückge­wiesen, so dass der Absender eine Information über die Zurückweisung erhält. (Im Stealth-Modus hat Abweisen dieselbe Wirkung wie Verwerfen.)

–Verwerfen bedeutet, die Datenpakete dürfen nicht pas­sieren. Sie werden verschluckt, so dass der Absender keine Information über deren Verbleib erhält.

Kommentar

Ein frei wählbarer Kommentar für diese Regel.

Log

Für jede einzelne Firewall-Regel können Sie festlegen, ob bei Greifen der Regel

–das Ereignis protokolliert werden soll – Funktion Log akti­vieren

–oder das Ereignis nicht protokolliert werden soll – Funkti­on Log deaktivieren (werkseitige Voreinstellung).

RADIUS-Authentifizierung

Benutzer können bei ihrer Anmeldung über einen RADIUS-Server authentifiziert werden. Nur bei den vordefinierten Benutzern (root, admin, netadmin, audit und user) wird das Passwort lokal geprüft.

Ermögliche RADIUS-Authentifizierung

Ja / Nein / Als einzige Methode zur Passwortprüfung

Bei aktivierter Funktion wird das Passwort der Benutzer, die sich über HTTPS einloggen, über die lokale Datenbank ge­prüft.

Nur wenn Nein ausgewählt ist, kann die   „Methode zur Benutzerauthentifizierung“   auf   „Login nur mit X.509-Be­nutzerzertifikat“   gesetzt werden.

Wählen Sie Ja, damit die Benutzer über den RADIUS-Server authentifiziert werden. Nur bei den vordefinierten Benutzern (root, admin, netadmin, audit und user) wird das Passwort lokal geprüft.

Die Berechtigungsstufen netadmin und audit beziehen sich auf Zugriffsrechte bei Zugriffen mit dem mGuard device manager (FL MGUARD DM UNLIMITED) .

Wenn Sie eine RADIUS-Authentifizierung das erste Mal ein­richten, wählen Sie Ja.

Wenn Sie planen, die RADIUS-Authentifizierung als einzige Methode zur Passwortprüfung einzurichten, empfehlen wir Ihnen ein „Customized Default Profile“ anzulegen, das die Au­thentifizierungsmethode zurücksetzt.

Wenn Sie die RADIUS-Authentifizierung als einzige Me­thode zur Passwortprüfung ausgewählt haben, dann ist der Zugang zum mGuard unter Umständen nicht mehr möglich. Dies gilt z. B. wenn Sie einen falschen RADIUS-Server ein­richten oder den mGuard umsetzen. Die vordefinierten Benut­zer (root, admin, netadmin, audit und user) werden dann nicht mehr akzeptiert.

Benutzerauthentifizierung

Sie können festlegen, ob sich ein Benutzer des mGuards bei seiner Anmeldung mit einem Passwort, einem X.509-Benutzerzertifikat oder einer Kombination daraus authentifiziert.

Legt fest, wie der lokale mGuard die entfernte Gegenstelle authentifiziert

Methode zur Benutzer­authentifizierung

Login mit Passwort

Legt fest, dass sich der aus der Ferne zugreifende Bediener des mGuards mit Angabe seines Passwortes beim mGuard anmelden muss. Das Passwort ist festgelegt unter Menü   „Au­thentifizierung >> Administrative Benutzer“   (siehe Seite 163). Außerdem gibt es die Möglichkeit der RADIUS-Authentifizie­rung (siehe Seite 170).

Je nach dem, mit welcher Benutzerkennung der Bediener sich anmeldet (User- oder Administrator-Passwort), hat er ent­sprechende Rechte, den mGuard zu bedienen bzw. zu konfi­gurieren.

Login mit X.509-Benutzerzertifikat oder Passwort

Die Benutzerauthentifizierung erfolgt per Login mit Passwort (siehe oben), oder

der Web-Browser des Benutzers authentisiert sich mit Hilfe eines X.509-Zertifikates und einem dazugehörigen privaten Schlüssel. Dazu sind unten weitere Angaben zu machen.

Welche Methode zur Anwendung kommt, hängt vom Web-Browser des von entfernt zugreifenden Benutzers ab. Die zweite Option kommt dann zur Anwendung, wenn der Web-Browser dem mGuard ein Zertifikat anbietet.

Login nur mit X.509-Benutzerzertifikat

Der Web-Browser des Benutzers muss sich mit Hilfe eines X.509-Zertifikates und dem zugehörigen privaten Schlüssel authentisieren. Dazu sind weitere Angaben zu machen.

Die Gegenstelle zeigt vor:

Zertifikat (personenbezogen) von CA signiert¹

Zertifikat (personenbezo­gen) selbst signiert

Der mGuard authentifi­ziert die Gegenstelle anhand von...

...allen CA-Zertifikaten, die mit dem von der Gegenstelle vorgezeigten Zertifikat die Kette bis zum Root-CA-Zerti­fikat bilden

ggf. PLUS

Client-Zertifikaten (Gegen­stellen-Zertifikaten), wenn sie als Filter verwendet wer­den.

Client-Zertifikat (Gegenstel­len-Zertifikat)

¹Die Gegenstelle kann zusätzlich Sub-CA-Zertifikate anbieten. In diesem Fall kann der mGuard mit den an­gebotenen CA-Zertifikaten und den bei ihm selber konfigurierten CA-Zertifikaten die Vereinigungsmenge bilden, um die Kette zu bilden. Auf jeden Fall muss aber das zugehörige Root-Zertifikat auf dem mGuard zur Verfügung stehen.

Ist unter Menüpunkt „Authentifizierung >> Zertifikate“, Zertifikatseinstellungen die Ver­wendung von Sperrlisten (= CRL-Prüfung) aktiviert, wird jedes von einer CA signierte Zer­tifikat, das HTTPS-Clients „vorzeigen“, auf Sperrung geprüft.

Authentifizierung mit­tels CA-Zertifikat

Die Konfiguration ist nur erforderlich, wenn der Benutzer, der per HTTPS zugreift, ein von einer CA signiertes Zertifikat vor­zeigt.

Es sind alle CA-Zertifikate zu konfigurieren, die der mGuard benötigt, um mit den von Benutzern vorgezeigten Zertifikaten jeweils die Kette bis zum jeweiligen Root-CA-Zertifikat zu bil­den.

Sollte der Web-Browser des aus der Ferne zugreifenden Be­nutzers zusätzlich CA-Zertifikate anbieten, die zur Bildung dieser Kette beitragen, dann ist es nicht notwendig, dass genau diese CA-Zertifikate beim mGuard installiert und an dieser Stelle referenziert werden.

Es muss aber auf jeden Fall das zugehörige Root-CA-Zertifi­kat beim mGuard installiert und zur Verfügung gestellt (= refe­renziert) sein.

Zugriffsberechtigung mittels X.509-Subject

Ermöglicht die Filtersetzung in Bezug auf den Inhalt des Fel­des Subject im Zertifikat, das vom Web-Browser/HTTPS-Cli­ent vorgezeigt wird.

Dadurch ist es möglich, den Zugriff von Web-Brow­ser/HTTPS-Client, die der mGuard auf Grundlage von Zertifi­katsprüfungen im Prinzip akzeptieren würde, wie folgt zu be­schränken bzw. freizugeben:

–Beschränkung auf bestimmte Subjects (d. h. Personen) und/oder auf Subjects, die bestimmte Merkmale (Attribu­te) haben, oder

–Freigabe für alle Subjects (siehe Glossar unter „Subject, Zertifikat“ auf Seite 337).

Freigabe für alle Subjects (d. h. Personen):

Mit * (Sternchen) im Feld X.509-Subject legen Sie fest, dass im vom Web-Browser/HTTPS-Client vorgezeigten Zertifikat beliebige Subject-Einträge erlaubt sind. Dann ist es überflüs­sig, das im Zertifikat jeweils angegebene Subject zu kennen oder festzulegen.

Beschränkung auf bestimmte Subjects (d. h. Personen) und/oder auf Subjects, die bestimmte Merkmale (Attri­bute) haben:

Im Zertifikat wird der Zertifikatsinhaber im Feld Subject ange­geben, dessen Eintrag sich aus mehreren Attributen zusam­mensetzt. Diese Attribute werden entweder als Object Identi­fier ausgedrückt (z. B.: 132.3.7.32.1) oder, geläufiger, als Buchstabenkürzel mit einem entsprechenden Wert.

Beispiel: CN=Max Muster, O=Fernwartung GmbH, C=DE

Sollen bestimmte Attribute des Subjects ganz bestimmte Werte haben, damit der mGuard den Web-Browser akzep­tiert, muss das entsprechend spezifiziert werden. Die Werte der anderen Attribute, die beliebig sein können, werden dann durch das Wildcard * (Sternchen) angegeben.

Beispiel: CN=*, O=*, C=DE    (mit oder ohne Leerzeichen zwi­schen Attributen)

Bei diesem Beispiel müsste im Zertifikat im Subject das Attri­but „C=DE“ stehen. Nur dann würde der mGuard den Zertifi­katsinhaber (= Subject) als Kommunikationspartner akzeptie­ren. Die anderen Attribute könnten in den zu filternden Zertifikaten beliebige Werte haben.

Bei HTTPS gibt der Web-Browser des zugreifenden Benut­zers nicht an, mit welchen Benutzer- bzw. Administratorrech­ten dieser sich anmeldet. Diese Rechtevergabe erfolgt bei der Filtersetzung hier (unter „Für den Zugriff autorisiert als“).

Das hat folgende Konsequenz: Gibt es mehrere Filter, die einen bestimmten Benutzer „durchlassen“, tritt der erste Filter in Kraft.

Und der Benutzer erhält das Zugriffsrecht, das ihm in diesem Filter zugesprochen wird. Und das könnte sich unterscheiden von Zugriffsrechten, die ihm in weiter unten stehenden Filtern zugeordnet sind.

Für den Zugriff autori­siert als

root / admin / netadmin / audit / user

Legt fest, welche Benutzer- bzw. Administratorrechte dem aus der Ferne zugreifenden Bediener eingeräumt werden.

Für eine Beschreibung der Berechtigungsstufen root, admin und user siehe „Authentifizierung >> Administrative Benutzer“ auf Seite 163.

Die Berechtigungsstufen netadmin und audit beziehen sich auf Zugriffsrechte bei Zugriffen mit dem mGuard device manager (FL MGUARD DM UNLIMITED) .

Authentifizierung mit­tels Client-Zertifikat

Die Konfiguration ist in den folgenden Fällen erforderlich:

–Von entfernt zugreifende Benutzer zeigen jeweils ein selbst signiertes Zertifikat vor.

–Von entfernt zugreifende Benutzer zeigen jeweils ein von einer CA signiertes Zertifikat vor. Es soll eine Filterung er­folgen: Zugang erhält nur der, dessen Zertifikats-Kopie im mGuard als Gegenstellen-Zertifikat installiert ist und in dieser Tabelle dem mGuard als Client-Zertifikat zur Verfü­gung gestellt wird.

Dieser Filter hat Vorrang gegenüber dem Subject-Filter in der Tabelle darüber, sofern verwendet.

Der Eintrag in diesem Feld legt fest, welches Gegenstellen-Zertifikat der mGuard heranziehen soll, um die Gegenstelle, den Web-Browser des von entfernt zugreifenden Benutzers, zu authentifizieren.

Dazu in der Auswahlliste eines der Client-Zertifikate auswählen.

Die Auswahlliste stellt die Client-Zertifikate zur Wahl, die in den mGuard unter Menüpunkt   „Authentifizierung >> Zertifi­kate“   geladen worden sind.

Für den Zugriff autori­siert als

root / admin / netadmin / audit / user

Legt fest, welche Nutzer- bzw. Administratorrechte dem aus der Ferne zugreifenden Bediener eingeräumt werden.

Für eine Beschreibung der Berechtigungsstufen root, admin und user siehe „Authentifizierung >> Administrative Benutzer“ auf Seite 163.

Die Berechtigungsstufen netadmin und audit beziehen sich auf Zugriffsrechte bei Zugriffen mit dem mGuard device manager (FL MGUARD DM UNLIMITED) .

Verwenden Sie die jeweils aktuelle Firmware-Version

Da mit jeder neuen Firmware-Version sicherheitsrelevante Verbesserungen in das Pro­dukt eingefügt werden, sollte grundsätzlich immer auf die neueste Firmware-Version ak­tualisiert werden.

Phoenix Contact stellt regelmäßig Firmware-Updates zur Verfügung. Diese finden Sie auf der Produktseite des jeweiligen Geräts (z. B. phoenixcontact.com/product/1357840).

•Stellen Sie sicher, dass die Firmware aller verwendeten Geräte immer auf dem aktu­ellen Stand ist.

•Beachten Sie die Change Notes / Release Notes zur jeweiligen Firmware-Version.

•Beachten Sie die Webseite des Product Security Incident Response Teams (PSIRT) von Phoenix Contact für Sicherheitshinweise zu veröffentlichten Sicherheitslücken.

Um sicherzustellen, dass die heruntergeladene Firmware- oder Update-Datei während des Downloads nicht von Dritten verändert wurde, können Sie die SHA256-Prüfsumme der Datei mit der auf der entsprechenden Produktseite (phoenixcontact.com/pro­duct/<Bestellnummer>) angegebenen Prüfsumme vergleichen.

Ein Update auf die aktuelle Firmware-Version ist von allen Firmware-Versionen ab mGu­ard 10.0.0 möglich. Ein Downgrade auf eine niedrigere Firmware-Version ist grundsätz­lich nicht möglich.

ACHTUNG: Eine Unterbrechung des Updates kann das Gerät beschädigen.

Schalten Sie das Gerät während des Update-Vorgangs nicht aus und unterbrechen Sie nicht die Stromversorgung des Geräts.

Systeminformationen

Listet Informationen zur Firmware-Version des mGuards auf.

Version

Die aktuelle Software-Version des mGuard-Geräts.

Basis

Die Version, mit der dieses Gerät ursprünglich geflasht wurde.

Updates

Liste der Updates, die zur Basis hinzu installiert worden sind.

Paketversionen

Listet die einzelnen Software-Module des mGuards auf. Diese Informationen werden ge­gebenenfalls im Support-Fall benötigt.

ACHTUNG: Nur das jeweils inaktive Gerät eines Redundanzpaares kann upgedatet werden.

ACHTUNG: Sie dürfen während des Updates auf keinen Fall die Stromversorgung des mGuards unterbrechen! Das Gerät könnte ansonsten beschädigt werden und nur noch durch den Hersteller reaktiviert werden können.

Abhängig von der Größe des Updates, kann dieses mehrere Minuten dauern.

Falls zum Abschluss des Updates ein Neustart erforderlich sein sollte, werden Sie durch eine Nachricht darauf hingewiesen.

Lokales Update

Installiere Pakete

Zur Installation von Paketen gehen Sie wie folgt vor:

•Das Icon  Keine Datei ausgewählt klicken, die Datei selektieren und öffnen.

Der Dateiname der Update-Datei ist abhängig von der Geräteplattform und der aktuell installierten Firmware-Version (siehe auch Anwenderhinweis AH DE MGU­ARD UPDATE „FL/TC MGUARD-Geräte updaten und fla­shen“).

•Beispiel: update-10.{0-2}-10.2.0.default.aarch64.tar.gz Dann die Schaltfläche Installiere Pakete klicken.

Automatische Updates

Bei einem automatischen Update ermittelt das Gerät das benötigte Package-Set eigen­ständig.

Installiere neueste Patches

Patch-Releases beheben Fehler der vorherigen Versionen und haben eine Versionsnummer, welche sich nur in der drit­ten Stelle ändern. Die Version 10.0.1 ist z. B. ein Patch-Re­lease zur Version 10.0.0.

Installiere aktuelles Minor-Release

Minor- und Major-Releases ergänzen den mGuard um neue Eigenschaften oder enthalten Änderungen am Verhalten des mGuards.

Ihre Versionsnummer ändert sich in der ersten oder zweiten Stelle. Die Version 10.1.0 ist z. B. ein Minor-Release zur Ver­sion 10.0.1.

Installiere das nächste Major-Release

Die Version 11.0.0 ist z. B. ein Major-Release zur Version 10.1.0.

Update-Server

Legen Sie fest, von welchen Servern ein Update vorgenommen werden darf.

Bei den Angaben haben Sie folgende Möglichkeiten:

Protokoll

Das Update kann per HTTPS, HTTP, FTP oder TFTP erfol­gen.

Server

Hostname oder IP-Adresse des Servers, der die Update-Da­teien bereitstellt.

Über VPN

Die Anfrage des Update-Servers wird, wenn möglich, über einen VPN-Tunnel durchgeführt.

Bei aktivierter Funktion wird die Kommunikation mit dem Ser­ver immer dann über einen verschlüsselten VPN-Tunnel ge­führt, wenn ein passender VPN-Tunnel verfügbar ist.

Login

Login für den Server.

Passwort

Passwort für den Login.

Server-Zertifikat

Um sicherzustellen, dass eine sichere HTTPS-Verbindung zum konfigurierten Update-Server aufgebaut wird, muss das entsprechende Server-Zertifikat des Update-Servers vom mGuard-Gerät geprüft werden.

Die Authentifizierung des Update-Servers erfolgt dabei ent­weder über ein entsprechendes Gegenstellen-Zertifikat oder über ein CA-Zertifikat. Das Zertifikat muss auf das mGuard-Gerät hochgeladen werden, damit es zur Prüfung des Server-Zertifikats in der Drop-Down-Liste ausgewählt werde kann (siehe Kapitel 6.4.4, „Gegenstellen-Zertifikate“ und Kapitel 6.4.3, „CA-Zertifikate“).

Wird die Option „Ignorieren“ ausgewählt. findet keine Prüfung statt.

Beim Abspeichern eines Konfigurationsprofils werden die Passwörter, die zur Authentifi­zierung des administrativen Zugriffs auf den mGuard dienen (Root-Passwort, Admin-Passwort, SNMPv3-Passwort), nicht mitgespeichert.

Es ist möglich, ein Konfigurationsprofil zu laden und in Kraft zu setzen, das unter einer äl­teren Firmware-Version erstellt wurde. Umgekehrt trifft das nicht zu: Ein unter einer neu­eren Firmware-Version erstelltes Konfigurationsprofil sollte nicht geladen werden und wird zurückgewiesen.

Konfigurationsprofile

Die Seite zeigt oben eine Liste von Konfigurationsprofilen, die im mGuard gespeichert sind, z. B. das Konfigurationsprofil Werkseinstellung. Sofern vom Benutzer Konfigurati­onsprofile gespeichert worden sind (siehe unten), werden diese hier aufgeführt.

Aktives Konfigurationsprofil: Das Konfigurationsprofil, das zurzeit in Kraft ist, hat vorne im Eintrag das Active-Symbol. Wird eine Konfiguration so geändert, dass sie einem gespeicherten Konfigurationsprofil entspricht, erhält dieses das Active-Symbol, nachdem die Änderungen übernommen wurden.

Sie können Konfigurationsprofile, die im mGuard gespeichert sind:

–in Kraft setzen (Profil wiederherstellen)

–als atv-Datei auf dem angeschlossenen Konfigurationsrechner herunterladen

–ansehen und bearbeiten (Profil bearbeiten)

–löschen

Konfigurationsprofil als atv-Datei herunterladen

•In der Liste den Namen des Konfigurationsprofils anklicken.

Das Konfigurationsprofil wird als atv-Datei heruntergeladen und kann mit einem Text-Editor analysiert werden.

Konfigurationsprofil vor der Wiederherstellung ansehen und bearbeiten (Profil bearbeiten)

•Rechts neben dem Namen des betreffenden Konfigurationsprofils auf das Icon  Profil bearbeiten klicken.

Das Konfigurationsprofil wird geladen aber noch nicht aktiviert. Alle Einträge, die Än­derungen zur aktuell verwendeten Konfiguration aufweisen, werden innerhalb der re­levanten Seite und im zugehörigen Menüpfad grün markiert. Die angezeigten Ände­rungen können unverändert oder mit weiteren Änderungen übernommen oder verworfen werden:

–Um die Einträge des geladenen Profils (gegebenenfalls mit weiteren Änderun­gen) zu übernehmen, klicken Sie auf das Icon  Übernehmen.

–Um alle Änderungen zu verwerfen, klicken Sie auf das Icon  Zurücksetzen.

Die Werkseinstellung oder ein vom Benutzer im mGuard gespeichertes Konfigu­rationsprofil in Kraft setzen (Profil wiederherstellen)

•Rechts neben dem Namen des betreffenden Konfigurationsprofils auf das Icon  Profil wiederherstellen klicken.

Das betreffende Konfigurationsprofil wird ohne Rückfrage wiederhergestellt und so­fort aktiviert.

Konfigurationsprofil als Datei auf dem Konfigurationsrechner speichern

•Rechts neben dem Namen des betreffenden Konfigurationsprofils auf das Icon  Profil herunterladen klicken.

•Legen Sie gegebenenfalls im angezeigten Dialogfeld den Dateinamen und Speicher­ort fest, unter dem das Konfigurationsprofil als Datei gespeichert werden soll. (Sie können die Datei beliebig benennen.)

Konfigurationsprofil löschen 

•Rechts neben dem Namen des betreffenden Konfigurationsprofils auf das Icon  Profil löschen klicken.

Aktuelle Konfigura­tion als Profil spei­chern

Aktuelle Konfiguration als Profil im mGuard speichern

•Hinter „Aktuelle Konfiguration als Profil speichern“ in das Feld Profilname den gewünschten Profilnamen eintragen.

•Auf die Schaltfläche  Übernehmen klicken.

Das Konfigurationsprofil wird im mGuard gespeichert. Der Name des Profils wird in der Liste der im mGuard gespeicher­ten Konfigurationsprofile angezeigt.

Hochladen einer Kon­figuration als Profil

Hochladen eines Konfigurationsprofils, das auf dem Konfigurationsrechner in einer Datei gespeichert ist

Voraussetzung: Sie haben nach dem oben beschriebenem Verfahren ein Konfigurationsprofil als Datei auf dem Konfigu­rationsrechners gespeichert.

•Hinter „Hochladen einer Konfiguration als Profil“ in das Feld Profilname den gewünschten Profilnamen ein­tragen, der angezeigt werden soll.

•Auf das Icon  Keine Datei ausgewählt klicken und im angezeigten Dialogfeld die betreffende Datei selektieren und öffnen.

•Auf die Schaltfläche  Hochladen klicken.

Das Konfigurationsprofil wird in den mGuard geladen, und der in Schritt 1 vergebene Name wird in der Liste der gespeicher­ten Profile angezeigt.

Externer Konfigurations­speicher (ECS)

Auf dem mGuard abgespeicherte Konfigurationsprofile können auf eine SD-Karte als ex­ternem Konfigurationsspeicher (ECS) exportiert und von dieser erneut in mGuard-Geräte importiert werden.

Name der exportierten Datei: ECS.tgz

Technische Voraussetzung von SD-Karten:

–FAT-kompatibles Dateisystem auf der ersten Partition.

Zertifizierte und freigegebene SD-Karten durch Phoenix Contact: siehe Bereich „Zube­hör“ auf den Produktseiten unter: phoenixcontact.com/products

Um die Datei in ein mGuard-Gerät zu importieren, muss die SD-Karte in den mGuard ein­gelegt werden.

Die Konfiguration kann

–beim Starten des Geräts automatisch geladen, entschlüsselt und als aktive Konfigu­ration verwendet oder

–über die Web-Oberfläche geladen und aktiviert werden.

Zustand des ECS

Der aktuelle Zustand wird dynamisch aktualisiert. (Siehe „Zu­stand des ECS“  in „Ereignistabelle“ auf Seite 62).

Aktuelle Konfigura­tion auf dem ECS spei­chern

Beim Austausch durch ein Ersatzgerät kann das Konfigurati­onsprofil des ursprünglichen Gerätes mit Hilfe des ECS über­nommen werden. Voraussetzung hierfür ist, dass das Ersatz­gerät noch „root“ als Passwort für den Benutzer „root“ verwendet.

Wenn das Root-Passwort auf dem Ersatzgerät ungleich „root“ ist, dann muss dieses Passwort in das Feld „Root-Passwort“ eingegeben werden. Übernehmen Sie die Eingabe mit einem Klick auf die Schaltfläche  Übernehmen.

Komplexe Konfigurationen z. B. mit einer großen Anzahl kon­figurierter Firewall-Regeln und/oder VPN-Verbindungen kön­nen zu großen Konfigurationsprofilen führen.

Konfiguration vom ECS laden

Befindet sich ein Konfigurationsprofil auf einem eingelegten bzw. angeschlossenen ECS-Speichermedium, wird dieses nach einem Klick auf die Schaltfläche  Laden in den mGuard importiert und dort als aktives Profil in Kraft gesetzt.

Das geladene Konfigurationsprofil erscheint nicht in der Liste der im mGuard gespeicherten Konfigurationsprofile.

Konfigurationsände­rungen automatisch auf dem ECS spei­chern

Bei aktivierter Funktion werden die Konfigurationsänderungen automatisch auf einem ECS gespeichert, so dass auf dem ECS stets das aktuell verwendete Profil gespeichert ist.

Automatisch abgespeicherte Konfigurationsprofile werden von einem mGuard beim Starten nur angewendet, wenn der mGuard als Passwort für den „root“-Benutzer noch das ur­sprüngliche Passwort (ebenfalls „root“) eingestellt hat.

Auch wenn der ECS nicht angeschlossen, voll oder defekt ist, werden Konfigurationsänderungen ausgeführt. Entspre­chende Fehlermeldungen erscheinen im Logging (siehe „Log­ging >> Logs ansehen“ auf Seite 311).

Die Aktivierung der neuen Einstellung verlängert die Reakti­onszeit der Bedienoberfläche, wenn Einstellungen geändert werden.

Daten auf dem ECS verschlüsseln

Bei aktivierter Funktion werden die Konfigurationsänderungen verschlüsselt auf einem ECS abgespeichert. Damit wird der Rollout von mGuards erleichtert.

Sie können mehrere mGuard-Konfigurationen auf einer SD-Karte abspeichern und anschließend zur Inbetriebnahme aller mGuards verwenden. Beim Startvorgang findet der mGuard die für ihn gültige Konfiguration auf dem Konfigurationsspei­cher. Diese wird geladen, entschlüsselt und als gültige Konfi­guration verwendet.

Lade die aktuelle Kon­figuration vom ECS beim Start

Bei aktivierter Funktion wird beim Booten des mGuards auf den ECS zugegriffen. Das Konfigurationsprofil wird vom ECS in den mGuard geladen, gegebenenfalls entschlüsselt und als gültige Konfiguration verwendet.

Die Konfiguration des mGuards darf nicht gleichzeitig über den Web-Zugriff, den Shell-Zugang oder SNMP erfolgen. Eine zeitgleiche Konfiguration über die verschiedenen Zu­gangsmethoden führt möglicherweise zu unerwarteten Ergebnissen.

Im Gegensatz zum Protokoll SNMPv3 unterstützen die älteren Versionen SNMPv1/SNMPv2 keine Authentifizierung und keine Verschlüsselung und gelten daher als nicht sicher. Das SNMPv1/2-Protokoll sollte nur in einer sicheren Netzwerkumgebung verwendet werden, die gänzlich unter Kontrolle des Betreibers steht.

SNMPv3 wird allerdings nicht von allen Management-Konsolen unterstützt.

Die Bearbeitung einer SNMP-Anfrage kann länger als eine Sekunde dauern. Dieser Wert entspricht jedoch dem Standard-Timeout-Wert einiger SNMP-Management-Applikatio­nen.

•Setzen Sie aus diesem Grund den Timeout-Wert Ihrer Management Applikation auf Werte zwischen 3 und 5 Sekunden, falls Timeout-Probleme auftreten sollten.

Einstellungen

Aktiviere SNMPv3

Aktivieren Sie die Funktion, wenn Sie zulassen wollen, dass der mGuard per SNMPv3 überwacht werden kann.

Für den Zugang per SNMPv3 ist eine Authentifizierung mittels Benutzername und Passwort notwendig. Die werkseitige Vor­einstellung für die Zugangsdaten lautet:

Benutzername: admin

Passwort: SnmpAdmin

(Bitte beachten Sie die Groß-/Kleinschreibung!)

Die SNMPv3-Zugangsdaten Benutzername und Passwort können über die Web-Oberfläche, eine ECS-Konfiguration oder ein Rollout-Script geändert werden.

Das Verwalten von SNMPv3-Benutzern über SNMPv3 USM ist nicht möglich.

Das Hinzufügen zusätzlicher SNMPv3-Benutzer wird aktuell nicht unterstützt.

Für die Authentifizierung wird MD5 verwendet, für die Ver­schlüsselung DES.

Aktiviere SNMPv1/v2

Aktivieren Sie die Funktion, wenn Sie zulassen wollen, dass der mGuard per SNMPv1/v2 überwacht werden kann.

Zusätzlich müssen Sie unter SNMPv1/v2-Community die Login-Daten angeben.

Port für SNMP-Verbin­dungen

Standard: 161

Wird diese Port-Nummer geändert, gilt die geänderte Port-Nummer nur für Zugriffe über das Interface Extern, DMZ und VPN. Für internen Zugriff gilt weiterhin 161.

Die entfernte Gegenstelle, die den Fernzugriff ausübt, muss bei der Adressenangabe gegebenenfalls die Port-Nummer angeben, die hier festgelegt ist.

Führe den SNMP-Agent mit den Rechten des folgenden Benut­zers aus

admin / netadmin

Legt fest, mit welchen Rechten der SNMP-Agent ausgeführt wird.

SNMPv3-Zugangsdaten

Benutzername

Ändert den aktuell vergebenen SNMPv3-Benutzernamen.

Passwort

Ändert das aktuell vergebene SNMPv3-Passwort.

Das Passwort kann nur geschrieben und nicht ausgelesen werden (write-only).

SNMPv1/v2-Community

Read-Write-Commu­nity

Geben Sie in diese Felder die erforderlichen Login-Daten ein.

Read-Only-Commu­nity

Geben Sie in diese Felder die erforderlichen Login-Daten ein.

Erlaubte Netzwerke

Listet die eingerichteten Firewall-Regeln auf. Sie gelten für eingehende Datenpakete eines SNMP-Zugriffs.

Sind keine Regeln gesetzt oder greift keine Regel, gelten folgende Standardeinstellun­gen:

–SNMP-Zugriffe über Intern und VPN sind erlaubt.

–SNMP-Zugriffe über Extern und DMZ werden verwehrt.

Legen Sie die Überwachungsmöglichkeiten nach Bedarf fest.

Die hier angegebenen Regeln treten nur in Kraft, wenn die Funktion Aktiviere SNMPv3 oder Aktiviere SNMPv1/v2 aktiviert ist.

Sind mehrere Firewall-Regeln gesetzt, werden diese in der Reihenfolge der Einträge von oben nach unten abgefragt, bis eine passende Regel gefunden wird. Diese wird dann an­gewandt. Sollten nachfolgend in der Regelliste weitere Regeln vorhanden sein, die auch passen würden, werden diese ignoriert.

Von IP

Geben Sie hier die Adresse des Rechners oder Netzes an, von dem der Zugang erlaubt beziehungsweise verboten ist.

Bei den Angaben haben Sie folgende Möglichkeiten:

–Eine IP-Adresse.

–Um einen Bereich anzugeben, benutzen Sie die CIDR-Schreibweise (siehe „CIDR (Classless Inter-Domain Rou­ting)“ auf Seite 34).

–0.0.0.0/0 bedeutet alle Adressen.

Interface

Intern / Extern / DMZ / VPN

Gibt an, für welches Interface die Regel gelten soll.

Sind keine Regeln gesetzt oder greift keine Regel, gelten fol­gende Standardeinstellungen:

–SNMP-Zugriffe über Intern und VPN sind erlaubt.

–SNMP-Zugriffe über Extern und DMZ werden verwehrt.

Legen Sie die Überwachungsmöglichkeiten nach Bedarf fest.

Aktion

Annehmen bedeutet, dass die Datenpakete passieren dür­fen.

Abweisen bedeutet, dass die Datenpakete zurückgewiesen werden, so dass der Absender eine Information über die Zu­rückweisung erhält. (Im Stealth-Modus hat Abweisen dieselbe Wirkung wie Verwerfen.)

Verwerfen bedeutet, dass die Datenpakete nicht passieren dürfen. Sie werden verschluckt, so dass der Absender keine Information über deren Verbleib erhält.

Kommentar

Ein frei wählbarer Kommentar für diese Regel.

Log

Für jede einzelne Firewall-Regel können Sie festlegen, ob bei Greifen der Regel

–das Ereignis protokolliert werden soll – Funktion Log akti­vieren oder

–das Ereignis nicht protokolliert werden soll – Funktion Log deaktivieren (werkseitige Voreinstellung).

Werden SNMP-Traps über einen VPN-Tunnel zur Gegenstelle gesendet, dann muss sich die IP-Adresse der Gegenstelle in dem Netzwerk befinden, das in der Definition der VPN-Verbindung als Gegenstellen-Netzwerk angegeben ist.

Und die interne IP-Adresse muss sich in dem Netzwerk befinden, das in der Definition der VPN-Verbindung als Lokal angegeben ist (siehe „IPsec VPN >> Verbindungen >> Editie­ren >> Allgemein“).

Basis-Traps

SNMP-Authentifika­tion

Trap-Beschreibung

–enterprise-oid   : mGuardInfo

–generic-trap   : authenticationFailure

–specific-trap   : 0

Wird gesendet, falls eine Station versucht, unberechtigt auf den SNMP-Agenten des mGuards zuzugreifen.

Linkstatus An/Aus

 Trap-Beschreibung

–enterprise-oid   : mGuardInfo

–generic-trap   : linkUp, linkDown

–specific-trap   : 0

Wird gesendet, wenn die Verbindung zu einem Port unterbro­chen (linkDown) bzw. wiederhergestellt (linkUp) wird.

Kaltstart

Trap-Beschreibung

–enterprise-oid   : mGuardInfo

–generic-trap   : coldStart

–specific-trap   : 0

Wird gesendet nach Kalt- oder Warmstart.

Administrativer Ver­bindungsversuch (SSH, HTTPS)

Trap-Beschreibung

–enterprise-oid   : mGuard

–generic-trap   : enterpriseSpecific

–specific-trap   : mGuardHTTPSLoginTrap (1)

–additional   : mGuardHTTPSLastAccessIP

Wird gesendet, wenn jemand erfolgreich oder vergeblich (z. B. mit einem falschen Passwort) versucht hat, eine HTTPS-Sitzung zu öffnen. Der Trap enthält die IP-Adresse, von der der Versuch stammte.

–enterprise-oid   : mGuard

–generic-trap   : enterpriseSpecific

–specific-trap   : mGuardShellLoginTrap (2)

–additional   : mGuardShellLastAccessIP

Wird gesendet, wenn jemand die Shell per SSH öffnet. Der Trap enthält die IP-Adresse der Login-Anfrage.

Administrativer Zugriff (SSH, HTTPS)

Trap-Beschreibung

–enterprise-oid   : mGuard

–generic-trap   : enterpriseSpecific

–specific-trap   : mGuardTrapSSHLogin

–additional   : mGuardTResSSHUsername

        mGuardTResSSHRemoteIP

Wird gesendet, wenn jemand per SSH auf den mGuard zu­greift.

–enterprise-oid   : mGuard

–generic-trap   : enterpriseSpecific

–specific-trap   : mGuardTrapSSHLogout

–additional   : mGuardTResSSHUsername

        mGuardTResSSHRemoteIP

Wird gesendet, wenn ein Zugriff per SSH auf den mGuard be­endet wird.

Neuer DHCP-Client

Trap-Beschreibung

–enterprise-oid   : mGuard

–generic-trap   : enterpriseSpecific

–specific-trap   : 3

–additional   : mGuardDHCPLastAccessMAC

Wird gesendet, wenn eine DHCP-Anfrage von einem unbe­kannten Client eingegangen ist.

Hardwarebezogene Traps

Chassis (Stromversor­gung, Relais)

Trap-Beschreibung

–enterprise-oid   : mGuardTrapSenderIndustrial

–generic-trap   : enterpriseSpecific

–specific-trap   : mGuardTrapIndustrialPowerStatus (2)

–additional   : mGuardTrapIndustrialPowerStatus

Wird gesendet, wenn das System einen Stromausfall regist­riert.

–enterprise-oid   : mGuardTrapSenderIndustrial

–generic-trap   : enterpriseSpecific

–specific-trap   : mGuardTrapSignalRelais (3)

–additional   : mGuardTResSignalRelaisState

        (mGuardTEsSignlalRelaisReason, mGuardTResSignal RelaisReasonIdx)

Wird gesendet nach geändertem Meldekontakt und gibt den dann aktuellen Status an (0 = Aus, 1 = Ein).

Service-Eingang/CMD

(Alternative Bezeichnung für den Service-Eingang: „I“.)

Trap-Beschreibung

–enterprise-oid   : mGuardTrapCMD

–generic-trap   : enterpriseSpecific

–specific-trap   : mGuardTrapCMDStateChange (1)

–additional   : mGuardCMDState         

Wird gesendet, wenn ein Service-Eingang/CMD durch einen Schalter oder Taster geschaltet wird. Bei jedem Schaltvor­gang (Ein/Aus) wird ein Trap gesendet.

Agent (externer Konfi­gurationsspeicher, Temperatur)

Trap-Beschreibung

–enterprise-oid   : mGuardTrapIndustrial

–generic-trap   : enterpriseSpecific

–specific-trap   : mGuardTrapIndustrialTemperature (1)

–additional   : mGuardSystemTemperature,

       mGuardTrapIndustrialTempHiLimit,

       mGuardTrapIndustrialLowLimit

Wird gesendet bei Überschreitung der festgelegten Grenz­werte und gibt die Temperatur an.

–enterprise-oid   : mGuardTrapIndustrial

–genericTrap   : enterpriseSpecific

–specific-trap   : mGuardTrapAutoConfigAdapterState (4)

–additional   : mGuardTrapAutoConfigAdapter Change

Wird gesendet nach Zugriff auf den ECS.

Benutzerfirewall-Traps

(Nicht bei Geräten der FL MGUARD 2000-Serie.)

Benutzerfirewall-Traps

Trap-Beschreibung.

–enterprise-oid   : mGuardTrapUserFirewall

–generic-trap   : enterpriseSpecific

–specific-trap   : mGuardTrapUserFirewallLogin (1)

–additional   : mGuardTResUserFirewallUsername,

      mGuardTResUserFirewallSrcIP,

   mGuardTResUserFirewallAuthenticationMethod

Wird gesendet beim Einloggen eines Benutzers der Benutzer-Firewall.

–enterprise-oid   : mGuardTrapUserFirewall

–generic-trap   : enterpriseSpecific

–specific-trap   : mGuardTrapUserFirewallLogout (2)

–additional   : mGuardTResUserFirewallUsername,

      mGuardTResUserFirewallSrcIP,

      mGuardTResUserFirewallLogoutRea­son

Wird gesendet beim Ausloggen eines Benutzers der Benut­zer-Firewall

–enterprise-oid   : mGuardTrapUserFirewall

–generic-trap   : enterpriseSpecific

–specific-trap   : mGuardTrapUserFirewallAuthError TRAP-TYPE (3)

–additional   : mGuardTResUserFirewallUsername,

      mGuardTResUserFirewallSrcIP,

      mGuardTResUserFirewallAuthenticationMet­hod

Wird gesendet bei einem Authentifizierungs-Fehler.

Redundanz-Traps

(Nicht auf Geräten der FL MGUARD 2000-Serie)

Statusänderung

Trap-Beschreibung

–enterprise-oid   : mGuardTrapRouterRedundancy

–generic-trap   : enterpriseSpecific

–specific-trap   : mGuardTrapRouterRedBackupDown

–additional   : mGuardTResRedundacyBackup­Down

Dieser Trap wird gesendet, wenn das Backup-Gerät (sekun­därer mGuard) nicht durch das Master-Gerät (primärer mGuard) erreicht werden kann. (Der Trap wird nur dann gesendet, wenn ICMP-Prüfungen aktiviert sind.)

–enterprise-oid   : mGuardTrapRouterRedundancy

–generic-trap   : enterpriseSpecific

–specific-trap   : mGuardTrapRRedundancyStatu­sChange

–additional   : mGuardRRedStateSSV,
mGuardRRedStateACSummary,
mGuardRRedStateCCSummary,
mGuardRRedStateStateRepSummary

Wird gesendet, wenn sich der Zustand des HA-Clusters geän­dert hat.

VPN-Traps

Statusänderungen von IPsec-Verbindun­gen

Trap-Beschreibung

–enterprise-oid    : mGuardTrapVPN

–genericTrap   : enterpriseSpecific

–specific-trap   : mGuardTrapVPNIKEServerStatus (1)

–additional   : mGuardTResVPNStatus

Wird gesendet beim Starten und Stoppen des IPsec-IKE-Ser­vers.

–enterprise-oid   : mGuardTrapVPN

–genericTrap   : enterpriseSpecific

–specific-trap   : mGuardTrapVPNIPsecConnStatus (2)

–additional   : mGuardTResVPNName,

      mGuardTResVPNIndex,

      mGuardTResVPNPeer,

      mGuardTResVPNStatus,

      mGuardTResVPNType,

      mGuardTResVPNLocal,

      mGuardTResVPNRemote

Wird gesendet bei einer Zustandsänderung einer IPsec-Ver­bindung.

–enterprise-oid   : mGuard

–generic-trap   : enterpriseSpecific

–specific-trap   : mGuardTrapVPNIPsecConnStatus

Wird gesendet, wenn eine Verbindung aufgebaut oder ge­trennt wird. Er wird nicht gesendet, wenn der mGuard dabei ist, eine Verbindungsanfrage für diese Verbindung zu akzep­tieren.

Statusänderungen von L2TP-Verbindun­gen

Trap-Beschreibung

–enterprise-oid   : mGuardTrapVPN

–genericTrap   : enterpriseSpecific

–specific-trap   : mGuardTrapVPNL2TPConnStatus (3)

–additional   : mGuardTResVPNName, mGuardTResVPNIndex,

      mGuardTResVPNPeer,

      mGuardTResVPNStatus,

      mGuardTResVPNLocal,

      mGuardTResVPNRemote

Wird gesendet bei einer Zustandsänderung einer L2TP-Ver­bindung.

Trap-Ziele

Traps können an mehrere Ziele versendet werden.

Ziel-IP

IP-Adresse, an welche der Trap gesendet werden soll.

Ziel-Port

Standard: 162

Ziel-Port, an welchen der Trap gesendet werden soll

Zielname

Ein optionaler beschreibender Name für das Ziel. Hat keinen Einfluss auf die generierten Traps.

Ziel-Community

Name der SNMP-Community, der der Trap zugeordnet ist.

LLDP

LLDP aktivieren

Der LLDP-Service bzw. -Agent kann hier global aktiviert bzw. deaktiviert werden.

LLDP auf externen Netzwerken

Sie können auswählen, ob der mGuard LLDP-Informationen aus externen und/oder internen Netzwerken nur empfängt oder ebenfalls sendet und empfängt.

LLDP auf internen Netzwerken

(siehe oben)

Geräte

Über LLDP gefundene Geräte

Lokales Interface

Lokales Interface, über das das Gerät gefunden wurde.

Geräte-ID-Subtyp

Eindeutiger Geräte-ID-Subtyp des gefundenen Rechners.

Geräte-ID

Eine eindeutige ID des gefundenen Rechners; üblicherweise eine seiner MAC-Adressen.

IP-Adresse

IP-Adresse des gefundenen Rechners, über die der Rechner per SNMP administriert werden kann.

Port-Beschreibung

Ein Text, welcher die Netzwerkschnittstelle beschreibt, über welche der Rechner gefunden wurde.

Systemname

Hostname des gefundenen Rechners.

Konfiguration holen

Zeitplan

Geben Sie hier an, ob - und wenn ja - wann bzw. in welchen Zeitabständen der mGuard versuchen soll, eine neue Konfi­guration vom Server herunterzuladen und bei sich in Kraft zu setzen. Öffnen Sie dazu die Auswahlliste und wählen Sie den gewünschten Wert.

Bei der Auswahl Nie wird der mGuard keinen Versuch unter­nehmen, eine Konfiguration vom Server herunterzuladen.

Bei der Auswahl Nach dem Einschalten wird der mGuard­nach jedem Neustart versuchen, eine Konfiguration vom Ser­ver herunterzuladen.

Bei Auswahl Zeitgesteuert wird unterhalb ein neues Feld ein­geblendet. In diesem geben Sie an, ob täglich oder an einem bestimmten Wochentag regelmäßig und zu welcher Uhrzeit eine neue Konfiguration vom Server heruntergeladen werden soll.

Das zeitgesteuerte Herunterladen einer neuen Konfiguration kann erst nach Synchronisation der Systemzeit erfolgen (siehe „Verwaltung >> Systemeinstellungen“ auf Seite 37, „Zeit und Datum“ auf Seite 39).

Die Zeitsteuerung setzt die ausgewählte Zeit in Bezug auf die eventuell konfigurierte Zeitzone.

Bei der Auswahl Alle xx min/h wird der mGuard in den aus­gewählten zeitlichen Abständen versuchen, eine Konfigura­tion vom Server herunterzuladen.

Server

IP-Adresse oder Hostname des Servers, welcher die Konfigu­rationen bereitstellt.

Port

Port, unter dem der Server erreichbar ist.

Verzeichnis

Das Verzeichnis (Ordner) auf dem Server, in dem die Konfigu­ration liegt.

Dateiname

Der Name der Datei in dem oben definierten Verzeichnis. Falls an dieser Stelle kein Dateiname definiert ist, wird die Se­riennummer des mGuards inklusive der Endung „.atv“ ver­wendet.

Anzahl der Zyklen, die ein Konfigurationspro­fil nach einem Roll­back ignoriert wird

Standard: 2

Nach Holen einer neuen Konfiguration könnte es im Prinzip passieren, dass nach Inkraftsetzen der neuen Konfiguration der mGuard nicht mehr erreichbar ist und damit eine neue, korrigierende Fernkonfiguration nicht mehr möglich ist. Um das auszuschließen, unternimmt der mGuard folgende Prü­fung:

Vorgangsbeschreibung

Sofort nach Inkraftsetzen der geholten Konfiguration versucht der mGuard auf Grundlage dieser neuen Konfiguration, die Verbindung zum Konfigurations-Server nochmals herzu­stellen und das neue, bereits in Kraft gesetzte Konfigurationsprofil erneut herunterzula­den.

Wenn das gelingt, bleibt die neue Konfiguration in Kraft.

Wenn diese Prüfung negativ ausfällt - aus welchen Gründen auch immer -, geht der mGuard davon aus, dass das gerade in Kraft gesetzte neue Konfigurationsprofil fehlerhaft ist. Für Identifizierungszwecke merkt sich der mGuard dessen MD5-Summe. Dann führt der mGuard ein Rollback durch.

Rollback bedeutet, dass die letzte (funktionierende) Konfiguration wiederhergestellt wird. Das setzt voraus, dass in der neuen (nicht funktionierenden) Konfiguration die Anweisung steht, ein Rollback durchzuführen, wenn ein neues geladenes Konfigurationsprofil sich in dem oben beschriebenen Prüfungsverfahren als fehlerhaft erweist.

Wenn nach der im Feld Zeitplan (und Zeitgesteuert) festgelegten Zeit der mGuard er­neut und zyklisch versucht, ein neues Konfigurationsprofil zu holen, wird er ein solches nur unter folgendem Auswahlkriterium annehmen: Das zur Verfügung gestellte Konfigu­rationsprofil muss sich unterscheiden von dem Konfigurationsprofil, das sich für den mGuard zuvor als fehlerhaft erwiesen hat und zum Rollback geführt hat.

(Dazu vergleicht der mGuard die bei ihm gespeicherte MD5-Summe der alten, für ihn feh­lerhaften und verworfenen Konfiguration mit der MD5-Summe des angebotenen neuen Konfigurationsprofils.)

Wird dieses Auswahlkriterium erfüllt, d. h. es wird ein neueres Konfigurationsprofil ange­boten, holt sich der mGuard dieses Konfigurationsprofil, setzt es in Kraft und prüft es gemäß des oben beschriebenen Verfahrens - und setzt es bei nicht bestandener Prüfung per Rollback wieder außer Kraft.

Wird dieses Auswahlkriterium nicht erfüllt (weil immer noch das selbe Konfigurations­profil angeboten wird), bleibt für die weiteren zyklischen Abfragen dieses Auswahlkrite­rium so lange in Kraft, wie in diesem Feld (Anzahl der Zyklen...) festgelegt ist.

Ist die hier festgelegte Anzahl von Zyklen abgelaufen, ohne dass das auf dem Konfigura­tions-Server angebotene Konfigurationsprofil verändert wurde, setzt der mGuard das un­veränderte neue („fehlerhafte“) Konfigurationsprofil ein weiteres Mal in Kraft, obwohl es sich als „fehlerhaft“ erwiesen hatte. Das geschieht um auszuschließen, dass das Misslin­gen der Prüfung durch äußere Faktoren (z. B. Netzwerkausfall) bedingt war.

Der mGuard versucht dann erneut, auf Grundlage der erneut eingesetzten neuen Konfi­guration die Verbindung zum Konfigurations-Server herzustellen und erneut das neue, jetzt in Kraft gesetzte Konfigurationsprofil herunterzuladen. Wenn das misslingt, erfolgt wieder ein Rollback, und für die weiteren Zyklen zum Laden einer neuen Konfiguration wird erneut das Auswahlkriterium in Kraft gesetzt - so oft, wie in diesem Feld (Anzahl der Zyklen...) festgelegt ist.

Wird im Feld Anzahl der Zyklen... als Wert 0 (Null) festgelegt, hat das zur Folge, dass das Auswahlkriterium - das angebotene Konfigurationsprofil wird ignoriert, wenn es un­verändert geblieben ist - niemals in Kraft tritt. Dadurch könnte das 2. der nachfolgend auf­geführten Ziele nicht realisiert werden.

Dieser Mechanismus hat folgende Ziele:

1.Nach Inkraftsetzen einer neuen Konfiguration muss sichergestellt sein, dass der mGuard sich weiterhin vom entfernten Standort aus konfigurieren lässt.

2.Bei eng gesetzten Zyklen (z. B. bei Zeitplan = 15 Minuten) muss verhindert werden, dass der mGuard stur ein möglicherweise fehlerhaftes Konfigurationsprofil in zu kur­zen Abständen immer wieder erneut testet. Das könnte dazu führen, dass der mGuard so mit sich selbst beschäftigt ist, dass ein administrativer Eingriff von außen behindert oder verhindert wird.

3.Es muss mit großer Wahrscheinlichkeit ausgeschlossen werden, dass äußere Fak­toren (z. B. Netzwerkausfall) den mGuard bewogen haben, eine Neukonfiguration als fehlerhaft zu betrachten.

Download-Timeout

Standard: 2 Minuten (0:02:00)

Gibt an, wie lange während eines Downloads der Konfigurati­onsdatei ein Timeout (Zeit der Inaktivität) maximal dauern darf. Bei Überschreitung wird der Download abgebrochen. Ob und wann ein nächster Download-Versuch stattfindet, richtet sich nach der Einstellung von Zeitplan (s. o.).

Die Eingabe kann aus Sekunden [ss], Minuten und Sekunden [mm:ss] oder Stunden, Minuten und Sekunden [hh:mm:ss] bestehen.

Login

Login (Benutzername), den der HTTPS Server abfragt.

Passwort

Passwort, das der HTTPS Server abfragt.

Server-Zertifikat

Das Zertifikat, mit dem der mGuard prüft, dass das vom Kon­figurations-Server „vorgezeigte“ Zertifikat echt ist. Es verhin­dert, dass von einem nicht autorisierten Server falsche Konfi­gurationen auf dem mGuard installiert werden.

Hier darf entweder

–ein selbst signiertes Zertifikat des Konfigurations-Servers angegeben werden oder

–das Wurzelzertifikat der CA (Certification Authority), wel­che das Zertifikat des Servers ausgestellt hat. Das gilt dann, wenn es sich beim Zertifikat des Konfigurations-Servers um ein von einer CA signiertes Zertifikat handelt (statt um ein selbst signiertes)

.

–Das Passwort sollte aus mindestens 30 zufälligen Groß- und Kleinbuchstaben sowie Ziffern bestehen, um uner­laubten Zugriff zu verhindern.

–Der HTTPS Server sollte über den angegebenen Login nebst Passwort nur Zugriff auf die Konfiguration dieses ei­nen mGuard ermöglichen. Ansonsten könnten sich die Benutzer anderer mGuards Zugriff verschaffen.

Zum Installieren eines Zertifikats wie folgt vorgehen:

Voraussetzung: Die Zertifikatsdatei ist auf dem angeschlosse­nen Rechner gespeichert

•Durchsuchen... klicken, um die Datei zu selektieren.

•Importieren klicken.

Download-Test

Durch Klicken auf die Schaltfläche „Download testen“ kön­nen Sie testen – ohne die geänderten Parameter zu speichern oder das Konfigurationsprofil zu aktivieren – ob die angegebe­nen Parameter funktionieren. Das Ergebnis des Tests wird in der rechten Spalte angezeigt.

Die Verwendung von Firewall-Regelsätzen ist auf Geräten der FL MGUARD 2000-Serie nicht möglich.

Eingang/CMD 1-3 (I1-3)

Am Kontakt ange­schlossener Schalter­typ

Taster / Ein-/Aus-Schalter

Auswahl des Typs des angeschlossen Schalters.

Zustand des Ein­gangs/CMD 1-3 (I1-3)

Anzeige des Zustandes des angeschlossen Schalters.

Der Schalter muss beim Editieren der VPN-Verbindung unter „Schaltender Service Eingang/CMD“  auswählt werden (unter   „IPsec VPN >> Verbindungen >> Editieren >> Allgemein“  oder   „OpenVPN-Client >> Verbindungen >> Editieren >> Allge­mein“  ).

Über diesen Eingang kontrollierte VPN-Ver­bindungen oder Fire­wall-Regelsätze

Der  mGuard verfügt über Anschlüsse, an die externe Taster oder Ein-/Aus-Schalter und Aktoren (z. B. eine Signallampe) angeschlossen werden können.

Über den Taster bzw. Ein/Aus-Schalter können

–konfigurierten VPN-Verbindungen gestartet oder ge­stoppt werden,

–konfigurierte Firewall-Regelsätze aktiviert oder deakti­viert werden.

Welche Ereignisse durch den Eingang gesteuert werden, kann an folgenden Stellen konfiguriert werden:

1.IPsec-VPN:  „IPsec VPN >> Verbindungen >> Editieren >> Allgemein“  .

2.OpenVPN:  „OpenVPN-Client >> Verbindungen >> Editie­ren >> Allgemein“  

3.Firewall-Regelsatz:  „Netzwerksicherheit >> Paketfilter >> Regelsätze“  

Ausgang/ACK 1-2 (O1-2)

Zu überwachende VPN-Verbindung bzw. Firewall-Regelsatz

Aus / VPN-Verbindung/Firewall-Regelsatz

Der Zustand der ausgewählten VPN-Verbindung oder des ausgewählten Firewall-Regelsatzes wird über den zugehöri­gen Meldekontakt (ACK-Ausgang / O1-2) signalisiert.

Allgemein

Betriebsmodus

Funktions-Überwachung / Manuelle Einstellung

Der Alarmausgang kann automatisch durch die Funktions-Überwachung geschaltet werden (Standard) oder durch Ma­nuelle Einstellung.

Manuelle Einstellung

Geschlossen / Offen (Alarm)

Hier kann der gewünschte Zustand des Alarmausgangs ge­wählt werden (zur Funktionskontrolle):

Wird der Zustand manuell auf Offen (Alarm) gestellt, leuchtet die LED FAIL nicht rot (kein Alarm).

Funktions-Überwachung

Zustand des Alarm­ausgangs

Anzeige des Zustandes des Alarmausganges. Zusätzlich wird eine Meldung im WBM am oberen Bildschirmrand angezeigt.

Aktivierungsgrund des Alarmausgangs

Der Grund für die Aktivierung des Alarmausgangs wird ange­zeigt.

Redundante Stromver­sorgung

(Nur bei FL MGUARD 4302.)

Bei Ignorieren hat der Zustand der Stromversorgung keinen Einfluss auf den Alarmausgang.

Bei Überwachen wird der Alarmausgang geöffnet, wenn eine der zwei Versorgungsspannungen ausfällt.

Passwörter nicht konfiguriert 

Überwacht, ob die voreingestellten Administrator-Passwörter für die Benutzer root und admin geändert wurden.

Bei Ignorieren haben die nicht geänderten Passwörter kei­nen Einfluss auf den Alarmausgang.

Bei Überwachen wird der Alarmausgang geöffnet, wenn die voreingestellten Passwörter nicht geändert wurden.

Link-Überwachung

Überwachung des Link-Status der Ethernet-Anschlüsse.

Bei Ignorieren hat der Link-Status der Ethernet-Anschlüsse keinen Einfluss auf den Alarmausgang.

Bei Überwachen wird der Alarmausgang geöffnet, wenn ein­Link keine Konnektivität aufweist. Stellen Sie dazu unter   „Netzwerk >> Ethernet >> MAU-Einstellungen“   unter „Link-Überwachung“ die Links ein, die überwacht werden sollen.

Temperaturzustand

Der Alarmausgang meldet eine Über- oder Untertemperatur. Der zulässige Bereich wird unter   „Systemtemperatur (°C)“    im Menü   „Verwaltung >> Systemeinstellung >> Host“   eingestellt.

Bei Ignorieren hat die Temperatur keinen Einfluss auf den Meldekontakt.

Bei Überwachen wird der Alarmausgang geöffnet, wenn die Temperatur den zulässigen Bereich verlässt.

Verbindungsstatus der Redundanz

Nur wenn die Funktion Redundanz genutzt wird (siehe Kapitel 13).

Bei Ignorieren hat die Konnektivitätsprüfung keinen Einfluss auf den Alarmausgang.

Bei Überwachen wird der Alarmausgang geöffnet, wenn die Konnektivitätsprüfung fehlschlägt. Das ist unabhängig davon, ob der mGuard aktiv oder im Bereitschaftszustand ist.

Neustart

Neustart

Ein Klick auf die Schaltfläche „Neustart“ startet den mGuard neu (Reboot).

Das Gerät benötigt ca. 30 Sekunden für den Neustart.

Ein Neustart hat den selben Effekt wie die vorübergehende Unterbrechung der Stromzufuhr. Der mGuard wird aus- und wieder eingeschaltet.

Ein Neustart ist erforderlich im Fehlerfall. Außerdem kann ein Neustart nach einem Software-Update erforderlich sein.