Einleitung
In diesem Dokument wird beschrieben, wie eine zeitbasierte Zugriffskontrollregel auf dem von FDM mit REST-API verwalteten FTD konfiguriert und validiert wird.
Voraussetzungen
Anforderungen
Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:
- Sichere Firewall-Bedrohungsabwehr (FTD)
- FirePOWER-Gerätemanagement (FDM)
- Kenntnisse der REST-API (Representational State Transfer Application Programming Interface)
- Zugriffskontrollliste (ACL)
Verwendete Komponenten
Die Informationen in diesem Dokument basieren auf FTD-Version 7.1.0.
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.
Hintergrundinformationen
FTD API Version 6.6.0 und höher unterstützt Zugriffskontrollregeln, die zeitlich begrenzt sind.
Mithilfe der FTD-API können Sie Zeitbereichsobjekte erstellen, die einmalige oder wiederkehrende Zeitbereiche angeben, und diese Objekte auf Zugriffskontrollregeln anwenden. Mithilfe von Zeiträumen können Sie eine Zugriffskontrollregel auf Datenverkehr anwenden, der zu bestimmten Tageszeiten oder für bestimmte Zeiträume generiert wird, um die Netzwerknutzung flexibel zu gestalten. Sie können FDM nicht zum Erstellen oder Anwenden von Zeitbereichen verwenden. FDM zeigt Ihnen auch nicht an, ob auf eine Zugriffskontrollregel ein Zeitbereich angewendet wurde.
Konfigurieren
Schritt 1: Klicken Sie auf die erweiterten Optionen (Kebab-Menü), um den FDM API Explorer zu öffnen.
Bild 1. FDM-Web-Benutzeroberfläche.
Schritt 2: Wählen Sie die Kategorie AccessPolicy
, um die verschiedenen API-Aufrufe anzuzeigen.
Bild 2. API-Explorer-Webbenutzeroberfläche.
Schritt 3: Führen Sie den GET
Anruf aus, um die Zugriffsrichtlinien-ID zu erhalten.
Bild 3. Zugriffsrichtlinienkategorie.
Schritt 4: Sie müssen auf klicken,TRY IT OUT!
um die API-Antwort abzurufen.
Abbildung 4: TRY IT OUT!-Taste, die den API-Aufruf ausführt.
Schritt 5: Kopieren Sie die JSON
Daten aus dem Antworttext auf ein Notizblock. Später müssen Sie die Richtlinien-ID für die Zugriffskontrolle verwenden.
Bild 5. GET-Antwort von der Zugriffsrichtlinie.
Schritt 6: Suchen und öffnen Sie die Kategorie TimeRange im API-Explorer, um die verschiedenen API-Aufrufe anzuzeigen.
Bild 6. Kategorie "Zeitbereich".
Schritt 7. Erstellen Sie mithilfe des POST-API-Aufrufs beliebig viele TimeRange-Objekte.
Bild 7. POST-Anruf im Zeitbereich.
Hier finden Sie einige JSON
Formatbeispiele, um zwei verschiedene TimeRange-Objekte zu erstellen.
Objekt 1:
{
"name": "range-obj-1",
"recurrenceList": [
{
"days": [
"MON",
"TUE",
"WED",
"THU",
"FRI"
],
"recurrenceType": "DAILY_INTERVAL",
"dailyStartTime": "00:00",
"dailyEndTime": "23:50",
"type": "recurrence"
}
],
"type": "timerangeobject"
}
Objekt 2:
{
"name": "range-obj-2",
"recurrenceList": [
{
"days": [
"MON"
],
"recurrenceType": "DAILY_INTERVAL",
"dailyStartTime": "12:00",
"dailyEndTime": "13:00",
"type": "recurrence"
}
],
"type": "timerangeobject",
}
Hinweis: Denken Sie daran, auf TRY IT OUT!
zu klicken, um die API-Aufrufe durchzuführen.
Schritt 8: Führen Sie denGET
Aufruf aus, um die TimeRange-Objekt-IDs abzurufen.
Bild 8. GET-Antwort aus dem Zeitbereich.
Schritt 9. Klicken Sie auf dieDeploy
Schaltfläche, um Ihre Änderungen zu validieren und anzuwenden.
Bild 9. Schaltfläche "Bereitstellen" im API-Explorer verfügbar.
Schritt 10. Validieren Sie die soeben erstellte Konfiguration, und klicken Sie auf DEPLOY NOW.
Bild 10. Fenster "Ausstehende FDM-Änderungen".
Schritt 11. Suchen Sie dieAccessPolicy
Kategorie, und öffnen Sie den POST-Anruf, um eine zeitbasierte Zugriffskontrollregel zu erstellen.
Bild 11. Zugriffsrichtlinien-POST-Aufruf.
Hier finden Sie ein JSON
Formatbeispiel für die Erstellung einer zeitbasierten ACL, die den Datenverkehr von der Innen- zur Außenzone zulässt.
Stellen Sie sicher, dass Sie die richtige Objektkennung für den Zeitbereich verwenden.
{
"name": "test_time_range_2",
"sourceZones": [
{
"name": "inside_zone",
"id": "90c377e0-b3e5-11e5-8db8-651556da7898",
"type": "securityzone"
}
],
"destinationZones": [
{
"name": "outside_zone",
"id": "b1af33e1-b3e5-11e5-8db8-afdc0be5453e",
"type": "securityzone"
}
],
"ruleAction": "PERMIT",
"eventLogAction": "LOG_FLOW_END",
"timeRangeObjects": [
{
"id": "718e6b5c-2697-11ee-a5a7-57e37203b186",
"type": "timerangeobject",
"name": "Time-test2"
}
],
"type": "accessrule"
}
Hinweis: eventLogAction
Das Ereignis muss protokolliert werden, LOG_FlOW_END
damit es am Ende des Datenflusses protokolliert werden kann. Andernfalls wird ein Fehler ausgegeben.
Schritt 12: Stellen Sie die Änderungen bereit, um die neue zeitbasierte Zugriffskontrollliste anzuwenden. An der Eingabeaufforderung Pending Changes (Ausstehende Änderungen) muss das in Schritt 10 verwendete Zeitbereichsobjekt angezeigt werden.
Bild 12. Im Fenster "FDM - ausstehende Änderungen" wird die neue Regel angezeigt.
Schritt 13 (optional). Wenn Sie die Zugriffskontrollliste bearbeiten möchten, können Sie denPUT
Anruf verwenden und die Zeitbereich-ID bearbeiten.
Bild 13. Zugriffsrichtlinien-PUT-Anruf.
Hier finden Sie das JSON
Formatbeispiel. Um den Zeitraum zu bearbeiten, können diese Zeitbereich-IDs mithilfe desGET
Anrufs erfasst werden.
{
"version": "flya3jw7wvqg7",
"name": "test_time_range",
"ruleId": 268435460,
"sourceZones": [
{
"version": "lypkhscmwq4bq",
"name": "inside_zone",
"id": "90c377e0-b3e5-11e5-8db8-651556da7898",
"type": "securityzone"
}
],
"destinationZones": [
{
"version": "pytctz6vvfb3i",
"name": "outside_zone",
"id": "b1af33e1-b3e5-11e5-8db8-afdc0be5453e",
"type": "securityzone"
}
],
"sourceNetworks": [],
"destinationNetworks": [],
"sourcePorts": [],
"destinationPorts": [],
"ruleAction": "PERMIT",
"eventLogAction": "LOG_FLOW_END",
"identitySources": [],
"users": [],
"embeddedAppFilter": null,
"urlFilter": null,
"intrusionPolicy": null,
"filePolicy": null,
"logFiles": false,
"syslogServer": null,
"destinationDynamicObjects": [],
"sourceDynamicObjects": [],
"timeRangeObjects": [
{
"version": "i3iohbd5iufol",
"name": "range-obj-1",
"id": "718e6b5c-2697-11ee-a5a7-57e37203b186",
"type": "timerangeobject"
}
],
"id": "0f2e8f56-269b-11ee-a5a7-6f90451d6efd",
"type": "accessrule"
}
Schritt 14: Bereitstellen und Überprüfen Ihrer Änderungen
Bild 14. Im Fenster "FDM-ausstehende Änderungen" wird die Änderung des Objekts angezeigt.
Überprüfung
1. Führen Sie denshow time-range
Befehl aus, um den Status der Zeitbereichsobjekte zu überprüfen.
> show time-range
time-range entry: range-obj-1 (active)
periodic weekdays 0:00 to 23:50
time-range entry: range-obj-2 (inactive)
periodic Monday 12:00 to 13:00
2. Verwenden Sie denshow access-control-config
Befehl, um die Konfiguration der Zugriffskontrollregel zu validieren.
> show access-control-config
===============[ NGFW-Access-Policy ]===============
Description :
=================[ Default Action ]=================
Default Action : Block
Logging Configuration
DC : Enabled
Beginning : Disabled
End : Disabled
Rule Hits : 0
Variable Set : Object missing: 76fa83ea-c972-11e2-8be8-8e45bb1343c0
===[ Security Intelligence - Network Whitelist ]====
===[ Security Intelligence - Network Blacklist ]====
Logging Configuration : Disabled
DC : Disabled
=====[ Security Intelligence - URL Whitelist ]======
=====[ Security Intelligence - URL Blacklist ]======
Logging Configuration : Disabled
DC : Disabled
======[ Rule Set: admin_category (Built-in) ]=======
=====[ Rule Set: standard_category (Built-in) ]=====
-------------[ Rule: test_time_range ]--------------
Action : Allow
Source ISE Metadata :
Source Zones : inside_zone
Destination Zones : outside_zone
Users
URLs
Logging Configuration
DC : Enabled
Beginning : Disabled
End : Enabled
Files : Disabled
Safe Search : No
Rule Hits : 0
Variable Set : Object missing: 76fa83ea-c972-11e2-8be8-8e45bb1343c0
Time Range : range-obj-1
Daily Interval
StartTime : 00:00
EndTime : 23:50
Days : Monday,Tuesday,Wednesday,Thursday,Friday
3. Führen Sie einenSystem Support Trace
Debugvorgang aus, um zu bestätigen, dass der Datenverkehr die richtige Regel trifft.
> system support trace
Enable firewall-engine-debug too? [n]: y
Please specify an IP protocol: tcp
Please specify a client IP address:
Please specify a client port:
Please specify a server IP address:
Please specify a server port: 443
Monitoring packet tracer and firewall debug messages
10.10.10.3 62360 -> Destination IP 443 6 AS=0 ID=3 GR=1-1 New firewall session
10.10.10.3 62360 -> Destination IP 443 6 AS=0 ID=3 GR=1-1 app event with app id no change, url no change, tls host no change, bits 0x1
10.10.10.3 62360 -> Destination IP 443 6 AS=0 ID=3 GR=1-1 Starting with minimum 1, 'test_time_range', and SrcZone first with zones 2 -> 1, geo 0 -> 0, vlan 0, src sgt: 0, src sgt type: unknown, dst sgt: 0, dst sgt type: unknown, svc 0, payload 0, client 0, misc 0, user 9999997
10.10.10.3 62360 -> Destination IP 443 6 AS=0 ID=3 GR=1-1 match rule order 1, 'test_time_range', action Allow
10.10.10.3 62360 -> Destination IP 443 6 AS=0 ID=3 GR=1-1 MidRecovery data sent for rule id: 268435460, rule_action:2, rev id:2116550259, rule_match flag:0x1
10.10.10.3 62360 -> Destination IP 443 6 AS=0 ID=3 GR=1-1 allow action
10.10.10.3 62360 -> Destination IP 443 6 AS=0 ID=3 GR=1-1 Packet 1930048: TCP ******S*, 07/20-18:05:06.790013, seq 4109528346, dsize 0
10.10.10.3 62360 -> Destination IP 443 6 AS=0 ID=3 GR=1-1 Session: new snort session
10.10.10.3 62360 -> Destination IP 443 6 AS=0 ID=3 GR=1-1 AppID: service: (0), client: (0), payload: (0), misc: (0)
10.10.10.3 62360 -> Destination IP 443 6 AS=0 ID=3 GR=1-1 Firewall: starting rule matching, zone 2 -> 1, geo 0(0) -> 0, vlan 0, src sgt: 0, src sgt type: unknown, dst sgt: 0, dst sgt type: unknown, user 9999997, no url or host, no xff
10.10.10.3 62360 -> Destination IP 443 6 AS=0 ID=3 GR=1-1 Firewall: allow rule, 'test_time_range', allow
10.10.10.3 62360 -> Destination IP 443 6 AS=0 ID=3 GR=1-1 Policies: Network 0, Inspection 0, Detection 0
10.10.10.3 62360 -> Destination IP 443 6 AS=0 ID=3 GR=1-1 Verdict: pass