Construtor de imagens de VM Kali

Este é o script de build para criar as imagens de Máquina Virtual (VM) do Kali Linux.

Atualmente, há dois métodos de build possíveis:

• build.sh - build diretamente da sua máquina
• build-in-container.sh - build a partir de dentro de um contêiner (Docker ou Podman)

De qualquer forma, o build acontece dentro de uma máquina virtual criada dinamicamente pela ferramenta de build debos. O debos usa fakemachine internamente, que por sua vez depende de QEMU/KVM.

Pré-requisitos

Certifique-se de que o repositório git esteja clonado localmente:

$ sudo apt install -y git
$ git clone https://gitlab.com/kalilinux/build-scripts/kali-vm.git
$ cd kali-vm/

Configuração do usuário

Devido aos requisitos do QEMU/KVM, você deve fazer parte do grupo kvm. Você pode verificar fazendo:

$ # Not apart of the group
$ grep kvm /etc/group
kvm:x:104:
$
$ # In the group
$ grep kvm /etc/group
kvm:x:104:kali

Se o seu nome de usuário não aparecer na linha retornada, significa que você não está no grupo e deve se adicionar ao grupo kvm:

$ sudo adduser $USER kvm

Em seguida, faça logout e login novamente para que a alteração entre em vigor.

Build a partir do host

Se for fazer o build diretamente da sua máquina, usando build.sh, você precisará instalar o debos:

$ sudo apt install -y 7zip debos dosfstools qemu-utils zerofree

Em seguida, use o script build.sh para criar uma imagem de VM diretamente na sua máquina.

Build a partir de um contêiner

Se você preferir fazer o build a partir de um contêiner, precisará instalar e configurar o docker ou o podman na sua máquina. Em seguida, use o script build-in-container.sh para criar uma imagem.

build-in-container.sh é simplesmente um wrapper sobre o build.sh. Ele detectará qual mecanismo de contêiner compatível com OCI usar, cuida da criação da imagem de contêiner, se estiver ausente, e por fim inicia o contêiner para realizar o build a partir dele.

O docker exige que o usuário seja adicionado ao grupo Docker, assim como acima com KVM, ou o uso da conta root (por exemplo, $ sudo ./build-in-container.sh). O podman foi testado tanto no modo rootful (por exemplo, $ sudo ./build-in-container.sh) quanto no modo rootless (por exemplo, $ ./build-in-container.sh).

Criando uma imagem

Use build.sh ou build-in-container.sh, de acordo com sua preferência. A partir deste ponto, usaremos build.sh por brevidade.

Exemplos

O melhor ponto de partida, como sempre, é a mensagem de uso:

$ ./build.sh -h
Usage: build.sh <options> [-- <debos options>]

Build a Kali Linux VM image

Build options:
  -a ARCH     Build an image for this architecture, default: amd64
              Supported values: amd64
  -b BRANCH   Kali branch used to build the image, default: kali-rolling
              Supported values: kali-dev kali-last-snapshot kali-rolling
  -f FORMAT   Format to export the image to, default depends on the VARIANT
              Supported values: hyperv ova ovf qemu raw vagrant virtualbox vmware
  -k          Keep raw disk image and other intermediary build artifacts
  -m MIRROR   Mirror used to build the image, default: http://http.kali.org/kali
  -r ROOTFS   rootfs to use to build the image, default: none
  -s SIZE     Size of the disk image in GB, default: 86
  -v VARIANT  Variant of image to build (see below for details), default: generic
              Supported values: generic hyperv qemu rootfs virtualbox vmware
  -x VERSION  What to name the image release as, default: rolling
  -z          Zip images and metadata files after the build

Customization options:
  -D DESKTOP  Desktop environment installed in the image, default: xfce
              Supported values: e17 gnome i3 kde lxde mate xfce none
  -H HOSTNAME Set system host name, default: kali
  -K KEYBOARD Set keyboard layout, default: us
              Refer to the README.md for more details
  -L LOCALE   Set locale, default: en_US.UTF-8
  -P PACKAGES Install extra packages (comma/space separated list)
  -T TOOLSET  The selection of tools to include in the image, default: default
              Supported values: default everything headless large none
  -U USERPASS Username and password, separated by a colon, default: kali:kali
  -Z TIMEZONE Set timezone, default: America/New_York

The different variants of images are:
  generic     Image with all virtualization support pre-installed, default format: raw
  hyperv      Image pre-configured for Hyper-V "Enhanced Session Mode", default format: hyperv
  qemu        Image with QEMU and SPICE guest agents pre-installed, default format: qemu
  rootfs      Not an image, a root filesystem (no bootloader/kernel), packed in a .tar.gz
  virtualbox  Image with VirtualBox guest utilities pre-installed, default format: virtualbox
  vmware      Image with Open VM Tools pre-installed, default format: vmware

The different formats are:
  hyperv      VHDX disk image, powershell install scripts
  ova         streamOptimized VMDK disk image, OVF metadata file, packed in a OVA archive
  ovf         monolithicSparse VMDK disk image, OVF metadata file
  qemu        QCOW2 disk image, no metadata
  raw         sparse disk image, no metadata
  virtualbox  VDI disk image, .vbox metadata file
  vmware      2GbMaxExtentSparse VMDK disk image, VMX metadata file

Supported environment variables:
  http_proxy  HTTP proxy URL, refer to the README.md for more details

Most useful debos options:
  --artifactdir DIR   Set artifact directory, default: images
  --memory, -m  SIZE  Limit amount of memory to build VM in GB, default: 4G
  --scratchsize SIZE  Limit amount of HDD to build VM in GB, default: 45G
  --debug-shell       Get a shell on the VM
  --help, -h          See the complete list of options for debos

Refer to the README.md for examples

As opções padrão criarão uma imagem Kali rolling, com desktop padrão e conjunto de ferramentas padrão para a arquitetura AMD64.

Esta é uma imagem de disco bruta, ou seja, uma imagem binária simples do disco (que pode ser iniciada com QEMU).

Exemplo:

$ ./build.sh

Para criar uma imagem do Kali Linux adaptada para VMware. Isso significa que ela vem com o Open VM Tools pré-instalado, e a imagem produzida está pronta para ser importada "como está" no VMware.

Além disso, vamos criá-la a partir da última versão estável do Kali, e usaremos o GNOME como ambiente de desktop, em vez do padrão usual Xfce:

./build.sh -v vmware -b kali-last-snapshot -D gnome

Para criar uma imagem do Kali Linux projetada para VirtualBox. Ela vem com os utilitários de convidado do VirtualBox pré-instalados, e a imagem pode ser importada "como está" no VirtualBox.

Além disso, queremos um disco virtual de 150 GB e instalaremos a seleção de ferramentas "everything":

./build.sh -v virtualbox -s 150 -S everything

Para criar uma imagem Kali leve, sem ambiente de desktop e sem conjunto de ferramentas padrão. Esta é uma imagem genérica, que vem com suporte para a maioria dos mecanismos de VM existentes. Nós a exportaremos para o formato OVA, adequado para VMware e VirtualBox.

Você pode instalar pacotes adicionais com a opção -P. Use a opção várias vezes (por exemplo, -P pkg1 -P pkg2 ...), ou forneça um valor separado por vírgula/espaço (por exemplo, -P "pkg1,pkg2, pkg3 pkg4"), ou uma mistura de ambos. Vamos também instalar o pacote metasploit-framework:

./build.sh -v generic -f ova -D headless -P metasploit-framework

Ao criar uma série de imagens, pode ser mais conveniente (e mais rápido) dividir o build em duas partes: primeiro, criar um rootfs e, em seguida, criar as imagens reutilizando esse rootfs como ponto de partida.

No exemplo abaixo, primeiro criamos um rootfs kali-rolling e, em seguida, criamos uma série de imagens Vagrant:

./build.sh -b kali-rolling -v rootfs
./build.sh -r images/rootfs-rolling-amd64.tar.gz -f vagrant -v hyperv
./build.sh -r images/rootfs-rolling-amd64.tar.gz -f vagrant -v qemu
./build.sh -r images/rootfs-rolling-amd64.tar.gz -f vagrant -v virtualbox
./build.sh -r images/rootfs-rolling-amd64.tar.gz -f vagrant -v vmware

Para definir as configurações de teclado, use a opção -K. A configuração tem a forma <layouts>/<models>/<variants>/<options>. Cada configuração pode ser omitida (nesse caso, o padrão é usado) ou pode ter vários valores separados por vírgulas. No caso mais simples, você pode apenas querer alterar o layout do teclado, então definiria us para um layout de teclado dos EUA, de para um layout de teclado alemão, e assim por diante. Explicações mais longas e exemplos podem ser encontrados na página de manual keyboard(5). Para a lista de valores suportados, consulte o arquivo /usr/share/X11/xkb/rules/xorg.lst (fornecido pelo pacote xkb-data em sistemas Debian e similares). Este arquivo tem diferentes seções (! layout, ! model, !variant e !option) que listam os valores possíveis para cada configuração. Você também pode verificar o que está configurado no seu sistema com . Há também um atalho para corresponder ao sistema host (ou seja, o que está definido no arquivo ).

Para definir a locale, use a opção -L. Escolha um valor na 1ª coluna de /usr/share/i18n/SUPPORTED, ou verifique o que está configurado no seu sistema com grep -v ^# /etc/locale.gen, ou simplesmente echo $LANG. Há também um atalho -L same para corresponder ao sistema host.

Para definir o fuso horário, use a opção -Z. Olhe em /usr/share/zoneinfo e escolha um diretório e um subdiretório. Em caso de dúvida, execute tzselect para se orientar, ou veja o que está configurado no seu sistema com realpath /etc/localtime. Há também um atalho -Z same para corresponder ao sistema host.

Para definir o nome e a senha do usuário sem privilégios, use a opção -U. O valor é uma única string e o : é usado para separar o nome de usuário da senha.

Aqui, criaremos uma imagem Kali e a configuraremos para imitar o sistema host: mesma locale, mesmo fuso horário e mesmo nome de usuário (com a senha password):

./build.sh -K same -L same -Z same -U $USER:password

Variantes e formatos

Diferentes variantes de imagem podem ser criadas, dependendo do mecanismo de VM no qual você deseja executar a imagem Kali. A VARIANT define principalmente qual pacote extra é instalado na imagem, para adicionar suporte a um mecanismo de VM específico. Em seguida, o FORMAT define o formato do disco virtual e quais arquivos de metadados adicionais serão produzidos.

Se não for definido, o formato (opção -f) é definido automaticamente de acordo com a variante (opção -v). Nem toda combinação de variante e formato faz sentido, então a tabela abaixo tenta resumir as combinações mais comuns.

As imagens generic vêm com pacotes de suporte à virtualização pré-instalados para QEMU, VirtualBox e VMware, daí o nome "generic". Enquanto outras imagens, que visam um mecanismo de VM específico, vêm apenas com suporte para esse mecanismo de virtualização específico.

Apenas o formato ova define um contêiner: o resultado do build é um arquivo .ova, que é simplesmente um arquivo tar. Para outros formatos, o build produz arquivos separados. Eles podem ser agrupados em um arquivo 7z com a opção -z.

Existe também o tipo rootfs: este não é uma imagem. É simplesmente uma árvore do sistema de arquivos raiz do Kali Linux, sem o kernel e o bootloader, empacotada em um arquivo .tar.gz. O principal caso de uso é reutilizá-lo como entrada para criar uma imagem de SO, e não se destina a ser usado fora do sistema de build.

Configuração de proxy de cache

Ao criar imagens de SO, é útil ter um mecanismo de cache em vigor, para evitar baixar todos os pacotes da Internet repetidamente. Para esse fim, o script de build tenta detectar proxies de cache conhecidos que estejam em execução no host local. Primeiro, ele consulta a configuração local do APT Acquire::http::Proxy. Se não estiver definida, ele tenta detectar apt-cacher-ng e squid-deb-proxy verificando se um serviço está escutando na porta padrão. Esse mecanismo não funciona para o approx (um proxy de cache APT bem conhecido), pois ele é iniciado automaticamente sob demanda.

Para substituir essa detecção, você pode exportar a variável de ambiente http_proxy você mesmo. No entanto, lembre-se de que o build acontece dentro de uma máquina virtual QEMU, portanto, localhost no ambiente de build refere-se à VM, não ao host. Se você quiser alcançar o host a partir da VM, provavelmente desejará usar http://10.0.2.2.

Por exemplo, se você quiser usar um proxy que está rodando na sua máquina na porta 9876, use: export http_proxy=http://10.0.2.2:9876. Se quiser garantir que nenhum proxy seja usado, use: export http_proxy=.

Consulte também https://github.com/go-debos/debos#environment-variables para mais detalhes.

Alternativamente, você pode configurar um espelho local.

Criando e reutilizando um rootfs

É possível dividir o build em duas etapas. Você pode primeiro criar um rootfs com ./build.sh -v rootfs e, em seguida, criar uma imagem baseada nesse rootfs com ./build.sh -r ROOTFS_NAME.tar.gz. Isso faz sentido se você planeja criar vários tipos de imagem, por exemplo.

Solução de problemas do build

Memória insuficiente

Quando a área de scratch fica cheia (ou seja, o valor de --scratchsize é muito baixo), o build pode falhar com este tipo de mensagens de erro:

[...]: failed to write (No space left on device)
[...]: Cannot write: No space left on device

Solução: aumente o valor de --scratchsize. Você pode passar argumentos para o debos após o caractere especial --, então, se precisar de, por exemplo, 50G, você pode fazer ./build.sh [...] -- --scratchsize=50G.

Obter um shell na VM quando o build falhar

Ao depurar falhas de build, é conveniente ser levado a um shell dentro da VM onde o build ocorre. Isso é possível fornecendo a opção --debug-shell ao debos: ./build.sh [...] -- --debug-shell.

Solução de problemas em tempo de execução

ovf não compatível com VMware ESXI

Este é um problema conhecido; consulte https://gitlab.com/kalilinux/build-scripts/kali-vm/-/work_items/25#note_1301070132 para uma solução alternativa.