Na sua situação, acho que podemos criar duas opções de design que provavelmente funcionariam.
- Execute o snort no roteador diretamente.
- Execute o snort em uma caixa separada dedicada para esse fim.
Rodando no roteador
Desde que você tenha rolado sua própria instância Debian para seu roteador, seria simplesmente uma questão de instalar ou compilar os pacotes para sua versão / arquitetura. Você poderia então configurar o snort para anexar a interface interna ou externa, dependendo de qual você quer monitorar, e deixar rasgar.
Isso poderia ser fácil, não exigiria a adição de mais hardware, poderia ser facilmente reconfigurado para ser executado no modo IDP e não exigiria configurações de rede potencialmente estranhas para funcionar. A maior desvantagem será o desempenho. O Snort pode consumir uma quantidade insana de recursos. Ele poderia consumir toda a RAM e CPU em um sistema, tornando seu roteador incapaz de rotear.
O Snort tem muitas opções de configuração. Não apenas ligar ou desligar regras, mas regras whitelisting para determinados hosts, ajustando o número de bytes de memória usados para desfragmentação de pacotes, o número de pacotes para armazenar na memória para remontagem de fluxo TCP, etc. Eu geralmente recomendo gastar uma quantidade insana de tempo ajustar esses parâmetros e até mesmo depois de configurá-los da maneira que você deseja que eles voltem e fazer revisões periódicas para ver se algo precisa ser ajustado.
Execução de um sensor dedicado
Esta é geralmente a solução recomendada. Ele resolve o problema de interrupção de rede para a concorrência de recursos. Ele permite que você use hardware especialmente criado para que seu sensor faça exatamente o que você deseja. Isso também irá liberá-lo para adicionar um disco rígido extra para executar o daemonlogger ou adicionar mais memória RAM sem ter que lidar com o agendamento de interrupções de rede. Também é mais escalável. Claro, eu posso começar a usar o Pentium 4 whitebox rodando pfSense em casa, mas de jeito nenhum eu conseguirei rodar em um Juniper EX-8216 no trabalho. Um sensor de propósito específico funcionará tão bem em ambos os ambientes.
A desvantagem é que você está adicionando ainda outro sistema para gerenciar, outra caixa consumindo energia, mais BTU para evacuar, etc. Dependendo da sua infraestrutura de rede, pode ser ou não fácil obter os dados nela. Os principais fornecedores de rede têm algo a fazer isso. Cisco chama-lhe uma sessão de SPAN, Juniper chama-lhe um analisador, Enterasys chama-lhe um espelho. É possível executar a mesma função com o iptables usando o TEE target, embora eu não conheça nenhum outro firewall de host para dizer se eles podem ou como fazer isso. Falhando tudo o que você pode usar um toque de rede que é um dispositivo físico que copia eletricamente o fluxo de dados.
Em qualquer caso, o que você precisa fazer é obter uma cópia do tráfego da sua infraestrutura de rede para o seu sensor. A melhor maneira de fazer isso e o método recomendado é ter duas NICs no seu sensor: 1 para gerenciamento e 1 para monitoramento. O preço das interfaces pode variar muito, mas, a menos que você esteja falando sobre situações com links de mais de 1Gbps, ou taxa de transferência sustentada que se aproxima de 1Gbps, os cartões são bem baratos. Eu tenho recomendado até mesmo um simples Intel Pro / 1000 GT, as coisas custam $ 30 e faço tudo que você precisa!
É possível executar em uma interface, mas não posso recomendá-lo. É mais provável que você encontre inconsistências estranhas em seu monitoramento, ou possíveis problemas de rede, graças ao problema de transmitir em um link que normalmente é esperado (presumido?) Para ser recebido apenas.
Há uma quantidade razoável de informações disponíveis na tag snort em nosso site parceiro