Arquivos Segurança - Marcius Costa

Integrando o AbuseIPDB ao Wazuh com cache de informações

marcius — Tue, 27 Feb 2024 19:19:09 +0000

O cenário é o seguinte:

Debian 12.4 com kernel 6.1.0-18-amd64 virtualizado em VirtualBox 6.1.50
Wazuh versão 4.7.2 (Manager, Indexer e Dashboard no mesmo servidor)

..::| Principais características dessa integração

Essa integração é diferente da que está no blog do Wazuh (link).

Evita realizar múltiplas consultas seguidas do mesmo IP em um curto intervalo de tempo, isso ajudará a prevenir que o limite diário de consultas seja atingido prematuramente.
Faz cache local das consultas, salvando-as em um banco da dados SQLite 3.
Informações dos IPs salvos em cache expiram após um tempo configurável, obrigando a uma nova consulta no API do AbuseIPDB após expirar.
Tem gerenciador próprio de chaves de API, podendo usar mais de uma.
Quando uma chave de API tem seu limite diário excedido, evita usá-la novamente e tentará outra, caso você tenha cadastrado mais de uma.
Volta a usar uma chave de API, que excedeu o limite diário de uso, após a próxima meia-noite (UTC).
Baixa uma blacklist do AbuseIPDB.
Verifica na blacklist se já existe o IP a ser pesquisado antes de consultá-lo na API do AbuseIPDB (essa verificação na blacklist tem que ser ativada).
No alerta do AbuseIPDB, várias informações do alerta original são exibidas para facilitar a análise.
Procura por IPv4 ou IPv6 em vários campos possíveis, não apenas o “srcip”.
Possibilidade de adicionar mais campos do alerta onde é possível ter um IP público.
Não faz consultas de IPs que não sejam públicos.

..::| Pré-requisitos

Ter o Python 3 instalado. Normalmente ele vem com o Wazuh e fica em /var/ossec/framework/python/bin/python3. Se precisar alterar o caminho do executável “python3“, altere o valor da variável “PYTHON_EXEC” do arquivo “custom-abuseipdb” e o shebang do “custom-abuseipdb.py“.
Pacotes do Python necessários: sys, json, time, os, fcntl, re, random, datetime, traceback, subprocess, requests, sqlite3 e ipaddress.

..::| Instalação

Faça o download do script principal de integração:

sudo wget https://raw.githubusercontent.com/marciuscosta/abuseipdb-wazuh-integration/main/custom-abuseipdb.py -O /var/ossec/integrations/custom-abuseipdb.py

Agora do script de facilitação de uso:

sudo wget https://raw.githubusercontent.com/marciuscosta/abuseipdb-wazuh-integration/main/custom-abuseipdb -O /var/ossec/integrations/custom-abuseipdb

Esse script só irá facilitar o uso do “custom-abuseipdb.py” na hora de administrar chaves de API e baixar blacklist, mais adiante.

No Wazuh, para um script customizado de integração ser aceito pelo sistema, o seu nome de arquivo precisa começar com “custom-” e ele deve estar dentro do diretório /var/ossec/integrations/.

Altere suas permissões com os seguintes comandos:

sudo chmod 750 /var/ossec/integrations/custom-abuseipdb
sudo chown root:wazuh /var/ossec/integrations/custom-abuseipdb
sudo chmod 750 /var/ossec/integrations/custom-abuseipdb.py
sudo chown root:wazuh /var/ossec/integrations/custom-abuseipdb.py

Para configurar a integração desse script Python no Wazuh, antes de tudo você precisará definir quais regras, ou grupo de regras, serão usadas para chamar essa integração.

No exemplo que citarei abaixo, irei usar um grupo de regras específico para essa integração. Ou seja, sempre que uma regra estiver nesse grupo de regras, que chamarei de “abuseipdb_integration“, e ela for usada em algum alerta, o conteúdo completo desse alerta será enviado para o “custom-abuseipdb.py” processar. O resultado do processamento desse script será outro alerta, que veremos mais adiante.

Abra o /var/ossec/etc/ossec.conf e inclua essa integração abaixo dentro de “ … “:


    custom-abuseipdb.py
    abuseipdb_integration,
    json



    /var/ossec/logs/integrations.log
    syslog

Note que nessa integração, diferente da que foi publicada no blog do Wazuh, não há os campos “” e ““, pois a URL da API do AbuseIPDB e a(s) chave(s) de API que você irá usar não ficarão aqui, mas dentro do próprio script (no caso da URL da API) e no banco de dados de cache de informações dessa integração (no caso da(s) chave(s) de API), que veremos mais adiante em detalhes. Toda a administração de chave(s) de API será feita pelo script “custom-abuseipdb.py“.

Você também poderá citar regras específicas para integração, ao invés do grupo de regras. Basta tirar o “abuseipdb_integration,” e colocar “ID_DA_REGRA” com as IDs separadas por vírgula. Ambos não funcionam juntos na mesma integração, a menos que um ID citado em “” faça parte de um grupo de regras que está citado em “” também na mesma integração.

O Wazuh irá monitorar o log /var/ossec/logs/integrations.log, que é o local onde ficam salvos os resultados da integração. Se quiser, você poderá alterar esse local, abrindo o “custom-abuseipdb.py” e informando o novo arquivo de log na variável “log_file“. Porém, lembre-se de alterar a “” das configurações de integração no ossec.conf (que fizemos acima) para esse novo local.

Antes de criarmos a primeira regra do novo grupo “abuseipdb_integration“, vamos adicionar a chave API do AbuseIPDB que temos.

Caso você não tenha uma chave de API ainda, precisará criar uma agora. Primeiro, crie uma conta (caso já não tenha) no https://www.abuseipdb.com/pricing que é muito simples. Quando você já tiver a sua conta, acesse-a e vá no menu com o nome que você deu a essa conta, que fica no canto superior direito da tela, clique nele e depois em “Account“. Na página inicial que irá abrir, clique na aba “API” e depois em “Create Key” (caso você já não tenha uma chave API):

Dê um nome para a sua chave, depois clique em “Create“. Copie a chave que irá aparecer no campo “Key” e a salve em local seguro.

Perceba que o limite de “checks” por dia é de 1000 na conta gratuíta. Se você tiver 2 ou mais contas no AbuseIPDB, por exemplo, poderá criar 2 ou mais chaves de API e, com isso, terá um limite diário de 2000 (ou mais) consultas a essa API. O script de integração fará a administração automaticamente dessas chaves. Ou seja, quando uma exceder o limite diário, ele marcará ela para não ser usada até a próxima meia-noite (UTC – o que dá 21:00 no horário de Brasília), passando a usar a outra chave de API disponível. Na próxima meia-noite (UTC) as contagens de uso dessas chaves serão zeradas pelo próprio AbuseIPDB. Não tenho informações sobre se há limites de consultas por um IP de origem, mas em meus testes eu consegui fazer 2 mil consultas com 2 chaves de API diferentes, usando um mesmo IP de origem, e não fui bloqueado e nem a minha conta foi invalidada de alguma forma.

Adicione a chave de API criada ao banco de dados de cache local do script, com o seguinte comando:

sudo /var/ossec/integrations/custom-abuseipdb apikey add COLE_SUA_CHAVE_AQUI

Para listar as chaves de API salvas no banco de dados de cache local, digite o comando:

sudo /var/ossec/integrations/custom-abuseipdb apikey list

Perceba que na direita há o campo “Usable after“. Significa que essa chave de API estará apta para uso após esse dia e horário (com base no relógio desse servidor). Se a data estiver a frente do momento atual, significa que ela excedeu o limite diário de consultas na API, e poderá ser usada novamente somente após a próxima meia-noite do fuso horário UTC, o que será às 21:00 no fuso-horário de Brasília. No entanto, para evitar problemas de dessincronização do horário atual do servidor com o de Brasília, coloquei 2 minutos além da meia-noite (que, no horário de Brasília, é 21:02).

Se a chave de API for considerada inválida pelo AbuseIPDB, o campo “Usable after” estará com o valor “INVALID” logo após o script de integração tentar usá-la. Em nenhum momento essa chave será usada novamente na integração.

Para remover uma chave de API do banco de dados de cache local, use o comando (mas não a remova agora pois iremos usá-la nos testes mais adiante):

sudo /var/ossec/integrations/custom-abuseipdb apikey remove CHAVE_API_A_SER_EXCLUÍDA

Agora vamos instalar os decoders que irão extrair as informações oriundas da API do AbuseIPDB, possibilitando criar regras com base nessas informações. Execute essa linha de comandos:

sudo wget https://raw.githubusercontent.com/marciuscosta/abuseipdb-wazuh-integration/main/1600-abuseipdb-integration_decoders.xml -O /var/ossec/etc/decoders/1600-abuseipdb-integration_decoders.xml && sudo chmod 660 /var/ossec/etc/decoders/1600-abuseipdb-integration_decoders.xml && sudo chown wazuh: /var/ossec/etc/decoders/1600-abuseipdb-integration_decoders.xml

Agora vamos criar algumas regras que irão gerar alertas com base nos resultados da integração com o AbuseIPDB. Para ficar organizado, vamos criar o arquivo /var/ossec/etc/rules/1600-abuseipdb-integration_rules.xml onde ficarão essas regras, com o seguinte conteúdo:



    
            abuseipdb
            AbuseIPDB: Integration message.
    


    
            110000
            \d+
            AbuseIPDB: Informations about IP $(srcip).
    

    
    
            110001
            ^((7|8|9)\d|100)
            AbuseIPDB: IP $(srcip) have $(abuseipdb.ip.score) confidence score.
    

    
            110000
            \.+
            AbuseIPDB: Integration error message.
    

    
            110003
            All API key\(s\) stored in local cache database has been exceeded daily limit or invalid
            AbuseIPDB: All saved API key(s) are invalid or have exceeded the daily limit.

Ajuste as permissões desse arquivo:

sudo chmod 660 /var/ossec/etc/rules/1600-abuseipdb-integration_rules.xml && sudo chown wazuh: /var/ossec/etc/rules/1600-abuseipdb-integration_rules.xml

Agora vamos criar algumas regras que irão chamar essa integração.

Apesar do script conseguir identificar um IP público, e com isso ele evita fazer pesquisas na API do AbuseIPDB quando não é um IP público, é bom evitar que esse script de integração seja executado em situações que não há necessidade de fazer consulta de um IP através dessa integração. Vamos criar regras que filtrem os IPs, identificando apenas os públicos. Isso evitará consumo desnecessário de recursos de processamento do servidor.

Vou usar o arquivo /var/ossec/etc/rules/local_rules.xml para criar algumas regras de exemplo. Logo abaixo da regra 100001, insira:

  10\.\d+\.\d+\.\d+|192\.168\.|172.(1[6-9]|2[0-9]|3[0-1])\.\d+\.\d+|127\.\d+\.\d+\.\d+|169.254.\d+\.\d+|244\.\d+\.\d+\.\d+|0{0,3}(|:){0,6}0{0,3}(::|:)0{0,3}1|fe8(0|):\S+|fc(00|0|):\S+|fd(00|0|):\S+

  
    5760
    (?i)Failed password for \S+ from $filter_non-public_ip port \d+
    sshd: Authentication failed from a public IP address $(srcip).
    authentication_failed,authentication_success,pci_dss_10.2.4,pci_dss_10.2.5,abuseipdb_integration,
  

  
    5715
    (?i)Accepted password for \S+ from $filter_non-public_ip port \d+
    sshd: Authentication succeeded from a public IP address $(srcip).
    authentication_failed,authentication_success,pci_dss_10.2.4,pci_dss_10.2.5,abuseipdb_integration,

Observe que as duas regras estão no grupo “abuseipdb_integration“. Então, quando usadas em um alerta, chamará a integração “custom-abuseipdb.py“, que procurará informações desse IP localmente no banco de dados de cache dessa integração e também na blacklist (se habilitada – veremos mais adiante como ela funcionará). Se as informações sobre o IP do alerta não forem encontradas localmente, ou se as suas informações em cache estiverem muito antigas (esse tempo de expiração de informação no cache é configurável), fará uma consulta na API do AbuseIPDB e o seu resultado ficará salvo no banco de dados de cache da integração para evitar consultas repetidas do mesmo IP logo após a primeira, economizando “checks” diários da API.

Vamos carregar essas novas regras, decoders e ativar a integração reiniciando o Wazuh Manager.

sudo /var/ossec/bin/wazuh-control restart

..::| Primeiros testes

Vou criar um arquivo de log para inserir eventos de autenticação de SSH, porém usando IPs públicos, justamente para chamar a integração.

Então vou criar o arquivo de log /var/log/testes.log primeiro e ajustarei suas permissões:

sudo touch /var/log/testes.log && sudo chmod 662 /var/log/testes.log

Agora vamos configurar o seu monitoramento no /var/ossec/etc/ossec.conf dentro da seção “ … ” dessa forma:

    
        /var/log/testes.log
        syslog

Para ativar o monitoramento desse log de testes, reiniciamos o Wazuh Manager:

sudo /var/ossec/bin/wazuh-control restart

Agora vamos inserir um evento nesse testes.log, porém com IP público:

sudo echo '2024-02-25T15:28:09.658271-03:00 srv-wazuh sshd[64497]: Failed password for root from 159.223.85.11 port 57414 ssh2' >> /var/log/testes.log

Agora, se tudo deu certo, aparecerá esse evento no Wazuh Dashboard, e outro alerta do AbuseIPDB, fornecendo informações sobre o IP de origem desse evento teste.

Veja como ficaram as informações do alerta gerado pela integração:

Observe o campo “data.abuseipdb.alert.ID“. Nele há o ID do alerta que chamou essa integração, que no caso foi a falha de autenticação SSH. Podemos buscar o alerta original filtrando por essa ID, dessa forma:

..::| Usando a blacklist

É possível usar esse script de integração para baixar e usar uma blacklist do AbuseIPDB. Na conta gratuíta, essa blacklist vem limitada a 10 mil IPs e pode ser baixada até 5 vezes no mesmo dia.

Por padrão, o uso da blacklist vem desabilitado no script de integração. Para habilitar, edite o arquivo “custom-abuseipdb.py” e altere o valor da variável “blacklist_enabled” para “True“.

Ao ativar o uso de blacklist na integração, os IPs a serem consultados serão pesquisados primeiro no banco de dados de cache local e, se não encontrado, a pesquisa será feita na blacklist, que será baixada automaticamente caso não exista localmente.

Se quiser baixá-la manualmente antes, execute esse comando:

sudo /var/ossec/integrations/custom-abuseipdb blacklist

Somente se o IP a ser consultado não estiver no banco de dados de cache local e na blacklist é que ele será consultado diretamente na API do AbuseIPDB.

No entanto, as informações sobre um IP na blacklist são limitadas apenas aos campos “IP“, “Country“, “Score” e “Last Reported“. Como são menos informações do que as que são provenientes da API, por esse motivo o script irá procurar primeiro no banco de dados de cache local.

Recomendo colocar para baixá-la automaticamente 1 vez ao dia. Por exemplo, você pode colocar o script para baixar a blacklist todos os dias a meia-noite, inserindo a seguinte linha no seu crontab (coloque no usuário root por causa das permissões de execução):

0   0   *   *   *   /var/ossec/integrations/custom-abuseipdb blacklist

..::| Customizações

Você poderá alterar várias coisas nesse script. Ao abrir o “custom-abuseipdb.py” você observará a seção “Global variables definitions“, onde é possível alterar várias coisas, entre elas:

“ip_fields” = É uma lista com os nomes dos campos, do alerta que o Wazuh envia para a integração, onde geralmente estão os IPs. Você pode adicionar mais campos apenas alimentando a lista, colocando entre aspas simples separando por vírgula. Os campos devem estar dentro da chave “data” do JSON do alerta, ou em alguma das suas possíveis subchaves. O script pegará todas as informações de todos os campos dessa lista que ele encontrar no alerta, não apenas o primeiro que encontrar.
“abuseipdb_local_cache_file” = Local do arquivo com o banco de dados de cache das informações obtidas de consultas a API do AbuseIPDB. Nesse arquivo também há as chaves de API salvas para uso do próprio script.
“log_file” = Local onde ficarão salvos os eventos provenientes da integração. Aqui ficarão todas as informações obtidas a respeito do IP pesquisado, e também informações sobre o alerta original, ou seja, o que chamou a integração inicialmente. Sobre o alerta original, foram excluídos os campos “full_log” e “previous_output” para evitar loop de decodificação pelo Wazuh. Aqui também ficarão outras mensagens a respeito da execução do script, como por exemplo algum erro ou informação importante.
“blacklist_enabled” = Se estiver como “True“, verificará na blacklist se a informação a respeito do IP pesquisado é encontrado. Se ainda não foi feito o download da blacklist, o script fará automaticamente no primeiro uso e somente dessa vez. Por isso é importante atualizar diariamente a blacklist, colocando na cron (como mencionei anteriormente). A intenção é evitar fazer pesquisas na API. Se estiver como “False“, a blacklist não será usada pela integração e nem será feito o download automaticamente no primeiro uso.
“blacklist_file” = Local onde ficará salva a blacklist ao ser baixada pelo script.
“confidenceMinimum” = É o valor mínimo de scores dos IPs que farão parte da blacklist. Em contas gratuítas, é recomendado não alterar isso.
“ip_expiration_time” = Tempo de armazenamento das informações de um IP no banco de dados de cache local. Esse valor deverá ser configurado em segundos. O valor padrão é de 86400, ou seja, 24 horas. Nesse caso, se um IP tiver sido inserido no banco de dados de cache local há mais de 24 horas, o script atualizará essa informação nesse banco de dados fazendo uma consulta a API do AbuseIPDB assim que esse IP aparecer em algum alerta que chamará a integração novamente.

..::| Conclusões

Com essa integração, informações muito importantes a respeito de um IP ficarão fáceis de serem consultadas. Não haverá a necessidade de pesquisar cada IP manualmente quando ele for um suspeito.

Além disso, fazer regras com base no score do IP ficou muito fácil. Como mostrei no exemplo da regra 110002, onde um alerta será gerado com level 12 quando um IP consultado no AbuseIPDB tiver um score igual ou maior que 70. Você também poderá criar um active-response para bloquear um IP com base nesse score. Podendo, por exemplo, criar uma regra onde, se o IP consultado tiver 100 de confidence score, ativará o active-response para bloqueá-lo em seus firewalls de borda de rede. Nesse exemplo, seria praticamente impossível um IP com 100 de score não ser malicioso, então as chances de um bloqueio com base num alerta falso-positivo serão praticamente nulas.

Agora você também poderá fazer regras com base em outras informações. Por exemplo, quando o IP for de um determinado país, você poderá criar uma regra com base nessa informação, assim como em outras informações como de qual ISP é esse IP, quantos registros de atos suspeitos ele tem, se ele pertence a rede TOR, se está em uma whitelist (para evitar falsos-positivos), etc.

Uma recomendação: configure a rotação do log /var/ossec/logs/integrations.log com o logrotate do Linux ou similar, pois o Wazuh não rotaciona esse log automaticamente e ele pode ficar muito grande, dependendo da sua infra.

Com certeza as informações passadas por essa integração ajudará bastante na tomada de decisões e na estratégia de segurança da sua empresa.

Fontes:

https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/integration.html
https://wazuh.com/blog/detecting-known-bad-actors-with-wazuh-and-abuseipdb/

O post Integrando o AbuseIPDB ao Wazuh com cache de informações apareceu primeiro em Marcius Costa.

Port Knocking no pfSense usando Wazuh

marcius — Thu, 31 Mar 2022 18:31:33 +0000

O cenário é o seguinte:

Debian Bullseye versão 5.10.84-1 com wazuh-manager 4.2.6-1 e elasticsearch, kibana e filebeat nas versões 7.14.2
pfSense 2.6.0-RELEASE
Ambos os servidores acima foram virtualizados em VirtualBox 6.1.32 r149290 em Arch Linux 5.16.13-arch1-1
O artigo parte do princípio que o wazuh-manager, wazuh-agent e o pfSense já estejam instalados, configurados e funcionais, como descrito acima.
IP do servidor com wazuh-manager: 10.0.2.201/24
IP do servidor com pfSense: 10.0.2.200/24 (LAN) e 10.0.0.200/24 (WAN)

..::| Objetivo

A técnica de Port Knocking consiste em estabelecer 3 ou mais portas aleatórias que, se “tocadas” (ou seja, se “brevemente conectadas”) por um IP na sequência correta, fará com que um script seja executado para liberar outra porta para o IP de origem desses toques. Mais informações sobre essa técnica você encontra aqui.

Nesse artigo a intenção é liberar o acesso ao pfSense, na porta “wan” dele, somente para um específico IP de origem quando esse conseguir tocar em 3 portas configuradas como “combinação de portas para liberação de conexão”, e na sequência correta. Aqui descreverei a liberação das portas 80/TCP e 22/TCP, porém só uma delas poderá ser liberada para um IP de origem enquanto não expirar essa liberação.

Essa liberação externa para acessar o pfSense possibilitará o administrador de redes a configurar remotamente o gateway de uma LAN, pois possibilitará acesso tanto via SSH quanto ao webadmin do pfSense. Como essas portas serão liberadas somente se o Port Knocking for acertado, evita-se diversos tipos de ataques a esse gateway, como o de força bruta, por exemplo. No caso desse artigo utilizei a porta 80, porém é sempre recomendado ativar o HTTPS do pfSense e desativar o acesso HTTP, para maior segurança ainda mais quando se está acessando-o da internet.

..::| Enviando registros ao wazuh-manager

Caso não tenha o acesso SSH ao servidor do pfSense habilitado, faça-o indo no menu System -> Advanced -> marque a opção “Enable Secure Shell” e depois salve.

Configure o agente do Wazuh no pfSense para ler e encaminhar o conteúdo do log /var/log/filter.log. Abra o arquivo /var/ossec/etc/ossec.conf no pfSense e, depois do último , adicione:


 syslog
 /var/log/filter.log

Reinicie o agent:

/usr/local/etc/rc.d/wazuh-agent restart

..::| Script portknocking.sh

Esse script será o responsável por verificar a sequência de portas tocadas, criar a regra de firewall para liberar acesso a porta solicitada caso a sequência de toques esteja correta, e também para excluir essa regra após um período pré-determinado a ser configurado no active-response do wazuh-manager.

Crie o arquivo /var/ossec/active-response/bin/portknocking.sh com o seguinte conteúdo:

#!/bin/sh
# Script para liberar porta atraves da tecnica port knocking
# Expect: srcip
# Author: Marcius da C. Silveira
# Last modified: Apr 1, 2022
# Publicado: https://marcius.pro/


ACAO=$1
USUARIO=$2
IP=$3
REGRA=$5                                # Regra no wazuh referente a esse port knocking especifico
INTWAN=`echo $9 | cut -d ',' -f1`       # Nome da interface de rede da porta wan que sera acessada externamente para liberacao da ${PORT} configurada abaixo
TABWAN=`echo $9 | cut -d ',' -f2`       # Nome que o pfsense da a interface de rede da porta wan configurada em ${INTWAN}
PROTO=`echo $9 | cut -d ',' -f3`        # Protocolo que sera liberado apos a sequencia de portas serem tocadas
PORT=`echo $9 | cut -d ',' -f4`         # Porta que sera liberada no port knocking
TIMEOUT=`echo $9 | cut -d ',' -f5`      # Tempo de espera entre o toque na primeira porta do port knocking e a ultima da sequencia, se passar desse valor em segundos a operacao nao se realizara
EXTRAIGNOREPORTS=`echo $9 | cut -d ',' -f6 `            # Portas a serem ignoradas tambem
ARLOG=/var/ossec/logs/active-responses.log

# logando as atividades desse script
echo "`date` $0 $1 $2 $3 $4 $5 $9" >> ${ARLOG}

# Adicionar ou remover IP
# Adicionando
if [ ${ACAO} == "add" ]; then

        # Separando as entradas no log de filtragem do pfSense referente ao IP que esta acessando esse sistema
        LOGFILTERORIGINAL=/var/log/filter.log
        LOGFILTER=/tmp/conexoes_${IP}_${PORT}_${PROTO}
        cat ${LOGFILTERORIGINAL} | grep ","${IP}"," > ${LOGFILTER}

        # Se foram encontradas conexoes desse IP no log de filtragem, executa esse script
        if [ `wc -l ${LOGFILTER} | awk '{print $1}'` -gt 0 ]; then

                # Portas do port knocking, na sequencia que devem ser tocadas
                PORTASK="`/usr/local/bin/xmllint --xpath "pfsense/filter/rule[starts-with(descr, 'Port Knocking ${REGRA}') and interface = '${TABWAN}']" /conf/config.xml | grep "" | grep -v ^$ | cut -d ">" -f 2 | cut -d "<" -f1 | tr "\n" "|" | sed 's/.$//'`"

                # Portas que serao ignoradas na contagem, tiradas das regras na tab ${TABWAN}.
                # A intencao aqui e evitar que conexoes legitimas sejam consideradas erros de sequencia de toque no port knocking desse script.
                IGNOREPORTS="`/usr/local/bin/xmllint --xpath "pfsense/filter/rule[interface = '${TABWAN}']/destination/port" /conf/config.xml | cut -d ">" -f2 | cut -d "<" -f1 | tr "\n" "|" | sed 's/.$//'`"

                # Removendo as portas do port knocking das portas encontradas na tab ${TABWAN} caso haja outras
                QTDIGNOREPORTS=`echo $IGNOREPORTS | tr "|" " " | wc -w  | sed 's/ //g'`
                QTDPORTASK=`echo $PORTASK | tr "|" " " | wc -w | sed 's/ //g'`
                if [ ${QTDIGNOREPORTS} != ${QTDPORTASK} ]; then
                        while [ ${QTDIGNOREPORTS} != 0 ]
                        do
                                QTDPRTSK=${QTDPORTASK}
                                while [ ${QTDPRTSK} != 0 ]
                                do
                                        IPORT=`echo $IGNOREPORTS | cut -d "|" -f${QTDIGNOREPORTS}`
                                        KPORT=`echo $PORTASK | cut -d "|" -f${QTDPRTSK}`
                                        if [ ! -z ${IPORT} ]; then
                                                if [ ${IPORT} = ${KPORT} ]; then
                                                        IGNOREPORTS=`echo $IGNOREPORTS | sed 's/^/|/' | sed 's/$/|/' | sed "s/|${IPORT}|/|/" | sed 's/|$//' | sed 's/||/|/' | sed 's/^|//'`
                                                fi
                                        fi
                                        QTDPRTSK=$((QTDPRTSK-1))
                                done
                                QTDIGNOREPORTS=$((QTDIGNOREPORTS-1))
                        done
                fi

                # Adicionando a porta que sera aberta pelo port knocking e as ${EXTRAIGNOREPORTS} a variavel de portas a serem ignoradas
                QTDEXTRAIGNOREPORTS=`echo ${EXTRAIGNOREPORTS} | tr "|" " " | wc -w | sed 's/ //g'`
                while [ ${QTDEXTRAIGNOREPORTS} != 0 ]; do
                        EIPORT=`echo ${EXTRAIGNOREPORTS} | cut -d "|" -f${QTDEXTRAIGNOREPORTS}`
                                if [ ${EIPORT} == ${PORT} ]; then
                                        EXTRAIGNOREPORTS=`echo ${EXTRAIGNOREPORTS} | sed "s/${EIPORT}//"`
                                fi
                        QTDEXTRAIGNOREPORTS=$((QTDEXTRAIGNOREPORTS-1))
                done
                if [ ${QTDIGNOREPORTS} != ${QTDPORTASK} ]; then
                        IGNOREPORTS=`echo -n ${IGNOREPORTS} | sed 's/^|//' ; echo "|"${PORT}"|"${EXTRAIGNOREPORTS} | sed 's/||/|/' | sed 's/|$//'`
                else
                        IGNOREPORTS=`echo -n ${IGNOREPORTS} | echo ${PORT}"|"${EXTRAIGNOREPORTS} | sed 's/||/|/' | sed 's/|$//'`
                fi

                # Coletando informacoes do registro mais recente de conexao na primeira porta da sequencia do port knocking
                PRIMEIRAPORTAK=`echo ${PORTASK} | awk -F "|" '{print $1}'`
                REGPRIMEIRAPORTAK=`cat $LOGFILTER | grep -n ${IP} | grep ",${PRIMEIRAPORTAK}," | tail -1 | sed 's/:/ /' | cut -d " " -f1-4`
                LINHAPRIMEIRAPORTAK=`echo ${REGPRIMEIRAPORTAK} | awk '{print $1}'`

                # Analisando se o tempo entre o toque na primeira porta da sequencia e a ultima esta dentro de ${TIMEOUT} segundos
                TSATUAL=`date +%s`
                TSTIMEOUT=`echo "${TSATUAL} - ${TIMEOUT}" | bc`
                TZANO=`date +%Z" "%Y`
                DATAPRIMEIRAPORTAK=`echo ${REGPRIMEIRAPORTAK} | awk -v tzano="${TZANO}" '{print $2" "$3" "$4" "tzano}'`
                TSPRIMEIRAPORTAK=`echo ${DATAPRIMEIRAPORTAK} | awk '{system("date -jf \"%a %b %d %t %z %Y\" \"Mon "$1" "$2" "$3" "$4" "$5"\" \"+%s\"")}'`
                # Diferenca em segundos do momento em que esse script esta rodando e o toque na primeira porta da sequencia
                # Lembrando que esse script so sera executado quando a ultima porta da sequencia do port knocking for tocada
                DIFTS=`echo ${TSATUAL} - ${TSPRIMEIRAPORTAK} | bc `

                # Separando a parte do log desde o ultimo toque dado na primeira porta da sequencia ate o final do mesmo
                TOTALLINHASLOG=`cat $LOGFILTER | wc -l | awk '{print $1}'`
                LINHASATEPRIMEIRAPORTAK=`echo "("${TOTALLINHASLOG} - ${LINHAPRIMEIRAPORTAK}") + 1" | bc`
                QTDPORTAS=`cat $LOGFILTER | grep $IP | tail -${LINHASATEPRIMEIRAPORTAK} | cut -d "," -f 22 | egrep -vw $IGNOREPORTS | sort | uniq | wc -l`
                # Coletando as portas acessadas.
                PORTASACESSADAS=`cat $LOGFILTER | grep $IP | tail -${LINHASATEPRIMEIRAPORTAK} | cut -d "," -f 22 | egrep -vw $IGNOREPORTS | awk -v RS="[ \n]+" '!n[$0]++' | sed 's/ //'`

                # Checando sequencia de portas acessadas
                if [ ${QTDPORTAS} -eq ${QTDPORTASK} -a ${DIFTS} -le ${TIMEOUT} ]; then
                        while [ ${QTDPORTAS} != 0 ]; do
                                if [ `echo ${PORTASACESSADAS} | cut -d " " -f${QTDPORTAS}` = `echo ${PORTASK} | cut -d "|" -f${QTDPORTASK}` ]; then
                                        RESULTCHECK=1
                                        QTDPORTAS=$((QTDPORTAS-1))
                                        QTDPORTASK=$((QTDPORTASK-1))
                                else
                                        echo "`date` Sequencia invalida de portas acessadas" >> ${ARLOG}
                                        RESULTCHECK=0
                                        QTDPORTAS=0
                                        QTDPORTASK=0
                                fi
                        done
                        if [ ${RESULTCHECK} == 1 ]; then
                                echo "pass in quick on ${INTWAN} proto ${PROTO} from ${IP} to port ${PORT}" | pfctl -a "userrules/${IP}_${PORT}_${PROTO}" -f -
                                echo "`date` Liberacao da porta ${PORT}/${PROTO} para o IP ${IP} ativada!" >> ${ARLOG}
                        fi

                elif [ ${DIFTS} -gt ${TIMEOUT} ]; then
                        echo "`date` Primeira porta (${PRIMEIRAPORTAK}) foi acessada a mais de ${TIMEOUT} segundos. Operacao nao realizada." >> ${ARLOG}
                else
                        echo "`date` Sequencia invalida de portas acessadas" >> ${ARLOG}
                fi

        else
                echo "`date` Sem registros de conexoes desse IP ${IP}. Nada a fazer" >> ${ARLOG}
        fi

# Removendo ${IP}
elif [ ${ACAO} == "delete" ]; then
        pfctl -a "userrules/${IP}_${PORT}_${PROTO}" -F rules
        if [ $? = 0 ]; then
                echo "`date` IP ${IP} removido com sucesso!" >> ${ARLOG}
        else
                echo "Erro ao remover o IP ${IP}" >> ${ARLOG}
        fi
else
        echo "`date` Operacao invalida" >> ${ARLOG}
fi

Dê permissão de execução para o script:

chmod +x /var/ossec/active-response/bin/portknocking.sh

..::| Portas para liberação de conexão

Agora vamos criar as regras no pfSense para as portas que, quando tocadas na sequência correta, liberarão as portas do serviço SSH e a do HTTP. Essas regras serão de bloqueio, pois o que queremos é apenas logar os toques nelas.

Escolhi a sequência de portas 1111, 1000 e 2000, para liberar a porta 22/TCP, e as portas 11, 52 e 40 para liberar a porta 80/TCP. Todas com o protocolo TCP.

É recomendado usar, no mínimo, 3 portas e que não sejam sequênciais (por exemplo: 1000, 1001 e 1002) para cada liberação pois, em casos de descoberta da primeira por um atacante, as demais seriam meio óbvias de adivinhar. Também é necessário marcar a opção de logar essas regras, para que os toques sejam registrados no /var/log/filter.log.

Caso queira criar mais do que 3 portas de toques, basta criá-la(s) no pfSense. O script reconhece automaticamente quantas portas são necessárias nessa técnica.

Na descrição de cada regra há um padrão extremamente importante para que o script funcione corretamente. Sempre escreva “Port Knocking (número da regra no wazuh)” pois o script irá procurar nesse campo as portas correspondentes ao Port Knocking em questão. Cada regra no wazuh (que serão criadas mais tarde) corresponde a uma liberação.

É muito importante colocar a descrição da regra corretamente, seguindo o padrão acima descrito

Crie todas as regras tal como a que foi criada na imagem acima, para cada uma das 6 portas (1111, 1000, 2000 com a descrição “Port Knocking 100001” e 11, 52 e 40 com a descrição “Port Knocking 100002“), ficando a tabela de regras WAN assim:

A ordem das regras será a sequência em que cada porta deverá ser tocada

Aqui você também define a ordem em que as portas devem ser tocadas. Então após a criação das regras, coloque-as na ordem em que elas devem ser tocadas. Mesmo que os toques acertem as 3 portas, se não forem tocadas na ordem correta o script não irá liberar a porta do serviço solicitado.

No exemplo acima não há outras regras além das desse artigo, mas se houvessem o script iria ignorá-las automaticamente para evitar que uma conexão legítima interfira na verificação dos toques.

No servidor Debian crie as seguintes regras no arquivo /var/ossec/etc/rules/local_rules.xml:

  
    87701
    2000
    Port knocking da porta SSH padrao
  

  
    87701
    40
    Port knocking da porta HTTP padrao

Note que em foram colocadas apenas as últimas portas das sequências de cada liberação

Acima foram criadas duas regras, uma para cada liberação (SSH e HTTP). Elas serão ativadas quando a última porta, da sequência correspondente ao serviço a ser liberado, for tocada pois assim significa que todas as anteriores necessárias já foram acessadas e, portanto, já logadas para serem lidas pelo script. Note que o número de cada regra (dentro de ) corresponde a descrição das regras criadas no pfSense anteriormente.

Acrescente o comando e o active-response a seguir no arquivo /var/ossec/etc/ossec.conf, logo após o último :

portknocking-ssh portknocking.sh em0,wan,tcp,22,120,22|80 yes portknocking-http portknocking.sh em0,wan,tcp,80,120,80|22 yes portknocking-ssh defined-agent 002 100001 no 60 portknocking-http defined-agent 002 100002 no 60

Veja que em há informações importantes (separadas por vírgula) que precisam ser passadas ao portknocking.sh, que são:

Nome da interface WAN reconhecida pelo FreeBSD

Nome da interface WAN dada pelo pfSense

Protocolo do serviço que será liberado
Porta que será liberada
Tempo máximo (em segundos) entre o toque na primeira porta da sequência e a última
Portas que serão ignoradas na verificação dos toques. Deve-se colocar as portas que forem usadas em outras liberações.

A ordem em que essas informações são colocadas é vital para o correto funcionamento do script de liberação.

Além disso, outra configuração muito importante é quanto ao tempo em que a regra de liberação de conexão ao serviço ficará ativa. Dentro da tag você estipula esse tempo em segundos.

Reinicie o wazuh-manager:

systemctl restart wazuh-manager

Se o pfSense foi recém instalado, os horários no /var/log/filter.log estarão diferentes da data do sistema operacional, gerando erro no script. Pra resolver, basta reiniciar o pfSense.

Lembrando que a regra de liberação criada após a sequência correta de toques nas portas do Port Knocking só é visível pelo comando pfctl, portanto não aparecerá no painel administrativo do pfSense, já que ela não foi criada via easyrules (porque através desse comando não é possível remover uma regra criada, por isso tive que usar o pfctl).

..::| Limitações

Quando o active-response do Wazuh é ativado para um determinado IP de origem, esse mesmo IP não consegue ativar outro active-response enquanto o primeiro ainda estiver ativo. Como o script é executado no pfSense, o mesmo não tem como avisar o Wazuh quando, por exemplo, uma sequência de portas forem tocadas na ordem errada, e assim evitar a execução do active-response. Ele é executado quando a última porta da sequência é tocada, mesmo que ela esteja errada, e ficará ativo até o seu timeout expirar. Portanto, caso erre a sequência uma vez, deve-se esperar o tempo configurado em que a liberação estivesse ativa, para então fazer uma nova tentativa (tags no /var/ossec/etc/ossec.conf na seção do ).

Por causa dessa limitação, recomenda-se um timeout pequeno, de uns 5 minutos, só para fazer uma manutenção rápida remotamente. Caso precise de mais tempo, o recomendado é criar uma regra diretamente no pfSense liberando a conexão para o seu IP de origem.

Por conta do que foi dito acima, também não é possível liberar as portas 22/TCP e 80/TCP ao mesmo tempo via Port Knocking. Quando uma for ativada, deve-se esperar o timeout dela passar para fazer o Port Knocking na outra.

..::| Testes

De um sistema linux, instale o curl e dê o seguinte comando (certifique-se que esse linux alcance a interface WAN do pfSense):

curl --connect-timeout 1 http://10.0.0.200:1111/ ; curl --connect-timeout 1 http://10.0.0.200:1000/ ; curl --connect-timeout 1 http://10.0.0.200:2000/ ; ssh root@10.0.0.200

Veja que, após os 3 toques feitos pelo comando curl, o prompt de autenticação SSH do pfSense é mostrado

Para verificar se a regra de liberação da porta do SSH foi criada com sucesso via pfctl, execute o comando no shell do pfSense:

pfctl -a "userrules/IP_PORTA_PROTOCOLO" -sr

Por exemplo, se o IP 10.0.0.182 pediu liberação da porta 22 do protocolo TCP, o comando acima ficará:

pfctl -a "userrules/10.0.0.182_22_tcp" -sr

No Windows, pode-se usar o PowerShell com o comando Test-NetConnection. Exemplo para a liberação da porta 22/TCP desse artigo:

Test-NetConnection -Port 1111 10.0.0.200 Test-NetConnection -Port 1000 10.0.0.200 Test-NetConnection -Port 2000 10.0.0.200

..::| Conclusão

Port Knocking é uma técnica que insere uma camada a mais de segurança para o acesso externo a sua rede. Com ele podemos evitar ataques de força bruta, por exemplo, e até ataques a aplicativos web em vulnerabilidades ainda não corrigidas. Não deixando uma porta sempre aberta para qualquer IP de origem bloqueia a detecção delas por escaneadores.

Se um administrador de rede está em uma situação em que não pode realizar uma conexão VPN a sua rede, ele poderá acessar o roteador se lembrar das 3 (ou mais) portas que devem ser tocadas antes da liberação de uma porta para um serviço administrativo desse roteador, e assim poderá criar outras regras para uma outra conexão, entre outras manutenções possíveis. O fato dessa porta administrativa ser liberada apenas para o IP de origem que efetuou os toques do Port Knocking, e com tempo dessa liberação ser pré-determinado, torna essa técnica excelente para que o seu firewall seja mais eficaz.

Em casos onde é possível estabelecer uma VPN, o Port Knocking também é útil pois poderá proteger a porta de conexão desse serviço. Não haveria necessidade de deixar essa porta sempre aberta para conexões. Nesse caso é recomendado criar um script, no lado do cliente, com os 3 (ou mais) toques já configurados para que se possa colocar um tempo maior de liberação (timeout) sem temer errar a sequência de portas, o que faria com que a porta do serviço solicitado ficasse inacessível pelo mesmo período em que estaria liberada. Geralmente uma VPN é necessária para períodos maiores de uso, por isso o timeout maior, nesse caso. Lembrando que o timeout vale para todos os active-response referente ao IP de origem.

O Wazuh tem a capacidade de enviar e-mails de alertas para o administrador quando uma regra é acionada, mediante configuração nela. Ou seja, é possível monitorar os acessos por Port Knocking, bastando apenas configurar as regras no Wazuh referente a essa técnica para que enviem e-mails sempre que ativadas.

Fontes:
https://documentation.wazuh.com/current/user-manual/capabilities/active-response/custom-active-response.html
https://forum.netgate.com/topic/147951/create-firewall-rules-by-script/4
https://www.openbsd.org/faq/pf/anchors.html
http://woshub.com/checking-tcp-port-response-using-powershell/

O post Port Knocking no pfSense usando Wazuh apareceu primeiro em Marcius Costa.

Wazuh criando regra no pfSense para bloquear IP de atacante

marcius — Fri, 11 Mar 2022 01:52:43 +0000

O cenário é o seguinte:

Debian Bullseye versão 5.10.92-1 com wazuh-manager 4.2.5-1 e elasticsearch, kibana e filebeat nas versões 7.14.2
pfSense CE 2.6.0-RELEASE
Ambos os servidores acima foram virtualizados em VirtualBox 6.1.32-2 em Arch Linux 5.16.13-arch1-1
O artigo parte do princípio que o wazuh-manager e o pfSense já estejam instalados, configurados e funcionais, como descrito acima
IP do servidor com wazuh-manager: 10.0.2.201/24
IP do servidor com pfSense: 10.0.2.200/24

..::| Instalando o agente no pfSense

Pra facilitar o trabalho de fazer as configurações no pfSense, habilite o acesso via SSH nesse servidor, indo em System -> Advanced -> marque a opção “Enable Secure Shell”:

Acesse o pfSense via SSH com o usuário root e instale o agente do Wazuh para FreeBSD 12 (base do pfSense):

pkg add https://pkg.freebsd.org/FreeBSD:12:amd64/quarterly/All/wazuh-agent-4.1.5.pkg

Configure o agente do Wazuh, editando o arquivo /var/ossec/etc/ossec.conf e alterando a palavra “IP” dentro da tag “
IP
” para o IP do servidor do Wazuh (debian), que nesse artigo é o 10.0.2.201, ficando assim:

Salve e saia do arquivo.

Agora vá na interface web do pfSense e instale a package “Shellcmd” para fazer com que o wazuh-agent inicie no boot desse servidor. Vá em System -> Package Manager -> Available Packages, procure por “Shellcmd” e o instale.

Depois de instalado, acesse-o em Services -> Shellcmd.

Clique no botão “+ Add” e preencha o campo “Command” com “/usr/local/etc/rc.d/wazuh-agent start” e depois clique me “Save”.

Agora crie uma regra para o agente se conectar com o wazuh-manager, indo em Firewall -> Rules -> LAN -> ADD e preencha da seguinte forma:

Lembre-se de substituir o IP 10.0.2.201 pelo do servidor onde está o wazuh-manager na sua arquitetura

Salve e aplique a regra. Tome cuidado para que ela não seja bloqueada por uma possível outra regra de bloqueio antes dessa.

Agora volte ao terminal conectado via SSH e habilite o agente:

/usr/local/etc/rc.d/wazuh-agent enable

Inicie o agente:

/usr/local/etc/rc.d/wazuh-agent start

Verifique se o agente iniciou normalmente:

/usr/local/etc/rc.d/wazuh-agent onestatus

Agora no painel do Wazuh, verifique se o novo agente se conectou ao servidor, indo no menu do Wazuh -> Management -> Status:

..::| Script de bloqueio

Agora volte para a conexão SSH com o servidor do pfSense para criarmos um script que será responsável pela criação de regras de bloqueio com base em regras acionadas no wazuh-manager.

Crie o arquivo /var/ossec/active-response/bin/easyrule-pf.sh com o seguinte conteúdo:

#!/bin/sh # Script para adicionar IPs bloqueados pelo Wazuh no pfSense dentro do aliase "EasyRuleBlockHosts" # Expect: srcip # Author: Marcius da C. Silveira # Last modified: Mar 3, 2022 ACAO=$1 USUARIO=$2 IP=$3 # logando as atividades desse script echo "`date` $0 $1 $2 $3 $4 $5" >> /var/ossec/logs/active-responses.log # Erro se o IP nao for mencionado nos argumentos if [ "x${IP}" = "x" ]; then echo "$0: Falta o IP no terceiro argumento (IP)" exit 1; fi # Coletando os nomes das interfaces do pfSense INTF=`/usr/local/bin/xmllint --xpath 'pfsense/interfaces/child::*' /conf/config.xml | grep '^<' | tr -d '<' | tr -d '>'` QTDINTF=`echo ${INTF} | wc -w` # a ACAO sera feita para cada interface coletada acima # caso deseje executar a ACAO para interfaces especificas, especifique elas na varialvel INTF colocando espacos entre cada uma, por exemplo: # INTF="wan lan" while [ ${QTDINTF} != 0 ]; do IF=`echo ${INTF} | cut -d ' ' -f ${QTDINTF}` # Se o argumento ACAO for "add" if [ "x${ACAO}" = "xadd" ]; then /usr/local/bin/easyrule block $IF "${IP}" # Se o argumento ACAO for "delete" elif [ "x${ACAO}" = "xdelete" ]; then /usr/local/bin/easyrule unblock $IF "${IP}" # Se o argumento ACAO for invalido else echo "$0: acao invalida: ${ACAO}" fi QTDINTF=$((QTDINTF-1)) done exit 1;

Dê as permissões 750 para esse arquivo:

chmod 750 /var/ossec/active-response/bin/easyrule-pf.sh

Reinicie o agente:

/usr/local/etc/rc.d/wazuh-agent restart

Agora vá até o servidor Debian onde está o wazuh-manager, e edite o arquivo /var/ossec/etc/ossec.conf acrescentando, depois do último ““, o seguinte conteúdo:

easyrule-pfsense easyrule-pf.sh yes easyrule-pfsense defined-agent 001 5758 no

Nesse exemplo acima eu especifiquei o agente recém instalado no pfSense, cujo o código é 001. Caso queira que mais de um agente execute a ação de criar regras de bloqueio, adicione os códigos desses agentes os separando por uma vírgula (por exemplo: 001,009,021). Nesse caso, lembre-se de colocar o script “easyrule-pf.sh” nesses outros servidores também, como descrito acima, assim como configurar suas permissões.

Aqui nesse exemplo eu também especifiquei uma regra que, quando acionada em algum ataque, irá executar o script “easyrule-pf.sh” no(s) agente(s) configurado(s) em ““. É possível colocar, ao invés de apenas uma regra, várias delas também as separando por vírgula, ou também um grupo de regras, mas nesse caso não se usa as tags ““, e sim ““, inserindo os nomes dos grupos que pretende usar (por exemplo: authentication_failed|authentication_failures). Mais informações sobre as possibilidades de configuração dos tipos de gatilhos você encontra aqui.

Reinicie o wazuh-manager:

systemctl restart wazuh-manager

..::| Testando

No exemplo acima, especifiquei uma regra cuja sua configuração detecta várias tentativas de login via SSH em um servidor. Para testar se o script que adiciona IP à regras de bloqueio no pfSense está funcionando, desabilitei a proteção SSH do pfSense indo em System -> Advanced, na primeira aba chamada “Admin Access“, e logo abaixo em “Login Protection” adicionei o IP da minha máquina no campo “Pass list“, para que o pfSense permita que eu faça várias tentativas de login pelo SSH ao invés de me bloquear automaticamente por ele mesmo.

Agora tente se conectar várias vezes seguidas via SSH com uma senha errada, para testar se a regra 5758 será acionada fazendo com que o active-response configurado acima crie uma regra de bloqueio nas abas de cada interface de rede do pfSense.

Veja que o script easyrule-pf.sh, usado no active-response, funcionou perfeitamente. Foi criada uma regra de bloqueio e um aliase chamado “EasyRuleBlockHosts” seguido do nome da interface, onde nele irá constar os IPs passados pelo wazuh-manager quando acionada a regra especificada nas configurações do active-response.

..::| Anti-lockout

Um detalhe importante, que deve ser observado, é quanto a regra criada na aba LAN:

Veja que o sistema “Anti-Lockout“, que por padrão vem ativado no pfSense para evitar que o administrador desse sistema não seja impedido de acessá-lo, ficará sempre em primeiro na lista de regras dessa aba. Como o teste que fiz acima era justamente para bloquear um acesso via SSH partindo de um IP na rede LAN do pfSense, a máquina usada no ataque não ficará bloqueada de fato, por conta desse “Anti-Lockout“.

Uma solução nesse caso é criar uma regra de liberação da porta 80 ao pfSense, colocando em primeiro na lista da aba LAN, acima da regra de bloqueio que usa o aliase “EasyRuleBlockHostsLAN“, assim:

Observe que a regra deve ficar sempre na primeira posição, e em segundo a regra criada pelo “easyrule-pf.sh“

Depois desative o sistema “Anti-Lockout” (em System -> Advanced -> marcar a opção “Disable webConfigurator anti-lockout rule“). Nesse momento você notará que não haverá mais aquela regra padrão no topo da aba LAN, ficando parecida com a imagem acima.

..::| Conclusão e considerações finais

Com essa técnica será possível ter uma blacklist própria com base em ataques direcionados a sua rede, e replicar para todos os seus gateways o IP do atacante, bloqueando-o antes que o mesmo tente um novo ataque por outros caminhos.

É importante lembrar também que os IPs de atacantes, na maioria das vezes, não são sempre os mesmos. Ou seja, depois de alguns dias as operadoras fornecem um novo IP para seus usuários, e isso pode implicar em bloqueios errados, pois um cliente da sua empresa pode acabar recebendo um IP que foi usado recentemente em um ataque, impossibilitando-o de acessar um servidor da sua rede, por exemplo.

Por isso, é importante colocar um tempo de bloqueio para cada IP, e após esses dias tirá-lo dos aliases das regras criadas pelo “easyrule-pf.sh“. Isso é configurável através da opção “” dentro do “” no “/var/ossec/etc/ossec.conf” dentro do servidor do wazuh-manager, e colocar um valor em segundos (por exemplo, para 8 dias de bloqueio: 691200).

Fontes:
https://techviewleo.com/how-to-install-wazuh-server-on-debian/
https://documentation.wazuh.com/
https://groups.google.com/g/wazuh/c/pc4IAOIjW-E?pli=1
https://freebsd.pkgs.org/12/freebsd-amd64/wazuh-agent-4.1.5.pkg.html
https://docs.netgate.com/pfsense/en/latest/development/boot-commands.html
https://documentation.wazuh.com/current/user-manual/capabilities/active-response/how-it-works.html#active-response-configuration
https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/active-response.html#reference-ossec-active-response

O post Wazuh criando regra no pfSense para bloquear IP de atacante apareceu primeiro em Marcius Costa.