Confissões de um testador: como vasculhei o IDS de um concorrente

Nenhum gateway de segurança de rede UTM que se preze pode ficar sem um IDS (Intrusion Detection System). Outra coisa é que a opção é frequentemente indicada pelo fabricante para um carrapato, a fim de acompanhar os concorrentes. Sei pela minha experiência como testador como isso acontece - parece haver IDS, mas na verdade não é bom. Por isso, quando me ofereceram para testar uma peça de UTM relativamente barata, sugeri antes de tudo "expulsar" sua OWL.


Peça UTM do inspetor de tráfego Next Generation S100 e switch Cisco 2960G


Se você tem experiência em trabalhar com o IDS, é interessante ler sobre isso nos comentários do artigo. É aconselhável - não sobre hardware caro (é claro que alguns Cisco NGFW de um milhão estão indo bem), mas sobre soluções mais acessíveis. Acho que os administradores da lokalka e os usuários em potencial dos gateways de rede ficarão curiosos para discutir quem trabalha com o IDS e se vale a pena comprar a um preço alto. Quando você puder, depois de dançar com um pandeiro, conseguir o mesmo por menos dinheiro.

Neste teste, estamos falando do modelo S100 - o preço mais acessível na linha Traffic Inspector Next Generation (os números significam que ele foi projetado para 100 assinantes). Aqui está a descrição dela no site oficial >>> . Em resumo, o hardware contém, por exemplo, um filtro de rede, uma VPN, um bloqueador de recursos e, é claro, o IDS.

Proponho uma metodologia simples de teste - verificamos a taxa de transferência e criamos a dependência do número de pacotes descartados na intensidade do tráfego em incrementos de 50, 100, 150 e 200 Mb / s. Por que fazemos tais intervalos? Começamos a partir de 100 Mb / s - a solicitação mais popular do cliente e adiamos mais e menos para ver o que acontece nos modos mais ou menos carregados, bem como no modo extremo 200 Mb / s.

A experiência de vida me diz que, com todas as regras ativas, o S100 pode não funcionar, por isso sugiro que o procedimento descrito seja realizado em três modos: primeiro, quando todas as regras estiverem ativas, depois com a parte das regras desativada (vamos chamá-lo de Grupo 1) e, finalmente, apenas quando estiver ativo apenas algumas regras (vamos chamá-lo de grupo número 2). Formamos os seguintes grupos de regras:

- Grupo nº 0: bem, isso é compreensível, todas as regras sem exceção.
- Grupo nº 1: grupo de regras de Threads Emergentes (eu conhecia as regras desde o teste do IDS Snort, com exceção das regras de jogos emergentes).
- Grupo No. 2: um grupo de regras que considero simplesmente vinculativas ao IDS (veja abaixo), incluindo a adição de regras p2p, porque, por experiência própria, sei como as grandes empresas se relacionam negativamente com o fato de seus funcionários usarem ativamente as empresas. rede para baixar seus programas de TV favoritos.

O teste é possível usando o utilitário tcpreplay . Este utilitário permite reproduzir o tráfego de rede pré-gravado em uma velocidade específica. Comando: tcpreplay –i <interface> -l 0 testTI.pcap . O arquivo testTI.pcap contém 1 146 313 pacotes (escolhemos esse volume para que, por um lado, existam boas estatísticas, por outro lado, o tempo para "executar" não seja muito longo, no nosso caso, não mais que 15 minutos). Além disso, como eu disse, lançamos um rastreador de torrents.

Layout do banco de ensaio:



Se alguém tiver perguntas sobre a metodologia de teste, estou pronto para responder nos comentários.

Então, os resultados.

Grupo 0

Testar em um conjunto completo envolve carregar todas as regras, e há 30 305 delas.

Ao testar, usamos as configurações padrão do IDS:



Começamos a testar com 100 Mb / se entendemos que o ferro mal consegue puxar: dos 114 mil pacotes, 109 mil são descartados! Portanto, não faz sentido testar em 150 e, mais ainda, em 200 Mb / s. Pelo contrário, proponho dar uma chance ao dispositivo e realizar um teste adicional a 10 Mb / s. O resultado na tabela:



Nota:

kernel_packets - pacotes enviados;
kernel_drops - pacotes descartados. Como você pode ver, com as configurações padrão e com um conjunto completo de regras, ocorrem grandes perdas de pacotes (> 30% em relação ao kernel_packets). Vamos esperar que a otimização das regras para configurações mude a situação;
decoder_packets - o número de pacotes que o sistema processou corretamente;
detect_alerts - número de ataques detectados. A maior parte dos ataques é do tipo Pacote Fragmentado, mas os ataques de Detecção de Rastreador de Torrent também foram identificados.

Número do grupo 1

Obviamente, o pedaço de hardware não é otimizado para funcionar como um poderoso IDS completo, mas há espaço para manobras, a saber, a capacidade de alterar o mecanismo de busca de rota, desativar o carregamento do conteúdo do pacote em relatórios (carga útil) e também desativar grupos de regras e grupos de pacotes específicos. Um pouco de experimentação com as configurações - e chegamos à opção que apresento na figura a seguir.



A lista de regras ativas que deixamos:



Resultado do teste:



Como você pode ver, a imagem melhorou significativamente com esse grupo de regras (a porcentagem de pacotes descartados diminuiu várias vezes). Um ataque como "Detectando um rastreador de torrent" foi detectado com sucesso (ataques de "Pacote fragmentado" não apareceram mais).

Número do grupo 2

As configurações são as mesmas. Lista de regras ativas:



O resultado na tabela:


Aqui, a imagem do processamento de pacotes é ainda melhor, o que é esperado.

Sumário

A tabela de resultados finais, expressa como uma porcentagem de kernel_drops em relação a kernel_packets, é mostrada abaixo:



Graficamente, o resultado é o seguinte:



Como você pode ver, o número de regras e configurações ativas afeta diretamente a eficiência. Não faz sentido ativar as configurações ao máximo e todas as regras ao mesmo tempo - as perdas imediatamente diminuem de escala, mesmo em 10 Mb / s. Nos modos otimizados, o hardware parece normal até 100 Mb / s, mas as perdas aumentam acentuadamente em tráfego mais intenso. No entanto, para uso em "escritório", 100 Mb / s é suficiente. Se você dirigir o dispositivo nessa velocidade e selecionar as regras, poderá obter um IDS bastante satisfatório.

Talvez, para usar o conjunto completo de regras, sejam necessárias melhorias para usar o mecanismo pf_ring (https://www.ntop.org/products/packet-capture/pf_ring/) como um mecanismo para transferir um pacote para o espaço do usuário a partir do buffer da interface de rede. Para fazer isso, você precisará usar várias instâncias do Suricata, que, é claro, consumirão recursos de outros processos, mas talvez o jogo valha a pena.

Repito que, na minha opinião, o principal objetivo do dispositivo testado é um firewall e a opção IDS é auxiliar. Honestamente, eu estava pronto para o fato de que o hardware falhará. Descobriu-se que, com uma certa percepção do administrador do sistema, o sistema de detecção de intrusões no S100 está totalmente operacional.

PS Como eu disse acima, peço aos leitores que escrevam sobre sua experiência no uso do IDS em soluções relativamente baratas.

O teste PPS é publicado na conta do fabricante, porque não quero me destacar. No entanto, estou pronto para responder a todas as perguntas e debater nos comentários, mas, novamente, não em meu próprio nome :)