Микротик загружает DNS процессора
Обновлено: 02.07.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.
< /p>
DNS потребляет ресурсы процессора маршрутизатора
Маршрутизатор настроен так, чтобы DNS мог проходить через веб-серверы, чтобы можно было искать и разрешать rDNS и другие записи. Это определенный блок IP, который получает свои адреса от маршрутизатора. Правила брандмауэра явно разрешают этот диапазон адресов. Мы скажем 192.168.88.0/24 и заблокируем все остальное. Это работает для веб-серверов. Но почему DNS по-прежнему сильно загружает ЦП?
Как оказалось, правило брандмауэра, разрешающее диапазон адресов сервера, также включает собственный адрес маршрутизатора! Таким образом, мы непреднамеренно добавили DNS-доступ к нашему маршрутизатору в белый список.
Чтобы решить эту проблему, мы можем добавить еще одно правило брандмауэра, которое явно блокирует трафик DNS на IP-адрес маршрутизатора. Мы используем два правила: одно для блокировки TCP, а другое для UDP.
Правила 6 и 7 — это два новых правила, которые мы только что применили. 14 и 15 блокируют вход в маршрутизатор, однако правила 8 и 9 непреднамеренно разрешают доступ к общедоступному IP-адресу маршрутизатора.
Правила брандмауэра для маршрутизатора
Результат? Загрузка нашего ЦП упала!
< /p>
Загрузка ЦП снизилась после добавления правил брандмауэра DNS.
Слишком драматично, как показано на следующем снимке экрана LibreNMS.
< /p>
График ЦП LibreNMS, показывающий общее улучшение использования ЦП
Для получения дополнительной информации об атаках DNS Amplification перейдите по следующим ссылкам.
Читайте также: