Элтекс

Обнаружилась проблема с telnet, ПО 4.0.16.2. Дошло до использования его как L3, и появился незакрытый файрволом реальный IP. telnet почти сразу перестал работать. Я так понимаю, из-за попыток подбора пароля, или ещё из-за какого-то трафика. Последняя запись про telnet:

и всё. Коммутатор доступен по SNMP, можно перезагрузить, но хватает не на долго. telnet telnet-ом, его починить бы конечно, но, в любом случае, надо бы и посредством ACL закрыть коммутатор. У некоторых производителей (и у Вас, но для ESR) есть специальные правила, означающие доступ к устройству. Есть ли что-то такое для MES? Что-то не увидел пока в документации.

Вариант с management access-list пропустил как-то, но он не очень всё равно: приводит к записи в лог ненужного

Было бы не плохо, если бы можно было написать что-то вроде no logging management-acl

И вот это не хорошо:
То есть надо отключить management access-class, а за это время telnet завесить могут...

И вот ещё засада:

Как удалить?

А какой приоритет у какого правила, да ещё с учётом, что у ip access-list назначается с шагом 20, не очень очевидно. Надо ace-priority тоже показывать, как для ip access-list

И вот это не хорошо:

Хотя их можно сделать больше одного и переключать между ними. Только тут в show run, на мой взгляд, помарка:
"exit" и "management" не сдвинуты влево. Но вопрос творческий...

Но отключение логгирования нужно всё равно, это хорошо, когда сообщения на syslog сервер шлются, а локально нужное точно мусором про попытки затрётся.

Добрый день.

Логирование можно отключить командой
console(config)#no management logging deny

Если требуется выяснить почему теряется доступ, то прошу завести заявку по форме:
https://eltex-co.ru/support/
К ней приложить в момент работы
show tech-sup
Также поcле возникновения проблемы при консольном подключении (возможно стоит заранее подключиться, чтобы занять сессию)
show tech-sup
show users
show services tcp-udp
Потом перейти в дебаг-режим и выполнить (как перейти могу в рамках заведённой заявки написать)
print ip tcp sessions

Логирование можно отключить командой
console(config)#no management logging deny

Спасибо!

Если требуется выяснить почему теряется доступ

Я попробую воспроизвести на 2308. Если удастся, это проще будет для опытов последующих.

Евгений Т писал(а):Логирование можно отключить командой
console(config)#no management logging deny

Что-то подумалось. А на сколько сложно реализовать третье состояние? То есть, кроме Enabled и Disabled, было бы интересно Syslog, как мне кажется. Мне - точно.

Добрый день.

Опишите подробнее. Чтобы ничего не отбрасывало, но логировалось?

Евгений Т писал(а):Опишите подробнее. Чтобы ничего не отбрасывало, но логировалось?

На примере "management logging deny" получается, что есть два состояния: Enabled и Disabled. В первом случае сообщения "Management ACL drop packet received ..." попадают и в локальный журнал коммутатора, и уходят на syslog-сервер, если отправка на syslog-сервер настроена. Во втором случае сообщения не пишутся ни локально (что хорошо), ни отправляются на syslog-сервер. Вот думается, что иметь третье состояние, когда локально не пишется, но на syslog-сервер отправляется, если он настроен, было бы не плохо.

И совсем хорошо было бы ещё для AAA настраивать отдельно исключение на логгирование пары username-IP, но тут, наверное сложнее, и, может быть, мало кому нужно. А нужно вот для чего. У нас мониторится доступность коммутаторов по telnet, и этих попыток тоже в журнале достаточно много. Использовать "no aaa logging login", в отличие от "no management logging deny", не очень хорошо. Хотя, если бы было можно оставить запись на syslog-сервер, было бы терпимо.

Вот думается, что иметь третье состояние, когда локально не пишется, но на syslog-сервер отправляется, если он настроен, было бы не плохо.

Тут вопрос глобальнее. У нас syslog для всего функционала и в локальный журнал пишется, и отправляется на сервер. Нельзя для какого-то функционала настроить исключение. Если только по уровням логирования
console#configure
console(config)#logging buffered
emergencies System is unusable
alerts Immediate action needed (severity=1)
critical Critical conditions (severity=2)
errors Error conditions (severity=3)
warnings Warning conditions (severity=4)
notifications Normal but significant conditions (severity=5)
informational Informational messages (severity=6)
debugging Debugging messages (severity=7)

Если требуется реализация, прошу завести обращение по форме https://eltex-co.ru/support/