O Kubernetes não está imune ao ransomware — e como o Illumio pode ajudar

Ransomware não é um problema no Kubernetes, certo? Os contêineres são estruturas tão dinâmicas e efêmeras que há pouco risco de um ransomware ter tempo de sequestrar um pod, por exemplo, e tentar propagar cargas maliciosas lateralmente entre namespaces. Os pods são iniciados e encerrados de forma tão dinâmica que o ransomware é uma preocupação menor no Kubernetes, portanto meu cluster está seguro contra essa ameaça específica de segurança cibernética, certo?

Infelizmente, essa suposição foi provada errada muitas vezes. O ransomware tende a funcionar de forma diferente no Kubernetes do que fora dos clusters de contêineres, mas é um risco de cibersegurança muito real que os arquitetos do DevSecOps não podem se dar ao luxo de ignorar. O ransomware pode causar danos muito reais em um cluster Kubernetes, e a melhor forma de remediação é a prevenção.

O Illumio pode impedir que o ransomware sequestre seu cluster Kubernetes, impedindo que sua organização seja a próxima vítima de ataque cibernético a aparecer nas notícias.  ․

Como o ransomware se propaga no Kubernetes

Em cargas de trabalho sem contêineres, o ransomware sequestra um host e depois procura portas abertas. As portas comuns que estão abertas por padrão em muitas cargas de trabalho são RDP, SSH e SMB. É trivial que o ransomware falsifique as conexões por essas portas e estabeleça uma conexão com um host vizinho. Depois que a conexão é aberta, o ransomware pode entregar rapidamente uma carga maliciosa ao próximo host, assumir o controle dela e procurar portas abertas, repetindo esse processo em todos os hosts vizinhos muito rapidamente.  

Essa propagação entre hosts pode ocorrer mais rapidamente do que a maioria das soluções de proteção contra malware do tipo "detecção e resposta" consegue identificar e combater. Em pouco tempo, toda a infraestrutura poderá ser tomada como refém.  

No Kubernetes, os hosts – também conhecidos como “nós” – são máquinas virtuais (VMs) ou hosts físicos que executam código de contêineres. Eles criam uma camada de abstração acima do sistema operacional (SO) subjacente do nó. Um cluster é criado quando pods e serviços são associados a um namespace, e esse namespace contém todo o código e as bibliotecas necessárias para a execução da aplicação dentro dele. As estruturas dentro de um namespace são dinâmicas: à medida que os recursos computacionais são escalados horizontalmente, os pods são iniciados, executam código e podem ser rapidamente desativados, apenas para serem iniciados novamente mais tarde com um endereço IP diferente.  

O tempo de vida de um pod pode ser muito curto, e a maioria dos pods não utiliza portas abertas como RDP ou SSH. Isso ocorre porque os pods geralmente não usam esses protocolos para se comunicar com outros pods. Assim, o ransomware é frequentemente percebido como tendo pouca relevância dentro de um cluster.  

Oransomware é uma grande ameaça no Kubernetes.

No entanto, um ataque de ransomware pode rapidamente se transformar em um desastre cibernético em um cluster Kubernetes. Códigos maliciosos podem ser introduzidos no início do ciclo de vida do desenvolvimento de código, mas não serem detectados porque ainda não estão em execução. Cargas maliciosas também podem ser introduzidas em um cluster Kubernetes por meio de APIs expostas, configurações de autenticação fracas, software sem patches ou, talvez o risco mais comum: configurações incorretas.  

As ameaças cibernéticas podem ser introduzidas em qualquer ponto da cadeia de fornecimento de software. Por exemplo, se a imagem de um contêiner for baixada de um repositório de código aberto e, em seguida, executada em um cluster, essa imagem poderá conter código incorporado que pode ser executado e "escapar" de um pod para o nó subjacente. Em seguida, ele implantará o ransomware nesse nó subjacente. Nesse ponto, o ransomware pode sequestrar esse nó e estabelecer conexões por meio de portas abertas com nós vizinhos, permitindo que a ameaça sequestre ou criptografe rapidamente todos os nós subjacentes que hospedam o cluster Kubernetes.  

Isso pode fazer com que os aplicativos em execução nos nós de trabalho fiquem "travados" – ou seja, sejam desligados. Se o código escapar para um nó mestre subjacente, o plano de controle do cluster Kubernetes poderá ser sequestrado, correndo o risco de inutilizar todo o cluster. Um pequeno problema introduzido no início do ciclo de vida do desenvolvimento do código pode rapidamente se transformar em um grande desastre.  

Um exemplo desse tipo de malware é o Siloscape, descoberto em março de 2021. Ele explora vulnerabilidades em processos de threads pouco documentados para acessar o nó subjacente e, em seguida, consegue acessar o kubectl para executar comandos que se propagam para os nós vizinhos. Este é um exemplo claro de por que o plano de controle dos nós do Kubernetes precisa ser protegido e o acesso limitado por outros processos. O Illumio consegue impor o acesso a processos específicos em um host, limitando quem tem acesso a eles.  

․ OIllumio pode se proteger proativamente contraransomware no Kubernetes

O Illumio impõe a comunicação da carga de trabalho dentro de um cluster Kubernetes e do nó subjacente.  

Em um cluster Kubernetes, o Illumio reforçará a comunicação entre namespaces ou entre namespaces e cargas de trabalho fora de um controlador de entrada, evitando a comunicação desnecessária entre cargas de trabalho. Ao contrário de outros fornecedores, a visibilidade e a fiscalização da Illumio se estendem por toda a superfície de ataque híbrida, não apenas aos contêineres, permitindo que as equipes de SecOps eliminem os silos de políticas e estendam as operações existentes em contêineres, melhorando a resiliência cibernética.

Entre os nós subjacentes, o Illumio também reforçará a comunicação para que, se um código malicioso desconhecido escapar do cluster Kubernetes e descer para o nó, esse código malicioso seja impedido de se propagar para os nós vizinhos. Isso é possível porque o Illumio impede que sessões sejam estabelecidas entre esses nós. Como a Illumio presume que as violações são inevitáveis, mesmo com ameaças introduzidas no início da cadeia de suprimentos de software, os clusters Kubernetes são protegidos contra ransomware com a intenção de interromper a infraestrutura subjacente.  

․Como mudar a segurança para a esquerda no Kubernetes com o Illumio

Em cibersegurança, shift-left se refere à introdução de soluções de segurança no início do ciclo de vida de desenvolvimento de código:  

• O lado direito do ciclo de vida representa hospedar o código como um aplicativo e implantar um firewall na frente dele.

• O lado esquerdo representa o nascimento desse código à medida que ele é desenvolvido.  

Se alguma carga de trabalho gerenciada contiver uma ameaça desconhecida incorporada ao código que posteriormente é iniciada e tenta se espalhar para os hosts vizinhos, a Illumio evitará que essa ameaça se espalhe.

Isso é verdade mesmo sem que Illumio saiba a intenção dessa ameaça. A maioria das soluções de segurança de detecção e resposta tenta entender a natureza de uma ameaça antes de tomar uma decisão. Mas a Illumio não perde tempo tentando entender isso antes de tomar uma decisão. A quantidade de comunicação lateral exigida pela maioria das cargas de trabalho é limitada, e a maioria das portas abertas deve ser fechada ou monitorada continuamente. Os dispositivos podem ser colocados em quarentena e o Illumio pode impedir toda comunicação lateral sem precisar saber que tipo de dano está sendo tentado.  

O Kubernetes nunca deve ser considerado imune ao ransomware. A prevenção é a melhor forma de remediação, e o Illumio impede que o ransomware infecte todas as cargas de trabalho, mesmo no Kubernetes.

Quer saber mais sobre como a Illumio pode proteger o Kubernetes da disseminação do ransomware? Entre em contato conosco hoje para uma consulta e demonstração gratuitas.