Durante a instalação via `apt`, várias configurações serão solicitadas. As opções padrão podem, em geral, ser aceitas. A única configuração que requer atenção é o endereço de sub-rede usado pela rede libvirt do mofos (padrão: `192.168.90.0/24`).

OU 

Instale as seguintes dependências:
- guestfs-tools
- libnotify-bin
- libvirt
- libvirt-clients
- libvirt-daemon
- make
- python3-click
- python3-click-completion
- python3-colorama
- python3-cryptography
- python3-dbus
- python3-jinja2
- python3-lxml
- python3-prettytable
- python3-pyroute2
- python3-tqdm
- qemu-system-common 
- qemu-system-modules-spice
- socat
- spice-client-gtk
- sudo
- virtinst
- virt-install
- virtiofsd
- virt-manager
- virt-viewer```
make install_files

### Considerações de segurança

O uso de sessões de sistema QEMU/KVM melhora o isolamento entre o host e as máquinas virtuais convidadas, executando instâncias qemu sob um usuário dedicado (`libvirt-qemu`) e aplicando perfis de segurança específicos a cada instância.

No entanto, por padrão, usuários comuns não podem interagir com o socket de sistema do `libvirtd` para gerenciar máquinas, redes e outros recursos. Para conseguir acesso, os usuários devem ser membros do grupo Unix libvirt ou usar sudo. Historicamente, vulnerabilidades de escalonamento local de privilégios exploraram a associação ao grupo libvirt para obter privilégios de root.

Para mitigar esses riscos, este repositório fornece um perfil AppArmor reforçado para o processo `libvirtd` em sistemas que usam AppArmor. Esse perfil restringe significativamente onde o `libvirtd` pode gravar arquivos e quais programas ele pode executar.

Além disso, regras `polkit` são incluídas para controlar ainda mais as ações permitidas aos membros do grupo `libvirt`.

Observe que os perfis AppArmor são empacotados no pacote `deb`, mas não são instalados pelo alvo `install_files` do Makefile e, portanto, devem ser instalados separadamente.

## Configuração do Mofos

O Mofos requer um arquivo de configuração localizado em `$HOME/.config/mofos/config.toml` com configurações mínimas para funcionar corretamente. Um exemplo mínimo de configuração pode ser encontrado em `/usr/share/mofos/config.minimal.toml`, enquanto uma configuração mais abrangente está documentada em `/usr/share/mofos/config.sample.toml`.

O seguinte erro indica que o arquivo de configuração não foi encontrado:```
[-] Copy the sample configuration file from /usr/share/mofos/config.minimal.toml to ~/.config/mofos/config.toml

As principais definições de configuração a personalizar nos arquivos de configuração são as seguintes:
- key (caminho): O arquivo de chave privada SSH usado para acessar as máquinas virtuais. Recomenda-se criar uma chave dedicada para esse fim.
- user (string): O nome de usuário para acesso SSH às máquinas virtuais.
- root_password (valor com hash): A senha raiz com hash a ser definida durante a instalação de um novo template.
- root_ssh_pubkey (string): A chave pública SSH a ser instalada no diretório do usuário root durante a instalação do template.

Além disso, os seguintes parâmetros devem ser configurados para a instalação do template:
- ntp
- dns (opcional se um proxy for fornecido)
- proxy

## Instalar um template

### Configurar o firewall

Como o processo de instalação depende de netboot PXE, é necessária uma conexão ativa com a internet. As seguintes regras de firewall devem ser configuradas:```
sysctl net.ipv4.ip_forward=1
iptables -t nat -I POSTROUTING -s 192.168.90.0/24 -j MASQUERADE
iptables -t nat -I POSTROUTING -s 192.168.91.0/24 -j MASQUERADE

Quando o parâmetro `ip_forward` estiver definido como 1, a cadeia FORWARD deve ser configurada para impedir que outros dispositivos na rede usem o host como roteador.

No geral, as seguintes regras são recomendadas:```
iptables -I INPUT -i mof0 -p udp --sport 68 --dport 67 -j ACCEPT -m comment --comment "mofos dhcp"
iptables -I INPUT -i mof0 -p udp --dport 69 -j ACCEPT -m comment --comment "mofos tftp"
iptables -I OUTPUT -o mof0 -j ACCEPT -m comment --comment "host -> mofos"
iptables -I FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -I FORWARD -i mof0 -j ACCEPT -m comment --comment "mofos ->"
iptables -t nat -I POSTROUTING -s 192.168.90.0/24 -j MASQUERADE
iptables -t nat -I POSTROUTING -s 192.168.91.0/24 -j MASQUERADE

chain input {
  type filter hook input priority 0; policy drop
  
  iifname "install-*" ip daddr 255.255.255.255 udp sport 68 udp dport 67 accept comment "mofos dhcp"
  iifname "mof0" ip daddr 255.255.255.255 udp sport 68 udp dport 67 accept comment "mofos dhcp"
  iifname "install-*" udp dport 69 accept comment "mofos tftp"
}

chain forward {
  type filter hook forward priority 0; policy drop
  
  ct state established,related accept;
  ct state invalid drop;
  
  iifname "mof0" counter accept
  iifname "install-*" counter accept
}

chain output {
  type filter hook output priority 0; policy drop
  
  oifname "mof0" counter accept
}

É recomendável restringir as regras de mascaramento e encaminhamento com base nas suas necessidades específicas, para evitar que as máquinas virtuais da Mofos acessem toda a rede do host.

O isolamento entre máquinas virtuais é aplicado automaticamente por um hook do libvirt, que requer nft para funcionar corretamente.


### Instalação

O primeiro passo é construir a camada inicial: o template. Por padrão, a Mofos pode instalar um template baseado no Debian 12.```
mofos template create debian-template

A variante é definida como `debian11` porque no Debian 12, a variante `osinfo` para o Debian 12 ainda não é instalável via libvirt.

Para instalar outra distribuição, modifique o dicionário localizado em `/usr/lib/python3/dist-packages/mofos/settings.py`.

Quando o comando acima é executado, o Mofos baixa os arquivos netboot e armazena em cache o arquivo `tar.gz` em `$HOME/.cache/template-installer`. Atualmente, se o arquivo netboot já existir, o Mofos não o baixará novamente. Isso pode causar erros se o arquivo em cache estiver desatualizado. Se tais erros ocorrerem durante a instalação, remover o arquivo em cache forçará o Mofos a baixar uma versão atualizada, o que deve resolver o problema.

Em seguida, o arquivo é extraído para `/tmp`, e o libvirt é configurado para servir seu conteúdo via TFTP.

A máquina virtual de template é então criada e configurada para inicializar via PXE, instalando a distribuição especificada usando o arquivo preseed fornecido (por padrão `/usr/share/mofos/templates/debian/preseed.cfg.j2`). Este arquivo é um template `jinja2`; antes de copiá-lo para o diretório raiz do TFTP, as variáveis dos arquivos de configuração (`ntp`, `proxy`, `dns`, `root_password`) são injetadas.

Ao final da instalação, o script `postinstall` é colocado no diretório TFTP e executado no template. Por padrão, é usado o script localizado em `/usr/share/mofos/templates/postinstall.sh.j2`. Este template `jinja2` injeta a chave pública SSH a ser configurada no template.

Além de configurar a chave pública SSH do root, as seguintes operações são executadas:
- Desabilitar o serviço SSH padrão e habilitar um SSHD sobre soquetes virtuais (vsock).
- Esvaziar o arquivo `/etc/resolv.conf`.
- Configurar o timeout do GRUB para 0 segundo.
- Instalar um hook de initramfs que monta o overlayfs quando a partição rotulada como `overlay` é detectada.

Assim que a instalação for concluída, a máquina virtual do libvirt é obtida e compactada em um arquivo `qcow2` local salvo no diretório atual.```
$ mofos template create debian-template
[*] Installing debian-template
[*] Configure the SSH host key of the template
[*] Waiting for the installation to be complete
[*] Installation is complete
[*] Downloading the resulting qcow2 disk
[*] Compressing the disk
[*] Save template's public ssh host key
[+] Template installation finished
[+] Template disk is debian-template-disk.qcow2

Este arquivo é usado automaticamente durante o processo de importação.

### Importar

O próximo passo é importar o arquivo de template `qcow2` criado para o Mofos.```
$ mofos template import debian-template debian-template-disk.qcow2 http://debian.org/debian/11 
[*] Uploading debian-template-disk.qcow2 to mofos pool
[*] Creating the virtual machine debian-template
[*] Configuring the template metadata
[*] Configuring the SSH key
[+] debian-template successfully imported

A partir deste ponto, o template pode ser iniciado e acessado para modificação conforme necessário.```
$ mofos start debian-template
$ mofos ls
+----+-----------------+---------+-------------+-------+-----+----------------+
| Id | Name            | State   | Description | Alias | Cid | IPv4 address   |
+----+-----------------+---------+-------------+-------+-----+----------------+
| 3  | debian-template | running |             |       | 3   | 192.168.90.202 |
+----+-----------------+---------+-------------+-------+-----+----------------+

## Criar o disco vazio da camada superior

O comando a seguir cria uma camada superior vazia com o rótulo especificado na única partição do disco:```
$ mofos template create-overlay-disk

Tenha em mente que as conexões SSH são feitas por meio de soquetes virtuais, portanto você não pode acessar via SSH diretamente a máquina recém-criada. Em vez disso, você deve usar o comando mofos ssh. Alternativamente, você pode criar uma configuração SSH especificando um `ProxyCommand `para acessar a porta SSH da máquina:```
$ mofos inventory --format ssh
Host debian-template
	User user
	PasswordAuthentication no
	IdentityFile /home/user/.ssh/id_ed25519
	ProxyCommand /usr/bin/mofos proxy-cmd %h
	CanonicalizeHostname=no

Host test
	User user
	PasswordAuthentication no
	IdentityFile /home/user/.ssh/id_ed25519
	ProxyCommand /usr/bin/mofos proxy-cmd %h
	CanonicalizeHostname=no

Durante uma sessão `mofos ssh`, um socket `ControlMaster` é estabelecido antecipadamente para acelerar conexões subsequentes. É por isso que o MOTD não é exibido.

## Customização

Para simplificar a personalização de templates e máquinas virtuais, o Mofos introduz o conceito de hooks e tags. Para cada tag, um hook correspondente (um script Bash) pode ser executado para realizar ações automatizadas na máquina virtual ou template alvo e configurá-lo adequadamente.

Hooks mínimos estão localizados em `/usr/share/mofos/hooks`. São scripts Bash simples que recebem as seguintes entradas:```
TAG=$1
NAME=$2
OS=$3
DISTRIB=$4
HOSTNAME=$5

Este script cria dinamicamente um inventário e executa um playbook contra ele.

### Máquina virtual - novo hook

Durante a criação da máquina virtual, outro hook pode ser usado, por exemplo, para randomizar o hostname.

Por padrão, o Mofos gera um alias com base na convenção clássica de nomenclatura do Windows (por exemplo, `DESKTOP-2BF9753`). Esse nome, juntamente com outras informações, é passado para o script do hook:```
#!/bin/bash

TAG=$1
NAME=$2
OS=$3
DISTRIB=$4
HOSTNAME=$5

if [ -z "${TAG}" ] || [ -z "${NAME}" ] || [ -z "${OS}" ] ; then
  exit 1
fi

if [ -z "${HOSTNAME}" ] ; then
  HOSTNAME="${NAME}"
fi

mofos run -u root "${NAME}" "echo ${HOSTNAME} > /etc/hostname && hostname ${HOSTNAME}"

Então, durante a criação da máquina virtual, este script será executado:```
$ mofos new test2 --tags test 
[*] New virtual machine name is test2
[+] Virtual machine test2 successfully created
[*] Triggering post install actions
[*] Create SSH known_hosts entries for test2
[*] Waiting for test2 to be up
[*] Running new hook: test
[+] test2 is ready

Similar à fase de instalação, os playbooks do Ansible também podem ser executados nesta etapa. Nesse caso, o comando `mofos inventory` pode ser usado para gerar um inventário do Ansible, simplificando o processo de seleção e acesso às máquinas virtuais:```
$ mofos inventory 
{
    "_meta": {
        "hostvars": {
            "debian-template": {
                "ansible_host": "debian-template",
                "ansible_ssh_common_args": "-o ProxyCommand='/usr/bin/mofos proxy-cmd %h'  -o CanonicalizeHostname=no"
            },
            "test": {
                "ansible_host": "test",
                "ansible_ssh_common_args": "-o ProxyCommand='/usr/bin/mofos proxy-cmd %h'  -o CanonicalizeHostname=no"
            },
            "test2": {
                "ansible_host": "test2",
                "ansible_ssh_common_args": "-o ProxyCommand='/usr/bin/mofos proxy-cmd %h'  -o CanonicalizeHostname=no"
            }
        }
    },
    "debian": [
        "debian-template",
        "test",
        "test2"
    ],
    "test": [
        "test2"
    ]

### Máquina virtual - início do hook

Da mesma forma, o hook de início é executado quando uma máquina virtual inicia. Ele normalmente é usado para iniciar os serviços necessários para a máquina virtual.

Por exemplo, para habilitar a integração transparente com o Windows dentro da máquina virtual, você pode instalar o `Xpra`.

Primeiro, instale o `ansible`:```
# apt install ansible

O bloco de entrada está vazio. Não há conteúdo para traduzir.```
$ ansible-playbook playbooks/user.yml -l test2
Using /home/user/mofos/ansible/ansible.cfg as config file
[WARNING]: Found both group and host with same name: test

PLAY [Create and configure a user]

[...]

PLAY RECAP
test2 : ok=4 changed=2 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0   

Em seguida, execute o playbook `Xpra`. Este playbook instala pacotes dos espelhos Debian. Observe que a rede Mofos não configura DNS, proxy ou gateway padrão por padrão. Eles devem ser configurados antes de executar o playbook.

Nenhuma modificação no playbook é necessária por padrão.```
ansible-playbook playbooks/xpra.yml -l test2

Caso contrário, o serviço será iniciado automaticamente na próxima reinicialização.

Em seguida, o serviço do cliente local também pode ser iniciado manualmente:```
$ mofos xpra start test2

Para garantir que este mecanismo funcione de forma suave e automática, o comando `mofos xpra` pode ser iniciado a partir do hook de início.```bash
#!/bin/bash

TAG=$1
NAME=$2
OS=$3
DISTRIB=$4
HOSTNAME=$5

if [ -z "${TAG}" ] || [ -z "${NAME}" ] ; then
exit 1
fi

mofos xpra start "${NAME}"

### Clipboard

O Mofos também pode gerenciar a área de transferência entre máquinas virtuais e o host. A ideia é configurar um atalho de teclado específico para acionar uma conexão SSH para a VM atualmente em foco, seja para puxar a área de transferência X11 ou para enviar conteúdo para ela.

Para enviar conteúdo para a área de transferência X11 da máquina virtual:```
mofos clipboard in pentest-0

Para cada operação, o mofos estabelecerá uma ligação SSH à máquina virtual e utilizará `xclip` e, no host, `wl-copy` ou `xclip`, dependendo da tecnologia de janelas (Wayland vs X11).

O nome da máquina no rastreio acima pode ser omitido; nesse caso, o script identificará a máquina virtual atualmente focada e atacá-la-á.

Se estiver a utilizar GNOME Wayland, poderá ser necessário instalar a extensão do shell GNOME `[email protected]` usando `sudo make install_gnome_extension`.
Terá de terminar a sessão e iniciá-la novamente para garantir que a extensão está instalada.

### Configurar roteamento entre máquinas

Existem duas opções no mofos para rotear uma VM:
- `mofos route`, que recebe um gateway e configura uma `ip rule` no host para rotear a máquina virtual através desse gateway.
- `mofos pivot`, que recebe outra máquina mofos, obtém o seu endereço IP e configura-o como gateway predefinido para a máquina virtual atual.

Ambas as opções podem aceitar um servidor DNS para o configurar.

### Configurar tunelamento através de caixas de pentest

O comando `mofos tunnel` configura uma VPN SSH (`ssh -w`) para rotear o tráfego de uma máquina mofos através de um servidor. Este recurso depende de algumas configurações:

Concretamente, o comando `mofos tunnel` executa as seguintes ações (sem magia negra aqui):
1. Cria uma interface tun local (`sudo /usr/libexec/mofos/mofosnet.py tun add pentest_box`) e atribui um endereço IP a essa interface.
2. Executa o `tunneling.command` no servidor remoto; este comando deve criar uma interface tun para ser depois ligada à interface local (`/usr/libexec/mofos/mofosnet.py sshvpn start pentest_box`).
3. Roteia o tráfego de uma máquina mofos através do gateway da caixa remota (`/usr/libexec/mofos/mofosnet.py route mofos_vm_ip gateway_ip`); o gateway predefinido da máquina virtual mofos também é alterado.

O `tunneling.command` deve ser definido no ficheiro de configuração `/etc/mofos/mofosnet.toml`. Por exemplo:```toml
[tunneling.command]
start = "sudo ssh-vpn start"  # the peer remote address will be supplied as argv[1]
stop = "sudo ssh-vpn stop"

A opção `force` desanexa e reanexa um dispositivo. É comumente usada para
reanexar um dispositivo que foi desconectado sem antes ter sido desanexado.

Nota: anexar um dispositivo USB só é válido durante a vida atual da máquina virtual. Quando ela é interrompida, o dispositivo é desanexado automaticamente.

### Gerenciamento de dispositivos PCI

Semelhante aos dispositivos USB, o mofos permite anexar um dispositivo PCI a uma máquina virtual em execução; os comandos são os mesmos.

Uma limitação adicional diz respeito a alguns dispositivos PCI que pertencem a um grupo. Por exemplo, anexar a placa de ethernet a uma máquina virtual em execução pode exigir mover todo o grupo PCI para dentro da máquina virtual. Como isso não pode ser feito sequencialmente, ainda não é suportado. No entanto, para um dispositivo PCI único, como uma placa de rede Wi-Fi, funciona perfeitamente.

### Pastas compartilhadas

O comando `mofos mount` cria pastas compartilhadas e pode montar o sistema de arquivos recém-adicionado em um diretório dentro da máquina virtual. O comando `mofos umount` desmontará o diretório e removerá as pastas compartilhadas da configuração da máquina virtual.

Esse mecanismo depende da tecnologia `virtiofsd`, que requer a ativação da memória compartilhada; isso agora é feito por padrão ao criar uma máquina virtual. Caso contrário, o seguinte comando a ativará:```console
virt-xml -c qemu:///system --edit --memorybacking source.type=memfd,access.mode=shared DOMAIN

A variável `SHARE_DIRS` é reutilizada na política, no entanto, devido a limitações do apparmor, não é possível reutilizá-la para diretivas `pivot_root`. Portanto, é necessário adaptar manualmente as diretivas `pivot_root` para cada um dos diretórios compartilhados.

Para montar um diretório local:```
mofos mount test ./Public/share -d /home/user/share

- O OpenSSH deve ser configurado com um shell `PowerShell` em vez de `cmd.exe`.```powershell
New-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" `
                 -Name DefaultShell `
                 -Value "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" `
                 -PropertyType String `
                 -Force

## Autocompletar

O autocompletar deve funcionar de forma nativa para `bash` e `fish`. Para `zsh`, pode ser necessário executar os seguintes comandos:```
autoload -Uz compinit
compinit
source /usr/share/zsh/vendor-completions/_mofos

Com interfaces de rede legadas `/etc/network/interfaces`:```
iface eth0 inet dhcp
  client no