11. Kali Linux in the Enterprise
11.1. Installing Kali Linux Over the Network (PXE Boot)
Overview:
Setting up PXE (Preboot eXecution Environment) allows you to boot and install Kali Linux on multiple machines over the network without needing physical boot media. This is ideal for environments where you need to perform a large-scale deployment of Kali Linux or streamline the installation process. PXE uses a combination of TFTP (Trivial File Transfer Protocol) and DHCP (Dynamic Host Configuration Protocol) servers to enable network booting.
Here’s a step-by-step guide to configuring PXE boot for Kali Linux installation:
1. Setting Up the Network Boot Environment
To get started, you'll need to set up both TFTP and DHCP/BOOTP servers. You can either use dnsmasq to handle both services together or configure them separately for more complex setups.
Dnsmasq is a lightweight solution for DHCP and TFTP, which simplifies the setup.
Separate DHCP and TFTP daemons: In more advanced scenarios, you might prefer using isc-dhcp-server and tftpd-hpa.
2. Installing and Configuring Dnsmasq (for DHCP and TFTP)
Install dnsmasq:
Configure dnsmasq: Edit the
/etc/dnsmasq.conffile to define network interface, DHCP range, and TFTP settings. Example configuration:Restart dnsmasq: After saving the configuration, restart dnsmasq to apply the changes:
3. Download and Configure Kali Linux Installation Files
Now, you need to download the necessary Kali Linux installation files to serve them over the network.
Create the TFTP root directory:
Download the appropriate Kali netboot archive:
For 64-bit (amd64), use:
For 32-bit (i386), use:
Extract the archive:
Verify files: Check that the files have been extracted correctly. You should see files like:
4. Customizing Boot Parameters
To automate the installation, you can predefine settings such as language, keyboard layout, and network configuration using a preseed file. A preseed file is used to provide automatic answers to the installation process.
Modify the boot parameters in the
txt.cfgfile: Edit the/tftpboot/debian-installer/amd64/txt.cfgfile to add your custom preseed settings:Modify the timeout settings: In the
/tftpboot/debian-installer/amd64/syslinux.cfg, adjust the boot menu timeout to automatically boot Kali if no key is pressed:
5. Using a Preseed File for Unattended Installation
The preseed file can be used to automate the entire installation, including partitioning, package selection, and user creation.
Create the preseed.cfg file:
This file should define all necessary configurations for the installation process. You can host this file on your web server (e.g., Apache) at a URL like
http://192.168.101.1/preseed.cfg.
Link the preseed file in your
txt.cfg: As shown earlier, you can reference the preseed file in the boot parameters:
6. Boot the Client Machine via PXE
Enable PXE booting: Ensure that the target machine is set to boot from the network in its BIOS/UEFI settings.
Start the installation: The client machine should now automatically receive a network boot request, download the necessary boot files from your PXE server, and begin the Kali Linux installation process. If you've configured a preseed file, the installation will proceed fully automatically.
Benefits of PXE Boot for Kali Linux Installation:
Automated Installations: You can automate the installation process for multiple machines without needing physical media.
Customizable: With preseed files, you can fully customize the installation process to suit your environment.
Quick Deployment: Ideal for large-scale deployments where installing Kali on multiple machines quickly is needed.
By following these steps, you can set up a PXE boot server and install Kali Linux over the network, enabling you to efficiently deploy Kali across multiple systems.
11.2. Leveraging Configuration Management
With the ability to install Kali on multiple computers very quickly, you will need some help in managing those machines post-installation.
Configuration management tools can be leveraged to manage these machines or configure replacement computers to any desired state.
Kali Linux contains many popular configuration management tools that you might want to use (Ansible, Chef, Puppet, SaltStack, etc.), but in this section, we will only cover SaltStack.
11.2.1. Setting Up SaltStack
SaltStack is a centralized configuration management service where a salt master manages many salt minions. To set up SaltStack, you need to install the salt-master package on a server that is reachable by all the hosts you want to manage, and the salt-minion package on the hosts that you wish to manage.
Each minion must be configured to know where to find its master. To do this, you need to edit the
/etc/salt/minionfile and set themasterkey to the DNS name or IP address of the Salt master.
For example:
Every minion has a unique identifier stored in
/etc/salt/minion_id, which defaults to its hostname. This identifier is important for configuration rules, so it’s essential to set it properly before the minion connects to the master.
To set the identifier and start the minion service, use:
When the salt-minion service is running, it will try to connect to the Salt master and exchange cryptographic keys. On the master side, you need to accept the minion’s key to allow the connection.
To start the master service and accept the minion’s key, use the following commands:
You’ll see an output with Unaccepted Keys that includes the minion’s identifier. To accept the key:
11.2.2. Executing Commands on Minions
Once the minions are connected, you can execute commands on them from the master. For example, to test the connection between the master and the minions, you can use the
test.pingfunction. This will returnTrueif the connection is working.
Example:
The '*' wildcard targets all minions. You can also target specific minions by their identifier or use a more specific wildcard (e.g., "-scratch" or "kali-").
For example, to execute an arbitrary shell command on a specific minion (kali-scratch):
One of the most useful modules is
pkg, which abstracts package management. For example,pkg.refresh_dbupdates the package list,pkg.upgradeinstalls available updates, andpkg.list_upgradeslists pending upgrades.
Examples:
For a more complex task, you could set up a distributed Nmap scan with
dnmap. First, install the package on all the minions:
Next, instruct all minions to start a client process that connects to the server:
Note that cmd.run_bg runs the command in the background. Since it's a long-running process, don't wait for it to finish. If needed, you can clean up the process later:
11.2.3. Salt States and Other Features
SaltStack offers more than just remote execution; one of its most powerful features is Salt States. These are reusable configuration templates that can be applied to manage systems. By formalizing common setup tasks in state files, you can run multiple operations with a single command using
state.apply.SaltStack provides several features that can be combined, such as:
Scheduled execution of actions
Defining actions triggered by events from minions
Collecting data from minions
Orchestrating sequences of operations across multiple minions
Applying states over SSH without needing to install the salt-minion service
Provisioning systems on cloud infrastructures and bringing them under management
To give you a practical example of working with state files, let's go over a simple one that enables an APT repository, installs a package, and registers an SSH key in root's account.
State files are stored in
/srv/salton the master and use YAML with the.slsextension. State files rely on various state modules to define actions. For example, the following state file (/srv/salt/offsec.sls) calls three modules:
The
offsec_repositorystate registers a package repository using thepkgrepo.managedfunction. It includes a GPG key fetched from the master to verify the repository. Therequire_inensures the repository is set up before the packageoffsec-defaultscan be installed. Thessh_key_for_rootstate adds an SSH key to/root/.ssh/authorized_keysfor root’s account.To apply this state to a minion:
This command will run the states in the offsec.sls file, and you will see output indicating the success of each action (e.g., configuring the repository, installing the package, adding the SSH key).
States can also be associated with specific minions by adding them to the
/srv/salt/top.slsfile, which is used by thestate.highstatecommand to apply all relevant states in a single pass:
To apply the highstate:
This will run all the states listed under the base section for the specified minion (kali-scratch), ensuring that the configuration is consistent.
The output of
state.highstatewill show that the states have already been applied (if they are already configured), ensuring idempotency. This is beneficial for maintaining a consistent configuration across many systems.
11.3. Extending and Customizing Kali Linux
Sometimes you need to modify Kali Linux to make it fit your local needs. The best way to achieve this is to maintain your own package repository hosting the modified versions of the Kali packages that you had to fork, as well as supplementary packages providing custom configuration and extra software (not provided by Kali Linux).
11.3.1. Forking Kali Packages
Forking a package in Kali Linux should be done with caution, as it comes with the responsibility of keeping the package updated with the latest changes from Kali. Forking is appropriate when there's a valid reason to make changes that Kali’s maintainers have not included, but it requires ongoing maintenance to ensure that updates don't conflict with the original version.
Reasons to fork a package:
To add a patch or feature: If you need to fix a bug or introduce a new feature not yet addressed by the upstream developers, forking the package can allow you to make those changes. However, it’s recommended to submit your patch to the upstream maintainers so the fix or feature can be added to the main version.
To compile with different options: If Kali did not compile the package with certain options you need, forking might be the solution. However, it’s best to check with Kali’s maintainers to see if they can incorporate those options, rather than maintaining your own fork.
Bad reasons to fork a package and how to handle them:
Modifying configuration files: Instead of forking a package to change configuration files, you should explore alternatives like using configuration management tools to deploy the modified configuration files automatically. You can also create or use existing configuration packages that place the modified file in the correct directory or divert the original file.
Updating to a newer upstream version: In Kali’s rolling release model, package updates are pushed quickly. Instead of forking the package, it’s better to work with Kali developers to ensure the package is updated in the official repositories.
Key packages that could be interesting to fork in certain scenarios:
kali-meta: This source package builds the
kali-linux-*andkali-tools-*metapackages, includingkali-linux-default, which defines the default packages in the Kali Linux ISO image. You may fork this package if you need to customize the default installation.desktop-base: This package contains files for the default desktop installation. If you want to customize the default desktop appearance, such as changing the background or theme to reflect your organization’s branding, forking this package is an option.
kali-menu: This package defines the structure of the Kali menu and provides
.desktopfiles for the applications listed in the menu. If you need to alter the menu layout or add/remove items, forkingkali-menumight be necessary.
By carefully considering these scenarios, you can avoid unnecessary forks and instead find more efficient ways to customize and maintain your Kali Linux environment.
11.3.2. Creating Configuration Packages
APT Sources & GPG Key:
/etc/apt/sources.list.d/offsec.list: Adds a custom repository for your internal package repository./etc/apt/trusted.gpg.d/offsec.gpg: Contains the GnuPG key used to sign the internal repository.
SaltStack Configuration:
/etc/salt/minion.d/offsec.conf: Configures the Salt minion to connect to your Salt master.
Desktop Configuration:
/usr/share/images/offsec/background.png: Custom background image for Kali systems./usr/share/glib-2.0/schemas/90_offsec-defaults.gschema.override: GNOME desktop settings (like setting the background image).
Steps to Create the Custom Package:
Create Package Directory and Files: Start by creating a directory to hold the package contents and place your files in the appropriate locations.
Run
dh_maketo Set Up Packaging: This will create a basic Debian package structure and required files.When prompted, select
ifor "indep" (since it's architecture-independent) and fill in the necessary information such as email and license details.Edit the Files Created by
dh_make: Afterdh_make, several files will be created in thedebian/directory. Here are the files that require editing:control: Modify the
Sectionfield tomiscand provide details about the package, such as its dependencies and description.copyright: Specify the license (GPL-3.0 in this case) and include the authors.
changelog: Update this file to describe what changes this package introduces (e.g., adding APT sources, configuring SaltStack, setting desktop settings).
Install Configuration Files: Use the
.installfile to specify where to install your configuration files. For example:GNOME Settings File: Create a
gsettings-overridefile to modify the GNOME desktop background and place it in the correct directory (debian/offsec-defaults.gsettings-override):Override
dh_installgsettings: Indebian/rules, override thedh_installgsettingscommand to use a priority of 90 (the priority level for organizational settings):Build the Package: Once all files are configured, use
dpkg-buildpackageto build the package:This will generate the
.debpackage, which can then be installed on any Kali system.Deploy the Package: The generated package
offsec-defaults_1.0_all.debcan be distributed and installed on multiple machines. When installed, it will:Add the custom APT sources and GPG key.
Configure SaltStack to connect to the Salt master.
Set the custom background image.
Apply custom GNOME desktop settings.
Summary:
This process is a great way to manage configuration across multiple machines. By creating a custom package with configuration files, you ensure that your systems are consistently configured. While it may seem complex at first, once you get the hang of it, creating and maintaining custom configuration packages can save a lot of time in managing systems at scale.
11.3.3. Creating a Package Repository for APT
Creating the Custom Package:
First, a custom configuration package (
offsec-defaults) was created. This package contains configuration files (e.g., APT sources, SaltStack configurations, custom background images, and GNOME desktop settings) to be deployed across multiple machines.The
dh_maketool was used to initialize the package structure, followed by editing files likecontrol,changelog, andrulesto customize the package.After building the package using
dpkg-buildpackage, the final.debpackage (offsec-defaults_1.0_all.deb) was created.
Setting Up the APT Package Repository:
The
repreprotool was used to create and manage a custom APT repository where the package would be stored.A new user (
pkgrepo) was created to manage the repository and GPG key.The GPG key was generated to sign the repository and ensure authenticity.
The repository was initialized, and the custom package was added using the
reprepro includecommand.
Configuring the Web Server for Repository Access:
An Apache server was configured to serve the repository's
distsandpooldirectories over HTTP.A corresponding
sources.listentry was created on client machines to access the repository and install the custom package.
PXE Booting and SaltStack Integration:
PXE booting allows machines to boot over the network, fetching the preseed file and the necessary package configurations to install Kali Linux automatically.
SaltStack manages the configuration on client machines, ensuring that they are configured and updated automatically via the Salt master.
Deployment:
Once the setup is complete, new machines can be PXE-booted, automatically configured, and managed without manual intervention.
The custom package can be installed during the installation process or through subsequent updates.
Final Thoughts:
This process is highly flexible and scalable. You can use it to manage a large number of Kali Linux installations across a network, ensuring that they are all uniformly configured and up-to-date with minimal effort. Here are a few additional recommendations and considerations:
Security: Ensure that the GPG keys used for signing the repository and packages are kept secure. If the repository is publicly accessible, ensure proper encryption and security measures are in place (e.g., HTTPS).
Updating Packages: Whenever new updates or configurations are needed, simply update the package and add the new version to the repository. The client machines will automatically pull the latest version when updated via SaltStack.
Automation & Customization: With SaltStack's flexibility, you can easily extend this setup to manage more complex configurations, deploy additional software, or monitor systems across your network.
Backup and Disaster Recovery: Consider implementing a backup strategy for the repository and configuration files. This ensures that you can quickly recover from any issues, whether they be accidental deletions or server failures.
This setup provides a powerful solution for managing and deploying consistent, secure environments across a network of Kali Linux systems, which can be particularly useful for enterprise, educational, or research environments.
11.4. Summary
Kali Linux in Large-Scale Deployments Kali Linux is capable of scaling beyond desktop usage, catering to medium and large-scale deployments, including enterprise-level environments. To facilitate the management of multiple Kali installations, SaltStack can be utilized, enabling centralized management. This setup helps deploy highly secure Kali systems that are preconfigured for specific needs, and ensures synchronization through the semi-automatic installation of package updates.
Package Forking Forking packages allows you to create customized distributable source packages. This capability can be particularly useful for tailoring Kali Linux to fit specific requirements. However, it’s important to evaluate the pros and cons of forking a package, as the process can be complex and challenging.
Steps for Setting Up SaltStack To establish Salt Masters and Minions for remote control and configuration of systems, follow these major steps:
Boot the machine via PXE with the necessary file servers: TFTP, DHCP/BOOTP, and a web server for debconf preseeding.
Use dnsmasq for DHCP and TFTP server configuration. Basic configuration includes defining the interface, DHCP range, gateway, DNS servers, and boot file for PXE booting.
Unpack Kali Linux installation boot files from the Kali archive into the
/tftpboot/directory.Modify
txt.cfgfor unattended installations if needed.
PXE Setup with dnsmasq The dnsmasq configuration for PXE booting should include the network interface to handle (e.g.,
interface=eth0), IP range allocation (dhcp-range), gateway, DNS servers, boot file (dhcp-boot=pxelinux.0), and TFTP options (enable-tftp). The boot files can be downloaded and unpacked from the Kali archive, with specific netboot files for 32-bit and 64-bit versions.SaltStack Configuration Once you have Kali Linux systems set up, SaltStack can be used to manage them. Install
salt-masteron the central server andsalt-minionon the managed hosts. Configure the/etc/salt/minionfile with the master’s DNS name or IP address. Set the minion’s unique identifier using/etc/salt/minion_id. Start thesalt-minionservice and enable it on boot:On the Salt master, accept the minion's key:
After the minion is connected, you can run commands on it from the master, such as checking connectivity with:
Execution and State Modules in SaltStack Salt allows executing commands remotely using execution modules. Examples include checking system information (
salt kali-scratch cmd.shell 'uptime; uname -a') or managing services (salt '*' service.enable ssh). Package management can also be handled with commands likesalt '*' pkg.refresh_dborsalt '*' pkg.upgrade dist_upgrade=True.Salt State Files For efficient configuration management, Salt state files are used to define reusable configuration templates. These can be used to orchestrate operations, provision cloud systems, and ensure desired configurations across multiple systems. Predefined Salt formulas are also available to speed up deployment.
Forking Packages Forking a package, such as kali-meta, desktop-base, or kali-menu, can be a viable strategy for customization. However, forking comes with its own challenges, and it is essential to carefully assess whether it is the best approach for your needs.
Hacker's Mantra: The hacker mindset doesn’t actually see what’s there; it sees what’s missing. -- Bruce Schneier
Last updated
Was this helpful?