Medo do Desconhecido: Os Segredos Sombrios dos Sistemas de Virtualização

128K+ Alcance em 30 dias Positive Technologies 4,21 Avaliação do Empregador 526,6 Classificação 118 451 Inscritos Inscrever-se ptsecurity Há 22 minutos Medo do Desconhecido: Os Segredos Sombrios dos Sistemas de Virtualização 13 min 1.5K Blog da Positive Technologies Segurança da Informação * Virtualização * Infraestrutura de TI * Olá, Habr! Meu nome é Danil Zaripov, sou especialista do centro de segurança (PT ESC) da Positive Technologies. Este artigo foi preparado em conjunto com meu colega Kirill Maslov, especialista de produto na área de Gerenciamento de Ativos. Estamos encerrando nosso ciclo de artigos sobre auditoria de ativos de TI e hoje falaremos sobre sistemas de virtualização. A infraestrutura virtual não é apenas uma maneira conveniente de economizar hardware. É um sistema complexo que envolve hipervisores, máquinas virtuais, redes, sistemas de armazenamento e software de gerenciamento. E se um invasor obtiver acesso a ela, considere que ele tem as chaves de qualquer "porta" da empresa. Para o defensor, é uma enorme camada de dados que ajuda a ver a infraestrutura como um todo, encontrar vulnerabilidades, detectar configurações inseguras e notar direitos de acesso excessivos a tempo. Como a infraestrutura virtual é organizada por dentro? Por que os atacantes estão cada vez mais caçando-a? E o mais importante - o que os defensores podem fazer para não deixar seus servidores se transformarem em uma botnet alheia? Vamos analisar usando os produtos VMware como exemplo! Anatomia da infraestrutura virtual Vamos começar com o básico para que todos tenham uma imagem completa. O sistema de virtualização consiste em vários componentes-chave, cada um dos quais é importante para entender como a infraestrutura virtual é organizada e onde os riscos podem estar ocultos. Hipervisores — servidores cujos recursos de hardware são usados para operar máquinas virtuais. O hipervisor atua como uma camada entre o hardware e as máquinas virtuais, distribuindo a capacidade. No ecossistema VMware, eles são chamados de ESXi - esta é a base de toda a infraestrutura virtual. Máquinas Virtuais (VM) — sistemas dentro dos quais os sistemas operacionais são instalados e, em cima deles, aplicativos, bancos de dados, serviços - tudo que implementa a lógica de negócios. Estes são os mesmos servidores, apenas embalados em arquivos e executados em cima do hipervisor. São as VMs que mais frequentemente se tornam o alvo dos atacantes - nelas estão os dados e os serviços. Sistemas de armazenamento de dados — parte integrante de qualquer virtualização séria. Todo o volume de informações precisa ser armazenado em algum lugar de forma confiável, e o SDS assume isso. Eles podem ser dispositivos separados ou soluções de software, mas precisam ser monitorados - a capacidade de operação de toda a infraestrutura depende de sua disponibilidade. Redes virtuais — uma camada sem a qual a virtualização é impossível. Para que os componentes interajam onde precisam e não interajam onde não precisam, os administradores organizam redes virtuais, segmentam o tráfego, configuram o isolamento. Do ponto de vista da segurança, isso é importante: rotas de movimento horizontal podem passar por redes mal configuradas. Software de gerenciamento — o cérebro de toda a infraestrutura virtual. No caso do VMware, este é o vCenter Server - um console central para gerenciar configurações, adicionar e remover componentes, atribuir direitos. O acesso ao software de gerenciamento dá ao invasor controle sobre tudo o que acontece no ambiente virtual. Contas de usuário do software de gerenciamento, hipervisores, etc. — eles têm funções e direitos de acesso. Para segurança, isso é crítico: devemos saber exatamente quais contas existem, quais direitos elas têm e se uma conta de um funcionário demitido ou uma conta com poderes excessivos não se intrometeu entre elas. Visão do atacante: do vCenter à botnet Há tanta informação dentro dos gerenciadores de máquinas virtuais que ela é de grande interesse para os invasores. Ataques à infraestrutura começam de uma forma ou de outra a afetar a camada virtual, e através dela os invasores invadem toda a organização. Como um ataque ao gerenciador de máquinas virtuais pode terminar? Um dos cenários mais sombrios é a criação de uma botnet a partir de sua própria infraestrutura virtual. Ao obter acesso ao software de gerenciamento, o invasor vê todas as máquinas virtuais e, se desejar, pode transformá-las em uma rede zumbi. Sim, você dirá que as máquinas zumbis também são físicas, mas o que impede de fazer o mesmo com as máquinas virtuais? Por exemplo, a empresa MITRE acompanha essa tendência há muito tempo e tem uma tabela separada de táticas e técnicas para ataques à infraestrutura virtual. Se você olhar para ela, pode notar que absolutamente todas elas estão incluídas na tabela Enterprise principal. Vale a pena estudá-las, pelo menos para entender melhor quais métodos de impacto na infraestrutura os invasores podem usar para capturar seu ambiente virtual. Mas mesmo que você não entre em técnicas complexas, o simples acesso ao gerenciador de máquinas virtuais dá ao hacker várias coisas extremamente valiosas: Notas dos administradores. Muito frequentemente, os administradores deixam notas para si mesmos para entender a infraestrutura mais tarde. Os campos de notas podem conter logins, senhas, endereços, o nome da pessoa responsável por uma determinada VM e outras informações que ajudam a ir mais longe. Ao obter acesso ao gerenciador, o invasor não pode entrar imediatamente na máquina virtual - uma janela de login aparecerá na frente dele. Mas se a senha estiver nas notas, a janela deixa de ser uma barreira. Mapa completo da infraestrutura. Quando as máquinas virtuais são criadas, os administradores as colocam não aleatoriamente, mas estruturadamente - caso contrário, seria impossível navegar nesse zoológico. No gerenciador, tudo isso é apresentado em forma de árvore. Ao percorrer a árvore, o invasor pode facilmente encontrar servidores de produção, sistemas críticos e máquinas virtuais de particular interesse. Ele nem precisará procurar algo sozinho, basta descarregar toda a árvore de pastas e VMs via API, carregá-la em LLM e perguntar à rede neural o que é importante dessa informação. Conveniente! Agora sua infraestrutura é conhecida pelo invasor (e graças aos dados que chegaram à rede neural – o mundo inteiro). Conhecendo os endereços IP ou FQDNs, você já pode mirar com mais precisão, procurar vulnerabilidades e atacar mais adiante. Visão do defensor: inventário, configurações e acessos Nós olhamos para a infraestrutura virtual pelos olhos do atacante, e agora vamos descobrir como aqueles que devem mantê-la e protegê-la a veem. Para profissionais de TI, a infraestrutura virtual é, em primeiro lugar, um objeto de inventário. Você precisa ver todos os componentes, entender como eles são organizados, como estão interconectados, em quais redes estão localizados, quais são as alavancas de controle. Sem isso, é impossível administrar a infraestrutura normalmente e, mais ainda, fortalecer sua segurança. Para o departamento de segurança da informação, tudo o que foi dito é verdade em dobro. Só podemos proteger o que sabemos. Portanto, o inventário de componentes virtuais é um primeiro passo obrigatório. Vendo todos os elementos, temos a oportunidade de controlar a segurança de suas configurações: como os componentes são configurados, quais parâmetros são definidos, se há pontos francamente fracos em algum lugar. Vendo em quais segmentos as máquinas virtuais estão localizadas e como elas podem interagir entre si, podemos notar as rotas que os invasores usam para movimento horizontal. Uma rede virtual configurada sem levar em conta a segurança pode dar ao atacante a capacidade de pular de um segmento para outro onde isso não deveria ser. E, finalmente, o controle de direitos de acesso excessivos - na infraestrutura virtual, como em qualquer outra, as contas se acumulam com o tempo, que há muito tempo precisam ser removidas ou limpas. Pode ser a conta de um funcionário que foi demitido há um ano, uma conta de serviço desnecessária criada há muito tempo para algum projeto, ou apenas uma conta que de repente teve muitos direitos. Tudo isso é importante rastrear e corrigir a tempo. Ferramentas de auditoria: da varredura à simulação de ataques Agora vamos contar como nós, na Positive Technologies, ajudamos a tornar a infraestrutura virtual mais segura e a impedir que os invasores a comprometam. Vamos começar com dois produtos que são responsáveis por vulnerabilidades e configurações. MaxPatrol VM e o módulo MaxPatrol HCC. Vulnerabilidades e configurações sob controle MaxPatrol VM permite construir um processo de gerenciamento de vulnerabilidades. Na placa de vulnerabilidade, sua criticidade, vetor CVSS, informações adicionais e recomendações para correção são visíveis. Além disso, o MaxPatrol VM mostra qual software está instalado no ativo e qual é sua configuração. Módulo MaxPatrol HCC é necessário para verificar a conformidade com os padrões e o endurecimento da infraestrutura. Ele se concentra precisamente nas configurações dos componentes instalados e sabe como notar configurações inseguras nelas. Não basta apenas encontrar o problema - o MaxPatrol HCC explica por que essa configuração é perigosa, dá recomendações para correção e permite rastrear se a correção realmente foi aplicada. Dois exemplos vívidos da vida real: O primeiro diz respeito ao hipervisor ESXi. Recomendamos enfaticamente proibir o acesso direto por SSH aos hipervisores. Se o vCenter for usado em sua infraestrutura (e isso acontece quase sempre), ele já gerencia os hipervisores, e o SSH direto para gerenciamento manual simplesmente não é necessário. Se esse acesso não for desativado, ele pode se tornar uma porta aberta para um invasor que irá comprometer o hipervisor através dele. O segundo exemplo é a configuração do próprio vCenter. Há uma conta vpxuser que é usada para que o vCenter gerencie os hipervisores. A força da senha para esta conta deve ser alta. Se a senha for fraca e comprometida, o invasor terá acesso a toda a infraestrutura virtual. MaxPatrol SIEM. Enriquecimento de eventos com dados do vCenter Mas o gerenciamento de vulnerabilidades e o controle de configurações são apenas parte do trabalho. Os dados da infraestrutura virtual também podem ser úteis na investigação de incidentes. MaxPatrol SIEM sabe como usar informações do vCenter usando listas de tabelas Asset Grid. Uma solicitação do MaxPatrol VM é passada no campo de solicitação e, após a instalação, a lista é preenchida automaticamente com dados sobre ativos e atualizada regularmente. Por exemplo, você pode criar uma lista de tabelas que rastreia máquinas virtuais críticas. São as VMs que são apresentadas no vCenter e têm funções importantes - por exemplo, controladores de domínio. Todos esses dados entram na lista de tabelas, e então as regras de correlação podem interagir com ela. Abaixo está um exemplo de como duas regras de correlação funcionam com essa lista: uma rastreia a clonagem de máquinas virtuais críticas, a outra - o carregamento de dados dessas máquinas. Lista de tabelas do sistema Para aqueles que desejam adicionar máquinas críticas manualmente, existe seu irmão gêmeo - a lista de tabelas VSphere_Critical_VMs_Custom, que pode ser preenchida manualmente. As regras de correlação funcionam com ambas. MaxPatrol Carbon. Modelagem de caminhos de ataque Os dados da infraestrutura virtual são úteis não apenas para detectar problemas, mas também para entender como um invasor pode usar esses problemas. MaxPatrol Carbon analisa informações do MaxPatrol VM (ativos, conectividade de rede, vulnerabilidades, configurações incorretas, direitos de usuário, etc.) e constrói possíveis caminhos de hacker para os sistemas críticos da empresa. Aqui está um exemplo de um stand real: MaxPatrol Carbon mostra a cadeia: usando a conta do helpdesk, você pode capturar o vCenter, através dele ir para a máquina virtual, onde as credenciais de um dos principais usuários são deixadas, e já com esses dados entrar em sua máquina. O MaxPatrol Carbon não apenas fala sobre a existência de tal caminho, mas também explica o que é esse caminho, quão perigoso ele é (tempo de ataque TTA – time to attack, número de etapas, complexidade da implementação, etc.) e dá recomendações sobre como removê-lo. Prática de auditoria: consultas PDQL para vCenter Agora vamos para a parte mais interessante - para consultas específicas que ajudam a extrair o máximo de informações úteis da infraestrutura virtual. Todas essas consultas são executadas no MaxPatrol VM e fornecem respostas às principais perguntas que qualquer defensor deve se fazer. Pesquisando todos os vCenters na infraestrutura A primeira e mais simples consulta é exibir todos os ativos nos quais o software do tipo vCenter Instance está instalado. Após a auditoria, eles aparecerão no banco de dados, e você verá quais vCenters existem em sua infraestrutura, quando foram verificados pela última vez e se está tudo bem com eles. Solicitação para pesquisar servidores VMware vCenter por software instalado Mas se você não tiver certeza de que todos os vCenters já foram verificados, você pode seguir outro caminho. Verificamos quais máquinas na infraestrutura têm portas abertas, típicas do vCenter. Solicitação para pesquisar servidores VMware vCenter por portas Para fazer isso, você precisa pré-verificar a infraestrutura no modo de descoberta de host, descoberta de serviço ou teste de penetração - de preferência em massa, em um grande número de sub-redes e portas. Pegamos portas típicas, solicitamos-as, colamos-as no número de correspondências para cada ativo e exibimos apenas aquelas onde mais de cinco portas estão abertas. Assim, garantimos que encontraremos todos os vCenters, mesmo aqueles para os quais a auditoria não foi realizada. Verificação de domínios conectados ao vCenter Você pode entrar no vCenter usando contas de domínio, por isso é fundamental verificar quais domínios estão conectados a cada vCenter. Geramos uma solicitação que extrai ativos com software vCenter Instance e exibe todos os domínios vinculados a eles: E então juntamos essas informações com ativos do tipo Active Directory, que já estão na infraestrutura: Deve-se prestar atenção especial às contas dentro do próprio vCenter. Com uma solicitação separada, extraímos-as e vemos se um administrador de domínio não se intrometeu entre elas. Se o administrador do domínio for simultaneamente o administrador do vCenter - este é um problema sério que precisa ser corrigido. Isso não pode ser feito. Pesquisando hipervisores e verificando com a realidade O próximo pedaço do quebra-cabeça são os hipervisores. No caso do VMware ESXi, extraímos dados do vCenter sobre todos os hosts ESXi vinculados a ele e os juntamos com ativos do tipo ESXi Host, que estão no MaxPatrol VM. No mundo ideal, todos os hipervisores que o vCenter conhece devem estar presentes no banco de dados e ser verificados regularmente. Solicitação de nós ESXi para os quais a auditoria não foi realizada Mas acontece de outra forma. A solicitação pode encontrar um ESXi que está registrado no vCenter, mas não há ativo com esse nome na VM. Isso é estranho, porque ao verificar via API, os ativos devem ser criados automaticamente. Talvez o hipervisor já tenha sido retirado de operação e eles simplesmente se esqueceram de removê-lo do gerenciador. Ou talvez algo muito pior tenha acontecido, e este ESXi precise de restauração imediata. Verificação de máquinas virtuais E a última peça é as máquinas virtuais. Extraímos do vCenter todas as VMs apresentadas nos data centers e as colamos nos ativos da infraestrutura via VM ID. Há uma nuance importante aqui: os ativos são criados apenas para máquinas virtuais ativadas. As VMs desligadas não são criadas ao verificar o próprio vCenter, e não as vemos na grade. Solicitações de dados de máquinas virtuais Se entre as VMs ativadas houver máquinas que não estão no banco de dados, ou vice-versa, há ativos no banco de dados que não estão no vCenter, esta é uma razão para descobrir o que está acontecendo com a infraestrutura. Como obter esses dados: verificando o vCenter Antes de executar todas essas consultas, você precisa verificar o próprio vCenter. Vamos contar como isso é feito. Criando uma conta. A partir daqui, vale a pena começar a criar uma conta no próprio vCenter. O manual do usuário descreve tudo em detalhes, mas, resumidamente, você precisa de uma conta com direitos somente leitura em toda a infraestrutura, em todos os componentes. Executando a tarefa. Depois de criar uma conta, adicionamos-a ao gerenciador de contas no MaxPatrol VM. Em seguida, criamos uma tarefa para coletar dados, especificamos essa conta, se necessário, alteramos a porta, parâmetros de criptografia e outras configurações. Mas, via de regra, não há necessidade disso. Executamos a tarefa para verificar o servidor vCenter usando o perfil vSphere Audit. Exemplo de criação de uma tarefa de auditoria com o perfil vSphere Audit O que está acontecendo sob o capô. O produto se conecta ao vCenter via API e começa a coletar dados. Primeiro, ele aprende sobre o próprio vCenter, depois recebe informações sobre quais hipervisores estão associados a ele, remove parâmetros deles. Em seguida, vendo as máquinas virtuais que estão sendo executadas nesses hipervisores, ele cria ativos para elas. Um ponto importante: os ativos criados dessa forma são bastante limitados em termos de conjunto de dados. Podemos descobrir apenas o sistema operacional (ou pelo menos sua família), o ID do vCenter e o endereço IP. Um conjunto básico, mas já permite entender que o ativo existe e, em seguida, realizar sua auditoria completa com o perfil necessário. Todas essas quatro etapas são executadas automaticamente, sob o capô, e não exigem nenhuma ação adicional do usuário. Verificamos o vCenter - obtivemos uma visão de quase toda a infraestrutura virtual. Por que é importante verificar também por SSH Falamos sobre a auditoria com o perfil vSphere Audit, mas recomendamos enfaticamente que você também execute a auditoria do gerenciador de máquinas virtuais com o perfil Unix SSH Audit. Por que isso é tão importante? É graças ao perfil SSH que veremos muito mais dados sobre o próprio host do que via API: descobriremos quais versões de software estão instaladas no ativo, obteremos informações adicionais que ajudarão a fortalecer a segurança. E o mais importante - seremos capazes de ver componentes vulneráveis e atualizar o software a tempo, fechando os buracos antes que os invasores cheguem até eles. A verificação por SSH não cria um ativo separado - é o mesmo vCenter, apenas uma camada mais profunda de dados sobre o próprio sistema operacional e suas configurações é removida dele. E há muito mais informações sobre a proteção desta máquina crítica. Três perguntas frequentes sobre a auditoria de infraestrutura virtual Durante a implementação e comunicação com os clientes, ouvimos regularmente as mesmas perguntas sobre a auditoria de sistemas de virtualização. Vamos analisar os três mais frequentes - para que você saiba que não é o único a ter encontrado isso e como esses problemas são resolvidos na prática. Crescimento do número de ativos com uma licença limitada A primeira pergunta é sobre o crescimento do número de ativos e licenciamento. Após verificar o vCenter, há mais ativos no sistema, mas eles não afetam a licença MaxPatrol VM. A licença leva em consideração apenas os ativos que foram auditados ou testados. VMs do vCenter apenas destacam a necessidade de sua verificação adicional, se você decidir que precisa. Combinação errônea de duas máquinas virtuais diferentes A segunda pergunta é sobre a combinação errônea de máquinas virtuais. Se você clonar um servidor importante para testes, o sistema poderá ver duas máquinas idênticas e não distinguir o clone do original. Como resultado, os eventos deles serão misturados e entradas extras aparecerão no banco de dados. Portanto, ao clonar VMs importantes, altere o nome do host, IP e MAC, e para máquinas de modelo, faça sysprep. Verificando o vCenter apenas por API e não verificando por SSH A terceira pergunta: é possível verificar o vCenter apenas por API, sem SSH? Teoricamente, é claro, ninguém vai proibi-lo de fazer isso, mas não recomendamos enfaticamente que você faça isso. A API fornece apenas informações sobre a infraestrutura, mas não sobre o próprio servidor: versões de software, vulnerabilidades do sistema operacional, serviços abertos. Verifique por API e por SSH - este é um ativo, ele afeta a licença uma vez, e haverá muito mais informações sobre a proteção da máquina crítica. Sistemas de virtualização alternativos Estivemos o tempo todo falando sobre VMware vCenter - e isso não é por acaso. De acordo com nossas pesquisas, o VMware continua sendo a plataforma mais massiva: 39% de nossos entrevistados indicaram que usam o vCenter. Mas, recentemente, outros sistemas de virtualização são cada vez mais encontrados em instalações reais. Alguém está mudando para alternativas conscientemente, e em algum lugar a substituição de importação dita seus termos. No momento, nossos produtos suportam: VMware vCenter — obviamente, a plataforma principal na qual mostramos todos os exemplos. Microsoft Hyper-V — também suportado, embora não tenhamos parado nele no material. Proxmox — uma plataforma aberta popular, 21% dos entrevistados a usam. zVirt — uma solução doméstica baseada em oVirt, que está ativamente se desenvolvendo e ganhando popularidade. Também planejamos adicionar suporte Alt Virtualization — esta é uma questão das próximas versões. À parte está Qemu e KVM — haverá suporte aqui, mas com uma pequena estrela, porque estes são mais componentes do que gerenciadores de máquinas virtuais completos. Mas vamos apoiá-los do ponto de vista de que, se esses componentes forem detectados em algum ativo, poderemos coletar informações sobre as máquinas virtuais em execução e seus parâmetros básicos deles. Sim, esta não será uma auditoria tão rica quanto no caso do vCenter, mas esses componentes não darão mais informações em nenhum caso. Se você vir que algum sistema não está na lista e você precisar dele - escreva, isso afeta nosso roteiro. Resumindo Estamos fechando o ciclo de artigos "Medo do Desconhecido" com um tema sem o qual a infraestrutura moderna já é impensável - sistemas de virtualização. Em quatro edições, percorremos o caminho de uma visão geral do gerenciamento de ativos a uma imersão profunda em dispositivos de rede, domínios e virtualização. E em todos os lugares voltamos a uma ideia: é impossível proteger o que você nem suspeita que existe. Para ajudá-lo com o inventário da infraestrutura no MaxPatrol VM e MaxPatrol SIEM, preparamos um guia de especialistas em auditoria de ativos e scripts de automação. Ele contém todas as consultas PDQL sobre as quais falamos, exemplos de webinars anteriores e comentários sobre como usá-los. E no script no GitHub eles são embalados em uma ferramenta pronta para uso que envia solicitações para a API MaxPatrol VM, verifica ativos e até mesmo avalia o quão prontos eles estão para proteção do MaxPatrol SIEM. Obrigado por estar conosco durante todo o ciclo. Se você tiver alguma dúvida ou ideias para novos tópicos - escreva, vamos discutir! Outros artigos do ciclo: Medo do Desconhecido: Uma Olhada Dentro do Domínio Medo do Desconhecido: Auditoria de Dispositivos de Rede Medo do Desconhecido: Gerenciamento de Ativos como a Base da Segurança Cibernética Danil Zaripov Especialista do Centro de Segurança, Positive Technologies Kirill Maslov Especialista do Grupo de Especialistas em Gerenciamento de Ativos, Positive Technologies Tags: gerenciamento de vulnerabilidades gerenciamento de ativos vmware modelagem de ataques vulnerabilidades maxpatrol auditoria Hubs: Blog da Positive Technologies Segurança da Informação Virtualização Infraestrutura de TI 0 1 0 128K+ Alcance em 30 dias Positive Technologies Telegram VKontakte 64K+ Alcance em 30 dias 333 Carma @ptsecurity Usuário Inscrever-se O fluxo de segurança da informação está disponível 24 horas por dia, 7 dias por semana, graças ao apoio dos amigos do Habr Cursos Habr para todos PUBLICIDADE Prática, Hexlet, SkyPro, cursos do autor - reunimos todos e pedimos descontos. Resta escolher! Ir Ir para o fluxo de segurança da informação Comentar Melhor do dia Semelhante