Your Basket
Cyber security for any size of business
CREST member company
Team of friendly certified experts
Configuring Kali Linux for Cyber Essentials Plus

Configuring Kali Linux for Cyber Essentials Plus

CE Plus Compliant Kali

IASME asked us to write up 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 games  

userdel news  

userdel backup    

userdel irc  

userdel 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:
    • lock accounts after no more than 10 unsuccessful attempts
    • limit the number of guesses allowed in a specified time period to no more than 10 guesses within 5 minutes
    • set a minimum password length of at least 8 characters
    • not set a maximum password length
    • change passwords promptly when the Applicant knows or suspects they have been compromised

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 Addresses

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 = alerts@hedgehogsecurity.com

sender = bot@hedgehogsecurity.com

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 = true

port = ftp,ftp-data,ftps,ftps-data

logpath = %(proftpd_log)s

backend = %(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 = true

maxretry = 3

findtime = 1d

bantime = 4w

ignoreip = 127.0.0.1/8 23.34.45.56

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 psad

ufw allow ssh

ufw allow https

ufw allow http

ufw enable

sed -i "s/root@localhost/$EMAIL/g" /etc/psad/psad.conf

sed -i "s/_CHANGE_ME_/$HOSTNAME/g" /etc/psad/psad.conf

sudo 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 admins

usermod -a -G admins usera

usermod -a -G admins userb

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

Port 22

KexAlgorithms ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256

Ciphers aes256-ctr

MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-256

Protocol 2

HostKey /etc/ssh/ssh_host_ed25519_key

HostKey /etc/ssh/ssh_host_ecdsa_key

HostKey /etc/ssh/ssh_host_dsa_key

HostKey /etc/ssh/ssh_host_rsa_key

UsePrivilegeSeparation sandbox

KeyRegenerationInterval 3600

ServerKeyBits 1024

SyslogFacility AUTH

LogLevel INFO

LoginGraceTime 60

PermitRootLogin no

AllowGroups admins

StrictModes yes

RSAAuthentication yes

PubkeyAuthentication yes

IgnoreRhosts yes

RhostsRSAAuthentication no

HostbasedAuthentication no

PermitEmptyPasswords no

ChallengeResponseAuthentication no

X11Forwarding no

X11DisplayOffset 10

PrintMotd yes

PrintLastLog yes

TCPKeepAlive yes

AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

 

 

Sign up to our newsletter

Keep up to date with the latest cyber security news and updates with our newsletter