Introduction
Ce document décrit comment configurer et valider une règle de contrôle d'accès basée sur le temps sur le FTD géré par FDM avec l'API Rest.
Conditions préalables
Exigences
Cisco vous recommande de prendre connaissance des rubriques suivantes :
- Protection pare-feu contre les menaces (FTD)
- Gestion des périphériques Firepower (FDM)
- Connaissance de l'interface de programmation REST (Representational State Transfer Application Programming Interface)
- Liste de contrôle d'accès (ACL)
Composants utilisés
Les informations contenues dans ce document sont basées sur la version FTD 7.1.0.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Informations générales
L'API FTD version 6.6.0 et ultérieure prend en charge des règles de contrôle d'accès limitées dans le temps.
À l'aide de l'API FTD, vous pouvez créer des objets d'intervalle de temps qui spécifient des intervalles de temps uniques ou récurrents et appliquer ces objets aux règles de contrôle d'accès. À l'aide de plages horaires, vous pouvez appliquer une règle de contrôle d'accès au trafic à certains moments de la journée ou pendant certaines périodes, afin de fournir une certaine flexibilité à l'utilisation du réseau. Vous ne pouvez pas utiliser FDM afin de créer ou d'appliquer des intervalles de temps, et FDM ne vous indique pas si une plage de temps est appliquée à une règle de contrôle d'accès.
Configurer
Étape 1. Cliquez sur les options avancées (menu Kebab) afin d'ouvrir l'explorateur d'API FDM.
Image 1. Interface utilisateur Web FDM.
Étape 2. Choisissez la catégorie AccessPolicy
afin d'afficher les différents appels d'API.
Image 2. Interface utilisateur Web de l'API Explorer.
Étape 3. Exécutez l'GET
appel afin d'obtenir l'ID de stratégie d'accès.
Image 3. Accéder à la catégorie Stratégie.
Étape 4. Vous devez cliquer surTRY IT OUT!
pour récupérer la réponse de l'API.
Image 4. TRY IT OUT ! qui exécute l'appel API.
Étape 5. Copiez les JSON
données du corps de la réponse dans un bloc-notes. Vous devez ensuite utiliser l'ID de stratégie de contrôle d'accès.
Image 5. Réponse GET de la politique d'accès.
Étape 6. Recherchez et ouvrez la catégorie TimeRange dans l'Explorateur d'API afin d'afficher les différents appels d'API.
Image 6. Catégorie Intervalle de temps.
Étape 7. Créez autant d'objets TimeRange que vous le souhaitez en utilisant l'appel de l'API POST.
Image 7. Intervalle de temps de l'appel POST.
Vous trouverez ici quelques exemples de JSON
format pour créer deux objets TimeRange différents.
Objet 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"
}
Objet 2 :
{
"name": "range-obj-2",
"recurrenceList": [
{
"days": [
"MON"
],
"recurrenceType": "DAILY_INTERVAL",
"dailyStartTime": "12:00",
"dailyEndTime": "13:00",
"type": "recurrence"
}
],
"type": "timerangeobject",
}
Remarque : n'oubliez pas d'appuyer sur TRY IT OUT!
pour exécuter les appels API.
Étape 8. Exécutez l'GET
appel pour obtenir les ID d'objet TimeRange.
Image 8. Réponse GET de Time Range.
Étape 9. Cliquez sur le boutonDeploy
afin de valider et d'appliquer vos modifications.
Image 9. Bouton Déployer disponible à partir de l'explorateur API.
Étape 10. Validez la configuration que vous venez de créer et cliquez sur DEPLOY NOW.
Image 10. Fenêtre Modifications FDM en attente.
Étape 11. Recherchez la catégorieAccessPolicy
et ouvrez l'appel POST afin de créer une règle de contrôle d'accès basée sur le temps.
Image 11. Stratégie d'accès appel POST.
Trouvez ici un exemple de JSON
format pour créer la liste de contrôle d'accès basée sur l'heure qui autorise le trafic de la zone interne vers la zone externe.
Assurez-vous d'utiliser l'ID d'objet Time Range correct.
{
"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"
}
Remarque : eventLogAction
doit être LOG_FlOW_END
pour enregistrer l'événement à la fin du flux, sinon il donne une erreur.
Étape 12. Déployez les modifications afin d'appliquer la nouvelle liste de contrôle d'accès basée sur le temps. L'invite Modifications en attente doit afficher l'objet de plage de temps utilisé à l'étape 10.
Image 12. La fenêtre Modifications en attente FDM affiche la nouvelle règle.
Étape 13 (facultatif). Si vous souhaitez modifier la liste de contrôle d'accès, vous pouvez utiliser l'PUT
appel et modifier l'ID de plage horaire.
Image 13. Stratégie d'accès Appel PUT.
Recherchez ici l' JSON
exemple de format. Pour modifier la plage horaire, ces ID de plage horaire peuvent être collectés à l'aide de cetGET
appel.
{
"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"
}
Étape 14. Déployez et validez vos modifications.
Image 14. La fenêtre Modifications en attente FDM affiche la modification de l'objet.
Vérifier
1. Exécutez la commandeshow time-range
afin de valider le statut de vos objets de plage de temps.
> 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. Utilisez la commandeshow access-control-config
afin de valider la configuration de la règle de contrôle d’accès.
> 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. Exécutez un débogageSystem Support Trace
afin de confirmer que le trafic atteint la règle correcte.
> 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