Como faço para proteger um cartão Dell Idrac?

Question

Estou tentando bloquear completamente um servidor que tem que existir fora de um firewall / diretamente roteado para a internet e enquanto eu tenho endurecido o sistema operacional base para o melhor de minha capacidade, eu tive um momento de horror quando eu Pensei que, se o pior acontecesse e alguém conseguisse acesso, seria possível que o DRAC pudesse ser usado como uma porta dos fundos para a nossa rede de gerenciamento.

Tanto quanto eu sei, não é possível apenas conectar e executar comandos arbitrários, você precisa de um nome de usuário e senha - no entanto, se tiver tempo ilimitado e acesso root, eu suponho que uma força bruta seja possível, então Eu queria saber como eu iria garantir o DRAC?

Diferente do último recurso da tela de falha, não consigo pensar em nenhum motivo pelo qual o host local precise de acesso ao DRAC, portanto, gostaria de desativar completamente o acesso local.

Está executando o seguinte suficiente do drac:

racadm config -g cfgRacTune -o cfgRacTuneLocalConfigDisable 1

E ao executar isso, há algum lado negativo?

Eu só encontrei um pequeno guia para o antigo iDrac 5, mas, eu queria saber se algo mudou / foi adicionado desde?

atualizar

Esta é uma placa Drac (add on) dedicada com uma porta de rede dedicada e a rede de gerenciamento é uma sub-rede / rede completamente diferente.

Enquanto logado via SSH para o Drac, eu noto que você pode fazer algumas coisas, eu simplesmente quero ter certeza que se a caixa já foi enraizada / hackeada, não é possível entrar no DRAC (mesmo se for dado tempo ilimitado / força bruta do host) e, basicamente, certifique-se que é completamente 100% isolado.

    

Answer 1

Os controladores de gerenciamento remoto geralmente são problemáticos do ponto de vista da segurança, porque são sistemas com recursos completos (a série (i) do DRAC, como muitos outros, é baseada no Linux) inserida em um cartão com acesso total ao seu hardware do servidor e raramente, se alguma vez, atualizado. Acessá-los a partir de uma rede de gerenciamento dedicada (como você está fazendo) é um nível mínimo necessário de segurança.

Você se preocupa, no entanto, com o acesso de alguém ao seu servidor e o gerenciamento do DRAC em sua rede de gerenciamento. Isso é, em teoria, possível, mas difícil, porque os dados trocados entre os sistemas são razoavelmente mínimos. Se você estiver disposto a conviver com as desvantagens, desabilitar o máximo possível de comunicação entre o sistema e o DRAC reduzirá sua superfície de ataque.

Uma coisa a ter em conta é que o acesso local ao DRAC requer acesso administrativo ao SO em execução no servidor, mas não requer autenticação além disso. Se você estiver executando o Unix e executar racadm ou omconfig (ou uma das ferramentas do IPMI) como raiz, você terá acesso administrativo ao DRAC.

A principal desvantagem de desativar o acesso DRAC local com racadm config -g cfgRacTune -o cfgRacTuneLocalConfigDisable 1 é que você não poderá mais alterar a configuração do DRAC localmente, o que provavelmente terá o maior impacto potencial se você precisar reconfigurar as configurações de rede do DRAC em alguns ponto. Fazer isso exigirá cuidado, porque você pode se tornar incapaz de configurá-lo ainda mais remotamente. Tanto quanto eu posso dizer, você ainda será capaz de modificar as configurações do DRAC através do BIOS do servidor, mesmo com a configuração local desativada.

Observe que essa configuração não desativa a comunicação entre os dois; os programas locais ainda poderão ler os parâmetros de configuração do DRAC. As ferramentas baseadas em IPMI devem ter os mesmos efeitos que racadm ; todas as configurações devem ser somente leitura, mas coisas como leituras de sensores ainda funcionarão. Se você tem o software OpenManage Server Administrator instalado, você terá que ver quais configurações relacionadas a DRAC você pode alterar com omconfig (esperançosamente, nenhum).

Mxx mencionou a desativação do "SO To iDRAC Pass-through". Eu ainda não trabalhei com o iDRAC7 (tenho alguns sob encomenda), mas a documentação indica que este é um canal de comunicação mais rápido entre o sistema principal e o DRAC. Desabilitá-lo provavelmente não fará diferença funcional para você - a comunicação entre os dois ainda ocorrerá, apenas sobre o IPMI ao invés da NIC - mas também não será inconveniente (já que você quer limitar a comunicação tanto quanto possível), então eu vou em frente e desabilitá-lo.

    

Answer 2

Qual é a sua preocupação aqui? Que o seu iDRAC, configurado com um IP público, será comprometido? Ou que alguém possa comprometer a máquina host e de alguma forma usar o iDRAC para lançar ataques contra outros controladores de gerenciamento?

Para o primeiro, sugiro que você não deixe o iDRAC diretamente exposto à Internet. Use algumas ACLs no seu roteador para evitar que IPs não autorizados o acessem. Se você puder, coloque-o em um bloco de IP privado para que isso seja um problema menor.

Para o último, uma coisa semelhante funciona. Use as ACLs do roteador para garantir que o iDRAC só possa falar com as máquinas de gerenciamento autorizadas, e não com o que se parece.

    

Answer 3

A Dell recomenda que a porta do iDRAC esteja em uma LAN fisicamente dedicada e elimina muitas das preocupações que uma pessoa teria racionalmente sobre esse recurso.

    

Answer 4

Não estou familiarizado com os comandos racadm , mas no iDRAC7 gui, existe uma opção chamada OS To iDRAC Pass-through . Sua descrição é:

Use this page to enable the internal system communication channel that provides a high-speed bi-directional in-band communication between iDRAC7 and the host operating system through a shared LOM or a dedicated NIC. This is applicable for systems that have Network Daughter Card (NDC) or LAN On Motherboard (LOM) devices.

Acho que isso é algo que você gostaria de ter certeza de que está desativado.

Além disso, em vez de usar contas de usuários locais, talvez faça sentido implementar a autenticação do AD / LDAP. Dessa forma, você pode configurar notificações / bloqueios de login com falha.