Quando um servidor host Linux de máquina virtual não está voltado para a Internet e é usado exclusivamente em uma LAN e está usando uma distribuição relativamente bem testada como o Proxmox, quão perigoso seria desligar todas as mitigações de vulnerabilidade por meio do kernel arg mitigations=off?
Além disso, alguém testou que tipos de ganhos de desempenho podem ser obtidos ao desativar todas essas mitigações?
Recentemente, isso se tornou uma dúvida para mim quando vi esse grande sucesso que as retbleedmitigações criam:https://www.phoronix.com/review/retbleed-benchmark
Esta linha de pensamento estendeu-se à curiosidade sobre quais podem ser as ramificações - tanto negativas como positivas - da remoção de todas ou de algumas mitigações, quer através do argumento central acima, quer através da desactivação individual de mitigações de alto impacto.
Responder1
O sinalizador do kernel Linux mitigations=[on|off]é uma alternância única para ativar/desativar facilmente todas as mitigações de kernel disponíveis para vulnerabilidades de hardware, conforme listado aquihttps://docs.kernel.org/admin-guide/hw-vuln/index.html
O impacto disso depende inteiramente da sua CPU:
Quando sua CPU não estiver vulnerável a nenhuma das vulnerabilidades conhecidas, nenhuma das mitigações será aplicável e o impacto deverá ser efetivamente zero.
Quando sua CPU está vulnerável a alguns (existem CPUs vulneráveis atodosdelas?) o impacto depende de quais vulnerabilidades específicas e da sua carga de trabalho.
Quanto à análise de risco, isso também depende da sua carga de trabalho e base de usuários.
Em um host de virtualização operado por um provedor VPS público, os convidados são menos confiáveis e muito mais propensos a serem mal-intencionados (ou comprometidos) do que eu esperaria em um host de virtualização interno usado exclusivamente por meus colegas.
Por exemplo, em nossos hosts de virtualização usados para pipelines de CI/CD e clusters de computação, todos os convidados têm vida curta, são implantados a partir de imagens confiáveis, são executados por até algumas horas e depois são destruídos novamente. Aí precisamos de todo o desempenho que pudermos obter e desabilitar as mitigações.
Em um cluster compartilhado diferente, hospedamos cargas de trabalho de consolidação de servidor mais clássicas; os hóspedes que são implantados lá podem (e são mais propensos a) funcionar “para sempre” em vez de horas. Possui uma combinação de cargas de trabalho de produção e não produção e os convidados são gerenciados por equipes de DevOps que não são tão diligentes na correção e atualização de seus sistemas e aplicativos.
Lá, o risco de um convidado mal-intencionado ou comprometido é muito maior, o possível desempenho reduzido para cargas de trabalho específicas é uma compensação aceitável e, portanto, as mitigações são habilitadas e limitamos quais sinalizadores de CPU são expostos aos convidados.
Responder2
é realmente impossível conectar o servidor, mesmo indiretamente, de fora da sua rede?
Essa é a primeira pergunta que você deve se fazer. Se a LAN puder ser acessada a partir de uma máquina que tenha 2 conexões de rede, uma para essa LAN e outra para outra rede conectada à Internet (esperançosamente através de várias camadas de firewalls), você acabou de conectar esse servidor à Internet.
E lembre-se que uma máquina não precisa estar conectada à internet para ficar vulnerável a ataques. Uma máquina pode estar infectada com malware que tem simplesmente a intenção de causar danos a ela por meio de um pendrive, disquete ou até mesmo comandos digitados em um terminal.
No final, toda a segurança, assim como todas as melhorias de desempenho, são um compromisso. Qual é um nível aceitável de risco para as recompensas obtidas.
Para descobrir seus ganhos potenciais de desempenho, execute testes na máquina enquanto ela não possui nenhuma conexão de rede e veja por si mesmo. Provavelmente não será muito, mas pode ser apenas o suficiente para espremer aqueles poucos ciclos extras de CPU que ajudam alguns hardwares antigos a sobreviver um pouco mais para que você tenha tempo de convencer a alta administração de que você realmente deveria obtenha o orçamento para um novo servidor.
Responder3
"... usado exclusivamente em uma LAN e usando uma distribuição relativamente bem testada como Proxmox, quão perigoso seria desligar todas as mitigações de vulnerabilidade por meio do kernel arg mitigations=off?"
...
"Esta linha de pensamento estendeu-se à curiosidade de quais podem ser as ramificações - tanto ruins quanto positivas - da remoção de todas ou algumas mitigações, seja por meio do argumento do kernel acima ou pelo desligamento individual de mitigações de alto impacto.".
Você ainda pode considerar a responsabilidade e o aumento do tempo para reparar até mesmo um pequeno número de problemas.
Dito isto, a maioria das mitigações já está implementada nas CPUs mais recentes; portanto, desativá-los causa pouca ou pequena perda de desempenho em sistemas mais novos - sim, geralmente é mais lento com as mitigações desativadas; mas, como qualquer referência, há exceções.
"... que tipos de ganhos de desempenho podem ser obtidos ao desativar todas essas mitigações?"
Michael Larabel da Phoronix diz:
Em seu artigo de 7 de dezembro de 2022:"Comparação do desempenho do impacto de mitigação do Intel Raptor Lake":
"... na maior parte, as mitigações envolvidas em software ainda relevantes para Raptor Lake podem ser mantidas sem qualquer diferença significativa no desempenho."
Em seu artigo de 30 de setembro de 2022:“Com o AMD Zen 4, surpreendentemente não vale a pena desativar as mitigações de segurança da CPU”:
"... para a ampla gama de 190 benchmarks diferentes realizados, manter as mitigações padrão foi cerca de 3% mais rápido no geral do que executar com mitigations=off. Basicamente o oposto do que normalmente vemos com outros processadores mais antigos.".
Com sistemas mais antigos, você ainda precisa considerar que funcionários insatisfeitos poderão elevar seus privilégios ou danificar sua LAN antes de saírem. Parte de sua insatisfação pode ser causada por equipamentos antiquados, que eles usam contra você. Além disso, um celular conectado quebraria a presunção de "não estar voltado para a Internet", carregar seu telefone e executar um aplicativo malicioso ou abrir um e-mail cuidadosamente elaborado só pode explorar as vulnerabilidades existentes.