Suricata mostrou como treinar sistemas de detecção de ataques baseados em ML em tráfego real

Suricata mostrou como treinar sistemas de detecção de ataques com ML em tráfego real

O IDS baseado em assinatura Suricata pode ser não apenas uma ferramenta de detecção, mas também uma fonte de rotulação para um modelo de ML de detecção de ataques. Os autores do estudo testaram essa ideia em tráfego corporativo real e encontraram um cenário viável, embora não universal, para treinar um ML IDS sem realizar ataques artificiais no recurso protegido.

Como o experimento foi configurado

O experimento foi implantado no banco de testes da empresa Ideco. Um servidor recebia tráfego corporativo real e o passava por um NGFW com um Suricata IDS modificado e assinaturas atuais. Um segundo servidor analisava o mesmo fluxo de tráfego com seu próprio utilitário session_analyzer, que coletava características para cada sessão de rede.

Os autores deliberadamente não construíram uma infraestrutura de laboratório com ataques sintéticos: o objetivo era entender se um modelo poderia ser treinado diretamente em uma rede já funcionando e em eventos reais de segurança. A coleta durou duas semanas—de 26 de junho a 10 de julho de 2025. Após filtragem, permaneceram 55.

548.971 conexões de rede. Das 118 características originais, selecionaram informações de endereço e 10 das características de sessão mais informativas, depois as compararam com as detecções do Suricata e atribuíram rótulos de Benign ou Attack.

O resultado foi um conjunto de dados binário onde o papel de "professor" para o modelo foi desempenhado não por pessoas ou rotulação manual, mas por um IDS baseado em assinatura já ajustado.

Onde o esquema falha

O principal problema se mostrou não na seleção de algoritmo, mas na qualidade da rotulação. O tempo do evento no Suricata não coincide com o tempo de início da conexão de rede: uma detecção pode se referir a um pacote que chega segundos após o início da sessão, e para ataques lentos a diferença ultrapassava 20 segundos. Adicionalmente, o mesmo tráfego poderia ser observado antes e depois do gateway, significando que um ataque correspondia a duas conexões com informações de endereço diferentes. Se tais casos não forem considerados, ruído entra no conjunto de dados e o modelo começa a aprender com exemplos contraditórios.

• nem todos os SIDs do Suricata são adequados para rotulação, especialmente regras ligadas apenas a IP, SNI ou URLs específicas;
• para alguns ataques, incluindo vários tipos de varredura de portas, o conjunto atual de características é simplesmente insuficiente;
• a amostra de treinamento deve cobrir pelo menos uma semana de tráfego real, incluindo dias úteis e fins de semana;
• o modelo deve ser retreinado quando novos tipos de ataques aparecem, assinaturas mudam, a infraestrutura de rede muda ou o padrão de trabalho dos funcionários muda.

Disso emergiu a descoberta chave sobre vetores "ruins": se duas conexões têm características iguais ou quase iguais mas rótulos diferentes, a qualidade da classificação cai drasticamente. Nem mesmo gradient boosting forte como CatBoost ajuda nesse caso. Alguns eventos do Suricata ajudam o modelo, enquanto outros apenas adicionam falsos positivos. Algumas assinaturas ultimamente fazem mais sentido excluir da rotulação e retornar as conexões correspondentes à classe Benign, caso contrário o ML IDS herda erros da camada de assinatura subjacente.

O que os resultados mostraram

Apesar de todas as limitações, a hipótese foi confirmada em geral: um ML IDS de nível de rede pode ser construído em uma rede já operacional, usando eventos do Suricata como fonte de rótulos. Isso é conveniente porque regras de assinatura bem ajustadas filtram antecipadamente uma porção significativa de alertas ruidosos aos quais os operadores não responderiam mesmo assim. Nesse modo, o Suricata se torna não apenas um sistema de detecção mas também um filtro de qualidade para o conjunto de treinamento.

O melhor resultado prático no estudo foi uma pontuação F1 de 0,98 com rotulação correta do conjunto de dados. Mas os autores honestamente apontam os limites da abordagem. Primeiro, eles resolveram um problema de classificação binária, mas para um NGFW real isso é insuficiente: o negócio precisa entender que classe exata de ataque foi detectada e como responder a ela.

Segundo, o experimento foi conduzido em uma rede corporativa de usuário, não em um serviço específico protegido como um servidor web, então transferir as descobertas para outras redes requer verificação separada.

O que isso significa

O estudo mostra um caminho prático da proteção baseada em assinatura para um modelo de ML sem um polígono de testes caro e rotulação manual de milhões de sessões. Mas também nos lembra do ponto principal: em cibersegurança, a qualidade do ML começa não com a seleção de algoritmo, mas com o quão cuidadosamente você conecta alertas reais, características de rede e contexto de infraestrutura.