Configuring Kali Linux for Cyber Essentials Plus

Configuring Kali Linux for Cyber Essentials Plus

Posted by Peter Bassill on 21/05/2021

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
 
 

Contact us



  • Worklab, Europort, Gibraltar

  • +350 540 73836

  • hello@wearehedgehog.com