7.2. Possible Security Measures
As the previous section explained, there is no single response to the question of how to secure Kali Linux. It all depends on how you use it and what you are trying to protect.
If you run Kali Linux on a publicly accessible server, you most likely want to secure network services by changing any default passwords that might be configured (see Section 7.3, “Securing Network Services”) and possibly also by restricting their access with a firewall (see Section 7.4, “Firewall or Packet Filtering”).
If you hand out user accounts either directly on the server or on one of the services, you want to ensure that you set strong passwords (they should resist brute-force attacks). At the same time, you might want to setup fail2ban, which will make it much harder to brute-force passwords over the network (by filtering away IP addresses that exceed a limit of failed login attempts). Install fail2ban with
apt update followed by
apt install fail2ban.
If you run web services, you probably want to host them over HTTPS to prevent network intermediaries from sniffing your traffic (which might include authentication cookies).
The laptop of a penetration tester is not subject to the same risks as a public server: for instance, you are less likely to be subject to random scans from script kiddies and even when you are, you probably won’t have any network services enabled.
Real risk often arises when you travel from one customer to the next. For example, your laptop could be stolen while traveling or seized by customs. That is why you most likely want to use full disk encryption (see Section 4.2.2, “Installation on a Fully Encrypted File System”) and possibly also setup the “nuke” feature (see Adding a Nuke Password for Extra Safety): the data that you have collected during your engagements are confidential and require the utmost protection.
You may also need firewall rules (see Section 7.4, “Firewall or Packet Filtering”) but not for the same purpose as on the server. You might want to forbid all outbound traffic except the traffic generated by your VPN access. This is meant as a safety net, so that when the VPN is down, you immediately notice it (instead of falling back to the local network access). That way, you do not divulge the IP addresses of your customers when you browse the web or do other online activities. In addition, if you are performing a local internal engagement, it is best to remain in control of all of your activity to reduce the noise you create on the network, which can alert the customer and their defense systems.