Durante l'installazione tramite `apt`, verranno richieste varie impostazioni. Le opzioni predefinite possono generalmente essere accettate. L'unica impostazione che richiede attenzione è l'indirizzo di sottorete utilizzato dalla rete libvirt di mofos (predefinito: `192.168.90.0/24`).

OPPURE 

Installare le seguenti dipendenze:
- 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

### Considerazioni sulla sicurezza

L'uso di sessioni di sistema QEMU/KVM migliora l'isolamento tra le macchine virtuali host e guest eseguendo le istanze qemu sotto un utente dedicato (`libvirt-qemu`) e applicando profili di sicurezza specifici a ciascuna istanza.

Tuttavia, per impostazione predefinita, gli utenti normali non possono interagire con il socket di sistema `libvirtd` per gestire macchine, reti e altre risorse. Per ottenere l'accesso, gli utenti devono essere membri del gruppo Unix libvirt o utilizzare sudo. Storicamente, le vulnerabilità di escalazione dei privilegi locali hanno sfruttato l'appartenenza al gruppo libvirt per ottenere i privilegi di root.

Per mitigare questi rischi, questo repository fornisce un profilo AppArmor rafforzato per il processo `libvirtd` sui sistemi che utilizzano AppArmor. Questo profilo limita significativamente le aree in cui `libvirtd` può scrivere file e i programmi che può eseguire.

Inoltre, sono incluse regole `polkit` per controllare ulteriormente le azioni consentite ai membri del gruppo `libvirt`.

Si noti che i profili AppArmor sono inclusi nel pacchetto `deb` ma non vengono installati dal target `install_files` del Makefile e pertanto devono essere installati separatamente.

## Configurazione di Mofos

Mofos richiede un file di configurazione situato in `$HOME/.config/mofos/config.toml` con impostazioni minime per funzionare correttamente. Un esempio di configurazione minimale è disponibile in `/usr/share/mofos/config.minimal.toml`, mentre una configurazione più completa è documentata in `/usr/share/mofos/config.sample.toml`.

Il seguente errore indica che il file di configurazione non è stato trovato:```
[-] Copy the sample configuration file from /usr/share/mofos/config.minimal.toml to ~/.config/mofos/config.toml

The key configuration settings to customize in the configuration files are as follows:
- key (percorso): il file della chiave privata SSH utilizzato per accedere alle macchine virtuali. Si consiglia di creare una chiave dedicata a questo scopo.
- user (stringa): il nome utente per l'accesso SSH alle macchine virtuali.
- root_password (valore hash): la password di root con hash da impostare durante l'installazione di un nuovo template.
- root_ssh_pubkey (stringa): la chiave pubblica SSH da installare nella directory dell'utente root durante l'installazione del template.

Inoltre, per l'installazione del template è necessario configurare i seguenti parametri:
- ntp
- dns (facoltativo se viene fornito un proxy)
- proxy

## Installare un template

### Configurare il firewall

Poiché il processo di installazione si basa sul netboot PXE, è richiesta una connessione Internet attiva. È opportuno configurare le seguenti regole del firewall:```
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 il parametro `ip_forward` è impostato a 1, la catena FORWARD dovrebbe essere configurata per impedire ad altri dispositivi sulla rete di utilizzare l'host come router.

In generale, si consigliano le seguenti regole:```
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
}

Si consiglia di limitare le regole di masquerade e forwarding in base alle proprie esigenze specifiche, per impedire alle macchine virtuali di mofos di accedere all'intera rete dell'host.

L'isolamento tra le macchine virtuali è applicato automaticamente da un hook di libvirt, che richiede nft per funzionare correttamente.


### Installazione

Il primo passo è costruire il livello iniziale: il template. Per impostazione predefinita, Mofos può installare un template basato su Debian 12.```
mofos template create debian-template

La variante è impostata su `debian11` perché in Debian 12 la variante `osinfo` per Debian 12 non è ancora installabile tramite libvirt.

Per installare un'altra distribuzione, modificare il dizionario situato in `/usr/lib/python3/dist-packages/mofos/settings.py`.

Quando viene eseguito il comando precedente, Mofos scarica i file netboot e memorizza nella cache l'archivio `tar.gz` in `$HOME/.cache/template-installer`. Attualmente, se l'archivio netboot esiste già, Mofos non lo scarica di nuovo. Questo può causare errori se l'archivio in cache è obsoleto. Se si verificano tali errori durante l'installazione, la rimozione dell'archivio in cache costringerà Mofos a scaricare una versione aggiornata, risolvendo il problema.

Successivamente, l'archivio viene estratto in `/tmp` e libvirt viene configurato per servire il suo contenuto tramite TFTP.

La macchina virtuale template viene quindi creata e impostata per l'avvio via PXE, installando la distribuzione specificata tramite il file preseed fornito (per impostazione predefinita `/usr/share/mofos/templates/debian/preseed.cfg.j2`). Questo file è un template `jinja2`; prima di copiarlo nella directory root TFTP, vengono iniettate le variabili provenienti dai file di configurazione (`ntp`, `proxy`, `dns`, `root_password`).

Al termine dell'installazione, lo script `postinstall` viene collocato nella directory TFTP ed eseguito sul template. Per impostazione predefinita viene utilizzato lo script situato in `/usr/share/mofos/templates/postinstall.sh.j2`. Questo template `jinja2` inietta la chiave pubblica SSH da configurare sul template.

Oltre alla configurazione della chiave pubblica SSH di root, vengono eseguite le seguenti operazioni:
- Disabilitare il servizio SSH standard e abilitare un SSHD su socket virtuali (vsock).
- Svuotare il file `/etc/resolv.conf`.
- Configurare il timeout di GRUB a 0 secondi.
- Installare un hook initramfs che monta l'overlayfs quando viene rilevata una partizione etichettata `overlay`.

Una volta completata l'installazione, la macchina virtuale libvirt viene recuperata e compressa in un file `qcow2` locale salvato nella directory corrente.```
$ 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

Questo file viene utilizzato automaticamente durante il processo di importazione.

### Importazione

Il passo successivo è importare il file di template `qcow2` creato in 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

Da questo punto, il template può essere avviato e accessibile per la modifica secondo necessità.```
$ mofos start debian-template
$ mofos ls
+----+-----------------+---------+-------------+-------+-----+----------------+
| Id | Name            | State   | Description | Alias | Cid | IPv4 address   |
+----+-----------------+---------+-------------+-------+-----+----------------+
| 3  | debian-template | running |             |       | 3   | 192.168.90.202 |
+----+-----------------+---------+-------------+-------+-----+----------------+

## Crea il disco vuoto del livello superiore

Il seguente comando crea un livello superiore vuoto con l'etichetta specificata sull'unica partizione del disco:```
$ mofos template create-overlay-disk

Tieni presente che le connessioni SSH vengono effettuate tramite socket virtuali, quindi non puoi connetterti direttamente in SSH alla macchina appena creata. Devi invece usare il comando `mofos ssh`. In alternativa, puoi creare una configurazione SSH specificando un `ProxyCommand` per accedere alla porta SSH della macchina:```
$ 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 una sessione `mofos ssh`, un socket `ControlMaster` viene stabilito in anticipo per velocizzare le connessioni successive. Ecco perché la MOTD non viene visualizzata.

## Personalizzazione

Per semplificare la personalizzazione di modelli e macchine virtuali, Mofos introduce il concetto di hook e tag. Per ogni tag, un hook corrispondente (uno script Bash) può essere eseguito per eseguire azioni automatizzate sulla macchina virtuale o sul modello di destinazione e configurarlo di conseguenza.

Gli hook minimi si trovano in `/usr/share/mofos/hooks`. Questi sono semplici script Bash che ricevono i seguenti input:```
TAG=$1
NAME=$2
OS=$3
DISTRIB=$4
HOSTNAME=$5

Questo script crea dinamicamente un inventory ed esegue un playbook su di esso.

### Macchina virtuale - hook new

Durante la creazione della macchina virtuale, può essere utilizzato un altro hook, ad esempio, per randomizzare l'hostname.

Per impostazione predefinita, Mofos genera un alias basato sulla convenzione di denominazione classica di Windows (ad es., `DESKTOP-2BF9753`). Questo nome, insieme ad altre informazioni, viene passato allo script 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}"

Quindi, durante la creazione della macchina virtuale, questo script verrà eseguito:```
$ 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

Analogamente alla fase di installazione, i playbook Ansible possono essere eseguiti anche in questa fase. In questo caso, il comando `mofos inventory` può essere utilizzato per generare un inventario Ansible, semplificando il processo di selezione e accesso alle macchine virtuali:```
$ 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"
    ]

### Macchina virtuale - hook di avvio

Analogamente, l'hook di avvio viene eseguito quando viene avviata una macchina virtuale. Viene tipicamente utilizzato per avviare i servizi richiesti dalla macchina virtuale.

Ad esempio, per abilitare un'integrazione fluida con Windows all'interno della macchina virtuale, puoi installare `Xpra`.

Per prima cosa installa `ansible`:```
# apt install ansible

Il contenuto del chunk è vuoto.```
$ 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   

Successivamente, esegui il playbook `Xpra`. Questo playbook installa i pacchetti dai mirror Debian. Tieni presente che la rete Mofos non configura DNS, proxy o un gateway predefinito per impostazione predefinita. Questi devono essere configurati prima di eseguire il playbook.

Non sono richieste modifiche al playbook per impostazione predefinita.```
ansible-playbook playbooks/xpra.yml -l test2

Altrimenti, il servizio si avvierà automaticamente al prossimo riavvio.

Successivamente, il servizio client locale può anche essere avviato manualmente:```
$ mofos xpra start test2

Per garantire che questo meccanismo funzioni senza intoppi e automaticamente, il comando `mofos xpra` può essere avviato dall'hook di avvio.```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}"

### Appunti

Mofos può anche gestire gli appunti tra le macchine virtuali e il sistema host. L'idea è di configurare una specifica combinazione di tasti per attivare una connessione SSH alla VM attualmente attiva, sia per recuperare gli appunti X11 sia per inviarvi contenuti.

Per inviare contenuti negli appunti X11 della macchina virtuale:```
mofos clipboard in pentest-0

Per ogni operazione, mofos stabilirà una connessione SSH alla macchina virtuale e userà `xclip` e sull'host `wl-copy` o `xclip` a seconda della tecnologia di windows (wayland vs X11).

Il nome della macchina nella traccia sopra può essere omesso; in questo caso, lo script identificherà la macchina virtuale attualmente in primo piano e la userà come destinazione.

Se utilizzi Gnome wayland, potrebbe essere necessario installare l'estensione della shell Gnome `[email protected]` usando `sudo make install_gnome_extension`.
Dovrai disconnetterti e riconnetterti per assicurarti che l'estensione sia installata.

### Configurare il routing tra le macchine

In mofos esistono due opzioni per instradare una VM:
- `mofos route` che prende un gateway e configura una `ip rule` sull'host per instradare la macchina virtuale attraverso questo gateway.
- `mofos pivot` che prende un'altra macchina mofos, recupera il suo indirizzo IP e
lo configura come gateway predefinito per la macchina virtuale corrente.

Entrambe le opzioni possono accettare un server DNS da configurare.

### Configurare il tunneling attraverso le pentest box

Il comando `mofos tunnel` configura una VPN SSH (`ssh -w`) per instradare il traffico di una
macchina mofos attraverso un server. Questa funzionalità si basa su poche configurazioni:

Concretamente il comando `mofos tunnel` esegue le seguenti azioni (niente magie oscure qui):
1. Crea un'interfaccia tun locale (`sudo /usr/libexec/mofos/mofosnet.py tun add pentest_box`) e assegna un indirizzo IP a questa interfaccia.
2. Esegue il `tunneling.command` sul server remoto; questo comando dovrebbe creare un'interfaccia tun da collegare poi con quella locale (`/usr/libexec/mofos/mofosnet.py sshvpn start pentest_box`).
3. Instrada il traffico di una macchina mofos attraverso il gateway della box remota (`/usr/libexec/mofos/mofosnet.py route mofos_vm_ip gateway_ip`); anche il gateway predefinito della macchina virtuale mofos viene modificato.

Il `tunneling.command` deve essere definito nel file di configurazione `/etc/mofos/mofosnet.toml`. Per esempio:```toml
[tunneling.command]
start = "sudo ssh-vpn start"  # the peer remote address will be supplied as argv[1]
stop = "sudo ssh-vpn stop"

L'opzione `force` scollega e ricollega un dispositivo. È comunemente usata per
riagganciare un dispositivo che è stato scollegato senza essere stato prima staccato.

Nota: il collegamento di un dispositivo USB è valido solo per la vita corrente della macchina virtuale. Quando questa si ferma, il dispositivo viene scollegato automaticamente.

### Gestione dei dispositivi PCI

Analogamente ai dispositivi USB, mofos consente di collegare un dispositivo PCI a una macchina virtuale in esecuzione; i comandi sono gli stessi.

Un'ulteriore limitazione riguarda alcuni dispositivi PCI che appartengono a un gruppo. Ad esempio, collegare la scheda ethernet a una macchina virtuale in esecuzione potrebbe richiedere lo spostamento dell'intero gruppo PCI all'interno della macchina virtuale. Poiché non può essere fatto in sequenza, non è ancora supportato. Tuttavia, per un singolo dispositivo PCI come una scheda di rete Wi-Fi, funziona correttamente.

### Cartelle condivise

Il comando `mofos mount` crea una cartella condivisa e può montare il filesystem appena aggiunto in una directory all'interno della macchina virtuale. Il comando `mofos umount` smonterà la directory e rimuoverà le cartelle condivise dalla configurazione della macchina virtuale.

Questo meccanismo si basa sulla tecnologia `virtiofsd` che richiede l'abilitazione della memoria condivisa; ora questa viene abilitata per impostazione predefinita quando si crea una macchina virtuale. In caso contrario, il seguente comando la abiliterà:```console
virt-xml -c qemu:///system --edit --memorybacking source.type=memfd,access.mode=shared DOMAIN

La variabile `SHARE_DIRS` viene riutilizzata nella policy, tuttavia, a causa delle limitazioni di apparmor, non è possibile riutilizzarla per le direttive `pivot_root`. Pertanto, è necessario adattare manualmente le direttive `pivot_root` per ciascuna delle directory condivise.

Per montare una directory locale:```
mofos mount test ./Public/share -d /home/user/share

OpenSSH dovrebbe essere configurato con una shell `PowerShell` invece di `cmd.exe`.```powershell
New-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" `
                 -Name DefaultShell `
                 -Value "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" `
                 -PropertyType String `
                 -Force

## Autocompletamento

L'autocompletamento dovrebbe essere gestito automaticamente per `bash` e `fish`. Per `zsh`, potrebbe essere necessario eseguire i seguenti comandi:```
autoload -Uz compinit
compinit
source /usr/share/zsh/vendor-completions/_mofos

Con le interfacce di rete legacy `/etc/network/interfaces`:```
iface eth0 inet dhcp
  client no