Microsoft Windows-DNS-Daten erfassen

In diesem Dokument wird Folgendes behandelt:

  • Beschreibt die Bereitstellungsarchitektur und Installationsschritte sowie alle erforderlichen Konfigurationen, die Logs generieren, die vom Chronicle Parser für Microsoft Windows-DNS-Ereignisse unterstützt werden. Eine Übersicht über die Chronicle-Datenaufnahme finden Sie unter Datenaufnahme in Chronicle.
  • Enthält Informationen darüber, wie der Parser Felder im Originallog den Feldern von Chronicle Unified Data Model zuordnet.

Die Informationen in diesem Dokument gelten für den Parser mit dem Label "WINDOWS_DNS". Das Aufnahmelabel gibt an, welcher Parser die Rohprotokolldaten auf das strukturierte UDM-Format normalisiert.

Hinweis

  • Sehen Sie sich die empfohlene Bereitstellungsarchitektur an.

    Das folgende Diagramm zeigt die empfohlenen Kernkomponenten in einer Deployment-Architektur, mit denen Microsoft Windows-DNS-Ereignisse erfasst und an Chronicle gesendet werden. Vergleichen Sie diese Informationen mit Ihrer Umgebung, um sicherzustellen, dass diese Komponenten installiert sind. Jede Kundenbereitstellung unterscheidet sich von dieser Darstellung und ist möglicherweise komplexer. Folgendes ist erforderlich:

    • Microsoft Windows DNS-Server mit aktiviertem DNS-Diagnose-Logging.
    • Alle Systeme, die mit der UTC-Zeitzone konfiguriert sind.
    • NXLog ist auf geclusterten Microsoft Windows-Servern installiert, um Logs zu erfassen und an den zentralen Microsoft Windows- oder Linux-Server weiterzuleiten.
    • Chronicle-Forwarder, der auf dem zentralen Microsoft Windows- oder Linux-Server installiert ist.

    Bereitstellungsarchitektur

  • Prüfen Sie die unterstützten Geräte und Versionen.

    Der Chronicle-Parser unterstützt Logs aus den folgenden Microsoft Windows Server-Versionen. Microsoft Windows Server wird in den folgenden Versionen veröffentlicht: Foundation, Essentials, Standard und Datacenter. Das Ereignisschema der Logs, die von jeder Version generiert werden, unterscheidet sich nicht.

    • Microsoft Windows Server 2019
    • Microsoft Windows Server 2016
    • Microsoft Windows Server 2012 R2

    Der Chronicle-Parser unterstützt von NXLog Enterprise Edition erfasste Logs.

  • Prüfen Sie die unterstützten Logtypen. Der Chronicle-Parser unterstützt die folgenden Logtypen, die von Microsoft Windows-DNS-Servern generiert werden. Weitere Informationen zu diesen Logtypen finden Sie in der Dokumentation Microsoft Windows DNS-Logging und -Diagnose. Es werden Logs unterstützt, die mit Text in englischer Sprache generiert wurden. Logs, die in anderen Sprachen als Englisch generiert wurden, werden nicht unterstützt.

    • Audit-Logs: Eine Beschreibung dieses Logtyps finden Sie in der Dokumentation zu Windows-Audit-Logs.
    • Analytics-Logs: Eine Beschreibung dieses Logtyps finden Sie in der Dokumentation zu Microsoft Windows-Analytics-Logs.
  • Richten Sie die Microsoft Windows-DNS-Server ein. Informationen zum Installieren und Aktivieren des DNS-Diagnoseprotokolls finden Sie in der Microsoft Windows-Dokumentation.

  • Installieren und konfigurieren Sie den zentralen Windows- oder Linux-Server.

  • Konfigurieren Sie alle Systeme mit der UTC-Zeitzone.

NXLog- und Chronicle-Forwarder konfigurieren

  1. Installieren Sie NXLog auf jedem Microsoft Windows-DNS-Server. Folgen Sie der NXLog-Dokumentation.
  2. Erstellen Sie für jede NXLog-Instanz eine Konfigurationsdatei. Verwenden Sie das Eingabemodul im_etw zum Extrahieren von DNS-Analyselogs und das Eingabemodul im_msvistalog für Audit-Logs.

    Hier sehen Sie ein Beispiel für eine NXLog-Konfiguration. Ersetzen Sie die Werte für <hostname> und <port> durch die Informationen zum zentralen Microsoft Windows- oder Linux-Server. Wenn Sie Logs optional in JSON statt in XML konvertieren und parsen möchten, ändern Sie die Zeile Exec to_xml(); in Exec to_json();. Weitere Informationen finden Sie in der NXLog-Dokumentation zum om_tcp-Modul.

    define ROOT C:\Program Files\nxlog
    define WINDNS_OUTPUT_DESTINATION_ADDRESS <hostname>
    define WINDNS_OUTPUT_DESTINATION_PORT <port>
    
    Moduledir   %ROOT%\modules
    CacheDir    %ROOT%\data
    Pidfile     %ROOT%\data\nxlog.pid
    SpoolDir    %ROOT%\data
    LogFile     %ROOT%\data\nxlog.log
    
    <Extension syslog>
        Module      xm_syslog
    </Extension>
    
    # To collect XML logs, use the below NXLog module
    <Extension xml>
        Module      xm_xml
    </Extension>
    
    # To collect JSON logs, use the below NXLog module
    <Extension json>
        Module      xm_json
    </Extension>
    
    <Input eventlog>
        Module      im_etw
        Provider    Microsoft-Windows-DNSServer
    </Input>
    
    <Input auditeventlog>
        Module      im_msvistalog
        <QueryXML>
            <QueryList>
                <Query Id="0" Path="Microsoft-Windows-DNSServer/Audit">
                    <Select Path="Microsoft-Windows-DNSServer/Audit">*</Select>
                </Query>
            </QueryList>
        </QueryXML>
    </Input>
    
    <Output out_chronicle_windns>
        Module      om_tcp
        Host        %WINDNS_OUTPUT_DESTINATION_ADDRESS%
        Port        %WINDNS_OUTPUT_DESTINATION_PORT%
        Exec        $EventTime = integer($EventTime) / 1000;
        Exec        $EventReceivedTime = integer($EventReceivedTime) / 1000;
        Exec        to_xml(); # To collect JSON, use to_json()
    </Output>
    
    <Route analytical_windns_to_chronicle>
        Path    eventlog => out_chronicle_windns
    </Route>
    
    <Route audit_windns_to_chronicle>
        Path    auditeventlog => out_chronicle_windns
    </Route>
    
  3. Installieren Sie den Chronicle-Forwarder auf dem zentralen Microsoft Windows- oder Linux-Server. Informationen zum Installieren und Konfigurieren des Forwarders finden Sie unter Forwarder unter Linux installieren und konfigurieren oder Forwarder auf Microsoft Windows installieren und konfigurieren.

  4. Konfigurieren Sie den Chronicle-Forwarder, um Logs an Chronicle zu senden. Hier sehen Sie ein Beispiel für eine Forwarder-Konfiguration.

      - syslog:
          common:
            enabled: true
            data_type: WINDOWS_DNS
            batch_n_seconds: 10
            batch_n_bytes: 1048576
          tcp_address: 0.0.0.0:10518
          connection_timeout_sec: 60
    

Referenz zur Feldzuordnung: Geräteprotokollfelder zu UDM-Feldern

In diesem Abschnitt wird beschrieben, wie der Parser die ursprünglichen Felder des Geräteprotokolls den UDM-Feldern (Unified Data Model) zuordnet.

Allgemeine Felder

NXLog-Feld UDM-Feld Kommentieren
SourceName metadata.vendor_name = Microsoft“

metadata.product_name = Windows DNS Server
Ereignis-ID Sicherheit_Ergebnis.Regelname Gespeichert als "EventID: %{EventID}". Bei Ereignissen mit Fehler- und Warnstufe ist das Feld "is_alert" auf "true" gesetzt.
Schweregrad Sicherheit_Ergebnis.Schweregrad Die Werte werden dem UDM-Feld im folgenden Format zugeordnet:
0 (Keines) – UNKNOWN_SEVERITY
1 (Kritisch) – INFORMATIONAL
2 (Fehler) – ERROR
3 (Warnung) – FEHLER
4 (Information) – INFORMATIONAL
5 (Ausführlich) – INFORMATIONAL
Logo: EventTime metadata.event_timestamp
Ausführungs-ID Principal.process.pid / target.process.pid In der Datei target.process.pid gespeicherter Wert für die folgenden Ereignis-IDs
Wert, der in Principal.process.pid für alle anderen Ereignis-IDs gespeichert ist.
Kanal metadata.product_event_type
Hostname Principal.Hostname / Target.Hostname Der Wert wird in target.hostname“ für die folgenden Ereignis-IDs gespeichert: 256, 259, 261, 263, 266, 268, 270, 272, 273, 275, 278, 279, 280.

Der Wert wird im Hauptkonto (hostname) aller anderen Ereignis-IDs gespeichert.
User-ID Principal.user.windows_sid / target.user.windows_sid Sie sind in target.user.windows_sid für die folgenden Ereignis-IDs gespeichert: 256, 259, 261, 263, 266, 268, 270, 272, 273, 275, 278, 279 und 280.

Wird in Principal.user.windows_sid für alle anderen Ereignis-IDs gespeichert

Analyselogs

Ursprüngliches Logfeld UDM-Feld Kommentieren
AA network.dns.authoritative.
Ziel target.ip / Principal.ip Wird sowohl im Hauptkonto als auch im Ziel angegeben.
Schnittstelle IP target.ip / Principal.ip Speichert die IP-Adresse des DNS-Servers in target.ip für die folgenden Ereignis-IDs, 256, 259, 261, 263, 266, 268, 270, 272, 273, 275, 278, 279 und 280.
Wird in Principal.ip für alle anderen Ereignis-IDs (DNS-Antwort) gespeichert.
Paketdaten network.dns.answers.binary_data
Port target.port / Principal.port
QNAME network.dns.questions.name
QTYPE network.dns.questions.type
CODE network.dns.response_code
Logo: RD network.dns.recursion_desired
Grund Sicherheit_Ergebnis.Zusammenfassung
Quelle Principal.ip / Target.ip Quell-IPv4-/IPv6-Adresse der Maschine, die die DNS-Anfrage initiiert hat
In target.ip für Ereignis-ID 274 gespeichert. Gespeichert in target.ip für Ereignis-ID 265 und 269, InterfaceIP enthält die IP-Adresse (Haupt-IP) des sekundären Servers und die Quelle (Ziel) die IP-Adresse des primären Servers.
TCP network.ip_protocol
XID. network.dns.id

Audit-Logs

Ursprüngliches Logfeld UDM-Feld Hinweis
Name target.resource.name Der Wert wird aus Ereignissen mit der Ereignis-ID 512 erfasst.
Richtlinie target.resource.name Der Wert wird aus den Ereignissen mit der Ereignis-ID 577, 578, 579, 580, 581 und 582 erfasst. Diese sind den Ereignistypen Setting_* zugeordnet.
QNAME network.dns.questions.name
QTYPE network.dns.questions.type
RecursionScope target.resource.name Der Wert wird aus Ereignissen erfasst, die Ereignis-IDs enthalten, die den Ereignistypen SETTING_* zugeordnet sind.
Umfang target.resource.name Der Wert wird aus Ereignissen erfasst, die Ereignis-IDs enthalten, die den Ereignistypen SETTING_* zugeordnet sind.
Einstellung target.resource.name Der Wert wird aus Ereignissen erfasst, die Ereignis-IDs enthalten, die den Ereignistypen SETTING_* zugeordnet sind.
Quelle Hauptkonto
Zone target.resource.name Der Wert wird aus Ereignissen erfasst, die Ereignis-IDs enthalten, die den Ereignistypen SETTING_* zugeordnet sind.
Zonenbereich target.resource.name Der Wert wird aus Ereignissen erfasst, die Ereignis-IDs enthalten, die den Ereignistypen SETTING_* zugeordnet sind.

Feldzuordnungsreferenz: Ereignis-ID zu UDM-Ereignistyp

In diesem Abschnitt wird beschrieben, wie der Parser Ereignis-IDs UMP-Ereignistypen zuordnet. Im Allgemeinen werden Ereignisse dem NETWORK_DNS-metadata.event_type zugeordnet, mit Ausnahme von Ereignis-IDs im folgenden Abschnitt.

Ereignis-ID Ereignistext UDM-Ereignistyp Hinweise
275 XFR_NOTIFY_ACK_IN: Source=%1; InterfaceIP=%2; PacketData=%4 GENERIC_EVENT
276 IXFR_RESP_OUT: TCP=%1; InterfaceIP=%2; Destination=%3; QNAME=%4; XID=%5; ZoneScope=%6; Zone=%7; RCODE=%8; PacketData=%10 GENERIC_EVENT
512 EINSTELLUNG_CREATION
513 Die Zone %1 wurde gelöscht. EINSTELLUNG_EINSTELLUNG
514 Die Zone %1 wurde aktualisiert. Die Einstellung "%2" wurde auf "%3" gesetzt. einstellung_MODIFICATION
515 Ein Ressourceneintrag vom Typ %1, Name %2, TTL %3 und RDATA %5 wurde im Bereich %7 der Zone %6 erstellt. SYSTEM_AUDIT_LOG_UNCATEGORIZED
516 Ein Ressourceneintrag vom Typ %1, der Name %2 und der RDATA-Wert %5 wurden aus dem Bereich %7 der Zone %6 gelöscht. SYSTEM_AUDIT_LOG_UNCATEGORIZED
517 Alle Ressourceneinträge vom Typ %1 mit dem Namen %2 wurden aus dem Bereich %4 von Zone %3 gelöscht. SYSTEM_AUDIT_LOG_UNCATEGORIZED
518 Alle Ressourceneinträge am Knotennamen %1 wurden aus Bereich %3 der Zone %2 gelöscht. SYSTEM_AUDIT_LOG_UNCATEGORIZED
519 Ein Ressourceneintrag vom Typ %1, Name %2, TTL %3 und RDATA %5 wurde über dynamische Aktualisierung von IP-Adresse %8 im Bereich %7 von Zone %6 erstellt. SYSTEM_AUDIT_LOG_UNCATEGORIZED
520 Ein Ressourceneintrag vom Typ %1, den Namen %2 und den RDATA-Wert %5 wurde durch dynamische Aktualisierung von der IP-Adresse %8 aus dem Bereich %7 der Zone %6 gelöscht. SYSTEM_AUDIT_LOG_UNCATEGORIZED
521 Ein Ressourceneintrag vom Typ %1, der Name %2, die TTL %3 und der RDATA %5 wurden aus dem Bereich %7 der Zone %6 entfernt. SYSTEM_AUDIT_LOG_UNCATEGORIZED
522 Der Bereich %1 wurde in Zone %2 erstellt. EINSTELLUNG_CREATION
523 Der Bereich %1 wurde in Zone %2 gelöscht. EINSTELLUNG_EINSTELLUNG
525 Die Zone %1 wurde mit den folgenden Properties signiert: DenialOfExistence=%2; DistributedTrustAnchor=%3; DnsKeyRecordSetTtl=%4; DSRecordGenerationAlgorithm=%5; DSRecordSetTtl=%6; EnableRfc5011KeyMouse=%1%1NSecSecure2%11%Sec SYSTEM_AUDIT_LOG_UNCATEGORIZED
526 Die Zone %1 wurde signiert. SYSTEM_AUDIT_LOG_UNCATEGORIZED
527 Die Zone %1 wurde mit den folgenden Attributen neu signiert: DenialOfExistence=%2; TrustTrustAnchor=%3; DnsKeyRecordSetTtl=%4; DSRecordGenerationAlgorithm=%5; DSRecordSetTtl=%6; ReadRfc5011KeyMouse%%3%1%Hash%23%2%Sec3 SYSTEM_AUDIT_LOG_UNCATEGORIZED
528 Mouseover wurde beim Typ %1 mit der GUID %2 der Zone %3 gestartet. SYSTEM_AUDIT_LOG_UNCATEGORIZED
529 Das Mouseover wurde auf dem Typ %1 mit der GUID %2 der Zone %3 abgeschlossen. SYSTEM_AUDIT_LOG_UNCATEGORIZED
530 Der Typ "%1" mit der GUID %2 der Zone "%3" wurde als retrikulär gekennzeichnet. Der Schlüssel wird nach Abschluss des Mouseovers entfernt. SYSTEM_AUDIT_LOG_UNCATEGORIZED
531 Der manuelle Mouseover wurde auf dem Typ %1 mit der GUID %2 der Zone %3 ausgelöst. SYSTEM_AUDIT_LOG_UNCATEGORIZED
533 Die Schlüssel zum Signieren des Schlüssels mit der GUID %1 in Zone %2, die auf eine Aktualisierung des Delegationssignaturs(DS) auf der übergeordneten Ebene warteten, wurden zum Abschluss des Mouseovers gezwungen. SYSTEM_AUDIT_LOG_UNCATEGORIZED
534 Die DNSSEC-Einstellungsmetadaten wurden %1-Schlüsselsignaturschlüsselschlüssel aus Zone %2 exportiert. SYSTEM_AUDIT_LOG_UNCATEGORIZED
535 DNSSEC-Einstellungsmetadaten wurden in Zone %1 importiert. SYSTEM_AUDIT_LOG_UNCATEGORIZED
536 Ein Datensatz vom Typ %1, QNAME %2 wurde im Bereich %3 im Cache gelöscht. SYSTEM_AUDIT_LOG_UNCATEGORIZED
537 Die Forwarder-Liste für Bereich %2 wurde auf %1 zurückgesetzt. einstellung_MODIFICATION target.resource.name wird auf Forwarder-Liste auf Bereich festgelegt: %{scope_name}"
540 Die Stammhinweise wurden geändert. einstellung_MODIFICATION Der Name der Datei target.resource.name wird mit dem Root-Hinweis gefüllt
541 Die Einstellung "%1" für den Bereich "%2" wurde auf "%3" festgelegt. einstellung_MODIFICATION
542 Der Bereich %1 des DNS-Servers wurde erstellt. EINSTELLUNG_CREATION
543 Der Bereich %1 des DNS-Servers wurde gelöscht. EINSTELLUNG_EINSTELLUNG
544 Der DNSKEY mit dem Schlüsselprotokoll %2, dem Base64-Datenwert %4 und dem kryptografischen Algorithmus %5 wurde am Vertrauenspunkt %1 hinzugefügt. SYSTEM_AUDIT_LOG_UNCATEGORIZED
545 Das DS mit Schlüsseltag: %2, Digesttyp: %3, Digest: %5 und kryptografischer Algorithmus: %6 wurde am Vertrauenspunkt %1 hinzugefügt. SYSTEM_AUDIT_LOG_UNCATEGORIZED
546 Der vertrauenswürdige Punkt bei %1 des Typs %2 wurde entfernt. SYSTEM_AUDIT_LOG_UNCATEGORIZED
547 Der Trust Anchor für die Root-Zone wurde hinzugefügt. SYSTEM_AUDIT_LOG_UNCATEGORIZED
548 Eine Anfrage zum Neustart des DNS-Serverdienstes wurde empfangen. SYSTEM_AUDIT_LOG_UNCATEGORIZED
549 Die Debug-Protokolle wurden von %1 auf dem DNS-Server gelöscht. SYSTEM_AUDIT_LOG_WIPE
550 Der Speicherinhalt aller Zonen auf dem DNS-Server wurde in die entsprechenden Dateien geleert. SYSTEM_AUDIT_LOG_UNCATEGORIZED
551 Alle statistischen Daten für den DNS-Server wurden gelöscht. SYSTEM_AUDIT_LOG_WIPE
552 Auf dem DNS-Server wurde ein Bereinigungszyklus für Ressourceneinträge gestartet. SYSTEM_AUDIT_LOG_UNCATEGORIZED
553 %1 SYSTEM_AUDIT_LOG_UNCATEGORIZED
554 Der Bereinigungszyklus für Ressourceneinträge wurde auf dem DNS-Server beendet. SYSTEM_AUDIT_LOG_UNCATEGORIZED
555 Der DNS-Server wurde für die Abwertung vorbereitet, indem Verweise auf ihn aus allen in Active Directory gespeicherten Zonen entfernt wurden. SYSTEM_AUDIT_LOG_UNCATEGORIZED
556 Die Informationen zu den Root-Hinweisen auf dem DNS-Server wurden in den nichtflüchtigen Speicher zurückgeschrieben. SYSTEM_AUDIT_LOG_UNCATEGORIZED
557 Die Adressen, die der DNS-Server überwacht, wurden in %1 geändert. einstellung_MODIFICATION Der Feld "target.resource.name" wird mit dem Text "Listener-Adressen" gefüllt
558 Für alle Trust Points wurde eine sofortige RFC 5011-Aktualisierung geplant. SYSTEM_AUDIT_LOG_UNCATEGORIZED
559 Die Zone %1 ist angehalten. SYSTEM_AUDIT_LOG_UNCATEGORIZED
560 Die Zone %1 wird fortgesetzt. SYSTEM_AUDIT_LOG_UNCATEGORIZED
561 Die Daten für Zone %1 wurden von %2 neu geladen. SYSTEM_AUDIT_LOG_UNCATEGORIZED
562 Die Daten für Zone %1 wurden vom Master-Server %2 aktualisiert. SYSTEM_AUDIT_LOG_UNCATEGORIZED
563 Die sekundäre Zone %1 ist abgelaufen und neue Daten wurden vom Masterserver %2 angefordert. SYSTEM_AUDIT_LOG_UNCATEGORIZED
564 Die Zone %1 wurde aus dem Active Directory neu geladen. SYSTEM_AUDIT_LOG_UNCATEGORIZED
565 Der Inhalt der Zone %1 wurde auf das Laufwerk geschrieben und die Benachrichtigung wurde an alle Benachrichtigungsserver gesendet. einstellung_MODIFICATION
566 Für alle DNS-Einträge am Knoten %1 in der Zone %2 wird der Zeitstempel der alten Zeit auf die aktuelle Zeit gesetzt.%3 SYSTEM_AUDIT_LOG_UNCATEGORIZED
567 Die in Active Directory integrierte Zone %1 wurde aktualisiert. Nur %2 kann Scaving ausführen. SYSTEM_AUDIT_LOG_UNCATEGORIZED
568 Die Schlüsselmasterrolle für Zone %1 wurde %2.%3. SYSTEM_AUDIT_LOG_UNCATEGORIZED
569 Der Deskriptor %1 singing (%2) wurde für die Zone %3 mit den folgenden Eigenschaften hinzugefügt: KeyId=%4; KeyType=%5; CurrentState=%6; KeyStorageProvider=%7; StoreKeysInAD=%8; CryptoAlgorithm=%1%1%12Key%%2%2%%2%2 aufgerufen%2%%%2%2 aufgerufen%%2 zusammen>%10%12%22%23%2 heraus. Die Zone wird mit dem mit diesen Attributen generierten %2 neu signiert. SYSTEM_AUDIT_LOG_UNCATEGORIZED
570 Ein %1-Singing-Schlüssel-Deskriptor (%2) mit der GUID %3 wurde für die Zone %4 aktualisiert. Die Eigenschaften dieses %2 Deskriptors wurden eingestellt auf: KeyId=%5; KeyType=%6; CurrentState=%7; KeyStorageProvider=%8; StoreKeysInAD=%9; CryptoAlgorithm=%12; KeyLength=%12%2%%22%2%%2%2%%%2% zugänglich perPosition über normalerweise Die Zone wird mit dem mit diesen Attributen generierten %2 neu signiert. SYSTEM_AUDIT_LOG_UNCATEGORIZED
571 Ein %1-Singing-Schlüssel-Deskriptor (%2) %4 wurde aus der Zone %3 entfernt. SYSTEM_AUDIT_LOG_UNCATEGORIZED
572 Der Status des %1-Signaturschlüssels (%2) %3 wurde für die Zone %4 geändert. Der neue aktive Schlüssel ist %5, der Standby-Schlüssel ist %6 und der nächste Schlüssel ist %7. SYSTEM_AUDIT_LOG_UNCATEGORIZED
573 Eine Delegierung für %1 im Bereich %2 der Zone %3 mit dem Nameserver %4 wurde hinzugefügt. SYSTEM_AUDIT_LOG_UNCATEGORIZED
574 Der Client-Subnetzeintrag mit dem Namen %1, Wert %2, wurde der Client-Subnetzzuordnung hinzugefügt. SYSTEM_AUDIT_LOG_UNCATEGORIZED
575 Der Clientsubnetzeintrag mit dem Namen %1 wurde aus der Clientsubnetzzuordnung gelöscht. SYSTEM_AUDIT_LOG_UNCATEGORIZED
576 Der Client-Subnetz-Eintrag mit dem Namen %1 wurde von der Client-Subnetzzuordnung aktualisiert. Das neue Clientsubnetz, auf das es sich bezieht, ist %2. SYSTEM_AUDIT_LOG_UNCATEGORIZED
577 Auf Serverebene %2 wurde eine Serverrichtlinie %6 mit den folgenden Eigenschaften erstellt: ProcessingOrder:%3; Kriterien:%4; Aktion:%5. EINSTELLUNG_CREATION
578 Eine Richtlinienrichtlinie %8 für %1 wurde für Zone %6 auf Server %2 mit den folgenden Eigenschaften erstellt: ProcessingOrder:%3; Kriterien:%4; Aktion:%5; Bereiche:%7. EINSTELLUNG_CREATION
579 Auf dem Server %2 wurde eine Weiterleitungsrichtlinie %6 mit den folgenden Eigenschaften erstellt: ProcessingOrder:%3; Kriterien:%4; Aktion:%5; Bereich:%1. EINSTELLUNG_CREATION
580 Die Serverrichtlinie %1 wurde von Server %2 gelöscht. EINSTELLUNG_EINSTELLUNG
581 Die Richtlinienrichtlinie %1 wurde von Zone %3 auf Server %2 gelöscht. EINSTELLUNG_EINSTELLUNG
582 Die Weiterleitungsrichtlinie %1 wurde vom Server %2 gelöscht. EINSTELLUNG_EINSTELLUNG