Нагрузка на cpu telnet+managment

[weedman]

Здравствуйте.

Стал иногда замечать не понятно с чего возникшую нагрузку на процы различных микротиковских устройств.

общая нагрузка- 100%, практически все сжирают вышеуказаные потребители (данные из profile)

После перезагрузки приходит в норму, но за последние пару недель встречаю это периодически.

в микроКотиках завелись микроКротики?

[VolanD666]

Сеть ведь мониторится?

[jffulcrum]

Если порты открыты всему миру, то это развлечения Анонизмусов. Я вот последние две месяца занят проверкой и включением fail2ban и аналогичных средств, потому как там даже трафика попытками перебора съедается уже заметное кол-во. 

[Saab95]

В 08.04.2022 в 16:09, jffulcrum сказал:

Если порты открыты всему миру, то это развлечения Анонизмусов. Я вот последние две месяца занят проверкой и включением fail2ban и аналогичных средств, потому как там даже трафика попытками перебора съедается уже заметное кол-во. 

Так и будет, если делать разные подобные штучки по ограничению подключений - это же CT включать надо.

 

Самое простое средство все закрыть извне и подключаться по VPN, а лучше что бы сам роутер подключался по VPN куда-то в единый центр и никаких проблем.

[weedman]

На маршрутизаторе в центре стоит правило от перебора, после трех попыток добавляет адреса в blacklist  (input+forward)

Сеть на серых адресах

[SUrov_IBM]

Weedman, здравствуйте.

 

В 09.04.2022 в 04:45, weedman сказал:

Сеть на серых адресах

Гипотетически, может быть ситуация, что IP адреса управления коммутаторов/маршрутизаторов доступны из пользовательской (клиентской) сети. Из-за этого, что-то находящееся на ПК в пользовательской сети, может пытаться «управлять» устройством, подбирая логин/пароль. Необходимо убедиться, что управление коммутаторов/маршрутизаторов разрешено только с определённых адресов. Желательно, чтобы под управление существовал выделенный VLAN.

Так же, я бы выключил на коммутаторах/маршрутизаторах возможность взаимодействия по Link Discovery Protocol (LLDP, CDP) и подобные UPnP взаимодействия.

 

И желательно, чтобы локальные маршрутизаторы на опорной сети, не выполняли функция DNS Relay и чего-то подобного, связанного с DNS и NTP, в плане ретрансляции для клиентской сети.

[weedman]

В 09.04.2022 в 18:07, SUrov_IBM сказал:

Weedman, здравствуйте.

 

Гипотетически, может быть ситуация, что IP адреса управления коммутаторов/маршрутизаторов доступны из пользовательской (клиентской) сети. Из-за этого, что-то находящееся на ПК в пользовательской сети, может пытаться «управлять» устройством, подбирая логин/пароль. Необходимо убедиться, что управление коммутаторов/маршрутизаторов разрешено только с определённых адресов. Желательно, чтобы под управление существовал выделенный VLAN.

Так же, я бы выключил на коммутаторах/маршрутизаторах возможность взаимодействия по Link Discovery Protocol (LLDP, CDP) и подобные UPnP взаимодействия.

 

И желательно, чтобы локальные маршрутизаторы на опорной сети, не выполняли функция DNS Relay и чего-то подобного, связанного с DNS и NTP, в плане ретрансляции для клиентской сети.

Здравствуйте, SUrov_IBM

попробовал в соединениях устройств с этими проблемами отфильтравать соединения на 22 и 23 порты, соединении не увидел. Эти службы могут каким-то образом соединяться по другим портам?

[jffulcrum]

Ну как минимум еще SNMP посмотреть. Серьезную нагрузку могут создавать скрипты в расписании, особенно если их много. Проведите инвентаризацию.

[SUrov_IBM]

Weedman,

 

В 09.04.2022 в 17:38, weedman сказал:

Эти службы могут каким-то образом соединяться по другим портам?

Честно говоря, я не большой специалист по оборудованию MIKROTIK, знаю, что у данного оборудования есть "mac telnet" и ему подобные сервисы, позволяющие подключатся к устройству на L2 уровне, поэтому и посоветовал выключить Link Discovery Protocol (LLDP, CDP) и подобные UPnP взаимодействия.

 

Обычно, когда CPU маршрутизатора или коммутатора неожиданно начинает нагружаться под 100% - его что-то "щупает", используя какой-то доступный с него сервис, помимо естественной нагрузки от маршрутизации или появления "петли" в сети, если такая имеется (про петлю, скорей всего, не ваш случай).

Edited April 9, 2022 by SUrov_IBM

[SUrov_IBM]

Можно ещё предположить, что на данном маршрутизаторе / коммутаторе возникает большая фрагментация IP пакетов из-за разного значения MTU, с которой CPU просто не справляется, но это тоже достаточно редкий случай. Тут нужно смотреть счётчики фрагментации (к сожалению не знаю точно, где можно посмотреть на Mikrotik).

[Saab95]

В 09.04.2022 в 04:45, weedman сказал:

На маршрутизаторе в центре стоит правило от перебора, после трех попыток добавляет адреса в blacklist  (input+forward)

Вот как раз пример ошибочной настройки - тут лишние правила, которые замедляют работу устройства.

 

В 09.04.2022 в 14:07, SUrov_IBM сказал:

Желательно, чтобы под управление существовал выделенный VLAN.

И чем это поможет? Есть много способов сделать подмену IP адреса, лишь бы знать на какой.

 

Достаточно установить ограничения по IP в настройках админов и в настройках служб, а администраторам разрешиться подключаться к сети по VPN.

[SUrov_IBM]

Saab95, здравствуйте.

 

В 10.04.2022 в 01:33, Saab95 сказал:

И чем это поможет?

Удобством администрирования, при создании ACL (списков доступа) management сети или группы сетей (если management подсети используются на удалённых площадках, за L3 маршрутизацией), что значительно упрощает настройку нового оборудования, подлежащего администрированию, так и добавлению хостов, имеющих право администрирования данного оборудования. Разделение полезной нагрузки IP трафика и management в разные VLAN, при определённой настройке, позволяет не потерять возможность управления оборудованием, например при появлении «петли» внутри VLAN с полезным IP трафиком и/или при непреднамеренном / намеренном пересечении IP адресов полезного трафика и устройств находящихся под управлением, в противовес схеме где всё бегает в одном Native или Tag VLAN.

 

Mmanagement сеть – это не только безопасность или удобство, это такая культура, сочетающая здравый смысл, удобство и безопасность при управлении устройствами в опорной сети. ;)

[weedman]

В 09.04.2022 в 21:42, jffulcrum сказал:

Ну как минимум еще SNMP посмотреть. Серьезную нагрузку могут создавать скрипты в расписании, особенно если их много. Проведите инвентаризацию.

Здравствуйте. Скрипты отсутствуют.

 

В 10.04.2022 в 05:33, Saab95 сказал:

Вот как раз пример ошибочной настройки - тут лишние правила, которые замедляют работу устройства.

 

И чем это поможет? Есть много способов сделать подмену IP адреса, лишь бы знать на какой.

 

Достаточно установить ограничения по IP в настройках админов и в настройках служб, а администраторам разрешиться подключаться к сети по VPN.

Это клиентские устройства, поднимать к каждому устройству vpn кажется слишком радикальной идеей

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

SNMP на устройствах отключен

Edited April 10, 2022 by weedman

[SUrov_IBM]

В 09.04.2022 в 18:18, SUrov_IBM сказал:

Можно ещё предположить, что на данном маршрутизаторе / коммутаторе возникает большая фрагментация IP пакетов из-за разного значения MTU, с которой CPU просто не справляется, но это тоже достаточно редкий случай.

Кстати, как вариант – чтобы проверить, «загибается» ли CPU от проходящего через маршрутизатор трафика полезной нагрузки, в момент когда CPU загружен на 100%,  этот трафик (между клиентом и сетью Интернет) после предупреждения и согласования с клиентом можно прервать (по крайней мере в одну сторону Интернет -> клиент) для теста, отключив прохождение на вышестоящем узле.

[Saab95]

В 10.04.2022 в 02:07, SUrov_IBM сказал:

Удобством администрирования, при создании ACL (списков доступа) management сети или группы сетей (если management подсети используются на удалённых площадках, за L3 маршрутизацией), что значительно упрощает настройку нового оборудования, подлежащего администрированию, так и добавлению хостов, имеющих право администрирования данного оборудования.

Это все работает только в плоских сетях, или L2.

 

В 10.04.2022 в 02:07, SUrov_IBM сказал:

Разделение полезной нагрузки IP трафика и management в разные VLAN, при определённой настройке, позволяет не потерять возможность управления оборудованием

Как вы себе представляете это в L3 сети.

 

Например есть цепочка из роутер А - роутер Б - роутер В, каким боком можно тут притянуть vlan для администрирования? Ведь роутер А видит роутер В через роутер Б, и просто так прокинуть влан через все 3 роутера нельзя, нужно его каждый раз создавать. А для чего создавать? Что бы по этому влану связь между роутерами осуществлять - излишняя нагрузка по конфигурации. Вместо простого указания одного IP адреса на интерфейсе и адреса управления на лупбеке.

 

В 10.04.2022 в 03:32, weedman сказал:

Это клиентские устройства, поднимать к каждому устройству vpn кажется слишком радикальной идеей

По VPN подключаются администраторы к центральному роутеру, а дальше с этих IP адресов заходят в настройки роутеров, тут у каждого админа получается свой IP адрес и заходить он может только с него.

[SUrov_IBM]

Saab95, здравствуйте.

 

В 10.04.2022 в 22:27, Saab95 сказал:

Это все работает только в плоских сетях, или L2.

А у Вас сеть только на маршрутизаторах строиться?

 

В 10.04.2022 в 22:27, Saab95 сказал:

Как вы себе представляете это в L3 сети.

 

Например есть цепочка из роутер А - роутер Б - роутер В, каким боком можно тут притянуть vlan для администрирования?

Из вышеперечисленной цепочки маршрутизаторов, ни за одним из них, не находится сегмента, в котором имеется управляемое оборудование (коммутаторы)? Хм…, неужели за маршрутизатором в Вашей сети только "тупняки" или имеются управляемые коммутаторы, интерфейс управления которых находится в той же сети, что и клиентские компьютеры?

 

Дайте подумать, возможно Вы скажите что – да, поскольку поверх всего этого бегает какой-нибудь PPPoE, поэтому не принципиально, что там "тупняки" или "управляшки" в одной сети с ПК, ведь полезная нагрузка бегает в "чулке PPPoE", а диагностируется всё это путём фиксации отвала PPP сессий. ;)

 

Ладно, мы с Вами в чужой теме флуд разводим, что ни есть хорошо. И ежу понятно, что у нас разный взгляд на сете-строение.

 

В 10.04.2022 в 22:27, Saab95 сказал:

и адреса управления на лупбеке

Вот это сетевое порно мне понравилось, надо будет запомнить. Честно говоря, даже не знал, что у MIKROTIK есть Loopback. Хотя, это не отменяет того, что администрировать через Loopback, это особенный вид сетевой порнографии. ;)

[Saab95]

В 10.04.2022 в 23:41, SUrov_IBM сказал:

А у Вас сеть только на маршрутизаторах строиться?

Да, максимум между ними 1-2 коммутатора, которые адресуются из сети, по которой общаются маршрутизаторы между собой.

 

В 10.04.2022 в 23:41, SUrov_IBM сказал:

интерфейс управления которых находится в той же сети, что и клиентские компьютеры?

У нас адреса выдаются поштучно, и никакой абонентский трафик дальше своего маршрутизатора не идет, более того, даже извне обратиться по шлюзу абонента нельзя. Связка address=10.10.10.1 network=10.10.10.123 - где 123 это и есть адрес, выданный абоненту. И даже если это белый IP, но извне будет доступен только IP абонента. Маршрутизатор по белому адресу шлюза извне не доступен.

 

Далее на микротике имеется локальный бридж, на который устанавливается IP адрес управления из определенной сети. При этом на каждом роутере где терминируются абоненты создаются правила, которые запрещают с абонентских адресов заходить на подсети адресации оборудования. То есть никто, кроме администраторов (разрешенных IP) в управление оборудованием попасть не может.

 

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

 

И что бы извне попасть внутрь - нужно подключиться по VPN. Но VPN сервер настраивается на каком-то отдельном устройстве (не основном маршрутизаторе) и попытки подключения всяких хакеров и подбор паролей у VPN не создают никаких нагрузок на основную сеть.

 

Вот это и есть пример, как надо настроить сеть, что бы никаких переборов паролей, нагрузок на CPU от управления не возникало.

[weedman]

В 10.04.2022 в 15:59, SUrov_IBM сказал:

Кстати, как вариант – чтобы проверить, «загибается» ли CPU от проходящего через маршрутизатор трафика полезной нагрузки, в момент когда CPU загружен на 100%,  этот трафик (между клиентом и сетью Интернет) после предупреждения и согласования с клиентом можно прервать (по крайней мере в одну сторону Интернет -> клиент) для теста, отключив прохождение на вышестоящем узле.

на интерфейсах нагрузки особой нет. Ну и profile показывает именно указанные потребители ресурсов.

[SUrov_IBM]

Weedman,

 

В 09.04.2022 в 17:38, weedman сказал:

Эти службы могут каким-то образом соединяться по другим портам?

Для управления, в RouterOS, помимо доступа по IP адресу, существует альтернативный способ - доступ по MAC (L2), за него отвечает служба "mac-server".

 

Просто предположение - в момент 100% загрузки CPU, посмотрите, возможно производятся попытки подключений по MAC:

/tool mac-server sessions print

 

Или лучше, для теста, отключите mac-server совсем (mac-winbox, mac-telnet и mac-ping). Учтите, после отключения mac-server, доступ к управлению маршрутизатора сохраниться только по IP (L3).

 

Дополнительно: в принципе, если у Вас ещё не настроен Log сервер, можно попробовать использовать его, чтобы видеть успешные и неудачные попытки авторизации на маршрутизаторе.

[Saab95]

В 12.04.2022 в 00:22, SUrov_IBM сказал:

Или лучше, для теста, отключите mac-server совсем (mac-winbox, mac-telnet и mac-ping). Учтите, после отключения mac-server, доступ к управлению маршрутизатора сохраниться только по IP (L3).

Зачем же отключать - можно выбрать интерфейсы на которых они будут работать, например тот, через который администратор подключается.

[SUrov_IBM]

Saab95,

 

В 12.04.2022 в 01:03, Saab95 сказал:

Зачем же отключать

 

В 12.04.2022 в 00:22, SUrov_IBM сказал:

для теста, отключите mac-server

Поскольку это предположение, для теста лучше отключить mac-server совсем. Возможно, дело и не в этом. Потом, можно будет произвести целенаправленную настройку интерфейса администрирования.

[YuryD]

 Для любителей мокротиков, надо помнить что в РФ они более не... Посему полагаю, что новых прошивок для рф не будет с их стороны, поддержка тоже на уровне форумов. В связи с этим, начинают доставаться из подвалов пыльные неадекватные железяки, не только от мокротика, но и прочих.... Для хохмы - мне притащили древний адсл, с просьбой перепилить его ethrouter.

[Saab95]

Уже писал у микротика продажи в РФ были порядка 30+ процентов от всех объемов. Не думаю что они долго будут отсиживаться и ждать, когда их нишу займут другие. Вот только только они хоть немного заняли нишу домашних роутеров.

[jffulcrum]

В 13.04.2022 в 17:35, YuryD сказал:

Посему полагаю, что новых прошивок для рф не будет с их стороны

С их стороны - нет, а просто как и для Cisco появятся специализированные сайты, где будет выкладываться день-в-день.

 

В 13.04.2022 в 17:35, YuryD сказал:

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

 

"Уже не так-то просто охренеть!"

[YuryD]

 А собственнно назачем ? При помегабайтной оплате от опсосов...