Contents

Introdução

Pré-requisitos

Requisitos

Componentes Utilizados

Informações de Apoio

Configurar

Verificar

Introdução

Este documento descreve como configurar e validar uma regra de controle de acesso com base no tempo com API Rest no FTD gerenciado pelo FDM.

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

- Firepower Threat Defense (FTD)

- FDM (Firepower Device Management, Gerenciamento de dispositivos do Firepower)

- Conhecimento da interface de programação de aplicativo de transferência de estado representacional (REST API)

- Lista de controle de acesso (ACL)

Componentes Utilizados

As informações neste documento são baseadas no FTD versão 7.1.0.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Informações de Apoio

A API do FTD versão 6.6.0 e posterior suporta regras de controle de acesso que são limitadas com base no tempo.

Usando a API do FTD, você pode criar objetos de intervalo de tempo, que especificam intervalos de tempo únicos ou recorrentes, e aplicar esses objetos às regras de controle de acesso. Usando intervalos de tempo, você pode aplicar uma regra de controle de acesso ao tráfego durante determinados horários do dia ou por determinados períodos de tempo, a fim de fornecer flexibilidade ao uso da rede. Não é possível usar o FDM para criar ou aplicar intervalos de tempo, nem o FDM mostrará se uma regra de controle de acesso tem um intervalo de tempo aplicado a ela.

Configurar

Etapa 1. Clique nas opções avançadas (menu Kebab) para abrir o FDM API explorer.

Imagem 1. Interface do usuário da Web do FDM.

Etapa 2. Escolha a categoria AccessPolicy para exibir as diferentes chamadas de API.

Imagem 2. Interface de usuário da Web do API Explorer.

Etapa 3. Execute o comando GET para obter a ID da política de acesso.

Imagem 3. Categoria de política de acesso.

Etapa 4. Você deve pressionar em TRY IT OUT!  para recuperar a resposta da API.

Imagem 4. TESTE! botão que executa a chamada à API.

Etapa 5. Copie o JSON dados do corpo da resposta para um bloco de notas. Posteriormente, você deverá usar a ID da Política de Controle de Acesso.

Imagem 5. Resposta GET da Política de Acesso.

Etapa 6. Localize e abra a categoria TimeRange no API Explorer para exibir as diferentes chamadas de API.

Imagem 6. Categoria de intervalo de tempo.

Passo 7. Crie quantos objetos TimeRange desejar usando a chamada à API POST.

Imagem 7. Intervalo de tempo após a chamada.

Encontre aqui algumas JSON formate exemplos para criar dois objetos TimeRange diferentes.

Objeto 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"

}

Objeto 2:

{

"name": "range-obj-2",

"recurrenceList": [

{

"days": [

"MON"

],

"recurrenceType": "DAILY_INTERVAL",

"dailyStartTime": "12:00",

"dailyEndTime": "13:00",

"type": "recurrence"

}

],

"type": "timerangeobject",

}

Observação: lembre-se de pressionar em TRY IT OUT!  para executar as chamadas de API.

Etapa 8. Execute o comando GET  chamada para obter as IDs de objeto de TimeRange.

Imagem 8. Resposta GET do Intervalo de Tempo.

Etapa 9. Clique no botão Deploy  para validar e aplicar suas alterações.

Imagem 9. Botão Implantar disponível no explorador de API.

Etapa 10. Valide a configuração recém-criada e clique em DEPLOY NOW.

Imagem 10. Janela Alterações Pendentes do FDM.

Etapa 11. Localize o AccessPolicy e abra a chamada POST para criar uma regra de controle de acesso baseada em tempo.

Imagem 11. Política de acesso - Chamada POST.

Encontre aqui um JSON formate um exemplo para criar a ACL baseada em tempo que permite o tráfego de dentro para fora da zona.

Certifique-se de usar a ID de objeto de Intervalo de tempo correta.

{

"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"

}

Note: eventLogAction deve ser LOG_FlOW_END para registrar o evento no final do fluxo, caso contrário, ele emitirá um erro.

Etapa 12. Implante as alterações para aplicar a nova ACL baseada em tempo. O prompt Alterações Pendentes deve exibir o objeto de intervalo de tempo usado na Etapa 10.

Imagem 12. A janela Alterações Pendentes do FDM exibe a nova regra.

Etapa 13 (opcional). Se quiser editar a ACL, você pode usar o comando PUT ligue e edite a ID do intervalo de tempo.

Imagem 13. Acesse a chamada PUT da política.

Encontre aqui o JSON para editar o intervalo de tempo, esses IDs de intervalo de tempo podem ser coletados usando o comandoGET chamada.

{

"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"

}

Etapa 14. Implante e valide suas alterações.

Imagem 14. A janela Alterações Pendentes do FDM exibe a alteração do objeto.

Verificar

1. Execute o comando show time-range para validar o status dos objetos de intervalo de tempo.

> 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. Use o comando show access-control-config  para validar a configuração da regra de controle de acesso.

> 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. Execute um System Support Trace  debug para confirmar se o tráfego está atingindo a regra correta.

> 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