[GTER] RES: DNS Alto Trafego

Jefferson Gondek jefferson.gondek at iveloz.net.br
Wed Mar 1 17:45:26 -03 2017


AAAA = consulta IPv6, se não estou enganado.

Caso esteja usando BIND e não tenha rede IPv6 implementada ainda, 
desabilite o suporte a IPv6 no default do bind (é um parâmetro que vc 
define). Ele vai parar com essas requisições e manter apenas as A (IPv4).

Att,

Jefferson


Em 01/03/2017 16:15, Eduardo Schoedler 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
>
>

-- 



More information about the gter mailing list