Este artefato tem como objetivo exemplificar o funcionamento prático de um cenário real de aplicação do DynSecNet, em que duas reivindicações são simuladas e a execução destas são demonstradas.
No primeiro cenário, quando um servidor web é iniciado e fica pronto para aceitar requisições, um mecanismo interno no servidor aciona a API do DynSecNet, que processa a informação e cria um serviço do tipo ACCEPT na SSoT, que por sua vez aciona de volta a API e desencadeia a criação de uma regra de iptables para liberação de porta 80 no servidor, permitindo que ele seja acessado.
No segundo cenário, o servidor web possui um monitor de acessos por segundo e, ao detectar uma anomalia no número de requisições, um mecanismo interno no servidor aciona a API do DynSecNet, que processa a informação e cria um serviço do tipo DROP na SSoT com source sendo o endereço IP do atacante, que por sua vez aciona de volta a API e desencadeia a criação de uma regra de iptables para o imediato bloqueio do IP do atacante, interrompendo o ataque.
A gestão de firewalls em ambientes heterogêneos é crítica para a cibersegurança organizacional considerandos aspectos como configuraçõoes inconsistentes e respostas lentas a incidentes. Este trabalho apresenta a DynSecNet, uma ferramenta de código aberto que unifica políticas de segurança em uma fonte central, permitindo tradução automatizada para múltiplos fabricantes, resposta adaptativa a eventos (e.g., bloqueio de IPs maliciosos em <2s) e rastreabilidade integral. Avaliações experimentais demonstram sua eficácia na mitigação proativa de ataques e na redução de erros operacionais.
Este README.md está organizado nas seguintes seções:
- Título, Objetivo e Resumo: Título do projeto, objetivo do artefato e resumo do artigo.
- Estrutura do README.md: A presente estrutura.
- Selos considerados: Lista dos Selos a serem considerados no processo de avaliação.
- Informações básicas: Descrição dos componentes e requisitos mínimos para a execução do experimento.
- Dependências: Informação sobre as dependências necessárias.
- Preocupações com segurança: Lista das considerações e preocupações com a segurança.
- Instalação: Relação de opções para a realização do experimento, bem como as instruções individuais de cada opção.
- Teste mínimo: Instruções para a execução das simulações.
- Experimentos: Informações de replicação das reivindicações.
- Documentação: Documentação básica da aplicação.
- Ambiente de teste: Ambientes que foram usados em testes.
- Licença: Informações sobre a licença do projeto.
Os selos considerados são:
- Artefatos Disponíveis (SeloD)
- Artefatos Funcionais (SeloF)
- Artefatos Sustentáveis (SeloS)
- Experimentos Reprodutíveis (SeloR)
- Opção 1: Imagem de VirtualBox com ambiente auto-contido já preparado para o experimento (testado em Sistema Operacional Microsoft Windows 10 ou superior e distribuições Linux baseada em Ubuntu versão 20.04 ou mais recente: Ubuntu, Kubuntu, Xubuntu e variantes) - o ambiente tem como usuário e senha experimento/experimento; ou
- Opção 2: Download de todos os contêineres envolvidos e execução destes, localmente em um desktop ou laptop (testado em Sistema Operacional não virtualizado, bare metal, baseado em Ubuntu versão 20.04 ou mais recente: Ubuntu, Kubuntu, Xubuntu e variantes, instalado).
- Opção 1: Nesta opção, deve ser feito o download e importação de um Appliance Virtual (arquivo .ova) e execução do ambiente virtualizado utilizando VirtualBox. Para tanto, são necessários: Sistema Operacional Microsoft Windows 10 ou superior e distribuições Linux baseada em Ubuntu versão 20.04 ou mais recente: Ubuntu, Kubuntu, Xubuntu e variantes), processador 64 bits com no mínimo 4 núcleos e flag de virtualzação VT-x ativada na BIOS, 4GB de memória RAM para uso exclusivo no experimento, VirtualBox 7.1 ou superior com Extension Pack correspondente à versão do VirtualBox; ou
- Opção 2: Nesta opção, todo experimento será executado em ambiente local através do download e execução automatizada de todos os componentes utilizando Docker. Para isto, são necessários: Sistema Operacional Linux, bare metal, baseado em Ubuntu versão 20.04 ou mais recente: Ubuntu, Kubuntu, Xubuntu e variantes), processador 64 bits com no mínimo 4 núcleos, 4GB de memória RAM para uso exclusivo no experimento, Docker Engine versão 26 ou superior e alguns pacotes disponíveis no repositório oficial (ver dependências).
Resumo dos requisitos de hardware e sistema operacional:
| Opção | Sistema Operacional | Memória RAM | Requisito |
|---|---|---|---|
| 1 | Microsoft Windows 10 ou superior, Linux baseado em Ubuntu versão 20.04 ou mais recente | 4GB | VirtualBox 7+ e ExtPack |
| 2 | Ubuntu bare metal versão 20.04 ou mais recente: Ubuntu, Kubuntu, Xubuntu e variantes | 4GB | Docker Engine 26+ |
O experimento possui duas opções disponíveis para execução, tendo cada uma delas as seguintes dependências:
- Opção 1: Cumpridos os requisitos descritos na seção anterior, referentes a Opção 1, esta opção não possui dependências.
- Opção 2: Cumpridos os requisitos descritos na seção anterior, referentes a Opção 2, é necessário certificar-se que o Docker Engine versão 26 ou superior esteja instalado conforme descrito na página oficial da ferramenta, bem como a seção postinstall, além dos pacotes curl, rsync, wget e git instalados.
Resumo dos pacotes adicionais necessários (dependências):
| Opção | Pacotes adicionais necessários |
|---|---|
| 1 | Nenhum pacote adicional |
| 2 | Pacotes curl, rsync, wget e git |
A instalação das dependências, caso necessário, ocorrerá automaticamente durante a execução do processo de execução do ambiente, bastando seguir as instruções exibidas em tela.
O experimento possui duas opções disponíveis para execução, tendo cada uma delas as seguintes preocupações com segurança:
- Opção 1: Por tratar-se de execução de Appliance pronta e virtualizada em ambiente auto contido, não há considerações quanto a preocupações de segurança nesta opção.
- Opção 2: Durante a execução do conjunto de contêineres envolvidos, dependendo das configurações do dispositivo que estiver hospedando o experimento, as portas 3000, 8000 e 8080 poderão estar abertas para a rede local, dependendo das configurações de firewall, encaminhamento de portas e perfil de segurança das interfaces de rede.
Cabe ressaltar que todas as senhas, chaves de API e outros elementos secretos dos componentes foram gerados para apenas para a demonstração do experimento, de tal forma que sua força de segurança foram propositalmente baixadas para facilitar o experimento. As senhas, chaves de API e chaves RSA do SSH utilizada são descartáveis e servem apenas ao propósito do experimento.
O experimento possui duas opções disponíveis para execução, tendo cada uma delas as seguintes etapas de instalação:
- Baixe o appliance (arquivo .ova) do experimento que está disponível através do link.
- Importe o arquivo exp-sf-sbseg2025.ova baixado no VirtualBox:
-
Clique em Finalizar e aguarde o processo de importação.
-
Execute a VM recém importada.
4.1. Caso seja exibida uma mensagem de erro do VirtualBox referente a interface de rede, isto é porque a nomenclatura do dispositivo de rede local é diferente daquela existente no computador onde a imagem foi gerada. Basta selecionar a opção "Alterar as opções de rede" e salvar.
- Após a inicialização da VM, abra o terminal (atalho no desktop) e execute:
iniciar-experimento- Aguarde a conclusão da preparação do ambiente. Informações do andamento da preparação serão exibidas, bem como informações da básicas da operação do experimento serão exibidas ao término do procedimento.
- Em um terminal do Linux local, executar:
wget "https://github.com/SBSeg25/DynSecNet/raw/refs/heads/main/experimento-sf-install.sh" -O "/tmp/experimento-sf-install.sh" ; chmod +x "/tmp/experimento-sf-install.sh" ; /tmp/experimento-sf-install.sh- Aguarde o término do processo de criação do ambiente.
(Caso alguma dependência ou requisito anteriormente descrito não tenham sido cumpridos, o script de instalação apresentará em tela as opções de resolução dos elementos faltantes)
- Ao término do processo de instalação, serão exibidas informações em tela com instruções básicas da operação do experimento.
O experimento possui duas opções disponíveis para execução, tendo cada uma delas os seguintes testes mínimos:
Estando na máquina virtual recém importada, certificar-se de que a máquina virtual possui conexão com a internet e o Docker Engine esteja pronto:
ping -c 3 github.com
Caso o retorno seja similar, a máquina virtual possui conexão com a internet.
docker ps -aCaso o retorno seja uma lista vazia similar ao exemplo acima, o Docker Engine estará pronto para a execução do experimento.
Certificar-se de que localmente há conexão com a internet e o Docker Engine está pronto: Abra um terminal local e execute:
ping -c 3 github.com
Caso o retorno seja similar, o dispositivo local possui conexão com a internet.
docker ps -aCaso o retorno seja uma lista vazia, o Docker Engine local estará pronto para a execução do experimento.
- No intuito de evitar quaisquer conflitos entre contêiners existentes no computador (caso o retorno anterior não seja uma lista vazia), sugere-se parar todos os contêiners que possam estar rodando localmente, para isso, execute em um terminal:
while read CID; do docker stop "${CID}"; done < <( docker ps -a | grep -v 'CONTAINER ID' | awk '{print $1}' )
O experimento possui duas opções disponíveis para execução, tendo cada uma delas os seguintes etapas para a obtenção das reivindicações:
Com o Ambiente já iniciado na máquina virtual, abrir um terminal e executar o alias que verifica o estado do iptables do servidor:
verificar-firewall-servidorAbrir o terminal e executar o comando para inspecionar o estado do iptables do servidor:
docker exec -it ubuntu-server iptables -nLObservar a implantação da regra de firewall permitindo o acesso à porta 80 tão logo o contêiner do servidor nginx subiu e ficou pronto para aceitar requisições.
Note que em ambos casos o Netbox tem como usuário e senha admin/admin
- No Netbox, verifique que há um serviço HTTP para o device container-nginx. Este serviço foi aplicado como regra de firewall assim que o nginx ficou disponível.
- No Grafana, observar a baixa contagem de acessos. Os contêineres ubuntu-client e ubuntu-rogue possuem scripts que acessam o contêiner ubuntu-server aleatoriamente de 1 a 9 vezes por segundo, simulando acessos considerados normais, demonstrando que o contêiner com o servidor nginx encontra-se acessível.
- Abrir um novo terminal e executar o alias para simular um ataque:
iniciar-ataque- Abrir um novo terminal e executar o comando para simular um ataque:
docker exec -it ubuntu-rogue /usr/local/bin/dos.sh- No Grafana, observar a anomalia no número de acessos. O contêiner ubuntu-rogue dispara uma rajada aleatória entre 100 e 150 acessos por segundo contra o contêiner ubuntu-server, simulando um ataque.
Note que poucos segundos após o início do ataque, o mesmo foi interrompido. Tão logo o monitoramento percebeu a anomalia no número de acessos, houve a implantação da regra de firewall bloqueando o acesso do IP do atacante.
- No Netbox, recarregue a página e verifique que há um novo serviço para o device container-nginx. Este serviço foi aplicado como regra de firewall com source do IP do atacante assim que o ataque foi identificado.
- Para reiniciar o experimento, pressione Ctrl+C no terminal do comando executado anteriormente (iniciar-ataque) e delete o serviço DoS no Netbox. A remoção do serviço fará o deploy da remoção da regra de bloqueio no firewall do servidor nginx.
- Para reiniciar o experimento, pressione Ctrl+C no terminal do comando executado anteriormente (docker exec -it ubuntu-rogue /usr/local/bin/dos.sh) e delete o serviço DoS no Netbox. A remoção do serviço fará o deploy da remoção da regra de bloqueio no firewall do servidor nginx.
Trata eventos do tipo 'model' == 'service' via POST do Webhook do SSoT, recebendo 'id' do serviço como parâmetro.
Aciona a função svc_deploy_task passando o 'id' do serviço e o tipo de evento como parâmetro.
Caso o evento seja 'created', aciona a função add_one_rule_service(service_id)
Caso o evento seja 'deleted', aciona a função del_one_rule_service(service_id)
Caso o evento seja 'updated', aciona a função del_one_rule_service(service_id) e em seguida a função add_one_rule_service(service_id)
Busca no SSoT as informações do serviço por 'id' e os serviços existentes do device através de consulta pela função device_services(device_id), retornando nome, portas, protocolo, endereço ip, tag, origem, descrição e comentários, renderizando o template Ansible de criação de regra de firewall com base nas informações obtidas e aplicando no inventory cujo endereço ip é do dispositivo em questão.
Busca no SSoT as informações do snapshot do estado anterior do serviço por 'id' e os serviços existentes do device através de consulta pela função device_services(device_id), retornando nome, portas, protocolo, endereço ip, tag, origem, descrição e comentários, renderizando o template Ansible de remoção de regra de firewall com base nas informações obtidas e aplicando no inventory cujo endereço ip é do dispositivo em questão.
Busca no SSoT os serviços existentes e aplicados em um device através de consulta pelo 'device_id', retornando o objeto completo do device em questão.
Busca serviços por 'id' cuja tag não seja DROP e aplica a tag ACCEPT. Esta ação aciona o webhook do SSoT com evento do tipo 'updated', desencadeando as funções del_one_rule_service e add_one_rule_service, aplicando a regra do tipo ACCEPT no SSoT, renderizando o template Ansible de criação de regra de firewall com base nas informações recebidas.
Recebe informações pelo sensor (porta, protocolo e endereço IP do atacante), busca no SSoT informações do device em questão com base no endereço IP de quem acionou a API, cria serviço no SSoT com tag do tipo DROP com as informações recebidas, atrelando ao device acionador, renderizando o template Ansible de criação de regra de firewall com base nas informações recebidas.
Para garantir a compatibilidade e o desempenho ideais, os testes foram realizados no seguinte ambiente: Hardware
Hardware: Notebook: Dell G15 (Modelo 2023/2024, com RTX 4050) Processador: Intel Core i7-13650HX Memória RAM: 16GB DDR5 @ 4800MHz (ou superior) Placa de Vídeo: NVIDIA GeForce RTX 4050 Laptop. Software: Sistema Operacional: Windows 11 Home, Virtual box 7.0 e Python 3.12.13 Software Secundário: Sistema Operacional: 24.04 LTS, Docker Engine 28.3.0 e Python 3.12.13
Hardware: Processador: AMD Ryzen 5 5500, Memória RAM: 8GB DDR4. Software: Sistema Operacional: 24.04 LTS, Docker Engine 28.3.0, Virtual box 7.0 e Python 3.12.13
Este projeto está licenciado sob a Licença GNU - veja o arquivo LICENSE para mais detalhes.
