AUF DIESER SEITE
Abrufen von Benutzerrollen und der Prozess der Richtliniensuche
Abrufen von Benutzernamen- und Rolleninformationen über die Firewall-Authentifizierung
Konfigurieren einer Benutzerrollen-Firewall für die Captive Portal-Umleitung
Beispiel: Konfigurieren einer Benutzerrollen-Firewall auf einem Gerät der SRX-Serie
Konfigurieren von Ressourcenrichtlinien mithilfe der Benutzerkontensteuerung
Plattformspezifische Benutzerrolle Verhalten der Firewall-Sicherheitsrichtlinien
Benutzerrolle Firewall-Sicherheitsrichtlinien
Mit den Firewall-Richtlinien für Benutzerrollen können Administratoren den Netzwerkzugriff für Benutzer basierend auf den ihnen zugewiesenen Rollen zulassen oder einschränken. Firewalls für Benutzerrollen ermöglichen eine bessere Bedrohungsabwehr, stellen informativere forensische Ressourcen bereit, verbessern die Archivierung von Datensätzen zur Einhaltung gesetzlicher Vorschriften und verbessern die Bereitstellung von routinemäßigen Zugriffslösungen.
Grundlegendes zu Benutzerrollen-Firewalls
Die Durchsetzung, Überwachung und Berichterstellung von Netzwerksicherheit, die bald ausschließlich auf IP-Informationen basieren, wird für die dynamische und mobile Belegschaft von heute nicht mehr ausreichen. Durch die Integration von Benutzer-Firewall-Richtlinien können Administratoren den Netzwerkzugriff von Mitarbeitern, Auftragnehmern, Partnern und anderen Benutzern basierend auf den ihnen zugewiesenen Rollen zulassen oder einschränken. Firewalls für Benutzerrollen ermöglichen eine bessere Bedrohungsabwehr, stellen informativere forensische Ressourcen bereit, verbessern die Archivierung von Datensätzen zur Einhaltung gesetzlicher Vorschriften und verbessern die Bereitstellung von routinemäßigen Zugriffslösungen.
Firewalls für Benutzerrollen lösen zwei Aktionen aus:
Abrufen von Benutzer- und Rolleninformationen, die dem Datenverkehr zugeordnet sind
Bestimmen der auszuführenden Aktion basierend auf sechs Übereinstimmungskriterien im Kontext des Zonenpaars
Das Feld "source-identity" unterscheidet eine Firewall mit Benutzerrolle von anderen Firewalltypen. Wenn die Quellidentität in einer Richtlinie für ein bestimmtes Zonenpaar angegeben ist, handelt es sich um eine Benutzerrollen-Firewall. Die Benutzer- und Rolleninformationen müssen vor der Richtliniensuche abgerufen werden. Wenn die Quellidentität in keiner Richtlinie angegeben ist, ist die Benutzer- und Rollensuche nicht erforderlich.
Zum Abrufen von Benutzer- und Rolleninformationen werden Authentifizierungstabellen nach einem Eintrag mit einer IP-Adresse durchsucht, die dem Datenverkehr entspricht. Wenn ein Eintrag gefunden wird, wird der Benutzer als authentifizierter Benutzer klassifiziert. Wenn der Benutzer nicht gefunden wird, wird er als nicht authentifizierter Benutzer klassifiziert.
Der Benutzername und die Rollen, die einem authentifizierten Benutzer zugeordnet sind, werden für den Richtlinienabgleich abgerufen. Sowohl die Authentifizierungsklassifizierung als auch die abgerufenen Benutzer- und Rolleninformationen werden verwendet, um das Feld "source-identity" abzugleichen.
Die Merkmale des Datenverkehrs werden an die Richtlinienspezifikationen angepasst. Im Zonenkontext bestimmt die erste Richtlinie, die dem Benutzer oder der Rolle entspricht, und die fünf Standardübereinstimmungskriterien die Aktion, die auf den Datenverkehr angewendet werden soll.
In den folgenden Abschnitten werden das Zusammenspiel des Benutzer- und Rollenabrufs und des Richtliniensuchprozesses, Methoden zum Abrufen von Benutzer- und Rollenzuweisungen, Techniken zum Konfigurieren von Firewall-Richtlinien für Benutzerrollen und ein Beispiel für die Konfiguration von Firewall-Richtlinien für Benutzerrollen beschrieben.
Abrufen von Benutzerrollen und der Prozess der Richtliniensuche
Für die Richtliniensuche werden Firewall-Richtlinien nach Zonenpaar gruppiert (der Von-Zone und der Bis-Zone). Innerhalb des Zonenpaars werden IP-basierte Firewall-Richtlinien anhand von fünf Kriterien mit dem Datenverkehr abgeglichen: Quell-IP, Quell-Port, Ziel-IP, Ziel-Port und Protokoll.
Firewall-Richtlinien für Benutzerrollen enthalten ein sechstes Übereinstimmungskriterium: die Quellidentität. Das Feld source-identity gibt die Benutzer und Rollen an, für die die Richtlinie gilt. Wenn das Feld source-identity in einer Richtlinie innerhalb des Zonenpaars angegeben ist, müssen Benutzer- und Rolleninformationen abgerufen werden, bevor die Richtliniensuche fortgesetzt werden kann. (Wenn alle Richtlinien im Zonenpaar auf any
oder keinen Eintrag im Feld "source-identity" festgelegt sind, sind keine Benutzer- und Rolleninformationen erforderlich, und die fünf Standardübereinstimmungskriterien werden für die Richtliniensuche verwendet.)
Die Benutzeridentifikationstabelle (UIT) enthält Benutzer- und Rolleninformationen für einen aktiven Benutzer, der bereits authentifiziert wurde. Jeder Eintrag in der Tabelle ordnet eine IP-Adresse einem authentifizierten Benutzer und allen Rollen zu, die diesem Benutzer zugeordnet sind.
Wenn der Datenverkehr Benutzer- und Rollendaten erfordert, wird jede registrierte UIT nach einem Eintrag mit derselben IP-Adresse durchsucht. Wenn ein Benutzer nicht authentifiziert wurde, gibt es keinen Eintrag für diese IP-Adresse in der Tabelle. Wenn kein UIT-Eintrag vorhanden ist, wird der Benutzer als nicht authentifizierter Benutzer betrachtet.
Die Richtliniensuche wird fortgesetzt, nachdem die Benutzer- und Rolleninformationen abgerufen wurden. Die Merkmale des Datenverkehrs werden mit den Übereinstimmungskriterien in den Richtlinien abgeglichen. Das Feld source-identity einer Richtlinie kann einen oder mehrere Benutzer oder Rollen und die folgenden Schlüsselwörter angeben:
authenticated-user | Benutzer, die authentifiziert wurden. |
unauthenticated-user | Benutzer, die nicht authentifiziert wurden. |
any | Alle Benutzer unabhängig von der Authentifizierung. Wenn das Feld source-identity nicht konfiguriert oder in allen Richtlinien für das Zonenpaar auf any festgelegt ist, werden nur fünf Kriterien erfüllt. |
unknown-user | Benutzer können aufgrund einer Unterbrechung der Verbindung mit dem Authentifizierungsserver, z. B. einem Stromausfall, nicht authentifiziert werden. |
Stellen Sie sich z. B. user-c vor, der der mgmt-Rolle zugewiesen ist. Wenn Datenverkehr von der Vertrauenszone zur nicht vertrauenswürdigen Zone von user-c an der IP-Adresse 198.51.100.3 empfangen wird, wird die Richtliniensuche initiiert. Tabelle 1 stellt drei Richtlinien in einer Benutzerrollenfirewall für das Zonenpaar "Vertrauensstellung zu nicht vertrauenswürdig" dar.
|
|
|
|
|
|
|
|
|
---|---|---|---|---|---|---|---|---|
Platz 1 |
vertrauen |
Nicht vertrauenswürdig |
192.0.2.0 |
203.0.113.0 |
jegliche |
http (Englisch) |
leugnen |
– |
Platz 2 |
vertrauen |
Nicht vertrauenswürdig |
jegliche |
jegliche |
Geschäftsführung |
jegliche |
erlauben |
– |
Platz 3 |
vertrauen |
Nicht vertrauenswürdig |
198.51.100.3 |
jegliche |
Arbeitnehmer |
http (Englisch) |
leugnen |
– |
Alle Richtlinien für das Zonenpaar werden zuerst auf eine source-identity-Option überprüft. Wenn eine der Richtlinien einen Benutzer, eine Rolle oder ein Schlüsselwort angibt, muss der Benutzer- und Rollenabruf erfolgen, bevor die Richtliniensuche fortgesetzt wird. Tabelle 1 zeigt, dass die Richtlinie P2 mgmt als Quellidentität angibt, wodurch dies zu einer Benutzerrollen-Firewall wird. Benutzer und Rollen müssen abgerufen werden, bevor die Richtliniensuche fortgesetzt werden kann.
Der Benutzer- und Rollenabruf wird nicht ausgeführt, wenn das Schlüsselwort any oder keine Quellidentität in allen Richtlinien im Zonenkontext angegeben ist. In solchen Fällen werden nur die fünf verbleibenden Werte mit den Richtlinienkriterien abgeglichen.
Die in Tabelle 2 dargestellte UIT wird auf die IP-Adresse überprüft. Da die Adresse gefunden wird, werden der Benutzername user-c, alle für user-c aufgelisteten Rollen (in diesem Fall mgmt und employee) und das Schlüsselwort authenticated-user zu Daten, die verwendet werden, um den Datenverkehr mit dem source-identity
Feld einer Richtlinie abzugleichen.
Quell-IP-Adresse |
Nutzername |
Rollen |
---|---|---|
192.0.2.4 |
Benutzer-A |
Arbeitnehmer |
198.51.100.3 |
Benutzer-C |
Geschäftsführer, Mitarbeiter |
203.0.113.2 |
Benutzer |
Unternehmer |
Die Richtliniensuche wird fortgesetzt und vergleicht die Übereinstimmungskriterien in jeder Richtlinie in Tabelle 1 mit dem eingehenden Datenverkehr. Unter der Annahme, dass alle anderen Kriterien übereinstimmen, könnte die erste Richtlinie, die user-c, mgmt, employee, authenticated-user oder any im Feld source-identity angibt, eine Übereinstimmung für diesen Datenverkehr sein. Die Richtlinie P1 stimmt mit einer der abgerufenen Rollen für user-c überein, aber die Quell-IP-Adresse stimmt nicht überein. Daher wird die Richtliniensuche fortgesetzt. Für die Richtlinie P2 stimmen alle Kriterien mit dem Datenverkehr überein. Daher wird die Richtlinienmaßnahme befolgt und der Datenverkehr wird zugelassen. Beachten Sie, dass der Datenverkehr auch mit Richtlinie P3 übereinstimmt, aber die Firewall-Richtlinien der Benutzer sind endgültig – die Richtliniensuche endet, wenn die erste Richtlinienübereinstimmung gefunden wird. Da Richtlinie P2 allen Kriterien entspricht, wird die Richtliniensuche beendet, und Richtlinie P3 wird nicht überprüft.
Richtlinien können auch auf der Klassifizierung basieren, die einem Benutzer aus den Ergebnissen des Benutzer- und Rollenabrufs zugewiesen wurde. Betrachten Sie einen anderen Satz von Richtlinien für dasselbe Zonenpaar, dargestellt in Tabelle 3. Wenn Datenverkehr von user-q unter der IP 198.51.100.5 empfangen wird, ist der Abruf von Benutzern und Rollen erforderlich, da das Feld "source-identity" in mindestens einer der Richtlinien angegeben ist.
|
|
|
|
|
|
|
|
|
---|---|---|---|---|---|---|---|---|
Platz 1 |
vertrauen |
Nicht vertrauenswürdig |
jegliche |
jegliche |
nicht authentifizierter Benutzer |
http (Englisch) |
leugnen |
– |
Platz 2 |
vertrauen |
Nicht vertrauenswürdig |
jegliche |
jegliche |
Geschäftsführung |
jegliche |
erlauben |
– |
Platz 3 |
vertrauen |
Nicht vertrauenswürdig |
198.51.100.3 |
jegliche |
Arbeitnehmer |
http (Englisch) |
leugnen |
– |
Wenn die UIT-Einträge in Tabelle 2 überprüft werden, wird kein Eintrag für die IP-Adresse 198.51.100.5 gefunden. Daher wird der Benutzer als nicht authentifizierter Benutzer betrachtet. Wenn die Richtliniensuche fortgesetzt wird, stimmt der Datenverkehr mit der Richtlinie P1 überein, und der Datenverkehr wird abgelehnt.
Grundlegendes zur Benutzeridentifikationstabelle
Bei der Firewall der SRX-Serie enthält die Benutzeridentifikationstabelle (UIT) die IP-Adresse, den Benutzernamen und die Rolleninformationen für jeden authentifizierten Benutzer. Die Einträge sind nach IP-Adresse sortiert. Wenn Benutzernamen- und Rolleninformationen von einer Sicherheitsrichtlinie verlangt werden, werden alle UITs überprüft. Das Auffinden der IP-Adresse in einem Eintrag in einer der UITs bedeutet, dass der Benutzer unter dieser Adresse bereits erfolgreich authentifiziert wurde.
Jede Authentifizierungsquelle verwaltet ihre eigene UIT unabhängig und stellt Abfragefunktionen für den Zugriff auf Daten bereit. Es werden drei Arten von UITs unterstützt: die lokale Authentifizierungstabelle, die UAC-Authentifizierungstabelle (Unified Access Control) und die Firewallauthentifizierungstabelle.
Local authentication table | Eine statische UIT, die auf der Firewall der SRX-Serie entweder manuell oder programmgesteuert mit CLI-Befehlen erstellt wurde. Alle Benutzer, die in der lokalen Authentifizierungstabelle enthalten sind, gelten als authentifizierte Benutzer. Wenn eine übereinstimmende IP-Adresse gefunden wird, werden Benutzer- und Rolleninformationen aus dem Tabelleneintrag abgerufen und dem Datenverkehr zugeordnet. Benutzer- und Rolleninformationen können manuell auf dem Gerät erstellt oder von einem Authentifizierungsserver eines Drittanbieters portiert werden, die Daten in der lokalen Authentifizierungstabelle werden jedoch nicht in Echtzeit aktualisiert. |
UAC authentication table | Eine dynamische UIT, die vom Junos Pulse Access Control-Service zur Firewall der SRX-Serie übertragen wird. Die UAC-Authentifizierungstabelle eines Junos Pulse Access Control-Service enthält einen Eintrag für jeden authentifizierten Benutzer. Die Daten in dieser Tabelle werden aktualisiert und an die Firewall der SRX-Serie übertragen, sobald die zugehörige Authentifizierungstabelle aktualisiert wird. Abhängig von der Gerätekonfiguration kann die Authentifizierung auf dem Junos Pulse Access Control-Dienst selbst oder auf einem Authentifizierungsserver eines Drittanbieters erfolgen. Wenn der Access Control Service Daten von einem Server eines Drittanbieters weiterleitet, werden die Daten vom Access Control Service entsprechend dem Dateiformat der Authentifizierungstabelle umstrukturiert und an die Firewall der SRX-Serie übertragen. |
Firewall authentication table | Eine dynamische UIT, die auf der Firewall der SRX-Serie erstellt wird, wenn Der |
- Lokale Authentifizierungstabelle
- UAC-Authentifizierungstabelle
- Firewall-Authentifizierungstabelle
- Richtlinienbereitstellung mit Benutzern und Rollen
Lokale Authentifizierungstabelle
Die lokale Authentifizierungstabelle wird mit CLI-Befehlen verwaltet, die Einträge einfügen oder löschen. Eine lokale Authentifizierungstabelle kann als Sicherungslösung verwendet werden, wenn keine dynamische UIT verfügbar ist, oder um Benutzer- und Rolleninformationen Geräten zuzuweisen, die sich nicht beim Netzwerk authentifizieren können, z. B. Drucker oder Dateiserver. Die lokale Authentifizierungstabelle kann zu Testzwecken verwendet werden oder um zu demonstrieren, wie eine Benutzerrollen-Firewall funktioniert, ohne dass die Firewall-Authentifizierung oder der Zugriffssteuerungsdienst konfiguriert ist.
Die IP-Adressen, Benutzernamen und Rollen aus einer Authentifizierungsquelle eines Drittanbieters können heruntergeladen und der lokalen Authentifizierungstabelle programmgesteuert mithilfe von CLI-Befehlen hinzugefügt werden. Wenn eine Authentifizierungsquelle Benutzer und Gruppen definiert, können die Gruppen als Rollen konfiguriert und dem Benutzer wie gewohnt zugeordnet werden.
Um mit der UAC-Authentifizierungstabelle kompatibel zu sein, sind Benutzernamen auf 65 Zeichen und Rollennamen auf 64 Zeichen beschränkt. Die lokale Authentifizierungstabelle enthält je nach Junos OS Version in Ihrer Installation maximal 10.240 Authentifizierungseinträge auf SRX1500 Geräten und höher, 5120 Authentifizierungseinträge auf SRX650-Geräten und darunter. Die lokale Authentifizierungstabelle enthält 5120 Authentifizierungseinträge auf der Virtuelle Firewall vSRX. Jedem Authentifizierungseintrag können bis zu 200 Rollen zugeordnet werden. Die maximale Kapazität basiert auf durchschnittlich 10 Rollen, die jedem Benutzer zugewiesen sind. Dies ist die gleiche Kapazität, die für eine UAC-Authentifizierungstabelle angegeben ist.
Verwenden Sie den folgenden Befehl, um einer lokalen Authentifizierungstabelle einen Eintrag hinzuzufügen. Beachten Sie, dass jeder Eintrag nach IP-Adresse verschlüsselt wird.
user@host> request security user-identification local-authentication-table add user user-name ip-address ip-address role [role-name role-name ]
Die role-Option in einem einzelnen CLI-Befehl akzeptiert bis zu 40 Rollen. Um einem einzelnen Benutzer mehr als 40 Rollen zuzuordnen, müssen Sie mehrere Befehle eingeben. Beachten Sie die folgenden Merkmale, wenn Sie Authentifizierungs-, Benutzer- und Rolleneinträge hinzufügen oder ändern.
Rollennamen dürfen nicht mit Benutzernamen identisch sein.
Wenn Sie die
add
Option mit einer vorhandenen IP-Adresse und einem vorhandenen Benutzernamen verwenden, werden die Rolleneinträge aggregiert. Die Tabelle kann bis zu 200 Rollen pro Benutzer unterstützen.Wenn Sie die
add
Option mit einer vorhandenen IP-Adresse und einem neuen Benutzernamen verwenden, wird der vorhandene Benutzername für diese IP-Adresse überschrieben.Die Rollenaggregation wirkt sich nicht auf vorhandene Sitzungen aus.
Um die Rollenliste eines vorhandenen Eintrags zu ändern, müssen Sie den vorhandenen Eintrag löschen und einen Eintrag mit der neuen Rollenliste hinzufügen.
Um die IP-Adresse eines bestehenden Eintrags zu ändern, müssen Sie den vorhandenen Eintrag löschen und einen Eintrag mit der neuen IP-Adresse hinzufügen.
Ein Eintrag kann nach IP-Adresse oder nach Benutzername gelöscht werden.
user@host> request security user-identification local-authentication-table delete (ip-address | user-name)
Die lokale Authentifizierungstabelle kann mit dem folgenden Befehl gelöscht werden:
user@host> clear security user-identification local-authentication-table
Um den Inhalt der lokalen Authentifizierungstabelle anzuzeigen, verwenden Sie den folgenden show...
Befehl:
user@host> show security user-identification local-authentication-table all (brief | extensive)
Die brief
Option (Standardeinstellung) zeigt Informationen in einem Tabellenformat an, das nach IP-Adresse sortiert ist. Benutzernamen und Rollenlisten werden an das Format angepasst.
user@host> show security user-identification local-authentication-table all
Total entries: 2 Source IP Username Roles 198.51.100.1 user1 role1 203.0.113.2 user2 role2, role3
Die extensive
Option zeigt den vollständigen Inhalt für jedes Feld an. Andere Optionen beschränken die Anzeige auf einen einzelnen Benutzernamen, eine IP-Adresse oder eine Rolle.
user@host> show security user-identification local-authentication-table all extensive
Total entries: 3 Ip-address: 198.51.100.2 Username: user1 Roles: role1 Ip-address: 203.0.113.2 Username: user1 Roles: role2 Ip-address: 192.0.2.3 Username: user3 Roles: role1, role2
UAC-Authentifizierungstabelle
Eine Firewall der SRX-Serie kann als Enforcer für einen Junos Pulse Access Control Service fungieren. In dieser Implementierung fungiert die Firewall der SRX-Serie als Layer-3-Durchsetzungspunkt und steuert den Zugriff auf Ressourcen mit IP-basierten Ressourcenrichtlinien, die vom Zugriffssteuerungsservice nach unten verschoben wurden.
Wenn die Firewall der SRX-Serie als Benutzerrollen-Firewall implementiert wird, kann sie auf ähnliche Weise auf das UAC-Netzwerk zugreifen, um Benutzerrollen abzurufen. In diesem Fall werden Benutzer- und Rolleninformationen für alle authentifizierten Benutzer per Push aus dem Zugriffssteuerungsdienst übertragen.
Die Konfiguration der Firewall der SRX-Serie ähnelt der eines Enforcers. Um eine Kommunikation herzustellen, benötigen beide Geräte Konfigurations- und Passworteinstellungen, um das jeweils andere zu erkennen. Verbinden Sie über die Firewall der SRX-Serie den Access Control Service als Infranet-Controller.
[edit] user@host# set services unified-access-control infranet-controller ic-name address ip-address user@host# set services unified-access-control infranet-controller ic-name interface interface-name user@host# set services unified-access-control infranet-controller ic-name password password
Definieren Sie im Zugriffssteuerungsservice die Firewall der SRX-Serie als neuen Enforcer. Verwenden Sie dasselbe Passwort, das auf der Firewall der SRX-Serie angegeben ist.
Benutzer und Kennwörter werden im Zugriffssteuerungsdienst wie in einer Standardauthentifizierungskonfiguration definiert. Den Benutzern können auch eine oder mehrere Rollen zugeordnet werden. Wenn ein Benutzer authentifiziert wird, wird der UAC-Authentifizierungstabelle im Zugriffssteuerungsdienst ein Eintrag hinzugefügt, der die IP-Adresse, den Benutzernamen und die zugeordneten Rollen enthält.
Die UAC-Authentifizierungstabelle wird vom Zugriffssteuerungsdienst an die Firewall der SRX-Serie übertragen, wenn die Verbindung zwischen den beiden Geräten initialisiert wird. Jedes Mal, wenn ein Eintrag im Zugriffssteuerungsdienst hinzugefügt, entfernt oder aktualisiert wird, wird die aktualisierte UAC-Authentifizierungstabelle an die Firewall der SRX-Serie übertragen.
Richtlinien für den Ressourcenzugriff sind für den Zugriffssteuerungsdienst für die Implementierung einer Firewall für Benutzerrollen nicht erforderlich. Das Zugriffsverhalten wird in den Richtlinienkonfigurationen der Firewall der SRX-Serie bereitgestellt. Wenn Richtlinien für den Ressourcenzugriff im Zugriffssteuerungsdienst definiert sind, werden sie per Push an die Firewall der SRX-Serie übertragen, sie werden jedoch nur verwendet, wenn eine bestimmte Firewall-Richtlinie UAC-Richtlinien im Aktionsfeld der Richtlinie implementiert.
Der folgende show services
Befehl zeigt den Inhalt der UAC-Authentifizierungstabelle auf der Firewall der SRX-Serie an und bestätigt, dass die Tabelle erfolgreich vom Access Control Service übertragen wurde:
user@host> show services unified-access-control authentication-table extended
Id Source IP Username Age Role name 3 192.0.2.1 april 60 Users 6 192.0.2.2 june 60 Employeees Total: 2
Die Firewall der SRX-Serie überwacht Verbindungen und erkennt, ob die Kommunikation mit dem Access Control Service unterbrochen wurde. Basierend auf der UAC-Konfiguration wartet die Firewall der SRX-Serie für ein konfiguriertes Intervall auf eine Antwort, bevor sie eine weitere Anfrage ausgibt. Wenn eine Antwort empfangen wird, wird der Zugriffssteuerungsdienst als funktionsfähig betrachtet. Wenn nach einem bestimmten Timeoutzeitraum keine Antwort empfangen wird, gilt die Kommunikation als verloren und die Timeoutaktion wird angewendet. Mit der folgenden UAC-Befehlssyntax werden die Intervall-, Timeout- und Timeout-Aktion konfiguriert:
user@host# set services unified-access-control interval seconds user@host# set services unified-access-control timeout seconds user@host# set services unified-access-control timeout-action (close | no-change | open)
Wenn während einer Trennung der Verbindung versucht wird, eine Benutzer- und Rollensuche für das getrennte Gerät durchzuführen, wird unabhängig von der Zeitüberschreitungsaktion ein Fehlercode zurückgegeben. Wenn der Zugriff auf alle Authentifizierungsquellen verloren geht, wird der IP-Adresse das Schlüsselwort unknown-user zugeordnet. Wenn die Richtliniensuche fortgesetzt wird, stimmt eine Richtlinie mit unknown-user als Quellidentität mit dem Datenverkehr überein. Durch das Implementieren einer spezifischen Richtlinie für unknown-user können Sie eine Methode zum Behandeln des Verlusts von Authentifizierungsquellen erstellen.
Firewall-Authentifizierungstabelle
Bei der Firewall-Authentifizierung müssen sich Benutzer bei der Firewall der SRX-Serie authentifizieren, bevor sie den Zugriff zwischen Zonen und Geräten zulassen. Wenn Datenverkehr empfangen wird, wird der Benutzer zur Eingabe eines Benutzernamens und eines Kennworts aufgefordert und anhand eines angegebenen Profils gültiger Benutzer überprüft. Je nach Gerätekonfiguration überprüft die Firewall-Authentifizierung, ob Telnet-, HTTP-, HTTPS- (für SRX5800-, SRX5600- und SRX5400-Geräte) und FTP-Datenverkehr lokal oder von einem RADIUS-, LDAP- oder SecureID-Authentifizierungsserver authentifiziert wurde.
Wenn die Firewall-Authentifizierung auf einem Gerät verwendet wird, kann der Authentifizierungsprozess auch die Benutzernamen- und Rolleninformationen bereitstellen, die für die Übereinstimmungskriterien für die Firewall der Benutzerrolle erforderlich sind. In diesem Fall werden die Informationen in einer UIT gesammelt und verwaltet, die als Firewallauthentifizierungstabelle bezeichnet wird. Eine oder mehrere Zugriffsrichtlinien in der Hierarchie definieren Authentifizierungsmethoden, die für die edit access
Firewallauthentifizierung verwendet werden sollen.
Die Firewallauthentifizierungstabelle muss als Authentifizierungsquelle für den Abruf von Benutzerrolleninformationen aktiviert sein. Die priority
Option gibt die Reihenfolge an, in der alle UITs überprüft werden.
user@host# set security user-identification authentication-source firewall-authentication priority priority
In einer Firewall-Richtlinie für ein bestimmtes Zonenpaar initiiert der firewall-authentication
für die permit
Aktion angegebene Dienst die Authentifizierung des übereinstimmenden Datenverkehrs. Der user-firewall
Authentifizierungstyp generiert den UIT-Eintrag für den authentifizierten Benutzer. Der in der access-profile
Option angegebene Name identifiziert das Profil, das zur Authentifizierung gültiger Benutzer verwendet werden soll.
[edit security policies from-zone zone to-zone zone policy policy-name] user@host# set match source-identity unauthenticated-user user@host# set then permit firewall-authentication user-firewall access-profile profile-name
Der UIT-Tabelleneintrag enthält die IP-Adresse des Datenverkehrs, der dem authentifizierten Benutzer und den zugeordneten Gruppen des Benutzers zugeordnet ist. Wenn der Benutzer nicht mehr aktiv ist, wird der Eintrag aus der Tabelle entfernt. Da Einträge kontinuierlich hinzugefügt und entfernt werden, wenn sich der Datenverkehr und die authentifizierten Benutzer ändern, wird die Firewallauthentifizierungstabelle als dynamisch betrachtet.
Wenn Richtlinien innerhalb desselben Zonenpaars das source-identity
Feld als Teil der Übereinstimmungskriterien angeben, werden alle aktivierten UITs nach einem Eintrag durchsucht, der der IP-Adresse des Datenverkehrs entspricht. Wenn sie gefunden werden, werden der zugeordnete Benutzername und die Gruppen für den Abgleich mit der Quellidentität abgerufen. (Gruppennamen für die Benutzerauthentifizierung gelten als Rollennamen für den Abgleich von Quellidentität.)
Richtlinienbereitstellung mit Benutzern und Rollen
Alle Benutzer und Rollen, unabhängig davon, ob sie in der Firewall der SRX-Serie oder im Zugriffssteuerungsservice definiert sind, werden in einer Benutzerrollendatei auf der Firewall der SRX-Serie verwaltet. Verwenden Sie die folgenden show security...
Befehle, um alle Benutzer und Rollen anzuzeigen, die für die Bereitstellung verfügbar sind.
Benutzernamen und Rollen in der Firewall-Authentifizierungstabelle sind in den folgenden Anzeigen nicht enthalten.
Verwenden Sie den
show security user-identification role-provision all
Befehl, um alle Rollen anzuzeigen, die für die Bereitstellung verfügbar sind. Beachten Sie, dass die Rollen aus allen UITs zusammen aufgelistet werden.Verwenden Sie den
show security user-identification user-provision all
Befehl, um alle Benutzer anzuzeigen, die für die Bereitstellung verfügbar sind.Verwenden Sie den
show security user-identification source-identity-provision all
Befehl, um alle Benutzer und Rollen anzuzeigen, die für die Bereitstellung verfügbar sind.
Wenn für eine Richtlinienkonfiguration ein Commit ausgeführt wird, wird die Benutzerrollendatei überprüft, um festzustellen, ob alle in der Richtlinie angegebenen Benutzer und Rollen für die Bereitstellung verfügbar sind. Wenn ein Benutzer oder eine Rolle nicht gefunden wird, wird der fehlende Benutzer oder die fehlende Rolle durch eine Warnung identifiziert, sodass Sie sie später definieren können.
Die Richtlinie wird auch dann festgelegt, wenn ein Benutzer oder eine Rolle noch nicht definiert ist.
Abrufen von Benutzernamen- und Rolleninformationen über die Firewall-Authentifizierung
Firewall-Richtlinien für Benutzerrollen können in die Firewall-Authentifizierung integriert werden, um sowohl Benutzer zu authentifizieren als auch Benutzernamen- und Rolleninformationen abzurufen. Die Informationen werden der IP-Adresse des Datenverkehrs zugeordnet, in der Firewall-Authentifizierungstabelle gespeichert und für die Durchsetzung von Firewall-Richtlinien in der Benutzerrolle verwendet.
Die folgenden CLI-Anweisungen konfigurieren die Firewallauthentifizierung für die Durchsetzung der Firewall für Benutzerrollen.
Konfigurieren einer Benutzerrollen-Firewall für die Captive Portal-Umleitung
Um nicht authentifizierte Benutzer automatisch an den Zugriffssteuerungsdienst umzuleiten, verwenden Sie die UAC Captive Portal-Funktion. Die folgende Syntax definiert das Profil für das Captive Portal:
set services unified-access-control captive-portal profile-name redirect-traffic [unauthenticated | all] set services unified-access-control captive-portal profile-name redirect-url host-url
Das Kerberos-Protokoll, das für die Authentifizierungsverschlüsselung verwendet wird, identifiziert den Zugriffssteuerungsdienst nur anhand seines Dienstprinzipalnamens (Service Principal Name, SPN). Das Protokoll akzeptiert keine IP-Adresse. Daher muss das Format für die Weiterleitungs-URL
service://hostname/options
In dieser Implementierung ist der Dienst HTTP, und der Hostname ist der FQDN des Zugriffssteuerungsdiensts. Optionen, die nach dem Hostnamen angegeben werden, leiten zusätzliche Informationen an den Zugriffssteuerungsdienst weiter, die den Benutzer zurück zum ursprünglichen Ziel, zur Firewall der SRX-Serie oder zu der Richtlinie leiten, von der die Umleitung stammt. Sie können die Optionen mit den folgenden Schlüsselwort- und Variablenpaaren konfigurieren:
?target=%dest-url% | Gibt die geschützte Ressource an, auf die der Benutzer zugreifen möchte. |
&enforcer=%enforcer-id% | Gibt die ID an, die der Firewall der SRX-Serie zugewiesen wird, wenn sie vom Zugriffssteuerungsdienst als Enforcer konfiguriert wird. |
&policy=%policy-id% | Gibt die verschlüsselte Richtlinien-ID für die Sicherheitsrichtlinie an, die den Datenverkehr umgeleitet hat. |
Die folgenden Anweisungen definieren das Profil des Captive Portals mit dem Namen auth-redirect. Das Captive-Portal leitet nicht authentifizierte Benutzer zur Authentifizierung an die URL des Zugriffssteuerungsdiensts weiter. Nach erfolgreicher Authentifizierung wird der Datenverkehr zurück zur Firewall der SRX-Serie geleitet.
[edit] user@host# set services unified-access-control captive-portal auth-redirect redirect-traffic unauthenticated user@host# set services unified-access-control captive-portal auth-redirect redirect-url "http://ic6000.example.com/?target=%dest-url%&enforcer=%enforcer-id%&policy=%policy-id%"
Ein definiertes Captive-Portal-Profil wird als Teil der UAC-Konfiguration angezeigt.
[edit] user@host#show services
unified-access-control { captive-portal auth-redirect { redirect-traffic unauthenticated; redirect-url "http://ic6000.example.com/?target=%dest-url%&enforcer=%enforcer-id%&policy=%policy-id%"; } }
Nachdem das Profil definiert wurde, kann eine Richtlinie das Captive Portal als Anwendungsdienst anwenden, wenn bestimmte Kriterien erfüllt sind. Wenn eine Benutzerrolle nicht authentifiziert ist, leitet auth-redirect Captive Portal den Datenverkehr von der Vertrauenszone in die nicht vertrauenswürdige Zone um. Im folgenden Beispiel wird die Richtlinie P1 definiert, um das Captive Portal-Profil auth-redirect auf jeden HTTP-Datenverkehr von der Vertrauensstellung auf nicht vertrauenswürdig anzuwenden:
[edit] user@host# set security policies from-zone trust to-zone untrust policy P1 match application http user@host# set security policies from-zone trust to-zone untrust policy P1 match source-identity unauthenticated-user user@host# set security policies from-zone trust to-zone untrust policy P1 then permit application-services uac-policy captive-portal auth-redirect
Beispiel: Konfigurieren einer Benutzerrollen-Firewall auf einem Gerät der SRX-Serie
Im folgenden Beispiel wird eine Benutzerrollen-Firewall auf einer Firewall der SRX-Serie konfiguriert. Die Firewall steuert den Zugriff von der Vertrauenszone zur nicht vertrauenswürdigen Zone basierend auf aktiven, authentifizierten Benutzern oder den ihnen zugeordneten Rollen. Für Firewall-Richtlinien für Benutzerrollen gelten die folgenden Einschränkungen:
Nur authentifizierte Benutzer sind aus der Vertrauenszone in die nicht vertrauenswürdige Zone zulässig.
Nicht authentifizierte Benutzer werden zur Authentifizierung an einen Zugriffssteuerungsdienst umgeleitet.
Der Datenverkehr von IP 192.0.2.0 bis IP 203.0.113.0 innerhalb des Zonenkontexts ist eingeschränkt. Nur der Datenverkehr von Benutzern mit der Rolle "dev-abc", "http-juniper-accessible" oder "ftp-accessible" ist zulässig. Zulässiger Datenverkehr wird außerdem durch AppFW-Regeln ausgewertet.
Zulässiger Datenverkehr, der als junos:FACEBOOK-ACCESS, junos:GOOGLE-TALK oder junos:MEEBO identifiziert wurde, wird abgelehnt.
Zulässiger Datenverkehr für alle anderen Anwendungen ist zulässig.
Der gesamte andere Datenverkehr von der Vertrauenszone zur nicht vertrauenswürdigen Zone wird zugelassen.
Anforderungen
Bevor Sie beginnen, stellen Sie sicher, dass die Firewall der SRX-Serie mit Junos OS Version 12.1 oder höher konfiguriert und initialisiert ist.
In diesem Beispiel werden Benutzer- und Rolleninformationen, die der IP-Adresse des Datenverkehrs zugeordnet sind, von einem Zugriffssteuerungsdienst bereitgestellt. Anweisungen zum Konfigurieren des Zugriffssteuerungsservers finden Sie unter Konfigurieren von Active Directory als Identitätsquelle.
Überblick
Tabelle 4 beschreibt eine Firewall, die die Anforderungen für dieses Beispiel erfüllt. Die Firewall für die Benutzerrolle besteht aus vier Richtlinien.
|
|
|
|
|
|
|
|
|
---|---|---|---|---|---|---|---|---|
user-roll-fw1 |
vertrauen |
Nicht vertrauenswürdig |
jegliche |
jegliche |
nicht authentifizierter Benutzer |
http (Englisch) |
erlauben |
UAC Captive Portal |
user-roll-fw2 |
vertrauen |
Nicht vertrauenswürdig |
192.0.2.0 |
203.0.113.0 |
dev-abc http-juniper-zugänglich ftp-zugänglich |
http (Englisch) |
erlauben |
AppFW-Regelsatz RS1 |
user-rolle-fw3 |
vertrauen |
Nicht vertrauenswürdig |
192.0.2.0 |
203.0.113.0 |
jegliche |
http (Englisch) |
leugnen |
|
user-roll-fw4 |
vertrauen |
Nicht vertrauenswürdig |
jegliche |
jegliche |
jegliche |
http (Englisch) |
erlauben |
|
Da das Feld für mindestens eine der Richtlinien in dieser Firewall angegeben ist, müssen Benutzer source-identity
- und Rolleninformationen abgerufen werden, bevor die Richtliniensuche durchgeführt wird. Die Quell-IP des Datenverkehrs wird mit den Elementen in der UIT verglichen. Wenn die Quell-IP-Adresse gefunden wird, werden das Schlüsselwort authenticated
, der Benutzername und alle Rollen, die diesem Benutzer zugeordnet sind, für die spätere Verwendung in der Richtliniensuche gespeichert. Wenn kein passender Eintrag für die IP-Adresse in der UIT gefunden wird, wird das Schlüsselwort unauthenticated-user
für die Richtliniensuche gespeichert.
Nach dem Abrufen des Benutzernamens, der Rollen und Schlüsselwörter beginnt die Richtliniensuche. Die Merkmale des eingehenden Datenverkehrs werden mit den Übereinstimmungskriterien der einzelnen Richtlinien verglichen. Wenn eine Übereinstimmung gefunden wird, wird die in dieser Richtlinie angegebene Aktion ausgeführt.
Eine Richtlinienübereinstimmung ist ein Endereignis, und nach der Übereinstimmung werden keine Richtlinien überprüft. Die Richtliniensequenz beeinflusst die Aktion, die für den Abgleich von Datenverkehr ausgeführt werden soll. In diesem Beispiel werden die Richtlinien in der folgenden Reihenfolge angewendet:
user-role-fw1 | Wendet den UAC Captive Portal-Dienst an, um HTTP-Datenverkehr mit dem Schlüsselwort unauthenticated-user abzugleichen, und leitet ihn zur Authentifizierung an den Zugriffssteuerungsdienst um. Außerdem muss ein UAC-Profil konfiguriert werden, um die Spezifikationen des Captive Portals anzugeben. |
user-role-fw2 | Wendet einen AppFW-Regelsatz auf jeden HTTP-Datenverkehr von der Adresse 192.0.2.0 bis zur Adresse 203.0.113.0 an, die über einen übereinstimmenden Benutzernamen oder eine übereinstimmende Rolle verfügt. Außerdem muss eine Anwendungs-Firewall konfiguriert werden, um den Regelsatz zu definieren. |
user-role-fw3 | Verweigert den gesamten verbleibenden HTTP-Datenverkehr von der Adresse 192.0.2.0 bis zur Adresse 203.0.113.0 für dieses Zonenpaar. |
user-role-fw4 | Lässt den gesamten verbleibenden HTTP-Datenverkehr für dieses Zonenpaar zu. |
Konfiguration
Im folgenden Beispiel 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 der Umleitung für nicht authentifizierte Benutzer
- Erstellen einer Benutzerrollenrichtlinie mit einer Anwendungs-Firewall
- Erstellen der verbleibenden Sicherheitsrichtlinien basierend auf Benutzer und Rolle
Konfigurieren der Umleitung für nicht authentifizierte Benutzer
Schritt-für-Schritt-Anleitung
Wenn eine IP-Adresse nicht in der UIT aufgeführt ist, wird das Schlüsselwort unauthenticated-user bei der Richtliniensuche verwendet. Anstatt den Zugriff auf diesen Datenverkehr zu verweigern, kann eine Richtlinie den Datenverkehr zur Authentifizierung an ein UAC-Captive Portal umleiten.
Es ist wichtig, eine Umleitungsrichtlinie für nicht authentifizierte Benutzer vor einer Richtlinie für "beliebige" Benutzer zu positionieren, damit die UAC-Authentifizierung nicht von einer Richtlinie überschattet wird, die für authentifizierte Benutzer vorgesehen ist.
So konfigurieren Sie die Umleitung von der Firewall der SRX-Serie zum Zugriffssteuerungsservice:
Konfigurieren Sie im Konfigurationsmodus das UAC-Profil für das acs-device des Captive Portals.
[edit] user@host# set services unified-access-control captive-portal acs-device redirect-traffic unauthenticated-user
Konfigurieren Sie die Umleitungs-URL für den Zugriffssteuerungsdienst oder eine Standard-URL für das Captive Portal.
[edit] user@host# set services unified-access-control captive-portal acs-device redirect-url “https://%ic-url%/?target=%dest-url%&enforcer=%enforcer-id%”
Diese Richtlinie gibt die standardmäßigen Ziel- und Enforcervariablen an, die vom Zugriffssteuerungsdienst verwendet werden sollen, um den Benutzer nach der Authentifizierung zurückzuleiten. Dadurch wird sichergestellt, dass Änderungen an den Systemspezifikationen keine Auswirkungen auf die Konfigurationsergebnisse haben.
Anmerkung:Wenn Variablen, z. B
?target=
. , in der Befehlszeile enthalten sind, müssen Sie die URL und die Variablen in Anführungszeichen setzen.Konfigurieren Sie eine Firewallrichtlinie für die Benutzerrolle, die HTTP-Datenverkehr von der Zonenvertrauensstellung in die nicht vertrauenswürdige Zone umleitet, wenn die Quellidentität nicht authentifiziert ist. Der Profilname des Captive Portals wird als die Aktion angegeben, die für Datenverkehr ausgeführt werden soll, der dieser Richtlinie entspricht.
[edit] user@host# set security policies from-zone trust to-zone untrust policy user-role-fw1 match source-address any user@host# set security policies from-zone trust to-zone untrust policy user-role-fw1 match destination-address any user@host# set security policies from-zone trust to-zone untrust policy user-role-fw1 match application http user@host# set security policies from-zone trust to-zone untrust policy user-role-fw1 match source-identity unauthenticated-user user@host# set security policies from-zone trust to-zone untrust policy user-role-fw1 then permit application-services uac-policy captive-portal acs-device
Wenn Sie mit der Konfiguration der Richtlinien fertig sind, übernehmen Sie die Änderungen.
[edit] user@host# commit
Befund
Bestätigen Sie im Konfigurationsmodus Ihre Konfiguration, indem Sie die show services
Befehle und show security policies
eingeben. Wenn in der Ausgabe nicht die beabsichtigte Konfiguration angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
[edit]
user@host#
show services unified-access-control { captive-portal acs-device { redirect-traffic unauthenticated; redirect-url “https://%ic-ip%/?target=%dest-url%&enforcer=%enforcer-id%”
user@host#
show security policies
from-zone trust to-zone untrust {
policy user-role-fw1 {
match {
source-address any;
destination-address any;
application http;
source-identity unauthenticated-user
}
then {
permit {
application-services {
uac-policy {
captive-portal acs-device;
}
}
}
}
}
}
Erstellen einer Benutzerrollenrichtlinie mit einer Anwendungs-Firewall
Schritt-für-Schritt-Anleitung
Diese Richtlinie schränkt den Datenverkehr von IP192.0.2.0 bis IP 203.0.113.0 basierend auf dem Benutzer und den Rollen sowie der Anwendung ein. Die Konfiguration definiert einen Anwendungsregelsatz und wendet ihn auf den entsprechenden Benutzerrollendatenverkehr an.
Konfigurieren Sie den AppFW-Regelsatz rs1. Der folgende Regelsatz verweigert den Datenverkehr der Anwendungen junos:FACEBOOK-ACCESS, junos:GOOGLE-TALK oder junos:MEEBO. Die Standardeinstellung "Zulassen" wird auf den verbleibenden Datenverkehr angewendet.
[edit security application-firewall rule-sets rs1] user@host# set rule r1 match dynamic-application [junos:FACEBOOK-ACCESS junos:GOOGLE-TALK junos:MEEBO] user@host# set rule r1 then deny user@host# set default-rule permit
Konfigurieren Sie eine Richtlinie, um den Regelsatz der RS1-Anwendungsfirewall auf Datenverkehr von IP 192.0.2.0 bis IP 203.0.113.0 mit der Benutzerrolle dev-abc, http-mgmt-accessible oder ftp-accessible anzuwenden.
[edit] user@host# set security policies from-zone trust to-zone untrust policy user-role-fw2 match source-address 192.0.2.0 user@host# set security policies from-zone trust to-zone untrust policy user-role-fw2 match destination-address 203.0.113.0 user@host# set security policies from-zone trust to-zone untrust policy user-role-fw2 match application http user@host# set security policies from-zone trust to-zone untrust policy user-role-fw2 match source-identity [dev-abc http-mgmt-accessible ftp-accessible] user@host# set security policies from-zone trust to-zone untrust policy user-role-fw2 then permit application-services application-firewall rule-set rs1
Wenn Sie mit der Konfiguration der Richtlinie fertig sind, übernehmen Sie die Änderungen.
[edit] user@host# commit
Befund
Vergewissern Sie sich, dass der AppFW-Regelsatz ordnungsgemäß konfiguriert ist. Wenn in der Ausgabe nicht die beabsichtigte Konfiguration angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
[edit]
user@host#
show security application-firewall rule-sets rs1 { rule r1 { match { dynamic-application [junos:FACEBOOK-ACCESS junos:GOOGLE-TALK junos:MEEBO] } then { deny; } } default-rule { permit; } }
Erstellen der verbleibenden Sicherheitsrichtlinien basierend auf Benutzer und Rolle
Schritt-für-Schritt-Anleitung
Mit dem folgenden Verfahren werden Richtlinien für den verbleibenden Datenverkehr konfiguriert.
Konfigurieren Sie eine Richtlinie, um Datenverkehr mit derselben Quell- und Zieladresse, aber mit anderen Benutzer- und Rollenkriterien als in der Richtlinie user-role-fw2 angegeben abzulehnen.
[edit] user@host# set security policies from-zone trust to-zone untrust policy user-role-fw3 match source-address 192.0.2.0 user@host# set security policies from-zone trust to-zone untrust policy user-role-fw3 match destination-address 203.0.113.0 user@host# set security policies from-zone trust to-zone untrust policy user-role-fw3 match application http user@host# set security policies from-zone trust to-zone untrust policy user-role-fw3 match source-identity any user@host# set security policies from-zone trust to-zone untrust policy user-role-fw3 then deny
Konfigurieren Sie eine Sicherheitsrichtlinie, um den gesamten anderen HTTP-Datenverkehr von der Zonenvertrauensstellung bis zur Zonennicht vertrauenswürdig zuzulassen.
[edit] user@host# set security policies from-zone trust to-zone untrust policy user-role-fw4 match source-address any user@host# set security policies from-zone trust to-zone untrust policy user-role-fw4 match destination-address any user@host# set security policies from-zone trust to-zone untrust policy user-role-fw4 match application http user@host# set security policies from-zone trust to-zone untrust policy user-role-fw4 match source-identity any user@host# set security policies from-zone trust to-zone untrust policy user-role-fw4 then permit
Befund
Überprüfen Sie den Inhalt und die Reihenfolge der Firewall-Richtlinien für die Benutzerrolle. Wenn in der Ausgabe nicht die beabsichtigte Konfiguration angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
[edit]
user@host#
show security policies ... from-zone trust to-zone untrust { policy user-role-fw1 { match { source-address any; destination-address any; application http; source-identity unauthenticated-user } then { permit { application-services { uac-policy { captive-portal acs-device; } } } } } } from-zone trust to-zone untrust { policy user-role-fw2 { match { source-address 192.0.2.0; destination-address 203.0.113.0; application http; source-identity [dev-abc http-juniper-accessible ftp-accessible] } then { permit { application-services { application-firewall { rule-set rs1 } } } } } } from-zone trust to-zone untrust { policy user-role-fw3 { match { source-address 192.0.2.0; destination-address 203.0.113.0; application http; source-identity any } then { deny } } } from-zone trust to-zone untrust { policy user-role-fw4 { match { source-address any; destination-address any; application http; source-identity any } then { permit } } }
Konfigurieren von Ressourcenrichtlinien mithilfe der Benutzerkontensteuerung
Wenn Sie die Firewallfunktion für Benutzerrollen verwenden, sind Ressourcenrichtlinien für den Zugriffssteuerungsdienst nicht erforderlich. Wenn jedoch Ressourcenrichtlinien vorhanden sind, werden diese bei der Verbindung an die Firewall der SRX-Serie übertragen. Sie können Richtlinien erstellen, die diese Ressourcenrichtlinien verwenden, indem Sie den UAC-Anwendungsdienst in der Richtlinienkonfiguration anwenden. Tabelle 5 zeigt drei Firewall-Richtlinien, die ausschließlich die UAC-Ressourcenrichtlinien verwenden:
|
|
|
|
|
|
|
|
|
---|---|---|---|---|---|---|---|---|
Platz 1 |
Zone1 |
Zone 2 |
jegliche |
192.0.2.1 |
jegliche |
http (Englisch) |
erlauben |
Inhaltssicherheit |
Platz 2 |
Zone1 |
Zone 2 |
jegliche |
net2 |
jegliche |
http (Englisch) |
erlauben |
IDP |
Platz 3 |
Zone1 |
Zone 2 |
jegliche |
jegliche |
jegliche |
jegliche |
erlauben |
UAC |
Die Richtlinien für den Datenverkehr von Zone1 zu Zone2 initiieren keinen Benutzer- und Rollenabruf, da im Feld "source-identity" jeder Richtlinie ein solcher angegeben ist. In diesem Beispiel ist der Datenverkehr an die IP-Adresse 192.0.2.1 zulässig, muss jedoch die Verarbeitungsanforderungen für den angegebenen Anwendungsdienst erfüllen, in diesem Fall die Inhaltssicherheit. Datenverkehr zu net2 wird durch die IDP-Verarbeitungsanforderungen zugelassen und verarbeitet. Verbleibender Datenverkehr wird durch die UAC-Verarbeitungsanforderungen zugelassen und verarbeitet.
Die Konfiguration für diese Firewall-Richtlinie würde wie folgt aussehen:
[edit]
user@host#
show security policies from-zone zone1 to-zone zone2 { policy P1 { match { source-address any; destination-address 192.0.2.1; source-identity any; application http; } then { permit { application-services { idp; } } } } } from-zone zone1 to-zone zone2 { policy P2 { match { source-address any; destination-address net2; source-identity any; application http; } then { permit { application-services { utm; } } } } } from-zone zone1 to-zone zone2 { policy P3 { match { source-address any; destination-address any; source-identity any; application any; } then { permit { application-services { uac-policy; } } } } }
In dieser Beispielkonfiguration wenden die Aktionsfelder in P1 und P2 alle Anforderungen an, die für IDP bzw. Content Security konfiguriert wurden. Durch Angeben der Option uac-policy bestimmen die an die Firewall der SRX-Serie übertragenen Ressourcenrichtlinien, ob auf das Ziel zugegriffen werden kann.
Eine Benutzerrollenfirewall kann sowohl Benutzerrollenrichtlinien als auch Ressourcenrichtlinien implementieren, die vom Zugriffssteuerungsdienst übertragen werden. Tabelle 6 zeigt die Richtlinien für drei Zonenpaare.
|
|
|
|
|
|
|
|
|
---|---|---|---|---|---|---|---|---|
Platz 1 |
Zone1 |
Zone 2 |
jegliche |
jegliche |
nicht authentifizierter Benutzer |
jegliche |
erlauben |
UAC Captive Portal |
Platz 2 |
Zone1 |
Zone 2 |
jegliche |
192.0.2.1 |
Rolle2 |
http (Englisch) |
erlauben |
IDP |
Platz 3 |
Zone1 |
Zone 2 |
jegliche |
net2 |
authentifizierter Benutzer |
http (Englisch) |
erlauben |
Inhaltssicherheit |
Platz 4 |
Zone1 |
Zone 2 |
jegliche |
jegliche |
jegliche |
jegliche |
erlauben |
|
Platz 5 |
Zone1 |
Zone 3 |
jegliche |
jegliche |
jegliche |
jegliche |
erlauben |
UAC |
Platz 6 |
Zone 2 |
Zone 3 |
jegliche |
jegliche |
jegliche |
jegliche |
erlauben |
UAC |
Der Datenverkehr von Zone1 zu Zone2 unterliegt einer von vier Benutzerrollenrichtlinien. Die erste dieser Richtlinien verwendet das UAC-Captive Portal, um nicht authentifizierte Benutzer zur Authentifizierung an den Zugriffssteuerungsdienst umzuleiten.
Der Zugriff des Datenverkehrs von Zone1 zu Zone3 und von Zone2 zu Zone3 wird durch die vom Zugriffssteuerungsdienst gepushten Ressourcenrichtlinien gesteuert.
Plattformspezifische Benutzerrolle Verhalten der Firewall-Sicherheitsrichtlinien
Verwenden Sie Funktionen entdecken, um die Plattform- und Releaseunterstützung für bestimmte Funktionen zu bestätigen.
Verwenden Sie die folgenden Tabellen, um das plattformspezifische Verhalten für Ihre Plattform zu überprüfen:
- Plattformspezifisches lokales Authentifizierungsverhalten
- Plattformspezifisches Firewall-Authentifizierungsverhalten
Plattformspezifisches lokales Authentifizierungsverhalten
Bahnsteig |
Unterschied |
---|---|
SRX-Serie |
|
Plattformspezifisches Firewall-Authentifizierungsverhalten
Bahnsteig |
Unterschied |
---|---|
SRX-Serie |
|