Back to Home

Kali Linux: security policy, protection of computers and network services / RUVDS.com blog

administration · Linux · security

Kali Linux: security policy, protecting computers and network services

Original author: Collective of authors
  • Transfer
→ Part 1. Kali Linux: security policy, protecting computers and network services
→ Part 2. Kali Linux: filtering traffic using netfilter
→ Part 3. Kali Linux: monitoring and logging
→ Part 4. Kali Linux: exercises to protect and monitor the system

Recently we asked the Habr community a question on the appropriateness of translating the book " Kali Linux Revealed ". Upon reflection, taking into account the voting results and comments on the material, we decided to translate some parts of the book. We begin with chapter 7: “Protecting and Monitoring Kali.” In particular, this material provides a translation of sections 7.1-7.3, which are devoted to the system security policy, protection of servers, laptops and network services.



Chapter 7. Protection and Monitoring Kali


As soon as you start using Kali Linux in increasingly demanding and large-scale projects, you will probably need to take your own system more seriously. This chapter will begin with a discussion of security policies.

Here we will highlight various points that you should pay attention to when defining a security policy, we will show some threats to which both computers and professional pentesters are exposed. In addition, we will discuss security measures applicable to laptops and desktops, with particular attention to firewalls and packet filtering. And finally, we will focus on monitoring tools and strategies, and show how to establish monitoring to identify potential threats.

7.1. Security Policy Definition


It makes no sense to talk about security in general terms, since the concept of "security" consists of a wide range of concepts, tools and procedures that are not applicable in all situations without exception. Choosing exactly what you need requires a clear understanding of the goals of someone who is going to protect something. System protection begins with answers to several questions. Having rushed headlong to introduce the first available means of ensuring security, anyone risks paying attention not to what is really important.

It is usually best to start by defining a specific goal. To do this, it is useful to find answers to the following questions:

  • What are you trying to protect? Security policies will vary depending on whether you want to protect computers or data. In the latter case, in addition, you need to know exactly what the data is.
  • What are you defending yourself from? Is this a confidential data leak? Accidental data loss? Loss of income caused by a malfunction in a certain service?
  • Who are you protecting yourself from? Security measures will vary greatly, for example, when protecting against the error of an ordinary user of the system and when protecting against a seriously configured external group of hackers.

The term “risk” is usually used to refer to all three of these factors: what to protect, what exactly needs to be prevented, and who can cause it. Risk modeling requires answers to the three questions above. A security policy can be created based on the constructed risk model, after which it can be implemented by performing specific actions.

▍ Security is a process


Bruce Schneier, a world-renowned security expert (and not just computer one), is trying to fight one of the most important myths in the field of security, saying: "Security is a process, not a result." What they protect changes over time, the same thing happens with threats and with tools that are available to potential attackers. Even if the security policy was originally ideally designed and implemented, one should never be content with what has been achieved. Risk components are evolving and responses must be developed accordingly.

When setting up a security policy, additional restrictions should be taken into account, as they can narrow the range of available funds. How far are you willing to go in order to protect the system? This issue has a decisive influence on deciding what exactly needs to be done. Too often, the answer to it is expressed only in terms of value, but other aspects need to be taken into account. Among them is the complication of user work or a drop in productivity.

After completing the risk modeling, you can begin to think about developing the security policy itself.

For example, here are a couple of examples that demonstrate the extremes in deciding which level of security to implement. On the one hand, providing a basic level of security is very simple.

For example, the system that needs to be protected is an old computer, whose only role is to help add up a couple of numbers at the end of the day. The decision not to do something special to protect such a computer would be quite reasonable. The objective value of the system is small, and the value of the data is completely zero, since they are not stored on this computer.

A potential attacker who has penetrated this system will have at his disposal only a calculator. The cost of protecting such a system may be higher than the loss from breaking it.

On the other side of the spectrum of value of systems is the task of ensuring the confidentiality of sensitive data using the most advanced security tools. Everything else is not important in this scenario. In such a case, the complete destruction of data would be an appropriate measure (it is safe to erase files, break a hard disk into pieces, dissolve these pieces in acid, and so on). If there is an additional requirement that the data should be stored for future use (although it does not have to be easily accessible), and if the cost of the issue does not matter, then you need to start by writing data to the iridium-platinum plates that are stored in bomb shelters built in the bowels of the mountains in several places on the globe, each of which (naturally) should be completely secret and guarded by an army.

Although these examples may seem very extreme, they, nevertheless, can represent adequate responses to certain risks, as long as they are the result of reflection, during which the goals and limitations of information protection are taken into account. Any security policy based on a reasoned decision is acceptable.

Let us return to more typical cases. The information system can be divided into homogeneous, and, basically, independent subsystems. Each subsystem will be characterized by its own requirements and limitations. As a result, risk analysis and development of a security policy framework should be performed separately for each of these subsystems. There is one valuable principle that is important to remember when working on security policies: a small attack surface is easier to defend than a large one. The network also needs to be organized accordingly. Critical services must be assembled on a small number of computers accessible through a minimum of routes or control points. There is a clear logic behind this: it’s easier to protect these control points than to protect valuable computers from the whole outside world. It is in this situation that the usefulness of network filtering becomes apparent (including the one performed by firewalls). Filtering can be implemented on the basis of dedicated hardware, but a simpler and more flexible solution is to use software firewalls, such as the one integrated into the Linux kernel.

7.2. About security measures


As mentioned in the previous section, there is no single right answer to the question of how to protect Kali Linux. It all depends on how you use it and what exactly you are trying to protect.

▍7.2.1. Server protection


If you use Kali Linux on a public server, you will most likely need to protect network services by changing the standard passwords that can be set in the configuration files (for more details, see 7.3., “ Protecting Network Services ”), and, perhaps by restricting access to them using a firewall (for more on this, see section 7.4., “ Firewall or packet filtering .”

If you issue accounts to other users either on the server itself or on one of the services, you need to check that they were installed resistant to cracking Oli, those that are able to withstand an attack by brute force. At the same time, it may be appropriate settingfail2ban, which will complicate cracking passwords with brute force over the network (by filtering IP addresses from which the limit for unsuccessful login attempts is exceeded). In order to install fail2ban, run the following commands:

apt update
apt install fail2ban

If you support web services, it’s probably worth it to arrange access to them via HTTPS in order to prevent an attacker from analyzing your traffic (which may contain authentication cookies).

▍7.2.2. Laptop protection


A Pentester laptop is not exposed to the same risks as a public server. For example, it is less likely to be the victim of a random scan performed by amateur hackers, and even if this happens, you probably will not have network services turned on.

The real risk often arises when you move from one client to another. For example, your laptop can be stolen on the go, it can be confiscated at customs. That is why you most likely should use full disk encryption (for more details, see section 4.2.2., “ Installing on a fully encrypted file system ”), and possibly configure the self-destruct function (for more details, see “ Installationself-destruct password to increase security"). The data that you collected during the study is confidential, they need the best protection.

In addition, you may need to set firewall rules (for more details, see section 7.4., “ Firewall or packet filtering ”).»), But not for the same purpose as on the server. You will probably find it necessary to block all outgoing traffic except for the one that your VPN generates. This means organizing secure networking. If, for example, your VPN connection stops working, you will immediately know about it (instead of switching to local access to the network). As a result, you don’t divulge your client’s IP addresses by browsing the web or doing something else on the Internet. In addition to this, if you perform a local external check, it is better to control everything that you do in order to reduce the “noise” that you create on the network, which can attract the attention of users and their protection systems.

7.3. Network Services Protection


It is recommended that you disable unused network services. In Kali, most network services are disabled by default.

While services are disabled, they do not pose a security risk. However, including them, you should be vigilant for the following reasons:

  • By default, the firewall is not enabled, so if the service listens on all network interfaces, they, in fact, become public.
  • Some services do not have credentials for authentication; they give you the option to set them up the first time you use them. Some have standard accounts, their logins and passwords are widely known. Check that service access passwords have been set or changed to those that only you know.
  • Many services run as superuser, with full administrative privileges, so unauthorized access to them or holes in their security system usually lead to serious consequences.

▍About standard accounts


We will not list here all the programs that, after installation, are configured to use standard credentials. In order to find out the details of the corresponding package, it is worth looking at its README.Debian file, as well as looking for information on docs.kali.org and tools.kali.org in order to find out if some service needs special actions to ensure it security.

If you use the system in live mode, the password for the root account is toor. As a result, you should not enable SSH before changing the password for the root account, or before configuring its configuration to prohibit connections using a password.

In addition, note that the BeEF program (from the already installed beef-xss package) has default credentials in the form of the user “beef” and the password “beef”, which are recorded in the standard configuration file.

Summary


In this article, you familiarized yourself with some considerations regarding the formation of a system security policy, learned about approaches to protecting servers, laptops, and network services. Next time we will share with you the translation of section 7.4., Which is devoted to the firewall and packet filtering in Kali LInux.

Dear readers! How do you approach the formation of security policies? How do you protect computers for various purposes?

Read Next