Lors de l'installation via `apt`, divers paramètres vous seront demandés. Les options par défaut peuvent généralement être acceptées. Le seul paramètre qui requiert votre attention est l'adresse de sous-réseau utilisée par le réseau libvirt mofos (par défaut : `192.168.90.0/24`).

OU

Installez les dépendances suivantes :
- 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

### Considérations de sécurité

L'utilisation de sessions système QEMU/KVM améliore l'isolation entre les machines virtuelles hôte et invitées en exécutant les instances qemu sous un utilisateur dédié (`libvirt-qemu`) et en appliquant des profils de sécurité spécifiques à chaque instance.

Cependant, par défaut, les utilisateurs ordinaires ne peuvent pas interagir avec le socket système `libvirtd` pour gérer les machines, les réseaux et d'autres ressources. Pour obtenir l'accès, les utilisateurs doivent soit être membres du groupe Unix libvirt, soit utiliser sudo. Historiquement, des vulnérabilités d'élévation de privilèges locaux ont exploité l'appartenance au groupe libvirt pour obtenir les privilèges root.

Pour atténuer ces risques, ce dépôt fournit un profil AppArmor renforcé pour le processus `libvirtd` sur les systèmes utilisant AppArmor. Ce profil restreint considérablement les endroits où `libvirtd` peut écrire des fichiers et les programmes qu'il peut exécuter.

De plus, des règles `polkit` sont incluses pour mieux contrôler les actions autorisées pour les membres du groupe `libvirt`.

Notez que les profils AppArmor sont empaquetés dans le paquet `deb` mais ne sont pas installés par la cible `install_files` du Makefile et doivent donc être installés séparément.

## Configuration de Mofos

Mofos nécessite un fichier de configuration situé dans `$HOME/.config/mofos/config.toml` avec des paramètres minimaux pour fonctionner correctement. Un exemple de configuration minimale se trouve dans `/usr/share/mofos/config.minimal.toml`, tandis qu'une configuration plus complète est documentée dans `/usr/share/mofos/config.sample.toml`.

L'erreur suivante indique que le fichier de configuration n'a pas été trouvé :```
[-] Copy the sample configuration file from /usr/share/mofos/config.minimal.toml to ~/.config/mofos/config.toml

Les principaux paramètres de configuration à personnaliser dans les fichiers de configuration sont les suivants :
- key (chemin): Le fichier de clé privée SSH utilisé pour accéder aux machines virtuelles. Il est recommandé de créer une clé dédiée à cet effet.
- user (chaîne): Le nom d'utilisateur pour l'accès SSH aux machines virtuelles.
- root_password (valeur hachée): Le mot de passe root haché à définir lors de l'installation d'un nouveau modèle.
- root_ssh_pubkey (chaîne): La clé publique SSH à installer dans le répertoire de l'utilisateur root lors de l'installation du modèle.

De plus, les paramètres suivants doivent être configurés pour l'installation du modèle :
- ntp
- dns (facultatif si un proxy est fourni)
- proxy

## Installer un modèle

### Configurer le pare-feu

Étant donné que le processus d'installation repose sur le netboot PXE, une connexion Internet active est requise. Les règles de pare-feu suivantes doivent être configurées :```
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

Lorsque le paramètre `ip_forward` est défini sur 1, la chaîne FORWARD doit être configurée pour empêcher les autres appareils du réseau d'utiliser l'hôte comme routeur.

Dans l'ensemble, les règles suivantes sont recommandées :```
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
}

Il est recommandé de restreindre les règles de masquerade et de transfert en fonction de vos besoins spécifiques, afin d'empêcher les machines virtuelles de mofos d'accéder à l'ensemble du réseau hôte.

L'isolation entre les machines virtuelles est automatiquement appliquée par un hook libvirt, qui nécessite nft pour fonctionner correctement.

### Installation```
mofos template create debian-template

La variante est définie sur `debian11` car, dans Debian 12, la variante `osinfo` pour Debian 12 n'est pas encore installable via libvirt.

Pour installer une autre distribution, modifiez le dictionnaire situé dans `/usr/lib/python3/dist-packages/mofos/settings.py`.

Lorsque la commande ci-dessus est exécutée, Mofos télécharge les fichiers netboot et met en cache l'archive `tar.gz` dans `$HOME/.cache/template-installer`. Actuellement, si l'archive netboot existe déjà, Mofos ne la téléchargera pas à nouveau. Cela peut provoquer des erreurs si l'archive en cache est obsolète. Si de telles erreurs surviennent lors de l'installation, la suppression de l'archive en cache forcera Mofos à télécharger une version mise à jour, ce qui devrait résoudre le problème.

Ensuite, l'archive est extraite dans `/tmp`, et libvirt est configuré pour servir son contenu via TFTP.

La machine virtuelle modèle est ensuite créée et configurée pour démarrer via PXE, installant la distribution spécifiée à l'aide du fichier preseed fourni (par défaut `/usr/share/mofos/templates/debian/preseed.cfg.j2`). Ce fichier est un modèle `jinja2` ; avant de le copier dans le répertoire racine TFTP, les variables des fichiers de configuration (`ntp`, `proxy`, `dns`, `root_password`) sont injectées.

À la fin de l'installation, le script `postinstall` est placé dans le répertoire TFTP et exécuté sur le modèle. Par défaut, le script situé à `/usr/share/mofos/templates/postinstall.sh.j2` est utilisé. Ce modèle `jinja2` injecte la clé publique SSH à configurer sur le modèle.

En plus de configurer la clé publique SSH de root, les opérations suivantes sont effectuées :
- Désactiver le service SSH standard et activer un SSHD sur des sockets virtuels (vsock).
- Vider le fichier `/etc/resolv.conf`.
- Configurer le délai d'attente de GRUB à 0 seconde.
- Installer un hook initramfs qui monte l'overlayfs lorsqu'une partition étiquetée `overlay` est détectée.

Une fois l'installation terminée, la machine virtuelle libvirt est récupérée et compressée dans un fichier `qcow2` local enregistré dans le répertoire courant.```
$ 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

Ce fichier est automatiquement utilisé pendant le processus d'importation.

### Importation

L'étape suivante consiste à importer le fichier modèle `qcow2` créé dans 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

À partir de ce point, le modèle peut être démarré et accessible pour modification si nécessaire.```
$ mofos start debian-template
$ mofos ls
+----+-----------------+---------+-------------+-------+-----+----------------+
| Id | Name            | State   | Description | Alias | Cid | IPv4 address   |
+----+-----------------+---------+-------------+-------+-----+----------------+
| 3  | debian-template | running |             |       | 3   | 192.168.90.202 |
+----+-----------------+---------+-------------+-------+-----+----------------+

## Créer le disque vide de la couche supérieure

La commande suivante crée une couche supérieure vide avec l'étiquette spécifiée sur la seule partition du disque :```
$ mofos template create-overlay-disk

Gardez à l’esprit que les connexions SSH sont établies via des sockets virtuelles, vous ne pouvez donc pas vous connecter directement en SSH à la machine nouvellement créée. Vous devez plutôt utiliser la commande `mofos ssh`. Vous pouvez également créer une configuration SSH spécifiant un `ProxyCommand `pour accéder au port SSH de la machine :```
$ 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

Lors d'une session `mofos ssh`, un socket `ControlMaster` est établi au préalable pour accélérer les connexions ultérieures. C'est pourquoi le MOTD n'est pas affiché.

## Personnalisation

Pour simplifier la personnalisation des modèles et des machines virtuelles, Mofos introduit le concept de hooks et de tags. Pour chaque tag, un hook correspondant (un script Bash) peut être exécuté pour effectuer des actions automatisées sur la machine virtuelle ou le modèle cible et le configurer en conséquence.

Les hooks minimaux sont situés dans `/usr/share/mofos/hooks`. Ce sont de simples scripts Bash qui reçoivent les entrées suivantes :```
TAG=$1
NAME=$2
OS=$3
DISTRIB=$4
HOSTNAME=$5

Ce script crée dynamiquement un inventaire et exécute un playbook sur celui-ci.

### Machine virtuelle - hook de création

Lors de la création d'une machine virtuelle, un autre hook peut être utilisé, par exemple, pour randomiser le nom d'hôte.

Par défaut, Mofos génère un alias basé sur la convention de nommage Windows classique (par exemple, `DESKTOP-2BF9753`). Ce nom, ainsi que d'autres informations, est transmis au 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}"

Ensuite, lors de la création de la machine virtuelle, ce script sera exécuté :```
$ 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

À l'instar de la phase d'installation, les playbooks Ansible peuvent également être exécutés à ce stade. Dans ce cas, la commande `mofos inventory` peut être utilisée pour générer un inventaire Ansible, ce qui simplifie le processus de sélection et d'accès aux machines virtuelles :```
$ 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"
    ]

### Machine virtuelle - hook de démarrage

De même, le hook de démarrage est exécuté lorsqu'une machine virtuelle démarre. Il est généralement utilisé pour lancer les services requis par la machine virtuelle.

Par exemple, pour activer une intégration Windows transparente dans la machine virtuelle, vous pouvez installer `Xpra`.

Installez d'abord `ansible`:```
# apt install ansible

- gitlab-cli <gitlab-instance> <gitlab-user-id> - pour obtenir les informations du profil utilisateur et les URLs des projets
- gitlab-cli <gitlab-instance> <gitlab-username> --verify - pour vérifier que l'utilisateur GitLab existe
- gitlab-cli <gitlab-instance> <gitlab-username> --terminal - pour obtenir les informations du profil utilisateur et les URLs des projets comme ci-dessus, mais en désactivant la colorisation qui peut causer des problèmes dans les terminaux non interactifs

Si l'option `--cookies` est passée et qu'un fichier `cookies.txt` est spécifié, cela remplacera les cookies pour tous les autres modules. Par exemple, si vous voulez que tous les modules utilisent les mêmes cookies

  gitlab --cookies cookies.txt <gitlab-instance> -c -u <username> -w wordlist.txt
  blackbird --cookies cookies.txt --username <username>
  ghunt --cookies cookies.txt ...

Remarque : ghunt-cli, gitlab-cli, snusbase-cli, blackbird-cli sont tous des alias pour mcore-cli ou maigret selon l'outil. Ils définissent simplement le module par défaut. Vous pouvez donc exécuter

  mcore <gitlab-instance> <gitlab-username>

plutôt que

  gitlab <gitlab-instance> <gitlab-username>

plus...```
$ 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   

Ensuite, exécutez le playbook `Xpra`. Ce playbook installe des paquets depuis les miroirs Debian. Veuillez noter que le réseau Mofos ne configure pas, par défaut, le DNS, le proxy ou la passerelle par défaut. Ces éléments doivent être configurés avant d'exécuter le playbook.

Aucune modification du playbook n'est requise par défaut.```
ansible-playbook playbooks/xpra.yml -l test2

Sinon, le service démarrera automatiquement au prochain redémarrage.

Ensuite, le service client local peut également être démarré manuellement :```
$ mofos xpra start test2

Pour garantir que ce mécanisme fonctionne de manière fluide et automatique, la commande `mofos xpra` peut être lancée depuis le hook de démarrage.```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}"

### Presse-papiers

Mofos peut également gérer le presse-papiers entre les machines virtuelles et l'hôte. L'idée est de configurer un raccourci clavier spécifique pour déclencher une connexion SSH à la machine virtuelle actuellement focalisée, soit pour récupérer le presse-papiers X11, soit pour y pousser du contenu.

Pour pousser du contenu dans le presse-papiers X11 de la machine virtuelle :```
mofos clipboard in pentest-0

Pour chaque opération, mofos établira une connexion SSH vers la machine virtuelle et utilisera xclip et, sur l'hôte, `wl-copy` ou `xclip` selon la technologie de fenêtrage (wayland vs X11).

Le nom de la machine dans la trace ci-dessus peut être omis ; dans ce cas, le script identifiera la machine virtuelle ayant actuellement le focus et la ciblera.

Si vous utilisez Gnome wayland, vous devrez peut-être installer l'extension Gnome Shell [email protected] à l'aide de `sudo make install_gnome_extension`.
Vous devrez vous déconnecter puis vous reconnecter pour vous assurer que l'extension est bien installée.

### Configuration du routage entre machines

Deux options existent dans mofos pour router une VM :
- `mofos route` qui prend une passerelle et configure une `ip rule` sur l'hôte pour router la machine virtuelle via cette passerelle.
- `mofos pivot` qui prend une autre machine mofos, récupère son adresse IP et la configure comme passerelle par défaut pour la machine virtuelle actuelle.

Les deux options peuvent accepter un serveur DNS à configurer.

### Configuration du tunneling à travers les boîtes de pentest

La commande `mofos tunnel` configure un VPN SSH (`ssh -w`) pour router le trafic d'une machine mofos à travers un serveur. Cette fonctionnalité repose sur quelques configurations :

Concrètement, la commande `mofos tunnel` effectue les actions suivantes (aucune magie noire ici) :
1. Créer une interface tun locale (`sudo /usr/libexec/mofos/mofosnet.py tun add pentest_box`) et attribuer une adresse IP à cette interface.
2. Exécuter la commande `tunneling.command` sur le serveur distant ; cette commande doit créer une interface tun qui sera ensuite reliée à l'interface locale (`/usr/libexec/mofos/mofosnet.py sshvpn start pentest_box`).
3. Router le trafic d'une machine mofos via la passerelle de la boîte distante (`/usr/libexec/mofos/mofosnet.py route mofos_vm_ip gateway_ip`) ; la passerelle par défaut de la machine virtuelle mofos est également modifiée.

La commande `tunneling.command` doit être définie dans le fichier de configuration `/etc/mofos/mofosnet.toml`. Par exemple :```toml
[tunneling.command]
start = "sudo ssh-vpn start"  # the peer remote address will be supplied as argv[1]
stop = "sudo ssh-vpn stop"

L'option `force` détache et rattache un périphérique. Elle est couramment utilisée pour
rattacher un périphérique qui a été débranché sans avoir été préalablement détaché.

Remarque : attacher un périphérique USB n'est valable que pour la durée de vie actuelle de la machine virtuelle. Lorsque celle-ci s'arrête, le périphérique est automatiquement détaché.

### Gestion des périphériques PCI

Comme pour les périphériques USB, mofos permet d'attacher un périphérique PCI à une machine virtuelle en cours d'exécution ; les commandes sont les mêmes.

Une limitation supplémentaire concerne certains périphériques PCI qui appartiennent à un groupe. Par exemple, attacher la carte Ethernet à une machine virtuelle en cours d'exécution peut nécessiter de déplacer l'ensemble du groupe PCI dans la machine virtuelle. Comme cela ne peut pas être fait séquentiellement, ce n'est pas encore pris en charge. Cependant, pour un périphérique PCI unique tel qu'une carte réseau Wi-Fi, cela fonctionne parfaitement.

### Dossiers partagés

La commande `mofos mount` crée un dossier partagé et peut monter le nouveau système de fichiers dans un répertoire à l'intérieur de la machine virtuelle. La commande `mofos umount` démontera le répertoire et supprimera le dossier partagé de la configuration de la machine virtuelle.

Ce mécanisme repose sur la technologie `virtiofsd` qui nécessite l'activation de la mémoire partagée ; cela est désormais fait par défaut lors de la création d'une machine virtuelle. Sinon, la commande suivante l'activera :```console
virt-xml -c qemu:///system --edit --memorybacking source.type=memfd,access.mode=shared DOMAIN

La variable `SHARE_DIRS` est réutilisée dans la politique, cependant, en raison des limitations d'apparmor, il n'est pas possible de la réutiliser pour les directives `pivot_root`. Par conséquent, il est nécessaire d'adapter manuellement les directives `pivot_root` pour chaque répertoire partagé.

Pour monter un répertoire local :```
mofos mount test ./Public/share -d /home/user/share

- OpenSSH doit être configuré avec un shell `PowerShell` au lieu de `cmd.exe`.```powershell
New-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" `
                 -Name DefaultShell `
                 -Value "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" `
                 -PropertyType String `
                 -Force

## Autocomplétion

L'autocomplétion devrait être prise en charge par défaut pour `bash` et `fish`. Pour `zsh`, il peut être nécessaire d'exécuter les commandes suivantes :```
autoload -Uz compinit
compinit
source /usr/share/zsh/vendor-completions/_mofos

Avec les interfaces réseau héritées `/etc/network/interfaces` :```
iface eth0 inet dhcp
  client no