bind9 logs estranhos e muitos deles

Question

Este é o meu log de bind, estes pedidos não param de vir e named usa muita cpu

    27-Sep-2018 21:34:19.693 queries: info: client 217.107.34.85#25183 (jk1l.ru): query: jk1l.ru IN ANY +E (192.168.0.200)
27-Sep-2018 21:34:19.738 queries: info: client 109.148.129.56#15451 (jk1l.ru): query: jk1l.ru IN ANY +E (192.168.0.200)
27-Sep-2018 21:34:19.796 queries: info: client 217.107.34.85#22807 (isc.org): query: isc.org IN ANY +E (192.168.0.200)
27-Sep-2018 21:34:19.805 queries: info: client 74.99.171.161#80 (jk1l.ru): query: jk1l.ru IN ANY +E (192.168.0.200)
27-Sep-2018 21:34:20.242 queries: info: client 142.112.165.146#80 (eftps.gov): query: eftps.gov IN ANY +E (192.168.0.200)
27-Sep-2018 21:34:20.243 queries: info: client 122.114.207.223#80 (aids.gov): query: aids.gov IN ANY +E (192.168.0.200)
27-Sep-2018 21:34:20.302 queries: info: client 217.107.34.85#36681 (isc.org): query: isc.org IN ANY +E (192.168.0.200)
27-Sep-2018 21:34:20.368 queries: info: client 92.11.206.190#80 (aids.gov): query: aids.gov IN ANY +E (192.168.0.200)
27-Sep-2018 21:34:20.426 queries: info: client 74.99.171.161#80 (eftps.gov): query: eftps.gov IN ANY +E (192.168.0.200)
27-Sep-2018 21:34:20.438 queries: info: client 217.107.34.85#51622 (aids.gov): query: aids.gov IN ANY +E (192.168.0.200)
27-Sep-2018 21:34:20.570 queries: info: client 70.29.66.36#47689 (eftps.gov): query: eftps.gov IN ANY +E (192.168.0.200)
27-Sep-2018 21:34:20.794 queries: info: client 109.148.129.56#37777 (eftps.gov): query: eftps.gov IN ANY +E (192.168.0.200)
27-Sep-2018 21:34:20.918 queries: info: client 74.99.171.161#80 (isc.org): query: isc.org IN ANY +E (192.168.0.200)
27-Sep-2018 21:34:20.941 queries: info: client 217.107.34.85#16138 (aids.gov): query: aids.gov IN ANY +E (192.168.0.200)
27-Sep-2018 21:34:20.961 queries: info: client 74.99.171.161#80 (isc.org): query: isc.org IN ANY +E (192.168.0.200)
27-Sep-2018 21:34:21.145 queries: info: client 74.99.171.161#80 (aids.gov): query: aids.gov IN ANY +E (192.168.0.200)
27-Sep-2018 21:34:21.156 queries: info: client 92.11.206.190#80 (isc.org): query: isc.org IN ANY +E (192.168.0.200)
27-Sep-2018 21:34:21.381 queries: info: client 68.84.209.198#80 (jk1l.ru): query: jk1l.ru IN ANY +E (192.168.0.200)
27-Sep-2018 21:34:21.382 queries: info: client 68.84.209.198#80 (jk1l.ru): query: jk1l.ru IN ANY +E (192.168.0.200)
27-Sep-2018 21:34:21.417 queries: info: client 74.99.171.161#80 (isc.org): query: isc.org IN ANY +E (192.168.0.200)
27-Sep-2018 21:34:21.421 queries: info: client 68.84.209.198#80 (jk1l.ru): query: jk1l.ru IN ANY +E (192.168.0.200)
27-Sep-2018 21:34:21.513 queries: info: client 68.84.209.198#80 (jk1l.ru): query: jk1l.ru IN ANY +E (192.168.0.200)

eu deveria estar preocupado?

    

Answer 1

Foi de fato usado para reflexão de dns & ataque de amplificação como dito por @HBruijn A solução foi restringir a recursão a clientes internos definindo acls .

    

Answer 2

Antes de mais nada, em relação às entradas de log, pode ser interessante apontar apenas o que os valores no log de consulta significam :

The query log entry first reports a client object identifier in @0x format. Next, it reports the client's IP address and port number, and the query name, class and type. Next, it reports whether the Recursion Desired flag was set (+ if set, - if not set), if the query was signed (S), EDNS was in used along with the EDNS version number (E(#)), if TCP was used (T), if DO (DNSSEC Ok) was set (D), if CD (Checking Disabled) was set (C), if a valid DNS Server COOKIE was received (V), or if a DNS COOKIE option without a valid Server COOKIE was present (K). After this the destination address the query was sent to is reported.

Olhando para uma das suas entradas (essencialmente da mesma forma):

27-Sep-2018 21:34:19.796 queries: info: client 217.107.34.85#22807 (isc.org): query: isc.org IN ANY +E (192.168.0.200)

Nós vemos + (recursão desejada) e E (EDNS) e que o qtype é ANY .
Também relevante é a ausência de T (TCP).

Esta é uma combinação que, ao escolher um nome de domínio onde eles sabem que há uma grande quantidade de registros, otimiza essencialmente para obter uma resposta tão grande quanto possível, enviada de volta através do UDP. (Recursão para poder usar qualquer nome de domínio escolhido, EDNS, para permitir respostas de > 512 bytes em UDP (facilmente falsificável).

Isso é mais ou menos ideal para amplificação de reflexões Ataques DDoS , em que o invasor envia um grande número de pequenas consultas com o endereço IP da vítima como o endereço de origem, fazendo com que o servidor envie as respostas grandes resultantes para o endereço da vítima.

As coisas óbvias para resolver isso são:

• Você provavelmente não tem uma boa razão para permitir a recursão ao público em geral, se for o caso. Você vai querer desabilitar isso! Consulte allow-recursion para limitar o acesso recursivo a apenas seus clientes pretendidos ou o recursion para desativar recursão completamente.
• O BIND também tem Limitação da taxa de resposta embutido, que permite limitar as consultas idênticas de seus clientes permitidos (veja o ponto anterior). Forçando os clientes que excedem o valor do limiar configurado para alternar para TCP (não trivialmente falsificável) para realmente obter as respostas reais ou para começar a eliminar completamente as respostas.

No quadro geral, os ISPs devem filtrar o IP de origem de seus clientes (veja BCP38 ) para limitar a possibilidade de qualquer pessoa que alegue ser um endereço IP (como é feito neste tipo de spoofing).