thetonygreen

Также прошу пояснить записи о подозрительных запросах к веб-серверу роутера Netcraze Ultra NC-1812, прошивка 5.02.B.2.0-2 (5.2 Beta 2). 4 ноября 2026 года в журнале появились следующие события. Время — Europe/Moscow: [E] Nov 4 18:19:29 ndm: Core::Scgi::Handler::GetIndex: malicious request: /wp-login.php [195.178.110.132]. [E] Nov 4 18:19:47 ndm: Core::Scgi::Handler::GetIndex: malicious request: /blog/wp-login.php [195.178.110.132]. [E] Nov 4 18:20:12 ndm: Core::Scgi::Handler::GetIndex: malicious request: /wordpress/wp-login.php [195.178.110.132]. [E] Nov 4 18:20:28 ndm: Core::Scgi::Handler::GetIndex: malicious request: /wp/wp-login.php [195.178.110.132]. [E] Nov 4 18:20:29 ndm: Core::Scgi::Handler::GetIndex: malicious request: /cms/wp-login.php [195.178.110.132]. [E] Nov 4 19:38:57 ndm: Core::Scgi::Handler::GetIndex: malicious request: /.env [2400:8d60:8::96b0:ddfd]. Для удалённого управления использую облачный доступ через доменное имя. В конфигурации присутствует: ip http security-level public ssl ip http lockout-policy enable ip http lockout-policy threshold 5 ip http lockout-policy duration 15 ip http lockout-policy observation-window 3 По характеру путей это похоже на автоматическое сканирование веб-сервера. Прошу уточнить: Означает ли malicious request, что запрос отклонён до авторизации? Какой HTTP-ответ получает отправитель? Можно ли установить, пришли эти запросы напрямую на роутер или через облачный доступ? IP-адрес в квадратных скобках — это адрес исходного клиента или возможного посредника? Распространяется ли защита от перебора на подобное сканирование путей, или она учитывает только неудачные попытки входа? Как ограничить такие обращения, сохранив возможность удалённого управления через облако? Полный журнал и самодиагностика сохранены, могу передать приватно.

Здравствуйте! Помогите разобраться с неожиданной записью об изменении пароля администратора. Устройство: Netcraze Ultra NC-1812. Прошивка: 5.2 Beta 2, 5.02.B.2.0-2, канал draft. 4 ноября 2026 года я вошёл в веб-интерфейс через KeenDNS/облачный доступ из Safari на Mac. На Mac был включён VPN. Заходил только посмотреть параметры маршрутизации: страницу смены пароля не открывал, пароль и права пользователя не менял. Сразу после входа в журнале появились записи об изменении набора паролей пользователя admin и сохранении конфигурации. Время роутера — Europe/Moscow: [N] Nov 4 15:37:13 ndm: Core::Security::Authority: started a user session [admin#112(password) from ndm+https://{http/rci}@188.187.172.37:/ agent Safari 27.0 on Mac OS X 10.15.7 via browser-cloud]. [I] Nov 4 15:37:14 ndm: Core::Security::Authenticator: password set has been changed for user "admin". [I] Nov 4 15:37:14 ndm: Core::System::StartupConfig: saving (http/rci). [I] Nov 4 15:37:17 ndm: Core::System::StartupConfig: configuration saved. [N] Nov 4 15:37:20 ndm: Core::Security::Authority: started a user session [admin#113(password) from coala://{coala/rci}@95.213.181.251:/ agent unknown on unknown via mobile-app]. [N] Nov 4 15:42:21 ndm: Core::Security::Authority: terminated a user session [admin#113(password) from coala://{coala/rci}@95.213.181.251:/ agent unknown on unknown via mobile-app]. [N] Nov 4 15:48:50 ndm: Core::Security::Authority: terminated a user session [admin#112(password) from ndm+https://{http/rci}@188.187.172.37:/ agent Safari 27.0 on Mac OS X 10.15.7 via browser-cloud]. Позже я смог снова войти с прежним паролем. В журнале есть локальный вход с Mac: [N] Nov 4 19:52:27 ndm: Core::Security::Authority: started a user session [admin#116(password) from http://{http/rci}@192.168.1.10:Home/ agent Safari 27.0 on Mac OS X 10.15.7 via browser-direct]. После обнаружения подозрительной записи я сам сменил пароль с домашнего Windows-компьютера. Поэтому второе событие в 20:03:18 объяснимо и к вопросу о неожиданном изменении не относится: [I] Nov 4 20:03:18 ndm: Core::Security::Authenticator: password set has been changed for user "admin". [I] Nov 4 20:03:21 ndm: Core::System::StartupConfig: configuration saved. Подскажите, пожалуйста: Может ли успешный вход через облако на этой сборке автоматически обновлять внутренние данные/хеши пароля и вызывать сообщение password set has been changed, хотя сам пароль остаётся прежним? Известна ли такая ошибка в 5.2 Beta 2? Может ли она быть связана с изменениями процедуры аутентификации в ветке 5.2? Можно ли по журналу или самодиагностике установить, какой именно запрос вызвал изменение в 15:37:14? Какие дополнительные данные нужно собрать? Полный журнал и файл самодиагностики сохранены; могу передать их поддержке приватно.