Я пытаюсь полностью заблокировать сервер, который должен существовать за пределами брандмауэра / напрямую подключаться к Интернету, и, хотя я максимально укрепил базовую ОС, у меня был момент ужаса, когда я подумал, что если должно случиться худшее, и кто-то смог получить доступ, возможно, что DRAC может использоваться как черный ход к нашей сети управления.
Насколько мне известно, невозможно просто подключиться и запустить произвольные команды, вам нужны имя пользователя и пароль - однако, если дать неограниченное время и root-доступ, я полагаю, что возможна грубая сила, поэтому мне было интересно как я могу защитить DRAC?
Кроме последней функции аварийного экрана, я не могу придумать ни одной причины, по которой локальному хосту даже нужен доступ к DRAC, поэтому я хотел бы полностью отключить локальный доступ.
Достаточно ли работает следующее от драка:
racadm config -g cfgRacTune -o cfgRacTuneLocalConfigDisable 1
И есть ли у этого запуска минусы?
Я смог найти только небольшое руководство по старому iDrac 5, но мне было интересно, было ли что-то изменено / добавлено с тех пор?
Это выделенная карта Drac (надстройка) с выделенным сетевым портом, а сеть управления представляет собой совершенно другую подсеть / сеть.
Во время входа в Drac через SSH я заметил, что вы можете делать некоторые забавные вещи, я просто хочу убедиться, что, если ящик когда-либо был рутирован / взломан, невозможно войти в DRAC (даже если предоставлено неограниченное time / brute force от хоста) и убедитесь, что он полностью изолирован на 100%.
Контроллеры удаленного управления, как правило, проблематичны с точки зрения безопасности, поскольку они являются достаточно полнофункциональными системами (серия (i) DRAC, как и многие другие, основана на Linux), которые размещены на карте с полным доступом к вашему серверному оборудованию и редко, если вообще, обновляется. Доступ к ним из выделенной сети управления (как вы это делаете) - необходимый минимальный уровень безопасности.
Однако вы обеспокоены тем, что кто-то получит доступ к вашему серверу, а затем сможет пройти через DRAC в вашу сеть управления. Теоретически это возможно, но сложно, поскольку данные, которыми обмениваются системы, минимальны. Если вы готовы смириться с недостатками, отключение максимально возможной связи между системой и DRAC уменьшит вашу поверхность атаки.
Следует помнить, что локальный доступ к DRAC требует административного доступа к ОС, работающей на сервере, но не требует дополнительной аутентификации. Если вы используете Unix и запускаете racadm или omconfig (или один из инструментов IPMI) как root, у вас будет административный доступ к DRAC.
Основной недостаток отключения локального доступа к DRAC с помощью racadm config -g cfgRacTune -o cfgRacTuneLocalConfigDisable 1, заключается в том, что вы больше не сможете изменять конфигурацию DRAC локально, что, вероятно, окажет наибольшее потенциальное влияние, если вам потребуется перенастроить сетевые параметры DRAC в какой-то момент. Это потребует осторожности, потому что вы можете лишиться возможности настраивать его дальше удаленно. Насколько я могу судить, вы все равно сможете изменять настройки DRAC через BIOS сервера даже при отключенной локальной конфигурации.
Обратите внимание, что этот параметр не отключает связь между ними; локальные программы по-прежнему смогут считывать параметры конфигурации из DRAC. Инструменты на основе IPMI должны иметь те же эффекты, что и racadm; все настройки должны быть доступны только для чтения, но такие вещи, как показания датчиков, будут работать. Если у вас установлено программное обеспечение OpenManage Server Administrator, вам нужно будет посмотреть, какие настройки, связанные с DRAC, вы можете изменить с помощью omconfig (надеюсь, нет).
Mxx упомянул об отключении «OS To iDRAC Pass-through». Я еще не работал с iDRAC7 (несколько у меня заказано), но в документации указано, что это более быстрый канал связи между основной системой и DRAC. Его отключение, вероятно, не повлияет на вас функционально - связь между ними будет по-прежнему осуществляться только через IPMI, а не через сетевую карту, но это также не доставит вам неудобств (так как вы хотите максимально ограничить связь. насколько это возможно), поэтому я бы отключил его.
Dell рекомендует, чтобы порт iDRAC находился в физически выделенной локальной сети, и снимает многие опасения, которые могли бы возникнуть по поводу такой функции.
Что вас здесь беспокоит? Что ваш iDRAC, настроенный с общедоступным IP-адресом, будет взломан? Или что кто-то может взломать хост-машину и каким-то образом использовать iDRAC для запуска атак на другие контроллеры управления?
Что касается первого, я бы посоветовал вам не оставлять iDRAC напрямую доступным в Интернет. Используйте некоторые ACL в вашем маршрутизаторе, чтобы предотвратить доступ к нему неавторизованных IP-адресов. Если можете, поместите его в частный IP-блок, чтобы это не было проблемой.
Для последнего работает аналогичная вещь. Используйте списки управления доступом маршрутизатора, чтобы гарантировать, что iDRAC может взаимодействовать только с авторизованными управляющими машинами, а не с какими бы то ни было чертами.
Я не знаком с racadm команды, но в iDRAC7 gui есть опция, называемая OS To iDRAC Pass-through. Его описание:
Используйте эту страницу для включения внутреннего системного канала связи, который обеспечивает высокоскоростную двунаправленную внутриполосную связь между iDRAC7 и операционной системой хоста через общий LOM или выделенную сетевую карту. Это применимо для систем, в которых есть дочерняя сетевая карта (NDC) или устройства LAN на материнской плате (LOM).
Я думаю, что это то, что вы хотели бы отключить.
Кроме того, вместо использования локальных учетных записей пользователей, возможно, имеет смысл реализовать аутентификацию AD / LDAP. Таким образом вы можете настроить уведомление / блокировку неудачного входа в систему.