Beispiel: Kontrollieren Sie den Verwaltungszugriff auf Juniper Netzwerkgeräten
Unser Content-Testing-Team hat dieses Beispiel validiert und aktualisiert.
In diesem Beispiel wird gezeigt, wie der Verwaltungszugriff auf Juniper Networking-Geräte basierend auf einem bestimmten Satz zulässiger IP-Adressen eingeschränkt wird. Diese Art von Funktionalität wird häufig als Zugriffssteuerungsliste (Access Control List, ACL) bezeichnet und als zustandsloser Firewall-Filter im Junos-Betriebssystem implementiert.
Anforderungen
Ein Netzwerkgerät von Juniper, das mit einem Verwaltungsnetzwerk verbunden ist. Um die Konfiguration zu validieren, sollte mindestens ein weiteres Gerät mit Zugriff auf das Verwaltungsnetzwerk vorhanden sein, das SSH- oder Telnet-Verbindungen mit dem zu testenden Gerät (DUT) initiieren kann. Für die Konfiguration dieses Beispiels ist keine spezielle Konfiguration erforderlich, die über die grundlegende Geräteinitialisierung hinausgeht (Verwaltungsschnittstelle und zugehörige statische Route, Systemdienste, Benutzeranmeldekonten usw.).
Überblick
Sie können einen Firewallfilter konfigurieren, um die IP-Adressen einzuschränken, die ein Gerät verwalten können. Dieser Firewallfilter muss einen Begriff enthalten, um jeglichen Datenverkehr mit Ausnahme der IP-Adressen abzulehnen, die für die Verwaltung des Geräts zulässig sind. Sie müssen den Firewallfilter auf die Loopback-Schnittstelle (lo0) anwenden, um sicherzustellen, dass nur Verwaltungsdatenverkehr, d. h. an das Gerät selbst gesendeter Datenverkehr, gefiltert wird.
Beispieltopologie
Abbildung 1 zeigt die Topologie für dieses Beispiel. Das R1-Gerät dient als Standardgateway für das Verwaltungsnetzwerk, dem das Subnetz 172.16.0.0/24 zugewiesen ist. Sie wenden den Filter an, der den Verwaltungszugriff auf das R2-Gerät einschränkt, und machen es in diesem Beispiel zum Prüfling. Die Remote-Workstation ist berechtigt, den Prüfling zu verwalten, und ihr wurde die Adresse 10.0.0.1/32 zugewiesen.
In diesem Beispiel gehen Sie wie folgt vor:
Konfigurieren Sie eine Präfixliste mit dem Namen manager-ip. Diese Liste definiert die IP-Adressen, die das Gerät verwalten dürfen. In diesem Beispiel enthält die Liste das Verwaltungssubnetz selbst (172.16.0.0/24) und die IP-Adresse eines autorisierten Remotebenutzers (10.0.0.1/32).
Konfigurieren Sie einen Firewallfilter limit-mgmt-access , der alle Quelladressen mit Ausnahme der in der manager-ip Präfixliste definierten Adressen ablehnt. Dadurch wird sichergestellt, dass nur IP-Adressen, die in der Präfixliste aufgeführt sind, das Gerät verwalten können.
Wenden Sie den limit-mgmt-access Filter auf die Loopback-Schnittstelle an. Jedes Mal, wenn ein an das lokale Gerät adressiertes Paket auf einer beliebigen Schnittstelle eintrifft, wendet die Loopback-Schnittstelle den Filter limit-mgmt-access an, um den Verwaltungszugriff auf zulässige Adressen zu beschränken.
Konfigurieren einer IP-Adressliste, um den Verwaltungszugriff auf ein Gerät einzuschränken
Verfahren
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, bearbeiten Sie die folgenden Befehle nach Bedarf, und fügen Sie sie in die CLI des R2-Geräts auf Hierarchieebene [edit] ein. Der Vollständigkeit halber enthält die Konfiguration Befehle zur Konfiguration von SSH (für Nichtbenutzer) und der Telnet-Systemdienste. Außerdem wird die Konfiguration der Verwaltungsschnittstelle und der zugehörigen statischen Route bereitgestellt. Diese Befehle sind nicht erforderlich, wenn auf Ihrem Gerät diese Funktion bereits konfiguriert ist.
Telnet unterstützt keine Root-Anmeldung auf Geräten von Juniper Networks. Die SSH-Anmeldung für den Root-Benutzer ist in diesem Beispiel nicht konfiguriert. Auf Ihrem Gerät sollte ein Nicht-Root-Benutzer konfiguriert sein, der eine Remote-Anmeldung zulässt. Alternativ können Sie das Argument zur Anweisung hinzufügen, um die root-login allowsystem services ssh Anmeldung von Root-Benutzern über SSH zuzulassen.
Stellen Sie sicher, dass Sie einen from-Konfigurationsmodus commit ausgeben, um die Änderungen zu aktivieren.
Wenn Sie einen Filter anwenden, der den Zugriff auf das Gerät einschränkt, sollten Sie die Verwendung von commit confirmed. Mit dieser Option wird die Konfiguration automatisch zurückgesetzt, wenn Sie in der angegebenen Zeit keinen weiteren Commit ausführen können.
set system services ssh set system services telnet set interfaces fxp0 unit 0 family inet address 172.16.0.253/24 set interfaces lo0 unit 0 family inet address 192.168.255.2/32 set routing-options static route 0.0.0.0/0 next-hop 172.16.0.254 no-readvertise set policy-options prefix-list manager-ip 172.16.0.0/24 set policy-options prefix-list manager-ip 10.0.0.1/32 set firewall filter limit-mgmt-access term block_non_manager from source-address 0.0.0.0/0 set firewall filter limit-mgmt-access term block_non_manager from source-prefix-list manager-ip except set firewall filter limit-mgmt-access term block_non_manager from protocol tcp set firewall filter limit-mgmt-access term block_non_manager from destination-port ssh set firewall filter limit-mgmt-access term block_non_manager from destination-port telnet set firewall filter limit-mgmt-access term block_non_manager then log set firewall filter limit-mgmt-access term block_non_manager then discard set firewall filter limit-mgmt-access term accept_everything_else then accept set interfaces lo0 unit 0 family inet filter input limit-mgmt-access
Schritt-für-Schritt-Anleitung
Für die folgenden Schritte müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Anweisungen hierzu finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im CLI-Benutzerhandbuch.
Konfigurieren Sie die Verwaltungs- und Loopback-Schnittstellen, und stellen Sie sicher, dass die Telnet- und SSH-Systemdienste aktiviert sind.
[edit] user@R2# set interfaces fxp0 unit 0 family inet address 172.16.0.253/24 user@R2# set interfaces lo0 unit 0 family inet address 192.168.255.2/32 user@R2# set routing-options static route 0.0.0.0/0 next-hop 172.16.0.254 no-readvertise user@R2# set system services ssh user@R2# set system services telnet
Definieren Sie den Satz der zulässigen Hostadressen in der Präfixliste. Diese Liste enthält Präfixe für das Verwaltungssubnetz und für eine einzelne autorisierte Remoteverwaltungsstation.
[edit policy-options] user@R2# set prefix-list manager-ip 172.16.0.0/24 user@R2# set prefix-list manager-ip 10.0.0.1/32
Auf die Präfixliste wird im Firewallfilter verwiesen. Die Verwendung einer Präfixliste erleichtert die Aktualisierung der Adressen, die für den Zugriff auf das Gerät zugelassen sind. Dies liegt daran, dass nur die Präfixliste aktualisiert werden muss. Es sind keine Änderungen am Firewallfilter selbst erforderlich, wenn zulässige Präfixe hinzugefügt oder entfernt werden.
Konfigurieren Sie einen Firewallfilter so, dass Telnet- und SSH-Datenverkehr von allen IP-Adressen mit Ausnahme der in der Präfixliste definierten IP-Adressen verweigert wird.
[edit firewall filter limit-mgmt-access] user@R2# set term block_non_manager from source-address 0.0.0.0/0 user@R2# set term block_non_manager from source-prefix-list manager-ip except user@R2# set term block_non_manager from protocol tcp user@R2# set term block_non_manager from destination-port ssh user@R2# set term block_non_manager from destination-port telnet user@R2# set term block_non_manager then discard
Beachten Sie die Verwendung des
exceptAktionsmodifikators. Der erste Begriff stimmt auf allen möglichen Quelladressen überein. Der nächste Ausdruck kehrt die Übereinstimmung für die Quelladressen in der angegebenen Präfixliste um. Dies hat zur Folge, dass Verwaltungsdatenverkehr, der für das angegebene Protokoll und die angegebenen Ports bestimmt ist, nur akzeptiert wird, wenn der Datenverkehr von einer Adresse in der Liste stammt. Datenverkehr von allen anderen Quellpräfixen zur gleichen Kombination aus Protokoll und Ports wird verworfen. In diesem Beispiel wird eine Protokollierungsaktion hinzugefügt, um das Debuggen und Überprüfen von Filtern zu unterstützen.Konfigurieren Sie einen Standardbegriff, um den gesamten anderen Datenverkehr zu akzeptieren. Dadurch wird sichergestellt, dass andere Dienste und Protokolle, z. B. Pings, BGP oder OSPF, nicht vom Filter betroffen sind.
Tipp:Der Beispielfilter ist von vornherein freizügig. Er kann eine Sicherheitsbedrohung darstellen, da er explizit den gesamten Datenverkehr akzeptiert, der nicht von vorherigen Filterbegriffen abgelehnt oder verworfen wurde. Sie können einen stärkeren Sicherheitsfilter konfigurieren, indem Sie explizit alle Protokolle und Dienste auflisten, die akzeptiert werden sollen, und den Filter implizit oder explizit mit einem deny all-Begriff beenden, um den gesamten anderen Datenverkehr zu filtern. Der Nachteil eines restriktiven Filters besteht darin, dass er jedes Mal bearbeitet werden muss, wenn ein unterstützter Dienst hinzugefügt oder entfernt wird.
[edit firewall filter imit-mgmt-access] user@R2# set term accept_everything_else then accept
Wenden Sie den zustandslosen Firewallfilter als Eingabefilter auf die Loopback-Schnittstelle an. Der vom lokalen Gerät gesendete Datenverkehr wird in diesem Beispiel nicht gefiltert.
[edit interfaces lo0 unit 0 ] user@R2# set family inet filter input limit-mgmt-access
Ergebnisse
Bestätigen Sie Ihre Arbeit, indem Sie die folgenden show configuration Befehle aus dem Konfigurationsmodus eingeben. Wenn die Ausgabe nicht die gewünschte Konfiguration anzeigt, wiederholen Sie die Konfigurationsanweisungen in diesem Beispiel, um sie zu korrigieren.
user@R2# show policy-options
prefix-list manager-ip {
172.16.0.0/24;
10.0.0.1/32;
}
user@R2# show firewall
filter limit-mgmt-access {
term block_non_manager {
from {
source-address {
0.0.0.0/0;
}
source-prefix-list {
manager-ip except;
}
protocol tcp;
destination-port [ ssh telnet ];
}
then {
log;
discard;
}
}
term accept_everything_else {
then accept;
}
}
user@R2# show interfaces
fxp0 {
unit 0 {
family inet {
address 172.16.0.253/24;
}
}
}
lo0 {
unit 0 {
family inet {
filter {
input limit-mgmt-access;
}
address 192.168.255.2/32;
}
}
}
user@R2# show routing-options
static {
route 0.0.0.0/0 {
next-hop 172.16.0.254;
no-readvertise;
}
}
user@R2# show system services ssh; telnet;
Wenn Sie mit Ihrer Arbeit zufrieden sind, rufen Sie den Konfigurationsmodus auf commit .
Wenn Sie einen Filter anwenden, der den Zugriff auf das Gerät einschränkt, sollten Sie die Verwendung von commit confirmed. Mit dieser Option wird die Konfiguration automatisch zurückgesetzt, wenn Sie in der angegebenen Zeit keinen weiteren Commit ausführen können.
Überprüfen des zustandslosen Firewallfilters
Vergewissern Sie sich, dass der Firewallfilter zum Einschränken des Verwaltungszugriffs ordnungsgemäß funktioniert.
Akzeptierte Pakete überprüfen
Zweck
Stellen Sie sicher, dass der Firewallfilter SSH und Telnet korrekt zulässt, wenn der Datenverkehr aus dem Subnetz 172.16.0.0/24 oder aus dem Hostpräfix 10.0.0.1 stammt, das der Remoteverwaltungsstation zugeordnet ist.
Action!
Löschen Sie das Firewall-Protokoll auf Ihrem Router oder Switch.
user@R2> clear firewall log
Verwenden Sie von einem Host, der mit dem Subnetz 172.16.0.0/24 verbunden ist, z. B. dem Gerät R1, den
ssh 172.16.0.253Befehl, um eine Verbindung zum Prüfling herzustellen. Standardmäßig bezieht das R1-Gerät seinen Datenverkehr von der Ausgangsschnittstelle, die zum Erreichen des Ziels verwendet wird. Daher wird der Testdatenverkehr von der Adresse 172.16.0.254 von R1 bezogen. Dieser Datenverkehr stimmt nicht mit dem block_non_manager Filterbegriff überein, da derexceptAktionsmodifizierer für Adressen verwendet wird, die mit der Präfixliste übereinstimmen, auf die verwiesen wird. Dieser Datenverkehr stimmt mit dem Filterbegriff überein, der accept_everything_else dazu führt, dass er akzeptiert wirdHINWEIS:Sie werden aufgefordert, den SSH-Hostschlüssel zu speichern, wenn dies die erste SSH-Anmeldung zwischen user diesen Geräten ist.
user@R1>ssh user@172.16.0.253 Password: Last login: Tue Sep 8 09:46:58 2020 from 10.107.199.39 --- JUNOS 20.2R1.10 Kernel 64-bit XEN JNPR-11.0-20200608.0016468_buil user@R2>
Melden Sie sich am R2-Gerät von der CLI ab, um die SSH-Sitzung zu schließen.
user@R2> exit logout Connection to 172.16.0.253 closed. user@R1>
HINWEIS:Wiederholen Sie diesen Schritt mit dem
telnetBefehl. Die Telnet-Verbindung sollte erfolgreich sein.Verwenden Sie den
show firewall logBefehl auf dem R2-Gerät, um zu überprüfen, ob der Firewallprotokollpuffer auf dem R2-Gerät keine Einträge mit einer Quelladresse im Subnetz 172.16.0.0/24 enthält. Dies bedeutet, dass die Paket-Header-Informationen für diesen Datenverkehr nicht im Firewallfilterprotokoll protokolliert werden. In diesem Beispiel wird nur Datenverkehr protokolliert, der mit dem block_non_manager Begriff übereinstimmt.user@R2> show firewall log user@R2>
Bedeutung
Die Ausgabe bestätigt, dass SSH- (und Telnet-) Verbindungen akzeptiert werden, wenn sie aus dem Verwaltungsnetzwerk stammen. Es zeigt auch, dass Pakete, die nicht mit dem block_non_manager Begriff übereinstimmen, nicht protokolliert werden. Die gleichen Ergebnisse werden erwartet, wenn der SSH- oder Telnet-Datenverkehr von der Remoteverwaltungsstation generiert wird, der die Adresse 10.0.0.1 zugewiesen ist.
Überprüfen von protokollierten und abgelehnten Paketen
Zweck
Stellen Sie sicher, dass der Firewallfilter SSH- und Telnet-Datenverkehr, der nicht von einem der Präfixe in der manager-ip Präfixliste stammt, korrekt verwirft.
Action!
Generieren Sie SSH-Datenverkehr, der von einer Adresse stammt, die nicht in der manager-ip Präfixliste angegeben ist. Sie können die Sitzung von der Loopback-Adresse des R1-Geräts beziehen, um eine nicht autorisierte IP-Adresse zu simulieren. Alternativ können Sie die Verbindung von einem beliebigen Remotegerät aus initiieren, das nicht mit dem Verwaltungssubnetz verbunden ist und dem nicht die IP-Adresse 10.0.0.1 zugewiesen wurde. Die Pakete für diese SSH-Sitzung sollten verworfen werden, und die Paket-Header-Informationen sollten im Protokollpuffer des Firewallfilters protokolliert werden.
HINWEIS:Sie sollten keine Fehlermeldung oder -antwort erwarten. Beim Verbindungsversuch tritt eine Zeitüberschreitung auf. Dies liegt daran, dass der Beispielfilter a
discardanstelle einerrejectAktion verwendet.user@unauthorized-remote-host ssh user@172.16.0.253 ssh: connect to host 172.16.0.253 port 22: Connection timed out
Die Ausgabe zeigt, dass die SSH-Verbindung nicht erfolgreich ist. Dadurch wird bestätigt, dass der Filter SSH-Datenverkehr korrekt blockiert, wenn er von einer unzulässigen Quelladresse gesendet wird. Das gleiche Ergebnis wird für Telnet-Sitzungen erwartet, die von einer nicht autorisierten IP-Quelladresse initiiert werden.
Verwenden Sie den
show firewall logBefehl, um zu überprüfen, ob der Firewall-Protokollpuffer auf dem R2-Gerät jetzt Einträge für Pakete mit einer nicht autorisierten Quelladresse enthält.user@R2> show firewall log Log : Time Filter Action Interface Protocol Src Addr Dest Addr 11:35:46 limit-mgmt-access D fxp0.0 TCP 10.0.0.119 172.16.0.253 11:35:14 limit-mgmt-access D fxp0.0 TCP 10.0.0.119 172.16.0.253 11:34:58 limit-mgmt-access D fxp0.0 TCP 10.0.0.119 172.16.0.253
Bedeutung
Die Ausgabe bestätigt, dass der Datenverkehr von der Quelladresse 10.0.0.119 mit einem Protokollierungsbegriff im limit-mgmt-access Filter übereinstimmt. Denken Sie daran, dass in diesem Beispiel nur der block_non_manager Begriff über eine Protokollaktion verfügt. In der Action Spalte wird a D angezeigt, um anzuzeigen, dass die Pakete verworfen wurden. Es wird bestätigt, dass es sich bei der Eingangsschnittstelle für den gefilterten Datenverkehr um den Verwaltungsport fxp0.0 auf dem Gerät handelt. Das Transportprotokoll TCP und die IP-Adressen der gefilterten Pakete werden ebenfalls angezeigt. Beachten Sie, dass die Quelladresse 10.0.0.119 für diesen Datenverkehr nicht in der manager-ip Präfixliste aufgeführt ist.
Diese Ergebnisse bestätigen, dass der Firewallfilter für dieses Beispiel ordnungsgemäß funktioniert.