Introdução
Suricata é uma ferramenta de Monitoramento de Segurança de Rede (NSM) que utiliza conjuntos de assinaturas criadas pela comunidade e definidas pelo usuário (também chamadas de regras) para examinar e processar o tráfego de rede. Suricata pode gerar eventos de registro, disparar alertas e bloquear o tráfego quando detecta pacotes suspeitos ou solicitações para qualquer número de diferentes serviços em execução em um servidor.
Por padrão, Suricata funciona como um Sistema de Detecção de Intrusão (IDS) passivo para escanear o tráfego suspeito em um servidor ou rede. Ele irá gerar e registrar alertas para investigação adicional. Também pode ser configurado como um Sistema de Prevenção de Intrusões (IPS) ativo para registrar, alertar e bloquear completamente o tráfego de rede que corresponda a regras específicas.
Você pode implantar Suricata em um host de gateway em uma rede para escanear todo o tráfego de entrada e saída de outros sistemas, ou pode executá-lo localmente em máquinas individuais em qualquer modo.
Neste tutorial, você aprenderá como instalar Suricata e como personalizar algumas de suas configurações padrão no Centos 8 Stream para atender às suas necessidades. Você também aprenderá como baixar conjuntos de assinaturas existentes (geralmente referidos como conjuntos de regras) que Suricata usa para escanear o tráfego de rede. Por fim, aprenderá como testar se Suricata está funcionando corretamente ao detectar solicitações e dados suspeitos em uma resposta.
Pré-requisitos
Dependendo da configuração da sua rede e de como você pretende usar o Suricata, você pode precisar de mais ou menos CPU e RAM para o seu servidor. Geralmente, quanto mais tráfego você planeja inspecionar, mais recursos você deve alocar para o Suricata. Em um ambiente de produção, planeje usar pelo menos 2 CPUs e 4 ou 8GB de RAM para começar. A partir daí, você pode aumentar os recursos de acordo com o desempenho do Suricata e a quantidade de tráfego que precisa processar.
Se você planeja usar o Suricata para proteger o servidor em que ele está sendo executado, você precisará de:
- Um servidor Centos 8 Stream com 2 ou mais CPUs, um usuário não-root com permissões de sudo e um firewall ativado. Para configurar isso, você pode seguir nosso tutorial Configuração Inicial do Servidor com CentOS Linux 8.
Caso contrário, se você planeja usar o Suricata em um host de gateway para monitorar e proteger vários servidores, você precisará garantir que a rede do host esteja configurada corretamente.
Se estiver usando o DigitalOcean, você pode seguir este guia sobre Como Configurar um Droplet como Gateway VPC. Essas instruções devem funcionar para a maioria dos servidores derivados do CentOS, Fedora e outras distribuições baseadas no RedHat.
Passo 1 — Instalando Suricata
Para começar a instalar o Suricata, você precisará adicionar as informações do repositório de software da Open Information Security Foundation (OISF) ao seu sistema CentOS. Você pode usar o comando dnf copr enable
para fazer isso. Você também precisará adicionar o repositório Extra Packages for Enterprise Linux (EPEL).
Para habilitar o subcomando Community Projects (copr
) para a ferramenta de pacotes dnf
, execute o seguinte:
Você será solicitado a instalar algumas dependências adicionais, bem como aceitar a chave GPG para a distribuição Linux CentOS. Pressione y
e ENTER
cada vez para concluir a instalação do pacote copr
.
Em seguida, execute o seguinte comando para adicionar o repositório OISF ao seu sistema e atualizar a lista de pacotes disponíveis:
Pressione y
e ENTER
quando for solicitado a confirmar que deseja adicionar o repositório.
Agora adicione o pacote epel-release
, que disponibilizará alguns pacotes de dependência extras para o Suricata:
Quando solicitado a importar a chave GPG, pressione y
e ENTER
para aceitar.
Agora que você tem os repositórios de software necessários habilitados, você pode instalar o pacote suricata
usando o comando dnf
:
Quando solicitado a adicionar a chave GPG para o repositório OISF, pressione y
e ENTER
. O pacote e suas dependências serão baixados e instalados.
Em seguida, habilite o suricata.service
para que ele seja executado quando o sistema reiniciar. Use o comando systemctl
para habilitá-lo:
Você deve receber uma saída semelhante à seguinte indicando que o serviço está habilitado:
OutputCreated symlink /etc/systemd/system/multi-user.target.wants/suricata.service → /usr/lib/systemd/system/suricata.service.
Antes de avançar para a próxima seção deste tutorial, que explica como configurar o Suricata, pare o serviço usando systemctl
:
Parar o Suricata garante que, ao editar e testar o arquivo de configuração, quaisquer alterações feitas serão validadas e carregadas quando o Suricata iniciar novamente.
Passo 2 — Configurando o Suricata pela Primeira Vez
O pacote Suricata dos repositórios OISF vem com um arquivo de configuração que abrange uma ampla variedade de casos de uso. O modo padrão para o Suricata é o modo IDS, portanto, nenhum tráfego será descartado, apenas registrado. Deixar esse modo definido como padrão é uma boa ideia enquanto você aprende o Suricata. Uma vez que você tenha o Suricata configurado e integrado em seu ambiente, e tenha uma boa ideia dos tipos de tráfego sobre os quais ele o alertará, você pode optar por ativar o modo IPS.
No entanto, a configuração padrão ainda possui algumas configurações que você pode precisar alterar, dependendo do seu ambiente e necessidades.
(Opcional) Habilitando o ID de Fluxo da Comunidade
O Suricata pode incluir um campo de ID da Comunidade em sua saída JSON para facilitar a correspondência de registros de eventos individuais a registros em conjuntos de dados gerados por outras ferramentas.
Se você planeja usar o Suricata com outras ferramentas como Zeek ou Elasticsearch, adicionar o ID da Comunidade agora é uma boa ideia.
Para habilitar a opção, abra o arquivo /etc/suricata/suricata.yaml
usando o vi
ou seu editor preferido:
Encontre a linha 120 que contém # ID de Fluxo da Comunidade
. Se estiver usando o vi
, digite 120gg
para ir diretamente para a linha. Abaixo dessa linha está a chave community-id
. Defina-a como true
para habilitar a configuração:
. . .
# ID de Fluxo da Comunidade
# Adiciona um campo 'community_id' aos registros EVE. Estes são destinados a fornecer
# registros um ID de fluxo previsível que pode ser usado para corresponder registros a
# saída de outras ferramentas como Zeek (Bro).
#
# Recebe uma 'seed' que precisa ser a mesma em sensores e ferramentas
# para tornar o id menos previsível.
# Habilita/desabilita o recurso de ID da comunidade.
community-id: true
. . .
Agora, ao examinar eventos, eles terão um ID como 1:S+3BA2UmrHK0Pk+u3XH78GAFTtQ=
que você pode usar para correlacionar registros em diferentes ferramentas NMS.
Salve e feche o arquivo /etc/suricata/suricata.yaml
. Se estiver usando o vi
, você pode fazer isso com ESC
e depois :x
, e então ENTER
para salvar e sair do arquivo.
Determinando Qual(is) Interface(s) de Rede Usar
Você pode precisar substituir a interface de rede padrão ou interfaces que deseja que o Suricata inspecione o tráfego. O arquivo de configuração fornecido com o pacote OISF Suricata padrão inspeciona o tráfego em um dispositivo chamado eth0
. Se o seu sistema usar uma interface de rede padrão diferente, ou se desejar inspecionar o tráfego em mais de uma interface, será necessário alterar esse valor.
Para determinar o nome do dispositivo da sua interface de rede padrão, você pode usar o comando ip
da seguinte forma:
A bandeira -p
formata a saída para ser mais legível, e a bandeira -j
imprime a saída como JSON.
Você deve receber uma saída como a seguinte:
Output[ {
"dst": "default",
"gateway": "203.0.113.254",
"dev": "eth0",
"protocol": "static",
"metric": 100,
"flags": [ ]
} ]
A linha dev
indica o dispositivo padrão. Neste exemplo de saída, o dispositivo é a interface eth0
destacada. Sua saída pode mostrar um nome de dispositivo como ens...
ou eno...
. Seja qual for o nome, faça uma nota dele.
Agora você pode editar a configuração do Suricata e verificar ou alterar o nome da interface. Abra o arquivo de configuração /etc/suricata/suricata.yaml
usando o vi
ou seu editor preferido:
Role pelo arquivo até encontrar uma linha que contenha af-packet:
por volta da linha 580. Se estiver usando o vi
, também é possível ir diretamente para a linha inserindo 580gg
. Abaixo dessa linha está a interface padrão que o Suricata usará para inspecionar o tráfego. Edite a linha para que corresponda à sua interface, como no exemplo destacado a seguir:
# Suporte a captura de alta velocidade do Linux
af-packet:
- interface: eth0
# Número de threads de recebimento. "auto" usa o número de núcleos
#threads: auto
# clusterid padrão. AF_PACKET balanceará os pacotes com base no fluxo.
cluster-id: 99
. . .
Se você deseja inspecionar o tráfego em interfaces adicionais, pode adicionar mais objetos YAML - interface: eth...
. Por exemplo, para adicionar um dispositivo chamado enp0s1
, role até o final da seção af-packet
, por volta da linha 650. Para adicionar uma nova interface, insira-a antes da seção - interface: default
, como no exemplo destacado a seguir:
# Para configurar o eBPF e o XDP, incluindo bypass, filtro e balanceamento de carga, por favor
# consulte o arquivo doc/userguide/capture-hardware/ebpf-xdp.rst para obter mais informações.
- interface: enp0s1
cluster-id: 98
- interface: default
#threads: auto
#use-mmap: no
#tpacket-v3: yes
Certifique-se de escolher um valor único para cluster-id
para cada objeto - interface
.
Mantenha seu editor aberto e prossiga para a próxima seção onde você configurará a recarregamento de regras ao vivo. Se você não deseja habilitar essa configuração, poderá salvar e fechar o arquivo /etc/suricata/suricata.yaml
. Se você estiver usando vi
, poderá fazê-lo com ESC
, depois :x
e ENTER
para salvar e sair.
Configurando Recarregamento de Regras ao Vivo
O Suricata suporta o recarregamento de regras ao vivo, o que significa que você pode adicionar, remover e editar regras sem precisar reiniciar o processo em execução do Suricata. Para habilitar a opção de recarregamento ao vivo, role até o final do arquivo de configuração e adicione as seguintes linhas:
. . .
detect-engine:
- rule-reload: true
Com essa configuração em vigor, você poderá enviar o sinal do sistema SIGUSR2
para o processo em execução, e o Suricata recarregará quaisquer regras alteradas na memória.
A command like the following will notify the Suricata process to reload its rulesets, without restarting the process:
A parte $(pidof suricata)
do comando invoca um subshell e encontra o ID do processo do daemon Suricata em execução. A parte inicial sudo kill -usr2
do comando utiliza a utilidade kill
para enviar o sinal SIGUSR2
para o ID do processo que é relatado pelo subshell.
Você pode usar este comando sempre que executar suricata-update
ou quando adicionar ou editar suas próprias regras personalizadas.
Salve e feche o arquivo /etc/suricata/suricata.yaml
. Se estiver usando vi
, você pode fazer isso com ESC
, então :x
e ENTER
para confirmar.
Passo 3 — Atualizando Conjuntos de Regras do Suricata
Neste ponto do tutorial, se você iniciasse o Suricata, receberia uma mensagem de aviso como a seguinte nos logs informando que não há regras carregadas:
Output<Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /var/lib/suricata/rules/suricata.rules
Por padrão, o pacote Suricata inclui um conjunto limitado de regras de detecção (no diretório /etc/suricata/rules
), então ligar o Suricata neste momento só detectaria uma quantidade limitada de tráfego ruim.
O Suricata inclui uma ferramenta chamada suricata-update
que pode buscar conjuntos de regras de provedores externos. Execute-o da seguinte forma para baixar um conjunto de regras atualizado para seu servidor Suricata:
Você deve receber uma saída como a seguinte:
Output19/10/2021 -- 19:31:03 - <Info> -- Using data-directory /var/lib/suricata.
19/10/2021 -- 19:31:03 - <Info> -- Using Suricata configuration /etc/suricata/suricata.yaml
19/10/2021 -- 19:31:03 - <Info> -- Using /usr/share/suricata/rules for Suricata provided rules.
. . .
19/10/2021 -- 19:31:03 - <Info> -- No sources configured, will use Emerging Threats Open
19/10/2021 -- 19:31:03 - <Info> -- Fetching https://rules.emergingthreats.net/open/suricata-6.0.3/emerging.rules.tar.gz.
100% - 3062850/3062850
. . .
19/10/2021 -- 19:31:06 - <Info> -- Writing rules to /var/lib/suricata/rules/suricata.rules: total: 31011; enabled: 23649; added: 31011; removed 0; modified: 0
19/10/2021 -- 19:31:07 - <Info> -- Writing /var/lib/suricata/rules/classification.config
19/10/2021 -- 19:31:07 - <Info> -- Testing with suricata -T.
19/10/2021 -- 19:31:32 - <Info> -- Done.
As linhas destacadas indicam que o suricata-update
buscou as regras gratuitas do Emerging Threats ET Open Rules e as salvou no arquivo /var/lib/suricata/rules/suricata.rules
do Suricata. Também indica o número de regras que foram processadas, neste exemplo, 31011 foram adicionadas e dessas 23649 foram habilitadas.
Adicionando Provedores de Conjuntos de Regras
A ferramenta suricata-update
pode buscar regras de uma variedade de provedores de conjuntos de regras gratuitos e comerciais. Alguns conjuntos de regras, como o conjunto ET Open que você já adicionou, estão disponíveis gratuitamente, enquanto outros requerem uma assinatura paga.
Você pode listar o conjunto padrão de provedores de regras usando a flag list-sources
para o suricata-update
assim:
Você receberá uma lista de fontes como a seguinte:
Output. . .
19/10/2021 -- 19:27:34 - <Info> -- Adding all sources
19/10/2021 -- 19:27:34 - <Info> -- Saved /var/lib/suricata/update/cache/index.yaml
Name: et/open
Vendor: Proofpoint
Summary: Emerging Threats Open Ruleset
License: MIT
. . .
Por exemplo, se você quiser incluir o conjunto de regras tgreen/hunting
, você pode habilitá-lo usando o seguinte comando:
Em seguida, execute novamente o suricata-update
e o novo conjunto de regras será adicionado, além das regras existentes do ET Open e quaisquer outras que você tenha baixado.
Passo 4 — Validando a Configuração do Suricata
Agora que você editou o arquivo de configuração do Suricata para incluir o ID da Comunidade opcional, especificou a interface de rede padrão e habilitou o recarregamento de regras ao vivo, é uma boa ideia testar a configuração.
O Suricata possui um modo de teste integrado que verificará o arquivo de configuração e quaisquer regras incluídas quanto à validade. Valide suas alterações da seção anterior usando a bandeira -T
para executar o Suricata no modo de teste. A bandeira -v
imprimirá algumas informações adicionais, e a bandeira -c
indica ao Suricata onde encontrar seu arquivo de configuração:
O teste pode levar algum tempo, dependendo da quantidade de CPU que você alocou para o Suricata e do número de regras que você adicionou, então esteja preparado para esperar um minuto ou dois para que ele seja concluído.
Com o conjunto de regras padrão do ET Open, você deve receber uma saída como a seguinte:
Output21/10/2021 -- 15:00:40 - <Info> - Running suricata under test mode
21/10/2021 -- 15:00:40 - <Notice> - This is Suricata version 6.0.3 RELEASE running in SYSTEM mode
21/10/2021 -- 15:00:40 - <Info> - CPUs/cores online: 2
21/10/2021 -- 15:00:40 - <Info> - fast output device (regular) initialized: fast.log
21/10/2021 -- 15:00:40 - <Info> - eve-log output device (regular) initialized: eve.json
21/10/2021 -- 15:00:40 - <Info> - stats output device (regular) initialized: stats.log
21/10/2021 -- 15:00:46 - <Info> - 1 rule files processed. 23879 rules successfully loaded, 0 rules failed
21/10/2021 -- 15:00:46 - <Info> - Threshold config parsed: 0 rule(s) found
21/10/2021 -- 15:00:47 - <Info> - 23882 signatures processed. 1183 are IP-only rules, 4043 are inspecting packet payload, 18453 inspect application layer, 107 are decoder event only
21/10/2021 -- 15:01:13 - <Notice> - Configuration provided was successfully loaded. Exiting.
21/10/2021 -- 15:01:13 - <Info> - cleaning up signature grouping structure... complete
Se houver um erro em seu arquivo de configuração, então o modo de teste gerará um código de erro específico e uma mensagem que você pode usar para ajudar na solução de problemas. Por exemplo, incluir um arquivo de regras que não existe chamado test.rules
geraria um erro como o seguinte:
Output21/10/2021 -- 15:10:15 - <Info> - Running suricata under test mode
21/10/2021 -- 15:10:15 - <Notice> - This is Suricata version 6.0.3 RELEASE running in SYSTEM mode
21/10/2021 -- 15:10:15 - <Info> - CPUs/cores online: 2
21/10/2021 -- 15:10:15 - <Info> - eve-log output device (regular) initialized: eve.json
21/10/2021 -- 15:10:15 - <Info> - stats output device (regular) initialized: stats.log
21/10/2021 -- 15:10:21 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /var/lib/suricata/rules/test.rules
Com esse erro, você poderia então editar seu arquivo de configuração para incluir o caminho correto, ou corrigir variáveis e opções de configuração inválidas.
Assim que a execução do modo de teste do Suricata for concluída com sucesso, você pode passar para o próximo passo, que é iniciar o Suricata no modo daemon.
Passo 5 — Executando o Suricata
Agora que você tem uma configuração válida do Suricata e um conjunto de regras, você pode iniciar o servidor Suricata. Execute o seguinte comando systemctl
:
Você pode examinar o status do serviço usando o comando systemctl status
:
Você deverá receber uma saída como a seguinte:
Output● suricata.service - Suricata Intrusion Detection Service
Loaded: loaded (/usr/lib/systemd/system/suricata.service; enabled; vendor preset: disabled)
Active: active (running) since Thu 2021-10-21 18:22:56 UTC; 1min 57s ago
Docs: man:suricata(1)
Process: 24588 ExecStartPre=/bin/rm -f /var/run/suricata.pid (code=exited, status=0/SUCCESS)
Main PID: 24590 (Suricata-Main)
Tasks: 1 (limit: 23473)
Memory: 80.2M
CGroup: /system.slice/suricata.service
└─24590 /sbin/suricata -c /etc/suricata/suricata.yaml --pidfile /var/run/suricata.pid -i eth0 --user suricata
Oct 21 18:22:56 suricata systemd[1]: Starting Suricata Intrusion Detection Service..
Oct 21 18:22:56 suricata systemd[1]: Started Suricata Intrusion Detection Service.
. . .
Assim como o comando de modo de teste, o Suricata levará um ou dois minutos para carregar e analisar todas as regras. Você pode usar o comando tail
para observar uma mensagem específica nos registros do Suricata que indica que ele terminou de iniciar:
Você receberá várias linhas de saída, e o terminal pode parecer estar travado enquanto o Suricata carrega. Continue aguardando a saída até receber uma linha como a seguinte:
Output19/10/2021 -- 19:22:39 - <Info> - All AFP capture threads are running.
Esta linha indica que o Suricata está em execução e pronto para inspecionar o tráfego. Você pode sair do comando tail
usando CTRL+C
.
Agora que você verificou que o Suricata está em execução, o próximo passo neste tutorial é verificar se o Suricata detecta uma solicitação para uma URL de teste que está projetada para gerar um alerta.
Passo 6 — Testando Regras do Suricata
O conjunto de regras ET Open que você baixou contém mais de 30.000 regras. Uma explicação completa de como as regras do Suricata funcionam e como construí-las está além do escopo deste tutorial introdutório. Um tutorial subsequente nesta série explicará como as regras funcionam e como construir as suas próprias.
Para os propósitos deste tutorial, testar se o Suricata está detectando tráfego suspeito com a configuração que você gerou é suficiente. O Suricata Quickstart recomenda testar a regra ET Open com o número 2100498
usando o comando curl
.
Execute o seguinte para gerar uma solicitação HTTP, que retornará uma resposta que corresponda à regra de alerta do Suricata:
O comando curl
irá gerar uma resposta como a seguinte:
Outputuid=0(root) gid=0(root) groups=0(root)
Estes dados de resposta de exemplo são projetados para acionar um alerta, fingindo retornar a saída de um comando como id
que pode ser executado em um sistema remoto comprometido via shell web.
Agora você pode verificar os logs do Suricata para um alerta correspondente. Existem dois logs que estão habilitados com a configuração padrão do Suricata. O primeiro está em /var/log/suricata/fast.log
e o segundo é um log legível por máquina em /var/log/suricata/eve.log
.
Examinando /var/log/suricata/fast.log
Para verificar uma entrada de log em /var/log/suricata/fast.log
que corresponde ao seu pedido curl
, use o comando grep
. Usando o identificador de regra 2100498
da documentação de Início Rápido, pesquise por entradas que correspondam a ele usando o seguinte comando:
Se o seu pedido usou IPv6, então você deve receber uma saída como a seguinte, onde 2001:DB8::1
é o endereço IPv6 público do seu sistema:
Output10/21/2021-18:35:54.950106 [**] [1:2100498:7] GPL ATTACK_RESPONSE id check returned root [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 2600:9000:2000:4400:0018:30b3:e400:93a1:80 -> 2001:DB8::1:34628
Se o seu pedido usou IPv4, então seu log deve ter uma mensagem como esta, onde 203.0.113.1
é o endereço IPv4 público do seu sistema:
Output10/21/2021-18:35:57.247239 [**] [1:2100498:7] GPL ATTACK_RESPONSE id check returned root [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 204.246.178.81:80 -> 203.0.113.1:36364
Observe o valor 2100498
destacado na saída, que é o ID de Assinatura (sid
) que o Suricata usa para identificar uma regra.
Examinando /var/log/suricata/eve.log
O Suricata também registra eventos no /var/log/suricata/eve.log
(apelidado de log EVE) usando JSON para formatar as entradas.
A documentação do Suricata recomenda o uso da utilidade jq
para ler e filtrar as entradas neste arquivo. Instale o jq
se você não o tiver em seu sistema usando o seguinte comando dnf
:
Depois de ter o jq
instalado, você pode filtrar os eventos no registro EVE pesquisando pela assinatura 2100498
com o seguinte comando:
O comando examina cada entrada JSON e imprime qualquer uma que tenha um objeto alert
, com uma chave signature_id
que corresponda ao valor 2100498
que você está procurando. A saída será semelhante ao seguinte:
Output{
"timestamp": "2021-10-21T19:42:47.368856+0000",
"flow_id": 775889108832281,
"in_iface": "eth0",
"event_type": "alert",
"src_ip": "203.0.113.1",
"src_port": 80,
"dest_ip": "147.182.148.159",
"dest_port": 38920,
"proto": "TCP",
"community_id": "1:vuSfAFyy7oUq0LQC5+KNTBSuPxg=",
"alert": {
"action": "allowed",
"gid": 1,
"signature_id": 2100498,
"rev": 7,
"signature": "GPL ATTACK_RESPONSE id check returned root",
"category": "Potentially Bad Traffic",
. . .
}
Observe a linha destacada "signature_id": 2100498,
, que é a chave que o jq
está procurando. Observe também a linha destacada "community_id": "1:vuSfAFyy7oUq0LQC5+KNTBSuPxg=",
na saída JSON. Esta chave é o Identificador de Fluxo Comunitário gerado que você habilitou no arquivo de configuração do Suricata.
Cada alerta irá gerar um Identificador de Fluxo Comunitário único. Outras ferramentas de NMS também podem gerar o mesmo identificador para permitir a correlação de um alerta do Suricata com a saída de outras ferramentas.
A matching log entry in either log file means that Suricata successfully inspected the network traffic, matched it against a detection rule, and generated an alert for subsequent analysis or logging. A future tutorial in this series will explore how to send Suricata alerts to a Security Information Event Management (SIEM) system for further processing.
Passo 7 — Lidando com Alertas do Suricata
Depois de configurar e testar os alertas, você pode escolher como deseja lidar com eles. Para alguns casos de uso, o registro de alertas para fins de auditoria pode ser suficiente; ou você pode preferir adotar uma abordagem mais ativa para bloquear o tráfego de sistemas que geram alertas repetidos.
Se você deseja bloquear o tráfego com base nos alertas gerados pelo Suricata, uma abordagem é usar entradas do registro EVE e, em seguida, adicionar regras de firewall para restringir o acesso ao seu sistema ou sistemas. Você pode usar a ferramenta jq
para extrair campos específicos de um alerta e, em seguida, adicionar regras UFW ou IPtables para bloquear solicitações.
Novamente, este exemplo é um cenário hipotético usando dados de solicitação e resposta deliberadamente elaborados. Seu conhecimento dos sistemas e protocolos aos quais seu ambiente deve poder acessar é essencial para determinar qual tráfego é legítimo e qual pode ser bloqueado.
Conclusão
Neste tutorial, você instalou o Suricata nos repositórios de software da OISF. Instalar o Suricata desta forma garante que você possa receber atualizações sempre que uma nova versão do Suricata for lançada. Após instalar o Suricata, você editou a configuração padrão para adicionar um ID de Fluxo da Comunidade para uso com outras ferramentas de segurança. Você também habilitou a recarga de regras ao vivo e baixou um conjunto inicial de regras.
Uma vez validada a configuração do Suricata, você iniciou o processo e gerou algum tráfego HTTP de teste. Você verificou que o Suricata conseguiu detectar tráfego suspeito examinando ambos os logs padrão para garantir que eles continham um alerta correspondente à regra que você estava testando.
Para mais informações sobre o Suricata, visite o Site Oficial do Suricata. Para mais detalhes sobre quaisquer das opções de configuração que você configurou neste tutorial, consulte o Guia do Usuário do Suricata.
Agora que você tem o Suricata instalado e configurado, você pode continuar para o próximo tutorial desta série Entendendo as Assinaturas do Suricata, onde você explorará como escrever suas próprias regras personalizadas do Suricata. Você aprenderá sobre diferentes maneiras de criar alertas, ou até mesmo como descartar o tráfego completamente, com base em critérios como pacotes TCP/IP inválidos, o conteúdo de consultas DNS, solicitações e respostas HTTP, e até mesmo apertos de mão TLS.
Source:
https://www.digitalocean.com/community/tutorials/how-to-install-suricata-on-centos-8-stream