[GTER] RES: DNS Alto Trafego

[Douglas Fischer]

Se entendi direito, ele está perguntado AAAA, mas com o conteúdo que seria
da PTR.

Isso tem cada de algo inadequado no unbound, nunca ví nada assim no BIND.


Em 1 de março de 2017 16:15, Eduardo Schoedler <listas at esds.com.br>
escreveu:

> Aqui eu encontrei vários IPs fazendo consultas nesse formato:
>
> unbound[27909:1] info: 20x.xxx.xxx.x 256.053.043.313. AAAA IN
> unbound[27909:0] info: 20x.xxx.xxx.x 344.175.372.001. AAAA IN
> unbound[27909:5] info: 20x.xxx.xxx.x 047.146.034.300. AAAA IN
> unbound[27909:6] info: 20x.xxx.xxx.x 245.240.376.105. AAAA IN
> unbound[27909:5] info: 20x.xxx.xxx.x 027.345.213.371. AAAA IN
> unbound[27909:6] info: 20x.xxx.xxx.x 022.316.327.353. AAAA IN
> unbound[27909:3] info: 20x.xxx.xxx.x 374.070.353.162. AAAA IN
> unbound[27909:7] info: 20x.xxx.xxx.x 063.310.246.317. AAAA IN
> unbound[27909:0] info: 20x.xxx.xxx.x 071.264.101.012. AAAA IN
> unbound[27909:0] info: 20x.xxx.xxx.x 070.327.054.154. AAAA IN
> unbound[27909:2] info: 20x.xxx.xxx.x 100.013.212.362. AAAA IN
> unbound[27909:5] info: 20x.xxx.xxx.x 375.124.343.322. AAAA IN
> unbound[27909:2] info: 20x.xxx.xxx.x 317.014.103.032. AAAA IN
> unbound[27909:0] info: 20x.xxx.xxx.x 100.013.212.362. AAAA IN
> unbound[27909:2] info: 20x.xxx.xxx.x 317.014.103.032. AAAA IN
> unbound[27909:0] info: 20x.xxx.xxx.x 161.324.253.144. AAAA IN
>
> Estou tentando bolar uma regra no iptables para dropar essas consultas.
> Com módulo string acho que não consigo, talvez com u32...
>
> Abs.
>
> Em 1 de março de 2017 11:32, Douglas Fischer
> <fischerdouglas at gmail.com> escreveu:
> > Rapaz, nesse feriadão é o terceiro caso parecido que escuto!
> >
> > Aposto que se olhar para as consultas, vais identificar o problema!
> >
> > No caso de um amigo, as respostas das consultas continham +/- 300
> Endereços
> > IPv4.
> > Isso gera um volume de tráfego bastante considerável.
> >
> > O que fizemos para remediar foi identificar os domínios as consultas
> > "malvadas" e subir zonas equivalentes a esses domínios no BIND Recursivo.
> >
> >
> > Em 1 de março de 2017 09:45, Bruno Zerves / Pulsive Digital Experience <
> > bruno at pulsive.com.br> escreveu:
> >
> >> O pessoal da Parks nos recomendou desativar o DNS Relay das ONUs e
> setar o
> >> nosso DNS direto no DHCP Server de cada uma. Mas não acredito que isso
> >> possa
> >> causar todo esse tráfego de cada cliente e o sistema estava funcionando
> já
> >> faz uns 2 anos e nunca teve esse problema, por isso também creio numa
> >> infecção. Posto o log do DNS aqui na sequência...
> >>
> >> Obrigado
> >>
> >> -----Mensagem original-----
> >> De: gter [mailto:gter-bounces at eng.registro.br] Em nome de Frederico A C
> >> Neves
> >> Enviada em: quarta-feira, 1 de março de 2017 09:22
> >> Para: Grupo de Trabalho de Engenharia e Operacao de Redes
> >> <gter at eng.registro.br>
> >> Assunto: Re: [GTER] DNS Alto Trafego
> >>
> >> Bruno,
> >>
> >> On Tue, Feb 28, 2017 at 11:36:54PM -0300, Bruno Zerves / Pulsive Digital
> >> Experience wrote:
> >> > Boa noite pessoal, venho aqui pedir alguma dica de vocês, pois estamos
> >> > esgotando as tentativas de solução.
> >> >
> >> >
> >> >
> >> > Temos um cenário de um provedor com cerca de 500 clientes conectados
> >> > simultaneamente ao concentrador. De uns tempos pra cá, percebemos que
> >> > pelo menos 100 clientes (nem sempre os mesmos 100) enviam requisições
> >> > ao DNS (Feito em Debian + BIND) que chegam a dar 4, 5mbps cada
> >> > cliente, gerando um tráfego grande e causando lentidão na entrega das
> >> requisições reais.
> >> >
> >> >
> >> >
> >> > O servidor está bloqueado para fora da rede do provedor, mas parece
> >> > que os próprios clientes estão atacando.
> >> >
> >> >
> >> >
> >> > Como este servidor está virtualizado, refizemos e redirecionamos um
> >> > novo, durou poucas horas, e voltou a apresentar os sintomas.
> >> >
> >> >
> >> >
> >> > Este DNS estava rodando à uns 2 anos sem problemas, e seguindo todas
> >> > as recomendações de boas práticas.
> >> >
> >> >
> >> >
> >> > Alguém já passou por isso ou tem uma dica pra tentar resolver? A única
> >> > forma que achamos de parar o tráfego foi desabilitando a recursão, mas
> >> > daí ninguém consegue consultar...
> >> >
> >>
> >> Você tem alguma coleta das consultas que estes clientes tem enviado
> para o
> >> servidor?
> >>
> >> Os sintomas que você reporta são fortes indícios de que estes clientes
> >> estão
> >> infectados com algum tipo de artefato malicioso.
> >>
> >> Como medida paliativa, e de posse das características das consultas,
> você
> >> pode tentar usar RPZ[1] para mitigar o problema.
> >>
> >> Como solução definitiva, identificado o problema, tente ajudar seus
> >> clientes
> >> a removerem o artefato de suas máquinas/CPEs etc...
> >>
> >> >
> >> > Obrigado desde já e desculpem se não é o local mais adequado.
> >> >
> >> >
> >> >
> >> > Atenciosamente,
> >> >
> >> > Bruno
> >> >
> >> > --
> >> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >>
> >> Fred
> >>
> >> [1] https://en.wikipedia.org/wiki/Response_policy_zone
> >> --
> >> gter list    https://eng.registro.br/mailman/listinfo/gter
> >>
> >> --
> >> gter list    https://eng.registro.br/mailman/listinfo/gter
> >>
> >
> >
> >
> > --
> > Douglas Fernando Fischer
> > Engº de Controle e Automação
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
>
>
>
> --
> Eduardo Schoedler
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>



-- 
Douglas Fernando Fischer
Engº de Controle e Automação