Stateful Firewalls
Junos Network Secure – Übersicht
Router verwenden Firewalls, um den Datenverkehrsfluss zu verfolgen und zu steuern. Adaptive Services und MultiServices PICs verwenden eine Art Firewall namens . Im Gegensatz zu einer Firewall, die Pakete isoliert untersucht, bietet eine Stateful-Firewall eine zusätzliche Sicherheitsebene, indem sie Zustandsinformationen aus früheren Kommunikations- und anderen Anwendungen verwendet, um dynamische Steuerungsentscheidungen für neue Kommunikationsversuche zu treffen.
Auf Routern der ACX-Serie wird die Stateful-Firewall-Konfiguration nur auf den ACX500-Innenroutern unterstützt.
Zustandsbehaftete Firewalls gruppieren relevant in . Ein Flow wird durch die folgenden fünf Eigenschaften identifiziert:
Quelladresse
Quell-Port
Zieladresse
Zielhafen
Protokoll
Eine typische TCP- (Transmission Control Protocol) oder UDP-Konversation (User Datagram Protocol) besteht aus zwei Abläufen: dem Initiierungsfluss und dem Antwortfluss. Einige Konversationen, z. B. eine FTP-Konversation, können jedoch aus zwei Kontrollflüssen und vielen Datenflüssen bestehen.
Firewall-Regeln regeln, ob die Konversation aufgebaut werden darf. Wenn eine Konversation zulässig ist, sind alle Flows innerhalb der Konversation zulässig, einschließlich Flows, die während des Lebenszyklus der Konversation erstellt werden.
Sie konfigurieren zustandsbehaftete Firewalls mithilfe eines leistungsstarken regelgesteuerten Pfads zur Behandlung von Konversationen. A besteht aus Richtung, Quelladresse, Quellport, Zieladresse, Zielport, IP-Protokollwert und Anwendungsprotokoll oder Dienst. Zusätzlich zu den spezifischen Werten, die Sie konfigurieren, können Sie den Wert any Regelobjekten, Adressen oder Ports zuweisen, sodass sie mit jedem Eingabewert übereinstimmen können. Schließlich können Sie optional die Regelobjekte negieren, wodurch das Ergebnis der typspezifischen Übereinstimmung negiert wird.
Firewall-Regeln sind richtungsweisend. Für jede neue Konversation prüft die Router-Software den Initiierungsablauf, der mit der in der Regel festgelegten Richtung übereinstimmt.
Firewall-Regeln werden geordnet. Die Software prüft die Regeln in der Reihenfolge, in der Sie sie in die Konfiguration aufnehmen. Wenn die Firewall zum ersten Mal eine Übereinstimmung erkennt, implementiert der Router die in dieser Regel angegebene Aktion. Noch ungeprüfte Regeln werden ignoriert.
Ab Junos OS Version 14.2 unterstützen MS-MPC- und MS-MIC-Schnittstellenkarten IPv6-Datenverkehr für die Junos Network Secure Stateful Firewall.
Weitere Informationen finden Sie unter Konfigurieren von Stateful Firewall-Regeln.
Stateful Firewall-Unterstützung für Anwendungsprotokolle
Durch die Überprüfung der Anwendungsprotokolldaten kann die AS- oder MultiServices PIC-Firewall Sicherheitsrichtlinien intelligent durchsetzen und nur den minimal erforderlichen Paketverkehr durch die Firewall fließen lassen.
Die Firewall-Regeln werden in Bezug auf eine Schnittstelle konfiguriert. Standardmäßig lässt die Stateful-Firewall zu, dass alle Sitzungen, die von den Hosts hinter der Schnittstelle initiiert werden, den Router passieren.
Stateful-Firewall-ALGs werden auf ACX500-Routern nicht unterstützt.
Stateful Firewall – Anomalieprüfung
Die Stateful-Firewall erkennt die folgenden Ereignisse als Anomalien und sendet sie zur Verarbeitung an die IDS-Software:
IP-Anomalien:
Die IP-Version ist nicht korrekt.
Das Feld für die IP-Header-Länge ist zu klein.
Die IP-Header-Länge wird größer als das gesamte Paket festgelegt.
Schlechte Header-Prüfsumme.
Das Feld für die IP-Gesamtlänge ist kürzer als die Header-Länge.
Das Paket hat falsche IP-Optionen.
Internet Control Message Protocol (ICMP)-Paketlängenfehler.
Die Gültigkeitsdauer (TTL) ist gleich 0.
IP-Adressanomalien:
Die IP-Paketquelle ist ein Broadcast oder Multicast.
Landangriff (Quell-IP gleich Ziel-IP).
Anomalien bei der IP-Fragmentierung:
Überlappung von IP-Fragmenten.
IP-Fragment übersehen.
Fehler bei der IP-Fragmentlänge.
Die IP-Paketlänge beträgt mehr als 64 Kilobyte (KB).
Angriff auf winzige Fragmente.
TCP-Anomalien:
TCP-Port 0.
TCP-Sequenznummer 0 und Flags 0.
TCP-Sequenznummer 0 und FIN/PSH/RST-Flags gesetzt.
TCP-Flags mit falscher Kombination (TCP FIN/RST oder SYN/(URG|FIN|RST).
Schlechte TCP-Prüfsumme.
UDP-Anomalien:
UDP-Quell- oder Zielport 0.
Fehler bei der Überprüfung der UDP-Header-Länge.
Schlechte UDP-Prüfsumme.
Anomalien, die durch Stateful-TCP- oder UDP-Prüfungen gefunden werden:
SYN gefolgt von SYN-ACK-Paketen ohne ACK vom Initiator.
SYN gefolgt von RST-Paketen.
SYN ohne SYN-ACK.
Nicht-SYN-First-Flow-Paket.
ICMP Unreachable Errors für SYN-Pakete.
ICMP Unreachable Errors für UDP-Pakete.
Pakete, die gemäß Stateful-Firewall-Regeln verworfen wurden.
ACX500-Router unterstützen keine IP-Fragmentierung-Anomalien.
Wenn Sie die Stateful-Anomalieerkennung zusammen mit der Stateless-Erkennung einsetzen, kann IDS eine Frühwarnung für eine Vielzahl von Angriffen bieten, z. B.:
TCP- oder UDP-Netzwerksonden und Port-Scans
SYN-Flood-Angriffe
Auf IP-Fragmentierung basierende Angriffe wie Teardrop, Bonk und Boink
Konfigurieren von Stateful Firewall-Regeln
Um eine Stateful-Firewall-Regel zu konfigurieren, fügen Sie die rule rule-name Anweisung auf Hierarchieebene [edit services stateful-firewall] ein:
[edit services stateful-firewall] rule rule-name { match-direction (input | output | input-output); term term-name { from { application-sets set-name; applications [ application-names ]; destination-address (address | any-ipv4 | any-ipv6 | any-unicast) <except>; destination-address-range low minimum-value high maximum-value <except>; destination-prefix-list list-name <except>; source-address (address | any-ipv4 | any-ipv6 | any-unicast) <except>; source-address-range low minimum-value high maximum-value <except>; source-prefix-list list-name <except>; } then { (accept <skip-ids>| discard | reject); allow-ip-options [ values ]; syslog; } } }
ACX500-Router unterstützen keine Anwendungen und Anwendungssätze auf der Hierarchieebene [edit services stateful-firewall rule rule-name term term-name from].
Um Syslog auf ACX500-Routern zu aktivieren, schließen Sie die stateful-firewall-logs CLI-Anweisung auf der Hierarchieebene [edit services service-set service-set-name syslog host local class] ein.
edit services stateful-firewall Hierarchie wird von der SRX-Serie nicht unterstützt.
Jede Stateful-Firewallregel besteht aus einer Reihe von Begriffen, ähnlich einem Filter, der auf Hierarchieebene [edit firewall] konfiguriert ist. Ein Begriff besteht aus dem Folgenden:
fromstatement: Gibt die Übereinstimmungsbedingungen und Anwendungen an, die ein- und ausgeschlossen werden. DiefromAnweisung ist in Stateful-Firewall-Regeln optional.thenstatement: Gibt die Aktionen und Aktionsmodifikatoren an, die von der Router-Software ausgeführt werden sollen. DiethenAnweisung ist in Stateful-Firewall-Regeln obligatorisch.
Router der ACX500-Serie unterstützen Folgendes bei der Konfiguration zustandsbehafteter Firewall-Regeln nicht:
match-direction(output | input-output)post-service-filterauf der Ebene der Eingabehierarchie des Schnittstellenservice.IPv6-Quelladresse und Zieladresse.
application-sets,application,allow-ip-optionsauf deredit services stateful-firewall[] Hierarchieebene.Gateways auf Anwendungsebene (ALGs).
Verkettung von Diensten innerhalb der Multiservices Modular Interfaces Card (MS-MIC) und mit Inline-Services (-si).
Class of Service.
Die folgenden
show services stateful-firewallCLI-Befehle werden nicht unterstützt:show services stateful-firewall conversations– Unterhaltungen anzeigenshow services stateful-firewall flow-analysis– Flow-Tabelleneinträge anzeigenshow services stateful-firewall redundancy-statistics– Redundanzstatistik anzeigenshow services stateful-firewall sip-call– SIP-Anrufinformationen anzeigenshow services stateful-firewall sip-register– SIP-Registerinformationen anzeigenshow services stateful-firewall subscriber-analysis– Tabelleneinträge für Anwender anzeigen
In den folgenden Abschnitten wird erläutert, wie die Komponenten von Stateful-Firewall-Regeln konfiguriert werden:
- Konfigurieren der Übereinstimmungsrichtung für Stateful Firewall-Regeln
- Konfigurieren von Übereinstimmungsbedingungen in Stateful Firewall-Regeln
- Konfigurieren von Aktionen in Stateful Firewall-Regeln
Konfigurieren der Übereinstimmungsrichtung für Stateful Firewall-Regeln
Jede Regel muss eine match-direction Anweisung enthalten, die die Richtung angibt, in der die Regelübereinstimmung angewendet wird. Um zu konfigurieren, wo die Übereinstimmung angewendet wird, fügen Sie die match-direction Anweisung auf Hierarchieebene [edit services stateful-firewall rule rule-name] ein:
[edit services stateful-firewall rule rule-name] match-direction (input | output | input-output);
Router der ACX500-Serie unterstützen match-direction (output | input-output)keine .
Wenn Sie match-direction input-outputkonfigurieren, können Sitzungen, die aus beiden Richtungen initiiert werden, dieser Regel entsprechen.
Die Übereinstimmungsrichtung wird in Bezug auf den Datenverkehrsfluss durch das AS- oder Multiservices-PIC verwendet. Wenn ein Paket an das PIC gesendet wird, werden Richtungsinformationen mitgeführt.
Bei einem Schnittstellen-Service-Set wird die Paketrichtung dadurch bestimmt, ob ein Paket in die Schnittstelle ein- oder ausgeht, auf der der Service-Satz angewendet wird.
Bei einem Next-Hop-Service-Set wird die Paketrichtung durch die Schnittstelle bestimmt, über die das Paket an das AS- oder Multiservices-PIC weitergeleitet wird. Wenn die interne Schnittstelle zum Weiterleiten des Pakets verwendet wird, wird die Paketrichtung eingegeben. Wenn die externe Schnittstelle verwendet wird, um das Paket an das PIC zu leiten, wird die Paketrichtung ausgegeben. Weitere Informationen zu internen und externen Schnittstellen finden Sie unter Konfigurieren von Service-Sets, die auf Service-Schnittstellen angewendet werden sollen.
Auf dem PIC wird eine Flusssuche durchgeführt. Wenn kein Fluss gefunden wird, wird die Regelverarbeitung durchgeführt. Regeln in diesem Service-Set werden nacheinander betrachtet, bis eine Übereinstimmung gefunden wird. Während der Regelverarbeitung wird die Paketrichtung mit den Regelrichtungen verglichen. Es werden nur Regeln mit Richtungsinformationen berücksichtigt, die mit der Paketrichtung übereinstimmen. Die meisten Pakete führen zur Erstellung bidirektionaler Datenströme.
Konfigurieren von Übereinstimmungsbedingungen in Stateful Firewall-Regeln
Um Übereinstimmungsbedingungen für zustandsbehaftete Firewalls zu konfigurieren, schließen Sie die from folgende Anweisung auf Hierarchieebene [edit services stateful-firewall rule rule-name term term-name] ein:
[edit services stateful-firewall rule rule-name term term-name] from { application-sets set-name; applications [ application-names ]; destination-address (address | any-ipv4 | any-ipv6 | any-unicast) <except>; destination-address-range low minimum-value high maximum-value <except>; destination-prefix-list list-name <except>; source-address (address | any-ipv4 | any-ipv6 | any-unicast) <except>; source-address-range low minimum-value high maximum-value <except>; source-prefix-list list-name <except>; }
ACX500-Router unterstützen keine Anwendungen und Anwendungssätze auf der Hierarchieebene [edit services stateful-firewall rule rule-name term term-name from].
Die Quell- und Zieladresse können entweder IPv4 oder IPv6 sein.
Sie können entweder die Quelladresse oder die Zieladresse als Übereinstimmungsbedingung verwenden, auf die gleiche Weise, wie Sie einen Firewallfilter konfigurieren würden. Weitere Informationen finden Sie im Benutzerhandbuch für Routing-Richtlinien, Firewall-Filter und Traffic Policers. Sie können die Platzhalterwerte any-unicastverwenden, die angeben, dass alle Unicast-Adressen übereinstimmen, , die angeben, any-ipv4dass alle IPv4-Adressen übereinstimmen, oder any-ipv6, die angeben, dass alle IPv6-Adressen übereinstimmen.
Alternativ können Sie eine Liste von Quell- oder Zielpräfixen angeben, indem Sie die prefix-list Anweisung auf Hierarchieebene [edit policy-options] konfigurieren und dann entweder die destination-prefix-list oder die source-prefix-list Anweisung in die Stateful-Firewallregel aufnehmen. Ein Beispiel finden Sie unter Beispiele: Konfigurieren von Stateful Firewall-Regeln.
Wenn Sie den from Begriff weglassen, akzeptiert die Stateful-Firewall den gesamten Datenverkehr und die Standardprotokollhandler werden wirksam:
Das User Datagram Protocol (UDP), das Transmission Control Protocol (TCP) und das Internet Control Message Protocol (ICMP) erzeugen einen bidirektionalen Datenfluss mit einem vorhergesagten Rückfluss.
IP erzeugt einen unidirektionalen Fluss.
Sie können auch Anwendungsprotokolldefinitionen einschließen, die Sie auf Hierarchieebene [edit applications] konfiguriert haben. Weitere Informationen finden Sie unter Anwendungseigenschaften konfigurieren.
Um eine oder mehrere spezifische Anwendungsprotokolldefinitionen anzuwenden, schließen Sie die
applicationsAnweisung auf der[edit services stateful-firewall rule rule-name term term-name from]Hierarchieebene ein.Um einen oder mehrere Sätze von Anwendungsprotokolldefinitionen anzuwenden, die Sie definiert haben, schließen Sie die
application-setsAnweisung auf Hierarchieebene[edit services stateful-firewall rule rule-name term term-name from]ein.Hinweis:Wenn Sie eine der Anweisungen einschließen, die Anwendungsprotokolle angibt, leitet der Router Port- und Protokollinformationen von der entsprechenden Konfiguration auf Hierarchieebene
[edit applications]ab. Sie können diese Eigenschaften nicht als Übereinstimmungsbedingungen angeben.
Konfigurieren von Aktionen in Stateful Firewall-Regeln
Um zustandsbehaftete Firewall-Aktionen zu konfigurieren, fügen Sie die then Anweisung auf Hierarchieebene [edit services stateful-firewall rule rule-name term term-name] ein:
[edit services stateful-firewall rule rule-name term term-name] then { (accept | discard | reject); allow-ip-options [ values ]; syslog; }
Sie müssen eine der folgenden Aktionen einschließen:
accept– Das Paket wird akzeptiert und an sein Ziel weitergeleitet.accept skip-ids– Das Paket wird akzeptiert und an sein Ziel weitergeleitet, aber die auf einem MS-MPC konfigurierte IDS-Regelverarbeitung wird übersprungen.discard– Das Paket wird nicht akzeptiert und nicht weiterverarbeitet.reject—Das Paket wird nicht akzeptiert und es wird eine Ablehnungsnachricht zurückgegeben. UDP sendet einen ICMP Unreachable Code und TCP sendet RST. Abgelehnte Pakete können protokolliert oder Stichproben entnommen werden.
Die ACX500-Indoor-Router unterstützen die Aktion accept skip-idsnicht .
Sie können die Firewall optional so konfigurieren, dass Informationen in der Systemprotokollierungsfunktion aufgezeichnet werden, indem Sie die syslog Anweisung auf Hierarchieebene [edit services stateful-firewall rule rule-name term term-name then] einschließen. Diese Anweisung überschreibt alle syslog Einstellungen, die in der Standardkonfiguration des Servicesatzes oder der Schnittstelle enthalten sind.
Konfigurieren der IP-Optionsbehandlung
Sie können die Firewall optional so konfigurieren, dass IP-Header-Informationen überprüft werden, indem Sie die allow-ip-options Anweisung auf Hierarchieebene [edit services stateful-firewall rule rule-name term term-name then] einschließen. Wenn Sie diese Anweisung konfigurieren, werden alle Pakete, die die in der from Anweisung angegebenen Kriterien erfüllen, zusätzlichen Übereinstimmungskriterien unterzogen. Ein Paket wird nur akzeptiert, wenn alle seine IP-Optionstypen als Werte in der allow-ip-options Anweisung konfiguriert sind. Wenn Sie nicht konfigurieren allow-ip-options, werden nur Pakete ohne IP-Header-Optionen akzeptiert.
ACX500-Indoor-Router unterstützen die Konfiguration der allow-ip-options Anweisung nicht.
Die zusätzliche Überprüfung der IP-Header-Option gilt nur für die accept Aktionen der Firewall und reject Stateful. Diese Konfiguration hat keine Auswirkungen auf die discard Aktion. Wenn die IP-Header-Überprüfung fehlschlägt, werden keine abgelehnten Frames gesendet. In diesem Fall hat die reject Aktion die gleiche Wirkung wie discard.
Wenn ein IP-Optionspaket von der Stateful-Firewall akzeptiert wird, werden Network Address Translation (NAT) und Intrusion Detection Service (IDS) auf die gleiche Weise angewendet wie auf Pakete ohne IP-Optionsheader. Die Konfiguration der IP-Option wird nur in den Stateful-Firewall-Regeln angezeigt. NAT gilt für Pakete mit oder ohne IP-Optionen.
Wenn ein Paket verworfen wird, weil es die Überprüfung der IP-Option nicht besteht, generiert dieses Ausnahmeereignis sowohl IDS-Ereignis- als auch Systemprotokollmeldungen. Der Ereignistyp hängt vom ersten abgelehnten IP-Optionsfeld ab.
Tabelle 1 listet die möglichen Werte für die allow-ip-options Anweisung auf. Sie können einen Bereich oder eine Reihe numerischer Werte oder eine oder mehrere der vordefinierten IP-Optionseinstellungen einschließen. Sie können entweder den Optionsnamen oder die numerische Entsprechung eingeben. Weitere Informationen finden Sie unter http://www.iana.org/assignments/ip-parameters.
Name der IP-Option |
Numerischer Wert |
Kommentar |
|---|---|---|
|
|
Jede IP-Option |
|
|
– |
|
|
– |
|
|
– |
|
|
– |
|
|
– |
|
|
– |
|
|
– |
Siehe auch
Konfigurieren von Regelsätzen für Stateful Firewall
Die rule-set Anweisung definiert eine Sammlung von Stateful-Firewall-Regeln, die bestimmen, welche Aktionen die Router-Software für Pakete im Datenstrom ausführt. Sie definieren jede Regel, indem Sie einen Regelnamen angeben und Begriffe konfigurieren. Anschließend legen Sie die Reihenfolge der Regeln fest, indem Sie die rule-set Anweisung auf der [edit services stateful-firewall] Hierarchieebene mit einer rule Anweisung für jede Regel aufnehmen:
[edit services stateful-firewall] rule-set rule-set-name { rule rule-name; }
Die Router-Software verarbeitet die Regeln in der Reihenfolge, in der Sie sie in der Konfiguration angeben. Wenn ein Begriff in einer Regel mit dem Paket übereinstimmt, führt der Router die entsprechende Aktion aus und die Regelverarbeitung wird beendet. Wenn kein Begriff in einer Regel mit dem Paket übereinstimmt, wird die Verarbeitung bis zur nächsten Regel im Regelsatz fortgesetzt. Wenn keine der Regeln mit dem Paket übereinstimmt, wird das Paket standardmäßig verworfen.
Beispiele: Konfigurieren von Stateful Firewall-Regeln
Das folgende Beispiel zeigt eine Stateful-Firewall-Konfiguration, die zwei Regeln enthält, eine für den Eingabeabgleich für einen angegebenen Anwendungssatz und die andere für den Ausgabeabgleich für eine angegebene Quelladresse:
[edit services]
stateful-firewall {
rule Rule1 {
match-direction input;
term 1 {
from {
application-sets Applications;
}
then {
accept;
}
}
term accept {
then {
accept;
}
}
}
rule Rule2 {
match-direction output;
term Local {
from {
source-address {
10.1.3.2/32;
}
}
then {
accept;
}
}
}
}
Das folgende Beispiel enthält eine einzelne Regel mit zwei Begriffen. Der erste Begriff lehnt den gesamten my-application-group Datenverkehr ab, der von der angegebenen Quelladresse stammt, und stellt einen detaillierten Systemprotokolldatensatz der abgelehnten Pakete bereit. Der zweite Begriff akzeptiert HTTP-Datenverkehr (Hypertext Transfer Protocol) von jedem an die angegebene Zieladresse.
[edit services stateful-firewall]
rule my-firewall-rule {
match-direction input-output;
term term1 {
from {
source-address 10.1.3.2/32;
application-sets my-application-group;
}
then {
reject;
syslog;
}
}
term term2 {
from {
destination-address 10.2.3.2/32;
applications http;
}
then {
accept;
}
}
}
Das folgende Beispiel zeigt die Verwendung von Quell- und Zielpräfixlisten. Dies erfordert zwei separate Konfigurationselemente.
Sie konfigurieren die Präfixliste auf Hierarchieebene [edit policy-options] :
[edit]
policy-options {
prefix-list p1 {
10.1.1.1/32;
10.2.2.0/24;
}
prefix-list p2 {
10.3.3.3/32;
10.4.4.0/24;
}
}
Sie verweisen auf die konfigurierte Präfixliste in der Stateful-Firewall-Regel:
[edit]
services {
stateful-firewall {
rule r1 {
match-direction input;
term t1 {
from {
source-prefix-list {
p1;
}
destination-prefix-list {
p2;
}
}
then {
accept;
}
}
}
}
}
Dies entspricht der folgenden Konfiguration:
[edit]
services {
stateful-firewall {
rule r1 {
match-direction input;
term t1 {
from {
source-address {
10.1.1.1/32;
10.2.2.0/24;
}
destination-address {
10.3.3.3/32;
10.4.4.0/24;
}
}
then {
accept;
}
}
}
}
}
Sie können den except Qualifizierer mit den Präfixlisten verwenden, wie im folgenden Beispiel gezeigt. In diesem Fall gilt der except Qualifizierer für alle Präfixe, die in der Präfixliste p2enthalten sind.
[edit]
services {
stateful-firewall {
rule r1 {
match-direction input;
term t1 {
from {
source-prefix-list {
p1;
}
destination-prefix-list {
p2 except;
}
}
then {
accept;
}
}
}
}
}
Weitere Beispiele, die die Konfiguration einer zustandsbehafteten Firewall mit anderen Services und mit VPN-Routing- und Weiterleitungstabellen (Virtual Private Network) kombinieren, finden Sie in den Konfigurationsbeispielen.
Sie können das Service-Set definieren und es entweder als Schnittstellenstil oder als Next-Hop-Stil zuweisen.
Siehe auch
Beispiel: BOOTP- und Broadcast-Adressen
Das folgende Beispiel unterstützt Bootstrap Protocol (BOOTP) und Broadcast-Adressen:
[edit applications]
application bootp {
application-protocol bootp;
protocol udp;
destination-port 67;
}
[edit services]
stateful-firewall bootp-support {
rule bootp-allow {
direction input;
term bootp-allow {
from {
destination-address {
any-unicast;
255.255.255.255;
}
application bootp;
}
then {
accept;
}
}
}
}
Beispiel: Konfigurieren von Layer-3-Services und des Services-SDK auf zwei PICs
Sie können das Layer-3-Servicepaket und das Services SDK auf zwei PIC konfigurieren. In diesem Beispiel müssen Sie einen FTP- oder HTTP-Client und einen Server konfigurieren. In dieser Konfiguration ist die Client-Seite der Router-Schnittstelle ge-1/2/2.1 und die Serverseite der Router-Schnittstelle ge-1/1/0.48. Diese Konfiguration ermöglicht Network Address Translation (NAT) mit Stateful Firewall (SFW) auf dem uKernel PIC und Anwendungsidentifikation (APPID), anwendungsbewusste Zugriffsliste (AACL) und Intrusion Detection and Prevention (IDP) auf dem Services SDK PIC für FTP- oder HTTP-Datenverkehr.
Das Services SDK unterstützt NAT noch nicht. Wenn NAT erforderlich ist, können Sie das Layer-3-Servicepaket so konfigurieren, dass NAT zusammen mit dem Services SDK wie APPID, AACL oder IDP bereitgestellt wird.
Die IDP-Funktionalität ist für die MX-Serie für Junos OS Version 17.1R1 und höher veraltet.
So stellen Sie das Layer-3-Servicepaket und das Services SDK auf zwei PIC bereit:
Beispiel: Virtuelles Routing und Weiterleitung (VRF) und Servicekonfiguration
Im folgenden Beispiel werden virtuelles Routing und Weiterleiten (VRF) und die Dienstkonfiguration kombiniert:
[edit policy-options]
policy-statement test-policy {
term t1 {
then reject;
}
}
[edit routing-instances]
test {
interface ge-0/2/0.0;
interface sp-1/3/0.20;
instance-type vrf;
route-distinguisher 10.58.255.1:37;
vrf-import test-policy;
vrf-export test-policy;
routing-options {
static {
route 0.0.0.0/0 next-table inet.0;
}
}
}
[edit interfaces]
ge-0/2/0 {
unit 0 {
family inet {
service {
input service-set nat-me;
output service-set nat-me;
}
}
}
}
sp-1/3/0 {
unit 0 {
family inet;
}
unit 20 {
family inet;
service-domain inside;
}
unit 21 {
family inet;
service-domain outside;
}
[edit services]
stateful-firewall {
rule allow-any-input {
match-direction input;
term t1 {
then accept;
}
}
}
nat {
pool hide-pool {
address 10.58.16.100;
port automatic;
}
rule hide-all-input {
match-direction input;
term t1 {
then {
translated {
source-pool hide-pool;
translation-type source napt-44;
}
}
}
}
}
service-set nat-me {
stateful-firewall-rules allow-any-input;
nat-rules hide-all-input;
interface-service {
service-interface sp-1/3/0.20;
}
}
}
Tabellarischer Änderungsverlauf
Die Unterstützung der Funktion hängt von der Plattform und der Version ab, die Sie benutzen. Verwenden Sie den Feature-Explorer , um festzustellen, ob eine Funktion auf Ihrer Plattform unterstützt wird.
accept skip-ids– Das Paket wird akzeptiert und an sein Ziel weitergeleitet, aber die auf einem MS-MPC konfigurierte IDS-Regelverarbeitung wird übersprungen.