2 pontos por GN⁺ 2024-09-04 | 1 comentários | Compartilhar no WhatsApp
  • Mesmo depois de os servidores convergirem para hardware de uso geral parecido com PCs, o gerenciamento fora de banda para lidar com falhas, boot e instalação remota continua sendo um recurso central que diferencia clientes e servidores
  • IPMI não é nome de produto, mas uma especificação; sistemas de gerenciamento de fornecedores como HP iLO e Dell DRAC se sobrepõem ao IPMI, mas têm histórias próprias e recursos estendidos
  • O IPMI roda no BMC e fornece tanto interfaces fora de banda baseadas em rede ou serial quanto interfaces in-band via drivers do sistema operacional
  • Implementações reais oferecem web UI, SSH, VNC, comandos baseados em UDP 623, console remoto, mídia virtual e controle de sensores, energia, ventoinhas e watchdog, mas são especialmente vulneráveis em termos de exposição de segurança
  • Intel ME e Intel AMT são tecnologias semelhantes no lado dos PCs cliente, mas por causa das exigências de AMT e vPro, a ideia comum de que dispositivos de consumo em geral permitem acesso de rede sideband está, na maior parte, errada

Até os servidores virarem “grandes computadores”

  • A computação cliente-servidor surgiu como uma evolução da computação por compartilhamento de tempo, em que vários terminais se conectavam a um único computador
  • Os terminais não precisavam ter a mesma arquitetura do computador, e essa visão continuou nos primeiros sistemas cliente-servidor
  • Em meados dos anos 1990, a revolução do PC criou uma monocultura WinTel no lado cliente, mas até os anos 2000 ainda era comum que servidores usassem sistemas operacionais e arquiteturas separados
    • A combinação de SPARC e Solaris era amplamente usada em servidores
    • A arquitetura de minicomputadores da IBM e seus vários sistemas operacionais também eram plataformas importantes de servidor
    • Java contribuiu para aplicações corporativas ao permitir reutilização de código entre backends Solaris/SPARC e clientes Windows/x86
  • Com o tempo, arquiteturas dedicadas para servidores passaram a ficar cada vez mais em desvantagem na competição de custo e desempenho com a arquitetura de PC
  • O software de servidor também migrou de uma ênfase em escala vertical e alta disponibilidade para escala horizontal e exigências de confiabilidade mais flexíveis, reduzindo as vantagens dos computadores de nível corporativo
  • Hoje, os diferenciais dos servidores estão principalmente em SMP multi-soquete e NUMA, controladores e topologias de armazenamento complexos, e recursos de gerenciamento fora de banda

O que o gerenciamento fora de banda resolve

  • Gerenciamento fora de banda é a capacidade de acessar um servidor por meio de um computador de administração separado, mesmo quando o sistema operacional ou componentes de uso geral não estão funcionando normalmente
  • SSH é um exemplo típico de gerenciamento in-band fornecido por software em cima do sistema operacional
  • O gerenciamento fora de banda é feito por uma pilha separada de hardware e software e, tradicionalmente, não exigia cooperação do sistema operacional nem da CPU
  • Hoje, essa função aparece com mais clareza no console remoto dos servidores
    • Ele funciona como um IP KVM embutido, permitindo operar o servidor como se um monitor e teclado locais estivessem conectados
    • O recurso de “mídia virtual” permite enviar um arquivo ISO e fazê-lo aparecer como um dispositivo físico, o que é útil para instalar o sistema operacional
  • Esses recursos não são uma ideia nova, e funcionalidades semelhantes podem ser encontradas ao longo de toda a história da computação empresarial
  • Servidores relativamente modernos normalmente já incluíam vários níveis de recursos de gerenciamento
    • Interfaces locais para operadores, como LCDs ou LEDs que mostram o estado do hardware
    • Console serial para acessar o bootloader inicial e sistemas persistentes de gerenciamento em baixo nível
    • Sistemas de gerenciamento de nível mais alto para administrar remotamente a carga de trabalho da máquina
  • Ainda hoje existem indicadores de falha no painel frontal e funções de gerenciamento serial, mas a variedade de componentes redundantes substituíveis em operação é menor do que no passado

A relação entre IPMI e BMC

  • IPMI não é um produto específico, mas a especificação Intel IPMI
  • Os principais fabricantes de servidores geralmente têm sua própria implementação de IPMI e usam nomes como HP iLO e Dell DRAC
    • Em alguns casos, esses sistemas existiam antes do IPMI, então chamá-los de “apenas IPMI” não é preciso
    • Fabricantes mais novos costumam usar o pacote padrão de fornecedores de firmware e chamá-lo simplesmente de IPMI
  • O software de IPMI normalmente roda em um processador chamado BMC (Baseboard Management Controller)
  • Às vezes, os termos IPMI e BMC são usados de forma intercambiável
  • LOM (Lights-Out Management) é, em geral, um termo mais antigo, mas continua vivo porque a HP(E) ainda usa o nome Integrated Lights-Out
  • É preciso distinguir o BMC do SMC (System Management Controller), que em computadores cliente cuida de tarefas como controle da velocidade das ventoinhas
    • Os dois componentes têm relação histórica
    • Em servidores, o BMC costuma cuidar da maior parte dessas funções
  • O IPMI especifica duas formas de acesso
    • Interfaces fora de banda por rede ou conexão serial
    • Interfaces in-band acessadas pelo sistema operacional via drivers
  • Graças ao acesso in-band, ferramentas como ipmitool no Linux podem interagir com o IPMI a partir do sistema operacional em execução
  • Como o IPMI é um sistema de gerenciamento independente, mas também fornece uma interface local ao sistema operacional por conveniência, entender essa estrutura ajuda a reduzir a confusão de termos

Como o IPMI é usado na prática e suas limitações de segurança

  • Produtos de IPMI oferecem cada vez mais seus recursos por meio de aplicações web
  • Muitos produtos também têm software cliente dedicado, mas há uma tendência de migração das funções para apps web embutidos
  • A qualidade das interfaces web varia muito entre implementações e, em geral, é ruim
  • A maioria dos servidores tem uma interface Ethernet dedicada identificada como IPMI ou management
  • A forma mais desejável de implantar a interface de gerenciamento IPMI é em uma rede física dedicada, por razões de segurança e confiabilidade
    • Mesmo que a rede principal tenha problemas de desempenho ou estabilidade, o IPMI deve continuar acessível
    • Uma rede física dedicada consome tempo, espaço e dinheiro
  • Um meio-termo comum é montar a rede de gerenciamento como uma VLAN sobre equipamentos de rede comuns
    • Ela funciona como uma rede privada independente, mas o equipamento real é compartilhado
    • O isolamento é implementado por software
  • Para evitar cabos extras, o IPMI também oferece rede sideband
    • O BMC se comunica diretamente pela mesma NIC usada pelo sistema operacional
    • A NIC faz parecer que existem duas interfaces diferentes, e o tráfego de IPMI se mistura ao mesmo fluxo de pacotes do tráfego do host, mas usa um endereço MAC diferente
    • A separação entre tráfego de IPMI e tráfego de aplicação fica mais fraca, o que exige atenção de segurança
  • Muitas implementações de IPMI já apresentaram problemas graves de segurança e não devem ficar acessíveis a usuários não confiáveis
  • Os recursos de rede variam conforme a implementação, mas em comum há uma interface padrão baseada em UDP 623 usada para descoberta e comandos básicos
  • SSH e interface web são comuns, e VNC também é usado com frequência no console remoto
  • Funções básicas que podem ser executadas via IPMI incluem
    • Ver a lista de módulos de hardware em nível de FRU ou número de peça do fornecedor
    • Controlar funções básicas de hardware, como sensores, estado de energia e ventoinhas
    • Usar um temporizador watchdog padrão
  • O watchdog pode ser combinado com software sobre o sistema operacional para fazer o servidor reiniciar quando uma aplicação entrar em estado anormal
  • O tempo limite do watchdog deve ser configurado longo o bastante para permitir a inicialização do sistema e tempo para desativá-lo após o login

Intel ME, AMD ST, AMT e a exceção dos PCs cliente

  • IPMI é comum em servidores corporativos, mas raro em computadores cliente comuns e em máquinas pequenas ou de baixo consumo
  • Intel ME e AMD ST são exceções próximas de um controlador de gerenciamento OOB presente em quase todos os processadores Intel e AMD
  • Intel ME é um componente que viabiliza o Intel AMT (Active Management Technology)
  • O AMT foi uma tentativa de levar gerenciamento fora de banda para máquinas cliente e oferece a maior parte das funções semelhantes ao IPMI
  • O AMT não teve grande sucesso, principalmente porque a Intel restringiu a maior parte de seus recursos ao uso com plataformas caras de gerenciamento corporativo
  • Existem clientes AMT de código aberto, mas continua existindo o problema de encontrar máquinas que realmente permitam usar AMT
  • O gerenciamento sideband do AMT gerou preocupação na comunidade de segurança, mas na prática ele só é possível quando todas as condições abaixo são atendidas
    • O processador precisa ser compatível com AMT
    • O chipset da placa-mãe precisa ser compatível com AMT
    • A NIC precisa ser compatível com AMT
    • Os três dispositivos ficam limitados a produtos Intel com selo vPro
  • Só o fato de NICs Intel não serem populares em dispositivos de consumo já faz com que o acesso sideband seja raro
  • O vPro fica restrito a processadores e chipsets relativamente mais avançados
  • A “verdade” amplamente difundida de que o Intel ME em dispositivos de consumo pode ser acessado por rede sideband geralmente não está correta, e a razão não é apenas o licenciamento de software da Intel
  • O próprio Intel ME, sem AMT, quase não oferece recursos de gerenciamento fora de banda, mas parece servir como uma base conveniente para hospedar e gerenciar componentes de execução confiável como Secure Boot e DRM
  • O Intel ME não pode ser auditado por terceiros e já teve vulnerabilidades de segurança importantes no passado
  • SoCs ARM modernos voltados ao consumidor também têm capacidades semelhantes, então isso não é um problema limitado a um fornecedor específico de x86

1 comentários

 
GN⁺ 2024-09-04
Opiniões do Hacker News
  • Há alguns pontos que diferem um pouco das informações mais recentes. A Intel ficou atrás da AMD no conjunto de CPUs/GPUs, e só se destacam exceções bem adequadas a usos de baixo consumo e sem ventoinha, como a linha N100
    Por isso, CPUs Intel tendem a ser compradas principalmente por organizações que precisam atualizar ambientes existentes com CPUs do mesmo fabricante; por exemplo, em algo como o EVC do vSphere, quando se quer fazer novos processadores se comportarem como modelos antigos do mesmo fabricante para permitir migração a quente entre arquiteturas de CPU e minimizar interrupções durante a troca de hardware
    Fora isso, o clima é de que quase todo mundo está indo para CPUs AMD, que são melhores e mais baratas em relação ao desempenho de processamento. NICs Intel são, de modo geral, boas, e estão aparecendo cada vez mais também em dispositivos de consumo. A exceção é a X710: embora esteja em listas de compatibilidade “enterprise”, como as da VMware, por mais de um ano causou falhas silenciosas de rede ou crashes por problemas de driver
    Para organizações que compram servidores, a Supermicro pode ser, em geral, uma boa opção. É mais barata e oferece maior flexibilidade em fator de forma, chassis, componentes, número de slots etc., além de ser geralmente confiável, mas o suporte é menos estável do que o suporte teórico da Dell/HPE, então funciona melhor em configurações redundantes
    Além disso, a especificação IPMI está sendo substituída pelo Redfish, que fornece uma API mais completa, segura, padronizada e adequada. Se for um servidor mainstream de alguns anos para cá, é bem provável que tenha Redfish junto com IPMI
    Recentemente, a empresa de pesquisa para venda a descoberto Hindenburg publicou um relatório expondo pontos suspeitos da Supermicro, mas o hardware em si ainda é de primeira linha e também é usado por grandes provedores de cloud: https://hindenburgresearch.com/smci/

    • Já mexi tanto com placas Supermicro quanto com ASRock Rack para workstation, e a placa da Supermicro não parecia um produto de 2024, mas sim uma placa feita em 2005
      Sem suporte a suspensão ACPI, suporte ruim a ventoinhas de 4/3 pinos — ventoinhas de 3 pinos sempre ficam a 100% —, interface web de IPMI igual à dos anos 2010, posicionamento de NVMe que impede o uso de dissipadores, e um monte de jumpers opacos sem nem rótulos na placa
      Já a placa ASRock Rack equivalente era incomparavelmente melhor
    • O problema da Supermicro não é o relatório de venda a descoberto, mas o vazamento das chaves de Secure Boot. A raiz de confiança foi quebrada, tornando impossível proteger adequadamente uma quantidade considerável de hardware
      https://arstechnica.com/security/2024/07/secure-boot-is-comp...
    • CPUs Intel recentes não parecem ruins nas especificações, mas na prática têm um problema de queimar
      Conforme o processo fica mais fino, problemas de vida útil inevitavelmente se tornam maiores, então isso não é tão surpreendente. Problemas como defeitos de migração podem virar um trouble grande com mais facilidade. Dizem que foi um problema de microcódigo exigindo voltagem excessiva da placa-mãe, e isso também está certo, mas também é verdade que os chips estão ficando mais sensíveis a mudanças no ambiente
      No passado eu gostava do desempenho e da compatibilidade com Linux das NICs Intel, e também gostava dos SSDs Intel. Só que era preciso perceber que eles tinham desempenho um pouco melhor na faixa P95~P99 do que concorrentes baratos, e o momento em que o computador parece lento e irritante é justamente esse P95~P99. Uma das razões pelas quais eu gostava e ao mesmo tempo não gostava da Anandtech era que ela frequentemente deixava passar esse ponto essencial
    • Eu gostaria que as PSUs da Supermicro fossem acessíveis via PMBus sem o utilitário IPMI proprietário, mas não são. Além disso, ele é exclusivo para x86, então não há como fazer interface em ppc64el
      Se fosse open source, daria para compilar facilmente
      https://www.supermicro.com/en/solutions/management-software/...
    • Estou automatizando com Redfish para manter os certificados SSL do IPMI atualizados, mas o processo de importar um novo certificado exige uma pequena mágica diferente em cada implementação Redfish de cada fornecedor
      Só para fazer upload e substituição de certificados — nome do certificado, codificação etc. — temos um conjunto de módulos Python para lidar com as diferenças esquisitas de cada fornecedor. Em tese, isso deveria terminar com algumas requisições PUT padronizadas que funcionassem em qualquer lugar, e a documentação da API Redfish também leva a crer nisso, mas a realidade não é assim
      Por isso, é difícil concordar que seja padronizado ou utilizável, e é tão irritante quanto na época em que era preciso manipular diretamente a interface web
  • Uma opção para quem diz que, se você insiste em computadores compactos ou de baixo consumo, precisa viver sem IPMI, é usar uma placa Supermicro MicroATX baseada em Atom com IPMI e resfriá-la silenciosamente com pequenas ventoinhas Noctua em um chassis 1U de pouca profundidade
    Uso um modelo antigo em casa, e ele era silencioso e pequeno, muito mais atraente do que os modelos Dell R2x0 que eu tinha visto. Por ter recursos de servidor como IPMI e RAM ECC, era melhor que um mini PC, e mais estável do que um RasPi improvisado
    Pessoalmente, eu não conectaria a porta IPMI à LAN principal, mas, isolada, ela era bastante útil e divertida para brincar

    • A ASRock Rack tem placas que usam chips AM4/AM5 padrão em chipsets como X470, X570 e X670, oferecendo muitos recursos de servidor como IPMI e ECC. No lado da AMD, ECC já parece ser bem comum
      Coloquei um 5950X na minha placa, mas também a usei bem por um tempo com um 5600G. Como é mATX/ATX, cabe em gabinetes comuns e fontes comuns, sem precisar de rack
    • IPMI e outras interfaces de gerenciamento são separados em uma VLAN de gerenciamento dedicada e ficam acessíveis apenas por meio de uma VPN dedicada
    • Tenho várias dessas placas Atom. Foi a primeira coisa que me veio à cabeça assim que li o texto, e o texto demorou bastante até dizer que IPMI significava equipamento grande
  • Se você quiser adicionar acesso remoto a um equipamento sem IPMI, dá para experimentar algo como o NanoKVM RISC-V de US$ 30
    Ele oferece captura e codificação HDMI, Ethernet/Wi-Fi, controle de energia ATX e roda uma distribuição Linux comum
    https://www.aliexpress.com/item/1005007369816019.html
    https://github.com/sipeed/NanoKVM

    • No momento estou testando um kit completo ligado a um mini PC de brinquedo. É um pequeno dispositivo RISC-V que consome só alguns watts e ainda não tem Wi-Fi, mas captura a saída HDMI para uma UI web e é emulado no PC como quatro dispositivos
      Funciona como teclado USB, mouse USB, um pendrive USB que armazena ISOs de boot para instalação/recuperação, e também como uma NIC USB bem boa
      Dá para usar essa NIC USB no PC para expor apenas a porta SSH de gerenciamento, então fica parecendo que o PC ganhou uma espécie de interface IPMI dedicada. O software mais recente também inclui suporte a WireGuard e Tailscale, permitindo conectar diretamente por VPN
      Ainda há pequenos problemas, mas os desenvolvedores estão corrigindo rapidamente
    • Para usar o breakout de controle de energia ATX, é preciso a versão completa de US$ 60. Esse breakout se conecta a um conector USB-C físico meio estranho que carrega os sinais ATX
      Você até poderia fazer um por conta própria, mas conectores USB-C são realmente péssimos de soldar
    • Fico me perguntando por que o AliExpress não vende esse dispositivo para clientes nos EUA
    • Do lado do software, por não ser open source, ele não é melhor do que as alternativas
      É só mais um KVM não confiável
  • No fim dos anos 1990, instalei vários servidores fabricados pela Intel. Eles eram enviados como computadores “barebone” baseados na plataforma de referência da Intel, com RAM e armazenamento adicionados pelo integrador, e faziam gerenciamento lights-out com o LANDesk Server Manager Pro e a “Emergency Management Card” (EMC)
    Eram máquinas da era Pentium Pro até os primeiros Pentium II, como AP450GX, BB440FX e RC440FX
    Considerando que código de referência da plataforma x86 nunca morre, eu frequentemente me perguntava quanto da estrutura atual do IPMI veio desse hardware e desse software. A senha padrão da Intel LANDesk Emergency Management Card era “calvin”, uma senha que deve ser familiar para quem já lidou com os primeiros Dell iDRAC. Não acho que seja coincidência
    A propósito, ouvi de um funcionário da Intel que o codinome da EMC era “Hobbes”, mas não consegui encontrar isso documentado
    Versões da EMC aparecem com frequência no eBay, e havia versões ISA e PCI. Era um PC x86 em uma placa, e algumas ou todas tinham um UPS integrado. Havia slots PCMCIA para adicionar gerenciamento out-of-band, uma fonte de alimentação externa, e a placa se conectava à placa-mãe do servidor pela interface de barramento do host da própria placa e por conectores proprietários
    Baixei e examinei o firmware de algumas versões da EMC, e algumas pareciam máquinas DOS embarcadas. Isso continua sendo um projeto de brincadeira que pretendo fazer um dia, então ainda não fiz engenharia reversa do código nem tentei rodá-lo no qemu, mas gostaria de fazer isso
    Terceiros que vendiam plataformas de referência da Intel, como Unisys, Fujitsu, ALR/Gateway e NCR, também ofereciam essa placa. Quando vejo essa placa em anúncios, é uma boa pista de que se trata de uma plataforma de referência da Intel, e referências a “LDSM” também são uma pista
    Se alguém conhecer essa linhagem, seria realmente interessante
    https://www.intel.com/pressroom/archive/releases/1998/ld1030...
    https://web.archive.org/web/20240903131630/https://www.ebay....

  • O Intel ME e o AMD PSP têm um papel importante em colocar a CPU em um estado parecido com um PC x86 no qual o firmware do host possa de fato ser executado
    A complexidade da inicialização ficou tão alta que faz mais sentido tratá-la via software em um núcleo embarcado separado, bem-comportado e programável em C, do que escrever toda a lógica em assembly estranhamente limitado, como no código tradicional de início do BIOS
    Em alguns HPE ProLiant, parece que parte dessa inicialização de baixo nível é realmente feita pelo iLO. Nessa etapa de boot, o iLO também controla diretamente o framebuffer; no G10, aparece rapidamente uma mensagem do tipo “passando o console para o host”, e então o display é reinicializado e aparecem as instruções das teclas de função
    Imagino que a Dell faça algo parecido, mas nas fases iniciais só aparece “Please wait” com um grande indicador de carregamento, sem mostrar o progresso

  • IPMI e outras soluções são boas, mas o que eu quero é uma interface serial padrão para um shell UEFI sempre em execução. Como acessar essa porta serial é problema meu

    • Os serviços de boot UEFI dos quais o shell depende não ficam disponíveis depois que o bootloader ou o sistema operacional chama ExitBootServices()
      O código é literalmente removido da RAM e aquela região é devolvida ao sistema operacional, então não é algo fácil de implementar
    • O que sinto falta nos Sun SPARC e em outros sistemas Unix é que havia acesso remoto de verdade em um nível muito baixo
      Consoles remotos de BIOS/UEFI sempre foram complicados e tinham resultados irregulares. Para acertar a entrada e a saída, frequentemente era preciso mexer nas configurações do GRUB ou do kernel
    • Hardware de servidor geralmente permite acessar a UEFI por serial. Mesmo assim, acho que ainda seria necessário controle remoto de energia
  • O IPMI é útil, mas deixa claro que não dá para confiar que empresas comerciais vão dar suporte adequado ao hardware no longo prazo
    O sistema operacional que roda no IPMI geralmente é relativamente seguro quando o sistema é novo, mas, quando sai um novo soquete de CPU, o fabricante perde cada vez mais o interesse em atualizar sistemas antigos. Isso vale mesmo quando o mesmo hardware de IPMI está tanto em placas antigas quanto em novas
    Se fosse possível instalar seu próprio sistema operacional no hardware de IPMI, ele seria muito mais útil. Assim, poderia ser seguro conectá-lo diretamente à internet. Hoje são necessárias comunicações sideband, como VPN, encaminhamento de porta SSH ou um segmento de rede separado, o que acaba gerando muito hardware e configuração extras para dar suporte ao IPMI
    Em instalações de grande escala, o custo adicional fica bem diluído, mas, em instalações pequenas, é um peso considerável. Para algo como colocar uma única máquina em colocation, chega a não valer a pena
    Como não dá para expor o IPMI diretamente à internet com segurança, acabamos prendendo algum tipo de Pi a cada equipamento. Fazendo isso, usar a porta serial fica igualmente fácil — na verdade, até mais fácil. No fim, é como voltar ao controle padrão por porta serial que existia desde a época de VAX, Sun e Alpha, e, quanto mais se pensa nisso, mais faz sentido do que uma interface de rede insegura

  • Para uma implantação menor, por exemplo na escala de cerca de 10 mil núcleos, eu montaria diretamente por meio de um integrador
    Com uma placa-mãe Gigabyte/ASRock Rack, série Epyc 9003, 384 GB de RAM e uma configuração comum de fontes de alimentação redundantes, o custo ficaria em torno de 7 mil dólares por nó, e a eficiência energética também pode ser bem boa
    O IPMI integrado também é bastante decente, funciona bem com ipmitool e normalmente inclui um pouco de funcionalidade relacionada a Redfish

  • Gosto muito de IPMI, mas o que não me agrada no uso em homelab é que ele consome cerca de 5 W a mais em idle
    A combinação de uma placa Gigabyte MC12-LE0 com um Ryzen Pro 5650 parece uma escolha óbvia para um servidor doméstico por cerca de 50 dólares, mas o consumo de energia mais alto não me deixa totalmente satisfeito
    Equipamentos mais antigos como Dell T20/T30 têm Intel AMT, que é bem mais limitado e também tem falhas de segurança, mas, usado com o MeshCommander, pelo menos oferece um caminho para gerenciamento remoto. Infelizmente, o MeshCommander foi descontinuado e os releases desapareceram de vários lugares, mas, por sorte, salvei o MSI e o pacote Node no servidor
    Pretendo testar o PiKVM V2 com um Raspberry 4 e uma placa simples de captura USB-HDMI de 8 dólares: https://docs.pikvm.org/v2/
    Tirando a ausência de alguns recursos, parece promissor por ser mais genérico e poder ser usado também com dispositivos que não dão nenhum suporte a gerenciamento remoto

    • O consumo adicional de energia depende muito da qualidade da fonte de alimentação. Fazer uma fonte eficiente tanto em carga alta quanto em idle é bem difícil
      Duvido que um BMC — às vezes um BMC embutido na NIC — realmente consuma tudo isso. Além disso, usando um Raspberry 4 para PiKVM, o consumo vai passar de 5 W
    • Agora que o firmware foi aberto, estou analisando o NanoKVM
      https://github.com/sipeed/NanoKVM
    • Os releases do MeshCommander ainda podem ser baixados em https://www.meshcommander.com/ e ele também pode ser instalado via NPM
      Não experimentei, mas parece que https://meshcentral.com/ é o sucessor pretendido
    • O MeshCommander 0.96 voltou a estar disponível no site. Li que isso aconteceu porque o desenvolvedor estava se adaptando a um novo emprego
  • A grande pergunta no IPMI é: qual é a chave padrão?
    Se alguém em algum ponto da cadeia de suprimentos instalar uma chave adicional de IPMI, ou se houver uma chave padrão, essa pessoa poderá gerenciar o computador remotamente
    https://www.rapid7.com/blog/post/2013/07/02/a-penetration-te...

    • Como citado adicionalmente no link, o processo de autenticação do IPMI 2.0 exige que, antes de o cliente se autenticar, o servidor envie ao cliente um hash SHA1 ou MD5 com salt da senha do usuário solicitado
      O IPMI também limita o tamanho máximo da senha a 20 caracteres. Na prática, é preciso considerar que o hash só deve permanecer secreto contra pentesters conhecidos que trabalham dentro de um prazo contratual limitado, não contra atacantes reais com tempo ilimitado
      Sou muito crítico em relação a esse ponto. Já se passaram 20 anos desde que isso entrou na especificação. A vantagem do software não deveria ser ser mais fácil de mudar do que hardware? É fácil dizer “tem que colocar em uma VLAN”, mas, quando vou fazer avaliações, o IPMI quase sempre está conectado à rede corporativa
      Se você coloca algo idiota como padrão, configurações idiotas se espalham pelo mundo inteiro, inclusive no momento em que qualquer empresa sem administradores de segurança experientes “compra um servidor”
    • Ele deve estar sempre em uma rede fisicamente separada, e BMCs que compartilham a NIC com o sistema devem ser evitados