Jump to content
Калькуляторы

Непонятный трафик DNS

Добрый вечер! Стоит Ubuntu 14.04 на нём поднят DNS и вот уже несколько дней я наблюдаю странную активность в сети, в логах ни чего странного не нашёл.

Что это может быть? Пытаются взломать?

 

post-121618-071938600 1416593210_thumb.jpg

Share this post


Link to post
Share on other sites

Закрой днс снаружи.

 

+1

Следующий этап включить логгирование

А если все равно не понятно, что происходит, то используйте анализаторы траффика - tcpdump, pcap, netflow

Share this post


Link to post
Share on other sites

Добрый вечер! Стоит Ubuntu 14.04 на нём поднят DNS и вот уже несколько дней я наблюдаю странную активность в сети, в логах ни чего странного не нашёл.

Что это может быть? Пытаются взломать?

 

dns.JPG

Норм, просто ты участвовал в ДНС ДДОСе на чей то сервер в Белизе на каймановых островах. Дырка микротика тому виной. Настраивайте фаервол и гуглите Mikrotik DNS DDOS.

ЗЫ - у себя в сети вчера нашел тоже десятка два микротиков которые атаковали этот же ип.

Share this post


Link to post
Share on other sites

Добрый вечер! Стоит Ubuntu 14.04 на нём поднят DNS и вот уже несколько дней я наблюдаю странную активность в сети, в логах ни чего странного не нашёл.

Что это может быть? Пытаются взломать?

 

dns.JPG

Норм, просто ты участвовал в ДНС ДДОСе на чей то сервер в Белизе на каймановых островах. Дырка микротика тому виной. Настраивайте фаервол и гуглите Mikrotik DNS DDOS.

ЗЫ - у себя в сети вчера нашел тоже десятка два микротиков которые атаковали этот же ип.

 

При чём тут дырка микротика? Я не ярый фанат или защитник микротика, но тут вы явно неправы. Если автор не потрудился закрыть снаружи ДНС, то дело не в микротике, а в авторе.

Share this post


Link to post
Share on other sites

Хорошим тоном является запрещать то, что не разрешено явно. Хотя бы для входящих подключений.

Если на МТ нужно явно закрывать открытый по умолчанию DNS-релей, то МТ тут тоже виноват.

Правда автор пишет про Ubuntu, а на скриншоте явно Mikrotik.

Share this post


Link to post
Share on other sites

Если на МТ нужно явно закрывать открытый по умолчанию DNS-релей, то МТ тут тоже виноват.

По умолчанию, днс снаружи закрыт. Так шта мимо.

Share this post


Link to post
Share on other sites

Хорошим тоном является запрещать то, что не разрешено явно. Хотя бы для входящих подключений.

Если на МТ нужно явно закрывать открытый по умолчанию DNS-релей, то МТ тут тоже виноват.

Правда автор пишет про Ubuntu, а на скриншоте явно Mikrotik.

Всё верно, микротик выступает в роли маршрутизатора, на сервере поднят DNS и платёжные модули QIWI и Comepay. Тогда вопрос, как закрыть так, чтобы не нарушить взаимодействие с серверами QIWI и Comepay?

Share this post


Link to post
Share on other sites

Если на МТ DNS-релей не включен, тогда нужно разбираться с сервером.

Для чего на нем DNS? Разрешена рекурсия? Он обслуживает запросы снаружи?

 

По умолчанию, днс снаружи закрыт.

Он не закрыт снаружи.

Он включен или выключен.

Если включен, то для всех и закрывать его снаружи нужно дополнительно.

http://demo.mt.lv/webfig/#IP:DNS

Share this post


Link to post
Share on other sites

Если на МТ DNS-релей не включен, тогда нужно разбираться с сервером.

Для чего на нем DNS? Разрешена рекурсия? Он обслуживает запросы снаружи?

DNS для обработки запросов со стороны серверов QIWI и Comepay, так как они обращаются по доменному имени, пробовал закрывать снаружи и всё сразу отваливалось

Share this post


Link to post
Share on other sites

DNS для обработки запросов со стороны серверов QIWI и Comepay, так как они обращаются по доменному имени

Сервера QIWI и Comepay используют ваш DNS-сервер для ресолвинга?

Очень странно.

Уверен, что у них свои собственные DNS-сервера.

DNS ставится на сервер в основном в двух случаях:

1. Обслуживает выделенную зону и является авторитетным. В этом случае он не должен осуществлять ресолвинг внешних зон.

2. Является кеширующим и обслуживает локальную сеть. В этом случае он не обязан обслуживать запросы из внешних сетей.

Если у вас своя зона (свой домен) и ваш сервер заодно является ns-сервером этой зоны, то отключите в нем рекурсию.

Share this post


Link to post
Share on other sites

DNS для обработки запросов со стороны серверов QIWI и Comepay, так как они обращаются по доменному имени

Сервера QIWI и Comepay используют ваш DNS-сервер для ресолвинга?

Очень странно.

Уверен, что у них свои собственные DNS-сервера.

DNS ставится на сервер в основном в двух случаях:

1. Обслуживает выделенную зону и является авторитетным. В этом случае он не должен осуществлять ресолвинг внешних зон.

2. Является кеширующим и обслуживает локальную сеть. В этом случае он не обязан обслуживать запросы из внешних сетей.

Если у вас своя зона (свой домен) и ваш сервер заодно является ns-сервером этой зоны, то отключите в нем рекурсию.

Как тогда грамотно закрыть?

Share this post


Link to post
Share on other sites

Он не закрыт снаружи.

В дефолтном конфиге "allow remote requests" НЕ отмечена. Даже если через квиксет настроить в роли домашнего роутера, то всё равно галочки нет. Будем дальше спорить?

Share this post


Link to post
Share on other sites

В дефолтном конфиге "allow remote requests" НЕ отмечена.

И в этом случае абоненту нужно использовать сторонний DNS-сервер.

Такой подход для домашнего роутера нормальным не назовешь. Иметь на борту DHCP и DNS — это уже стандарт де-факто для CPE.

 

Как тогда грамотно закрыть?

Понятия не имею.

Нужно спрашивать у того, кто знаком с вашей сетью и кто ее настраивал.

 

dst-port=53 in-interface=твой WAN

А разве на скриншоте атака направлена на роутер?

Я так понял, что на скриншоте транзитный трафик.

Share this post


Link to post
Share on other sites

И в этом случае абоненту нужно использовать сторонний DNS-сервер.

Не нужно. Клиентам локальной сети он всё равно будет отвечать.

 

Я так понял, что на скриншоте транзитный трафик.

А я так не понял. И как теперь жить?

Share this post


Link to post
Share on other sites

Клиентам локальной сети он всё равно будет отвечать.

Не будет.

Да и как он поймет, где клиенты локальной сети?

У него нет WAN/LAN интерфейсов, все определяется конфигурацией.

Share this post


Link to post
Share on other sites

В дефолтном конфиге "allow remote requests" НЕ отмечена.

И в этом случае абоненту нужно использовать сторонний DNS-сервер.

Такой подход для домашнего роутера нормальным не назовешь. Иметь на борту DHCP и DNS — это уже стандарт де-факто для CPE.

 

Как тогда грамотно закрыть?

Понятия не имею.

Нужно спрашивать у того, кто знаком с вашей сетью и кто ее настраивал.

 

dst-port=53 in-interface=твой WAN

А разве на скриншоте атака направлена на роутер?

Я так понял, что на скриншоте транзитный трафик.

Да, это транзитный трафик из сети вышестоящего через мой маршрутизатор к железке DNS

Share this post


Link to post
Share on other sites

swat11, для своем DNS-сервере разрешите рекурсию (allow-recursion) только для отмеченных подсетей (своей локальной сети и серверов QIWI и Comepay, если им это в самом деле нужно).

Это если у вас своя зона и авторитетный сервер. Если зону обслуживает DNS-сервер регистратора — то на своем DNS нужно вообще заблокировать доступ снаружи(allow-query).

Share this post


Link to post
Share on other sites

swat11, для своем DNS-сервере разрешите рекурсию (allow-recursion) только для отмеченных подсетей (своей локальной сети и серверов QIWI и Comepay, если им это в самом деле нужно).

Это если у вас своя зона и авторитетный сервер. Если зону обслуживает DNS-сервер регистратора — то на своем DNS нужно вообще заблокировать доступ снаружи(allow-query).

Спасибо! Лишнее закрыл, всё работает :)

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.