# Bloquear atacantes automaticamente a partir de detecções do SIEM Uma equipe de SOC detecta ameaças no seu SIEM mas aplica bloqueios à mão, então um atacante continua alcançando as aplicações entre a detecção e a mitigação. O firewall já roda WAF, e os seus eventos já chegam ao SIEM, mas nada leva uma decisão de volta. Esta página configura uma network list que uma regra de firewall nega, a chamada que um playbook de SIEM ou SOAR envia para adicionar um endereço a ela com uma expiração e o job que remove os itens expirados. O resultado é medido pelo tempo entre a detecção e o bloqueio e pela parcela de incidentes mitigados sem passos manuais. Este caso de uso não cobre a lógica de detecção em si, que fica no SIEM da equipe. ## Pré-requisitos - Um firewall vinculado ao workload de cada aplicação a proteger, com WAF aplicado por uma regra. Para montar um, consulte [Primeiros passos com WAF](/pt-br/documentacao/plataforma/firewall/waf/primeiros-passos/). - Um stream dos eventos do WAF para o SIEM. Para criá-lo, consulte [Envie eventos do WAF para um SIEM](/pt-br/documentacao/guias/seguranca-de-aplicacoes/firewall-e-waf/integrar-siems/). - Um personal token para o playbook, criado por um usuário cuja equipe tem a permissão **Edit Network Lists**. Para criar um, consulte [Gerencie personal tokens](/pt-br/documentacao/guias/plataforma/conta-e-billing/personal-tokens/), e para a permissão, consulte [Permissões](/pt-br/documentacao/plataforma/firewall/network-shield/network-lists/#permissoes). - Uma plataforma de SIEM ou SOAR que consiga enviar uma requisição HTTPS a partir de um playbook e executar um job de forma agendada. - Os valores do seu ambiente. Esta página usa `siem-blocklist` como lista, `192.0.2.10` como um endereço que a sua equipe bloqueia permanentemente, `198.51.100.23` como um endereço que uma detecção sinaliza, `DET-4471` como o ID da detecção e `www.example.com` como domínio. Substitua cada valor pelo seu em todos os passos. --- ## Produtos necessários | O SOC precisa de | O que significa | Produto | Documentado em | | ------------------------------------------------------------------ | -------------------------------------------------------------------------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Eventos do firewall e do WAF no SIEM, onde as detecções rodam | Um stream da fonte de dados *WAF Events* para o endpoint do SIEM | Data Stream | [Envie eventos do WAF para um SIEM](/pt-br/documentacao/guias/seguranca-de-aplicacoes/firewall-e-waf/integrar-siems/) | | Os sinais de ataque que as detecções leem | Um WAF rule set que uma regra *Set WAF* aplica às requisições da aplicação | WAF | [Primeiros passos com WAF](/pt-br/documentacao/plataforma/firewall/waf/primeiros-passos/) | | Um bloqueio que um playbook consegue aplicar sem alterar uma regra | Uma network list que uma regra de negação lê pelo critério *Network* | Network Shield | [Network Lists](/pt-br/documentacao/plataforma/firewall/network-shield/network-lists/) | | Bloqueios que terminam sozinhos | Uma data de vencimento em cada item, aplicada por uma gravação agendada da lista | Network Shield | [Atualize uma network list a partir de uma automação](/pt-br/documentacao/guias/seguranca-de-aplicacoes/bots-e-rede/atualizar-network-list-a-partir-de-automacao/) | --- ## Arquitetura de referência Esta página constrói o *loop de mitigação no firewall orientado pelo SIEM*: os eventos saem do firewall para o SIEM, e uma detecção volta como um item em uma network list que uma regra de firewall já aplica. ```mermaid %%{init: {"layout": "dagre", "themeVariables": {"fontSize": "13px"}, "flowchart": {"nodeSpacing": 12, "rankSpacing": 12, "padding": 6, "wrappingWidth": 70, "minNodeWidth": 40, "useMaxWidth": true}}}%% flowchart TD Attacker["Atacante"] -->|"requisições"| FW["firewall: regra de negação em siem-blocklist, depois WAF"] FW -->|"WAF Events"| DS["Data Stream"] DS --> SIEM["SIEM: detecção"] SIEM --> SOAR["playbook de SOAR"] SOAR -->|"PATCH com um item datado"| API["API da Azion"] API --> List["siem-blocklist"] List -->|"lida pela regra de negação"| FW Job["job de expiração, agendado"] -->|"gravação dos mesmos itens"| API ``` Leia o diagrama como um loop que começa e termina no firewall. Os eventos saem dele pelo Data Stream, a decisão é tomada no SIEM, e a decisão volta como dado, um item em `siem-blocklist`, nunca como uma regra nova. A regra que lê a lista existe antes de qualquer detecção, então o loop altera o que o firewall corresponde sem alterar a sua configuração. O job de expiração fecha o loop pelo outro lado, encerrando cada bloqueio quando o seu prazo passa. ### Fluxo de dados 1. As requisições do atacante chegam ao firewall. O WAF as pontua, e o Data Stream envia os eventos do WAF ao SIEM. 2. Uma detecção no SIEM inicia um playbook de SOAR, que lê `siem-blocklist`, adiciona o endereço do atacante com uma data de vencimento e grava a lista de volta pela API. 3. A regra de negação já lê `siem-blocklist`, então as próximas requisições desse endereço recebem `403` assim que a alteração chega ao tráfego, em cerca de 100 segundos. 4. Uma lista pode ser lida por regras em vários firewalls, então uma gravação bloqueia o endereço em toda aplicação que esses firewalls protegem. 5. Um job agendado grava os itens da lista de volta, e a plataforma descarta todo item cuja data de vencimento passou, o que encerra esse bloqueio. ### Componentes - **Data Stream**: exporta os eventos do WAF do firewall para o endpoint que o SIEM lê, que é onde o loop começa. - **SIEM ou SOAR**: a integração que guarda a lógica de detecção e executa o playbook que transforma uma detecção em uma atualização da lista. - **API e Terraform Provider**: os Platform Resources pelos quais o playbook atualiza a lista. A API substitui os itens da lista a cada gravação, e o Terraform Provider gerencia a lista como um recurso. - **Network Shield**: adiciona o critério *Network* que compara cada endereço de cliente com a lista, e guarda a lista com uma data de vencimento e um comentário em cada item. - **firewall**: o Platform Resource que aplica o bloqueio. A sua regra de negação na lista roda antes do WAF, então um endereço listado é recusado antes de ser pontuado. - **WAF**: a fonte dos eventos. Os seus scores, as regras correspondidas e as actions são o que as detecções do SIEM leem. --- ## Configure a lista e a regra que a aplica A regra existe antes de qualquer detecção, então um playbook nunca cria nem altera uma regra. Uma alteração nos itens de uma lista chega ao tráfego em cerca de 100 segundos, enquanto uma regra nova leva de 6 a 10 minutos, e uma lista não soma nada às regras que o seu plano inclui por firewall. A regra ocupa a primeira posição no firewall, então um endereço listado é recusado antes que o WAF o pontue. A lista começa com um item sem data de vencimento, `192.0.2.10`. Uma gravação em que todos os itens estão vencidos é recusada com `22019`, então um item sem data mantém a lista gravável depois que todas as detecções expiraram. **Console** Para criar a lista: 1. **Abra a página Network Lists** Acesse [Azion Console](https://console.azion.com/) > **Edge Libraries** > **Network Lists**. 2. **Selecione Network List** 3. **Nomeie a lista** Na seção **General**, insira `siem-blocklist` em **Name**. 4. **Selecione o tipo IP/CIDR** Na seção **Network List Settings**, selecione *IP/CIDR*. Só este tipo aceita uma data de vencimento nos seus itens. 5. **Insira o item permanente** No campo **List**, insira `192.0.2.10 #permanent block`. 6. **Selecione Save** Para criar a regra que a lê: 1. **Abra a aba Rules Engine do firewall** Acesse **Firewalls**, selecione o firewall, vá para a aba **Rules Engine** e selecione **Rule**. 2. **Nomeie a regra** Insira `siem - deny listed addresses`. 3. **Corresponda à lista** Na seção **Criteria**, selecione a variável *Network* e o operador *matches*, e depois selecione `siem-blocklist` em **Select a Network**. 4. **Na seção Behaviors, selecione Deny (403 Forbidden)** 5. **Selecione Save** 6. **Mova a regra para o topo** Na lista do **Rules Engine**, mova `siem - deny listed addresses` para cima da regra que aplica o WAF. **API** Para criar a lista: ```bash curl --request POST \ --url https://api.azion.com/v4/workspace/network_lists \ --header 'Authorization: Token ' \ --header 'Content-Type: application/json' \ --data '{"name":"siem-blocklist","type":"ip_cidr","items":["192.0.2.10 #permanent block"]}' ``` A API responde `201` com um `state` igual a `executed`. Guarde o `id` da lista, que a regra e o playbook usam: ```json {"state":"executed","data":{"id":,"name":"siem-blocklist","type":"ip_cidr","items":["192.0.2.10 #permanent block"],...}} ``` Para criar a regra, envie o ID da lista como um inteiro JSON: ```bash curl --request POST \ --url https://api.azion.com/v4/workspace/firewalls//request_rules \ --header 'Authorization: Token ' \ --header 'Content-Type: application/json' \ --data '{ "name": "siem - deny listed addresses", "active": true, "criteria": [ [{ "variable": "${network}", "conditional": "if", "operator": "is_in_list", "argument": }] ], "behaviors": [{ "type": "deny" }] }' ``` A API responde `202` com um `state` igual a `pending` e a `order` da regra. A API atribui a `order` na ordem de criação, então, em um firewall que já tem a regra de WAF, mova esta regra para cima dela na lista do **Rules Engine** no Azion Console. Todo endereço em `siem-blocklist` recebe `403` assim que a regra se propaga, de 6 a 10 minutos depois de salva. Para proteger várias aplicações, adicione a mesma regra a cada um dos seus firewalls: toda regra lê a mesma lista, então uma gravação bloqueia o endereço em todos eles. --- ## Configure a gravação do playbook na lista O playbook envia duas chamadas para cada detecção: ele lê a lista e depois a grava de volta com o item novo. Um `PATCH` que envia `items` substitui o array inteiro, então um playbook que enviasse só o endereço novo removeria todos os outros itens, inclusive o permanente. Cada item novo carrega duas anotações. A data de vencimento, `--LT` seguido de uma data e hora UTC em segundos inteiros, marca quando o bloqueio termina, e esta página usa 24 horas depois da detecção. O comentário, `#` seguido do ID da detecção, diz a um analista por que o endereço está ali. ```mermaid %%{init: {"layout": "dagre", "themeVariables": {"fontSize": "13px"}, "flowchart": {"nodeSpacing": 12, "rankSpacing": 12, "padding": 6, "wrappingWidth": 70, "minNodeWidth": 40, "useMaxWidth": true}}}%% sequenceDiagram participant SIEM as SIEM participant SOAR as playbook de SOAR participant API as API da Azion participant FW as firewall SIEM->>SOAR: detecção DET-4471 SOAR->>API: GET da lista API-->>SOAR: itens atuais SOAR->>API: PATCH dos itens mais o item novo API-->>SOAR: 200, itens armazenados API->>FW: os itens novos chegam ao tráfego ``` 1. O SIEM gera uma detecção para `198.51.100.23` e inicia o playbook. 2. O playbook lê os itens atuais de `siem-blocklist`. 3. O playbook adiciona `198.51.100.23 --LT #DET-4471` a esses itens e grava o array inteiro de volta. 4. A API responde `200` e armazena os itens. O firewall nega o endereço assim que a alteração chega ao tráfego. O playbook envia a leitura e a gravação que [Atualize uma network list a partir de uma automação](/pt-br/documentacao/guias/seguranca-de-aplicacoes/bots-e-rede/atualizar-network-list-a-partir-de-automacao/#adicione-um-item-a-lista) descreve para adicionar um item, com estes valores: - **Lista**: `siem-blocklist`, que guarda o item permanente `192.0.2.10 #permanent block`. - **Item novo**: o endereço detectado, uma data de vencimento 24 horas depois da detecção e o ID da detecção como comentário. - **Gravação**: para `DET-4471`, com `2030-01-01T00:00:00Z` no lugar do horário da detecção mais 24 horas, o corpo de `PATCH /v4/workspace/network_lists/` é: ```json {"items":["192.0.2.10 #permanent block","198.51.100.23 --LT2030-01-01T00:00:00Z #DET-4471"]} ``` A API responde `200` e armazena os itens exatamente como foram enviados. O playbook valida cada item antes de enviar o array, porque uma gravação recusada nomeia só o primeiro item inválido. O Azion Terraform Provider também gerencia uma network list, como o recurso `azion_network_list`. Para os seus argumentos, consulte [Recursos de segurança](/pt-br/documentacao/devtools/terraform/security/). --- ## Configure o job de expiração Uma data de vencimento nunca remove um item sozinha. A plataforma lê as datas de vencimento só quando os itens de uma lista são gravados: cada gravação descarta os itens já vencidos, e um item cuja data passa depois da gravação continua correspondendo. O job de expiração é essa gravação, enviada de forma agendada. Ele lê os itens e envia os mesmos itens de volta, e a plataforma descarta os expirados. O agendamento define por quanto tempo um item expirado continua bloqueando. Esta página executa o job a cada hora, então um bloqueio termina no máximo uma hora depois da sua data de vencimento. Uma detecção que dispara de novo antes de o job rodar mantém o endereço listado: a gravação do playbook carrega uma nova data de vencimento para ele. O job envia a leitura e a gravação sem alterações que [Atualize uma network list a partir de uma automação](/pt-br/documentacao/guias/seguranca-de-aplicacoes/bots-e-rede/atualizar-network-list-a-partir-de-automacao/#remova-itens-expirados-de-forma-agendada) descreve, com estes valores: - **Lista**: `siem-blocklist`. O item permanente `192.0.2.10 #permanent block` não carrega data de vencimento, então a gravação do job nunca é recusada por ter só itens expirados. - **Agendamento**: a cada hora, pelo agendador da plataforma de SIEM ou SOAR. - **Gravação**: depois da data de vencimento de `DET-4471`, escrita abaixo como ``, o corpo do `PATCH` é: ```json {"items":["192.0.2.10 #permanent block","198.51.100.23 --LT #DET-4471"]} ``` A API responde `200` e armazena só `192.0.2.10 #permanent block`. O endereço volta a receber as respostas da aplicação assim que a alteração chega ao tráfego. --- ## Verifique a configuração Uma alteração nos itens de uma lista chega ao tráfego de 46 a cerca de 100 segundos depois da gravação, e as respostas se alternam até ela se estabilizar. Repita cada requisição até a resposta se manter. - **Uma detecção vira um bloqueio.** Execute o playbook para uma detecção de teste em um endereço que você controla e depois requisite a aplicação a partir desse endereço: ```bash curl -s -o /dev/null -w '%{http_code}\n' https://www.example.com/ ``` O comando imprime `403` em até cerca de 100 segundos depois da gravação do playbook. - **A gravação manteve todos os outros itens.** Leia a lista com o `GET` da gravação do playbook. Os seus `items` guardam o item permanente, toda detecção anterior ainda em vigor e o item novo. - **Um bloqueio expirado termina.** Dê a um item de teste uma data de vencimento alguns minutos à frente, espere ela passar e execute o job de expiração. A gravação do job retorna os itens sem esse item, e o mesmo `curl` a partir desse endereço volta a imprimir o status da aplicação. - **Os eventos chegam ao SIEM.** No Real-Time Events, a fonte de dados *Data Stream* lista cada envio do stream do WAF, e um **Status Code** `200` significa que o endpoint do SIEM aceitou o lote. --- ## Medindo resultados | Métrica | Onde ler | Como é o funcionamento correto | | -------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | | Tempo entre a detecção e o bloqueio | O timestamp da detecção no SIEM, comparado ao primeiro `403` do endereço na fonte de dados HTTP Requests do [Real-Time Events](/pt-br/documentacao/plataforma/real-time-events/fontes-de-dados/#http-requests), lido por **Remote Address** e **Status** | O tempo de execução do playbook mais cerca de 100 segundos de propagação | | Parcela de incidentes mitigados sem passos manuais | O **Last Editor** da lista, o usuário cujo token fez a última gravação, e o histórico de execuções do playbook na plataforma de SOAR | Toda gravação em `siem-blocklist` vem do usuário do playbook, e toda detecção do tipo que bloqueia tem uma execução | --- ## Boas práticas - **Dê um único dono à lista.** Cada gravação substitui o array inteiro e sobrescreve todos os outros editores, então a edição de um analista no Azion Console entre a leitura e a gravação do playbook se perde. Mantenha os bloqueios manuais em uma lista própria, com a sua própria regra. - **Dê ao playbook o seu próprio usuário e token.** **Last Editor** nomeia o usuário cujo token gravou a lista, então as gravações do playbook e as de pessoas ficam separadas, e o token pode ser revogado sem mexer no acesso de ninguém. - **Coloque uma data de vencimento em todo item automatizado.** Um item sem data de vencimento bloqueia até alguém removê-lo, e uma lista que um playbook preenche cresce a cada detecção. A data de vencimento faz cada bloqueio automatizado terminar sozinho, na próxima execução do job de expiração. - **Escreva o ID da detecção no comentário.** O comentário é armazenado com o item e exibido na lista, então um analista que recebe uma reclamação de um cliente bloqueado encontra a detecção por trás dela. - **Nunca grave as listas mantidas pela Azion.** Qualquer gravação em `Azion IP Tor Exit Nodes` é recusada com `22004`. Referencie-a a partir de uma regra própria e mantenha os endereços do playbook em `siem-blocklist`. --- ## Guias deste caso de uso - [Atualize uma network list a partir de uma automação](/pt-br/documentacao/guias/seguranca-de-aplicacoes/bots-e-rede/atualizar-network-list-a-partir-de-automacao.md): Envie a leitura e a gravação que adicionam um item datado a siem-blocklist, e a gravação agendada que descarta os expirados. - [Envie eventos do WAF para um SIEM](/pt-br/documentacao/guias/seguranca-de-aplicacoes/firewall-e-waf/integrar-siems.md): Crie o stream de eventos do WAF que as detecções do SIEM leem, e confirme que o endpoint do SIEM o aceita.