Configuring Kali Linux for Cyber Essentials Plus


*** This is out of date ***

I have documented how to build and configure our base Kali Linux machines.

Configuring Kali Linux for Cyber Essentials Plus

Posted on 2021-05-21 by Peter Bassill in category Cyber Essentials.


Cyber Essentials   Kali   Guides  


Caution - This is now of out date. The NCSC don't want anyone running Kali. As per an email from Andrew at IASME: "Pentesting machines running dedicated software for example Kali Linux or Parrot OS are not compliant for Cyber Essentials and should be moved to a separate Sub-Set."

So now, please see "How to build a kali equivalent that is CE Plus compliant." A link will appear shortly.

CE Plus Compliant Kali

Here is our Kali Linux build after a lot of firms were having issues getting their Kali builds through the Cyber Essentials Plus standard. So here I have documented how to build and configure our base Kali Linux machines.

If you are not familiar with Kali Linux, it is one of the more popular Penetration Testing distributions. Based on the ever-popular Debian builds, you should be able to adapt this for most Linux distributions.

Section 1: Computers and Network Devices

Let us look at the Cyber Essentials requirements for your computers. The standard requires that you must:

remove and disable unnecessary user accounts (such as guest accounts and administrative accounts that won’t be used)
change any default or guessable account passwords to something non-obvious
remove or disable unnecessary software (including applications, system utilities and network services)
disable any auto-run feature which allows file execution without user authorisation (such as when they are downloaded from the Internet)
authenticate users before allowing Internet-based access to commercially or personally sensitive data, or data that is critical to the running of the organisation

All of that is straightforward and logical. Let us apply some modifications to a base Kali Linux build so we are in line with the stand.

Remove and disable unnecessary user account

userdel gamesuserdel newsuserdel backupuserdel ircuserdel gnats
userdel nobody

Change any default or guessable account passwords to something non-obvious


RPASS=`openssl rand -base64 32`
echo"root:$RPASS"| sudo chpasswd

 

Remove or disable unnecessary software

As this is a Kali workstation, used for penetration testing, it is safe to say that all of the installed applications and software are required.

Disable any auto-run feature which allows file execution without user authorisation
The Auto-mounting of disks in Debian-based Linux distros (and perhaps others) comes from a service called udisks2. Disabling this service will prevent any disk from automatically being mounted, while still allowing manual mounting.

Disable the service - No automatic or manual starts

systemctl mask udisks2

Get the status

systemctl status udisks2

Section 2 - Password Authentication

The standard here is very verbose. The standard states Internet-facing. You MUST assume that a penetration testers workstation is going to be used in multiple environments and therefore is deemed to be Internet-facing.

For password-based authentication in Internet-facing services you must protect against brute-force password guessing, by using at least one of the following methods:


1. lock accounts after no more than 10 unsuccessful attempts
2. limit the number of guesses allowed in a specified time period to no more than 10 guesses within 5 minutes
3. set a minimum password length of at least 8 characters
4. not set a maximum password length
5. change passwords promptly when the Applicant knows or suspects they have been compromised
6. Protect against brute-force password guessing

This is really simple by leverage the service fail2ban. To install it, use:

sudo apt install fail2ban

Once the installation is completed, the Fail2ban service will start automatically. You can verify it by checking the status of the service:

sudo systemctl status fail2ban

The default Fail2ban installation comes with two configuration files, /etc/fail2ban/jail.conf and /etc/fail2ban/jail.d/defaults-debian.conf. It is not recommended to modify these files as they may be overwritten when the package is updated.

Fail2ban reads the configuration files in the following order. Each .local file overrides the settings from the .conf file:

/etc/fail2ban/jail.conf/etc/fail2ban/jail.d/*.conf/etc/fail2ban/jail.local/etc/fail2ban/jail.d/*.local

For most users, the easiest way to configure Fail2ban is to copy the jail.conf to jail.local and modify the .local file. More advanced users can build a .local configuration file from scratch. The .local file doesn’t have to include all settings from the corresponding .conf file, only those you want to override.

Create a .local configuration file from the default jail.conf file:

sudo cp /etc/fail2ban/jail.{conf,local}

To start configuring the Fail2ban server open, the jail.local file with your text editor:

sudo nano /etc/fail2ban/jail.local

The file includes comments describing what each configuration option does. In this example, we’ll change the basic settings.

Whitelist IP Addresse

IP addresses, IP ranges, or hosts that you want to exclude from banning can be added to the ignoreip directive. Here you should add your local PC IP address and all other machines that you want to whitelist.

Uncomment the line starting with ignoreip and add your IP addresses separated by space:

/etc/fail2ban/jail.local
ignoreip = 127.0.0.1/8 ::1 123.123.123.123 192.168.1.0/24

Ban Settings

The values of bantime, findtime, and maxretry options define the ban time and ban conditions.

bantime is the duration for which the IP is banned. When no suffix is specified, it defaults to seconds. By default, the bantime value is set to 10 minutes. Generally, most users will want to set a longer ban time. Change the value to your liking:/etc/fail2ban/jail.local

bantime = 10d

To permanently ban the IP use a negative number.

findtime is the duration between the number of failures before a ban is set. For example, if Fail2ban is set to ban an IP after five failures (maxretry, see below), those failures must occur within the findtime duration. Look in /etc/fail2ban/jail.local

findtime = 10m

maxretry is the number of failures before an IP is banned. The default value is set to five, which should be fine for most users. Look in /etc/fail2ban/jail.local

maxretry = 3

Email Notifications

Fail2ban can send email alerts when an IP has been banned. To receive emails, you need to have an SMTP installed on your server and change the default action, which only bans the IP to %(action_mw)s, as shown below in /etc/fail2ban/jail.local:

action = %(action_mw)s

%(action_mw)s bans the offending IP and sends an email with a whois report. If you want to include the relevant logs in the email, set the action to %(action_mwl)s.

You can also adjust the sending and receiving email addresses in /etc/fail2ban/jail.local

destemail = [email protected] = [email protected]

Fail2ban Jails

Fail2ban uses a concept of jails. A jail describes a service and includes filters and actions. Log entries matching the search pattern are counted, and when a predefined condition is met, the corresponding actions are executed.

Fail2ban ships with a number of jail for different services. You can also create your own jail configurations.

By default, only the ssh jail is enabled. To enable a jail, you need to add enabled = true after the jail title. The following example shows how to enable the proftpd jail:

/etc/fail2ban/jail.local[proftpd]enabled = trueport = ftp,ftp-data,ftps,ftps-datalogpath = %(proftpd_log)sbackend = %(proftpd_backend)s

The settings we discussed in the previous section, can be set per jail. Here is an example:

/etc/fail2ban/jail.local[sshd]enabled = truemaxretry = 3findtime = 1dbantime = 4w

The filters are located in the /etc/fail2ban/filter.d directory, stored in a file with the same name as the jail. If you have a custom setup and experience with regular expressions, you can fine-tune the filters.

Each time you edit a configuration file, you need to restart the Fail2ban service for changes to take effect:

sudo systemctl restart fail2ban

Setting Password Strength

We will set the password policy using pam_pwquality

apt install libpam-pwquality
sed -i "s/pam_pwquality.so retry=3/pam_pwquality.so retry=3 minlen=16 credit=-1 dcredit=-1 minclass=2/g" /etc/pam.d/common-password

Changing the password at regular interval helps limits the period of unauthorized use of passwords. Password expiration policy can be configured through “/etc/login.defs” file.Run this command to edit this file:

sudo nano /etc/login.defs

Add the following lines with values as per your requirements.

PASS_MAX_DAYS 0PASS_MIN_DAYS 0PASS_WARN_AGE 8

Section 3 - Malware Protection

The simplest thing here is to get a licence for ESET NOD32 Linux endpoint AV/AM solution. But be warned, you are going to need to spend some time setting up your exclusions.

Your other option is ClamAV and then using a browser plugin to scan pages and files.

Section 4 - Security Update Management

If you are not updating your Kali workstation every day, then you should be. The very simplest way is to add it to the root user cron table. Add the following entry to the root crontab:

0 0 * * * root apt update && apt DEBIAN_FRONTEND=noninteractive upgrade -y > /dev/null 2>&1

Now every night the updates will run automatically. However, it is always a good idea as a matter of good house keeping to run it when you first login. All you need is:

sudo apt update && sudo apt upgrade -y

Section X – Beyond Cyber Essentials

While getting over the baseline of Cyber Essentials is great, there is a lot more you should do if you are going to be using Kali as a professional.

Add in a firewall

We use UFW to provide an easy way to run the host local firewall and then PSAD to detect anyone scanning our system and automatically block that IP.

apt install -y ufw psadufw allow sshufw allow httpsufw allow httpufw enablesed -i "s/[email protected]/$EMAIL/g" /etc/psad/psad.confsed -i "s/_CHANGE_ME_/$HOSTNAME/g" /etc/psad/psad.confsudo service psad restart

Harden SSH

It is a good idea to restrict who can SSH to your machine. If you do not already have an admins group on your workstation, you can create it very easily and add users to it like this:

addgroup adminsusermod -a -G admins userausermod -a -G admins userb

Next you simply copy over the following SSH config to your /etc/ssh/sshd_config.

Port 22KexAlgorithms ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256Ciphers aes256-ctrMACs [email protected],[email protected],hmac-sha2-512,hmac-sha2-256


Get in Touch

Kindly fill the form and we will get back to you.

Contact us if you are experiencing a Cyber IncidentHaving a Cyber Incident?