[GTER] Mitigando ataques DDoS tcp com iptables
Wilson R Lopes
wilsonlopes00 at gmail.com
Mon Jul 4 17:57:24 -03 2016
1) Já faz tempo que DDoS "De gente grande" é UDP
Depende o ponto de vista. Eu considero que DDoS de gente grande é de
aplicação, https, por exemplo, quando uma grande quantidade de máquinas ou
dispositivos infectados controlados por um c&c disparam uma série de
requests em https para a sua aplicação. Muito mais difícil o atacante ter
uma botnet grande o suficiente para gerar uma grande quantidade de
requests, e estes muitos mais dificeis de controlar, pois não precisam de
muito tráfego e você no meio do caminho não tem visibilidade da quantidade
de requests criptografados no https, passam por mecanismos de validação de
javascript, etc.
Isso é muito mais de "gente grande" do que simplesmente abusar de
servidores ntp ou dns abertos.
Claro, ataques UDP possuem maior volumetria pelos mecanismos de
amplificação - isso trata-se antes de entrar na sua rede, com um serviço de
clean pipe qualquer. Esses, bem fáceis de tratar por ser fácil distinguir
tráfego legíitmo.
A recomendação do post é bem específica - ataques tcp, que obviamente, não
são maiores que seu link, e você não tem um device específico de mitigação
DDoS. Iptables é uma alternativa home made, como disse no post, limitada,
mas eficaz.
Considerando que esta é uma solução para ser aplicada no endpoint (direto
> no servidor web, por exemplo, ou um um firewall dentro da sua rede onde
> você conhece todo o mtu do path e garante que não tem nada com mtu menor
> que o default de 1500), e o próposito é de filtrar ataques tcp, pmtud
neste
> caso não é um problema.
2)Você consegue ter absoluta certeza que a internet inteira trafega em 1500?
Se o cliente é um PPoE ou utilize qualquer tecnologia com mtu menor que
1500, no momento do estabelecimento da conexão TCP, o MSS é negociado entre
meu servidor e ele, e o MSS da conexão será o do menor valor - neste caso,
do cliente PPPoE.
Quem pode gerar problema neste caso é alguem no meio do caminho com MTU
menor, e este bloqueando icmp, impedindo o pmtud de funcionar por bloquear
as msgs de fragmentation needed.
O meu servidor ou firewall no endpoint bloqueando icmp não faz diferença
alguma.
Abs,
Wilson.
Em 4 de julho de 2016 15:18, Leonardo Amaral - Listas <
listas at leonardoamaral.com.br> escreveu:
> 1) Já faz tempo que DDoS "De gente grande" é UDP
> 2) Conntrack? Sério mesmo?
> 3)
>
> Considerando que esta é uma solução para ser aplicada no endpoint (direto
> > no servidor web, por exemplo, ou um um firewall dentro da sua rede onde
> > você conhece todo o mtu do path e garante que não tem nada com mtu menor
> > que o default de 1500), e o próposito é de filtrar ataques tcp, pmtud
> neste
> > caso não é um problema.
>
>
> Você consegue ter absoluta certeza que a internet inteira trafega em 1500?
> A Morto e provedores que rodam PPPoE acham que não.
>
>
>
> [image: --]
>
> Leonardo Amaral
> [image: https://]about.me/leonardo.amaral
> <
> https://about.me/leonardo.amaral?promo=email_sig&utm_source=email_sig&utm_medium=email_sig&utm_campaign=external_links
> >
>
> Em 4 de julho de 2016 12:47, Wilson R Lopes <wilsonlopes00 at gmail.com>
> escreveu:
>
> > Depende o ponto de vista....
> >
> >
> > Considerando que esta é uma solução para ser aplicada no endpoint (direto
> > no servidor web, por exemplo, ou um um firewall dentro da sua rede onde
> > você conhece todo o mtu do path e garante que não tem nada com mtu menor
> > que o default de 1500), e o próposito é de filtrar ataques tcp, pmtud
> neste
> > caso não é um problema. Problemas podem surgir caso se filtre todo icmp
> no
> > meio do caminho e você não conhece o que tem para trás.
> >
> > Se o MTU for menor do lado cliente, mesmo que ele não saiba qual o MTU do
> > seu servidor, o negócio se resolve na negociação do MSS.
> >
> >
> > Na prática, fugir de alguns "best practices" pode ajudar muito em
> ambientes
> > com grande volume de ataques. O descarte de floods de icmp
> "desncessários"
> > pode aliviar bastante na hora do processamento do volume de pps em um
> > ataque.
> >
> >
> >
> > Abs,
> > Wilson.
> >
> >
> > Em 4 de julho de 2016 11:34, Leonardo Amaral - Listas <
> > listas at leonardoamaral.com.br> escreveu:
> >
> > > Eu nem quis comentar. Enfiaram filtro computacionalmente caro ali pra
> > > filtrar DDoS.
> > >
> > >
> > >
> > > [image: --]
> > >
> > > Leonardo Amaral
> > > [image: https://]about.me/leonardo.amaral
> > > <
> > >
> >
> https://about.me/leonardo.amaral?promo=email_sig&utm_source=email_sig&utm_medium=email_sig&utm_campaign=external_links
> > > >
> > >
> > > Em 4 de julho de 2016 10:28, Christian Lyra <lyra at pop-pr.rnp.br>
> > escreveu:
> > >
> > > > Caros,
> > > >
> > > > Achei que tava indo bem... até que boom!!
> > > >
> > > > "iptables -t mangle -A PREROUTING -p icmp -j DROP
> > > >
> > > > This drops all ICMP packets. ICMP is only used to ping a host to find
> > out
> > > > if it's still alive. Because it's usually not needed and only
> > represents
> > > > another vulnerability that attackers can exploit, we block all ICMP
> > > packets
> > > > to mitigate Ping of Death (ping flood), ICMP flood and ICMP
> > fragmentation
> > > > flood."
> > > >
> > > >
> > > > preparar para problemas com MTU em 3, 2...
> > > >
> > > > 2016-07-03 20:53 GMT-03:00 Rodrigo Meireles <mikrotikfull at gmail.com
> >:
> > > >
> > > > > Excelente!
> > > > >
> > > > > Em 3 de julho de 2016 19:36, Wagner Loula <wld.net1 at gmail.com>
> > > escreveu:
> > > > >
> > > > > > Muito bom
> > > > > > Em 3 de jul de 2016 18:28, "Wilson R Lopes" <
> > wilsonlopes00 at gmail.com
> > > >
> > > > > > escreveu:
> > > > > >
> > > > > > > Excelente artigo que mostra como configurar e otimizar o
> iptables
> > > > para
> > > > > > > mitigar vários tipos de ataques tcp - syn floods, ack floods,
> > > invalid
> > > > > tcp
> > > > > > > headers, open connections flood. Limitada, mas uma boa solução
> > > "home
> > > > > > made".
> > > > > > >
> > > > > > >
> > > > > > > https://javapipe.com/iptables-ddos-protection
> > > > > > >
> > > > > > >
> > > > > > > Abs,
> > > > > > > Wilson
> > > > > > > --
> > > > > > > gter list https://eng.registro.br/mailman/listinfo/gter
> > > > > > --
> > > > > > gter list https://eng.registro.br/mailman/listinfo/gter
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > *Rodrigo Melo Meireles*
> > > > >
> > > > > *CTO - Solustic Solucoes em Tecnologia-TI*
> > > > > Analista/Consultor de Redes
> > > > > Analista de Segurança
> > > > > Mikrotik Certified
> > > > > URBSS Certified
> > > > > 85.40629515 85.996459346
> > > > > --
> > > > > gter list https://eng.registro.br/mailman/listinfo/gter
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Christian Lyra
> > > > PoP-PR/RNP
> > > > (41) 3361-3343
> > > > --
> > > > gter list https://eng.registro.br/mailman/listinfo/gter
> > > >
> > > --
> > > gter list https://eng.registro.br/mailman/listinfo/gter
> > >
> > --
> > gter list https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list https://eng.registro.br/mailman/listinfo/gter
>
More information about the gter
mailing list