Firewalls verwalten

IBM Cloud® Virtual Router Appliance (VRA) kann Firewallregeln verarbeiten, um die über die Einheit gesteuerten VLANs zu schützen.

Für die Firewalls in der VRA können die beiden folgenden Schritte unterschieden werden:

Einen oder mehrere Regelsätze definieren
Anwendung einer Reihe von Regeln auf eine Schnittstelle oder eine Zonenrichtlinie. (eine Zone besteht aus einer oder mehreren Netzschnittstellen) Eine Zonenrichtlinie wird für Datenverkehr definiert, der von einer Zone in eine andere Zone durchquert wird.

Erstellte Firewallregeln sollten unbedingt getestet werden, um sicherzustellen, dass sie die erwartete Wirkung haben und nicht den Verwaltungszugriff auf die Einheit einschränken.

Es wird empfohlen, beim Bearbeiten von Regeln in der Schnittstelle dp0bond1 die Verbindung zu der Einheit mit dp0bond0 herzustellen. Die Verbindung zur Konsole kann auch über IPMI (Intelligent Platform Management Interface) hergestellt werden.

Statusunabhängig gegenüber statusabhängig

Die Firewall ist standardmäßig vom Status unabhängig, aber Sie kann bei Bedarf auch statusabhängig konfiguriert werden. Eine statusunabhängige Firewall erfordert Regeln für den Datenverkehr in beide Richtungen. Statusabhängige Firewalls dagegen verfolgen Verbindungen und ermöglichen automatisch den Rückfluss des akzeptierten Datenverkehrs. Zum Konfigurieren einer statusabhängigen Firewall müssen Sie festlegen, welche Regeln statusabhängig befolgt werden sollen.

Führen Sie die folgenden Befehle aus, um eine statusabhängige Verfolgung von tcp-, udp- oder icmp-Datenverkehr zu aktivieren.

set security firewall global-state-policy icmp
set security firewall global-state-policy tcp
set security firewall global-state-policy udp

Beachten Sie, dass die Befehle global-state-policy nur den Status des Verkehrs verfolgen, der mit einer Firewallregel übereinstimmt, die explizit das entsprechende Protokoll definiert. Beispiel:

set security firewall name GLOBAL_STATELESS rule 1 action accept

Da GLOBAL_STATELESS nicht protocol tcp definiert, gilt der Befehl global-state-policy tcp nicht für diese Regel.

set security firewall name GLOBAL_STATEFUL_TCP rule 1 action accept
set security firewall name GLOBAL_STATEFUL_TCP rule 1 protocol tcp

In diesem Fall wird protocol tcp explizit definiert. Der Befehl global-state-policy tcp aktiviert die statusabhängige Verfolgung von Datenverkehr, der mit Regel 1 von GLOBAL_STATEFUL_TCP übereinstimmt.

Führen Sie folgende Befehle aus, um einzelne Firewallregeln als statusabhängig zu definieren:

set security firewall name TEST rule 1 allow
set security firewall name TEST rule 1 state enable

Mit diesen Befehlen wird die statusabhängige Verfolgung des gesamten Datenverkehrs aktiviert, der statusabhängig verfolgt werden kann und mit Regel 1 von TEST übereinstimmt. Die Verfolgung geschieht unabhängig davon, ob der Befehl global-state-policy vorhanden ist.

ALG für unterstützte statusabhängige Verfolgung

Einige wenige Protokolle wie zum Beispiel FTP verwenden komplexere Sitzungen, die bei normalem statusabhängigen Firewallbetrieb verfolgt werden können. Es gibt vorkonfigurierte Module, die eine statusabhängige Verwaltung dieser Protokolle ermöglichen.

Es wird empfohlen, diese ALG-Module zu inaktivieren, solange sie nicht für die erfolgreiche Verwendung der jeweiligen Protokolle erforderlich sind.

set system alg ftp 'disable'
set system alg icmp 'disable'
set system alg pptp 'disable'
set system alg rpc 'disable'
set system alg rsh 'disable'
set system alg sip 'disable'
set system alg tftp 'disable'

Firewallregelsätze

Firewallregeln werden zu benannten Regelsätzen gruppiert, um das Anwenden von Regeln auf mehrere Schnittstellen zu erleichtern. Jedem Regelsatz wird eine Standardaktion zugeordnet. Sehen Sie sich dazu das folgende Beispiel an:

set security firewall name ALLOW_LEGACY default-action accept
set security firewall name ALLOW_LEGACY rule 1 action drop
set security firewall name ALLOW_LEGACY rule 1 source address network-group1
set security firewall name ALLOW_LEGACY rule 2 action drop
set security firewall name ALLOW_LEGACY rule 2 destination port 23
set security firewall name ALLOW_LEGACY rule 2 log
set security firewall name ALLOW_LEGACY rule 2 protocol tcp
set security firewall name ALLOW_LEGACY rule 2 source address network-group2

In dem Regelsatz ALLOW_LEGACY sind zwei Regeln definiert. Die erste Regel löscht jeden Datenverkehr, der von einer Adressgruppe namens network-group1 stammt. Die zweite verwirft und protokolliert jeglichen Verkehr, der für den Telnet-Port (tcp/23) von der Adressgruppe namens network-group2 bestimmt ist. Die Standardaktion bedeutet, dass alles andere akzeptiert wird. Es hat sich bewährt, nur den erforderlichen Datenverkehr zuzulassen und dann den Rest mit der Standardaktion des Regelsatzes zu blockieren.

Zugriff auf das Rechenzentrum zulassen

IBM Cloud hostet viele Teilnetze (private Servicenetze), die Services und Unterstützung für Client-Server, die in ihren Rechenzentren ausgeführt werden, bereitstellen. Beispielsweise werden die DNS-Resolver-Services unter 10.0.80.11 und 10.0.80.12 und der NTP-Standardserver unter 10.0.77.54 ausgeführt. Alle drei befinden sich im 10.0.64.0/29-Servicenetz. Für Bereitstellung und Support werden andere Teilnetze verwendet. Sie finden die privaten Servicenetze, die in den Rechenzentren verwendet werden, in diesem Abschnitt.

Sie können den Zugriff auf das Rechenzentrum zulassen, indem Sie am Anfang des Firewallregelsatzes entsprechende Regeln für SERVICE-ALLOW mit einer Aktion accept einfügen. Wo der Regelsatz angewendet werden muss, hängt vom implementierten Routing- und Firewalldesign ab.

Es wird empfohlen, die Firewallregeln an der Speicherposition zu platzieren, die am wenigsten doppelten Arbeitsaufwand verursacht. Beispiel: Das Zulassen von Back-End-Teilnetzen für ankommende Daten über dp0bond0 verursacht weniger Arbeitsaufwand als das Zulassen von Back-End-Teilnetzen für abgehende Daten an jede virtuelle VLAN-Schnittstelle.

Schnittstellenspezifische Firewallkonfiguration

Eine Methode zum Konfigurieren der Firewall in einer VRA besteht darin, Firewallregelsätze auf jede Schnittstelle anzuwenden. In diesem Fall kann eine Schnittstelle eine interne VLAN-Schnittstelle (z. B. dp0bond0.1303), eine der externen Schnittstellen (dp0bond0 (privat) oder dp0bond1 (öffentlich)) oder Tunnelschnittstellen (z. B. tun0 oder vti0) sein. Für jede Schnittstelle sind drei Firewallzuweisungen möglich:

in- Die Firewall filtert Pakete, die an der Schnittstelle ankommen. Diese Pakete können entweder über die VRA laufen oder für sie bestimmt sein.

out- Die Firewall filtert Pakete, die die Schnittstelle verlassen. Diese Pakete können entweder über die VRA laufen oder für sie bestimmt sein.

local- Die Firewall wird auf Pakete geprüft, die für die VRA bestimmt sind. Die Loopback-Schnittstelle lo kann zum Filtern des lokalen eingehenden Datenverkehrs in jeder Schnittstelle verwendet werden. Auf local angewendete Firewallfilter und Regelsätze werden nach allen Firewallregelsätzen verarbeitet, die als in auf eine beliebige Schnittstelle angewendet werden.

Eine Schnittstelle kann über mehrere Regelsätze verfügen, die in jeder Richtung angewendet werden. Sie werden in der Reihenfolge der Konfiguration angewendet. Beachten Sie, dass dies nicht für Firewalldatenverkehr gilt, der von der VRA-Einheit mit Firewalls für einzelne Schnittstellen stammt.

Um zum Beispiel den Regelsatz ALLOW_LEGACY der Option in für die Schnittstelle dp0bond1 zuzuweisen, würden Sie den Konfigurationsbefehl verwenden:

set interfaces bonding dp0bond1 firewall in ALLOW_LEGACY

Steuerebenenvorgabe (Control Plane Policing, CPP)

Die Steuerebenenvorgabe (Control Plane Policing, CPP) bietet Schutz vor Angriffen auf IBM Cloud® Virtual Router Appliance, indem Firewallrichtlinien konfiguriert werden, die den gewünschten Schnittstellen zugewiesen und auf ankommende Pakete in der VRA angewendet werden.

CPP wird implementiert, wenn das Schlüsselwort local in Firewallrichtlinien verwendet wird, die einem beliebigen VRA-Schnittstellentyp zugewiesen sind (z. B. Datenebenen- oder Loopback-Schnittstellen). Im Unterschied zu Firewallregeln für durch die VRA durchgeleitete Datenpakete verwenden Firewallregeln für ankommenden oder abgehenden Datenverkehr auf der Steuerebene die Standardaktion Allow. Wenn dieses Standardverhalten nicht erwünscht ist, muss der Benutzer explizite Löschregeln hinzufügen.

Die VRA stellt einen CPP-Basisregelsatz als Vorlage bereit. Führen Sie den folgenden Befehl aus, um diese Vorlage mit Ihrer Konfiguration zusammenzuführen:

vyatta@vrouter# merge /opt/vyatta/etc/cpp.conf

Nachdem der Regelsatz mit der Konfiguration zusammengeführt wurde, wird ein neuer Firewallregelsatz mit dem Namen CPP hinzugefügt und auf die Loopback-Schnittstelle angewendet. Es wird empfohlen, diesen Regelsatz an Ihre Umgebung anzupassen.

Bitte beachten Sie, dass CPP-Regeln nicht statusabhängig sein können und nur für eingehenden Datenverkehr gelten.

Zonenbasierte Firewallkonfiguration

In zonenbasierten Firewallkonfigurationen sind einer Zone mindestens eine Schnittstelle zugeordnet (obwohl eine Schnittstelle nicht mehreren Zonen zugeordnet werden kann) und Firewallregelsätze werden von einer Zone auf eine andere angewendet. Bei einer Einzelzonenrichtlinie wird der Datenverkehr gefiltert, wenn er von der ersten Zone an die zweite Zone übergeben wird, und die Filterung erfolgt nur in der Schnittstelle für abgehende Daten/Egress. In jeder Zone wird der ankommende Datenverkehr gelöscht, wenn er nicht explizit zugelassen wurde.

Eine Schnittstelle kann entweder zu einer Zone gehören oder eine Firewall-Konfiguration pro Schnittstelle haben; beides geht nicht.

Stellen Sie sich das folgende Büroszenario mit drei Abteilungen vor, wobei jede Abteilung über ein eigenes VLAN verfügt:

Abteilung A - VLANs 10 und 20 (Schnittstellen dp0bond1.10 und dp0bond1.20)
Abteilung B - VLANs 30 und 40 (Schnittstellen dp0bond1.30 und dp0bond1.40)
Abteilung C - VLAN 50 (Schnittstelle dp0bond1.50)

Für jede Abteilung kann eine Zone erstellt werden und die zugehörigen Schnittstellen können zu der Zone hinzugefügt werden. Dies wird im folgenden Beispiel veranschaulicht:

set security zone-policy zone DEPARTMENTA interface dp0bond1.10
set security zone-policy zone DEPARTMENTA interface dp0bond1.20
set security zone-policy zone DEPARTMENTB interface dp0bond1.30
set security zone-policy zone DEPARTMENTB interface dp0bond1.40
set security zone-policy zone DEPARTMENTC interface dp0bond1.50

Der Befehl commit belegt jede Zone als eine Schnittstelle und die Standardlöschregeln löschen jeden Datenverkehr, der die Zone von außen erreicht. Im vorliegenden Beispiel können VLAN 10 und VLAN 20 Datenpakete übermitteln, da sie zur selben Zone (DEPARTMENTA) gehören, während VLAN 10 und VLAN 30 keine Datenpakete übermitteln können, da VLAN 30 zu einer anderen Zone (DEPARTMENTB) gehört.

Die Schnittstellen in jeder Zone können Datenverkehr ungehindert weiterleiten und es können Regeln für die Interaktion zwischen den Zonen definiert werden. Ein Regelsatz für den Übergang von Daten aus einer Zone in eine andere Zone wird konfiguriert.

Der folgende Befehl enthält ein Beispiel für das Konfigurieren einer Regel:

set security zone-policy zone DEPARTMENTC to DEPARTMENTB firewall ALLOW_PING

Dieser Befehl verknüpft den Übergang von DEPARTMENTC zu DEPARTMENTB mit dem Regelsatz namens ALLOW_PING. Der Verkehr, der aus der Zone DEPARTMENTC in die Zone DEPARTMENTB gelangt, wird anhand dieses Regelsatzes überprüft.

Es ist wichtig zu verstehen, dass diese Zuordnung von der Zone DEPARTMENTC in die Zone DEPARTMENTB keine Aussage über die Umkehrung macht. Wenn es keine Regeln gibt, die den Verkehr von der Zone DEPARTMENTB in die Zone DEPARTMENTC erlauben, dann wird der Verkehr (ICMP-Antworten) nicht zu den Hosts in DEPARTMENTC zurückkehren.

ALLOW_PING würde als out Firewall auf die Schnittstellen der Zone DEPARTMENTB (dp0bond1.30 und dp0bond1.40) angewendet werden. Da dies von der Zonenrichtlinie installiert wird, wird nur der Verkehr, der von den Schnittstellen der Quellzone (dp0bond1.50) ausgeht, anhand des Regelsatzes überprüft.

Beispiel für zonenbasierte Firewall

Das folgende Beispiel enthält Details zu einer Firewallumgebung, die das gesamte eggressing-und ingressing für den Datenverkehr einer VRA überwacht und debuggt.

Das Hinzufügen von "log" zu Regel 1 wirkt sich stark auf die Leistung aus und sollte nur für das Debugging verwendet werden.

Lassen Sie Ihre öffentlichen Schnittstellen nie weit offen, wie in diesem Beispiel.

set security zone-policy zone Public-and-VTI interface dp0bond1
set security zone-policy zone Public-and-VTI interface vti2
set security zone-policy zone Public-Inside interface dp0bond1.807
set security zone-policy zone Private-Outside interface dp0bond0
set security zone-policy zone Private-Inside interface dp0bond0.829

#ruleset to allow all statefully and log every packet
set security firewall name AllowAllLogALL rule 1 action accept
set security firewall name AllowAllLogALL rule 1 log
set security firewall name AllowAllLogALL rule 1 state enable

#security policy pair between public/IPSec and private network servers
set security zone-policy zone Public-and-VTI to Private-Inside firewall AllowAllLogALL
set security zone-policy zone Private-Inside to Public-and-VTI firewall AllowAllLogALL

#security policy pair between public/IPSec and public network servers
set security zone-policy zone Public-and-VTI to Public-Inside firewall AllowAllLogALL
set security zone-policy zone Public-Inside to Public-and-VTI firewall AllowAllLogALL

#security policy pair between service networks/private outside and private network customer servers
set security zone-policy zone Private-Outside to Private-Inside firewall AllowAllLogALL
set security zone-policy zone Private-Inside to Private-Outside firewall AllowAllLogALL

Fehlerbehebung für Firewallregeln

Sie können Fehler in interace-basierten und zonenbasierten Firewallkonfigurationen beheben.

Fehlerbehebung für schnittstellenbasierte Firewallkonfigurationen

Um mit der Überprüfung und Fehlerbehebung zu beginnen, führen Sie die folgenden Befehle aus, um die Konfiguration der Richtlinien zu verstehen:

Um zu erfassen, welche Firewallregelsätze auf die einzelnen Schnittstellen angewendet werden und in welche Richtung sie angewendet werden, führen Sie show configuration commands | grep firewall | grep interface aus.
Mithilfe der Ausgabe von Schritt 1 können Sie alle Regeln finden, die auf die Schnittstellen in dem Flow angewendet wurden, den Sie zu überprüfen versuchen, indem Sie show configuration commands | grep -iE '<name of firewall ruleset>'. ausführen.
Überprüfen Sie die Regeln, um sicherzustellen, dass die richtigen Teilnetze, Ports und Protokolle zulässig sind.
- Wenn Sie die Fehlerbehebung für das Servicenetz zur privaten Serverkonnektivität durchführen und der Regelsatz in auf die VIFs (dp0bond0.XXX) angewendet wird, müssen Sie die Servicenetze als Ziele definieren. Dies liegt daran, wenn Datenverkehr in die VIF fließt, d. h. wenn der Client-Server abgehenden Datenverkehr sendet.
- Wenn Sie die Fehlerbehebung für das Servicenetz zur privaten Serverkonnektivität durchführen und der Regelsatz out der VIFs (dp0bond0.XXX) angewendet wird, müssen Sie die Servicenetze als Quellen definieren. Dies liegt daran, dass der Datenverkehr aus der VIF in Richtung der Client-Server fließt.
- Wenn Sie bei der Verbindung zwischen dem Servicenetzwerk und dem privaten Server eine Störung beheben und der Regelsatz in auf die Schnittstelle dp0bond0 angewendet wird, müssen Sie die Servicenetzwerke als Quellen definieren. Dies liegt daran, dass der Datenverkehr, der in die dp0bond0-Schnittstelle fließt, in der Regel für die Server hinter dem Vyatta bestimmt ist.
- Wenn Sie die Konnektivität zwischen dem Servicenetz und dem privaten Server beheben und der Regelsatz out der dp0bond0-Schnittstelle angewendet wird, müssen Sie die Servicenetze als Ziele definieren. Dies liegt daran, dass der Datenverkehr aus dp0bond0 in die Richtung von den Client-Servern, die sich hinter Vyatta befinden, weggeht.

Fehlerbehebung bei zonenbasierten Firewallkonfigurationen

Um mit der Überprüfung und Fehlerbehebung zu beginnen, führen Sie die folgenden Befehle aus, um die Konfiguration der Richtlinien zu verstehen:

Um anzuzeigen, welche Schnittstellen sich in welchen Zonen befinden, führen Sie show configuration commands | grep zone | grep interface aus.
Anhand der Ausgabe aus Schritt 1 können Sie den Firewallregelsatz ermitteln, der in jeder Zonenrichtlinie angewendet wurde, indem Sie show configuration commands | grep <name of zone> | grep <name of other zone> ausführen.
Mithilfe der Ausgabe von Schritt 2 können Sie alle Regeln finden, die auf die Schnittstellen in dem Flow angewendet wurden, den Sie durch Ausführen von show configuration commands | grep -iE '<name of firewall ruleset>|<name of other firewall ruleset>' überprüfen möchten.
Überprüfen Sie die Regeln, um sicherzustellen, dass die richtigen Teilnetze, Ports und Protokolle zulässig sind.
- Wenn Sie die Fehlerbehebung für das Servicenetz zur privaten Serverkonnektivität durchführen und die Richtlinie von den VIFs (dp0bond0.XXX) zu dp0bond0 stammt, müssen Sie die Servicenetze als Ziel definieren.
- Für Richtlinien von dp0bond0 zu den VIFs (dp0bond0.XXX) müssen Sie die Servicenetze als Quellen definieren.

Das folgende Beispiel enthält Details zu den Befehlen, mit denen Sie die Informationen extrahieren können, die erforderlich sind, um festzustellen, ob die Firewall die Servicenetze zulassen sollte.

vyatta@gateway02:~$ show configuration commands | grep zone | grep interface
set security zone-policy zone SL-Private-Servers interface 'dp0bond0.1750'
set security zone-policy zone SL-Private-Servers interface 'dp0bond0.1623'
set security zone-policy zone SL-Service interface 'dp0bond0'

vyatta@gateway02:~$ show configuration commands | grep SL-Private-Servers | grep SL-Service
set security zone-policy zone SL-Private-Servers to SL-Service firewall 'To-Private-Service-Network'
set security zone-policy zone SL-Service to SL-Private-Servers firewall 'To-Private-Servers'

vyatta@gateway02:~$ show configuration commands | grep -iE 'To-Private-Service-Network|To-Private-Servers'
set security firewall name To-Private-Servers rule 1 action 'accept'
set security firewall name To-Private-Servers rule 1 source address 'ServiceNetwork'
set security firewall name To-Private-Service-Network rule 1 action 'accept'
set security firewall name To-Private-Service-Network rule 1 destination address 'ServiceNetwork'
set security zone-policy zone SL-Private-Servers to SL-Service firewall 'To-Private-Service-Network'
set security zone-policy zone SL-Service to SL-Private-Servers firewall 'To-Private-Servers'

#Pull the actual subnets that I'm allowing via the defined ServiceNetwork addresses:
vyatta@gateway02:~$ show configuration commands | grep ServiceNetwork
set resources group address-group ServiceNetwork address '10.0.86.0/24'
set resources group address-group ServiceNetwork address '10.2.128.0/20'
set resources group address-group ServiceNetwork address '10.1.176.0/20'
set resources group address-group ServiceNetwork address '10.1.64.0/19'
set resources group address-group ServiceNetwork address '10.1.96.0/19'
set resources group address-group ServiceNetwork address '10.1.192.0/20'
set resources group address-group ServiceNetwork address '10.1.160.0/20'
set resources group address-group ServiceNetwork address '10.2.32.0/20'
set resources group address-group ServiceNetwork address '10.2.64.0/20'
set resources group address-group ServiceNetwork address '10.2.112.0/20'
set resources group address-group ServiceNetwork address '10.2.160.0/20'
set resources group address-group ServiceNetwork address '10.1.208.0/20'
set resources group address-group ServiceNetwork address '10.2.80.0/20'
set resources group address-group ServiceNetwork address '10.2.144.0/20'
set resources group address-group ServiceNetwork address '10.2.48.0/20'
set resources group address-group ServiceNetwork address '10.2.176.0/20'
set resources group address-group ServiceNetwork address '10.3.64.0/20'
set resources group address-group ServiceNetwork address '10.0.64.0/19'
set resources group address-group ServiceNetwork address '10.0.80.11'
set resources group address-group ServiceNetwork address '10.0.80.12'
set resources group address-group ServiceNetwork address '10.200.80.0/20'
set resources group address-group ServiceNetwork address '10.3.160.0/20'
set resources group address-group ServiceNetwork address '10.201.0.0/20'
set resources group address-group ServiceNetwork address '10.3.80.0/20'
set security firewall name To-Private-Servers rule 1 source address 'ServiceNetwork'
set security firewall name To-Private-Service-Network rule 1 destination address 'ServiceNetwork'

Sitzungs- und Paketprotokollierung

Die VRA unterstützt zwei Typen von Protokollierung: Sitzung und pro Paket.

Sitzungsprotokollierung

Mit dem Befehl security firewall session-log können Sie die Protokollierung von Firewallsitzungen konfigurieren.

Bei UDP, ICMP und allen Nicht-TCP-Datenflüssen durchläuft Ihre Sitzung während der Lebensdauer des Datenflusses vier Statusübergänge. Sie können konfigurieren, dass die VRA für jeden Übergang eine Nachricht protokolliert. TCP verfügt über zahlreiche Statusübergänge, für die jeweils die Protokollierung konfiguriert werden kann. Im folgenden Beispiel wird die Konfiguration von session-log für Ihre Firewall detailliert beschrieben:

set security firewall session-log icmp established
set security firewall session-log tcp established
set security firewall session-log udp established

Protokollierung pro Paket

Stellen Sie für die Paketprotokollierung sicher, dass Sie das Schlüsselwort log in die Firewall oder NAT-Regel einschließen. Dadurch wird jedes Netzpaket protokolliert, das der Regel entspricht.

Die Paketprotokollierung findet auf den Paketweiterleitungspfaden statt und erzeugt umfangreiche Ausgabedaten. Die paketweise Protokollierung kann den Durchsatz des VRA erheblich verringern, Leistungsprobleme verursachen und den für die Protokolldateien benötigten Speicherplatz drastisch erhöhen. Es wird empfohlen, die Paketprotokollierung nur für Debugzwecke zu verwenden. Für alle betrieblichen Zwecke sollte stattdessen die zustandsabhängige Sitzungsprotokollierung verwendet werden.

Fehlerbehebung mithilfe von Firewallprotokollen

Für Debugzwecke können Sie das Standardprotokoll und die Paketprotokollierung konfigurieren. Pro Paketprotokollierung kann zu jeder einzelnen Regel hinzugefügt werden, um in den Protokollen anzuzeigen, wann Pakete gelöscht oder akzeptiert werden (je nach Aktionsset für die Regel). Das Standardprotokoll zeichnet eine "implizite" Löschung auf, wenn sie auftritt. Für die folgende zonenrichtlinienbasierte Firewallkonfiguration protokolliert die Einstellung "default-log" jedes Mal, wenn der Datenverkehr nicht mit Regel 1 übereinstimmt. Dies ist die einzige konfigurierte Regel.

set security firewall name To-Private-Servers rule 1 action drop
set security firewall name To-Private-Servers rule 1 source address ServiceNetwork
set security firewall name To-Private-Servers rule 1 log
set security firewall name To-Private-Servers default-log

Zum Anzeigen des Protokolls gibt es zwei Befehle und die folgende Ausgabe zeigt einen protokollierten Block eines bestimmten Datenverkehrs:

journalctl -u vyatta-dataplane | grep <IP Address>
show log firewall name To-Private-Servers | grep <IP Address>

vyatta@gateway02# journalctl -f -u vyatta-dataplane | grep 10.3.84.106
Feb 18 05:47:09 gateway02 vyatta-dataplane.service dataplane[4313]: fw rule To-Private-Servers:10000 block icmp(1) src=//10.3.84.106 dst=dp0bond0.1750//10.126.19.174 len=84 ttl=55 type=8 code=0
Feb 18 05:47:10 gateway02 vyatta-dataplane.service dataplane[4313]: fw rule To-Private-Servers:10000 block icmp(1) src=//10.3.84.106 dst=dp0bond0.1750//10.126.19.174 len=84 ttl=55 type=8 code=0
^C
[edit]