Skip to content
KitploitKITPLOIT
FerramentasExploitsBlog
Enviar
FerramentasExploitsBlog
Enviar

Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!

Kitploit é um diretório de ferramentas de hacking, cibersegurança e pentesting. Descubra as últimas atualizações de projetos para encontrar vulnerabilidades, analisar sistemas, automatizar testes e fortalecer sua segurança.

··Feeds·Contato·Privacidade·© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
NetworkSandboxEngine — Um sandbox de rede determinístico para testar regras de nftables. Ele usa namespaces de rede Linux efêmeros (netns) e Scapy para validar a lógica de firewall com segurança. | Kitploit
Ferramentas/GitHubGitHub/onyks-os/networksandboxengine
Ferramentas DefensivasSniffing e Análise de PacotesScripting e AutomaçãoAuditoria de ConfiguraçãoSegurança de RedeDevSecOps
GitHubonyks-os/networksandboxengine

NetworkSandboxEngine

Um sandbox de rede determinístico para testar regras de nftables. Ele usa namespaces de rede Linux efêmeros (netns) e Scapy para validar a lógica de firewall com segurança.

Mais Populares

Ver todos →

Descubra as ferramentas mais usadas pela nossa comunidade.

Explore todas as ferramentas

Navegue pela nossa coleção de ferramentas

Ver todas as ferramentas →
Ver RepositórioSite
25há 1 diaAinda não revisado
Compartilhar

Network Sandbox Engine (NSE)

Um motor Linux para testes determinísticos de firewall nftables dentro de namespaces de rede isolados.

Linux Python CI Status Documentation PyPI

License

Por que NSE? • Recursos • Requisitos • Instalação • Início Rápido • Como Funciona • Estrutura do Projeto


Network Sandbox Engine Interface


Por que NSE?

Testar conjuntos de regras de firewall em um sistema Linux em produção apresenta riscos significativos: regras malformadas podem derrubar sessões SSH de gerenciamento, vazar tráfego em texto claro durante os testes ou deixar tabelas de firewall órfãs ativas no host.

O Network Sandbox Engine (NSE) fornece um ambiente de teste seguro e reproduzível. Ele constrói namespaces de rede Linux efêmeros, conecta pares de ethernet virtuais, compila conjuntos de regras nftables e injeta pacotes sintéticos de Camada 2 e Camada 3 usando Scapy. Toda a avaliação acontece dentro do namespace sandbox: o estado do firewall do host nunca é alterado.

Propriedades arquiteturais principais:

  • Zero Mutação no Host: Os conjuntos de regras são carregados exclusivamente em namespaces sandbox efêmeros (nse_<uuid>) e são completamente removidos durante o encerramento.
  • Oráculo Auto-verificável: Cada execução injeta um pacote canário antes dos pacotes de teste e novamente depois deles, e só reporta um resultado se o trace do kernel para ambos foi observado. Veja O contrato do oráculo.
  • Dual-Stack e Topologias: Suporte nativo para tráfego IPv4 e IPv6, além de topologias Gateway multi-namespace para validação de regras de roteador, NAT e encaminhamento.
  • Superfície pequena e auditável: Um pacote, sem servidor web, sem JavaScript. nse/ tem ~1150 instruções com 98% de cobertura de testes.

Requer root

O NSE cria namespaces de rede, carrega conjuntos de regras nftables e lê eventos de trace do kernel, portanto é executado como root. Ele não abre um socket, uma porta ou um endpoint RPC de qualquer tipo — é uma biblioteca e uma CLI que você invoca, e mantém privilégios apenas durante a execução.

A versão 2.1.0 removeu a interface web FastAPI/Svelte que as versões anteriores incluíam. Essa interface era executada em processo como root a partir da 2.0.0, o que representava uma grande superfície de ataque para uma ferramenta de teste; o código permanece no histórico do git na tag v2.0.0 caso você precise dele.


O contrato do oráculo

Um teste de firewall é uma asserção negativa — "este pacote não passou" — e uma asserção negativa não vale nada a menos que o instrumento seja conhecido por estar funcionando. Um monitor de trace que nunca se conectou ao kernel e um firewall que bloqueou tudo produzem saída byte a byte idêntica.

Portanto, o NSE se recusa a reportar um veredito que não pode demonstrar que mediu:

GarantiaMecanismo
O monitor foi conectado antes do primeiro pacote de testeUm canário de prontidão é injetado e reinjetado até que seu trace no kernel seja observado. Sem observação, sem execução.
O monitor ainda estava conectado após o últimoUm canário de vivacidade é executado após a injeção. Se for perdido, o fluxo de vereditos é declarado truncado.
O parser entendeu o que o kernel disseLinhas de trace que nenhum padrão corresponde são contadas, e qualquer contagem acima de zero é um erro em vez de um log de depuração.
O monitor não morreu silenciosamenteO loop de leitura registra por que ele terminou — parada limpa, EOF inesperado, timeout ou crash — e apenas uma parada limpa é aceitável.
Um veredito ausente não é uma aprovaçãoO executor da CLI falha quando o número de vereditos observados difere do número esperado, em qualquer direção.

Pacotes canário são excluídos dos resultados por trace id, portanto nunca aparecem no seu fluxo de vereditos.

A suíte prova que isso se mantém, em vez de apenas afirmá-lo: make test-blind força o parser a não entender nada, e a build falha a menos que o executor saia com código diferente de zero. Essa tarefa é executada na CI a cada push.


Recursos

  • Motor In-Process: API Python direta (run_test_pipeline) retornando modelos Pydantic estruturados (TestRequest, TraceEvent).
  • Injeção de Pacotes Scapy: Forje pacotes TCP arbitrários (com flags SYN, ACK, FIN, RST personalizadas), UDP, ICMP e ICMPv6.
  • Topologias Isoladas:
    • Simple: Namespace sandbox único (nse_<id>) conectado diretamente ao host.
    • Gateway: Cadeia de Roteador (nse_router_<id>) e Servidor (nse_server_<id>) para testes de encaminhamento e NAT.
  • Limpeza Automatizada: Varreduras na inicialização detectam e removem namespaces e pares veth remanescentes de execuções abortadas anteriores. Os encerramentos incluem tentativas com backoff exponencial.
  • Executor de Testes YAML via CLI: Execute suítes de teste YAML declarativas para pipelines de CI/CD automatizados (nse-runner). Sai com código diferente de zero em um veredito errado e em um veredito que não conseguiu observar.
  • Padrões de Qualidade Rigorosos: Verificação de tipos estática completa (mypy --strict), imposição de limites arquiteturais (import-linter), formatação ruff e uma catraca de cobertura (make test-cov, piso de 98%).

Requisitos

  • SO Linux (Kernel 5.4 ou posterior com suporte a network namespace e nftables)
  • Python 3.10+
  • nftables (nft)
  • iproute2 (ip)
  • Privilégios de root (necessários para ip netns e operações de trace do kernel)

Em sistemas Debian ou Ubuntu:

root@kitploit:~
sudo apt update && sudo apt install -y nftables iproute2 conntrack

Instalação

1. Pacote PyPI (Recomendado)

Instale o motor principal com suporte a CLI:

root@kitploit:~
pip install "network-sandbox-engine[cli]"

2. Instalação Manual a partir do Código-Fonte

Para desenvolvimento local:

root@kitploit:~
git clone https://github.com/onyks-os/NetworkSandboxEngine.git
cd NetworkSandboxEngine
make setup

Início Rápido

1. Biblioteca Python Headless

root@kitploit:~
import asyncio
from nse.core.netns_controller import NetnsController
from nse.core.pipeline import run_test_pipeline
from nse.models.test_request import TestRequest, PacketSpec

rules = """
table ip filter {
    chain input {
        type filter hook input priority 0; policy drop;
        tcp dport 80 accept
    }
}
"""

request = TestRequest(
    rules=rules,
    packets=[
        PacketSpec(protocol="tcp", src_ip="10.0.0.1", dst_ip="10.0.0.2", dst_port=80),
        PacketSpec(protocol="tcp", src_ip="10.0.0.1", dst_ip="10.0.0.2", dst_port=22),
    ],
)


async def main():
    controller = NetnsController()
    events = await run_test_pipeline(request=request, controller=controller)
    for evt in events:
        if evt.verdict:
            print(f"[{evt.chain}] Verdict: {evt.verdict}")


asyncio.run(main())

2. Executor de Suíte de Testes YAML (CLI)

Crie um arquivo de teste firewall_test.yaml:

root@kitploit:~
tests:
  - name: "Allow HTTP Port 80, Drop SSH Port 22"
    topology: simple
    rules: |
      table ip filter {
        chain input {
          type filter hook input priority 0; policy drop;
          tcp dport 80 accept
        }
      }
    packets:
      - protocol: tcp
        src_ip: 10.0.0.1
        dst_ip: 10.0.0.2
        dst_port: 80
        expected_verdict: ACCEPT
      - protocol: tcp
        src_ip: 10.0.0.1
        dst_ip: 10.0.0.2
        dst_port: 22
        expected_verdict: DROP

expected_verdict é por pacote. Chaves desconhecidas são rejeitadas em vez de receberem valor padrão, portanto um erro de digitação faz a suíte falhar em vez de silenciosamente se tornar uma expectativa que você nunca escreveu.

Execute a suíte com privilégios de root:

root@kitploit:~
sudo nse-runner --file firewall_test.yaml

Códigos de saída: 0 todos os pacotes corresponderam; 1 um veredito estava errado ou o motor não conseguiu observar um. Erros do oráculo são reportados separadamente de falhas do firewall, porque significam que a medição quebrou, não o conjunto de regras.

3. Em um contêiner

root@kitploit:~
podman build -t nse .
podman run --rm --cap-add=NET_ADMIN --cap-add=NET_RAW \
    -v "$PWD/firewall_test.yaml:/suite.yaml:ro" nse --file /suite.yaml

Útil para fixar a versão do nftables contra a qual suas regras são testadas.


Como Funciona

O NSE orquestra subsistemas de rede do kernel Linux e interfaces de trace através de um pipeline de execução estruturado em múltiplos estágios:

root@kitploit:~
graph TD
    subgraph Step1["1. Test Specification"]
        Req["<b>TestRequest</b><br/>ruleset + packets + topology"]
    end

    subgraph Step2["2. Ephemeral Netns Sandbox"]
        direction TB
        Netns["<b>Netns Setup</b><br/>nse_&lt;id&gt; & veth links"]
        RuleEng["<b>Rule Engine</b><br/>validate & load nftables"]
        Inject["<b>Scapy Injector</b><br/>L2/L3 packet injection"]
        NFT["<b>Kernel nftables</b><br/>meta nftrace set 1"]

        Netns --> RuleEng
        RuleEng --> Inject
        Inject --> NFT
    end

    subgraph Step3["3. Trace Evaluation & Oracle"]
        direction TB
        Harvester["<b>Trace Harvester</b><br/>nft monitor trace stream"]
        Oracle["<b>Deterministic Oracle</b><br/>TraceEvents & verdicts"]

        Harvester --> Oracle
    end

    Step1 --> Step2
    Step2 --> Step3
  1. Validação do Conjunto de Regras: RuleEngine.validate() executa uma simulação do conjunto de regras usando nft --check -f.
  2. Provisionamento do Sandbox: NetnsController cria o namespace de rede isolado e configura interfaces de ethernet virtual (veth).
  3. Inicialização do Trace: Os conjuntos de regras são carregados no namespace com o trace do kernel armado (meta nftrace set 1).
  4. Injeção de Pacotes: ScapyInjector injeta quadros sintéticos através do link veth.
  5. Coleta de Vereditos: TraceHarvester captura eventos de nft monitor trace e retorna objetos TraceEvent estruturados.
  6. Encerramento: O namespace e todas as interfaces veth associadas são automaticamente excluídos.

Para especificações técnicas completas, consulte o Guia de Arquitetura Técnica.


Estrutura do Projeto

root@kitploit:~
NetworkSandboxEngine/
├── nse/                        # Core PyPI package (network-sandbox-engine)
│   ├── core/                   # Kernel primitives, pipeline, and naming rules
│   ├── models/                 # Pydantic models (TestRequest, PacketSpec, TraceEvent)
│   └── cli/                    # Headless YAML runner entrypoint
├── docs/                       # Architecture specs and MkDocs web documentation
├── tests/                      # Unit, golden file, and privileged e2e tests
│   └── fixtures/nft_trace/     # Golden `nft monitor trace` corpus
├── pyproject.toml              # Build backend configuration
└── Makefile                    # Local automation and CI workflow

Lançamento

Uma tag. git push origin vX.Y.Z compila, assina com Sigstore, publica o GitHub Release, envia para o TestPyPI, instala a partir do TestPyPI e faz um smoke test, e só então envia para o PyPI. Ensaie com make release-dry.

Veja docs/RELEASING.md.

Documentação

A documentação web interativa completa está disponível em:
https://onyks-os.github.io/nse/

Compile a documentação localmente:

root@kitploit:~
make docs

Sirva a documentação com hot-reload em http://127.0.0.1:8000:

root@kitploit:~
make docs-serve

Testes e CI Local

Execute linting estático e testes unitários:

root@kitploit:~
make verify

Execute a verificação completa de CI local (inclui linting, testes unitários, build do frontend, build da documentação, smoke test do PyPI e testes de integração privilegiados):

root@kitploit:~
make ci-local

Licença

Este projeto está licenciado sob a Licença MIT.

Baixar ferramenta