Pentera Installation Guide-V5.10.2

Pentera Installation
Guide
Automated Penetration Testing at the
Click of a Button
December 20, 2023
Version 5.10 Edition
Proprietary Information
Copyright © 2023 Pentera Ltd. All rights reserved. Pentera is a registered trademark of Pentera Ltd.
Pentera, its logo, Pentera SP, PTaaS and certain names, product and service names referenced herein may be registered trademarks, trademarks, trade
names or service marks of Pentera Ltd. in certain jurisdictions.
The material contained herein is proprietary, privileged and confidential and owned by Pentera or its third-party licensors. The information herein is
provided only to the person or entity to which it is addressed, for its own use and evaluation; therefore, no disclosure of the content of this document will
be made to any third parties without specific written permission from Pentera Ltd. The content herein is subject to change without further notice.
THE INFORMATION SPECIFIED HEREIN IS PROVIDED “AS IS” AND PENTERA MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND, EXPRESS
OR IMPLIED, WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF ACCURACY,
COMPLETENESS, MERCHANTABILITY, TITLE, NON-INFRINGEMENT AND/OR FITNESS FOR A PARTICULAR PURPOSE.
Pentera reserves the right to make changes in or to the said information, or any part thereof, in its sole judgment, without the requirement of giving any
notice prior to or after making such changes to the information. Pentera shall not be expected to update or revise these statements to reflect subsequent
occurring events or circumstances, or changes in its actual results, level of activity, performance or achievements.
All other trademarks are the property of their respective owners. Other company and brand products and service names are trademarks or registered
trademarks of their respective holders.
Table of Contents
1. Planning Your Deployment ............................................................................................................................ 1
1.1. Deployment Options .......................................................................................................................... 1
1.2. Node Types ...................................................................................................................................... 2
1.3. Distributed Architecture Examples ..................................................................................................... 3
1.4. Deciding Between A Single-Server Deployment And A Distributed Deployment ....................................... 8
1.5. Switching From A Single-Server Deployment To A Distributed Deployment ............................................. 8
1.6. Segmentation .................................................................................................................................. 8
1.7. Distributed Deployment - Procedure Overview ..................................................................................... 9
2. Infrastructure Considerations ..................................................................................................................... 10
2.1. Deployment In The Cloud .................................................................................................................. 10
2.2. Examples Of Cloud Deployments ...................................................................................................... 12
2.3. Deployment On A VM ....................................................................................................................... 14
2.4. Deployment On A Physical Machine ................................................................................................... 14
3. Connectivity Requirements ........................................................................................................................ 15
4. Hardware & Software Requirements ............................................................................................................ 18
4.1. Single-Server Requirements ............................................................................................................ 18
4.2. Distributed Platform Requirements .................................................................................................. 19
5. Before You Begin ....................................................................................................................................... 21
6. Installing Ubuntu ...................................................................................................................................... 22
6.1. Ubuntu Cheat Sheet ........................................................................................................................ 35
7. Installing The Main Node ............................................................................................................................ 36
7.1. Online Installation Via CLI ................................................................................................................ 36
7.2. Offline Installation Via CLI ............................................................................................................... 45
8. Logging Into Pentera For The First Time ...................................................................................................... 53
9. Starting/Stopping Pentera ........................................................................................................................ 59
10. Configuring Network Settings Using Netplan .............................................................................................. 60
10.1. Configure Multiple NICs Using Netplan ............................................................................................. 62
11. Using A Trunk Port ................................................................................................................................... 64
11.1. Configuring A VLAN Using Netplan .................................................................................................. 65
11.2. Performing Penetration Tests On Multiple VLANs .............................................................................. 66
12. Upgrading Pentera .................................................................................................................................. 68
12.1. Upgrade Online ............................................................................................................................. 69
12.2. Upgrade Offline ............................................................................................................................. 71
12.3. Upgrading Via CLI (Legacy Procedure) ............................................................................................. 73
13. Distributed Architecture .......................................................................................................................... 75
13.1. Managing Pentera's Nodes .............................................................................................................. 75
13.2. Attack Bridges ............................................................................................................................. 83
14. Troubleshooting And Support .................................................................................................................. 100
Version 5.10 Copyright © 2023 Pentera Ltd. All rights reserved

Planning your deployment 1
1. Planning your deployment
1.1. Deployment Options
Pentera can be deployed on a single server or in a distributed manner. The recommended setup depends on the size and
distribution of the network, among other factors.
• In a single-server Pentera deployment, all Pentera capabilities are centralized on the Main Node. This deployment model
is not distributed and the Main Node must have GPU processing power to perform password cracking.
• If the Main Node does not support GPU processing, a stand-alone Cracking Node can be added. This is only relevant if the
Main Node does not support GPU.
• If the network to be tested cannot be fully covered by the Main Node, additional Pentera nodes can be added to further
extend the platform and expand its reach.
Pentera's reach can be extended by any combination of the following:
• Remote Attack Nodes (RANs)
• Dynamic Attack Nodes
• Attack Bridges (formerly known as Dynamic Attack Node Executables)
There are several ways to build out a distributed deployment, and the best option will depend on your particular network
architecture. Distributing Pentera allows for running penetration tests on multiple remote sites or networks. These sites
may be co-located within a single building on the same LAN or on different LANs. Or, they may be geographically spread
out across different regions, states, countries, or even different continents. All sites are managed by a single Pentera
management console.

1.2. Node Types
A distributed deployment of Pentera is recommended for networks that are larger, segmented, or geographically
dispersed.
Pentera has several components that can be combined in a modular fashion to plan out a distributed deployment. Each
type of Pentera Node performs different functions:
1. Main Node – The Main Node is always the first node to be installed, and only one Main Node is supported per Pentera
deployment. Given the right conditions, the Main Node has the ability to function as a stand-alone, single-server
platform that performs all functions: management, attack, and password cracking.
The Main Node can only perform password cracking if it has GPU processing power. Otherwise, a dedicated Cracking
Node will be required. For example, a Main Node installed on a VM with GPU Passthrough can support password
cracking and will not require a dedicated Cracking Node.
Additional Pentera Nodes can be installed from Pentera's web interface to distribute the platform, as explained below.
2. Cracking Node – The Cracking Node operates Pentera’s Password Cracking Engine. This node is installed on a
dedicated machine equipped with a physical GPU card. Only one Cracking Node is supported per Pentera deployment.
A Cracking Node is only relevant if the Main Node does not have a GPU.
3. Remote Attack Node – Extends Pentera's reach by providing access to remote networks, that are not reachable by the
Main Node. Every Remote Attack Node is installed on a dedicated machine, either a physical host or a VM.
There is no limit on the number of Remote Attack Nodes that can be installed. However, a maximum of 7 Remote
Attack Nodes can actively participate at any given time in a single Testing Scenario.
4. Dynamic Attack Node (DAN) – An ad-hoc Pentera deployment that enables cross-segmentation testing via a VPN
connection. The Dynamic Attack Node is automatically managed by Pentera, deployed on a Windows host during a
testing run and automatically removed at the end of the testing run.
Dynamic Attack Nodes do not require dedicated machines. They can be deployed on Windows hosts that are actively
being used for other purposes with no known degradation of the user experience.
5. Attack Bridge - A semi-permanent Windows-based Pentera deployment that enables cross-segmentation testing via
a VPN connection. The Attack Bridge is manually managed and deployed on Windows hosts.
Attack Bridges were formerly known as Dynamic Attack Node Executables.

1.3. Distributed Architecture Examples
Cracking Node & Remote Attack Node
In this deployment, Pentera's Main Node is installed in the organizational headquarters (HQ) on a VM with GPU Passthrough
architecture. (If GPU Passthrough cannot be supported, a stand-alone Cracking Node must be added. It may be installed in
the Cloud over AWS or Azure, or installed on a dedicated physical host powered with a GPU.)
In the example below, the organization has 2 different offices. If we don’t want to open the firewall from Pentera to all
the segments in the remote branch, we can deploy a Remote Attack Node (RAN) on the remote site and open 2 firewall
rules from the Main Node to the RAN. The ports are configurable, and default to port 22 and 8080. In this deployment, the
security of the remote office can be fully tested by Pentera.

Dynamic Attack Node
In this scenario, 2 network segments are separated by a firewall.
Pentera is located in the server segment. In order to reach the user segment we have to open the firewall from Pentera
to all of the user segment. If we cannot provision a dedicated host (VM / Physical) for a Remote Attack Node (DAN), we
can deploy a Dynamic Attack Node (DAN) on one of the hosts in that segment instead. The Pentera Main Node will be
responsible for all attack and processing activity. The host serving as a Dynamic Attack Node will channel all of Pentera’s
communication to the targeted segment, providing Layer-2 (LAN) visibility to the network.
Highlights:
• The Dynamic Attack Node is automatically deleted at the end of the task by Pentera.
• Continue working on the Windows host as usual while Pentera's Dynamic Attack Node is running in the background.
• All of Pentera's communication to the remote segment is channeled through the DAN NIC (Network Interface Card of the
Dynamic Attack Node). Note that each test can run one Dynamic Attack Node at a time.

Multi-homed Main Node (Multiple NICs)
In this scenario, the target network consists of several VLANs. The Main Node can be equipped with multiple Network
Interface Cards (NICs) to connect it with the different VLANs. This way, you can select the attack interface per test from
the Pentera web interface.
When creating a Testing Scenario template, use the Attack Interface Selection step to configure the relevant VLAN. This
determines the VLAN Pentera will use to launch its attacks. Pentera will automatically detect the available VLANs for easy
configuration of the test. See Attack Interface Selection [67].
In the example below, the Main Node is connected to the target network via 3 NICs, each connected to a different VLAN.
Pentera can attack the target network via one interface at a time. The relevant VLAN to serve as the Attack Interface is
configurable from the Pentera web interface, when creating a Testing Scenario template.
Easily select the attack interface per test from the Pentera web interface. See Attack Interface Selection [67]

Multi-homed Remote Attack Node (Multiple NICs)
In this scenario, the remote network consists of several VLANs. The Remote Attack Node can be equipped with multiple
Network Interface Cards (NICs) to connect it with the different VLANs. This way, you can select the relevant attack
interface per test from the Pentera web interface. The configuration process is similar to that of the multihomed Main
Node, as shown above.
In the example below, the Remote Attack Node is connected to the target network via 3 NICs, each connected to a different
VLAN. Pentera can attack the target network via one interface at a time. The relevant VLAN to serve as the Attack
Interface is configurable from the Pentera web interface, when creating a Testing Scenario template.

Attacking over a Trunk Port
If the Pentera Main Node or Remote Attack Node (RAN) is connected to the switch via a trunk port, Pentera can be
configured to launch its attacks from a different VLAN for every test. This will introduce additional variability to your
security validations and achieve better testing results.
Pentera can attack the target network via one interface at a time. The relevant VLAN to serve as the Attack Interface is
configurable from the Pentera web interface. When creating a Testing Scenario template, Pentera will automatically detect
the VLANs available to serve as attack interfaces and allow the user to make a selection.

1.4. Deciding between a single-server deployment and a distributed deployment
To decide whether your organization will benefit from a distributed deployment or a single-server deployment of Pentera,
you’ll need to evaluate your network size and segmentation, and its physical locations.
In general, a single-server Pentera deployment is appropriate if you need to perform penetration testing on a specific
network in one central site. In most other cases, a more complex and distributed deployment method will be required to
fully cover the network.
1.5. Switching from a Single-Server Deployment to a Distributed Deployment
You can scale up your single-server Pentera platform by adding Remote Attack Nodes and Dynamic Attack Nodes.
Once additional nodes are added, the original Pentera server will become the Main Node, and remain responsible for
Pentera's web portal (user interface), management functions, and orchestrating attack and password cracking actions.
1.6. Segmentation
Pentera uses sniffing techniques to steal credentials. Sniffing is performed by manipulating Multicast Name Resolution
Protocols, including LLMNR, mDNS, and NBNS. Multicast Name Resolution Protocols use broadcast and/or multicast
requests that are prone to manipulation by attackers.
To perform sniffing attacks, Pentera requires Layer 2 (Data-Link) access to the targeted network. In other words, Pentera
has sniffing capabilities in all broadcast domains to which it has Layer 2 access. Deploying Remote Attack Nodes offers a
way to give Pentera access to additional broadcast domains in order to expand the attack surface.

1.7. Distributed Deployment - Procedure Overview
In a distributed deployment, Pentera is installed over several nodes. Once the Main Node is installed, additional nodes can
be deployed from Pentera's user interface. Following is an overview of the deployment procedure:
1. Prepare the VM, cloud infrastructure, or physical machine to be installed with Pentera's Main Node. Install it with the
required Ubuntu operating system. See Installing Ubuntu [22]
2. Install Pentera's Main Node via the command line on the designated Ubuntu machine. See Installing the Main
Node [36]
3. Log into Pentera for the first time [53] and provide your licensing information.
4. Prepare the VMs, cloud infrastructure, or physical machines to serve as Pentera's Remote Attack Nodes and/or
Cracking Node.
Install and configure the Ubuntu operating system as with the Main Node. See step 1, above.
5. Log into Pentera's web interface and follow the steps in the user guide to install a Remote Attack Node and/or
Cracking Node.

Infrastructure Considerations 10
2. Infrastructure Considerations
Pentera's Main Node and Cracking Node can be deployed on a VM managed by a Cloud service provider, a local VM, or a
physical device. Below are the technical requirements for each deployment method.
• Deployment in the Cloud [10]
• Deployment on a VM [14]
• Deployment on a Physical Machine [14]
2.1. Deployment in the Cloud
Pentera's Main Node, Cracking Node, or both may be deployed on cloud infrastructure over AWS or Azure.
Supported Cloud Service Providers:
• AWS EC2
• Azure Virtual Machines
Cloud deployments are subject to the general hardware and software requirements and port whitelisting rules. See
Connectivity Requirements [15] and Hardware & Software Requirements [18] for further information.
Precautions
When deploying a Pentera instance in the Cloud, be sure to restrict access to it, as follows:
• Allow connections only for internal organizational use
• Do not expose the instance to the Internet
Following the above best-practices will help to avert potential attacks.
Authentication Requirements for Azure
For Azure Virtual Machines, note that only password authentication is supported. In other words, SSH public keys are not
supported.

Recommendations
When the Main Node is in the Cloud, we recommend setting Remote Attack Nodes and the Cracking Node to pull
upgrades directly from Pentera's repositories. This helps to optimize node installation and upgrade speed. See Whitelisting
Requirements (Applies to Online Installations) [16]

2.2. Examples of Cloud Deployments
Pentera's Main Node, Cracking Node, or both may be deployed over AWS or Azure. The following architectures are
supported.
Main Node with GPU-compute power deployed in the Cloud.
No Cracking Node is required. Any other components are

deployed on-premises, using local VMs or physical machines.
Main Node (without GPU) deployed in the Cloud.
A Cracking Node and any other components are deployed on-

premises, using local VMs or physical machines.

Main Node and Cracking Node deployed in the Cloud, preferably

in the same segment.
Any other components are deployed on-premises, using local VMs

or physical machines.
IMPORTANT
We recommend deploying the Main Node and

Cracking Node in same segment, for increased
security.
Cracking Node deployed in the Cloud.
The Main Node (without GPU) and any other components are
deployed on-premises, using local VMs or physical machines.
For all of the above, other components may include Remote Attack Nodes, Dynamic Attack Nodes, and Attack Bridges.

2.3. Deployment on a VM
If installing Pentera on a VM (Virtual Machine), the following considerations apply:
• The network must have a bridged connection and must not be configured to use a NAT Gateway.
• It is recommended to allocate a dedicated NIC for Pentera’s Attack and Management Interfaces for easier segmentation
control.
• Note that Pentera has a dependency on the VM's UUID, and that the virtual disk (typically VMDK) cannot be migrated
between VMs. Therefore, attaching an existing virtual disk to a new VM will cause a failure when starting Pentera.
Contact support if you plan to migrate between VMs or back up your Pentera.
2.4. Deployment on a Physical Machine
If installing Pentera on a physical machine (as opposed to a VM), secure boot must be disabled. This can be done using the
machine's Boot Menu.

Connectivity Requirements 15
3. Connectivity Requirements
Main Node Connectivity
Pentera's Main Server has several interfaces, as follows:
• Web Interface - The Main Node serves Pentera's web interface over port 8181. To access Pentera's web interface, users
will browse to https://<Pentera-Main-Node-IP>:8181.
• Attack Interface - This is the interface used by the Main Node to engage with the tested networks.
• Management Interface - This interface is used for the Main Node to communicate with other Pentera Nodes.
Port Connectivity Requirements for a Distributed Platform
If your Pentera Platform involves more than 1 node, you will need to ensure that no firewall restrictions are placed on
Pentera's interfaces which may prevent Pentera’s operation.
The following ports are required to support communication between Pentera's nodes.
Interface Default Port Configurable

Inter-Node Communication 8080 Yes
Installation and Upgrade 22 No
Pentera's Management Interface allows the Main Node to communicate with the Cracking Node and Remote Attack Nodes.
It is comprised of the following:
• Inter-Node Communication is bidirectional and performed over port 8080, by default. The port can be configured.
• Installation and upgrade is performed over port 22 (SSH).
Any firewall restrictions of the above interfaces can prevent Pentera’s operation, interfere with the installation and upgrade
of Pentera, block the execution of penetration tests, and prevent the general operation of Pentera.
TIP
The communication ports are configurable from the Environment menu in the Pentera user interface.

Other Requirements for a Distributed Platform

• Every Pentera Node requires a static IP address. A static IP address is required for the Management Interface and every
Attack Interface of every Pentera Node in a distributed platform. In other words, all Pentera Nodes require a static IP
address, including: Main Node, Cracking Node, and Remote Attack Nodes.
You can use the netplan utility following initial installation of the Ubuntu OS as explained in Using a Trunk Port [64].
• NICs to be used by Pentera need to have a live default gateway configured.
Whitelisting Requirements (Applies to Online Installations)
Pentera Nodes that are connected to the web can be installed and upgraded directly from Pentera's online repositories.
Pentera's installation packages can be downloaded directly from Pentera's Internet Repositories. For this option,
permissions to download data from the relevant resources is required.
Whitelist the following URLs for download in your firewall:
• https://core.pentera.io/
• https://repositories.pentera.io/
• https://docker-images.pentera.io/
• logs.pentera.io
• download.docker.com
• *.docker.io

Applicability
• Main Node
Whitelist the above URLs from the Main Node to support online installation and upgrades. If this is not possible, Pentera
will need to be installed and upgraded offline. See Pentera can be deployed online or offline [36].
• Remote Attack Node & Cracking Node
If the Node is configured to pull installation packages from the Internet, it will require the option to reach the above
URLs. Otherwise, it does not.
To check which Installation Source is configured for the Node, go to Environment > Distributed Architecture > Node
Management .
If Installation Source = Internet Repository, the Node requires connectivity to the the above resources. Otherwise, it
does not.

Hardware & Software Requirements 18
4. Hardware & Software Requirements
IMPORTANT
Please contact us via the Support Portal before placing your final hardware order to confirm that it is compliant with the technical
requirements and fully compatible with Pentera.
4.1. Single-Server Requirements
The following hardware and software requirements apply if your Pentera platform will be installed on a single server. The
server must include a dedicated GPU for password cracking.
If you plan to deploy Pentera on a VM, configure the ESXi host to use the GPU of the virtual host graphics card. If GPU
pass-through will be used, see the VMware Compatibility Guide for shared pass-through graphics.
CPU Intel i7 (6 cores minimum) or higher

Memory 32 GB RAM
Hard Drive At least 250 GB SSD of available disk space
OS Ubuntu server version 20.04.6 (Versions 20.04.5 / 20.04.4 / 20.04.3 are also acceptable. They will be updated
automatically.)
Network Interface Card An RJ45 NIC is mandatory on the PC/laptop/server for direct network connection (Intel, Realtek and so on).
(NIC)
IMPORTANT
Killer Gaming NICs and USB network dongles are not supported.
Dedicated Graphics A dedicated high-quality graphic card with GPU is critical to provide optimal password cracking results.
Processing Unit (GPU)*
If GPU pass-through will be used, see the VMware Compatibility Guide for shared pass-through graphics.
*GPU is not required if a
stand-alone Cracking Node • Supported NVIDIA display drivers include:
will be used.
• GeForce GTX 16x0 series
• GeForce RTX 20x0 series
Supported NVIDIA Data Center cards include: A-Series, T-Series, and more.
See NVIDIA's official specifications for Data Center Driver For Linux X64
See NVIDIA's official specifications for Linux X64 (AMD64/EM64T) Display Driver

4.2. Distributed Platform Requirements
4.2.1. Main Node Requirements (Distributed Platform)
The following table describes the hardware and software requirements for Pentera's Main Node in a distributed installation.
Note that if a separate Cracking Node is installed, the Main Node does not require a dedicated GPU.

Memory 32 GB RAM
OS Ubuntu server version 20.04.6 (Versions 20.04.5 / 20.04.4 / 20.04.3 are also acceptable. They will be updated
automatically.)
(NIC)
IMPORTANT
Dedicated Graphics A dedicated high-quality graphic card with GPU is critical to provide optimal password cracking results.
Processing Unit (GPU)*
If GPU pass-through will be used, see the VMware Compatibility Guide for shared pass-through graphics.
*GPU is not required if a
stand-alone Cracking Node • Supported NVIDIA display drivers include:
will be used.
4.2.2. Remote Attack Node Requirements
The following table describes the hardware and software requirements for installing a Pentera Remote Attack Node.

Memory 32 GB RAM
OS Ubuntu server version 20.04.6 (Versions 20.04.5 / 20.04.4 / 20.04.3 are also acceptable. They will be updated automatically.)
IMPORTANT

4.2.3. Cracking Node Requirements
The Cracking Node is responsible for Pentera's advanced password cracking efforts. The following table describes the
hardware and software requirements for the installation of a dedicated Cracking Node.
A dedicated Cracking Node is only relevant when the Main Node does not support the necessary GPU processing power.
Note that only one Cracking Node may be installed per Pentera Platform.
IMPORTANT
Please contact us via the support portal before placing your final hardware order to verify that the dedicated GPU is compliant with the
technical requirements.
CPU Intel i7 or higher

Memory 16 GB RAM
OS Ubuntu server version 20.04.6 (Versions 20.04.5 / 20.04.4 / 20.04.3 are also acceptable. They will be updated automatically.)
IMPORTANT
Dedicated Graphics A dedicated high-quality graphic card with GPU is critical for providing optimal password cracking results.
Processing Unit
• Supported NVIDIA display drivers include:

Before You Begin 21
5. Before You Begin
Treat Pentera Nodes as black box appliances. Below are a few tips and clarifications gathered over many installations.
• Verify that the designated machine on which you will be installing Pentera meets the hardware requirements. See
Hardware & Software Requirements [18].
• Verify that you have the latest Pentera version and installation package from Pentera.
• Make sure there are no firewall restrictions on Pentera's interfaces which can prevent Pentera’s operation. See
Connectivity Requirements [15] for details.
• Verify that the designated Pentera server/laptop is connected to a port that is allowed by the Network Access Control
(NAC).
• Verify that network configuration settings are compatible with Pentera's requirements. See Configuring Network
Settings using Netplan [60] for details.
• For the online installation procedure, make sure that Pentera has internet access to Pentera's cloud repositories. See
Connectivity Requirements [15].
• Pentera supports corporate proxy server configuration. There are several ways to configure a proxy server:
• During initial installation, directly from the Command Line Interface (CLI). See Online Installation via CLI [36]
• Post-installation, directly from the Pentera user interface.
NOTE
Please collect all proxy server configuration settings before starting the installation.

Installing Ubuntu 22
6. Installing Ubuntu
Install the Ubuntu operating system on the VM or host to prepare it for installation of Pentera. Pentera supports Ubuntu
server version 20.04.6. (Versions 20.04.5 / 20.04.4 / 20.04.3 are also acceptable. They will be updated automatically.)
Version Compatibility
Before proceeding with the installation, note the following about version compatibility:
• Adhere to the specified release number and image type to avoid unnecessary technical difficulties.
• Avoid modifying the installation package or the repos prior to the installation. Download the default Ubuntu package
as is, without modifying the default configurations to ensure that packages can be downloaded from public internet
repositories.
• Refrain from using the sudo apt-get upgrade command and avoid performing any unnecessary OS updates
throughout the installation process.
Updating the OS before installing Pentera may interfere with the installation or cause it to fail owing to the fact that
Pentera uses a hardened custom package repository during the installation process.
• Avoid installing any 3rd party services or agents on the machine. No other containers are permitted to run alongside
Pentera and are likely to interfere with system upgrades and regular maintenance.
• Confirm the memory requirements are fulfilled before proceeding with the installation. Note that different Pentera
nodes have different memory requirements. See Hardware & Software Requirements [18]
Procedure
1. Download Ubuntu server version Ubuntu server version 20.04.6 from the official repository: https://
releases.ubuntu.com/20.04/. Be sure to select the server version.
The direct link to download the file: http://old-releases.ubuntu.com/releases/focal/ubuntu-20.04.5-live-server-

amd64.iso

2. Ensure that the correct file was downloaded. The file name should be: ubuntu-20.04.6-live-server-amd64.iso.
3. Select your preferred language.

4. Select your preferred keyboard layout.
5. Set the network configuration to set a static IP:
a. Select the option Edit IPv4
b. Select the IPv4 method: Manual

c. Fill out the form information:
• Subnet
• Address - It is recommended to use the same address previously defined for Pentera. This will ensure the
smoothest migration process.
• Gateway
• Name servers

d. Save your changes. The window will collapse and show the static IP configured for the server.
6. Configure a proxy address, if relevant.
7. Configure Ubuntu archive mirror, if relevant. You can click Enter to keep the default and skip this step.

8. Configure the storage configuration to use the entire disk space as an LVM group. Enable both Use an entire disk and
Set up this disk as an LVM group. Then, select Done.
9. The following screen will appear. This is where you will configure the partitioning.

a. Unmount the drive. Select the / directory and select Unmount.
b. Edit the logical partition. Under available devices, select ubuntu-lv to edit it.

c. In the editing window, edit the field Mount to grant the maximum available space on the / drive. You can see the
amount to be allocated under Capped Partition.
d. Confirm the updated partitions to make sure that there are no available devices. Review the details to ensure that
no space remains unallocated.

Storage configurations are highly variable and depend on your particular instance. The screenshot below is
provided as an illustrative example.
e. A warning will appear asking you to confirm your selection. Opt to Continue.

10. Create the pentera user in the profile setup. Set your server's hostname as you please. In the example below, it is set to
pentera_main.
11. Enable Ubuntu Advantage, if relevant. Otherwise, keep the default and click Enter to continue to the next step.

12. Install OpenSSH to enable SSH connectivity to the server.
13. For Featured Server Snaps , keep the default and click Enter to continue to the next step. In other words, do not select
anything.
All the packages required by Pentera will be automatically installed during the installation of Pentera.

14. Start the installation and allow it to run uninterrupted.
15. After the installation is complete, select Reboot Now.

16. That’s it! You can connect to the newly-installed server once it has rebooted. Use the pentera user you created in the
previous step to log in.
17. Verify that the IP you configured is set correctly. Run:
ip a
18. Verify that the pentera user is in the sudo group. Run:
sudo groups pentera
19. Verify connectivity to the server via SSH.

20. Verify that the DNS configuration was applied correctly. Run:
resolvectl dns
6.1. Ubuntu Cheat Sheet
We've put together a short list of basic commands to help you get started with Ubuntu.
Centos 7 Command Ubuntu Command Purpose

ifconfig ip a List all associated IP addresses on all network interfaces
vi vi Open text editor
- nano Open text Editor
/etc/yum.repos.d/*.repo /etc/apt/sources.list Repository configuration file
/etc/yum.conf /etc/apt/apt.conf Repository configuration file
yum search apt search List the packages along with their latest available versions and a short description
yum search {keyword} apt search {keyword} Search for a package by a keyword related to the package name
yum list apt list List repositories
yum info apt show Show package information
yum install apt install Install a package
yum install --skip-broken apt -f install Fix broken dependencies during package installation
yum remove apt purge {package_name} Uninstall a package and remove everything related to it, including the configuration files

Installing the Main Node 36
7. Installing the Main Node
Pentera's Main Node is installed via the command line interface (CLI). Once the Main Node is installed, additional nodes can
be installed from Pentera's web interface.
Pentera can be deployed online or offline
Pentera can be installed using an online or offline installation process. The preferred method depends on your use case.
Offline installation is only intended for cases where Pentera will remain completely disconnected from the internet. For all
other cases, online installation is recommended.
• Pentera can be installed and operated online. For the online installation process, you will need to verify that the
Pentera server/node has direct access to the internet and can reach Pentera's code repositories. See Connectivity
Requirements [15].
• Pentera can be installed and operated offline. For the offline installation process, no internet connectivity is required.
7.1. Online Installation via CLI
The following explains how to install Pentera’s Main Node via the Command Line Interface.
Procedure
1. Copy the zipped installation file to the /home/pentera/ directory on the designated machine: ansible-5_6_x.tar
.
TIP
It is recommended to use an SSH client (such as WinSCP/MobaXterm) when copying files from a Windows machine and for machine
administration.
2. To unzip the file, run (with the exact file name):
sudo tar -xvf ansible-5_6_x.tar
3. Confirm that you are currently logged in with the pentera user. Run:
whoami
4. To check that the OS, connectivity, and memory requirements have been fulfilled, run:
sudo ./ansible-5_x.run -- -f

Modify the command as per the installer version on hand.
If the conditions have been met, details for the following will be printed along with success messages:
• OS
• CPU
• RAM
• Disk Space
• Docker Hub
• AWS
If the test was successful, you are ready to install Pentera. Proceed to the next step.
5. Run the installation commands, as follows:
sudo chmod +x ansible-5.x.run

sudo ./ansible-5.x.run

6. The process will decompress the Pentera Installer and ask you to confirm the version number. Respond y to continue
with the installation.
7. The installation process supports corporate proxy server configuration. Pentera will only use the Proxy server to
access installation and update files. If you want to configure access to the internet using a corporate proxy, respond y
to continue. Otherwise, respond n.
8. The installation process will run. Allow a few minutes.
9. Configure your network environment by selecting one of the following options:
• Single NIC - Choose when using a machine with a single NIC for management and attacking
• Multiple NICs - Choose when using a machine or machines with multiple physical network cards
• VLANs - Choose when you need to test multiple network segments (configurations)
• Multiple NICs & VLANs - Choose when you have multiple NICs to segmented network and VLAN interfaces
After selecting an environment, follow the relevant procedure below to configure your network settings. Pentera uses
a Netplan configuration (YAML) file to update network settings. Once complete, you will be able to review and confirm
the Netplan configuration before proceeding to the next step.
A typical Netplan YAML configuration file (Each ens represents a NIC)

Follow the relevant procedure below to configure the selected environment.
Single NIC - Pentera will use the same NIC for its management and attack interfaces. Define the following settings:
• Interface name
• IP/subnet mask
• DNS IPs (for nameservers) – You can add multiple IPs
• Default gateway IP address
• Metric

Multiple NICs - Pentera will use a management NIC and multiple attack NICs. Define the following settings:
• For the Management NIC:
• Interface name
• IP/subnet mask
• DNS IPs (nameservers) – You can add multiple IPs
• Default gateway IP
• Metric (Tip: Set Pentera's Management Interface with the lowest metric to give it top priority. For example, a
metric of 0 takes priority over 1.)
• Attack NIC 1 - Define the settings below for each attack NIC:
• Interface name
• IP/Subnet mask
• DNS IPs (nameservers) - You can add multiple IPs
• Metric (Tip: The metric must be higher than Pentera's Management Interface (The lower the metric, the higher the
priority) and unique from the other metrics.)
Add additional NICs as needed
VLANs - Pentera will use a management VLAN and multiple attack VLANs. Define the following settings:
• Configure the Management VLAN:
• VLAN ID
• Interface name
• IP/subnet mask
• DNS IPs (nameservers) - you can add multiple IPs
• Metric (Tip: Pentera's Management Interface requires the lowest metric to give it top priority. For example, a
Configure the Attack VLAN 1 - Define the settings below for each attack VLAN:
• VLAN ID
• Interface name
• IP/subnet mask

Add additional VLANs as needed
Multiple NICs & VLANs - Pentera will use multiple VLANs and NICs. Define the settings below:
• Select the management interface type:
• VLAN
• NIC
Select the attack interface type:
• VLAN
• NIC
Add additional interfaces as needed.
10. You will be prompted to review and confirm your Netplan configuration’s YAML file. Click Y to confirm or N to start over.
Once confirmed, your new Netplan configuration is saved to file path /netplan.yaml.latest. The previous configuration
is saved as netplan.yaml.v1
11. You will be prompted to select Pentera's network interfaces.
a. Select the Management Interface from the available options. The management interface is used for accessing
the Pentera user interface and Pentera’s SSH management port.
b. Select the Attack Interface. The Attack interface is connected to the network that will be targeted by Pentera
and subjected to penetration testing.

TIP
If there is only a single NIC on the Pentera machine, use the same network interface for both the Management and Attack
Interfaces.
c. If a CNAME address value of the network was configured for Pentera, enter it here. Otherwise, if no such
configuration was done, press the ENTER key to skip to the next step.
12. (Recommended) Provide the IP address or FQDN of your NTP server to sync the clocks with Pentera. You can set up
syncing with up to 4 servers.
TIP
Syncing the clocks between Pentera and your NTP server is crucial for supporting two factor authentication (2FA or MFA) for users to
access Pentera. It can also optimize Kerberos attacks and other exploitation methods that are highly sensitive to clock syncing.
It is possible to set up syncing after installation directly from the integrations menu in the Pentera web interface. However, this option is
limited to syncing with a single NTP server.

13. During installation an automatic reboot will occur. The installation will show the following before rebooting:
ask [hardening : Wait for reboot locally] **********

Pausing for 300 seconds
Please allow the machine to reboot.
14. After the machine has restarted, log in again with the user pentera and perform the following command: sudo su
Next, you will be asked to enter the pentera user password.
15. Please note that when the following message is displayed, you should wait while Pentera downloads, which may take
some time to complete.
TASK [pentera : Start pentera docker services] *
16. Check the last line of the file to verify that the installation was successful. The following message should appear:
PLAY RECAP************************
localhost: ok=34 changed=16
unreachable=0 failed=0

If the process was completed without errors you should see failed=0. If this is not the case, please contact support
for assistance.
17. Wait approximately 10–15 minutes after completion for all the services to load and start.
18. You are now ready to log into Pentera for the first time. See Logging into Pentera for the first time [53]

7.2. Offline Installation via CLI
The offline installation method is intended for installing a Pentera machine that is completely disconnected from the
Internet. This procedure should be performed after consulting with a Pentera professional. A deployment installer
containing all the prerequisite software will be delivered via a link provided by Pentera or a Pentera representative.
NOTE
Once decided on an offline installation, future upgrades will be performed offline as well. To switch between methods, consult with Pentera
Support.
Procedure
1. Copy the installation installer .run file to the designated Pentera server and place it under the path /home/pentera.
2. Confirm that you are currently logged in with the pentera user. Run:
whoami
3. To check that the OS, connectivity, and memory requirements have been fulfilled, run:
sudo ./ansible-5_x.run -- -f
If the conditions have been met, details for the following will be printed along with success messages:
• OS
• CPU
• RAM
• Disk Space
Since the host is offline, the following will return as false:
• Docker Hub
• AWS
4. Run the installation commands:
sudo chmod +x ansible-5.x-deployer.run

sudo ./ansible-5.x-deployer.run -- -o

5. The process will decompress the Pentera Installer and ask you to confirm the version number. Respond y to continue
with the installation.
6. The installation process supports corporate proxy server configuration. Pentera will only use the Proxy server to
access installation and update files. If you want to configure access to the internet using a corporate proxy, respond y
to continue. Otherwise, respond n.
7. The installation process will run. Allow a few minutes.
8. Configure your network environment by selecting one of the following options:
• Single NIC - Choose when using a machine with a single NIC for management and attacking
• Multiple NICs - Choose when using a machine or machines with multiple physical network cards
• VLANs - Choose when you need to test multiple network segments (configurations)
• Multiple NICs & VLANs - Choose when you have multiple NICs to segmented network and VLAN interfaces
After selecting an environment, follow the relevant procedure below to configure your network settings. Pentera uses
a Netplan configuration (YAML) file to update network settings. Once complete, you will be able to review and confirm
the Netplan configuration before proceeding to the next step.
A typical Netplan YAML configuration file (Each ens represents a NIC)

Follow the relevant procedure below to configure the selected environment.
Single NIC - Pentera will use the same NIC for its management and attack interfaces. Define the following settings:
• Interface name
• IP/subnet mask
• DNS IPs (for nameservers) – You can add multiple IPs
• Metric

Multiple NICs - Pentera will use a management NIC and multiple attack NICs. Define the following settings:
• For the Management NIC:
• Interface name
• IP/subnet mask
• DNS IPs (nameservers) – You can add multiple IPs
• Metric (Tip: Set Pentera's Management Interface with the lowest metric to give it top priority. For example, a
• Attack NIC 1 - Define the settings below for each attack NIC:
• Interface name
• IP/Subnet mask
• DNS IPs (nameservers) - You can add multiple IPs
Add additional NICs as needed
VLANs - Pentera will use a management VLAN and multiple attack VLANs. Define the following settings:
• Configure the Management VLAN:
• VLAN ID
• Interface name
• IP/subnet mask
• Metric (Tip: Pentera's Management Interface requires the lowest metric to give it top priority. For example, a
Configure the Attack VLAN 1 - Define the settings below for each attack VLAN:
• VLAN ID
• Interface name
• IP/subnet mask

Add additional VLANs as needed
Multiple NICs & VLANs - Pentera will use multiple VLANs and NICs. Define the settings below:
• Select the management interface type:
• VLAN
• NIC
Select the attack interface type:
• VLAN
• NIC
Add additional interfaces as needed.
9. You will be prompted to review and confirm your Netplan configuration’s YAML file. Click Y to confirm or N to start over.
Once confirmed, your new Netplan configuration is saved to file path /netplan.yaml.latest. The previous configuration
is saved as netplan.yaml.v1
10. You will be prompted to select Pentera's network interfaces.
a. Select the Management Interface from the available options. The management interface is used for accessing
the Pentera user interface and Pentera’s SSH management port.
b. Select the Attack Interface. The Attack interface is connected to the network that will be targeted by Pentera
and subjected to penetration testing.

TIP
If there is only a single NIC on the Pentera machine, use the same network interface for both the Management and Attack
Interfaces.
c. If a CNAME address value of the network was configured for Pentera, enter it here. Otherwise, if no such
configuration was done, press the ENTER key to skip to the next step.
11. (Recommended) Provide the IP address or FQDN of your NTP server to sync the clocks with Pentera. You can set up
syncing with up to 4 servers.
TIP
Syncing the clocks between Pentera and your NTP server is crucial for supporting two factor authentication (2FA or MFA) for users to
access Pentera. It can also optimize Kerberos attacks and other exploitation methods that are highly sensitive to clock syncing.
It is possible to set up syncing after installation directly from the integrations menu in the Pentera web interface. However, this option is
limited to syncing with a single NTP server.

12. During installation an automatic reboot will occur. The installation will show the following before rebooting:
ask [hardening : Wait for reboot locally] **********

Pausing for 300 seconds
Please allow the machine to reboot.
13. After the machine has restarted, log in again with the user pentera and perform the following command: sudo su
Next, you will be asked to enter the pentera user password.
14. Please note that when the following message is displayed, you should wait while Pentera downloads, which may take
some time to complete.
TASK [pentera : Start pentera docker services] *
15. Check the last line of the file to verify that the installation was successful. The following message should appear:
PLAY RECAP************************
localhost: ok=34 changed=16
unreachable=0 failed=0

If the process was completed without errors you should see failed=0. If this is not the case, please contact support
for assistance.
16. Wait approximately 10–15 minutes after completion for all the services to load and start.
17. You are now ready to log into Pentera for the first time. See Logging into Pentera for the first time [53]

Logging into Pentera for the first time 53
8. Logging into Pentera for the first time
Contact your Pentera Admin for information about how to connect to Pentera and your user information. Or, if you're the
first user, follow the steps below [53] to finish setting up your Pentera platform.
Set up your first Admin User

The first step after installing Pentera is to upload your license and set up the first admin user.
To log into Pentera for the first time:

1. From your workstation, validate that you can access the machine running Pentera by running: ping <target
machine IP>.
TIP
If your Pentera Platform is distributed, you need to reach the IP of your Pentera Main Node to access the Pentera application.
2. Open a browser window. Google Chrome and Microsoft Edge are supported.
3. Navigate to your Pentera platform over port 8181. Type the IP address in your browser as follows: https://
<target_machine>:8181. For example, if your main Pentera node is at 10.10.168.10, navigate to https://
10.10.168.10:8181/.
You should see a welcome screen, as shown below:

4. Upload a valid license to proceed, and click Next.
5. Create your first Admin user. Provide the following:
• Full name - Provide your name.
• Title - Provide your official role at the company, for example, Chief Information Security Officer.
• User name - The user name will be used to authenticate to Pentera directly.
• Description - Add a description with additional information, as necessary.
• Email - Provide your company email address.
• Password - Set a strong password.
User must change password on next login (Optional) - For additional security, you have the option to enable the toggle
button to force a password change on the next login.

6. Read and agree to Pentera's Terms and Conditions. Your agreement will sign the End User License Agreement (EULA)
and will send the details of the user entered in the previous step to Pentera's Management Server.
7. Congratulations! You are now ready to log into Pentera with the admin credentials you just created.


Logging in with 2FA for the first time
If you've been invited to Pentera with 2FA enabled, you'll need to sync Pentera with your personal device using a time-based
verification app. Any standard time-based verification app can be used, including Google Authenticator, AUTHY, and
others.
To log into Pentera with 2FA enabled:
1. Open Pentera in your browser and input your username and password. The following window will appear -
2. Open the selected time-based verification app on your device. If you don't yet have a verification app installed, install it
to proceed.
When ready, click Yes, ready to scan code.
3. Scan the QR code shown by Pentera with your verification app. Alternatively, you have the option to manually input the
Account name (It's your username in Pentera) and Key (A random 32 alphanumeric code).

4. Your new Pentera account will now appear in your verification app with a time-bound 6-digit code. Every time you login
to Pentera, you will be asked to input the 6-digit code from your verification app.

Starting/Stopping Pentera 59
9. Starting/Stopping Pentera
Pentera runs as a daemon upon boot.
Run the following commands to start, stop or restart the Pentera application service.
• To start the Pentera application service, run:
sudo systemctl start pentera
• To stop the Pentera application service, run:
sudo systemctl stop pentera
• To restart the Pentera application service, run:
sudo systemctl restart pentera
• To view the status of the Pentera application service, run:
sudo systemctl status pentera

Configuring Network Settings using Netplan 60
10. Configuring Network Settings using Netplan
Netplan is a recommended command-line network configuration utility introduced in Ubuntu 17.10 to easily manage and
configure network settings in Ubuntu systems. Netplan makes it possible to configure Pentera's network interfaces and
VLANs by editing the Netplan YAML configuration file.
You can edit the yaml file using a Linux file editor such as vi.
Netplan Configuration Explained
The structure of the yaml file is as follows:
network:
ethernets:
<interface_name>:
addresses: [IP_address/subnet_mask]
nameservers:
addresses: [DNS_IP]
routes:
- to: default
via: <default_gateway_IP>
metric: <number>
version: 2
• The interface name
• The IP address or subnet mask
• The DNS IP address for the nameserver
• For the route:
• Add the default gateway IP address.
• Add a route metric count.
A routing metric is a value which identifies the cost that's associated with using that route. The route will go in the
direction of the gateway with the lowest metric count.
WARNING
Avoid setting a metric count = 20 while configuring Netplan. This is because Pentera will automatically add a pre-defined metric count of
20 to the default NIC for failover.

For example, below is a configuration for an interface named ens160:
network:
ethernets:
ens160:
addresses: [172.20.21.30/16]
nameservers:
addresses: [8.8.8.8]
routes:
- to: default
via: 172.20.0.1
metric: 50
version: 2
WARNING
YAML files are extremely sensitive to indentation. We recommend using a YAML linter to verify that the syntax and indentation are valid.
Procedure
1. Update the Netplan configuration yaml file.
By default, the .yaml configuration file is located under: /etc/netplan
2. After making your changes, save the file.
3. Execute the following commands:
sudo netplan try

sudo netplan apply
4. To confirm that the interfaces have been updated, run: ip a
It will list all network interfaces, their IP addresses, subnet masks and gateways, and MAC addresses.
For some extra reassurance, you can run ip r to see the created routes.
5. That's it. The interfaces are now updated.

10.1. Configure multiple NICs using Netplan
When to use multiple NICs
When the machine has more than one physical network card and needs to connect to different network segments, you will
need to configure multiple NICs and networks using Netplan.
For example, see below an example of a Netplan configuration for 2 NICs: ens160 and ens33.
network:
ethernets:
ens160:
addresses: [172.26.21.60/16]
nameservers:
routes:
- to: default
via: 172.26.0.1
metric: 50
ens33:
addresses: [192.168.20.25/24]
nameservers:
routes:
- to: default
via: 192.168.20.1
metric: 100
version: 2
Procedure
1. Before you begin, you will need to know the network interface names. To look them up, run the command: ip a
2. Open the Netplan configuration yaml file to update it. You can use the vi editor or another Linux file editor to view and
edit the file.
3. In addition to the basic network settings, you will need to add a route metric count.
A routing metric is a value which identifies the cost that's associated with using that route. The route will go in the
direction of the gateway with the lowest metric count.

WARNING
Avoid setting a metric count = 20 while configuring Netplan. This is because Pentera will automatically add a pre-defined metric count of
20 to the default NIC for failover.
4. After making your changes, save the file.
sudo netplan try

sudo netplan apply

Using a Trunk Port 64
11. Using a Trunk Port
You can connect Pentera to a network using a trunk port to run penetration tests against different VLANs without
physically moving the server. A trunk port is a networking feature that enables multiple VLANs to be carried through a
single network link by utilizing a trunking protocol.
To enable multiple VLANs on a single link, the Ethernet frames of individual VLANs must be identified. The most common
and recommended method is IEEE 802.1Q, which adds a tag to the Ethernet frame to label which VLAN it belongs to. If
your environment includes equipment from multiple vendors, 802.1Q is the only suitable option as it is based on an open
standard.
The example below shows how to connect Pentera through a trunk port to provide direct access to VLANs 10–12.

Pentera's Network Interfaces
Pentera's server has 2 network interfaces:
• Management Interface – A static network interface that enables access to Pentera’s web server or SSH management
interface. This interface is out-of-band of the attack process and should be located in the DMZ or network management
segment.
• Attack Interface – A dynamic interface from which all penetration test attack operations originate. When connecting
Pentera to the network using a trunk interface, the target network for the penetration test can be changed by selecting a
different attack interface.
11.1. Configuring a VLAN using Netplan
Netplan can be used to configure VLANs for Pentera.
Sample VLAN Configuration
Below is an example Netplan configuration file for VLANs.
network:
version: 2
ethernets:
ens192:
optional: true
vlans:
vlan.219:
id: 219
link: ens192
addresses: [172.19.3.229/16]
nameservers:
addresses:
- 192.168.32.2
- 8.8.8.8
search: []
routes:
- to: default
via: 172.19.0.1
metric: 100
vlan.220:
id: 220
link: ens192
addresses: [192.168.10.0/24]
nameservers:
addresses:

- 192.168.32.2
- 8.8.8.8
search: []
routes:
- to: default
via: 192.168.10.1
metric: 200
In the example above, the following interfaces are configured:
• NIC: ens192
• VLANs: 219 and 220
Each with its own IP, default gateway, nameservers and route metric (which must be different from other VLANs).
Procedure
1. Update the Netplan configuration yaml file.
2. Save the file.
sudo netplan try

sudo netplan apply
11.2. Performing Penetration Tests on Multiple VLANs
With Pentera, you can perform penetration tests on multiple network segments using a dedicated NIC for each segment or
using a trunk port.

For each Testing Scenario, you will select the relevant NIC to serve as Pentera's Attack Interface. This setting enables you
to switch to another NIC in order to perform a penetration test on a different target VLAN.
Attack Interface Selection
If your Pentera nodes are multi-homed, you can configure the attack network interface for Pentera to automatically switch
to the correct NIC at the beginning of the run. This option is relevant if Pentera is connected to several target networks via
different Network Interface Cards (NIC), LAN adapters, or similar.
For optimal results, Pentera should be directly connected to the network under test in the same broadcast domain.
Otherwise, Pentera will have limited ability to perform relay, sniffing, and spoofing attacks.
NOTE
The Pentera nodes required for the Testing Scenario are automatically determined by the IP ranges to be covered by the test.
To configure the Attack Interface:
1. Toggle the Attack Interface Selection to enable it.
For every Pentera node, the IP ranges covered by the node are listed.
2. For each node, select the Attack Interface from the drop-down list. NIC format: <NIC name>: <NIC CIDR subnet
mask>. Example: ens192: 192.168.32.209/24.
3. You can click the refresh button to refresh the list of NICs.

Upgrading Pentera 68
12. Upgrading Pentera
It's recommended to upgrade to the latest product release as soon as possible to benefit from the newly added exploits and
features.
The Pentera upgrade process can be performed directly from the Pentera web interface or it can be performed on the
server via CLI (Command Line Interface).
The upgrade process supports corporate proxy server configuration, which incorporates the destination to which a proxy
server filters all outgoing HTTPS requests.
CAUTION
Before installing a proxy server in an enterprise, the Proxy Server Integration must be configured to allow Pentera outbound communication
with Pentera’s cloud services.
Getting notified of new version updates
For each new product release, the following popup menu is automatically displayed to notify Pentera administrators of a
new release.
Automatic rollback
If for any reason an error occurs during the upgrade process, automatic version rollback is automatically performed.

12.1. Upgrading Pentera (Online)
You can check for updates and run the upgrade process directly from your Pentera platform. The only requirement is that
your Pentera platform is connected to the Internet.
CAUTION
It is not possible to upgrade Pentera while a Testing Scenario is in progress. If someone attempts to upgrade Pentera while a test is running, a
warning message will be shown requesting to stop all Testing Scenarios before performing the upgrade.
To upgrade Pentera to a new version:
1. Go to Administration > Upgrade.
2. Click the Check for Updates button to get the latest update.
3. Select the appropriate Pentera version from the list and click the Download button to begin downloading
the upgrade package. You may view the download progress under in the Status column. The following displays –

4. After the download has completed, the Status column changes to Ready for Upgrade. The following displays –
5. To start the upgrade process, select the downloaded version from the list and click the Upgrade button .
A confirmation window appears:
6. Click the Upgrade button to confirm and proceed the upgrade. The following displays –
7. A Pentera upgrade may take up to 30 minutes. During the upgrade process, do not close or refresh this window before
a notification has been displayed that the process is complete. The following displays –

8. If for any reason the upgrade process fails, Pentera automatically reverts back to the last working version and a popup
message is displayed. In this case, please contact Pentera support for assistance.
12.2. Upgrading Pentera (Offline)

To upgrade from a file when Pentera is offline:
1. Go to Administration > Upgrade.
2. Click the Upgrade from File button (top right corner). The file explorer of the machine will open.
3. Locate the new *.run offline upgrade file provided by Pentera. Select the file and click the Open button.
A progress notification will display:

4. To start the upgrade process, select the downloaded version from the list and click the Upgrade button .
A confirmation window appears:
5. Click the Upgrade button to confirm and proceed the upgrade. The following displays:
6. A Pentera upgrade may take up to 30 minutes. During the upgrade process, do not close or refresh this window before
a notification has been displayed that the process is complete. The following displays:

7. If for any reason the upgrade process fails, Pentera automatically reverts back to the last working version and a popup
message is displayed. In this case, please contact support for assistance.
12.3. Upgrading via CLI (Legacy Procedure)
Upgrading directly from your Pentera web interface is recommended. However, if you need to upgrade using the legacy
process, this is also possible.
Online upgrade via CLI
1. Copy the upgrade binary *.run file named ansible-5.x-stable.run to the machine under the /home/pentera directory.
The filename will depend on the version number.
2. First, check to confirm that Pentera is not running. Run:
docker ps
If Pentera is running, stop it. Run:

3. Run the upgrade binary:
sudo chmod +x ansible-5.x-stable.run

sudo ./ansible-5.x-stable.run
4. Respond y to the prompt to continue with the upgrade.
5. Continue with the standard installation procedure. See Online Installation via CLI [36]
Offline upgrade via CLI
The offline upgrade method is intended for upgrading a Pentera machine that is completely disconnected from the Internet
and was previously installed in an offline fashion. This procedure should be performed after consulting with Pentera
Support.
A deployment installer package containing all the prerequisite software will be delivered via a link provided by a Pentera
representative. You will need to transfer the package to the designated Pentera host.
1. Move the Pentera installation deployer *.run file to the /home/pentera location.
2. If Pentera is running, run the following to stop it:
3. Run the upgrade binary:
sudo chmod +x ansible-5.x-deployer.run

sudo ./ansible-5.x-deployer.run -- -o
4. Continue with the standard installation procedure. See Online Installation via CLI [36]
IMPORTANT
The machine will not reboot by default, as this is not a new installation.

Distributed Architecture 75
13. Distributed Architecture
Pentera can be distributed over large, complex, geographically dispersed, and/or segmented networks by deploying
additional system components. The following components are created and managed directly from Pentera's user interface.
In other words, log into your Pentera platform to begin.
Options for distributing the Pentera platform:
• Managing Pentera's Nodes [75] - For Remote Attack Nodes and/or a dedicated Cracking Node deployed over a
dedicated Ubuntu server.
• Attack Bridges [83] - For lightweight Attack Bridges deployed over hosts in the target network. Pentera's Attack
Bridges can run in the background while the hosts are being used for other purposes as well. The hosts do not need to be
dedicated for Pentera's software.
13.1. Managing Pentera's Nodes
Go to the Distributed Architecture > Node Management page to create, edit, and manage your Pentera Nodes. Here you
can also see whether the Pentera Node is online and which IP ranges are covered by each node.
See Distributed Architecture Examples [3] to learn more about the options and help planning out your Pentera platform.
Page permissions
• Pentera Admins can view and edit the Distributed Architecture page. They have the permissions to manage all aspects
of the Pentera Platform.

• Pentera Operators have view-only permissions to the Distributed Architecture page.
• Pentera View-Only users do not have access to the Distributed Architecture page. The tab will simply not display for
them.
Information provided on the Node Management page
Each row represents a Pentera node in your Pentera platform. The following information is shown for each node:
• Name – Specifies the name of the node.
• Type – Specifies the type of node. It may be a Main Node, Cracking Node, or Attack Node.
• IP Address – Specifies the IP address of the node.
• Port – Specifies the port used to communicate with the node.
• Operating System - Specifies the OS installed on the node.
• Version – Specifies the Pentera software version currently installed on the node.
• Status – Indicates the current connectivity status of the node, as follows:
• Online – The node was successfully installed and is operational.
• Offline – The node was successfully installed but is not currently online. Possible causes include a firewall issue,
computer shutdown, etc.
• Non-Operational – The node was successfully installed but the node has some type of error and is therefore not
operational. Common causes include an error starting Pentera or a software version mismatch between nodes. If this
occurs, please contact our support for assistance.
• Pending – The node definition is incomplete and must be completed before the node can be installed.
• Installing – The node is currently being installed.
• IP Ranges – Specifies the IPs that the Pentera node can perform penetration testing on.
13.1.1. Installing a Pentera Node
You may install additional Remote Attack Nodes to distribute your Pentera platform and test a wider range of IPs. Or, you
may install a stand-alone Cracking Node, if the Main Node requires it.
NOTE
See the official Installation Guide for the hardware and OS requirements and considerations for placement of Attack Nodes in the corporate
network.

To install a node:
1. In the Distributed Architecture page, click the New button. The following displays –
2. In the Type dropdown list, select the node type. Note that a Cracking node must be installed on a machine with a
physical GPU.
3. In the Name field, enter a free-text name for the node.
4. In the IP Address field, enter the IP address of the dedicated computer on which to install the node.
5. In the Node Communication Port field, enter the port to be used for communicating with the node. This is an
HTTPS-based port. By default, this port is 8080. This port is used to communicate with the node, after its installation.

6. In the SSH Username and SSH Password fields, enter the SSH credentials of the user to be used on the computer on
which the node is being installed.
7. In the SSH Port field, enter the port used to install and manage the node. By default, this port is 22.
8. In the Installation Source dropdown list, select from where installation files are to be copied. By default, the
installation files are copied from the Main node, but it some cases it may be more efficient to copy them from
the Internet repository in order to prevent copying the files over a slow network link.
9. For an Attack node, specify the IP ranges to be used for attacks by selecting one of the following options. This step is
not relevant for a Cracking node.
• Select the Type IP Ranges radio button and then specify the range of IP addresses. The Attack node will only be able
to run on IPs in the range configured.
If you specify an IP range that overlaps the range defined for another node, a warning message displays.

NOTE
Any IPs that are not within any range on any installed node are automatically assigned to the Main node. In other words,IPs that are not
explicitly covered by the range of a Pentera Attack node are automatically assigned to the Main node.
Whenever you run a penetration test containing a subset or all the IP ranges assigned to a specific Attack node, the attack is
performed from this Attack node and not from the Main node.
• Select the Upload radio button to upload a text file.
10. Click the Install button. At this point, the SSH credentials provided in the previous step are validated on
the computer on which the node is to be installed. If the credentials are valid, the installation will continue to the next
step. If an error prevented the validation, a prompt will ask you to retype the credentials.
11. Next, the network interfaces defined on the remote computer are checked. If there is only one such interface, then it
is automatically selected and the next page of the node installation wizard displays. If there is more than one network
interface, the following displays in which you select the attack network interface to be used. Select the attack network
interface to be used by selecting its radio button.
12. Click the Next button. The following displays –
13. Select the management network interface to be used by selecting its radio button.

14. Click the Next button.
The installation window will show the installation logs running while the node is being installed.
15. Node installation can take between 30–40 minutes to complete, depending on the speed of the Internet connection.
You can either click the Close button to close this window or wait until the installation completes. The
window shows Operation Done once the installation completes.
After node installation completes, the Distributed Architecture page redisplays, showing the new node and its status in
the Status column. For a successful installation, the status shows Online for the new node.
NOTE
A node with a Pending status means that there is missing information in the definition of the new node, which must be completed before the
node can be installed. In this case, you can click the Pending link in the Status column in the Distributed Architecture page to open the node
definition window at the point in the installation wizard where information is missing. Then, simply fill in the missing information and click
Install to install the node.
13.1.2. Editing Node Configurations
A node’s properties can be modified, as needed.

To edit a node:
1. In the Distributed Architecture page, check the checkbox of the node that you want to modify.
2. Click the Edit button. The following displays:
3. Modify the node’s properties, as needed. All fields are editable except for the Node Communication Port and SSH Port
fields.
NOTE
The name of the default node cannot be edited. The Node Communication Port and SSH Port fields will be editable in a future Pentera
version.
13.1.3. Upgrading a Node
When a new Pentera software version is released, all nodes connected to the Main Node are automatically upgraded. If for
any reason a node was not upgraded during such a process (for example, if a node was offline), then its software version
can be manually upgraded, as described below.

To upgrade a node:
1. In the Distributed Architecture page, select the Node to be upgraded to a new version of Pentera.
2. Click the Upgrade button. A window displaying the progress of the update will track the progress of the
update.
The node upgrade can take between 30–40 minutes to complete, depending on the speed of the Internet connection.
You can either click the Close button to close this window or wait until the upgrade completes.
3. The window shows Operation Done once the process completes.
13.1.4. Removing a Node
A Pentera Node can be removed, as needed.
To remove a node:
1. In the Distributed Architecture page, select the Node you wish to delete.
2. Click the Delete button.
You will be asked to confirm the deletion.
13.1.5. Troubleshooting Node Installation
Checking node installation logs
If a node is not successfully installed, you can check the logs to look for possible errors and troubleshoot the installation.
You can also access the log for a given node by clicking its status link in the Status column, as shown below –

Node shows pending status
If a node shows a Pending status, it is missing information is blocking the node from being installed. To complete the
missing information, in the Distributed Architecture page, click the Pending link in the Status column to open the node
definition window at the point in the installation wizard where the information is missing. Then, simply fill in the missing
information and click Install to install the node.
13.2. Attack Bridges
13.2.1. Attack Bridge Prerequisites
Introduction
Deploy an Attack Bridge to expand Pentera’s Layer 2 penetration testing capabilities to a remote segment that is outside
the reach of Pentera's Nodes.
An Attack Bridge is deployed on a Windows host in a remote segment, where it creates a VPN connection back to
the parent Pentera node. This enables the parent node to use its own MAC and IP addresses in the remote segment, giving
Pentera layer 2 access in the remote segment. Either the Main Node or a Remote Attack Node can be selected to serve as
a parent node.
IMPORTANT
Only one Attack Bridge can be deployed per segment.

Deployment Prerequisites
Target host prerequisites
The following requirements apply to the host. This is the machine on which the Attack Bridge will be run.
1. OS requirements
The Attack Bridge can only be run on hosts running x64 bit versions of the following Windows Operating Systems:
• Windows 10
• Windows 2012R2
• Windows 2016
• Windows 2019
2. User permissions
Credentials for a user account are required to run the Attack Bridge Executable File on the Windows target host.
Either of the following permissions are acceptable:
1. Privileged domain account with local administrative permissions on the target host
2. Local admin account on the target host
3. Promiscuous mode
Promiscuous mode must be enabled on the target host. The exact configuration depends on the type of Windows host
that will be used.

Target host platform Configuration

Windows hardware Promiscuous mode is enabled by default.
Windows hosted by VMware (vSphere) Configure the port on the vSwitch / PortGroup to which the VM host is connected.
Windows hosted by HyperV • Set the MAC address to Dynamic
• Enable MAC address spoofing
4. EDR/AV/EPP Rules
Whitelist the following to prevent security tools from blocking the download or killing the process:
Type What to allow

Application Whitelist the Attack Bridge Executable File in your AV/EDR/EPP tools. You may need to calculate the file hash, as explained below.
Each Attack Bridge is deployed using an executable file that is customized for a particular host. The file is created and managed in
Pentera from Environment > Distributed Architecture > Attack Bridges.
See how to calculate a file hash [88] below.

Port Outgoing port: 44443
Networking
Firewall Whitelisting Rules
To enable communication between the Attack Bridge and the parent Pentera node, whitelist the relevant port across the
network.
Communication Direction Allowed ports

Target host to parent Pentera Node Port 44443
Switch
The following examples are specific to CISCO equipment. Apply similar settings on other layer 2 equipment, as relevant.
1. Port Security
Allow communication of 2 different MAC addresses via the same port, using one of the following configurations:

Settings Port security Settings

Option 1 • Port Security = Enabled
(Recommended) • Maximum MAC Addresses = 2
• Bind the port to 2 specific MAC addresses:
• Target host MAC address
• MAC address of the Virtual NIC

Option 2 • Port Security = Enabled
• Maximum MAC Addresses = 2

Option 3 • Port Security = Disabled
2. Dynamic ARP Inspection Settings (ARP Protect)
The following table describes in what cases there is a need to add a new access list (IP and MAC of the Virtual NIC) to
the ARP table.
ARP Protect DHCP Snooping Assigned IP ARP Table Changes
(Virtual NIC)
Enabled Enabled Dynamic No changes required
Enabled Enabled Static Create an ARP-ACL (MAC+IP of the virtual NIC) and assign it to ARP Protect on the specific
VLAN.
See the appendix for further information [90].

Disabled – – No changes required
vSphere
The following settings are required if the target host is a vSphere client.
1. Advanced settings at the vSwitch level
To preserve the security posture of the vSwitch, apply the security settings to the port level instead of the entire
vSwitch.
Under override port policies, set the following:
• Security policy = Allowed
• Traffic filtering and marking = Allowed

2. Security settings at the Host Port level
Override the existing settings and set the following security configurations:
• Promiscuous mode = Override & Accept
The host will receive frames that are not destined for it
• Forged transmits = Override & Accept
The host will transmit frames that are not sourced from it
3. Traffic rules
Create an ACL for Traffic Filtering and Marking with the following rules:
• Allow incoming and outgoing traffic to both of the MAC addresses of the Windows host and only to them.
• Configure the last rule to Deny Any Any to enforce these settings.

Appendix
How to calculate a file hash
Run the PowerShell command Get-FileHash to calculate the hash value for a specific file. Be sure to specify the file
path and desired algorithm:
Get-FileHash {complete file path} -Algorithm {hash type}
Click to learn more in Microsoft's official documentation.
Example showing how to calculate the MD5 hash for a file
How to whitelist a specific file in Windows Defender
1. Open Windows Security. Under Virus & threat protection settings, select Manage settings.

2. Under Exclusions, select Add or remove exclusions.
3. Select Add an exclusion > File and select the relevant file.

4. The file will appear on the list of Exclusions.
Additional Resources
• Configuring Port Security by Cisco
• DHCP Snooping by Cisco
• Dynamic ARP Inspection by Cisco
• vSphere Traffic Filtering by VMware
13.2.2. Deciding Between an Attack Bridge and a Dynamic Attack Node
Attack Bridges are functionally similar to Dynamic Attack Nodes. Both solutions are designed to provide Pentera L2 access
to a remote network segment by establishing a VPN connection.
A Dynamic Attack Node is a small non-persistent software component that Pentera automatically deploys during testing
and removes at the end of testing. In contrast, an Attack Bridge is manually downloaded and managed on the target host.
Therefore, if your network can meet the requirements to support a Dynamic Attack Node, this is the preferred option as
it is fully automated and managed by Pentera. Otherwise, you can manually deploy and and manage Attack Bridges on
compatible Windows hosts.
13.2.3. Procedure Overview
1. Plan the deployment
The first step is to identify a host that is a good candidate to run the Attack Bridge. It must meet the host
prerequisites.
The key is to select a host that can serve as a bridge to connect the parent Pentera node with another network
segment currently outside the parent node's reach.

2. Meet the networking requirements
Fulfill the networking requirements to support the Attack Bridge.
3. Create the Attack Bridge
Each Attack Bridge is configured for a specific host with a specific IP address.
Open the Environment tab > Distributed Architecture > Attack Bridges, and follow the wizard to create an Attack
Bridge.
The procedure will result in an executable file you will need to download and save where it can be transferred to the
designated host.
In the background, Pentera will create a VPN connection on the parent node, which will be activated once the targeted
host is running the executable. See detailed instructions below.
4. Run the executable file on the target host
Transfer the executable to the target host and run the file. The file can be run locally or from the command line.
• To run the file locally on the host: right-click the executable file (.exe file) and select Run as Administrator.
The file must be run in highest integrity mode and User Account Control bypass mode. In other words, admin
rights are not sufficient.
IMPORTANT
The executable will need to be run every time the host is rebooted or the user logs out.
• To run the file from the command line using an administrator CMD, run the following:
{Attack Bridge Executable Name} /usermode_bridge

# for example
# AttackBridge-192.168.15.1__default-node-10.0.80.9.exe /usermode_bridge
IMPORTANT
Closing the CMD window kills the process.
5. Confirm that the VPN connection is live
Before moving on to the next step, check that the VPN connection is live.
Go to Environment tab > Distributed Architecture > Attack Bridges, and review the VPN Status to ensure that it is
connected.

6. Select the Attack Interface in the Testing Scenario
Configure (or edit) a Testing Scenario. In the Ranges section, set the template to cover IPs found in the same network
segment as the host running the Attack Bridge.
Next, under the Attack Interface Selection, select the relevant VPN.
If it does not appear in the menu, go back to the previous step and check the VPN status. The VPN can only be selected
as an Attack Interface after it was first established, even if it is not actively connected. In other words, the VPN will not
be available for selection if it was never established.

7. Run the test
Pentera will use the host installed with the Attack Bridge as a pivot machine to reach across network segmentation.
13.2.4. Creating an Attack Bridge

1. Before you begin, decide which host will be used to run the Attack Bridge and prepare its internal IP address. If the
host has multiple NICs (Network Interface Cards), determine which NIC will be used for the VPN tunnel.
IMPORTANT
Only one Attack Bridge can be deployed per segment.
Also note that the Attack Bridge is customized per host and specifically tied to its internal IP address.
2. In Pentera, go to the Environment tab and select the tab Attack Bridges.
3. Select the New button to launch the wizard.
4. Provide the Host Details:
• Attack Bridge Name - Provide a name to identify the Attack Bridge. Note that the name can be edited later on, at
any point.
• Host IP - Specify the internal IPv4 address of the host designated to run the Attack Bridge.
• Parent Node - The parent Pentera node will be automatically determined. It may be the Main Pentera Node or
another Remote Attack Node in your Pentera platform.
You can visit the Node Management screen to view which nodes are available and the IP ranges they each cover.

• Bind IP - (Optional) Specify the IP of the relevant NIC IP. This is relevant if the host has multiple NICs. By default, the
Host IP is also used to bind to the VPN bridge.
• Parent Node is reachable via a public network - Toggle this option to enable it. This option is relevant if NAT or PAT
(Network Address Translation or Port Address Translation) is used to reach the Parent Node.
You can skip this step if the host selected to run the Attack Bridge resides on the same internal network as its
parent Pentera node.
• Public IP/Hostname - Specify the public IP address or hostname of the Pentera Parent Node. This step applies
where Network Address Translation (NAT) is in use.
• Public Port - Specify the public port used for the Pentera Parent Node. This step applies where Port Address
Translation (PAT) is in use.
5. Select Next to progress to the next step.
6. Configure the MAC address assignment method for the Virtual Attack Interface on the Parent Node:
a. Automatic
Select this option for the MAC address to be randomly generated.
b. Manual
Manually set the MAC address of the Attack Interface to be used by the Parent Node. Use Colon-Hexadecimal
notation, for example: CE:46:D6:FD:1F:70.

REQUIREMENT
The MAC address must be unicast and locally administrated. To check if this requirement is met, confirm that the second character
is 2, 6, A, or E. For example: xE:xx:xx:xx:xx:xx.
7. Configure the IP address of the Virtual Attack Interface of the Parent Node:
a. DHCP (Recommended)
Select this option for Dynamic IP assignment. The IP address will be automatically assigned once the executable
is run on the host.
b. Manual
Select this option to configure a static IP address. You will need to provide the following:
• IP Address
• Subnet Mask
• Default Gateway
• DNS Servers (Optional) - List the IP addresses of the DNS servers by priority, from first to last.
If none are listed, the attack bridge will default to the DNS servers that are used by the parent node.
8. Select Next to progress to the next step.
9. Download the executable and save it for future reference. The executable file is not saved in Pentera and will not be
available for download once the wizard is closed.

The file name follows the convention: DAN-{bind ip}__{parent node type}-{parent node ip}.exe, for example:
DAN-192.168.39.1__Main-172.19.5.23.exe.
10. Transfer the executable file to the target host and run it.
11. Proceed to the next steps. See Procedure Overview [90]
13.2.5. Deleting Attack Bridges
You can remove Attack Bridges when you are done using them.
There are 2 aspects to deleting an Attack Bridge:
• Removing the executable file directly from the host. This step is not performed by Pentera.
It is recommended to perform this step first.
• Deleting the item from the list of Attack Bridges in Pentera. This action deletes the relevant virtual NIC on the Parent
Node and removes the records from the table.

Procedure
1. Open the Environment tab > Distributed Architecture.
2. Select the tab Attack Bridges.
3. Check-off the relevant entities to select them. Bulk deletion is supported.
4. Click the Delete button above the list and confirm your action.
5. Done! The deleted entities will be removed from the list of Attack Bridges. This action also deletes the relevant virtual
NICs on the Parent Node.
WARNING
Deleting an Attack Bridge from the Pentera UI does not remove the executable file from the host. It is recommended to check the host manually
to ensure that the EXE file has been removed. See
The executable file name is listed in the table, for example: DAN-192.168.39.1__Main-172.19.5.23.exe.
13.2.6. Managing Attack Bridges
Review the list of existing Attack Bridges to easily manage them, check on their connectivity status, and review their
Attack Interface details.

The following information is provided for each entity:
• Attack Bridge Name - A descriptive name. This can be edited at any point.
• Executable file - Specifies the name of the executable file. The file is only available for download from the wizard, when
creating a new executable, and cannot be restored from Pentera.
The file name follows the convention: DAN-{bind ip}__{parent node type}-{parent node ip}.exe, for example:
DAN-192.168.39.1__Main-172.19.5.23.exe.
• Host IP - Specifies the internal IP address of the host where the Attack Bridge is activate.
• Bind IP - Specifies the NIC IP that interfaces with the target network. The Bind IP is identical to the Host IP, unless the
host has multiple NICs.
• Parent Node - Specifies the Node and IP address of the Parent Pentera Node.
• Public IP / Hostname of Parent Node - Only relevant if Network Address Translation (NAT) is used to reach the Parent
Node. Specifies the public IP address or hostname for the Pentera Parent Node.
• Public Port of Parent Node - Only relevant if Port Address Translation (PAT) is used to reach the Parent Node. Specifies
the public port for the Pentera Parent Node.
• Attack Interface - Specifies the Attack Interface created on the target host when the bridge is live, for example:
vpn_1, MAC=5e:11:b6:46:dd:23, IP=not set. This is the Attack Interface used to configure the Testing
Scenario template in Pentera. See Attack Interface Selection [67]
• VPN name - Specifies the VPN name, for example: vpn_13. The VPN name is auto-generated and cannot be changed.
• MAC address - The MAC address may be automatically generated or manually set, depending on how the Attack Bridge
was configured. For example, MAC=5e:11:b6:46:dd:23.

• IP address - The IP may be dynamic or static, depending on how the Attack Bridge was configured. If the IP is
controlled by DHCP, it will show IP=not set until the VPN is connected.
• VPN Status - Specifies the current status of the VPN bridge to the Parent Pentera Node in real-time.
• Connected - The VPN bridge is live and ready for testing.
• Not connected - The VPN bridge is down and the Attack Bridge is not currently active.
To fix the issue and to activate the bridge, run the executable file on the target host.
• Never established - The VPN bridge has never yet been activated.
To fix the issue and to activate the bridge, run the executable file on the target host.

Troubleshooting and Support 100
14. Troubleshooting and Support
Please visit our Support Portal at https://support.pentera.io/ for guidance, support, and questions. We welcome your
inputs and requests.

Pentera Installation Guide-V5.10.2

Uploaded by

Copyright:

Available Formats

You might also like

Pentera Installation Guide-V5.10.2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Pentera Installation Guide-V5.10.2

Uploaded by

Copyright:

Available Formats

Pentera Installation

Version 5.10 Copyright © 2023 Pentera Ltd. All rights reserved

1. Planning your deployment

1.1. Deployment Options

Pentera's reach can be extended by any combination of the following:

• Remote Attack Nodes (RANs)

• Dynamic Attack Nodes

• Attack Bridges (formerly known as Dynamic Attack Node Executables)

Version 5.10 Copyright © 2023 Pentera Ltd. All rights reserved

1.2. Node Types

Attack Bridges were formerly known as Dynamic Attack Node Executables.

Version 5.10 Copyright © 2023 Pentera Ltd. All rights reserved

1.3. Distributed Architecture Examples

Cracking Node & Remote Attack Node

Version 5.10 Copyright © 2023 Pentera Ltd. All rights reserved

Dynamic Attack Node

In this scenario, 2 network segments are separated by a firewall.

Version 5.10 Copyright © 2023 Pentera Ltd. All rights reserved

Multi-homed Main Node (Multiple NICs)

Version 5.10 Copyright © 2023 Pentera Ltd. All rights reserved

Multi-homed Remote Attack Node (Multiple NICs)

Version 5.10 Copyright © 2023 Pentera Ltd. All rights reserved

Attacking over a Trunk Port

Version 5.10 Copyright © 2023 Pentera Ltd. All rights reserved

1.4. Deciding between a single-server deployment and a distributed deployment

1.5. Switching from a Single-Server Deployment to a Distributed Deployment

Version 5.10 Copyright © 2023 Pentera Ltd. All rights reserved

1.7. Distributed Deployment - Procedure Overview

Version 5.10 Copyright © 2023 Pentera Ltd. All rights reserved

• Deployment in the Cloud [10]

• Deployment on a Physical Machine [14]

2.1. Deployment in the Cloud

Supported Cloud Service Providers:

• Azure Virtual Machines

• Allow connections only for internal organizational use

• Do not expose the instance to the Internet

Following the above best-practices will help to avert potential attacks.

Authentication Requirements for Azure

Version 5.10 Copyright © 2023 Pentera Ltd. All rights reserved

Version 5.10 Copyright © 2023 Pentera Ltd. All rights reserved

2.2. Examples of Cloud Deployments

Main Node with GPU-compute power deployed in the Cloud.

No Cracking Node is required. Any other components are

Main Node (without GPU) deployed in the Cloud.

A Cracking Node and any other components are deployed on-

Version 5.10 Copyright © 2023 Pentera Ltd. All rights reserved

Main Node and Cracking Node deployed in the Cloud, preferably

Any other components are deployed on-premises, using local VMs

We recommend deploying the Main Node and

Cracking Node deployed in the Cloud.

Version 5.10 Copyright © 2023 Pentera Ltd. All rights reserved

If installing Pentera on a VM (Virtual Machine), the following considerations apply:

2.4. Deployment on a Physical Machine

Version 5.10 Copyright © 2023 Pentera Ltd. All rights reserved

Main Node Connectivity

Pentera's Main Server has several interfaces, as follows:

Port Connectivity Requirements for a Distributed Platform

Interface Default Port Configurable