Безопасный удалённый доступ к консолям оборудования

 ДМИТРИЙ РЖАВИН, РАФАЭЛЬ ШАРАФАУТДИМОВ

Безопасный удалённый доступ к консолям оборудования

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

Последовательные консоли были и остаются атрибутами Intel- и RISC-серверов, коммутаторов, маршрутизаторов, устройств VPN, офисных АТС и источников бесперебойного питания. Секрет консольного доступа заключается в его простоте, широком распространении и универсальности. Можно возразить, что необходимость встроенной консоли становится со временем менее актуальной, и производители встраивают в свои продукты графические интерфейсы администрирования, доступные в любой точке сети через стандартный веб-браузер. Да, так оно и есть, но рекламируя средства визуализации, производители часто умалчивают о том, что не все функции доступны в этом режиме. Что же мешает им в этом благородном деле?

Ответ в общем-то прост. Наделяя свои устройства избыточными с точки зрения их основного назначения средствами визуализации, производителям приходится увеличивать размеры микроядра, управляющего ПО. Это в свою очередь снижает надежность этого самого ПО, и чем больше оно поддерживает графических возможностей, тем больше объем кода и тем больше вероятность сбоя. Даром ничего не дается. Достаточно вспомнить пример перехода со старой доброй ОС MS DOS на Windows 2.0 или 3.1 и какую дань нам приходится платить до сегодняшнего дня за удобства графического интерфейса Microsoft Windows. Кроме того, увеличение ПО и его функциональности снижает общую производительность устройств, что вынуждает использовать более мощные процессоры и увеличивать объем оперативной и флэш-памяти. В конечном итоге все это приводит к увеличению стоимости устройств, что не может устроить ни потребителей, ни поставщиков в условиях всеобщей ценовой конкуренции.

Поэтому сегодня мы имеем дело с компромиссными решениями, когда наиболее часто используемые и простые функции становятся доступны в виде графического интерфейса, а по-настоящему полноценный тюнинг по-прежнему доступен с управляющей консоли. Не надо также забывать, что некоторые брандмауэры конфигурируются исключительно с консольного порта, а ввод c консоли команды сброса всех текущих установок зачастую является единственной возможностью вернуть к жизни «зависшее» устройство.

История выбора

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

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

Как известно, всегда хочется иметь нечто такое, что идеально подходило бы для конкретной задачи, а не то, что в принципе может решить проблему. Распространенным решением является использование маршрутизаторов Cisco 25хх серии, которые в целом неплохо справляются с задачами терминального доступа. Но это устаревшее оборудование с максимальной плотностью 16 асинхронных портов на 1U, которое по сообщениям производителя уже давно должно быть снято с производства. Устройства 26 серии позволяют достичь нужной плотности портов, но дешевым это решение уже назвать трудно.

Очень быстро удалось выяснить, что на текущий момент несколько производителей предлагают специализированные устройства для удаленного терминального и консольного доступа с высокой плотностью портов. На первый взгляд они обладали сходными техническими характеристиками и теоретически должны были справиться с поставленной задачей. Поэтому поступившее в начале 2003 года предложение одного из российских дистрибуторов компании Digi Int. протестировать ее продукцию оказалось как нельзя кстати.

После тестирования нескольких устройств выбор пал на консольный сервер PortServer CM 32, который в ходе экспресс-тестирования удовлетворил большую часть наших требований и ожиданий. Спустя три месяца было решено приобрести один сервер и приступить к его полномасштабным испытаниям в условиях, максимально приближенных к боевым.

История внедрения

При покупке нас ожидал настоящий сюрприз: поставщик прекратил производство так понравившегося нам консольного сервера, а вместо него предлагалась новая модель – Digi CM 32 (с 32 серийными портами) и по более привлекательной цене. Внешний дизайн устройства не претерпел значительных изменений, зато на передней панели появился слот для установки карт формата PCMCIA. В перечень поддерживаемых карт входили флэш-карты, карты беспроводного доступа, модемы и сетевые карты. Эта опция показалась нам весьма полезной, поскольку позволяла создавать дополнительное соединение при построении резервной сети управления. Кроме того, теперь имелся выбор из 8, 16, 32 и 48 портовых моделей.

Текущей задачей была организация небольшой сетевой лаборатории. Как известно, людям свойственно ошибаться, и они пользуются этим свойством часто и с удовольствием. Причем это относится не только к пользователям, но и к многочисленным разработчикам, особенно ПО. Впрочем, все, кто проводил хоть сколько-нибудь сложные тесты оборудования, прекрасно понимают необходимость консольного доступа к устройствам.

Собственно, при проведении тестирования у вас есть несколько вариантов: можно притащить большой и шумящий сервер или маршрутизатор на свой рабочий стол. Если вас не побьют коллеги. Также можно несколько раз в день брать ноутбук и идти в серверную комнату. Можно поставить консольный концентратор и подключить все консоли лаборатории к нему. Мы выбрали последний вариант.

Итак, создание тестовой зоны мы решили начать с установки консольного концентратора, пары серверов, коммутатора и маршрутизатора, обеспечивающего подключение всего этого хозяйства к корпоративной сети. Все консольные кабели были подключены к консольному серверу Digi CM, кроме консоли самого Digi, которая была подключена к консольному концентратору технологической площадки – Cisco 26xx. Проблем с подключением не возникло, в сопроводительной документации есть схемы всех необходимых разводок. Для подключения консолей всех устройств использовалась стандартная кабельная разводка – обычные патч-корды 5-й категории и переходники-конструкторы RJ-45 – DB-9/DB-25, которые очень рекомендую. Переходники надо заказывать отдельно бандлами по 8 штук, но они перекрывают практически все варианты консолей DB-9, DB-25, male и female.

Начальная конфигурация Digi осуществлялась через консоль. После конфигурации сетевого интерфейса мы перешли на веб-интерфейс, поскольку поддерживается и HTTP, и HTTPS. Меню простые и достаточно удобные, так что, если тонкая настройка не требуется, использовать CLI для управления концентратором не обязательно. Вообще поставляемое с Digi ПО удовлетворяет большинству стандартных запросов, так что лезть в устройство Shell может потребоваться только в специфичных случаях. Поэтому вам не придется изучать систему команд еще одного устройства только для того, чтобы добраться до консольных портов своего оборудования. Для любителей покрутить труднодоступные ручки намекну, что внутри живет сильно обрезанный Linux (Hard Hat Distribution).

Начальная настройка устройства тоже не заняла много времени. Поменяли пароли предопределенных пользователей, выбрали настройки доступа к консолям: кроме параметров порта, можно выбрать протокол доступа к концентратору – мы выбрали SSH, включить port logging и даже настроить Digi на анализ сообщений с консоли устройства, установить фильтры доступа к консоли по IP-адресу и имени пользователя и много чего еще. Затем выделили порт и IP-адрес для каждой консоли и добавили нескольких новых пользователей.

К быстро обнаруженным неприятным особенностям можно отнести очень большое время установки SSH-соединения (хотя после соединения сессия не тормозит), а также требование выделять для обращения к каждому консольному порту уникальный IP-адрес. Хотя для подсоединения к консоли можно было использовать и основной IP-адрес устройства. Также показалось неудобным ограничение на длину имени пользователя – не менее пяти знаков. С настройкой остальных параметров пользователя все оказалось просто здорово: предусмотрены 4 предопределенных группы пользователей – User, Port Admin, System Admin, Root и 4 варианта их доступа к устройству – Web Interface, Port Access Menu, Direct Port Access, Custom Menu. Доступ к настройке параметров Digi CM, также возможен тремя путями: через Web Interface Configuration menu и интерфейс командной строки – CLI.

Надо заметить, что только Root User может использовать CLI для полного доступа к встроенной операционной системе Linux Hard Hat. System Admin может использовать CLI только для чтения, но не ввода команд. Port Admin, System Admin и Root могут производить настройку параметров консолей, как в Web Interface, так и в Configuration menu. Группа User не имеют никаких возможностей вносить изменения в действующие настройки. В дополнение к авторизации с помощью паролей (поддерживаются локальная авторизация либо сетевая: TACACS+, RADIUS, LDAP, Kerberos) можно настроить авторизацию по public key:

При этом авторизацию на доступ к портам и к Port menu можно настроить независимо от авторизации на доступ к устройству:

К числу недостатков, обнаруженных позднее, можно отнести отсутствие опции timezone, без которой использование NTP выглядело проблематично из-за перехода на зимнее/летнее время. Также к явным багам можно отнести наличие права у пользователей группы Port Admin на перезагрузку устройства. Более того, в процессе эксплуатации была обнаружена несколько забавная ситуация: через некоторое время устройство поднимало на 80-м порту вместо веб-сервера сервер SSH. Вообще перечень замечаний оказался достаточно длинным: невозможность установить на порту ACL с netmask менее чем на 256 адресов, нестабильное соединение с консолью сервера через меню и т. д. В конечном итоге список возникших у нас вопросов и пожеланий был отправлен в службу технической поддержки Digi Int. Через некоторое время был получен ответ, что они учтут наши пожелания в следующих версиях. А еще через некоторое время вышла новая версия прошивки для Digi CM, в которой наиболее неприятные проблемы уже отсутствовали.

После установки новой версии устройство стало работать стабильно, были поправлены некоторые неприятные особенности, например, выделение IP-адреса для доступа к порту стало опциональным, минимальная длина имени пользователя была сокращена до 3 знаков, кроме того, появилось множество удобных нововведений.

Дальнейшие эксперименты проводились с новой версией ПО. Теперь веб-интерфейс не предусматривает возможности установки ACL для доступа только из одной сети. В одном из писем службы поддержки сообщалось, что Digi Int. не считает необходимой реализацию возможностей создания ACL из нескольких строк в веб-интерфейсе. Вместо этого они рекомендовали настроить ACL из CLI, используя обычный синтаксис ipf, на базе которого, собственно, все и построено.

Как уже было отмечено выше, на время тестирования было принято принципиальное решение не использовать CLI, чтобы установить, чего можно добиться, не проводя специального обучения сотрудников. А поскольку рабочие станции специалистов и администраторов серверной зоны находятся в разных сетях, было решено разделить доступ по управлению устройством по портам: специалисты настраивают Digi СМ через веб-интерфейс, а администраторы серверной зоны заносят данные по подключенному оборудованию через консольное меню.

Как уже говорилось, каждый порт имеет собственный ACL, поэтому доступ к ним остается возможным для пользователей других сетей. Обращаться можно напрямую на IP-адрес и порт, назначенный данной консоли, или через меню.

Совсем короткая история

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

В заключение хочется дать один совет: по возможности при установке обеспечивайте доступность консольного сервера несколькими путями. При эксплуатации Digi CM 32 как-то раз перегрузился маршрутизатор, обеспечивающий IP-доступ к лаборатории. Локальная сеть лаборатории была multihome, что позволило нам через другое устройство попасть на Digi CM, и в конечном итоге на консоль перезагрузившегося маршрутизатора. О причинах перезагрузки поведал все тот же Digi, точнее, его port log, который хранится в буферной памяти каждого серийного порта: