Микротик загружает DNS процессора
Обновлено: 21.11.2024
Пожалуйста, войдите или зарегистрируйтесь, чтобы добавить комментарий.
Пожалуйста, войдите или зарегистрируйтесь, чтобы ответить на этот вопрос.
8 ответов
1 комментарий
Пожалуйста, войдите или зарегистрируйтесь, чтобы добавить комментарий.
0 комментариев
Пожалуйста, войдите или зарегистрируйтесь, чтобы добавить комментарий.
<р>1. обновить ROS до последней версии2. обнулить
3. настроить все через быстрый набор установив галочку на Брандмауэре.
0 комментариев
Пожалуйста, войдите или зарегистрируйтесь, чтобы добавить комментарий.
0 комментариев
Пожалуйста, войдите или зарегистрируйтесь, чтобы добавить комментарий.
2 комментария
Пожалуйста, войдите или зарегистрируйтесь, чтобы добавить комментарий.
Что нового в версии 6.22 (2014-ноября-11 14:46):
*) ovpn — добавлена поддержка нулевой криптографии;
*) файлы - позволяют удалить пустые папки на диске;
*) sntp - исправление ошибок при разрешении DNS-имен, которые вызывали
тайм-аут системного сторожевого таймера;
*) туннели eoip/eoipv6/gre/gre6/ipip/ipipv6/6to4 имеют новые функции:
туннели отключаются при отсутствии маршрута к месту назначения;
туннели отключаются на 1 минуту при обнаружении петли передачи, записывается предупреждение;
новая настройка повторных попыток проверки активности;
keepalive включен по умолчанию для новых туннелей (интервал 10 секунд, 10 повторных попыток);
*) улучшено сопоставление состояния соединения в брандмауэре - может сопоставлять несколько состояний в одном правиле, поддерживает отрицание;
*) добавлен сопоставитель состояния соединения-ната - может сопоставлять соединения, которые являются srcnatted, dstnatted или обоими;
*) исправлена 100% загрузка ЦП из-за службы DNS;
*) исправлена 100% загрузка ЦП из-за неклассифицированных служб;
*) исправлен туннель 6to4;
*) новая прошивка RouterBOOT для Metal 2SHPn для улучшения стабильности беспроводной сети;
0 комментариев
Пожалуйста, войдите или зарегистрируйтесь, чтобы добавить комментарий.
То же самое произошло около года назад. Решается закрытием порта 53.
chain input; Dst Adress @your IP
Протокол 6 (tcp)
Dst порт 53.
action drop
(или если вы хотите добавить эти адреса в список флуда и бан списка на определенное время)
И 1 правило — это то же правило для UDP
Protocol 17 (udp)
0 комментариев
Пожалуйста, войдите или зарегистрируйтесь, чтобы добавить комментарий.
Подскажите, как это правильно сделать, т.к. в моем фаерволе я забанил: input, source_adr 0.0.0.0/0 , dst. адр Савойя, 53 ткп. После этого ваша домашняя сеть начала «разрешать» адреса и т. д.
Чт, 08 ноября 2018 г., 2:40
Я заметил высокую загрузку ЦП в разное время дня, и после использования инструмента профиля выяснилось, что виноват DNS! Я проверил DNS и заметил, что кеш быстро увеличивается и заполняется странными записями.
Я разрешаю удаленные запросы, и у меня уже есть правило брандмауэра для отклонения DNS-запросов из глобальной сети.
Я отправил электронное письмо в службу поддержки по поводу этой проблемы несколько дней назад, но они не ответили!
Чт, 08 ноября 2018 г., 4:17
Чт, 08 ноября 2018 г., 4:30
Я получаю те же неизвестные записи; за исключением того, что записи предназначены для внутренних узлов в intrAnet..
У меня уже есть правила брандмауэра DNS для глобальной сети.. почему я получаю эти записи НЕИЗВЕСТНОГО типа в кэше MT DNS??
Чт, 08 ноября 2018 г., 4:37
Чт, 08 ноября 2018 г., 4:43
Чт, 08 ноября 2018 г., 5:09
Чт, 08 ноября 2018 г., 7:34
для поиска источника DNS-трафика можно использовать torch.
также, если вы действительно сделали правила брандмауэра для блокировки DNS-запросов извне, не забывайте, что порядок правил важен в брандмауэре (например, если есть правило, которое "разрешить все" или что-то в этом роде до блокировка - нет смысла блокировать правило).
Итак, если в torch источник находится вне вашей сети = ваше правило не работает. если внутри - проверьте исходный компьютер на наличие вирусов и другого ПО
Чт, 08 ноября 2018 г., 9:01
Кроме того, у меня открытая точка доступа, так что проверить на наличие вирусов будет непросто!
Пт, 09 ноября 2018 г., 1:58
Я использовал факел и ничего подозрительного не заметил!
Я не знаю, в чем причина проблемы, и я думаю, что служба поддержки MT тоже не знает, потому что они еще не ответили, а прошла уже неделя!
Пт, 09 ноября 2018 г., 4:43
То же самое здесь. У меня нет высокой загрузки ЦП DNS, но у меня ДЕЙСТВИТЕЛЬНО есть DNS-записи неизвестного ТИПА в кеше, все внутренние.
Не знаю, что их вызывает. Зараженный ПК в интранете. Как я могу отладить это, как я могу отследить корень?
Что означает буква «N» в первом столбце таблицы кэша DNS
Пт, 09 ноября 2018 г., 4:56
Хорошо, поэтому я включил ведение системного журнала для DNS и заметил,
что DNS-запросы, сделанные ПК во внутреннем домене host.mtdomain,
отправляются на DNS-серверы провайдера для ответ и получение
ответа от DNS-серверов интернет-провайдера с «ошибкой имени», возможно, это
где 0.0.0.0 добавляется с неизвестным.
Пн, 14 января 2013 г., 16:09
Я использую DNS-кэш-сервер Mikrotik и замечаю, что каждый час в течение от 30 секунд до полутора минут DNS-запросы терпят неудачу. Я все еще могу пинговать по IP, но не по имени. Глядя на профилировщик, я вижу, что в это время DNS потребляет 100% ЦП, за которым следует Flash, потребляющий много ЦП, а затем не классифицируемый. У меня есть около 10000 статических записей. Я предполагаю, что это часть проблемы. Я использую RB1200 с 1,5 ГБ ОЗУ на последней версии RouterOS 5.22. Я играл с выделением различного объема памяти для DNS безрезультатно. Верно ли, что 10 МБ — это максимальный объем памяти, который можно использовать для DNS?
Я не знаю, с чего начать устранение этой проблемы. Любые мысли о том, с чего начать отслеживание этой проблемы?
Поддержка MikroTik
Пн, 14 января 2013 г., 16:46
Что вы настроили в настройках /ip dns? (кроме статических записей) что такое использование кеша и сколько кеша у вас есть?
Пн, 14 января 2013 г., 17:02
серверы: 8.26.56.26,8.20.247.20,198.153.192.40,198.153.194.40,
8.8.4.4,8.8.8.8
динамические серверы:
разрешить удаленные запросы: yes
max-udp-packet-size: 512
cache-size: 10240KiB
cache-max-ttl: 1w
cache-used: 10062KiB
Ранее я использовал значение max-udp-packet-size до 4096 и выделял до 128 МБ для кэширования. Не похоже, чтобы решить эту проблему.
По счастливой случайности я мог наткнуться на него. Мой сервер Dude отключился в течение последнего часа, и DNS не отключился. Возможно что-то в Чуваке забивает мой DNS? Пока что на Чуваке я отключил мониторинг службы DNS на этом роутере. Любые идеи, какие другие настройки в Dude могли бы сделать это? Я переключился так, что машина теперь вообще не использует этот маршрутизатор в качестве DNS. В следующий запланированный интервал я посмотрю, изменилось ли поведение, и сообщу об этом.
Кто-нибудь знает, каким может быть максимальное использование кеша для DNS-прокси? Я видел в документации 10240 КБ, но это позволяет указать более высокие значения.
Пн, 14 января 2013 г., 19:57
Ну, я отключил кучу настроек типа DNS в Dude, и он все еще работает. Когда я нахожусь в winbox, а DNS использует 100% ЦП, в IP-> DNS он показывает, что «разрешить удаленные запросы» не отмечен, и никакие серверы не заполнены. Это связано с тем, что winbox не загрузился полностью или возможно, на самом деле это не кеширование в этот момент? Возможно, мне следует запустить DNS на отдельном сервере? Вы, ребята, рекомендуете Power DNS или BIND или что-то другое? В любом случае я хотел бы использовать свой довольно большой черный список.
Чт, 31 января 2013 г., 18:31
Frego. У меня такая же проблема с моим rb450g. Если я включу «разрешить удаленные запросы», процессор почти сразу перейдет на 100%. Теперь я возился с этим и включил эту опцию, а затем снова включил, когда в кеше было около 400 элементов. (около 200 IP-адресов использовали его для кэширования)
Я только что прошил его и снова включил. Кэш начинает пополняться, процессор загружен примерно на 10%.
Программное обеспечение версии 5.22
МАКСИМАЛЬНЫЙ размер пакета UDP – 512
размер кеша – 10 240
На данный момент у меня есть DNS-IP-адреса только моих вышестоящих провайдеров в Mikrotik. (В настройках DNS, а также в настройках Static и DHCP-сервера DNS.
Я хотел бы знать, как это исправить.
Чт, 31 января 2013 г., 21:21
Хорошо, у меня это работает уже некоторое время. В настоящее время у меня есть только около 40 IP-адресов, использующих кеш/DNS.
Примерно 350 элементов в кеше, загрузка ЦП составляет 50–60 %.
Через него проходит не более 13 МБ данных.
Пн, 18 февраля 2013 г., 5:15
У меня есть обновление, о котором нужно сообщить. Я отключил DNS на маршрутизаторе, с которым у меня была эта проблема. Однако у меня все еще есть тонна статических записей DNS. Что я заметил, так это то, что раз в день или около того, через неравные промежутки времени, процессор по-прежнему будет привязываться к 100%, а DNS потребляет все это. Я пришел к выводу, что это связано с флэш-памятью и что причиной этого должно быть количество статических записей, которые у меня есть. Я думаю, что есть какая-то служебная нить, которая может быть причиной такого довольно плохого использования ресурсов.
Пт, 06 июня 2014 г., 16:41
Та же проблема на моем RB751G-2HnD. Профиль показывает использование DNS на 80%. Запрет удаленных запросов помогает, но не решает эту проблему. Я создал правило фильтрации пакетов, которое отбрасывает DNS-запросы (UDP-трафик на порт 53) из всех подсетей, кроме локальной (192.168.0.0/24). Загрузка ЦП падает с 70-80% до 3-4%, а профилирование не показывает процент DNS. Похоже, некоторые боты используют Mikrotik в качестве DNS-сервера для каких-то целей и генерируют множество запросов.
Пт, 31 октября 2014 г., 1:08
Просто отклоняю этот старый запрос, так как наиболее вероятная причина заключается в том, что у вас есть DNS-атаки из-за пределов вашей сети, поскольку вы разрешили открывать удаленные подключения. Вам нужно включить брандмауэр.
Пт, 16 января 2015 г., 16:32
Та же проблема на моем RB751G-2HnD. Профиль показывает использование DNS на 80%. Запрет удаленных запросов помогает, но не решает эту проблему.Я создал правило фильтрации пакетов, которое отбрасывает DNS-запросы (UDP-трафик на порт 53) из всех подсетей, кроме локальной (192.168.0.0/24). Загрузка ЦП падает с 70-80% до 3-4%, а профилирование не показывает процент DNS. Похоже, некоторые боты используют Mikrotik в качестве DNS-сервера для каких-то целей и генерируют множество запросов.
Привет, seidizem, кажется, ты прав.
Я видел много сообщений в Интернете, где люди даже меняют свое оборудование, думая, что у них есть узкое место при использовании процессора.
У меня была такая же проблема на моем 951G-2HnD, и правило брандмауэра вместе nat для запросов DNS решило мою проблему.
Вт, 9 февраля 2016 г., 20:30
Здравствуйте, это работа для меня
/ip фильтр брандмауэра
add action=drop chain=input dst-port=53 in-interface=wan protocol=udp
Пт, 29 апр. 2016 г., 17:43
Пт, 29 апр. 2016 г., 18:10
Это не лучший метод. В этой статье описывается только блокировка порта 53, но на самом деле вы должны блокировать все
новые входящие пакеты из интернет-интерфейса.
Обратите внимание, что это уже значение по умолчанию. Если у вас возникла проблема, вы либо изменили
брандмауэр по умолчанию, либо изменили интернет-порт без соответствующей настройки брандмауэра.
(это происходит из-за неоптимальной настройки стандартного брандмауэра, который не хотят исправлять)
При использовании PPPoE убедитесь, что интерфейс "ether1-gateway" в брандмауэре изменен на ваш
интерфейс PPPoE в правиле, которое отбрасывает входящий трафик с этого интерфейса.
Тренер
Чт, 9 марта 2017 г., 6:53
Основная проблема DNS заключается в том, что он не поддерживает многопоточность. Он может загрузить только один процессор и легко достичь 100%. В этом случае даже мощный CCR1072 не имеет ничего против DNS-запроса. Если бы служба DNS поддерживала многопоточность, было бы очень хорошо.
Чт, 9 марта 2017 г., 13:53
Визуально эти атаки можно увидеть на вкладке "Подключения" в брандмауэре. Знание общего количества подключений при нормальном использовании — хороший способ определить аномальный трафик. Например, на моем домашнем маршрутизаторе я знаю, что все, что превышает 5 или 600 подключений, означает, что происходит что-то странное.
Когда ваши порты DNS открыты для Интернета, у вас будет несколько тысяч подключений к порту 53 UDP. На вкладке подключений вы сразу это заметите.
Тренер
Пт, 24 марта 2017 г., 9:21
В случае DNS-атаки ее очень легко остановить/заблокировать. В случае с моими точками доступа многие клиенты запрашивают DNS у маршрутизатора, и CCR1072 замедляется при выполнении запроса DNS. Но на самом деле CCR1072 может обслуживать тысячи клиентов точек доступа, за исключением роли DNS-сервера. Я реализовал отдельный DNS-сервер для его обработки, что мне не нравится, когда RouterOS поддерживает DNS-сервер.
Пт, 24 марта 2017 г., 15:42
Я думаю, что ограничение обработки DNS-запросов при обычном использовании связано не столько с использованием ЦП, сколько
ограничением количества запросов без ответа, по-видимому, какой-то таблицы внутри DNS-сервера.
Когда пересылается много запросов, в какой-то момент эта таблица переполняется.
Пт, 24 марта 2017 г., 17:14
Всем, у кого возникла эта проблема, в первую очередь нужно проверить, не используется ли ваш маршрутизатор в качестве усилителя DDoS-атак.
Как указывалось ранее в этой ветке, проверьте в таблице подключений брандмауэра DNS-трафик на интерфейсе WAN. Если вы видите DNS-трафик в/из чего-либо, кроме настроенных DNS-резольверов маршрутизатора, значит, вы подвергаетесь атаке DDoS, поскольку правила вашего брандмауэра не блокируют его.
Проблема: высокая загрузка ЦП. Профиль показывает, что большая часть этого связана с DNS.
DNS потребляет ресурсы процессора маршрутизатора
Маршрутизатор настроен так, чтобы DNS мог проходить через веб-серверы, чтобы можно было искать и разрешать rDNS и другие записи. Это определенный блок IP, который получает свои адреса от маршрутизатора. Правила брандмауэра явно разрешают этот диапазон адресов. Мы скажем 192.168.88.0/24 и заблокируем все остальное. Это работает для веб-серверов. Но почему DNS по-прежнему сильно загружает ЦП?
Как оказалось, правило брандмауэра, разрешающее диапазон адресов сервера, также включает собственный адрес маршрутизатора! Таким образом, мы непреднамеренно добавили DNS-доступ к нашему маршрутизатору в белый список.
Чтобы решить эту проблему, мы можем добавить еще одно правило брандмауэра, которое явно блокирует трафик DNS на IP-адрес маршрутизатора. Мы используем два правила: одно для блокировки TCP, а другое для UDP.
Правила 6 и 7 — это два новых правила, которые мы только что применили. 14 и 15 блокируют вход в маршрутизатор, однако правила 8 и 9 непреднамеренно разрешают доступ к общедоступному IP-адресу маршрутизатора.
Правила брандмауэра для маршрутизатора
Результат? Загрузка нашего ЦП упала!
Загрузка ЦП снизилась после добавления правил брандмауэра DNS.
Слишком драматично, как показано на следующем снимке экрана LibreNMS.
График ЦП LibreNMS, показывающий общее улучшение использования ЦП
Для получения дополнительной информации об атаках DNS Amplification перейдите по следующим ссылкам.
Читайте также: