Git-Mirrors/qubes-doc
1
0
Fork 0
mirror of https://github.com/QubesOS/qubes-doc.git synced 2025-12-10 21:49:07 -05:00
Code Issues Projects Releases Packages Wiki Activity

Rename External subsections to avoid name collision

Browse source 
QubesOS/qubes-issues#4693
This commit is contained in:
Andrew David Wong 2019-05-26 19:56:33 -05:00
parent d31c786942
commit 9ee193896b
No known key found for this signature in database
GPG key ID: 8CE137352A019A17
14 changed files with 2 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

434
external/os-guides/archlinux.md vendored Normal file
View file

@ -0,0 +1,434 @@
---
layout: doc
title: Archlinux Template
permalink: /doc/templates/archlinux/
redirect_from:
- /doc/archlinux/
- /en/doc/templates/archlinux/
- /doc/Templates/Archlinux/
- /wiki/Templates/Archlinux/
---
# Archlinux Template
Archlinux template is one of the templates made by Qubes community. It should
be considered experimental as Qubes developers team use mainly Fedora-based VMs
to test new features/updates.
Main maintainer of this template is [Olivier Médoc](mailto:o_medoc@yahoo.fr).
Updates for this template are provided by [Olivier Médoc](mailto:o_medoc@yahoo.fr) and are signed by the following key:
pub 2048R/2043E7ACC1833B9C 2014-03-27 [expires: 2018-03-29]
Key fingerprint = D85E E12F 9678 51CC F433 515A 2043 E7AC C183 3B9C
uid Olivier MEDOC (Qubes-OS signing key) <o_medoc@yahoo.fr>
## Installation
A prebuilt template is available only for Qubes 3.2. Before Qubes 3.2, it should be compiled from source as described in [building-archlinux-template](/doc/building-archlinux-template/).
[user@dom0 ~]$ sudo qubes-dom0-update --enablerepo=qubes-templates-community qubes-template-archlinux
## Binary packages activation
The Qubes update repository is disabled by default in the Archlinux template. You can however choose to trust it by registering it into pacman.
Since November 2017, an activation package is present in the template. The update repository can thus be activated by running the following command inside the template:
# pacman -sU /etc/pacman.d/qubes-vm-keyring*.pkg.tar.xz
It should be noted to this command will create a trust for packages provided by [Olivier Médoc](mailto:o_medoc@yahoo.fr) and signed by the PGP key above.
If the qubes-vm-keyring package is not present in `/etc/pacman.d/`, please refer to the section #Activating binary packages manually.
## Optional Qubes packages
Several Qubes packages are not necessarily installed by default in the Archlinux Template. These packages can be installed to add additional functionnalities to the template:
* `qubes-vm-networking`: Contains Qubes tools and dependencies required to use the template as a NetVM/ProxyVM
* `qubes-vm-pulseaudio`: Contains `Pulseaudio` agent enabling sound support in the template
## Default template packages
In order to keep the template as small and simple as possible, default installed package have been arbitrarily selected based on multiple subjective criterias that however essentially include libraries dependencies. This packages are:
* Some font packages to keep good user experience
* leafpad: a note pad
* xfce4-terminal: a terminal
* thunar: a file browser that supports mounting usb keys
* firefox: web browser
* thunderbird: a mail browser
* evince: a document viewer
Note that Archlinux does not install GUI packages by default as this decision is left to users. These packages have only been selected to have a usable template.
## Activating binary packages manually
Enable the repository by running the following command:
# rm /etc/pacman.d/99-qubes-repository-3.2.conf
# ln -s /etc/pacman.d/99-qubes-repository-3.2.disabled /etc/pacman.d/99-qubes-repository-3.2.conf
Then you need to install and sign the public GPG key of the package maintainer (note that accessing to GPG servers requires to temporarily disable the firewall in your template):
# pacman-key --recv-key 2043E7ACC1833B9C
# pacman-key --finger 2043E7ACC1833B9C
If the fingerprint is correct, you can then sign the key:
# pacman-key --lsign-key 2043E7ACC1833B9C
## Updating a Qubes-3.2 Archlinux Template
Because of changes in the Qubes-4.0 partition layout, and usage of XEN HVMs instead of pv-guests. It is not straightforward to update a Qubes-3.2 template to Qubes-4.0.
For this reason, it is recommended to start from a new template in Qubes-4.0.
## Updating a Qubes-3.1 Archlinux Template
If you decide to use binary packages but that you were using a Qubes-3.1 Template, you can follow these instructions to enable Qubes 3.2 agents.
You can use a template that you built for Qubes 3.1 in Qubes 3.2. The qrexec and gui agent functionalities should still be working so that you can at least open a terminal.
In order to enable binary packages for Qubes 3.2, add the following lines to the end of /etc/pacman.conf
```
[qubes-r3.2]
Server = http://olivier.medoc.free.fr/archlinux/current/
```
You should then follow the instruction related to pacman-key in order to sign the binary packages PGP key. With the key enabled, a pacman update will update qubes agents:
` # pacman -Suy `
The two lines that have just been added to /etc/pacman.conf should then be removed as they have been included in the qubes-vm-core update in the file `/etc/pacmand.d/99-qubes-repository-3.2.conf`
## Known Issues
### Package cannot be updated because of errors related to xorg-server or pulseaudio versions
The Qubes GUI agent must be rebuilt whenever xorg-server or pulseaudio make major changes.
If an update of one of these packages causes your template to break, simply [revert it](https://www.qubes-os.org/doc/software-update-vm/#reverting-changes-to-a-templatevm) and wait for corresponding Qubes package updates to be available (or attempt to build them yourself, if you're so inclined).
This should not happen frequently.
### qubes-vm is apparently starting properly (green dot) however graphical applications do not appear to work
They are multiple potential reasons. Some of them are described in the following issue:
* https://github.com/QubesOS/qubes-issues/issues/2612
In issue 2612, check that the option `noauto` is present for all lines in /etc/fstab related to /rw or /home. This bug can appear if you come from an old Archlinux Template (pre February 2017).
## Debugging a broken VM
In order to identify the issue, you should start by getting a console access to the VM:
* Either by running in dom0 `qvm-run --pass-io --nogui yourbrokenvm 'your command here'`
* Or by running in dom0 `sudo xl console yourbrokenvm`
Start by trying to run a GUI application such as xfce4-terminal in order to identify any error message.
Then you can check potential broken systemd service by running the following command inside the broken vm: `systemctl | grep fail`.
If you identified a broken service check `journalctl -la -u yourbrokenservice`. If not check `journalctl -b` for errors.
Finally, errors related to the GUI agent can be found inside the VM in `/home/user/.xsession-errors`
## Packages manager wrapper
Powerpill is a full Pacman wrapper that not only gives easy proxy configuration but further offers numerous other advantages.
Please check out:
[Archlinux Powerpill](https://wiki.archlinux.org/index.php/powerpill)
[XYNE's (dev) Powerpill](http://xyne.archlinux.ca/projects/powerpill/)
**Important Note:** As you are working in a template vm, by default, you will have to open network access to the template to download files manually, except for managed packages which should be handled by the Qubes proxy. You can use the "allow full access for" a given time period in the FW settings of the template in the VMM or open up the various services through the same window. Remember to change it back if you choose the later route. Actions needing network access will be noted with (needs network access)
<br>
<br>
##### **1: Editing Pacman's configuration file (pacman.conf)** #####
* Open archlinux terminal app
* edit /etc/pacman.conf
* **$ sudo nano -w /etc/pacman.conf**
* Below is the output of a correct pacman.conf file Make the changes so your file matches this one or rename the original and create a new one and copy and paste this text into it. Text should be justified left in the file. The changes from your default are to make gpg signing mandatory for packages but not required for DBs for the archlinux repos. Also to add the repo (at the end) for the Powerpill package.
<br>
<br>
# /etc/pacman.conf
#
# See the pacman.conf(5) manpage for option and repository directives
#
# GENERAL OPTIONS
#
[options]
# The following paths are commented out with their default values listed.
# If you wish to use different paths, uncomment and update the paths.
# RootDir = /
# DBPath = /var/lib/pacman/
# CacheDir = /var/cache/pacman/pkg/
# LogFile = /var/log/pacman.log
GPGDir = /etc/pacman.d/gnupg/
HoldPkg = pacman glibc
# XferCommand = /usr/bin/curl -C - -f %u > %o
# XferCommand = /usr/bin/wget --passive-ftp -c -O %o %u
# CleanMethod = KeepInstalled
# UseDelta = 0.7
Architecture = auto
# Pacman won't upgrade packages listed in IgnorePkg and members of IgnoreGroup
# IgnorePkg =
# IgnoreGroup =
# NoUpgrade =
NoUpgrade = /etc/X11/xinit/xinitrc.d/pulseaudio
NoUpgrade = /etc/X11/xinit/xinitrc.d/pulseaudio
NoUpgrade = /etc/X11/xinit/xinitrc.d/pulseaudio
# NoExtract =
# Misc options
# UseSyslog
# Color
# TotalDownload
CheckSpace
# VerbosePkgLists
# By default, pacman accepts packages signed by keys that its local keyring
# trusts (see pacman-key and its man page), as well as unsigned packages.
**Edited Line:** `# SigLevel = Required DatabaseOptional`
LocalFileSigLevel = Optional
# RemoteFileSigLevel = Required
# NOTE: You must run `pacman-key --init` before first using pacman; the local
# keyring can then be populated with the keys of all official Arch Linux
# packagers with `pacman-key --populate archlinux`.
#
# REPOSITORIES
# - can be defined here or included from another file
# - pacman will search repositories in the order defined here
# - local/custom mirrors can be added here or in separate files
# - repositories listed first will take precedence when packages
# have identical names, regardless of version number
# - URLs will have $repo replaced by the name of the current repo
# - URLs will have $arch replaced by the name of the architecture
#
# Repository entries are of the format:
# [repo-name]
# Server = ServerName
# Include = IncludePath
#
# The header [repo-name] is crucial - it must be present and
# uncommented to enable the repo.
#
# The testing repositories are disabled by default. To enable, uncomment the
# repo name header and Include lines. You can add preferred servers immediately
# after the header, and they will be used before the default mirrors.
# [testing]
# SigLevel = PackageRequired
# Include = /etc/pacman.d/mirrorlist
[core]
**Edited Line:** `SigLevel = PackageRequired`
Include = /etc/pacman.d/mirrorlist
[extra]
**Edited Line:** `SigLevel = PackageRequired`
Include = /etc/pacman.d/mirrorlist
# [community-testing]
# SigLevel = PackageRequired
# Include = /etc/pacman.d/mirrorlist
[community]
**Edited Line:** `SigLevel = PackageRequired`
Include = /etc/pacman.d/mirrorlist
# If you want to run 32 bit applications on your x86_64 system,
# enable the multilib repositories as required here.
# [multilib-testing]
# Include = /etc/pacman.d/mirrorlist
# [multilib]
# Include = /etc/pacman.d/mirrorlist
# An example of a custom package repository. See the pacman manpage for
# tips on creating your own repositories.
# [custom]
# SigLevel = Optional TrustAll
# Server = file:///home/custompkgs
[multilib]
**Edited Line:** `SigLevel = PackageRequired`
Include = /etc/pacman.d/mirrorlist
**Edited Line:** `# [qubes]`
**Edited Line:** `# Server = http://olivier.medoc.free.fr/archlinux/pkgs/`
**Add Section Below:**
[xyne-x86_64]
# A repo for Xyne's own projects: http://xyne.archlinux.ca/projects/
# Packages for the "x86_64" architecture.
# Added for PowerPill app
# Note that this includes all packages in [xyne-any].
SigLevel = Required
Server = http://xyne.archlinux.ca/repos/xyne
----------
<br>
##### **2: Setting Up GPG** (needs network access) #####
* Initialize GPG Keyring
* **$ sudo pacman-key --init**
* Populate the keyring with Archlinux master keys
* **$ sudo pacman-key --populate archlinux**
* Confirm keys with those at [Archlinux Master Keys](https://www.archlinux.org/master-keys/)
* For more information on Pacman key signing: [Pacman Package Key Signing](https://wiki.archlinux.org/index.php/Pacman/Package_signing)
<br>
<br>
##### **3: Install Powerpill (Pacman wrapper)** #####
* **$ sudo pacman -S powerpill**
<br>
<br>
##### **4: Install Reflector** #####
*Note: It scripts mirror updating. Grabbing the most up to date gen mirror list. It ranks them by most recently sync'd. Then ranks them on fastest speed. Also can be used by Powerpill config to allow a once stop conf file for all if so wanted.*
* **$ sudo pacman -S reflector**
Note: You can combine package downloads: **$ sudo pacman -S powerpill reflector**
<br>
<br>
##### **5: Backup mirrorlist prior to first running Reflector.** #####
Note: For info on Reflector and its configs: [Reflector](https://wiki.archlinux.org/index.php/Reflector)
* **$ sudo cp /etc/pacman.d/mirrorlist /etc/pacman.d/mirrorlist.bkup**
<br>
<br>
##### **6: Setup mirrolist with Reflector** (needs network access)** #####
*Note: Look at the Reflector page to decide what filter and argument string you wish to run. Below is a default string that will work for most all to setup a working basic mirrorlist.
*Look to Reflector pages or --help for more info on args and filters.*
* **$ sudo reflector --verbose -l 5 --sort rate --save /etc/pacman.d/mirrorlist**
* The above ranks all the most up to date and sorts for the 5 fastest
* You can confirm the new list by opening the newly created mirrorlist.
<br>
<br>
##### **7: Configure Powerpill configuration file to use Qubes Proxy Service** #####
* Qubes Proxy Address: **10.137.255.254:8082**
* Edit **powerpill.json** (powerpill config file)
* **$ sudo nano -w /etc/powerpill/powerpill.json**
* Add line '**--all-proxy=10.137.255.254:8082**' at the bottom of the list under the **"aria2"** section under the **"args"** line. Example below:
<br>
{
"aria2": {
"args": [
"--allow-overwrite=true",
"--always-resume=false",
"--auto-file-renaming=false",
"--check-integrity=true",
"--conditional-get=true",
"--continue=true",
"--file-allocation=none",
"--log-level=error",
"--max-concurrent-downloads=100",
"--max-connection-per-server=5",
"--min-split-size=5M",
"--remote-time=true",
"--show-console-readout=true",
"--all-proxy=10.137.255.254:8082"
],
"path": "/usr/bin/aria2c"
},
<br>
<br>
##### **8: Test Powerpill Configuration** #####
*Note: Powerpill uses and passes the same syntax as pacman*
* Configure Archlinux Template to only use the Qubes Proxy Update Service
* In the Qubes VM Manager under Archlinux FW tab make sure only the access check box for update proxy is on. All others should be set to deny.
* **$ sudo powerpill -Syu**
* You should get a similar output as below:
<br>
<br>
![arch-template-26](/attachment/wiki/ArchlinuxTemplate/arch-template-26.png)
<br>
<br>
**Remember you must open up network access anytime you wish to run the Reflector script to update the mirrorlist. This page will be updated when/if this situation changes.**
### **If the above checks out, you can start using your new Archlinux Template** ###
<br>
<br>
## Want to contribute?
* [How can I contribute to the Qubes Project?](/doc/contributing/)
* [Guidelines for Documentation Contributors](/doc/doc-guidelines/)
<br>

96
external/os-guides/linux-hvm-tips.md vendored Normal file
View file

@ -0,0 +1,96 @@
---
layout: doc
title: Linux HVM Tips
permalink: /doc/linux-hvm-tips/
redirect_from:
- /en/doc/linux-hvm-tips/
- /doc/LinuxHVMTips/
- /wiki/LinuxHVMTips/
---
Tips for Linux in HVM domain
============================
How to fix bootup kernel error
-------------------------------
The HVM may pause on boot, showing a fixed cursor.
After a while a series of warnings may be shown similar to this:
BUG: soft lockup - CPU#0 stuck for 23s! [systemd-udevd:244]
To fix this:
1. Kill the HVM.
1. Start the HVM
1. Press "e" at the grub screen to edit the boot parameters
1. Find the /vmlinuz line, and edit it to replace "rhgb" with "modprobe.blacklist=bochs_drm"
1. Press "Ctrl-x" to start the HVM
If this solves the problem then you will want to make the change permanent:
1. Edit the file `/etc/default/grub`.
1. Find the line which starts:
~~~
GRUB_CMDLINE_LINUX=
~~~
1. Remove this text from that line:
~~~
rhgb
~~~
1. Add this text to that line:
~~~
modprobe.blacklist=bochs_drm
~~~
1. Run this command:
~~~
grub2-mkconfig --output=/boot/grub2/grub.cfg
~~~
The HVM should now start normally.
Screen resolution
-----------------
Some kernel/Xorg combinations use only 640x480 in HVM, which is quite small.
To enable maximum resolution, some changes in the Xorg configuration are needed:
1. Force "vesa" video driver
2. Provide wide horizontal synchronization range
To achieve it (all commands to be run as root):
1. Generate XOrg configuration (if you don't have it):
~~~
X -configure :1 && mv ~/xorg.conf.new /etc/X11/xorg.conf
~~~
1. Add HorizSync line to Monitor section, it should look something like:
~~~
Section "Monitor"
Identifier "Monitor0"
VendorName "Monitor Vendor"
ModelName "Monitor Model"
HorizSync 30.0 - 60.0
EndSection
~~~
1. Change driver to "vesa" in Device section:
~~~
Section "Device"
# (...)
Identifier "Card0"
Driver "vesa"
VendorName "Technical Corp."
BoardName "Unknown Board"
BusID "PCI:0:2:0"
EndSection
~~~
Now you should get resolution of at least 1280x1024 and should be able to choose other modes.
Qubes agents
------------
Linux Qubes agents are written primarily for PV qubes, but it is possible to run them also in a HVM qube.
However some work may be required to achieve this. Check [this thread](https://groups.google.com/group/qubes-devel/browse_thread/thread/081df4a43e49e7a5).

23
external/os-guides/netbsd.md vendored Normal file
View file

@ -0,0 +1,23 @@
---
layout: doc
title: How to Create a NetBSD VM
permalink: /doc/netbsd/
---
How to Create a NetBSD VM
=========================
1. Create a StandaloneVM with the default template.
2. Replace `vmlinuz` with the `netbsd-INSTALL_XEN3_DOMU` kernel.
3. During setup, choose to install on the `xbd1` hard disk.
4. Attach the CD to the VM.
5. Configure the networking.
6. Optionally enable SSHD during the post-install configuration.
7. Replace the kernel with `netbsd-XEN3_DOMU`.
8. The VM may fail to boot automatically, in which case you must explicitly
specify `xbd1a` as the root device when prompted.
For further discussion, please see this [thread] and this [guide].
[thread]: https://groups.google.com/group/qubes-devel/msg/4015c8900a813985
[guide]: https://wiki.xen.org/wiki/How_to_install_a_NetBSD_PV_domU_on_a_Debian_Squeeze_host_%28Xen_4.0.1%29

30
external/os-guides/pentesting.md vendored Normal file
View file

@ -0,0 +1,30 @@
---
layout: doc
title: Penetration Testing
permalink: /doc/pentesting/
---
**Legal notice:**
The usage of penetration testing tools outside your own laboratory environment requires the permission of the organization you attack. Penetration testing without permission can have legal consequences.
To avoid such legal conflicts please refer to the [EC-Council: Code of Ethics](https://www.eccouncil.org/Support/code-of-ethics).
Penetration Testing
===================
"A penetration test, colloquially known as a pen test, is an authorised simulated attack on a computer system that looks for security weaknesses, potentially gaining access to the system's features and data." (Source: [Wikipedia](https://en.wikipedia.org/wiki/Penetration_test)).
Penetration Testing Distributions
---------------------------------
The following instructions explain how to install a penetration testing distribution within Qubes OS.
- [BlackArch](/doc/pentesting/blackarch/)
- [Kali](/doc/pentesting/kali/)
- [PenTester Framework (PTF)](/doc/pentesting/ptf/)
Using Qubes OS to host a "hacking" laboratory
---------------------------------------------
Qubes OS is a hypervisor based operating system. Qubes OS can host various operating systems such as Linux, Unix or Windows and run them in parallel. Qubes OS can therefore be used to host your own "hacking" laboratory.

96
external/os-guides/pentesting/blackarch.md vendored Normal file
View file

@ -0,0 +1,96 @@
---
layout: doc
title: How to Create a BlackArch VM
permalink: /doc/pentesting/blackarch/
redirect_from:
- /doc/blackarch/
---
**General reminder:**
- The installation scripts and provided tools may have bugs, be vulnerable to Man in the Middle (MitM) attacks or other vulnerabilities.
- Adding additional repositories or tools for installing software extends your trust to those tool providers.
Please keep in mind that using such a VM or VMs based on the template for security and privacy critical tasks is not recommended.
How to Create a BlackArch VM
============================
[BlackArch](https://www.blackarch.org) Linux is an [Arch Linux](https://www.archlinux.org)-based distribution for penetration testers and security researchers. The repository contains [1434](https://www.blackarch.org/tools.html) tools.
- List of [tools](https://www.blackarch.org/tools.html)
- [Installation Instructions](https://www.blackarch.org/downloads.html)
Create ArchLinux Based BlackArch Template
-----------------------------------------
1. Create ArchlLinux Template
- Follow the [Archlinux Template instructions](/doc/templates/archlinux/)
2. Update Template
sudo pacman -Syyu
3. Clone template
1. Via Qubes VM Manager
2. Via command line
qvm-clone archlinux blackarch
4. Install BlackArch repository
$ curl -O https://blackarch.org/strap.sh
# The SHA1 sum should match: 34b1a3698a4c971807fb1fe41463b9d25e1a4a09
$ sha1sum strap.sh
# Set execute bit
$ chmod +x strap.sh
# Run strap.sh
$ sudo ./strap.sh
5. Install tools
- install all tools
sudo pacman -S blackarch
- or by category:
# list available categories
pacman -Sg | grep blackarch
# install category
sudo pacman -S blackarch-<category>
# example
sudo pacman -S blackarch-forensic
- or specific tool
# Search for tool
pacman -Ss <tool-name>
# Install tool
sudo pacman -S <tool-name>
# Example
pacman -Ss burpsuite
sudo pacman -S burpsuite
6. Create a AppVMs based on the `blackarch` template
- (Optional) Attach necessary devices
Alternative Options to BlackArch
--------------------------------
- [Kali](/doc/pentesting/kali/)
- [PenTester Framework (PTF)](/doc/pentesting/ptf/)
- [Pentesting](/doc/pentesting/)

616
external/os-guides/pentesting/kali.md vendored Normal file
View file

@ -0,0 +1,616 @@
---
layout: doc
title: How to create a Kali Linux VM
permalink: /doc/pentesting/kali/
redirect_from:
- /doc/kali/
---
# How to create a Kali Linux VM
## Warnings
- The installation scripts and provided tools may have bugs, be vulnerable to Man in the Middle (MitM) attacks or other vulnerabilities.
- Adding additional repositories or tools for installing software extends your trust to those tool providers.
- Please keep in mind that using such a VM or VM's based on the template for security and privacy critical tasks is not recommended.
- Kali Linux distribution is a rolling distribution based constantly on Debian testing release, so it always will have newer software base than available in Qubes OS debian template. Keep in mind that it may result in problems (especially in regard to package dependency) not covered by this tutorial.
## Qubes 3.2
### How to Create a Kali Linux VM
This guide is being created to give guidance on ways in which you could create a [Kali Linux][kali] penetration testing VM (qube) in Qubes OS.
Kali Linux is the most widely used penetration testing Linux distribution.
There are multiple ways to create a Kali Linux VM:
1. Create a HVM and use the official ISO to install the system or convert a [Virtual Image][kali-vbox]. Explained [here](#hvm3_2).
2. Clone the Qubes OS latest Debian template image and turn it into a Kali Linux distribution:
- using [katoolin]. Explained [here](#katoolin3_2).
- manually. Explained [here](#templatevm-from-debian3_2).
### Kali Linux HVM <a name="hvm3_2"/>
1. Download the Kali installation DVD
2. Create a new HVM
3. Start the HVM with attached CD/DVD
[user@dom0 ~]$ qvm-start <hvm-name> --cdrom <vm-name>:/home/user/Downloads/<iso-name>.iso
### Debian based Kali Template with Katoolin <a name="katoolin3_2"/>
**Note:** The prompt on each line indicates where each command should be entered (`@dom0`, `@debian-<X>` or `@kali`).
1. (Optional) Check for latest Debian stable template and install it (if not already done)
[user@dom0 ~]$ sudo qubes-dom0-update --action="search all" qubes-template-debian
[user@dom0 ~]$ sudo qubes-dom0-update <latest Debian template>
2. Start, update and close your latest Debian template
[user@dom0 ~]$ qvm-start debian-<X>
[user@dom0 ~]$ qvm-run -a debian-<X> gnome-terminal
[user@debian-<X> ~]$ sudo apt-get update
[user@debian-<X> ~]$ sudo apt-get upgrade
[user@dom0 ~]$ qvm-shutdown debian-<X>
3. Clone `debian-<X>` template (two options)
1. Via Qubes VM Manager
![Clone Debian Template](/attachment/wiki/Kali/clone-kali.png)
2. Via command line
[user@dom0 ~]$ qvm-clone debian-<X> kali
4. Check the name of currently used repository in `/etc/apt/sources.list` and current testing [Debian release][Debian-releases]. Update repository list accordingly
[user@kali ~]$ sudo sed -i 's/<current stable>/<current testing>/g' /etc/apt/sources.list
[user@kali ~]$ sudo sed -i 's/<current stable>/<current testing>/g' /etc/apt/sources.list.d/qubes-r<X>.list
e.g. in this example we update `stretch` stable repository to `buster` testing repository
[user@kali ~]$ sudo sed -i 's/stretch/buster/g' /etc/apt/sources.list
[user@kali ~]$ sudo sed -i 's/stretch/buster/g' /etc/apt/sources.list.d/qubes-r<X>.list
5. Upgrade `kali` template to latest Debian testing release
[user@kali ~]$ sudo apt-get update
[user@kali ~]$ sudo apt-get dist-upgrade
[user@kali ~]$ sudo apt-get autoremove
**Note:** During execution of a `dist-upgrade` command read carefully list of packages to be removed.
If it contains `qubes-*` packages, terminate operation and try to resolve `qubes-*` packages missing dependencies first.
6. Install Katoolin and add Kali Linux repositories
1. Install Katoolin
[user@kali ~]$ sudo apt-get install git
[user@kali ~]$ git clone https://github.com/LionSec/katoolin.git
[user@kali ~]$ sudo cp katoolin/katoolin.py /usr/bin/katoolin
[user@kali ~]$ sudo chmod +x /usr/bin/katoolin
[user@kali ~]$ rm -rf katoolin
2. Add Kali Linux repositories
- start katoolin
[user@kali ~]$ sudo katoolin
- select 'Add Kali repositories & Update'
1) Add Kali repositories & Update
2) View Categories
3) Install classicmenu indicator
4) Install Kali menu
5) Help
kat > 1
![Add Kali repositories and Update menu](/attachment/wiki/Kali/katoolin-add-update-repo-menu.png)
- select 'Add kali linux repositories'
1) Add kali linux repositories
2) Update
3) Remove all kali linux repositories
4) View the contents of sources.list file
What do you want to do ?> 1
![Add Kali repositories](/attachment/wiki/Kali/katoolin-add-repos-menu.png)
- update Kali repositories
1) Add kali linux repositories
2) Update
3) Remove all kali linux repositories
4) View the contents of sources.list file
What do you want to do ?> 2
- quit katoolin by pressing `CRTL` + `c` keys
What do you want to do ?> ^CShutdown requested...Goodbye...
7. Clean up and update `kali` template
[user@kali ~]$ sudo apt-get dist-upgrade
[user@kali ~]$ sudo apt-get autoremove
8. Shutdown and trim `kali` template
- Shutdown `kali` template
[user@kali ~]$ sudo shutdown -h now
- In `dom0` console:
[user@dom0 ~]$ qvm-trim-template kali
9. Start image
[user@dom0 ~]$ qvm-start kali
10. Install tools
**Note** [Resize the template disk image][qubes-resize-disk-image] to at least 20GB if you plan on installing all packages from Kali distribution.
1. View Categories
- start katoolin
[user@kali ~]$ sudo katoolin
- select `2) View Categories`
2. Select the categories/tools you want to install
- For more information on how to use Katoolin see [How to Auto Install All Kali Linux Tools Using “Katoolin” on Debian/Ubuntu][katoolin-howto].
- **Note:** The `all` option does not work for `Information Gathering`, `Web Apps`, `Forensic Tools`, `Reverse Engineering` and `Extra`.
11. Create a AppVMs based on the `kali` template
- (Optional) Attach necessary devices
### Kali Linux TemplateVM from a Debian template <a name="templatevm-from-debian3_2"/>
This section will explain how to create your own [Kali] Linux TemplateVM based
on a current stable Debian TemplateVM. The basic idea is to personalize the
template with all the tools needed, and then spin up isolated AppVMs based on
the template.
The steps can be summarised as:
1. Install Qubes stable Debian template
2. Upgrade the template to Debian testing release
3. Install Kali Linux through the ``kali-linux-full`` package
4. Use the template to build AppVM so that you can maintain isolation between
e.g. pentesting jobs
#### Get Kali Linux GPG key
**CAUTION:** Before proceeding, please carefully read [On Digital Signatures and Key Verification][qubes-verifying-signatures].
This website cannot guarantee that any PGP key you download from the Internet is authentic.
Always obtain a trusted key fingerprint via other channels, and always check any key you download against your trusted copy of the fingerprint.
This step is required since by (security) default a TemplateVM do not have a
direct Internet connectivity. Users understanding the risks of enabling such
access can change this configuration in firewall settings for the TemplateVM.
**Note:** The prompt on each line indicates where each command should be entered
(`@dom0`, `@kali-rolling`, `@xxxx-dvm` or `@debian-<X>`).
1. Retrive the Kali Linux GPG key using a DispVM.
[user@xxxx-dvm ~]$ gpg --keyserver hkp://keys.gnupg.net --recv-key 44C6513A8E4FB3D30875F758ED444FF07D8D0BF6
[user@xxxx-dvm ~]$ gpg --list-keys --with-fingerprint 44C6513A8E4FB3D30875F758ED444FF07D8D0BF6
[user@xxxx-dvm ~]$ gpg --export --armor 44C6513A8E4FB3D30875F758ED444FF07D8D0BF6 > kali-key.asc
2. **DO NOT TURN OFF** the DispVM, the `kali-key.asc` file will be copied to
the Kali Linux template in a further step.
3. Make sure the key is the authentic Kali key.
See the [Kali website] for further advice and instructions on verification.
#### Create a Kali Linux (rolling) template
These instructions will show you how to upgrade a Debian TemplateVM to Kali Linux.
1. (Optional) Check for latest Debian stable template and install it (if not already done)
[user@dom0 ~]$ sudo qubes-dom0-update --action="search all" qubes-template-debian
[user@dom0 ~]$ sudo qubes-dom0-update <latest Debian template>
2. Start, update and close your latest Debian template
[user@dom0 ~]$ qvm-start debian-<X>
[user@dom0 ~]$ qvm-run -a debian-<X> gnome-terminal
[user@debian-<X> ~]$ sudo apt-get update
[user@debian-<X> ~]$ sudo apt-get upgrade
[user@dom0 ~]$ qvm-shutdown debian-<X>
3. Clone `debian-X` template
[user@dom0 ~]$ qvm-clone debian-<X> kali-rolling
4. Check the name of currently used repository in `/etc/apt/sources.list` and current testing [Debian release][Debian-releases]. Update repository list accordingly
[user@kali-rolling ~]$ sudo sed -i 's/<current stable>/<current testing>/g' /etc/apt/sources.list
[user@kali-rolling ~]$ sudo sed -i 's/<current stable>/<current testing>/g' /etc/apt/sources.list.d/qubes-r<X>.list
e.g. in this example we update `stretch` stable repository to `buster` testing repository
[user@kali-rolling ~]$ sudo sed -i 's/stretch/buster/g' /etc/apt/sources.list
[user@kali-rolling ~]$ sudo sed -i 's/stretch/buster/g' /etc/apt/sources.list.d/qubes-r<X>.list
5. Upgrade `kali-rolling` template to latest Debian testing release
[user@kali-rolling ~]$ sudo apt-get update
[user@kali-rolling ~]$ sudo apt-get dist-upgrade
[user@kali-rolling ~]$ sudo apt-get autoremove
**Note:** During execution of a `dist-upgrade` command read carefully list of packages to be removed. If it contains `qubes-*` packages, terminate operation and try to resolve `qubes-*` packages missing dependencies first.
6. Copy the Kali GPG key from the DispVM to the new template:
[user@xxxx-dvm ~]$ qvm-copy-to-vm kali-rolling kali-key.asc
The DispVM can now be turned off.
7. Add the Kali GPG key to the list of keys trusted to authenticate packages:
[user@kali-rolling ~]$ cat /home/user/QubesIncoming/dispXXX/kali-key.asc | sudo apt-key add -
This command should return `OK` on a line by itself.
8. Attempt the upgrade process in the new template.
[user@kali-rolling ~]$ sudo cat <<EOF > /etc/apt/sources.list.d/kali.list
# Kali Linux repository
deb http://http.kali.org/kali kali-rolling main non-free contrib
EOF
[user@kali-rolling ~]$ sudo apt-get update
[user@kali-rolling ~]$ sudo apt-get dist-upgrade
[user@kali-rolling ~]$ sudo apt-get autoremove
9. Shut down and trim the new template.
[user@dom0 ~]$ qvm-shutdown kali-rolling
[user@dom0 ~]$ qvm-trim-template kali-rolling
10. Ensure a terminal can be opened in the new template.
[user@dom0 ~]$ qvm-run -a kali-rolling gnome-terminal
#### Install the Kali tools
At this point you should have a working template and you can install the tools you need.
1. [Resize the template disk image][qubes-resize-disk-image] if you plan on installing the full Kali distribution. For example to install `kali-linux-full` you must **grow** the size of the VM system from 10GB to at least 20GB.
2. Install Kali Linux tools:
[user@kali-rolling ~]$ sudo apt-get install kali-linux-full
3. (Optional) Customise the template's home directory (e.g. install your licensed copy of Burp Suite Professional)
#### Use the template
The template is ready to be used. You can now spin up AppVMs based on the `kali-rolling` template.
## Qubes 4.0
### How to Create a Kali Linux VM
This guide is being created to give guidance on ways in which you could create a [Kali Linux][kali] penetration testing VM (qube) in Qubes OS.
Kali Linux is the most widely used penetration testing Linux distribution.
There are multiple ways to create a Kali Linux VM:
1. Create a HVM and use the official ISO to install the system or convert a [Virtual Image][kali-vbox]. Explained [here](#hvm4_0).
2. Clone the Qubes OS latest Debian template image and turn it into a Kali Linux distribution:
- using [katoolin]. Explained [here](#katoolin4_0).
- manually. Explained [here](#templatevm-from-debian4_0).
### Kali Linux HVM <a name="hvm4_0"/>
1. Download the Kali installation DVD
2. Create a new HVM
3. Start the HVM with attached CD/DVD
[user@dom0 ~]$ qvm-start <hvm-name> --cdrom <vm-name>:/home/user/Downloads/<iso-name>.iso
### Debian based Kali Template with Katoolin <a name="katoolin4_0"/>
**Note:** The prompt on each line indicates where each command should be entered (`@dom0`, `@debian-<X>` or `@kali`).
1. (Optional) Check for latest Debian stable template and install it (if not already done)
[user@dom0 ~]$ sudo qubes-dom0-update --action="search all" qubes-template-debian
[user@dom0 ~]$ sudo qubes-dom0-update <latest Debian template>
2. Start, update and close your latest Debian template
[user@dom0 ~]$ qvm-start debian-<X>
[user@dom0 ~]$ qvm-run -a debian-<X> gnome-terminal
[user@debian-<X> ~]$ sudo apt-get update
[user@debian-<X> ~]$ sudo apt-get upgrade
[user@dom0 ~]$ qvm-shutdown debian-<X>
3. Clone `debian-<X>` template (two options)
1. Via Qubes VM Manager
![Clone Debian Template](/attachment/wiki/Kali/clone-kali.png)
2. Via command line
[user@dom0 ~]$ qvm-clone debian-<X> kali
4. Check the name of currently used repository in `/etc/apt/sources.list` and current testing [Debian release][Debian-releases]. Update repository list accordingly.
[user@kali ~]$ sudo sed -i 's/<current stable>/<current testing>/g' /etc/apt/sources.list
[user@kali ~]$ sudo sed -i 's/<current stable>/<current testing>/g' /etc/apt/sources.list.d/qubes-r<X>.list
e.g. in this example we update `stretch` stable repository to `buster` testing repository
[user@kali ~]$ sudo sed -i 's/stretch/buster/g' /etc/apt/sources.list
[user@kali ~]$ sudo sed -i 's/stretch/buster/g' /etc/apt/sources.list.d/qubes-r<X>.list
5. Upgrade `kali` template to latest Debian testing release
[user@kali ~]$ sudo apt-get update
[user@kali ~]$ sudo apt-get dist-upgrade
[user@kali ~]$ sudo apt-get autoremove
**Note:** During execution of a `dist-upgrade` command read carefully list of packages to be removed.
If it contains `qubes-*` packages, terminate operation and try to resolve `qubes-*` packages missing dependencies first.
6. Install Katoolin and add Kali Linux repositories
1. Install Katoolin
[user@kali ~]$ sudo apt-get install git
[user@kali ~]$ git clone https://github.com/LionSec/katoolin.git
[user@kali ~]$ sudo cp katoolin/katoolin.py /usr/bin/katoolin
[user@kali ~]$ sudo chmod +x /usr/bin/katoolin
[user@kali ~]$ rm -rf katoolin
2. Add Kali Linux repositories
- start katoolin
[user@kali ~]$ sudo katoolin
- select 'Add Kali repositories & Update'
1) Add Kali repositories & Update
2) View Categories
3) Install classicmenu indicator
4) Install Kali menu
5) Help
kat > 1
![Add Kali repositories and Update menu](/attachment/wiki/Kali/katoolin-add-update-repo-menu.png)
- select 'Add kali linux repositories'
1) Add kali linux repositories
2) Update
3) Remove all kali linux repositories
4) View the contents of sources.list file
What do you want to do ?> 1
![Add Kali repositories](/attachment/wiki/Kali/katoolin-add-repos-menu.png)
- update Kali repositories
1) Add kali linux repositories
2) Update
3) Remove all kali linux repositories
4) View the contents of sources.list file
What do you want to do ?> 2
- quit katoolin by pressing `CRTL` + `c` keys
What do you want to do ?> ^CShutdown requested...Goodbye...
7. Clean up and update `kali` template
[user@kali ~]$ sudo apt-get dist-upgrade
[user@kali ~]$ sudo apt-get autoremove
8. Install tools
**Note** [Resize the template disk image][qubes-resize-disk-image] to at least 20GB if you plan on installing all packages from Kali distribution.
1. View Categories
- start katoolin
[user@kali ~]$ sudo katoolin
- select `2) View Categories`
2. Select the categories/tools you want to install
- For more information on how to use Katoolin see [How to Auto Install All Kali Linux Tools Using “Katoolin” on Debian/Ubuntu][katoolin-howto].
- **Note:** The `all` option does not work for `Information Gathering`, `Web Apps`, `Forensic Tools`, `Reverse Engineering` and `Extra`.
9. Create a AppVMs based on the `kali` template
- (Optional) Attach necessary devices
### Kali Linux TemplateVM from a Debian template <a name="templatevm-from-debian4_0"/>
This section will explain how to create your own [Kali] Linux TemplateVM based
on a current stable Debian TemplateVM. The basic idea is to personalize the
template with all the tools needed, and then spin up isolated AppVMs based on
the template.
The steps can be summarised as:
1. Install Qubes stable Debian template
2. Upgrade the template to Debian testing release
3. Install Kali Linux through the ``kali-linux-full`` package
4. Use the template to build AppVM so that you can maintain isolation between
e.g. pentesting jobs
#### Get Kali Linux GPG key
**CAUTION:** Before proceeding, please carefully read [On Digital Signatures and Key Verification][qubes-verifying-signatures].
This website cannot guarantee that any PGP key you download from the Internet is authentic.
Always obtain a trusted key fingerprint via other channels, and always check any key you download against your trusted copy of the fingerprint.
This step is required since by (security) default a TemplateVM do not have a
direct Internet connectivity. Users understanding the risks of enabling such
access can change this configuration in firewall settings for the TemplateVM.
**Note:** The prompt on each line indicates where each command should be entered
(`@dom0`, `@kali-rolling`, `@xxxx-dvm` or `@debian-<X>`).
1. Retrive the Kali Linux GPG key using a DispVM.
[user@xxxx-dvm ~]$ gpg --keyserver hkp://keys.gnupg.net --recv-key 44C6513A8E4FB3D30875F758ED444FF07D8D0BF6
[user@xxxx-dvm ~]$ gpg --list-keys --with-fingerprint 44C6513A8E4FB3D30875F758ED444FF07D8D0BF6
[user@xxxx-dvm ~]$ gpg --export --armor 44C6513A8E4FB3D30875F758ED444FF07D8D0BF6 > kali-key.asc
2. **DO NOT TURN OFF** the DispVM, the `kali-key.asc` file will be copied to
the Kali Linux template in a further step.
3. Make sure the key is the authentic Kali key.
See the [Kali website] for further advice and instructions on verification.
#### Create a Kali Linux (rolling) template
These instructions will show you how to upgrade a Debian TemplateVM to Kali Linux.
1. (Optional) Check for latest Debian stable template and install it (if not already done)
[user@dom0 ~]$ sudo qubes-dom0-update --action="search all" qubes-template-debian
[user@dom0 ~]$ sudo qubes-dom0-update <latest Debian template>
2. Start, update and close your latest Debian template
[user@dom0 ~]$ qvm-start debian-<X>
[user@dom0 ~]$ qvm-run -a debian-<X> gnome-terminal
[user@debian-<X> ~]$ sudo apt-get update
[user@debian-<X> ~]$ sudo apt-get upgrade
[user@dom0 ~]$ qvm-shutdown debian-<X>
3. Clone `debian-X` template
[user@dom0 ~]$ qvm-clone debian-<X> kali-rolling
4. Check the name of currently used repository in `/etc/apt/sources.list` and current testing [Debian release][Debian-releases]. Update repository list accordingly
[user@kali-rolling ~]$ sudo sed -i 's/<current stable>/<current testing>/g' /etc/apt/sources.list
[user@kali-rolling ~]$ sudo sed -i 's/<current stable>/<current testing>/g' /etc/apt/sources.list.d/qubes-r<X>.list
e.g. in this example we update `stretch` stable repository to `buster` testing repository
[user@kali-rolling ~]$ sudo sed -i 's/stretch/buster/g' /etc/apt/sources.list
[user@kali-rolling ~]$ sudo sed -i 's/stretch/buster/g' /etc/apt/sources.list.d/qubes-r<X>.list
5. Upgrade `kali-rolling` template to latest Debian testing release
[user@kali-rolling ~]$ sudo apt-get update
[user@kali-rolling ~]$ sudo apt-get dist-upgrade
[user@kali-rolling ~]$ sudo apt-get autoremove
**Note:** During execution of a `dist-upgrade` command read carefully list of packages to be removed. If it contains `qubes-*` packages, terminate operation and try to resolve `qubes-*` packages missing dependencies first.
6. Copy the Kali GPG key from the DispVM to the new template:
[user@xxxx-dvm ~]$ qvm-copy kali-key.asc
The DispVM can now be turned off.
7. Add the Kali GPG key to the list of keys trusted to authenticate packages:
[user@kali-rolling ~]$ cat /home/user/QubesIncoming/dispXXX/kali-key.asc | sudo apt-key add -
This command should return `OK` on a line by itself.
8. Attempt the upgrade process in the new template.
[user@kali-rolling ~]$ sudo cat <<EOF > /etc/apt/sources.list.d/kali.list
# Kali Linux repository
deb http://http.kali.org/kali kali-rolling main non-free contrib
EOF
[user@kali-rolling ~]$ sudo apt-get update
[user@kali-rolling ~]$ sudo apt-get dist-upgrade
[user@kali-rolling ~]$ sudo apt-get autoremove
9. Ensure a terminal can be opened in the new template.
[user@dom0 ~]$ qvm-run -a kali-rolling gnome-terminal
#### Install the Kali tools
At this point you should have a working template and you can install the tools you need.
1. [Resize the template disk image][qubes-resize-disk-image] if you plan on installing the full Kali distribution. For example to install `kali-linux-full` you must **grow** the size of the VM system from 10GB to at least 20GB.
2. Install Kali Linux tools:
[user@kali-rolling ~]$ sudo apt-get install kali-linux-full
3. (Optional) Customise the template's home directory (e.g. install your licensed copy of Burp Suite Professional)
#### Use the template
The template is ready to be used. You can now spin up AppVMs based on the `kali-rolling` template.
### Alternative Options to Kali Linux
* [PenTester Framework][PTF], with [PTF Qubes OS guide][qubes-ptf]
* BlackArch Linux, with [BA Qubes OS guide][qubes-blackarch]
* [KATOOLIN][katoolin-howto]
* more on the [Penetration Testing page][qubes-pentesting]
## Notes
Thanks to the people in [the discussion thread](https://github.com/QubesOS/qubes-issues/issues/1981).
[qubes-verifying-signatures]: /security/verifying-signatures/
[qubes-pentesting]: /doc/pentesting/
[qubes-blackarch]: /doc/pentesting/blackarch/
[qubes-ptf]: /doc/pentesting/ptf/
[qubes-template-debian-install]: /doc/templates/debian/#install
[qubes-resize-disk-image]: /doc/resize-disk-image/
[kali]: https://www.kali.org/
[kali-vbox]: https://www.offensive-security.com/kali-linux-vmware-virtualbox-image-download/
[kali website]: https://docs.kali.org/introduction/download-official-kali-linux-images
[PTF]: https://www.trustedsec.com/may-2015/new-tool-the-pentesters-framework-ptf-released/
[katoolin]: https://github.com/LionSec/katoolin
[katoolin-howto]: http://www.tecmint.com/install-kali-linux-tools-using-katoolin-on-ubuntu-debian/
[Debian-releases]: https://www.debian.org/releases/

121
external/os-guides/pentesting/ptf.md vendored Normal file
View file

@ -0,0 +1,121 @@
---
layout: doc
title: How to create Penetration Testers Framework (PTF) VM
permalink: /doc/pentesting/ptf/
redirect_from:
- /doc/ptf/
---
**General reminder:**
- The installation scripts and provided tools may have bugs, be vulnerable to Man in the Middle (MitM) attacks or other vulnerabilities.
- Adding additional repositories or tools for installing software extends your trust to those tool providers.
Please keep in mind that using such a VM or VM's based on the template for security and privacy critical tasks is not recommended.
How to create Penetration Testers Framework (PTF) VM
====================================================
"The PenTesters Framework (PTF) is a Python script designed for Debian/Ubuntu/ArchLinux based distributions to create a similar and familiar distribution for Penetration Testing.
PTF attempts to install all of your penetration testing tools (latest and greatest), compile them, build them, and make it so that you can install/update your distribution on any machine." (source [PTF Readme](https://github.com/trustedsec/ptf/blob/master/README.md))
**Note** PTF works on Debian testing as well as on Debian 8. PTF itself works with Debian 8, but the software tools will have missing dependencies. Metasploit for example requires a newer Ruby version than Debian 8 has in the repositories. Therefore the best way to install PTF is by upgrading a Debian 8 into Debian testing with additional Kali repositories. Instead of installing the tools from Kali, PTF will install and update the newest tools.
Create Debian Based Penetration Testers Framework (PTF) Template
----------------------------------------------------------------
1. Create PTF template
1. Follow [Create Debian Based Kali Template](/doc/pentesting/kali/) till step 7.
2. (Optional) Rename the cloned template to `ptf`
2. Download PTF
sudo apt-get install git
cd /opt
sudo git clone https://github.com/trustedsec/ptf.git
- (Optional) Configure PTF
1. Go to configuration directory
cd /opt/ptf/config
2. Edit the configuration file
for example by using vim:
sudo vim ptf.config
the configuration options are described in the `ptf.config` file
3. Install PTF
cd /opt/ptf
sudo ./ptf
**Note:** the config file has to be in the same directory as the executable. It is not
possible to do sudo ptf/ptf
PTF will put itself into `/usr/local/bin/ptf`. You can use `ptf` from now on.
4. Install/Update modules (tools)
1. Start PTF
sudo ptf
![PTF start banner](/attachment/wiki/PTF/ptf-banner.png)
2. Show available modules (tools)
ptf> show modules
3. Install/Update modules (all/)
- Install/Update all tools
ptf> use modules/install_update_all
- or by category Install/Update
ptf> use modules/code-audit/install_update_all
- or individually (example Metasploit)
1. Search for module
ptf> search metasploit
[*] Search results below:
modules/exploitation/metasploit
2. Use module
ptf> use modules/exploitation/metasploit
ptf:(modules/exploitation/metasploit)>
3. Install module
ptf:(modules/exploitation/metasploit)>install
4. Run Metasploit
ptf:(modules/exploitation/metasploit)>exit
ptf> quit
[*] Exiting PTF - the easy pentest platform creation framework.
sudo msfconsole
5. Create an AppVM based on the `ptf` template
- (Optional) Attach necessary devices
Alternative Options to PTF
--------------------------
- [BlackArch](/doc/pentesting/blackarch/)
- [Kali](/doc/pentesting/kali/)
- [Pentesting](/doc/pentesting/)

41
external/os-guides/ubuntu.md vendored Normal file
View file

@ -0,0 +1,41 @@
---
layout: doc
title: Ubuntu Template
permalink: /doc/templates/ubuntu/
redirect_from:
- /doc/ubuntu/
- /en/doc/templates/ubuntu/
- /doc/Templates/Ubuntu/
- /wiki/Templates/Ubuntu/
---
Ubuntu template(s)
==================
If you would like to use Ubuntu Linux distribution in your AppVMs, you can build and
install one of the available Ubuntu templates. These templates are currently not
available in ready to use binary packages, because Canonical does not allow
redistribution of a modified Ubuntu. The redistribution is not allowed by their
[Intellectual property rights policy](https://www.ubuntu.com/legal/terms-and-policies/intellectual-property-policy).
Install
-------
It can be built using [Qubes Builder](/doc/qubes-builder/). You can also access its
documentation in the [source code
repository](https://github.com/QubesOS/qubes-builder/blob/master/README.md).
To quickly prepare the builder configuration, you can use the `setup` script
available in the repository - it will interactively ask you which templates you
want to build.
The build for Ubuntu 14.04 LTS (Trusty) should be straightforward.
The build for Ubuntu 16.04 LTS (Xenial) is straightforward. Note that packages perl-Digest-MD5 and perl-Digest-SHA are required for the build to succeed.
----------
If you want to help in improving the template, feel free to
[contribute](/doc/contributing/).

158
external/os-guides/windows/windows-tools.md vendored Normal file
View file

@ -0,0 +1,158 @@
---
layout: doc
title: Qubes Windows Tools
permalink: /doc/windows-tools/
redirect_from:
- /doc/windows-appvms/
- /en/doc/windows-appvms/
- /doc/WindowsAppVms/
- /wiki/WindowsAppVms/
---
Qubes Windows Tools
===================
Qubes Windows Tools are a set of programs and drivers that provide integration of Windows AppVMs with the rest of the Qubes system. Currently the following features are available for Windows VMs after installation of those tools:
- Seamless GUI mode that integrates apps windows onto the common Qubes trusted desktop
- Support for [secure clipboard copy/paste](/doc/copy-paste/) between the Windows VM and other AppVMs
- Support for [secure file exchange](/doc/copying-files/) between the Windows VM and other AppVMs
- Support for qvm-run and generic qrexec for the Windows VM (e.g. ability to run custom service within/from the Windows VM)
- Xen PV drivers for Windows that increase performance compared to qemu emulated devices
Qubes Windows Tools are open source and are distributed under a GPL license.
NOTES:
- Qubes Windows Tools are currently unmaintained
- Currently only 64-bit versions of Windows 7 are supported by Qubes Windows Tools. Only emulated SVGA GPU is supported (although [there has been reports](https://groups.google.com/forum/#!topic/qubes-users/cmPRMOkxkdA) on working GPU passthrough).
- There is currently no audio support for Windows HVMs.
- There is currently no USB pass-through support for Windows HVMs.
- __This page documents the process of installing Qubes Windows Tools on versions up to R3.2.__. Installation on Qubes R4.0 is possible but is a work in progress and there are limitations/bugs (see [issue #3585](https://github.com/QubesOS/qubes-issues/issues/3585)).
Installing Windows OS in a Qubes VM
-----------------------------------
Please refer to [this page](/doc/windows-vm/) for instructions on how to install Windows in a Qubes VM.
NOTE: It is strongly suggested to enable autologon for any Windows HVMs that will have Qubes Tools installed. To do so, run `netplwiz` command from the `Win+R`/Start menu and uncheck the *Users must enter a user name and password to use this computer* option.
Installing Qubes guest tools in Windows 7 VMs
---------------------------------------------
First, make sure that `qubes-windows-tools` is installed in your system:
~~~
sudo qubes-dom0-update qubes-windows-tools
~~~
(If the above command does not work, it could be that the Qubes Tools are not in the stable repo yet. Try installing from the testing repo instead.)
You can also install the package from testing repositories, where we usually publish new versions first:
~~~
sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing qubes-windows-tools
~~~
This package brings the ISO with Qubes Windows Tools that is passed to the VM when `--install-windows-tools` is specified for the `qvm-start` command. Please note that none of this software ever runs in Dom0 or any other part of the system except for the Windows AppVM in which it is to be installed.
Before proceeding with the installation we need to disable Windows mechanism that allows only signed drivers to be installed, because currently (beta releases) the drivers we provide as part of the Windows Tools are not digitally signed with a publicly recognizable certificate. To do that:
- Start command prompt as Administrator, i.e. right click on the Command Prompt icon (All Programs -> Accessories) and choose "Run as administrator"
- In the command prompt type `bcdedit /set testsigning on`
- Reboot your Windows VM
In the future this step will not be necessary anymore, because we will sign our drivers with a publicly verifiable certificate. However, it should be noted that even now, the fact that those drivers are not digitally signed, this doesn't affect security of the Windows VM in 'any' way. This is because the actual installation ISO (the `qubes-windows-tools-*.iso` file) is distributed as a signed RPM package and its signature is verified by the `qubes-dom0-update` utility once it's being installed in Dom0. The only downside of those drivers not being signed is the inconvenience to the user that he or she must disable the signature enforcement policy before installing the tools.
To install the Qubes Windows Tools in a Windows VM one should start the VM passing the additional option `--install-windows-tools`:
~~~
qvm-start lab-win7 --install-windows-tools
~~~
Once the Windows VM boots, a CDROM should appear in the 'My Computer' menu (typically as `D:`) with a setup program in its main directory.
After successful installation, the Windows VM must be shut down and started again, possibly a couple of times.
Qubes will automatically detect the tools has been installed in the VM and will set appropriate properties for the VM, such as `qrexec_installed`, `guiagent_installed`, and `default_user`. This can be verified (but is not required) using qvm-prefs command:
~~~
qvm-prefs <your-appvm-name>
~~~
NOTE: it is recommended to increase the default value of Windows VM's `qrexec_timeout` property from 60 (seconds) to, for example, 300. During one of the first reboots after Windows Tools installation Windows user profiles are moved onto the private VM's virtual disk (private.img) and this operation can take some time. Moving profiles is performed in an early boot phase when qrexec is not yet running, so timeout may occur with the default value. To change the property use this command in dom0:
~~~
qvm-prefs -s <vm-name> qrexec_timeout 300
~~~
Using Windows AppVMs in seamless mode
-------------------------------------
Once you start a Windows-based AppVM with Qubes Tools installed, you can easily start individual applications from the VM (note the `-a` switch used here, which will auto-start the VM if it is not running):
~~~
qvm-run -a my-win7-appvm explorer.exe
~~~
![windows-seamless-4.png](/attachment/wiki/WindowsAppVms/windows-seamless-4.png) ![windows-seamless-1.png](/attachment/wiki/WindowsAppVms/windows-seamless-1.png)
Also, the inter-VM services work as usual -- e.g. to request opening a document or URL in the Windows AppVM from another VM:
~~~
[user@work ~]$ qvm-open-in-vm work-win7 roadmap.pptx
~~~
~~~
[user@work ~]$ qvm-open-in-vm work-win7 https://invisiblethingslab.com
~~~
... just like in the case of Linux AppVMs. Of course all those operations are governed by central policy engine running in Dom0 -- if the policy doesn't contain explicit rules for the source and/or target AppVM, the user will be asked whether to allow or deny the operation.
Inter-VM file copy and clipboard works for Windows AppVMs the same way as for Linux AppVM (except that we don't provide a command line wrapper, `qvm-copy-to-vm` in Windows VMs) -- to copy files from Windows AppVMs just right-click on the file in Explorer, and choose: Send To-\> Other AppVM.
To simulate CTRL-ALT-DELETE in the HVM (SAS, Secure Attention Sequence), press Ctrl-Alt-Home while having any window of this VM in the foreground.
![windows-seamless-7.png](/attachment/wiki/WindowsAppVms/windows-seamless-7.png)
Changing between seamless and full desktop mode
-----------------------------------------------
You can switch between seamless and "full desktop" mode for Windows HVMs in their settings in Qubes Manager. The latter is the default.
Using template-based Windows AppVMs
-----------------------------------
Qubes allows HVM VMs to share a common root filesystem from a select Template VM, just as for Linux AppVMs. This mode is not limited to Windows AppVMs, and can be used for any HVM (e.g. FreeBSD running in a HVM).
In order to create a HVM TemplateVM one can use the following command, suitably adapted:
~~~
qvm-create --class TemplateVM win7-x64-template --property virt_mode=HVM --property kernel='' -l green
~~~
... , set memory as appropriate, and install Windows OS (or other OS) into this template the same way as you would install it into a normal HVM -- please see instructions on [this page](/doc/hvm-create/).
If you use this Template as it is, then any HVMs that use it will effectively be DisposableVMs - the User directory will be wiped when the HVN is closed down.
If you want to retain the User directory between reboots, then it would make sense to store the `C:\Users` directory on the 2nd disk which is automatically exposed by Qubes to all HVMs.
This 2nd disk is backed by the `private.img` file in the AppVMs' and is not reset upon AppVMs reboot, so the user's directories and profiles would survive the AppVMs reboot, unlike the "root" filesystem which will be reverted to the "golden image" from the Template VM automatically.
To facilitate such separation of user profiles, Qubes Windows Tools provide an option to automatically move `C:\Users` directory to the 2nd disk backed by `private.img`.
It's a selectable feature of the installer, enabled by default.
If that feature is selected during installation, completion of the process requires two reboots:
- The private disk is initialized and formatted on the first reboot after tools installation. It can't be done **during** the installation because Xen mass storage drivers are not yet active.
- User profiles are moved to the private disk on the next reboot after the private disk is initialized.
Reboot is required because the "mover utility" runs very early in the boot process so OS can't yet lock any files in there.
This can take some time depending on the profiles' size and because the GUI agent is not yet active dom0/Qubes Manager may complain that the AppVM failed to boot.
That's a false alarm (you can increase AppVM's default boot timeout using `qvm-prefs`), the VM should appear "green" in Qubes Manager shortly after.
It also makes sense to disable Automatic Updates for all the template-based AppVMs -- of course this should be done in the Template VM, not in individual AppVMs, because the system-wide settings are stored in the root filesystem (which holds the system-wide registry hives).
Then, periodically check for updates in the Template VM and the changes will be carried over to any child AppVMs.
Once the template has been created and installed it is easy to create AppVMs based on it:
~~~
qvm-create --hvm <new windows appvm name> --template <name of template vm> --label <label color>
~~~

188
external/os-guides/windows/windows-vm.md vendored Normal file
View file

@ -0,0 +1,188 @@
---
layout: doc
title: Installing a Windows VM
permalink: /doc/windows-vm/
---
Installing a Windows VM
=======================
Qubes 4.0 - importing a Windows VM from R3.2
-------------------------------------------
Importing should work, simply make sure that you are not using Xen's newer linux stubdomain and that the VM is in HVM mode (these steps should be done automatically when importing the VM):
~~~
qvm-features VMNAME linux-stubdom ''
qvm-prefs VMNAME virt_mode hvm
~~~
Note however that you are better off creating a new Windows VM to benefit from the more recent emulated hardware: R3.2 uses a MiniOS based stubdomain with an old and mostly unmaintained 'qemu-traditional' while R4.0 uses a Linux based stubdomain with a recent version of upstream qemu (see [this post](https://groups.google.com/d/msg/qubes-devel/tBqwJmOAJ94/xmFCGJnuAwAJ)).
Windows VM installation
-----------------------
### Summary ###
~~~
qvm-create --class StandaloneVM --label red --property virt_mode=hvm win7new
qvm-prefs win7new memory 4096
qvm-prefs win7new maxmem 4096
qvm-prefs win7new kernel ''
qvm-volume extend win7new:root 25g
qvm-prefs win7new debug true
qvm-features win7new video-model cirrus
qvm-start --cdrom=untrusted:/home/user/windows_install.iso win7new
# restart after the first part of the windows installation process ends
qvm-start win7new
# once Windows is installed and working
qvm-prefs win7new memory 2048
qvm-prefs win7new maxmem 2048
qvm-features --unset win7new video-model
qvm-prefs win7new qrexec_timeout 300
# with Qubes Windows Tools installed:
qvm-prefs win7new debug false
~~~
To install Qubes Windows Tools, follow instructions [below](#xen-pv-drivers-and-qubes-windows-tools).
### Detailed instructions ###
MS Windows versions considerations:
- The instructions *may* work on other versions than Windows 7 x64 but haven't been tested.
- Qubes Windows Tools (QWT) only supports Windows 7 x64. Note that there are [known issues](https://github.com/QubesOS/qubes-issues/issues/3585) with QWT on Qubes 4.x
Create a VM named win7new in [HVM](/doc/hvm/) mode (Xen's current PVH limitations precludes from using PVH):
~~~
qvm-create --class StandaloneVM --label red --property virt_mode=hvm win7new
~~~
Windows' installer requires a significant amount of memory or else the VM will crash with such errors:
`/var/log/xen/console/hypervisor.log`:
> p2m_pod_demand_populate: Dom120 out of PoD memory! (tot=102411 ents=921600 dom120)
> (XEN) domain_crash called from p2m-pod.c:1218
> (XEN) Domain 120 (vcpu#0) crashed on cpu#3:
So, increase the VM's memory to 4096MB (memory = maxmem because we don't use memory balancing).
~~~
qvm-prefs win7new memory 4096
qvm-prefs win7new maxmem 4096
~~~
Disable direct boot so that the VM will go through the standard cdrom/HDD boot sequence:
~~~
qvm-prefs win7new kernel ''
~~~
A typical Windows 7 installation requires between 15GB up to 19GB of disk space depending on the version (Home/Professional/...). Windows updates also end up using significant space. So, extend the root volume from the default 10GB to 25GB (note: it is straightforward to increase the root volume size after Windows is installed: simply extend the volume again in dom0 and then extend the system partition with Windows's disk manager).
~~~
qvm-volume extend win7new:root 25g
~~~
Set the debug flag in order to have a graphical console:
~~~
qvm-prefs win7new debug true
~~~
The second part of the installation process will crash with the standard VGA video adapter and the VM will stay in "transient" mode with the following error in `guest-win7new-dm.log`:
> qemu: /home/user/qubes-src/vmm-xen-stubdom-linux/build/qemu/exec.c:1187: cpu_physical_memory_snapshot_get_dirty: Assertion `start + length <= snap->end' failed.
To avoid that error we temporarily have to switch the video adapter to 'cirrus':
~~~
qvm-features win7new video-model cirrus
~~~
The VM is now ready to be started; the best practice is to use an installation ISO [located in a VM](/doc/hvm/#installing-an-os-in-an-hvm-domain):
~~~
qvm-start --cdrom=untrusted:/home/user/windows_install.iso win7new
~~~
Given the higher than usual memory requirements of Windows, you may get a `Not enough memory to start domain 'win7new'` error. In that case try to shutdown unneeded VMs to free memory before starting the Windows VM.
At this point you may open a tab in dom0 for debugging, in case something goes amiss:
~~~
tailf /var/log/qubes/vm-win7new.log \
/var/log/xen/console/hypervisor.log \
/var/log/xen/console/guest-win7new-dm.log
~~~
The VM will shutdown after the installer completes the extraction of Windows installation files. It's a good idea to clone the VM now (eg. `qvm-clone win7new win7newbkp1`). Then, (re)start the VM with `qvm-start win7new`.
The second part of Windows' installer should then be able to complete successfully. You may then perform the following post-install steps:
Decrease the VM's memory to a more reasonable value (memory balancing on Windows is unstable so keep `memory` equal to `maxmen`).
~~~
qvm-prefs win7new memory 2048
qvm-prefs win7new maxmem 2048
~~~
Revert to the standard VGA adapter :
~~~
qvm-features --unset win7new video-model
~~~
Finally, increase the VM's `qrexec_timeout`: in case you happen to get a BSOD or a similar crash in the VM, utilities like chkdsk won't complete on restart before qrexec_timeout automatically halts the VM. That can really put the VM in a totally unrecoverable state, whereas with higher qrexec_timeout, chkdsk or the appropriate utility has plenty of time to fix the VM. Note that Qubes Windows Tools also require a larger timeout to move the user profiles to the private volume the first time the VM reboots after the tools' installation.
~~~
qvm-prefs win7new qrexec_timeout 300
~~~
At that point you should have a functional and stable Windows VM, although without updates, Xen's PV drivers nor Qubes integration (see sections [Windows Update](#windows-update) and [Xen PV drivers and Qubes Windows Tools](#xen-pv-drivers-and-qubes-windows-tools) below). It is a good time to clone the VM again.
Windows update
--------------
Depending on how old your installation media is, fully updating your Windows VM may take *hours* (this isn't specific to Xen/Qubes) so make sure you clone your VM between the mandatory reboots in case something goes wrong. This [comment](https://github.com/QubesOS/qubes-issues/issues/3585#issuecomment-366471111) provides useful links on updating a Windows 7 SP1 VM.
Note: if you already have Qubes Windows Tools installed the video adapter in Windows will be "Qubes video driver" and you won't be able to see the Windows Update process when the VM is being powered off because Qubes services would have been stopped by then. Depending on the size of the Windows update packs it may take a bit of time until the VM shutdowns by itself, leaving one wondering if the VM has crashed or still finalizing the updates (in dom0 a changing CPU usage - eg. shown with `xentop` - usually indicates that the VM hasn't crashed).
To avoid guessing the VM's state enable debugging (`qvm-prefs -s win7new debug true`) and in Windows' device manager (My computer -> Manage / Device manager / Display adapters) temporarily re-enable the standard VGA adapter and disable "Qubes video driver". You can disable debugging and revert to Qubes' display once the VM is updated.
Xen PV drivers and Qubes Windows Tools
------------------------------------
Installing Xen's PV drivers in the VM will lower its resources usage when using network and/or I/O intensive applications, but *may* come at the price of system stability (although Xen's PV drivers on a Win7 VM are usually very stable). There are two ways of installing the drivers:
1. installing the drivers independently, from Xen's [official site](https://www.xenproject.org/developers/teams/windows-pv-drivers.html)
2. installing Qubes Windows Tools (QWT), which bundles Xen's PV drivers.
Notes about using Xen's VBD (storage) PV driver:
- Windows 7: installing the driver requires a fully updated VM or else you'll likely get a BSOD and a VM in a difficult to fix state. Updating Windows takes *hours* and for casual usage there isn't much of a performance between the disk PV driver and the default one; so there is likely no need to go through the lengthy Windows Update process if your VM doesn't have access to untrusted networks and if you don't use I/O intensive apps. If you plan to update your newly installed Windows VM it is recommended that you do so *before* installing Qubes Windows Tools (QWT). If QWT are installed, you should temporarily re-enable the standard VGA adapter in Windows and disable Qubes' (see the section above).
- the option to install the storage PV driver is disabled by default in Qubes Windows Tools
- in case you already had QWT installed without the storage PV driver and you then updated the VM, you may then install the driver from Xen's site (xenvbd.tar).
Installing Qubes Windows Tools:
- on R3.2: see [this page](/doc/windows-tools/)
- R4.0: you'll have to install QWT for Qubes R3.2. Be warned that QWT on R4.0 is a work in progress though (see [issue #3585](https://github.com/QubesOS/qubes-issues/issues/3585) for instructions and known issues).
With Qubes Windows Tools installed the early graphical console provided in debugging mode isn't needed anymore since Qubes' display driver will be used instead of the default VGA driver:
~~~
qvm-prefs -s win7new debug false
~~~
Further customization
---------------------
Please see the [Customizing Windows 7 templates](/doc/windows-template-customization/) page (despite the focus on preparing the VM for use as a template, most of the instructions are independent from how the VM will be used - ie. TemplateVM or StandaloneVM).