[GTER] Mitigando ataques DDoS tcp com iptables

Tue Jul 5 12:56:28 -03 2016

Pina, tudo bem

mais uma vez, depende do ponto de vista.
Ataques para entupir links ainda são os mais usados, mas em termos de
complexidade já são coisa do passado (seja amplificação udp -
ssdp,ntp,dns,snmp,chargen,etc - ou tcp, estes menos usados por não haver,
ou haver pouco, poder de amplificação), porque são muito fáceis de mitigar,
pois mantem um padrão de tráfego. Este padrão é muito fácil de ser
diferenciado de tráfego legítimo.

Filtros estáticos configurados em um template de mitigação de qualquer
serviço anti-DDoS (aka serviços de cloud da arbor, radware, incapsula,
black lotus, etc etc) detectam e mitigam isso em menos de 1 minuto.
Detectado o ataque via netflow o template já sobe com um simples fitro como
"drop proto udp and src port 1900,123,161 etc". Todas essas soluções
oferecem mais de 1Tbps de capacidade de mitigação.
Dificilmente você terá problemas com um ataque volumétrico usando qualquer
uma destas soluções.

Hoje, e daqui para frente, a complexidade de mitigação de ataques estará
nos ataques de aplicação, onde a origem é muito distribuida (dezenas ou
centenas de milhares de ips de origem), que passam pelos syn cookies porque
fecham a conexão tcp, passam por validações de inserção de javascript e
captcha, porque conseguem se passar por um browser de mercado, e fica
extremamente dificil diferenciar este tráfego de um cliente real - porque
ele faz exatamente o que um cliente real faz.

A IoT já está representando problemas hoje, como nesses DVRs comprometidos
citados. Para constar, no Brasil já temos mais de 3 mil desses
comprometidos sendo usados como bot em ataques, fazendo ataque de aplicação
como o acima que citei.

Respondendo o amigo Leonardo Amaral:

Volumetria não demanda uma botnet imensa, exatamente pelo poder de
amplificação dos protocolos UDP.
Veja no slide 4 da minha apresentação no GTER 39, que com apenas 4.5k
servidores ntp abertos a Cloudflare contabilizou 400Gbps de ataque NTP.
Ainda, esses 4.5k servidores ntp podem ter recebido o comando de ataque de
apenas *UMA UNICA* origem que permite spoofing do ip de origem.
Não tem nenhum bot ou máquina invadida neste ataque, apenas ntp servers
 "mal configurados"

ftp://ftp.registro.br/pub/gter/gter39/08-AtaquesDdosPanoramaMitigacaoEvolucao.pdf

“To generate approximately 400Gbps of traffic, the attacker used 4,529 NTP
servers running on 1,298 different networks. On average, each of these
servers sent 87Mbps of traffic to the intended victim on CloudFlare's
network. Remarkably, it is possible that the attacker used only a single
server running on a network that allowed source IP address spoofing to
initiate the requests"

Voltando ao subject do thread, a solução proposta com iptables + synproxy é
uma home made, limitada como eu disse, mas que pode ser de grande serventia
para quem, por exemplo, hoje roda bgp na borda com soluções de software
(mikrotik, quagga, vyatta, bird, etc), e cai com ataques de syn flood de
míseros 200 ou 300 kpps. Aplicando esta configuração de synproxy isso já
sobe para quase *3 milhões de syn por segundo*.Também é de bastante
serventia no caso de um servidor web como eu citei.

*Existem soluções e soluções - o diferencial é saber onde e quando usar.*

Vejam também no último slide desta mesma apresentação, qual a recomendação
geral quando a questão é mitigação de DDoS:

• Mitigação híbrida – Tenha o controle nas mãos para não morrer pela vacina
         Bloqueio de ataques l3/l4 no provedor
         Bloqueio local de ataques de aplicação

• Monitoração com foco específico para DDoS
         Monitorações do NOC geralmente não atendem à agilidade que a
mitigação de um DDoS necessita

• Bom e velho Anycast

• Fuja de controles statefull na borda

ftp://ftp.registro.br/pub/gter/gter39/08-AtaquesDdosPanoramaMitigacaoEvolucao.pdf

O paper Cert.BR recém lançado aborda todas essas questões para todos os
públicos-alvo - operadoras, provedores de acesso, provedores de conteúdo,
usuário final - paper este que tem a minha contribuição.

http://www.cert.br/docs/whitepapers/ddos/

O assunto DDoS sempre rende bastante discussão na lista. Eu sugiro que a
organização do GTER monte um painel sobre isso na próxima reunião em São
Paulo.

Eu me disponho a participar para contribuir com os lessons learned desses
últimos anos, e também aprender com a experiência do que os demais vem
sofrendo. Acredito eu será de bastante valia para toda a lista, onde muitos
ainda são carentes de informação de como agir sob ataque.

Abraço!
Wilson.

Em 5 de julho de 2016 09:10, Antonio Carlos Pina <
antoniocarlospina at gmail.com> escreveu:

> Wilson, sua afirmação sobre DDoS de "gente grande"  ser UDP não é correta,
> porque DDoS de "gente grande" pode ser qualquer protocolo, o objetivo é o
> flood da capacidade do pipe. Por exemplo, pacotes TCP grandes (que não
> seriam aceitos pelo 3-way dos servidores ou firewalls) são usados do mesmo
> jeito porque "entopem" os links.
>
> Os ataques acabam sendo mais do tipo UDP porque aplicativos de ataque como
> LOIC vem com UDP como default e os "hackers" (rs) não reconfiguram, usam o
> default.
>
> Aqui um artigo que fiz sobre ataques VOLUMÉTRICOS:
>
> https://www.linkedin.com/pulse/ataques-ddos-e-mitigação-1-volumétricos-antonio-carlos-pina
> e que mostra que o protocolo não importa e é por isso que o iptables não
> fará diferença.
>
> Abs
>
> Em 4 de julho de 2016 17:57, Wilson R Lopes <wilsonlopes00 at gmail.com>
> escreveu:
>
> > 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
> > >
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>