Eu começaria com o fail2ban se fosse você.
Ambos podem ser um dreno em seus recursos se eles não estiverem configurados corretamente, mas eu suspeito que as ressalvas de trabalhar com regex serão mais familiares para você.fail2ban é mais fácil de fazer imediatamente útil (aos meus olhos, pelo menos).
É muito mais simples configurar para bloquear fontes maliciosas do que snort, e você pode configurar o fail2ban para varrer logs de snort, a fim de bani-los.
Nem é provável que você proteja você contra DDoS como tal, mas ambos poderiam, em seu equivalente ao modo de bloqueio, ser usados para evitar o esgotamento de recursos que não sejam de rede, evitando interações com servidores de aplicativos reais.
Um problema com o snort é que é um pouco não trivial que ele funcione no modo IPS (ou seja, bloqueando o tráfego) - AFAIK, muito mais comum é executá-lo como um IDS (ou seja, detectar tráfego malicioso). / p>
O fail2ban é, como você diz, essencialmente apenas um script que regexa os arquivos de log, extrai fontes maliciosas desses logs (por exemplo, falha no login SSH, o cliente Web que aciona respostas repetidas 4xx ou 5xx, ou ter um user agent associado perfis de atacantes conhecidos). Ele se integra ao iptables (e qualquer coisa que possa estar rodando sobre o iptables, por exemplo, firewalld, shorewall), para bloquear o tráfego relacionado a hosts maliciosos. Esses blocos tendem a ser implementados como regras simples do iptables, ou como uma regra iptables + um ipset.
snort (e suricata e outros IDSen) realmente inspecionam vários aspectos dos fluxos de tráfego, a fim de detectar tráfego potencialmente malicioso. Ele usa regras em um formato específico de domínio, que também pode fazer correspondência de endereço IP (e / ou nome do host / domínio), bem como inspeção de pacotes, remontagem e muito mais. Um conjunto de regras bastante amplamente utilizado em de EmergingThreat - você pode querer ler (algumas delas), para obter uma sensação das capacidades do snort.
Uma consideração é que o fail2ban geralmente será útil fora da caixa, onde não é totalmente o caso do snort - você geralmente precisa ajustar suas regras (e possivelmente adicionar algumas das suas próprias) para balancear volumes de eventos com sua capacidade de ação.
Pessoalmente, uma configuração que funciona para mim enquanto gasto algum tempo melhorando no snort é:
- setup fail2ban com ssh e web jails relevantes
- crie uma cadeia lendo o log de alerta do IDS (no meu caso, isso é suricata, mas isso é um detalhe), notavelmente procurando por alertas do Prio 1 e também procurando por hosts marcados como DROP (sim, eu poderia carregar o ipsets relevantes)
- deixe o fail2ban fazer o resto.
Isso pode ou não funcionar para você, mas significa que você obtém alguma proteção extra contra o snort sem precisar se tornar particularmente conhecedor de seus internos.
No entanto, eu mencionaria que as regras do snort podem parecer um pouco mais alarmistas do que se pode justificar - ter uma ideia de quais ameaças elas estão apontando, e como entender / interpretar alertas, geralmente vale o esforço.
Depois de se sentir mais confortável com o snort, primeiro ajuste-o e depois considere se deseja permitir que ele lide diretamente com as coisas (por exemplo, coloque-o no modo IPS).
De passagem, você pode considerar como um WAF pode fazer parte da imagem, se muitos de seus ativos expostos forem baseados na Web.