[GTER] RES: Sistema de detecção de ataques de DDOS
Wed Oct 7 16:48:28 -03 2015
Previous message (by thread): [GTER] Sistema de detecção de ataques de DDOS
Next message (by thread): [GTER] RES: Sistema de detecção de ataques de DDOS
Também implementamos aqui, tivemos que fazer pequenos ajustes, mas o último fim de semana um IP que estava na mira dos ataques não nos tirou o sono, só recebemos os avisos de bloqueio, nem deu muito tempo de pegar no gráfico SNMP, que pega amostras minuto a minuto, mas confirmei nos flows.
Também tive um evento interessante ao bloquear um cliente que estava fazendo PortScan pela quantidade de Flows.
Uma dica pra quem vá implementar, seja usando a imagem VyOS ou instalado no script ou na unha, é aumentar o parâmetro "average_calculation_time = " para 60 ou 120, isso ajuda a evitar Falsos-Positivos. Ativar o contrack na configuração dele tbm para calcular Flows, aqui a média dos IPs com mais flows é de 300, assim definimos em 1000 e tem resolvido bem com DDoS.
Quanto ao bloqueio interno, bom, filtre para seus clientes residenciais as portas UDP 53,123,161 e 1900 (DNS, NTP, SNMP e SSDP) que são os protocolos que costumam amplificar. Para os casos de PortScan ou ataques com uso de banda alta no cliente e portscan, o próprio cliente sente que está lento, mas vc pode tentar usar o NfSen com o plugin NfSigth, não usei mas pelo que li dele faz mais ou menos isso de identificar e notificar esses casos.
De: gter [mailto:gter-bounces at eng.registro.br] Em nome de Cleber A. Nascimento
Enviada em: quarta-feira, 7 de outubro de 2015 15:41
Assunto: Re: [GTER] Sistema de detecção de ataques de DDOS
Estamos em testes aqui com FreeBSD.
Alguns colegas tb o estão testando com VyOS e estão sendo surpreendidos com a taxa de acertos, assim como a simplicidade de implementação.
Em 7 de outubro de 2015 14:43, <luciano at netvga.com.br> escreveu:
> Dizem ser muito bom! mais ainda não implementei.
> https://github.com/FastVPSEestiOu/fastnetmon
> > On 10/07/15 12:17, suporte salvador wrote:
> >> Nesse caso seria interessante enviar um aviso ao cliente também,
> >> para que o mesmo limpe suas máquinas.
> > O objetivo é justamente detectar essas origens comprometidas e
> > mitigar o problema. Hoje mesmo aconteceu com um cliente nosso. No
> > final das contas era um Mikrotik com 'allow-remote-request'
> > habilitado nas configurações de DNS. Qualquer algoritmo que
> > implemente algum tipo de threshold para tuplas src/dst ip/port em
> > conexões UDP e nos notifique já seria um bom começo. A solução
> > com sFlow seria bem plausível por enviar somente amostras dos pacotes e não precisar estar "inline".